[sipcore] RFC5628 - notifier setting up "cseq" attribute

Ivo Sedlacek <ivo.sedlacek@ericsson.com> Tue, 11 October 2011 09:58 UTC

From: Ivo Sedlacek <ivo.sedlacek@ericsson.com>
To: "sipcore@ietf.org" <sipcore@ietf.org>
Date: Tue, 11 Oct 2011 11:58:53 +0200
Thread-Topic: RFC5628 - notifier setting up "cseq" attribute
Thread-Index: AcyH9Hc+Zadzf/2BT0aPWrjiLFykCQAAfbAg
Message-ID: <3A324A65CCACC64289667DFAC0B88E12183EF5E46F@ESESSCMS0360.eemea.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_3A324A65CCACC64289667DFAC0B88E12183EF5E46FESESSCMS0360e_"
MIME-Version: 1.0
Subject: [sipcore] RFC5628 - notifier setting up "cseq" attribute
Precedence: list

Hello,

RFC5628 states in section 5:
-------
   If the notifier includes the <temp-gruu> element, it MUST populate
   the element with the most recently assigned temporary GRUU that is
   associated with the instance ID and AOR of the registered contact.
   >>>It MUST also populate ___the element___ with a "cseq" attribute
   corresponding to the first (oldest) currently active temporary GRUU
   that is associated with the instance ID and AOR of the registered
   contact. The value of the "cseq" attribute is set to the value of
   the CSeq header field of the REGISTER request that caused that first
   temporary GRUU to be assigned. <<<
-------

My question relates to the marked sentences above (between >>> and <<<).

Does ___the element___ in the 1st marked sentence refer to:
A) the <temp-gruu> element (defined in RFC5628); or
B) the <contact> element (defined in RFC3680)?



If A) is the answer, then the marked sentences seem to be incorrect as "cseq" attribute is not defined in the <temp-gruu> element in the XML schema in RFC5628 section 9. Most likely "cseq" attribute should be replaced with "first-cseq" attribute.

If B) is the answer, then RFC5628 seems to contradict RFC3680 since:
- RFC3680 states:
        ----
        The optional
           "callid" attribute contains the current Call-ID carried in the
           REGISTER that was last used to update this contact, and the optional
           "cseq" attribute contains the last CSeq value present in a REGISTER
           request that updated this contact value.
        ---
- the 2nd marked sentence states:
        ----
        The value of the "cseq" attribute is set to the value of
           the CSeq header field of the REGISTER request that caused that first
           temporary GRUU to be assigned.
        ----

Thanks for clarification.

Kind regards

Ivo Sedlacek

Ericsson
Technology and Portfolio Management, Terminal Standardization
Sweden
Office: +46 10 711 9382
Fax: +46 10 713 5929
ivo.sedlacek@ericsson.com
www.ericsson.com

[http://www.ericsson.com/shared/images/Email.gif]


This communication is confidential. We only send and receive email on the basis of the term set out at www.ericsson.com/email_disclaimer<http://www.ericsson.com/email_disclaimer>

[sipcore] RFC5628 - notifier setting up "cseq" at… Ivo Sedlacek
Re: [sipcore] RFC5628 - notifier setting up "cseq… Paul Kyzivat
Re: [sipcore] RFC5628 - notifier setting up "cseq… Paul Kyzivat