On 10/1/14 9:08 AM, Kumar, Puneet (Puneet) wrote:
Hi All,
Consider following use case:
UA1 Proxy UA2
----SUBSCRIBE---->
----------SUBSCRIBE----->
<----------200---------------
<-----------NOTIFY----------
<-------NOTIFY------
<-------200-----------
As seen above UA1 Subscribe to UA2 for an event through Proxy server.
UA2 accepts this subscribe & respond with a 200 followed by a NOTIFY to
indicate current status of the event.
But somehow proxy send the NOTIFY first to UA1 followed by 200 for SUBSCRIBE.
As per section 3.1.4.4 on RFC 3265 above behavior on UA1 is allowed.
Currently UA1 ignores this NOTIFY as it always expected NOTIFY after
200(SUBSCRIBE)
What should UA1 do so that it can handle this message mismatch properly?
If UA2 receive some 4xx response for NOTIFY with a retry-after header will it
retry NOTIFY?
Maybe, if you are lucky.
I presume you are talking about a case where all of these are following
RFC3265, rather than RFC6665?
The way UA1 is supposed to behave is:
- the subscribe has a to-tag but no from-tag.
- after sending the subscribe, UA1 has a pending dialog
awaiting complete establishment when the from-tag becomes known
- the notify will have the from-tag and call-id from the invite,
plus a to-tag assigned by UA2
- UA1 should try to match the (from-tag,call-id,to-tag) of the
notify against existing established dialogs. This will fail.
- then (special case for notify), UA1 should try to match the
(from-tag,call-id) against pending dialogs. This will succeed.
- UA1 marks the pending dialog complete, filling in the to-tag.
(You can make the assumption here that the subscribe will
eventually succeed.)
- UA1 goes ahead and processes the notify.
- later the 2xx for the invite arrives. UA1 successfully matches
this against existing established dialogs, and processes it.
RFC6665 clarifies this behavior and tweaks it some.
Thanks,
Paul
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
