Hi When the Subscription expires on the server, it should have sent NOTIFY message with Subscription State as "Terminated" before removing the dialog. Sending a NOTIFY would ensure that the subscriber has also been communicated that the subscription no longer exist and if it wants to subscribe again, it should be fresh subscription request rather than refresh subscription. If the server still receives a subscribe requets with "To" tag that does not match any dialogs at server then it should be responded with 481 response.
Regards Anuradha Gupta (Aricent) ________________________________________ From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Hari Kumar [EMAIL PROTECTED] Sent: Wednesday, October 08, 2008 6:59 PM To: 'Iñaki Baz Castillo' Cc: [email protected] Subject: Re: [Sip-implementors] Initial Subscribe Request with "To Tag" Hi, Thanks for the reply. Actually our device acts as a sip server (which maintains dialogs). Sorry for the confusion. Scenario is, Our sip server acts as the subscription server also. IP phone has subscribed to our server, say for 500.sec. After 100.sec, IP phone was not available in the network till 600.sec. Now the subscription will expire on the server (since the IP phone has not renewed its subscription). So the corresponding dialog also would be destroyed in the server. Once the IP phone becomes available on the network, it would try to renew the subscription (with old dialog parameters). >From the server point of view, it is a new subscribe request with "To tag", >which does not match any of its dialogs. I believe that, now you have understood the scenario. So shall we proceed with "481 call/transaction does not exist". Regards Hari -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Iñaki Baz Castillo Sent: Wednesday, October 08, 2008 6:19 PM Cc: [email protected] Subject: Re: [Sip-implementors] Initial Subscribe Request with "To Tag" 2008/10/8 Hari Kumar <[EMAIL PROTECTED]>: > Hi, > > > > If a proxy server receives an initial subscribe request with "to > tag", then how it should handle. From the proxy point of view, there is no > matching dialog. Is there any need to create a new dialog, for this request > (with To tag).. Shall we send "481 call/transaction does not exist". I suppose that when you say "an initial subscribe request with 'to' tag" you mean a SUBSCRIBE with To tag not matching an existing dialog. Well, a proxy doesn't handle dialogs (SUBSCRIBE creates a dialog), it's a task of a presence server (that could be located in the same hsot as the proxy but it's a completely different role, in fact it's a **UAS**). So, the real escenario would be: UA ------ Proxy ----- Presence Server (UAS) (maybe the Proxy and Presence Server are the same, but they are two differents nodes). So when the Proxy receives a SUBSCRIBE with "To" tag (or any request with "To" tag) it should just route it (based in RURI or remaining Route headers if they exist after the proxies eliminates the top Route pointing to him). So, the Presence Server (UAS) will receive the request, an in-dialog request, and since it's a UAS it **can** know that the dialog doesn't exist, so it must reply a "481 call/transaction does not exist". -- Iñaki Baz Castillo <[EMAIL PROTECTED]> _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors DISCLAIMER: This message is proprietary to D-Link (India) Limited and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. D-Link (India) Limited accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error,please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
