Dale,
Its getting a little hypothetical when we are discussing how a UA should
respond after it has already made an error. But ...
Lets assume the problem is that UA1 considers the BYE to terminate the
whole dialog, rather than just a usage. Then the fact that it didn't
send any response to the *first* notify is a bug. It either should have
processed it before the BYE, and so have sent a 200, or else it should
have processed it after the BYE tore down the whole dialog, and so sent
a 481, even before receiving the retransmitted NOTIFYs.
The later NOTIFYs are retransmissions. Assuming UA1 received the first
NOTIFY, it should recognize them as such, and so not treat them as new
transactions with out of order CSeq.
But once we know the UA is broken, it can be broken in many ways. The
main thing is that it needs to be fixed, or else the scope of its
brokenness understood in order to formulate a work-around.
Paul
[EMAIL PROTECTED] wrote:
> <---NOTIFY------
> ------200 OK (BYE)->
> <---BYE---------
>
> ----200 OK BYE->
> <-----NOTIFY------
> <-----NOTIFY------
> <-----NOTIFY------
>
> Even worse, even if UA1 makes the mistake of terminating the entire
> dialog when it sees the BYE, when UA1 receives the resend of NOTIFY,
> it should respond 481. So the fact that UA1 is not responding to the
> NOTIFY is a double-bug.
>
> My mistake there -- The second NOTIFY should receive a 500 (Request
> Out of Order) response, since its CSeq is less than that of the BYE
> that the subscriber just processed. (section 12.2.2, although I think
> there should be a 4xx code for Request Out of Order) The notifier
> should then retry the NOTIFY at the application level (since the 500
> doesn't necessarily mean the subscription has failed), with a CSeq
> higher than that of the BYE. This third NOTIFY (the second retry of
> NOTIFY) should be rejected with a 481.
>
> (And it is scenarios like this which show why "request out of order"
> should be distinguished from generalized failure cases, as there is a
> specific curative action the UAC can take.)
>
> Dale
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
Sip-implementors@cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
