From sip-bounces@ietf.org Tue Nov 01 02:56:17 2005 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 1EWr0D-0006Up-D0; Tue, 01 Nov 2005 02:56:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWr0B-0006US-FC; Tue, 01 Nov 2005 02:56:15 -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 CAA19154; Tue, 1 Nov 2005 02:55:55 -0500 (EST) Received: from gw-eur4.philips.com ([161.85.125.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWrEV-0007Bu-PT; Tue, 01 Nov 2005 03:11:05 -0500 Received: from smtpscan-eur5.philips.com (smtpscan-eur5.mail.philips.com [130.144.57.168]) by gw-eur4.philips.com (Postfix) with ESMTP id 6613F49707; Tue, 1 Nov 2005 07:55:56 +0000 (UTC) Received: from smtpscan-eur5.philips.com (localhost [127.0.0.1]) by localhost.philips.com (Postfix) with ESMTP id B04355DF436; Tue, 1 Nov 2005 07:55:55 +0000 (GMT) Received: from smtprelay-eur2.philips.com (smtprelay-eur2.philips.com [130.144.57.171]) by smtpscan-eur5.philips.com (Postfix) with ESMTP id 7758D162; Tue, 1 Nov 2005 07:55:55 +0000 (GMT) Received: from ehvrmh02.diamond.philips.com (ehvrmh02-srv.diamond.philips.com [130.139.27.125]) by smtprelay-eur2.philips.com (Postfix) with ESMTP id 4C8A4576; Tue, 1 Nov 2005 07:55:55 +0000 (GMT) In-Reply-To: <2FE23D25B7292B489A217D1965CDA866089900@bh-exchange02.saic-abingdon.com> To: "Roy, Radhika (AEAD)" Subject: RE: [Sip] About the ECMA TR/87 (aka SIP CTI Interface) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.3 September 26, 2003 Message-ID: From: Frank Derks Date: Tue, 1 Nov 2005 08:48:53 +0100 X-MIMETrack: Serialize by Router on ehvrmh02/H/SERVER/PHILIPS(Release 6.5.3FP1HF291 | September 19, 2005) at 01/11/2005 08:54:07, Serialize complete at 01/11/2005 08:54:07 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc Cc: SIP , SIPPING , sip-bounces@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi Roy, I agree that this should be strived for, but I fear that reality somewhat restricts this idealism. Take the example of SDP being used to put a media stream on hold. Although this could be defended as being an example of manipulating session parameters, this is rather arguable. The presence framework is yet another example, sending a piece of XML data results in a response of another piece of XML data. As far as I am concernced this is also "protocol tunnelling". Any thoughts? Cheers, Frank "Roy, Radhika (AEAD)" Sent by: sip-bounces@ietf.org 2005-10-31 05:22 PM To Frank Derks/HVS/BE/PHILIPS@PHILIPS "Mariano Stokle" cc SIP sip-bounces@ietf.org SIPPING Subject RE: [Sip] About the ECMA TR/87 (aka SIP CTI Interface) Classification The use of other protocols like SDP and others in SIP must NOT need to be generalized by making a technically "wrong" interpretation such as "carrying of other protocols." Technically write interpretation of using SDP and others in SIP is this: 1. SDP and other protocols "complement" the session initiation in SIP. 2. SIP must NOT be used just another "transport" protocol for carrying other protocols. 3. SIP must NOT be used to carry another protocol suits of "session establishment" protocols that contradict the very fundamentals for which SIP has been created as a standard. If anyone violates the above items, definitely, they are abusing SIP standards, and it must be stopped immediately. Any comments? Best regards, Radhika R. Roy SAIC -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Frank Derks Sent: Monday, October 31, 2005 3:02 AM To: Mariano Stokle Cc: SIP; SIPPING; sip-bounces@ietf.org Subject: Re: [Sip] About the ECMA TR/87 (aka SIP CTI Interface) Hi Mariano, I realise that I am treading on dangerous ground here, but I couldn't resist answering. If you are asking yourself whether SIP is appropriate for carrying another "signalling protocol" is like asking "can I use SIP to do something for me". Most, if not all, SIP implementations rely on the fact that some other protocol is being carried in a SIP body. SDP and the XML used for IM and presence are good examples of this. The SIP methods that could be used to convey these protocols, is obviously open for discussion, but I fear that it will be extremely difficult to come to real consensus on this. In the CSTA case, I would say that, depending on what you are doing, both methods could be appropriate. BTW, Microsoft uses SIP messages with the CSTA XML variant for LCS. 3PCC is not quite as powerful as CSTA. Realise that "CSTA" covers a complete suite of 3rd party call control functionality, whereas 3PCC "just" describes a method by which a few 3rd party call control services could be realised. Precisely because of 3PCC's limitations TR/87 was created. Cheers, Frank Mariano Stokle Sent by: sip-bounces@ietf.org 2005-10-28 12:25 PM To SIP SIPPING cc Subject [Sip] About the ECMA TR/87 (aka SIP CTI Interface) Classification Recently I noticed the implementation of TR/87 spec in several SIP Application Servers. My question (sorry it is out off topic for these lists) is about if it is a right use of SIP according to the architectural design principles of SIP and particulary, the use of INVITE for establish a signalling session. I mean: is SIP the right choice to transport another signalling protocol as CSTA? If yes, it is INVITE the right method to transport CSTA information or SUBSCRIBE-NOTIFY would be a better choice? Finally, do we need CSTA over SIP when we have RFC 4117 for 3PCC? Regards, -- Mariano Stokle _______________________________________________ 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 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 From sip-bounces@ietf.org Tue Nov 01 04:04:09 2005 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 1EWs3s-00017w-Kq; Tue, 01 Nov 2005 04:04:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWs3q-00017o-Hc for sip@megatron.ietf.org; Tue, 01 Nov 2005 04:04:06 -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 EAA22137 for ; Tue, 1 Nov 2005 04:03:46 -0500 (EST) Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWsIB-0005EX-D9 for sip@ietf.org; Tue, 01 Nov 2005 04:18:56 -0500 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0IP900901QDVMT@siemenscomms.co.uk> for sip@ietf.org; Tue, 01 Nov 2005 09:01:07 +0000 (GMT) Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0IP9007BZQDT2Z@siemenscomms.co.uk>; Tue, 01 Nov 2005 09:01:05 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Tue, 01 Nov 2005 09:03:35 +0000 Content-return: allowed Date: Tue, 01 Nov 2005 09:03:34 +0000 From: "Elwell, John" To: Cullen Jennings , Rohan Mahy Message-id: <50B1CBA96870A34799A506B2313F266706D5241B@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: sip@ietf.org Subject: [Sip] Outbound-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1248411528==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1248411528== Content-return: allowed Content-type: multipart/alternative; boundary="Boundary_(ID_m4hHOMQB8eRVB3LgXz+qVA)" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --Boundary_(ID_m4hHOMQB8eRVB3LgXz+qVA) Content-type: text/plain Content-Transfer-Encoding: 7BIT Cullen, Rohan, I had a hard time understanding some of the changes to this draft. I think it needs some more information about the reasons for GRUU and more explanation of the pin-route option tag (not just behavioural requirements, but explanation of what the mechanism is trying to achieve). Note that section 14 provides a hint, but that text will not remain in the RFC. I couldn't figure out the relevance of the first paragraph of 4.1. The section is about forming flows, but initiating dialogs is something that shouldn't happen until after a flow has been formed. The first paragraph of 4.1.1 seems a little convoluted. First it says what to do when sending a request with a Contact header when you don't have a GRUU. Then it says you can't do this for an INVITE-initiated dialog. So why not describe sending a Contact header without a GRUU only in the context of dialogs that are not INVITE-initiated? What is it that makes the mechanism unsuitable for an INVITE-initiated dialog? Section 7 uses the term "SIP device" a few times without defining it. Why does section 9 cover only flow-id, whereas section 10 covers both flow-id and sip-stun? Thanks, John --Boundary_(ID_m4hHOMQB8eRVB3LgXz+qVA) Content-type: text/html Content-Transfer-Encoding: 7BIT Outbound-01

Cullen, Rohan,

I had a hard time understanding some of the changes to this draft. I think it needs some more information about the reasons for GRUU and more explanation of the pin-route option tag (not just behavioural requirements, but explanation of what the mechanism is trying to achieve). Note that section 14 provides a hint, but that text will not remain in the RFC.

I couldn't figure out the relevance of the first paragraph of 4.1. The section is about forming flows, but initiating dialogs is something that shouldn't happen until after a flow has been formed.

The first paragraph of 4.1.1 seems a little convoluted. First it says what to do when sending a request with a Contact header when you don't have a GRUU. Then it says you can't do this for an INVITE-initiated dialog. So why not describe sending a Contact header without a GRUU only in the context of dialogs that are not INVITE-initiated? What is it that makes the mechanism unsuitable for an INVITE-initiated dialog?

Section 7 uses the term "SIP device" a few times without defining it.

Why does section 9 cover only flow-id, whereas section 10 covers both flow-id and sip-stun?

Thanks,

John



--Boundary_(ID_m4hHOMQB8eRVB3LgXz+qVA)-- --===============1248411528== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1248411528==-- From sip-bounces@ietf.org Tue Nov 01 09:50:28 2005 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 1EWxT2-0001Wv-52; Tue, 01 Nov 2005 09:50:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWxSz-0001WC-4L; Tue, 01 Nov 2005 09:50:25 -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 JAA24718; Tue, 1 Nov 2005 09:50:05 -0500 (EST) Received: from mclmx2.mail.saic.com ([149.8.64.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWxhO-0002O4-7L; Tue, 01 Nov 2005 10:05:18 -0500 Received: from 0015-its-ieg01.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx2.mail.saic.com; Tue, 1 Nov 2005 09:50:12 -0500 Received: from mclmx.mail.saic.com ([149.8.64.10]) by 0015-its-ieg01.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2005110109501218415 ; Tue, 01 Nov 2005 09:50:12 -0500 Received: from bh-exchangefe.saic-abingdon.com ([149.8.64.21] [149.8.64.21]) by mclmx.mail.saic.com with ESMTP; Tue, 1 Nov 2005 09:50:12 -0500 Received: from bh-exchange02.saic-abingdon.com ([10.42.81.226]) by bh-exchangefe.saic-abingdon.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Nov 2005 09:54:04 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] About the ECMA TR/87 (aka SIP CTI Interface) Date: Tue, 1 Nov 2005 09:53:48 -0500 Message-Id: <2FE23D25B7292B489A217D1965CDA86608990F@bh-exchange02.saic-abingdon.com> Thread-Topic: [Sip] About the ECMA TR/87 (aka SIP CTI Interface) Thread-Index: AcXeujY71GoUTI43SP2zhWQAoX17mgAOHtsQ From: "Roy, Radhika \(AEAD\)" To: X-OriginalArrivalTime: 01 Nov 2005 14:54:04.0390 (UTC) FILETIME=[1A42D060:01C5DEF4] X-Spam-Score: 0.0 (/) X-Scan-Signature: f884eb1d4ec5a230688d7edc526ea665 Content-Transfer-Encoding: quoted-printable Cc: SIP , SIPPING , sip-bounces@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, Frank: SIP also carries MIME format in its message body. Carrying of SDP results so many things: audio, video, and others streams. Carrying of XML triggers many other activities. There is nothing NEW about it in SIP. But what does SIP standard stand for? The fundamental thing is this: They all MUST complement the fundamental objective of session initiation (especially human user in mind). If anyone wants to extend SIP, let them come in the IETF SIP/SIPPING WG. They are welcome, and standards are developed for the whole world, not some abusiveness of standards as done in private arena. Let them bring contributions in IETF and we can into those, and we will go from there. Hope this helps. BR/Radhika -----Original Message----- From: frank.derks@philips.com [mailto:frank.derks@philips.com]=20 Sent: Tuesday, November 01, 2005 2:49 AM To: Roy, Radhika (AEAD) Cc: Mariano Stokle; SIP; sip-bounces@ietf.org; SIPPING Subject: RE: [Sip] About the ECMA TR/87 (aka SIP CTI Interface) Hi Roy, I agree that this should be strived for, but I fear that reality somewhat=20 restricts this idealism. Take the example of SDP being used to put a media stream on=20 hold.=20 Although this could be defended as being an example of manipulating=20 session parameters, this is rather arguable. The presence framework is yet another example,=20 sending a piece of XML data results in a response of another piece of XML data. As far as I am concernced this is also "protocol tunnelling". Any thoughts? Cheers, Frank "Roy, Radhika (AEAD)" =20 Sent by: sip-bounces@ietf.org 2005-10-31 05:22 PM To Frank Derks/HVS/BE/PHILIPS@PHILIPS "Mariano Stokle" cc SIP sip-bounces@ietf.org SIPPING Subject RE: [Sip] About the ECMA TR/87 (aka SIP CTI Interface) Classification The use of other protocols like SDP and others in SIP must NOT need to be generalized by making a technically "wrong" interpretation such as "carrying of other protocols." Technically write interpretation of using SDP and others in SIP is this: 1. SDP and other protocols "complement" the session initiation in SIP. 2. SIP must NOT be used just another "transport" protocol for carrying other protocols. 3. SIP must NOT be used to carry another protocol suits of "session establishment" protocols that contradict the very fundamentals for which SIP has been created as a standard. If anyone violates the above items, definitely, they are abusing SIP standards, and it must be stopped immediately. Any comments? Best regards, Radhika R. Roy SAIC -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Frank Derks Sent: Monday, October 31, 2005 3:02 AM To: Mariano Stokle Cc: SIP; SIPPING; sip-bounces@ietf.org Subject: Re: [Sip] About the ECMA TR/87 (aka SIP CTI Interface) Hi Mariano, I realise that I am treading on dangerous ground here, but I couldn't=20 resist answering.=20 If you are asking yourself whether SIP is appropriate for carrying another=20 "signalling=20 protocol" is like asking "can I use SIP to do something for me". Most, if=20 not all,=20 SIP implementations rely on the fact that some other protocol is being=20 carried in a SIP body. SDP and the XML used for IM and presence are good examples of this.=20 The SIP methods that could be used to convey these protocols, is obviously open for=20 discussion, but I fear that it will be extremely difficult to come to real consensus on=20 this. In the CSTA case, I would say that, depending on what you are doing, both methods=20 could be appropriate.=20 BTW, Microsoft uses SIP messages with the CSTA XML variant for LCS. 3PCC is not quite as powerful as CSTA. Realise that "CSTA" covers a=20 complete suite of 3rd party call control functionality, whereas 3PCC "just" describes a method by which a few 3rd party call control services could be realised. Precisely because of=20 3PCC's limitations TR/87 was created. Cheers, Frank Mariano Stokle =20 Sent by: sip-bounces@ietf.org 2005-10-28 12:25 PM To SIP SIPPING cc Subject [Sip] About the ECMA TR/87 (aka SIP CTI Interface) Classification Recently I noticed the implementation of TR/87 spec in several SIP Application Servers. My question (sorry it is out off topic for these lists) is about if it is a right use of SIP according to the architectural design principles of SIP and particulary, the use of INVITE for establish a signalling session. I mean: is SIP the right choice to transport another signalling protocol as CSTA? If yes, it is INVITE the right method to transport CSTA information or SUBSCRIBE-NOTIFY would be a better choice? Finally, do we need CSTA over SIP when we have RFC 4117 for 3PCC? Regards, -- Mariano Stokle _______________________________________________ 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 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 From sip-bounces@ietf.org Tue Nov 01 10:44:05 2005 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 1EWyIv-0001nm-Kz; Tue, 01 Nov 2005 10:44:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWyIt-0001nO-8c; Tue, 01 Nov 2005 10:44:03 -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 KAA27711; Tue, 1 Nov 2005 10:43:42 -0500 (EST) Received: from gw-eur4.philips.com ([161.85.125.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWyXG-0007NW-C5; Tue, 01 Nov 2005 10:58:56 -0500 Received: from smtpscan-eur4.philips.com (smtpscan-eur4.mail.philips.com [130.144.57.167]) by gw-eur4.philips.com (Postfix) with ESMTP id 80B1649704; Tue, 1 Nov 2005 15:43:46 +0000 (UTC) Received: from smtpscan-eur4.philips.com (localhost [127.0.0.1]) by localhost.philips.com (Postfix) with ESMTP id 4CBCC5240; Tue, 1 Nov 2005 15:43:46 +0000 (GMT) Received: from smtprelay-eur2.philips.com (smtprelay-eur2.philips.com [130.144.57.171]) by smtpscan-eur4.philips.com (Postfix) with ESMTP id 30F4751EE; Tue, 1 Nov 2005 15:43:46 +0000 (GMT) Received: from ehvrmh02.diamond.philips.com (ehvrmh02-srv.diamond.philips.com [130.139.27.125]) by smtprelay-eur2.philips.com (Postfix) with ESMTP id EA4FE54C; Tue, 1 Nov 2005 15:43:45 +0000 (GMT) In-Reply-To: <2FE23D25B7292B489A217D1965CDA86608990F@bh-exchange02.saic-abingdon.com> To: "Roy, Radhika (AEAD)" Subject: RE: [Sip] About the ECMA TR/87 (aka SIP CTI Interface) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.3 September 26, 2003 Message-ID: From: Frank Derks Date: Tue, 1 Nov 2005 16:41:55 +0100 X-MIMETrack: Serialize by Router on ehvrmh02/H/SERVER/PHILIPS(Release 6.5.3FP1HF291 | September 19, 2005) at 01/11/2005 16:41:58, Serialize complete at 01/11/2005 16:41:58 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: 83e9494d829b08cc3f644ef6ac1b9bd4 Cc: SIP , SIPPING , sip-bounces@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi Roy, You are probably right about the process, but the SIP/SIPPING/SIMPLE workgroups have not always been co-operative in these efforts. Some of the 3GPP efforts demonstrate this. Obviously, that doesn't mean that anybody should then just do their own thing;-) Cheers, Frank "Roy, Radhika (AEAD)" Sent by: RoyR@saic-abingdon.com 2005-11-01 03:53 PM To Frank Derks/HVS/BE/PHILIPS@PHILIPS cc "Mariano Stokle" "SIP" "SIPPING" Subject RE: [Sip] About the ECMA TR/87 (aka SIP CTI Interface) Classification Hi, Frank: SIP also carries MIME format in its message body. Carrying of SDP results so many things: audio, video, and others streams. Carrying of XML triggers many other activities. There is nothing NEW about it in SIP. But what does SIP standard stand for? The fundamental thing is this: They all MUST complement the fundamental objective of session initiation (especially human user in mind). If anyone wants to extend SIP, let them come in the IETF SIP/SIPPING WG. They are welcome, and standards are developed for the whole world, not some abusiveness of standards as done in private arena. Let them bring contributions in IETF and we can into those, and we will go from there. Hope this helps. BR/Radhika -----Original Message----- From: frank.derks@philips.com [mailto:frank.derks@philips.com] Sent: Tuesday, November 01, 2005 2:49 AM To: Roy, Radhika (AEAD) Cc: Mariano Stokle; SIP; sip-bounces@ietf.org; SIPPING Subject: RE: [Sip] About the ECMA TR/87 (aka SIP CTI Interface) Hi Roy, I agree that this should be strived for, but I fear that reality somewhat restricts this idealism. Take the example of SDP being used to put a media stream on hold. Although this could be defended as being an example of manipulating session parameters, this is rather arguable. The presence framework is yet another example, sending a piece of XML data results in a response of another piece of XML data. As far as I am concernced this is also "protocol tunnelling". Any thoughts? Cheers, Frank "Roy, Radhika (AEAD)" Sent by: sip-bounces@ietf.org 2005-10-31 05:22 PM To Frank Derks/HVS/BE/PHILIPS@PHILIPS "Mariano Stokle" cc SIP sip-bounces@ietf.org SIPPING Subject RE: [Sip] About the ECMA TR/87 (aka SIP CTI Interface) Classification The use of other protocols like SDP and others in SIP must NOT need to be generalized by making a technically "wrong" interpretation such as "carrying of other protocols." Technically write interpretation of using SDP and others in SIP is this: 1. SDP and other protocols "complement" the session initiation in SIP. 2. SIP must NOT be used just another "transport" protocol for carrying other protocols. 3. SIP must NOT be used to carry another protocol suits of "session establishment" protocols that contradict the very fundamentals for which SIP has been created as a standard. If anyone violates the above items, definitely, they are abusing SIP standards, and it must be stopped immediately. Any comments? Best regards, Radhika R. Roy SAIC -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Frank Derks Sent: Monday, October 31, 2005 3:02 AM To: Mariano Stokle Cc: SIP; SIPPING; sip-bounces@ietf.org Subject: Re: [Sip] About the ECMA TR/87 (aka SIP CTI Interface) Hi Mariano, I realise that I am treading on dangerous ground here, but I couldn't resist answering. If you are asking yourself whether SIP is appropriate for carrying another "signalling protocol" is like asking "can I use SIP to do something for me". Most, if not all, SIP implementations rely on the fact that some other protocol is being carried in a SIP body. SDP and the XML used for IM and presence are good examples of this. The SIP methods that could be used to convey these protocols, is obviously open for discussion, but I fear that it will be extremely difficult to come to real consensus on this. In the CSTA case, I would say that, depending on what you are doing, both methods could be appropriate. BTW, Microsoft uses SIP messages with the CSTA XML variant for LCS. 3PCC is not quite as powerful as CSTA. Realise that "CSTA" covers a complete suite of 3rd party call control functionality, whereas 3PCC "just" describes a method by which a few 3rd party call control services could be realised. Precisely because of 3PCC's limitations TR/87 was created. Cheers, Frank Mariano Stokle Sent by: sip-bounces@ietf.org 2005-10-28 12:25 PM To SIP SIPPING cc Subject [Sip] About the ECMA TR/87 (aka SIP CTI Interface) Classification Recently I noticed the implementation of TR/87 spec in several SIP Application Servers. My question (sorry it is out off topic for these lists) is about if it is a right use of SIP according to the architectural design principles of SIP and particulary, the use of INVITE for establish a signalling session. I mean: is SIP the right choice to transport another signalling protocol as CSTA? If yes, it is INVITE the right method to transport CSTA information or SUBSCRIBE-NOTIFY would be a better choice? Finally, do we need CSTA over SIP when we have RFC 4117 for 3PCC? Regards, -- Mariano Stokle _______________________________________________ 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 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 From sip-bounces@ietf.org Tue Nov 01 10:53:09 2005 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 1EWyRg-0001dc-Rb; Tue, 01 Nov 2005 10:53:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWyRd-0001Xk-4g; Tue, 01 Nov 2005 10:53:05 -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 KAA28474; Tue, 1 Nov 2005 10:52:44 -0500 (EST) Received: from mclmx.mail.saic.com ([149.8.64.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWyg1-0008MP-B0; Tue, 01 Nov 2005 11:07:59 -0500 Received: from 0015-its-ieg02.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx.mail.saic.com; Tue, 1 Nov 2005 10:52:52 -0500 Received: from mclmx2.mail.saic.com ([149.8.64.32]) by 0015-its-ieg02.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2005110110525202903 ; Tue, 01 Nov 2005 10:52:52 -0500 Received: from bh-exchangefe.saic-abingdon.com ([149.8.64.21] [149.8.64.21]) by mclmx2.mail.saic.com with ESMTP; Tue, 1 Nov 2005 10:52:52 -0500 Received: from bh-exchange02.saic-abingdon.com ([10.42.81.226]) by bh-exchangefe.saic-abingdon.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Nov 2005 10:56:44 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] About the ECMA TR/87 (aka SIP CTI Interface) Date: Tue, 1 Nov 2005 10:56:28 -0500 Message-Id: <2FE23D25B7292B489A217D1965CDA866089914@bh-exchange02.saic-abingdon.com> Thread-Topic: [Sip] About the ECMA TR/87 (aka SIP CTI Interface) Thread-Index: AcXe+5UZQuP8QVTESeSMeDrRkJHlyQAACVSg From: "Roy, Radhika \(AEAD\)" To: X-OriginalArrivalTime: 01 Nov 2005 15:56:44.0453 (UTC) FILETIME=[DB6EE550:01C5DEFC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4515df9441674711565101d9d5c4f63f Content-Transfer-Encoding: quoted-printable Cc: SIP , SIPPING , sip-bounces@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, Frank: It is a simple process as follows: 1. Bring contributions in the IETF 2. Convince people that there is something needs to be done in those areas 3. See which existing WGs fit to meet those requirements for standardization 4. If item 3 is not a fit, ask for BoF for creation of a new WG Unless efforts are made, nothing will happen. I believe that SIP CTI interfaces may be a good area to focus on for standardization because there is a definite market opportunity.=20 Why SIP should not be standardized to explore this new area? It is also better for SIP because this is another "call control" area for real-time communications. Best regards, Radhika -----Original Message----- From: frank.derks@philips.com [mailto:frank.derks@philips.com]=20 Sent: Tuesday, November 01, 2005 10:42 AM To: Roy, Radhika (AEAD) Cc: Mariano Stokle; Roy, Radhika (AEAD); SIP; sip-bounces@ietf.org; SIPPING Subject: RE: [Sip] About the ECMA TR/87 (aka SIP CTI Interface) Hi Roy, You are probably right about the process, but the SIP/SIPPING/SIMPLE=20 workgroups have not always been co-operative in these efforts. Some of the 3GPP=20 efforts demonstrate this. Obviously, that doesn't mean that anybody should then=20 just do=20 their own thing;-) Cheers, Frank "Roy, Radhika (AEAD)" =20 Sent by: RoyR@saic-abingdon.com 2005-11-01 03:53 PM To Frank Derks/HVS/BE/PHILIPS@PHILIPS cc "Mariano Stokle" "SIP" "SIPPING" Subject RE: [Sip] About the ECMA TR/87 (aka SIP CTI Interface) Classification Hi, Frank: SIP also carries MIME format in its message body. Carrying of SDP results so many things: audio, video, and others streams. Carrying of XML triggers many other activities. There is nothing NEW about it in SIP. But what does SIP standard stand for? The fundamental thing is this: They all MUST complement the fundamental objective of session initiation (especially human user in mind). If anyone wants to extend SIP, let them come in the IETF SIP/SIPPING WG. They are welcome, and standards are developed for the whole world, not some abusiveness of standards as done in private arena. Let them bring contributions in IETF and we can into those, and we will go from there. Hope this helps. BR/Radhika -----Original Message----- From: frank.derks@philips.com [mailto:frank.derks@philips.com]=20 Sent: Tuesday, November 01, 2005 2:49 AM To: Roy, Radhika (AEAD) Cc: Mariano Stokle; SIP; sip-bounces@ietf.org; SIPPING Subject: RE: [Sip] About the ECMA TR/87 (aka SIP CTI Interface) Hi Roy, I agree that this should be strived for, but I fear that reality somewhat=20 restricts this idealism. Take the example of SDP being used to put a media stream on=20 hold.=20 Although this could be defended as being an example of manipulating=20 session parameters, this is rather arguable. The presence framework is yet another example,=20 sending a piece of XML data results in a response of another piece of XML data. As far as I am concernced this is also "protocol tunnelling". Any thoughts? Cheers, Frank "Roy, Radhika (AEAD)" =20 Sent by: sip-bounces@ietf.org 2005-10-31 05:22 PM To Frank Derks/HVS/BE/PHILIPS@PHILIPS "Mariano Stokle" cc SIP sip-bounces@ietf.org SIPPING Subject RE: [Sip] About the ECMA TR/87 (aka SIP CTI Interface) Classification The use of other protocols like SDP and others in SIP must NOT need to be generalized by making a technically "wrong" interpretation such as "carrying of other protocols." Technically write interpretation of using SDP and others in SIP is this: 1. SDP and other protocols "complement" the session initiation in SIP. 2. SIP must NOT be used just another "transport" protocol for carrying other protocols. 3. SIP must NOT be used to carry another protocol suits of "session establishment" protocols that contradict the very fundamentals for which SIP has been created as a standard. If anyone violates the above items, definitely, they are abusing SIP standards, and it must be stopped immediately. Any comments? Best regards, Radhika R. Roy SAIC -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Frank Derks Sent: Monday, October 31, 2005 3:02 AM To: Mariano Stokle Cc: SIP; SIPPING; sip-bounces@ietf.org Subject: Re: [Sip] About the ECMA TR/87 (aka SIP CTI Interface) Hi Mariano, I realise that I am treading on dangerous ground here, but I couldn't=20 resist answering.=20 If you are asking yourself whether SIP is appropriate for carrying another=20 "signalling=20 protocol" is like asking "can I use SIP to do something for me". Most, if=20 not all,=20 SIP implementations rely on the fact that some other protocol is being=20 carried in a SIP body. SDP and the XML used for IM and presence are good examples of this.=20 The SIP methods that could be used to convey these protocols, is obviously open for=20 discussion, but I fear that it will be extremely difficult to come to real consensus on=20 this. In the CSTA case, I would say that, depending on what you are doing, both methods=20 could be appropriate.=20 BTW, Microsoft uses SIP messages with the CSTA XML variant for LCS. 3PCC is not quite as powerful as CSTA. Realise that "CSTA" covers a=20 complete suite of 3rd party call control functionality, whereas 3PCC "just" describes a method by which a few 3rd party call control services could be realised. Precisely because of=20 3PCC's limitations TR/87 was created. Cheers, Frank Mariano Stokle =20 Sent by: sip-bounces@ietf.org 2005-10-28 12:25 PM To SIP SIPPING cc Subject [Sip] About the ECMA TR/87 (aka SIP CTI Interface) Classification Recently I noticed the implementation of TR/87 spec in several SIP Application Servers. My question (sorry it is out off topic for these lists) is about if it is a right use of SIP according to the architectural design principles of SIP and particulary, the use of INVITE for establish a signalling session. I mean: is SIP the right choice to transport another signalling protocol as CSTA? If yes, it is INVITE the right method to transport CSTA information or SUBSCRIBE-NOTIFY would be a better choice? Finally, do we need CSTA over SIP when we have RFC 4117 for 3PCC? Regards, -- Mariano Stokle _______________________________________________ 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 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 From sip-bounces@ietf.org Tue Nov 01 11:36:53 2005 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 1EWz81-0003F2-HQ; Tue, 01 Nov 2005 11:36:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWz7z-0003DN-Vj for sip@megatron.ietf.org; Tue, 01 Nov 2005 11:36:52 -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 LAA00624 for ; Tue, 1 Nov 2005 11:36:31 -0500 (EST) Received: from [211.94.36.20] (helo=mail.chinaunicom.com.cn) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWzMM-00043K-7r for sip@ietf.org; Tue, 01 Nov 2005 11:51:46 -0500 Received: from yanbf ([211.94.36.212]) by mail.chinaunicom.com.cn with Microsoft SMTPSVC(5.0.2195.6713); Wed, 2 Nov 2005 00:36:18 +0800 Message-ID: <00e801c5df02$64191060$0416c00a@yanbf> From: "Binfeng Yan" To: Date: Wed, 2 Nov 2005 00:36:20 +0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-RFC2646: Format=Flowed; Original X-OriginalArrivalTime: 01 Nov 2005 16:36:18.0054 (UTC) FILETIME=[6235AA60:01C5DF02] X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Rohan Mahy , Dean Willis Subject: [Sip] I-D ACTION: draft-yan-sip-cave-requirements-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hello, all! Please check the following draft. A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : MMD CAVE Support Requirements Author(s) : B. Yan, et al. Filename : draft-yan-sip-cave-requirements-00.txt Pages : 8 Date : 2005-10-31 This document describes why there is a need to support CAVE authentication in Multi-Media Domain, and outlines the requirements of the potential solution to this problem. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-yan-sip-cave-requirements-00.txt Sorry for late post, since repository has some problem with my draft. After I negotiated with them, it post today. If you have any question, please don't hesitate to let us know it. Best Regards. Yan _______________________________________________ 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 From sip-bounces@ietf.org Tue Nov 01 11:40:59 2005 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 1EWzBz-0005jm-EY; Tue, 01 Nov 2005 11:40:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWzBw-0005ih-JD; Tue, 01 Nov 2005 11:40:56 -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 LAA00878; Tue, 1 Nov 2005 11:40:35 -0500 (EST) Received: from mail.pingtel.com ([65.220.123.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWzQL-0004kv-Jc; Tue, 01 Nov 2005 11:55:50 -0500 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id 108C66C017; Tue, 1 Nov 2005 11:40:50 -0500 (EST) Subject: RE: [Sip] About the ECMA TR/87 (aka SIP CTI Interface) From: "Dale R. Worley" To: Sip , Sipping In-Reply-To: References: Content-Type: text/plain Date: Tue, 01 Nov 2005 11:40:49 -0500 Message-Id: <1130863249.21112.7.camel@cdhcp139.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-6) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Tue, 2005-11-01 at 16:41 +0100, Frank Derks wrote: > You are probably right about the process, but the SIP/SIPPING/SIMPLE workgroups > have not always been co-operative in these efforts. Some of the 3GPP efforts > demonstrate this. Obviously, that doesn't mean that anybody should then just do > their own thing;-) Or maybe we should make explicit what is implicit is Roy's description: One brings a *request* to the IETF -- and the IETF might answer "No", because what one wants to do might be a Bad Idea. The difficulty with the 3GPP efforts is that generally, they have come to the IETF with the tone "This is what we are going to do, and we want you to certify it." Dale _______________________________________________ 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 From sip-bounces@ietf.org Tue Nov 01 11:43:02 2005 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 1EWzDy-0006Vi-I1; Tue, 01 Nov 2005 11:43:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWzDu-0006UE-VZ; Tue, 01 Nov 2005 11:42:59 -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 LAA00965; Tue, 1 Nov 2005 11:42:38 -0500 (EST) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWzSJ-0004tm-VN; Tue, 01 Nov 2005 11:57:53 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id jA1GgkKg000133; Tue, 1 Nov 2005 10:42:47 -0600 (CST) Received: from [135.185.173.147] (il0015vkg1.ih.lucent.com [135.185.173.147]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id jA1Ggj504604; Tue, 1 Nov 2005 10:42:45 -0600 (CST) Message-ID: <43679B05.9040304@lucent.com> Date: Tue, 01 Nov 2005 10:42:45 -0600 From: "Vijay K. Gurbani" Organization: Wireless Networks Research and Development User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF SIP List , SIPPING LIST , Simple WG X-Spam-Score: 0.0 (/) X-Scan-Signature: b045c2b078f76b9f842d469de8a32de3 Cc: Subject: [Sip] Get the aggregate PDF file for all I-Ds in a session X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0594322711==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0594322711== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060202090609010809070108" This is a cryptographically signed message in MIME format. --------------ms060202090609010809070108 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Folks: In preparation for the SIP, SIPPING and SIMPLE WGs in the upcoming Vancouver IETF, I have collated all the I-Ds to be discussed in a session into an aggregate PDF file. You can access the PDF files from: SIP WG I-Ds (2 PDF files, each corresponding to a session) ----------- http://www.iit.edu/~gurbvij/SIPWG-Session-1.pdf http://www.iit.edu/~gurbvij/SIPWG-Session-2.pdf SIPPING WG I-Ds (2 PDF files, each corresponding to a session) --------------- http://www.iit.edu/~gurbvij/SIPPINGWG-Session-1.pdf http://www.iit.edu/~gurbvij/SIPPINGWG-Session-2.pdf SIMPLE WG I-Ds -------------- http://www.iit.edu/~gurbvij/SIMPLEWG-Session.pdf You have 2.17 MBytes of data to read and digest ... but who's counting ... ;-) Enjoy. Thanks, - vijay -- Vijay K. Gurbani, Ph.D. vkg@{lucent.com,research.bell-labs.com,acm.org} Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 --------------ms060202090609010809070108 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIkNjCC CZowggiCoAMCAQICChq5SpYAAAAABscwDQYJKoZIhvcNAQEFBQAwgbIxJTAjBgkqhkiG9w0B CQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5jb20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcg SmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkgSGlsbDEcMBoGA1UEChMTTHVjZW50IFRlY2hub2xv Z2llczEzMDEGA1UEAxMqTHVjZW50IFRlY2hub2xvZ2llcyBDZXJ0aWZpY2F0ZSBTZXJ2aWNl cyAxMB4XDTA0MDYyMzIwMDM0MVoXDTA2MDYyMzIwMTM0MVowQTEdMBsGCSqGSIb3DQEJARYO dmtnQGx1Y2VudC5jb20xIDAeBgNVBAMTF1ZpamF5IEsgR3VyYmFuaSAoVmlqYXkpMIGfMA0G CSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8/1oQRIU0sF4rsiC0F6mQu6TSvQPCRl6BObQcR58a 5swju1dVwTz3XbON9p5qjYRqxm9d+OX7W2Bj68dxlYUTz5yp9KkwH7hNLVTy09E3dwdZM36L +7ICKUK9M6YU64MJAGTg1tTxUIxflKy0SMCPJIldiEp/JrXYb2aVhmW8tQIDAQABo4IGpDCC BqAwHQYDVR0OBBYEFFG9/4w6CpUIC+mXdQWpWuBH+nkbMIH+BgNVHSMEgfYwgfOAFISfQVWc EIhPO03ThDp+IUtPSt/LoYHOpIHLMIHIMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5s dWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxML TXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxHDAaBgNVBAsTE0x1 Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1Y2VudCBUZWNobm9sb2dpZXMgUm9vdCBB dXRob3JpdHmCCmEMFx0AAAAAAAUwEwYKCZImiZPyLGQBAQQFFgN2a2cwFwYKCZImiZPyLGQB LAQJFgczNzA5NDM4MBEGCWCGSAGG+EIBAQQEAwIFoDALBgNVHQ8EBAMCA/gwJwYDVR0lBCAw HgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDBzCCAncGCCsGAQUFBwEBBIICaTCCAmUw gc4GCCsGAQUFBzAChoHBbGRhcDovL2xkYXAtdXNlYXN0LnBvc3QubHVjZW50LmNvbS9jbj1M dWNlbnQlMjBUZWNobm9sb2dpZXMlMjBDZXJ0aWZpY2F0ZSUyMFNlcnZpY2VzJTIwMSxvdT1D ZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NhY2VydGlmaWNhdGU7 YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBwgYIKwYB BQUHMAKGgbVsZGFwOi8vbGRhcC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2ll cyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRo b3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3Rj bGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHMBggrBgEFBQcwAoaBv2xkYXA6Ly9sZGFw LWVtZWEucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRp ZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxv PWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0 aWZpY2F0aW9uQXV0aG9yaXR5MIICigYDVR0fBIICgTCCAn0wgdaggdOggdCGgc1sZGFwOi8v bGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUy MENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3Jp dGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFz ZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHKoIHHoIHEhoHBbGRhcDov L2xkYXAubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBDZXJ0aWZpY2F0 ZSUyMFNlcnZpY2VzJTIwMSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNl bnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xh c3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCB1KCB0aCBzoaBy2xkYXA6Ly9sZGFwLWVtZWEu cG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRl JTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2Vu dC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZT9vYmplY3RjbGFz cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MA0GCSqGSIb3DQEBBQUAA4IBAQBZ1m98/KuOGemr fAEgtDWIiZjKEN3ShsKT3bfKvjw/zSOtL2UpwNab9xqHKdV9rt4O0wzx6By/0JY/hCQrPMAm YCO0Xo14fC8OSzRkRl1kSPn0E+v8vD+dn42a+dBdmN2SD56jg7/EkvifgaCw9n/HMi4vXcOS +RUdxZkPRnYLyh4GiocnBx88IQEzWK9shMLzC7gm3K6V6kggUSchxR703OHNTLb7XKeEDzSX LdXMVHA5N89xTQGyVWk8Mc6fO7icn0LthC81Ig0/M6v12Vmb2+Tdq7aB7ZVgaU95f/eezcHh LgaYlutde9q6s+c8ok8/hI2VBcGMt85Apf5GAktoMIIJmjCCCIKgAwIBAgIKGrlKlgAAAAAG xzANBgkqhkiG9w0BAQUFADCBsjElMCMGCSqGSIb3DQEJARYWY2FAc2VjdXJpdHkubHVjZW50 LmNvbTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC011cnJh eSBIaWxsMRwwGgYDVQQKExNMdWNlbnQgVGVjaG5vbG9naWVzMTMwMQYDVQQDEypMdWNlbnQg VGVjaG5vbG9naWVzIENlcnRpZmljYXRlIFNlcnZpY2VzIDEwHhcNMDQwNjIzMjAwMzQxWhcN MDYwNjIzMjAxMzQxWjBBMR0wGwYJKoZIhvcNAQkBFg52a2dAbHVjZW50LmNvbTEgMB4GA1UE AxMXVmlqYXkgSyBHdXJiYW5pIChWaWpheSkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB ALz/WhBEhTSwXiuyILQXqZC7pNK9A8JGXoE5tBxHnxrmzCO7V1XBPPdds432nmqNhGrGb134 5ftbYGPrx3GVhRPPnKn0qTAfuE0tVPLT0Td3B1kzfov7sgIpQr0zphTrgwkAZODW1PFQjF+U rLRIwI8kiV2ISn8mtdhvZpWGZby1AgMBAAGjggakMIIGoDAdBgNVHQ4EFgQUUb3/jDoKlQgL 6Zd1Bala4Ef6eRswgf4GA1UdIwSB9jCB84AUhJ9BVZwQiE87TdOEOn4hS09K38uhgc6kgcsw gcgxJTAjBgkqhkiG9w0BCQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5jb20xCzAJBgNVBAYTAlVT MRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkgSGlsbDEcMBoGA1UEChMT THVjZW50IFRlY2hub2xvZ2llczEcMBoGA1UECxMTTHVjZW50IFRlY2hub2xvZ2llczErMCkG A1UEAxMiTHVjZW50IFRlY2hub2xvZ2llcyBSb290IEF1dGhvcml0eYIKYQwXHQAAAAAABTAT BgoJkiaJk/IsZAEBBAUWA3ZrZzAXBgoJkiaJk/IsZAEsBAkWBzM3MDk0MzgwEQYJYIZIAYb4 QgEBBAQDAgWgMAsGA1UdDwQEAwID+DAnBgNVHSUEIDAeBggrBgEFBQcDAgYIKwYBBQUHAwQG CCsGAQUFBwMHMIICdwYIKwYBBQUHAQEEggJpMIICZTCBzgYIKwYBBQUHMAKGgcFsZGFwOi8v bGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUy MENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3Jp dGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFz cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHCBggrBgEFBQcwAoaBtWxkYXA6Ly9sZGFwLmx1 Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2 aWNlcyUyMDEsb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9j YWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRo b3JpdHkwgcwGCCsGAQUFBzAChoG/bGRhcDovL2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20v Y249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEs b3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmlj YXRlO2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwggKK BgNVHR8EggKBMIICfTCB1qCB06CB0IaBzWxkYXA6Ly9sZGFwLXVzZWFzdC5wb3N0Lmx1Y2Vu dC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNl cyUyMDEsb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0 aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmlj YXRpb25BdXRob3JpdHkwgcqggceggcSGgcFsZGFwOi8vbGRhcC5sdWNlbnQuY29tL2NuPUx1 Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNl cnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZv Y2F0aW9ubGlzdDtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9y aXR5MIHUoIHRoIHOhoHLbGRhcDovL2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVj ZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEsb3U9Q2Vy dGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9j YXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3Jp dHkwDQYJKoZIhvcNAQEFBQADggEBAFnWb3z8q44Z6at8ASC0NYiJmMoQ3dKGwpPdt8q+PD/N I60vZSnA1pv3Gocp1X2u3g7TDPHoHL/Qlj+EJCs8wCZgI7RejXh8Lw5LNGRGXWRI+fQT6/y8 P52fjZr50F2Y3ZIPnqODv8SS+J+BoLD2f8cyLi9dw5L5FR3FmQ9GdgvKHgaKhycHHzwhATNY r2yEwvMLuCbcrpXqSCBRJyHFHvTc4c1Mtvtcp4QPNJct1cxUcDk3z3FNAbJVaTwxzp87uJyf Qu2ELzUiDT8zq/XZWZvb5N2rtoHtlWBpT3l/957NweEuBpiW61172rqz5zyiTz+EjZUFwYy3 zkCl/kYCS2gwghD2MIIP3qADAgECAgphDBcdAAAAAAAFMA0GCSqGSIb3DQEBBQUAMIHIMSUw IwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEG A1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2Vu dCBUZWNobm9sb2dpZXMxHDAaBgNVBAsTE0x1Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMT Ikx1Y2VudCBUZWNobm9sb2dpZXMgUm9vdCBBdXRob3JpdHkwHhcNMDAxMjA2MTYyNjQ1WhcN MTAxMjA2MTYzNjQ1WjCBsjElMCMGCSqGSIb3DQEJARYWY2FAc2VjdXJpdHkubHVjZW50LmNv bTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC011cnJheSBI aWxsMRwwGgYDVQQKExNMdWNlbnQgVGVjaG5vbG9naWVzMTMwMQYDVQQDEypMdWNlbnQgVGVj aG5vbG9naWVzIENlcnRpZmljYXRlIFNlcnZpY2VzIDEwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCrbIc03eHms6QdVIh5h01zu8+SHMLFNRPuo3EVY8dgvQsy1pM5DSOtjDt+ JXW723615PF8cVgDVUQGE4D9T9k5B2DP3DUhtrsvH3SEKJL6NceqgWDhLzgf0JjhNdid9IHE x5xRWAiONeeLiRcScIZyRgANiokhSaM5VM2tZBctDFWrXkqxRUHvSSlWXMoXh7HYBOfEjhfJ E3BGQTOX0HOFKkCNS3CDh7ZAwNnw4Ntgkf+8bOqAzmX1ToyZbFLn7bZ9rNFg3gcDzyoFD46C ZQsibysVefigRA57WfouqpbgZ8JzIAmXAeaJLSRgutALT5beOyx75TNPdglVhKlHg4MLAgMB AAGjggz0MIIM8DAQBgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUhJ9BVZwQiE87TdOEOn4h S09K38swCwYDVR0PBAQDAgHGMA8GA1UdEwEB/wQFMAMBAf8wggEEBgNVHSMEgfwwgfmAFG/h K1C+quh9NWJpDO7LUuiSAjxdoYHOpIHLMIHIMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0 eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UE BxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxHDAaBgNVBAsT E0x1Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1Y2VudCBUZWNobm9sb2dpZXMgUm9v dCBBdXRob3JpdHmCEFmZihipVMC2QAXNTB3ruM8wggXfBgNVHR8EggXWMIIF0jCBzKCByaCB xoaBw2xkYXA6Ly9sZGFwLXVzZWFzdC5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVj aG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9y aXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jh c2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBzKCByaCBxoaBw2xkYXA6 Ly9sZGFwLXVzd2VzdC5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVz JTIwUm9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1s dWNlbnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0 Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCByaCBxqCBw4aBwGxkYXA6Ly9sZGFwLmV4 dGVybmFsLmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1 dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2Nl cnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlm aWNhdGlvbkF1dGhvcml0eTCBz6CBzKCByYaBxmxkYXA6Ly9sZGFwLXVzY2VudHJhbC5wb3N0 Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0 eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmlj YXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlv bkF1dGhvcml0eTCByqCBx6CBxIaBwWxkYXA6Ly9sZGFwLWVtZWEucG9zdC5sdWNlbnQuY29t L2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlm aWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRp b25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkw gcqggceggcSGgcFsZGFwOi8vbGRhcC1jYWxhLnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQl MjBUZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBB dXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5h cnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHIoIHFoIHChoG/ bGRhcDovL2xkYXAtYXAucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2ll cyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89 bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVj dGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwL6AtoCuGKWh0dHA6Ly93d3cuc2VjdXJp dHkubHVjZW50LmNvbS9jYS9jYTEuY3JsMIIFsgYIKwYBBQUHAQEEggWkMIIFoDCBxAYIKwYB BQUHMAKGgbdsZGFwOi8vbGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUy MFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1 dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVj dGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcQGCCsGAQUFBzAChoG3bGRhcDovL2xk YXAtdXN3ZXN0LnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBS b290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2Vu dC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0 aW9uQXV0aG9yaXR5MIHBBggrBgEFBQcwAoaBtGxkYXA6Ly9sZGFwLmV4dGVybmFsLmx1Y2Vu dC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1D ZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NhY2VydGlmaWNhdGU7 YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBxwYIKwYB BQUHMAKGgbpsZGFwOi8vbGRhcC11c2NlbnRyYWwucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2Vu dCUyMFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUy MEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29i amVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcIGCCsGAQUFBzAChoG1bGRhcDov L2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIw Um9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNl bnQuY29tP2NhY2VydGlmaWNhdGU7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNh dGlvbkF1dGhvcml0eTCBwgYIKwYBBQUHMAKGgbVsZGFwOi8vbGRhcC1jYWxhLnBvc3QubHVj ZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91 PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0 ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHABggr BgEFBQcwAoaBs2xkYXA6Ly9sZGFwLWFwLnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBU ZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRo b3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3Rj bGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MDUGCCsGAQUFBzAChilodHRwOi8vd3d3LnNl Y3VyaXR5Lmx1Y2VudC5jb20vY2EvY2ExLmNydDANBgkqhkiG9w0BAQUFAAOCAQEAObP5Urds B2nOxTrekCTXpBxKF4K0t8Doi/zHhUuupK+Bc5ppNu9dqYeGr1bKNLRbF/hccvzn4xuj3o82 gm7eZee7lssn9e6T/AjmHca+pCG9n5wZNgY6S0AJryUk6/hfyWc/7z1HfFHrkMM2zn9kqm13 h4tgCPG3WS86+WE4PO12sjAi0GYc43CszaxuU0GZoZ3cfapl5AzC8pMLltGyu/DqJLBk/biR Zr61dWmQWajF/dKhwrAtDiGc0PYZykl/Dg1mYD+eadv5qSKUdTuoa8idlief/sWnUUWbGkYb 1QUPqg8/g9UQcvBx+dgrnsf11X6GHq9gI+LKDBNLyWdEvTGCA8kwggPFAgEBMIHBMIGyMSUw IwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEG A1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2Vu dCBUZWNobm9sb2dpZXMxMzAxBgNVBAMTKkx1Y2VudCBUZWNobm9sb2dpZXMgQ2VydGlmaWNh dGUgU2VydmljZXMgMQIKGrlKlgAAAAAGxzAJBgUrDgMCGgUAoIICXTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNTExMDExNjQyNDVaMCMGCSqGSIb3DQEJ BDEWBBQXvDbkmJyJSqfH5dLkBZD8eLUwOzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIB KDCB0gYJKwYBBAGCNxAEMYHEMIHBMIGyMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5s dWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxML TXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxMzAxBgNVBAMTKkx1 Y2VudCBUZWNobm9sb2dpZXMgQ2VydGlmaWNhdGUgU2VydmljZXMgMQIKGrlKlgAAAAAGxzCB 1AYLKoZIhvcNAQkQAgsxgcSggcEwgbIxJTAjBgkqhkiG9w0BCQEWFmNhQHNlY3VyaXR5Lmx1 Y2VudC5jb20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtN dXJyYXkgSGlsbDEcMBoGA1UEChMTTHVjZW50IFRlY2hub2xvZ2llczEzMDEGA1UEAxMqTHVj ZW50IFRlY2hub2xvZ2llcyBDZXJ0aWZpY2F0ZSBTZXJ2aWNlcyAxAgoauUqWAAAAAAbHMA0G CSqGSIb3DQEBAQUABIGALmSIuPqZpiFPTyH07H0hYc4kf9EQM8L3O6sg2aIcdRI3zR2pzxRe TYRjmFcRgActyFcC9ww0orRJ4F88OxVIzfCQakZPU1s3CjuJpnQ6/T46bZyN6MuzFi2M4kkM PnBEv7NzmQhDVSZwl5Z2f/8ehVkGsIEekaz0Fh7hHm5VZnAAAAAAAAA= --------------ms060202090609010809070108-- --===============0594322711== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============0594322711==-- From sip-bounces@ietf.org Tue Nov 01 12:05:34 2005 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 1EWzZm-0000sw-Ot; Tue, 01 Nov 2005 12:05:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWzZk-0000rt-8J for sip@megatron.ietf.org; Tue, 01 Nov 2005 12:05:32 -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 MAA02477 for ; Tue, 1 Nov 2005 12:05:10 -0500 (EST) Received: from [211.94.36.20] (helo=mail.chinaunicom.com.cn) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWzo8-0007bP-Ct for sip@ietf.org; Tue, 01 Nov 2005 12:20:26 -0500 Received: from yanbf ([211.94.36.212]) by mail.chinaunicom.com.cn with Microsoft SMTPSVC(5.0.2195.6713); Wed, 2 Nov 2005 01:05:03 +0800 Message-ID: <013101c5df06$68c00660$0416c00a@yanbf> From: "Binfeng Yan" To: "Dean Willis" , "Rohan Mahy" References: <834B54D356AA8F46B9B233DD88BEAA38BC6982@hcbjdc2> Subject: Re: [Sip] Another Revised agenda for SIP et IETF 64 Date: Wed, 2 Nov 2005 01:05:06 +0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-RFC2646: Format=Flowed; Original X-OriginalArrivalTime: 01 Nov 2005 17:05:03.0851 (UTC) FILETIME=[66DD63B0:01C5DF06] X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dear Dean and Rohan Thanks for your kindly put my request in the list : http://www.softarmor.com/sipwg/meets/ietf64/requests.html and also sorry until today it could be posted to repository after we negotiate with secretriat many times: http://www.ietf.org/internet-drafts/draft-yan-sip-cave-requirements-00.txt I understand that you already announced almost final agenda. But I still expect that this draft could be discussed in this ietf meeting if there are still very small chance. Best wishes to you Sincerely yours Binfeng _______________________________________________ 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 From sip-bounces@ietf.org Tue Nov 01 14:55:25 2005 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 1EX2E9-0006Gx-8N; Tue, 01 Nov 2005 14:55:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EX2E7-0006Gs-UT for sip@megatron.ietf.org; Tue, 01 Nov 2005 14:55:23 -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 OAA10977 for ; Tue, 1 Nov 2005 14:55:04 -0500 (EST) Received: from mail.pingtel.com ([65.220.123.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EX2SY-0000tU-Rq for sip@ietf.org; Tue, 01 Nov 2005 15:10:20 -0500 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id 833BC6C017 for ; Tue, 1 Nov 2005 14:55:15 -0500 (EST) Subject: Re: [Sip] Are we done with draft-ietf-sip-target-dialog-02.txt andready to request publication? From: "Dale R. Worley" To: Sip In-Reply-To: <004201c5dd5c$1de14740$6402a8c0@BEMBUSTER> References: <2A80C18F-61E9-4C31-BDF5-ABC35DE6C32B@softarmor.com> <4362A002.5040807@cisco.com> <004201c5dd5c$1de14740$6402a8c0@BEMBUSTER> Content-Type: text/plain Date: Tue, 01 Nov 2005 14:55:15 -0500 Message-Id: <1130874915.21112.17.camel@cdhcp139.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-6) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Sun, 2005-10-30 at 15:13 +0100, Jeroen van Bemmel wrote: > Interestingly, the remote-cc-02 draft is not using it for authorization > purposes (yet) as seems to be the main intention formulated in the > target-dialog draft. Rather, it states that the Target-Dialog header MUST be > used "to select the appropriate dialog from which to source the request". I > would say that - based on the name of the header - this would be one of the > most obvious usages of the header, but the target-dialog draft does not > really discuss this aspect. I assume that the following is so understood that Jonathan didn't see the need to write it down: The primary purpose of Target-Dialog is to specify the dialog on which the operation implied by the request is to be performed. Target-Dialog also has a somewhat secondary function of providing authorization, based on the fact that Call-Ids are hard to guess. (Somewhat like "capability" based security systems.) This seems to be clear from both of the examples in section 1, and also from the name of the header. It would seem to me to be an editorial improvement if this was mentioned in the introduction somewhere. Dale _______________________________________________ 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 From sip-bounces@ietf.org Tue Nov 01 16:44:28 2005 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 1EX3vg-0000Wz-Nf; Tue, 01 Nov 2005 16:44:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EX3ve-0000Sh-4A for sip@megatron.ietf.org; Tue, 01 Nov 2005 16:44:26 -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 QAA17931 for ; Tue, 1 Nov 2005 16:44:05 -0500 (EST) Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EX4A5-0004fV-Q5 for sip@ietf.org; Tue, 01 Nov 2005 16:59:23 -0500 Received: (qmail 19802 invoked by uid 0); 1 Nov 2005 21:44:13 -0000 Received: from unknown (HELO BEMBUSTER) ([81.59.101.130]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 1 Nov 2005 21:44:13 -0000 Message-ID: <009f01c5df2d$64e32fa0$6402a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "Dale R. Worley" , "Sip" References: <2A80C18F-61E9-4C31-BDF5-ABC35DE6C32B@softarmor.com><4362A002.5040807@cisco.com> <004201c5dd5c$1de14740$6402a8c0@BEMBUSTER> <1130874915.21112.17.camel@cdhcp139.pingtel.com> Subject: Re: [Sip] Are we done with draft-ietf-sip-target-dialog-02.txtandready to request publication? Date: Tue, 1 Nov 2005 22:44:10 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: 1.2 (+) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org And what should be the error response code if this target dialog is not found? My first thought was "481 Target dialog does not exist", but 481 is normally received for either Call-ID or transaction mismatch. A 481 to a REFER (with Target-Dialog) sent within an ongoing dialog would be ambiguous. "403 Forbidden" would not be appropriate if TD is not used for authentication, as in the remote-cc draft. ----- Original Message ----- From: "Dale R. Worley" To: "Sip" Sent: Tuesday, November 01, 2005 8:55 PM Subject: Re: [Sip] Are we done with draft-ietf-sip-target-dialog-02.txtandready to request publication? > On Sun, 2005-10-30 at 15:13 +0100, Jeroen van Bemmel wrote: >> Interestingly, the remote-cc-02 draft is not using it for authorization >> purposes (yet) as seems to be the main intention formulated in the >> target-dialog draft. Rather, it states that the Target-Dialog header MUST >> be >> used "to select the appropriate dialog from which to source the request". >> I >> would say that - based on the name of the header - this would be one of >> the >> most obvious usages of the header, but the target-dialog draft does not >> really discuss this aspect. > > I assume that the following is so understood that Jonathan didn't see > the need to write it down: > > The primary purpose of Target-Dialog is to specify the dialog on which > the operation implied by the request is to be performed. Target-Dialog > also has a somewhat secondary function of providing authorization, based > on the fact that Call-Ids are hard to guess. (Somewhat like > "capability" based security systems.) > > This seems to be clear from both of the examples in section 1, and also > from the name of the header. > > It would seem to me to be an editorial improvement if this was mentioned > in the introduction somewhere. > > Dale > > > > _______________________________________________ > 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 From sip-bounces@ietf.org Tue Nov 01 18:04:10 2005 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 1EX5Ao-0001CV-Ek; Tue, 01 Nov 2005 18:04:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EX5Am-0001Bx-Gu for sip@megatron.ietf.org; Tue, 01 Nov 2005 18:04:08 -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 SAA22553 for ; Tue, 1 Nov 2005 18:03:47 -0500 (EST) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EX5PF-0007uk-0C for sip@ietf.org; Tue, 01 Nov 2005 18:19:06 -0500 Received: from [64.101.149.214] (dhcp-64-101-149-214.cisco.com [64.101.149.214] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id jA1N9JPp001206 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Tue, 1 Nov 2005 17:09:20 -0600 Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: 7bit Message-Id: <7CA967C6-4561-4DEE-9AAC-93140DA7805A@softarmor.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: sip@ietf.org From: Dean Willis Date: Tue, 1 Nov 2005 17:04:07 -0600 X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit Subject: [Sip] Review of draft-jennings-sip-voicemail-uri-04 by Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Cullen has (as agreed by the SIP working group) requested publication of the individual submission draft-jennings-sip-voicemail-uri-04 as an informational-track RFC. I prepared the following brief review to assist the RFC editor. If you see problems, please bring them to our attention. ---- The format of the document appears to be correct, and the idnits tool version 1.82 returned no complaints. The various boilerplate appears to be correct. The draft makes no IPR disclosures, and I am unaware of any related IPR that should be disclosed. The abstract, though brief, seems reasonable. The examples seem to offer reasonable coverage, and are formatted in a manner consistent with "less formal" documents of the SIP working group, In particular, the SIP Content-Length header fields are elided, with commentary to that effect in-place. The ABNF grammar reference given in the document is to RFC 2234. This reference has expired, and should be replaced with a reference to RFC 4234. I believe the very simple syntax described in Section 7 of this draft is consistent with RFC 4234 to at least the extent that existing SIP syntax is so consistent, although I have not applied formal verification tools. The IANA and Security considerations sections of this draft seem reasonable, and are consistent with regular usage in standards-track documents produced by the SIP working group. The document, although intended for informative publication, normatively references RFC 2119. This requires us to consider carefully whether the language of RFC 2119 is being used appropriately. In the one instance wherein the keyword "MUST" is used (towards the end of Section 10.2), the usage is effectively a paraphrase of the content of RFC 3323 and 3325, which are referenced in that section. As the paraphrase is accurate and consistent with the RFC 2119 usage in the referenced documents, I believe this usage of MUST to be reasonable. Section 8 of this draft uses the RFC 2119 keyword "SHOULD" (four instances) in relation to a recommended mapping between SIP and PSTN cause codes. As this is supported through neither normative argumentation nor reference to a normative specification (it is a recommendation, not a requirement) I believe this usage would be better replaced by a lower-case "should". Section 8 also uses the RFC 2119 keywords "SHOULD NOT" and "MAY". These terms are also used in a paraphrase of RFC 3325 and are consistent with that specification, so I believe this usage to be reasonable. I therefore recommend publication of draft-jennings-sip-voicemail- uri-04 as an Informational track document with the following "Instructions to the RFC Editor": Section 8 of the draft uses the RFC 2119 keyword "SHOULD" four times. Please replace all four usages with the lower-case string "should". Please replace the reference to RFC 2234 with a reference to RFC 4234. -- Dean Willis SIP co-chair _______________________________________________ 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 From sip-bounces@ietf.org Tue Nov 01 18:14:32 2005 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 1EX5Kq-0006fb-4T; Tue, 01 Nov 2005 18:14:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EX5Ko-0006f9-1R for sip@megatron.ietf.org; Tue, 01 Nov 2005 18:14:30 -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 SAA23101 for ; Tue, 1 Nov 2005 18:14:09 -0500 (EST) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EX5ZG-0008KK-Kc for sip@ietf.org; Tue, 01 Nov 2005 18:29:27 -0500 Received: from [64.101.149.214] (dhcp-64-101-149-214.cisco.com [64.101.149.214] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id jA1NJSdr001269 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 1 Nov 2005 17:19:29 -0600 In-Reply-To: <013101c5df06$68c00660$0416c00a@yanbf> References: <834B54D356AA8F46B9B233DD88BEAA38BC6982@hcbjdc2> <013101c5df06$68c00660$0416c00a@yanbf> Mime-Version: 1.0 (Apple Message framework v746.2) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <836A9D1A-8874-4E9F-BD1C-CEE2F32CD13F@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Another Revised agenda for SIP et IETF 64 Date: Tue, 1 Nov 2005 17:14:16 -0600 To: Binfeng Yan X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > Thanks for your kindly put my request in the list : > http://www.softarmor.com/sipwg/meets/ietf64/requests.html > > and also sorry until today it could be posted to repository after we > negotiate > with secretriat many times: > http://www.ietf.org/internet-drafts/draft-yan-sip-cave- > requirements-00.txt > > I understand that you already announced almost final agenda. > > But I still expect that this draft could be discussed in this ietf > meeting > if there are still very small chance. The draft draft-yan-sip-cave-requirements-00.txt seems to be raising a requirement for an EAP extension supporting CAVE, much like the existing EAP extension supporting AKA as documented in RFC 3310. One obvious question would be "And why can't you just use conventional digest authentication?" Would the subject be adequately raised by including one slide (you provide the content) during the chair's status report? Or is there a deeper discussion that we need to be having at this time? Thanks, -- Dean _______________________________________________ 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 From sip-bounces@ietf.org Wed Nov 02 05:36:49 2005 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 1EXFz7-0005zD-23; Wed, 02 Nov 2005 05:36:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXFz5-0005z8-3O for sip@megatron.ietf.org; Wed, 02 Nov 2005 05:36:47 -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 FAA25737 for ; Wed, 2 Nov 2005 05:36:26 -0500 (EST) Received: from zproxy.gmail.com ([64.233.162.198]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXGDc-0002Dc-VQ for sip@ietf.org; Wed, 02 Nov 2005 05:51:50 -0500 Received: by zproxy.gmail.com with SMTP id 9so18682nzo for ; Wed, 02 Nov 2005 02:36:43 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=fw09z+n4OJbBdE+F+l9OhQmFCZF0iOiLiKAKITr1gJDqlJ7YcOiDkA8maq5I43HeoYqg/k+UeCAiDYtyjq5i+tlSf9/McIcIJMX9P7Hab//ZItEArbxbuiVGSmSsaDc6qVQqZoXIybWdM4GfpqJLkmRj6ZQA8YJsntoY7ZtCA5Q= Received: by 10.36.84.4 with SMTP id h4mr238308nzb; Wed, 02 Nov 2005 02:36:43 -0800 (PST) Received: by 10.36.46.20 with HTTP; Wed, 2 Nov 2005 02:36:42 -0800 (PST) Message-ID: <8320074d0511020236m2d02bed6vf9a9062c635b9a83@mail.gmail.com> Date: Wed, 2 Nov 2005 16:06:42 +0530 From: Rohan Sen To: "Jain, Rajnish" Subject: Re: [Sip] Any help would be highly appreciated In-Reply-To: <656BE56E7D48F6419054CC1C811149270239FC5C@exch01.corp.xl.com> MIME-Version: 1.0 References: <656BE56E7D48F6419054CC1C811149270239FC5C@exch01.corp.xl.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 6379955759c38e2371a49573a0932fc7 Cc: SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0486674897==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============0486674897== Content-Type: multipart/alternative; boundary="----=_Part_983_20579048.1130927802976" ------=_Part_983_20579048.1130927802976 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Jain, Thank you very much for your reply. There are a few more issues, on which if you could shed some light, it woul= d be of immense help. Issue # 1 ---------------------------------------------------------------------------= --------------------- In rfc3261, Section 10.3 Page 65 'Processing REGISTER Requests', "The registrar checks whether the request contains the Contact header field..." here, what I understood gives the following pseudo-code segment : if (contact header field is present) { if (contact =3D=3D '*') { if ((expires =3D=3D '0') || (additional contact header field is present)) { Send 400 response } else { if (Call-Id !=3D bound-call-id) { Remove binding } else if (Cseq < bound-cseq) { ERROR } else { Remove binding } } } else { /* General processing of contact field and update of binding */ } } else { /* Fetching of binding */ } Please let me know if my understanding is incorrect. Issue # 2 ---------------------------------------------------------------------------= --------------------- In rfc3261, Section 16.12 Page 117 'Summary of Proxy Route Processing' "2. The proxy will inspect the URI in the topmost Route header field value. If it indicates this proxy,..." My understanding of the purpose of route header field is to specify a next proxy server (can be a loose router) for the SIP Message to the proxy server. I am unable to visualize any scenario where the 1st entry of Router field can point to that of the receiving proxy, because at every step it gets removed and the next value becomes the top most value (next poxy for the next proxy server)= . Issue # 3 ---------------------------------------------------------------------------= --------------------- In rfc3261, Section 10.3 Page 62 'Processing REGISTER Requests' "Each REGISTER message MUST be processed independently of any other registration or binding changes." Does this imply that the registrar must not buffer register requests in attempt to answer with 1 OK for several REGISTER messages for the same AOR ? Ex: If a Registrar receives 2 consecutive REGISTER messages with same AOR but different contact fields, then should it send a single 200 containing 2 bindings or 2 distinct OKs fo= r each of the REGISTER messages ? What exactly are the implications if REGISTER requests are not processed independently ? Issue # 4 ---------------------------------------------------------------------------= --------------------- In rfc3261, Section 10.3 Page 63 'Processing REGISTER Requests' "If the address-of-record is not valid for the domain in the Request-URI, the registrar MUST send a 404 (Not Found) response and skip the remaining steps." What will be the response status code when a REGISTRAR responsible for domain abc.def.com receives a REGISTER message with : i. To field set to user1@abc.xyz.com but Request-URI set to abc.def.com ii. To field set to user1@abc.xyz.com and Request-URI set to abc.xyz.com Issue # 5 ---------------------------------------------------------------------------= --------------------------------------------- What will a dialog stateful proxy send back to a caller, from which it has received a BYE request to terminate a dialog which was not established through this proxy ? It would not find any associated dialog for that BYE request. Any help with these issues will be very much appreciated. thanks, Rohan Sen On 10/3/05, Jain, Rajnish wrote: > > When a proxy server encounters a transport error when forwarding should > it send a 500 response upstream ? > > [RJ] I don't think there is clear guidance on this behavior in RFC > 3261/3263. It'll depend on the kind of transport error that the proxy > encounters or perhaps based implementation-specific logic in the proxy. I= f a > TCP socket connection attempt fails, then an attempt to deliver the reque= st > on UDP should be made. If a UDP request comes back w/ ICMP errors then th= at > means bailing out on the call w/ some kind of error response upstream. > > What message should a user agent (or a proxy) send to a registrar to find > out about the eixtsing bindings ? > [RJ] REGISTER itself. Just leave out the Contact/Expires header fields in > that REGISTER. See section 10. of RFC 3261. > > How, when and why should a stateful proxy transition to state less > operation and for that does it need to remain stateless for the rest of t= he > transaction ? > [RJ] Implementation-specific. > > When it says that a proxy may arbitrarily group the target set and then d= o > parallel processing of the > addresses in a single group. Is it right to assume that such grouping can > be done based on q parameter ? > [RJ] The "q" parameter will suggest parallel/sequential forking w/in a > group. > > How can a proxy determine the transport used to connect to the next proxy > downstream ? > [RJ] Configuration. RFC 3263. > > In Selection of a next hop, for a particular request-URI can that be > configured manually by means other than SIP or if using SIP protocol itse= lf, > how can that be done ? > [RJ] SIP is only a signaling protocol not an OAM&P protocol. > > How can a proxy ensure that all proxies which may be traversed by the > request (say INVITE) are loose routers ? > [RJ] It can't. > > An element is supposed to forward the SIP message to be sent directly to > the transport layer in case the transaction layer is no longer available. > When can exactly a transaction be not available ? Can it be that it has > crashed for some reason ? Will there be any manifestation of any behavior= al > change for that element in which the transaction in progress is no more > available ? > [RJ] In case of INVITE-2XX-ACK, the ACK is between User Core and Transpor= t > layer (transaction layer on both UAC and UAS dies upon receipt/sending of > 2XX). See RFC 3261 section 17. > > What exactly is a local outbound proxy ? > [RJ] As an analogy w/ PSTN, this a bit like your local end office or PBX. > The guidance here is that outbound proxy is a place where you send all yo= ur > calls to and receive all your calls from. You can have multiple local > outbound proxies one for each "line" in your UA. > > Any light on these above issues would be highly appreciated. > > > -- > thanks, > Rohan Sen > -- thanks, Rohan Sen ------=_Part_983_20579048.1130927802976 Content-Type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Jain,

Thank you very much for your reply.

There are a few more issues, on which if you could shed some light, it woul= d be
of immense help.

Issue # 1
---------------------------------------------------------------------------= ---------------------
In rfc3261, Section 10.3 Page 65 'Processing REGISTER Requests',

"The registrar checks whether the request contains the Contact
header field..."

here, what I understood gives the following pseudo-code segment :

if (contact header field is present) {
  if (contact =3D=3D '*') {
    if ((expires =3D=3D '0') || (additional contact header f= ield is present)) {
      Send 400 response
    }
    else {
      if (Call-Id !=3D bound-call-id) {
        Remove binding
      }
      else if (Cseq < bound-cseq) {
        ERROR
      }
      else {
        Remove binding
      }
    }
  }
  else {
    /* General processing of contact field and update of bin= ding */
  }
}
else {
  /* Fetching of binding */
}

Please let me know if my understanding is incorrect.

Issue # 2
---------------------------------------------------------------------------= ---------------------
In rfc3261, Section 16.12 Page 117 'Summary of Proxy Route Processing'
"2.  The proxy will inspect the URI in the topmost Route header        field value.  If it indicates thi= s proxy,..."

My understanding of the purpose of route header field is to specify a next = proxy server (can be a loose router)
for the SIP Message to the proxy server. I am unable to visualize any scena= rio where the 1st entry
of Router field can point to that of the receiving proxy, because at every = step it gets removed and the
next value becomes the top most value (next poxy for the next proxy server)= .

Issue # 3
---------------------------------------------------------------------------= ---------------------
In rfc3261, Section 10.3 Page 62 'Processing REGISTER Requests'
"Each REGISTER message MUST be processed independently of any
other registration or binding changes."

Does this imply that the registrar must not buffer register requests in att= empt to answer
with 1 OK for several REGISTER messages for the same AOR ?
Ex: If a Registrar receives 2 consecutive REGISTER messages with same AOR b= ut different contact fields,
       then should it send a single 200 containing 2 bindings or 2 distinct OKs for each of the REGISTER messages ?
What exactly are the implications if REGISTER requests are not processed in= dependently ?

Issue # 4
---------------------------------------------------------------------------= ---------------------
In rfc3261, Section 10.3 Page 63 'Processing REGISTER Requests'
"If the address-of-record is not valid
for the domain in the Request-URI, the registrar MUST send a
404 (Not Found) response and skip the remaining steps."

What will be the response status code when a REGISTRAR responsible for doma= in
abc.def.com receives a REGISTER message<= br> with :
i.    To field set to u= ser1@abc.xyz.com but Request-URI set to = abc.def.com
ii.   To field set to user1@= abc.xyz.com and Request-URI set to abc.x= yz.com

Issue #  5
---------------------------------------------------------------------------= ---------------------------------------------
What will a dialog stateful proxy send back to a caller, from which it has = received a
BYE request to terminate a dialog which was not established through this pr= oxy ?
It would not find any associated dialog for that BYE request.

Any help with these issues will be very much appreciated.

thanks,
Rohan Sen


On 10/3/05, Jain, Rajnish <r= jain@excelswitching.com> wrote:
 
When a proxy server encounters a transport error whe= n forwarding should it=20 send a 500 response upstream ?
 
[RJ]  I=20 don't think there is clear guidance on this behavior in RFC 3261/3263. It'l= l=20 depend on the kind of transport error that the proxy encounters or perhaps = based=20 implementation-specific logic in the proxy. If a TCP socket connection atte= mpt=20 fails, then an attempt to deliver the request on UDP should be made. If a U= DP=20 request comes back w/ ICMP errors then that means bailing out on the call w= /=20 some kind of error response upstream.
What message should a=20 user agent (or a proxy) send to a registrar to find out about the eixtsing= =20 bindings ?
[RJ] REGISTER itself. Just leave out the Contact/Expires header= =20 fields in that REGISTER. See section 10. of RFC 3261.

How,=20 when and why should a stateful proxy transition to state less operation and= for=20 that does it need to remain stateless for the rest of the transaction ?
= [RJ] Im= plementation-specific. 

When it= =20 says that a proxy may arbitrarily group the target set and then do parallel= =20 processing of the
addresses in a single group. Is it right to assume th= at=20 such grouping can be done based on q parameter ?
[RJ] The "q"=20 parameter will suggest parallel/sequential forking w/in a=20 group. 

How can a proxy determi= ne the transport used=20 to connect to the next proxy downstream ? 
[RJ] Configuration. RFC 3263.=

In Selection of a=20 next hop, for a particular request-URI can that be configured manually by m= eans=20 other than SIP or if using SIP protocol itself, how can that be done ?
<= /span>[RJ] SIP= is=20 only a signaling protocol not an OAM&P=20 protocol. 

How can a proxy ensu= re that all proxies=20 which may be traversed by the request (say INVITE) are loose routers ?
<= /span>[RJ] It= =20 can't. 

An element is supposed = to forward the SIP=20 message to be sent directly to the transport layer in case the transaction = layer=20 is no longer available. When can exactly a transaction be not available ? C= an it=20 be that it has crashed for some reason ? Will there be any manifestation of= any=20 behavioral change for that element in which the transaction in progress is = no=20 more available ?
[RJ] In case of INVITE-2XX-ACK, the ACK is between=20 User Core and Transport layer (transaction layer on both UAC and UAS d= ies=20 upon receipt/sending of 2XX). See RFC 3261 section 17.

What=20 exactly is a local outbound proxy ?
[RJ] As an analogy w/ PSTN, this a bit like= =20 your local end office or PBX. The guidance here is that outbound= =20 proxy is a place where you send all your calls to and receive all your= =20 calls from. You can have multiple local outbound proxies one for each "= ;line" in=20 your UA.
 
Any=20 light on these above issues would be highly appreciated.


--=20
thanks,
Rohan Sen



--
thanks,
Rohan Sen ------=_Part_983_20579048.1130927802976-- --===============0486674897== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============0486674897==-- From sip-bounces@ietf.org Wed Nov 02 09:47:16 2005 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 1EXJtU-0002dM-1j; Wed, 02 Nov 2005 09:47:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXJtQ-0002d2-Vo for sip@megatron.ietf.org; Wed, 02 Nov 2005 09:47:13 -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 JAA10078 for ; Wed, 2 Nov 2005 09:46:52 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXK82-0004Wm-LV for sip@ietf.org; Wed, 02 Nov 2005 10:02:19 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 02 Nov 2005 06:47:04 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jA2EkgUc004179; Wed, 2 Nov 2005 06:47:01 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 2 Nov 2005 06:46:48 -0800 Received: from [10.89.20.87] ([10.89.20.87]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 2 Nov 2005 06:46:48 -0800 Message-ID: <4368D156.3080106@cisco.com> Date: Wed, 02 Nov 2005 09:46:46 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Elwell, John" Subject: Re: [Sip] Alert-Info Idea (was Re: Comment on draft-willis-sip-an sweralert-01) References: <50B1CBA96870A34799A506B2313F266706D5158B@ntht201e.siemenscomms.co.uk> In-Reply-To: <50B1CBA96870A34799A506B2313F266706D5158B@ntht201e.siemenscomms.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Nov 2005 14:46:48.0351 (UTC) FILETIME=[40C64AF0:01C5DFBC] X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, MARJOU Xavier RD-MAPS-LAN , leo@cisco.com, Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I remain troubled about the semantics of Supports and Requires. I think they are considerably underspecified. In this case I think the evidence and precedent is in agreement with Dean, but there are exceptions. Exceptions are the bane if implementors, so I would encourage creating no more of them. Paul Elwell, John wrote: > Dean, > > While I accept this would be reasonable behaviour for alert-info case, I > still disagree with your statement that "SIP is actually very clear here -- > accepting the request with a Requires: option tag says only that you > understand the extension, not that you are committing to doing what it says > for this call." > > In section 3 of RFC 3262 it states: "The UAS MUST send any non-100 > provisional response reliably if the initial request contained a Require > header field with the option tag 100rel. If the UAS is unwilling to do so, > it MUST reject the initial request with a 420 (Bad Extension) and include an > Unsupported header field containing the option tag 100rel." So in this > particular case you cannot accept the request but not honour the extension. > > John > > > >>-----Original Message----- >>From: Dean Willis [mailto:dean.willis@softarmor.com] >>Sent: 28 October 2005 22:13 >>To: Elwell, John >>Cc: Paul Kyzivat; sip@ietf.org; MARJOU Xavier RD-MAPS-LAN; >>leo@cisco.com >>Subject: Re: [Sip] Alert-Info Idea (was Re: Comment on >>draft-willis-sip-an sweralert-01) >> >> >>On Oct 28, 2005, at 2:24 AM, Elwell, John wrote: >> >> >>>Dean, >>> >>> >>> >>>>>The question then is: if the OPTION tag is there, should the >>>>>request be rejected if the Alert-Info value isn't >>>>> >>>> >>>>understood, or if >>>> >>>> >>>>>it won't be honored? >>>>> >>>>> >>>> >>>>SIP is actually very clear here -- accepting the request with a >>>>Requires: option tag says only that you understand the >>>>extension, not >>>>that you are committing to doing what it says for this call. >>>> >>> >>>[JRE] This is already broken with 100rel. >>> >> >>Not at all. You could always fail the transaction. There's a >>difference between rejecting a request because you don't >>understand a >>specific extension and rejecting a request because your policy >>disallows acting on that extension for this specific request -- in >>one case you return a "bad extension" response, and in the other a >>"forbidden" with reason text explaining why it was forbidden ("403 I >>ain't doing preconditions with you, sucker!") >> >>It's like the difference between not supporting digest >>authentication, and not allowing a specific user to place a call. >> >> >>I suppose it would be fair to say that it is up to the specific >>extension to say one of: >> >>1) If you accept a request but can't/won't honor the extension, the >>transaction proceeds with a potentially diminished or altered user >>experience. >>2) If you accept a request but can't/wont honor the extension, then >>an error condition results. >> >> >>This is one of the differentiators for P-class extensions: they have >>to be in class 1 above. There are other differentiators, such as >>that P-headers are not allowed to have option tags, and they aren't >>required to be standards-track. >> >> >>Alert-Info definitely falls into class 1. You might receive an Alert- >>Info with the semantic "distinctive ring associated with your >>primary >>line service", but have a user-interface that recognizes that the >>call is from your fiance's phone and instead plays Mendelsohn's >>"Wedding March". This doesn't break the protocol. So the same phone >>might receive an Alert-Info with the semantic "Emergency" and >>instead >>play your configured emergency tone. In both cases your phone >>understands the Alert-Info header and would accept the request even >>with a Require:. >> >> >>-- >>Dean >> > > _______________________________________________ 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 From sip-bounces@ietf.org Wed Nov 02 10:23:43 2005 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 1EXKSl-00010x-B8; Wed, 02 Nov 2005 10:23:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXKSj-00010p-Bf for sip@megatron.ietf.org; Wed, 02 Nov 2005 10:23:41 -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 KAA12532 for ; Wed, 2 Nov 2005 10:23:20 -0500 (EST) Received: from server100.appriver.com ([207.97.227.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXKhE-0006VS-5j for sip@ietf.org; Wed, 02 Nov 2005 10:38:47 -0500 Received: by server100.appriver.com (CommuniGate Pro PIPE 4.3.8) with PIPE id 7042081; Wed, 02 Nov 2005 10:23:18 -0500 Received: from [216.168.161.154] (HELO BUR-SR7-QDL580-1.ivanet.net) by server100.appriver.com (CommuniGate Pro SMTP 4.3.8) with SMTP id 7042054; Wed, 02 Nov 2005 10:23:03 -0500 Received: from server507.ibasis.net ([216.168.160.47]) by BUR-SR7-QDL580-1.ivanet.net (SMSSMTP 4.0.0.59) with SMTP id M2005110210163630884 ; Wed, 02 Nov 2005 10:16:36 -0500 Received: by server507.bur.ibasis.net with Internet Mail Service (5.5.2657.72) id ; Wed, 2 Nov 2005 10:21:21 -0500 Message-ID: <6E9C6C7D27E3714190801A551BE37610C2C5E8@server507.bur.ibasis.net> From: Manpreet Singh To: sip-implementors@cs.columbia.edu, sip@ietf.org Date: Wed, 2 Nov 2005 10:21:21 -0500 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Policy: GLOBAL X-Policy: GLOBAL X-ALLOW: msingh@ibasis.net ALLOWED X-Virus-Scan: V-F0 X-Note: This Email was scanned by AppRiver SecureTide X-Note: Spam Tests Failed: X-Note: User Rule Hits: X-Country-Path: UNITED STATES->UNITED STATES->destination X-Note-Sending-IP: 216.168.161.154 X-Note-Reverse-DNS: BUR-SR7-QDL580-1.ivanet.net X-Note-WHTLIST: msingh@ibasis.net X-Spam-Score: 3.6 (+++) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: Subject: [Sip] SRV Question X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1550728543==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1550728543== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5DFC1.1477B9C0" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C5DFC1.1477B9C0 Content-Type: text/plain Hi I am trying to understand the the way UAC handles a SRV response. If an UAC is trying to reach a user at something.com and does a SRV query for _sip._udp.something.com and the SRV response comes with server1.something.com (higher priority) and server2.something.com ( lower priority),(after the UAC has done the A record lookup) would the INVITE carry the user@something.com as the Request-URI or would the Request-URI would be user@server1.something.com ? Also would the "To" field be affected by any chance? I would assume the To field to be same and Request-URI to change but if someone can confirm the true behaviour and also point me to the right document explaing it, it would be great. Thanks Manpreet ------_=_NextPart_001_01C5DFC1.1477B9C0 Content-Type: text/html
Hi
 
I am trying to understand the the way UAC handles a SRV response.
 
If an UAC is trying to reach a user at something.com and does a SRV query for _sip._udp.something.com and the SRV response comes with server1.something.com (higher priority) and server2.something.com ( lower priority),(after the UAC has done the A record lookup) would the INVITE carry the user@something.com as the Request-URI or would the Request-URI would be user@server1.something.com?
 
Also would the "To" field be affected by any chance? I would assume the To field to be same and Request-URI to change but if someone can confirm the true behaviour and also point me to the right document explaing it, it would be great.
 
Thanks
 
Manpreet
------_=_NextPart_001_01C5DFC1.1477B9C0-- --===============1550728543== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1550728543==-- From sip-bounces@ietf.org Wed Nov 02 10:50:01 2005 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 1EXKsD-0006h5-O7; Wed, 02 Nov 2005 10:50:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXKsA-0006fX-W0 for sip@megatron.ietf.org; Wed, 02 Nov 2005 10:49:59 -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 KAA14416 for ; Wed, 2 Nov 2005 10:49:37 -0500 (EST) Received: from [211.94.36.20] (helo=mail.chinaunicom.com.cn) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXL6l-0007wO-Ey for sip@ietf.org; Wed, 02 Nov 2005 11:05:05 -0500 Received: from yanbf ([211.94.36.206]) by mail.chinaunicom.com.cn with Microsoft SMTPSVC(5.0.2195.6713); Wed, 2 Nov 2005 23:49:15 +0800 Message-ID: <002501c5dfc4$fd2c9a70$0416c00a@yanbf> From: "Binfeng Yan" To: "Dean Willis" References: <834B54D356AA8F46B9B233DD88BEAA38BC6982@hcbjdc2> <013101c5df06$68c00660$0416c00a@yanbf> <836A9D1A-8874-4E9F-BD1C-CEE2F32CD13F@softarmor.com> Subject: Re: [Sip] Another Revised agenda for SIP et IETF 64 Date: Wed, 2 Nov 2005 23:49:20 +0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-RFC2646: Format=Flowed; Response X-OriginalArrivalTime: 02 Nov 2005 15:49:15.0195 (UTC) FILETIME=[FA1150B0:01C5DFC4] X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: sip@ietf.org, Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, Dean > The draft draft-yan-sip-cave-requirements-00.txt seems to be raising a > requirement for an EAP extension supporting CAVE, much like the existing > EAP extension supporting AKA as documented in RFC 3310. RFC 3310 is HTTP digest extension supporting AKA, which is different with EAP extension AKA like IKEv2 EAP-AKA. > One obvious question would be "And why can't you just use conventional > digest authentication?" Since there are tremendous subscribers of CDMA 1x, and they are currently using CAVE, to ask them change SIM card is not easy work. Only China Unicom is the only one CDMA 1x operator around the world using removable SIM card like GSM/GPRS cellular phone. As defined in RFC3329, four authentication mechanisms is supported by SIP: tls, digest, ipsec-ike, ipsec-man. Currently none of them support CAVE authentication. Either to extend one of them supporting CAVE or to define a new CAVE mechanism is essential to solve this problem. > Would the subject be adequately raised by including one slide (you > provide the content) during the chair's status report? Or is there a > deeper discussion that we need to be having at this time? > If possible, to attract more attention, we guess that one slide is not enough for raising this problem. If possible, maybe 5 minutes will be enough. Thanks for your help Best regards, Binfeng _______________________________________________ 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 From sip-bounces@ietf.org Wed Nov 02 12:06:54 2005 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 1EXM4c-0002qH-De; Wed, 02 Nov 2005 12:06:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXM4a-0002n9-5z for sip@megatron.ietf.org; Wed, 02 Nov 2005 12:06:52 -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 MAA21605 for ; Wed, 2 Nov 2005 12:06:30 -0500 (EST) From: Bjorn.Hjelm@alltel.com Received: from scarlitlx023.alltel.com ([198.133.100.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXMJC-0003qv-40 for sip@ietf.org; Wed, 02 Nov 2005 12:21:59 -0500 Received: from scarlitlx024.alltel.com (scarlitlx024.alltel.com [10.33.8.73]) by scarlitlx023.alltel.com (8.12.8/8.12.8) with ESMTP id jA2H6YUW019171; Wed, 2 Nov 2005 11:06:34 -0600 Received: from scarlitnt642.alltel.com (scarlitnt642.alltel.com [10.33.8.30]) by scarlitlx024.alltel.com (8.12.10/8.12.10) with ESMTP id jA2H6Vlq016708; Wed, 2 Nov 2005 11:06:32 -0600 (envelope-from Bjorn.Hjelm@alltel.com) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] I-D ACTION: draft-yan-sip-cave-requirements-00.txt Date: Wed, 2 Nov 2005 11:06:31 -0600 Message-ID: <1270D164D92D2C43A52B99673149BAC93FA174@scarlitnt642.alltel.com> Thread-Topic: [Sip] I-D ACTION: draft-yan-sip-cave-requirements-00.txt Thread-Index: AcXfArsg2yHEqUbKS9uNRukFe1K/PwAyPISA To: , X-Spam-Score: 0.3 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: quoted-printable Cc: rohan@ekabal.com, dean.willis@softarmor.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Yan, Please forgive my ignorance but I guess I'm puzzled why this issue is not addressed within 3GPP2 where it seems to belong. BR, Bjorn -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Binfeng Yan Sent: Tuesday, November 01, 2005 10:36 AM To: sip@ietf.org Cc: Rohan Mahy; Dean Willis Subject: [Sip] I-D ACTION: draft-yan-sip-cave-requirements-00.txt Hello, all! Please check the following draft. A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : MMD CAVE Support Requirements Author(s) : B. Yan, et al. Filename : draft-yan-sip-cave-requirements-00.txt Pages : 8 Date : 2005-10-31 This document describes why there is a need to support CAVE authentication in Multi-Media Domain, and outlines the requirements of the potential solution to this problem. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-yan-sip-cave-requirements-00.t xt Sorry for late post, since repository has some problem with my draft. After I negotiated with them, it post today. If you have any question, please don't hesitate to let us know it. Best Regards. Yan=20 _______________________________________________ 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 ***************************************************************************= *************** The information contained in this message, including attachments, may conta= in=20 privileged or confidential information that is intended to be delivered onl= y to the=20 person identified above. If you are not the intended recipient, or the pers= on=20 responsible for delivering this message to the intended recipient, ALLTEL r= equests=20 that you immediately notify the sender and asks that you do not read the me= ssage or its=20 attachments, and that you delete them without copying or sending them to an= yone else.=20 _______________________________________________ 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 From sip-bounces@ietf.org Wed Nov 02 13:28:39 2005 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 1EXNLi-0003hA-T9; Wed, 02 Nov 2005 13:28:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXNLe-0003ek-Rw for sip@megatron.ietf.org; Wed, 02 Nov 2005 13:28:34 -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 NAA29127 for ; Wed, 2 Nov 2005 13:28:12 -0500 (EST) Received: from mail.pingtel.com ([65.220.123.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXNaH-0000J9-Ec for sip@ietf.org; Wed, 02 Nov 2005 13:43:42 -0500 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id 6962C6C020 for ; Wed, 2 Nov 2005 13:28:28 -0500 (EST) Subject: Re: [Sip] Alert-Info Idea (was Re: Comment on draft-willis-sip-an sweralert-01) From: "Dale R. Worley" To: Sip In-Reply-To: <4368D156.3080106@cisco.com> References: <50B1CBA96870A34799A506B2313F266706D5158B@ntht201e.siemenscomms.co.uk> <4368D156.3080106@cisco.com> Content-Type: text/plain Date: Wed, 02 Nov 2005 13:28:28 -0500 Message-Id: <1130956108.30072.54.camel@cdhcp139.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-6) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Wed, 2005-11-02 at 09:46 -0500, Paul Kyzivat wrote: > I remain troubled about the semantics of Supports and Requires. I think > they are considerably underspecified. In this case I think the evidence > and precedent is in agreement with Dean, but there are exceptions. > Exceptions are the bane if implementors, so I would encourage creating > no more of them. Perhaps I have not thought enough about this problem, but Supported and Requires seem to be fairly simple to me -- Supported is used by a UA to advertise that it conforms to ("supports" or "understands" in the vernacular) the particular RFC that defines the listed option-tags. Exactly what that conformance requires the UA to do in various cases is defined by the RFC, of course. Its presence in a request does not place any constraint on the UAS that responds. Requires is used in a request to modify the behavior of a UAS. If the UAS does not conform to the RFC in question, it MUST reject the request with 420. And so if it does not reject the request with 420, it MUST perform whatever additional processing is required by the RFC. Within this framework, what a UAC should do depends on its intentions as to what should happen if the UAC does not understand the extension. If the UAC prefers the UAS to ignore the extension syntax elements (in the default manner) so as to "complete the operation with diminished user experience", it omits a Requires header. If the UAC prefers that instead the UAS reject the request, it includes a Requires header. (These are, I think, Dean's two cases. E.g., since all P-headers are to be processed in the first manner, there is no option-tag for any of them.) So far, this doesn't seem to be controversial, and I think that all this is specified or implied in one place or another. If a UAS doesn't want to perform an extension when interacting with some particular UAC, what should it do? Ideally, the extension defines what to do in this case. Or it could reject the request based on authorization; as far as I know, 403 is always allowed. I suppose if the request has a Requires, it can pretend it doesn't understand the extension and return 420, but that is less useful (as 403 is closer to reality), and semantically contradicts any mention of the extension in other Supported headers. Similarly, if the request doesn't have a Requires, the UAS can pretend to not understand the extension and ignore the use of the extension (though again contradicting any Supported that it may have sent). As an example, I see that in sections 20.4 and 20.9 of RFC 3261, a UA is permitted to ignore the potentially hazardous headers Alert-Info and Call-Info based on external factors. Similarly, if there are aspects of an extension that a UA might want to selectively allow or forbit, I'd expect the RFC to make clear how a UA should deal with extension requests that it does not want to honor for specific reasons. Dale _______________________________________________ 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 From sip-bounces@ietf.org Wed Nov 02 14:37:50 2005 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 1EXOQf-0007oU-V1; Wed, 02 Nov 2005 14:37:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXOQZ-0007l6-H4 for sip@megatron.ietf.org; Wed, 02 Nov 2005 14:37:47 -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 OAA03512 for ; Wed, 2 Nov 2005 14:37:21 -0500 (EST) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXOfC-00037p-PC for sip@ietf.org; Wed, 02 Nov 2005 14:52:52 -0500 Received: from [192.168.2.101] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id jA2JgarE005777 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 2 Nov 2005 13:42:38 -0600 In-Reply-To: <002501c5dfc4$fd2c9a70$0416c00a@yanbf> References: <834B54D356AA8F46B9B233DD88BEAA38BC6982@hcbjdc2> <013101c5df06$68c00660$0416c00a@yanbf> <836A9D1A-8874-4E9F-BD1C-CEE2F32CD13F@softarmor.com> <002501c5dfc4$fd2c9a70$0416c00a@yanbf> Mime-Version: 1.0 (Apple Message framework v746.2) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4181D9CD-D94C-4934-8A04-0F7FD00EFFF6@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Another Revised agenda for SIP et IETF 64 Date: Wed, 2 Nov 2005 13:37:25 -0600 To: Binfeng Yan X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Nov 2, 2005, at 9:49 AM, Binfeng Yan wrote: > > As defined in RFC3329, four authentication mechanisms is supported by > SIP: tls, digest, ipsec-ike, ipsec-man. Currently none of them support > CAVE authentication. To be honest, I'm not at all sure that a direct extension to support CAVE would withstand an IETF security review, although I'm sure that our security advisors could say more on that. Those guys seem to be deeply paranoid. If there is a retrofit needed to secure CAVE to the level that IETF would endorse, I would think that would be in-scope for 3GPP2, not IETF. The CDMA operators I know doing SIP appear to have successfully deployed using digest (which, while it has certain security limitations, is essentially well-understood and is already specified by IETF). Why doesn't this approach work in the general CDMA case? I think you could perhaps use CAVE-secured OTA provisioning to push digest credentials easily to the phone, and thereby eliminate another IETF dependency. -- Dean _______________________________________________ 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 From sip-bounces@ietf.org Wed Nov 02 15:29:10 2005 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 1EXPEM-0006Ye-Ol; Wed, 02 Nov 2005 15:29:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXPEK-0006YS-Tp for sip@megatron.ietf.org; Wed, 02 Nov 2005 15:29:09 -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 PAA06577 for ; Wed, 2 Nov 2005 15:28:46 -0500 (EST) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXPSy-0005S7-9Y for sip@ietf.org; Wed, 02 Nov 2005 15:44:17 -0500 Received: from [192.168.2.101] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id jA2KYJfP005971 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 2 Nov 2005 14:34:20 -0600 In-Reply-To: <1130956108.30072.54.camel@cdhcp139.pingtel.com> References: <50B1CBA96870A34799A506B2313F266706D5158B@ntht201e.siemenscomms.co.uk> <4368D156.3080106@cisco.com> <1130956108.30072.54.camel@cdhcp139.pingtel.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Alert-Info Idea (was Re: Comment on draft-willis-sip-an sweralert-01) Date: Wed, 2 Nov 2005 14:29:06 -0600 To: "Dale R. Worley" X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 2.0 (++) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Cc: Sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Nov 2, 2005, at 12:28 PM, Dale R. Worley wrote: > > If a UAS doesn't want to perform an extension when interacting with > some > particular UAC, what should it do? Ideally, the extension defines > what > to do in this case. Or it could reject the request based on > authorization; as far as I know, 403 is always allowed. I suppose if > the request has a Requires, it can pretend it doesn't understand the > extension and return 420, but that is less useful (as 403 is closer to > reality), and semantically contradicts any mention of the extension in > other Supported headers. Similarly, if the request doesn't have a > Requires, the UAS can pretend to not understand the extension and > ignore > the use of the extension (though again contradicting any Supported > that > it may have sent). > > As an example, I see that in sections 20.4 and 20.9 of RFC 3261, a > UA is > permitted to ignore the potentially hazardous headers Alert-Info and > Call-Info based on external factors. Similarly, if there are > aspects of > an extension that a UA might want to selectively allow or forbit, I'd > expect the RFC to make clear how a UA should deal with extension > requests that it does not want to honor for specific reasons. > Yes, I believe this is exactly consistent with what I was trying to say. It's up to the extension to describe what should be done if you support an extension listed in a Require: header field but don't want (for whatever reason) to apply that extension to the specific request. Otherwise said, what to do in this case is determined by the extension, not by the Require mechanism of RFC 3261. We have existing extensions that make different choices here already, and that seems to work ok. But it would, I think, be useful to have a broader understanding of this concept so that the developers of new extensions can clearly document this decision in there new extensions. I wonder if it's worth trying to tack something onto draft-ietf-sip- guidelines-09.txt? -- Dean _______________________________________________ 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 From sip-bounces@ietf.org Wed Nov 02 17:00:28 2005 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 1EXQei-0002Dd-OW; Wed, 02 Nov 2005 17:00:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXQeg-0002B6-8Q for sip@megatron.ietf.org; Wed, 02 Nov 2005 17:00:26 -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 RAA10507 for ; Wed, 2 Nov 2005 17:00:05 -0500 (EST) Message-Id: <200511022200.RAA10507@ietf.org> Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXQtK-0000em-UF for sip@ietf.org; Wed, 02 Nov 2005 17:15:36 -0500 Received: from localhost ([127.0.0.1] helo=psg.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EXQec-000KaF-Bj; Wed, 02 Nov 2005 22:00:22 +0000 To: "Binfeng Yan" Subject: Re: [Sip] Another Revised agenda for SIP et IETF 64 Date: Wed, 02 Nov 2005 14:00:22 -0800 From: Allison Mankin X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: sip@ietf.org, Rohan Mahy , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, I think this is a reasonable place for the Area Director to speak a little more. There's definitely a precedent for making room for existing types of SIM in the IETF-structured security designs. But why is this an issue for the SIP working group, once SIP has come up with a basic security design that has IETF-structured security in it? In my view, the Security Area needs to review your requirements and then your specification. I would recommend that the document become an AD-sponsored individual submission, the same way that Digest-AKA was. I would be happy to ask Russ Housley to adopt this work, and ask SIP for advice to the extent any SIP issues come up. Just reading a little, there have been enough attacks on CAVE, that though it's widely used, the tradeoff for the specification will be to make sure it states clearly what the risks are, and it's this stuff especially that makes it a non-SIP Informational with a SEC AD sponsor. Allison Transport AD for 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 From sip-bounces@ietf.org Wed Nov 02 23:23:54 2005 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 1EXWdm-0005vO-8r; Wed, 02 Nov 2005 23:23:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXWdk-0005tA-3T for sip@megatron.ietf.org; Wed, 02 Nov 2005 23:23:52 -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 XAA29891 for ; Wed, 2 Nov 2005 23:23:30 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXWsR-00013Z-Tq for sip@ietf.org; Wed, 02 Nov 2005 23:39:05 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 02 Nov 2005 20:23:41 -0800 X-IronPort-AV: i="3.97,284,1125903600"; d="scan'208"; a="360160912:sNHT26396896" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jA34NdTH026024; Wed, 2 Nov 2005 20:23:39 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 2 Nov 2005 20:23:38 -0800 Received: from [10.89.16.198] ([10.89.16.198]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 2 Nov 2005 20:23:37 -0800 Message-ID: <436990C6.9040002@cisco.com> Date: Wed, 02 Nov 2005 23:23:34 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Dale R. Worley" References: <50B1CBA96870A34799A506B2313F266706D5158B@ntht201e.siemenscomms.co.uk> <4368D156.3080106@cisco.com> <1130956108.30072.54.camel@cdhcp139.pingtel.com> In-Reply-To: <1130956108.30072.54.camel@cdhcp139.pingtel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Nov 2005 04:23:38.0492 (UTC) FILETIME=[5D1853C0:01C5E02E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7bit Cc: Sip Subject: [Sip] Whats wrong with Supported. (was: Alert-Info Idea) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Response at end is really a new subject, hence a new subject line. Paul Dale R. Worley wrote: > On Wed, 2005-11-02 at 09:46 -0500, Paul Kyzivat wrote: > >>I remain troubled about the semantics of Supports and Requires. I think >>they are considerably underspecified. In this case I think the evidence >>and precedent is in agreement with Dean, but there are exceptions. >>Exceptions are the bane if implementors, so I would encourage creating >>no more of them. > > > Perhaps I have not thought enough about this problem, but Supported and > Requires seem to be fairly simple to me -- > > Supported is used by a UA to advertise that it conforms to ("supports" > or "understands" in the vernacular) the particular RFC that defines the > listed option-tags. Exactly what that conformance requires the UA to do > in various cases is defined by the RFC, of course. Its presence in a > request does not place any constraint on the UAS that responds. > > Requires is used in a request to modify the behavior of a UAS. If the > UAS does not conform to the RFC in question, it MUST reject the request > with 420. And so if it does not reject the request with 420, it MUST > perform whatever additional processing is required by the RFC. One issue is the one that has been discussed in this thread: do Supports and Requires just negotiate the *availability* of an option, or do they also, in one way or another, imply the *use* of an option. For example, the GRUU spec calls for a UA that has obtained a gruu and is inserting it as a contact in some request to insert a Supported: gruu. Recipients of such a request are expected to interpret this as meaning that the contact in the request has the gruu property. So in that case the presence of the Supported header is being construed to mean that the sender *used* the option in a particular way. My other problem with Supported, Required, Accept, Accept-Language, ... is that there is no clear definition of the scope over which this declaration applies. Some possible interpretations are: 1) just this message 2) this transaction 3) until the time of some action that the recipient is expected to take as a result of this message 4) for the remainder of this dialog 5) for the remainder of this dialog unless overridden later in the dialog 6) for all messages with this UA 7) for all messages with this UA unless overridden later OPTIONS requests are supposed to specify these things. That seems to imply to imply the scope must be 6 or 7. But even if that is true, how would the recipient know uniquely when it is talking to the same UA? Without that it can't know when its prior knowledge applies. Which scope is correct affects when a UA needs to insert this information into a request. If a UA doesn't include all info in every request is is making an implicit assumption that the recipient will retain this information until the UA sends it again. You can't get this right unless both parties agree on what this scope is. AFAIK this has never been made clear. I'm pretty sure if we took a poll we would not see any concensus. (Maybe we ought to take that poll. IMO the only answers that make any sense are 3 & 5.) Paul _______________________________________________ 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 From sip-bounces@ietf.org Thu Nov 03 00:25:24 2005 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 1EXXP5-0000Gm-GE; Thu, 03 Nov 2005 00:12:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXXP3-0000GK-6I for sip@megatron.ietf.org; Thu, 03 Nov 2005 00:12:45 -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 AAA05169 for ; Thu, 3 Nov 2005 00:12:23 -0500 (EST) Received: from mail.pingtel.com ([65.220.123.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXXdm-0004PQ-HP for sip@ietf.org; Thu, 03 Nov 2005 00:27:58 -0500 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id 215A56C01C for ; Thu, 3 Nov 2005 00:12:36 -0500 (EST) From: "Dale R. Worley" To: Sip In-Reply-To: <436990C6.9040002@cisco.com> References: <50B1CBA96870A34799A506B2313F266706D5158B@ntht201e.siemenscomms.co.uk> <4368D156.3080106@cisco.com> <1130956108.30072.54.camel@cdhcp139.pingtel.com> <436990C6.9040002@cisco.com> Content-Type: text/plain Date: Thu, 03 Nov 2005 00:12:35 -0500 Message-Id: <1130994755.2569.30.camel@cdhcp139.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-6) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Subject: [Sip] Re: Whats wrong with Supported. (was: Alert-Info Idea) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Wed, 2005-11-02 at 23:23 -0500, Paul Kyzivat wrote: > One issue is the one that has been discussed in this thread: do Supports > and Requires just negotiate the *availability* of an option, or do they > also, in one way or another, imply the *use* of an option. > > For example, the GRUU spec calls for a UA that has obtained a gruu and > is inserting it as a contact in some request to insert a Supported: > gruu. Recipients of such a request are expected to interpret this as > meaning that the contact in the request has the gruu property. So in > that case the presence of the Supported header is being construed to > mean that the sender *used* the option in a particular way. Hmmm... I was going to reiterate my philosophy that Supported indicates conformance to an RFC, rather than a specific feature of a message. That would be boring, but I think it might be an entry-point to the core of the problem. Using Supported/Required only in regard to the UA-wide property of whether it conforms to an RFC is straightforward, and it dodges the issue of the scope over with the declaration applies -- it applies to *all* messages, though of course, whether it implies anything about any one particular message depends on the RFC. >From this point of view, using "Supported: gruu" to indicate that the Contact is a GRUU is fundamentally broken, as the UA either supports GRUUs or not, regardless of whether it has obtained a GRUU that is usable for this transaction. I would then suggest that GRUU Contacts should be indicated by a field-parameter of "gruu" or some such. "Supported: gruu" is just the signal that the UA won't apply the gruu field-parameter without it meaning "This Contact is a GRUU". (I seem to recall somebody suggested this a while back.) > My other problem with Supported, Required, Accept, Accept-Language, ... > is that there is no clear definition of the scope over which this > declaration applies. Some possible interpretations are: So I would argue that if an extension could be applied to only part of a UA's traffic, there would need to be a specifically defined facility in the RFC to enable it. > AFAIK this has never been made clear. I'm pretty sure if we took a poll > we would not see any concensus. (Maybe we ought to take that poll. IMO > the only answers that make any sense are 3 & 5.) It sounds like it would be useful to take that poll, if only to make it clear how confused we are on the subject. Dale _______________________________________________ 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 From sip-bounces@ietf.org Thu Nov 03 01:14:00 2005 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 1EXYMJ-0005ap-LH; Thu, 03 Nov 2005 01:13:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXYMH-0005Xs-HU for sip@megatron.ietf.org; Thu, 03 Nov 2005 01:13:57 -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 BAA09014 for ; Thu, 3 Nov 2005 01:13:35 -0500 (EST) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXYb0-0007iF-8L for sip@ietf.org; Thu, 03 Nov 2005 01:29:11 -0500 Received: from [192.168.2.101] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id jA36J8mk007522 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 3 Nov 2005 00:19:10 -0600 In-Reply-To: <1130994755.2569.30.camel@cdhcp139.pingtel.com> References: <50B1CBA96870A34799A506B2313F266706D5158B@ntht201e.siemenscomms.co.uk> <4368D156.3080106@cisco.com> <1130956108.30072.54.camel@cdhcp139.pingtel.com> <436990C6.9040002@cisco.com> <1130994755.2569.30.camel@cdhcp139.pingtel.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Date: Thu, 3 Nov 2005 00:13:52 -0600 To: "Dale R. Worley" X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit Cc: Sip Subject: [Sip] GRUU (was Whats wrong with Supported. (was: Alert-Info Idea) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Nov 2, 2005, at 11:12 PM, Dale R. Worley wrote: > On Wed, 2005-11-02 at 23:23 -0500, Paul Kyzivat wrote: >> One issue is the one that has been discussed in this thread: do >> Supports >> and Requires just negotiate the *availability* of an option, or do >> they >> also, in one way or another, imply the *use* of an option. >> >> For example, the GRUU spec calls for a UA that has obtained a gruu >> and >> is inserting it as a contact in some request to insert a Supported: >> gruu. Recipients of such a request are expected to interpret this as >> meaning that the contact in the request has the gruu property. So in >> that case the presence of the Supported header is being construed to >> mean that the sender *used* the option in a particular way. > . . . > > Using Supported/Required only in regard to the UA-wide property of > whether it conforms to an RFC is straightforward, and it dodges the > issue of the scope over with the declaration applies -- it applies to > *all* messages, though of course, whether it implies anything about > any > one particular message depends on the RFC. > >> From this point of view, using "Supported: gruu" to indicate that the > Contact is a GRUU is fundamentally broken, as the UA either supports > GRUUs or not, regardless of whether it has obtained a GRUU that is > usable for this transaction. I would then suggest that GRUU Contacts > should be indicated by a field-parameter of "gruu" or some such. > "Supported: gruu" is just the signal that the UA won't apply the gruu > field-parameter without it meaning "This Contact is a GRUU". (I > seem to > recall somebody suggested this a while back.) Ok, having looked at the GRUU draft again, I'd like to consider this a WGLC comment on GRUU, which I shall paraphrase as "What do you mean, Supported:?" One could make the argument that a UA that supports GRUU would never, for any reason, populate the Contact in a transaction other than REGISTER (or the 200 OK thereto) with something that is not a GRUU, and that one can therefore assume that the presence of Supported: gruu in a message outside a REGISTER transaction means that the contact is a GRUU. But if one were to make that argument, one would need to spell this out clearly. One might also make the argument that the user of a contact need (outside a REGISTER transaction) never know whether that contact is a GRUU. Rather, if it works, it works. So the Supported: gruu means nothing outside a REGISTER or OPTIONS transaction, and very little in an OPTIONS transaction. Or perhaps one might argue that I've built a castle of fallacious logic around the use of SIP option tags, and they really mean "If I put this option tag here, I'm either doing or requiring you do exactly what that option tag means". This then raises the possibility that policy might say we "do" an option for correspondent A but not for correspondent B, which means the "option tag constancy" characteristic of RFC 3261 is incorrectly worded (and I believe I argued for this model during 3261, but that was a while back). -- Dean _______________________________________________ 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 From sip-bounces@ietf.org Thu Nov 03 10:32:55 2005 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 1EXh5D-00074G-1Q; Thu, 03 Nov 2005 10:32:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXh5B-00074B-59 for sip@megatron.ietf.org; Thu, 03 Nov 2005 10:32:53 -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 KAA06752 for ; Thu, 3 Nov 2005 10:32:27 -0500 (EST) Received: from ip-10-194-65-202.rev.dyxnet.com ([202.65.194.10] helo=hitachi.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EXhJv-0006h5-DB for sip@ietf.org; Thu, 03 Nov 2005 10:48:09 -0500 Received: (qmail 15499 invoked from network); 3 Nov 2005 15:32:18 -0000 X-NetworkBox-HamSign: 0101;OUT;hitachihk1;290a985d037bbd35328aa2c64cd5f21e; Received: from unknown (HELO hitachihk5.hitachi.cn) (170.95.94.1)by ip-11-194-65-202.rev.dyxnet.com with SMTP; 3 Nov 2005 15:32:18 -0000 Received: (qmail 4374 invoked from network); 3 Nov 2005 15:32:18 -0000 X-NetworkBox-HamSign: 0101;OUT;hitachihk5;c9e8bb6603de2bd68ec9255e09898c74; Received: from hchidc204.hitachi-china.com (HELO hchidc204.hitachi.cn) (170.95.82.6)by 172.16.10.9 with SMTP; 3 Nov 2005 15:32:18 -0000 Received: from hcbjdc2.hitachi.cn ([170.95.81.2]) by hchidc204.hitachi.cn with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Nov 2005 23:32:18 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] I-D ACTION: draft-yan-sip-cave-requirements-00.txt Date: Thu, 3 Nov 2005 23:32:16 +0800 Message-ID: <834B54D356AA8F46B9B233DD88BEAA38BC698B@hcbjdc2> Thread-Topic: [Sip] I-D ACTION: draft-yan-sip-cave-requirements-00.txt Thread-Index: AcXfArsg2yHEqUbKS9uNRukFe1K/PwAyPISAAC/xhvM= From: "DENG, HUI -HCHBJ" To: , , X-OriginalArrivalTime: 03 Nov 2005 15:32:18.0339 (UTC) FILETIME=[C6632730:01C5E08B] X-Scanned-By-hitachihk5: Virus scan performed by network-box X-Scanned-By-hitachihk5: Scanner file id is hitachihk5-1131031938.579-4371-000 X-Scanned-By-hitachihk5: No known viruses found in message (received+scanned in 0.02/0.05 secs) X-Scanned-By-hitachihk5: Spam-Check-Result: No, hits=0 required=7 tests= autolearn=no version=2.0 X-Spam-Status: No X-Scanned-By-hitachihk1: Virus scan performed by network-box X-Scanned-By-hitachihk1: Scanner file id is hitachihk1-1131031938.874-15494-000 X-Scanned-By-hitachihk1: No known viruses found in message (received+scanned in 0.01/0.01 secs) X-Scanned-By-hitachihk1: Spam-Check-Result: No, hits=0 required=7 tests= autolearn=no version=2.0 X-Scanned-By-hitachihk1: Whitelisted with valid signature (outbound via Network Box hitachihk5) X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: rohan@ekabal.com, dean.willis@softarmor.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1815839253==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============1815839253== Content-class: urn:content-classes:message Content-Type: text/plain;charset="UTF-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 Qmpvcm4NCiANCldlIGd1ZXNzIHRoYXQgaWYgdGhlcmUgYXJlIHNvbWUgc29sdXRpb24gY29tZSBm cm9tIElFVEYsIA0KdGhlbiBJUFIgaXNzdWUgY291bGQgYmUgbGVzcyB0aGFuIDNHUFAyIGZvciBt b2JpbGUgb3BlcmF0b3IuDQogDQpUaGFua3MNCiANCi1IdWkNCg0KCS0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tIA0KCUZyb206IEJqb3JuLkhqZWxtQGFsbHRlbC5jb20gW21haWx0bzpCam9ybi5I amVsbUBhbGx0ZWwuY29tXSANCglTZW50OiAyMDA1LTExLTMgKOaYn+acn+WbmykgMTowNiANCglU bzogeWFuYmZAY2hpbmF1bmljb20uY29tLmNuOyBzaXBAaWV0Zi5vcmcgDQoJQ2M6IHJvaGFuQGVr YWJhbC5jb207IGRlYW4ud2lsbGlzQHNvZnRhcm1vci5jb20gDQoJU3ViamVjdDogUkU6IFtTaXBd IEktRCBBQ1RJT046IGRyYWZ0LXlhbi1zaXAtY2F2ZS1yZXF1aXJlbWVudHMtMDAudHh0DQoJDQoJ DQoNCglZYW4sIA0KCVBsZWFzZSBmb3JnaXZlIG15IGlnbm9yYW5jZSBidXQgSSBndWVzcyBJJ20g cHV6emxlZCB3aHkgdGhpcyBpc3N1ZSBpcyANCglub3QgYWRkcmVzc2VkIHdpdGhpbiAzR1BQMiB3 aGVyZSBpdCBzZWVtcyB0byBiZWxvbmcuIA0KDQoJQlIsIA0KCUJqb3JuIA0KDQoJLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0gDQoJRnJvbTogc2lwLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpz aXAtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIA0KCUJpbmZlbmcgWWFuIA0KCVNlbnQ6 IFR1ZXNkYXksIE5vdmVtYmVyIDAxLCAyMDA1IDEwOjM2IEFNIA0KCVRvOiBzaXBAaWV0Zi5vcmcg DQoJQ2M6IFJvaGFuIE1haHk7IERlYW4gV2lsbGlzIA0KCVN1YmplY3Q6IFtTaXBdIEktRCBBQ1RJ T046IGRyYWZ0LXlhbi1zaXAtY2F2ZS1yZXF1aXJlbWVudHMtMDAudHh0IA0KDQoJSGVsbG8sIGFs bCEgDQoJUGxlYXNlIGNoZWNrIHRoZSBmb2xsb3dpbmcgZHJhZnQuIA0KDQoJQSBOZXcgSW50ZXJu ZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIA0K CWRpcmVjdG9yaWVzLiANCgkgVGl0bGUgIDogTU1EIENBVkUgU3VwcG9ydCBSZXF1aXJlbWVudHMg DQoJIEF1dGhvcihzKSA6IEIuIFlhbiwgZXQgYWwuIA0KCSBGaWxlbmFtZSA6IGRyYWZ0LXlhbi1z aXAtY2F2ZS1yZXF1aXJlbWVudHMtMDAudHh0IA0KCSBQYWdlcyAgOiA4IA0KCSBEYXRlICA6IDIw MDUtMTAtMzEgDQoJICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgd2h5IHRoZXJlIGlzIGEgbmVl ZCB0byBzdXBwb3J0IENBVkUgDQoJICAgYXV0aGVudGljYXRpb24gaW4gTXVsdGktTWVkaWEgRG9t YWluLCBhbmQgb3V0bGluZXMgdGhlIHJlcXVpcmVtZW50cyANCgkgICBvZiB0aGUgcG90ZW50aWFs IHNvbHV0aW9uIHRvIHRoaXMgcHJvYmxlbS4gDQoJQSBVUkwgZm9yIHRoaXMgSW50ZXJuZXQtRHJh ZnQgaXM6IA0KCWh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXlhbi1z aXAtY2F2ZS1yZXF1aXJlbWVudHMtMDAudCANCgl4dCANCg0KCVNvcnJ5IGZvciBsYXRlIHBvc3Qs IHNpbmNlIHJlcG9zaXRvcnkgaGFzIHNvbWUgcHJvYmxlbSB3aXRoIG15IGRyYWZ0LiANCglBZnRl ciBJIG5lZ290aWF0ZWQgd2l0aCB0aGVtLCBpdCBwb3N0IHRvZGF5LiANCg0KCUlmIHlvdSBoYXZl IGFueSBxdWVzdGlvbiwgcGxlYXNlIGRvbid0IGhlc2l0YXRlIHRvIGxldCB1cyBrbm93IGl0LiAN Cg0KDQoJQmVzdCBSZWdhcmRzLiANCg0KCVlhbiANCg0KDQoNCglfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXyANCglTaXAgbWFpbGluZyBsaXN0ICBodHRwczov L3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXAgDQoJVGhpcyBsaXN0IGlzIGZvciBO RVcgZGV2ZWxvcG1lbnQgb2YgdGhlIGNvcmUgU0lQIFByb3RvY29sIFVzZSANCglzaXAtaW1wbGVt ZW50b3JzQGNzLmNvbHVtYmlhLmVkdSBmb3IgcXVlc3Rpb25zIG9uIGN1cnJlbnQgc2lwIFVzZSAN CglzaXBwaW5nQGlldGYub3JnIGZvciBuZXcgZGV2ZWxvcG1lbnRzIG9uIHRoZSBhcHBsaWNhdGlv biBvZiBzaXAgDQoNCgkqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKiogDQoJVGhlIGlu Zm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1lc3NhZ2UsIGluY2x1ZGluZyBhdHRhY2htZW50 cywgbWF5IGNvbnRhaW4gDQoJcHJpdmlsZWdlZCBvciBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24g dGhhdCBpcyBpbnRlbmRlZCB0byBiZSBkZWxpdmVyZWQgb25seSB0byB0aGUgDQoJcGVyc29uIGlk ZW50aWZpZWQgYWJvdmUuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIG9y IHRoZSBwZXJzb24gDQoJcmVzcG9uc2libGUgZm9yIGRlbGl2ZXJpbmcgdGhpcyBtZXNzYWdlIHRv IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIEFMTFRFTCByZXF1ZXN0cyANCgl0aGF0IHlvdSBpbW1l ZGlhdGVseSBub3RpZnkgdGhlIHNlbmRlciBhbmQgYXNrcyB0aGF0IHlvdSBkbyBub3QgcmVhZCB0 aGUgbWVzc2FnZSBvciBpdHMgDQoJYXR0YWNobWVudHMsIGFuZCB0aGF0IHlvdSBkZWxldGUgdGhl bSB3aXRob3V0IGNvcHlpbmcgb3Igc2VuZGluZyB0aGVtIHRvIGFueW9uZSBlbHNlLiANCg0KDQoJ X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gDQoJU2lwIG1h aWxpbmcgbGlzdCAgaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwIA0K CVRoaXMgbGlzdCBpcyBmb3IgTkVXIGRldmVsb3BtZW50IG9mIHRoZSBjb3JlIFNJUCBQcm90b2Nv bCANCglVc2Ugc2lwLWltcGxlbWVudG9yc0Bjcy5jb2x1bWJpYS5lZHUgZm9yIHF1ZXN0aW9ucyBv biBjdXJyZW50IHNpcCANCglVc2Ugc2lwcGluZ0BpZXRmLm9yZyBmb3IgbmV3IGRldmVsb3BtZW50 cyBvbiB0aGUgYXBwbGljYXRpb24gb2Ygc2lwIA0KDQo= Disclaimer: The contents of this e-mail, and its attachments, if any, are confidential and may be protected by law against any unauthorized use. If you have received this e-mail by mistake or have reason to believe that you are not the intended recipient, please notify the sender by reply e-mail as soon as possible and delete it from your computer system immediately thereafter. If you are not the intended recipient, you must not copy this e-mail or attachment or disclose the contents to any other person. While we have made every effort to keep our network virus free, we take no responsibility for any computer virus which might be transferred by way of this e-mail. --===============1815839253== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1815839253==-- From sip-bounces@ietf.org Thu Nov 03 10:36:56 2005 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 1EXh96-0007cv-RG; Thu, 03 Nov 2005 10:36:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXh94-0007cP-Vr for sip@megatron.ietf.org; Thu, 03 Nov 2005 10:36:55 -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 KAA06977 for ; Thu, 3 Nov 2005 10:36:31 -0500 (EST) Received: from ip-10-194-65-202.rev.dyxnet.com ([202.65.194.10] helo=hitachi.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EXhNs-0006vQ-BF for sip@ietf.org; Thu, 03 Nov 2005 10:52:14 -0500 Received: (qmail 16884 invoked from network); 3 Nov 2005 15:36:43 -0000 X-NetworkBox-HamSign: 0101;OUT;hitachihk1;d37a675b8c1c18cf427237c9c8fff7e8; Received: from unknown (HELO hitachihk5.hitachi.cn) (170.95.94.1)by ip-11-194-65-202.rev.dyxnet.com with SMTP; 3 Nov 2005 15:36:43 -0000 Received: (qmail 5436 invoked from network); 3 Nov 2005 15:36:42 -0000 X-NetworkBox-HamSign: 0101;OUT;hitachihk5;9e82e16f2c78f734b5a0b31d2c974eaa; Received: from hchidc204.hitachi-china.com (HELO hchidc204.hitachi.cn) (170.95.82.6)by 172.16.10.9 with SMTP; 3 Nov 2005 15:36:42 -0000 Received: from hcbjdc2.hitachi.cn ([170.95.81.2]) by hchidc204.hitachi.cn with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Nov 2005 23:36:42 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] Another Revised agenda for SIP et IETF 64 Date: Thu, 3 Nov 2005 23:36:40 +0800 Message-ID: <834B54D356AA8F46B9B233DD88BEAA38BC698C@hcbjdc2> Thread-Topic: [Sip] Another Revised agenda for SIP et IETF 64 Thread-Index: AcXf5OHdt2UUOXEmTXWYHVjHdmW01AApue+v From: "DENG, HUI -HCHBJ" To: "Dean Willis" , "Binfeng Yan" X-OriginalArrivalTime: 03 Nov 2005 15:36:42.0589 (UTC) FILETIME=[63E480D0:01C5E08C] X-Scanned-By-hitachihk5: Virus scan performed by network-box X-Scanned-By-hitachihk5: Scanner file id is hitachihk5-1131032202.767-5433-000 X-Scanned-By-hitachihk5: No known viruses found in message (received+scanned in 0.02/0.05 secs) X-Scanned-By-hitachihk5: Spam-Check-Result: No, hits=0 required=7 tests= autolearn=no version=2.0 X-Spam-Status: No X-Scanned-By-hitachihk1: Virus scan performed by network-box X-Scanned-By-hitachihk1: Scanner file id is hitachihk1-1131032203.83-16870-000 X-Scanned-By-hitachihk1: No known viruses found in message (received+scanned in 0.02/0.02 secs) X-Scanned-By-hitachihk1: Spam-Check-Result: No, hits=0 required=7 tests= autolearn=no version=2.0 X-Scanned-By-hitachihk1: Whitelisted with valid signature (outbound via Network Box hitachihk5) X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: sip@ietf.org, Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1111044637==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============1111044637== Content-class: urn:content-classes:message Content-Type: text/plain;charset="UTF-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 PiBBcyBkZWZpbmVkIGluIFJGQzMzMjksIGZvdXIgYXV0aGVudGljYXRpb24gbWVjaGFuaXNtcyBp cyBzdXBwb3J0ZWQgYnkgDQo+IFNJUDogdGxzLCBkaWdlc3QsIGlwc2VjLWlrZSwgaXBzZWMtbWFu LiBDdXJyZW50bHkgbm9uZSBvZiB0aGVtIHN1cHBvcnQgDQo+IENBVkUgYXV0aGVudGljYXRpb24u IA0KDQoJVG8gYmUgaG9uZXN0LCBJJ20gbm90IGF0IGFsbCBzdXJlIHRoYXQgYSBkaXJlY3QgZXh0 ZW5zaW9uIHRvIHN1cHBvcnQgIA0KCUNBVkUgd291bGQgd2l0aHN0YW5kIGFuIElFVEYgc2VjdXJp dHkgcmV2aWV3LCBhbHRob3VnaCBJJ20gc3VyZSB0aGF0ICANCglvdXIgc2VjdXJpdHkgYWR2aXNv cnMgY291bGQgc2F5IG1vcmUgb24gdGhhdC4gVGhvc2UgZ3V5cyBzZWVtIHRvIGJlICANCglkZWVw bHkgcGFyYW5vaWQuICBJZiB0aGVyZSBpcyBhIHJldHJvZml0IG5lZWRlZCB0byBzZWN1cmUgQ0FW RSB0byB0aGUgIA0KCWxldmVsIHRoYXQgSUVURiB3b3VsZCBlbmRvcnNlLCBJIHdvdWxkIHRoaW5r IHRoYXQgd291bGQgYmUgaW4tc2NvcGUgIA0KCWZvciAzR1BQMiwgbm90IElFVEYuIA0KDQoJPT0+ IFVuZGVyc3RhbmQgeW91ciBjb25jZXJuIGhlcmUsIG9uZSBpbnRlbnRpb24gY291bGQgYmUNCg0K CXRoZXJlIGFyZSBsZXNzIElQUiBpc3N1ZSBpbiBJRVRGIHRoYW4gM0dQUDIuDQoNCgkgDQoNCglU aGUgQ0RNQSBvcGVyYXRvcnMgSSBrbm93IGRvaW5nIFNJUCBhcHBlYXIgdG8gaGF2ZSBzdWNjZXNz ZnVsbHkgIA0KCWRlcGxveWVkIHVzaW5nIGRpZ2VzdCAod2hpY2gsIHdoaWxlIGl0IGhhcyBjZXJ0 YWluIHNlY3VyaXR5ICANCglsaW1pdGF0aW9ucywgaXMgZXNzZW50aWFsbHkgd2VsbC11bmRlcnN0 b29kIGFuZCBpcyBhbHJlYWR5IHNwZWNpZmllZCAgDQoJYnkgSUVURikuIFdoeSBkb2Vzbid0IHRo aXMgYXBwcm9hY2ggd29yayBpbiB0aGUgZ2VuZXJhbCBDRE1BIGNhc2U/IEkgIA0KCXRoaW5rIHlv dSBjb3VsZCBwZXJoYXBzIHVzZSBDQVZFLXNlY3VyZWQgT1RBIHByb3Zpc2lvbmluZyB0byBwdXNo ICANCglkaWdlc3QgY3JlZGVudGlhbHMgZWFzaWx5IHRvIHRoZSBwaG9uZSwgYW5kIHRoZXJlYnkg ZWxpbWluYXRlIGFub3RoZXIgIA0KCUlFVEYgZGVwZW5kZW5jeS4gDQoNCgk9PT4gSSBiZWNvbWUg dW5kZXJzdGFuZCB3aGF0IHlvdSBzYWlkIHllc3RlcmRheSBhYm91dCBjb252ZW50aW9uYWwgZGln ZXN0IA0KDQoJc29sdXRpb24sIEkgZmVlbCB3aGF0IHlvdSBwcm9wb3NlZCBzb2x1dGlvbiBoZXJl IGlzIHByZXR0eSBzbWFydCwgYWZ0ZXIgZ2V0IENBVkUNCg0KCWdlbmVyYXRlZCBrZXksIGl0IGNv dWxkIGJlIGRpcmVjdGx5IHVzZWQgZm9yIEhUVFAgZGlnZXN0IHNvbHV0aW9uLCBhbnl3YXksDQoN CglpdCBzdGlsbCBuZWVkIG1vcmUgaW52ZXN0aWdhdGlvbiBhYm91dCBpbnRlcm9wYXJ0aW9uIHRl c3QgY29uc2lkZXJhdGlvbiBldCBhbC4NCg0KCSANCg0KCS1IdWkNCg0K Disclaimer: The contents of this e-mail, and its attachments, if any, are confidential and may be protected by law against any unauthorized use. If you have received this e-mail by mistake or have reason to believe that you are not the intended recipient, please notify the sender by reply e-mail as soon as possible and delete it from your computer system immediately thereafter. If you are not the intended recipient, you must not copy this e-mail or attachment or disclose the contents to any other person. While we have made every effort to keep our network virus free, we take no responsibility for any computer virus which might be transferred by way of this e-mail. --===============1111044637== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1111044637==-- From sip-bounces@ietf.org Thu Nov 03 10:43:03 2005 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 1EXhF1-0000sn-Ja; Thu, 03 Nov 2005 10:43:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXhF0-0000sd-1Q for sip@megatron.ietf.org; Thu, 03 Nov 2005 10:43:02 -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 KAA07560 for ; Thu, 3 Nov 2005 10:42:38 -0500 (EST) Received: from ip-10-194-65-202.rev.dyxnet.com ([202.65.194.10] helo=hitachi.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EXhTo-0007OB-Er for sip@ietf.org; Thu, 03 Nov 2005 10:58:21 -0500 Received: (qmail 18768 invoked from network); 3 Nov 2005 15:42:51 -0000 X-NetworkBox-HamSign: 0101;OUT;hitachihk1;801140d8d045cf596017974b5e38476c; Received: from unknown (HELO hitachihk5.hitachi.cn) (170.95.94.1)by ip-11-194-65-202.rev.dyxnet.com with SMTP; 3 Nov 2005 15:42:50 -0000 Received: (qmail 6914 invoked from network); 3 Nov 2005 15:42:50 -0000 X-NetworkBox-HamSign: 0101;OUT;hitachihk5;e4432081fe90b8931b4b3ab557ae6548; Received: from hchidc204.hitachi-china.com (HELO hchidc204.hitachi.cn) (170.95.82.6)by 172.16.10.9 with SMTP; 3 Nov 2005 15:42:50 -0000 Received: from hcbjdc2.hitachi.cn ([170.95.81.2]) by hchidc204.hitachi.cn with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Nov 2005 23:42:50 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] Another Revised agenda for SIP et IETF 64 Date: Thu, 3 Nov 2005 23:42:48 +0800 Message-ID: <834B54D356AA8F46B9B233DD88BEAA38BC698D@hcbjdc2> Thread-Topic: [Sip] Another Revised agenda for SIP et IETF 64 Thread-Index: AcXf+l5iR4FnHF/2QSOvVOv1GDIq+wAkhoNw From: "DENG, HUI -HCHBJ" To: "Allison Mankin" , "Binfeng Yan" X-OriginalArrivalTime: 03 Nov 2005 15:42:50.0400 (UTC) FILETIME=[3F200200:01C5E08D] X-Scanned-By-hitachihk5: Virus scan performed by network-box X-Scanned-By-hitachihk5: Scanner file id is hitachihk5-1131032570.597-6904-000 X-Scanned-By-hitachihk5: No known viruses found in message (received+scanned in 0.02/0.07 secs) X-Scanned-By-hitachihk5: Spam-Check-Result: No, hits=0 required=7 tests= autolearn=no version=2.0 X-Spam-Status: No X-Scanned-By-hitachihk1: Virus scan performed by network-box X-Scanned-By-hitachihk1: Scanner file id is hitachihk1-1131032570.880-18749-000 X-Scanned-By-hitachihk1: No known viruses found in message (received+scanned in 0.01/0.01 secs) X-Scanned-By-hitachihk1: Spam-Check-Result: No, hits=0 required=7 tests= autolearn=no version=2.0 X-Scanned-By-hitachihk1: Whitelisted with valid signature (outbound via Network Box hitachihk5) X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: sip@ietf.org, Rohan Mahy , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0466998106==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============0466998106== Content-class: urn:content-classes:message Content-Type: text/plain;charset="UTF-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SGksIA0KDQoJSSB0aGluayB0aGlzIGlzIGEgcmVhc29uYWJsZSBwbGFjZSBmb3IgdGhlIEFyZWEg RGlyZWN0b3IgdG8gDQoJc3BlYWsgYSBsaXR0bGUgbW9yZS4gIFRoZXJlJ3MgZGVmaW5pdGVseSBh IHByZWNlZGVudCBmb3IgbWFraW5nIHJvb20gDQoJZm9yIGV4aXN0aW5nIHR5cGVzIG9mIFNJTSBp biB0aGUgSUVURi1zdHJ1Y3R1cmVkIHNlY3VyaXR5IGRlc2lnbnMuIA0KCUJ1dCB3aHkgaXMgdGhp cyBhbiBpc3N1ZSBmb3IgdGhlIFNJUCB3b3JraW5nIGdyb3VwLCANCglvbmNlIFNJUCBoYXMgY29t ZSB1cCB3aXRoIGEgYmFzaWMgc2VjdXJpdHkgZGVzaWduIHRoYXQgaGFzIA0KCUlFVEYtc3RydWN0 dXJlZCBzZWN1cml0eSBpbiBpdD8gDQoNCgk9PT4gVGhhbmtzIEFEIGhlcmUsIHdlIHRoaW5rIHJl YXNvbiBpcyBzaW5jZSBIVFRQIEFLQS1EaWdlc3QgYXBwZWFycyBoZXJlIDopDQoNCglJbiBteSB2 aWV3LCB0aGUgU2VjdXJpdHkgQXJlYSBuZWVkcyB0byByZXZpZXcgeW91ciByZXF1aXJlbWVudHMg DQoJYW5kIHRoZW4geW91ciBzcGVjaWZpY2F0aW9uLiAgSSB3b3VsZCByZWNvbW1lbmQgdGhhdCAN Cgl0aGUgZG9jdW1lbnQgYmVjb21lIGFuIEFELXNwb25zb3JlZCBpbmRpdmlkdWFsIHN1Ym1pc3Np b24sIHRoZSANCglzYW1lIHdheSB0aGF0IERpZ2VzdC1BS0Egd2FzLiAgDQoNCgk9PT4gd2UgYXJl IG5vdCBmYW1pbGlhciB3aXRoIHdoYXQncyBoYXBwZW5lZCBmb3IgRGlnZXN0LUFLQSBoaXN0b3Jp Y2FsbHkNCg0KCXdvdWxkIGxpa2UgdG8gdW5kZXJzdGFuZCBtb3JlLg0KDQoJSSB3b3VsZCBiZSBo YXBweSB0byBhc2sgUnVzcyBIb3VzbGV5IHRvIGFkb3B0IHRoaXMgd29yaywgYW5kIA0KCWFzayBT SVAgZm9yIGFkdmljZSB0byB0aGUgZXh0ZW50IGFueSBTSVAgaXNzdWVzIGNvbWUgdXAuIA0KDQoJ PT0+IFRoYW5rcyBhZ2Fpbg0KDQoJSnVzdCByZWFkaW5nIGEgbGl0dGxlLCB0aGVyZSBoYXZlIGJl ZW4gZW5vdWdoIGF0dGFja3Mgb24gQ0FWRSwgdGhhdCANCgl0aG91Z2ggaXQncyB3aWRlbHkgdXNl ZCwgdGhlIHRyYWRlb2ZmIGZvciB0aGUgc3BlY2lmaWNhdGlvbiB3aWxsIA0KCWJlIHRvIG1ha2Ug c3VyZSBpdCBzdGF0ZXMgY2xlYXJseSB3aGF0IHRoZSByaXNrcyBhcmUsIGFuZCBpdCdzIHRoaXMg DQoJc3R1ZmYgZXNwZWNpYWxseSB0aGF0IG1ha2VzIGl0IGEgbm9uLVNJUCBJbmZvcm1hdGlvbmFs IHdpdGggYSANCglTRUMgQUQgc3BvbnNvci4gDQoNCgk9PT4gSSBndWVzcyB0aGF0IGhlcmUgd2hh dCB5b3UgbWVhbiBpcyBsaWtlIHRoZSBTZWN0aW9uIG9mIFNlY3VyaXR5IENvbnNpZGVyYXRpb24N Cg0KCWluIFJGQyAzMzEwLg0KDQoJT25lIHRoaW5nIEkgc3RpbGwgbm90IGNsZWFyIGlzIGRvIHlv dSBtZWFuIHRoaXMgYW5hbHlzaXMgc2hvdWxkIGJlIGRvbmUgaW4gcHJvYmxlbSANCg0KCXN0YXRl bWVudCBvciBpbiBzb2x1dGlvbi4NCg0KCUFub3RoZXIgdGhpbmcgaXMgZG8geW91IG1lYW4gdGhh dCBzb2x1dGlvbiBjb3VsZCBiZWNvbWUgbm9uLVNJUCBpbmZvcm1hdGlvbmFsDQoNCglvciBwcm9i bGVtIHN0YXRlbWVudCBjb3VsZCBiZWNvbWUgbm9uLVNJUCBpbmZvcm1hdGlvbmFsDQoNCgkgDQoN CgltYW55IHRoYW5rcw0KDQoJLUh1aQ0KDQo= Disclaimer: The contents of this e-mail, and its attachments, if any, are confidential and may be protected by law against any unauthorized use. If you have received this e-mail by mistake or have reason to believe that you are not the intended recipient, please notify the sender by reply e-mail as soon as possible and delete it from your computer system immediately thereafter. If you are not the intended recipient, you must not copy this e-mail or attachment or disclose the contents to any other person. While we have made every effort to keep our network virus free, we take no responsibility for any computer virus which might be transferred by way of this e-mail. --===============0466998106== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============0466998106==-- From sip-bounces@ietf.org Thu Nov 03 14:35:17 2005 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 1EXkrl-0003j5-Pl; Thu, 03 Nov 2005 14:35:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXkrd-0003in-J5 for sip@megatron.ietf.org; Thu, 03 Nov 2005 14:35:16 -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 OAA21682 for ; Thu, 3 Nov 2005 14:34:46 -0500 (EST) Message-Id: <200511031934.OAA21682@ietf.org> Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXl6T-0001jV-9l for sip@ietf.org; Thu, 03 Nov 2005 14:50:30 -0500 Received: from localhost ([127.0.0.1] helo=psg.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EXkrW-00083U-UA; Thu, 03 Nov 2005 19:35:02 +0000 To: "DENG, HUI -HCHBJ" Subject: Re: [Sip] Another Revised agenda for SIP et IETF 64 Date: Thu, 03 Nov 2005 11:35:02 -0800 From: Allison Mankin X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: sip@ietf.org, Rohan Mahy , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, > > I think this is a reasonable place for the Area Director to > speak a little more. There's definitely a precedent for making room > for existing types of SIM in the IETF-structured security designs. > But why is this an issue for the SIP working group, > once SIP has come up with a basic security design that has > IETF-structured security in it? > > ==> Thanks AD here, we think reason is since HTTP AKA-Digest appears here :) Understood. The first time that we extended Digest, we did do it with a SIP WG document. It sort of booted the security design. Because the original question asked by the AKA folks was whether this should be HTTP-Digest-EAP-AKA, and there needed to be some discussion about why not EAP (that was actually mostly with the Security Area, I recall) and then some discussion to make sure that SIP Digest use was well thought through (this was in 2002, a long time ago). But when AKA folks needed to do HTTP AKA-Digest v2, this was not done as a SIP document. It was done as an independent AD-sponsored document with security review. > > In my view, the Security Area needs to review your requirements > and then your specification. I would recommend that > the document become an AD-sponsored individual submission, the > same way that Digest-AKA was. > > ==> we are not familiar with what's happened for Digest-AKA historically > > would like to understand more. See above. > > I would be happy to ask Russ Housley to adopt this work, and > ask SIP for advice to the extent any SIP issues come up. > > ==> Thanks again > > Just reading a little, there have been enough attacks on CAVE, that > though it's widely used, the tradeoff for the specification will > be to make sure it states clearly what the risks are, and it's this > stuff especially that makes it a non-SIP Informational with a > SEC AD sponsor. > > ==> I guess that here what you mean is like the Section of Security Consideration > > in RFC 3310. Yes. > > One thing I still not clear is do you mean this analysis should be done in problem > > statement or in solution. I'd probably just do one document with both the problem statement and the solution in it. > > Another thing is do you mean that solution could become non-SIP informational > > or problem statement could become non-SIP informational I'd do one Informational document that is AD sponsored, a non-SIP Informational, similar in content to draft-torvinen-http-digest-aka-v2-02.txt, which was independent and AD-sponsored, and which is about to come out as RFC 4169. Allison _______________________________________________ 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 From sip-bounces@ietf.org Thu Nov 03 14:55:17 2005 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 1EXlB7-0001K6-9d; Thu, 03 Nov 2005 14:55:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXlB4-0001K0-Od for sip@megatron.ietf.org; Thu, 03 Nov 2005 14:55:14 -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 OAA22893 for ; Thu, 3 Nov 2005 14:54:51 -0500 (EST) Received: from mail.pingtel.com ([65.220.123.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXlPu-0002J1-H3 for sip@ietf.org; Thu, 03 Nov 2005 15:10:35 -0500 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id 3D8766C017 for ; Thu, 3 Nov 2005 14:55:07 -0500 (EST) Subject: Re: [Sip] Alert-Info Idea (was Re: Comment on draft-willis-sip-an sweralert-01) From: "Dale R. Worley" To: Sip In-Reply-To: References: <50B1CBA96870A34799A506B2313F266706D5158B@ntht201e.siemenscomms.co.uk> <4368D156.3080106@cisco.com> <1130956108.30072.54.camel@cdhcp139.pingtel.com> Content-Type: text/plain Date: Thu, 03 Nov 2005 14:55:06 -0500 Message-Id: <1131047707.18145.26.camel@cdhcp139.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-6) Content-Transfer-Encoding: 7bit X-Spam-Score: 2.0 (++) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Wed, 2005-11-02 at 14:29 -0600, Dean Willis wrote: > But it would, I think, be useful to have a broader understanding of > this concept so that the developers of new extensions can clearly > document this decision in there new extensions. > > I wonder if it's worth trying to tack something onto draft-ietf-sip- > guidelines-09.txt? >From the looks of it, the I-D is close to what we've been discussing: Most other extensions of this type require that the server only insert the header field or parameter if it is sure the client understands it. In this case, these extensions will need to make use of the Supported request header field mechanism. This mechanism allows a server to determine if the client can understand some extension, so that it can apply the extension to the response. By their nature, these extensions may not always be able to be applied to every response. But I think that it would be good to see these conventions made more explicit. Dale _______________________________________________ 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 From sip-bounces@ietf.org Thu Nov 03 17:02:53 2005 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 1EXnAb-0008JN-TJ; Thu, 03 Nov 2005 17:02:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXnAX-0008Ii-5F; Thu, 03 Nov 2005 17:02:49 -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 RAA29243; Thu, 3 Nov 2005 17:02:25 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXnPP-0005qF-7P; Thu, 03 Nov 2005 17:18:11 -0500 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1EXnAS-0006rE-Sj; Thu, 03 Nov 2005 17:02:44 -0500 Content-Type: text/plain Mime-Version: 1.0 To: IETF-Announce@ietf.org From: The IESG Message-Id: Date: Thu, 03 Nov 2005 17:02:44 -0500 X-Spam-Score: 0.8 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Cc: sip@ietf.org, Rohan Mahy , Dean Willis Subject: [Sip] WG Action: RECHARTER: Session Initiation Protocol (sip) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org The charter of the Session Initiation Protocol (sip) working group in the Transport Area of the IETF has been updated. For additional information, please contact the Area Directors or the working group Chairs. +++ Session Initiation Protocol (sip) ================================== Current Status: Active Working Group Chair(s): Dean Willis Rohan Mahy Transport Area Director(s): Allison Mankin Jon Peterson Transport Area Advisor: Allison Mankin Technical Advisor(s): Dan Romascanu Mailing Lists: General Discussion: sip@ietf.org To Subscribe: sip-request@ietf.org In Body: subscribe Archive: http://www.ietf.org/mail-archive/web/sip/index.html Description of Working Group: The Session Initiation Protocol (SIP) working group is chartered to maintain and continue the development of SIP, currently specified as proposed standard RFC 3261, and its family of extensions. SIP is a text-based protocol, similar to HTTP and SMTP, for initiating interactive communication sessions between users. Such sessions include voice, video, chat, interactive games, and virtual reality. The main tasks of the group involve bringing SIP from proposed to draft standard and specifying and developing proposed extensions that arise out of strong requirements. The SIP working group will concentrate on the specification of SIP and its extensions, and will not explore the use of SIP for specific environments or applications. It will, however respond to general- purpose requirements for changes to SIP provided by other working groups, including the SIPPING working group, when those requirements are within the scope and charter of SIP. The process and requirements for such extensions are documented in RFC 3427, "Change Process for the Session Initiation Protocol". Throughout its work, the group will strive to maintain the basic model and architecture defined by SIP. In particular: 1. Services and features are provided end-to-end whenever possible. 2. Standards-track extensions and new features must be generally applicable, and not applicable only to a specific set of session types. 3. Simplicity is key. 4. Reuse of existing Internet protocols and architectures and integrating with other Internet applications is crucial. The primary source of change requirements to be considered by the SIP Working Group is the SIPPING working group, which analyzes the requirements for application of SIP to several different tasks, including the tasks of standards-development organizations that are developing systems based on SIP and that may require changes or extensions thereto. Additional requirements are produced by the other IETF working groups that are using SIP, including the SIMPLE WG (which is using SIP for messaging and presence) and the XCON working group (which is using SIP for centralized conferencing). In addition to extending SIP as required to address these externally- derived requirements, the deliverables of the group include assuring capable security and privacy mechanisms within SIP and increasing the stability of the SIP specification. Specific deliverables toward these goals include: 1. Mechanisms for secure expression of identity in requests and responses. 2. Mechanism to securely request services delivery by non-terminal elements ("end-to-middle"). 3. Guidelines for use of existing security mechanisms such as TLS, IPsec, and certificates. 4. Guidelines for the use of descriptive techniques such as SAML (Security Association Markup Language) with SIP. 5. Draft standard versions of SIP and critical supporting specifications. Other deliverables may be agreed upon as extensions are understood to be necessary. Prospective deliverables will be discussed with the Area Director before inclusion on agendas, and new proposed work must be approved via a charter update. Goals and Milestones: Done Server Features Negotiation submitted to IESG Done Complete IESG requested fixes to provrel and servfeat Done Revised proposed standard version of SIP (2543bis) submitted to IESG Done SIP Events specification to IESG Done The UPDATE Method submitted for Proposed Standard Done SIP extensions for media authorization (call-auth) submitted as Informational Done Preconditions extensions (manyfolks) spec to IESG Done SIP Privacy specification to IESG Done SIP Privacy and Security Requirements to IESG Done The MESSAGE Method submitted for Proposed Standard Done The Replaces Header submitted for Proposed Standard Done Refer spec to IESG Done SIP NAT extension submitted to IESG Done SIP over SCTP specification and applicability statement Done Mechanism for Content Indirection in SIP submitted to IESG for Proposed Standard Done The SIP Referred-By Header submitted to IESG for Proposed Standard Done Session Timer spec, revised to IESG Done Caller preferences specification submitted to IESG Done Submit SIP Identity documents to IESG for Proposed Standard Done The SIP Join Header submitted to IESG for Proposed Standard Done Replaces header to IESG (PS) Done Upgrade S/MIME requirement for AES in 3261 to IESG (PS) Done Application Interaction to IESG (BCP) Done Presence Publication to IESG (PS) Done Resource Priority signaling mechanism to IESG (PS) Done Guidelines for Authors of SIP extensions submitted as Informational Done Enhancements for Authenticated Identity Management to IESG (BCP) Done MIB spec to IESG Done Request History mechanism to IESG (PS) Oct 05 Mechanism for obtaining globally routable unique URIs (GRUU) to IESG (PS) Oct 05 Mechanism for REFER without implicit SUBSCRIBE to IESG (PS) Nov 05 Connection reuse mechanism to IESG (PS) Dec 05 Mechanism for Target-Dialog to IESG (PS) Jan 06 Mechanism for feature parameters with REFER To IESG (PS) Feb 06 Mechanism and guidelines for outbound connections to IESG (PS) Feb 06 Guidelines for Using Certificates with SIP to IESG (BCP) Mar 06 Location Conveyance with SIP to IESG (PS) Apr 06 Mechanism for End-to-Middle Requests to IESG (PS) Apr 06 Mechanism for Response Identity to IESG (PS) Jul 06 Using SAML for SIP (PS) Jul 06 Revise Charter, including developing a task for a roadmap that will identify the "critical supporting specifications" and map out the Draft Standard interoperability report effort _______________________________________________ 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 From sip-bounces@ietf.org Thu Nov 03 17:16:14 2005 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 1EXnNW-0002de-6S; Thu, 03 Nov 2005 17:16:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXnNT-0002dQ-NC for sip@megatron.ietf.org; Thu, 03 Nov 2005 17:16:12 -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 RAA00927 for ; Thu, 3 Nov 2005 17:15:50 -0500 (EST) Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXncL-0006XP-Ja for sip@ietf.org; Thu, 03 Nov 2005 17:31:34 -0500 Received: (qmail 22943 invoked by uid 0); 3 Nov 2005 22:15:56 -0000 Received: from unknown (HELO BEMBUSTER) ([81.59.101.130]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 3 Nov 2005 22:15:56 -0000 Message-ID: <038c01c5e0c4$26b6c050$6402a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "Dean Willis" , "Dale R. Worley" References: <50B1CBA96870A34799A506B2313F266706D5158B@ntht201e.siemenscomms.co.uk><4368D156.3080106@cisco.com><1130956108.30072.54.camel@cdhcp139.pingtel.com><436990C6.9040002@cisco.com><1130994755.2569.30.camel@cdhcp139.pingtel.com> Subject: Re: [Sip] GRUU (was Whats wrong with Supported. (was: Alert-Info Idea) Date: Thu, 3 Nov 2005 23:15:51 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2670 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: 1.2 (+) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Content-Transfer-Encoding: 7bit Cc: Sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dean, Dale, I asked a question about this on this list (28/9), which Jonathan responded to on 20/10. In summary, I asked if it wouldn't make more sense to use a parameter in the URI to indicate that it is a GRUU, instead of the Supported: gruu approach. My reasoning was that the other use cases for GRUUs ( e.g. as contact element in PIDF documents) would not have access to the Supported: header, so clients using the URI would not know if it was a GRUU or not. Another (implicit) reason for my question was my impression that the way Supported: is used in this draft deviates from the way it is normally used. "Supported: timer" for example means - to me - that the UA understands the headers defined in the session timer RFC, Session-Expires, etc., and that it will behave in the way described there. Supported: gruu in a non-REGISTER / OPTIONS request means that the URI in the Contact header is a GRUU - hence my question "why not mark it in that header instead?" Jonathan's anwer was: "We have in fact discussed this a few times. As a general rule, its preferable to not include information in the URI itself which describes the properties of the resource to which the URI points" I understood GRUU as a property of the URI, not the resource itself. I did not receive an answer to that, and don't know if it would change the outcome of this discussion. As to the second part of my argument - that for other use cases clients won't know the URI is a GRUU - Jonathan's reply was: "In all of these cases, I don't think the recipient of the URI would do anything differently if it knew it was a gruu, as opposed to if it didnt. A GRUU is just a URI that has the property that URIs in Refer-To, contact and PIDF need to have in order to work right anyway. To date, we havent had a way to produce those URI reliably. Now we do." So the question is: would the other side (or proxies on the path) behave differently when the Supported: gruu header is present? The motivation given in the draft-06 states: "[...] since the remote target used by clients to date has typically not had the GRUU properties, implementations have adapted their behaviors (oftentimes in proprietary ways) to compensate. To facilitate a transition away from these behaviors, it is necessary for a UA receiving the message to know whether the remote target is a GRUU or not." (section 5, non-normative) In other words: "Supported: gruu" is a signal to implementations to ~not~ "adapt their behavior". So the assumption is that they would behave differently without the "Supported: gruu". If this line of reasoning is followed, I think it should be applied consistently. By implication it should also be indicated if the Refer-To URI is a GRUU or not, under the assumption that implementations would otherwise "adapt their behavior". However, this creates an ambiguity when Supported: gruu is used to indicate that: What if a request is sent with both a Contact and a Refer-To header, and only one of the two is a GRUU? IMO, the usage of Supported here is questionable (with the exception of the REGISTER and OPTIONS requests, for which it does makes sense) Regards, jeroen ----- Original Message ----- From: "Dean Willis" To: "Dale R. Worley" Cc: "Sip" Sent: Thursday, November 03, 2005 7:13 AM Subject: [Sip] GRUU (was Whats wrong with Supported. (was: Alert-Info Idea) > On Nov 2, 2005, at 11:12 PM, Dale R. Worley wrote: > >> On Wed, 2005-11-02 at 23:23 -0500, Paul Kyzivat wrote: >>> One issue is the one that has been discussed in this thread: do >>> Supports >>> and Requires just negotiate the *availability* of an option, or do they >>> also, in one way or another, imply the *use* of an option. >>> >>> For example, the GRUU spec calls for a UA that has obtained a gruu and >>> is inserting it as a contact in some request to insert a Supported: >>> gruu. Recipients of such a request are expected to interpret this as >>> meaning that the contact in the request has the gruu property. So in >>> that case the presence of the Supported header is being construed to >>> mean that the sender *used* the option in a particular way. >> . . . >> >> Using Supported/Required only in regard to the UA-wide property of >> whether it conforms to an RFC is straightforward, and it dodges the >> issue of the scope over with the declaration applies -- it applies to >> *all* messages, though of course, whether it implies anything about any >> one particular message depends on the RFC. >> >>> From this point of view, using "Supported: gruu" to indicate that the >> Contact is a GRUU is fundamentally broken, as the UA either supports >> GRUUs or not, regardless of whether it has obtained a GRUU that is >> usable for this transaction. I would then suggest that GRUU Contacts >> should be indicated by a field-parameter of "gruu" or some such. >> "Supported: gruu" is just the signal that the UA won't apply the gruu >> field-parameter without it meaning "This Contact is a GRUU". (I seem to >> recall somebody suggested this a while back.) > > > Ok, having looked at the GRUU draft again, I'd like to consider this a > WGLC comment on GRUU, which I shall paraphrase as "What do you mean, > Supported:?" > > One could make the argument that a UA that supports GRUU would never, for > any reason, populate the Contact in a transaction other than REGISTER (or > the 200 OK thereto) with something that is not a GRUU, and that one can > therefore assume that the presence of Supported: gruu in a message > outside a REGISTER transaction means that the contact is a GRUU. But if > one were to make that argument, one would need to spell this out clearly. > > One might also make the argument that the user of a contact need (outside > a REGISTER transaction) never know whether that contact is a GRUU. > Rather, if it works, it works. So the Supported: gruu means nothing > outside a REGISTER or OPTIONS transaction, and very little in an OPTIONS > transaction. > > Or perhaps one might argue that I've built a castle of fallacious logic > around the use of SIP option tags, and they really mean "If I put this > option tag here, I'm either doing or requiring you do exactly what that > option tag means". This then raises the possibility that policy might say > we "do" an option for correspondent A but not for correspondent B, which > means the "option tag constancy" characteristic of RFC 3261 is > incorrectly worded (and I believe I argued for this model during 3261, > but that was a while back). > > -- > Dean > > > _______________________________________________ > 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 From sip-bounces@ietf.org Thu Nov 03 19:41:03 2005 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 1EXpdf-00057D-L6; Thu, 03 Nov 2005 19:41:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXpdd-000574-LZ for sip@megatron.ietf.org; Thu, 03 Nov 2005 19:41:01 -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 TAA08905 for ; Thu, 3 Nov 2005 19:40:39 -0500 (EST) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXpsX-00029C-37 for sip@ietf.org; Thu, 03 Nov 2005 19:56:25 -0500 Received: from [64.101.149.214] (deanwillis-comp.cisco.com [64.101.149.214]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id jA40kCSJ011258 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 3 Nov 2005 18:46:13 -0600 In-Reply-To: <038c01c5e0c4$26b6c050$6402a8c0@BEMBUSTER> References: <50B1CBA96870A34799A506B2313F266706D5158B@ntht201e.siemenscomms.co.uk><4368D156.3080106@cisco.com><1130956108.30072.54.camel@cdhcp139.pingtel.com><436990C6.9040002@cisco.com><1130994755.2569.30.camel@cdhcp139.pingtel.com> <038c01c5e0c4$26b6c050$6402a8c0@BEMBUSTER> Mime-Version: 1.0 (Apple Message framework v746.2) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <49ED8F8B-1A9B-431D-81E7-52769F6199E6@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] GRUU (was Whats wrong with Supported. (was: Alert-Info Idea) Date: Thu, 3 Nov 2005 18:40:47 -0600 To: "Jeroen van Bemmel" X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit Cc: Sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Nov 3, 2005, at 4:15 PM, Jeroen van Bemmel wrote: > > I understood GRUU as a property of the URI, not the resource > itself. I did not receive an answer to that, and don't know if it > would change the outcome of this discussion. > I agree with the assertion that GRUU is a property of the URI, not of the resource indicated by the URI. However, I'm not certain that we need to know that the URI has the "GRUU properties". More on that later. > As to the second part of my argument - that for other use cases > clients won't know the URI is a GRUU - Jonathan's reply was: "In > all of these cases, I don't think the recipient of the URI would do > anything differently if it knew it was a gruu, as opposed to if it > didnt. A GRUU is just a URI that has the property that URIs in > Refer-To, contact and PIDF need to have in order to work right > anyway. To date, we havent had a way to produce those URI reliably. > Now we do." > > So the question is: would the other side (or proxies on the path) > behave differently when the Supported: gruu header is present? > > The motivation given in the draft-06 states: "[...] since the > remote target used by clients to date has typically not had the > GRUU properties, implementations have adapted their behaviors > (oftentimes in proprietary ways) to compensate. To facilitate a > transition away from these behaviors, it is necessary for a UA > receiving the message to know whether the remote target is a GRUU > or not." (section 5, non-normative) > > In other words: "Supported: gruu" is a signal to implementations to > ~not~ "adapt their behavior". So the assumption is that they would > behave differently without the "Supported: gruu". > > If this line of reasoning is followed, I think it should be applied > consistently. By implication it should also be indicated if the > Refer-To URI is a GRUU or not, under the assumption that > implementations would otherwise "adapt their behavior". However, > this creates an ambiguity when Supported: gruu is used to indicate > that: What if a request is sent with both a Contact and a Refer-To > header, and only one of the two is a GRUU? > > IMO, the usage of Supported here is questionable (with the > exception of the REGISTER and OPTIONS requests, for which it does > makes sense) The open question is: would modes (other than registrars) really behave differently if they thought a URI to be a GRUU? If not, then we have no need for the use of "Supported: gruu" as a hint, or to tag a URI as a GRUU syntactically. If so, then we would appear to need a way, on a per-URI basis, to indicate that a URI isa GRUU. -- Dean _______________________________________________ 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 From sip-bounces@ietf.org Thu Nov 03 19:55:38 2005 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 1EXprm-0000G1-Js; Thu, 03 Nov 2005 19:55:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXprl-0000Fv-Ja for sip@megatron.ietf.org; Thu, 03 Nov 2005 19:55: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 TAA09713 for ; Thu, 3 Nov 2005 19:55:14 -0500 (EST) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXq6e-0002Z6-O9 for sip@ietf.org; Thu, 03 Nov 2005 20:11:01 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Thu, 3 Nov 2005 16:55:26 -0800 Received: from red-hub-02.redmond.corp.microsoft.com ([157.54.7.100]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Nov 2005 16:55:26 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Nov 2005 16:55:26 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.89]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Nov 2005 16:55:25 -0800 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] GRUU (was Whats wrong with Supported. (was: Alert-Info Idea) Date: Thu, 3 Nov 2005 16:57:02 -0800 Message-ID: Thread-Topic: [Sip] GRUU (was Whats wrong with Supported. (was: Alert-Info Idea) thread-index: AcXg2OWyDVgYZOHfRy+JszPEkDNKhwAAV3Ew From: "Sean Olson" To: "Dean Willis" , "Jeroen van Bemmel" X-OriginalArrivalTime: 04 Nov 2005 00:55:25.0924 (UTC) FILETIME=[715B7A40:01C5E0DA] X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: quoted-printable Cc: Sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Well, if GRUU =3D=3D Globally Routable UA URI, and you treat a URI as a GRUU which does not have one of these properties, things will break. If you care when things break, you would want to know in advance. This would apply to UAs, proxies, etc. You could make the argument that all URIs should be GRUUs so what you really want is a property that says a URI is *not* at a GRUU and assume all others are ;-)=20 -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Dean Willis Sent: Thursday, November 03, 2005 4:41 PM To: Jeroen van Bemmel Cc: Sip Subject: Re: [Sip] GRUU (was Whats wrong with Supported. (was: Alert-Info Idea) On Nov 3, 2005, at 4:15 PM, Jeroen van Bemmel wrote: > > I understood GRUU as a property of the URI, not the resource itself. I > did not receive an answer to that, and don't know if it would change=20 > the outcome of this discussion. > I agree with the assertion that GRUU is a property of the URI, not of the resource indicated by the URI. However, I'm not certain that we need to know that the URI has the "GRUU properties". More on that later. > As to the second part of my argument - that for other use cases=20 > clients won't know the URI is a GRUU - Jonathan's reply was: "In all=20 > of these cases, I don't think the recipient of the URI would do=20 > anything differently if it knew it was a gruu, as opposed to if it=20 > didnt. A GRUU is just a URI that has the property that URIs in=20 > Refer-To, contact and PIDF need to have in order to work right anyway. > To date, we havent had a way to produce those URI reliably. > Now we do." > > So the question is: would the other side (or proxies on the path)=20 > behave differently when the Supported: gruu header is present? > > The motivation given in the draft-06 states: "[...] since the remote=20 > target used by clients to date has typically not had the GRUU=20 > properties, implementations have adapted their behaviors (oftentimes=20 > in proprietary ways) to compensate. To facilitate a transition away=20 > from these behaviors, it is necessary for a UA receiving the message=20 > to know whether the remote target is a GRUU or not." (section 5,=20 > non-normative) > > In other words: "Supported: gruu" is a signal to implementations to=20 > ~not~ "adapt their behavior". So the assumption is that they would=20 > behave differently without the "Supported: gruu". > > If this line of reasoning is followed, I think it should be applied=20 > consistently. By implication it should also be indicated if the=20 > Refer-To URI is a GRUU or not, under the assumption that=20 > implementations would otherwise "adapt their behavior". However, this=20 > creates an ambiguity when Supported: gruu is used to indicate > that: What if a request is sent with both a Contact and a Refer-To=20 > header, and only one of the two is a GRUU? > > IMO, the usage of Supported here is questionable (with the exception=20 > of the REGISTER and OPTIONS requests, for which it does makes sense) The open question is: would modes (other than registrars) really behave differently if they thought a URI to be a GRUU? If not, then we have no need for the use of "Supported: gruu" as a hint, or to tag a URI as a GRUU syntactically. If so, then we would appear to need a way, on a per-URI basis, to indicate that a URI isa GRUU. -- Dean _______________________________________________ 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 From sip-bounces@ietf.org Thu Nov 03 21:50:44 2005 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 1EXrfA-000153-1q; Thu, 03 Nov 2005 21:50:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXrf8-00014y-DZ for sip@megatron.ietf.org; Thu, 03 Nov 2005 21:50:42 -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 VAA15438 for ; Thu, 3 Nov 2005 21:50:19 -0500 (EST) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXru1-0005Xs-U9 for sip@ietf.org; Thu, 03 Nov 2005 22:06:07 -0500 Received: from [64.101.149.214] (deanwillis-comp.cisco.com [64.101.149.214]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id jA42tgYO011734 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 3 Nov 2005 20:55:43 -0600 Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Date: Thu, 3 Nov 2005 20:50:24 -0600 To: Sip X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Cc: mankin@ietf.org, Gonzalo Camarillo , Rohan Mahy Subject: [Sip] Problem with IANA policy in RFC 3969 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org RFC 3969 defines the IANA registry for SIP and SIPS URI parameters. It currently says: -------- 4.2. Registration Policy for SIP and SIPS URI Parameters As per the terminology in RFC 2434 [4], the registration policy for SIP and SIPS URI parameters shall be "Specification Required". For the purposes of this registry, the parameter for which IANA registration is requested MUST be defined by a standards-track RFC. --------- Which IANA has quite reasonably interpreted as "Specification Required". It has been pointed out to me that the text in 3969 is self contradictory, and that the policy as interpreted by IANA is not exactly consistent with what we may have meant in 3969 (although I think I argued for a simple "specification required" at the time, I think I got out-shouted). What we may have been trying to say is "Specification Required, but if that specification is an RFC, we want that RFC to represent an IETF consensus as defined by RFC 2434 (meaning that it has had IESG review and is appealable)." Thoughts? -- Dean _______________________________________________ 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 From sip-bounces@ietf.org Thu Nov 03 22:02:35 2005 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 1EXrqd-0003ZO-Gi; Thu, 03 Nov 2005 22:02:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXrqa-0003X9-FX for sip@megatron.ietf.org; Thu, 03 Nov 2005 22:02:33 -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 WAA16103 for ; Thu, 3 Nov 2005 22:02:08 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXs5T-0005rN-Ls for sip@ietf.org; Thu, 03 Nov 2005 22:17:57 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 03 Nov 2005 19:02:21 -0800 X-IronPort-AV: i="3.97,289,1125903600"; d="scan'208"; a="671784615:sNHT25451916" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jA432IVR001107; Thu, 3 Nov 2005 19:02:19 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 3 Nov 2005 22:02:18 -0500 Received: from [10.82.217.53] ([10.82.217.53]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 3 Nov 2005 22:02:17 -0500 Message-ID: <436ACF39.8070907@cisco.com> Date: Thu, 03 Nov 2005 22:02:17 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Dale R. Worley" Subject: Re: [Sip] Alert-Info Idea (was Re: Comment on draft-willis-sip-an sweralert-01) References: <50B1CBA96870A34799A506B2313F266706D5158B@ntht201e.siemenscomms.co.uk> <4368D156.3080106@cisco.com> <1130956108.30072.54.camel@cdhcp139.pingtel.com> <1131047707.18145.26.camel@cdhcp139.pingtel.com> In-Reply-To: <1131047707.18145.26.camel@cdhcp139.pingtel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Nov 2005 03:02:17.0905 (UTC) FILETIME=[2A739A10:01C5E0EC] X-Spam-Score: 2.0 (++) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Cc: Sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dale R. Worley wrote: > On Wed, 2005-11-02 at 14:29 -0600, Dean Willis wrote: > >>But it would, I think, be useful to have a broader understanding of >>this concept so that the developers of new extensions can clearly >>document this decision in there new extensions. >> >>I wonder if it's worth trying to tack something onto draft-ietf-sip- >>guidelines-09.txt? I haven't looked at that in a long time. It raises some additional questions in my mind. For instance: In order to achieve backwards compatibility for extensions that define new methods, the Allow header field is used. There are two types of new methods - those that are used for established dialogs (initiated by INVITE, for example), and those that are sent as the initial request to a UA. Since INVITE and its response both SHOULD contain an Allow header field, a UA can readily determine whether the new method can be supported within the dialog. For example, once an INVITE dialog is established, a user agent could determine if the REFER method [12] is supported if it is present in an Allow header. If it wasn't, the "transfer" button on the UI could be "greyed out" once the call is established. This implies that the scope of Allow is, or at least encompasses, the dialog. Similarly: When a body must be understood to properly process a request or response, it is preferred that the sending entity know ahead of time whether the new body is understood by the recipient. For requests that establish a dialog, inclusion of Accept in the request and its success responses is RECOMMENDED. This will allow both parties to determine what body types are supported by their peers. Subsequent messaging between the peers would then only include body types that were indicated as being understood. implies that the scope of Accept is a dialog. Perhaps I read too much into this language. But the emphasis that dialog establishing requests and their responses should include these things also implies that other requests and responses need not. But at best this is an incomplete set of rules. >>From the looks of it, the I-D is close to what we've been discussing: > > Most other extensions of this type require that the server only > insert the header field or parameter if it is sure the client > understands it. In this case, these extensions will need to make use > of the Supported request header field mechanism. This mechanism > allows a server to determine if the client can understand some > extension, so that it can apply the extension to the response. By > their nature, these extensions may not always be able to be applied > to every response. > > But I think that it would be good to see these conventions made more explicit. I agree. Paul _______________________________________________ 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 From sip-bounces@ietf.org Thu Nov 03 22:13:03 2005 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 1EXs0l-0006UO-DR; Thu, 03 Nov 2005 22:13:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXs0j-0006UJ-LH for sip@megatron.ietf.org; Thu, 03 Nov 2005 22:13:01 -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 WAA16595 for ; Thu, 3 Nov 2005 22:12:38 -0500 (EST) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXsFd-00067d-IX for sip@ietf.org; Thu, 03 Nov 2005 22:28:26 -0500 Received: from [64.101.149.214] (deanwillis-comp.cisco.com [64.101.149.214]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id jA43IEfu011837 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 3 Nov 2005 21:18:15 -0600 Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0F7F6BB4-1B10-4882-B037-F25DC704133B@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Date: Thu, 3 Nov 2005 21:12:56 -0600 To: Sip X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: Allison Mankin Subject: [Sip] Possible flaw in SIP Change process RFC 3427 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org RCP 3427 / BCP 67, "Change Process for the Session Initiation Protocol", spells out the level of review necessary for SIP extensions, event packages, and lots of other stuff. But it talks only minimally, if at all about "usage conventions" and "mappings". As I've just learned following my review of draft-jennings-sip- voicemail-uri-04 for the RFC editor (we had thought this document innocuous enough to publish as Individual Informational), there's a hole 'nother category of "gotchas" that RFC 3427 doesn't cover. It seems that anytime we do a mapping between an IETF protocol and some "foreign" protocol, even in something that's just a "usage convention", we have to be very careful. This is something that's hard to do correctly, and potentially politically charged due to relations between IETF and the standards bodies responsible for the "foreign" protocol. Should we document this as an errata for RFC 3427, or what? -- Dean _______________________________________________ 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 From sip-bounces@ietf.org Thu Nov 03 23:15:56 2005 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 1EXszc-0005Gb-KB; Thu, 03 Nov 2005 23:15:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXsza-0005GW-RV for sip@megatron.ietf.org; Thu, 03 Nov 2005 23:15:54 -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 XAA19715 for ; Thu, 3 Nov 2005 23:15:31 -0500 (EST) Received: from mail.pingtel.com ([65.220.123.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXtES-0007kQ-Sa for sip@ietf.org; Thu, 03 Nov 2005 23:31:19 -0500 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id DF2B86C017 for ; Thu, 3 Nov 2005 23:15:45 -0500 (EST) Subject: Re: [Sip] Possible flaw in SIP Change process RFC 3427 From: "Dale R. Worley" To: Sip In-Reply-To: <0F7F6BB4-1B10-4882-B037-F25DC704133B@softarmor.com> References: <0F7F6BB4-1B10-4882-B037-F25DC704133B@softarmor.com> Content-Type: text/plain Date: Thu, 03 Nov 2005 23:15:45 -0500 Message-Id: <1131077745.8991.9.camel@cdhcp139.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-6) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Thu, 2005-11-03 at 21:12 -0600, Dean Willis wrote: > It seems that anytime we do a mapping between an IETF protocol and > some "foreign" protocol, even in something that's just a "usage > convention", we have to be very careful. This is something that's > hard to do correctly, and potentially politically charged due to > relations between IETF and the standards bodies responsible for the > "foreign" protocol. > > Should we document this as an errata for RFC 3427, or what? If we have evidence that unpleasant mistakes have been made in this area, it's worth flagging as a potential trouble area. But I assume that you also have some idea of advice or even rules (of thumb) as to how this problem can be resolved, which is what would be a valuable addition to 3427. Dale _______________________________________________ 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 From sip-bounces@ietf.org Thu Nov 03 23:39:19 2005 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 1EXtMF-0002Nl-2e; Thu, 03 Nov 2005 23:39:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXtMD-0002Ng-84 for sip@megatron.ietf.org; Thu, 03 Nov 2005 23:39:17 -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 XAA20808 for ; Thu, 3 Nov 2005 23:38:55 -0500 (EST) Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXtb7-0008Kq-LZ for sip@ietf.org; Thu, 03 Nov 2005 23:54:43 -0500 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id jA44ck8U024125 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 3 Nov 2005 20:38:47 -0800 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id jA44ciZH016155; Thu, 3 Nov 2005 20:38:45 -0800 (PST) Received: from NAEX08.na.qualcomm.com ([10.46.56.94]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 3 Nov 2005 20:38:44 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 3 Nov 2005 20:38:43 -0800 Message-ID: Thread-Topic: media description in SDP is for sender or receiver? Thread-Index: AcXg+aLcFGoOi4AFTj+O7UnAA/2j+w== From: "Ling, Fan" To: , X-OriginalArrivalTime: 04 Nov 2005 04:38:44.0656 (UTC) FILETIME=[A39FBB00:01C5E0F9] X-Spam-Score: 0.1 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Cc: Subject: [Sip] media description in SDP is for sender or receiver? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0519539463==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0519539463== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5E0F9.A3480C6E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5E0F9.A3480C6E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, The following SDP message describes a MPEG4 video bitstream: =20 m=3Dvideo 20000 RTP/AVP 98 34 a=3Drtpmap:98 MP4V-ES/90000 a=3Dfmtp:98 profile-level-id=3D8;config=3D000001B008000001B5090000010000000120008440F= A28 2C2090A21F =20 Does this SDP message describes the sender encoder generated media settings or the required media settings on the receiver's encoder? Or both? Can some one point me to the proper RFCs? I believe this media settings is for the sender side, but I can't find definitely description in any RFCs. Thanks a lot Fan ------_=_NextPart_001_01C5E0F9.A3480C6E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

The following SDP message describes a MPEG4 video = bitstream:

 

m=3Dvideo 20000 RTP/AVP 98 = 34

a=3Drtpmap:98 = MP4V-ES/90000

a=3Dfmtp:98 profile-level-id=3D8;config=3D000001B008000001B5090000010000000120008440F= A282C2090A21F

 

Does this SDP message describes the = sender encoder generated media settings or the required media settings on the = receiver’s encoder? Or both? Can some one point me to the proper RFCs? I believe = this media settings is for the sender side, but  I can’t find = definitely description in any RFCs.

Thanks a lot

Fan

------_=_NextPart_001_01C5E0F9.A3480C6E-- --===============0519539463== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============0519539463==-- From sip-bounces@ietf.org Thu Nov 03 23:58:35 2005 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 1EXtet-0006yj-T6; Thu, 03 Nov 2005 23:58:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXter-0006yA-BK for sip@megatron.ietf.org; Thu, 03 Nov 2005 23:58:33 -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 XAA21575 for ; Thu, 3 Nov 2005 23:58:11 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXttm-0000SL-0z for sip@ietf.org; Fri, 04 Nov 2005 00:13:59 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 03 Nov 2005 20:58:23 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jA44wKVR006804; Thu, 3 Nov 2005 20:58:21 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 3 Nov 2005 20:58:20 -0800 Received: from jmpolk-wxp.cisco.com ([10.21.96.203]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 3 Nov 2005 20:58:20 -0800 Message-Id: <4.3.2.7.2.20051103225653.0351ab40@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 03 Nov 2005 22:58:19 -0500 To: "Ling, Fan" , , From: "James M. Polk" Subject: Re: [Sip] media description in SDP is for sender or receiver? In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 04 Nov 2005 04:58:20.0345 (UTC) FILETIME=[6063A290:01C5E0FC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org At 08:38 PM 11/3/2005 -0800, Ling, Fan wrote: >The following SDP message describes a MPEG4 video bitstream: >m=video 20000 RTP/AVP 98 34 >a=rtpmap:98 MP4V-ES/90000 >a=fmtp:98 >profile-level-id=8;config=000001B008000001B5090000010000000120008440FA282C2090A21F > >Can some one point me to the proper RFCs? RFC3264 > > >Thanks a lot > >Fan >_______________________________________________ >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 cheers, James ******************* Truth is not to be argued... it is to be presented. _______________________________________________ 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 From sip-bounces@ietf.org Fri Nov 04 01:50:30 2005 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 1EXvPC-0007xz-Ir; Fri, 04 Nov 2005 01:50:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXvP7-0007x0-W8 for sip@megatron.ietf.org; Fri, 04 Nov 2005 01:50:28 -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 BAA26588 for ; Fri, 4 Nov 2005 01:50:03 -0500 (EST) Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXve4-0003E7-1s for sip@ietf.org; Fri, 04 Nov 2005 02:05:52 -0500 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id jA46nPGe006846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 3 Nov 2005 22:49:26 -0800 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id jA46nNZH009600; Thu, 3 Nov 2005 22:49:23 -0800 (PST) Received: from NAEX08.na.qualcomm.com ([10.46.56.94]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 3 Nov 2005 22:49:23 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 3 Nov 2005 22:49:21 -0800 Message-ID: Thread-Topic: [Sip-implementors] media description in SDP is for sender or receiver? Thread-Index: AcXhAixCiR6BzgveTGmqsPQ9RZjIMwAByzKQ From: "Ling, Fan" To: , X-OriginalArrivalTime: 04 Nov 2005 06:49:23.0177 (UTC) FILETIME=[E3BF1D90:01C5E10B] X-Spam-Score: 0.2 (/) X-Scan-Signature: 7b4956e5f2f9c5fe16a8fbd4ddb538bc Cc: sip@ietf.org Subject: [Sip] RE: [Sip-implementors] media description in SDP is for sender or receiver? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0232038387==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0232038387== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5E10B.E35E52DA" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5E10B.E35E52DA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sir, Thanks for the reply.=20 The following is an abstract from RFC3264 section 6.1 page 8: " The interpretation of fmtp parameters in an offer depends on the parameters. Inmany cases, those parameters describe specific configurations of the media format, and should therefore be processed as the media format value itself would be. This means that the same fmtp parameters with the same values MUST be present in the answer if the media format they describe is present in the answer. Other fmtp parameters are more like parameters, for which it is perfectly acceptable for each agent to use different values. In that case, the answer MAY contain fmtp parameters, and those MAY have the same values as those in the offer, or they MAY be different. SDP extensions that define new parameters SHOULD specify the proper interpretation in offer/answer. " Since the "config=3D" field in my example is specific configuration for MPEG4 simple profile video bitstream, its interpretation should "depends on the parameters", however, I can't find such interpretation in MPEG4 RTP RFC3016. =20 Any of your advice is welcome! Thanks, Fan =20 =20 -----Original Message----- From: Somesh S Shanbhag [mailto:someshss@yahoo.com]=20 Sent: Thursday, November 03, 2005 9:33 PM To: Ling, Fan; sip-implementors@cs.columbia.edu Subject: Re: [Sip-implementors] media description in SDP is for sender or receiver? =20 Hi, =20 RFC 3264 specifies sendonly, recvonly, sendrecv and=20 inactive attributes. UA can specify any of these=20 attributes according to it's preference. When no such attribute is present, it is assumed that the stream is "sendrecv" stream and whatever the encodings specified =20 applies to both sender and receiver side. =20 Regards Somesh S. Shanbhag =20 --- "Ling, Fan" wrote: =20 > Hi, >=20 > The following SDP message describes a MPEG4 video > bitstream: >=20 > =20 >=20 > m=3Dvideo 20000 RTP/AVP 98 34 >=20 > a=3Drtpmap:98 MP4V-ES/90000 >=20 > a=3Dfmtp:98 >=20 profile-level-id=3D8;config=3D000001B008000001B5090000010000000120008440F= A28 > 2C2090A21F >=20 > =20 >=20 > Does this SDP message describes the sender encoder > generated media > settings or the required media settings on the > receiver's encoder? Or > both? Can some one point me to the proper RFCs? I > believe this media > settings is for the sender side, but I can't find > definitely > description in any RFCs. >=20 > Thanks a lot >=20 > Fan >=20 > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@cs.columbia.edu >=20 http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors >=20 =20 =20 ----------------------------------------- SIMPLICITY IS THE BEAUTY. BE NATURAL LIVE NATURAL. ----------------------------------------- Somesh S. Shanbhag Focus Area - VoIP Team (FA-VoIP) Mascon Global Communication Technologies Enterprise of Mascon Global Limited #59/2, 100Ft Ring Road Banashankari II stage Bangalore-560070 Karnataka INDIA Website: http://www.masconit.com ----------------------------------------- =20 =20 =20 =20 __________________________________=20 Yahoo! Mail - PC Magazine Editors' Choice 2005=20 http://mail.yahoo.com ------_=_NextPart_001_01C5E10B.E35E52DA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sir,

Thanks for the reply.

The following is an abstract from RFC3264 section 6.1 page = 8:

"

The interpretation of fmtp parameters in an offer depends on the parameters. Inmany = cases, those parameters

describe specific configurations of the media format, and should therefore be processed as the media format

value itself would be. This means that the same fmtp parameters = with the same values MUST be present

in the answer if the media format they describe is present in = the answer. Other fmtp parameters are more

like parameters, for which it is perfectly acceptable for each = agent to use different values. In that case, the

answer MAY contain fmtp parameters, and those MAY have the same = values as those in the offer, or they

MAY be different. SDP extensions that define new parameters SHOULD specify the proper interpretation in

offer/answer.

"

Since the “config=3D” field in my example is = specific configuration for MPEG4 simple profile video bitstream, its = interpretation should “depends on the = parameters”, however, I can’t find such interpretation in MPEG4 RTP = RFC3016.

 

Any of your advice is welcome!

Thanks,

Fan  

 

-----Original Message-----
From: Somesh S Shanbhag [mailto:someshss@yahoo.com]
Sent: Thursday, November 03, 2005 9:33 PM
To: Ling, Fan; sip-implementors@cs.columbia.edu
Subject: Re: [Sip-implementors] media description in SDP is for sender = or receiver?

 

Hi,

 

RFC 3264 specifies sendonly, recvonly, sendrecv and =

inactive attributes. UA can specify any of these =

attributes according to it's preference. When no = such

attribute is present, it is assumed that the stream = is

"sendrecv" stream and whatever the encodings = specified

 

applies to both sender and receiver side.

 

Regards

Somesh S. Shanbhag

 

--- "Ling, Fan" <fanl@qualcomm.com> = wrote:

 

> Hi,

>

> The following SDP message describes a MPEG4 = video

> bitstream:

>

> 

>

> m=3Dvideo 20000 RTP/AVP 98 34

>

> a=3Drtpmap:98 MP4V-ES/90000

>

> a=3Dfmtp:98

> 

profile-level-id=3D8;config=3D000001B008000001B509000001000000012= 0008440FA28

> 2C2090A21F

>

> 

>

> Does this SDP message describes the sender = encoder

> generated media

> settings or the required media settings on = the

> receiver's encoder? Or

> both? Can some one point me to the proper RFCs? = I

> believe this media

> settings is for the sender side, but  I can't = find

> definitely

> description in any RFCs.

>

> Thanks a lot

>

> Fan

>

> = _______________________________________________

> Sip-implementors mailing list

> Sip-implementors@cs.columbia.edu

> 

http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

>

 

 

-----------------------------------------

SIMPLICITY IS THE BEAUTY.

BE NATURAL LIVE NATURAL.

-----------------------------------------

Somesh S. Shanbhag

Focus Area - VoIP Team (FA-VoIP)

Mascon Global Communication Technologies

Enterprise of Mascon Global Limited

#59/2, 100Ft Ring Road

Banashankari II stage

Bangalore-560070

Karnataka

INDIA

Website: http://www.masconit.com

-----------------------------------------

 

 

     

           = ;

__________________________________

Yahoo! Mail - PC Magazine Editors' Choice 2005 =

http://mail.yahoo.com

------_=_NextPart_001_01C5E10B.E35E52DA-- --===============0232038387== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============0232038387==-- From sip-bounces@ietf.org Fri Nov 04 02:29:11 2005 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 1EXw0d-00088c-K0; Fri, 04 Nov 2005 02:29:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXw0b-00088X-4x for sip@megatron.ietf.org; Fri, 04 Nov 2005 02:29:09 -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 CAA28503 for ; Fri, 4 Nov 2005 02:28:46 -0500 (EST) Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXwFY-0004FP-1y for sip@ietf.org; Fri, 04 Nov 2005 02:44:36 -0500 Received: (qmail 29925 invoked by uid 0); 4 Nov 2005 07:28:46 -0000 Received: from unknown (HELO BEMBUSTER) ([81.59.101.130]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 4 Nov 2005 07:28:46 -0000 Message-ID: <000c01c5e111$61e8fd80$6402a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "Sean Olson" , "Dean Willis" References: Subject: Re: [Sip] GRUU (was Whats wrong with Supported. (was: Alert-Info Idea) Date: Fri, 4 Nov 2005 08:28:42 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: 1.2 (+) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Content-Transfer-Encoding: 7bit Cc: Sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org With the current state of things, that would give many false positives... What could be defined, is a set of criteria for a URI to positively determine that it is not a GRUU. One obvious criterion is if the host part is an IP address in the private space Besides this, I think it would be wise to err on the side of caution: if we don't mark known GRUUs as such, elements that would behave differently have no way of determining that. What do we have to loose if we do mark them? There are consequences: - URI equality rules should be updated to say that if one URI is marked as GRUU and another is not, then they are not equal - anywhere where URIs are being ordered (e.g. proxy target set), with q-values being equal or absent a GRUU SHOULD be preferred over a non-GRUU - ... Regards, Jeroen ----- Original Message ----- From: "Sean Olson" To: "Dean Willis" ; "Jeroen van Bemmel" Cc: "Sip" Sent: Friday, November 04, 2005 1:57 AM Subject: RE: [Sip] GRUU (was Whats wrong with Supported. (was: Alert-Info Idea) Well, if GRUU == Globally Routable UA URI, and you treat a URI as a GRUU which does not have one of these properties, things will break. If you care when things break, you would want to know in advance. This would apply to UAs, proxies, etc. You could make the argument that all URIs should be GRUUs so what you really want is a property that says a URI is *not* at a GRUU and assume all others are ;-) -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Dean Willis Sent: Thursday, November 03, 2005 4:41 PM To: Jeroen van Bemmel Cc: Sip Subject: Re: [Sip] GRUU (was Whats wrong with Supported. (was: Alert-Info Idea) On Nov 3, 2005, at 4:15 PM, Jeroen van Bemmel wrote: > > I understood GRUU as a property of the URI, not the resource itself. I > did not receive an answer to that, and don't know if it would change > the outcome of this discussion. > I agree with the assertion that GRUU is a property of the URI, not of the resource indicated by the URI. However, I'm not certain that we need to know that the URI has the "GRUU properties". More on that later. > As to the second part of my argument - that for other use cases > clients won't know the URI is a GRUU - Jonathan's reply was: "In all > of these cases, I don't think the recipient of the URI would do > anything differently if it knew it was a gruu, as opposed to if it > didnt. A GRUU is just a URI that has the property that URIs in > Refer-To, contact and PIDF need to have in order to work right anyway. > To date, we havent had a way to produce those URI reliably. > Now we do." > > So the question is: would the other side (or proxies on the path) > behave differently when the Supported: gruu header is present? > > The motivation given in the draft-06 states: "[...] since the remote > target used by clients to date has typically not had the GRUU > properties, implementations have adapted their behaviors (oftentimes > in proprietary ways) to compensate. To facilitate a transition away > from these behaviors, it is necessary for a UA receiving the message > to know whether the remote target is a GRUU or not." (section 5, > non-normative) > > In other words: "Supported: gruu" is a signal to implementations to > ~not~ "adapt their behavior". So the assumption is that they would > behave differently without the "Supported: gruu". > > If this line of reasoning is followed, I think it should be applied > consistently. By implication it should also be indicated if the > Refer-To URI is a GRUU or not, under the assumption that > implementations would otherwise "adapt their behavior". However, this > creates an ambiguity when Supported: gruu is used to indicate > that: What if a request is sent with both a Contact and a Refer-To > header, and only one of the two is a GRUU? > > IMO, the usage of Supported here is questionable (with the exception > of the REGISTER and OPTIONS requests, for which it does makes sense) The open question is: would modes (other than registrars) really behave differently if they thought a URI to be a GRUU? If not, then we have no need for the use of "Supported: gruu" as a hint, or to tag a URI as a GRUU syntactically. If so, then we would appear to need a way, on a per-URI basis, to indicate that a URI isa GRUU. -- Dean _______________________________________________ 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 From sip-bounces@ietf.org Fri Nov 04 03:12:51 2005 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 1EXwgs-0000EU-Vc; Fri, 04 Nov 2005 03:12:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXwgq-0000EK-5c for sip@megatron.ietf.org; Fri, 04 Nov 2005 03:12:48 -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 DAA00688 for ; Fri, 4 Nov 2005 03:12:21 -0500 (EST) Received: from ip-10-194-65-202.rev.dyxnet.com ([202.65.194.10] helo=hitachi.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EXwvj-0005RA-4z for sip@ietf.org; Fri, 04 Nov 2005 03:28:12 -0500 Received: (qmail 7924 invoked from network); 4 Nov 2005 08:12:24 -0000 X-NetworkBox-HamSign: 0101;OUT;hitachihk1;0f91b5e8ddd4f896ef185549de3fa25b; Received: from unknown (HELO hitachihk5.hitachi.cn) (170.95.94.1)by ip-11-194-65-202.rev.dyxnet.com with SMTP; 4 Nov 2005 08:12:24 -0000 Received: (qmail 3734 invoked from network); 4 Nov 2005 08:12:23 -0000 X-NetworkBox-HamSign: 0101;OUT;hitachihk5;09783223a193c7d03eea8a7b68b4fa28; Received: from hchidc204.hitachi-china.com (HELO hchidc204.hitachi.cn) (170.95.82.6)by 172.16.10.9 with SMTP; 4 Nov 2005 08:12:23 -0000 Received: from hcbjdc2.hitachi.cn ([170.95.81.2]) by hchidc204.hitachi.cn with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Nov 2005 16:12:20 +0800 Subject: RE: [Sip] Another Revised agenda for SIP et IETF 64 MIME-Version: 1.0 Date: Fri, 4 Nov 2005 16:12:00 +0800 Message-ID: <834B54D356AA8F46B9B233DD88BEAA38BC698F@hcbjdc2> content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: [Sip] Another Revised agenda for SIP et IETF 64 Thread-Index: AcXgrbPfhjndpPXLRxO105yE0wsB8QAZ2ODQ From: "DENG, HUI -HCHBJ" To: "Allison Mankin" X-OriginalArrivalTime: 04 Nov 2005 08:12:20.0818 (UTC) FILETIME=[7AA6DB20:01C5E117] X-Scanned-By-hitachihk5: Virus scan performed by network-box X-Scanned-By-hitachihk5: Scanner file id is hitachihk5-1131091943.901-3731-000 X-Scanned-By-hitachihk5: No known viruses found in message (received+scanned in 0.02/0.05 secs) X-Scanned-By-hitachihk5: Spam-Check-Result: No, hits=0 required=7 tests= autolearn=no version=2.0 X-Spam-Status: No X-Scanned-By-hitachihk1: Virus scan performed by network-box X-Scanned-By-hitachihk1: Scanner file id is hitachihk1-1131091944.224-7917-000 X-Scanned-By-hitachihk1: No known viruses found in message (received+scanned in 0.01/0.02 secs) X-Scanned-By-hitachihk1: Spam-Check-Result: No, hits=0 required=7 tests= autolearn=no version=2.0 X-Scanned-By-hitachihk1: Whitelisted with valid signature (outbound via Network Box hitachihk5) X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: sip@ietf.org, Rohan Mahy , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0754236829==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============0754236829== Content-Type: text/plain;charset="utf-8" Content-Transfer-Encoding: base64 content-class: urn:content-classes:message Content-Transfer-Encoding: base64 SGksDQoNCj5VbmRlcnN0b29kLiAgVGhlIGZpcnN0IHRpbWUgdGhhdCB3ZSBleHRlbmRlZCBEaWdl c3QsIHdlIGRpZCBkbyBpdCB3aXRoDQo+YSBTSVAgV0cgZG9jdW1lbnQuICBJdCBzb3J0IG9mIGJv b3RlZCB0aGUgc2VjdXJpdHkgZGVzaWduLiAgQmVjYXVzZQ0KPnRoZSBvcmlnaW5hbCBxdWVzdGlv biBhc2tlZCBieSB0aGUgQUtBIGZvbGtzIHdhcyB3aGV0aGVyIHRoaXMgc2hvdWxkIGJlDQo+SFRU UC1EaWdlc3QtRUFQLUFLQSwgYW5kIHRoZXJlIG5lZWRlZCB0byBiZSBzb21lIGRpc2N1c3Npb24g YWJvdXQgd2h5DQo+bm90IEVBUCAodGhhdCB3YXMgYWN0dWFsbHkgbW9zdGx5IHdpdGggdGhlIFNl Y3VyaXR5IEFyZWEsIEkgcmVjYWxsKQ0KPmFuZCB0aGVuIHNvbWUgZGlzY3Vzc2lvbiB0byBtYWtl IHN1cmUgdGhhdCBTSVAgRGlnZXN0IHVzZSB3YXMgd2VsbCB0aG91Z2h0DQo+dGhyb3VnaCAodGhp cyB3YXMgaW4gMjAwMiwgYSBsb25nIHRpbWUgYWdvKS4NCkhlcmUgSSBhbHNvIGZlZWwgaW50ZXJl c3RlZCBpbiB3aHkgbm90IHVzZSBFQVAsIHRoZW4gaXQgY291bGQgYmUgdHJhbnNwb3J0ZWQgb3Zl ciANCnZhcmlvdXMga2luZCBvZiBjb25uZWN0aW9uLg0KDQo+QnV0IHdoZW4gQUtBIGZvbGtzIG5l ZWRlZCB0byBkbyBIVFRQIEFLQS1EaWdlc3QgdjIsIHRoaXMgd2FzIG5vdCBkb25lIGFzDQo+YSBT SVAgZG9jdW1lbnQuICBJdCB3YXMgZG9uZSBhcyBhbiBpbmRlcGVuZGVudCBBRC1zcG9uc29yZWQg ZG9jdW1lbnQNCj53aXRoIHNlY3VyaXR5IHJldmlldy4NCldlIGFyZSBhbHNvIG5vdCBmYW1pbGlh ciB3aXRoIEFELXNwb25zb3JlZCBkb2N1bWVudCwgZG9lcyB0aGF0IG1lYW5zIA0KdGhpcyBkb2N1 bWVudCBjb3VsZCBiZWNvbWUgaW5kZXBlbmRlbnQgZG9jdW1lbnQgb3V0IG9mIGFueSB3b3JraW5n IGdyb3VwPw0KZXhjdXNlIHVzIG5haXZlIHF1ZXN0aW9uLg0KDQo+SSdkIGRvIG9uZSBJbmZvcm1h dGlvbmFsIGRvY3VtZW50IHRoYXQgaXMgQUQgc3BvbnNvcmVkLCBhIG5vbi1TSVAgSW5mb3JtYXRp b25hbCwNCj5zaW1pbGFyIGluIGNvbnRlbnQgdG8gZHJhZnQtdG9ydmluZW4taHR0cC1kaWdlc3Qt YWthLXYyLTAyLnR4dCwgd2hpY2ggd2FzDQo+aW5kZXBlbmRlbnQgYW5kIEFELXNwb25zb3JlZCwg YW5kIHdoaWNoIGlzIGFib3V0IHRvIGNvbWUgb3V0IGFzIFJGQyA0MTY5Lg0KSGVyZSBtYXkgSSBh c2sgb25lIHF1ZXN0aW9uLCBzaW5jZSB0aGVyZSBhcmUgb24gSVBSIHN0YXRlbWVudCBhYm91dCBp dDoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvcHVibGljL2lwcl9kZXRhaWxfc2hvdy5j Z2k/Jmlwcl9pZD01OTENCkluIHRoaXMgY2FzZSwgdGhpcyBkcmFmdCBzdGlsbCBjYW4gYmVjb21l IGFuIGluZm9ybWF0aW9uYWwgUkZDPw0KIA0KVGhhbmtzLA0KIA0KLUh1aQ0KDQogDQo= Disclaimer: The contents of this e-mail, and its attachments, if any, are confidential and may be protected by law against any unauthorized use. If you have received this e-mail by mistake or have reason to believe that you are not the intended recipient, please notify the sender by reply e-mail as soon as possible and delete it from your computer system immediately thereafter. If you are not the intended recipient, you must not copy this e-mail or attachment or disclose the contents to any other person. While we have made every effort to keep our network virus free, we take no responsibility for any computer virus which might be transferred by way of this e-mail. --===============0754236829== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============0754236829==-- From sip-bounces@ietf.org Fri Nov 04 07:57:02 2005 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 1EY17u-0003ly-94; Fri, 04 Nov 2005 07:57:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY17r-0003li-IX for sip@megatron.ietf.org; Fri, 04 Nov 2005 07:57:00 -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 HAA17371 for ; Fri, 4 Nov 2005 07:56:36 -0500 (EST) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EY1Mq-0005er-JC for sip@ietf.org; Fri, 04 Nov 2005 08:12:29 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id jA4Cukhf022147; Fri, 4 Nov 2005 06:56:47 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Fri, 4 Nov 2005 12:56:46 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB0112A1F97@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'DENG, HUI -HCHBJ'" Subject: RE: [Sip] Another Revised agenda for SIP et IETF 64 Date: Fri, 4 Nov 2005 12:56:44 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="utf-8" X-Spam-Score: 1.0 (+) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: "'sip@ietf.org'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I am not sure I understand the concern about IPR here, and would like some clarification. Both IETF and 3GPP2 have broadly similar IPR rules. They both require IPR to be declared. They both allow adoption of solutions that contain IPR. Both organisations specifications are freely available without cost, and no charge is levied to implement the specifications by the organisations concerned. I fail to see the difference. It depends on the decisions of the people adopting the solution as to what is there, and I would suggest that in your document, you have probably already gone far enough in deciding the solution that any IPR owned on the solution would become apparent. As an example, I would note that most of the IPR in IMS comes from the inherited IETF specifications for SIP and associated protocols! regards Keith > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of > DENG, HUI -HCHBJ > Sent: 03 November 2005 15:37 > To: Dean Willis; Binfeng Yan > Cc: sip@ietf.org; Rohan Mahy > Subject: RE: [Sip] Another Revised agenda for SIP et IETF 64 > > > > As defined in RFC3329, four authentication mechanisms is > supported by > > SIP: tls, digest, ipsec-ike, ipsec-man. Currently none of > them support > > CAVE authentication. > > To be honest, I'm not at all sure that a direct > extension to support > CAVE would withstand an IETF security review, although > I'm sure that > our security advisors could say more on that. Those > guys seem to be > deeply paranoid. If there is a retrofit needed to > secure CAVE to the > level that IETF would endorse, I would think that would > be in-scope > for 3GPP2, not IETF. > > ==> Understand your concern here, one intention could be > > there are less IPR issue in IETF than 3GPP2. > > _______________________________________________ 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 From sip-bounces@ietf.org Fri Nov 04 08:04:49 2005 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 1EY1FR-00054i-Gi; Fri, 04 Nov 2005 08:04:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY1FO-00053e-PN; Fri, 04 Nov 2005 08:04:46 -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 IAA18057; Fri, 4 Nov 2005 08:04:23 -0500 (EST) Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EY1UN-0005wX-JC; Fri, 04 Nov 2005 08:20:16 -0500 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 0904AE29; Fri, 4 Nov 2005 14:04:39 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Nov 2005 14:04:04 +0100 Received: from [147.214.34.71] ([147.214.34.71]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Nov 2005 14:04:04 +0100 Message-ID: <436B5C42.3070907@ericsson.com> Date: Fri, 04 Nov 2005 14:04:02 +0100 From: Magnus Westerlund User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Ling, Fan" Subject: Re: [Sip] RE: [Sip-implementors] media description in SDP is for sender or receiver? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Nov 2005 13:04:04.0341 (UTC) FILETIME=[3B908250:01C5E140] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, sip-implementors@cs.columbia.edu, someshss@yahoo.com, IETF AVT WG X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, (cc also AVT as this is an AVT WG matter) It took AVT a long time until actually offer/answer sections started appearing in the RTP payload formats. It is basically only the last year or two that they have been included. In general parameters applies for the stream the offerer/answer wants to receive. However config is a bit problematic. It provides information that concerns the bit-stream that the encoder will send out. Thus config applies from sender to receiver. This is at least spelled out in RFC 3016: "config: This parameter SHALL be used to indicate the configuration of the corresponding MPEG-4 Visual bitstream. It SHALL NOT be used to indicate the codec capability in the capability exchange procedure." So the interpretation I make is the following: profile-level-id in an offer for a sendrecv stream tells the answerer the highest level and profile it may use to send media to the offerer. The config string tells the answerer about the bit-stream it will receive from the offerer. The issue with all parameters that relate to stream properties rather than capabilities or reception configurations that the receiver can determine for the sender is that they are based on assumptions about the other end-points capabilities. The offerer assumes that the answerer is at least as capable as the offerer and can handle the config string. I think it is currently unspecified if the answerer may downgrade the received profile-level-id to a lower capability in its answer. I think that is reasonable, but it do generates some issues in regards to the config string. Because suddenly the config that the offerer provided may no longer be valid. The offerer would be forced to re-invite with a new offer that matches the answerer reception capabilities. If one is interested in how terribly complicated this becomes should take a look at the H.264/MPEG AVC RTP payload format in RFC 3984. RFC 3016 would benefit from an update to include the necessary offer/answer section that describe this. So volunteers are very welcome to start this work. Simply contact the authors and the AVT WG chairs. As the above is my interpretation, if the interpretation made in implementations differ, then that fact should be commented on. Cheers Magnus Westerlund AVT WG Chair Ling, Fan wrote: > > Since the "config=" field in my example is specific configuration for > MPEG4 simple profile video bitstream, its interpretation should "depends > on the parameters", however, I can't find such interpretation in MPEG4 > RTP RFC3016. > -- Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ 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 From sip-bounces@ietf.org Fri Nov 04 10:20:37 2005 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 1EY3Mr-000838-46; Fri, 04 Nov 2005 10:20:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXJng-0000bI-Ew for sip@megatron.ietf.org; Wed, 02 Nov 2005 09:41:16 -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 JAA09747 for ; Wed, 2 Nov 2005 09:40:56 -0500 (EST) From: henry@sinnreich.net Message-Id: <200511021440.JAA09747@ietf.org> Received: from xmail.bluehost.com ([70.98.111.4]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EXK2G-0004Fa-VF for sip@ietf.org; Wed, 02 Nov 2005 09:56:22 -0500 Received: (qmail 8036 invoked by uid 0); 2 Nov 2005 14:41:10 -0000 Received: from unknown (HELO box6.bluehost.com) (70.98.111.61) by xmail.bluehost.com with SMTP; 2 Nov 2005 14:41:10 -0000 Received: from c-24-1-136-53.hsd1.tx.comcast.net ([24.1.136.53] helo=1AB764895C324D3) by box6.bluehost.com with esmtp (Exim 4.52) id 1EXJnP-0007uN-K9; Wed, 02 Nov 2005 07:40:59 -0700 To: , , , Subject: RE: [Sipping] RE: [Sip] unification of wireless technologies Date: Wed, 2 Nov 2005 08:37:16 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcXbhrRLE+OvgQshRJaRQ1w8NsbLGgChqyPAAE26SyA= In-Reply-To: <1270D164D92D2C43A52B99673149BAC9B6A327@scarlitnt642.alltel.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-PopBeforeSMTPSenders: henry@sinnreich.net X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box6.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - sinnreich.net X-Spam-Score: 2.9 (++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 04 Nov 2005 10:20:35 -0500 Cc: ddunn@kyocera-wireless.com, ddunn@ktrc-na.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Bjorn's question is really very critical: >When you are referring to "unification," is your question related to the >ability of the core network to authenticate a user and deliver a VoIP >service independent of access technology or the ability for a device >access multiple air interface technologies to support VoIP? Media Independent Handover (MIH) in 802.21 supports both models and this show's the IEEE will support both "network based" control and endpoint control in agreement with the e2e principle of the Internet. Let's hope the IETF can also support the Internet e2e architecture :-) Thanks, Henry -----Original Message----- From: Bjorn.Hjelm@alltel.com [mailto:Bjorn.Hjelm@alltel.com] Sent: Monday, October 31, 2005 3:55 PM To: digambar@kyocera-wireless.com; sip@ietf.org; sipping@ietf.org Cc: ddunn@kyocera-wireless.com; ddunn@ktrc-na.com Subject: [Sipping] RE: [Sip] unification of wireless technologies Digambar, When you are referring to "unification," is your question related to the ability of the core network to authenticate a user and deliver a VoIP service independent of access technology or the ability for a device access multiple air interface technologies to support VoIP? BR, Bjorn _______________________________________________ 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 From sip-bounces@ietf.org Fri Nov 04 10:51:07 2005 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 1EY3qN-0006GY-Hq; Fri, 04 Nov 2005 10:51:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY3qL-0006GS-L4 for sip@megatron.ietf.org; Fri, 04 Nov 2005 10:51:05 -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 KAA26832 for ; Fri, 4 Nov 2005 10:50:41 -0500 (EST) Received: from mail.pingtel.com ([65.220.123.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EY45L-0002Di-St for sip@ietf.org; Fri, 04 Nov 2005 11:06:37 -0500 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id 95B7D6C017 for ; Fri, 4 Nov 2005 10:50:55 -0500 (EST) Subject: Re: [Sip] Re: Dialogs vs Dialog Usages From: "Dale R. Worley" To: Sip In-Reply-To: <43485374.2070608@cisco.com> References: <4346BCB9.7050505@cisco.com> <1128725134.15737.145.camel@cdhcp139.pingtel.com> <43470130.3030003@cisco.com> <1128799316.21489.4.camel@cdhcp139.pingtel.com> <43485374.2070608@cisco.com> Content-Type: text/plain Date: Fri, 04 Nov 2005 10:50:55 -0500 Message-Id: <1131119455.14505.4.camel@cdhcp139.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-6) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Sat, 2005-10-08 at 19:17 -0400, Paul Kyzivat wrote: > Dale R. Worley wrote: > > True, the difference is not absolute. But in an INVITE situation, the > > proxies attempt to prevent the establishment of more than one confirmed > > dialog, whereas in a SUBSCRIBE situation, they are forbidden from trying > > to prune the set of dialogs. > > They are? That is news to me. Where is that specified? After checking around, I think I have to say I'm wrong there. (Although I think I could make a strong case that forking of non-INVITE requests would be a lot more useful if the proxies didn't treat them the same way as INVITEs.) I have to think about this more... Dale _______________________________________________ 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 From sip-bounces@ietf.org Fri Nov 04 12:18:49 2005 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 1EY57F-0003sZ-LO; Fri, 04 Nov 2005 12:12:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY579-0003rz-VX; Fri, 04 Nov 2005 12:12:32 -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 MAA01762; Fri, 4 Nov 2005 12:12:07 -0500 (EST) Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EY5M9-0004dq-OR; Fri, 04 Nov 2005 12:28:04 -0500 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id jA4HBpGe014257 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 4 Nov 2005 09:11:52 -0800 Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id jA4HBmv9002055; Fri, 4 Nov 2005 09:11:49 -0800 (PST) Received: from NAEX08.na.qualcomm.com ([10.46.56.94]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 4 Nov 2005 09:11:48 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] RE: [Sip-implementors] media description in SDP is for sender or receiver? Date: Fri, 4 Nov 2005 09:11:47 -0800 Message-ID: Thread-Topic: [Sip] RE: [Sip-implementors] media description in SDP is for sender or receiver? Thread-Index: AcXhQFi4EMU6Ng/WRWiMarbVOVEf+QAIPWmw From: "Ling, Fan" To: "Magnus Westerlund" X-OriginalArrivalTime: 04 Nov 2005 17:11:48.0611 (UTC) FILETIME=[D75C1D30:01C5E162] X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org, sip-implementors@cs.columbia.edu, someshss@yahoo.com, IETF AVT WG X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Magnus, You are dead on on the issues we are concerned about. Initially, our understanding is the same as yours. However, when we proceed from one-to-one video telephony application to multiparty video conference application, the same understanding brings in some trouble. Let's assume "MPEG4 simple profile level 1" is the negotiated codec.=20 In one-to-one video telephony, both ends can use different video sending parameters, that is, "config=3D" or VOL parameters, both ends decoder = just configure itself to the incoming video bitstream's setting. In multiparty conference, this means any one terminal has to configure its multiple decoders according to different incoming bitstreams. This makes the system a lot more complicated. That's why we are coming back to the standards, to see whether there is a rule that dictates that not only the codec type needs to be the same, the video bitstream parameters (VOL) also needs to be the same for both encoder and decoder. Your suggestion/advice is greatly appreciated. Fan -----Original Message----- From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 Sent: Friday, November 04, 2005 5:04 AM To: Ling, Fan Cc: someshss@yahoo.com; sip-implementors@cs.columbia.edu; sip@ietf.org; IETF AVT WG Subject: Re: [Sip] RE: [Sip-implementors] media description in SDP is for sender or receiver? Hi, (cc also AVT as this is an AVT WG matter) It took AVT a long time until actually offer/answer sections started=20 appearing in the RTP payload formats. It is basically only the last year or two that they have been included. In general parameters applies for the stream the offerer/answer wants to receive. However config is a bit problematic. It provides information=20 that concerns the bit-stream that the encoder will send out. Thus config applies from sender to receiver. This is at least spelled out in RFC 3016: "config: This parameter SHALL be used to indicate the configuration of the corresponding MPEG-4 Visual bitstream. It SHALL NOT be used to indicate the codec capability in the capability exchange procedure." So the interpretation I make is the following: profile-level-id in an offer for a sendrecv stream tells the answerer=20 the highest level and profile it may use to send media to the offerer. The config string tells the answerer about the bit-stream it will=20 receive from the offerer. The issue with all parameters that relate to stream properties rather=20 than capabilities or reception configurations that the receiver can=20 determine for the sender is that they are based on assumptions about the other end-points capabilities. The offerer assumes that the answerer is=20 at least as capable as the offerer and can handle the config string. I think it is currently unspecified if the answerer may downgrade the=20 received profile-level-id to a lower capability in its answer. I think=20 that is reasonable, but it do generates some issues in regards to the=20 config string. Because suddenly the config that the offerer provided may no longer be valid. The offerer would be forced to re-invite with a new=20 offer that matches the answerer reception capabilities. If one is interested in how terribly complicated this becomes should=20 take a look at the H.264/MPEG AVC RTP payload format in RFC 3984. RFC 3016 would benefit from an update to include the necessary=20 offer/answer section that describe this. So volunteers are very welcome=20 to start this work. Simply contact the authors and the AVT WG chairs. As the above is my interpretation, if the interpretation made in=20 implementations differ, then that fact should be commented on. Cheers Magnus Westerlund AVT WG Chair Ling, Fan wrote: >=20 > Since the "config=3D" field in my example is specific configuration = for > MPEG4 simple profile video bitstream, its interpretation should "depends > on the parameters", however, I can't find such interpretation in MPEG4 > RTP RFC3016. >=20 --=20 Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ 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 From sip-bounces@ietf.org Fri Nov 04 12:47:06 2005 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 1EY5eb-0003hS-SU; Fri, 04 Nov 2005 12:47:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY5eY-0003gx-U2 for sip@megatron.ietf.org; Fri, 04 Nov 2005 12:47:03 -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 MAA03880 for ; Fri, 4 Nov 2005 12:46:40 -0500 (EST) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EY5ta-0005cy-C5 for sip@ietf.org; Fri, 04 Nov 2005 13:02:35 -0500 Received: from [64.101.149.214] (deanwillis-comp.cisco.com [64.101.149.214]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id jA4Hq2xT016660 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 4 Nov 2005 11:52:04 -0600 In-Reply-To: <1131077745.8991.9.camel@cdhcp139.pingtel.com> References: <0F7F6BB4-1B10-4882-B037-F25DC704133B@softarmor.com> <1131077745.8991.9.camel@cdhcp139.pingtel.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <59DC0BFF-E04C-4CBE-B414-6BA8D9620294@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Possible flaw in SIP Change process RFC 3427 Date: Fri, 4 Nov 2005 11:46:46 -0600 To: "Dale R. Worley" X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: Sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Nov 3, 2005, at 10:15 PM, Dale R. Worley wrote: > On Thu, 2005-11-03 at 21:12 -0600, Dean Willis wrote: >> It seems that anytime we do a mapping between an IETF protocol and >> some "foreign" protocol, even in something that's just a "usage >> convention", we have to be very careful. This is something that's >> hard to do correctly, and potentially politically charged due to >> relations between IETF and the standards bodies responsible for the >> "foreign" protocol. >> >> Should we document this as an errata for RFC 3427, or what? > > If we have evidence that unpleasant mistakes have been made in this > area, it's worth flagging as a potential trouble area. But I assume > that you also have some idea of advice or even rules (of thumb) as to > how this problem can be resolved, which is what would be a valuable > addition to 3427. > I just made a mistake with the voicemail URI draft. I try to learn from my mistakes occasionally. The rule of thumb I would suggest is probably "Any SIP-related RFC that specifies a mapping between an IETF protocol and an external protocol MUST be broadly reviewed, at least to the level of IETF Consensus as defined in RFC 2434 and preferably to the level of a standards-track RFC." -- Dean _______________________________________________ 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 From sip-bounces@ietf.org Fri Nov 04 12:49:55 2005 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 1EY5hL-0004Wq-FH; Fri, 04 Nov 2005 12:49:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY5hJ-0004Wl-CH for sip@megatron.ietf.org; Fri, 04 Nov 2005 12:49:53 -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 MAA04059 for ; Fri, 4 Nov 2005 12:49:30 -0500 (EST) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EY5wL-0005je-US for sip@ietf.org; Fri, 04 Nov 2005 13:05:26 -0500 Received: from [64.101.149.214] (deanwillis-comp.cisco.com [64.101.149.214]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id jA4Ht7jM016690 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 4 Nov 2005 11:55:08 -0600 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <37D35F9A-00A1-4455-BAED-22FBB0784FB5@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] GRUU (was Whats wrong with Supported. (was: Alert-Info Idea) Date: Fri, 4 Nov 2005 11:49:50 -0600 To: Sean Olson X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: Sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Nov 3, 2005, at 6:57 PM, Sean Olson wrote: > Well, if GRUU == Globally Routable UA URI, and you treat a URI as a > GRUU which does not have one of these properties, things will > break. If > you care when things break, you would want to know in advance. This > would apply to UAs, proxies, etc. You could make the argument that all > URIs should be GRUUs so what you really want is a property that says a > URI is *not* at a GRUU and assume all others are ;-) So, exactly what do you do differently if you think something might not be GRUU? You've been given this URI. Don't you just have to try it and see if it works, and if not then back off to some other behavior? Remember, there's really no such thing as an absolutely universally reachable URI. It might b a URI on the public internet that your corp firewall has decided to block. It might just stop working between the time you get it and the time you try to use it. The Net might partition in between you. And so on. -- Dean _______________________________________________ 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 From sip-bounces@ietf.org Fri Nov 04 12:54:31 2005 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 1EY5ln-0005s6-KY; Fri, 04 Nov 2005 12:54:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY5lk-0005rN-2x for sip@megatron.ietf.org; Fri, 04 Nov 2005 12:54:28 -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 MAA04446 for ; Fri, 4 Nov 2005 12:54:05 -0500 (EST) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EY60m-0005sZ-LL for sip@ietf.org; Fri, 04 Nov 2005 13:10:01 -0500 Received: from [64.101.149.214] (deanwillis-comp.cisco.com [64.101.149.214]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id jA4HxRS8016722 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 4 Nov 2005 11:59:28 -0600 In-Reply-To: <834B54D356AA8F46B9B233DD88BEAA38BC698F@hcbjdc2> References: <834B54D356AA8F46B9B233DD88BEAA38BC698F@hcbjdc2> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0C8D60A7-2AC0-4A9E-994F-AE2D112F945B@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Another Revised agenda for SIP et IETF 64 Date: Fri, 4 Nov 2005 11:54:11 -0600 To: "DENG, HUI -HCHBJ" X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, Rohan Mahy , Allison Mankin X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Nov 4, 2005, at 2:12 AM, DENG, HUI -HCHBJ wrote: > > We are also not familiar with AD-sponsored document, does that means > this document could become independent document out of any working > group? > excuse us naive question. > It's a procedure defined in RFC 3932, which modifies the procedure of RFC 2026. It allows for ADs to sponsor informational documents that are not in the scope of a specific working group, get the mIESG reviewed, and published as RFCs. It's preferred over direct-to-RFC-ed individual informationals because there is still IESG review over these documents and an opportunity for public debate that is not inherent with the direct-to-RFCed process of RFC 2026. >> I'd do one Informational document that is AD sponsored, a non-SIP >> Informational, >> similar in content to draft-torvinen-http-digest-aka-v2-02.txt, >> which was >> independent and AD-sponsored, and which is about to come out as >> RFC 4169. > Here may I ask one question, since there are on IPR statement about > it: > https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=591 > In this case, this draft still can become an informational RFC? While the IETF generally prefers approaches that are not IPR encumbered, the presence of an IPR claim does not generally prevent publication as an informational document. -- Dean Willis SIP co-chair _______________________________________________ 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 From sip-bounces@ietf.org Fri Nov 04 13:13:48 2005 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 1EY64R-00015X-VF; Fri, 04 Nov 2005 13:13:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY64P-00015R-UN for sip@megatron.ietf.org; Fri, 04 Nov 2005 13:13:46 -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 NAA05240 for ; Fri, 4 Nov 2005 13:13:23 -0500 (EST) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EY6JQ-0006K2-Io for sip@ietf.org; Fri, 04 Nov 2005 13:29:18 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Fri, 4 Nov 2005 10:13:33 -0800 Received: from red-hub-04.redmond.corp.microsoft.com ([157.54.3.6]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Nov 2005 10:13:33 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Nov 2005 10:13:33 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.89]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Nov 2005 10:13:32 -0800 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] GRUU (was Whats wrong with Supported. (was: Alert-Info Idea) Date: Fri, 4 Nov 2005 10:15:13 -0800 Message-ID: Thread-Topic: [Sip] GRUU (was Whats wrong with Supported. (was: Alert-Info Idea) thread-index: AcXhaDma6kIVKx9fR4mTH6yfyLvrmwAAxYiw From: "Sean Olson" To: "Dean Willis" X-OriginalArrivalTime: 04 Nov 2005 18:13:32.0885 (UTC) FILETIME=[77477850:01C5E16B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: quoted-printable Cc: Sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Very true. You can always try, fail, then take appropriate steps. I'm just talking about short circuiting the failure. You don't know that a GRUU will succeed, but you have a fairly high level of confidence that a non-GRUU will fail. I really hope that this becomes the 1% case with 99% of URIs are GRUUs. With that long term goal in mind, I'd prefer to signal that something is not a GRUU rather than always have to signal that it is one.=20 -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com]=20 Sent: Friday, November 04, 2005 9:50 AM To: Sean Olson Cc: Jeroen van Bemmel; Sip Subject: Re: [Sip] GRUU (was Whats wrong with Supported. (was: Alert-Info Idea) On Nov 3, 2005, at 6:57 PM, Sean Olson wrote: > Well, if GRUU =3D=3D Globally Routable UA URI, and you treat a URI as = a=20 > GRUU which does not have one of these properties, things will break.=20 > If you care when things break, you would want to know in advance. This > would apply to UAs, proxies, etc. You could make the argument that all > URIs should be GRUUs so what you really want is a property that says a > URI is *not* at a GRUU and assume all others are ;-) So, exactly what do you do differently if you think something might not be GRUU? You've been given this URI. Don't you just have to try it and see if it works, and if not then back off to some other behavior? Remember, there's really no such thing as an absolutely universally reachable URI. It might b a URI on the public internet that your corp firewall has decided to block. It might just stop working between the time you get it and the time you try to use it. The Net might partition in between you. And so on. -- Dean _______________________________________________ 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 From sip-bounces@ietf.org Fri Nov 04 13:34:39 2005 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 1EY6Oc-0004Fp-RD; Fri, 04 Nov 2005 13:34:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY6Oa-0004Dp-5H for sip@megatron.ietf.org; Fri, 04 Nov 2005 13:34:36 -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 NAA06275 for ; Fri, 4 Nov 2005 13:34:13 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EY6dd-0006tZ-2w for sip@ietf.org; Fri, 04 Nov 2005 13:50:09 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 04 Nov 2005 10:34:26 -0800 X-IronPort-AV: i="3.97,292,1125903600"; d="scan'208"; a="672004970:sNHT25725882" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jA4IXlPZ012762; Fri, 4 Nov 2005 10:34:24 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 4 Nov 2005 10:34:22 -0800 Received: from [10.89.16.56] ([10.89.16.56]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 4 Nov 2005 10:34:22 -0800 Message-ID: <436BA9AD.1010808@cisco.com> Date: Fri, 04 Nov 2005 13:34:21 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] GRUU (was Whats wrong with Supported. References: <37D35F9A-00A1-4455-BAED-22FBB0784FB5@softarmor.com> In-Reply-To: <37D35F9A-00A1-4455-BAED-22FBB0784FB5@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Nov 2005 18:34:22.0406 (UTC) FILETIME=[600D3E60:01C5E16E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Cc: Sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Dean - see below. Paul Dean Willis wrote: > > On Nov 3, 2005, at 6:57 PM, Sean Olson wrote: > >> Well, if GRUU == Globally Routable UA URI, and you treat a URI as a >> GRUU which does not have one of these properties, things will break. If >> you care when things break, you would want to know in advance. This >> would apply to UAs, proxies, etc. You could make the argument that all >> URIs should be GRUUs so what you really want is a property that says a >> URI is *not* at a GRUU and assume all others are ;-) > > > > So, exactly what do you do differently if you think something might not > be GRUU? > > You've been given this URI. Don't you just have to try it and see if it > works, and if not then back off to some other behavior? There is an example in section 6.3 of draft-ietf-sipping-cc-transfer-05: If the Contact URI of the Transfer Target is a GRUU (Globally Routable User Agent URI) GRUU [5] then the Transferee SHOULD use that URI as the Refer-To URI. If the Contact URI is not known to be a GRUU (Supported: gruu is not present), then the Address of Record (AOR) of the Transfer Target should be used. That is, the same URI that the Transferee used to establish the session with the Transfer Target should be used. In case the triggered INVITE is routed to a different User Agent than the Transfer Target, the Require: replaces header field should be used in the triggered INVITE. (This is to prevent an incorrect User Agent which does not support Replaces from ignoring the Replaces and answering the INVITE without a dialog match.) > Remember, there's really no such thing as an absolutely universally > reachable URI. It might b a URI on the public internet that your corp > firewall has decided to block. It might just stop working between the > time you get it and the time you try to use it. The Net might partition > in between you. And so on. > > -- > Dean > > > _______________________________________________ > 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 From sip-bounces@ietf.org Fri Nov 04 18:09:30 2005 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 1EYAgc-0007If-1u; Fri, 04 Nov 2005 18:09:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYAga-0007I0-2A for sip@megatron.ietf.org; Fri, 04 Nov 2005 18:09:28 -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 SAA20187 for ; Fri, 4 Nov 2005 18:09:03 -0500 (EST) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYAve-0005s3-3q for sip@ietf.org; Fri, 04 Nov 2005 18:25:03 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id jA4N98aT002119; Fri, 4 Nov 2005 17:09:08 -0600 (CST) Received: from [135.185.173.147] (il0015vkg1.ih.lucent.com [135.185.173.147]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id jA4N97L27826; Fri, 4 Nov 2005 17:09:07 -0600 (CST) Message-ID: <436BEA14.8010302@lucent.com> Date: Fri, 04 Nov 2005 17:09:08 -0600 From: "Vijay K. Gurbani" Organization: Wireless Networks Research and Development User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis , Rohan Mahy Subject: Re: [Sip] WGLC for draft-ietf-sip-connect-reuse-04.txt References: <312FA63B-E9F0-453D-8DF5-853CB7056A42@softarmor.com> In-Reply-To: <312FA63B-E9F0-453D-8DF5-853CB7056A42@softarmor.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: b360bd6cb019c35178e5cf9eeb747a5c Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1399892787==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1399892787== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080806090202080204070803" This is a cryptographically signed message in MIME format. --------------ms080806090202080204070803 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dean Willis wrote: > I'd like to go ahead and start WGLC for the connection reuse draft. > This is on the proposed SIP re-charter with a November deliverable, so > we need to get moving on it. Dean, Rohan: Here are my WGLC comments for connect-reuse-04. They are organized such that substantitive comments come first, followed by nits. 1) The whole issue of "Directional Connectivity" in Section 2.2 is best left to the outbound draft. Currently it is discussed in detail under the high order heading of "Problem Statement (Section 2)." But connect-reuse does not solve this particular problem; so I think it is best to take Section 2.2 out, and instead, put it in the outbound I-D. The outbound I-D does not have a "Problem Statement" section and I think that it will benefit handsomely from this swap. Ditto for the last paragraph in "Clustering" Section 2.3. This paragraph is best put in the outbound I-D "Problem Statement" section. 2) In Section 4, where the interaction of DNS and "alias" is described, I believe that the use of "alias" leads to starvation of other servers in a proxy farm since we have established an affinity with a particular server. Let me explain. If within the Priority field of SRV RRs, the Weight fields are the same (as is the example), then there will arise a situation where the "alias" parameter will lead to the starvation of other servers in a proxy farm. Under normal circumstances, since the Weight field of the SRV RRs is the same, traffic should be distributed equally. If instead, because of the "alias" parameter, we do not use SRV, then only one host from the proxy farm gets bombasted with *all* the traffic, effectively inhibiting load distribution through SRV. Do you see this as a problem? 3) In Section 3 "Requirements", Requirement 1 -- I am not sure why we are worried about responses. Responses tend to use the same connection over which the request was sent (based on rfc3261). It is subsequent requests in the opposite direction, and to a lesser extent subsequent requests in the same direction that are a problem. 4) In Step 3 of Section 4.1.1, define "advertised name". I think you take this to mean what is in the sent-by production rule. In other words: Via: SIP/2.0/TCP proxy-farm-a.example.com; ... Here, "proxy-farm-a.example.com" is the "advertised name" ... yes? 5) I think a little bit more explanation around the example that follows the 4 steps in Section 4.1.1 will help implementors in gauging the intent. Something as simple as replicating the Via string mentioned before (i.e., Via: SIP/2.0/TLS proxy-farm-a.example.com;branch=z9hG4bK7c8ze;alias; received=10.54.32.2) will add some more understanding to the example. Nits: 1) Section 2 s/connections instead using the/connections instead, using the 2) Section 2.1: I would suggest a vertical time-line diagram is appropriate for the call flow. Something like: Proxy A Proxy B | | Create connection 1 +---INV--->| | | |<---200---+ Response over connection 1 | | Re-use connection 1 +---ACK--->| | | = = | | |<---BYE---+ Create connection 2 | | Response over +---200--->| connection 2 3) Section 4.1.1: s/Finally, Verify/Finally, verify 4) Section 4.1.1: s/For example, take the example/Take the example 5) Label the figure in Section 4. Change naming conventions in it to reflect "a1" and "a2" (which are used in the text) instead of "A1" and "A2" (used only in the figure). Also, consider naming the boxes on the left hand side as "host-a1.example.com" and "host-a2.example.com". 6) Section 4 says that "The originator places their alias in the Via header field value (in the sent-by production)." Pedantically speaking the "alias" is not in the sent-by production rule but rather in the via-parms, as Section 4.2 accurately reflects. 7) Is it okay to use 10.0.0.0 addresses as examples? I have learned that as per rfc3330, the 192.0.2.0/24 is what we should be using in documentation and example code. Thanks, - vijay -- Vijay K. Gurbani, Ph.D. vkg@{lucent.com,research.bell-labs.com,acm.org} Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 --------------ms080806090202080204070803 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIkNjCC CZowggiCoAMCAQICChq5SpYAAAAABscwDQYJKoZIhvcNAQEFBQAwgbIxJTAjBgkqhkiG9w0B CQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5jb20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcg SmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkgSGlsbDEcMBoGA1UEChMTTHVjZW50IFRlY2hub2xv Z2llczEzMDEGA1UEAxMqTHVjZW50IFRlY2hub2xvZ2llcyBDZXJ0aWZpY2F0ZSBTZXJ2aWNl cyAxMB4XDTA0MDYyMzIwMDM0MVoXDTA2MDYyMzIwMTM0MVowQTEdMBsGCSqGSIb3DQEJARYO dmtnQGx1Y2VudC5jb20xIDAeBgNVBAMTF1ZpamF5IEsgR3VyYmFuaSAoVmlqYXkpMIGfMA0G CSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8/1oQRIU0sF4rsiC0F6mQu6TSvQPCRl6BObQcR58a 5swju1dVwTz3XbON9p5qjYRqxm9d+OX7W2Bj68dxlYUTz5yp9KkwH7hNLVTy09E3dwdZM36L +7ICKUK9M6YU64MJAGTg1tTxUIxflKy0SMCPJIldiEp/JrXYb2aVhmW8tQIDAQABo4IGpDCC BqAwHQYDVR0OBBYEFFG9/4w6CpUIC+mXdQWpWuBH+nkbMIH+BgNVHSMEgfYwgfOAFISfQVWc EIhPO03ThDp+IUtPSt/LoYHOpIHLMIHIMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5s dWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxML TXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxHDAaBgNVBAsTE0x1 Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1Y2VudCBUZWNobm9sb2dpZXMgUm9vdCBB dXRob3JpdHmCCmEMFx0AAAAAAAUwEwYKCZImiZPyLGQBAQQFFgN2a2cwFwYKCZImiZPyLGQB LAQJFgczNzA5NDM4MBEGCWCGSAGG+EIBAQQEAwIFoDALBgNVHQ8EBAMCA/gwJwYDVR0lBCAw HgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDBzCCAncGCCsGAQUFBwEBBIICaTCCAmUw gc4GCCsGAQUFBzAChoHBbGRhcDovL2xkYXAtdXNlYXN0LnBvc3QubHVjZW50LmNvbS9jbj1M dWNlbnQlMjBUZWNobm9sb2dpZXMlMjBDZXJ0aWZpY2F0ZSUyMFNlcnZpY2VzJTIwMSxvdT1D ZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NhY2VydGlmaWNhdGU7 YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBwgYIKwYB BQUHMAKGgbVsZGFwOi8vbGRhcC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2ll cyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRo b3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3Rj bGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHMBggrBgEFBQcwAoaBv2xkYXA6Ly9sZGFw LWVtZWEucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRp ZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxv PWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0 aWZpY2F0aW9uQXV0aG9yaXR5MIICigYDVR0fBIICgTCCAn0wgdaggdOggdCGgc1sZGFwOi8v bGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUy MENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3Jp dGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFz ZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHKoIHHoIHEhoHBbGRhcDov L2xkYXAubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBDZXJ0aWZpY2F0 ZSUyMFNlcnZpY2VzJTIwMSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNl bnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xh c3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCB1KCB0aCBzoaBy2xkYXA6Ly9sZGFwLWVtZWEu cG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRl JTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2Vu dC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZT9vYmplY3RjbGFz cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MA0GCSqGSIb3DQEBBQUAA4IBAQBZ1m98/KuOGemr fAEgtDWIiZjKEN3ShsKT3bfKvjw/zSOtL2UpwNab9xqHKdV9rt4O0wzx6By/0JY/hCQrPMAm YCO0Xo14fC8OSzRkRl1kSPn0E+v8vD+dn42a+dBdmN2SD56jg7/EkvifgaCw9n/HMi4vXcOS +RUdxZkPRnYLyh4GiocnBx88IQEzWK9shMLzC7gm3K6V6kggUSchxR703OHNTLb7XKeEDzSX LdXMVHA5N89xTQGyVWk8Mc6fO7icn0LthC81Ig0/M6v12Vmb2+Tdq7aB7ZVgaU95f/eezcHh LgaYlutde9q6s+c8ok8/hI2VBcGMt85Apf5GAktoMIIJmjCCCIKgAwIBAgIKGrlKlgAAAAAG xzANBgkqhkiG9w0BAQUFADCBsjElMCMGCSqGSIb3DQEJARYWY2FAc2VjdXJpdHkubHVjZW50 LmNvbTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC011cnJh eSBIaWxsMRwwGgYDVQQKExNMdWNlbnQgVGVjaG5vbG9naWVzMTMwMQYDVQQDEypMdWNlbnQg VGVjaG5vbG9naWVzIENlcnRpZmljYXRlIFNlcnZpY2VzIDEwHhcNMDQwNjIzMjAwMzQxWhcN MDYwNjIzMjAxMzQxWjBBMR0wGwYJKoZIhvcNAQkBFg52a2dAbHVjZW50LmNvbTEgMB4GA1UE AxMXVmlqYXkgSyBHdXJiYW5pIChWaWpheSkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB ALz/WhBEhTSwXiuyILQXqZC7pNK9A8JGXoE5tBxHnxrmzCO7V1XBPPdds432nmqNhGrGb134 5ftbYGPrx3GVhRPPnKn0qTAfuE0tVPLT0Td3B1kzfov7sgIpQr0zphTrgwkAZODW1PFQjF+U rLRIwI8kiV2ISn8mtdhvZpWGZby1AgMBAAGjggakMIIGoDAdBgNVHQ4EFgQUUb3/jDoKlQgL 6Zd1Bala4Ef6eRswgf4GA1UdIwSB9jCB84AUhJ9BVZwQiE87TdOEOn4hS09K38uhgc6kgcsw gcgxJTAjBgkqhkiG9w0BCQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5jb20xCzAJBgNVBAYTAlVT MRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkgSGlsbDEcMBoGA1UEChMT THVjZW50IFRlY2hub2xvZ2llczEcMBoGA1UECxMTTHVjZW50IFRlY2hub2xvZ2llczErMCkG A1UEAxMiTHVjZW50IFRlY2hub2xvZ2llcyBSb290IEF1dGhvcml0eYIKYQwXHQAAAAAABTAT BgoJkiaJk/IsZAEBBAUWA3ZrZzAXBgoJkiaJk/IsZAEsBAkWBzM3MDk0MzgwEQYJYIZIAYb4 QgEBBAQDAgWgMAsGA1UdDwQEAwID+DAnBgNVHSUEIDAeBggrBgEFBQcDAgYIKwYBBQUHAwQG CCsGAQUFBwMHMIICdwYIKwYBBQUHAQEEggJpMIICZTCBzgYIKwYBBQUHMAKGgcFsZGFwOi8v bGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUy MENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3Jp dGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFz cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHCBggrBgEFBQcwAoaBtWxkYXA6Ly9sZGFwLmx1 Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2 aWNlcyUyMDEsb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9j YWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRo b3JpdHkwgcwGCCsGAQUFBzAChoG/bGRhcDovL2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20v Y249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEs b3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmlj YXRlO2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwggKK BgNVHR8EggKBMIICfTCB1qCB06CB0IaBzWxkYXA6Ly9sZGFwLXVzZWFzdC5wb3N0Lmx1Y2Vu dC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNl cyUyMDEsb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0 aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmlj YXRpb25BdXRob3JpdHkwgcqggceggcSGgcFsZGFwOi8vbGRhcC5sdWNlbnQuY29tL2NuPUx1 Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNl cnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZv Y2F0aW9ubGlzdDtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9y aXR5MIHUoIHRoIHOhoHLbGRhcDovL2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVj ZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEsb3U9Q2Vy dGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9j YXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3Jp dHkwDQYJKoZIhvcNAQEFBQADggEBAFnWb3z8q44Z6at8ASC0NYiJmMoQ3dKGwpPdt8q+PD/N I60vZSnA1pv3Gocp1X2u3g7TDPHoHL/Qlj+EJCs8wCZgI7RejXh8Lw5LNGRGXWRI+fQT6/y8 P52fjZr50F2Y3ZIPnqODv8SS+J+BoLD2f8cyLi9dw5L5FR3FmQ9GdgvKHgaKhycHHzwhATNY r2yEwvMLuCbcrpXqSCBRJyHFHvTc4c1Mtvtcp4QPNJct1cxUcDk3z3FNAbJVaTwxzp87uJyf Qu2ELzUiDT8zq/XZWZvb5N2rtoHtlWBpT3l/957NweEuBpiW61172rqz5zyiTz+EjZUFwYy3 zkCl/kYCS2gwghD2MIIP3qADAgECAgphDBcdAAAAAAAFMA0GCSqGSIb3DQEBBQUAMIHIMSUw IwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEG A1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2Vu dCBUZWNobm9sb2dpZXMxHDAaBgNVBAsTE0x1Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMT Ikx1Y2VudCBUZWNobm9sb2dpZXMgUm9vdCBBdXRob3JpdHkwHhcNMDAxMjA2MTYyNjQ1WhcN MTAxMjA2MTYzNjQ1WjCBsjElMCMGCSqGSIb3DQEJARYWY2FAc2VjdXJpdHkubHVjZW50LmNv bTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC011cnJheSBI aWxsMRwwGgYDVQQKExNMdWNlbnQgVGVjaG5vbG9naWVzMTMwMQYDVQQDEypMdWNlbnQgVGVj aG5vbG9naWVzIENlcnRpZmljYXRlIFNlcnZpY2VzIDEwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCrbIc03eHms6QdVIh5h01zu8+SHMLFNRPuo3EVY8dgvQsy1pM5DSOtjDt+ JXW723615PF8cVgDVUQGE4D9T9k5B2DP3DUhtrsvH3SEKJL6NceqgWDhLzgf0JjhNdid9IHE x5xRWAiONeeLiRcScIZyRgANiokhSaM5VM2tZBctDFWrXkqxRUHvSSlWXMoXh7HYBOfEjhfJ E3BGQTOX0HOFKkCNS3CDh7ZAwNnw4Ntgkf+8bOqAzmX1ToyZbFLn7bZ9rNFg3gcDzyoFD46C ZQsibysVefigRA57WfouqpbgZ8JzIAmXAeaJLSRgutALT5beOyx75TNPdglVhKlHg4MLAgMB AAGjggz0MIIM8DAQBgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUhJ9BVZwQiE87TdOEOn4h S09K38swCwYDVR0PBAQDAgHGMA8GA1UdEwEB/wQFMAMBAf8wggEEBgNVHSMEgfwwgfmAFG/h K1C+quh9NWJpDO7LUuiSAjxdoYHOpIHLMIHIMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0 eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UE BxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxHDAaBgNVBAsT E0x1Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1Y2VudCBUZWNobm9sb2dpZXMgUm9v dCBBdXRob3JpdHmCEFmZihipVMC2QAXNTB3ruM8wggXfBgNVHR8EggXWMIIF0jCBzKCByaCB xoaBw2xkYXA6Ly9sZGFwLXVzZWFzdC5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVj aG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9y aXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jh c2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBzKCByaCBxoaBw2xkYXA6 Ly9sZGFwLXVzd2VzdC5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVz JTIwUm9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1s dWNlbnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0 Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCByaCBxqCBw4aBwGxkYXA6Ly9sZGFwLmV4 dGVybmFsLmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1 dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2Nl cnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlm aWNhdGlvbkF1dGhvcml0eTCBz6CBzKCByYaBxmxkYXA6Ly9sZGFwLXVzY2VudHJhbC5wb3N0 Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0 eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmlj YXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlv bkF1dGhvcml0eTCByqCBx6CBxIaBwWxkYXA6Ly9sZGFwLWVtZWEucG9zdC5sdWNlbnQuY29t L2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlm aWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRp b25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkw gcqggceggcSGgcFsZGFwOi8vbGRhcC1jYWxhLnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQl MjBUZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBB dXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5h cnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHIoIHFoIHChoG/ bGRhcDovL2xkYXAtYXAucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2ll cyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89 bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVj dGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwL6AtoCuGKWh0dHA6Ly93d3cuc2VjdXJp dHkubHVjZW50LmNvbS9jYS9jYTEuY3JsMIIFsgYIKwYBBQUHAQEEggWkMIIFoDCBxAYIKwYB BQUHMAKGgbdsZGFwOi8vbGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUy MFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1 dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVj dGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcQGCCsGAQUFBzAChoG3bGRhcDovL2xk YXAtdXN3ZXN0LnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBS b290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2Vu dC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0 aW9uQXV0aG9yaXR5MIHBBggrBgEFBQcwAoaBtGxkYXA6Ly9sZGFwLmV4dGVybmFsLmx1Y2Vu dC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1D ZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NhY2VydGlmaWNhdGU7 YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBxwYIKwYB BQUHMAKGgbpsZGFwOi8vbGRhcC11c2NlbnRyYWwucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2Vu dCUyMFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUy MEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29i amVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcIGCCsGAQUFBzAChoG1bGRhcDov L2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIw Um9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNl bnQuY29tP2NhY2VydGlmaWNhdGU7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNh dGlvbkF1dGhvcml0eTCBwgYIKwYBBQUHMAKGgbVsZGFwOi8vbGRhcC1jYWxhLnBvc3QubHVj ZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91 PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0 ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHABggr BgEFBQcwAoaBs2xkYXA6Ly9sZGFwLWFwLnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBU ZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRo b3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3Rj bGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MDUGCCsGAQUFBzAChilodHRwOi8vd3d3LnNl Y3VyaXR5Lmx1Y2VudC5jb20vY2EvY2ExLmNydDANBgkqhkiG9w0BAQUFAAOCAQEAObP5Urds B2nOxTrekCTXpBxKF4K0t8Doi/zHhUuupK+Bc5ppNu9dqYeGr1bKNLRbF/hccvzn4xuj3o82 gm7eZee7lssn9e6T/AjmHca+pCG9n5wZNgY6S0AJryUk6/hfyWc/7z1HfFHrkMM2zn9kqm13 h4tgCPG3WS86+WE4PO12sjAi0GYc43CszaxuU0GZoZ3cfapl5AzC8pMLltGyu/DqJLBk/biR Zr61dWmQWajF/dKhwrAtDiGc0PYZykl/Dg1mYD+eadv5qSKUdTuoa8idlief/sWnUUWbGkYb 1QUPqg8/g9UQcvBx+dgrnsf11X6GHq9gI+LKDBNLyWdEvTGCA8kwggPFAgEBMIHBMIGyMSUw IwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEG A1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2Vu dCBUZWNobm9sb2dpZXMxMzAxBgNVBAMTKkx1Y2VudCBUZWNobm9sb2dpZXMgQ2VydGlmaWNh dGUgU2VydmljZXMgMQIKGrlKlgAAAAAGxzAJBgUrDgMCGgUAoIICXTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNTExMDQyMzA5MDhaMCMGCSqGSIb3DQEJ BDEWBBTih/5u9S8qvUHEawbTuO+sWhWyIDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIB KDCB0gYJKwYBBAGCNxAEMYHEMIHBMIGyMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5s dWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxML TXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxMzAxBgNVBAMTKkx1 Y2VudCBUZWNobm9sb2dpZXMgQ2VydGlmaWNhdGUgU2VydmljZXMgMQIKGrlKlgAAAAAGxzCB 1AYLKoZIhvcNAQkQAgsxgcSggcEwgbIxJTAjBgkqhkiG9w0BCQEWFmNhQHNlY3VyaXR5Lmx1 Y2VudC5jb20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtN dXJyYXkgSGlsbDEcMBoGA1UEChMTTHVjZW50IFRlY2hub2xvZ2llczEzMDEGA1UEAxMqTHVj ZW50IFRlY2hub2xvZ2llcyBDZXJ0aWZpY2F0ZSBTZXJ2aWNlcyAxAgoauUqWAAAAAAbHMA0G CSqGSIb3DQEBAQUABIGAEGB+6oGi5lCTsJuH5COM9Vr5orEAsDIGYfwdjBRkSpS1h1wrLkrb fjPl0BUkKq7omWiGmkRdBryfnjX+QOGdJ6OlmkH+sNf/GfeCgbI4nixY7WYIMFdkboyhe2eD J4Wo5S4cBp3IgLHJNG4h4PSeBCLQr4VR/ePBOu2wh+WspcsAAAAAAAA= --------------ms080806090202080204070803-- --===============1399892787== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1399892787==-- From sip-bounces@ietf.org Fri Nov 04 19:02:20 2005 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 1EYBVk-0000zR-8Y; Fri, 04 Nov 2005 19:02:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYBVh-0000xn-FH for sip@megatron.ietf.org; Fri, 04 Nov 2005 19:02:17 -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 TAA23050 for ; Fri, 4 Nov 2005 19:01:54 -0500 (EST) Received: from mail.pingtel.com ([65.220.123.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYBkl-0007Mi-NF for sip@ietf.org; Fri, 04 Nov 2005 19:17:53 -0500 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id 032D86C017 for ; Fri, 4 Nov 2005 19:02:06 -0500 (EST) Subject: Re: [Sip] GRUU (was Whats wrong with Supported. (was: Alert-Info Idea) From: "Dale R. Worley" To: Sip In-Reply-To: <37D35F9A-00A1-4455-BAED-22FBB0784FB5@softarmor.com> References: <37D35F9A-00A1-4455-BAED-22FBB0784FB5@softarmor.com> Content-Type: text/plain Date: Fri, 04 Nov 2005 19:02:05 -0500 Message-Id: <1131148925.1814.17.camel@cdhcp139.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-6) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Fri, 2005-11-04 at 11:49 -0600, Dean Willis wrote: > So, exactly what do you do differently if you think something might > not be GRUU? > > You've been given this URI. Don't you just have to try it and see if > it works, and if not then back off to some other behavior? I believe that is what everybody does in practice. And we have sort of given them permission to do so, since RFC 3261 says that Contacts should be GRUUs. Dale _______________________________________________ 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 From sip-bounces@ietf.org Fri Nov 04 20:59:21 2005 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 1EYDKz-0005Uj-7o; Fri, 04 Nov 2005 20:59:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYDKx-0005UU-NR for sip@megatron.ietf.org; Fri, 04 Nov 2005 20:59:19 -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 UAA29011 for ; Fri, 4 Nov 2005 20:58:56 -0500 (EST) Received: from mail126.messagelabs.com ([216.82.254.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EYDZz-0001tB-0S for sip@ietf.org; Fri, 04 Nov 2005 21:14:56 -0500 X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-8.tower-126.messagelabs.com!1131155939!9594692!1 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 14302 invoked from network); 5 Nov 2005 01:59:00 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-8.tower-126.messagelabs.com with SMTP; 5 Nov 2005 01:59:00 -0000 Received: from OCCLUST04EVS1.ugd.att.com (135.38.164.12) by attrh3i.attrh.att.com (7.2.052) id 435BB4FA001DE608; Fri, 4 Nov 2005 20:58:58 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] GRUU (was Whats wrong with Supported. (was: Alert-Info Idea) Date: Fri, 4 Nov 2005 19:58:58 -0600 Message-ID: <28F05913385EAC43AF019413F674A0170DE0BD72@OCCLUST04EVS1.ugd.att.com> Thread-Topic: [Sip] GRUU (was Whats wrong with Supported. (was: Alert-Info Idea) Thread-Index: AcXhnE2HoADATJkATkCjFpUdM4RUVwAD8w+g From: "Dolly, Martin C, ALABS" To: "Dale R. Worley" , "Sip" X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org the wonderful things about GRUUs, are that GRUUs are wonderful things, there names are made out of URIs, but individual things.... > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of > Dale R. Worley > Sent: Friday, November 04, 2005 7:02 PM > To: Sip > Subject: Re: [Sip] GRUU (was Whats wrong with Supported. (was: > Alert-Info Idea) >=20 >=20 > On Fri, 2005-11-04 at 11:49 -0600, Dean Willis wrote: > > So, exactly what do you do differently if you think=20 > something might =20 > > not be GRUU? > >=20 > > You've been given this URI. Don't you just have to try it=20 > and see if =20 > > it works, and if not then back off to some other behavior? >=20 > I believe that is what everybody does in practice. And we=20 > have sort of > given them permission to do so, since RFC 3261 says that=20 > Contacts should > be GRUUs. >=20 > Dale >=20 >=20 >=20 > _______________________________________________ > 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 >=20 _______________________________________________ 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 From sip-bounces@ietf.org Fri Nov 04 23:56:19 2005 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 1EYG6F-0006rn-5B; Fri, 04 Nov 2005 23:56:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYG6C-0006ri-Po for sip@megatron.ietf.org; Fri, 04 Nov 2005 23:56:16 -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 XAA08632 for ; Fri, 4 Nov 2005 23:55:51 -0500 (EST) Received: from c243-111.rim.net ([216.9.243.111] helo=MHS01YKF.rim.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYGLJ-0006YL-Kw for sip@ietf.org; Sat, 05 Nov 2005 00:11:54 -0500 Importance: normal Priority: normal Received: from ngw01ykf.rim.net ([10.102.108.30]) by MHS01YKF.rim.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 4 Nov 2005 23:56:01 -0500 Received: from XCH21YKF.rim.net ([10.102.100.36]) by ngw01ykf.rim.net (SAVSMTP 3.1.6.45) with SMTP id M2005110423560132520 ; Fri, 04 Nov 2005 23:56:01 -0500 Received: from XCH30YKF.rim.net ([10.102.100.42]) by XCH21YKF.rim.net with Microsoft SMTPSVC(5.0.2195.6713); Fri, 4 Nov 2005 23:56:01 -0500 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181 Subject: Re: [Sip] GRUU (was Whats wrong with Supported. (was: Alert-Info Idea) Date: Fri, 4 Nov 2005 23:56:00 -0500 Message-ID: Thread-Topic: [Sip] GRUU (was Whats wrong with Supported. (was: Alert-InfoIdea) thread-index: AcXhaDma6kIVKx9fR4mTH6yfyLvrmwAAxYiwABZ7sjE= From: "Andrew Allen" To: , X-OriginalArrivalTime: 05 Nov 2005 04:56:01.0427 (UTC) FILETIME=[38002E30:01C5E1C5] X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org While I agree with the sentiments the fact is that pre-GRUU devices will = not be able to signal that they don't support GRUU and will not even be = aware that their URI is not a GRUU. Therefore are we not forced to indicate that the URI is a GRUU so we can = tell between those URIs that are GRUUs and those that may not be? -------------------------- Andrew Allen Manager Standards Research In Motion Ltd BlackBerry Mobile +1 847 809 8636 http://www.rim.com/ Sent from my BlackBerry Wireless Handheld -----Original Message----- From: sip-bounces@ietf.org To: Dean Willis CC: Sip Sent: Fri Nov 04 13:15:13 2005 Subject: RE: [Sip] GRUU (was Whats wrong with Supported. (was: = Alert-Info Idea) Very true. You can always try, fail, then take appropriate steps. I'm just talking about short circuiting the failure. You don't know that a GRUU will succeed, but you have a fairly high level of confidence that a non-GRUU will fail. I really hope that this becomes the 1% case with 99% of URIs are GRUUs. With that long term goal in mind, I'd prefer to signal that something is not a GRUU rather than always have to signal that it is one.=20 -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com]=20 Sent: Friday, November 04, 2005 9:50 AM To: Sean Olson Cc: Jeroen van Bemmel; Sip Subject: Re: [Sip] GRUU (was Whats wrong with Supported. (was: Alert-Info Idea) On Nov 3, 2005, at 6:57 PM, Sean Olson wrote: > Well, if GRUU =3D=3D Globally Routable UA URI, and you treat a URI as = a=20 > GRUU which does not have one of these properties, things will break.=20 > If you care when things break, you would want to know in advance. This > would apply to UAs, proxies, etc. You could make the argument that all > URIs should be GRUUs so what you really want is a property that says a > URI is *not* at a GRUU and assume all others are ;-) So, exactly what do you do differently if you think something might not be GRUU? You've been given this URI. Don't you just have to try it and see if it works, and if not then back off to some other behavior? Remember, there's really no such thing as an absolutely universally reachable URI. It might b a URI on the public internet that your corp firewall has decided to block. It might just stop working between the time you get it and the time you try to use it. The Net might partition in between you. And so on. -- Dean _______________________________________________ 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 --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential = information, privileged material (including material protected by the = solicitor-client or other applicable privileges), or constitute = non-public information. Any use of this information by anyone other than = the intended recipient is prohibited. If you have received this = transmission in error, please immediately reply to the sender and delete = this information from your system. Use, dissemination, distribution, or = reproduction of this transmission by unintended recipients is not = authorized and may be unlawful. _______________________________________________ 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 From sip-bounces@ietf.org Sat Nov 05 17:12:52 2005 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 1EYWHM-0004VG-Qh; Sat, 05 Nov 2005 17:12:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYWHL-0004V8-6c for sip@megatron.ietf.org; Sat, 05 Nov 2005 17:12:51 -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 RAA23145 for ; Sat, 5 Nov 2005 17:12:26 -0500 (EST) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYWWc-000579-AH for sip@ietf.org; Sat, 05 Nov 2005 17:28:38 -0500 Received: from [206.176.144.210] (206-176-144-210.waymark.net [206.176.144.210] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id jA5MHxUj024365 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 5 Nov 2005 16:18:00 -0600 Message-ID: <436D2E58.4020902@softarmor.com> Date: Sat, 05 Nov 2005 16:12:40 -0600 From: Dean Willis User-Agent: Mozilla Thunderbird 0.8 (X11/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Allen Subject: Re: [Sip] GRUU (was Whats wrong with Supported. (was: Alert-Info Idea) References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Andrew Allen wrote: > While I agree with the sentiments the fact is that pre-GRUU devices will not be able to signal that they don't support GRUU and will not even be aware that their URI is not a GRUU. > > Therefore are we not forced to indicate that the URI is a GRUU so we can tell between those URIs that are GRUUs and those that may not be? That's just my argument. We lack a reasonable way to say a URI is a GRUU. Even if we absolutely knew it to be a GRUU, it might still fail for the usage. Old stuff will also never be able to indicate or know that a contact is or is not a GRUU. So all we can ever do is try the contact, and if it works, it works, and if it doesn't, fall back to the AOR or give up. cc-transfer and Sean indicate that if we know a contact is not a GRUU, we should proceed directly to the AOR without trying the contact. But what if the contact is really reachable and would have worked if we had tried it? Aren't we shooting ourselves for no apparent reason? For example, presume a jillion users in an enterprise. Their contact-space is "gruu like" within their administrative domain, but they have a natting firewall between them and the real world. If you transfer a call within the domain, it works just fine using the Contact. Only when you transfer across the domain boundary does a GRUU become useful. Why do we want all of these transfers to proceed back through the gruu-routing proxy if they don't need to? And how would they play in a P2P world? If given a Contact, do I need to use the full P2P search algorithm on that contact like I would on a GRUU or an AOR? I don't THINK so. Or maybe we do, in which the GRUU is really just a "parameter of the AOR", and we really should have been routing everything at the AOR instead of the Contact level all along. Ok, I was just struck by an idea-pair. It'll sound crazier than most of my ideas (which says a lot), but I want to get it "out there" before it evaporates from my head. Feel free to laugh or ignore it, but there IS "something good" in there somewhere. 1) If instead of "proxy retargeting" things, we just pushed the new "handler URI" onto the route set ahead of the old target, we can clean up a lot of the insanity relating to retargeting. This gets back to the fundmental routing error in RFC 2543 that rewrote the request URI on every proxy hope. We sortof bandaid fixed this with loose routing, but it didn't go QUITE far enough. We can go a step further here: So far example, an INVITE may show up on my phone. By looking at the route-set, my phone can see that my AOR is the next hop. So, the phone lets me know I have a call. But if the next hop were, say, Jonathan's AOR, and my phone know's I'm authorized to take calls for Jonathan, my phone tells me that Jonathan has a call. On the other hand, say an INVITE lands on my proxy, and there's no next-hop on the route. The proxy then just adds my phone's URI (note I don't say "contact") to the route-set in front of my AOR, and sends the INVITE on. Visualizing this, a "minimal" route set on an initial request might look like "," where "domain" points to my proxy. The proxy applies "contact" routing by transfoirming this to ",'. See how the TARGET never changes -- just the steps between "here" and the "target" change. There is NO RETARGETING, just the insertion of additional steps "in between". 2) If something needs to refer to a particular "contact" or "delegate" or whatever we want to call it relative to an AOR (what we more or less do with GRUU), we invert this logic by having a target that explicitly "hangs off of" an AOR. Effectively, a route-triple. My proxy acts on this simply by deleting itself from the route-set and passing the request on. So if my phone knows it is hiding behind a "GRUU proxy" and that some particular request (for example, a transfer, needs to reach THIS PHONE, it doesn't hand you a "," route set, it instead uses a ",<," set. Or, my proxy could perform this manipulation on behalf of my phone. Putting this into practice: Extend "Contact:" and similar fields to take a route vector instead of a single URI. Side effect: This seems to fix the fundamental problem of Service-Route (which is currently defined on a per-AOR, rather than per-Contact) basis. -- Dean _______________________________________________ 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 From sip-bounces@ietf.org Sun Nov 06 16:09:22 2005 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 1EYrlS-0003Kh-LV; Sun, 06 Nov 2005 16:09:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYrlQ-0003Jv-MG for sip@megatron.ietf.org; Sun, 06 Nov 2005 16:09:20 -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 QAA19972 for ; Sun, 6 Nov 2005 16:08:56 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYs0t-0004nE-7I for sip@ietf.org; Sun, 06 Nov 2005 16:25:20 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 06 Nov 2005 13:09:14 -0800 X-IronPort-AV: i="3.97,298,1125903600"; d="scan'208"; a="227698402:sNHT25591568" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jA6L8gNf001834; Sun, 6 Nov 2005 13:09:12 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 6 Nov 2005 16:09:01 -0500 Received: from [209.52.109.209] ([10.86.242.55]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 6 Nov 2005 16:09:01 -0500 Message-ID: <436E4D4F.80006@cisco.com> Date: Sun, 06 Nov 2005 13:37:03 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] Alert-Info Idea (was Re: Comment on draft-willis-sip-an sweralert-01) References: <50B1CBA96870A34799A506B2313F266706D5158B@ntht201e.siemenscomms.co.uk> <4368D156.3080106@cisco.com> <1130956108.30072.54.camel@cdhcp139.pingtel.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Nov 2005 21:09:01.0651 (UTC) FILETIME=[4FBD2A30:01C5E316] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Cc: Sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org inline. Dean Willis wrote: > > On Nov 2, 2005, at 12:28 PM, Dale R. Worley wrote: > > >> >> If a UAS doesn't want to perform an extension when interacting with some >> particular UAC, what should it do? Ideally, the extension defines what >> to do in this case. Or it could reject the request based on >> authorization; as far as I know, 403 is always allowed. I suppose if >> the request has a Requires, it can pretend it doesn't understand the >> extension and return 420, but that is less useful (as 403 is closer to >> reality), and semantically contradicts any mention of the extension in >> other Supported headers. Similarly, if the request doesn't have a >> Requires, the UAS can pretend to not understand the extension and ignore >> the use of the extension (though again contradicting any Supported that >> it may have sent). >> >> As an example, I see that in sections 20.4 and 20.9 of RFC 3261, a UA is >> permitted to ignore the potentially hazardous headers Alert-Info and >> Call-Info based on external factors. Similarly, if there are aspects of >> an extension that a UA might want to selectively allow or forbit, I'd >> expect the RFC to make clear how a UA should deal with extension >> requests that it does not want to honor for specific reasons. >> > > Yes, I believe this is exactly consistent with what I was trying to > say. It's up to the extension to describe what should be done if you > support an extension listed in a Require: header field but don't want > (for whatever reason) to apply that extension to the specific request. I agree with this, that is the intent of Supported/Require. I think the confusion caused by 100rel is that the spec tells you that if you don't want to honor the extension, you "pretend" that you don't implement it, and thus reject with a 420. This, then, begs the question that Paul has asked about scope of Allow, Accept, etc. I'll post separately on that in a moment... -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ 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 From sip-bounces@ietf.org Sun Nov 06 16:09:23 2005 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 1EYrlT-0003LU-Lo; Sun, 06 Nov 2005 16:09:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYrlR-0003K5-5o for sip@megatron.ietf.org; Sun, 06 Nov 2005 16:09:21 -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 QAA19975 for ; Sun, 6 Nov 2005 16:08:56 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYs0u-0004nH-JB for sip@ietf.org; Sun, 06 Nov 2005 16:25:20 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 06 Nov 2005 13:09:17 -0800 X-IronPort-AV: i="3.97,298,1125903600"; d="scan'208"; a="227698409:sNHT26528668" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jA6L8gNh001834; Sun, 6 Nov 2005 13:09:14 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 6 Nov 2005 16:09:03 -0500 Received: from [209.52.109.209] ([10.86.242.55]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 6 Nov 2005 16:09:03 -0500 Message-ID: <436E4E99.3060309@cisco.com> Date: Sun, 06 Nov 2005 13:42:33 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] GRUU (was Whats wrong with Supported. References: <50B1CBA96870A34799A506B2313F266706D5158B@ntht201e.siemenscomms.co.uk> <4368D156.3080106@cisco.com> <1130956108.30072.54.camel@cdhcp139.pingtel.com> <436990C6.9040002@cisco.com> <1130994755.2569.30.camel@cdhcp139.pingtel.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Nov 2005 21:09:03.0166 (UTC) FILETIME=[50A455E0:01C5E316] X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: 7bit Cc: Sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org inline. Dean Willis wrote: > On Nov 2, 2005, at 11:12 PM, Dale R. Worley wrote: > >> On Wed, 2005-11-02 at 23:23 -0500, Paul Kyzivat wrote: >> >>> One issue is the one that has been discussed in this thread: do >>> Supports >>> and Requires just negotiate the *availability* of an option, or do they >>> also, in one way or another, imply the *use* of an option. >>> >>> For example, the GRUU spec calls for a UA that has obtained a gruu and >>> is inserting it as a contact in some request to insert a Supported: >>> gruu. Recipients of such a request are expected to interpret this as >>> meaning that the contact in the request has the gruu property. So in >>> that case the presence of the Supported header is being construed to >>> mean that the sender *used* the option in a particular way. >> >> . . . >> >> Using Supported/Required only in regard to the UA-wide property of >> whether it conforms to an RFC is straightforward, and it dodges the >> issue of the scope over with the declaration applies -- it applies to >> *all* messages, though of course, whether it implies anything about any >> one particular message depends on the RFC. >> >>> From this point of view, using "Supported: gruu" to indicate that the >> >> Contact is a GRUU is fundamentally broken, as the UA either supports >> GRUUs or not, regardless of whether it has obtained a GRUU that is >> usable for this transaction. I would then suggest that GRUU Contacts >> should be indicated by a field-parameter of "gruu" or some such. >> "Supported: gruu" is just the signal that the UA won't apply the gruu >> field-parameter without it meaning "This Contact is a GRUU". (I seem to >> recall somebody suggested this a while back.) > > > > Ok, having looked at the GRUU draft again, I'd like to consider this a > WGLC comment on GRUU, which I shall paraphrase as "What do you mean, > Supported:?" > > One could make the argument that a UA that supports GRUU would never, > for any reason, populate the Contact in a transaction other than > REGISTER (or the 200 OK thereto) with something that is not a GRUU, and > that one can therefore assume that the presence of Supported: gruu in a > message outside a REGISTER transaction means that the contact is a > GRUU. But if one were to make that argument, one would need to spell > this out clearly. That is the intent. The idea is this - the GRUU spec basically says, at MUST strength, that you have to use your GRUU in the contact of dialog forming requests and responses. Supported:gruu implies ONLY that the UA sending the request supports the gruu spec. As a consequence, since the gruu spec implies that a compliant implementation also place a GRUU into the contact, the presence of Supported:gruu ALSO implies that the request contains a GRUU in the contact. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ 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 From sip-bounces@ietf.org Sun Nov 06 16:09:24 2005 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 1EYrlU-0003Lv-LF; Sun, 06 Nov 2005 16:09:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYrlR-0003K9-B2 for sip@megatron.ietf.org; Sun, 06 Nov 2005 16:09:21 -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 QAA19978 for ; Sun, 6 Nov 2005 16:08:56 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYs0u-0004nE-Pr for sip@ietf.org; Sun, 06 Nov 2005 16:25:21 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 06 Nov 2005 13:09:19 -0800 X-IronPort-AV: i="3.97,298,1125903600"; d="scan'208"; a="227698416:sNHT26404064" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jA6L8gNj001834; Sun, 6 Nov 2005 13:09:17 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 6 Nov 2005 16:09:05 -0500 Received: from [209.52.109.209] ([10.86.242.55]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 6 Nov 2005 16:09:04 -0500 Message-ID: <436E51F0.1030906@cisco.com> Date: Sun, 06 Nov 2005 13:56:48 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Sip] Whats wrong with Supported. References: <50B1CBA96870A34799A506B2313F266706D5158B@ntht201e.siemenscomms.co.uk> <4368D156.3080106@cisco.com> <1130956108.30072.54.camel@cdhcp139.pingtel.com> <436990C6.9040002@cisco.com> In-Reply-To: <436990C6.9040002@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Nov 2005 21:09:04.0838 (UTC) FILETIME=[51A37660:01C5E316] X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 7bit Cc: Sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org inline. Paul Kyzivat wrote: > My other problem with Supported, Required, Accept, Accept-Language, ... > is that there is no clear definition of the scope over which this > declaration applies. Some possible interpretations are: > 1) just this message > 2) this transaction > 3) until the time of some action that the recipient is > expected to take as a result of this message > 4) for the remainder of this dialog > 5) for the remainder of this dialog unless > overridden later in the dialog > 6) for all messages with this UA > 7) for all messages with this UA unless > overridden later > > OPTIONS requests are supposed to specify these things. That seems to > imply to imply the scope must be 6 or 7. But even if that is true, how > would the recipient know uniquely when it is talking to the same UA? > Without that it can't know when its prior knowledge applies. I agree that this has really become a mess. The idea when 3261 was being written IIRC is that its really (6), but this doesn't work awfully well since, as you say, you don't know if you're talking to the same UA when you send a request to a particular URI. Most of these headers are inherited from HTTP, where they had two different meanings. Some, like Allow, were really properties of the resource itself. Others, like Accept, were useful for the transaction only to indicate what can come in the response. SIP "borrowed" these, but the different nature of SIP resources compared to HTTP ones has introduced a lot of confusion here. The difficulty as Paul has pointed out is that support for various extensions, headers, and methods is ultimately a property of a particular instance of software. However, a typical SIP URI, an in particular an AOR like sip:joe@example.com, represents a user that can be reached at possibly many pieces of software. To make matters messier, software can also be upgraded over time, so even if a UA routed to a particular instance, these properties arent truly static. Things get a little cleaner if you assume that an instance ID (in the gruu sense) changes for a UA when its firmware or software changes. In such a case, there could be a static relationship between the Allow, Accept, etc. values and an instnace ID, and you could cache that relationship. Using those values to guess how to construct a request would then only be useful when sending a reuqest to a known instance. That happens for mid-dialog requests, but also for requests targeted to a gruu. One question, though, is whether it is allowed to indicate different capabilities for a UA instance depending who is asking. We have generally allowed that for other things, and allowing it here (as 100rel basically does) breaks the model that you could cache these properties as associated with an instance ID, UNLESS you basically changed instance IDs if you change values of Allow, Accept, etc. We should definitely try and figure out what the scope really is and put that somewhere in a document, or at least into the bugzilla instance. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ 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 From sip-bounces@ietf.org Sun Nov 06 16:30:24 2005 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 1EYs5o-0002Cs-Kn; Sun, 06 Nov 2005 16:30:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYs5n-0002Cn-6Y for sip@megatron.ietf.org; Sun, 06 Nov 2005 16:30:23 -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 QAA21279 for ; Sun, 6 Nov 2005 16:29:58 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYsLF-0005Qm-NS for sip@ietf.org; Sun, 06 Nov 2005 16:46:23 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 06 Nov 2005 13:30:11 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jA6LU7dv023774; Sun, 6 Nov 2005 13:30:08 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 6 Nov 2005 16:30:07 -0500 Received: from [209.52.109.209] ([10.86.242.55]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 6 Nov 2005 16:30:06 -0500 Message-ID: <436E75DD.8060107@cisco.com> Date: Sun, 06 Nov 2005 16:30:05 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Allen Subject: Re: [Sip] GRUU (was Whats wrong with Supported. (was: Alert-Info Idea) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Nov 2005 21:30:06.0832 (UTC) FILETIME=[41D87700:01C5E319] X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, dean.willis@softarmor.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I still don't believe its needed. The reason is, that in places where a GRUU appears along with an alternate choice (i.e., a contact), you have the Supported header field telling you whether it is or not. In places where a GRUU appears solo (like a web page or in a Refer-To header field), you don't really have another choice but to just use it, so what is the point in signaling that it is or isnt a gruu? The point is, the contents of Refer-To, Contact and so on are SUPPOSED to have the gruu property to begin with; the problem is we never had a way for that to be an easily guaranteed property. -Jonathan R. Andrew Allen wrote: > While I agree with the sentiments the fact is that pre-GRUU devices > will not be able to signal that they don't support GRUU and will not > even be aware that their URI is not a GRUU. > > Therefore are we not forced to indicate that the URI is a GRUU so we > can tell between those URIs that are GRUUs and those that may not be? > -------------------------- Andrew Allen Manager Standards Research > In Motion Ltd BlackBerry Mobile +1 847 809 8636 http://www.rim.com/ > > Sent from my BlackBerry Wireless Handheld > > > -----Original Message----- From: sip-bounces@ietf.org To: Dean Willis > CC: Sip Sent: Fri Nov 04 13:15:13 2005 Subject: RE: [Sip] GRUU (was > Whats wrong with Supported. (was: Alert-Info Idea) > > Very true. You can always try, fail, then take appropriate steps. I'm > just talking about short circuiting the failure. You don't know that > a GRUU will succeed, but you have a fairly high level of confidence > that a non-GRUU will fail. I really hope that this becomes the 1% > case with 99% of URIs are GRUUs. With that long term goal in mind, > I'd prefer to signal that something is not a GRUU rather than always > have to signal that it is one. > > -----Original Message----- From: Dean Willis > [mailto:dean.willis@softarmor.com] Sent: Friday, November 04, 2005 > 9:50 AM To: Sean Olson Cc: Jeroen van Bemmel; Sip Subject: Re: [Sip] > GRUU (was Whats wrong with Supported. (was: Alert-Info Idea) > > > On Nov 3, 2005, at 6:57 PM, Sean Olson wrote: > > >> Well, if GRUU == Globally Routable UA URI, and you treat a URI as >> a GRUU which does not have one of these properties, things will >> break. If you care when things break, you would want to know in >> advance. This > > >> would apply to UAs, proxies, etc. You could make the argument that >> all > > >> URIs should be GRUUs so what you really want is a property that >> says a > > >> URI is *not* at a GRUU and assume all others are ;-) > > > > So, exactly what do you do differently if you think something might > not be GRUU? > > You've been given this URI. Don't you just have to try it and see if > it works, and if not then back off to some other behavior? > > Remember, there's really no such thing as an absolutely universally > reachable URI. It might b a URI on the public internet that your corp > firewall has decided to block. It might just stop working between > the time you get it and the time you try to use it. The Net might > partition in between you. And so on. > > -- Dean > > > _______________________________________________ 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 > > > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain > confidential information, privileged material (including material > protected by the solicitor-client or other applicable privileges), or > constitute non-public information. Any use of this information by > anyone other than the intended recipient is prohibited. If you have > received this transmission in error, please immediately reply to the > sender and delete this information from your system. Use, > dissemination, distribution, or reproduction of this transmission by > unintended recipients is not authorized and may be unlawful. > > _______________________________________________ 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 > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ 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 From sip-bounces@ietf.org Sun Nov 06 16:39:18 2005 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 1EYsEQ-0003tH-Lh; Sun, 06 Nov 2005 16:39:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYsEM-0003tA-Gp for sip@megatron.ietf.org; Sun, 06 Nov 2005 16:39:14 -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 QAA21614 for ; Sun, 6 Nov 2005 16:38:49 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYsTq-0005cT-49 for sip@ietf.org; Sun, 06 Nov 2005 16:55:14 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 06 Nov 2005 13:39:05 -0800 X-IronPort-AV: i="3.97,298,1125903600"; d="scan'208"; a="361461336:sNHT27174368" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jA6Lcsdx025625; Sun, 6 Nov 2005 13:39:03 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 6 Nov 2005 16:38:56 -0500 Received: from [209.52.109.209] ([10.86.242.55]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 6 Nov 2005 16:38:55 -0500 Message-ID: <436E77E5.1060208@cisco.com> Date: Sun, 06 Nov 2005 16:38:45 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] GRUU (was Whats wrong with Supported. (was: Alert-Info Idea) References: <436D2E58.4020902@softarmor.com> In-Reply-To: <436D2E58.4020902@softarmor.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Nov 2005 21:38:55.0866 (UTC) FILETIME=[7D2CA5A0:01C5E31A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org inline. Dean Willis wrote: > For example, presume a jillion users in an enterprise. Their > contact-space is "gruu like" within their administrative domain, but > they have a natting firewall between them and the real world. If you > transfer a call within the domain, it works just fine using the Contact. > Only when you transfer across the domain boundary does a GRUU become > useful. Why do we want all of these transfers to proceed back through > the gruu-routing proxy if they don't need to? The gruu draft acknowledges that direct signaling is lost with gruu, and that this would be revisited at some point in the future. > 1) If instead of "proxy retargeting" things, we just pushed the new > "handler URI" onto the route set ahead of the old target, we can clean > up a lot of the insanity relating to retargeting. This gets back to the > fundmental routing error in RFC 2543 that rewrote the request URI on > every proxy hope. We sortof bandaid fixed this with loose routing, but > it didn't go QUITE far enough. Wow - shocking timing here - I more or less posted this same idea on the plane ride out here, prior to reading your note. I shudder at the thought that Dean and I are thinking alike... next thing you know I'll want to deprecate forking.... > We can go a step further here: So far > example, an INVITE may show up on my phone. By looking at the route-set, > my phone can see that my AOR is the next hop. I think the AOR would be in the requeust-URI. > So, the phone lets me know > I have a call. But if the next hop were, say, Jonathan's AOR, and my > phone know's I'm authorized to take calls for Jonathan, my phone tells > me that Jonathan has a call. On the other hand, say an INVITE lands on > my proxy, and there's no next-hop on the route. The proxy then just adds > my phone's URI (note I don't say "contact") to the route-set in front of > my AOR, and sends the INVITE on. I think it adds your contact URI as a Route value, but the AOR wouldn't be there. The R-URI remains as the identifier of the target. The route set tells you how to get there, including the endpoint itself. > > Visualizing this, a "minimal" route set on an initial request might look > like "," where "domain" points to my proxy. The proxy > applies "contact" routing by transfoirming this to ",'. > See how the TARGET never changes -- just the steps between "here" and > the "target" change. There is NO RETARGETING, just the insertion of > additional steps "in between". I think the way it works is that an initial request is like: INVITE AOR and then every time a next hop needs to be reached, its added as a route header field value, including the endpoint contact itself. > > > 2) If something needs to refer to a particular "contact" or "delegate" > or whatever we want to call it relative to an AOR (what we more or less > do with GRUU), we invert this logic by having a target that explicitly > "hangs off of" an AOR. Effectively, a route-triple. My proxy acts on > this simply by deleting itself from the route-set and passing the > request on. No, that I disagree with. One of the things we discussed early on in the design of gruu was simulating the effect with embedded Route headers, basically what you are describing it. We discarded that, because you want to apply service treatment and other logic to the GRUU, and to do that you really need it to be a separate resource. I think the issue of gruu is orthogonal to this idea of putting the endpoint hop in a route header. So, if I send a request to a gruu, and that gruu is bound to contact sip:ua-contact, the initial INVITE would look like: INVITE sip:gruu and then this arrives at the proxy, which does this: INVITE sip:gruu Route: sip:ua-contact > Side effect: This seems to fix the fundamental problem of Service-Route > (which is currently defined on a per-AOR, rather than per-Contact) basis. Err, you lost me there. Service route (and Path) remain broken AFAICT... -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ 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 From sip-bounces@ietf.org Sun Nov 06 17:12:39 2005 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 1EYskh-0003mz-Bc; Sun, 06 Nov 2005 17:12:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYskf-0003kh-0m for sip@megatron.ietf.org; Sun, 06 Nov 2005 17:12: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 RAA23265 for ; Sun, 6 Nov 2005 17:12:12 -0500 (EST) Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYt08-0006QX-Px for sip@ietf.org; Sun, 06 Nov 2005 17:28:37 -0500 Received: (qmail 7869 invoked by uid 0); 6 Nov 2005 22:12:07 -0000 Received: from unknown (HELO BEMBUSTER) ([81.59.101.130]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 6 Nov 2005 22:12:07 -0000 Message-ID: <003e01c5e31f$2036c9c0$6402a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "Jonathan Rosenberg" , "Andrew Allen" References: <436E75DD.8060107@cisco.com> Subject: Re: [Sip] GRUU (was Whats wrong with Supported. (was: Alert-Info Idea) Date: Sun, 6 Nov 2005 23:12:06 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: 1.2 (+) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, dean.willis@softarmor.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Jonathan, What about a PIDF document with one or more contact elements and a pres: URI? Similar to the example in section 6.3 of draft-ietf-sipping-cc-transfer-05 that Paul mentioned, there is a choice (both amongst contacts and between contact / pres: URI if the contact is not a GRUU) Regards, Jeroen ----- Original Message ----- From: "Jonathan Rosenberg" To: "Andrew Allen" Cc: ; Sent: Sunday, November 06, 2005 10:30 PM Subject: Re: [Sip] GRUU (was Whats wrong with Supported. (was: Alert-Info Idea) >I still don't believe its needed. > > The reason is, that in places where a GRUU appears along with an alternate > choice (i.e., a contact), you have the Supported header field telling you > whether it is or not. In places where a GRUU appears solo (like a web page > or in a Refer-To header field), you don't really have another choice but > to just use it, so what is the point in signaling that it is or isnt a > gruu? > > The point is, the contents of Refer-To, Contact and so on are SUPPOSED to > have the gruu property to begin with; the problem is we never had a way > for that to be an easily guaranteed property. > > -Jonathan R. > > Andrew Allen wrote: > >> While I agree with the sentiments the fact is that pre-GRUU devices >> will not be able to signal that they don't support GRUU and will not >> even be aware that their URI is not a GRUU. >> >> Therefore are we not forced to indicate that the URI is a GRUU so we >> can tell between those URIs that are GRUUs and those that may not be? >> -------------------------- Andrew Allen Manager Standards Research >> In Motion Ltd BlackBerry Mobile +1 847 809 8636 http://www.rim.com/ >> >> Sent from my BlackBerry Wireless Handheld >> >> >> -----Original Message----- From: sip-bounces@ietf.org To: Dean Willis >> CC: Sip Sent: Fri Nov 04 13:15:13 2005 Subject: RE: [Sip] GRUU (was >> Whats wrong with Supported. (was: Alert-Info Idea) >> >> Very true. You can always try, fail, then take appropriate steps. I'm >> just talking about short circuiting the failure. You don't know that >> a GRUU will succeed, but you have a fairly high level of confidence >> that a non-GRUU will fail. I really hope that this becomes the 1% >> case with 99% of URIs are GRUUs. With that long term goal in mind, >> I'd prefer to signal that something is not a GRUU rather than always >> have to signal that it is one. >> >> -----Original Message----- From: Dean Willis >> [mailto:dean.willis@softarmor.com] Sent: Friday, November 04, 2005 >> 9:50 AM To: Sean Olson Cc: Jeroen van Bemmel; Sip Subject: Re: [Sip] >> GRUU (was Whats wrong with Supported. (was: Alert-Info Idea) >> >> >> On Nov 3, 2005, at 6:57 PM, Sean Olson wrote: >> >> >>> Well, if GRUU == Globally Routable UA URI, and you treat a URI as >>> a GRUU which does not have one of these properties, things will >>> break. If you care when things break, you would want to know in >>> advance. This >> >> >>> would apply to UAs, proxies, etc. You could make the argument that >>> all >> >> >>> URIs should be GRUUs so what you really want is a property that >>> says a >> >> >>> URI is *not* at a GRUU and assume all others are ;-) >> >> >> >> So, exactly what do you do differently if you think something might >> not be GRUU? >> >> You've been given this URI. Don't you just have to try it and see if >> it works, and if not then back off to some other behavior? >> >> Remember, there's really no such thing as an absolutely universally >> reachable URI. It might b a URI on the public internet that your corp >> firewall has decided to block. It might just stop working between >> the time you get it and the time you try to use it. The Net might >> partition in between you. And so on. >> >> -- Dean >> >> >> _______________________________________________ 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 >> >> >> >> --------------------------------------------------------------------- >> This transmission (including any attachments) may contain >> confidential information, privileged material (including material >> protected by the solicitor-client or other applicable privileges), or >> constitute non-public information. Any use of this information by >> anyone other than the intended recipient is prohibited. If you have >> received this transmission in error, please immediately reply to the >> sender and delete this information from your system. Use, >> dissemination, distribution, or reproduction of this transmission by >> unintended recipients is not authorized and may be unlawful. >> >> _______________________________________________ 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 >> > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > > _______________________________________________ > 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 From sip-bounces@ietf.org Sun Nov 06 23:05:19 2005 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 1EYyFz-0002v6-No; Sun, 06 Nov 2005 23:05:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYyFx-0002v1-V8 for sip@megatron.ietf.org; Sun, 06 Nov 2005 23:05:18 -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 XAA11199 for ; Sun, 6 Nov 2005 23:04:52 -0500 (EST) Received: from [211.94.36.20] (helo=mail.chinaunicom.com.cn) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYyVT-0006Jw-2y for sip@ietf.org; Sun, 06 Nov 2005 23:21:20 -0500 Received: from yanbf ([211.94.36.206]) by mail.chinaunicom.com.cn with Microsoft SMTPSVC(5.0.2195.6713); Mon, 7 Nov 2005 12:04:42 +0800 Message-ID: <006a01c5e350$65c75be0$0416c00a@yanbf> From: "Binfeng Yan" To: "Dean Willis" Subject: Re: [Sip] Another Revised agenda for SIP et IETF 64 Date: Mon, 7 Nov 2005 12:04:49 +0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-RFC2646: Format=Flowed; Original X-OriginalArrivalTime: 07 Nov 2005 04:04:42.0687 (UTC) FILETIME=[61C13CF0:01C5E350] X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Thanks for chair's help. On Nov 4, 2005, at 11:54 Dean Willis wrote: It's a procedure defined in RFC 3932, which modifies the procedure of RFC 2026. It allows for ADs to sponsor informational documents that are not in the scope of a specific working group, get the mIESG reviewed, and published as RFCs. It's preferred over direct-to-RFC-ed individual informationals because there is still IESG review over these documents and an opportunity for public debate that is not inherent with the direct-to-RFCed process of RFC 2026. While the IETF generally prefers approaches that are not IPR encumbered, the presence of an IPR claim does not generally prevent publication as an informational document. _______________________________________________ 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 From sip-bounces@ietf.org Sun Nov 06 23:12:51 2005 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 1EYyNH-0004Hm-8b; Sun, 06 Nov 2005 23:12:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYyNF-0004GZ-4U for sip@megatron.ietf.org; Sun, 06 Nov 2005 23:12:49 -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 XAA11605 for ; Sun, 6 Nov 2005 23:12:24 -0500 (EST) Received: from [211.94.36.20] (helo=mail.chinaunicom.com.cn) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYycm-0006V0-5t for sip@ietf.org; Sun, 06 Nov 2005 23:28:52 -0500 Received: from yanbf ([211.94.36.206]) by mail.chinaunicom.com.cn with Microsoft SMTPSVC(5.0.2195.6713); Mon, 7 Nov 2005 12:12:31 +0800 Message-ID: <007101c5e351$7d42e7c0$0416c00a@yanbf> From: "Binfeng Yan" To: Subject: RE: [Sip] Another Revised agenda for SIP et IETF 64 Date: Mon, 7 Nov 2005 12:12:37 +0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-RFC2646: Format=Flowed; Original X-OriginalArrivalTime: 07 Nov 2005 04:12:31.0577 (UTC) FILETIME=[793C2C90:01C5E351] X-Spam-Score: 1.1 (+) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org IETF generally prefers approaches that are not IPR encumbered as chair said here. Anyhow, thanks for your explanation. -----Original Message----- From: Drage, Keith (Keith) Sent: 2005-11-4 20:56 To: 'DENG, HUI -HCHBJ' Cc: 'sip@ietf.org' Subject: RE: [Sip] Another Revised agenda for SIP et IETF 64 I am not sure I understand the concern about IPR here, and would like some clarification. Both IETF and 3GPP2 have broadly similar IPR rules. They both require IPR to be declared. They both allow adoption of solutions that contain IPR. Both organisations specifications are freely available without cost, and no charge is levied to implement the specifications by the organisations concerned. I fail to see the difference. It depends on the decisions of the people adopting the solution as to what is there, and I would suggest that in your document, you have probably already gone far enough in deciding the solution that any IPR owned on the solution would become apparent. As an example, I would note that most of the IPR in IMS comes from the inherited IETF specifications for SIP and associated protocols! regards Keith ------------------------------- _______________________________________________ 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 From sip-bounces@ietf.org Mon Nov 07 09:48:11 2005 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 1EZ8I7-0008Hd-JF; Mon, 07 Nov 2005 09:48:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZ8I6-0008H2-0M for sip@megatron.ietf.org; Mon, 07 Nov 2005 09:48:10 -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 JAA13725 for ; Mon, 7 Nov 2005 09:47:42 -0500 (EST) Received: from mailhost.iperia.com ([204.57.52.4] helo=iperia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZ8Xg-0005hh-BP for sip@ietf.org; Mon, 07 Nov 2005 10:04:18 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Subject: RE: [Sip] Whats wrong with Supported. Date: Mon, 7 Nov 2005 09:47:44 -0500 Message-ID: <8019F8581B5FC14DBD94BAF86844868E8D84C7@viridis.IPeria.local> Thread-Topic: [Sip] Whats wrong with Supported. Thread-Index: AcXjFvi1rrF2R0+ZS3elYdYJ/d5OfQAkGroA From: "Gordon Ledgard" To: "Jonathan Rosenberg" , "Paul Kyzivat" X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: quoted-printable Cc: Sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Yes, the Sup/Req/Acc/Acc-L headers have this problem with temporal duration and scope. But they have another problem that digs deeper into the biggest flaw of SIP, in my opinion: SIP does a lousy job of separating the functional layers of the network. Sip wants to be your network connection (INVITE/OK/ACK), your discovery channel (300 redirects and forking proxies), your router control protocol (Route/RecordRoute), and your transport mechanism (SDP, etc), and your session control manager(dialogs), all in one iddy-biddy packet. Actually, the fact that it is all in one packet is not the problem. That there is not a clearer definition of layered responsibilities is the issue. In fact SIP manages to do all this stuff amazingly well most of the time, and a hats off to everyone for that. However, unless you can delineate these functionalities better, the scope of Sup/Req/Acc/Acc-L will remain fuzzy. Gordon R. Ledgard IPeria, Inc. >=20 > Paul Kyzivat wrote: >=20 >=20 > > My other problem with Supported, Required, Accept, Accept-Language, ... > > is that there is no clear definition of the scope over which this > > declaration applies. Some possible interpretations are: > > 1) just this message > > 2) this transaction > > 3) until the time of some action that the recipient is > > expected to take as a result of this message > > 4) for the remainder of this dialog > > 5) for the remainder of this dialog unless > > overridden later in the dialog > > 6) for all messages with this UA > > 7) for all messages with this UA unless > > overridden later > ......... > > And Jonathan Rosenberg replied...... >=20 > The difficulty as Paul has pointed out is that support for various > extensions, headers, and methods is ultimately a property of a > particular instance of software. However, a typical SIP URI, an in > particular an AOR like sip:joe@example.com, represents a user that can > be reached at possibly many pieces of software. To make matters messier, > software can also be upgraded over time, so even if a UA routed to a > particular instance, these properties arent truly static. >=20 _______________________________________________ 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 From sip-bounces@ietf.org Mon Nov 07 09:56:01 2005 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 1EZ8Ph-000205-7a; Mon, 07 Nov 2005 09:56:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZ8Pf-0001zz-7q for sip@megatron.ietf.org; Mon, 07 Nov 2005 09:55:59 -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 JAA14395 for ; Mon, 7 Nov 2005 09:55:32 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZ8fH-00060v-Ru for sip@ietf.org; Mon, 07 Nov 2005 10:12:08 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 07 Nov 2005 06:55:50 -0800 X-IronPort-AV: i="3.97,300,1125903600"; d="scan'208"; a="672385211:sNHT28292512" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jA7EtDOF023863; Mon, 7 Nov 2005 06:55:47 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 7 Nov 2005 09:55:30 -0500 Received: from [209.52.109.209] ([10.86.242.151]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 7 Nov 2005 09:55:30 -0500 Message-ID: <436F6AE1.2060906@cisco.com> Date: Mon, 07 Nov 2005 09:55:29 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeroen van Bemmel Subject: Re: [Sip] GRUU (was Whats wrong with Supported. References: <436E75DD.8060107@cisco.com> <003e01c5e31f$2036c9c0$6402a8c0@BEMBUSTER> In-Reply-To: <003e01c5e31f$2036c9c0$6402a8c0@BEMBUSTER> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Nov 2005 14:55:30.0385 (UTC) FILETIME=[4BFF1C10:01C5E3AB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, dean.willis@softarmor.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org But again, what choice do you have? You can use the in the pidf document to reach that service, and thats it. There isn't going to be an alternate URI for that service that you could try. -Jonathan R. Jeroen van Bemmel wrote: > Jonathan, > > What about a PIDF document with one or more contact elements and a pres: > URI? > Similar to the example in section 6.3 of > draft-ietf-sipping-cc-transfer-05 that Paul mentioned, there is a choice > (both amongst contacts and between contact / pres: URI if the contact is > not a GRUU) > > Regards, > Jeroen > > ----- Original Message ----- From: "Jonathan Rosenberg" > To: "Andrew Allen" > Cc: ; > Sent: Sunday, November 06, 2005 10:30 PM > Subject: Re: [Sip] GRUU (was Whats wrong with Supported. (was: > Alert-Info Idea) > > >> I still don't believe its needed. >> >> The reason is, that in places where a GRUU appears along with an >> alternate choice (i.e., a contact), you have the Supported header >> field telling you whether it is or not. In places where a GRUU appears >> solo (like a web page or in a Refer-To header field), you don't really >> have another choice but to just use it, so what is the point in >> signaling that it is or isnt a gruu? >> >> The point is, the contents of Refer-To, Contact and so on are SUPPOSED >> to have the gruu property to begin with; the problem is we never had a >> way for that to be an easily guaranteed property. >> >> -Jonathan R. >> >> Andrew Allen wrote: >> >>> While I agree with the sentiments the fact is that pre-GRUU devices >>> will not be able to signal that they don't support GRUU and will not >>> even be aware that their URI is not a GRUU. >>> >>> Therefore are we not forced to indicate that the URI is a GRUU so we >>> can tell between those URIs that are GRUUs and those that may not be? >>> -------------------------- Andrew Allen Manager Standards Research >>> In Motion Ltd BlackBerry Mobile +1 847 809 8636 http://www.rim.com/ >>> >>> Sent from my BlackBerry Wireless Handheld >>> >>> >>> -----Original Message----- From: sip-bounces@ietf.org To: Dean Willis >>> CC: Sip Sent: Fri Nov 04 13:15:13 2005 Subject: RE: [Sip] GRUU (was >>> Whats wrong with Supported. (was: Alert-Info Idea) >>> >>> Very true. You can always try, fail, then take appropriate steps. I'm >>> just talking about short circuiting the failure. You don't know that >>> a GRUU will succeed, but you have a fairly high level of confidence >>> that a non-GRUU will fail. I really hope that this becomes the 1% >>> case with 99% of URIs are GRUUs. With that long term goal in mind, >>> I'd prefer to signal that something is not a GRUU rather than always >>> have to signal that it is one. >>> >>> -----Original Message----- From: Dean Willis >>> [mailto:dean.willis@softarmor.com] Sent: Friday, November 04, 2005 >>> 9:50 AM To: Sean Olson Cc: Jeroen van Bemmel; Sip Subject: Re: [Sip] >>> GRUU (was Whats wrong with Supported. (was: Alert-Info Idea) >>> >>> >>> On Nov 3, 2005, at 6:57 PM, Sean Olson wrote: >>> >>> >>>> Well, if GRUU == Globally Routable UA URI, and you treat a URI as >>>> a GRUU which does not have one of these properties, things will >>>> break. If you care when things break, you would want to know in >>>> advance. This >>> >>> >>> >>>> would apply to UAs, proxies, etc. You could make the argument that >>>> all >>> >>> >>> >>>> URIs should be GRUUs so what you really want is a property that >>>> says a >>> >>> >>> >>>> URI is *not* at a GRUU and assume all others are ;-) >>> >>> >>> >>> >>> So, exactly what do you do differently if you think something might >>> not be GRUU? >>> >>> You've been given this URI. Don't you just have to try it and see if >>> it works, and if not then back off to some other behavior? >>> >>> Remember, there's really no such thing as an absolutely universally >>> reachable URI. It might b a URI on the public internet that your corp >>> firewall has decided to block. It might just stop working between >>> the time you get it and the time you try to use it. The Net might >>> partition in between you. And so on. >>> >>> -- Dean >>> >>> >>> _______________________________________________ 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 >>> >>> >>> >>> --------------------------------------------------------------------- >>> This transmission (including any attachments) may contain >>> confidential information, privileged material (including material >>> protected by the solicitor-client or other applicable privileges), or >>> constitute non-public information. Any use of this information by >>> anyone other than the intended recipient is prohibited. If you have >>> received this transmission in error, please immediately reply to the >>> sender and delete this information from your system. Use, >>> dissemination, distribution, or reproduction of this transmission by >>> unintended recipients is not authorized and may be unlawful. >>> >>> _______________________________________________ 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 >>> >> >> -- >> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >> Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 >> Cisco Systems >> jdrosen@cisco.com FAX: (973) 952-5050 >> http://www.jdrosen.net PHONE: (973) 952-5000 >> http://www.cisco.com >> >> _______________________________________________ >> 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 > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ 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 From sip-bounces@ietf.org Mon Nov 07 09:58:20 2005 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 1EZ8Rw-0002qG-H8; Mon, 07 Nov 2005 09:58:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZ8Rv-0002q8-3L for sip@megatron.ietf.org; Mon, 07 Nov 2005 09:58:19 -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 JAA14563 for ; Mon, 7 Nov 2005 09:57:52 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZ8hX-00065A-QB for sip@ietf.org; Mon, 07 Nov 2005 10:14:28 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 07 Nov 2005 06:58:09 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,300,1125903600"; d="scan'208"; a="14672245:sNHT25815140" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jA7Evid6002855; Mon, 7 Nov 2005 09:58:07 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 7 Nov 2005 09:58:06 -0500 Received: from [209.52.109.209] ([10.86.242.151]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 7 Nov 2005 09:58:05 -0500 Message-ID: <436F6B7C.4000400@cisco.com> Date: Mon, 07 Nov 2005 09:58:04 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeroen van Bemmel Subject: Re: [Sip] GRUU (was Whats wrong with Supported. References: <436E75DD.8060107@cisco.com> <003e01c5e31f$2036c9c0$6402a8c0@BEMBUSTER> In-Reply-To: <003e01c5e31f$2036c9c0$6402a8c0@BEMBUSTER> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Nov 2005 14:58:05.0947 (UTC) FILETIME=[A8B7FCB0:01C5E3AB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, dean.willis@softarmor.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Sorry I replied without having correctly understood your response. The pres URI is not going to be suitable for reaching the service, since its not a service URI at all. Its an identifier for the presentity. You might try different services, sure, but those don't represent an alternative for reaching the service you have chosen. If you knew that the for some service wasn't a gruu, would that mean you'd give up and use a different service entirely? No. You'd try the service you want, and if it can't be reached (timeout or whatever), you'd then try something else. No need to know whether the is a gruu or not. -Jonathan R. Jeroen van Bemmel wrote: > Jonathan, > > What about a PIDF document with one or more contact elements and a pres: > URI? > Similar to the example in section 6.3 of > draft-ietf-sipping-cc-transfer-05 that Paul mentioned, there is a choice > (both amongst contacts and between contact / pres: URI if the contact is > not a GRUU) > > Regards, > Jeroen > > ----- Original Message ----- From: "Jonathan Rosenberg" > To: "Andrew Allen" > Cc: ; > Sent: Sunday, November 06, 2005 10:30 PM > Subject: Re: [Sip] GRUU (was Whats wrong with Supported. (was: > Alert-Info Idea) > > >> I still don't believe its needed. >> >> The reason is, that in places where a GRUU appears along with an >> alternate choice (i.e., a contact), you have the Supported header >> field telling you whether it is or not. In places where a GRUU appears >> solo (like a web page or in a Refer-To header field), you don't really >> have another choice but to just use it, so what is the point in >> signaling that it is or isnt a gruu? >> >> The point is, the contents of Refer-To, Contact and so on are SUPPOSED >> to have the gruu property to begin with; the problem is we never had a >> way for that to be an easily guaranteed property. >> >> -Jonathan R. >> >> Andrew Allen wrote: >> >>> While I agree with the sentiments the fact is that pre-GRUU devices >>> will not be able to signal that they don't support GRUU and will not >>> even be aware that their URI is not a GRUU. >>> >>> Therefore are we not forced to indicate that the URI is a GRUU so we >>> can tell between those URIs that are GRUUs and those that may not be? >>> -------------------------- Andrew Allen Manager Standards Research >>> In Motion Ltd BlackBerry Mobile +1 847 809 8636 http://www.rim.com/ >>> >>> Sent from my BlackBerry Wireless Handheld >>> >>> >>> -----Original Message----- From: sip-bounces@ietf.org To: Dean Willis >>> CC: Sip Sent: Fri Nov 04 13:15:13 2005 Subject: RE: [Sip] GRUU (was >>> Whats wrong with Supported. (was: Alert-Info Idea) >>> >>> Very true. You can always try, fail, then take appropriate steps. I'm >>> just talking about short circuiting the failure. You don't know that >>> a GRUU will succeed, but you have a fairly high level of confidence >>> that a non-GRUU will fail. I really hope that this becomes the 1% >>> case with 99% of URIs are GRUUs. With that long term goal in mind, >>> I'd prefer to signal that something is not a GRUU rather than always >>> have to signal that it is one. >>> >>> -----Original Message----- From: Dean Willis >>> [mailto:dean.willis@softarmor.com] Sent: Friday, November 04, 2005 >>> 9:50 AM To: Sean Olson Cc: Jeroen van Bemmel; Sip Subject: Re: [Sip] >>> GRUU (was Whats wrong with Supported. (was: Alert-Info Idea) >>> >>> >>> On Nov 3, 2005, at 6:57 PM, Sean Olson wrote: >>> >>> >>>> Well, if GRUU == Globally Routable UA URI, and you treat a URI as >>>> a GRUU which does not have one of these properties, things will >>>> break. If you care when things break, you would want to know in >>>> advance. This >>> >>> >>> >>>> would apply to UAs, proxies, etc. You could make the argument that >>>> all >>> >>> >>> >>>> URIs should be GRUUs so what you really want is a property that >>>> says a >>> >>> >>> >>>> URI is *not* at a GRUU and assume all others are ;-) >>> >>> >>> >>> >>> So, exactly what do you do differently if you think something might >>> not be GRUU? >>> >>> You've been given this URI. Don't you just have to try it and see if >>> it works, and if not then back off to some other behavior? >>> >>> Remember, there's really no such thing as an absolutely universally >>> reachable URI. It might b a URI on the public internet that your corp >>> firewall has decided to block. It might just stop working between >>> the time you get it and the time you try to use it. The Net might >>> partition in between you. And so on. >>> >>> -- Dean >>> >>> >>> _______________________________________________ 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 >>> >>> >>> >>> --------------------------------------------------------------------- >>> This transmission (including any attachments) may contain >>> confidential information, privileged material (including material >>> protected by the solicitor-client or other applicable privileges), or >>> constitute non-public information. Any use of this information by >>> anyone other than the intended recipient is prohibited. If you have >>> received this transmission in error, please immediately reply to the >>> sender and delete this information from your system. Use, >>> dissemination, distribution, or reproduction of this transmission by >>> unintended recipients is not authorized and may be unlawful. >>> >>> _______________________________________________ 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 >>> >> >> -- >> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >> Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 >> Cisco Systems >> jdrosen@cisco.com FAX: (973) 952-5050 >> http://www.jdrosen.net PHONE: (973) 952-5000 >> http://www.cisco.com >> >> _______________________________________________ >> 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 > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ 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 From sip-bounces@ietf.org Mon Nov 07 12:33:40 2005 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 1EZAsG-0003Mb-FD; Mon, 07 Nov 2005 12:33:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZAsE-0003M3-DU; Mon, 07 Nov 2005 12:33:38 -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 MAA24196; Mon, 7 Nov 2005 12:33:12 -0500 (EST) Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZB7r-0002FJ-H0; Mon, 07 Nov 2005 12:49:49 -0500 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id DCC3152B; Mon, 7 Nov 2005 18:33:35 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Nov 2005 18:32:49 +0100 Received: from [138.85.5.53] ([138.85.5.53]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Nov 2005 18:32:48 +0100 Message-ID: <436F5A56.9030807@ericsson.com> Date: Mon, 07 Nov 2005 14:44:54 +0100 From: Magnus Westerlund User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Ling, Fan" Subject: Re: [AVT] RE: [Sip] RE: [Sip-implementors] media description in SDP is for sender or receiver? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Nov 2005 17:32:49.0390 (UTC) FILETIME=[4614F8E0:01C5E3C1] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.7 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, someshss@yahoo.com, sip-implementors@cs.columbia.edu, IETF AVT WG X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi Ling, See inline. Ling, Fan wrote: > Magnus, > You are dead on on the issues we are concerned about. Initially, our > understanding is the same as yours. However, when we proceed from > one-to-one video telephony application to multiparty video conference > application, the same understanding brings in some trouble. > Let's assume "MPEG4 simple profile level 1" is the negotiated codec. > In one-to-one video telephony, both ends can use different video sending > parameters, that is, "config=" or VOL parameters, both ends decoder just > configure itself to the incoming video bitstream's setting. In > multiparty conference, this means any one terminal has to configure its > multiple decoders according to different incoming bitstreams. This makes > the system a lot more complicated. I don't see that you can avoid this. You anyway need to save the per stream decoder state, thus all active participants will result in state on the receiver side. However isn't the real issue in multi-party that in many of the setup scenarios you are not able to describe in the answer more than a single configuration. Thus you are forced to use the inband transport that is not as robust. > That's why we are coming back to the standards, to see whether there is > a rule that dictates that not only the codec type needs to be the same, > the video bitstream parameters (VOL) also needs to be the same for both > encoder and decoder. To my knowledge this is not possible. However input from video coding experts are solicited. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ 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 From sip-bounces@ietf.org Mon Nov 07 13:27:44 2005 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 1EZBia-000828-5U; Mon, 07 Nov 2005 13:27:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZBiY-00081x-KE; Mon, 07 Nov 2005 13:27:42 -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 NAA27418; Mon, 7 Nov 2005 13:27:16 -0500 (EST) Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZByD-0003mD-4J; Mon, 07 Nov 2005 13:43:53 -0500 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id jA7IR53M021228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 7 Nov 2005 10:27:06 -0800 Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id jA7IQEZl013287; Mon, 7 Nov 2005 10:27:03 -0800 (PST) Received: from NAEX08.na.qualcomm.com ([10.46.56.97]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 7 Nov 2005 10:26:54 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [AVT] RE: [Sip] RE: [Sip-implementors] media description in SDP is for sender or receiver? Date: Mon, 7 Nov 2005 10:26:53 -0800 Message-ID: Thread-Topic: [AVT] RE: [Sip] RE: [Sip-implementors] media description in SDP is for sender or receiver? Thread-Index: AcXjwWi/QGp2fP0gT+O0kSUWr+nDyQABh2lg From: "Ling, Fan" To: "Magnus Westerlund" X-OriginalArrivalTime: 07 Nov 2005 18:26:54.0624 (UTC) FILETIME=[D4646200:01C5E3C8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org, someshss@yahoo.com, sip-implementors@cs.columbia.edu, IETF AVT WG X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Magnus, As you pointed out, inband transport of VOL headers may be one solution. We also have explored this possibility. However, due to possible loss of RTP packets, this may cause corrupted images for one whole GOP, which can be several seconds long.=20 It looks like the current standards don't have a satisfactory solution to our problem. We are now looking for proprietary methods. Thanks for your wonderful comments and advices. Fan -----Original Message----- From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 Sent: Monday, November 07, 2005 5:45 AM To: Ling, Fan Cc: sip@ietf.org; sip-implementors@cs.columbia.edu; someshss@yahoo.com; IETF AVT WG Subject: Re: [AVT] RE: [Sip] RE: [Sip-implementors] media description in SDP is for sender or receiver? Hi Ling, See inline. Ling, Fan wrote: > Magnus, > You are dead on on the issues we are concerned about. Initially, our > understanding is the same as yours. However, when we proceed from > one-to-one video telephony application to multiparty video conference > application, the same understanding brings in some trouble. > Let's assume "MPEG4 simple profile level 1" is the negotiated codec.=20 > In one-to-one video telephony, both ends can use different video sending > parameters, that is, "config=3D" or VOL parameters, both ends decoder just > configure itself to the incoming video bitstream's setting. In > multiparty conference, this means any one terminal has to configure its > multiple decoders according to different incoming bitstreams. This makes > the system a lot more complicated. I don't see that you can avoid this. You anyway need to save the per=20 stream decoder state, thus all active participants will result in state=20 on the receiver side. However isn't the real issue in multi-party that in many of the setup=20 scenarios you are not able to describe in the answer more than a single=20 configuration. Thus you are forced to use the inband transport that is=20 not as robust. > That's why we are coming back to the standards, to see whether there is > a rule that dictates that not only the codec type needs to be the same, > the video bitstream parameters (VOL) also needs to be the same for both > encoder and decoder. To my knowledge this is not possible. However input from video coding=20 experts are solicited. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ 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 From sip-bounces@ietf.org Mon Nov 07 14:52:15 2005 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 1EZD2N-00066H-Dw; Mon, 07 Nov 2005 14:52:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZD2L-000669-3n for sip@megatron.ietf.org; Mon, 07 Nov 2005 14:52:13 -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 OAA03768 for ; Mon, 7 Nov 2005 14:51:46 -0500 (EST) Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZDHy-0006cP-13 for sip@ietf.org; Mon, 07 Nov 2005 15:08:24 -0500 Received: (qmail 18498 invoked by uid 0); 7 Nov 2005 19:51:59 -0000 Received: from unknown (HELO BEMBUSTER) ([81.59.101.130]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 7 Nov 2005 19:51:59 -0000 Message-ID: <006401c5e3d4$b6427df0$6402a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "Jonathan Rosenberg" References: <436E75DD.8060107@cisco.com> <003e01c5e31f$2036c9c0$6402a8c0@BEMBUSTER> <436F6B7C.4000400@cisco.com> Subject: Re: [Sip] GRUU (was Whats wrong with Supported. Date: Mon, 7 Nov 2005 20:51:57 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: 1.2 (+) X-Scan-Signature: a8041eca2a724d631b098c15e9048ce9 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, dean.willis@softarmor.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I was thinking about a PIDF document with 2 contact entries, one for an older device that does not support GRUUs (and published a non-GRUU) and one for a newer one. Sure, you can always use trial-and-error, which is what current implementations will do anyway. Having a GRUU-indication would make little - but not 0 - difference What bothers me is not if GRUUs are recognisable or not, but more the inconsistency of doing it in some cases (dialog-creating requests and responses) and not in others. The current Supported: mechanism is mixing two things - support for GRUUs and their usage. What if the UAC does not manage to obtain a GRUU, e.g. because the registrar does not support it? Then it could not insert a Supported header anymore, because that would be interpreted as Contact=GRUU. So from the other side the UAC seems to have lost support for GRUUs? ----- Original Message ----- From: "Jonathan Rosenberg" To: "Jeroen van Bemmel" Cc: "Andrew Allen" ; ; Sent: Monday, November 07, 2005 3:58 PM Subject: Re: [Sip] GRUU (was Whats wrong with Supported. > Sorry I replied without having correctly understood your response. > > The pres URI is not going to be suitable for reaching the service, since > its not a service URI at all. Its an identifier for the presentity. You > might try different services, sure, but those don't represent an > alternative for reaching the service you have chosen. If you knew that the > for some service wasn't a gruu, would that mean you'd give up > and use a different service entirely? No. You'd try the service you want, > and if it can't be reached (timeout or whatever), you'd then try something > else. No need to know whether the is a gruu or not. > > -Jonathan R. > > Jeroen van Bemmel wrote: > >> Jonathan, >> >> What about a PIDF document with one or more contact elements and a pres: >> URI? >> Similar to the example in section 6.3 of >> draft-ietf-sipping-cc-transfer-05 that Paul mentioned, there is a choice >> (both amongst contacts and between contact / pres: URI if the contact is >> not a GRUU) >> >> Regards, >> Jeroen >> >> ----- Original Message ----- From: "Jonathan Rosenberg" >> >> To: "Andrew Allen" >> Cc: ; >> Sent: Sunday, November 06, 2005 10:30 PM >> Subject: Re: [Sip] GRUU (was Whats wrong with Supported. (was: Alert-Info >> Idea) >> >> >>> I still don't believe its needed. >>> >>> The reason is, that in places where a GRUU appears along with an >>> alternate choice (i.e., a contact), you have the Supported header field >>> telling you whether it is or not. In places where a GRUU appears solo >>> (like a web page or in a Refer-To header field), you don't really have >>> another choice but to just use it, so what is the point in signaling >>> that it is or isnt a gruu? >>> >>> The point is, the contents of Refer-To, Contact and so on are SUPPOSED >>> to have the gruu property to begin with; the problem is we never had a >>> way for that to be an easily guaranteed property. >>> >>> -Jonathan R. >>> >>> Andrew Allen wrote: >>> >>>> While I agree with the sentiments the fact is that pre-GRUU devices >>>> will not be able to signal that they don't support GRUU and will not >>>> even be aware that their URI is not a GRUU. >>>> >>>> Therefore are we not forced to indicate that the URI is a GRUU so we >>>> can tell between those URIs that are GRUUs and those that may not be? >>>> -------------------------- Andrew Allen Manager Standards Research >>>> In Motion Ltd BlackBerry Mobile +1 847 809 8636 http://www.rim.com/ >>>> >>>> Sent from my BlackBerry Wireless Handheld >>>> >>>> >>>> -----Original Message----- From: sip-bounces@ietf.org To: Dean Willis >>>> CC: Sip Sent: Fri Nov 04 13:15:13 2005 Subject: RE: [Sip] GRUU (was >>>> Whats wrong with Supported. (was: Alert-Info Idea) >>>> >>>> Very true. You can always try, fail, then take appropriate steps. I'm >>>> just talking about short circuiting the failure. You don't know that >>>> a GRUU will succeed, but you have a fairly high level of confidence >>>> that a non-GRUU will fail. I really hope that this becomes the 1% >>>> case with 99% of URIs are GRUUs. With that long term goal in mind, >>>> I'd prefer to signal that something is not a GRUU rather than always >>>> have to signal that it is one. >>>> >>>> -----Original Message----- From: Dean Willis >>>> [mailto:dean.willis@softarmor.com] Sent: Friday, November 04, 2005 >>>> 9:50 AM To: Sean Olson Cc: Jeroen van Bemmel; Sip Subject: Re: [Sip] >>>> GRUU (was Whats wrong with Supported. (was: Alert-Info Idea) >>>> >>>> >>>> On Nov 3, 2005, at 6:57 PM, Sean Olson wrote: >>>> >>>> >>>>> Well, if GRUU == Globally Routable UA URI, and you treat a URI as >>>>> a GRUU which does not have one of these properties, things will >>>>> break. If you care when things break, you would want to know in >>>>> advance. This >>>> >>>> >>>> >>>>> would apply to UAs, proxies, etc. You could make the argument that >>>>> all >>>> >>>> >>>> >>>>> URIs should be GRUUs so what you really want is a property that >>>>> says a >>>> >>>> >>>> >>>>> URI is *not* at a GRUU and assume all others are ;-) >>>> >>>> >>>> >>>> >>>> So, exactly what do you do differently if you think something might >>>> not be GRUU? >>>> >>>> You've been given this URI. Don't you just have to try it and see if >>>> it works, and if not then back off to some other behavior? >>>> >>>> Remember, there's really no such thing as an absolutely universally >>>> reachable URI. It might b a URI on the public internet that your corp >>>> firewall has decided to block. It might just stop working between >>>> the time you get it and the time you try to use it. The Net might >>>> partition in between you. And so on. >>>> >>>> -- Dean >>>> >>>> >>>> _______________________________________________ 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 >>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> This transmission (including any attachments) may contain >>>> confidential information, privileged material (including material >>>> protected by the solicitor-client or other applicable privileges), or >>>> constitute non-public information. Any use of this information by >>>> anyone other than the intended recipient is prohibited. If you have >>>> received this transmission in error, please immediately reply to the >>>> sender and delete this information from your system. Use, >>>> dissemination, distribution, or reproduction of this transmission by >>>> unintended recipients is not authorized and may be unlawful. >>>> >>>> _______________________________________________ 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 >>>> >>> >>> -- >>> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >>> Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 >>> Cisco Systems >>> jdrosen@cisco.com FAX: (973) 952-5050 >>> http://www.jdrosen.net PHONE: (973) 952-5000 >>> http://www.cisco.com >>> >>> _______________________________________________ >>> 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 >> >> > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com _______________________________________________ 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 From sip-bounces@ietf.org Mon Nov 07 16:39:04 2005 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 1EZEhk-0006Mz-3y; Mon, 07 Nov 2005 16:39:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZEhi-0006Mu-3u for sip@megatron.ietf.org; Mon, 07 Nov 2005 16:39:02 -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 QAA09414 for ; Mon, 7 Nov 2005 16:38:36 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZExM-00013n-GC for sip@ietf.org; Mon, 07 Nov 2005 16:55:14 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 07 Nov 2005 13:38:51 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jA7Lc8OJ003586; Mon, 7 Nov 2005 13:38:47 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 7 Nov 2005 16:38:42 -0500 Received: from [209.52.109.209] ([10.86.242.137]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 7 Nov 2005 16:38:22 -0500 Message-ID: <436FC946.6000902@cisco.com> Date: Mon, 07 Nov 2005 16:38:14 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeroen van Bemmel Subject: Re: [Sip] GRUU (was Whats wrong with Supported. References: <436E75DD.8060107@cisco.com> <003e01c5e31f$2036c9c0$6402a8c0@BEMBUSTER> <436F6B7C.4000400@cisco.com> <006401c5e3d4$b6427df0$6402a8c0@BEMBUSTER> In-Reply-To: <006401c5e3d4$b6427df0$6402a8c0@BEMBUSTER> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Nov 2005 21:38:37.0711 (UTC) FILETIME=[9CC429F0:01C5E3E3] X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, dean.willis@softarmor.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org inline. Jeroen van Bemmel wrote: > I was thinking about a PIDF document with 2 contact entries, one for an > older device that does not support GRUUs (and published a non-GRUU) and > one for a newer one. Sure, you can always use trial-and-error, which is > what current implementations will do anyway. Having a GRUU-indication > would make little - but not 0 - difference Well, firstly to be clear, a "device" is not represented in a presence document through a SIP URI. If you are talking about a "service" (i.e., a ), I doubt that the element which constructs the presence document would do it with something that doesn't at least have the property that it works for recipients; typically if a GRUU is not there it would be an AOR. > > What bothers me is not if GRUUs are recognisable or not, but more the > inconsistency of doing it in some cases (dialog-creating requests and > responses) and not in others. Well, I tihnk the real problem is that, to date, folks have not included URI in Contact with the gruu property, and so implementations have had to resort to hacks. The GRUU spec makes the need for the hacks go away - things should work as they originally should have. So, it seems wrong to me to hard-code into the URI a flag which merely says that you don't need to do the hacks that you needed to do before. > > The current Supported: mechanism is mixing two things - support for > GRUUs and their usage. What if the UAC does not manage to obtain a GRUU, > e.g. because the registrar does not support it? Then it could not insert > a Supported header anymore, because that would be interpreted as > Contact=GRUU. So from the other side the UAC seems to have lost support > for GRUUs? Ah, now that is a good point. If this happens, then there is a difference between the presence of the Supported header field and whether or not the contact is a gruu. I would still argue against a specific URI parameter for this, however. We want to be moving AWAY from telling people to try various tricks to get a URI to work. It ought to just work - thats what gruu allows. As such, in the case above, I'd still argue that the right thing is to try the contact URI, as it may work anyway... -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ 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 From sip-bounces@ietf.org Mon Nov 07 17:24:40 2005 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 1EZFPs-0008F7-T5; Mon, 07 Nov 2005 17:24:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZFPr-0008Ez-4j for sip@megatron.ietf.org; Mon, 07 Nov 2005 17:24:39 -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 RAA11979 for ; Mon, 7 Nov 2005 17:24:13 -0500 (EST) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZFfU-0002Hn-MB for sip@ietf.org; Mon, 07 Nov 2005 17:40:52 -0500 Received: from [209.52.153.104] ([209.52.153.104]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id jA7MTjFO020978 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 7 Nov 2005 16:29:46 -0600 In-Reply-To: <436E4E99.3060309@cisco.com> References: <50B1CBA96870A34799A506B2313F266706D5158B@ntht201e.siemenscomms.co.uk> <4368D156.3080106@cisco.com> <1130956108.30072.54.camel@cdhcp139.pingtel.com> <436990C6.9040002@cisco.com> <1130994755.2569.30.camel@cdhcp139.pingtel.com> <436E4E99.3060309@cisco.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] GRUU (was Whats wrong with Supported. Date: Mon, 7 Nov 2005 16:24:26 -0600 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Cc: Sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Nov 6, 2005, at 12:42 PM, Jonathan Rosenberg wrote: > > The idea is this - the GRUU spec basically says, at MUST strength, > that you have to use your GRUU in the contact of dialog forming > requests and responses. Supported:gruu implies ONLY that the UA > sending the request supports the gruu spec. As a consequence, since > the gruu spec implies that a compliant implementation also place a > GRUU into the contact, the presence of Supported:gruu ALSO implies > that the request contains a GRUU in the contact. > I think I'm OK with this, but the gruu text should make this more clear. -- Dean _______________________________________________ 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 From sip-bounces@ietf.org Mon Nov 07 17:31:57 2005 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 1EZFWv-0000fR-Fq; Mon, 07 Nov 2005 17:31:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZFWt-0000ew-TP for sip@megatron.ietf.org; Mon, 07 Nov 2005 17:31:56 -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 RAA12585 for ; Mon, 7 Nov 2005 17:31:30 -0500 (EST) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZFma-0002YK-G1 for sip@ietf.org; Mon, 07 Nov 2005 17:48:09 -0500 Received: from [209.52.153.104] ([209.52.153.104]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id jA7MbBS5021024 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 7 Nov 2005 16:37:12 -0600 In-Reply-To: <436E77E5.1060208@cisco.com> References: <436D2E58.4020902@softarmor.com> <436E77E5.1060208@cisco.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <54A270BA-1E78-46B3-9EC1-B38C504E9C2A@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] GRUU (was Whats wrong with Supported. (was: Alert-Info Idea) Date: Mon, 7 Nov 2005 16:31:53 -0600 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > > Err, you lost me there. Service route (and Path) remain broken > AFAICT... > 1) if the Contact: actually included the entire route from the serving proxy to the UA, including the UA's URI, then Contact essentially does " Path". 2) If the contact: actually included the entire route from the UA to the serving proxy, it essentially does "Service-Route". So if I register, and the registrar stores both #1 and #2 "Contacts" for my AOR, uses #1 contacts to "reach" my UA, and returns #2 contacts in the 200 OK response for use by my UA, we need neither Path nor Service-Route. -- Dean _______________________________________________ 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 From sip-bounces@ietf.org Mon Nov 07 17:46:25 2005 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 1EZFkv-0005r7-KD; Mon, 07 Nov 2005 17:46:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZFkt-0005r2-Ug for sip@megatron.ietf.org; Mon, 07 Nov 2005 17:46:24 -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 RAA14111 for ; Mon, 7 Nov 2005 17:45:58 -0500 (EST) Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZG0Z-0003BI-Nn for sip@ietf.org; Mon, 07 Nov 2005 18:02:37 -0500 Received: (qmail 5556 invoked by uid 0); 7 Nov 2005 22:45:56 -0000 Received: from unknown (HELO BEMBUSTER) ([81.59.101.130]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 7 Nov 2005 22:45:56 -0000 Message-ID: <007f01c5e3ed$034ed720$6402a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "Jonathan Rosenberg" References: <436E75DD.8060107@cisco.com> <003e01c5e31f$2036c9c0$6402a8c0@BEMBUSTER> <436F6B7C.4000400@cisco.com> <006401c5e3d4$b6427df0$6402a8c0@BEMBUSTER> <436FC946.6000902@cisco.com> Subject: Re: [Sip] GRUU (was Whats wrong with Supported. Date: Mon, 7 Nov 2005 23:45:54 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: 1.2 (+) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, dean.willis@softarmor.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org inline ----- Original Message ----- From: "Jonathan Rosenberg" To: "Jeroen van Bemmel" Cc: "Andrew Allen" ; ; Sent: Monday, November 07, 2005 10:38 PM Subject: Re: [Sip] GRUU (was Whats wrong with Supported. > inline. > > Jeroen van Bemmel wrote: > >> I was thinking about a PIDF document with 2 contact entries, one for an >> older device that does not support GRUUs (and published a non-GRUU) and >> one for a newer one. Sure, you can always use trial-and-error, which is >> what current implementations will do anyway. Having a GRUU-indication >> would make little - but not 0 - difference > > Well, firstly to be clear, a "device" is not represented in a presence > document through a SIP URI. If you are talking about a "service" (i.e., a > ), I doubt that the element which constructs the presence document > would do it with something that doesn't at least have the property that it > works for recipients; typically if a GRUU is not there it would be an AOR. > >> >> What bothers me is not if GRUUs are recognisable or not, but more the >> inconsistency of doing it in some cases (dialog-creating requests and >> responses) and not in others. > > Well, I tihnk the real problem is that, to date, folks have not included > URI in Contact with the gruu property, and so implementations have had to > resort to hacks. The GRUU spec makes the need for the hacks go away - > things should work as they originally should have. So, it seems wrong to > me to hard-code into the URI a flag which merely says that you don't need > to do the hacks that you needed to do before. > > >> >> The current Supported: mechanism is mixing two things - support for GRUUs >> and their usage. What if the UAC does not manage to obtain a GRUU, e.g. >> because the registrar does not support it? Then it could not insert a >> Supported header anymore, because that would be interpreted as >> Contact=GRUU. So from the other side the UAC seems to have lost support >> for GRUUs? > > Ah, now that is a good point. > > If this happens, then there is a difference between the presence of the > Supported header field and whether or not the contact is a gruu. > > I would still argue against a specific URI parameter for this, however. We > want to be moving AWAY from telling people to try various tricks to get a > URI to work. It ought to just work - thats what gruu allows. As such, in > the case above, I'd still argue that the right thing is to try the contact > URI, as it may work anyway... > OK, so in that case: what if we just let Supported: gruu mean what it says - that the UAC supports GRUUs, in the sense that it knows how to request them from a registrar and to use them as Contact when available. Supported would not be a guarantee that the Contact is a GRUU (but does make it more likely), its absence means that the Contact was not obtained from a registrar or provisioned administratively as a GRUU (but may still work). A UAC MUST use a GRUU as Contact, that is when it is provided with one. It MUST insert Supported: gruu in all dialog-creating requests and responses (btw, in addition to 2xx responses to INVITE I think it should also be included in 1xx responses with a to-tag, in particular 100rel responses) Implementations SHOULD assume that Contacts are GRUUs (and act accordingly), regardless of the presence or absence of a Supported: gruu header. In particular, the Refer-To example SHOULD use the Contact URI (this leaves some room for implementations to deviate, if they really see a need) PS I like the suggestion of loose contact routing, as a side effect it would obviate the need for special handling of the 'grid' parameter Jeroen > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com _______________________________________________ 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 From sip-bounces@ietf.org Mon Nov 07 20:06:10 2005 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 1EZHwA-0006xi-Ou; Mon, 07 Nov 2005 20:06:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZHw7-0006py-Qc for sip@megatron.ietf.org; Mon, 07 Nov 2005 20:06:09 -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 UAA28017 for ; Mon, 7 Nov 2005 20:05:41 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZIBo-0000jf-I4 for sip@ietf.org; Mon, 07 Nov 2005 20:22:21 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 07 Nov 2005 17:05:57 -0800 X-IronPort-AV: i="3.97,302,1125903600"; d="scan'208"; a="227947485:sNHT25465520" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id jA815sZ3010441 for ; Mon, 7 Nov 2005 17:05:55 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 7 Nov 2005 20:05:54 -0500 Received: from [209.52.109.209] ([10.86.240.215]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 7 Nov 2005 20:05:54 -0500 Message-ID: <436FF9F0.3040504@cisco.com> Date: Mon, 07 Nov 2005 20:05:52 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Nov 2005 01:05:54.0165 (UTC) FILETIME=[91787250:01C5E400] X-Spam-Score: 0.2 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit Subject: [Sip] comments on draft-elwell-sip-connected-identity-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Thanks for putting this together. As I have posted previously, I support work in this area. On the mechanism itself, I prefer the approach that the connected-party identity is conveyed in the To header field in the response of the dialog forming request. This DOES mean that you will modify the URI in the response from the request. Though they are supposed to be the same (and also in subsequent requests in the reverse direction), 3261 recognizes that this may change. Note Section 12.2.1.1: Usage of the URI from the To and From fields in the original request within subsequent requests is done for backwards compatibility with RFC 2543, which used the URI for dialog identification. In this specification, only the tags are used for dialog identification. It is expected that mandatory reflection of the original To and From URI in mid-dialog requests will be deprecated in a subsequent revision of this specification. To support modifying the identity, an UPDATE can be sent with a new From header field. I do believe an UPDATE without an SDP is acceptable. Indeed, the original design of UPDATE was to allow both session updates and other updates. UPDATE had been conceived as a fix to the HERFP problem as well, in which case its purpose was to update non-session stuff. Note that, if an UPDATE contains no SDP, there would be no SDP in the 200 OK. Unlike INVITE< there is no ACK which would allow an offer/answer exchange to start with an offer in a response. Using To/From means that we don't need to invent new header fields and define a variation of the authentication service which is the same in every way as the one in draft-ietf-sip-identity, but differs in the field names. We can just reuse the identity service as defined. I think its important to mention in the security considerations section that this mechanism provides no protection whatsoever against malicious forwarding. It provides no way to know whether the call went to the intended recipient or not. The only way to determine whether or not the response identity is to be trusted is based on the trustworthiness of the domain that has signed the response. This does mean that a subscriber could provide their own authentication service and place an Identity in a response; such identities should be stripped out and re-created by the proxy for the domain. However, if a domain does not perform such stripping (presumably because it doesnt implement response identity at all), the user can assert whatever identity they like within domains for which they can obtain a certificate. Of course, that is no different than request identity. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ 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 From sip-bounces@ietf.org Mon Nov 07 21:34:27 2005 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 1EZJJb-0007bC-FS; Mon, 07 Nov 2005 21:34:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZJJY-0007aY-Mh for sip@megatron.ietf.org; Mon, 07 Nov 2005 21:34:24 -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 VAA03149 for ; Mon, 7 Nov 2005 21:33:57 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZJZG-000329-Bs for sip@ietf.org; Mon, 07 Nov 2005 21:50:39 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 07 Nov 2005 18:34:16 -0800 Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jA82Y4Nv003684; Mon, 7 Nov 2005 18:34:14 -0800 (PST) Received: from 10.21.120.150 ([10.21.120.150]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Tue, 8 Nov 2005 02:34:42 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Mon, 07 Nov 2005 15:53:44 -0800 From: Cullen Jennings To: "sip@ietf.org" Message-ID: Thread-Topic: Comment on draft-ietf-sip-connect-reuse-04 Thread-Index: AcXj9nx9uy3l0U/pEdqiNgARJEEJ/A== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: Rohan Mahy Subject: [Sip] Comment on draft-ietf-sip-connect-reuse-04 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Two issues... This is very difficult to implement for most people. If you do a DNS lookup of an A record, this requires you to get every IP address then look at your alias to see if you have one that matches - and not do load balancing. This is hard unless you have your own DNS resolve library which most people do not. Second, I don't think it works. If a server runs two virtual domain a.com and b.com both on 1.2.3.4:5060 and use the TLS extended hello to separate them, then if it connects to C as A.com, and later C wants to send a sips message to B.com, it will deliver it over the connection to A.com which is totally broken from a security point of view. _______________________________________________ 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 From sip-bounces@ietf.org Tue Nov 08 01:39:06 2005 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 1EZN8L-0000H7-RV; Tue, 08 Nov 2005 01:39:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZN8K-0000H0-1J for sip@megatron.ietf.org; Tue, 08 Nov 2005 01:39:04 -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 BAA14228 for ; Tue, 8 Nov 2005 01:38:37 -0500 (EST) Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZNO2-0000qa-VR for sip@ietf.org; Tue, 08 Nov 2005 01:55:21 -0500 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0IPM00K01ICAQ0@siemenscomms.co.uk> for sip@ietf.org; Tue, 08 Nov 2005 06:36:10 +0000 (GMT) Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0IPM00FB6ICANJ@siemenscomms.co.uk>; Tue, 08 Nov 2005 06:36:10 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Tue, 08 Nov 2005 06:38:41 +0000 Content-return: allowed Date: Tue, 08 Nov 2005 06:38:27 +0000 From: "Elwell, John" Subject: RE: [Sip] comments on draft-elwell-sip-connected-identity-00 To: Jonathan Rosenberg , IETF SIP List Message-id: <50B1CBA96870A34799A506B2313F266706FC306E@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.2 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: 7BIT Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Jonathan, Thanks for your comments - see below. John > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Sent: 08 November 2005 01:06 > To: IETF SIP List > Subject: [Sip] comments on draft-elwell-sip-connected-identity-00 > > Thanks for putting this together. As I have posted > previously, I support > work in this area. > > On the mechanism itself, I prefer the approach that the > connected-party > identity is conveyed in the To header field in the response of the > dialog forming request. This DOES mean that you will modify > the URI in > the response from the request. Though they are supposed to be > the same > (and also in subsequent requests in the reverse direction), 3261 > recognizes that this may change. Note Section 12.2.1.1: > > Usage of the URI from the To and From fields in the original > request within subsequent requests is done for backwards > compatibility with RFC 2543, which used the URI for dialog > identification. In this specification, only the tags > are used for > dialog identification. It is expected that mandatory > reflection > of the original To and From URI in mid-dialog requests will be > deprecated in a subsequent revision of this specification. [JRE] I would very much like to go in this direction, but I feared there was too much opposition at an earlier IETF. > > > To support modifying the identity, an UPDATE can be sent with > a new From > header field. > > I do believe an UPDATE without an SDP is acceptable. Indeed, the > original design of UPDATE was to allow both session updates and other > updates. UPDATE had been conceived as a fix to the HERFP problem as > well, in which case its purpose was to update non-session stuff. Note > that, if an UPDATE contains no SDP, there would be no SDP in > the 200 OK. > Unlike INVITE< there is no ACK which would allow an offer/answer > exchange to start with an offer in a response. > > Using To/From means that we don't need to invent new header > fields and > define a variation of the authentication service which is the same in > every way as the one in draft-ietf-sip-identity, but differs in the > field names. We can just reuse the identity service as defined. > > I think its important to mention in the security > considerations section > that this mechanism provides no protection whatsoever against > malicious > forwarding. It provides no way to know whether the call went to the > intended recipient or not. The only way to determine whether > or not the > response identity is to be trusted is based on the trustworthiness of > the domain that has signed the response. This does mean that a > subscriber could provide their own authentication service and > place an > Identity in a response; such identities should be stripped out and > re-created by the proxy for the domain. However, if a domain does not > perform such stripping (presumably because it doesnt > implement response > identity at all), the user can assert whatever identity they > like within > domains for which they can obtain a certificate. Of course, > that is no > different than request identity. [JRE]Good points. > > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Director, Service Provider VoIP Architecture Parsippany, NJ > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > > _______________________________________________ > 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 From sip-bounces@ietf.org Tue Nov 08 11:59:55 2005 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 1EZWp9-0004rd-8M; Tue, 08 Nov 2005 11:59:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZWp7-0004qU-It for sip@megatron.ietf.org; Tue, 08 Nov 2005 11:59:53 -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 LAA17141 for ; Tue, 8 Nov 2005 11:59:27 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZX4v-0000vN-Qc for sip@ietf.org; Tue, 08 Nov 2005 12:16:16 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 08 Nov 2005 08:59:41 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jA8Gwxee000132; Tue, 8 Nov 2005 08:59:38 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 8 Nov 2005 08:59:38 -0800 Received: from [10.21.88.255] ([10.21.88.255]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 8 Nov 2005 08:59:38 -0800 Message-ID: <43703065.9070806@cisco.com> Date: Mon, 07 Nov 2005 23:58:13 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Sip] GRUU (was Whats wrong with Supported. References: <50B1CBA96870A34799A506B2313F266706D5158B@ntht201e.siemenscomms.co.uk> <4368D156.3080106@cisco.com> <1130956108.30072.54.camel@cdhcp139.pingtel.com> <436990C6.9040002@cisco.com> <1130994755.2569.30.camel@cdhcp139.pingtel.com> <436E4E99.3060309@cisco.com> In-Reply-To: <436E4E99.3060309@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Nov 2005 16:59:38.0112 (UTC) FILETIME=[CD99D000:01C5E485] X-Spam-Score: 0.4 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Cc: Sip , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Jonathan Rosenberg wrote: >> Ok, having looked at the GRUU draft again, I'd like to consider this >> a WGLC comment on GRUU, which I shall paraphrase as "What do you >> mean, Supported:?" >> >> One could make the argument that a UA that supports GRUU would never, >> for any reason, populate the Contact in a transaction other than >> REGISTER (or the 200 OK thereto) with something that is not a GRUU, >> and that one can therefore assume that the presence of Supported: >> gruu in a message outside a REGISTER transaction means that the >> contact is a GRUU. But if one were to make that argument, one would >> need to spell this out clearly. > > That is the intent. > > The idea is this - the GRUU spec basically says, at MUST strength, that > you have to use your GRUU in the contact of dialog forming requests and > responses. Supported:gruu implies ONLY that the UA sending the request > supports the gruu spec. As a consequence, since the gruu spec implies > that a compliant implementation also place a GRUU into the contact, the > presence of Supported:gruu ALSO implies that the request contains a GRUU > in the contact. And in the Refer-To of REFER? And in *all* the Contacts of a 3xx? And in ???. What happens when there are multiple addresses in the message and only some of them are known to have the GRUU property? For instance, suppose I'm sending a REFER, and I know the Refer-To is a gruu, but I wasn't able to get a gruu for the Contact in my own REFER? Do I put a Supported: gruu in the REFER request? Paul _______________________________________________ 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 From sip-bounces@ietf.org Tue Nov 08 11:59:56 2005 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 1EZWpA-0004sF-OP; Tue, 08 Nov 2005 11:59:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZWp7-0004qZ-TA for sip@megatron.ietf.org; Tue, 08 Nov 2005 11:59:53 -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 LAA17139 for ; Tue, 8 Nov 2005 11:59:27 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZX4w-0000vO-NM for sip@ietf.org; Tue, 08 Nov 2005 12:16:16 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 08 Nov 2005 08:59:43 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jA8GxSeC000576; Tue, 8 Nov 2005 08:59:40 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 8 Nov 2005 08:59:39 -0800 Received: from [10.21.88.255] ([10.21.88.255]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 8 Nov 2005 08:59:38 -0800 Message-ID: <43703537.7090600@cisco.com> Date: Tue, 08 Nov 2005 00:18:47 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Sip] Whats wrong with Supported. References: <50B1CBA96870A34799A506B2313F266706D5158B@ntht201e.siemenscomms.co.uk> <4368D156.3080106@cisco.com> <1130956108.30072.54.camel@cdhcp139.pingtel.com> <436990C6.9040002@cisco.com> <436E51F0.1030906@cisco.com> In-Reply-To: <436E51F0.1030906@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Nov 2005 16:59:38.0846 (UTC) FILETIME=[CE09CFE0:01C5E485] X-Spam-Score: 0.6 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: 7bit Cc: Sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Jonathan Rosenberg wrote: > inline. > > Paul Kyzivat wrote: > > >> My other problem with Supported, Required, Accept, Accept-Language, >> ... is that there is no clear definition of the scope over which this >> declaration applies. Some possible interpretations are: >> 1) just this message >> 2) this transaction >> 3) until the time of some action that the recipient is >> expected to take as a result of this message >> 4) for the remainder of this dialog >> 5) for the remainder of this dialog unless >> overridden later in the dialog >> 6) for all messages with this UA >> 7) for all messages with this UA unless >> overridden later >> >> OPTIONS requests are supposed to specify these things. That seems to >> imply to imply the scope must be 6 or 7. But even if that is true, how >> would the recipient know uniquely when it is talking to the same UA? >> Without that it can't know when its prior knowledge applies. > > > I agree that this has really become a mess. The idea when 3261 was being > written IIRC is that its really (6), but this doesn't work awfully well > since, as you say, you don't know if you're talking to the same UA when > you send a request to a particular URI. > > Most of these headers are inherited from HTTP, where they had two > different meanings. Some, like Allow, were really properties of the > resource itself. Others, like Accept, were useful for the transaction > only to indicate what can come in the response. SIP "borrowed" these, > but the different nature of SIP resources compared to HTTP ones has > introduced a lot of confusion here. > > The difficulty as Paul has pointed out is that support for various > extensions, headers, and methods is ultimately a property of a > particular instance of software. However, a typical SIP URI, an in > particular an AOR like sip:joe@example.com, represents a user that can > be reached at possibly many pieces of software. To make matters messier, > software can also be upgraded over time, so even if a UA routed to a > particular instance, these properties arent truly static. In some cases, whether something is supported depends on context - the same UA may support it in one context, but not another. The Accept header is a good case of this: I might Accept SDP in INVITE, UPDATE, PRACK, and their responses, but not in other places. Or I might support multipart/alternative in MESSAGE but not elsewhere. > Things get a little cleaner if you assume that an instance ID (in the > gruu sense) changes for a UA when its firmware or software changes. In > such a case, there could be a static relationship between the Allow, > Accept, etc. values and an instnace ID, and you could cache that > relationship. Using those values to guess how to construct a request > would then only be useful when sending a reuqest to a known instance. > That happens for mid-dialog requests, but also for requests targeted to > a gruu. That could help. > One question, though, is whether it is allowed to indicate different > capabilities for a UA instance depending who is asking. We have > generally allowed that for other things, and allowing it here (as 100rel > basically does) breaks the model that you could cache these properties > as associated with an instance ID, UNLESS you basically changed instance > IDs if you change values of Allow, Accept, etc. I didn't follow that. If I am disclosing capabilities, and do so differently when talking to X than Y, then I see no problem with X and Y caching those results as long as I am consistent in what I report to each of them. > We should definitely try and figure out what the scope really is and put > that somewhere in a document, or at least into the bugzilla instance. Yeah, as things stand nobody knows when they should/needn't insert these headers, and nobody knows how to remember them. This doesn't bode well for interoperability. Paul _______________________________________________ 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 From sip-bounces@ietf.org Tue Nov 08 12:26:12 2005 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 1EZXEa-0005RA-PO; Tue, 08 Nov 2005 12:26:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZXEY-0005R5-Sd for sip@megatron.ietf.org; Tue, 08 Nov 2005 12:26:11 -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 MAA19018 for ; Tue, 8 Nov 2005 12:25:44 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZXUO-0001nE-Jr for sip@ietf.org; Tue, 08 Nov 2005 12:42:34 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 08 Nov 2005 12:25:58 -0500 X-IronPort-AV: i="3.97,305,1125892800"; d="scan'208"; a="75278789:sNHT25472872" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jA8HPAxc002435; Tue, 8 Nov 2005 12:25:55 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 8 Nov 2005 12:25:50 -0500 Received: from [209.52.152.168] ([10.86.242.85]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 8 Nov 2005 12:25:49 -0500 Message-ID: <4370DF9D.7000408@cisco.com> Date: Tue, 08 Nov 2005 12:25:49 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Sip] Whats wrong with Supported. References: <50B1CBA96870A34799A506B2313F266706D5158B@ntht201e.siemenscomms.co.uk> <4368D156.3080106@cisco.com> <1130956108.30072.54.camel@cdhcp139.pingtel.com> <436990C6.9040002@cisco.com> <436E51F0.1030906@cisco.com> <43703537.7090600@cisco.com> In-Reply-To: <43703537.7090600@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Nov 2005 17:25:49.0823 (UTC) FILETIME=[7669E0F0:01C5E489] X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: 7bit Cc: Sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org inline. Paul Kyzivat wrote: >> The difficulty as Paul has pointed out is that support for various >> extensions, headers, and methods is ultimately a property of a >> particular instance of software. However, a typical SIP URI, an in >> particular an AOR like sip:joe@example.com, represents a user that can >> be reached at possibly many pieces of software. To make matters >> messier, software can also be upgraded over time, so even if a UA >> routed to a particular instance, these properties arent truly static. > > > In some cases, whether something is supported depends on context - the > same UA may support it in one context, but not another. The Accept > header is a good case of this: I might Accept SDP in INVITE, UPDATE, > PRACK, and their responses, but not in other places. Or I might support > multipart/alternative in MESSAGE but not elsewhere. In principal this is a problem. Is it true in practice? If a particular extension can (according to the spec), be used with INVITE and UPDATE, and an implementation supports the spec, are there implementations that would only use it for INVITE and not UPDATE? My suspicion is that this is actually rare, and furthermore, that when it does happen, you really need to view it differently. The UA does SUPPORT the extension, it just elects not to utilize it. > >> Things get a little cleaner if you assume that an instance ID (in the >> gruu sense) changes for a UA when its firmware or software changes. In >> such a case, there could be a static relationship between the Allow, >> Accept, etc. values and an instnace ID, and you could cache that >> relationship. Using those values to guess how to construct a request >> would then only be useful when sending a reuqest to a known instance. >> That happens for mid-dialog requests, but also for requests targeted >> to a gruu. > > > That could help. > >> One question, though, is whether it is allowed to indicate different >> capabilities for a UA instance depending who is asking. We have >> generally allowed that for other things, and allowing it here (as >> 100rel basically does) breaks the model that you could cache these >> properties as associated with an instance ID, UNLESS you basically >> changed instance IDs if you change values of Allow, Accept, etc. > > > I didn't follow that. If I am disclosing capabilities, and do so > differently when talking to X than Y, then I see no problem with X and Y > caching those results as long as I am consistent in what I report to > each of them. Fair point. The bigger problem is if you change what you said to a particular caller, without changing instance ID. > >> We should definitely try and figure out what the scope really is and >> put that somewhere in a document, or at least into the bugzilla instance. > > > Yeah, as things stand nobody knows when they should/needn't insert these > headers, and nobody knows how to remember them. This doesn't bode well > for interoperability. In principal I suppose. I'm curious if anyone has seen interop problems in the wild as a consequence of this... -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ 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 From sip-bounces@ietf.org Tue Nov 08 12:59:35 2005 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 1EZXkt-0008Ub-Jm; Tue, 08 Nov 2005 12:59:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZXkr-0008Tm-8E for sip@megatron.ietf.org; Tue, 08 Nov 2005 12:59:33 -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 MAA22295 for ; Tue, 8 Nov 2005 12:59:06 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZY0h-0003AN-1r for sip@ietf.org; Tue, 08 Nov 2005 13:15:56 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 08 Nov 2005 09:59:22 -0800 X-IronPort-AV: i="3.97,305,1125903600"; d="scan'208"; a="228127882:sNHT30282056" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id jA8Hwuaw003267; Tue, 8 Nov 2005 09:59:20 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 8 Nov 2005 09:59:19 -0800 Received: from [10.21.88.255] ([10.21.88.255]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 8 Nov 2005 09:59:19 -0800 Message-ID: <4370E772.4030802@cisco.com> Date: Tue, 08 Nov 2005 12:59:14 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Sip] Whats wrong with Supported. References: <50B1CBA96870A34799A506B2313F266706D5158B@ntht201e.siemenscomms.co.uk> <4368D156.3080106@cisco.com> <1130956108.30072.54.camel@cdhcp139.pingtel.com> <436990C6.9040002@cisco.com> <436E51F0.1030906@cisco.com> <43703537.7090600@cisco.com> <4370DF9D.7000408@cisco.com> In-Reply-To: <4370DF9D.7000408@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Nov 2005 17:59:19.0232 (UTC) FILETIME=[241D5C00:01C5E48E] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: 7bit Cc: Sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org More inline. Paul Jonathan Rosenberg wrote: > Paul Kyzivat wrote: > >>> The difficulty as Paul has pointed out is that support for various >>> extensions, headers, and methods is ultimately a property of a >>> particular instance of software. However, a typical SIP URI, an in >>> particular an AOR like sip:joe@example.com, represents a user that >>> can be reached at possibly many pieces of software. To make matters >>> messier, software can also be upgraded over time, so even if a UA >>> routed to a particular instance, these properties arent truly static. >> >> >> In some cases, whether something is supported depends on context - the >> same UA may support it in one context, but not another. The Accept >> header is a good case of this: I might Accept SDP in INVITE, UPDATE, >> PRACK, and their responses, but not in other places. Or I might >> support multipart/alternative in MESSAGE but not elsewhere. > > In principal this is a problem. Is it true in practice? If a particular > extension can (according to the spec), be used with INVITE and UPDATE, > and an implementation supports the spec, are there implementations that > would only use it for INVITE and not UPDATE? > > My suspicion is that this is actually rare, and furthermore, that when > it does happen, you really need to view it differently. The UA does > SUPPORT the extension, it just elects not to utilize it. I suspect this is not a problem with options. But I think it is very likely a problem with content types. Consider a softphone that supports INVITE and MESSAGE. If done on a UA-wide basis, I think it must say Accept: application/sdp, text/plain But what is it going to do if I send it a MESSAGE containing an SDP body? It probably can't accept it. If it wants to refuse it, what error can it return? I think it must return 415: 21.4.13 415 Unsupported Media Type The server is refusing to service the request because the message body of the request is in a format not supported by the server for ^^^ the requested method. The server MUST return a list of acceptable ^^^^^^^^^^^^^^^^^^^^ formats using the Accept, Accept-Encoding, or Accept-Language header field, depending on the specific problem with the content. UAC processing of this response is described in Section 8.1.3.5. In that response it would have to include a new Accept header: Accept: text/plain to indicate what is valid for the MESSAGE. But this too is not clearly scoped to apply to the particular message. >>> Things get a little cleaner if you assume that an instance ID (in the >>> gruu sense) changes for a UA when its firmware or software changes. >>> In such a case, there could be a static relationship between the >>> Allow, Accept, etc. values and an instnace ID, and you could cache >>> that relationship. Using those values to guess how to construct a >>> request would then only be useful when sending a reuqest to a known >>> instance. That happens for mid-dialog requests, but also for requests >>> targeted to a gruu. >> >> That could help. >> >>> One question, though, is whether it is allowed to indicate different >>> capabilities for a UA instance depending who is asking. We have >>> generally allowed that for other things, and allowing it here (as >>> 100rel basically does) breaks the model that you could cache these >>> properties as associated with an instance ID, UNLESS you basically >>> changed instance IDs if you change values of Allow, Accept, etc. >> >> I didn't follow that. If I am disclosing capabilities, and do so >> differently when talking to X than Y, then I see no problem with X and >> Y caching those results as long as I am consistent in what I report to >> each of them. > > Fair point. The bigger problem is if you change what you said to a > particular caller, without changing instance ID. > >>> We should definitely try and figure out what the scope really is and >>> put that somewhere in a document, or at least into the bugzilla >>> instance. >> >> Yeah, as things stand nobody knows when they should/needn't insert >> these headers, and nobody knows how to remember them. This doesn't >> bode well for interoperability. > > In principal I suppose. I'm curious if anyone has seen interop problems > in the wild as a consequence of this... Yes, I too am curious. Maybe it doesn't matter because nobody conditions their behavior on what they receive this way. _______________________________________________ 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 From sip-bounces@ietf.org Tue Nov 08 13:59:45 2005 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 1EZYh7-0006fx-Qk; Tue, 08 Nov 2005 13:59:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZYh6-0006fr-Fm for sip@megatron.ietf.org; Tue, 08 Nov 2005 13:59:44 -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 NAA25912 for ; Tue, 8 Nov 2005 13:59:17 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZYwx-0004sE-4L for sip@ietf.org; Tue, 08 Nov 2005 14:16:08 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 08 Nov 2005 10:59:33 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,305,1125903600"; d="scan'208"; a="14745657:sNHT21661920" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jA8IxJms023826; Tue, 8 Nov 2005 13:59:31 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 8 Nov 2005 13:59:22 -0500 Received: from [209.52.152.168] ([10.86.242.85]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 8 Nov 2005 13:59:22 -0500 Message-ID: <4370F589.3000901@cisco.com> Date: Tue, 08 Nov 2005 13:59:21 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Elwell, John" Subject: Re: [Sip] comments on draft-elwell-sip-connected-identity-00 References: <50B1CBA96870A34799A506B2313F266706FC306E@ntht201e.siemenscomms.co.uk> In-Reply-To: <50B1CBA96870A34799A506B2313F266706FC306E@ntht201e.siemenscomms.co.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Nov 2005 18:59:22.0594 (UTC) FILETIME=[87E2C420:01C5E496] X-Spam-Score: 0.2 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org inline. Elwell, John wrote: >> Usage of the URI from the To and From fields in the original >> request within subsequent requests is done for backwards >> compatibility with RFC 2543, which used the URI for dialog >> identification. In this specification, only the tags >>are used for >> dialog identification. It is expected that mandatory >>reflection >> of the original To and From URI in mid-dialog requests will be >> deprecated in a subsequent revision of this specification. > > [JRE] I would very much like to go in this direction, but I feared there was > too much opposition at an earlier IETF. I recall controversy as well, but I can't think of a reason why this wouldn't work. Can anyone? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ 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 From sip-bounces@ietf.org Tue Nov 08 14:13:03 2005 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 1EZYtz-0002bY-0J; Tue, 08 Nov 2005 14:13:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZYtx-0002bM-2J for sip@megatron.ietf.org; Tue, 08 Nov 2005 14:13:01 -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 OAA26705 for ; Tue, 8 Nov 2005 14:12:34 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZZ9n-0005FP-MA for sip@ietf.org; Tue, 08 Nov 2005 14:29:25 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 08 Nov 2005 11:12:50 -0800 X-IronPort-AV: i="3.97,305,1125903600"; d="scan'208"; a="362427317:sNHT26314904" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jA8JCHZa001907; Tue, 8 Nov 2005 11:12:47 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 8 Nov 2005 14:12:34 -0500 Received: from [209.52.152.168] ([10.86.242.85]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 8 Nov 2005 14:12:34 -0500 Message-ID: <4370F8A1.8070505@cisco.com> Date: Tue, 08 Nov 2005 14:12:33 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Sip] GRUU (was Whats wrong with Supported. References: <50B1CBA96870A34799A506B2313F266706D5158B@ntht201e.siemenscomms.co.uk> <4368D156.3080106@cisco.com> <1130956108.30072.54.camel@cdhcp139.pingtel.com> <436990C6.9040002@cisco.com> <1130994755.2569.30.camel@cdhcp139.pingtel.com> <436E4E99.3060309@cisco.com> <43703065.9070806@cisco.com> In-Reply-To: <43703065.9070806@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Nov 2005 19:12:34.0411 (UTC) FILETIME=[5FD873B0:01C5E498] X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit Cc: Sip , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org inline. Paul Kyzivat wrote: > > > Jonathan Rosenberg wrote: > >>> Ok, having looked at the GRUU draft again, I'd like to consider this >>> a WGLC comment on GRUU, which I shall paraphrase as "What do you >>> mean, Supported:?" >>> >>> One could make the argument that a UA that supports GRUU would >>> never, for any reason, populate the Contact in a transaction other >>> than REGISTER (or the 200 OK thereto) with something that is not a >>> GRUU, and that one can therefore assume that the presence of >>> Supported: gruu in a message outside a REGISTER transaction means >>> that the contact is a GRUU. But if one were to make that argument, >>> one would need to spell this out clearly. >> >> >> That is the intent. >> >> The idea is this - the GRUU spec basically says, at MUST strength, >> that you have to use your GRUU in the contact of dialog forming >> requests and responses. Supported:gruu implies ONLY that the UA >> sending the request supports the gruu spec. As a consequence, since >> the gruu spec implies that a compliant implementation also place a >> GRUU into the contact, the presence of Supported:gruu ALSO implies >> that the request contains a GRUU in the contact. > > > And in the Refer-To of REFER? And in *all* the Contacts of a 3xx? And in > ???. I don't follow you here. Refer-To is different; this doesn't usually contain MY URI, its someone elses that is pulled from somewhere (Contact). Whether you'd place your own gruu into a redirect, I don't know of a user case for that. > > What happens when there are multiple addresses in the message and only > some of them are known to have the GRUU property? We're only talking about contact. > > For instance, suppose I'm sending a REFER, and I know the Refer-To is a > gruu, but I wasn't able to get a gruu for the Contact in my own REFER? > Do I put a Supported: gruu in the REFER request? Supported: gruu means that the endpoints supports GRUU, and that as a consequence, the Contact in dialog forming requests (like REFER) will contain a gruu for the UAC. Supported:gruu says NOTHIGN about the contents of Refer-To since the GRUU spec isn't about that. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ 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 From sip-bounces@ietf.org Tue Nov 08 14:15:21 2005 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 1EZYwD-00031C-4G; Tue, 08 Nov 2005 14:15:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZYwB-0002yx-Jx for sip@megatron.ietf.org; Tue, 08 Nov 2005 14:15:19 -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 OAA26830 for ; Tue, 8 Nov 2005 14:14:52 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZZC1-0005IZ-Qd for sip@ietf.org; Tue, 08 Nov 2005 14:31:43 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 08 Nov 2005 11:15:08 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jA8JE0Za003001; Tue, 8 Nov 2005 11:15:06 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 8 Nov 2005 14:15:03 -0500 Received: from [209.52.152.168] ([10.86.242.85]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 8 Nov 2005 14:15:02 -0500 Message-ID: <4370F935.10107@cisco.com> Date: Tue, 08 Nov 2005 14:15:01 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeroen van Bemmel Subject: Re: [Sip] GRUU (was Whats wrong with Supported. References: <436E75DD.8060107@cisco.com> <003e01c5e31f$2036c9c0$6402a8c0@BEMBUSTER> <436F6B7C.4000400@cisco.com> <006401c5e3d4$b6427df0$6402a8c0@BEMBUSTER> <436FC946.6000902@cisco.com> <007f01c5e3ed$034ed720$6402a8c0@BEMBUSTER> In-Reply-To: <007f01c5e3ed$034ed720$6402a8c0@BEMBUSTER> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Nov 2005 19:15:02.0812 (UTC) FILETIME=[B84CA5C0:01C5E498] X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, dean.willis@softarmor.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org inline Jeroen van Bemmel wrote: >> If this happens, then there is a difference between the presence of >> the Supported header field and whether or not the contact is a gruu. >> >> I would still argue against a specific URI parameter for this, >> however. We want to be moving AWAY from telling people to try various >> tricks to get a URI to work. It ought to just work - thats what gruu >> allows. As such, in the case above, I'd still argue that the right >> thing is to try the contact URI, as it may work anyway... >> > > OK, so in that case: what if we just let Supported: gruu mean what it > says - that the UAC supports GRUUs, in the sense that it knows how to > request them from a registrar and to use them as Contact when available. > Supported would not be a guarantee that the Contact is a GRUU (but does > make it more likely), its absence means that the Contact was not > obtained from a registrar or provisioned administratively as a GRUU (but > may still work). Yes. > > A UAC MUST use a GRUU as Contact, that is when it is provided with one. > It MUST insert Supported: gruu in all dialog-creating requests and > responses (btw, in addition to 2xx responses to INVITE I think it should > also be included in 1xx responses with a to-tag, in particular 100rel > responses) Yes. > > Implementations SHOULD assume that Contacts are GRUUs (and act > accordingly), regardless of the presence or absence of a Supported: gruu > header. Well, here I would rather have the draft say that presence of Supported: gruu is a strong hint that the contact is a gruu, and that endpoints using such cotnacs for new requests will have a high likelihood of those working, and then leave it at that. In particular, the Refer-To example SHOULD use the Contact URI > (this leaves some room for implementations to deviate, if they really > see a need) I am thinking now that usage of the Contact for other things, like REFER, should not be the problem of the gruu spec.. > > PS I like the suggestion of loose contact routing, as a side effect it > would obviate the need for special handling of the 'grid' parameter Yes, I realized that as well. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ 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 From sip-bounces@ietf.org Tue Nov 08 14:22:53 2005 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 1EZZ3V-0005v1-0p; Tue, 08 Nov 2005 14:22:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZZ3U-0005uw-2W for sip@megatron.ietf.org; Tue, 08 Nov 2005 14:22:52 -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 OAA27408 for ; Tue, 8 Nov 2005 14:22:25 -0500 (EST) Received: from hostr51.alcatel.com ([143.209.5.1] helo=aurfsy.aur.alcatel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZZJK-0005a1-PR for sip@ietf.org; Tue, 08 Nov 2005 14:39:16 -0500 Received: from usrald00141 (localhost [127.0.0.1]) by aurfsy.aur.alcatel.com (8.11.6+Sun/8.11.3) with ESMTP id jA8JMfN16387 for ; Tue, 8 Nov 2005 14:22:41 -0500 (EST) Message-Id: <200511081922.jA8JMfN16387@aurfsy.aur.alcatel.com> From: "Jim Li" To: Date: Tue, 8 Nov 2005 14:22:40 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: AcXkmbuCDf8tc1plTD63ceJqceWhOw== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Subject: [Sip] SIP Header: Content-Disposition Syntax X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi there, Could anyone help me to verify the Content-Disposition header syntax is correct: Content-Disposition: session; handling=required Thanks in advance. Jim _______________________________________________ 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 From sip-bounces@ietf.org Tue Nov 08 15:19:18 2005 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 1EZZw6-0007rs-LQ; Tue, 08 Nov 2005 15:19:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZZw5-0007rk-6i for sip@megatron.ietf.org; Tue, 08 Nov 2005 15:19:17 -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 PAA01007 for ; Tue, 8 Nov 2005 15:18:43 -0500 (EST) Received: from empbedex1.empirix.com ([12.38.203.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZaBo-00079x-65 for sip@ietf.org; Tue, 08 Nov 2005 15:35:35 -0500 Received: from EMPBEDEX.empirix.com ([10.16.0.91]) by empbedex1.empirix.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 8 Nov 2005 15:17:59 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] SIP Header: Content-Disposition Syntax Date: Tue, 8 Nov 2005 15:14:00 -0500 Message-ID: Thread-Topic: [Sip] SIP Header: Content-Disposition Syntax Thread-Index: AcXkmbuCDf8tc1plTD63ceJqceWhOwABzk84 From: "Bhattacharyya, Dipankar" To: "Jim Li" , X-OriginalArrivalTime: 08 Nov 2005 20:17:59.0372 (UTC) FILETIME=[834DF8C0:01C5E4A1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi Jim, It appears that you Content -Disposition header example is fine: Section 25.1 of RFC 3261 defines the Header as below : =20 Content-Disposition =3D "Content-Disposition" HCOLON disp-type *( SEMI disp-param ) disp-type =3D "render" / "session" / "icon" / "alert" / disp-extension-token disp-param =3D handling-param / generic-param handling-param =3D "handling" EQUAL ( "optional" / "required" / other-handling ) other-handling =3D token disp-extension-token =3D token Thanks, Regards, -Dipankar.=20 =20 ________________________________ From: sip-bounces@ietf.org on behalf of Jim Li Sent: Tue 11/8/2005 2:22 PM To: sip@ietf.org Subject: [Sip] SIP Header: Content-Disposition Syntax Hi there, Could anyone help me to verify the Content-Disposition header syntax is correct: Content-Disposition: session; handling=3Drequired Thanks in advance. Jim _______________________________________________ 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 From sip-bounces@ietf.org Tue Nov 08 18:04:49 2005 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 1EZcWH-0001M2-Iy; Tue, 08 Nov 2005 18:04:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZcWG-0001KV-3X for sip@megatron.ietf.org; Tue, 08 Nov 2005 18:04:48 -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 SAA12241 for ; Tue, 8 Nov 2005 18:04:21 -0500 (EST) Received: from mail.pingtel.com ([65.220.123.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZcm7-0003y8-QW for sip@ietf.org; Tue, 08 Nov 2005 18:21:14 -0500 Received: from maine.pingtel.com (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id B17656C01C for ; Tue, 8 Nov 2005 18:04:35 -0500 (EST) From: "Dale R. Worley" To: Sip Content-Type: multipart/mixed; boundary="=-tQ42J7Vco1jOtSovuZEJ" Date: Tue, 08 Nov 2005 17:26:23 -0500 Message-Id: <1131488783.4389.38.camel@maine.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-7) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Subject: [Sip] GRUU: problem with description of solution to edge-router problem X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --=-tQ42J7Vco1jOtSovuZEJ Content-Type: text/plain Content-Transfer-Encoding: 7bit I've been trying to fully understand the solution to the "edge router" problem that is described in section 8.4.2 of draft-ietf-sip-gruu-06. One component of the solution is described at the top of page 25: Similarly, if a request arrives from the client towards the home proxy, the edge proxy would look at the identity of the sender of the request. If the proxy knows that it is placing itself on the Path for registrations from that AOR, and the request contains a Supported header field with the value "gruu", the edge proxy would insert a Record-Route into the request, and then remove it in the response. I believe that this description is incorrect, in fact reversed from the behavior that is desired. I've charted the message flows for dialog- establishing messages in the edge-router situation, and the route-sets that we want established at the ends of the dialog. From the route- sets, one can determine the manipulations that the edge router must perform on the request and response. The message flows are in an attachment to this message. >From the message flow, it seems to me that the above quoted paragraph is incorrect, and should be written as Similarly, if a request arrives from the client towards the home proxy, the edge proxy would look at the identity of the sender of the request. If the proxy knows that it is placing itself on the Path for registrations from that AOR, and the request contains a Supported header field with the value "gruu", the edge proxy would not insert a Record-Route into the request, but would rather insert it into the response. I fear that I may be overlooking something here and making a fool of myself, but I've checked this over, and I think that this is a bug in the text of the I-D. Dale --=-tQ42J7Vco1jOtSovuZEJ Content-Disposition: attachment; filename=R Content-Type: text/plain; name=R; charset=UTF-8 Content-Transfer-Encoding: 7bit Rosenberg's mechanism from draft-ietf-sip-gruu-06 ** Network structure: HP EP UA Home Proxy Edge Proxy User Agent H1 --> E1 --> U1 --> <-- H1 <-- E1 GRUU (real location) GRUU (referent) * Initial outgoing request <-- Contact: GRUU <-- Contact: GRUU (E1 does not insert "Record-Route: E1") <-- Contact: GRUU Record-Route: H1 Response to the request Record-Route: H1 --> Record-Route: H1 --> Record-Route: E1 --> Record-Route: H1 (E1 inserts "Record-Route: E1") [received] * Initial incoming request Request-URI: GRUU --> Request-URI: U1 --> Route: E1 Record-Route: H1 Request-URI: U1 --> Record-Route: H1 Record-Route: E1 [received] Response to the request <-- Contact: GRUU Record-Route: H1 Record-Route: E1 <-- Contact: GRUU Record-Route: H1 (ER has removed "Record-Route: E1") <-- Contact: GRUU Record-Route: H1 * Route-sets: ..., H1, [GRUU] E1, H1, ... * Mid-dialog incoming request Request-URI: GRUU --> Route: H1 Request-URI: U1 --> Route: E1 Request-URI: U1 --> [received] * Mid-dialog outgoing request <-- Request-URI: X Route: E1 Route: H1 <-- Request-URI: X Route: H1 <-- Request-URI: X --=-tQ42J7Vco1jOtSovuZEJ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --=-tQ42J7Vco1jOtSovuZEJ-- From sip-bounces@ietf.org Wed Nov 09 12:28:49 2005 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 1EZtkf-0002n3-77; Wed, 09 Nov 2005 12:28:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZtkc-0002my-U7 for sip@megatron.ietf.org; Wed, 09 Nov 2005 12:28:47 -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 MAA24023 for ; Wed, 9 Nov 2005 12:28:20 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZu0f-000337-F7 for sip@ietf.org; Wed, 09 Nov 2005 12:45:22 -0500 Received: from razor.cs.columbia.edu (razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id jA9HSgho024353 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 9 Nov 2005 12:28:43 -0500 (EST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.11/8.12.11) with ESMTP id jA9HSfr0021308 for ; Wed, 9 Nov 2005 12:28:41 -0500 Message-ID: <437231CC.3070405@cs.columbia.edu> Date: Wed, 09 Nov 2005 12:28:44 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Subject: [Sip] Changing To in service-marked calls X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Picking up on a slightly-related discussion at the SIP meeting. An emerging consensus for marking emergency calls is to use the urn:service URN (see related draft). However, for backward-compatibility, we need to deal with phones that will issue requests such as INVITE sip:911@example.com;user=phone To: sip:911@example.com;user=phone which the outbound proxy should then translate to INVITE urn:service:sos To: urn:service:sos or INVITE sip:psap@some-psap.gov To: urn:service:sos if that outbound proxy also does a PSAP look up. Any comments on this approach? (I find it somewhat distasteful.) In general, the goals are to be able to - distinguish emergency calls - and detect if a location-to-URL translation has already taken place (we don't want to do this several times) As a side note, this is also applicable to other services beyond emergency calling. One alternative is to use a pre-loaded Route to urn:service:sos added by the outbound proxy. Advice appreciated. Henning _______________________________________________ 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 From sip-bounces@ietf.org Wed Nov 09 13:14:06 2005 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 1EZuSU-0003DM-GK; Wed, 09 Nov 2005 13:14:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZuSS-00034I-2H for sip@megatron.ietf.org; Wed, 09 Nov 2005 13:14:04 -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 NAA27023 for ; Wed, 9 Nov 2005 13:13:37 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZuiT-0004Rw-SK for sip@ietf.org; Wed, 09 Nov 2005 13:30:40 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 09 Nov 2005 10:13:52 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jA9IDRc5005654; Wed, 9 Nov 2005 10:13:50 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 9 Nov 2005 10:13:50 -0800 Received: from [10.89.16.53] ([10.89.16.53]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 9 Nov 2005 10:13:49 -0800 Message-ID: <43723C5C.3030103@cisco.com> Date: Wed, 09 Nov 2005 13:13:48 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Sip] Changing To in service-marked calls References: <437231CC.3070405@cs.columbia.edu> In-Reply-To: <437231CC.3070405@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Nov 2005 18:13:49.0518 (UTC) FILETIME=[554236E0:01C5E559] X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Henning Schulzrinne wrote: > Picking up on a slightly-related discussion at the SIP meeting. An > emerging consensus for marking emergency calls is to use the urn:service > URN (see related draft). However, for backward-compatibility, we need to > deal with phones that will issue requests such as > > INVITE sip:911@example.com;user=phone > To: sip:911@example.com;user=phone > > which the outbound proxy should then translate to > > INVITE urn:service:sos > To: urn:service:sos > > or > > INVITE sip:psap@some-psap.gov > To: urn:service:sos I know we started to open the door to changing To and From, but did we really agree to allow *proxies* to change them??? > if that outbound proxy also does a PSAP look up. Any comments on this > approach? (I find it somewhat distasteful.) Why is it important to have the value in To? > In general, the goals are to be able to > - distinguish emergency calls > - and detect if a location-to-URL translation has already taken place > (we don't want to do this several times) > > As a side note, this is also applicable to other services beyond > emergency calling. > > One alternative is to use a pre-loaded Route to urn:service:sos added by > the outbound proxy. On that theme, how about: INVITE sip:911@example.com;user=phone To: sip:911@example.com;user=phone which the outbound proxy should then translate to INVITE urn:service:sos To: sip:911@example.com;user=phone and then eventually to: INVITE urn:service:sos To: sip:911@example.com;user=phone Route: sip:psap@some-psap.gov;lr This way, once the 911 is recognized as a local representation of an emergency call it is replaced with a global representation of an emergency call and remains unchanged from then on. The Route headers then get it there. Paul _______________________________________________ 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 From sip-bounces@ietf.org Wed Nov 09 13:19:00 2005 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 1EZuXE-0004qN-Dn; Wed, 09 Nov 2005 13:19:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZuXC-0004pm-JA for sip@megatron.ietf.org; Wed, 09 Nov 2005 13:18:58 -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 NAA27337 for ; Wed, 9 Nov 2005 13:18:31 -0500 (EST) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZunF-0004cZ-7q for sip@ietf.org; Wed, 09 Nov 2005 13:35:34 -0500 Received: from [209.52.106.112] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id jA9IO2MZ002198 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 9 Nov 2005 12:24:05 -0600 In-Reply-To: <437231CC.3070405@cs.columbia.edu> References: <437231CC.3070405@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Changing To in service-marked calls Date: Wed, 9 Nov 2005 12:18:40 -0600 To: Henning Schulzrinne X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Nov 9, 2005, at 11:28 AM, Henning Schulzrinne wrote: > Picking up on a slightly-related discussion at the SIP meeting. An > emerging consensus for marking emergency calls is to use the > urn:service URN (see related draft). However, for backward- > compatibility, we need to deal with phones that will issue requests > such as > > INVITE sip:911@example.com;user=phone > To: sip:911@example.com;user=phone > > which the outbound proxy should then translate to > > INVITE urn:service:sos > To: urn:service:sos > > or > > INVITE sip:psap@some-psap.gov > To: urn:service:sos Is this the same question as "Should the To: change on a retargeting operation"? Or is it "Is 911 service determination a retargeting operation or is it a routing operation"? -- Dean _______________________________________________ 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 From sip-bounces@ietf.org Wed Nov 09 14:03:47 2005 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 1EZvEY-0003Ph-Vk; Wed, 09 Nov 2005 14:03:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZvEX-0003PY-Gq for sip@megatron.ietf.org; Wed, 09 Nov 2005 14:03:45 -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 OAA00819 for ; Wed, 9 Nov 2005 14:03:17 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZvUa-00069a-Cj for sip@ietf.org; Wed, 09 Nov 2005 14:20:21 -0500 Received: from razor.cs.columbia.edu (razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id jA9J3dho018164 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 9 Nov 2005 14:03:40 -0500 (EST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.11/8.12.11) with ESMTP id jA9J3cY3021538; Wed, 9 Nov 2005 14:03:39 -0500 Message-ID: <4372480D.1080701@cs.columbia.edu> Date: Wed, 09 Nov 2005 14:03:41 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Sip] Changing To in service-marked calls References: <437231CC.3070405@cs.columbia.edu> <43723C5C.3030103@cisco.com> In-Reply-To: <43723C5C.3030103@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > I know we started to open the door to changing To and From, but did we > really agree to allow *proxies* to change them??? That's where my discomfort arises. I checked RFC 3261 and To is proxy 'r', i.e., this is not an option. > >> if that outbound proxy also does a PSAP look up. Any comments on this >> approach? (I find it somewhat distasteful.) > > > Why is it important to have the value in To? Parties in the call path should be able to tell that this was an emergency call. It does appear to be a (logical) destination identifier. The original motivation was to make sure that calls marked as emergency might bypass authorization, but you want to make sure that you can't do INVITE urn:service:sos Route: sip:alice@yahoo.com;lr where Alice is a friend not providing (officially recognized) emergency services. I don't think this is possible, so the only entities that can make such authorization bypass decisions would be the one inserting the Route (which is probably what you would do in any event). > On that theme, how about: > > INVITE sip:911@example.com;user=phone > To: sip:911@example.com;user=phone > > which the outbound proxy should then translate to > > INVITE urn:service:sos > To: sip:911@example.com;user=phone > > and then eventually to: > > INVITE urn:service:sos > To: sip:911@example.com;user=phone > Route: sip:psap@some-psap.gov;lr > > This way, once the 911 is recognized as a local representation of an > emergency call it is replaced with a global representation of an > emergency call and remains unchanged from then on. The Route headers > then get it there. Works for me. Is there any estimate how existing proxies would deal with a service URN + Route combination? > > Paul _______________________________________________ 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 From sip-bounces@ietf.org Wed Nov 09 14:31:23 2005 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 1EZvfH-0008ES-1X; Wed, 09 Nov 2005 14:31:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZvfG-0008EI-50 for sip@megatron.ietf.org; Wed, 09 Nov 2005 14:31:22 -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 OAA03012 for ; Wed, 9 Nov 2005 14:30:54 -0500 (EST) Received: from mail.pingtel.com ([65.220.123.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZvvJ-00078A-AX for sip@ietf.org; Wed, 09 Nov 2005 14:47:58 -0500 Received: from maine.pingtel.com (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id 938DF6C01C for ; Wed, 9 Nov 2005 14:31:14 -0500 (EST) Subject: Re: [Sip] GRUU (was Whats wrong with Supported. From: "Dale R. Worley" To: Sip In-Reply-To: <4370F935.10107@cisco.com> References: <436E75DD.8060107@cisco.com> <003e01c5e31f$2036c9c0$6402a8c0@BEMBUSTER> <436F6B7C.4000400@cisco.com> <006401c5e3d4$b6427df0$6402a8c0@BEMBUSTER> <436FC946.6000902@cisco.com> <007f01c5e3ed$034ed720$6402a8c0@BEMBUSTER> <4370F935.10107@cisco.com> Content-Type: text/plain Date: Wed, 09 Nov 2005 14:31:14 -0500 Message-Id: <1131564674.4353.38.camel@maine.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-7) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Tue, 2005-11-08 at 14:15 -0500, Jonathan Rosenberg wrote: > > Implementations SHOULD assume that Contacts are GRUUs (and act > > accordingly), regardless of the presence or absence of a Supported: gruu > > header. > > Well, here I would rather have the draft say that presence of Supported: > gruu is a strong hint that the contact is a gruu, and that endpoints > using such cotnacs for new requests will have a high likelihood of those > working, and then leave it at that. Perhaps you could say something like this: "The presence of Supported: gruu suggests a high likelihood that the Contact is a GRUU, and so a UA using that Contact SHOULD proceed on the assumption that it is a GRUU, until it has positive information that it is not. In particular, the UA should not utilize any mechanisms to work around that the Contact is not a GRUU until it has determined that utilizing it as a GRUU does not work." That language: 1) makes all current networks conforming, regardless of "proprietary hacks", because no element sends Supported: gruu yet. 2) when "Supported: gruu" is present, bans proprietary hacks except as a fall-back mechanism. which seems to me to be a good combination. Dale _______________________________________________ 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 From sip-bounces@ietf.org Wed Nov 09 14:51:44 2005 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 1EZvyy-0007C6-Mx; Wed, 09 Nov 2005 14:51:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZvyx-0007C1-Mb for sip@megatron.ietf.org; Wed, 09 Nov 2005 14:51:43 -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 OAA04013 for ; Wed, 9 Nov 2005 14:51:15 -0500 (EST) Received: from mail.pingtel.com ([65.220.123.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZwF2-0007eP-57 for sip@ietf.org; Wed, 09 Nov 2005 15:08:20 -0500 Received: from maine.pingtel.com (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id BE9436C01C for ; Wed, 9 Nov 2005 14:51:37 -0500 (EST) From: "Dale R. Worley" To: Sip Content-Type: text/plain Date: Wed, 09 Nov 2005 14:51:37 -0500 Message-Id: <1131565897.4353.48.camel@maine.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-7) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Subject: [Sip] The significance of "Supported: gruu" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I was thinking that the discussion of what "Supported: gruu" means about the Contact in a message is not as significant as it seems. In most cases, if a UA wants to contact its counterpart UA, it does so by sending an in-dialog request (which *must* work), rather than sending an out-of-dialog request to the Contact URI. In my experience, the way that a Contact URI is used is by being revealed in a dialog event package, and the subscriber to the dialog event package uses that URI to execute a call-control operation. But by the time that the subscriber sees the Contact URI, any information that was present in the original message is entirely lost, except for what is in the URI itself. Dale _______________________________________________ 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 From sip-bounces@ietf.org Wed Nov 09 17:59:11 2005 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 1EZyuN-0001o4-CL; Wed, 09 Nov 2005 17:59:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZyuM-0001nr-5g for sip@megatron.ietf.org; Wed, 09 Nov 2005 17:59:10 -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 RAA15976 for ; Wed, 9 Nov 2005 17:58:41 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZzAS-00053M-El for sip@ietf.org; Wed, 09 Nov 2005 18:15:48 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 09 Nov 2005 14:59:01 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,310,1125903600"; d="scan'208"; a="14832535:sNHT23146348" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jA9MwYxM017959 for ; Wed, 9 Nov 2005 17:58:59 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 9 Nov 2005 17:58:40 -0500 Received: from [209.52.109.209] ([10.86.240.214]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 9 Nov 2005 17:58:39 -0500 Message-ID: <43727F1E.8090001@cisco.com> Date: Wed, 09 Nov 2005 17:58:38 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Nov 2005 22:58:39.0798 (UTC) FILETIME=[1FDBFD60:01C5E581] X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: 7bit Subject: [Sip] GRUU, EP record-route stripping and retargeting X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org While working on slides on GRUU for tomorrows meeting, I ran into a pretty major issue with the mechanism in the GRUU spec where the proxy removes its record-route from requests or responses. The issue is of a more practical nature, but significant. If implementors follow the guidance of the specification, any mid-dialog requests arriving at the home proxy get routed based on the GRUU in the request URI. This will cause the request to be delivered to an EP based on their registered contact and any Path values that may have been there. All of these are URI, and were created as a consequence of registration, and are not specific to the dialog. There are two primary consequences: 1. there is no way to guarantee that the mid-dialog request goes to the same proxy that saw the initial request 2. there is no way a proxy can place some information into a record-route and get it back out in a mid-dialog request Any implementations which store any kind of call state, either internal to the server or in the record-routes, will simply no longer work. The mid-dialog request might go to the wrong place, and even if it goes to the right place, any state or state references in the record-route might have been lost. We've had other concerns raised against this part of the GRUU spec, and its definitely the weakest part of the document. I think this issue pushes it over the edge, and we need to do something different. I would like to revisit a proposal we discussed during the Paris IETF, which was dismissed at the time. However, recent discussions on retargeting vs. routing have clarified things in my mind sufficiently that I think its the right way to go. The proposal that was made (by Dale I think), was to have the endpoint insert the GRUU in the Contact of the 200 OK, but also have the UAS insert a Record-Route for itself. As a consequence of this, the mid-dialog requests would show up at the EP, but wouldn't get routed back around to the home proxy because there is another route - pointing to the UA itself. Thus, the request shows up at the UA in this form: INVITE sip:gruu Route: sip:endpoint-ip this requires an endpoint to get a request with a Route header field and process it. Whats interesting is that this is exactly the same structure we've been talking about in the discussion on retargeting vs. routing. There, the idea was that for requests outside of a dialog, the request would show up at the home proxy, and the registered contact would then be placed into the topmost Route header, and the R-URI would be preserved. When it arrives at the UAS, the request would look like: INVITE sip:aor Route: sip:endpoint-ip this actually makes a lot of sense; both initial and mid-dialog requests are routed via Route header fields eventually arriving at the UAS with a Route header that looks identically in each case. Initial requests show up with an AOR in the r-uri, and mid-dialog requests, being targeted to the instance to which the call is currently active, show up with the GRUU. There were two reasons discussed at the last IETF IIRC, on why we didn't choose this approach. They were: 1. major change in sip architecture 2. mid-dialog requests get "pegged" to a specific UA IP address and port for the duration of the dialog, since they now appear in a record-route, which cannot be updated mid-dialog I think the first issue is true, but recent discussions have clarified (for me at least) how this would work and I am increasingly comfortable with this change. The second issue is also still true. The question is whether that is really important right now. The main applications for it have been sip-level session mobility and continuation of dialogs during failures of proxies when used with sip-outbound. The latter is something I'd really like to have, but I'd prefer to defer specification of an approach for this to a later time. As for the former usage (SIP-level session mobility), others need to comment on how important that is (most mobility work is done below the SIP layer). Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ 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 From sip-bounces@ietf.org Wed Nov 09 19:52:51 2005 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 1Ea0gN-0004XQ-Ft; Wed, 09 Nov 2005 19:52:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ea0gL-0004Vz-Me for sip@megatron.ietf.org; Wed, 09 Nov 2005 19:52:49 -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 TAA22734 for ; Wed, 9 Nov 2005 19:52:22 -0500 (EST) Received: from mail.pingtel.com ([65.220.123.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ea0wR-00085x-Lo for sip@ietf.org; Wed, 09 Nov 2005 20:09:28 -0500 Received: from maine.pingtel.com (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id A5C916C01C for ; Wed, 9 Nov 2005 19:52:40 -0500 (EST) From: "Dale R. Worley" To: Sip Content-Type: text/plain Date: Wed, 09 Nov 2005 16:48:43 -0500 Message-Id: <1131572923.4359.16.camel@maine.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-7) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.7 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Subject: [Sip] Editorial suggestion for draft-ietf-sip-gruu-06 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org In regard to the special edge router behavior described in section 8.4.2, while I was working out some sample call flows, it struck me that the descriptions of the special edge router behaviors at the end of 8.4.2 would benefit with being spelled out more exactly. I was thinking of something like "When the edge router receives a response containing a Record-Route that it inserted ... and the Request-URI (or first Route) is ..., then it should remove that Record-Route from the response." This is a practical problem. When I was checking to see how this algorithm interacted with another approach to solve the edge router problem, I noticed that I could not rigorously determine how 8.4.2 would behave without (essentially) assuming that it would do the right thing in unusual cases. I would be willing to help rewriting these paragraphs. Dale _______________________________________________ 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 From sip-bounces@ietf.org Wed Nov 09 22:09:26 2005 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 1Ea2oY-0003OV-PA; Wed, 09 Nov 2005 22:09:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ea2oV-0003Nm-V0 for sip@megatron.ietf.org; Wed, 09 Nov 2005 22:09:24 -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 WAA00344 for ; Wed, 9 Nov 2005 22:08:55 -0500 (EST) Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ea34b-00035q-V8 for sip@ietf.org; Wed, 09 Nov 2005 22:26:04 -0500 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0IPP00J01XYOQ1@siemenscomms.co.uk> for sip@ietf.org; Thu, 10 Nov 2005 03:06:24 +0000 (GMT) Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0IPP00B99XYNO4@siemenscomms.co.uk> for sip@ietf.org; Thu, 10 Nov 2005 03:06:23 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Thu, 10 Nov 2005 03:08:55 +0000 Content-return: allowed Date: Thu, 10 Nov 2005 03:08:35 +0000 From: "Elwell, John" To: IETF SIP List Message-id: <50B1CBA96870A34799A506B2313F266707240134@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Subject: [Sip] Changing the To header X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1500562903==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1500562903== Content-return: allowed Content-type: multipart/alternative; boundary="Boundary_(ID_7GSlwRL+XPjLTeIEgLLxBA)" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --Boundary_(ID_7GSlwRL+XPjLTeIEgLLxBA) Content-type: text/plain Content-Transfer-Encoding: 7BIT In yesterday's SIP session it was agreed to investigate the possibility of changing the To header field URI in a response to a dialog-forming request. To kick off this discussion, here are my thoughts. A modified To header field URI in a response to a dialog-forming request can indicate that the request has been retargeted. This would not be authenticated, so if an authenticated called party identity is required it would be necessary to ignore the modified To header field URI and wait for an authenticated identity in a subsequent request from the called party. One use case is in a closed environment, particularly where sips is used, where transitive trust is used to give credibility to the unauthenticated identity. A second use case is to give a preliminary indication based on an identity in a provisional response, to be replaced by an indication based on an authenticated identity in the subsequent 2xx response. Fire away. John --Boundary_(ID_7GSlwRL+XPjLTeIEgLLxBA) Content-type: text/html Content-Transfer-Encoding: 7BIT Changing the To header

In yesterday's SIP session it was agreed to investigate the possibility of changing the To header field URI in a response to a dialog-forming request. To kick off this discussion, here are my thoughts.

A modified To header field URI in a response to a dialog-forming request can indicate that the request has been retargeted. This would not be authenticated, so if an authenticated called party identity is required it would be necessary to ignore the modified To header field URI and wait for an authenticated identity in a subsequent request from the called party.

One use case is in a closed environment, particularly where sips is used, where transitive trust is used to give credibility to the unauthenticated identity.

A second use case is to give a preliminary indication based on an identity in a provisional response, to be replaced by an indication based on an authenticated identity in the subsequent 2xx response.

Fire away.

John

--Boundary_(ID_7GSlwRL+XPjLTeIEgLLxBA)-- --===============1500562903== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1500562903==-- From sip-bounces@ietf.org Wed Nov 09 22:09:28 2005 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 1Ea2oa-0003Ow-F3; Wed, 09 Nov 2005 22:09:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ea2oW-0003Nw-5q for sip@megatron.ietf.org; Wed, 09 Nov 2005 22:09:24 -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 WAA00343 for ; Wed, 9 Nov 2005 22:08:55 -0500 (EST) Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ea34b-00035r-Uz for sip@ietf.org; Wed, 09 Nov 2005 22:26:04 -0500 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0IPP00J01XYOQ2@siemenscomms.co.uk> for sip@ietf.org; Thu, 10 Nov 2005 03:06:24 +0000 (GMT) Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0IPP00B9BXYNO4@siemenscomms.co.uk> for sip@ietf.org; Thu, 10 Nov 2005 03:06:23 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Thu, 10 Nov 2005 03:08:55 +0000 Content-return: allowed Date: Thu, 10 Nov 2005 03:08:35 +0000 From: "Elwell, John" To: IETF SIP List Message-id: <50B1CBA96870A34799A506B2313F266707240133@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Subject: [Sip] Changing the From header X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0228575557==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0228575557== Content-return: allowed Content-type: multipart/alternative; boundary="Boundary_(ID_L5MmXw3lDN+VfMK/XgU8xA)" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --Boundary_(ID_L5MmXw3lDN+VfMK/XgU8xA) Content-type: text/plain Content-Transfer-Encoding: 7BIT At yesterday's SIP session we had rough consensus on changing the From header field URI in mid-dialog requests. We also said that no special provision would be made to accommodate proxies that cannot cope with this. Nothing was said about UASs that cannot cope with this. Do we need an option tag to indicate support for a changed From header field URI during a dialog? With such an option tag, a UA that does not receive a Supported header field with this option tag during the dialog-forming transaction would refrain from changing the From header field URI in mid-dialog requests. John --Boundary_(ID_L5MmXw3lDN+VfMK/XgU8xA) Content-type: text/html Content-Transfer-Encoding: 7BIT Changing the From header

At yesterday's SIP session we had rough consensus on changing the From header field URI in mid-dialog requests. We also said that no special provision would be made to accommodate proxies that cannot cope with this. Nothing was said about UASs that cannot cope with this. Do we need an option tag to indicate support for a changed From header field URI during a dialog? With such an option tag, a UA that does not receive a Supported header field with this option tag during the dialog-forming transaction would refrain from changing the From header field URI in mid-dialog requests.

John

--Boundary_(ID_L5MmXw3lDN+VfMK/XgU8xA)-- --===============0228575557== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============0228575557==-- From sip-bounces@ietf.org Thu Nov 10 09:29:06 2005 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 1EaDQI-0001Qn-6U; Thu, 10 Nov 2005 09:29:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaDQG-0001QE-JO for sip@megatron.ietf.org; Thu, 10 Nov 2005 09:29:05 -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 JAA06197 for ; Thu, 10 Nov 2005 09:28:36 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaDgS-0003Si-Ki for sip@ietf.org; Thu, 10 Nov 2005 09:45:51 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 10 Nov 2005 09:28:29 -0500 X-IronPort-AV: i="3.97,313,1125892800"; d="scan'208"; a="75405459:sNHT46501115668" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jAAES4ms014146; Thu, 10 Nov 2005 09:28:26 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 10 Nov 2005 09:28:14 -0500 Received: from [209.52.109.209] ([10.86.242.44]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 10 Nov 2005 09:28:13 -0500 Message-ID: <437358FD.1030808@cisco.com> Date: Thu, 10 Nov 2005 09:28:13 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Dale R. Worley" Subject: Re: [Sip] GRUU (was Whats wrong with Supported. References: <436E75DD.8060107@cisco.com> <003e01c5e31f$2036c9c0$6402a8c0@BEMBUSTER> <436F6B7C.4000400@cisco.com> <006401c5e3d4$b6427df0$6402a8c0@BEMBUSTER> <436FC946.6000902@cisco.com> <007f01c5e3ed$034ed720$6402a8c0@BEMBUSTER> <4370F935.10107@cisco.com> <1131564674.4353.38.camel@maine.pingtel.com> In-Reply-To: <1131564674.4353.38.camel@maine.pingtel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Nov 2005 14:28:13.0704 (UTC) FILETIME=[FBB2A880:01C5E602] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit Cc: Sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org The text below seems fine to me. Hopefully we are concluded on this topic... -Jonathan R. Dale R. Worley wrote: > On Tue, 2005-11-08 at 14:15 -0500, Jonathan Rosenberg wrote: > >>>Implementations SHOULD assume that Contacts are GRUUs (and act >>>accordingly), regardless of the presence or absence of a Supported: gruu >>>header. >> >>Well, here I would rather have the draft say that presence of Supported: >>gruu is a strong hint that the contact is a gruu, and that endpoints >>using such cotnacs for new requests will have a high likelihood of those >>working, and then leave it at that. > > > Perhaps you could say something like this: > > "The presence of Supported: gruu suggests a high likelihood that the > Contact is a GRUU, and so a UA using that Contact SHOULD proceed on the > assumption that it is a GRUU, until it has positive information that it > is not. In particular, the UA should not utilize any mechanisms to work > around that the Contact is not a GRUU until it has determined that > utilizing it as a GRUU does not work." > > That language: > > 1) makes all current networks conforming, regardless of "proprietary > hacks", because no element sends Supported: gruu yet. > > 2) when "Supported: gruu" is present, bans proprietary hacks except as a > fall-back mechanism. > > which seems to me to be a good combination. > > Dale > > > > _______________________________________________ > 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 > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ 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 From sip-bounces@ietf.org Thu Nov 10 11:40:20 2005 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 1EaFTI-0006m1-2F; Thu, 10 Nov 2005 11:40:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaFTG-0006il-Cz for sip@megatron.ietf.org; Thu, 10 Nov 2005 11:40:18 -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 LAA15309 for ; Thu, 10 Nov 2005 11:39:49 -0500 (EST) Received: from mail1.hotsip.com ([62.119.82.23] helo=mail2.hotsip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaFjU-0007ZE-Ni for sip@ietf.org; Thu, 10 Nov 2005 11:57:06 -0500 Received: from 62.119.82.41 [62.119.82.41] by mail2.hotsip.com with XWall v3.33 ; Thu, 10 Nov 2005 17:39:40 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] GRUU (was Whats wrong with Supported. X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Thu, 10 Nov 2005 17:39:42 +0100 Message-ID: Thread-Topic: [Sip] GRUU (was Whats wrong with Supported. thread-index: AcXlZRHKn0YGrEcxSpKXjL366EykuAApnNmw From: "Christian Jansson" To: "Dale R. Worley" , "Sip" X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Comments below: >Perhaps you could say something like this: > >"The presence of Supported: gruu suggests a high likelihood that the >Contact is a GRUU, and so a UA using that Contact SHOULD proceed on the >assumption that it is a GRUU, until it has positive information that it >is not. In particular, the UA should not utilize any mechanisms to work >around that the Contact is not a GRUU until it has determined that >utilizing it as a GRUU does not work." > >That language: > >1) makes all current networks conforming, regardless of "proprietary >hacks", because no element sends Supported: gruu yet. > >2) when "Supported: gruu" is present, bans proprietary hacks except as a >fall-back mechanism. > >which seems to me to be a good combination. > >Dale 1. Contact URIs should always have been globally routable 2. With GRUU there exists a mechanism to get a contact that fulfills 1. 3. From now on all clients that does what the spec says (1.) must include Supported: gruu... !!? Otherwise servers that do not follow the spec break things... but is that not a general rule of broken things?=20 Should we also add "Supported: transaction-id" that states that the transaction id is really unique over space and time, to let the other side understand that we did not just copy-paste the z9hG4bK into the branch id without understanding its purpose? Should "Supported: valid-sip" be added to indicate that we have added all mandatory headers like to, from, and so on? My conclusion: Servers that were broken before and applied hack solutions will not understand "Supported: gruu" and will continue to apply the hack solution. Servers that follow the spec and first try the contact as if it were a GRUU will work regardless of the presence of "Supported: gruu". Therefore I think the "Supported: gruu" should not be used (apart from REGISTER). / Christian Jansson _______________________________________________ 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 From sip-bounces@ietf.org Thu Nov 10 12:35:53 2005 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 1EaGL3-00044F-Rv; Thu, 10 Nov 2005 12:35:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaGL2-00044A-6T for sip@megatron.ietf.org; Thu, 10 Nov 2005 12:35:52 -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 MAA20641 for ; Thu, 10 Nov 2005 12:35:23 -0500 (EST) Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaGbI-0001P3-3m for sip@ietf.org; Thu, 10 Nov 2005 12:52:40 -0500 Received: (qmail 12042 invoked by uid 0); 10 Nov 2005 17:35:23 -0000 Received: from unknown (HELO BEMBUSTER) ([81.59.101.130]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 10 Nov 2005 17:35:23 -0000 Message-ID: <003501c5e61d$1e6961b0$6402a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "Jonathan Rosenberg" , "IETF SIP List" References: <43727F1E.8090001@cisco.com> Subject: Re: [Sip] GRUU, EP record-route stripping and retargeting Date: Thu, 10 Nov 2005 18:35:18 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: 1.2 (+) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Jonathan, see inline > I would like to revisit a proposal we discussed during the Paris IETF, > which was dismissed at the time. However, recent discussions on > retargeting vs. routing have clarified things in my mind sufficiently that > I think its the right way to go. > > The proposal that was made (by Dale I think), was to have the endpoint > insert the GRUU in the Contact of the 200 OK, but also have the UAS insert > a Record-Route for itself. As a consequence of this, the mid-dialog > requests would show up at the EP, but wouldn't get routed back around to > the home proxy because there is another route - pointing to the UA itself. > Thus, the request shows up at the UA in this form: > > INVITE sip:gruu > Route: sip:endpoint-ip > > this requires an endpoint to get a request with a Route header field and > process it. > > Whats interesting is that this is exactly the same structure we've been > talking about in the discussion on retargeting vs. routing. There, the > idea was that for requests outside of a dialog, the request would show up > at the home proxy, and the registered contact would then be placed into > the topmost Route header, and the R-URI would be preserved. When it > arrives at the UAS, the request would look like: > > INVITE sip:aor > Route: sip:endpoint-ip > > this actually makes a lot of sense; both initial and mid-dialog requests > are routed via Route header fields eventually arriving at the UAS with a > Route header that looks identically in each case. Initial requests show up > with an AOR in the r-uri, and mid-dialog requests, being targeted to the > instance to which the call is currently active, show up with the GRUU. > > There were two reasons discussed at the last IETF IIRC, on why we didn't > choose this approach. They were: > > 1. major change in sip architecture > 2. mid-dialog requests get "pegged" to a specific UA IP address and port > for the duration of the dialog, since they now appear in a record-route, > which cannot be updated mid-dialog > > I think the first issue is true, but recent discussions have clarified > (for me at least) how this would work and I am increasingly comfortable > with this change. > > The second issue is also still true. The question is whether that is > really important right now. The main applications for it have been > sip-level session mobility and continuation of dialogs during failures of > proxies when used with sip-outbound. The latter is something I'd really > like to have, but I'd prefer to defer specification of an approach for > this to a later time. As for the former usage (SIP-level session > mobility), others need to comment on how important that is (most mobility > work is done below the SIP layer). Instead of specifying that the UAS adds a Record-Route header to its response, what about making the UAC add a Route header containing the remote target (Contact) it learned from the dialog-creating response, in all mid-dialog requests. This gives the same resulting message and takes care of (2), since any endpoint can update its Contact when its IP address or port changes. Essentially this would make the UAC act just like a proxy would when it resolves an AoR to a Contact. A next logical step would be to have the UAC insert the URI it used for the initial request (i.e. typically an AoR) also in mid-dialog requests as request-URI, instead of the remote target (Contact). Changes to the request URI are then reserved for retargeting cases, which mid-dialog requests are not. They then become requests that are routed to a specific Contact (GRUU). In other words, all requests (both in and outside dialogs) would arrive at the UAS as: INVITE sip:aor Route: gruu (with grid) Regards, Jeroen van Bemmel _______________________________________________ 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 From sip-bounces@ietf.org Thu Nov 10 13:06:01 2005 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 1EaGoD-00042E-Gf; Thu, 10 Nov 2005 13:06:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaGoB-000429-Ai for sip@megatron.ietf.org; Thu, 10 Nov 2005 13:05:59 -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 NAA22358 for ; Thu, 10 Nov 2005 13:05:29 -0500 (EST) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaH4Q-0002EP-Au for sip@ietf.org; Thu, 10 Nov 2005 13:22:47 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id jAAI5b812673; Thu, 10 Nov 2005 13:05:37 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] Changing the From header Date: Thu, 10 Nov 2005 12:05:14 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF0536DEA1@zrc2hxm0.corp.nortel.com> Thread-Topic: [Sip] Changing the From header Thread-Index: AcXlpWiE1LijrOAdRNST1j9BF/G0CAAe5csw From: "Francois Audet" To: "Elwell, John" , "IETF SIP List" X-Spam-Score: 0.9 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2135855002==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============2135855002== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5E621.4D740600" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5E621.4D740600 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable John, =20 Do you think we need this? =20 Seems to me this is unecessary (provided we don't require RFC 2543 backward compatibility). =20 -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Elwell, John Sent: Wednesday, November 09, 2005 19:09 To: IETF SIP List Subject: [Sip] Changing the From header At yesterday's SIP session we had rough consensus on changing the From header field URI in mid-dialog requests. We also said that no special provision would be made to accommodate proxies that cannot cope with this. Nothing was said about UASs that cannot cope with this. Do we need an option tag to indicate support for a changed From header field URI during a dialog? With such an option tag, a UA that does not receive a Supported header field with this option tag during the dialog-forming transaction would refrain from changing the From header field URI in mid-dialog requests. John=20 ------_=_NextPart_001_01C5E621.4D740600 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
John,
 
Do you=20 think we need this?
 
Seems=20 to me this is unecessary (provided we don't require RFC 2543 backward=20 compatibility).
 
-----Original Message-----
From:=20 sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of = Elwell,=20 John
Sent: Wednesday, November 09, 2005 19:09
To: = IETF SIP=20 List
Subject: [Sip] Changing the From = header

At yesterday's SIP session we had rough = consensus=20 on changing the From header field URI in mid-dialog requests. We also = said=20 that no special provision would be made to accommodate proxies that = cannot=20 cope with this. Nothing was said about UASs that cannot cope with = this. Do we=20 need an option tag to indicate support for a changed From header field = URI=20 during a dialog? With such an option tag, a UA that does not receive a = Supported header field with this option tag during the dialog-forming=20 transaction would refrain from changing the From header field URI in=20 mid-dialog requests.

John =

------_=_NextPart_001_01C5E621.4D740600-- --===============2135855002== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============2135855002==-- From sip-bounces@ietf.org Thu Nov 10 14:06:05 2005 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 1EaHkL-00057h-3q; Thu, 10 Nov 2005 14:06:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaHkI-000553-U4 for sip@megatron.ietf.org; Thu, 10 Nov 2005 14:06:03 -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 OAA26706 for ; Thu, 10 Nov 2005 14:05:34 -0500 (EST) Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaI0Y-0004Dd-6T for sip@ietf.org; Thu, 10 Nov 2005 14:22:51 -0500 Received: from BPenfield2 [209.52.111.165] by acmepacket.com with ESMTP (SMTPD-8.21) id A9200754; Thu, 10 Nov 2005 14:01:52 -0500 Message-ID: <002501c5e629$a5191820$a56f34d1@acmepacket.com> From: "Bob Penfield" To: "Jeroen van Bemmel" , "Jonathan Rosenberg" , "IETF SIP List" References: <43727F1E.8090001@cisco.com> <003501c5e61d$1e6961b0$6402a8c0@BEMBUSTER> Subject: Re: [Sip] GRUU, EP record-route stripping and retargeting Date: Thu, 10 Nov 2005 11:04:57 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org inline ----- Original Message ----- From: "Jeroen van Bemmel" > Instead of specifying that the UAS adds a Record-Route header to its > response, what about making the UAC add a Route header containing the remote > target (Contact) it learned from the dialog-creating response, in all > mid-dialog requests. This gives the same resulting message and takes care of > (2), since any endpoint can update its Contact when its IP address or port > changes. > > Essentially this would make the UAC act just like a proxy would when it > resolves an AoR to a Contact. I think it is best that the UAS add the record-route. The general principle of adding things like record-route and path is that the entity desiring to be in the path inserts itself. Besides, if there is a B2BUA in the middle, such as a privacy service as defined in RFC 3323, the full route-set on the UAS side of the B2BUA does not reach the UAC. > > A next logical step would be to have the UAC insert the URI it used for the > initial request (i.e. typically an AoR) also in mid-dialog requests as > request-URI, instead of the remote target (Contact). Changes to the request > URI are then reserved for retargeting cases, which mid-dialog requests are > not. They then become requests that are routed to a specific Contact (GRUU). > > In other words, all requests (both in and outside dialogs) would arrive at > the UAS as: > > INVITE sip:aor > Route: gruu (with grid) I think this would still cause the mid-dialog request to spiral thru the edge proxy. > > Regards, > > Jeroen van Bemmel > > > > > _______________________________________________ > 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 From sip-bounces@ietf.org Thu Nov 10 14:12:52 2005 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 1EaHqu-00086a-BI; Thu, 10 Nov 2005 14:12:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaHqr-00083u-Gp for sip@megatron.ietf.org; Thu, 10 Nov 2005 14:12:49 -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 OAA27446 for ; Thu, 10 Nov 2005 14:12:21 -0500 (EST) Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaI78-0004YN-CO for sip@ietf.org; Thu, 10 Nov 2005 14:29:38 -0500 Received: from BPenfield2 [209.52.111.165] by acmepacket.com with ESMTP (SMTPD-8.21) id AABF111C; Thu, 10 Nov 2005 14:08:47 -0500 Message-ID: <003b01c5e62a$9cc41c00$a56f34d1@acmepacket.com> From: "Bob Penfield" To: "Francois Audet" , "Elwell, John" , "IETF SIP List" References: <1ECE0EB50388174790F9694F77522CCF0536DEA1@zrc2hxm0.corp.nortel.com> Subject: Re: [Sip] Changing the From header Date: Thu, 10 Nov 2005 11:11:52 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org The consequences of not using an option tag would be that a 2543 UAS might reject the in-dialog request with a 481. The UAC could then change back to the original From and re-try, but if any proxies along the path are keeping any kind of dialog/call state, they might remove that state when they saw the 481 pass by. cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 71 Third Avenue Burlington, MA 01803 bpenfield@acmepacket.com ----- Original Message ----- From: "Francois Audet" To: "Elwell, John" ; "IETF SIP List" Sent: Thursday, November 10, 2005 10:05 AM Subject: RE: [Sip] Changing the From header John, Do you think we need this? Seems to me this is unecessary (provided we don't require RFC 2543 backward compatibility). -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Elwell, John Sent: Wednesday, November 09, 2005 19:09 To: IETF SIP List Subject: [Sip] Changing the From header At yesterday's SIP session we had rough consensus on changing the From header field URI in mid-dialog requests. We also said that no special provision would be made to accommodate proxies that cannot cope with this. Nothing was said about UASs that cannot cope with this. Do we need an option tag to indicate support for a changed From header field URI during a dialog? With such an option tag, a UA that does not receive a Supported header field with this option tag during the dialog-forming transaction would refrain from changing the From header field URI in mid-dialog requests. John ---------------------------------------------------------------------------- ---- > _______________________________________________ > 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 From sip-bounces@ietf.org Thu Nov 10 14:15:41 2005 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 1EaHtc-00012D-Um; Thu, 10 Nov 2005 14:15:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaHta-0000zL-EV for sip@megatron.ietf.org; Thu, 10 Nov 2005 14:15:38 -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 OAA27756 for ; Thu, 10 Nov 2005 14:15:10 -0500 (EST) Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaI9r-0004gi-7h for sip@ietf.org; Thu, 10 Nov 2005 14:32:27 -0500 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0IPR00B016PKDQ@siemenscomms.co.uk> for sip@ietf.org; Thu, 10 Nov 2005 19:12:56 +0000 (GMT) Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0IPR008AI6PJO1@siemenscomms.co.uk>; Thu, 10 Nov 2005 19:12:55 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Thu, 10 Nov 2005 19:15:27 +0000 Content-return: allowed Date: Thu, 10 Nov 2005 19:15:18 +0000 From: "Elwell, John" Subject: RE: [Sip] Changing the From header To: Francois Audet , IETF SIP List Message-id: <50B1CBA96870A34799A506B2313F266707240C1E@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.7 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0367472474==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0367472474== Content-return: allowed Content-type: multipart/alternative; boundary="Boundary_(ID_Asgd42EsBG+HQDce3g7Dew)" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --Boundary_(ID_Asgd42EsBG+HQDce3g7Dew) Content-type: text/plain Content-Transfer-Encoding: 7BIT Francois, I hope we don't need it, but I would like confirmation. John _____ From: Francois Audet [mailto:audet@nortel.com] Sent: 10 November 2005 18:05 To: Elwell, John; IETF SIP List Subject: RE: [Sip] Changing the From header John, Do you think we need this? Seems to me this is unecessary (provided we don't require RFC 2543 backward compatibility). -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Elwell, John Sent: Wednesday, November 09, 2005 19:09 To: IETF SIP List Subject: [Sip] Changing the From header At yesterday's SIP session we had rough consensus on changing the From header field URI in mid-dialog requests. We also said that no special provision would be made to accommodate proxies that cannot cope with this. Nothing was said about UASs that cannot cope with this. Do we need an option tag to indicate support for a changed From header field URI during a dialog? With such an option tag, a UA that does not receive a Supported header field with this option tag during the dialog-forming transaction would refrain from changing the From header field URI in mid-dialog requests. John --Boundary_(ID_Asgd42EsBG+HQDce3g7Dew) Content-type: text/html Content-Transfer-Encoding: 7BIT Message
Francois,
 
I hope we don't need it, but I would like confirmation.
 
John

From: Francois Audet [mailto:audet@nortel.com]
Sent: 10 November 2005 18:05
To: Elwell, John; IETF SIP List
Subject: RE: [Sip] Changing the From header

John,
 
Do you think we need this?
 
Seems to me this is unecessary (provided we don't require RFC 2543 backward compatibility).
 
-----Original Message-----
From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Elwell, John
Sent: Wednesday, November 09, 2005 19:09
To: IETF SIP List
Subject: [Sip] Changing the From header

At yesterday's SIP session we had rough consensus on changing the From header field URI in mid-dialog requests. We also said that no special provision would be made to accommodate proxies that cannot cope with this. Nothing was said about UASs that cannot cope with this. Do we need an option tag to indicate support for a changed From header field URI during a dialog? With such an option tag, a UA that does not receive a Supported header field with this option tag during the dialog-forming transaction would refrain from changing the From header field URI in mid-dialog requests.

John

--Boundary_(ID_Asgd42EsBG+HQDce3g7Dew)-- --===============0367472474== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============0367472474==-- From sip-bounces@ietf.org Thu Nov 10 14:49:19 2005 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 1EaIQB-0003G6-Qf; Thu, 10 Nov 2005 14:49:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaIQ9-0003Eu-JG for sip@megatron.ietf.org; Thu, 10 Nov 2005 14:49:17 -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 OAA29835 for ; Thu, 10 Nov 2005 14:48:49 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaIgP-0006GU-AA for sip@ietf.org; Thu, 10 Nov 2005 15:06:07 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 10 Nov 2005 11:49:06 -0800 X-IronPort-AV: i="3.99,114,1131350400"; d="scan'208,217"; a="363498888:sNHT44071760" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jAAJmqbr022238; Thu, 10 Nov 2005 11:49:04 -0800 (PST) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 10 Nov 2005 14:48:56 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] Changing the From header Date: Thu, 10 Nov 2005 14:48:55 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3C0B966@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Sip] Changing the From header Thread-Index: AcXmK6XWelbeeTK7Q+Or6Ue3Q1AbNQAA1AfQ From: "Michael Hammer \(mhammer\)" To: "Elwell, John" , "Francois Audet" , "IETF SIP List" X-OriginalArrivalTime: 10 Nov 2005 19:48:56.0527 (UTC) FILETIME=[C9506DF0:01C5E62F] X-Spam-Score: 0.7 (/) X-Scan-Signature: a492040269d440726bfd84680622cee7 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1980471262==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1980471262== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5E62F.C9241BA0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5E62F.C9241BA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable John, =20 Wouldn't you need to have every UA and proxy involved with the call to signal that it supports changing From, e.g. in the Record-Route, e.g. a 3261 tag? If any one does not support it then making a mid-dialog change will break at the point that one doesn't recognize the dialog. =20 The converse might be to have a option-tag: 2543 if any node recognizes that another node will not support the above. =20 Mike ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Elwell, John Sent: Thursday, November 10, 2005 2:15 PM To: Francois Audet; IETF SIP List Subject: RE: [Sip] Changing the From header =09 =09 Francois, =20 I hope we don't need it, but I would like confirmation. =20 John ________________________________ From: Francois Audet [mailto:audet@nortel.com]=20 Sent: 10 November 2005 18:05 To: Elwell, John; IETF SIP List Subject: RE: [Sip] Changing the From header =09 =09 John, =20 Do you think we need this? =20 Seems to me this is unecessary (provided we don't require RFC 2543 backward compatibility). =20 -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Elwell, John Sent: Wednesday, November 09, 2005 19:09 To: IETF SIP List Subject: [Sip] Changing the From header =09 =09 At yesterday's SIP session we had rough consensus on changing the From header field URI in mid-dialog requests. We also said that no special provision would be made to accommodate proxies that cannot cope with this. Nothing was said about UASs that cannot cope with this. Do we need an option tag to indicate support for a changed From header field URI during a dialog? With such an option tag, a UA that does not receive a Supported header field with this option tag during the dialog-forming transaction would refrain from changing the From header field URI in mid-dialog requests. John=20 ------_=_NextPart_001_01C5E62F.C9241BA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
John,
 
Wouldn't you need to have every UA and proxy involved = with the=20 call to signal that it supports changing From, e.g. in the Record-Route, = e.g. a=20 3261 tag?  If any one does not support it then making a mid-dialog = change=20 will break at the point that one doesn't recognize the=20 dialog.
 
The converse might be to have a option-tag: 2543 if = any node=20 recognizes that another node will not support the = above.
 
Mike

From: sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org] On Behalf Of Elwell, = John
Sent:=20 Thursday, November 10, 2005 2:15 PM
To: Francois Audet; IETF = SIP=20 List
Subject: RE: [Sip] Changing the From=20 header

Francois,
 
I hope we don't need it, but I would like=20 confirmation.
 
John

From: Francois Audet=20 [mailto:audet@nortel.com]
Sent: 10 November 2005=20 18:05
To: Elwell, John; IETF SIP List
Subject: = RE: [Sip]=20 Changing the From header

John,
 
Do=20 you think we need this?
 
Seems to me this is unecessary (provided we don't require = RFC 2543=20 backward compatibility).
 
-----Original Message-----
From:=20 sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of = Elwell, John
Sent: Wednesday, November 09, 2005=20 19:09
To: IETF SIP List
Subject: [Sip] = Changing the=20 From header

At yesterday's SIP session we had = rough=20 consensus on changing the From header field URI in mid-dialog = requests. We=20 also said that no special provision would be made to accommodate = proxies=20 that cannot cope with this. Nothing was said about UASs that = cannot cope=20 with this. Do we need an option tag to indicate support for a = changed From=20 header field URI during a dialog? With such an option tag, a UA = that does=20 not receive a Supported header field with this option tag during = the=20 dialog-forming transaction would refrain from changing the From = header=20 field URI in mid-dialog requests.

John=20

------_=_NextPart_001_01C5E62F.C9241BA0-- --===============1980471262== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1980471262==-- From sip-bounces@ietf.org Thu Nov 10 14:53:48 2005 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 1EaIUW-0004VD-Ca; Thu, 10 Nov 2005 14:53:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaIUT-0004UT-R3 for sip@megatron.ietf.org; Thu, 10 Nov 2005 14:53:45 -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 OAA00106 for ; Thu, 10 Nov 2005 14:53:17 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaIkk-0006P5-RJ for sip@ietf.org; Thu, 10 Nov 2005 15:10:35 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 10 Nov 2005 11:53:36 -0800 X-IronPort-AV: i="3.99,114,1131350400"; d="scan'208,217"; a="363501260:sNHT38604516" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jAAJrUq5022886; Thu, 10 Nov 2005 11:53:34 -0800 (PST) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 10 Nov 2005 14:53:26 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] Changing the To header Date: Thu, 10 Nov 2005 14:53:25 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3C0B968@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Sip] Changing the To header Thread-Index: AcXlpZSEVkdiPR4KT1eSOss4LOmuJgAiou0g From: "Michael Hammer \(mhammer\)" To: "Elwell, John" , "IETF SIP List" X-OriginalArrivalTime: 10 Nov 2005 19:53:26.0258 (UTC) FILETIME=[6A161D20:01C5E630] X-Spam-Score: 0.6 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1244280603==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1244280603== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5E630.6A02262A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5E630.6A02262A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Could you clarify what you mean by wait for an authenticated identity. Is that an Auth-ID body or is it the implication that an endpoint corrected the To: header or provided an additional P-header? =20 Mike =20 ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Elwell, John Sent: Wednesday, November 09, 2005 10:09 PM To: IETF SIP List Subject: [Sip] Changing the To header =09 =09 In yesterday's SIP session it was agreed to investigate the possibility of changing the To header field URI in a response to a dialog-forming request. To kick off this discussion, here are my thoughts. A modified To header field URI in a response to a dialog-forming request can indicate that the request has been retargeted. This would not be authenticated, so if an authenticated called party identity is required it would be necessary to ignore the modified To header field URI and wait for an authenticated identity in a subsequent request from the called party. One use case is in a closed environment, particularly where sips is used, where transitive trust is used to give credibility to the unauthenticated identity. A second use case is to give a preliminary indication based on an identity in a provisional response, to be replaced by an indication based on an authenticated identity in the subsequent 2xx response. Fire away.=20 John=20 ------_=_NextPart_001_01C5E630.6A02262A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Changing the To header
Could you clarify what you mean by wait for an = authenticated=20 identity.  Is that an Auth-ID body or is it the implication that an = endpoint corrected the To: header or provided an additional=20 P-header?
 
Mike
 

From: sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org] On Behalf Of Elwell, = John
Sent:=20 Wednesday, November 09, 2005 10:09 PM
To: IETF SIP=20 List
Subject: [Sip] Changing the To = header

In yesterday's SIP session it was = agreed to=20 investigate the possibility of changing the To header field URI in a = response=20 to a dialog-forming request. To kick off this discussion, here are my=20 thoughts.

A modified To header field URI in a = response to a=20 dialog-forming request can indicate that the request has been = retargeted. This=20 would not be authenticated, so if an authenticated called party = identity is=20 required it would be necessary to ignore the modified To header field = URI and=20 wait for an authenticated identity in a subsequent request from the = called=20 party.

One use case is in a closed = environment,=20 particularly where sips is used, where transitive trust is used to = give=20 credibility to the unauthenticated identity.

A second use case is to give a = preliminary=20 indication based on an identity in a provisional response, to be = replaced by=20 an indication based on an authenticated identity in the subsequent 2xx = response.

Fire away.

John =

------_=_NextPart_001_01C5E630.6A02262A-- --===============1244280603== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1244280603==-- From sip-bounces@ietf.org Thu Nov 10 15:36:05 2005 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 1EaJ9R-0004Nm-S3; Thu, 10 Nov 2005 15:36:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaJ9Q-0004Nh-M6 for sip@megatron.ietf.org; Thu, 10 Nov 2005 15:36:04 -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 PAA02903 for ; Thu, 10 Nov 2005 15:35:36 -0500 (EST) Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaJPi-0007g3-3B for sip@ietf.org; Thu, 10 Nov 2005 15:52:54 -0500 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0IPR00801AFB41@siemenscomms.co.uk> for sip@ietf.org; Thu, 10 Nov 2005 20:33:12 +0000 (GMT) Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0IPR0039LAFBJ7@siemenscomms.co.uk>; Thu, 10 Nov 2005 20:33:11 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Thu, 10 Nov 2005 20:35:44 +0000 Content-return: allowed Date: Thu, 10 Nov 2005 20:34:22 +0000 From: "Elwell, John" Subject: RE: [Sip] Changing the To header To: "Michael Hammer (mhammer)" , IETF SIP List Message-id: <50B1CBA96870A34799A506B2313F266707240C45@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.9 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1682263761==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1682263761== Content-return: allowed Content-type: multipart/alternative; boundary="Boundary_(ID_F8fG2JEpxXa1/G+Ol2JMrg)" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --Boundary_(ID_F8fG2JEpxXa1/G+Ol2JMrg) Content-type: text/plain Content-Transfer-Encoding: 7BIT Michael, What I mean is a request in the reverse direction (e.g., UPDATE) carrying the Identity header, which authenticates the From header. John _____ From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] Sent: 10 November 2005 19:53 To: Elwell, John; IETF SIP List Subject: RE: [Sip] Changing the To header Could you clarify what you mean by wait for an authenticated identity. Is that an Auth-ID body or is it the implication that an endpoint corrected the To: header or provided an additional P-header? Mike _____ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Elwell, John Sent: Wednesday, November 09, 2005 10:09 PM To: IETF SIP List Subject: [Sip] Changing the To header In yesterday's SIP session it was agreed to investigate the possibility of changing the To header field URI in a response to a dialog-forming request. To kick off this discussion, here are my thoughts. A modified To header field URI in a response to a dialog-forming request can indicate that the request has been retargeted. This would not be authenticated, so if an authenticated called party identity is required it would be necessary to ignore the modified To header field URI and wait for an authenticated identity in a subsequent request from the called party. One use case is in a closed environment, particularly where sips is used, where transitive trust is used to give credibility to the unauthenticated identity. A second use case is to give a preliminary indication based on an identity in a provisional response, to be replaced by an indication based on an authenticated identity in the subsequent 2xx response. Fire away. John --Boundary_(ID_F8fG2JEpxXa1/G+Ol2JMrg) Content-type: text/html Content-Transfer-Encoding: 7BIT Changing the To header
Michael,
 
What I mean is a request in the reverse direction (e.g., UPDATE) carrying the Identity header, which authenticates the From header.
 
John

From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com]
Sent: 10 November 2005 19:53
To: Elwell, John; IETF SIP List
Subject: RE: [Sip] Changing the To header

Could you clarify what you mean by wait for an authenticated identity.  Is that an Auth-ID body or is it the implication that an endpoint corrected the To: header or provided an additional P-header?
 
Mike
 

From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Elwell, John
Sent: Wednesday, November 09, 2005 10:09 PM
To: IETF SIP List
Subject: [Sip] Changing the To header

In yesterday's SIP session it was agreed to investigate the possibility of changing the To header field URI in a response to a dialog-forming request. To kick off this discussion, here are my thoughts.

A modified To header field URI in a response to a dialog-forming request can indicate that the request has been retargeted. This would not be authenticated, so if an authenticated called party identity is required it would be necessary to ignore the modified To header field URI and wait for an authenticated identity in a subsequent request from the called party.

One use case is in a closed environment, particularly where sips is used, where transitive trust is used to give credibility to the unauthenticated identity.

A second use case is to give a preliminary indication based on an identity in a provisional response, to be replaced by an indication based on an authenticated identity in the subsequent 2xx response.

Fire away.

John

--Boundary_(ID_F8fG2JEpxXa1/G+Ol2JMrg)-- --===============1682263761== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1682263761==-- From sip-bounces@ietf.org Thu Nov 10 15:36:41 2005 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 1EaJA1-0004Uf-B2; Thu, 10 Nov 2005 15:36:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaJ9z-0004Si-8a for sip@megatron.ietf.org; Thu, 10 Nov 2005 15:36:39 -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 PAA02929 for ; Thu, 10 Nov 2005 15:36:11 -0500 (EST) Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaJQG-0007hk-Ig for sip@ietf.org; Thu, 10 Nov 2005 15:53:29 -0500 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0IPR00801AGL54@siemenscomms.co.uk> for sip@ietf.org; Thu, 10 Nov 2005 20:33:57 +0000 (GMT) Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0IPR003A9AGKJ7@siemenscomms.co.uk>; Thu, 10 Nov 2005 20:33:56 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Thu, 10 Nov 2005 20:36:29 +0000 Content-return: allowed Date: Thu, 10 Nov 2005 20:36:09 +0000 From: "Elwell, John" Subject: RE: [Sip] Changing the From header To: "Michael Hammer (mhammer)" , Francois Audet , IETF SIP List Message-id: <50B1CBA96870A34799A506B2313F266707240C47@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.7 (/) X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0833235576==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0833235576== Content-return: allowed Content-type: multipart/alternative; boundary="Boundary_(ID_Tb5zh6sARUJSSOiz71BbVw)" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --Boundary_(ID_Tb5zh6sARUJSSOiz71BbVw) Content-type: text/plain Content-Transfer-Encoding: 7BIT Michael, The consensus in SIP on Tuesday was that we should not take any special action to deal with proxies that fail to comply with RFC3261. Therefore my question concerns only UAs. John _____ From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] Sent: 10 November 2005 19:49 To: Elwell, John; Francois Audet; IETF SIP List Subject: RE: [Sip] Changing the From header John, Wouldn't you need to have every UA and proxy involved with the call to signal that it supports changing From, e.g. in the Record-Route, e.g. a 3261 tag? If any one does not support it then making a mid-dialog change will break at the point that one doesn't recognize the dialog. The converse might be to have a option-tag: 2543 if any node recognizes that another node will not support the above. Mike _____ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Elwell, John Sent: Thursday, November 10, 2005 2:15 PM To: Francois Audet; IETF SIP List Subject: RE: [Sip] Changing the From header Francois, I hope we don't need it, but I would like confirmation. John _____ From: Francois Audet [mailto:audet@nortel.com] Sent: 10 November 2005 18:05 To: Elwell, John; IETF SIP List Subject: RE: [Sip] Changing the From header John, Do you think we need this? Seems to me this is unecessary (provided we don't require RFC 2543 backward compatibility). -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Elwell, John Sent: Wednesday, November 09, 2005 19:09 To: IETF SIP List Subject: [Sip] Changing the From header At yesterday's SIP session we had rough consensus on changing the From header field URI in mid-dialog requests. We also said that no special provision would be made to accommodate proxies that cannot cope with this. Nothing was said about UASs that cannot cope with this. Do we need an option tag to indicate support for a changed From header field URI during a dialog? With such an option tag, a UA that does not receive a Supported header field with this option tag during the dialog-forming transaction would refrain from changing the From header field URI in mid-dialog requests. John --Boundary_(ID_Tb5zh6sARUJSSOiz71BbVw) Content-type: text/html Content-Transfer-Encoding: 7BIT Message
Michael,
 
The consensus in SIP on Tuesday was that we should not take any special action to deal with proxies that fail to comply with RFC3261. Therefore my question concerns only UAs.
 
John
 
From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com]
Sent: 10 November 2005 19:49
To: Elwell, John; Francois Audet; IETF SIP List
Subject: RE: [Sip] Changing the From header

John,
 
Wouldn't you need to have every UA and proxy involved with the call to signal that it supports changing From, e.g. in the Record-Route, e.g. a 3261 tag?  If any one does not support it then making a mid-dialog change will break at the point that one doesn't recognize the dialog.
 
The converse might be to have a option-tag: 2543 if any node recognizes that another node will not support the above.
 
Mike

From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Elwell, John
Sent: Thursday, November 10, 2005 2:15 PM
To: Francois Audet; IETF SIP List
Subject: RE: [Sip] Changing the From header

Francois,
 
I hope we don't need it, but I would like confirmation.
 
John

From: Francois Audet [mailto:audet@nortel.com]
Sent: 10 November 2005 18:05
To: Elwell, John; IETF SIP List
Subject: RE: [Sip] Changing the From header

John,
 
Do you think we need this?
 
Seems to me this is unecessary (provided we don't require RFC 2543 backward compatibility).
 
-----Original Message-----
From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Elwell, John
Sent: Wednesday, November 09, 2005 19:09
To: IETF SIP List
Subject: [Sip] Changing the From header

At yesterday's SIP session we had rough consensus on changing the From header field URI in mid-dialog requests. We also said that no special provision would be made to accommodate proxies that cannot cope with this. Nothing was said about UASs that cannot cope with this. Do we need an option tag to indicate support for a changed From header field URI during a dialog? With such an option tag, a UA that does not receive a Supported header field with this option tag during the dialog-forming transaction would refrain from changing the From header field URI in mid-dialog requests.

John

--Boundary_(ID_Tb5zh6sARUJSSOiz71BbVw)-- --===============0833235576== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============0833235576==-- From sip-bounces@ietf.org Thu Nov 10 20:42:50 2005 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 1EaNwI-00027y-64; Thu, 10 Nov 2005 20:42:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaNwG-00027F-9f for sip@megatron.ietf.org; Thu, 10 Nov 2005 20:42:48 -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 UAA01832 for ; Thu, 10 Nov 2005 20:42:20 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaOCa-0003Jk-GB for sip@ietf.org; Thu, 10 Nov 2005 20:59:40 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 10 Nov 2005 17:42:38 -0800 X-IronPort-AV: i="3.99,115,1131350400"; d="scan'208"; a="229177714:sNHT32844292" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id jAB1gYZd026980; Thu, 10 Nov 2005 17:42:35 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 10 Nov 2005 20:42:35 -0500 Received: from [209.52.109.209] ([10.86.241.14]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 10 Nov 2005 20:42:34 -0500 Message-ID: <4373F709.6020201@cisco.com> Date: Thu, 10 Nov 2005 20:42:33 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Elwell, John" Subject: Re: [Sip] Changing the From header References: <50B1CBA96870A34799A506B2313F266707240C47@ntht201e.siemenscomms.co.uk> In-Reply-To: <50B1CBA96870A34799A506B2313F266707240C47@ntht201e.siemenscomms.co.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Nov 2005 01:42:35.0385 (UTC) FILETIME=[30BD3690:01C5E661] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: 7bit Cc: IETF SIP List , Francois Audet X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I still think a Supported is a good idea. At the very least, if its not supported, a UA on the other side can know its not worth its trouble to try an UPDATE with a new From. There is no harm to the Supported tag, and it might help. -Jonathan R. Elwell, John wrote: > Michael, > > The consensus in SIP on Tuesday was that we should not take any special > action to deal with proxies that fail to comply with RFC3261. Therefore > my question concerns only UAs. > > John > > ------------------------------------------------------------------------ > *From:* Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > *Sent:* 10 November 2005 19:49 > *To:* Elwell, John; Francois Audet; IETF SIP List > *Subject:* RE: [Sip] Changing the From header > > John, > > Wouldn't you need to have every UA and proxy involved with the call > to signal that it supports changing From, e.g. in the Record-Route, > e.g. a 3261 tag? If any one does not support it then making a > mid-dialog change will break at the point that one doesn't recognize > the dialog. > > The converse might be to have a option-tag: 2543 if any node > recognizes that another node will not support the above. > > Mike > > ------------------------------------------------------------------------ > *From:* sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] *On > Behalf Of *Elwell, John > *Sent:* Thursday, November 10, 2005 2:15 PM > *To:* Francois Audet; IETF SIP List > *Subject:* RE: [Sip] Changing the From header > > Francois, > > I hope we don't need it, but I would like confirmation. > > John > > ------------------------------------------------------------------------ > *From:* Francois Audet [mailto:audet@nortel.com] > *Sent:* 10 November 2005 18:05 > *To:* Elwell, John; IETF SIP List > *Subject:* RE: [Sip] Changing the From header > > John, > > Do you think we need this? > > Seems to me this is unecessary (provided we don't require > RFC 2543 backward compatibility). > > > -----Original Message----- > *From:* sip-bounces@ietf.org > [mailto:sip-bounces@ietf.org] *On Behalf Of *Elwell, John > *Sent:* Wednesday, November 09, 2005 19:09 > *To:* IETF SIP List > *Subject:* [Sip] Changing the From header > > At yesterday's SIP session we had rough consensus on > changing the From header field URI in mid-dialog > requests. We also said that no special provision would > be made to accommodate proxies that cannot cope with > this. Nothing was said about UASs that cannot cope with > this. Do we need an option tag to indicate support for a > changed From header field URI during a dialog? With such > an option tag, a UA that does not receive a Supported > header field with this option tag during the > dialog-forming transaction would refrain from changing > the From header field URI in mid-dialog requests. > > John > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ 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 From sip-bounces@ietf.org Thu Nov 10 22:07:45 2005 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 1EaPGT-0002VJ-C3; Thu, 10 Nov 2005 22:07:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaPGR-0002VD-9D for sip@megatron.ietf.org; Thu, 10 Nov 2005 22:07:43 -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 WAA06364 for ; Thu, 10 Nov 2005 22:07:14 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaPWl-0005Rb-7m for sip@ietf.org; Thu, 10 Nov 2005 22:24:36 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 10 Nov 2005 19:07:33 -0800 X-IronPort-AV: i="3.99,115,1131350400"; d="scan'208"; a="673856586:sNHT37086776" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jAB36qZk016414; Thu, 10 Nov 2005 19:07:30 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 10 Nov 2005 19:07:29 -0800 Received: from [10.21.113.175] ([10.21.113.175]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 10 Nov 2005 19:07:28 -0800 Message-ID: <43740AF6.10106@cisco.com> Date: Thu, 10 Nov 2005 22:07:34 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Jansson Subject: Re: [Sip] GRUU (was Whats wrong with Supported. References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Nov 2005 03:07:28.0453 (UTC) FILETIME=[0C71B750:01C5E66D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: Sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Christian Jansson wrote: > My conclusion: > Servers that were broken before and applied hack solutions will not > understand "Supported: gruu" and will continue to apply the hack > solution. Servers that follow the spec and first try the contact as if > it were a GRUU will work regardless of the presence of "Supported: > gruu". Therefore I think the "Supported: gruu" should not be used (apart > from REGISTER). I think there are practical difficulties with this. In a real deployment you would like the common case to be that things work on the first try. If you usually have to try twice then you effectively double the amount of signaling your network must support, and increase the latency as well. Following your suggestion, if you deploy a "modern" (gruuful) proxy with only gruuless UAs, you would have double the traffic you would have if you had the proxy recognize "Supported:gruu". Paul _______________________________________________ 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 From sip-bounces@ietf.org Fri Nov 11 03:14:07 2005 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 1EaU2w-0004R2-NO; Fri, 11 Nov 2005 03:14:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaU2v-0004Qx-5L for sip@megatron.ietf.org; Fri, 11 Nov 2005 03:14:05 -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 DAA22051 for ; Fri, 11 Nov 2005 03:13:36 -0500 (EST) Received: from mail1.hotsip.com ([62.119.82.23] helo=mail2.hotsip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaUJH-0004sz-DQ for sip@ietf.org; Fri, 11 Nov 2005 03:31:01 -0500 Received: from 62.119.82.41 [62.119.82.41] by mail2.hotsip.com with XWall v3.33 ; Fri, 11 Nov 2005 09:13:47 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] GRUU (was Whats wrong with Supported. X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Fri, 11 Nov 2005 09:13:48 +0100 Message-ID: Thread-Topic: [Sip] GRUU (was Whats wrong with Supported. thread-index: AcXmbnUxCtsjF2bHSTCucEViuDpCHQAJohEg From: "Christian Jansson" To: "Paul Kyzivat" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable Cc: Sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org >I think there are practical difficulties with this. > >In a real deployment you would like the common case to be that things >work on the first try. If you usually have to try twice then you >effectively double the amount of signaling your network must support, >and increase the latency as well. > >Following your suggestion, if you deploy a "modern" (gruuful) proxy with >only gruuless UAs, you would have double the traffic you would have if >you had the proxy recognize "Supported:gruu". > > Paul But wouldn't it be better to let the broken things advertise that they do not follow the specification completely. Let the UAs that do not insert contact that is globally routable add a "Supported: not-gruu-contact" if they do not want to have the penalty of the proxy trying twice. I think we should optimize the performance for those who do things right according to the spec, instead of having everybody adding more kludges to their messages. Of course we should also have a backwards compatible solution, but I think it is very important to have the additional cost paid by members with the broken implementations, "Supported: not-gruu-contact" would be my simple suggestion. / Christian Jansson _______________________________________________ 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 From sip-bounces@ietf.org Fri Nov 11 09:16:30 2005 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 1EaZhe-0003Aw-4T; Fri, 11 Nov 2005 09:16:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaZhc-0003AI-5D for sip@megatron.ietf.org; Fri, 11 Nov 2005 09:16:28 -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 JAA07544 for ; Fri, 11 Nov 2005 09:15:58 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaZ6j-0007d5-BU for sip@ietf.org; Fri, 11 Nov 2005 08:38:21 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 11 Nov 2005 05:21:14 -0800 X-IronPort-AV: i="3.99,118,1131350400"; d="scan'208"; a="363851892:sNHT26502292" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jABDKmc1016051; Fri, 11 Nov 2005 05:21:11 -0800 (PST) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 11 Nov 2005 08:20:58 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] GRUU (was Whats wrong with Supported. Date: Fri, 11 Nov 2005 08:20:56 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3C0BAD6@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Sip] GRUU (was Whats wrong with Supported. Thread-Index: AcXmbnUxCtsjF2bHSTCucEViuDpCHQAJohEgAAtqXqA= From: "Michael Hammer \(mhammer\)" To: "Christian Jansson" , "Paul Kyzivat \(pkyzivat\)" X-OriginalArrivalTime: 11 Nov 2005 13:20:58.0001 (UTC) FILETIME=[C0A50010:01C5E6C2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: quoted-printable Cc: Sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Christian, Isn't this the equivalent of asking everyone not in the room to please raise your hand? Mike =20 > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20 > Behalf Of Christian Jansson > Sent: Friday, November 11, 2005 3:14 AM > To: Paul Kyzivat (pkyzivat) > Cc: Sip > Subject: RE: [Sip] GRUU (was Whats wrong with Supported. >=20 > >I think there are practical difficulties with this. > > > >In a real deployment you would like the common case to be=20 > that things=20 > >work on the first try. If you usually have to try twice then you=20 > >effectively double the amount of signaling your network must=20 > support,=20 > >and increase the latency as well. > > > >Following your suggestion, if you deploy a "modern" (gruuful) proxy > with > >only gruuless UAs, you would have double the traffic you=20 > would have if=20 > >you had the proxy recognize "Supported:gruu". > > > > Paul >=20 > But wouldn't it be better to let the broken things advertise=20 > that they do not follow the specification completely. Let the=20 > UAs that do not insert contact that is globally routable add=20 > a "Supported: > not-gruu-contact" if they do not want to have the penalty of=20 > the proxy trying twice. I think we should optimize the=20 > performance for those who do things right according to the=20 > spec, instead of having everybody adding more kludges to=20 > their messages. Of course we should also have a backwards=20 > compatible solution, but I think it is very important to have=20 > the additional cost paid by members with the broken implementations, > "Supported: not-gruu-contact" would be my simple suggestion. >=20 > / Christian Jansson >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ 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 From sip-bounces@ietf.org Sat Nov 12 09:13:05 2005 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 1Eaw7s-0000Zq-Vq; Sat, 12 Nov 2005 09:13:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eaw7r-0000ZF-90 for sip@megatron.ietf.org; Sat, 12 Nov 2005 09:13:03 -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 JAA04658 for ; Sat, 12 Nov 2005 09:12:32 -0500 (EST) Received: from [203.188.58.134] (helo=rautu.tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EawOS-0006YK-NF for sip@ietf.org; Sat, 12 Nov 2005 09:30:14 -0500 Received: from rautu.tutpro.com (smmsp@localhost [127.0.0.1]) by rautu.tutpro.com (8.13.4/8.13.4/Debian-3) with ESMTP id jACECTVn003245; Sat, 12 Nov 2005 16:12:38 +0200 Received: (from jh@localhost) by rautu.tutpro.com (8.13.4/8.13.4/Submit) id jACDt9OU004023; Sat, 12 Nov 2005 15:55:09 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17269.62525.630010.95@rautu.tutpro.com> Date: Sat, 12 Nov 2005 15:55:09 +0200 From: Juha Heinanen To: Jonathan Rosenberg Subject: [Sip] GRUU, EP record-route stripping and retargeting In-Reply-To: <43727F1E.8090001@cisco.com> References: <43727F1E.8090001@cisco.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Jonathan Rosenberg writes: > 2. mid-dialog requests get "pegged" to a specific UA IP address and port > for the duration of the dialog, since they now appear in a record-route, > which cannot be updated mid-dialog jonathan, i was hoping that gruu together with for example replaces header could be used to implement session level mobility between different network technologies. i would be VERY disappointed if that would no longer be the case. > The second issue is also still true. The question is whether that is > really important right now. The main applications for it have been > sip-level session mobility and continuation of dialogs during failures > of proxies when used with sip-outbound. The latter is something I'd > really like to have, but I'd prefer to defer specification of an > approach for this to a later time. As for the former usage (SIP-level > session mobility), others need to comment on how important that is (most > mobility work is done below the SIP layer). are you saying it is OK that IETF has no solution for sip session level mobility and those who need it should use UMA or some other 3gpp technology instead? -- juha _______________________________________________ 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 From sip-bounces@ietf.org Mon Nov 14 10:48:34 2005 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 1EbgZO-00024B-PH; Mon, 14 Nov 2005 10:48:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbgZN-00023d-Dt for sip@megatron.ietf.org; Mon, 14 Nov 2005 10:48:33 -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 KAA00423 for ; Mon, 14 Nov 2005 10:48:01 -0500 (EST) Received: from mail1.hotsip.com ([62.119.82.23] helo=mail2.hotsip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EbgqQ-0000qE-JS for sip@ietf.org; Mon, 14 Nov 2005 11:06:11 -0500 Received: from 62.119.82.41 [62.119.82.41] by mail2.hotsip.com with XWall v3.33 ; Mon, 14 Nov 2005 16:47:59 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: [Sip] GRUU (was Whats wrong with Supported. Date: Mon, 14 Nov 2005 16:47:58 +0100 Message-ID: Thread-Topic: [Sip] GRUU (was Whats wrong with Supported. thread-index: AcXmbnUxCtsjF2bHSTCucEViuDpCHQAJohEgAAtqXqAAm32IAA== From: "Christian Jansson" To: "Michael Hammer (mhammer)" , "Paul Kyzivat (pkyzivat)" X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: quoted-printable Cc: Sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org So, you think the solution I presented is not enough?=20 The implementations that know they are broken can say so to speed up handling (optional to follow by server). The rest of the broken implementations will get a penalty when the server first tries to do the right thing before finally trying any dirty hacks. I bet someone is going to say something like: "But what if I know that all my UAs are "broken". Then the server can do the hacks first to speed things up". My answer to that is that our goal is to standardize and optimize the correct way of doing things. People can do whatever crazy things they like and implement other solutions, but it won't be standard SIP. In this case I even presented a back-up solution that will work even for those who haven't done everything right. What more could they ask for?=20 Instead, tell me why everybody, from now on, and forever, should pay the prize because some implementations choose to take a short-cut. (SIP is already full of those kludges, lets not make another one if we can avoid it!) / Christian Jansson >Isn't this the equivalent of asking everyone not in the room to please >raise your hand? > >Mike > > >> -----Original Message----- >> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On >> Behalf Of Christian Jansson >> Sent: Friday, November 11, 2005 3:14 AM >> To: Paul Kyzivat (pkyzivat) >> Cc: Sip >> Subject: RE: [Sip] GRUU (was Whats wrong with Supported. >> >> >I think there are practical difficulties with this. >> > >> >In a real deployment you would like the common case to be >> that things >> >work on the first try. If you usually have to try twice then you >> >effectively double the amount of signaling your network must >> support, >> >and increase the latency as well. >> > >> >Following your suggestion, if you deploy a "modern" (gruuful) proxy >> with >> >only gruuless UAs, you would have double the traffic you >> would have if >> >you had the proxy recognize "Supported:gruu". >> > >> > Paul >> >> But wouldn't it be better to let the broken things advertise >> that they do not follow the specification completely. Let the >> UAs that do not insert contact that is globally routable add >> a "Supported: >> not-gruu-contact" if they do not want to have the penalty of >> the proxy trying twice. I think we should optimize the >> performance for those who do things right according to the >> spec, instead of having everybody adding more kludges to >> their messages. Of course we should also have a backwards >> compatible solution, but I think it is very important to have >> the additional cost paid by members with the broken implementations, >> "Supported: not-gruu-contact" would be my simple suggestion. >> >> / Christian Jansson >> >> >> >> _______________________________________________ >> 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 From sip-bounces@ietf.org Mon Nov 14 13:45:56 2005 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 1EbjL2-0004Hk-DG; Mon, 14 Nov 2005 13:45:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbjKz-0004GS-Pt for sip@megatron.ietf.org; Mon, 14 Nov 2005 13:45:54 -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 NAA13175 for ; Mon, 14 Nov 2005 13:45:22 -0500 (EST) Received: from bdsoft10.vwh.net ([130.94.149.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ebjc4-0007IG-1A for sip@ietf.org; Mon, 14 Nov 2005 14:03:33 -0500 Received: from brett1 (ip67-88-7-2.z7-88-67.customer.algx.net [67.88.7.2]) (authenticated bits=0) by bdsoft10.vwh.net (8.13.1/8.12.11) with ESMTP id jAEIjRPZ031519; Mon, 14 Nov 2005 13:45:33 -0500 (EST) From: "Brett Tate" To: Subject: RE: [Sip] WGLC for draft-ietf-sip-connect-reuse-04.txt Date: Mon, 14 Nov 2005 13:45:56 -0500 Message-ID: <000501c5e94b$a6f01ca0$2c28a8c0@brett1> 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.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal In-Reply-To: <312FA63B-E9F0-453D-8DF5-853CB7056A42@softarmor.com> X-PMX-IsInternal: True X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: 'Rohan Mahy' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > Let's start by putting Brett's three questions "on the plate" > and noting that WGLC isn't over until they're resolved. > > > See: > > http://www1.ietf.org/mail-archive/web/sip/current/msg12069.html > http://www1.ietf.org/mail-archive/web/sip/current/msg12077.html > http://www1.ietf.org/mail-archive/web/sip/current/msg12106.html > The IETF 64 SIP agenda mentioned that the reuse draft was to be discussed. I wish that I could have attended. And I am anxiously awaiting the preliminary minutes and slides. :) If the discussion included resolutions for the linked questions, would someone please post (or send me) the answers to the questions. Thanks in advance, Brett _______________________________________________ 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 From sip-bounces@ietf.org Mon Nov 14 13:57:00 2005 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 1EbjVk-0006d7-5d; Mon, 14 Nov 2005 13:57:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbjVi-0006ce-0p for sip@megatron.ietf.org; Mon, 14 Nov 2005 13:56:58 -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 NAA13794 for ; Mon, 14 Nov 2005 13:56:26 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ebjmn-0007f6-8E for sip@ietf.org; Mon, 14 Nov 2005 14:14:37 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 14 Nov 2005 13:56:49 -0500 X-IronPort-AV: i="3.97,328,1125892800"; d="scan'208"; a="75710666:sNHT27070632" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jAEIuN4d017707; Mon, 14 Nov 2005 13:56:46 -0500 (EST) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 14 Nov 2005 13:56:43 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] GRUU (was Whats wrong with Supported. Date: Mon, 14 Nov 2005 13:56:42 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3C6F5E3@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Sip] GRUU (was Whats wrong with Supported. Thread-Index: AcXmbnUxCtsjF2bHSTCucEViuDpCHQAJohEgAAtqXqAAm32IAAAHAN4g From: "Michael Hammer \(mhammer\)" To: "Christian Jansson" , "Paul Kyzivat \(pkyzivat\)" X-OriginalArrivalTime: 14 Nov 2005 18:56:43.0780 (UTC) FILETIME=[27B42C40:01C5E94D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Content-Transfer-Encoding: quoted-printable Cc: Sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Could you explain the cost/benefit of some vendor to upgrade their client just to say they don't support each new feature? That doesn't mean that the system can not progress, just that it needs to determine if it is breaking a previous feature where backward compatibility is worthwhile, or whether the previous feature was broken to begin with and will remain broken until certain elements get with the program. Mike > -----Original Message----- > From: Christian Jansson [mailto:christian.jansson@hotsip.com]=20 > Sent: Monday, November 14, 2005 10:48 AM > To: Michael Hammer (mhammer); Paul Kyzivat (pkyzivat) > Cc: Sip > Subject: RE: [Sip] GRUU (was Whats wrong with Supported. >=20 >=20 >=20 > So, you think the solution I presented is not enough?=20 >=20 > The implementations that know they are broken can say so to=20 > speed up handling (optional to follow by server). The rest of=20 > the broken implementations will get a penalty when the server=20 > first tries to do the right thing before finally trying any=20 > dirty hacks. >=20 > I bet someone is going to say something like: "But what if I=20 > know that all my UAs are "broken". Then the server can do the=20 > hacks first to speed things up". My answer to that is that=20 > our goal is to standardize and optimize the correct way of=20 > doing things. People can do whatever crazy things they like=20 > and implement other solutions, but it won't be standard SIP.=20 > In this case I even presented a back-up solution that will=20 > work even for those who haven't done everything right. What=20 > more could they ask for?=20 >=20 > Instead, tell me why everybody, from now on, and forever,=20 > should pay the prize because some implementations choose to=20 > take a short-cut. > (SIP is already full of those kludges, lets not make another=20 > one if we can avoid it!) >=20 > / Christian Jansson >=20 >=20 >=20 >=20 > >Isn't this the equivalent of asking everyone not in the room=20 > to please=20 > >raise your hand? > > > >Mike > > > > > >> -----Original Message----- > >> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]=20 > On Behalf Of=20 > >> Christian Jansson > >> Sent: Friday, November 11, 2005 3:14 AM > >> To: Paul Kyzivat (pkyzivat) > >> Cc: Sip > >> Subject: RE: [Sip] GRUU (was Whats wrong with Supported. > >> > >> >I think there are practical difficulties with this. > >> > > >> >In a real deployment you would like the common case to be > >> that things > >> >work on the first try. If you usually have to try twice then you=20 > >> >effectively double the amount of signaling your network must > >> support, > >> >and increase the latency as well. > >> > > >> >Following your suggestion, if you deploy a "modern"=20 > (gruuful) proxy > >> with > >> >only gruuless UAs, you would have double the traffic you > >> would have if > >> >you had the proxy recognize "Supported:gruu". > >> > > >> > Paul > >> > >> But wouldn't it be better to let the broken things advertise that=20 > >> they do not follow the specification completely. Let the=20 > UAs that do=20 > >> not insert contact that is globally routable add a "Supported: > >> not-gruu-contact" if they do not want to have the penalty of the=20 > >> proxy trying twice. I think we should optimize the performance for=20 > >> those who do things right according to the spec, instead of having=20 > >> everybody adding more kludges to their messages. Of course=20 > we should=20 > >> also have a backwards compatible solution, but I think it is very=20 > >> important to have the additional cost paid by members with=20 > the broken=20 > >> implementations, > >> "Supported: not-gruu-contact" would be my simple suggestion. > >> > >> / Christian Jansson > >> > >> > >> > >> _______________________________________________ > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol Use=20 > >> sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >> sipping@ietf.org for new developments on the application of sip > >> >=20 _______________________________________________ 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 From sip-bounces@ietf.org Mon Nov 14 16:35:41 2005 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 1EblzJ-0007uK-I2; Mon, 14 Nov 2005 16:35:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EblzI-0007sn-18 for sip@megatron.ietf.org; Mon, 14 Nov 2005 16:35:40 -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 QAA02949 for ; Mon, 14 Nov 2005 16:35:07 -0500 (EST) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EbmGN-0007xU-Gx for sip@ietf.org; Mon, 14 Nov 2005 16:53:20 -0500 Received: from [192.168.2.101] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id jAELeo7C032109 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 14 Nov 2005 15:40:51 -0600 In-Reply-To: <000501c5e94b$a6f01ca0$2c28a8c0@brett1> References: <000501c5e94b$a6f01ca0$2c28a8c0@brett1> Mime-Version: 1.0 (Apple Message framework v746.2) X-Priority: 3 (Normal) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] WGLC for draft-ietf-sip-connect-reuse-04.txt Date: Mon, 14 Nov 2005 15:35:29 -0600 To: Brett Tate X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, 'Rohan Mahy' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Nov 14, 2005, at 12:45 PM, Brett Tate wrote: >> Let's start by putting Brett's three questions "on the plate" >> and noting that WGLC isn't over until they're resolved. >> >> >> See: >> >> http://www1.ietf.org/mail-archive/web/sip/current/msg12069.html >> http://www1.ietf.org/mail-archive/web/sip/current/msg12077.html >> http://www1.ietf.org/mail-archive/web/sip/current/msg12106.html >> > > The IETF 64 SIP agenda mentioned that the reuse draft was to be > discussed. > I wish that I could have attended. And I am anxiously awaiting the > preliminary minutes and slides. :) > > If the discussion included resolutions for the linked questions, would > someone please post (or send me) the answers to the questions. > Rough notes are already posted on the softarmor site. Connection reuse got deprecated from the agenda due to a flair-up of the higher-priority GRUU. Rohan recapped the status as follows: === From Scott's rough notes, Rohan Mahy - Connection Reuse Rohan has received a number of mutually conflicting suggestions on how to address problems. Since a quorum of those making the suggestions are not available here now, it will be taken to the list. Cullen Jennings - what is the timetable to resolve them? RM - will do work with the goal of completing it before the next IETF. === I also had several people ask if we still really need this draft. Do we? -- Dean _______________________________________________ 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 From sip-bounces@ietf.org Mon Nov 14 16:39:17 2005 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 1Ebm2n-0000Gw-5h; Mon, 14 Nov 2005 16:39:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebm2l-0000Gm-OZ for sip@megatron.ietf.org; Mon, 14 Nov 2005 16:39:15 -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 QAA03212 for ; Mon, 14 Nov 2005 16:38:43 -0500 (EST) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EbmJs-00086D-EZ for sip@ietf.org; Mon, 14 Nov 2005 16:56:56 -0500 Received: from [192.168.2.101] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id jAELicnj032132 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Mon, 14 Nov 2005 15:44:39 -0600 Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: 7bit Message-Id: <99524620-2437-48A8-9D22-F90C0DD1EA61@softarmor.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: Sip From: Dean Willis Date: Mon, 14 Nov 2005 15:39:17 -0600 X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Subject: [Sip] Slides and NOets posted X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org SIP working group meeting slides and notes (one set of slides missing at this moment) have been posted to the supplementary site at: http://www.softarmor.com/sipwg/meets/ietf64/index.html The slides are also on the IETF proceedings page, to which there is a link on the softarmor site. I'll get the one remaining set of slides posted when I get them. I'll also try and draft up some minutes and get them out fairly soon. -- Dean _______________________________________________ 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 From sip-bounces@ietf.org Wed Nov 16 03:58:02 2005 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 1EcJ7C-0005nj-OB; Wed, 16 Nov 2005 03:58:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcJ7A-0005nN-Ph for sip@megatron.ietf.org; Wed, 16 Nov 2005 03:58:00 -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 DAA10855 for ; Wed, 16 Nov 2005 03:57:28 -0500 (EST) Received: from mail1.hotsip.com ([62.119.82.23] helo=mail2.hotsip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcJOS-0000Z2-Js for sip@ietf.org; Wed, 16 Nov 2005 04:16:00 -0500 Received: from 62.119.82.41 [62.119.82.41] by mail2.hotsip.com with XWall v3.33 ; Wed, 16 Nov 2005 09:57:36 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: [Sip] GRUU (was Whats wrong with Supported. Date: Wed, 16 Nov 2005 09:57:34 +0100 Message-ID: Thread-Topic: [Sip] GRUU (was Whats wrong with Supported. thread-index: AcXmbnUxCtsjF2bHSTCucEViuDpCHQAJohEgAAtqXqAAm32IAAAHAN4gAE428vA= From: "Christian Jansson" To: "Michael Hammer (mhammer)" , "Paul Kyzivat (pkyzivat)" X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable Cc: Sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org >Could you explain the cost/benefit of some vendor to upgrade their >client just to say they don't support each new feature? As I said, people can do whatever they like, and if you do not like to upgrade your clients and servers, fine. The SIP WG is here to create and promote a working standard, from now on, and forever. My point was to optimize the behavior of the protocol for the ones that have, and for those who will, implement it in a correct way. I also presented the back-up plan of how broken implementations will work together with correct implementations. Your question seems to be "The vendor has a working system, with broken clients and broken servers, how should I explain why they should upgrade?)". My answer, don't fix it, if the system is working for the moment, but don't try to optimize the SIP standard for that scenario. > >That doesn't mean that the system can not progress, just that it needs >to determine if it is breaking a previous feature where backward >compatibility is worthwhile, or whether the previous feature was broken >to begin with and will remain broken until certain elements get with the >program. > >Mike This is not a discussion of some additional special feature, it is part of the core specification. As have been said before, the contact header should always have been globally routable. Otherwise we could end up with extension tags for everything that is actually in RFC-3261, just like I described in my first mail. Are you actually thinking that is a good idea? / Christian Jansson _______________________________________________ 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 From sip-bounces@ietf.org Wed Nov 16 06:25:09 2005 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 1EcLPZ-0000IV-7M; Wed, 16 Nov 2005 06:25:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebs3N-0004Wd-2C for sip@megatron.ietf.org; Mon, 14 Nov 2005 23:04:17 -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 XAA26297 for ; Mon, 14 Nov 2005 23:03:43 -0500 (EST) Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EbsKV-0004De-04 for sip@ietf.org; Mon, 14 Nov 2005 23:22:00 -0500 Received: from [131.161.248.90] (open-131-161-248-90.cliq.com [131.161.248.90]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id jAF441W15736; Mon, 14 Nov 2005 20:04:01 -0800 In-Reply-To: <000501c5e94b$a6f01ca0$2c28a8c0@brett1> References: <000501c5e94b$a6f01ca0$2c28a8c0@brett1> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6229a86f1c61f6664dbdf3091010c749@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Sip] WGLC for draft-ietf-sip-connect-reuse-04.txt Date: Mon, 14 Nov 2005 20:04:01 -0800 To: "Brett Tate" X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 16 Nov 2005 06:25:07 -0500 Cc: sip@ietf.org, Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi Brett, We didn't discuss connection reuse. Looking over the comments I received, we would need you and Jeroen to have a reasonable discussion, so I yielded the time so we could discuss GRUU. I'd like to schedule some time on the phone to talk about the connect reuse draft and how to fix it. thanks, -rohan On Nov 14, 2005, at 10:45, Brett Tate wrote: >> Let's start by putting Brett's three questions "on the plate" >> and noting that WGLC isn't over until they're resolved. >> >> >> See: >> >> http://www1.ietf.org/mail-archive/web/sip/current/msg12069.html >> http://www1.ietf.org/mail-archive/web/sip/current/msg12077.html >> http://www1.ietf.org/mail-archive/web/sip/current/msg12106.html >> > > The IETF 64 SIP agenda mentioned that the reuse draft was to be > discussed. > I wish that I could have attended. And I am anxiously awaiting the > preliminary minutes and slides. :) > > If the discussion included resolutions for the linked questions, would > someone please post (or send me) the answers to the questions. > > Thanks in advance, > Brett > _______________________________________________ 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 From sip-bounces@ietf.org Wed Nov 16 06:50:09 2005 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 1EcLnk-0005IU-Uh; Wed, 16 Nov 2005 06:50:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcLni-0005IK-QR for sip@megatron.ietf.org; Wed, 16 Nov 2005 06:50:07 -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 GAA19155 for ; Wed, 16 Nov 2005 06:49:32 -0500 (EST) Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcM53-00052E-2a for sip@ietf.org; Wed, 16 Nov 2005 07:08:07 -0500 Received: (qmail 31618 invoked by uid 0); 16 Nov 2005 11:49:40 -0000 Received: from unknown (HELO BEMBUSTER) ([81.59.101.130]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 16 Nov 2005 11:49:40 -0000 Message-ID: <009701c5eaa3$d2565810$6402a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "Rohan Mahy" , "Brett Tate" References: <000501c5e94b$a6f01ca0$2c28a8c0@brett1> <6229a86f1c61f6664dbdf3091010c749@ekabal.com> Subject: Re: [Sip] WGLC for draft-ietf-sip-connect-reuse-04.txt Date: Wed, 16 Nov 2005 12:49:37 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: 1.2 (+) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Just to share the 2 comments I sent: 1 - about the fact that TLS is a MUST > >Dean announced IETF LC for your draft on connection reuse, which reminded >me of a comment I had to share: >The draft states "SIP Proxy Servers which implement this mechanism MUST >implement TLS mutual authentication, and MUST follow the authorization >rules described in Section 4.1.1.". Basically this implies that a server >MUST ignore an alias parameter on a Via with a non-TLS transport. This >(intentionally I assume) limits the >applicability of the mechanism to >infrastructures with a PKI in place >I imagine that people will also want to use this for plain TCP, for the >performance benefit. The draft effectively disallows this. Would it be an >idea to specify that - in addition to the TLS mutual authentication, which >is RECOMMENDED - it is also possible to use the mechanism with TCP, >provided that the TCP connection comes from a trusted host? e.g. the proxy >maintains a list of trusted IP addresses, within a private network which >has some defence against spoofing. >In other words, I feel that "the connection sharing mechanism SHOULD work >for all connection-oriented transports" is also a requirement to consider. with a possible extension: 1) What if you allow alias if the request contains a challenge response that the server / proxy can verify to come from an authorised user? 2) Same with S/MIME bodies? 2 - about ephemereal ports in Via headers >I have a short question on >http://www.ietf.org/internet-drafts/draft-ietf-sip-connect-reuse-04.txt >section 4: >The given example is: >Assuming the Via header field value shown below from the most recent > request arrived over a connection from 10.54.32.1 port 8241: > Via: SIP/2.0/TLS 10.54.32.1:5061;branch=z9hG4bKa7c8dze ;alias>In this > scenario, my stack would have used '8241' as the port in the Via sent-by > value. >Is there something wrong with that?(Rohan's answer: Its actually > better to put the real port in sent-by, so you are doing nothing wrong. > Unfortunately a lot of SIP stacks don't/can't do this.) Jeroen ----- Original Message ----- From: "Rohan Mahy" To: "Brett Tate" Cc: ; "Rohan Mahy" Sent: Tuesday, November 15, 2005 5:04 AM Subject: Re: [Sip] WGLC for draft-ietf-sip-connect-reuse-04.txt > Hi Brett, > > We didn't discuss connection reuse. Looking over the comments I received, > we would need you and Jeroen to have a reasonable discussion, so I yielded > the time so we could discuss GRUU. I'd like to schedule some time on the > phone to talk about the connect reuse draft and how to fix it. > > thanks, > -rohan > > > On Nov 14, 2005, at 10:45, Brett Tate wrote: >>> Let's start by putting Brett's three questions "on the plate" >>> and noting that WGLC isn't over until they're resolved. >>> >>> >>> See: >>> >>> http://www1.ietf.org/mail-archive/web/sip/current/msg12069.html >>> http://www1.ietf.org/mail-archive/web/sip/current/msg12077.html >>> http://www1.ietf.org/mail-archive/web/sip/current/msg12106.html >>> >> >> The IETF 64 SIP agenda mentioned that the reuse draft was to be >> discussed. >> I wish that I could have attended. And I am anxiously awaiting the >> preliminary minutes and slides. :) >> >> If the discussion included resolutions for the linked questions, would >> someone please post (or send me) the answers to the questions. >> >> Thanks in advance, >> Brett >> > > > _______________________________________________ > 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 From sip-bounces@ietf.org Wed Nov 16 09:17:24 2005 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 1EcO6G-0006bZ-Co; Wed, 16 Nov 2005 09:17:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcO6E-0006bU-Fe for sip@megatron.ietf.org; Wed, 16 Nov 2005 09:17:22 -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 JAA28917 for ; Wed, 16 Nov 2005 09:16:49 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcONg-0001OO-HQ for sip@ietf.org; Wed, 16 Nov 2005 09:35:24 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 16 Nov 2005 06:17:13 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,337,1125903600"; d="scan'208"; a="15298996:sNHT23392020" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jAGEEv7W000469; Wed, 16 Nov 2005 09:17:10 -0500 (EST) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 16 Nov 2005 09:17:06 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] GRUU (was Whats wrong with Supported. Date: Wed, 16 Nov 2005 09:17:05 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3C6FB61@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Sip] GRUU (was Whats wrong with Supported. Thread-Index: AcXmbnUxCtsjF2bHSTCucEViuDpCHQAJohEgAAtqXqAAm32IAAAHAN4gAE428vAADIeaMA== From: "Michael Hammer \(mhammer\)" To: "Christian Jansson" , "Paul Kyzivat \(pkyzivat\)" X-OriginalArrivalTime: 16 Nov 2005 14:17:06.0433 (UTC) FILETIME=[6C73AF10:01C5EAB8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: quoted-printable Cc: Sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org You keep trying to extrapolate from a very simple comment to some other undesirable design. If that leads to uneasiness on your part then don't do it. I meant only to say that it is not worthwhile to waste time inventing a protocol element that would likely never get used. =20 Nothing more. Mike=20 > -----Original Message----- > From: Christian Jansson [mailto:christian.jansson@hotsip.com]=20 > Sent: Wednesday, November 16, 2005 3:58 AM > To: Michael Hammer (mhammer); Paul Kyzivat (pkyzivat) > Cc: Sip > Subject: RE: [Sip] GRUU (was Whats wrong with Supported. >=20 >=20 >=20 > >Could you explain the cost/benefit of some vendor to upgrade their=20 > >client just to say they don't support each new feature? >=20 > As I said, people can do whatever they like, and if you do=20 > not like to upgrade your clients and servers, fine. The SIP=20 > WG is here to create and promote a working standard, from now=20 > on, and forever. My point was to optimize the behavior of the=20 > protocol for the ones that have, and for those who will,=20 > implement it in a correct way. I also presented the back-up=20 > plan of how broken implementations will work together with=20 > correct implementations. Your question seems to be "The=20 > vendor has a working system, with broken clients and broken=20 > servers, how should I explain why they should upgrade?)". My=20 > answer, don't fix it, if the system is working for the=20 > moment, but don't try to optimize the SIP standard for that scenario. >=20 > > > >That doesn't mean that the system can not progress, just=20 > that it needs=20 > >to determine if it is breaking a previous feature where backward=20 > >compatibility is worthwhile, or whether the previous feature=20 > was broken=20 > >to begin with and will remain broken until certain elements get with > the > >program. > > > >Mike >=20 >=20 > This is not a discussion of some additional special feature,=20 > it is part of the core specification. As have been said=20 > before, the contact header should always have been globally=20 > routable. Otherwise we could end up with extension tags for=20 > everything that is actually in RFC-3261, just like I=20 > described in my first mail. Are you actually thinking that is=20 > a good idea? >=20 > / Christian Jansson >=20 _______________________________________________ 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 From sip-bounces@ietf.org Wed Nov 16 09:45:48 2005 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 1EcOXk-000765-4q; Wed, 16 Nov 2005 09:45:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcOXi-00075V-Ht for sip@megatron.ietf.org; Wed, 16 Nov 2005 09:45:46 -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 JAA01247 for ; Wed, 16 Nov 2005 09:45:13 -0500 (EST) Received: from mail1.hotsip.com ([62.119.82.23] helo=mail2.hotsip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcOp4-0002PZ-9R for sip@ietf.org; Wed, 16 Nov 2005 10:03:48 -0500 Received: from 62.119.82.41 [62.119.82.41] by mail2.hotsip.com with XWall v3.33 ; Wed, 16 Nov 2005 15:45:22 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: [Sip] GRUU (was Whats wrong with Supported. Date: Wed, 16 Nov 2005 15:45:20 +0100 Message-ID: Thread-Topic: [Sip] GRUU (was Whats wrong with Supported. thread-index: AcXmbnUxCtsjF2bHSTCucEViuDpCHQAJohEgAAtqXqAAm32IAAAHAN4gAE428vAADIeaMAABGP9A From: "Christian Jansson" To: "Michael Hammer (mhammer)" , "Paul Kyzivat (pkyzivat)" X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: quoted-printable Cc: Sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org >You keep trying to extrapolate from a very simple comment to some other >undesirable design. If that leads to uneasiness on your part then don't >do it. I meant only to say that it is not worthwhile to waste time >inventing a protocol element that would likely never get used. > >Nothing more. > >Mike Oops, sorry I misinterpreted what you said. / Christian _______________________________________________ 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 From sip-bounces@ietf.org Wed Nov 16 09:52:46 2005 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 1EcOeU-0000XS-5J; Wed, 16 Nov 2005 09:52:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcOeQ-0000SL-Ly for sip@megatron.ietf.org; Wed, 16 Nov 2005 09:52:44 -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 JAA01678 for ; Wed, 16 Nov 2005 09:52:09 -0500 (EST) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcOvr-0002de-NV for sip@ietf.org; Wed, 16 Nov 2005 10:10:45 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id jAGEqNcv023993; Wed, 16 Nov 2005 08:52:23 -0600 (CST) Received: from [135.185.173.147] (il0015vkg1.ih.lucent.com [135.185.173.147]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id jAGEqNw04631; Wed, 16 Nov 2005 08:52:23 -0600 (CST) Message-ID: <437B47A7.1020204@lucent.com> Date: Wed, 16 Nov 2005 08:52:23 -0600 From: "Vijay K. Gurbani" Organization: Wireless Networks Research and Development User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rohan Mahy Subject: Re: [Sip] WGLC for draft-ietf-sip-connect-reuse-04.txt References: <000501c5e94b$a6f01ca0$2c28a8c0@brett1> <6229a86f1c61f6664dbdf3091010c749@ekabal.com> In-Reply-To: <6229a86f1c61f6664dbdf3091010c749@ekabal.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 36fb765c89ed47dab364ab702a78e8fd Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1880040585==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1880040585== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000307020100070204060808" This is a cryptographically signed message in MIME format. --------------ms000307020100070204060808 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Rohan Mahy wrote: > Hi Brett, > > We didn't discuss connection reuse. Looking over the comments I > received, we would need you and Jeroen to have a reasonable discussion, > so I yielded the time so we could discuss GRUU. I'd like to schedule > some time on the phone to talk about the connect reuse draft and how to > fix it. Rohan: Conference me in on the phone call as well. I had posted some comments on connect-reuse (see http://www1.ietf.org/mail-archive/web/sip/current/msg12373.html). I am more interested in your thoughts on the interaction of "alias" and DNS discussed in that email. Thanks, - vijay -- Vijay K. Gurbani, Ph.D. vkg@{lucent.com,research.bell-labs.com,acm.org} Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 --------------ms000307020100070204060808 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIkNjCC CZowggiCoAMCAQICChq5SpYAAAAABscwDQYJKoZIhvcNAQEFBQAwgbIxJTAjBgkqhkiG9w0B CQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5jb20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcg SmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkgSGlsbDEcMBoGA1UEChMTTHVjZW50IFRlY2hub2xv Z2llczEzMDEGA1UEAxMqTHVjZW50IFRlY2hub2xvZ2llcyBDZXJ0aWZpY2F0ZSBTZXJ2aWNl cyAxMB4XDTA0MDYyMzIwMDM0MVoXDTA2MDYyMzIwMTM0MVowQTEdMBsGCSqGSIb3DQEJARYO dmtnQGx1Y2VudC5jb20xIDAeBgNVBAMTF1ZpamF5IEsgR3VyYmFuaSAoVmlqYXkpMIGfMA0G CSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8/1oQRIU0sF4rsiC0F6mQu6TSvQPCRl6BObQcR58a 5swju1dVwTz3XbON9p5qjYRqxm9d+OX7W2Bj68dxlYUTz5yp9KkwH7hNLVTy09E3dwdZM36L +7ICKUK9M6YU64MJAGTg1tTxUIxflKy0SMCPJIldiEp/JrXYb2aVhmW8tQIDAQABo4IGpDCC BqAwHQYDVR0OBBYEFFG9/4w6CpUIC+mXdQWpWuBH+nkbMIH+BgNVHSMEgfYwgfOAFISfQVWc EIhPO03ThDp+IUtPSt/LoYHOpIHLMIHIMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5s dWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxML TXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxHDAaBgNVBAsTE0x1 Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1Y2VudCBUZWNobm9sb2dpZXMgUm9vdCBB dXRob3JpdHmCCmEMFx0AAAAAAAUwEwYKCZImiZPyLGQBAQQFFgN2a2cwFwYKCZImiZPyLGQB LAQJFgczNzA5NDM4MBEGCWCGSAGG+EIBAQQEAwIFoDALBgNVHQ8EBAMCA/gwJwYDVR0lBCAw HgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDBzCCAncGCCsGAQUFBwEBBIICaTCCAmUw gc4GCCsGAQUFBzAChoHBbGRhcDovL2xkYXAtdXNlYXN0LnBvc3QubHVjZW50LmNvbS9jbj1M dWNlbnQlMjBUZWNobm9sb2dpZXMlMjBDZXJ0aWZpY2F0ZSUyMFNlcnZpY2VzJTIwMSxvdT1D ZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NhY2VydGlmaWNhdGU7 YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBwgYIKwYB BQUHMAKGgbVsZGFwOi8vbGRhcC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2ll cyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRo b3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3Rj bGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHMBggrBgEFBQcwAoaBv2xkYXA6Ly9sZGFw LWVtZWEucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRp ZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxv PWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0 aWZpY2F0aW9uQXV0aG9yaXR5MIICigYDVR0fBIICgTCCAn0wgdaggdOggdCGgc1sZGFwOi8v bGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUy MENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3Jp dGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFz ZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHKoIHHoIHEhoHBbGRhcDov L2xkYXAubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBDZXJ0aWZpY2F0 ZSUyMFNlcnZpY2VzJTIwMSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNl bnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xh c3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCB1KCB0aCBzoaBy2xkYXA6Ly9sZGFwLWVtZWEu cG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRl JTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2Vu dC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZT9vYmplY3RjbGFz cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MA0GCSqGSIb3DQEBBQUAA4IBAQBZ1m98/KuOGemr fAEgtDWIiZjKEN3ShsKT3bfKvjw/zSOtL2UpwNab9xqHKdV9rt4O0wzx6By/0JY/hCQrPMAm YCO0Xo14fC8OSzRkRl1kSPn0E+v8vD+dn42a+dBdmN2SD56jg7/EkvifgaCw9n/HMi4vXcOS +RUdxZkPRnYLyh4GiocnBx88IQEzWK9shMLzC7gm3K6V6kggUSchxR703OHNTLb7XKeEDzSX LdXMVHA5N89xTQGyVWk8Mc6fO7icn0LthC81Ig0/M6v12Vmb2+Tdq7aB7ZVgaU95f/eezcHh LgaYlutde9q6s+c8ok8/hI2VBcGMt85Apf5GAktoMIIJmjCCCIKgAwIBAgIKGrlKlgAAAAAG xzANBgkqhkiG9w0BAQUFADCBsjElMCMGCSqGSIb3DQEJARYWY2FAc2VjdXJpdHkubHVjZW50 LmNvbTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC011cnJh eSBIaWxsMRwwGgYDVQQKExNMdWNlbnQgVGVjaG5vbG9naWVzMTMwMQYDVQQDEypMdWNlbnQg VGVjaG5vbG9naWVzIENlcnRpZmljYXRlIFNlcnZpY2VzIDEwHhcNMDQwNjIzMjAwMzQxWhcN MDYwNjIzMjAxMzQxWjBBMR0wGwYJKoZIhvcNAQkBFg52a2dAbHVjZW50LmNvbTEgMB4GA1UE AxMXVmlqYXkgSyBHdXJiYW5pIChWaWpheSkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB ALz/WhBEhTSwXiuyILQXqZC7pNK9A8JGXoE5tBxHnxrmzCO7V1XBPPdds432nmqNhGrGb134 5ftbYGPrx3GVhRPPnKn0qTAfuE0tVPLT0Td3B1kzfov7sgIpQr0zphTrgwkAZODW1PFQjF+U rLRIwI8kiV2ISn8mtdhvZpWGZby1AgMBAAGjggakMIIGoDAdBgNVHQ4EFgQUUb3/jDoKlQgL 6Zd1Bala4Ef6eRswgf4GA1UdIwSB9jCB84AUhJ9BVZwQiE87TdOEOn4hS09K38uhgc6kgcsw gcgxJTAjBgkqhkiG9w0BCQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5jb20xCzAJBgNVBAYTAlVT MRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkgSGlsbDEcMBoGA1UEChMT THVjZW50IFRlY2hub2xvZ2llczEcMBoGA1UECxMTTHVjZW50IFRlY2hub2xvZ2llczErMCkG A1UEAxMiTHVjZW50IFRlY2hub2xvZ2llcyBSb290IEF1dGhvcml0eYIKYQwXHQAAAAAABTAT BgoJkiaJk/IsZAEBBAUWA3ZrZzAXBgoJkiaJk/IsZAEsBAkWBzM3MDk0MzgwEQYJYIZIAYb4 QgEBBAQDAgWgMAsGA1UdDwQEAwID+DAnBgNVHSUEIDAeBggrBgEFBQcDAgYIKwYBBQUHAwQG CCsGAQUFBwMHMIICdwYIKwYBBQUHAQEEggJpMIICZTCBzgYIKwYBBQUHMAKGgcFsZGFwOi8v bGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUy MENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3Jp dGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFz cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHCBggrBgEFBQcwAoaBtWxkYXA6Ly9sZGFwLmx1 Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2 aWNlcyUyMDEsb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9j YWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRo b3JpdHkwgcwGCCsGAQUFBzAChoG/bGRhcDovL2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20v Y249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEs b3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmlj YXRlO2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwggKK BgNVHR8EggKBMIICfTCB1qCB06CB0IaBzWxkYXA6Ly9sZGFwLXVzZWFzdC5wb3N0Lmx1Y2Vu dC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNl cyUyMDEsb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0 aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmlj YXRpb25BdXRob3JpdHkwgcqggceggcSGgcFsZGFwOi8vbGRhcC5sdWNlbnQuY29tL2NuPUx1 Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNl cnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZv Y2F0aW9ubGlzdDtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9y aXR5MIHUoIHRoIHOhoHLbGRhcDovL2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVj ZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEsb3U9Q2Vy dGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9j YXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3Jp dHkwDQYJKoZIhvcNAQEFBQADggEBAFnWb3z8q44Z6at8ASC0NYiJmMoQ3dKGwpPdt8q+PD/N I60vZSnA1pv3Gocp1X2u3g7TDPHoHL/Qlj+EJCs8wCZgI7RejXh8Lw5LNGRGXWRI+fQT6/y8 P52fjZr50F2Y3ZIPnqODv8SS+J+BoLD2f8cyLi9dw5L5FR3FmQ9GdgvKHgaKhycHHzwhATNY r2yEwvMLuCbcrpXqSCBRJyHFHvTc4c1Mtvtcp4QPNJct1cxUcDk3z3FNAbJVaTwxzp87uJyf Qu2ELzUiDT8zq/XZWZvb5N2rtoHtlWBpT3l/957NweEuBpiW61172rqz5zyiTz+EjZUFwYy3 zkCl/kYCS2gwghD2MIIP3qADAgECAgphDBcdAAAAAAAFMA0GCSqGSIb3DQEBBQUAMIHIMSUw IwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEG A1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2Vu dCBUZWNobm9sb2dpZXMxHDAaBgNVBAsTE0x1Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMT Ikx1Y2VudCBUZWNobm9sb2dpZXMgUm9vdCBBdXRob3JpdHkwHhcNMDAxMjA2MTYyNjQ1WhcN MTAxMjA2MTYzNjQ1WjCBsjElMCMGCSqGSIb3DQEJARYWY2FAc2VjdXJpdHkubHVjZW50LmNv bTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC011cnJheSBI aWxsMRwwGgYDVQQKExNMdWNlbnQgVGVjaG5vbG9naWVzMTMwMQYDVQQDEypMdWNlbnQgVGVj aG5vbG9naWVzIENlcnRpZmljYXRlIFNlcnZpY2VzIDEwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCrbIc03eHms6QdVIh5h01zu8+SHMLFNRPuo3EVY8dgvQsy1pM5DSOtjDt+ JXW723615PF8cVgDVUQGE4D9T9k5B2DP3DUhtrsvH3SEKJL6NceqgWDhLzgf0JjhNdid9IHE x5xRWAiONeeLiRcScIZyRgANiokhSaM5VM2tZBctDFWrXkqxRUHvSSlWXMoXh7HYBOfEjhfJ E3BGQTOX0HOFKkCNS3CDh7ZAwNnw4Ntgkf+8bOqAzmX1ToyZbFLn7bZ9rNFg3gcDzyoFD46C ZQsibysVefigRA57WfouqpbgZ8JzIAmXAeaJLSRgutALT5beOyx75TNPdglVhKlHg4MLAgMB AAGjggz0MIIM8DAQBgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUhJ9BVZwQiE87TdOEOn4h S09K38swCwYDVR0PBAQDAgHGMA8GA1UdEwEB/wQFMAMBAf8wggEEBgNVHSMEgfwwgfmAFG/h K1C+quh9NWJpDO7LUuiSAjxdoYHOpIHLMIHIMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0 eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UE BxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxHDAaBgNVBAsT E0x1Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1Y2VudCBUZWNobm9sb2dpZXMgUm9v dCBBdXRob3JpdHmCEFmZihipVMC2QAXNTB3ruM8wggXfBgNVHR8EggXWMIIF0jCBzKCByaCB xoaBw2xkYXA6Ly9sZGFwLXVzZWFzdC5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVj aG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9y aXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jh c2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBzKCByaCBxoaBw2xkYXA6 Ly9sZGFwLXVzd2VzdC5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVz JTIwUm9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1s dWNlbnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0 Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCByaCBxqCBw4aBwGxkYXA6Ly9sZGFwLmV4 dGVybmFsLmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1 dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2Nl cnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlm aWNhdGlvbkF1dGhvcml0eTCBz6CBzKCByYaBxmxkYXA6Ly9sZGFwLXVzY2VudHJhbC5wb3N0 Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0 eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmlj YXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlv bkF1dGhvcml0eTCByqCBx6CBxIaBwWxkYXA6Ly9sZGFwLWVtZWEucG9zdC5sdWNlbnQuY29t L2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlm aWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRp b25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkw gcqggceggcSGgcFsZGFwOi8vbGRhcC1jYWxhLnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQl MjBUZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBB dXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5h cnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHIoIHFoIHChoG/ bGRhcDovL2xkYXAtYXAucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2ll cyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89 bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVj dGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwL6AtoCuGKWh0dHA6Ly93d3cuc2VjdXJp dHkubHVjZW50LmNvbS9jYS9jYTEuY3JsMIIFsgYIKwYBBQUHAQEEggWkMIIFoDCBxAYIKwYB BQUHMAKGgbdsZGFwOi8vbGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUy MFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1 dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVj dGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcQGCCsGAQUFBzAChoG3bGRhcDovL2xk YXAtdXN3ZXN0LnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBS b290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2Vu dC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0 aW9uQXV0aG9yaXR5MIHBBggrBgEFBQcwAoaBtGxkYXA6Ly9sZGFwLmV4dGVybmFsLmx1Y2Vu dC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1D ZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NhY2VydGlmaWNhdGU7 YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBxwYIKwYB BQUHMAKGgbpsZGFwOi8vbGRhcC11c2NlbnRyYWwucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2Vu dCUyMFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUy MEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29i amVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcIGCCsGAQUFBzAChoG1bGRhcDov L2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIw Um9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNl bnQuY29tP2NhY2VydGlmaWNhdGU7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNh dGlvbkF1dGhvcml0eTCBwgYIKwYBBQUHMAKGgbVsZGFwOi8vbGRhcC1jYWxhLnBvc3QubHVj ZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91 PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0 ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHABggr BgEFBQcwAoaBs2xkYXA6Ly9sZGFwLWFwLnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBU ZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRo b3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3Rj bGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MDUGCCsGAQUFBzAChilodHRwOi8vd3d3LnNl Y3VyaXR5Lmx1Y2VudC5jb20vY2EvY2ExLmNydDANBgkqhkiG9w0BAQUFAAOCAQEAObP5Urds B2nOxTrekCTXpBxKF4K0t8Doi/zHhUuupK+Bc5ppNu9dqYeGr1bKNLRbF/hccvzn4xuj3o82 gm7eZee7lssn9e6T/AjmHca+pCG9n5wZNgY6S0AJryUk6/hfyWc/7z1HfFHrkMM2zn9kqm13 h4tgCPG3WS86+WE4PO12sjAi0GYc43CszaxuU0GZoZ3cfapl5AzC8pMLltGyu/DqJLBk/biR Zr61dWmQWajF/dKhwrAtDiGc0PYZykl/Dg1mYD+eadv5qSKUdTuoa8idlief/sWnUUWbGkYb 1QUPqg8/g9UQcvBx+dgrnsf11X6GHq9gI+LKDBNLyWdEvTGCA8kwggPFAgEBMIHBMIGyMSUw IwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEG A1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2Vu dCBUZWNobm9sb2dpZXMxMzAxBgNVBAMTKkx1Y2VudCBUZWNobm9sb2dpZXMgQ2VydGlmaWNh dGUgU2VydmljZXMgMQIKGrlKlgAAAAAGxzAJBgUrDgMCGgUAoIICXTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNTExMTYxNDUyMjNaMCMGCSqGSIb3DQEJ BDEWBBSD8idNhes78CFRIa7Szl/iwphIzTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIB KDCB0gYJKwYBBAGCNxAEMYHEMIHBMIGyMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5s dWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxML TXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxMzAxBgNVBAMTKkx1 Y2VudCBUZWNobm9sb2dpZXMgQ2VydGlmaWNhdGUgU2VydmljZXMgMQIKGrlKlgAAAAAGxzCB 1AYLKoZIhvcNAQkQAgsxgcSggcEwgbIxJTAjBgkqhkiG9w0BCQEWFmNhQHNlY3VyaXR5Lmx1 Y2VudC5jb20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtN dXJyYXkgSGlsbDEcMBoGA1UEChMTTHVjZW50IFRlY2hub2xvZ2llczEzMDEGA1UEAxMqTHVj ZW50IFRlY2hub2xvZ2llcyBDZXJ0aWZpY2F0ZSBTZXJ2aWNlcyAxAgoauUqWAAAAAAbHMA0G CSqGSIb3DQEBAQUABIGAevrM4xEdjJ/jkq8mJSyUSbV7lXsfUl3T+Ny6QkaAG8w7ue8QvRvf o9qFd6rxEq1xqEHldLwNTNPgdpWXCbmppGbcQf24dNY5eJzAIoG5fjqb73rzNOMD/7zkkr7E QRaSXiIg/kb/4YUbLd3QwQnzm4l1UwHiAVsdnbBewYdytQsAAAAAAAA= --------------ms000307020100070204060808-- --===============1880040585== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1880040585==-- From sip-bounces@ietf.org Wed Nov 16 11:22:16 2005 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 1EcQ36-0001tS-Ep; Wed, 16 Nov 2005 11:22:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcQ34-0001tI-0p for sip@megatron.ietf.org; Wed, 16 Nov 2005 11:22:14 -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 LAA07434 for ; Wed, 16 Nov 2005 11:21:40 -0500 (EST) Message-Id: <200511161621.LAA07434@ietf.org> Received: from smtp102.biz.mail.re2.yahoo.com ([68.142.229.216]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EcQKV-0007Hm-OA for sip@ietf.org; Wed, 16 Nov 2005 11:40:17 -0500 Received: (qmail 31277 invoked from network); 16 Nov 2005 16:21:51 -0000 Received: from unknown (HELO IBM8910DAD9647) (david@kayote.com@212.25.94.33 with login) by smtp102.biz.mail.re2.yahoo.com with SMTP; 16 Nov 2005 16:21:49 -0000 From: "David Schwartz" To: "'Otmar Lendl'" , "David Schwartz" , , , Date: Wed, 16 Nov 2005 18:21:46 +0200 Organization: Kayote Networks MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 thread-index: AcXpOzYaCaw+fVSoQMyhSU9+TEc/EABiE/Tg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <20051114164814.GL18495@nic.at> X-Spam-Score: 0.3 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, sipping@ietf.org Subject: [Sip] RE: Comment on draft-schwartz-sipping-spit-saml-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: david@kayote.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi Otmar. First of all I believe the correct place is in SIP and not SIPPING. As for the comments... I tried to stay away from floating point values for performance reasons. My question is, why would you need to insert a value BETWEEN other values? Why not just add a new higher value? Are you referring to cases where the new value is a subset of another value?. Can you think of an example? As for proposal to use 40,50, etc., I usually try to stay away from solutions that make things "a little better". If indeed there is a need for values between existing values than using 40,50, etc. is not a real solution since it only makes things a little better. As for your comment on the complexity of the example I agree. I was focusing more on which attributes to use and less on the actual syntax. I took this example from many others such examples on the web. If I did do this, though, the xmlns would have to be the Trusted Anchor and not the originating MI as these newly defined attributes need to be agreed on by all participants of the federation and not just the two MI's in question. I hope to release an updated version with this and a few other changes shortly so if you have any other input feel free to respond. Thanks, David -----Original Message----- From: Otmar Lendl [mailto:lendl@nic.at] Sent: Monday, November 14, 2005 6:48 PM To: david.schwartz@kayote.com; baruch.sterman@kayote.com; eli.katz@xconnect.net; Hannes.Tschofenig@siemens.com Subject: Comment on draft-schwartz-sipping-spit-saml-00 Hello, as I'm not sure whether this draft is supposed to be discussed in sip or sipping, I'm writing directly to you: After a quick reading of draft-schwartz-sipping-spit-saml-00 I'm wondering: * e.g. 5.1.1: The numerical values maybe fine to denote the strength levels you have in mind now, but they do not offer any space for adding new notions which lie between current values. I'd recommend you change the values from 0,1,2,3,4 to 0,10,20,30,40 to accomodate future enhancements. * The XML (SAML) framents look overly complex: I haven't read the SAML spec itself, but the example 2 looks overly contorted. Why not the following? 2 cheers, /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ 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 From sip-bounces@ietf.org Wed Nov 16 13:38:00 2005 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 1EcSAS-0001eZ-II; Wed, 16 Nov 2005 13:38:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcSAQ-0001eU-HI for sip@megatron.ietf.org; Wed, 16 Nov 2005 13:37:58 -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 NAA16054 for ; Wed, 16 Nov 2005 13:37:24 -0500 (EST) Received: from bdsoft10.vwh.net ([130.94.149.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcSRt-0003nB-V2 for sip@ietf.org; Wed, 16 Nov 2005 13:56:03 -0500 Received: from brett1 (ip67-88-7-2.z7-88-67.customer.algx.net [67.88.7.2]) (authenticated bits=0) by bdsoft10.vwh.net (8.13.1/8.12.11) with ESMTP id jAGIbUtZ089936 for ; Wed, 16 Nov 2005 13:37:34 -0500 (EST) From: "Brett Tate" To: "sip-ietf" Date: Wed, 16 Nov 2005 13:37:59 -0500 Message-ID: <000d01c5eadc$de84b170$2c28a8c0@brett1> 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.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal X-PMX-IsInternal: True X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Subject: [Sip] RFC 3261 supported header in 1xx responses X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Within early versions of draft-ietf-sip-rfc2543bis, the Supported header could be expected within 1xx responses. However within draft-ietf-sip-rfc2543bis-06 it was removed and remains so within RFC 3261. Is there a reason why it is undesirable to indicate supported extensions within a 1xx? Or was it just an oversight when changing the "Summary of header fields" table to indicate 2xx instead of all responses? _______________________________________________ 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 From sip-bounces@ietf.org Wed Nov 16 15:46:35 2005 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 1EcUAt-0002oe-Gv; Wed, 16 Nov 2005 15:46:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcUAr-0002oZ-Vx for sip@megatron.ietf.org; Wed, 16 Nov 2005 15:46:34 -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 PAA23198 for ; Wed, 16 Nov 2005 15:46:01 -0500 (EST) Received: from bdsoft10.vwh.net ([130.94.149.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcUSM-0008LZ-GK for sip@ietf.org; Wed, 16 Nov 2005 16:04:39 -0500 Received: from brett1 (ip67-88-7-2.z7-88-67.customer.algx.net [67.88.7.2]) (authenticated bits=0) by bdsoft10.vwh.net (8.13.1/8.12.11) with ESMTP id jAGKkOR0099492; Wed, 16 Nov 2005 15:46:28 -0500 (EST) From: "Brett Tate" To: "'Vijay K. Gurbani'" , "'Rohan Mahy'" Subject: RE: [Sip] WGLC for draft-ietf-sip-connect-reuse-04.txt Date: Wed, 16 Nov 2005 15:46:53 -0500 Message-ID: <001601c5eaee$e0ce9c40$2c28a8c0@brett1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal In-Reply-To: <436BEA14.8010302@lucent.com> X-PMX-IsInternal: True X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > 2) In Section 4, where the interaction of DNS and "alias"=20 > is described, I believe that the use of "alias" leads to=20 > starvation of other servers in a proxy farm since we have=20 > established an affinity with a particular server. =20 > Let me explain. >=20 > If within the Priority field of SRV RRs, the Weight fields=20 > are the same (as is the example), then there will arise a=20 > situation where the "alias" parameter will lead to the=20 > starvation of other servers in a proxy farm. Under normal=20 > circumstances, since the Weight field of the SRV RRs is the=20 > same, traffic should be distributed equally. If instead,=20 > because of the "alias" parameter, we do not use SRV, then=20 > only one host from the proxy farm gets bombasted with *all*=20 > the traffic, effectively inhibiting load distribution=20 > through SRV. >=20 > Do you see this as a problem? My current understanding/assumption is that the sender would loadbalance across the opened connections for the alias. Thus each cluster member = could establish a connection and keep it open to remain one of the choices for = the alias. However it is definitely a problem when SRV would have indicated different priority levels (or weights). I think that this problem (and many of the questions I posted in prior emails) arise from section 3 requirement 2. Is requirement 2 really a mandatory requirement for the reuse draft? If not, requirement 2 potentially could be removed and placed into a separate draft. The draft could provide a more complete solution = concerning how to overlay the benefits of SRV priority and weights with the desired number of connections between 2 devices, between a device and cluster, = and between 2 clusters. It potentially could also define a mechanism to = know when to skip even trying to open a new connection towards a particular device or cluster. _______________________________________________ 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 From sip-bounces@ietf.org Wed Nov 16 16:06:27 2005 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 1EcUU7-0001Pj-TH; Wed, 16 Nov 2005 16:06:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcUU5-0001PD-PQ for sip@megatron.ietf.org; Wed, 16 Nov 2005 16:06:26 -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 QAA27359 for ; Wed, 16 Nov 2005 16:05:52 -0500 (EST) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcUla-0001fu-6w for sip@ietf.org; Wed, 16 Nov 2005 16:24:31 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id jAGL64SV007771; Wed, 16 Nov 2005 15:06:04 -0600 (CST) Received: from [135.185.173.147] (il0015vkg1.ih.lucent.com [135.185.173.147]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id jAGL63w19156; Wed, 16 Nov 2005 15:06:03 -0600 (CST) Message-ID: <437B9F3B.8010107@lucent.com> Date: Wed, 16 Nov 2005 15:06:03 -0600 From: "Vijay K. Gurbani" Organization: Wireless Networks Research and Development User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brett Tate Subject: Re: [Sip] WGLC for draft-ietf-sip-connect-reuse-04.txt References: <001601c5eaee$e0ce9c40$2c28a8c0@brett1> In-Reply-To: <001601c5eaee$e0ce9c40$2c28a8c0@brett1> X-Spam-Score: 0.0 (/) X-Scan-Signature: 3f3e54d3c03ed638c06aa9fa6861237e Cc: sip@ietf.org, 'Rohan Mahy' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0132625404==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0132625404== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020803050603020305090908" This is a cryptographically signed message in MIME format. --------------ms020803050603020305090908 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Brett Tate wrote: > My current understanding/assumption is that the sender would > loadbalance across the opened connections for the alias. Thus each > cluster member could establish a connection and keep it open to > remain one of the choices for the alias. Over time, this will cause an aliased connection to be established across all servers in a cluster. The disadvantage is that this forces the sender talking to the cluster to keep multiple connections open, thereby defeating the purpose having a single connection. However, this is one way to solve it. If we agree, then we ought to mention this in the draft. > However it is definitely a problem when SRV would have indicated > different priority levels (or weights). Yes, different priority levels are a problem anyway ... but I think that the problem even occurs across the same priority level as I indicated. The solution for different priority/ weights would essentially be the same, namely open multiple connections. > I think that this problem (and many of the questions I posted in > prior emails) arise from section 3 requirement 2. Is requirement 2 > really a mandatory requirement for the reuse draft? Hmmm ... interesting. Maybe something to discuss during the phone call. Rohan, Brett, Jeroene: I can get a bridge if that will help. We can have a private email exchange to work out the time and other logistics. > If not, requirement 2 potentially could be removed and placed into a > separate draft. The draft could provide a more complete solution > concerning how to overlay the benefits of SRV priority and weights > with the desired number of connections between 2 devices, between a > device and cluster, and between 2 clusters. It potentially could > also define a mechanism to know when to skip even trying to open a > new connection towards a particular device or cluster. Thanks, - vijay -- Vijay K. Gurbani, Ph.D. vkg@{lucent.com,research.bell-labs.com,acm.org} Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 --------------ms020803050603020305090908 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIkNjCC CZowggiCoAMCAQICChq5SpYAAAAABscwDQYJKoZIhvcNAQEFBQAwgbIxJTAjBgkqhkiG9w0B CQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5jb20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcg SmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkgSGlsbDEcMBoGA1UEChMTTHVjZW50IFRlY2hub2xv Z2llczEzMDEGA1UEAxMqTHVjZW50IFRlY2hub2xvZ2llcyBDZXJ0aWZpY2F0ZSBTZXJ2aWNl cyAxMB4XDTA0MDYyMzIwMDM0MVoXDTA2MDYyMzIwMTM0MVowQTEdMBsGCSqGSIb3DQEJARYO dmtnQGx1Y2VudC5jb20xIDAeBgNVBAMTF1ZpamF5IEsgR3VyYmFuaSAoVmlqYXkpMIGfMA0G CSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8/1oQRIU0sF4rsiC0F6mQu6TSvQPCRl6BObQcR58a 5swju1dVwTz3XbON9p5qjYRqxm9d+OX7W2Bj68dxlYUTz5yp9KkwH7hNLVTy09E3dwdZM36L +7ICKUK9M6YU64MJAGTg1tTxUIxflKy0SMCPJIldiEp/JrXYb2aVhmW8tQIDAQABo4IGpDCC BqAwHQYDVR0OBBYEFFG9/4w6CpUIC+mXdQWpWuBH+nkbMIH+BgNVHSMEgfYwgfOAFISfQVWc EIhPO03ThDp+IUtPSt/LoYHOpIHLMIHIMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5s dWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxML TXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxHDAaBgNVBAsTE0x1 Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1Y2VudCBUZWNobm9sb2dpZXMgUm9vdCBB dXRob3JpdHmCCmEMFx0AAAAAAAUwEwYKCZImiZPyLGQBAQQFFgN2a2cwFwYKCZImiZPyLGQB LAQJFgczNzA5NDM4MBEGCWCGSAGG+EIBAQQEAwIFoDALBgNVHQ8EBAMCA/gwJwYDVR0lBCAw HgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDBzCCAncGCCsGAQUFBwEBBIICaTCCAmUw gc4GCCsGAQUFBzAChoHBbGRhcDovL2xkYXAtdXNlYXN0LnBvc3QubHVjZW50LmNvbS9jbj1M dWNlbnQlMjBUZWNobm9sb2dpZXMlMjBDZXJ0aWZpY2F0ZSUyMFNlcnZpY2VzJTIwMSxvdT1D ZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NhY2VydGlmaWNhdGU7 YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBwgYIKwYB BQUHMAKGgbVsZGFwOi8vbGRhcC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2ll cyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRo b3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3Rj bGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHMBggrBgEFBQcwAoaBv2xkYXA6Ly9sZGFw LWVtZWEucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRp ZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxv PWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0 aWZpY2F0aW9uQXV0aG9yaXR5MIICigYDVR0fBIICgTCCAn0wgdaggdOggdCGgc1sZGFwOi8v bGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUy MENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3Jp dGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFz ZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHKoIHHoIHEhoHBbGRhcDov L2xkYXAubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBDZXJ0aWZpY2F0 ZSUyMFNlcnZpY2VzJTIwMSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNl bnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xh c3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCB1KCB0aCBzoaBy2xkYXA6Ly9sZGFwLWVtZWEu cG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRl JTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2Vu dC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZT9vYmplY3RjbGFz cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MA0GCSqGSIb3DQEBBQUAA4IBAQBZ1m98/KuOGemr fAEgtDWIiZjKEN3ShsKT3bfKvjw/zSOtL2UpwNab9xqHKdV9rt4O0wzx6By/0JY/hCQrPMAm YCO0Xo14fC8OSzRkRl1kSPn0E+v8vD+dn42a+dBdmN2SD56jg7/EkvifgaCw9n/HMi4vXcOS +RUdxZkPRnYLyh4GiocnBx88IQEzWK9shMLzC7gm3K6V6kggUSchxR703OHNTLb7XKeEDzSX LdXMVHA5N89xTQGyVWk8Mc6fO7icn0LthC81Ig0/M6v12Vmb2+Tdq7aB7ZVgaU95f/eezcHh LgaYlutde9q6s+c8ok8/hI2VBcGMt85Apf5GAktoMIIJmjCCCIKgAwIBAgIKGrlKlgAAAAAG xzANBgkqhkiG9w0BAQUFADCBsjElMCMGCSqGSIb3DQEJARYWY2FAc2VjdXJpdHkubHVjZW50 LmNvbTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC011cnJh eSBIaWxsMRwwGgYDVQQKExNMdWNlbnQgVGVjaG5vbG9naWVzMTMwMQYDVQQDEypMdWNlbnQg VGVjaG5vbG9naWVzIENlcnRpZmljYXRlIFNlcnZpY2VzIDEwHhcNMDQwNjIzMjAwMzQxWhcN MDYwNjIzMjAxMzQxWjBBMR0wGwYJKoZIhvcNAQkBFg52a2dAbHVjZW50LmNvbTEgMB4GA1UE AxMXVmlqYXkgSyBHdXJiYW5pIChWaWpheSkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB ALz/WhBEhTSwXiuyILQXqZC7pNK9A8JGXoE5tBxHnxrmzCO7V1XBPPdds432nmqNhGrGb134 5ftbYGPrx3GVhRPPnKn0qTAfuE0tVPLT0Td3B1kzfov7sgIpQr0zphTrgwkAZODW1PFQjF+U rLRIwI8kiV2ISn8mtdhvZpWGZby1AgMBAAGjggakMIIGoDAdBgNVHQ4EFgQUUb3/jDoKlQgL 6Zd1Bala4Ef6eRswgf4GA1UdIwSB9jCB84AUhJ9BVZwQiE87TdOEOn4hS09K38uhgc6kgcsw gcgxJTAjBgkqhkiG9w0BCQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5jb20xCzAJBgNVBAYTAlVT MRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkgSGlsbDEcMBoGA1UEChMT THVjZW50IFRlY2hub2xvZ2llczEcMBoGA1UECxMTTHVjZW50IFRlY2hub2xvZ2llczErMCkG A1UEAxMiTHVjZW50IFRlY2hub2xvZ2llcyBSb290IEF1dGhvcml0eYIKYQwXHQAAAAAABTAT BgoJkiaJk/IsZAEBBAUWA3ZrZzAXBgoJkiaJk/IsZAEsBAkWBzM3MDk0MzgwEQYJYIZIAYb4 QgEBBAQDAgWgMAsGA1UdDwQEAwID+DAnBgNVHSUEIDAeBggrBgEFBQcDAgYIKwYBBQUHAwQG CCsGAQUFBwMHMIICdwYIKwYBBQUHAQEEggJpMIICZTCBzgYIKwYBBQUHMAKGgcFsZGFwOi8v bGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUy MENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3Jp dGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFz cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHCBggrBgEFBQcwAoaBtWxkYXA6Ly9sZGFwLmx1 Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2 aWNlcyUyMDEsb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9j YWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRo b3JpdHkwgcwGCCsGAQUFBzAChoG/bGRhcDovL2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20v Y249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEs b3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmlj YXRlO2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwggKK BgNVHR8EggKBMIICfTCB1qCB06CB0IaBzWxkYXA6Ly9sZGFwLXVzZWFzdC5wb3N0Lmx1Y2Vu dC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNl cyUyMDEsb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0 aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmlj YXRpb25BdXRob3JpdHkwgcqggceggcSGgcFsZGFwOi8vbGRhcC5sdWNlbnQuY29tL2NuPUx1 Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNl cnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZv Y2F0aW9ubGlzdDtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9y aXR5MIHUoIHRoIHOhoHLbGRhcDovL2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVj ZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEsb3U9Q2Vy dGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9j YXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3Jp dHkwDQYJKoZIhvcNAQEFBQADggEBAFnWb3z8q44Z6at8ASC0NYiJmMoQ3dKGwpPdt8q+PD/N I60vZSnA1pv3Gocp1X2u3g7TDPHoHL/Qlj+EJCs8wCZgI7RejXh8Lw5LNGRGXWRI+fQT6/y8 P52fjZr50F2Y3ZIPnqODv8SS+J+BoLD2f8cyLi9dw5L5FR3FmQ9GdgvKHgaKhycHHzwhATNY r2yEwvMLuCbcrpXqSCBRJyHFHvTc4c1Mtvtcp4QPNJct1cxUcDk3z3FNAbJVaTwxzp87uJyf Qu2ELzUiDT8zq/XZWZvb5N2rtoHtlWBpT3l/957NweEuBpiW61172rqz5zyiTz+EjZUFwYy3 zkCl/kYCS2gwghD2MIIP3qADAgECAgphDBcdAAAAAAAFMA0GCSqGSIb3DQEBBQUAMIHIMSUw IwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEG A1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2Vu dCBUZWNobm9sb2dpZXMxHDAaBgNVBAsTE0x1Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMT Ikx1Y2VudCBUZWNobm9sb2dpZXMgUm9vdCBBdXRob3JpdHkwHhcNMDAxMjA2MTYyNjQ1WhcN MTAxMjA2MTYzNjQ1WjCBsjElMCMGCSqGSIb3DQEJARYWY2FAc2VjdXJpdHkubHVjZW50LmNv bTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC011cnJheSBI aWxsMRwwGgYDVQQKExNMdWNlbnQgVGVjaG5vbG9naWVzMTMwMQYDVQQDEypMdWNlbnQgVGVj aG5vbG9naWVzIENlcnRpZmljYXRlIFNlcnZpY2VzIDEwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCrbIc03eHms6QdVIh5h01zu8+SHMLFNRPuo3EVY8dgvQsy1pM5DSOtjDt+ JXW723615PF8cVgDVUQGE4D9T9k5B2DP3DUhtrsvH3SEKJL6NceqgWDhLzgf0JjhNdid9IHE x5xRWAiONeeLiRcScIZyRgANiokhSaM5VM2tZBctDFWrXkqxRUHvSSlWXMoXh7HYBOfEjhfJ E3BGQTOX0HOFKkCNS3CDh7ZAwNnw4Ntgkf+8bOqAzmX1ToyZbFLn7bZ9rNFg3gcDzyoFD46C ZQsibysVefigRA57WfouqpbgZ8JzIAmXAeaJLSRgutALT5beOyx75TNPdglVhKlHg4MLAgMB AAGjggz0MIIM8DAQBgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUhJ9BVZwQiE87TdOEOn4h S09K38swCwYDVR0PBAQDAgHGMA8GA1UdEwEB/wQFMAMBAf8wggEEBgNVHSMEgfwwgfmAFG/h K1C+quh9NWJpDO7LUuiSAjxdoYHOpIHLMIHIMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0 eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UE BxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxHDAaBgNVBAsT E0x1Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1Y2VudCBUZWNobm9sb2dpZXMgUm9v dCBBdXRob3JpdHmCEFmZihipVMC2QAXNTB3ruM8wggXfBgNVHR8EggXWMIIF0jCBzKCByaCB xoaBw2xkYXA6Ly9sZGFwLXVzZWFzdC5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVj aG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9y aXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jh c2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBzKCByaCBxoaBw2xkYXA6 Ly9sZGFwLXVzd2VzdC5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVz JTIwUm9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1s dWNlbnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0 Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCByaCBxqCBw4aBwGxkYXA6Ly9sZGFwLmV4 dGVybmFsLmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1 dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2Nl cnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlm aWNhdGlvbkF1dGhvcml0eTCBz6CBzKCByYaBxmxkYXA6Ly9sZGFwLXVzY2VudHJhbC5wb3N0 Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0 eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmlj YXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlv bkF1dGhvcml0eTCByqCBx6CBxIaBwWxkYXA6Ly9sZGFwLWVtZWEucG9zdC5sdWNlbnQuY29t L2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlm aWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRp b25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkw gcqggceggcSGgcFsZGFwOi8vbGRhcC1jYWxhLnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQl MjBUZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBB dXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5h cnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHIoIHFoIHChoG/ bGRhcDovL2xkYXAtYXAucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2ll cyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89 bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVj dGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwL6AtoCuGKWh0dHA6Ly93d3cuc2VjdXJp dHkubHVjZW50LmNvbS9jYS9jYTEuY3JsMIIFsgYIKwYBBQUHAQEEggWkMIIFoDCBxAYIKwYB BQUHMAKGgbdsZGFwOi8vbGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUy MFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1 dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVj dGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcQGCCsGAQUFBzAChoG3bGRhcDovL2xk YXAtdXN3ZXN0LnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBS b290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2Vu dC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0 aW9uQXV0aG9yaXR5MIHBBggrBgEFBQcwAoaBtGxkYXA6Ly9sZGFwLmV4dGVybmFsLmx1Y2Vu dC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1D ZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NhY2VydGlmaWNhdGU7 YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBxwYIKwYB BQUHMAKGgbpsZGFwOi8vbGRhcC11c2NlbnRyYWwucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2Vu dCUyMFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUy MEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29i amVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcIGCCsGAQUFBzAChoG1bGRhcDov L2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIw Um9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNl bnQuY29tP2NhY2VydGlmaWNhdGU7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNh dGlvbkF1dGhvcml0eTCBwgYIKwYBBQUHMAKGgbVsZGFwOi8vbGRhcC1jYWxhLnBvc3QubHVj ZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91 PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0 ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHABggr BgEFBQcwAoaBs2xkYXA6Ly9sZGFwLWFwLnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBU ZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRo b3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3Rj bGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MDUGCCsGAQUFBzAChilodHRwOi8vd3d3LnNl Y3VyaXR5Lmx1Y2VudC5jb20vY2EvY2ExLmNydDANBgkqhkiG9w0BAQUFAAOCAQEAObP5Urds B2nOxTrekCTXpBxKF4K0t8Doi/zHhUuupK+Bc5ppNu9dqYeGr1bKNLRbF/hccvzn4xuj3o82 gm7eZee7lssn9e6T/AjmHca+pCG9n5wZNgY6S0AJryUk6/hfyWc/7z1HfFHrkMM2zn9kqm13 h4tgCPG3WS86+WE4PO12sjAi0GYc43CszaxuU0GZoZ3cfapl5AzC8pMLltGyu/DqJLBk/biR Zr61dWmQWajF/dKhwrAtDiGc0PYZykl/Dg1mYD+eadv5qSKUdTuoa8idlief/sWnUUWbGkYb 1QUPqg8/g9UQcvBx+dgrnsf11X6GHq9gI+LKDBNLyWdEvTGCA8kwggPFAgEBMIHBMIGyMSUw IwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEG A1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2Vu dCBUZWNobm9sb2dpZXMxMzAxBgNVBAMTKkx1Y2VudCBUZWNobm9sb2dpZXMgQ2VydGlmaWNh dGUgU2VydmljZXMgMQIKGrlKlgAAAAAGxzAJBgUrDgMCGgUAoIICXTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNTExMTYyMTA2MDNaMCMGCSqGSIb3DQEJ BDEWBBQ2CCspLS8ux5bfY5sHtceeNoUF+jBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIB KDCB0gYJKwYBBAGCNxAEMYHEMIHBMIGyMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5s dWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxML TXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxMzAxBgNVBAMTKkx1 Y2VudCBUZWNobm9sb2dpZXMgQ2VydGlmaWNhdGUgU2VydmljZXMgMQIKGrlKlgAAAAAGxzCB 1AYLKoZIhvcNAQkQAgsxgcSggcEwgbIxJTAjBgkqhkiG9w0BCQEWFmNhQHNlY3VyaXR5Lmx1 Y2VudC5jb20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtN dXJyYXkgSGlsbDEcMBoGA1UEChMTTHVjZW50IFRlY2hub2xvZ2llczEzMDEGA1UEAxMqTHVj ZW50IFRlY2hub2xvZ2llcyBDZXJ0aWZpY2F0ZSBTZXJ2aWNlcyAxAgoauUqWAAAAAAbHMA0G CSqGSIb3DQEBAQUABIGAE5ZnKOAY/13dQ09WV7Sd72D/fSHmCOTtOPxRf6vdmXsQujmM+EAd p8saXN8r48GHFWtfLMFQ6K6JaRLPONGcbXToQDg6htV6KKXmhQDZ5y9iz5ErP4OLs6bCXHEh fg+koVup0SbeNMujWIiy0o1zHKpAjtoX/34cSys94I75e7QAAAAAAAA= --------------ms020803050603020305090908-- --===============0132625404== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============0132625404==-- From sip-bounces@ietf.org Thu Nov 17 05:38:58 2005 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 1EchAQ-0001wY-0N; Thu, 17 Nov 2005 05:38:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcRPx-0002vT-VU for sip@megatron.ietf.org; Wed, 16 Nov 2005 12:49:58 -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 MAA12950 for ; Wed, 16 Nov 2005 12:49:24 -0500 (EST) Received: from zproxy.gmail.com ([64.233.162.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcRhO-00021h-W0 for sip@ietf.org; Wed, 16 Nov 2005 13:08:02 -0500 Received: by zproxy.gmail.com with SMTP id 16so247557nzp for ; Wed, 16 Nov 2005 09:49:50 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=WIO4EQjXCbvL8Gnru/HW3n6FB7V0R2KZQbkV5dc6aTJ90HRZoP7FLxBDtPx3+8qAFmxgltv07VtmODMCoPW5rgJ5+ytyxE52LIiAezSNjiBy7dWIQRfZU4EgbKDfTZJkIhtLhu51zGz6tkORGSCbn1bEOOdp+jbHb1xUWMLn87k= Received: by 10.36.109.16 with SMTP id h16mr4292248nzc; Wed, 16 Nov 2005 09:49:49 -0800 (PST) Received: by 10.36.31.12 with HTTP; Wed, 16 Nov 2005 09:49:49 -0800 (PST) Message-ID: Date: Wed, 16 Nov 2005 10:49:49 -0700 From: Daryl Sanders To: Muralish P N In-Reply-To: <29b2ffd80511132257s355ef174g7426cc50d40a2ac9@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <29b2ffd80511132257s355ef174g7426cc50d40a2ac9@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 17 Nov 2005 05:38:55 -0500 Cc: sip@ietf.org, sip-implementors@cs.columbia.edu Subject: [Sip] Re: [Sip-implementors] help X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org The RFC is a good place to start. http://www.ietf.org/rfc/rfc3261.txt - Daryl On 11/13/05, Muralish P N wrote: > hai > My name is Muralish.Can u please help me in implementing sip in VoIP. > Whether there is any predefined functions to be used or we want to > create.Can u please send me some links abt the details of SIP and its > implementaion.Also help me in implementing it in VoIP. > from > muralish > Programmer > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@cs.columbia.edu > http://lists.cs.columbia.edu/mailman/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 From sip-bounces@ietf.org Thu Nov 17 05:38:59 2005 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 1EchAR-0001wz-JP; Thu, 17 Nov 2005 05:38:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcdjV-0003SQ-85 for sip@megatron.ietf.org; Thu, 17 Nov 2005 01:58:57 -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 BAA02953 for ; Thu, 17 Nov 2005 01:58:22 -0500 (EST) From: sushma.boppana@wipro.com Received: from wip-ec-wd.wipro.com ([203.91.193.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ece0j-0005O8-4w for sip@ietf.org; Thu, 17 Nov 2005 02:17:08 -0500 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id 67F92205F9 for ; Thu, 17 Nov 2005 12:14:51 +0530 (IST) Received: from blr-ec-bh01.wipro.com (blr-ec-bh01.wipro.com [10.201.50.91]) by wip-ec-wd.wipro.com (Postfix) with ESMTP id 48B13205E1 for ; Thu, 17 Nov 2005 12:14:51 +0530 (IST) Received: from BLR-EC-MBX02.wipro.com ([10.201.50.162]) by blr-ec-bh01.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Nov 2005 12:27:46 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 17 Nov 2005 12:27:27 +0530 Message-ID: Thread-Topic: Use of NPDI Param in SIP Message Thread-Index: AcXrRCvGEhVw8xQhRxK1kF+EIeO2Mw== To: X-OriginalArrivalTime: 17 Nov 2005 06:57:46.0447 (UTC) FILETIME=[3716C5F0:01C5EB44] X-Spam-Score: 0.4 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c X-Mailman-Approved-At: Thu, 17 Nov 2005 05:38:55 -0500 Cc: Subject: [Sip] Use of NPDI Param in SIP Message X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2072336631==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============2072336631== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5EB44.37018FAC" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5EB44.37018FAC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 I want to know the use of NPDI Parameter in sip message. Could you please provide me any document related to NPDI param? =20 Regards, Sushma =20 =20 =20 ------_=_NextPart_001_01C5EB44.37018FAC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I want to know the use of NPDI Parameter in sip message. = Could you please provide me any document related to NPDI = param?

 

Regards,

Sushma

 

 

 

------_=_NextPart_001_01C5EB44.37018FAC-- --===============2072336631== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============2072336631==-- From sip-bounces@ietf.org Thu Nov 17 13:58:04 2005 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 1EcoxQ-0004Hr-Ig; Thu, 17 Nov 2005 13:58:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcoxP-0004Hi-8l for sip@megatron.ietf.org; Thu, 17 Nov 2005 13:58:03 -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 NAA14078 for ; Thu, 17 Nov 2005 13:57:28 -0500 (EST) Received: from smtp.persistent.co.in ([202.54.11.65]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcpF5-000554-Nr for sip@ietf.org; Thu, 17 Nov 2005 14:16:20 -0500 Received: from mail.persistent.co.in ([10.12.0.1]) by smtp.persistent.co.in (8.12.9/) with ESMTP id jAHIw55E032016 for ; Fri, 18 Nov 2005 00:28:06 +0530 Received: from ps0692 ([10.33.1.80]) by mail.persistent.co.in (MOS 3.6.4-CR) with ESMTP id AFN89207; Fri, 18 Nov 2005 00:27:46 +0530 (IST) From: "Manjeet Soodan" To: Date: Fri, 18 Nov 2005 00:28:24 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Brightmail-Tracker: AAAAAQAAAAQ= X-Whitelist: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Subject: [Sip] Query about '491 response' in case of RE-INVITE. X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org 1) There are two SIP UA's A and B. 2) A sends INVITE with SDP to B. 3) B responds with 100 and then 180 Ringing(wthout SDP) and adds TO tag to 180. 3) After 180 is received, A sends a RE-INVITE before 200 OK is received (i.e RE-INVITE with all the headers having same value as initial INVITE and higher CSEQ value). 4) In this case B responds with a '491 Request Pending' for RE-INVITE. Is it the right behaviour, if not then what should be the right behaviour of B? -Manjeet _______________________________________________ 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 From sip-bounces@ietf.org Thu Nov 17 14:10:33 2005 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 1Ecp9V-0000Yp-Ny; Thu, 17 Nov 2005 14:10:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecp9U-0000Yk-4V for sip@megatron.ietf.org; Thu, 17 Nov 2005 14:10:32 -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 OAA14899 for ; Thu, 17 Nov 2005 14:09:57 -0500 (EST) Received: from sonussf1.sonusnet.com ([208.45.178.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcpRA-0005Xz-CH for sip@ietf.org; Thu, 17 Nov 2005 14:28:49 -0500 Received: from sonusmail03.sonusnet.com (sonusmail03.sonusnet.com [10.128.32.97]) by sonussf1.sonusnet.com (8.13.3/8.13.3) with ESMTP id jAHJAFJu006585; Thu, 17 Nov 2005 14:10:15 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Query about '491 response' in case of RE-INVITE. Date: Thu, 17 Nov 2005 14:10:15 -0500 Message-ID: Thread-Topic: [Sip] Query about '491 response' in case of RE-INVITE. Thread-Index: AcXrqW8OySErBo7qSdWDDyNEZhZRYgAAFHMQ From: "Syed, Mohammad Rafi" To: "Manjeet Soodan" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is right behaviour as Offer recvd at UA-B in the initial INVITE is = still not replied with an answer(either in 18X if reliable is used or = 200OK with SDP). A B ----INVITEOffer1----> <------answer1----(18X with SDP if reliable or 200 OK with SDP) -Rafi. -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of Manjeet Soodan Sent: Thursday, November 17, 2005 1:58 PM To: sip@ietf.org Subject: [Sip] Query about '491 response' in case of RE-INVITE. 1) There are two SIP UA's A and B. 2) A sends INVITE with SDP to B. 3) B responds with 100 and then 180 Ringing(wthout SDP) and adds TO tag = to 180. 3) After 180 is received, A sends a RE-INVITE before 200 OK is received (i.e RE-INVITE with all the headers having same value as initial INVITE = and higher CSEQ value). 4) In this case B responds with a '491 Request Pending' for RE-INVITE. Is it the right behaviour, if not then what should be the right = behaviour of B? -Manjeet _______________________________________________ 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 From sip-bounces@ietf.org Thu Nov 17 15:21:13 2005 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 1EcqFt-0002Fi-63; Thu, 17 Nov 2005 15:21:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcqFr-0002FH-4O for sip@megatron.ietf.org; Thu, 17 Nov 2005 15:21:11 -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 PAA17435 for ; Thu, 17 Nov 2005 15:20:35 -0500 (EST) From: ramakrishna.adukuri@wipro.com Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcqXV-0007Ow-3k for sip@ietf.org; Thu, 17 Nov 2005 15:39:28 -0500 Received: from wip-ec-wd.wipro.com ([203.91.193.32]) by mx2.foretec.com with esmtp (Exim 4.24) id 1EcqA5-0008SO-0s for sip@ietf.org; Thu, 17 Nov 2005 15:15:13 -0500 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id 12E3120641 for ; Fri, 18 Nov 2005 01:31:04 +0530 (IST) Received: from blr-ec-bh01.wipro.com (blr-ec-bh01.wipro.com [10.201.50.91]) by wip-ec-wd.wipro.com (Postfix) with ESMTP id BD7D5205F8 for ; Fri, 18 Nov 2005 01:00:42 +0530 (IST) Received: from BLR-EC-MBX04.wipro.com ([10.201.50.165]) by blr-ec-bh01.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Nov 2005 01:13:38 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] Query about '491 response' in case of RE-INVITE. Date: Fri, 18 Nov 2005 01:13:38 +0530 Message-ID: Thread-Topic: [Sip] Query about '491 response' in case of RE-INVITE. Thread-Index: AcXrqeXpVnCxvZ22QC6XxyCUc2/ceAAAYtgZ To: , X-OriginalArrivalTime: 17 Nov 2005 19:43:38.0729 (UTC) FILETIME=[34C88D90:01C5EBAF] X-Spam-Score: 0.8 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1442320405==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1442320405== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5EBAF.34AEDFEB" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5EBAF.34AEDFEB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable After receiving 180, Invite Client Transaction at User A is in = 'Proceeding' state. Re-Invite must not be sent before the previous = INVITE trasaction gets into a Completed or Terminated state. =20 =20 ----------- RFC 3261, 14.1 UAC Behavior States: UAC MUST NOT initiate a new INVITE transaction within a dialog while = another INVITE transaction is in progress in either direction. If there = is an ongoing INVITE client transaction, the TU MUST wait until the = transaction reaches the completed or terminated state before initiating = the new INVITE. ------------ Also 491 'Request Pending' is sent when a UAS receives an INVITE while = it is expecting a response for the INVITE it has sent. 500 Server Internal Error with 'Retry-After' is appropriate for this = case. See RFC 3261 section 14.2. -Ramakrishna =20 =20 ________________________________ From: sip-bounces@ietf.org on behalf of Manjeet Soodan Sent: Fri 11/18/2005 12:28 AM To: sip@ietf.org Subject: [Sip] Query about '491 response' in case of RE-INVITE. 1) There are two SIP UA's A and B. 2) A sends INVITE with SDP to B. 3) B responds with 100 and then 180 Ringing(wthout SDP) and adds TO tag = to 180. 3) After 180 is received, A sends a RE-INVITE before 200 OK is received (i.e RE-INVITE with all the headers having same value as initial INVITE = and higher CSEQ value). 4) In this case B responds with a '491 Request Pending' for RE-INVITE. Is it the right behaviour, if not then what should be the right = behaviour of B? -Manjeet _______________________________________________ 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 ------_=_NextPart_001_01C5EBAF.34AEDFEB Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= [Sip] Query about '491 response' in case of RE-INVITE.=0A= =0A= =0A=
=0A=
After = receiving 180, =0A= Invite Client Transaction at User A is in 'Proceeding' state. =0A= Re-Invite must not be sent before the previous INVITE = trasaction =0A= gets into a Completed or Terminated state.  
=0A=
 
=0A=
-----------
=0A=
RFC 3261, 14.1 =0A= UAC Behavior States:
=0A=
UAC MUST NOT = initiate a new =0A= INVITE transaction within a dialog while another INVITE transaction is = in =0A= progress in either direction. If there = is an =0A= ongoing INVITE client transaction, the TU MUST wait until the = transaction =0A= reaches the completed or terminated state before initiating the new = INVITE.
=0A=
------------
=0A=
=0A=

Also 491 'Request Pending' is sent when a = UAS =0A= receives an INVITE while it is expecting a response for the INVITE it = has =0A= sent.

=0A=

500 Server Internal Error with = 'Retry-After' is =0A= appropriate for this case. See RFC 3261 section 14.2.

=0A=

-Ramakrishna

=0A=

 

=0A=
 
=0A=

=0A=
=0A= From: sip-bounces@ietf.org on behalf = of Manjeet =0A= Soodan
Sent: Fri 11/18/2005 12:28 AM
To: =0A= sip@ietf.org
Subject: [Sip] Query about '491 response' in case = of =0A= RE-INVITE.

=0A=
=0A=

1) There are two SIP UA's A and B.
2) A sends = INVITE with SDP =0A= to B.
3) B responds with 100 and then 180 Ringing(wthout SDP)  = and adds =0A= TO tag to
180.
3) After 180 is received, A sends a  RE-INVITE = before =0A= 200 OK is received
(i.e RE-INVITE with all the headers having same = value as =0A= initial INVITE and
higher CSEQ value).
4) In this case B responds = with =0A= a  '491 Request Pending' for RE-INVITE.

Is it the right = behaviour, =0A= if not then what should be the right behaviour =0A= of
B?


-Manjeet



_____________________________= __________________
Sip =0A= mailing list  https://www1.ietf.org= /mailman/listinfo/sip
This =0A= list is for NEW development of the core SIP Protocol
Use =0A= sip-implementors@cs.columbia.edu for questions on current sip
Use =0A= sipping@ietf.org for new developments on the application of =0A= sip

=0A= =0A= =0A= ------_=_NextPart_001_01C5EBAF.34AEDFEB-- --===============1442320405== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1442320405==-- From sip-bounces@ietf.org Thu Nov 17 15:23:42 2005 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 1EcqII-0002nm-9T; Thu, 17 Nov 2005 15:23:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcqIF-0002nH-UT for sip@megatron.ietf.org; Thu, 17 Nov 2005 15:23:40 -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 PAA17835 for ; Thu, 17 Nov 2005 15:23:04 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcqXx-0007Ni-Vq for sip@ietf.org; Thu, 17 Nov 2005 15:39:55 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by mx2.foretec.com with esmtp (Exim 4.24) id 1Ecq4g-00080u-AZ for sip@ietf.org; Thu, 17 Nov 2005 15:09:38 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by sj-iport-3.cisco.com with ESMTP; 17 Nov 2005 12:08:06 -0800 X-IronPort-AV: i="3.97,343,1125903600"; d="scan'208"; a="366873692:sNHT114233966" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jAHK7im1012394; Thu, 17 Nov 2005 15:08:03 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 17 Nov 2005 15:07:48 -0500 Received: from [161.44.79.90] ([161.44.79.90]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 17 Nov 2005 15:07:47 -0500 Message-ID: <437CE313.9000301@cisco.com> Date: Thu, 17 Nov 2005 15:07:47 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Syed, Mohammad Rafi" Subject: Re: [Sip] Query about '491 response' in case of RE-INVITE. References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Nov 2005 20:07:47.0964 (UTC) FILETIME=[949843C0:01C5EBB2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org No, this is not correct behavior. There must not be a reinvite until the initial invite transaction is completed (with a 200 and an ACK). If the 180 is sent *reliably* (using the 100rel option) and then PRACKed, then there is an early dialog and A may send an UPDATE. That is as close as you can get to the functionality of a reinvite before the initial invite is present. Paul Syed, Mohammad Rafi wrote: > This is right behaviour as Offer recvd at UA-B in the initial INVITE is still not replied with an answer(either in 18X if reliable is used or 200OK with SDP). > > A B > ----INVITEOffer1----> > <------answer1----(18X with SDP if reliable or 200 OK with SDP) > > > -Rafi. > > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of > Manjeet Soodan > Sent: Thursday, November 17, 2005 1:58 PM > To: sip@ietf.org > Subject: [Sip] Query about '491 response' in case of RE-INVITE. > > > 1) There are two SIP UA's A and B. > 2) A sends INVITE with SDP to B. > 3) B responds with 100 and then 180 Ringing(wthout SDP) and adds TO tag to > 180. > 3) After 180 is received, A sends a RE-INVITE before 200 OK is received > (i.e RE-INVITE with all the headers having same value as initial INVITE and > higher CSEQ value). > 4) In this case B responds with a '491 Request Pending' for RE-INVITE. > > Is it the right behaviour, if not then what should be the right behaviour of > B? > > > -Manjeet > > > > _______________________________________________ > 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 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 From sip-bounces@ietf.org Thu Nov 17 22:52:56 2005 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 1EcxJ2-000419-FI; Thu, 17 Nov 2005 22:52:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcxJ0-00040E-GJ for sip@megatron.ietf.org; Thu, 17 Nov 2005 22:52:54 -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 WAA18160 for ; Thu, 17 Nov 2005 22:52:20 -0500 (EST) From: Shweta.Kavishwar@flextronicssoftware.com Received: from delta.hssblr.co.in ([203.145.155.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ecxah-00074N-C6 for sip@ietf.org; Thu, 17 Nov 2005 23:11:16 -0500 Received: from espion.blr.hss.hns.com (espion.blr.hss.hns.com [10.203.193.21]) by delta.hssblr.co.in (8.11.6/8.11.6) with ESMTP id jAI3qgx32519 for ; Fri, 18 Nov 2005 09:22:42 +0530 To: sip@ietf.org X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: Date: Fri, 18 Nov 2005 09:19:12 +0530 X-MIMETrack: Serialize by Router on Espion/BLR/HSS(Release 6.5|September 18, 2003) at 11/18/2005 09:37:45 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.5 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [Sip] 3xx response for a re-Invite ? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi All, I would like to know if it is correct to send a 3xx response for a re-Invite request. And if so, what could be the possible scenarios. Also refer the following link which says 3xx to re_INVITE allowed.( IETF meeting 52 ): http://www.softarmor.com/sipwg/meets/ietf52/slides/pres-jdrosen-sip-new-bis-ietf52.ppt Thanks, Shweta. "DISCLAIMER: This message is proprietary to Flextronics Software Systems Limited (FSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." _______________________________________________ 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 From sip-bounces@ietf.org Fri Nov 18 02:20:19 2005 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 1Ed0Xj-0003Q5-6w; Fri, 18 Nov 2005 02:20:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed0Xh-0003Pv-IG for sip@megatron.ietf.org; Fri, 18 Nov 2005 02:20:17 -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 CAA27528 for ; Fri, 18 Nov 2005 02:19:42 -0500 (EST) Received: from smtp.persistent.co.in ([202.54.11.65]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ed0pU-0004V2-MX for sip@ietf.org; Fri, 18 Nov 2005 02:38:41 -0500 Received: from mail.persistent.co.in ([10.12.0.1]) by smtp.persistent.co.in (8.12.9/) with ESMTP id jAI7K5Lp031602; Fri, 18 Nov 2005 12:50:10 +0530 Received: from ps0692 ([10.33.1.80]) by mail.persistent.co.in (MOS 3.6.4-CR) with ESMTP id AFO03176; Fri, 18 Nov 2005 12:49:53 +0530 (IST) From: "Manjeet Soodan" To: "Paul Kyzivat" Subject: RE: [Sip] Query about '491 response' in case of RE-INVITE. Date: Fri, 18 Nov 2005 12:50:32 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <437CE313.9000301@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Brightmail-Tracker: AAAAAQAAAAQ= X-Whitelist: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Paul, but in our case an early dialog is already formed when we received a '180' with TO tag, so in this case a INVITE can be considered as a RE-INVITE as is the case below, then a '491' becomes a valid response. Acc to RFC 3261 :- 12.1 Creation of a Dialog Dialogs are created through the generation of non-failure responses to requests with specific methods. Within this specification, only 2xx and 101-199 responses with a To tag, where the request was INVITE, will establish a dialog. A dialog established by a non-final response to a request is in the "early" state and it is called an early dialog. -Manjeet -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: Friday, November 18, 2005 1:38 AM To: Syed, Mohammad Rafi Cc: Manjeet Soodan; sip@ietf.org Subject: Re: [Sip] Query about '491 response' in case of RE-INVITE. No, this is not correct behavior. There must not be a reinvite until the initial invite transaction is completed (with a 200 and an ACK). If the 180 is sent *reliably* (using the 100rel option) and then PRACKed, then there is an early dialog and A may send an UPDATE. That is as close as you can get to the functionality of a reinvite before the initial invite is present. Paul Syed, Mohammad Rafi wrote: > This is right behaviour as Offer recvd at UA-B in the initial INVITE is still not replied with an answer(either in 18X if reliable is used or 200OK with SDP). > > A B > ----INVITEOffer1----> > <------answer1----(18X with SDP if reliable or 200 OK with SDP) > > > -Rafi. > > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of > Manjeet Soodan > Sent: Thursday, November 17, 2005 1:58 PM > To: sip@ietf.org > Subject: [Sip] Query about '491 response' in case of RE-INVITE. > > > 1) There are two SIP UA's A and B. > 2) A sends INVITE with SDP to B. > 3) B responds with 100 and then 180 Ringing(wthout SDP) and adds TO tag to > 180. > 3) After 180 is received, A sends a RE-INVITE before 200 OK is received > (i.e RE-INVITE with all the headers having same value as initial INVITE and > higher CSEQ value). > 4) In this case B responds with a '491 Request Pending' for RE-INVITE. > > Is it the right behaviour, if not then what should be the right behaviour of > B? > > > -Manjeet > > > > _______________________________________________ > 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 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 From sip-bounces@ietf.org Fri Nov 18 04:24:58 2005 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 1Ed2UL-000819-Qc; Fri, 18 Nov 2005 04:24:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed2UK-00080G-3S for sip@megatron.ietf.org; Fri, 18 Nov 2005 04:24:56 -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 EAA03644 for ; Fri, 18 Nov 2005 04:24:20 -0500 (EST) Received: from smtp.persistent.co.in ([202.54.11.65]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ed2m6-0008TJ-Ch for sip@ietf.org; Fri, 18 Nov 2005 04:43:21 -0500 Received: from mail.persistent.co.in ([10.12.0.1]) by smtp.persistent.co.in (8.12.9/) with ESMTP id jAI9OisF018716; Fri, 18 Nov 2005 14:54:47 +0530 Received: from ps0692 ([10.33.1.80]) by mail.persistent.co.in (MOS 3.6.4-CR) with ESMTP id AFO08788; Fri, 18 Nov 2005 14:54:31 +0530 (IST) From: "Manjeet Soodan" To: "Paul Kyzivat" , "Syed, Mohammad Rafi" Subject: RE: [Sip] Query about '491 response' in case of RE-INVITE. Date: Fri, 18 Nov 2005 14:55:10 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <437CE313.9000301@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Brightmail-Tracker: AAAAAQAAAAQ= X-Whitelist: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org if we say that this is not the correct behaviour then what should be the reply from the UAS B, when the 2nd INVITE is send. what error code will be a valid response for the 2nd INVITE in this case? -Manjeet -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: Friday, November 18, 2005 1:38 AM To: Syed, Mohammad Rafi Cc: Manjeet Soodan; sip@ietf.org Subject: Re: [Sip] Query about '491 response' in case of RE-INVITE. No, this is not correct behavior. There must not be a reinvite until the initial invite transaction is completed (with a 200 and an ACK). If the 180 is sent *reliably* (using the 100rel option) and then PRACKed, then there is an early dialog and A may send an UPDATE. That is as close as you can get to the functionality of a reinvite before the initial invite is present. Paul Syed, Mohammad Rafi wrote: > This is right behaviour as Offer recvd at UA-B in the initial INVITE is still not replied with an answer(either in 18X if reliable is used or 200OK with SDP). > > A B > ----INVITEOffer1----> > <------answer1----(18X with SDP if reliable or 200 OK with SDP) > > > -Rafi. > > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of > Manjeet Soodan > Sent: Thursday, November 17, 2005 1:58 PM > To: sip@ietf.org > Subject: [Sip] Query about '491 response' in case of RE-INVITE. > > > 1) There are two SIP UA's A and B. > 2) A sends INVITE with SDP to B. > 3) B responds with 100 and then 180 Ringing(wthout SDP) and adds TO tag to > 180. > 3) After 180 is received, A sends a RE-INVITE before 200 OK is received > (i.e RE-INVITE with all the headers having same value as initial INVITE and > higher CSEQ value). > 4) In this case B responds with a '491 Request Pending' for RE-INVITE. > > Is it the right behaviour, if not then what should be the right behaviour of > B? > > > -Manjeet > > > > _______________________________________________ > 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 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 From sip-bounces@ietf.org Fri Nov 18 04:38:56 2005 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 1Ed2hs-0006wJ-Ng; Fri, 18 Nov 2005 04:38:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed2hq-0006sF-Rs for sip@megatron.ietf.org; Fri, 18 Nov 2005 04:38:54 -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 EAA04549 for ; Fri, 18 Nov 2005 04:38:18 -0500 (EST) From: ramakrishna.adukuri@wipro.com Received: from wip-ec-wd.wipro.com ([203.91.193.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ed2zU-0000Wv-FT for sip@ietf.org; Fri, 18 Nov 2005 04:57:19 -0500 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id 1C97A20623 for ; Fri, 18 Nov 2005 14:55:02 +0530 (IST) Received: from blr-ec-bh01.wipro.com (blr-ec-bh01.wipro.com [10.201.50.91]) by wip-ec-wd.wipro.com (Postfix) with ESMTP id F42222061B for ; Fri, 18 Nov 2005 14:55:01 +0530 (IST) Received: from BLR-EC-MBX04.wipro.com ([10.201.50.165]) by blr-ec-bh01.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Nov 2005 15:07:58 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Query about '491 response' in case of RE-INVITE. Date: Fri, 18 Nov 2005 15:07:57 +0530 Message-ID: Thread-Topic: [Sip] Query about '491 response' in case of RE-INVITE. Thread-Index: AcXsE2lH4qHpEfO3RQKBqkSp9ConuAAC9zlQ To: X-OriginalArrivalTime: 18 Nov 2005 09:37:58.0854 (UTC) FILETIME=[C2F16E60:01C5EC23] X-Spam-Score: 0.3 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org, pkyzivat@cisco.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Manjeet- A) Re-Invite must not be sent before the previous Invite transaction completes. B) A new offer must not be sent before a offer/answer exchange completes. In the case you mentioned, 180 is received without SDP. From the message flow, I think it is not a reliable provisional also. As offer/answer is not completed, you cannot send another offer(even UPDATE is not possible). You may want to look at "Table 1. Summary of SIP Usage of Offer/Answer Model" in 'draft-sawada-sipping-sip-offeranswer-00'. A new offer is possible in early dialog only with PRACK and UPDATE requests. C) If UAS receives a re-Invite(from an errant UAC) before UAS sends a final response to previous Invite, it should respond back with 500 (Server Internal Error) and include 'Retry-After' header with a value between 0 to 10 seconds. 491 is not the correct message. -Ramakrishna -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Manjeet Soodan Sent: Friday, November 18, 2005 12:51 PM To: Paul Kyzivat Cc: sip@ietf.org Subject: RE: [Sip] Query about '491 response' in case of RE-INVITE. Paul, but in our case an early dialog is already formed when we received a '180' with TO tag, so in this case a INVITE can be considered as a RE-INVITE as is the case below, then a '491' becomes a valid response. Acc to RFC 3261 :- 12.1 Creation of a Dialog Dialogs are created through the generation of non-failure responses to requests with specific methods. Within this specification, only 2xx and 101-199 responses with a To tag, where the request was INVITE, will establish a dialog. A dialog established by a non-final response to a request is in the "early" state and it is called an early dialog. -Manjeet -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: Friday, November 18, 2005 1:38 AM To: Syed, Mohammad Rafi Cc: Manjeet Soodan; sip@ietf.org Subject: Re: [Sip] Query about '491 response' in case of RE-INVITE. No, this is not correct behavior. There must not be a reinvite until the initial invite transaction is completed (with a 200 and an ACK). If the 180 is sent *reliably* (using the 100rel option) and then PRACKed, then there is an early dialog and A may send an UPDATE. That is as close as you can get to the functionality of a reinvite before the initial invite is present. Paul Syed, Mohammad Rafi wrote: > This is right behaviour as Offer recvd at UA-B in the initial INVITE=20 > is still not replied with an answer(either in 18X if reliable is used or 200OK with SDP). > > A B > ----INVITEOffer1----> > <------answer1----(18X with SDP if reliable or 200 OK with SDP) > > > -Rafi. > > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of=20 > Manjeet Soodan > Sent: Thursday, November 17, 2005 1:58 PM > To: sip@ietf.org > Subject: [Sip] Query about '491 response' in case of RE-INVITE. > > > 1) There are two SIP UA's A and B. > 2) A sends INVITE with SDP to B. > 3) B responds with 100 and then 180 Ringing(wthout SDP) and adds TO=20 > tag to > 180. > 3) After 180 is received, A sends a RE-INVITE before 200 OK is=20 > received (i.e RE-INVITE with all the headers having same value as=20 > initial INVITE and > higher CSEQ value). > 4) In this case B responds with a '491 Request Pending' for RE-INVITE. > > Is it the right behaviour, if not then what should be the right=20 > behaviour of > B? > > > -Manjeet > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > 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=20 > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > 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 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 From sip-bounces@ietf.org Fri Nov 18 05:42:26 2005 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 1Ed3hK-0005v5-Rv; Fri, 18 Nov 2005 05:42:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed3hI-0005tC-0C for sip@megatron.ietf.org; Fri, 18 Nov 2005 05:42:24 -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 FAA08090 for ; Fri, 18 Nov 2005 05:41:49 -0500 (EST) Received: from smtp3.clb.oleane.net ([213.56.31.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ed3z4-0002dv-9Y for sip@ietf.org; Fri, 18 Nov 2005 06:00:49 -0500 Received: from Pavillonquatre ([194.3.133.88]) (authenticated) by smtp3.clb.oleane.net with ESMTP id jAIAftli007868 for ; Fri, 18 Nov 2005 11:41:56 +0100 Message-Id: <200511181041.jAIAftli007868@smtp3.clb.oleane.net> From: "Chantal Ladouce" To: Date: Fri, 18 Nov 2005 11:41:31 +0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXsLKMTqUh8cMRuRGCzYMU+byEpCg== X-Spam-Score: 0.0 (/) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c Subject: [Sip] IMS at the International SIP 2006 - Paris - France X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1559418575==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1559418575== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0047_01C5EC35.059D8BC0" This is a multi-part message in MIME format. ------=_NextPart_000_0047_01C5EC35.059D8BC0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Carriers Experience on SIP based IMS Real Size Experiments . Extending SIP IMS Architecture from Wireless to Wireline Networks . Challenges in IMS Testing Everything you need to know on IMS and SIP will be delivered at the International SIP conference to be held in Paris next 21-24 February 2006. Get all details at: http://www.upperside.fr/sip2006/sip2006program.htm#day2 ------=_NextPart_000_0047_01C5EC35.059D8BC0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Carriers = Experience on SIP based IMS Real Size = Experiments

=

. Extending = SIP IMS Architecture from Wireless to Wireline Networks

=

. Challenges in = IMS Testing

=

 

Everything you = need to know on IMS and SIP will be delivered at the International SIP = conference to be held in Paris next 21-24 February 2006.

=

 

Get all details = at:

=

 

http://w= ww.upperside.fr/sip2006/sip2006program.htm#day2

 

 

------=_NextPart_000_0047_01C5EC35.059D8BC0-- --===============1559418575== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1559418575==-- From sip-bounces@ietf.org Fri Nov 18 07:03:21 2005 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 1Ed4xd-0005I1-LC; Fri, 18 Nov 2005 07:03:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed4xZ-0005HS-Qs; Fri, 18 Nov 2005 07:03:18 -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 HAA12279; Fri, 18 Nov 2005 07:02:42 -0500 (EST) Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ed5FO-0005C2-E3; Fri, 18 Nov 2005 07:21:44 -0500 Received: from mail1.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id jAIC2qbi031697; Fri, 18 Nov 2005 13:02:52 +0100 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id jAIC2pEl030339; Fri, 18 Nov 2005 13:02:51 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Fri, 18 Nov 2005 13:02:47 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 18 Nov 2005 13:02:41 +0100 Message-ID: Thread-Topic: Comment on draft-schwartz-sipping-spit-saml-00 Thread-Index: AcXpOzeUo0WNAfT1QQyrGK8ysWf5WACeNnEg From: "Tschofenig, Hannes" To: "Otmar Lendl" , , , X-OriginalArrivalTime: 18 Nov 2005 12:02:47.0748 (UTC) FILETIME=[FDED7040:01C5EC37] X-Spam-Score: 0.2 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org, sipping@ietf.org Subject: [Sip] AW: Comment on draft-schwartz-sipping-spit-saml-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org hi otmar,=20 thanks for your feedback. let me also respond to your comments.=20 > Hello, >=20 > as I'm not sure whether this draft is supposed to be discussed in > sip or sipping, I'm writing directly to you: >=20 > After a quick reading of draft-schwartz-sipping-spit-saml-00 I'm > wondering: >=20 > * e.g. 5.1.1:=20 > The numerical values maybe fine to denote the strength levels > you have in mind now, but they do not offer any space for > adding new notions which lie between current values. >=20 > I'd recommend you change the values from 0,1,2,3,4 to > 0,10,20,30,40 to accomodate future enhancements. >=20 that's a very good question.=20 let me point to a few aspects here:=20 - first, i think that there is a difference in the way how difficult it is to obtain an identity in a certain domain. i guess there are no doubts about this.=20 - the second aspect is how you actually rank the different ways. i am not sure whether it is a good idea to make a ranking at all. maybe it is just better to assume that there are different categories and to let the person that writes the policies decide whether they think that certain mechanisms are more difficult in, for example, one country than in another one.=20 - the third aspect is extensibility. how do you actually add new mechanisms to the list? currently we do not define an extensibility mechanism and that needs to be fixed.=20 for example, what happens if i want to add something like a 'return-routability' check. this is often done with today's email providers. you need to have a valid email address (or something similar). you might also use an sms (which provides higher security , probably).=20 - the forth aspect is: 'are the currently defined values reasonable?' for example, is the 'paying service' actually indicating something about your identity. at some point in time we need to go through these attributes and discuss what attributes & values are most useful. > * The XML (SAML) framents look overly complex: > I haven't read the SAML spec itself, but the example >=20 > AttributeName=3D"IdentityStrength" > AttributeNamespace=3D"http://mio.com"> > 2 > > >=20 > looks overly contorted. Why not the following? >=20 > 2 i will look at this aspect in the next few days. let me send you a response about it later. the usage of the attribute statement seems to be the right way forward but i am not sure about the details at the moment. we, however, might not be able to put arbitrary xml statements in a saml assertion.=20 ciao hannes >=20 > cheers, >=20 > /ol > --=20 > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > >=20 _______________________________________________ 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 From sip-bounces@ietf.org Fri Nov 18 08:52:43 2005 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 1Ed6fT-0001Ad-Bp; Fri, 18 Nov 2005 08:52:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed6fR-0001AV-K7 for sip@megatron.ietf.org; Fri, 18 Nov 2005 08:52:41 -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 IAA18817 for ; Fri, 18 Nov 2005 08:52:06 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ed6xI-0000ck-HC for sip@ietf.org; Fri, 18 Nov 2005 09:11:08 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 18 Nov 2005 05:52:32 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jAIDptes024671; Fri, 18 Nov 2005 05:52:30 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 18 Nov 2005 08:51:18 -0500 Received: from [10.86.243.40] ([10.86.243.40]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 18 Nov 2005 08:51:17 -0500 Message-ID: <437DDC54.9000301@cisco.com> Date: Fri, 18 Nov 2005 08:51:16 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Manjeet Soodan Subject: Re: [Sip] Query about '491 response' in case of RE-INVITE. References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Nov 2005 13:51:17.0846 (UTC) FILETIME=[263F8F60:01C5EC47] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Manjeet, Sorry that my prior reply missed the point of what you were asking. Once we havemade the assumption that A has violated 3261, we are in an area of speculation. In general 3261 doesn't specify the proper response to invalid usage. I think your use of 491 might be ok. Lots of other things might also be plausible. Paul Manjeet Soodan wrote: > if we say that this is not the correct behaviour then what should be the > reply from the UAS B, when the 2nd INVITE is send. > > what error code will be a valid response for the 2nd INVITE in this case? > > > -Manjeet > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Friday, November 18, 2005 1:38 AM > To: Syed, Mohammad Rafi > Cc: Manjeet Soodan; sip@ietf.org > Subject: Re: [Sip] Query about '491 response' in case of RE-INVITE. > > > No, this is not correct behavior. There must not be a reinvite until the > initial invite transaction is completed (with a 200 and an ACK). > > If the 180 is sent *reliably* (using the 100rel option) and then > PRACKed, then there is an early dialog and A may send an UPDATE. That is > as close as you can get to the functionality of a reinvite before the > initial invite is present. > > Paul > > Syed, Mohammad Rafi wrote: > >>This is right behaviour as Offer recvd at UA-B in the initial INVITE is > > still not replied with an answer(either in 18X if reliable is used or 200OK > with SDP). > >>A B >>----INVITEOffer1----> >><------answer1----(18X with SDP if reliable or 200 OK with SDP) >> >> >>-Rafi. >> >>-----Original Message----- >>From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of >>Manjeet Soodan >>Sent: Thursday, November 17, 2005 1:58 PM >>To: sip@ietf.org >>Subject: [Sip] Query about '491 response' in case of RE-INVITE. >> >> >>1) There are two SIP UA's A and B. >>2) A sends INVITE with SDP to B. >>3) B responds with 100 and then 180 Ringing(wthout SDP) and adds TO tag > > to > >>180. >>3) After 180 is received, A sends a RE-INVITE before 200 OK is received >>(i.e RE-INVITE with all the headers having same value as initial INVITE > > and > >>higher CSEQ value). >>4) In this case B responds with a '491 Request Pending' for RE-INVITE. >> >>Is it the right behaviour, if not then what should be the right behaviour > > of > >>B? >> >> >>-Manjeet >> >> >> >>_______________________________________________ >>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 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 From sip-bounces@ietf.org Fri Nov 18 10:34:40 2005 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 1Ed8G8-0008EN-A1; Fri, 18 Nov 2005 10:34:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed8G5-00084s-Ml for sip@megatron.ietf.org; Fri, 18 Nov 2005 10:34: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 KAA23935 for ; Fri, 18 Nov 2005 10:34:01 -0500 (EST) Received: from smtp.persistent.co.in ([202.54.11.65]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ed8Xx-0003mA-6l for sip@ietf.org; Fri, 18 Nov 2005 10:53:05 -0500 Received: from mail.persistent.co.in ([10.12.0.1]) by smtp.persistent.co.in (8.12.9/) with ESMTP id jAIFYWPs001608; Fri, 18 Nov 2005 21:04:32 +0530 Received: from ps0692 ([10.33.1.80]) by mail.persistent.co.in (MOS 3.6.4-CR) with ESMTP id AFO20701; Fri, 18 Nov 2005 21:04:15 +0530 (IST) From: "Manjeet Soodan" To: "Paul Kyzivat" Subject: RE: [Sip] Query about '491 response' in case of RE-INVITE. Date: Fri, 18 Nov 2005 21:04:54 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <437DDC54.9000301@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Brightmail-Tracker: AAAAAQAAAAQ= X-Whitelist: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org paul, just last question, can we send '180 Ringing' as a response in this case for the 2nd INVITE, and would 180 be a valid response in this case.? We are having a big discussion over this? -Manjeet -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: Friday, November 18, 2005 7:21 PM To: Manjeet Soodan Cc: Syed, Mohammad Rafi; sip@ietf.org Subject: Re: [Sip] Query about '491 response' in case of RE-INVITE. Manjeet, Sorry that my prior reply missed the point of what you were asking. Once we havemade the assumption that A has violated 3261, we are in an area of speculation. In general 3261 doesn't specify the proper response to invalid usage. I think your use of 491 might be ok. Lots of other things might also be plausible. Paul Manjeet Soodan wrote: > if we say that this is not the correct behaviour then what should be the > reply from the UAS B, when the 2nd INVITE is send. > > what error code will be a valid response for the 2nd INVITE in this case? > > > -Manjeet > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Friday, November 18, 2005 1:38 AM > To: Syed, Mohammad Rafi > Cc: Manjeet Soodan; sip@ietf.org > Subject: Re: [Sip] Query about '491 response' in case of RE-INVITE. > > > No, this is not correct behavior. There must not be a reinvite until the > initial invite transaction is completed (with a 200 and an ACK). > > If the 180 is sent *reliably* (using the 100rel option) and then > PRACKed, then there is an early dialog and A may send an UPDATE. That is > as close as you can get to the functionality of a reinvite before the > initial invite is present. > > Paul > > Syed, Mohammad Rafi wrote: > >>This is right behaviour as Offer recvd at UA-B in the initial INVITE is > > still not replied with an answer(either in 18X if reliable is used or 200OK > with SDP). > >>A B >>----INVITEOffer1----> >><------answer1----(18X with SDP if reliable or 200 OK with SDP) >> >> >>-Rafi. >> >>-----Original Message----- >>From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of >>Manjeet Soodan >>Sent: Thursday, November 17, 2005 1:58 PM >>To: sip@ietf.org >>Subject: [Sip] Query about '491 response' in case of RE-INVITE. >> >> >>1) There are two SIP UA's A and B. >>2) A sends INVITE with SDP to B. >>3) B responds with 100 and then 180 Ringing(wthout SDP) and adds TO tag > > to > >>180. >>3) After 180 is received, A sends a RE-INVITE before 200 OK is received >>(i.e RE-INVITE with all the headers having same value as initial INVITE > > and > >>higher CSEQ value). >>4) In this case B responds with a '491 Request Pending' for RE-INVITE. >> >>Is it the right behaviour, if not then what should be the right behaviour > > of > >>B? >> >> >>-Manjeet >> >> >> >>_______________________________________________ >>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 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 From sip-bounces@ietf.org Fri Nov 18 11:18:14 2005 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 1Ed8wI-0000Uj-1j; Fri, 18 Nov 2005 11:18:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed8wG-0000Md-8D for sip@megatron.ietf.org; Fri, 18 Nov 2005 11:18:12 -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 LAA26642 for ; Fri, 18 Nov 2005 11:17:37 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ed9E6-0005D4-SB for sip@ietf.org; Fri, 18 Nov 2005 11:36:40 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 18 Nov 2005 08:18:00 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jAIGHxCN001591; Fri, 18 Nov 2005 08:18:00 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 18 Nov 2005 11:17:50 -0500 Received: from [10.86.243.40] ([10.86.243.40]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 18 Nov 2005 11:17:50 -0500 Message-ID: <437DFEAD.40809@cisco.com> Date: Fri, 18 Nov 2005 11:17:49 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Manjeet Soodan Subject: Re: [Sip] Query about '491 response' in case of RE-INVITE. References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Nov 2005 16:17:50.0448 (UTC) FILETIME=[9F0C2700:01C5EC5B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Manjeet Soodan wrote: > paul, > > just last question, can we send '180 Ringing' as a response in this case for > the 2nd INVITE, and would 180 be a valid response in this case.? > > We are having a big discussion over this? The entire call flow is invalid from the time that A sent the reinvite, because a reinvite is not allowed in that state. So it is impossible to say what response to it is "valid". All you can do is conjecture what kind of response will have the most satisfactory result. But you are guessing about how a broken UA (A) will respond, and there is no general way to know that. You can send any final error response to the reinvite, and then send an error response to the initial invite as well to indicate your displeasure. Or you can just reject the reinvite and hope for the best. I can't find any error responses that are really appropriate for this situation. The 491 you suggest seems at least as good as any other for the reinvite. If you then want to reject the original invite as well because of concern that the caller is broken, there is again no obviously appropriate status to use. I think I might use 487 in that case. Paul > -Manjeet > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Friday, November 18, 2005 7:21 PM > To: Manjeet Soodan > Cc: Syed, Mohammad Rafi; sip@ietf.org > Subject: Re: [Sip] Query about '491 response' in case of RE-INVITE. > > > Manjeet, > > Sorry that my prior reply missed the point of what you were asking. Once > we havemade the assumption that A has violated 3261, we are in an area > of speculation. In general 3261 doesn't specify the proper response to > invalid usage. I think your use of 491 might be ok. Lots of other things > might also be plausible. > > Paul > > Manjeet Soodan wrote: > >>if we say that this is not the correct behaviour then what should be the >>reply from the UAS B, when the 2nd INVITE is send. >> >>what error code will be a valid response for the 2nd INVITE in this case? >> >> >>-Manjeet >> >>-----Original Message----- >>From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>Sent: Friday, November 18, 2005 1:38 AM >>To: Syed, Mohammad Rafi >>Cc: Manjeet Soodan; sip@ietf.org >>Subject: Re: [Sip] Query about '491 response' in case of RE-INVITE. >> >> >>No, this is not correct behavior. There must not be a reinvite until the >>initial invite transaction is completed (with a 200 and an ACK). >> >>If the 180 is sent *reliably* (using the 100rel option) and then >>PRACKed, then there is an early dialog and A may send an UPDATE. That is >>as close as you can get to the functionality of a reinvite before the >>initial invite is present. >> >> Paul >> >>Syed, Mohammad Rafi wrote: >> >> >>>This is right behaviour as Offer recvd at UA-B in the initial INVITE is >> >>still not replied with an answer(either in 18X if reliable is used or > > 200OK > >>with SDP). >> >> >>>A B >>>----INVITEOffer1----> >>><------answer1----(18X with SDP if reliable or 200 OK with SDP) >>> >>> >>>-Rafi. >>> >>>-----Original Message----- >>>From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of >>>Manjeet Soodan >>>Sent: Thursday, November 17, 2005 1:58 PM >>>To: sip@ietf.org >>>Subject: [Sip] Query about '491 response' in case of RE-INVITE. >>> >>> >>>1) There are two SIP UA's A and B. >>>2) A sends INVITE with SDP to B. >>>3) B responds with 100 and then 180 Ringing(wthout SDP) and adds TO tag >> >>to >> >> >>>180. >>>3) After 180 is received, A sends a RE-INVITE before 200 OK is received >>>(i.e RE-INVITE with all the headers having same value as initial INVITE >> >>and >> >> >>>higher CSEQ value). >>>4) In this case B responds with a '491 Request Pending' for RE-INVITE. >>> >>>Is it the right behaviour, if not then what should be the right behaviour >> >>of >> >> >>>B? >>> >>> >>>-Manjeet >>> >>> >>> >>>_______________________________________________ >>>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 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 From sip-bounces@ietf.org Fri Nov 18 16:01:50 2005 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 1EdDMk-0000J3-C5; Fri, 18 Nov 2005 16:01:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdDMi-0000Ip-1M for sip@megatron.ietf.org; Fri, 18 Nov 2005 16:01:48 -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 QAA10385 for ; Fri, 18 Nov 2005 16:01:12 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EdDeb-0003l9-PL for sip@ietf.org; Fri, 18 Nov 2005 16:20:19 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 18 Nov 2005 13:01:37 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jAIL1Ieg003400 for ; Fri, 18 Nov 2005 13:01:35 -0800 (PST) Received: from xmb-sjc-21d.amer.cisco.com ([171.70.151.140]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 18 Nov 2005 13:01:32 -0800 Received: from [64.101.149.214] ([64.101.149.214]) by xmb-sjc-21d.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 18 Nov 2005 13:01:31 -0800 Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: Sip From: Dean Willis Date: Fri, 18 Nov 2005 15:01:39 -0600 X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 18 Nov 2005 21:01:31.0904 (UTC) FILETIME=[40A03800:01C5EC83] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Subject: [Sip] Problems with Mail from Softarmor to Nortel X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I'd like to apologize to the community for any confusion that may have resulted from an operational problem. Recently I thought I'd been having lots of conversations with Francois and Mary and others from Nortel, as well as lots of folks from other shops, about reason and History-Info and whatnot. But it seems that Nortel.com started filtering all email from my server to Nortel around October 19. I presume the Nortel folks have been getting most of what I had to say via the mailing list, but I suspect some stuff got lost in the mixup. I would ordinarily have noticed this sooner, but had implemented a filter to divert "mailer errors" to a folder due to the huge flood of "hello.exe" bounce spam related to sobig and other worms. And I got lazy about looking in that folder. Today I looked, and was horrified to see dozens of bounce messages from Nortel. So if the conversation about Reason, and History, and Voicemail URI has seemed particularly confusing to some of you, it may well be because of this error, and I apologize. I'm also kind of ticked at the mail admins at Nortel, I might add. But these things do happen from time to time. I just found my spam filter was blocking mail from Henry, so I guess I shouldn't throw too many stones. -- Dean _______________________________________________ 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 From sip-bounces@ietf.org Fri Nov 18 16:04:42 2005 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 1EdDPW-0000sT-6K; Fri, 18 Nov 2005 16:04:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdDPU-0000sM-Jd for sip@megatron.ietf.org; Fri, 18 Nov 2005 16:04:40 -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 QAA10583 for ; Fri, 18 Nov 2005 16:04:04 -0500 (EST) Received: from mail.pingtel.com ([65.220.123.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EdDhM-0003ql-0o for sip@ietf.org; Fri, 18 Nov 2005 16:23:11 -0500 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id 839A06C01C for ; Fri, 18 Nov 2005 16:04:24 -0500 (EST) Subject: Re: [Sip] 3xx response for a re-Invite ? From: "Dale R. Worley" To: Sip In-Reply-To: References: Content-Type: text/plain Date: Fri, 18 Nov 2005 16:04:24 -0500 Message-Id: <1132347864.29385.7.camel@cdhcp139.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-6) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Fri, 2005-11-18 at 09:19 +0530, Shweta.Kavishwar@flextronicssoftware.com wrote: > I would like to know if it is correct to send a 3xx response for a > re-Invite request. And if so, what could be the possible scenarios. > Also refer the following link which says 3xx to re_INVITE allowed.( IETF > meeting 52 ): > http://www.softarmor.com/sipwg/meets/ietf52/slides/pres-jdrosen-sip-new-bis-ietf52.ppt I don't know if it's officially allowed by RFC 3261, but 3xx responses to in-dialog requests have been mentioned on the mailing lists several times, and nobody has come up with a sensible meaning to assign to them. Once a route-set is established, all one can change in the flow of messages is the contacts on each end, and re-INVITE is defined as the means to do that. So at present, I'd say that 3xx for a re-INVITE is not allowed. Dale _______________________________________________ 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 From sip-bounces@ietf.org Fri Nov 18 18:39:27 2005 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 1EdFpH-0001MP-C0; Fri, 18 Nov 2005 18:39:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdFpG-0001K2-02 for sip@megatron.ietf.org; Fri, 18 Nov 2005 18:39:26 -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 SAA21997 for ; Fri, 18 Nov 2005 18:38:51 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EdG7B-0000VQ-To for sip@ietf.org; Fri, 18 Nov 2005 18:57:58 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 18 Nov 2005 15:39:16 -0800 X-IronPort-AV: i="3.97,348,1125903600"; d="scan'208"; a="232287104:sNHT25983956" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id jAINd8Or006938; Fri, 18 Nov 2005 15:39:11 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 18 Nov 2005 18:39:11 -0500 Received: from [10.242.20.81] ([10.86.240.215]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 18 Nov 2005 18:39:11 -0500 Message-ID: <437E661E.1060305@cisco.com> Date: Fri, 18 Nov 2005 18:39:10 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brett Tate Subject: Re: [Sip] RFC 3261 supported header in 1xx responses References: <000d01c5eadc$de84b170$2c28a8c0@brett1> In-Reply-To: <000d01c5eadc$de84b170$2c28a8c0@brett1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Nov 2005 23:39:11.0660 (UTC) FILETIME=[47146EC0:01C5EC99] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Cc: sip-ietf X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org It makes sense to include them in a dialog forming response. A normal 1xx is not dialog forming. My suspicion (though I didn't check if this was true) is that it went away when 100rel moved out of 3261. It can't hurt to send them, of course, but it would be ignored unless its reliable. -Jonathan R. Brett Tate wrote: > Within early versions of draft-ietf-sip-rfc2543bis, the Supported header > could be expected within 1xx responses. However within > draft-ietf-sip-rfc2543bis-06 it was removed and remains so within RFC 3261. > Is there a reason why it is undesirable to indicate supported extensions > within a 1xx? Or was it just an oversight when changing the "Summary of > header fields" table to indicate 2xx instead of all responses? > > > > > _______________________________________________ > 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 > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ 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 From sip-bounces@ietf.org Fri Nov 18 20:04:27 2005 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 1EdH9X-00076H-T6; Fri, 18 Nov 2005 20:04:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdH9W-000768-4J for sip@megatron.ietf.org; Fri, 18 Nov 2005 20:04:26 -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 UAA25833 for ; Fri, 18 Nov 2005 20:03:50 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EdHRR-0002P3-Vc for sip@ietf.org; Fri, 18 Nov 2005 20:22:59 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 18 Nov 2005 17:04:15 -0800 X-IronPort-AV: i="3.97,348,1125903600"; d="scan'208"; a="232301154:sNHT34814996" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jAJ14DeS026607; Fri, 18 Nov 2005 17:04:13 -0800 (PST) Received: from xmb-sjc-21e.amer.cisco.com ([171.70.151.156]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 18 Nov 2005 17:04:13 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] RFC 3261 supported header in 1xx responses Date: Fri, 18 Nov 2005 17:04:07 -0800 Message-ID: <75B2A84D9323BC4CA3977CF378CE75EBCA41C8@xmb-sjc-21e.amer.cisco.com> Thread-Topic: [Sip] RFC 3261 supported header in 1xx responses Thread-Index: AcXsmYLYTvywZ/7nS8y6rjCv+YbMcgACwABg From: "Arunachalam Venkatraman \(arunvenk\)" To: "Jonathan Rosenberg \(jdrosen\)" , "Brett Tate" X-OriginalArrivalTime: 19 Nov 2005 01:04:13.0199 (UTC) FILETIME=[27D581F0:01C5ECA5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: quoted-printable Cc: sip-ietf X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Can a proxy add Supported? Is this disallowed? If proxy may do so, the Supported cannot be interpreted as UAS capabilities, even if the 1xx is reliable (consider INVITE with Require:100rel). -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Jonathan Rosenberg (jdrosen) Sent: Friday, November 18, 2005 5:39 PM To: Brett Tate Cc: sip-ietf Subject: Re: [Sip] RFC 3261 supported header in 1xx responses It makes sense to include them in a dialog forming response. A normal 1xx is not dialog forming. My suspicion (though I didn't check if this was true) is that it went away when 100rel moved out of 3261. It can't hurt to send them, of course, but it would be ignored unless its reliable. -Jonathan R. Brett Tate wrote: > Within early versions of draft-ietf-sip-rfc2543bis, the Supported=20 > header could be expected within 1xx responses. However within > draft-ietf-sip-rfc2543bis-06 it was removed and remains so within RFC 3261. > Is there a reason why it is undesirable to indicate supported=20 > extensions within a 1xx? Or was it just an oversight when changing=20 > the "Summary of header fields" table to indicate 2xx instead of all responses? >=20 >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > sipping@ietf.org for new developments on the application of sip >=20 --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ 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 From sip-bounces@ietf.org Mon Nov 21 06:52:43 2005 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 1EeADz-0003MF-G9; Mon, 21 Nov 2005 06:52:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeADx-0003M7-9j for sip@megatron.ietf.org; Mon, 21 Nov 2005 06:52:41 -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 GAA23146 for ; Mon, 21 Nov 2005 06:52:02 -0500 (EST) From: priti.sarode@flextronicssoftware.com Received: from delta.hssblr.co.in ([203.145.155.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeAWM-0008KY-0D for sip@ietf.org; Mon, 21 Nov 2005 07:11:44 -0500 Received: from espion.blr.hss.hns.com (espion.blr.hss.hns.com [10.203.193.21]) by delta.hssblr.co.in (8.11.6/8.11.6) with ESMTP id jALBqTx02805; Mon, 21 Nov 2005 17:22:30 +0530 To: Cullen Jennings X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: Date: Mon, 21 Nov 2005 17:18:43 +0530 X-MIMETrack: Serialize by Router on Espion/BLR/HSS(Release 6.5|September 18, 2003) at 11/21/2005 05:38:21 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.5 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: sip@ietf.org, Rohan Mahy Subject: [Sip] pin-route option tag in outbound-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, As per the outbound-01 draft, the pin-route option tag can be used by UAs that do not have a GRUU, in SUBSCRIBE request sent to configuration framework. Can the same tag also be used in SUBSCRIBE request sent to event framework (event- Presence) ? - Priti *********************** FSS-Unclassified *********************** "DISCLAIMER: This message is proprietary to Flextronics Software Systems Limited (FSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." _______________________________________________ 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 From sip-bounces@ietf.org Mon Nov 21 10:00:20 2005 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 1EeD9Y-0000kd-DS; Mon, 21 Nov 2005 10:00:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeD9W-0000kV-LJ for sip@megatron.ietf.org; Mon, 21 Nov 2005 10:00:18 -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 JAA05860 for ; Mon, 21 Nov 2005 09:59:41 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeDRz-0005R1-2W for sip@ietf.org; Mon, 21 Nov 2005 10:19:24 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 21 Nov 2005 07:00:08 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,356,1125903600"; d="scan'208"; a="15678816:sNHT21428826" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jALF06ln012739; Mon, 21 Nov 2005 10:00:06 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 21 Nov 2005 10:00:05 -0500 Received: from [192.168.1.100] ([10.86.242.115]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 21 Nov 2005 10:00:04 -0500 Message-ID: <4381E0F3.9050601@cisco.com> Date: Mon, 21 Nov 2005 10:00:03 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Arunachalam Venkatraman (arunvenk)" Subject: Re: [Sip] RFC 3261 supported header in 1xx responses References: <75B2A84D9323BC4CA3977CF378CE75EBCA41C8@xmb-sjc-21e.amer.cisco.com> In-Reply-To: <75B2A84D9323BC4CA3977CF378CE75EBCA41C8@xmb-sjc-21e.amer.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Nov 2005 15:00:04.0566 (UTC) FILETIME=[41344F60:01C5EEAC] X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit Cc: sip-ietf , Brett Tate X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org If a proxy genreates the 1xx itself, it is effectively acting as a UAS, in which case insertion of Supported is fine. This won't confuse a UAC since any 1xx generated by the proxy itself will have different tags from a 2xx or other responses generated by the actual UA, and thus represent a different (early) dialog. A proxy cannot insert or modify a Supported header in a response that passes by it (i.e., one for which it is proxying). -Jonathan R. Arunachalam Venkatraman (arunvenk) wrote: > Can a proxy add Supported? Is this disallowed? > If proxy may do so, the Supported cannot be interpreted as UAS > capabilities, even if the 1xx is reliable (consider INVITE with > Require:100rel). > > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > Jonathan Rosenberg (jdrosen) > Sent: Friday, November 18, 2005 5:39 PM > To: Brett Tate > Cc: sip-ietf > Subject: Re: [Sip] RFC 3261 supported header in 1xx responses > > It makes sense to include them in a dialog forming response. A normal > 1xx is not dialog forming. My suspicion (though I didn't check if this > was true) is that it went away when 100rel moved out of 3261. It can't > hurt to send them, of course, but it would be ignored unless its > reliable. > > -Jonathan R. > > Brett Tate wrote: > > >>Within early versions of draft-ietf-sip-rfc2543bis, the Supported >>header could be expected within 1xx responses. However within >>draft-ietf-sip-rfc2543bis-06 it was removed and remains so within RFC > > 3261. > >>Is there a reason why it is undesirable to indicate supported >>extensions within a 1xx? Or was it just an oversight when changing >>the "Summary of header fields" table to indicate 2xx instead of all > > responses? > >> >> >> >>_______________________________________________ >>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 >> > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ 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 From sip-bounces@ietf.org Mon Nov 21 10:55:30 2005 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 1EeE0w-0003SF-3u; Mon, 21 Nov 2005 10:55:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeE0u-0003S9-F8 for sip@megatron.ietf.org; Mon, 21 Nov 2005 10:55:28 -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 KAA10579 for ; Mon, 21 Nov 2005 10:54:50 -0500 (EST) Received: from wproxy.gmail.com ([64.233.184.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeEJN-0007LI-3f for sip@ietf.org; Mon, 21 Nov 2005 11:14:34 -0500 Received: by wproxy.gmail.com with SMTP id 58so826296wri for ; Mon, 21 Nov 2005 07:55:23 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=PNjSPjVCtFh9EUPnyDJThy6cxx5zgh8LmVs40nraiN3mpxKlbt/lBAbumGYhsILKco3Elmk93Z7G8o1xsq5NYb6oy4eTYYxc9t4BLWuFXz7ko9NY5VFjjsnPpb58GDy5E6U9V1KL++SLWY1bHB9r7PQCJ0hoU6TNApVNtcHvMkE= Received: by 10.54.131.10 with SMTP id e10mr1282105wrd; Mon, 21 Nov 2005 07:55:23 -0800 (PST) Received: by 10.54.124.13 with HTTP; Mon, 21 Nov 2005 07:55:23 -0800 (PST) Message-ID: <30526bbf0511210755l11d2a0dai9563895c90af147e@mail.gmail.com> Date: Mon, 21 Nov 2005 08:55:23 -0700 From: Ramesh <2ramesh@gmail.com> To: Manjeet Soodan Subject: Re: [Sip] Query about '491 response' in case of RE-INVITE. In-Reply-To: MIME-Version: 1.0 References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1464607052==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============1464607052== Content-Type: multipart/alternative; boundary="----=_Part_36041_20727747.1132588523438" ------=_Part_36041_20727747.1132588523438 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I think it is wrong to send the 491 in this case. 491 response can only be sent by A to B, in your example, if B sends an INVITE to A. A can send multiple Invites as these are nothing but updates to the original. If you look at the ISUP-SIP overlap signaling ( RFC 3578) you will see this scenario described when SAM messages are sent. Cheers Ramesh On 11/17/05, Manjeet Soodan wrote: > > 1) There are two SIP UA's A and B. > 2) A sends INVITE with SDP to B. > 3) B responds with 100 and then 180 Ringing(wthout SDP) and adds TO tag t= o > 180. > 3) After 180 is received, A sends a RE-INVITE before 200 OK is received > (i.e RE-INVITE with all the headers having same value as initial INVITE > and > higher CSEQ value). > 4) In this case B responds with a '491 Request Pending' for RE-INVITE. > > Is it the right behaviour, if not then what should be the right behaviour > of > B? > > > -Manjeet > > > > _______________________________________________ > 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 > -- cheers ramesh ------=_Part_36041_20727747.1132588523438 Content-Type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I think it is wrong to send the 491 in this case. 491 response can only be sent by A to B, in your example, if B sends an INVITE to A. A can send multiple Invites as these are nothing but updates to the original. If you look at the ISUP-SIP overlap signaling ( RFC 3578)  you will see this scenario described when SAM messages are sent.

Cheers
Ramesh

On 11/17/05, Manjeet Soodan <manjeet_soodan@persistent.co.in> wrote: 1) There are two SIP UA's A and B.
2) A sends INVITE with SDP to B.
3= ) B responds with 100 and then 180 Ringing(wthout SDP)  and adds = TO tag to
180.
3) After 180 is received, A sends a  RE-INVI= TE before 200 OK is received
(i.e RE-INVITE with all the headers having same value as initial INVITE= and
higher CSEQ value).
4) In this case B responds with a  = ;'491 Request Pending' for RE-INVITE.

Is it the right behaviour, if = not then what should be the right behaviour of
B?


-Manjeet



_________________________________= ______________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sipThis list is for NEW development of the core SIP Protocol
Use sip-implementor= s@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the applica= tion of sip



--
cheers
ramesh ------=_Part_36041_20727747.1132588523438-- --===============1464607052== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1464607052==-- From sip-bounces@ietf.org Mon Nov 21 11:04:36 2005 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 1EeE9k-0005bl-Rt; Mon, 21 Nov 2005 11:04:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeE9h-0005bX-0S for sip@megatron.ietf.org; Mon, 21 Nov 2005 11:04:34 -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 LAA11174 for ; Mon, 21 Nov 2005 11:03:55 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeESA-0007bo-Kt for sip@ietf.org; Mon, 21 Nov 2005 11:23:39 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 21 Nov 2005 08:04:23 -0800 X-IronPort-AV: i="3.97,357,1125903600"; d="scan'208,217"; a="368172536:sNHT38843898" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jALG48sC012076; Mon, 21 Nov 2005 08:04:21 -0800 (PST) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 21 Nov 2005 11:03:54 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] Query about '491 response' in case of RE-INVITE. Date: Mon, 21 Nov 2005 11:03:53 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3CD0926@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Sip] Query about '491 response' in case of RE-INVITE. Thread-Index: AcXutGY168eJhpP7QWGy3VI7qlEltQAAJG9Q From: "Michael Hammer \(mhammer\)" To: "Ramesh" <2ramesh@gmail.com>, "Manjeet Soodan" X-OriginalArrivalTime: 21 Nov 2005 16:03:54.0610 (UTC) FILETIME=[2C16A520:01C5EEB5] X-Spam-Score: 3.2 (+++) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0944552816==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0944552816== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5EEB5.2BE95565" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5EEB5.2BE95565 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ramesh, =20 Be very carerful with the overlap signaling. In fact, the subsequent INVITEs that A sends are each new dialogs, with each old previous dialog being later rejected. They are not updates to the same dialog. =20 Mike =20 ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Ramesh Sent: Monday, November 21, 2005 10:55 AM To: Manjeet Soodan Cc: sip@ietf.org Subject: Re: [Sip] Query about '491 response' in case of RE-INVITE. =09 =09 I think it is wrong to send the 491 in this case. 491 response can only be sent by A to B, in your example, if B sends an INVITE to A. A can send multiple Invites as these are nothing but updates to the original. If you look at the ISUP-SIP overlap signaling ( RFC 3578) you will see this scenario described when SAM messages are sent. =09 Cheers Ramesh =09 =09 On 11/17/05, Manjeet Soodan wrote:=20 1) There are two SIP UA's A and B. 2) A sends INVITE with SDP to B. 3) B responds with 100 and then 180 Ringing(wthout SDP) and adds TO tag to 180. 3) After 180 is received, A sends a RE-INVITE before 200 OK is received=20 (i.e RE-INVITE with all the headers having same value as initial INVITE and higher CSEQ value). 4) In this case B responds with a '491 Request Pending' for RE-INVITE. =09 Is it the right behaviour, if not then what should be the right behaviour of=20 B? =09 =09 -Manjeet =09 =09 =09 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol=20 Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip=20 =09 --=20 cheers ramesh=20 ------_=_NextPart_001_01C5EEB5.2BE95565 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Ramesh,
 
Be very carerful with the overlap signaling.  In = fact, the=20 subsequent INVITEs that A sends are each new dialogs, with each old = previous=20 dialog being later rejected.  They are not updates to the same=20 dialog.
 
Mike
 

From: sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org] On Behalf Of = Ramesh
Sent:=20 Monday, November 21, 2005 10:55 AM
To: Manjeet = Soodan
Cc:=20 sip@ietf.org
Subject: Re: [Sip] Query about '491 response' = in case=20 of RE-INVITE.

I think it is wrong to send the 491 in this case. 491 = response can=20 only be sent by A to B, in your example, if B sends an INVITE to A. A = can send=20 multiple Invites as these are nothing but updates to the original. If = you look=20 at the ISUP-SIP overlap signaling ( RFC 3578)  you will see this = scenario=20 described when SAM messages are sent.

Cheers
Ramesh

On 11/17/05, Manjeet=20 Soodan <manjeet_soodan@persistent= .co.in>=20 wrote:
1)=20 There are two SIP UA's A and B.
2) A sends INVITE with SDP to = B.
3) B=20 responds with 100 and then 180 Ringing(wthout SDP)  and = adds TO=20 tag to
180.
3) After 180 is received, A sends = a  RE-INVITE=20 before 200 OK is received
(i.e RE-INVITE with all the headers = having=20 same value as initial INVITE and
higher CSEQ value).
4) In = this case B=20 responds with a  '491 Request Pending' for = RE-INVITE.

Is it=20 the right behaviour, if not then what should be the right behaviour = of=20 =
B?


-Manjeet



_______________________________= ________________
Sip=20 mailing list  https://www1.ietf.org= /mailman/listinfo/sip
This=20 list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.colu= mbia.edu=20 for questions on current sip
Use sipping@ietf.org for new = developments on=20 the application of sip



--=20
cheers
ramesh ------_=_NextPart_001_01C5EEB5.2BE95565-- --===============0944552816== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============0944552816==-- From sip-bounces@ietf.org Mon Nov 21 11:25:08 2005 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 1EeETc-0003Lw-LU; Mon, 21 Nov 2005 11:25:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeETa-0003Lm-NK for sip@megatron.ietf.org; Mon, 21 Nov 2005 11:25:06 -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 LAA12276 for ; Mon, 21 Nov 2005 11:24:29 -0500 (EST) Received: from web52801.mail.yahoo.com ([206.190.48.244]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EeElx-00088Q-9J for sip@ietf.org; Mon, 21 Nov 2005 11:44:13 -0500 Received: (qmail 72530 invoked by uid 60001); 21 Nov 2005 16:24:49 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=WQoPDoIbydCLLBM3dpNLE/P8HmfWxcbMhGv6Uy0Wqrolv+SnsP+csu41au/uH9yfRIuSqU+v5Cs1zQIxD4iQGIlegjmcIo7PiMKfePRckDot11ky/pTGyHx6Qde+7ZdWcmps9jkeTdnlAM3SiX/hziF2lnOHUo4ncQceG9oUy44= ; Message-ID: <20051121162449.72528.qmail@web52801.mail.yahoo.com> Received: from [47.165.150.254] by web52801.mail.yahoo.com via HTTP; Mon, 21 Nov 2005 08:24:49 PST Date: Mon, 21 Nov 2005 08:24:49 -0800 (PST) From: Fatih "Eyüp" NAR Subject: RE: [Sip] Query about '491 response' in case of RE-INVITE. To: "Michael Hammer \(mhammer\)" , Ramesh <2ramesh@gmail.com>, Manjeet Soodan In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3CD0926@xmb-rtp-20b.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Content-Transfer-Encoding: 8bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org I think that using re-invite for the sessions that are not completed (i.e. 200 ok not received) do not make sense , instead usage of UPDATE more appropriate ... --- "Michael Hammer (mhammer)" wrote: > Ramesh, > > Be very carerful with the overlap signaling. In > fact, the subsequent > INVITEs that A sends are each new dialogs, with each > old previous dialog > being later rejected. They are not updates to the > same dialog. > > Mike > > > > ________________________________ > > From: sip-bounces@ietf.org > [mailto:sip-bounces@ietf.org] On > Behalf Of Ramesh > Sent: Monday, November 21, 2005 10:55 AM > To: Manjeet Soodan > Cc: sip@ietf.org > Subject: Re: [Sip] Query about '491 response' in > case of > RE-INVITE. > > > I think it is wrong to send the 491 in this case. > 491 response > can only be sent by A to B, in your example, if B > sends an INVITE to A. > A can send multiple Invites as these are nothing but > updates to the > original. If you look at the ISUP-SIP overlap > signaling ( RFC 3578) you > will see this scenario described when SAM messages > are sent. > > Cheers > Ramesh > > > On 11/17/05, Manjeet Soodan > > wrote: > > 1) There are two SIP UA's A and B. > 2) A sends INVITE with SDP to B. > 3) B responds with 100 and then 180 Ringing(wthout > SDP) > and adds TO tag to > 180. > 3) After 180 is received, A sends a RE-INVITE > before > 200 OK is received > (i.e RE-INVITE with all the headers having same > value as > initial INVITE and > higher CSEQ value). > 4) In this case B responds with a '491 Request > Pending' > for RE-INVITE. > > Is it the right behaviour, if not then what should > be > the right behaviour of > B? > > > -Manjeet > > > > _______________________________________________ > 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 > > > > > > -- > cheers > ramesh > > > _______________________________________________ > 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 __________________________________ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.com _______________________________________________ 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 From sip-bounces@ietf.org Mon Nov 21 11:48:20 2005 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 1EeEq4-0000IM-Nf; Mon, 21 Nov 2005 11:48:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeEq0-0000HW-Rv for sip@megatron.ietf.org; Mon, 21 Nov 2005 11:48:18 -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 LAA13725 for ; Mon, 21 Nov 2005 11:47:39 -0500 (EST) Received: from wproxy.gmail.com ([64.233.184.201]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeF8U-0000Mb-4G for sip@ietf.org; Mon, 21 Nov 2005 12:07:23 -0500 Received: by wproxy.gmail.com with SMTP id 58so839165wri for ; Mon, 21 Nov 2005 08:48:14 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=qWGqwqRDhFJE8qwQTNFA+S/aZVp8hQbFLWEeW584D8LHF5uK/c/6QxJcOwASg5a7Pir0pWEXTMBvRK+ARJ05vjLxejjcQvvI+stCayouXoItr56SVqOMMve1Dm5Y2wTzZG2VHPRQmj3nECAKRrAQYyaOC9mL3oZl65kLZdhm4no= Received: by 10.54.78.19 with SMTP id a19mr1204933wrb; Mon, 21 Nov 2005 08:48:12 -0800 (PST) Received: by 10.54.124.13 with HTTP; Mon, 21 Nov 2005 08:48:12 -0800 (PST) Message-ID: <30526bbf0511210848x290c2802ta223ebe7d3447df7@mail.gmail.com> Date: Mon, 21 Nov 2005 09:48:12 -0700 From: Ramesh <2ramesh@gmail.com> To: =?ISO-8859-1?Q?Fatih_Ey=FCp_NAR?= Subject: Re: [Sip] Query about '491 response' in case of RE-INVITE. In-Reply-To: <20051121162449.72528.qmail@web52801.mail.yahoo.com> MIME-Version: 1.0 References: <072C5B76F7CEAB488172C6F64B30B5E3CD0926@xmb-rtp-20b.amer.cisco.com> <20051121162449.72528.qmail@web52801.mail.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0140903238==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============0140903238== Content-Type: multipart/alternative; boundary="----=_Part_37053_16481167.1132591692249" ------=_Part_37053_16481167.1132591692249 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable There are issues with update. You will really not know if "UPDATE" is supported until response other than trying is made. So the only method that you can use is INVITE. Here in this perticular interop scenario the initial invite did not have the complete routable information so the subsequent invites will update the number. As Mr. Hammer pointed out the invites that were send need to be acked. I don't know with what error messag they will be acked. Ramesh On 11/21/05, Fatih Ey=FCp NAR wrote: > > I think that using re-invite for the sessions that are > not completed (i.e. 200 ok not received) do not make > sense , instead usage of UPDATE more appropriate ... > > > --- "Michael Hammer (mhammer)" > wrote: > > > Ramesh, > > > > Be very carerful with the overlap signaling. In > > fact, the subsequent > > INVITEs that A sends are each new dialogs, with each > > old previous dialog > > being later rejected. They are not updates to the > > same dialog. > > > > Mike > > > > > > > > ________________________________ > > ------=_Part_37053_16481167.1132591692249 Content-Type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable There are issues with update. You will really not know if "UPDATE"= ; is supported until response other than trying is made. So the only method that you can use is INVITE. Here in this perticular interop scenario the initial invite did not have the complete routable information so the subsequent invites will update the number.
  As Mr. Hammer pointed out the invites that were send need to be acked. I don't know with what error messag they will be acked.

Ramesh

On 11/21/05, Fatih Ey=FCp NAR <= fenar@yahoo.com> wrote:
I think that using re-invite for the sessions that are
not completed (i.= e. 200 ok not received) do not make
sense , instead usage of UPDATE more= appropriate ...


--- "Michael Hammer (mhammer)" < mhammer@cisco.com>
wrote:
> Ramesh,
>
> Be very carerful with the overlap signali= ng.  In
> fact, the subsequent
> INVITEs that A sends= are each new dialogs, with each
> old previous dialog
> being later rejected.  They = are not updates to the
> same dialog.
>
> Mike
>>
>
> ________________________________

------=_Part_37053_16481167.1132591692249-- --===============0140903238== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============0140903238==-- From sip-bounces@ietf.org Tue Nov 22 04:36:12 2005 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 1EeUZQ-0006NC-DK; Tue, 22 Nov 2005 04:36:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeUZO-0006LS-E0 for sip@megatron.ietf.org; Tue, 22 Nov 2005 04:36:10 -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 EAA22789 for ; Tue, 22 Nov 2005 04:35:32 -0500 (EST) Received: from [202.54.64.17] (helo=hclnpd.hclt-ntl.co.in) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeUs0-0008Oc-DA for sip@ietf.org; Tue, 22 Nov 2005 04:55:25 -0500 Received: from npd-mail1.hclt-ntl.co.in ([10.105.1.106]) by hclnpd.hclt-ntl.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id WFGCLYCM; Tue, 22 Nov 2005 15:05:50 +0530 Content-Class: urn:content-classes:message X-MessageTextProcessor: DisclaimIt (2.50.252) [HCL Technologies Ltd., Chennai, India] Received: from npd-mail.hclt-ntl.co.in ([10.105.1.104]) by npd-mail1.hclt-ntl.co.in with Microsoft SMTPSVC(5.0.2195.6713); Tue, 22 Nov 2005 15:05:49 +0530 Received: by npd-mail.hclt-ntl.co.in with Internet Mail Service (5.5.2657.72) id ; Tue, 22 Nov 2005 15:05:49 +0530 Message-ID: <4B1D6623CCBD79489DE28D1CA062A47E01661A61@npd-mail.hclt-ntl.co.in> From: "Karthik Kamaraj - NPD, Chennai" Content-Transfer-Encoding: quoted-printable To: Date: Tue, 22 Nov 2005 15:05:48 +0530 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 22 Nov 2005 09:35:49.0994 (UTC) FILETIME=[1FC9F4A0:01C5EF48] X-Spam-Score: 0.3 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: quoted-printable Subject: [Sip] Regarding Registrar behaviour in GRUU draft X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > Hi, > I have one more doubt regarding this.Suppose Consider a case > where UA Sends REGISTER request with Supported header has option tag = as > "gruu" and two Contact header one has "+sip.instance" header param = another > doesn't have it. > I want to know the behaviour of registrar in this case. > Thanks in advance, > Karthik >=20 > -----Original Message----- > From: Karthik Kamaraj - NPD, Chennai =20 > Sent: Friday, November 18, 2005 8:46 PM > To: 'sip-bounces@ietf.org' > Subject: Regarding Registrar behaviour in GRUU draft >=20 > Hi, > Section in draft-ietf-sip-gruu-06 states that "As the > registrar is processing the contacts in the REGISTER request = according > to the procedures of step 7 in Section 10.3 of RFC 3261, > the registrar checks whether each Contact header field in > the REGISTER message contains a "+sip.instance" header field = parameter.If > present, the contact is processed further. " >=20 > I want to know the behaviour of Registrar if it received > REGISTER request with Supported header has option tag as "gruu", but > Contact header doesn't have "+sip.instance" header parameter.=20 >=20 > Thanks, > Karthik=20 >=20 Disclaimer: This message and any attachment(s) contained here are information that = is confidential, proprietary to HCL Technologies and its customers, = privileged or otherwise protected by law. The information is solely = intended for the individual or the entity it is addressed to. If you are = not the intended recipient of this message, you are not authorized to = read, forward, print, retain, copy or disseminate this message or any = part of it. If you have received this e-mail in error, please notify the = sender immediately by return e-mail and delete it from your computer. _______________________________________________ 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 From sip-bounces@ietf.org Tue Nov 22 07:54:22 2005 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 1EeXfC-0000P8-9S; Tue, 22 Nov 2005 07:54:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeXfA-0000Oh-OZ for sip@megatron.ietf.org; Tue, 22 Nov 2005 07:54:20 -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 HAA13296 for ; Tue, 22 Nov 2005 07:53:41 -0500 (EST) From: ramakrishna.adukuri@wipro.com Received: from wip-ec-wd.wipro.com ([203.91.193.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeXxl-0001NS-QI for sip@ietf.org; Tue, 22 Nov 2005 08:13:37 -0500 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id E73EF2062E for ; Tue, 22 Nov 2005 18:10:49 +0530 (IST) Received: from blr-ec-bh01.wipro.com (blr-ec-bh01.wipro.com [10.201.50.91]) by wip-ec-wd.wipro.com (Postfix) with ESMTP id CC8B12063D for ; Tue, 22 Nov 2005 18:10:49 +0530 (IST) Received: from BLR-EC-MBX04.wipro.com ([10.201.50.165]) by blr-ec-bh01.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Nov 2005 18:23:52 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] RFC 3261 supported header in 1xx responses Date: Tue, 22 Nov 2005 18:23:50 +0530 Message-ID: Thread-Topic: [Sip] RFC 3261 supported header in 1xx responses Thread-Index: AcXurPBqxASv71SbS2i9BgXUE1D2lwAsySBA To: , X-OriginalArrivalTime: 22 Nov 2005 12:53:52.0603 (UTC) FILETIME=[CA6032B0:01C5EF63] X-Spam-Score: 0.3 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org, brett@broadsoft.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Is this different for 'Require', because in the case of session timers proxy can add a 'Require' to request/response depending on UAC/UAS not supporting session timers.=20 -Ramakrishna -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Jonathan Rosenberg Sent: Monday, November 21, 2005 8:30 PM To: Arunachalam Venkatraman (arunvenk) Cc: sip-ietf; Brett Tate Subject: Re: [Sip] RFC 3261 supported header in 1xx responses If a proxy genreates the 1xx itself, it is effectively acting as a UAS, in which case insertion of Supported is fine. This won't confuse a UAC since any 1xx generated by the proxy itself will have different tags from a 2xx or other responses generated by the actual UA, and thus represent a different (early) dialog. A proxy cannot insert or modify a Supported header in a response that passes by it (i.e., one for which it is proxying). -Jonathan R. Arunachalam Venkatraman (arunvenk) wrote: > Can a proxy add Supported? Is this disallowed? > If proxy may do so, the Supported cannot be interpreted as UAS=20 > capabilities, even if the 1xx is reliable (consider INVITE with=20 > Require:100rel). >=20 > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of=20 > Jonathan Rosenberg (jdrosen) > Sent: Friday, November 18, 2005 5:39 PM > To: Brett Tate > Cc: sip-ietf > Subject: Re: [Sip] RFC 3261 supported header in 1xx responses >=20 > It makes sense to include them in a dialog forming response. A normal=20 > 1xx is not dialog forming. My suspicion (though I didn't check if this > was true) is that it went away when 100rel moved out of 3261. It can't > hurt to send them, of course, but it would be ignored unless its=20 > reliable. >=20 > -Jonathan R. >=20 > Brett Tate wrote: >=20 >=20 >>Within early versions of draft-ietf-sip-rfc2543bis, the Supported=20 >>header could be expected within 1xx responses. However within >>draft-ietf-sip-rfc2543bis-06 it was removed and remains so within RFC >=20 > 3261. >=20 >>Is there a reason why it is undesirable to indicate supported=20 >>extensions within a 1xx? Or was it just an oversight when changing=20 >>the "Summary of header fields" table to indicate 2xx instead of all >=20 > responses? >=20 >> >> >> >>_______________________________________________ >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>This list is for NEW development of the core SIP Protocol Use=20 >>sip-implementors@cs.columbia.edu for questions on current sip Use=20 >>sipping@ietf.org for new developments on the application of sip >> >=20 >=20 --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ 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 From sip-bounces@ietf.org Tue Nov 22 08:41:07 2005 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 1EeYOR-000333-Qv; Tue, 22 Nov 2005 08:41:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeYOP-00032v-VC for sip@megatron.ietf.org; Tue, 22 Nov 2005 08:41:06 -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 IAA18125 for ; Tue, 22 Nov 2005 08:40:26 -0500 (EST) Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeYh3-0003np-6l for sip@ietf.org; Tue, 22 Nov 2005 09:00:23 -0500 Received: from eamrcnt751.exu.ericsson.se (eamrcnt751.exu.ericsson.se [138.85.133.52]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id jAMDerRJ032230; Tue, 22 Nov 2005 07:40:53 -0600 Received: by eamrcnt751.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Tue, 22 Nov 2005 07:40:53 -0600 Message-ID: From: "George Foti (QA/EMC)" To: "'jdrosen@cisco.com'" , "'sip@ietf.org'" Date: Tue, 22 Nov 2005 07:41:02 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.1 (/) X-Scan-Signature: 841b5d6ad57042632519d2198f34cc8d Cc: Subject: [Sip] Doubts about Handling of RR in GRUU X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0947157542==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0947157542== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5EF6A.60D64D5A" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C5EF6A.60D64D5A Content-Type: text/plain Hi, I have a question on the GRUU draft when it comes to Record Routing. I am not sure if the desired result, as depicted in the draft can be achieved with the current description. The draft talks about the edge proxy removing itself from the RR of responses both at the originating domain and terminating domain with the desired result being as quoted from the spec: " Removing its Record-Route value from the response will result in the route set being seen differently by the caller and callee; the callee (which is the user agent in the figure) will have a route set entry for its edge proxy, while the caller will not. The caller will have a route set entry for its edge proxy, while the callee will not." Lets take an example to see where the problem is as far as the description in the draft is concerned So lets take the following case: UE1--- HP1------EP1..........................HP2------EP2---------UE2 Both UE1, and UE2 acquired GRUUs, and both EP1 & EP2 are in the path for their subsequent UEs when they REGISTER. If UE1 initiates an INVITE and all proxies insert themselves in the RR, so we have the RR arriving at UE2 having EP2, HP1, EP1, HP1. Then according to the draft both EP2, and EP1 should remove themselves from the response to the INVITE. So, if UE2 returns a 200 OK with the RR, EP2 removes itself, and EP1 removes itself as well. So UE1 sees a RR including HP1,HP2, and that the route set it has While UE2 have a route set entry that includes all 4 proxies, EP2, HP1, EP1, HP1. Am I misinterpreting the spec? Rgds/gf Ericsson Canada ------_=_NextPart_001_01C5EF6A.60D64D5A Content-Type: text/html Content-Transfer-Encoding: quoted-printable

Hi,

 

I have a question = on the GRUU draft when it comes to Record Routing. =

I am not sure if = the desired result, as depicted in the draft can be achieved with the current = description.

The draft talks = about the edge proxy removing itself from the RR of responses both at the = originating domain and terminating domain with the desired result being as quoted = from the spec:

 

"
Removing =
its Record-Route value from the response will result in =
the
   route set being seen =
differently by the caller and callee; the =
callee
 =
  (which is the user agent in the figure) will have a route =
set entry
   for its edge proxy, while the =
caller will not.  The caller will =
have
   a route set entry for its edge =
proxy, while the callee will not."

 

Lets take an = example to see where the problem is as far as the

description in the = draft is concerned So lets take the following case:

 

 UE1--- HP1------EP1..........................HP2------EP2---------UE2

 

 Both UE1, = and UE2 acquired GRUUs, and both EP1 & EP2 are in the path =

 for their = subsequent UEs when they REGISTER.

 

If UE1 initiates = an INVITE and all proxies insert themselves in

the RR, so we have = the RR arriving at UE2 having EP2, HP1, EP1, HP1.

  =

Then according to = the draft both EP2, and EP1 should remove themselves

from the response = to the INVITE.

So, if UE2 returns = a 200 OK with the RR, EP2 removes itself, and EP1 removes itself as = well.

So UE1 sees a RR = including HP1,HP2, and that the route set it has

While UE2 have a = route set entry that includes all 4 proxies, EP2, HP1, EP1, = HP1.

 

Am I = misinterpreting the spec?

 

Rgds/gf

Ericsson = Canada

 

------_=_NextPart_001_01C5EF6A.60D64D5A-- --===============0947157542== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============0947157542==-- From sip-bounces@ietf.org Tue Nov 22 09:14:39 2005 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 1EeYut-0001lA-9j; Tue, 22 Nov 2005 09:14:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeYur-0001if-1s for sip@megatron.ietf.org; Tue, 22 Nov 2005 09:14: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 JAA21410 for ; Tue, 22 Nov 2005 09:13:57 -0500 (EST) Received: from sonussf1.sonusnet.com ([208.45.178.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeZDV-0005Id-MX for sip@ietf.org; Tue, 22 Nov 2005 09:33:54 -0500 Received: from sonusmail02.sonusnet.com (sonusmail02.sonusnet.com [10.128.32.96]) by sonussf1.sonusnet.com (8.13.3/8.13.3) with ESMTP id jAMEEM7E013038 for ; Tue, 22 Nov 2005 09:14:22 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 22 Nov 2005 09:14:19 -0500 Message-ID: <05AE95C39E8E2642AF9C04526EDAC414B498F0@sonusmail02.sonusnet.com> Thread-Topic: draft-sparks-sip-nit-problems-02 Thread-Index: AcXvbzAQ4u9OETh4TsG3M8glrKISEA== From: "Bharrat, Shaun" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: quoted-printable Subject: [Sip] draft-sparks-sip-nit-problems-02 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi: I lost track of the discussion on problems with the non-INVITE = transaction. The latest draft version I could find has now expired. Can someone = please point me to a email archive, meeting minutes, etc that describes the final outcome or prescription? (I am particularly interested in the = current recommendation on sending provisional responses for the non-INVITE=20 transaction.) Thanks in advance. Cheers, Shaun Bharrat Shaun Bharrat Sonus Networks Nothing witty to say ;-( www.sonusnet.com _______________________________________________ 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 From sip-bounces@ietf.org Tue Nov 22 10:42:17 2005 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 1EeaHh-0008AZ-MY; Tue, 22 Nov 2005 10:42:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeaHf-00089P-Di for sip@megatron.ietf.org; Tue, 22 Nov 2005 10:42:15 -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 KAA01678 for ; Tue, 22 Nov 2005 10:41:37 -0500 (EST) Received: from wproxy.gmail.com ([64.233.184.206]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeaaK-0001Mk-7A for sip@ietf.org; Tue, 22 Nov 2005 11:01:33 -0500 Received: by wproxy.gmail.com with SMTP id 58so1069142wri for ; Tue, 22 Nov 2005 07:42:12 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=Oxd8hq0i2+KddgHMHiqSNNvS8CC3+4J4QOCjuBi4R48Dz15ge7MJ8NdR202QHnx/s7JVMIRmCbmujqko1VPUAjfS/IBzMhLRtdRYX64BuXJjjFvdk0J1UePX4/L6Js45CA+wsXj/Gg6ivKWzW0OHn+ERFI5Y0vkt2zN/gQ5VlXU= Received: by 10.54.81.2 with SMTP id e2mr54772wrb; Tue, 22 Nov 2005 07:42:11 -0800 (PST) Received: by 10.54.124.13 with HTTP; Tue, 22 Nov 2005 07:42:11 -0800 (PST) Message-ID: <30526bbf0511220742n23c974f8sc45fedb312860167@mail.gmail.com> Date: Tue, 22 Nov 2005 08:42:11 -0700 From: Ramesh <2ramesh@gmail.com> To: "Michael Hammer (mhammer)" Subject: Re: [Sip] Query about '491 response' in case of RE-INVITE. In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3CD0926@xmb-rtp-20b.amer.cisco.com> MIME-Version: 1.0 References: <072C5B76F7CEAB488172C6F64B30B5E3CD0926@xmb-rtp-20b.amer.cisco.com> X-Spam-Score: 0.9 (/) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1623284531==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============1623284531== Content-Type: multipart/alternative; boundary="----=_Part_53519_10203487.1132674131238" ------=_Part_53519_10203487.1132674131238 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable What should be the response to close the Invite transaction in case of the subsequent INVITE, would it be 484 address incomplete. It cannot be 200ok. Cheers Ramesh On 11/21/05, Michael Hammer (mhammer) wrote: > > Ramesh, > Be very carerful with the overlap signaling. In fact, the subsequent > INVITEs that A sends are each new dialogs, with each old previous dialog > being later rejected. They are not updates to the same dialog. > Mike > > ------------------------------ > *From:* sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] *On Behalf Of = * > Ramesh > *Sent:* Monday, November 21, 2005 10:55 AM > *To:* Manjeet Soodan > *Cc:* sip@ietf.org > *Subject:* Re: [Sip] Query about '491 response' in case of RE-INVITE. > > I think it is wrong to send the 491 in this case. 491 response can only b= e > sent by A to B, in your example, if B sends an INVITE to A. A can send > multiple Invites as these are nothing but updates to the original. If you > look at the ISUP-SIP overlap signaling ( RFC 3578) you will see this > scenario described when SAM messages are sent. > > Cheers > Ramesh > > On 11/17/05, Manjeet Soodan wrote: > > > > 1) There are two SIP UA's A and B. > > 2) A sends INVITE with SDP to B. > > 3) B responds with 100 and then 180 Ringing(wthout SDP) and adds TO tag > > to > > 180. > > 3) After 180 is received, A sends a RE-INVITE before 200 OK is received > > (i.e RE-INVITE with all the headers having same value as initial INVITE > > and > > higher CSEQ value). > > 4) In this case B responds with a '491 Request Pending' for RE-INVITE. > > > > Is it the right behaviour, if not then what should be the right > > behaviour of > > B? > > > > > > -Manjeet > > > > > > > > _______________________________________________ > > 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 > > > > > > -- > cheers > ramesh > > -- cheers ramesh ------=_Part_53519_10203487.1132674131238 Content-Type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable What should be the response to close the Invite transaction in case of the subsequent INVITE, would it be 484 address incomplete. It cannot be 200ok.

Cheers
Ramesh

On 11/21/05, Michael Hammer (mhammer) <mhammer@cisco.com> wrote:
Ramesh,
 
Be very carerful with the overlap signaling.  In fact, the=20 subsequent INVITEs that A sends are each new dialogs, with each old previou= s=20 dialog being later rejected.  They are not updates to the same=20 dialog.
 
Mike
 

From: sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org]= On Behalf Of Ramesh
Sent:=20 Monday, November 21, 2005 10:55 AM
To: Manjeet Soodan
Cc:= =20 sip@ietf.org
= Subject: Re: [Sip] Query about '491 response' in case=20 of RE-INVITE.

I think it = is wrong to send the 491 in this case. 491 response can=20 only be sent by A to B, in your example, if B sends an INVITE to A. A can= send=20 multiple Invites as these are nothing but updates to the original. If you= look=20 at the ISUP-SIP overlap signaling ( RFC 3578)  you will see this sce= nario=20 described when SAM messages are sent.

Cheers
Ramesh

On 11/17/05, Manjeet=20 Soodan <manjee= t_soodan@persistent.co.in>=20 wrote:
1)=20 There are two SIP UA's A and B.
2) A sends INVITE with SDP to B.
= 3) B=20 responds with 100 and then 180 Ringing(wthout SDP)  and adds = TO=20 tag to
180.
3) After 180 is received, A sends a  RE-INV= ITE=20 before 200 OK is received
(i.e RE-INVITE with all the headers havin= g=20 same value as initial INVITE and
higher CSEQ value).
4) In this c= ase B=20 responds with a  '491 Request Pending' for RE-INVITE.

= Is it=20 the right behaviour, if not then what should be the right behaviour of= =20
B?


-Manjeet



_____________________________= __________________
Sip=20 mailing list  https://www1.ietf.org/mailman/listinfo/sip
This=20 list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu<= /a> =20 for questions on current sip
Use sipping@ietf.org for new developments on=20 the application of sip


--=20
cheers
ramesh



--
cheers
ramesh ------=_Part_53519_10203487.1132674131238-- --===============1623284531== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1623284531==-- From sip-bounces@ietf.org Tue Nov 22 10:58:50 2005 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 1EeaXi-0008EP-1X; Tue, 22 Nov 2005 10:58:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeaXg-0008AP-Mv for sip@megatron.ietf.org; Tue, 22 Nov 2005 10:58:48 -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 KAA04695 for ; Tue, 22 Nov 2005 10:58:10 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeaqM-0002fE-Sb for sip@ietf.org; Tue, 22 Nov 2005 11:18:07 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 22 Nov 2005 10:58:37 -0500 X-IronPort-AV: i="3.97,362,1125892800"; d="scan'208"; a="76311317:sNHT26184996" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jAMFvWeV008898; Tue, 22 Nov 2005 10:58:35 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 22 Nov 2005 10:58:34 -0500 Received: from [161.44.79.90] ([161.44.79.90]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 22 Nov 2005 10:58:34 -0500 Message-ID: <43834029.4060703@cisco.com> Date: Tue, 22 Nov 2005 10:58:33 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Karthik Kamaraj - NPD, Chennai" Subject: Re: [Sip] Regarding Registrar behaviour in GRUU draft References: <4B1D6623CCBD79489DE28D1CA062A47E01661A61@npd-mail.hclt-ntl.co.in> In-Reply-To: <4B1D6623CCBD79489DE28D1CA062A47E01661A61@npd-mail.hclt-ntl.co.in> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Nov 2005 15:58:34.0060 (UTC) FILETIME=[977058C0:01C5EF7D] X-Spam-Score: 0.2 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Karthik Kamaraj - NPD, Chennai wrote: >> Hi, >> I have one more doubt regarding this.Suppose Consider a case >>where UA Sends REGISTER request with Supported header has option tag as >>"gruu" and two Contact header one has "+sip.instance" header param another >>doesn't have it. >> I want to know the behaviour of registrar in this case. >> Thanks in advance, >> Karthik I believe it should return a GRUU for the contact that has an instance parameter, and not for the other one. Paul >> -----Original Message----- >> From: Karthik Kamaraj - NPD, Chennai >> Sent: Friday, November 18, 2005 8:46 PM >> To: 'sip-bounces@ietf.org' >> Subject: Regarding Registrar behaviour in GRUU draft >> >> Hi, >> Section in draft-ietf-sip-gruu-06 states that "As the >>registrar is processing the contacts in the REGISTER request according >>to the procedures of step 7 in Section 10.3 of RFC 3261, >> the registrar checks whether each Contact header field in >>the REGISTER message contains a "+sip.instance" header field parameter.If >>present, the contact is processed further. " >> >> I want to know the behaviour of Registrar if it received >>REGISTER request with Supported header has option tag as "gruu", but >>Contact header doesn't have "+sip.instance" header parameter. >> >> Thanks, >> Karthik >> > > > > Disclaimer: > > This message and any attachment(s) contained here are information that is confidential, proprietary to HCL Technologies and its customers, privileged or otherwise protected by law. The information is solely intended for the individual or the entity it is addressed to. If you are not the intended recipient of this message, you are not authorized to read, forward, print, retain, copy or disseminate this message or any part of it. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete it from your computer. > > _______________________________________________ > 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 From sip-bounces@ietf.org Tue Nov 22 11:09:29 2005 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 1Eeai1-0005nD-8P; Tue, 22 Nov 2005 11:09:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eeahz-0005kk-DH for sip@megatron.ietf.org; Tue, 22 Nov 2005 11:09:27 -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 LAA05876 for ; Tue, 22 Nov 2005 11:08:49 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eeb0f-0003HR-JS for sip@ietf.org; Tue, 22 Nov 2005 11:28:46 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 22 Nov 2005 08:09:17 -0800 X-IronPort-AV: i="3.97,362,1125903600"; d="scan'208,217"; a="233245510:sNHT61871948" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jAMG9As6010230; Tue, 22 Nov 2005 08:09:15 -0800 (PST) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 22 Nov 2005 11:09:06 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] Query about '491 response' in case of RE-INVITE. Date: Tue, 22 Nov 2005 11:09:06 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3CD0C80@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Sip] Query about '491 response' in case of RE-INVITE. Thread-Index: AcXve1aQuhG+u2VqQ6W4RcRuIyCOOwAA66qA From: "Michael Hammer \(mhammer\)" To: "Ramesh" <2ramesh@gmail.com> X-OriginalArrivalTime: 22 Nov 2005 16:09:06.0967 (UTC) FILETIME=[10AE4A70:01C5EF7F] X-Spam-Score: 0.6 (/) X-Scan-Signature: 681e62a2ce9b0804b459fe780d892beb Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1431364459==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1431364459== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5EF7F.1090A31B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5EF7F.1090A31B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I belive you are correct as to 484 being sent. =20 Mike =20 ________________________________ From: Ramesh [mailto:2ramesh@gmail.com]=20 Sent: Tuesday, November 22, 2005 10:42 AM To: Michael Hammer (mhammer) Cc: Manjeet Soodan; sip@ietf.org Subject: Re: [Sip] Query about '491 response' in case of RE-INVITE. =09 =09 What should be the response to close the Invite transaction in case of the subsequent INVITE, would it be 484 address incomplete. It cannot be 200ok. =09 Cheers Ramesh =09 =09 On 11/21/05, Michael Hammer (mhammer) wrote: Ramesh, =20 Be very carerful with the overlap signaling. In fact, the subsequent INVITEs that A sends are each new dialogs, with each old previous dialog being later rejected. They are not updates to the same dialog. =20 Mike =20 ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Ramesh Sent: Monday, November 21, 2005 10:55 AM To: Manjeet Soodan Cc: sip@ietf.org Subject: Re: [Sip] Query about '491 response' in case of RE-INVITE. =09 =09 =09 I think it is wrong to send the 491 in this case. 491 response can only be sent by A to B, in your example, if B sends an INVITE to A. A can send multiple Invites as these are nothing but updates to the original. If you look at the ISUP-SIP overlap signaling ( RFC 3578) you will see this scenario described when SAM messages are sent. =09 Cheers Ramesh =09 =09 On 11/17/05, Manjeet Soodan wrote:=20 1) There are two SIP UA's A and B. 2) A sends INVITE with SDP to B. 3) B responds with 100 and then 180 Ringing(wthout SDP) and adds TO tag to 180. 3) After 180 is received, A sends a RE-INVITE before 200 OK is received=20 (i.e RE-INVITE with all the headers having same value as initial INVITE and higher CSEQ value). 4) In this case B responds with a '491 Request Pending' for RE-INVITE. =09 Is it the right behaviour, if not then what should be the right behaviour of=20 B? =09 =09 -Manjeet =09 =09 =09 =09 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol=20 Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip=20 =09 --=20 cheers ramesh=20 --=20 cheers ramesh=20 ------_=_NextPart_001_01C5EF7F.1090A31B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I belive you are correct as to 484 being = sent.
 
Mike
 

From: Ramesh = [mailto:2ramesh@gmail.com]=20
Sent: Tuesday, November 22, 2005 10:42 AM
To: = Michael=20 Hammer (mhammer)
Cc: Manjeet Soodan; = sip@ietf.org
Subject:=20 Re: [Sip] Query about '491 response' in case of=20 RE-INVITE.

What should be the response to close the Invite transaction = in case=20 of the subsequent INVITE, would it be 484 address incomplete. It = cannot be=20 200ok.

Cheers
Ramesh

On 11/21/05, Michael=20 Hammer (mhammer) <mhammer@cisco.com> = wrote:
Ramesh,
 
Be very=20 carerful with the overlap signaling.  In fact, the subsequent = INVITEs=20 that A sends are each new dialogs, with each old previous dialog = being later=20 rejected.  They are not updates to the same = dialog.
 
Mike
 

From: sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org]=20 On Behalf Of Ramesh
Sent: Monday, November 21, = 2005 10:55=20 AM
To: Manjeet Soodan
Cc: sip@ietf.org
Subject: Re: [Sip] Query about '491 response' = in case=20 of RE-INVITE.

I think it is wrong to send the 491 in this case. 491 = response=20 can only be sent by A to B, in your example, if B sends an INVITE = to A. A=20 can send multiple Invites as these are nothing but updates to the=20 original. If you look at the ISUP-SIP overlap signaling ( RFC = 3578) =20 you will see this scenario described when SAM messages are=20 sent.

Cheers
Ramesh

On 11/17/05, Manjeet Soodan <manjeet_soodan@persistent.co.in> = wrote:=20
1)=20 There are two SIP UA's A and B.
2) A sends INVITE with SDP to = B.
3) B responds with 100 and then 180 Ringing(wthout=20 SDP)  and adds TO tag to
180.
3) After 180 is = received,=20 A sends a  RE-INVITE before 200 OK is received =
(i.e=20 RE-INVITE with all the headers having same value as initial = INVITE=20 and
higher CSEQ value).
4) In this case B responds with=20 a  '491 Request Pending' for RE-INVITE.

Is it = the right=20 behaviour, if not then what should be the right behaviour of=20 =
B?


-Manjeet



_______________________________= ________________
Sip=20 mailing list  https://www1.ietf.org/mailman/listinfo/sip
This=20 list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for = questions on=20 current sip
Use sipping@ietf.org for=20 new developments on the application of sip =


--
cheers
ramesh=20



--=20
cheers
ramesh ------_=_NextPart_001_01C5EF7F.1090A31B-- --===============1431364459== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1431364459==-- From sip-bounces@ietf.org Tue Nov 22 11:18:32 2005 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 1Eeaql-0007r6-Th; Tue, 22 Nov 2005 11:18:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eeaqk-0007pW-1v for sip@megatron.ietf.org; Tue, 22 Nov 2005 11:18:30 -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 LAA07015 for ; Tue, 22 Nov 2005 11:17:51 -0500 (EST) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eeb9O-0003i1-Fs for sip@ietf.org; Tue, 22 Nov 2005 11:37:48 -0500 Received: from ZTCFHXM0.corp.nortel.com (ztcfhxm0.corp.nortel.com [47.10.33.94]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id jAMGIA823432; Tue, 22 Nov 2005 11:18:10 -0500 (EST) Received: from zcarhxs1.corp.nortel.com ([47.129.230.89]) by ZTCFHXM0.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 22 Nov 2005 11:17:17 -0500 Received: from [127.0.0.1] ([47.130.18.39] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 22 Nov 2005 11:17:13 -0500 Message-ID: <43834484.4010601@nortel.com> Date: Tue, 22 Nov 2005 11:17:08 -0500 From: "Tom-PT Taylor" User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ramesh <2ramesh@gmail.com> Subject: Re: [Sip] Query about '491 response' in case of RE-INVITE. References: <072C5B76F7CEAB488172C6F64B30B5E3CD0926@xmb-rtp-20b.amer.cisco.com> <30526bbf0511220742n23c974f8sc45fedb312860167@mail.gmail.com> In-Reply-To: <30526bbf0511220742n23c974f8sc45fedb312860167@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Nov 2005 16:17:13.0259 (UTC) FILETIME=[32888FB0:01C5EF80] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org 484. Ramesh wrote: > What should be the response to close the Invite transaction in case of > the subsequent INVITE, would it be 484 address incomplete. It cannot be > 200ok. > > Cheers > Ramesh > > On 11/21/05, *Michael Hammer (mhammer)* > wrote: > > Ramesh, > > Be very carerful with the overlap signaling. In fact, the > subsequent INVITEs that A sends are each new dialogs, with each old > previous dialog being later rejected. They are not updates to the > same dialog. > > Mike > > > ------------------------------------------------------------------------ > *From:* sip-bounces@ietf.org > [mailto:sip-bounces@ietf.org ] *On > Behalf Of *Ramesh > *Sent:* Monday, November 21, 2005 10:55 AM > *To:* Manjeet Soodan > *Cc:* sip@ietf.org > *Subject:* Re: [Sip] Query about '491 response' in case of > RE-INVITE. > > I think it is wrong to send the 491 in this case. 491 response > can only be sent by A to B, in your example, if B sends an > INVITE to A. A can send multiple Invites as these are nothing > but updates to the original. If you look at the ISUP-SIP overlap > signaling ( RFC 3578) you will see this scenario described when > SAM messages are sent. > > Cheers > Ramesh > > On 11/17/05, *Manjeet Soodan* > wrote: > > 1) There are two SIP UA's A and B. > 2) A sends INVITE with SDP to B. > 3) B responds with 100 and then 180 Ringing(wthout SDP) and > adds TO tag to > 180. > 3) After 180 is received, A sends a RE-INVITE before 200 OK > is received > (i.e RE-INVITE with all the headers having same value as > initial INVITE and > higher CSEQ value). > 4) In this case B responds with a '491 Request Pending' for > RE-INVITE. > > Is it the right behaviour, if not then what should be the > right behaviour of > B? > > > -Manjeet > > > > _______________________________________________ > 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 > > > > > -- > cheers > ramesh > > > > > -- > cheers > ramesh > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 From sip-bounces@ietf.org Tue Nov 22 11:44:30 2005 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 1EebFu-0004yA-I3; Tue, 22 Nov 2005 11:44:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EebFs-0004ut-K6 for sip@megatron.ietf.org; Tue, 22 Nov 2005 11:44:28 -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 LAA09984 for ; Tue, 22 Nov 2005 11:43:50 -0500 (EST) Received: from mail.pingtel.com ([65.220.123.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EebYZ-00052q-En for sip@ietf.org; Tue, 22 Nov 2005 12:03:47 -0500 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id 2FFD96C01F for ; Tue, 22 Nov 2005 11:44:19 -0500 (EST) Subject: RE: [Sip] Query about '491 response' in case of RE-INVITE. From: "Dale R. Worley" To: Sip In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3CD0C80@xmb-rtp-20b.amer.cisco.com> References: <072C5B76F7CEAB488172C6F64B30B5E3CD0C80@xmb-rtp-20b.amer.cisco.com> Content-Type: text/plain Date: Tue, 22 Nov 2005 11:44:18 -0500 Message-Id: <1132677859.25389.19.camel@cdhcp139.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-6) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > Be very carerful with the overlap signaling. In fact, > the subsequent INVITEs that A sends are each new > dialogs, with each old previous dialog being later > rejected. They are not updates to the same dialog. > I think it is wrong to send the 491 in this > case. 491 response can only be sent by A to B, > in your example, if B sends an INVITE to A. A > can send multiple Invites as these are nothing > but updates to the original. If you look at > the ISUP-SIP overlap signaling ( RFC 3578) > you will see this scenario described when SAM > messages are sent. > 1) There are two SIP UA's A and B. > 2) A sends INVITE with SDP to B. > 3) B responds with 100 and then 180 > Ringing(wthout SDP) and adds TO tag > to > 180. > 3) After 180 is received, A sends > a RE-INVITE before 200 OK is > received > (i.e RE-INVITE with all the headers > having same value as initial INVITE > and > higher CSEQ value). > 4) In this case B responds with > a '491 Request Pending' for RE- > INVITE. > > Is it the right behaviour, if not then > what should be the right behaviour of > B? The rules for handling these situations are in section 14 of RFC 3261. The first issue is whether an INVITE is a re-INVITE, that is, whether it is within an existing dialog. Section 14.2 paragraph 1 refers to section 13.3.1 for how to make this distinction. Basically, if it contains a to-tag, it is in-dialog, and if it does not, it is out-of- dialog. If an INVITE is out-of-dialog, it does not interact with any previous INVITE (other than that a UA may reject it as erroneous, since it has the same Call-Id as a previous dialog). Within a dialog, a re-INVITE cannot be processed while another INVITE is being processed. If the INVITE being processed was sent by the sender of the new INVITE, the server should reject the latter with 500 (section 14.2 paragraph 2). If the INVITE being processed was sent by the other UA, the recipient of the new INVITE must reject it with 491 (section 14.2, paragraph 3). Dale _______________________________________________ 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 From sip-bounces@ietf.org Tue Nov 22 11:54:47 2005 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 1EebPr-0003F6-CN; Tue, 22 Nov 2005 11:54:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EebPp-0003E0-1o for sip@megatron.ietf.org; Tue, 22 Nov 2005 11:54:45 -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 LAA11280 for ; Tue, 22 Nov 2005 11:54:06 -0500 (EST) Message-Id: <200511221654.LAA11280@ietf.org> Received: from smtp.b3g-telecom.com ([217.66.113.10] helo=mail.b3g-telecom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EebiL-0005eb-NI for sip@ietf.org; Tue, 22 Nov 2005 12:14:04 -0500 Received: from [217.66.119.5] (helo=PCMJOSSET) by mail.b3g-telecom.com with esmtp (Exim 4.31; FreeBSD) id 1EebP9-000Hz2-T8 for sip@ietf.org; Tue, 22 Nov 2005 17:54:04 +0100 From: "Maxime JOSSET" To: Date: Tue, 22 Nov 2005 17:53:24 +0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXvhUCOJvdRc0ZIT0mh3fXG+7RiVg== X-Spam-Score: 0.2 (/) X-Scan-Signature: 731ea0e9f5725b67e634db1918f3b951 Subject: [Sip] message UPDATE X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1141316856==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1141316856== Content-Type: multipart/related; boundary="----=_NextPart_000_027A_01C5EF8D.A2C083C0" This is a multi-part message in MIME format. ------=_NextPart_000_027A_01C5EF8D.A2C083C0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_027B_01C5EF8D.A2C083C0" ------=_NextPart_001_027B_01C5EF8D.A2C083C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi folks, =20 A call is initiated bye a SIP INVITE message, then 10 minutes after, = peer A send a message UPDATE ( I don=92t know why) to which the remote peer B = doesn=92t send anything but ICMP message =93 destination unreachable (port = unreachable)=94 A few message UDATE later without response and a few seconds more later, = the remote peer sends a BYE message to close the communication. =20 Do you think that this is the flow of UDATE that make the remote peer = close the com ? =20 Why does the peer A send the message UPDATE after 1O minutes time =85 =20 Do you think about a bad configuration of one peer ? =20 Thanks for your replies, =20 =20 Best regards to the community, =20 Maxime Josset=20 Ing=E9nieur NOC Tel : +33(0)1 75 00 83 68 Gsm : +33(0)6 16 75 04 36 maxime.josset@b3g-telecom.com =20 15-17 rue Auber 75009 Paris =20 ------=_NextPart_001_027B_01C5EF8D.A2C083C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi folks,

 

A call is initiated bye a SIP INVITE message, = then 10 minutes after, peer A send a message UPDATE ( I don’t know why) to = which the remote peer B doesn’t send anything but ICMP message “ = destination unreachable (port unreachable)”

A few message UDATE later without response and = a few seconds more later, the remote peer sends a BYE message to close the communication.

 

Do you think that this is the flow of UDATE = that make the remote peer close the com ?

 

Why does the peer A send the message UPDATE = after 1O minutes time …

=A0

Do you think about a bad configuration of one = peer ?

 

Thanks for your = replies,

 

 

Best regards to the = community,

 

Maxime = Josset

Ing=E9nieur = NOC

Tel :  +33(0)1 75 00 83 = 68

Gsm : = +33(0)6 16 75 04 36

maxime.josset@b3g-telecom.com

 

15-17 rue = Auber

75009 = Paris

 

------=_NextPart_001_027B_01C5EF8D.A2C083C0-- ------=_NextPart_000_027A_01C5EF8D.A2C083C0 Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCABPAHcDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD2Wiii gAooooATtSfhS1g694w0fw/8l5c5mIyIYxuc/h2/GmVCEpvlirs3R+VLXnp+L2l+Zgafdbc/e+X+ Wa29I8YaX4iubeOwnYShyZIXUq23a34EZxQbzwlamryjZHUUUUUjmCiiigAooooAKKKKACqtxf29 q4SZ9rEZ6Zq1XP69/wAfif7n9TQBpf2xZf8APU/98mpIdQtZ22xyjcegPGazLXRkuLaOYzMC4zjF VL6yaxlUb9ysMqcYoAu+LNa/sHw9dXygGRV2xg92PArwRmudTvdzF7i5uH+rOxNe8XukW3ijQ4rb UDIUDBjsbaSRkf1qjpnw70HS9QhvoEmMsDbk3SZGfpSaPVwWLpYam7r3mcGvwr19rPzjLaiUrnyS xz9M4xml+GsE1p44a3njaOWOKRXVhyCMV7IzKgJJAArzLQby3vvi7fXFqytC0bAMvRiFUE/mDTsa wxtavSqRntY9OZlRSzMAB1JNVTqlmGx9oX8jWTq128900Ck7EOMDualTQGaIF5grkfdC5AoPFNmO WOZd0bq6+oNSVy8Es2m3xVj904cdiK6cEEAjoaAFooooAKKKKACuf17/AI/E/wBz+proK5/Xv+Px P9z+poAjg1m5ghSJEiKqMDIOf51Xnupb6dWmdR2HGAtb2nwQtYQs0SEleSVFZutwwxSRGJVV2B3B f0oA2bSFLe2jjQ7gB19fep6ytMuY4tMVriVI1DlQXYAfrVuPULSVxHHdQu56KsgJNA0m1c8k+J9/ eR+J2tUup0gMCExLIQh69ulQfC0f8Vgv/XB/6V65faPpuo5N5ZQTFhgl0BOPrXAaDokWgfFOSzti fINs0kYJyVB7fmDStqe1SxcJ4WVJKzSOmcZ1Y57zf1rdv74WKIxjL7jjrisK6zBqsjEfdl3fhnNd DJFb3kStIqyJ1BzxTPEM067ETk2uT9RWvG2+NWxjcAcVy98ITeutso2AgDHc11Ea7IlX0UCgB9FF FABRRRQAVi6vZ3Fxcq0URYBMZFbVFAHMix1JQAqSgDsGp0ek3s0n7xdg7sxrpKKAON+IWkG48FSx W6lmtGWYDucdT+RNeQ6PqUmj6va6jENzW8gbb6joR+IzX0a6K6lWGQRgg968y8R/Ct5Ll7rQpY0V zk20hIC/7p/oaTPYy/FUoQdKrszcT4o+GzaiVpZ1k25MPksWz6Z6frXOeEtbfxB8S5dQdNivAyxp nO1RjH+P41gH4c+KA2z+zx9fNXH866zwT4K1Dw7rUN/fyxhpA0QiTkjKk5J/CjU2qUsHRpzdOV21 3O51HTFvP3iELKBjnoay/wCytQU7Ahx7OMVtfaz/AGgbPyW4j8zzMjHXGOuaZa6il2lw4idVgdkO 7HzY64png8r3K1ho/kyCa4ILLyqjoPrWvWfcapHBpaah5buj+XtQY3fOQB/6EKdcX3kTQRLC8jTH +HHyjjJOfqKBpNlzHFGO9UZNSWPVYrAxOWkXPmDG0HDED1/hNQrr1s2uto4V/PRSxOBjGAc/r+hp jUJPp5mtRRRSJCiiigAooooAKKKKACoZIVllikJIMTFh78Ef1qaigCLyY/O8zaN+3bu9vSmQ2kMA kWNMCVizDcSCT1+lT5ozQF2VP7PtjZLZeWfIXG1d5yMHI5znggVJNZ29w0TTRhzC25CexqfNGaAu yu1nbtdrdNEDOi7VfuB/kn8zTRptmt+b8W6C5ZdplxyR6VaooC7FooooA//Z ------=_NextPart_000_027A_01C5EF8D.A2C083C0-- --===============1141316856== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1141316856==-- From sip-bounces@ietf.org Tue Nov 22 12:45:36 2005 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 1EecBD-0004nR-9H; Tue, 22 Nov 2005 12:43:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EecBA-0004mA-Ko for sip@megatron.ietf.org; Tue, 22 Nov 2005 12:43:40 -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 MAA17289 for ; Tue, 22 Nov 2005 12:42:59 -0500 (EST) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EecJ6-0007go-Tx for sip@ietf.org; Tue, 22 Nov 2005 12:51:54 -0500 Received: from [64.101.149.214] (deanwillis-comp.cisco.com [64.101.149.214]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id jAMHbsGH013873 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 22 Nov 2005 11:37:57 -0600 In-Reply-To: <05AE95C39E8E2642AF9C04526EDAC414B498F0@sonusmail02.sonusnet.com> References: <05AE95C39E8E2642AF9C04526EDAC414B498F0@sonusmail02.sonusnet.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] draft-sparks-sip-nit-problems-02 Date: Tue, 22 Nov 2005 11:32:24 -0600 To: "Bharrat, Shaun" X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Nov 22, 2005, at 8:14 AM, Bharrat, Shaun wrote: > Hi: > > I lost track of the discussion on problems with the non-INVITE > transaction. > The latest draft version I could find has now expired. Can someone > please > point me to a email archive, meeting minutes, etc that describes the > final outcome or prescription? (I am particularly interested in the > current > recommendation on sending provisional responses for the non-INVITE > transaction.) > Using the IETF draft tracker at: https://datatracker.ietf.org/public/pidtracker.cgi I see that: http://www.ietf.org/internet-drafts/draft-sparks-sip-nit-problems-02.txt and http://www.ietf.org/internet-drafts/draft-sparks-sip-nit-actions-03.txt have been approved by the IESG and are in the RFC Editor's queue, Once a draft has entered this state, it doesn't "expire" even if it persists past the date on the draft. This is important, since drafts normally expire after six months, and the queue is longer than that. -- Dean _______________________________________________ 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 From sip-bounces@ietf.org Tue Nov 22 12:49:45 2005 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 1EecH3-0006Kg-AM; Tue, 22 Nov 2005 12:49:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EecH1-0006KT-Hn for sip@megatron.ietf.org; Tue, 22 Nov 2005 12:49:43 -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 MAA18384 for ; Tue, 22 Nov 2005 12:49:04 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EecZh-0000Rq-QT for sip@ietf.org; Tue, 22 Nov 2005 13:09:03 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 22 Nov 2005 09:49:32 -0800 X-IronPort-AV: i="3.97,362,1125903600"; d="scan'208"; a="233274736:sNHT27166684" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id jAMHn3PB019949; Tue, 22 Nov 2005 09:49:30 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 22 Nov 2005 12:49:02 -0500 Received: from [161.44.79.90] ([161.44.79.90]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 22 Nov 2005 12:49:02 -0500 Message-ID: <43835A0E.7030403@cisco.com> Date: Tue, 22 Nov 2005 12:49:02 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "George Foti (QA/EMC)" Subject: Re: [Sip] Doubts about Handling of RR in GRUU References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Nov 2005 17:49:02.0432 (UTC) FILETIME=[0641A600:01C5EF8D] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Content-Transfer-Encoding: 7bit Cc: "'sip@ietf.org'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org George, I just recently noticed this as well. I don't think you are misinterpretting the draft, I think the draft is in error. The problem is that on the terminating side, to get the intended result, EP2 needs to leave itself out of the R-R in the request, but add itself in to the R-R in the response. For that to work when there are more complex topologies beyond it, when it forwards the request it needs to remember where the top of the R-R stack is, so that it will know *where* in the R-R to place itself when the response arrives. Paul George Foti (QA/EMC) wrote: > Hi, > > > > I have a question on the GRUU draft when it comes to Record Routing. > > I am not sure if the desired result, as depicted in the draft can be > achieved with the current description. > > The draft talks about the edge proxy removing itself from the RR of > responses both at the originating domain and terminating domain with the > desired result being as quoted from the spec: > > > > " > > Removing its Record-Route value from the response will result in the > > route set being seen differently by the caller and callee; the callee > > (which is the user agent in the figure) will have a route set entry > > for its edge proxy, while the caller will not. The caller will have > > a route set entry for its edge proxy, while the callee will not." > > > > Lets take an example to see where the problem is as far as the > > description in the draft is concerned So lets take the following case: > > > > UE1--- HP1------EP1..........................HP2------EP2---------UE2 > > > > Both UE1, and UE2 acquired GRUUs, and both EP1 & EP2 are in the path > > for their subsequent UEs when they REGISTER. > > > > If UE1 initiates an INVITE and all proxies insert themselves in > > the RR, so we have the RR arriving at UE2 having EP2, HP1, EP1, HP1. > > > > Then according to the draft both EP2, and EP1 should remove themselves > > from the response to the INVITE. > > So, if UE2 returns a 200 OK with the RR, EP2 removes itself, and EP1 > removes itself as well. > > So UE1 sees a RR including HP1,HP2, and that the route set it has > > While UE2 have a route set entry that includes all 4 proxies, EP2, HP1, > EP1, HP1. > > > > Am I misinterpreting the spec? > > > > Rgds/gf > > Ericsson Canada > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 From sip-bounces@ietf.org Tue Nov 22 13:53:05 2005 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 1EedGL-0007gV-7E; Tue, 22 Nov 2005 13:53:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EedGI-0007be-Ll for sip@megatron.ietf.org; Tue, 22 Nov 2005 13:53:03 -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 NAA25363 for ; Tue, 22 Nov 2005 13:52:23 -0500 (EST) Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EedWj-0004S8-6T for sip@ietf.org; Tue, 22 Nov 2005 14:10:02 -0500 Received: from eamrcnt751.exu.ericsson.se (eamrcnt751.exu.ericsson.se [138.85.133.52]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id jAMIoNVt000421; Tue, 22 Nov 2005 12:50:23 -0600 Received: by eamrcnt751.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Tue, 22 Nov 2005 12:50:22 -0600 Message-ID: From: "George Foti (QA/EMC)" To: "'Paul Kyzivat'" Subject: RE: [Sip] Doubts about Handling of RR in GRUU Date: Tue, 22 Nov 2005 12:50:30 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: "'sip@ietf.org'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Thanks Paul, The desired result to avoid spiralling is that UE2 should have the following route set to be derived from the incoming request: EP2, HP2, HP1. UE1 should have the following route set derived from the response: EP1, HP1, HP2. I made a mistake in the drawing, HP1 & EP1 should be reversed, so it should like to that. UE1--- EP1------HP1..........................HP2------EP2---------UE2 Rgds/gf -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: November 22, 2005 12:49 PM To: George Foti (QA/EMC) Cc: 'jdrosen@cisco.com'; 'sip@ietf.org' Subject: Re: [Sip] Doubts about Handling of RR in GRUU George, I just recently noticed this as well. I don't think you are misinterpretting the draft, I think the draft is in error. The problem is that on the terminating side, to get the intended result, EP2 needs to leave itself out of the R-R in the request, but add itself in to the R-R in the response. For that to work when there are more complex topologies beyond it, when it forwards the request it needs to remember where the top of the R-R stack is, so that it will know *where* in the R-R to place itself when the response arrives. Paul George Foti (QA/EMC) wrote: > Hi, > > > > I have a question on the GRUU draft when it comes to Record Routing. > > I am not sure if the desired result, as depicted in the draft can be > achieved with the current description. > > The draft talks about the edge proxy removing itself from the RR of > responses both at the originating domain and terminating domain with the > desired result being as quoted from the spec: > > > > " > > Removing its Record-Route value from the response will result in the > > route set being seen differently by the caller and callee; the callee > > (which is the user agent in the figure) will have a route set entry > > for its edge proxy, while the caller will not. The caller will have > > a route set entry for its edge proxy, while the callee will not." > > > > Lets take an example to see where the problem is as far as the > > description in the draft is concerned So lets take the following case: > > > > UE1--- HP1------EP1..........................HP2------EP2---------UE2 > > > > Both UE1, and UE2 acquired GRUUs, and both EP1 & EP2 are in the path > > for their subsequent UEs when they REGISTER. > > > > If UE1 initiates an INVITE and all proxies insert themselves in > > the RR, so we have the RR arriving at UE2 having EP2, HP1, EP1, HP1. > > > > Then according to the draft both EP2, and EP1 should remove themselves > > from the response to the INVITE. > > So, if UE2 returns a 200 OK with the RR, EP2 removes itself, and EP1 > removes itself as well. > > So UE1 sees a RR including HP1,HP2, and that the route set it has > > While UE2 have a route set entry that includes all 4 proxies, EP2, HP1, > EP1, HP1. > > > > Am I misinterpreting the spec? > > > > Rgds/gf > > Ericsson Canada > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 From sip-bounces@ietf.org Tue Nov 22 14:29:43 2005 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 1Eedpn-00075Y-Ok; Tue, 22 Nov 2005 14:29:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eedpl-00070S-T9 for sip@megatron.ietf.org; Tue, 22 Nov 2005 14:29:42 -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 OAA29613 for ; Tue, 22 Nov 2005 14:29:02 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eee8T-0007FS-2b for sip@ietf.org; Tue, 22 Nov 2005 14:49:02 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 22 Nov 2005 11:29:31 -0800 X-IronPort-AV: i="3.97,362,1125903600"; d="scan'208"; a="677649424:sNHT29872344" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jAMJSvem014137; Tue, 22 Nov 2005 11:29:27 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 22 Nov 2005 14:29:15 -0500 Received: from [161.44.55.201] ([161.44.55.201]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 22 Nov 2005 14:29:14 -0500 Message-ID: <4383718A.6000203@cisco.com> Date: Tue, 22 Nov 2005 14:29:14 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ramakrishna.adukuri@wipro.com Subject: Re: [Sip] RFC 3261 supported header in 1xx responses References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Nov 2005 19:29:14.0637 (UTC) FILETIME=[05CF53D0:01C5EF9B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, arunvenk@cisco.com, brett@broadsoft.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Yes, its different from Require. Require is not an indication of capabilities of a UA - its an indication that a particular extension needs to be applied. -Jonathan R. ramakrishna.adukuri@wipro.com wrote: > > Is this different for 'Require', because in the case of session timers > proxy can add a 'Require' to request/response depending on UAC/UAS not > supporting session timers. > > > -Ramakrishna > > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > Jonathan Rosenberg > Sent: Monday, November 21, 2005 8:30 PM > To: Arunachalam Venkatraman (arunvenk) > Cc: sip-ietf; Brett Tate > Subject: Re: [Sip] RFC 3261 supported header in 1xx responses > > If a proxy genreates the 1xx itself, it is effectively acting as a UAS, > in which case insertion of Supported is fine. This won't confuse a UAC > since any 1xx generated by the proxy itself will have different tags > from a 2xx or other responses generated by the actual UA, and thus > represent a different (early) dialog. > > A proxy cannot insert or modify a Supported header in a response that > passes by it (i.e., one for which it is proxying). > > -Jonathan R. > > Arunachalam Venkatraman (arunvenk) wrote: > > >>Can a proxy add Supported? Is this disallowed? >>If proxy may do so, the Supported cannot be interpreted as UAS > > >>capabilities, even if the 1xx is reliable (consider INVITE with > > >>Require:100rel). >> > > >>-----Original Message----- >>From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > > >>Jonathan Rosenberg (jdrosen) >>Sent: Friday, November 18, 2005 5:39 PM >>To: Brett Tate >>Cc: sip-ietf >>Subject: Re: [Sip] RFC 3261 supported header in 1xx responses >> > > >>It makes sense to include them in a dialog forming response. A normal > > >>1xx is not dialog forming. My suspicion (though I didn't check if this > > >>was true) is that it went away when 100rel moved out of 3261. It can't > > >>hurt to send them, of course, but it would be ignored unless its > > >>reliable. >> > > >>-Jonathan R. >> > > >>Brett Tate wrote: >> > > > >>>Within early versions of draft-ietf-sip-rfc2543bis, the Supported > > >>>header could be expected within 1xx responses. However within >>>draft-ietf-sip-rfc2543bis-06 it was removed and remains so within RFC >> > >>3261. >> > > >>>Is there a reason why it is undesirable to indicate supported > > >>>extensions within a 1xx? Or was it just an oversight when changing > > >>>the "Summary of header fields" table to indicate 2xx instead of all >> > >>responses? >> > > >>> >>> >>>_______________________________________________ >>>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 >>> >> > > > > -- > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > > _______________________________________________ > 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 > > > Confidentiality Notice > > > The information contained in this electronic message and any attachments to this message are intended > for the exclusive use of the addressee(s) and may contain confidential or privileged information. If > you are not the intended recipient, please notify the sender at Wipro or Mailadmin@wipro.com immediately > and destroy all copies of this message and any attachments. > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ 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 From sip-bounces@ietf.org Tue Nov 22 20:02:38 2005 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 1Eej1y-0000uz-38; Tue, 22 Nov 2005 20:02:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eej1v-0000uo-TG for sip@megatron.ietf.org; Tue, 22 Nov 2005 20:02:35 -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 UAA10485 for ; Tue, 22 Nov 2005 20:01:56 -0500 (EST) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EejKf-0001rW-TG for sip@ietf.org; Tue, 22 Nov 2005 20:21:59 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Tue, 22 Nov 2005 17:02:25 -0800 Received: from RED-MSG-43.redmond.corp.microsoft.com ([157.54.12.203]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Nov 2005 17:02:25 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 22 Nov 2005 17:02:24 -0800 Message-ID: <1BEC4DA05ABCD34FACFCFC82086AC2470839B590@RED-MSG-43.redmond.corp.microsoft.com> Thread-Topic: Distinguishing subscription from polling resource state thread-index: AcXvyZBoVYnkXPPvTtOhiZvOTOlqKQ== From: "Tim Rang" To: X-OriginalArrivalTime: 23 Nov 2005 01:02:25.0159 (UTC) FILETIME=[9116E970:01C5EFC9] X-Spam-Score: 0.2 (/) X-Scan-Signature: 8068004c042dabd7f1301bcc80e039df Subject: [Sip] Distinguishing subscription from polling resource state X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0453982761==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0453982761== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5EFC9.90AFD2DD" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5EFC9.90AFD2DD Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable I have an issue regarding RFC 3265 section 3.3.6 "Polling Resource State". It is clear that a SUBSCRIBE request with an Expires value of 0 may constitute a resource query or an unsubscribe, depending upon whether a dialog exists. If I have a proxy server wants to distinguish between unsubscribe and resource query, and my proxy server does not maintain dialog state, what message element(s) can it use to make that determination? =20 My position is that you can use the To tag parameter (or lack of). On reading through 3261, 12.1.2 states that To tags should not be expected as they were not mandated in 2543 (there seems to be a lot of this lately). However, 2543 states in section 6.37- =20 "It MUST be placed in the To field of the response by each instance when there is a possibility that the request was forked at an intermediate proxy." =20 That RFC is silent on when it is ok to omit. My read of this is that a UAS can only "know" that a forking server was NOT in the path in one condition- if the request was sent peer to peer, without any proxy servers in the path.=20 =20 Accepting that, and knowing that my question is unique to scenarios when proxies are involved, is it ok to assume that any SUBSCRIBE request sent by a UA (either 3261 or 2543 compliant) which passes through a proxy meets the following conditions- - if a tag parameter is present in the To header, then the SUBSCRIBE (Expires=3D0) is in fact an unsubscribe. - If a tag parameter is NOT present, the SUBSCRIBE = (Expires=3D0) is a polling subscribe? =20 Thanks, Tim Rang ------_=_NextPart_001_01C5EFC9.90AFD2DD Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

I have an issue regarding RFC 3265 section 3.3.6 = “Polling = Resource State”.  It is clear that a SUBSCRIBE request with an Expires value of 0 may = constitute a resource query or an unsubscribe, depending upon whether a dialog exists.  If I have a proxy server wants to distinguish between = unsubscribe and resource query, and my proxy server does not maintain dialog state, = what message element(s) can it use to make that = determination?

 

My position is that you can =
use the To tag parameter (or lack of).  On reading through 3261, =
12.1.2 states that To tags should not be expected as they were not =
mandated in 2543 (there seems to be a lot of this lately).  =
However, 2543 states in section =
6.37-
 
  =
“It MUST be placed in the To field of the response by each =
instance when there is a possibility that the request was forked at an =
intermediate proxy.”

 

That RFC is silent on when it is ok to omit.  My = read of this is that a UAS can only “know” that a forking server = was NOT in the path in one condition- if the request was sent peer to peer, = without any proxy servers in the path.

 

Accepting that, and knowing that my question is = unique to scenarios when proxies are involved, is it ok to assume that any = SUBSCRIBE request sent by a UA (either 3261 or 2543 compliant) which passes through a = proxy meets the following conditions-

-          if a tag parameter is = present in the To header, then the SUBSCRIBE (Expires=3D0) is in fact an = unsubscribe.

-          If a tag parameter is NOT = present, the SUBSCRIBE (Expires=3D0) is a polling = subscribe?

 

Thanks,

Tim Rang

------_=_NextPart_001_01C5EFC9.90AFD2DD-- --===============0453982761== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============0453982761==-- From sip-bounces@ietf.org Tue Nov 22 20:25:39 2005 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 1EejOF-0006Po-Co; Tue, 22 Nov 2005 20:25:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EejOC-0006PB-Pp; Tue, 22 Nov 2005 20:25:36 -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 UAA13477; Tue, 22 Nov 2005 20:24:57 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eejgx-0003Dk-Un; Tue, 22 Nov 2005 20:45:00 -0500 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jAN1OjE25223; Tue, 22 Nov 2005 17:24:45 -0800 (PST) Message-Id: <200511230124.jAN1OjE25223@boreas.isi.edu> To: ietf-announce@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Tue, 22 Nov 2005 17:24:45 -0800 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-Spam-Score: -14.6 (--------------) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: sip@ietf.org, rfc-editor@rfc-editor.org Subject: [Sip] RFC 4244 on An Extension to the Session Initiation Protocol (SIP) for Request History Information X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --NextPart A new Request for Comments is now available in online RFC libraries. RFC 4244 Title: An Extension to the Session Initiation Protocol (SIP) for Request History Information Author(s): M. Barnes, Ed. Status: Standards Track Date: November 2005 Mailbox: mary.barnes@nortel.com Pages: 44 Characters: 98992 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-sip-history-info-06.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4244.txt This document defines a standard mechanism for capturing the history information associated with a Session Initiation Protocol (SIP) request. This capability enables many enhanced services by providing the information as to how and why a call arrives at a specific application or user. This document defines a new optional SIP header, History-Info, for capturing the history information in requests. This document is a product of the Session Initiation Protocol Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <051122172347.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc4244 --OtherAccess Content-Type: Message/External-body; name="rfc4244.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <051122172347.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --NextPart-- From sip-bounces@ietf.org Wed Nov 23 00:15:41 2005 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 1Eemxo-0006Yn-IE; Wed, 23 Nov 2005 00:14:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eemxm-0006Yi-MM for sip@megatron.ietf.org; Wed, 23 Nov 2005 00:14:35 -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 AAA10082 for ; Wed, 23 Nov 2005 00:13:55 -0500 (EST) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EenGZ-0007yz-3o for sip@ietf.org; Wed, 23 Nov 2005 00:34:00 -0500 Received: from [192.168.2.111] (c-24-1-177-214.hsd1.tx.comcast.net [24.1.177.214]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id jAN5JuD1016371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Nov 2005 23:19:57 -0600 Message-ID: <4383FAB5.5000202@softarmor.com> Date: Tue, 22 Nov 2005 23:14:29 -0600 From: Dean Willis User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org X-Spam-Score: 2.0 (++) X-Scan-Signature: fe6e20eef2d8927c50910823cd0d1c84 Cc: Rohan Mahy , Allison Mankin Subject: [Sip] Draft minutes, SIP at IETF 64 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1743263983==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============1743263983== Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The draft minutes for SIP at IETF 64 are posted at:

http://www.softarmor.com/sipwg/meets/ietf64/notes/minutes-sip-ietf64.html

and

http://www3.ietf.org/proceedings/05nov/minutes/sip.html

and text follows. Please send any corrections to the list and chairs ASAP.

-------

Minutes, SIP Working Group, IETF 64

Edited by Dean Willis from notes by:

  • Spencer Dawkins

  • Eric Burger

  • Scott Lawrence

  • Steve Donovan




Initial Agenda, Session 1: Tuesday, November 8, 1300-1500

Time

Discussion Leader

Topic

Draft

Time

1300

Chairs

Agenda Bash

5

1305

Chairs

Status, Charter and Schedule

15

1320

Chairs (announce)

Response Identity

draft-cao-sip-response-auth-00

0

1320

John Elwell

Connected identity

draft-elwell-sip-connected-identity-00

15

1335

Cullen Jennings

Certs

draft-ietf-sipping-certs-02

15

1350

Hannes Tschofenig

SAML

draft-tschofenig-sip-saml-04

15

1405

Dean Willis
Andrew Allen

Answer and Alert Modes

draft-willis-sip-answeralert-01

15

1420

Kumiko Ono

Trust Path Discovery

draft-ono-trust-path-discovery-01

15

1435

David Schwartz

SAML for SPIT

draft-schwartz-sipping-spit-saml-00

10

1445

Rohan Mahy

Remote Call Control

draft-mahy-sip-remote-cc-02

10

Topic: Agenda

GRUU will be added to the agenda when possible due to new issues on-list.

Certs dropped from agenda due to no open issues requiring discussion.



Topic: Charter and Status

Discussion led by chairs

Slides presented and included in proceedings.

Issue: Charter. The only element of the new charter receiving substantial discussion was the milestone “Draft standard versions of SIP and critical supporting
specifications”. This was highly controversial as read. The group discussed the meaning of “draft standard” and its requirement for at least two independent interoperable implementations. The general consensus seems to be that it is premature to discuss elevating the standards level of SIP at this time. Two key points were noted:

  • It would be useful to develop a document like the “TCP Roadmap” that explains which RFCs are “part of SIP” and are critical to implementations. Jonathan Rosenberg expressed an interest in this work.

  • Robert Sparks has been tracking the normative requirements (“MUSTs”) of the core specification and will contribute this work to the process.

Issue: draft-cao-sip-response-auth-00. Few comments received on list. Attendees asked to review.

Issue: Certs draft. This draft is moving from SIPPING to SIP as a charter deliverable. A poll of the room indicated that at least seven parties plan to implement the specification. All parties are asked to review the draft, but Rohan will pick out at least two of the implementers to assist in a detailed review.

TODO: Rohan to coordinate review of Certs draft.

Issue: MIB Document. The review of this document has been delayed by slow responses to MIB doctor requests. The editors report that there is some controversy over method identifiers, which the MIB doctors apparently asked to have deleted from the document, then asked to have added back.

Topic: Connected Identity

Discussion led by John Elwell

Slides presented and included in proceedings.

Issue: Basic mechanism. Several approaches proposed. Discussion rapidly converged on modification of “From:” header fields to reflect identity as used in the Identity draft. Tieing this change to the Outbound draft seems to provide for most aspects of backward compatibility, but several participants argued strongly that we should go ahead and “really fix” the “From: header without cruft to support backward compatibility. The changing of From: in mid-dialog requests also seemed to have a general consensus, but didn't appear to be generally understood. The discussion concluded with a strong consensus on this general line of work, but a general feeling tht there are probably some lurking issues that won't become clear until the approach is specified in a draft.

Topic: SAML

Discussion led by Hannes Tschofenig

Slides presented and included in proceedings.

There seems to be a strong general interest in the approach, but the working group seemed to agree that we need a draft with more discussion of practical mechanism and examples in order to really get started here. There was no consensus to adopt the draft at this time as baseline text toward the charter deliverable, but the author was encouraged to proceed with the work and continue the discussion with the working group in hopes of reaching critical mass.

Topic: Answer and Alert Modes

Discussion led by Dean Willis and Andrew Allen

Slides presented and included in proceedings.

Discussion centered on possible security issues relating to the combination of auto-answer and null alert modes providing a “bug my phone” or “baby monitor” attack. The group reached consensus on revising the draft to eliminate the alert-mode functionality, with a general agreement that the use of Alert-Info with URN behaviors as proposed in SIPPING is a more attractive approach. The revised draft shall also include stronger guidance on the “bug my phone” aspect. Robert Sparks noted that several aspects of the draft would be likely to be misunderstood by implementers and might result in “train wreck” implementations, and agreed to send text to the editor to correct these flaws. The group did agree that completing this work for OMA is critical and consistent with the new charter of the working group.

TODO: Chairs to coordinate new milestone with AD.

Topic: Trust Path Discovery

Discussion led by Kumiko Ono

Slides presented and included in proceedings.

Issue: Scaling and “push” vs “pull” model. Noted that push model requires advance calculation of several degrees of connectivity, which can become very large very quickly. It was reported that AOL cannot three degrees of connectivity for the AIM database as the problem space becomes too large.

Noted that the IAB messaging workshop recommended investigation of a distributed reputation system.

Noted that there is a problem relationship to DKIM, so there could be a similarity in the solution.

Suggested that this material is worth holding a BOF on and perhaps chartering a working group.

The chairs requested the author to keep the working group informed of progress in this area, but the general consensus is that this problem is outside the scope of SIP.



Topic: SAML for SPIT

Discussion led by David Schwartz

Slides presented and included in proceedings.

Discussion indicated a general interest in the problem and approach if it can be shown to scale to practical problem sets.

It was noted that the current draft is domain-oriented, but that it could be extended to end-user devices if those devices supported SAML.

The author was also encouraged to further explore the idea of federated domains.



Topic: Remote Call Control

Discussion led by Rohan Mahy

Slides presented and included in proceedings.

Question: Would full arbitration of end-point (not just dialog) state be in scope for this draft? The authors don't feel it to be in scope at this time.

Noted that revisions should explain how this interacts with REFER.

Noted that this is approaching “full CTI (computer telephony integration)”, which has previously been out of scope in SIP. The room was asked to show hands if they thought this discussion to be in/out of the interest of SIP. About 20 responded positively, with about 2 opposed.

The meeting session concluded on-schedule.

Initial Agenda, Session  2: Thursday, November 10, 1300-1500 (Note: conflicts with SAAG)

Time

Discussion Leader

Topic

Draft

Time

1300

Chairs

Agenda Bash

5

1305

Rohan Mahy

Connection Reuse

draft-ietf-sip-connect-reuse-04

25

1330

Cullen Jennings

Outbound

draft-ietf-sip-outbound-01

30

1400

Orit Levin

Refer Feature Parameters

draft-ietf-sip-refer-feature-param-00

15

1415

James Polk
Brian Rosen

Location Conveyance

draft-ietf-sip-location-conveyance-01

15

1430

Jonathan Rosenberg

Route Construction

draft-rosenberg-sip-route-construct-00

15

1445

Jonathan Rosenberg

Target Dialog

draft-ietf-sip-target-dialog-02

15

Topic: Agenda

James Polk suggested that there is no need to discuss location conveyance. We agreed to have a minimal discussion.

GRUU added to agenda.

Outbound and Refer Feature Parameters reordered due to slide availability issues.

If time permits, we will discuss Dale Worley's draft on dialog event package implementation guidelines, draft-worley-sipping-dialog-00.txt

Topic: Connection reuse

Discussion led by Rohan Mahy

Rohan reports that there have been conflicting proposals to fix open issues and that the draft has been languishing. He will reopen discussion of the draft on the mailing list.

No slides presented

Topic: GRUU

Discussion led by Jonathan Rosenberg

Slides presented and included in proceedings

Issue: Indicating URI is a GRUU. Consensus emerged on not using a URI parameter to indicate that a URI is a GRUU, but to rely on normative behavior that clients supporting GRUU will always use a GRUU. The text will be amended based on text submitted by Dale Worley on the SIP list. The text will also be revised to clarify that one does not make the assumption of GRUUness based on “Supported: gruu”.


Issue: Difference between retargeting and routing.

Definitions:

  • Retargeting - change in resource to which request is destined

  • Routing - change in request destination to reach the resource to which the request is targeted

Proposal: 305 implies re-routing, Other 3xx imply re-targeting. Tie to SIP outbound. Put registered contact in Route header instead of request-URI.

Issue: GRUU usage as proposed breaks Outbound as written. This point was agreed, and led to intense discussion. Suggested by Sean Olson that the GRUU be placed in the route header, not in the contact. Jonathan asked for written clarification on this. Discussion raged interminably, resulting in a decision to have an after-hours discussion.

Noted that this represents a substantial change, but a huge improvement, in general SIP routing methodology. Should this increment or change the SIP version number? The consensus here was “no”, although we appear to be getting very close to that threshold.

Topic: Outbound

Discussion led by Cullen Jennings

Slides presented and included in proceedings

Issue: Config framework requires a subscribe before UA has credentials to perform registration.

Resolution: Use of pin-route option tag in require header agreed to by group.

Issue : Record-Route and Reliability

Proposal: Use GRUU and don't record-route in EP

No discussion of issue – seemed to be general consensus on proposal.

Issue: Service Route

Proposal: Start with configured outbound proxy, each registration returns a service route, this service route replaces the outbound just for that registration.

Discussion finally concluded that this was a not major issue, but that some changes to Service-Route would be needed.

Issue: Should outbound have a dependency on draft-rosenberg-sip-route-construct?

Resolution: Take it to the list

Issue: Terminology

The flow/flow-id/connection terms are confusing and Cullen asked for suggested new wording.

Topic: Location Conveyance

Discussion led by Brian Rosen, supported by James Polk

Issue: Need people to look at draft

Issue: Do we need a separate package or should we just use presence package?

Proposal: State that it works with presence and it can be included in other packages

Resolution: Discuss on list

Topic: Refer Feature Parameters

Discussion led by Orit Levin

Slides presented and included in proceedings

Issue: What feature tags should be included in REFER?

Proposal: Update 3840 and callerprefs use cases, include all feature tags that were listed in the most recent contact header field of the REFER-Target.

Alternate proposal (Cullen proposal): Need to have a document that gives implementers information on what feature tags to include in what messages.

Resolution: Consensus as judged by chair: Move forward with proposal for REFER as presented. Deal with Cullen's proposal separately.

Topic: Target Dialog

Discussion led by Jonathan Rosenberg

Slides presented and included in proceedings

Issue: Proposal to extend target-dialog

Resolution: Don't do it

Issue: Handling of request with target-dialog that doesn't exist.

Proposal on list was to use 481.

Resolution: Don't use 481, use existing text.

Noted by Cullen Jennings & Robert Sparks that 3261 already recommends the use of crypto-random tag values, but that existing implementations do not use enough bits to have sufficient randomness. This shows a need for more than rough guidance on this sort of thing.

Action: Revise and resubmit document.

Topic: Route Construction

Discussion led by Jonathan Rosenberg

Slides presented and included in proceedings

Discussion was generally favorable and the working group was asked to consider whether this document provides sufficient additional clarity to SIP that it should be considered under the revised charter scope of “increasing the stability of the SIP specification”. The consensus is favorable, and the chairs are directed to work with the AD to establish a milestone.

TODO: Chairs to work with AD to establish a milestone for Route Construction.

Topic: Dialog Event Package

Discussion led by Dale Worley

Slides presented and included in proceedings

Implementations do not currently contain the information needed to be useful.

So, this draft provides guidelines on how to use dialog even package. Need implementers to review this draft and see if it helps.

Cullen Jennings noted that there is an ambiguity with respect to how to signal state at the end of a call and that it would be useful to address this in future revisions.



--===============1743263983== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1743263983==-- From sip-bounces@ietf.org Wed Nov 23 01:38:48 2005 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 1EeoHI-0003pk-AK; Wed, 23 Nov 2005 01:38:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeoHF-0003oD-S9 for sip@megatron.ietf.org; Wed, 23 Nov 2005 01:38:45 -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 BAA17330 for ; Wed, 23 Nov 2005 01:38:06 -0500 (EST) From: nagendra.swamy@flextronicssoftware.com Received: from delta.hssblr.co.in ([203.145.155.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeoZy-0003cm-8r for sip@ietf.org; Wed, 23 Nov 2005 01:58:08 -0500 Received: from espion.blr.hss.hns.com (espion.blr.hss.hns.com [10.203.193.21]) by delta.hssblr.co.in (8.11.6/8.11.6) with ESMTP id jAN6cWx30099 for ; Wed, 23 Nov 2005 12:08:32 +0530 Subject: RE:[Sip] Distinguishing subscription from polling resource state To: sip@ietf.org X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: Date: Wed, 23 Nov 2005 12:04:51 +0530 X-MIMETrack: Serialize by Router on Espion/BLR/HSS(Release 6.5|September 18, 2003) at 11/23/2005 12:24:47 PM MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable X-Spam-Score: 0.5 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Content-Transfer-Encoding: quoted-printable X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi Tim, yes,you can consider these conditions to distinguish between poll and terminate subscription Regards Nagendra FSS, Bangalore. To: From: "Tim Rang" Sent by: sip-bounces@ietf.org Date: 11/23/2005 06:32AM Subject: [Sip] Distinguishing subscription from polling resource state= I have an issue regarding RFC 3265 section 3.3.6 ? Polling Resource St= ate ?. It is clear that a SUBSCRIBE request with an Expires value of 0 ma= y constitute a resource query or an unsubscribe, depending upon whether = a dialog exists. If I have a proxy server wants to distinguish between unsubscribe and resource query, and my proxy server does not maintain dialog state, what message element(s) can it use to make that determination? My position is that you can use the To tag parameter (or lack of). On= reading through 3261, 12.1.2 states that To tags should not be expecte= d as they were not mandated in 2543 (there seems to be a lot of this lately= ). However, 2543 states in section 6.37- ?It MUST be placed in the To field of the response by each instance = when there is a possibility that the request was forked at an intermediate proxy.? That RFC is silent on when it is ok to omit. My read of this is that = a UAS can only ?know? that a forking server was NOT in the path in one condition- if the request was sent peer to peer, without any proxy ser= vers in the path. Accepting that, and knowing that my question is unique to scenarios wh= en proxies are involved, is it ok to assume that any SUBSCRIBE request se= nt by a UA (either 3261 or 2543 compliant) which passes through a proxy m= eets the following conditions- - if a tag parameter is present in the To header, then the SUBSCRIBE (Expires=3D0) is in fact an unsubscribe. - = If a tag parameter is NOT present, the SUBSCRIBE (Expires=3D0= ) is a polling subscribe? = = = = = = Thanks, = = = Tim Rang = = *********************** FSS-Unclassified *********************** "DISCLAIMER: This message is proprietary to Flextronics Software System= s Limited (FSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received th= is message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSS accepts no responsibility for los= s or damage arising from the use of the information transmitted by this email including damage from virus."= _______________________________________________ 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 From sip-bounces@ietf.org Wed Nov 23 06:37:57 2005 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 1Eeswn-0005Hz-Eg; Wed, 23 Nov 2005 06:37:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eeswl-0005HG-1T for sip@megatron.ietf.org; Wed, 23 Nov 2005 06:37:55 -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 GAA17277 for ; Wed, 23 Nov 2005 06:37:15 -0500 (EST) Message-Id: <200511231137.GAA17277@ietf.org> Received: from [80.86.198.153] (helo=MAIL02.NEXLINK.CH) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EetFa-0003HO-H2 for sip@ietf.org; Wed, 23 Nov 2005 06:57:23 -0500 Received: from localhost ([127.0.0.1] helo=MAIL02.NEXLINK.CH) by MAIL02.NEXLINK.CH with esmtp (Exim 4.51) id 1Eesw9-0002Oa-Nv; Wed, 23 Nov 2005 12:37:17 +0100 MIME-Version: 1.0 From: To: sip@ietf.org Date: Wed, 23 Nov 2005 12:37:17 +0100 X-Uidl: 1132745837101942935 X-Mailer: AtMail 4.11 X-Spam-Score: 2.6 (++) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: mary.barnes@nortel.com Subject: [Sip] ABNF rule used in RFC 4244 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: joel.repiquet@tech-invite.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2141184517==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============2141184517== Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

In RFC 4244 (An Extension to SIP for Request Hist= ory Information) there is the following ABNF rule:

   =     hi-index =3D "index" EQUAL 1*DIGIT *(DOT 1*DIG= IT) 

DOT is not defined as an ABNF core rule in RFC  4234 (= ABNF) and is not defined as a basic rule in RFC 3261.

It is only used= and defined in RFC 3525 (Gateway Control Protocol Version 1).
=0D

Is it defined elsewhere? 

 

This could be a pr= oblem for parsers.
=0D

This rule should be:

       hi-i= ndex =3D "index" EQUAL 1*DIGIT *("." 1*DIGIT)
= =0D

 

Regards

Joël 


--===============2141184517== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============2141184517==-- From sip-bounces@ietf.org Wed Nov 23 07:06:40 2005 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 1EetOa-0002dD-8w; Wed, 23 Nov 2005 07:06:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EetOX-0002c0-HI for sip@megatron.ietf.org; Wed, 23 Nov 2005 07:06: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 HAA20130 for ; Wed, 23 Nov 2005 07:05:58 -0500 (EST) From: priti.sarode@flextronicssoftware.com Received: from delta.hssblr.co.in ([203.145.155.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EethG-0004hi-UC for sip@ietf.org; Wed, 23 Nov 2005 07:26:06 -0500 Received: from espion.blr.hss.hns.com (espion.blr.hss.hns.com [10.203.193.21]) by delta.hssblr.co.in (8.11.6/8.11.6) with ESMTP id jANC65x06454; Wed, 23 Nov 2005 17:36:06 +0530 In-Reply-To: To: Rohan Mahy X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: Date: Wed, 23 Nov 2005 17:32:14 +0530 X-MIMETrack: Serialize by Router on Espion/BLR/HSS(Release 6.5|September 18, 2003) at 11/23/2005 05:52:23 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.5 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: Cullen Jennings , Rohan Mahy , sip@ietf.org Subject: [Sip] Re: pin-route option tag in outbound-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi Rohan, Thanks for the response. If pin-route option is not recommended for subscription dialog (event- Presence), then how should the watcher behind NAT be supported ? If GRUU is used in Contact header of SUBSCRIBE, it requires location service lookup for the Contact and also requires watcher to register. Is there anyway to support watchers behind NAT (subscription dialog ) and not having GRUU ? Regards, Priti Rohan Mahy To priti.sarode@flextronicssoftware.co 11/21/2005 09:17 m PM cc Cullen Jennings , Rohan Mahy , sip@ietf.org Subject Re: pin-route option tag in outbound-01 Hi Priti, This is not recommended. The first-hop proxy and the presence agent would both have to support pin-route (which seems unlikely for the presence agent), and the subscribe request would only be useful for fetching immediate presence. For the configuration framework, you can use the pin-route option to get your configuration on bootup. Then you should issue a new subscription using your GRUU (once you have registered) to get change notifications. The reason for this is that a single dialog using the pin-route option will only use the flow over which it was originally sent. If that flow dies, notifications won't get back to the subscriber, even if another flow is available. If you use a GRUU registered with multiple flows for outbound, only one of them has to work. thanks, -rohan On Nov 21, 2005, at 3:48, priti.sarode@flextronicssoftware.com wrote: > Hi, > > As per the outbound-01 draft, the pin-route option tag can be used by > UAs > that do not have a GRUU, > in SUBSCRIBE request sent to configuration framework. Can the same tag > also > be used > in SUBSCRIBE request sent to event framework (event- Presence) ? > > - Priti > > > > *********************** FSS-Unclassified *********************** > "DISCLAIMER: This message is proprietary to Flextronics Software > Systems > Limited (FSS) and is intended solely for the use of the > individual to whom it is addressed. It may contain privileged or > confidential information and should not be circulated or used for > any purpose other than for what it is intended. If you have received > this > message in error, please notify the originator immediately. > If you are not the intended recipient, you are notified that you are > strictly prohibited from using, copying, altering, or disclosing > the contents of this message. FSS accepts no responsibility for > loss or > damage arising from the use of the information transmitted > by this email including damage from virus." *********************** FSS-Unclassified *********************** "DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." _______________________________________________ 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 From sip-bounces@ietf.org Wed Nov 23 10:30:29 2005 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 1EewZp-0003jG-Tr; Wed, 23 Nov 2005 10:30:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EewZo-0003jB-HV for sip@megatron.ietf.org; Wed, 23 Nov 2005 10:30:28 -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 KAA15707 for ; Wed, 23 Nov 2005 10:29:48 -0500 (EST) Received: from mail.pingtel.com ([65.220.123.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eewsg-0008SU-Ah for sip@ietf.org; Wed, 23 Nov 2005 10:49:59 -0500 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id DE0956C017 for ; Wed, 23 Nov 2005 10:30:21 -0500 (EST) Subject: Re: [Sip] Distinguishing subscription from polling resource state From: "Dale R. Worley" To: Sip In-Reply-To: <1BEC4DA05ABCD34FACFCFC82086AC2470839B590@RED-MSG-43.redmond.corp.microsoft.com> References: <1BEC4DA05ABCD34FACFCFC82086AC2470839B590@RED-MSG-43.redmond.corp.microsoft.com> Content-Type: text/plain; charset=utf-8 Date: Wed, 23 Nov 2005 10:30:21 -0500 Message-Id: <1132759821.3662.13.camel@cdhcp139.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-6) Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: quoted-printable X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Tue, 2005-11-22 at 17:02 -0800, Tim Rang wrote: > I have an issue regarding RFC 3265 section 3.3.6 =E2=80=9CPolling Resou= rce > State=E2=80=9D. It is clear that a SUBSCRIBE request with an Expires v= alue of > 0 may constitute a resource query or an unsubscribe, depending upon > whether a dialog exists. If I have a proxy server wants to > distinguish between unsubscribe and resource query, and my proxy > server does not maintain dialog state, what message element(s) can it > use to make that determination? Why would it need to distinguish between "unsubscribe" and "resource query"? In either usage, the UAS is *required* to send a complete status, so the response that the proxy has to process is no different. Dale _______________________________________________ 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 From sip-bounces@ietf.org Wed Nov 23 10:41:23 2005 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 1EewkN-0003Zq-I6; Wed, 23 Nov 2005 10:41:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EewkL-0003Ya-Az for sip@megatron.ietf.org; Wed, 23 Nov 2005 10:41:21 -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 KAA17032 for ; Wed, 23 Nov 2005 10:40:41 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eex3E-0000iJ-2I for sip@ietf.org; Wed, 23 Nov 2005 11:00:52 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 23 Nov 2005 07:41:11 -0800 X-IronPort-AV: i="3.97,364,1125903600"; d="scan'208"; a="369405134:sNHT27817840" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jANFekek020282; Wed, 23 Nov 2005 07:41:09 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 23 Nov 2005 10:41:04 -0500 Received: from [161.44.79.90] ([161.44.79.90]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 23 Nov 2005 10:41:04 -0500 Message-ID: <43848D90.6090307@cisco.com> Date: Wed, 23 Nov 2005 10:41:04 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Rang Subject: Re: [Sip] Distinguishing subscription from polling resource state References: <1BEC4DA05ABCD34FACFCFC82086AC2470839B590@RED-MSG-43.redmond.corp.microsoft.com> In-Reply-To: <1BEC4DA05ABCD34FACFCFC82086AC2470839B590@RED-MSG-43.redmond.corp.microsoft.com> Content-Type: text/plain; charset=windows-1252; format=flowed X-OriginalArrivalTime: 23 Nov 2005 15:41:04.0303 (UTC) FILETIME=[5025E3F0:01C5F044] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id KAA17032 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Tim Rang wrote: > I have an issue regarding RFC 3265 section 3.3.6 =93Polling Resource=20 > State=94. It is clear that a SUBSCRIBE request with an Expires value o= f 0=20 > may constitute a resource query or an unsubscribe, depending upon=20 > whether a dialog exists. If I have a proxy server wants to distinguish= =20 > between unsubscribe and resource query, Why would the proxy want to know? Perhaps to do authorization for=20 messages outside a dialog but not for those in a dialog??? > and my proxy server does not=20 > maintain dialog state, what message element(s) can it use to make that=20 > determination? >=20 > My position is that you can use the To tag parameter (or lack of). On = reading through 3261, 12.1.2 states that To tags should not be expected a= s they were not mandated in 2543 (there seems to be a lot of this lately)= . However, 2543 states in section 6.37- >=20 > =93It MUST be placed in the To field of the response by each instance= when there is a possibility that the request was forked at an intermedia= te proxy.=94 >=20 > That RFC is silent on when it is ok to omit. My read of this is that a= =20 > UAS can only =93know=94 that a forking server was NOT in the path in on= e=20 > condition- if the request was sent peer to peer, without any proxy=20 > servers in the path. >=20 > Accepting that, and knowing that my question is unique to scenarios whe= n=20 > proxies are involved, is it ok to assume that any SUBSCRIBE request sen= t=20 > by a UA (either 3261 or 2543 compliant) which passes through a proxy=20 > meets the following conditions- >=20 > - if a tag parameter is present in the To header, then the=20 > SUBSCRIBE (Expires=3D0) is in fact an unsubscribe. >=20 > - If a tag parameter is NOT present, the SUBSCRIBE (Expires=3D= 0)=20 > is a polling subscribe? Well, an unsubscribe *is* a polling subscribe, in that it results in one=20 last transmission of state as well as terminating the subscription. There is also the possibility that the UAS has crashed and forgotten the=20 dialog state. In that case the UAS most likely will fail the request=20 with a 481 response. But it might recover the dialog and then terminate i= t. Depending on what you are trying to accomplish, a UAC might use a bogus=20 To-tag to get around you. Most UASs would probably respond with a 481,=20 but a buggy one, or one that is complicit with the UAC might accept it. Paul _______________________________________________ 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 From sip-bounces@ietf.org Wed Nov 23 15:31:24 2005 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 1Ef1H2-0002r0-DE; Wed, 23 Nov 2005 15:31:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ef1H0-0002qd-GU for sip@megatron.ietf.org; Wed, 23 Nov 2005 15:31:22 -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 PAA24962 for ; Wed, 23 Nov 2005 15:30:42 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ef1Zv-0001qr-0e for sip@ietf.org; Wed, 23 Nov 2005 15:50:56 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 23 Nov 2005 12:31:09 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id jANKUaPF007897 for ; Wed, 23 Nov 2005 12:31:06 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 23 Nov 2005 12:30:57 -0800 Received: from jmpolk-wxp.cisco.com ([10.21.97.7]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 23 Nov 2005 12:30:57 -0800 Message-Id: <4.3.2.7.2.20051123142425.032ac858@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 23 Nov 2005 14:30:56 -0600 To: sip@ietf.org From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 23 Nov 2005 20:30:57.0411 (UTC) FILETIME=[CF3F8D30:01C5F06C] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: fluffy@cisco.com Subject: [Sip] draft-jennings-sipping-pay-03 defining 402? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Cullen Color me slow, but in my review of what documents (RFC, SIP or SIPPING WG item, or individual ID) register (or ask for the registration of) SIP Response codes, I came across this ID (draft-jennings-sipping-pay-03) having an IANA registration request for the 402 (Payment Required) Response code, yet 3261 already defines this code, and seemingly for what you want to use it for, down to the text string being identical. Please educate me on the differences between 3261's meaning of 402 and your ID's, and perhaps why your ID would want to register 402 again. cheers, James ******************* Truth is not to be argued... it is to be presented. _______________________________________________ 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 From sip-bounces@ietf.org Thu Nov 24 01:57:17 2005 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 1EfB2j-0001Az-OY; Thu, 24 Nov 2005 01:57:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ee7Vp-0001v0-8N for sip@megatron.ietf.org; Mon, 21 Nov 2005 03:58:57 -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 DAA14394 for ; Mon, 21 Nov 2005 03:58:20 -0500 (EST) Received: from [202.54.64.17] (helo=hclnpd.hclt-ntl.co.in) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ee7oE-00042T-2n for sip@ietf.org; Mon, 21 Nov 2005 04:17:59 -0500 Received: from npd-mail1.hclt-ntl.co.in ([10.105.1.106]) by hclnpd.hclt-ntl.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id WFGCLHJL; Mon, 21 Nov 2005 14:13:01 +0530 Content-Class: urn:content-classes:message X-MessageTextProcessor: DisclaimIt (2.50.252) [HCL Technologies Ltd., Chennai, India] Received: from npd-mail.hclt-ntl.co.in ([10.105.1.104]) by npd-mail1.hclt-ntl.co.in with Microsoft SMTPSVC(5.0.2195.6713); Mon, 21 Nov 2005 14:13:01 +0530 Received: by npd-mail.hclt-ntl.co.in with Internet Mail Service (5.5.2657.72) id ; Mon, 21 Nov 2005 14:13:00 +0530 Message-ID: <4B1D6623CCBD79489DE28D1CA062A47E0160902B@npd-mail.hclt-ntl.co.in> From: "Karthik Kamaraj - NPD, Chennai" Content-Transfer-Encoding: quoted-printable To: Date: Mon, 21 Nov 2005 14:12:53 +0530 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 21 Nov 2005 08:43:01.0133 (UTC) FILETIME=[949663D0:01C5EE77] X-Spam-Score: 0.3 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 24 Nov 2005 01:57:15 -0500 Subject: [Sip] Regarding Registrar behaviour in GRUU draft X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Karthik Kamaraj - NPD, Chennai =20 > Sent: Saturday, November 19, 2005 1:18 PM > To: 'sip-bounces@ietf.org' > Subject: RE: Regarding Registrar behaviour in GRUU draft >=20 > Hi, > I have one more doubt regarding this.Suppose Consider a case = where > UA Sends REGISTER request with Supported header has option tag as = "gruu" > and two Contact header one has "+sip.instance" header param another > doesn't have it. > I want to know the behaviour of registrar in this case. > Thanks in advance, > Karthik >=20 > -----Original Message----- > From: Karthik Kamaraj - NPD, Chennai =20 > Sent: Friday, November 18, 2005 8:46 PM > To: 'sip-bounces@ietf.org' > Subject: Regarding Registrar behaviour in GRUU draft >=20 > Hi, > Section in draft-ietf-sip-gruu-06 states that "As the > registrar is processing the contacts in the REGISTER request = according > to the procedures of step 7 in Section 10.3 of RFC 3261, > the registrar checks whether each Contact header field in the > REGISTER message contains a "+sip.instance" header field parameter.If > present, the contact is processed further. " >=20 > I want to know the behaviour of Registrar if it received REGISTER > request with Supported header has option tag as "gruu", but Contact = header > doesn't have "+sip.instance" header parameter.=20 >=20 > Thanks, > Karthik=20 >=20 Disclaimer: This message and any attachment(s) contained here are information that = is confidential, proprietary to HCL Technologies and its customers, = privileged or otherwise protected by law. The information is solely = intended for the individual or the entity it is addressed to. If you are = not the intended recipient of this message, you are not authorized to = read, forward, print, retain, copy or disseminate this message or any = part of it. If you have received this e-mail in error, please notify the = sender immediately by return e-mail and delete it from your computer. _______________________________________________ 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 From sip-bounces@ietf.org Thu Nov 24 01:57:19 2005 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 1EfB2l-0001BQ-3j; Thu, 24 Nov 2005 01:57:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeDte-0002Kc-1m for sip@megatron.ietf.org; Mon, 21 Nov 2005 10:47:58 -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 KAA10184 for ; Mon, 21 Nov 2005 10:47:20 -0500 (EST) Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeEC6-00078U-EE for sip@ietf.org; Mon, 21 Nov 2005 11:07:03 -0500 Received: from [131.161.248.90] (open-131-161-248-90.cliq.com [131.161.248.90]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id jALFloW17958; Mon, 21 Nov 2005 07:47:50 -0800 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Rohan Mahy Date: Mon, 21 Nov 2005 07:47:49 -0800 To: priti.sarode@flextronicssoftware.com X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 24 Nov 2005 01:57:15 -0500 Cc: Cullen Jennings , Rohan Mahy , sip@ietf.org Subject: [Sip] Re: pin-route option tag in outbound-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi Priti, This is not recommended. The first-hop proxy and the presence agent would both have to support pin-route (which seems unlikely for the presence agent), and the subscribe request would only be useful for fetching immediate presence. For the configuration framework, you can use the pin-route option to get your configuration on bootup. Then you should issue a new subscription using your GRUU (once you have registered) to get change notifications. The reason for this is that a single dialog using the pin-route option will only use the flow over which it was originally sent. If that flow dies, notifications won't get back to the subscriber, even if another flow is available. If you use a GRUU registered with multiple flows for outbound, only one of them has to work. thanks, -rohan On Nov 21, 2005, at 3:48, priti.sarode@flextronicssoftware.com wrote: > Hi, > > As per the outbound-01 draft, the pin-route option tag can be used by > UAs > that do not have a GRUU, > in SUBSCRIBE request sent to configuration framework. Can the same tag > also > be used > in SUBSCRIBE request sent to event framework (event- Presence) ? > > - Priti > > > > *********************** FSS-Unclassified *********************** > "DISCLAIMER: This message is proprietary to Flextronics Software > Systems > Limited (FSS) and is intended solely for the use of the > individual to whom it is addressed. It may contain privileged or > confidential information and should not be circulated or used for > any purpose other than for what it is intended. If you have received > this > message in error, please notify the originator immediately. > If you are not the intended recipient, you are notified that you are > strictly prohibited from using, copying, altering, or disclosing > the contents of this message. FSS accepts no responsibility for > loss or > damage arising from the use of the information transmitted > by this email including damage from virus." _______________________________________________ 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 From sip-bounces@ietf.org Thu Nov 24 01:57:20 2005 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 1EfB2m-0001Bv-C5; Thu, 24 Nov 2005 01:57:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eez4n-0007V4-7Z for sip@megatron.ietf.org; Wed, 23 Nov 2005 13:10: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 NAA05866 for ; Wed, 23 Nov 2005 13:09:57 -0500 (EST) Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EezNf-0001Hv-3v for sip@ietf.org; Wed, 23 Nov 2005 13:30:09 -0500 Received: from [131.161.248.90] (open-131-161-248-90.cliq.com [131.161.248.90]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id jANIAKW18006; Wed, 23 Nov 2005 10:10:20 -0800 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Rohan Mahy Date: Wed, 23 Nov 2005 10:10:20 -0800 To: priti.sarode@flextronicssoftware.com X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.2 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 24 Nov 2005 01:57:15 -0500 Cc: Cullen Jennings , Rohan Mahy , sip@ietf.org Subject: [Sip] Re: pin-route option tag in outbound-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org On Nov 23, 2005, at 4:02, priti.sarode@flextronicssoftware.com wrote: > Hi Rohan, > > Thanks for the response. > If pin-route option is not recommended for subscription dialog (event- > Presence), then how should the watcher behind NAT be supported ? subscribe using a GRUU > If GRUU is used in Contact header of SUBSCRIBE, it requires location > service lookup for the Contact and also requires watcher to register. yes > Is there anyway to support watchers behind NAT (subscription dialog ) > and not having GRUU ? not in a manner that allows the notifier to fail over to another flow. thanks, -rohan > Regards, > Priti > > > > > Rohan Mahy > > To > > priti.sarode@flextronicssoftware.co > 11/21/2005 09:17 m > PM > cc > Cullen Jennings > , > Rohan Mahy , > sip@ietf.org > > Subject > Re: pin-route option tag in > outbound-01 > > > > > > > > > > > Hi Priti, > > This is not recommended. The first-hop proxy and the presence agent > would both have to support pin-route (which seems unlikely for the > presence agent), and the subscribe request would only be useful for > fetching immediate presence. > > For the configuration framework, you can use the pin-route option to > get your configuration on bootup. Then you should issue a new > subscription using your GRUU (once you have registered) to get change > notifications. The reason for this is that a single dialog using the > pin-route option will only use the flow over which it was originally > sent. If that flow dies, notifications won't get back to the > subscriber, even if another flow is available. If you use a GRUU > registered with multiple flows for outbound, only one of them has to > work. > > thanks, > -rohan > > > On Nov 21, 2005, at 3:48, priti.sarode@flextronicssoftware.com wrote: >> Hi, >> >> As per the outbound-01 draft, the pin-route option tag can be used by >> UAs >> that do not have a GRUU, >> in SUBSCRIBE request sent to configuration framework. Can the same tag >> also >> be used >> in SUBSCRIBE request sent to event framework (event- Presence) ? >> >> - Priti >> >> >> >> *********************** FSS-Unclassified *********************** >> "DISCLAIMER: This message is proprietary to Flextronics Software >> Systems >> Limited (FSS) and is intended solely for the use of the >> individual to whom it is addressed. It may contain privileged or >> confidential information and should not be circulated or used for >> any purpose other than for what it is intended. If you have received >> this >> message in error, please notify the originator immediately. >> If you are not the intended recipient, you are notified that you are >> strictly prohibited from using, copying, altering, or disclosing >> the contents of this message. FSS accepts no responsibility for >> loss or >> damage arising from the use of the information transmitted >> by this email including damage from virus." > > > > > *********************** FSS-Unclassified *********************** > "DISCLAIMER: This message is proprietary to Hughes Software Systems > Limited > (HSS) and is intended solely for the use of the individual to whom it > is > addressed. It may contain privileged or confidential information and > should not be circulated or used for any purpose other than for what > it is > intended. If you have received this message in error, please notify the > originator immediately. If you are not the intended recipient, you are > notified that you are strictly prohibited from using, copying, > altering, or > disclosing the contents of this message. HSS accepts no responsibility > for > loss or damage arising from the use of the information transmitted by > this > email including damage from virus." _______________________________________________ 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 From sip-bounces@ietf.org Thu Nov 24 01:57:21 2005 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 1EfB2n-0001CN-O5; Thu, 24 Nov 2005 01:57:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeC3c-0005Li-Sm for sip@megatron.ietf.org; Mon, 21 Nov 2005 08:50:08 -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 IAA01242 for ; Mon, 21 Nov 2005 08:49:31 -0500 (EST) Received: from xproxy.gmail.com ([66.249.82.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeCM4-0003UE-Ay for sip@ietf.org; Mon, 21 Nov 2005 09:09:13 -0500 Received: by xproxy.gmail.com with SMTP id i26so663038wxd for ; Mon, 21 Nov 2005 05:50:06 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=S2kDl09SWMV74ADGOxsdz3Q3Uxh+fRtMsMXgLTRspyMfoYSR3XVTYgqGof3cxqGFO1n/mmO9nrN50a4Rqt3gSSwLFEjp960chzOz98HGkfXB1bs9ITFYzQt2zV1qsbNNTxtudTg+z+KA0SdScHLwsR4OxWhZh56y3W6m16MDxBM= Received: by 10.65.237.13 with SMTP id o13mr111541qbr; Mon, 21 Nov 2005 05:50:05 -0800 (PST) Received: by 10.65.182.9 with HTTP; Mon, 21 Nov 2005 05:50:05 -0800 (PST) Message-ID: <573eded90511210550ida06329u75cf29ae72f67d26@mail.gmail.com> Date: Mon, 21 Nov 2005 19:20:05 +0530 From: vinay singh To: sip-request@ietf.org, sip@ietf.org In-Reply-To: <573eded90511210548r3a67aa3bq14e7e7caae348b40@mail.gmail.com> MIME-Version: 1.0 References: <573eded90511210548r3a67aa3bq14e7e7caae348b40@mail.gmail.com> X-Spam-Score: 3.8 (+++) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab X-Mailman-Approved-At: Thu, 24 Nov 2005 01:57:15 -0500 Subject: [Sip] SIP Query X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0226152710==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org --===============0226152710== Content-Type: multipart/alternative; boundary="----=_Part_35540_25219921.1132581005054" ------=_Part_35540_25219921.1132581005054 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable hello sir, sir my self vinay singh and my friend akhilesh dwivedi we are going to make a testing tool on SIP Technology.and we are Fresher,we don't having any proper guidance so please sir help us. i got your mail id from Internet. as you are working on SIP Technology, overview of the project:: Firstly we are going to make a testing tool which will test the connection establishment between two sip terminals(sip phone).in this we having some problems like 1. system requirement(in java platform) 2. how to install SIP Stack. please suggest us some idea regarding this project. we are hopping a positive reply. thanking you akhilesh dwivedi ( akhi82@rediffmail.com ) vinay singh ( it_vinaysingh@yahoo.co.in ) ------=_Part_35540_25219921.1132581005054 Content-Type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable
 
hello sir,
sir my self vinay singh and my friend akhilesh dwivedi we are going to= make a testing tool on SIP Technology.and we are Fresher,we don't having a= ny proper guidance so please sir help us.
 i got your mail id from Internet. as you are working on SIP Tech= nology,
 
overview of the project::
 
Firstly we are going to make a testing tool which will test the connec= tion establishment between two sip terminals(sip phone).in this we having s= ome problems like
1. system requirement(in java platform)
2. how to install SIP Stack.
 
please suggest us some idea regarding this project.
 
we are hopping a positive reply.
 
thanking you
 
akhilesh dwivedi ( akhi82@red= iffmail.com )
 
 ------=_Part_35540_25219921.1132581005054-- --===============0226152710== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============0226152710==-- From sip-bounces@ietf.org Thu Nov 24 01:57:23 2005 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 1EfB2p-0001Co-6C; Thu, 24 Nov 2005 01:57:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeuAV-0001u6-Az; Wed, 23 Nov 2005 07:56:11 -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 HAA25156; Wed, 23 Nov 2005 07:55:31 -0500 (EST) Received: from [202.144.91.188] (helo=axestechnologies.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeuTG-0007K6-Lc; Wed, 23 Nov 2005 08:15:40 -0500 Received: from axesind ([192.168.5.3]) by axestechnologies.com (8.12.10+Sun/8.9.3) with ESMTP id jANCsag0025474; Wed, 23 Nov 2005 18:24:55 +0530 (IST) Received: from axestechnologies.com (unknown [192.168.1.104]) by axesind (Postfix) with ESMTP id CD7F2ACDA6; Wed, 23 Nov 2005 18:12:36 +0530 (IST) Message-ID: <438468FF.2030503@axestechnologies.com> Date: Wed, 23 Nov 2005 18:35:03 +0530 From: jijo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 24 Nov 2005 01:57:15 -0500 Cc: sip-implementors@cs.columbia.edu, IETF AVT WG Subject: [Sip] SIP Basic Authentication X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi All, I would like to know about the usage of SIP Baic Authnetication using OSIP library.. I wanted to send username and password as authentication parameters. Its looks like the OSIP library doesn't support Basic, as it supports only Digest. Please throw some light on this.. Thanks Jijo _______________________________________________ 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 From sip-bounces@ietf.org Thu Nov 24 02:33:43 2005 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 1EfBbz-0006LQ-O6; Thu, 24 Nov 2005 02:33:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfBbx-0006L4-A7 for sip@megatron.ietf.org; Thu, 24 Nov 2005 02:33:41 -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 CAA26423 for ; Thu, 24 Nov 2005 02:33:00 -0500 (EST) From: nagendra.swamy@flextronicssoftware.com Received: from delta.hssblr.co.in ([203.145.155.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfBuu-0000T9-96 for sip@ietf.org; Thu, 24 Nov 2005 02:53:20 -0500 Received: from espion.blr.hss.hns.com (espion.blr.hss.hns.com [10.203.193.21]) by delta.hssblr.co.in (8.11.6/8.11.6) with ESMTP id jAO7Wxx17641; Thu, 24 Nov 2005 13:03:00 +0530 To: Cullen Jennings , Rohan Mahy , sip@ietf.org X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: Date: Thu, 24 Nov 2005 12:59:28 +0530 X-MIMETrack: Serialize by Router on Espion/BLR/HSS(Release 6.5|September 18, 2003) at 11/24/2005 01:19:29 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.5 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: Subject: [Sip] Re: pin-route option tag in outbound-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi Rohan, Some comments inlined Regards Nagendra. Rohan Mahy To priti.sarode@flextronicssoftware.co 11/21/2005 09:17 m PM cc Cullen Jennings , Rohan Mahy , sip@ietf.org Subject Re: pin-route option tag in outbound-01 Hi Priti, This is not recommended. The first-hop proxy and the presence agent would both have to support pin-route (which seems unlikely for the presence agent), and the subscribe request would only be useful for fetching immediate presence. Nagendra>> I completely agree with this in case the presence agent is behind the Proxy. I mean if the first hop after the NAT is not the presence agent then presence agent need not to support the pin-route option. But what if first hop after the NAT is itself presence-server(which works as defined in RFC 3265)?. Now it is the responsibility of the presence server to maintaint the connection, isn't it?. In this case, can pin-route option be a solution? For the configuration framework, you can use the pin-route option to get your configuration on bootup. Then you should issue a new subscription using your GRUU (once you have registered) to get change notifications. The reason for this is that a single dialog using the pin-route option will only use the flow over which it was originally sent. If that flow dies, notifications won't get back to the subscriber, even if another flow is available. If you use a GRUU registered with multiple flows for outbound, only one of them has to work. Nagendra>> But, inorder to subscribe for the status of a presentity, watcher is not required to register first. Are you suggesting to mandate the registration before subscription?. thanks, -rohan On Nov 21, 2005, at 3:48, priti.sarode@flextronicssoftware.com wrote: > Hi, > > As per the outbound-01 draft, the pin-route option tag can be used by > UAs > that do not have a GRUU, > in SUBSCRIBE request sent to configuration framework. Can the same tag > also > be used > in SUBSCRIBE request sent to event framework (event- Presence) ? > > - Priti > *********************** FSS-Unclassified *********************** *********************** FSS-Unclassified *********************** "DISCLAIMER: This message is proprietary to Flextronics Software Systems Limited (FSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." _______________________________________________ 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 From sip-bounces@ietf.org Thu Nov 24 02:41:12 2005 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 1EfBjE-0001Bj-Tb; Thu, 24 Nov 2005 02:41:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfBjC-0001BY-Mw; Thu, 24 Nov 2005 02:41:10 -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 CAA27119; Thu, 24 Nov 2005 02:40:30 -0500 (EST) Received: from gw-eur4.philips.com ([161.85.125.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfC2C-0000gJ-Ty; Thu, 24 Nov 2005 03:00:50 -0500 Received: from smtpscan-eur4.philips.com (smtpscan-eur4.mail.philips.com [130.144.57.167]) by gw-eur4.philips.com (Postfix) with ESMTP id 5EA9749707; Thu, 24 Nov 2005 07:40:51 +0000 (UTC) Received: from smtpscan-eur4.philips.com (localhost [127.0.0.1]) by localhost.philips.com (Postfix) with ESMTP id EB406509C3B; Thu, 24 Nov 2005 07:40:50 +0000 (GMT) Received: from smtprelay-eur2.philips.com (smtprelay-eur2.philips.com [130.144.57.171]) by smtpscan-eur4.philips.com (Postfix) with ESMTP id BFB13509C13; Thu, 24 Nov 2005 07:40:50 +0000 (GMT) Received: from ehvrmh02.diamond.philips.com (ehvrmh02-srv.diamond.philips.com [130.139.27.125]) by smtprelay-eur2.philips.com (Postfix) with ESMTP id 9E7383B; Thu, 24 Nov 2005 07:40:50 +0000 (GMT) In-Reply-To: <438468FF.2030503@axestechnologies.com> To: jijo Subject: Re: [Sip] SIP Basic Authentication MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.3 September 26, 2003 Message-ID: From: Frank Derks Date: Thu, 24 Nov 2005 08:39:02 +0100 X-MIMETrack: Serialize by Router on ehvrmh02/H/SERVER/PHILIPS(Release 6.5.3FP1HF291 | September 19, 2005) at 24/11/2005 08:39:08, Serialize complete at 24/11/2005 08:39:08 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: sip@ietf.org, sip-implementors@cs.columbia.edu, sip-bounces@ietf.org, IETF AVT WG X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi Jijo, RFC 3261 specifically states that Basic Authentication is NOT allowed for SIP. For this reason OSIP does NOT support this. Cheers, Frank jijo Sent by: sip-bounces@ietf.org 2005-11-23 02:05 PM To sip@ietf.org cc sip-implementors@cs.columbia.edu IETF AVT WG Subject [Sip] SIP Basic Authentication Classification Hi All, I would like to know about the usage of SIP Baic Authnetication using OSIP library.. I wanted to send username and password as authentication parameters. Its looks like the OSIP library doesn't support Basic, as it supports only Digest. Please throw some light on this.. Thanks Jijo _______________________________________________ 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 From sip-bounces@ietf.org Mon Nov 28 07:52:10 2005 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 1EgiUM-0000W8-MY; Mon, 28 Nov 2005 07:52:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgiUJ-0000UM-6W for sip@megatron.ietf.org; Mon, 28 Nov 2005 07:52:07 -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 HAA29171 for ; Mon, 28 Nov 2005 07:51:23 -0500 (EST) Received: from smtp12.clb.oleane.net ([213.56.31.47]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Egio8-0004CR-3M for sip@ietf.org; Mon, 28 Nov 2005 08:12:39 -0500 Received: from Pavillonquatre ([194.3.133.88]) (authenticated) by smtp12.clb.oleane.net with ESMTP id jASCpbxr019028 for ; Mon, 28 Nov 2005 13:51:42 +0100 Message-Id: <200511281251.jASCpbxr019028@smtp12.clb.oleane.net> From: "Chantal Ladouce" To: Date: Mon, 28 Nov 2005 13:51:11 +0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcX0Gmiu+9k+Xvj1RNW8tooh45MUTw== X-Spam-Score: 0.2 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Subject: [Sip] WiMAX Summit 06 - Paris - France X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1304294660==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1304294660== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0323_01C5F422.CAC5E740" This is a multi-part message in MIME format. ------=_NextPart_000_0323_01C5F422.CAC5E740 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit WiMAX Summit 06: Incumbent and New Entrant Operators Architectures The WiMAX Summit 2006 will be held on February 21 to 24 at the Sofitel Bercy hotel in Paris. Capitalizing on the 2005 edition success, the organizer, Upper Side plans to welcome more than 200 participants and more than 20 exhibitors, making WiMAX Summit the most important event in Europe. The conference will largely be devoted to case studies presented by both incumbent and new entrant operators who have set up WiMAX infrastructures. Get all details on the following link: http://www.upperside.fr/wimax2006/wimax2006intro.htm ------=_NextPart_000_0323_01C5F422.CAC5E740 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

WiMAX = Summit 06: Incumbent and New Entrant Operators = Architectures

 

The WiMAX Summit 2006 will be held on = February 21 to = 24 at the Sofitel Bercy hotel in Paris.
Capitalizing on the 2005 edition success, the organizer, Upper Side = plans to welcome more than 200 participants and more than 20 exhibitors, making = WiMAX Summit the most important event in Europe.

 

The conference will largely be devoted to case = studies presented by both incumbent and new entrant operators who have set up = WiMAX infrastructures.  

Get all details on the following = link:

 

http://www.upperside.fr/wimax2006/wimax2006intro.htm<= /a>

 

------=_NextPart_000_0323_01C5F422.CAC5E740-- --===============1304294660== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1304294660==-- From sip-bounces@ietf.org Mon Nov 28 15:02:30 2005 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 1EgpCn-0000o3-VL; Mon, 28 Nov 2005 15:02:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgpCm-0000nr-De for sip@megatron.ietf.org; Mon, 28 Nov 2005 15:02:28 -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 PAA27583 for ; Mon, 28 Nov 2005 15:01:44 -0500 (EST) Received: from bdsoft10.vwh.net ([130.94.149.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EgpWg-0004Xx-Ii for sip@ietf.org; Mon, 28 Nov 2005 15:23:04 -0500 Received: from brett1 (ip67-88-7-2.z7-88-67.customer.algx.net [67.88.7.2]) (authenticated bits=0) by bdsoft10.vwh.net (8.13.1/8.12.11) with ESMTP id jASK22SI063096; Mon, 28 Nov 2005 15:02:07 -0500 (EST) From: "Brett Tate" To: "'Maxime JOSSET'" , Subject: RE: [Sip] message UPDATE Date: Mon, 28 Nov 2005 15:02:34 -0500 Message-ID: <000901c5f456$adb237b0$2c28a8c0@brett1> 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.6626 In-Reply-To: <200511221654.LAA11280@ietf.org> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-PMX-IsInternal: True X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org > Do you think that this is the flow of UPDATE that > make the remote peer close the com ? The lack of response to UPDATE can trigger a BYE. > Why does the peer A send the message UPDATE > after 1O minutes time . It is most likely sent to refresh the session or check if the session still exists. > Do you think about a bad configuration of one peer ? It could be a bad configuration or intended behavior by the device sending the ICMP message "destination unreachable (port unreachable)". It depends upon how the device allocates ports, the status of the device, and the status of the dialog. _______________________________________________ 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 From sip-bounces@ietf.org Tue Nov 29 12:02:35 2005 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 1Eh8sF-0007PF-Fn; Tue, 29 Nov 2005 12:02:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh8sD-0007P7-R1 for sip@megatron.ietf.org; Tue, 29 Nov 2005 12:02:33 -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 MAA03581 for ; Tue, 29 Nov 2005 12:01:47 -0500 (EST) Received: from mail2.hutchison.com.au ([203.18.188.195] helo=mailsweeper2.orange.net.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eh9CG-00031L-B5 for sip@ietf.org; Tue, 29 Nov 2005 12:23:20 -0500 Received: from mail.hutch.com.au (unverified [203.31.24.24]) by mailsweeper2.orange.net.au (Content Technologies SMTPRS 4.3.19) with ESMTP id for ; Wed, 30 Nov 2005 04:01:37 +1100 Received: from GWACCESS-MTA by mail.hutch.com.au with Novell_GroupWise; Wed, 30 Nov 2005 04:02:10 +1100 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.4 Date: Wed, 30 Nov 2005 04:01:53 +1100 From: "Philip Walls" To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: quoted-printable Subject: [Sip] Re: Sip Digest, Vol 19, Issue 29 (Out of office) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Thanks for your email. Sorry, but I'll be out of the office from Wed 30 Nov until Mon 16 Jan. =20 In my absence, please contact Angus Clearie +61 (0)433-132-823. Hope you have a Merry Christmas & a safe & happy New Year. Cheers Phil _______________________________________________ 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 From sip-bounces@ietf.org Wed Nov 30 01:21:11 2005 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 1EhLL5-0007TE-5Y; Wed, 30 Nov 2005 01:21:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhLL2-0007T9-Uo for sip@megatron.ietf.org; Wed, 30 Nov 2005 01:21:09 -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 BAA01247 for ; Wed, 30 Nov 2005 01:20:19 -0500 (EST) Received: from [219.141.250.5] (helo=mail) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhLfA-0005mp-NS for sip@ietf.org; Wed, 30 Nov 2005 01:42:00 -0500 Received: from asechenshuping (hw-lixiang.cecwireless.com.cn [10.2.5.43]) by mail.cecwireless.com.cn (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTPA id <0IQR00G8Z89VSG@mail.cecwireless.com.cn> for sip@ietf.org; Wed, 30 Nov 2005 14:20:23 +0800 (CST) Date: Wed, 30 Nov 2005 14:20:26 +0800 From: Chen Shuping To: sip@ietf.org Message-id: <000901c5f576$27d5db80$2b05020a@cecwireless.com.cn> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcX1diZzXhpxgyhnTfydfKN4fGjMWA== X-Spam-Score: 0.3 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Subject: [Sip] [SIP Cacel Method] X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0634286103==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0634286103== Content-type: multipart/alternative; boundary="Boundary_(ID_Ue9nQxm9HwIkGv+B6Ka4gw)" This is a multi-part message in MIME format. --Boundary_(ID_Ue9nQxm9HwIkGv+B6Ka4gw) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT Hi,All I have such a doubt: In RFC 3261 17.1.1.2 Time_B timeout in Calling state,Invite transaction transit to terminated state,What if Timer_B timeout in Proceeding state(this could happen when the callee is not in office, his softphone keep ringring until caller's timer_b timeout). In my implementation my call flow like this: CASE 1: caller callee ------------INVITE-------------------> <-----------100 Trying----------------- <-----------180 Ringing-------------- caller hang up --------------Cancel-----------------> <-------------200 for Cancel-------- <-------------487---------------------- ---------------ACK------------------> CASE 2: INVITE-------------------> <-----------100 Trying----------------- <-----------180 Ringing-------------- caller keep waiting ,Timer_b time out --------------Cancel-----------------> <-------------200 for Cancel-------- <-------------487---------------------- <-------------487---------------------- <-------------487---------------------- <-------------487---------------------- <-------------487---------------------- My question is should I generate ACK for the second case. Thanks --Boundary_(ID_Ue9nQxm9HwIkGv+B6Ka4gw) Content-type: text/html; charset=us-ascii Content-Transfer-Encoding: 7BIT
Hi,All
 
  I have such a doubt:
 
   In RFC 3261 17.1.1.2  Time_B timeout in Calling state,Invite transaction transit to terminated
 
state,What if Timer_B timeout in Proceeding  state(this could happen when the callee is not in office,
 
his softphone keep ringring until caller's timer_b timeout).
 
In my implementation my call flow like this:
 
CASE 1:
 
caller                                          callee
------------INVITE------------------->
<-----------100 Trying-----------------
<-----------180 Ringing--------------
 
caller hang up
 
--------------Cancel----------------->
<-------------200 for Cancel--------
<-------------487----------------------
---------------ACK------------------>
 
CASE 2:
 
INVITE------------------->
<-----------100 Trying-----------------
<-----------180 Ringing--------------
 
caller keep waiting ,Timer_b time out
 
--------------Cancel----------------->
<-------------200 for Cancel--------
<-------------487----------------------
<-------------487----------------------
<-------------487----------------------
<-------------487----------------------
<-------------487----------------------
 
My question is should I generate ACK for the second case.
 
 
Thanks
 
 
 
 
--Boundary_(ID_Ue9nQxm9HwIkGv+B6Ka4gw)-- --===============0634286103== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============0634286103==-- From sip-bounces@ietf.org Wed Nov 30 02:35:01 2005 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 1EhMUX-0000lk-L1; Wed, 30 Nov 2005 02:35:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhMUV-0000la-JX for sip@megatron.ietf.org; Wed, 30 Nov 2005 02:34:59 -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 CAA09342 for ; Wed, 30 Nov 2005 02:34:12 -0500 (EST) From: sreeram.kanumuri@wipro.com Received: from wip-ec-wd.wipro.com ([203.91.193.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhMoW-0008GU-H0 for sip@ietf.org; Wed, 30 Nov 2005 02:55:54 -0500 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id 39B4920633 for ; Wed, 30 Nov 2005 12:50:50 +0530 (IST) Received: from blr-ec-bh02.wipro.com (blr-ec-bh02.wipro.com [10.201.50.92]) by wip-ec-wd.wipro.com (Postfix) with ESMTP id 1C9CA205D9 for ; Wed, 30 Nov 2005 12:50:50 +0530 (IST) Received: from BLR-EC-MBX02.wipro.com ([10.201.50.162]) by blr-ec-bh02.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Nov 2005 13:04:04 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] [SIP Cacel Method] Date: Wed, 30 Nov 2005 13:04:03 +0530 Message-ID: Thread-Topic: [Sip] [SIP Cacel Method] Thread-Index: AcX1diZzXhpxgyhnTfydfKN4fGjMWAACNh8g To: , X-OriginalArrivalTime: 30 Nov 2005 07:34:04.0151 (UTC) FILETIME=[7078C870:01C5F580] X-Spam-Score: 0.8 (/) X-Scan-Signature: 223e3c753032a50d5dc4443c921c3fcd Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0897769612==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0897769612== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5F580.702980D4" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5F580.702980D4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes you must generate ACK in second case also. =20 also, in case2) it is not "timerb timeout" as the caller received provisional response its state machine goes to "proceeding state" It should be some other timer implemented at the uac to handle the case when there is no final response in the "proceeding state" =20 =20 HTH, Sreeram. ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Chen Shuping Sent: Wednesday, November 30, 2005 11:50 AM To: sip@ietf.org Subject: [Sip] [SIP Cacel Method] Hi,All =20 I have such a doubt: =20 In RFC 3261 17.1.1.2 Time_B timeout in Calling state,Invite transaction transit to terminated =20 state,What if Timer_B timeout in Proceeding state(this could happen when the callee is not in office, =20 his softphone keep ringring until caller's timer_b timeout). =20 In my implementation my call flow like this: =20 CASE 1: =20 caller callee ------------INVITE-------------------> <-----------100 Trying----------------- <-----------180 Ringing-------------- =20 caller hang up =20 --------------Cancel-----------------> <-------------200 for Cancel-------- <-------------487---------------------- ---------------ACK------------------> =20 CASE 2: =20 INVITE------------------->=20 <-----------100 Trying----------------- <-----------180 Ringing-------------- =20 caller keep waiting ,Timer_b time out =20 --------------Cancel-----------------> <-------------200 for Cancel-------- <-------------487---------------------- <-------------487---------------------- <-------------487---------------------- <-------------487---------------------- <-------------487---------------------- =20 My question is should I generate ACK for the second case. =20 =20 Thanks =20 =20 =20 =20 ------_=_NextPart_001_01C5F580.702980D4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
From: sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org] On Behalf Of Chen = Shuping
Sent:=20 Wednesday, November 30, 2005 11:50 AM
To:=20 sip@ietf.org
Subject: [Sip] [SIP Cacel = Method]

Hi,All
 
  I have=20 such a doubt:
 
   In RFC = 3261=20 17.1.1.2  Time_B timeout in Calling state,Invite transaction = transit to=20 terminated
 
state,What if = Timer_B timeout=20 in Proceeding  state(this could happen when the callee is not in=20 office,
 
Yes you must generate ACK in second case=20 also.
 
also, in case2) it is not "timerb timeout" as = the=20 caller received provisional response its state machine goes to = "proceeding=20 state"
It should be some other timer = implemented  at the uac to handle the=20 case  when there is no final response in the "proceeding=20 state"   =20
 
HTH,
Sreeram.
his softphone keep = ringring=20 until caller's timer_b timeout).
 
In my = implementation my call=20 flow like this:
 
CASE = 1:
 
caller         &nbs= p;            = ;            =        =20 callee
------------INVITE------------------->
<-----------100=20 Trying-----------------
<-----------180=20 Ringing--------------
 
caller hang=20 up
 
--------------Cancel----------------->
<-------------200 for=20 Cancel--------
<-------------487----------------------
---------------ACK------------------>
 
CASE = 2:
 
INVITE------------------->=20
<-----------100=20 Trying-----------------
<-----------180=20 Ringing--------------
 
caller keep waiting = ,Timer_b=20 time out
 
--------------Cancel----------------->
<-------------200 for=20 Cancel--------
<-------------487----------------------
<-------------487----------------------
<-------------487----------------------
<-------------487----------------------
<-------------487----------------------
 
My question is = should I=20 generate ACK for the second case.
 
 
Thanks
 
 
 
 
------_=_NextPart_001_01C5F580.702980D4-- --===============0897769612== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============0897769612==-- From sip-bounces@ietf.org Wed Nov 30 05:06:51 2005 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 1EhOrT-0000zq-Pr; Wed, 30 Nov 2005 05:06:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhOrS-0000ys-5o for sip@megatron.ietf.org; Wed, 30 Nov 2005 05:06:50 -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 FAA23518 for ; Wed, 30 Nov 2005 05:06:04 -0500 (EST) Received: from [202.54.64.17] (helo=hclnpd.hclt-ntl.co.in) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhPBh-0004XX-Bb for sip@ietf.org; Wed, 30 Nov 2005 05:27:46 -0500 Received: from npd-mail1.hclt-ntl.co.in ([10.105.1.106]) by hclnpd.hclt-ntl.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id WFGCPKJT; Wed, 30 Nov 2005 15:36:37 +0530 X-MessageTextProcessor: DisclaimIt (2.50.252) [HCL Technologies Ltd., Chennai, India] Content-Class: urn:content-classes:message Received: from npd-mail.hclt-ntl.co.in ([10.105.1.104]) by npd-mail1.hclt-ntl.co.in with Microsoft SMTPSVC(5.0.2195.6713); Wed, 30 Nov 2005 15:36:37 +0530 Received: by npd-mail.hclt-ntl.co.in with Internet Mail Service (5.5.2657.72) id ; Wed, 30 Nov 2005 15:36:37 +0530 Message-ID: <4B1D6623CCBD79489DE28D1CA062A47E016BCA9A@npd-mail.hclt-ntl.co.in> From: "Prakash Maria susai - NPD, Chennai" To: , , Subject: RE: [Sip] [SIP Cacel Method] Date: Wed, 30 Nov 2005 15:36:34 +0530 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Mailer: Internet Mail Service (5.5.2657.72) X-OriginalArrivalTime: 30 Nov 2005 10:06:37.0180 (UTC) FILETIME=[C01A2BC0:01C5F595] X-Spam-Score: 0.8 (/) X-Scan-Signature: a630332fa112280ecc4c4186b5c9ea83 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1034701875==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1034701875== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5F595.BE783B90" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5F595.BE783B90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 As Sreeram has mentioned, it cannot be Timer B, since Timer B is not = active once 1xx is got. The some other timer could be a Timer started through Expires Header indicated in INVITE request. =20 Thanks, Prakash. -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of sreeram.kanumuri@wipro.com Sent: Wednesday, November 30, 2005 1:04 PM To: shuping.chen@cecwireless.com.cn; sip@ietf.org Subject: RE: [Sip] [SIP Cacel Method] Yes you must generate ACK in second case also. =20 also, in case2) it is not "timerb timeout" as the caller received provisional response its state machine goes to "proceeding state" It should be some other timer implemented at the uac to handle the case when there is no final response in the "proceeding state" =20 =20 HTH, Sreeram. _____ =20 From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of = Chen Shuping Sent: Wednesday, November 30, 2005 11:50 AM To: sip@ietf.org Subject: [Sip] [SIP Cacel Method] Hi,All =20 I have such a doubt: =20 In RFC 3261 17.1.1.2 Time_B timeout in Calling state,Invite = transaction transit to terminated =20 state,What if Timer_B timeout in Proceeding state(this could happen = when the callee is not in office, =20 his softphone keep ringring until caller's timer_b timeout). =20 In my implementation my call flow like this: =20 CASE 1: =20 caller callee ------------INVITE-------------------> <-----------100 Trying----------------- <-----------180 Ringing-------------- =20 caller hang up =20 --------------Cancel-----------------> <-------------200 for Cancel-------- <-------------487---------------------- ---------------ACK------------------> =20 CASE 2: =20 INVITE------------------->=20 <-----------100 Trying----------------- <-----------180 Ringing-------------- =20 caller keep waiting ,Timer_b time out =20 --------------Cancel-----------------> <-------------200 for Cancel-------- <-------------487---------------------- <-------------487---------------------- <-------------487---------------------- <-------------487---------------------- <-------------487---------------------- =20 My question is should I generate ACK for the second case. =20 =20 Thanks =20 =20 =20 =20 Disclaimer: This message and any attachment(s) contained here are information that = is confidential, proprietary to HCL Technologies and its customers, = privileged or otherwise protected by law. The information is solely = intended for the individual or the entity it is addressed to. If you are = not the intended recipient of this message, you are not authorized to = read, forward, print, retain, copy or disseminate this message or any = part of it. If you have received this e-mail in error, please notify the = sender immediately by return e-mail and delete it from your computer. ------_=_NextPart_001_01C5F595.BE783B90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
As=20 Sreeram has mentioned, it cannot be Timer B, since Timer B is not active = once=20 1xx is got.
The=20 some other timer could be a Timer started through Expires Header = indicated in=20 INVITE request.
 
Thanks,
Prakash.
-----Original Message-----
From: = sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org]On Behalf Of=20 sreeram.kanumuri@wipro.com
Sent: Wednesday, November 30, = 2005=20 1:04 PM
To: shuping.chen@cecwireless.com.cn;=20 sip@ietf.org
Subject: RE: [Sip] [SIP Cacel=20 Method]

Yes you must generate ACK in second case=20 also.
 
also, in case2) it is not "timerb timeout" = as the=20 caller received provisional response its state machine goes to = "proceeding=20 state"
It should be some other timer = implemented  at the uac to handle the = case  when there is no final response in the = "proceeding=20 state"   =20
 
HTH,
Sreeram.

From: sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org] On Behalf Of Chen = Shuping
Sent:=20 Wednesday, November 30, 2005 11:50 AM
To:=20 sip@ietf.org
Subject: [Sip] [SIP Cacel = Method]

Hi,All
 
  I have=20 such a doubt:
 
   In = RFC 3261=20 17.1.1.2  Time_B timeout in Calling state,Invite transaction = transit to=20 terminated
 
state,What if = Timer_B timeout=20 in Proceeding  state(this could happen when the callee is not in=20 office,
 
his softphone = keep ringring=20 until caller's timer_b timeout).
 
In my = implementation my call=20 flow like this:
 
CASE = 1:
 
caller         &nbs= p;            = ;            =        =20 callee
------------INVITE------------------->
<-----------100=20 Trying-----------------
<-----------180=20 Ringing--------------
 
caller hang=20 up
 
--------------Cancel----------------->
<-------------200 for=20 Cancel--------
<-------------487----------------------
---------------ACK------------------>
 
CASE = 2:
 
INVITE------------------->=20
<-----------100=20 Trying-----------------
<-----------180=20 Ringing--------------
 
caller keep = waiting ,Timer_b=20 time out
 
--------------Cancel----------------->
<-------------200 for=20 Cancel--------
<-------------487----------------------
<-------------487----------------------
<-------------487----------------------
<-------------487----------------------
<-------------487----------------------
 
My question is = should I=20 generate ACK for the second case.
 
 
Thanks
 
 
 
 

Disclaimer: This message and any attachment(s) contained here are information that = is confidential, proprietary to HCL Technologies and its customers, = privileged or otherwise protected by law. The information is solely = intended for the individual or the entity it is addressed to. If you are = not the intended recipient of this message, you are not authorized to = read, forward, print, retain, copy or disseminate this message or any = part of it. If you have received this e-mail in error, please notify the = sender immediately by return e-mail and delete it from your computer.

------_=_NextPart_001_01C5F595.BE783B90-- --===============1034701875== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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 --===============1034701875==-- From sip-bounces@ietf.org Wed Nov 30 07:51:43 2005 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 1EhRR1-0004bq-P4; Wed, 30 Nov 2005 07:51:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhRQz-0004Yj-1G; Wed, 30 Nov 2005 07:51:41 -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 HAA09752; Wed, 30 Nov 2005 07:50:54 -0500 (EST) From: khairunnisa.hassanali@flextronicssoftware.com Received: from delta.hssblr.co.in ([203.145.155.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhRlE-0001CO-GY; Wed, 30 Nov 2005 08:12:38 -0500 Received: from espion.blr.hss.hns.com (espion.blr.hss.hns.com [10.203.193.21]) by delta.hssblr.co.in (8.11.6/8.11.6) with ESMTP id jAUCpNx27824; Wed, 30 Nov 2005 18:21:23 +0530 Subject: Re:[Sip] [SIP Cacel Method] To: Chen Shuping X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: Date: Wed, 30 Nov 2005 18:17:38 +0530 X-MIMETrack: Serialize by Router on Espion/BLR/HSS(Release 6.5|September 18, 2003) at 11/30/2005 06:21:38 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.5 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: sip@ietf.org, sip-bounces@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Hi, Please find my response within Regards Nisha Chen Shuping To Sent by: sip@ietf.org sip-bounces@ietf. cc org Subject [Sip] [SIP Cacel Method] 11/30/2005 11:50 AM Hi,All I have such a doubt: In RFC 3261 17.1.1.2 Time_B timeout in Calling state,Invite transaction transit to terminated state,What if Timer_B timeout in Proceeding state(this could happen when the callee is not in office, his softphone keep ringring until caller's timer_b timeout). In my implementation my call flow like this: CASE 1: caller callee ------------INVITE-------------------> <-----------100 Trying----------------- <-----------180 Ringing-------------- caller hang up --------------Cancel-----------------> <-------------200 for Cancel-------- <-------------487---------------------- ---------------ACK------------------> CASE 2: INVITE-------------------> <-----------100 Trying----------------- <-----------180 Ringing-------------- caller keep waiting ,Timer_b time out --------------Cancel-----------------> <-------------200 for Cancel-------- <-------------487---------------------- <-------------487---------------------- <-------------487---------------------- <-------------487---------------------- <-------------487---------------------- My question is should I generate ACK for the second case. According to Section 13.1 of RFC, a UAC should respond with an ACK for every final response that it receives. In this case, 487 is a final response therefore an ACK must be generated in the CASE 2 described above. ----------------------Extract from RFC 3261---------------------------------------------------------- After possibly receiving one or more provisional responses, the UAC will get one or more 2xx responses or one non-2xx final response. Because of the protracted amount of time it can take to receive final responses to INVITE, the reliability mechanisms for INVITE transactions differ from those of other requests (like OPTIONS). Once it receives a final response, the UAC needs to send an ACK for every final response it receives. The procedure for sending this ACK depends on the type of response. For final responses between 300 and 699, the ACK processing is done in the transaction layer and follows one set of rules (See Section 17). For 2xx responses, the ACK is generated by the UAC core. ---------------------------End of extract from RFC 3261--------------------------------------------------- Thanks *********************** FSS-Unclassified *********************** "DISCLAIMER: This message is proprietary to Flextronics Software Systems Limited (FSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." _______________________________________________ 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 From sip-bounces@ietf.org Wed Nov 30 11:45:56 2005 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 1EhV5g-0003sx-KB; Wed, 30 Nov 2005 11:45:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhV5e-0003sP-Od; Wed, 30 Nov 2005 11:45:54 -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 LAA08816; Wed, 30 Nov 2005 11:45:09 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] helo=nostrum.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhVPw-0001Ah-Li; Wed, 30 Nov 2005 12:06:54 -0500 Received: from [172.17.2.252] (dsl001-129-069.dfw1.dsl.speakeasy.net [72.1.129.69]) (authenticated bits=0) by nostrum.com (8.12.11/8.12.11) with ESMTP id jAUGioiJ052987 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 30 Nov 2005 10:45:48 -0600 (CST) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: 7bit Message-Id: <6C480FF6-4C06-40C1-9E09-942F326AF70E@nostrum.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: "sip@ietf.org WG" , SIMPLE mailing list From: Robert Sparks Date: Wed, 30 Nov 2005 10:45:48 -0600 X-Mailer: Apple Mail (2.746.2) Received-SPF: pass (nostrum.com: 72.1.129.69 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Cc: Subject: [Sip] SIPIT 18 schedule X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org Folks - SIPIT 18 has been scheduled for the week of April 17, 2006 in Tokyo. JPNIC is hosting the event, with the support of the WIDE project, NiCT, MIC, TTC, HATS and others. Registration will open in a few weeks. www.sipit.net will have details as they become available. I just wanted to let everyone know the date and place as soon as possible. Thanks, RjS _______________________________________________ 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 From sip-bounces@ietf.org Wed Nov 30 14:39:43 2005 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 1EhXnr-0007Uy-CU; Wed, 30 Nov 2005 14:39:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhXnn-0007R2-RE; Wed, 30 Nov 2005 14:39:40 -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 OAA02609; Wed, 30 Nov 2005 14:38:53 -0500 (EST) Received: from pine.neustar.com ([209.173.57.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhY89-00088C-3H; Wed, 30 Nov 2005 15:00:41 -0500 Received: from stntsmtp1.cis.neustar.com (smartexch.neustar.com [10.31.13.79]) by pine.neustar.com (8.12.8/8.11.0) with ESMTP id jAUJYZtC003582; Wed, 30 Nov 2005 19:38:35 GMT Received: from stntexch01.cis.neustar.com ([10.31.13.43]) by stntsmtp1.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Nov 2005 14:36:18 -0500 Received: from 10.31.34.133 ([10.31.34.133]) by stntexch01.cis.neustar.com ([10.31.13.43]) with Microsoft Exchange Server HTTP-DAV ; Wed, 30 Nov 2005 19:36:17 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Wed, 30 Nov 2005 14:37:25 -0500 Subject: Re: [Sip] AW: Comment on draft-schwartz-sipping-spit-saml-00 From: Peter Davis To: "Tschofenig, Hannes" , Otmar Lendl , , , Message-ID: Thread-Topic: [Sip] AW: Comment on draft-schwartz-sipping-spit-saml-00 Thread-Index: AcXpOzeUo0WNAfT1QQyrGK8ysWf5WACeNnEgAoxbA1Q= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 30 Nov 2005 19:36:18.0076 (UTC) FILETIME=[5580FDC0:01C5F5E5] X-Spam-Score: 0.2 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Cc: SIp , sipping@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org >> * The XML (SAML) framents look overly complex: >> I haven't read the SAML spec itself, but the example >> >> > AttributeName="IdentityStrength" >> AttributeNamespace="http://mio.com"> >> 2 >> >> >> >> looks overly contorted. Why not the following? >> >> 2 > > i will look at this aspect in the next few days. let me send you a > response about it later. the usage of the attribute statement seems to > be the right way forward but i am not sure about the details at the > moment. we, however, might not be able to put arbitrary xml statements > in a saml assertion. > Might I suggest making use of the security mechanisms (authentication context) vocabulary the SSTC @ OASIS produced [1]. Rather than requiring a subjective gradation of various security mechanism strengths, one simply conveys the mechanism in use for the given session. These are normatively defined URNs in [1]. Adding new security mechanisms as above would allow sufficient extensibility, I think. It also allows for 'private' mechanisms, for closed deployments. SAML advice provides the extention point you seek for arbitrary XML: =peterd [1] http://docs.oasis-open.org/security/saml/v2.0/saml-authn-context-2.0-os.pdf _______________________________________________ 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