Hi, Dale.

Your explanation is very comprehensible and persuasive to me.
Especially, "preliminary dialog" is an useful concept for all
implementors.

Thank you so much.

Regards,
Shinji

>On Fri, 2010-01-29 at 19:30 +0900, OKUMURA Shinji wrote:
>> Consider the following scenario.
>> 
>>      |      INVITE(CSeq:1)        |
>>      |--------------------------->|
>>      |                            |
>>      |      18x                   |
>>      |<---------------------------|
>>      |                            |
>>      |      PRACK(CSeq:2)         |
>>      |--------------------------->|
>>      |                            |
>>      |      200 OK(PRACK)         |
>>      |<---------------------------|
>>      |                            |
>>      |      415                   |
>>      |<---------------------------|
>>      |                            |
>>      |      ACK                   |
>>      |--------------------------->|
>>      |                            |
>>      |      INVITE(CSeq:2)        |
>>      |--------------------------->|
>>      |      with the same Call-ID |
>>      |                            |
>> 
>> 
>> according to the section 8.1.3.5 in RFC3261, 2nd INVITE
>>   "SHOULD have the same value of the
>>    Call-ID, To, and From of the previous request, but the CSeq should
>>    contain a new sequence number that is one higher than the previous."
>> 
>> therefore, I think the CSeq of 2nd INVITE SHOULD be "2".
>
>To be exact, the CSeq of the 2nd INVITE MUST be 2 or higher, and SHOULD
>be 2.
>
>The analysis is messy, and the rules that are needed to make SIP work
>are not clearly stated in RFC 3261.
>
>The principle is that the initial INVITE is part of a "preliminary
>dialog", that is, the sequence of messages with the given Call-Id and
>from-tag, but no to-tag.  Each early (or established) dialog, that is,
>each sequence of messages with the given Call-Id and from-tag but with a
>specific to-tag, *continues* the preliminary dialog, from the point of
>the INVITE that was responded to, but the early/established dialogs are
>*independent of each other*.  Think of them as branches growing out of
>the trunk of a tree.
>
>This interpretation is the only way that allows the (potentially many)
>UASs to not interfere with each other or with any needed retries of the
>INVITE.
>
>So the 1st and 2nd INVITEs are in the preliminary dialog, and the PRACK
>is in the early dialog created by the 18x response to the 1st INVITE.
>Since the 2nd INVITE and the PRACK are not within the same
>preliminary/early/confirmed dialog, they take their CSeq's from
>different counters.  They both have CSeq 2, because for both of them,
>the preceding request is the 1st INVITE.
>
>Dale
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Reply via email to