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
