In this case I agree with Brett - option 2 is better. There is nothing
about the status of the first invite that prevents the processing of the
second one.
The first failed without ever establishing a dialog. So the reuse of the
callid does not conflict with anything.
Paul
Brett Tate wrote:
>> UAC UAS
>>
>> ---- INVITE (1) ---->
>>
>> <--- 401 (1) -----
>>
>> ---- ACK (1) -X ACK packet lost in transit
>>
>> ---- INVITE (2) ----> (with Auth. credentials)
>>
>> What should the UAS do with INVITE (2) before it
>> receives the ACK for the 1st transaction?
>>
>> I'm assuming that INVITE (2) has incremented the CSeq, but
>> it has the same Call-ID and From tag as the INVITE (1).
>>
>> I've heard two answers:
>>
>>
>>
>> 1) UAS sends 491 to UAC
>>
>> 2) UAS processes INVITE (2)
>>
>>
>>
>> Which one is correct?
>
> Similar race conditions are discussed within
> draft-ietf-sipping-race-examples.
>
> Since Paul and I are currently in disagreement about using 491 Pending
> Request when not actually a pending request, I thought that I'd mention
> the following thread to hopefully spark more discussion about 491 versus
> 500 with Retry-After.
>
> http://www1.ietf.org/mail-archive/web/sipping/current/msg13657.html
>
> Concerning your specific question...
>
> Option 2 is the better solution when the race condition corresponds with
> 401 related ACK.
>
> If you follow rfc3261 and don't retry the 401 response until ACK, you
> definitely should not reject the INVITE.
>
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
