On Thu, 2008-08-21 at 18:14 -0400, Arjun Nair wrote: > When the sipXrls server starts up, it sends a SUBSCRIBE to the monitored > phone through the PROXY.. Upon receiving this, the phone accepts it and > sends back a NOTIFY. However, sipXrls replies to this NOTIFY with a 481, > terminating the subscription. It then sends a second SUBSCRIBE > (different call-id etc.) straight to the phone (bypassing the proxy), > and establishes a dialog successfully. > > Is this an intentional behavior? If so why?
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 _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
