Dale Worley wrote: > > Although it looks strange, it is an intentional behavior. > > sipXrls uses this algorithm for subscribing to any URI that appears in a > resource list: sipXrls maintains a list of "contacts" for the URI, and > then maintains a dialog event subscription to each contact. By default, > the only contact for a URI is the URI itself. But sipXrls also > attempts to maintain a 'reg' event subscription to the URI, in order to > retrieve the list of registered contacts for the URI. If sipXrls > receives a reg event, it will use the registered contacts listed in the > NOTIFY to update the list of contacts for the URI. (If there are no > contacts, the URI itself is put in the list of contacts.) > > So when sipXrls starts up, it first does a dialog event subscription to > the URI itself (because it hasn't yet seen a reg event for that URI, and > so the only listed contact for the URI is the URI itself). That is > where the first SUBSCRIBE comes from. Soon afterward, it does a reg > event subscription to the URI and receives a reg event. So sipXrls > updates the contact list for the URI to be the registered contact > address. sipXrls then subscribes to the contact address. That is where > the second SUBSCRIBE comes from. sipXrls also un-subscribes from the > URI itself, which is no longer a listed contact. > > The confusing message flow is because sipXrls is trying to terminate the > first subscription. Depending on the exact timing of various events, > there are a number of possibilities, but the commonest is that the > sipXrls application code makes the un-subscribe call to the Subscribe > Client before sipXrls has received either the 2xx response to the > SUBSCRIBE or the first NOTIFY from the phone. So the Subscribe Client > can't immediately send a "SUBSCRIBE expires=0" to terminate the > subscription, as it doesn't have a to-tag to send with. Then, the > Subscribe Client receives the first NOTIFY, to which it responds 481 > (because the subscription has been terminated by the application). > Then, the Subscribe Client receives the 2xx from the SUBSCRIBE, which it > ignores (because it has already told the far end that the subscription > is terminated, via the 481 response to the NOTIFY, and so knowing the > to-tag from the 2xx does not make it send "SUBSCRIBE expires=0"). > > The message flow looks strange, but it works correctly. (After I fixed > a couple of bugs in the Subscribe Client.) > > Dale > >
Thanks for the explanation. The timing of the messages totally threw me off me into thinking that sipXrls was updating the contact info from the dialog-forming 200 OK it received, and then starting a new subscription based on that. The SipUserAgent instance passed to the SipSubscribeClient is not configured with an outbound proxy. Hence when you build a SUBSCRIBE using the contact address found from the 'reg' event subscription, the subscribe bypasses the proxy and goes straight to the phone. Is this ideal (esp. with the NAT Traversal feature)? Is is feasible to send the subscriptions using the URI that appears in the resource list, and let the proxy and registrar deal with forwarding it to the respective contacts associated with the URI? We can still use the 'reg' events to keep a tab on all phone registration events, with the difference being the subscriptions are not updated for individual contacts, but the URI in general. Arjun _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
