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

[Vijay Badola]

Hi,
UAC SHOULD use the same Call-ID header field value for registrations sent to a particular Registrar.
CSeq, from-tag and some other header field value will differ.
Even when UAC will go to refresh its registration SHOULD use same Call-ID header field value.

Regards,
Vijay Badola

From: discussion-bounces at sipforum.org [mailto:discussion-bounces at sipforum.org] On Behalf Of SAKCA, HALIT (HALIT)
Sent: Thursday, March 28, 2013 4:58 PM
To: discussion at sipforum.org
Subject: [SIPForum-discussion] call-id and cseq relation -> rfc 3261 clarification help required

Dear All,

Could you please help me to figure out following scenario and RFC 3261 statement?
A sip call with auth;
1.       Agcf -> INVITE  -> scscf
2.       Agcf <- 407  <- scscf
3.       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



________________________________

DISCLAIMER: The information in this message is confidential and may be legally privileged. It is intended solely for the addressee. Access to this message by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, or distribution of the message, or any action or omission taken by you in reliance on it, is prohibited and may be unlawful. Please immediately contact the sender if you have received this message in error. Further, this e-mail may contain viruses and all reasonable precaution to minimize the risk arising there from is taken by OnMobile. OnMobile is not liable for any damage sustained by you as a result of any virus in this e-mail. All applicable virus checks should be carried out by you before opening this e-mail or any attachment thereto.
Thank you - OnMobile Global Limited.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sipforum.org/pipermail/discussion/attachments/20130403/50a29868/attachment-0002.html>