Yong Xin wrote:
> Hi,
>
> The RFC3261 is clear that UA can not send a re-INVITE when another
> INVITE is pending. However, for non-INVITE request (e.g.: INFO), I was
> not able to find any restriction like this. So I assume this is allowed.
>
> However, sending another INFO before the previous one has been answered
> can cause problem when UDP packet is deliveried out-of-order. Here is an
> example:
>
> - INFO (cseq=1) is lost due to network issue
> - INFO (cseq=2) is received and processed by the server
> - retranmission of INFO (cseq=1) arrives at server which replies with
> 500 error, because the cseq number is lower than the last cseq number on
> the dialog
>
> I'm wondering what is the right solution for this:
>
> 1) Should we switch to use TCP as the transport protocol so that the
> order of the packet delivery is guaranteed?
Switching to TCP *won't* guarantee the order of delivery if there are
any intermediate nodes in the path.
> 2) Should UAC send INFO messages in sequence (i.e.: not start a new one
> until previous one is final responded)?
I haven't seen this discussed with respect to INFO, but issues are much
the same as NOTIFY.
Bottom line is that in general you should wait, only sending one at a
time. In certain special cases it may make sense not to wait. Notably if
the new message preempts the prior one, so it doesn't matter if the
prior one gets processed or not.
Thanks,
Paul
> Thanks,
> Yong
>
>
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
