From mailnull@www1.ietf.org Sun Dec 1 23:09:23 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23052 for ; Sun, 1 Dec 2002 23:09:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB24Bmp20254 for sip-archive@odin.ietf.org; Sun, 1 Dec 2002 23:11:48 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB24BLv20235; Sun, 1 Dec 2002 23:11:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB249wv20104 for ; Sun, 1 Dec 2002 23:09:58 -0500 Received: from mta0 (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22979 for ; Sun, 1 Dec 2002 23:07:00 -0500 (EST) Received: from prasannacl1105 (mta0 [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0H6H00CMX4TCKH@mta0.huawei.com> for sip@ietf.org; Mon, 02 Dec 2002 12:08:02 +0800 (CST) Date: Mon, 02 Dec 2002 09:35:53 +0530 From: Prasanna Venkatesh Subject: RE: [Sip] B2BUA In-reply-to: <000f01c29825$4ed3a3e0$0100a8c0@txdwillis> To: Dean Willis , Juan-Carlos.Rojas@alcatel.fr, sip@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT May be in place of "n" "two or more" is better.. -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Dean Willis Sent: Saturday, November 30, 2002 9:32 AM To: Juan-Carlos.Rojas@alcatel.fr; sip@ietf.org Subject: RE: [Sip] B2BUA Juan-Carlos said: > Back-to-Back User Agent: A SIP element being able to handle a > collection of "n" User Agents (behaving each one as UAC and > UAS, according to SIP rules), which are linked by some > application logic that is fully independent of the SIP protocol rules. This seems like a reasonable definition. Poll: Would it be worth including this in 3261bis? Do we need to say N>1? -- 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 mailnull@www1.ietf.org Sun Dec 1 23:10:55 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23088 for ; Sun, 1 Dec 2002 23:10:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB24DKp20314 for sip-archive@odin.ietf.org; Sun, 1 Dec 2002 23:13:20 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB24D5v20304; Sun, 1 Dec 2002 23:13:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB24C2v20272 for ; Sun, 1 Dec 2002 23:12:02 -0500 Received: from mta1 (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23050 for ; Sun, 1 Dec 2002 23:09:04 -0500 (EST) Received: from prasannacl1105 (mta1 [172.17.1.60]) by mta1.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.7 (built Jun 26 2002)) with ESMTPA id <0H6H00MCT4VSPR@mta1.huawei.com> for sip@ietf.org; Mon, 02 Dec 2002 12:09:31 +0800 (CST) Date: Mon, 02 Dec 2002 09:38:01 +0530 From: Prasanna Venkatesh Subject: RE: [Sip] different messages with same call-id before 100 is sent out In-reply-to: <51.27e94654.2b1906f7@aol.com> To: Mpierce1@aol.com, Gonzalo.Camarillo@lmf.ericsson.se Cc: rshiroor@aplion.stpn.soft.net, sip@ietf.org, "Sip-Implementors@Cs.Columbia.Edu" Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Hi Gonzalo, I also agree to Mike's suggestion. Can't a recommendation be made on the INGRESS GW that the CSeq for an overlapped dial message should monotonically increase, though each of the INVITEs constitute a different dialog. This can help the EGRESS GW to drop out-of-order INVITEs. Regards, Prasanna Huawei Technologies. -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Mpierce1@aol.com Sent: Friday, November 29, 2002 11:38 PM To: Gonzalo.Camarillo@lmf.ericsson.se; prasanna@huawei.com Cc: rshiroor@aplion.stpn.soft.net; sip@ietf.org Subject: Re: [Sip] different messages with same call-id before 100 is sent out In a message dated 11/28/2002 5:08:11 AM Eastern Standard Time, Gonzalo.Camarillo@lmf.ericsson.se writes: in the overlap case we do not care if the nth INVITE reaches the other end before the (n-1)th INVITe, so you do not have to wait for anything before sending the new INVITE. [MAP] This may be true as long as the "other end" knows to throw away the old INVITE (with fewer digits). However, I believe that the very fact that INVITE's can arrive out of order leads to significant difficulty, since their correct interpretation depends on the order. Going back to some earlier comments, I believe there must be a requirement that, for the PSTN-IP-PSTN case (which I think is the focus in this whole discussion), that a single IAM received on the ingress side (of IP) must result in exactly one IAM being sent on the egress side back to the PSTN. There may be fewer (or no) SAMs sent than received, for example, if the IP portion, at either the ingress or egress GW, does overlap to en-bloc operation, or simply has the smarts to put multiple digits (from SAMs) together. I believe that a solution to meeting this requirement (single IAM) has a significant impact on all the other discussions about out-of-order INVITES, same or different Call-IDs, etc. Therefore, unless it can be agreed that this is a requirement, all the other discussion is meaningless. I raise this point especially with relation to my proposals in IEPREP for a priority-based service for a military application which includes preemption in the circuit switched world using SS#7 (MLPP). Multiple IAMs (for high priority calls) would have the unacceptable result of preempting calls and then releasing the IAM when another arrived (or took another path). Is it possible to agree that this single IAM rule should be followed? Mike Pierce Artel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Mon Dec 2 02:38:37 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06440 for ; Mon, 2 Dec 2002 02:38:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB27f5U08643 for sip-archive@odin.ietf.org; Mon, 2 Dec 2002 02:41:05 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB27egv08631; Mon, 2 Dec 2002 02:40:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB27cPv08472 for ; Mon, 2 Dec 2002 02:38:25 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06387 for ; Mon, 2 Dec 2002 02:35:25 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gB27bkQ1001873; Mon, 2 Dec 2002 08:37:46 +0100 (MET) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id YBCSN610; Mon, 2 Dec 2002 08:37:46 +0100 Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.18]) by hendrix.lmf.ericsson.se (8.12.6/8.12.6/lmf-2.1-jcs) with ESMTP id gB27bju4002949; Mon, 2 Dec 2002 09:37:46 +0200 (EET) Message-ID: <3DEB0DC9.E5393F56@lmf.ericsson.se> Date: Mon, 02 Dec 2002 09:37:45 +0200 X-Sybari-Trust: 4be78ff1 ca231590 b7e212f9 00000138 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mpierce1@aol.com CC: prasanna@huawei.com, rshiroor@aplion.stpn.soft.net, sip@ietf.org Subject: Re: [Sip] different messages with same call-id before 100 is sent out References: <51.27e94654.2b1906f7@aol.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, It has been explained several times why you cannot force the subsequent INVITEs to follow the rute that the first one followed. You can find the discussions in the archives or in the slides I presented in Australia. Thanks, Gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Mon Dec 2 02:44:58 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06546 for ; Mon, 2 Dec 2002 02:44:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB27lRU08850 for sip-archive@odin.ietf.org; Mon, 2 Dec 2002 02:47:27 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB27l9v08841; Mon, 2 Dec 2002 02:47:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB27kKv08791 for ; Mon, 2 Dec 2002 02:46:20 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06514 for ; Mon, 2 Dec 2002 02:43:19 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gB27juKV002164; Mon, 2 Dec 2002 08:45:56 +0100 (MET) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id YBCYLC10; Mon, 2 Dec 2002 08:45:56 +0100 Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.18]) by hendrix.lmf.ericsson.se (8.12.6/8.12.6/lmf-2.1-jcs) with ESMTP id gB27juu4003468; Mon, 2 Dec 2002 09:45:56 +0200 (EET) Message-ID: <3DEB0FB3.E429BC5E@lmf.ericsson.se> Date: Mon, 02 Dec 2002 09:45:56 +0200 X-Sybari-Trust: fd9e2a13 ca231590 b7e212f9 00000138 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Prasanna Venkatesh CC: Mpierce1@aol.com, rshiroor@aplion.stpn.soft.net, sip@ietf.org, "Sip-Implementors@Cs.Columbia.Edu" Subject: Re: [Sip] different messages with same call-id before 100 is sent out References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, The recommendation about using increasing Cseqs is already in the draft. 5th paragraph of section 3.3 Gonzalo Prasanna Venkatesh wrote: > > Hi Gonzalo, > I also agree to Mike's suggestion. Can't a recommendation be made on > the INGRESS GW that the CSeq for an overlapped dial message should > monotonically increase, though each of the INVITEs constitute a different > dialog. This can help the EGRESS GW to drop out-of-order INVITEs. > Regards, > Prasanna > Huawei Technologies. > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of > Mpierce1@aol.com > Sent: Friday, November 29, 2002 11:38 PM > To: Gonzalo.Camarillo@lmf.ericsson.se; prasanna@huawei.com > Cc: rshiroor@aplion.stpn.soft.net; sip@ietf.org > Subject: Re: [Sip] different messages with same call-id before 100 is sent > out > > In a message dated 11/28/2002 5:08:11 AM Eastern Standard Time, > Gonzalo.Camarillo@lmf.ericsson.se writes: > > in the overlap case we do not care if the nth INVITE reaches the other > end before the (n-1)th INVITe, so you do not have to wait for anything > before sending the new INVITE. > > [MAP] This may be true as long as the "other end" knows to throw away the > old INVITE (with fewer digits). However, I believe that the very fact that > INVITE's can arrive out of order leads to significant difficulty, since > their correct interpretation depends on the order. > > Going back to some earlier comments, I believe there must be a requirement > that, for the PSTN-IP-PSTN case (which I think is the focus in this whole > discussion), that a single IAM received on the ingress side (of IP) must > result in exactly one IAM being sent on the egress side back to the PSTN. > There may be fewer (or no) SAMs sent than received, for example, if the IP > portion, at either the ingress or egress GW, does overlap to en-bloc > operation, or simply has the smarts to put multiple digits (from SAMs) > together. > > I believe that a solution to meeting this requirement (single IAM) has a > significant impact on all the other discussions about out-of-order INVITES, > same or different Call-IDs, etc. Therefore, unless it can be agreed that > this is a requirement, all the other discussion is meaningless. > > I raise this point especially with relation to my proposals in IEPREP for a > priority-based service for a military application which includes preemption > in the circuit switched world using SS#7 (MLPP). Multiple IAMs (for high > priority calls) would have the unacceptable result of preempting calls and > then releasing the IAM when another arrived (or took another path). > > Is it possible to agree that this single IAM rule should be followed? > > Mike Pierce > Artel -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Mon Dec 2 06:21:46 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10283 for ; Mon, 2 Dec 2002 06:21:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB2BO4422461 for sip-archive@odin.ietf.org; Mon, 2 Dec 2002 06:24:04 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2BLqv22366; Mon, 2 Dec 2002 06:21:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2BI4v22235 for ; Mon, 2 Dec 2002 06:18:04 -0500 Received: from hclnpd.hclt.co.in (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10208 for ; Mon, 2 Dec 2002 06:15:14 -0500 (EST) Received: from blaze.hcltech.com (blaze.hclt-ntl.co.in [192.168.19.30]) by hclnpd.hclt.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SP0ATVJT; Mon, 2 Dec 2002 16:49:06 +0530 Received: from sachin-pc.netlab.hcltech.com ([192.168.201.60]) by blaze.hcltech.com (8.9.3/8.9.3) with ESMTP id RAA31947 for ; Mon, 2 Dec 2002 17:16:19 +0530 Message-Id: <4.3.2.7.0.20021202162407.02d5f3a0@blaze> X-Sender: sachins@blaze X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 02 Dec 2002 16:39:44 +0530 To: sip@ietf.org From: Sachin Shenoy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Sip] Detecting merged requests? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi, According to RFC 3261, a request is a merged request if ... "8.2.2.2 Merged Requests If the request has no tag in the To header field, the UAS core MUST check the request against ongoing transactions. If the From tag, Call-ID, and CSeq exactly match those associated with an ongoing transaction, but the request does not match that transaction (based on the matching rules in Section 17.2.3), the UAS core SHOULD generate a 482 (Loop Detected) response and pass it to the server transaction." Suppose if there are 2 UAS application sharing the same SIP stack (same process). They are listening for incoming calls for the same user. One application is handling the fax machine for user_a and the other the phone for user_a. user_a's fax machine can be reached at fax_user_a@test.com And user_a's phone can be reached at phone_user_a@test.com A call made to user_a@test.com gets forked at a proxy. The 2 forked request arrives at the UAS with the respective request URI's INVITE sip:fax_user_a@test.com ... INVITE sip:phone_user_a@test.com ... Now, according to the RFC, the first INVITE would be processed and the second would be responded with 482 "loop detected". Shouldn't the second INVITE also be processed? Logically, these are 2 different application handling 2 different devices for the same user. The fact that they are sharing the same process should not interfere each other. I think merged request matching should also take the Request-Uri into consideration. Request-Uri identifies the end point at UAS. If a UAS gets 2 INVITES for the same request-uri with the same Call-ID, Cseq and From-Tag, and with no To-Tag then it should be considered as merged request. Thanks Sachin _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Mon Dec 2 06:44:56 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10688 for ; Mon, 2 Dec 2002 06:44:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB2BlFI23888 for sip-archive@odin.ietf.org; Mon, 2 Dec 2002 06:47:15 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2Bj6v23845; Mon, 2 Dec 2002 06:45:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2Bghv23762 for ; Mon, 2 Dec 2002 06:42:43 -0500 Received: from hindon.hss.co.in (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10634 for ; Mon, 2 Dec 2002 06:39:51 -0500 (EST) From: akkasam@hss.hns.com Received: from hindon.hss.co.in (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id gB2Bfor08687 for ; Mon, 2 Dec 2002 17:11:50 +0530 (IST) Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id gB2Bfn808677; Mon, 2 Dec 2002 17:11:49 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id gB2Bham05437; Mon, 2 Dec 2002 17:13:36 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256C83.003FB684 ; Mon, 2 Dec 2002 17:05:54 +0530 X-Lotus-FromDomain: HSSBLR@HSS To: Sachin Shenoy cc: sip@ietf.org Message-ID: <65256C83.003FB518.00@sandesh.hss.hns.com> Date: Mon, 2 Dec 2002 17:08:52 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Sip] Regarding SIPS Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , HI RFC 3261 16.4 section. If the Request-URI contains a maddr parameter, the proxy MUST check to see if its value is in the set of addresses or domains the proxy is configured to be responsible for. If the Request-URI has a maddr parameter with a value the proxy is responsible for, and the request was received using the port and transport indicated (explicitly or by default) in the Request-URI, the proxy MUST strip the maddr and any non-default port or transport parameter and continue processing as if those values had not been present in the request. A request may arrive with a maddr matching the proxy, but on a port or transport different from that indicated in the URI. Such a request needs to be forwarded to the proxy using the indicated port and transport. What if the Request URI is like this sips:abc@def.com:33445;transport=tcp and if request is received at def.com on TCP. Should we forward the request on TLS?? or if request is received at def.com on TLS. since transport is TCP......Should we forward the request on TCP. With Regds Ajay Kumar _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Mon Dec 2 07:43:56 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11709 for ; Mon, 2 Dec 2002 07:43:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB2CkGe27173 for sip-archive@odin.ietf.org; Mon, 2 Dec 2002 07:46:16 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2Chov27052; Mon, 2 Dec 2002 07:43:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2CfJv26964 for ; Mon, 2 Dec 2002 07:41:19 -0500 Received: from willow.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11662 for ; Mon, 2 Dec 2002 07:38:27 -0500 (EST) Received: from cypress.neustar.com (stih650a-eth-s1p2c0.va.neustar.com [209.173.53.81]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id gB2CfGi24027; Mon, 2 Dec 2002 12:41:16 GMT Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by cypress.neustar.com (8.11.6/8.11.6) with ESMTP id gB2CfAx19920; Mon, 2 Dec 2002 12:41:11 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Mon, 2 Dec 2002 07:42:36 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA815EB420@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Jonathan Rosenberg'" , Adam Roach Cc: "'Dean Willis'" , sip@ietf.org Subject: RE: [Sip] DISCUSS on Service Route Discovery Date: Mon, 2 Dec 2002 07:42:26 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , I do agree that there are meaningful threats against registrars that emerge when a registering UAC cannot establish a direct, secure (per RFC3261, TLS) connection to the registrar. While service disco is not the first draft to condone architectures in which there are intermediaries in the registration process, I do think it is a reasonable place to stage some security considerations that focus on this case. It could be said that the RFC3261 security philosophy is "love it or leave it" - we show some architectures in which the mechanisms we recommend will work, and the price of deviation from these architectures is deriving your security properties from some other mechanisms. Perhaps this leaves the ball squarely in the court of I-Ds using different architectures. As I'm sure we all recall, during the RFC3261 review, the IESG suggested that over time, the normative language about S/MIME in the SIP standard might have to be strengthened. I don't think there's anything wrong with revisiting our security situation incrementally, as we come to understand more vulnerabilities in the light of proposed architectures or deployments in I-Ds that go before the SIP groups. Security considerations seem to be one of the few places in which the IESG welcomes redundancy - if multiple documents that consider these sorts of architectures need to have more or less identical language to this effect, I don't think that will be a problem (not Obviously Wrong, anyway). So from my perspective, I support the change recommended by the Discuss. RFC3261 is what it is - when we have the opportunity to reconsider some of its statutes, we will undoubtedly incorporate a number of changes influenced by drafts that have passed in the interim. Perhaps we can say that we're issuing an IOU to revisiting registrar security in the base spec later. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Wednesday, November 27, 2002 6:28 AM > To: Adam Roach > Cc: 'Dean Willis'; sip@ietf.org > Subject: Re: [Sip] DISCUSS on Service Route Discovery > > > inline. > > Adam Roach wrote: > >>-----Original Message----- > >>From: Dean Willis [mailto:dean.willis@softarmor.com] > >> > >>The second concern seems to be more interesting. Is it reasonable to > >>mandate that registrars implementing the Service-Route header > >>field also > >>MUST implement S/MIME? This doesn't say they have to USE > it, just that > >>they must IMPLEMENT it. > >> > >>My personal feeling is that implementing this in a > registrar is fairly > >>straightforward, and even the key management is easy, so it "does no > >>harm" to include as a MUST. > > > > > > I'm inclined to agree; first, though, I'd like to > understand the threat > > posed by a registrar that doesn't/can't use S/MIME versus one that > > can. Not in the general context of registering, of course -- only > > in the context of the extra functionality introduced by srvrtdisco. > > > > It's not obvious to me that this point is addressing an issue raised > > by *this* draft, versus a general issue with SIP -- and it would > > be Obviously Wrong (tm) to fix problems in the base spec in every > > other document that mentions it, as opposed to just recording it > > as a bug and fixing it next go round. > > I agree. I don't believe the threats specific to service > route are worse > than the general threats imposed through impersonating a registrar, > which are explicitly called out in section 26.1.2 of bis. Indeed, the > insertion of a fake 301 response to a REGISTER request is much more > damaging than a fake service route, I believe. > > So, if we think that S/MIME is a MUST to protect service > route, then its > also a MUST for rfc 3261. > > I suppose the counter-argument might be this. Bis more or > less assumes > that there is the possibility of a direct connection between > the client > and registrar, as it talks about using TLS to secure registrations > (Section 26.3.2.1). Almost by definition, that approach > doesn't work for > the problem space of service route, because of the existence > of proxies > between the UA and the registrar, not a common case. Thus, > this draft is > addressing a specific architecture where the normal bis security > recommendations don't apply, and thus a different > recommendation is needed. > > I'm not entirely sure I believe this counter-argument.... > > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.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 mailnull@www1.ietf.org Mon Dec 2 08:18:37 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13319 for ; Mon, 2 Dec 2002 08:18:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB2DKw829277 for sip-archive@odin.ietf.org; Mon, 2 Dec 2002 08:20:58 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2DKUv29241; Mon, 2 Dec 2002 08:20:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2D8Mv28664 for ; Mon, 2 Dec 2002 08:08:22 -0500 Received: from willow.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12732 for ; Mon, 2 Dec 2002 08:05:30 -0500 (EST) Received: from cypress.neustar.com (stih650a-eth-s1p2c0.va.neustar.com [209.173.53.81]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id gB2D8Ji24466; Mon, 2 Dec 2002 13:08:19 GMT Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by cypress.neustar.com (8.11.6/8.11.6) with ESMTP id gB2D8Ex20172; Mon, 2 Dec 2002 13:08:14 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Mon, 2 Dec 2002 08:09:39 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA815EB421@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'stoshniwal@hss.hns.com'" , sip@ietf.org Subject: RE: SIPS related clarifications (was: [Sip] SIPS question) Date: Mon, 2 Dec 2002 08:09:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , We did discuss this issue a bit in Atlanta. Unfortunately, I think all we agreed on is that we all need to think about it some more. Some more specific suggestions are offered below. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: stoshniwal@hss.hns.com [mailto:stoshniwal@hss.hns.com] > Sent: Thursday, November 28, 2002 7:09 AM > To: sip@ietf.org > Subject: SIPS related clarifications (was: [Sip] SIPS question) > > > > > > Hi all, > > There were couple of interesting questions raised in > this thread by Christer earlier this month that perhaps > got left out in the middle of the conversation. Wanted > to get my understanding regarding inter-mingling of > "sip:" and "sips:" URLs within the spec clear. Sorry > if any questions had got resolved earlier and I missed > the mail as I'm entering the discussion late. Any > pointers are welcome. > > * Is it allowed for a SIP proxy that got a request on > TLS to forward the request downstream on a non-TLS > protocol? Depends on what you mean by 'got a request'. This also doesn't say whether or not SIPS appears in the Request-URI or not; it is possible for a proxy server to receive a request over TLS that does not have the SIPS URI scheme in the Request-URI. > Jon Peterson had suggested that "sips" was > designed to allow selective hops in the path to be > secure, I suggested that SIPS could appear, for example, in a Route header, in which case it would only be intended to secure a particular hop. > while Rosenberg had mentioned that the presence > of "sips:" should imply that the end-to-end path is > secure. If SIPS appears in the Request-URI of the original request sent by the UAC, it implies this end-to-end path security. I don't think these two ways of using the SIPS URI are mutually exclusive - we don't have to say that SIPS is only usable in one or the other of these contexts. > I guess the way I understand the spec stands > at present is that if the Req-URI is re-written to a > "sips:" URL at any stage of the routing, then any hop > downstream _from_this_hop_onwards_ has to forward the > request on TLS. I agree, that is how we should understand it - with the caveat that SIPS only applies to the entire path until it reaches the domain indicated by the hostname portion of the Request-URI. Once a proxy server in the destination gets hold of the request, it can retarget it arbitrarily (to non-SIPS resources, if it wishes). Also note that proxies should not 're-write' the Request-URI of a SIP request at just any stage of the routing. In fact, there are rules in RFC3261 about when the Request-URI can be retargeted, and they are somewhat restrictive. > The entire path (from UA to UA) need > not be secure. Is this correct? Yes. > Or can the request > path be set-up with some hops on TLS and others on > non-TLS in any combination of them? > Not when the Request-URI contains a SIPS URI. > * What is the response code to be used by a UAS to > inform the UAC that it is not willing to accept > insecure calls and that the UAC should retry the > request on TLS? > Although 416 might look like an attractive candidate, the language in 8.1.3.5 makes it a little ugly. I would suggest 403. > * Also, another question Christer had raised in the > discussion was end-points should not be allowed to > send REGISTER with AoR as "sip:" and Contacts as "sips:" > since end-to-end security (if that's what "sips:" > implies always) would not be assured if a request > for that end-point came with Req-URI of "sip:". Is > this the case? > Mr. Holmberg's cases got a lot nastier than that - for example, if I use a SIP URI scheme in the Contact header I send when I register, but a SIPS URI scheme in the Contact header that I send in (say) 200 OK responses to requests. This creates some tricky cases, ones we are still mulling, I think. Just for the sake of simplicity, it might be nice to forbid this, but the spec doesn't forbid it today. > * Finally, the conclusion of the earlier thread seemed > to be that the last sentence of Section 8.1.2 > (paragraph 1) is incorrect and the UAC's choice for > the transport protocol should not rest on the req-uri's > scheme being "sips:" alone. But this was not logged > into bugzilla for resolution? Did I miss something? > I think we do need to fix the 8.1.2 text, yes. We should log this into bugzilla. I think the only reason this may not have happened yet is that the answer to all of this may rest on some more fundamental principles that we want to consider further before we propose any new language. > Thanks for your time. > > Regards, > Siddharth. > > -------------------------------------------------------- > Siddharth Toshniwal > Hughes Software Systems > Prestige Opal http://www.hssworld.com > 146, Infantry Road Ph (O): +91-80-2286390 (7094) > Bangalore-560001, India Mobile: +91-9845154068 > -------------------------------------------------------- > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Mon Dec 2 08:38:33 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14140 for ; Mon, 2 Dec 2002 08:38:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB2DerU30959 for sip-archive@odin.ietf.org; Mon, 2 Dec 2002 08:40:53 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2DePv30944; Mon, 2 Dec 2002 08:40:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2DdLv30875 for ; Mon, 2 Dec 2002 08:39:21 -0500 Received: from smail3.alcatel.fr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14059 for ; Mon, 2 Dec 2002 08:36:29 -0500 (EST) From: Juan-Carlos.Rojas@alcatel.fr Received: from frmail25.netfr.alcatel.fr (frmail25.netfr.alcatel.fr [155.132.182.155]) by smail3.alcatel.fr (ALCANET/NETFR) with ESMTP id gB2DdGek007559; Mon, 2 Dec 2002 14:39:16 +0100 Subject: RE: [Sip] B2BUA To: "Dean Willis" Cc: Date: Mon, 2 Dec 2002 14:39:14 +0100 Message-ID: X-MIMETrack: Serialize by Router on FRMAIL25/FR/ALCATEL(Release 5.0.8 |June 18, 2001) at 12/02/2002 14:39:16 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Dean et al, The main reason to propose this definition is to clearly precise that User Agents being involved in a B2BUA are "linked by some application logic that is fully independent of the SIP protocol rules" This is currently not precised in RFC 3261, and sometimes brings confusion on what can or cannot be done by a B2BUA. Best regards Juan Carlos "Dean Willis" on 30/11/2002 05:02:10 To: Juan-Carlos ROJAS/FR/ALCATEL@ALCATEL, cc: Subject: RE: [Sip] B2BUA Juan-Carlos said: > Back-to-Back User Agent: A SIP element being able to handle a > collection of "n" User Agents (behaving each one as UAC and > UAS, according to SIP rules), which are linked by some > application logic that is fully independent of the SIP protocol rules. This seems like a reasonable definition. Poll: Would it be worth including this in 3261bis? Do we need to say N>1? -- 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 mailnull@www1.ietf.org Mon Dec 2 08:59:03 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15046 for ; Mon, 2 Dec 2002 08:59:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB2E1O532114 for sip-archive@odin.ietf.org; Mon, 2 Dec 2002 09:01:24 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2E0wv32026; Mon, 2 Dec 2002 09:00:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2Dxrv31823 for ; Mon, 2 Dec 2002 08:59:53 -0500 Received: from mail-blue.research.att.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14930 for ; Mon, 2 Dec 2002 08:57:02 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 048214CEAD; Mon, 2 Dec 2002 08:59:51 -0500 (EST) Received: from fish.research.att.com (fish.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id IAA22537; Mon, 2 Dec 2002 08:59:47 -0500 (EST) From: William Marshall Received: (from wtm@localhost) by fish.research.att.com (SGI-8.9.3/8.8.5) id JAA31619; Mon, 2 Dec 2002 09:06:13 -0500 (EST) Date: Mon, 2 Dec 2002 09:06:13 -0500 (EST) Message-Id: <200212021406.JAA31619@fish.research.att.com> To: dean.willis@softarmor.com Cc: sip@ietf.org Subject: Re: [Sip] B2BUA Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Dean, you wrote: > Juan-Carlos said: > > Back-to-Back User Agent: A SIP element being able to handle a > > collection of "n" User Agents (behaving each one as UAC and > > UAS, according to SIP rules), which are linked by some > > application logic that is fully independent of the SIP protocol rules. > > This seems like a reasonable definition. > I dislike the use of "is" in the last line. Many actual B2BUAs are not "fully independent of the SIP protocol rules", and the above definition seems to say they must be. Perhaps "may be"? In particular, I don't think a firewall ALG will fit in the above definition of a B2BUA. Neither will the 3GPP P-CSCF. If the above definition captures the common understanding of what a B2BUA is (and it certainly captures the problems of the general case), there needs to be another type of SIP entity defined for what exists in practice. The term "transparent B2BUA" has been used in the past. I don't think those can be considered a subcase of the general definition above. Bill Marshall wtm@research.att.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 mailnull@www1.ietf.org Mon Dec 2 09:18:45 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15948 for ; Mon, 2 Dec 2002 09:18:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB2EL6q01131 for sip-archive@odin.ietf.org; Mon, 2 Dec 2002 09:21:06 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2EKYv01095; Mon, 2 Dec 2002 09:20:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2EJkv01009 for ; Mon, 2 Dec 2002 09:19:46 -0500 Received: from smail3.alcatel.fr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15875 for ; Mon, 2 Dec 2002 09:16:53 -0500 (EST) From: Juan-Carlos.Rojas@alcatel.fr Received: from frmail25.netfr.alcatel.fr (frmail25.netfr.alcatel.fr [155.132.182.155]) by smail3.alcatel.fr (ALCANET/NETFR) with ESMTP id gB2EJfek003623; Mon, 2 Dec 2002 15:19:41 +0100 Subject: Re: [Sip] B2BUA To: William Marshall Cc: dean.willis@softarmor.com, sip@ietf.org Date: Mon, 2 Dec 2002 15:19:40 +0100 Message-ID: X-MIMETrack: Serialize by Router on FRMAIL25/FR/ALCATEL(Release 5.0.8 |June 18, 2001) at 12/02/2002 15:19:41 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , William, "Many actual B2BUAs are not "fully independent of the SIP protocol rules", and the above definition seems to say they must be..." The proposed definition states that User Agents MUST behave as UAC ans UAS according to SIP rules (this MUST could be enforced in the definition). This is SIP standard, nothing else. All what is added is that the way of linking User Agents in a B2BUA is not related to SIP rules, and is not subject to SIP standardisation. As Dean pointed out in his mail, they are User Agents, they can do anything they want to do, and we don't want to standardise their behaviour. You can define a B2BUA whose behaviour is based on SIP rules, but this is a special case for a specific B2BUA implementing a well defined application. However, this cannot be generalised to any B2BUA. Concerning your statement "there needs to be another type of SIP entity defined for what exists in practice", my feeling is that today there are two SIP entity types: Proxy and B2BUA, and that seems to be enough (Am I missed something ?) Best regards Juan Carlos William Marshall @ietf.org on 02/12/2002 15:06:13 Sent by: sip-admin@ietf.org To: dean.willis@softarmor.com cc: sip@ietf.org Subject: Re: [Sip] B2BUA Dean, you wrote: > Juan-Carlos said: > > Back-to-Back User Agent: A SIP element being able to handle a > > collection of "n" User Agents (behaving each one as UAC and > > UAS, according to SIP rules), which are linked by some > > application logic that is fully independent of the SIP protocol rules. > > This seems like a reasonable definition. > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Mon Dec 2 10:44:30 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20467 for ; Mon, 2 Dec 2002 10:44:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB2FkoZ07833 for sip-archive@odin.ietf.org; Mon, 2 Dec 2002 10:46:50 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2FkFv07822; Mon, 2 Dec 2002 10:46:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2FiFv07741 for ; Mon, 2 Dec 2002 10:44:15 -0500 Received: from ebene.inrialpes.fr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20308 for ; Mon, 2 Dec 2002 10:41:23 -0500 (EST) Received: from imap-serv.inrialpes.fr (imap-serv.inrialpes.fr [194.199.18.72]) by ebene.inrialpes.fr (8.11.6/8.11.6) with ESMTP id gB2Fi9M02178 for ; Mon, 2 Dec 2002 16:44:09 +0100 (MET) Received: from inrialpes.fr (einsteinium.inrialpes.fr [194.199.25.99]) by imap-serv.inrialpes.fr (8.11.6/8.11.3/ImagV2) with ESMTP id gB2Fi9b10152 for ; Mon, 2 Dec 2002 16:44:09 +0100 (MET) Message-ID: <3DEB7FF1.1030407@inrialpes.fr> Date: Mon, 02 Dec 2002 16:44:49 +0100 From: olayaida 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 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Transcoding Invocation: Callee's capacities? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi all, I have a small question about transcoding services invocation, described in draft-camarillo-sip-deaf-01 : In Figures 2, 4 and 5, The 3pcc sends transcoded descriptions without having the original ones (Ex. SDP B in figure 2). Did this implies that T uses the OPTIONS message to have the missing description? Thank's in advance --- Oussama Layaida, PhD student LSR-IMAG Laboratory, SARDES Project (INPG, INRIA, UJF) Web: E-mail: Oussama.Layaida@inria.fr Phone: +33 4 76 61 52 79, Fax: +33 4 76 61 52 52 Address: INRIA Rhone-Alpes, SARDES, Oussama Layaida 655 av. de l'Europe, Montbonnot 38334 St Ismier Cedex France _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Mon Dec 2 11:21:36 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23522 for ; Mon, 2 Dec 2002 11:21:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB2GNvQ10730 for sip-archive@odin.ietf.org; Mon, 2 Dec 2002 11:23:57 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2GNXv10704; Mon, 2 Dec 2002 11:23:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2GK1v10484 for ; Mon, 2 Dec 2002 11:20:01 -0500 Received: from avgw.vxserver.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23183 for ; Mon, 2 Dec 2002 11:17:08 -0500 (EST) Received: from disney.internal.ridgewaysystems.com ([194.128.67.181]) by avgw.vxserver.com (NAVGW 2.5.2.12) with SMTP id M2002120216184424956 for ; Mon, 02 Dec 2002 16:18:44 GMT Received: from Unknown [10.1.1.1] by disney.internal.ridgewaysystems.com - SurfControl E-mail Filter (4.5); Monday, 02 December 2002, 16:20:15 Received: by ridgeway.internal.ridgewaysystems.com with Internet Mail Service (5.5.2653.19) id ; Mon, 2 Dec 2002 16:19:54 -0000 Message-ID: <00533D13955AD411AF3800A0C9B4263994D874@ridgeway.internal.ridgewaysystems.com> From: Phil Reynolds To: sip@ietf.org Date: Mon, 2 Dec 2002 16:19:54 -0000 Subject: RE: [Sip] B2BUA MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--=_NextPart_ST_16_20_15_Monday_December_02_2002_12317" X-Mailer: Internet Mail Service (5.5.2653.19) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , 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_ST_16_20_15_Monday_December_02_2002_12317 Content-Type: text/plain Can we not define B2BUAs as a SIP entity that exhibits the behaviour of a UAC and UAS combination. i.e. it can not be distinguished externally from a properly conforming UA, thus not constraining it's internal functionality or implementation. -----Original Message----- From: Juan-Carlos.Rojas@alcatel.fr [mailto:Juan-Carlos.Rojas@alcatel.fr] Sent: 02 December 2002 14:20 To: William Marshall Cc: dean.willis@softarmor.com; sip@ietf.org Subject: Re: [Sip] B2BUA William, "Many actual B2BUAs are not "fully independent of the SIP protocol rules", and the above definition seems to say they must be..." The proposed definition states that User Agents MUST behave as UAC ans UAS according to SIP rules (this MUST could be enforced in the definition). This is SIP standard, nothing else. All what is added is that the way of linking User Agents in a B2BUA is not related to SIP rules, and is not subject to SIP standardisation. As Dean pointed out in his mail, they are User Agents, they can do anything they want to do, and we don't want to standardise their behaviour. You can define a B2BUA whose behaviour is based on SIP rules, but this is a special case for a specific B2BUA implementing a well defined application. However, this cannot be generalised to any B2BUA. Concerning your statement "there needs to be another type of SIP entity defined for what exists in practice", my feeling is that today there are two SIP entity types: Proxy and B2BUA, and that seems to be enough (Am I missed something ?) Best regards Juan Carlos William Marshall @ietf.org on 02/12/2002 15:06:13 Sent by: sip-admin@ietf.org To: dean.willis@softarmor.com cc: sip@ietf.org Subject: Re: [Sip] B2BUA Dean, you wrote: > Juan-Carlos said: > > Back-to-Back User Agent: A SIP element being able to handle a > > collection of "n" User Agents (behaving each one as UAC and UAS, > > according to SIP rules), which are linked by some application logic > > that is fully independent of the SIP protocol rules. > > This seems like a reasonable definition. > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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_ST_16_20_15_Monday_December_02_2002_12317 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Sip] B2BUA

Can we not define B2BUAs as a SIP entity that exhibits th= e behaviour of a UAC and UAS combination. i.e. it can not be distinguished = externally from a properly conforming UA, thus not constraining it's intern= al functionality or implementation.

-----Original Message-----
From: Juan-Carlos.Rojas@alcatel.fr [mailto:Juan-Carlos.Rojas@alcatel.fr]
Sent: 02 December 2002 14:20
To: William Marshall
Cc: dean.willis@softarmor.com; sip@ietf.org
Subject: Re: [Sip] B2BUA



William,

"Many actual B2BUAs are not "fully independent = of the SIP protocol rules", and the above definition seems to say they= must be..." The proposed definition states that User Agents MUST beha= ve as UAC ans UAS according to SIP rules (this MUST could be enforced in th= e definition). This is SIP standard, nothing else. All what is added is tha= t the way of linking User Agents in a B2BUA is not related to SIP rules, an= d is not subject to SIP standardisation. As Dean pointed out in his mail, t= hey are User Agents, they can do anything they want to do, and we don't wan= t to standardise their behaviour. You can define a B2BUA whose behaviour is= based on SIP rules, but this is a special case for a specific B2BUA implem= enting a well defined application. However, this cannot be generalised to a= ny B2BUA.

Concerning your statement "there needs to be another= type of SIP entity defined for what exists in practice", my feeling i= s that today there are two SIP entity types: Proxy and B2BUA, and that seem= s to be enough (Am I missed something ?)


Best regards
Juan Carlos





William Marshall <wtm@research.att.com>@ietf.org on= 02/12/2002 15:06:13

Sent by:  sip-admin@ietf.org


To:   dean.willis@softarmor.com
cc:   sip@ietf.org
Subject:  Re: [Sip] B2BUA


Dean,

you wrote:
> Juan-Carlos said:
> > Back-to-Back User Agent: A SIP element being a= ble to handle a
> > collection of "n" User Agents (behav= ing each one as UAC and UAS,
> > according to SIP rules), which are linked by s= ome application logic
> > that is fully independent of the SIP protocol = rules.
>
> This seems like a reasonable definition.
>



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listi= nfo/sip
This list is for NEW development of the core SIP Protoco= l
Use sip-implementors@cs.columbia.edu for questions on cu= rrent sip Use sipping@ietf.org for new developments on the application of s= ip

----=_NextPart_ST_16_20_15_Monday_December_02_2002_12317-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Mon Dec 2 11:57:03 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25813 for ; Mon, 2 Dec 2002 11:57:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB2GxON13262 for sip-archive@odin.ietf.org; Mon, 2 Dec 2002 11:59:24 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2Gthv13036; Mon, 2 Dec 2002 11:55:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2Gs5v12963 for ; Mon, 2 Dec 2002 11:54:05 -0500 Received: from zsc3s004.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25497 for ; Mon, 2 Dec 2002 11:51:12 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by zsc3s004.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gB2Grv910941; Mon, 2 Dec 2002 08:53:58 -0800 (PST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gB2Gs9Y11489; Mon, 2 Dec 2002 10:54:09 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 2 Dec 2002 10:53:56 -0600 Message-ID: <1B54FA3A2709D51195C800508BF9386A05A7CB16@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'Phil Reynolds'" , sip@ietf.org Subject: RE: [Sip] B2BUA Date: Mon, 2 Dec 2002 10:53:50 -0600 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi all, I guess I have to ask, what's the problem with the definition in RFC 3261? Back-to-Back user agent: A back-to-back user agent (B2BUA) is a logical entity that receives a request, and processes it as a UAS. In order to determine how the request should be answered, it acts as a UAC and generates requests. Unlike a proxy server, it maintains dialog state, and must participate in all requests sent on the dialogs it has established. Since it is a concatenation of a UAC and UAS, no explicit definitions are needed for its behavior. Regards, Mary. -----Original Message----- From: Phil Reynolds [mailto:preynolds@ridgewaysystems.com] Sent: Monday, December 02, 2002 10:20 AM To: sip@ietf.org Subject: RE: [Sip] B2BUA Can we not define B2BUAs as a SIP entity that exhibits the behaviour of a UAC and UAS combination. i.e. it can not be distinguished externally from a properly conforming UA, thus not constraining it's internal functionality or implementation. -----Original Message----- From: Juan-Carlos.Rojas@alcatel.fr [mailto:Juan-Carlos.Rojas@alcatel.fr] Sent: 02 December 2002 14:20 To: William Marshall Cc: dean.willis@softarmor.com; sip@ietf.org Subject: Re: [Sip] B2BUA William, "Many actual B2BUAs are not "fully independent of the SIP protocol rules", and the above definition seems to say they must be..." The proposed definition states that User Agents MUST behave as UAC ans UAS according to SIP rules (this MUST could be enforced in the definition). This is SIP standard, nothing else. All what is added is that the way of linking User Agents in a B2BUA is not related to SIP rules, and is not subject to SIP standardisation. As Dean pointed out in his mail, they are User Agents, they can do anything they want to do, and we don't want to standardise their behaviour. You can define a B2BUA whose behaviour is based on SIP rules, but this is a special case for a specific B2BUA implementing a well defined application. However, this cannot be generalised to any B2BUA. Concerning your statement "there needs to be another type of SIP entity defined for what exists in practice", my feeling is that today there are two SIP entity types: Proxy and B2BUA, and that seems to be enough (Am I missed something ?) Best regards Juan Carlos William Marshall @ietf.org on 02/12/2002 15:06:13 Sent by: sip-admin@ietf.org To: dean.willis@softarmor.com cc: sip@ietf.org Subject: Re: [Sip] B2BUA Dean, you wrote: > Juan-Carlos said: > > Back-to-Back User Agent: A SIP element being able to handle a > > collection of "n" User Agents (behaving each one as UAC and UAS, > > according to SIP rules), which are linked by some application logic > > that is fully independent of the SIP protocol rules. > > This seems like a reasonable definition. > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Mon Dec 2 12:20:21 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26993 for ; Mon, 2 Dec 2002 12:20:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB2HMhE15496 for sip-archive@odin.ietf.org; Mon, 2 Dec 2002 12:22:43 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2HMMv15485; Mon, 2 Dec 2002 12:22:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2HJtv15359 for ; Mon, 2 Dec 2002 12:19:55 -0500 Received: from smail3.alcatel.fr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26864 for ; Mon, 2 Dec 2002 12:17:02 -0500 (EST) From: Juan-Carlos.Rojas@alcatel.fr Received: from frmail25.netfr.alcatel.fr (frmail25.netfr.alcatel.fr [155.132.182.155]) by smail3.alcatel.fr (ALCANET/NETFR) with ESMTP id gB2HJoek013465; Mon, 2 Dec 2002 18:19:50 +0100 Subject: RE: [Sip] B2BUA To: "Mary Barnes" Cc: sip@ietf.org Date: Mon, 2 Dec 2002 18:19:43 +0100 Message-ID: X-MIMETrack: Serialize by Router on FRMAIL25/FR/ALCATEL(Release 5.0.8 |June 18, 2001) at 12/02/2002 18:19:49 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hello, Well, if from times to times there are questions and debates on a given subject, it is surely because the definition needs to be improved, or at least clarified. "Since it is a concatenation of a UAC and UAS" 1.- A B2BUA is not a "concatenation of a UAC and UAS", but a collection of several UAs (two, three or more), which behave individually as UAS or UAC according to SIP rules (and are seen as such from the outside of the B2BUA). For example, a conference server where all the participants send INVITE messages to the server could be made with UAS only (do note that this is strictly a matter of application definition, and cannot be subject to standardisation). 2.- UAs are not "concateneted" in the B2BUA, but they are linked by some application logic which is by definition, a non-standard element. This is the key element that should be precised in the RFC3261 to avoid confusion. You cannot define the behaviour of a B2BUA, you can define only the behaviour of each UA (and this is actually done by the SIP specification). Hoping this answers your questions Best regards Juan Carlos "Mary Barnes" @ietf.org on 02/12/2002 17:53:50 Sent by: sip-admin@ietf.org To: "'Phil Reynolds'" , sip@ietf.org cc: Subject: RE: [Sip] B2BUA Hi all, I guess I have to ask, what's the problem with the definition in RFC 3261? Back-to-Back user agent: A back-to-back user agent (B2BUA) is a logical entity that receives a request, and processes it as a UAS. In order to determine how the request should be answered, it acts as a UAC and generates requests. Unlike a proxy server, it maintains dialog state, and must participate in all requests sent on the dialogs it has established. Since it is a concatenation of a UAC and UAS, no explicit definitions are needed for its behavior. Regards, Mary. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Mon Dec 2 12:47:37 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28469 for ; Mon, 2 Dec 2002 12:47:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB2Hnxw17493 for sip-archive@odin.ietf.org; Mon, 2 Dec 2002 12:49:59 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2HnSv17472; Mon, 2 Dec 2002 12:49:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2Hkwv17365 for ; Mon, 2 Dec 2002 12:46:58 -0500 Received: from zsc3s004.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28342 for ; Mon, 2 Dec 2002 12:44:05 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by zsc3s004.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gB2Hkp903589; Mon, 2 Dec 2002 09:46:51 -0800 (PST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gB2Hl3Y02845; Mon, 2 Dec 2002 11:47:03 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 2 Dec 2002 11:46:49 -0600 Message-ID: <1B54FA3A2709D51195C800508BF9386A05A7CB19@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'Juan-Carlos.Rojas@alcatel.fr'" Cc: sip@ietf.org Subject: RE: [Sip] B2BUA Date: Mon, 2 Dec 2002 11:46:48 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C29A2A.CA093460" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , 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_01C29A2A.CA093460 Content-Type: text/plain; charset="iso-8859-1" Juan-Carlos, So, I guess you're suggesting that the term "concatenation" is not accurate or is misleading and I guess that depends upon how loosely one applies the term concatenation here; my assumption had been that it meant that they were "linked" (consistent with Webster's definition of concatenate) in some manner which is unprescribed, so I think your point 2 below isn't a problem with the current definition. My understanding of the current definition is that there isn't anything more for the SIP protocol to prescribe about the operation of a B2BUA other than what is required from a protocol perspective to function as a UAC and a UAS. From a protocol perspective, it is a logical entity and thus whether there's one or multiple doesn't seem to apply. I think what you (and perhaps others) are suggesting is that there's a definition of a B2BUA that more closely parallels the definition of a Proxy Server since in many cases the physical rendition of the logical B2BUA functionality would be replacing a Proxy Server in a network. And I think this is where the problem begins, as many are opposed to this model (as it increases the complexity, etc.) and this is why the logical definition has remained. On your first point, however, I think we need to wait until the conferencing work in SIPPING is more complete before we can suggest that a conference server would be a B2BUA. Mary. -----Original Message----- From: Juan-Carlos.Rojas@alcatel.fr [mailto:Juan-Carlos.Rojas@alcatel.fr] Sent: Monday, December 02, 2002 11:20 AM To: Barnes, Mary [NGC:B602:EXCH] Cc: sip@ietf.org Subject: RE: [Sip] B2BUA Hello, Well, if from times to times there are questions and debates on a given subject, it is surely because the definition needs to be improved, or at least clarified. "Since it is a concatenation of a UAC and UAS" 1.- A B2BUA is not a "concatenation of a UAC and UAS", but a collection of several UAs (two, three or more), which behave individually as UAS or UAC according to SIP rules (and are seen as such from the outside of the B2BUA). For example, a conference server where all the participants send INVITE messages to the server could be made with UAS only (do note that this is strictly a matter of application definition, and cannot be subject to standardisation). 2.- UAs are not "concateneted" in the B2BUA, but they are linked by some application logic which is by definition, a non-standard element. This is the key element that should be precised in the RFC3261 to avoid confusion. You cannot define the behaviour of a B2BUA, you can define only the behaviour of each UA (and this is actually done by the SIP specification). Hoping this answers your questions Best regards Juan Carlos "Mary Barnes" @ietf.org on 02/12/2002 17:53:50 Sent by: sip-admin@ietf.org To: "'Phil Reynolds'" , sip@ietf.org cc: Subject: RE: [Sip] B2BUA Hi all, I guess I have to ask, what's the problem with the definition in RFC 3261? Back-to-Back user agent: A back-to-back user agent (B2BUA) is a logical entity that receives a request, and processes it as a UAS. In order to determine how the request should be answered, it acts as a UAC and generates requests. Unlike a proxy server, it maintains dialog state, and must participate in all requests sent on the dialogs it has established. Since it is a concatenation of a UAC and UAS, no explicit definitions are needed for its behavior. Regards, Mary. ------_=_NextPart_001_01C29A2A.CA093460 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] B2BUA

Juan-Carlos,

So, I guess you're suggesting that the term = "concatenation" is not accurate or is misleading and I guess = that depends upon how loosely one applies the term concatenation here; = my assumption had been that it meant that they were "linked" = (consistent with Webster's definition of concatenate) in some manner = which is unprescribed, so I think your point 2 below isn't a problem = with the current definition.  My understanding of the current = definition is that there isn't anything more for the SIP protocol to = prescribe about the operation of a B2BUA other than what is required = from a protocol perspective to function as a UAC and a UAS. From a = protocol perspective, it is a logical entity and thus whether there's = one or multiple doesn't seem to apply.  I think what you (and = perhaps others) are suggesting is that there's a definition of a B2BUA = that more closely parallels the definition of a Proxy Server since in = many cases the physical rendition of the logical B2BUA functionality = would be replacing a Proxy Server in a network. And I think this is = where the problem begins, as many are opposed to this model (as it = increases the complexity, etc.) and this is why the logical definition = has remained.

On your first point, however, I think we need to wait = until the conferencing work in SIPPING is more complete before we can = suggest that a conference server would be a B2BUA.

Mary.

-----Original Message-----
From: Juan-Carlos.Rojas@alcatel.fr [mailto:Juan-Carlos.Rojas@al= catel.fr]
Sent: Monday, December 02, 2002 11:20 AM
To: Barnes, Mary [NGC:B602:EXCH]
Cc: sip@ietf.org
Subject: RE: [Sip] B2BUA



Hello,
Well, if from times to times there are questions and = debates on a given
subject, it is surely because the definition needs = to be improved, or at
least clarified.

"Since it is a concatenation of a UAC and = UAS"
1.- A B2BUA is not a "concatenation of a UAC = and UAS", but a collection of
several UAs (two, three or more), which behave = individually as UAS or UAC
according to SIP rules (and are seen as such from = the outside of the
B2BUA). For example, a conference server where all = the participants send
INVITE messages to the server could be made with UAS = only (do note that
this is strictly a matter of application definition, = and cannot be subject
to standardisation).
2.- UAs are not "concateneted" in the = B2BUA, but they are linked by some
application logic which is by definition, a = non-standard element. This is
the key element that should be precised in the = RFC3261 to avoid confusion.
You cannot define the behaviour of a B2BUA, you can = define only the
behaviour of each UA (and this is actually done by = the SIP specification).

Hoping this answers your questions
Best regards
Juan Carlos




"Mary Barnes" = <mbarnes@nortelnetworks.com>@ietf.org on 02/12/2002 = 17:53:50

Sent by:  sip-admin@ietf.org


To:   "'Phil Reynolds'" = <preynolds@ridgewaysystems.com>, sip@ietf.org
cc:
Subject:  RE: [Sip] B2BUA


Hi all,

I guess I have to ask, what's the problem with the = definition in RFC 3261?

Back-to-Back user agent: A back-to-back user agent = (B2BUA) is a
          &nb= sp;  logical entity that receives a request, and processes it = as
          &nb= sp;  a UAS. In order to determine how the request should be
          &nb= sp;  answered, it acts as a UAC and generates requests. Unlike = a
          &nb= sp;  proxy server, it maintains dialog state, and must
          &nb= sp;  participate in all requests sent on the dialogs it has
          &nb= sp;  established. Since it is a concatenation of a UAC and = UAS,
          &nb= sp;  no explicit definitions are needed for its behavior.

Regards,
Mary.




------_=_NextPart_001_01C29A2A.CA093460-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Mon Dec 2 12:56:27 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29217 for ; Mon, 2 Dec 2002 12:56:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB2Hwn518241 for sip-archive@odin.ietf.org; Mon, 2 Dec 2002 12:58:49 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2Hvrv18158; Mon, 2 Dec 2002 12:57:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2Hu6v18072 for ; Mon, 2 Dec 2002 12:56:06 -0500 Received: from imo-d04.mx.aol.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28950 for ; Mon, 2 Dec 2002 12:53:13 -0500 (EST) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-d04.mx.aol.com (mail_out_v34.13.) id r.90.2fe85b0b (25508); Mon, 2 Dec 2002 12:51:40 -0500 (EST) Message-ID: <90.2fe85b0b.2b1cf7ac@aol.com> Date: Mon, 2 Dec 2002 12:51:40 EST Subject: Re: [Sip] different messages with same call-id before 100 is sent out To: Gonzalo.Camarillo@lmf.ericsson.se CC: prasanna@huawei.com, rshiroor@aplion.stpn.soft.net, sip@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_90.2fe85b0b.2b1cf7ac_boundary" X-Mailer: AOL 6.0 for Windows XP US sub 51 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --part1_90.2fe85b0b.2b1cf7ac_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 12/2/2002 2:38:32 AM Eastern Standard Time, Gonzalo.Camarillo@lmf.ericsson.se writes: > Hi, > > It has been explained several times why you cannot force the subsequent > INVITEs to follow the rute that the first one followed. You can find the > discussions in the archives or in the slides I presented in Australia. > > Thanks, > > [MAP] I understand that you can not "force" anything to take the same route, or even to arrive at the same egress point. But my previous comments were generally the following: 1. Define the procedures for overlap based on a presumption that all INVITEs for one call will follow the same route. 2. Strongly "suggest" that the ingress point should not send the first INVITE until it has enough digits for proper routing (generally to the egress point). 3. The ingress clearly marks the first INVITE as incomplete and subsequent INVITEs (call id, seq number, or whatever) to indicate that they belong together 4. The egress doesn't handle anything that isn't correct, i.e., throws away an initial incomplete INVITE if it doesn't understand how to do overlap, stores it if it doesn't want to do overlap, or throws away a subsequent INVITE if it didn't get the previous. I realize that 4. could be a problem if a subsequent INVITE looks just like a normal one and the egress GW knows nothing about handling overlap, that is, it doesn't understand that it is supposed to do what 4. says. But this is the whole point of my comments. There needs to be distinguishing information in the INVITE and if the egress GW doesn't understand the overlap procedures, then it shouldn't be doing it. If SIP doesn't have a good way to tell the other end to ignore a message if it doesn't understand some specific part, then there is a bigger problem. Mike Pierce Artel --part1_90.2fe85b0b.2b1cf7ac_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 12/2/2002 2:38:32 AM Eastern Standard Time, Gonzalo.Camarillo@lmf.ericsson.se writes:


Hi,

It has been explained several times why you cannot force the subsequent
INVITEs to follow the rute that the first one followed. You can find the
discussions in the archives or in the slides I presented in Australia.

Thanks,




[MAP] I understand that you can not "force" anything to take the same route, or even to arrive at the same egress point.

But my previous comments were generally the following:

1. Define the procedures for overlap based on a presumption that all INVITEs for one call will follow the same route.
2. Strongly "suggest" that the ingress point should not send the first INVITE until it has enough digits for proper routing (generally to the egress point).
3. The ingress clearly marks the first INVITE as incomplete and subsequent INVITEs (call id, seq number, or whatever) to indicate that they belong together
4. The egress doesn't handle anything that isn't correct, i.e., throws away an initial incomplete INVITE if it doesn't understand how to do overlap, stores it if it doesn't want to do overlap, or throws away a subsequent INVITE if it didn't get the previous.

I realize that 4. could be a problem if a subsequent INVITE looks just like a normal one and the egress GW knows nothing about handling overlap, that is, it doesn't understand that it is supposed to do what 4. says. But this is the whole point of my comments. There needs to be distinguishing information in the INVITE and if the egress GW doesn't understand the overlap procedures, then it shouldn't be doing it.

If SIP doesn't have a good way to tell the other end to ignore a message if it doesn't understand some specific part, then there is a bigger problem.

Mike Pierce
Artel
--part1_90.2fe85b0b.2b1cf7ac_boundary-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Mon Dec 2 13:07:50 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29874 for ; Mon, 2 Dec 2002 13:07:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB2IAC219590 for sip-archive@odin.ietf.org; Mon, 2 Dec 2002 13:10:12 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2I9Rv19456; Mon, 2 Dec 2002 13:09:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2I35v18589 for ; Mon, 2 Dec 2002 13:03:05 -0500 Received: from smail3.alcatel.fr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29525 for ; Mon, 2 Dec 2002 13:00:11 -0500 (EST) From: Juan-Carlos.Rojas@alcatel.fr Received: from frmail25.netfr.alcatel.fr (frmail25.netfr.alcatel.fr [155.132.182.155]) by smail3.alcatel.fr (ALCANET/NETFR) with ESMTP id gB2I2wek025656; Mon, 2 Dec 2002 19:02:58 +0100 Subject: RE: [Sip] B2BUA To: "Mary Barnes" Cc: sip@ietf.org Date: Mon, 2 Dec 2002 19:02:57 +0100 Message-ID: X-MIMETrack: Serialize by Router on FRMAIL25/FR/ALCATEL(Release 5.0.8 |June 18, 2001) at 12/02/2002 19:02:58 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gB2I35v18590 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Mary, Debates about what a B2BUA can or cannot do come back regularly. That's why I suggested that to avoid confusion, the definition needs maybe to be improved. See other comments inline in your text. Best regards Juan Carlos "Mary Barnes" on 02/12/2002 18:46:48 To: Juan-Carlos ROJAS/FR/ALCATEL@ALCATEL cc: sip@ietf.org Subject: RE: [Sip] B2BUA Juan-Carlos, So, I guess you're suggesting that the term "concatenation" is not accurate or is misleading and I guess that depends upon how loosely one applies the term concatenation here; my assumption had been that it meant that they were "linked" (consistent with Webster's definition of concatenate) in some manner which is unprescribed, so I think your point 2 below isn't a problem with the current definition.  My understanding of the current definition is that there isn't anything more for the SIP protocol to prescribe about the operation of a B2BUA other than what is required from a protocol perspective to function as a UAC and a UAS. From a protocol perspective, it is a logical entity and thus whether there's one or multiple doesn't seem to apply. JC: you say "...they were "linked" ... in some manner which is unprescribed". Fully agree with you, and in my feeling, the word "unprescribed" or any other synonym should be used explicitly in the definition of a B2BUA (this is not currently the case), because very often this is the reason of confusion. I think what you (and perhaps others) are suggesting is that there's a definition of a B2BUA that more closely parallels the definition of a Proxy Server since in many cases the physical rendition of the logical B2BUA functionality would be replacing a Proxy Server in a network. And I think this is where the problem begins, as many are opposed to this model (as it increases the complexity, etc.) and this is why the logical definition has remained. JC: it is definitely not my case to search for any parallel with the definition of a Proxy Server (whose behaviour is well defined in RFC3261). Do mind that this discusion thread started because somebody asked what a B2BUA can or cannot do. The central problem is once again this "unprescribed" relation of UAs in a B2BUA. On your first point, however, I think we need to wait until the conferencing work in SIPPING is more complete before we can suggest that a conference server would be a B2BUA. JC: you can define a conference server as a B2BUA or not, no problem with that. But this is only one type of application; I'm not suggesting it, I used only as an example. Mary. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Mon Dec 2 14:56:03 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06998 for ; Mon, 2 Dec 2002 14:56:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB2JwQZ27509 for sip-archive@odin.ietf.org; Mon, 2 Dec 2002 14:58:26 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2Jvcv27424; Mon, 2 Dec 2002 14:57:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB2Jrsv27260 for ; Mon, 2 Dec 2002 14:53:54 -0500 Received: from mail-green.research.att.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06817 for ; Mon, 2 Dec 2002 14:50:59 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id DB6331E0E3; Mon, 2 Dec 2002 14:53:47 -0500 (EST) Received: from fish.research.att.com (fish.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id OAA28180; Mon, 2 Dec 2002 14:53:44 -0500 (EST) From: William Marshall Received: (from wtm@localhost) by fish.research.att.com (SGI-8.9.3/8.8.5) id OAA53813; Mon, 2 Dec 2002 14:59:55 -0500 (EST) Date: Mon, 2 Dec 2002 14:59:55 -0500 (EST) Message-Id: <200212021959.OAA53813@fish.research.att.com> To: Juan-Carlos.Rojas@alcatel.fr Cc: sip@ietf.org Subject: RE: [Sip] B2BUA Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Juan Carlow wrote, in part: > 2.- UAs are not "concateneted" in the B2BUA, but they are linked by some > application logic which is by definition, a non-standard element. This is ~~~~~~~~~~~~~~~~~~~~~~ > the key element that should be precised in the RFC3261 to avoid confusion. This is the exact point that I disagree with. The entity that we are describing receives SIP requests on one side, processes them internally, and generates SIP requests on the other side. Responses are handled in the reverse path. I don't think there is any disagreement so far. There is wide variation possible in the algorithms used internally to process the requests and responses. But they are all B2BUAs. One of the possible algorithms is defined in section 16 of rfc3261. Many other possible algorithms exist, and are not covered in rfc3261. The definition needs to cover all of these possibilities, not just the non-standard ones. At some point we need to define exactly what the requirements are for the internal processing algorithm, such that new services will work through it. Section 16 is one example. But I don't think we are ready yet to generalize this. Bill Marshall wtm@research.att.com -----original message----- From: Juan-Carlos.Rojas@alcatel.fr [mailto:Juan-Carlos.Rojas@alcatel.fr] Sent: Monday, December 02, 2002 11:20 AM To: Barnes, Mary [NGC:B602:EXCH] Cc: sip@ietf.org Subject: RE: [Sip] B2BUA Hello, Well, if from times to times there are questions and debates on a given subject, it is surely because the definition needs to be improved, or at least clarified. "Since it is a concatenation of a UAC and UAS" 1.- A B2BUA is not a "concatenation of a UAC and UAS", but a collection of several UAs (two, three or more), which behave individually as UAS or UAC according to SIP rules (and are seen as such from the outside of the B2BUA). For example, a conference server where all the participants send INVITE messages to the server could be made with UAS only (do note that this is strictly a matter of application definition, and cannot be subject to standardisation). 2.- UAs are not "concateneted" in the B2BUA, but they are linked by some application logic which is by definition, a non-standard element. This is the key element that should be precised in the RFC3261 to avoid confusion. You cannot define the behaviour of a B2BUA, you can define only the behaviour of each UA (and this is actually done by the SIP specification). Hoping this answers your questions Best regards Juan Carlos _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Tue Dec 3 01:00:49 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28484 for ; Tue, 3 Dec 2002 01:00:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB363HJ01228 for sip-archive@odin.ietf.org; Tue, 3 Dec 2002 01:03:17 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB362lv01168; Tue, 3 Dec 2002 01:02:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB360jv01068 for ; Tue, 3 Dec 2002 01:00:45 -0500 Received: from bdsl.greycouncil.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28417 for ; Tue, 3 Dec 2002 00:57:46 -0500 (EST) Received: from txdwillis (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.5/8.12.5) with ESMTP id gB360SQt007639; Tue, 3 Dec 2002 00:00:33 -0600 From: "Dean Willis" To: "'William Marshall'" Cc: Subject: RE: [Sip] B2BUA Date: Tue, 3 Dec 2002 00:00:19 -0600 Message-ID: <002201c29a91$45da3920$0100a8c0@txdwillis> 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.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <200212021406.JAA31619@fish.research.att.com> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > > Juan-Carlos said: > > > Back-to-Back User Agent: A SIP element being able to handle a > > > collection of "n" User Agents (behaving each one as UAC and > > > UAS, according to SIP rules), which are linked by some > > > application logic that is fully independent of the SIP > protocol rules. > > I dislike the use of "is" in the last line. Many actual B2BUAs are > not "fully independent of the SIP protocol rules", and the above > definition seems to say they must be. Perhaps "may be"? > > In particular, I don't think a firewall ALG will fit in the above > definition of a B2BUA. Neither will the 3GPP P-CSCF. If the above > definition captures the common understanding of what a B2BUA is > (and it certainly captures the problems of the general case), there > needs to be another type of SIP entity defined for what exists in > practice. Well, "fully independent" doen't seem the same to me as "must ignore", but perhaps "may be" would be better. Honestly, the existing text satisfies me quite nicely, but I have noticed that it seems to confuse people which raises the question of "how can we keep this confusion from occurring in the mind of the reader." > The term "transparent B2BUA" has been used in the past. I don't think > those can be considered a subcase of the general definition above. > Oh no -- I'll have to dig up my "Transparency Top 10" list again. Maybe that should become a yearly post, sent out the week after my "B2BUA" post . . .;-) Really, I think that almost any of the "Top 10" transparency modes can be violated by a B2BUA, whereas, if I recall my post, NONE are violated by a conformant proxy. Something like a Firewall Control Proxy preserves many of the transparency modes, while violating something fundamental like "media transparency". It's still not really a "proxy", so it's "some kind of B2BUA that is almost but not quite exactly a proxy". Just because the FCP's application logic implements something that is SIMILAR TO the SIP protocol rules, it doesn't mean that it isn't INDEPENDENT OF thos same rules. But hey, the 3261 def works for me, so what do I know? -- 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 mailnull@www1.ietf.org Tue Dec 3 01:00:54 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28499 for ; Tue, 3 Dec 2002 01:00:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB363Me01240 for sip-archive@odin.ietf.org; Tue, 3 Dec 2002 01:03:22 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3632v01216; Tue, 3 Dec 2002 01:03:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB360jv01071 for ; Tue, 3 Dec 2002 01:00:45 -0500 Received: from bdsl.greycouncil.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28415 for ; Tue, 3 Dec 2002 00:57:45 -0500 (EST) Received: from txdwillis (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.5/8.12.5) with ESMTP id gB360SQs007639; Tue, 3 Dec 2002 00:00:29 -0600 From: "Dean Willis" To: "'Mary Barnes'" , Cc: Subject: RE: [Sip] B2BUA Date: Tue, 3 Dec 2002 00:00:19 -0600 Message-ID: <001d01c29a91$440ca510$0100a8c0@txdwillis> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001E_01C29A5E.F9723510" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <1B54FA3A2709D51195C800508BF9386A05A7CB19@zrc2c000.us.nortel.com> Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_001E_01C29A5E.F9723510 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Mary said: ----- So, I guess you're suggesting that the term "concatenation" is not accurate or is misleading and I guess that depends upon how loosely one applies the term concatenation here; my assumption had been that it meant that they were "linked" (consistent with Webster's definition of concatenate) in some manner which is unprescribed, so I think your point 2 below isn't a problem with the current definition. My understanding of the current definition is that there isn't anything more for the SIP protocol to prescribe about the operation of a B2BUA other than what is required from a protocol perspective to function as a UAC and a UAS. From a protocol perspective, it is a logical entity and thus whether there's one or multiple doesn't seem to apply. I think what you (and perhaps others) are suggesting is that there's a definition of a B2BUA that more closely parallels the definition of a Proxy Server since in many cases the physical rendition of the logical B2BUA functionality would be replacing a Proxy Server in a network. And I think this is where the problem begins, as many are opposed to this model (as it increases the complexity, etc.) and this is why the logical definition has remained. ------ Well, I think the argument is being made that this definition doesn't (for some reason that I seem incapable of comprehending) work for some people, and that therefore we should clarify it. At the fundamental level, I think some people do not find the implications of this definition obvious. There are several ways we might address this. We might add examples. We might add "In other words, the only relationship between the UAC and the UAS is the application logic, and that can do anything that one can imagine an application doing", or we might just use better wording. I don't think the argument is being made that the definition in 3261 is wrong, just that we can make it better for those who don't get it the way it is written. Of course, if we discuss it here long enough, maybe most of them WILL get it -- but that doesn't help the ones who aren't "here" yet. I think that Bill is suggesting that there is also something BETWEEN the B2BUA and the conformant proxy, and that the world would be a better place (ok, maybe not THAT much better) if our taxonomy also included this "between" thing. -- Dean ------=_NextPart_000_001E_01C29A5E.F9723510 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Mary = said:
 -----
 So, I = guess you're=20 suggesting that the term "concatenation" is not accurate or is = misleading and I=20 guess that depends upon how loosely one applies the term concatenation = here; my=20 assumption had been that it meant that they were "linked" (consistent = with=20 Webster's definition of concatenate) in some manner which is = unprescribed, so I=20 think your point 2 below isn't a problem with the current = definition.  My=20 understanding of the current definition is that there isn't anything = more for=20 the SIP protocol to prescribe about the operation of a B2BUA other than = what is=20 required from a protocol perspective to function as a UAC and a UAS. = From a=20 protocol perspective, it is a logical entity and thus whether there's = one or=20 multiple doesn't seem to apply.  I think what you (and perhaps = others) are=20 suggesting is that there's a definition of a B2BUA that more closely = parallels=20 the definition of a Proxy Server since in many cases the physical = rendition of=20 the logical B2BUA functionality would be replacing a Proxy Server in a = network.=20 And I think this is where the problem begins, as many are opposed to = this model=20 (as it increases the complexity, etc.) and this is why the logical = definition=20 has remained.  
------ 
 
Well,=20 I think the argument is being made that this definition doesn't (for = some reason=20 that I seem incapable of comprehending) work for some people, and that = therefore=20 we should clarify it. At the fundamental level, I think some people do = not find=20 the implications of this definition obvious. There are several ways we = might=20 address this. We might add examples. We might add "In other words, the = only=20 relationship between the UAC and the UAS is the application logic, and = that can=20 do anything that one can imagine an application doing", or we might just = use=20 better wording.
 
I=20 don't think the argument is being made that the definition in 3261 is = wrong,=20 just that we can make it better for those who don't get it the way it is = written. Of course, if we discuss it here long enough, maybe most of = them WILL=20 get it -- but that doesn't help the ones who aren't "here"=20 yet.
 
I=20 think that Bill is suggesting that there is also something BETWEEN the = B2BUA and=20 the conformant proxy, and that the world would be a better place (ok, = maybe not=20 THAT much better) if our taxonomy also included this "between"=20 thing.
 
--
Dean
 
------=_NextPart_000_001E_01C29A5E.F9723510-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Tue Dec 3 01:23:06 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29013 for ; Tue, 3 Dec 2002 01:23:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB36PYt02750 for sip-archive@odin.ietf.org; Tue, 3 Dec 2002 01:25:34 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB36PEv02724; Tue, 3 Dec 2002 01:25:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB36OMv02687 for ; Tue, 3 Dec 2002 01:24:22 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28975 for ; Tue, 3 Dec 2002 01:21:22 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gB36OAKV013704; Tue, 3 Dec 2002 07:24:10 +0100 (MET) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id YCDYV3BG; Tue, 3 Dec 2002 07:24:10 +0100 Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.68]) by hendrix.lmf.ericsson.se (8.12.6/8.12.6/lmf-2.1-jcs) with ESMTP id gB36O9u4013139; Tue, 3 Dec 2002 08:24:09 +0200 (EET) Message-ID: <3DEC4E0C.E1F0635E@lmf.ericsson.se> Date: Tue, 03 Dec 2002 08:24:13 +0200 X-Sybari-Trust: 9fe629a1 ca231590 3510fc58 00000138 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg , sip@ietf.org Subject: Re: [Sip] The fate of session timer? References: <3DD3B930.E6230AC3@lmf.ericsson.se> <3DD4A760.BD1FF3C3@lmf.ericsson.se> <3DD89B30.9010709@dynamicsoft.com> <3DD8DE55.34DF9786@lmf.ericsson.se> <3DDAB04E.3010803@dynamicsoft.com> <3DDB75BC.8AEF2A38@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, Any news on this issue? Was this discussed at the Atlanta IETF? Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Tue Dec 3 04:01:25 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11827 for ; Tue, 3 Dec 2002 04:01:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB393uY23014 for sip-archive@odin.ietf.org; Tue, 3 Dec 2002 04:03:56 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB393Rv22966; Tue, 3 Dec 2002 04:03:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB391Tv22632 for ; Tue, 3 Dec 2002 04:01:29 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11729 for ; Tue, 3 Dec 2002 03:58:27 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gB391AKV022302; Tue, 3 Dec 2002 10:01:10 +0100 (MET) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id YBCSXKCG; Tue, 3 Dec 2002 10:01:10 +0100 Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.18]) by hendrix.lmf.ericsson.se (8.12.6/8.12.6/lmf-2.1-jcs) with ESMTP id gB3919u4022999; Tue, 3 Dec 2002 11:01:09 +0200 (EET) Message-ID: <3DEC72D5.85FFCB6F@lmf.ericsson.se> Date: Tue, 03 Dec 2002 11:01:09 +0200 X-Sybari-Trust: 25604ff3 ca231590 3510fc58 00000138 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mpierce1@aol.com CC: prasanna@huawei.com, rshiroor@aplion.stpn.soft.net, sip@ietf.org Subject: Re: [Sip] different messages with same call-id before 100 is sent out References: <90.2fe85b0b.2b1cf7ac@aol.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, (I cannot "quote" your mail to answer more specifically because you sent in in html format.) Anyway, what you are proposing is a variant of what it has been proposed a (large) number of times in the mailing list. It was also discussed in the Australian IETF. Thanks, Gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Tue Dec 3 04:03:53 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11899 for ; Tue, 3 Dec 2002 04:03:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB396OA23196 for sip-archive@odin.ietf.org; Tue, 3 Dec 2002 04:06:24 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3966v23179; Tue, 3 Dec 2002 04:06:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB395Lv23123 for ; Tue, 3 Dec 2002 04:05:21 -0500 Received: from mta0 (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11875 for ; Tue, 3 Dec 2002 04:02:18 -0500 (EST) Received: from prasannacl1105 (mta0 [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0H6J00KQAD5J4D@mta0.huawei.com> for sip@ietf.org; Tue, 03 Dec 2002 17:03:21 +0800 (CST) Date: Tue, 03 Dec 2002 14:31:12 +0530 From: Prasanna Venkatesh Subject: RE: [Sip] different messages with same call-id before 100 is sent out In-reply-to: <3DEC72D5.85FFCB6F@lmf.ericsson.se> To: Gonzalo Camarillo , Mpierce1@aol.com Cc: rshiroor@aplion.stpn.soft.net, sip@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT One more query Gonzalo. Can the draft define some behaviour on the UAS (egress GW) for out-of-order messages? There may be typical issues for SIP-T like, the first message bore the IAM and a subsequent one had the SAM. If they come out of order, the egress GW's behaviour is confusing. Regards, Prasanna Huawei Technologies -----Original Message----- From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] Sent: Tuesday, December 03, 2002 2:31 PM To: Mpierce1@aol.com Cc: prasanna@huawei.com; rshiroor@aplion.stpn.soft.net; sip@ietf.org Subject: Re: [Sip] different messages with same call-id before 100 is sent out Hi, (I cannot "quote" your mail to answer more specifically because you sent in in html format.) Anyway, what you are proposing is a variant of what it has been proposed a (large) number of times in the mailing list. It was also discussed in the Australian IETF. Thanks, Gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Tue Dec 3 04:29:07 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12435 for ; Tue, 3 Dec 2002 04:29:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB39Vcf24908 for sip-archive@odin.ietf.org; Tue, 3 Dec 2002 04:31:38 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB39VHv24898; Tue, 3 Dec 2002 04:31:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB39Ucv24851 for ; Tue, 3 Dec 2002 04:30:38 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12406 for ; Tue, 3 Dec 2002 04:27:36 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gB39UGKV002310; Tue, 3 Dec 2002 10:30:16 +0100 (MET) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id YBCYT6H4; Tue, 3 Dec 2002 10:30:16 +0100 Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.18]) by hendrix.lmf.ericsson.se (8.12.6/8.12.6/lmf-2.1-jcs) with ESMTP id gB39UGu4024773; Tue, 3 Dec 2002 11:30:16 +0200 (EET) Message-ID: <3DEC79A7.E60EB248@lmf.ericsson.se> Date: Tue, 03 Dec 2002 11:30:15 +0200 X-Sybari-Trust: 15a10b6e ca231590 3510fc58 00000138 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Prasanna Venkatesh CC: Mpierce1@aol.com, rshiroor@aplion.stpn.soft.net, sip@ietf.org Subject: Re: [Sip] different messages with same call-id before 100 is sent out References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, > Can the draft define some behaviour on the UAS (egress GW) for out-of-order > messages? There may be typical issues for SIP-T like, the first message > bore the IAM and a subsequent one had the SAM. All the INVITEs contain the IAM and all the subsequent SAMs. Anyway, I will see if I can clarify the behavior in the draft so that it is clearer. Thanks, Gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Tue Dec 3 04:42:12 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12906 for ; Tue, 3 Dec 2002 04:42:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB39ihs26150 for sip-archive@odin.ietf.org; Tue, 3 Dec 2002 04:44:43 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB39iPv26102; Tue, 3 Dec 2002 04:44:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB39hav26026 for ; Tue, 3 Dec 2002 04:43:36 -0500 Received: from mta0 (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12804 for ; Tue, 3 Dec 2002 04:40:32 -0500 (EST) Received: from prasannacl1105 (mta0 [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0H6J00JEMESUZB@mta0.huawei.com> for sip@ietf.org; Tue, 03 Dec 2002 17:38:58 +0800 (CST) Date: Tue, 03 Dec 2002 15:06:47 +0530 From: Prasanna Venkatesh Subject: RE: [Sip] different messages with same call-id before 100 is sent out In-reply-to: <3DEC79A7.E60EB248@lmf.ericsson.se> To: Gonzalo Camarillo Cc: Mpierce1@aol.com, rshiroor@aplion.stpn.soft.net, sip@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Is this behaviour that all INVITEs contain all the IAMs and SAMs mentioned in the draft. I am very sorry if I have overlooked it. regards, Prasanna -----Original Message----- From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] Sent: Tuesday, December 03, 2002 3:00 PM To: Prasanna Venkatesh Cc: Mpierce1@aol.com; rshiroor@aplion.stpn.soft.net; sip@ietf.org Subject: Re: [Sip] different messages with same call-id before 100 is sent out Hi, > Can the draft define some behaviour on the UAS (egress GW) for out-of-order > messages? There may be typical issues for SIP-T like, the first message > bore the IAM and a subsequent one had the SAM. All the INVITEs contain the IAM and all the subsequent SAMs. Anyway, I will see if I can clarify the behavior in the draft so that it is clearer. Thanks, Gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Tue Dec 3 05:08:04 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13489 for ; Tue, 3 Dec 2002 05:08:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB3AAMR27715 for sip-archive@odin.ietf.org; Tue, 3 Dec 2002 05:10:22 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3A9uv27667; Tue, 3 Dec 2002 05:09:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3A6wv27019 for ; Tue, 3 Dec 2002 05:06:58 -0500 Received: from hss.hns.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13435 for ; Tue, 3 Dec 2002 05:04:03 -0500 (EST) From: stoshniwal@hss.hns.com Received: from sampark.hss.hns.com (sampark [139.85.229.22]) by hss.hns.com (8.11.6/8.11.2) with SMTP id gB39ici26419; Tue, 3 Dec 2002 15:14:46 +0530 Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256C84.00372A8B ; Tue, 3 Dec 2002 15:32:33 +0530 X-Lotus-FromDomain: HSSBLR To: "Peterson, Jon" cc: sip@ietf.org Message-ID: <65256C84.00372915.00@sampark.hss.hns.com> Date: Tue, 3 Dec 2002 15:32:29 +0530 Subject: RE: SIPS related clarifications (was: [Sip] SIPS question) Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi Peterson, Thanks for your response. Please find some comments inline. Regards, Siddharth. ------------------------------------------------------- Siddharth Toshniwal Hughes Software Systems Prestige Opal http://www.hssworld.com 146, Infantry Road Ph (O): +91-80-2286390 (7094) Bangalore-560001, India Mobile: +91-9845154068 ------------------------------------------------------- > We did discuss this issue a bit in Atlanta. > Unfortunately, I think all we agreed on is that we > all need to think about it some more. Aside from this question, can someone suggest what is the best way to track open issues related to the spec? I tried the bugzilla this time around, but as you mentioned some issues (like this one) may take a while to reach there if there are other significant issues surrounding the original question that you wish to discuss before proposing a solution. If the spec is going to undergo rewording in some aspect, I would request the authors to post to the discussion list while they discussed the changes... else people may implement incorrect behaviour and would need to go back and change the same when the draft gets fixed. It would help if you could give me a pointer for this IETF's minutes regarding SIP issues that were discussed. >> * Is it allowed for a SIP proxy that got a request on >> TLS to forward the request downstream on a non-TLS >> protocol? > > Depends on what you mean by 'got a request'. This also > doesn't say whether or not SIPS appears in the Request-URI > or not; it is possible for a proxy server to receive a > request over TLS that does not have the SIPS URI scheme > in the Request-URI. I'm sorry for the ambiguity in my question. I had referred to the foll scenario: Lets say that the request-uri does not contain "sips:" but the request was received on TLS (perhaps because of a Route header configured with a previous hop). Can the proxy send it downstream on a non-TLS protocol if there are no more Route headers present in the message? From your mail, I gather this is allowed. >> while Rosenberg had mentioned that the presence >> of "sips:" should imply that the end-to-end path is >> secure. > > If SIPS appears in the Request-URI of the original > request sent by the UAC, it implies this end-to-end > path security. >> I guess the way I understand the spec stands >> at present is that if the Req-URI is re-written to a >> "sips:" URL at any stage of the routing, then any hop >> downstream _from_this_hop_onwards_ has to forward the >> request on TLS. > > I agree, that is how we should understand it - with the > caveat that SIPS only applies to the entire path until > it reaches the domain indicated by the hostname portion > of the Request-URI. Once a proxy server in the destination > gets hold of the request, it can retarget it arbitrarily > (to non-SIPS resources, if it wishes). Aren't the 2 texts quoted by you at opposite ends? a) the UAS cannot be sure of end-to-end security if it received a INVITE with the request-URI as "sips:" ... Some hop in the middle could have modified the req-URI for "sips:". It may even be the proxy with whom the UAS registered with the Contact as "sips:" ? b) (If the caveat that you mentioned holds) the UAC cannot be sure that the UAS received the request on TLS. Shouldn't the destination's proxy be disallowed to route a request received on TLS to a non-TLS client? >> * What is the response code to be used by a UAS to >> inform the UAC that it is not willing to accept >> insecure calls and that the UAC should retry the >> request on TLS? >> > > Although 416 might look like an attractive candidate, the language in > 8.1.3.5 makes it a little ugly. I would suggest 403. can we add this text to the spec too if everyone agrees on it? _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Tue Dec 3 05:37:40 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13991 for ; Tue, 3 Dec 2002 05:37:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB3AdxX29516 for sip-archive@odin.ietf.org; Tue, 3 Dec 2002 05:39:59 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3AdYv29502; Tue, 3 Dec 2002 05:39:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3AcQv29444 for ; Tue, 3 Dec 2002 05:38:26 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13946 for ; Tue, 3 Dec 2002 05:35:35 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gB3Ac9KV026850; Tue, 3 Dec 2002 11:38:09 +0100 (MET) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id YCDYXP3Q; Tue, 3 Dec 2002 11:38:08 +0100 Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.18]) by hendrix.lmf.ericsson.se (8.12.6/8.12.6/lmf-2.1-jcs) with ESMTP id gB3Ac8u4028865; Tue, 3 Dec 2002 12:38:08 +0200 (EET) Message-ID: <3DEC898F.82EAA699@lmf.ericsson.se> Date: Tue, 03 Dec 2002 12:38:07 +0200 X-Sybari-Trust: 2df32d2d ca231590 3510fc58 00000138 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Prasanna Venkatesh CC: Mpierce1@aol.com, rshiroor@aplion.stpn.soft.net, sip@ietf.org Subject: Re: [Sip] different messages with same call-id before 100 is sent out References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, 7th paragraph of section 3.3: If the gateway is encapsulating ISUP messages as SIP bodies, it should place the IAM and all the SAMs received so far in this INVITE. Regards, Gonzalo Prasanna Venkatesh wrote: > > Is this behaviour that all INVITEs contain all the IAMs and SAMs mentioned > in the draft. I am very sorry if I have overlooked it. > regards, > Prasanna > > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Sent: Tuesday, December 03, 2002 3:00 PM > To: Prasanna Venkatesh > Cc: Mpierce1@aol.com; rshiroor@aplion.stpn.soft.net; sip@ietf.org > Subject: Re: [Sip] different messages with same call-id before 100 is > sent out > > Hi, > > > Can the draft define some behaviour on the UAS (egress GW) for > out-of-order > > messages? There may be typical issues for SIP-T like, the first message > > bore the IAM and a subsequent one had the SAM. > > All the INVITEs contain the IAM and all the subsequent SAMs. > > Anyway, I will see if I can clarify the behavior in the draft so that it > is clearer. > > Thanks, > > Gonzalo -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Tue Dec 3 05:59:56 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14308 for ; Tue, 3 Dec 2002 05:59:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB3B2EQ30565 for sip-archive@odin.ietf.org; Tue, 3 Dec 2002 06:02:14 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3B1Pv30519; Tue, 3 Dec 2002 06:01:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3B0Pv30469 for ; Tue, 3 Dec 2002 06:00:25 -0500 Received: from avgw.vxserver.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA14285 for ; Tue, 3 Dec 2002 05:57:35 -0500 (EST) Received: from disney.internal.ridgewaysystems.com ([194.128.67.181]) by avgw.vxserver.com (NAVGW 2.5.2.12) with SMTP id M2002120310590516610 for ; Tue, 03 Dec 2002 10:59:05 GMT Received: from Unknown [10.1.1.1] by disney.internal.ridgewaysystems.com - SurfControl E-mail Filter (4.5); Tuesday, 03 December 2002, 11:00:39 Received: by ridgeway.internal.ridgewaysystems.com with Internet Mail Service (5.5.2653.19) id ; Tue, 3 Dec 2002 11:00:17 -0000 Message-ID: <00533D13955AD411AF3800A0C9B4263994D878@ridgeway.internal.ridgewaysystems.com> From: Phil Reynolds To: "'sip@ietf.org'" Date: Tue, 3 Dec 2002 11:00:15 -0000 Subject: FW: [Sip] B2BUA MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--=_NextPart_ST_11_00_40_Tuesday_December_03_2002_27867" X-Mailer: Internet Mail Service (5.5.2653.19) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , 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_ST_11_00_40_Tuesday_December_03_2002_27867 Content-Type: text/plain The problem as I see it is that the RFC defines 2 distinct intermediary entities a "SIP Proxy" which has limited functionality, i.e. it is not allowed to modify the body of the message, and a B2BUA which is a full blown pair of Uas with all the transactional and dialogue stuff. What we build is something in the middle... We rely on the "real" UAs to do all the transactions, retries dialogs etc, and we modify the messages and SDP bodies as they go through. Personally I don't care what the spec says. We build a system that does a useful function, if it doesn't fit into a category that is defined by the spec -- so what? However the marketing types don't quite see it that way ;-) If the spec is going to define the permissible intermediaries, it SHOULD allow for things that are not implemented as UAs but externally appear to be so. -----Original Message----- From: Mary Barnes [mailto:mbarnes@nortelnetworks.com] Sent: 02 December 2002 16:54 To: 'Phil Reynolds'; sip@ietf.org Subject: RE: [Sip] B2BUA Hi all, I guess I have to ask, what's the problem with the definition in RFC 3261? ----=_NextPart_ST_11_00_40_Tuesday_December_03_2002_27867 Content-Type: text/html Content-Transfer-Encoding: quoted-printable FW: [Sip] B2BUA




The problem as I see it is that the RFC defines 2 distinc= t intermediary entities a "SIP Proxy" which has limited functiona= lity, i.e. it is not allowed to modify the body of the message, and a B2BUA= which is a full blown pair of Uas with all the transactional and dialogue = stuff.

What we build is something in the middle... We rely on th= e "real" UAs to do all the transactions, retries dialogs etc, and= we modify the messages and SDP bodies as they go through.

Personally I don't care what the spec says. We build a sy= stem that does a useful function, if it doesn't fit into a category that is= defined by the spec -- so what? However the marketing types don't quite se= e it that way ;-)

If the spec is going to define the permissible intermedia= ries, it SHOULD allow for things that are not implemented as UAs but extern= ally appear to be so.

-----Original Message-----
From: Mary Barnes [mailto:mbarnes@nortelnetworks.com]
Sent: 02 December 2002 16:54
To: 'Phil Reynolds'; sip@ietf.org
Subject: RE: [Sip] B2BUA


Hi all,

I guess I have to ask, what's the problem with the defini= tion in RFC 3261?

----=_NextPart_ST_11_00_40_Tuesday_December_03_2002_27867-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Tue Dec 3 08:23:07 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18320 for ; Tue, 3 Dec 2002 08:23:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB3DPRx06808 for sip-archive@odin.ietf.org; Tue, 3 Dec 2002 08:25:27 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3DP2v06789; Tue, 3 Dec 2002 08:25:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3DNsv06739 for ; Tue, 3 Dec 2002 08:23:54 -0500 Received: from mail-blue.research.att.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18231 for ; Tue, 3 Dec 2002 08:21:02 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 555AF4CF6C; Tue, 3 Dec 2002 08:23:50 -0500 (EST) Received: from fish.research.att.com (fish.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id IAA08405; Tue, 3 Dec 2002 08:23:46 -0500 (EST) From: William Marshall Received: (from wtm@localhost) by fish.research.att.com (SGI-8.9.3/8.8.5) id IAA72497; Tue, 3 Dec 2002 08:29:00 -0500 (EST) Date: Tue, 3 Dec 2002 08:29:00 -0500 (EST) Message-Id: <200212031329.IAA72497@fish.research.att.com> To: dean.willis@softarmor.com Cc: mbarnes@nortelnetworks.com, Juan-Carlos.Rojas@alcatel.fr, sip@ietf.org Subject: RE: [Sip] B2BUA Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Dean wrote: > I think that Bill is suggesting that there is also something BETWEEN the > B2BUA and the conformant proxy, and that the world would be a better > place (ok, maybe not THAT much better) if our taxonomy also included > this "between" thing. To further elaborate, there certainly exists on paper a box that does some abritrary and weird algorithm, not conformant with any of the rules in rfc3261, that transforms requests and response and breaks everything that goes through it. Call it "Dean's devilish-B2BUA". But I don't think anyone builds such a box. At least not intentionally. What is built instead are boxes that are close to the definition of proxies, but not quite. They serve a real need in the market (and vendors tend to build what sells). But due to various details, like looking at the attachment (a proxy-no-no) to open pinholes in the firewall, they don't strictly qualify as proxies. Saying there are only two types of boxes, proxies and devilish-B2BUAs, ignores the reality. The writing of an accurate definition of a B2BUA is only the first step. Unfortunately there is interaction with definition of new services. The definition of proxy is very restrictive for a reason, so that it leaves wide open the possibilities for designs of new services. But the not-quite-proxy boxes will exist, and endpoints will need to interoperate with them. So services will also need to work through them. This will impose some restrictions on how new services are defined. I think the objective should be to minimize those restrictions; to do that the variations in not-quite-proxy behavior need to be documented and made predictable so that services can be defined to interwork with them. Having services work through the "something BETWEEN the B2BUA and the conformant proxy" would certainly make the world a much better place (yes, THAT much better). Bill Marshall wtm@research.att.com -----original message----- From: "Dean Willis" To: "'Mary Barnes'" , Cc: Subject: RE: [Sip] B2BUA Date: Tue, 3 Dec 2002 00:00:19 -0600 Mary said: ----- So, I guess you're suggesting that the term "concatenation" is not accurate or is misleading and I guess that depends upon how loosely one applies the term concatenation here; my assumption had been that it meant that they were "linked" (consistent with Webster's definition of concatenate) in some manner which is unprescribed, so I think your point 2 below isn't a problem with the current definition. My understanding of the current definition is that there isn't anything more for the SIP protocol to prescribe about the operation of a B2BUA other than what is required from a protocol perspective to function as a UAC and a UAS. >From a protocol perspective, it is a logical entity and thus whether there's one or multiple doesn't seem to apply. I think what you (and perhaps others) are suggesting is that there's a definition of a B2BUA that more closely parallels the definition of a Proxy Server since in many cases the physical rendition of the logical B2BUA functionality would be replacing a Proxy Server in a network. And I think this is where the problem begins, as many are opposed to this model (as it increases the complexity, etc.) and this is why the logical definition has remained. ------ Well, I think the argument is being made that this definition doesn't (for some reason that I seem incapable of comprehending) work for some people, and that therefore we should clarify it. At the fundamental level, I think some people do not find the implications of this definition obvious. There are several ways we might address this. We might add examples. We might add "In other words, the only relationship between the UAC and the UAS is the application logic, and that can do anything that one can imagine an application doing", or we might just use better wording. I don't think the argument is being made that the definition in 3261 is wrong, just that we can make it better for those who don't get it the way it is written. Of course, if we discuss it here long enough, maybe most of them WILL get it -- but that doesn't help the ones who aren't "here" yet. I think that Bill is suggesting that there is also something BETWEEN the B2BUA and the conformant proxy, and that the world would be a better place (ok, maybe not THAT much better) if our taxonomy also included this "between" thing. -- 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 mailnull@www1.ietf.org Tue Dec 3 08:34:21 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18927 for ; Tue, 3 Dec 2002 08:34:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB3DagQ07582 for sip-archive@odin.ietf.org; Tue, 3 Dec 2002 08:36:42 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3DaEv07564; Tue, 3 Dec 2002 08:36:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3DZYv07490 for ; Tue, 3 Dec 2002 08:35:34 -0500 Received: from zsc3s004.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18800 for ; Tue, 3 Dec 2002 08:32:42 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by zsc3s004.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gB3DZSA09620; Tue, 3 Dec 2002 05:35:28 -0800 (PST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gB3DZdw23105; Tue, 3 Dec 2002 07:35:40 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 3 Dec 2002 07:35:26 -0600 Message-ID: <1B54FA3A2709D51195C800508BF9386A05A7CB1E@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'William Marshall'" , dean.willis@softarmor.com Cc: Juan-Carlos.Rojas@alcatel.fr, sip@ietf.org Subject: RE: [Sip] B2BUA Date: Tue, 3 Dec 2002 07:35:26 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C29AD0.D6E80480" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , 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_01C29AD0.D6E80480 Content-Type: text/plain; charset="iso-8859-1" Bill et al, My comments are embedded below [MB]: -----Original Message----- From: William Marshall [mailto:wtm@research.att.com] Sent: Tuesday, December 03, 2002 7:29 AM To: dean.willis@softarmor.com Cc: Barnes, Mary [NGC:B602:EXCH]; Juan-Carlos.Rojas@alcatel.fr; sip@ietf.org Subject: RE: [Sip] B2BUA Dean wrote: > I think that Bill is suggesting that there is also something BETWEEN the > B2BUA and the conformant proxy, and that the world would be a better > place (ok, maybe not THAT much better) if our taxonomy also included > this "between" thing. To further elaborate, there certainly exists on paper a box that does some abritrary and weird algorithm, not conformant with any of the rules in rfc3261, that transforms requests and response and breaks everything that goes through it. Call it "Dean's devilish-B2BUA". But I don't think anyone builds such a box. At least not intentionally. What is built instead are boxes that are close to the definition of proxies, but not quite. They serve a real need in the market (and vendors tend to build what sells). But due to various details, like looking at the attachment (a proxy-no-no) to open pinholes in the firewall, they don't strictly qualify as proxies. [MB]: And I think this is where we get into problems trying to agree what defines this in-between thing, as everyone has something that is likely slightly different. Saying there are only two types of boxes, proxies and devilish-B2BUAs, ignores the reality. The writing of an accurate definition of a B2BUA is only the first step. Unfortunately there is interaction with definition of new services. The definition of proxy is very restrictive for a reason, so that it leaves wide open the possibilities for designs of new services. But the not-quite-proxy boxes will exist, and endpoints will need to interoperate with them. So services will also need to work through them. This will impose some restrictions on how new services are defined. I think the objective should be to minimize those restrictions; to do that the variations in not-quite-proxy behavior need to be documented and made predictable so that services can be defined to interwork with them. [MB]: Well, perhaps the most reasonable way forward would be to put together an informational draft defining the various "flavors" of these in-between things and categorizing the issues for service interworking introduced by each of the variations. Some of this, of course, will lead us back to the list of the reasons why some folks consider these things "evil", but would this also not lead us down the road of being very prescriptive about how services work in SIP? Having services work through the "something BETWEEN the B2BUA and the conformant proxy" would certainly make the world a much better place (yes, THAT much better). Bill Marshall wtm@research.att.com -----original message----- From: "Dean Willis" To: "'Mary Barnes'" , Cc: Subject: RE: [Sip] B2BUA Date: Tue, 3 Dec 2002 00:00:19 -0600 Mary said: ----- So, I guess you're suggesting that the term "concatenation" is not accurate or is misleading and I guess that depends upon how loosely one applies the term concatenation here; my assumption had been that it meant that they were "linked" (consistent with Webster's definition of concatenate) in some manner which is unprescribed, so I think your point 2 below isn't a problem with the current definition. My understanding of the current definition is that there isn't anything more for the SIP protocol to prescribe about the operation of a B2BUA other than what is required from a protocol perspective to function as a UAC and a UAS. >From a protocol perspective, it is a logical entity and thus whether there's one or multiple doesn't seem to apply. I think what you (and perhaps others) are suggesting is that there's a definition of a B2BUA that more closely parallels the definition of a Proxy Server since in many cases the physical rendition of the logical B2BUA functionality would be replacing a Proxy Server in a network. And I think this is where the problem begins, as many are opposed to this model (as it increases the complexity, etc.) and this is why the logical definition has remained. ------ Well, I think the argument is being made that this definition doesn't (for some reason that I seem incapable of comprehending) work for some people, and that therefore we should clarify it. At the fundamental level, I think some people do not find the implications of this definition obvious. There are several ways we might address this. We might add examples. We might add "In other words, the only relationship between the UAC and the UAS is the application logic, and that can do anything that one can imagine an application doing", or we might just use better wording. I don't think the argument is being made that the definition in 3261 is wrong, just that we can make it better for those who don't get it the way it is written. Of course, if we discuss it here long enough, maybe most of them WILL get it -- but that doesn't help the ones who aren't "here" yet. I think that Bill is suggesting that there is also something BETWEEN the B2BUA and the conformant proxy, and that the world would be a better place (ok, maybe not THAT much better) if our taxonomy also included this "between" thing. -- Dean ------_=_NextPart_001_01C29AD0.D6E80480 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] B2BUA

Bill et al,

My comments are embedded below [MB]:

-----Original Message-----
From: William Marshall [mailto:wtm@research.att.com]
Sent: Tuesday, December 03, 2002 7:29 AM
To: dean.willis@softarmor.com
Cc: Barnes, Mary [NGC:B602:EXCH]; = Juan-Carlos.Rojas@alcatel.fr;
sip@ietf.org
Subject: RE: [Sip] B2BUA


Dean wrote:
> I think that Bill is suggesting that there is = also something BETWEEN the
> B2BUA and the conformant proxy, and that the = world would be a better
> place (ok, maybe not THAT much better) if our = taxonomy also included
> this "between" thing.

To further elaborate, there certainly exists on paper = a box that does
some abritrary and weird algorithm, not conformant = with any of the
rules in rfc3261, that transforms requests and = response and breaks
everything that goes through it.  Call it = "Dean's devilish-B2BUA".

But I don't think anyone builds such a box.  At = least not intentionally.

What is built instead are boxes that are close to the = definition of
proxies, but not quite.  They serve a real need = in the market (and
vendors tend to build what sells).  But due to = various details, like
looking at the attachment (a proxy-no-no) to open = pinholes in the firewall,
they don't strictly qualify as proxies.

[MB]: And I think this is where we get into problems = trying to agree what defines this in-between thing, as everyone has = something that is likely slightly different. 

Saying there are only two types of boxes, proxies and = devilish-B2BUAs,
ignores the reality.

The writing of an accurate definition of a B2BUA is = only the first step.
Unfortunately there is interaction with definition = of new services.  The
definition of proxy is very restrictive for a = reason, so that it leaves
wide open the possibilities for designs of new = services.  But the
not-quite-proxy boxes will exist, and endpoints will = need to interoperate
with them.  So services will also need to work = through them.  This will
impose some restrictions on how new services are = defined.  I think the
objective should be to minimize those restrictions; = to do that the variations
in not-quite-proxy behavior need to be documented = and made predictable so
that services can be defined to interwork with = them.

[MB]: Well, perhaps the most reasonable way forward = would be to put together an informational draft defining the various = "flavors" of these in-between things and categorizing the = issues for service interworking introduced by each of the variations.&nb= sp; Some of this, of course, will lead us back to the list of the = reasons why some folks consider these things "evil", but = would this also not lead us down the road of being very prescriptive = about how services work in SIP?

Having services work through the "something = BETWEEN the B2BUA and the
conformant proxy" would certainly make the = world a much better place
(yes, THAT much better).

Bill Marshall
wtm@research.att.com

-----original message-----
From: "Dean Willis" = <dean.willis@softarmor.com>
To: "'Mary Barnes'" = <mbarnes@nortelnetworks.com>,
        = <Juan-Carlos.Rojas@alcatel.fr>
Cc: <sip@ietf.org>
Subject: RE: [Sip] B2BUA
Date: Tue, 3 Dec 2002 00:00:19 -0600

Mary said:
 -----
 So, I guess you're suggesting that the term = "concatenation" is not
accurate or is misleading and I guess that depends = upon how loosely one
applies the term concatenation here; my assumption = had been that it
meant that they were "linked" (consistent = with Webster's definition of
concatenate) in some manner which is unprescribed, = so I think your point
2 below isn't a problem with the current = definition.  My understanding
of the current definition is that there isn't = anything more for the SIP
protocol to prescribe about the operation of a B2BUA = other than what is
required from a protocol perspective to function as = a UAC and a UAS.
>From a protocol perspective, it is a logical = entity and thus whether
there's one or multiple doesn't seem to apply.  = I think what you (and
perhaps others) are suggesting is that there's a = definition of a B2BUA
that more closely parallels the definition of a = Proxy Server since in
many cases the physical rendition of the logical = B2BUA functionality
would be replacing a Proxy Server in a network. And = I think this is
where the problem begins, as many are opposed to = this model (as it
increases the complexity, etc.) and this is why the = logical definition
has remained. 
------
 
Well, I think the argument is being made that this = definition doesn't
(for some reason that I seem incapable of = comprehending) work for some
people, and that therefore we should clarify it. At = the fundamental
level, I think some people do not find the = implications of this
definition obvious. There are several ways we might = address this. We
might add examples. We might add "In other = words, the only relationship
between the UAC and the UAS is the application = logic, and that can do
anything that one can imagine an application = doing", or we might just
use better wording.
 
I don't think the argument is being made that the = definition in 3261 is
wrong, just that we can make it better for those who = don't get it the
way it is written. Of course, if we discuss it here = long enough, maybe
most of them WILL get it -- but that doesn't help = the ones who aren't
"here" yet.
 
I think that Bill is suggesting that there is also = something BETWEEN the
B2BUA and the conformant proxy, and that the world = would be a better
place (ok, maybe not THAT much better) if our = taxonomy also included
this "between" thing.
 
--
Dean
 

------_=_NextPart_001_01C29AD0.D6E80480-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Tue Dec 3 08:50:33 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19634 for ; Tue, 3 Dec 2002 08:50:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB3Dqsp09246 for sip-archive@odin.ietf.org; Tue, 3 Dec 2002 08:52:54 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3DqLv09222; Tue, 3 Dec 2002 08:52:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3DpZv09102 for ; Tue, 3 Dec 2002 08:51:35 -0500 Received: from mail-green.research.att.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19545 for ; Tue, 3 Dec 2002 08:48:42 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id D10E11E169; Tue, 3 Dec 2002 08:51:30 -0500 (EST) Received: from fish.research.att.com (fish.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id IAA08693; Tue, 3 Dec 2002 08:51:27 -0500 (EST) From: William Marshall Received: (from wtm@localhost) by fish.research.att.com (SGI-8.9.3/8.8.5) id IAA35260; Tue, 3 Dec 2002 08:57:19 -0500 (EST) Date: Tue, 3 Dec 2002 08:57:19 -0500 (EST) Message-Id: <200212031357.IAA35260@fish.research.att.com> To: mbarnes@nortelnetworks.com Cc: dean.willis@softarmor.com, Juan-Carlos.Rojas@alcatel.fr, sip@ietf.org Subject: RE: [Sip] B2BUA Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Mary wrote: > [MB]: Well, perhaps the most reasonable way forward would be to put together > an informational draft defining the various "flavors" of these in-between > things and categorizing the issues for service interworking introduced by > each of the variations. Some of this, of course, will lead us back to the > list of the reasons why some folks consider these things "evil", but would > this also not lead us down the road of being very prescriptive about how > services work in SIP? Sounds good. In all these different "flavors" there are likely lots of dont-cares in how to handle requests/responses/errors not directly related to their function. I think this could also serve as a BCP-like document listing how these issues should be resolved to maximize interoperability. Bill Marshall wtm@research.att.com -----original message----- From: "Mary Barnes" To: "'William Marshall'" , dean.willis@softarmor.com Cc: Juan-Carlos.Rojas@alcatel.fr, sip@ietf.org Subject: RE: [Sip] B2BUA Date: Tue, 3 Dec 2002 07:35:26 -0600 Bill et al, My comments are embedded below [MB]: -----Original Message----- From: William Marshall [mailto:wtm@research.att.com] Sent: Tuesday, December 03, 2002 7:29 AM To: dean.willis@softarmor.com Cc: Barnes, Mary [NGC:B602:EXCH]; Juan-Carlos.Rojas@alcatel.fr; sip@ietf.org Subject: RE: [Sip] B2BUA Dean wrote: > I think that Bill is suggesting that there is also something BETWEEN the > B2BUA and the conformant proxy, and that the world would be a better > place (ok, maybe not THAT much better) if our taxonomy also included > this "between" thing. To further elaborate, there certainly exists on paper a box that does some abritrary and weird algorithm, not conformant with any of the rules in rfc3261, that transforms requests and response and breaks everything that goes through it. Call it "Dean's devilish-B2BUA". But I don't think anyone builds such a box. At least not intentionally. What is built instead are boxes that are close to the definition of proxies, but not quite. They serve a real need in the market (and vendors tend to build what sells). But due to various details, like looking at the attachment (a proxy-no-no) to open pinholes in the firewall, they don't strictly qualify as proxies. [MB]: And I think this is where we get into problems trying to agree what defines this in-between thing, as everyone has something that is likely slightly different. Saying there are only two types of boxes, proxies and devilish-B2BUAs, ignores the reality. The writing of an accurate definition of a B2BUA is only the first step. Unfortunately there is interaction with definition of new services. The definition of proxy is very restrictive for a reason, so that it leaves wide open the possibilities for designs of new services. But the not-quite-proxy boxes will exist, and endpoints will need to interoperate with them. So services will also need to work through them. This will impose some restrictions on how new services are defined. I think the objective should be to minimize those restrictions; to do that the variations in not-quite-proxy behavior need to be documented and made predictable so that services can be defined to interwork with them. [MB]: Well, perhaps the most reasonable way forward would be to put together an informational draft defining the various "flavors" of these in-between things and categorizing the issues for service interworking introduced by each of the variations. Some of this, of course, will lead us back to the list of the reasons why some folks consider these things "evil", but would this also not lead us down the road of being very prescriptive about how services work in SIP? Having services work through the "something BETWEEN the B2BUA and the conformant proxy" would certainly make the world a much better place (yes, THAT much better). Bill Marshall wtm@research.att.com -----original message----- From: "Dean Willis" To: "'Mary Barnes'" , Cc: Subject: RE: [Sip] B2BUA Date: Tue, 3 Dec 2002 00:00:19 -0600 Mary said: ----- So, I guess you're suggesting that the term "concatenation" is not accurate or is misleading and I guess that depends upon how loosely one applies the term concatenation here; my assumption had been that it meant that they were "linked" (consistent with Webster's definition of concatenate) in some manner which is unprescribed, so I think your point 2 below isn't a problem with the current definition. My understanding of the current definition is that there isn't anything more for the SIP protocol to prescribe about the operation of a B2BUA other than what is required from a protocol perspective to function as a UAC and a UAS. >From a protocol perspective, it is a logical entity and thus whether there's one or multiple doesn't seem to apply. I think what you (and perhaps others) are suggesting is that there's a definition of a B2BUA that more closely parallels the definition of a Proxy Server since in many cases the physical rendition of the logical B2BUA functionality would be replacing a Proxy Server in a network. And I think this is where the problem begins, as many are opposed to this model (as it increases the complexity, etc.) and this is why the logical definition has remained. ------ Well, I think the argument is being made that this definition doesn't (for some reason that I seem incapable of comprehending) work for some people, and that therefore we should clarify it. At the fundamental level, I think some people do not find the implications of this definition obvious. There are several ways we might address this. We might add examples. We might add "In other words, the only relationship between the UAC and the UAS is the application logic, and that can do anything that one can imagine an application doing", or we might just use better wording. I don't think the argument is being made that the definition in 3261 is wrong, just that we can make it better for those who don't get it the way it is written. Of course, if we discuss it here long enough, maybe most of them WILL get it -- but that doesn't help the ones who aren't "here" yet. I think that Bill is suggesting that there is also something BETWEEN the B2BUA and the conformant proxy, and that the world would be a better place (ok, maybe not THAT much better) if our taxonomy also included this "between" thing. -- 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 mailnull@www1.ietf.org Tue Dec 3 08:53:15 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19777 for ; Tue, 3 Dec 2002 08:53:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB3Dtak09415 for sip-archive@odin.ietf.org; Tue, 3 Dec 2002 08:55:36 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3DtEv09395; Tue, 3 Dec 2002 08:55:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3Ds4v09296 for ; Tue, 3 Dec 2002 08:54:04 -0500 Received: from avgw.vxserver.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA19683 for ; Tue, 3 Dec 2002 08:51:11 -0500 (EST) Received: from disney.internal.ridgewaysystems.com ([194.128.67.181]) by avgw.vxserver.com (NAVGW 2.5.2.12) with SMTP id M2002120313524728566 ; Tue, 03 Dec 2002 13:52:47 GMT Received: from Unknown [10.1.1.1] by disney.internal.ridgewaysystems.com - SurfControl E-mail Filter (4.5); Tuesday, 03 December 2002, 13:54:22 Received: by ridgeway.internal.ridgewaysystems.com with Internet Mail Service (5.5.2653.19) id ; Tue, 3 Dec 2002 13:53:59 -0000 Message-ID: <00533D13955AD411AF3800A0C9B4263994D87A@ridgeway.internal.ridgewaysystems.com> From: Phil Reynolds To: "'sip@ietf.org'" Cc: "'Mary Barnes'" Date: Tue, 3 Dec 2002 13:53:56 -0000 Subject: RE: [Sip] B2BUA MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--=_NextPart_ST_13_54_22_Tuesday_December_03_2002_30999" X-Mailer: Internet Mail Service (5.5.2653.19) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , 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_ST_13_54_22_Tuesday_December_03_2002_30999 Content-Type: text/plain The trouble with that is that the RFC stipulates the way these intermediaries work and unless your intermediaries work in that way, you cant put "CONFORMS TO RFCxyz" on the box and hence the spec is stifling my creativity (and more importantly my marketability). The spec should stick to defining the "on wire" protocols and let us "creative types" come up with imaginative ways to subvert them :-) -----Original Message----- From: Mary Barnes [mailto:mbarnes@nortelnetworks.com] Sent: 03 December 2002 13:20 To: 'Phil Reynolds' Subject: RE: [Sip] B2BUA Phil, I do see both sides of this debate, but I've yet to see it come to a resolution to which everyone can agree, as everyone has built something that's slightly different (and yes our marketing folks want each of ours to be the best of such different things). Realistically, building anything beyond a basic proxy is a tradeoff between desired (and many believe required) functionality versus the complexity and the potential for interworking problems. I think it's the fundamental problem that the IETF doesn't define architectures, but rather protocols. However, to define the protocols, you must define some architectural elements to set the context and that's where the problems begin, as everyone's implementation of the architectural elements is always different because the specs don't provide enough detail. So, perhaps the best way around this is to leave the basic SIP spec as is and write an informational RFC defining the various flavors of entities "Beyond SIP Proxys" and "Towards B2BUAs" so that we can give our marketing folks a pointer to a document that describes at some level the "flavor" of system we provide. I say this rather facetiously, but realistically, it might be the most effective way to resolve this problem and end this long debates. Regards, Mary. -----Original Message----- From: Phil Reynolds [mailto:preynolds@ridgewaysystems.com] Sent: Tuesday, December 03, 2002 4:05 AM To: Barnes, Mary [NGC:B602:EXCH] Subject: RE: [Sip] B2BUA The problem as I see it is that the RFC defines 2 distinct intermediary entities a "SIP Proxy" which has limited functionality, i.e. it is not allowed to modify the body of the message, and a B2BUA which is a full blown pair of Uas with all the transactional and dialogue stuff. What we build is something in the middle... We rely on the "real" UAs to do all the transactions, retries dialogs etc, and we modify the messages and SDP bodies as they go through. Personally I don't care what the spec says. We build a system that does a useful function, if it doesn't fit into a category that is defined by the spec -- so what? However the marketing types don't quite see it that way ;-) If the spec is going to define the permissible intermediaries, it SHOULD allow for things that are not implemented as UAs but externally appear to be so. -----Original Message----- From: Mary Barnes [mailto:mbarnes@nortelnetworks.com ] Sent: 02 December 2002 16:54 To: 'Phil Reynolds'; sip@ietf.org Subject: RE: [Sip] B2BUA Hi all, I guess I have to ask, what's the problem with the definition in RFC 3261? ----=_NextPart_ST_13_54_22_Tuesday_December_03_2002_30999 Content-Type: text/html Message
The trouble with that is that the RFC stipulates the way these intermediaries work and unless your intermediaries work in that way, you cant put "CONFORMS TO RFCxyz" on the box and hence the spec is stifling my creativity (and more importantly my marketability).
 
The spec should stick to defining the "on wire" protocols and let us "creative types" come up with imaginative ways to subvert them :-)
-----Original Message-----
From: Mary Barnes [mailto:mbarnes@nortelnetworks.com]
Sent: 03 December 2002 13:20
To: 'Phil Reynolds'
Subject: RE: [Sip] B2BUA

Phil,
 
I do see both sides of this debate, but I've yet to see it come to a resolution to which everyone can agree, as everyone has built something that's slightly different (and yes our marketing folks want each of ours to be the best of such different things). Realistically, building anything beyond a basic proxy is a tradeoff between desired (and many believe required) functionality versus the complexity and the potential for interworking problems. I think it's the fundamental problem that the IETF doesn't define architectures, but rather protocols.  However, to define the protocols, you must define some architectural elements to set the context and that's where the problems begin, as everyone's implementation of the architectural elements is always different because the specs don't provide enough detail.
 
So, perhaps the best way around this is to leave the basic SIP spec as is and write an informational RFC defining the various flavors of entities "Beyond SIP Proxys"  and "Towards B2BUAs" so that we can give our marketing folks a pointer to a document that describes at some level the "flavor" of system we provide.  I say this rather facetiously, but realistically, it might be the most effective way to resolve this problem and end this long debates.
 
Regards,
Mary.
 
 
 -----Original Message-----
From: Phil Reynolds [mailto:preynolds@ridgewaysystems.com]
Sent: Tuesday, December 03, 2002 4:05 AM
To: Barnes, Mary [NGC:B602:EXCH]
Subject: RE: [Sip] B2BUA

The problem as I see it is that the RFC defines 2 distinct intermediary entities a "SIP Proxy" which has limited functionality, i.e. it is not allowed to modify the body of the message, and a B2BUA which is a full blown pair of Uas with all the transactional and dialogue stuff.

What we build is something in the middle... We rely on the "real" UAs to do all the transactions, retries dialogs etc, and we modify the messages and SDP bodies as they go through.

Personally I don't care what the spec says. We build a system that does a useful function, if it doesn't fit into a category that is defined by the spec -- so what? However the marketing types don't quite see it that way ;-)

If the spec is going to define the permissible intermediaries, it SHOULD allow for things that are not implemented as UAs but externally appear to be so.

-----Original Message-----
From: Mary Barnes [mailto:mbarnes@nortelnetworks.com]
Sent: 02 December 2002 16:54
To: 'Phil Reynolds'; sip@ietf.org
Subject: RE: [Sip] B2BUA


Hi all,

I guess I have to ask, what's the problem with the definition in RFC 3261?

----=_NextPart_ST_13_54_22_Tuesday_December_03_2002_30999-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Tue Dec 3 09:35:41 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22144 for ; Tue, 3 Dec 2002 09:35:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB3Ec3E05484 for sip-archive@odin.ietf.org; Tue, 3 Dec 2002 09:38:03 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3Eavv24908; Tue, 3 Dec 2002 09:36:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3EZsv12142 for ; Tue, 3 Dec 2002 09:35:54 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21993 for ; Tue, 3 Dec 2002 09:33:00 -0500 (EST) From: aki.niemi@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gB3EZBG14363 for ; Tue, 3 Dec 2002 16:35:11 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 3 Dec 2002 16:35:48 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 3 Dec 2002 16:35:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] B2BUA Date: Tue, 3 Dec 2002 16:35:48 +0200 Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9019450B8@esebe013.ntc.nokia.com> Thread-Topic: [Sip] B2BUA Thread-Index: AcKaLQEyS9QVc6VBT7qXaibD6unfcwAqJ0ew To: , Cc: X-OriginalArrivalTime: 03 Dec 2002 14:35:48.0943 (UTC) FILETIME=[45CCDDF0:01C29AD9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gB3EZsv12148 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi, I agree with Mary that concatenation is the right word for it. But the source of confusion is probably this: UA = UAC + UAS B2BUA = UA | UA => B2BUA = (UAC + UAS) | (UAC + UAS) So the B2BUA is a concatenation of two User Agents, each of which acts both as UAC and UAS. A conference server will probably look like a UA, definitely not a B2BUA, IMHO. Cheers, Aki -----Original Message----- From: ext Mary Barnes [mailto:mbarnes@nortelnetworks.com] Sent: Monday, December 02, 2002 7:47 PM To: 'Juan-Carlos.Rojas@alcatel.fr' Cc: sip@ietf.org Subject: RE: [Sip] B2BUA Juan-Carlos, So, I guess you're suggesting that the term "concatenation" is not accurate or is misleading and I guess that depends upon how loosely one applies the term concatenation here; my assumption had been that it meant that they were "linked" (consistent with Webster's definition of concatenate) in some manner which is unprescribed, so I think your point 2 below isn't a problem with the current definition. My understanding of the current definition is that there isn't anything more for the SIP protocol to prescribe about the operation of a B2BUA other than what is required from a protocol perspective to function as a UAC and a UAS. From a protocol perspective, it is a logical entity and thus whether there's one or multiple doesn't seem to apply. I think what you (and perhaps others) are suggesting is that there's a definition of a B2BUA that more closely parallels the definition of a Proxy Server since in many cases the physical rendition of the logical B2BUA functionality would! be replacing a Proxy Server in a network. And I think this is where the problem begins, as many are opposed to this model (as it increases the complexity, etc.) and this is why the logical definition has remained. On your first point, however, I think we need to wait until the conferencing work in SIPPING is more complete before we can suggest that a conference server would be a B2BUA. Mary. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Tue Dec 3 09:36:51 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22238 for ; Tue, 3 Dec 2002 09:36:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB3EdC318763 for sip-archive@odin.ietf.org; Tue, 3 Dec 2002 09:39:12 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3Ec8v06264; Tue, 3 Dec 2002 09:38:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3Eaav20917 for ; Tue, 3 Dec 2002 09:36:36 -0500 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22022 for ; Tue, 3 Dec 2002 09:33:44 -0500 (EST) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id gB369Ycb029818 for ; Mon, 2 Dec 2002 22:09:34 -0800 (PST) Received: from cj14 (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-9.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with SMTP id DVA00062; Mon, 2 Dec 2002 22:09:56 -0800 (PST) From: "Cullen Jennings" To: Subject: RE: [Sip] B2BUA Date: Mon, 2 Dec 2002 22:12:17 -0800 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.2911.0) In-Reply-To: <200212021959.OAA53813@fish.research.att.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit One problem is that people often want a definition of what a B2BUA can or can not do. It is not clear that it is possible to define a SIP speaking systems this way. What function can a proxy provide? Well just about anything as long as the responses it sends are compliant with the constraints of a thing called a proxy in 3261. How a proxy determines the next hop for an requested targeted to it is completely up to the proxy and not specified in SIP. We run into the same problem with defining what can a B2BUA do. The answer is, well lots of things. It can handle multiple different dialogs at the same time and the message sent on each dialogs will meet the constraints of a what 3261 calls a UA. How the message on one dialog relate to the message on another dialog is completely up to the B2BUA and not specified in SIP. I recognize this is not a very satisfactory way to help people understand B2BUA so I have a proposal. Trying to have an all encompassing functional definition of a B2BUA is very hard. However, it is possible to have call flows that show some common application of B2BUA. Perhaps even form some sub classification of a B2BUA that specify how a given class of B2B will interact with messages. If you think about it, this is similar to the SIP to QSIG mapping. We say how messages on one side will get mapped to message on the other side. It's not a normative part of SIP. I think a few folks are already working on this - perhaps we will get a whole taxonomy of different variants of the B2BUA beast. Cullen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Tue Dec 3 10:07:51 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24432 for ; Tue, 3 Dec 2002 10:07:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB3FADc16177 for sip-archive@odin.ietf.org; Tue, 3 Dec 2002 10:10:13 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3F96v16101; Tue, 3 Dec 2002 10:09:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3F7Sv15996 for ; Tue, 3 Dec 2002 10:07:28 -0500 Received: from mailserv.intranet.gr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24255 for ; Tue, 3 Dec 2002 10:04:31 -0500 (EST) Received: from mailserv.intranet.gr (localhost [127.0.0.1]) by mailserv.intranet.gr (8.11.3/8.11.3) with ESMTP id gB3F8dH19940 for ; Tue, 3 Dec 2002 17:08:39 +0200 (EET) Received: from hal.intranet.gr (hal.intranet.GR [146.124.2.254]) by mailserv.intranet.gr (8.11.3/8.11.3) with ESMTP id gB3F8cm19935; Tue, 3 Dec 2002 17:08:38 +0200 (EET) Received: from dpd_ssal (pcdpd120 [146.124.2.235]) by hal.intranet.gr (8.10.2+Sun/8.10.2) with SMTP id gB3ExrH16214; Tue, 3 Dec 2002 16:59:54 +0200 (EET) From: "F.S.Salloum" To: , "Peterson, Jon" Cc: Subject: RE: SIPS related clarifications (was: [Sip] SIPS question) Date: Tue, 3 Dec 2002 17:12:03 +0200 Keywords: IETF 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.2911.0) Importance: Normal In-Reply-To: <65256C84.00372915.00@sampark.hss.hns.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dear all, >Lets say that the request-uri does not contain >"sips:" but the request was received on TLS (perhaps >because of a Route header configured with a previous >hop). Can the proxy send it downstream on a non-TLS >protocol if there are no more Route headers present >in the message? > >From your mail, I gather this is allowed. I believe that the difference between sip over TLS and sips over TLS is the following Using sip: over TLS the UA that sends the requests over TLS to a proxy server has no assurance that TLS will be used end-to-end (RFC3261:pp238) Using sips: over TLS the SIPS scheme signifies that each hop over which the request is forwarded, until the request reaches the SIP entity responsible for the domain portion of the Request URI must be secured with TLS; once it reaches the domain in question it is handled in accordance with local security and routing policy, quite possibly using TLS for any last hop to a UAS. (RFC3261:pp238) >> while Rosenberg had mentioned that the presence >> of "sips:" should imply that the end-to-end path is >> secure. > > If SIPS appears in the Request-URI of the original > request sent by the UAC, it implies this end-to-end > path security. In this case end-to-end actually referes the UAC and the first entity in the domain in question then it depends on the local security and routing policy of that domain. >> I guess the way I understand the spec stands >> at present is that if the Req-URI is re-written to a >> "sips:" URL at any stage of the routing, then any hop >> downstream _from_this_hop_onwards_ has to forward the >> request on TLS. > > I agree, that is how we should understand it - with the > caveat that SIPS only applies to the entire path until > it reaches the domain indicated by the hostname portion > of the Request-URI. Once a proxy server in the destination > gets hold of the request, it can retarget it arbitrarily > (to non-SIPS resources, if it wishes). Aren't the 2 texts quoted by you at opposite ends? a) the UAS cannot be sure of end-to-end security if it received a INVITE with the request-URI as "sips:" ... Some hop in the middle could have modified the req-URI for "sips:". It may even be the proxy with whom the UAS registered with the Contact as "sips:" ? The UAS by parsing the sips is sure that security exist between the previous hop and him. The UAC initiator is the only one sure for end-to-end security (till the domain etc) because he has initiated a session using sips: b) (If the caveat that you mentioned holds) the UAC cannot be sure that the UAS received the request on TLS. Shouldn't the destination's proxy be disallowed to route a request received on TLS to a non-TLS client? I believe that end-to-end security is reffered between the UAC and the first entity in the domain in question and not the final UAS this depends on routing and local security policy. For example the edge proxy may connect with the UAs or the final UAC using IPSec since maybe the UAs have a pre-shared kwying relationship with their first-hop proxy server. The sure thing is that when something is sent with sips then the sender is sure that it will be sent securely till the referenced domain ... if a UA receives something with sips it is sure that has been sent securely from the previous hop... Regards F.S.Salloum _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Tue Dec 3 10:13:56 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24901 for ; Tue, 3 Dec 2002 10:13:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB3FGIL16583 for sip-archive@odin.ietf.org; Tue, 3 Dec 2002 10:16:18 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3F2Kv15077; Tue, 3 Dec 2002 10:02:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3F1Vv14877 for ; Tue, 3 Dec 2002 10:01:31 -0500 Received: from kcmso2.proxy.att.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23803 for ; Tue, 3 Dec 2002 09:58:38 -0500 (EST) Received: from attrh3i.attrh.att.com ([135.71.62.12]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id gB3EvaAL027882 for ; Tue, 3 Dec 2002 09:01:18 -0600 (CST) Received: from occlust04evs1.ugd.att.com (135.71.164.12) by attrh3i.attrh.att.com (6.5.019) id 3DDD63A1004F0332; Tue, 3 Dec 2002 10:00:50 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: [Sip] B2BUA Date: Tue, 3 Dec 2002 10:00:50 -0500 Message-ID: <62DA45D4963FA747BA1B253E266760F904D2B63A@OCCLUST04EVS1.ugd.att.com> Thread-Topic: [Sip] B2BUA Thread-Index: AcKa2CTWNige0Z+iRRillY17COqpmQAA9kuw From: "Roy, Radhika R, ALASO" To: Cc: , , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gB3F1Vv14878 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Mary wrote: > [MB]: Some of this, of course, will lead us back to the > list of the reasons why some folks consider these things "evil", ... I do not remember whether anyone has ever said that B2BUA is evil things. What I remember is that the dumping of the B2BUA functionality in the name of SIP Proxy is an evil thing. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Tue Dec 3 10:37:27 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27055 for ; Tue, 3 Dec 2002 10:37:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB3FdoE19194 for sip-archive@odin.ietf.org; Tue, 3 Dec 2002 10:39:50 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3FHMv16646; Tue, 3 Dec 2002 10:17:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3FGRv16597 for ; Tue, 3 Dec 2002 10:16:27 -0500 Received: from mailserv.intranet.gr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24880 for ; Tue, 3 Dec 2002 10:13:28 -0500 (EST) Received: from mailserv.intranet.gr (localhost [127.0.0.1]) by mailserv.intranet.gr (8.11.3/8.11.3) with ESMTP id gB3FHbH21670 for ; Tue, 3 Dec 2002 17:17:37 +0200 (EET) Received: from hal.intranet.gr (hal.intranet.GR [146.124.2.254]) by mailserv.intranet.gr (8.11.3/8.11.3) with ESMTP id gB3FHam21664 for ; Tue, 3 Dec 2002 17:17:37 +0200 (EET) Received: from dpd_ssal (pcdpd120 [146.124.2.235]) by hal.intranet.gr (8.10.2+Sun/8.10.2) with SMTP id gB3F8rH16426 for ; Tue, 3 Dec 2002 17:08:53 +0200 (EET) From: "F.S.Salloum" To: "Sip@Ietf. Org" Date: Tue, 3 Dec 2002 17:21:04 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1253" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Content-Transfer-Encoding: 7bit Subject: [Sip] Missing TLS? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dear All, On page RFC 3261/pp151 on comment (1) I think its missing an TLS, it should be changed from "The default is 5061 for sip: using TLS over TCP and sips: over TCP." To "The default is 5061 for sip: using TLS over TCP and sips: TLS over TCP." Regards F.S.Salloum _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Tue Dec 3 11:32:57 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01198 for ; Tue, 3 Dec 2002 11:32:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB3GZIw23803 for sip-archive@odin.ietf.org; Tue, 3 Dec 2002 11:35:18 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3GVDv23594; Tue, 3 Dec 2002 11:31:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3GTLv23486 for ; Tue, 3 Dec 2002 11:29:21 -0500 Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00844 for ; Tue, 3 Dec 2002 11:26:29 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA09454; Tue, 3 Dec 2002 11:29:15 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA20182; Tue, 3 Dec 2002 11:29:16 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 3 Dec 2002 11:29:16 -0500 Message-ID: <313680C9A886D511A06000204840E1CF030B5BB3@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'aki.niemi@nokia.com'" Cc: sip@ietf.org Subject: RE: [Sip] B2BUA Date: Tue, 3 Dec 2002 11:29:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , > So the B2BUA is a concatenation of two User Agents, each of > which acts both as UAC and UAS. A conference server will > probably look like a UA, definitely not a B2BUA, IMHO. > This thread is, hopefully reaching an end (with an agreement to do some examples with call flows). However, the above statement is yet one more example of the confusion people have with B2BUA. The key thing about a B2BUA is that it looks like a UA to whatever it is connected to (on both sides). So, a conference server looks like a UA to each of it's ports, and it has at least two of them, and there is some "magic" between them. If you look at the concept of the "focus" from the conferencing work, it is a thing that has a bunch of two ended SIP calls, one with each participant. Each participant thinks it is talking to a UA. While some messages sent from a participant to a UA might be consumed by the UA (state changes), often, a message will trigger messages from the focus to other participants. This seems, to me, to meet the definition of B2BUA in 3261, and more strongly meets proposed changes in the definition. Of course, it really doesn't matter if you consider the focus to be a B2BUA or not. Brian _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Tue Dec 3 11:39:09 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01596 for ; Tue, 3 Dec 2002 11:39:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB3GfUw24923 for sip-archive@odin.ietf.org; Tue, 3 Dec 2002 11:41:30 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3GaCv23893; Tue, 3 Dec 2002 11:36:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3GZhv23830 for ; Tue, 3 Dec 2002 11:35:43 -0500 Received: from mail4.microsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01190 for ; Tue, 3 Dec 2002 11:32:50 -0500 (EST) Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Tue, 3 Dec 2002 08:35:38 -0800 Received: from 157.54.8.155 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 03 Dec 2002 08:35:37 -0800 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Tue, 3 Dec 2002 08:35:37 -0800 Received: from WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Tue, 3 Dec 2002 08:35:37 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3710.0); Tue, 3 Dec 2002 08:35:28 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Sip] B2BUA Date: Tue, 3 Dec 2002 08:35:28 -0800 Message-ID: Thread-Topic: [Sip] B2BUA Thread-Index: AcKa2CTWNige0Z+iRRillY17COqpmQAA9kuwAANPtzA= From: "Christian Huitema" To: "Roy, Radhika R, ALASO" , Cc: , , X-OriginalArrivalTime: 03 Dec 2002 16:35:28.0140 (UTC) FILETIME=[FCEF64C0:01C29AE9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gB3GZhv23831 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit > > [MB]: Some of this, of course, will lead us back to the > > list of the reasons why some folks consider these things "evil", ... > > I do not remember whether anyone has ever said that B2BUA is evil > things. What I remember is that the dumping of the B2BUA functionality > in the name of SIP Proxy is an evil thing. The real issue in all this is security. Many security folks believe that, in order to get proper security, the body of the signaling messages should be signed, and possibly encrypted. In that logic, the proxies only manipulate the information exposed in the SIP header, which can be as little as the pair of source and destination URL. Any intermediary that attempts to "rewrite the SDP" has to somehow insert itself in the end-to-end security exchange; many security folks will resent that as "breaking end-to-end security". Insofar as SDP rewriting attempts to provide a legitimate service, the challenge is thus to provide the service in such a way that it does not require breaking end-to-end encryption. -- Christian Huitema _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Tue Dec 3 11:55:08 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02575 for ; Tue, 3 Dec 2002 11:55:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB3GvTl26082 for sip-archive@odin.ietf.org; Tue, 3 Dec 2002 11:57:29 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3GaFv23924; Tue, 3 Dec 2002 11:36:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3GZlv23836 for ; Tue, 3 Dec 2002 11:35:47 -0500 Received: from dyn-tx-arch-crash.dfw.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01193 for ; Tue, 3 Dec 2002 11:32:55 -0500 (EST) Received: from RjS.localdomain (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id gB3GZgI03578 for ; Tue, 3 Dec 2002 10:35:42 -0600 From: Robert Sparks To: sip@ietf.org Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 03 Dec 2002 10:35:01 -0600 Message-Id: <1038933302.911.62.camel@RjS.localdomain> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: [Sip] Constructing the branch parameter at stateless proxies Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit This list has seen a couple of requests to clarify the language in RFC 3261 concerning how a stateless proxy creates a branch identifier. The current text requires uniqueness, dependency on route decision affecting parameters and care to be sure that those parameters are retransmission invariant. It goes on to recommend a hash over a set of fields (this set has been the subject of the requests for clarification). I think there's a much simpler solution. The purpose of this branch parameter is to act as a transaction identifier. Who cares about this identifier? Only the stateful elements at each end of the transaction. Any stateless proxies between these elements don't use that identifier in any of their decisions, so I assert that it is not useful to change it as it crosses the stateless proxy. I propose, then, that a stateless proxy simply copy the branch parameter from the topmost Via header field value it receives into the Via header field value it adds to the request. I don't believe it matters that this parameter contain the magic cookie. If it doesn't, the next stateful hop will use the 2543-style transaction identifiers provided by the sending stateful element. The stateless elements are by definition transaction transparent. So - can anyone construct a scenario where this doesn't function correctly? If not, we can remove several convoluted paragraphs from the spec and replace them with a very simple couple of sentences. 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 mailnull@www1.ietf.org Tue Dec 3 12:13:16 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03649 for ; Tue, 3 Dec 2002 12:13:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB3HFcx28333 for sip-archive@odin.ietf.org; Tue, 3 Dec 2002 12:15:38 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3HDpv28185; Tue, 3 Dec 2002 12:13:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3HCqv28126 for ; Tue, 3 Dec 2002 12:12:52 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03488 for ; Tue, 3 Dec 2002 12:09:54 -0500 (EST) From: aki.niemi@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gB3HC4G17143 for ; Tue, 3 Dec 2002 19:12:04 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 3 Dec 2002 19:12:41 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 3 Dec 2002 19:12:41 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] B2BUA Date: Tue, 3 Dec 2002 19:12:41 +0200 Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9019450BC@esebe013.ntc.nokia.com> Thread-Topic: [Sip] B2BUA Thread-Index: AcKa6SLC3UqWHaKATDK/Xs6eTZEKygAAH21A To: Cc: X-OriginalArrivalTime: 03 Dec 2002 17:12:41.0470 (UTC) FILETIME=[301A81E0:01C29AEF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gB3HCqv28127 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Inline. > The key thing about a B2BUA is that it looks like a UA to whatever > it is connected to (on both sides). So, a conference server > looks like a UA to each of it's ports, and it has at least two of > them, and there is some "magic" between them. If you look at the > concept of the "focus" from the conferencing work, it is a > thing that has a bunch of two ended SIP calls, one with each > participant. Each participant thinks it is talking to a UA. > While some messages sent from a participant to a UA might be > consumed by the UA (state changes), often, a message will trigger > messages from the focus to other participants. This just generalized the B2BUA to cover any normal UA behavior. Example, I get a MESSAGE from a friend to my UA, based on which decide to call another friend by sending an INVITE from that UA. This I think is quite normal UA operation, the "magic" being me via my UI. > This seems, to me, to meet the definition of B2BUA in 3261, > and more strongly meets proposed changes in the definition. > Of course, it really doesn't matter if you consider the focus to > be a B2BUA or not. Hmm... Let's think of the B2BUA as 'in-UA' concatenated with 'out-UA'. By definition: 1) in-UAS receives request, 2) out-UAC sends request' 3) out-UAC receives response' 4) in-UAS sends response (The same process happens with requests going from 'out' to 'in') Within this B2BUA, 'in-UAS' shares magic with 'out-UAC', and 'in-UAC' shares magic with 'out-UAS'. However, if (as you state above), 4) follows immediately after 1), it's no longer a B2BUA, but a plain old UA, IMHO. Cheers, Aki _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Tue Dec 3 12:18:49 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04110 for ; Tue, 3 Dec 2002 12:18:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB3HLBH28961 for sip-archive@odin.ietf.org; Tue, 3 Dec 2002 12:21:11 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3HJAv28792; Tue, 3 Dec 2002 12:19:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3HIQv28700 for ; Tue, 3 Dec 2002 12:18:26 -0500 Received: from smail3.alcatel.fr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03890 for ; Tue, 3 Dec 2002 12:15:33 -0500 (EST) From: Juan-Carlos.Rojas@alcatel.fr Received: from frmail25.netfr.alcatel.fr (frmail25.netfr.alcatel.fr [155.132.182.155]) by smail3.alcatel.fr (ALCANET/NETFR) with ESMTP id gB3HIKek007734; Tue, 3 Dec 2002 18:18:21 +0100 Subject: RE: [Sip] B2BUA To: "Dean Willis" Cc: Date: Tue, 3 Dec 2002 18:18:19 +0100 Message-ID: X-MIMETrack: Serialize by Router on FRMAIL25/FR/ALCATEL(Release 5.0.8 |June 18, 2001) at 12/03/2002 18:18:20 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gB3HIQv28701 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Dean, I fully agree with you. I've never said that the definition in 3261 is wrong, just that it could be completed (or improved, etc.) to avoid confusion. After reading the mails in this discusion thread, what could be added is that: 1) A B2BUA handles two or more UAs (each one behaving as UAC/UAS, as described in 3261 for UAs) 2) The SIP protocol specification does not mandate for any behaviour of such B2BUA, i.e. on how to "link" (or "concatenate") two or more UAs. As a consequence, you cannot standardise the behaviour of a B2BUA, since a B2BUA is an application "and that can do anything that one can imagine an application doing". But you can still standardise an application or a class of applications that behave as B2BUA. These applications exhibit a UA behaviour for each concerned UA, according to SIP rules defined in 3261. But this is yet another story. Best regards Juan Carlos P.S.: The "something BETWEEN the B2BUA and the conformant proxy" story should be handled in a separate discusion thread, to avoid to mix all problems in the same thread. "Dean Willis" @ietf.org on 03/12/2002 07:00:19 Sent by: sip-admin@ietf.org To: "'Mary Barnes'" , Juan-Carlos ROJAS/FR/ALCATEL@ALCATEL cc: Subject: RE: [Sip] B2BUA Mary said:  -----  So, I guess you're suggesting that the term "concatenation" is not accurate or is misleading and I guess that depends upon how loosely one applies the term concatenation here; my assumption had been that it meant that they were "linked" (consistent with Webster's definition of concatenate) in some manner which is unprescribed, so I think your point 2 below isn't a problem with the current definition.  My understanding of the current definition is that there isn't anything more for the SIP protocol to prescribe about the operation of a B2BUA other than what is required from a protocol perspective to function as a UAC and a UAS. From a protocol perspective, it is a logical entity and thus whether there's one or multiple doesn't seem to apply.  I think what you (and perhaps others) are suggesting is that there's a definition of a B2BUA that more closely parallels the definition of a Proxy Server since in many cases the physical rendition of the logical B2BUA functionality would be replacing a Proxy Server in a network. And I think this is where the problem begins, as many are opposed to this model (as it increases the complexity, etc.) and this is why the logical definition has remained. ------ Well, I think the argument is being made that this definition doesn't (for some reason that I seem incapable of comprehending) work for some people, and that therefore we should clarify it. At the fundamental level, I think some people do not find the implications of this definition obvious. There are several ways we might address this. We might add examples. We might add "In other words, the only relationship between the UAC and the UAS is the application logic, and that can do anything that one can imagine an application doing", or we might just use better wording. I don't think the argument is being made that the definition in 3261 is wrong, just that we can make it better for those who don't get it the way it is written. Of course, if we discuss it here long enough, maybe most of them WILL get it -- but that doesn't help the ones who aren't "here" yet. I think that Bill is suggesting that there is also something BETWEEN the B2BUA and the conformant proxy, and that the world would be a better place (ok, maybe not THAT much better) if our taxonomy also included this "between" thing. -- 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 mailnull@www1.ietf.org Tue Dec 3 12:50:39 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06024 for ; Tue, 3 Dec 2002 12:50:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB3Hr1n31626 for sip-archive@odin.ietf.org; Tue, 3 Dec 2002 12:53:01 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3HUVv29531; Tue, 3 Dec 2002 12:30:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3HTtv29463 for ; Tue, 3 Dec 2002 12:29:55 -0500 Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04582 for ; Tue, 3 Dec 2002 12:27:02 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA14329; Tue, 3 Dec 2002 12:29:49 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA05212; Tue, 3 Dec 2002 12:29:49 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 3 Dec 2002 12:29:48 -0500 Message-ID: <313680C9A886D511A06000204840E1CF030B5BB4@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'aki.niemi@nokia.com'" Cc: sip@ietf.org Subject: RE: [Sip] B2BUA Date: Tue, 3 Dec 2002 12:29:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Of course these things are never so simple. On an "end system mixed" conference, an INVITE from a new participant triggers Re-INVITES to existing participants. Depending on details, a focus could hold the response from the INVITE of the new participant until it receives responses from all existing participants (new CODEC negotiation for example). That meets your definition of B2BUA. On the other hand, a centrally mixed conference would not normally trigger Re-INVITES. Does that mean that an end-system mixed focus is a B2BUA but a centrally mixed focus is not? Hard to differentiate. With both of them, a state change, signaled by, say a NOTIFY from one to the focus triggers NOTIFIES to (possibly a subset of) the other participants, so that would meet the definition. Would you call that a change in roles? Brian > -----Original Message----- > From: aki.niemi@nokia.com [mailto:aki.niemi@nokia.com] > Sent: Tuesday, December 03, 2002 12:13 PM > To: Brian.Rosen@marconi.com > Cc: sip@ietf.org > Subject: RE: [Sip] B2BUA > > > Inline. > > > The key thing about a B2BUA is that it looks like a UA to whatever > > it is connected to (on both sides). So, a conference server > > looks like a UA to each of it's ports, and it has at least two of > > them, and there is some "magic" between them. If you look at the > > concept of the "focus" from the conferencing work, it is a > > thing that has a bunch of two ended SIP calls, one with each > > participant. Each participant thinks it is talking to a UA. > > While some messages sent from a participant to a UA might be > > consumed by the UA (state changes), often, a message will trigger > > messages from the focus to other participants. > > This just generalized the B2BUA to cover any normal UA > behavior. Example, I get a MESSAGE from a friend to my UA, > based on which decide to call another friend by sending an > INVITE from that UA. This I think is quite normal UA > operation, the "magic" being me via my UI. > > > This seems, to me, to meet the definition of B2BUA in 3261, > > and more strongly meets proposed changes in the definition. > > Of course, it really doesn't matter if you consider the focus to > > be a B2BUA or not. > > Hmm... Let's think of the B2BUA as 'in-UA' concatenated with > 'out-UA'. By definition: > > 1) in-UAS receives request, > > 2) out-UAC sends request' > 3) out-UAC receives response' > > 4) in-UAS sends response > > (The same process happens with requests going from 'out' to 'in') > > Within this B2BUA, 'in-UAS' shares magic with 'out-UAC', and > 'in-UAC' shares magic with 'out-UAS'. However, if (as you > state above), 4) follows immediately after 1), it's no longer > a B2BUA, but a plain old UA, IMHO. > > Cheers, > Aki > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Tue Dec 3 13:25:02 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08087 for ; Tue, 3 Dec 2002 13:25:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB3IROS02115 for sip-archive@odin.ietf.org; Tue, 3 Dec 2002 13:27:24 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3I50v32505; Tue, 3 Dec 2002 13:05:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3I03v32084 for ; Tue, 3 Dec 2002 13:00:03 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06433 for ; Tue, 3 Dec 2002 12:57:08 -0500 (EST) From: aki.niemi@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gB3I15W17956 for ; Tue, 3 Dec 2002 20:01:05 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 3 Dec 2002 19:59:56 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 3 Dec 2002 19:59:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] B2BUA Date: Tue, 3 Dec 2002 19:59:56 +0200 Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9019450BE@esebe013.ntc.nokia.com> Thread-Topic: [Sip] B2BUA Thread-Index: AcKa8Zg3KvItklIFRPi+srZEaXRrqAAACLaw To: Cc: X-OriginalArrivalTime: 03 Dec 2002 17:59:56.0734 (UTC) FILETIME=[CA0D75E0:01C29AF5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gB3I03v32085 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Brian, inline. > Of course these things are never so simple. > On an "end system mixed" conference, an INVITE > from a new participant triggers Re-INVITES to > existing participants. Depending on details, > a focus could hold the response from the INVITE > of the new participant until it receives responses > from all existing participants (new CODEC negotiation > for example). That meets your definition of B2BUA. > > On the other hand, a centrally mixed conference > would not normally trigger Re-INVITES. Does that > mean that an end-system mixed focus is a B2BUA > but a centrally mixed focus is not? Hard to > differentiate. With both of them, a state > change, signaled by, say a NOTIFY from one to > the focus triggers NOTIFIES to (possibly a > subset of) the other participants, so that > would meet the definition. Would you call > that a change in roles? I agree, a conference server could assume both UA and B2BUA roles, as well as proxy and redirect server roles depending on the system, application, request, and so on. But whether a focus is a UA, a B2BUA, or both is somewhat besides the point. The roles need to be defined so that B2BUA behavior is distinct from UA behavior. The end-point can then use one that best fits its purpose. Cheers, Aki > > Brian > > > -----Original Message----- > > From: aki.niemi@nokia.com [mailto:aki.niemi@nokia.com] > > Sent: Tuesday, December 03, 2002 12:13 PM > > To: Brian.Rosen@marconi.com > > Cc: sip@ietf.org > > Subject: RE: [Sip] B2BUA > > > > > > Inline. > > > > > The key thing about a B2BUA is that it looks like a UA to whatever > > > it is connected to (on both sides). So, a conference server > > > looks like a UA to each of it's ports, and it has at least two of > > > them, and there is some "magic" between them. If you look at the > > > concept of the "focus" from the conferencing work, it is a > > > thing that has a bunch of two ended SIP calls, one with each > > > participant. Each participant thinks it is talking to a UA. > > > While some messages sent from a participant to a UA might be > > > consumed by the UA (state changes), often, a message will trigger > > > messages from the focus to other participants. > > > > This just generalized the B2BUA to cover any normal UA > > behavior. Example, I get a MESSAGE from a friend to my UA, > > based on which decide to call another friend by sending an > > INVITE from that UA. This I think is quite normal UA > > operation, the "magic" being me via my UI. > > > > > This seems, to me, to meet the definition of B2BUA in 3261, > > > and more strongly meets proposed changes in the definition. > > > Of course, it really doesn't matter if you consider the focus to > > > be a B2BUA or not. > > > > Hmm... Let's think of the B2BUA as 'in-UA' concatenated with > > 'out-UA'. By definition: > > > > 1) in-UAS receives request, > > > > 2) out-UAC sends request' > > 3) out-UAC receives response' > > > > 4) in-UAS sends response > > > > (The same process happens with requests going from 'out' to 'in') > > > > Within this B2BUA, 'in-UAS' shares magic with 'out-UAC', and > > 'in-UAC' shares magic with 'out-UAS'. However, if (as you > > state above), 4) follows immediately after 1), it's no longer > > a B2BUA, but a plain old UA, IMHO. > > > > Cheers, > > Aki > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Tue Dec 3 15:54:55 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17661 for ; Tue, 3 Dec 2002 15:54:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB3KvKV14377 for sip-archive@odin.ietf.org; Tue, 3 Dec 2002 15:57:20 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3Ku5v14288; Tue, 3 Dec 2002 15:56:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3Ki9v13798 for ; Tue, 3 Dec 2002 15:44:09 -0500 Received: from web80306.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17050 for ; Tue, 3 Dec 2002 15:41:13 -0500 (EST) Message-ID: <20021203204403.93841.qmail@web80306.mail.yahoo.com> Received: from [216.198.139.38] by web80306.mail.yahoo.com via HTTP; Tue, 03 Dec 2002 15:44:03 EST Date: Tue, 3 Dec 2002 15:44:03 -0500 (EST) From: Wenbo Sheng To: sip@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Sip] SIP servers interconnection Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hello, I have a question about SIP Servers (Agents) interconnection question. It would be appreciated if you could give me some point or suggestions. The question is, if a service provider1(SP1) has a SIP server in its network and it wants to connect to its partner service provider2(SP2)'s SIP server so that the user can roam between these 2 SPs, what kind of protocol or solution will be applied between these 2 SIP servers to communicate so that the user(who is registed in SP1) can use SP1's SIP server when he/she is in SP1 service coverage and use SP2's SIP server when in SP2 service coverage? What if these 2 SIP servers are using different databases (e.g. oracle and infomix)? Thanks a lot and I look forward to your help! B. ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Tue Dec 3 15:55:15 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17733 for ; Tue, 3 Dec 2002 15:55:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB3KvdS14394 for sip-archive@odin.ietf.org; Tue, 3 Dec 2002 15:57:39 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3Klcv13931; Tue, 3 Dec 2002 15:47:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3KfBv13695 for ; Tue, 3 Dec 2002 15:41:11 -0500 Received: from protactinium (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16889 for ; Tue, 3 Dec 2002 15:38:11 -0500 (EST) Received: from host213-122-129-192.in-addr.btopenworld.com ([213.122.129.192] helo=tkw) by protactinium with smtp (Exim 3.22 #16) id 18JJqh-0005eD-00 for sip@ietf.org; Tue, 03 Dec 2002 20:40:55 +0000 Message-ID: <000201c29b0b$f7be8900$0200000a@tkw> From: "Pete Cordell" To: References: Date: Tue, 3 Dec 2002 17:44:21 -0000 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.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Sip] B2BUA & Max-Forwards Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit One issue that the recent B2BUA discussion has raised in my mind is what a B2BUA (whatever its decided that should be) should do with Max-Forwards. This may have been discussed before, but while RFC 3261 says a B2BUA is a back to back UAS / UAC, and the coupling is not specified in the RFC, perhaps it ought to say that the max-forwards parameter MUST be propagated from the incoming request to the outgoing request using the same rules as a regular proxy. This would seem helpful for the avoidance of loops. Any comments? Pete. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Tue Dec 3 16:04:17 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18333 for ; Tue, 3 Dec 2002 16:04:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB3L6gC15001 for sip-archive@odin.ietf.org; Tue, 3 Dec 2002 16:06:42 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3L1Lv14528; Tue, 3 Dec 2002 16:01:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3KjUv13842 for ; Tue, 3 Dec 2002 15:45:30 -0500 Received: from mail-blue.research.att.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17105 for ; Tue, 3 Dec 2002 15:42:34 -0500 (EST) Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101]) by mail-blue.research.att.com (Postfix) with ESMTP id 35A314CF7A for ; Tue, 3 Dec 2002 15:45:24 -0500 (EST) Received: from research.att.com (lola.research.att.com [135.207.23.157]) by bigmail.research.att.com (8.11.6+Sun/8.11.6) with ESMTP id gB3KhwN03571 for ; Tue, 3 Dec 2002 15:43:58 -0500 (EST) Message-ID: <3DED17E1.7080106@research.att.com> Date: Tue, 03 Dec 2002 15:45:21 -0500 From: Hal Purdy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: SIP Mailng List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: B2BUA draft proposal Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > This thread is, hopefully reaching an end (with an agreement to > do some examples with call flows). However, the above statement > is yet one more example of the confusion people have with B2BUA. A group of us have been contemplating writing an informational draft in sipping that would provide examples with call flows among other things. We floated this idea with several people at the recent IETF meeting. In particular, while recognizing that little can be said about the behavior of the most general form of B2BUA, it seems possible to classify different kinds (sub-classes) of B2BUAs and then take a stab at specifying "suggested" behavior for these sub-classes by means of call flows. To be clear, we recognize that any "specification" of behavior of any sort of B2BUA would not be normative and would perhaps ultimately take the form of a BCP. Thinking to start things simply, we considered looking at the case of a "transparent" B2BUA with a UAC on one side and a UAS on the other. While not functionally interesting, this case would provide a baseline of behavior to serve as a launching point for more interesting B2BUAs types. Following an examination of the "transparent" B2BUA, we would hopefully move on to looking at a B2BUA that serves as a firewall gateway. Naturally, my colleagues and I welcome feedback on this proposal. I don't know if it's appropriate to move any discussion of this proposal to the sipping list since it seems to belong there. I'm happy to follow the group consensus regarding where the discussion should be held. Hal Purdy _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Tue Dec 3 16:21:50 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19351 for ; Tue, 3 Dec 2002 16:21:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB3LOFq16395 for sip-archive@odin.ietf.org; Tue, 3 Dec 2002 16:24:15 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3LJxv16185; Tue, 3 Dec 2002 16:19:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3LBnv15800 for ; Tue, 3 Dec 2002 16:11:49 -0500 Received: from auemail2.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18616 for ; Tue, 3 Dec 2002 16:08:52 -0500 (EST) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by auemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id gB3LBek02575; Tue, 3 Dec 2002 16:11:40 -0500 (EST) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id PAA24314; Tue, 3 Dec 2002 15:11:39 -0600 (CST) Message-ID: <3DED1E09.5030000@lucent.com> Date: Tue, 03 Dec 2002 15:11:37 -0600 From: "Vijay K. Gurbani" Organization: Lucent Technologies, Inc./Bell Laboratories User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pete Cordell CC: sip@ietf.org Subject: Re: [Sip] B2BUA & Max-Forwards References: <000201c29b0b$f7be8900$0200000a@tkw> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Pete Cordell wrote: > One issue that the recent B2BUA discussion has raised in my mind is what a > B2BUA (whatever its decided that should be) should do with Max-Forwards. > > This may have been discussed before, but while RFC 3261 says a B2BUA is a > back to back UAS / UAC, and the coupling is not specified in the RFC, > perhaps it ought to say that the max-forwards parameter MUST be propagated > from the incoming request to the outgoing request using the same rules > as a regular proxy. This would seem helpful for the avoidance of loops. I have a feeling that specialized handling of headers for B2BUAs is yet another nightmare in the making. A B2BUA is a UA, period. So long as the request made it to one half of the B2BUA before Max-Forwards reached 0, the protocol constraints on that request have been satisfied. What the other half of the B2BUA wants to do with the Max-Forwards header is entirely up to it. Regards, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Tue Dec 3 16:22:24 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19394 for ; Tue, 3 Dec 2002 16:22:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB3LOnr16416 for sip-archive@odin.ietf.org; Tue, 3 Dec 2002 16:24:49 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3LE3v15876; Tue, 3 Dec 2002 16:14:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3L88v15658 for ; Tue, 3 Dec 2002 16:08:08 -0500 Received: from almso2.proxy.att.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18405 for ; Tue, 3 Dec 2002 16:05:12 -0500 (EST) Received: from attrh3i.attrh.att.com ([135.71.62.12]) by almso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id gB3KCTQO002082 for ; Tue, 3 Dec 2002 16:08:00 -0500 (EST) Received: from occlust04evs1.ugd.att.com (135.71.164.12) by attrh3i.attrh.att.com (6.5.019) id 3DDD63A100512970; Tue, 3 Dec 2002 16:07:59 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] B2BUA & Max-Forwards Date: Tue, 3 Dec 2002 16:07:55 -0500 Message-ID: <62DA45D4963FA747BA1B253E266760F904D2BBF5@OCCLUST04EVS1.ugd.att.com> Thread-Topic: [Sip] B2BUA & Max-Forwards Thread-Index: AcKbDjGUhGUhyIbbRWOjofuC26Ne0AAAI5qA From: "Roy, Radhika R, ALASO" To: "Pete Cordell" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gB3L88v15659 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit inline [RRR] -----Original Message----- From: Pete Cordell [mailto:pete@tech-know-ware.com] Sent: Tuesday, December 03, 2002 12:44 PM To: sip@ietf.org Subject: [Sip] B2BUA & Max-Forwards One issue that the recent B2BUA discussion has raised in my mind is what a B2BUA (whatever its decided that should be) should do with Max-Forwards. This may have been discussed before, but while RFC 3261 says a B2BUA is a back to back UAS / UAC, and the coupling is not specified in the RFC, perhaps it ought to say that the max-forwards parameter MUST be propagated from the incoming request to the outgoing request using the same rules as a regular proxy. This would seem helpful for the avoidance of loops. [RRR] It depends. Proxy MUST abide by its own rules as specified in RFC 3261. Similarly, UAs also MUST need to obey all SIP rules. These two (i.e., Proxy and B2BUA) act independently as per their SIP rules. The question then comes: How do people build services/applications that have the dependency between B2BUA and proxy function? SIP does not define these rules. That is why, people are coming to the conclusion let there should an informational RFC in defining B2BUA functionalities along with call flows (as Brain and others pointed out). Any comments? Pete. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Tue Dec 3 16:46:27 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20334 for ; Tue, 3 Dec 2002 16:46:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB3LmqZ18056 for sip-archive@odin.ietf.org; Tue, 3 Dec 2002 16:48:52 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3LfDv17747; Tue, 3 Dec 2002 16:41:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3LZrv16944 for ; Tue, 3 Dec 2002 16:35:53 -0500 Received: from hotmail.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19849 for ; Tue, 3 Dec 2002 16:32:57 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 3 Dec 2002 13:35:46 -0800 Received: from 12.146.131.5 by lw7fd.law7.hotmail.msn.com with HTTP; Tue, 03 Dec 2002 21:35:46 GMT X-Originating-IP: [12.146.131.5] From: "Padma Suresh" To: vkg@lucent.com, pete@tech-know-ware.com Cc: sip@ietf.org Subject: Re: [Sip] B2BUA & Max-Forwards Date: Tue, 03 Dec 2002 21:35:46 +0000 Mime-Version: 1.0 Content-Type: text/html Message-ID: X-OriginalArrivalTime: 03 Dec 2002 21:35:46.0935 (UTC) FILETIME=[F0F95070:01C29B13] Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: ,

Vijay,

     You are right -

    A B2BUA needs to propagate some of the headers received in a request/response to the other endpoint.

    Example: Require, Expires to name a few. This is because these headers actually are relevant end to end.

   However, some of the other headers like Contact should be set by the B2BUA as itself.  

   Padma

>From: "Vijay K. Gurbani"
>To: Pete Cordell
>CC: sip@ietf.org
>Subject: Re: [Sip] B2BUA & Max-Forwards
>Date: Tue, 03 Dec 2002 15:11:37 -0600
>
>Pete Cordell wrote:
>>One issue that the recent B2BUA discussion has raised in my mind is
>>what a
>>B2BUA (whatever its decided that should be) should do with
>>Max-Forwards.
>>
>>This may have been discussed before, but while RFC 3261 says a
>>B2BUA is a
>>back to back UAS / UAC, and the coupling is not specified in the
>>RFC,
>>perhaps it ought to say that the max-forwards parameter MUST be
>>propagated
>>from the incoming request to the outgoing request using the same
>>rules as a regular proxy. This would seem helpful for the
>>avoidance of loops.
>
>I have a feeling that specialized handling of headers for B2BUAs is
>yet
>another nightmare in the making.
>
>A B2BUA is a UA, period. So long as the request made it to one half
>of the B2BUA before Max-Forwards reached 0, the protocol constraints
>on that request have been satisfied. What the other half of the
>B2BUA wants to do with the Max-Forwards header is entirely up to it.
>
>Regards,
>
>- vijay
>--
>Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org}
>Wireless Networks Group/Internet Software and Services
>Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm
>6G-440
>Naperville, Illinois 60566 Voice: +1 630 224 0216
>
>_______________________________________________
>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP Protocol
>Use sip-implementors@cs.columbia.edu for questions on current sip
>Use sipping@ietf.org for new developments on the application of sip

Add photos to your e-mail with MSN 8. Get 2 months FREE*. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Tue Dec 3 17:34:44 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22883 for ; Tue, 3 Dec 2002 17:34:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB3Mb9222189 for sip-archive@odin.ietf.org; Tue, 3 Dec 2002 17:37:09 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3MQiv21380; Tue, 3 Dec 2002 17:26:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3MMsv21243 for ; Tue, 3 Dec 2002 17:22:54 -0500 Received: from gateway.hns.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22158; Tue, 3 Dec 2002 17:19:58 -0500 (EST) From: aroychow@hss.hns.com Received: from excore1.hns.com (excore1.hns.com [139.85.52.104]) by gateway.hns.com (Switch-3.0.0/Switch-3.0.0) with ESMTP id gB3MMjLo024869; Tue, 3 Dec 2002 17:22:45 -0500 (EST) Received: from atlas (atlas.hns.com [139.85.177.110]) by excore1.hns.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gB3MMe121690; Tue, 3 Dec 2002 17:22:40 -0500 (EST) To: "Vijay K. Gurbani" Cc: Pete Cordell , sip@ietf.org, sip-admin@ietf.org Subject: Re: [Sip] B2BUA & Max-Forwards MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Tue, 3 Dec 2002 17:26:45 -0500 X-MIMETrack: Serialize by Router on Atlas/HNS(Release 5.0.10 |March 22, 2002) at 12/03/2002 05:20:43 PM, Serialize complete at 12/03/2002 05:20:43 PM Content-Type: text/plain; charset="us-ascii" X-Filtered: Sendmail MIME Filter v1.0.7 excore1.hns.com gB3MMe121690 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , I've been following two threads on the B'to'BUA definition and looks like both are pretty similar. So Here are my 2c: * First, hope I am not offending someone by using BtoBUA instead of B2BUA. Beleive it or not, this '2' also is another source of confusion for many people who seem to think '2' means the number two and implies '1 UA and 1 UAS' and therefore should be really called BnBUA :-) * How a BtoBUA functions depends on what application is being implemented by it. Therefore, it does not make sense to me trying to dictate or suggest how the BtoB associates one or more UAS instances with one or more UAC instances. Therefore, a BtoB can only be defined as how its seen from the 'outside' -> i.e. as Vijay points out, A B2BUA is a UA, period. So long as the request made it to one half of the B2BUA before Max-Forwards reached 0, the protocol constraints on that request have been satisfied. What the other half of the B2BUA wants to do with the Max-Forwards header is entirely up to it. * How the BtoB 'associates' one or more UAS instances with one or more UAC instances is dependent on an algorithm which MAY associate using defined SIP protocol semantics or some other application level semantic which cannot be standardized. * 'transparent' , 'semi-transparent', 'evil' BtoBUAs reflect different algorithms that a BtoB applies to a message after a inbound SIP message is received and before an associated SIP message is sent out. * Therefore, trying to define what a BtoBUA should do with a message without defining what is the application that is using this model seems like it will simply add to the confusion instead of trying to solve it. In summary, as suggested by some others, the only way to 'describe' what a BtoB may do, makes sense only if we define call-flows with specific applications in mind. Trying to generalize an application-specific entity is going to confuse implementors much more. In addition, these call flows should describe how one can achieve certain end services (specific) instead of trying to project the message that this is how a BtoB should really work (generic). Atleast now implementors know they can do what they want with the B2B internally as long as external interfaces are standard. While this may seem like sacrilege, it makes a lot of sense to keep it this way . Opinions on what should or should not be done really depends on a particular scenario and deployment case (as proven time and again by 3G CSCFs as well as FCPs, media proxies et al). regds arjun -- Arjun Roychowdhury @ Hughes Software Systems 11717 Exploration Lane, Germantown MD 20876 (O): 301-212-7860 (M): 240-997-0066 "Vijay K. Gurbani" Sent by: sip-admin@ietf.org 12/03/2002 04:11 PM To: Pete Cordell cc: sip@ietf.org Subject: Re: [Sip] B2BUA & Max-Forwards Pete Cordell wrote: > One issue that the recent B2BUA discussion has raised in my mind is what a > B2BUA (whatever its decided that should be) should do with Max-Forwards. > > This may have been discussed before, but while RFC 3261 says a B2BUA is a > back to back UAS / UAC, and the coupling is not specified in the RFC, > perhaps it ought to say that the max-forwards parameter MUST be propagated > from the incoming request to the outgoing request using the same rules > as a regular proxy. This would seem helpful for the avoidance of loops. I have a feeling that specialized handling of headers for B2BUAs is yet another nightmare in the making. A B2BUA is a UA, period. So long as the request made it to one half of the B2BUA before Max-Forwards reached 0, the protocol constraints on that request have been satisfied. What the other half of the B2BUA wants to do with the Max-Forwards header is entirely up to it. Regards, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Tue Dec 3 19:40:26 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27237 for ; Tue, 3 Dec 2002 19:40:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB40gp230633 for sip-archive@odin.ietf.org; Tue, 3 Dec 2002 19:42:51 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB40d9v30498; Tue, 3 Dec 2002 19:39:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB40b6v30059 for ; Tue, 3 Dec 2002 19:37:06 -0500 Received: from mail2.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27086 for ; Tue, 3 Dec 2002 19:34:10 -0500 (EST) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id gB40ZnXE010242; Tue, 3 Dec 2002 19:35:50 -0500 (EST) Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 3 Dec 2002 18:36:57 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A6436D@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Padma Suresh'" , vkg@lucent.com, pete@tech-know-ware.com Cc: sip@ietf.org Subject: RE: [Sip] B2BUA & Max-Forwards Date: Tue, 3 Dec 2002 18:36:50 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , -----Original Message----- From: Padma Suresh [mailto:padma_suresh@hotmail.com] > A B2BUA needs to propagate some of the headers received in a > request/response to the other endpoint. Example: Require... No. As emphatically as possible: NO. This is completely wrong, and it appears to be a growing -- and dangerous -- misconception. A B2BUA cannot transparently pass Require through. It must understand and invoke the extension indicated. "The Require header field contains a list of option tags, described in Section 19.2. Each option tag defines a SIP extension that MUST be understood to process the request." A back to back user agent *is* a UAS, and *is* bound by this provision. Whether the UAC portion then turns around and imposes the same requirement on the UAS it contacts is a local decision. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Tue Dec 3 21:38:48 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00459 for ; Tue, 3 Dec 2002 21:38:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB42fF504823 for sip-archive@odin.ietf.org; Tue, 3 Dec 2002 21:41:15 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB42eTv04798; Tue, 3 Dec 2002 21:40:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB42c9v04710 for ; Tue, 3 Dec 2002 21:38:09 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00355 for ; Tue, 3 Dec 2002 21:35:10 -0500 (EST) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id gB42bf0J003179; Tue, 3 Dec 2002 18:37:41 -0800 (PST) Received: from fluffyw2k (dhcp-128-107-142-55.cisco.com [128.107.142.55]) by mira-sjc5-9.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with SMTP id DXK00273; Tue, 3 Dec 2002 18:38:20 -0800 (PST) From: "Cullen Jennings" To: "Hal Purdy" , "SIP Mailng List" Subject: RE: [Sip] Re: B2BUA draft proposal Date: Tue, 3 Dec 2002 18:37:59 -0800 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3DED17E1.7080106@research.att.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Sounds good - I look forward to seeing it - and since this will not change the behavior of SIP but just show some ways to use it, I think the sipping list would be the place to discuss it. Cullen > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Hal > Purdy > Sent: Tuesday, December 03, 2002 12:45 PM > To: SIP Mailng List > Subject: [Sip] Re: B2BUA draft proposal > > > > This thread is, hopefully reaching an end (with an agreement to > > do some examples with call flows). However, the above statement > > is yet one more example of the confusion people have with B2BUA. > > > A group of us have been contemplating writing an informational > draft in sipping that would provide examples with call flows among other > things. > We floated this idea with several people at the recent IETF meeting. > > In particular, while recognizing that little can be said about the > behavior of the most > general form of B2BUA, it seems possible to classify different kinds > (sub-classes) > of B2BUAs and then take a stab at specifying "suggested" behavior for > these sub-classes > by means of call flows. To be clear, we recognize that any > "specification" of behavior > of any sort of B2BUA would not be normative and would perhaps ultimately > take the form of a BCP. > > Thinking to start things simply, we considered looking at the case of a > "transparent" B2BUA with a UAC on one side and a UAS on the other. While > not > functionally interesting, this case would provide a baseline of > behavior to serve as a launching point for more interesting B2BUAs types. > Following an examination of the "transparent" B2BUA, we would hopefully > move > on to looking at a B2BUA that serves as a firewall gateway. > > Naturally, my colleagues and I welcome feedback on this proposal. > > I don't know if it's appropriate to move any discussion of this proposal > to the > sipping list since it seems to belong there. I'm happy to follow the > group consensus > regarding where the discussion should be held. > > > Hal Purdy > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Tue Dec 3 21:52:40 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00717 for ; Tue, 3 Dec 2002 21:52:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB42t8K05307 for sip-archive@odin.ietf.org; Tue, 3 Dec 2002 21:55:08 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB42j6v04962; Tue, 3 Dec 2002 21:45:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB42iGv04911 for ; Tue, 3 Dec 2002 21:44:16 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00507 for ; Tue, 3 Dec 2002 21:41:18 -0500 (EST) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id gB42hm0J006075; Tue, 3 Dec 2002 18:43:48 -0800 (PST) Received: from fluffyw2k (dhcp-128-107-142-55.cisco.com [128.107.142.55]) by mira-sjc5-9.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with SMTP id DXK00404; Tue, 3 Dec 2002 18:44:27 -0800 (PST) From: "Cullen Jennings" To: "Pete Cordell" , Subject: RE: [Sip] B2BUA & Max-Forwards Date: Tue, 3 Dec 2002 18:44:06 -0800 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.2911.0) In-Reply-To: <000201c29b0b$f7be8900$0200000a@tkw> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit A related question to this was how to stop routing loops that included some PSTN hops. One solution to this was to make sure that as a call was passed from SIP to SS7 there was a mapping of the number of hops. A trivial 1:1 mapping would be unlikely to work. I really don't really care that much if something like this is documented or not but I imagine that some devices will do it to stop routing loops that eat infinite amounts of resources. Cullen > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Pete > Cordell > Sent: Tuesday, December 03, 2002 9:44 AM > To: sip@ietf.org > Subject: [Sip] B2BUA & Max-Forwards > > > One issue that the recent B2BUA discussion has raised in my mind is what a > B2BUA (whatever its decided that should be) should do with Max-Forwards. > > This may have been discussed before, but while RFC 3261 says a B2BUA is a > back to back UAS / UAC, and the coupling is not specified in the RFC, > perhaps it ought to say that the max-forwards parameter MUST be propagated > from the incoming request to the outgoing request using the same > rules as a > regular proxy. This would seem helpful for the avoidance of loops. > > Any comments? > > Pete. > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Wed Dec 4 02:40:49 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00907 for ; Wed, 4 Dec 2002 02:40:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB47hJ129413 for sip-archive@odin.ietf.org; Wed, 4 Dec 2002 02:43:19 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB47gev29398; Wed, 4 Dec 2002 02:42:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB47dQv29293 for ; Wed, 4 Dec 2002 02:39:26 -0500 Received: from smail3.alcatel.fr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00867 for ; Wed, 4 Dec 2002 02:36:25 -0500 (EST) From: Juan-Carlos.Rojas@alcatel.fr Received: from frmail25.netfr.alcatel.fr (frmail25.netfr.alcatel.fr [155.132.182.155]) by smail3.alcatel.fr (ALCANET/NETFR) with ESMTP id gB47dDek000543; Wed, 4 Dec 2002 08:39:14 +0100 Subject: Re: [Sip] Re: B2BUA draft proposal To: Hal Purdy Cc: SIP Mailng List Date: Wed, 4 Dec 2002 08:39:13 +0100 Message-ID: X-MIMETrack: Serialize by Router on FRMAIL25/FR/ALCATEL(Release 5.0.8 |June 18, 2001) at 12/04/2002 08:39:14 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hello, "In particular, while recognizing that little can be said about the behavior of the most general form of B2BUA, it seems possible to classify different kinds (sub-classes)" Good idea to give examples of implementing an application using a B2BUA, this can illustrate what could be done with a B2BUA (even if is very likely that this will generate a lot of debate). But please *do not* classify B2BUA, because there will always be a new application not fitting in your classification. Best regards Juan Carlos Hal Purdy @ietf.org on 03/12/2002 21:45:21 Sent by: sip-admin@ietf.org To: SIP Mailng List cc: Subject: [Sip] Re: B2BUA draft proposal > This thread is, hopefully reaching an end (with an agreement to > do some examples with call flows). However, the above statement > is yet one more example of the confusion people have with B2BUA. A group of us have been contemplating writing an informational draft in sipping that would provide examples with call flows among other things. We floated this idea with several people at the recent IETF meeting. In particular, while recognizing that little can be said about the behavior of the most general form of B2BUA, it seems possible to classify different kinds (sub-classes) of B2BUAs and then take a stab at specifying "suggested" behavior for these sub-classes by means of call flows. To be clear, we recognize that any "specification" of behavior of any sort of B2BUA would not be normative and would perhaps ultimately take the form of a BCP. Thinking to start things simply, we considered looking at the case of a "transparent" B2BUA with a UAC on one side and a UAS on the other. While not functionally interesting, this case would provide a baseline of behavior to serve as a launching point for more interesting B2BUAs types. Following an examination of the "transparent" B2BUA, we would hopefully move on to looking at a B2BUA that serves as a firewall gateway. Naturally, my colleagues and I welcome feedback on this proposal. I don't know if it's appropriate to move any discussion of this proposal to the sipping list since it seems to belong there. I'm happy to follow the group consensus regarding where the discussion should be held. Hal Purdy _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Wed Dec 4 02:49:59 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01033 for ; Wed, 4 Dec 2002 02:49:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB47qTT29768 for sip-archive@odin.ietf.org; Wed, 4 Dec 2002 02:52:29 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB47qDv29747; Wed, 4 Dec 2002 02:52:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB47pav29711 for ; Wed, 4 Dec 2002 02:51:36 -0500 Received: from smail3.alcatel.fr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01019 for ; Wed, 4 Dec 2002 02:48:35 -0500 (EST) From: Juan-Carlos.Rojas@alcatel.fr Received: from frmail25.netfr.alcatel.fr (frmail25.netfr.alcatel.fr [155.132.182.155]) by smail3.alcatel.fr (ALCANET/NETFR) with ESMTP id gB47pFek005539; Wed, 4 Dec 2002 08:51:16 +0100 Subject: RE: [Sip] B2BUA & Max-Forwards To: Adam Roach Cc: "'Padma Suresh'" , vkg@lucent.com, pete@tech-know-ware.com, sip@ietf.org Date: Wed, 4 Dec 2002 08:51:13 +0100 Message-ID: X-MIMETrack: Serialize by Router on FRMAIL25/FR/ALCATEL(Release 5.0.8 |June 18, 2001) at 12/04/2002 08:51:15 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hello, As it was already stated in this discusion thread, a B2BUA is an *application* linking several UAs As such, the behaviour of a B2BUA cannot be standardised. Therefore, one cannot say that "A B2BUA needs to propagate some of the headers received". However, you can say that the application "x" behaves as a B2BUA, and that the application "x" "needs to propagate" the a-header or the b-header etc. for the needs of the application. This is the choice of the application, that's all. Best regards Juan Carlos Adam Roach @ietf.org on 04/12/2002 01:36:50 Sent by: sip-admin@ietf.org To: "'Padma Suresh'" , vkg@lucent.com, pete@tech-know-ware.com cc: sip@ietf.org Subject: RE: [Sip] B2BUA & Max-Forwards -----Original Message----- From: Padma Suresh [mailto:padma_suresh@hotmail.com] > A B2BUA needs to propagate some of the headers received in a > request/response to the other endpoint. Example: Require... No. As emphatically as possible: NO. This is completely wrong, and it appears to be a growing -- and dangerous -- misconception. A B2BUA cannot transparently pass Require through. It must understand and invoke the extension indicated. "The Require header field contains a list of option tags, described in Section 19.2. Each option tag defines a SIP extension that MUST be understood to process the request." A back to back user agent *is* a UAS, and *is* bound by this provision. Whether the UAC portion then turns around and imposes the same requirement on the UAS it contacts is a local decision. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Wed Dec 4 03:01:12 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01496 for ; Wed, 4 Dec 2002 03:01:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB483gf30260 for sip-archive@odin.ietf.org; Wed, 4 Dec 2002 03:03:42 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB483Kv30246; Wed, 4 Dec 2002 03:03:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB482Av30203 for ; Wed, 4 Dec 2002 03:02:10 -0500 Received: from smail3.alcatel.fr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01428 for ; Wed, 4 Dec 2002 02:59:09 -0500 (EST) From: Juan-Carlos.Rojas@alcatel.fr Received: from frmail25.netfr.alcatel.fr (frmail25.netfr.alcatel.fr [155.132.182.155]) by smail3.alcatel.fr (ALCANET/NETFR) with ESMTP id gB481wek011038; Wed, 4 Dec 2002 09:01:58 +0100 Subject: Re: [Sip] B2BUA & Max-Forwards To: "Pete Cordell" Cc: Date: Wed, 4 Dec 2002 09:01:56 +0100 Message-ID: X-MIMETrack: Serialize by Router on FRMAIL25/FR/ALCATEL(Release 5.0.8 |June 18, 2001) at 12/04/2002 09:01:57 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hello, The following text comes from RFC 3261, page 39 "A UAC MUST insert a Max-Forwards header field into each request it originates with a value that SHOULD be 70" Now, a B2BUA handles several UAs. For a given UA, when behaving as UAC, the Max-Forwards header has to be *initialised* by the UA. The RFC3261 recommends to use the value 70, but this is not mandatory (to fixe the initial value of Max-Forwards, RFC3261 uses a SHOULD and not a MUST). Therefore, a B2BUA acting as an application can freely choose for a UAC which it is handling: - Initialise Max-Forwards to 70, as recommended by RFC3261 for a UAC - Initialise Max-Forwards with the value possibly received in a UA acting as UAS. - Initialise Max-Forwards to any other value, according to the application definition Once again, this is a question of application defintion. Best regards Juan Carlos "Pete Cordell" @ietf.org on 03/12/2002 18:44:21 Sent by: sip-admin@ietf.org To: cc: Subject: [Sip] B2BUA & Max-Forwards One issue that the recent B2BUA discussion has raised in my mind is what a B2BUA (whatever its decided that should be) should do with Max-Forwards. This may have been discussed before, but while RFC 3261 says a B2BUA is a back to back UAS / UAC, and the coupling is not specified in the RFC, perhaps it ought to say that the max-forwards parameter MUST be propagated from the incoming request to the outgoing request using the same rules as a regular proxy. This would seem helpful for the avoidance of loops. Any comments? Pete. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Wed Dec 4 03:37:51 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02404 for ; Wed, 4 Dec 2002 03:37:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB48eL832737 for sip-archive@odin.ietf.org; Wed, 4 Dec 2002 03:40:21 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB48dmv32658; Wed, 4 Dec 2002 03:39:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB48cjv32623 for ; Wed, 4 Dec 2002 03:38:45 -0500 Received: from dharti.aplion.stpn.soft.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02344 for ; Wed, 4 Dec 2002 03:35:11 -0500 (EST) Received: from ravishiroor (localhost [127.0.0.1]) by dharti.aplion.stpn.soft.net (8.11.2/8.11.2) with SMTP id gB48dDs12836 for ; Wed, 4 Dec 2002 14:09:13 +0530 From: "Ravi Shiroor" To: Date: Wed, 4 Dec 2002 14:06:06 +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 V5.50.4910.0300 Content-Transfer-Encoding: 7bit Subject: [Sip] response to merged requests Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit posting this on sip as there were no responses on sip-implementors. ---------> section 8.2.2.2 in RFC 3261 says that when a UAS receives merged requests, it should respond to the INVITEs receieved after the first one (those detected as merged) with 482 (loop detected). i was wondering why "loop detected" is being being used when merged requests are receieved? wouldnt it be appropriate to define a specific 4xx response for merged requests? can somebody please clarify if there is a valid reason for using "loop detected" in this scenario? TIA, ravi. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Wed Dec 4 04:38:57 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03883 for ; Wed, 4 Dec 2002 04:38:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB49fTP04427 for sip-archive@odin.ietf.org; Wed, 4 Dec 2002 04:41:29 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB49f2v04415; Wed, 4 Dec 2002 04:41:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB49bGv04138 for ; Wed, 4 Dec 2002 04:37:16 -0500 Received: from avgw.vxserver.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA03818 for ; Wed, 4 Dec 2002 04:34:14 -0500 (EST) Received: from disney.internal.ridgewaysystems.com ([194.128.67.181]) by avgw.vxserver.com (NAVGW 2.5.2.12) with SMTP id M2002120409355028818 for ; Wed, 04 Dec 2002 09:35:50 GMT Received: from Unknown [10.1.1.1] by disney.internal.ridgewaysystems.com - SurfControl E-mail Filter (4.5); Wednesday, 04 December 2002, 09:37:26 Received: by ridgeway.internal.ridgewaysystems.com with Internet Mail Service (5.5.2653.19) id ; Wed, 4 Dec 2002 09:37:03 -0000 Message-ID: <00533D13955AD411AF3800A0C9B4263994D87D@ridgeway.internal.ridgewaysystems.com> From: Phil Reynolds To: sip@ietf.org Date: Wed, 4 Dec 2002 09:36:53 -0000 Subject: RE: [Sip] B2BUA & Max-Forwards MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--=_NextPart_ST_09_37_26_Wednesday_December_04_2002_9163" X-Mailer: Internet Mail Service (5.5.2653.19) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , 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_ST_09_37_26_Wednesday_December_04_2002_9163 Content-Type: text/plain Now your back to restricting what I can and can't do in an intermediary. It can't be a B2BUA 'cos it doesn't need to honour require headers (the UA at the other end does that, if they were meant for my intermediary then they would be proxy-require?), and it can't be a proxy 'cos of the rules about not changing the body so what is it? It's not sanctioned by the RFC, yet id does an important and useful job. -----Original Message----- From: Adam Roach [mailto:adam@dynamicsoft.com] Sent: 04 December 2002 00:37 To: 'Padma Suresh'; vkg@lucent.com; pete@tech-know-ware.com Cc: sip@ietf.org Subject: RE: [Sip] B2BUA & Max-Forwards -----Original Message----- From: Padma Suresh [mailto:padma_suresh@hotmail.com] > A B2BUA needs to propagate some of the headers received in a > request/response to the other endpoint. Example: Require... No. As emphatically as possible: NO. This is completely wrong, and it appears to be a growing -- and dangerous -- misconception. A B2BUA cannot transparently pass Require through. It must understand and invoke the extension indicated. "The Require header field contains a list of option tags, described in Section 19.2. Each option tag defines a SIP extension that MUST be understood to process the request." A back to back user agent *is* a UAS, and *is* bound by this provision. Whether the UAC portion then turns around and imposes the same requirement on the UAS it contacts is a local decision. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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_ST_09_37_26_Wednesday_December_04_2002_9163 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Sip] B2BUA & Max-Forwards

Now your back to restricting what I can and can't do in a= n intermediary. It can't be a B2BUA 'cos it doesn't need to honour require = headers (the UA at the other end does that, if they were meant for my inter= mediary then they would be proxy-require?), and it can't be a proxy 'cos of= the rules about not changing the body so what is it?

It's not sanctioned by the RFC, yet id does an important = and useful job.

-----Original Message-----
From: Adam Roach [mailto:adam@dynamicsoft.com]
Sent: 04 December 2002 00:37
To: 'Padma Suresh'; vkg@lucent.com; pete@tech-know-ware.= com
Cc: sip@ietf.org
Subject: RE: [Sip] B2BUA & Max-Forwards


-----Original Message-----
From: Padma Suresh [mailto:padma_suresh@hotmail.com]
 
> A B2BUA needs to propagate some of the headers rece= ived in a
> request/response to the other endpoint. Example: Re= quire...

No. As emphatically as possible: NO. This is completely w= rong, and it appears to be a growing -- and dangerous -- misconception.

A B2BUA cannot transparently pass Require through. It mus= t understand and invoke the extension indicated.

  "The Require header field contains a list of = option tags, described in
   Section 19.2.  Each option tag defines= a SIP extension that MUST be
   understood to process the request."

A back to back user agent *is* a UAS, and *is* bound by t= his provision.

Whether the UAC portion then turns around and imposes the= same requirement on the UAS it contacts is a local decision.

/a
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listi= nfo/sip
This list is for NEW development of the core SIP Protoco= l
Use sip-implementors@cs.columbia.edu for questions on cu= rrent sip Use sipping@ietf.org for new developments on the application of s= ip

----=_NextPart_ST_09_37_26_Wednesday_December_04_2002_9163-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Wed Dec 4 07:23:07 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07378 for ; Wed, 4 Dec 2002 07:23:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB4CPQm13206 for sip-archive@odin.ietf.org; Wed, 4 Dec 2002 07:25:26 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4CP4v13171; Wed, 4 Dec 2002 07:25:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4CNQv13088 for ; Wed, 4 Dec 2002 07:23:26 -0500 Received: from hss.hns.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07332 for ; Wed, 4 Dec 2002 07:20:32 -0500 (EST) From: sunayak@hss.hns.com Received: from sampark.hss.hns.com (sampark [139.85.229.22]) by hss.hns.com (8.11.6/8.11.2) with SMTP id gB4C1Ti01981; Wed, 4 Dec 2002 17:31:29 +0530 Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256C85.0043B534 ; Wed, 4 Dec 2002 17:49:33 +0530 X-Lotus-FromDomain: HSSBLR To: Robert Sparks cc: sip@ietf.org Message-ID: <65256C85.0043B503.00@sampark.hss.hns.com> Date: Wed, 4 Dec 2002 17:49:32 +0530 Subject: Re: [Sip] Constructing the branch parameter at stateless proxies Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi Robert, Here's one issue i could think of: Insertion of branch parameter in Via header has been mandatory for proxies all along. However, for UA's it became mandatory only from bis-06 onwards. So if we have a pre-bis-06 UA sending a request to a stateless proxy (i.e. first hop is a SLP), the proxy would end up forwarding it without a branch parameter. Ofcourse, things would still work fine at the next stateful hop. But, by not inserting a branch parameter, the SLP would not be compliant to the spec. (Proxies MUST insert a branch). This would happen only if a SLP is at the first hop from such a UA. Thereafter, even if the request loops or spirals through, the SLP would end up adding different branches by following your approach. So we could special-case this with a simpler logic so that if the SLP doesn't see a branch in the topmost Via, it could insert a simple one (concatenating the Tags-CallId-CseqNum for example). Subhash Nayak Hughes Software Systems http://www.hssworld.com Robert Sparks on 12/03/2002 10:05:01 PM To: sip@ietf.org cc: (bcc: Subhash Ullal Nayak/HSSBLR) Subject: [Sip] Constructing the branch parameter at stateless proxies This list has seen a couple of requests to clarify the language in RFC 3261 concerning how a stateless proxy creates a branch identifier. The current text requires uniqueness, dependency on route decision affecting parameters and care to be sure that those parameters are retransmission invariant. It goes on to recommend a hash over a set of fields (this set has been the subject of the requests for clarification). I think there's a much simpler solution. The purpose of this branch parameter is to act as a transaction identifier. Who cares about this identifier? Only the stateful elements at each end of the transaction. Any stateless proxies between these elements don't use that identifier in any of their decisions, so I assert that it is not useful to change it as it crosses the stateless proxy. I propose, then, that a stateless proxy simply copy the branch parameter from the topmost Via header field value it receives into the Via header field value it adds to the request. I don't believe it matters that this parameter contain the magic cookie. If it doesn't, the next stateful hop will use the 2543-style transaction identifiers provided by the sending stateful element. The stateless elements are by definition transaction transparent. So - can anyone construct a scenario where this doesn't function correctly? If not, we can remove several convoluted paragraphs from the spec and replace them with a very simple couple of sentences. 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Wed Dec 4 08:04:30 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08740 for ; Wed, 4 Dec 2002 08:04:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB4D6pc15448 for sip-archive@odin.ietf.org; Wed, 4 Dec 2002 08:06:51 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4D6Uv15433; Wed, 4 Dec 2002 08:06:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4D3Tv15331 for ; Wed, 4 Dec 2002 08:03:29 -0500 Received: from fox.iptel.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08596 for ; Wed, 4 Dec 2002 08:00:37 -0500 (EST) Received: from jku07.fokus.fraunhofer.de (port-212-202-168-86.reverse.qdsl-home.de [212.202.168.86]) by fox.iptel.org (8.11.6/8.11.6) with ESMTP id gB4D36415373; Wed, 4 Dec 2002 14:03:06 +0100 Message-Id: <5.2.0.9.0.20021204133027.036e0410@mailhost.fokus.gmd.de> X-Sender: jku@mailhost.fokus.gmd.de (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 04 Dec 2002 13:31:35 +0100 To: "Christian Huitema" , "Roy, Radhika R, ALASO" , From: Jiri Kuthan Subject: RE: [Sip] B2BUA Cc: , , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , At 05:35 PM 12/3/2002, Christian Huitema wrote: >> > [MB]: Some of this, of course, will lead us back to the >> > list of the reasons why some folks consider these things "evil", ... >> >> I do not remember whether anyone has ever said that B2BUA is evil >> things. What I remember is that the dumping of the B2BUA functionality >> in the name of SIP Proxy is an evil thing. > >The real issue in all this is security. Many security folks believe >that, in order to get proper security, the body of the signaling >messages should be signed, and possibly encrypted. In that logic, the >proxies only manipulate the information exposed in the SIP header, which >can be as little as the pair of source and destination URL. > >Any intermediary that attempts to "rewrite the SDP" has to somehow >insert itself in the end-to-end security exchange; many security folks >will resent that as "breaking end-to-end security". Insofar as SDP >rewriting attempts to provide a legitimate service, the challenge is >thus to provide the service in such a way that it does not require >breaking end-to-end encryption. > >-- Christian Huitema I think there are more issues with B2BUA. A B2BUA's failure affects all current calls :-( -Jiri _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Wed Dec 4 08:36:13 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10034 for ; Wed, 4 Dec 2002 08:36:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB4DcYY18031 for sip-archive@odin.ietf.org; Wed, 4 Dec 2002 08:38:34 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4Dc8v18008; Wed, 4 Dec 2002 08:38:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4Daxv17365 for ; Wed, 4 Dec 2002 08:36:59 -0500 Received: from avgw.vxserver.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA09964 for ; Wed, 4 Dec 2002 08:34:07 -0500 (EST) Received: from disney.internal.ridgewaysystems.com ([194.128.67.181]) by avgw.vxserver.com (NAVGW 2.5.2.12) with SMTP id M2002120413354215558 for ; Wed, 04 Dec 2002 13:35:42 GMT Received: from Unknown [10.1.1.1] by disney.internal.ridgewaysystems.com - SurfControl E-mail Filter (4.5); Wednesday, 04 December 2002, 13:37:19 Received: by ridgeway.internal.ridgewaysystems.com with Internet Mail Service (5.5.2653.19) id ; Wed, 4 Dec 2002 13:36:55 -0000 Message-ID: <00533D13955AD411AF3800A0C9B4263994D87F@ridgeway.internal.ridgewaysystems.com> From: Phil Reynolds To: sip@ietf.org Date: Wed, 4 Dec 2002 13:36:47 -0000 Subject: RE: [Sip] B2BUA MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--=_NextPart_ST_13_37_19_Wednesday_December_04_2002_13645" X-Mailer: Internet Mail Service (5.5.2653.19) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , 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_ST_13_37_19_Wednesday_December_04_2002_13645 Content-Type: text/plain If a telephone switch crashes you loose all calls... The telecoms people are clever enough to have thought about that and build redundancy, fault tolerance and failover into their switches. Maybe some of us IP-telecoms people have thought of similar techniques for SIP intermediaries? -----Original Message----- From: Jiri Kuthan [mailto:jiri.kuthan@fokus.fraunhofer.de] Sent: 04 December 2002 12:32 To: Christian Huitema; Roy, Radhika R, ALASO; mbarnes@nortelnetworks.com Cc: dean.willis@softarmor.com; Juan-Carlos.Rojas@alcatel.fr; sip@ietf.org Subject: RE: [Sip] B2BUA [...snip...] I think there are more issues with B2BUA. A B2BUA's failure affects all current calls :-( -Jiri _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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_ST_13_37_19_Wednesday_December_04_2002_13645 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Sip] B2BUA

If a telephone switch crashes you loose all calls... = ; The telecoms people are clever enough to have thought about that and buil= d redundancy, fault tolerance and failover into their switches.

Maybe some of us IP-telecoms people have thought of simil= ar techniques for SIP intermediaries?

-----Original Message-----
From: Jiri Kuthan [mailto:jiri.kuthan@fokus.fraunhofer.de]
Sent: 04 December 2002 12:32
To: Christian Huitema; Roy, Radhika R, ALASO; mbarnes@no= rtelnetworks.com
Cc: dean.willis@softarmor.com; Juan-Carlos.Rojas@alcatel= =2Efr; sip@ietf.org
Subject: RE: [Sip] B2BUA

[...snip...]

I think there are more issues with B2BUA. A B2BUA's failu= re affects all current calls :-(

-Jiri

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listi= nfo/sip
This list is for NEW development of the core SIP Protoco= l
Use sip-implementors@cs.columbia.edu for questions on cu= rrent sip Use sipping@ietf.org for new developments on the application of s= ip

----=_NextPart_ST_13_37_19_Wednesday_December_04_2002_13645-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Wed Dec 4 09:29:50 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12855 for ; Wed, 4 Dec 2002 09:29:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB4EWCo20946 for sip-archive@odin.ietf.org; Wed, 4 Dec 2002 09:32:12 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4EVgv20893; Wed, 4 Dec 2002 09:31:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4EURv20805 for ; Wed, 4 Dec 2002 09:30:27 -0500 Received: from fox.iptel.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12733 for ; Wed, 4 Dec 2002 09:27:33 -0500 (EST) Received: from jku07.iptel.org (port-212-202-168-86.reverse.qdsl-home.de [212.202.168.86]) by fox.iptel.org (8.11.6/8.11.6) with ESMTP id gB4EUJ416126; Wed, 4 Dec 2002 15:30:19 +0100 Message-Id: <5.2.0.9.0.20021204145156.038f88f8@iptel.org> X-Sender: jiri@iptel.org (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 04 Dec 2002 15:16:25 +0100 To: Phil Reynolds , sip@ietf.org From: Jiri Kuthan Subject: RE: [Sip] B2BUA In-Reply-To: <00533D13955AD411AF3800A0C9B4263994D87F@ridgeway.internal.r idgewaysystems.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , I think a better strategy to design reliable IP networks is not to have stateful elements in the middle. It is sometimes not easy to achieve, but you don't need to solve the problem what happens when they fail. Besides that, all sort of middleboxes (B2BUA can IMHO be labeled as app-layer middlebox) have e2e security issues as pointed out by Christian, and are not free of scalability issues. I suggest you read RFC3234 -- it covers various issues middleboxes have, including failure handling. -Jiri At 02:36 PM 12/4/2002, Phil Reynolds wrote: >If a telephone switch crashes you loose all calls... The telecoms people are clever enough to have thought about that and build redundancy, fault tolerance and failover into their switches. > >Maybe some of us IP-telecoms people have thought of similar techniques for SIP intermediaries? > >-----Original Message----- >From: Jiri Kuthan [mailto:jiri.kuthan@fokus.fraunhofer.de] >Sent: 04 December 2002 12:32 >To: Christian Huitema; Roy, Radhika R, ALASO; mbarnes@nortelnetworks.com >Cc: dean.willis@softarmor.com; Juan-Carlos.Rojas@alcatel.fr; sip@ietf.org >Subject: RE: [Sip] B2BUA > >[...snip...] > >I think there are more issues with B2BUA. A B2BUA's failure affects all current calls :-( > >-Jiri > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Wed Dec 4 09:52:00 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14150 for ; Wed, 4 Dec 2002 09:52:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB4EsMB22500 for sip-archive@odin.ietf.org; Wed, 4 Dec 2002 09:54:22 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4Eocv22356; Wed, 4 Dec 2002 09:50:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4EnCv22289 for ; Wed, 4 Dec 2002 09:49:12 -0500 Received: from dyn-tx-arch-crash.dfw.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13929 for ; Wed, 4 Dec 2002 09:46:19 -0500 (EST) Received: from RjS.localdomain (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id gB4En9I22178 for ; Wed, 4 Dec 2002 08:49:09 -0600 From: Robert Sparks To: sip@ietf.org Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 04 Dec 2002 08:48:21 -0600 Message-Id: <1039013301.910.15.camel@RjS.localdomain> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: [Sip] Update to REFER Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I've just submitted http://www.nostrum.com/~rjsparks/draft-ietf-sip-refer-07.txt to the I-D repository. This revision incorporates feedback from the IESG. The changes were additions to the security considerations to discuss replay and cut-and-paste issues with the use of message/sipfrag, and a more detailed discussion of the risks associated with acting on a REFER request, particularly when the reference is to a non-SIP URI. The updated sections are 5.2 and 5.3. 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 mailnull@www1.ietf.org Wed Dec 4 10:20:49 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15939 for ; Wed, 4 Dec 2002 10:20:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB4FNBX24837 for sip-archive@odin.ietf.org; Wed, 4 Dec 2002 10:23:11 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4FMiv24759; Wed, 4 Dec 2002 10:22:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4FLLv24671 for ; Wed, 4 Dec 2002 10:21:21 -0500 Received: from ihemail1.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15798 for ; Wed, 4 Dec 2002 10:18:27 -0500 (EST) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by ihemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id gB4FLGY29918; Wed, 4 Dec 2002 10:21:16 -0500 (EST) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id JAA21186; Wed, 4 Dec 2002 09:21:14 -0600 (CST) Message-ID: <3DEE1D67.40000@lucent.com> Date: Wed, 04 Dec 2002 09:21:11 -0600 From: "Vijay K. Gurbani" Organization: Lucent Technologies, Inc./Bell Laboratories User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Padma Suresh CC: pete@tech-know-ware.com, sip@ietf.org Subject: Re: [Sip] B2BUA & Max-Forwards References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Padma Suresh wrote: > Vijay, > > You are right - > > A B2BUA needs to propagate some of the headers received in a > request/response to the other endpoint. Choosing which headers should be passed by a B2BUA and which not is exactly the ambiguity that we should AVOID, as I pointed out in my my response to the original poster. As others have expressed, we may try to taxonomize different types of B2BUAs, but each will have a different manner of handling the headers (depending on the application being realized by that particular B2BUA). An anonymizer B2BUA may change To, From, Contact, etc, for instance (and maintain internal state). A network-hiding B2BUA may scrap all Via headers coming in and only expose one Via header going out. The possibilities are endless. > Example: Require, Expires to name a few. This is because these > headers actually are relevant end to end. A B2BUA may decide to consume the Require and change the Expires header (maybe decrease its value) before sending it downstream, thus causing havoc with the expectations of the sending UAC. > However, some of the other headers like Contact should be set by the > B2BUA as itself. Likewise, I can imagine a B2BUA which rendezvous two users and steps out of subsequent signaling. Thus the Contact it sends to each of the users is that of the other peer. I would strongly *stay away* from prescribing which headers must be passed by a B2BUA and which must not. Regards, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Wed Dec 4 10:28:12 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16313 for ; Wed, 4 Dec 2002 10:28:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB4FUZT25221 for sip-archive@odin.ietf.org; Wed, 4 Dec 2002 10:30:35 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4FU9v25208; Wed, 4 Dec 2002 10:30:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4FTCv25152 for ; Wed, 4 Dec 2002 10:29:12 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16150 for ; Wed, 4 Dec 2002 10:26:18 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gB4FT7KV016532; Wed, 4 Dec 2002 16:29:07 +0100 (MET) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id YFXD21F4; Wed, 4 Dec 2002 16:29:07 +0100 Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.18]) by hendrix.lmf.ericsson.se (8.12.6/8.12.6/lmf-2.1-jcs) with ESMTP id gB4FT7u4001647; Wed, 4 Dec 2002 17:29:07 +0200 (EET) Message-ID: <3DEE1F40.7A950623@lmf.ericsson.se> Date: Wed, 04 Dec 2002 17:29:04 +0200 X-Sybari-Trust: 0b51dc91 ca231590 9763731a 00000138 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Juan-Carlos.Rojas@alcatel.fr CC: Hal Purdy , SIP Mailng List Subject: Re: [Sip] Re: B2BUA draft proposal References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Folks, If my UA receives a request, it uses an API to interact with me thru the GUI. Based on that, it will send a response. If my SIP-PSTN gateway receives a request, it uses ISUP, Q.931, or what have you to interact with me. Based on that, it will send a response. If my SIP entity happens to use SIP instead of an API or ISUP to interact with whoever of whatever it has to interact with, we call it "B2BUA". Based on that, it will send a response. That simple. Every time you drive your state machinery using SIP to communicate with another entity, you are a B2BUA. I do not think we need more definitions or examples. Things that can be done with a B2BUA depend on how innovative are the engineers in your company. We should not standardize them. About a draft with B2BUA examples, it might be valuable to point out at some stupid things you do not want to do because they may be harmful for the network... but providing an exhaustive list of B2BUA types is a terrible idea. Regards, Gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Wed Dec 4 11:08:21 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18995 for ; Wed, 4 Dec 2002 11:08:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB4GAiC29330 for sip-archive@odin.ietf.org; Wed, 4 Dec 2002 11:10:44 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4G6cv28401; Wed, 4 Dec 2002 11:06:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4FsGv27736 for ; Wed, 4 Dec 2002 10:54:16 -0500 Received: from mail2.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17912 for ; Wed, 4 Dec 2002 10:51:22 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id gB4Fr4XE012800 for ; Wed, 4 Dec 2002 10:53:04 -0500 (EST) Received: from dynamicsoft.com (63.113.46.52 [63.113.46.52]) by DYN-EXCH-001.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id W6F8GY56; Wed, 4 Dec 2002 10:54:10 -0500 Message-ID: <3DEE251A.5080306@dynamicsoft.com> Date: Wed, 04 Dec 2002 10:54:02 -0500 From: Anders Kristensen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sparks CC: sip@ietf.org Subject: Re: [Sip] Constructing the branch parameter at stateless proxies References: <1038933302.911.62.camel@RjS.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Robert, Sounds like a very good idea. One special case to consider is what happens if the request spirals back to the sending proxy (which presumably is stateful) -- either directly from the stateless proxy or via a number of other stateless proxies. The stateful proxy in this case will have a server transaction and a client transaction with the same id, which might confuse some implementations. This can be addressed simply by appending a fixed string to the branch value at each stateless proxy doing this trick, e.g. a single character. This guarantees the uniqueness properties required by rfc 3261, which seems desirable. Anders Robert Sparks wrote: > This list has seen a couple of requests to clarify the language in > RFC 3261 concerning how a stateless proxy creates a branch identifier. > > The current text requires uniqueness, dependency on route decision > affecting parameters and care to be sure that those parameters are > retransmission invariant. It goes on to recommend a hash over a > set of fields (this set has been the subject of the requests for > clarification). > > I think there's a much simpler solution. The purpose of this > branch parameter is to act as a transaction identifier. Who > cares about this identifier? Only the stateful elements at > each end of the transaction. Any stateless proxies between > these elements don't use that identifier in any of their > decisions, so I assert that it is not useful to change it > as it crosses the stateless proxy. > > I propose, then, that a stateless proxy simply copy > the branch parameter from the topmost Via header field > value it receives into the Via header field value it adds > to the request. > > I don't believe it matters that this parameter contain the > magic cookie. If it doesn't, the next stateful hop will use > the 2543-style transaction identifiers provided by the sending > stateful element. The stateless elements are by definition > transaction transparent. > > So - can anyone construct a scenario where this doesn't > function correctly? If not, we can remove several convoluted > paragraphs from the spec and replace them with a very simple > couple of sentences. > > 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Wed Dec 4 11:13:38 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19215 for ; Wed, 4 Dec 2002 11:13:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB4GG1E29584 for sip-archive@odin.ietf.org; Wed, 4 Dec 2002 11:16:01 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4GFCv29538; Wed, 4 Dec 2002 11:15:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4G6Uv28389 for ; Wed, 4 Dec 2002 11:06:30 -0500 Received: from dyn-tx-arch-crash.dfw.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18645 for ; Wed, 4 Dec 2002 11:03:35 -0500 (EST) Received: from RjS.localdomain (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id gB4G6PI23350; Wed, 4 Dec 2002 10:06:25 -0600 Subject: Re: [Sip] Constructing the branch parameter at stateless proxies From: Robert Sparks To: Anders Kristensen Cc: sip@ietf.org In-Reply-To: <3DEE251A.5080306@dynamicsoft.com> References: <1038933302.911.62.camel@RjS.localdomain> <3DEE251A.5080306@dynamicsoft.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 04 Dec 2002 10:05:36 -0600 Message-Id: <1039017937.910.76.camel@RjS.localdomain> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Wed, 2002-12-04 at 09:54, Anders Kristensen wrote: > Hi Robert, > > Sounds like a very good idea. One special case to consider is what > happens if the request spirals back to the sending proxy (which > presumably is stateful) -- either directly from the stateless proxy or > via a number of other stateless proxies. The stateful proxy in this > case will have a server transaction and a client transaction with the > same id, which might confuse some implementations. This is no different from the same proxy spiraling directly to itself is it? > > This can be addressed simply by appending a fixed string to the branch > value at each stateless proxy doing this trick, e.g. a single character. > This guarantees the uniqueness properties required by rfc 3261, which > seems desirable. There are several things we could do here - append the count of present via header fields for example to make sure you get different values as you spiral through the stateless elements, etc. I don't think any of this is necessary though - the stateless elements are supposed to be transaction invisible. If they _can_ do something that botches the transaction, we've got a weak spot in the protocol. I propose that preserving the transaction identifier provided by the stateful element is exactly the right thing to do, and that any mucking with it brings nothing good to the table, and has the potential to bring harm. > > Anders > > > Robert Sparks wrote: > > This list has seen a couple of requests to clarify the language in > > RFC 3261 concerning how a stateless proxy creates a branch identifier. > > > > The current text requires uniqueness, dependency on route decision > > affecting parameters and care to be sure that those parameters are > > retransmission invariant. It goes on to recommend a hash over a > > set of fields (this set has been the subject of the requests for > > clarification). > > > > I think there's a much simpler solution. The purpose of this > > branch parameter is to act as a transaction identifier. Who > > cares about this identifier? Only the stateful elements at > > each end of the transaction. Any stateless proxies between > > these elements don't use that identifier in any of their > > decisions, so I assert that it is not useful to change it > > as it crosses the stateless proxy. > > > > I propose, then, that a stateless proxy simply copy > > the branch parameter from the topmost Via header field > > value it receives into the Via header field value it adds > > to the request. > > > > I don't believe it matters that this parameter contain the > > magic cookie. If it doesn't, the next stateful hop will use > > the 2543-style transaction identifiers provided by the sending > > stateful element. The stateless elements are by definition > > transaction transparent. > > > > So - can anyone construct a scenario where this doesn't > > function correctly? If not, we can remove several convoluted > > paragraphs from the spec and replace them with a very simple > > couple of sentences. > > > > 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Wed Dec 4 11:17:19 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19356 for ; Wed, 4 Dec 2002 11:17:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB4GJg629767 for sip-archive@odin.ietf.org; Wed, 4 Dec 2002 11:19:42 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4GIpv29736; Wed, 4 Dec 2002 11:18:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4GC6v29381 for ; Wed, 4 Dec 2002 11:12:06 -0500 Received: from mail2.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19040 for ; Wed, 4 Dec 2002 11:09:12 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id gB4GAtXE012955 for ; Wed, 4 Dec 2002 11:10:55 -0500 (EST) Received: from dynamicsoft.com (63.113.46.52 [63.113.46.52]) by DYN-EXCH-001.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id W6F8GY79; Wed, 4 Dec 2002 11:12:01 -0500 Message-ID: <3DEE294A.9080806@dynamicsoft.com> Date: Wed, 04 Dec 2002 11:11:54 -0500 From: Anders Kristensen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sparks CC: sip@ietf.org Subject: Re: [Sip] Constructing the branch parameter at stateless proxies References: <1038933302.911.62.camel@RjS.localdomain> <3DEE251A.5080306@dynamicsoft.com> <1039017937.910.76.camel@RjS.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Robert Sparks wrote: > On Wed, 2002-12-04 at 09:54, Anders Kristensen wrote: > >>Hi Robert, >> >>Sounds like a very good idea. One special case to consider is what >>happens if the request spirals back to the sending proxy (which >>presumably is stateful) -- either directly from the stateless proxy or >>via a number of other stateless proxies. The stateful proxy in this >>case will have a server transaction and a client transaction with the >>same id, which might confuse some implementations. > > > This is no different from the same proxy spiraling directly to itself > is it? Well, it's different in that it is NOT spiraling directly to itself and so is currently guaranteed to see a different branch ID in a spiralled request. It may be the case that noone depends on this but who knows? > > >>This can be addressed simply by appending a fixed string to the branch >>value at each stateless proxy doing this trick, e.g. a single character. >>This guarantees the uniqueness properties required by rfc 3261, which >>seems desirable. > > > There are several things we could do here - append the count of present > via header fields for example to make sure you get different values as > you spiral through the stateless elements, etc. I don't think any of > this is necessary though - the stateless elements are supposed to be > transaction invisible. If they _can_ do something that botches the > transaction, we've got a weak spot in the protocol. I propose that > preserving the transaction identifier provided by the stateful element > is exactly the right thing to do, and that any mucking with it brings > nothing good to the table, and has the potential to bring harm. Like what? Anders _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Wed Dec 4 11:42:58 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20820 for ; Wed, 4 Dec 2002 11:42:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB4GjLE32572 for sip-archive@odin.ietf.org; Wed, 4 Dec 2002 11:45:21 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4GZMv31302; Wed, 4 Dec 2002 11:35:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4GYhv31209 for ; Wed, 4 Dec 2002 11:34:43 -0500 Received: from dyn-tx-arch-crash.dfw.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20280 for ; Wed, 4 Dec 2002 11:31:49 -0500 (EST) Received: from RjS.localdomain (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id gB4GYcI23723; Wed, 4 Dec 2002 10:34:38 -0600 Subject: Re: [Sip] Constructing the branch parameter at stateless proxies From: Robert Sparks To: Anders Kristensen Cc: sip@ietf.org In-Reply-To: <3DEE294A.9080806@dynamicsoft.com> References: <1038933302.911.62.camel@RjS.localdomain> <3DEE251A.5080306@dynamicsoft.com> <1039017937.910.76.camel@RjS.localdomain> <3DEE294A.9080806@dynamicsoft.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 04 Dec 2002 10:33:50 -0600 Message-Id: <1039019630.910.132.camel@RjS.localdomain> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Wed, 2002-12-04 at 10:11, Anders Kristensen wrote: > > > Robert Sparks wrote: > > On Wed, 2002-12-04 at 09:54, Anders Kristensen wrote: > > > >>Hi Robert, > >> > >>Sounds like a very good idea. One special case to consider is what > >>happens if the request spirals back to the sending proxy (which > >>presumably is stateful) -- either directly from the stateless proxy or > >>via a number of other stateless proxies. The stateful proxy in this > >>case will have a server transaction and a client transaction with the > >>same id, which might confuse some implementations. > > > > > > This is no different from the same proxy spiraling directly to itself > > is it? > > Well, it's different in that it is NOT spiraling directly to itself and > so is currently guaranteed to see a different branch ID in a spiralled > request. It may be the case that noone depends on this but who knows? Ok - so an implementation _may_ have gone to some effort to ensure that it wasn't sending a message to itself and is counting on not seeing the same transaction identifier come back to it. Not a choice I would recommend, but I can see how someone might have made it. We could avoid this with the suffix mechanism you suggest, or we could add an admonishment to the spec to tell systems to be prepared to have their transaction ID come back. I'd rather do the second. > > > > > > >>This can be addressed simply by appending a fixed string to the branch > >>value at each stateless proxy doing this trick, e.g. a single character. > >>This guarantees the uniqueness properties required by rfc 3261, which > >>seems desirable. > > > > > > There are several things we could do here - append the count of present > > via header fields for example to make sure you get different values as > > you spiral through the stateless elements, etc. I don't think any of > > this is necessary though - the stateless elements are supposed to be > > transaction invisible. If they _can_ do something that botches the > > transaction, we've got a weak spot in the protocol. I propose that > > preserving the transaction identifier provided by the stateful element > > is exactly the right thing to do, and that any mucking with it brings > > nothing good to the table, and has the potential to bring harm. > > Like what? Well, nothing earth-shattering. Right now, just an increased probability that implementation error will lead to protocol failure. Its hard to get this right, and we can greatly simplify it. My growing distaste for what the stateless proxies are currently doing comes from seeing it somewhat like a NAT. The transaction is really between the two stateful elements reguardless of how many stateless elements lie between. Right now, the stateless elements are "translating" the transaction identifier as the message goes through. We haven't identified anything in the protocol that breaks as long as they do this consistently, but I haven't been able to identify any benefit to the behavior. Now I'll go out on a limb. In the future, we might want as part of diagnostics, error recovery, or some similar function, to be able to refer to the transaction by its identifier. It would be very nice if that identifier were the same at the stateful elements on each end of the transaction. > > Anders _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Wed Dec 4 11:49:29 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21375 for ; Wed, 4 Dec 2002 11:49:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB4GprN00446 for sip-archive@odin.ietf.org; Wed, 4 Dec 2002 11:51:53 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4GpJv00423; Wed, 4 Dec 2002 11:51:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4Golv00383 for ; Wed, 4 Dec 2002 11:50:47 -0500 Received: from hotmail.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21262 for ; Wed, 4 Dec 2002 11:47:52 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 4 Dec 2002 08:50:42 -0800 Received: from 12.234.188.124 by lw7fd.law7.hotmail.msn.com with HTTP; Wed, 04 Dec 2002 16:50:42 GMT X-Originating-IP: [12.234.188.124] From: "Padma Suresh" To: vkg@lucent.com Cc: pete@tech-know-ware.com, sip@ietf.org Subject: Re: [Sip] B2BUA & Max-Forwards Date: Wed, 04 Dec 2002 16:50:42 +0000 Mime-Version: 1.0 Content-Type: text/html Message-ID: X-OriginalArrivalTime: 04 Dec 2002 16:50:42.0420 (UTC) FILETIME=[484D3340:01C29BB5] Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: ,

A B2BUA is an intermediate network element and MUST maintain the expectations of the endpoints involved in the session.

Not forwarding the Require or Expires headers (and some more) would break the above which would not be quite acceptable.

However, yes, the B2BUA can choose to step out of the signalling path by setting the contact header to the appropriate endpoint.

Vijay I agree that the ambiguity of choosing which header to pass on and which not, could be well avoided.

Regards

Padma

>From: "Vijay K. Gurbani"
>To: Padma Suresh
>CC: pete@tech-know-ware.com, sip@ietf.org
>Subject: Re: [Sip] B2BUA & Max-Forwards
>Date: Wed, 04 Dec 2002 09:21:11 -0600
>
>Padma Suresh wrote:
>>Vijay,
>>
>> You are right -
>>
>> A B2BUA needs to propagate some of the headers received in a
>>request/response to the other endpoint.
>
>Choosing which headers should be passed by a B2BUA and which not is
>exactly the ambiguity that we should AVOID, as I pointed out in my
>my response to the original poster. As others have expressed, we
>may
>try to taxonomize different types of B2BUAs, but each will have a
>different manner of handling the headers (depending on the
>application
>being realized by that particular B2BUA).
>
>An anonymizer B2BUA may change To, From, Contact, etc, for instance
>(and
>maintain internal state). A network-hiding B2BUA may scrap all Via
>headers coming in and only expose one Via header going out. The
>possibilities are endless.
>
>> Example: Require, Expires to name a few. This is because these
>>headers actually are relevant end to end.
>
>A B2BUA may decide to consume the Require and change the Expires
>header
>(maybe decrease its value) before sending it downstream, thus
>causing
>havoc with the expectations of the sending UAC.
>
>> However, some of the other headers like Contact should be set
>>by the B2BUA as itself.
>
>Likewise, I can imagine a B2BUA which rendezvous two users and steps
>out of subsequent signaling. Thus the Contact it sends to each of
>the users is that of the other peer.
>
>I would strongly *stay away* from prescribing which headers must be
>passed by a B2BUA and which must not.
>
>Regards,
>
>- vijay
>--
>Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org}
>Wireless Networks Group/Internet Software and Services
>Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm
>6G-440
>Naperville, Illinois 60566 Voice: +1 630 224 0216
>
>_______________________________________________
>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP Protocol
>Use sip-implementors@cs.columbia.edu for questions on current sip
>Use sipping@ietf.org for new developments on the application of sip

Tired of spam? Get advanced junk mail protection with MSN 8. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Wed Dec 4 13:21:21 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26641 for ; Wed, 4 Dec 2002 13:21:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB4INif09077 for sip-archive@odin.ietf.org; Wed, 4 Dec 2002 13:23:44 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4INCv09018; Wed, 4 Dec 2002 13:23:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4IL2v08914 for ; Wed, 4 Dec 2002 13:21:02 -0500 Received: from fox.iptel.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26522 for ; Wed, 4 Dec 2002 13:18:07 -0500 (EST) Received: from jku07.iptel.org (port-212-202-171-41.reverse.qdsl-home.de [212.202.171.41]) by fox.iptel.org (8.11.6/8.11.6) with ESMTP id gB4IKo417790; Wed, 4 Dec 2002 19:20:50 +0100 Message-Id: <5.2.0.9.0.20021204191223.00b7ba50@iptel.org> X-Sender: jiri@iptel.org (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 04 Dec 2002 19:18:31 +0100 To: Kedar Patil , Phil Reynolds From: Jiri Kuthan Subject: RE: [Sip] B2BUA Cc: sip@ietf.org In-Reply-To: <4B9386E83999D411997100508BAF206A07C7B647@stamail.telecom.s na.samsung.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , REGISTER does not create call state, that's it. If you create call state with INVITE, the B2BUA will keep it until the call is gone or a failure occurs. -Jiri At 06:14 PM 12/4/2002, Kedar Patil wrote: >BtoBUA need not always be call stateful. >e.g. a SIP REGISTER request reaches a BtoBUA, >it sends a new request to appropriate Registrar >based on some local application specific >configuration. > >There isn't any network state here (except the >transaction state, like sip proxy). > >Pls. let me know, if you foresee any problem here. > >thanks, >= Kedar = _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Wed Dec 4 14:04:42 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28640 for ; Wed, 4 Dec 2002 14:04:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB4J75J11902 for sip-archive@odin.ietf.org; Wed, 4 Dec 2002 14:07:05 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4J6av11712; Wed, 4 Dec 2002 14:06:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4J5sv11681 for ; Wed, 4 Dec 2002 14:05:54 -0500 Received: from pmesmtp01.wcom.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28601 for ; Wed, 4 Dec 2002 14:02:59 -0500 (EST) Received: from pmismtp03.wcomnet.com ([166.38.62.38]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0H6L00HDWZML04@firewall.wcom.com> for sip@ietf.org; Wed, 04 Dec 2002 19:03:58 +0000 (GMT) Received: from pmismtp03.wcomnet.com by pmismtp03.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0H6L00H01ZLZDC@pmismtp03.wcomnet.com>; Wed, 04 Dec 2002 19:03:53 +0000 (GMT) Received: from hsinnreich2 ([166.35.136.36]) by pmismtp03.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0H6L00G3SZKFSL@pmismtp03.wcomnet.com>; Wed, 04 Dec 2002 19:02:40 +0000 (GMT) Date: Wed, 04 Dec 2002 13:02:38 -0600 From: Henry Sinnreich Subject: RE: [Sip] B2BUA In-reply-to: <00533D13955AD411AF3800A0C9B4263994D87F@ridgeway.internal.ridgewaysystems.com> To: "'Phil Reynolds'" , sip@ietf.org Message-id: <000901c29bc7$b762fc30$248823a6@hsinnreich2> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1097 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit >The telecoms people are clever enough to have thought >about that and build redundancy, fault tolerance and failover into their switches. This has proven unfortunately not to be the case on September 11 when telecom service failed for days, while Internet traffic continued smoothly. I suggest you to look at the central control model of the switch network versus the e2e architecture of the Internet. SIP enabled networks are also fully distributed and the e2e control principle maintained - that's why state in placed in SIP endpoints. I am not sure if a few words here can give full justice to the superior resilience of the Internet and to SIP enabled services,... Thanks, Henry -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Phil Reynolds Sent: Wednesday, December 04, 2002 7:37 AM To: sip@ietf.org Subject: RE: [Sip] B2BUA If a telephone switch crashes you loose all calls... The telecoms people are clever enough to have thought about that and build redundancy, fault tolerance and failover into their switches. Maybe some of us IP-telecoms people have thought of similar techniques for SIP intermediaries? -----Original Message----- From: Jiri Kuthan [mailto:jiri.kuthan@fokus.fraunhofer.de] Sent: 04 December 2002 12:32 To: Christian Huitema; Roy, Radhika R, ALASO; mbarnes@nortelnetworks.com Cc: dean.willis@softarmor.com; Juan-Carlos.Rojas@alcatel.fr; sip@ietf.org Subject: RE: [Sip] B2BUA [...snip...] I think there are more issues with B2BUA. A B2BUA's failure affects all current calls :-( -Jiri _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Wed Dec 4 15:04:07 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01542 for ; Wed, 4 Dec 2002 15:04:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB4K6V115662 for sip-archive@odin.ietf.org; Wed, 4 Dec 2002 15:06:31 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4K5pv15634; Wed, 4 Dec 2002 15:05:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4K4Pv15568 for ; Wed, 4 Dec 2002 15:04:25 -0500 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01485 for ; Wed, 4 Dec 2002 15:01:28 -0500 (EST) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB4K4IK0020190; Wed, 4 Dec 2002 12:04:18 -0800 (PST) Received: from fluffyw2k ([10.32.138.84]) by mira-sjc5-9.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with SMTP id DZK00816; Wed, 4 Dec 2002 12:04:38 -0800 (PST) From: "Cullen Jennings" To: "Phil Reynolds" , Subject: RE: [Sip] B2BUA & Max-Forwards Date: Wed, 4 Dec 2002 12:04:17 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0014_01C29B8D.44FE5D90" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-reply-to: <00533D13955AD411AF3800A0C9B4263994D87D@ridgeway.internal.ridgewaysystems.com> Importance: Normal Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0014_01C29B8D.44FE5D90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit RE: [Sip] B2BUA & Max-ForwardsI think the answer to what it is is fairly simple - it's not a proxy and it's not a B2BUA. And in some call flows, it will probably be called broken :-) Cullen -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Phil Reynolds Sent: Wednesday, December 04, 2002 1:37 AM To: sip@ietf.org Subject: RE: [Sip] B2BUA & Max-Forwards Now your back to restricting what I can and can't do in an intermediary. It can't be a B2BUA 'cos it doesn't need to honour require headers (the UA at the other end does that, if they were meant for my intermediary then they would be proxy-require?), and it can't be a proxy 'cos of the rules about not changing the body so what is it? It's not sanctioned by the RFC, yet id does an important and useful job. -----Original Message----- From: Adam Roach [mailto:adam@dynamicsoft.com] Sent: 04 December 2002 00:37 To: 'Padma Suresh'; vkg@lucent.com; pete@tech-know-ware.com Cc: sip@ietf.org Subject: RE: [Sip] B2BUA & Max-Forwards -----Original Message----- From: Padma Suresh [mailto:padma_suresh@hotmail.com] > A B2BUA needs to propagate some of the headers received in a > request/response to the other endpoint. Example: Require... No. As emphatically as possible: NO. This is completely wrong, and it appears to be a growing -- and dangerous -- misconception. A B2BUA cannot transparently pass Require through. It must understand and invoke the extension indicated. "The Require header field contains a list of option tags, described in Section 19.2. Each option tag defines a SIP extension that MUST be understood to process the request." A back to back user agent *is* a UAS, and *is* bound by this provision. Whether the UAC portion then turns around and imposes the same requirement on the UAS it contacts is a local decision. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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_000_0014_01C29B8D.44FE5D90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] B2BUA & Max-Forwards
I=20 think the answer to what it is is fairly simple - it's not a proxy and = it's not=20 a B2BUA.
 
And in=20 some call flows, it will probably be called broken :-) =
 
Cullen
 
 
-----Original Message-----
From: sip-admin@ietf.org = [mailto:sip-admin@ietf.org]On Behalf Of Phil = Reynolds
Sent:=20 Wednesday, December 04, 2002 1:37 AM
To:=20 sip@ietf.org
Subject: RE: [Sip] B2BUA &=20 Max-Forwards

Now your back to restricting what I can and can't do = in an=20 intermediary. It can't be a B2BUA 'cos it doesn't need to honour = require=20 headers (the UA at the other end does that, if they were meant for my=20 intermediary then they would be proxy-require?), and it can't be a = proxy 'cos=20 of the rules about not changing the body so what is it?

It's not sanctioned by the RFC, yet id does an = important and=20 useful job.

-----Original Message-----
From: Adam=20 Roach [mailto:adam@dynamicsoft.com]=20
Sent: 04 December 2002 00:37 =
To: 'Padma Suresh'; vkg@lucent.com; = pete@tech-know-ware.com=20
Cc: sip@ietf.org
Subject: = RE: [Sip]=20 B2BUA & Max-Forwards


-----Original Message-----
From: Padma=20 Suresh [mailto:padma_suresh@hotmail.com<= /A>]=20
 
> A B2BUA needs = to=20 propagate some of the headers received in a
>=20 request/response to the other endpoint. Example: Require... =

No. As emphatically as possible: NO. This is = completely wrong,=20 and it appears to be a growing -- and dangerous -- = misconception.

A B2BUA cannot transparently pass Require through. = It must=20 understand and invoke the extension indicated.

  "The Require header field contains a list of = option=20 tags, described in
   Section = 19.2. =20 Each option tag defines a SIP extension that MUST be
   understood to process the request."

A back to back user agent *is* a UAS, and *is* bound = by this=20 provision.

Whether the UAC portion then turns around and = imposes the same=20 requirement on the UAS it contacts is a local decision.

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

------=_NextPart_000_0014_01C29B8D.44FE5D90-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Wed Dec 4 15:40:02 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02725 for ; Wed, 4 Dec 2002 15:40:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB4KgRu18815 for sip-archive@odin.ietf.org; Wed, 4 Dec 2002 15:42:27 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4Kfmv18753; Wed, 4 Dec 2002 15:41:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4KeUv18696 for ; Wed, 4 Dec 2002 15:40:30 -0500 Received: from ihemail2.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02621 for ; Wed, 4 Dec 2002 15:37:34 -0500 (EST) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by ihemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id gB4KeOw10032; Wed, 4 Dec 2002 15:40:24 -0500 (EST) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id OAA01161; Wed, 4 Dec 2002 14:40:23 -0600 (CST) Message-ID: <3DEE6833.3030808@lucent.com> Date: Wed, 04 Dec 2002 14:40:19 -0600 From: "Vijay K. Gurbani" Organization: Lucent Technologies, Inc./Bell Laboratories User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kedar Patil CC: sip@ietf.org Subject: Re: [Sip] B2BUA & Max-Forwards References: <4B9386E83999D411997100508BAF206A07C7B646@stamail.telecom.sna.samsung.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Kedar Patil wrote: > This discussion raises one more doubt for me, pls. clarify. > > UA1------->BtoBUA---------->UA2 > > Is the BtoBUA a SIP endpoint from UA1's point of view? In other > words, are the the "Require:" etc end-to-end headers sent by UA1, > meant for B2BUA or UA2? As Adam pointed out in an earlier email in this thread, "A B2BUA cannot transparently pass Require through. It must understand and invoke the extension indicated." (rfc3261 says the same; see sec 20.32) Having said that, I realize that there exist what are called transparent B2BUAs that pass e2e headers through without operating on them. Time and experience will decide if they are a boon or a bane; right now my personal feeling is that a proxy is a far more better tool than a transparent B2BUA. It plays by the rules and is unlikely to break e2e feature support. > Is the UAS part in in BtoBUA is bound by the definition and rules > in 3261? Yes, it is a UA. - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Wed Dec 4 15:44:00 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02956 for ; Wed, 4 Dec 2002 15:44:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB4KkPF19013 for sip-archive@odin.ietf.org; Wed, 4 Dec 2002 15:46:25 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4Kk7v19004; Wed, 4 Dec 2002 15:46:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4KjXv18981 for ; Wed, 4 Dec 2002 15:45:33 -0500 Received: from mail2.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02847 for ; Wed, 4 Dec 2002 15:42:37 -0500 (EST) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id gB4KiJXE014326; Wed, 4 Dec 2002 15:44:20 -0500 (EST) Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 4 Dec 2002 14:45:27 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A64377@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Phil Reynolds'" , sip@ietf.org Subject: RE: [Sip] B2BUA & Max-Forwards Date: Wed, 4 Dec 2002 14:45:26 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , -----Original Message----- From: Phil Reynolds [mailto:preynolds@ridgewaysystems.com] > Now your back to restricting what I can and can't do in an > intermediary. It can't be a B2BUA 'cos it doesn't need to > honour require headers (the UA at the other end does that, > if they were meant for my intermediary then they would be > proxy-require?), and it can't be a proxy 'cos of the rules > about not changing the body so what is it? Broken. The restrictions placed on nodes by 3261 (which I'm merely reiterating, not imposing) aren't an authoritarian attempt at unnecessary proscription. They serve a purpose. I'll describe one of the (several) purposes that applies to the situation you propose. One of the things that UAs are required to be able to do is sign and/or encrypt the bodies and/or some subset of the headers to ensure confidentiality and/or integrity. The protocol places restrictions on various nodes to ensure that this can be done. Your box is broken precisely because it interferes with these abilities (or, more precisely, these abilities interfere with it). /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Wed Dec 4 15:48:08 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03085 for ; Wed, 4 Dec 2002 15:48:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB4KoX919237 for sip-archive@odin.ietf.org; Wed, 4 Dec 2002 15:50:33 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4Ko9v19210; Wed, 4 Dec 2002 15:50:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4Knbv19161 for ; Wed, 4 Dec 2002 15:49:37 -0500 Received: from mail2.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03033 for ; Wed, 4 Dec 2002 15:46:41 -0500 (EST) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id gB4KmMXE014345; Wed, 4 Dec 2002 15:48:23 -0500 (EST) Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 4 Dec 2002 14:49:30 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A64378@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Kedar Patil'" , Adam Roach , "'Padma Suresh'" , vkg@lucent.com, pete@tech-know-ware.com Cc: sip@ietf.org Subject: RE: [Sip] B2BUA & Max-Forwards Date: Wed, 4 Dec 2002 14:49:29 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , -----Original Message----- From: Kedar Patil [mailto:kpatil@sta.samsung.com] > This discussion raises one more doubt for me, pls. clarify. > > UA1------->BtoBUA---------->UA2 > > Is the BtoBUA a SIP endpoint from UA1's point of view? Yes. > In other > words, are the the "Require:" etc end-to-end headers sent by UA1, > meant for B2BUA or UA2? B2BUA. > Is the UAS part in in BtoBUA is bound by the definition and rules > in 3261? Yes. I'll revise your drawing to more clearly show what is going on here. UAC(a)--->UAS(b)===[application logic here]===UAC(b)--->UAS(c) /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Wed Dec 4 15:54:14 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03335 for ; Wed, 4 Dec 2002 15:54:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB4Kudp19434 for sip-archive@odin.ietf.org; Wed, 4 Dec 2002 15:56:39 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4KuCv19415; Wed, 4 Dec 2002 15:56:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4KtOv19378 for ; Wed, 4 Dec 2002 15:55:24 -0500 Received: from mail2.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03238 for ; Wed, 4 Dec 2002 15:52:28 -0500 (EST) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id gB4Ks8XE014369; Wed, 4 Dec 2002 15:54:09 -0500 (EST) Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 4 Dec 2002 14:55:16 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A64379@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Juan-Carlos.Rojas@alcatel.fr'" , Adam Roach Cc: "'Padma Suresh'" , vkg@lucent.com, pete@tech-know-ware.com, sip@ietf.org Subject: RE: [Sip] B2BUA & Max-Forwards Date: Wed, 4 Dec 2002 14:55:15 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Unless you were merely trying to agree at length with the final paragraph of my previous message, I'm afraid that you missed my point rather broadly. I'll reiterate the main point concisely: a B2BUA is a UAS attached to a UAC by application logic. Read that carefully: Part of a B2BUA is a UAS. That UAS is bound by RFC 3261 to certain behaviors. One of those behaviors is honoring "Require" headers. /a > -----Original Message----- > From: Juan-Carlos.Rojas@alcatel.fr > [mailto:Juan-Carlos.Rojas@alcatel.fr] > Sent: Wednesday, December 04, 2002 1:51 > To: Adam Roach > Cc: 'Padma Suresh'; vkg@lucent.com; pete@tech-know-ware.com; > sip@ietf.org > Subject: RE: [Sip] B2BUA & Max-Forwards > > > > Hello, > > As it was already stated in this discusion thread, a B2BUA is an > *application* linking several UAs > As such, the behaviour of a B2BUA cannot be standardised. > > Therefore, one cannot say that "A B2BUA needs to propagate some of the > headers received". > However, you can say that the application "x" behaves as a > B2BUA, and that > the application "x" "needs to propagate" the a-header or the > b-header etc. > for the needs of the application. This is the choice of the > application, > that's all. > > Best regards > Juan Carlos > > > > > > Adam Roach @ietf.org on 04/12/2002 01:36:50 > > Sent by: sip-admin@ietf.org > > > To: "'Padma Suresh'" , vkg@lucent.com, > pete@tech-know-ware.com > cc: sip@ietf.org > Subject: RE: [Sip] B2BUA & Max-Forwards > > > -----Original Message----- > From: Padma Suresh [mailto:padma_suresh@hotmail.com] > > > A B2BUA needs to propagate some of the headers received in a > > request/response to the other endpoint. Example: Require... > > No. As emphatically as possible: NO. This is completely wrong, > and it appears to be a growing -- and dangerous -- misconception. > > A B2BUA cannot transparently pass Require through. It must > understand and invoke the extension indicated. > > "The Require header field contains a list of option tags, > described in > Section 19.2. Each option tag defines a SIP extension that MUST be > understood to process the request." > > A back to back user agent *is* a UAS, and *is* bound by this > provision. > > Whether the UAC portion then turns around and imposes the same > requirement on the UAS it contacts is a local decision. > > /a > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Wed Dec 4 16:02:55 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03565 for ; Wed, 4 Dec 2002 16:02:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB4L5KS19713 for sip-archive@odin.ietf.org; Wed, 4 Dec 2002 16:05:20 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4L4Bv19673; Wed, 4 Dec 2002 16:04:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4L3Fv19644 for ; Wed, 4 Dec 2002 16:03:15 -0500 Received: from mail2.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03503 for ; Wed, 4 Dec 2002 16:00:19 -0500 (EST) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id gB4L1xXE014416; Wed, 4 Dec 2002 16:02:00 -0500 (EST) Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 4 Dec 2002 15:03:07 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A6437A@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Vijay K. Gurbani'" , Kedar Patil Cc: sip@ietf.org Subject: RE: [Sip] B2BUA & Max-Forwards Date: Wed, 4 Dec 2002 15:03:06 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , > -----Original Message----- > From: Vijay K. Gurbani [mailto:vkg@lucent.com] > > I realize that there exist what are called > transparent B2BUAs that pass e2e headers through > without operating on them. And the point that I'm trying to make is that such network elements are out of spec. The will run into interoperability problems with compliant nodes. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Wed Dec 4 16:33:54 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04876 for ; Wed, 4 Dec 2002 16:33:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB4LaKo21530 for sip-archive@odin.ietf.org; Wed, 4 Dec 2002 16:36:20 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4LZev21480; Wed, 4 Dec 2002 16:35:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4LYhv21420 for ; Wed, 4 Dec 2002 16:34:43 -0500 Received: from mail2.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04752 for ; Wed, 4 Dec 2002 16:31:47 -0500 (EST) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id gB4LXJXE014580; Wed, 4 Dec 2002 16:33:19 -0500 (EST) Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 4 Dec 2002 15:34:23 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A6437D@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'William Marshall'" , dean.willis@softarmor.com Cc: mbarnes@nortelnetworks.com, Juan-Carlos.Rojas@alcatel.fr, sip@ietf.org Subject: RE: [Sip] B2BUA Date: Wed, 4 Dec 2002 15:34:22 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , > -----Original Message----- > From: William Marshall [mailto:wtm@research.att.com] > > What is built instead are boxes that are close to the definition of > proxies, but not quite. They serve a real need in the market (and > vendors tend to build what sells). But due to various details, like > looking at the attachment (a proxy-no-no) to open pinholes in > the firewall, > they don't strictly qualify as proxies. > > Saying there are only two types of boxes, proxies and devilish-B2BUAs, > ignores the reality. Right. And no one from the ISOC, IAB, IESG, or the working group is going to show up with tanks and guns to force you to not build these. However, there are demonstratable cases in which these nodes break when communicating with other nodes that follow 3261 to the letter. Our goal is not to make protocols that kinda interoperate under some circumstances... sorta... maybe. Our goal is to make protocols that interoperate. Period. So, while you might build, deploy, and sell such boxes that fail to interoperate with fully compliant nodes under certain circumstances (encrypted SDP, in your example), that does NOT mean that condoning such partially-interoperable behavior would be appropriate. In fact, the illusion of implied interoperability that would result from codifying such partially-interoperable nodes would be dishonest. Doing so would damage the credibility of the protocols generated by the IETF in general, and the SIP-related working groups in particular. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Wed Dec 4 17:00:28 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06240 for ; Wed, 4 Dec 2002 17:00:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB4M2sG23753 for sip-archive@odin.ietf.org; Wed, 4 Dec 2002 17:02:54 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4M2Uv23718; Wed, 4 Dec 2002 17:02:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4M16v23593 for ; Wed, 4 Dec 2002 17:01:06 -0500 Received: from willow.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06134 for ; Wed, 4 Dec 2002 16:58:09 -0500 (EST) Received: from cypress.neustar.com (stih650a-eth-s1p2c0.va.neustar.com [209.173.53.81]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id gB4M0xi28459 for ; Wed, 4 Dec 2002 22:00:59 GMT Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by cypress.neustar.com (8.11.6/8.11.6) with ESMTP id gB4M0sx21057 for ; Wed, 4 Dec 2002 22:00:54 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Wed, 4 Dec 2002 17:02:22 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA815EB43D@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'sip@ietf.org'" Date: Wed, 4 Dec 2002 17:02:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] Discuss on service discovery Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , The thread on the Discuss for service discovery related to the requirement for S/MIME seems to have petered out - it would be nice if we could come to a conclusion and go forward with the draft. From my own reading of the thread, I think the predominant consensus was that requiring S/MIME for registrars (in the context of architectures in which hop-by-hop security is unavailable or insufficient) was reasonable. There were concerns that this was a broader issue than just service discovery - but ultimately, I don't think that argues against the suggested change from the IESG, it merely argues that this fix may have even broader utility. Can we go forward with the requested fix? Jon Peterson NeuStar, Inc. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Wed Dec 4 17:37:05 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07627 for ; Wed, 4 Dec 2002 17:37:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB4MdVR26691 for sip-archive@odin.ietf.org; Wed, 4 Dec 2002 17:39:31 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4Mcwv26654; Wed, 4 Dec 2002 17:38:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4MbGv26376 for ; Wed, 4 Dec 2002 17:37:16 -0500 Received: from gamma.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07439; Wed, 4 Dec 2002 17:34:17 -0500 (EST) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id gB4Mb8D00614; Wed, 4 Dec 2002 14:37:08 -0800 (PST) Message-Id: <200212042237.gB4Mb8D00614@gamma.isi.edu> To: IETF-Announce: ; Cc: rfc-editor@rfc-editor.org, sip@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 04 Dec 2002 14:37:08 -0800 Subject: [Sip] RFC 3323 on A Privacy Mechanism for the Session Initiation Protocol (SIP) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3323 Title: A Privacy Mechanism for the Session Initiation Protocol (SIP) Author(s): J. Peterson Status: Standards Track Date: November 2002 Mailbox: jon.peterson@neustar.biz Pages: 22 Characters: 54116 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-sip-privacy-general-01.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3323.txt This document defines new mechanisms for the Session Initiation Protocol (SIP) in support of privacy. Specifically, guidelines are provided for the creation of messages that do not divulge personal identity information. A new "privacy service" logical role for intermediaries is defined to answer some privacy requirements that user agents cannot satisfy themselves. Finally, means are presented by which a user can request particular functions from a privacy service. This document is a product of the Session Initiation Proposal Investigation 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.echo 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: <021204142838.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3323 --OtherAccess Content-Type: Message/External-body; name="rfc3323.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <021204142838.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Wed Dec 4 17:41:21 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07774 for ; Wed, 4 Dec 2002 17:41:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB4MhmS26930 for sip-archive@odin.ietf.org; Wed, 4 Dec 2002 17:43:48 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4Me6v26768; Wed, 4 Dec 2002 17:40:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4MdQv26683 for ; Wed, 4 Dec 2002 17:39:26 -0500 Received: from gamma.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07595; Wed, 4 Dec 2002 17:36:27 -0500 (EST) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id gB4MdHD01844; Wed, 4 Dec 2002 14:39:17 -0800 (PST) Message-Id: <200212042239.gB4MdHD01844@gamma.isi.edu> To: IETF-Announce: ; Cc: rfc-editor@rfc-editor.org, sip@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 04 Dec 2002 14:39:17 -0800 Subject: [Sip] RFC 3324 on Short Term Requirements for Network Asserted Identity Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3324 Title: Short Term Requirements for Network Asserted Identity Author(s): M. Watson Status: Informational Date: November 2002 Mailbox: mwatson@nortelnetworks.com Pages: 11 Characters: 21964 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-sipping-nai-reqs-02.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3324.txt A Network Asserted Identity is an identity initially derived by a Session Initiation Protocol (SIP) network intermediary as a result of an authentication process. This document describes short term requirements for the exchange of Network Asserted Identities within networks of securely interconnected trusted nodes and to User Agents securely connected to such networks. There is no requirement for identities asserted by a UA in a SIP message to be anything other than the user's desired alias. This document is a product of the Session Initiation Proposal Investigation Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. 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.echo 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: <021204143733.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3324 --OtherAccess Content-Type: Message/External-body; name="rfc3324.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <021204143733.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Wed Dec 4 17:41:31 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07790 for ; Wed, 4 Dec 2002 17:41:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB4MhvR26950 for sip-archive@odin.ietf.org; Wed, 4 Dec 2002 17:43:57 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4MhNv26908; Wed, 4 Dec 2002 17:43:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4MgOv26880 for ; Wed, 4 Dec 2002 17:42:24 -0500 Received: from gamma.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07704; Wed, 4 Dec 2002 17:39:21 -0500 (EST) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id gB4MgCD02478; Wed, 4 Dec 2002 14:42:12 -0800 (PST) Message-Id: <200212042242.gB4MgCD02478@gamma.isi.edu> To: IETF-Announce: ; Cc: rfc-editor@rfc-editor.org, sip@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 04 Dec 2002 14:42:12 -0800 Subject: [Sip] RFC 3325 on Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3325 Title: Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks Author(s): C. Jennings, J. Peterson, M. Watson Status: Informational Date: November 2002 Mailbox: fluffy@cisco.com, Jon.Peterson@NeuStar.biz, mwatson@nortelnetworks.com Pages: 18 Characters: 36170 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-sip-asserted-identity-02.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3325.txt This document describes private extensions to the Session Initiation Protocol (SIP) that enable a network of trusted SIP servers to assert the identity of authenticated users, and the application of existing privacy mechanisms to the identity problem. The use of these extensions is only applicable inside an administrative domain with previously agreed-upon policies for generation, transport and usage of such information. This document does NOT offer a general privacy or identity model suitable for use between different trust domains, or use in the Internet at large. This document is a product of the Session Initiation Protocol Working Group and the Session Initiation Proposal Investigation Working Groups of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. 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.echo 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: <021204143939.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3325 --OtherAccess Content-Type: Message/External-body; name="rfc3325.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <021204143939.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Wed Dec 4 17:42:57 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07899 for ; Wed, 4 Dec 2002 17:42:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB4MjOm27072 for sip-archive@odin.ietf.org; Wed, 4 Dec 2002 17:45:24 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4Mi7v27001; Wed, 4 Dec 2002 17:44:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4MhWv26921 for ; Wed, 4 Dec 2002 17:43:32 -0500 Received: from kcmso2.proxy.att.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07735 for ; Wed, 4 Dec 2002 17:40:34 -0500 (EST) Received: from attrh3i.attrh.att.com ([135.71.62.12]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id gB4LsxE7000259 for ; Wed, 4 Dec 2002 16:43:25 -0600 (CST) Received: from occlust04evs1.ugd.att.com (135.71.164.12) by attrh3i.attrh.att.com (6.5.019) id 3DDD63A10058FB36; Wed, 4 Dec 2002 17:43:24 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] B2BUA & Max-Forwards Date: Wed, 4 Dec 2002 17:43:12 -0500 Message-ID: <62DA45D4963FA747BA1B253E266760F904DAD270@OCCLUST04EVS1.ugd.att.com> Thread-Topic: [Sip] B2BUA & Max-Forwards Thread-Index: AcKb14zkzRHmsUlpT7y/yS7hXf5wUQADOXbw From: "Roy, Radhika R, ALASO" To: "Adam Roach" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gB4MhWv26922 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Adam: I would appreciate if you would clarify the following questions provided inline [RRR]. Radhika > Is the UAS part in in BtoBUA is bound by the definition and rules > in 3261? Yes. I'll revise your drawing to more clearly show what is going on here. UAC(a)--->UAS(b)===[application logic here]===UAC(b)--->UAS(c) /a [RRR] I like to know who has been the called party when UAC(a)) sent the INVITE message? Has it been UAS(b) or UAS(c)? [RRR] If the answer is UAS(c), the question is: Why the call has been routed to UAS(b) by UAC(a) in the first place? [RRR] If the answer is UAS(b), probably UAC(a) does not care. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Wed Dec 4 17:43:30 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07960 for ; Wed, 4 Dec 2002 17:43:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB4Mjua27101 for sip-archive@odin.ietf.org; Wed, 4 Dec 2002 17:45:56 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4Mj7v27057; Wed, 4 Dec 2002 17:45:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4Mivv27025 for ; Wed, 4 Dec 2002 17:44:57 -0500 Received: from mail2.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07832 for ; Wed, 4 Dec 2002 17:41:59 -0500 (EST) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id gB4MhgXE014957; Wed, 4 Dec 2002 17:43:42 -0500 (EST) Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 4 Dec 2002 16:44:49 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A6437F@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Peterson, Jon'" , "'sip@ietf.org'" Subject: RE: [Sip] Discuss on service discovery Date: Wed, 4 Dec 2002 16:44:49 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , ... > Can we go forward with the requested fix? In light of the conclusions of the previous discussions on the topic, I have no further objections. I would, however, like to see a bug opened against 3261 to address this issue so that the solution can eventually appear in a centralized place. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Wed Dec 4 17:45:08 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08013 for ; Wed, 4 Dec 2002 17:45:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB4MlZU27216 for sip-archive@odin.ietf.org; Wed, 4 Dec 2002 17:47:35 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4Ml5v27194; Wed, 4 Dec 2002 17:47:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4Mk5v27154 for ; Wed, 4 Dec 2002 17:46:05 -0500 Received: from willow.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07943 for ; Wed, 4 Dec 2002 17:43:07 -0500 (EST) Received: from cypress.neustar.com (stih650a-eth-s1p2c0.va.neustar.com [209.173.53.81]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id gB4Mjwi29437; Wed, 4 Dec 2002 22:45:58 GMT Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by cypress.neustar.com (8.11.6/8.11.6) with ESMTP id gB4Mjrx21529; Wed, 4 Dec 2002 22:45:53 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Wed, 4 Dec 2002 17:47:22 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA815EB440@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Adam Roach'" , "'sip@ietf.org'" Subject: RE: [Sip] Discuss on service discovery Date: Wed, 4 Dec 2002 17:47:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , I think that's quite reasonable. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Adam Roach [mailto:adam@dynamicsoft.com] > Sent: Wednesday, December 04, 2002 2:45 PM > To: 'Peterson, Jon'; 'sip@ietf.org' > Subject: RE: [Sip] Discuss on service discovery > > > ... > > Can we go forward with the requested fix? > > In light of the conclusions of the previous discussions on the > topic, I have no further objections. > > I would, however, like to see a bug opened against 3261 to > address this issue so that the solution can eventually appear > in a centralized place. > > /a > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Wed Dec 4 17:57:17 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08543 for ; Wed, 4 Dec 2002 17:57:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB4MxiO27683 for sip-archive@odin.ietf.org; Wed, 4 Dec 2002 17:59:44 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4MxHv27675; Wed, 4 Dec 2002 17:59:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4MwSv27654 for ; Wed, 4 Dec 2002 17:58:28 -0500 Received: from mail2.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08512 for ; Wed, 4 Dec 2002 17:55:31 -0500 (EST) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id gB4Mv8XE015058; Wed, 4 Dec 2002 17:57:11 -0500 (EST) Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 4 Dec 2002 16:58:15 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A64380@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Roy, Radhika R, ALASO'" , Adam Roach Cc: sip@ietf.org Subject: RE: [Sip] B2BUA & Max-Forwards Date: Wed, 4 Dec 2002 16:58:14 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , > UAC(a)--->UAS(b)===[application logic here]===UAC(b)--->UAS(c) > > [RRR] I like to know who has been the called party when > UAC(a)) sent the INVITE message? Has it been UAS(b) or UAS(c)? I'm going to first need to clarify your question. The question I will answer is: "If an INVITE is sent through the network described in this diagram, what is the value of the Request-URI when UAC(a) sends it?" The answer is: it depends. In general, yes, it will probably be either of UAS(b) or UAS(c). > [RRR] If the answer is UAS(c), the question is: Why the call > has been routed to UAS(b) by UAC(a) in the first place? The most obvious of several plausible answers is: UAC(a) has UAS(b) configured as a local outbound proxy. > [RRR] If the answer is UAS(b), probably UAC(a) does not care. About what? /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Wed Dec 4 18:36:51 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10420 for ; Wed, 4 Dec 2002 18:36:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB4NdGi30396 for sip-archive@odin.ietf.org; Wed, 4 Dec 2002 18:39:16 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4NcRv30359; Wed, 4 Dec 2002 18:38:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4NbKv30315 for ; Wed, 4 Dec 2002 18:37:20 -0500 Received: from host4.imagelinkusa.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10317 for ; Wed, 4 Dec 2002 18:34:24 -0500 (EST) Received: from packetiz by host4.imagelinkusa.net with local (Exim 3.36 #1) id 18Jj4r-0002H0-00 for sip@ietf.org; Wed, 04 Dec 2002 18:37:13 -0500 From: "Paul Long" To: sip@ietf.org Subject: RE: [Sip] B2BUA & Max-Forwards X-Mailer: NeoMail 1.25 X-IPAddress: 216.54.151.164 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Message-Id: Date: Wed, 04 Dec 2002 18:37:13 -0500 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host4.imagelinkusa.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [746 747] / [746 747] X-AntiAbuse: Sender Address Domain - host4.imagelinkusa.net Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Adam, FWIW, a B2BUA operates identically in this regard to an H.323 routing gatekeeper. The gatekeeper must contain H.323 endpoint functionality facing each of the two "real" endpoints with "application logic" in between the two functional endpoints, although this is not made explicit in any of the Recommendations. Vendors have wedged all sorts of applications in between these two virtual endpoints within the gatekeeper. Interestingly, some H.323 vendors have undergone the same initial naivete as some of the posters on this reflector. The bottom line is that you must fully terminate the connections on both sides and not simply pass everything or even selectively some things through and hope for the best. Paul > Unless you were merely trying to agree at length with the > final paragraph of my previous message, I'm afraid that > you missed my point rather broadly. > > I'll reiterate the main point concisely: a B2BUA is a UAS > attached to a UAC by application logic. > > Read that carefully: Part of a B2BUA is a UAS. > > That UAS is bound by RFC 3261 to certain behaviors. > > One of those behaviors is honoring "Require" headers. > > /a > > > -----Original Message----- > > From: Juan-Carlos.Rojas@alcatel.fr > > [mailto:Juan-Carlos.Rojas@alcatel.fr] > > Sent: Wednesday, December 04, 2002 1:51 > > To: Adam Roach > > Cc: 'Padma Suresh'; vkg@lucent.com; pete@tech-know-ware.com; > > sip@ietf.org > > Subject: RE: [Sip] B2BUA & Max-Forwards > > > > > > > > Hello, > > > > As it was already stated in this discusion thread, a B2BUA is an > > *application* linking several UAs > > As such, the behaviour of a B2BUA cannot be standardised. > > > > Therefore, one cannot say that "A B2BUA needs to propagate some of the > > headers received". > > However, you can say that the application "x" behaves as a > > B2BUA, and that > > the application "x" "needs to propagate" the a-header or the > > b-header etc. > > for the needs of the application. This is the choice of the > > application, > > that's all. > > > > Best regards > > Juan Carlos > > > > > > > > > > > > Adam Roach @ietf.org on 04/12/2002 01:36:50 > > > > Sent by: sip-admin@ietf.org > > > > > > To: "'Padma Suresh'" , vkg@lucent.com, > > pete@tech-know-ware.com > > cc: sip@ietf.org > > Subject: RE: [Sip] B2BUA & Max-Forwards > > > > > > -----Original Message----- > > From: Padma Suresh [mailto:padma_suresh@hotmail.com] > > > > > A B2BUA needs to propagate some of the headers received in a > > > request/response to the other endpoint. Example: Require... > > > > No. As emphatically as possible: NO. This is completely wrong, > > and it appears to be a growing -- and dangerous -- misconception. > > > > A B2BUA cannot transparently pass Require through. It must > > understand and invoke the extension indicated. > > > > "The Require header field contains a list of option tags, > > described in > > Section 19.2. Each option tag defines a SIP extension that MUST be > > understood to process the request." > > > > A back to back user agent *is* a UAS, and *is* bound by this > > provision. > > > > Whether the UAC portion then turns around and imposes the same > > requirement on the UAS it contacts is a local decision. > > > > /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Wed Dec 4 19:17:52 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11894 for ; Wed, 4 Dec 2002 19:17:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB50KHh32748 for sip-archive@odin.ietf.org; Wed, 4 Dec 2002 19:20:17 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB50Jjv32608; Wed, 4 Dec 2002 19:19:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB50Ggv32447 for ; Wed, 4 Dec 2002 19:16:42 -0500 Received: from hotmail.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11695 for ; Wed, 4 Dec 2002 19:13:45 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 4 Dec 2002 16:16:34 -0800 Received: from 12.146.131.5 by lw7fd.law7.hotmail.msn.com with HTTP; Thu, 05 Dec 2002 00:16:34 GMT X-Originating-IP: [12.146.131.5] From: "Padma Suresh" To: adam@dynamicsoft.com, rrroy@att.com Cc: sip@ietf.org Subject: RE: [Sip] B2BUA & Max-Forwards Date: Thu, 05 Dec 2002 00:16:34 +0000 Mime-Version: 1.0 Content-Type: text/html Message-ID: X-OriginalArrivalTime: 05 Dec 2002 00:16:34.0463 (UTC) FILETIME=[91C302F0:01C29BF3] Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: ,

For UAC (a) UAS (c) is the intended called party in the call. We have to define the intended party in a call when a B2BUA is involved. B2BUA IS an intermediate network element. It acts as some kind of a controller for a domain. It is not the called party in any call.

Regards

Padma

>From: Adam Roach
>To: "'Roy, Radhika R, ALASO'" , Adam Roach
>CC: sip@ietf.org
>Subject: RE: [Sip] B2BUA & Max-Forwards
>Date: Wed, 4 Dec 2002 16:58:14 -0600
>
> > UAC(a)--->UAS(b)===[application logic here]===UAC(b)--->UAS(c)
> >
> > [RRR] I like to know who has been the called party when
> > UAC(a)) sent the INVITE message? Has it been UAS(b) or UAS(c)?
>
>I'm going to first need to clarify your question.
>
>The question I will answer is: "If an INVITE is sent through the
>network described in this diagram, what is the value of the
>Request-URI when UAC(a) sends it?"
>
>The answer is: it depends. In general, yes, it will probably be
>either of UAS(b) or UAS(c).
>
> > [RRR] If the answer is UAS(c), the question is: Why the call
> > has been routed to UAS(b) by UAC(a) in the first place?
>
>The most obvious of several plausible answers is: UAC(a)
>has UAS(b) configured as a local outbound proxy.
>
> > [RRR] If the answer is UAS(b), probably UAC(a) does not care.
>
>About what?
>
>/a
>_______________________________________________
>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP Protocol
>Use sip-implementors@cs.columbia.edu for questions on current sip
>Use sipping@ietf.org for new developments on the application of sip

Add photos to your e-mail with MSN 8. Get 2 months FREE*. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Wed Dec 4 20:09:41 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13511 for ; Wed, 4 Dec 2002 20:09:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB51C7Y03770 for sip-archive@odin.ietf.org; Wed, 4 Dec 2002 20:12:07 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB51BOv03748; Wed, 4 Dec 2002 20:11:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB518Zv03667 for ; Wed, 4 Dec 2002 20:08:35 -0500 Received: from mail2.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13432 for ; Wed, 4 Dec 2002 20:05:37 -0500 (EST) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id gB5136XE015505; Wed, 4 Dec 2002 20:03:07 -0500 (EST) Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 4 Dec 2002 19:04:14 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A64383@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Padma Suresh'" , Adam Roach , rrroy@att.com Cc: sip@ietf.org Subject: RE: [Sip] B2BUA & Max-Forwards Date: Wed, 4 Dec 2002 19:04:13 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , You see, that's why I rephrased the question to be more precise. The original question didn't make a whole lot of sense, because the term "called party" is somewhat counter-intuitive when applied to B2BUAs. Invitee, Invited User, Called Party, Callee: The party that receives an INVITE request for the purpose of establishing a new session. A callee retains this role from the time it receives the INVITE until the termination of the dialog established by that INVITE. In RFC3261 terms, the answer to Radhika's question, "who has been the called party?" is "both UAS(b) and UAS(c)". They both receive the INVITE, and establish a session. These sessions are, from a protocol perspective, unrelated -- although they're obviously related by some application logic. But "both" would have been a flip answer, and it would be answering a question that Radhika obviously did not intend to ask. That notwithstanding, even using the colloquial definition you seem to have in mind (which apparently has the constraint that the "called party" device has a user sitting in front of it, or has something to do with some personal desire held by the calling party, or something like that), your assertion is demonstratably false. Take, for example, the situation in which User A (at UAC(a)) calls User B (at UAS(b)). They have a brief discussion, and user B decides that he wants to add User C to the call; using whatever interface is available, User B instructs his client do so: User B (at UAC(b)) sends an INVITE request to User C (at UAS(c)). User B decides to drop out of the call, but instructs his device to keep the call up until one of the parties disconnects. So User B's device, which was obviously the called party in the initial phase of the call (by either the 3261 or any reasonable and most unreasonable colloquial definitions), is rather clearly acting as a B2BUA. /a -----Original Message----- From: Padma Suresh [mailto:padma_suresh@hotmail.com] Sent: Wednesday, December 04, 2002 18:17 To: adam@dynamicsoft.com; rrroy@att.com Cc: sip@ietf.org Subject: RE: [Sip] B2BUA & Max-Forwards For UAC (a) UAS (c) is the intended called party in the call. We have to define the intended party in a call when a B2BUA is involved. B2BUA IS an intermediate network element. It acts as some kind of a controller for a domain. It is not the called party in any call. Regards Padma >From: Adam Roach >To: "'Roy, Radhika R, ALASO'" , Adam Roach >CC: sip@ietf.org >Subject: RE: [Sip] B2BUA & Max-Forwards >Date: Wed, 4 Dec 2002 16:58:14 -0600 > > > UAC(a)--->UAS(b)===[application logic here]===UAC(b)--->UAS(c) > > > > [RRR] I like to know who has been the called party when > > UAC(a)) sent the INVITE message? Has it been UAS(b) or UAS(c)? > >I'm going to first need to clarify your question. > >The question I will answer is: "If an INVITE is sent through the >network described in this diagram, what is the value of the >Request-URI when UAC(a) sends it?" > >The answer is: it depends. In general, yes, it will probably be >either of UAS(b) or UAS(c). > > > [RRR] If the answer is UAS(c), the question is: Why the call > > has been routed to UAS(b) by UAC(a) in the first place? > >The most obvious of several plausible answers is: UAC(a) >has UAS(b) configured as a local outbound proxy. > > > [RRR] If the answer is UAS(b), probably UAC(a) does not care. > >About what? > >/a >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip Add photos to your e-mail with MSN 8. Get 2 months FREE*. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Wed Dec 4 20:24:12 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13839 for ; Wed, 4 Dec 2002 20:24:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB51Qcb04263 for sip-archive@odin.ietf.org; Wed, 4 Dec 2002 20:26:38 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB51Q8v04245; Wed, 4 Dec 2002 20:26:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB51NWv04128 for ; Wed, 4 Dec 2002 20:23:32 -0500 Received: from bdsl.greycouncil.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13734 for ; Wed, 4 Dec 2002 20:20:35 -0500 (EST) Received: from txdwillis (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.5/8.12.5) with ESMTP id gB51NOQs022390 for ; Wed, 4 Dec 2002 19:23:24 -0600 From: "Dean Willis" To: Date: Wed, 4 Dec 2002 19:23:23 -0600 Message-ID: <00cc01c29bfc$e74751f0$fe0c0c42@txdwillis> 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.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Sip] Back-to-Back User Agent Ttransparency Top 10 list Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Apologies to those of you who have seen this before. It's a couple of years old, which explains my frustration with this particular topic. Note that "conformant" proxies satisfy all 10. Strict UAs satisfy none. ---------------------------- 1) Dialog transparency: The call-ID is the same on "both sides" of the B2BUA. Proxies have this characteristic. A B2BUA that actually terminates a dialog on one side and generates a new dialog on the other doesn't. Some 3GPP AS functions fall into this category, as do 3PCC controllers. 2) Identity transparency: The user appears to have the same identity on both sides of the B2BUA. A proxy has this property. An identity anonymizer doesn't. 3) CSEQ transparency: The B2BUA does not alter CSEQ numbers. A traditional proxy has this property. A 3GPP P-CSCF does not, as it can generate a BYE message and then have to manage disjoint CSEQ spaces on each side. 4) Header transparency: The B2BUA doesn't change headers that transit it. Proxies have mostly this property, changing onlya few headers that are specifically changed by the proxy function. Proxies don't change headers they don't understand. 3GPP "proxies" are likely to go to town changing all SORTS of headers. All with the best of intentions, mind you. 5) Body transparency: The MIME bodies on the SIP message are not altered by the B2BUA. Real SIP proxies have this property. Firewall proxies that modify SDP, and most everything in 3GPP, doesn't. 6) Media transparency: AS with body transparency, but considering only the media aspects. The 3GPP P-CSCF breaks this transparency rule by editing one's SDP to meet operator preferences. 7) Topology transparency. Via, Route, Record-Route, Path, P-Service-Route, and other headers that reveal topology are roughly the same on both sides of the B2BUA, save for any which uniquely identify that B2BUA. Proxies have this characteristic. Topology hiding devices like the dynamicosft "firewall proxy in edge proxy mode" or the 3GPP THIG don't. 8) Security transparency: The B2BUA doesn't alter security aspects, such as encryptions, authorization headers, etc. Proxies generally have this property, but 3GPP stuff doesn't. 9) Accounting transparency: Stuff used to generate records or track usage is not altered by a B2BUA with this property. Proxies have this property. 3GPP is trying to define a P-header (P-original-dialog-ID, I believe) to provide for accounting transparency across 3GPP AS elements operating at a low level of transparency. 10) Functional transparency: The task that the user of the UA wants to accomplish actually works across the B2BUA, rather than being blocked/distorted by it. Proxies generally have this property, with the caveat the proxy can reject a request if needed. Some 3GPP entities can mutate functionality beyond all recognition. This is probably the single most important transparency concept. The rules of a "proxy" as defined in RFC3162 are there to preserve functional transparency, and anything that "breaks" those rules is likely to compromise functionality in some 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 mailnull@www1.ietf.org Wed Dec 4 20:26:01 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13904 for ; Wed, 4 Dec 2002 20:26:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB51SRG04374 for sip-archive@odin.ietf.org; Wed, 4 Dec 2002 20:28:27 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB51S9v04342; Wed, 4 Dec 2002 20:28:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB51NXv04137 for ; Wed, 4 Dec 2002 20:23:33 -0500 Received: from bdsl.greycouncil.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13737 for ; Wed, 4 Dec 2002 20:20:36 -0500 (EST) Received: from txdwillis (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.5/8.12.5) with ESMTP id gB51NOQs022391; Wed, 4 Dec 2002 19:23:25 -0600 From: "Dean Willis" To: "'Pete Cordell'" , Subject: RE: [Sip] B2BUA & Max-Forwards Date: Wed, 4 Dec 2002 19:23:23 -0600 Message-ID: <00cd01c29bfc$e7dd0240$fe0c0c42@txdwillis> 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.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <000201c29b0b$f7be8900$0200000a@tkw> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > One issue that the recent B2BUA discussion has raised in my > mind is what a B2BUA (whatever its decided that should be) > should do with Max-Forwards. It does the same thing as it does with any other header or body part, which is the same thing that ANY 500-pound gorilla does to somebody's body parts -- whatever it wants. What you're asking is "what is the transparency of this node with respect to max-forwards", which is "#4 -- Header Transaprency" in my top-10 list. The specification of a back-to-back user agent doesn't mandate any level of transparency on this or any other header. -- 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 mailnull@www1.ietf.org Wed Dec 4 20:43:18 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14426 for ; Wed, 4 Dec 2002 20:43:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB51jjr05785 for sip-archive@odin.ietf.org; Wed, 4 Dec 2002 20:45:45 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB51jJv05763; Wed, 4 Dec 2002 20:45:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB51gxv05681 for ; Wed, 4 Dec 2002 20:42:59 -0500 Received: from bdsl.greycouncil.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14294 for ; Wed, 4 Dec 2002 20:40:01 -0500 (EST) Received: from txdwillis (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.5/8.12.5) with ESMTP id gB51gpQs022497 for ; Wed, 4 Dec 2002 19:42:51 -0600 From: "Dean Willis" To: Subject: RE: [Sip] Back-to-Back User Agent Ttransparency Top 10 list Date: Wed, 4 Dec 2002 19:42:49 -0600 Message-ID: <00e601c29bff$9e99cac0$fe0c0c42@txdwillis> 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.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <00cc01c29bfc$e74751f0$fe0c0c42@txdwillis> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit By the way, 3GPP proxies are much more conformant now than they were when I first posted this, so please don't beat them up about anything here. They've done a great job improving the transparency of their system. Thank you, 3GPP! -- Dean > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of Dean Willis > Sent: Wednesday, December 04, 2002 7:23 PM > To: sip@ietf.org > Subject: [Sip] Back-to-Back User Agent Ttransparency Top 10 list > > > > Apologies to those of you who have seen this before. It's a > couple of years old, which explains my frustration with this > particular topic. > > Note that "conformant" proxies satisfy all 10. Strict UAs > satisfy none. > > ---------------------------- > > 1) Dialog transparency: The call-ID is the same on "both > sides" of the > B2BUA. Proxies have this characteristic. A B2BUA that actually > terminates a dialog on one side and generates a new dialog on > the other > doesn't. Some 3GPP AS functions fall into this category, as do 3PCC > controllers. > > 2) Identity transparency: The user appears to have the same > identity on > both sides of the B2BUA. A proxy has this property. An identity > anonymizer doesn't. > > 3) CSEQ transparency: The B2BUA does not alter CSEQ numbers. A > traditional proxy has this property. A 3GPP P-CSCF does not, > as it can > generate a BYE message and then have to manage disjoint CSEQ > spaces on > each side. > > 4) Header transparency: The B2BUA doesn't change headers that transit > it. Proxies have mostly this property, changing onlya few > headers that > are specifically changed by the proxy function. Proxies don't change > headers they don't understand. 3GPP "proxies" are likely to > go to town > changing all SORTS of headers. All with the best of intentions, mind > you. > > 5) Body transparency: The MIME bodies on the SIP message are not > altered by the B2BUA. Real SIP proxies have this property. Firewall > proxies that modify SDP, and most everything in 3GPP, doesn't. > > 6) Media transparency: AS with body transparency, but > considering only > the media aspects. The 3GPP P-CSCF breaks this transparency rule by > editing one's SDP to meet operator preferences. > > 7) Topology transparency. Via, Route, Record-Route, Path, > P-Service-Route, and other headers that reveal topology are > roughly the > same on both sides of the B2BUA, save for any which uniquely identify > that B2BUA. Proxies have this characteristic. Topology hiding devices > like the dynamicosft "firewall proxy in edge proxy mode" or the 3GPP > THIG don't. > > 8) Security transparency: The B2BUA doesn't alter security aspects, > such as encryptions, authorization headers, etc. Proxies > generally have > this property, but 3GPP stuff doesn't. > > 9) Accounting transparency: Stuff used to generate records or track > usage is not altered by a B2BUA with this property. Proxies have this > property. 3GPP is trying to define a P-header (P-original-dialog-ID, I > believe) to provide for accounting transparency across 3GPP > AS elements > operating at a low level of transparency. > > 10) Functional transparency: The task that the user of the UA > wants to > accomplish actually works across the B2BUA, rather than being > blocked/distorted by it. Proxies generally have this > property, with the > caveat the proxy can reject a request if needed. Some 3GPP > entities can > mutate functionality beyond all recognition. This is probably the > single most important transparency concept. The rules of a "proxy" as > defined in RFC3162 are there to preserve functional transparency, and > anything that "breaks" those rules is likely to compromise > functionality in some 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 > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Wed Dec 4 20:45:42 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14482 for ; Wed, 4 Dec 2002 20:45:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB51m9505912 for sip-archive@odin.ietf.org; Wed, 4 Dec 2002 20:48:09 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB51lrv05862; Wed, 4 Dec 2002 20:47:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB51h1v05689 for ; Wed, 4 Dec 2002 20:43:01 -0500 Received: from bdsl.greycouncil.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14296 for ; Wed, 4 Dec 2002 20:40:02 -0500 (EST) Received: from txdwillis (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.5/8.12.5) with ESMTP id gB51gpQt022497; Wed, 4 Dec 2002 19:42:52 -0600 From: "Dean Willis" To: "'Phil Reynolds'" , Subject: RE: [Sip] B2BUA Date: Wed, 4 Dec 2002 19:42:49 -0600 Message-ID: <00e701c29bff$9ef3f8b0$fe0c0c42@txdwillis> 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.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <00533D13955AD411AF3800A0C9B4263994D87F@ridgeway.internal.ridgewaysystems.com> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Phil Reynolds Sent: Wednesday, December 04, 2002 7:37 AM To: sip@ietf.org Subject: RE: [Sip] B2BUA If a telephone switch crashes you loose all calls... The telecoms people are clever enough to have thought about that and build redundancy, fault tolerance and failover into their switches. Maybe some of us IP-telecoms people have thought of similar techniques for SIP intermediaries? ----- Yes. We call them "proxies". -- 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 mailnull@www1.ietf.org Wed Dec 4 21:10:10 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15132 for ; Wed, 4 Dec 2002 21:10:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB52CbH07407 for sip-archive@odin.ietf.org; Wed, 4 Dec 2002 21:12:37 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB52C7v07369; Wed, 4 Dec 2002 21:12:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5296v07286 for ; Wed, 4 Dec 2002 21:09:06 -0500 Received: from szsmtp.utstar.com.cn (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15044 for ; Wed, 4 Dec 2002 21:06:07 -0500 (EST) Received: from nicky ([172.16.161.58]) by szsmtp.utstar.com.cn (8.11.1/8.11.1) with SMTP id gB5274721281; Thu, 5 Dec 2002 10:07:04 +0800 Message-ID: <009601c29c03$2416bca0$3aa110ac@cn.utstar.com> Reply-To: "Nicky Song" From: "Nicky Song" To: "Adam Roach" , "'Kedar Patil'" , "'Padma Suresh'" , , Cc: References: <9BF66EBF6BEFD942915B4D4D45C051F3A64378@DYN-TX-EXCH-001.dynamicsoft.com> Subject: Re: [Sip] B2BUA & Max-Forwards Date: Thu, 5 Dec 2002 10:08:01 +0800 Organization: UTStarcom MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id gB5296v07287 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit > -----Original Message----- > From: Kedar Patil [mailto:kpatil@sta.samsung.com] > > > This discussion raises one more doubt for me, pls. clarify. > > > > UA1------->BtoBUA---------->UA2 > > > > Is the BtoBUA a SIP endpoint from UA1's point of view? > > Yes. > I'm confused. Isn't the "BtoBUA" a concept of the combination of UACs and UASs? I think from the UA1's point of view, it doesn't know whether its peer is a B2BUA or a normal single UA. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Wed Dec 4 22:59:27 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18703 for ; Wed, 4 Dec 2002 22:59:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB541uv13271 for sip-archive@odin.ietf.org; Wed, 4 Dec 2002 23:01:56 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB541Uv13258; Wed, 4 Dec 2002 23:01:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB53wXv13143 for ; Wed, 4 Dec 2002 22:58:33 -0500 Received: from mail2.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18661 for ; Wed, 4 Dec 2002 22:55:33 -0500 (EST) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id gB53vBXE015915; Wed, 4 Dec 2002 22:57:12 -0500 (EST) Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 4 Dec 2002 21:58:18 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A64384@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Nicky Song'" , Adam Roach , "'Kedar Patil'" , "'Padma Suresh'" , vkg@lucent.com, pete@tech-know-ware.com Cc: sip@ietf.org Subject: RE: [Sip] B2BUA & Max-Forwards Date: Wed, 4 Dec 2002 21:58:17 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , > -----Original Message----- > From: Nicky Song [mailto:nicky.song@utstar.com] > > > -----Original Message----- > > From: Kedar Patil [mailto:kpatil@sta.samsung.com] > > > > > This discussion raises one more doubt for me, pls. clarify. > > > > > > UA1------->BtoBUA---------->UA2 > > > > > > Is the BtoBUA a SIP endpoint from UA1's point of view? > > > > Yes. > > > I'm confused. Isn't the "BtoBUA" a concept of the combination > of UACs and UASs? I think from the UA1's point of view, it > doesn't know whether its peer is a B2BUA or a normal single UA. Yep. It doesn't know whether its peer is a B2BUA or a "normal" UA. So, it's a SIP endpoint from UA1's point of view. It's not clear to me where the confusion comes in. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Wed Dec 4 23:37:24 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19624 for ; Wed, 4 Dec 2002 23:37:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB54dr715880 for sip-archive@odin.ietf.org; Wed, 4 Dec 2002 23:39:53 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB54dYv15856; Wed, 4 Dec 2002 23:39:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB54aav15186 for ; Wed, 4 Dec 2002 23:36:36 -0500 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19590 for ; Wed, 4 Dec 2002 23:33:35 -0500 (EST) Received: from whoami-new.cisco.com (IDENT:mirapoint@whoami-new.cisco.com [64.101.128.102]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id gB54aQLW029337 for ; Wed, 4 Dec 2002 20:36:26 -0800 (PST) Received: from ARUNVENKW2K1 (ams-clip-vpn-dhcp129.cisco.com [10.50.0.128]) by whoami-new.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with SMTP id AAM85972; Wed, 4 Dec 2002 22:36:23 -0600 (CST) From: "Arunachalam Venkatraman" To: Subject: RE: [Sip] Detecting merged requests? Date: Wed, 4 Dec 2002 22:39:03 -0600 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) In-reply-to: <4.3.2.7.0.20021202162407.02d5f3a0@blaze> X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Sachin Your interpretation is correct. The request is not considered merged, unless the ReqUri matches that on a previously received request on the same calId (in addition to other headers specified in the RFC). ReqUri is a primary parameter in a merged request. The other criteria come into play only when the request uri indicates this as a possibility. In transaction matching rules, used to detect retransmissions/merged requests ReqUri, VIA, From Tag/ToTag, CSEQ and CallId are all used. The correct thing for the two UASs to do is respond with a different To Tag on each request and proceed to set up the calls independently(This is distinct from 2 legs on the same call.) This scenario is also referred to, loosely, as UAS forking. -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Sachin Shenoy Sent: Monday, December 02, 2002 5:10 AM To: sip@ietf.org Subject: [Sip] Detecting merged requests? Hi, According to RFC 3261, a request is a merged request if ... "8.2.2.2 Merged Requests If the request has no tag in the To header field, the UAS core MUST check the request against ongoing transactions. If the From tag, Call-ID, and CSeq exactly match those associated with an ongoing transaction, but the request does not match that transaction (based on the matching rules in Section 17.2.3), the UAS core SHOULD generate a 482 (Loop Detected) response and pass it to the server transaction." Suppose if there are 2 UAS application sharing the same SIP stack (same process). They are listening for incoming calls for the same user. One application is handling the fax machine for user_a and the other the phone for user_a. user_a's fax machine can be reached at fax_user_a@test.com And user_a's phone can be reached at phone_user_a@test.com A call made to user_a@test.com gets forked at a proxy. The 2 forked request arrives at the UAS with the respective request URI's INVITE sip:fax_user_a@test.com ... INVITE sip:phone_user_a@test.com ... Now, according to the RFC, the first INVITE would be processed and the second would be responded with 482 "loop detected". Shouldn't the second INVITE also be processed? Logically, these are 2 different application handling 2 different devices for the same user. The fact that they are sharing the same process should not interfere each other. I think merged request matching should also take the Request-Uri into consideration. Request-Uri identifies the end point at UAS. If a UAS gets 2 INVITES for the same request-uri with the same Call-ID, Cseq and From-Tag, and with no To-Tag then it should be considered as merged request. Thanks Sachin _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Thu Dec 5 01:20:12 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21861 for ; Thu, 5 Dec 2002 01:20:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB56Mfr20947 for sip-archive@odin.ietf.org; Thu, 5 Dec 2002 01:22:41 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB56MDv20912; Thu, 5 Dec 2002 01:22:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB56GOv20729 for ; Thu, 5 Dec 2002 01:16:24 -0500 Received: from hotmail.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21684 for ; Thu, 5 Dec 2002 01:13:24 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 4 Dec 2002 22:16:13 -0800 Received: from 12.234.181.64 by lw7fd.law7.hotmail.msn.com with HTTP; Thu, 05 Dec 2002 06:16:13 GMT X-Originating-IP: [12.234.181.64] From: "Padma Suresh" To: dwillis@dynamicsoft.com, sip@ietf.org Subject: Re: [Sip] Back-to-Back User Agent Ttransparency Top 10 list Date: Thu, 05 Dec 2002 06:16:13 +0000 Mime-Version: 1.0 Content-Type: text/html Message-ID: X-OriginalArrivalTime: 05 Dec 2002 06:16:13.0563 (UTC) FILETIME=[CFE85CB0:01C29C25] Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: ,

"4) Header transparency: The B2BUA doesn't change headers that transit it."

This mail seems to suggest that a B2BUA forwards the headers to the other endpoint (in other words does not change the headers that transit it) .

Am I wrong in this assumption?

The content of this mail would definitely be pretty useful in a draft on the B2BUA.

Regards

Padma

>From: "Dean Willis"
>To:
>Subject: [Sip] Back-to-Back User Agent Ttransparency Top 10 list
>Date: Wed, 4 Dec 2002 19:23:23 -0600
>
>
>Apologies to those of you who have seen this before. It's a couple of
>years old, which explains my frustration with this particular topic.
>
>Note that "conformant" proxies satisfy all 10. Strict UAs satisfy none.
>
>----------------------------
>
>1) Dialog transparency: The call-ID is the same on "both sides" of the
>B2BUA. Proxies have this characteristic. A B2BUA that actually
>terminates a dialog on one side and generates a new dialog on the other
>doesn't. Some 3GPP AS functions fall into this category, as do 3PCC
>controllers.
>
>2) Identity transparency: The user appears to have the same identity on
>both sides of the B2BUA. A proxy has this property. An identity
>anonymizer doesn't.
>
>3) CSEQ transparency: The B2BUA does not alter CSEQ numbers. A
>traditional proxy has this property. A 3GPP P-CSCF does not, as it can
>generate a BYE message and then have to manage disjoint CSEQ spaces on
>each side.
>
>4) Header transparency: The B2BUA doesn't change headers that transit
>it. Proxies have mostly this property, changing onlya few headers that
>are specifically changed by the proxy function. Proxies don't change
>headers they don't understand. 3GPP "proxies" are likely to go to town
>changing all SORTS of headers. All with the best of intentions, mind
>you.
>
>5) Body transparency: The MIME bodies on the SIP message are not
>altered by the B2BUA. Real SIP proxies have this property. Firewall
>proxies that modify SDP, and most everything in 3GPP, doesn't.
>
>6) Media transparency: AS with body transparency, but considering only
>the media aspects. The 3GPP P-CSCF breaks this transparency rule by
>editing one's SDP to meet operator preferences.
>
>7) Topology transparency. Via, Route, Record-Route, Path,
>P-Service-Route, and other headers that reveal topology are roughly the
>same on both sides of the B2BUA, save for any which uniquely identify
>that B2BUA. Proxies have this characteristic. Topology hiding devices
>like the dynamicosft "firewall proxy in edge proxy mode" or the 3GPP
>THIG don't.
>
>8) Security transparency: The B2BUA doesn't alter security aspects,
>such as encryptions, authorization headers, etc. Proxies generally have
>this property, but 3GPP stuff doesn't.
>
>9) Accounting transparency: Stuff used to generate records or track
>usage is not altered by a B2BUA with this property. Proxies have this
>property. 3GPP is trying to define a P-header (P-original-dialog-ID, I
>believe) to provide for accounting transparency across 3GPP AS elements
>operating at a low level of transparency.
>
>10) Functional transparency: The task that the user of the UA wants to
>accomplish actually works across the B2BUA, rather than being
>blocked/distorted by it. Proxies generally have this property, with the
>caveat the proxy can reject a request if needed. Some 3GPP entities can
>mutate functionality beyond all recognition. This is probably the
>single most important transparency concept. The rules of a "proxy" as
>defined in RFC3162 are there to preserve functional transparency, and
>anything that "breaks" those rules is likely to compromise
>functionality in some 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

the new MSN 8 and get 2 months FREE* _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Thu Dec 5 01:38:03 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22143 for ; Thu, 5 Dec 2002 01:38:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB56eWm22121 for sip-archive@odin.ietf.org; Thu, 5 Dec 2002 01:40:32 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB56eBv22097; Thu, 5 Dec 2002 01:40:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB56bHv21857 for ; Thu, 5 Dec 2002 01:37:17 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22090 for ; Thu, 5 Dec 2002 01:34:17 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.83]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gB56b8YH012119; Thu, 5 Dec 2002 01:37:08 -0500 (EST) Message-ID: <3DEEF411.2020408@dynamicsoft.com> Date: Thu, 05 Dec 2002 01:37:05 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adam Roach CC: "'Phil Reynolds'" , sip@ietf.org Subject: Re: [Sip] B2BUA & Max-Forwards References: <9BF66EBF6BEFD942915B4D4D45C051F3A64377@DYN-TX-EXCH-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit inline. Adam Roach wrote: > -----Original Message----- > From: Phil Reynolds [mailto:preynolds@ridgewaysystems.com] > > >>Now your back to restricting what I can and can't do in an >>intermediary. It can't be a B2BUA 'cos it doesn't need to >>honour require headers (the UA at the other end does that, >>if they were meant for my intermediary then they would be >>proxy-require?), and it can't be a proxy 'cos of the rules >>about not changing the body so what is it? > > > Broken. Adam is correct. > > The restrictions placed on nodes by 3261 (which I'm merely > reiterating, not imposing) aren't an authoritarian attempt > at unnecessary proscription. They serve a purpose. > > I'll describe one of the (several) purposes that applies > to the situation you propose. > > One of the things that UAs are required to be able to do is > sign and/or encrypt the bodies and/or some subset of the > headers to ensure confidentiality and/or integrity. The > protocol places restrictions on various nodes to ensure > that this can be done. Your box is broken precisely because > it interferes with these abilities (or, more precisely, > these abilities interfere with it). Let me add some more here. Anything that deviates at all from proxy rules will need to be a b2bua and follow b2bua rules, including processing of Require. There is no black-or-white here. Let me give some examples. Lets say my b2bua is a proxy in all ways, BUT it happens to muck with SDP to enable firewall traversal. Surely then it can ignore Require, right? WRONG. Lets say I define extension foo, which means "the content of this SDP is not what it seems - look at this header to instead find the real port/address for media". This extension needs a Require (because only a UA ever looks at bodies), but not a Proxy-Require, because proxies don't. Thus, your almost-a-proxy will fail in odd ways because it has ignored Require when it shouldn't have. Indeed, for any operation prohibited to a proxy, but allowed for a UA, I can come up with an extension, indicated in a Require header, that would need to be understood by a b2bua which breaks the proxy rules and performs this operation. Indeed, the rules on what is a UA, and what is a proxy, are meant precisely to help define what goes in Require, and what goes in Proxy-Require. Whether or not Require gets passed on by such a b2bua depends entirely on the application logic. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.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 mailnull@www1.ietf.org Thu Dec 5 01:48:51 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22324 for ; Thu, 5 Dec 2002 01:48:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB56pKB22380 for sip-archive@odin.ietf.org; Thu, 5 Dec 2002 01:51:20 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB56p1v22362; Thu, 5 Dec 2002 01:51:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB56mGv22295 for ; Thu, 5 Dec 2002 01:48:16 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22226 for ; Thu, 5 Dec 2002 01:45:16 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.83]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gB56lxYH012129; Thu, 5 Dec 2002 01:47:59 -0500 (EST) Message-ID: <3DEEF69C.5030709@dynamicsoft.com> Date: Thu, 05 Dec 2002 01:47:56 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: William Marshall CC: dean.willis@softarmor.com, mbarnes@nortelnetworks.com, Juan-Carlos.Rojas@alcatel.fr, sip@ietf.org Subject: Re: [Sip] B2BUA References: <200212031329.IAA72497@fish.research.att.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit inline. William Marshall wrote: > Dean wrote: > >>I think that Bill is suggesting that there is also something BETWEEN the >>B2BUA and the conformant proxy, and that the world would be a better >>place (ok, maybe not THAT much better) if our taxonomy also included >>this "between" thing. > > > To further elaborate, there certainly exists on paper a box that does > some abritrary and weird algorithm, not conformant with any of the > rules in rfc3261, that transforms requests and response and breaks > everything that goes through it. Call it "Dean's devilish-B2BUA". > > But I don't think anyone builds such a box. At least not intentionally. > > What is built instead are boxes that are close to the definition of > proxies, but not quite. They serve a real need in the market (and > vendors tend to build what sells). But due to various details, like > looking at the attachment (a proxy-no-no) to open pinholes in the firewall, > they don't strictly qualify as proxies. > > Saying there are only two types of boxes, proxies and devilish-B2BUAs, > ignores the reality. > > The writing of an accurate definition of a B2BUA is only the first step. No. If, indeed, there is a strong need for elements that are ALMOST proxies, but are doing X,Y, and Z things that proxies cannot, there are two approaches. The first approach is, as you propose, to presume the existence of a new type of element and go about defining it. The second, is to consider how to add that capability to the repetoire of things a proxy can, in fact, legally do. As an example, a very common offense is mucking with SDP, for example, to implement a firewall control proxy, ala midcom. Instead of defining a new element, called an SDP-munging proxy, and dealing with all the horrible security implications that will arise from it, I would propose to simply FIX THE PROBLEM and define a means by which a proxy can impose session policies without breaking SIP. Indeed, I wrote a draft on just such a topic: http://www.jdrosen.net/papers/draft-rosenberg-sipping-session-policy-00.txt Perhaps if you could list what is it that a "transparent b2bua" needs to do that a proxy cannot, we can figure out how to fix the problem instead of defining an entirely new protocol element. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.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 mailnull@www1.ietf.org Thu Dec 5 02:13:37 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01481 for ; Thu, 5 Dec 2002 02:13:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB57G6j00956 for sip-archive@odin.ietf.org; Thu, 5 Dec 2002 02:16:06 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB57CQv00785; Thu, 5 Dec 2002 02:12:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB579kv30486 for ; Thu, 5 Dec 2002 02:09:46 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26960 for ; Thu, 5 Dec 2002 02:06:45 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.83]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gB579bYH012133; Thu, 5 Dec 2002 02:09:37 -0500 (EST) Message-ID: <3DEEFBAE.5050009@dynamicsoft.com> Date: Thu, 05 Dec 2002 02:09:34 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Peterson, Jon" CC: "'Adam Roach'" , "'sip@ietf.org'" Subject: Re: [Sip] Discuss on service discovery References: <15A2739B7DAA624D8091C65981D7DA815EB440@stntexch2.va.neustar.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Done. Logged as: http://www.sipwg.org/sipwg/show_bug.cgi?id=679 I would request, though, that service route at least call out that this issue is exacerbated by service route, because of the underlying assumption of intervening proxies between the client and registrar. -Jonathan R. Peterson, Jon wrote: > I think that's quite reasonable. > > Jon Peterson > NeuStar, Inc. > > >>-----Original Message----- >>From: Adam Roach [mailto:adam@dynamicsoft.com] >>Sent: Wednesday, December 04, 2002 2:45 PM >>To: 'Peterson, Jon'; 'sip@ietf.org' >>Subject: RE: [Sip] Discuss on service discovery >> >> >>... >> >>>Can we go forward with the requested fix? >> >>In light of the conclusions of the previous discussions on the >>topic, I have no further objections. >> >>I would, however, like to see a bug opened against 3261 to >>address this issue so that the solution can eventually appear >>in a centralized place. >> >>/a >> > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.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 mailnull@www1.ietf.org Thu Dec 5 02:27:10 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02667 for ; Thu, 5 Dec 2002 02:27:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB57TdM02101 for sip-archive@odin.ietf.org; Thu, 5 Dec 2002 02:29:39 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB57Scv02076; Thu, 5 Dec 2002 02:28:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB57Pkv02000 for ; Thu, 5 Dec 2002 02:25:46 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02564 for ; Thu, 5 Dec 2002 02:22:46 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.83]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gB57PcYH012137; Thu, 5 Dec 2002 02:25:38 -0500 (EST) Message-ID: <3DEEFF6F.3000605@dynamicsoft.com> Date: Thu, 05 Dec 2002 02:25:35 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sparks CC: Anders Kristensen , sip@ietf.org Subject: Re: [Sip] Constructing the branch parameter at stateless proxies References: <1038933302.911.62.camel@RjS.localdomain> <3DEE251A.5080306@dynamicsoft.com> <1039017937.910.76.camel@RjS.localdomain> <3DEE294A.9080806@dynamicsoft.com> <1039019630.910.132.camel@RjS.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit inline. Robert Sparks wrote: > On Wed, 2002-12-04 at 10:11, Anders Kristensen wrote: > >> >>Robert Sparks wrote: >> >>>On Wed, 2002-12-04 at 09:54, Anders Kristensen wrote: >>> >>> >>>>Hi Robert, >>>> >>>>Sounds like a very good idea. One special case to consider is what >>>>happens if the request spirals back to the sending proxy (which >>>>presumably is stateful) -- either directly from the stateless proxy or >>>>via a number of other stateless proxies. The stateful proxy in this >>>>case will have a server transaction and a client transaction with the >>>>same id, which might confuse some implementations. >>> >>> >>>This is no different from the same proxy spiraling directly to itself >>>is it? >> >>Well, it's different in that it is NOT spiraling directly to itself and >>so is currently guaranteed to see a different branch ID in a spiralled >>request. It may be the case that noone depends on this but who knows? > > > Ok - so an implementation _may_ have gone to some effort to ensure > that it wasn't sending a message to itself and is counting on not > seeing the same transaction identifier come back to it. Not a choice > I would recommend, but I can see how someone might have made it. > > We could avoid this with the suffix mechanism you suggest, or we > could add an admonishment to the spec to tell systems to be prepared > to have their transaction ID come back. I'd rather do the second. I agree with Robert. Over time, our view of stateless proxies has changed a lot. Initially, we tried to treat them as the same as stateful ones, but it has become clear that there are important differences (for example, there are restrictions on the types of routing logic that are permitted). One of the big changes in bis was the formal definition of a transaction as being between a client transaction in one element and a server transaction in another (figure 4). Whats important is that the transaction is between transaction-stateful elements (by definition). It would seem very logical, then, that the transaction identifier (the branch ID) would be the same for all messages in this transaction. Since a stateless proxy doesn't muck with the transaction, just forwards messages, I would argue that the transaction ID should stay the same. Indeed, the analogy is similar to the dialog identifiers in a stateful proxy; they too are not modified, since the proxy doesn't act as a termination point of the dialog. If it did (b2bua), it would need to modify those identifiers. > > Well, nothing earth-shattering. Right now, just an increased probability > that implementation error will lead to protocol failure. Its hard to get > this right, and we can greatly simplify it. > > My growing distaste for what the stateless proxies are currently doing > comes from seeing it somewhat like a NAT. The transaction is really > between the two stateful elements reguardless of how many stateless > elements lie between. Right now, the stateless elements are > "translating" the transaction identifier as the message goes through. > We haven't identified anything in the protocol that breaks as long > as they do this consistently, but I haven't been able to identify any > benefit to the behavior. I agree. I think its really legacy at this point. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.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 mailnull@www1.ietf.org Thu Dec 5 02:30:48 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02831 for ; Thu, 5 Dec 2002 02:30:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB57XHH02238 for sip-archive@odin.ietf.org; Thu, 5 Dec 2002 02:33:17 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB57Wsv02207; Thu, 5 Dec 2002 02:32:54 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB57UIv02152 for ; Thu, 5 Dec 2002 02:30:18 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02681 for ; Thu, 5 Dec 2002 02:27:17 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.83]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gB57U9YH012141; Thu, 5 Dec 2002 02:30:09 -0500 (EST) Message-ID: <3DEF007E.7030000@dynamicsoft.com> Date: Thu, 05 Dec 2002 02:30:06 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sparks CC: Anders Kristensen , sip@ietf.org Subject: Re: [Sip] Constructing the branch parameter at stateless proxies References: <1038933302.911.62.camel@RjS.localdomain> <3DEE251A.5080306@dynamicsoft.com> <1039017937.910.76.camel@RjS.localdomain> <3DEE294A.9080806@dynamicsoft.com> <1039019630.910.132.camel@RjS.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit By the way, I am now tracking this in bugzilla: http://www.sipwg.org/sipwg/show_bug.cgi?id=680 -Jonathan R. Robert Sparks wrote: > On Wed, 2002-12-04 at 10:11, Anders Kristensen wrote: > >> >>Robert Sparks wrote: >> >>>On Wed, 2002-12-04 at 09:54, Anders Kristensen wrote: >>> >>> >>>>Hi Robert, >>>> >>>>Sounds like a very good idea. One special case to consider is what >>>>happens if the request spirals back to the sending proxy (which >>>>presumably is stateful) -- either directly from the stateless proxy or >>>>via a number of other stateless proxies. The stateful proxy in this >>>>case will have a server transaction and a client transaction with the >>>>same id, which might confuse some implementations. >>> >>> >>>This is no different from the same proxy spiraling directly to itself >>>is it? >> >>Well, it's different in that it is NOT spiraling directly to itself and >>so is currently guaranteed to see a different branch ID in a spiralled >>request. It may be the case that noone depends on this but who knows? > > > Ok - so an implementation _may_ have gone to some effort to ensure > that it wasn't sending a message to itself and is counting on not > seeing the same transaction identifier come back to it. Not a choice > I would recommend, but I can see how someone might have made it. > > We could avoid this with the suffix mechanism you suggest, or we > could add an admonishment to the spec to tell systems to be prepared > to have their transaction ID come back. I'd rather do the second. > > >>> >>>>This can be addressed simply by appending a fixed string to the branch >>>>value at each stateless proxy doing this trick, e.g. a single character. >>>>This guarantees the uniqueness properties required by rfc 3261, which >>>>seems desirable. >>> >>> >>>There are several things we could do here - append the count of present >>>via header fields for example to make sure you get different values as >>>you spiral through the stateless elements, etc. I don't think any of >>>this is necessary though - the stateless elements are supposed to be >>>transaction invisible. If they _can_ do something that botches the >>>transaction, we've got a weak spot in the protocol. I propose that >>>preserving the transaction identifier provided by the stateful element >>>is exactly the right thing to do, and that any mucking with it brings >>>nothing good to the table, and has the potential to bring harm. >> >>Like what? > > > Well, nothing earth-shattering. Right now, just an increased probability > that implementation error will lead to protocol failure. Its hard to get > this right, and we can greatly simplify it. > > My growing distaste for what the stateless proxies are currently doing > comes from seeing it somewhat like a NAT. The transaction is really > between the two stateful elements reguardless of how many stateless > elements lie between. Right now, the stateless elements are > "translating" the transaction identifier as the message goes through. > We haven't identified anything in the protocol that breaks as long > as they do this consistently, but I haven't been able to identify any > benefit to the behavior. > > Now I'll go out on a limb. In the future, we might want as part of > diagnostics, error recovery, or some similar function, to be able > to refer to the transaction by its identifier. It would be very > nice if that identifier were the same at the stateful elements on > each end of the transaction. > > >>Anders > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.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 mailnull@www1.ietf.org Thu Dec 5 02:38:01 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03086 for ; Thu, 5 Dec 2002 02:38:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB57eUO03167 for sip-archive@odin.ietf.org; Thu, 5 Dec 2002 02:40:30 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB57e7v03142; Thu, 5 Dec 2002 02:40:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB57aHv02382 for ; Thu, 5 Dec 2002 02:36:17 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02942 for ; Thu, 5 Dec 2002 02:33:16 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.83]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gB57WFYH012144; Thu, 5 Dec 2002 02:32:56 -0500 (EST) Message-ID: <3DEF00FC.1020201@dynamicsoft.com> Date: Thu, 05 Dec 2002 02:32:12 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ravi Shiroor CC: sip@ietf.org Subject: Re: [Sip] response to merged requests References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I don't think there was an explicit decision to not define a new response code. The error condition seemed close enough to a loop (its another topology failure) that it was reasonable to reuse the code. -Jonathan R. Ravi Shiroor wrote: > posting this on sip as there were no responses on sip-implementors. > > ---------> > > section 8.2.2.2 in RFC 3261 says that when a UAS receives > merged requests, it should respond to the INVITEs receieved > after the first one (those detected as merged) with 482 (loop detected). > > i was wondering why "loop detected" is being being used when > merged requests are receieved? wouldnt it be appropriate to > define a specific 4xx response for merged requests? > > can somebody please clarify if there is a valid reason for > using "loop detected" in this scenario? > > TIA, > ravi. > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.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 mailnull@www1.ietf.org Thu Dec 5 02:52:40 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03390 for ; Thu, 5 Dec 2002 02:52:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB57tAu03651 for sip-archive@odin.ietf.org; Thu, 5 Dec 2002 02:55:10 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB57skv03620; Thu, 5 Dec 2002 02:54:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB57p9v03540 for ; Thu, 5 Dec 2002 02:51:09 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03318 for ; Thu, 5 Dec 2002 02:48:08 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.83]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gB57hLYH012154; Thu, 5 Dec 2002 02:43:21 -0500 (EST) Message-ID: <3DEF0396.4030301@dynamicsoft.com> Date: Thu, 05 Dec 2002 02:43:18 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sachin Shenoy CC: sip@ietf.org Subject: Re: [Sip] Detecting merged requests? References: <4.3.2.7.0.20021202162407.02d5f3a0@blaze> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Remember, SIP talks about logical elements, and doesn't care about specific implementations. In your example, there are really two separate user agents, in the sense that there are two separate entities making decisions about whether to accept or reject calls. That these happen to share an internal stack and port is a matter of implementation. As such, according to the spec, they would be treated as separate UA and thus not subject to the merged request rule. That rule is meant to deal explicitly with the case of a single UA, in the logical sense above, getting two requests. The issue is how a particular call acceptance decision - accept, reject, redirect - manifests itself in terms of responses across multiple transactions. That is a non-issue in your case. -Jonathan R. Sachin Shenoy wrote: > Hi, > > According to RFC 3261, a request is a merged request if ... > > "8.2.2.2 Merged Requests > > If the request has no tag in the To header field, the UAS core MUST > check the request against ongoing transactions. If the From tag, > Call-ID, and CSeq exactly match those associated with an ongoing > transaction, but the request does not match that transaction (based > on the matching rules in Section 17.2.3), the UAS core SHOULD > generate a 482 (Loop Detected) response and pass it to the server > transaction." > > Suppose if there are 2 UAS application sharing the same SIP stack > (same process). They are listening for incoming calls for the same > user. One application is handling the fax machine for user_a and the > other the phone for user_a. > > user_a's fax machine can be reached at fax_user_a@test.com > And user_a's phone can be reached at phone_user_a@test.com > > > A call made to user_a@test.com gets forked at a proxy. The > 2 forked request arrives at the UAS with the respective request > URI's > > INVITE sip:fax_user_a@test.com > ... > > INVITE sip:phone_user_a@test.com > ... > > Now, according to the RFC, the first INVITE would be processed and the > second would be responded with 482 "loop detected". Shouldn't the > second INVITE also be processed? Logically, these are 2 different > application handling 2 different devices for the same user. The fact that > they are sharing the same process should not interfere each other. > > I think merged request matching should also take the Request-Uri > into consideration. Request-Uri identifies the end point at UAS. If > a UAS gets 2 INVITES for the same request-uri with the same Call-ID, > Cseq and From-Tag, and with no To-Tag then it should be considered > as merged request. > > Thanks > Sachin > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.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 mailnull@www1.ietf.org Thu Dec 5 02:56:44 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03479 for ; Thu, 5 Dec 2002 02:56:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB57xEW03742 for sip-archive@odin.ietf.org; Thu, 5 Dec 2002 02:59:14 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB57wuv03732; Thu, 5 Dec 2002 02:58:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB57uUv03698 for ; Thu, 5 Dec 2002 02:56:30 -0500 Received: from bdsl.greycouncil.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03429 for ; Thu, 5 Dec 2002 02:53:28 -0500 (EST) Received: from dwillis9 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.5/8.12.5) with SMTP id gB57uHQs024404; Thu, 5 Dec 2002 01:56:18 -0600 Message-ID: <000d01c29c33$c8d20f30$1b02a8c0@dwillis9> From: "Dean Willis" To: "Padma Suresh" , References: Subject: Re: [Sip] Back-to-Back User Agent Ttransparency Top 10 list Date: Thu, 5 Dec 2002 01:56:14 -0600 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.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Padma asked: > "4) Header transparency: The B2BUA doesn't change headers that transit it." > > This mail seems to suggest that a B2BUA forwards the headers to the other endpoint (in other words does not change the headers that transit it) . > > Am I wrong in this assumption? > > The content of this mail would definitely be pretty useful in a draft on the B2BUA. A B2BUA that has the propoerty of header transparency would not change headers, as said. However, not all B2BUAs have such a property. For example, the 3GPP Topology Hiding Internetwork Gateway, or THIG, transforms headers that reveal topology information about the operator network. The DCS/PacketCable "Anonymizer" transforms headers that reveal the identity or location of a caller. Even a basic proxy actually changes some headers, for example Via and possibly Route and Record-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 mailnull@www1.ietf.org Thu Dec 5 04:38:46 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05509 for ; Thu, 5 Dec 2002 04:38:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB59fHv09172 for sip-archive@odin.ietf.org; Thu, 5 Dec 2002 04:41:17 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB59eqv09115; Thu, 5 Dec 2002 04:40:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB59ZBv08312 for ; Thu, 5 Dec 2002 04:35:11 -0500 Received: from smail3.alcatel.fr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05322 for ; Thu, 5 Dec 2002 04:32:08 -0500 (EST) From: Juan-Carlos.Rojas@alcatel.fr Received: from frmail25.netfr.alcatel.fr (frmail25.netfr.alcatel.fr [155.132.182.155]) by smail3.alcatel.fr (ALCANET/NETFR) with ESMTP id gB59Ykek015847; Thu, 5 Dec 2002 10:34:46 +0100 Subject: Re: [Sip] B2BUA & Max-Forwards To: Jonathan Rosenberg Cc: Adam Roach , "'Phil Reynolds'" , sip@ietf.org Date: Thu, 5 Dec 2002 10:34:44 +0100 Message-ID: X-MIMETrack: Serialize by Router on FRMAIL25/FR/ALCATEL(Release 5.0.8 |June 18, 2001) at 12/05/2002 10:34:46 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hello, Fully agree with you. Indeed, that's what should be explicitly added to the B2BUA definition in 3261, to avoid confusion: "Anything that deviates at all from proxy rules will need to be a b2bua and follow b2bua rules" "...a b2bua depends entirely on the application logic" All the debate is around these two notions. Best regards Juan Carlos Jonathan Rosenberg @ietf.org on 05/12/2002 07:37:05 Sent by: sip-admin@ietf.org To: Adam Roach cc: "'Phil Reynolds'" , sip@ietf.org Subject: Re: [Sip] B2BUA & Max-Forwards inline. Adam Roach wrote: > -----Original Message----- > From: Phil Reynolds [mailto:preynolds@ridgewaysystems.com] > > >>Now your back to restricting what I can and can't do in an >>intermediary. It can't be a B2BUA 'cos it doesn't need to >>honour require headers (the UA at the other end does that, >>if they were meant for my intermediary then they would be >>proxy-require?), and it can't be a proxy 'cos of the rules >>about not changing the body so what is it? > > > Broken. Adam is correct. > > The restrictions placed on nodes by 3261 (which I'm merely > reiterating, not imposing) aren't an authoritarian attempt > at unnecessary proscription. They serve a purpose. > > I'll describe one of the (several) purposes that applies > to the situation you propose. > > One of the things that UAs are required to be able to do is > sign and/or encrypt the bodies and/or some subset of the > headers to ensure confidentiality and/or integrity. The > protocol places restrictions on various nodes to ensure > that this can be done. Your box is broken precisely because > it interferes with these abilities (or, more precisely, > these abilities interfere with it). Let me add some more here. Anything that deviates at all from proxy rules will need to be a b2bua and follow b2bua rules, including processing of Require. There is no black-or-white here. Let me give some examples. Lets say my b2bua is a proxy in all ways, BUT it happens to muck with SDP to enable firewall traversal. Surely then it can ignore Require, right? WRONG. Lets say I define extension foo, which means "the content of this SDP is not what it seems - look at this header to instead find the real port/address for media". This extension needs a Require (because only a UA ever looks at bodies), but not a Proxy-Require, because proxies don't. Thus, your almost-a-proxy will fail in odd ways because it has ignored Require when it shouldn't have. Indeed, for any operation prohibited to a proxy, but allowed for a UA, I can come up with an extension, indicated in a Require header, that would need to be understood by a b2bua which breaks the proxy rules and performs this operation. Indeed, the rules on what is a UA, and what is a proxy, are meant precisely to help define what goes in Require, and what goes in Proxy-Require. Whether or not Require gets passed on by such a b2bua depends entirely on the application logic. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.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 mailnull@www1.ietf.org Thu Dec 5 04:45:49 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05699 for ; Thu, 5 Dec 2002 04:45:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB59mKL09308 for sip-archive@odin.ietf.org; Thu, 5 Dec 2002 04:48:20 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB59lvv09295; Thu, 5 Dec 2002 04:47:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB59j6v09226 for ; Thu, 5 Dec 2002 04:45:06 -0500 Received: from smail3.alcatel.fr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05595 for ; Thu, 5 Dec 2002 04:42:04 -0500 (EST) From: Juan-Carlos.Rojas@alcatel.fr Received: from frmail25.netfr.alcatel.fr (frmail25.netfr.alcatel.fr [155.132.182.155]) by smail3.alcatel.fr (ALCANET/NETFR) with ESMTP id gB59ikek022788; Thu, 5 Dec 2002 10:44:46 +0100 Subject: RE: [Sip] B2BUA & Max-Forwards To: Adam Roach Cc: "'Padma Suresh'" , vkg@lucent.com, pete@tech-know-ware.com, sip@ietf.org Date: Thu, 5 Dec 2002 10:44:44 +0100 Message-ID: X-MIMETrack: Serialize by Router on FRMAIL25/FR/ALCATEL(Release 5.0.8 |June 18, 2001) at 12/05/2002 10:44:46 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Adam, I don't think there is any disagreement. I said that "However, you can say that the application "x" behaves as a B2BUA, and that the application "x" "needs to propagate" the a-header or the b-header etc. for the needs of the application. This is the choice of the application" So, I wanted to stress the fact that once again the behaviour of the B2BUA is depending on the application logic. Strictly speaking, I should have not said that the "application "x" needs to propagate" the a-header, etc. Instead, one should say that the application "x" choice is to generate the a-header on the UAC side with the same content of the a-header received in the UAS side. This means that the SIP dialog on the UAS side is terminated and that the B2BUA is generating another dialog on the UAC side. The criteria used by the application "x" to fill the a-header are strictly depending on the application logic, and this can be applied to any SIP header. Best regards Juan Carlos Adam Roach on 04/12/2002 21:55:15 To: Juan-Carlos ROJAS/FR/ALCATEL@ALCATEL, Adam Roach cc: "'Padma Suresh'" , vkg@lucent.com, pete@tech-know-ware.com, sip@ietf.org Subject: RE: [Sip] B2BUA & Max-Forwards Unless you were merely trying to agree at length with the final paragraph of my previous message, I'm afraid that you missed my point rather broadly. I'll reiterate the main point concisely: a B2BUA is a UAS attached to a UAC by application logic. Read that carefully: Part of a B2BUA is a UAS. That UAS is bound by RFC 3261 to certain behaviors. One of those behaviors is honoring "Require" headers. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Thu Dec 5 04:47:37 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05763 for ; Thu, 5 Dec 2002 04:47:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB59o8Q09417 for sip-archive@odin.ietf.org; Thu, 5 Dec 2002 04:50:08 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB59nrv09349; Thu, 5 Dec 2002 04:49:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB59jGv09232 for ; Thu, 5 Dec 2002 04:45:16 -0500 Received: from dharti.aplion.stpn.soft.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05598 for ; Thu, 5 Dec 2002 04:42:10 -0500 (EST) Received: from ravishiroor (localhost [127.0.0.1]) by dharti.aplion.stpn.soft.net (8.11.2/8.11.2) with SMTP id gB59k8s09574; Thu, 5 Dec 2002 15:16:08 +0530 From: "Ravi Shiroor" To: "Adam Roach" Cc: Subject: RE: [Sip] B2BUA & Max-Forwards Date: Thu, 5 Dec 2002 15:13:04 +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 V5.50.4910.0300 In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3A64383@DYN-TX-EXCH-001.dynamicsoft.com> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > Take, for example, the situation in which User A (at UAC(a)) > calls User B (at UAS(b)). They have a brief discussion, and > user B decides that he wants to add User C to the call; > using whatever interface is available, User B instructs his > client do so: User B (at UAC(b)) sends an INVITE request to > User C (at UAS(c)). User B decides to drop out of the call, > but instructs his device to keep the call up until one of > the parties disconnects. > > So User B's device, which was obviously the called party in > the initial phase of the call (by either the 3261 or any > reasonable and most unreasonable colloquial definitions), is > rather clearly acting as a B2BUA. > > /a > Looking at the above example and reading the discussions on this thread I am wondering why SIP RFC should even try to name or give definitions to such a device. I feel that SIP should only define behaviour of UACs, UASs and proxies; other intelliginet(?) devices are built using these as its communication interfaces should be out of scope of SIP. SIP RFC does say that the intelligence built in these devices are not in its scope, but it still tries to give a broad definition of the term B2BUA. I feel that also should not be done. It should restrict itself to defining terms which are used in the RFC to define the protocol itself. regards, ravi. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Thu Dec 5 04:49:38 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05795 for ; Thu, 5 Dec 2002 04:49:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB59qAB09513 for sip-archive@odin.ietf.org; Thu, 5 Dec 2002 04:52:10 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB59prv09482; Thu, 5 Dec 2002 04:51:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB59nqv09343 for ; Thu, 5 Dec 2002 04:49:52 -0500 Received: from avgw.vxserver.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA05736 for ; Thu, 5 Dec 2002 04:46:49 -0500 (EST) Received: from disney.internal.ridgewaysystems.com ([194.128.67.181]) by avgw.vxserver.com (NAVGW 2.5.2.12) with SMTP id M2002120509482419222 for ; Thu, 05 Dec 2002 09:48:24 GMT Received: from Unknown [10.1.1.1] by disney.internal.ridgewaysystems.com - SurfControl E-mail Filter (4.5); Thursday, 05 December 2002, 09:50:04 Received: by ridgeway.internal.ridgewaysystems.com with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Dec 2002 09:49:39 -0000 Message-ID: <00533D13955AD411AF3800A0C9B4263994D884@ridgeway.internal.ridgewaysystems.com> From: Phil Reynolds To: sip@ietf.org Date: Thu, 5 Dec 2002 09:49:38 -0000 Subject: RE: [Sip] B2BUA & Max-Forwards MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--=_NextPart_ST_09_50_04_Thursday_December_05_2002_1982" X-Mailer: Internet Mail Service (5.5.2653.19) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , 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_ST_09_50_04_Thursday_December_05_2002_1982 Content-Type: text/plain Our system isn't broken. I would say that this shows that the spec is broken not our system. Our system provides facilities for some (and we hope "most") users. We don't provide these facilities for all users because: A) We don't think they are important for most users, B) The spec precludes us from doing so (e.g. end-to-end security) But because the spec says we MUST do end-to-end security we can't be sanctioned as compliant, despite the fact that "most" of our users don't want that. (BTW I have yet to see a endpoint that does end-to-end security so it appears that these are all broken as well) -----Original Message----- From: Adam Roach [mailto:adam@dynamicsoft.com] Sent: 04 December 2002 20:45 To: 'Phil Reynolds'; sip@ietf.org Subject: RE: [Sip] B2BUA & Max-Forwards -----Original Message----- From: Phil Reynolds [mailto:preynolds@ridgewaysystems.com] > Now your back to restricting what I can and can't do in an > intermediary. It can't be a B2BUA 'cos it doesn't need to honour > require headers (the UA at the other end does that, if they were meant > for my intermediary then they would be proxy-require?), and it can't > be a proxy 'cos of the rules about not changing the body so what is > it? Broken. The restrictions placed on nodes by 3261 (which I'm merely reiterating, not imposing) aren't an authoritarian attempt at unnecessary proscription. They serve a purpose. I'll describe one of the (several) purposes that applies to the situation you propose. One of the things that UAs are required to be able to do is sign and/or encrypt the bodies and/or some subset of the headers to ensure confidentiality and/or integrity. The protocol places restrictions on various nodes to ensure that this can be done. Your box is broken precisely because it interferes with these abilities (or, more precisely, these abilities interfere with it). /a ----=_NextPart_ST_09_50_04_Thursday_December_05_2002_1982 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Sip] B2BUA & Max-Forwards

Our system isn't broken. I would say that this shows that= the spec is broken not our system.

Our system provides facilities for some (and we hope &quo= t;most") users. We don't provide these facilities for all users becaus= e: A) We don't think they are important for most users, B) The spec preclud= es us from doing so (e.g. end-to-end security)

But because the spec says we MUST do end-to-end security = we can't be sanctioned as compliant, despite the fact that "most"= of our users don't want that. (BTW I have yet to see a endpoint that does = end-to-end security so it appears that these are all broken as well)=

-----Original Message-----
From: Adam Roach [mailto:adam@dynamicsoft.com]
Sent: 04 December 2002 20:45
To: 'Phil Reynolds'; sip@ietf.org
Subject: RE: [Sip] B2BUA & Max-Forwards


-----Original Message-----
From: Phil Reynolds [mailto:preynolds@ridgewaysystems.com]

> Now your back to restricting what I can and can't do= in an
> intermediary. It can't be a B2BUA 'cos it doesn't n= eed to honour
> require headers (the UA at the other end does that,= if they were meant
> for my intermediary then they would be proxy-requir= e?), and it can't
> be a proxy 'cos of the rules about not changing the= body so what is
> it?

Broken.

The restrictions placed on nodes by 3261 (which I'm merel= y reiterating, not imposing) aren't an authoritarian attempt at unnecessary= proscription. They serve a purpose.

I'll describe one of the (several) purposes that applies<= /FONT>
to the situation you propose.

One of the things that UAs are required to be able to do = is sign and/or encrypt the bodies and/or some subset of the headers to ensu= re confidentiality and/or integrity. The protocol places restrictions on va= rious nodes to ensure that this can be done. Your box is broken precisely b= ecause it interferes with these abilities (or, more precisely, these abilit= ies interfere with it).

/a

----=_NextPart_ST_09_50_04_Thursday_December_05_2002_1982-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Thu Dec 5 05:18:15 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06492 for ; Thu, 5 Dec 2002 05:18:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB5AKa911057 for sip-archive@odin.ietf.org; Thu, 5 Dec 2002 05:20:36 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5AKHv11043; Thu, 5 Dec 2002 05:20:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5AHTv10937 for ; Thu, 5 Dec 2002 05:17:29 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06409 for ; Thu, 5 Dec 2002 05:14:38 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gB5AHSQ1026584 for ; Thu, 5 Dec 2002 11:17:28 +0100 (MET) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id YBCT2ZRB; Thu, 5 Dec 2002 11:17:28 +0100 Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.68]) by hendrix.lmf.ericsson.se (8.12.6/8.12.6/lmf-2.1-jcs) with ESMTP id gB5AHSu4027927 for ; Thu, 5 Dec 2002 12:17:28 +0200 (EET) Message-ID: <3DEF27BE.80ED31E2@lmf.ericsson.se> Date: Thu, 05 Dec 2002 12:17:34 +0200 X-Sybari-Trust: d2d12471 ca231590 0ab44ba3 00000138 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] ABNF issue Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, The ABNF syntax in RFC3261 says the following things: LWS = [*WSP CRLF] 1*WSP ; linear whitespace Request = Request-Line *( message-header ) CRLF [ message-body ] message-body = *OCTET Also, the syntax says that every message-header ends with CTRL. Now, the spec says that the SIP part of a message ends with CTRL CTRL. However, if the message-body part starts with one or more WSP, won't the CRLF between the message-body be interpreted as LWS instead? Ie, there will NOT be CRLF CRLF at the end of the SIP part of message, but instead CRLF LWS. I think this is a bug in the ABNF, since the message-body from a syntax point of view is part of the SIP messages, so they can't be "separated". Now, to solve this the ABNF needs to be changed, so that the definition for LWS is not valid at the beginning of a new line (when a message-header has been successfully parsed), ie LWS is only valid within headers. Then, if a new line starts with CRLF, is is CRLF no matter what comes after. Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Thu Dec 5 08:01:50 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09832 for ; Thu, 5 Dec 2002 08:01:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB5D4Bf20298 for sip-archive@odin.ietf.org; Thu, 5 Dec 2002 08:04:11 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5D3jv20285; Thu, 5 Dec 2002 08:03:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5D01v20152 for ; Thu, 5 Dec 2002 08:00:01 -0500 Received: from lutetium (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09751 for ; Thu, 5 Dec 2002 07:57:09 -0500 (EST) Received: from host213-122-42-93.in-addr.btopenworld.com ([213.122.42.93] helo=tkw) by lutetium with smtp (Exim 3.22 #16) id 18Jvbg-0005kD-00; Thu, 05 Dec 2002 12:59:56 +0000 Message-ID: <013b01c29c5d$e22bad40$0200000a@tkw> From: "Pete Cordell" To: "Henry Sinnreich" Cc: References: <000901c29bc7$b762fc30$248823a6@hsinnreich2> Subject: Re: [Sip] B2BUA Date: Thu, 5 Dec 2002 12:24:42 -0000 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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Henry, The Internet has had a few famous outages as well. Besides, if all the telco traffic was put over IP, with today's level of QoS on the Internet, it would have been brought to its knees also. To say that one is all goodness and light and the other all evil doesn't do us as a community any good as when customers find out there are problems they tend not to believe anything else we say! Only vapourware is flawless. Most people know that. Respect the intelligence of your customer, or they will find somebody that does!!! Pete. ----- Original Message ----- From: "Henry Sinnreich" To: "'Phil Reynolds'" ; Sent: 04 December 2002 19:02 Subject: RE: [Sip] B2BUA > >The telecoms people are clever enough to have thought > >about that and build redundancy, fault tolerance and failover into > their switches. > > This has proven unfortunately not to be the case on September 11 when > telecom service failed for days, while Internet traffic continued > smoothly. I suggest you to look at the central control model of the > switch network versus the e2e architecture of the Internet. SIP enabled > networks are also fully distributed and the e2e control principle > maintained - that's why state in placed in SIP endpoints. > > I am not sure if a few words here can give full justice to the superior > resilience of the Internet and to SIP enabled services,... > > Thanks, Henry > > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Phil > Reynolds > Sent: Wednesday, December 04, 2002 7:37 AM > To: sip@ietf.org > Subject: RE: [Sip] B2BUA > > > If a telephone switch crashes you loose all calls... The telecoms > people are clever enough to have thought about that and build > redundancy, fault tolerance and failover into their switches. > Maybe some of us IP-telecoms people have thought of similar techniques > for SIP intermediaries? > -----Original Message----- > From: Jiri Kuthan [mailto:jiri.kuthan@fokus.fraunhofer.de] > Sent: 04 December 2002 12:32 > To: Christian Huitema; Roy, Radhika R, ALASO; mbarnes@nortelnetworks.com > > Cc: dean.willis@softarmor.com; Juan-Carlos.Rojas@alcatel.fr; > sip@ietf.org > Subject: RE: [Sip] B2BUA > [...snip...] > I think there are more issues with B2BUA. A B2BUA's failure affects all > current calls :-( > -Jiri > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Thu Dec 5 08:03:52 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09891 for ; Thu, 5 Dec 2002 08:03:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB5D6DB20371 for sip-archive@odin.ietf.org; Thu, 5 Dec 2002 08:06:13 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5D5mv20357; Thu, 5 Dec 2002 08:05:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5D01v20156 for ; Thu, 5 Dec 2002 08:00:01 -0500 Received: from lutetium (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09754 for ; Thu, 5 Dec 2002 07:57:09 -0500 (EST) Received: from host213-122-42-93.in-addr.btopenworld.com ([213.122.42.93] helo=tkw) by lutetium with smtp (Exim 3.22 #16) id 18Jvbd-0005kD-00; Thu, 05 Dec 2002 12:59:53 +0000 Message-ID: <013901c29c5d$e02c81e0$0200000a@tkw> From: "Pete Cordell" To: "Jonathan Rosenberg" , "Adam Roach" Cc: "'Phil Reynolds'" , References: <9BF66EBF6BEFD942915B4D4D45C051F3A64377@DYN-TX-EXCH-001.dynamicsoft.com> <3DEEF411.2020408@dynamicsoft.com> Subject: Re: [Sip] B2BUA & Max-Forwards Date: Thu, 5 Dec 2002 11:46:30 -0000 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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit This is correct. A B2BUA can't blindly forward a request containing a Require header. The saving grace for a B2BUA is that it does not need to understand the extension in detail. It just needs to know whether it can forward a request that contains a given Require header. This can be easily provisioned using some sort of ASCII configuration file, and doesn't require any new code etc. A B2BUA could even routinely download the list of acceptable Require headers from some sort of server. (A smart B2BUA could even post back a set of unknown Require headers that it has seen recently.) Added to that, ideally extensions will avoid the need for specifying Require as much as possible. Thus the impact of Require headers is likely to be fairly minimal for most B2BUAs. As it is so easy to support the majority of Require extensions in a B2BUA, B2BUAs will likely support the extensions before the majority of actual UAs! (And a firewall related B2BUA really ought to be blocking what it doesn't understand anyway, so there is little conflict here also.) Pete. ----- Original Message ----- From: "Jonathan Rosenberg" To: "Adam Roach" Cc: "'Phil Reynolds'" ; Sent: 05 December 2002 06:37 Subject: Re: [Sip] B2BUA & Max-Forwards > inline. > > Adam Roach wrote: > > -----Original Message----- > > From: Phil Reynolds [mailto:preynolds@ridgewaysystems.com] > > > > > >>Now your back to restricting what I can and can't do in an > >>intermediary. It can't be a B2BUA 'cos it doesn't need to > >>honour require headers (the UA at the other end does that, > >>if they were meant for my intermediary then they would be > >>proxy-require?), and it can't be a proxy 'cos of the rules > >>about not changing the body so what is it? > > > > > > Broken. > > Adam is correct. > > > > > The restrictions placed on nodes by 3261 (which I'm merely > > reiterating, not imposing) aren't an authoritarian attempt > > at unnecessary proscription. They serve a purpose. > > > > I'll describe one of the (several) purposes that applies > > to the situation you propose. > > > > One of the things that UAs are required to be able to do is > > sign and/or encrypt the bodies and/or some subset of the > > headers to ensure confidentiality and/or integrity. The > > protocol places restrictions on various nodes to ensure > > that this can be done. Your box is broken precisely because > > it interferes with these abilities (or, more precisely, > > these abilities interfere with it). > > Let me add some more here. > > Anything that deviates at all from proxy rules will need to be a b2bua > and follow b2bua rules, including processing of Require. There is no > black-or-white here. Let me give some examples. > > Lets say my b2bua is a proxy in all ways, BUT it happens to muck with > SDP to enable firewall traversal. Surely then it can ignore Require, > right? WRONG. Lets say I define extension foo, which means "the content > of this SDP is not what it seems - look at this header to instead find > the real port/address for media". This extension needs a Require > (because only a UA ever looks at bodies), but not a Proxy-Require, > because proxies don't. Thus, your almost-a-proxy will fail in odd ways > because it has ignored Require when it shouldn't have. > > Indeed, for any operation prohibited to a proxy, but allowed for a UA, I > can come up with an extension, indicated in a Require header, that would > need to be understood by a b2bua which breaks the proxy rules and > performs this operation. Indeed, the rules on what is a UA, and what is > a proxy, are meant precisely to help define what goes in Require, and > what goes in Proxy-Require. > > Whether or not Require gets passed on by such a b2bua depends entirely > on the application logic. > > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.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 mailnull@www1.ietf.org Thu Dec 5 08:07:26 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10001 for ; Thu, 5 Dec 2002 08:07:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB5D9le21089 for sip-archive@odin.ietf.org; Thu, 5 Dec 2002 08:09:47 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5D9Vv21078; Thu, 5 Dec 2002 08:09:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5D04v20172 for ; Thu, 5 Dec 2002 08:00:04 -0500 Received: from lutetium (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09772 for ; Thu, 5 Dec 2002 07:57:12 -0500 (EST) Received: from host213-122-42-93.in-addr.btopenworld.com ([213.122.42.93] helo=tkw) by lutetium with smtp (Exim 3.22 #16) id 18Jvbi-0005kD-00; Thu, 05 Dec 2002 12:59:58 +0000 Message-ID: <013c01c29c5d$e3690f40$0200000a@tkw> From: "Pete Cordell" To: "Cullen Jennings" , References: Subject: Re: [Sip] B2BUA & Max-Forwards Date: Thu, 5 Dec 2002 12:38:00 -0000 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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Cullen, That's an interesting question. But I don't think that SIP to SS7 being a difficult problem should stop us recommending simple behaviour that can help protect the integrity of SIP networks where B2BUAs are involved. Pete. ----- Original Message ----- From: "Cullen Jennings" To: "Pete Cordell" ; Sent: 04 December 2002 02:44 Subject: RE: [Sip] B2BUA & Max-Forwards > > A related question to this was how to stop routing loops that included some > PSTN hops. One solution to this was to make sure that as a call was passed > from SIP to SS7 there was a mapping of the number of hops. A trivial 1:1 > mapping would be unlikely to work. > > I really don't really care that much if something like this is documented or > not but I imagine that some devices will do it to stop routing loops that > eat infinite amounts of resources. > > Cullen > > > > -----Original Message----- > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Pete > > Cordell > > Sent: Tuesday, December 03, 2002 9:44 AM > > To: sip@ietf.org > > Subject: [Sip] B2BUA & Max-Forwards > > > > > > One issue that the recent B2BUA discussion has raised in my mind is what a > > B2BUA (whatever its decided that should be) should do with Max-Forwards. > > > > This may have been discussed before, but while RFC 3261 says a B2BUA is a > > back to back UAS / UAC, and the coupling is not specified in the RFC, > > perhaps it ought to say that the max-forwards parameter MUST be propagated > > from the incoming request to the outgoing request using the same > > rules as a > > regular proxy. This would seem helpful for the avoidance of loops. > > > > Any comments? > > > > Pete. > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Thu Dec 5 08:08:43 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10022 for ; Thu, 5 Dec 2002 08:08:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB5DB4a21124 for sip-archive@odin.ietf.org; Thu, 5 Dec 2002 08:11:04 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5D7dv21020; Thu, 5 Dec 2002 08:07:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5D02v20160 for ; Thu, 5 Dec 2002 08:00:02 -0500 Received: from lutetium (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09767 for ; Thu, 5 Dec 2002 07:57:10 -0500 (EST) Received: from host213-122-42-93.in-addr.btopenworld.com ([213.122.42.93] helo=tkw) by lutetium with smtp (Exim 3.22 #16) id 18Jvbf-0005kD-00; Thu, 05 Dec 2002 12:59:55 +0000 Message-ID: <013a01c29c5d$e1591b00$0200000a@tkw> From: "Pete Cordell" To: "Dean Willis" , References: <00cd01c29bfc$e7dd0240$fe0c0c42@txdwillis> Subject: Re: [Sip] B2BUA & Max-Forwards Date: Thu, 5 Dec 2002 12:09:36 -0000 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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dean, Firstly, your statement that "The B2BUA doesn't change headers that transit it." seems inconsistent with the statement "It does the same thing as ... ANY 500-pound gorilla does". I don't understand. Secondly, I think max-forwards is a special case. It is important for the protection of SIP systems as it prevents loops. Indeed, there is a major difference between a UAS and a B2BUA and that is that the former terminates a request, and the latter terminates a request AND ALSO forwards an associated request (or more). The impact of this difference should be covered in the spec in the interests of protecting other SIP systems. Pete. ----- Original Message ----- From: "Dean Willis" To: "'Pete Cordell'" ; Sent: 05 December 2002 01:23 Subject: RE: [Sip] B2BUA & Max-Forwards > > One issue that the recent B2BUA discussion has raised in my > > mind is what a B2BUA (whatever its decided that should be) > > should do with Max-Forwards. > > It does the same thing as it does with any other header or body part, > which is the same thing that ANY 500-pound gorilla does to somebody's > body parts -- whatever it wants. > > What you're asking is "what is the transparency of this node with > respect to max-forwards", which is "#4 -- Header Transaprency" in my > top-10 list. The specification of a back-to-back user agent doesn't > mandate any level of transparency on this or any other header. > > -- > 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 mailnull@www1.ietf.org Thu Dec 5 08:09:14 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10041 for ; Thu, 5 Dec 2002 08:09:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB5DBZl21163 for sip-archive@odin.ietf.org; Thu, 5 Dec 2002 08:11:35 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5DBLv21151; Thu, 5 Dec 2002 08:11:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5D08v20178 for ; Thu, 5 Dec 2002 08:00:08 -0500 Received: from lutetium (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09775 for ; Thu, 5 Dec 2002 07:57:16 -0500 (EST) Received: from host213-122-42-93.in-addr.btopenworld.com ([213.122.42.93] helo=tkw) by lutetium with smtp (Exim 3.22 #16) id 18Jvbk-0005kD-00; Thu, 05 Dec 2002 13:00:01 +0000 Message-ID: <013d01c29c5d$e4a7f7e0$0200000a@tkw> From: "Pete Cordell" To: "Christian Huitema" Cc: References: Subject: Re: [Sip] B2BUA - Security Date: Thu, 5 Dec 2002 12:55:18 -0000 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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Christian, I'm afraid I think that end-to-end security of SDP is a complete red herring. I would say that encrypting and / or integrity checking of SDP alone achieves absolutely no security benefit. SDP really does two things. It specifies transport addresses and chosen codecs. Let's assume that you do encrypt the SDP and I can't read it. I can have a good guess at the transport addresses in use from many of the other fields in SIP such as via lines, To, From, uri, contact, route etc. By analysing the RTP traffic, I can easily find out what codec is being used, either because the packet tells me, or from other statistical characteristics. I have therefore discovered, with very little effort most of what I would find useful in SDP. (Ironically sending stuff to a media relay would make this slightly harder!!!) If you want security of the media, then you have to encrypt and integrity check the RTP. Encrypting SDP simply burns CPU cycles!!! (Put another way, encrypting SDP is another form of security by obscurity. And we all know what that means.) (Note that it may make sense to encrypt other bodies types, such as those that contain HTML, but this is a different case.) Pete. ----- Original Message ----- From: "Christian Huitema" To: "Roy, Radhika R, ALASO" ; Cc: ; ; Sent: 03 December 2002 16:35 Subject: RE: [Sip] B2BUA > > > [MB]: Some of this, of course, will lead us back to the > > > list of the reasons why some folks consider these things "evil", ... > > > > I do not remember whether anyone has ever said that B2BUA is evil > > things. What I remember is that the dumping of the B2BUA functionality > > in the name of SIP Proxy is an evil thing. > > The real issue in all this is security. Many security folks believe > that, in order to get proper security, the body of the signaling > messages should be signed, and possibly encrypted. In that logic, the > proxies only manipulate the information exposed in the SIP header, which > can be as little as the pair of source and destination URL. > > Any intermediary that attempts to "rewrite the SDP" has to somehow > insert itself in the end-to-end security exchange; many security folks > will resent that as "breaking end-to-end security". Insofar as SDP > rewriting attempts to provide a legitimate service, the challenge is > thus to provide the service in such a way that it does not require > breaking end-to-end encryption. > > -- Christian Huitema > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Thu Dec 5 08:13:04 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10103 for ; Thu, 5 Dec 2002 08:13:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB5DFPA21309 for sip-archive@odin.ietf.org; Thu, 5 Dec 2002 08:15:25 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5DEsv21267; Thu, 5 Dec 2002 08:14:54 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5DCXv21211 for ; Thu, 5 Dec 2002 08:12:33 -0500 Received: from protactinium (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10056 for ; Thu, 5 Dec 2002 08:09:40 -0500 (EST) Received: from host213-122-42-93.in-addr.btopenworld.com ([213.122.42.93] helo=tkw) by protactinium with smtp (Exim 3.22 #16) id 18Jvnf-0003PG-00; Thu, 05 Dec 2002 13:12:19 +0000 Message-ID: <016901c29c5f$996a4560$0200000a@tkw> From: "Pete Cordell" To: "Jonathan Rosenberg" , "William Marshall" Cc: References: <200212031329.IAA72497@fish.research.att.com> <3DEEF69C.5030709@dynamicsoft.com> Subject: Re: [Sip] B2BUA - (session policy fix) Date: Thu, 5 Dec 2002 13:09:38 -0000 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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jonathan, I agree with this whole heartedly. However, as I think SDP security is a red herring (see other mail), and the real issue is RTP end-to-end security, I would first like to explore whether all the necessary security issues can be tackled by using SIP as is rather than developing new extensions. That way we could get away with just an informational RFC, or perhaps some guidelines in 3261 bis. Pete. ----- Original Message ----- From: "Jonathan Rosenberg" ... > > As an example, a very common offense is mucking with SDP, for example, > to implement a firewall control proxy, ala midcom. Instead of defining a > new element, called an SDP-munging proxy, and dealing with all the > horrible security implications that will arise from it, I would propose > to simply FIX THE PROBLEM and define a means by which a proxy can impose > session policies without breaking SIP. Indeed, I wrote a draft on just > such a topic: > > http://www.jdrosen.net/papers/draft-rosenberg-sipping-session-policy-00.txt > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Thu Dec 5 08:21:55 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10306 for ; Thu, 5 Dec 2002 08:21:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB5DOGT21791 for sip-archive@odin.ietf.org; Thu, 5 Dec 2002 08:24:16 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5DNuv21769; Thu, 5 Dec 2002 08:23:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5DLav21696 for ; Thu, 5 Dec 2002 08:21:36 -0500 Received: from gbnewp0915s1.eu.ubiquity.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA10262 for ; Thu, 5 Dec 2002 08:18:44 -0500 (EST) Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net via smtpd (for [132.151.6.1]) with SMTP; 5 Dec 2002 13:21:04 UT X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] B2BUA & Max-Forwards Date: Thu, 5 Dec 2002 13:21:36 -0000 Message-ID: <45730E094814E44488F789C1CDED27AE018C2553@GBNEWP0758M.eu.ubiquity.net> Thread-Topic: [Sip] B2BUA & Max-Forwards Thread-Index: AcKcX0wj3H7Pg1ozRv6ugCok3XbcTgAAKJyA From: "James Undery" To: "Pete Cordell" , "Dean Willis" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gB5DLav21697 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi, I think your confusion comes from mixing two email threads; the first statement in context says if a specific B2BUA demonstrates header transparency it doesn't change headers; the second statement is about B2BUAs in general and says they can do whatever they want (without commenting on the desirability of their actions). Max-Forwards probably are an important case for your particular application, in general they may not be required (e.g. routing to an element you can guarantee not to proxy). Your comment on Max-Forwards highlights well the difficulties faced in defining a B2BUA more specifically than the definition in 3261. James > -----Original Message----- > From: Pete Cordell [mailto:pete@tech-know-ware.com] > Sent: 05 December 2002 12:10 > To: Dean Willis; sip@ietf.org > Subject: Re: [Sip] B2BUA & Max-Forwards > > > Dean, > > Firstly, your statement that "The B2BUA doesn't change > headers that transit > it." seems inconsistent with the statement "It does the same > thing as ... > ANY 500-pound gorilla does". I don't understand. > > Secondly, I think max-forwards is a special case. It is > important for the > protection of SIP systems as it prevents loops. > > Indeed, there is a major difference between a UAS and a B2BUA > and that is > that the former terminates a request, and the latter > terminates a request > AND ALSO forwards an associated request (or more). The impact of this > difference should be covered in the spec in the interests of > protecting > other SIP systems. > > Pete. > > ----- Original Message ----- > From: "Dean Willis" > To: "'Pete Cordell'" ; > Sent: 05 December 2002 01:23 > Subject: RE: [Sip] B2BUA & Max-Forwards > > > > > One issue that the recent B2BUA discussion has raised in my > > > mind is what a B2BUA (whatever its decided that should be) > > > should do with Max-Forwards. > > > > It does the same thing as it does with any other header or > body part, > > which is the same thing that ANY 500-pound gorilla does to > somebody's > > body parts -- whatever it wants. > > > > What you're asking is "what is the transparency of this node with > > respect to max-forwards", which is "#4 -- Header Transaprency" in my > > top-10 list. The specification of a back-to-back user agent doesn't > > mandate any level of transparency on this or any other header. > > > > -- > > 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 > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Thu Dec 5 08:47:21 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11069 for ; Thu, 5 Dec 2002 08:47:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB5Dnhm23702 for sip-archive@odin.ietf.org; Thu, 5 Dec 2002 08:49:43 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5DnLv23687; Thu, 5 Dec 2002 08:49:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5Dkfv23594 for ; Thu, 5 Dec 2002 08:46:41 -0500 Received: from beamer.mchh.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10983 for ; Thu, 5 Dec 2002 08:43:48 -0500 (EST) Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id OAA02728; Thu, 5 Dec 2002 14:46:33 +0100 (MET) Received: from mchh253e.mchh.siemens.de ([139.21.200.63]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id OAA04176; Thu, 5 Dec 2002 14:46:32 +0100 (MET) Received: by MCHH253E with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Dec 2002 14:45:54 +0100 Message-ID: <1D82815C322BD41196EA00508B951F7B067A4B2C@MCHH265E> From: Liebhart Rainer To: "'Pete Cordell'" , Henry Sinnreich Cc: sip@ietf.org Subject: AW: [Sip] B2BUA Date: Thu, 5 Dec 2002 14:45:51 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gB5Dkkv23597 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Henry, unfortunately you are comparing apples and pears when stating that the telecom service failed for days after Sept 11, while Internet traffic continued smoothly. The mentioned "telefon service" consists of thousands of (real-time) calls to emergency centres while the Internet traffic consists mainly of requests to the Web pages of CNN and others (with bad response times) to retrieve *information* on the status of the catastrophe. Rainer -----Ursprüngliche Nachricht----- Von: Pete Cordell [mailto:pete@tech-know-ware.com] Gesendet: Donnerstag, 5. Dezember 2002 13:25 An: Henry Sinnreich Cc: sip@ietf.org Betreff: Re: [Sip] B2BUA Henry, The Internet has had a few famous outages as well. Besides, if all the telco traffic was put over IP, with today's level of QoS on the Internet, it would have been brought to its knees also. To say that one is all goodness and light and the other all evil doesn't do us as a community any good as when customers find out there are problems they tend not to believe anything else we say! Only vapourware is flawless. Most people know that. Respect the intelligence of your customer, or they will find somebody that does!!! Pete. ----- Original Message ----- From: "Henry Sinnreich" To: "'Phil Reynolds'" ; Sent: 04 December 2002 19:02 Subject: RE: [Sip] B2BUA > >The telecoms people are clever enough to have thought > >about that and build redundancy, fault tolerance and failover into > their switches. > > This has proven unfortunately not to be the case on September 11 when > telecom service failed for days, while Internet traffic continued > smoothly. I suggest you to look at the central control model of the > switch network versus the e2e architecture of the Internet. SIP enabled > networks are also fully distributed and the e2e control principle > maintained - that's why state in placed in SIP endpoints. > > I am not sure if a few words here can give full justice to the superior > resilience of the Internet and to SIP enabled services,... > > Thanks, Henry > > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Phil > Reynolds > Sent: Wednesday, December 04, 2002 7:37 AM > To: sip@ietf.org > Subject: RE: [Sip] B2BUA > > > If a telephone switch crashes you loose all calls... The telecoms > people are clever enough to have thought about that and build > redundancy, fault tolerance and failover into their switches. > Maybe some of us IP-telecoms people have thought of similar techniques > for SIP intermediaries? > -----Original Message----- > From: Jiri Kuthan [mailto:jiri.kuthan@fokus.fraunhofer.de] > Sent: 04 December 2002 12:32 > To: Christian Huitema; Roy, Radhika R, ALASO; mbarnes@nortelnetworks.com > > Cc: dean.willis@softarmor.com; Juan-Carlos.Rojas@alcatel.fr; > sip@ietf.org > Subject: RE: [Sip] B2BUA > [...snip...] > I think there are more issues with B2BUA. A B2BUA's failure affects all > current calls :-( > -Jiri > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Thu Dec 5 08:49:52 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11199 for ; Thu, 5 Dec 2002 08:49:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB5DqEx23962 for sip-archive@odin.ietf.org; Thu, 5 Dec 2002 08:52:14 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5Dprv23859; Thu, 5 Dec 2002 08:51:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5DnGv23677 for ; Thu, 5 Dec 2002 08:49:16 -0500 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11053 for ; Thu, 5 Dec 2002 08:46:23 -0500 (EST) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id gB5Dn9LW028273; Thu, 5 Dec 2002 05:49:09 -0800 (PST) Received: from ORANLT.cisco.com ([161.44.238.36]) by mira-sjc5-9.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id EBM00054; Thu, 5 Dec 2002 05:49:29 -0800 (PST) Date: Thu, 05 Dec 2002 08:48:57 -0500 From: "David R. Oran" To: Padma Suresh , vkg@lucent.com cc: pete@tech-know-ware.com, sip@ietf.org Subject: Re: [Sip] B2BUA & Max-Forwards Message-ID: <2173925.1039078137@ORANLT.cisco.com> In-Reply-To: References: X-Mailer: Mulberry/3.0.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit --On Wednesday, December 04, 2002 4:50 PM +0000 Padma Suresh wrote: > > > > A B2BUA is an intermediate network element no it isn't. It's one or more UA's in the same box communicating with each other using some private machinery, such as an API+application code. Calling a B2BUA an intermediate network element is probably where most of the nonsense on this thread originates. Perhaps that's the basic clarification we need in the description to avoid these incorrect expectations? >and MUST maintain the > expectations of the endpoints involved in the session. > Also incorrect. Since the B2BUA is at least 2 UA's its job is to SEPARATELY maintain the expectations of EACH endpoint it is talking to. This does not infer ANY transitivity properties across a B2BUA at all; in fact, if you wanted well-defined transitivity you would have put in a proxy instead. > Not forwarding the Require or Expires headers (and some more) would break > the above which would not be quite acceptable. > Disagree vociferiously. As others have pointed out, it is crucial to NOT forward any headers. You MUST consume them and process them on receipt. You must GENERATE and send them on transmit. What happens in between is whatever algorithm or algorithms the application doing the B2BUA functions deems appropriate. If there is any relationship at all between the input and the output, that relationship is established by the the application logic. If the application logic performs the identity mapping, then that is what the application thinks is the appropriate thing to do. If the application logic (for example) decrements Max-Forwards by 42 because Douglas Adam's probate attorney wrote it, that's ok too (as long as the result is >0 of course...). > However, yes, the B2BUA can choose to step out of the signalling path by > setting the contact header to the appropriate endpoint. > It is not *in* the signaling path. > Vijay I agree that the ambiguity of choosing which header to pass on and > which not, could be well avoided. > > Regards > > Padma > If this level of misunderstanding of SIP persists by having the spec talk about B2BUAs, then perhaps the best this to do is the radical step of simply removing all references to them and banning the term from the lexicon. Dave. > > >> From: "Vijay K. Gurbani" >> To: Padma Suresh >> CC: pete@tech-know-ware.com, sip@ietf.org >> Subject: Re: [Sip] B2BUA & Max-Forwards >> Date: Wed, 04 Dec 2002 09:21:11 -0600 >> >> Padma Suresh wrote: >>> Vijay, >>> >>> You are right - >>> >>> A B2BUA needs to propagate some of the headers received in a >>> request/response to the other endpoint. >> >> Choosing which headers should be passed by a B2BUA and which not is >> exactly the ambiguity that we should AVOID, as I pointed out in my >> my response to the original poster. As others have expressed, we >> may >> try to taxonomize different types of B2BUAs, but each will have a >> different manner of handling the headers (depending on the >> application >> being realized by that particular B2BUA). >> >> An anonymizer B2BUA may change To, From, Contact, etc, for instance >> (and >> maintain internal state). A network-hiding B2BUA may scrap all Via >> headers coming in and only expose one Via header going out. The >> possibilities are endless. >> >>> Example: Require, Expires to name a few. This is because these >>> headers actually are relevant end to end. >> >> A B2BUA may decide to consume the Require and change the Expires >> header >> (maybe decrease its value) before sending it downstream, thus >> causing >> havoc with the expectations of the sending UAC. >> >>> However, some of the other headers like Contact should be set >>> by the B2BUA as itself. >> >> Likewise, I can imagine a B2BUA which rendezvous two users and steps >> out of subsequent signaling. Thus the Contact it sends to each of >> the users is that of the other peer. >> >> I would strongly *stay away* from prescribing which headers must be >> passed by a B2BUA and which must not. >> >> Regards, >> >> - vijay >> -- >> Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} >> Wireless Networks Group/Internet Software and Services >> Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm >> 6G-440 >> Naperville, Illinois 60566 Voice: +1 630 224 0216 >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > > > __________________________________________________ > Tired of spam? Get advanced junk mail protection with MSN > 8._______________________________________________ Sip mailing list > https://www1.ietf.org/mailman/listinfo/sip This list is for NEW > development of the core SIP Protocol Use sip-implementors@cs.columbia.edu > for questions on current sip Use sipping@ietf.org for new developments on > the application of sip ------------------------ David R. Oran Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 Office: +1 978 264 2048 VoIP: +1 408 571 4576 Email: oran@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 mailnull@www1.ietf.org Thu Dec 5 09:03:23 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11734 for ; Thu, 5 Dec 2002 09:03:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB5E5jl24595 for sip-archive@odin.ietf.org; Thu, 5 Dec 2002 09:05:45 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5E5Jv24571; Thu, 5 Dec 2002 09:05:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5E2iv24466 for ; Thu, 5 Dec 2002 09:02:44 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11600 for ; Thu, 5 Dec 2002 08:59:51 -0500 (EST) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id gB5E2M0J009273; Thu, 5 Dec 2002 06:02:22 -0800 (PST) Received: from ORANLT.cisco.com ([161.44.238.36]) by mira-sjc5-9.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id EBM00250; Thu, 5 Dec 2002 06:03:01 -0800 (PST) Date: Thu, 05 Dec 2002 09:02:29 -0500 From: "David R. Oran" To: Pete Cordell , Dean Willis , sip@ietf.org Subject: Re: [Sip] B2BUA & Max-Forwards Message-ID: <2986103.1039078949@ORANLT.cisco.com> In-Reply-To: <013a01c29c5d$e1591b00$0200000a@tkw> References: <00cd01c29bfc$e7dd0240$fe0c0c42@txdwillis> <013a01c29c5d$e1591b00$0200000a@tkw> X-Mailer: Mulberry/3.0.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit --On Thursday, December 05, 2002 12:09 PM +0000 Pete Cordell wrote: > Dean, > > Firstly, your statement that "The B2BUA doesn't change headers that > transit it." seems inconsistent with the statement "It does the same > thing as ... ANY 500-pound gorilla does". I don't understand. > > Secondly, I think max-forwards is a special case. It is important for the > protection of SIP systems as it prevents loops. > Once a dialog is terminated at a UAS it's up to the application to do loop prevention. SIP is not involved any more. The application could compute a value of Max-forwards for initiating outgoing calls based on incoming calls which preserves the "strictly decreasing" invariant, or alternatively it could just use the default MAx-Forwards in outgoing requests and execute a contant memory loop suppression algorithm such as Knuth's even-odd iterator. In either event the SIP spec(s) need say nothing about this. > Indeed, there is a major difference between a UAS and a B2BUA and that is > that the former terminates a request, and the latter terminates a request > AND ALSO forwards an associated request (or more). I disagree. A UAS is a UAS. It's behavior is completely specified by RFC3261 (unless there's a hole in the spec of course...). What it means to originate (NOT FORWARD!!!!) an "associated request" is completely application dependent. If I program my child's phone to initiate a SIP call to my surrepititious recording device every time it receives a call and give that device first chance to over-ride policy of the child's phone is the phone a B2BUA? Yes, no, maybe so, but who cares? Tell me what the applciation is and I can write some specs for that application and how it has to originate, terminate and process SIP transactions to do that application. I think the botom line is that there is not a single, well defined appliation that one can point to and say "that's a B2BUA". > The impact of this > difference should be covered in the spec in the interests of protecting > other SIP systems. > I disagree. > Pete. > > ----- Original Message ----- > From: "Dean Willis" > To: "'Pete Cordell'" ; > Sent: 05 December 2002 01:23 > Subject: RE: [Sip] B2BUA & Max-Forwards > > >> > One issue that the recent B2BUA discussion has raised in my >> > mind is what a B2BUA (whatever its decided that should be) >> > should do with Max-Forwards. >> >> It does the same thing as it does with any other header or body part, >> which is the same thing that ANY 500-pound gorilla does to somebody's >> body parts -- whatever it wants. >> >> What you're asking is "what is the transparency of this node with >> respect to max-forwards", which is "#4 -- Header Transaprency" in my >> top-10 list. The specification of a back-to-back user agent doesn't >> mandate any level of transparency on this or any other header. >> >> -- >> 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 ------------------------ David R. Oran Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 Office: +1 978 264 2048 VoIP: +1 408 571 4576 Email: oran@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 mailnull@www1.ietf.org Thu Dec 5 09:29:11 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13054 for ; Thu, 5 Dec 2002 09:29:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB5EVXL26843 for sip-archive@odin.ietf.org; Thu, 5 Dec 2002 09:31:33 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5EVEv26819; Thu, 5 Dec 2002 09:31:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5ESvv26697 for ; Thu, 5 Dec 2002 09:28:57 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12884; Thu, 5 Dec 2002 09:26:03 -0500 (EST) Message-Id: <200212051426.JAA12884@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 05 Dec 2002 09:26:03 -0500 Subject: [Sip] I-D ACTION:draft-ietf-sip-refer-07.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : The SIP Refer Method Author(s) : R. Sparks Filename : draft-ietf-sip-refer-07.txt Pages : 23 Date : 2002-12-4 This document defines the REFER method. This SIP extension requests that the recipient REFER to a resource provided in the request. It provides a mechanism allowing the party sending the REFER to be notified of the outcome of the referenced request. This can be used to enable many applications, including call transfer. In addition to the REFER method, this document defines the the refer event package and the Refer-To request header. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-refer-07.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-refer-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-refer-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-12-4095951.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-refer-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-refer-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-12-4095951.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Thu Dec 5 09:38:06 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13578 for ; Thu, 5 Dec 2002 09:38:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB5EeSb28122 for sip-archive@odin.ietf.org; Thu, 5 Dec 2002 09:40:28 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5Edsv28042; Thu, 5 Dec 2002 09:39:54 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5Ebbv27908 for ; Thu, 5 Dec 2002 09:37:37 -0500 Received: from hsr.ch (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13446 for ; Thu, 5 Dec 2002 09:34:42 -0500 (EST) Received: from [152.96.193.8] (account ) by hsr.ch (CommuniGate Pro WebUser 3.5.9) with HTTP id 5445140 for ; Thu, 05 Dec 2002 15:37:31 +0100 From: "C. Boesch" To: sip@ietf.org X-Mailer: CommuniGate Pro Web Mailer v.3.5.9 Date: Thu, 05 Dec 2002 15:37:31 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [Sip] SIP signaling QoS Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi all, we are two students at the university of applied sciences in Rapperswil (Switzerland). Currently we're working on a student research project concerning the use of SIP in a policy based network. Therefore we're looking for information on this topic. We've already read RFC 3312 (Integration of Resource Management and Session Initiation Protocol) and the draft "SIP Extensions for QoS support" by L. Veltri. Does anybody know if there exist any other approaches/solutions for using SIP signaling QoS? We're looking forward to hearing from you. Kind regards C. Boesch cboesch@hsr.ch _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Thu Dec 5 09:41:06 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13822 for ; Thu, 5 Dec 2002 09:41:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB5EhTL28388 for sip-archive@odin.ietf.org; Thu, 5 Dec 2002 09:43:29 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5Egrv28291; Thu, 5 Dec 2002 09:42:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5EdDv28005 for ; Thu, 5 Dec 2002 09:39:13 -0500 Received: from zsc3s004.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13509 for ; Thu, 5 Dec 2002 09:36:18 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by zsc3s004.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gB5Ed6307934; Thu, 5 Dec 2002 06:39:06 -0800 (PST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gB5EdH726159; Thu, 5 Dec 2002 08:39:18 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Dec 2002 08:39:04 -0600 Message-ID: <1B54FA3A2709D51195C800508BF9386A05A7CB30@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'Liebhart Rainer'" , "'Pete Cordell'" , Henry Sinnreich Cc: sip@ietf.org Subject: RE: [Sip] B2BUA Date: Thu, 5 Dec 2002 08:39:03 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C29C6C.0EB96FB0" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , 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_01C29C6C.0EB96FB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Rainer, Henry was referring to was the fact that SIP calls were able to be made = on the Internet when the phone system in the NYC area was not available = for use by Columbia University, per the following thread: http://www1.ietf.org/mail-archive/working-groups/sip/current/msg01026.ht= ml Mary. -----Original Message----- From: Liebhart Rainer [mailto:rainer.liebhart@siemens.com] Sent: Thursday, December 05, 2002 7:46 AM To: 'Pete Cordell'; Henry Sinnreich Cc: sip@ietf.org Subject: AW: [Sip] B2BUA Henry, unfortunately you are comparing apples and pears when stating that the telecom service failed for days after Sept 11, while Internet traffic continued smoothly. The mentioned "telefon service" consists of = thousands of (real-time) calls to emergency centres while the Internet traffic = consists mainly of requests to the Web pages of CNN and others (with bad = response times) to retrieve *information* on the status of the catastrophe. Rainer -----Urspr=FCngliche Nachricht----- Von: Pete Cordell [mailto:pete@tech-know-ware.com] Gesendet: Donnerstag, 5. Dezember 2002 13:25 An: Henry Sinnreich Cc: sip@ietf.org Betreff: Re: [Sip] B2BUA Henry, The Internet has had a few famous outages as well. Besides, if all the telco traffic was put over IP, with today's level of QoS on the = Internet, it would have been brought to its knees also. To say that one is all goodness and light and the other all evil = doesn't do us as a community any good as when customers find out there are = problems they tend not to believe anything else we say! Only vapourware is flawless. Most people know that. Respect the intelligence of your customer, or they will find somebody that does!!! Pete. ----- Original Message ----- From: "Henry Sinnreich" To: "'Phil Reynolds'" ; Sent: 04 December 2002 19:02 Subject: RE: [Sip] B2BUA > >The telecoms people are clever enough to have thought > >about that and build redundancy, fault tolerance and failover into > their switches. > > This has proven unfortunately not to be the case on September 11 when > telecom service failed for days, while Internet traffic continued > smoothly. I suggest you to look at the central control model of the > switch network versus the e2e architecture of the Internet. SIP = enabled > networks are also fully distributed and the e2e control principle > maintained - that's why state in placed in SIP endpoints. > > I am not sure if a few words here can give full justice to the = superior > resilience of the Internet and to SIP enabled services,... > > Thanks, Henry > > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of = Phil > Reynolds > Sent: Wednesday, December 04, 2002 7:37 AM > To: sip@ietf.org > Subject: RE: [Sip] B2BUA > > > If a telephone switch crashes you loose all calls... The telecoms > people are clever enough to have thought about that and build > redundancy, fault tolerance and failover into their switches. > Maybe some of us IP-telecoms people have thought of similar = techniques > for SIP intermediaries? > -----Original Message----- > From: Jiri Kuthan [mailto:jiri.kuthan@fokus.fraunhofer.de] > Sent: 04 December 2002 12:32 > To: Christian Huitema; Roy, Radhika R, ALASO; = mbarnes@nortelnetworks.com > > Cc: dean.willis@softarmor.com; Juan-Carlos.Rojas@alcatel.fr; > sip@ietf.org > Subject: RE: [Sip] B2BUA > [...snip...] > I think there are more issues with B2BUA. A B2BUA's failure affects = all > current calls :-( > -Jiri > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 ------_=_NextPart_001_01C29C6C.0EB96FB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] B2BUA

Hi Rainer,

Henry was referring to was the fact that SIP calls = were able to be made on the Internet when the phone system in the NYC = area was not available for use by Columbia University, per the = following thread:

http://www1.ietf.org/mail-archive/working-groups/sip/c= urrent/msg01026.html

Mary.

-----Original Message-----
From: Liebhart Rainer [mailto:rainer.liebhart@sieme= ns.com]
Sent: Thursday, December 05, 2002 7:46 AM
To: 'Pete Cordell'; Henry Sinnreich
Cc: sip@ietf.org
Subject: AW: [Sip] B2BUA


Henry,

unfortunately you are comparing apples and pears when = stating that the telecom service failed for days after Sept 11, while = Internet traffic continued smoothly. The mentioned "telefon = service" consists of thousands of (real-time) calls to emergency = centres while the Internet traffic consists mainly of requests to the = Web pages of CNN and others (with bad response times) to retrieve = *information* on the status of the catastrophe.

Rainer


-----Urspr=FCngliche Nachricht-----
Von: Pete Cordell [mailto:pete@tech-know-ware.com]
Gesendet: Donnerstag, 5. Dezember 2002 13:25
An: Henry Sinnreich
Cc: sip@ietf.org
Betreff: Re: [Sip] B2BUA


Henry,

The Internet has had a few famous outages as = well.  Besides, if all the
telco traffic was put over IP, with today's level of = QoS on the Internet, it
would have been brought to its knees also.

To say that one is all goodness and light and the = other all evil doesn't do
us as a community any good as when customers find = out there are problems
they tend not to believe anything else we = say!

Only vapourware is flawless.  Most people know = that.  Respect the
intelligence of your customer, or they will find = somebody that does!!!

Pete.

----- Original Message -----
From: "Henry Sinnreich" = <Henry.Sinnreich@wcom.com>
To: "'Phil Reynolds'" = <preynolds@ridgewaysystems.com>; <sip@ietf.org>
Sent: 04 December 2002 19:02
Subject: RE: [Sip] B2BUA


> >The telecoms people are clever enough to = have thought
> >about that and build redundancy, fault = tolerance and failover into
> their switches.
>
> This has proven unfortunately not to be the = case on September 11 when
> telecom service failed for days, while Internet = traffic continued
> smoothly. I suggest you to look at the central = control model of the
> switch network versus the e2e architecture of = the Internet. SIP enabled
> networks are also fully distributed and the e2e = control principle
> maintained - that's why state in placed in SIP = endpoints.
>
> I am not sure if a few words here can give full = justice to the superior
> resilience of the Internet and to SIP enabled = services,...
>
> Thanks, Henry
>
> -----Original Message-----
> From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On = Behalf Of Phil
> Reynolds
> Sent: Wednesday, December 04, 2002 7:37 = AM
> To: sip@ietf.org
> Subject: RE: [Sip] B2BUA
>
>
> If a telephone switch crashes you loose all = calls...  The telecoms
> people are clever enough to have thought about = that and build
> redundancy, fault tolerance and failover into = their switches.
> Maybe some of us IP-telecoms people have = thought of similar techniques
> for SIP intermediaries?
> -----Original Message-----
> From: Jiri Kuthan [mailto:jiri.kuthan@fokus= .fraunhofer.de]
> Sent: 04 December 2002 12:32
> To: Christian Huitema; Roy, Radhika R, ALASO; = mbarnes@nortelnetworks.com
>
> Cc: dean.willis@softarmor.com; = Juan-Carlos.Rojas@alcatel.fr;
> sip@ietf.org
> Subject: RE: [Sip] B2BUA
> [...snip...]
> I think there are more issues with B2BUA. A = B2BUA's failure affects all
> current calls :-(
> -Jiri
> = _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core = SIP 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

------_=_NextPart_001_01C29C6C.0EB96FB0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Thu Dec 5 09:47:11 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14263 for ; Thu, 5 Dec 2002 09:47:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB5EnYQ29023 for sip-archive@odin.ietf.org; Thu, 5 Dec 2002 09:49:34 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5Emvv28951; Thu, 5 Dec 2002 09:48:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5Ekfv28762 for ; Thu, 5 Dec 2002 09:46:41 -0500 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13984 for ; Thu, 5 Dec 2002 09:43:47 -0500 (EST) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB5EkbK0002138; Thu, 5 Dec 2002 06:46:37 -0800 (PST) Received: from ORANLT.cisco.com ([161.44.238.36]) by mira-sjc5-9.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id EBP00026; Thu, 5 Dec 2002 06:46:58 -0800 (PST) Date: Thu, 05 Dec 2002 09:45:06 -0500 From: "David R. Oran" To: Pete Cordell , Christian Huitema cc: sip@ietf.org Subject: Re: [Sip] B2BUA - Security Message-ID: <5543400.1039081506@ORANLT.cisco.com> In-Reply-To: <013d01c29c5d$e4a7f7e0$0200000a@tkw> References: <013d01c29c5d$e4a7f7e0$0200000a@tkw> X-Mailer: Mulberry/3.0.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit --On Thursday, December 05, 2002 12:55 PM +0000 Pete Cordell wrote: > Christian, > > I'm afraid I think that end-to-end security of SDP is a complete red > herring. > > I would say that encrypting and / or integrity checking of SDP alone > achieves absolutely no security benefit. > > SDP really does two things. It specifies transport addresses and chosen > codecs. > ...and carries keys for SRTP...hmmmmmmmm........ > Let's assume that you do encrypt the SDP and I can't read it. > > I can have a good guess at the transport addresses in use from many of the > other fields in SIP such as via lines, To, From, uri, contact, route etc. > Uh huh, sure. My experience is that you can only guess with reasonable probability by knowing the implementation details of the UAs. I remember we changed the RTP port allocation algorithm on IOS and all of a sudden people started screaming because their ACL filters "stopped working". Trying to beat the devil seem a pretty poor direction. > By analysing the RTP traffic, I can easily find out what codec is being > used, either because the packet tells me, or from other statistical > characteristics. > Really? Maybe for the standard codecs but why on earth bother? > I have therefore discovered, with very little effort most of what I would > find useful in SDP. (Ironically sending stuff to a media relay would make > this slightly harder!!!) > > If you want security of the media, then you have to encrypt and integrity > check the RTP. > or put it through an IPSEC tunnel. What's the point? > Encrypting SDP simply burns CPU cycles!!! > No, it prevents media hijacking by a MITM. > (Put another way, encrypting SDP is another form of security by obscurity. > And we all know what that means.) > Disagree vociferously. > (Note that it may make sense to encrypt other bodies types, such as those > that contain HTML, but this is a different case.) > > Pete. > Dave. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Thu Dec 5 11:19:39 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18077 for ; Thu, 5 Dec 2002 11:19:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB5GM2p02969 for sip-archive@odin.ietf.org; Thu, 5 Dec 2002 11:22:02 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5GL3v02924; Thu, 5 Dec 2002 11:21:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5GGxv02728 for ; Thu, 5 Dec 2002 11:16:59 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17912 for ; Thu, 5 Dec 2002 11:14:04 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.83]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gB5GGtYH012535; Thu, 5 Dec 2002 11:16:57 -0500 (EST) Message-ID: <3DEF7BF4.5070706@dynamicsoft.com> Date: Thu, 05 Dec 2002 11:16:52 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pete Cordell CC: Adam Roach , "'Phil Reynolds'" , sip@ietf.org Subject: Re: [Sip] B2BUA & Max-Forwards References: <9BF66EBF6BEFD942915B4D4D45C051F3A64377@DYN-TX-EXCH-001.dynamicsoft.com> <3DEEF411.2020408@dynamicsoft.com> <013901c29c5d$e02c81e0$0200000a@tkw> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Pete Cordell wrote: > This is correct. A B2BUA can't blindly forward a request containing a > Require header. > > The saving grace for a B2BUA is that it does not need to understand the > extension in detail. It just needs to know whether it can forward a request > that contains a given Require header. This can be easily provisioned using > some sort of ASCII configuration file, and doesn't require any new code etc. > A B2BUA could even routinely download the list of acceptable Require headers > from some sort of server. (A smart B2BUA could even post back a set of > unknown Require headers that it has seen recently.) This is a vast over-simplification. As people have been saying over and over in this thread, there is no such thing as a "generic b2bua" as you seem to be implying. What is right in a b2bua depends entirely on what its doing. To be honest, I can't think of any b2bua for which the processing you describe above is sensible. As I mentioned in a previous note, a b2bua deviates from a proxy by doing some featurs that are normally associated with a UA. That b2bua will need to process extensions (i.e., implement them) that are associated with that feature. I am at the point where I agree with the sentiment raised by others, that we should remove the term b2bua entirely from the specification. It has caused more confusion than anything else. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.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 mailnull@www1.ietf.org Thu Dec 5 11:29:48 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18456 for ; Thu, 5 Dec 2002 11:29:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB5GWCa03484 for sip-archive@odin.ietf.org; Thu, 5 Dec 2002 11:32:12 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5GV8v03435; Thu, 5 Dec 2002 11:31:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5GSWv03272 for ; Thu, 5 Dec 2002 11:28:32 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18383 for ; Thu, 5 Dec 2002 11:25:37 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.83]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gB5GSUYH012551; Thu, 5 Dec 2002 11:28:30 -0500 (EST) Message-ID: <3DEF7EAB.2070109@dynamicsoft.com> Date: Thu, 05 Dec 2002 11:28:27 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pete Cordell CC: Christian Huitema , sip@ietf.org Subject: Re: [Sip] B2BUA - Security References: <013d01c29c5d$e4a7f7e0$0200000a@tkw> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Pete Cordell wrote: > I would say that encrypting and / or integrity checking of SDP alone > achieves absolutely no security benefit. Really?? Wow. I actually think it prevents the most devastating attacks against SIP. These include: 1. modifying SDP in transit to point media streams to an intermediate recording device, allowing attackers to establish wiretaps 2. downgrading any SRTP keying done in SDP, so that the media itself is not encrypted or integrity protected (this came up during the mmusic session in IETF as a driver for S/MIME) 3. launching a DoS attack by sending everyones voice traffic to the intended target. You get huge amplification gains here. Very appealing for hackers! > > SDP really does two things. It specifies transport addresses and chosen > codecs. > > Let's assume that you do encrypt the SDP and I can't read it. > > I can have a good guess at the transport addresses in use from many of the > other fields in SIP such as via lines, To, From, uri, contact, route etc. Confidentiality is only one property of security. I am much more concerned about message integrity. > (Put another way, encrypting SDP is another form of security by obscurity. > And we all know what that means.) I have no idea how you would arrive at such a conclusion. Security through obscurity means that information is not cryptographically protected, but encoded with a known process that is just a bit complicated. By definition, this is not encryption. Perhaps you have discovered some new flaws in encryption technology? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.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 mailnull@www1.ietf.org Thu Dec 5 11:34:09 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18571 for ; Thu, 5 Dec 2002 11:34:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB5GaXX03678 for sip-archive@odin.ietf.org; Thu, 5 Dec 2002 11:36:33 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5GYov03578; Thu, 5 Dec 2002 11:34:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5GWNv03503 for ; Thu, 5 Dec 2002 11:32:23 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18447 for ; Thu, 5 Dec 2002 11:29:28 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.83]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gB5GWGYH012563; Thu, 5 Dec 2002 11:32:17 -0500 (EST) Message-ID: <3DEF7F8D.70902@dynamicsoft.com> Date: Thu, 05 Dec 2002 11:32:13 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christer Holmberg CC: sip@ietf.org Subject: Re: [Sip] ABNF issue References: <3DEF27BE.80ED31E2@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit inline. Christer Holmberg wrote: > Hi, > > The ABNF syntax in RFC3261 says the following things: > > LWS = [*WSP CRLF] 1*WSP ; linear whitespace > > Request = Request-Line > *( message-header ) > CRLF > [ message-body ] > > message-body = *OCTET > > Also, the syntax says that every message-header ends with CTRL. > > Now, the spec says that the SIP part of a message ends with CTRL CTRL. > > However, if the message-body part starts with one or more WSP, won't the > > CRLF between the message-body be interpreted as LWS instead? Ie, there > will NOT be CRLF CRLF at the end of the SIP part of message, but instead > > CRLF LWS. I don't know how you come to this conclusion. If the body starts with LWS, you will see a CRLF after the last header field, another CRLF before the body, and then an LWS which is the first byte of the body. Thus: CRLF CRLF LWS which is fine. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.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 mailnull@www1.ietf.org Thu Dec 5 11:38:12 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18697 for ; Thu, 5 Dec 2002 11:38:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB5Geai04504 for sip-archive@odin.ietf.org; Thu, 5 Dec 2002 11:40:36 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5Gdtv04442; Thu, 5 Dec 2002 11:39:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5GZMv03615 for ; Thu, 5 Dec 2002 11:35:22 -0500 Received: from protactinium (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18515 for ; Thu, 5 Dec 2002 11:32:27 -0500 (EST) Received: from host213-1-189-73.btinternet.com ([213.1.189.73] helo=tkw) by protactinium with smtp (Exim 3.22 #16) id 18Jyy3-0000pc-00; Thu, 05 Dec 2002 16:35:16 +0000 Message-ID: <005701c29c7b$b4deb580$0200000a@tkw> From: "Pete Cordell" To: "James Undery" , References: <45730E094814E44488F789C1CDED27AE018C2553@GBNEWP0758M.eu.ubiquity.net> Subject: Re: [Sip] B2BUA & Max-Forwards Date: Thu, 5 Dec 2002 15:48:27 -0000 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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit James, Thanks for your comments. I think in general you CAN'T guarantee that an element you route to won't proxy (or be a B2BUA). And therefore loop detection is a problem. Propagating Max-Forwards even when you know the precise routing should not cause you any problems. Pete. ----- Original Message ----- From: "James Undery" To: "Pete Cordell" ; "Dean Willis" ; Sent: 05 December 2002 13:21 Subject: RE: [Sip] B2BUA & Max-Forwards Hi, I think your confusion comes from mixing two email threads; the first statement in context says if a specific B2BUA demonstrates header transparency it doesn't change headers; the second statement is about B2BUAs in general and says they can do whatever they want (without commenting on the desirability of their actions). Max-Forwards probably are an important case for your particular application, in general they may not be required (e.g. routing to an element you can guarantee not to proxy). Your comment on Max-Forwards highlights well the difficulties faced in defining a B2BUA more specifically than the definition in 3261. James > -----Original Message----- > From: Pete Cordell [mailto:pete@tech-know-ware.com] > Sent: 05 December 2002 12:10 > To: Dean Willis; sip@ietf.org > Subject: Re: [Sip] B2BUA & Max-Forwards > > > Dean, > > Firstly, your statement that "The B2BUA doesn't change > headers that transit > it." seems inconsistent with the statement "It does the same > thing as ... > ANY 500-pound gorilla does". I don't understand. > > Secondly, I think max-forwards is a special case. It is > important for the > protection of SIP systems as it prevents loops. > > Indeed, there is a major difference between a UAS and a B2BUA > and that is > that the former terminates a request, and the latter > terminates a request > AND ALSO forwards an associated request (or more). The impact of this > difference should be covered in the spec in the interests of > protecting > other SIP systems. > > Pete. > > ----- Original Message ----- > From: "Dean Willis" > To: "'Pete Cordell'" ; > Sent: 05 December 2002 01:23 > Subject: RE: [Sip] B2BUA & Max-Forwards > > > > > One issue that the recent B2BUA discussion has raised in my > > > mind is what a B2BUA (whatever its decided that should be) > > > should do with Max-Forwards. > > > > It does the same thing as it does with any other header or > body part, > > which is the same thing that ANY 500-pound gorilla does to > somebody's > > body parts -- whatever it wants. > > > > What you're asking is "what is the transparency of this node with > > respect to max-forwards", which is "#4 -- Header Transaprency" in my > > top-10 list. The specification of a back-to-back user agent doesn't > > mandate any level of transparency on this or any other header. > > > > -- > > 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 > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Thu Dec 5 12:10:03 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20064 for ; Thu, 5 Dec 2002 12:10:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB5HCRl07300 for sip-archive@odin.ietf.org; Thu, 5 Dec 2002 12:12:27 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5HBfv07118; Thu, 5 Dec 2002 12:11:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5H6ev06042 for ; Thu, 5 Dec 2002 12:06:40 -0500 Received: from protactinium (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19782 for ; Thu, 5 Dec 2002 12:03:44 -0500 (EST) Received: from host213-1-189-73.btinternet.com ([213.1.189.73] helo=tkw) by protactinium with smtp (Exim 3.22 #16) id 18JzSK-0004b4-00; Thu, 05 Dec 2002 17:06:33 +0000 Message-ID: <007d01c29c80$092ebc80$0200000a@tkw> From: "Pete Cordell" To: "Jonathan Rosenberg" Cc: "Adam Roach" , "'Phil Reynolds'" , References: <9BF66EBF6BEFD942915B4D4D45C051F3A64377@DYN-TX-EXCH-001.dynamicsoft.com> <3DEEF411.2020408@dynamicsoft.com> <013901c29c5d$e02c81e0$0200000a@tkw> <3DEF7BF4.5070706@dynamicsoft.com> Subject: Re: [Sip] B2BUA & Max-Forwards Date: Thu, 5 Dec 2002 16:46:53 -0000 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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jonathan, I have not said anything about generic B2BUAs here. Each B2BUA implementation will need to have its own record (and server) of what it is transparent to or not. It would not be a generic list. Perhaps it is reasonable to remove the B2BUA definition, since there is no definition of a gateway and they are similar beasts. Just as long as such an action does not imply that SIP is not suitable for a certain class of problem. Pete. ----- Original Message ----- From: "Jonathan Rosenberg" To: "Pete Cordell" Cc: "Adam Roach" ; "'Phil Reynolds'" ; Sent: 05 December 2002 16:16 Subject: Re: [Sip] B2BUA & Max-Forwards > > > Pete Cordell wrote: > > This is correct. A B2BUA can't blindly forward a request containing a > > Require header. > > > > The saving grace for a B2BUA is that it does not need to understand the > > extension in detail. It just needs to know whether it can forward a request > > that contains a given Require header. This can be easily provisioned using > > some sort of ASCII configuration file, and doesn't require any new code etc. > > A B2BUA could even routinely download the list of acceptable Require headers > > from some sort of server. (A smart B2BUA could even post back a set of > > unknown Require headers that it has seen recently.) > > This is a vast over-simplification. > > As people have been saying over and over in this thread, there is no > such thing as a "generic b2bua" as you seem to be implying. What is > right in a b2bua depends entirely on what its doing. To be honest, I > can't think of any b2bua for which the processing you describe above is > sensible. As I mentioned in a previous note, a b2bua deviates from a > proxy by doing some featurs that are normally associated with a UA. That > b2bua will need to process extensions (i.e., implement them) that are > associated with that feature. > > I am at the point where I agree with the sentiment raised by others, > that we should remove the term b2bua entirely from the specification. It > has caused more confusion than anything else. > > -Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.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 mailnull@www1.ietf.org Thu Dec 5 12:16:04 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20286 for ; Thu, 5 Dec 2002 12:16:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB5HISt07572 for sip-archive@odin.ietf.org; Thu, 5 Dec 2002 12:18:28 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5HHwv07516; Thu, 5 Dec 2002 12:17:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5HEQv07367 for ; Thu, 5 Dec 2002 12:14:26 -0500 Received: from brmx1.fl.icn.siemens.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20102 for ; Thu, 5 Dec 2002 12:11:31 -0500 (EST) Received: from boca210a.boca.ssc.siemens.com (boca210a.boca.ssc.siemens.com [165.218.12.110]) by brmx1.fl.icn.siemens.com (8.9.3/8.9.3) with ESMTP id MAA07525; Thu, 5 Dec 2002 12:14:18 -0500 (EST) Received: by BOCA210A with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Dec 2002 12:14:17 -0500 Message-ID: From: "Mahey, Sonit" To: "'Jonathan Rosenberg'" , Pete Cordell Cc: Christian Huitema , sip@ietf.org Subject: RE: [Sip] B2BUA - Security Date: Thu, 5 Dec 2002 12:14:12 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , I agree with Jonathan. That brings up the question: Is NAT traversal for encrypted SIP traffic addressed anywhere? - sonit > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Thursday, December 05, 2002 11:28 AM > To: Pete Cordell > Cc: Christian Huitema; sip@ietf.org > Subject: Re: [Sip] B2BUA - Security > > > > > Pete Cordell wrote: > > > I would say that encrypting and / or integrity checking of SDP alone > > achieves absolutely no security benefit. > > Really?? Wow. I actually think it prevents the most > devastating attacks > against SIP. These include: > > 1. modifying SDP in transit to point media streams to an intermediate > recording device, allowing attackers to establish wiretaps > > 2. downgrading any SRTP keying done in SDP, so that the media > itself is > not encrypted or integrity protected (this came up during the mmusic > session in IETF as a driver for S/MIME) > > 3. launching a DoS attack by sending everyones voice traffic to the > intended target. You get huge amplification gains here. Very > appealing > for hackers! > > > > > > > > SDP really does two things. It specifies transport > addresses and chosen > > codecs. > > > > Let's assume that you do encrypt the SDP and I can't read it. > > > > I can have a good guess at the transport addresses in use > from many of the > > other fields in SIP such as via lines, To, From, uri, > contact, route etc. > > Confidentiality is only one property of security. I am much more > concerned about message integrity. > > > (Put another way, encrypting SDP is another form of > security by obscurity. > > And we all know what that means.) > > I have no idea how you would arrive at such a conclusion. Security > through obscurity means that information is not cryptographically > protected, but encoded with a known process that is just a bit > complicated. By definition, this is not encryption. Perhaps you have > discovered some new flaws in encryption technology? > > -Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.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 mailnull@www1.ietf.org Thu Dec 5 12:18:03 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20390 for ; Thu, 5 Dec 2002 12:18:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB5HKST07768 for sip-archive@odin.ietf.org; Thu, 5 Dec 2002 12:20:28 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5HJov07650; Thu, 5 Dec 2002 12:19:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5HFmv07429 for ; Thu, 5 Dec 2002 12:15:48 -0500 Received: from p2.piuha.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20122 for ; Thu, 5 Dec 2002 12:12:52 -0500 (EST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 25BE66A905; Thu, 5 Dec 2002 19:15:42 +0200 (EET) Message-ID: <3DEF89E4.8010301@piuha.net> Date: Thu, 05 Dec 2002 19:16:20 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: Pete Cordell , Christian Huitema , sip@ietf.org Subject: Re: [Sip] B2BUA - Security References: <013d01c29c5d$e4a7f7e0$0200000a@tkw> <3DEF7EAB.2070109@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > > Pete Cordell wrote: > >> I would say that encrypting and / or integrity checking of SDP alone >> achieves absolutely no security benefit. > > > Really?? Wow. I actually think it prevents the most devastating attacks > against SIP. These include: > > 1. modifying SDP in transit to point media streams to an intermediate > recording device, allowing attackers to establish wiretaps True. But if you are worried about this, perhaps you should use strong end-to-end media security instead of just relying on the IP addresses to stay unchanged? If the attacker is there to change the SDP, he can be there to intercept the cleartext media streams as well. > 2. downgrading any SRTP keying done in SDP, so that the media itself is > not encrypted or integrity protected (this came up during the mmusic > session in IETF as a driver for S/MIME) I think all SRTP keying mechanisms should be written to be secure against downgrade attacks. And as far as I know, they are. (With the exception of downgrade between MIKEY and a hypothetical future key management protocol that also runs within SDP. But that issue is being addressed as we speak...) > 3. launching a DoS attack by sending everyones voice traffic to the > intended target. You get huge amplification gains here. Very appealing > for hackers! Yes. This is serious. Interesting attack! Jari _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Thu Dec 5 12:32:01 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20769 for ; Thu, 5 Dec 2002 12:32:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB5HYQs08412 for sip-archive@odin.ietf.org; Thu, 5 Dec 2002 12:34:26 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5HWsv08327; Thu, 5 Dec 2002 12:32:54 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5HTTv08169 for ; Thu, 5 Dec 2002 12:29:29 -0500 Received: from gbnewp0915s1.eu.ubiquity.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA20606 for ; Thu, 5 Dec 2002 12:26:33 -0500 (EST) Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net via smtpd (for [132.151.6.1]) with SMTP; 5 Dec 2002 17:28:55 UT X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] B2BUA & Max-Forwards Date: Thu, 5 Dec 2002 17:29:27 -0000 Message-ID: <45730E094814E44488F789C1CDED27AE018C2556@GBNEWP0758M.eu.ubiquity.net> Thread-Topic: [Sip] B2BUA & Max-Forwards Thread-Index: AcKcfE2y6ig4uwNLQNyPNcm0I176HAAAJWTg From: "James Undery" To: "Pete Cordell" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gB5HTTv08170 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Pete, By sheer coincidence at the time I wrote that email I was writting some code to access a media server directly, via a B2BUA ;). Although adding Max-Forwards wouldn't hurt, I could absolutely guarantee the request wouldn't loop so just left the default value in from our "Message Factory". The fact that there is no general B2BUA is my whole point, you need the Max-Forwards to be strictly decreasing across your B2BUA, I don't and can guarantee I don't and still have both sides conform to rfc3261 without risk of looping. Despite actually using B2BUAs I'll have to add my voice to the "remove all references to B2BUAs" camp. Personally I found the definition easy to comprehend (even the name tells you what it is), but it is obviously a source of confusion; also letting people build two UAs that conform to the spec and linking them together by whatever innovative applications they can think of doesn't strike me as an area suitable for standardisation. James > -----Original Message----- > From: Pete Cordell [mailto:pete@tech-know-ware.com] > Sent: 05 December 2002 15:48 > To: James Undery; sip@ietf.org > Subject: Re: [Sip] B2BUA & Max-Forwards > > > James, > > Thanks for your comments. > > I think in general you CAN'T guarantee that an element you > route to won't > proxy (or be a B2BUA). And therefore loop detection is a problem. > > Propagating Max-Forwards even when you know the precise > routing should not > cause you any problems. > > Pete. > > ----- Original Message ----- > From: "James Undery" > To: "Pete Cordell" ; "Dean Willis" > ; > Sent: 05 December 2002 13:21 > Subject: RE: [Sip] B2BUA & Max-Forwards > > > Hi, > > I think your confusion comes from mixing two email threads; the first > statement in context says if a specific B2BUA demonstrates header > transparency it doesn't change headers; the second statement > is about B2BUAs > in general and says they can do whatever they want (without > commenting on > the desirability of their actions). > > Max-Forwards probably are an important case for your > particular application, > in general they may not be required (e.g. routing to an > element you can > guarantee not to proxy). > > Your comment on Max-Forwards highlights well the difficulties faced in > defining a B2BUA more specifically than the definition in 3261. > > James > > > -----Original Message----- > > From: Pete Cordell [mailto:pete@tech-know-ware.com] > > Sent: 05 December 2002 12:10 > > To: Dean Willis; sip@ietf.org > > Subject: Re: [Sip] B2BUA & Max-Forwards > > > > > > Dean, > > > > Firstly, your statement that "The B2BUA doesn't change > > headers that transit > > it." seems inconsistent with the statement "It does the same > > thing as ... > > ANY 500-pound gorilla does". I don't understand. > > > > Secondly, I think max-forwards is a special case. It is > > important for the > > protection of SIP systems as it prevents loops. > > > > Indeed, there is a major difference between a UAS and a B2BUA > > and that is > > that the former terminates a request, and the latter > > terminates a request > > AND ALSO forwards an associated request (or more). The > impact of this > > difference should be covered in the spec in the interests of > > protecting > > other SIP systems. > > > > Pete. > > > > ----- Original Message ----- > > From: "Dean Willis" > > To: "'Pete Cordell'" ; > > Sent: 05 December 2002 01:23 > > Subject: RE: [Sip] B2BUA & Max-Forwards > > > > > > > > One issue that the recent B2BUA discussion has raised in my > > > > mind is what a B2BUA (whatever its decided that should be) > > > > should do with Max-Forwards. > > > > > > It does the same thing as it does with any other header or > > body part, > > > which is the same thing that ANY 500-pound gorilla does to > > somebody's > > > body parts -- whatever it wants. > > > > > > What you're asking is "what is the transparency of this node with > > > respect to max-forwards", which is "#4 -- Header > Transaprency" in my > > > top-10 list. The specification of a back-to-back user > agent doesn't > > > mandate any level of transparency on this or any other header. > > > > > > -- > > > 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 > > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Thu Dec 5 12:33:06 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20804 for ; Thu, 5 Dec 2002 12:33:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB5HZVV08465 for sip-archive@odin.ietf.org; Thu, 5 Dec 2002 12:35:31 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5HYvv08437; Thu, 5 Dec 2002 12:34:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5HWMv08293 for ; Thu, 5 Dec 2002 12:32:22 -0500 Received: from lutetium (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20688 for ; Thu, 5 Dec 2002 12:29:25 -0500 (EST) Received: from host213-1-189-73.btinternet.com ([213.1.189.73] helo=tkw) by lutetium with smtp (Exim 3.22 #16) id 18Jzr7-00012n-00; Thu, 05 Dec 2002 17:32:10 +0000 Message-ID: <009701c29c83$97462280$0200000a@tkw> From: "Pete Cordell" To: "David R. Oran" , "Christian Huitema" Cc: References: <013d01c29c5d$e4a7f7e0$0200000a@tkw> <5543400.1039081506@ORANLT.cisco.com> Subject: Re: [Sip] B2BUA - Security Date: Thu, 5 Dec 2002 17:05:12 -0000 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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dave, Please see inline... Pete. ----- Original Message ----- From: "David R. Oran" To: "Pete Cordell" ; "Christian Huitema" Cc: Sent: 05 December 2002 14:45 Subject: Re: [Sip] B2BUA - Security > --On Thursday, December 05, 2002 12:55 PM +0000 Pete Cordell > wrote: > > > Christian, > > > > I'm afraid I think that end-to-end security of SDP is a complete red > > herring. > > > > I would say that encrypting and / or integrity checking of SDP alone > > achieves absolutely no security benefit. > > > > SDP really does two things. It specifies transport addresses and chosen > > codecs. > > > ...and carries keys for SRTP...hmmmmmmmm........ I assumed the keying used some sort of Diffee-Hellman type technique, and so this wouldn't be an issue. I will look into this. Maybe that area of SDP usage could be improved. > > > Let's assume that you do encrypt the SDP and I can't read it. > > > > I can have a good guess at the transport addresses in use from many of the > > other fields in SIP such as via lines, To, From, uri, contact, route etc. > > > Uh huh, sure. My experience is that you can only guess with reasonable > probability by knowing the implementation details of the UAs. I remember we > changed the RTP port allocation algorithm on IOS and all of a sudden people > started screaming because their ACL filters "stopped working". Trying to > beat the devil seem a pretty poor direction. Real time ACL control is very different issue to working out which RTP stream goes with what SIP session at some point. > > > By analysing the RTP traffic, I can easily find out what codec is being > > used, either because the packet tells me, or from other statistical > > characteristics. > > > Really? Maybe for the standard codecs but why on earth bother? Your point is? > > > I have therefore discovered, with very little effort most of what I would > > find useful in SDP. (Ironically sending stuff to a media relay would make > > this slightly harder!!!) > > > > If you want security of the media, then you have to encrypt and integrity > > check the RTP. > > > or put it through an IPSEC tunnel. What's the point? IPSEC would have trouble with NATs etc. The point is to encrypt the media some way. I'm not seeing your point. > > > Encrypting SDP simply burns CPU cycles!!! > > > No, it prevents media hijacking by a MITM. No - not really. It helps in some MITM situations but it is not a complete solution. > > > (Put another way, encrypting SDP is another form of security by obscurity. > > And we all know what that means.) > > > Disagree vociferously. > > > (Note that it may make sense to encrypt other bodies types, such as those > > that contain HTML, but this is a different case.) > > > > Pete. > > > Dave. > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Thu Dec 5 12:34:45 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20863 for ; Thu, 5 Dec 2002 12:34:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB5HbAI08866 for sip-archive@odin.ietf.org; Thu, 5 Dec 2002 12:37:10 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5Hapv08520; Thu, 5 Dec 2002 12:36:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5HWSv08300 for ; Thu, 5 Dec 2002 12:32:28 -0500 Received: from lutetium (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20695 for ; Thu, 5 Dec 2002 12:29:31 -0500 (EST) Received: from host213-1-189-73.btinternet.com ([213.1.189.73] helo=tkw) by lutetium with smtp (Exim 3.22 #16) id 18JzrC-00012n-00; Thu, 05 Dec 2002 17:32:14 +0000 Message-ID: <009901c29c83$9a304a20$0200000a@tkw> From: "Pete Cordell" To: "David R. Oran" , "Dean Willis" , References: <00cd01c29bfc$e7dd0240$fe0c0c42@txdwillis> <013a01c29c5d$e1591b00$0200000a@tkw> <2986103.1039078949@ORANLT.cisco.com> Subject: Re: [Sip] B2BUA & Max-Forwards Date: Thu, 5 Dec 2002 17:24:08 -0000 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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dave, To save your disagreeableness, can we say something like: "A B2BUA MUST perform loop prevention. One way to do this is to propagate the Max-Forwards header from the incoming request to the outgoing request in the same way that a proxy does." It's the loops that I'm worried about, not the Max-Forwards per se. This addresses my concern, and I think James' and possibly yours. Pete. ----- Original Message ----- From: "David R. Oran" To: "Pete Cordell" ; "Dean Willis" ; Sent: 05 December 2002 14:02 Subject: Re: [Sip] B2BUA & Max-Forwards > --On Thursday, December 05, 2002 12:09 PM +0000 Pete Cordell > wrote: > > > Dean, > > > > Firstly, your statement that "The B2BUA doesn't change headers that > > transit it." seems inconsistent with the statement "It does the same > > thing as ... ANY 500-pound gorilla does". I don't understand. > > > > Secondly, I think max-forwards is a special case. It is important for the > > protection of SIP systems as it prevents loops. > > > Once a dialog is terminated at a UAS it's up to the application to do loop > prevention. SIP is not involved any more. The application could compute a > value of Max-forwards for initiating outgoing calls based on incoming calls > which preserves the "strictly decreasing" invariant, or alternatively it > could just use the default MAx-Forwards in outgoing requests and execute a > contant memory loop suppression algorithm such as Knuth's even-odd > iterator. In either event the SIP spec(s) need say nothing about this. > > > Indeed, there is a major difference between a UAS and a B2BUA and that is > > that the former terminates a request, and the latter terminates a request > > AND ALSO forwards an associated request (or more). > I disagree. A UAS is a UAS. It's behavior is completely specified by > RFC3261 (unless there's a hole in the spec of course...). What it means to > originate (NOT FORWARD!!!!) an "associated request" is completely > application dependent. If I program my child's phone to initiate a SIP call > to my surrepititious recording device every time it receives a call and > give that device first chance to over-ride policy of the child's phone is > the phone a B2BUA? Yes, no, maybe so, but who cares? Tell me what the > applciation is and I can write some specs for that application and how it > has to originate, terminate and process SIP transactions to do that > application. > > I think the botom line is that there is not a single, well defined > appliation that one can point to and say "that's a B2BUA". > > > The impact of this > > difference should be covered in the spec in the interests of protecting > > other SIP systems. > > > I disagree. > > > Pete. > > > > ----- Original Message ----- > > From: "Dean Willis" > > To: "'Pete Cordell'" ; > > Sent: 05 December 2002 01:23 > > Subject: RE: [Sip] B2BUA & Max-Forwards > > > > > >> > One issue that the recent B2BUA discussion has raised in my > >> > mind is what a B2BUA (whatever its decided that should be) > >> > should do with Max-Forwards. > >> > >> It does the same thing as it does with any other header or body part, > >> which is the same thing that ANY 500-pound gorilla does to somebody's > >> body parts -- whatever it wants. > >> > >> What you're asking is "what is the transparency of this node with > >> respect to max-forwards", which is "#4 -- Header Transaprency" in my > >> top-10 list. The specification of a back-to-back user agent doesn't > >> mandate any level of transparency on this or any other header. > >> > >> -- > >> 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 > > ------------------------ > David R. Oran > Cisco Systems > 7 Ladyslipper Lane > Acton, MA 01720 > Office: +1 978 264 2048 > VoIP: +1 408 571 4576 > Email: oran@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 mailnull@www1.ietf.org Thu Dec 5 12:36:41 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20951 for ; Thu, 5 Dec 2002 12:36:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB5Hd5w09279 for sip-archive@odin.ietf.org; Thu, 5 Dec 2002 12:39:05 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5Hcjv09198; Thu, 5 Dec 2002 12:38:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5HWTv08308 for ; Thu, 5 Dec 2002 12:32:29 -0500 Received: from lutetium (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20697 for ; Thu, 5 Dec 2002 12:29:33 -0500 (EST) Received: from host213-1-189-73.btinternet.com ([213.1.189.73] helo=tkw) by lutetium with smtp (Exim 3.22 #16) id 18Jzr9-00012n-00; Thu, 05 Dec 2002 17:32:11 +0000 Message-ID: <009801c29c83$985129e0$0200000a@tkw> From: "Pete Cordell" To: "Jonathan Rosenberg" Cc: "Christian Huitema" , References: <013d01c29c5d$e4a7f7e0$0200000a@tkw> <3DEF7EAB.2070109@dynamicsoft.com> Subject: Re: [Sip] B2BUA - Security Date: Thu, 5 Dec 2002 17:19:59 -0000 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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jonathan, Please see in-line... Pete. ----- Original Message ----- From: "Jonathan Rosenberg" To: "Pete Cordell" Cc: "Christian Huitema" ; Sent: 05 December 2002 16:28 Subject: Re: [Sip] B2BUA - Security > > > Pete Cordell wrote: > > > I would say that encrypting and / or integrity checking of SDP alone > > achieves absolutely no security benefit. > > Really?? Wow. I actually think it prevents the most devastating attacks > against SIP. These include: > > 1. modifying SDP in transit to point media streams to an intermediate > recording device, allowing attackers to establish wiretaps This is only partially successful. Encryption of RTP is the only complete solution. > > 2. downgrading any SRTP keying done in SDP, so that the media itself is > not encrypted or integrity protected (this came up during the mmusic > session in IETF as a driver for S/MIME) I don't think you need to encrypt the entire SDP body to prevent key downgrading. In the absence of any other contraints that might be a simple route to go, but if it causes problems (as it is) then we should look at other ways. As an aside - This is the sort of reason I would like to get this sort of thing on the agenda. It's not that its not possible to enable SIP to meet these requirements, there's just not a desire to do among the core SIP people. I know why they don't want to do it, but I also think that SIP fails to address a whole class of problem as a result. In the long run I think that will be detrimental to SIP. > 3. launching a DoS attack by sending everyones voice traffic to the > intended target. You get huge amplification gains here. Very appealing > for hackers! Don't need SDP to do that. I could just rip out the entire SDP and put in a new version. I might not get the ports right, but I could probably cause enough damage to get my kicks. > > > > > SDP really does two things. It specifies transport addresses and chosen > > codecs. > > > > Let's assume that you do encrypt the SDP and I can't read it. > > > > I can have a good guess at the transport addresses in use from many of the > > other fields in SIP such as via lines, To, From, uri, contact, route etc. > > Confidentiality is only one property of security. I am much more > concerned about message integrity. Integrity of which bits? And are you sure that maintaining integrity buys you anything except for in a few special cases? > > > (Put another way, encrypting SDP is another form of security by obscurity. > > And we all know what that means.) > > I have no idea how you would arrive at such a conclusion. Security > through obscurity means that information is not cryptographically > protected, but encoded with a known process that is just a bit > complicated. By definition, this is not encryption. That's what I meant - yes. Hiding the SDP does not get you security. > Perhaps you have > discovered some new flaws in encryption technology? > > -Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.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 mailnull@www1.ietf.org Thu Dec 5 12:51:26 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21328 for ; Thu, 5 Dec 2002 12:51:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB5Hrno09893 for sip-archive@odin.ietf.org; Thu, 5 Dec 2002 12:53:49 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5HrSv09855; Thu, 5 Dec 2002 12:53:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5HoNv09722 for ; Thu, 5 Dec 2002 12:50:23 -0500 Received: from smail3.alcatel.fr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21213 for ; Thu, 5 Dec 2002 12:47:26 -0500 (EST) From: Juan-Carlos.Rojas@alcatel.fr Received: from frmail25.netfr.alcatel.fr (frmail25.netfr.alcatel.fr [155.132.182.155]) by smail3.alcatel.fr (ALCANET/NETFR) with ESMTP id gB5HoAek029499; Thu, 5 Dec 2002 18:50:10 +0100 Subject: Re: [Sip] B2BUA & Max-Forwards To: Jonathan Rosenberg Cc: sip@ietf.org Date: Thu, 5 Dec 2002 18:50:08 +0100 Message-ID: X-MIMETrack: Serialize by Router on FRMAIL25/FR/ALCATEL(Release 5.0.8 |June 18, 2001) at 12/05/2002 18:50:10 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hello, "I am at the point where I agree with the sentiment raised by others, that we should remove the term b2bua entirely from the specification. It has caused more confusion than anything else." Yes, this is one possibility. An alternative (as I proposed in an earlier mail) is to complete the current definition in 3261 saying explicitly that : 1) A B2BUA handles two or more UAs, each one behaving as UAC/UAS, as described in 3261 for UAs 2) The SIP protocol specification does not mandate for any behaviour of such B2BUA, i.e. on how to "link" (or "concatenate") two or more UAs. Best regards Juan Carlos Jonathan Rosenberg @ietf.org on 05/12/2002 17:16:52 Sent by: sip-admin@ietf.org To: Pete Cordell cc: Adam Roach , "'Phil Reynolds'" , sip@ietf.org Subject: Re: [Sip] B2BUA & Max-Forwards Pete Cordell wrote: > This is correct. A B2BUA can't blindly forward a request containing a > Require header. > > The saving grace for a B2BUA is that it does not need to understand the > extension in detail. It just needs to know whether it can forward a request > that contains a given Require header. This can be easily provisioned using > some sort of ASCII configuration file, and doesn't require any new code etc. > A B2BUA could even routinely download the list of acceptable Require headers > from some sort of server. (A smart B2BUA could even post back a set of > unknown Require headers that it has seen recently.) This is a vast over-simplification. As people have been saying over and over in this thread, there is no such thing as a "generic b2bua" as you seem to be implying. What is right in a b2bua depends entirely on what its doing. To be honest, I can't think of any b2bua for which the processing you describe above is sensible. As I mentioned in a previous note, a b2bua deviates from a proxy by doing some featurs that are normally associated with a UA. That b2bua will need to process extensions (i.e., implement them) that are associated with that feature. I am at the point where I agree with the sentiment raised by others, that we should remove the term b2bua entirely from the specification. It has caused more confusion than anything else. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.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 mailnull@www1.ietf.org Thu Dec 5 12:53:57 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21382 for ; Thu, 5 Dec 2002 12:53:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB5HuKd10023 for sip-archive@odin.ietf.org; Thu, 5 Dec 2002 12:56:20 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5Htpv09975; Thu, 5 Dec 2002 12:55:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5Hrov09905 for ; Thu, 5 Dec 2002 12:53:50 -0500 Received: from mail4.microsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21294 for ; Thu, 5 Dec 2002 12:50:56 -0500 (EST) Received: from mail6.microsoft.com ([157.54.6.196]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 5 Dec 2002 09:53:45 -0800 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 5 Dec 2002 09:53:40 -0800 Received: from 157.54.8.109 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 05 Dec 2002 09:53:41 -0800 Received: from RED-IMC-02.redmond.corp.microsoft.com ([157.54.9.107]) by INET-HUB-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3710.0); Thu, 5 Dec 2002 09:53:50 -0800 Received: from WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 5 Dec 2002 09:53:40 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.82]) by WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3710.0); Thu, 5 Dec 2002 09:53:36 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Sip] B2BUA - Security Date: Thu, 5 Dec 2002 09:53:39 -0800 Message-ID: Thread-Topic: [Sip] B2BUA - Security Thread-Index: AcKcgcgb36brIS1YSPaEIfsetm8rJAABH/Pg From: "Christian Huitema" To: "Mahey, Sonit" , "Jonathan Rosenberg" , "Pete Cordell" Cc: X-OriginalArrivalTime: 05 Dec 2002 17:53:36.0661 (UTC) FILETIME=[3C566C50:01C29C87] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gB5Hrov09906 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit > From: Mahey, Sonit [mailto:Sonit.Mahey@icn.siemens.com] > Sent: Thursday, December 05, 2002 9:14 AM > > I agree with Jonathan. > > That brings up the question: > Is NAT traversal for encrypted SIP traffic addressed anywhere? There are two possibilities. If your application only uses UDP, it is possible to use IPv4 and STUN to find out the "outside ports" for your UDP traffic (check draft-ietf-midcom-stun-03.txt); you may need to use the "a:rtcp" convention to encode port numbers in SDP (check draft-ietf-mmusic-sdp4nat-03.txt). If you need to also support TCP, or use IPSEC, or generally do away with the complications of NAT, the best solution is to just move to IPv6; see Teredo (draft-ietf-ngtrans-shipworm-08.txt) for one possible way to carry IPv6 across NAT, and 6to4 (RFC 3056 & 3068) for a possible way to upgrade the NAT and make it an IPv6 router. -- Christian Huitema _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Thu Dec 5 12:56:48 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21440 for ; Thu, 5 Dec 2002 12:56:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB5HxBi10123 for sip-archive@odin.ietf.org; Thu, 5 Dec 2002 12:59:11 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5Hwqv10113; Thu, 5 Dec 2002 12:58:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5Ht2v09944 for ; Thu, 5 Dec 2002 12:55:02 -0500 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21350 for ; Thu, 5 Dec 2002 12:52:08 -0500 (EST) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB5HsvK0022483; Thu, 5 Dec 2002 09:54:57 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAU14065; Thu, 5 Dec 2002 09:48:08 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA20866; Thu, 5 Dec 2002 09:54:56 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15855.37616.486738.421932@thomasm-u1.cisco.com> Date: Thu, 5 Dec 2002 09:54:56 -0800 (PST) To: "Pete Cordell" Cc: "David R. Oran" , "Dean Willis" , Subject: Re: [Sip] B2BUA & Max-Forwards In-Reply-To: <009901c29c83$9a304a20$0200000a@tkw> References: <00cd01c29bfc$e7dd0240$fe0c0c42@txdwillis> <013a01c29c5d$e1591b00$0200000a@tkw> <2986103.1039078949@ORANLT.cisco.com> <009901c29c83$9a304a20$0200000a@tkw> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Pete Cordell writes: > Dave, > > To save your disagreeableness, can we say something like: > > "A B2BUA MUST perform loop prevention. One way to do this is to propagate > the Max-Forwards header from the incoming request to the outgoing request in > the same way that a proxy does." > > It's the loops that I'm worried about, not the Max-Forwards per se. And prevent me from building a SIP Cyclotron? Hell no. Mike _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Thu Dec 5 13:00:54 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21543 for ; Thu, 5 Dec 2002 13:00:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB5I3Hf10403 for sip-archive@odin.ietf.org; Thu, 5 Dec 2002 13:03:17 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5I2vv10383; Thu, 5 Dec 2002 13:02:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5I0Zv10275 for ; Thu, 5 Dec 2002 13:00:35 -0500 Received: from brmx1.fl.icn.siemens.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21479 for ; Thu, 5 Dec 2002 12:57:41 -0500 (EST) Received: from boca210a.boca.ssc.siemens.com (boca210a.boca.ssc.siemens.com [165.218.12.110]) by brmx1.fl.icn.siemens.com (8.9.3/8.9.3) with ESMTP id NAA20782; Thu, 5 Dec 2002 13:00:27 -0500 (EST) Received: by BOCA210A with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Dec 2002 13:00:27 -0500 Message-ID: From: "Mahey, Sonit" To: "'Christian Huitema'" , Jonathan Rosenberg , Pete Cordell Cc: sip@ietf.org Subject: RE: [Sip] B2BUA - Security Date: Thu, 5 Dec 2002 13:00:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Thanks, Christian. Assuming IPv4 addresses and without delving into the draft RFC on STUN: The SDP contains the RTP/RTCP port numbers that are private and these are also required to be NAT'd. Now, if the SDP, which forms part of the SIP body, is encrypted, how will RTP/RTCP ports be translated? regards, - sonit > -----Original Message----- > From: Christian Huitema [mailto:huitema@windows.microsoft.com] > Sent: Thursday, December 05, 2002 12:54 PM > To: Mahey, Sonit; Jonathan Rosenberg; Pete Cordell > Cc: sip@ietf.org > Subject: RE: [Sip] B2BUA - Security > > > > From: Mahey, Sonit [mailto:Sonit.Mahey@icn.siemens.com] > > Sent: Thursday, December 05, 2002 9:14 AM > > > > I agree with Jonathan. > > > > That brings up the question: > > Is NAT traversal for encrypted SIP traffic addressed anywhere? > > There are two possibilities. If your application only uses UDP, it is > possible to use IPv4 and STUN to find out the "outside ports" for your > UDP traffic (check draft-ietf-midcom-stun-03.txt); you may need to use > the "a:rtcp" convention to encode port numbers in SDP (check > draft-ietf-mmusic-sdp4nat-03.txt). If you need to also support TCP, or > use IPSEC, or generally do away with the complications of > NAT, the best > solution is to just move to IPv6; see Teredo > (draft-ietf-ngtrans-shipworm-08.txt) for one possible way to > carry IPv6 > across NAT, and 6to4 (RFC 3056 & 3068) for a possible way to > upgrade the > NAT and make it an IPv6 router. > > -- Christian Huitema > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Thu Dec 5 13:02:53 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21658 for ; Thu, 5 Dec 2002 13:02:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB5I5GY10568 for sip-archive@odin.ietf.org; Thu, 5 Dec 2002 13:05:16 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5I4qv10485; Thu, 5 Dec 2002 13:04:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5I0hv10285 for ; Thu, 5 Dec 2002 13:00:43 -0500 Received: from dgesmtp02.wcom.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21486 for ; Thu, 5 Dec 2002 12:57:49 -0500 (EST) Received: from pmismtp03.wcomnet.com ([166.38.62.38]) by firewall.wcom.com (Iplanet MTA ) with ESMTP id <0H6N002K9R99AD@firewall.wcom.com> for sip@ietf.org; Thu, 05 Dec 2002 17:58:22 +0000 (GMT) Received: from pmismtp03.wcomnet.com by pmismtp03.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0H6N00601R3F6L@pmismtp03.wcomnet.com>; Thu, 05 Dec 2002 17:58:21 +0000 (GMT) Received: from hsinnreich2 ([166.42.42.174]) by pmismtp03.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0H6N004LPR6G7Q@pmismtp03.wcomnet.com>; Thu, 05 Dec 2002 17:57:01 +0000 (GMT) Date: Thu, 05 Dec 2002 11:56:40 -0600 From: Henry Sinnreich Subject: RE: [Sip] B2BUA In-reply-to: <013b01c29c5d$e22bad40$0200000a@tkw> To: "'Pete Cordell'" Cc: sip@ietf.org Message-id: <000101c29c87$b4c96250$ae2a2aa6@hsinnreich2> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1097 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Can you document any _outages_ of the _Internet_? I don't recall any. Please provide references. Thanks, Henry > -----Original Message----- > From: Pete Cordell [mailto:pete@tech-know-ware.com] > Sent: Thursday, December 05, 2002 6:25 AM > To: Henry Sinnreich > Cc: sip@ietf.org > Subject: Re: [Sip] B2BUA > > > Henry, > > The Internet has had a few famous outages as well. Besides, > if all the telco traffic was put over IP, with today's level > of QoS on the Internet, it would have been brought to its knees also. > > To say that one is all goodness and light and the other all > evil doesn't do us as a community any good as when customers > find out there are problems they tend not to believe anything > else we say! > > Only vapourware is flawless. Most people know that. Respect > the intelligence of your customer, or they will find somebody > that does!!! > > Pete. > > ----- Original Message ----- > From: "Henry Sinnreich" > To: "'Phil Reynolds'" ; > Sent: 04 December 2002 19:02 > Subject: RE: [Sip] B2BUA > > > > >The telecoms people are clever enough to have thought > > >about that and build redundancy, fault tolerance and failover into > > their switches. > > > > This has proven unfortunately not to be the case on > September 11 when > > telecom service failed for days, while Internet traffic continued > > smoothly. I suggest you to look at the central control model of the > > switch network versus the e2e architecture of the Internet. SIP > > enabled networks are also fully distributed and the e2e control > > principle maintained - that's why state in placed in SIP endpoints. > > > > I am not sure if a few words here can give full justice to the > > superior resilience of the Internet and to SIP enabled services,... > > > > Thanks, Henry > > > > -----Original Message----- > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of Phil > > Reynolds > > Sent: Wednesday, December 04, 2002 7:37 AM > > To: sip@ietf.org > > Subject: RE: [Sip] B2BUA > > > > > > If a telephone switch crashes you loose all calls... The telecoms > > people are clever enough to have thought about that and build > > redundancy, fault tolerance and failover into their switches. Maybe > > some of us IP-telecoms people have thought of similar > techniques for > > SIP intermediaries? -----Original Message----- > > From: Jiri Kuthan [mailto:jiri.kuthan@fokus.fraunhofer.de] > > Sent: 04 December 2002 12:32 > > To: Christian Huitema; Roy, Radhika R, ALASO; > mbarnes@nortelnetworks.com > > > > Cc: dean.willis@softarmor.com; Juan-Carlos.Rojas@alcatel.fr; > > sip@ietf.org > > Subject: RE: [Sip] B2BUA > > [...snip...] > > I think there are more issues with B2BUA. A B2BUA's failure affects > > all current calls :-( -Jiri > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Thu Dec 5 13:26:07 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22504 for ; Thu, 5 Dec 2002 13:26:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB5ISUF12412 for sip-archive@odin.ietf.org; Thu, 5 Dec 2002 13:28:30 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5IPJv12244; Thu, 5 Dec 2002 13:25:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5IM7v12111 for ; Thu, 5 Dec 2002 13:22:07 -0500 Received: from dgesmtp02.wcom.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22280 for ; Thu, 5 Dec 2002 13:19:12 -0500 (EST) Received: from dgismtp05.wcomnet.com ([166.38.58.88]) by firewall.wcom.com (Iplanet MTA ) with ESMTP id <0H6N0054LS4AOH@firewall.wcom.com> for sip@ietf.org; Thu, 05 Dec 2002 18:16:58 +0000 (GMT) Received: from dgismtp05.wcomnet.com by dgismtp05.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0H6N00H01S49OR@dgismtp05.wcomnet.com>; Thu, 05 Dec 2002 18:16:58 +0000 (GMT) Received: from hsinnreich2 ([166.42.42.148]) by dgismtp05.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0H6N00FJRS430P@dgismtp05.wcomnet.com>; Thu, 05 Dec 2002 18:16:57 +0000 (GMT) Date: Thu, 05 Dec 2002 12:16:51 -0600 From: Henry Sinnreich Subject: RE: [Sip] B2BUA In-reply-to: <1D82815C322BD41196EA00508B951F7B067A4B2C@MCHH265E> To: "'Liebhart Rainer'" , "'Pete Cordell'" Cc: sip@ietf.org Message-id: <000001c29c8a$7eb6e310$942a2aa6@hsinnreich2> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1097 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=iso-8859-1 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gB5IM7v12112 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Rainer, the fact is that people could communicate on 9/11/01 using IM and SIP telephony from Columbia University, while the telecom phone service, both landline and mobile was down for days. There is very little or very much to comment on these facts. Henry > -----Original Message----- > From: Liebhart Rainer [mailto:rainer.liebhart@siemens.com] > Sent: Thursday, December 05, 2002 7:46 AM > To: 'Pete Cordell'; Henry Sinnreich > Cc: sip@ietf.org > Subject: AW: [Sip] B2BUA > > > Henry, > > unfortunately you are comparing apples and pears when stating > that the telecom service failed for days after Sept 11, while > Internet traffic continued smoothly. The mentioned "telefon > service" consists of thousands of (real-time) calls to > emergency centres while the Internet traffic consists mainly > of requests to the Web pages of CNN and others (with bad > response times) to retrieve *information* on the status of > the catastrophe. > > Rainer > > > -----Ursprüngliche Nachricht----- > Von: Pete Cordell [mailto:pete@tech-know-ware.com] > Gesendet: Donnerstag, 5. Dezember 2002 13:25 > An: Henry Sinnreich > Cc: sip@ietf.org > Betreff: Re: [Sip] B2BUA > > > Henry, > > The Internet has had a few famous outages as well. Besides, > if all the telco traffic was put over IP, with today's level > of QoS on the Internet, it would have been brought to its knees also. > > To say that one is all goodness and light and the other all > evil doesn't do us as a community any good as when customers > find out there are problems they tend not to believe anything > else we say! > > Only vapourware is flawless. Most people know that. Respect > the intelligence of your customer, or they will find somebody > that does!!! > > Pete. > > ----- Original Message ----- > From: "Henry Sinnreich" > To: "'Phil Reynolds'" ; > Sent: 04 December 2002 19:02 > Subject: RE: [Sip] B2BUA > > > > >The telecoms people are clever enough to have thought > > >about that and build redundancy, fault tolerance and failover into > > their switches. > > > > This has proven unfortunately not to be the case on > September 11 when > > telecom service failed for days, while Internet traffic continued > > smoothly. I suggest you to look at the central control model of the > > switch network versus the e2e architecture of the Internet. SIP > > enabled networks are also fully distributed and the e2e control > > principle maintained - that's why state in placed in SIP endpoints. > > > > I am not sure if a few words here can give full justice to the > > superior resilience of the Internet and to SIP enabled services,... > > > > Thanks, Henry > > > > -----Original Message----- > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of Phil > > Reynolds > > Sent: Wednesday, December 04, 2002 7:37 AM > > To: sip@ietf.org > > Subject: RE: [Sip] B2BUA > > > > > > If a telephone switch crashes you loose all calls... The telecoms > > people are clever enough to have thought about that and build > > redundancy, fault tolerance and failover into their switches. Maybe > > some of us IP-telecoms people have thought of similar > techniques for > > SIP intermediaries? -----Original Message----- > > From: Jiri Kuthan [mailto:jiri.kuthan@fokus.fraunhofer.de] > > Sent: 04 December 2002 12:32 > > To: Christian Huitema; Roy, Radhika R, ALASO; > mbarnes@nortelnetworks.com > > > > Cc: dean.willis@softarmor.com; Juan-Carlos.Rojas@alcatel.fr; > > sip@ietf.org > > Subject: RE: [Sip] B2BUA > > [...snip...] > > I think there are more issues with B2BUA. A B2BUA's failure affects > > all current calls :-( -Jiri > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Thu Dec 5 13:35:18 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22841 for ; Thu, 5 Dec 2002 13:35:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB5Ibfu13448 for sip-archive@odin.ietf.org; Thu, 5 Dec 2002 13:37:41 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5IbCv13159; Thu, 5 Dec 2002 13:37:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5IYOv12701 for ; Thu, 5 Dec 2002 13:34:24 -0500 Received: from mail2.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22713 for ; Thu, 5 Dec 2002 13:31:29 -0500 (EST) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id gB5IWdXE019109; Thu, 5 Dec 2002 13:32:39 -0500 (EST) Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Dec 2002 12:33:47 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A64388@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Mahey, Sonit'" , Jonathan Rosenberg , Pete Cordell Cc: Christian Huitema , sip@ietf.org Subject: RE: [Sip] B2BUA - Security Date: Thu, 5 Dec 2002 12:33:45 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Yes. See STUN. /a > -----Original Message----- > From: Mahey, Sonit [mailto:Sonit.Mahey@icn.siemens.com] > Sent: Thursday, December 05, 2002 11:14 > To: 'Jonathan Rosenberg'; Pete Cordell > Cc: Christian Huitema; sip@ietf.org > Subject: RE: [Sip] B2BUA - Security > > > I agree with Jonathan. > > That brings up the question: > Is NAT traversal for encrypted SIP traffic addressed anywhere? > > - sonit > > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > Sent: Thursday, December 05, 2002 11:28 AM > > To: Pete Cordell > > Cc: Christian Huitema; sip@ietf.org > > Subject: Re: [Sip] B2BUA - Security > > > > > > > > > > Pete Cordell wrote: > > > > > I would say that encrypting and / or integrity checking > of SDP alone > > > achieves absolutely no security benefit. > > > > Really?? Wow. I actually think it prevents the most > > devastating attacks > > against SIP. These include: > > > > 1. modifying SDP in transit to point media streams to an > intermediate > > recording device, allowing attackers to establish wiretaps > > > > 2. downgrading any SRTP keying done in SDP, so that the media > > itself is > > not encrypted or integrity protected (this came up during > the mmusic > > session in IETF as a driver for S/MIME) > > > > 3. launching a DoS attack by sending everyones voice traffic to the > > intended target. You get huge amplification gains here. Very > > appealing > > for hackers! > > > > > > > > > > > > > > SDP really does two things. It specifies transport > > addresses and chosen > > > codecs. > > > > > > Let's assume that you do encrypt the SDP and I can't read it. > > > > > > I can have a good guess at the transport addresses in use > > from many of the > > > other fields in SIP such as via lines, To, From, uri, > > contact, route etc. > > > > Confidentiality is only one property of security. I am much more > > concerned about message integrity. > > > > > (Put another way, encrypting SDP is another form of > > security by obscurity. > > > And we all know what that means.) > > > > I have no idea how you would arrive at such a conclusion. Security > > through obscurity means that information is not cryptographically > > protected, but encoded with a known process that is just a bit > > complicated. By definition, this is not encryption. Perhaps > you have > > discovered some new flaws in encryption technology? > > > > -Jonathan R. > > -- > > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.dynamicsoft.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 > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Thu Dec 5 13:55:02 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23585 for ; Thu, 5 Dec 2002 13:55:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB5IvQ914337 for sip-archive@odin.ietf.org; Thu, 5 Dec 2002 13:57:26 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5Iv0v14302; Thu, 5 Dec 2002 13:57:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5IsZv14186 for ; Thu, 5 Dec 2002 13:54:35 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23447 for ; Thu, 5 Dec 2002 13:51:39 -0500 (EST) From: aki.niemi@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gB5ItdW23921 for ; Thu, 5 Dec 2002 20:55:39 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 5 Dec 2002 20:54:28 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 5 Dec 2002 20:54:27 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] B2BUA & Max-Forwards Date: Thu, 5 Dec 2002 20:54:26 +0200 Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9019450CC@esebe013.ntc.nokia.com> Thread-Topic: [Sip] B2BUA & Max-Forwards Thread-Index: AcKciJaW2fEfF3TgS8+dmC3ogtvxkAABQuAA To: Cc: X-OriginalArrivalTime: 05 Dec 2002 18:54:27.0402 (UTC) FILETIME=[BC594AA0:01C29C8F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gB5IsZv14187 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi, inline. > "I am at the point where I agree with the sentiment raised by others, > that we should remove the term b2bua entirely from the > specification. It > has caused more confusion than anything else." > > Yes, this is one possibility. An alternative (as I proposed > in an earlier > mail) is to complete the current definition in 3261 saying > explicitly that > : > 1) A B2BUA handles two or more UAs, each one behaving as UAC/UAS, as > described in 3261 for UAs I don't get this. Does two or more mean, for example, four? And does that in turn make it a B2BB2BUA? ;) The only minor clarification I think might be in order for RFC3261 is that it's not just a UAC/UAS concatenation, but a pair of UAC/UAS concatenations. However, the fact that the traffic in this thread alone equals to a year's worth of emails on the SIMPLE list suggests that no clarification is enough clarification. So I agree with the other people in that getting rid of the definition altogether is the best option. After all, if it looks like a UA to the outside world, it must be a UA. > 2) The SIP protocol specification does not mandate for any > behaviour of > such B2BUA, i.e. on how to "link" (or "concatenate") two or more UAs. Yes, probably the reason why the definition for a B2BUA is also useless. Cheers, Aki _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Thu Dec 5 14:11:04 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24302 for ; Thu, 5 Dec 2002 14:11:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB5JDSl15807 for sip-archive@odin.ietf.org; Thu, 5 Dec 2002 14:13:28 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5JD2v15786; Thu, 5 Dec 2002 14:13:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5JArv15732 for ; Thu, 5 Dec 2002 14:10:53 -0500 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24196 for ; Thu, 5 Dec 2002 14:07:58 -0500 (EST) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id gB5JAj0R002845; Thu, 5 Dec 2002 11:10:45 -0800 (PST) Received: from ORANLT.cisco.com ([161.44.238.36]) by mira-sjc5-9.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id ECC00220; Thu, 5 Dec 2002 11:11:07 -0800 (PST) Date: Thu, 05 Dec 2002 14:10:34 -0500 From: David Oran To: Pete Cordell , Dean Willis , sip@ietf.org Subject: Re: [Sip] B2BUA & Max-Forwards Message-ID: <21471264.1039097434@ORANLT.cisco.com> In-Reply-To: <009901c29c83$9a304a20$0200000a@tkw> References: <00cd01c29bfc$e7dd0240$fe0c0c42@txdwillis> <013a01c29c5d$e1591b00$0200000a@tkw> <2986103.1039078949@ORANLT.cisco.com> <009901c29c83$9a304a20$0200000a@tkw> X-Mailer: Mulberry/3.0.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit --On Thursday, December 05, 2002 5:24 PM +0000 Pete Cordell wrote: > Dave, > > To save your disagreeableness, can we say something like: > > "A B2BUA MUST perform loop prevention. One way to do this is to propagate > the Max-Forwards header from the incoming request to the outgoing request > in the same way that a proxy does." > I don't understand what it means to have normative language for a beast which is fundamentally undefined. Suppose I write a piece of code which accepts SIP requests, issues tachyon commands to alpha centauri, and meanwhile receives routing instructions from a chronosynclastic infundibulum (for the unintiated, that is a device which effects reverse causality based on the message to alpha centauri whose response would not normally arrive for 7.8 years). It then uses those routing instructions to formulate an outbound SIP request to the destination received through the chronosynclastic infundibulum. Question: is this application a B2BUA and hence required to have a Max-Forwards value in the request whose value is strictly less than the value received in the SIP request? Beats me. > It's the loops that I'm worried about, not the Max-Forwards per se. > There are many ways to suppress loops. Using application semantics is actually safer than lower-layer protocol machinery because of the hazards introduced by protocol translation (e.g. the PSTN hop case mentioned earlier, or a SIP<->H.323 conversion somewhere else). > This addresses my concern, and I think James' and possibly yours. > Sorry, not mine. From where I sit, the less said about B2BUAs the better, including asymptotically toward zero. Cheers, Dave. > Pete. > > ----- Original Message ----- > From: "David R. Oran" > To: "Pete Cordell" ; "Dean Willis" > ; > Sent: 05 December 2002 14:02 > Subject: Re: [Sip] B2BUA & Max-Forwards > > >> --On Thursday, December 05, 2002 12:09 PM +0000 Pete Cordell >> wrote: >> >> > Dean, >> > >> > Firstly, your statement that "The B2BUA doesn't change headers that >> > transit it." seems inconsistent with the statement "It does the same >> > thing as ... ANY 500-pound gorilla does". I don't understand. >> > >> > Secondly, I think max-forwards is a special case. It is important for > the >> > protection of SIP systems as it prevents loops. >> > >> Once a dialog is terminated at a UAS it's up to the application to do >> loop prevention. SIP is not involved any more. The application could >> compute a value of Max-forwards for initiating outgoing calls based on >> incoming > calls >> which preserves the "strictly decreasing" invariant, or alternatively it >> could just use the default MAx-Forwards in outgoing requests and execute >> a contant memory loop suppression algorithm such as Knuth's even-odd >> iterator. In either event the SIP spec(s) need say nothing about this. >> >> > Indeed, there is a major difference between a UAS and a B2BUA and that > is >> > that the former terminates a request, and the latter terminates a > request >> > AND ALSO forwards an associated request (or more). >> I disagree. A UAS is a UAS. It's behavior is completely specified by >> RFC3261 (unless there's a hole in the spec of course...). What it means >> to originate (NOT FORWARD!!!!) an "associated request" is completely >> application dependent. If I program my child's phone to initiate a SIP > call >> to my surrepititious recording device every time it receives a call and >> give that device first chance to over-ride policy of the child's phone is >> the phone a B2BUA? Yes, no, maybe so, but who cares? Tell me what the >> applciation is and I can write some specs for that application and how it >> has to originate, terminate and process SIP transactions to do that >> application. >> >> I think the botom line is that there is not a single, well defined >> appliation that one can point to and say "that's a B2BUA". >> >> > The impact of this >> > difference should be covered in the spec in the interests of protecting >> > other SIP systems. >> > >> I disagree. >> >> > Pete. >> > >> > ----- Original Message ----- >> > From: "Dean Willis" >> > To: "'Pete Cordell'" ; >> > Sent: 05 December 2002 01:23 >> > Subject: RE: [Sip] B2BUA & Max-Forwards >> > >> > >> >> > One issue that the recent B2BUA discussion has raised in my >> >> > mind is what a B2BUA (whatever its decided that should be) >> >> > should do with Max-Forwards. >> >> >> >> It does the same thing as it does with any other header or body part, >> >> which is the same thing that ANY 500-pound gorilla does to somebody's >> >> body parts -- whatever it wants. >> >> >> >> What you're asking is "what is the transparency of this node with >> >> respect to max-forwards", which is "#4 -- Header Transaprency" in my >> >> top-10 list. The specification of a back-to-back user agent doesn't >> >> mandate any level of transparency on this or any other header. >> >> >> >> -- >> >> 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 >> >> ------------------------ >> David R. Oran >> Cisco Systems >> 7 Ladyslipper Lane >> Acton, MA 01720 >> Office: +1 978 264 2048 >> VoIP: +1 408 571 4576 >> Email: oran@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 mailnull@www1.ietf.org Thu Dec 5 15:05:57 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26064 for ; Thu, 5 Dec 2002 15:05:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB5K8Mm19233 for sip-archive@odin.ietf.org; Thu, 5 Dec 2002 15:08:22 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5K7nv19207; Thu, 5 Dec 2002 15:07:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5K3hv18425 for ; Thu, 5 Dec 2002 15:03:43 -0500 Received: from commserver.iperia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25858 for ; Thu, 5 Dec 2002 15:00:47 -0500 (EST) Received: by commserver.erictest.com with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Dec 2002 15:03:55 -0500 Message-ID: <1A69639B9B6AD511812B00B0D0DE19F60A3935@commserver.erictest.com> From: Gordon Ledgard To: "'David Oran'" , Pete Cordell , Dean Willis , sip@ietf.org Subject: RE: [Sip] B2BUA & Max-Forwards Date: Thu, 5 Dec 2002 15:03:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , inline - > -----Original Message----- > From: David Oran [mailto:oran@cisco.com] > Sent: Thursday, December 05, 2002 2:11 PM > To: Pete Cordell; Dean Willis; sip@ietf.org > Subject: Re: [Sip] B2BUA & Max-Forwards > > > --On Thursday, December 05, 2002 5:24 PM +0000 Pete Cordell > wrote: > > > Dave, > > > > To save your disagreeableness, can we say something like: > > > > "A B2BUA MUST perform loop prevention. One way to do this > is to propagate > > the Max-Forwards header from the incoming request to the > outgoing request > > in the same way that a proxy does." > > > I don't understand what it means to have normative language > for a beast > which is fundamentally undefined. Suppose I write a piece of > code which > accepts SIP requests, issues tachyon commands to alpha centauri, and > meanwhile receives routing instructions from a chronosynclastic > infundibulum (for the unintiated, that is a device which > effects reverse > causality based on the message to alpha centauri whose > response would not > normally arrive for 7.8 years). It then uses those routing > instructions to > formulate an outbound SIP request to the destination received > through the > chronosynclastic infundibulum. > > Question: is this application a B2BUA and hence required to have a > Max-Forwards value in the request whose value is strictly > less than the > value received in the SIP request? Beats me. Only if that's the way it wants to do it. You can defeat the loops howsoever you want. > > > It's the loops that I'm worried about, not the Max-Forwards per se. > > > There are many ways to suppress loops. Using application semantics is > actually safer than lower-layer protocol machinery because of > the hazards > introduced by protocol translation (e.g. the PSTN hop case mentioned > earlier, or a SIP<->H.323 conversion somewhere else). > > > This addresses my concern, and I think James' and possibly yours. > > > Sorry, not mine. From where I sit, the less said about B2BUAs > the better, > including asymptotically toward zero. > > Cheers, Dave. > > > Pete. > > > > ----- Original Message ----- > > From: "David R. Oran" > > To: "Pete Cordell" ; "Dean Willis" > > ; > > Sent: 05 December 2002 14:02 > > Subject: Re: [Sip] B2BUA & Max-Forwards > > > > > >> --On Thursday, December 05, 2002 12:09 PM +0000 Pete Cordell > >> wrote: > >> > >> > Dean, > >> > > >> > Firstly, your statement that "The B2BUA doesn't change > headers that > >> > transit it." seems inconsistent with the statement "It > does the same > >> > thing as ... ANY 500-pound gorilla does". I don't understand. > >> > > >> > Secondly, I think max-forwards is a special case. It is > important for > > the > >> > protection of SIP systems as it prevents loops. > >> > > >> Once a dialog is terminated at a UAS it's up to the > application to do > >> loop prevention. SIP is not involved any more. The > application could > >> compute a value of Max-forwards for initiating outgoing > calls based on > >> incoming > > calls > >> which preserves the "strictly decreasing" invariant, or > alternatively it > >> could just use the default MAx-Forwards in outgoing > requests and execute > >> a contant memory loop suppression algorithm such as > Knuth's even-odd > >> iterator. In either event the SIP spec(s) need say nothing > about this. > >> > >> > Indeed, there is a major difference between a UAS and a > B2BUA and that > > is > >> > that the former terminates a request, and the latter terminates a > > request > >> > AND ALSO forwards an associated request (or more). > >> I disagree. A UAS is a UAS. It's behavior is completely > specified by > >> RFC3261 (unless there's a hole in the spec of course...). > What it means > >> to originate (NOT FORWARD!!!!) an "associated request" is > completely > >> application dependent. If I program my child's phone to > initiate a SIP > > call > >> to my surrepititious recording device every time it > receives a call and > >> give that device first chance to over-ride policy of the > child's phone is > >> the phone a B2BUA? Yes, no, maybe so, but who cares? Tell > me what the > >> applciation is and I can write some specs for that > application and how it > >> has to originate, terminate and process SIP transactions to do that > >> application. > >> > >> I think the botom line is that there is not a single, well defined > >> appliation that one can point to and say "that's a B2BUA". > >> > >> > The impact of this > >> > difference should be covered in the spec in the > interests of protecting > >> > other SIP systems. > >> > > >> I disagree. > >> > >> > Pete. > >> > > >> > ----- Original Message ----- > >> > From: "Dean Willis" > >> > To: "'Pete Cordell'" ; > >> > Sent: 05 December 2002 01:23 > >> > Subject: RE: [Sip] B2BUA & Max-Forwards > >> > > >> > > >> >> > One issue that the recent B2BUA discussion has raised in my > >> >> > mind is what a B2BUA (whatever its decided that should be) > >> >> > should do with Max-Forwards. > >> >> > >> >> It does the same thing as it does with any other header > or body part, > >> >> which is the same thing that ANY 500-pound gorilla does > to somebody's > >> >> body parts -- whatever it wants. > >> >> > >> >> What you're asking is "what is the transparency of this > node with > >> >> respect to max-forwards", which is "#4 -- Header > Transaprency" in my > >> >> top-10 list. The specification of a back-to-back user > agent doesn't > >> >> mandate any level of transparency on this or any other header. > >> >> > >> >> -- > >> >> 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 > >> > >> ------------------------ > >> David R. Oran > >> Cisco Systems > >> 7 Ladyslipper Lane > >> Acton, MA 01720 > >> Office: +1 978 264 2048 > >> VoIP: +1 408 571 4576 > >> Email: oran@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 mailnull@www1.ietf.org Thu Dec 5 15:19:01 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26525 for ; Thu, 5 Dec 2002 15:19:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB5KLQw19857 for sip-archive@odin.ietf.org; Thu, 5 Dec 2002 15:21:26 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5KKgv19810; Thu, 5 Dec 2002 15:20:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5KEFv19499 for ; Thu, 5 Dec 2002 15:14:15 -0500 Received: from moutvdom.kundenserver.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26217 for ; Thu, 5 Dec 2002 15:11:19 -0500 (EST) Received: from [212.227.126.222] (helo=mrvdomng.kundenserver.de) by moutvdom.kundenserver.de with esmtp (Exim 3.35 #1) id 18K2Ns-00023F-00; Thu, 05 Dec 2002 21:14:08 +0100 Received: from [62.155.142.161] (helo=MHHBWMBC.wwnet.ww) by mrvdomng.kundenserver.de with esmtp (Exim 3.35 #1) id 18K2Nr-0008O4-00; Thu, 05 Dec 2002 21:14:08 +0100 Subject: RE: [Sip] B2BUA From: Wilhelm Wimmreuter To: Henry Sinnreich Cc: "'Liebhart Rainer'" , "'Pete Cordell'" , sip@ietf.org In-Reply-To: <000001c29c8a$7eb6e310$942a2aa6@hsinnreich2> References: <000001c29c8a$7eb6e310$942a2aa6@hsinnreich2> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 05 Dec 2002 21:14:03 +0100 Message-Id: <1039119246.1798.11.camel@mhhbwmbc> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Henry, cant resist throwing my nonsense in as well On Thu, 2002-12-05 at 19:16, Henry Sinnreich wrote: > Rainer, the fact is that people could communicate on 9/11/01 using IM > and SIP telephony from Columbia University, while the telecom phone > service, both landline and mobile was down for days. > > There is very little or very much to comment on these facts. > Did you forget, that a qualified busy/congestion tone, even for some days, does not reflect a system outage ;-) ... If required, call me on my SIP phone to sort that out. It will work as usual :-) Willi _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Thu Dec 5 15:28:49 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26891 for ; Thu, 5 Dec 2002 15:28:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB5KVEL20322 for sip-archive@odin.ietf.org; Thu, 5 Dec 2002 15:31:14 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5KNYv19955; Thu, 5 Dec 2002 15:23:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5KGjv19605 for ; Thu, 5 Dec 2002 15:16:45 -0500 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26257 for ; Thu, 5 Dec 2002 15:13:49 -0500 (EST) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id gB5KGb0R005769; Thu, 5 Dec 2002 12:16:37 -0800 (PST) Received: from ORANLT.cisco.com ([161.44.238.36]) by mira-sjc5-9.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id ECF00404; Thu, 5 Dec 2002 12:16:59 -0800 (PST) Date: Thu, 05 Dec 2002 15:16:27 -0500 From: David Oran To: Gordon Ledgard , Pete Cordell , Dean Willis , sip@ietf.org Subject: RE: [Sip] B2BUA & Max-Forwards Message-ID: <25423627.1039101387@ORANLT.cisco.com> In-Reply-To: <1A69639B9B6AD511812B00B0D0DE19F60A3935@commserver.erictest.com> References: <1A69639B9B6AD511812B00B0D0DE19F60A3935@commserver.erictest.com> X-Mailer: Mulberry/3.0.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit --On Thursday, December 05, 2002 3:03 PM -0500 Gordon Ledgard wrote: > inline - > >> -----Original Message----- >> From: David Oran [mailto:oran@cisco.com] >> Sent: Thursday, December 05, 2002 2:11 PM >> To: Pete Cordell; Dean Willis; sip@ietf.org >> Subject: Re: [Sip] B2BUA & Max-Forwards >> >> >> --On Thursday, December 05, 2002 5:24 PM +0000 Pete Cordell >> wrote: >> >> > Dave, >> > >> > To save your disagreeableness, can we say something like: >> > >> > "A B2BUA MUST perform loop prevention. One way to do this >> is to propagate >> > the Max-Forwards header from the incoming request to the >> outgoing request >> > in the same way that a proxy does." >> > >> I don't understand what it means to have normative language >> for a beast >> which is fundamentally undefined. Suppose I write a piece of >> code which >> accepts SIP requests, issues tachyon commands to alpha centauri, and >> meanwhile receives routing instructions from a chronosynclastic >> infundibulum (for the unintiated, that is a device which >> effects reverse >> causality based on the message to alpha centauri whose >> response would not >> normally arrive for 7.8 years). It then uses those routing >> instructions to >> formulate an outbound SIP request to the destination received >> through the >> chronosynclastic infundibulum. >> >> Question: is this application a B2BUA and hence required to have a >> Max-Forwards value in the request whose value is strictly >> less than the >> value received in the SIP request? Beats me. > > Only if that's the way it wants to do it. You can defeat > the loops howsoever you want. > Ok, then how about the following wording: "a B2BUA MUST prevent loops and it MUST NOT behave in such as way as to cause broadcast storms, or contribute to any exponential message explosion of SIP or any other messages. In addition, it MUST comply will all local and national fire codes, including the Underwriter's Laboratory flaming oil test*. *Note: this is important guidance for implementers. I once had a device I helped design fail the flaming oil test for one of the six possible mounting orientations of the box (it passed in the other 5 orientations). The orientation it failed in was with all of the I/O sockets facing the wall (making it impossible to plug anything into the box, but that didn't matter to the testers). Tiring of this subject, as should be apparent...Dave. >> >> > It's the loops that I'm worried about, not the Max-Forwards per se. >> > >> There are many ways to suppress loops. Using application semantics is >> actually safer than lower-layer protocol machinery because of >> the hazards >> introduced by protocol translation (e.g. the PSTN hop case mentioned >> earlier, or a SIP<->H.323 conversion somewhere else). >> >> > This addresses my concern, and I think James' and possibly yours. >> > >> Sorry, not mine. From where I sit, the less said about B2BUAs >> the better, >> including asymptotically toward zero. >> >> Cheers, Dave. >> >> > Pete. >> > >> > ----- Original Message ----- >> > From: "David R. Oran" >> > To: "Pete Cordell" ; "Dean Willis" >> > ; >> > Sent: 05 December 2002 14:02 >> > Subject: Re: [Sip] B2BUA & Max-Forwards >> > >> > >> >> --On Thursday, December 05, 2002 12:09 PM +0000 Pete Cordell >> >> wrote: >> >> >> >> > Dean, >> >> > >> >> > Firstly, your statement that "The B2BUA doesn't change >> headers that >> >> > transit it." seems inconsistent with the statement "It >> does the same >> >> > thing as ... ANY 500-pound gorilla does". I don't understand. >> >> > >> >> > Secondly, I think max-forwards is a special case. It is >> important for >> > the >> >> > protection of SIP systems as it prevents loops. >> >> > >> >> Once a dialog is terminated at a UAS it's up to the >> application to do >> >> loop prevention. SIP is not involved any more. The >> application could >> >> compute a value of Max-forwards for initiating outgoing >> calls based on >> >> incoming >> > calls >> >> which preserves the "strictly decreasing" invariant, or >> alternatively it >> >> could just use the default MAx-Forwards in outgoing >> requests and execute >> >> a contant memory loop suppression algorithm such as >> Knuth's even-odd >> >> iterator. In either event the SIP spec(s) need say nothing >> about this. >> >> >> >> > Indeed, there is a major difference between a UAS and a >> B2BUA and that >> > is >> >> > that the former terminates a request, and the latter terminates a >> > request >> >> > AND ALSO forwards an associated request (or more). >> >> I disagree. A UAS is a UAS. It's behavior is completely >> specified by >> >> RFC3261 (unless there's a hole in the spec of course...). >> What it means >> >> to originate (NOT FORWARD!!!!) an "associated request" is >> completely >> >> application dependent. If I program my child's phone to >> initiate a SIP >> > call >> >> to my surrepititious recording device every time it >> receives a call and >> >> give that device first chance to over-ride policy of the >> child's phone is >> >> the phone a B2BUA? Yes, no, maybe so, but who cares? Tell >> me what the >> >> applciation is and I can write some specs for that >> application and how it >> >> has to originate, terminate and process SIP transactions to do that >> >> application. >> >> >> >> I think the botom line is that there is not a single, well defined >> >> appliation that one can point to and say "that's a B2BUA". >> >> >> >> > The impact of this >> >> > difference should be covered in the spec in the >> interests of protecting >> >> > other SIP systems. >> >> > >> >> I disagree. >> >> >> >> > Pete. >> >> > >> >> > ----- Original Message ----- >> >> > From: "Dean Willis" >> >> > To: "'Pete Cordell'" ; >> >> > Sent: 05 December 2002 01:23 >> >> > Subject: RE: [Sip] B2BUA & Max-Forwards >> >> > >> >> > >> >> >> > One issue that the recent B2BUA discussion has raised in my >> >> >> > mind is what a B2BUA (whatever its decided that should be) >> >> >> > should do with Max-Forwards. >> >> >> >> >> >> It does the same thing as it does with any other header >> or body part, >> >> >> which is the same thing that ANY 500-pound gorilla does >> to somebody's >> >> >> body parts -- whatever it wants. >> >> >> >> >> >> What you're asking is "what is the transparency of this >> node with >> >> >> respect to max-forwards", which is "#4 -- Header >> Transaprency" in my >> >> >> top-10 list. The specification of a back-to-back user >> agent doesn't >> >> >> mandate any level of transparency on this or any other header. >> >> >> >> >> >> -- >> >> >> 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 >> >> >> >> ------------------------ >> >> David R. Oran >> >> Cisco Systems >> >> 7 Ladyslipper Lane >> >> Acton, MA 01720 >> >> Office: +1 978 264 2048 >> >> VoIP: +1 408 571 4576 >> >> Email: oran@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 mailnull@www1.ietf.org Thu Dec 5 15:36:38 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27325 for ; Thu, 5 Dec 2002 15:36:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB5Kd3921414 for sip-archive@odin.ietf.org; Thu, 5 Dec 2002 15:39:03 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5KYgv20472; Thu, 5 Dec 2002 15:34:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5KVjv20369 for ; Thu, 5 Dec 2002 15:31:45 -0500 Received: from mail.siemenscom.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26888 for ; Thu, 5 Dec 2002 15:28:48 -0500 (EST) Received: from mail-stc.rolm.com (mail-stc.siemenscom.com [12.146.131.7]) by mail.siemenscom.com (8.9.3/8.9.3) with ESMTP id MAA11219; Thu, 5 Dec 2002 12:31:38 -0800 (PST) Received: from stca200a.bus.sc.rolm.com (stca200a.bus.sc.rolm.com [165.218.68.180]) by mail-stc.rolm.com (8.11.6/8.11.6) with ESMTP id gB5KMPu22497; Thu, 5 Dec 2002 12:22:25 -0800 (PST) Received: by stca200a.bus.sc.rolm.com with Internet Mail Service (5.5.2653.19) id <49ZXKDYJ>; Thu, 5 Dec 2002 12:31:37 -0800 Message-ID: From: "Carr, Steve" To: "'Henry Sinnreich'" , "'Pete Cordell'" Cc: sip@ietf.org Subject: RE: [Sip] B2BUA Date: Thu, 5 Dec 2002 12:31:36 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , http://www.lightreading.com/document.asp?doc_id=22549&site=lightreading Some company called WorldCom, who are they?? :-{ -----Original Message----- From: Henry Sinnreich [mailto:Henry.Sinnreich@wcom.com] Sent: Thursday, December 05, 2002 12:57 PM To: 'Pete Cordell' Cc: sip@ietf.org Subject: RE: [Sip] B2BUA Can you document any _outages_ of the _Internet_? I don't recall any. Please provide references. Thanks, Henry > -----Original Message----- > From: Pete Cordell [mailto:pete@tech-know-ware.com] > Sent: Thursday, December 05, 2002 6:25 AM > To: Henry Sinnreich > Cc: sip@ietf.org > Subject: Re: [Sip] B2BUA > > > Henry, > > The Internet has had a few famous outages as well. Besides, > if all the telco traffic was put over IP, with today's level > of QoS on the Internet, it would have been brought to its knees also. > > To say that one is all goodness and light and the other all > evil doesn't do us as a community any good as when customers > find out there are problems they tend not to believe anything > else we say! > > Only vapourware is flawless. Most people know that. Respect > the intelligence of your customer, or they will find somebody > that does!!! > > Pete. > > ----- Original Message ----- > From: "Henry Sinnreich" > To: "'Phil Reynolds'" ; > Sent: 04 December 2002 19:02 > Subject: RE: [Sip] B2BUA > > > > >The telecoms people are clever enough to have thought > > >about that and build redundancy, fault tolerance and failover into > > their switches. > > > > This has proven unfortunately not to be the case on > September 11 when > > telecom service failed for days, while Internet traffic continued > > smoothly. I suggest you to look at the central control model of the > > switch network versus the e2e architecture of the Internet. SIP > > enabled networks are also fully distributed and the e2e control > > principle maintained - that's why state in placed in SIP endpoints. > > > > I am not sure if a few words here can give full justice to the > > superior resilience of the Internet and to SIP enabled services,... > > > > Thanks, Henry > > > > -----Original Message----- > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of Phil > > Reynolds > > Sent: Wednesday, December 04, 2002 7:37 AM > > To: sip@ietf.org > > Subject: RE: [Sip] B2BUA > > > > > > If a telephone switch crashes you loose all calls... The telecoms > > people are clever enough to have thought about that and build > > redundancy, fault tolerance and failover into their switches. Maybe > > some of us IP-telecoms people have thought of similar > techniques for > > SIP intermediaries? -----Original Message----- > > From: Jiri Kuthan [mailto:jiri.kuthan@fokus.fraunhofer.de] > > Sent: 04 December 2002 12:32 > > To: Christian Huitema; Roy, Radhika R, ALASO; > mbarnes@nortelnetworks.com > > > > Cc: dean.willis@softarmor.com; Juan-Carlos.Rojas@alcatel.fr; > > sip@ietf.org > > Subject: RE: [Sip] B2BUA > > [...snip...] > > I think there are more issues with B2BUA. A B2BUA's failure affects > > all current calls :-( -Jiri > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Thu Dec 5 17:15:34 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02507 for ; Thu, 5 Dec 2002 17:15:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB5MI1i27646 for sip-archive@odin.ietf.org; Thu, 5 Dec 2002 17:18:01 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5MGbv27551; Thu, 5 Dec 2002 17:16:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5MBhv27223 for ; Thu, 5 Dec 2002 17:11:43 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02265 for ; Thu, 5 Dec 2002 17:08:45 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gB5MBZQ1005544; Thu, 5 Dec 2002 23:11:35 +0100 (MET) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id YFXDR1L5; Thu, 5 Dec 2002 23:11:35 +0100 Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.106.10]) by hendrix.lmf.ericsson.se (8.12.6/8.12.6/lmf-2.1-jcs) with ESMTP id gB5MBZu4006919; Fri, 6 Dec 2002 00:11:35 +0200 (EET) Message-ID: <3DEFCF15.3C381C9F@lmf.ericsson.se> Date: Fri, 06 Dec 2002 00:11:33 +0200 X-Sybari-Trust: ce3eedd3 ca231590 0ab44ba3 00000138 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: sip@ietf.org Subject: Re: [Sip] ABNF issue References: <3DEF27BE.80ED31E2@lmf.ericsson.se> <3DEF7F8D.70902@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Jonathan, > Christer Holmberg wrote: > > Hi, > > > > The ABNF syntax in RFC3261 says the following things: > > > > LWS = [*WSP CRLF] 1*WSP ; linear whitespace > > > > Request = Request-Line > > *( message-header ) > > CRLF > > [ message-body ] > > > > message-body = *OCTET > > > > Also, the syntax says that every message-header ends with CTRL. > > > > Now, the spec says that the SIP part of a message ends with CTRL CTRL. > > > > However, if the message-body part starts with one or more WSP, won't the > > > > CRLF between the message-body be interpreted as LWS instead? Ie, there > > will NOT be CRLF CRLF at the end of the SIP part of message, but instead > > > > CRLF LWS. > > I don't know how you come to this conclusion. If the body starts with > LWS, you will see a CRLF after the last header field, another CRLF > before the body, and then an LWS which is the first byte of the body. Thus: > > CRLF CRLF LWS > > which is fine. The body does not start with LWS. The body starts with WSP (RFC3261 doesn't define what WSP is, but if I remember correct it is SP or TAB). So, in that case you will have: CRLF CRLF WSP ...which, according to the ABNF is: CRLF LWS Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Thu Dec 5 20:56:19 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09269 for ; Thu, 5 Dec 2002 20:56:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB61wl208241 for sip-archive@odin.ietf.org; Thu, 5 Dec 2002 20:58:47 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB61t9v07985; Thu, 5 Dec 2002 20:55:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB61p1v07822 for ; Thu, 5 Dec 2002 20:51:01 -0500 Received: from pmesmtp02.wcom.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09063 for ; Thu, 5 Dec 2002 20:48:03 -0500 (EST) Received: from pmismtp03.wcomnet.com ([166.38.62.38]) by firewall.wcom.com (Iplanet MTA ) with ESMTP id <0H6O0073ID4JEW@firewall.wcom.com> for sip@ietf.org; Fri, 06 Dec 2002 01:50:43 +0000 (GMT) Received: from pmismtp03.wcomnet.com by pmismtp03.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0H6O00I01D4JN2@pmismtp03.wcomnet.com>; Fri, 06 Dec 2002 01:50:43 +0000 (GMT) Received: from hsinnreich2 ([166.50.112.53]) by pmismtp03.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0H6O00I4FD4105@pmismtp03.wcomnet.com>; Fri, 06 Dec 2002 01:50:42 +0000 (GMT) Date: Thu, 05 Dec 2002 19:50:24 -0600 From: Henry Sinnreich Subject: RE: [Sip] B2BUA In-reply-to: <1039119246.1798.11.camel@mhhbwmbc> To: "'Wilhelm Wimmreuter'" Cc: "'Liebhart Rainer'" , "'Pete Cordell'" , sip@ietf.org Message-id: <004b01c29cc9$e0ddff80$357032a6@hsinnreich2> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1097 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit No "qualified busy/congestion tone" was experienced by any IM, e-mail or SIP users. Henry > -----Original Message----- > From: Wilhelm Wimmreuter [mailto:wilhelm@wimmreuter.de] > Sent: Thursday, December 05, 2002 2:14 PM > To: Henry Sinnreich > Cc: 'Liebhart Rainer'; 'Pete Cordell'; sip@ietf.org > Subject: RE: [Sip] B2BUA > > > Hi Henry, > cant resist throwing my nonsense in as well > > On Thu, 2002-12-05 at 19:16, Henry Sinnreich wrote: > > Rainer, the fact is that people could communicate on > 9/11/01 using IM > > and SIP telephony from Columbia University, while the telecom phone > > service, both landline and mobile was down for days. > > > > There is very little or very much to comment on these facts. > > > > Did you forget, that a qualified busy/congestion tone, even > for some days, does not reflect a system outage ;-) > > ... If required, call me on my SIP phone to sort that out. > It will work as usual :-) > > Willi > > > > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Thu Dec 5 20:57:29 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09312 for ; Thu, 5 Dec 2002 20:57:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB61xuE08311 for sip-archive@odin.ietf.org; Thu, 5 Dec 2002 20:59:56 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB61u6v08111; Thu, 5 Dec 2002 20:56:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB61twv08091 for ; Thu, 5 Dec 2002 20:55:58 -0500 Received: from mail4.microsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09174 for ; Thu, 5 Dec 2002 20:53:00 -0500 (EST) Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 5 Dec 2002 17:55:08 -0800 Received: from 157.54.8.23 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 05 Dec 2002 17:55:03 -0800 Received: from RED-IMC-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 5 Dec 2002 17:55:10 -0800 Received: from WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 5 Dec 2002 17:55:09 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3710.0); Thu, 5 Dec 2002 17:55:05 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Sip] B2BUA - Security Date: Thu, 5 Dec 2002 17:55:05 -0800 Message-ID: Thread-Topic: [Sip] B2BUA - Security Thread-Index: AcKck3dWFE/Y18xZSImGMp6KJbqPYwANvdUA From: "Christian Huitema" To: "Mahey, Sonit" , "Jonathan Rosenberg" , "Pete Cordell" Cc: X-OriginalArrivalTime: 06 Dec 2002 01:55:05.0492 (UTC) FILETIME=[7F6C3540:01C29CCA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gB61twv08092 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit The sending UA places the result of the STUN translation in the SDP, not the private addresses and port numbers. > -----Original Message----- > From: Mahey, Sonit [mailto:Sonit.Mahey@icn.siemens.com] > Sent: Thursday, December 05, 2002 10:00 AM > To: Christian Huitema; Jonathan Rosenberg; Pete Cordell > Cc: sip@ietf.org > Subject: RE: [Sip] B2BUA - Security > > Thanks, Christian. > > Assuming IPv4 addresses and without delving into the draft RFC on STUN: > The SDP contains the RTP/RTCP port numbers that are private and these are > also required to be NAT'd. Now, if the SDP, which forms part of the SIP > body, is encrypted, how will RTP/RTCP ports be translated? > > regards, > - sonit > > > -----Original Message----- > > From: Christian Huitema [mailto:huitema@windows.microsoft.com] > > Sent: Thursday, December 05, 2002 12:54 PM > > To: Mahey, Sonit; Jonathan Rosenberg; Pete Cordell > > Cc: sip@ietf.org > > Subject: RE: [Sip] B2BUA - Security > > > > > > > From: Mahey, Sonit [mailto:Sonit.Mahey@icn.siemens.com] > > > Sent: Thursday, December 05, 2002 9:14 AM > > > > > > I agree with Jonathan. > > > > > > That brings up the question: > > > Is NAT traversal for encrypted SIP traffic addressed anywhere? > > > > There are two possibilities. If your application only uses UDP, it is > > possible to use IPv4 and STUN to find out the "outside ports" for your > > UDP traffic (check draft-ietf-midcom-stun-03.txt); you may need to use > > the "a:rtcp" convention to encode port numbers in SDP (check > > draft-ietf-mmusic-sdp4nat-03.txt). If you need to also support TCP, or > > use IPSEC, or generally do away with the complications of > > NAT, the best > > solution is to just move to IPv6; see Teredo > > (draft-ietf-ngtrans-shipworm-08.txt) for one possible way to > > carry IPv6 > > across NAT, and 6to4 (RFC 3056 & 3068) for a possible way to > > upgrade the > > NAT and make it an IPv6 router. > > > > -- Christian Huitema > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Fri Dec 6 01:01:29 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15841 for ; Fri, 6 Dec 2002 01:01:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB6640o21527 for sip-archive@odin.ietf.org; Fri, 6 Dec 2002 01:04:00 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB663Yv21516; Fri, 6 Dec 2002 01:03:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB661lv21396 for ; Fri, 6 Dec 2002 01:01:47 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15719 for ; Fri, 6 Dec 2002 00:58:45 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.83]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gB661cYH012836; Fri, 6 Dec 2002 01:01:38 -0500 (EST) Message-ID: <3DF03D40.2030608@dynamicsoft.com> Date: Fri, 06 Dec 2002 01:01:36 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christer Holmberg CC: sip@ietf.org Subject: Re: [Sip] ABNF issue References: <3DEF27BE.80ED31E2@lmf.ericsson.se> <3DEF7F8D.70902@dynamicsoft.com> <3DEFCF15.3C381C9F@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit inline. Christer Holmberg wrote: > The body does not start with LWS. The body starts with WSP (RFC3261 doesn't > define what WSP is, but if I remember correct it is SP or TAB). So, in that > case you will have: > > CRLF CRLF WSP > > ...which, according to the ABNF is: > > CRLF LWS You are taking this out of context. It is not the case that you would parse through the message replaceing all instances of CRLF WSP with LWS. The BNF specifies that message-header ends with a CRLF. What follows that is one of two things - either another CRLF, marking the end of the headers, or another message header, which never begins with LWS. Thus, if a CRLF is followed by something OTHER than WSP, the next construction cannot be LWS. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.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 mailnull@www1.ietf.org Fri Dec 6 01:14:57 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16093 for ; Fri, 6 Dec 2002 01:14:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB66HSH22608 for sip-archive@odin.ietf.org; Fri, 6 Dec 2002 01:17:28 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB66H9v22554; Fri, 6 Dec 2002 01:17:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB66ETv22444 for ; Fri, 6 Dec 2002 01:14:29 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16013 for ; Fri, 6 Dec 2002 01:11:27 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.83]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gB66DlYH012846; Fri, 6 Dec 2002 01:13:48 -0500 (EST) Message-ID: <3DF04018.7050200@dynamicsoft.com> Date: Fri, 06 Dec 2002 01:13:44 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Mahey, Sonit" CC: "'Christian Huitema'" , Pete Cordell , sip@ietf.org Subject: Re: [Sip] B2BUA - Security References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit When STUN is used, there is no need to translate. THe client itself inserts the proper addresses. If you are not using stun, and rather using an ALG or an FCP ala midcom, and the SIP body is encrypted, well, right now you are out of luck. I will once again point out that this is the reason I wrote the session policy draft: http://www.jdrosen.net/papers/draft-rosenberg-sipping-session-policy-00.txt -Jonathan R. Mahey, Sonit wrote: > Thanks, Christian. > > Assuming IPv4 addresses and without delving into the draft RFC on STUN: > The SDP contains the RTP/RTCP port numbers that are private and these are > also required to be NAT'd. Now, if the SDP, which forms part of the SIP > body, is encrypted, how will RTP/RTCP ports be translated? > > regards, > - sonit > > >>-----Original Message----- >>From: Christian Huitema [mailto:huitema@windows.microsoft.com] >>Sent: Thursday, December 05, 2002 12:54 PM >>To: Mahey, Sonit; Jonathan Rosenberg; Pete Cordell >>Cc: sip@ietf.org >>Subject: RE: [Sip] B2BUA - Security >> >> >> >>>From: Mahey, Sonit [mailto:Sonit.Mahey@icn.siemens.com] >>>Sent: Thursday, December 05, 2002 9:14 AM >>> >>>I agree with Jonathan. >>> >>>That brings up the question: >>>Is NAT traversal for encrypted SIP traffic addressed anywhere? >> >>There are two possibilities. If your application only uses UDP, it is >>possible to use IPv4 and STUN to find out the "outside ports" for your >>UDP traffic (check draft-ietf-midcom-stun-03.txt); you may need to use >>the "a:rtcp" convention to encode port numbers in SDP (check >>draft-ietf-mmusic-sdp4nat-03.txt). If you need to also support TCP, or >>use IPSEC, or generally do away with the complications of >>NAT, the best >>solution is to just move to IPv6; see Teredo >>(draft-ietf-ngtrans-shipworm-08.txt) for one possible way to >>carry IPv6 >>across NAT, and 6to4 (RFC 3056 & 3068) for a possible way to >>upgrade the >>NAT and make it an IPv6 router. >> >>-- Christian Huitema >> > > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.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 mailnull@www1.ietf.org Fri Dec 6 01:24:05 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16325 for ; Fri, 6 Dec 2002 01:24:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB66QZ123041 for sip-archive@odin.ietf.org; Fri, 6 Dec 2002 01:26:35 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB66QDv23029; Fri, 6 Dec 2002 01:26:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB66Pov23001 for ; Fri, 6 Dec 2002 01:25:50 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16283 for ; Fri, 6 Dec 2002 01:22:50 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.83]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gB66PgYH012870; Fri, 6 Dec 2002 01:25:42 -0500 (EST) Message-ID: <3DF042E4.70504@dynamicsoft.com> Date: Fri, 06 Dec 2002 01:25:40 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pete Cordell CC: Adam Roach , "'Phil Reynolds'" , sip@ietf.org Subject: Re: [Sip] B2BUA & Max-Forwards References: <9BF66EBF6BEFD942915B4D4D45C051F3A64377@DYN-TX-EXCH-001.dynamicsoft.com> <3DEEF411.2020408@dynamicsoft.com> <013901c29c5d$e02c81e0$0200000a@tkw> <3DEF7BF4.5070706@dynamicsoft.com> <007d01c29c80$092ebc80$0200000a@tkw> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Pete Cordell wrote: > Jonathan, > > I have not said anything about generic B2BUAs here. Each B2BUA > implementation will need to have its own record (and server) of what it is > transparent to or not. It would not be a generic list. > > Perhaps it is reasonable to remove the B2BUA definition, since there is no > definition of a gateway and they are similar beasts. Just as long as such > an action does not imply that SIP is not suitable for a certain class of > problem. Removal of the definition has nothing at all to do with whether or not such a SIP application can be built. Clearly it can. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.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 mailnull@www1.ietf.org Fri Dec 6 01:44:40 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16847 for ; Fri, 6 Dec 2002 01:44:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB66l9x24659 for sip-archive@odin.ietf.org; Fri, 6 Dec 2002 01:47:09 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB66kfv24639; Fri, 6 Dec 2002 01:46:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB66juv24596 for ; Fri, 6 Dec 2002 01:45:56 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16816 for ; Fri, 6 Dec 2002 01:42:55 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.83]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gB66jmYH012875; Fri, 6 Dec 2002 01:45:48 -0500 (EST) Message-ID: <3DF04799.7010208@dynamicsoft.com> Date: Fri, 06 Dec 2002 01:45:45 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pete Cordell CC: Christian Huitema , sip@ietf.org Subject: Re: [Sip] B2BUA - Security References: <013d01c29c5d$e4a7f7e0$0200000a@tkw> <3DEF7EAB.2070109@dynamicsoft.com> <009801c29c83$985129e0$0200000a@tkw> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit inline as always. But, first, a question. Pete - what are you after? Are you actually trying to convince the working group to disallow encryption/authentication over SDP so that your b2bua-thingy can modify it?? As I have tried to argue in my session policy draft, there are a LOT of issues with intermediary modification of media information, many of them related to the kind of things OPES has been dealing with. You need to consider the problem more broadly. Pete Cordell wrote: >>1. modifying SDP in transit to point media streams to an intermediate >>recording device, allowing attackers to establish wiretaps > > > This is only partially successful. Encryption of RTP is the only complete > solution. True. > > >>2. downgrading any SRTP keying done in SDP, so that the media itself is >>not encrypted or integrity protected (this came up during the mmusic >>session in IETF as a driver for S/MIME) > > > I don't think you need to encrypt the entire SDP body to prevent key > downgrading. In the absence of any other contraints that might be a simple > route to go, but if it causes problems (as it is) then we should look at > other ways. You need to protect the key exchanges. I am trying to establish that a lot of the information in SDP needs to be protected e2e. > > As an aside - This is the sort of reason I would like to get this sort of > thing on the agenda. It's not that its not possible to enable SIP to meet > these requirements, there's just not a desire to do among the core SIP > people. I know why they don't want to do it, but I also think that SIP > fails to address a whole class of problem as a result. In the long run I > think that will be detrimental to SIP. I have no idea what "it" is in this aside. > > >>3. launching a DoS attack by sending everyones voice traffic to the >>intended target. You get huge amplification gains here. Very appealing >>for hackers! > > > Don't need SDP to do that. I could just rip out the entire SDP and put in a > new version. I might not get the ports right, but I could probably cause > enough damage to get my kicks. If you rip it out and replace it, and the UA is requiring signed SDP, then this won't work. Another interesting attack I thought of, is to modify the SDP to send the RTP to a relay, which does forward it to the right destination, but only after inserting 100ms of delay. The result is that the conversation takes place, but at lousy quality. Why do this? Maybe a way for one provider to convince customers of another provider to switch. Dropping the packets outright might be too overt of an attack, but a subtle increase in delays... just a thought. >>Confidentiality is only one property of security. I am much more >>concerned about message integrity. > > > Integrity of which bits? And are you sure that maintaining integrity buys > you anything except for in a few special cases? Definitely. I don't want someone removing my video stream my session. I don't want someone to modify my codecs, forcing me to use a lower quality one when a better one would actually work. I don't want someone to receive my media when I intended it for the party I called. And so on. The above concerns are real, and cover a good set of the information in SDP. Let me pose the question in reverse. What information in SDP do you feel is NOT worth protecting? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.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 mailnull@www1.ietf.org Fri Dec 6 01:58:23 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17152 for ; Fri, 6 Dec 2002 01:58:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB670ql25205 for sip-archive@odin.ietf.org; Fri, 6 Dec 2002 02:00:52 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB670Sv25185; Fri, 6 Dec 2002 02:00:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB66x9v25118 for ; Fri, 6 Dec 2002 01:59:09 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17123 for ; Fri, 6 Dec 2002 01:56:09 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.83]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gB66wvYH012885; Fri, 6 Dec 2002 01:58:57 -0500 (EST) Message-ID: <3DF04AAE.9080301@dynamicsoft.com> Date: Fri, 06 Dec 2002 01:58:54 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pete Cordell CC: "David R. Oran" , Dean Willis , sip@ietf.org Subject: Re: [Sip] B2BUA & Max-Forwards References: <00cd01c29bfc$e7dd0240$fe0c0c42@txdwillis> <013a01c29c5d$e1591b00$0200000a@tkw> <2986103.1039078949@ORANLT.cisco.com> <009901c29c83$9a304a20$0200000a@tkw> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Pete Cordell wrote: > Dave, > > To save your disagreeableness, can we say something like: > > "A B2BUA MUST perform loop prevention. One way to do this is to propagate > the Max-Forwards header from the incoming request to the outgoing request in > the same way that a proxy does." A statement like this is completely out of scope for rfc3261. It might be a reasonable statement to make in some kind of application document that describes a particular type of b2bua. However, it makes no more sense to say this in RFC 3261 as it would be to discuss the ways in which to build a focus or a 3pcc controller (both of which are also informational, by the way). I can't resist pointing out that much of this is deja vu. Folks may recall heated discussions in Adelaide, where there was a bof (I think) that wanted to have a working group to specify SIP to H.323 conversion. THe same arguemtns that were made there are being made here; its an application level issue, there are many ways to do it, don't stifle creativity, etc. In fact I recall that Dave was, as always, quite vociferous on these points. The eventual conclusion in the h323/sip conversion case was to write an INFORMATIONAL RFC that documents reasonable practices in building such a device. I believe the same logic and conclusions apply here. If folks have a particular type of b2bua application they are fond of, please feel free to write up your implementation advice and I am sure sipping would consider whether or not it would make a useful informational RFC. However, it is completely inappropriate to ever make such application logic normative, and even more inappropraite for such wording to be in rfc3261. Anyway, I too am tired of this thread. I think, in fact, there is "rough" consensus to remove the definition of b2bua entirely from rfc3261 in its next revision (which is quite some time in the future anyway). However, I'll let the chairs decide that. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.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 mailnull@www1.ietf.org Fri Dec 6 02:35:24 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27682 for ; Fri, 6 Dec 2002 02:35:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB67bs405424 for sip-archive@odin.ietf.org; Fri, 6 Dec 2002 02:37:54 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB67bUv05411; Fri, 6 Dec 2002 02:37:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB67ZFv04744 for ; Fri, 6 Dec 2002 02:35:15 -0500 Received: from smail3.alcatel.fr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27620 for ; Fri, 6 Dec 2002 02:32:14 -0500 (EST) From: Juan-Carlos.Rojas@alcatel.fr Received: from frmail25.netfr.alcatel.fr (frmail25.netfr.alcatel.fr [155.132.182.155]) by smail3.alcatel.fr (ALCANET/NETFR) with ESMTP id gB67Z3ek029092; Fri, 6 Dec 2002 08:35:03 +0100 Subject: RE: [Sip] B2BUA & Max-Forwards To: Cc: Date: Fri, 6 Dec 2002 08:35:01 +0100 Message-ID: X-MIMETrack: Serialize by Router on FRMAIL25/FR/ALCATEL(Release 5.0.8 |June 18, 2001) at 12/06/2002 08:35:02 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hello, "I don't get this. Does two or more mean, for example, four?" Two or more means exactly that: two or more. The exact number depends on what the application is actually providing, and you cannot fixe it in advance. "but a pair of UAC/UAS concatenations" OK, I get your point, you are thinking on a specific class of application for bi-party communications. But this is only one case. At the end, I start to agree with some other people: - either we are able to provide a definition of a B2BUA independently of what the B2BUA is actually doing - or we drop the definition Best regards Juan Carlos on 05/12/2002 19:54:26 To: Juan-Carlos ROJAS/FR/ALCATEL@ALCATEL cc: Subject: RE: [Sip] B2BUA & Max-Forwards Hi, inline. > "I am at the point where I agree with the sentiment raised by others, > that we should remove the term b2bua entirely from the > specification. It > has caused more confusion than anything else." > > Yes, this is one possibility. An alternative (as I proposed > in an earlier > mail) is to complete the current definition in 3261 saying > explicitly that > : > 1) A B2BUA handles two or more UAs, each one behaving as UAC/UAS, as > described in 3261 for UAs I don't get this. Does two or more mean, for example, four? And does that in turn make it a B2BB2BUA? ;) The only minor clarification I think might be in order for RFC3261 is that it's not just a UAC/UAS concatenation, but a pair of UAC/UAS concatenations. However, the fact that the traffic in this thread alone equals to a year's worth of emails on the SIMPLE list suggests that no clarification is enough clarification. So I agree with the other people in that getting rid of the definition altogether is the best option. After all, if it looks like a UA to the outside world, it must be a UA. > 2) The SIP protocol specification does not mandate for any > behaviour of > such B2BUA, i.e. on how to "link" (or "concatenate") two or more UAs. Yes, probably the reason why the definition for a B2BUA is also useless. Cheers, Aki _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Fri Dec 6 03:28:54 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28897 for ; Fri, 6 Dec 2002 03:28:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB68VPh07990 for sip-archive@odin.ietf.org; Fri, 6 Dec 2002 03:31:25 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB68Ujv07959; Fri, 6 Dec 2002 03:30:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB68Tav07904 for ; Fri, 6 Dec 2002 03:29:36 -0500 Received: from gorilla.mchh.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28879 for ; Fri, 6 Dec 2002 03:26:34 -0500 (EST) Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id JAA25390; Fri, 6 Dec 2002 09:29:21 +0100 (MET) Received: from mchh273e.demchh201e.icn.siemens.de ([139.21.200.83]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id JAA29215; Fri, 6 Dec 2002 09:29:23 +0100 (MET) Received: by MCHH273E with Internet Mail Service (5.5.2656.59) id ; Fri, 6 Dec 2002 09:28:44 +0100 Message-ID: <1D82815C322BD41196EA00508B951F7B067A4B3A@MCHH265E> From: Liebhart Rainer To: "'Henry Sinnreich'" Cc: sip@ietf.org Subject: AW: [Sip] B2BUA Date: Fri, 6 Dec 2002 09:28:44 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gB68Tbv07905 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Henry, thank you for that info, Mary provided this already. But the question is: how many users at Columbia were using SIP as communication medium and was the communication restricted to the Columbia campus? Rainer ------------------------------------------------------------------------------- Rainer Liebhart Siemens AG ICM N PG SP ST N 1 Mch H; R. 1759/1048 Tel.: +49 89 722 50302 Fax: +49 89 722 39793 mailto:rainer.liebhart@siemens.com ------------------------------------------------------------------------------- -----Ursprüngliche Nachricht----- Von: Henry Sinnreich [mailto:Henry.Sinnreich@wcom.com] Gesendet: Donnerstag, 5. Dezember 2002 19:17 An: 'Liebhart Rainer'; 'Pete Cordell' Cc: sip@ietf.org Betreff: RE: [Sip] B2BUA Rainer, the fact is that people could communicate on 9/11/01 using IM and SIP telephony from Columbia University, while the telecom phone service, both landline and mobile was down for days. There is very little or very much to comment on these facts. Henry > -----Original Message----- > From: Liebhart Rainer [mailto:rainer.liebhart@siemens.com] > Sent: Thursday, December 05, 2002 7:46 AM > To: 'Pete Cordell'; Henry Sinnreich > Cc: sip@ietf.org > Subject: AW: [Sip] B2BUA > > > Henry, > > unfortunately you are comparing apples and pears when stating > that the telecom service failed for days after Sept 11, while > Internet traffic continued smoothly. The mentioned "telefon > service" consists of thousands of (real-time) calls to > emergency centres while the Internet traffic consists mainly > of requests to the Web pages of CNN and others (with bad > response times) to retrieve *information* on the status of > the catastrophe. > > Rainer > > > -----Ursprüngliche Nachricht----- > Von: Pete Cordell [mailto:pete@tech-know-ware.com] > Gesendet: Donnerstag, 5. Dezember 2002 13:25 > An: Henry Sinnreich > Cc: sip@ietf.org > Betreff: Re: [Sip] B2BUA > > > Henry, > > The Internet has had a few famous outages as well. Besides, > if all the telco traffic was put over IP, with today's level > of QoS on the Internet, it would have been brought to its knees also. > > To say that one is all goodness and light and the other all > evil doesn't do us as a community any good as when customers > find out there are problems they tend not to believe anything > else we say! > > Only vapourware is flawless. Most people know that. Respect > the intelligence of your customer, or they will find somebody > that does!!! > > Pete. > > ----- Original Message ----- > From: "Henry Sinnreich" > To: "'Phil Reynolds'" ; > Sent: 04 December 2002 19:02 > Subject: RE: [Sip] B2BUA > > > > >The telecoms people are clever enough to have thought > > >about that and build redundancy, fault tolerance and failover into > > their switches. > > > > This has proven unfortunately not to be the case on > September 11 when > > telecom service failed for days, while Internet traffic continued > > smoothly. I suggest you to look at the central control model of the > > switch network versus the e2e architecture of the Internet. SIP > > enabled networks are also fully distributed and the e2e control > > principle maintained - that's why state in placed in SIP endpoints. > > > > I am not sure if a few words here can give full justice to the > > superior resilience of the Internet and to SIP enabled services,... > > > > Thanks, Henry > > > > -----Original Message----- > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of Phil > > Reynolds > > Sent: Wednesday, December 04, 2002 7:37 AM > > To: sip@ietf.org > > Subject: RE: [Sip] B2BUA > > > > > > If a telephone switch crashes you loose all calls... The telecoms > > people are clever enough to have thought about that and build > > redundancy, fault tolerance and failover into their switches. Maybe > > some of us IP-telecoms people have thought of similar > techniques for > > SIP intermediaries? -----Original Message----- > > From: Jiri Kuthan [mailto:jiri.kuthan@fokus.fraunhofer.de] > > Sent: 04 December 2002 12:32 > > To: Christian Huitema; Roy, Radhika R, ALASO; > mbarnes@nortelnetworks.com > > > > Cc: dean.willis@softarmor.com; Juan-Carlos.Rojas@alcatel.fr; > > sip@ietf.org > > Subject: RE: [Sip] B2BUA > > [...snip...] > > I think there are more issues with B2BUA. A B2BUA's failure affects > > all current calls :-( -Jiri > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Fri Dec 6 10:35:43 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10595 for ; Fri, 6 Dec 2002 10:35:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB6Fc7F32667 for sip-archive@odin.ietf.org; Fri, 6 Dec 2002 10:38:07 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB6FbSv32543; Fri, 6 Dec 2002 10:37:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB6FZmv31816 for ; Fri, 6 Dec 2002 10:35:48 -0500 Received: from gadolinium.btinternet.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10419 for ; Fri, 6 Dec 2002 10:32:52 -0500 (EST) Received: from host213-122-57-72.in-addr.btopenworld.com ([213.122.57.72] helo=tkw) by gadolinium.btinternet.com with smtp (Exim 3.22 #16) id 18KKVv-00051f-00; Fri, 06 Dec 2002 15:35:40 +0000 Message-ID: <014101c29d3d$27b2f280$0200000a@tkw> From: "Pete Cordell" To: "Jonathan Rosenberg" Cc: References: <00cd01c29bfc$e7dd0240$fe0c0c42@txdwillis> <013a01c29c5d$e1591b00$0200000a@tkw> <2986103.1039078949@ORANLT.cisco.com> <009901c29c83$9a304a20$0200000a@tkw> <3DF04AAE.9080301@dynamicsoft.com> Subject: Re: [Sip] B2BUA & Max-Forwards Date: Fri, 6 Dec 2002 15:33:16 -0000 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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jonathan, As principle author of the document you obviously have a major say on what's in scope or not. However, I would argue that RFC 3261 says much about what a proxy must do to be a proxy. However, it does not do it in complete detail. For example, it does not say that it must do a SQL query to find a user records, or ask the Ferengi. It says enough about the proxy to make it functional from a SIP point of view. I'm only arguing that the spec should have the same scope for B2BUAs. There are actually less SIP issues for a B2BUA than there are for a proxy. However, I think prevention of loops is one thing it should say, as this has a direct impact on the integrity of SIP systems, and this must surely be a primary concern of the RFC. If there is no need to say something about it for B2BUAs, then I see no need to say anything about it for proxies! --- As for removing the definition of B2BUA from the RFC, that may be a sensible thing to do. The upshot of doing that is that people might start calling what is now a B2BUA, a proxy. This wouldn't be unreasonable as the functionality of a B2BUA is analogous to an FTP proxy. How about the following as a definition of a B2BUA? Or is it too loose? "Back-to-Back User Agent: A back-to-back user agent (B2BUA) is a logical entity that has one or more egress SIP dialogs associated with an ingress SIP dialog, but does not conform to the definition of a proxy. The manner in which the ingress and egress dialogs are associated is purely an implementation issue and outside the scope of this document. When it receives a request it appears from an external point of view to process the request as if it were a user agent server (UAS). On a transaction by transaction basis, to determine how the request should be handled it may generate and send SIP requests such that from an external point of view it appears as one or more user agent clients (UAC), or it may respond to the request locally." Pete. ----- Original Message ----- From: "Jonathan Rosenberg" To: "Pete Cordell" Cc: "David R. Oran" ; "Dean Willis" ; Sent: 06 December 2002 06:58 Subject: Re: [Sip] B2BUA & Max-Forwards > > > Pete Cordell wrote: > > Dave, > > > > To save your disagreeableness, can we say something like: > > > > "A B2BUA MUST perform loop prevention. One way to do this is to propagate > > the Max-Forwards header from the incoming request to the outgoing request in > > the same way that a proxy does." > > A statement like this is completely out of scope for rfc3261. It might > be a reasonable statement to make in some kind of application document > that describes a particular type of b2bua. However, it makes no more > sense to say this in RFC 3261 as it would be to discuss the ways in > which to build a focus or a 3pcc controller (both of which are also > informational, by the way). > > I can't resist pointing out that much of this is deja vu. Folks may > recall heated discussions in Adelaide, where there was a bof (I think) > that wanted to have a working group to specify SIP to H.323 conversion. > THe same arguemtns that were made there are being made here; its an > application level issue, there are many ways to do it, don't stifle > creativity, etc. In fact I recall that Dave was, as always, quite > vociferous on these points. > > The eventual conclusion in the h323/sip conversion case was to write an > INFORMATIONAL RFC that documents reasonable practices in building such a > device. I believe the same logic and conclusions apply here. If folks > have a particular type of b2bua application they are fond of, please > feel free to write up your implementation advice and I am sure sipping > would consider whether or not it would make a useful informational RFC. > > However, it is completely inappropriate to ever make such application > logic normative, and even more inappropraite for such wording to be in > rfc3261. > > Anyway, I too am tired of this thread. I think, in fact, there is > "rough" consensus to remove the definition of b2bua entirely from > rfc3261 in its next revision (which is quite some time in the future > anyway). However, I'll let the chairs decide that. > > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.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 mailnull@www1.ietf.org Fri Dec 6 10:35:45 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10608 for ; Fri, 6 Dec 2002 10:35:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB6FcA132680 for sip-archive@odin.ietf.org; Fri, 6 Dec 2002 10:38:10 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB6Fbgv32566; Fri, 6 Dec 2002 10:37:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB6FZmv31820 for ; Fri, 6 Dec 2002 10:35:48 -0500 Received: from gadolinium.btinternet.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10420 for ; Fri, 6 Dec 2002 10:32:52 -0500 (EST) Received: from host213-122-57-72.in-addr.btopenworld.com ([213.122.57.72] helo=tkw) by gadolinium.btinternet.com with smtp (Exim 3.22 #16) id 18KKVp-00051f-00; Fri, 06 Dec 2002 15:35:33 +0000 Message-ID: <013e01c29d3d$24070180$0200000a@tkw> From: "Pete Cordell" To: "David Oran" , References: <00cd01c29bfc$e7dd0240$fe0c0c42@txdwillis> <013a01c29c5d$e1591b00$0200000a@tkw> <2986103.1039078949@ORANLT.cisco.com> <009901c29c83$9a304a20$0200000a@tkw> <21471264.1039097434@ORANLT.cisco.com> Subject: Re: [Sip] B2BUA & Max-Forwards Date: Fri, 6 Dec 2002 13:36:42 -0000 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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Please see inline... ----- Original Message ----- From: "David Oran" > --On Thursday, December 05, 2002 5:24 PM +0000 Pete Cordell > wrote: > > > Dave, > > > > To save your disagreeableness, can we say something like: > > > > "A B2BUA MUST perform loop prevention. One way to do this is to propagate > > the Max-Forwards header from the incoming request to the outgoing request > > in the same way that a proxy does." > > > I don't understand what it means to have normative language for a beast > which is fundamentally undefined. Suppose I write a piece of code which > accepts SIP requests, issues tachyon commands to alpha centauri, and > meanwhile receives routing instructions from a chronosynclastic > infundibulum (for the unintiated, that is a device which effects reverse > causality based on the message to alpha centauri whose response would not > normally arrive for 7.8 years). It then uses those routing instructions to > formulate an outbound SIP request to the destination received through the > chronosynclastic infundibulum. > > Question: is this application a B2BUA and hence required to have a > Max-Forwards value in the request whose value is strictly less than the > value received in the SIP request? Beats me. If you read what I said, you would see that the cyborg (or whoever) didn't actually have to know about Max-Fowards. They could use the colonic drive if they wished to. > > > It's the loops that I'm worried about, not the Max-Forwards per se. > > > There are many ways to suppress loops. Using application semantics is > actually safer than lower-layer protocol machinery because of the hazards > introduced by protocol translation (e.g. the PSTN hop case mentioned > earlier, or a SIP<->H.323 conversion somewhere else). Which is what I was agreeing to. > > This addresses my concern, and I think James' and possibly yours. > > > Sorry, not mine. From where I sit, the less said about B2BUAs the better, > including asymptotically toward zero. But not quite zero then. Mentioning taking steps to prevent loops doesn't seem much. > > Cheers, Dave. > > > Pete. > > > > ----- Original Message ----- > > From: "David R. Oran" > > To: "Pete Cordell" ; "Dean Willis" > > ; > > Sent: 05 December 2002 14:02 > > Subject: Re: [Sip] B2BUA & Max-Forwards > > > > > >> --On Thursday, December 05, 2002 12:09 PM +0000 Pete Cordell > >> wrote: > >> > >> > Dean, > >> > > >> > Firstly, your statement that "The B2BUA doesn't change headers that > >> > transit it." seems inconsistent with the statement "It does the same > >> > thing as ... ANY 500-pound gorilla does". I don't understand. > >> > > >> > Secondly, I think max-forwards is a special case. It is important for > > the > >> > protection of SIP systems as it prevents loops. > >> > > >> Once a dialog is terminated at a UAS it's up to the application to do > >> loop prevention. SIP is not involved any more. The application could > >> compute a value of Max-forwards for initiating outgoing calls based on > >> incoming > > calls > >> which preserves the "strictly decreasing" invariant, or alternatively it > >> could just use the default MAx-Forwards in outgoing requests and execute > >> a contant memory loop suppression algorithm such as Knuth's even-odd > >> iterator. In either event the SIP spec(s) need say nothing about this. > >> > >> > Indeed, there is a major difference between a UAS and a B2BUA and that > > is > >> > that the former terminates a request, and the latter terminates a > > request > >> > AND ALSO forwards an associated request (or more). > >> I disagree. A UAS is a UAS. It's behavior is completely specified by > >> RFC3261 (unless there's a hole in the spec of course...). What it means > >> to originate (NOT FORWARD!!!!) an "associated request" is completely > >> application dependent. If I program my child's phone to initiate a SIP > > call > >> to my surrepititious recording device every time it receives a call and > >> give that device first chance to over-ride policy of the child's phone is > >> the phone a B2BUA? Yes, no, maybe so, but who cares? Tell me what the > >> applciation is and I can write some specs for that application and how it > >> has to originate, terminate and process SIP transactions to do that > >> application. > >> > >> I think the botom line is that there is not a single, well defined > >> appliation that one can point to and say "that's a B2BUA". > >> > >> > The impact of this > >> > difference should be covered in the spec in the interests of protecting > >> > other SIP systems. > >> > > >> I disagree. > >> > >> > Pete. > >> > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Fri Dec 6 10:35:56 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10622 for ; Fri, 6 Dec 2002 10:35:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB6FcL532758 for sip-archive@odin.ietf.org; Fri, 6 Dec 2002 10:38:21 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB6Fbjv32585; Fri, 6 Dec 2002 10:37:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB6FZov31825 for ; Fri, 6 Dec 2002 10:35:50 -0500 Received: from gadolinium.btinternet.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10425 for ; Fri, 6 Dec 2002 10:32:54 -0500 (EST) Received: from host213-122-57-72.in-addr.btopenworld.com ([213.122.57.72] helo=tkw) by gadolinium.btinternet.com with smtp (Exim 3.22 #16) id 18KKVt-00051f-00; Fri, 06 Dec 2002 15:35:37 +0000 Message-ID: <014001c29d3d$26388780$0200000a@tkw> From: "Pete Cordell" To: "Henry Sinnreich" Cc: References: <000101c29c87$b4c96250$ae2a2aa6@hsinnreich2> Subject: Re: [Sip] B2BUA Date: Fri, 6 Dec 2002 14:06:12 -0000 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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I was thinking of this one. Admittedly not as long, but a much wider area. http://flix.flirble.org/demon.html Pete. ----- Original Message ----- From: "Henry Sinnreich" To: "'Pete Cordell'" Cc: Sent: 05 December 2002 17:56 Subject: RE: [Sip] B2BUA > Can you document any _outages_ of the _Internet_? I don't recall any. > > Please provide references. > > Thanks, Henry > > > -----Original Message----- > > From: Pete Cordell [mailto:pete@tech-know-ware.com] > > Sent: Thursday, December 05, 2002 6:25 AM > > To: Henry Sinnreich > > Cc: sip@ietf.org > > Subject: Re: [Sip] B2BUA > > > > > > Henry, > > > > The Internet has had a few famous outages as well. Besides, > > if all the telco traffic was put over IP, with today's level > > of QoS on the Internet, it would have been brought to its knees also. > > > > To say that one is all goodness and light and the other all > > evil doesn't do us as a community any good as when customers > > find out there are problems they tend not to believe anything > > else we say! > > > > Only vapourware is flawless. Most people know that. Respect > > the intelligence of your customer, or they will find somebody > > that does!!! > > > > Pete. > > > > ----- Original Message ----- > > From: "Henry Sinnreich" > > To: "'Phil Reynolds'" ; > > Sent: 04 December 2002 19:02 > > Subject: RE: [Sip] B2BUA > > > > > > > >The telecoms people are clever enough to have thought > > > >about that and build redundancy, fault tolerance and failover into > > > their switches. > > > > > > This has proven unfortunately not to be the case on > > September 11 when > > > telecom service failed for days, while Internet traffic continued > > > smoothly. I suggest you to look at the central control model of the > > > switch network versus the e2e architecture of the Internet. SIP > > > enabled networks are also fully distributed and the e2e control > > > principle maintained - that's why state in placed in SIP endpoints. > > > > > > I am not sure if a few words here can give full justice to the > > > superior resilience of the Internet and to SIP enabled services,... > > > > > > Thanks, Henry > > > > > > -----Original Message----- > > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > > Behalf Of Phil > > > Reynolds > > > Sent: Wednesday, December 04, 2002 7:37 AM > > > To: sip@ietf.org > > > Subject: RE: [Sip] B2BUA > > > > > > > > > If a telephone switch crashes you loose all calls... The telecoms > > > people are clever enough to have thought about that and build > > > redundancy, fault tolerance and failover into their switches. Maybe > > > some of us IP-telecoms people have thought of similar > > techniques for > > > SIP intermediaries? -----Original Message----- > > > From: Jiri Kuthan [mailto:jiri.kuthan@fokus.fraunhofer.de] > > > Sent: 04 December 2002 12:32 > > > To: Christian Huitema; Roy, Radhika R, ALASO; > > mbarnes@nortelnetworks.com > > > > > > Cc: dean.willis@softarmor.com; Juan-Carlos.Rojas@alcatel.fr; > > > sip@ietf.org > > > Subject: RE: [Sip] B2BUA > > > [...snip...] > > > I think there are more issues with B2BUA. A B2BUA's failure affects > > > all current calls :-( -Jiri > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Fri Dec 6 10:36:03 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10635 for ; Fri, 6 Dec 2002 10:36:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB6FcRc00311 for sip-archive@odin.ietf.org; Fri, 6 Dec 2002 10:38:27 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB6Fbmv32604; Fri, 6 Dec 2002 10:37:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB6FZpv31829 for ; Fri, 6 Dec 2002 10:35:51 -0500 Received: from gadolinium.btinternet.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10428 for ; Fri, 6 Dec 2002 10:32:55 -0500 (EST) Received: from host213-122-57-72.in-addr.btopenworld.com ([213.122.57.72] helo=tkw) by gadolinium.btinternet.com with smtp (Exim 3.22 #16) id 18KKVx-00051f-00; Fri, 06 Dec 2002 15:35:42 +0000 Message-ID: <014201c29d3d$28d7ea80$0200000a@tkw> From: "Pete Cordell" To: "Jonathan Rosenberg" Cc: References: <013d01c29c5d$e4a7f7e0$0200000a@tkw> <3DEF7EAB.2070109@dynamicsoft.com> <009801c29c83$985129e0$0200000a@tkw> <3DF04799.7010208@dynamicsoft.com> Subject: Re: [Sip] B2BUA - Security - (Midcom Reqts?) Date: Fri, 6 Dec 2002 15:35:04 -0000 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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jonathan, Perhaps as you say, we should take a step back. I want to address midcom scenarios shown in the time line shown in section 7.1. of RFC 3303 (Midcom framework) and 2.3.1 and 2.3.2 in draft-ietf-midcom-scenarios-02.txt. The current security situation in SIP makes this problematic, and I don't think there is any chartered item in SIP or SIPPING to address this. I would like there to be a secure mode of operation even for midcom systems that allows encryption and authentication. I would imagine that the IESG would block midcom if it did not allow such security. I think we know enough from a SIP point of view what a midcom solution will need to do to a SIP system. Therefore, I believe we should start work on this sooner rather than later. Perhaps the way to go is for the midcom group to produce a requirements draft detailing what it needs from the SIP world (in its broadest sense) that can be put into SIPPING and hopefully lead to a chartered item. To me the successful conclusion of midcom seems dependent on this sort of work being done. Pete. ----- Original Message ----- From: "Jonathan Rosenberg" To: "Pete Cordell" Cc: "Christian Huitema" ; Sent: 06 December 2002 06:45 Subject: Re: [Sip] B2BUA - Security > inline as always. But, first, a question. Pete - what are you after? Are > you actually trying to convince the working group to disallow > encryption/authentication over SDP so that your b2bua-thingy can modify > it?? As I have tried to argue in my session policy draft, there are a > LOT of issues with intermediary modification of media information, many > of them related to the kind of things OPES has been dealing with. You > need to consider the problem more broadly. > > > Pete Cordell wrote: > > >>1. modifying SDP in transit to point media streams to an intermediate > >>recording device, allowing attackers to establish wiretaps > > > > > > This is only partially successful. Encryption of RTP is the only complete > > solution. > > True. > > > > > > >>2. downgrading any SRTP keying done in SDP, so that the media itself is > >>not encrypted or integrity protected (this came up during the mmusic > >>session in IETF as a driver for S/MIME) > > > > > > I don't think you need to encrypt the entire SDP body to prevent key > > downgrading. In the absence of any other contraints that might be a simple > > route to go, but if it causes problems (as it is) then we should look at > > other ways. > > You need to protect the key exchanges. I am trying to establish that a > lot of the information in SDP needs to be protected e2e. > > > > > As an aside - This is the sort of reason I would like to get this sort of > > thing on the agenda. It's not that its not possible to enable SIP to meet > > these requirements, there's just not a desire to do among the core SIP > > people. I know why they don't want to do it, but I also think that SIP > > fails to address a whole class of problem as a result. In the long run I > > think that will be detrimental to SIP. > > I have no idea what "it" is in this aside. > > > > > > >>3. launching a DoS attack by sending everyones voice traffic to the > >>intended target. You get huge amplification gains here. Very appealing > >>for hackers! > > > > > > Don't need SDP to do that. I could just rip out the entire SDP and put in a > > new version. I might not get the ports right, but I could probably cause > > enough damage to get my kicks. > > If you rip it out and replace it, and the UA is requiring signed SDP, > then this won't work. > > Another interesting attack I thought of, is to modify the SDP to send > the RTP to a relay, which does forward it to the right destination, but > only after inserting 100ms of delay. The result is that the conversation > takes place, but at lousy quality. Why do this? Maybe a way for one > provider to convince customers of another provider to switch. Dropping > the packets outright might be too overt of an attack, but a subtle > increase in delays... just a thought. > > >>Confidentiality is only one property of security. I am much more > >>concerned about message integrity. > > > > > > Integrity of which bits? And are you sure that maintaining integrity buys > > you anything except for in a few special cases? > > Definitely. > > I don't want someone removing my video stream my session. > I don't want someone to modify my codecs, forcing me to use a lower > quality one when a better one would actually work. > I don't want someone to receive my media when I intended it for the > party I called. > > And so on. The above concerns are real, and cover a good set of the > information in SDP. > > Let me pose the question in reverse. What information in SDP do you feel > is NOT worth protecting? > > -Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.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 mailnull@www1.ietf.org Fri Dec 6 10:39:09 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10887 for ; Fri, 6 Dec 2002 10:39:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB6FfXJ00496 for sip-archive@odin.ietf.org; Fri, 6 Dec 2002 10:41:33 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB6Ff8v00473; Fri, 6 Dec 2002 10:41:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB6FeWv00449 for ; Fri, 6 Dec 2002 10:40:32 -0500 Received: from zsc3s004.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10732 for ; Fri, 6 Dec 2002 10:37:36 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by zsc3s004.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gB6FeM327657; Fri, 6 Dec 2002 07:40:22 -0800 (PST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gB6FeX701103; Fri, 6 Dec 2002 09:40:34 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 6 Dec 2002 09:40:20 -0600 Message-ID: <1B54FA3A2709D51195C800508BF9386A05A7CB43@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'Jonathan Rosenberg'" , Pete Cordell Cc: "David R. Oran" , Dean Willis , sip@ietf.org Subject: RE: [Sip] B2BUA & Max-Forwards Date: Fri, 6 Dec 2002 09:40:17 -0600 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , I agree with Jonathan. As mentioned earlier this week apparently, there is already work underway by some individuals to write an informational draft documenting BBUA scenarios/call flows. I'll keep my fingers crossed that the existence of such a document can save us from another round of B2BUA discussions again in 3 months. Regards, Mary. -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Friday, December 06, 2002 12:59 AM To: Pete Cordell Cc: David R. Oran; Dean Willis; sip@ietf.org Subject: Re: [Sip] B2BUA & Max-Forwards Pete Cordell wrote: > Dave, > > To save your disagreeableness, can we say something like: > > "A B2BUA MUST perform loop prevention. One way to do this is to propagate > the Max-Forwards header from the incoming request to the outgoing request in > the same way that a proxy does." A statement like this is completely out of scope for rfc3261. It might be a reasonable statement to make in some kind of application document that describes a particular type of b2bua. However, it makes no more sense to say this in RFC 3261 as it would be to discuss the ways in which to build a focus or a 3pcc controller (both of which are also informational, by the way). I can't resist pointing out that much of this is deja vu. Folks may recall heated discussions in Adelaide, where there was a bof (I think) that wanted to have a working group to specify SIP to H.323 conversion. THe same arguemtns that were made there are being made here; its an application level issue, there are many ways to do it, don't stifle creativity, etc. In fact I recall that Dave was, as always, quite vociferous on these points. The eventual conclusion in the h323/sip conversion case was to write an INFORMATIONAL RFC that documents reasonable practices in building such a device. I believe the same logic and conclusions apply here. If folks have a particular type of b2bua application they are fond of, please feel free to write up your implementation advice and I am sure sipping would consider whether or not it would make a useful informational RFC. However, it is completely inappropriate to ever make such application logic normative, and even more inappropraite for such wording to be in rfc3261. Anyway, I too am tired of this thread. I think, in fact, there is "rough" consensus to remove the definition of b2bua entirely from rfc3261 in its next revision (which is quite some time in the future anyway). However, I'll let the chairs decide that. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.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 mailnull@www1.ietf.org Fri Dec 6 10:45:24 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11145 for ; Fri, 6 Dec 2002 10:45:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB6Flnb00840 for sip-archive@odin.ietf.org; Fri, 6 Dec 2002 10:47:49 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB6Fbqv32623; Fri, 6 Dec 2002 10:37:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB6FZqv31833 for ; Fri, 6 Dec 2002 10:35:52 -0500 Received: from gadolinium.btinternet.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10435 for ; Fri, 6 Dec 2002 10:32:57 -0500 (EST) Received: from host213-122-57-72.in-addr.btopenworld.com ([213.122.57.72] helo=tkw) by gadolinium.btinternet.com with smtp (Exim 3.22 #16) id 18KKVr-00051f-00; Fri, 06 Dec 2002 15:35:36 +0000 Message-ID: <013f01c29d3d$257844c0$0200000a@tkw> From: "Pete Cordell" To: "David Oran" , "Gordon Ledgard" , "Dean Willis" , References: <1A69639B9B6AD511812B00B0D0DE19F60A3935@commserver.erictest.com> <25423627.1039101387@ORANLT.cisco.com> Subject: Re: [Sip] B2BUA & Max-Forwards Date: Fri, 6 Dec 2002 13:45:27 -0000 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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "David Oran" ... much deleted ... > >> Question: is this application a B2BUA and hence required to have a > >> Max-Forwards value in the request whose value is strictly > >> less than the > >> value received in the SIP request? Beats me. > > > > Only if that's the way it wants to do it. You can defeat > > the loops howsoever you want. > > > Ok, then how about the following wording: "a B2BUA MUST prevent loops and > it MUST NOT behave in such as way as to cause broadcast storms, or > contribute to any exponential message explosion of SIP or any other > messages. Preventing loops will help with this. But more helpfully, the text used to describe proxies in this respect might be useful guidance on how far to go. > In addition, it MUST comply will all local and national fire > codes, including the Underwriter's Laboratory flaming oil test*. Doesn't seem a SIP issue, but if you think its helpful from a SIP point of view... Pete _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Fri Dec 6 17:22:39 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27482 for ; Fri, 6 Dec 2002 17:22:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB6MP7s25760 for sip-archive@odin.ietf.org; Fri, 6 Dec 2002 17:25:07 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB6MLAv25593; Fri, 6 Dec 2002 17:21:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB6MJTv25496 for ; Fri, 6 Dec 2002 17:19:29 -0500 Received: from gamma.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27302; Fri, 6 Dec 2002 17:16:28 -0500 (EST) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id gB6MJKD23830; Fri, 6 Dec 2002 14:19:20 -0800 (PST) Message-Id: <200212062219.gB6MJKD23830@gamma.isi.edu> To: IETF-Announce: ; Cc: rfc-editor@rfc-editor.org, sip@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Fri, 06 Dec 2002 14:19:20 -0800 Subject: [Sip] RFC 3428 on Session Initiation Protocol (SIP) Extension for Instant Messaging Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3428 Title: Session Initiation Protocol (SIP) Extension for Instant Messaging Author(s): B. Campbell, Ed., J. Rosenberg, H. Schulzrinne, C. Huitema, D. Gurle Status: Standards Track Date: December 2002 Mailbox: bcampbell@dynamicsoft.com, jdrosen@dynamicsoft.com, schulzrinne@cs.columbia.edu, huitema@microsoft.com, dgurle@microsoft.com Pages: 18 Characters: 41475 Updates/Obsoletes:SeeAlso: None I-D Tag: draft-ietf-sip-message-07.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3428.txt Instant Messaging (IM) refers to the transfer of messages between users in near real-time. These messages are usually, but not required to be, short. IMs are often used in a conversational mode, that is, the transfer of messages back and forth is fast enough for participants to maintain an interactive conversation. This document proposes the MESSAGE method, an extension to the Session Initiation Protocol (SIP) that allows the transfer of Instant Messages. Since the MESSAGE request is an extension to SIP, it inherits all the request routing and security features of that protocol. MESSAGE requests carry the content in the form of MIME body parts. MESSAGE requests do not themselves initiate a SIP dialog; under normal usage each Instant Message stands alone, much like pager messages. MESSAGE requests may be sent in the context of a dialog initiated by some other SIP request. 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.echo 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: <021206141712.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3428 --OtherAccess Content-Type: Message/External-body; name="rfc3428.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <021206141712.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Fri Dec 6 17:35:46 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28125 for ; Fri, 6 Dec 2002 17:35:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB6McEV26897 for sip-archive@odin.ietf.org; Fri, 6 Dec 2002 17:38:14 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB6MP8v25774; Fri, 6 Dec 2002 17:25:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB6MOZv25721 for ; Fri, 6 Dec 2002 17:24:35 -0500 Received: from gamma.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27449; Fri, 6 Dec 2002 17:21:27 -0500 (EST) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id gB6MOID26451; Fri, 6 Dec 2002 14:24:18 -0800 (PST) Message-Id: <200212062224.gB6MOID26451@gamma.isi.edu> To: IETF-Announce: ; Cc: rfc-editor@rfc-editor.org, sip@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Fri, 06 Dec 2002 14:24:18 -0800 Subject: [Sip] RFC 3326 on The Reason Header Field for the Session Initiation Protocol (SIP) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3326 Title: The Reason Header Field for the Session Initiation Protocol (SIP) Author(s): H. Schulzrinne, D. Oran, G. Camarillo Status: Standards Track Date: December 2002 Mailbox: schulzrinne@cs.columbia.edu, oran@cisco.com, Gonzalo.Camarillo@ericsson.com Pages: 8 Characters: 15695 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-sip-reason-01.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3326.txt For creating services, it is often useful to know why a Session Initiation Protocol (SIP) request was issued. This document defines a header field, Reason, that provides this information. The Reason header field is also intended to be used to encapsulate a final status code in a provisional response. This functionality is needed to resolve the "Heterogeneous Error Response Forking Problem", or HERFP. This document is a product of the Session Initiation Protocol and the Session Initiation Proposal Investigation Working Groups 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.echo 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: <021206142158.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3326 --OtherAccess Content-Type: Message/External-body; name="rfc3326.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <021206142158.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Fri Dec 6 18:26:28 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00251 for ; Fri, 6 Dec 2002 18:26:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB6NSvC29746 for sip-archive@odin.ietf.org; Fri, 6 Dec 2002 18:28:57 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB6NRav29648; Fri, 6 Dec 2002 18:27:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB6NQrv29602 for ; Fri, 6 Dec 2002 18:26:53 -0500 Received: from willow.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00083 for ; Fri, 6 Dec 2002 18:23:53 -0500 (EST) Received: from cypress.neustar.com (stih650a-eth-s1p2c0.va.neustar.com [209.173.53.81]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id gB6NQii20845; Fri, 6 Dec 2002 23:26:44 GMT Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by cypress.neustar.com (8.11.6/8.11.6) with ESMTP id gB6NQSx11685; Fri, 6 Dec 2002 23:26:28 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Fri, 6 Dec 2002 18:28:00 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA815EB474@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Pete Cordell'" , Jonathan Rosenberg Cc: sip@ietf.org Subject: RE: [Sip] B2BUA - Security - (Midcom Reqts?) Date: Fri, 6 Dec 2002 18:27:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , My favorite property of S/MIME protection for SDP is middlebox detection. I'd like to know if some putatively benevolent middlebox is attempting to 'help' my session media get where it needs to go. Although the midcom working group may favor middlebox transparency, I do not believe that should be a goal of this working group. SIP is a peer-to-peer protocol. While applications of SIP are free not to apply security properties to SDP if they wish, I think it is unarguably valid for a SIP user agent to secure SDP, even if that runs the risk of troubling middleboxes. In any event, there already is a secure way to allow encryption and authentication via middleboxes - you can apply security properties to the SDP using a certificate held by the middlebox (or its controller as the case may be). If you actually intend for the middlebox to be in the path of your media, this seems like a reasonable solution. I don't think we need anything more. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Pete Cordell [mailto:pete@tech-know-ware.com] > Sent: Friday, December 06, 2002 7:35 AM > To: Jonathan Rosenberg > Cc: sip@ietf.org > Subject: Re: [Sip] B2BUA - Security - (Midcom Reqts?) > > > Jonathan, > > Perhaps as you say, we should take a step back. > > I want to address midcom scenarios shown in the time line shown in section > 7.1. of RFC 3303 (Midcom framework) and 2.3.1 and 2.3.2 in > draft-ietf-midcom-scenarios-02.txt. > > The current security situation in SIP makes this problematic, and I don't > think there is any chartered item in SIP or SIPPING to address this. > > I would like there to be a secure mode of operation even for midcom systems > that allows encryption and authentication. I would imagine that the IESG > would block midcom if it did not allow such security. > > I think we know enough from a SIP point of view what a midcom solution will > need to do to a SIP system. Therefore, I believe we should start work on > this sooner rather than later. > > Perhaps the way to go is for the midcom group to produce a requirements > draft detailing what it needs from the SIP world (in its broadest sense) > that can be put into SIPPING and hopefully lead to a chartered item. > > To me the successful conclusion of midcom seems dependent on this sort of > work being done. > > Pete. > > ----- Original Message ----- > From: "Jonathan Rosenberg" > To: "Pete Cordell" > Cc: "Christian Huitema" ; > > Sent: 06 December 2002 06:45 > Subject: Re: [Sip] B2BUA - Security > > > > inline as always. But, first, a question. Pete - what are > you after? Are > > you actually trying to convince the working group to disallow > > encryption/authentication over SDP so that your > b2bua-thingy can modify > > it?? As I have tried to argue in my session policy draft, > there are a > > LOT of issues with intermediary modification of media > information, many > > of them related to the kind of things OPES has been dealing > with. You > > need to consider the problem more broadly. > > > > > > Pete Cordell wrote: > > > > >>1. modifying SDP in transit to point media streams to an > intermediate > > >>recording device, allowing attackers to establish wiretaps > > > > > > > > > This is only partially successful. Encryption of RTP is the only > complete > > > solution. > > > > True. > > > > > > > > > > >>2. downgrading any SRTP keying done in SDP, so that the > media itself is > > >>not encrypted or integrity protected (this came up during > the mmusic > > >>session in IETF as a driver for S/MIME) > > > > > > > > > I don't think you need to encrypt the entire SDP body to > prevent key > > > downgrading. In the absence of any other contraints that > might be a > simple > > > route to go, but if it causes problems (as it is) then we > should look at > > > other ways. > > > > You need to protect the key exchanges. I am trying to > establish that a > > lot of the information in SDP needs to be protected e2e. > > > > > > > > As an aside - This is the sort of reason I would like to > get this sort > of > > > thing on the agenda. It's not that its not possible to > enable SIP to > meet > > > these requirements, there's just not a desire to do among > the core SIP > > > people. I know why they don't want to do it, but I also > think that SIP > > > fails to address a whole class of problem as a result. > In the long run > I > > > think that will be detrimental to SIP. > > > > I have no idea what "it" is in this aside. > > > > > > > > > > >>3. launching a DoS attack by sending everyones voice > traffic to the > > >>intended target. You get huge amplification gains here. > Very appealing > > >>for hackers! > > > > > > > > > Don't need SDP to do that. I could just rip out the > entire SDP and put > in a > > > new version. I might not get the ports right, but I > could probably > cause > > > enough damage to get my kicks. > > > > If you rip it out and replace it, and the UA is requiring > signed SDP, > > then this won't work. > > > > Another interesting attack I thought of, is to modify the > SDP to send > > the RTP to a relay, which does forward it to the right > destination, but > > only after inserting 100ms of delay. The result is that the > conversation > > takes place, but at lousy quality. Why do this? Maybe a way for one > > provider to convince customers of another provider to > switch. Dropping > > the packets outright might be too overt of an attack, but a subtle > > increase in delays... just a thought. > > > > >>Confidentiality is only one property of security. I am much more > > >>concerned about message integrity. > > > > > > > > > Integrity of which bits? And are you sure that > maintaining integrity > buys > > > you anything except for in a few special cases? > > > > Definitely. > > > > I don't want someone removing my video stream my session. > > I don't want someone to modify my codecs, forcing me to use a lower > > quality one when a better one would actually work. > > I don't want someone to receive my media when I intended it for the > > party I called. > > > > And so on. The above concerns are real, and cover a good set of the > > information in SDP. > > > > Let me pose the question in reverse. What information in > SDP do you feel > > is NOT worth protecting? > > > > -Jonathan R. > > -- > > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.dynamicsoft.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 mailnull@www1.ietf.org Fri Dec 6 18:34:25 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00495 for ; Fri, 6 Dec 2002 18:34:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB6NasR29992 for sip-archive@odin.ietf.org; Fri, 6 Dec 2002 18:36:54 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB6NaIv29981; Fri, 6 Dec 2002 18:36:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB6NZlv29938 for ; Fri, 6 Dec 2002 18:35:47 -0500 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00424 for ; Fri, 6 Dec 2002 18:32:47 -0500 (EST) Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB6NZcFp003700; Fri, 6 Dec 2002 15:35:38 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABK39637; Fri, 6 Dec 2002 15:32:31 -0800 (PST) Date: Fri, 6 Dec 2002 15:35:54 -0800 Subject: Re: [Sip] B2BUA & Max-Forwards Content-Type: multipart/alternative; boundary=Apple-Mail-41-781012764 Mime-Version: 1.0 (Apple Message framework v548) Cc: sip@ietf.org To: Phil Reynolds From: Rohan Mahy In-Reply-To: <00533D13955AD411AF3800A0C9B4263994D884@ridgeway.internal.ridgewaysystems.com> Message-Id: <76BE89A9-0973-11D7-9AE1-0003938AF740@cisco.com> X-Mailer: Apple Mail (2.548) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --Apple-Mail-41-781012764 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Thursday, December 5, 2002, at 01:49 AM, Phil Reynolds wrote: > Our system isn't broken. I would say that this shows that the spec is > broken not our system. That remains to be seen. If I demonstrated how to satisfy the business goal you are trying to solve without violating the spec, then I suspect the spec is just fine. > Our system provides facilities for some (and we hope "most") users. We > don't provide these facilities for all users because: A) We don't > think they are important for most users, B) The spec precludes us from > doing so (e.g. end-to-end security) ... or that you preclude secure customers from using your product. > But because the spec says we MUST do end-to-end security we can't be > sanctioned as compliant, despite the fact that "most" of our users > don't want that. (BTW I have yet to see a endpoint that does > end-to-end security so it appears that these are all broken as well) re: end-to-end, check out the datasheet for: http://www.marconi.com/html/products/virtualpresencesystem.htm likewise I believe Pingtel has an implementation. thanks, -rohan > -----Original Message----- > From: Adam Roach [mailto:adam@dynamicsoft.com] > Sent: 04 December 2002 20:45 > To: 'Phil Reynolds'; sip@ietf.org > Subject: RE: [Sip] B2BUA & Max-Forwards > > > -----Original Message----- > From: Phil Reynolds [mailto:preynolds@ridgewaysystems.com] > > > Now your back to restricting what I can and can't do in an > > intermediary. It can't be a B2BUA 'cos it doesn't need to honour > > require headers (the UA at the other end does that, if they were > meant > > for my intermediary then they would be proxy-require?), and it can't > > be a proxy 'cos of the rules about not changing the body so what is > > it? > > Broken. > > The restrictions placed on nodes by 3261 (which I'm merely > reiterating, not imposing) aren't an authoritarian attempt at > unnecessary proscription. They serve a purpose. > > I'll describe one of the (several) purposes that applies > to the situation you propose. > > One of the things that UAs are required to be able to do is sign > and/or encrypt the bodies and/or some subset of the headers to ensure > confidentiality and/or integrity. The protocol places restrictions on > various nodes to ensure that this can be done. Your box is broken > precisely because it interferes with these abilities (or, more > precisely, these abilities interfere with it). > > /a > --Apple-Mail-41-781012764 Content-Type: text/enriched; charset=US-ASCII Content-Transfer-Encoding: 7bit On Thursday, December 5, 2002, at 01:49 AM, Phil Reynolds wrote: Our system isn't broken. I would say that this shows that the spec is broken not our system. That remains to be seen. If I demonstrated how to satisfy the business goal you are trying to solve without violating the spec, then I suspect the spec is just fine. Our system provides facilities for some (and we hope "most") users. We don't provide these facilities for all users because: A) We don't think they are important for most users, B) The spec precludes us from doing so (e.g. end-to-end security) ... or that you preclude secure customers from using your product. But because the spec says we MUST do end-to-end security we can't be sanctioned as compliant, despite the fact that "most" of our users don't want that. (BTW I have yet to see a endpoint that does end-to-end security so it appears that these are all broken as well) re: end-to-end, check out the datasheet for: http://www.marconi.com/html/products/virtualpresencesystem.htm likewise I believe Pingtel has an implementation. thanks, -rohan -----Original Message----- From: Adam Roach [1999,1999,FFFFmailto:adam@dynamicsoft.com] Sent: 04 December 2002 20:45 To: 'Phil Reynolds'; sip@ietf.org Subject: RE: [Sip] B2BUA & Max-Forwards -----Original Message----- From: Phil Reynolds [1999,1999,FFFFmailto:preynolds@ridgewaysystems.com] > Now your back to restricting what I can and can't do in an > intermediary. It can't be a B2BUA 'cos it doesn't need to honour > require headers (the UA at the other end does that, if they were meant > for my intermediary then they would be proxy-require?), and it can't > be a proxy 'cos of the rules about not changing the body so what is > it? Broken. The restrictions placed on nodes by 3261 (which I'm merely reiterating, not imposing) aren't an authoritarian attempt at unnecessary proscription. They serve a purpose. I'll describe one of the (several) purposes that applies to the situation you propose. One of the things that UAs are required to be able to do is sign and/or encrypt the bodies and/or some subset of the headers to ensure confidentiality and/or integrity. The protocol places restrictions on various nodes to ensure that this can be done. Your box is broken precisely because it interferes with these abilities (or, more precisely, these abilities interfere with it). /a --Apple-Mail-41-781012764-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Fri Dec 6 19:06:43 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01780 for ; Fri, 6 Dec 2002 19:06:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB709C032273 for sip-archive@odin.ietf.org; Fri, 6 Dec 2002 19:09:12 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB704Pv31495; Fri, 6 Dec 2002 19:04:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB7032v31452 for ; Fri, 6 Dec 2002 19:03:02 -0500 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01555 for ; Fri, 6 Dec 2002 19:00:01 -0500 (EST) Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id gB702ofm019418; Fri, 6 Dec 2002 16:02:50 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABK39927; Fri, 6 Dec 2002 15:59:44 -0800 (PST) Date: Fri, 6 Dec 2002 16:03:07 -0800 Subject: Re: [Sip] B2BUA & Max-Forwards Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: , To: Juan-Carlos.Rojas@alcatel.fr From: Rohan Mahy In-Reply-To: Message-Id: <43F2F3A7-0977-11D7-9AE1-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Thursday, December 5, 2002, at 11:35 PM, Juan-Carlos.Rojas@alcatel.fr wrote: > > Hello, > > "I don't get this. Does two or more mean, for example, four?" > Two or more means exactly that: two or more. The exact number depends > on > what the application is actually providing, and you cannot fixe it in > advance. think "starfish" thx, -r > "but a pair of UAC/UAS concatenations" > OK, I get your point, you are thinking on a specific class of > application > for bi-party communications. But this is only one case. > > At the end, I start to agree with some other people: > - either we are able to provide a definition of a B2BUA independently > of > what the B2BUA is actually doing > - or we drop the definition > > Best regards > Juan Carlos > > > > > > on 05/12/2002 19:54:26 > > To: Juan-Carlos ROJAS/FR/ALCATEL@ALCATEL > cc: > Subject: RE: [Sip] B2BUA & Max-Forwards > > > Hi, > > inline. > >> "I am at the point where I agree with the sentiment raised by others, >> that we should remove the term b2bua entirely from the >> specification. It >> has caused more confusion than anything else." >> >> Yes, this is one possibility. An alternative (as I proposed >> in an earlier >> mail) is to complete the current definition in 3261 saying >> explicitly that >> : >> 1) A B2BUA handles two or more UAs, each one behaving as UAC/UAS, as >> described in 3261 for UAs > > I don't get this. Does two or more mean, for example, four? And does > that > in turn make it a B2BB2BUA? ;) > > The only minor clarification I think might be in order for RFC3261 is > that > it's not just a UAC/UAS concatenation, but a pair of UAC/UAS > concatenations. > > However, the fact that the traffic in this thread alone equals to a > year's > worth of emails on the SIMPLE list suggests that no clarification is > enough > clarification. > > So I agree with the other people in that getting rid of the definition > altogether is the best option. After all, if it looks like a UA to the > outside world, it must be a UA. > >> 2) The SIP protocol specification does not mandate for any >> behaviour of >> such B2BUA, i.e. on how to "link" (or "concatenate") two or more UAs. > > Yes, probably the reason why the definition for a B2BUA is also > useless. > > Cheers, > Aki > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Fri Dec 6 19:18:40 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02564 for ; Fri, 6 Dec 2002 19:18:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB70LAc32693 for sip-archive@odin.ietf.org; Fri, 6 Dec 2002 19:21:10 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB70JCv32617; Fri, 6 Dec 2002 19:19:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB70Imv32595 for ; Fri, 6 Dec 2002 19:18:48 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02503 for ; Fri, 6 Dec 2002 19:15:47 -0500 (EST) Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id gB70IJjS012629; Fri, 6 Dec 2002 16:18:19 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABK40099; Fri, 6 Dec 2002 16:15:32 -0800 (PST) Date: Fri, 6 Dec 2002 16:18:55 -0800 Subject: Re: AW: [Sip] B2BUA Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: "'Pete Cordell'" , Henry Sinnreich , sip@ietf.org To: Liebhart Rainer From: Rohan Mahy In-Reply-To: <1D82815C322BD41196EA00508B951F7B067A4B2C@MCHH265E> Message-Id: <78EFD3FC-0979-11D7-9AE1-0003938AF740@cisco.com> X-Mailer: Apple Mail (2.548) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gB70Imv32596 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Folks, Let's please leave this flame war for the IEPREP mailing list, ok ;-) thanks, -rohan On Thursday, December 5, 2002, at 05:45 AM, Liebhart Rainer wrote: > Henry, > > unfortunately you are comparing apples and pears when stating that the > telecom service failed for days after Sept 11, while Internet traffic > continued smoothly. The mentioned "telefon service" consists of > thousands of (real-time) calls to emergency centres while the Internet > traffic consists mainly of requests to the Web pages of CNN and others > (with bad response times) to retrieve *information* on the status of > the catastrophe. > > Rainer > > > -----Ursprüngliche Nachricht----- > Von: Pete Cordell [mailto:pete@tech-know-ware.com] > Gesendet: Donnerstag, 5. Dezember 2002 13:25 > An: Henry Sinnreich > Cc: sip@ietf.org > Betreff: Re: [Sip] B2BUA > > > Henry, > > The Internet has had a few famous outages as well. Besides, if all the > telco traffic was put over IP, with today's level of QoS on the > Internet, it > would have been brought to its knees also. > > To say that one is all goodness and light and the other all evil > doesn't do > us as a community any good as when customers find out there are > problems > they tend not to believe anything else we say! > > Only vapourware is flawless. Most people know that. Respect the > intelligence of your customer, or they will find somebody that does!!! > > Pete. > > ----- Original Message ----- > From: "Henry Sinnreich" > To: "'Phil Reynolds'" ; > Sent: 04 December 2002 19:02 > Subject: RE: [Sip] B2BUA > > >>> The telecoms people are clever enough to have thought >>> about that and build redundancy, fault tolerance and failover into >> their switches. >> >> This has proven unfortunately not to be the case on September 11 when >> telecom service failed for days, while Internet traffic continued >> smoothly. I suggest you to look at the central control model of the >> switch network versus the e2e architecture of the Internet. SIP >> enabled >> networks are also fully distributed and the e2e control principle >> maintained - that's why state in placed in SIP endpoints. >> >> I am not sure if a few words here can give full justice to the >> superior >> resilience of the Internet and to SIP enabled services,... >> >> Thanks, Henry >> >> -----Original Message----- >> From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Phil >> Reynolds >> Sent: Wednesday, December 04, 2002 7:37 AM >> To: sip@ietf.org >> Subject: RE: [Sip] B2BUA >> >> >> If a telephone switch crashes you loose all calls... The telecoms >> people are clever enough to have thought about that and build >> redundancy, fault tolerance and failover into their switches. >> Maybe some of us IP-telecoms people have thought of similar techniques >> for SIP intermediaries? >> -----Original Message----- >> From: Jiri Kuthan [mailto:jiri.kuthan@fokus.fraunhofer.de] >> Sent: 04 December 2002 12:32 >> To: Christian Huitema; Roy, Radhika R, ALASO; >> mbarnes@nortelnetworks.com >> >> Cc: dean.willis@softarmor.com; Juan-Carlos.Rojas@alcatel.fr; >> sip@ietf.org >> Subject: RE: [Sip] B2BUA >> [...snip...] >> I think there are more issues with B2BUA. A B2BUA's failure affects >> all >> current calls :-( >> -Jiri >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Fri Dec 6 19:35:06 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03132 for ; Fri, 6 Dec 2002 19:35:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB70bai01465 for sip-archive@odin.ietf.org; Fri, 6 Dec 2002 19:37:36 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB70bCv01217; Fri, 6 Dec 2002 19:37:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB70ahv00757 for ; Fri, 6 Dec 2002 19:36:43 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03050 for ; Fri, 6 Dec 2002 19:33:42 -0500 (EST) Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id gB70ZajS019095; Fri, 6 Dec 2002 16:35:36 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABK40264; Fri, 6 Dec 2002 16:32:49 -0800 (PST) Date: Fri, 6 Dec 2002 16:36:12 -0800 Subject: Re: [Sip] B2BUA - Security Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: "'Jonathan Rosenberg'" , Pete Cordell , Christian Huitema , sip@ietf.org To: "Mahey, Sonit" From: Rohan Mahy In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit In addition to Jonathan's approach to session policy, there is no reason a middlebox controller can't be a proxy if it: 1. opens pinholes referenced in a clear text or integrity protected SDP 2. rejects requests with no readable SDP (the UA could instead include a full SDP, with keying material, encrypted with SMIME, and an abbreviated copy which is only integrity protected). 3. rejects requests which use private addresses, and include in its response an offer with corresponding public addresses. hope this helps. thanks, -rohan On Thursday, December 5, 2002, at 09:14 AM, Mahey, Sonit wrote: > I agree with Jonathan. > > That brings up the question: > Is NAT traversal for encrypted SIP traffic addressed anywhere? > > - sonit > >> -----Original Message----- >> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] >> Sent: Thursday, December 05, 2002 11:28 AM >> To: Pete Cordell >> Cc: Christian Huitema; sip@ietf.org >> Subject: Re: [Sip] B2BUA - Security >> >> >> >> >> Pete Cordell wrote: >> >>> I would say that encrypting and / or integrity checking of SDP alone >>> achieves absolutely no security benefit. >> >> Really?? Wow. I actually think it prevents the most >> devastating attacks >> against SIP. These include: >> >> 1. modifying SDP in transit to point media streams to an intermediate >> recording device, allowing attackers to establish wiretaps >> >> 2. downgrading any SRTP keying done in SDP, so that the media >> itself is >> not encrypted or integrity protected (this came up during the mmusic >> session in IETF as a driver for S/MIME) >> >> 3. launching a DoS attack by sending everyones voice traffic to the >> intended target. You get huge amplification gains here. Very >> appealing >> for hackers! >> >> >> >> >>> >>> SDP really does two things. It specifies transport >> addresses and chosen >>> codecs. >>> >>> Let's assume that you do encrypt the SDP and I can't read it. >>> >>> I can have a good guess at the transport addresses in use >> from many of the >>> other fields in SIP such as via lines, To, From, uri, >> contact, route etc. >> >> Confidentiality is only one property of security. I am much more >> concerned about message integrity. >> >>> (Put another way, encrypting SDP is another form of >> security by obscurity. >>> And we all know what that means.) >> >> I have no idea how you would arrive at such a conclusion. Security >> through obscurity means that information is not cryptographically >> protected, but encoded with a known process that is just a bit >> complicated. By definition, this is not encryption. Perhaps you have >> discovered some new flaws in encryption technology? >> >> -Jonathan R. >> -- >> Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. >> Chief Scientist First Floor >> dynamicsoft East Hanover, NJ 07936 >> jdrosen@dynamicsoft.com FAX: (973) 952-5050 >> http://www.jdrosen.net PHONE: (973) 952-5000 >> http://www.dynamicsoft.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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Fri Dec 6 19:36:01 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03162 for ; Fri, 6 Dec 2002 19:36:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB70cU201518 for sip-archive@odin.ietf.org; Fri, 6 Dec 2002 19:38:30 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB70YYv00604; Fri, 6 Dec 2002 19:34:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB70T4v00418 for ; Fri, 6 Dec 2002 19:29:04 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02766 for ; Fri, 6 Dec 2002 19:26:04 -0500 (EST) Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id gB70SajS016150; Fri, 6 Dec 2002 16:28:36 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABK40190; Fri, 6 Dec 2002 16:25:49 -0800 (PST) Date: Fri, 6 Dec 2002 16:29:13 -0800 Subject: Re: [Sip] B2BUA - Security Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: "David R. Oran" , "Christian Huitema" , To: "Pete Cordell" From: Rohan Mahy In-Reply-To: <009701c29c83$97462280$0200000a@tkw> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Thursday, December 5, 2002, at 09:05 AM, Pete Cordell wrote: > Dave, > > Please see inline... > > Pete. > > ----- Original Message ----- > From: "David R. Oran" > To: "Pete Cordell" ; "Christian Huitema" > > Cc: > Sent: 05 December 2002 14:45 > Subject: Re: [Sip] B2BUA - Security > > >> --On Thursday, December 05, 2002 12:55 PM +0000 Pete Cordell >> wrote: >> >>> Christian, >>> >>> I'm afraid I think that end-to-end security of SDP is a complete red >>> herring. >>> >>> I would say that encrypting and / or integrity checking of SDP alone >>> achieves absolutely no security benefit. >>> >>> SDP really does two things. It specifies transport addresses and >>> chosen >>> codecs. >>> >> ...and carries keys for SRTP...hmmmmmmmm........ > > I assumed the keying used some sort of Diffee-Hellman type technique, > and so > this wouldn't be an issue. I will look into this. Maybe that area of > SDP > usage could be improved. see draft-baugher-mmusic-sdpmediasec-00.txt thx, -r >> >>> Let's assume that you do encrypt the SDP and I can't read it. >>> >>> I can have a good guess at the transport addresses in use from many >>> of > the >>> other fields in SIP such as via lines, To, From, uri, contact, route > etc. >>> >> Uh huh, sure. My experience is that you can only guess with reasonable >> probability by knowing the implementation details of the UAs. I >> remember > we >> changed the RTP port allocation algorithm on IOS and all of a sudden > people >> started screaming because their ACL filters "stopped working". Trying >> to >> beat the devil seem a pretty poor direction. > > Real time ACL control is very different issue to working out which RTP > stream goes with what SIP session at some point. > >> >>> By analysing the RTP traffic, I can easily find out what codec is >>> being >>> used, either because the packet tells me, or from other statistical >>> characteristics. >>> >> Really? Maybe for the standard codecs but why on earth bother? > > Your point is? > >> >>> I have therefore discovered, with very little effort most of what I > would >>> find useful in SDP. (Ironically sending stuff to a media relay would > make >>> this slightly harder!!!) >>> >>> If you want security of the media, then you have to encrypt and > integrity >>> check the RTP. >>> >> or put it through an IPSEC tunnel. What's the point? > > IPSEC would have trouble with NATs etc. The point is to encrypt the > media > some way. I'm not seeing your point. > >> >>> Encrypting SDP simply burns CPU cycles!!! >>> >> No, it prevents media hijacking by a MITM. > > No - not really. It helps in some MITM situations but it is not a > complete > solution. > >> >>> (Put another way, encrypting SDP is another form of security by > obscurity. >>> And we all know what that means.) >>> >> Disagree vociferously. >> >>> (Note that it may make sense to encrypt other bodies types, such as > those >>> that contain HTML, but this is a different case.) >>> >>> Pete. >>> >> Dave. >> >> > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Fri Dec 6 19:49:17 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03566 for ; Fri, 6 Dec 2002 19:49:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB70pkX02204 for sip-archive@odin.ietf.org; Fri, 6 Dec 2002 19:51:46 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB70pIv02178; Fri, 6 Dec 2002 19:51:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB70oYv02153 for ; Fri, 6 Dec 2002 19:50:34 -0500 Received: from bdsl.greycouncil.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03545 for ; Fri, 6 Dec 2002 19:47:33 -0500 (EST) Received: from txdwillis (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.5/8.12.5) with ESMTP id gB70oGUx007109; Fri, 6 Dec 2002 18:50:16 -0600 From: "Dean Willis" To: "'Rohan Mahy'" , "'Phil Reynolds'" Cc: Subject: STOP! RE: [Sip] B2BUA & Max-Forwards Date: Fri, 6 Dec 2002 18:50:12 -0600 Message-ID: <1c7601c29d8a$99b3cba0$fe0c0c42@txdwillis> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_1C77_01C29D58.4F195BA0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <76BE89A9-0973-11D7-9AE1-0003938AF740@cisco.com> Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_1C77_01C29D58.4F195BA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Pardon me while I assert. This thread is non-productive and downloading it is taking forever. I think we have enough input to make any clarifications on B2BUA in bis that I think we're going to be able to make. The IESG has decreed that our specs WILL have provisions for security functions, etc. and that anything that isn't compliant with these provisions is NOT COMPLIANT with the specification. Enough said. If you don't like it, talk to the non-com about changing the IESG or take it up with the iESG. Your can build ANY NON-COMPLIANT SYSTEM YOU WANT TO BUILD. Many such systems will be USEFUL and WIDELY DEPLOYED. But it would be an error to say that any such system is "compliant o RFC ABCD" when that system does not implement something that RFC ABCD lists as MUST IMPLEMENT. So if you have a thing you call a SIP proxy that does not implement MUST IMPLEMENT functions of a SIP proxy as specified in RFC 3261, then it IS NOT, by definition, a fully compliant SIP proxy. Odds are, it's some kind of B2BUA that acts mostly but not quite like a proxy, and that's OK. But DO be advised that anything that is "not a compliant proxy" is likely to have limitations with some kind of service, extension or usage of SIP, and that we're NOT going to worry about that a whole lot in the protocol design. So be prepared to update the widget occasionally if it needs it to continue being useful. Thanks. -- Dean Willis Annoyed Co-Chair, SIP Working Group. ------=_NextPart_000_1C77_01C29D58.4F195BA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Pardon=20 me while I assert.
 
This=20 thread is non-productive and downloading it is taking forever. I think = we have=20 enough input to make any clarifications on B2BUA in bis that I think = we're going=20 to be able to make.
 
The=20 IESG has decreed that our specs WILL have provisions for security = functions,=20 etc. and that anything that isn't compliant with these provisions is NOT = COMPLIANT with the specification. Enough said. If you don't like it, = talk to the=20 non-com about changing the IESG or take it up with the = iESG.
 
Your=20 can build ANY NON-COMPLIANT SYSTEM YOU WANT TO BUILD. Many such systems = will be=20 USEFUL and WIDELY DEPLOYED. But it would be an error to say that any = such system=20 is "compliant  o RFC ABCD" when that system does not implement = something=20 that RFC ABCD lists as MUST IMPLEMENT.
 
So if=20 you have a thing you call a SIP proxy that does not implement MUST = IMPLEMENT=20 functions of a SIP proxy as specified in RFC 3261, then it IS NOT, by=20 definition, a fully compliant SIP proxy. Odds are, it's some kind = of B2BUA=20 that acts mostly but not quite like a proxy, and that's OK. But DO be = advised=20 that anything that is "not a compliant proxy" is likely to have = limitations with=20 some kind of service, extension or usage of SIP, and that we're NOT = going to=20 worry about that a whole lot in the protocol design.  So be = prepared to=20 update the widget occasionally if it needs it to continue being=20 useful.
 
Thanks.
 
--
Dean=20 Willis
Annoyed Co-Chair, SIP Working=20 Group.
 
------=_NextPart_000_1C77_01C29D58.4F195BA0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Fri Dec 6 22:58:36 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07950 for ; Fri, 6 Dec 2002 22:58:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB7417C10187 for sip-archive@odin.ietf.org; Fri, 6 Dec 2002 23:01:07 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB7405v10156; Fri, 6 Dec 2002 23:00:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB73wav10099 for ; Fri, 6 Dec 2002 22:58:36 -0500 Received: from f1ee40-19.idc1.level3.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07923 for ; Fri, 6 Dec 2002 22:55:35 -0500 (EST) Received: from idc1exc0001.corp.global.level3.com (localhost [127.0.0.1]) by f1ee40-19.idc1.level3.com (8.8.8+Sun/8.8.8) with SMTP id DAA17735 for ; Sat, 7 Dec 2002 03:58:26 GMT Received: from idc1exc0004.corp.global.level3.com ([10.1.6.220]) by idc1exc0001.corp.global.level3.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 6 Dec 2002 20:58:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 6 Dec 2002 20:58:25 -0700 Message-ID: <3DB099919328BA41905F651A6EF83976083F88@idc1exc0004.corp.global.level3.com> Thread-Topic: Refer subscription clarification Thread-Index: AcKdpOQKHW0NdQkrEdec0ERFU1RCAA== From: "Hearty, John" To: X-OriginalArrivalTime: 07 Dec 2002 03:58:26.0004 (UTC) FILETIME=[E4E27940:01C29DA4] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gB73wbv10100 Subject: [Sip] Refer subscription clarification Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit The refer-07 draft states: "The lifetime of the state being subscribed to is determined by the progress of the referenced request." If the original dialog that was refered is dropped after the transferee already sent a 202 to the transferor for the Refer, is the subscription still considered alive by the Transferor? Example flow to illustrate what I'm getting at: Transferor Transferee Transfer | | Target | INVITE | | Call-ID:1 |<-------------------| | | 200 OK | | Call-ID:1 |------------------->| | | ACK | | Call-ID:1 |<-------------------| | | INVITE (hold) | | Call-ID:1 |------------------->| | | 200 OK | | Call-ID:1 |<-------------------| | | ACK | | Call-ID:1 |------------------->| | | REFER | | Call-ID:1 |------------------->| | | 202 Accepted | | Call-ID:1 |<-------------------| | | NOTIFY (100 Trying)| | Call-ID:1 |<-------------------| | | 200 OK | | Call-ID:1 |------------------->| | | | INVITE | Call-ID:2 | |------------------->| | | 180 | Call-ID:2 | |<-------------------| | BYE | | Call-ID:1 |<-------------------| | | 200 OK | | Call-ID:1 |------------------->| | | | CANCEL | Call-ID:2 | |------------------->| | | 200 OK | Call-ID:2 | |<-------------------| | | 487 | Call-ID:2 | |<-------------------| | | ACK | Call-ID:2 | |------------------->| Is the Transferee expected to still send a Notify at this point? I presume he is based on the text above, and that the subscription is not over when the Transferor gets the BYE for Call-ID 1. Please confirm. I realize the CANCEL of Call-ID:2 should probabally happen before the BYE on Call-ID:1, I have reasons I'd rather not go into why it is happening in the order shown. Posted to the sip list because I could not find any clear reference to this, and clarification may be needed in the draft. John Hearty Level 3 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Sat Dec 7 10:52:08 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00430 for ; Sat, 7 Dec 2002 10:52:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB7FsWE18994 for sip-archive@odin.ietf.org; Sat, 7 Dec 2002 10:54:32 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB7Fovv18888; Sat, 7 Dec 2002 10:50:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB7FnMv18836 for ; Sat, 7 Dec 2002 10:49:22 -0500 Received: from dyn-tx-arch-crash.dfw.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00323 for ; Sat, 7 Dec 2002 10:46:26 -0500 (EST) Received: from RjS.localdomain (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id gB7Fn4I17639; Sat, 7 Dec 2002 09:49:06 -0600 Subject: Re: [Sip] Refer subscription clarification From: Robert Sparks To: "Hearty, John" Cc: sip@ietf.org In-Reply-To: <3DB099919328BA41905F651A6EF83976083F88@idc1exc0004.corp.global.level3.com> References: <3DB099919328BA41905F651A6EF83976083F88@idc1exc0004.corp.global.level3.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 07 Dec 2002 09:47:49 -0600 Message-Id: <1039276072.984.13.camel@RjS.localdomain> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit inline On Fri, 2002-12-06 at 21:58, Hearty, John wrote: > The refer-07 draft states: > > "The lifetime of the state being subscribed to is determined by the progress of the referenced request." > > If the original dialog that was refered is dropped after the transferee already sent a 202 to the transferor for the Refer, is the subscription still considered alive by the Transferor? Example flow to illustrate what I'm getting at: I dont know what "the original dialog that was refered" means. I am assuming from the flow that you are asking this question. If I send a REFER inside a dialog created by an INVITE, does a BYE terminate the subscription? which is exactly the same question as If I send a SUBSCRIBE inside a dialog created by an INVITE, does a BYE terminate the subscription? If that's not your question ask again. The answer to the above question is no - and the answer to your below question is yes, a NOTIFY is still expected. If that was your question, then I don't think _this_ draft needs further clarification. That's a basic use of sip-events question, as we've discussed on the list many times, and should be clarified there. RjS > > Transferor Transferee Transfer > | | Target > | INVITE | | > Call-ID:1 |<-------------------| | > | 200 OK | | > Call-ID:1 |------------------->| | > | ACK | | > Call-ID:1 |<-------------------| | > | INVITE (hold) | | > Call-ID:1 |------------------->| | > | 200 OK | | > Call-ID:1 |<-------------------| | > | ACK | | > Call-ID:1 |------------------->| | > | REFER | | > Call-ID:1 |------------------->| | > | 202 Accepted | | > Call-ID:1 |<-------------------| | > | NOTIFY (100 Trying)| | > Call-ID:1 |<-------------------| | > | 200 OK | | > Call-ID:1 |------------------->| | > | | INVITE | > Call-ID:2 | |------------------->| > | | 180 | > Call-ID:2 | |<-------------------| > | BYE | | > Call-ID:1 |<-------------------| | > | 200 OK | | > Call-ID:1 |------------------->| | > | | CANCEL | > Call-ID:2 | |------------------->| > | | 200 OK | > Call-ID:2 | |<-------------------| > | | 487 | > Call-ID:2 | |<-------------------| > | | ACK | > Call-ID:2 | |------------------->| > > Is the Transferee expected to still send a Notify at this point? I presume he is based on the text above, and that the subscription is not over when the Transferor gets the BYE for Call-ID 1. Please confirm. I realize the CANCEL of Call-ID:2 should probabally happen before the BYE on Call-ID:1, I have reasons I'd rather not go into why it is happening in the order shown. Posted to the sip list because I could not find any clear reference to this, and clarification may be needed in the draft. > > > John Hearty > Level 3 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Mon Dec 9 02:25:05 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00267 for ; Mon, 9 Dec 2002 02:25:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB97Rc113873 for sip-archive@odin.ietf.org; Mon, 9 Dec 2002 02:27:38 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB97NVv13710; Mon, 9 Dec 2002 02:23:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB97GNv12885 for ; Mon, 9 Dec 2002 02:16:23 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28728 for ; Mon, 9 Dec 2002 02:13:18 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gB97GBQ1009877; Mon, 9 Dec 2002 08:16:11 +0100 (MET) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id YCDZY093; Mon, 9 Dec 2002 08:16:11 +0100 Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.68]) by hendrix.lmf.ericsson.se (8.12.6/8.12.6/lmf-2.1-jcs) with ESMTP id gB97GBu4015990; Mon, 9 Dec 2002 09:16:11 +0200 (EET) Message-ID: <3DF4433B.B180D38@lmf.ericsson.se> Date: Mon, 09 Dec 2002 09:16:11 +0200 X-Sybari-Trust: 9a9790c8 ca231590 64e43b73 00000138 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: sip@ietf.org Subject: Re: [Sip] ABNF issue References: <3DEF27BE.80ED31E2@lmf.ericsson.se> <3DEF7F8D.70902@dynamicsoft.com> <3DEFCF15.3C381C9F@lmf.ericsson.se> <3DF03D40.2030608@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, > >The body does not start with LWS. The body starts with WSP (RFC3261 doesn't > >define what WSP is, but if I remember correct it is SP or TAB). So, in that > >case you will have: > > > >CRLF CRLF WSP > > > >...which, according to the ABNF is: > > > >CRLF LWS > > You are taking this out of context. It is not the case that you would > parse through the message replaceing all instances of CRLF WSP with LWS. So, where in the rules is it said when I should do that, and when I should not? To my understanding the LWS rule is defined as a "general rule". > The BNF specifies that message-header ends with a CRLF. Yes. > What follows that is one of two things - either another CRLF, marking the end > of the > headers, or another message header, which never begins with LWS. From a SIP grammar point of view that is correct. However, I don't see it said anywhere that the definition of LWS isn't valid at the beginning of a new line. Also, just for the record, where is it said that a sip-header can't start with LWS? Where is it said that line folding can't be used at the beginning of a line? The text only says that the sip-header field values can be folded onto multiple lines. > Thus, if a CRLF is followed by something OTHER than WSP, the next construction > cannot be LWS. Maybe I missunderstand you, but the case I try to describe is when the CRLF IS followed by WSP. Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Mon Dec 9 04:14:59 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02772 for ; Mon, 9 Dec 2002 04:14:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB99HWc20349 for sip-archive@odin.ietf.org; Mon, 9 Dec 2002 04:17:32 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB99Dlv20224; Mon, 9 Dec 2002 04:13:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB99CPv20109 for ; Mon, 9 Dec 2002 04:12:25 -0500 Received: from david.sae.siemens.com.sg (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02586 for ; Mon, 9 Dec 2002 04:09:19 -0500 (EST) X-Envelope-Sender-Is: kokjeng.loh@siemens.com (at relayer david.sae.siemens.com.sg) Received: from mail.sae.siemens.com.sg (mail.sae.siemens.com.sg [194.138.237.14]) by david.sae.siemens.com.sg (8.11.6/8.11.6) with ESMTP id gB999Dl25447 for ; Mon, 9 Dec 2002 17:09:13 +0800 (SGT) Message-ID: <7319EDDDE0CD7C458023FF64886CB177030E3479@sgpk001a.sae.siemens.com.sg> From: Loh Kok Jeng To: sip@ietf.org Date: Mon, 9 Dec 2002 17:03:53 +0800 Subject: [Sip] Handling of REFER/NOTIFY by Stateful Proxy Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Dear all, I have a question regarding the handling of REFER/NOTIFY that is tied to a session initiated with INVITE, i.e. REFER/NOTIFY belongs to the same dialog as INVITE. What should a stateful proxy do when it receives a NOTIFY whose dialog has been terminated? I have 2 specific scenarios in mind, and both of them are illustrated in the diagrams below. Case 1: The Referrer terminates the session with BYE. The stateful proxy receives NOTIFY after 200 OK for BYE. At that particular instance, the stateful proxy has already removed the dialog. Case 2: The session expires and the stateful proxy removed the session. It receives NOTIFY from UAS. For these two cases, should the stateful proxy rejects NOTIFY with 481? Or should it proxy NOTIFY onwards? Thanks. regards, KJ Loh +--------+ +--------+ +--------+ |Referrer| |Stateful| | UAS | | | | Proxy | | | +--------+ 1 INVITE +--------+ +--------+ |------------------------->| 2 INVITE | | |------------------------->| | | 3 200 OK | | |<-------------------------| | 4 200 OK | | |<-------------------------| | | 5 REFER | | |------------------------->| 6 REFER | | |------------------------->| | | 7 200 OK | | |<-------------------------| | 8 200 OK | | |<-------------------------| | | | 9 NOTIFY | | |<-------------------------| | 10 NOTIFY | | |<-------------------------| | | 11 200 OK | | |------------------------->| 12 200 OK | | |------------------------->| | ....... | ...... | | | | | 13 REFER | | |------------------------->| 14 REFER | | |------------------------->| | | 15 200 OK | | |<-------------------------| | 16 200 OK | | |<-------------------------| | | 17 BYE | | |------------------------->| 18 BYE | | |------------------------->| | | 19 200 OK | | |<-------------------------| | 21 200 OK | 20 NOTIFY | |<-------------------------|<-------------------------| +--------+ +--------+ +--------+ |Referrer| |Stateful| | UAS | | | | Proxy | | | +--------+ 1 INVITE +--------+ +--------+ |------------------------->| 2 INVITE | | |------------------------->| | | 3 200 OK | | |<-------------------------| | 4 200 OK | | |<-------------------------| | | 5 REFER | | |------------------------->| 6 REFER | | |------------------------->| | | 7 200 OK | | |<-------------------------| | 8 200 OK | | |<-------------------------| | | | 9 NOTIFY | | |<-------------------------| | 10 NOTIFY | | |<-------------------------| | | 11 200 OK | | |------------------------->| 12 200 OK | | |------------------------->| | ....... | ...... | | | | | 13 REFER | | |------------------------->| 14 REFER | | |------------------------->| | | 15 200 OK | | |<-------------------------| | 16 200 OK | | |<-------------------------| | | +-----------------+ | | |Session Timeout | | | |Session torn down| | | +-----------------+ | | | 17 NOTIFY | | |<-------------------------| _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Mon Dec 9 05:16:57 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03833 for ; Mon, 9 Dec 2002 05:16:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB9AJKW23424 for sip-archive@odin.ietf.org; Mon, 9 Dec 2002 05:19:20 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB9AFTv23312; Mon, 9 Dec 2002 05:15:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB9ADnv23226 for ; Mon, 9 Dec 2002 05:13:49 -0500 Received: from znsgs01r.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03741 for ; Mon, 9 Dec 2002 05:10:53 -0500 (EST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.160.46.124]) by znsgs01r.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gB9ACEV00198; Mon, 9 Dec 2002 10:12:14 GMT Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 9 Dec 2002 10:12:14 -0000 Message-ID: From: "Mark Watson" To: "'Rohan Mahy'" , "Mahey, Sonit" Cc: "'Jonathan Rosenberg'" , Pete Cordell , Christian Huitema , sip@ietf.org Subject: RE: [Sip] B2BUA - Security Date: Mon, 9 Dec 2002 10:12:13 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C29F6B.7129FF50" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , 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_01C29F6B.7129FF50 Content-Type: text/plain; charset="iso-8859-1" Rohan wrote: > In addition to Jonathan's approach to session policy, there is no > reason a middlebox controller can't be a proxy if it: > > 1. opens pinholes referenced in a clear text or integrity > protected SDP > 2. rejects requests with no readable SDP (the UA could > instead include > a full SDP, with keying material, encrypted with SMIME, ****and an > abbreviated copy which is only integrity protected****). I was about to write a draft suggesting exactly this. As per Jonathan's draft there is a need for the UA to be able to 'declare' to network entities those parts of the SDP information which are needed for the network entity to perform whatever service it performs (e.g. NAT or Firewall control). But the UA should not have to declare the whole SDP, and the terminating UA should be able to tell if a network entity has modified these parameters. Rather than putting this information into new SIP headers, we could include two copies of the SDP. One copy is unprotected and contains only the information that the UE wishes to 'declare' to the network entities. The other copy is protected and contains the full information. This approach would work through existing devices which inspect/modify SDP. I'm not sure how an existing S/MIME compliant client would behave on receiving these two copies. If it uses the unprotected SDP, then things are no worse than the present situation - the call suceeds, but without the advantages of S/MIME. If it uses the protected SDP (which has not been modified by the NAT controlling device), then the call fails, but this is still no worse than the present situation. I guess if people liked this approach we would need to document somewhere the UAS behaviour, namely: compare protected & unprotected copies & take 'appropriate' action on discrepencies. etc. Also to recommend that the UAC include both copies when it uses S/MIME encryption. Regards...Mark > 3. rejects requests which use private addresses, and include in its > response an offer with corresponding public addresses. > > hope this helps. > thanks, > -rohan > > > > On Thursday, December 5, 2002, at 09:14 AM, Mahey, Sonit wrote: > > > I agree with Jonathan. > > > > That brings up the question: > > Is NAT traversal for encrypted SIP traffic addressed anywhere? > > > > - sonit > > > >> -----Original Message----- > >> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > >> Sent: Thursday, December 05, 2002 11:28 AM > >> To: Pete Cordell > >> Cc: Christian Huitema; sip@ietf.org > >> Subject: Re: [Sip] B2BUA - Security > >> > >> > >> > >> > >> Pete Cordell wrote: > >> > >>> I would say that encrypting and / or integrity checking > of SDP alone > >>> achieves absolutely no security benefit. > >> > >> Really?? Wow. I actually think it prevents the most > >> devastating attacks > >> against SIP. These include: > >> > >> 1. modifying SDP in transit to point media streams to an > intermediate > >> recording device, allowing attackers to establish wiretaps > >> > >> 2. downgrading any SRTP keying done in SDP, so that the media > >> itself is > >> not encrypted or integrity protected (this came up during > the mmusic > >> session in IETF as a driver for S/MIME) > >> > >> 3. launching a DoS attack by sending everyones voice traffic to the > >> intended target. You get huge amplification gains here. Very > >> appealing > >> for hackers! > >> > >> > >> > >> > >>> > >>> SDP really does two things. It specifies transport > >> addresses and chosen > >>> codecs. > >>> > >>> Let's assume that you do encrypt the SDP and I can't read it. > >>> > >>> I can have a good guess at the transport addresses in use > >> from many of the > >>> other fields in SIP such as via lines, To, From, uri, > >> contact, route etc. > >> > >> Confidentiality is only one property of security. I am much more > >> concerned about message integrity. > >> > >>> (Put another way, encrypting SDP is another form of > >> security by obscurity. > >>> And we all know what that means.) > >> > >> I have no idea how you would arrive at such a conclusion. Security > >> through obscurity means that information is not cryptographically > >> protected, but encoded with a known process that is just a bit > >> complicated. By definition, this is not encryption. > Perhaps you have > >> discovered some new flaws in encryption technology? > >> > >> -Jonathan R. > >> -- > >> Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > >> Chief Scientist First Floor > >> dynamicsoft East Hanover, NJ 07936 > >> jdrosen@dynamicsoft.com FAX: (973) 952-5050 > >> http://www.jdrosen.net PHONE: (973) 952-5000 > >> http://www.dynamicsoft.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 > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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_01C29F6B.7129FF50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] B2BUA - Security

Rohan wrote:

> In addition to Jonathan's approach to session = policy, there is no
> reason a middlebox controller can't be a proxy = if it:
>
> 1. opens pinholes referenced in a clear text or = integrity
> protected SDP
> 2. rejects requests with no readable SDP (the = UA could
> instead include
> a full SDP, with keying material, encrypted = with SMIME, ****and an
> abbreviated copy which is only integrity = protected****).


I was about to write a draft suggesting exactly = this.

As per Jonathan's draft there is a need for the UA to = be able to 'declare' to network entities those parts of the SDP = information which are needed for the network entity to perform whatever = service it performs (e.g. NAT or Firewall control). But the UA should = not have to declare the whole SDP, and the terminating UA should be = able to tell if a network entity has modified these = parameters.

Rather than putting this information into new SIP = headers, we could include two copies of the SDP. One copy is = unprotected and contains only the information that the UE wishes to = 'declare' to the network entities. The other copy is protected and = contains the full information.

This approach would work through existing devices = which inspect/modify SDP.

I'm not sure how an existing S/MIME compliant client = would behave on receiving these two copies. If it uses the unprotected = SDP, then things are no worse than the present situation - the call = suceeds, but without the advantages of S/MIME. If it uses the protected = SDP (which has not been modified by the NAT controlling device), then = the call fails, but this is still no worse than the present = situation.

I guess if people liked this approach we would need = to document somewhere the UAS behaviour, namely: compare protected = & unprotected copies & take 'appropriate' action on = discrepencies. etc. Also to recommend that the UAC include both copies = when it uses S/MIME encryption.

Regards...Mark


> 3. rejects requests which use private addresses, = and include in its
> response an offer with corresponding public = addresses.
>
> hope this helps.
> thanks,
> -rohan
>
>
>
> On Thursday, December 5, 2002, at 09:14 AM, = Mahey, Sonit wrote:
>
> > I agree with Jonathan.
> >
> > That brings up the question:
> > Is NAT traversal for encrypted SIP traffic = addressed anywhere?
> >
> > - sonit
> >
> >> -----Original Message-----
> >> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> >> Sent: Thursday, December 05, 2002 = 11:28 AM
> >> To: Pete Cordell
> >> Cc: Christian Huitema; = sip@ietf.org
> >> Subject: Re: [Sip] B2BUA - = Security
> >>
> >>
> >>
> >>
> >> Pete Cordell wrote:
> >>
> >>> I would say that encrypting and / = or integrity checking
> of SDP alone
> >>> achieves absolutely no security = benefit.
> >>
> >> Really?? Wow. I actually think it = prevents the most
> >> devastating attacks
> >> against SIP. These include:
> >>
> >> 1. modifying SDP in transit to point = media streams to an
> intermediate
> >> recording device, allowing attackers = to establish wiretaps
> >>
> >> 2. downgrading any SRTP keying done in = SDP, so that the media
> >> itself is
> >> not encrypted or integrity protected = (this came up during
> the mmusic
> >> session in IETF as a driver for = S/MIME)
> >>
> >> 3. launching a DoS attack by sending = everyones voice traffic to the
> >> intended target. You get huge = amplification gains here. Very
> >> appealing
> >> for hackers!
> >>
> >>
> >>
> >>
> >>>
> >>> SDP really does two things.  = It specifies transport
> >> addresses and chosen
> >>> codecs.
> >>>
> >>> Let's assume that you do encrypt = the SDP and I can't read it.
> >>>
> >>> I can have a good guess at the = transport addresses in use
> >> from many of the
> >>> other fields in SIP such as via = lines, To, From, uri,
> >> contact, route etc.
> >>
> >> Confidentiality is only one property = of security. I am much more
> >> concerned about message = integrity.
> >>
> >>> (Put another way, encrypting SDP = is another form of
> >> security by obscurity.
> >>> And we all know what that = means.)
> >>
> >> I have no idea how you would arrive at = such a conclusion. Security
> >> through obscurity means that = information is not cryptographically
> >> protected, but encoded with a known = process that is just a bit
> >> complicated. By definition, this is = not encryption.
> Perhaps you have
> >> discovered some new flaws in = encryption technology?
> >>
> >> -Jonathan R.
> >> --
> >> Jonathan D. Rosenberg, = Ph.D.           &= nbsp;    72 Eagle Rock Ave.
> >> Chief = Scientist          &nb= sp;           &nb= sp;      First Floor
> >> = dynamicsoft          &= nbsp;           &= nbsp;          East = Hanover, NJ 07936
> >> = jdrosen@dynamicsoft.com        &= nbsp;            = FAX:   (973) 952-5050
> >> http://www.jdrosen.net    &nbs= p;           &nbs= p;     PHONE: (973) 952-5000
> >> http://www.dynamicsoft.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
>
> = _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core = SIP 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_01C29F6B.7129FF50-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Mon Dec 9 06:39:25 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05059 for ; Mon, 9 Dec 2002 06:39:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB9Bfng27469 for sip-archive@odin.ietf.org; Mon, 9 Dec 2002 06:41:49 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB9BYuv26681; Mon, 9 Dec 2002 06:34:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB9BWxv26588 for ; Mon, 9 Dec 2002 06:32:59 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04943 for ; Mon, 9 Dec 2002 06:30:04 -0500 (EST) From: hisham.khartabil@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gB9BYDW20856 for ; Mon, 9 Dec 2002 13:34:13 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 9 Dec 2002 13:32:55 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 9 Dec 2002 13:32:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] B2BUA & Max-Forwards Date: Mon, 9 Dec 2002 13:32:53 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE705F@esebe019.ntc.nokia.com> Thread-Topic: [Sip] B2BUA & Max-Forwards Thread-Index: AcKce7ETRbRM5yh8QGC3W8D6j0iWbgC+R+7g To: , Cc: , , X-OriginalArrivalTime: 09 Dec 2002 11:32:55.0415 (UTC) FILETIME=[B78BE070:01C29F76] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gB9BX0v26590 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Thursday, December 05, 2002 6:17 PM > To: Pete Cordell > Cc: Adam Roach; 'Phil Reynolds'; sip@ietf.org > Subject: Re: [Sip] B2BUA & Max-Forwards > > > I am at the point where I agree with the sentiment raised by others, > that we should remove the term b2bua entirely from the > specification. It > has caused more confusion than anything else. > I agree. Just forget about this B2BUA thing. There are things called "Application Servers (AS)" that perform whatever service you wish to invent. And most importantly, they are UASs. Think presence server. It is one type of AS. It receives SUBSCRIBE, on its UAS side, that is destined to a URI who's principle normally uses a terminal, and responds to them. Therefore needs to handle require-header. This Presence Server may initiate a SUBSCRIBE of its own, from its UAC side, that is destined to the same user. Here we have a B2BUA, but I hate that name, so I say here we have an Application Server. Think also presence list server. This is an example of one UAS to many UACs or one to many B2BUA. I like to call it Application Server. So lets drop this term B2BUA and use Application Server instead. I think people understand this term better. If 3GPP want every intermediary in the network to do something that is not SIP proxy compliant, then they better call it Application Server. Regards, Hisham _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Mon Dec 9 06:50:23 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05195 for ; Mon, 9 Dec 2002 06:50:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB9BqmD27720 for sip-archive@odin.ietf.org; Mon, 9 Dec 2002 06:52:48 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB9BnFv27617; Mon, 9 Dec 2002 06:49:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB9Bmnv27595 for ; Mon, 9 Dec 2002 06:48:49 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05116 for ; Mon, 9 Dec 2002 06:45:53 -0500 (EST) From: hisham.khartabil@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gB9Bo4W05056 for ; Mon, 9 Dec 2002 13:50:04 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 9 Dec 2002 13:48:23 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 9 Dec 2002 13:48:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] Handling of REFER/NOTIFY by Stateful Proxy Date: Mon, 9 Dec 2002 13:48:22 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE7060@esebe019.ntc.nokia.com> Thread-Topic: [Sip] Handling of REFER/NOTIFY by Stateful Proxy Thread-Index: AcKfZJ9EbBpmk9iBTii/htHOecwi/gAE+Xrg To: , X-OriginalArrivalTime: 09 Dec 2002 11:48:23.0116 (UTC) FILETIME=[E07FD0C0:01C29F78] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gB9Bmov27596 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit You are talking about Dialog Stateful proxy. In this case, the dialog at the proxy is not removed until the NOTIFY of a REFER terminates the dialog (or an unSUBSCRIBE). Remember, from recent discussions on the mailing list and from RFC3265, a dialog exists until all "associations" with that dialog are terminated. regards, Hisham > -----Original Message----- > From: ext Loh Kok Jeng [mailto:kokjeng.loh@siemens.com] > Sent: Monday, December 09, 2002 11:04 AM > To: sip@ietf.org > Subject: [Sip] Handling of REFER/NOTIFY by Stateful Proxy > > > Dear all, > > I have a question regarding the handling of REFER/NOTIFY that > is tied to > a session initiated with INVITE, i.e. REFER/NOTIFY belongs to > the same > dialog as INVITE. What should a stateful proxy do when it receives a > NOTIFY whose dialog has been terminated? I have 2 specific > scenarios in > mind, and both of them are illustrated in the diagrams below. > > Case 1: > The Referrer terminates the session with BYE. The stateful > proxy receives > NOTIFY after 200 OK for BYE. At that particular instance, > the stateful > proxy has already removed the dialog. > > Case 2: > The session expires and the stateful proxy removed the > session. It receives > NOTIFY from UAS. > > For these two cases, should the stateful proxy rejects NOTIFY > with 481? Or > should it proxy NOTIFY onwards? > > Thanks. > > regards, > KJ Loh > > > > +--------+ +--------+ +--------+ > |Referrer| |Stateful| | UAS | > | | | Proxy | | | > +--------+ 1 INVITE +--------+ +--------+ > |------------------------->| 2 INVITE | > | |------------------------->| > | | 3 200 OK | > | |<-------------------------| > | 4 200 OK | | > |<-------------------------| | > | 5 REFER | | > |------------------------->| 6 REFER | > | |------------------------->| > | | 7 200 OK | > | |<-------------------------| > | 8 200 OK | | > |<-------------------------| | > | | 9 NOTIFY | > | |<-------------------------| > | 10 NOTIFY | | > |<-------------------------| | > | 11 200 OK | | > |------------------------->| 12 200 OK | > | |------------------------->| > | ....... | ...... | > | | | > | 13 REFER | | > |------------------------->| 14 REFER | > | |------------------------->| > | | 15 200 OK | > | |<-------------------------| > | 16 200 OK | | > |<-------------------------| | > | 17 BYE | | > |------------------------->| 18 BYE | > | |------------------------->| > | | 19 200 OK | > | |<-------------------------| > | 21 200 OK | 20 NOTIFY | > |<-------------------------|<-------------------------| > > > > +--------+ +--------+ +--------+ > |Referrer| |Stateful| | UAS | > | | | Proxy | | | > +--------+ 1 INVITE +--------+ +--------+ > |------------------------->| 2 INVITE | > | |------------------------->| > | | 3 200 OK | > | |<-------------------------| > | 4 200 OK | | > |<-------------------------| | > | 5 REFER | | > |------------------------->| 6 REFER | > | |------------------------->| > | | 7 200 OK | > | |<-------------------------| > | 8 200 OK | | > |<-------------------------| | > | | 9 NOTIFY | > | |<-------------------------| > | 10 NOTIFY | | > |<-------------------------| | > | 11 200 OK | | > |------------------------->| 12 200 OK | > | |------------------------->| > | ....... | ...... | > | | | > | 13 REFER | | > |------------------------->| 14 REFER | > | |------------------------->| > | | 15 200 OK | > | |<-------------------------| > | 16 200 OK | | > |<-------------------------| | > | +-----------------+ | > | |Session Timeout | | > | |Session torn down| | > | +-----------------+ | > | | 17 NOTIFY | > | |<-------------------------| > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Mon Dec 9 10:34:18 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14048 for ; Mon, 9 Dec 2002 10:34:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB9FahK08837 for sip-archive@odin.ietf.org; Mon, 9 Dec 2002 10:36:43 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB9FWuv08546; Mon, 9 Dec 2002 10:32:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB9FVJv08485 for ; Mon, 9 Dec 2002 10:31:19 -0500 Received: from dyn-tx-arch-crash.dfw.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13762 for ; Mon, 9 Dec 2002 10:28:23 -0500 (EST) Received: from RjS.localdomain (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id gB9FV8I31731; Mon, 9 Dec 2002 09:31:08 -0600 Subject: Re: [Sip] ABNF issue From: Robert Sparks To: Christer Holmberg Cc: Jonathan Rosenberg , sip@ietf.org In-Reply-To: <3DF4433B.B180D38@lmf.ericsson.se> References: <3DEF27BE.80ED31E2@lmf.ericsson.se> <3DEF7F8D.70902@dynamicsoft.com> <3DEFCF15.3C381C9F@lmf.ericsson.se> <3DF03D40.2030608@dynamicsoft.com> <3DF4433B.B180D38@lmf.ericsson.se> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 09 Dec 2002 09:29:38 -0600 Message-Id: <1039447778.918.34.camel@RjS.localdomain> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit inline On Mon, 2002-12-09 at 01:16, Christer Holmberg wrote: > > Hi, > > > >The body does not start with LWS. The body starts with WSP (RFC3261 doesn't > > >define what WSP is, but if I remember correct it is SP or TAB). So, in that > > >case you will have: > > > > > >CRLF CRLF WSP > > > > > >...which, according to the ABNF is: > > > > > >CRLF LWS > > > > You are taking this out of context. It is not the case that you would > > parse through the message replaceing all instances of CRLF WSP with LWS. > > So, where in the rules is it said when I should do that, and when I should not? > To my understanding the LWS rule is defined as a "general rule". You need to be very careful here. Just because there is a production rule that says A -> BC does not mean all occurrences of BC in the language resulted from the expansion of A. Blindly doing a reverse token substitution will produce an incorrect parse. You can only apply it when you have proven the left side of the rule fits in a valid parse of the message. So from your original example. LWS is not defined inside a body - the body is just a sequence of octets from the perspective of the SIP grammar. Your SIP parser _cannot_ apply a match against LWS inside it - there is no valid expansion of the SIP grammar that has LWS appearing after CRLF CRLF > > > The BNF specifies that message-header ends with a CRLF. > > Yes. > > > What follows that is one of two things - either another CRLF, marking the end > > of the > > headers, or another message header, which never begins with LWS. > > >From a SIP grammar point of view that is correct. However, I don't see it said > anywhere that the definition of LWS isn't valid at the beginning of a new line. It _is_ valid after CRLF (which is what I think you mean by a new line) if (and only if) you are still in the expansion of message-header. > > Also, just for the record, where is it said that a sip-header can't start with > LWS? Where is it said that line folding can't be used at the beginning of a line? > The text only says that the sip-header field values can be folded onto multiple > lines. I don't know what you mean by beginning of a line here. I assume you are asking why we cant have a header that looks like (\b for blank): \b\bNewHeader: foo which is a "\b\bNewheader"? The grammar answers that. extension-header starts with a token. > > > Thus, if a CRLF is followed by something OTHER than WSP, the next construction > > > cannot be LWS. > > Maybe I missunderstand you, but the case I try to describe is when the CRLF IS > followed by WSP. If its in a valid expansion of message-header (which will not happen across a CRLFCRLF string), then you are looking at LWS. The _only_ place that second CRLF matches in the grammar is the literal in the Request and Response rules. So for your example, any whitespace following that second CRLF matches message-body = *OCTET, NOT LWS. > > Regards, > > Christer Holmberg > Ericsson Finland > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Mon Dec 9 10:43:31 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14375 for ; Mon, 9 Dec 2002 10:43:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB9FjuT09875 for sip-archive@odin.ietf.org; Mon, 9 Dec 2002 10:45:56 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB9FgGv09707; Mon, 9 Dec 2002 10:42:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB9Ffsv09681 for ; Mon, 9 Dec 2002 10:41:54 -0500 Received: from ihemail1.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14248 for ; Mon, 9 Dec 2002 10:38:58 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by ihemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id gB9Ffn705622 for ; Mon, 9 Dec 2002 10:41:50 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2653.19) id ; Mon, 9 Dec 2002 15:41:48 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB006E5631A@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "Rosen, Brian" , "'aki.niemi@nokia.com'" Cc: sip@ietf.org Subject: RE: [Sip] B2BUA Date: Mon, 9 Dec 2002 15:41:46 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , I would suggest that in addition to this, we list in this proposed informational document Deans 10 rules of transparency (suitably enhanced if necessary). B2BUA providers can then use this as a tick list to indicate some of the functionality of the B2BUA, and receivers of such a list will get an idea of how significantly the entity breaks the end-to-end SIP transparency, which is after all the main thing of interest to the end UA. Doing this may actually provide a document of some use, and allow IETF to put forward that even if it is a B2BUA, designing as much transparency into it, while still performing the un-proxy-like function that is intended, is a good thing. Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: 03 December 2002 16:29 > To: 'aki.niemi@nokia.com' > Cc: sip@ietf.org > Subject: RE: [Sip] B2BUA > > > > > So the B2BUA is a concatenation of two User Agents, each of > > which acts both as UAC and UAS. A conference server will > > probably look like a UA, definitely not a B2BUA, IMHO. > > > This thread is, hopefully reaching an end (with an agreement to > do some examples with call flows). However, the above statement > is yet one more example of the confusion people have with B2BUA. > > The key thing about a B2BUA is that it looks like a UA to whatever > it is connected to (on both sides). So, a conference server > looks like a UA to each of it's ports, and it has at least two of > them, and there is some "magic" between them. If you look at the > concept of the "focus" from the conferencing work, it is a > thing that has a bunch of two ended SIP calls, one with each > participant. Each participant thinks it is talking to a UA. > While some messages sent from a participant to a UA might be > consumed by the UA (state changes), often, a message will trigger > messages from the focus to other participants. > > This seems, to me, to meet the definition of B2BUA in 3261, > and more strongly meets proposed changes in the definition. > Of course, it really doesn't matter if you consider the focus to > be a B2BUA or not. > > Brian > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Mon Dec 9 10:43:34 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14390 for ; Mon, 9 Dec 2002 10:43:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB9FjxW09892 for sip-archive@odin.ietf.org; Mon, 9 Dec 2002 10:45:59 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB9FgQv09733; Mon, 9 Dec 2002 10:42:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB9Ffuv09685 for ; Mon, 9 Dec 2002 10:41:56 -0500 Received: from ihemail1.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14253 for ; Mon, 9 Dec 2002 10:38:59 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by ihemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id gB9Ffp705651 for ; Mon, 9 Dec 2002 10:41:51 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2653.19) id ; Mon, 9 Dec 2002 15:41:48 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB006E5631B@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: aki.niemi@nokia.com, Brian.Rosen@marconi.com Cc: sip@ietf.org Subject: RE: [Sip] B2BUA Date: Mon, 9 Dec 2002 15:41:47 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , I would assume there are some instances where we want transparency of SIP contents and bodies between UAs "connected" to a focus, and therefore defining it as a B2BUA with some requirements on transparency, is actually better than saying there is no relationship between the UAs that make up the focus. Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com > -----Original Message----- > From: aki.niemi@nokia.com [mailto:aki.niemi@nokia.com] > Sent: 03 December 2002 18:00 > To: Brian.Rosen@marconi.com > Cc: sip@ietf.org > Subject: RE: [Sip] B2BUA > > > Brian, > > inline. > > > Of course these things are never so simple. > > On an "end system mixed" conference, an INVITE > > from a new participant triggers Re-INVITES to > > existing participants. Depending on details, > > a focus could hold the response from the INVITE > > of the new participant until it receives responses > > from all existing participants (new CODEC negotiation > > for example). That meets your definition of B2BUA. > > > > On the other hand, a centrally mixed conference > > would not normally trigger Re-INVITES. Does that > > mean that an end-system mixed focus is a B2BUA > > but a centrally mixed focus is not? Hard to > > differentiate. With both of them, a state > > change, signaled by, say a NOTIFY from one to > > the focus triggers NOTIFIES to (possibly a > > subset of) the other participants, so that > > would meet the definition. Would you call > > that a change in roles? > > I agree, a conference server could assume both UA and B2BUA > roles, as well as proxy and redirect server roles depending > on the system, application, request, and so on. But whether > a focus is a UA, a B2BUA, or both is somewhat besides the > point. The roles need to be defined so that B2BUA behavior > is distinct from UA behavior. The end-point can then use one > that best fits its purpose. > > Cheers, > Aki > > > > > Brian > > > > > -----Original Message----- > > > From: aki.niemi@nokia.com [mailto:aki.niemi@nokia.com] > > > Sent: Tuesday, December 03, 2002 12:13 PM > > > To: Brian.Rosen@marconi.com > > > Cc: sip@ietf.org > > > Subject: RE: [Sip] B2BUA > > > > > > > > > Inline. > > > > > > > The key thing about a B2BUA is that it looks like a UA > to whatever > > > > it is connected to (on both sides). So, a conference server > > > > looks like a UA to each of it's ports, and it has at > least two of > > > > them, and there is some "magic" between them. If you > look at the > > > > concept of the "focus" from the conferencing work, it is a > > > > thing that has a bunch of two ended SIP calls, one with each > > > > participant. Each participant thinks it is talking to a UA. > > > > While some messages sent from a participant to a UA might be > > > > consumed by the UA (state changes), often, a message > will trigger > > > > messages from the focus to other participants. > > > > > > This just generalized the B2BUA to cover any normal UA > > > behavior. Example, I get a MESSAGE from a friend to my UA, > > > based on which decide to call another friend by sending an > > > INVITE from that UA. This I think is quite normal UA > > > operation, the "magic" being me via my UI. > > > > > > > This seems, to me, to meet the definition of B2BUA in 3261, > > > > and more strongly meets proposed changes in the definition. > > > > Of course, it really doesn't matter if you consider the focus to > > > > be a B2BUA or not. > > > > > > Hmm... Let's think of the B2BUA as 'in-UA' concatenated with > > > 'out-UA'. By definition: > > > > > > 1) in-UAS receives request, > > > > > > 2) out-UAC sends request' > > > 3) out-UAC receives response' > > > > > > 4) in-UAS sends response > > > > > > (The same process happens with requests going from 'out' to 'in') > > > > > > Within this B2BUA, 'in-UAS' shares magic with 'out-UAC', and > > > 'in-UAC' shares magic with 'out-UAS'. However, if (as you > > > state above), 4) follows immediately after 1), it's no longer > > > a B2BUA, but a plain old UA, IMHO. > > > > > > Cheers, > > > Aki > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Mon Dec 9 10:43:39 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14403 for ; Mon, 9 Dec 2002 10:43:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB9Fk4t09910 for sip-archive@odin.ietf.org; Mon, 9 Dec 2002 10:46:04 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB9FgTv09755; Mon, 9 Dec 2002 10:42:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB9Ffxv09689 for ; Mon, 9 Dec 2002 10:41:59 -0500 Received: from hoemail1.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14250 for ; Mon, 9 Dec 2002 10:38:59 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by hoemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id gB9Ffof01009 for ; Mon, 9 Dec 2002 10:41:50 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2653.19) id ; Mon, 9 Dec 2002 15:41:49 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB006E5631C@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: Mary Barnes , "'Jonathan Rosenberg'" , Pete Cordell Cc: "David R. Oran" , Dean Willis , sip@ietf.org Subject: RE: [Sip] B2BUA & Max-Forwards Date: Mon, 9 Dec 2002 15:41:47 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This thread is definitely going way beyond what it should do (both in scope and duration) - it did however start (about a 100 messages ago) with some reasonable modifications to the B2BUA definition, and save those relatively minor modifications, I do not want to see any other modifications in RFC 3261 or its next revision. I certainly will not agree to removal of any existing definition of B2BUA. Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com > -----Original Message----- > From: Mary Barnes [mailto:mbarnes@nortelnetworks.com] > Sent: 06 December 2002 15:40 > To: 'Jonathan Rosenberg'; Pete Cordell > Cc: David R. Oran; Dean Willis; sip@ietf.org > Subject: RE: [Sip] B2BUA & Max-Forwards > > > > I agree with Jonathan. As mentioned earlier this week > apparently, there is > already work underway by some individuals to write an > informational draft > documenting BBUA scenarios/call flows. > > I'll keep my fingers crossed that the existence of such a > document can save > us from another round of B2BUA discussions again in 3 months. > > Regards, > Mary. > > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Friday, December 06, 2002 12:59 AM > To: Pete Cordell > Cc: David R. Oran; Dean Willis; sip@ietf.org > Subject: Re: [Sip] B2BUA & Max-Forwards > > > > > Pete Cordell wrote: > > Dave, > > > > To save your disagreeableness, can we say something like: > > > > "A B2BUA MUST perform loop prevention. One way to do this > is to propagate > > the Max-Forwards header from the incoming request to the > outgoing request > in > > the same way that a proxy does." > > A statement like this is completely out of scope for rfc3261. > It might > be a reasonable statement to make in some kind of application > document > that describes a particular type of b2bua. However, it makes no more > sense to say this in RFC 3261 as it would be to discuss the ways in > which to build a focus or a 3pcc controller (both of which are also > informational, by the way). > > I can't resist pointing out that much of this is deja vu. Folks may > recall heated discussions in Adelaide, where there was a bof > (I think) > that wanted to have a working group to specify SIP to H.323 > conversion. > THe same arguemtns that were made there are being made here; its an > application level issue, there are many ways to do it, don't stifle > creativity, etc. In fact I recall that Dave was, as always, quite > vociferous on these points. > > The eventual conclusion in the h323/sip conversion case was > to write an > INFORMATIONAL RFC that documents reasonable practices in > building such a > device. I believe the same logic and conclusions apply here. If folks > have a particular type of b2bua application they are fond of, please > feel free to write up your implementation advice and I am > sure sipping > would consider whether or not it would make a useful > informational RFC. > > However, it is completely inappropriate to ever make such application > logic normative, and even more inappropraite for such wording > to be in > rfc3261. > > Anyway, I too am tired of this thread. I think, in fact, there is > "rough" consensus to remove the definition of b2bua entirely from > rfc3261 in its next revision (which is quite some time in the future > anyway). However, I'll let the chairs decide that. > > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.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 > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Mon Dec 9 13:36:40 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23798 for ; Mon, 9 Dec 2002 13:36:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB9Id8e22414 for sip-archive@odin.ietf.org; Mon, 9 Dec 2002 13:39:08 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB9IZOv21645; Mon, 9 Dec 2002 13:35:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB9IXnv21561 for ; Mon, 9 Dec 2002 13:33:49 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23488 for ; Mon, 9 Dec 2002 13:30:50 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.25]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gB9IXbYH014459; Mon, 9 Dec 2002 13:33:37 -0500 (EST) Message-ID: <3DF4E1FD.40205@dynamicsoft.com> Date: Mon, 09 Dec 2002 13:33:33 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Drage, Keith (Keith)" CC: Mary Barnes , Pete Cordell , "David R. Oran" , Dean Willis , sip@ietf.org Subject: Re: [Sip] B2BUA & Max-Forwards References: <475FF955A05DD411980D00508B6D5FB006E5631C@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Drage, Keith (Keith) wrote: > This thread is definitely going way beyond what it should do (both in > scope and duration) - it did however start (about a 100 messages ago) > with some reasonable modifications to the B2BUA definition, and save > those relatively minor modifications, I do not want to see any other > modifications in RFC 3261 or its next revision. > > I certainly will not agree to removal of any existing definition of > B2BUA. Well, we have some time to conclude this (since we are not revving rfc3261 for some time), but it was my sense that there was ROUGH consensus to remove it. Rough doesn't mean unanimous of course... -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.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 mailnull@www1.ietf.org Mon Dec 9 13:40:44 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24025 for ; Mon, 9 Dec 2002 13:40:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB9IhCX22683 for sip-archive@odin.ietf.org; Mon, 9 Dec 2002 13:43:12 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB9IdJv22437; Mon, 9 Dec 2002 13:39:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB9Icfv22383 for ; Mon, 9 Dec 2002 13:38:41 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23727 for ; Mon, 9 Dec 2002 13:35:42 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.25]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gB9IbuYH014462; Mon, 9 Dec 2002 13:37:57 -0500 (EST) Message-ID: <3DF4E300.90909@dynamicsoft.com> Date: Mon, 09 Dec 2002 13:37:52 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Watson CC: "'Rohan Mahy'" , "Mahey, Sonit" , Pete Cordell , Christian Huitema , sip@ietf.org Subject: Re: [Sip] B2BUA - Security References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit inline. Mark Watson wrote: > Rohan wrote: > > > In addition to Jonathan's approach to session policy, there is no > > reason a middlebox controller can't be a proxy if it: > > > > 1. opens pinholes referenced in a clear text or integrity > > protected SDP > > 2. rejects requests with no readable SDP (the UA could > > instead include > > a full SDP, with keying material, encrypted with SMIME, ****and an > > abbreviated copy which is only integrity protected****). > > > I was about to write a draft suggesting exactly this. THis is simply not sufficient. It will suffice for firewalls, but not for NAT, where an actual modification needs to occur. I think that, per Pete's suggestion, the correct path forward is a requirements document that describes the problem and the requirements for the solution. I believe there are many interesting requirements here about disclosure of what is being done, that will strongly impact the solution. > > As per Jonathan's draft there is a need for the UA to be able to > 'declare' to network entities those parts of the SDP information which > are needed for the network entity to perform whatever service it > performs (e.g. NAT or Firewall control). But the UA should not have to > declare the whole SDP, and the terminating UA should be able to tell if > a network entity has modified these parameters. Sounds like we are beginning the requirements work here... > > Rather than putting this information into new SIP headers, we could > include two copies of the SDP. One copy is unprotected and contains only > the information that the UE wishes to 'declare' to the network entities. > The other copy is protected and contains the full information. I think we can leave the header/body debate for down the road. I would be happy if we can get agreement on this general problem as one that we need to solve. > > This approach would work through existing devices which inspect/modify SDP. > > I'm not sure how an existing S/MIME compliant client would behave on > receiving these two copies. If it uses the unprotected SDP, then things > are no worse than the present situation - the call suceeds, but without > the advantages of S/MIME. If it uses the protected SDP (which has not > been modified by the NAT controlling device), then the call fails, but > this is still no worse than the present situation. It comes down to disclosure. The message needs to convey information about the meaning of the multiple session descriptions - who set which, and why. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.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 mailnull@www1.ietf.org Mon Dec 9 13:43:35 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24173 for ; Mon, 9 Dec 2002 13:43:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB9Ik3822805 for sip-archive@odin.ietf.org; Mon, 9 Dec 2002 13:46:03 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB9IgGv22622; Mon, 9 Dec 2002 13:42:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB9Ifsv22580 for ; Mon, 9 Dec 2002 13:41:54 -0500 Received: from brmx1.fl.icn.siemens.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23898 for ; Mon, 9 Dec 2002 13:38:55 -0500 (EST) Received: from boca210a.boca.ssc.siemens.com (boca210a.boca.ssc.siemens.com [165.218.12.110]) by brmx1.fl.icn.siemens.com (8.9.3/8.9.3) with ESMTP id NAA20392; Mon, 9 Dec 2002 13:41:29 -0500 (EST) Received: by BOCA210A with Internet Mail Service (5.5.2653.19) id ; Mon, 9 Dec 2002 13:41:28 -0500 Message-ID: From: "Mahey, Sonit" To: "'Jonathan Rosenberg'" , Mark Watson Cc: "'Rohan Mahy'" , Pete Cordell , Christian Huitema , sip@ietf.org Subject: RE: [Sip] B2BUA - Security Date: Mon, 9 Dec 2002 13:40:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Folks, I agree with Jonathan. We need some definition around the work. - sonit > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Monday, December 09, 2002 1:38 PM > To: Mark Watson > Cc: 'Rohan Mahy'; Mahey, Sonit; Pete Cordell; Christian Huitema; > sip@ietf.org > Subject: Re: [Sip] B2BUA - Security > > > inline. > > Mark Watson wrote: > > Rohan wrote: > > > > > In addition to Jonathan's approach to session policy, there is no > > > reason a middlebox controller can't be a proxy if it: > > > > > > 1. opens pinholes referenced in a clear text or integrity > > > protected SDP > > > 2. rejects requests with no readable SDP (the UA could > > > instead include > > > a full SDP, with keying material, encrypted with SMIME, > ****and an > > > abbreviated copy which is only integrity protected****). > > > > > > I was about to write a draft suggesting exactly this. > > THis is simply not sufficient. > > It will suffice for firewalls, but not for NAT, where an actual > modification needs to occur. > > I think that, per Pete's suggestion, the correct path forward is a > requirements document that describes the problem and the requirements > for the solution. I believe there are many interesting > requirements here > about disclosure of what is being done, that will strongly impact the > solution. > > > > > As per Jonathan's draft there is a need for the UA to be able to > > 'declare' to network entities those parts of the SDP > information which > > are needed for the network entity to perform whatever service it > > performs (e.g. NAT or Firewall control). But the UA should > not have to > > declare the whole SDP, and the terminating UA should be > able to tell if > > a network entity has modified these parameters. > > Sounds like we are beginning the requirements work here... > > > > > Rather than putting this information into new SIP headers, we could > > include two copies of the SDP. One copy is unprotected and > contains only > > the information that the UE wishes to 'declare' to the > network entities. > > The other copy is protected and contains the full information. > > I think we can leave the header/body debate for down the > road. I would > be happy if we can get agreement on this general problem as > one that we > need to solve. > > > > > This approach would work through existing devices which > inspect/modify SDP. > > > > I'm not sure how an existing S/MIME compliant client would > behave on > > receiving these two copies. If it uses the unprotected SDP, > then things > > are no worse than the present situation - the call suceeds, > but without > > the advantages of S/MIME. If it uses the protected SDP > (which has not > > been modified by the NAT controlling device), then the call > fails, but > > this is still no worse than the present situation. > > It comes down to disclosure. The message needs to convey information > about the meaning of the multiple session descriptions - who > set which, > and why. > > -Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.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 mailnull@www1.ietf.org Mon Dec 9 15:00:55 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28449 for ; Mon, 9 Dec 2002 15:00:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB9K3Nm28184 for sip-archive@odin.ietf.org; Mon, 9 Dec 2002 15:03:23 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB9JuBv27860; Mon, 9 Dec 2002 14:56:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB9JsOv27763 for ; Mon, 9 Dec 2002 14:54:24 -0500 Received: from mail2.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27998 for ; Mon, 9 Dec 2002 14:51:24 -0500 (EST) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id gB9Jr8vo003217; Mon, 9 Dec 2002 14:53:08 -0500 (EST) Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 9 Dec 2002 13:54:17 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A64394@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'hisham.khartabil@nokia.com'" , kokjeng.loh@siemens.com, sip@ietf.org Subject: RE: [Sip] Handling of REFER/NOTIFY by Stateful Proxy Date: Mon, 9 Dec 2002 13:54:16 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hisham Khartabil wrote: > You are talking about Dialog Stateful proxy. In this case, > the dialog at the proxy is not removed until the NOTIFY of a > REFER terminates the dialog (or an unSUBSCRIBE). The issue, I beleive, is that the proxy in question doesn't necessarily know anything about the behavior associated with SUBSCRIBE and NOTIFY. So, from its perspective, the dialog *is* terminated with the BYE. So, that brings us back to Loh Kok Jeng's question: > What should a stateful proxy do when it receives > a NOTIFY whose dialog has been terminated? > ...[S]hould the stateful proxy rejects NOTIFY > with 481? Or should it proxy NOTIFY onwards? As Hisham points out, your question appears to apply to a *dialog* stateful proxy, which is a rather different beast than a stateful proxy. The simple answer is: it should proxy it on. However, this behavior should naturally fall out of good design on the part of the proxy. Ask yourself: in general, if your proxy receives a request with a "Route" header for which you have no dialog, what is the correct behavior? Well, if you know *how* to proxy it, you *should* proxy it. In this case, the presence of a "Route" header gives you sufficient information about where to send it. (This is one of the important SIP protocol behaviors, for example, behind the "Service Route Discovery" draft). /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Mon Dec 9 16:01:03 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01645 for ; Mon, 9 Dec 2002 16:01:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB9L3Xi31616 for sip-archive@odin.ietf.org; Mon, 9 Dec 2002 16:03:33 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB9KxAv31436; Mon, 9 Dec 2002 15:59:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB9Kvhv31387 for ; Mon, 9 Dec 2002 15:57:43 -0500 Received: from mailcity.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA01336 for ; Mon, 9 Dec 2002 15:54:42 -0500 (EST) Received: from Unknown/Local ([?.?.?.?]) by mailcity.com; Mon, 09 Dec 2002 20:57:14 -0000 To: sip@ietf.org Date: Mon, 09 Dec 2002 15:57:14 -0500 From: "Jitender Arora" Message-ID: Mime-Version: 1.0 X-Sent-Mail: off Reply-To: jitender_arora@lycos.com X-Mailer: MailCity Service X-Priority: 3 X-Sender-Ip: 63.144.164.60 Organization: Lycos Mail (http://www.mail.lycos.com:80) Content-Type: text/plain; charset=us-ascii Content-Language: en Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] (No Subject) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi , Can we use REFER call transfer mechanism to , transfer the call from one PSTN subscriber to the other PSTN subscriber ( in the Net-2-Phone calls )....... I am talking of the Net-2-Phone Scenario ( say one guy sitting on PC, Using SIP Phone ) , is making a call to PSTN Phone . So we will be using the SIP on one side and ISUP ( just for example) on the PSTN side ......... So will the following call flow valid , and can be used as a REFER call scenario : SIP PHONE/Proxy Switch PSTN INVITE F1 --------------------------------> IAM S1 -------------------------------> ( PSTN Phone 1) 100 Trying F2 <--------------------------------- ACM S2 <-------------------------------- ( PSTN Phone 1) 183 F3 <-------------------------------- ANM S3 <-------------------------------- ( PSTN Phone 1) 200 O.K F4 <-------------------------------- ACK F5 ---------------------------------> INVITE ( Hold )F6 ----------------------------------> 200 O.K F7 <---------------------------------- ACK F8 ---------------------------------> REFER ( New PSTN URI )F9 ----------------------------------> 202 ACCEPTED F10 <--------------------------------- IAM S4 ------------------------------------> (PSTN Phone 2) ACM S5 <------------------------------------ ( PSTN Phone2 ) ANM S6 <----------------------------------- ( PSTN Phone 2) NOTIFY F11 <--------------------------------- 200 OK F12 ----------------------------------> REL for first PSTN Subscriber S7 --------------------------------------->(PSTN Phone 1) REL Confirm S8 <----------------------------------------- (PSTN Phone 1) Plese let me know if it is valid call flow ...... Regards, jitender . _____________________________________________________________ Get 25MB, POP3, Spam Filtering with LYCOS MAIL PLUS for $19.95/year. http://login.mail.lycos.com/brandPage.shtml?pageId=plus&ref=lmtplus _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Mon Dec 9 17:50:39 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06604 for ; Mon, 9 Dec 2002 17:50:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB9Mr8706284 for sip-archive@odin.ietf.org; Mon, 9 Dec 2002 17:53:08 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB9Mk1v06025; Mon, 9 Dec 2002 17:46:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB9Miov05965 for ; Mon, 9 Dec 2002 17:44:50 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06244 for ; Mon, 9 Dec 2002 17:41:50 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.25]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gB9MijYH014566; Mon, 9 Dec 2002 17:44:45 -0500 (EST) Message-ID: <3DF51CDA.5060504@dynamicsoft.com> Date: Mon, 09 Dec 2002 17:44:42 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?UTF-8?B?UGV0ZXIgUMOkcHBpbmdoYXVz?= CC: sip@ietf.org Subject: Re: [Sip] Buggy example in draft-ietf-sipping-reg-event-00 References: <3DCBD689.9030805@siemens.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Yes, this is a bug in the example. Thanks for pointing it out. -Jonathan R. Peter Päppinghaus wrote: > Hi, > > I believe to have stumbled on a buggy example in > draft-ietf-sipping-reg-event-00.txt. > > Quotation from top of p. 19: > > "Later on, the user registers (5): > > REGISTER sip:joe@bar.com SIP/2.0 > Via: SIP/2.0/UDP pc34.bar.com;branch=z9hG4bKnaaff > From: sip:joe@bar.com;tag=99a8s > To: sip:joe@bar.com > Call-ID: 88askjda9@pc34.bar.com > CSeq: 9976 REGISTER > Contact: sip:joe@pc34.bar.com" > > The Request-URI in this example violates RFC 3261, sec. 10.2: > "The userinfo and "@" components of the SIP URI MUST NOT be present." > > Regards, > > Peter Paeppinghaus > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.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 mailnull@www1.ietf.org Mon Dec 9 18:55:15 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08809 for ; Mon, 9 Dec 2002 18:55:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gB9NvjZ09840 for sip-archive@odin.ietf.org; Mon, 9 Dec 2002 18:57:45 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB9Ns2v09649; Mon, 9 Dec 2002 18:54:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB9Nq5v09585 for ; Mon, 9 Dec 2002 18:52:05 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08570 for ; Mon, 9 Dec 2002 18:49:04 -0500 (EST) Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id gB9NotjS003338; Mon, 9 Dec 2002 15:50:55 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABK63656; Mon, 9 Dec 2002 15:48:08 -0800 (PST) Date: Mon, 9 Dec 2002 15:51:36 -0800 Subject: Re: [Sip] B2BUA - Security Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: Mark Watson , "Mahey, Sonit" , Pete Cordell , Christian Huitema , sip@ietf.org To: Jonathan Rosenberg From: Rohan Mahy In-Reply-To: <3DF4E300.90909@dynamicsoft.com> Message-Id: <27043D6A-0BD1-11D7-8C59-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Monday, December 9, 2002, at 10:37 AM, Jonathan Rosenberg wrote: > inline. > > Mark Watson wrote: >> Rohan wrote: >> > In addition to Jonathan's approach to session policy, there is no >> > reason a middlebox controller can't be a proxy if it: >> > >> > 1. opens pinholes referenced in a clear text or integrity >> > protected SDP >> > 2. rejects requests with no readable SDP (the UA could >> > instead include >> > a full SDP, with keying material, encrypted with SMIME, ****and an >> > abbreviated copy which is only integrity protected****). >> I was about to write a draft suggesting exactly this. > > THis is simply not sufficient. > > It will suffice for firewalls, but not for NAT, where an actual > modification needs to occur. The midbox controller could propose a new SDP with public addresses/ports, which the UAC could actually sign. I believe this will work, and requires minimal changes to SIP (at most a new response code). Also if we separate the NAT problem into address/port discovery, and refresh, the UAC could use STUN to discover addresses, and just send a copy of the SDP with these recently discovered public addresses to the midbox controller, which just needs to *a* copy of part of the SDP to keep ports open. It can even use session timer to avoid keeping state. thanks, -rohan > I think that, per Pete's suggestion, the correct path forward is a > requirements document that describes the problem and the requirements > for the solution. I believe there are many interesting requirements > here about disclosure of what is being done, that will strongly impact > the solution. > >> As per Jonathan's draft there is a need for the UA to be able to >> 'declare' to network entities those parts of the SDP information >> which are needed for the network entity to perform whatever service >> it performs (e.g. NAT or Firewall control). But the UA should not >> have to declare the whole SDP, and the terminating UA should be able >> to tell if a network entity has modified these parameters. > > Sounds like we are beginning the requirements work here... > >> Rather than putting this information into new SIP headers, we could >> include two copies of the SDP. One copy is unprotected and contains >> only the information that the UE wishes to 'declare' to the network >> entities. The other copy is protected and contains the full >> information. > > I think we can leave the header/body debate for down the road. I would > be happy if we can get agreement on this general problem as one that > we need to solve. > >> This approach would work through existing devices which >> inspect/modify SDP. >> I'm not sure how an existing S/MIME compliant client would behave on >> receiving these two copies. If it uses the unprotected SDP, then >> things are no worse than the present situation - the call suceeds, >> but without the advantages of S/MIME. If it uses the protected SDP >> (which has not been modified by the NAT controlling device), then the >> call fails, but this is still no worse than the present situation. > > It comes down to disclosure. The message needs to convey information > about the meaning of the multiple session descriptions - who set > which, and why. > > -Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.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 mailnull@www1.ietf.org Tue Dec 10 02:26:57 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00371 for ; Tue, 10 Dec 2002 02:26:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBA7TVk09868 for sip-archive@odin.ietf.org; Tue, 10 Dec 2002 02:29:31 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBA7Piv09673; Tue, 10 Dec 2002 02:25:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4GrQv00562 for ; Wed, 4 Dec 2002 11:53:26 -0500 Received: from stamail.telecom.sna.samsung.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21418 for ; Wed, 4 Dec 2002 11:50:31 -0500 (EST) Received: by stamail.telecom.sna.samsung.com with Internet Mail Service (5.5.2653.19) id ; Wed, 4 Dec 2002 10:54:20 -0600 Message-ID: <4B9386E83999D411997100508BAF206A07C7B646@stamail.telecom.sna.samsung.com> From: Kedar Patil To: "'Adam Roach'" , "'Padma Suresh'" , vkg@lucent.com, pete@tech-know-ware.com Cc: sip@ietf.org Subject: RE: [Sip] B2BUA & Max-Forwards Date: Wed, 4 Dec 2002 10:54:18 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C29BB5.C9375DF0" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , 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_01C29BB5.C9375DF0 Content-Type: text/plain; charset="iso-8859-1" This discussion raises one more doubt for me, pls. clarify. UA1------->BtoBUA---------->UA2 Is the BtoBUA a SIP endpoint from UA1's point of view? In other words, are the the "Require:" etc end-to-end headers sent by UA1, meant for B2BUA or UA2? Is the UAS part in in BtoBUA is bound by the definition and rules in 3261? thanks, = Kedar = > -----Original Message----- > From: Adam Roach [mailto:adam@dynamicsoft.com] > Sent: Tuesday, December 03, 2002 6:37 PM > To: 'Padma Suresh'; vkg@lucent.com; pete@tech-know-ware.com > Cc: sip@ietf.org > Subject: RE: [Sip] B2BUA & Max-Forwards > > > -----Original Message----- > From: Padma Suresh [mailto:padma_suresh@hotmail.com] > > > A B2BUA needs to propagate some of the headers received in a > > request/response to the other endpoint. Example: Require... > > No. As emphatically as possible: NO. This is completely wrong, > and it appears to be a growing -- and dangerous -- misconception. > > A B2BUA cannot transparently pass Require through. It must > understand and invoke the extension indicated. > > "The Require header field contains a list of option tags, > described in > Section 19.2. Each option tag defines a SIP extension that MUST be > understood to process the request." > > A back to back user agent *is* a UAS, and *is* bound by this > provision. > > Whether the UAC portion then turns around and imposes the same > requirement on the UAS it contacts is a local decision. > > /a ------_=_NextPart_001_01C29BB5.C9375DF0 Content-Type: text/html; charset="iso-8859-1" RE: [Sip] B2BUA & Max-Forwards

This discussion raises one more doubt for me, pls. clarify.

UA1------->BtoBUA---------->UA2

Is the BtoBUA a SIP endpoint from UA1's point of view? In other
words, are the the "Require:" etc end-to-end headers sent by UA1,
meant for B2BUA or UA2?

Is the UAS part in in BtoBUA is bound by the definition and rules
in 3261?

thanks,
= Kedar =

> -----Original Message-----
> From: Adam Roach [mailto:adam@dynamicsoft.com]
> Sent: Tuesday, December 03, 2002 6:37 PM
> To: 'Padma Suresh'; vkg@lucent.com; pete@tech-know-ware.com
> Cc: sip@ietf.org
> Subject: RE: [Sip] B2BUA & Max-Forwards
>
>
> -----Original Message-----
> From: Padma Suresh [mailto:padma_suresh@hotmail.com]
> 
> > A B2BUA needs to propagate some of the headers received in a
> > request/response to the other endpoint. Example: Require...
>
> No. As emphatically as possible: NO. This is completely wrong,
> and it appears to be a growing -- and dangerous -- misconception.
>
> A B2BUA cannot transparently pass Require through. It must
> understand and invoke the extension indicated.
>
>   "The Require header field contains a list of option tags,
> described in
>    Section 19.2.  Each option tag defines a SIP extension that MUST be
>    understood to process the request."
>
> A back to back user agent *is* a UAS, and *is* bound by this
> provision.
>
> Whether the UAC portion then turns around and imposes the same
> requirement on the UAS it contacts is a local decision.
>
> /a
 

------_=_NextPart_001_01C29BB5.C9375DF0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Tue Dec 10 02:27:04 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00384 for ; Tue, 10 Dec 2002 02:27:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBA7TcC09880 for sip-archive@odin.ietf.org; Tue, 10 Dec 2002 02:29:38 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBA7QBv09720; Tue, 10 Dec 2002 02:26:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4NQ1v29377 for ; Wed, 4 Dec 2002 18:26:01 -0500 Received: from stamail.telecom.sna.samsung.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09990 for ; Wed, 4 Dec 2002 18:23:05 -0500 (EST) Received: by stamail.telecom.sna.samsung.com with Internet Mail Service (5.5.2653.19) id ; Wed, 4 Dec 2002 17:26:52 -0600 Message-ID: <4B9386E83999D411997100508BAF206A07C7B64E@stamail.telecom.sna.samsung.com> From: Kedar Patil To: "'Roy, Radhika R, ALASO'" Cc: sip@ietf.org, "'Adam Roach'" Subject: RE: [Sip] B2BUA & Max-Forwards Date: Wed, 4 Dec 2002 17:26:47 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C29BEC.9DAE7B00" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , 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_01C29BEC.9DAE7B00 Content-Type: text/plain; charset="iso-8859-1" > -----Original Message----- > From: Adam Roach [mailto:adam@dynamicsoft.com] > Sent: Wednesday, December 04, 2002 4:58 PM > To: 'Roy, Radhika R, ALASO'; Adam Roach > Cc: sip@ietf.org > Subject: RE: [Sip] B2BUA & Max-Forwards > > > > UAC(a)--->UAS(b)===[application logic here]===UAC(b)--->UAS(c) > > > > [RRR] I like to know who has been the called party when > > UAC(a)) sent the INVITE message? Has it been UAS(b) or UAS(c)? > > I'm going to first need to clarify your question. > > The question I will answer is: "If an INVITE is sent through the > network described in this diagram, what is the value of the > Request-URI when UAC(a) sends it?" > > The answer is: it depends. In general, yes, it will probably be > either of UAS(b) or UAS(c). > > > [RRR] If the answer is UAS(c), the question is: Why the call > > has been routed to UAS(b) by UAC(a) in the first place? > > The most obvious of several plausible answers is: UAC(a) > has UAS(b) configured as a local outbound proxy. Or most likely, when the INVITE request arrived at some outbound proxy of UAC(a), it decided to route the request to UAS(b) as a local polocy. This is possible irrespective of Request-URI and To: field. My 2-cents. thanks, = Kedar = > > > [RRR] If the answer is UAS(b), probably UAC(a) does not care. > > About what? > > /a > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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_01C29BEC.9DAE7B00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] B2BUA & Max-Forwards

> -----Original Message-----
> From: Adam Roach [mailto:adam@dynamicsoft.com]
> Sent: Wednesday, December 04, 2002 4:58 = PM
> To: 'Roy, Radhika R, ALASO'; Adam Roach
> Cc: sip@ietf.org
> Subject: RE: [Sip] B2BUA & = Max-Forwards
>
>
> > UAC(a)--->UAS(b)=3D=3D=3D[application = logic here]=3D=3D=3DUAC(b)--->UAS(c)
> >
> > [RRR] I like to know who has been the = called party when
> > UAC(a)) sent the INVITE message? Has it = been UAS(b) or UAS(c)?
>
> I'm going to first need to clarify your = question.
>
> The question I will answer is: "If an = INVITE is sent through the
> network described in this diagram, what is the = value of the
> Request-URI when UAC(a) sends it?"
>
> The answer is: it depends. In general, yes, it = will probably be
> either of UAS(b) or UAS(c).
>
> > [RRR] If the answer is UAS(c), the = question is: Why the call
> > has been routed to UAS(b) by UAC(a) in the = first place?
>
> The most obvious of several plausible answers = is: UAC(a)
> has UAS(b) configured as a local outbound = proxy.

Or most likely, when the INVITE request arrived at = some outbound
proxy of UAC(a), it decided to route the request to = UAS(b) as
a local polocy.

This is possible irrespective of Request-URI and To: = field.

My 2-cents.

thanks,
=3D Kedar =3D

>
> > [RRR] If the answer is UAS(b), probably = UAC(a) does not care.
>
> About what?
>
> /a
> = _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core = SIP 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_01C29BEC.9DAE7B00-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Tue Dec 10 02:27:07 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00403 for ; Tue, 10 Dec 2002 02:27:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBA7Tfa09892 for sip-archive@odin.ietf.org; Tue, 10 Dec 2002 02:29:41 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBA7QFv09739; Tue, 10 Dec 2002 02:26:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5I0Xv10271 for ; Thu, 5 Dec 2002 13:00:33 -0500 Received: from stamail.telecom.sna.samsung.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21476 for ; Thu, 5 Dec 2002 12:57:38 -0500 (EST) Received: by stamail.telecom.sna.samsung.com with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Dec 2002 12:01:26 -0600 Message-ID: <4B9386E83999D411997100508BAF206A07C7B657@stamail.telecom.sna.samsung.com> From: Kedar Patil To: "'Pete Cordell'" Cc: "David R. Oran" , Dean Willis , sip@ietf.org Subject: RE: [Sip] B2BUA & Max-Forwards Date: Thu, 5 Dec 2002 12:01:26 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C29C88.54622A40" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , 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_01C29C88.54622A40 Content-Type: text/plain; charset="iso-8859-1" Interesting. What if a BtoBUA(UAS side) received a request with Max-forward=0? A proxy would have responded with 483. I believe a B2BUA may not do the same. thanks, = Kedar = > -----Original Message----- > From: Pete Cordell [mailto:pete@tech-know-ware.com] > Sent: Thursday, December 05, 2002 11:24 AM > To: David R. Oran; Dean Willis; sip@ietf.org > Subject: Re: [Sip] B2BUA & Max-Forwards > > > Dave, > > To save your disagreeableness, can we say something like: > > "A B2BUA MUST perform loop prevention. One way to do this is > to propagate > the Max-Forwards header from the incoming request to the > outgoing request in > the same way that a proxy does." > > It's the loops that I'm worried about, not the Max-Forwards per se. > > This addresses my concern, and I think James' and possibly yours. > > Pete. > > ------_=_NextPart_001_01C29C88.54622A40 Content-Type: text/html; charset="iso-8859-1" RE: [Sip] B2BUA & Max-Forwards

Interesting.

What if a BtoBUA(UAS side) received a request with Max-forward=0?
A proxy would have responded with 483. I believe a B2BUA may not
do the same.

thanks,
= Kedar =


> -----Original Message-----
> From: Pete Cordell [mailto:pete@tech-know-ware.com]
> Sent: Thursday, December 05, 2002 11:24 AM
> To: David R. Oran; Dean Willis; sip@ietf.org
> Subject: Re: [Sip] B2BUA & Max-Forwards
>
>
> Dave,
>
> To save your disagreeableness, can we say something like:
>
> "A B2BUA MUST perform loop prevention.  One way to do this is
> to propagate
> the Max-Forwards header from the incoming request to the
> outgoing request in
> the same way that a proxy does."
>
> It's the loops that I'm worried about, not the Max-Forwards per se.
>
> This addresses my concern, and I think James' and possibly yours.
>
> Pete.
>
>

------_=_NextPart_001_01C29C88.54622A40-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Tue Dec 10 02:27:13 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00417 for ; Tue, 10 Dec 2002 02:27:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBA7TlM09906 for sip-archive@odin.ietf.org; Tue, 10 Dec 2002 02:29:47 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBA7Q8v09700; Tue, 10 Dec 2002 02:26:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4HDKv03928 for ; Wed, 4 Dec 2002 12:13:20 -0500 Received: from stamail.telecom.sna.samsung.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22333 for ; Wed, 4 Dec 2002 12:10:27 -0500 (EST) Received: by stamail.telecom.sna.samsung.com with Internet Mail Service (5.5.2653.19) id ; Wed, 4 Dec 2002 11:14:12 -0600 Message-ID: <4B9386E83999D411997100508BAF206A07C7B647@stamail.telecom.sna.samsung.com> From: Kedar Patil To: "'Jiri Kuthan'" , Phil Reynolds Cc: sip@ietf.org Subject: RE: [Sip] B2BUA Date: Wed, 4 Dec 2002 11:14:10 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C29BB8.8F952840" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , 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_01C29BB8.8F952840 Content-Type: text/plain BtoBUA need not always be call stateful. e.g. a SIP REGISTER request reaches a BtoBUA, it sends a new request to appropriate Registrar based on some local application specific configuration. There isn't any network state here (except the transaction state, like sip proxy). Pls. let me know, if you foresee any problem here. thanks, = Kedar = > -----Original Message----- > From: Jiri Kuthan [mailto:jiri@iptel.org] > Sent: Wednesday, December 04, 2002 8:16 AM > To: Phil Reynolds; sip@ietf.org > Subject: RE: [Sip] B2BUA > > > I think a better strategy to design reliable IP networks is not to > have stateful elements in the middle. It is sometimes not > easy to achieve, but you don't need to solve the problem what > happens when they fail. > > Besides that, all sort of middleboxes (B2BUA can IMHO be labeled > as app-layer middlebox) have e2e security issues as pointed out > by Christian, and are not free of scalability issues. > > I suggest you read RFC3234 -- it covers various issues middleboxes > have, including failure handling. > > -Jiri > ------_=_NextPart_001_01C29BB8.8F952840 Content-Type: text/html RE: [Sip] B2BUA

BtoBUA need not always be call stateful.
e.g. a SIP REGISTER request reaches a BtoBUA,
it sends a new request to appropriate Registrar
based on some local application specific
configuration.

There isn't any network state here (except the
transaction state, like sip proxy).

Pls. let me know, if you foresee any problem here.

thanks,
= Kedar =


> -----Original Message-----
> From: Jiri Kuthan [mailto:jiri@iptel.org]
> Sent: Wednesday, December 04, 2002 8:16 AM
> To: Phil Reynolds; sip@ietf.org
> Subject: RE: [Sip] B2BUA
>
>
> I think a better strategy to design reliable IP networks is not to
> have stateful elements in the middle. It is sometimes not
> easy to achieve, but you don't need to solve the problem what
> happens when they fail.
>
> Besides that, all sort of middleboxes (B2BUA can IMHO be labeled
> as app-layer middlebox) have e2e security issues as pointed out
> by Christian, and are not free of scalability issues.
>
> I suggest you read RFC3234 -- it covers various issues middleboxes
> have, including failure handling.
>
> -Jiri
>

------_=_NextPart_001_01C29BB8.8F952840-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Tue Dec 10 07:39:19 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05011 for ; Tue, 10 Dec 2002 07:39:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBACfj626286 for sip-archive@odin.ietf.org; Tue, 10 Dec 2002 07:41:45 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBACc7v26180; Tue, 10 Dec 2002 07:38:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBACauv25533 for ; Tue, 10 Dec 2002 07:36:56 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04967 for ; Tue, 10 Dec 2002 07:33:59 -0500 (EST) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id gBACaVjS028295; Tue, 10 Dec 2002 04:36:31 -0800 (PST) Received: from stealth-10-32-254-179.cisco.com (stealth-10-32-254-179.cisco.com [10.32.254.179]) by mira-sjc5-9.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with SMTP id EPE00117; Tue, 10 Dec 2002 04:37:14 -0800 (PST) Date: Tue, 10 Dec 2002 07:36:47 -0500 From: "David R. Oran" To: Kedar Patil cc: sip@ietf.org Subject: RE: [Sip] B2BUA & Max-Forwards Message-ID: <429826507.1039505807@[10.32.254.179]> In-Reply-To: <4B9386E83999D411997100508BAF206A07C7B646@stamail.telecom.sna.samsung.com> References: <4B9386E83999D411997100508BAF206A07C7B646@stamail.telecom.sna.sa msung.com> X-Mailer: Mulberry/3.0.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit --On Wednesday, December 04, 2002 10:54 AM -0600 Kedar Patil wrote: > > This discussion raises one more doubt for me, pls. clarify. > > UA1------->BtoBUA---------->UA2 > > Is the BtoBUA a SIP endpoint from UA1's point of view? Yes. Definintely. > In other > words, are the the "Require:" etc end-to-end headers sent by UA1, > meant for B2BUA or UA2? > It doesn't matter who they are "meant for". They MUST be processed and understood by B2BUA. Whatever UA2 sees is at the whim of the application on top of the UAS/UAC performing as the B2BUA. > Is the UAS part in in BtoBUA is bound by the definition and rules > in 3261? > Yes. Emphatically. > thanks, > = Kedar = > >> -----Original Message----- >> From: Adam Roach [mailto:adam@dynamicsoft.com] >> Sent: Tuesday, December 03, 2002 6:37 PM >> To: 'Padma Suresh'; vkg@lucent.com; pete@tech-know-ware.com >> Cc: sip@ietf.org >> Subject: RE: [Sip] B2BUA & Max-Forwards >> >> >> -----Original Message----- >> From: Padma Suresh [mailto:padma_suresh@hotmail.com] >> >> > A B2BUA needs to propagate some of the headers received in a >> > request/response to the other endpoint. Example: Require... >> >> No. As emphatically as possible: NO. This is completely wrong, >> and it appears to be a growing -- and dangerous -- misconception. >> >> A B2BUA cannot transparently pass Require through. It must >> understand and invoke the extension indicated. >> >> "The Require header field contains a list of option tags, >> described in >> Section 19.2. Each option tag defines a SIP extension that MUST be >> understood to process the request." >> >> A back to back user agent *is* a UAS, and *is* bound by this >> provision. >> >> Whether the UAC portion then turns around and imposes the same >> requirement on the UAS it contacts is a local decision. >> >> /a > ------------------------ David R. Oran Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 Office: +1 978 264 2048 VoIP: +1 408 571 4576 Email: oran@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 mailnull@www1.ietf.org Tue Dec 10 07:46:13 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05158 for ; Tue, 10 Dec 2002 07:46:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBACmdw26450 for sip-archive@odin.ietf.org; Tue, 10 Dec 2002 07:48:39 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBACjBv26402; Tue, 10 Dec 2002 07:45:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBACiKv26355 for ; Tue, 10 Dec 2002 07:44:20 -0500 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05067 for ; Tue, 10 Dec 2002 07:41:23 -0500 (EST) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id gBACiHKv026824; Tue, 10 Dec 2002 04:44:17 -0800 (PST) Received: from stealth-10-32-254-179.cisco.com (stealth-10-32-254-179.cisco.com [10.32.254.179]) by mira-sjc5-9.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with SMTP id EPE00227; Tue, 10 Dec 2002 04:44:39 -0800 (PST) Date: Tue, 10 Dec 2002 07:44:12 -0500 From: "David R. Oran" To: Kedar Patil cc: sip@ietf.org Subject: RE: [Sip] B2BUA Message-ID: <430270956.1039506252@[10.32.254.179]> In-Reply-To: <4B9386E83999D411997100508BAF206A07C7B647@stamail.telecom.sna.samsung.com> References: <4B9386E83999D411997100508BAF206A07C7B647@stamail.telecom.sna.sa msung.com> X-Mailer: Mulberry/3.0.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit --On Wednesday, December 04, 2002 11:14 AM -0600 Kedar Patil wrote: > > BtoBUA need not always be call stateful. Uh, on the contrary, since it has a UAS and a UAC, it most certainly has call (properly: dialog) state. > e.g. a SIP REGISTER request reaches a BtoBUA, > it sends a new request to appropriate Registrar > based on some local application specific > configuration. > > There isn't any network state here (except the > transaction state, like sip proxy). > Well, that's because REGISTER doesn't establish a dialog. > Pls. let me know, if you foresee any problem here. > Possibly, mostly having to do with security. As long as 3rd party REGISTERs work (i.e. somebody other than the contact being registered for the AOR doing the transaction), then this scenario should be no different. The operative condition though, is that the register comes from the B2BUA. From the point of view of the registrar it could just as we'll have been a mystical experience that caused the register to be sent by the B2BUA as some incoming register transaction. > thanks, > = Kedar = > >> -----Original Message----- >> From: Jiri Kuthan [mailto:jiri@iptel.org] >> Sent: Wednesday, December 04, 2002 8:16 AM >> To: Phil Reynolds; sip@ietf.org >> Subject: RE: [Sip] B2BUA >> >> >> I think a better strategy to design reliable IP networks is not to >> have stateful elements in the middle. It is sometimes not >> easy to achieve, but you don't need to solve the problem what >> happens when they fail. >> >> Besides that, all sort of middleboxes (B2BUA can IMHO be labeled >> as app-layer middlebox) have e2e security issues as pointed out >> by Christian, and are not free of scalability issues. >> >> I suggest you read RFC3234 -- it covers various issues middleboxes >> have, including failure handling. >> >> -Jiri ------------------------ David R. Oran Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 Office: +1 978 264 2048 VoIP: +1 408 571 4576 Email: oran@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 mailnull@www1.ietf.org Tue Dec 10 08:19:16 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05687 for ; Tue, 10 Dec 2002 08:19:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBADLhG28021 for sip-archive@odin.ietf.org; Tue, 10 Dec 2002 08:21:43 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBADHlv27866; Tue, 10 Dec 2002 08:17:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBADG8v27814 for ; Tue, 10 Dec 2002 08:16:08 -0500 Received: from mail-blue.research.att.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05569 for ; Tue, 10 Dec 2002 08:13:11 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 05EAE4D0BE; Tue, 10 Dec 2002 08:16:06 -0500 (EST) Received: from fish.research.att.com (fish.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id IAA13275; Tue, 10 Dec 2002 08:16:03 -0500 (EST) From: William Marshall Received: (from wtm@localhost) by fish.research.att.com (SGI-8.9.3/8.8.5) id IAA24955; Tue, 10 Dec 2002 08:22:26 -0500 (EST) Date: Tue, 10 Dec 2002 08:22:26 -0500 (EST) Message-Id: <200212101322.IAA24955@fish.research.att.com> To: oran@cisco.com Cc: kpatil@sta.samsung.com, sip@ietf.org Subject: RE: [Sip] B2BUA Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Dave Oran wrote: > wrote: > > > > BtoBUA need not always be call stateful. > Uh, on the contrary, since it has a UAS and a UAC, it most certainly has > call (properly: dialog) state. I think you're agruing details of semantics here. If the B2BUA has nothing stored itself that it needs to clean up when the call/dialog/ transaction completes, I'd call is stateless. However, it may have used a mechanism like what was defined in draft-ietf-sip-state to have that information stored somewhere else, or could have it encoded in the Contact header of the outgoing request, or numerous other valid hiding places. End result is a "stateful" box that is "stateless". The term looses meaning. Bill Marshall wtm@research.att.com -----original message----- Date: Tue, 10 Dec 2002 07:44:12 -0500 From: "David R. Oran" To: Kedar Patil Cc: sip@ietf.org Subject: RE: [Sip] B2BUA --On Wednesday, December 04, 2002 11:14 AM -0600 Kedar Patil wrote: > > BtoBUA need not always be call stateful. Uh, on the contrary, since it has a UAS and a UAC, it most certainly has call (properly: dialog) state. > e.g. a SIP REGISTER request reaches a BtoBUA, > it sends a new request to appropriate Registrar > based on some local application specific > configuration. > > There isn't any network state here (except the > transaction state, like sip proxy). > Well, that's because REGISTER doesn't establish a dialog. > Pls. let me know, if you foresee any problem here. > Possibly, mostly having to do with security. As long as 3rd party REGISTERs work (i.e. somebody other than the contact being registered for the AOR doing the transaction), then this scenario should be no different. The operative condition though, is that the register comes from the B2BUA. From the point of view of the registrar it could just as we'll have been a mystical experience that caused the register to be sent by the B2BUA as some incoming register transaction. > thanks, > = Kedar = > >> -----Original Message----- >> From: Jiri Kuthan [mailto:jiri@iptel.org] >> Sent: Wednesday, December 04, 2002 8:16 AM >> To: Phil Reynolds; sip@ietf.org >> Subject: RE: [Sip] B2BUA >> >> >> I think a better strategy to design reliable IP networks is not to >> have stateful elements in the middle. It is sometimes not >> easy to achieve, but you don't need to solve the problem what >> happens when they fail. >> >> Besides that, all sort of middleboxes (B2BUA can IMHO be labeled >> as app-layer middlebox) have e2e security issues as pointed out >> by Christian, and are not free of scalability issues. >> >> I suggest you read RFC3234 -- it covers various issues middleboxes >> have, including failure handling. >> >> -Jiri ------------------------ David R. Oran Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 Office: +1 978 264 2048 VoIP: +1 408 571 4576 Email: oran@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 mailnull@www1.ietf.org Tue Dec 10 14:28:04 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18371 for ; Tue, 10 Dec 2002 14:28:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBAJUYK22451 for sip-archive@odin.ietf.org; Tue, 10 Dec 2002 14:30:34 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBAJOnv22228; Tue, 10 Dec 2002 14:24:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBAJNbv22159 for ; Tue, 10 Dec 2002 14:23:37 -0500 Received: from dyn-tx-arch-crash.dfw.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18245; Tue, 10 Dec 2002 14:20:37 -0500 (EST) Received: from RjS.localdomain (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id gBAJNUI23012; Tue, 10 Dec 2002 13:23:30 -0600 From: Robert Sparks To: sip@ietf.org, simple@ietf.org, sip-implementors@cs.columbia.edu Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 10 Dec 2002 13:21:53 -0600 Message-Id: <1039548113.944.40.camel@RjS.localdomain> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: [Sip] Reminder: SIPit 12 Registration Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit The 12th SIPit will be hosted by Hotsip in Stockholm February 24-28, 2003. Please see http://www.hotsip.com/sipit12/ for details and registration. Registration closes January 20. 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 mailnull@www1.ietf.org Wed Dec 11 03:32:24 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28748 for ; Wed, 11 Dec 2002 03:32:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBB8Yx009784 for sip-archive@odin.ietf.org; Wed, 11 Dec 2002 03:34:59 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBB8K5v09463; Wed, 11 Dec 2002 03:20:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBB8Esv09299 for ; Wed, 11 Dec 2002 03:14:54 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28584 for ; Wed, 11 Dec 2002 03:11:47 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gBB8EfQ1012191; Wed, 11 Dec 2002 09:14:41 +0100 (MET) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id YCD5JVWS; Wed, 11 Dec 2002 09:14:41 +0100 Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.68]) by hendrix.lmf.ericsson.se (8.12.6/8.12.6/lmf-2.1-jcs) with ESMTP id gBB8Eeu4018697; Wed, 11 Dec 2002 10:14:40 +0200 (EET) Message-ID: <3DF6F3F0.9D2182B@lmf.ericsson.se> Date: Wed, 11 Dec 2002 10:14:40 +0200 X-Sybari-Trust: c0d558f9 ca231590 9555c2c6 00000138 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Robert Sparks CC: Jonathan Rosenberg , sip@ietf.org Subject: Re: [Sip] ABNF issue References: <3DEF27BE.80ED31E2@lmf.ericsson.se> <3DEF7F8D.70902@dynamicsoft.com> <3DEFCF15.3C381C9F@lmf.ericsson.se> <3DF03D40.2030608@dynamicsoft.com> <3DF4433B.B180D38@lmf.ericsson.se> <1039447778.918.34.camel@RjS.localdomain> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, > Blindly doing a reverse token substitution will produce an incorrect > parse. You can only apply it when you have proven the left side of > the rule fits in a valid parse of the message. [CHH] Correct. And, I "shift" a message-header when I have found one CRLF (the end of the header). After that I'm done with that header. After that I continue parsing, and if the previous message-header was the last one I expect to parse a second CRLF, to indentify the end of the SIP header part of the message. So far I agree. What we disagree on is the fact that you say that now the definition of LWS is not valid anymore (even if we are still parsing the SIP part of the message), and that in this case a CRLF is a CRLF - no matter what comes after it. > So from your original example. LWS is not defined inside a body - the > body is just a sequence of octets from the perspective of the SIP > grammar. Your SIP parser _cannot_ apply a match against LWS inside it - > there is no valid expansion of the SIP grammar that has LWS appearing > after CRLF CRLF [CHH] I don't think there is such thing as CRLF CRLF in the current SIP grammar (it used to be before, though, I think). Again, the message-header is shifted once I found one CRLF, so there will be no CRLF CRLF shift. > >>The BNF specifies that message-header ends with a CRLF. > > > >Yes. > > > >>What follows that is one of two things - either another CRLF, marking the end > >>of the headers, or another message header, which never begins with LWS. > > > >>From a SIP grammar point of view that is correct. However, I don't see it said > >>anywhere that the definition of LWS isn't valid at the beginning of a new line. > > It _is_ valid after CRLF (which is what I think you mean by a new line) > if (and only if) you are still in the expansion of message-header. [CHH] That is what I am asking: where is it said that LWS is only valid within the context of a message-header? I do agree that LWS is not valid within the message-body part of the message, once we get there, but I see it nowhere said that I can't parse a LWS AFTER I've shifted a message-header, when I'm still in the SIP part of the message. No, the SIP grammar may not allow it, and we may return a parser error, but that is a separate issue. > >Also, just for the record, where is it said that a sip-header can't start with > >LWS? Where is it said that line folding can't be used at the beginning of a line? > >The text only says that the sip-header field values can be folded onto multiple > >lines. > I don't know what you mean by beginning of a line here. I assume you are > asking why we cant have a header that looks like (\b for blank): > \b\bNewHeader: foo which is a "\b\bNewheader"? > > The grammar answers that. extension-header starts with a token. [CHH] Of course the LWS would not be part of the message-header grammar itself. LWS is not even part of the message-header grammar within a header (ie the SIP grammar doesn't require any LWS to be parsed). The grammar only says that LWS can be used message-header parts for line folding, but it's not part of the grammar. Let's take an example: INVITE sip:12345@sip.com SIP/2.0 Call-ID: 67890@sip.com CSeq: 100 INVITE Now, the parser shifts the Call-ID header when it has found CRLF_2. Then, it finds CRLF_3 and SP_1, and returns LWS. So, there is a line-folding before the beginning of the CSeq header. Again, the LWS is NOT part of the CSeq header itself, but my question is: where is it said that this LWS is NOT allowed at the beginning of a line, before the actual message-header, but only WITHIN a message-header? Have I missed it in the text? > >>Thus, if a CRLF is followed by something OTHER than WSP, the next construction > >>cannot be LWS. > > > >Maybe I missunderstand you, but the case I try to describe is when the CRLF IS > >followed by WSP. > If its in a valid expansion of message-header (which will not happen > across a CRLFCRLF string), then you are looking at LWS. [CHH] I may be wrong, but again I don't think there is such a thing as CRLFCRLF (DOUBLE-CRLF) in the current SIP grammar. Each CRLF is treated separately, and if there is another CRLF after a message-header has been shifted we have found the end of the SIP part of the message. I don't argue on that point. My issue is, that once we've shifted a message-header, why isn't the definition of LWS valid anymore, since we still are parsing the SIP part of the message? > The _only_ place that second CRLF matches in the grammar is the literal in > the Request and Response rules. [CHH] Again, the point is not where it matches in the grammar. I am not talking about the SIP grammar, but of the definition of the parts/tokens building the grammar. > So for your example, any whitespace following that second CRLF matches message-body = > *OCTET, NOT LWS. [CHH] Again, I don't think we have any token called the "second CRLF" in the SIP grammar. I also think it's important to have a look at the definition of OCTET. RFC2234 says: OCTET = %x00-FF SP = %x20 Now, if we say that CRLF/SP is LWS, but that CRLF/OCTET is not LWS, don't we have a conflict here, since %x20 is part of both SP and OCTET? Anyway, I don't want to go on with this argument forever. I am not an ABNF expert, and it is possible to fix this on the implementation level, so... Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Wed Dec 11 04:21:34 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29338 for ; Wed, 11 Dec 2002 04:21:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBB9OAQ12931 for sip-archive@odin.ietf.org; Wed, 11 Dec 2002 04:24:10 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBB97hv12379; Wed, 11 Dec 2002 04:07:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBB96Wv11709 for ; Wed, 11 Dec 2002 04:06:32 -0500 Received: from carbon.btinternet.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29189 for ; Wed, 11 Dec 2002 04:03:24 -0500 (EST) Received: from host213-122-174-221.in-addr.btopenworld.com ([213.122.174.221] helo=tkw) by carbon.btinternet.com with smtp (Exim 3.22 #16) id 18M2ol-0006pO-00; Wed, 11 Dec 2002 09:06:12 +0000 Message-ID: <001d01c2a0f4$2025ae80$0200000a@tkw> From: "Pete Cordell" To: "Jonathan Rosenberg" Cc: References: <3DF4E300.90909@dynamicsoft.com> Subject: Re: [Sip] B2BUA - Security Date: Wed, 11 Dec 2002 09:03:00 -0000 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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit OK - I'll go through some scenarios (host is agent, 'proxy' is agent, NAT only, firewall only, NAT & firewall) and derive some requirements that Midcom desires of SIP. I assume these are application specific requirements which will be generalised in a future round of development. Is that the correct way to do it? Pete. (to: and cc: list pruned in case it looks like spam!) ----- Original Message ----- From: "Jonathan Rosenberg" To: "Mark Watson" Cc: "'Rohan Mahy'" ; "Mahey, Sonit" ; "Pete Cordell" ; "Christian Huitema" ; Sent: 09 December 2002 18:37 Subject: Re: [Sip] B2BUA - Security > inline. > > Mark Watson wrote: > > Rohan wrote: > > > > > In addition to Jonathan's approach to session policy, there is no > > > reason a middlebox controller can't be a proxy if it: > > > > > > 1. opens pinholes referenced in a clear text or integrity > > > protected SDP > > > 2. rejects requests with no readable SDP (the UA could > > > instead include > > > a full SDP, with keying material, encrypted with SMIME, ****and an > > > abbreviated copy which is only integrity protected****). > > > > > > I was about to write a draft suggesting exactly this. > > THis is simply not sufficient. > > It will suffice for firewalls, but not for NAT, where an actual > modification needs to occur. > > I think that, per Pete's suggestion, the correct path forward is a > requirements document that describes the problem and the requirements > for the solution. I believe there are many interesting requirements here > about disclosure of what is being done, that will strongly impact the > solution. > > > > > As per Jonathan's draft there is a need for the UA to be able to > > 'declare' to network entities those parts of the SDP information which > > are needed for the network entity to perform whatever service it > > performs (e.g. NAT or Firewall control). But the UA should not have to > > declare the whole SDP, and the terminating UA should be able to tell if > > a network entity has modified these parameters. > > Sounds like we are beginning the requirements work here... > > > > > Rather than putting this information into new SIP headers, we could > > include two copies of the SDP. One copy is unprotected and contains only > > the information that the UE wishes to 'declare' to the network entities. > > The other copy is protected and contains the full information. > > I think we can leave the header/body debate for down the road. I would > be happy if we can get agreement on this general problem as one that we > need to solve. > > > > > This approach would work through existing devices which inspect/modify SDP. > > > > I'm not sure how an existing S/MIME compliant client would behave on > > receiving these two copies. If it uses the unprotected SDP, then things > > are no worse than the present situation - the call suceeds, but without > > the advantages of S/MIME. If it uses the protected SDP (which has not > > been modified by the NAT controlling device), then the call fails, but > > this is still no worse than the present situation. > > It comes down to disclosure. The message needs to convey information > about the meaning of the multiple session descriptions - who set which, > and why. > > -Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.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 mailnull@www1.ietf.org Wed Dec 11 04:24:14 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29415 for ; Wed, 11 Dec 2002 04:24:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBB9QpG13067 for sip-archive@odin.ietf.org; Wed, 11 Dec 2002 04:26:51 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBB9GKv12655; Wed, 11 Dec 2002 04:16:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBB9Fcv12622 for ; Wed, 11 Dec 2002 04:15:38 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29268 for ; Wed, 11 Dec 2002 04:12:29 -0500 (EST) From: hisham.khartabil@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gBB9GiW20521 for ; Wed, 11 Dec 2002 11:16:44 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 11 Dec 2002 11:15:23 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 11 Dec 2002 11:15:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] ABNF issue Date: Wed, 11 Dec 2002 11:15:23 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE7070@esebe019.ntc.nokia.com> Thread-Topic: [Sip] ABNF issue Thread-Index: AcKg74Lklco5HbkFTP6e0Wyu9PjeyAABV9bA To: , Cc: , X-OriginalArrivalTime: 11 Dec 2002 09:15:23.0887 (UTC) FILETIME=[D6141FF0:01C2A0F5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gBB9Fcv12623 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit CRLF/WSP is definitely a LWS, but you have to realise that the second CRLF signals the end of the SIP headers. The WSP that follows is part of the body so you can't combine the CRLF (that is part of the headers) and the WSP (which is part of the body) as a LWS sipheader:value/CRLF/CRLF/WSP ^ | | sip headers end. WSP is sent to the body parser (which is presumably a separate one from the sip parser) Regards, Hisham > -----Original Message----- > From: ext Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: Wednesday, December 11, 2002 10:15 AM > To: Robert Sparks > Cc: Jonathan Rosenberg; sip@ietf.org > Subject: Re: [Sip] ABNF issue > > > > Hi, > > > Blindly doing a reverse token substitution will produce an incorrect > > parse. You can only apply it when you have proven the left side of > > the rule fits in a valid parse of the message. > > [CHH] Correct. And, I "shift" a message-header when I have > found one CRLF (the end of > the header). After that I'm done with that header. After that > I continue parsing, and > if the previous message-header was the last one I expect to > parse a second CRLF, to > indentify the end of the SIP header part of the message. So > far I agree. What we > disagree on is the fact that you say that now the definition > of LWS is not valid > anymore (even if we are still parsing the SIP part of the > message), and that in this > case a CRLF is a CRLF - no matter what comes after it. > > > So from your original example. LWS is not defined inside a > body - the > > body is just a sequence of octets from the perspective of the SIP > > grammar. Your SIP parser _cannot_ apply a match against LWS > inside it - > > there is no valid expansion of the SIP grammar that has LWS > appearing > > after CRLF CRLF > > [CHH] I don't think there is such thing as CRLF CRLF in the > current SIP grammar (it > used to be before, though, I think). Again, the > message-header is shifted once I found > one CRLF, so there will be no CRLF CRLF shift. > > > >>The BNF specifies that message-header ends with a CRLF. > > > > > >Yes. > > > > > >>What follows that is one of two things - either another > CRLF, marking the end > > >>of the headers, or another message header, which never > begins with LWS. > > > > > >>From a SIP grammar point of view that is correct. > However, I don't see it said > > >>anywhere that the definition of LWS isn't valid at the > beginning of a new line. > > > > It _is_ valid after CRLF (which is what I think you mean by > a new line) > > if (and only if) you are still in the expansion of message-header. > > [CHH] That is what I am asking: where is it said that LWS is > only valid within the > context of a message-header? > > I do agree that LWS is not valid within the message-body part > of the message, once we > get there, but I see it nowhere said that I can't parse a LWS > AFTER I've shifted a > message-header, when I'm still in the SIP part of the > message. No, the SIP grammar may > not allow it, and we may return a parser error, but that is a > separate issue. > > > >Also, just for the record, where is it said that a > sip-header can't start with > > >LWS? Where is it said that line folding can't be used at > the beginning of a line? > > >The text only says that the sip-header field values can be > folded onto multiple > > >lines. > > I don't know what you mean by beginning of a line here. I > assume you are > > asking why we cant have a header that looks like (\b for blank): > > \b\bNewHeader: foo which is a "\b\bNewheader"? > > > > The grammar answers that. extension-header starts with a token. > > [CHH] Of course the LWS would not be part of the > message-header grammar itself. LWS is > not even part of the message-header grammar within a header > (ie the SIP grammar doesn't > require any LWS to be parsed). The grammar only says that LWS > can be used > message-header parts for line folding, but it's not part of > the grammar. > > Let's take an example: > > INVITE sip:12345@sip.com SIP/2.0 > Call-ID: 67890@sip.com > > CSeq: 100 INVITE > > Now, the parser shifts the Call-ID header when it has found CRLF_2. > > Then, it finds CRLF_3 and SP_1, and returns LWS. So, there is > a line-folding before the > beginning of the CSeq header. Again, the LWS is NOT part of > the CSeq header itself, but > my question is: where is it said that this LWS is NOT allowed > at the beginning of a > line, before the actual message-header, but only WITHIN a > message-header? Have I missed > it in the text? > > > >>Thus, if a CRLF is followed by something OTHER than WSP, > the next construction > > >>cannot be LWS. > > > > > >Maybe I missunderstand you, but the case I try to describe > is when the CRLF IS > > >followed by WSP. > > If its in a valid expansion of message-header (which will not happen > > across a CRLFCRLF string), then you are looking at LWS. > > [CHH] I may be wrong, but again I don't think there is such a > thing as CRLFCRLF > (DOUBLE-CRLF) in the current SIP grammar. > > Each CRLF is treated separately, and if there is another CRLF > after a message-header > has been shifted we have found the end of the SIP part of the > message. I don't argue on > that point. > > My issue is, that once we've shifted a message-header, why > isn't the definition of LWS > valid anymore, since we still are parsing the SIP part of the message? > > > The _only_ place that second CRLF matches in the grammar is > the literal in > > the Request and Response rules. > > [CHH] Again, the point is not where it matches in the > grammar. I am not talking about > the SIP grammar, but of the definition of the parts/tokens > building the grammar. > > > So for your example, any whitespace following that second > CRLF matches message-body = > > *OCTET, NOT LWS. > > [CHH] Again, I don't think we have any token called the > "second CRLF" in the SIP > grammar. > > I also think it's important to have a look at the definition > of OCTET. RFC2234 says: > > OCTET = %x00-FF > > SP = %x20 > > Now, if we say that CRLF/SP is LWS, but that CRLF/OCTET is > not LWS, don't we have a > conflict here, since %x20 is part of both SP and OCTET? > > Anyway, I don't want to go on with this argument forever. I > am not an ABNF expert, and > it is possible to fix this on the implementation level, so... > > Regards, > > Christer Holmberg > Ericsson Finland > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Wed Dec 11 04:48:47 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29815 for ; Wed, 11 Dec 2002 04:48:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBB9pN714768 for sip-archive@odin.ietf.org; Wed, 11 Dec 2002 04:51:23 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBB9jWv14568; Wed, 11 Dec 2002 04:45:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBB9gXv14415 for ; Wed, 11 Dec 2002 04:42:33 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29687 for ; Wed, 11 Dec 2002 04:39:25 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gBB9gJQ1006813; Wed, 11 Dec 2002 10:42:19 +0100 (MET) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id YBCP3S5R; Wed, 11 Dec 2002 10:42:19 +0100 Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.68]) by hendrix.lmf.ericsson.se (8.12.6/8.12.6/lmf-2.1-jcs) with ESMTP id gBB9gJu4024452; Wed, 11 Dec 2002 11:42:19 +0200 (EET) Message-ID: <3DF7087B.44B815ED@lmf.ericsson.se> Date: Wed, 11 Dec 2002 11:42:19 +0200 X-Sybari-Trust: b638a2f5 ca231590 9555c2c6 00000138 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: rsparks@dynamicsoft.com, jdrosen@dynamicsoft.com, sip@ietf.org Subject: Re: [Sip] ABNF issue References: <2038BCC78B1AD641891A0D1AE133DBB7FE7070@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, > CRLF/WSP is definitely a LWS, but you have to realise that the second CRLF signals the end of the SIP headers. The WSP that follows is part of the body so you can't combine the CRLF (that is part of the headers) and the WSP (which is part of the body) as a LWS > > sipheader:value/CRLF/CRLF/WSP > ^ > | > | > sip headers end. WSP is sent to the body parser (which is presumably a separate one from the sip parser) What you say would work very fine, but that is not how the grammar is defined today. Please correct me if I'm wrong, but there is no CRLF/CRLF/WSP token defined in the grammar today. YES, you can do this in your implementation, so that is not the problem. My original question was if there is a bug in the spec or not. Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Wed Dec 11 06:43:18 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01860 for ; Wed, 11 Dec 2002 06:43:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBBBjhL21424 for sip-archive@odin.ietf.org; Wed, 11 Dec 2002 06:45:43 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBBBZ4v20436; Wed, 11 Dec 2002 06:35:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBBBVNv20294 for ; Wed, 11 Dec 2002 06:31:23 -0500 Received: from NREXCH.netrake.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01582 for ; Wed, 11 Dec 2002 06:28:28 -0500 (EST) content-class: urn:content-classes:message Subject: RE: [Sip] ABNF issue MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 11 Dec 2002 05:31:21 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Message-ID: <7E06D3212981524CA10D2A114937C414014949A7@nrexch.netrake.net> Thread-Topic: [Sip] ABNF issue Thread-Index: AcKg/25bVDndl/hiRXypijpIIiz2TQACJxvw From: "Rob Phillips" To: "Christer Holmberg" , Cc: , , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gBBBVNv20295 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit I would argue that the grammar is not ambiguous when taken in context. Refer the ABNF and text in section 7: generic-message = start-line *message-header CRLF [ message-body ] start-line = Request-Line / Status-Line The start-line, each message-header line, and the empty line MUST be terminated by a carriage-return line-feed sequence (CRLF). Note that the empty line MUST be present even if the message-body is not. As has been shown before, you can't always take the ABNF in a vacuum - the context found in the rest of the RFC can often narrow what's allowed by the protocol, even when the ABNF says it's "legal". - rob -- Rob Phillips, Sr. Software Engineer Netrake Corporation mailto: rob@netrake.com 3000 Technology Drive voice: (214) 291-1096 Suite 100 fax: (214) 291-1010 http://www.netrake.com Plano, Texas 75074 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Wed Dec 11 07:02:31 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02156 for ; Wed, 11 Dec 2002 07:02:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBBC4ux21942 for sip-archive@odin.ietf.org; Wed, 11 Dec 2002 07:04:56 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBBBtMv21688; Wed, 11 Dec 2002 06:55:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBBBomv21572 for ; Wed, 11 Dec 2002 06:50:48 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01908 for ; Wed, 11 Dec 2002 06:47:52 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gBBBokKV016094; Wed, 11 Dec 2002 12:50:46 +0100 (MET) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id YV61GL1B; Wed, 11 Dec 2002 12:50:46 +0100 Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.68]) by hendrix.lmf.ericsson.se (8.12.6/8.12.6/lmf-2.1-jcs) with ESMTP id gBBBoku4002508; Wed, 11 Dec 2002 13:50:46 +0200 (EET) Message-ID: <3DF72695.68E9B83B@lmf.ericsson.se> Date: Wed, 11 Dec 2002 13:50:46 +0200 X-Sybari-Trust: 39184b17 ca231590 9555c2c6 00000138 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Rob Phillips CC: hisham.khartabil@nokia.com, rsparks@dynamicsoft.com, jdrosen@dynamicsoft.com, sip@ietf.org Subject: Re: [Sip] ABNF issue References: <7E06D3212981524CA10D2A114937C414014949A7@nrexch.netrake.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Rob, > I would argue that the grammar is not ambiguous when taken in context. Refer the ABNF and text in section 7: > > generic-message = start-line > *message-header > CRLF > [ message-body ] > start-line = Request-Line / Status-Line > > The start-line, each message-header line, and the empty line MUST be > terminated by a carriage-return line-feed sequence (CRLF). Note that > the empty line MUST be present even if the message-body is not. Yes. > As has been shown before, you can't always take the ABNF in a vacuum - the context found in the rest of the RFC can often narrow what's allowed by the protocol, even when the ABNF says it's "legal". I FULLY agree. But, in those cases you have to specify the things in the spec. Now the spec only says that the SIP part of the message ends with CRLF, and that is not the issue. IF the spec would "narrow" the ABNF rules by saying that the definition of LWS is not valid in the beginning of a new line, OR if the spec would define the CRLFCRLF token, we would not have this problem. Regards, Christer Holmberg Ericsson Finland > > > - rob > > -- > Rob Phillips, Sr. Software Engineer Netrake Corporation > mailto: rob@netrake.com 3000 Technology Drive > voice: (214) 291-1096 Suite 100 > fax: (214) 291-1010 http://www.netrake.com Plano, Texas 75074 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Wed Dec 11 07:22:02 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02526 for ; Wed, 11 Dec 2002 07:22:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBBCORe23163 for sip-archive@odin.ietf.org; Wed, 11 Dec 2002 07:24:27 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBBCB6v22775; Wed, 11 Dec 2002 07:11:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBBC89v22674 for ; Wed, 11 Dec 2002 07:08:09 -0500 Received: from NREXCH.netrake.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02214 for ; Wed, 11 Dec 2002 07:05:13 -0500 (EST) content-class: urn:content-classes:message Subject: RE: [Sip] ABNF issue MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 11 Dec 2002 06:08:07 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Message-ID: <7E06D3212981524CA10D2A114937C414014949A8@nrexch.netrake.net> Thread-Topic: [Sip] ABNF issue Thread-Index: AcKhC4/gdmEILP1dSgymUDNOruve0QAAGDkw From: "Rob Phillips" To: "Christer Holmberg" Cc: , , , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gBBC89v22675 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Christer Holmberg writes: > IF the spec would "narrow" the ABNF rules by saying that the definition > of LWS is not valid in the beginning of a new line, OR if the spec > would define the CRLFCRLF token, we would not have this problem. I guess the way I read generic-message = start-line *message-header CRLF [ message-body ] the spec essentially DOES define a defacto CRLF-CRLF token (if not in ABNF) by saying that: 1. All message headers end with CRLF, and 2. When another CRLF follows directly thereafter, that marks the end of the message headers and the beginning of the message body (if any). So that in taking your example: INVITE sip:12345@sip.com SIP/2.0 Call-ID: 67890@sip.com CSeq: 100 INVITE the precedence rules for interpreting CRLF_2-CRLF_3-SP_1 have to be treated as (CRLF_2-CRLF_3) SP_1 "end of headers" instead of CRLF_2 (CRLF_3-SP_1) "CRLF LWS" - rob _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Wed Dec 11 08:02:24 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03110 for ; Wed, 11 Dec 2002 08:02:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBBD4o425016 for sip-archive@odin.ietf.org; Wed, 11 Dec 2002 08:04:50 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBBCjQv24361; Wed, 11 Dec 2002 07:45:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBBCfbv24258 for ; Wed, 11 Dec 2002 07:41:37 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02762 for ; Wed, 11 Dec 2002 07:38:40 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gBBCfWQ1022318; Wed, 11 Dec 2002 13:41:32 +0100 (MET) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id YRS3JYCP; Wed, 11 Dec 2002 13:41:32 +0100 Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.68]) by hendrix.lmf.ericsson.se (8.12.6/8.12.6/lmf-2.1-jcs) with ESMTP id gBBCfWu4005571; Wed, 11 Dec 2002 14:41:32 +0200 (EET) Message-ID: <3DF7327C.76E2E96B@lmf.ericsson.se> Date: Wed, 11 Dec 2002 14:41:32 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Rob Phillips CC: hisham.khartabil@nokia.com, rsparks@dynamicsoft.com, jdrosen@dynamicsoft.com, sip@ietf.org Subject: Re: [Sip] ABNF issue References: <7E06D3212981524CA10D2A114937C414014949A8@nrexch.netrake.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Rob, > > IF the spec would "narrow" the ABNF rules by saying that the definition > > of LWS is not valid in the beginning of a new line, OR if the spec > > would define the CRLFCRLF token, we would not have this problem. > > I guess the way I read > > generic-message = start-line > *message-header > CRLF > [ message-body ] > > the spec essentially DOES define a defacto CRLF-CRLF token (if not in ABNF) by saying that: > 1. All message headers end with CRLF, and > 2. When another CRLF follows directly thereafter, that marks the end of the message headers and the beginning of the message body (if any). This "directly after" is part of what confuses me. To me it still sounds like a separate token, ie not a single CRLF-CRLF token. Anyway, if I am the onlyone who understands in a different way there is no idea to continue arguing about it. Also, if everybody also agree on what is said below, ie that a SIP header always must start at the beginning of a new line, there are no conflicts. > So that in taking your example: > > INVITE sip:12345@sip.com SIP/2.0 > Call-ID: 67890@sip.com > > CSeq: 100 INVITE > > the precedence rules for interpreting CRLF_2-CRLF_3-SP_1 have to be treated as > (CRLF_2-CRLF_3) SP_1 "end of headers" > instead of > CRLF_2 (CRLF_3-SP_1) "CRLF LWS" So, this means that is not possible to use line folding before the first token (the header name) of a header, since assuming that the "directly after" rule really means a CRLF-CRLF token the parser will assume it has found the end of the SIP part (due to the CRLF_2-CRLF_3) token, and and the CSeq header will be treated as part of the message-body. In this case, I think it is important to note that a SIP header MUST start at the BEGINNING of a new line. I think is said in the SDP spec, for the SDP parameters, but not in the SIP spec for the SIP headers, is it? Also, H.248 explicitly says when something must be at the beginning of a new line, and when SP eg is allowed. Maybe this is something that could be tested at SIPit, or at least added to the torture test document? Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Wed Dec 11 09:13:43 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05965 for ; Wed, 11 Dec 2002 09:13:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBBEGAp29690 for sip-archive@odin.ietf.org; Wed, 11 Dec 2002 09:16:10 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBBE1kv28580; Wed, 11 Dec 2002 09:01:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBBDvAv28309 for ; Wed, 11 Dec 2002 08:57:10 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05170 for ; Wed, 11 Dec 2002 08:54:12 -0500 (EST) From: hisham.khartabil@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gBBDwRW14109 for ; Wed, 11 Dec 2002 15:58:27 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 11 Dec 2002 15:57:06 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 11 Dec 2002 15:57:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] ABNF issue Date: Wed, 11 Dec 2002 15:57:04 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE707C@esebe019.ntc.nokia.com> Thread-Topic: [Sip] ABNF issue Thread-Index: AcKhEqbN5aIC28SqTxuX2wfGCDIb/wACoJBw To: , Cc: , , X-OriginalArrivalTime: 11 Dec 2002 13:57:05.0857 (UTC) FILETIME=[30701310:01C2A11D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gBBDvAv28310 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit > -----Original Message----- > From: ext Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: Wednesday, December 11, 2002 2:42 PM > To: Rob Phillips > Cc: Khartabil Hisham (NMP/Helsinki); rsparks@dynamicsoft.com; > jdrosen@dynamicsoft.com; sip@ietf.org > Subject: Re: [Sip] ABNF issue > > In this case, I think it is important to note that a SIP > header MUST start at the BEGINNING of a new line. Header fields can be extended over multiple lines by preceding each extra line with at least one SP or horizontal tab (HT). Also, in RFC2822: "Messages are divided into lines of characters. A line is a series of characters that is delimited with the two characters carriage-return and line-feed; that is, the carriage return (CR) character (ASCII value 13) followed immediately by the line feed (LF) character (ASCII value 10). (The carriage-return/line-feed pair is usually written in this document as "CRLF".) A message consists of header fields (collectively called "the header of the message") followed, optionally, by a body. ... Header fields are lines composed of a field name, followed by a colon (":"), followed by a field body, and terminated by CRLF. A field name MUST be composed of printable US-ASCII characters (i.e., characters that have values between 33 and 126, inclusive), except colon. " No header name is allowed a CR or LF in it,and certainly no sip header has CRLF included in its name. Regards, Hisham > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Wed Dec 11 09:31:50 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06682 for ; Wed, 11 Dec 2002 09:31:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBBEYHb30639 for sip-archive@odin.ietf.org; Wed, 11 Dec 2002 09:34:17 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBBEQ2v30176; Wed, 11 Dec 2002 09:26:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBBELqv29916 for ; Wed, 11 Dec 2002 09:21:52 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06143 for ; Wed, 11 Dec 2002 09:18:54 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gBBELnQ1019172; Wed, 11 Dec 2002 15:21:49 +0100 (MET) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id YV61H3X4; Wed, 11 Dec 2002 15:21:48 +0100 Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.68]) by hendrix.lmf.ericsson.se (8.12.6/8.12.6/lmf-2.1-jcs) with ESMTP id gBBELnu4012008; Wed, 11 Dec 2002 16:21:49 +0200 (EET) Message-ID: <3DF749FC.4F7FC89@lmf.ericsson.se> Date: Wed, 11 Dec 2002 16:21:49 +0200 X-Sybari-Trust: c3e79d51 ca231590 a609720c 00000138 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: rob@netrake.com, rsparks@dynamicsoft.com, jdrosen@dynamicsoft.com, sip@ietf.org Subject: Re: [Sip] ABNF issue References: <2038BCC78B1AD641891A0D1AE133DBB7FE707C@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, > >In this case, I think it is important to note that a SIP header MUST start at the BEGINNING of a new line. > > Header fields can be extended over multiple lines by preceding each extra line with at least one SP or horizontal tab (HT). That's line folding, which is a separate issue. What I said was that the START of the header MUST be at the BEGINNING of a new line, no matter if the rest of the header is then folded/extended over multiple lines. > Also, in RFC2822: > > "Messages are divided into lines of characters. A line is a series of > characters that is delimited with the two characters carriage-return > and line-feed; that is, the carriage return (CR) character (ASCII > value 13) followed immediately by the line feed (LF) character (ASCII > value 10). (The carriage-return/line-feed pair is usually written in > this document as "CRLF".) > > A message consists of header fields (collectively called "the header > of the message") followed, optionally, by a body. > > ... > > Header fields are lines composed of a field name, followed by a colon > (":"), followed by a field body, and terminated by CRLF. A field > name MUST be composed of printable US-ASCII characters (i.e., > characters that have values between 33 and 126, inclusive), except > colon. " > > No header name is allowed a CR or LF in it,and certainly no sip header has CRLF included in its name. I never said that the CRLF is part of the header name. My question was if the header name token could be proceeded by LWS, or the header name token always be at the beginning of a new line. Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Wed Dec 11 11:31:10 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11288 for ; Wed, 11 Dec 2002 11:31:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBBGXdM05802 for sip-archive@odin.ietf.org; Wed, 11 Dec 2002 11:33:39 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBBGTFv05465; Wed, 11 Dec 2002 11:29:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBBGPCv05287 for ; Wed, 11 Dec 2002 11:25:12 -0500 Received: from NREXCH.netrake.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10912 for ; Wed, 11 Dec 2002 11:22:13 -0500 (EST) content-class: urn:content-classes:message Subject: RE: [Sip] ABNF issue MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 11 Dec 2002 10:25:08 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Message-ID: <7E06D3212981524CA10D2A114937C414014949A9@nrexch.netrake.net> Thread-Topic: [Sip] ABNF issue Thread-Index: AcKhKVa3FvMG4w9yQnyqywLu9cfavwABxYUw From: "Rob Phillips" To: "Christer Holmberg" , Cc: , , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gBBGPCv05288 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit The answer to this question: > My question was if the header name token could be proceeded by LWS, or > the header name token always be at the beginning of a new line. is: RFC-3261 does not specifically ALLOW the name token to be proceeded by LWS, i.e. the definition of message-header per ABNF is: message-header = (Accept / .... / extension-header) CRLF Therefore, the header name token MUST always be at the beginning of a new line. - rob _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Wed Dec 11 12:38:09 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13897 for ; Wed, 11 Dec 2002 12:38:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBBHea010509 for sip-archive@odin.ietf.org; Wed, 11 Dec 2002 12:40:36 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBBHSov09503; Wed, 11 Dec 2002 12:28:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBBHPhv09387 for ; Wed, 11 Dec 2002 12:25:43 -0500 Received: from smail3.alcatel.fr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13287 for ; Wed, 11 Dec 2002 12:22:44 -0500 (EST) From: Juan-Carlos.Rojas@alcatel.fr Received: from frmail25.netfr.alcatel.fr (frmail25.netfr.alcatel.fr [155.132.182.155]) by smail3.alcatel.fr (ALCANET/NETFR) with ESMTP id gBBHPbek014269 for ; Wed, 11 Dec 2002 18:25:37 +0100 Subject: RE: [Sip] B2BUA To: sip@ietf.org Date: Wed, 11 Dec 2002 18:25:35 +0100 Message-ID: X-MIMETrack: Serialize by Router on FRMAIL25/FR/ALCATEL(Release 5.0.8 |June 18, 2001) at 12/11/2002 18:25:37 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hello, The last mails on this thread are once again confirming that the SIP protocol specification does not mandate for any B2BUA behaviour. This should be clearly written in the RFC 3261. This does not preclude in anyway to write separate drafts defining specific SIP applications or classes of SIP applications behaving as B2BUA with given rules (transparency, etc.). Interested people can start specific discussion threads for those cases. Comments ? Best regards Juan Carlos _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Wed Dec 11 16:58:42 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22917 for ; Wed, 11 Dec 2002 16:58:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBBM1DU24511 for sip-archive@odin.ietf.org; Wed, 11 Dec 2002 17:01:13 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBBLr3v23580; Wed, 11 Dec 2002 16:53:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBBLiiv23304 for ; Wed, 11 Dec 2002 16:44:44 -0500 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22120 for ; Wed, 11 Dec 2002 16:41:42 -0500 (EST) Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id gBBLiTfm012354; Wed, 11 Dec 2002 13:44:30 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABK88898; Wed, 11 Dec 2002 13:41:23 -0800 (PST) Date: Wed, 11 Dec 2002 11:14:49 -0800 Subject: Re: [Sip] B2BUA - Security Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: "Jonathan Rosenberg" , To: "Pete Cordell" From: Rohan Mahy In-Reply-To: <001d01c2a0f4$2025ae80$0200000a@tkw> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Wednesday, December 11, 2002, at 01:03 AM, Pete Cordell wrote: > OK - I'll go through some scenarios (host is agent, 'proxy' is agent, > NAT > only, firewall only, NAT & firewall) and derive some requirements that > Midcom desires of SIP. good. > I assume these are application specific requirements which will be > generalised in a future round of development. Is that the correct way > to do > it? yes, thanks. whether it is a draft or just some text sent to the mailing list, lets discuss this in SIPPING, since it is a requirements discussion. thx, -rohan > Pete. > > (to: and cc: list pruned in case it looks like spam!) > > ----- Original Message ----- > From: "Jonathan Rosenberg" > To: "Mark Watson" > Cc: "'Rohan Mahy'" ; "Mahey, Sonit" > ; "Pete Cordell" > ; > "Christian Huitema" ; > Sent: 09 December 2002 18:37 > Subject: Re: [Sip] B2BUA - Security > > >> inline. >> >> Mark Watson wrote: >>> Rohan wrote: >>> >>>> In addition to Jonathan's approach to session policy, there is no >>>> reason a middlebox controller can't be a proxy if it: >>>> >>>> 1. opens pinholes referenced in a clear text or integrity >>>> protected SDP >>>> 2. rejects requests with no readable SDP (the UA could >>>> instead include >>>> a full SDP, with keying material, encrypted with SMIME, ****and an >>>> abbreviated copy which is only integrity protected****). >>> >>> >>> I was about to write a draft suggesting exactly this. >> >> THis is simply not sufficient. >> >> It will suffice for firewalls, but not for NAT, where an actual >> modification needs to occur. >> >> I think that, per Pete's suggestion, the correct path forward is a >> requirements document that describes the problem and the requirements >> for the solution. I believe there are many interesting requirements >> here >> about disclosure of what is being done, that will strongly impact the >> solution. >> >>> >>> As per Jonathan's draft there is a need for the UA to be able to >>> 'declare' to network entities those parts of the SDP information >>> which >>> are needed for the network entity to perform whatever service it >>> performs (e.g. NAT or Firewall control). But the UA should not have >>> to >>> declare the whole SDP, and the terminating UA should be able to tell >>> if >>> a network entity has modified these parameters. >> >> Sounds like we are beginning the requirements work here... >> >>> >>> Rather than putting this information into new SIP headers, we could >>> include two copies of the SDP. One copy is unprotected and contains >>> only >>> the information that the UE wishes to 'declare' to the network >>> entities. >>> The other copy is protected and contains the full information. >> >> I think we can leave the header/body debate for down the road. I would >> be happy if we can get agreement on this general problem as one that >> we >> need to solve. >> >>> >>> This approach would work through existing devices which >>> inspect/modify > SDP. >>> >>> I'm not sure how an existing S/MIME compliant client would behave on >>> receiving these two copies. If it uses the unprotected SDP, then >>> things >>> are no worse than the present situation - the call suceeds, but >>> without >>> the advantages of S/MIME. If it uses the protected SDP (which has not >>> been modified by the NAT controlling device), then the call fails, >>> but >>> this is still no worse than the present situation. >> >> It comes down to disclosure. The message needs to convey information >> about the meaning of the multiple session descriptions - who set >> which, >> and why. >> >> -Jonathan R. >> -- >> Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. >> Chief Scientist First Floor >> dynamicsoft East Hanover, NJ 07936 >> jdrosen@dynamicsoft.com FAX: (973) 952-5050 >> http://www.jdrosen.net PHONE: (973) 952-5000 >> http://www.dynamicsoft.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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Wed Dec 11 17:02:47 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23017 for ; Wed, 11 Dec 2002 17:02:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBBM5ID24699 for sip-archive@odin.ietf.org; Wed, 11 Dec 2002 17:05:18 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBBLsxv23634; Wed, 11 Dec 2002 16:54:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBBLijv23308 for ; Wed, 11 Dec 2002 16:44:45 -0500 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22123 for ; Wed, 11 Dec 2002 16:41:43 -0500 (EST) Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBBLiVFp027555; Wed, 11 Dec 2002 13:44:32 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABK88899; Wed, 11 Dec 2002 13:41:25 -0800 (PST) Date: Wed, 11 Dec 2002 11:23:45 -0800 Subject: Re: [Sip] ABNF issue Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: hisham.khartabil@nokia.com, rob@netrake.com, rsparks@dynamicsoft.com, jdrosen@dynamicsoft.com, sip@ietf.org To: Christer Holmberg From: Rohan Mahy In-Reply-To: <3DF749FC.4F7FC89@lmf.ericsson.se> Message-Id: <10BAA00A-0D3E-11D7-8C59-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Christer, You specific question has been answered twice already, and I will answer it a third time. If you still do not understand, please email one of the chairs privately and we will arrange for someone to explain it to you. On Wednesday, December 11, 2002, at 06:21 AM, Christer Holmberg wrote: > I never said that the CRLF is part of the header name. My question was > if the header name token could be proceeded by LWS, or > the header name token always be at the beginning of a new line. as rob@netrake said: > RFC-3261 does not specifically ALLOW the name token to be proceeded > by LWS, i.e. the definition of message-header per ABNF is: > > message-header = (Accept / .... / extension-header) CRLF > > Therefore, the header name token MUST always be at the beginning of a > new line. and as robert sparks said: > The grammar answers that. > extension-header starts with a token. in other words, a SIP header ALWAYS starts with a token (all of the existing headers are tokens), which can NEVER contain leading whitespace. thanks, -rohan _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Thu Dec 12 01:36:51 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04840 for ; Thu, 12 Dec 2002 01:36:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBC6dQd18074 for sip-archive@odin.ietf.org; Thu, 12 Dec 2002 01:39:26 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBC6Vdv17208; Thu, 12 Dec 2002 01:31:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBC6Tuv17115 for ; Thu, 12 Dec 2002 01:29:56 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04681 for ; Thu, 12 Dec 2002 01:26:51 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gBC6TfKV000262; Thu, 12 Dec 2002 07:29:41 +0100 (MET) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id YBCPVXA0; Thu, 12 Dec 2002 07:29:41 +0100 Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.68]) by hendrix.lmf.ericsson.se (8.12.6/8.12.6/lmf-2.1-jcs) with ESMTP id gBC6Teu4027137; Thu, 12 Dec 2002 08:29:40 +0200 (EET) Message-ID: <3DF82CD5.CD7087A6@lmf.ericsson.se> Date: Thu, 12 Dec 2002 08:29:41 +0200 X-Sybari-Trust: ea849cc7 ca231590 296be55b 00000138 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Rohan Mahy CC: hisham.khartabil@nokia.com, rob@netrake.com, rsparks@dynamicsoft.com, jdrosen@dynamicsoft.com, sip@ietf.org Subject: Re: [Sip] ABNF issue References: <10BAA00A-0D3E-11D7-8C59-0003938AF740@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, > You specific question has been answered twice already, and I will > answer it a third time. If you still do not understand, please email > one of the chairs privately and we will arrange for someone to explain > it to you. > > On Wednesday, December 11, 2002, at 06:21 AM, Christer Holmberg wrote: > > I never said that the CRLF is part of the header name. My question was > > if the header name token could be proceeded by LWS, or > > the header name token always be at the beginning of a new line. > > as rob@netrake said: > > RFC-3261 does not specifically ALLOW the name token to be proceeded > > by LWS, i.e. the definition of message-header per ABNF is: > > > > message-header = (Accept / .... / extension-header) CRLF > > > > Therefore, the header name token MUST always be at the beginning of a > > new line. > > and as robert sparks said: > > The grammar answers that. > > extension-header starts with a token. > > in other words, a SIP header ALWAYS starts with a token (all of the > existing headers are tokens), which can NEVER contain leading > whitespace. And I don't know how many times I've said this: I've NEVER claimed that a header would start with anything else than a token. What I've been talking about are general ABNF rules. Anway, I have had a private discussion with Brian about this, so there is no idea to continue it here. Rob also presented some assumptions we make in SIP, and if everybody agrees on those I am happy. Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Thu Dec 12 04:41:35 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18041 for ; Thu, 12 Dec 2002 04:41:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBC9iCf06794 for sip-archive@odin.ietf.org; Thu, 12 Dec 2002 04:44:12 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBC9CBv04552; Thu, 12 Dec 2002 04:12:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBC9AJv04472 for ; Thu, 12 Dec 2002 04:10:19 -0500 Received: from em.njupt.edu.cn (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA17233 for ; Thu, 12 Dec 2002 04:07:03 -0500 (EST) Received: (qmail 24132 invoked from network); 12 Dec 2002 09:40:12 -0000 Received: from unknown (HELO njupt.edu.cn) (10.10.3.123) by em.njupt.edu.cn with SMTP; 12 Dec 2002 09:40:12 -0000 Message-ID: <3DF85426.5030207@njupt.edu.cn> Date: Thu, 12 Dec 2002 17:17:26 +0800 From: feng zhang User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=gb18030; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] no-op Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi all, When I'm reading RFC3261, I met "no-op" in the document. But I can not find where it is defined, and I want to know what's the meaning of "no-op"? no-op ?= no-operation Thanks a lot! _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Thu Dec 12 13:49:32 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06724 for ; Thu, 12 Dec 2002 13:49:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBCIq2e07664 for sip-archive@odin.ietf.org; Thu, 12 Dec 2002 13:52:02 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBCIfev07296; Thu, 12 Dec 2002 13:41:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBCIcbv07168 for ; Thu, 12 Dec 2002 13:38:37 -0500 Received: from msgbas2x.cos.agilent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06183 for ; Thu, 12 Dec 2002 13:35:37 -0500 (EST) From: brian_moody@agilent.com Received: from relcos2.cos.agilent.com (relcos2.cos.agilent.com [130.29.152.237]) by msgbas2x.cos.agilent.com (Postfix) with ESMTP id 565B1FA for ; Thu, 12 Dec 2002 11:38:23 -0700 (MST) Received: from axcsbh2.cos.agilent.com (axcsbh2.cos.agilent.com [130.29.152.144]) by relcos2.cos.agilent.com (Postfix) with SMTP id D5B5A62A for ; Thu, 12 Dec 2002 11:38:13 -0700 (MST) Received: from 130.29.152.144 by axcsbh2.cos.agilent.com (InterScan E-Mail VirusWall NT); Thu, 12 Dec 2002 11:38:05 -0700 Received: by axcsbh2.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 12 Dec 2002 11:38:05 -0700 Message-ID: <08E9E30FCA2CD5119BEA0090274066DF05800C98@axcs16.cos.agilent.com> To: sip@ietf.org Date: Thu, 12 Dec 2002 11:38:02 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] SIP deployment Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , I'm gathering SIP network deployment information at the service provider level. Anyone that has experience deploying a SIP network at this level please reply with troubleshooting tips and significant challenges that were dealt with. Thank you. Brian _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Thu Dec 12 14:28:19 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08842 for ; Thu, 12 Dec 2002 14:28:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBCJUnq10206 for sip-archive@odin.ietf.org; Thu, 12 Dec 2002 14:30:49 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBCJNAv09755; Thu, 12 Dec 2002 14:23:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBCJK5v09588 for ; Thu, 12 Dec 2002 14:20:05 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08121 for ; Thu, 12 Dec 2002 14:17:03 -0500 (EST) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id gBCJJajU001285 for ; Thu, 12 Dec 2002 11:19:36 -0800 (PST) Received: from cj14 (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-9.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with SMTP id EVM00815; Thu, 12 Dec 2002 11:20:21 -0800 (PST) From: "Cullen Jennings" To: Subject: RE: [Sip] B2BUA & Max-Forwards Date: Thu, 12 Dec 2002 11:23:10 -0800 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.2911.0) In-Reply-To: <475FF955A05DD411980D00508B6D5FB006E5631C@en0033exch001u.uk.lucent.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I can't really see how it matters if the term B2BUA is defined in 3261bis or not since it would make no normative changes to the specification either way. It does seem very obvious to me that B2BUA is a useful description of a certain class of valid SIP applications. I'm sure the term will continue to be widely used and one the most commonly occurring works in the sip mailing lists. I can't imagine how we could wish the term away or even why we would want too. Deans 10 rules of transparency will no doubt be used to describe the characteristics of certain B2BUA. Thanks Dean. So out of this long and dreary thread, I see only a few real proposals of Do a INFORMATIONAL draft(s) with one or more of the following: 1) describing various transparencies of B2BUA 2) attempt some level of definition of what we mean by a B2BUA 3) show some call flows (like the service examples) that show possible call flows for solving some of the common problems people are trying to solve with B2BUA My view is I don't see any particular harm in doing any of the above but I would not have much time to help on them because I think there are more important things. If other people do have time (as several have suggested they do) lets say thanks and get on with it. Cullen > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Drage, > Keith (Keith) > Sent: Monday, December 09, 2002 7:42 AM > To: Mary Barnes; 'Jonathan Rosenberg'; Pete Cordell > Cc: David R. Oran; Dean Willis; sip@ietf.org > Subject: RE: [Sip] B2BUA & Max-Forwards > > > This thread is definitely going way beyond what it should do > (both in scope and duration) - it did however start (about a 100 > messages ago) with some reasonable modifications to the B2BUA > definition, and save those relatively minor modifications, I do > not want to see any other modifications in RFC 3261 or its next revision. > > I certainly will not agree to removal of any existing definition of B2BUA. > > Keith > > Keith Drage > Lucent Technologies > Tel: +44 1793 776249 > Email: drage@lucent.com > > > -----Original Message----- > > From: Mary Barnes [mailto:mbarnes@nortelnetworks.com] > > Sent: 06 December 2002 15:40 > > To: 'Jonathan Rosenberg'; Pete Cordell > > Cc: David R. Oran; Dean Willis; sip@ietf.org > > Subject: RE: [Sip] B2BUA & Max-Forwards > > > > > > > > I agree with Jonathan. As mentioned earlier this week > > apparently, there is > > already work underway by some individuals to write an > > informational draft > > documenting BBUA scenarios/call flows. > > > > I'll keep my fingers crossed that the existence of such a > > document can save > > us from another round of B2BUA discussions again in 3 months. > > > > Regards, > > Mary. > > > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > Sent: Friday, December 06, 2002 12:59 AM > > To: Pete Cordell > > Cc: David R. Oran; Dean Willis; sip@ietf.org > > Subject: Re: [Sip] B2BUA & Max-Forwards > > > > > > > > > > Pete Cordell wrote: > > > Dave, > > > > > > To save your disagreeableness, can we say something like: > > > > > > "A B2BUA MUST perform loop prevention. One way to do this > > is to propagate > > > the Max-Forwards header from the incoming request to the > > outgoing request > > in > > > the same way that a proxy does." > > > > A statement like this is completely out of scope for rfc3261. > > It might > > be a reasonable statement to make in some kind of application > > document > > that describes a particular type of b2bua. However, it makes no more > > sense to say this in RFC 3261 as it would be to discuss the ways in > > which to build a focus or a 3pcc controller (both of which are also > > informational, by the way). > > > > I can't resist pointing out that much of this is deja vu. Folks may > > recall heated discussions in Adelaide, where there was a bof > > (I think) > > that wanted to have a working group to specify SIP to H.323 > > conversion. > > THe same arguemtns that were made there are being made here; its an > > application level issue, there are many ways to do it, don't stifle > > creativity, etc. In fact I recall that Dave was, as always, quite > > vociferous on these points. > > > > The eventual conclusion in the h323/sip conversion case was > > to write an > > INFORMATIONAL RFC that documents reasonable practices in > > building such a > > device. I believe the same logic and conclusions apply here. If folks > > have a particular type of b2bua application they are fond of, please > > feel free to write up your implementation advice and I am > > sure sipping > > would consider whether or not it would make a useful > > informational RFC. > > > > However, it is completely inappropriate to ever make such application > > logic normative, and even more inappropraite for such wording > > to be in > > rfc3261. > > > > Anyway, I too am tired of this thread. I think, in fact, there is > > "rough" consensus to remove the definition of b2bua entirely from > > rfc3261 in its next revision (which is quite some time in the future > > anyway). However, I'll let the chairs decide that. > > > > -Jonathan R. > > > > -- > > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.dynamicsoft.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 > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Fri Dec 13 00:14:47 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03660 for ; Fri, 13 Dec 2002 00:14:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBD5HNh12835 for sip-archive@odin.ietf.org; Fri, 13 Dec 2002 00:17:23 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBD5DTv12692; Fri, 13 Dec 2002 00:13:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBD5B1v12550 for ; Fri, 13 Dec 2002 00:11:01 -0500 Received: from bdsl.greycouncil.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03476 for ; Fri, 13 Dec 2002 00:07:54 -0500 (EST) Received: from txdwillis (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.5/8.12.5) with ESMTP id gBD5AoUx021562 for ; Thu, 12 Dec 2002 23:10:51 -0600 From: "Dean Willis" To: Date: Thu, 12 Dec 2002 23:10:46 -0600 Message-ID: <004e01c2a265$ff3eaf50$78f30a0a@txdwillis> 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.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Sip] Minutes IETF 55, SIP WG Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I have posted draft minutes at: http://www.softarmor.com/sipwg/meets/ietf55/minutes/minutes.html Please review ASAP. 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 mailnull@www1.ietf.org Fri Dec 13 09:15:45 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23903 for ; Fri, 13 Dec 2002 09:15:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBDEIC519548 for sip-archive@odin.ietf.org; Fri, 13 Dec 2002 09:18:12 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBDE3xv18243; Fri, 13 Dec 2002 09:03:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBDDxcv18043 for ; Fri, 13 Dec 2002 08:59:38 -0500 Received: from gw-nl3.philips.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23442; Fri, 13 Dec 2002 08:56:39 -0500 (EST) From: frank.derks@philips.com Received: from smtpscan-nl2.philips.com (smtpscan-nl2.philips.com [130.139.36.22]) by gw-nl3.philips.com (Postfix) with ESMTP id 6664A91E3D; Fri, 13 Dec 2002 14:59:29 +0100 (MET) Received: from smtprelay-nl1.philips.com (localhost [127.0.0.1]) by smtpscan-nl2.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id OAA00633; Fri, 13 Dec 2002 14:59:24 +0100 (MET) Received: from ehv001soh.diamond.philips.com (e2soh01.diamond.philips.com [130.139.52.13]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id OAA11965; Fri, 13 Dec 2002 14:59:18 +0100 (MET) To: sip@ietf.org, sipping@ietf.org Cc: e-tc32-tg17@ecma.ch MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Fri, 13 Dec 2002 14:57:36 +0100 X-MIMETrack: Serialize by Router on ehv001soh/H/SERVER/PHILIPS(Release 5.0.9a |January 7, 2002) at 13/12/2002 14:57:41, Serialize complete at 13/12/2002 14:57:41 Content-Type: text/plain; charset="us-ascii" Subject: [Sip] Challenges when interworking QSIG and SIP Call Transfer Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , When trying to put together some interworking scenarios between SIP call transfer and QSIG call transfer, some problems were identified. The purpose of this E-mail message is to solicit advice on how these problems could best be tackled. In the below text, SIP terminology is used, rather than telecoms terminology. Therefore, parties that would normally be referred to as "Party X or X-Party" are being referred to as Transferor, Transferee and Transfer Target. Hopefully, this makes the text more readable. Currently there is no specific SIP mechanism to notify parties involved in SIP call transfer that a call transfer is taking place or has taken place, without establishing a new session. I.e. the notification of transfer and the communication of identities is solved (for attended transfer only) by including a Replaces "header" in a SIP URI in the Refer-to header in a REFER (to the Transferee) and/or by including a Replaces header in an INVITE (to the Transfer Target). The current mechanisms are sufficient to effect the call transfer, but in some cases the Transferee and/or the Transfer Target will not be aware of what is going on. In particular in interworking scenarios with QSIG, some difficulties have been identified. Below, first an attempt to analyse the situation for a pure SIP situation is presented. The purpose of this is to determine if the problems that were identified for QSIG interworking scenarios have a broader scope. The "All" SIP situation The below examples are based on the situation that the Transferor has a session established with both the Transferee and the Transfer Target. For the purpose of this analysis, this will be referred to as "attended transfer". 1) When the Transferor does not support the use of the Replaces header in the Refer-to URI, neither the Transferee, nor the Transfer Target can be explicitely aware of a transfer. This knowledge, however, could be inferred from the fact that the calls between the Transferor and the Transferee and between the Transferor and the Transfer Target are terminated shortly after the new call between the Transferee and the Transfer Target has been established. Both the Transferee and the Transfer Target are aware of each other's identity because the Tranferee establishes the new session with the Transfer Target. 2) When the Transferor does support the use of the Replaces header in the Refer-to URI, but the Transferee does not, the situation, could be identical to the above one, provided that the Transferee simply ignores this header. An alternative could be that the Transferee does not interpret this header and simply copies it into the INVITE to the Transfer Target. The Transfer Target, depending on its capabilities, can then be aware of the fact that a call transfer is taking place. The Transferee will not be aware of this. The Transferee and the Transfer Target are aware of each other's identity. 3) When the Transferor and the Transferee support the use of Replaces header in a Refer-to URI and the Transfer Target supports the use of the Replaces header in an INVITE message, both the Transferee and the Transfer Target are aware of the transfer and the identities of the new parties in the call. Summarising the above situations, it can be stated that in all the above cases the Transferee and the Transfer Target are aware of each other's identity, but may not be aware of the fact that a transfer has taken place. When all involved parties know about support the use of the Replaces header (in a Refer-to URI and/or an INVITE message), the Transferee and the Transfer Target are both aware of transfer taking place and the identities of each other. The means of "signalling" that a transfer is taking place is the Replaces header (either in a Refer-to URI or in an INVITE message). For situations in which the Transferor does have a session established with the Transferee, but not with the Transfer Target (prior to sending a REFER message to the Transferee) the situation is somewhat simpler. For the purpose of this analysis, this will be referred to as "unattended transfer". It is not possible to use the Replaces header (either in a Refer-to URI or in an INVITE message) because there is no session to replace. Therefore, neither the Transferee nor the Transfer Target are explicitely aware of the fact that a transfer is taking place. The Transferee and the Transfer Target are aware of each other's identity. Interworking scenarios with QSIG When interworking with QSIG call transfer (attended transfer) or QSIG single step call transfer ("unattended transfer"), the situation is different. Two examples (one for attended transfer and one for unattended transfer) are given below. 1) Attended transfer. The Transferor is in QSIG and the Transferee and the Transfer Target are in SIP. When the Transferor performs a Call Transfer by join, it will send a notification to both the Transferee and the Transfer Target and then connect the B-channels of the respective calls. Each notification will arrive at a SIP gateway, which has an established session with either Transferee or the Transfer Target. No SIP signalling is required to "connect" these two sessions at the Transferor. Although it may be desirable (from a SIP point of view or for QoS reasons) to have the Transferee establish a session with the Transfer Target, this would complicate matters from the QSIG point of view: The (QSIG) Transferor assumes that it is in control over the two calls and the associated B-channels. Relinquishing control to the Transferee would cut the Transferor out of the picture. Furthermore, the Transferor in this situation is a node in the QSIG network and we cannot assume that this node will be upgraded in order to support calls via gateways to/from SIP. In any case, such a node is unlikely to be aware that the transferee and transfer target are in a SIP network, and therefore will not be in a position to treat such a scenario differently from a normal QSIG-only scenario. To be able to inform the Transferee and the Transfer Target about the transfer that took place and about the identities of the new parties in the call, the options that are available today would seem to be the following: - send a new INVITE with a Replaces header to both the Transferee and the Transfer Target. The destination of the INVITE, however, has to support the Replaces header to avoid undesirable side effects. - send a re-INVITE, optionally with a Referred-By header, to both the Transferee and the Transfer Target. Although the meaning of "Referred-By" is not that a call transfer took place, subsequent release of the already established sessions (in combination with Referred-by) could be used as a strong hint that call transfer did take place. - send a REFER to the Transferee (with the address of the GW in the Refer-to URI) and an INVITE with a Replaces header to the Transfer Target. These methods seem to generate a lot of messages and processing, while the only purpose of the establishment of the new sessions is to inform both parties about the transfer and/or the identities of the new parties. 2) Unattended transfer. The Transferor is in QSIG and the Transferee and the Transfer Target are in SIP. When the Transferor performs an unattended transfer, it can establish a call with the Transfer Target (which also notifies the Transfer Target that a transfer is taking place) and notify the Transferee about the fact that a transfer is taking place and about the progress of this new call. When the new call is established, the B-channels of the two calls can be connected at the Transferor. There is no way to inform the Transfer Target that this call is the result of a transfer. There is no way to inform the Transferree that transfer is taking place. The only way to "repair" this situation would seem to be the use of the options mentioned in the previous example. Another possibility, is that the INVITE to the Transfer Target contains history-info with a new reason code to indicate transfer. Several interworking scenarios between SIP and QSIG for call transfer present this sort of problem. In most cases it would be sufficient if it were possible to simply send a notification message (i.e. a message that does neither modify the characteristics of the session nor its state) to the Transferee and/or the Transfer Target. (An example this could be a be a SIP INFO message with a P-Asserted-Identity header) Any comments and/or proposals on the above are welcomed. Regards, Frank _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Fri Dec 13 20:19:25 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12260 for ; Fri, 13 Dec 2002 20:19:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBE1LwU26584 for sip-archive@odin.ietf.org; Fri, 13 Dec 2002 20:21:58 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBE1HTv26301; Fri, 13 Dec 2002 20:17:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBE1Bav26133 for ; Fri, 13 Dec 2002 20:11:36 -0500 Received: from gamma.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11969; Fri, 13 Dec 2002 20:08:31 -0500 (EST) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id gBE1BRD27887; Fri, 13 Dec 2002 17:11:27 -0800 (PST) Message-Id: <200212140111.gBE1BRD27887@gamma.isi.edu> To: IETF-Announce: ; Cc: rfc-editor@rfc-editor.org, sip@ietf.org, sipping@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Fri, 13 Dec 2002 17:11:27 -0800 Subject: [Sip] RFC 3327 on Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3327 Title: Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts Author(s): D. Willis, B. Hoeneisen Status: Standards Track Date: December 2002 Mailbox: dean.willis@softarmor.com, bernhard.honeisen@nokia.com, b.hoeneisen@ieee.org Pages: 17 Characters: 36493 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-willis-sip-path-08.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3327.txt The REGISTER function is used in a Session Initiation Protocol (SIP) system primarily to associate a temporary contact address with an address-of-record. This contact is generally in the form of a Uniform Resource Identifier (URI), such as Contact: and is generally dynamic and associated with the IP address or hostname of the SIP User Agent (UA). The problem is that network topology may have one or more SIP proxies between the UA and the registrar, such that any request traveling from the user's home network to the registered UA must traverse these proxies. The REGISTER method does not give us a mechanism to discover and record this sequence of proxies in the registrar for future use. This document defines an extension header field, "Path" which provides such a mechanism. This document is a product of the Session Initiation Protocol and the Session Initiation Proposal Investigation Working Groups 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.echo 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: <021213170800.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3327 --OtherAccess Content-Type: Message/External-body; name="rfc3327.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <021213170800.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Fri Dec 13 22:51:53 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15390 for ; Fri, 13 Dec 2002 22:51:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBE3sS600576 for sip-archive@odin.ietf.org; Fri, 13 Dec 2002 22:54:28 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBE3onv00489; Fri, 13 Dec 2002 22:50:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBE3lmv00421 for ; Fri, 13 Dec 2002 22:47:48 -0500 Received: from em.njupt.edu.cn (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA15296 for ; Fri, 13 Dec 2002 22:44:40 -0500 (EST) Message-Id: <200212140344.WAA15296@ietf.org> Received: (qmail 26613 invoked from network); 14 Dec 2002 04:18:03 -0000 Received: from unknown (HELO toto) (10.10.3.123) by em.njupt.edu.cn with SMTP; 14 Dec 2002 04:18:03 -0000 Date: Sat, 14 Dec 2002 11:55:42 +0800 From: feng zhang Reply-To: y01317@njupt.edu.cn To: "sip@ietf.org" Organization: NUPT-CED202 X-mailer: FoxMail 4.0 beta 2 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id gBE3lmv00422 Subject: [Sip] REFER-07 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hello all, Can the authors give the detailed Changelog between refer-07 & refer-06? Thanks a lot! _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Sat Dec 14 08:04:00 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01873 for ; Sat, 14 Dec 2002 08:04:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBED6UR00904 for sip-archive@odin.ietf.org; Sat, 14 Dec 2002 08:06:30 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBED2Mv00816; Sat, 14 Dec 2002 08:02:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBECvNv00700 for ; Sat, 14 Dec 2002 07:57:23 -0500 Received: from rsys001a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01764 for ; Sat, 14 Dec 2002 07:54:22 -0500 (EST) Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Sat, 14 Dec 2002 12:57:19 -0000 Received: from percy.roke.co.uk ([193.118.192.111]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id YRZNXA46; Sat, 14 Dec 2002 12:57:17 -0000 From: "Conroy, Lawrence (SMTP)" To: sip@ietf.org Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: Date: Sat, 14 Dec 2002 12:57:16 +0000 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Sip] Use of Tel URL in To header Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi Folks, (potentially dumb question warning): Section 8.1.1.2 (To Header) of RFC3261 - Use of tel URL. I imply from this that the tel URL in a To header can be evaluated at "each domain through which the request passes". Example given there - dialing "411" at an Airport would be evaluated at the outgoing proxy at the Airport, not in the user's home domain. Q:: What is the meaning of the "user's home domain" when dialing out to a tel URL? Follow-up: When originating a call, one assumes that the INVITE request could go via an outgoing proxy. Is this proxy required to route a call onwards to a "home server", and if so how is that "home server" indicated in the INVITE sent to the outgoing proxy? The From header and Contact header indicates the (potential) AoR and current addressability of the caller. Is the From header used to indicate the home domain for the caller? all the best from a confused, Lawrence -- ----------------------------------------------------------------------- Roke Manor Research : This information is provided "as is" and is not : intended to create any contractual or legal : relationship. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Mon Dec 16 02:34:28 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28127 for ; Mon, 16 Dec 2002 02:34:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBG7b7r01871 for sip-archive@odin.ietf.org; Mon, 16 Dec 2002 02:37:07 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBG7XMv01558; Mon, 16 Dec 2002 02:33:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBG7Uvv01434 for ; Mon, 16 Dec 2002 02:30:57 -0500 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27891; Mon, 16 Dec 2002 02:27:46 -0500 (EST) Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBG7UhFp000245; Sun, 15 Dec 2002 23:30:43 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABL31227; Sun, 15 Dec 2002 23:27:37 -0800 (PST) Date: Sun, 15 Dec 2002 23:31:14 -0800 Subject: Re: [Sip] Challenges when interworking QSIG and SIP Call Transfer Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: sip@ietf.org, sipping@ietf.org, e-tc32-tg17@ecma.ch To: frank.derks@philips.com From: Rohan Mahy In-Reply-To: Message-Id: <5B338816-10C8-11D7-8C59-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, I appreciate the thorough analysis in your mail. I plan to reply to the content of your message shortly. However, I wanted to reply to your mail right away with an important list management issue. In the spirit of reducing cross postings between SIP and SIPPING, I am removing SIP from this reply. This is purely a SIPPING issue, so everyone please do not post/reply to both lists. I think this is especially important when we are also cross posting to another standards group mailing list. many thanks, -rohan On Friday, December 13, 2002, at 05:57 AM, frank.derks@philips.com wrote: > When trying to put together some interworking scenarios between SIP > call > transfer and QSIG call transfer, some problems were identified. The > purpose of this E-mail message is to solicit advice on how these > problems could best be tackled. In the below text, SIP terminology is > used, rather than telecoms terminology. Therefore, parties that would > normally be referred to as "Party X or X-Party" are being referred to > as Transferor, Transferee and Transfer Target. Hopefully, this makes > the > text more readable. > > Currently there is no specific SIP mechanism to notify parties involved > in SIP call transfer that a call transfer is taking place or has taken > place, without establishing a new session. I.e. the notification of > transfer and the communication of identities is solved (for attended > transfer only) by including a Replaces "header" in a SIP URI in the > Refer-to header in a REFER (to the Transferee) and/or by including a > Replaces header in an INVITE (to the Transfer Target). > > The current mechanisms are sufficient to effect the call transfer, but > in some cases the Transferee and/or the Transfer Target will not be > aware of what is going on. In particular in interworking scenarios with > QSIG, some difficulties have been identified. > > Below, first an attempt to analyse the situation for a pure SIP > situation is presented. The purpose of this is to determine if the > problems that were identified for QSIG interworking scenarios have a > broader scope. > > The "All" SIP situation > > The below examples are based on the situation that the Transferor has a > session established with both the Transferee and the Transfer Target. > For the purpose of this analysis, this will be referred to as "attended > transfer". > > 1) When the Transferor does not support the use of the > Replaces header in the Refer-to URI, neither the Transferee, nor the > Transfer Target can be explicitely aware of a transfer. This knowledge, > however, could be inferred from the fact that the calls between the > Transferor and the Transferee and between the Transferor and the > Transfer Target are terminated shortly after the new call between the > Transferee and the Transfer Target has been established. Both the > Transferee and the Transfer Target are aware of each other's identity > because the Tranferee establishes the new session with the Transfer > Target. > > 2) When the Transferor does support the use of the Replaces > header in the Refer-to URI, but the Transferee does not, the situation, > could be identical to the above one, provided that the Transferee > simply > ignores this header. An alternative could be that the Transferee does > not interpret this header and simply copies it into the INVITE to the > Transfer Target. The Transfer Target, depending on its capabilities, > can > then be aware of the fact that a call transfer is taking place. The > Transferee will not be aware of this. The Transferee and the Transfer > Target are aware of each other's identity. > > 3) When the Transferor and the Transferee support the use of > Replaces header in a Refer-to URI and the Transfer Target supports > the use of the Replaces header in an INVITE message, both the > Transferee > and the Transfer Target are aware of the transfer and the identities of > the new parties in the call. > > Summarising the above situations, it can be stated that in all the > above > cases the Transferee and the Transfer Target are aware of each other's > identity, but may not be aware of the fact that a transfer has taken > place. When all involved parties know about support the use of the > Replaces header (in a Refer-to URI and/or an INVITE message), the > Transferee and the Transfer Target are both aware of transfer taking > place and the identities of each other. The means of "signalling" that > a > transfer is taking place is the Replaces header (either in a Refer-to > URI or in an INVITE message). > > For situations in which the Transferor does have a session established > with the Transferee, but not with the Transfer Target (prior to sending > a REFER message to the Transferee) the situation is somewhat simpler. > For the purpose of this analysis, this will be referred to as > "unattended > transfer". It is not possible to use the Replaces header (either in a > Refer-to URI or in an INVITE message) because there is no session to > replace. Therefore, neither the Transferee nor the Transfer Target are > explicitely aware of the fact that a transfer is taking place. The > Transferee and the Transfer Target are aware of each other's identity. > > Interworking scenarios with QSIG > > When interworking with QSIG call transfer (attended transfer) or QSIG > single step call transfer ("unattended transfer"), the situation is > different. Two examples (one for attended transfer and one for > unattended transfer) are given below. > > 1) Attended transfer. > > The Transferor is in QSIG and the Transferee and the Transfer Target > are > in SIP. When the Transferor performs a Call Transfer by join, it will > send a notification to both the Transferee and the Transfer Target and > then connect the B-channels of the respective calls. > Each notification will arrive at a SIP gateway, which has an > established > session with either Transferee or the Transfer Target. No SIP > signalling > is required to "connect" these two sessions at the Transferor. Although > it may be desirable (from a SIP point of view or for QoS reasons) to > have the Transferee establish a session with the Transfer Target, this > would complicate matters from the QSIG point of view: The (QSIG) > Transferor assumes that it is in control over the two calls and the > associated B-channels. Relinquishing control to the Transferee would > cut > the Transferor out of the picture. Furthermore, the Transferor in this > situation is a node in the QSIG network and we cannot assume that this > node will be upgraded in order to support calls via gateways to/from > SIP. In any case, such a node is unlikely to be aware that the > transferee and transfer target are in a SIP network, and therefore will > not be in a position to treat such a scenario differently from a normal > QSIG-only scenario. > > To be able to inform the Transferee and the Transfer Target about the > transfer that took place and about the identities of the new parties in > the call, the options that are available today would seem to be the > following: > > - send a new INVITE with a Replaces header to both the Transferee and > the Transfer Target. The destination of the INVITE, however, has to > support the Replaces header to avoid undesirable side effects. > > - send a re-INVITE, optionally with a Referred-By header, to both the > Transferee and the Transfer Target. Although the meaning of > "Referred-By" is not that a call transfer took place, subsequent > release of the already established sessions (in combination with > Referred-by) could be used as a strong hint that call transfer did > take place. > > - send a REFER to the Transferee (with the address of the GW in the > Refer-to URI) and an INVITE with a Replaces header to the Transfer > Target. > > These methods seem to generate a lot of messages and processing, while > the only purpose of the establishment of the new sessions is to inform > both parties about the transfer and/or the identities of the new > parties. > > 2) Unattended transfer. > > The Transferor is in QSIG and the Transferee and the Transfer Target > are > in SIP. When the Transferor performs an unattended transfer, it can > establish a call with the Transfer Target (which also notifies the > Transfer Target that a transfer is taking place) and notify the > Transferee about the fact that a transfer is taking place and about the > progress of this new call. When the new call is established, the > B-channels of the two calls can be connected at the Transferor. There > is > no way to inform the Transfer Target that this call is the result of a > transfer. There is no way to inform the Transferree that transfer is > taking place. The only way to "repair" this situation would seem to be > the use of the options mentioned in the previous example. Another > possibility, is that the INVITE to the Transfer Target contains > history-info with a new reason code to indicate transfer. > > Several interworking scenarios between SIP and QSIG for call transfer > present this sort of problem. In most cases it would be sufficient if > it > were possible to simply send a notification message (i.e. a message > that > does neither modify the characteristics of the session nor its state) > to > the Transferee and/or the Transfer Target. (An example this could > be a be a SIP INFO message with a P-Asserted-Identity header) > > Any comments and/or proposals on the above are welcomed. > > > Regards, > > Frank > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Mon Dec 16 05:57:38 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01082 for ; Mon, 16 Dec 2002 05:57:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBGB07212517 for sip-archive@odin.ietf.org; Mon, 16 Dec 2002 06:00:07 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBGAuDv12385; Mon, 16 Dec 2002 05:56:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBGAt0v12312 for ; Mon, 16 Dec 2002 05:55:00 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01000 for ; Mon, 16 Dec 2002 05:52:00 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gBGAsvAv013928; Mon, 16 Dec 2002 11:54:57 +0100 (MET) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id YV6FD2GH; Mon, 16 Dec 2002 11:54:57 +0100 Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.80]) by hendrix.lmf.ericsson.se (8.12.6/8.12.6/lmf-2.1-jcs) with ESMTP id gBGAsvu4020281; Mon, 16 Dec 2002 12:54:57 +0200 (EET) Message-ID: <3DFDB100.3476D31C@lmf.ericsson.se> Date: Mon, 16 Dec 2002 12:54:56 +0200 X-Sybari-Trust: 24bf4139 ca231590 99595932 00000138 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Robert Sparks , Anders Kristensen , sip@ietf.org Subject: Re: [Sip] Constructing the branch parameter at stateless proxies References: <1038933302.911.62.camel@RjS.localdomain> <3DEE251A.5080306@dynamicsoft.com> <1039017937.910.76.camel@RjS.localdomain> <3DEE294A.9080806@dynamicsoft.com> <1039019630.910.132.camel@RjS.localdomain> <3DEEFF6F.3000605@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, I was thiking of an scenario where we may have problems: +----->S1-----+ | v UAC--->P1 P2--->UAS | ^ +----->S2-----+ The UAC sends an INVITE. P1 forks to S1 and S2 (both stateless). Both S1 and S2 will route the INVITE to P2 (stateful). From P2 perspective, both INVITEs will have the same branch ID. Therefore, P2 will treat the INVITE that arrives later as a retransmission of the first INVITE. P2 could be able to differentiate both INVITEs using the received Via parameter or the port number in the Via header. But P2 is not supposed to need to include these paramteres when calculating the transaction ID. In this situation, everything will recover fine (P1 will CANCEL the branch that does not return a final response), but it is, nevertheless, an error situation. Thoughts? Gonzalo Jonathan Rosenberg wrote: > > inline. > > Robert Sparks wrote: > > On Wed, 2002-12-04 at 10:11, Anders Kristensen wrote: > > > >> > >>Robert Sparks wrote: > >> > >>>On Wed, 2002-12-04 at 09:54, Anders Kristensen wrote: > >>> > >>> > >>>>Hi Robert, > >>>> > >>>>Sounds like a very good idea. One special case to consider is what > >>>>happens if the request spirals back to the sending proxy (which > >>>>presumably is stateful) -- either directly from the stateless proxy or > >>>>via a number of other stateless proxies. The stateful proxy in this > >>>>case will have a server transaction and a client transaction with the > >>>>same id, which might confuse some implementations. > >>> > >>> > >>>This is no different from the same proxy spiraling directly to itself > >>>is it? > >> > >>Well, it's different in that it is NOT spiraling directly to itself and > >>so is currently guaranteed to see a different branch ID in a spiralled > >>request. It may be the case that noone depends on this but who knows? > > > > > > Ok - so an implementation _may_ have gone to some effort to ensure > > that it wasn't sending a message to itself and is counting on not > > seeing the same transaction identifier come back to it. Not a choice > > I would recommend, but I can see how someone might have made it. > > > > We could avoid this with the suffix mechanism you suggest, or we > > could add an admonishment to the spec to tell systems to be prepared > > to have their transaction ID come back. I'd rather do the second. > > I agree with Robert. Over time, our view of stateless proxies has > changed a lot. Initially, we tried to treat them as the same as stateful > ones, but it has become clear that there are important differences (for > example, there are restrictions on the types of routing logic that are > permitted). > > One of the big changes in bis was the formal definition of a transaction > as being between a client transaction in one element and a server > transaction in another (figure 4). Whats important is that the > transaction is between transaction-stateful elements (by definition). It > would seem very logical, then, that the transaction identifier (the > branch ID) would be the same for all messages in this transaction. Since > a stateless proxy doesn't muck with the transaction, just forwards > messages, I would argue that the transaction ID should stay the same. > > Indeed, the analogy is similar to the dialog identifiers in a stateful > proxy; they too are not modified, since the proxy doesn't act as a > termination point of the dialog. If it did (b2bua), it would need to > modify those identifiers. > > > > > Well, nothing earth-shattering. Right now, just an increased probability > > that implementation error will lead to protocol failure. Its hard to get > > this right, and we can greatly simplify it. > > > > My growing distaste for what the stateless proxies are currently doing > > comes from seeing it somewhat like a NAT. The transaction is really > > between the two stateful elements reguardless of how many stateless > > elements lie between. Right now, the stateless elements are > > "translating" the transaction identifier as the message goes through. > > We haven't identified anything in the protocol that breaks as long > > as they do this consistently, but I haven't been able to identify any > > benefit to the behavior. > > I agree. I think its really legacy at this point. > > -Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.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 -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Mon Dec 16 06:11:45 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01201 for ; Mon, 16 Dec 2002 06:11:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBGBEEt13486 for sip-archive@odin.ietf.org; Mon, 16 Dec 2002 06:14:14 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBGBAIv13433; Mon, 16 Dec 2002 06:10:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBGB9Hv13391 for ; Mon, 16 Dec 2002 06:09:17 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01179 for ; Mon, 16 Dec 2002 06:06:17 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gBGB9FKV007638; Mon, 16 Dec 2002 12:09:15 +0100 (MET) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id Y820NZZY; Mon, 16 Dec 2002 12:09:15 +0100 Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.80]) by hendrix.lmf.ericsson.se (8.12.6/8.12.6/lmf-2.1-jcs) with ESMTP id gBGB9Fu4021238; Mon, 16 Dec 2002 13:09:15 +0200 (EET) Message-ID: <3DFDB459.18144C35@lmf.ericsson.se> Date: Mon, 16 Dec 2002 13:09:13 +0200 X-Sybari-Trust: 2a161340 ca231590 99595932 00000138 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Conroy, Lawrence (SMTP)" CC: sip@ietf.org Subject: Re: [Sip] Use of Tel URL in To header References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Lawrence, inline: "Conroy, Lawrence (SMTP)" wrote: > > Hi Folks, > (potentially dumb question warning): > > Section 8.1.1.2 (To Header) of RFC3261 - Use of tel URL. > > I imply from this that the tel URL in a To header can be evaluated at > "each domain through which the request passes". Example given there - > dialing "411" at an Airport would be evaluated at the outgoing proxy > at the Airport, not in the user's home domain. > > Q:: What is the meaning of the "user's home domain" when dialing out > to a tel URL? That is what the text in 8.1.1.2 is trying to say. Since the caller does not have any specific domain in mind, it uses a tel URL. Alternatively, the caller could have dialed sip:411@ericsson.com;user=phone In this situation, 411 would have been evaluated in the domain ericsson.com > Follow-up: > When originating a call, one assumes that the INVITE request could go > via an outgoing proxy. Yes, an outbound proxy may or may not be used. > Is this proxy required to route a call onwards > to a "home server" No. The outbound proxy, like any other proxy, will make routing decisions based on the Route header field, the Request-URI, and any other information the proxy wants (e.g., time, day of the week, caller's name...). >, and if so how is that "home server" indicated in > the INVITE sent to the outgoing proxy? > If you want your INVITE to traverse an outbound proxy and your home proxy you should indicate so in a Route header. The SIP loose routing mechanisms allow you to do that. > The From header and Contact header indicates the (potential) AoR and > current addressability of the caller. > Is the From header used to indicate the home domain for the caller? The From header is mostly used to identify the caller from a human perspective. In order to send requests back within the same dialog you would use the Contact header field. To send requests to the caller *outside* the dialog you would typically use the Reply-To header field. Regards, Gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Mon Dec 16 06:36:20 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01506 for ; Mon, 16 Dec 2002 06:36:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBGBciR14803 for sip-archive@odin.ietf.org; Mon, 16 Dec 2002 06:38:44 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBGBXcv14071; Mon, 16 Dec 2002 06:33:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBGBWlv13968 for ; Mon, 16 Dec 2002 06:32:47 -0500 Received: from hclnpd.hclt.co.in (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01374 for ; Mon, 16 Dec 2002 06:29:25 -0500 (EST) Received: from mailnpd.hclt-ntl.co.in ([192.168.19.36]) by hclnpd.hclt.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Y1WDACFR; Mon, 16 Dec 2002 17:02:54 +0530 Received: from kowsalyapc (kowsalya-pc.hclt-ntl.co.in [192.168.19.111]) by mailnpd.hclt-ntl.co.in (8.11.0/8.11.0) with SMTP id gBGBG5Z27331; Mon, 16 Dec 2002 16:46:05 +0530 Message-ID: <00f601c2a4f6$f9386d10$6f13a8c0@hcltntl.co.in> From: "Kowsalya Subramanian" To: "Gonzalo Camarillo" , "Jonathan Rosenberg" Cc: "Robert Sparks" , "Anders Kristensen" , References: <1038933302.911.62.camel@RjS.localdomain> <3DEE251A.5080306@dynamicsoft.com> <1039017937.910.76.camel@RjS.localdomain> <3DEE294A.9080806@dynamicsoft.com> <1039019630.910.132.camel@RjS.localdomain> <3DEEFF6F.3000605@dynamicsoft.com> <3DFDB100.3476D31C@lmf.ericsson.se> Subject: Re: [Sip] Constructing the branch parameter at stateless proxies Date: Mon, 16 Dec 2002 17:03:36 +0530 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 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Gonzalo, From my understanding of 16.5, forking will be done by P1 only if its the edge proxy for the req-uri. The only way the forked request can reach other proxies is through route headers. so the scenario under question can never happen or am i missing something?. Thanks Kowsalya ----- Original Message ----- From: Gonzalo Camarillo To: Jonathan Rosenberg Cc: Robert Sparks ; Anders Kristensen ; Sent: Monday, December 16, 2002 4:24 PM Subject: Re: [Sip] Constructing the branch parameter at stateless proxies > Hi, > > I was thiking of an scenario where we may have problems: > > +----->S1-----+ > | v > UAC--->P1 P2--->UAS > | ^ > +----->S2-----+ > > The UAC sends an INVITE. P1 forks to S1 and S2 (both stateless). Both S1 > and S2 will route the INVITE to P2 (stateful). > > >From P2 perspective, both INVITEs will have the same branch ID. > Therefore, P2 will treat the INVITE that arrives later as a > retransmission of the first INVITE. > > P2 could be able to differentiate both INVITEs using the received Via > parameter or the port number in the Via header. But P2 is not supposed > to need to include these paramteres when calculating the transaction ID. > > In this situation, everything will recover fine (P1 will CANCEL the > branch that does not return a final response), but it is, nevertheless, > an error situation. > > Thoughts? > > Gonzalo > > > > > Jonathan Rosenberg wrote: > > > > inline. > > > > Robert Sparks wrote: > > > On Wed, 2002-12-04 at 10:11, Anders Kristensen wrote: > > > > > >> > > >>Robert Sparks wrote: > > >> > > >>>On Wed, 2002-12-04 at 09:54, Anders Kristensen wrote: > > >>> > > >>> > > >>>>Hi Robert, > > >>>> > > >>>>Sounds like a very good idea. One special case to consider is what > > >>>>happens if the request spirals back to the sending proxy (which > > >>>>presumably is stateful) -- either directly from the stateless proxy or > > >>>>via a number of other stateless proxies. The stateful proxy in this > > >>>>case will have a server transaction and a client transaction with the > > >>>>same id, which might confuse some implementations. > > >>> > > >>> > > >>>This is no different from the same proxy spiraling directly to itself > > >>>is it? > > >> > > >>Well, it's different in that it is NOT spiraling directly to itself and > > >>so is currently guaranteed to see a different branch ID in a spiralled > > >>request. It may be the case that noone depends on this but who knows? > > > > > > > > > Ok - so an implementation _may_ have gone to some effort to ensure > > > that it wasn't sending a message to itself and is counting on not > > > seeing the same transaction identifier come back to it. Not a choice > > > I would recommend, but I can see how someone might have made it. > > > > > > We could avoid this with the suffix mechanism you suggest, or we > > > could add an admonishment to the spec to tell systems to be prepared > > > to have their transaction ID come back. I'd rather do the second. > > > > I agree with Robert. Over time, our view of stateless proxies has > > changed a lot. Initially, we tried to treat them as the same as stateful > > ones, but it has become clear that there are important differences (for > > example, there are restrictions on the types of routing logic that are > > permitted). > > > > One of the big changes in bis was the formal definition of a transaction > > as being between a client transaction in one element and a server > > transaction in another (figure 4). Whats important is that the > > transaction is between transaction-stateful elements (by definition). It > > would seem very logical, then, that the transaction identifier (the > > branch ID) would be the same for all messages in this transaction. Since > > a stateless proxy doesn't muck with the transaction, just forwards > > messages, I would argue that the transaction ID should stay the same. > > > > Indeed, the analogy is similar to the dialog identifiers in a stateful > > proxy; they too are not modified, since the proxy doesn't act as a > > termination point of the dialog. If it did (b2bua), it would need to > > modify those identifiers. > > > > > > > > Well, nothing earth-shattering. Right now, just an increased probability > > > that implementation error will lead to protocol failure. Its hard to get > > > this right, and we can greatly simplify it. > > > > > > My growing distaste for what the stateless proxies are currently doing > > > comes from seeing it somewhat like a NAT. The transaction is really > > > between the two stateful elements reguardless of how many stateless > > > elements lie between. Right now, the stateless elements are > > > "translating" the transaction identifier as the message goes through. > > > We haven't identified anything in the protocol that breaks as long > > > as they do this consistently, but I haven't been able to identify any > > > benefit to the behavior. > > > > I agree. I think its really legacy at this point. > > > > -Jonathan R. > > -- > > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.dynamicsoft.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 > > -- > Gonzalo Camarillo Phone : +358 9 299 33 71 > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > Telecom R&D Fax : +358 9 299 30 52 > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > Finland http://www.hut.fi/~gonzalo > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Mon Dec 16 07:15:09 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02339 for ; Mon, 16 Dec 2002 07:15:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBGCHdl16877 for sip-archive@odin.ietf.org; Mon, 16 Dec 2002 07:17:39 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBGCDqv16735; Mon, 16 Dec 2002 07:13:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBGCC1v16610 for ; Mon, 16 Dec 2002 07:12:01 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02141 for ; Mon, 16 Dec 2002 07:08:39 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gBGCBTKV025750; Mon, 16 Dec 2002 13:11:30 +0100 (MET) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id Y518Z8RJ; Mon, 16 Dec 2002 13:11:29 +0100 Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.80]) by hendrix.lmf.ericsson.se (8.12.6/8.12.6/lmf-2.1-jcs) with ESMTP id gBGCBTu4025258; Mon, 16 Dec 2002 14:11:30 +0200 (EET) Message-ID: <3DFDC2F0.46324F68@lmf.ericsson.se> Date: Mon, 16 Dec 2002 14:11:28 +0200 X-Sybari-Trust: d8bc3225 ca231590 99595932 00000138 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Kowsalya Subramanian CC: Jonathan Rosenberg , Robert Sparks , Anders Kristensen , sip@ietf.org Subject: Re: [Sip] Constructing the branch parameter at stateless proxies References: <1038933302.911.62.camel@RjS.localdomain> <3DEE251A.5080306@dynamicsoft.com> <1039017937.910.76.camel@RjS.localdomain> <3DEE294A.9080806@dynamicsoft.com> <1039019630.910.132.camel@RjS.localdomain> <3DEEFF6F.3000605@dynamicsoft.com> <3DFDB100.3476D31C@lmf.ericsson.se> <00f601c2a4f6$f9386d10$6f13a8c0@hcltntl.co.in> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, to give you a more concrete example: P1: SIP proxy at ericsson.com S1: Stateless proxy at cs.columbia.edu S2: Stateless proxy at lmf.ericsson.se P2: proxy at hut.fi, where I am giving a speech today. You send an INVITE to gonzalo@ericsson.com. That proxy will fork the INVITE to try to reach me at the university (cs.columbia.edu) or at my office (lmf.ericsson.se). In both places, I have registered myself as being in hut.fi. There request will reach me at hut.fi Regards, Gonzalo Kowsalya Subramanian wrote: > > Hi Gonzalo, > > From my understanding of 16.5, forking will be done by P1 only if its the > edge proxy for the req-uri. The only way the forked request can reach other > proxies is through route headers. so the scenario under question can never > happen or am i missing something?. > > Thanks > Kowsalya > > ----- Original Message ----- > From: Gonzalo Camarillo > To: Jonathan Rosenberg > Cc: Robert Sparks ; Anders Kristensen > ; > Sent: Monday, December 16, 2002 4:24 PM > Subject: Re: [Sip] Constructing the branch parameter at stateless proxies > > > Hi, > > > > I was thiking of an scenario where we may have problems: > > > > +----->S1-----+ > > | v > > UAC--->P1 P2--->UAS > > | ^ > > +----->S2-----+ > > > > The UAC sends an INVITE. P1 forks to S1 and S2 (both stateless). Both S1 > > and S2 will route the INVITE to P2 (stateful). > > > > >From P2 perspective, both INVITEs will have the same branch ID. > > Therefore, P2 will treat the INVITE that arrives later as a > > retransmission of the first INVITE. > > > > P2 could be able to differentiate both INVITEs using the received Via > > parameter or the port number in the Via header. But P2 is not supposed > > to need to include these paramteres when calculating the transaction ID. > > > > In this situation, everything will recover fine (P1 will CANCEL the > > branch that does not return a final response), but it is, nevertheless, > > an error situation. > > > > Thoughts? > > > > Gonzalo > > > > > > > > > > Jonathan Rosenberg wrote: > > > > > > inline. > > > > > > Robert Sparks wrote: > > > > On Wed, 2002-12-04 at 10:11, Anders Kristensen wrote: > > > > > > > >> > > > >>Robert Sparks wrote: > > > >> > > > >>>On Wed, 2002-12-04 at 09:54, Anders Kristensen wrote: > > > >>> > > > >>> > > > >>>>Hi Robert, > > > >>>> > > > >>>>Sounds like a very good idea. One special case to consider is what > > > >>>>happens if the request spirals back to the sending proxy (which > > > >>>>presumably is stateful) -- either directly from the stateless proxy > or > > > >>>>via a number of other stateless proxies. The stateful proxy in this > > > >>>>case will have a server transaction and a client transaction with > the > > > >>>>same id, which might confuse some implementations. > > > >>> > > > >>> > > > >>>This is no different from the same proxy spiraling directly to itself > > > >>>is it? > > > >> > > > >>Well, it's different in that it is NOT spiraling directly to itself > and > > > >>so is currently guaranteed to see a different branch ID in a spiralled > > > >>request. It may be the case that noone depends on this but who knows? > > > > > > > > > > > > Ok - so an implementation _may_ have gone to some effort to ensure > > > > that it wasn't sending a message to itself and is counting on not > > > > seeing the same transaction identifier come back to it. Not a choice > > > > I would recommend, but I can see how someone might have made it. > > > > > > > > We could avoid this with the suffix mechanism you suggest, or we > > > > could add an admonishment to the spec to tell systems to be prepared > > > > to have their transaction ID come back. I'd rather do the second. > > > > > > I agree with Robert. Over time, our view of stateless proxies has > > > changed a lot. Initially, we tried to treat them as the same as stateful > > > ones, but it has become clear that there are important differences (for > > > example, there are restrictions on the types of routing logic that are > > > permitted). > > > > > > One of the big changes in bis was the formal definition of a transaction > > > as being between a client transaction in one element and a server > > > transaction in another (figure 4). Whats important is that the > > > transaction is between transaction-stateful elements (by definition). It > > > would seem very logical, then, that the transaction identifier (the > > > branch ID) would be the same for all messages in this transaction. Since > > > a stateless proxy doesn't muck with the transaction, just forwards > > > messages, I would argue that the transaction ID should stay the same. > > > > > > Indeed, the analogy is similar to the dialog identifiers in a stateful > > > proxy; they too are not modified, since the proxy doesn't act as a > > > termination point of the dialog. If it did (b2bua), it would need to > > > modify those identifiers. > > > > > > > > > > > Well, nothing earth-shattering. Right now, just an increased > probability > > > > that implementation error will lead to protocol failure. Its hard to > get > > > > this right, and we can greatly simplify it. > > > > > > > > My growing distaste for what the stateless proxies are currently doing > > > > comes from seeing it somewhat like a NAT. The transaction is really > > > > between the two stateful elements reguardless of how many stateless > > > > elements lie between. Right now, the stateless elements are > > > > "translating" the transaction identifier as the message goes through. > > > > We haven't identified anything in the protocol that breaks as long > > > > as they do this consistently, but I haven't been able to identify any > > > > benefit to the behavior. > > > > > > I agree. I think its really legacy at this point. > > > > > > -Jonathan R. > > > -- > > > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > > > Chief Scientist First Floor > > > dynamicsoft East Hanover, NJ 07936 > > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > > http://www.jdrosen.net PHONE: (973) 952-5000 > > > http://www.dynamicsoft.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 > > > > -- > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > Telecom R&D Fax : +358 9 299 30 52 > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > Finland http://www.hut.fi/~gonzalo > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Mon Dec 16 10:32:10 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08163 for ; Mon, 16 Dec 2002 10:32:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBGFYes27754 for sip-archive@odin.ietf.org; Mon, 16 Dec 2002 10:34:40 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBGFV6v27483; Mon, 16 Dec 2002 10:31:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBGFQ8v27324 for ; Mon, 16 Dec 2002 10:26:08 -0500 Received: from dyn-tx-arch-crash.dfw.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07877 for ; Mon, 16 Dec 2002 10:23:06 -0500 (EST) Received: from RjS.localdomain (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id gBGFPvI15773; Mon, 16 Dec 2002 09:25:57 -0600 Subject: Re: [Sip] Constructing the branch parameter at stateless proxies From: Robert Sparks To: Gonzalo Camarillo Cc: Jonathan Rosenberg , Anders Kristensen , sip@ietf.org In-Reply-To: <3DFDB100.3476D31C@lmf.ericsson.se> References: <1038933302.911.62.camel@RjS.localdomain> <3DEE251A.5080306@dynamicsoft.com > <1039017937.910.76.camel@RjS.localdomain> <3DEE294A.9080806@dynamicsoft.com> <1039019630.910.132.camel@RjS.localdomain> <3DEEFF6F.3000605@dynamicsoft.com> <3DFDB100.3476D31C@lmf.ericsson.se> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 16 Dec 2002 09:24:05 -0600 Message-Id: <1040052245.912.1.camel@RjS.localdomain> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit inline On Mon, 2002-12-16 at 04:54, Gonzalo Camarillo wrote: > Hi, > > I was thiking of an scenario where we may have problems: > > +----->S1-----+ > | v > UAC--->P1 P2--->UAS > | ^ > +----->S2-----+ > > The UAC sends an INVITE. P1 forks to S1 and S2 (both stateless). Both S1 > and S2 will route the INVITE to P2 (stateful). > > >From P2 perspective, both INVITEs will have the same branch ID. > Therefore, P2 will treat the INVITE that arrives later as a > retransmission of the first INVITE. P1 spawned two branches - why would it use the same branch ID on each of them? > > P2 could be able to differentiate both INVITEs using the received Via > parameter or the port number in the Via header. But P2 is not supposed > to need to include these paramteres when calculating the transaction ID. > > In this situation, everything will recover fine (P1 will CANCEL the > branch that does not return a final response), but it is, nevertheless, > an error situation. > > Thoughts? > > Gonzalo > > > > > Jonathan Rosenberg wrote: > > > > inline. > > > > Robert Sparks wrote: > > > On Wed, 2002-12-04 at 10:11, Anders Kristensen wrote: > > > > > >> > > >>Robert Sparks wrote: > > >> > > >>>On Wed, 2002-12-04 at 09:54, Anders Kristensen wrote: > > >>> > > >>> > > >>>>Hi Robert, > > >>>> > > >>>>Sounds like a very good idea. One special case to consider is what > > >>>>happens if the request spirals back to the sending proxy (which > > >>>>presumably is stateful) -- either directly from the stateless proxy or > > >>>>via a number of other stateless proxies. The stateful proxy in this > > >>>>case will have a server transaction and a client transaction with the > > >>>>same id, which might confuse some implementations. > > >>> > > >>> > > >>>This is no different from the same proxy spiraling directly to itself > > >>>is it? > > >> > > >>Well, it's different in that it is NOT spiraling directly to itself and > > >>so is currently guaranteed to see a different branch ID in a spiralled > > >>request. It may be the case that noone depends on this but who knows? > > > > > > > > > Ok - so an implementation _may_ have gone to some effort to ensure > > > that it wasn't sending a message to itself and is counting on not > > > seeing the same transaction identifier come back to it. Not a choice > > > I would recommend, but I can see how someone might have made it. > > > > > > We could avoid this with the suffix mechanism you suggest, or we > > > could add an admonishment to the spec to tell systems to be prepared > > > to have their transaction ID come back. I'd rather do the second. > > > > I agree with Robert. Over time, our view of stateless proxies has > > changed a lot. Initially, we tried to treat them as the same as stateful > > ones, but it has become clear that there are important differences (for > > example, there are restrictions on the types of routing logic that are > > permitted). > > > > One of the big changes in bis was the formal definition of a transaction > > as being between a client transaction in one element and a server > > transaction in another (figure 4). Whats important is that the > > transaction is between transaction-stateful elements (by definition). It > > would seem very logical, then, that the transaction identifier (the > > branch ID) would be the same for all messages in this transaction. Since > > a stateless proxy doesn't muck with the transaction, just forwards > > messages, I would argue that the transaction ID should stay the same. > > > > Indeed, the analogy is similar to the dialog identifiers in a stateful > > proxy; they too are not modified, since the proxy doesn't act as a > > termination point of the dialog. If it did (b2bua), it would need to > > modify those identifiers. > > > > > > > > Well, nothing earth-shattering. Right now, just an increased probability > > > that implementation error will lead to protocol failure. Its hard to get > > > this right, and we can greatly simplify it. > > > > > > My growing distaste for what the stateless proxies are currently doing > > > comes from seeing it somewhat like a NAT. The transaction is really > > > between the two stateful elements reguardless of how many stateless > > > elements lie between. Right now, the stateless elements are > > > "translating" the transaction identifier as the message goes through. > > > We haven't identified anything in the protocol that breaks as long > > > as they do this consistently, but I haven't been able to identify any > > > benefit to the behavior. > > > > I agree. I think its really legacy at this point. > > > > -Jonathan R. > > -- > > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.dynamicsoft.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 > > -- > Gonzalo Camarillo Phone : +358 9 299 33 71 > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > Telecom R&D Fax : +358 9 299 30 52 > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > Finland http://www.hut.fi/~gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Mon Dec 16 13:04:02 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12475 for ; Mon, 16 Dec 2002 13:04:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBGI6Y204474 for sip-archive@odin.ietf.org; Mon, 16 Dec 2002 13:06:34 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBGI2hv04339; Mon, 16 Dec 2002 13:02:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBGI1fv04248 for ; Mon, 16 Dec 2002 13:01:41 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12323; Mon, 16 Dec 2002 12:58:36 -0500 (EST) Message-Id: <200212161758.MAA12323@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , sip@ietf.org, sipping@ietf.org From: The IESG Date: Mon, 16 Dec 2002 12:58:36 -0500 Subject: [Sip] Protocol Action: The Refer Method to Proposed Standard Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , The IESG has approved publication of The Refer Method as a Proposed Standard. This document is the product of the Session Initiation Protocol Working Group. The IESG contact persons are Allison Mankin and Scott Bradner. Technical Summary This document defines the REFER method. This SIP extension requests that the recipient REFER to a resource provided in the request. It provides a mechanism allowing the party sending the REFER to be notified of the outcome of the referenced request. This can be used to enable many applications, including call transfer. In addition to the REFER method, this document defines the refer event package and the Refer-To request header. Working Group Summary The working group reached good consensus on this document. A header for Referred-by was split out so that it could await authenticated identity. Protocol Quality The document was reviewed for the IESG by Eric Rescorla, Steve Bellovin, and Allison Mankin. Implementations of this method have been tested in interoperability events by a number of vendors. RFC Editor Please replace each instance of: "atlanta.com" with "atlanta.example.com" "biloxi.com" with "biloxi.example.net" "cleveland.com" with "cleveland.example.org" "denver.com" with "denver.example.org" Please add to the end of the document before the Copyright Statement a copy of the RFC 2026 10.4(A) and 10.4(B) notices under the heading Intellectual Property Statement. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Mon Dec 16 22:06:37 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24841 for ; Mon, 16 Dec 2002 22:06:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBH39Fo01131 for sip-archive@odin.ietf.org; Mon, 16 Dec 2002 22:09:15 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBH35Wv00395; Mon, 16 Dec 2002 22:05:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBH31Vv32762 for ; Mon, 16 Dec 2002 22:01:31 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24762 for ; Mon, 16 Dec 2002 21:58:22 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.70]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gBH31JYH018490; Mon, 16 Dec 2002 22:01:20 -0500 (EST) Message-ID: <3DFE937B.7060409@dynamicsoft.com> Date: Mon, 16 Dec 2002 22:01:15 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sparks CC: Gonzalo Camarillo , Anders Kristensen , sip@ietf.org Subject: Re: [Sip] Constructing the branch parameter at stateless proxies References: <1038933302.911.62.camel@RjS.localdomain> <3DEE251A.5080306@dynamicsoft.com > <1039017937.910.76.camel@RjS.localdomain> <3DEE294A.9080806@dynamicsoft.com> <1039019630.910.132.camel@RjS.localdomain> <3DEEFF6F.3000605@dynamicsoft.com> <3DFDB100.3476D31C@lmf.ericsson.se> <1040052245.912.1.camel@RjS.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit inline. Robert Sparks wrote: > inline > On Mon, 2002-12-16 at 04:54, Gonzalo Camarillo wrote: > >>Hi, >> >>I was thiking of an scenario where we may have problems: >> >> +----->S1-----+ >> | v >>UAC--->P1 P2--->UAS >> | ^ >> +----->S2-----+ >> >>The UAC sends an INVITE. P1 forks to S1 and S2 (both stateless). Both S1 >>and S2 will route the INVITE to P2 (stateful). >> >>>From P2 perspective, both INVITEs will have the same branch ID. >>Therefore, P2 will treat the INVITE that arrives later as a >>retransmission of the first INVITE. > > > P1 spawned two branches - why would it use the same branch ID > on each of them? Yes, I was going to ask that too. It should have used two different branch IDs. Indeed, this is a good example of why not touching the branch ID works better. In order for P2 to properly disambiguate the transactions, it needs to have S1 and S2 BOTH correctly set them. GIven the ease with which this is done improperly, having S1 and S2 not change them reduces the chances of a problem. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.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 mailnull@www1.ietf.org Tue Dec 17 03:50:41 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09542 for ; Tue, 17 Dec 2002 03:50:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBH8rMl28445 for sip-archive@odin.ietf.org; Tue, 17 Dec 2002 03:53:22 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBH8nav28222; Tue, 17 Dec 2002 03:49:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBH8jNv28119 for ; Tue, 17 Dec 2002 03:45:23 -0500 Received: from porsta.cs.Helsinki.FI (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09393 for ; Tue, 17 Dec 2002 03:42:11 -0500 (EST) Received: from cs.helsinki.fi (sahtikari.cs.helsinki.fi [128.214.11.165]) by porsta.cs.Helsinki.FI (8.11.6/8.11.6) with ESMTP id gBH8j6B30233; Tue, 17 Dec 2002 10:45:06 +0200 Message-ID: <3DFEE411.7010402@cs.helsinki.fi> Date: Tue, 17 Dec 2002 10:45:05 +0200 From: Simone Leggio User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: fi,en MIME-Version: 1.0 To: veltri@coritel.it CC: sip@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Scalability of the Q-SIP solution Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Luca and all, in the draft-veltri-sip-qsip-01 "SIP extension for QoS support" it is stated as requirement that the resulting architecture should be as scalable as possible. I wonder whether it is possible to reconcile this requirement with the functionalities of a Q-SIP stateful proxy server: is such a server scalable when it has to manage state information pertaining to many flows? On the other hand, in case of stateless configuration, what could be the increase in size of the SIP message? If it is relevant, problems of UDP fragmentation could arise as evidenced in: draft-willis-sip-congestsafe-00 Regards, Simone. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Tue Dec 17 05:27:03 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10844 for ; Tue, 17 Dec 2002 05:27:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBHATVx01081 for sip-archive@odin.ietf.org; Tue, 17 Dec 2002 05:29:31 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHAPtv00999; Tue, 17 Dec 2002 05:25:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBGLr7v17062 for ; Mon, 16 Dec 2002 16:53:07 -0500 Received: from agitator.ibr.cs.tu-bs.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19362; Mon, 16 Dec 2002 16:50:02 -0500 (EST) Received: from hansa.ibr.cs.tu-bs.de (hansa.ibr.cs.tu-bs.de [134.169.34.81]) by agitator.ibr.cs.tu-bs.de (8.12.6/8.12.6/Debian-6Woody) with ESMTP id gBGLqvOI004230 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Mon, 16 Dec 2002 22:52:57 +0100 Received: from hansa.ibr.cs.tu-bs.de (strauss@localhost [127.0.0.1]) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian -4) with ESMTP id gBGLqvAa027815 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Mon, 16 Dec 2002 22:52:57 +0100 Received: (from strauss@localhost) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian -4) id gBGLquXB027812; Mon, 16 Dec 2002 22:52:56 +0100 From: Frank Strauss To: The IESG Cc: RFC Editor , Internet Architecture Board , sip@ietf.org, sipping@ietf.org References: <200212161758.MAA12323@ietf.org> Date: 16 Dec 2002 22:52:56 +0100 In-Reply-To: <200212161758.MAA12323@ietf.org> Message-ID: Lines: 15 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Sip] Re: Protocol Action: The Refer Method to Proposed Standard Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi! IESG> The IESG has approved publication of The Refer Method IESG> as a Proposed Standard. Sorry for being late. -- Really late. :-( I didn't read anything but the abstract. But, wouldn't it be good to express the relation to SIP in the document title, e.g. simply "The SIP Refer Method"? Just a thought. I don't have a strong opinion about this. If it's too late, just let it move on. -frank _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Tue Dec 17 06:02:07 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11386 for ; Tue, 17 Dec 2002 06:02:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBHB4as03024 for sip-archive@odin.ietf.org; Tue, 17 Dec 2002 06:04:36 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHB16v02865; Tue, 17 Dec 2002 06:01:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHAWqv01221 for ; Tue, 17 Dec 2002 05:32:52 -0500 Received: from fox.iptel.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10878 for ; Tue, 17 Dec 2002 05:29:49 -0500 (EST) Received: from jku07.fokus.fraunhofer.de (port-212-202-201-139.reverse.qdsl-home.de [212.202.201.139]) by fox.iptel.org (8.11.6/8.11.6) with ESMTP id gBHAWbg31973; Tue, 17 Dec 2002 11:32:37 +0100 Message-Id: <5.2.0.9.0.20021217105820.02caaeb8@mailhost.fokus.gmd.de> X-Sender: jku@mailhost.fokus.gmd.de (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 17 Dec 2002 11:04:38 +0100 To: Robert Sparks , sip@ietf.org From: Jiri Kuthan Subject: Re: [Sip] Constructing the branch parameter at stateless proxies In-Reply-To: <1038933302.911.62.camel@RjS.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Do we really need to specify algorithms for branch computing? Isn't it sufficient to mandate uniquiness within address in Via, so that downstream elements can use it for transaction matching? Implementers may decide whether their branch construction features additional properties such as loop detection, transaction matching ability and whatsoever. If you still like to do that, I see a possible problem with your specific proposal. The spec now promises the branch parameter to be unique within space of address stated in Via. If a proxy only reuses branch, it effectively merges two spaces, which may result in a collision. That would prevent a downstream server from recognizing two such requests as parts of distinct transactions. -Jiri ps -- regarding your motivation to have a globaly unique tid for the purpose of diagnostics -- can't bottommost via make the job? At 05:35 PM 12/3/2002, Robert Sparks wrote: >This list has seen a couple of requests to clarify the language in >RFC 3261 concerning how a stateless proxy creates a branch identifier. > >The current text requires uniqueness, dependency on route decision >affecting parameters and care to be sure that those parameters are >retransmission invariant. It goes on to recommend a hash over a >set of fields (this set has been the subject of the requests for >clarification). > >I think there's a much simpler solution. The purpose of this >branch parameter is to act as a transaction identifier. Who >cares about this identifier? Only the stateful elements at >each end of the transaction. Any stateless proxies between >these elements don't use that identifier in any of their >decisions, so I assert that it is not useful to change it >as it crosses the stateless proxy. > >I propose, then, that a stateless proxy simply copy >the branch parameter from the topmost Via header field >value it receives into the Via header field value it adds >to the request. > >I don't believe it matters that this parameter contain the >magic cookie. If it doesn't, the next stateful hop will use >the 2543-style transaction identifiers provided by the sending >stateful element. The stateless elements are by definition >transaction transparent. > >So - can anyone construct a scenario where this doesn't >function correctly? If not, we can remove several convoluted >paragraphs from the spec and replace them with a very simple >couple of sentences. > >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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Tue Dec 17 06:54:16 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12013 for ; Tue, 17 Dec 2002 06:54:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBHBukB05673 for sip-archive@odin.ietf.org; Tue, 17 Dec 2002 06:56:46 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHBr7v05571; Tue, 17 Dec 2002 06:53:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHBjBv05399 for ; Tue, 17 Dec 2002 06:45:11 -0500 Received: from softfront.co.jp (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA11855 for ; Tue, 17 Dec 2002 06:42:09 -0500 (EST) Received: (qmail 21157 invoked from network); 17 Dec 2002 20:45:03 +0900 Received: from mail2.softfront.co.jp (172.16.1.41) by gw-l.softfront.co.jp with SMTP; 17 Dec 2002 20:45:03 +0900 Received: from wstar by mail2.softfront.co.jp id AA01564 ; 17 Dec 2002 20:43:07 +0900 Date: Tue, 17 Dec 2002 20:45:00 +0900 From: OKUMURA Shinji To: sip@ietf.org Organization: SOFTFRONT X-Priority: 3 X-Mailer: Datula version 1.50.45 for Windows Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Message-Id: <200212171143.AA01564@mail2.softfront.co.jp> Subject: [Sip] Query on 'new offer' during INVITE-PRACK transaction Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi Folks, I have one question concerning a new offer inclusion during a transaction of INVITE-PRACK at stated in the following figure. Here my question goes, is it possible to include a new 'offer 2' within 200 INVITE at line (5) and the corresponding 'answer 2' in ACK at line (6)? Thanks in advance for your kind response. Caller Callee | | | | |(1) INVITE with offer 1 | |---------------------------->| | | | | |(2) 180 INVITE with answer 1 | |<----------------------------| | Require: 100rel | | | | | |(3) PRACK | |---------------------------->| | | | | |(4) 200 PRACK | |<----------------------------| | | | | |(5) 200 INVITE with offer 2 | |<----------------------------| | | | | |(6) ACK with answer 3 | |---------------------------->| | | | | Best regards, _________________________________________________________ OKUMURA Shinji E-mail:shin@softfront.co.jp _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Tue Dec 17 07:22:31 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12426 for ; Tue, 17 Dec 2002 07:22:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBHCP1h07056 for sip-archive@odin.ietf.org; Tue, 17 Dec 2002 07:25:01 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHCLTv06937; Tue, 17 Dec 2002 07:21:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHCEUv06737 for ; Tue, 17 Dec 2002 07:14:30 -0500 Received: from hss.hns.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12253 for ; Tue, 17 Dec 2002 07:11:26 -0500 (EST) From: ssundaragopalan@hss.hns.com Received: from sampark.hss.hns.com (sampark [139.85.229.22]) by hss.hns.com (8.11.6/8.11.2) with SMTP id gBHBoki03380; Tue, 17 Dec 2002 17:20:54 +0530 Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256C92.0042D7CA ; Tue, 17 Dec 2002 17:40:06 +0530 X-Lotus-FromDomain: HSSBLR To: OKUMURA Shinji cc: sip@ietf.org Message-ID: <65256C92.0042D70D.00@sampark.hss.hns.com> Date: Tue, 17 Dec 2002 17:40:03 +0530 Subject: Re: [Sip] Query on 'new offer' during INVITE-PRACK transaction Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi, " If the initial offer is in an INVITE, the answer MUST be in a reliable non-failure message from UAS back to UAC which is correlated to that INVITE. For this specification, that is only the final 2xx response to that INVITE. That same exact answer MAY also be placed in any provisional responses sent prior to the answer. * The UAC MUST treat the first session description it receives as the answer, and MUST ignore any session descriptions in subsequent responses to the initial INVITE.* ", According to the above excerpt from RFC 3261, you cant send a *newoffer* in 200 OK. If an *answer* is sent in any Reliable Provisional Response,then any session description in subsequent responses(including 200OK for INVITE) should be ignored.So,though you send a *newoffer*, your session description in 200OK will be ignored. If at all you want to propose a *newoffer*,you should use *Update* for the same. regds, srikanth sundaragopalan OKUMURA Shinji on 12/17/2002 05:15:00 PM To: sip@ietf.org cc: (bcc: Srikanth Sundaragopalan/HSSBLR) Subject: [Sip] Query on 'new offer' during INVITE-PRACK transaction Hi Folks, I have one question concerning a new offer inclusion during a transaction of INVITE-PRACK at stated in the following figure. Here my question goes, is it possible to include a new 'offer 2' within 200 INVITE at line (5) and the corresponding 'answer 2' in ACK at line (6)? Thanks in advance for your kind response. Caller Callee | | | | |(1) INVITE with offer 1 | |---------------------------->| | | | | |(2) 180 INVITE with answer 1 | |<----------------------------| | Require: 100rel | | | | | |(3) PRACK | |---------------------------->| | | | | |(4) 200 PRACK | |<----------------------------| | | | | |(5) 200 INVITE with offer 2 | |<----------------------------| | | | | |(6) ACK with answer 3 | |---------------------------->| | | | | Best regards, _________________________________________________________ OKUMURA Shinji E-mail:shin@softfront.co.jp _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Tue Dec 17 09:14:32 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14189 for ; Tue, 17 Dec 2002 09:14:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBHEH3Z12933 for sip-archive@odin.ietf.org; Tue, 17 Dec 2002 09:17:03 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHE9pv12730; Tue, 17 Dec 2002 09:09:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHE6Zv12007 for ; Tue, 17 Dec 2002 09:06:35 -0500 Received: from fox.iptel.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14074 for ; Tue, 17 Dec 2002 09:03:32 -0500 (EST) Received: from jku07.iptel.org (port-212-202-201-139.reverse.qdsl-home.de [212.202.201.139]) by fox.iptel.org (8.11.6/8.11.6) with ESMTP id gBHE6Tg01091 for ; Tue, 17 Dec 2002 15:06:29 +0100 Message-Id: <5.2.0.9.0.20021217144447.00b53ac8@iptel.org> X-Sender: jiri@iptel.org (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 17 Dec 2002 14:58:15 +0100 To: sip@ietf.org From: Jiri Kuthan Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [Sip] Replies to ACK Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , I would like to verify with the mailing list whether negative replies to ACKs are legal or not. Clearly, it makes no use to solicit positive reply for a "good" ACK and it is explicitely prohibited to challenge ACKs. However, what about "bad" ACKs? Let's say an ACK misses 'CallID' or has a broken r-uri -- should it be replied the same way as say BYE/INFO/FOOBAR requests? Some implementations do that and it helps upstream clients to understand what has gone wrong. Some implementations don't do that. Can a spec-interpreter share with my an opinion on this? Thanks, -Jiri -- Jiri Kuthan http://iptel.org/~jiri/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Tue Dec 17 10:02:40 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15088 for ; Tue, 17 Dec 2002 10:02:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBHF5CY15194 for sip-archive@odin.ietf.org; Tue, 17 Dec 2002 10:05:12 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHEvuv14911; Tue, 17 Dec 2002 09:57:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHEs9v14830 for ; Tue, 17 Dec 2002 09:54:09 -0500 Received: from auemail2.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14855 for ; Tue, 17 Dec 2002 09:51:06 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by auemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id gBHEs5o14707 for ; Tue, 17 Dec 2002 09:54:05 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 17 Dec 2002 14:54:04 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00439EB56@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Jiri Kuthan'" , sip@ietf.org Subject: RE: [Sip] Replies to ACK Date: Tue, 17 Dec 2002 14:54:03 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , I would have expected this to occur only if the request was so broken that it could not be recognised as an ACK and I am not sure whether this is possible. I note that the security clauses of RFC 3261 explicitly preclude any challenge (401 or 407) to an ACK. My understanding of section 17 4th paragraph [The client transaction is also responsible for receiving responses and delivering them to the TU, filtering out any response retransmissions or disallowed responses (such as a response to ACK)].is that if a proxy receives such a response, it would kill it at the client transaction, so the sender would probably not see the response anyway. This would imply to me that there is no advantage to sending a response to ACK even for fault detection purposes. Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com > -----Original Message----- > From: Jiri Kuthan [mailto:jiri@iptel.org] > Sent: 17 December 2002 13:58 > To: sip@ietf.org > Subject: [Sip] Replies to ACK > > > I would like to verify with the mailing list whether negative > replies to > ACKs are legal or not. > > Clearly, it makes no use to solicit positive reply for a > "good" ACK and > it is explicitely prohibited to challenge ACKs. However, what > about "bad" > ACKs? Let's say an ACK misses 'CallID' or has a broken r-uri > -- should it > be replied the same way as say BYE/INFO/FOOBAR requests? > > Some implementations do that and it helps upstream clients to > understand > what has gone wrong. Some implementations don't do that. > > Can a spec-interpreter share with my an opinion on this? > > Thanks, > > -Jiri > > > -- > Jiri Kuthan http://iptel.org/~jiri/ > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Tue Dec 17 10:29:56 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15646 for ; Tue, 17 Dec 2002 10:29:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBHFWTA16809 for sip-archive@odin.ietf.org; Tue, 17 Dec 2002 10:32:29 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHFPhv16591; Tue, 17 Dec 2002 10:25:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHFM8v16504 for ; Tue, 17 Dec 2002 10:22:08 -0500 Received: from mail1.telekom.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15461 for ; Tue, 17 Dec 2002 10:19:05 -0500 (EST) Received: from g9jbr.mgb01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Tue, 17 Dec 2002 16:04:40 +0100 Received: by G9JBR.mgb01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Tue, 17 Dec 2002 16:04:39 +0100 Message-Id: From: "Alexeitsev, D" To: Gonzalo.Camarillo@lmf.ericsson.se Cc: sip@ietf.org Subject: RE: [Sip] Use of Tel URL in To header Date: Tue, 17 Dec 2002 16:04:34 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hello All Sorry for the jumping onto the asked question, but I'm really interested why could not it be just said that in case that the caller did not have any preferences the address of the outbound proxy shall be used as hostport? And then it is as in the tel: URI case the issue of the proxy to route it wherever it wants. like: sip:411@outbound.airport.com;user=phone Greetings, Denis Alexeitsev >That is what the text in 8.1.1.2 is trying to say. Since the caller does >not have any specific domain in mind, it uses a tel URL. > >Alternatively, the caller could have dialed >sip:411@ericsson.com;user=phone > >In this situation, 411 would have been evaluated in the domain >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 mailnull@www1.ietf.org Tue Dec 17 10:45:42 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16095 for ; Tue, 17 Dec 2002 10:45:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBHFmF918205 for sip-archive@odin.ietf.org; Tue, 17 Dec 2002 10:48:15 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHFfXv17866; Tue, 17 Dec 2002 10:41:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHFcRv17684 for ; Tue, 17 Dec 2002 10:38:27 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15782 for ; Tue, 17 Dec 2002 10:35:23 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gBHFcEKV015949; Tue, 17 Dec 2002 16:38:14 +0100 (MET) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id Y519D12W; Tue, 17 Dec 2002 16:38:14 +0100 Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.80]) by hendrix.lmf.ericsson.se (8.12.6/8.12.6/lmf-2.1-jcs) with ESMTP id gBHFcEu4022406; Tue, 17 Dec 2002 17:38:14 +0200 (EET) Message-ID: <3DFF44E3.4DE97831@lmf.ericsson.se> Date: Tue, 17 Dec 2002 17:38:11 +0200 X-Sybari-Trust: 81eade30 1864f774 2a3f1235 00000138 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Alexeitsev, D" CC: sip@ietf.org Subject: Re: [Sip] Use of Tel URL in To header References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, If I understand your suggestion, you are suggesting that we re-phrase the sentence, right? If this is the case, it is far too late for that type of change. Thanks, Gonzalo "Alexeitsev, D" wrote: > > Hello All > > Sorry for the jumping onto the asked question, but I'm really interested why could not it be just said that in case that the caller did not have any preferences the address of the outbound proxy shall be used as hostport? And then it is as in the tel: URI case the issue of the proxy to route it wherever it wants. > > like: > > sip:411@outbound.airport.com;user=phone > > Greetings, > Denis Alexeitsev > > >That is what the text in 8.1.1.2 is trying to say. Since the caller does > >not have any specific domain in mind, it uses a tel URL. > > > >Alternatively, the caller could have dialed > >sip:411@ericsson.com;user=phone > > > >In this situation, 411 would have been evaluated in the domain > >ericsson.com -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Tue Dec 17 11:09:50 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16467 for ; Tue, 17 Dec 2002 11:09:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBHGCLh19628 for sip-archive@odin.ietf.org; Tue, 17 Dec 2002 11:12:21 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHG5Wv18830; Tue, 17 Dec 2002 11:05:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHG29v18711 for ; Tue, 17 Dec 2002 11:02:09 -0500 Received: from mail1.telekom.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16290 for ; Tue, 17 Dec 2002 10:59:07 -0500 (EST) Received: from g9jbr.mgb01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Tue, 17 Dec 2002 17:02:05 +0100 Received: by G9JBR.mgb01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Tue, 17 Dec 2002 17:02:05 +0100 Message-Id: From: "Alexeitsev, D" To: Gonzalo.Camarillo@lmf.ericsson.se Cc: sip@ietf.org Subject: RE: [Sip] Use of Tel URL in To header Date: Tue, 17 Dec 2002 17:02:04 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hello Gonzalo, No I was not proposing any changes to the baseline, I was just trying to clarify how tel URI is used in the SIP environment. As the tel URI spec itself does not specify semantics for tel URI it is important to have a clear definition about it's application in SIP environment. So far the only use I could recognise in SIP was to transfer the processing of the userpart of Request-URI to local proxy and this could be achieved by native SIP procedures. If this is correct observation then probably some additional clarifications are required concerning the use of tel URI in SIP, that could be realised outside of the RFC 3261 Greetings, Denis Alexeitsev -----Original Message----- From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] Sent: Tuesday, December 17, 2002 4:38 PM To: Alexeitsev, D Cc: sip@ietf.org Subject: Re: [Sip] Use of Tel URL in To header Hi, If I understand your suggestion, you are suggesting that we re-phrase the sentence, right? If this is the case, it is far too late for that type of change. Thanks, Gonzalo "Alexeitsev, D" wrote: > > Hello All > > Sorry for the jumping onto the asked question, but I'm really interested why could not it be just said that in case that the caller did not have any preferences the address of the outbound proxy shall be used as hostport? And then it is as in the tel: URI case the issue of the proxy to route it wherever it wants. > > like: > > sip:411@outbound.airport.com;user=phone > > Greetings, > Denis Alexeitsev > > >That is what the text in 8.1.1.2 is trying to say. Since the caller does > >not have any specific domain in mind, it uses a tel URL. > > > >Alternatively, the caller could have dialed > >sip:411@ericsson.com;user=phone > > > >In this situation, 411 would have been evaluated in the domain > >ericsson.com -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Tue Dec 17 12:01:03 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17543 for ; Tue, 17 Dec 2002 12:01:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBHH3ZS22169 for sip-archive@odin.ietf.org; Tue, 17 Dec 2002 12:03:35 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHGudv21674; Tue, 17 Dec 2002 11:56:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHGrbv21564 for ; Tue, 17 Dec 2002 11:53:37 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17291 for ; Tue, 17 Dec 2002 11:50:33 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gBHGrGAv015270; Tue, 17 Dec 2002 17:53:16 +0100 (MET) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id Y8JAQSDD; Tue, 17 Dec 2002 17:53:16 +0100 Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.106.10]) by hendrix.lmf.ericsson.se (8.12.6/8.12.6/lmf-2.1-jcs) with ESMTP id gBHGrGu4026475; Tue, 17 Dec 2002 18:53:16 +0200 (EET) Message-ID: <3DFF567A.74DC0431@lmf.ericsson.se> Date: Tue, 17 Dec 2002 18:53:14 +0200 X-Sybari-Trust: 43bf2eb2 1864f774 2a3f1235 00000138 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Alexeitsev, D" CC: Gonzalo.Camarillo@lmf.ericsson.se, sip@ietf.org Subject: Re: [Sip] Use of Tel URL in To header References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Denis, Please remember that we are allowed to use basically ANY kind of URI in the Request-URI, so even if we would add some clarifying text for TEL-URLs we would have the same routing problem for other URIs. Regards, Christer Holmberg Ericsson Finland "Alexeitsev, D" wrote: > Hello Gonzalo, > > No I was not proposing any changes to the baseline, I was just trying to clarify how tel URI is used in the SIP environment. > As the tel URI spec itself does not specify semantics for tel URI it is important to have a clear definition about it's application in SIP environment. So far the only use I could recognise in SIP was to transfer the processing of the userpart of Request-URI to local proxy and this could be achieved by native SIP procedures. > If this is correct observation then probably some additional clarifications are required concerning the use of tel URI in SIP, that could be realised outside of the RFC 3261 > > Greetings, > Denis Alexeitsev > > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Sent: Tuesday, December 17, 2002 4:38 PM > To: Alexeitsev, D > Cc: sip@ietf.org > Subject: Re: [Sip] Use of Tel URL in To header > > Hi, > > If I understand your suggestion, you are suggesting that we re-phrase > the sentence, right? If this is the case, it is far too late for that > type of change. > > Thanks, > > Gonzalo > > "Alexeitsev, D" wrote: > > > > Hello All > > > > Sorry for the jumping onto the asked question, but I'm really interested why could not it be just said that in case that the caller did not have any preferences the address of the outbound proxy shall be used as hostport? And then it is as in the tel: URI case the issue of the proxy to route it wherever it wants. > > > > like: > > > > sip:411@outbound.airport.com;user=phone > > > > Greetings, > > Denis Alexeitsev > > > > >That is what the text in 8.1.1.2 is trying to say. Since the caller does > > >not have any specific domain in mind, it uses a tel URL. > > > > > >Alternatively, the caller could have dialed > > >sip:411@ericsson.com;user=phone > > > > > >In this situation, 411 would have been evaluated in the domain > > >ericsson.com > > -- > Gonzalo Camarillo Phone : +358 9 299 33 71 > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > Telecom R&D Fax : +358 9 299 30 52 > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > Finland http://www.hut.fi/~gonzalo > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Tue Dec 17 12:04:29 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17683 for ; Tue, 17 Dec 2002 12:04:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBHH71L22620 for sip-archive@odin.ietf.org; Tue, 17 Dec 2002 12:07:01 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHGxkv21790; Tue, 17 Dec 2002 11:59:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHGuev21676 for ; Tue, 17 Dec 2002 11:56:40 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17338 for ; Tue, 17 Dec 2002 11:53:37 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gBHGuZAv015736; Tue, 17 Dec 2002 17:56:35 +0100 (MET) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id Y519D4GK; Tue, 17 Dec 2002 17:56:35 +0100 Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.106.10]) by hendrix.lmf.ericsson.se (8.12.6/8.12.6/lmf-2.1-jcs) with ESMTP id gBHGuZu4026733; Tue, 17 Dec 2002 18:56:35 +0200 (EET) Message-ID: <3DFF5741.C239EAC5@lmf.ericsson.se> Date: Tue, 17 Dec 2002 18:56:33 +0200 X-Sybari-Trust: 5a2fedf7 1864f774 2a3f1235 00000138 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Drage, Keith (Keith)" CC: "'Jiri Kuthan'" , sip@ietf.org Subject: Re: [Sip] Replies to ACK References: <475FF955A05DD411980D00508B6D5FB00439EB56@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, Since the ACK will stop the re-transmission of the final response, if the re-transmissions of the final responses keep coming it does indicate to the UAC that something (even if not exactly what) is wrong. Regards, Christer Holmberg Ericsson Finland "Drage, Keith (Keith)" wrote: > I would have expected this to occur only if the request was so broken that it could not be recognised as an ACK and I am not sure whether this is possible. > > I note that the security clauses of RFC 3261 explicitly preclude any challenge (401 or 407) to an ACK. > > My understanding of section 17 4th paragraph [The client transaction is also responsible for receiving responses and delivering them to the TU, filtering out any response retransmissions or disallowed responses (such as a response to ACK)].is that if a proxy receives such a response, it would kill it at the client transaction, so the sender would probably not see the response anyway. This would imply to me that there is no advantage to sending a response to ACK even for fault detection purposes. > > Keith > > Keith Drage > Lucent Technologies > Tel: +44 1793 776249 > Email: drage@lucent.com > > > -----Original Message----- > > From: Jiri Kuthan [mailto:jiri@iptel.org] > > Sent: 17 December 2002 13:58 > > To: sip@ietf.org > > Subject: [Sip] Replies to ACK > > > > > > I would like to verify with the mailing list whether negative > > replies to > > ACKs are legal or not. > > > > Clearly, it makes no use to solicit positive reply for a > > "good" ACK and > > it is explicitely prohibited to challenge ACKs. However, what > > about "bad" > > ACKs? Let's say an ACK misses 'CallID' or has a broken r-uri > > -- should it > > be replied the same way as say BYE/INFO/FOOBAR requests? > > > > Some implementations do that and it helps upstream clients to > > understand > > what has gone wrong. Some implementations don't do that. > > > > Can a spec-interpreter share with my an opinion on this? > > > > Thanks, > > > > -Jiri > > > > > > -- > > Jiri Kuthan http://iptel.org/~jiri/ > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Tue Dec 17 12:53:51 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18913 for ; Tue, 17 Dec 2002 12:53:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBHHuNv25758 for sip-archive@odin.ietf.org; Tue, 17 Dec 2002 12:56:23 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHHnZv25497; Tue, 17 Dec 2002 12:49:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBHHkNv25401 for ; Tue, 17 Dec 2002 12:46:23 -0500 Received: from fox.iptel.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18691 for ; Tue, 17 Dec 2002 12:43:20 -0500 (EST) Received: from jku07.iptel.org (port-212-202-201-58.reverse.qdsl-home.de [212.202.201.58]) by fox.iptel.org (8.11.6/8.11.6) with ESMTP id gBHHkBg02798; Tue, 17 Dec 2002 18:46:11 +0100 Message-Id: <5.2.0.9.0.20021217182442.0291c008@iptel.org> X-Sender: jiri@iptel.org (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 17 Dec 2002 18:37:12 +0100 To: Christer Holmberg , "Drage, Keith (Keith)" From: Jiri Kuthan Subject: Re: [Sip] Replies to ACK Cc: sip@ietf.org In-Reply-To: <3DFF5741.C239EAC5@lmf.ericsson.se> References: <475FF955A05DD411980D00508B6D5FB00439EB56@en0033exch001u.uk.lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , At 05:56 PM 12/17/2002, Christer Holmberg wrote: >Hi, > >Since the ACK will stop the re-transmission of the final response, if the re-transmissions of the final responses keep coming it does indicate to the UAC that something (even if not exactly what) is wrong. ^^^^^^^^^^^^^^^^^^^^^^^^^ That's the primary argument, I think, some implementers have decided to send replies to ACKs. (However surprising this technique may sound [to me too], I don't see it breaks the spec, except challenges are prohibitted.) An assertation "the r-uri which made it to me is bad" is certainly much more useful than one-bit diagnostic assertation "something is wrong". -Jiri _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Tue Dec 17 19:27:26 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27631 for ; Tue, 17 Dec 2002 19:27:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBI0U2U15681 for sip-archive@odin.ietf.org; Tue, 17 Dec 2002 19:30:02 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBI0MVv15365; Tue, 17 Dec 2002 19:22:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBI0F4v15176 for ; Tue, 17 Dec 2002 19:15:04 -0500 Received: from imo-d09.mx.aol.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27215 for ; Tue, 17 Dec 2002 19:11:57 -0500 (EST) Received: from bertculpepper@netscape.net by imo-d09.mx.aol.com (mail_out_v34.13.) id r.1c.6807a0a (22680); Tue, 17 Dec 2002 19:14:51 -0500 (EST) Received: from netscape.net (159.252.8.67.cfl.rr.com [67.8.252.159]) by air-in04.mx.aol.com (v89.21) with ESMTP id MAILININ41-1217191451; Tue, 17 Dec 2002 19:14:51 -0500 Message-ID: <3DFFBE79.2040706@netscape.net> Date: Tue, 17 Dec 2002 19:16:57 -0500 From: Bert Culpepper User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 To: sathish kumar CC: sip@ietf.org, sip-implementors@cs.columbia.edu References: <20021217101736.10903.qmail@web40702.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Mailer: Unknown (No Version) Content-Transfer-Encoding: 7bit Subject: [Sip] Re: [Sip-implementors] (no subject) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Standardization of mechanisms on sending DTMF in INFO has not occurred. For SIP, the use of DTMF is seen as a means for user interaction with network-based applications. To this end, work is ongoing on to define a framework and mechanisms for users to interact with applications in SIP. See the I-Ds below for how this is expected to be supported. http://www.ietf.org/internet-drafts/draft-culpepper-sipping-app-interact-reqs-02.txt http://www.jdrosen.net/papers/draft-rosenberg-sipping-app-interaction-framework-00.txt http://www.ietf.org/internet-drafts/draft-burger-sipping-kpml-00.txt http://www.ietf.org/internet-drafts/draft-jennings-sip-app-info-00.txt Regards, Bert sathish kumar wrote: > Hi, > > Pertaining to the SIP INFO method defined in RFC 2976 used for sending > mid call signaling information. > > After establishment of Voice path between two user agents i wish to send > the DTMF digits from UAC to UAS. > > 1. Can anyone tell me the format of sending the information (Header, > Message Body if any). > > thanx and regards > > sathises. > > > ------------------------------------------------------------------------ > Do you Yahoo!? > Yahoo! Mail Plus > - > Powerful. Affordable. Sign up now > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Tue Dec 17 20:58:30 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29189 for ; Tue, 17 Dec 2002 20:58:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBI217M20849 for sip-archive@odin.ietf.org; Tue, 17 Dec 2002 21:01:07 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBI1ruv20485; Tue, 17 Dec 2002 20:53:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBI1ncv20300 for ; Tue, 17 Dec 2002 20:49:38 -0500 Received: from david.sae.siemens.com.sg (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28974 for ; Tue, 17 Dec 2002 20:46:28 -0500 (EST) X-Envelope-Sender-Is: kokjeng.loh@siemens.com (at relayer david.sae.siemens.com.sg) Received: from mail.sae.siemens.com.sg (mail.sae.siemens.com.sg [194.138.237.14]) by david.sae.siemens.com.sg (8.11.6/8.11.6) with ESMTP id gBI1kQl11604 for ; Wed, 18 Dec 2002 09:46:26 +0800 (SGT) Received: from sgpk001a.sae.siemens.com.sg (sgpk001a.sae.siemens.com.sg [140.231.107.1]) by mail.sae.siemens.com.sg (8.11.6/8.11.6) with ESMTP id gBI1lhE02696 for ; Wed, 18 Dec 2002 09:47:43 +0800 (SGT) Received: by sgpk001a.sae.siemens.com.sg with Internet Mail Service (5.5.2655.55) id ; Wed, 18 Dec 2002 09:40:49 +0800 Message-ID: <7319EDDDE0CD7C458023FF64886CB177032A1EAB@sgpk001a.sae.siemens.com.sg> From: Loh Kok Jeng To: sip@ietf.org Date: Wed, 18 Dec 2002 09:40:49 +0800 X-Mailer: Internet Mail Service (5.5.2655.55) Subject: [Sip] Contact in REGISTER Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Dear all, Suppose there is no binding at all for an Address-of-Record, and the Registrar receives a REGISTER message with "Contact: *" for that particular address-of-record, how should the Registrar handle it? Likewise, if the Contact header is missing, what should the Registrar do? In both cases, there is no additional contact information carried in the REGISTER message. So effectively the Registrar still doesn't know the contact binding of the Address-of-Record. Thanks. regards, KJ Loh _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Tue Dec 17 22:52:15 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01423 for ; Tue, 17 Dec 2002 22:52:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBI3srF26588 for sip-archive@odin.ietf.org; Tue, 17 Dec 2002 22:54:53 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBI3pDv26513; Tue, 17 Dec 2002 22:51:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBI3luv26412 for ; Tue, 17 Dec 2002 22:47:56 -0500 Received: from dharti.aplion.stpn.soft.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01373 for ; Tue, 17 Dec 2002 22:44:42 -0500 (EST) Received: from ravishiroor (localhost [127.0.0.1]) by dharti.aplion.stpn.soft.net (8.11.2/8.11.2) with SMTP id gBI3lsV18766; Wed, 18 Dec 2002 09:17:55 +0530 From: "Ravi Shiroor" To: "Jiri Kuthan" , Subject: RE: [Sip] Replies to ACK Date: Wed, 18 Dec 2002 09:15:25 +0530 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <5.2.0.9.0.20021217144447.00b53ac8@iptel.org> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit ACK is a part of the three way handshake unlike other methods. So I think it would not need a negetive reply to it. Implementing a negetive reply to help an upstream client can only be a debugging mechanism, but what then if the negetive reply gets broken? Should we have a negetive reply for a broken negetive reply? regards, ravi. > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Jiri > Kuthan > Sent: Tuesday, December 17, 2002 7:28 PM > To: sip@ietf.org > Subject: [Sip] Replies to ACK > > > I would like to verify with the mailing list whether negative replies to > ACKs are legal or not. > > Clearly, it makes no use to solicit positive reply for a "good" ACK and > it is explicitely prohibited to challenge ACKs. However, what about "bad" > ACKs? Let's say an ACK misses 'CallID' or has a broken r-uri -- should it > be replied the same way as say BYE/INFO/FOOBAR requests? > > Some implementations do that and it helps upstream clients to understand > what has gone wrong. Some implementations don't do that. > > Can a spec-interpreter share with my an opinion on this? > > Thanks, > > -Jiri > > > -- > Jiri Kuthan http://iptel.org/~jiri/ > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Wed Dec 18 02:04:53 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10567 for ; Wed, 18 Dec 2002 02:04:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBI77Wn08004 for sip-archive@odin.ietf.org; Wed, 18 Dec 2002 02:07:32 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBI73fv05513; Wed, 18 Dec 2002 02:03:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBI6xPv03310 for ; Wed, 18 Dec 2002 01:59:25 -0500 Received: from hss.hns.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04198 for ; Wed, 18 Dec 2002 01:56:11 -0500 (EST) From: sunayak@hss.hns.com Received: from sampark.hss.hns.com (sampark [139.85.229.22]) by hss.hns.com (8.11.6/8.11.2) with SMTP id gBI40Oi04854; Wed, 18 Dec 2002 09:34:24 +0530 Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256C93.0017C876 ; Wed, 18 Dec 2002 09:49:46 +0530 X-Lotus-FromDomain: HSSBLR To: Loh Kok Jeng cc: sip@ietf.org Message-ID: <65256C93.0017C7AF.00@sampark.hss.hns.com> Date: Wed, 18 Dec 2002 09:49:43 +0530 Subject: Re: [Sip] Contact in REGISTER Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi Loh, In both cases, the registrar should respond with a 200 OK containing no Contacts. Whenever a registrar responds to a REGISTER request it includes the bindings that are currently known to it in the response. (The second case that you refer to, is equivalent to a query to the registrar to fetch the current bindings). Regards, Subhash. P.S.> Implementation related questions can be addressed to sip-implementors@cs.columbia.edu Loh Kok Jeng on 12/18/2002 07:10:49 AM To: sip@ietf.org cc: (bcc: Subhash Ullal Nayak/HSSBLR) Subject: [Sip] Contact in REGISTER Dear all, Suppose there is no binding at all for an Address-of-Record, and the Registrar receives a REGISTER message with "Contact: *" for that particular address-of-record, how should the Registrar handle it? Likewise, if the Contact header is missing, what should the Registrar do? In both cases, there is no additional contact information carried in the REGISTER message. So effectively the Registrar still doesn't know the contact binding of the Address-of-Record. Thanks. regards, KJ Loh _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Wed Dec 18 06:15:32 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02073 for ; Wed, 18 Dec 2002 06:15:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBIBI2v28580 for sip-archive@odin.ietf.org; Wed, 18 Dec 2002 06:18:02 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBIBEAv28430; Wed, 18 Dec 2002 06:14:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBIB95v28306 for ; Wed, 18 Dec 2002 06:09:05 -0500 Received: from hoemail1.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01984 for ; Wed, 18 Dec 2002 06:06:04 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by hoemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id gBIB92s13277 for ; Wed, 18 Dec 2002 06:09:02 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 18 Dec 2002 11:09:01 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00439EB5C@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Jiri Kuthan'" , Christer Holmberg , "Drage, Keith (Keith)" Cc: sip@ietf.org Subject: RE: [Sip] Replies to ACK Date: Wed, 18 Dec 2002 11:09:00 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Remember we do not tend to write standards stating what is precluded. There is an implicit assumption that what is not allowed is precluded. Certainly any equipment claiming conformance to RFC 3261 should list this as an exception, like any other extensions, as it is not explicitly required by RFC 3261. I would also still question the use. There seems to be little point in responding when as far as I read RFC 3261, any intermediate proxy would kill the incoming response message at the client process, and not pass it up to the transaction layer for further processing. The sort of error detection you are talking about would need to be done by the sender of the ACK, which would be this proxy only for ACK following non 2xx final responses. Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com > -----Original Message----- > From: Jiri Kuthan [mailto:jiri@iptel.org] > Sent: 17 December 2002 17:37 > To: Christer Holmberg; Drage, Keith (Keith) > Cc: sip@ietf.org > Subject: Re: [Sip] Replies to ACK > > > At 05:56 PM 12/17/2002, Christer Holmberg wrote: > > >Hi, > > > >Since the ACK will stop the re-transmission of the final > response, if the re-transmissions of the final responses keep > coming it does indicate to the UAC that something (even if > not exactly what) is wrong. > > ^^^^^^^^^^^^^^^^^^^^^^^^^ > That's the primary argument, I think, some implementers have > decided to send replies > to ACKs. (However surprising this technique may sound [to me > too], I don't see it > breaks the spec, except challenges are prohibitted.) An > assertation "the r-uri which > made it to me is bad" is certainly much more useful than > one-bit diagnostic assertation > "something is wrong". > > -Jiri > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Wed Dec 18 06:18:08 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02154 for ; Wed, 18 Dec 2002 06:18:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBIBKcr28750 for sip-archive@odin.ietf.org; Wed, 18 Dec 2002 06:20:38 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBIBHBv28522; Wed, 18 Dec 2002 06:17:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBIBAJv28356 for ; Wed, 18 Dec 2002 06:10:19 -0500 Received: from softfront.co.jp (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA01992 for ; Wed, 18 Dec 2002 06:07:17 -0500 (EST) Received: (qmail 35077 invoked from network); 18 Dec 2002 20:10:15 +0900 Received: from mail2.softfront.co.jp (172.16.1.41) by gw-l.softfront.co.jp with SMTP; 18 Dec 2002 20:10:15 +0900 Received: from wstar by mail2.softfront.co.jp id AA01724 ; 18 Dec 2002 20:08:06 +0900 Date: Wed, 18 Dec 2002 20:10:17 +0900 From: OKUMURA Shinji Subject: Re: [Sip] Query on 'new offer' during INVITE-PRACK transaction To: ssundaragopalan@hss.hns.com, Jonathan Rosenberg Cc: sip@ietf.org Organization: SOFTFRONT In-Reply-To: <65256C92.0042D70D.00@sampark.hss.hns.com> References: <65256C92.0042D70D.00@sampark.hss.hns.com> X-Mailer: Datula version 1.50.45 for Windows Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Message-Id: <200212181108.AA01724@mail2.softfront.co.jp> Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi Srikanth, Thank you very much for your response. I have gotten the answer but I wish to understand the reason behind for adopting such regulation. For example, consider the following two transaction scenarios side by side. Caller Callee Caller Callee | | | | | | | | |(1) INVITE with offer 1 | |(1) INVITE with offer 1 | |---------------------------->| |---------------------------->| | | | | | | | | |(2) 180 INVITE with answer 1 | |(2) 180 INVITE with answer 1 | |<----------------------------| |<----------------------------| | Require: 100rel | | Require: 100rel | | | | | | | | | |(3) PRACK | |(3) PRACK | |---------------------------->| |---------------------------->| | | | | | | | | |(4) 200 PRACK | |(4) 200 PRACK | |<----------------------------| |<----------------------------| | | | | | | | | |(5) UPDATE with offer 2 | | | |<----------------------------| | | | | | | | | | | |(6) 200 UPDATE with answer 2 | | | |---------------------------->| | | | | | | | | | | |(7) 200 INVITE | |(5) 200 INVITE with offer 2 | |<----------------------------| |<----------------------------| | | | | | | | | |(8) ACK | |(6) ACK with answer 2 | |---------------------------->| |---------------------------->| | | | | Figure 1-A Figure 1-B IMHU, both of these two processes can solve the same problem whereas in the process of Figure 1-B, it looks more optimized. Then why this second process could not be accepted? What possible problem does it cause? Looking for any comment. Best regards. ssundaragopalan@hss.hns.com wrote in <65256C92.0042D70D.00@sampark.hss.hns.com> >Hi, > " If the initial offer is in an INVITE, the answer MUST be in a > reliable non-failure message from UAS back to UAC which is > correlated to that INVITE. For this specification, that is > only the final 2xx response to that INVITE. That same exact > answer MAY also be placed in any provisional responses sent > prior to the answer. * The UAC MUST treat the first session > description it receives as the answer, and MUST ignore any > session descriptions in subsequent responses to the initial > INVITE.* ", > > According to the above excerpt from RFC 3261, you cant send a >*newoffer* in 200 OK. >If an *answer* is sent in any Reliable Provisional Response,then any >session description in subsequent >responses(including 200OK for INVITE) should be ignored.So,though you send >a *newoffer*, your session >description in 200OK will be ignored. > >If at all you want to propose a *newoffer*,you should use *Update* for the same. > >regds, >srikanth sundaragopalan > >OKUMURA Shinji on 12/17/2002 05:15:00 PM >To: sip@ietf.org >cc: (bcc: Srikanth Sundaragopalan/HSSBLR) >Subject: [Sip] Query on 'new offer' during INVITE-PRACK transaction > >Hi Folks, > >I have one question concerning a new offer inclusion during a transaction of >INVITE-PRACK at stated in the following figure. > >Here my question goes, is it possible to include a new 'offer 2' within 200 >INVITE at line (5) and the corresponding 'answer 2' in ACK at line (6)? > >Thanks in advance for your kind response. > >Caller Callee > | | > | | > |(1) INVITE with offer 1 | > |---------------------------->| > | | > | | > |(2) 180 INVITE with answer 1 | > |<----------------------------| > | Require: 100rel | > | | > | | > |(3) PRACK | > |---------------------------->| > | | > | | > |(4) 200 PRACK | > |<----------------------------| > | | > | | > |(5) 200 INVITE with offer 2 | > |<----------------------------| > | | > | | > |(6) ACK with answer 3 | > |---------------------------->| > | | > | | _________________________________________________________ OKUMURA Shinji E-mail:shin@softfront.co.jp _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Wed Dec 18 07:23:30 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03515 for ; Wed, 18 Dec 2002 07:23:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBICQ1v32400 for sip-archive@odin.ietf.org; Wed, 18 Dec 2002 07:26:01 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBICM7v32187; Wed, 18 Dec 2002 07:22:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBICIJv32051 for ; Wed, 18 Dec 2002 07:18:19 -0500 Received: from fox.iptel.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03334 for ; Wed, 18 Dec 2002 07:15:17 -0500 (EST) Received: from jku07.iptel.org (dhcp219.fokus.gmd.de [195.37.78.219]) by fox.iptel.org (8.11.6/8.11.6) with ESMTP id gBICI5g25177; Wed, 18 Dec 2002 13:18:05 +0100 Message-Id: <5.2.0.9.0.20021218124417.02c6ceb8@iptel.org> X-Sender: jiri@iptel.org (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 18 Dec 2002 13:16:45 +0100 To: "Drage, Keith (Keith)" , Christer Holmberg , "Drage, Keith (Keith)" From: Jiri Kuthan Subject: RE: [Sip] Replies to ACK Cc: sip@ietf.org In-Reply-To: <475FF955A05DD411980D00508B6D5FB00439EB5C@en0033exch001u.uk .lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Just to be safe -- I'm not advocating ACK/replies, I'm trying to understand a potential gap betweeen running code I sighted, specification and its interpretations. I simply wish to know whether it is a bug or feature, which is not apparent to me from the spec. At 12:09 PM 12/18/2002, Drage, Keith (Keith) wrote: >Remember we do not tend to write standards stating what is precluded. > >There is an implicit assumption that what is not allowed is precluded. >Certainly any equipment claiming conformance to RFC 3261 should list this as an exception, like any other extensions, as it is not explicitly required by RFC 3261. What implementers of the device in question might have seen in RFC3261 is "...each transaction consists of a reuqest...and at least one response..." (Section 4) and "...ACK...considered its own transaction" (Section 17). >I would also still question the use. There seems to be little point in responding when as far as I read RFC 3261, any intermediate proxy would kill the incoming response message at the client process, and not pass it up to the transaction layer for further processing. I read the spec slightly differently. Reply matching succeeds if both branch and CSeq method matches (you would not be able to distinguish replies to CANCEL and INVITEs otherwise). If a device sends a reply to an ACK, the reply will be forwarded upstream statelessly. Besides that, such a reply does not have to visit a proxy at all, as it follows ACK path, which may be direct. -Jiri _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Wed Dec 18 08:35:08 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06143 for ; Wed, 18 Dec 2002 08:35:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBIDbe804755 for sip-archive@odin.ietf.org; Wed, 18 Dec 2002 08:37:40 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBIDXOv03893; Wed, 18 Dec 2002 08:33:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBIDTSv03579 for ; Wed, 18 Dec 2002 08:29:28 -0500 Received: from lohi.eng.song.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05477 for ; Wed, 18 Dec 2002 08:26:24 -0500 (EST) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 18OeGH-0000kn-00; Wed, 18 Dec 2002 15:29:21 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15872.30769.394777.966989@harjus.eng.song.fi> Date: Wed, 18 Dec 2002 15:29:21 +0200 To: Jiri Kuthan Cc: "Drage, Keith (Keith)" , Christer Holmberg , sip@ietf.org Subject: RE: [Sip] Replies to ACK In-Reply-To: <5.2.0.9.0.20021218124417.02c6ceb8@iptel.org> References: <475FF955A05DD411980D00508B6D5FB00439EB5C@en0033exch001u.uk .lucent.com> <5.2.0.9.0.20021218124417.02c6ceb8@iptel.org> X-Mailer: VM 7.03 under Emacs 21.2.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jiri Kuthan writes: > Just to be safe -- I'm not advocating ACK/replies, I'm trying to > understand a potential gap betweeen running code I sighted, > specification and its interpretations. I simply wish to know > whether it is a bug or feature, which is not apparent to me > from the spec. i looked every place where rfc3261 mentions ack and didn't mention anywhere if a proxy is allowed to respond to an ack it doesn't like. my interpretation of rfc3261 is that an ack to 2xx response is routed exactly like any other request, which means, for example, that if a proxy gets such an ack that contains a request uri it doesn't for some reason like, it is allowed to respond with, for example, 403 forbidden. since this clearly is unclear, i would suggest that whoever keeps an bug list on rfc3261, adds this issue there to be clarified one way or another in the next revision. -- 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 mailnull@www1.ietf.org Wed Dec 18 17:15:37 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20349 for ; Wed, 18 Dec 2002 17:15:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBIMIE202197 for sip-archive@odin.ietf.org; Wed, 18 Dec 2002 17:18:14 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBIMEWv02118; Wed, 18 Dec 2002 17:14:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBIM88v01956 for ; Wed, 18 Dec 2002 17:08:08 -0500 Received: from dyn-tx-arch-crash.dfw.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20032 for ; Wed, 18 Dec 2002 17:05:00 -0500 (EST) Received: from RjS.localdomain (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id gBIM7RI22574; Wed, 18 Dec 2002 16:07:27 -0600 Subject: RE: [Sip] Replies to ACK From: Robert Sparks To: jh@lohi.eng.song.fi Cc: Jiri Kuthan , "Drage, Keith (Keith)" , Christer Holmberg , sip@ietf.org In-Reply-To: <15872.30769.394777.966989@harjus.eng.song.fi> References: <475FF955A05DD411980D00508B6D5FB00439EB5C@en0033exch001u.uk .lucent.com> <5.2.0.9.0.20021218124417.02c6ceb8@iptel.org> <15872.30769.394777.966989@harjus.eng.song.fi> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 18 Dec 2002 16:05:29 -0600 Message-Id: <1040249134.930.143.camel@RjS.localdomain> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I've added this to the list of bugs being tracked as bug #684. It has always been the intent that no element ever generate a response to an ACK. Here is some evidence of that intent: From the first paragraph of page 124 (this alone addresses what stateful proxies are going to do with responses to ACKs): The client transaction is also responsible for receiving responses and delivering them to the TU, filtering out any response retransmissions or disallowed responses (such as a response to ACK). From page 130: Although any request MAY contain a body, a body in an ACK is special since the request cannot be rejected if the body is not understood. From page 51 o A stateless UAS MUST ignore ACK requests. There are probably more, but I think those make the point RjS On Wed, 2002-12-18 at 07:29, jh@lohi.eng.song.fi wrote: > Jiri Kuthan writes: > > > Just to be safe -- I'm not advocating ACK/replies, I'm trying to > > understand a potential gap betweeen running code I sighted, > > specification and its interpretations. I simply wish to know > > whether it is a bug or feature, which is not apparent to me > > from the spec. > > i looked every place where rfc3261 mentions ack and didn't mention > anywhere if a proxy is allowed to respond to an ack it doesn't like. my > interpretation of rfc3261 is that an ack to 2xx response is routed > exactly like any other request, which means, for example, that if a > proxy gets such an ack that contains a request uri it doesn't for some > reason like, it is allowed to respond with, for example, 403 forbidden. > > since this clearly is unclear, i would suggest that whoever keeps an bug > list on rfc3261, adds this issue there to be clarified one way or > another in the next revision. > > -- 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Thu Dec 19 03:45:52 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11822 for ; Thu, 19 Dec 2002 03:45:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBJ8mY211031 for sip-archive@odin.ietf.org; Thu, 19 Dec 2002 03:48:34 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBJ8icv10815; Thu, 19 Dec 2002 03:44:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBJ8ZQv09905 for ; Thu, 19 Dec 2002 03:35:26 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11673; Thu, 19 Dec 2002 03:32:13 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gBJ8ZEKV015652; Thu, 19 Dec 2002 09:35:14 +0100 (MET) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id Y8JAF0ZX; Thu, 19 Dec 2002 09:35:13 +0100 Received: from lmf.ericsson.se (sealwa04-199.sw.ericsson.se [130.100.249.199]) by hendrix.lmf.ericsson.se (8.12.6/8.12.6/lmf-2.1-jcs) with ESMTP id gBJ8ZAu4022410; Thu, 19 Dec 2002 10:35:11 +0200 (EET) Message-ID: <3E0184C2.91A204B9@lmf.ericsson.se> Date: Thu, 19 Dec 2002 10:35:14 +0200 X-Sybari-Trust: 8d4d44d3 1864f774 1de1e207 00000138 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip , sipping , simple@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] SIP parameters Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Folks, I have just submitted the draft below: http://standards.ericsson.net/gonzalo/papers/draft-camarillo-sip-parameter-registry-00.txt It defines a new IANA registry for SIP parameters. If you know of any RFC or Internet draft that defines header field parameters or SIP/SIPS URI parameters, please let me know. Answer directly to me, do NOT reply to all the mailing lists. The specs we have taken into account are RFC 3261, comp=sigcomp, rport, 3GPP P-headers and caller preferences... but we might have missed something. Thanks, Gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Thu Dec 19 10:18:02 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17700 for ; Thu, 19 Dec 2002 10:18:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBJFKlX32247 for sip-archive@odin.ietf.org; Thu, 19 Dec 2002 10:20:47 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBJFGmv32094; Thu, 19 Dec 2002 10:16:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBJF7xv31804 for ; Thu, 19 Dec 2002 10:07:59 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17509 for ; Thu, 19 Dec 2002 10:04:43 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.76]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gBJF7dYH020137; Thu, 19 Dec 2002 10:07:40 -0500 (EST) Message-ID: <3E01E0B9.9050806@dynamicsoft.com> Date: Thu, 19 Dec 2002 10:07:37 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sparks CC: jh@lohi.eng.song.fi, Jiri Kuthan , "Drage, Keith (Keith)" , Christer Holmberg , sip@ietf.org Subject: Re: [Sip] Replies to ACK References: <475FF955A05DD411980D00508B6D5FB00439EB5C@en0033exch001u.uk .lucent.com> <5.2.0.9.0.20021218124417.02c6ceb8@iptel.org> <15872.30769.394777.966989@harjus.eng.song.fi> <1040249134.930.143.camel@RjS.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Robert Sparks wrote: > I've added this to the list of bugs being tracked as bug #684. > > It has always been the intent that no element ever generate > a response to an ACK. Robert is absolutely correct. I believe there were explicit statements to this regard in bis revisions, but this is something that got lost. I suspect it got lost because it was always obvious in the minds of the editors and thus somehow never got stated... Jiri has claimed that they are "harmless". However, in practice, we found that they confused implementations. Indeed, according to the transaction matching rules, an ACK for non-2xx has the same branch ID as the INVITE. As such, the response to ACK also has this same branch ID. This will cause the INVITE state machine to consider that response as a response to the original INVITE (CSeq method is not needed in the matching process!). This will trigger an ACK retransmit, which triggers an ACK response, which triggers an ACK retransmit, etc. The result is a message storm. Thus, sending an ACK response is a BAD THING. Robert has already logged a bug against it. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.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 mailnull@www1.ietf.org Thu Dec 19 13:22:49 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22281 for ; Thu, 19 Dec 2002 13:22:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBJIPYn11122 for sip-archive@odin.ietf.org; Thu, 19 Dec 2002 13:25:34 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBJILov10886; Thu, 19 Dec 2002 13:21:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBJIIGv10775 for ; Thu, 19 Dec 2002 13:18:16 -0500 Received: from fmis402r.omnitel.it (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22061 for ; Thu, 19 Dec 2002 13:14:59 -0500 (EST) Received: from fmis438.omnitel.it by fmis402r.omnitel.it via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; 19 Dec 2002 18:18:00 UT Received: (private information removed) Received: (private information removed) Message-ID: <67D2057AA55D974191FEADB8BE53CE04ADA5B9@OMIMEXO08.omnitel.it> From: FERRIERI Antonio To: "'sip@ietf.org'" Subject: [Sip] INFO Contact Date: Thu, 19 Dec 2002 19:17:56 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Folks, I'm a new entry in SIP world and I've a question on Contact Header: Does a Registar bind the Request-URI, in a Register message, to the URI in Contact? So, is not a Request-URI binded to the IP address in VIA field? and If the contact Header is absent, what happens? Thanks, Antonio ================================= "STRICTLY PERSONAL AND CONFIDENTIAL This message may contain confidential and proprietary material for the sole use of the intended recipient. Any review or distribution by others is strictly prohibited. If you are not the intended recipient please contact the sender and delete all copies. The contents of this message that do not relate to the official business of our company shall be understood as neither given nor endorsed by it." ================================= _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Fri Dec 20 05:37:18 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21351 for ; Fri, 20 Dec 2002 05:37:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBKAeDX07724 for sip-archive@odin.ietf.org; Fri, 20 Dec 2002 05:40:13 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBKAabv06986; Fri, 20 Dec 2002 05:36:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBKAWcv06899 for ; Fri, 20 Dec 2002 05:32:38 -0500 Received: from fox.iptel.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21274 for ; Fri, 20 Dec 2002 05:29:12 -0500 (EST) Received: from jku07.iptel.org (dial43.cesnet.cz [195.113.150.43]) by fox.iptel.org (8.11.6/8.11.6) with ESMTP id gBKAVHg08232; Fri, 20 Dec 2002 11:31:18 +0100 Message-Id: <5.2.0.9.0.20021219163044.02b51008@iptel.org> X-Sender: jiri@iptel.org (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 20 Dec 2002 11:10:11 +0100 To: Jonathan Rosenberg , Robert Sparks From: Jiri Kuthan Subject: Re: [Sip] Replies to ACK Cc: jh@lohi.eng.song.fi, "Drage, Keith (Keith)" , Christer Holmberg , sip@ietf.org In-Reply-To: <3E01E0B9.9050806@dynamicsoft.com> References: <475FF955A05DD411980D00508B6D5FB00439EB5C@en0033exch001u.uk .lucent.com> <5.2.0.9.0.20021218124417.02c6ceb8@iptel.org> <15872.30769.394777.966989@harjus.eng.song.fi> <1040249134.930.143.camel@RjS.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , At 04:07 PM 12/19/2002, Jonathan Rosenberg wrote: >Jiri has claimed that they are "harmless". I'm not sure I ever did. Never mind. [...] >This will cause the INVITE state machine to consider that response as >a response to the original INVITE (CSeq method is not needed in the matching process!). Is that some implicit assumption too? I read the following in spec, section 17.1.3: "A response matches ... If the method parameter in the CSeq header field matches the method of the request that created the transaction." It does not mention any special case, in which method matching is not used. Which is IMHO correct. >This will trigger an ACK retransmit, which triggers an ACK response, which triggers an ACK retransmit, etc. The result is a message storm. > >Thus, sending an ACK response is a BAD THING. > >Robert has already logged a bug against it. Thanks -- I think explicitely declaring replies to ACKs as illegal would add clarity. -Jiri _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Fri Dec 20 07:17:40 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23386 for ; Fri, 20 Dec 2002 07:17:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBKCKYX12276 for sip-archive@odin.ietf.org; Fri, 20 Dec 2002 07:20:34 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBKCH1v12118; Fri, 20 Dec 2002 07:17:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBKCCDv11946 for ; Fri, 20 Dec 2002 07:12:13 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22893; Fri, 20 Dec 2002 07:08:47 -0500 (EST) Message-Id: <200212201208.HAA22893@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sip@ietf.org, sipping@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 20 Dec 2002 07:08:47 -0500 Subject: [Sip] I-D ACTION:draft-shenoy-sip-via-validation-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Session Initiation Protocol Extension for Response Integrity Check using Validation Cookie Author(s) : S. Shenoy Filename : draft-shenoy-sip-via-validation-00.txt Pages : 7 Date : 2002-12-18 This document defines an extension to the Session Initiation Protocol (SIP). This extension allows detection of stale responses and responses whose Via header (SIP [1]) have been modified. This memo suggests new processing rules at the proxy servers while forwarding requests and responses. The extension works by defining a new parameter which would be used to run an integrity check on received responses. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-shenoy-sip-via-validation-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-shenoy-sip-via-validation-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-shenoy-sip-via-validation-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-12-18131849.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-shenoy-sip-via-validation-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-shenoy-sip-via-validation-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-12-18131849.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Fri Dec 20 14:42:18 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07802 for ; Fri, 20 Dec 2002 14:42:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBKJjGq04166 for sip-archive@odin.ietf.org; Fri, 20 Dec 2002 14:45:16 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBKJfav03818; Fri, 20 Dec 2002 14:41:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBKJXQv02913 for ; Fri, 20 Dec 2002 14:33:26 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07338 for ; Fri, 20 Dec 2002 14:29:57 -0500 (EST) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id gBKJWWjW017190 for ; Fri, 20 Dec 2002 11:32:33 -0800 (PST) Received: from fluffyw2k (dhcp-128-107-141-97.cisco.com [128.107.141.97]) by mira-sjc5-9.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id FRR00358; Fri, 20 Dec 2002 11:33:24 -0800 (PST) From: "Cullen Jennings" To: Date: Fri, 20 Dec 2002 11:32:56 -0800 Message-ID: <004401c2a85e$99855700$618d6b80@amer.cisco.com> 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.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Sip] Enrollment in SIP services (and should we undeprecate basic auth) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I have been thinking about how devices can easily enroll to some sip service such as a registrar. In some cases it will be complex and require credit cards and web pages but in some cases it could be very simple. Imagine someone was offering a basic service and not directly charging for it. It would be nice if I could send it a message and it would create an account for me. It seems that a I could send a REGISTER to a registrar. If the registrar had never heard of my user name before, it could just create it as a new account. However, I would need to somehow provide it with the password I wish to use. Using basic authentication over a TLS connection to the registrar would be a nice way to do this. I'm wondering if we should undeprecate basic authentication. Is there better ways to meet this requirement? Are there other uses for basic that would support it coming back? Cullen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Fri Dec 20 15:00:17 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08629 for ; Fri, 20 Dec 2002 15:00:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBKK3Fi05079 for sip-archive@odin.ietf.org; Fri, 20 Dec 2002 15:03:15 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBKJwwv04792; Fri, 20 Dec 2002 14:58:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBKJutv04716 for ; Fri, 20 Dec 2002 14:56:55 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08206 for ; Fri, 20 Dec 2002 14:53:25 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.53]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gBKJuQYH020822; Fri, 20 Dec 2002 14:56:27 -0500 (EST) Message-ID: <3E0375E7.1080608@dynamicsoft.com> Date: Fri, 20 Dec 2002 14:56:23 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings CC: sip@ietf.org Subject: Re: [Sip] Enrollment in SIP services (and should we undeprecate basic auth) References: <004401c2a85e$99855700$618d6b80@amer.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit User provisioning (aka enrollment) is not the role of the SIP REGISTER request. It usually involves far more than just providing a username/password, and for many reasons REGISTER is a poor fit (and ultimately, was a poor choice of names because of its (ab)use for things that seemed like "registrations"). Genreally I like web-based enrollment in applications. I have been thinking about undeprecating basic, but for a totally different reason (which was suggested by Christian some time back). When you do authentication over TLS, there is no security benefits to digest as opposed to basic. However, with basic, it is easier to integrate with back-end AAA systems, because you don't need to assume that they've stored the password in the form described in rfc 2617. Of course, if the server doing the authentication is several hops beyond the one you've terminated your TLS connection to, you've got problems. The combination of sips and basic would always work, however. -Jonathan R. Cullen Jennings wrote: > I have been thinking about how devices can easily enroll to some sip > service such as a registrar. In some cases it will be complex and > require credit cards and web pages but in some cases it could be very > simple. Imagine someone was offering a basic service and not directly > charging for it. It would be nice if I could send it a message and it > would create an account for me. > > It seems that a I could send a REGISTER to a registrar. If the registrar > had never heard of my user name before, it could just create it as a new > account. However, I would need to somehow provide it with the password I > wish to use. Using basic authentication over a TLS connection to the > registrar would be a nice way to do this. > > I'm wondering if we should undeprecate basic authentication. Is there > better ways to meet this requirement? Are there other uses for basic > that would support it coming back? > > Cullen > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.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 mailnull@www1.ietf.org Fri Dec 20 15:25:09 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09120 for ; Fri, 20 Dec 2002 15:25:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBKKS8706465 for sip-archive@odin.ietf.org; Fri, 20 Dec 2002 15:28:08 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBKKOZv06359; Fri, 20 Dec 2002 15:24:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBKKLpv06309 for ; Fri, 20 Dec 2002 15:21:51 -0500 Received: from dyn-tx-arch-crash.dfw.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09039 for ; Fri, 20 Dec 2002 15:18:21 -0500 (EST) Received: from RjS.localdomain (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id gBKKLDI29446; Fri, 20 Dec 2002 14:21:13 -0600 Subject: Re: [Sip] Enrollment in SIP services (and should we undeprecate basic auth) From: Robert Sparks To: Jonathan Rosenberg Cc: Cullen Jennings , sip@ietf.org In-Reply-To: <3E0375E7.1080608@dynamicsoft.com> References: <004401c2a85e$99855700$618d6b80@amer.cisco.com> <3E0375E7.1080608@dynamicsoft.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 20 Dec 2002 14:21:11 -0600 Message-Id: <1040415671.949.161.camel@RjS.localdomain> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I see no value at all to resurrecting BASIC. If you are wanting to provide a shared secret and punt all of the security responsibilities to the transport layer, then express that secret in its native form (plaintext for a password). Anything else you do wastes cycles and encourages people to make bad assumptions about the level of protection they are getting (increasing the risk that it would get foolishly used outside the environment you intended to punt to). More inline: On Fri, 2002-12-20 at 13:56, Jonathan Rosenberg wrote: > User provisioning (aka enrollment) is not the role of the SIP REGISTER > request. It usually involves far more than just providing a > username/password, and for many reasons REGISTER is a poor fit (and > ultimately, was a poor choice of names because of its (ab)use for things > that seemed like "registrations"). Genreally I like web-based enrollment > in applications. > > I have been thinking about undeprecating basic, but for a totally > different reason (which was suggested by Christian some time back). When > you do authentication over TLS, there is no security benefits to digest > as opposed to basic. However, with basic, it is easier to integrate with > back-end AAA systems, because you don't need to assume that they've > stored the password in the form described in rfc 2617. I don't understand the last statement. A system that accepts digest credentials is not required to keep its local knowledge of the password in the hash recommended in 2617. > > Of course, if the server doing the authentication is several hops beyond > the one you've terminated your TLS connection to, you've got problems. > The combination of sips and basic would always work, however. > > -Jonathan R. > > Cullen Jennings wrote: > > I have been thinking about how devices can easily enroll to some sip > > service such as a registrar. In some cases it will be complex and > > require credit cards and web pages but in some cases it could be very > > simple. Imagine someone was offering a basic service and not directly > > charging for it. It would be nice if I could send it a message and it > > would create an account for me. > > > > It seems that a I could send a REGISTER to a registrar. If the registrar > > had never heard of my user name before, it could just create it as a new > > account. However, I would need to somehow provide it with the password I > > wish to use. Using basic authentication over a TLS connection to the > > registrar would be a nice way to do this. > > > > I'm wondering if we should undeprecate basic authentication. Is there > > better ways to meet this requirement? Are there other uses for basic > > that would support it coming back? > > > > Cullen > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP 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. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.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 mailnull@www1.ietf.org Fri Dec 20 20:47:12 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18286 for ; Fri, 20 Dec 2002 20:47:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBL1oDb24133 for sip-archive@odin.ietf.org; Fri, 20 Dec 2002 20:50:13 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBL1kSv24060; Fri, 20 Dec 2002 20:46:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBL1arv23249 for ; Fri, 20 Dec 2002 20:36:53 -0500 Received: from bdsl.greycouncil.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18086 for ; Fri, 20 Dec 2002 20:33:21 -0500 (EST) Received: from txdwillis (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.5/8.12.5) with ESMTP id gBL1aM8X006738 for ; Fri, 20 Dec 2002 19:36:22 -0600 From: "Dean Willis" To: Date: Fri, 20 Dec 2002 19:36:21 -0600 Message-ID: <001801c2a891$5da5b3a0$fe0c0c42@txdwillis> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gBL1arv23250 Subject: [Sip] Slides for IETF 55 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit We don't seem to have all of the slides that were used at IETF 55 posted at: http://www.softarmor.com/sipwg/meets/ietf55/slides/ Please check and see if yours are there, if you used any. If not, get them to me ASAP. 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 mailnull@www1.ietf.org Fri Dec 20 20:53:34 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18430 for ; Fri, 20 Dec 2002 20:53:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBL1uZL24369 for sip-archive@odin.ietf.org; Fri, 20 Dec 2002 20:56:35 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBL1r6v24249; Fri, 20 Dec 2002 20:53:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBL1auv23257 for ; Fri, 20 Dec 2002 20:36:56 -0500 Received: from bdsl.greycouncil.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18090; Fri, 20 Dec 2002 20:33:22 -0500 (EST) Received: from txdwillis (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.5/8.12.5) with ESMTP id gBL1aM8Z006738; Fri, 20 Dec 2002 19:36:23 -0600 From: "Dean Willis" To: , Date: Fri, 20 Dec 2002 19:36:21 -0600 Message-ID: <001c01c2a891$5e153e50$fe0c0c42@txdwillis> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gBL1avv23258 Subject: [Sip] Minutes, SIP Working Group, IETF 55 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Also posted at: http://www.softarmor.com/sipwg/meets/ietf55/minutes/minutes.html Edited by Dean Willis dean.willis@softarmor.com Notes recorded by Andrew Bender and Mary Barnes and Vijay Gurbani Meeting held Tuesday November 19, 1930-2200 in Atlanta, GA, USA Agenda Bash -------------- No objections raised Status and Charter, Chairs --------------------------- New co-chairs Rohan Mahy and Jon Peterson introduced. Status of work items reviewed by Rohan Mahy. 11 of 19 charter items reported complete. New RFCs issued include 3310, 3311, 3312, 3361. Identity and Privacy and AuthID Open Issues, Jon Peterson ------------------------------------------------------------ Draft-peterson-sip-identity-00 split into 2 WG documents, which were discussed seperately. Document draft-ietf-sip-authid-body-00.txt -------------------------------------------- Status: A specification of a MIME body that could be used as an authentication token. Now relies on either message/sip or message/sigfrag Discussion: There was discussion around whether Call-id should always be a must as there are scenarios (Referred-by and 3pcc) that need a flexible mechanism for correlation. There was a proposal that it should be Call-id unless you provide another mechanism for replay protection. There was discussion and agreement that it is always deterministic and clear when you don't want to include call-id. There was also discussion around the vulnerabilities of NOT sending the Contact header, with the suggestion that if the AIB is intended for use inside a Dialog, then a Contact should be a MUST. Conclusion: Jon will address this in the draft. Document draft-ietf-sip-identity-00.txt --------------------------------------- Status: Now defines status codes and practices for providing an authentication token (which might be auth-id body, or could be something else). An AuthService authenticates user agents, creates some sort of authentication token (as a MIME body), adds token to messages. Document describes 3 ways that body can be added to requests: 1) (Essentially) Redirection (push body back to UA), 2) Auth Service acts as B2BUA, and the optimal mechanism 3) Content-Indirection Discussion: Point 1: Why a header can't be used for the mime body. Given the S/MIME direction it really has to be a body. Point 2: Long term identity versus short term identity solutions (as described in the past). It was questioned as to how the multiple identities in the "short term" document would be supported. It was discussed that the support of this has to do with how the token is structured. There are 6 headers, 3 musts, 3 shoulds and optionals. It wasn't believed that it's necessary to define the Multiple identities explicitly in this draft. But, this discussion is a reasonable one to have. The concern expressed was that although there are multiple identity headers, there aren't clearly defined semantics. Proposal: Discussion of this topic should continue on the list. Point 3: Normative support for AIB. It was agreed that a normative statement is needed for interoperability. You need to define the scope if it's negotiable, etc. This gets into the downgrade attack issues, etc. There was concern that this might limit extensibility of the mechanism, however, Allison highlighted that the minimum mandatory to implement should be specified and that should not limit SIP's future. Document draft-peterson-sip-smime-aes-00.txt ------------------------------------------------- Status: Recommends changing required encryption for the SIP profile of S/MIME from 3DES to AES. Why deal with this now? Because S/MIME for SIP has yet to catch on, better to fix now. Lower footprint of AES might also help foster S/MIME adoption. Additonal advantage: Same encryption algorithm as TLS (AES). Discussion: There was a proposal to add this as a 3261 bis bug, but it was highlighted that this is of much greater scope than a typical 3261 bug. There was also a concern raised over obsoleting parts of an RFC, however, Allison highlighted that it's an accepted practice to update parts of RFCs with another RFC. It was suggested that occasionally writing a roadmap makes navigating the RFCs easier. Conclusion: Seemed to be general WG agreement for this to be a WG document. Content Indirection Open Issues, Sean Olson ---------------------------------------------- Issue: use of size parameter in content-type - this can be used instead of content length header richer negotiation of indirection per mime type security issues- sips/smime, access control, revocation / invalidation Proposal(s)- * use standard size parameter* * recommend s/mime and or tls * acl and negotiation are out of scope for this document... should be solved for sip in general * suggest wglc Discussion: why do we need size? Should it be madatory or optional? Conclusion: should make optional, as it may not always be possible to know the real size at the time of the indirection. Issue WGLC 2 weeks after changes published if there are no objections on list. RFC3261 Open Issues Jonathan Rosenberg ---------------------------------------------------------------- Group decided not to discuss at this time as the author indicated all open issues had been adeuqately discussed on-list. Caller Preferences Open Issues, Jonathan Rosenberg ------------------------------------------------------ Slides presented on open issues. Briefly reviewed Changes since last revision with the biggest change being the Require-Contact. A draft on related scenarios should be published shortly. Issue#1: Forced Parameter If a UA doesn't say anything about a parameter, it still matches a rule with that parameter. Proposal: Add a parm to Require Contact rule that explicitly says whether it MUST match. No arguments against proposal raised. Issue #2 AND within single feature tag In some cases, you want to specifiy that a UA has to support multiple values for the same feature tag. Current mechanism is to use multiple values of the Require-Contact header field Proposal: keep as is. No arguments raised against proposal. Some discussion held about differences between multiple occurences of the same value vs. multiple values. Issue #3: Weight q-values based on amount of overlap Proposal: develop q-value algorithm which weighs based on amount of overlap; can be done in RFC 2533 framework. Discussion indicated that we need to develop a metric for the amount of overlap, and that in order to prevent spiral problems where each parameter has a differnet q-value, we must compute q-values automatically based on the amount of overlap. There was also discussion on exact match as a limiting case. The argument was made that whereas RFC2533 implies that partial matching is impractical in a general case, we believe we have enough constraints to be able to solve the problem within the given scenarios. Issue #4: Merge Require, Accept Contacts Require and Accept Contact are similar Proposal: Merge back into single Accept-Contact header field and define should-match parm which if contact predicate doesn't match, causes it to drop. No arguments raised against proposal. Discussion: Similar to Issue #1. Issue #5: No one cares There has been little feedback on this draft given that it is widely referencec. Proposal: Rewrite intro to give it a bit more spark, explain better the power of the spec and that it is truly providing "one number" service. Discussion: lack of comments does not equate to lack of interest. It may be that this is just not contentious anymore. Issue #6: Priority semantics Proposal: work through use cases and express in draft. Discussion: priority semantics may be out of scope, since this is really a callee rather than caller issue. Proposed that this should handled through CPL. Issue #7: Implicit compatibility mechanism Skipped. Issue #8: Escaping Sadly, RFC 2533 syntax for feature tags uses characters not permitted in token (slash and colon). These characters are in use. Proposal: Use characters allowed in token, but not in feature tag, to represent those characters; bang gets mapped to colon, single quote gets mapped to slash. Conclusion: Although, there was lots of discussion on alternatives, none were deemed reasonable, so will go forward with proposal. Discussion: Could we have only one escaping mechanism? Point: There will be not translation that occurs. we are just renaming feature tags in the token codespace, and there is never a decode. Path Forward: Proposal: One more rev with these issues. Question: Ready for WGLC? Poll taken, general consensus recorded. Question: What about use cases? Should it find a home somewhere? There was some discussion on what to do with the use cases, with the general consensus expressed that the use cases are useful; whether they should remain in a separate doc, be put in an appendix of this doc or merged with other call flows is still undecided. Conclusion: 2 week WGLC after proposed changes. SIP Guidelines Open Issues, Rohan Mahy ------------------------------------------- Issues: Notion of CANCELs and provisional responses for non-INVITES currently conflicts with RFC 3261, that you must specify processing in new drafts. Does this causes more harm than good? Discussion: There was discussion around exactly what's currently in RFC 3261, with Rohan suggesting that there's never a good reason to receive Cancel for a non-INVITE. However, Robert S. highlighted that there is one. If a non-INVITE times out with no responses, the SRV draft is written that the endpoint fails over. Immediate provisionals are BAD for non-INVITE. Sending a provisional before a transaction times out can prevent some problems. There are really two different problems here: provisional responses, and CANCELs for non-invite messages. The discussion continued around TCP introducing additional problems and the importance of separating the 100 Trying from the discussion of provisionals. Conclusion: Robert to start list discussion on this particular topic once draft is available. SIP Session Timer -- Jonathan Rosenberg ------------------------------------------ Changes from last rev: * Rewrote overview of operation * 422 response causes you to retry with same call-ID and bumped CSEQ like 401 * Clarified that mid-dialog re-INVITE w/o session timer cancels session timer Issues: * Many complaints and limited interest * No defined requirements, not entirely clear the problem that is being solved. Proposition: only useful application is cleanup of state in proxies * Is it too complex for that usage? Proposals: * Redefine the scope * Keep the scope, but clarify the wording * Keep the scope, but pursue a completely a new design * For example, just use the dialog package! Conclusion: Concensus appears to be option 2 - keep the scope and clarify the wording. Discussion: There was some discussion around the lack of requirements, which is likely what leads to many of the problems in understanding the draft and finding issues therewith. Proposal: Draft should have a reasonable statement of requirements in the draft, including some which are not already there. Discussion of previously discussed alternatives, including the suggestion that this solution could align with RTSP and use the PING method. There was also discussion around support of this in other methods, however, it was highlighted that that introduces the need to maintain state. Question: Who would support this draft? Medium hum vote support Question: Who would support if it were enhanced (that wouldn't support otherwise)? Even smaller hum vote. Question: How many people violently object to moving this draft forward as-is? No objections. o Final Conclusion: Jonathan will clarify the current version and submit for going forward and WGLC. SIPS URIs, Jonathan Rosenberg --------------------------------- Basic problem (SIPS URI): Text is a bit confused on whether its e2e or hop-by-hop Additional problems: Mixed cases - SIPS URI in Contact 200 ok if it ws nowhere else? Solution Need to come to agreement on the high level behavior, from there the detailed behaviors will flow Discussion: There was some discussion around the requirement for using SIPS. The general problem is with the double Record Routing. It was highlighted that there needs to be one place that properly describes record routing that can be re-used by compression, SIPS and transport. It was highlighted that (for compression) the double record routing works okay because there is not currently a scenario that needs to change something in the response. Robert proposed that you can use this abstraction to highlight that the link characteristics on either side are different. And that, SIPS may introduce additional constraints. Proposal: Robert will specify this general mechanism for multiple record routing. The specific cases where the issues have been identified in RFC3261 with different characteristics should reference the general mechanism. Conclusion: Go forward with Robert's proposal and update the text in RFC3261 appropriately to make use of this mechanism. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Sun Dec 22 10:02:59 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02421 for ; Sun, 22 Dec 2002 10:02:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBMF6IX07756 for sip-archive@odin.ietf.org; Sun, 22 Dec 2002 10:06:18 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBMF2Pv07657; Sun, 22 Dec 2002 10:02:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBMEu1v07514 for ; Sun, 22 Dec 2002 09:56:01 -0500 Received: from fmis402r.omnitel.it (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA02303 for ; Sun, 22 Dec 2002 09:52:10 -0500 (EST) From: loretosa@vizzavi.it Received: from fmis439.omnitel.it by fmis402r.omnitel.it via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; 22 Dec 2002 14:55:13 UT Received: (private information removed) Received: (private information removed) Content-Class: urn:content-classes:message To: Cc: Subject: RE: [SIP] INFO Contact Date: Sun, 22 Dec 2002 15:55:08 +0100 Message-ID: <47b301c2a9ca$1f05ffd0$5cde010a@omnitel.it> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailer: Microsoft CDO for Windows 2000 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Thread-Index: AcKpyh8FVt9bTV/mTd+DoTI+u7nxbg== Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gBMEu1v07515 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Antonio, in a REGISTER message, the "To" Header Field contains the address of Record whose registration it to be created. The "Contact" Field MAY be present in REGISTER REQUEST and it may contain "zero or more values" containg address bindings. If Contact Header is absent, the only contact address for the user is the Address present in the "To" Header. What do you mean about the binding between IP address in VIA field and the Request-URI? I'm not understand the question and what do you mean. ciao Salvatore personal mail: loretosa@vizzavi.it work mail: salvatore.loreto@eri.ericsson.se loreto@coritel.it _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Mon Dec 23 07:43:40 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27180 for ; Mon, 23 Dec 2002 07:43:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBNCkxH07779 for sip-archive@odin.ietf.org; Mon, 23 Dec 2002 07:46:59 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBNCh6v07590; Mon, 23 Dec 2002 07:43:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBNCdav07456 for ; Mon, 23 Dec 2002 07:39:36 -0500 Received: from ws9.cdotb.ernet.in (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27042 for ; Mon, 23 Dec 2002 07:34:57 -0500 (EST) Received: from cdotb.ernet.in ([192.168.51.210]) by ws9.cdotb.ernet.in (8.9.3/8.9.3) with ESMTP id RAA28977; Mon, 23 Dec 2002 17:44:36 +0500 (GMT+0500) Message-ID: <3E070194.6080006@cdotb.ernet.in> Date: Mon, 23 Dec 2002 17:59:08 +0530 From: Prakash R Reply-To: rprakash@cdotb.ernet.in Organization: C-DOT (Center for Development of Telematics) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: cdotb.itg.stacks.sip To: sip-implementors@cs.columbia.edu, sip@ietf.org CC: "Pramodh.N" , Gade Ramesh Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] SIP backward compatibility issue Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit 1) Assuming we have an application built using SIP stack developed to comply with RFC 3261, does it have to interwork with RFC 2543 compliant stack? If not RFC2543, then what about the various drafts (draft 5, draft 6, ..., draft 9)? 2) I was also wondering about the theoretical possibility of backward compatibility? Any provisions in the protocol for an implementation to detect and manage this issue? 3) Is it feasible for applications to have dual SIP Stacks? (Both 2543 and 3261)? 4) Does it make sense now to still deal with 2543? Thanks in advance. Regards, -- Prakash R Senior Program Manager, Internet Telephony Group ===================================================================== C-DOT (Centre for Development of Telematics) 71/1, Sneha Complex, Miller Road, Bangalore - 560052, India email: rprakash@cdotb.ernet.in, prakash_r@hotmail.com Phone: +91-80-2263399, +91-80-2383951, Fax: +91-80-2263256 ===================================================================== _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Mon Dec 23 08:09:19 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29030 for ; Mon, 23 Dec 2002 08:09:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBNDCmg09156 for sip-archive@odin.ietf.org; Mon, 23 Dec 2002 08:12:48 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBND9Gv09020; Mon, 23 Dec 2002 08:09:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBNCxLv08067 for ; Mon, 23 Dec 2002 07:59:21 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27603; Mon, 23 Dec 2002 07:55:21 -0500 (EST) Message-Id: <200212231255.HAA27603@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 23 Dec 2002 07:55:21 -0500 Subject: [Sip] I-D ACTION:draft-camarillo-sip-parameter-registry-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The Internet Assigned Number Authority Header Field and Universal Resource Identifier Parameter Registry for the Session Initiation Protocol Author(s) : G. Camarillo Filename : draft-camarillo-sip-parameter-registry-00.txt Pages : 6 Date : 2002-12-20 This document creates an IANA registry for SIP header field, SIP URI and SIPS URI parameters. It also lists the already existing parameters to be used as initial values for that registry. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-camarillo-sip-parameter-registry-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-camarillo-sip-parameter-registry-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-camarillo-sip-parameter-registry-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-12-20130014.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-camarillo-sip-parameter-registry-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-camarillo-sip-parameter-registry-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-12-20130014.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Mon Dec 23 09:00:04 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02467 for ; Mon, 23 Dec 2002 09:00:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBNE3Zd12670 for sip-archive@odin.ietf.org; Mon, 23 Dec 2002 09:03:35 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBNDxlv12454; Mon, 23 Dec 2002 08:59:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBNDwlv12314 for ; Mon, 23 Dec 2002 08:58:47 -0500 Received: from jupiter.jmi.co.kr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA01964 for ; Mon, 23 Dec 2002 08:54:45 -0500 (EST) Received: (qmail 13871 invoked by uid 525); 23 Dec 2002 22:58:49 +0900 Received: (qmail 13805 invoked from network); 23 Dec 2002 22:58:38 +0900 Received: from unknown (HELO polo.jmi.co.kr) (211.45.79.31) by 0 with SMTP; 23 Dec 2002 22:58:38 +0900 Received: from ran.ietf.org (ran.ietf.org [132.151.6.60]) by polo.jmi.co.kr (8.9.0/8.9.0) with ESMTP id XAA29427 for ; Mon, 23 Dec 2002 23:01:47 +0900 (KST) Received: from majordomo by ran.ietf.org with local (Exim 4.10) id 18QSEg-0003kQ-00 for ietf-announce-list@ran.ietf.org; Mon, 23 Dec 2002 08:03:10 -0500 Received: from odin.ietf.org ([10.27.2.28] helo=ietf.org) by ran.ietf.org with esmtp (Exim 4.10) id 18QSBc-0003eW-00 for all-ietf@ran.ietf.org; Mon, 23 Dec 2002 08:00:00 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27603; Mon, 23 Dec 2002 07:55:21 -0500 (EST) Message-Id: <200212231255.HAA27603@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: hangsang@dreamwiz.com CC: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 23 Dec 2002 07:55:21 -0500 Precedence: bulk Subject: [Sip] I-D ACTION:draft-camarillo-sip-parameter-registry-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The Internet Assigned Number Authority Header Field and Universal Resource Identifier Parameter Registry for the Session Initiation Protocol Author(s) : G. Camarillo Filename : draft-camarillo-sip-parameter-registry-00.txt Pages : 6 Date : 2002-12-20 This document creates an IANA registry for SIP header field, SIP URI and SIPS URI parameters. It also lists the already existing parameters to be used as initial values for that registry. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-camarillo-sip-parameter-registry-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-camarillo-sip-parameter-registry-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-camarillo-sip-parameter-registry-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-12-20130014.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-camarillo-sip-parameter-registry-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-camarillo-sip-parameter-registry-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-12-20130014.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Mon Dec 23 09:53:25 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04561 for ; Mon, 23 Dec 2002 09:53:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBNEuu415824 for sip-archive@odin.ietf.org; Mon, 23 Dec 2002 09:56:56 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBNErPv15752; Mon, 23 Dec 2002 09:53:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBNEqjv15707 for ; Mon, 23 Dec 2002 09:52:45 -0500 Received: from e-eihq01.eis.ernet.in (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04478 for ; Mon, 23 Dec 2002 09:48:40 -0500 (EST) Received: from uucp-relay-delhi.ernet.in by e-eihq01.eis.ernet.in (8.10.2/1.1.2.10/13Jul01-0336PM) id gBNFQ9s0000026783; Mon, 23 Dec 2002 20:26:09 +0500 (GMT+0500) Received: by uucp-relay-delhi.ernet.in (8.9.3+Sun/SMI-4.1-MHS-7.0) id MAA09135; Mon, 23 Dec 2002 12:13:50 -0500 (GMT) >Received: from virgo.cdotd.ernet.in by cdotd.cdotd.ernet.in (SMI-8.6/SMI-SVR4) id LAA04895; Mon, 23 Dec 2002 11:59:45 -0500 Message-ID: <3E074FE4.6C05CC10@cdotd.ernet.in> Date: Mon, 23 Dec 2002 11:03:17 -0700 From: Rinchen Tundup X-Mailer: Mozilla 4.7 [en] (X11; I; HP-UX B.11.00 9000/785) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org, sip@ietf.com Received: from cdotd by vikram.eis.ernet.in; Mon, 23 Dec 2002 12:13 GMT Content-Type: multipart/alternative; boundary="------------695C5364C8528D56E7A4EC24" Subject: [Sip] Contact header for PSTN 2 IP call Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --------------695C5364C8528D56E7A4EC24 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I have a question ! What will be the contact header in the sip message when an PSTN to IP call is made via a media gateway ? Since PSTN phone is not a SIP entity and cannot have a SIP URI. Should it be sip:phone_no@media_gateway_domain.com? or something else? pls help Rinchen -- Rinchen Tundup --------------695C5364C8528D56E7A4EC24 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  
Hi,
I have a question ! What will be the contact header in the sip message
when an PSTN to IP call is made via a media gateway ? Since PSTN phone
is not a SIP entity and cannot have a SIP URI.
Should it be sip:phone_no@media_gateway_domain.com? or something else?
pls help
 

Rinchen
 
  

-- 
Rinchen Tundup      
  --------------695C5364C8528D56E7A4EC24-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Mon Dec 23 10:39:10 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07045 for ; Mon, 23 Dec 2002 10:39:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBNFgfn18732 for sip-archive@odin.ietf.org; Mon, 23 Dec 2002 10:42:41 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBNFccv18626; Mon, 23 Dec 2002 10:38:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBNFaBv17946 for ; Mon, 23 Dec 2002 10:36:11 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06847 for ; Mon, 23 Dec 2002 10:32:09 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gBNFZAAv015881; Mon, 23 Dec 2002 16:35:10 +0100 (MET) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id ZGNJCL44; Mon, 23 Dec 2002 16:35:10 +0100 Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.106.10]) by hendrix.lmf.ericsson.se (8.12.6/8.12.6/lmf-2.1-jcs) with ESMTP id gBNFZAu4011021; Mon, 23 Dec 2002 17:35:10 +0200 (EET) Message-ID: <3E072D2D.AE862F8E@lmf.ericsson.se> Date: Mon, 23 Dec 2002 17:35:09 +0200 X-Sybari-Trust: 1542e656 1864f774 cb0df5b2 00000138 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Rinchen Tundup CC: sip@ietf.org, sip@ietf.com Subject: Re: [Sip] Contact header for PSTN 2 IP call References: <3E074FE4.6C05CC10@cdotd.ernet.in> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, The PSTN phone is not a SIP entity, but the media gateway is. In a normal case I would assume the values of the userpart and host are as you describe in your example. Regards, Christer Holmberg Ericsson Finland Rinchen Tundup wrote: > > Hi, > I have a question ! What will be the contact header in the sip message > > when an PSTN to IP call is made via a media gateway ? Since PSTN phone > > is not a SIP entity and cannot have a SIP URI. > Should it be sip:phone_no@media_gateway_domain.com? or something else? > > pls help > > > Rinchen > > > > -- > Rinchen Tundup > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Mon Dec 23 10:50:05 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07343 for ; Mon, 23 Dec 2002 10:50:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBNFra519175 for sip-archive@odin.ietf.org; Mon, 23 Dec 2002 10:53:36 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBNFo7v19037; Mon, 23 Dec 2002 10:50:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBNFmfv18952 for ; Mon, 23 Dec 2002 10:48:41 -0500 Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07231 for ; Mon, 23 Dec 2002 10:44:39 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA18805; Mon, 23 Dec 2002 10:47:41 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA18802; Mon, 23 Dec 2002 10:47:41 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Mon, 23 Dec 2002 10:47:41 -0500 Message-ID: <313680C9A886D511A06000204840E1CF030B5C70@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Rinchen Tundup'" , sip@ietf.org Subject: RE: [Sip] Contact header for PSTN 2 IP call Date: Mon, 23 Dec 2002 10:47:40 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Usually it is phonenumber@gateway.com There is some work to update the "tel" URI, which would probably be used, as in tel:+17247426826@gateway.marconi.com Some gateways need to get a "port" number in there, and you occasionally see: "7247426826" although that is more often found in a From or To rather than a Contact. Brian -----Original Message----- From: Rinchen Tundup [mailto:rinchen@cdotd.ernet.in] Sent: Monday, December 23, 2002 1:03 PM To: sip@ietf.org; sip@ietf.com Subject: [Sip] Contact header for PSTN 2 IP call Hi, I have a question ! What will be the contact header in the sip message when an PSTN to IP call is made via a media gateway ? Since PSTN phone is not a SIP entity and cannot have a SIP URI. Should it be sip:phone_no@media_gateway_domain.com? or something else? pls help Rinchen -- Rinchen Tundup _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Mon Dec 23 11:28:26 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08391 for ; Mon, 23 Dec 2002 11:28:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBNGVws21032 for sip-archive@odin.ietf.org; Mon, 23 Dec 2002 11:31:58 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBNGSQv20954; Mon, 23 Dec 2002 11:28:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBNGRdv20838 for ; Mon, 23 Dec 2002 11:27:39 -0500 Received: from mailcity.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08259 for ; Mon, 23 Dec 2002 11:23:36 -0500 (EST) Received: from Unknown/Local ([?.?.?.?]) by mailcity.com; Mon, 23 Dec 2002 16:26:26 -0000 To: sip@ietf.org, sip@ietf.com, "Rinchen Tundup" Date: Mon, 23 Dec 2002 11:26:26 -0500 From: "Jitender Arora" Message-ID: Mime-Version: 1.0 X-Sent-Mail: off Reply-To: jitender_arora@lycos.com X-Mailer: MailCity Service X-Priority: 3 Subject: Re: [Sip] Contact header for PSTN 2 IP call X-Sender-Ip: 63.144.164.60 Organization: Lycos Mail (http://www.mail.lycos.com:80) Content-Type: text/plain; charset=us-ascii Content-Language: en Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi , Assume that u are using the ISUP on the PSTN side , so on recieving the IAM ,at the Media Gateway u find that this is a SIP call ( PhonetoNet call) ... U will send an invite out to the SIP Proxy ,with following content .... INVITE sip:phonenumber@host ( Host will depend on the Proxy , to which u are sending the Request and how your proxy is configured to ) From : sip:Mediagatewayname@host Similarly other headers are also required ...... The contact will be : contact:sip:Mediagatewayname@host:portnumber Regards, Jitender -- On Mon, 23 Dec 2002 11:03:17 Rinchen Tundup wrote: > >Hi, >I have a question ! What will be the contact header in the sip message >when an PSTN to IP call is made via a media gateway ? Since PSTN phone >is not a SIP entity and cannot have a SIP URI. >Should it be sip:phone_no@media_gateway_domain.com? or something else? >pls help > > >Rinchen > > > >-- >Rinchen Tundup > > > _____________________________________________________________ Get 25MB, POP3, Spam Filtering with LYCOS MAIL PLUS for $19.95/year. http://login.mail.lycos.com/brandPage.shtml?pageId=plus&ref=lmtplus _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Mon Dec 23 11:35:36 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08492 for ; Mon, 23 Dec 2002 11:35:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBNGcxt21837 for sip-archive@odin.ietf.org; Mon, 23 Dec 2002 11:38:59 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBNGZJv21161; Mon, 23 Dec 2002 11:35:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBNGXvv21102 for ; Mon, 23 Dec 2002 11:33:57 -0500 Received: from hoemail1.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08405 for ; Mon, 23 Dec 2002 11:29:54 -0500 (EST) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by hoemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id gBNGUIg26834; Mon, 23 Dec 2002 11:30:18 -0500 (EST) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id KAA08990; Mon, 23 Dec 2002 10:30:17 -0600 (CST) Message-ID: <3E0739F5.8050103@lucent.com> Date: Mon, 23 Dec 2002 10:29:41 -0600 From: "Vijay K. Gurbani" Organization: Lucent Technologies, Inc./Bell Laboratories User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: rprakash@cdotb.ernet.in CC: sip@ietf.org, "Pramodh.N" , Gade Ramesh Subject: Re: [Sip] SIP backward compatibility issue References: <3E070194.6080006@cdotb.ernet.in> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Prakash R wrote: > 1) Assuming we have an application built using SIP stack developed to > comply with RFC 3261, does it have to interwork with RFC 2543 compliant > stack? If not RFC2543, then what about the various drafts (draft 5, > draft 6, ..., draft 9)? A rfc3261 compliant SIP entity will be compliant with most of rfc2543 anyway. There are some parts of the protocol that were ambiguous to begin with in rfc2543 -- Record-Route handling to construct Route headers is a good example. As such, these were not uniformly implemented anyway. So, rfc3261 took some liberty in specifying these in a more uniform and unambiguous manner than did rfc2543. Even then, in the case of R-R, backward compatibility has not been forsaken; a rfc3261 SIP proxy, for instance, can still inter-operate with rfc2543 UAs which will not understand the loose-route extension. Another example of possible non-compatibility include security (i.e. deprecation of PGP and use of S/MIME). But again, these features were not uniformly (or widely) implemented by rfc2543 implementors anyway. Regarding compatibility with drafts, no. You do not have to be compliant with intermediate drafts -- they are good for 6 months anyway. You can, of course, index your implementation to these drafts and thus progress along the same curve as the protocol matures. Compliance only makes sense for an rfc, not an intermediate draft (see rfc2026). > 2) I was also wondering about the theoretical possibility of backward > compatibility? Any provisions in the protocol for an implementation to > detect and manage this issue? The SIP protocol number is still "SIP/2.0"; not "SIP/2.1". You could glean some information from the presence or absence of the Via magic cookie, but you should not depend on it for anything. There was a thread a while ago on why depending on the magic cookie for operations is not a good idea -- I don't have a reference to it (if someone else on the list does, feel free to post it). One of the reason you cannot depend on the magic cookie is that it only tells you something about the upstream UA and nothing about the downstream server (assuming you are a proxy). > 3) Is it feasible for applications to have dual SIP Stacks? (Both 2543 > and 3261)? Yes; although, once again, the utility of support PGP which was probably absent in most rfc2543 implementations is dubious at best. > 4) Does it make sense now to still deal with 2543? Sure. There is deployed gear that is rfc2543 compliant. 3Com's Ethernet SIP phones for example are still used in many installations (they work great) and are rfc2543 compliant only. Regards, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Mon Dec 23 12:39:13 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10224 for ; Mon, 23 Dec 2002 12:39:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBNHgkH25827 for sip-archive@odin.ietf.org; Mon, 23 Dec 2002 12:42:46 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBNHd9v25534; Mon, 23 Dec 2002 12:39:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBNHaRv24806 for ; Mon, 23 Dec 2002 12:36:27 -0500 Received: from lohi.eng.song.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09947; Mon, 23 Dec 2002 12:32:22 -0500 (EST) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 18QWU9-00074g-00; Mon, 23 Dec 2002 19:35:25 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15879.18781.814839.765981@harjus.eng.song.fi> Date: Mon, 23 Dec 2002 19:35:25 +0200 To: Internet-Drafts@ietf.org Cc: hangsang@dreamwiz.com, sip@ietf.org Subject: [Sip] I-D ACTION:draft-camarillo-sip-parameter-registry-00.txt In-Reply-To: <200212231255.HAA27603@ietf.org> References: <200212231255.HAA27603@ietf.org> X-Mailer: VM 7.03 under Emacs 21.2.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Internet-Drafts@ietf.org writes: > This document creates an IANA registry for SIP header field, SIP URI > and SIPS URI parameters. It also lists the already existing > parameters to be used as initial values for that registry. how about registering various sip header fields for radius accounting purpose? -- 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 mailnull@www1.ietf.org Mon Dec 23 15:16:28 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14362 for ; Mon, 23 Dec 2002 15:16:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBNKK2F01535 for sip-archive@odin.ietf.org; Mon, 23 Dec 2002 15:20:02 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBNKGSv01455; Mon, 23 Dec 2002 15:16:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBNKFTv01393 for ; Mon, 23 Dec 2002 15:15:29 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14230 for ; Mon, 23 Dec 2002 15:11:24 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.53]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gBNKEHYH021933; Mon, 23 Dec 2002 15:14:18 -0500 (EST) Message-ID: <3E076E97.9050606@dynamicsoft.com> Date: Mon, 23 Dec 2002 15:14:15 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephane.Coulombe@nokia.com CC: schulzrinne@cs.columbia.edu, sip@ietf.org References: <97C16120D52CD249ADE310B69842D5B9011DC8CD@daebe004.americas.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: Caller Preferences and Callee Capabilities: comments on version 7 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit My apologies to the delay in responding to this. I'm just getting back to caller prefs now. Stephane.Coulombe@nokia.com wrote: > Hi Jonathan and Henning, > > I would like to comment on the latest version of "Session Initiation > Protocol (SIP) Caller Preferences and Callee Capabilities" document. > The document significantly improved from the previous version. > However, it still has many shortcomings, which I would like to > address here. > > First, I am a bit concerned about the restricted way RFC 2533 is > used, by saying: > > "The feature predicate constructed by a UA MUST be an AND of terms. > Each term is either an OR of simple filters (called a disjunction), > or a single simple filter. In the case of an OR of simple filters, > each filter MUST indicate feature values for the same feature tag > (i.e., the disjunction represents a set of values for a particular > feature tag), and each element of the conjunction MUST be for a > different feature tag. Each filter can be an equality, the negation > of an equality, or in the case of numeric feature tags, an inequality > or range" This has been the scope of the caller preferences capabilities since the draft was first published way, way back - some FOUR years now [this is the oldest sip extension in existence]. Anyway, the reasoning here is that this specification is NOT meant as a general solution to the problem of declaring device capabilities. Its meant as a way to express capabilities to assist caller preference routing. THis introduces several important constraints. First, a proxy must perform computations on each message that gets sent, in real time. Thus, we cannot afford arbitrarily complex matching. Second, the set of things over which one might like to do preferential routing on, is much less than the general set of capabilities of a device. Honestly, I can't see anyone wanting to route a call because the screen size of the recipient is 100x200 as opposed to 200x300. This may be useful for some of the transcoding work you have been looking at, but I think that this is out of scope. > > this pretty much cuts the legs of RFC 2533. Not only it has the > restriction that it needs to be a serie of ORs inside a big AND. But > the terms in the OR need to have same feature tags. This is very > limiting especially if you want to deal with media content. A simple > example from RFC 2533: (| (& (pix-x=750) (pix-y=500) (color=15) ) (& > (dpi=300) (ua-media=stationery) (papersize=iso-A4) ) ) would not be > acceptable according to the proposed document. Correct. But why would you care to route a call based on this? > > To express caller's capabilities, "AND"ing terms is often sufficient > (but not always) but certainly not for expressing callee capabilities > which should be a big "OR" of supported features. RFC 2533 is full of > "OR" examples. E.g. (| (& (| (& (pix-x<=640) (pix-y<=480) > (color<=16777216) ) (& (pix-x<=800) (pix-y<=600) (color<=65535) ) (& > (pix-x<=1024) (pix-y<=768) (color<=256) ) ) (ua-media=screen) ) (& > (dpi=300) (ua-media=stationery) (papersize=iso-A4) ) ) > > How to interpret the following callee capabilities? Contact: > sip:1.2.3.4;type="video/H263,image/jpeg,audio/amr";video="TRUE",audio- > ="TRUE",resolution="#<200" According to the rule, (& (| > (type=video/H263) (type-image/jpeg) (type=audio/amr) (video=TRUE) > (audio=TRUE) (resolution < 200) ) This is not the way RFC 2533 would > represent a terminal supporting audio OR video (the syntax here > suggests that the received media MUST be video AND audio). Not at all. Please see section 5 which outlines the model of how rfc2533 is used. You seem to be interpreting the predicate as saying "media streams that I receive MUST have these characteristics". But that is not the meaning. The meaning is, this predicate represents the set of instantaneous operating modes I support. > Therefore, I also share the concern raised during the SIP meeting > regarding the reference to RFC 2533 but definition of a new syntax in > the document. The proposal should be better aligned with RFC 2533. What value is gained from changing syntax? > > The resolution attribute would better apply to the specific MIME type > rather than be general for all media types. E.g. | (& > (type=image/jpeg) (resolution<640)) & (type=video/h263) > (resolution<176))) See my above comment on scope. > > I am also concerned about the usage of a range in capabilities. For > instance, if the caller uses resolution="#R5..100" as in the > document. If callee capabilities are resolution="#R5..50", then I > guess that terminal is acceptable because intersection is not zero. Right. > Then, what happens to the terminal if the sender sends 100 pixel > image because system said it was okay? Well, I once again question the usage of caller prefs for this kind of operation. However, if a caller wants to route to a UA that supports resolutions 100 and higher it would ask for that, i.e., "#>=100". > Presently, the document mostly focuses on callee capabilities that > could be useful to a caller to set preferences on. Indeed callee > capabilities include: methods, events, etc. But the scope is general > and also applies to terminal characteristics which can be used in a > broader range of situations and applications (the document indeed > gives example of resolution, format types, etc.). The document says that this information can be used for other things. It does not say that caller prefs is a genreal solution to declaring client capabilities for a broad set of applications. That, I contend, is a much broader scoped problem, and one with many existing solutions. It would need a much richer set of attributes, and declarations. You probably want to make it hard state, support uploading a URL. You have different authorization issues - now you might not want everyone to see and use it, only certain applications. And so on. It may very well be that IFF we had a general UA capability declaration function, caller preferences should be based on that. But we don't. We are (still) trying to solve a smaller scoped problem at hand. At such time as we have a more general purpose mechanism, if needed, we can revisit aligning caller preferences with it. Therefore, it would > be good if these callee capabilities would not be limited to the > REGISTER method but be part of other methods such as OPTIONS (for > someone to learn about these capabilities), Actually I thought OPTIONS was covered, since the Contact in OPTIONS is similar to the Contact in 200 to INVITE, which can have caller prefs parameters. I'll mention that. > SUBSCRIBE (for presence > server to be able to create appropriate presence messages), etc. This doesn't make sense to me. > In > that manner, not only the specification can be used for message > routing based on caller preferences but also based on knowledge of > callee capabilities (either in routing stage or at the sending end). > > In summary, here are my recommendations: - > Align the syntax and > overall functionality to use full extent of RFC 2533. Disagree. See above comments on scope. > o Remove the > restriction of having a serie of "OR" in a big "AND" in syntax. Disagree. See above comments on scope. >o Fix > matching problem with ranges. It was not clear to me what the problem is. > o Fix other syntax problems outlined > above. Which? o Allow and add more detailed media capability description and > preferences (e.g. resolution can apply to specific MIME types. - I > suggest to add the descriptors used in > draft-coulombe-message-adaptation-framework-00.txt : 1. length: > maximum size of the entity specified. It could apply to the whole > message or to specific MIME types. Disagree. See above discussions on scope. > > 2. media-pix-x: horizontal resolution of visual media (e.g. image or > video). It could apply to all images or video or to specific MIME > types. I don't think this is useful given the current scope. > > 3. media-pix-y: vertical resolution of visual media (e.g. image or > video). It could apply to all images or video or to specific MIME > types. As described in the document, it should be possible to > associate "length" to the whole message or to specific MIME types. > These feature tags are quite important for mobile terminals and some > handheld devices. Note that the resolution is NOT necessarily the > display resolution, but rather what the terminal can support (usually > larger than the display resolution). For instance, I may want to > route a message containing an image to a terminal that support > high-enough resolution. As above. > > - Extend the methods where the callee capabilities are provided (not > just REGISTER but also SUBSCRIBE, OPTIONS, etc.) OPTIONS ought to be there. I see no use for SUBSCRIBE. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.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 mailnull@www1.ietf.org Mon Dec 23 17:36:38 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16811 for ; Mon, 23 Dec 2002 17:36:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBNMeEM02613 for sip-archive@odin.ietf.org; Mon, 23 Dec 2002 17:40:14 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBNMZ5J01883; Mon, 23 Dec 2002 17:35:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBNMPlJ01678 for ; Mon, 23 Dec 2002 17:25:47 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16646 for ; Mon, 23 Dec 2002 17:20:15 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.53]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gBNMNHYH022047; Mon, 23 Dec 2002 17:23:18 -0500 (EST) Message-ID: <3E078CD3.1010904@dynamicsoft.com> Date: Mon, 23 Dec 2002 17:23:15 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jh@lohi.eng.song.fi CC: hangsang@dreamwiz.com, sip@ietf.org Subject: Re: [Sip] I-D ACTION:draft-camarillo-sip-parameter-registry-00.txt References: <200212231255.HAA27603@ietf.org> <15879.18781.814839.765981@harjus.eng.song.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit This spec is meant JUST to fill in the gap of IANA registries for parameters that can be extended in SIP. RADIUS parameters are well outside of the scope here... -Jonathan R. jh@lohi.eng.song.fi wrote: > Internet-Drafts@ietf.org writes: > > > This document creates an IANA registry for SIP header field, SIP URI > > and SIPS URI parameters. It also lists the already existing > > parameters to be used as initial values for that registry. > > how about registering various sip header fields for radius accounting > purpose? > > -- 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 > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.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 mailnull@www1.ietf.org Mon Dec 23 17:46:46 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16996 for ; Mon, 23 Dec 2002 17:46:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBNMoM102817 for sip-archive@odin.ietf.org; Mon, 23 Dec 2002 17:50:22 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBNMjYJ02709; Mon, 23 Dec 2002 17:45:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBNMSFJ01748 for ; Mon, 23 Dec 2002 17:28:15 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16687 for ; Mon, 23 Dec 2002 17:24:09 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.53]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gBNMRDYH022050; Mon, 23 Dec 2002 17:27:13 -0500 (EST) Message-ID: <3E078DBE.4060602@dynamicsoft.com> Date: Mon, 23 Dec 2002 17:27:10 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Rosen, Brian" CC: "'Rinchen Tundup'" , sip@ietf.org Subject: Re: [Sip] Contact header for PSTN 2 IP call References: <313680C9A886D511A06000204840E1CF030B5C70@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit The Contact URI can be whatever you want. The only requirement is that its globally routable, and when you invoke it, it routes back to that UA instance. You need not put the phone number in there if you don't want to. The user part can be set arbitrarily at the discretion of the implementor. However: Rosen, Brian wrote: > Usually it is phonenumber@gateway.com > There is some work to update the "tel" URI, which would > probably be used, as in > tel:+17247426826@gateway.marconi.com No. First off, the tel URI has no domain part, i.e., tel:+17247426826. Anyway, you cannot use a tel URI since the Contact header MUST be a sip or sips URI. It is fine to use sip:+17247426826@gateway.marconi.com, however. > > Some gateways need to get a "port" number in there, > and you occasionally see: > "7247426826" > although that is more often found in a From or To rather > than a Contact. The meaning of To, From, Contact are well defined in the spec. To/From are logical identifiers, and shouldn't be of the form user@host where host is a specific device (the gateway, a PC, etc.), but rather, user@domain. Contact, on the other hand, needs to reference the device as I mentioned above. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.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 mailnull@www1.ietf.org Mon Dec 23 17:55:08 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17107 for ; Mon, 23 Dec 2002 17:55:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBNMwje02939 for sip-archive@odin.ietf.org; Mon, 23 Dec 2002 17:58:45 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBNMrvJ02866; Mon, 23 Dec 2002 17:53:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBNMohJ02830 for ; Mon, 23 Dec 2002 17:50:43 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16991 for ; Mon, 23 Dec 2002 17:46:36 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.53]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gBNMnaYH022055; Mon, 23 Dec 2002 17:49:36 -0500 (EST) Message-ID: <3E0792FD.1040701@dynamicsoft.com> Date: Mon, 23 Dec 2002 17:49:33 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Vijay K. Gurbani" CC: rprakash@cdotb.ernet.in, sip@ietf.org, "Pramodh.N" , Gade Ramesh Subject: Re: [Sip] SIP backward compatibility issue References: <3E070194.6080006@cdotb.ernet.in> <3E0739F5.8050103@lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Vijay K. Gurbani wrote: >> 2) I was also wondering about the theoretical possibility of backward >> compatibility? Any provisions in the protocol for an implementation to >> detect and manage this issue? > > > The SIP protocol number is still "SIP/2.0"; not "SIP/2.1". You could > glean some information from the presence or absence of the Via magic > cookie, but you should not depend on it for anything. There is absolutely no need. rfc3261 is sufficiently backwards compatible with rfc2543. There is no need to detect versions or anything. Any backwards compatibility functions are built into specific features of rfc3261 that needed to support backwards compatibility. If you just implement rfc3261 you will be backwards compatible. There is no versioning of the protocol. Things like the via cookie are meant to deal with backwards compatibility for THAT SPECIFIC FEATURE. It is possible to encounter an implementation that supports the contact cookie, but is still a strict router. Using the contact cookie to imply support for all of 3261 is a mistake. The lr parameter deals with the record-routing changes, and the contact cookie, with the via header changes. There was a > thread a while ago on why depending on the magic cookie for operations > is not a good idea -- I don't have a reference to it (if someone else > on the list does, feel free to post it). One of the reason you cannot > depend on the magic cookie is that it only tells you something about > the upstream UA and nothing about the downstream server (assuming you > are a proxy). The problem, as I outline above, is we are not trying to strictly version the protocol, but provide interoperability and backwards compatibility on a feature-by-feature basis. So, via cookie tells you nothing except that the via branch ID is sufficiently unique to be used as a transaction ID. > >> 3) Is it feasible for applications to have dual SIP Stacks? (Both 2543 >> and 3261)? > > > Yes; although, once again, the utility of support PGP which was probably > absent in most rfc2543 implementations is dubious at best. There were none that anyone mentioned. To me, "dual-stack" is non-sensical. rfc3261 provides backwards compatibility where needed. > >> 4) Does it make sense now to still deal with 2543? > > > Sure. There is deployed gear that is rfc2543 compliant. 3Com's > Ethernet SIP phones for example are still used in many installations > (they work great) and are rfc2543 compliant only. As above, it is my opinion that rfc3261 sufficiently deals with rfc2543 for any feature you are going to find in use from rfc2543. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.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 mailnull@www1.ietf.org Tue Dec 24 02:38:21 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03363 for ; Tue, 24 Dec 2002 02:38:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBO7g5k03613 for sip-archive@odin.ietf.org; Tue, 24 Dec 2002 02:42:05 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBO7XMJ02646; Tue, 24 Dec 2002 02:33:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBO7V3J02594 for ; Tue, 24 Dec 2002 02:31:03 -0500 Received: from lohi.eng.song.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03220 for ; Tue, 24 Dec 2002 02:26:46 -0500 (EST) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 18QjVb-0007kb-00; Tue, 24 Dec 2002 09:29:47 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15880.3307.353815.869319@harjus.eng.song.fi> Date: Tue, 24 Dec 2002 09:29:47 +0200 To: Jonathan Rosenberg Cc: hangsang@dreamwiz.com, sip@ietf.org Subject: Re: [Sip] I-D ACTION:draft-camarillo-sip-parameter-registry-00.txt In-Reply-To: <3E078CD3.1010904@dynamicsoft.com> References: <200212231255.HAA27603@ietf.org> <15879.18781.814839.765981@harjus.eng.song.fi> <3E078CD3.1010904@dynamicsoft.com> X-Mailer: VM 7.03 under Emacs 21.2.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jonathan Rosenberg writes: > This spec is meant JUST to fill in the gap of IANA registries for > parameters that can be extended in SIP. RADIUS parameters are well > outside of the scope here... i didn't mean that they should be included in this spec, but that they are iana numbers that would be very useful to exist. now everyone invents their own radius attribute values. -- 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 mailnull@www1.ietf.org Tue Dec 24 11:09:48 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09106 for ; Tue, 24 Dec 2002 11:09:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBOGDjG25352 for sip-archive@odin.ietf.org; Tue, 24 Dec 2002 11:13:45 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBOG8IJ25237; Tue, 24 Dec 2002 11:08:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBJIIXv10784 for ; Thu, 19 Dec 2002 13:18:33 -0500 Received: from chuckie.dgms.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22067 for ; Thu, 19 Dec 2002 13:15:17 -0500 (EST) Received: from ulticom.com (localhost [127.0.0.1]) by chuckie.dgms.com (8.9.3/8.9.3) with ESMTP id NAA14927 for ; Thu, 19 Dec 2002 13:18:16 -0500 (EST) Message-ID: <3E020D94.59905CB2@ulticom.com> Date: Thu, 19 Dec 2002 13:19:00 -0500 From: Vijaya Venkatachalam Organization: Ulticom, Inc. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id gBJIIXv10785 Subject: [Sip] INVITE transaction Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi, I have a question regarding the INVITE transaction state machine. It seems that in RFC 3261 - transaction state machine for INVITE transactions, there is a potential for the client side transaction to indefinitely be in the "Proceeding" state since all timers are cancelled on the reception of a 1xx response. Can somebody tell me how the client side transaction can come out of this state, if the server transaction on the remote end dies? Is it that the timer B is not cancelled and that only timer A is cancelled when the 1xx is received or is there some other means. Appreciate a quick response. Thanks, Vijaya _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Tue Dec 24 11:11:33 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09137 for ; Tue, 24 Dec 2002 11:11:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBOGFUt25386 for sip-archive@odin.ietf.org; Tue, 24 Dec 2002 11:15:30 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBOGAGJ25284; Tue, 24 Dec 2002 11:10:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBK5kNv15112 for ; Fri, 20 Dec 2002 00:46:23 -0500 Received: from e-eihq01.eis.ernet.in (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07581 for ; Fri, 20 Dec 2002 00:42:58 -0500 (EST) Received: from uucp-relay-delhi.ernet.in by e-eihq01.eis.ernet.in (8.10.2/1.1.2.10/13Jul01-0336PM) id gBK6KWe0000017571; Fri, 20 Dec 2002 11:20:32 +0500 (GMT+0500) Received: by uucp-relay-delhi.ernet.in (8.9.3+Sun/SMI-4.1-MHS-7.0) id LAA29261; Fri, 20 Dec 2002 11:11:50 -0500 (GMT) >Received: from virgo.cdotd.ernet.in by cdotd.cdotd.ernet.in (SMI-8.6/SMI-SVR4) id LAA25879; Fri, 20 Dec 2002 11:06:55 -0500 Message-ID: <3E034EFC.94AA5C51@cdotd.ernet.in> Date: Fri, 20 Dec 2002 10:10:21 -0700 From: Rinchen Tundup X-Mailer: Mozilla 4.7 [en] (X11; I; HP-UX B.11.00 9000/785) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org, sip@ietf.com Content-Transfer-Encoding: 7bit Received: from cdotd by vikram.eis.ernet.in; Fri, 20 Dec 2002 11:11 GMT Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [Sip] Contact header for an PSTN to IP call Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, I have a question ! What will be the contact header in the sip message when an PSTN to IP call is made via a media gateway ? Since PSTN phone is not a SIP entity and cannot have a SIP URI. Should it be sip:phone_no@media_gateway_domain.com? or something else? pls help Rinchen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Tue Dec 24 11:13:21 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09169 for ; Tue, 24 Dec 2002 11:13:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBOGHIj25409 for sip-archive@odin.ietf.org; Tue, 24 Dec 2002 11:17:18 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBOGC7J25331; Tue, 24 Dec 2002 11:12:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBNLn8v05583 for ; Mon, 23 Dec 2002 16:49:08 -0500 Received: from kevlar.softarmor.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16050 for ; Mon, 23 Dec 2002 16:45:02 -0500 (EST) Received: from kevlar.softarmor.com (kevlar.softarmor.com [127.0.0.1]) by kevlar.softarmor.com (8.12.5/8.12.5) with ESMTP id gBNMBY51007480; Mon, 23 Dec 2002 16:11:34 -0600 Received: from localhost (localhost [[UNIX: localhost]]) by kevlar.softarmor.com (8.12.5/8.12.5/Submit) id gBNMBSko007478; Mon, 23 Dec 2002 16:11:28 -0600 Content-Type: text/plain; charset="iso-8859-1" From: Dean Willis To: Rinchen Tundup , sip@ietf.org, sip@ietf.com Subject: Re: [Sip] Contact header for PSTN 2 IP call Date: Mon, 23 Dec 2002 16:11:27 -0600 User-Agent: KMail/1.4.3 References: <3E074FE4.6C05CC10@cdotd.ernet.in> In-Reply-To: <3E074FE4.6C05CC10@cdotd.ernet.in> MIME-Version: 1.0 Message-Id: <200212231611.27933.dwillis@greycouncil.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gBNLn9v05584 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit On Monday 23 December 2002 12:03 pm, Rinchen Tundup wrote: > Hi, > I have a question ! What will be the contact header in the sip > message when an PSTN to IP call is made via a media gateway ? Since > PSTN phone is not a SIP entity and cannot have a SIP URI. > Should it be sip:phone_no@media_gateway_domain.com? or something > else? pls help Well, it generally is "whatever the media gateway wants it to be". I suspect it must satisfy two requirements -- it points at the gateway, and can be used by the gateway to identify the correct association. The gateways I use at the office use sip:phone_no@hostname-o-fgateway or sip:phone_no@ip-address-of-gateway depending on which gateway and how it is configured. -- 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 mailnull@www1.ietf.org Tue Dec 24 11:27:35 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09383 for ; Tue, 24 Dec 2002 11:27:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBOGVWG25767 for sip-archive@odin.ietf.org; Tue, 24 Dec 2002 11:31:32 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBOGQFJ25639; Tue, 24 Dec 2002 11:26:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBOGPVJ25601 for ; Tue, 24 Dec 2002 11:25:31 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09305 for ; Tue, 24 Dec 2002 11:21:03 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.53]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gBOGNvYH022223; Tue, 24 Dec 2002 11:23:58 -0500 (EST) Message-ID: <3E088A1A.4050307@dynamicsoft.com> Date: Tue, 24 Dec 2002 11:23:54 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jiri Kuthan CC: Robert Sparks , jh@lohi.eng.song.fi, "Drage, Keith (Keith)" , Christer Holmberg , sip@ietf.org Subject: Re: [Sip] Replies to ACK References: <475FF955A05DD411980D00508B6D5FB00439EB5C@en0033exch001u.uk .lucent.com> <5.2.0.9.0.20021218124417.02c6ceb8@iptel.org> <15872.30769.394777.966989@harjus.eng.song.fi> <1040249134.930.143.camel@RjS.localdomain> <5.2.0.9.0.20021219163044.02b51008@iptel.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit inline. Jiri Kuthan wrote: > >> This will cause the INVITE state machine to consider that response >> as a response to the original INVITE (CSeq method is not needed in >> the matching process!). > > > Is that some implicit assumption too? I read the following in spec, > section 17.1.3: "A response matches ... If the method parameter in > the CSeq header field matches the method of the request that created > the transaction." It does not mention any special case, in which > method matching is not used. Which is IMHO correct. Not an implicit assumption, just me forgetting that the method check was there too. So, I guess there would not be any confusion in the client state machine. But, there are enough other potential problems that I still think its not a good idea. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.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 mailnull@www1.ietf.org Tue Dec 24 11:30:29 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09415 for ; Tue, 24 Dec 2002 11:30:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBOGYQg25809 for sip-archive@odin.ietf.org; Tue, 24 Dec 2002 11:34:26 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBOGT7J25695; Tue, 24 Dec 2002 11:29:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBOGQuJ25643 for ; Tue, 24 Dec 2002 11:26:56 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09334 for ; Tue, 24 Dec 2002 11:22:27 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.53]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gBOGPYYH022226; Tue, 24 Dec 2002 11:25:34 -0500 (EST) Message-ID: <3E088A7B.9030206@dynamicsoft.com> Date: Tue, 24 Dec 2002 11:25:31 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijaya Venkatachalam CC: sip@ietf.org Subject: Re: [Sip] INVITE transaction References: <3E020D94.59905CB2@ulticom.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit This is an application issue. It can decide to give up at any time and send CANCEL. We don't want to specify the maximum time a user will let the phone ring. -Jonathan R. Vijaya Venkatachalam wrote: > Hi, > > I have a question regarding the INVITE transaction > state machine. > > It seems that in RFC 3261 - transaction state machine for > INVITE transactions, there is a potential for > the client side transaction to indefinitely be > in the "Proceeding" state since all timers > are cancelled on the reception of a 1xx response. > > Can somebody tell me how the client side transaction > can come out of this state, if the server transaction on > the remote end dies? > > Is it that the timer B is not cancelled and that only > timer A is cancelled when the 1xx is received or is > there some other means. > > Appreciate a quick response. > > Thanks, > Vijaya > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.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 mailnull@www1.ietf.org Tue Dec 24 11:45:00 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09686 for ; Tue, 24 Dec 2002 11:44:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBOGmlg26790 for sip-archive@odin.ietf.org; Tue, 24 Dec 2002 11:48:47 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBOGhHJ26644; Tue, 24 Dec 2002 11:43:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBOGgRJ26621 for ; Tue, 24 Dec 2002 11:42:27 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09616 for ; Tue, 24 Dec 2002 11:37:59 -0500 (EST) Received: from dingdong.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBOGXRBo008484; Tue, 24 Dec 2002 11:33:28 -0500 (EST) Received: from STLEVY-W2K.cisco.com (dhcp-64-102-97-128.cisco.com [64.102.97.128]) by dingdong.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABA14963; Tue, 24 Dec 2002 11:32:51 -0500 (EST) Message-Id: <4.3.2.7.2.20021224112121.0207a0a0@dingdong.cisco.com> X-Sender: stlevy@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 24 Dec 2002 11:32:49 -0500 To: Jonathan Rosenberg From: Steve Levy Subject: Re: [Sip] SIP backward compatibility issue Cc: "Vijay K. Gurbani" , rprakash@cdotb.ernet.in, sip@ietf.org, "Pramodh.N" , Gade Ramesh In-Reply-To: <3E0792FD.1040701@dynamicsoft.com> References: <3E070194.6080006@cdotb.ernet.in> <3E0739F5.8050103@lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , > >rfc3261 is sufficiently backwards compatible with rfc2543. There is no >need to detect versions or anything. Any backwards compatibility functions >are built into specific features of rfc3261 that needed to support >backwards compatibility. If you just implement rfc3261 you will be >backwards compatible. broadening the discussion to rfc 3264 (offer/answer), isn't there a potential for backward compatibility issues with rfc 2543 implementations wrt early media ? thx, steve _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Tue Dec 24 11:50:39 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09802 for ; Tue, 24 Dec 2002 11:50:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBOGsRc26960 for sip-archive@odin.ietf.org; Tue, 24 Dec 2002 11:54:27 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBOGn6J26837; Tue, 24 Dec 2002 11:49:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBOGmMJ26775 for ; Tue, 24 Dec 2002 11:48:22 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09682 for ; Tue, 24 Dec 2002 11:43:53 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.53]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gBOGkuYH022233; Tue, 24 Dec 2002 11:46:57 -0500 (EST) Message-ID: <3E088F7E.4060701@dynamicsoft.com> Date: Tue, 24 Dec 2002 11:46:54 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Steve Levy CC: "Vijay K. Gurbani" , rprakash@cdotb.ernet.in, sip@ietf.org, "Pramodh.N" , Gade Ramesh Subject: Re: [Sip] SIP backward compatibility issue References: <3E070194.6080006@cdotb.ernet.in> <3E0739F5.8050103@lucent.com> <4.3.2.7.2.20021224112121.0207a0a0@dingdong.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Early media was not specified in rfc2543. It did say that you should be prepared to receive media before receiving the answer, which is still the case for 3264. Another issue was that people used to put SDP in non-reliable 1xx responses, and then put the same thing in 2xx. That case is explicitly allowed for in 3261, so it should interoperate as well. Perhaps you could identify the specific problem you are concerned about? -Jonathan R. Steve Levy wrote: > >> >> rfc3261 is sufficiently backwards compatible with rfc2543. There is no >> need to detect versions or anything. Any backwards compatibility >> functions are built into specific features of rfc3261 that needed to >> support backwards compatibility. If you just implement rfc3261 you >> will be backwards compatible. > > > > broadening the discussion to rfc 3264 (offer/answer), isn't there a > potential for backward compatibility issues with rfc 2543 > implementations wrt early media ? > > thx, > steve > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.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 mailnull@www1.ietf.org Tue Dec 24 13:03:45 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10832 for ; Tue, 24 Dec 2002 13:03:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBOI7Zk31089 for sip-archive@odin.ietf.org; Tue, 24 Dec 2002 13:07:35 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBOHubJ30285; Tue, 24 Dec 2002 12:56:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBOHtSJ30247 for ; Tue, 24 Dec 2002 12:55:28 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10705 for ; Tue, 24 Dec 2002 12:50:57 -0500 (EST) Received: from dingdong.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBOHkRwL015407; Tue, 24 Dec 2002 12:46:27 -0500 (EST) Received: from STLEVY-W2K.cisco.com (dhcp-64-102-97-128.cisco.com [64.102.97.128]) by dingdong.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABA16128; Tue, 24 Dec 2002 12:45:50 -0500 (EST) Message-Id: <4.3.2.7.2.20021224123942.0208c448@dingdong.cisco.com> X-Sender: stlevy@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 24 Dec 2002 12:45:49 -0500 To: Jonathan Rosenberg From: Steve Levy Subject: Re: [Sip] SIP backward compatibility issue Cc: "Vijay K. Gurbani" , rprakash@cdotb.ernet.in, sip@ietf.org, "Pramodh.N" , Gade Ramesh In-Reply-To: <3E088F7E.4060701@dynamicsoft.com> References: <3E070194.6080006@cdotb.ernet.in> <3E0739F5.8050103@lucent.com> <4.3.2.7.2.20021224112121.0207a0a0@dingdong.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , At 11:46 AM 12/24/2002 -0500, Jonathan Rosenberg wrote: >Early media was not specified in rfc2543. It did say that you should be >prepared to receive media before receiving the answer, which is still the >case for 3264. Another issue was that people used to put SDP in >non-reliable 1xx responses, and then put the same thing in 2xx. That case >is explicitly allowed for in 3261, so it should interoperate as well. > >Perhaps you could identify the specific problem you are concerned about? my concern was SDP in a 18x followed by another 18x/2xx with different SDP. Wouldnt the SDP in the subsequent 18x/2xx be treated differently by 3264 compliant UAs as opposed to earlier 2543 compliant UAs ? thx, steve >-Jonathan R. > >Steve Levy wrote: >> >>> >>>rfc3261 is sufficiently backwards compatible with rfc2543. There is no >>>need to detect versions or anything. Any backwards compatibility >>>functions are built into specific features of rfc3261 that needed to >>>support backwards compatibility. If you just implement rfc3261 you will >>>be backwards compatible. >> >>broadening the discussion to rfc 3264 (offer/answer), isn't there a >>potential for backward compatibility issues with rfc 2543 implementations >>wrt early media ? >>thx, >>steve > >-- >Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. >Chief Scientist First Floor >dynamicsoft East Hanover, NJ 07936 >jdrosen@dynamicsoft.com FAX: (973) 952-5050 >http://www.jdrosen.net PHONE: (973) 952-5000 >http://www.dynamicsoft.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 mailnull@www1.ietf.org Thu Dec 26 15:20:48 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15216 for ; Thu, 26 Dec 2002 15:20:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBQKPnb11626 for sip-archive@odin.ietf.org; Thu, 26 Dec 2002 15:25:49 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBQKLXJ11483; Thu, 26 Dec 2002 15:21:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBQKEUJ11276 for ; Thu, 26 Dec 2002 15:14:30 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15007 for ; Thu, 26 Dec 2002 15:08:58 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.53]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gBQKC7YH022685 for ; Thu, 26 Dec 2002 15:12:07 -0500 (EST) Message-ID: <3E0B6293.4030600@dynamicsoft.com> Date: Thu, 26 Dec 2002 15:12:03 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] INFO considered harmful Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Folks, For some time, I've been complaining about the continued abuse of the INFO method for things that should be done other ways (frequently, not using sip at all). I've written up a summary of the problems and a proposed path forward. Specifically, I'd like to obsolete INFO and replace it with a spec that is approved ONLY for SIP-T. Until the I-D appears, you can pick up a version at: http://www.jdrosen.net/papers/draft-rosenberg-sip-info-harmful-00.txt http://www.jdrosen.net/papers/draft-rosenberg-sip-info-harmful-00.html Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.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 mailnull@www1.ietf.org Thu Dec 26 17:20:21 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16509 for ; Thu, 26 Dec 2002 17:20:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBQMPOp17244 for sip-archive@odin.ietf.org; Thu, 26 Dec 2002 17:25:24 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBQMKIJ17126; Thu, 26 Dec 2002 17:20:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBQMIWJ17058 for ; Thu, 26 Dec 2002 17:18:32 -0500 Received: from hclnpd.hclt.co.in (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16377 for ; Thu, 26 Dec 2002 17:12:57 -0500 (EST) Received: from blaze.hcltech.com (blaze.hclt-ntl.co.in [192.168.19.30]) by hclnpd.hclt.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Y1WD1SX4; Fri, 27 Dec 2002 03:46:45 +0530 Received: from sachin-pc.netlab.hcltech.com ([192.168.201.60]) by blaze.hcltech.com (8.9.3/8.9.3) with ESMTP id EAA25881 for ; Fri, 27 Dec 2002 04:13:47 +0530 Message-Id: <4.3.2.7.0.20021227031600.0321d950@blaze> X-Sender: sachins@blaze X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 27 Dec 2002 03:37:15 +0530 To: sip@ietf.org From: Sachin Shenoy Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_-1610655670==_.ALT" Subject: [Sip] Fwd: Re: [Sip-implementors] Response retransmission Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --=====================_-1610655670==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi, Following an earlier thread from sip-implementors here is another scenario that leads to similar problem. Suppose UAC sends an INVITE out and receives 2 provisional response with different to-tags. These 2 provisional response would be handled by the same client transaction as both of the would have the same top-most branch-id (even though they have different to-tags) They will create 2 early dialogs. Now suppose, one of the early dialog matures with a 2xx response. This would immediately delete the client transaction. Now, let the other dialog be terminated with a 4xx. 1. Should we send ACK for this 4xx? 2. If yes, Who should send the ACK for this 4xx. TU? or TL? 3. Also, how should it be sent. Should we create a new client transaction for this purpose? RFC 3261 Section 17.1.1.2 Formal Description, says, "The client transaction MUST pass the received response up to the TU, and the client transaction MUST generate an ACK request, even if the transport is reliable (guidelines for constructing the ACK from the response are given in Section 17.1.1.3) and then pass the ACK to the transport layer for transmission. The ACK MUST be sent to the same address, port, and transport to which the original request was sent." Now, in our case as we don't have client transaction we have lost all the context regarding the original transaction. Should we create a new client transaction and send the ACK using it. If this is done, then we would have another problem. Re transmissions of the 2xx for the matured dialog would hit on this client transaction (since they would have the same branch-id's). Due to this the 2xx won't be indicated to the TU at all. As I said earlier (see below mail) I still think that this should be explicitly stated in the RFC. Making this explicit would ensure that implementors don't accidentally over look this point. Thanks Sachin >Sorry, I think correction might be required not in Response matching but in >FSM Figure 5: INVITE client transaction. > >We need to add one more event in "Completed" state, event 2xx. >In "Completed" state if we recieve a 2xx we would indicate it to TU. > >Hope I got it right. > >Thanks >Sachin > > >At 07:24 PM 7/24/02 +0530, you wrote: >>Hi Bob, >> >>According to RFC 3261 17.1.3 "Matching Responses to Client Transactions", >>It is said that client transaction for response is matched using >>topmost via-branch & Cseq method. >> >>I guess this will have to be changed if we have to forward the 2xx also. >> >>Since the response context for 4xx would be still active, when a >>2xx comes, according to RFC, we will match it with the 4xx's response >>context. We will end up retransmitting ACK (not knowing that it is 2xx >>but thinking that it is a 4xx). >> >>Hope I didn't miss anything over here. >> >>Thanks >>Sachin >> >> >>At 09:40 AM 7/24/02 -0400, you wrote: >> >>>----- Original Message ----- >>>From: "Sachin Shenoy" >>> >>> > Hi, >>> > >>> > If a proxy sends out an INVITE statefully, and gets a non-2xx response >>>(say >>> > 4xx), >>> > it will send out an ACK locally. Now if it gets 2xx on the same branch, >>> > it would consider this 2xx as retransmission of 4xx and retransmit ACK. >>> > (Since 4xx & 2xx would have the same top-most via branch) >>> > >>> > (It may end up getting 2xx after forwarding 4xx due to a mis-behaving >>>proxy >>> > down the line, which forked the INVITE?). >>> > >>> > Is this behaviour Ok? >>> > >>> >>>No. >>> >>>If this proxy did receive a 2xx after receiving a 4xx, it would mean a >>>downstream (not necessarily mis-behaving) proxy had given up on waiting for >>>a response on a given branch. The 2xx and 4xx would not have come from the >>>same UAS. >>> >>>The proxy should not send an ACK for the 2xx, but should forward the >>>response back toward the UAC. ACK for non-2xx is hop-by-hop, but ACK for 2xx >>>is end-to-end and it is a request within the dialog established/identified >>>by the 2xx. >>> >>>If the UAC had already given up on the call, it would send a BYE after >>>sending the ACK. --=====================_-1610655670==_.ALT Content-Type: text/html; charset="us-ascii" Hi,
Following an earlier thread from sip-implementors here is another
scenario that leads to similar problem.

Suppose UAC sends an INVITE out and receives 2 provisional
response with different to-tags. These 2 provisional response would
be handled by the same client transaction as both of the would have
the same top-most branch-id (even though they have different to-tags)
They will create 2 early dialogs. Now suppose, one of the early dialog
matures with a 2xx response. This would immediately delete the client
transaction. Now, let the other dialog be terminated with a 4xx.

1. Should we send ACK for this 4xx?
2. If yes, Who  should send the ACK for this 4xx. TU? or TL?
3. Also, how should it be sent. Should we create a new client transaction
    for this purpose?

RFC 3261 Section 17.1.1.2 Formal Description, says,

"The client transaction
   MUST pass the received response up to the TU, and the client
   transaction MUST generate an ACK request, even if the transport is
   reliable (guidelines for constructing the ACK from the response are
   given in Section 17.1.1.3) and then pass the ACK to the transport
   layer for transmission.  The ACK MUST be sent to the same address,
   port, and transport to which the original request was sent."

Now, in our case as we don't have client transaction we have lost
all the context regarding the original transaction. Should we create
a new client transaction and send the ACK using it. If this is done,
then we would have another problem. Re transmissions of the 2xx
for the matured dialog would hit on this client transaction (since
they would have the same branch-id's). Due to this the 2xx won't
be indicated to the TU at all. As I said earlier (see below mail) I still
think that this should be explicitly stated in the RFC. Making this
explicit would ensure that implementors don't accidentally over look
this point.

Thanks
Sachin



Sorry, I think correction might be required not in Response matching but in
FSM Figure 5: INVITE client transaction.

We need to add one more event in "Completed" state,  event 2xx.
In "Completed" state if we recieve a 2xx we would indicate it to TU.

Hope I got it right.

Thanks
Sachin


At 07:24 PM 7/24/02 +0530, you wrote:
Hi Bob,

According to RFC 3261 17.1.3 "Matching Responses to Client Transactions",
It is said that client transaction for response is matched using
topmost via-branch & Cseq method.

I guess this will have to be changed if we have to forward the 2xx also.

Since the response context for 4xx would be still active, when a
2xx comes, according to RFC, we will match it with the 4xx's response
context. We will end up retransmitting ACK (not knowing that it is 2xx
but thinking that it is a 4xx).

Hope I didn't miss anything over here.

Thanks
Sachin


At 09:40 AM 7/24/02 -0400, you wrote:

----- Original Message -----
From: "Sachin Shenoy" <sachins@netlab.hcltech.com>

> Hi,
>
> If a proxy sends out an INVITE statefully, and gets a non-2xx response
(say
> 4xx),
> it will send out an ACK locally. Now if it gets 2xx on the same branch,
> it would consider this 2xx as retransmission of 4xx and retransmit ACK.
> (Since 4xx & 2xx would have the same top-most via branch)
>
> (It may end up getting 2xx after forwarding 4xx due to a mis-behaving
proxy
> down the line, which forked the INVITE?).
>
> Is this behaviour Ok?
>

No.

If this proxy did receive a 2xx after receiving a 4xx, it would mean a
downstream (not necessarily mis-behaving) proxy had given up on waiting for
a response on a given branch. The 2xx and 4xx would not have come from the
same UAS.

The proxy should not send an ACK for the 2xx, but should forward the
response back toward the UAC. ACK for non-2xx is hop-by-hop, but ACK for 2xx
is end-to-end and it is a request within the dialog established/identified
by the 2xx.

If the UAC had already given up on the call, it would send a BYE after
sending the ACK.
--=====================_-1610655670==_.ALT-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Fri Dec 27 06:25:51 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05889 for ; Fri, 27 Dec 2002 06:25:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBRBV9n31079 for sip-archive@odin.ietf.org; Fri, 27 Dec 2002 06:31:09 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBRBQUJ30942; Fri, 27 Dec 2002 06:26:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBRBO6J30886 for ; Fri, 27 Dec 2002 06:24:06 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05793 for ; Fri, 27 Dec 2002 06:18:17 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gBRBLIKV018358; Fri, 27 Dec 2002 12:21:18 +0100 (MET) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id ZGNJ35GD; Fri, 27 Dec 2002 12:21:18 +0100 Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.106.10]) by hendrix.lmf.ericsson.se (8.12.6/8.12.6/lmf-2.1-jcs) with ESMTP id gBRBLHu4001777; Fri, 27 Dec 2002 13:21:18 +0200 (EET) Message-ID: <3E0C37AC.1A007145@lmf.ericsson.se> Date: Fri, 27 Dec 2002 13:21:16 +0200 X-Sybari-Trust: a523edbd 1864f774 a686a40a 00000138 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: sip@ietf.org Subject: Re: [Sip] INFO considered harmful References: <3E0B6293.4030600@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, From a SIP point of view your draft is basically talking about putting restrictions on what kind of message body types to use in INFO, since the SIP stack really doesn't care about what the application does with the data sent in the INFO. Now, does this mean that we also need to restrict what kind of message body types we allow in INVITE, re-INVITE and UPDATE? I know the stack can ignore message body types it doesn't support, but if people start sending their DTMF tones etc in THESE messages I think we still have the same interop/wrong-use-of problem as we currently have with INFO, don't we? Just some thoughts... Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Fri Dec 27 07:23:18 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06695 for ; Fri, 27 Dec 2002 07:23:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBRCScT01349 for sip-archive@odin.ietf.org; Fri, 27 Dec 2002 07:28:38 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBRCOIJ01211; Fri, 27 Dec 2002 07:24:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBRCNgJ01147 for ; Fri, 27 Dec 2002 07:23:42 -0500 Received: from hss.hns.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06602 for ; Fri, 27 Dec 2002 07:17:47 -0500 (EST) From: hbhondwe@hss.hns.com Received: from sampark.hss.hns.com (sampark [139.85.229.22]) by hss.hns.com (8.11.6/8.11.2) with SMTP id gBRBu9i21658; Fri, 27 Dec 2002 17:26:11 +0530 Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256C9C.00436B12 ; Fri, 27 Dec 2002 17:46:23 +0530 X-Lotus-FromDomain: HSSBLR To: sip@ietf.org cc: adam@dynamicsoft.com, simple@mailman.dynamicsoft.com Message-ID: <65256C9C.00436AD1.00@sampark.hss.hns.com> Date: Fri, 27 Dec 2002 17:46:21 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Sip] Comments on draft-roach-sip-list-template-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi, Some comments on this draft, assuming that this draft is open for comments. Not sure if this should go to Simple or Sip mailing list. 1)Section 4.3 Constructing Coherent Resource State, states "The resource list subscriber maintains a table for each resource list. The table contains a row for each resource in the resource list." and then it states that a version number is associated with each row of the resource list table. Why should a version be associated with each resource of a resource list? Should it not be associated with the resource list table instead? RFC 3265 states in section 4.3.2 State Deltas, "Any event package that supports delta changes to states MUST include a version number that increases by exactly one for each NOTIFY transaction in a subscription. ". 2)Section 4.3 (of the draft) states that when the version number jumps, the document received should be processed. I presume that "processing" implies what is elaborated in the same section later on. Extract from sec 4.3 of the draft: "If the value in the document is more than one higher than the local version number, the local version number is set to the value in the new document, the document is processed, and the .list subscriber SHOULD generate a refresh request to trigger a full state notification." whereas RFC 3265 in sec 4.3.2 says that when version number jumps , the Notify message can be ignored. Extract from RFC 3265, sec 4.3.2: "If a NOTIFY arrives that has a version number that is incremented by more than one, the subscriber knows that a state delta has been missed; it ignores the NOTIFY message containing the state delta (except for the version number, which it retains to detect message loss), and re-sends a SUBSCRIBE to force a NOTIFY containing a complete state snapshot. 3)Should the .list subscriber generate a refresh request even when the version is not consecutive AND "State" header indicates full state? The .list subcriber may have lost some intermediate notifications, but has now received full state. It can very well update its local version to the new version without doing any refresh. If the "State" indicates partial, however, then a refresh request is called for. thanks Harsh Bhondwe 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 mailnull@www1.ietf.org Fri Dec 27 08:27:48 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07628 for ; Fri, 27 Dec 2002 08:27:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBRDX9604489 for sip-archive@odin.ietf.org; Fri, 27 Dec 2002 08:33:09 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBRDSQJ04250; Fri, 27 Dec 2002 08:28:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBRDQ9J04190 for ; Fri, 27 Dec 2002 08:26:09 -0500 Received: from ws9.cdotb.ernet.in (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07466 for ; Fri, 27 Dec 2002 08:19:15 -0500 (EST) Received: from cdotb.ernet.in ([192.168.51.210]) by ws9.cdotb.ernet.in (8.9.3/8.9.3) with ESMTP id SAA27824; Fri, 27 Dec 2002 18:23:57 +0500 (GMT+0500) Message-ID: <3E0C50C8.4060302@cdotb.ernet.in> Date: Fri, 27 Dec 2002 18:38:24 +0530 From: Prakash R Reply-To: rprakash@cdotb.ernet.in Organization: C-DOT (Center for Development of Telematics) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021126 X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: cdotb.itg.stacks.sip To: Jonathan Rosenberg CC: "Vijay K. Gurbani" , sip@ietf.org, "Pramodh.N" , Gade Ramesh , Titty Thomas Subject: Re: [Sip] SIP backward compatibility issue References: <3E070194.6080006@cdotb.ernet.in> <3E0739F5.8050103@lucent.com> <3E0792FD.1040701@dynamicsoft.com> In-Reply-To: <3E0792FD.1040701@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > Vijay K. Gurbani wrote: > >>> 2) I was also wondering about the theoretical possibility of backward >>> compatibility? Any provisions in the protocol for an implementation >>> to detect and manage this issue? >> >> The SIP protocol number is still "SIP/2.0"; not "SIP/2.1". You could >> glean some information from the presence or absence of the Via magic >> cookie, but you should not depend on it for anything. > > There is absolutely no need. > > rfc3261 is sufficiently backwards compatible with rfc2543. There is no > need to detect versions or anything. Any backwards compatibility > functions are built into specific features of rfc3261 that needed to > support backwards compatibility. If you just implement rfc3261 you will > be backwards compatible. > > There is no versioning of the protocol. Things like the via cookie are > meant to deal with backwards compatibility for THAT SPECIFIC FEATURE. It > is possible to encounter an implementation that supports the contact > cookie, but is still a strict router. Using the contact cookie to imply > support for all of 3261 is a mistake. The lr parameter deals with the > record-routing changes, and the contact cookie, with the via header > changes. An rfc3261 stack compliant stack will be 100% backward compatible with a rfc2543 stack? I can just get the two stacks to interwork without any issues at all? All the rfc2543 gear already deployed will work smoothly with a new stack? Hope this is true... Makes life simple for us. >> There was a >> thread a while ago on why depending on the magic cookie for operations >> is not a good idea -- I don't have a reference to it (if someone else >> on the list does, feel free to post it). One of the reason you cannot >> depend on the magic cookie is that it only tells you something about >> the upstream UA and nothing about the downstream server (assuming you >> are a proxy). > > The problem, as I outline above, is we are not trying to strictly > version the protocol, but provide interoperability and backwards > compatibility on a feature-by-feature basis. So, via cookie tells you > nothing except that the via branch ID is sufficiently unique to be used > as a transaction ID. I was earlier thinking of using this branch-tag to check which rfc the remote stack was complying with. Was not clear with all the scenarios though. BTW, When will the protocol version be incremented? What sort of changes will necessitate a protocol version upgrade? I wasn't tracking the mailing list when the version got upgraded to 2.0. >>> 4) Does it make sense now to still deal with 2543? >> >> Sure. There is deployed gear that is rfc2543 compliant. 3Com's >> Ethernet SIP phones for example are still used in many installations >> (they work great) and are rfc2543 compliant only. > > As above, it is my opinion that rfc3261 sufficiently deals with rfc2543 > for any feature you are going to find in use from rfc2543. I think I'll currently stick to rfc3261 and hope for the best. Will deal with 2543 as and when issues arise... Regards, -- Prakash R Senior Program Manager, Internet Telephony Group ===================================================================== C-DOT (Centre for Development of Telematics) 71/1, Sneha Complex, Miller Road, Bangalore - 560052, India email: rprakash@cdotb.ernet.in, prakash_r@hotmail.com Phone: +91-80-2263399, +91-80-2383951, Fax: +91-80-2263256 ===================================================================== _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Sat Dec 28 01:37:06 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21617 for ; Sat, 28 Dec 2002 01:37:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBS6gm617556 for sip-archive@odin.ietf.org; Sat, 28 Dec 2002 01:42:48 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBS6crJ17368; Sat, 28 Dec 2002 01:38:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBS6WSJ16602 for ; Sat, 28 Dec 2002 01:32:28 -0500 Received: from bdsl.greycouncil.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21526 for ; Sat, 28 Dec 2002 01:26:14 -0500 (EST) Received: from softarmor.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.5/8.12.5) with ESMTP id gBS6TA8W003691; Sat, 28 Dec 2002 00:29:10 -0600 Message-ID: <3E0D44AF.8060301@softarmor.com> Date: Sat, 28 Dec 2002 00:29:03 -0600 From: Dean Willis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: sip@ietf.org Subject: Re: [Sip] INFO considered harmful References: <3E0B6293.4030600@dynamicsoft.com> In-Reply-To: <3E0B6293.4030600@dynamicsoft.com> X-Enigmail-Version: 0.65.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > Folks, > > For some time, I've been complaining about the continued abuse of the > INFO method for things that should be done other ways (frequently, not > using sip at all). I've written up a summary of the problems and a > proposed path forward. Specifically, I'd like to obsolete INFO and > replace it with a spec that is approved ONLY for SIP-T. > > Until the I-D appears, you can pick up a version at: > > http://www.jdrosen.net/papers/draft-rosenberg-sip-info-harmful-00.txt > http://www.jdrosen.net/papers/draft-rosenberg-sip-info-harmful-00.html Jonathan and I have had "extended discussions" on this. I'm more inclined to think that INFO needs specifications for specific usages, much as we use "events packages" for SIP Events (SUBSCRIBE, NOTIFY). In my own completely non-original way, I call these "INFO Packages". I think that the SIP-T usage of INFO is a perfect example of an INFO package. However, I think it is NOT the only reasonable use for INFO. Unsolicited in-dialog "stuff" is pretty darned useful. All we really need is for the usages to be differentiable, negotiable, and well-documented. Admittedly, INFO doesn't have any of those three characteristics right now, but I think we can probably fix it without breaking too much existing stuff. Anybody else have a third opinion? -- Dean Not Speaking From The 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 mailnull@www1.ietf.org Sat Dec 28 01:46:33 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21690 for ; Sat, 28 Dec 2002 01:46:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBS6qF517725 for sip-archive@odin.ietf.org; Sat, 28 Dec 2002 01:52:15 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBS6moJ17637; Sat, 28 Dec 2002 01:48:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBS6jTJ17595 for ; Sat, 28 Dec 2002 01:45:29 -0500 Received: from dyn-tx-app-007.dfw.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21635 for ; Sat, 28 Dec 2002 01:39:16 -0500 (EST) Received: from TXADAM (localhost.localdomain [127.0.0.1]) by dyn-tx-app-007.dfw.dynamicsoft.com (8.11.6/8.11.6) with SMTP id gBS6g5108521; Sat, 28 Dec 2002 00:42:05 -0600 Message-ID: <000b01c2ae3c$447786f0$6601a8c0@dynamicsoft.com> From: "Adam Roach" To: Cc: References: <3E070194.6080006@cdotb.ernet.in> <3E0739F5.8050103@lucent.com> <4.3.2.7.2.20021224112121.0207a0a0@dingdong.cisco.com> <4.3.2.7.2.20021224123942.0208c448@dingdong.cisco.com> Subject: Re: [Sip] SIP backward compatibility issue Date: Sat, 28 Dec 2002 00:42:03 -0600 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.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit "Prakash R" wrote in message news:3E0C50C8.4060302@cdotb.ernet.in... > An rfc3261 stack compliant stack will be 100% backward compatible with a > rfc2543 stack? I can just get the two stacks to interwork without any > issues at all? All the rfc2543 gear already deployed will work smoothly > with a new stack? Hope this is true... Makes life simple for us. Yes, that was a design goal for RFC3261. That said, there are "holes" in RFC2543 -- places in which the protocol was underspecified. Interop tests and operational experience have revealed these holes; all the ones that we have discovered to date have been fixed in RFC3261. So, there are ways to implement an RFC2543 stack that won't work in general (even with other RFC2543 stacks). There is obviously no magic fix for these problems. > I was earlier thinking of using this branch-tag to check which rfc the > remote stack was complying with. Was not clear with all the scenarios > though. Don't do that. Don't even try. You still encounter a huge number of stacks that use the branch parameter but don't do 100% of RFC3261. > BTW, When will the protocol version be incremented? What sort of changes > will necessitate a protocol version upgrade? From a practical perspective, I expect that such a change will be made only if enhancements to the protocol cannot be added in a way that is backwards compatible. For a parallel, see the rather major enhancements that occured between HTTP/1.0 and HTTP/1.1. If an overhaul of SIP of that magnitude is ever attempted, there might be a minor version increment. However, given the sheer volume of protocol spec at this point, it is quite unlikely (IMHO) that such an undertaking will ever be attempted. Further, because of the foresight of adding the "Require" and "Proxy-Require" mechanisms, it is additionally unlikely that such a change will ever even be desirable. A major version change, which is even less likely, would probably represent completely scrapping the protocol and starting from scratch. (As a footnote: like SIP, HTTP has had multiple RFCs that describe one protocol version: RFC2068 and RFC2616 both describe HTTP/1.1 -- so we're not doing anything particularly unprecedented or even unusual in doing the same). > I wasn't tracking the > mailing list when the version got upgraded to 2.0. It was almost 9 years ago. SIP/1.0 was one of the proposals for a session invitation protocol when the MMUSIC working group first started on that task back in early 1996. It was very terse and SDP-like. SCIP/1.0 was a proposal that was offered at the same time. Almost immediately, they were merged together into one protocol, dubbed "SIP/2.0". To my knowledge, neither of the original protocols ever escaped research facilities. > I think I'll currently stick to rfc3261 and hope for the best. Will deal > with 2543 as and when issues arise... You shouldn't have to. If you do encounter any such problems, please post about them to the list so we can register a bug and fix it in the next release. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Sat Dec 28 02:31:19 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02244 for ; Sat, 28 Dec 2002 02:31:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBS7b2r30278 for sip-archive@odin.ietf.org; Sat, 28 Dec 2002 02:37:02 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBS7X3J29922; Sat, 28 Dec 2002 02:33:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBS7TTJ29818 for ; Sat, 28 Dec 2002 02:29:29 -0500 Received: from dyn-tx-app-007.dfw.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02023 for ; Sat, 28 Dec 2002 02:23:15 -0500 (EST) Received: from TXADAM (localhost.localdomain [127.0.0.1]) by dyn-tx-app-007.dfw.dynamicsoft.com (8.11.6/8.11.6) with SMTP id gBS7QJ108672; Sat, 28 Dec 2002 01:26:19 -0600 Message-ID: <002c01c2ae42$69572ab0$6601a8c0@dynamicsoft.com> From: "Adam Roach" To: "Dean Willis" , "Jonathan Rosenberg" Cc: References: <3E0B6293.4030600@dynamicsoft.com> <3E0D44AF.8060301@softarmor.com> Subject: Re: [Sip] INFO considered harmful Date: Sat, 28 Dec 2002 01:26:17 -0600 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.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit From: "Dean Willis" > > http://www.jdrosen.net/papers/draft-rosenberg-sip-info-harmful-00.txt > > http://www.jdrosen.net/papers/draft-rosenberg-sip-info-harmful-00.html > > Jonathan and I have had "extended discussions" on this. I'm more > inclined to think that INFO needs specifications for specific usages, > much as we use "events packages" for SIP Events (SUBSCRIBE, NOTIFY). In > my own completely non-original way, I call these "INFO Packages". > > Anybody else have a third opinion? Not exactly a third opinion, but here goes: I agree 100% that something must be done about the current state of INFO. So far, with the one well-known exception, INFO has just served as a way that people can throw random crap in the body of a meaningless message so that their implementation has no chance of interoperating with any other, but can still claim 100% compliance with IETF proposed standard documents. (The embarassing thing is: they're not lying.) I'm not so set on which of the two actions (packages, or restriction to SIP-T) is correct. However, I find a couple of arguments that Jonathan makes in the draft extremely compelling: 1. The INFO spec does not actually define any semantics. It only says "this acts like a BYE, except that it doesn't tear the session down". 2. Any new feature that INFO enables could be defined by adding a new method; and, the existence of the INFO spec does not provide any ease over doing so. I'll add a third: despite INFO being an RFC for more than two years, there have been no additional internet-drafts that suggest alternate legitimate uses for this method. If it were useful enough to warrant saving, certainly at least one additional use would have been identified by now. These arguments would seem to indicate the path of deprecating INFO except for its only currently approved purpose: ISUP transfer. I can probably be swayed, but haven't heard any counter-arguments yet. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Sat Dec 28 14:58:17 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08479 for ; Sat, 28 Dec 2002 14:58:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBSK4FJ29581 for sip-archive@odin.ietf.org; Sat, 28 Dec 2002 15:04:15 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBSK0LJ29456; Sat, 28 Dec 2002 15:00:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBSJsVJ29344 for ; Sat, 28 Dec 2002 14:54:31 -0500 Received: from dyn-tx-app-007.dfw.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08407 for ; Sat, 28 Dec 2002 14:48:02 -0500 (EST) Received: from TXADAM (localhost.localdomain [127.0.0.1]) by dyn-tx-app-007.dfw.dynamicsoft.com (8.11.6/8.11.6) with SMTP id gBSJp1111385; Sat, 28 Dec 2002 13:51:01 -0600 Message-ID: <002001c2aeaa$6fbbb0c0$6601a8c0@dynamicsoft.com> From: "Adam Roach" To: "Christer Holmberg" , "Jonathan Rosenberg" Cc: References: <3E0B6293.4030600@dynamicsoft.com> <3E0C37AC.1A007145@lmf.ericsson.se> Subject: Re: [Sip] INFO considered harmful Date: Sat, 28 Dec 2002 13:50:54 -0600 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.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit From: "Christer Holmberg" > Now, does this mean that we also need to restrict what kind of message > body types we allow in INVITE, re-INVITE and UPDATE? Not really. INVITE means something: it means "I'm trying to set up a session, and here's a description of that session." The first half ("I'm trying to set up a session") has specific semantics associated with it. The second half ("here's a description of that session") tells you exactly what goes in the body. INFO just says "Here's a framed chunk of data." There is no valid comparison between the two. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Sat Dec 28 16:58:09 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09546 for ; Sat, 28 Dec 2002 16:58:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBSM4B601956 for sip-archive@odin.ietf.org; Sat, 28 Dec 2002 17:04:11 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBSM08J01762; Sat, 28 Dec 2002 17:00:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBSLr4J01421 for ; Sat, 28 Dec 2002 16:53:04 -0500 Received: from radvpost.RADVISION.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09353 for ; Sat, 28 Dec 2002 16:46:31 -0500 (EST) Received: by radvpost.radvision.com with Internet Mail Service (5.5.2653.19) id ; Sat, 28 Dec 2002 16:49:12 -0500 Message-ID: From: Orit Levin To: "'Dean Willis'" , Jonathan Rosenberg Cc: sip@ietf.org Subject: RE: [Sip] INFO considered harmful Date: Sat, 28 Dec 2002 16:49:11 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , I (also) vote for the direction #2 from the draft (i.e. convert INFO into a proper framework). I don't like using neither SIP Events nor INFO as general mechanisms for implementing applications only because they happened to be collocated with an existing SIP stack. I do think that both mechanisms are very useful for features closely related to the SIP call control (once these features are well-defined and standardized). An alternative would be maintaining an expensive separate transport channel for each of the light and complementary to the call control applications... On a different note, I would like to stress out that in general events vs. requests (when properly applied) would be different in semantics. In other words, it doesn't make sense for certain applications to use events and vs. versa. Each mechanism stands on its own and both are required. Orit Levin Chief Architect RADVISION Phone: +1.201.6896330 Video: +1.201.6896430 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Saturday, December 28, 2002 1:29 AM > To: Jonathan Rosenberg > Cc: sip@ietf.org > Subject: Re: [Sip] INFO considered harmful > > > > Jonathan Rosenberg wrote: > > Folks, > > > > For some time, I've been complaining about the continued abuse of the > > INFO method for things that should be done other ways (frequently, not > > using sip at all). I've written up a summary of the problems and a > > proposed path forward. Specifically, I'd like to obsolete INFO and > > replace it with a spec that is approved ONLY for SIP-T. > > > > Until the I-D appears, you can pick up a version at: > > > > http://www.jdrosen.net/papers/draft-rosenberg-sip-info-harmful-00.txt > > http://www.jdrosen.net/papers/draft-rosenberg-sip-info-harmful-00.html > > Jonathan and I have had "extended discussions" on this. I'm more > inclined to think that INFO needs specifications for specific usages, > much as we use "events packages" for SIP Events (SUBSCRIBE, NOTIFY). In > my own completely non-original way, I call these "INFO Packages". > > I think that the SIP-T usage of INFO is a perfect example of an INFO > package. However, I think it is NOT the only reasonable use for INFO. > Unsolicited in-dialog "stuff" is pretty darned useful. All we really > need is for the usages to be differentiable, negotiable, and > well-documented. Admittedly, INFO doesn't have any of those three > characteristics right now, but I think we can probably fix it without > breaking too much existing stuff. > > Anybody else have a third opinion? > > -- > Dean > Not Speaking From The 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Sat Dec 28 20:30:47 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11198 for ; Sat, 28 Dec 2002 20:30:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBT1aqp09857 for sip-archive@odin.ietf.org; Sat, 28 Dec 2002 20:36:52 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBT1XFJ09740; Sat, 28 Dec 2002 20:33:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBT1SAJ09612 for ; Sat, 28 Dec 2002 20:28:10 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11104 for ; Sat, 28 Dec 2002 20:21:34 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.25]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gBT1OgYH023130; Sat, 28 Dec 2002 20:24:42 -0500 (EST) Message-ID: <3E0E4ED7.4090900@dynamicsoft.com> Date: Sat, 28 Dec 2002 20:24:39 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis CC: sip@ietf.org Subject: Re: [Sip] INFO considered harmful References: <3E0B6293.4030600@dynamicsoft.com> <3E0D44AF.8060301@softarmor.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit inline. Dean Willis wrote: > > > Jonathan Rosenberg wrote: > >> Folks, >> >> For some time, I've been complaining about the continued abuse of the >> INFO method for things that should be done other ways (frequently, not >> using sip at all). I've written up a summary of the problems and a >> proposed path forward. Specifically, I'd like to obsolete INFO and >> replace it with a spec that is approved ONLY for SIP-T. >> >> Until the I-D appears, you can pick up a version at: >> >> http://www.jdrosen.net/papers/draft-rosenberg-sip-info-harmful-00.txt >> http://www.jdrosen.net/papers/draft-rosenberg-sip-info-harmful-00.html > > > Jonathan and I have had "extended discussions" on this. I'm more > inclined to think that INFO needs specifications for specific usages, > much as we use "events packages" for SIP Events (SUBSCRIBE, NOTIFY). In > my own completely non-original way, I call these "INFO Packages". > > I think that the SIP-T usage of INFO is a perfect example of an INFO > package. However, I think it is NOT the only reasonable use for INFO. > Unsolicited in-dialog "stuff" is pretty darned useful. All we really > need is for the usages to be differentiable, negotiable, and > well-documented. The point I was making in the draft was - why bother? INFO by itself provides nothing. If you want differentiable, negotiable and well-documented things, define them as new methods. What does INFO give you beyond that? > -- > Dean > Not Speaking From The Chair. > From the stool then? ;) -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.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 mailnull@www1.ietf.org Sun Dec 29 00:15:08 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13905 for ; Sun, 29 Dec 2002 00:15:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBT5LJc18522 for sip-archive@odin.ietf.org; Sun, 29 Dec 2002 00:21:19 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBT5HSJ18414; Sun, 29 Dec 2002 00:17:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBT5BCJ18338 for ; Sun, 29 Dec 2002 00:11:12 -0500 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13870 for ; Sun, 29 Dec 2002 00:04:30 -0500 (EST) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id gBT57afm013305; Sat, 28 Dec 2002 21:07:36 -0800 (PST) Received: from cj14 (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-9.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with SMTP id GOY00013; Sat, 28 Dec 2002 21:08:00 -0800 (PST) From: "Cullen Jennings" To: "Jonathan Rosenberg" , Subject: RE: [Sip] INFO considered harmful Date: Sat, 28 Dec 2002 21:11:31 -0800 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <3E0B6293.4030600@dynamicsoft.com> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Proposal 3 might result in moving the problem from INFO to the MESSAGE message. Cullen > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of > Jonathan Rosenberg > Sent: Thursday, December 26, 2002 12:12 PM > To: sip@ietf.org > Subject: [Sip] INFO considered harmful > > > Folks, > > For some time, I've been complaining about the continued abuse of the > INFO method for things that should be done other ways (frequently, not > using sip at all). I've written up a summary of the problems and a > proposed path forward. Specifically, I'd like to obsolete INFO and > replace it with a spec that is approved ONLY for SIP-T. > > Until the I-D appears, you can pick up a version at: > > http://www.jdrosen.net/papers/draft-rosenberg-sip-info-harmful-00.txt > http://www.jdrosen.net/papers/draft-rosenberg-sip-info-harmful-00.html > > Thanks, > Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.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 mailnull@www1.ietf.org Sun Dec 29 01:25:34 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14485 for ; Sun, 29 Dec 2002 01:25:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBT6ViY20987 for sip-archive@odin.ietf.org; Sun, 29 Dec 2002 01:31:44 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBT6S0J20875; Sun, 29 Dec 2002 01:28:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBT6NJJ20759 for ; Sun, 29 Dec 2002 01:23:19 -0500 Received: from dyn-tx-app-007.dfw.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14390 for ; Sun, 29 Dec 2002 01:16:38 -0500 (EST) Received: from TXADAM (localhost.localdomain [127.0.0.1]) by dyn-tx-app-007.dfw.dynamicsoft.com (8.11.6/8.11.6) with SMTP id gBT6JZ113423; Sun, 29 Dec 2002 00:19:35 -0600 Message-ID: <004e01c2af02$3c8d3e00$6601a8c0@dynamicsoft.com> From: "Adam Roach" To: "Cullen Jennings" , "Jonathan Rosenberg" , References: Subject: Re: [Sip] INFO considered harmful Date: Sun, 29 Dec 2002 00:19:25 -0600 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.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit From: "Cullen Jennings" > Proposal 3 might result in moving the problem from INFO to the MESSAGE > message. Yes, but that's an obvious and intentional abuse of the system, not a well-intentioned attempt at something "standard." Certain parties may actually be hellbent on being incompatible, and there's nothing we can do to fix their attitude. For the only slightly misguided, though, we could make it at least somewhat obvious what behavior is going to lead to interop problems. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Sun Dec 29 12:44:33 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00508 for ; Sun, 29 Dec 2002 12:44:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBTHoli01212 for sip-archive@odin.ietf.org; Sun, 29 Dec 2002 12:50:47 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBTHklJ01107; Sun, 29 Dec 2002 12:46:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBTHdsJ00865 for ; Sun, 29 Dec 2002 12:39:54 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00357 for ; Sun, 29 Dec 2002 12:32:57 -0500 (EST) Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id gBTHYVjS025576; Sun, 29 Dec 2002 09:34:31 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABM39695; Sun, 29 Dec 2002 09:31:51 -0800 (PST) Date: Sun, 29 Dec 2002 09:35:11 -0800 Subject: Re: [Sip] SIP backward compatibility issue Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Jonathan Rosenberg , "Vijay K. Gurbani" , rprakash@cdotb.ernet.in, sip@ietf.org, "Pramodh.N" , Gade Ramesh To: Steve Levy From: Rohan Mahy In-Reply-To: <4.3.2.7.2.20021224123942.0208c448@dingdong.cisco.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Tuesday, December 24, 2002, at 09:45 AM, Steve Levy wrote: > At 11:46 AM 12/24/2002 -0500, Jonathan Rosenberg wrote: >> Early media was not specified in rfc2543. It did say that you should >> be prepared to receive media before receiving the answer, which is >> still the case for 3264. Another issue was that people used to put >> SDP in non-reliable 1xx responses, and then put the same thing in >> 2xx. That case is explicitly allowed for in 3261, so it should >> interoperate as well. >> >> Perhaps you could identify the specific problem you are concerned >> about? > > my concern was SDP in a 18x followed by another 18x/2xx with different > SDP. Wouldnt the SDP in the subsequent 18x/2xx be treated differently > by 3264 compliant UAs as opposed to earlier 2543 compliant UAs ? Because offers and answers need to be sent reliably, you can't put an answer in a non-reliable 18x and an offer in a 2xx. This is spelled out in 3261 section 13 as quoted below... > If the initial offer is in an INVITE, the answer MUST be in a reliable > non-failure message from UAS back to UAC which is correlated to that > INVITE. For this specification, that is only the final 2xx response to > that INVITE. That same exact answer MAY also be placed in any > provisional responses sent prior to the answer. The UAC MUST treat the > first session description it receives as the answer, and MUST ignore > any session descriptions in subsequent responses to the initial > INVITE. thanks, -rohan > thx, > steve > > > >> -Jonathan R. >> >> Steve Levy wrote: >>> >>>> >>>> rfc3261 is sufficiently backwards compatible with rfc2543. There is >>>> no need to detect versions or anything. Any backwards compatibility >>>> functions are built into specific features of rfc3261 that needed >>>> to support backwards compatibility. If you just implement rfc3261 >>>> you will be backwards compatible. >>> >>> broadening the discussion to rfc 3264 (offer/answer), isn't there a >>> potential for backward compatibility issues with rfc 2543 >>> implementations wrt early media ? >>> thx, >>> steve >> >> -- >> Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. >> Chief Scientist First Floor >> dynamicsoft East Hanover, NJ 07936 >> jdrosen@dynamicsoft.com FAX: (973) 952-5050 >> http://www.jdrosen.net PHONE: (973) 952-5000 >> http://www.dynamicsoft.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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Sun Dec 29 13:18:22 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00921 for ; Sun, 29 Dec 2002 13:18:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBTIOlI02593 for sip-archive@odin.ietf.org; Sun, 29 Dec 2002 13:24:47 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBTILAJ02511; Sun, 29 Dec 2002 13:21:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBTIHhJ02432 for ; Sun, 29 Dec 2002 13:17:43 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00882 for ; Sun, 29 Dec 2002 13:10:47 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gBTIDrAv020738; Sun, 29 Dec 2002 19:13:53 +0100 (MET) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id ZGM0886T; Sun, 29 Dec 2002 19:13:53 +0100 Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.106.10]) by hendrix.lmf.ericsson.se (8.12.6/8.12.6/lmf-2.1-jcs) with ESMTP id gBTIDru4020616; Sun, 29 Dec 2002 20:13:53 +0200 (EET) Message-ID: <3E0F3B60.A1D37549@lmf.ericsson.se> Date: Sun, 29 Dec 2002 20:13:52 +0200 X-Sybari-Trust: 54d202e3 1864f774 a4c78476 00000138 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Adam Roach CC: Jonathan Rosenberg , sip@ietf.org Subject: Re: [Sip] INFO considered harmful References: <3E0B6293.4030600@dynamicsoft.com> <3E0C37AC.1A007145@lmf.ericsson.se> <002001c2aeaa$6fbbb0c0$6601a8c0@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, > >Now, does this mean that we also need to restrict what kind of message > >body types we allow in INVITE, re-INVITE and UPDATE? > > Not really. INVITE means something: it means "I'm trying to set up a > session, and here's a description of that session." The first half ("I'm > trying to set up a session") has specific semantics associated with it. The > second half ("here's a description of that session") tells you exactly what > goes in the body. > > INFO just says "Here's a framed chunk of data." > > There is no valid comparison between the two. I agree that the semantics of the commands are different. However, one IS allowed to include any kind of message body in the INVITE request, to provide whatever "extra information" about the session (text, HTML, whatever...), so someone could argue that whatever stuff they put into the INVITE does provide "extra information" about the session... And, since it IS allowed to send re-INVITE, or UPDATE, without actually updating the session description (the SDP message body) someone could include that whatever stuff also in those messages... I am not saying that anyone is doing that TODAY, though... Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Sun Dec 29 13:49:59 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01307 for ; Sun, 29 Dec 2002 13:49:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBTIuPv04061 for sip-archive@odin.ietf.org; Sun, 29 Dec 2002 13:56:25 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBTIqdJ03944; Sun, 29 Dec 2002 13:52:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBTImoJ03845 for ; Sun, 29 Dec 2002 13:48:50 -0500 Received: from dyn-tx-app-007.dfw.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01231 for ; Sun, 29 Dec 2002 13:41:53 -0500 (EST) Received: from TXADAM (localhost.localdomain [127.0.0.1]) by dyn-tx-app-007.dfw.dynamicsoft.com (8.11.6/8.11.6) with SMTP id gBTIio119004; Sun, 29 Dec 2002 12:44:50 -0600 Message-ID: <001901c2af6a$56b6a600$6401a8c0@dynamicsoft.com> From: "Adam Roach" To: "Christer Holmberg" Cc: "Jonathan Rosenberg" , References: <3E0B6293.4030600@dynamicsoft.com> <3E0C37AC.1A007145@lmf.ericsson.se> <002001c2aeaa$6fbbb0c0$6601a8c0@dynamicsoft.com> <3E0F3B60.A1D37549@lmf.ericsson.se> Subject: Re: [Sip] INFO considered harmful Date: Sun, 29 Dec 2002 12:44:36 -0600 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.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit From: "Christer Holmberg" > And, since it IS allowed to send re-INVITE, or UPDATE, without actually > updating the session description (the SDP message body) someone could include > that whatever stuff also in those messages... Ah -- I see what you're saying. The proposal was floated to deprecate INFO except for its currently defined use (ISUP transfer) -- so, you're arguing that we should deprecate INVITE except for its currently defined uses (setting up and modifying sessions), and deprecate UPDATE except for its currently defined use (modifying sessions), right? That's... interesting. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Sun Dec 29 14:06:11 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01465 for ; Sun, 29 Dec 2002 14:06:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBTJCb304984 for sip-archive@odin.ietf.org; Sun, 29 Dec 2002 14:12:37 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBTJ8sJ04885; Sun, 29 Dec 2002 14:08:54 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBTJ5qJ04221 for ; Sun, 29 Dec 2002 14:05:52 -0500 Received: from hclnpd.hclt.co.in (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01347 for ; Sun, 29 Dec 2002 13:58:53 -0500 (EST) Received: from blaze.hcltech.com (blaze.hclt-ntl.co.in [192.168.19.30]) by hclnpd.hclt.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Y1WDFTR1; Mon, 30 Dec 2002 00:32:45 +0530 Received: from sachinhome ([192.168.19.43]) by blaze.hcltech.com (8.9.3/8.9.3) with SMTP id AAA15716 for ; Mon, 30 Dec 2002 00:59:30 +0530 Message-ID: <006001c2af6e$9ed02660$a5f1fea9@sachinhome> From: "Sachin Shenoy" To: Date: Mon, 30 Dec 2002 00:42:49 +0530 Organization: HCL Technologies MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0045_01C2AF9C.610E95E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [Sip] Loop detection; Not a bad thing to have Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0045_01C2AF9C.610E95E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Loop detection was made optional in RFC 3261. Now it seems=20 that, due to a problem with its processing at stateless proxies,=20 loop-detection cannot be performed correctly (as it is given in RFC=20 3261) at stateless proxies. I think loop detection is not a bad thing to have. Our problem with loop detection is not because loop detection itself has problems. It is because we tried to overuse the branch-id parameter=20 for too many things. The purpose of branch-id parameter has=20 changed over time, but there seems to have been little or no attempt to redesign mechanism of loop-detection w.r.t. these=20 changes. I suggest removing the loop detection part from the branch-id parameter and placing it in a new parameter. Having loop detection done using a separate parameter would avoid it from interfering with branch-id's primary use as transaction identifier. All other=20 mechanism remaining the same as given in RFC 3261, I think, this will allow implementations to support loop detection without=20 much trouble. =20 Thanks Sachin ------=_NextPart_000_0045_01C2AF9C.610E95E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
Loop detection was made optional in RFC 3261. = Now it=20 seems
that, due to a problem with its = processing at=20 stateless proxies,
loop-detection cannot = be performed=20 correctly (as it is given in RFC
3261) at stateless proxies.
 
I think loop detection is not a bad thing to = have. Our=20 problem with
loop detection is not because loop detection = itself has=20 problems.
It is because we tried to overuse the = branch-id parameter
for too many things. = The purpose=20 of branch-id parameter has
changed over time, but there seems to have been little or = no
attempt to redesign=20 mechanism of loop-detection w.r.t. these=20
changes.
 
I suggest removing the loop detection part from = the=20 branch-id
parameter and placing it in a new = parameter. Having=20 loop detection
done using a separate parameter would = avoid it=20 from interfering
with branch-id's primary use as transaction = identifier. All other
mechanism remaining the same as given in RFC = 3261, I=20 think,
this will allow implementations to support loop=20 detection without
much trouble.
 
Thanks
Sachin
 
------=_NextPart_000_0045_01C2AF9C.610E95E0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Sun Dec 29 20:28:29 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05428 for ; Sun, 29 Dec 2002 20:28:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBU1Z3U21320 for sip-archive@odin.ietf.org; Sun, 29 Dec 2002 20:35:03 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBU1V5J21240; Sun, 29 Dec 2002 20:31:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBU1RTJ21131 for ; Sun, 29 Dec 2002 20:27:29 -0500 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05398 for ; Sun, 29 Dec 2002 20:20:24 -0500 (EST) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id gBU1NNfm022799; Sun, 29 Dec 2002 17:23:23 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAZ67739; Sun, 29 Dec 2002 17:16:20 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA26042; Sun, 29 Dec 2002 17:23:18 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15887.40965.977734.86775@thomasm-u1.cisco.com> Date: Sun, 29 Dec 2002 17:23:17 -0800 (PST) To: Robert Sparks Cc: Jonathan Rosenberg , Cullen Jennings , sip@ietf.org Subject: Re: [Sip] Enrollment in SIP services (and should we undeprecate basic auth) In-Reply-To: <1040415671.949.161.camel@RjS.localdomain> References: <004401c2a85e$99855700$618d6b80@amer.cisco.com> <3E0375E7.1080608@dynamicsoft.com> <1040415671.949.161.camel@RjS.localdomain> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Robert Sparks writes: > I see no value at all to resurrecting BASIC. > > If you are wanting to provide a shared secret and punt all of the > security responsibilities to the transport layer, then express that > secret in its native form (plaintext for a password). Anything else > you do wastes cycles and encourages people to make bad assumptions > about the level of protection they are getting (increasing the risk > that it would get foolishly used outside the environment you intended > to punt to). Er, that's what basic does. The reason that the password is in uuencode format is, I'd assume, to provide the ability to ship binary passwords, not security through obscurity. Mike _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Mon Dec 30 09:02:56 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24613 for ; Mon, 30 Dec 2002 09:02:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBUE9k904388 for sip-archive@odin.ietf.org; Mon, 30 Dec 2002 09:09:46 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBUE5uJ03697; Mon, 30 Dec 2002 09:05:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBUE3gJ03642 for ; Mon, 30 Dec 2002 09:03:42 -0500 Received: from node24.neomagic.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24548 for ; Mon, 30 Dec 2002 08:56:21 -0500 (EST) Received: from node26.neomagic.com (node26.neomagic.com [192.168.51.26]) by node24.neomagic.com (8.12.5/8.12.5) with ESMTP id gBUEuqwl032635 for ; Mon, 30 Dec 2002 06:56:52 -0800 Received: from neomagic.com ([192.168.31.253]) by node26.neomagic.com (8.12.5/8.12.5) with ESMTP id gBUExLxx001058 for ; Mon, 30 Dec 2002 06:59:23 -0800 Message-ID: <3E105179.2080902@neomagic.com> Date: Mon, 30 Dec 2002 19:30:25 +0530 From: Mukul Purohit Organization: NeoMagic User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.9) Gecko/20020311 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] resource reservation Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi, I have a basic question after going through RFC 3312, "Integration of Resource Management and SIP". Has the actual resource reservation mechanism been specified (mandated or suggested) by IETF? Also, has it been specified by any other body like 3GPP which has chosen SIP for signaling? Hope to get some quick replies. And if these queries are out of scope of this list, then a pointer to proper place will be appriciated. regards Mukul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Mon Dec 30 11:38:49 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26550 for ; Mon, 30 Dec 2002 11:38:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBUGjgl12243 for sip-archive@odin.ietf.org; Mon, 30 Dec 2002 11:45:42 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBUGffJ12120; Mon, 30 Dec 2002 11:41:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBUGdHJ12004 for ; Mon, 30 Dec 2002 11:39:17 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26484 for ; Mon, 30 Dec 2002 11:31:53 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.25]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gBUGZ1YH023839; Mon, 30 Dec 2002 11:35:02 -0500 (EST) Message-ID: <3E1075B3.4070602@dynamicsoft.com> Date: Mon, 30 Dec 2002 11:34:59 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christer Holmberg CC: Adam Roach , sip@ietf.org Subject: Re: [Sip] INFO considered harmful References: <3E0B6293.4030600@dynamicsoft.com> <3E0C37AC.1A007145@lmf.ericsson.se> <002001c2aeaa$6fbbb0c0$6601a8c0@dynamicsoft.com> <3E0F3B60.A1D37549@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit inline. Christer Holmberg wrote: > Hi, > > >>>Now, does this mean that we also need to restrict what kind of message >>>body types we allow in INVITE, re-INVITE and UPDATE? >> >>Not really. INVITE means something: it means "I'm trying to set up a >>session, and here's a description of that session." The first half ("I'm >>trying to set up a session") has specific semantics associated with it. The >>second half ("here's a description of that session") tells you exactly what >>goes in the body. >> >>INFO just says "Here's a framed chunk of data." >> >>There is no valid comparison between the two. > > > I agree that the semantics of the commands are different. However, one IS > allowed to include any kind of message body in the INVITE request, to provide > whatever "extra information" about the session (text, HTML, whatever...), so > someone could argue that whatever stuff they put into the INVITE does provide > "extra information" about the session... There is a huge difference that you are ignorning. The semantics of INVITE are well defined. SIP-guidelines says bodies can't change that basic semantic. Same with UPDATE. INFO has no defined semantic. Thus, it is not currently a violation of the spec (and indeed, seemingly encouraged by it) to place all kinds of stuff in it. THis is why we HAVE seen abuse of INFO, but not INVITE or UPDATE. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.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 mailnull@www1.ietf.org Mon Dec 30 11:38:55 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26563 for ; Mon, 30 Dec 2002 11:38:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBUGjmA12256 for sip-archive@odin.ietf.org; Mon, 30 Dec 2002 11:45:48 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBUGg7J12161; Mon, 30 Dec 2002 11:42:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBUGfYJ12114 for ; Mon, 30 Dec 2002 11:41:34 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26497 for ; Mon, 30 Dec 2002 11:34:10 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.25]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gBUGbKYH023842; Mon, 30 Dec 2002 11:37:21 -0500 (EST) Message-ID: <3E10763E.2070907@dynamicsoft.com> Date: Mon, 30 Dec 2002 11:37:18 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mukul Purohit CC: sip@ietf.org Subject: Re: [Sip] resource reservation References: <3E105179.2080902@neomagic.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Mukul Purohit wrote: > hi, > I have a basic question after going through RFC 3312, "Integration of > Resource Management and SIP". > > Has the actual resource reservation mechanism been specified (mandated > or suggested) by IETF? There is no mandatory resource reservation scheme. The primary one specified so far is RSVP. nsis is another one under development. Groups like packetcable have specified their own QoS protocols. > Also, has it been specified by any other body like 3GPP which has chosen > SIP for signaling? Yes, 3gpp has its own mechanisms that are specific to 3gpp. As I understand they are built into the GPRS procedures, and reservation occurs only on the wireless link. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.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 mailnull@www1.ietf.org Mon Dec 30 12:04:34 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26961 for ; Mon, 30 Dec 2002 12:04:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBUHBSK13985 for sip-archive@odin.ietf.org; Mon, 30 Dec 2002 12:11:28 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBUH7iJ13795; Mon, 30 Dec 2002 12:07:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBUH2AJ12754 for ; Mon, 30 Dec 2002 12:02:10 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26729 for ; Mon, 30 Dec 2002 11:54:45 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.25]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gBUGoJYH023846; Mon, 30 Dec 2002 11:50:19 -0500 (EST) Message-ID: <3E107948.10301@dynamicsoft.com> Date: Mon, 30 Dec 2002 11:50:16 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sachin Shenoy CC: sip@ietf.org Subject: Re: [Sip] Loop detection; Not a bad thing to have References: <006001c2af6e$9ed02660$a5f1fea9@sachinhome> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit inline. Sachin Shenoy wrote: > Hi, > Loop detection was made optional in RFC 3261. Now it seems > that, due to a problem with its processing at stateless proxies, > loop-detection cannot be performed correctly (as it is given in RFC > 3261) at stateless proxies. > > I think loop detection is not a bad thing to have. Our problem with > loop detection is not because loop detection itself has problems. > It is because we tried to overuse the branch-id parameter > for too many things. I disagree. Your assessment is quite at odds with my recollection of the history here. The problems we had with loop detection were that it became increasingly unclear about what a loop was, as opposed to a spiral. Initially (in rfc2543), a loop was any request that arrived at the same proxy (there were no spirals). It became clear that this was broken, so we had to consider changes in the request URI. Then, we ran into cases were other fields would change, such as Route headers, and those had to be taken into account as well. Real implementations were frequently getting this wrong, hampering interop and proper functioning of applications. As we began to realize that more and more headers might need to be taken into consideration, it became clear that properly doing loop detection was simultaneously ill-defined and complex to implement (potentially requiring hashes of the entire message). That is coupled with the fact that such loop conditions will probably be rare in deployed networks. Unlike IP routing, SIP routing is considerably more static, and I consider the likelihood of real loops a rare one outside of a lab. Thus, its appropriate to handle them in a way which perhaps consumes more resources, at the cost of much lower complexity, and more importantly, proper operation in the normal case. Thats the max-forwards mecahnism. It is much easier to implement, always correct in the normal case (i.e., it won't mis-detect loops), and much more interoperable. In other words - this is good engineering practice. We don't worry about optimally solving a corner case, we optimize for the baseline case. > The purpose of branch-id parameter has > changed over time, but there seems to have been little or no > attempt to redesign mechanism of loop-detection w.r.t. these > changes. > > I suggest removing the loop detection part from the branch-id > parameter and placing it in a new parameter. Having loop detection > done using a separate parameter would avoid it from interfering > with branch-id's primary use as transaction identifier. I am at a loss as to why you believe this will solve all the ails of loop detection. It is very easy to combine the functions of unique identification along with the change-detection functions of loop detections. You merely include a transaction ID as part of the long hash you are already doing. I fail to see why that is hard. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.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 mailnull@www1.ietf.org Mon Dec 30 12:33:25 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27766 for ; Mon, 30 Dec 2002 12:33:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBUHeJk15871 for sip-archive@odin.ietf.org; Mon, 30 Dec 2002 12:40:19 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBUHaUJ15027; Mon, 30 Dec 2002 12:36:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBUHZ2J14976 for ; Mon, 30 Dec 2002 12:35:02 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27425 for ; Mon, 30 Dec 2002 12:27:37 -0500 (EST) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id gBUHU9jS001848; Mon, 30 Dec 2002 09:30:09 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAZ75730; Mon, 30 Dec 2002 09:23:41 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA26198; Mon, 30 Dec 2002 09:30:38 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15888.33470.324282.680736@thomasm-u1.cisco.com> Date: Mon, 30 Dec 2002 09:30:38 -0800 (PST) To: Jonathan Rosenberg Cc: Christer Holmberg , Adam Roach , sip@ietf.org Subject: Re: [Sip] INFO considered harmful In-Reply-To: <3E1075B3.4070602@dynamicsoft.com> References: <3E0B6293.4030600@dynamicsoft.com> <3E0C37AC.1A007145@lmf.ericsson.se> <002001c2aeaa$6fbbb0c0$6601a8c0@dynamicsoft.com> <3E0F3B60.A1D37549@lmf.ericsson.se> <3E1075B3.4070602@dynamicsoft.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jonathan Rosenberg writes: > There is a huge difference that you are ignorning. > > The semantics of INVITE are well defined. SIP-guidelines says bodies > can't change that basic semantic. Same with UPDATE. > > INFO has no defined semantic. Thus, it is not currently a violation of > the spec (and indeed, seemingly encouraged by it) to place all kinds of > stuff in it. THis is why we HAVE seen abuse of INFO, but not INVITE or > UPDATE. So... s/INFO/X-SIPPING and be done with it? Mike _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Mon Dec 30 14:20:33 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00186 for ; Mon, 30 Dec 2002 14:20:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBUJRSr21689 for sip-archive@odin.ietf.org; Mon, 30 Dec 2002 14:27:28 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBUJNQJ21480; Mon, 30 Dec 2002 14:23:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBUJKSJ21318 for ; Mon, 30 Dec 2002 14:20:28 -0500 Received: from bdsl.greycouncil.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00075 for ; Mon, 30 Dec 2002 14:13:01 -0500 (EST) Received: from txdwillis (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.5/8.12.5) with ESMTP id gBUJG18W001854; Mon, 30 Dec 2002 13:16:01 -0600 From: "Dean Willis" To: "'Christer Holmberg'" , "'Adam Roach'" Cc: "'Jonathan Rosenberg'" , Subject: RE: [Sip] INFO considered harmful Date: Mon, 30 Dec 2002 13:15:46 -0600 Message-ID: <00c501c2b037$db7e90f0$56fa403f@txdwillis> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <3E0F3B60.A1D37549@lmf.ericsson.se> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gBUJKSJ21323 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Christer said: > I agree that the semantics of the commands are different. > However, one IS allowed to include any kind of message body > in the INVITE request, to provide whatever "extra > information" about the session (text, HTML, whatever...), so > someone could argue that whatever stuff they put into the > INVITE does provide "extra information" about the session... > > And, since it IS allowed to send re-INVITE, or UPDATE, > without actually updating the session description (the SDP > message body) someone could include that whatever stuff also > in those messages... That's actually quite interesting. One can get the same functionality as INFO using UPDATE methods. For example, SIP-T could encode the mid-session ISUP and send it using UPDATE. So, what is the semantic differentiation? I propose that we've been operating under a logic system where "UPDATE affects SIP state and INFO doesn't". It might be that this exposes a fallacy (which one might call "telephone centric" thinking) in our logic. There are really two different "sessions" in a typical SIP exchange: 1) The SIP-level session, or "dialog", framed in INVITE and BYE or SUBSCRIBE and BYE, and 2) the negotiated session, expressed in SDP, which may or may not exist. Since there may or may not be a negotiated session, and since SIP works just fine either way, is it reasonable to divide SIP mid-dialog semantics into "things that we think might affect the negotiated session", and "things that we think don't"? Perhaps all we're really doing is handing a blob of data to the application (which exists ABOVE the SIP layer), which then uses that information to affect its own state, and may consequently affect the SIP state? In any case, I think there is a much deeper semantic problem lurking here that we really haven't thought out. -- 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 mailnull@www1.ietf.org Mon Dec 30 14:20:36 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00201 for ; Mon, 30 Dec 2002 14:20:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBUJRWG21704 for sip-archive@odin.ietf.org; Mon, 30 Dec 2002 14:27:32 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBUJNtJ21512; Mon, 30 Dec 2002 14:23:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBUJKTJ21326 for ; Mon, 30 Dec 2002 14:20:29 -0500 Received: from bdsl.greycouncil.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00077 for ; Mon, 30 Dec 2002 14:13:02 -0500 (EST) Received: from txdwillis (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.5/8.12.5) with ESMTP id gBUJG18X001854; Mon, 30 Dec 2002 13:16:02 -0600 From: "Dean Willis" To: "'Jonathan Rosenberg'" Cc: Subject: RE: [Sip] INFO considered harmful Date: Mon, 30 Dec 2002 13:15:46 -0600 Message-ID: <00c601c2b037$dbcc89e0$56fa403f@txdwillis> 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.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <3E0E4ED7.4090900@dynamicsoft.com> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > The point I was making in the draft was - why bother? INFO by itself > provides nothing. If you want differentiable, negotiable and > well-documented things, define them as new methods. What does > INFO give > you beyond that? The ability to define a new usage without having to make code changes to one's SIP stack, just as Events allows. SIP, as you may have noticed, is a fairly complicated protocol. This has given rise to the distribution of reusable (even open source) SIP stacks. Personally I'm not up to hacking a new method (into, say, the Vovida stack) everytime I want to deliver a new type of blob. INFO, constructed as I've proposed, would let me implement a new INFO package on a stack without having to rewrite the stack. We'd just need an API to tell the stack what INFO packages we handled at the application layer, and it could do the rest of the work without caring what data is being transported in the INFOs. Events, you may have noticed, has exactly this property. At some level, this is comparable to the "Why do we use MIME instead of defining a new transport protocol for each and every possible type of data" argument. At its heart, INFO is for delivering APPLICATION SPECIFIC DATA within a dialog. The SIP state machine does not have to care about that data, just its delivery (although, as with SIP-T, the application itself may use the data to influence the SIP state machine via the stacks's APIs). If SIP were a proper transport protocol, we wouldn't have to define protocol extensions for every application-specific datum. I suspect that this working group has gotten very muddled between "application" and "transport" layers. We have atendency to try and define application semantics at the protocol level, and that's just wrong. The protocol should define only protocol semantics. -- 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 mailnull@www1.ietf.org Mon Dec 30 14:46:28 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00565 for ; Mon, 30 Dec 2002 14:46:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBUJrN423353 for sip-archive@odin.ietf.org; Mon, 30 Dec 2002 14:53:23 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBUJnUJ23212; Mon, 30 Dec 2002 14:49:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBUJm7J23150 for ; Mon, 30 Dec 2002 14:48:07 -0500 Received: from willow.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00533 for ; Mon, 30 Dec 2002 14:40:40 -0500 (EST) Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id gBUJhg802225; Mon, 30 Dec 2002 19:43:42 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Mon, 30 Dec 2002 14:45:50 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA815EB4D2@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Jonathan Rosenberg'" , sip@ietf.org Subject: RE: [Sip] INFO considered harmful Date: Mon, 30 Dec 2002 14:45:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , First, I think it is a really good idea to restrict the applicability of SIP INFO method - I very much agree with the problem defined in Section 2 of this draft. That much said, when it comes to solutions I am torn between option number 3 and a more radical alternative - deprecating INFO altogether. While it is true that INFO was inspired by some of the requirements of SIP-T, over time, we've found less and less use for INFO. The original vision for SIP+ (an ancestor of SIP-T) relied on INFO for sending virtually every ISUP message, but today, there just isn't that much that we do with INFO. Practically speaking, we could probably find alternatives to INFO for carrying ISUP data in these cases (which include SUS/RES, INF/INR, some provisional response cases). Using INFO to send other ISUP messages is frequently misguided, and can potentially lead to the same sorts of interoperability problems we have with INFO in other arenas. Today, however, RFC3398 does allow the use of INFO in these three cases, so it's simplest to let the INFO method to exist (option 3) for the time being - but we should be sure to document, even for ISUP transmissions, the cases in which it is and is not appropriate. In the long term, though, I think we should just get rid of it entirely. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Thursday, December 26, 2002 12:12 PM > To: sip@ietf.org > Subject: [Sip] INFO considered harmful > > > Folks, > > For some time, I've been complaining about the continued abuse of the > INFO method for things that should be done other ways > (frequently, not > using sip at all). I've written up a summary of the problems and a > proposed path forward. Specifically, I'd like to obsolete INFO and > replace it with a spec that is approved ONLY for SIP-T. > > Until the I-D appears, you can pick up a version at: > > http://www.jdrosen.net/papers/draft-rosenberg-sip-info-harmful-00.txt > http://www.jdrosen.net/papers/draft-rosenberg-sip-info-harmful-00.html > > Thanks, > Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.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 mailnull@www1.ietf.org Mon Dec 30 15:59:24 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01796 for ; Mon, 30 Dec 2002 15:59:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBUL6Ml27454 for sip-archive@odin.ietf.org; Mon, 30 Dec 2002 16:06:22 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBUL2WJ27341; Mon, 30 Dec 2002 16:02:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBUL0uJ27287 for ; Mon, 30 Dec 2002 16:00:56 -0500 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01745 for ; Mon, 30 Dec 2002 15:53:27 -0500 (EST) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id gBUKuTfm021909; Mon, 30 Dec 2002 12:56:29 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAZ81019; Mon, 30 Dec 2002 12:49:25 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA26218; Mon, 30 Dec 2002 12:56:22 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15888.45814.401844.797450@thomasm-u1.cisco.com> Date: Mon, 30 Dec 2002 12:56:22 -0800 (PST) To: "Dean Willis" Cc: "'Christer Holmberg'" , "'Adam Roach'" , "'Jonathan Rosenberg'" , Subject: RE: [Sip] INFO considered harmful In-Reply-To: <00c501c2b037$db7e90f0$56fa403f@txdwillis> References: <3E0F3B60.A1D37549@lmf.ericsson.se> <00c501c2b037$db7e90f0$56fa403f@txdwillis> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dean, I think the important part of the observation here is that if SIP defines a way to transport data, somebody really, really ought to define the color/shape/consistency of that data too. To not do that is to create interoperability problems by definition. Now there is a management question of _who_ defines those semantics -- eg, the SIP wg or somebody else, but I don't think there should be too much debate that it really ought to be done. Opening up the door for un(der)defined semantics seems really dangerous to me. A high energy barrier for new semantics is probably a Good Thing at this point as SIP is already a terribly complicated beast. To end up with an official backdoor for whatever kruft people want to wrap in a SIP packet seems, well, like shortcut on the road to hell. Mike Dean Willis writes: > > Christer said: > > I agree that the semantics of the commands are different. > > However, one IS allowed to include any kind of message body > > in the INVITE request, to provide whatever "extra > > information" about the session (text, HTML, whatever...), so > > someone could argue that whatever stuff they put into the > > INVITE does provide "extra information" about the session... > > > > And, since it IS allowed to send re-INVITE, or UPDATE, > > without actually updating the session description (the SDP > > message body) someone could include that whatever stuff also > > in those messages... > > That's actually quite interesting. One can get the same functionality as > INFO using UPDATE methods. For example, SIP-T could encode the mid-session > ISUP and send it using UPDATE. > > So, what is the semantic differentiation? > > I propose that we've been operating under a logic system where "UPDATE > affects SIP state and INFO doesn't". It might be that this exposes a fallacy > (which one might call "telephone centric" thinking) in our logic. There are > really two different "sessions" in a typical SIP exchange: 1) The SIP-level > session, or "dialog", framed in INVITE and BYE or SUBSCRIBE and BYE, and 2) > the negotiated session, expressed in SDP, which may or may not exist. > > Since there may or may not be a negotiated session, and since SIP works just > fine either way, is it reasonable to divide SIP mid-dialog semantics into > "things that we think might affect the negotiated session", and "things that > we think don't"? Perhaps all we're really doing is handing a blob of data to > the application (which exists ABOVE the SIP layer), which then uses that > information to affect its own state, and may consequently affect the SIP > state? > > In any case, I think there is a much deeper semantic problem lurking here > that we really haven't thought out. > > -- > 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 mailnull@www1.ietf.org Mon Dec 30 16:37:41 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02277 for ; Mon, 30 Dec 2002 16:37:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBULidn29953 for sip-archive@odin.ietf.org; Mon, 30 Dec 2002 16:44:39 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBULefJ29780; Mon, 30 Dec 2002 16:40:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBULcHJ29663 for ; Mon, 30 Dec 2002 16:38:17 -0500 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02135 for ; Mon, 30 Dec 2002 16:30:46 -0500 (EST) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id gBULXmfm004150; Mon, 30 Dec 2002 13:33:48 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAZ81803; Mon, 30 Dec 2002 13:26:46 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA26227; Mon, 30 Dec 2002 13:33:43 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15888.48055.267146.65154@thomasm-u1.cisco.com> Date: Mon, 30 Dec 2002 13:33:43 -0800 (PST) To: Jonathan Rosenberg Cc: Cullen Jennings , sip@ietf.org Subject: Re: [Sip] Enrollment in SIP services (and should we undeprecate basic auth) In-Reply-To: <3E0375E7.1080608@dynamicsoft.com> References: <004401c2a85e$99855700$618d6b80@amer.cisco.com> <3E0375E7.1080608@dynamicsoft.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jonathan Rosenberg writes: > I have been thinking about undeprecating basic, but for a totally > different reason (which was suggested by Christian some time back). When > you do authentication over TLS, there is no security benefits to digest > as opposed to basic. However, with basic, it is easier to integrate with > back-end AAA systems, because you don't need to assume that they've > stored the password in the form described in rfc 2617. > > Of course, if the server doing the authentication is several hops beyond > the one you've terminated your TLS connection to, you've got problems. > The combination of sips and basic would always work, however. While not passing judgement one way or the other, basic is clearly less secure than digest even with TLS. With digest, intermediate devices don't see the cleartext password -- including a directly adjacent (SIPwise) proxy. The AAA benefit you list specifically takes advantage of lowering the security bar (eg, so that the proxy can form a CHAP/PAP authenticator to send to a AAA). My sense is that if there are reasons people want to take advantage of basic, it might be better to consider the root causes first rather than rushing headlong into undeprecating (precating?) basic. Mike _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Mon Dec 30 16:40:06 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02297 for ; Mon, 30 Dec 2002 16:40:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBULl5330030 for sip-archive@odin.ietf.org; Mon, 30 Dec 2002 16:47:05 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBULhUJ29908; Mon, 30 Dec 2002 16:43:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBULg9J29853 for ; Mon, 30 Dec 2002 16:42:09 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02237 for ; Mon, 30 Dec 2002 16:34:39 -0500 (EST) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id gBULbBjS013761; Mon, 30 Dec 2002 13:37:11 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAZ81910; Mon, 30 Dec 2002 13:30:42 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA26230; Mon, 30 Dec 2002 13:37:39 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15888.48291.700746.59246@thomasm-u1.cisco.com> Date: Mon, 30 Dec 2002 13:37:39 -0800 (PST) To: Robert Sparks Cc: Jonathan Rosenberg , Cullen Jennings , sip@ietf.org Subject: Re: [Sip] Enrollment in SIP services (and should we undeprecate basic auth) In-Reply-To: <1040415671.949.161.camel@RjS.localdomain> References: <004401c2a85e$99855700$618d6b80@amer.cisco.com> <3E0375E7.1080608@dynamicsoft.com> <1040415671.949.161.camel@RjS.localdomain> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit One comment: Robert Sparks writes: > I don't understand the last statement. A system that accepts digest > credentials is not required to keep its local knowledge of the password > in the hash recommended in 2617. The problem is that AAA's expect either a CHAP or PAP formated authenticator. Digest, while it doesn't chip the cleartext password ain't the same format so you have a problem. Basic allows you to hack up an authenticator at the proxy. Maybe EAP+digest is our friend. Or maybe not. Mike _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Mon Dec 30 16:46:16 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02374 for ; Mon, 30 Dec 2002 16:46:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBULrFw30261 for sip-archive@odin.ietf.org; Mon, 30 Dec 2002 16:53:15 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBULnYJ30129; Mon, 30 Dec 2002 16:49:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBULmlJ30087 for ; Mon, 30 Dec 2002 16:48:47 -0500 Received: from dyn-tx-app-007.dfw.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02315 for ; Mon, 30 Dec 2002 16:41:16 -0500 (EST) Received: from TXADAM (localhost.localdomain [127.0.0.1]) by dyn-tx-app-007.dfw.dynamicsoft.com (8.11.6/8.11.6) with SMTP id gBULiM124683; Mon, 30 Dec 2002 15:44:22 -0600 Message-ID: <001d01c2b04c$902349b0$6401a8c0@dynamicsoft.com> From: "Adam Roach" To: "Dean Willis" , "'Jonathan Rosenberg'" Cc: References: <00c601c2b037$dbcc89e0$56fa403f@txdwillis> Subject: Re: [Sip] INFO considered harmful Date: Mon, 30 Dec 2002 15:43:59 -0600 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.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit From: "Dean Willis" > SIP, as you may have noticed, is a fairly complicated protocol. This has > given rise to the distribution of reusable (even open source) SIP stacks. > Personally I'm not up to hacking a new method (into, say, the Vovida stack) > everytime I want to deliver a new type of blob. INFO, constructed as I've > proposed, would let me implement a new INFO package on a stack without > having to rewrite the stack. We'd just need an API to tell the stack what > INFO packages we handled at the application layer, and it could do the rest > of the work without caring what data is being transported in the INFOs. So, your fundamental argument springs from the desire to have the API to most SIP stacks include a function called something like "registerNewInfoPackage" instead of "registerNewMethod". For some reason, that doesn't strike me as particularly compelling. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Mon Dec 30 16:52:31 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02484 for ; Mon, 30 Dec 2002 16:52:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBULxUn30467 for sip-archive@odin.ietf.org; Mon, 30 Dec 2002 16:59:30 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBULtlJ30353; Mon, 30 Dec 2002 16:55:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBULs3J30287 for ; Mon, 30 Dec 2002 16:54:03 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02390 for ; Mon, 30 Dec 2002 16:46:33 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.25]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gBULnhYH023940; Mon, 30 Dec 2002 16:49:43 -0500 (EST) Message-ID: <3E10BF75.9030902@dynamicsoft.com> Date: Mon, 30 Dec 2002 16:49:41 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis CC: sip@ietf.org Subject: Re: [Sip] INFO considered harmful References: <00c601c2b037$dbcc89e0$56fa403f@txdwillis> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit inline. Dean Willis wrote: >>The point I was making in the draft was - why bother? INFO by itself >>provides nothing. If you want differentiable, negotiable and >>well-documented things, define them as new methods. What does >>INFO give >>you beyond that? > > > The ability to define a new usage without having to make code changes to > one's SIP stack, just as Events allows. Code to handle INFO goes somewhere. > > SIP, as you may have noticed, is a fairly complicated protocol. This has > given rise to the distribution of reusable (even open source) SIP stacks. > Personally I'm not up to hacking a new method (into, say, the Vovida stack) > everytime I want to deliver a new type of blob. INFO, constructed as I've > proposed, would let me implement a new INFO package on a stack without > having to rewrite the stack. How is this different from allowing new methods, and passing off handling of that method to registered callbacks for each method?? Not different at all. > We'd just need an API to tell the stack what > INFO packages we handled at the application layer, Or, you could have an API to tell the stack what methods are handled. > and it could do the rest > of the work without caring what data is being transported in the INFOs. What work?? There is no semantics associated with INFO. None. Zero. Nada. Zip. > Events, you may have noticed, has exactly this property. The big huge difference I have been trying to point out is that EVENTS DEFINES SEMANTICS, whereas INFO doesnt. > > At some level, this is comparable to the "Why do we use MIME instead of > defining a new transport protocol for each and every possible type of data" > argument. MIME provides semantics and syntax that are independent of the type. SIP events provides semantics and syntax that are independent of the package. INFO provides nothing. > > At its heart, INFO is for delivering APPLICATION SPECIFIC DATA within a > dialog. The SIP state machine does not have to care about that data, just > its delivery (although, as with SIP-T, the application itself may use the > data to influence the SIP state machine via the stacks's APIs). If SIP were > a proper transport protocol, we wouldn't have to define protocol extensions > for every application-specific datum. SIP is not a protocol for shipping data between applications. I do not think we should encourage the arbitrary transport of stuff in SIP. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.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 mailnull@www1.ietf.org Mon Dec 30 16:53:04 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02630 for ; Mon, 30 Dec 2002 16:53:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBUM03830546 for sip-archive@odin.ietf.org; Mon, 30 Dec 2002 17:00:03 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBULuaJ30388; Mon, 30 Dec 2002 16:56:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBULtgJ30347 for ; Mon, 30 Dec 2002 16:55:42 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02438 for ; Mon, 30 Dec 2002 16:48:11 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.25]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gBULpJYH023949; Mon, 30 Dec 2002 16:51:19 -0500 (EST) Message-ID: <3E10BFD5.3050201@dynamicsoft.com> Date: Mon, 30 Dec 2002 16:51:17 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Thomas CC: Christer Holmberg , Adam Roach , sip@ietf.org Subject: Re: [Sip] INFO considered harmful References: <3E0B6293.4030600@dynamicsoft.com> <3E0C37AC.1A007145@lmf.ericsson.se> <002001c2aeaa$6fbbb0c0$6601a8c0@dynamicsoft.com> <3E0F3B60.A1D37549@lmf.ericsson.se> <3E1075B3.4070602@dynamicsoft.com> <15888.33470.324282.680736@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Michael Thomas wrote: > Jonathan Rosenberg writes: > > There is a huge difference that you are ignorning. > > > > The semantics of INVITE are well defined. SIP-guidelines says bodies > > can't change that basic semantic. Same with UPDATE. > > > > INFO has no defined semantic. Thus, it is not currently a violation of > > the spec (and indeed, seemingly encouraged by it) to place all kinds of > > stuff in it. THis is why we HAVE seen abuse of INFO, but not INVITE or > > UPDATE. > > So... s/INFO/X-SIPPING and be done with it? Sorry for being dense, but I don't follow what you mean here. If you are asking whether I am suggesting that people define their stuff as new methods, then yes, that is what I am suggesting. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.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 mailnull@www1.ietf.org Mon Dec 30 16:56:26 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02685 for ; Mon, 30 Dec 2002 16:56:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBUM3FO31189 for sip-archive@odin.ietf.org; Mon, 30 Dec 2002 17:03:15 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBULxdJ30490; Mon, 30 Dec 2002 16:59:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBULwKJ30430 for ; Mon, 30 Dec 2002 16:58:20 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02474 for ; Mon, 30 Dec 2002 16:50:50 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.25]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gBULrqYH023952; Mon, 30 Dec 2002 16:53:52 -0500 (EST) Message-ID: <3E10C06E.2010508@dynamicsoft.com> Date: Mon, 30 Dec 2002 16:53:50 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adam Roach CC: sip@ietf.org, rprakash@cdotb.ernet.in Subject: Re: [Sip] SIP backward compatibility issue References: <3E070194.6080006@cdotb.ernet.in> <3E0739F5.8050103@lucent.com> <4.3.2.7.2.20021224112121.0207a0a0@dingdong.cisco.com> <4.3.2.7.2.20021224123942.0208c448@dingdong.cisco.com> <000b01c2ae3c$447786f0$6601a8c0@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit A few additional notes inline. Adam Roach wrote: > "Prakash R" wrote in message > news:3E0C50C8.4060302@cdotb.ernet.in... > > >>An rfc3261 stack compliant stack will be 100% backward compatible with a >>rfc2543 stack? I can just get the two stacks to interwork without any >>issues at all? All the rfc2543 gear already deployed will work smoothly >>with a new stack? Hope this is true... Makes life simple for us. > > > Yes, that was a design goal for RFC3261. That said, there are "holes" in > RFC2543 -- places in which the protocol was underspecified. Interop tests > and operational experience have revealed these holes; all the ones that we > have discovered to date have been fixed in RFC3261. So, there are ways to > implement an RFC2543 stack that won't work in general (even with other > RFC2543 stacks). There is obviously no magic fix for these problems. There are also some never-implemented or never-used features of rfc2543 that were dropped, including PGP and absolute time in register expirations. Since these were never used outside of a lab, you shouldn't see them in real life. > > >>I was earlier thinking of using this branch-tag to check which rfc the >>remote stack was complying with. Was not clear with all the scenarios >>though. > > > > Don't do that. Don't even try. You still encounter a huge number of stacks > that use the branch parameter but don't do 100% of RFC3261. Right. I also tried to explain this. > > >>BTW, When will the protocol version be incremented? What sort of changes >>will necessitate a protocol version upgrade? > > >>From a practical perspective, I expect that such a change will be made only > if enhancements to the protocol cannot be added in a way that is backwards > compatible. You mean, never? We have no plans to ever rev the version. It makes no sense. Instead, we have looked at each feature, one at a time, and addressed backwards compatibility for it using mechanisms appropriate for that feature. That means that implementations can support grades of behavior (a very common case) rather than lumping everyting into a version number, which would effectively require dual-stacks. With our approach, there are no dual stacks. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.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 mailnull@www1.ietf.org Mon Dec 30 16:59:43 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02730 for ; Mon, 30 Dec 2002 16:59:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBUM6Wu31328 for sip-archive@odin.ietf.org; Mon, 30 Dec 2002 17:06:32 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBUM2sJ31169; Mon, 30 Dec 2002 17:02:54 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBUM18J30903 for ; Mon, 30 Dec 2002 17:01:08 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02644 for ; Mon, 30 Dec 2002 16:53:38 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.25]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gBULumYH023955; Mon, 30 Dec 2002 16:56:48 -0500 (EST) Message-ID: <3E10C11D.9010809@dynamicsoft.com> Date: Mon, 30 Dec 2002 16:56:45 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rohan Mahy CC: Steve Levy , "Vijay K. Gurbani" , rprakash@cdotb.ernet.in, sip@ietf.org, "Pramodh.N" , Gade Ramesh Subject: Re: [Sip] SIP backward compatibility issue References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Rohan Mahy wrote: > > On Tuesday, December 24, 2002, at 09:45 AM, Steve Levy wrote: > >> At 11:46 AM 12/24/2002 -0500, Jonathan Rosenberg wrote: >> >>> Early media was not specified in rfc2543. It did say that you should >>> be prepared to receive media before receiving the answer, which is >>> still the case for 3264. Another issue was that people used to put >>> SDP in non-reliable 1xx responses, and then put the same thing in >>> 2xx. That case is explicitly allowed for in 3261, so it should >>> interoperate as well. >>> >>> Perhaps you could identify the specific problem you are concerned about? >> >> >> my concern was SDP in a 18x followed by another 18x/2xx with different >> SDP. Wouldnt the SDP in the subsequent 18x/2xx be treated differently >> by 3264 compliant UAs as opposed to earlier 2543 compliant UAs ? > > > Because offers and answers need to be sent reliably, you can't put an > answer in a non-reliable 18x and an offer in a 2xx. This is spelled out > in 3261 section 13 as quoted below... All of this supposed "rfc2543 behavior" was never documented in rfc2543, and is rather one of several interpretations people have made about the spec. Even supposedly "rfc2543-compliant" UAs probably wont interwork for features like this. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.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 mailnull@www1.ietf.org Mon Dec 30 17:01:48 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02809 for ; Mon, 30 Dec 2002 17:01:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBUM8lx32021 for sip-archive@odin.ietf.org; Mon, 30 Dec 2002 17:08:47 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBUM5MJ31303; Mon, 30 Dec 2002 17:05:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBUM4CJ31250 for ; Mon, 30 Dec 2002 17:04:12 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02702 for ; Mon, 30 Dec 2002 16:56:42 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.25]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gBULxrYH023958; Mon, 30 Dec 2002 16:59:53 -0500 (EST) Message-ID: <3E10C1D6.6030305@dynamicsoft.com> Date: Mon, 30 Dec 2002 16:59:50 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Thomas CC: Cullen Jennings , sip@ietf.org Subject: Re: [Sip] Enrollment in SIP services (and should we undeprecate basic auth) References: <004401c2a85e$99855700$618d6b80@amer.cisco.com> <3E0375E7.1080608@dynamicsoft.com> <15888.48055.267146.65154@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit inline. Michael Thomas wrote: > Jonathan Rosenberg writes: > > I have been thinking about undeprecating basic, but for a totally > > different reason (which was suggested by Christian some time back). When > > you do authentication over TLS, there is no security benefits to digest > > as opposed to basic. However, with basic, it is easier to integrate with > > back-end AAA systems, because you don't need to assume that they've > > stored the password in the form described in rfc 2617. > > > > Of course, if the server doing the authentication is several hops beyond > > the one you've terminated your TLS connection to, you've got problems. > > The combination of sips and basic would always work, however. > > While not passing judgement one way or the other, > basic is clearly less secure than digest even with > TLS. With digest, intermediate devices don't see > the cleartext password -- including a directly > adjacent (SIPwise) proxy. The AAA benefit you list > specifically takes advantage of lowering the > security bar (eg, so that the proxy can form a > CHAP/PAP authenticator to send to a AAA). OK, a good point. > My sense > is that if there are reasons people want to take > advantage of basic, it might be better to consider > the root causes first rather than rushing headlong > into undeprecating (precating?) basic. I wasn't arguing to rush into anything. It was just a thought. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.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 mailnull@www1.ietf.org Mon Dec 30 17:05:16 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02847 for ; Mon, 30 Dec 2002 17:05:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBUMCG032144 for sip-archive@odin.ietf.org; Mon, 30 Dec 2002 17:12:16 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBUM8dJ32015; Mon, 30 Dec 2002 17:08:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBUM79J31520 for ; Mon, 30 Dec 2002 17:07:09 -0500 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02732 for ; Mon, 30 Dec 2002 16:59:38 -0500 (EST) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gBUM2eFp018395; Mon, 30 Dec 2002 14:02:40 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAZ82488; Mon, 30 Dec 2002 13:55:41 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA26239; Mon, 30 Dec 2002 14:02:38 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15888.49790.761732.576060@thomasm-u1.cisco.com> Date: Mon, 30 Dec 2002 14:02:38 -0800 (PST) To: Jonathan Rosenberg Cc: Michael Thomas , Christer Holmberg , Adam Roach , sip@ietf.org Subject: Re: [Sip] INFO considered harmful In-Reply-To: <3E10BFD5.3050201@dynamicsoft.com> References: <3E0B6293.4030600@dynamicsoft.com> <3E0C37AC.1A007145@lmf.ericsson.se> <002001c2aeaa$6fbbb0c0$6601a8c0@dynamicsoft.com> <3E0F3B60.A1D37549@lmf.ericsson.se> <3E1075B3.4070602@dynamicsoft.com> <15888.33470.324282.680736@thomasm-u1.cisco.com> <3E10BFD5.3050201@dynamicsoft.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jonathan Rosenberg writes: > > > Michael Thomas wrote: > > Jonathan Rosenberg writes: > > > There is a huge difference that you are ignorning. > > > > > > The semantics of INVITE are well defined. SIP-guidelines says bodies > > > can't change that basic semantic. Same with UPDATE. > > > > > > INFO has no defined semantic. Thus, it is not currently a violation of > > > the spec (and indeed, seemingly encouraged by it) to place all kinds of > > > stuff in it. THis is why we HAVE seen abuse of INFO, but not INVITE or > > > UPDATE. > > > > So... s/INFO/X-SIPPING and be done with it? > > Sorry for being dense, but I don't follow what you mean here. > > If you are asking whether I am suggesting that people define their stuff > as new methods, then yes, that is what I am suggesting. Sorry for being too flippant, but if we're going to have a junk heap for undefined semantics, some truth in advertising might be in order. Hence X-. Mike _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Mon Dec 30 17:33:00 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03214 for ; Mon, 30 Dec 2002 17:33:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBUMe0i01226 for sip-archive@odin.ietf.org; Mon, 30 Dec 2002 17:40:00 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBUMZuJ00451; Mon, 30 Dec 2002 17:35:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBUMYHJ00376 for ; Mon, 30 Dec 2002 17:34:17 -0500 Received: from zoe.office.snowshore.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03171 for ; Mon, 30 Dec 2002 17:26:46 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 30 Dec 2002 17:29:55 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209D097BBF@zoe.office.snowshore.com> Thread-Topic: INFO *is* Harmful; The Alternatives *are* Worse Thread-Index: AcKwUvo2q7sjITcMSGu1U5uhjpPwgQ== From: "Eric Burger" To: "SIP List (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gBUMYIJ00377 Subject: [Sip] INFO *is* Harmful; The Alternatives *are* Worse Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Speaking as an acknowledged INFO abuser (step 1 of the 12-step program?)... Dean hit the nail on the head: > -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] > > [snip] What does INFO give you beyond that? > > The ability to define a new usage without having to make code > changes to one's SIP stack, just as Events allows. What are my options when I want to *try* something new in the SIP world. I can: 1. Write an I-D, hoping to get an RFC published, before I have any road-time or clue how my idea will work in the real-world. 2. Hack my own method into my own infrastructure, and hope I never go outside my lab or tangentially interoperate with other SIP services. [N.B.: If those other SIP services needed to be aware of my change, they would be aware of my change BY DEFINITION.] 3. Hack my own APPLICATION payload onto a generic TRANSPORT mechanism that is well-known by the rest of the infrastructure. I'm open for Option 4... What we need is some way to do experiments without breaking stuff or having to hack everything. I am firmly on the record that option 1 is EVIL. IMHO it is a waste of resources to toss out ideas hoping to see what sticks. There needs to be a way of trying stuff out without burning WG cycles. Stuff doesn't need to be fully baked (in fact, it shouldn't be fully baked so when the WG sees the inevitable fatal flaw, no one is too upset to change). However, stuff should have seen the light of the real world to both work out the obvious "oh no's!" and the not so obvious "it should work, but it doesn't!". Option 2 is just a non-starter. I can speak to Option 3 from personal experience. We used INFO for information reporting from media servers. Is that the right answer today? No, of course not. NOTIFY is the right answer. However, NOTIFY didn't exist. More to the point, we have a lot of road-time on what does work, and what doesn't (e.g., HTTP does NOT work for everyone, re-INVITE takes too long and the dialog *isn't* changing, etc.). Now that we have real-world experience, we are in a position to publish the I-D, including using "modern" techniques, and go forward through the WG gauntlet. What is your proposal without INFO? Now my turn for a bit of soap-boxing: I absolutely, positively consider the statement that the use of INFO results in a lack of interoperability to be totally irrelevant. I posit this for two reasons. The first is that all of the "extensions" offered in "The Session Initiation Protocol (SIP) INFO Method Considered Harmful" as creating non-interoperable extensions actually were proposals to ENSURE INTEROPERABLE extensions. One cannot say, "using INFO is not interoperable" at the same time one says, "we will not allow anyone to define interoperable uses of INFO." That is like saying, "Only people that have sea duty can become an admiral, but you will never be allowed to have sea duty." One escape for that line of thinking is Dean's proposal for INFO packages. The problem here is that proposal would cast experiments in stone, like X-INFO. That smells like SOAP over SIP. The second reason I consider the statement of non-interoperability to be irrelevant is if one looks at two of the cited usages, "DTMF digits" and "media servers", *only* the client and the server are even AWARE of the capabilities. THERE IS NO THIRD PARTY THAT NEEDS TO NEGOTIATE THE CAPABILITY, EITHER "IN" OR "OUT". BY DEFINITION, THERE IS NO INTEROPERABILITY ISSUE. Why? Because the drafts describe how to interoperate, and messages will only ever originate and terminate at "aware" devices. Again, and I'm sure I'll have to point out this paragraph when people flame about the last paragraph, I see the use of INFO for experimental stuff. After the experiment is done, I will lay wagers that one of the following outcomes will occur. 1. What's being tried is really useful and fits into the SIP Framework. Very likely to be a new method. 2. What's being tried is really useful and something else already covers it, e.g., NOTIFY for digit reporting. 3. What's being tried is really useful but isn't SIP, e.g., bulk transfer of data, which is what FTP and HTTP are for. 4. What's being tried just doesn't work. Don't waste WG time on it. In fact, I would be one of the first to jump up and say "Whoa" when someone publishes a "we want to use INFO for..." I-D's. Why? Because one of the above 4 items really end up being the right answer. As hgs says, we have an infinite method namespace. On the other hand, let's say you don't want to use an infinite method namespace. In that case, I would put my weight behind Dean's suggestion to have INFO packages. Otherwise, and great apologies to Adam, but Christer is 100% correct. Banning INFO will move the problem to MESSAGE, INVITE, and UPDATE. We even saw a proposal to use SUBSCRIBE to change the state of the UAS as a way to "work around" the "INFO problem." Let's not make things worse! _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Mon Dec 30 17:36:12 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03237 for ; Mon, 30 Dec 2002 17:36:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBUMhCB01336 for sip-archive@odin.ietf.org; Mon, 30 Dec 2002 17:43:12 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBUMdVJ01172; Mon, 30 Dec 2002 17:39:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBUMc9J01119 for ; Mon, 30 Dec 2002 17:38:09 -0500 Received: from zoe.office.snowshore.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03185 for ; Mon, 30 Dec 2002 17:30:38 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 30 Dec 2002 17:33:47 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209D097BC0@zoe.office.snowshore.com> Thread-Topic: [Sip] INFO considered harmful Thread-Index: AcKtHfmY2Oe99UmMQsKFY7UPviKAwQDNQrFg From: "Eric Burger" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gBUMc9J01120 Subject: [Sip] SIP and Media Servers [was: INFO considered harmful] Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit "The guidelines for authors of SIP extensions[7] clearly rules some of them, such as media server control, out of scope." [7] clearly, and IMHO correctly, rules using SIP for device control to be out of scope. However, I would offer that media server control, e.g., "I want to route a SIP message to my farm of media servers (a routing problem), and possibly to a bunch in parallel (a forking problem) to the 'user' that represents an send-only source (a.k.a., an announcement)" is in scope. For that matter, the words "media server" never appear in [7] :-) [7] Rosenberg, J., "Guidelines for Authors of Extensions to the Session Initiation Protocol (SIP)", draft-ietf-sip-guidelines-06 (work in progress), November 2002. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Thursday, December 26, 2002 3:12 PM > To: sip@ietf.org > Subject: [Sip] INFO considered harmful > > > Folks, > > For some time, I've been complaining about the continued abuse of the > INFO method for things that should be done other ways > (frequently, not > using sip at all). I've written up a summary of the problems and a > proposed path forward. Specifically, I'd like to obsolete INFO and > replace it with a spec that is approved ONLY for SIP-T. > > Until the I-D appears, you can pick up a version at: > > http://www.jdrosen.net/papers/draft-rosenberg-sip-info-harmful-00.txt > http://www.jdrosen.net/papers/draft-rosenberg-sip-info-harmful-00.html > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Mon Dec 30 17:51:49 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03421 for ; Mon, 30 Dec 2002 17:51:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBUMwoE01814 for sip-archive@odin.ietf.org; Mon, 30 Dec 2002 17:58:50 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBUMsnJ01729; Mon, 30 Dec 2002 17:54:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBUMrXJ01691 for ; Mon, 30 Dec 2002 17:53:33 -0500 Received: from face.sentitonetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA03334 for ; Mon, 30 Dec 2002 17:46:01 -0500 (EST) Received: (qmail 37495 invoked from network); 30 Dec 2002 22:49:10 -0000 Received: from unknown (HELO overhill) (10.0.0.159) by face.sentito.com with SMTP; 30 Dec 2002 22:49:10 -0000 Message-ID: <006c01c2b055$aab320d0$9f00000a@overhill> From: "Frank W. Miller" To: References: <3E0F3B60.A1D37549@lmf.ericsson.se><00c501c2b037$db7e90f0$56fa403f@txdwillis> <15888.45814.401844.797450@thomasm-u1.cisco.com> Subject: Re: [Sip] INFO considered harmful Date: Mon, 30 Dec 2002 17:49:09 -0500 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.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Greetings, A lurker speaks! I've read Jonathan's draft and have some comments. Please be advised that these comments are meant to be constructive although they might seem a bit heavy handed at first reading. I would take issue with the basic premise of the draft, which is that the SIP and SIPPING groups need to have control over every bit that passes through a SIP message. It is not possible for the standard to anticpate every situation that people might want to use the protocol. It's interesting how many times I've heard WG members say, "thats not what I intended it for". The beauty of SIP is that its basic framework and semantic level endear it to so many different signaling situations. The use of INFO to supplement the corners of specific applications is a very important part of that versatility. JR cites three specific problems with INFO: Lack of interoperability: This is not a problem. Since the INFO contents are explicitly outside the standard, this must be assumed by the implementor. If they persist with INFO to implement some signaling situtations, there are likely other good reasons for doing so. Inappropriateness: As I've already stated, I do not feel that the SIP and SIPPING working groups should (let alone can) realistically expect that they can determine how and when the protocol will be applied in applications at this late date. Incorrectness: Jonathan is eluding to the possiblity of errors being present in the protocol extensions. Well, this is not the SIP and SIPPING groups problem. These extensions are outside the scope of the standard. If the purveyors of the extension design the error, they're responsible for it, not the SIP and SIPPING groups. As has already been noted in this thread, there are a number of fine implementations (including Dynamicsoft) in the field, many, if not all, including a punt to the application of the INFO body. This is very useful functionality to implementors and as such it makes very little sense to deprecate this method. Another will take its place as the abused. For example, I've had discussions with people about doing extensions using SUBSCRIBE/NOTIFY that had nothing whatever to do with events just because of the "political incorrectness" of INFO. The point is, what difference does it make. SIP and SIPPING can't control every use of the protocol and shouldnt try. To this end I would propose another radical approach to this problem. Limit the scope of the SIP and SIPPING groups to activities having to do with the base protocol, e.g. new methods and headers. Handling extensions can fall into two buckets 1) small extensions that handle corner cases in some signaling situations that aren't covered by the SIP spec and 2) major extensions that either add large, application-specific sets of signaling function or have really nothing to do with signaling. These latter extensions should be separated from SIP and SIPPING within IETF and handled in different WGs. FM Frank W. Miller, Ph.D. Chief Technical Officer sentitO Networks, Inc. fmiller@sentito.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 mailnull@www1.ietf.org Mon Dec 30 18:00:28 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03519 for ; Mon, 30 Dec 2002 18:00:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBUN7Th02582 for sip-archive@odin.ietf.org; Mon, 30 Dec 2002 18:07:29 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBUN41J01972; Mon, 30 Dec 2002 18:04:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBUN2lJ01932 for ; Mon, 30 Dec 2002 18:02:47 -0500 Received: from radvpost.RADVISION.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03483 for ; Mon, 30 Dec 2002 17:55:15 -0500 (EST) Received: by radvpost.radvision.com with Internet Mail Service (5.5.2653.19) id ; Mon, 30 Dec 2002 17:57:50 -0500 Message-ID: From: Orit Levin To: "'Jonathan Rosenberg'" , Dean Willis Cc: sip@ietf.org Subject: RE: [Sip] INFO considered harmful Date: Mon, 30 Dec 2002 17:57:43 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Inline. Orit. > The big huge difference I have been trying to point out is that EVENTS > DEFINES SEMANTICS, whereas INFO doesnt. > MIME provides semantics and syntax that are independent of the type. > SIP events provides semantics and syntax that are independent of the > package. > INFO provides nothing. INFO provides "minimal" but very important semantics: asynchronous data reliably follows the established SIP path. Another solution would be to have each pair of UAs registered to each other's event packages (and using EVENTs minimal semantics only). Would it be the preferred way to go??? _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Mon Dec 30 18:27:29 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03899 for ; Mon, 30 Dec 2002 18:27:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBUNYVe03533 for sip-archive@odin.ietf.org; Mon, 30 Dec 2002 18:34:31 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBUNUnJ03458; Mon, 30 Dec 2002 18:30:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBUNTqJ03419 for ; Mon, 30 Dec 2002 18:29:52 -0500 Received: from marionberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03868 for ; Mon, 30 Dec 2002 18:22:20 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id gBUNPSFk005519 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 30 Dec 2002 18:25:29 -0500 (EST) Message-ID: <3E10D655.5050206@cs.columbia.edu> Date: Mon, 30 Dec 2002 18:27:17 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Burger CC: "SIP List (E-mail)" Subject: Re: [Sip] INFO *is* Harmful; The Alternatives *are* Worse References: <4A3384433CE2AB46A63468CB207E209D097BBF@zoe.office.snowshore.com> In-Reply-To: <4A3384433CE2AB46A63468CB207E209D097BBF@zoe.office.snowshore.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I don't see the major problem of defining new methods. There seem to be two issues: programming and naming. I believe that modern stacks, like those based on the JAIN SIP API, have no problems dealing with new methods. (Somebody who has more day-to-day experience with this should confirm this...) Stack writers (for UA stacks) need to get used to the idea that new methods come along, so they should make it easy to register support for new (non-INVITE) methods. After all, this is pretty much just a table lookup. In terms of naming, there are at least two sensible approaches: - If you believe that the method may at some point be more generally applicable, give it a regular-looking SIP method name. If it doesn't get standardized but is deployed on a proprietary basis, your only 'problem' is that you may need to monitor the WGs to protest should somebody pick that name for something different. I suspect nobody wants to cause completely unnecessary interop problems, given that there is no scarcity of names. (We could have solved this problem differently and less informally, with the aid of IANA, but I've said my piece on that.) The best solution is clearly to not deploy stuff until there is some generally-agreed upon sense that this is stable. (Presumably, this means that it's past the IESG, at least.) Since that can take a few years, unless your affiliation reads 3GPP, this is asking a bit, but that's a different discussion... - If you believe that this is strictly your own proprietary thing that you don't want to bother documenting for whatever reason, make up your own name, such as "SNOWSHORE-EXPLODE-TERMINAL". Again, I wish there was a better mechanism for this, but that's a different discussion. Obviously, interoperability isn't going to be in the cards, but at least it is very obvious and obvious immediately that this is a non-standard extension, with a very well-understood error message (501) and negotiation mechanism (Allow). (No need to peek deep inside some generic INFO message and try to figure out what error indication would fit and no need to invent another Allow-* mechanism.) I'm not advocating the second approach; the INFO abuse seems to indicate, however, that the current approach leaves implementors short. (I don't think the approach in draft-narten-iana-experimental-allocations-03.txt is particularly applicable here since it assumes scarcity and advocates re-use of a small number range, which we don't need or want. We really don't want to designate INFO1, INFO2, INFO3, ..., INFO63 here...) 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 mailnull@www1.ietf.org Tue Dec 31 00:55:25 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08535 for ; Tue, 31 Dec 2002 00:55:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBV62ZG21620 for sip-archive@odin.ietf.org; Tue, 31 Dec 2002 01:02:35 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBV5wWJ21397; Tue, 31 Dec 2002 00:58:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBV5rKJ21257 for ; Tue, 31 Dec 2002 00:53:20 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08450 for ; Tue, 31 Dec 2002 00:45:40 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.25]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gBV5moYH024028; Tue, 31 Dec 2002 00:48:50 -0500 (EST) Message-ID: <3E112FBF.8040306@dynamicsoft.com> Date: Tue, 31 Dec 2002 00:48:47 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Orit Levin CC: Dean Willis , sip@ietf.org Subject: Re: [Sip] INFO considered harmful References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Orit Levin wrote: > Inline. > > Orit. > > >>The big huge difference I have been trying to point out is that EVENTS >>DEFINES SEMANTICS, whereas INFO doesnt. >>MIME provides semantics and syntax that are independent of the type. >>SIP events provides semantics and syntax that are independent of the >>package. >>INFO provides nothing. > > > INFO provides "minimal" but very important semantics: asynchronous data > reliably follows the established SIP path. Huh? Every new SIP method is reliable, it inherits the SIP transaction state machine for non-invite. Follows the established path? Every in-dialog method would have this property, it is method independent. Asynchronous? You can send any method at any time. Thus, nothing you have pointed out above is different between INFO and any other new method we might introduce. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.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 mailnull@www1.ietf.org Tue Dec 31 01:51:39 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08922 for ; Tue, 31 Dec 2002 01:51:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBV6wo524221 for sip-archive@odin.ietf.org; Tue, 31 Dec 2002 01:58:50 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBV6sUJ24146; Tue, 31 Dec 2002 01:54:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBV6rPJ24104 for ; Tue, 31 Dec 2002 01:53:25 -0500 Received: from bdsl.greycouncil.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08894 for ; Tue, 31 Dec 2002 01:45:43 -0500 (EST) Received: from dwillis9.softarmor.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.5/8.12.5) with ESMTP id gBV6mk8X005393; Tue, 31 Dec 2002 00:48:46 -0600 Message-Id: <5.2.0.9.0.20021231004126.025ac570@localhost> X-Sender: sipdean@localhost (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 31 Dec 2002 00:48:26 -0600 To: Jonathan Rosenberg , Orit Levin From: Dean Willis Subject: Re: [Sip] INFO considered harmful Cc: sip@ietf.org In-Reply-To: <3E112FBF.8040306@dynamicsoft.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , At 12:48 AM 12/31/2002 -0500, Jonathan Rosenberg wrote: >Orit Levin wrote: >>>The big huge difference I have been trying to point out is that EVENTS >>>DEFINES SEMANTICS, whereas INFO doesnt. >>>MIME provides semantics and syntax that are independent of the type. >>>SIP events provides semantics and syntax that are independent of the >>>package. >>>INFO provides nothing. >> >>INFO provides "minimal" but very important semantics: asynchronous data >>reliably follows the established SIP path. > >Huh? > >Every new SIP method is reliable, it inherits the SIP transaction state >machine for non-invite. Follows the established path? Every in-dialog >method would have this property, it is method independent. >Asynchronous? You can send any method at any time. > >Thus, nothing you have pointed out above is different between INFO and any >other new method we might introduce. I think the key point is that there is a difference between transport protocol semantic and application semantic. The transport protocol semantic expressed in INFO is "Here is some data that will be used by the application. It is not important to the transport protocol, except that the transport protocol is expected to deliver it reliably". INFO says NOTHING about the APPLICATION level semantic -- that's up to what goes IN the INFO payloads. The question is -- do we try to rigidly define application-level semantics here? Do we define that there ARE no such applications possible? Or do we design a framework by which application-level semantics can be expressed outside of the protocol definition? And as for "Just add another method to your SIP stack". Let's say I have a mobile phone and the SIP stack is burned into ROM and exposes only a simplistic transactional API. This is only likely to happen, oh, 100 million times or so over the next two years . . . Now, just exactly how is my BREW or JTME application going to go about extending the SIP stack to support another method? Will the evil wireless operator networks even pass another method? Neither is happening anytime soon, I think . . . -- 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 mailnull@www1.ietf.org Tue Dec 31 03:03:47 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19468 for ; Tue, 31 Dec 2002 03:03:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBV8Aw006339 for sip-archive@odin.ietf.org; Tue, 31 Dec 2002 03:10:58 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBV83sJ05536; Tue, 31 Dec 2002 03:03:54 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBV82KJ05493 for ; Tue, 31 Dec 2002 03:02:20 -0500 Received: from hclnpd.hclt.co.in (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19355 for ; Tue, 31 Dec 2002 02:54:38 -0500 (EST) Received: from blaze.hcltech.com (blaze.hclt-ntl.co.in [192.168.19.30]) by hclnpd.hclt.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Y1WDG29W; Tue, 31 Dec 2002 13:28:32 +0530 Received: from sachin-pc.netlab.hcltech.com ([192.168.201.60]) by blaze.hcltech.com (8.9.3/8.9.3) with ESMTP id NAA32757; Tue, 31 Dec 2002 13:55:24 +0530 Message-Id: <4.3.2.7.0.20021231124454.00e19220@blaze> X-Sender: sachins@blaze X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 31 Dec 2002 13:19:15 +0530 To: Jonathan Rosenberg From: Sachin Shenoy Subject: Re: [Sip] Loop detection; Not a bad thing to have Cc: sip@ietf.org In-Reply-To: <3E107948.10301@dynamicsoft.com> References: <006001c2af6e$9ed02660$a5f1fea9@sachinhome> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Please find my comments inline. >I disagree. Your assessment is quite at odds with my recollection of the >history here. > >The problems we had with loop detection were that it became increasingly >unclear about what a loop was, as opposed to a spiral. Initially (in >rfc2543), a loop was any request that arrived at the same proxy (there >were no spirals). It became clear that this was broken, so we had to >consider changes in the request URI. Then, we ran into cases were other >fields would change, such as Route headers, and those had to be taken into >account as well. Real implementations were frequently getting this wrong, >hampering interop and proper functioning of applications. As we began to >realize that more and more headers might need to be taken into >consideration, it became clear that properly doing loop detection was >simultaneously ill-defined and complex to implement (potentially requiring >hashes of the entire message). I have to admit I am quite unaware (ignorant) about these real-world problems. >That is coupled with the fact that such loop conditions will probably be >rare in deployed networks. Unlike IP routing, SIP routing is considerably >more static, and I consider the likelihood of real loops a rare one >outside of a lab. Thus, its appropriate to handle them in a way which >perhaps consumes more resources, at the cost of much lower complexity, and >more importantly, proper operation in the normal case. Thats the >max-forwards mecahnism. It is much easier to implement, always correct in >the normal case (i.e., it won't mis-detect loops), and much more interoperable. I have to take your word on this (that loops are rare). But sure it creates havoc once it happens. (Simple tests where request from UA looped between 2 proxies ran for more than 10 minutes. Where re transmissions of original INVITE from UA, the "Too Many hops" response and ACK for this just kept on circulating). >In other words - this is good engineering practice. We don't worry about >optimally solving a corner case, we optimize for the baseline case. I agree with this. Then can we assume (or hope) that in future standard loop detection would be deprecated? >> >>I suggest removing the loop detection part from the branch-id >>parameter and placing it in a new parameter. Having loop detection >>done using a separate parameter would avoid it from interfering >>with branch-id's primary use as transaction identifier. > >I am at a loss as to why you believe this will solve all the ails of loop >detection. It is very easy to combine the functions of unique >identification along with the change-detection functions of loop >detections. You merely include a transaction ID as part of the long hash >you are already doing. I fail to see why that is hard. Here I was trying to address (solve) a particular problem where stateless proxies cannot do loop detection. (There was an earlier mail which stated the problem subject:"[Sip] BranchID in CANCEL & INVITE"). Stateless proxies have to maintain same branch for CANCEL & INVITE. Now if stateless proxies try to do loop detection, the branch could turn out to be different for CANCEL & INVITE. (Loop detection part calculated for CANCEL could be different from the loop detection part calculated for INVITE). This is why I suggested moving the loop detection part out of BranchId. I mentioned this solution being quite unaware of the real problems plaguing loop detection. Again, if this is some feature that has lot of inherent problems with it, I think it is better to take it off completely. Thanks Sachin _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Tue Dec 31 07:24:07 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22370 for ; Tue, 31 Dec 2002 07:24:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBVCVPp18503 for sip-archive@odin.ietf.org; Tue, 31 Dec 2002 07:31:25 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBVCMxJ18271; Tue, 31 Dec 2002 07:23:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBVCJwJ18141 for ; Tue, 31 Dec 2002 07:19:58 -0500 Received: from lohi.eng.song.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22254 for ; Tue, 31 Dec 2002 07:12:08 -0500 (EST) Received: from jh by lohi.eng.song.fi with local (Exim 3.34 #1 (Debian)) id 18TLIY-0007Wo-00; Tue, 31 Dec 2002 14:15:06 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15889.35402.270711.303036@lohi.eng.song.fi> Date: Tue, 31 Dec 2002 14:15:06 +0200 To: Michael Thomas Cc: Robert Sparks , Jonathan Rosenberg , Cullen Jennings , sip@ietf.org Subject: Re: [Sip] Enrollment in SIP services (and should we undeprecate basic auth) In-Reply-To: <15888.48291.700746.59246@thomasm-u1.cisco.com> References: <004401c2a85e$99855700$618d6b80@amer.cisco.com> <3E0375E7.1080608@dynamicsoft.com> <1040415671.949.161.camel@RjS.localdomain> <15888.48291.700746.59246@thomasm-u1.cisco.com> X-Mailer: VM 6.97 under Emacs 20.7.2 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Michael Thomas writes: > The problem is that AAA's expect either a CHAP or > PAP formated authenticator. Digest, while it > doesn't chip the cleartext password ain't the same > format so you have a problem. Basic allows you to > hack up an authenticator at the proxy. Maybe > EAP+digest is our friend. Or maybe not. what is wrong with draft-sterman-aaa-sip-00.txt? we use it with digets authentication without any problems. leading radius servers support it as well as all good sip proxies. -- 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 mailnull@www1.ietf.org Tue Dec 31 08:19:52 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23016 for ; Tue, 31 Dec 2002 08:19:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBVDRBg21199 for sip-archive@odin.ietf.org; Tue, 31 Dec 2002 08:27:11 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBVDIVJ20906; Tue, 31 Dec 2002 08:18:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBVDHmJ20880 for ; Tue, 31 Dec 2002 08:17:48 -0500 Received: from mta1 (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22910 for ; Tue, 31 Dec 2002 08:09:31 -0500 (EST) Received: from Natarajucl1127 (mta1 [172.17.1.60]) by mta1.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.7 (built Jun 26 2002)) with ESMTPA id <0H7Z003HXJ7J9M@mta1.huawei.com> for sip@ietf.org; Tue, 31 Dec 2002 21:09:21 +0800 (CST) Date: Tue, 31 Dec 2002 18:43:16 +0530 From: "Nataraju A.B." To: sip@ietf.org Message-id: <004401c2b0ce$627520b0$5d02120a@in.huawei.com> Organization: Huawei Technologies India Pvt. Ltd., MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Mailer: Microsoft Outlook Express 5.50.4522.1200 Content-type: multipart/alternative; boundary="Boundary_(ID_hzMqxDpSi1EcthsVzTQLrQ)" X-Priority: 3 X-MSMail-priority: Normal References: <004401c2a85e$99855700$618d6b80@amer.cisco.com> <3E0375E7.1080608@dynamicsoft.com> <1040415671.949.161.camel@RjS.localdomain> <15888.48291.700746.59246@thomasm-u1.cisco.com> <15889.35402.270711.303036@lohi.eng.song.fi> Subject: [Sip] A simple query... Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --Boundary_(ID_hzMqxDpSi1EcthsVzTQLrQ) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT Hi, I have a query regarding the server/user-agent coding format: The ABNF encoding specifies it as : Server = "Server" HCOLON server-val *(LWS server-val) server-val = product / comment product = token [SLASH product-version] product-version = token whereas teh SIP-rfc says it should be Server: HomeServer v2 CanI know the correct format to be used. If the SIP format is to be used then is it product version is a mandatory argument. I feel the example given might be incorrect. It must have been like Server: HomeServer /v2 Regards, ------------------------------------------- Nataraju A.B. Huawei Technologies India Pvt. Ltd., Tel : +91-80-5216824/6/7 Xtn 142 ------------------------------------------- ----- Original Message ----- From: Juha Heinanen To: Michael Thomas Cc: Robert Sparks ; Jonathan Rosenberg ; Cullen Jennings ; sip@ietf.org Sent: Tuesday, 31 December 2002 17-45 Subject: Re: [Sip] Enrollment in SIP services (and should we undeprecate basic auth) Michael Thomas writes: > The problem is that AAA's expect either a CHAP or > PAP formated authenticator. Digest, while it > doesn't chip the cleartext password ain't the same > format so you have a problem. Basic allows you to > hack up an authenticator at the proxy. Maybe > EAP+digest is our friend. Or maybe not. what is wrong with draft-sterman-aaa-sip-00.txt? we use it with digets authentication without any problems. leading radius servers support it as well as all good sip proxies. -- 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 --Boundary_(ID_hzMqxDpSi1EcthsVzTQLrQ) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT
Hi,
I have a query regarding the server/user-agent coding format:
The ABNF encoding specifies it as : 
 
Server           =  "Server" HCOLON server-val *(LWS server-val)
server-val       =  product / comment
product          =  token [SLASH product-version]
product-version  =  token
 
whereas teh SIP-rfc says it should be
 Server: HomeServer v2
CanI know the correct format to be used.
 
If the SIP format is to be used then is it product version is a mandatory argument.
 
I feel the example given might be incorrect.
 
It must have been like Server: HomeServer /v2
 
Regards,
-------------------------------------------
Nataraju A.B.
Huawei Technologies India Pvt. Ltd.,
Tel : +91-80-5216824/6/7 Xtn 142
-------------------------------------------
----- Original Message -----
Sent: Tuesday, 31 December 2002 17-45
Subject: Re: [Sip] Enrollment in SIP services (and should we undeprecate basic auth)

Michael Thomas writes:

 > The problem is that AAA's expect either a CHAP or
 > PAP formated authenticator. Digest, while it
 > doesn't chip the cleartext password ain't the same
 > format so you have a problem. Basic allows you to
 > hack up an authenticator at the proxy. Maybe
 > EAP+digest is our friend. Or maybe not.

what is wrong with draft-sterman-aaa-sip-00.txt?  we use it with digets
authentication without any problems.  leading radius servers support it
as well as all good sip proxies.

-- 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
--Boundary_(ID_hzMqxDpSi1EcthsVzTQLrQ)-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Tue Dec 31 09:44:42 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24031 for ; Tue, 31 Dec 2002 09:44:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBVEq1N25326 for sip-archive@odin.ietf.org; Tue, 31 Dec 2002 09:52:01 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBVEhIJ25091; Tue, 31 Dec 2002 09:43:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBVEfWJ25054 for ; Tue, 31 Dec 2002 09:41:32 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23850 for ; Tue, 31 Dec 2002 09:33:42 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.25]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gBVEafYH024126; Tue, 31 Dec 2002 09:36:46 -0500 (EST) Message-ID: <3E11AB76.5080903@dynamicsoft.com> Date: Tue, 31 Dec 2002 09:36:38 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Nataraju A.B." CC: sip@ietf.org Subject: Re: [Sip] A simple query... References: <004401c2a85e$99855700$618d6b80@amer.cisco.com> <3E0375E7.1080608@dynamicsoft.com> <1040415671.949.161.camel@RjS.localdomain> <15888.48291.700746.59246@thomasm-u1.cisco.com> <15889.35402.270711.303036@lohi.eng.song.fi> <004401c2b0ce$627520b0$5d02120a@in.huawei.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit inline. Nataraju A.B. wrote: > Hi, > I have a query regarding the server/user-agent coding format: > The ABNF encoding specifies it as : > > Server = "Server" HCOLON server-val *(LWS server-val) > server-val = product / comment > product = token [SLASH product-version] > product-version = token > > whereas teh SIP-rfc says it should be > Server: HomeServer v2 > CanI know the correct format to be used. The above is just an example of the server header. It is a valid value according to the BNF, since the BNF allows a series of lws-separated tokens, without any slashes. Thus, either of these is valid: Server: HomeServer v2 Server: HomeServer/v2 > > If the SIP format is to be used then is it product version is a > mandatory argument. Version is not mandatory according to the BNF. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.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 mailnull@www1.ietf.org Tue Dec 31 09:54:26 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24178 for ; Tue, 31 Dec 2002 09:54:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBVF1jO25624 for sip-archive@odin.ietf.org; Tue, 31 Dec 2002 10:01:45 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBVEsHJ25430; Tue, 31 Dec 2002 09:54:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBVErcJ25376 for ; Tue, 31 Dec 2002 09:53:38 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24064 for ; Tue, 31 Dec 2002 09:45:48 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.25]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gBVEfKYH024129; Tue, 31 Dec 2002 09:41:20 -0500 (EST) Message-ID: <3E11AC8D.5090700@dynamicsoft.com> Date: Tue, 31 Dec 2002 09:41:17 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sachin Shenoy CC: sip@ietf.org Subject: Re: [Sip] Loop detection; Not a bad thing to have References: <006001c2af6e$9ed02660$a5f1fea9@sachinhome> <4.3.2.7.0.20021231124454.00e19220@blaze> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit inline. Sachin Shenoy wrote: > Please find my comments inline. > > >> That is coupled with the fact that such loop conditions will probably >> be rare in deployed networks. Unlike IP routing, SIP routing is >> considerably more static, and I consider the likelihood of real loops >> a rare one outside of a lab. Thus, its appropriate to handle them in a >> way which perhaps consumes more resources, at the cost of much lower >> complexity, and more importantly, proper operation in the normal case. >> Thats the max-forwards mecahnism. It is much easier to implement, >> always correct in the normal case (i.e., it won't mis-detect loops), >> and much more interoperable. > > > I have to take your word on this (that loops are rare). But sure it > creates havoc once > it happens. (Simple tests where request from UA looped between 2 proxies > ran for more > than 10 minutes. That should not happen. Max-Forwards should be preventing that. > Where re transmissions of original INVITE from UA, the > "Too Many hops" response and ACK for this just kept on circulating). The INVITE should not be retransmitted once the final response has arrived. It seems your problems are the result of faulty software, not an incorrect approach to handling loops. >> I am at a loss as to why you believe this will solve all the ails of >> loop detection. It is very easy to combine the functions of unique >> identification along with the change-detection functions of loop >> detections. You merely include a transaction ID as part of the long >> hash you are already doing. I fail to see why that is hard. > > > Here I was trying to address (solve) a particular problem where stateless > proxies cannot do loop detection. (There was an earlier mail which > stated the > problem subject:"[Sip] BranchID in CANCEL & INVITE"). Stateless proxies > have to maintain same branch for CANCEL & INVITE. Now if stateless proxies > try to do loop detection, the branch could turn out to be different for > CANCEL > & INVITE. (Loop detection part calculated for CANCEL could be different > from > the loop detection part calculated for INVITE). Not for any valid loop detection algorithm. CANCEL and INVITE will both share the same To, From, Call-ID, CSeq number, request-uri, route headers, and a whole bunch of other fields, pretty much anything that might be included in a loop detection hash (although i still feel that the whole process is brittle and unneeded). Max-Forwards is easier to deal with at a stateless proxy. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.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 mailnull@www1.ietf.org Tue Dec 31 14:38:20 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28157 for ; Tue, 31 Dec 2002 14:38:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBVJji208344 for sip-archive@odin.ietf.org; Tue, 31 Dec 2002 14:45:44 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBVJaqJ07273; Tue, 31 Dec 2002 14:36:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBVJSoJ07014 for ; Tue, 31 Dec 2002 14:28:50 -0500 Received: from imr2.ericy.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27804 for ; Tue, 31 Dec 2002 14:20:52 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.224.157]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id gBVJNpW29876; Tue, 31 Dec 2002 13:23:51 -0600 (CST) Received: from noah.lmc.ericsson.se (noah.lmc.ericsson.se [142.133.1.1]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id gBVJNpH14847; Tue, 31 Dec 2002 13:23:51 -0600 (CST) Received: from eammlex033.lmc.ericsson.se (eammlex033.lmc.ericsson.se [142.133.1.133]) by noah.lmc.ericsson.se (8.11.2/8.9.2) with ESMTP id gBVJNoh29779; Tue, 31 Dec 2002 14:23:50 -0500 (EST) Received: by eammlex033.lmc.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 31 Dec 2002 14:24:47 -0500 Message-ID: <32CD630F6CBED411AE180008C7894CBC0C037BF7@lmc37.lmc.ericsson.se> From: "George Foti (LMC)" To: "'Jonathan Rosenberg'" , Dean Willis Cc: sip@ietf.org Subject: RE: [Sip] INFO considered harmful Date: Tue, 31 Dec 2002 14:23:43 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="ISO-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , The requirement is to be able to send application data transperently e2e via the SIP proxies, without impacting the SIP state machine. It is as simple as that. INFO fulfills that requirement. 1) To suggest that this is an abuse of INFO as it permits SIP to be used as transport is simply bogus. This will be the case with any other proprietary method, anyways. So there is simply no teeth in this argument. No wireless device will maintain X methods simply to be able to communicate with x ASs belonging to X vendors. It is simply not a workable solution. This is not about coding. This just does not make sence, and serves no purpose other than shear control of what goes in INFO, or the likes. 2) To claim that INFO has no semantics so it is useless simply does not work either. The requirment calls precisely for that. We *dont want* semantics associated with INFO. It is e2e and transperent. Any suggestion to try and standardize what should be carried in INFO or whatever else is doomed to failure. 3) To suggest that MESSAGE can be used instead of INFO, so what have we solved ??? So far, the so claimed harm has not been spelled whatsoever. It sounds like a philosophical harm. Deprecating INFO or limiting its use, will create more interoperability problems, without solving anything. Bodies like 3GPP will not buy into that. I think that before we shoot ourselves in the leg, come up with the requirements and proposals. Then and only then we can decide what should be done with INFO. Rgds/gf -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Monday, December 30, 2002 4:50 PM To: Dean Willis Cc: sip@ietf.org Subject: Re: [Sip] INFO considered harmful inline. Dean Willis wrote: >>The point I was making in the draft was - why bother? INFO by itself >>provides nothing. If you want differentiable, negotiable and >>well-documented things, define them as new methods. What does >>INFO give >>you beyond that? > > > The ability to define a new usage without having to make code changes to > one's SIP stack, just as Events allows. Code to handle INFO goes somewhere. > > SIP, as you may have noticed, is a fairly complicated protocol. This has > given rise to the distribution of reusable (even open source) SIP stacks. > Personally I'm not up to hacking a new method (into, say, the Vovida stack) > everytime I want to deliver a new type of blob. INFO, constructed as I've > proposed, would let me implement a new INFO package on a stack without > having to rewrite the stack. How is this different from allowing new methods, and passing off handling of that method to registered callbacks for each method?? Not different at all. > We'd just need an API to tell the stack what > INFO packages we handled at the application layer, Or, you could have an API to tell the stack what methods are handled. > and it could do the rest > of the work without caring what data is being transported in the INFOs. What work?? There is no semantics associated with INFO. None. Zero. Nada. Zip. > Events, you may have noticed, has exactly this property. The big huge difference I have been trying to point out is that EVENTS DEFINES SEMANTICS, whereas INFO doesnt. > > At some level, this is comparable to the "Why do we use MIME instead of > defining a new transport protocol for each and every possible type of data" > argument. MIME provides semantics and syntax that are independent of the type. SIP events provides semantics and syntax that are independent of the package. INFO provides nothing. > > At its heart, INFO is for delivering APPLICATION SPECIFIC DATA within a > dialog. The SIP state machine does not have to care about that data, just > its delivery (although, as with SIP-T, the application itself may use the > data to influence the SIP state machine via the stacks's APIs). If SIP were > a proper transport protocol, we wouldn't have to define protocol extensions > for every application-specific datum. SIP is not a protocol for shipping data between applications. I do not think we should encourage the arbitrary transport of stuff in SIP. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.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 mailnull@www1.ietf.org Tue Dec 31 15:52:05 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29027 for ; Tue, 31 Dec 2002 15:52:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBVKxVU11369 for sip-archive@odin.ietf.org; Tue, 31 Dec 2002 15:59:31 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBVKokJ11218; Tue, 31 Dec 2002 15:50:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBVKlXJ11133 for ; Tue, 31 Dec 2002 15:47:33 -0500 Received: from hclnpd.hclt.co.in (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28923 for ; Tue, 31 Dec 2002 15:39:35 -0500 (EST) Received: from blaze.hcltech.com (blaze.hclt-ntl.co.in [192.168.19.30]) by hclnpd.hclt.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Y1WDGR9G; Wed, 1 Jan 2003 02:13:30 +0530 Received: from sachinhome ([192.168.19.43]) by blaze.hcltech.com (8.9.3/8.9.3) with SMTP id CAA07308; Wed, 1 Jan 2003 02:40:19 +0530 Message-ID: <00a901c2b10f$0ba53f40$a5f1fea9@sachinhome> From: "Sachin Shenoy" To: "Jonathan Rosenberg" Cc: References: <006001c2af6e$9ed02660$a5f1fea9@sachinhome> <4.3.2.7.0.20021231124454.00e19220@blaze> <3E11AC8D.5090700@dynamicsoft.com> Subject: Re: [Sip] Loop detection; Not a bad thing to have Date: Wed, 1 Jan 2003 02:26:07 +0530 Organization: HCL Technologies 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 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit please find my comments inline. > > I have to take your word on this (that loops are rare). But sure it > > creates havoc once > > it happens. (Simple tests where request from UA looped between 2 proxies > > ran for more > > than 10 minutes. > > That should not happen. Max-Forwards should be preventing that. Max-Forwards did work in this case. But didn't prevent the above mentioned problem. > > Where re transmissions of original INVITE from UA, the > > "Too Many hops" response and ACK for this just kept on circulating). > > The INVITE should not be retransmitted once the final response has arrived. > > It seems your problems are the result of faulty software, not an > incorrect approach to handling loops. Let me check and confirm these figures again (will take sometime). But if I remember correctly the time taken for the request to go 70 hops forward & the "Too May Hops" response to take 70 hops backwards was enough for the retransmissions to fireup.(Maybe the implementation chose to queueup too many messages rather than dropping them and as a result was not able to flush them out properly). As you said this could be the case of faulty software, I have to double check it. > > Here I was trying to address (solve) a particular problem where stateless > > proxies cannot do loop detection. (There was an earlier mail which > > stated the > > problem subject:"[Sip] BranchID in CANCEL & INVITE"). Stateless proxies > > have to maintain same branch for CANCEL & INVITE. Now if stateless proxies > > try to do loop detection, the branch could turn out to be different for > > CANCEL > > & INVITE. (Loop detection part calculated for CANCEL could be different > > from > > the loop detection part calculated for INVITE). > > Not for any valid loop detection algorithm. I think this is a known bug in the RFC3261 and has already been logged in bugzilla. http://www.sipwg.org/sipwg/show_bug.cgi?id=659 > CANCEL and INVITE will both share the same To, From, Call-ID, CSeq > number, request-uri, route headers, and a whole bunch of other fields, > pretty much anything that might be included in a loop detection hash > (although i still feel that the whole process is brittle and unneeded). CANCEL & INVITE need not share Require & Proxy-Require fields according to RFC 3261. RFC 3261 explicilty states that CANCEL MUST NOT have Require & Proxy-Require (Section 9.1), while INVITE may have them. An implementation choosing to use these fields for calculating the loop-detection part would end up having different value for the hash. Placing this hash in branch would break the transaction matching rules where CANCEL & INVITE should have the same branch-id's (Section 9.1). From what I can see there are 2 ways to go. 1. Deprecate loop detection. 2. Keep loop detection. 1. Deprecate loop detection. A non issue for me (actually I am for this). 2. Keep loop detection. If we choose this, let us take full advantage of it. Let it be possible for stateless proxies to detect loops. Let us take the loop detection part out of branch-id (which will solve the above mentioned problem) or find some other solution to the problem. Anyway, I fail to see any advantage of retaining the loop-detection part in branch-id. If anything it can only cause problems. Keep unrelated things separate - A good design practice. We don't want to worry about things interfering with each other. (In this particular case transaction matching & loop-detection). Again, I am also for the Max-Forward solution as it is much simpler and straight forward as you point. But then, some consensus have to be reached on what has to be done with the existing mechanism of loop-detection. Implementators (like me) should be given a clear direction to proceed with. Thanks Sachin >"9.1 Client Behavior > ... > The CANCEL request MUST NOT contain any Require or Proxy-Require header > fields." > "9.1 Client Behavior > ... > A CANCEL constructed by a client MUST have only a single Via header field > value matching the top Via value in the request being cancelled. Using > the same > values for these header fields allows the CANCEL to be matched with the > request it cancels (Section 9.2 indicates how such matching occurs)." _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 mailnull@www1.ietf.org Tue Dec 31 18:21:47 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00900 for ; Tue, 31 Dec 2002 18:21:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gBVNT6w17965 for sip-archive@odin.ietf.org; Tue, 31 Dec 2002 18:29:06 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBVNNBJ17849; Tue, 31 Dec 2002 18:23:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBVNJZJ17769 for ; Tue, 31 Dec 2002 18:19:35 -0500 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00831 for ; Tue, 31 Dec 2002 18:11:33 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id gBVNEhKv015324 for ; Tue, 31 Dec 2002 15:14:43 -0800 (PST) Received: from bhadoria-lnx.cisco.com (bhadoria-lnx.cisco.com [128.107.140.160]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABS88517; Tue, 31 Dec 2002 15:14:42 -0800 (PST) Date: Tue, 31 Dec 2002 15:14:42 -0800 (PST) From: Amit Bhadoria To: sip@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Sip] TLS: how to validate multiple domains with single certificate (fwd) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , repost from yesterday... ---------- Forwarded message ---------- Date: Mon, 30 Dec 2002 17:20:50 -0800 (PST) From: Amit Bhadoria To: sip@ietf.org Subject: [TLS] how to validate multiple domains with single certificate hi, i have some questions based on rfc 3263 "locating sip services". in rfc 3263 it is mentioned that: "For NAPTR records with SIPS protocol fields, (if the server is using a site certificate), the domain name in the query and the domain name in the replacement field MUST both be valid based on the site certificate handed out by the server in the TLS exchange. Similarly, the domain name in the SRV query and the domain name in the target in the SRV record MUST both be valid based on the same site certificate. Otherwise, an attacker could modify the DNS records to contain replacement values in a different domain, and the client could not validate that this was the desired behavior or the result of an attack." now, there are three potentially different domains in concern while processing a SIPS request: 1. domain used in NAPTR querry: this is the target domain for this request 2. domain mentioned in replacement field of NAPTR records: this is the domain used in the SRV querry, obtained from replacement field of NAPTR records 3. domain mentioned in target in the SRV record: the domain mentioned in the SRV record selected for final A lookup is it possible to have all the three domains different, or is it just a bad example (due to my limited knowledge of DNS setups), and in practical cases the three domains will either be same as TARGET or a subdomain of it? incase my imagination is correct, and it is possible to have a setup where all three domains (from three steps of DNS procedures) are different, then how can a client validate these three domains using the same certificate? i'd appreciate your comments/explanation to my querries. thanks, -amit. ---------------------------------------------------------------------------- I have hardly ever known a mathematician who was capable of reasoning. -- gnulib _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip