On 4/10/12 10:48 AM, Iñaki Baz Castillo wrote:
> Hi, what should do a UAS that receives an in-dialog request while it
> has not yet replied a final response for a previous in-dialog
> request?:
>
>
> alice bob
> -----------------------------
>
> INVITE --------------->
> <--------------------- 200
> ACK -------------------->
>
>
> IN-DIALOG-1 ------->
> <--------------------- 100
>
> IN-DIALOG-2 ------->
> <------------------ XXX?
This is a complicated subject, with multiple answers.
In general its dangerous for the UAC to do this, because lost/delayed
messages can cause a lot of trouble. (Suppose IN-DIALOG-1 arrives at the
UAS after IN-DIALOG-2? Then it must fail due to wrong CSeq.)
But this can be useful/important in certain cases. The one I have
thought about is NOTIFY. If you have a dialog event package where each
notification sends complete state, then it could be appropriate to send
a notify each time the state changes, even if an outstanding notify
hasn't completed. If the earlier one fails (500) because it arrives
late, that can be ignored by the UAC because the later one will provide
what is needed. But this isn't an appropriate strategy if the
notifications provide only incremental state changes. In that case the
UAC really needs to wait for one to complete before sending another.
A case where this might arise incidentally is if a dialog is being
shared by multiple dialog usages. For instance, consider case where you
have an INVITE dialog usage, and send a REFER within it, resulting in a
refer event subscription sharing the dialog. Differing application
components might be dealing with these asynchronously, so that you might
have notify messages being driven by state changes in the call resulting
from the refer, and independently you might need to do something in the
invite dialog usage (e.g. a reinvite due to session timer.) As long as
the messages all are delivered in order this should work out. But if
they cross it will make a mess.
> Does it depend on the in-dialog request method of IN-DIALOG-1 and
> IN-DIALOG-2? Some cases:
>
>
> 1) IN-DIALOG-1 = INVITE, IN-DIALOG-2 = BYE
>
> Should bob reply 200 to the BYE and later a final response for the INVITE?
IMO this is legal and meaningful. Clearly there must be responses to
both messages. It would be simpler for the UAC if the INVITE got a final
response before the BYE. But I suppose that isn't required.
Note that RFC 5407 addresses this to some extent, showing some obscure
cases.
> 2) IN-DIALOG-1 = INVITE, IN-DIALOG-2 = INVITE
>
> What should reply bob for the second INVITE?
I just responded to another message about this one.
> 3) IN-DIALOG-1 = INVITE, IN-DIALOG-2 = OPTIONS
According to 3261 section 11.2:
An OPTIONS request received within a dialog generates a 200 (OK)
response that is identical to one constructed outside a dialog and
does not have any impact on the dialog.
But I have found that requirement to be un-helpful. It clearly must
affect dialog state in that it changes the last-sent/last-received cseq
value. (And there is some question whether an in-dialog OPTIONS should
get a 481 response if the dialog is not known to the UAS.)
In this context I see no reason not to respond to the OPTIONS in a
normal way.
> 3) IN-DIALOG-1 = INFO, IN-DIALOG-2 = OPTIONS
Same as above - might as well let it go normally.
Thanks,
Paul
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
