[Sip-implementors] SUBSCRIBE 200 & NOTIFY out of order.

[Kumar, Puneet (Puneet)]

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?

Thanks,
Puneet

[Paul Kyzivat]

Post by Kumar, Puneet (Puneet)
Hi All,
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

[Dale R. Worley]

From: "Kumar, Puneet (Puneet)" <puneetk at avaya.com>
As per section 3.1.4.4 on RFC 3265 above behavior on UA1 is allowed.

The reason this is allowed is that the messages may go through the
network at different speeds. Even if UA2 *sends* the NOTIFY after the
200, there is no guarantee it will *arrive* at UA1 after the 200.

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?

The correct behavior for UA1 (the subscriber) is described in detail
in RFC 6665 section 4.1.2.

If UA2 receive some 4xx response for NOTIFY with a retry-after
header will it retry NOTIFY?

In general, if UA2 (the notifier) receives a 4xx response to a NOTIFY,
it will delete the subscription. The correct behavior is described in
RFC 6665 section 4.2.2, including:

If the NOTIFY transaction fails due to the receipt of a 404, 405,
410, 416, 480-485, 489, 501, or 604 response to the NOTIFY request,
the notifier MUST remove the corresponding subscription. See
[RFC5057] for further details and notes about the effect of error
codes on dialogs and usages within dialog (such as subscriptions).

Dale