Re: submission of a new I-D: "Dialog Event foR Identity VErification"

2008/10/28 Juha Heinanen <[email protected]>:
> Iñaki Baz Castillo writes:
>
>  > >  > I'm afraid that you are assuming that a presence server is used.
>  > >  > Derive is an _end-to-end mechanism_ implemented in the UAs.
>  > >
>  > > if i have configured my proxy to use presence server for local users,
>  > > how does subscribe reach the UA?
>  >
>  > If you proxy includes a dialog presence server, then the SUBSCRIBE
>  > doesn't need to reach the UA since your proxy already has the
>  > information about dialogs of that UA.
>
> inaki,
>
> now i'm confused again.  in above, you say that this is a UA thing,  now
> you seem to indicate, that proxy needs to keep track of the dialogs.
> so far i'm not convinced that proxy can reliable keep track of dialogs.

There are two possibilities:

1) The SUBSCRIBE arrives to the UA location.
- A calls B.
- B sends a SUBSCRIBE (Event: dialog;acll-id=xx;to-tag=xx) to A AoR.
- The proxy responsible for A receives the SUBSCRIBE and forwards it
to A location(s). Note that the proxy allows this SUBSCRIBE since the
"Event" header is "dialog" containing "call-id" and "to-tag". It could
also check if the "Expires" equals 0. So this is not a SUBSCRIBE "for
all the calls from/to A", but a SUBSCRIBE for an spedific dialog.
- B receives the SUBSCRIBE and since B implements RFC 4235 (receiving
the SUBSCRIBE, not just publishing) it checks if that dialog exists.
If it, B replies 200 and sends a NOTIFY (mandatory).
- A receives the 200 so has verified the sender identity.
- B start ringing and so...

2) The SUBSCRIBE is handled by a proxy / presence server.
- A calls B through P1 (proxy responsible for A).
- P1 includes a dialog presence agent (as pua_dialoginfo). This agent
generates a PUBLISH that is sent to the integrated (or separate)
dialog presence server (we are not speaking about a SIMPLE presence
server). So the dialog presence server is now aware of the current
dialog between A and B.
- B sends a SUBSCRIBE (Event: dialog;acll-id=xx;to-tag=xx) to A AoR.
- The proxy responsible for A receives the SUBSCRIBE and forwards it
to its presence server. Again, the proxy allows this SUBSCRIBE since
the "Event" header is "dialog" containing "call-id" and "to-tag".
- The presence server checks the dialog data in the "Event" header of
the SUBSCRIBE (as A does in case 1). If it matches an existing dialog
if replies 200 and NOTIFY as in case 1.
- A receives the 200 so has verified the sender identity.
- B start ringing and so...


> in openser/kamailio environment, for example, keeping track of dialogs
> is implemented using dialog module, which has the history of being the
> most buggies module of all.  perhaps that is due to the difficulty of
> the problem, i.e., proxy is made to do something it is not really
> intended for.

Probably. Anyway this draft defines a correct behaviour that can work
in environments in which the SUBSCRIBE would be sent to UA or would be
handled by a presence server.
As you say, probably dialog status shouldn't be handled by a proxy,
but that's a different issue.



-- 
Iñaki Baz Castillo
<[email protected]>
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip