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
