RE: [Sip] doubt/bug with RFC-3455
"Nataraju A B" <bnataraju@kodiaknetworks.com> Tue, 24 January 2006 04:28 UTC
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1FnL-000289-QS; Mon, 23 Jan 2006 23:28:39 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1FnJ-00026K-Jb for sip@megatron.ietf.org; Mon, 23 Jan 2006 23:28:37 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03527 for <sip@ietf.org>; Mon, 23 Jan 2006 23:27:08 -0500 (EST)
Received: from [203.200.4.5] (helo=serversmb.kodiaknetworks.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1Fwl-00082P-Rz for sip@ietf.org; Mon, 23 Jan 2006 23:38:25 -0500
Received: from Nataraju ([192.168.2.115]) by serversmb.kodiaknetworks.com (8.11.6/8.11.6) with ESMTP id k0O4OtP14995; Tue, 24 Jan 2006 09:54:56 +0530
From: Nataraju A B <bnataraju@kodiaknetworks.com>
To: "'Drage, Keith (Keith)'" <drage@lucent.com>, sip@ietf.org
Subject: RE: [Sip] doubt/bug with RFC-3455
Date: Tue, 24 Jan 2006 09:57:59 +0530
Message-ID: <002701c6209e$8ee2aee0$7302a8c0@Nataraju>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
In-Reply-To: <475FF955A05DD411980D00508B6D5FB00C290769@en0033exch001u.uk.lucent.com>
X-Spam-Score: 2.9 (++)
X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c
Content-Transfer-Encoding: 7bit
Cc:
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
Thanks & Regards, Nataraju A.B. -----Original Message----- From: Drage, Keith (Keith) [mailto:drage@lucent.com] Sent: Monday, January 23, 2006 9:55 PM To: 'Nataraju A B'; 'sip@ietf.org' Subject: RE: [Sip] FW: [Sip-implementors] doubt/bug with RFC-3455 I cannot answer the question, but I can indicate that as far as I understand the issue, 3GPP never needs to send only zero URIs, as this is included in a successful registration only, and therefore at least one address must be registered. The associated list is the list of all registered URIs, both implicit and explicit: Extract from 3GPP TS 24.229 subclause 5.4.1.2.2: "...create a 200 (OK) response for the REGISTER request, including: ... b) a P-Associated-URI header containing the list of the registered public user identity and its associated set of implicitly registered public user identities. The first URI in the list of public user identities supplied by the HSS to the S-CSCF will indicate the default public user identity to be used by the S-CSCF. The public user identity indicated as the default public user identity must be a registered public user identity. The S-CSCF shall place the default public user identity as the first entry in the list of URIs present in the P-Associated-URI header. The default public user identity will be used by the P-CSCF in conjunction with the procedures for the P-Asserted-Identity header, as described in subclause 5.2.6.3. The S-CSCF shall not add a barred public user identity to the list of URIs in the P-Associated-URI header;" I will add this to a number of issues I am in the process of addressing in RFC 3455. [ABN] If the P-Associated-URI carries at least the registered publicURI, then the definition of P-Associated-URI should be changed to carry atleast one URI (registered publicURI) not zero or more URIs ??? Does this make sense... ???? regards Keith > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of > Nataraju A B > Sent: 23 January 2006 11:47 > To: sip@ietf.org > Subject: [Sip] FW: [Sip-implementors] doubt/bug with RFC-3455 > > > Hi All, > > I am posting the same query here in sipping since I did not get any > convincing answers in sip-Implementors list...... > > Thanks & Regards, > Nataraju A.B. > > -----Original Message----- > From: sip-implementors-bounces@cs.columbia.edu > [mailto:sip-implementors-bounces@cs.columbia.edu] On Behalf > Of Nataraju > A B > Sent: Friday, January 20, 2006 11:57 AM > To: sip-implementors@cs.columbia.edu > Subject: [Sip-implementors] doubt/bug with RFC-3455 > > Hi All, > > I have a doubt in the rfc 3455 with respect to > P-Associated-URI syntax, > > Excerpt from RFC-3455 > <<< > 4.1.2 Usage of the P-Associated-URI header > > The registrar inserts the P-Associated-URI header field > into the 200 > OK response to a REGISTER request. The header field value is > populated with a list containing zero or more URIs that are > associated to the address-of-record. > If the registrar supports the P-Associated-URI header > extension, then > the registrar MUST always insert the P-Associated-URI > header field in > all the 200 OK responses to a REGISTER request, regardless > of whether > the REGISTER was an initial registration, re-registration, or > de-registration and regardless of whether there are zero or more > associated URIs. > >>> > > it says if the registrar supports P-Associated-URI, then it has to > insert the P-Asserted-URI in 200 OK response for REGISTER > while defining the ABNF for the same its been mentioned as > > P-Associated-URI = "P-Associated-URI" HCOLON > (p-aso-uri-spec) > *(COMMA p-aso-uri-spec) > p-aso-uri-spec = name-addr *(SEMI ai-param) > ai-param = generic-param > > This ABNF syntax says as one or more, not zero or more number of > p-aso-uri-spec, > > Now my question is? > 1) Why do we need to insert the P-Associated-URI header if > there are no > entry to fill in ? > 2) How do we specify the zero or more P-Associated-URI header > values ? > > Best Regards, > Nataraju A.B. > Kodiak Networks Ind Pvt Ltd > "Change your thoughts, and you change your world." > > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip
- [Sip] FW: [Sip-implementors] doubt/bug with RFC-3… Nataraju A B
- RE: [Sip] FW: [Sip-implementors] doubt/bug with R… Drage, Keith (Keith)
- Re: [Sip] FW: [Sip-implementors] doubt/bug with R… Paul Kyzivat
- RE: [Sip] doubt/bug with RFC-3455 Nataraju A B
- Re: [Sip] FW: [Sip-implementors] doubt/bug with R… Miguel Garcia
- Re: [Sip] FW: [Sip-implementors] doubt/bug with R… Paul Kyzivat