[SIPForum-discussion] call-id and cseq relation -> rfc 3261 clarification help required

[Stephen James]

I think the key statement is:


When the originating UAC receives the 401 (Unauthorized), it SHOULD,    if it is 
able, re-originate the request with the proper credentials.

Assuming the word re-originate, means send the INVITE with the same CallId.
Since it says SHOULD you don't have to re-originate, creating a new INVITE.
If you are creating a new INVITE with a different CallId, then the CSeq is 
unrelated to the CSeq of the original INVITE. 

the confusion is probably that re-originate is not a clear term and only used in 
section 22 of RFC 3261

 
Stephen James 
sjames_1958 at yahoo.com
 
We are not princes of the earth, we are the descendants of worms, and any 
nobility must be earned.





________________________________
From: Pritam QA <prachipritam at gmail.com>
To: "SAKCA, HALIT (HALIT)" <halit.sakca at alcatel-lucent.com>
Cc: "discussion at sipforum.org" <discussion at sipforum.org>
Sent: Thu, May 30, 2013 3:18:48 PM
Subject: Re: [SIPForum-discussion] call-id and cseq relation -> rfc 3261 
clarification help required

Hey Halit,

1.       Agcf -> INVITE  -> scscf

2.       Agcf <- 407  <- scscf

3.       Agcf -> INVITE  -> scscf


For above scenario  Call-ID of INVITE  will be same because its in
same dialog but CSeq will be different(increment by 1 number) because
it is RE-INVITE(with Proxy-Authorization header field - authentication
information of the user ) against "407  Proxy Authentication Required"

Thanks,
Prachi Pritam

On Wed, May 29, 2013 at 8:24 AM, Vijay Tiwari <vijay11tiwari at gmail.com> wrote:
>
> Hello Halit
>
> Cseq is incremented by one in this case because we are sending re-invite to the 
>server and this is a new request. whenever we send new request to the server, 
>UAC will increment Cseq number by one.
>
> and when we are re-transmit the request, then Cseq number will be same as 
>previous invite .
>
> This is the only difference between re-invite and re-transmission of the invite 
>request.
>
> Regards
> vijay
>
>
>
> On Thu, Mar 28, 2013 at 4:58 PM, SAKCA, HALIT (HALIT) 
><halit.sakca at alcatel-lucent.com> wrote:
>>
>> Dear All,
>>
>> Could you please help me to figure out following scenario and RFC 3261 
>>statement?
>> A sip call with auth;
>>
>> Agcf -> INVITE  -> scscf
>> Agcf <- 407  <- scscf
>> Agcf -> INVITE  -> scscf
>>
>> .
>> .
>> .
>>
>> The INVITE in 3rd has a different call-id than the INVITE in 1st,
>> I see in RFC that;
>>
>> RFC 3261 clause 22.2 states (at the end of the clause):
>>
>>    When a UAC resubmits a request with its credentials after receiving a
>>    401 (Unauthorized) or 407 (Proxy Authentication Required) response,
>>    it MUST increment the CSeq header field value as it would normally
>>    when sending an updated request.
>>
>> Does ‘Incrementing Cseq’ basically means that the CallID remains the same?
>> I am wondering if it is only in case the UAC RESUBMITS a request.
>> In request above we don't resubmit so we don't have to follow this rule.
>> The UAC is not obliged to resubmit.
>>
>> Am I correct?
>>
>> Regards,
>> Halit
>>
>>
>>
>> _______________________________________________
>> This is the SIP Forum discussion mailing list
>> TO UNSUBSCRIBE, or edit your delivery options, please visit 
>>http://sipforum.org/mailman/listinfo/discussion
>> Post to the list at discussion at sipforum.org
>>
>
>
>
> --
> They can because they think they can.
>
>
> _______________________________________________
> This is the SIP Forum discussion mailing list
> TO UNSUBSCRIBE, or edit your delivery options, please visit 
>http://sipforum.org/mailman/listinfo/discussion
> Post to the list at discussion at sipforum.org
>

_______________________________________________
This is the SIP Forum discussion mailing list
TO UNSUBSCRIBE, or edit your delivery options, please visit 
http://sipforum.org/mailman/listinfo/discussion
Post to the list at discussion at sipforum.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sipforum.org/pipermail/discussion/attachments/20130531/50ec8a01/attachment-0002.html>