From sip-bounces@ietf.org Wed Aug 01 00:51:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IG6AR-0002Ev-7v; Wed, 01 Aug 2007 00:50:39 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IG6AP-0002Em-ST for sip-confirm+ok@megatron.ietf.org; Wed, 01 Aug 2007 00:50:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IG6AP-0002Ed-HE for sip@ietf.org; Wed, 01 Aug 2007 00:50:37 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IG6AP-0000Tr-1o for sip@ietf.org; Wed, 01 Aug 2007 00:50:37 -0400 Received: from 206-176-144-210.waymark.net ([206.176.144.210]) by nylon.softarmor.com with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1IG6AL-0001Xf-5A; Tue, 31 Jul 2007 23:50:33 -0500 Message-ID: <46B0125D.1060209@softarmor.com> Date: Tue, 31 Jul 2007 23:55:57 -0500 From: Dean Willis User-Agent: Icedove 1.5.0.12 (X11/20070607) MIME-Version: 1.0 To: Hadriel Kaplan Subject: Re: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 References: <1ECE0EB50388174790F9694F77522CCF11697776@zrc2hxm0.corp.nortel.com> <247B95AF-63F6-432D-9D6E-AF083AF9C525@nostrum.com> <46A92B7C.7080202@cisco.com> <1ECE0EB50388174790F9694F77522CCF116E20B5@zrc2hxm0.corp.nortel.com><20070727153727.A4BDD33C1A@delta.rtfm.com><46AA138D.6030001@cisco.com><46AA1FAA.3000204@cisco.com> <325E76F4-3A53-4101-BBDB-D2131FA4BB1D@ekabal.com> <030401c7d3b9$457a9360$800101df@acmepacket.com> In-Reply-To: <030401c7d3b9$457a9360$800101df@acmepacket.com> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: 'Rohan Mahy' , 'Michael Thomas' , 'IETF SIP List' , 'Francois Audet' , Jon.Peterson@neustar.com, 'Paul Kyzivat' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hadriel Kaplan wrote: > Yeah but a 480 implies the resource is not available, whereas in reality the > resource *is* available using a different scheme. I guess one question is > if the sips scheme literally means the UAS is a different "resource". If > so, then registering a sips contact only should not implicitly make the UAS > available for routing plain sip. The draft currently says they represent > the *same* resource. I tried to make this argument earlier (I think one should have separate registrations for sip and sips) but wasn't successful. Perhaps you've just made it more convincingly. > I'm not convinced by the downgrade argument. The far-end can just as easily > send a 3xx redirecting the UAC to the sip contact. Per this new draft the > proxies must not recurse on that, and the UAC should inform the user before > doing so. But I think a new 4xx response code would be much more likely to > make that a reality, as any vendor implementing support for recursing on a > 418 would have read the draft and seen where it says "inform the user". If > they didn't read the draft, they'd fail the request since they got an > unknown 4xx response. (compare that to a 3xx, which is known/usable without > reading this draft) Am I missing the gist of the concern? If they haven't read the draft, failing the request is the Right Thing to Do. What we are apparently attempting to do is make it where an unread implementer is likely to Do the Wrong Thing, namely downgrade to sip: and try again. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Aug 01 00:53:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IG6DJ-0005Z7-Qm; Wed, 01 Aug 2007 00:53:37 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IG6DH-0005Z1-KU for sip-confirm+ok@megatron.ietf.org; Wed, 01 Aug 2007 00:53:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IG6DH-0005Ys-Ay for sip@ietf.org; Wed, 01 Aug 2007 00:53:35 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IG6DG-0007Kp-33 for sip@ietf.org; Wed, 01 Aug 2007 00:53:35 -0400 Received: from 206-176-144-210.waymark.net ([206.176.144.210]) by nylon.softarmor.com with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1IG6DC-0001YJ-Qq; Tue, 31 Jul 2007 23:53:31 -0500 Message-ID: <46B0130F.70702@softarmor.com> Date: Tue, 31 Jul 2007 23:58:55 -0500 From: Dean Willis User-Agent: Icedove 1.5.0.12 (X11/20070607) MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 References: <1ECE0EB50388174790F9694F77522CCF11697776@zrc2hxm0.corp.nortel.com> <247B95AF-63F6-432D-9D6E-AF083AF9C525@nostrum.com> <46A92B7C.7080202@cisco.com> <1ECE0EB50388174790F9694F77522CCF116E20B5@zrc2hxm0.corp.nortel.com><20070727153727.A4BDD33C1A@delta.rtfm.com><46AA138D.6030001@cisco.com><46AA1FAA.3000204@cisco.com> <325E76F4-3A53-4101-BBDB-D2131FA4BB1D@ekabal.com> <030401c7d3b9$457a9360$800101df@acmepacket.com> <46B0125D.1060209@softarmor.com> In-Reply-To: <46B0125D.1060209@softarmor.com> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: 'Rohan Mahy' , 'Michael Thomas' , 'IETF SIP List' , 'Francois Audet' , Jon.Peterson@neustar.com, 'Paul Kyzivat' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dean Willis wrote: > What we are apparently attempting to do is make it where an unread > implementer is likely to Do the Wrong Thing, namely downgrade to sip: > and try again. Darn it! I mean "UNLIKELY to Do the Wrong Thing". I gotta stop reading email while running regression tests in another window. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Aug 01 01:20:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IG6cq-0006S9-F5; Wed, 01 Aug 2007 01:20:00 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IG6cp-0006Rz-CA for sip-confirm+ok@megatron.ietf.org; Wed, 01 Aug 2007 01:19:59 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IG6co-0006Rr-Dt for sip@ietf.org; Wed, 01 Aug 2007 01:19:58 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IG6cn-0000vg-Po for sip@ietf.org; Wed, 01 Aug 2007 01:19:58 -0400 Received: from hkaplan [72.254.167.248] by acmepacket.com with ESMTP (SMTPD-9.10) id A7FB03E8; Wed, 01 Aug 2007 01:19:55 -0400 From: "Hadriel Kaplan" To: "'Dean Willis'" References: <1ECE0EB50388174790F9694F77522CCF11697776@zrc2hxm0.corp.nortel.com> <247B95AF-63F6-432D-9D6E-AF083AF9C525@nostrum.com> <46A92B7C.7080202@cisco.com> <1ECE0EB50388174790F9694F77522CCF116E20B5@zrc2hxm0.corp.nortel.com><20070727153727.A4BDD33C1A@delta.rtfm.com><46AA138D.6030001@cisco.com><46AA1FAA.3000204@cisco.com> <325E76F4-3A53-4101-BBDB-D2131FA4BB1D@ekabal.com> <030401c7d3b9$457a9360$800101df@acmepacket.com> <46B0125D.1060209@softarmor.com> Subject: RE: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 Date: Wed, 1 Aug 2007 01:18:21 -0400 Message-ID: <034701c7d3fb$6146f240$800101df@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcfT939UZ6LQ7rKJQbG1qoMQLvz5YwAAurWw In-Reply-To: <46B0125D.1060209@softarmor.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: 'Rohan Mahy' , 'Michael Thomas' , 'IETF SIP List' , 'Francois Audet' , Jon.Peterson@neustar.com, 'Paul Kyzivat' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Wednesday, August 01, 2007 12:56 AM > > > I'm not convinced by the downgrade argument. The far-end can just as > easily > > send a 3xx redirecting the UAC to the sip contact. Per this new draft > the > > proxies must not recurse on that, and the UAC should inform the user > before > > doing so. But I think a new 4xx response code would be much more likely > to > > make that a reality, as any vendor implementing support for recursing on > a > > 418 would have read the draft and seen where it says "inform the user". > If > > they didn't read the draft, they'd fail the request since they got an > > unknown 4xx response. (compare that to a 3xx, which is known/usable > without > > reading this draft) Am I missing the gist of the concern? > > If they haven't read the draft, failing the request is the Right Thing > to Do. Yup, that was my point. -hadriel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Aug 01 01:24:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IG6gz-0000oe-4j; Wed, 01 Aug 2007 01:24:17 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IG6gw-0000oZ-Q0 for sip-confirm+ok@megatron.ietf.org; Wed, 01 Aug 2007 01:24:14 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IG6gw-0000oR-9n for sip@ietf.org; Wed, 01 Aug 2007 01:24:14 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IG6gv-0000yq-If for sip@ietf.org; Wed, 01 Aug 2007 01:24:14 -0400 Received: from hkaplan [72.254.167.248] by acmepacket.com with ESMTP (SMTPD-9.10) id A8FC0708; Wed, 01 Aug 2007 01:24:12 -0400 From: "Hadriel Kaplan" To: "'Francois Audet'" References: <1ECE0EB50388174790F9694F77522CCF11697776@zrc2hxm0.corp.nortel.com> <247B95AF-63F6-432D-9D6E-AF083AF9C525@nostrum.com> <46A92B7C.7080202@cisco.com> <1ECE0EB50388174790F9694F77522CCF116E20B5@zrc2hxm0.corp.nortel.com><20070727153727.A4BDD33C1A@delta.rtfm.com><46AA138D.6030001@cisco.com><46AA1FAA.3000204@cisco.com> <325E76F4-3A53-4101-BBDB-D2131FA4BB1D@ekabal.com> <030401c7d3b9$457a9360$800101df@acmepacket.com> <1ECE0EB50388174790F9694F77522CCF1179493C@zrc2hxm0.corp.nortel.com> Subject: RE: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 Date: Wed, 1 Aug 2007 01:22:37 -0400 Message-ID: <034801c7d3fb$fa0aeae0$800101df@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcfTjJOvyvyREiMrQ9+74ysSMh8lpQAKWj6AAAF/ZaAAD+A8kA== In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1179493C@zrc2hxm0.corp.nortel.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: 'IETF SIP List' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Ahh - no what I missed was that you were giving a specific warning code for the 480 such that a machine can automatically warn the user and retry, disambiguating it from a generic 480. That's cool for me. I thought the options were either an ambiguous 480 or explicit 418, but it's now an explicit 480. Sounds good. -hadriel > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: Tuesday, July 31, 2007 5:51 PM > To: Hadriel Kaplan > Cc: IETF SIP List > Subject: RE: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 > > 480 means that the user identified by the Request-URI is recognized, but > there is currently no valid forwarding location for that user. In this > case, > no SIPS contacts. > > What many people are missing in the 480 vs. 418 argument is the > following: > > - Existing implementations will treat new 4XX error codes as 400, > which basically means "the protocol message is broken". > > - Existing implements will treat 480 with new Warning just like > 480 witn no warning, i.e., as "Temporarily unavailable". > > There is a huge difference between the 2. 400 will lead you to believe > that there is something wrong with the equipment (i.e., you may file a > complaint with the manufacturer). Very bad. > > 480 just means the other end is not available at that address. Good. > Everybody is happy. > > > -----Original Message----- > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > Sent: Tuesday, July 31, 2007 14:25 > > To: 'Rohan Mahy'; 'Michael Thomas' > > Cc: 'IETF SIP List'; Audet, Francois (SC100:3055); > > Jon.Peterson@neustar.com; 'Paul Kyzivat' > > Subject: RE: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 > > > > Yeah but a 480 implies the resource is not available, whereas > > in reality the resource *is* available using a different > > scheme. I guess one question is if the sips scheme literally > > means the UAS is a different "resource". If so, then > > registering a sips contact only should not implicitly make > > the UAS available for routing plain sip. The draft currently > > says they represent the *same* resource. > > > > I'm not convinced by the downgrade argument. The far-end can > > just as easily send a 3xx redirecting the UAC to the sip > > contact. Per this new draft the proxies must not recurse on > > that, and the UAC should inform the user before doing so. > > But I think a new 4xx response code would be much more likely > > to make that a reality, as any vendor implementing support > > for recursing on a > > 418 would have read the draft and seen where it says "inform > > the user". If they didn't read the draft, they'd fail the > > request since they got an unknown 4xx response. (compare that > > to a 3xx, which is known/usable without reading this draft) > > Am I missing the gist of the concern? > > > > -hadriel > > > > > > > -----Original Message----- > > > From: Rohan Mahy [mailto:rohan@ekabal.com] > > > Sent: Tuesday, July 31, 2007 12:04 PM > > > To: Michael Thomas > > > Cc: Rohan Mahy; IETF SIP List; Francois Audet; > > > Jon.Peterson@neustar.com; Paul Kyzivat > > > Subject: Re: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 > > > > > > Michael, > > > > > > The semantics of a request to a sip: resource are different from a > > > request to a sips: resource. If there are no Contacts registered > > > against a sips: resource, then the correct thing for the > > proxy to do > > > is to send a 480. This is the same thing the proxy would > > do if there > > > were no Contacts registered against a sip: resource. > > > > > > We are not talking about a ciphersuite downgrade here. Providing an > > > error response code that encourages a client to downgrade is just > > > plain irresponsible. > > > > > > thanks, > > > -rohan > > > > > > > > > On Jul 27, 2007, at 9:39 AM, Michael Thomas wrote: > > > > Rohan Mahy wrote: > > > >> Michael, > > > >> > > > >> At issue here is what the default implementor is likely to do. > > > >> With a new 4xx, the misguided but well-meaning implementor is > > > >> likely to try to "helpfully" "repair" the error without thinking > > > >> about or understanding the security context. > > > >> > > > >> Using a Warning code raises the bar significantly, but > > still allows > > > >> automata to at least log what happened. > > > > As I said, a receiver is completely at liberty to prevent the > > > > downgrade by not accepting the downgraded request. > > Problem solved > > > > by those who care. On the other hand I think it's pretty > > > > presumptuous that we "know" in all cases whether it's wrong to > > > > "repair" the error. Paul brought up several examples. > > > > Also: if the receiver allows non-SIPS requests why shouldn't you > > > > infer that they want you to "repair" the request? It sure > > seems like > > > > this is a misguided attempt at forcing ineffectual > > nannyware which > > > > is a pointless enterprise for IETF protocols. > > > > > > > > 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 > > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Aug 01 04:44:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IG9oB-0000DB-O1; Wed, 01 Aug 2007 04:43:55 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IG9o9-0000CK-Nd for sip-confirm+ok@megatron.ietf.org; Wed, 01 Aug 2007 04:43:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IG9o8-0000C7-Ub for sip@ietf.org; Wed, 01 Aug 2007 04:43:52 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IG9o8-00071n-33 for sip@ietf.org; Wed, 01 Aug 2007 04:43:52 -0400 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JM3000676WMFZ@siemenscomms.co.uk> for sip@ietf.org; Wed, 01 Aug 2007 09:43:34 +0100 (BST) Date: Wed, 01 Aug 2007 09:43:46 +0100 From: "Elwell, John" To: Cullen Jennings , Mahy Rohan , sip@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D020638F@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: WGLC comments on sip-outbound-10 Thread-Index: AcfUGBL7ygcRQo2NTvWF+yqVEhvz8g== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: Subject: [Sip] WGLC comments on sip-outbound-10 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org 1. "The UA can also include a reg-id parameter which is used to allow the registrar to detect and avoid keeping invalid contacts when a UA reboots or reconnects after its old connection has failed for some reason." Surely if outbound behaviour is required it is necessary to include reg-id. So it should say "The UA also includes...." 2. "When the proxy goes to forward a request to a given target, it looks and finds the flows over which it received the registration." In the case being described here in 3.2 there is only a single flow. Add ", in this case, only a single flow". 3. "The proxy then forwards the request on that flow, instead of resolving the Contact URI using the procedures in RFC 3263 [4] and trying to form a new flow to that contact. This allows the proxy to forward a request to a particular contact over the same flow that the UA used to register this AOR." This seems a bit circular. It effectively says that by forwarding on the existing flow it enables the proxy to forward on the existing flow! I think the second of these two sentences can be deleted. 4. "To convey its instance-id in both requests and responses, the UA includes a "sip.instance" media feature tag as a UA characteristic [7] ." The sending of instance-id in responses does not seem to be specified anywhere, so perhaps this sentence should only refer to requests. On the other hand, perhaps the intention is to send an instance-id in a contact in a response, as described for requests in 4.3. If so, a section on sending responses is required. 5. "These ordinary registration requests include a distinct reg-id parameter in the Contact header field." There is no RFC2119 language here. Shouldn't it say something like: "If outbound behavior is required, registration requests MUST include..." 6. "4.3. Sending Requests" I am not sure whether this section is intended to cover all requests (including REGISTER requests) or requests other than REGISTER. If the latter, the title should be "Sending Requests other than REGISTER". 7. "The contact is formed normally in that the UAC uses the IP address of the device (even if the device is behind a NAT)." This does not allow for the use of a GRUU in non-REGISTER requests. 8. "Note that the requirements in this section applies to both REGISTER requests received from an Edge Proxy as well as requests received directly from the UAC." I think this note is intended to refer only to the current paragraph, not the entire section. 9. "then the proxy MUST send the request over the same 'logical flow' saved with the binding that is known to deliver data to the specific target UA instance." It is the logical flow that is know to deliver data to the UA, not the binding. I think it should say: "then the proxy MUST send the request over the same 'logical flow' saved with the binding, since that flow is known to deliver data to the specific target UA instance." 10. "8. STUN Keepalive Processing" This section contains a mixture of requirements on a UA and requirements on a server. It would be good practice to separate these. 11. "Note that UACs MUST NOT use an ambiguous configuration option such as "Work through NATs?" or "Do Keepalives?" to imply next hop STUN support." I am not sure about RFC2119 language here. First, it does not express a protocol requirement. Second, the whole statement is a note. Third, the requirement is vague and hard to test. I would have thought it sufficient to say "should not". If RFC2119 language is really considered necessary, it should not be stronger than "SHOULD NOT" because of the vagueness of the requirement. 12. "Later, after the Primary reboots, The Callee discovers the flow failure and reestablishes a new flow to the Primary." Alternatively the proxy might discover the flow failure before the Primary reboots, although it cannot of course successfully re-establish the flow until after reboot. Perhaps it should say: "Later, after the Primary reboots, the Callee successfully reestablishes a new flow to the Primary. Keepalive checks and any failed attempts to re-establish the flow are not shown." 13. "The value of the reg-id MUST NOT be 0 and MUST be less than 2**31." According to the ABNF, the value can be less than or equal to 2**31. NITS - Change "the Registrar MUST NOR" to "the Registrar MUST NOT". - Change "Note that the requirements in this section applies" to "Note that the requirements in this section apply" John _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Aug 01 07:25:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGCKO-000476-Uo; Wed, 01 Aug 2007 07:25:20 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IGCKN-00045E-7d for sip-confirm+ok@megatron.ietf.org; Wed, 01 Aug 2007 07:25:19 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGCKM-000456-Rc for sip@ietf.org; Wed, 01 Aug 2007 07:25:18 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGCKM-00034u-45 for sip@ietf.org; Wed, 01 Aug 2007 07:25:18 -0400 Received: from sjc12-sbr-sw3-3f5.cisco.com (HELO imail.cisco.com) ([172.19.96.182]) by sj-iport-2.cisco.com with ESMTP; 01 Aug 2007 04:25:18 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAOgKsEasE2C2/2dsb2JhbAAN X-IronPort-AV: i="4.19,208,1183359600"; d="scan'208"; a="389529439:sNHT30680806" Received: from [64.142.29.214] ([10.21.71.186]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id l71A5DnP030627; Wed, 1 Aug 2007 03:05:13 -0700 Message-ID: <46B06DA2.2090904@cisco.com> Date: Wed, 01 Aug 2007 04:25:22 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.12) Gecko/20070509 Thunderbird/1.5.0.12 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Rohan Mahy Subject: Re: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 References: <1ECE0EB50388174790F9694F77522CCF11697776@zrc2hxm0.corp.nortel.com> <247B95AF-63F6-432D-9D6E-AF083AF9C525@nostrum.com> <46A92B7C.7080202@cisco.com> <1ECE0EB50388174790F9694F77522CCF116E20B5@zrc2hxm0.corp.nortel.com><20070727153727.A4BDD33C1A@delta.rtfm.com><46AA138D.6030001@cisco.com><46AA1FAA.3000204@cisco.com> <325E76F4-3A53-4101-BBDB-D2131FA4BB1D@ekabal.com> <030401c7d3b9$457a9360$800101df@acmepacket.com> <3B61AA00-CC03-4607-9606-CA5B8C2EC5CB@ekabal.com> In-Reply-To: <3B61AA00-CC03-4607-9606-CA5B8C2EC5CB@ekabal.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4426; t=1185962714; x=1186826714; c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mat@cisco.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[Sip]=20draft-ietf-sip-sips-05=3A=20480=20vs.=20418 |Sender:=20 |To:=20Rohan=20Mahy=20; bh=2HvNAlbwQGq/1nee1DytmUUmbGgEW5Ptlcpe+LLu5GM=; b=B4ZDx1xgjLsW+EKKbsqIE7el8ALYOleMAECH9choXbKeq8In/Czdjt5vs7jjn6nDXF8uHoIT 7tm3OXNofe82/vd5rmpJjiLTPGZ97sX/xTv1DB04fu1Flpd5Sn9y3ek0; Authentication-Results: imail.cisco.com; header.From=mat@cisco.com; dkim=pass ( sig from cisco.com/oregon verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: 'IETF SIP List' , 'Francois Audet' , 'Paul Kyzivat' , Jon.Peterson@neustar.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Rohan Mahy wrote: > The resource that was requested (sips:foo@example.com) is NOT > available. There may be a related but different resource available, > so it is nice as a courtesy to provide this information, but the basic > semantics should still be a 480. The proposal out which had the two different warning codes alleviates my concern which is that the implementor who doesn't much care about IETF nanny proclamations has incentive to pay attention to them so that it doesn't make _useless_ re-requests for SIP:. Question: as currently defined can these two new warnings be reused by any future method that is hopefully more secure than SIPS so that we don't have to rehash this argument again? Mike > > thanks, > -rohan > > > On Jul 31, 2007, at 2:25 PM, Hadriel Kaplan wrote: > >> Yeah but a 480 implies the resource is not available, whereas in >> reality the >> resource *is* available using a different scheme. I guess one >> question is >> if the sips scheme literally means the UAS is a different >> "resource". If >> so, then registering a sips contact only should not implicitly make >> the UAS >> available for routing plain sip. The draft currently says they >> represent >> the *same* resource. >> >> I'm not convinced by the downgrade argument. The far-end can just as >> easily >> send a 3xx redirecting the UAC to the sip contact. Per this new >> draft the >> proxies must not recurse on that, and the UAC should inform the user >> before >> doing so. But I think a new 4xx response code would be much more >> likely to >> make that a reality, as any vendor implementing support for recursing >> on a >> 418 would have read the draft and seen where it says "inform the >> user". If >> they didn't read the draft, they'd fail the request since they got an >> unknown 4xx response. (compare that to a 3xx, which is known/usable >> without >> reading this draft) Am I missing the gist of the concern? >> >> -hadriel >> >> >>> -----Original Message----- >>> From: Rohan Mahy [mailto:rohan@ekabal.com] >>> Sent: Tuesday, July 31, 2007 12:04 PM >>> To: Michael Thomas >>> Cc: Rohan Mahy; IETF SIP List; Francois Audet; >>> Jon.Peterson@neustar.com; >>> Paul Kyzivat >>> Subject: Re: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 >>> >>> Michael, >>> >>> The semantics of a request to a sip: resource are different from a >>> request to a sips: resource. If there are no Contacts registered >>> against a sips: resource, then the correct thing for the proxy to do >>> is to send a 480. This is the same thing the proxy would do if there >>> were no Contacts registered against a sip: resource. >>> >>> We are not talking about a ciphersuite downgrade here. Providing an >>> error response code that encourages a client to downgrade is just >>> plain irresponsible. >>> >>> thanks, >>> -rohan >>> >>> >>> On Jul 27, 2007, at 9:39 AM, Michael Thomas wrote: >>>> Rohan Mahy wrote: >>>>> Michael, >>>>> >>>>> At issue here is what the default implementor is likely to do. >>>>> With a new 4xx, the misguided but well-meaning implementor is >>>>> likely to try to "helpfully" "repair" the error without thinking >>>>> about or understanding the security context. >>>>> >>>>> Using a Warning code raises the bar significantly, but still >>>>> allows automata to at least log what happened. >>>> As I said, a receiver is completely at liberty to prevent the >>>> downgrade by not >>>> accepting the downgraded request. Problem solved by those who >>>> care. On >>>> the other hand I think it's pretty presumptuous that we "know" in >>>> all cases >>>> whether it's wrong to "repair" the error. Paul brought up several >>>> examples. >>>> Also: if the receiver allows non-SIPS requests why shouldn't you >>>> infer that >>>> they want you to "repair" the request? It sure seems like this is a >>>> misguided >>>> attempt at forcing ineffectual nannyware which is a pointless >>>> enterprise for >>>> IETF protocols. >>>> >>>> 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Aug 01 10:15:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGEyW-000130-DX; Wed, 01 Aug 2007 10:14:56 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IGEyT-00011i-KN for sip-confirm+ok@megatron.ietf.org; Wed, 01 Aug 2007 10:14:53 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGEyS-000119-1R; Wed, 01 Aug 2007 10:14:52 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGEyR-0000Dx-Dv; Wed, 01 Aug 2007 10:14:51 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id AEF6320422; Wed, 1 Aug 2007 16:14:50 +0200 (CEST) X-AuditID: c1b4fb3c-b067fbb0000007e1-98-46b0955a7593 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 944EC20011; Wed, 1 Aug 2007 16:14:50 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Aug 2007 16:14:50 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Aug 2007 16:14:50 +0200 Message-ID: <46B0955A.3040900@ericsson.com> Date: Wed, 01 Aug 2007 16:14:50 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: Janet P Gunn References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Aug 2007 14:14:50.0324 (UTC) FILETIME=[52AD5940:01C7D446] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: sip@ietf.org, IETF SIPPING WG , tsvwg , NSIS Subject: [Sip] Re: [Tsvwg] Draft Liaision response to SG13 on Emergency Telecommunications X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Janet P Gunn skrev: > > Magnus, > > You might want to add- > > draft-polk-tsvwg-signaled-domain-id-00.txt Well, I want to be somewhat restricted in adding individual work into the liaison. Also to me it is not clear how this is applicable in the emergency context. > and > draft-polk-ecrit-local-emergency-rph-namespace-01.txt > Well, I got another comment about ECRIT WG document which we hadn't considered. I will contact the WG chairs and see what they say. > > And maybe > draft-carlberg-trip-attribute-rp-02 Well, this is in IETF last call currently. So I will put it on my list of documents to consider and try to learn more about it. > > My spelling checker says "Liaision" should be "Liaison", but it may be a > US centric dictionary. No, it is Liaison, but I think that error only is in the subject of this email. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Aug 01 10:35:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGFI0-0005i7-Pg; Wed, 01 Aug 2007 10:35:04 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IGFHz-0005hz-Uv for sip-confirm+ok@megatron.ietf.org; Wed, 01 Aug 2007 10:35:03 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGFHz-0005hm-IY for sip@ietf.org; Wed, 01 Aug 2007 10:35:03 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGFHy-0000w7-6K for sip@ietf.org; Wed, 01 Aug 2007 10:35:03 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l71EYGGY009876; Wed, 1 Aug 2007 17:34:52 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Aug 2007 17:34:28 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Aug 2007 17:34:28 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: [Sip] WGLC comments on sip-outbound-10: behaviour of the registrar Date: Wed, 1 Aug 2007 17:34:27 +0300 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F03EC9853@esebe103.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] WGLC comments on sip-outbound-10: behaviour of the registrar Thread-Index: AcfUSRBhM+QAwevFQba6eLzLLwXhMA== From: To: , , X-OriginalArrivalTime: 01 Aug 2007 14:34:28.0455 (UTC) FILETIME=[10E5DF70:01C7D449] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 65bc4909d78e8b10349def623cf7a1d1 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, Here are my comments regarding to the behaviour of the registrar as specified within SIP Outbound-10.=20 As a summary, it seems to me that section 6 would need substantial changes to become clearer. I am sorry to not find and point all that=20 out until WGLC. To compensate I tried to rework section 6 and you=20 can find the result in the end of this email. Please use for version 11, if you find it useful. 3.1. Summary of Mechanism Nit: "The registrar can use the reg-id label to recognize that a UA is registering after a reboot or a network failure." In practice the registrar can not detect from the reg-id=20 if the UA is just refreshing an existing registration or=20 registering after a reboot or other failure. Thus my suggestion=20 is to replace that sentence with this one: "The registrar can=20 use the reg-id label to recognize whether an UA is creating a=20 new flow or refreshing an existing flow, possibly after a reboot=20 or a network failure." 6. Registrar Mechanisms Nit: "When no +sip.instance media feature parameter is present in a Contact header field value in a REGISTER request, the corresponding binding is still between an AOR and the URI from that Contact header field value." I believe this statement should be dropped from the spec as it does not tell anything new compared to RFC 3261. But if the idea is rather to tell what the registrar should do if the Contact contains reg-id but does not contain the +sip.instance, then the statement has to be clarified to point that out. In my opinion the statement is not needed even for this latter case as the section 6 covers that case later. =20 Nit: "When a +sip.instance media feature parameter is present in a Contact header field value in a REGISTER request, the corresponding binding is between an AOR and the combination of the instance-id (from the +sip.instance media feature parameter) and the value of reg-id parameter if it is present." As GRUU specifies what the registrar should do when the Contact header contains +sip.instance without reg-id, this statement should more clearly focus to the case when Contact has both of them. I suggest rewrite like this: "When both +sip.instance media feature parameter and reg-id parameter are present in a Contact header field of=20 a REGISTER request, the corresponding binding is between an AOR and=20 the combination of the instance-id (from the +sip.instance media=20 feature parameter) and the value of reg-id parameter." With the=20 current formulation the statement is a bit open-ended and leaves the reader to wonder what might happen if reg-id parameter is not present (which is the case in GRUU). Nit: "A Contact header field value with an instance-id but no reg-id is valid" An informative reference to GRUU would be helpful here. Minor technical: "For a binding with an instance-id, the registrar still stores the Contact header field value URI with the binding, but does not consider the Contact URI for comparison purposes." Why does the registrar has to store the URI ? To which purpose it will be used ? If there is no explicit purpose for storing the URI=20 I suggest dropping that statement and reformulating this one: "The=20 registrar MUST also store all the Contact header field information"=20 just to require storage all the Contact header parameters, not URI. Major technical: "Specifically, if it ignores the 'reg-id' parameter the registrar MUST use RFC 3261 Contact binding rules" What happens if the UA is requesting both Outbound and GRUU behavior in its REGISTER request, but the edge proxy does not support Outbound ? The statement above in the Outbound seems to suggest that the registrar will not deliver even the GRUUs (and store the instance-Id with AOR as specified for GRUU), which however does not sound correct to me. Instead the UA should get its GRUUs and the registrar should use binding rules specified in GRUU spec. Nit: "If a Path header field is present, RFC 3327 [5] requires the registrar to store this information as well." Why to repeat this in Outbound ? I suggest dropping it and only leaving the statement given earlier in the same section: "Registrars which=20 implement this specification MUST support the Path header mechanism [5]."=20 Major technical: "and MUST NOT include the 'outbound' option-tag in its Supported header=20 field." "The Registrar MUST include the 'outbound' option-tag (defined in Section (Section 12.1)) in a Supported header field value in its responses to REGISTER requests for which it has performed outbound processing" It was stated already earlier the registrar must add the tag into the Require header (and may also add it into Supported header). Nit: "and MUST NOT include this option-tag if it did not perform outbound processing. Furthermore, the Registrar MUST NOR include this option-tag in its response if the Registrar skipped outbound processing by ignoring the reg-id parameter as described in this specification." The text above unnecessarily says the same thing twice. Statement starting with word "Furthermore" is redundant and should be deleted. Nit: "The registrar MUST also store all the Contact header field information including the reg-id and instance-id parameters and SHOULD also store the time at which the binding was last updated." It is not logical to have this statement in the middle of the text=20 which discusses what the registrar should do if it has a direct flow with the UA.=20 =3D=3D=3D=3D=3D=3D=3D=3D Here is the reworked text for section 6. It is at least shorter=20 than the original version without any loss of functionality. I also=20 believe that the structure has become much clearer during the rewrite=20 and consists now of the following steps: =09 a) Validation of Contact header (with help of Via and Path) and decision whether to use Outbound or not b) Creating bindings for Contacts with reg-id and instance-id and responding to the UA c) Maintenance of flows and registration refreshes d) Support for keepalives 6. Registrar Mechanisms: Processing REGISTER Requests This specification updates the definition of a binding in RFC 3261 [1] Section 10 and RFC 3327 [5] Section 5.3. Registrars which implement this specification MUST support the Path header mechanism [5]. When receiving a REGISTER request, the registrar first checks from its Via header field if the registrar is the first hop or not. If the registrar is not the first hop, it examines Path header of the request. If the Path header field is missing or it exists but the=20 first URI does not have an 'ob' URI parameter, the registrar MUST=20 ignore the reg-id parameter of the Contact header. A Contact header field value with an instance-id but no reg-id is=20 valid (as specified in GRUU [25]), but one with a reg-id but no=20 instance-id is not. If the registrar processes a Contact header=20 field value with a reg-id but no instance-id, it simply ignores=20 the reg-id parameter. If the Contact header did not contain 'reg-id' parameter or if that parameter became ignored (as described above) the registrar MUST NOT apply any outbound processing for the request. Specifically, registrar MUST NOT include the 'outbound' option-tag in the Require header field=20 of its response and it MUST use Contact binding rules of GRUU [25] or RFC 3261 [1], depending whether or not the Contact header contains +sip.instance media feature parameter.=20 The registrar MUST be prepared to receive, simultaneously for the=20 same AOR, some registrations that use instance-id and reg-id and=20 some registrations that do not. The Registrar MAY be configured=20 with local policy to reject any registrations that do not include=20 the instance-id and reg-id, or with Path header field values that=20 do not contain the 'ob' parameter. When both +sip.instance media feature parameter and reg-id parameter=20 are present in a Contact header field of a REGISTER request (after the Contact header validation as described above), the corresponding=20 binding is between an AOR and the combination of the instance-id=20 (from the +sip.instance media feature parameter) and the value of=20 reg-id parameter. The registrar MUST store all the Contact parameters in the binding and SHOULD also store the time at which the binding=20 was last updated. Further on the Registrar MUST include the 'outbound'=20 option-tag (defined in Section (Section 12.1)) into a Require header=20 field value in its response to the REGISTER request.=20 If the UAC has a direct flow with the registrar, the registrar MUST store enough information to uniquely identify the network flow over which the request arrived. For common operating systems with TCP, this would typically just be the handle to the file descriptor where the handle would become invalid if the TCP session was closed. For common operating systems with UDP this would typically be the file descriptor for the local socket that received the request, the local interface, and the IP address and port number of the remote side that sent the request. The registrar MAY store this information by adding itself to the Path header field with an appropriate flow token. If the registrar receives a re-registration for a specific combination of AOR, instance-id and reg-id values, the registrar MUST update any=20 information that uniquely identifies the network flow over which=20 the request arrived if that information has changed, and SHOULD=20 update the time the binding was last updated. To be compliant with this specification, registrars which can receive SIP requests directly from a UAC without intervening edge proxies MUST implement STUN NAT Keepalives on its SIP UDP ports as described in Section 8 and when it receives a double-CRLF sequence on a connection oriented transport such as TCP or SCTP, it MUST immediately respond with a single CRLF over the same connection. Regards, Erkki _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Aug 01 11:44:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGGMg-0008Il-Ml; Wed, 01 Aug 2007 11:43:58 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IGGMe-0008Ig-I9 for sip-confirm+ok@megatron.ietf.org; Wed, 01 Aug 2007 11:43:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGGMe-0008IY-7h for sip@ietf.org; Wed, 01 Aug 2007 11:43:56 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGGMd-0002ef-Ua for sip@ietf.org; Wed, 01 Aug 2007 11:43:56 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l71Fhqs06584; Wed, 1 Aug 2007 15:43:53 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 Date: Wed, 1 Aug 2007 10:43:38 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF11794FFA@zrc2hxm0.corp.nortel.com> In-reply-to: <034801c7d3fb$fa0aeae0$800101df@acmepacket.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 Thread-Index: AcfTjJOvyvyREiMrQ9+74ysSMh8lpQAKWj6AAAF/ZaAAD+A8kAAVziKw References: <1ECE0EB50388174790F9694F77522CCF11697776@zrc2hxm0.corp.nortel.com> <247B95AF-63F6-432D-9D6E-AF083AF9C525@nostrum.com> <46A92B7C.7080202@cisco.com> <1ECE0EB50388174790F9694F77522CCF116E20B5@zrc2hxm0.corp.nortel.com><20070727153727.A4BDD33C1A@delta.rtfm.com><46AA138D.6030001@cisco.com><46AA1FAA.3000204@cisco.com> <325E76F4-3A53-4101-BBDB-D2131FA4BB1D@ekabal.com> <030401c7d3b9$457a9360$800101df@acmepacket.com> <1ECE0EB50388174790F9694F77522CCF1179493C@zrc2hxm0.corp.nortel.com> <034801c7d3fb$fa0aeae0$800101df@acmepacket.com> From: "Francois Audet" To: "Hadriel Kaplan" X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Ok, cool.=20 > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 > Sent: Tuesday, July 31, 2007 22:23 > To: Audet, Francois (SC100:3055) > Cc: 'IETF SIP List' > Subject: RE: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 >=20 > Ahh - no what I missed was that you were giving a specific=20 > warning code for the 480 such that a machine can=20 > automatically warn the user and retry, disambiguating it from=20 > a generic 480. That's cool for me. I thought the options=20 > were either an ambiguous 480 or explicit 418, but it's now an=20 > explicit 480. Sounds good. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Aug 01 11:56:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGGYV-0007NI-Kv; Wed, 01 Aug 2007 11:56:11 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IGGYU-0007Ms-3A for sip-confirm+ok@megatron.ietf.org; Wed, 01 Aug 2007 11:56:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGGYT-0007Mj-Pg for sip@ietf.org; Wed, 01 Aug 2007 11:56:09 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGGYS-00029q-8b for sip@ietf.org; Wed, 01 Aug 2007 11:56:09 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l71Fu4924495; Wed, 1 Aug 2007 15:56:04 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 Date: Wed, 1 Aug 2007 10:55:48 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF11795034@zrc2hxm0.corp.nortel.com> In-reply-to: <46B06DA2.2090904@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 Thread-Index: AcfULqjYr9/fOicOQYakFJ9W326jDAAJGrVg References: <1ECE0EB50388174790F9694F77522CCF11697776@zrc2hxm0.corp.nortel.com> <247B95AF-63F6-432D-9D6E-AF083AF9C525@nostrum.com> <46A92B7C.7080202@cisco.com> <1ECE0EB50388174790F9694F77522CCF116E20B5@zrc2hxm0.corp.nortel.com><20070727153727.A4BDD33C1A@delta.rtfm.com><46AA138D.6030001@cisco.com><46AA1FAA.3000204@cisco.com> <325E76F4-3A53-4101-BBDB-D2131FA4BB1D@ekabal.com> <030401c7d3b9$457a9360$800101df@acmepacket.com> <3B61AA00-CC03-4607-9606-CA5B8C2EC5CB@ekabal.com> <46B06DA2.2090904@cisco.com> From: "Francois Audet" To: "Michael Thomas" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com]=20 > Sent: Wednesday, August 01, 2007 04:25 > To: Rohan Mahy > Cc: Hadriel Kaplan; 'IETF SIP List'; Audet, Francois=20 > (SC100:3055); Jon.Peterson@neustar.com; 'Paul Kyzivat' > Subject: Re: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 >=20 > Question: as currently defined can these two new warnings be=20 > reused by any future method that is hopefully more secure=20 > than SIPS so that we don't have to rehash this argument again? The draft uses the Warn-codes in 480. But it could be used by other response (e.g., 424 for location conveyance, if we decide it makes sense). Or any other response. I'm assuming you mean "other URI schemes" instead of "other methods". I currently have it as follows: 380 SIPS Not Allowed 381 SIPS Required So, obviously, they are tied to SIPS.=20 If we defined another URI scheme (e.g., sipsec or whatever), then it would probably need new Warning Codes. The alternative, which I presented in Chicago, based on Attila's proposal (i.e., defining a new header that specifically list the Allowed or Required=20 URI schemes) was NOT viewed favorably by the group. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Aug 01 12:18:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGGuK-00021K-RY; Wed, 01 Aug 2007 12:18:44 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IGGuJ-00020Z-0H for sip-confirm+ok@megatron.ietf.org; Wed, 01 Aug 2007 12:18:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGGuH-00020E-R9; Wed, 01 Aug 2007 12:18:41 -0400 Received: from mail130.messagelabs.com ([216.82.250.163]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IGGuH-0003c1-7H; Wed, 01 Aug 2007 12:18:41 -0400 X-VirusChecked: Checked X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-6.tower-130.messagelabs.com!1185985118!10207402!1 X-StarScan-Version: 5.5.12.11; banners=-,-,- X-Originating-IP: [20.137.52.151] Received: (qmail 17586 invoked from network); 1 Aug 2007 16:18:39 -0000 Received: from amer-mta07.csc.com (HELO amer-mta07.csc.com) (20.137.52.151) by server-6.tower-130.messagelabs.com with AES256-SHA encrypted SMTP; 1 Aug 2007 16:18:39 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta07.csc.com (Switch-3.1.6/Switch-3.1.7) with ESMTP id l71GIqaX015895; Wed, 1 Aug 2007 12:18:54 -0400 (EDT) In-Reply-To: <46B0955A.3040900@ericsson.com> To: Magnus Westerlund MIME-Version: 1.0 X-Mailer: Lotus Notes 652HF83 November 04, 2004 From: Janet P Gunn Message-ID: Date: Wed, 1 Aug 2007 12:18:34 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 7.0.2FP1 HF180|March 29, 2007) at 08/01/2007 12:17:15 PM, Serialize complete at 08/01/2007 12:17:15 PM X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: sip@ietf.org, IETF SIPPING WG , tsvwg , NSIS Subject: [Sip] Re: [Tsvwg] Draft Liaision response to SG13 on Emergency Telecommunications X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1378372366==" Errors-To: sip-bounces@ietf.org This is a multipart message in MIME format. --===============1378372366== Content-Type: multipart/alternative; boundary="=_alternative 0059975B8525732A_=" This is a multipart message in MIME format. --=_alternative 0059975B8525732A_= Content-Type: text/plain; charset="US-ASCII" Magnus Westerlund wrote on 08/01/2007 10:14:50 AM: > Janet P Gunn skrev: > > > > Magnus, > > > > You might want to add- > > > > draft-polk-tsvwg-signaled-domain-id-00.txt > > Well, I want to be somewhat restricted in adding individual work into > the liaison. Also to me it is not clear how this is applicable in the > emergency context. Well, you included draft-polk-sip-rph-new-namespaces-01, and draft-polk-tsvwg-signaled-domain-id-00 addresses the same scenarios. It would make sense to include either both or neither. > > > and > > draft-polk-ecrit-local-emergency-rph-namespace-01.txt > > > > Well, I got another comment about ECRIT WG document which we hadn't > considered. I will contact the WG chairs and see what they say. Yes, ecrit should make the call. But I know at least one other stds body ( PacketCable PKT2 0-SP-RSTF-D01-060330 TCHG) is addressing it. Janet > > Cheers > > Magnus Westerlund > > IETF Transport Area Director & TSVWG Chair > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM/M > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- --=_alternative 0059975B8525732A_= Content-Type: text/html; charset="US-ASCII"



Magnus Westerlund <magnus.westerlund@ericsson.com> wrote on 08/01/2007 10:14:50 AM:

> Janet P Gunn skrev:
> >
> > Magnus,
> >
> > You might want to add-
> >
> > draft-polk-tsvwg-signaled-domain-id-00.txt
>
> Well, I want to be somewhat restricted in adding individual work into
> the liaison. Also to me it is not clear how this is applicable in the
> emergency context.

Well, you included draft-polk-sip-rph-new-namespaces-01, and draft-polk-tsvwg-signaled-domain-id-00 addresses the same scenarios.  It would make sense to include either both or neither.
>
> > and
> > draft-polk-ecrit-local-emergency-rph-namespace-01.txt
> >
>
> Well, I got another comment about ECRIT WG document which we hadn't
> considered. I will contact the WG chairs and see what they say.

Yes, ecrit should make the call. But I know at least one other stds body (PacketCable PKT2 0-SP-RSTF-D01-060330 TCHG) is addressing it.

Janet

>
> Cheers
>
> Magnus Westerlund
>
> IETF Transport Area Director & TSVWG Chair
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM/M
> ----------------------------------------------------------------------
> Ericsson AB                | Phone +46 8 4048287
> Torshamsgatan 23           | Fax   +46 8 7575550
> S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
 --=_alternative 0059975B8525732A_=-- --===============1378372366== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1378372366==-- From sip-bounces@ietf.org Wed Aug 01 13:12:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGHkM-0003rX-Eq; Wed, 01 Aug 2007 13:12:30 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IGHkK-0003qO-G5 for sip-confirm+ok@megatron.ietf.org; Wed, 01 Aug 2007 13:12:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGHkK-0003qG-5l for sip@ietf.org; Wed, 01 Aug 2007 13:12:28 -0400 Received: from [203.187.132.25] (helo=tapal.aricent.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGHkJ-0005FU-8s for sip@ietf.org; Wed, 01 Aug 2007 13:12:28 -0400 Received: from tapal.aricent.com (localhost [127.0.0.1]) by tapal.aricent.com (8.13.8/8.13.8) with ESMTP id l71H75BK000689 for ; Wed, 1 Aug 2007 22:37:06 +0530 Received: from pragati.bgh.aricent.com (pragati.bgh.aricent.com [10.203.193.22])by tapal.aricent.com (8.13.8/8.13.8) with ESMTP id l71H75vI000681for ; Wed, 1 Aug 2007 22:37:05 +0530 From: Amit.Mishra@aricent.com To: sip@ietf.org Message-ID: Date: Wed, 1 Aug 2007 22:37:04 +0530 X-MIMETrack: Serialize by Router on Pragati/BLR/HSS(Release 6.5.5|November 30, 2005) at08/01/2007 10:36:38 PM MIME-Version: 1.0 X-imss-version: 2.047 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-2.5238 TC:1F TRN:27 TV:3.6.1039(15332.002) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:2 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 1.8 (+) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [Sip] Amit Kumar Mishra is out of the office. X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0288670643==" Errors-To: sip-bounces@ietf.org --===============0288670643== Content-type: text/html; charset=US-ASCII Content-Disposition: inline

I will be out of the office starting 08/01/2007 and will not return until 08/02/2007.

I will respond to your message when I return.
For escalation please contact Sudarshan Naganathan

"DISCLAIMER: This message is proprietary to Aricent 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. Aricent accepts no responsibility for
loss or damage arising from the use of the information transmitted by this email including damage from virus."
--===============0288670643== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0288670643==-- From sip-bounces@ietf.org Wed Aug 01 13:36:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGI7e-0008AA-Hq; Wed, 01 Aug 2007 13:36:34 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IGI7c-0008A5-HF for sip-confirm+ok@megatron.ietf.org; Wed, 01 Aug 2007 13:36:32 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGI7c-00089x-5n for sip@ietf.org; Wed, 01 Aug 2007 13:36:32 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGI7b-0005s5-Ig for sip@ietf.org; Wed, 01 Aug 2007 13:36:32 -0400 Received: from repmmr01.bea.com (repmmr01.bea.com [10.160.29.71]) by repmmg02.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l71HZrrr020194; Wed, 1 Aug 2007 10:35:53 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr01.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l71HZjpf009159; Wed, 1 Aug 2007 10:35:51 -0700 Received: from 172.24.29.60 ([172.24.29.60]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Wed, 1 Aug 2007 17:35:49 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Wed, 01 Aug 2007 10:42:30 -0500 Subject: Re: Content-Disposition in multiparts WAS (Re: [Sip] Draft slides forbody (MIME) handling) From: Eric Burger To: Dean Willis , Qian Sun Message-ID: Thread-Topic: Content-Disposition in multiparts WAS (Re: [Sip] Draft slides forbody (MIME) handling) Thread-Index: AcfUUpGw0G3fbEBFEdyQPgAWy4mm/w== In-Reply-To: <3F408003-7BD5-455E-9633-54D2914DD9F8@softarmor.com> Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: 'sip' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Content-Disposition="advertisement" would never pass MIME review. It is not a disposition. Give it up and move on to more important stuff, like running code :-) On 7/31/07 8:37 AM, "Dean Willis" wrote: > > On Jul 30, 2007, at 8:36 PM, Qian Sun wrote: > >> Hi, Dean >> >> Sorry for late response. Do you mean "advertisement" content always >> is needed to 'render'? So a single content disposition >> "advertisement" is enough. > > Well, I'm wondering if advertisements have any other need than > "render". If not, why not just use "render"? > > If we define an "advertisement" content disposition, we might as well > call it "ignore", in which case there's hardly any point in sending > it to start with, right? > > Although I must admit I'm intrigued by the prospect of getting > advertisers to self-label stuff so that it can be discarded as > efficiently as possible. > >> In addition, some content body (e.g. Geolocation or advertisement) >> may be inserted or modified by intermediary. Could we specify a >> common way for indicating the source of inserted content body? For >> example, define a new MIME header: Content-Insertedby. A B2BUA may >> insert a content body including AD like this: >> >> Content-Type: text/plain >> Content-Disposition: advertisement >> Content-Insertedby: AD-Agent > > I'm sure there has been discussion of this in geopriv, but I don't > recall the details. I suspect there have been concerns about > mismatches between the "source" and the "information". > > -- > 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 Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete 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 sip-bounces@ietf.org Wed Aug 01 14:12:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGIfz-0005Ro-Rm; Wed, 01 Aug 2007 14:12:03 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IGIfx-0005Rh-M5 for sip-confirm+ok@megatron.ietf.org; Wed, 01 Aug 2007 14:12:01 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGIfx-0005RZ-8F for sip@ietf.org; Wed, 01 Aug 2007 14:12:01 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGIfw-0006wO-5W for sip@ietf.org; Wed, 01 Aug 2007 14:12:01 -0400 Received: from kyzyl.cablelabs.com (kyzyl.cablelabs.com [10.253.0.7]) by ondar.cablelabs.com (8.13.8/8.13.8) with ESMTP id l71IBuCg025539; Wed, 1 Aug 2007 12:11:56 -0600 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Wed, 1 Aug 2007 12:11:56 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 1 Aug 2007 12:11:57 -0600 Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C63AFE87@srvxchg3.cablelabs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC comments on sip-outbound-10 Thread-Index: AcfUZ3K56WBzpLW2T5GuBSLydfetuw== From: "Kevin Johns" To: , , X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 Cc: Subject: [Sip] WGLC comments on sip-outbound-10 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0542117545==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0542117545== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7D467.71BC1857" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7D467.71BC1857 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 Here are my comments on outbound. A few technical comments and several nits... =20 Kevin =20 Technical (minor) Detecting Flow Failure - I could not find any text in this section which provides requirements (nor informative guidance) on when a flow should be considered failed. For CRLF it can be pretty straight forward given there are no re-transmission algorithms going on in the background (missed a response, immediatly send another CRLF before declaring a failure or immediately declare the flow failed). However, STUN does have a retransmission algorithm that the UA would need to implement and presumably this would need to complete before a flow is considered failed? =20 Edge Proxy Mechanisms - A question on edge proxy behavior when the registrar does not provide an indication of outbound support in the REGISTER response. Assuming that the UAC indicated outbound support and placed a reg-id in the contact header, the Edge Proxy would create a flow token and add that to the Path header. The registrar may not support outbound, but may support the Path header and store that as part of the contact/AOR binding. If this is done, how is the Edge Proxy to behave if it receives a request which contains a Path header with a flow token? Is it to ignore the flow token and follow standard forwarding rules per 3261 or do something else (act on the flow token and forward per Outbound procedures?) =20 STUN Keepalive Processing - I think almost all of the points made in RFC3489bis around how to define a STUN usage are addressed by this section with the exception of usage of optional attributes (in particular FINGERPRINT). I think it can be inferred that Outbound does not require (nor recommend?) the use of optional attributes, but it might be good to clarify that to ensure interoperable implementations. =20 Nits: Abstract - the last sentence states 'specifies the usage of multiple connections'. I find this statement a bit ambiguous as it does not provide any context as to what multiple connections are used for? =20 Introduction, 1st paragraph, last sentence states 'this specification allows SIP registrations when the UA is behind such a firewall or NAT'. I thought this spec was about allowing inbound requests from the proxy or registrar to the UA in the presence of a firewall or NAT? =20 Overview, 1st sentence state 'this technique'. What technique is being referred to? I assume Outbound procedures? =20 Summary of mechanism, 2nd paragraph, 2nd sentence states 'A failure on a particular flow can be tried again on an alternate flow". Suggest rewording to state A failure to deliver a request on a particular flow can be re-attempted on an alternate flow. =20 Edge Proxy Keepalive Handling - This section makes it very clear that STUN MUST be supported, but only implies that CRLF must be supported. It would be nice to align the text for the two methods. ------_=_NextPart_001_01C7D467.71BC1857 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,
 
Here = are my comments=20 on outbound. A few technical comments and several = nits...
 
Kevin
 
Technical=20 (minor)
Detecting Flow=20 Failure - I could not find any text in this section which provides = requirements=20 (nor informative guidance) on when a flow should be considered failed. = For CRLF=20 it can be pretty straight forward given there are no re-transmission = algorithms=20 going on in the background (missed a response, immediatly send another = CRLF=20 before declaring a failure or immediately declare the flow failed). = However,=20 STUN does have a retransmission algorithm that the UA would need to = implement=20 and presumably this would need to complete before a flow is considered=20 failed?
 
Edge = Proxy=20 Mechanisms - A question on edge proxy behavior when the = registrar does=20 not provide an indication of outbound support in the REGISTER response. = Assuming=20 that the UAC indicated outbound support and placed a reg-id in the = contact=20 header, the Edge Proxy would create a flow token and add that to the = Path=20 header. The=20 registrar may not support outbound, but may support the Path header and = store=20 that as part of the contact/AOR binding. If this is done, how is the = Edge Proxy=20 to behave if it receives a request which contains a Path header with a = flow=20 token? Is it to ignore the flow token and follow standard forwarding = rules per=20 3261 or do something else (act on the flow token and forward per = Outbound=20 procedures?)
 
STUN = Keepalive=20 Processing - I think almost all of the points made in RFC3489bis = around how=20 to define a STUN usage are addressed by this section with the exception = of usage=20 of optional attributes (in particular FINGERPRINT). I think it can be = inferred=20 that Outbound does not require (nor recommend?) the use of optional = attributes,=20 but it might be good to clarify that to ensure interoperable=20 implementations.
 
Nits:
Abstract - the last=20 sentence states 'specifies the usage of multiple connections'. I find = this=20 statement a bit ambiguous as it does not provide any context as to what = multiple=20 connections are used for?
 
Introduction, 1st=20 paragraph, last sentence states 'this specification allows SIP = registrations=20 when the UA is behind such a firewall or NAT'. I thought this spec was = about=20 allowing inbound requests from the proxy or registrar to the UA in the = presence=20 of a firewall or NAT?
 
Overview, 1st=20 sentence state 'this technique'. What technique is being referred to? I = assume=20 Outbound procedures?
 
Summary of=20 mechanism, 2nd paragraph, 2nd sentence states 'A failure on a particular = flow=20 can be tried again on an alternate flow". Suggest rewording to state A = failure=20 to deliver a request on a particular flow can be re-attempted on an = alternate=20 flow.
 
Edge = Proxy Keepalive=20 Handling - This section makes it very clear that STUN MUST be supported, = but=20 only implies that CRLF must be supported. It would be nice to align the = text for=20 the two=20 methods.
------_=_NextPart_001_01C7D467.71BC1857-- --===============0542117545== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0542117545==-- From sip-bounces@ietf.org Wed Aug 01 14:35:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGJ2U-0005Fv-MJ; Wed, 01 Aug 2007 14:35:18 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IGJ2T-0005Fo-Sh for sip-confirm+ok@megatron.ietf.org; Wed, 01 Aug 2007 14:35:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGJ2T-0005Ff-Iw for sip@ietf.org; Wed, 01 Aug 2007 14:35:17 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGJ2S-0006Ij-74 for sip@ietf.org; Wed, 01 Aug 2007 14:35:17 -0400 Received: from cpe-76-185-142-113.tx.res.rr.com ([76.185.142.113] helo=[192.168.2.100]) by nylon.softarmor.com with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1IGJ2R-0002Q7-87 for sip@ietf.org; Wed, 01 Aug 2007 13:35:15 -0500 Message-ID: <46B0D347.8000400@softarmor.com> Date: Wed, 01 Aug 2007 13:39:03 -0500 From: Dean Willis User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Subject: [Sip] Procedural question on updating RFC 3261 Table 2 and 3 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org If I understood things correctly, during our discussion of resource priority header extensions at IETF 69, Robert Sparks proposed a procedural change for documents that define new SIP header fields. The current Guidelines for Authors of Extensions to the Session Initiation Protocol (RFC 4485) says: o The extension MUST define which header fields can be present in requests of that method. It is RECOMMENDED that this information be represented as a new column of Table 2/3 of RFC 3261 [2]. The table MUST contain rows for all header fields defined in standards-track RFCs at the time of writing of the extension. Updating these tables (or is it just one table since it is split into two only for page-formatting reasons?) has been a contentious issue for some time. I've personally refused to do it for the last few drafts, since I got it wrong so many times before. Furthermore, this requirement is making the table(s) very, very wide, and introducing a draft-ordering problem. There's also the issue that everybody seems to interpret the table(s) differently, and that this has made for some very odd state machines when people try to code using the table(s). And I'm sure Robert had even more compelling reasons as to why we should stop updating this table (or these tables) with every draft, though I fear that they weren't recorded effectively in the minutes. So I'd like to ask the group some questions: 1) Should we stop updating Table 2/3 in each draft? 2) If so, do we need an update to RFC 4485 to establish new guidelines? 3) Should we do something instead of updating Table 2/3, such as coming up with a new representation? 4) If we have a new representation, should it be fully presented in each draft, or should it establish a new registry that each draft would update via IANA actions? Or somethinge else? -- Dean, Duly Appointed Co-Chair and Self-Appointed Pontificous Mediator _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Aug 01 14:48:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGJFI-0002fk-E8; Wed, 01 Aug 2007 14:48:32 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IGJFG-0002fe-8d for sip-confirm+ok@megatron.ietf.org; Wed, 01 Aug 2007 14:48:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGJFF-0002fW-V5 for sip@ietf.org; Wed, 01 Aug 2007 14:48:29 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGJFE-0006bN-53 for sip@ietf.org; Wed, 01 Aug 2007 14:48:29 -0400 Received: from cpe-76-185-142-113.tx.res.rr.com ([76.185.142.113] helo=[192.168.2.100]) by nylon.softarmor.com with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1IGJFC-0002Qm-F6; Wed, 01 Aug 2007 13:48:27 -0500 Message-ID: <46B0D65E.2060602@softarmor.com> Date: Wed, 01 Aug 2007 13:52:14 -0500 From: Dean Willis User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d465bee15753def7c258f355435bdf03 Cc: CULLEN JENNINGS , "Drage, Keith \(Keith\)" Subject: [Sip] Draft minutes for SIP at IETF 69 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0146756111==" Errors-To: sip-bounces@ietf.org --===============0146756111== Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Draft minutes are now available at:

http://www.softarmor.com/mediawiki/index.php/Minutes_for_SIP_at_IETF_69

HTMLized text follows for those reading offline:

Contents

[edit]

Session One, Monday July 23 2007 0900-1130

Agenda Bash and Status

Led by chairs Keith Drage and Dean Willis.

The agenda was accepted as presented.

The chairs reviewed the working group's progress since the last meeting.

A brief slide on draft-hilt-sip-correction-503 was presented by the chairs, and teh working group was asked to consider the draft and discuss it on the mailing list.

[edit]

SIPS

Led by Francois Audet.

Slides presented.

Issues raised during WGLC discussed.

[edit]

Issue: How to reject SIP or SIPS requests

currently two error codes

  1. 418 - SIPS not allowed
  2. 419 - SIPS required

Proposal is to have one error code with Allow-URI and Require-URI header

  • pro - would support other URI schemes (e.g. sipsec)
  • con - adds 2 new headers

Discussion ranged widely. Topics included:

  • Possibility of using 416 error code.
  • Meaning of 416 vs 418 error codes: 416 means I don't understand the scheme, 418 means I understand it, but it is not allowed.
  • Semantics of not allowing SIPS. Does this degrades security? Do we need a more specific and targeted solution rather than general one?
  • What is the real meaning to "support" something. Context defines reasons it support. its the same problem here with 416.
  • Need for a hard failure when cannot forward to UA because of sip/sips.
  • Option for a 480. 416 when proxy does not support sips. Use 480 because there are no contacts registered for the scheme. Worried that this might overload 480.
  • Using 480 confusing for backward compatibility. do need something that is explicit. dont like EKR idea of using a string. do 416 or 418.
  • Do not wish to make it more convenient to downgrade security. People's default behavior is to ignore the warnings and it is bad to encourage this trap.
  • Need to use a Warning header that automata can use. using 480 would require more thought by implementor to automatically downgrade. If we hide it, people will be less likely to be stupid.
  • semantics should be that there are no resources registered with that scheme.

Conclusion:No conclusion noted. Chairs are to schedule a conference call. (Ed: Topic has subsequently been raised on SIP mailing list).

[edit]

Issue on Section 3.3.2

Conclusion: Consensus is that this section has been superceded and shall be deleted.

[edit]

Outbound

Led by Rohan Mahy.

Slides presented.

Changes to draft since last meeting reviewed.


[edit]

Issue: Flow token algorithm 1 - remove?

Conclusion: Consensus: no objection to removing it.

[edit]

Issue: Merge 'keep-stun' and 'keep-crlf' into 'keep'

Conclusion: Consensus: no objection to proposed merger.

[edit]

Issue: Abuse of option tags

Conclusion: Consensus: Change draft to correct the error.

[edit]

Resource Priority Header in Responses

Led by James Polk

Slides presented.

Suggestion: That more text be added to illustrate the utility of this change.

Suggestion: Stop updating Table 2 (chairs to take to list).


Poll on "WG Adoption" reported moderate response with no one opposing.

Poll on "Accepting this document as baseline" reported weak response with no opposition.

Conclusion: Adopt as WG item. Chairs to work with ADs for milestone.

[edit]

Resource Priority Header Namespaces

Led by James Polk.

Slides presented.

Author to remove description of semantics of '-', just establish registry.

Conclusion: Adopt as WG item. Chairs to work with ADs and establish a milestone.

[edit]

Delivering Request URI and Parameters to UAS, aka UA Loose Routing

led by Jonathan Rosenberg.

Slides presented.

Alternative proposed on the list: use P-Called-Party-ID.

Discussion centered on P-Called-Party-IDs lack of standards-track status and need for further work to meet requirements. However, tehre are some existing implementations.

Noted that this is like the e-mail "faceted address problem". URI parameters might be made to work. It would be desirable to avoid "local knowledge".

Further work is needed to address issues with re-targeting & routing.

Noted that if solution is a parameter, input & output both have to be a sip URI

Suggested that a writeup of the suggested P-Called-Party-ID would be useful.

Noted that we need to coordinate any changes to P-Called-Party-ID with 3GPP, as IMS might be affected.

Poll: make decision now? or later when more documentation available?

Conclusion: To revisit problem later when there is more documentation of the other solutions.

[edit]

MIME Body Handling

Led by Gonzalo Camarillo

Slides presented.

Conclusion: General consensus that our specifications must proplerly exercise MIME. "Profiling" of MIME is not acceptable.


[edit]

Issue: multipart/alternative

Conclusions:

  • Support for multipart/alternative in UAs is a MUST
  • parts with disposition of 'session' MUST have different content-types
  • parts with disposition of 'early-session MUST have different content-types
[edit]

Issue multipart/mixed

Conclusion: Support for multipart/mixed in UAs is a MUST.

[edit]

Issue: content-disposition

Conclusion: Default for multipart/mixed is 'render', and we do not need a new disposition type.


[edit]

Issue: Content-Transfer-Encoding

Conclusion: Agreed that transfer encoding for binary payloads in SIP messages MUST be binary.


[edit]

Issue: 415 Response Codes

Conclusions:

  • alternative: new 4xx code for Content Type of Disposition Type not supported in this context.
  • proposal: clarify current 415 approach
[edit]

Issue: References to body parts

Conclusion: No consensus, discussion deferred to the list.


[edit]

Additional conclusions:

  • Include guidance on reasonable usage via SHOULD
  • change the encoding requirement to an explicit MUST
  • Consensus to make a WG item for this document. Chairs are to coordinate with AD for a milestone.
[edit]

Session Two, Tuesday July 24 2007 0900-1130

[edit]

Agenda Bash and Status

Agenda accepted as presented.

Document draft-ietf-connect-reuse discussed, including a new abstract and change of scope. WG showed a consensus to continue the work and publish the document. Jonathan Rosenberg strongly objected, and is to meet offline with Vijay Gurbani and attempt a compromise.

[edit]

Fork Loop Fix

Led by Robert Sparks.

Slides presented.

[edit]

Issue: Max-Breadth vs Whole Tree approach

Conclusion: Agreed that we would work with Max-Breadth approach and see if Security ADs will accept it.

[edit]

Essential corrections

Led by Robert Sparks.

Slides presented.

Open question on format. Many readers find current approach difficult to follow.

Suggested that we should replace whole chapters, but these can be very long.

Suggested that we do fixes like extensions; do not make a list of several small corrections.

Alternative proposal: cite the text which was changed

Suggested that implementors need a complete document that is readable (meaning a new RFC 3261), and that a diff is too hard to read.

It would be good to have an automatic way to get a final document, but change ordinality would make this very difficult.

Conclusion: Apparently there was no real conclusion here.

[edit]

SAML

Led by Jeff Hodges.

Slides presented.

[edit]

Issue: URI format

Noted that should no be restricted to http/htttps. For example, cid: might be needed.


[edit]

Issue: Relationship to RFC 4474

Will update RFC 4474.

[edit]

Issue: By-Value delivery and end-host addition

Agreed that we need by-value and by-reference.

[edit]

Issue: privacy

Authors asked to add discussion of privacy.

[edit]

Issue: WG Review

Authors were asked to propose and discuss changes "on list" instead of just making them,


Conclusion: WG is mostly confused, and more work is needed on the doc.

[edit]

eTags for Notification

Led by Aki Niemi.

Slides presented.

[edit]

Issue: Wild cards if suppressed match

Two use cases were presented:

  1. heartbeat
  2. metadata headers without body, e.g. subscription state

Conclusion: Document is confusing. Authors are to clarify in document.

[edit]

Issue: Option tag

No current justification for option tag.

Conclusion: Remove from document.

[edit]

204 Response Code

Semantics of 204 response code may be unclear, although it has a use case (lost messages).

Conclusion: Author to check on references for 204, clarify if needed.


There may also be some relation here to the NOTIFY paise work, which may need to be clarified before WGLC.

[edit]

UA-Driven Privacy

Led by Mayumi Munakata

Slides presented.

[edit]

Issue 1: what should be the privacy flag?

  • Privacy: id alone is not sufficient
[edit]

Issue 2: is it problematic that the proxy-inserted headers besides P-A-ID are disclosed?

  • Via, Record-Route, History-Info reveal network information
[edit]

Issue 3: TURN for signaling

  • JDR had previously objected here, but has withdrawn his objection.

Comments:

  • WRT issue 1: we can not re-use the id tag - a new option tag would be helpful.
  • Proxy-require can not be used as suggested by one speaker - what happens if a proxy in the middle doesn't recognize the new option?
  • Can not prevent non-compliant proxies from adding additional information. The only solution would be proxy-require, which might suggest using a new privacy-id.
  • If a message has really been anonymomized how can a hop later add privacy information?
[edit]

Conclusions:

  • The majority sees a problem which the WG needs to work on
  • The WG wants to work on UA initiated privacy
  • The WG will adopt the draft for future work. Chairs are to coordinate with ADs for milestones.
[edit]

Domain Certificates

led by Scott Lawrence

Slides presented.

[edit]

Issue: Extended key usage

PKIX reviewer noted that the CN usage in this draft is inconsistent with current specifications.

Rohan Mahy reports that certs issued today use CN.

Poll: Does the WG wish to work on this problem?

Conclusion: The WG wishes to work on this problem.

Poll: Does the WG wish to adopt this document as baseline text toward a working group effort?

Conclusion: The WG wishes to adopt this draft. Chairs are directed to work with AD to schedule.

[edit]

Authentication Using Certificates

Led by Steve Dotson.

Slides presented.

Discussion focused on whether the requirements are clear based on the current draft, and especially the use case therein. The general consensus is that this is not clear, and that the draft fails to make a case for the mechanism proposed. Several use cases were proposed during discussion. Suggestions were made that the draft be revised to account for these concerns, and that more emphasis be explained on why existing mechanisms, such as SIP Identity, might not be suitable.

It was also suggested that the authors may wish to discuss user versus device certification and authentication, and explain how things like pre-provisioned device certificates might be reasonably exercised in the scenarios addressed by the draft.

Conclusion: Authors to revise as suggested.

[edit]

INFO Considered Harmful

Led by Eric Burger.

Slides presented included in proceedings.

Discussion covered history of INFO, prior guidance on INFO usages, non-standard usages such as DTMF, the SIP extension architecture, and what, if anything, could now be reasonably addressed.

Three options were proposed:

  1. Developing an RFC to explain the issues with INFO and proscribe further usages beyond those specified by existing RFCs. It was noted that this approach, if taken, would require that we include substantial background on the architectural issue and give clear guidance on the preferred way to do things including using alternatives such as URI parameters, new SIP methods, new SIP header fields and parameters, and media sessions.
  2. Developing an INFO usage registry, documentation guidelines, and negotiation mechanism similar to that of RFC 3265.
  3. Continuing to refrain from further specification.

Conclusions:

  • The meeting responded unanimously to the question "does this working group need to do something about INFO?", thereby discarding option #3 above.
  • The clear majority of those responding in the room preferred the option of prohibiting new usages of INFO to the option of developing an INFO usage registry and negotiation mechanism. The chairs refrained from judging consensus at this time and have brought the topic to the mailing list for further consideration, proposing that the working group adopt option #1 above.
[edit]

Media Identity

Led by Dan Wing.

Slides presented.

Dan Wing reports that Cisco has made IPR claims related to this material.

Discussion centered on difficulties with applying RFC 4474 techniques through session border controllers and other B2BUA.

Some participants in the discussion questioned the use case or wondered whether the problem posed by the use case needs to be solved.

Conclusion: There was no consensus to pursue the work at this time, but the WG might be willing to reconsider if more convincing use cases can be provided.


Back to SIP Notes and Minutes at IETF 69


--===============0146756111== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0146756111==-- From sip-bounces@ietf.org Wed Aug 01 15:50:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGKCz-0008KI-Lv; Wed, 01 Aug 2007 15:50:13 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IGKCy-0008K5-H0 for sip-confirm+ok@megatron.ietf.org; Wed, 01 Aug 2007 15:50:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGKCy-0008Jx-7P for sip@ietf.org; Wed, 01 Aug 2007 15:50:12 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGKCw-0000Hk-Vn for sip@ietf.org; Wed, 01 Aug 2007 15:50:12 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 01 Aug 2007 12:50:10 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAD6BsEarR7PE/2dsb2JhbAA X-IronPort-AV: i="4.19,210,1183359600"; d="scan'208"; a="389676979:sNHT29361808" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l71JoA6t029540; Wed, 1 Aug 2007 12:50:10 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l71Jo1E2022201; Wed, 1 Aug 2007 19:50:02 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Aug 2007 12:49:55 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.119.77]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Aug 2007 12:49:54 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 01 Aug 2007 14:49:53 -0500 To: Dean Willis , sip@ietf.org From: "James M. Polk" Subject: Re: [Sip] Procedural question on updating RFC 3261 Table 2 and 3 In-Reply-To: <46B0D347.8000400@softarmor.com> References: <46B0D347.8000400@softarmor.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 01 Aug 2007 19:49:54.0917 (UTC) FILETIME=[21F2C950:01C7D475] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1287; t=1185997810; x=1186861810; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Sip]=20Procedural=20question=20on=20updating=20RFC=2 03261=20Table=202=20and=0A=20=203 |Sender:=20; bh=UiuP4eDrWYDIyvikn3ZmyMTweUhkdP6+H3tpFYlZb+s=; b=Z8IC3e0jx//7BOTBJxFZ0TLVKCYqaCeA7FLo0juJhQ8a4iPPwlYVCg/Wn+CAHN1xt7cJq4vL 1I86sS09uxV7hXXe69hvQYVie00/NKbCLF2cVxOsVmtnTxWC+FSDDeQq; Authentication-Results: sj-dkim-4; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 01:39 PM 8/1/2007, Dean Willis wrote: >So I'd like to ask the group some questions: > >1) Should we stop updating Table 2/3 in each draft? > >2) If so, do we need an update to RFC 4485 to establish new guidelines? > >3) Should we do something instead of updating Table 2/3, such as >coming up with a new representation? > >4) If we have a new representation, should it be fully presented in >each draft, or should it establish a new registry that each draft >would update via IANA actions? Or somethinge else? If we choose #s 3 or 4 - we need to update RFC-4485 Doing #1 also requires an update to RFC-4485 meaning, unless we continue doing the table fill per draft, we need to update RFC-4485. What would an alternative to table 2/3 be? While I agree that supporting text in a particular doc doesn't always follow the doc's table 2/3 update, which should have been a requirement in RFC-4485 BTW, having that inconsistency can only cause inconsistent implementations. I like the table, but feel we need to update RFC-4485 with consistent text supporting the table in each doc, if we keep the table (and the RFC-4485 requirement in Dean's original message). >-- >Dean, Duly Appointed Co-Chair and Self-Appointed Pontificous Mediator _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Aug 01 15:51:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGKEJ-0000ab-Sz; Wed, 01 Aug 2007 15:51:35 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IGKEI-0000ZN-Ab for sip-confirm+ok@megatron.ietf.org; Wed, 01 Aug 2007 15:51:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGKEH-0000ZF-Vs for sip@ietf.org; Wed, 01 Aug 2007 15:51:34 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGKEH-0001Sl-FX for sip@ietf.org; Wed, 01 Aug 2007 15:51:33 -0400 Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l71JpU921293; Wed, 1 Aug 2007 19:51:30 GMT x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Procedural question on updating RFC 3261 Table 2 and 3 Date: Wed, 1 Aug 2007 14:51:12 -0500 Message-ID: In-Reply-To: <46B0D347.8000400@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Procedural question on updating RFC 3261 Table 2 and 3 Thread-Index: AcfUasEHuGkQmuL1Tv2c/R/gqrB9wwACXVxg From: "Mary Barnes" To: "Dean Willis" X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Responses embedded below [MB]. Mary -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com]=20 Sent: Wednesday, August 01, 2007 1:39 PM To: sip@ietf.org Subject: [Sip] Procedural question on updating RFC 3261 Table 2 and 3 If I understood things correctly, during our discussion of resource=20 priority header extensions at IETF 69, Robert Sparks proposed a=20 procedural change for documents that define new SIP header fields. The current Guidelines for Authors of Extensions to the Session=20 Initiation Protocol (RFC 4485) says: o The extension MUST define which header fields can be present in requests of that method. It is RECOMMENDED that this information be represented as a new column of Table 2/3 of RFC 3261 [2]. The table MUST contain rows for all header fields defined in standards-track RFCs at the time of writing of the extension. Updating these tables (or is it just one table since it is split into=20 two only for page-formatting reasons?) has been a contentious issue for=20 some time. I've personally refused to do it for the last few drafts,=20 since I got it wrong so many times before. Furthermore, this requirement is making the table(s) very, very wide, and introducing a draft-ordering problem. There's also the issue that everybody seems to interpret the table(s)=20 differently, and that this has made for some very odd state machines=20 when people try to code using the table(s). [MB] I agree that folks have problems interpreting the table and they tend to use their (wrong) interpretation rather than normative text. [/MB] And I'm sure Robert had even more compelling reasons as to why we should stop updating this table (or these tables) with every draft, though I=20 fear that they weren't recorded effectively in the minutes. So I'd like to ask the group some questions: 1) Should we stop updating Table 2/3 in each draft? [MB] Yes.=20 2) If so, do we need an update to RFC 4485 to establish new guidelines? [MB] I don't think we need to update RFC 4485. As you mention previously, not all documents have been doing the table. I'd say to wait to update RFC 4485 until after you've got the alternative approach defined. [/MB] 3) Should we do something instead of updating Table 2/3, such as coming=20 up with a new representation? [MB] I think we should wait until 3261bis before trying to come up with a new format. =20 4) If we have a new representation, should it be fully presented in each draft, or should it establish a new registry that each draft would=20 update via IANA actions? Or somethinge else? [MB] If we do have a new representation, I don't think it needs to be fully represented in each draft. I think a registry would be far better. [/MB] -- Dean, Duly Appointed Co-Chair and Self-Appointed Pontificous Mediator _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Aug 01 16:31:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGKr8-0004A7-2n; Wed, 01 Aug 2007 16:31:42 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IGKr5-00049m-Q5 for sip-confirm+ok@megatron.ietf.org; Wed, 01 Aug 2007 16:31:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGKr4-000492-9e; Wed, 01 Aug 2007 16:31:38 -0400 Received: from alnrmhc14.comcast.net ([206.18.177.54]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGKr3-0002Vr-T8; Wed, 01 Aug 2007 16:31:38 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (alnrmhc14) with ESMTP id <20070801203136b1400pgtsle>; Wed, 1 Aug 2007 20:31:37 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l71KVZ8t016569; Wed, 1 Aug 2007 16:31:35 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l71KVZBv016565; Wed, 1 Aug 2007 16:31:35 -0400 Date: Wed, 1 Aug 2007 16:31:35 -0400 Message-Id: <200708012031.l71KVZBv016565@dragon.ariadne.com> From: Dale.Worley@comcast.net To: magnus.westerlund@ericsson.com In-reply-to: <46AF5370.9020304@ericsson.com> (magnus.westerlund@ericsson.com) Subject: Re: [Sip] Draft Liaision response to SG13 on Emergency Telecommunications References: <46AF5370.9020304@ericsson.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: sip@ietf.org, sipping@ietf.org, tsvwg@ietf.org, nsis@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org This is a response to the liaison request made by Q3/13 regarding It looks like that should be "Q.3/13". emergency telecommunications (REF: NGN-GSI/DOC – 60 Rev.2). We would first like to apologize for failing to meet the deadline in responding. We do hope that the late answer still can be of some use. The liaison request was made to the following working groups (WG): IEPREP, TSVWG, and NSIS. Since the request was sent the IEPREP WG has concluded. In addition to the WGs from which information was requested, we also think that work performed by the SIP and SIPPING WG may be of relevance. Pursuant to ITU-T Study Group 13 request for information on relevant and related work in the IETF regarding emergency communications, we list below RFCs and works in progress that we feel may be of interest to your group. Some of the completed work is Informational, and others are in the category of Standards Track. Q.3/13 also requested that we keep you informed of any developments in regards to emergency telecommunications. In those regards we would like to make you aware that IETF mailing list participation and document information is free and open for anyone. Allowing participants in Q.3/13 "... free and open to anyone, allowing ..." to keep them selves informed of any developments. If Q.3/13 desire to "... themselves ..." (unless that's a US-ism) get further information about specific ongoing work, then please send a liaison request to the responsible WG for those specific documents. The following list is divided under the associated working groups from which the work has been done within the IETF. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Aug 01 17:07:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGLQ3-00020U-1v; Wed, 01 Aug 2007 17:07:47 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IGLQ2-00020O-0q for sip-confirm+ok@megatron.ietf.org; Wed, 01 Aug 2007 17:07:46 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGLQ1-00020G-KD for sip@ietf.org; Wed, 01 Aug 2007 17:07:45 -0400 Received: from cluster-f.mailcontrol.com ([85.119.2.190]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGLQ0-0003Pb-PP for sip@ietf.org; Wed, 01 Aug 2007 17:07:45 -0400 Received: from rly03f.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly03f.srv.mailcontrol.com (MailControl) with ESMTP id l71L7WXD013241 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 1 Aug 2007 22:07:32 +0100 Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly03f.srv.mailcontrol.com (MailControl) id l71L72x4011695 for sip@ietf.org; Wed, 1 Aug 2007 22:07:02 +0100 Received: from exsmtp01.nasstar-t1.net (exsmtp01.nasstar-t1.net [89.28.233.12]) by rly03f-eth0.srv.mailcontrol.com (envelope-sender attila.sipos@vegastream.com) (MIMEDefang) with ESMTP id l71L6war011404; Wed, 01 Aug 2007 22:07:02 +0100 (BST) Received: from ExBE03.nasstar-t1.net ([10.2.10.102]) by exsmtp01.nasstar-t1.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Aug 2007 22:06:37 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 Date: Wed, 1 Aug 2007 22:04:56 +0100 Message-ID: <165288C2C3E29449AFDE022DD10CC4710359EF46@ExBE03.nasstar-t1.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 Thread-Index: AcfULqjYr9/fOicOQYakFJ9W326jDAAJGrVgAAsiZo4= References: <1ECE0EB50388174790F9694F77522CCF11697776@zrc2hxm0.corp.nortel.com><247B95AF-63F6-432D-9D6E-AF083AF9C525@nostrum.com><46A92B7C.7080202@cisco.com><1ECE0EB50388174790F9694F77522CCF116E20B5@zrc2hxm0.corp.nortel.com><20070727153727.A4BDD33C1A@delta.rtfm.com><46AA138D.6030001@cisco.com><46AA1FAA.3000204@cisco.com><325E76F4-3A53-4101-BBDB-D2131FA4BB1D@ekabal.com><030401c7d3b9$457a9360$800101df@acmepacket.com><3B61AA00-CC03-4607-9606-CA5B8C2EC5CB@ekabal.com><46B06DA2.2090904@cisco.com> <1ECE0EB50388174790F9694F77522CCF11795034@zrc2hxm0.corp.nortel.com> From: "Attila Sipos" To: "Francois Audet" , "Michael Thomas" X-OriginalArrivalTime: 01 Aug 2007 21:06:37.0283 (UTC) FILETIME=[D92C1B30:01C7D47F] X-Scanned-By: MailControl A-07-08-00 (www.mailcontrol.com) on 10.70.1.113 X-Spam-Score: 1.8 (+) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0321820585==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0321820585== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7D47F.D86A4364" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7D47F.D86A4364 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable by the way what were the objections? just curious. =20 Regards, =20 Attila =20 ________________________________ From: Francois Audet [mailto:audet@nortel.com] Sent: Wed 01/08/2007 16:55 To: Michael Thomas Cc: IETF SIP List Subject: RE: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Wednesday, August 01, 2007 04:25 > To: Rohan Mahy > Cc: Hadriel Kaplan; 'IETF SIP List'; Audet, Francois > (SC100:3055); Jon.Peterson@neustar.com; 'Paul Kyzivat' > Subject: Re: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 > > Question: as currently defined can these two new warnings be > reused by any future method that is hopefully more secure > than SIPS so that we don't have to rehash this argument again? The draft uses the Warn-codes in 480. But it could be used by other response (e.g., 424 for location conveyance, if we decide it makes sense). Or any other response. I'm assuming you mean "other URI schemes" instead of "other methods". I currently have it as follows: 380 SIPS Not Allowed 381 SIPS Required So, obviously, they are tied to SIPS. If we defined another URI scheme (e.g., sipsec or whatever), then it would probably need new Warning Codes. The alternative, which I presented in Chicago, based on Attila's proposal (i.e., defining a new header that specifically list the Allowed or Required URI schemes) was NOT viewed favorably by the group. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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_01C7D47F.D86A4364 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] draft-ietf-sip-sips-05: 480 vs. = 418=0A= =0A= =0A= =0A=
=0A=
by the way = what were the objections?
=0A=
just curious.
=0A=
 
=0A=
Regards,
=0A=
 
=0A=
Attila
=0A=
 
=0A=

=0A=
=0A= From: Francois Audet = [mailto:audet@nortel.com]
Sent: Wed 01/08/2007 = 16:55
To: Michael Thomas
Cc: IETF SIP = List
Subject: RE: [Sip] draft-ietf-sip-sips-05: 480 vs. = 418

=0A=
=0A=



> -----Original Message-----
> From: = Michael Thomas [mailto:mat@cisco.com]
> Sent: = Wednesday, August 01, 2007 04:25
> To: Rohan Mahy
> Cc: = Hadriel Kaplan; 'IETF SIP List'; Audet, Francois
> (SC100:3055); = Jon.Peterson@neustar.com; 'Paul Kyzivat'
> Subject: Re: [Sip] = draft-ietf-sip-sips-05: 480 vs. 418
>
> Question: as = currently defined can these two new warnings be
> reused by any = future method that is hopefully more secure
> than SIPS so that we = don't have to rehash this argument again?

The draft uses the = Warn-codes in 480. But it could be used
by other response (e.g., 424 = for location conveyance, if we
decide it makes sense). Or any other = response.

I'm assuming you mean "other URI schemes" instead of = "other
methods".

I currently have it as = follows:

   380  SIPS Not = Allowed

   381  SIPS Required

So, = obviously, they are tied to SIPS.

If we defined another URI = scheme (e.g., sipsec or whatever), then it
would probably need new = Warning Codes.

The alternative, which I presented in Chicago, = based on Attila's
proposal
(i.e., defining a new header that = specifically list the Allowed or
Required
URI schemes) was NOT = viewed favorably by the = group.




_______________________________________________=
Sip mailing list  https://www1.ietf.org= /mailman/listinfo/sip
This list is for NEW development of the = core SIP 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_01C7D47F.D86A4364-- --===============0321820585== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0321820585==-- From sip-bounces@ietf.org Wed Aug 01 22:06:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGQ5C-0000bs-4Q; Wed, 01 Aug 2007 22:06:34 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IGQ5A-0000bk-IV for sip-confirm+ok@megatron.ietf.org; Wed, 01 Aug 2007 22:06:32 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGQ5A-0000bZ-8N for sip@ietf.org; Wed, 01 Aug 2007 22:06:32 -0400 Received: from sccrmhc14.comcast.net ([204.127.200.84]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGQ59-0000wE-TJ for sip@ietf.org; Wed, 01 Aug 2007 22:06:32 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (sccrmhc14) with ESMTP id <20070802020625014001893ce>; Thu, 2 Aug 2007 02:06:25 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l7226O8t008933 for ; Wed, 1 Aug 2007 22:06:24 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l7226OYX008929; Wed, 1 Aug 2007 22:06:24 -0400 Date: Wed, 1 Aug 2007 22:06:24 -0400 Message-Id: <200708020206.l7226OYX008929@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <46AEDFED.6000302@nokia.com> (aki.niemi@nokia.com) Subject: Re: [Sip] subnot-etags: suppressing NOTIFY interactions with SBCs and other middleboxes References: <46AEDFED.6000302@nokia.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: Aki Niemi Currently, subnot-etags offers two modes of operation. In the first, the body of the SUBSCRIBE-generated NOTIFY is suppressed, and in the other, the entire NOTIFY is suppressed, and a new response 204 (No Notification) is generated instead. The latter is a considerable change to how SIP events works, and might cause a middlebox that tracks the SIP dialog to basically barf, thinking the dialog expires when it in fact gets refreshed. I'm tempted to put all the responsibility on the SBC, since the fundamental "deal" for an SBC is that in return for not being a proxy, it takes on the responsibility of keeping up with evolving standards and behaviors. But looking at RFC 3265, I see that all 2xx responses to SUBSCRIBEs are required to contain an Expires header for the subscription. And draft-ietf-sip-subnot-etags-00, section 4.5, item 2 reiterates that rule. So SBCs can track subscription lifetime without seeing NOTIFYs, and for robustness should already be doing so. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Aug 01 22:07:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGQ5w-0001zL-5W; Wed, 01 Aug 2007 22:07:20 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IGQ5u-0001p3-Lq for sip-confirm+ok@megatron.ietf.org; Wed, 01 Aug 2007 22:07:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGQ5u-0001oO-AQ for sip@ietf.org; Wed, 01 Aug 2007 22:07:18 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGQ5s-0007jV-4o for sip@ietf.org; Wed, 01 Aug 2007 22:07:18 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JM400944J6QVX@szxga02-in.huawei.com> for sip@ietf.org; Thu, 02 Aug 2007 10:06:27 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JM4005ODJ6QLC@szxga02-in.huawei.com> for sip@ietf.org; Thu, 02 Aug 2007 10:06:26 +0800 (CST) Received: from s32328b ([10.70.108.124]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JM4003M0J6KK2@szxml04-in.huawei.com> for sip@ietf.org; Thu, 02 Aug 2007 10:06:26 +0800 (CST) Date: Thu, 02 Aug 2007 10:06:20 +0800 From: Qian Sun Subject: RE: Content-Disposition in multiparts WAS (Re: [Sip] Draft slides forbody (MIME) handling) In-reply-to: To: 'Eric Burger' , 'Dean Willis' Message-id: <004701c7d4a9$b87bc870$7c6c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7BIT Thread-index: AcfUUpGw0G3fbEBFEdyQPgAWy4mm/wAUjwsA X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: 'sip' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, Eric An AD bodypart should be marked "advertisement" if it is intended to be displayed in a non-disturbed/non-confusing way. The "advertisement" Disposition Type would be a kind of display manner between "Inline" and "Attachment". For example, a client could display advertisement in a place different from the content window. Cheers, Qian -----Original Message----- From: Eric Burger [mailto:eburger@bea.com] Sent: Wednesday, August 01, 2007 11:42 PM To: Dean Willis; Qian Sun Cc: 'sip' Subject: Re: Content-Disposition in multiparts WAS (Re: [Sip] Draft slides forbody (MIME) handling) Content-Disposition="advertisement" would never pass MIME review. It is not a disposition. Give it up and move on to more important stuff, like running code :-) On 7/31/07 8:37 AM, "Dean Willis" wrote: > > On Jul 30, 2007, at 8:36 PM, Qian Sun wrote: > >> Hi, Dean >> >> Sorry for late response. Do you mean "advertisement" content always >> is needed to 'render'? So a single content disposition >> "advertisement" is enough. > > Well, I'm wondering if advertisements have any other need than > "render". If not, why not just use "render"? > > If we define an "advertisement" content disposition, we might as well > call it "ignore", in which case there's hardly any point in sending > it to start with, right? > > Although I must admit I'm intrigued by the prospect of getting > advertisers to self-label stuff so that it can be discarded as > efficiently as possible. > >> In addition, some content body (e.g. Geolocation or advertisement) >> may be inserted or modified by intermediary. Could we specify a >> common way for indicating the source of inserted content body? For >> example, define a new MIME header: Content-Insertedby. A B2BUA may >> insert a content body including AD like this: >> >> Content-Type: text/plain >> Content-Disposition: advertisement >> Content-Insertedby: AD-Agent > > I'm sure there has been discussion of this in geopriv, but I don't > recall the details. I suspect there have been concerns about > mismatches between the "source" and the "information". > > -- > 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 Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete 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 sip-bounces@ietf.org Wed Aug 01 22:38:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGQZg-0005jS-6o; Wed, 01 Aug 2007 22:38:04 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IGQZe-0005jG-Ro for sip-confirm+ok@megatron.ietf.org; Wed, 01 Aug 2007 22:38:02 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGQZe-0005im-HN for sip@ietf.org; Wed, 01 Aug 2007 22:38:02 -0400 Received: from rwcrmhc11.comcast.net ([216.148.227.151]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGQZe-0001We-6v for sip@ietf.org; Wed, 01 Aug 2007 22:38:02 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (rwcrmhc11) with ESMTP id <20070802023800m110013l18e>; Thu, 2 Aug 2007 02:38:01 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l722c08t011340 for ; Wed, 1 Aug 2007 22:38:00 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l722c0jx011336; Wed, 1 Aug 2007 22:38:00 -0400 Date: Wed, 1 Aug 2007 22:38:00 -0400 Message-Id: <200708020238.l722c0jx011336@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <004701c7d4a9$b87bc870$7c6c460a@china.huawei.com> (sunqian@huawei.com) Subject: Re: Content-Disposition in multiparts WAS (Re: [Sip] Draft slides forbody (MIME) handling) References: <004701c7d4a9$b87bc870$7c6c460a@china.huawei.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: Qian Sun An AD bodypart should be marked "advertisement" if it is intended to be displayed in a non-disturbed/non-confusing way. The "advertisement" Disposition Type would be a kind of display manner between "Inline" and "Attachment". For example, a client could display advertisement in a place different from the content window. I'd hack my UA so that it wouldn't display "advertisement"s at all! Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Aug 02 00:37:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGSQX-000470-UZ; Thu, 02 Aug 2007 00:36:45 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IGSQW-00046s-92 for sip-confirm+ok@megatron.ietf.org; Thu, 02 Aug 2007 00:36:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGSQV-00046k-VF for sip@ietf.org; Thu, 02 Aug 2007 00:36:43 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGSQV-0004DB-2L for sip@ietf.org; Thu, 02 Aug 2007 00:36:43 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JM400GGEQ403E@szxga02-in.huawei.com> for sip@ietf.org; Thu, 02 Aug 2007 12:36:00 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JM400HC5Q3ZBN@szxga02-in.huawei.com> for sip@ietf.org; Thu, 02 Aug 2007 12:36:00 +0800 (CST) Received: from s32328b ([10.70.108.124]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JM4008EBQ3WKA@szxml04-in.huawei.com> for sip@ietf.org; Thu, 02 Aug 2007 12:35:59 +0800 (CST) Date: Thu, 02 Aug 2007 12:35:56 +0800 From: Qian Sun Subject: RE: Content-Disposition in multiparts WAS (Re: [Sip] Draft slidesforbody (MIME) handling) In-reply-to: <200708020238.l722c0jx011336@dragon.ariadne.com> To: Dale.Worley@comcast.net, sip@ietf.org Message-id: <004b01c7d4be$9e1130f0$7c6c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7BIT Thread-index: AcfUri0iV5MoAQ8nRHWLYgvzmaa2XwADuMcw X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, Dale Yes, you can do that. But most of people wouldn't use hacked software. And this kind of advertisement is harmless, it's not worth hacking your UA. Cheers, Qian -----Original Message----- From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net] Sent: Thursday, August 02, 2007 10:38 AM To: sip@ietf.org Subject: Re: Content-Disposition in multiparts WAS (Re: [Sip] Draft slidesforbody (MIME) handling) From: Qian Sun An AD bodypart should be marked "advertisement" if it is intended to be displayed in a non-disturbed/non-confusing way. The "advertisement" Disposition Type would be a kind of display manner between "Inline" and "Attachment". For example, a client could display advertisement in a place different from the content window. I'd hack my UA so that it wouldn't display "advertisement"s at all! Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Aug 02 01:21:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGT7N-00029L-RJ; Thu, 02 Aug 2007 01:21:01 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IGT7K-00029F-Jb for sip-confirm+ok@megatron.ietf.org; Thu, 02 Aug 2007 01:20:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGT7J-000296-T3 for sip@ietf.org; Thu, 02 Aug 2007 01:20:57 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGT7H-0003Tq-Lz for sip@ietf.org; Thu, 02 Aug 2007 01:20:57 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JM400KSES5L0F@szxga03-in.huawei.com> for sip@ietf.org; Thu, 02 Aug 2007 13:20:09 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JM400L53S5L2I@szxga03-in.huawei.com> for sip@ietf.org; Thu, 02 Aug 2007 13:20:09 +0800 (CST) Received: from t34932 ([10.70.108.127]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JM4003T7S5GK2@szxml04-in.huawei.com> for sip@ietf.org; Thu, 02 Aug 2007 13:20:09 +0800 (CST) Date: Thu, 02 Aug 2007 13:20:04 +0800 From: Linyi Tian Subject: RE: Content-Disposition in multiparts WAS (Re: [Sip] Draftslidesforbody (MIME) handling) In-reply-to: <004b01c7d4be$9e1130f0$7c6c460a@china.huawei.com> To: 'Qian Sun' , Dale.Worley@comcast.net, sip@ietf.org Message-id: <022b01c7d4c4$c91a21c0$7f6c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7BIT Thread-index: AcfUri0iV5MoAQ8nRHWLYgvzmaa2XwADuMcwAAHjg/A= X-Spam-Score: 1.2 (+) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, guys If you can make money from it, you may not want to hack your UA. BR, Linyi -----Original Message----- From: Qian Sun [mailto:sunqian@huawei.com] Sent: Thursday, August 02, 2007 12:36 PM To: Dale.Worley@comcast.net; sip@ietf.org Subject: RE: Content-Disposition in multiparts WAS (Re: [Sip] Draftslidesforbody (MIME) handling) Hi, Dale Yes, you can do that. But most of people wouldn't use hacked software. And this kind of advertisement is harmless, it's not worth hacking your UA. Cheers, Qian -----Original Message----- From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net] Sent: Thursday, August 02, 2007 10:38 AM To: sip@ietf.org Subject: Re: Content-Disposition in multiparts WAS (Re: [Sip] Draft slidesforbody (MIME) handling) From: Qian Sun An AD bodypart should be marked "advertisement" if it is intended to be displayed in a non-disturbed/non-confusing way. The "advertisement" Disposition Type would be a kind of display manner between "Inline" and "Attachment". For example, a client could display advertisement in a place different from the content window. I'd hack my UA so that it wouldn't display "advertisement"s at all! Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Aug 02 03:38:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGVGd-0007zS-3j; Thu, 02 Aug 2007 03:38:43 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IGVGb-0007zK-FN for sip-confirm+ok@megatron.ietf.org; Thu, 02 Aug 2007 03:38:41 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGVGb-0007zB-2f for sip@ietf.org; Thu, 02 Aug 2007 03:38:41 -0400 Received: from cluster-f.mailcontrol.com ([85.119.2.190]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGVGZ-00007V-M7 for sip@ietf.org; Thu, 02 Aug 2007 03:38:40 -0400 Received: from rly12f.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly12f.srv.mailcontrol.com (MailControl) with ESMTP id l727cYO5015044 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 2 Aug 2007 08:38:36 +0100 Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly12f.srv.mailcontrol.com (MailControl) id l727cFRX014371 for sip@ietf.org; Thu, 2 Aug 2007 08:38:15 +0100 Received: from exsmtp01.nasstar-t1.net (exsmtp01.nasstar-t1.net [89.28.233.12]) by rly12f-eth0.srv.mailcontrol.com (envelope-sender attila.sipos@vegastream.com) (MIMEDefang) with ESMTP id l727c0P7013820; Thu, 02 Aug 2007 08:38:15 +0100 (BST) Received: from ExBE03.nasstar-t1.net ([10.2.10.102]) by exsmtp01.nasstar-t1.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Aug 2007 08:38:06 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 Date: Thu, 2 Aug 2007 08:38:04 +0100 Message-ID: <165288C2C3E29449AFDE022DD10CC4710359EF47@ExBE03.nasstar-t1.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 Thread-Index: AcfULqjYr9/fOicOQYakFJ9W326jDAAJGrVgAAsiZo4AAHJIMAAVKTDk References: <1ECE0EB50388174790F9694F77522CCF11697776@zrc2hxm0.corp.nortel.com><247B95AF-63F6-432D-9D6E-AF083AF9C525@nostrum.com><46A92B7C.7080202@cisco.com><1ECE0EB50388174790F9694F77522CCF116E20B5@zrc2hxm0.corp.nortel.com><20070727153727.A4BDD33C1A@delta.rtfm.com><46AA138D.6030001@cisco.com><46AA1FAA.3000204@cisco.com><325E76F4-3A53-4101-BBDB-D2131FA4BB1D@ekabal.com><030401c7d3b9$457a9360$800101df@acmepacket.com><3B61AA00-CC03-4607-9606-CA5B8C2EC5CB@ekabal.com><46B06DA2.2090904@cisco.com> <1ECE0EB50388174790F9694F77522CCF11795034@zrc2hxm0.corp.nortel.com> <165288C2C3E29449AFDE022DD10CC4710359EF46@ExBE03.nasstar-t1.net> <1ECE0EB50388174790F9694F77522CCF117DB650@zrc2hxm0.corp.nortel.com> From: "Attila Sipos" To: "Francois Audet" , X-OriginalArrivalTime: 02 Aug 2007 07:38:06.0366 (UTC) FILETIME=[10D35BE0:01C7D4D8] X-Scanned-By: MailControl A-07-08-00 (www.mailcontrol.com) on 10.70.1.122 X-Spam-Score: 1.8 (+) X-Scan-Signature: 162d87dc0b780d17da9b1934777fd451 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0377653944==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0377653944== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7D4D8.0FE5A62F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7D4D8.0FE5A62F Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >>Basically, a large number of people wanted the error to NOT be = explicit, and allow "downgrades".=20 =20 I still don't get it. In a similar scenario, if you're using a web browser then the user will = know what sites are secure because of the padlock icon. When diverted away from a secure site (automatically) the user can see the padlock = disappears. And in some cases, the browser will display a message to tell the user that the connection is no longer secure. =20 I don't see why the equivalent thing can't be done in SIP/SIPS. The security (or lack of) doesn't matter provided the user is informed. It should be up to the user to decide if they want to allow a downgrade, not the protocol specification. I agree that a bad implementor could = do the downgrade secretly but, for me, this is no different to a bad web = browser which doesn't tell you about the security level - you simply wouldn't = choose to use such a browser. =20 I know SIP and HTTP are different but I can't see the difference in this case. =20 Regards, Attila =20 ________________________________ From: Francois Audet [mailto:audet@nortel.com] Sent: Wed 01/08/2007 22:19 To: Attila Sipos Subject: RE: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 Basically, a large number of people wanted the error to NOT be explicit, = and allow "downgrades".=20 =20 The use of the Warning is a compromise for them. The idea being that = most people will ignore the warning and just fail the call, unless they = really know what they are doing. =20 =20 ________________________________ From: Attila Sipos [mailto:attila.sipos@vegastream.com]=20 Sent: Wednesday, August 01, 2007 14:05 To: Audet, Francois (SC100:3055); Michael Thomas Cc: IETF SIP List Subject: RE: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 =09 =09 by the way what were the objections? just curious. =20 Regards, =20 Attila =20 ________________________________ From: Francois Audet [mailto:audet@nortel.com] Sent: Wed 01/08/2007 16:55 To: Michael Thomas Cc: IETF SIP List Subject: RE: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 =09 =09 =09 =09 > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Wednesday, August 01, 2007 04:25 > To: Rohan Mahy > Cc: Hadriel Kaplan; 'IETF SIP List'; Audet, Francois > (SC100:3055); Jon.Peterson@neustar.com; 'Paul Kyzivat' > Subject: Re: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 > > Question: as currently defined can these two new warnings be > reused by any future method that is hopefully more secure > than SIPS so that we don't have to rehash this argument again? =09 The draft uses the Warn-codes in 480. But it could be used by other response (e.g., 424 for location conveyance, if we decide it makes sense). Or any other response. =09 I'm assuming you mean "other URI schemes" instead of "other methods". =09 I currently have it as follows: =09 380 SIPS Not Allowed =09 381 SIPS Required =09 So, obviously, they are tied to SIPS. =09 If we defined another URI scheme (e.g., sipsec or whatever), then it would probably need new Warning Codes. =09 The alternative, which I presented in Chicago, based on Attila's proposal (i.e., defining a new header that specifically list the Allowed or Required URI schemes) was NOT viewed favorably by the group. =09 =09 =09 =09 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip =09 ------_=_NextPart_001_01C7D4D8.0FE5A62F Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] draft-ietf-sip-sips-05: 480 vs. = 418=0A= =0A= =0A= =0A=
=0A=
>>Basically, a large number of people wanted the error to = NOT be explicit, and allow "downgrades".
=0A=
 
=0A=
I still don't get = it.
=0A=
In a similar scenario, if = you're using a web browser then the user will know
=0A=
what sites are secure because = of the padlock icon.  When diverted away
=0A=
from a secure site = (automatically) the user can see the padlock disappears.
=0A=
And in some cases, the = browser will display a message to tell the user
=0A=
that the connection is no = longer secure.
=0A=
 
=0A=
I don't see why the = equivalent thing can't be done in SIP/SIPS.
=0A=
The security (or lack of) = doesn't matter provided the user is informed.
=0A=
It should be up to the user = to decide if they want to allow a downgrade,
=0A=
not the protocol = specification.   I agree that a bad implementor could = do
=0A=
the downgrade secretly but, = for me, this is no different to a bad web browser
=0A=
which doesn't tell you about = the security level - you simply wouldn't choose
=0A=
to use such a = browser.
=0A=
 
=0A=
I know SIP and HTTP are = different but I can't see the difference
=0A=
in this case.
=0A=
 
=0A=
Regards,
=0A=
Attila
=0A=
 
=0A=

=0A=
=0A= From: Francois Audet = [mailto:audet@nortel.com]
Sent: Wed 01/08/2007 = 22:19
To: Attila Sipos
Subject: RE: [Sip] = draft-ietf-sip-sips-05: 480 vs. 418

=0A=
=0A=
Basically, a large number of people wanted the error to NOT be = explicit, and allow "downgrades".
=0A=
 
=0A=
The use of the Warning is a compromise for them. The idea being = that most people will ignore the warning and just fail the call, unless = they really know what they are doing.
=0A=
 
=0A=
 

=0A=
=0A=
=0A=
=0A= From: Attila Sipos = [mailto:attila.sipos@vegastream.com]
Sent: Wednesday, August = 01, 2007 14:05
To: Audet, Francois (SC100:3055); Michael = Thomas
Cc: IETF SIP List
Subject: RE: [Sip] = draft-ietf-sip-sips-05: 480 vs. 418

=0A=
=0A=
=0A=
by the way = what were the objections?
=0A=
just curious.
=0A=
 
=0A=
Regards,
=0A=
 
=0A=
Attila
=0A=
 
=0A=

=0A=
=0A= From: Francois Audet = [mailto:audet@nortel.com]
Sent: Wed 01/08/2007 = 16:55
To: Michael Thomas
Cc: IETF SIP = List
Subject: RE: [Sip] draft-ietf-sip-sips-05: 480 vs. = 418

=0A=
=0A=



> -----Original Message-----
> From: = Michael Thomas [mailto:mat@cisco.com]
> Sent: = Wednesday, August 01, 2007 04:25
> To: Rohan Mahy
> Cc: = Hadriel Kaplan; 'IETF SIP List'; Audet, Francois
> (SC100:3055); = Jon.Peterson@neustar.com; 'Paul Kyzivat'
> Subject: Re: [Sip] = draft-ietf-sip-sips-05: 480 vs. 418
>
> Question: as = currently defined can these two new warnings be
> reused by any = future method that is hopefully more secure
> than SIPS so that we = don't have to rehash this argument again?

The draft uses the = Warn-codes in 480. But it could be used
by other response (e.g., 424 = for location conveyance, if we
decide it makes sense). Or any other = response.

I'm assuming you mean "other URI schemes" instead of = "other
methods".

I currently have it as = follows:

   380  SIPS Not = Allowed

   381  SIPS Required

So, = obviously, they are tied to SIPS.

If we defined another URI = scheme (e.g., sipsec or whatever), then it
would probably need new = Warning Codes.

The alternative, which I presented in Chicago, = based on Attila's
proposal
(i.e., defining a new header that = specifically list the Allowed or
Required
URI schemes) was NOT = viewed favorably by the = group.




_______________________________________________=
Sip mailing list  https://www1.ietf.org= /mailman/listinfo/sip
This list is for NEW development of the = core SIP 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_01C7D4D8.0FE5A62F-- --===============0377653944== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0377653944==-- From sip-bounces@ietf.org Thu Aug 02 03:51:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGVSq-0000ks-IV; Thu, 02 Aug 2007 03:51:20 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IGVSo-0000de-KC for sip-confirm+ok@megatron.ietf.org; Thu, 02 Aug 2007 03:51:18 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGVSo-0000dR-8l for sip@ietf.org; Thu, 02 Aug 2007 03:51:18 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGVSn-0000Oq-Hb for sip@ietf.org; Thu, 02 Aug 2007 03:51:18 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l727oaO1025405; Thu, 2 Aug 2007 10:51:01 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Aug 2007 10:50:44 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Aug 2007 10:50:44 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: [Sip] WGLC comments on sip-outbound-10: further concerns for registrar Date: Thu, 2 Aug 2007 10:50:43 +0300 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F03EC99B1@esebe103.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] WGLC comments on sip-outbound-10: further concerns for registrar Thread-Index: AcfU2dPhL44o/l0WRX6z3EFCPvf1Og== From: To: , , X-OriginalArrivalTime: 02 Aug 2007 07:50:44.0020 (UTC) FILETIME=[D46C2F40:01C7D4D9] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, After cleaning up the Section 6 from some apparently redundant text I finally got my thoughts focused to some aspects of the registrar behaviour defined in=20 the remaining pieces of text. Here are the related comments: 6. Registrar Mechanisms Minor technical: "The registrar MUST be prepared to receive, simultaneously for the same AOR, some registrations that use instance-id and reg-id and some registrations that do not." Which specific use cases this is expected to cover: a) for the same AOR but from different devices; or b) for the same AOR even from one single device so that one REGISTER contains reg-id while another=20 does not; or c) for the same AOR from one single device so that a single REGISTER would contain multiple Contacts, some of them having reg-id while others not ? To me the cases b) and c) do not make sense so I suggest scoping this statement for case a) as follows: "The registrar MUST be prepared to receive, for the same AOR (from different devices),=20 some registrations that use instance-id and=20 reg-id and some registrations that do not." Minor technical: "The Registrar MAY be configured=20 with local policy to reject any registrations that do not include=20 the instance-id and reg-id, or with Path header field values that=20 do not contain the 'ob' parameter. If REGISTER request with mixed type of Contacts is allowed (case c above) some text has to be added how to handle such=20 REGISTER requests if the proxy has been configured a local=20 policy to reject registrations without reg-id or instance-id. Shall the registrar reject the whole request or only those contacts which are not according to the policy ? Minor technical: "The registrar MUST store all the Contact parameters=20 in the binding and SHOULD also store the time at which the=20 binding was last updated." "and SHOULD update the time the binding was last updated." Maybe this has been explained earlier, but I did not find from the document any reason why the registrar should store the time at which the binding was last updated. Why should it do that ? At least the time should not be needed for=20 replacing earlier registrations with newer ones, which is described in section 3.2 like this: "If the instance-id and reg-id are the same as a previous registration for the=20 same AOR, the registrar replaces the old Contact URI and=20 flow information." Related Nit for Section 3.2: As pointed out in my earlier email, in my opinion the storing the Contact URI is not necessary for Outbound so that the section 3.2 should say: "If the instance-id and reg-id are the same as a previous registration for the=20 same AOR, the registrar replaces the old binding and=20 flow information." Regards, Erkki=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Aug 02 04:50:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGWNo-0006Ve-4Q; Thu, 02 Aug 2007 04:50:12 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IGWNl-0006U8-6E for sip-confirm+ok@megatron.ietf.org; Thu, 02 Aug 2007 04:50:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGWNj-0006SZ-V9; Thu, 02 Aug 2007 04:50:08 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGWNj-0002JT-8y; Thu, 02 Aug 2007 04:50:07 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 455D52071D; Thu, 2 Aug 2007 10:50:06 +0200 (CEST) X-AuditID: c1b4fb3e-b0034bb0000007e1-aa-46b19abe2e83 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 1E4DB2133C; Thu, 2 Aug 2007 10:50:06 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Aug 2007 10:50:05 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Aug 2007 10:50:05 +0200 Message-ID: <46B19ABC.9080909@ericsson.com> Date: Thu, 02 Aug 2007 10:50:04 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: Dale.Worley@comcast.net Subject: Re: [Sip] Draft Liaision response to SG13 on Emergency Telecommunications References: <46AF5370.9020304@ericsson.com> <200708012031.l71KVZBv016565@dragon.ariadne.com> In-Reply-To: <200708012031.l71KVZBv016565@dragon.ariadne.com> Content-Type: text/plain; charset=UTF-8; format=flowed X-OriginalArrivalTime: 02 Aug 2007 08:50:05.0234 (UTC) FILETIME=[1F125120:01C7D4E2] X-Brightmail-Tracker: AAAAAA== Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: sip@ietf.org, sipping@ietf.org, tsvwg@ietf.org, nsis@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dale.Worley@comcast.net skrev: > This is a response to the liaison request made by Q3/13 regarding=20 >=20 > It looks like that should be "Q.3/13". >=20 > emergency telecommunications (REF: NGN-GSI/DOC =E2=80=93 60 Rev.2). = We would=20 > first like to apologize for failing to meet the deadline in respondi= ng.=20 > We do hope that the late answer still can be of some use. >=20 > The liaison request was made to the following working groups (WG):=20 > IEPREP, TSVWG, and NSIS. Since the request was sent the IEPREP WG ha= s=20 > concluded. In addition to the WGs from which information was request= ed,=20 > we also think that work performed by the SIP and SIPPING WG may be o= f=20 > relevance. >=20 > Pursuant to ITU-T Study Group 13 request for information on relevant= and=20 > related work in the IETF regarding emergency communications, we list= =20 > below RFCs and works in progress that we feel may be of interest to = your=20 > group. Some of the completed work is Informational, and others are = in=20 > the category of Standards Track. >=20 > Q.3/13 also requested that we keep you informed of any developments = in=20 > regards to emergency telecommunications. In those regards we would l= ike=20 > to make you aware that IETF mailing list participation and document=20 > information is free and open for anyone. Allowing participants in Q.= 3/13=20 >=20 > "... free and open to anyone, allowing ..." >=20 > to keep them selves informed of any developments. If Q.3/13 desire t= o=20 >=20 > "... themselves ..." (unless that's a US-ism) >=20 > get further information about specific ongoing work, then please sen= d a=20 > liaison request to the responsible WG for those specific documents. >=20 > The following list is divided under the associated working groups fr= om=20 > which the work has been done within the IETF. >=20 > Dale >=20 Thanks, incorporated. Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Aug 02 07:04:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGYTF-0007Qd-TX; Thu, 02 Aug 2007 07:03:57 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IGYTE-0007M3-J9 for sip-confirm+ok@megatron.ietf.org; Thu, 02 Aug 2007 07:03:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGYTD-0007Kj-8R for sip@ietf.org; Thu, 02 Aug 2007 07:03:55 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGYTC-0006Sf-As for sip@ietf.org; Thu, 02 Aug 2007 07:03:55 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l72B3KTM013489; Thu, 2 Aug 2007 14:03:40 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Aug 2007 14:03:06 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Aug 2007 14:03:06 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: [Sip] WGLC comments on sip-outbound-10: behaviour of the UA Date: Thu, 2 Aug 2007 14:03:05 +0300 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F03F03422@esebe103.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] WGLC comments on sip-outbound-10: behaviour of the UA Thread-Index: AcfUSRBhM+QAwevFQba6eLzLLwXhMAAjlP4g From: To: , , X-OriginalArrivalTime: 02 Aug 2007 11:03:06.0529 (UTC) FILETIME=[B44B4910:01C7D4F4] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, Here are my comments regarding to the behaviour of the UA as specified within SIP Outbound-10. I also hope that these would be my final comments for this WGLC. 4.1. Instance ID Creation Nit: I suggest renaming section 4.1 as "Instance ID Creation and Usage" as the section also discusses how to convey the ID in requests and responses. Minor technical: "To convey its instance-id in both requests and responses, the UA includes a "sip.instance" media feature tag as a UA characteristic [7] . As described in [7], this media feature tag will be encoded in the Contact header field as the "+sip.instance" Contact header field parameter. The value of this parameter MUST be a URN [8]. One case where a UA may not want to include the URN in the sip.instance media feature tag is when it is making an anonymous request or some other privacy concern requires that the UA not reveal its identity." It sounds odd to state that the value of sip.instance parameter MUST be URN but tell that there is a case when a UA would not want to include URN into that parameter. The last statement should instead tell that the UA is free not to include sip.instance media tag (but if it includes it, the value must always be URN). I suggest rephrasing=20 the paragraph like this: "To convey its instance-id in both requests and responses, the UA MAY add a "sip.instance" media feature tag as a UA characteristic [7]. As described in [7], the media feature tag will be encoded in the Contact header field as the "+sip.instance" Contact header field parameter. The value of this parameter MUST be a URN [8]. A UA MAY=20 decide not to add the sip.instance media feature tag e.g. when it is=20 making an anonymous request or some other privacy concern requires=20 that the UA not reveal its identity." 4.2. Registrations Nit: "These ordinary registration requests include a distinct reg-id parameter in the Contact header field." Propose to rewrite the statement like this: "REGISTER requests sent towards different URIs within the outbound-proxy-set MUST include the reg-id parameter into the Contact header field, with a distinct=20 reg-id value for each proxy." Major technical: "The UAC can situationally decide whether to request outbound behavior by including or omitting the 'reg-id' parameter. For example, imagine the outbound-proxy-set contains two proxies in different domains, EP1 and EP2. If an outbound-style registration succeeded for a flow through EP1, the UA might decide to include 'outbound' in its Require header field when registering with EP2, in order to insure consistency. Similarly, if the registration through EP1 did not support outbound, the UA might decide to omit the 'reg-id' parameter when registering with EP2." To me this paragraph sounds dangerous and I suggest removing it for the following reasons: - It is not specified anywhere what the registrar should do if it finds a REGISTER request to contain Require: outbound in a case where the reg-id will be ignored due to the proxy not supporting outbound. Intuitively the registrar should reject the REGISTER with an error response, but which one ? Using 420 Bad Extension is not according to RFC 3261, since the registrar supports Outbound but would just like to tell that it can not apply it since the first hop proxy did not support Outbound. More text is needed into the spec if a REGISTER request is allowed to use Require: Outbound. - If a registration through EP1 did not support outbound, then I would believe the UA should not try to register via EP2 at all. Otherwise the authoritative proxy could fork an incoming request to the a multihomed UA via both EP1 and EP2, which is not desirable. And if the UA is not multihomed then this kind of double registration without Outbound does not make sense. Major technical: "The UAC MAY examine successful registrations for the presence of an 'outbound' option-tag in a Supported header field value. Presence of this option-tag indicates that the registrar is compliant with this specification, and that any edge proxies which need to participate are also compliant." =20 As stated earlier, registrar will use Require header for this purpose. 9. Example Message Flow Minor technical: "The second registration in message 3 and 4 are similar other than the Call-ID has changed, the reg-id is 2, and the route is set to the secondary instead of the primary." "The registrations in message 13 and 14 are the same as message 1 and 2 other than the Call-ID and tags have changed. Because these messages will contain the same instance-id and reg-id as those in 1 and 2, this flow will partially supersede that for messages 1 and 2 and will be tried first by Primary." In the examples the UA is changing the Call-ID for every successive REGISTER request. What is the reason for the UA to do that ? The normative text for neither the UA nor the registrar suggest any that kind of behaviour. If the UA and registrar use GRUU this would cause the temporary GRUUs to be invalidated and I do not think the purpose of this example would be to implicate any such behavior for case when UA is using Outbound. Regards, Erkki=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Aug 02 09:08:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGaOF-00010a-TK; Thu, 02 Aug 2007 09:06:56 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IE2gl-0007gt-9E for sip-confirm+ok@megatron.ietf.org; Thu, 26 Jul 2007 08:43:31 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IE2gk-0007gl-W6 for sip@ietf.org; Thu, 26 Jul 2007 08:43:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE2cQ-0006e0-No for sip@ietf.org; Thu, 26 Jul 2007 08:39:02 -0400 Received: from wa-out-1112.google.com ([209.85.146.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IE2cP-0004CR-H7 for sip@ietf.org; Thu, 26 Jul 2007 08:39:02 -0400 Received: by wa-out-1112.google.com with SMTP id j37so342475waf for ; Thu, 26 Jul 2007 05:39:00 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=DVkpeAILH4yFI5GP3LBt955GTduqaTXfuwYxcl/R2Sc2ORaX0vWw/EvXZ4hxXwkvD6LvHa8Y0ksT4eD2h+al/ClzekQQg8B7BFGk97usjocW8S1lLFZD8G7KW+J3KTFaIT9TNmmWoU0tepl/FlmrDVaMhqmKrgtnGIE0afaaDoY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=JvkhWSE96PUGptrYIIKIeLkyYk3vFzqrk5Z3one9qCrpYb8sdD5fjCds/txf3eSUA2dN87ZB788edXkae36odEVk7SE9PaQVqzq9ZMC5yQn6HKkh7meE3C5G7Xk4Pwo/MI/5ib/tienwHYW8Hnr64pFsbTS8U2gowPKRwSV+6iU= Received: by 10.114.76.1 with SMTP id y1mr1661547waa.1185453540735; Thu, 26 Jul 2007 05:39:00 -0700 (PDT) Received: by 10.114.88.17 with HTTP; Thu, 26 Jul 2007 05:39:00 -0700 (PDT) Message-ID: Date: Thu, 26 Jul 2007 18:09:00 +0530 From: "Shrinivas Shetti" To: sip@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 X-TMDA-Confirmed: Thu, 26 Jul 2007 08:43:30 -0400 X-Mailman-Approved-At: Thu, 02 Aug 2007 09:06:54 -0400 Subject: [Sip] related to RFC3841 (caller prefs) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0530734656==" Errors-To: sip-bounces@ietf.org --===============0530734656== Content-Type: multipart/alternative; boundary="----=_Part_112519_27176631.1185453540701" ------=_Part_112519_27176631.1185453540701 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I have a dumb query. Does this spec forbid SIP response carry accept/reject-contact headers? Table in section 9 mentions its applicability to only requests. Does that mean responses MUST NOT carry this header? OR It is OK to carry these headers in response? There is no other statement I could find in spec related to this aspect. Thanks in advance, Shetti ------=_Part_112519_27176631.1185453540701 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
I have a dumb query.
 
Does this spec forbid SIP response carry accept/reject-contact headers?
 
Table in section 9 mentions its applicability to only requests. Does that mean responses MUST NOT carry this header?
 
OR
 
It is OK to carry these headers in response?
 
There is no other statement I could find in spec related to this aspect.
 
Thanks in advance,
Shetti
------=_Part_112519_27176631.1185453540701-- --===============0530734656== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0530734656==-- From sip-bounces@ietf.org Thu Aug 02 09:08:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGaOH-00010s-JQ; Thu, 02 Aug 2007 09:06:57 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IGSYV-0002z3-O4 for sip-confirm+ok@megatron.ietf.org; Thu, 02 Aug 2007 00:44:59 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IGSYV-0002yu-EW for sip@ietf.org; Thu, 02 Aug 2007 00:44:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGSVq-0000zS-8q for sip@ietf.org; Thu, 02 Aug 2007 00:42:14 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGSVo-0002k7-Th for sip@ietf.org; Thu, 02 Aug 2007 00:42:14 -0400 Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l724g587020280 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Aug 2007 23:42:05 -0500 (CDT) Received: from [127.0.0.1] (volkerh.lra.lucent.com [135.244.0.59]) by umail.lucent.com (8.13.8/TPES) with ESMTP id l724g2bm025129; Wed, 1 Aug 2007 23:42:05 -0500 (CDT) Message-ID: <46B16096.3070706@alcatel-lucent.com> Date: Thu, 02 Aug 2007 00:41:58 -0400 From: Volker Hilt User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "DRAGE, Keith \(Keith\)" References: <5D1A7985295922448D5550C94DE29180012C977E@DEEXC1U01.de.lucent.com> In-Reply-To: <5D1A7985295922448D5550C94DE29180012C977E@DEEXC1U01.de.lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9b281509fec590bb711c36d4c3ba4f74 X-TMDA-Confirmed: Thu, 02 Aug 2007 00:44:59 -0400 X-Mailman-Approved-At: Thu, 02 Aug 2007 09:06:54 -0400 Cc: IETF SIP List , Gonzalo.Camarillo@ericsson.com Subject: [Sip] Re: WGLC comments on draft-ietf-sip-session-policy-framework-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Keith, thanks much for reviewing this document. Comments inline. > > 1) Section 4.4.7.2: > > A proxy MAY add the "non- > cacheable" header field parameter to indicate that a UA MUST NOT > cache this policy server URI. > > You are either mixing a proxy requirement and a UA requirement in the > same sentence here, or we have one instance two many of RFC 2119 > language. Either way, what we have is the wrong of writing it. > I've split this up into two separate sentences. > 2) For reference [4] config-framework, I am missing any RFC 2119 > language round it. I think we are saying "provides the only way of" > rather than "provides one means of" therefore I would have expected a > "MUST implement". > I agree. I've added RFC 2119 language to make the implementation of the config-framework a MUST. Another change is that a UA supporting session-independent policies MUST attempt to retrieve these policies from i) the local network and ii) the SIP service provider domain. This was SHOULD before. > 3) Section 4.4: > > If we show the table of support in methods, I would prefer we show all > the current methods, and therefore show all the "-". There are other SIP > documents you can use as a template. > I've expanded the table to include all current methods. I've changed the requirements for the presence of a header field from optional to conditional since the headers need to be used/understood under certain conditions. > 4) Update reference [7] from RFC 2327 to RFC 4566. There does not > seem to be any need to reference the older version. > Done. > 5) With regard to reference [8] RFC 3264 the text: > > A UAC compliant to this specification MUST include a Supported header > field with the option tag "policy" into all requests that can > initiate an offer/answer exchange [8] (e.g. INVITE, UPDATE and PRACK > requests). > > Makes this a normative reference rather than an informative reference. > Done. > 6) One of the requirements of RFC 4485 (Guidelines to SIP authors) > is to clearly structure the requirements relating to each entity. > > A) I see a mixture of requirements for UAC and policy server in > section 3.2, and some of the requirements apply to both. I've added subsections "UAC Behavior" and "UAS Behavior" and moved the paragraphs to the respective subsections. > B) In section 4.4.7.1 can you move the RFC 2119 requirement to the > appropriate procedures section. > C) The same applies for section 4.4.7.2. I've removed the RFC 2119 language from 4.4.7.x since it was already contained the procedures section above. > D) Can you explain why section 3.2 and section 4.5 are so widely > separated? > 3.2 covers session-independent policies whereas section 4.5 covers session-specific policies. > 7) Section 3.2: > > The session-independent policies contained in a > notification MUST represent a complete session-independent policy. > Deltas to previous policies or partial policies are not supported. > > Seems to be primarily a sending requirement (i.e. for the policy > server). Please write "The policy server MUST..." and if there is a > separate receiver (UAC) requirement, then draft a separate statement. > Done. > 8) There are two ways of doing the requirements for security. One > is to put all the RFC 2119 language relating to security in the security > considerations section, which is apparently what this draft does. The > other is to integrate these requirements in the procedures and reflect > on the security support given by these requirements in the security > considerations section. I prefer the latter - it makes it harder for an > implementor to ignore the security requirements. > I agree. However, in this particular case, I would prefer to keep it as it is. This draft is a framework and refers to other specifications, e.g., for the subscriptions to policies. For this reason, it seems appropriate to cover the security aspects in one place. I've added a sentence to the protocol description that recommends the use of TLS to protect the Policy-Contact header (previously this was only in the security considerations). > 9) I don't like the semantics of the option tag registration. I > would prefer to relate this to support of particular procedures, rather > than support of the headers. Support of headers is a bit nebulous - a > proxy supports it if it passes it on transparently. A UA supports it if > it renders the contents to a user. > I've updated the option tag registration accordingly. > 10) Can you put the appendixes at the end of the document, thereby > bringing forward the references and author details. > Done for references. rfc2xml seems to automatically place author details at the end. I've made the changes proposed in the NITS below. Thanks much! Volker > NITS: > > 1) For all response code usage, use the form "488 (Not Acceptable > Here) response" rather than any abbreviated form on all occurrences. > > 2) There seems to be a significant usage of "it" in statements with > RFC 2119 language, as in > > It SHOULD store > policy server URIs in this list even if they are marked as "non- > cacheable" > > Please use the name of entity even if it was included in the conditional > at the start of the sentence, or in a previous sentence. > > 3) In all references made from the text, rather than statements of > the form > > (e.g. according to [6]) > > Can we use either: > > (e.g. according to RFC 3261 [6]) > > Or > > (e.g. according to [RFC3261]) > > To save having to refer to the list at the end of the document. > > 4) Please deal with idnits as identified below: > > -------------------------------------------------------------------- > > idnits 2.04.09 > > tmp/draft-ietf-sip-session-policy-framework-01.txt: > > Checking boilerplate required by RFC 3978 and 3979, updated by RFC > 4748: > > ------------------------------------------------------------------------ > ---- > > No issues found here. > > Checking nits according to > http://www.ietf.org/ietf/1id-guidelines.txt: > > ------------------------------------------------------------------------ > ---- > > == No 'Intended status' indicated for this document; assuming Proposed > Standard > > > Checking nits according to http://www.ietf.org/ID-Checklist.html: > > ------------------------------------------------------------------------ > ---- > > No issues found here. > > Miscellaneous warnings: > > ------------------------------------------------------------------------ > ---- > > == Line 952 has weird spacing: '... where prox...' > > == The document seems to lack the recommended RFC 2119 boilerplate, > even if > it appears to use RFC 2119 keywords -- however, there's a paragraph > with > a matching beginning. Boilerplate error? > > (The document does seem to have the reference to RFC 2119 which the > ID-Checklist requires). > > Checking references for intended status: Proposed Standard > > ------------------------------------------------------------------------ > ---- > > (See RFC 3967 for information about using normative references to > lower-maturity documents in RFCs) > -- Possible downref: Normative reference to a draft: ref. '2' (No > intended > status found in state file of draft-ietf-sipping-policy-package) > > == Outdated reference: A later version (-04) exists of > draft-ietf-sipping-media-policy-dataset-02 > > -- Possible downref: Normative reference to a draft: ref. '3' (No > intended > status found in state file of > draft-ietf-sipping-media-policy-dataset) > > == Outdated reference: A later version (-12) exists of > draft-ietf-sipping-config-framework-10 > > -- Obsolete informational reference (is this intentional?): RFC 2327 > (ref. > '7') (Obsoleted by RFC 4566) > > ------------------------------------------------------------------------ > ----- > > 5) I suspect you will need to update the address for Jonathan > Rosenberg. > > 6) Section 1: > > However, experience has shown that there is a need for SIP > intermediaries to impact aspects of a session. For example, SIP may > be used in a wireless network, which has limited resources for media > traffic. > > Change "may" --> "can" > > Also same paragraph: > > Similarly, a > network provider may have a service level agreement with a user that > defines the set of media types a user can use. > > Change "may" --> "can" > > Also section 1: > > Domains often enforce the session policies they have in place. For > example, a domain might have a policy that disallows the use of video > and may enforce this policy by dropping all packets that contain a > video encoding. > > Change "may" --> "can" > > And same paragraph > > This may > lead to a malfunctioning of devices that is incomprehensible to the > user. > > Change "may" --> "can" > > 7) Section 3: > > Session-independent policies are policies that are created > independent of a session and generally apply to all sessions a user > agent is setting up. They typically remain stable for a longer > period of time and apply to any session set up while they are valid. > However, session-independent policies may also change over time. For > example, a policy that defines a bandwidth limit for a user may > change during the day, defining a lower limit during peak hours and > allow more bandwidth off-peak. > > Change "may" --> "can" twice. > > 8) Section 3.1 > > A SIP UA may receive session-independent policies from one or more > policy servers. In a typical configuration, a UA receives session- > independent policies from a policy server in the access or local > network domain (i.e. the domain from which the UA receives IP > service) and possibly the home network domain (i.e. the domain the UA > registers at). The local network may have policies that support the > access network infrastructure. For example, in a wireless network > where bandwidth is scarce, a provider may restrict the bandwidth > available to an individual user. The home network may have policies > that are needed to support services or policies that reflect the > service level agreement with the user. Thus, in most cases, a UA > will receive session-independent policies from one or two policy > servers. > > Change "may" --> "can" three times. > > 2. The policy server selects the policies that apply to this user > agent. The policy server may have general policies that apply to > all users or maintain separate policies for each individual user. > The selected policies are returned to the user agent. > 3. The policy server may update the policies, for example, when > network conditions change. > > Change "may" --> "can" twice. > > 9) Section 3.2: > > A change in the policy may be triggered, for > example, by a change in the network status, by the change in the time > of day or by an update of the service level agreement with the > customer. > > Change "may" --> "can" > > 10) Section 4: > > Session-specific policies are policies that are created specifically > for one particular session of a UA. Thus, session-specific policies > will typically be different for different sessions. The session- > specific policies for a session may change during the course of the > session. For example, a user may run out of credit during a session, > which will cause the network to disallow the transmission all media > streams from this point on. > > Change "may" --> "can" twice. > > 11) Section 4.1: > > The policy server is a separate logical entity that may be physically > co-located with the proxy. The role of the policy server is to > deliver session policies to UAs. The policy server receives session > information from the UA, uses this information to determine the > policies that apply to the session and returns these policies to the > UA. The mechanism for generating policies (i.e. making policy > decisions) is outside of the scope of this specification. A policy > server may, for example, query an external entity to get policies or > it may directly incorporate a policy decision point and generate > policies locally. > > Change "may" --> "can" three times. > > And in the same section: > > A UA receives the URI of a policy server from a proxy. It uses this > URI to contact the policy server. It provides information about the > current session to the policy server and receives session policies in > response. The UA may also receive policy updates from the policy > server during the course of a session. > > Change "may" --> "can" > > A network may have a policy enforcement infrastructure in place. > However, this specification does not make any assumptions about the > enforcement of session policies and the mechanisms defined here are > orthogonal a policy enforcement infrastructure. Their goal is to > provide a mechanism to convey session information to a policy server > and to return the policies that apply to a session to the UA. > > Change "may" --> "can" > > 12) Section 4.2: > > In many cases, the mechanism for session-specific policies will be > used to disclose session information and return session policies. > However, some scenarios may only involve the disclosure of session > information to a network intermediary. If an intermediary does not > intend to return a policy, it can simply accept the session as it was > proposed. Similarly, some session-specific policies only apply to > the offer (and therefore only require the disclosure of the offer) > whereas others apply to offer and answer. Both types of policies are > supported by session-specific policy mechanism. > > Change "may" --> "can" > > 13) Section 4.4.1: > > A UAC may receive a 488 response that contains a Policy-Contact > header field. > > Change "may" --> "can" > > The token is an opaque > string the UAC may have received from the policy server after > contacting it. > > Change "may" --> "can" > > Note: it has been proposed to use the Policy-Id header to provide > a hint for a proxy that the UAC has actually contacted the policy > server. This usage also requires the policy server to return a > token to the UA. In addition, the policy server needs to share > valid tokens with the proxy. After receiving a request with a > Policy-Id header, the proxy can determine if the token in the > Policy-Id header is valid. If it is valid, the proxy knows that > the UA has contacted the policy server for this session. However, > it is important to note that this token does not provide any proof > that the UA has actually used the policies it has received from > the policy server. A malicious UA may simply contact the policy > server, discard all policies it receives but still use the token > in the Policy-Id header. > > Change "may" --> "can" > Delete: "it is important to note that". > > In some cases, a request may traverse multiple domains with session- > policies in place. Each of these domains may return a 488 response > containing a policy server URI. > > Change "may" --> "can" twice. > > A UA may decide to change the session description of a session and to > initiate subsequent offer/answer exchanges (e.g. using INVITE, UPDATE > or PRACK requests) to re-negotiate the session description. > > Change "may" --> "can" > > 14) Section 4.4.2: > > If the local policy server URI is present in a Policy-Id header value > of a request, then the proxy MUST NOT reject the request as described > above (it may still reject the request for other reasons). > > Change "may" --> "can" > > 15) Section 4.4.3: > > A UAS may receive an INVITE, UPDATE or PRACK request (or another > request that can initiate offer/answer exchanges), which contains a > Policy-Contact header filed with a list of policy server URIs. > > Change "may" --> "can" > > A UAS may receive a token from a policy server via the policy > channel. Since the UAS does not create a Policy-ID header, it can > simply ignore this token. > > Change "may" --> "can" > > 16) Section 4.4.4: > > A UAC may frequently need to contact the policy server in the local > domain before sending a request. To avoid the retransmission of the > local policy server URI for each new request, a UA SHOULD maintain a > cache that contains the URI of the local policy server. A UA may > receive this URI in a Policy-Contact header of a request or a 488 > response. The UA may also receive the local policy server URI > through configuration, for example, via the configuration framework > [4]. If a UA has received a local policy server URI through > configuration and receives another local policy server URI in a > Policy-Contact header, it SHOULD overwrite the configured URI with > the most recent one received in a Policy-Contact header. > > Change "may" --> "can" three times. > > The UA SHOULD NOT cache policy server URIs it has received from > proxies outside of the local domain. These policy servers may not be > relevant for subsequent sessions, which may go to a different > destination, traversing different domains. > > Change "may not" to "need not" > Change "may" --> "can" > > The UA MUST NOT cache tokens it may receive from a policy server. A > token is only valid for one request. > > Change "may" --> "can" > > 17) Section 4.4.6: > > Note: this assumes that the policy server can always respond > immediately to a policy request and does not require manual > intervention to create a policy. This will be the case for most > policy servers. If, however, a policy server cannot respond with > a policy right away, it may return a policy that temporarily > denies the session and update this policy as the actual policy > decision becomes available. A delay in the response from the > policy server to the UA would delay the transmission of the ACK > and could trigger retransmissions of the INVITE response (also see > the recommendations for Flow I in [9]). > > Change "may" --> "can" > > A UA MUST inform the policy server when a session is terminated via > the policy channel. This enables a policy server to free all > resources it may have allocated for this session. A policy server > can indicate via the policy channel that it does not need to be > contacted at the end of a session. In this case, the UA SHOULD NOT > inform the policy server about the termination of the session. > > Change "may have" --> "has" > > 18) Section 4.4.7.1: > > The value of a Policy-Id header consists of a policy server URI. A > Policy-Id header value may have an optional token parameter. The > token parameter contains a token the UA may receive from the policy > server. > > Change "may have" --> "can have" > Change "may receive" --> "received" > > 19) Section 4.5: > > If the policy update causes a change in the session > description of a session, the UA may need to re-negotiate the > modified session description with its peer UA, for example, using a > re-INVITE or UPDATE request. > > Change "may need" to "needs". > > 20 Section 5: > > Session policies can significantly change the behavior of a user > agent and can be used by an attacker to compromise a user agent. For > example, session policies can be used to prevent a user agent from > successfully establishing a session (e.g. by setting the available > bandwidth to zero). Such a policy can be submitted to the user agent > during a session, which may cause the UA to terminate the session. > > Change "may cause" to "causes". > > A user agent transmits session information to a policy server for > session-specific policies. This session information may contain > sensitive data the user may not want an eavesdropper or an > unauthorized policy server to see. For example, the session > information may contain the encryption keys for media streams. Vice > versa, session policies may also contain sensitive information about > the network or service level agreements the service provider may not > want to disclose to an eavesdropper or an unauthorized user agent. > > Change "may contain" to "can contain" twice > Change "may not" to "does not" twice > Change "may also" to "can also" > > This would impede the rendezvous between UA and policy server and, > since the UA would not contact the policy server, may prevent a UA > from setting up a session. > > Change "may" to "can" > > Policy servers SHOULD authenticate UAs to protect the information > that is contained in a session policy. However, a policy server may > also frequently encounter UAs it cannot authenticate. > > Change "may" to "can" _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Aug 02 09:08:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGaOG-00010l-VE; Thu, 02 Aug 2007 09:06:56 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IERiS-00068l-FU for sip-confirm+ok@megatron.ietf.org; Fri, 27 Jul 2007 11:26:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IERiS-00068d-5w for sip@ietf.org; Fri, 27 Jul 2007 11:26:56 -0400 Received: from nz-out-0506.google.com ([64.233.162.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IERiR-0006rT-UP for sip@ietf.org; Fri, 27 Jul 2007 11:26:56 -0400 Received: by nz-out-0506.google.com with SMTP id n1so739883nzf for ; Fri, 27 Jul 2007 08:26:55 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer:sender; b=IktWY3LhOkA4K5Cq771m6i476KOAWpD0YNwWT2UWu0qTxdZRTJGnrQbAkH+cpKuZkHQD9+UWReCBPSEEwcKfGhR/H8XVpfWT38tepKjRiApdizYdGfdXlqhHE1HjBwfpi0uj2VV9M0IvPk3RKwYSaS6uCW8dZE4HmWgYo1747e0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer:sender; b=dfCVaGMvyqZnEXmDArQGkoVZoUa0P7UFvYJV9sP7HWEzTOvDSqFOFYKv8IF3vvT7NHwCNtjEMhvrxK8rw5Q5ftZVLJQId4JpOm1GO8XW6YEhgspkOd8D8Ym/3W1Ii7AVUaeZOSDeD28LQqLhpCL4kUDAYEcOdnEe2Nnx7bwFGBw= Received: by 10.114.59.1 with SMTP id h1mr3053225waa.1185550013181; Fri, 27 Jul 2007 08:26:53 -0700 (PDT) Received: from ?130.129.16.139? ( [130.129.16.139]) by mx.google.com with ESMTPS id m40sm4473310waf.2007.07.27.08.26.49 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 27 Jul 2007 08:26:52 -0700 (PDT) In-Reply-To: <46AA09F1.6010401@cisco.com> References: <1ECE0EB50388174790F9694F77522CCF11697776@zrc2hxm0.corp.nortel.com> <247B95AF-63F6-432D-9D6E-AF083AF9C525@nostrum.com> <46A92B7C.7080202@cisco.com> <1ECE0EB50388174790F9694F77522CCF116E20B5@zrc2hxm0.corp.nortel.com> <46AA09F1.6010401@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Alan Hawrylyshen Subject: Re: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 Date: Fri, 27 Jul 2007 10:26:40 -0500 To: Kyzivat Paul , Mahy Rohan X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-Mailman-Approved-At: Thu, 02 Aug 2007 09:06:54 -0400 Cc: IETF SIP List , Francois Audet , Jon.Peterson@neustar.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On 27-Jul-2007, at 10:06 , Paul Kyzivat wrote: > I understand that if the user entered a sips URI then it should be > the user that must decide to downgrade. But if the user didn't know > whether to use sip or sips in the first place, and the UA decides > to try sips first then I see no problem in the UA having a policy > that causes it to downgrade. I was under the impression (based on meeting discussion) that : 1 - the downgrade was undesirable because it reveals (possibly) information about the targeted party in the clear, and; 2 - The 480 with a Warning header was an option to provide automata- friendly indication of the failure reason. Alan Hawrylyshen a l a n a t p o l y p h a s e d o t 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 sip-bounces@ietf.org Thu Aug 02 09:08:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGaOF-00010a-TK; Thu, 02 Aug 2007 09:06:56 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IE2gl-0007gt-9E for sip-confirm+ok@megatron.ietf.org; Thu, 26 Jul 2007 08:43:31 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IE2gk-0007gl-W6 for sip@ietf.org; Thu, 26 Jul 2007 08:43:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE2cQ-0006e0-No for sip@ietf.org; Thu, 26 Jul 2007 08:39:02 -0400 Received: from wa-out-1112.google.com ([209.85.146.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IE2cP-0004CR-H7 for sip@ietf.org; Thu, 26 Jul 2007 08:39:02 -0400 Received: by wa-out-1112.google.com with SMTP id j37so342475waf for ; Thu, 26 Jul 2007 05:39:00 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=DVkpeAILH4yFI5GP3LBt955GTduqaTXfuwYxcl/R2Sc2ORaX0vWw/EvXZ4hxXwkvD6LvHa8Y0ksT4eD2h+al/ClzekQQg8B7BFGk97usjocW8S1lLFZD8G7KW+J3KTFaIT9TNmmWoU0tepl/FlmrDVaMhqmKrgtnGIE0afaaDoY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=JvkhWSE96PUGptrYIIKIeLkyYk3vFzqrk5Z3one9qCrpYb8sdD5fjCds/txf3eSUA2dN87ZB788edXkae36odEVk7SE9PaQVqzq9ZMC5yQn6HKkh7meE3C5G7Xk4Pwo/MI/5ib/tienwHYW8Hnr64pFsbTS8U2gowPKRwSV+6iU= Received: by 10.114.76.1 with SMTP id y1mr1661547waa.1185453540735; Thu, 26 Jul 2007 05:39:00 -0700 (PDT) Received: by 10.114.88.17 with HTTP; Thu, 26 Jul 2007 05:39:00 -0700 (PDT) Message-ID: Date: Thu, 26 Jul 2007 18:09:00 +0530 From: "Shrinivas Shetti" To: sip@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 X-TMDA-Confirmed: Thu, 26 Jul 2007 08:43:30 -0400 X-Mailman-Approved-At: Thu, 02 Aug 2007 09:06:54 -0400 Subject: [Sip] related to RFC3841 (caller prefs) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0530734656==" Errors-To: sip-bounces@ietf.org --===============0530734656== Content-Type: multipart/alternative; boundary="----=_Part_112519_27176631.1185453540701" ------=_Part_112519_27176631.1185453540701 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I have a dumb query. Does this spec forbid SIP response carry accept/reject-contact headers? Table in section 9 mentions its applicability to only requests. Does that mean responses MUST NOT carry this header? OR It is OK to carry these headers in response? There is no other statement I could find in spec related to this aspect. Thanks in advance, Shetti ------=_Part_112519_27176631.1185453540701 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
I have a dumb query.
 
Does this spec forbid SIP response carry accept/reject-contact headers?
 
Table in section 9 mentions its applicability to only requests. Does that mean responses MUST NOT carry this header?
 
OR
 
It is OK to carry these headers in response?
 
There is no other statement I could find in spec related to this aspect.
 
Thanks in advance,
Shetti
------=_Part_112519_27176631.1185453540701-- --===============0530734656== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0530734656==-- From sip-bounces@ietf.org Thu Aug 02 09:08:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGaOH-00010s-JQ; Thu, 02 Aug 2007 09:06:57 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IGSYV-0002z3-O4 for sip-confirm+ok@megatron.ietf.org; Thu, 02 Aug 2007 00:44:59 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IGSYV-0002yu-EW for sip@ietf.org; Thu, 02 Aug 2007 00:44:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGSVq-0000zS-8q for sip@ietf.org; Thu, 02 Aug 2007 00:42:14 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGSVo-0002k7-Th for sip@ietf.org; Thu, 02 Aug 2007 00:42:14 -0400 Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l724g587020280 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Aug 2007 23:42:05 -0500 (CDT) Received: from [127.0.0.1] (volkerh.lra.lucent.com [135.244.0.59]) by umail.lucent.com (8.13.8/TPES) with ESMTP id l724g2bm025129; Wed, 1 Aug 2007 23:42:05 -0500 (CDT) Message-ID: <46B16096.3070706@alcatel-lucent.com> Date: Thu, 02 Aug 2007 00:41:58 -0400 From: Volker Hilt User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "DRAGE, Keith \(Keith\)" References: <5D1A7985295922448D5550C94DE29180012C977E@DEEXC1U01.de.lucent.com> In-Reply-To: <5D1A7985295922448D5550C94DE29180012C977E@DEEXC1U01.de.lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9b281509fec590bb711c36d4c3ba4f74 X-TMDA-Confirmed: Thu, 02 Aug 2007 00:44:59 -0400 X-Mailman-Approved-At: Thu, 02 Aug 2007 09:06:54 -0400 Cc: IETF SIP List , Gonzalo.Camarillo@ericsson.com Subject: [Sip] Re: WGLC comments on draft-ietf-sip-session-policy-framework-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Keith, thanks much for reviewing this document. Comments inline. > > 1) Section 4.4.7.2: > > A proxy MAY add the "non- > cacheable" header field parameter to indicate that a UA MUST NOT > cache this policy server URI. > > You are either mixing a proxy requirement and a UA requirement in the > same sentence here, or we have one instance two many of RFC 2119 > language. Either way, what we have is the wrong of writing it. > I've split this up into two separate sentences. > 2) For reference [4] config-framework, I am missing any RFC 2119 > language round it. I think we are saying "provides the only way of" > rather than "provides one means of" therefore I would have expected a > "MUST implement". > I agree. I've added RFC 2119 language to make the implementation of the config-framework a MUST. Another change is that a UA supporting session-independent policies MUST attempt to retrieve these policies from i) the local network and ii) the SIP service provider domain. This was SHOULD before. > 3) Section 4.4: > > If we show the table of support in methods, I would prefer we show all > the current methods, and therefore show all the "-". There are other SIP > documents you can use as a template. > I've expanded the table to include all current methods. I've changed the requirements for the presence of a header field from optional to conditional since the headers need to be used/understood under certain conditions. > 4) Update reference [7] from RFC 2327 to RFC 4566. There does not > seem to be any need to reference the older version. > Done. > 5) With regard to reference [8] RFC 3264 the text: > > A UAC compliant to this specification MUST include a Supported header > field with the option tag "policy" into all requests that can > initiate an offer/answer exchange [8] (e.g. INVITE, UPDATE and PRACK > requests). > > Makes this a normative reference rather than an informative reference. > Done. > 6) One of the requirements of RFC 4485 (Guidelines to SIP authors) > is to clearly structure the requirements relating to each entity. > > A) I see a mixture of requirements for UAC and policy server in > section 3.2, and some of the requirements apply to both. I've added subsections "UAC Behavior" and "UAS Behavior" and moved the paragraphs to the respective subsections. > B) In section 4.4.7.1 can you move the RFC 2119 requirement to the > appropriate procedures section. > C) The same applies for section 4.4.7.2. I've removed the RFC 2119 language from 4.4.7.x since it was already contained the procedures section above. > D) Can you explain why section 3.2 and section 4.5 are so widely > separated? > 3.2 covers session-independent policies whereas section 4.5 covers session-specific policies. > 7) Section 3.2: > > The session-independent policies contained in a > notification MUST represent a complete session-independent policy. > Deltas to previous policies or partial policies are not supported. > > Seems to be primarily a sending requirement (i.e. for the policy > server). Please write "The policy server MUST..." and if there is a > separate receiver (UAC) requirement, then draft a separate statement. > Done. > 8) There are two ways of doing the requirements for security. One > is to put all the RFC 2119 language relating to security in the security > considerations section, which is apparently what this draft does. The > other is to integrate these requirements in the procedures and reflect > on the security support given by these requirements in the security > considerations section. I prefer the latter - it makes it harder for an > implementor to ignore the security requirements. > I agree. However, in this particular case, I would prefer to keep it as it is. This draft is a framework and refers to other specifications, e.g., for the subscriptions to policies. For this reason, it seems appropriate to cover the security aspects in one place. I've added a sentence to the protocol description that recommends the use of TLS to protect the Policy-Contact header (previously this was only in the security considerations). > 9) I don't like the semantics of the option tag registration. I > would prefer to relate this to support of particular procedures, rather > than support of the headers. Support of headers is a bit nebulous - a > proxy supports it if it passes it on transparently. A UA supports it if > it renders the contents to a user. > I've updated the option tag registration accordingly. > 10) Can you put the appendixes at the end of the document, thereby > bringing forward the references and author details. > Done for references. rfc2xml seems to automatically place author details at the end. I've made the changes proposed in the NITS below. Thanks much! Volker > NITS: > > 1) For all response code usage, use the form "488 (Not Acceptable > Here) response" rather than any abbreviated form on all occurrences. > > 2) There seems to be a significant usage of "it" in statements with > RFC 2119 language, as in > > It SHOULD store > policy server URIs in this list even if they are marked as "non- > cacheable" > > Please use the name of entity even if it was included in the conditional > at the start of the sentence, or in a previous sentence. > > 3) In all references made from the text, rather than statements of > the form > > (e.g. according to [6]) > > Can we use either: > > (e.g. according to RFC 3261 [6]) > > Or > > (e.g. according to [RFC3261]) > > To save having to refer to the list at the end of the document. > > 4) Please deal with idnits as identified below: > > -------------------------------------------------------------------- > > idnits 2.04.09 > > tmp/draft-ietf-sip-session-policy-framework-01.txt: > > Checking boilerplate required by RFC 3978 and 3979, updated by RFC > 4748: > > ------------------------------------------------------------------------ > ---- > > No issues found here. > > Checking nits according to > http://www.ietf.org/ietf/1id-guidelines.txt: > > ------------------------------------------------------------------------ > ---- > > == No 'Intended status' indicated for this document; assuming Proposed > Standard > > > Checking nits according to http://www.ietf.org/ID-Checklist.html: > > ------------------------------------------------------------------------ > ---- > > No issues found here. > > Miscellaneous warnings: > > ------------------------------------------------------------------------ > ---- > > == Line 952 has weird spacing: '... where prox...' > > == The document seems to lack the recommended RFC 2119 boilerplate, > even if > it appears to use RFC 2119 keywords -- however, there's a paragraph > with > a matching beginning. Boilerplate error? > > (The document does seem to have the reference to RFC 2119 which the > ID-Checklist requires). > > Checking references for intended status: Proposed Standard > > ------------------------------------------------------------------------ > ---- > > (See RFC 3967 for information about using normative references to > lower-maturity documents in RFCs) > -- Possible downref: Normative reference to a draft: ref. '2' (No > intended > status found in state file of draft-ietf-sipping-policy-package) > > == Outdated reference: A later version (-04) exists of > draft-ietf-sipping-media-policy-dataset-02 > > -- Possible downref: Normative reference to a draft: ref. '3' (No > intended > status found in state file of > draft-ietf-sipping-media-policy-dataset) > > == Outdated reference: A later version (-12) exists of > draft-ietf-sipping-config-framework-10 > > -- Obsolete informational reference (is this intentional?): RFC 2327 > (ref. > '7') (Obsoleted by RFC 4566) > > ------------------------------------------------------------------------ > ----- > > 5) I suspect you will need to update the address for Jonathan > Rosenberg. > > 6) Section 1: > > However, experience has shown that there is a need for SIP > intermediaries to impact aspects of a session. For example, SIP may > be used in a wireless network, which has limited resources for media > traffic. > > Change "may" --> "can" > > Also same paragraph: > > Similarly, a > network provider may have a service level agreement with a user that > defines the set of media types a user can use. > > Change "may" --> "can" > > Also section 1: > > Domains often enforce the session policies they have in place. For > example, a domain might have a policy that disallows the use of video > and may enforce this policy by dropping all packets that contain a > video encoding. > > Change "may" --> "can" > > And same paragraph > > This may > lead to a malfunctioning of devices that is incomprehensible to the > user. > > Change "may" --> "can" > > 7) Section 3: > > Session-independent poFrom sip-bounces@ietf.org Thu Aug 02 09:08:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGaOF-00010a-TK; Thu, 02 Aug 2007 09:06:56 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IE2gl-0007gt-9E for sip-confirm+ok@megatron.ietf.org; Thu, 26 Jul 2007 08:43:31 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IE2gk-0007gl-W6 for sip@ietf.org; Thu, 26 Jul 2007 08:43:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE2cQ-0006e0-No for sip@ietf.org; Thu, 26 Jul 2007 08:39:02 -0400 Received: from wa-out-1112.google.com ([209.85.146.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IE2cP-0004CR-H7 for sip@ietf.org; Thu, 26 Jul 2007 08:39:02 -0400 Received: by wa-out-1112.google.com with SMTP id j37so342475waf for ; Thu, 26 Jul 2007 05:39:00 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=DVkpeAILH4yFI5GP3LBt955GTduqaTXfuwYxcl/R2Sc2ORaX0vWw/EvXZ4hxXwkvD6LvHa8Y0ksT4eD2h+al/ClzekQQg8B7BFGk97usjocW8S1lLFZD8G7KW+J3KTFaIT9TNmmWoU0tepl/FlmrDVaMhqmKrgtnGIE0afaaDoY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=JvkhWSE96PUGptrYIIKIeLkyYk3vFzqrk5Z3one9qCrpYb8sdD5fjCds/txf3eSUA2dN87ZB788edXkae36odEVk7SE9PaQVqzq9ZMC5yQn6HKkh7meE3C5G7Xk4Pwo/MI/5ib/tienwHYW8Hnr64pFsbTS8U2gowPKRwSV+6iU= Received: by 10.114.76.1 with SMTP id y1mr1661547waa.1185453540735; Thu, 26 Jul 2007 05:39:00 -0700 (PDT) Received: by 10.114.88.17 with HTTP; Thu, 26 Jul 2007 05:39:00 -0700 (PDT) Message-ID: Date: Thu, 26 Jul 2007 18:09:00 +0530 From: "Shrinivas Shetti" To: sip@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 X-TMDA-Confirmed: Thu, 26 Jul 2007 08:43:30 -0400 X-Mailman-Approved-At: Thu, 02 Aug 2007 09:06:54 -0400 Subject: [Sip] related to RFC3841 (caller prefs) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0530734656==" Errors-To: sip-bounces@ietf.org --===============0530734656== Content-Type: multipart/alternative; boundary="----=_Part_112519_27176631.1185453540701" ------=_Part_112519_27176631.1185453540701 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I have a dumb query. Does this spec forbid SIP response carry accept/reject-contact headers? Table in section 9 mentions its applicability to only requests. Does that mean responses MUST NOT carry this header? OR It is OK to carry these headers in response? There is no other statement I could find in spec related to this aspect. Thanks in advance, Shetti ------=_Part_112519_27176631.1185453540701 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
I have a dumb query.
 
Does this spec forbid SIP response carry accept/reject-contact headers?
 
Table in section 9 mentions its applicability to only requests. Does that mean responses MUST NOT carry this header?
 
OR
 
It is OK to carry these headers in response?
 
There is no other statement I could find in spec related to this aspect.
 licies are policies that are created > independent of a session and generally apply to all sessions a user > agent is setting up. They typically remain stable for a longer > period of time and apply to any session set up while they are valid. > However, session-independent policies may also change over time. For > example, a policy that defines a bandwidth limit for a user may > change during the day, defining a lower limit during peak hours and > allow more bandwidth off-peak. > > Change "may" --> "can" twice. > > 8) Section 3.1 > > A SIP UA may receive session-independent policies from one or more > policy servers. In a typical configuration, a UA receives session- > independent policies from a policy server in the access or local > network domain (i.e. the domain from which the UA receives IP > service) and possibly the home network domain (i.e. the domain the UA > registers at). The local network may have policies that support the > access network infrastructure. For example, in a wireless network > where bandwidth is scarce, a provider may restrict the bandwidth > available to an individual user. The home network may have policies > that are needed to support services or policies that reflect the > service level agreement with the user. Thus, in most cases, a UA > will receive session-independent policies from one or two policy > servers. > > Change "may" --> "can" three times. > > 2. The policy server selects the policies that apply to this user > agent. The policy server may have general policies that apply to > all users or maintain separate policies for each individual user. > The selected policies are returned to the user agent. > 3. The policy server may update the policies, for example, when > network conditions change. > > Change "may" --> "can" twice. > > 9) Section 3.2: > > A change in the policy may be triggered, for > example, by a change in the network status, by the change in the time > of day or by an update of the service level agreement with the > customer. > > Change "may" --> "can" > > 10) Section 4: > > Session-specific policies are policies that are created specifically > for one particular session of a UA. Thus, session-specific policies > will typically be different for different sessions. The session- > specific policies for a session may change during the course of the > session. For example, a user may run out of credit during a session, > which will cause the network to disallow the transmission all media > streams from this point on. > > Change "may" --> "can" twice. > > 11) Section 4.1: > > The policy server is a separate logical entity that may be physically > co-located with the proxy. The role of the policy server is to > deliver session policies to UAs. The policy server receives session > information from the UA, uses this information to determine the > policies that apply to the session and returns these policies to the > UA. The mechanism for generating policies (i.e. making policy > decisions) is outside of the scope of this specification. A policy > server may, for example, query an external entity to get policies or > it may directly incorporate a policy decision point and generate > policies locally. > > Change "may" --> "can" three times. > > And in the same section: > > A UA receives the URI of a policy server from a proxy. It uses this > URI to contact the policy server. It provides information about the > current session to the policy server and receives session policies in > response. The UA may also receive policy updates from the policy > server during the course of a session. > > Change "may" --> "can" > > A network may have a policy enforcement infrastructure in place. > However, this specification does not make any assumptions about the > enforcement of session policies and the mechanisms defined here are > orthogonal a policy enforcement infrastruc;
Thanks in advance,
Shetti
------=_Part_112519_27176631.1185453540701-- --===============0530734656== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0530734656==-- From sip-bounces@ietf.org Thu Aug 02 09:08:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGaOH-00010s-JQ; Thu, 02 Aug 2007 09:06:57 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IGSYV-0002z3-O4 for sip-confirm+ok@megatron.ietf.org; Thu, 02 Aug 2007 00:44:59 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IGSYV-0002yu-EW for sip@ietf.org; Thu, 02 Aug 2007 00:44:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGSVq-0000zS-8q for sip@ietf.org; Thu, 02 Aug 2007 00:42:14 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGSVo-0002k7-Th for sip@ietf.org; Thu, 02 Aug 2007 00:42:14 -0400 Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l724g587020280 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Aug 2007 23:42:05 -0500 (CDT) Received: from [127.0.0.1] (volkerh.lra.lucent.com [135.244.0.59]) by umail.lucent.com (8.13.8/TPES) with ESMTP id l724g2bm025129; Wed, 1 Aug 2007 23:42:05 -0500 (CDT) Message-ID: <46B16096.3070706@alcatel-lucent.com> Date: Thu, 02 Aug 2007 00:41:58 -0400 From: Volker Hilt User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "DRAGE, Keith \(Keith\)" References: <5D1A7985295922448D5550C94DE29180012C977E@DEEXC1U01.de.lucent.com> In-Reply-To: <5D1A7985295922448D5550C94DE29180012C977E@DEEXC1U01.de.lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9b281509fec590bb711c36d4c3ba4f74 X-TMDA-Confirmed: Thu, 02 Aug 2007 00:44:59 -0400 X-Mailman-Approved-At: Thu, 02 Aug 2007 09:06:54 -0400 Cc: IETF SIP List , Gonzalo.Camarillo@ericsson.com Subject: [Sip] Re: WGLC comments on draft-ietf-sip-session-policy-framework-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Keith, thanks much for reviewing this document. Comments inline. > > 1) Section 4.4.7.2: > > A proxy MAY add the "non- > cacheable" header field parameter to indicate that a UA MUST NOT > cache this policy server URI. > > You are either mixing a proxy requirement and a UA requirement in the > same sentence here, or we have one instance two many of RFC 2119 > language. Either way, what we have is the wrong of writing it. > I've split this up into two separate sentences. > 2) For reference [4] config-framework, I am missing any RFC 2119 > language round it. I think we are saying "provides the only way of" > rather than "provides one means of" therefore I would have expected a > "MUST implement". > I agree. I've added RFC 2119 language to make the implementation of the config-framework a MUST. Another change is that a UA supporting sesture. Their goal is to > provide a mechanism to convey session information to a policy server > and to return the policies that apply to a session to the UA. > > Change "may" --> "can" > > 12) Section 4.2: > > In many cases, the mechanism for session-specific policies will be > used to disclose session information and return session policies. > However, some scenarios may only involve the disclosure of session > information to a network intermediary. If an intermediary does not > intend to return a policy, it can simply accept the session as it was > proposed. Similarly, some session-specific policies only apply to > the offer (and therefore only require the disclosure of the offer) > whereas others apply to offer and answer. Both types of policies are > supported by session-specific policy mechanism. > > Change "may" --> "can" > > 13) Section 4.4.1: > > A UAC may receive a 488 response that contains a Policy-Contact > header field. > > Change "may" --> "can" > > The token is an opaque > string the UAC may have received from the policy server after > contacting it. > > Change "may" --> "can" > > Note: it has been proposed to use the Policy-Id header to provide > a hint for a proxy that the UAC has actually contacted the policy > server. This usage also requires the policy server to return a > token to the UA. In addition, the policy server needs to share > valid tokens with the proxy. After receiving a request with a > Policy-Id header, the proxy can determine if the token in the > Policy-Id header is valid. If it is valid, the proxy knows that > the UA has contacted the policy server for this session. However, > it is important to note that this token does not provide any proof > that the UA has actually used the policies it has received from > the policy server. A malicious UA may simply contact the policy > server, discard all policies it receives but still use the token > in the Policy-Id header. > > Change "may" --> "can" > Delete: "it is important to note that". > > In some cases, a request may traverse multiple domains with session- > policies in place. Each of these domains may return a 488 response > containing a policy server URI. > > Change "may" --> "can" twice. > > A UA may decide to change the session description of a session and to > initiate subsequent offer/answer exchanges (e.g. using INVITE, UPDATE > or PRACK requests) to re-negotiate the session description. > > Change "may" --> "can" > > 14) Section 4.4.2: > > If the local policy server URI is present in a Policy-Id header value > of a request, then the proxy MUST NOT reject the request as described > above (it may still reject the request for other reasons). > > Change "may" --> "can" > > 15) Section 4.4.3: > > A UAS may receive an INVITE, UPDATE or PRACK request (or another > request that can initiate offer/answer exchanges), which contains a > Policy-Contact header filed with a list of policy server URIs. > > Change "may" --> "can" > > A UAS may receive a token from a policy server via the policy > channel. Since the UAS does not create a Policy-ID header, it can > simply ignore this token. > > Change "may" --> "can" > > 16) Section 4.4.4: > > A UAC may frequently need to contact the policy server in the local > domain before sending a request. To avoid the retransmission of the > local policy server URI for each new request, a UA SHOULD maintain a > cache that contains the URI of the local policy server. A UA may > receive this URI in a Policy-Contact header of a request or a 488 > response. The UA may also receive the local policy server URI > through configuration, for example, via the configuration framework > [4]. If a UA has received a local policy server URI through > configuration and receives another local policy server URI in a > Policy-Contact header, it SHOULD overwrite the configured URI with > sion-independent policies MUST attempt to retrieve these policies from i) the local network and ii) the SIP service provider domain. This was SHOULD before. > 3) Section 4.4: > > If we show the table of support in methods, I would prefer we show all > the current methods, and therefore show all the "-". There are other SIP > documents you can use as a template. > I've expanded the table to include all current methods. I've changed the requirements for the presence of a header field from optional to conditional since the headers need to be used/understood under certain conditions. > 4) Update reference [7] from RFC 2327 to RFC 4566. There does not > seem to be any need to reference the older version. > Done. > 5) With regard to reference [8] RFC 3264 the text: > > A UAC compliant to this specification MUST include a Supported header > field with the option tag "policy" into all requests that can > initiate an offer/answer exchange [8] (e.g. INVITE, UPDATE and PRACK > requests). > > Makes this a normative reference rather than an informative reference. > Done. > 6) One of the requirements of RFC 4485 (Guidelines to SIP authors) > is to clearly structure the requirements relating to each entity. > > A) I see a mixture of requirements for UAC and policy server in > section 3.2, and some of the requirements apply to both. I've added subsections "UAC Behavior" and "UAS Behavior" and moved the paragraphs to the respective subsections. > B) In section 4.4.7.1 can you move the RFC 2119 requirement to the > appropriate procedures section. > C) The same applies for section 4.4.7.2. I've removed the RFC 2119 language from 4.4.7.x since it was already contained the procedures section above. > D) Can you explain why section 3.2 and section 4.5 are so widely > separated? > 3.2 covers session-independent policies whereas section 4.5 covers session-specific policies. > 7) Section 3.2: > > The session-independent policies contained in a > notification MUST represent a complete session-independent policy. > Deltas to previous policies or partial policies are not supported. > > Seems to be primarily a sending requirement (i.e. for the policy > server). Please write "The policy server MUST..." and if there is a > separate receiver (UAC) requirement, then draft a separate statement. > Done. > 8) There are two ways of doing the requirements for security. One > is to put all the RFC 2119 language relating to security in the security > considerations section, which is apparently what this draft does. The > other is to integrate these requirements in the procedures and reflect > on the security support given by these requirements in the security > considerations section. I prefer the latter - it makes it harder for an > implementor to ignore the security requirements. > I agree. However, in this particular case, I would prefer to keep it as it is. This draft is a framework and refers to other specifications, e.g., for the subscriptions to policies. For this reason, it seems appropriate to cover the security aspects in one place. I've added a sentence to the protocol description that recommends the use of TLS to protect the Policy-Contact header (previously this was only in the security considerations). > 9) I don't like the semantics of the option tag registration. I > would prefer to relate this to support of particular procedures, rather > than support of the headers. Support of headers is a bit nebulous - a > proxy supports it if it passes it on transparently. A UA supports it if > it renders the contents to a user. > I've updated the option tag registration accordingly. > 10) Can you put the appendixes at the end of the document, thereby > bringing forward the references and author details. > Done for references. rfc2xml seems to automatically place author details at the end. I've made the changes proposed in the NITS below. Thanks much! Volker > NITS: > > 1) For all response code usage, use the form "488 (Not Acceptable > Here) response" rather than any abbreviated the most recent one received in a Policy-Contact header. > > Change "may" --> "can" three times. > > The UA SHOULD NOT cache policy server URIs it has received from > proxies outside of the local domain. These policy servers may not be > relevant for subsequent sessions, which may go to a different > destination, traversing different domains. > > Change "may not" to "need not" > Change "may" --> "can" > > The UA MUST NOT cache tokens it may receive from a policy server. A > token is only valid for one request. > > Change "may" --> "can" > > 17) Section 4.4.6: > > Note: this assumes that the policy server can always respond > immediately to a policy request and does not require manual > intervention to create a policy. This will be the case for most > policy servers. If, however, a policy server cannot respond with > a policy right away, it may return a policy that temporarily > denies the session and update this policy as the actual policy > decision becomes available. A delay in the response from the > policy server to the UA would delay the transmission of the ACK > and could trigger retransmissions of the INVITE response (also see > the recommendations for Flow I in [9]). > > Change "may" --> "can" > > A UA MUST inform the policy server when a session is terminated via > the policy channel. This enables a policy server to free all > resources it may have allocated for this session. A policy server > can indicate via the policy channel that it does not need to be > contacted at the end of a session. In this case, the UA SHOULD NOT > inform the policy server about the termination of the session. > > Change "may have" --> "has" > > 18) Section 4.4.7.1: > > The value of a Policy-Id header consists of a policy server URI. A > Policy-Id header value may have an optional token parameter. The > token parameter contains a token the UA may receive from the policy > server. > > Change "may have" --> "can have" > Change "may receive" --> "received" > > 19) Section 4.5: > > If the policy update causes a change in the session > description of a session, the UA may need to re-negotiate the > modified session description with its peer UA, for example, using a > re-INVITE or UPDATE request. > > Change "may need" to "needs". > > 20 Section 5: > > Session policies can significantly change the behavior of a user > agent and can be used by an attacker to compromise a user agent. For > example, session policies can be used to prevent a user agent from > successfully establishing a session (e.g. by setting the available > bandwidth to zero). Such a policy can be submitted to the user agent > during a session, which may cause the UA to terminate the session. > > Change "may cause" to "causes". > > A user agent transmits session information to a policy server for > session-specific policies. This session information may contain > sensitive data the user may not want an eavesdropper or an > unauthorized policy server to see. For example, the session > information may contain the encryption keys for media streams. Vice > versa, session policies may also contain sensitive information about > the network or service level agreements the service provider may not > want to disclose to an eavesdropper or an unauthorized user agent. > > Change "may contain" to "can contain" twice > Change "may not" to "does not" twice > Change "may also" to "can also" > > This would impede the rendezvous between UA and policy server and, > since the UA would not contact the policy server, may prevent a UA > from setting up a session. > > Change "may" to "can" > > Policy servers SHOULD authenticate UAs to protect the information > that is contained in a session policy. However, a policy server may > also frequently encounter UAs it cannot authenticate. > > Change "may" to "can" _______________________________________________ Sip mailing lform on all occurrences. > > 2) There seems to be a significant usage of "it" in statements with > RFC 2119 language, as in > > It SHOULD store > policy server URIs in this list even if they are marked as "non- > cacheable" > > Please use the name of entity even if it was included in the conditional > at the start of the sentence, or in a previous sentence. > > 3) In all references made from the text, rather than statements of > the form > > (e.g. according to [6]) > > Can we use either: > > (e.g. according to RFC 3261 [6]) > > Or > > (e.g. according to [RFC3261]) > > To save having to refer to the list at the end of the document. > > 4) Please deal with idnits as identified below: > > -------------------------------------------------------------------- > > idnits 2.04.09 > > tmp/draft-ietf-sip-session-policy-framework-01.txt: > > Checking boilerplate required by RFC 3978 and 3979, updated by RFC > 4748: > > ------------------------------------------------------------------------ > ---- > > No issues found here. > > Checking nits according to > http://www.ietf.org/ietf/1id-guidelines.txt: > > ------------------------------------------------------------------------ > ---- > > == No 'Intended status' indicated for this document; assuming Proposed > Standard > > > Checking nits according to http://www.ietf.org/ID-Checklist.html: > > ------------------------------------------------------------------------ > ---- > > No issues found here. > > Miscellaneous warnings: > > ------------------------------------------------------------------------ > ---- > > == Line 952 has weird spacing: '... where prox...' > > == The document seems to lack the recommended RFC 2119 boilerplate, > even if > it appears to use RFC 2119 keywords -- however, there's a paragraph > with > a matching beginning. Boilerplate error? > > (The document does seem to have the reference to RFC 2119 which the > ID-Checklist requires). > > Checking references for intended status: Proposed Standard > > ------------------------------------------------------------------------ > ---- > > (See RFC 3967 for information about using normative references to > lower-maturity documents in RFCs) > -- Possible downref: Normative reference to a draft: ref. '2' (No > intended > status found in state file of draft-ietf-sipping-policy-package) > > == Outdated reference: A later version (-04) exists of > draft-ietf-sipping-media-policy-dataset-02 > > -- Possible downref: Normative reference to a draft: ref. '3' (No > intended > status found in state file of > draft-ietf-sipping-media-policy-dataset) > > == Outdated reference: A later version (-12) exists of > draft-ietf-sipping-config-framework-10 > > -- Obsolete informational reference (is this intentional?): RFC 2327 > (ref. > '7') (Obsoleted by RFC 4566) > > ------------------------------------------------------------------------ > ----- > > 5) I suspect you will need to update the address for Jonathan > Rosenberg. > > 6) Section 1: > > However, experience has shown that there is a need for SIP > intermediaries to impact aspects of a session. For example, SIP may > be used in a wireless network, which has limited resources for media > traffic. > > Change "may" --> "can" > > Also same paragraph: > > Similarly, a > network provider may have a service level agreement with a user that > defines the set of media types a user can use. > > Change "may" --> "can" > > Also section 1: > > Domains often enforce the session policies they have in place. For > example, a domain might have a policy that disallows the use of video > and may enforce this policy by dropping all packets that contain a > video encoding. > > Change "may" --> "can" > > And same paragraph > > This may > lead to a malfunctioning of devices that is incomprehensible to the > user. > > Change "may" --> "can" > > 7) Section 3: > > Session-independent poist https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Aug 02 09:08:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGaOG-00010l-VE; Thu, 02 Aug 2007 09:06:56 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IERiS-00068l-FU for sip-confirm+ok@megatron.ietf.org; Fri, 27 Jul 2007 11:26:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IERiS-00068d-5w for sip@ietf.org; Fri, 27 Jul 2007 11:26:56 -0400 Received: from nz-out-0506.google.com ([64.233.162.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IERiR-0006rT-UP for sip@ietf.org; Fri, 27 Jul 2007 11:26:56 -0400 Received: by nz-out-0506.google.com with SMTP id n1so739883nzf for ; Fri, 27 Jul 2007 08:26:55 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer:sender; b=IktWY3LhOkA4K5Cq771m6i476KOAWpD0YNwWT2UWu0qTxdZRTJGnrQbAkH+cpKuZkHQD9+UWReCBPSEEwcKfGhR/H8XVpfWT38tepKjRiApdizYdGfdXlqhHE1HjBwfpi0uj2VV9M0IvPk3RKwYSaS6uCW8dZE4HmWgYo1747e0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer:sender; b=dfCVaGMvyqZnEXmDArQGkoVZoUa0P7UFvYJV9sP7HWEzTOvDSqFOFYKv8IF3vvT7NHwCNtjEMhvrxK8rw5Q5ftZVLJQId4JpOm1GO8XW6YEhgspkOd8D8Ym/3W1Ii7AVUaeZOSDeD28LQqLhpCL4kUDAYEcOdnEe2Nnx7bwFGBw= Received: by 10.114.59.1 with SMTP id h1mr3053225waa.1185550013181; Fri, 27 Jul 2007 08:26:53 -0700 (PDT) Received: from ?130.129.16.139? ( [130.129.16.139]) by mx.google.com with ESMTPS id m40sm4473310waf.2007.07.27.08.26.49 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 27 Jul 2007 08:26:52 -0700 (PDT) In-Reply-To: <46AA09F1.6010401@cisco.com> References: <1ECE0EB50388174790F9694F77522CCF11697776@zrc2hxm0.corp.nortel.com> <247B95AF-63F6-432D-9D6E-AF083AF9C525@nostrum.com> <46A92B7C.7080202@cisco.com> <1ECE0EB50388174790F9694F77522CCF116E20B5@zrc2hxm0.corp.nortel.com> <46AA09F1.6010401@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Alan Hawrylyshen Subject: Re: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 Date: Fri, 27 Jul 2007 10:26:40 -0500 To: Kyzivat Paul , Mahy Rohan X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-Mailman-Approved-At: Thu, 02 Aug 2007 09:06:54 -0400 Cc: IETF SIP List , Francois Audet , Jon.Peterson@neustar.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On 27-Jul-2007, at 10:06 , Paul Kyzivat wrote: > I understand that if the user entered a sips URI then it should be > the user that must decide to downgrade. But if the user didn't know > whether to use sip or sips in the first place, and the UA decides > to try sips first then I see no problem in the UA having a policy > that causes it to downgrade. I was under the impression (based on meeting discussion) that : 1 - the downgrade walicies are policies that are created > independent of a session and generally apply to all sessions a user > agent is setting up. They typically remain stable for a longer > period of time and apply to any session set up while they are valid. > However, session-independent policies may also change over time. For > example, a policy that defines a bandwidth limit for a user may > change during the day, defining a lower limit during peak hours and > allow more bandwidth off-peak. > > Change "may" --> "can" twice. > > 8) Section 3.1 > > A SIP UA may receive session-independent policies from one or more > policy servers. In a typical configuration, a UA receives session- > independent policies from a policy server in the access or local > network domain (i.e. the domain from which the UA receives IP > service) and possibly the home network domain (i.e. the domain the UA > registers at). The local network may have policies that support the > access network infrastructure. For example, in a wireless network > where bandwidth is scarce, a provider may restrict the bandwidth > available to an individual user. The home network may have policies > that are needed to support services or policies that reflect the > service level agreement with the user. Thus, in most cases, a UA > will receive session-independent policies from one or two policy > servers. > > Change "may" --> "can" three times. > > 2. The policy server selects the policies that apply to this user > agent. The policy server may have general policies that apply to > all users or maintain separate policies for each individual user. > The selected policies are returned to the user agent. > 3. The policy server may update the policies, for example, when > network conditions change. > > Change "may" --> "can" twice. > > 9) Section 3.2: > > A change in the policy may be triggered, for > example, by a change in the network status, by the change in the time > of day or by an update of the service level agreement with the > customer. > > Change "may" --> "can" > > 10) Section 4: > > Session-specific policies are policies that are created specifically > for one particular session of a UA. Thus, session-specific policies > will typically be different for different sessions. The session- > specific policies for a session may change during the course of the > session. For example, a user may run out of credit during a session, > which will cause the network to disallow the transmission all media > streams from this point on. > > Change "may" --> "can" twice. > > 11) Section 4.1: > > The policy server is a separate logical entity that may be physically > co-located with the proxy. The role of the policy server is to > deliver session policies to UAs. The policy server receives session > information from the UA, uses this information to determine the > policies that apply to the session and returns these policies to the > UA. The mechanism for generating policies (i.e. making policy > decisions) is outside of the scope of this specification. A policy > server may, for example, query an external entity to get policies or > it may directly incorporate a policy decision point and generate > policies locally. > > Change "may" --> "can" three times. > > And in the same section: > > A UA receives the URI of a policy server from a proxy. It uses this > URI to contact the policy server. It provides information about the > current session to the policy server and receives session policies in > response. The UA may also receive policy updates from the policy > server during the course of a session. > > Change "may" --> "can" > > A network may have a policy enforcement infrastructure in place. > However, this specification does not make any assumptions about the > enforcement of session policies and the mechanisms defined here are > orthogonal a policy enforcement infrastrucs undesirable because it reveals (possibly) information about the targeted party in the clear, and; 2 - The 480 with a Warning header was an option to provide automata- friendly indication of the failure reason. Alan Hawrylyshen a l a n a t p o l y p h a s e d o t 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 ture. Their goal is to > provide a mechanism to convey session information to a policy server > and to return the policies that apply to a session to the UA. > > Change "may" --> "can" > > 12) Section 4.2: > > In many cases, the mechanism for session-specific policies will be > used to disclose session information and return session policies. > However, some scenarios may only involve the disclosure of session > information to a network intermediary. If an intermediary does not > intend to return a policy, it can simply accept the session as it was > proposed. Similarly, some session-specific policies only apply to > the offer (and therefore only require the disclosure of the offer) > whereas others apply to offer and answer. Both types of policies are > supported by session-specific policy mechanism. > > Change "may" --> "can" > > 13) Section 4.4.1: > > A UAC may receive a 488 response that contains a Policy-Contact > header field. > > Change "may" --> "can" > > The token is an opaque > string the UAC may have received from the policy server after > contacting it. > > Change "may" --> "can" > > Note: it has been proposed to use the Policy-Id header to provide > a hint for a proxy that the UAC has actually contacted the policy > server. This usage also requires the policy server to return a > token to the UA. In addition, the policy server needs to share > valid tokens with the proxy. After receiving a request with a > Policy-Id header, the proxy can determine if the token in the > Policy-Id header is valid. If it is valid, the proxy knows that > the UA has contacted the policy server for this session. However, > it is important to note that this token does not provide any proof > that the UA has actually used the policies it has received from > the policy server. A malicious UA may simply contact the policy > server, discard all policies it receives but still use the token > in the Policy-Id header. > > Change "may" --> "can" > Delete: "it is important to note that". > > In some cases, a request may traverse multiple domains with session- > policies in place. Each of these domains may return a 488 response > containing a policy server URI. > > Change "may" --> "can" twice. > > A UA may decide to change the session description of a session and to > initiate subsequent offer/answer exchanges (e.g. using INVITE, UPDATE > or PRACK requests) to re-negotiate the session description. > > Change "may" --> "can" > > 14) Section 4.4.2: > > If the local policy server URI is present in a Policy-Id header value > of a request, then the proxy MUST NOT reject the request as described > above (it may still reject the request for other reasons). > > Change "may" --> "can" > > 15) Section 4.4.3: > > A UAS may receive an INVITE, UPDATE or PRACK request (or another > request that can initiate offer/answer exchanges), which contains a > Policy-Contact header filed with a list of policy server URIs. > > Change "may" --> "can" > > A UAS may receive a token from a policy server via the policy > channel. Since the UAS does not create a Policy-ID header, it can > simply ignore this token. > > Change "may" --> "can" > > 16) Section 4.4.4: > > A UAC may frequently need to contact the policy server in the local > domain before sending a request. To avoid the retransmission of the > local policy server URI for each new request, a UA SHOULD maintain a > cache that contains the URI of the local policy server. A UA may > receive this URI in a Policy-Contact header of a request or a 488 > response. The UA may also receive the local policy server URI > through configuration, for example, via the configuration framework > [4]. If a UA has received a local policy server URI through > configuration and receives another local policy server URI in a > Policy-Contact header, it SHOULD overwrite the configured URI with > the most recent one received in a Policy-Contact header. > > Change "may" --> "can" three times. > > The UA SHOULD NOT cache policy server URIs it has received from > proxies outside of the local domain. These policy servers may not be > relevant for subsequent sessions, which may go to a different > destination, traversing different domains. > > Change "may not" to "need not" > Change "may" --> "can" > > The UA MUST NOT cache tokens it may receive from a policy server. A > token is only valid for one request. > > Change "may" --> "can" > > 17) Section 4.4.6: > > Note: this assumes that the policy server can always respond > immediately to a policy request and does not require manual > intervention to create a policy. This will be the case for most > policy servers. If, however, a policy server cannot respond with > a policy right away, it may return a policy that temporarily > denies the session and update this policy as the actual policy > decision becomes available. A delay in the response from the > policy server to the UA would delay the transmission of the ACK > and could trigger retransmissions of the INVITE response (also see > the recommendations for Flow I in [9]). > > Change "may" --> "can" > > A UA MUST inform the policy server when a session is terminated via > the policy channel. This enables a policy server to free all > resources it may have allocated for this session. A policy server > can indicate via the policy channel that it does not need to be > contacted at the end of a session. In this case, the UA SHOULD NOT > inform the policy server about the termination of the session. > > Change "may have" --> "has" > > 18) Section 4.4.7.1: > > The value of a Policy-Id header consists of a policy server URI. A > Policy-Id header value may have an optional token parameter. The > token parameter contains a token the UA may receive from the policy > server. > > Change "may have" --> "can have" > Change "may receive" --> "received" > > 19) Section 4.5: > > If the policy update causes a change in the session > description of a session, the UA may need to re-negotiate the > modified session description with its peer UA, for example, using a > re-INVITE or UPDATE request. > > Change "may need" to "needs". > > 20 Section 5: > > Session policies can significantly change the behavior of a user > agent and can be used by an attacker to compromise a user agent. For > example, session policies can be used to prevent a user agent from > successfully establishing a session (e.g. by setting the available > bandwidth to zero). Such a policy can be submitted to the user agent > during a session, which may cause the UA to terminate the session. > > Change "may cause" to "causes". > > A user agent transmits session information to a policy server for > session-specific policies. This session information may contain > sensitive data the user may not want an eavesdropper or an > unauthorized policy server to see. For example, the session > information may contain the encryption keys for media streams. Vice > versa, session policies may also contain sensitive information about > the network or service level agreements the service provider may not > want to disclose to an eavesdropper or an unauthorized user agent. > > Change "may contain" to "can contain" twice > Change "may not" to "does not" twice > Change "may also" to "can also" > > This would impede the rendezvous between UA and policy server and, > since the UA would not contact the policy server, may prevent a UA > from setting up a session. > > Change "may" to "can" > > Policy servers SHOULD authenticate UAs to protect the information > that is contained in a session policy. However, a policy server may > also frequently encounter UAs it cannot authenticate. > > Change "may" to "can" _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Aug 02 09:08:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGaOG-00010l-VE; Thu, 02 Aug 2007 09:06:56 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IERiS-00068l-FU for sip-confirm+ok@megatron.ietf.org; Fri, 27 Jul 2007 11:26:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IERiS-00068d-5w for sip@ietf.org; Fri, 27 Jul 2007 11:26:56 -0400 Received: from nz-out-0506.google.com ([64.233.162.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IERiR-0006rT-UP for sip@ietf.org; Fri, 27 Jul 2007 11:26:56 -0400 Received: by nz-out-0506.google.com with SMTP id n1so739883nzf for ; Fri, 27 Jul 2007 08:26:55 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer:sender; b=IktWY3LhOkA4K5Cq771m6i476KOAWpD0YNwWT2UWu0qTxdZRTJGnrQbAkH+cpKuZkHQD9+UWReCBPSEEwcKfGhR/H8XVpfWT38tepKjRiApdizYdGfdXlqhHE1HjBwfpi0uj2VV9M0IvPk3RKwYSaS6uCW8dZE4HmWgYo1747e0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer:sender; b=dfCVaGMvyqZnEXmDArQGkoVZoUa0P7UFvYJV9sP7HWEzTOvDSqFOFYKv8IF3vvT7NHwCNtjEMhvrxK8rw5Q5ftZVLJQId4JpOm1GO8XW6YEhgspkOd8D8Ym/3W1Ii7AVUaeZOSDeD28LQqLhpCL4kUDAYEcOdnEe2Nnx7bwFGBw= Received: by 10.114.59.1 with SMTP id h1mr3053225waa.1185550013181; Fri, 27 Jul 2007 08:26:53 -0700 (PDT) Received: from ?130.129.16.139? ( [130.129.16.139]) by mx.google.com with ESMTPS id m40sm4473310waf.2007.07.27.08.26.49 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 27 Jul 2007 08:26:52 -0700 (PDT) In-Reply-To: <46AA09F1.6010401@cisco.com> References: <1ECE0EB50388174790F9694F77522CCF11697776@zrc2hxm0.corp.nortel.com> <247B95AF-63F6-432D-9D6E-AF083AF9C525@nostrum.com> <46A92B7C.7080202@cisco.com> <1ECE0EB50388174790F9694F77522CCF116E20B5@zrc2hxm0.corp.nortel.com> <46AA09F1.6010401@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Alan Hawrylyshen Subject: Re: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 Date: Fri, 27 Jul 2007 10:26:40 -0500 To: Kyzivat Paul , Mahy Rohan X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-Mailman-Approved-At: Thu, 02 Aug 2007 09:06:54 -0400 Cc: IETF SIP List , Francois Audet , Jon.Peterson@neustar.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On 27-Jul-2007, at 10:06 , Paul Kyzivat wrote: > I understand that if the user entered a sips URI then it should be > the user that must decide to downgrade. But if the user didn't know > whether to use sip or sips in the first place, and the UA decides > to try sips first then I see no problem in the UA having a policy > that causes it to downgrade. I was under the impression (based on meeting discussion) that : 1 - the downgrade was undesirable because it reveals (possibly) information about the targeted party in the clear, and; 2 - The 480 with a Warning header was an option to provide automata- friendly indication of the failure reason. Alan Hawrylyshen a l a n a t p o l y p h a s e d o t 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 sip-bounces@ietf.org Thu Aug 02 09:59:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGbCY-0006pw-C2; Thu, 02 Aug 2007 09:58:54 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IGbCW-0006pl-TL for sip-confirm+ok@megatron.ietf.org; Thu, 02 Aug 2007 09:58:52 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGbCW-0006pd-Ib for sip@ietf.org; Thu, 02 Aug 2007 09:58:52 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGbCV-00023U-SU for sip@ietf.org; Thu, 02 Aug 2007 09:58:52 -0400 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l72DwhMx029877 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 2 Aug 2007 06:58:43 -0700 Received: from [76.102.94.28] (vpn-10-50-0-111.qualcomm.com [10.50.0.111]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l72Dwb53011432; Thu, 2 Aug 2007 06:58:37 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <004701c7d4a9$b87bc870$7c6c460a@china.huawei.com> References: <004701c7d4a9$b87bc870$7c6c460a@china.huawei.com> Date: Thu, 2 Aug 2007 06:58:37 -0700 To: Qian Sun , "'Eric Burger'" , "'Dean Willis'" From: Ted Hardie Subject: RE: Content-Disposition in multiparts WAS (Re: [Sip] Draft slides forbody (MIME) handling) Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: 'sip' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 10:06 AM +0800 8/2/07, Qian Sun wrote: >Hi, Eric > >An AD bodypart should be marked "advertisement" if it is intended to be displayed in a non-disturbed/non-confusing way. >The "advertisement" Disposition Type would be a kind of display manner between "Inline" and "Attachment". >For example, a client could display advertisement in a place different from the content window. > >Cheers, >Qian I agree with Eric that "advertisement" is not a disposition; it is a statement about who is getting paid. "inline-subordinate" would be a disposition that said "put this inline, but don't let it block anything with a regular "inline" tag. You seem to want people to infer what disposition to give based on the "advertisement" status. As you have seen, some are inferring that they can cheerfully junk the content. I think there are a number of problems even with something like "inline-subordinate" (what do you do when you are using text-to-speach rendering for blind users?), but I think your focus should be on describing what the software should do rather than on the commercial relationships. Lastly, I'll point out that introducing a disposition like "advertisement" or "inline-subordinate" has an impact on the MIME folks in general, and a more general discussion would be needed before things progressed. regards, Ted Hardie >-----Original Message----- >From: Eric Burger [mailto:eburger@bea.com] >Sent: Wednesday, August 01, 2007 11:42 PM >To: Dean Willis; Qian Sun >Cc: 'sip' >Subject: Re: Content-Disposition in multiparts WAS (Re: [Sip] Draft slides forbody (MIME) handling) > >Content-Disposition="advertisement" would never pass MIME review. It is not >a disposition. > >Give it up and move on to more important stuff, like running code :-) > > >On 7/31/07 8:37 AM, "Dean Willis" wrote: > >> >> On Jul 30, 2007, at 8:36 PM, Qian Sun wrote: >> >>> Hi, Dean >>> >>> Sorry for late response. Do you mean "advertisement" content always >>> is needed to 'render'? So a single content disposition >>> "advertisement" is enough. >> >> Well, I'm wondering if advertisements have any other need than >> "render". If not, why not just use "render"? >> >> If we define an "advertisement" content disposition, we might as well >> call it "ignore", in which case there's hardly any point in sending >> it to start with, right? >> >> Although I must admit I'm intrigued by the prospect of getting >> advertisers to self-label stuff so that it can be discarded as >> efficiently as possible. >> >>> In addition, some content body (e.g. Geolocation or advertisement) >>> may be inserted or modified by intermediary. Could we specify a >>> common way for indicating the source of inserted content body? For >>> example, define a new MIME header: Content-Insertedby. A B2BUA may >>> insert a content body including AD like this: >>> >>> Content-Type: text/plain >>> Content-Disposition: advertisement >>> Content-Insertedby: AD-Agent >> >> I'm sure there has been discussion of this in geopriv, but I don't >> recall the details. I suspect there have been concerns about >> mismatches between the "source" and the "information". >> >> -- >> 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 > > >Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Aug 02 11:16:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGcNT-0002N4-MW; Thu, 02 Aug 2007 11:14:15 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IGcNR-0002Mw-SB for sip-confirm+ok@megatron.ietf.org; Thu, 02 Aug 2007 11:14:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGcNR-0002Mn-HX for sip@ietf.org; Thu, 02 Aug 2007 11:14:13 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGcNQ-00045V-TM for sip@ietf.org; Thu, 02 Aug 2007 11:14:13 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l72FCJl26910; Thu, 2 Aug 2007 15:12:19 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 Date: Thu, 2 Aug 2007 10:14:08 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF117DBC46@zrc2hxm0.corp.nortel.com> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 Thread-Index: AcfVBk4gS62CPw9nRX+FhWINznu/UgADye7Q References: <1ECE0EB50388174790F9694F77522CCF11697776@zrc2hxm0.corp.nortel.com> <247B95AF-63F6-432D-9D6E-AF083AF9C525@nostrum.com> <46A92B7C.7080202@cisco.com> <1ECE0EB50388174790F9694F77522CCF116E20B5@zrc2hxm0.corp.nortel.com> <46AA09F1.6010401@cisco.com> From: "Francois Audet" To: "IETF SIP List" , "Dean Willis" , "DRAGE, Keith (Keith)" X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: Alan Hawrylyshen X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Again, you are correct. It seems that we have been in a circular argument on this list for a while. The same old arguments keep coming back. Basically we have 3 groups of people: 1 - People who prefer the response to be very explicit (e.g., separate error codes), and tell "what URI Scheme is acceptable". 2 - People who prefer the response to be a "hard failure" with no explicit indication of the acceptable URI scheme provided, in order to not encourage automatic=20 downgrades 3 - People who don't really care either way The compromise that emerged from this is to use a single error code, 480, which is the error used when the network cannot locate a contact for a particular recognized AOR. But, in addition, a Warning header field with one of 2 warn-codes is provided, to indicate the reason for the failure: SIPS Not Allowed or SIPS Required. This is meant to provide an indication to an Automata or an end user on the cause for the failure.=20 It has the benefit that existing implementations or "simple implementations" will behave=20 as desired, i.e, if they will treat it as a normal 480, and not harmful downgrades occur. So we achieve the goals of group 2 who want to avoid people shooting themselves in the=20 foot. Implementations that want to provide further indications of what went wrong will be able to use the Warn-Code to provide an indication of the problem (for end-user, network administrator, etc.). So we achieve the goals of group 1. It seems to me that this is a good solution. I'd really like to put an end to this=20 discussion and move on to something else.=20 =20 > -----Original Message----- > From: Alan Hawrylyshen [mailto:alan@polyphase.ca]=20 > Sent: Friday, July 27, 2007 08:27 > To: Kyzivat Paul; Mahy Rohan > Cc: IETF SIP List; Audet, Francois (SC100:3055);=20 > Jon.Peterson@neustar.com > Subject: Re: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 >=20 >=20 > On 27-Jul-2007, at 10:06 , Paul Kyzivat wrote: >=20 > > I understand that if the user entered a sips URI then it=20 > should be the=20 > > user that must decide to downgrade. But if the user didn't know=20 > > whether to use sip or sips in the first place, and the UA=20 > decides to=20 > > try sips first then I see no problem in the UA having a policy that=20 > > causes it to downgrade. >=20 > I was under the impression (based on meeting discussion) that : > 1 - the downgrade was undesirable because it reveals=20 > (possibly) information about the targeted party in the clear, and; > 2 - The 480 with a Warning header was an option to provide=20 > automata- friendly indication of the failure reason. >=20 > Alan Hawrylyshen >=20 > a l a n a t p o l y p h a s e d o t c a >=20 >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Aug 02 16:08:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGgwq-0007Ra-BK; Thu, 02 Aug 2007 16:07:04 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IGgwp-0007RS-Da for sip-confirm+ok@megatron.ietf.org; Thu, 02 Aug 2007 16:07:03 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGgwp-0007QH-3E; Thu, 02 Aug 2007 16:07:03 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGgwo-0001tG-Qm; Thu, 02 Aug 2007 16:07:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 8DD3817622; Thu, 2 Aug 2007 20:06:32 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IGgwK-00056T-5e; Thu, 02 Aug 2007 16:06:32 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Thu, 02 Aug 2007 16:06:32 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: sip@ietf.org Subject: [Sip] Last Call: draft-ietf-sip-ice-option-tag (Indicating Support for Interactive Connectivity Establishment (ICE) in the Session Initiation Protocol (SIP)) to Proposed Standard X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietf@ietf.org List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org The IESG has received a request from the Session Initiation Protocol WG (sip) to consider the following document: - 'Indicating Support for Interactive Connectivity Establishment (ICE) in the Session Initiation Protocol (SIP) ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2007-08-16. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-sip-ice-option-tag-02.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15577&rfc_flag=0 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Aug 02 17:00:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGhlK-0004GQ-79; Thu, 02 Aug 2007 16:59:14 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IGhlI-0004GJ-Vq for sip-confirm+ok@megatron.ietf.org; Thu, 02 Aug 2007 16:59:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGhlI-0004GB-MJ for sip@ietf.org; Thu, 02 Aug 2007 16:59:12 -0400 Received: from alnrmhc14.comcast.net ([206.18.177.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGhlH-0002OJ-Gp for sip@ietf.org; Thu, 02 Aug 2007 16:59:12 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (alnrmhc14) with ESMTP id <20070802205910b1400ph4vke>; Thu, 2 Aug 2007 20:59:10 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l72KxA8t027421 for ; Thu, 2 Aug 2007 16:59:10 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l72KxArL027417; Thu, 2 Aug 2007 16:59:10 -0400 Date: Thu, 2 Aug 2007 16:59:10 -0400 Message-Id: <200708022059.l72KxArL027417@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <200707250352.l6P3qdYB007762@dragon.ariadne.com> (Dale.Worley@comcast.net) Subject: Re: [Sip] INFO, Mime-multipart, and Content Negotiation (oh, my!) References: <7374777208BDC7449D5620EF942325670743C97A@esealmw113.eemea.ericsson.se> <7374777208BDC7449D5620EF942325670743C97B@esealmw113.eemea.ericsson.se><46A36757.7020500@nostrum.com><200707241605.l6OG57VQ020718@dragon.ariadne.com> <200707242118.l6OLI9xH011201@dragon.ariadne.com> <006e01c7ce39$335b55f0$0601a8c0@BEMBUSTER> <200707250352.l6P3qdYB007762@dragon.ariadne.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: Dale.Worley@comcast.net From: "Jeroen van Bemmel" > I see no problem with proliferating methods, as that is no worse than > proliferating Content-Dispositions. Well, for one it could cause existing proxies to Record-Route such requests as they would not know the method and would therefore be forced to assume it to be dialog creating. So there is some overhead, compared to C-D as extension point IIRC, there's a set of rules that avoid Record-Routing except in the first request or two of a dialog. Scott Lawrence once explained them to me, and I checked them, and they're method-independent (as one would expect). The rules for Record-Route: When a proxy forwards a request that has no to-tag, and the proxy wishes to remain in the signaling path, it adds a Record-Route header. (In special cases such as REGISTER, the proxy can know from the semantics of the request that it will not be dialog-forming and so the proxy never needs to remain in the signaling path, but in general, the proxy must Record-Route all such requests if it wants to be in the signaling path of a dialog.) When a UA receives a request with Record-Route headers, it returns them in its response (and saves them as the route set). When a UA sends a request that has a to-tag, but is potentially dialog-forming, it must add the route set elements to the request in Record-Route headers (in addition to adding them in Route headers). (This ensures that the server will know the route set even if it has not yet received a response from the original request.) A request that has a to-tag is potentially dialog-forming if the sender: - has received the dialog-forming request (without a to-tag) - has not received a request with a to-tag (including ACK) - has not received a response from any request it has sent The last item became necessary when we created SUBSCRIBE, which can fork and create dialogs. We really should get this written into 3261 so people get it right. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Aug 02 18:03:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGik3-0003LO-60; Thu, 02 Aug 2007 18:01:59 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IGik1-0003LJ-OG for sip-confirm+ok@megatron.ietf.org; Thu, 02 Aug 2007 18:01:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGik1-0003LB-Eq for sip@ietf.org; Thu, 02 Aug 2007 18:01:57 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGijz-0003Q0-Vp for sip@ietf.org; Thu, 02 Aug 2007 18:01:57 -0400 Received: from repmmr01.bea.com (repmmr01.bea.com [10.160.29.71]) by repmmg02.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l72M1sxh025838 for ; Thu, 2 Aug 2007 15:01:54 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr01.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l72M1pMR004511 for ; Thu, 2 Aug 2007 15:01:53 -0700 Received: from 172.24.28.178 ([172.24.28.178]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Thu, 2 Aug 2007 22:01:51 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Thu, 02 Aug 2007 18:01:49 -0400 From: Eric Burger To: "'sip'" Message-ID: Thread-Topic: C-T-E and MIME Body Handling Thread-Index: AcfVULmF9/zYUkFDEdyigQAWy4mm/w== Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [Sip] C-T-E and MIME Body Handling X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Something was bothering me with the discussion of Content-Transfer-Encoding in Chicago, but I could not put my finger on it. I just figured it out. I very much agree that *today*, if you have binary data in a SIP MIME part, and most of it is binary data, then one MUST use BINARY Content-Transfer-Encoding. That is fine and very well and good. What bothers me is that people might take a short-cut and never specify the Content-Transfer-Encoding. What happens if someone comes up with a really cool and useful Content-Transfer-Encoding? If we say *all* SIP message body parts that are MIME have a Content-Transfer-Encoding of BINARY, then we could never use that new C-T-E. What I could go for is saying the default C-T-E for SIP is BINARY, but that user agents MUST parse for C-T-E, and take the appropriate action if they find a C-T-E header. For today's parsers, that most likely would be to barf if the encoding is something other than 7bit, 8bit, or binary. That is fine - you are allowed to not understand a C-T-E. However, what would be "less than ideal" would be to have a parser that barfs on *any* C-T-E specification, including binary. Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete 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 sip-bounces@ietf.org Thu Aug 02 20:06:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGker-0003HN-3R; Thu, 02 Aug 2007 20:04:45 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IGkeo-0003FV-6v for sip-confirm+ok@megatron.ietf.org; Thu, 02 Aug 2007 20:04:42 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGkem-0003E5-Tc; Thu, 02 Aug 2007 20:04:41 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGkem-0006jy-0T; Thu, 02 Aug 2007 20:04:40 -0400 Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l7304Ohr007049; Thu, 2 Aug 2007 19:04:24 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Aug 2007 19:04:24 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.27]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Aug 2007 02:04:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Re: [Tsvwg] Draft Liaision response to SG13 onEmergency Telecommunications Date: Fri, 3 Aug 2007 02:04:20 +0200 Message-ID: <5D1A7985295922448D5550C94DE29180014EED0F@DEEXC1U01.de.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: [Tsvwg] Draft Liaision response to SG13 onEmergency Telecommunications Thread-Index: AcfUV6mjGtO5TKErQSCBtjCYHVYrNAAx//qA References: <46B0955A.3040900@ericsson.com> From: "DRAGE, Keith \(Keith\)" To: "Janet P Gunn" , "Magnus Westerlund" X-OriginalArrivalTime: 03 Aug 2007 00:04:21.0197 (UTC) FILETIME=[D7C5FFD0:01C7D561] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: sip@ietf.org, IETF SIPPING WG , tsvwg , NSIS X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org While I wish to make no comment on the inclusion of other documents, I would point out that the two drafts: draft-polk-sip-rph-new-namespaces-01 and draft-ietf-sip-rph-response were both discussed by the SIP WG and agreed that we would work on them. This is still awaiting AD approval of the new milestones, but apart from that, these are now essentially WG items. This does place them in a different position to other author drafts. Regards Keith ________________________________ From: Janet P Gunn [mailto:jgunn6@csc.com]=20 Sent: Wednesday, August 01, 2007 5:19 PM To: Magnus Westerlund Cc: sip@ietf.org; IETF SIPPING WG; tsvwg; NSIS Subject: [Sip] Re: [Tsvwg] Draft Liaision response to SG13 onEmergency Telecommunications =09 =09 =09 =09 =09 Magnus Westerlund wrote on 08/01/2007 10:14:50 AM: =09 > Janet P Gunn skrev: > >=20 > > Magnus, > >=20 > > You might want to add- > >=20 > > draft-polk-tsvwg-signaled-domain-id-00.txt >=20 > Well, I want to be somewhat restricted in adding individual work into=20 > the liaison. Also to me it is not clear how this is applicable in the=20 > emergency context.=20 =09 Well, you included draft-polk-sip-rph-new-namespaces-01, and draft-polk-tsvwg-signaled-domain-id-00 addresses the same scenarios. It would make sense to include either both or neither. >=20 > > and > > draft-polk-ecrit-local-emergency-rph-namespace-01.txt > > >=20 > Well, I got another comment about ECRIT WG document which we hadn't=20 > considered. I will contact the WG chairs and see what they say.=20 =09 Yes, ecrit should make the call. But I know at least one other stds body (PacketCable PKT2 0-SP-RSTF-D01-060330 TCHG) is addressing it. =09 Janet =09 >=20 > Cheers >=20 > Magnus Westerlund >=20 > IETF Transport Area Director & TSVWG Chair > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM/M > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- =09 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Aug 03 01:46:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGpyJ-0005bH-DR; Fri, 03 Aug 2007 01:45:11 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IGpyH-0005bB-4m for sip-confirm+ok@megatron.ietf.org; Fri, 03 Aug 2007 01:45:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGpyG-0005b2-P2 for sip@ietf.org; Fri, 03 Aug 2007 01:45:08 -0400 Received: from py-out-1112.google.com ([64.233.166.179]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGpyG-000656-4g for sip@ietf.org; Fri, 03 Aug 2007 01:45:08 -0400 Received: by py-out-1112.google.com with SMTP id f31so2293907pyh for ; Thu, 02 Aug 2007 22:45:07 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=X68frSV/uRhc8k5HWYbuWaXgvT9V0X6Tv47428XNANmIMZEi1tOpUKa7jqWIi53CEZUfNcWPy8l/WdpWAZ5LipDGda47xZcfEc2juh+FlbsTled14U3Rcfxg3rQkX93LqEy/lYN3CzJgz3cAxvZVH1Z2UvLxPyMlplk6X7eUsL8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=g48Gqn+xlNNipBQFgYYf3npKK4Nq40mNN77j4rg5p646H7a3xewuFeYifmbjCQTKPCHUd7b6lhkBEC64RHanf3EmdNJhl5GvCanfWDRm4l1oETT95uylX6udTDcGD9wNTZVeceErcAPoGVui0PtzU+j5SjNiNAIKu7tREqkL3JE= Received: by 10.65.254.5 with SMTP id g5mr4439107qbs.1186119524573; Thu, 02 Aug 2007 22:38:44 -0700 (PDT) Received: by 10.65.213.1 with HTTP; Thu, 2 Aug 2007 22:38:44 -0700 (PDT) Message-ID: <66cd252f0708022238x149e0474o744c3e1b4610a199@mail.gmail.com> Date: Fri, 3 Aug 2007 15:38:44 +1000 From: "Hisham Khartabil" To: "Aki Niemi" Subject: Re: [Sip] subnot-etags: suppressing NOTIFY interactions with SBCs and other middleboxes In-Reply-To: <46AEDFED.6000302@nokia.com> MIME-Version: 1.0 References: <46AEDFED.6000302@nokia.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1283880790==" Errors-To: sip-bounces@ietf.org --===============1283880790== Content-Type: multipart/alternative; boundary="----=_Part_24319_3526581.1186119524513" ------=_Part_24319_3526581.1186119524513 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Aki, That's hardly a show stopper. Hisham On 31/07/07, Aki Niemi wrote: > > Hi all, > > This is a potential show-stopper issue that Rohan brought up in the SIP > WG session last week. > > Currently, subnot-etags offers two modes of operation. In the first, the > body of the SUBSCRIBE-generated NOTIFY is suppressed, and in the other, > the entire NOTIFY is suppressed, and a new response 204 (No > Notification) is generated instead. > > The latter is a considerable change to how SIP events works, and might > cause a middlebox that tracks the SIP dialog to basically barf, thinking > the dialog expires when it in fact gets refreshed. > > Do folks think this is a problem? It would be great if some SBC vendors > could check what their implementation does with SUBSCRIBE dialogs. > > Personally, I'd hate to hack around boxes that people claim are doing > something fishy. But if this is a real problem, then subnot-etags would > basically need to be reduced to just suppressing bodies of NOTIFYs. > > 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 > ------=_Part_24319_3526581.1186119524513 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Aki,
 
That's hardly a show stopper.
 
Hisham

 
On 31/07/07, Aki Niemi <aki.niemi@nokia.com> wrote:
Hi all,

This is a potential show-stopper issue that Rohan brought up in the SIP
WG session last week.

Currently, subnot-etags offers two modes of operation. In the first, the
body of the SUBSCRIBE-generated NOTIFY is suppressed, and in the other,
the entire NOTIFY is suppressed, and a new response 204 (No
Notification) is generated instead.

The latter is a considerable change to how SIP events works, and might
cause a middlebox that tracks the SIP dialog to basically barf, thinking
the dialog expires when it in fact gets refreshed.

Do folks think this is a problem? It would be great if some SBC vendors
could check what their implementation does with SUBSCRIBE dialogs.

Personally, I'd hate to hack around boxes that people claim are doing
something fishy. But if this is a real problem, then subnot-etags would
basically need to be reduced to just suppressing bodies of NOTIFYs.

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

------=_Part_24319_3526581.1186119524513-- --===============1283880790== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1283880790==-- From sip-bounces@ietf.org Fri Aug 03 06:50:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGuiR-0004Sh-HQ; Fri, 03 Aug 2007 06:49:07 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IGuiP-0004Sa-IB for sip-confirm+ok@megatron.ietf.org; Fri, 03 Aug 2007 06:49:05 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGuiP-0004SS-7N for sip@ietf.org; Fri, 03 Aug 2007 06:49:05 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGuiO-000661-3d for sip@ietf.org; Fri, 03 Aug 2007 06:49:04 -0400 Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l73An3Ow003265; Fri, 3 Aug 2007 05:49:03 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Aug 2007 05:49:02 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.27]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Aug 2007 12:48:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Procedural question on updating RFC 3261 Table 2 and 3 Date: Fri, 3 Aug 2007 12:48:45 +0200 Message-ID: <5D1A7985295922448D5550C94DE29180014EEEB1@DEEXC1U01.de.lucent.com> In-Reply-To: <46B0D347.8000400@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Procedural question on updating RFC 3261 Table 2 and 3 Thread-Index: AcfUasz5AeMY47l8ToCYTEHO+h8m8QBPnk6g References: <46B0D347.8000400@softarmor.com> From: "DRAGE, Keith \(Keith\)" To: "Dean Willis" , X-OriginalArrivalTime: 03 Aug 2007 10:48:45.0817 (UTC) FILETIME=[DDAECE90:01C7D5BB] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Whatever we do here, we should recognise the prime requirement of what = we need to specify. All to often our procedures state what we do need to implement. This can = either be specific to one method, or in some cases the procedures are = rather unspecific as to which method they are referring to. Sometimes the table is our only reference as to what happens when it is = used in a method that is not explicitly mentioned in the procedures. There is an issue of conformance here; if an implementor supports both = the REFER extension, and the later xyz header field extension, but then = does not support the interaction of the two (but rather treats it as an = unknown header), is it conformant or not. In many cases we can only tell = by the contents of the table. So it is my belief that we cannot just delete the table. If we wish to = remove the table, we have to specify what would have otherwise have gone = in the table in RFC 2119 language in the procedures, i.e. things like: The xyz header field MUST NOT be used in responses The xyz header field is not intended for use in the abc methods What the table is poor on is indicating things like whether the header = field parameter is applicable only to the first request of a dialog or = is also valid in a subsequent request and so on. So in summary, if we delete the table, we must lay down clear guidelines = of what must appear in the procedures text to replace it. Regards Keith > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: Wednesday, August 01, 2007 7:39 PM > To: sip@ietf.org > Subject: [Sip] Procedural question on updating RFC 3261 Table 2 and 3 >=20 > If I understood things correctly, during our discussion of=20 > resource priority header extensions at IETF 69, Robert Sparks=20 > proposed a procedural change for documents that define new=20 > SIP header fields. >=20 > The current Guidelines for Authors of Extensions to the=20 > Session Initiation Protocol (RFC 4485) says: >=20 > o The extension MUST define which header fields can be present in > requests of that method. It is RECOMMENDED that this=20 > information > be represented as a new column of Table 2/3 of RFC=20 > 3261 [2]. The > table MUST contain rows for all header fields defined in > standards-track RFCs at the time of writing of the extension. >=20 >=20 > Updating these tables (or is it just one table since it is=20 > split into two only for page-formatting reasons?) has been a=20 > contentious issue for some time. I've personally refused to=20 > do it for the last few drafts, since I got it wrong so many=20 > times before. Furthermore, this requirement is making the=20 > table(s) very, very wide, and introducing a draft-ordering problem. >=20 > There's also the issue that everybody seems to interpret the=20 > table(s) differently, and that this has made for some very=20 > odd state machines when people try to code using the table(s). >=20 > And I'm sure Robert had even more compelling reasons as to=20 > why we should stop updating this table (or these tables) with=20 > every draft, though I fear that they weren't recorded=20 > effectively in the minutes. >=20 > So I'd like to ask the group some questions: >=20 > 1) Should we stop updating Table 2/3 in each draft? >=20 > 2) If so, do we need an update to RFC 4485 to establish new=20 > guidelines? >=20 > 3) Should we do something instead of updating Table 2/3, such=20 > as coming up with a new representation? >=20 > 4) If we have a new representation, should it be fully=20 > presented in each draft, or should it establish a new=20 > registry that each draft would update via IANA actions? Or=20 > somethinge else? >=20 > -- > Dean, Duly Appointed Co-Chair and Self-Appointed Pontificous Mediator >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Aug 03 08:03:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGvrB-0005Xg-7V; Fri, 03 Aug 2007 08:02:13 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IGjnR-00006W-3A for sip-confirm+ok@megatron.ietf.org; Thu, 02 Aug 2007 19:09:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGjnQ-00006O-Pu for sip@ietf.org; Thu, 02 Aug 2007 19:09:32 -0400 Received: from rv-out-0910.google.com ([209.85.198.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGjnP-00052l-Iz for sip@ietf.org; Thu, 02 Aug 2007 19:09:32 -0400 Received: by rv-out-0910.google.com with SMTP id f1so478335rvb for ; Thu, 02 Aug 2007 16:09:31 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer:sender; b=VQA+EYmGQXbzG1F+9JQWOUDB9baD+E8fIPtILv78WHKn6i1WaKq7geS51UmLCC07ZMS7o2E2WG9clYKS0Pu6PEZ6xay5shhAN/b8gdV2ru8lLA0mUjM8LoATwiiF8SC7f8PhnfvyseMizwmrGg/XCoT+KUasHN2lCJr4A5GZuyQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer:sender; b=layt5Ex+E95xQ4Qh+Jne2rHEIfGBwQsY3Ir/msW2tqI06oARLTxGP70UTmREXUUqVGK7z0jJ8W3HwOiEeTQP2Qfb8NScnkZ+r37Zm78QUd6KJqxnCqrqVJ9x/F3G3EoNY+vn04g4uuRdSWUsGtldlsHozMSs9jHl70wqSM+Ht0s= Received: by 10.114.151.13 with SMTP id y13mr2341345wad.1186096170875; Thu, 02 Aug 2007 16:09:30 -0700 (PDT) Received: from ?192.168.16.25? ( [66.11.84.109]) by mx.google.com with ESMTPS id n37sm3624977wag.2007.08.02.16.09.27 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 02 Aug 2007 16:09:27 -0700 (PDT) In-Reply-To: <1ECE0EB50388174790F9694F77522CCF117DBC46@zrc2hxm0.corp.nortel.com> References: <1ECE0EB50388174790F9694F77522CCF11697776@zrc2hxm0.corp.nortel.com> <247B95AF-63F6-432D-9D6E-AF083AF9C525@nostrum.com> <46A92B7C.7080202@cisco.com> <1ECE0EB50388174790F9694F77522CCF116E20B5@zrc2hxm0.corp.nortel.com> <46AA09F1.6010401@cisco.com> <1ECE0EB50388174790F9694F77522CCF117DBC46@zrc2hxm0.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <8F9FBE6D-E28B-4081-8FED-350AAD1D4291@polyphase.ca> Content-Transfer-Encoding: quoted-printable From: Alan Hawrylyshen Subject: Re: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 Date: Thu, 2 Aug 2007 17:09:15 -0600 To: Francois Audet X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-Mailman-Approved-At: Fri, 03 Aug 2007 08:02:11 -0400 Cc: IETF SIP List , "DRAGE, Keith \(Keith\)" , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On 02-Aug-2007, at 09:14 , Francois Audet wrote: > It seems to me that this is a good solution. I'd really like to put an > end to this > discussion and move on to something else. I find this proposal very acceptable for the reasons you already =20 stated. Thanks Fran=E7ois. Perhaps this was something of a bike shed painting exercise[1] , I'm =20 glad we are converging on a colour selection. Alan [1] http://ln-s.net/mva a l a n a t p o l y p h a s e d o t 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 sip-bounces@ietf.org Fri Aug 03 09:24:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGx7u-00089V-PT; Fri, 03 Aug 2007 09:23:34 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IGx7s-00088W-Eu for sip-confirm+ok@megatron.ietf.org; Fri, 03 Aug 2007 09:23:32 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGx7s-00087w-40 for sip@ietf.org; Fri, 03 Aug 2007 09:23:32 -0400 Received: from web56515.mail.re3.yahoo.com ([66.196.97.44]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IGx7r-0002Pe-Os for sip@ietf.org; Fri, 03 Aug 2007 09:23:32 -0400 Received: (qmail 75830 invoked by uid 60001); 3 Aug 2007 13:23:31 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=eSVQI6BcCxbZTFagda2jo4waHtU+niuAtMH1KMW9r5nd4x0Q6VQN4p9Lgh0I8ALjDNYchDwK1EVRZzYd3xHt0j6SonVgGWgRTGXVVV17nS+FyU92+q4LuX2qfJHk5vrc60lQDjS2aE0r2Hb9mzfp3OhycYLH8/2liqieswMiRq4=; X-YMail-OSG: eB7B0GoVM1nL3iwNfImY7XYKpk5xruIlc9kMtkJscyqk3_nhQTizcC9rPk2BwequMEXrdQMjIJ1_ZfEz3umf1wrtPSHCg95LhJcfGlrZC9eSsT1oH9hC2obNWP9GDk8FcgwzjkrvXms30.vGx3ZsPLyr Received: from [202.54.176.11] by web56515.mail.re3.yahoo.com via HTTP; Fri, 03 Aug 2007 06:23:31 PDT Date: Fri, 3 Aug 2007 06:23:31 -0700 (PDT) From: sengottuvelan srirangan To: sip@ietf.org MIME-Version: 1.0 Message-ID: <275480.75108.qm@web56515.mail.re3.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: [Sip] opaque field in proxy authentication header X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1816296355==" Errors-To: sip-bounces@ietf.org --===============1816296355== Content-Type: multipart/alternative; boundary="0-1926978964-1186147411=:75108" Content-Transfer-Encoding: 8bit --0-1926978964-1186147411=:75108 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi SIP experts, I don't understand about the usage of opaque field in SIP proxy authentication headers. For example. Proxy-Authenticate: Digest realm="atlanta.com", domain="sip:ss1.carrier.com", qop="auth", nonce="f84f1cec41e6cbe5aea9c8e88d359", opaque="", stale=FALSE, algorithm=MD5 could you please anyone clarify the opaque field with an example? Thanks in adavance. Regards Sengottuvelan --------------------------------- Need a vacation? Get great deals to amazing places on Yahoo! Travel. --0-1926978964-1186147411=:75108 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Hi SIP experts,
 
I don't understand about the usage of opaque field in SIP proxy authentication headers. For example.
 
      Proxy-Authenticate: Digest realm="atlanta.com",
       domain="sip:ss1.carrier.com", qop="auth",
       nonce="f84f1cec41e6cbe5aea9c8e88d359",
       opaque="", stale=FALSE, algorithm=MD5
 
could you please anyone clarify the opaque field with an example?
 
Thanks in adavance.
 
Regards
Sengottuvelan
 

Need a vacation? Get great deals to amazing places on Yahoo! Travel. --0-1926978964-1186147411=:75108-- --===============1816296355== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1816296355==-- From sip-bounces@ietf.org Fri Aug 03 10:59:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGybN-00078u-8m; Fri, 03 Aug 2007 10:58:05 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IGybL-0006yF-2C for sip-confirm+ok@megatron.ietf.org; Fri, 03 Aug 2007 10:58:03 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGybK-0006wM-M5 for sip@ietf.org; Fri, 03 Aug 2007 10:58:02 -0400 Received: from cluster-f.mailcontrol.com ([85.119.2.190]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGybJ-0005T2-Og for sip@ietf.org; Fri, 03 Aug 2007 10:58:02 -0400 Received: from rly19f.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly19f.srv.mailcontrol.com (MailControl) with ESMTP id l73EuUxc005936 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 3 Aug 2007 15:56:57 +0100 Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly19f.srv.mailcontrol.com (MailControl) id l73EuH1f005462 for sip@ietf.org; Fri, 3 Aug 2007 15:56:17 +0100 Received: from exsmtp01.nasstar-t1.net (exsmtp01.nasstar-t1.net [89.28.233.12]) by rly19f-eth0.srv.mailcontrol.com (envelope-sender attila.sipos@vegastream.com) (MIMEDefang) with ESMTP id l73Ernp0031101; Fri, 03 Aug 2007 15:56:16 +0100 (BST) Received: from ExBE03.nasstar-t1.net ([10.2.10.102]) by exsmtp01.nasstar-t1.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Aug 2007 15:56:18 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] opaque field in proxy authentication header Date: Fri, 3 Aug 2007 15:56:05 +0100 Message-ID: <165288C2C3E29449AFDE022DD10CC47106839528@ExBE03.nasstar-t1.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] opaque field in proxy authentication header Thread-Index: AcfV0cZFKs8jZHjuRVuCMXAVO2bURgADAhbw From: "Attila Sipos" To: "sengottuvelan srirangan" , X-OriginalArrivalTime: 03 Aug 2007 14:56:18.0716 (UTC) FILETIME=[72B355C0:01C7D5DE] X-Scanned-By: MailControl A-07-08-00 (www.mailcontrol.com) on 10.70.1.129 X-Spam-Score: 0.0 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1390683076==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1390683076== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7D5DE.7147E3E0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7D5DE.7147E3E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Because the opaque has to be returned, it can be used transport anything back to the challenger. =20 >From RFC 2617: =20 Because the client is required to return the value of the opaque directive given to it by the server for the duration of a session, the opaque data may be used to transport authentication session state information.=20 =20 It is up to the generator of the Authenticate challenge to decide what to use this opaque field for. =20 It could be, for example, some kind of stateful information required by a stateless proxy. =20 Regards, =20 Attila =20 =20 =20 ________________________________ From: sengottuvelan srirangan [mailto:sengottuvelan_s@yahoo.com]=20 Sent: 03 August 2007 14:24 To: sip@ietf.org Subject: [Sip] opaque field in proxy authentication header Hi SIP experts, =20 I don't understand about the usage of opaque field in SIP proxy authentication headers. For example. =20 Proxy-Authenticate: Digest realm=3D"atlanta.com", domain=3D"sip:ss1.carrier.com", qop=3D"auth", nonce=3D"f84f1cec41e6cbe5aea9c8e88d359", opaque=3D"", stale=3DFALSE, algorithm=3DMD5 =20 could you please anyone clarify the opaque field with an example? =20 Thanks in adavance. =20 Regards Sengottuvelan =20 ________________________________ Need a vacation? Get great deals to amazing places on Yahoo! Travel.=20 ------_=_NextPart_001_01C7D5DE.7147E3E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Because the opaque has to be returned, it can = be used=20 transport
anything back to the = challenger.
 
From RFC 2617:
 
   Because the=20 client is required to return the value of the opaque
   = directive=20 given to it by the server for the duration of a session,
   = the=20 opaque data may be used to transport authentication session=20 state
   information.
 
It is up to the=20 generator of the Authenticate challenge to decide
what to use this opaque field = for.
 
It could be, for example, some kind of stateful = information=20 required
by a stateless proxy.
 
Regards,
 
Attila
 
 
 

From: sengottuvelan srirangan=20 [mailto:sengottuvelan_s@yahoo.com]
Sent: 03 August 2007=20 14:24
To: sip@ietf.org
Subject: [Sip] opaque field = in proxy=20 authentication header

Hi SIP experts,
 
I don't understand about the usage of opaque field in SIP proxy=20 authentication headers. For example.
 
      Proxy-Authenticate: Digest=20 realm=3D"atlanta.com",
      =20 domain=3D"sip:ss1.carrier.com",=20 qop=3D"auth",
      =20 nonce=3D"f84f1cec41e6cbe5aea9c8e88d359",
     = ; =20 opaque=3D"", stale=3DFALSE, algorithm=3DMD5
 
could you please anyone clarify the opaque field with an = example?
 
Thanks in adavance.
 
Regards
Sengottuvelan
 

Need a vacation? Get=20 great deals to amazing places on Yahoo! Travel. ------_=_NextPart_001_01C7D5DE.7147E3E0-- --===============1390683076== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1390683076==-- From sip-bounces@ietf.org Fri Aug 03 11:17:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGytW-0000As-Fv; Fri, 03 Aug 2007 11:16:50 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IGytV-0000Am-Ay for sip-confirm+ok@megatron.ietf.org; Fri, 03 Aug 2007 11:16:49 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IGytV-0000Ae-1i for sip@ietf.org; Fri, 03 Aug 2007 11:16:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGyj6-0006ye-5S for sip@ietf.org; Fri, 03 Aug 2007 11:06:04 -0400 Received: from web7908.mail.in.yahoo.com ([202.86.4.84]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IGyj5-0005fO-ED for sip@ietf.org; Fri, 03 Aug 2007 11:06:04 -0400 Received: (qmail 99681 invoked by uid 60001); 3 Aug 2007 14:59:21 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=nvOMA0621UFKFGcZDTcC11MH4jGBFN7Y5cwYjdOql1sHwtOKua9oYNZhHaQAHsvH8cbJvpItXqCuSSvBNdz7QBN1x39S8p0N9Y6pYgpwXWPpTMqRBI2mzTazr7/p7P7K/G/3HQlKOSsdW3WWe2RqqprB+Qfiiy2K+bcfVaIqql0=; X-YMail-OSG: j5Q0Jq0VM1nUwQe_yBzvBWXmREEJ4KehwPjM7bQ6.yiFLW3n1iZVM04ub8dhKpZbf9ZqKPJS1qZu2Jd1IDZDzEogfCp2jwGzr14CrNsyStXnpJN7F4X_b_vk2Oi8AA-- Received: from [134.102.123.211] by web7908.mail.in.yahoo.com via HTTP; Fri, 03 Aug 2007 15:59:20 BST Date: Fri, 3 Aug 2007 15:59:20 +0100 (BST) From: nisha varghese To: sip@ietf.org MIME-Version: 1.0 Message-ID: <954900.78622.qm@web7908.mail.in.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-TMDA-Confirmed: Fri, 03 Aug 2007 11:16:49 -0400 Subject: [Sip] sip implementation X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0285343704==" Errors-To: sip-bounces@ietf.org --===============0285343704== Content-Type: multipart/alternative; boundary="0-1352697877-1186153160=:78622" Content-Transfer-Encoding: 8bit --0-1352697877-1186153160=:78622 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit hello, I am looking for a SIP implementation which supports terminal mobility. Can anyone suggest an open source SIP implementation with mobility support. Thanks in advance. --------------------------------- Get the freedom to save as many mails as you wish. Click here to know how. --0-1352697877-1186153160=:78622 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit hello,

I am looking for a SIP implementation which supports terminal mobility. Can anyone suggest an open source SIP implementation with mobility support.

Thanks in advance.

Get the freedom to save as many mails as you wish. Click here to know how. --0-1352697877-1186153160=:78622-- --===============0285343704== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0285343704==-- From sip-bounces@ietf.org Fri Aug 03 12:46:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IH0HW-0003XP-Rb; Fri, 03 Aug 2007 12:45:42 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IH0HU-0003XD-UT for sip-confirm+ok@megatron.ietf.org; Fri, 03 Aug 2007 12:45:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IH0HU-0003X0-KI for sip@ietf.org; Fri, 03 Aug 2007 12:45:40 -0400 Received: from host122.155.212.198.conversent.net ([155.212.198.122] helo=mail.pingtel.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IH0HU-0008QD-73 for sip@ietf.org; Fri, 03 Aug 2007 12:45:40 -0400 Received: from [127.0.0.1] (unknown [10.1.1.12]) by mail.pingtel.com (Postfix) with ESMTP id B8C066C018; Fri, 3 Aug 2007 12:45:01 -0400 (EDT) Subject: Re: [Sip] opaque field in proxy authentication header From: Scott Lawrence To: sengottuvelan srirangan In-Reply-To: <275480.75108.qm@web56515.mail.re3.yahoo.com> References: <275480.75108.qm@web56515.mail.re3.yahoo.com> Content-Type: text/plain Organization: Bluesocket Inc. Date: Fri, 03 Aug 2007 12:45:39 -0400 Message-Id: <1186159539.3526.22.camel@sukothai.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Fri, 2007-08-03 at 06:23 -0700, sengottuvelan srirangan wrote: > Hi SIP experts, > > I don't understand about the usage of opaque field in SIP proxy > authentication headers. For example. > > Proxy-Authenticate: Digest realm="atlanta.com", > domain="sip:ss1.carrier.com", qop="auth", > nonce="f84f1cec41e6cbe5aea9c8e88d359", > opaque="", stale=FALSE, algorithm=MD5 > > could you please anyone clarify the opaque field with an example? The server can put anything it wants to into the value. The client MUST just return that value if present in the Authorization header. RFC-2617 says: Because the client is required to return the value of the opaque directive given to it by the server for the duration of a session, the opaque data may be used to transport authentication session state information. RFC-2617 also says: Note that any such use can also be accomplished more easily and safely by including the state in the nonce. which was a nicer way of saying 'opaque is pointless and insecure' because the opaque value is not protected by the response hash, it can be replayed by an attacker. If you're implementing a server, it is best not to include it. If you're implementing a client, just send it back and ignore 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 sip-bounces@ietf.org Fri Aug 03 17:01:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IH4Fh-0004A0-SD; Fri, 03 Aug 2007 17:00:05 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IH4Fe-00040Y-TM for sip-confirm+ok@megatron.ietf.org; Fri, 03 Aug 2007 17:00:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IH4Fe-0003x2-Cq for sip@ietf.org; Fri, 03 Aug 2007 17:00:02 -0400 Received: from sccrmhc14.comcast.net ([63.240.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IH4Fc-0002J7-Jz for sip@ietf.org; Fri, 03 Aug 2007 17:00:02 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (sccrmhc14) with ESMTP id <200708032100000140019a2je>; Fri, 3 Aug 2007 21:00:00 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l73Kxx8t003496 for ; Fri, 3 Aug 2007 16:59:59 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l73Kxxvw003492; Fri, 3 Aug 2007 16:59:59 -0400 Date: Fri, 3 Aug 2007 16:59:59 -0400 Message-Id: <200708032059.l73Kxxvw003492@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: (jmpolk@cisco.com) Subject: Re: [Sip] Re: Comments on draft-polk-sip-rph-new-namespaces-00 References: <5D1A7985295922448D5550C94DE2918001473951@DEEXC1U01.de.lucent.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I get the feeling that this issue is a lot simpler than people are making it out to be. Starting with some ideas some speaker at IETF 69 expressed: The basic idea is to reserve all RPH namespaces starting with "dsn-" to DISA. Any SIP agent that doesn't support the dsn namespaces doesn't have to parse the namespace in any interesting way to discover that it is a namespace that it doesn't support, so implementing this change within SIP doesn't require any change to any agent that doesn't need to specifically support it. Conversely, unless *all* namespaces starting with "dsn-" are reserved in IANA to DISA, there is nothing to prevent Osama bin Ladin from registering "dsn-al-qaeda", or worse, "dsn-usnavy-CINCPAC", unless DISA has happened to enumerate those particular values in a registration. As long as we restrict all such "group" registrations to end with the same separator character, and allow no other use of the separator character, and the separator character is not yet used in any registered RPH namespace, there is no compatibility problem with existing uses. And conveniently, "-" meets all the criteria. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Aug 03 19:21:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IH6Rk-0002CZ-Qe; Fri, 03 Aug 2007 19:20:40 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IH6Ri-0002B0-QX for sip-confirm+ok@megatron.ietf.org; Fri, 03 Aug 2007 19:20:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IH6Ri-000245-B5 for sip@ietf.org; Fri, 03 Aug 2007 19:20:38 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IH6Rh-0001oP-7a for sip@ietf.org; Fri, 03 Aug 2007 19:20:37 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l73NKWp00732; Fri, 3 Aug 2007 23:20:33 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 3 Aug 2007 18:20:31 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1187017D@zrc2hxm0.corp.nortel.com> In-reply-to: <8B1D53AEF7B03449A6D3771B3B7F850F03EC99B1@esebe103.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC comments on sip-outbound-10 Thread-Index: AcfU2dPhL44o/l0WRX6z3EFCPvf1OgBMaoaA References: <8B1D53AEF7B03449A6D3771B3B7F850F03EC99B1@esebe103.NOE.Nokia.com> From: "Francois Audet" To: , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: Subject: [Sip] WGLC comments on sip-outbound-10 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Some more WGLC on sip-outbound-10 --------------------------------- ------- Section 4.4: change "timed-keepalives" to "time-keepalive" (there are at least 2 instances of=20 this mistake). ------- The example in section 9 should use TCP instead of of UDP, since TCP is preferred (as discussed in section 14). Furthermore, if the UDP example is used, it should show the rport parameter in the Via header. It should be clarified that the last paragraph of 4.3 only applies to UDP. ------ I would like to see more details in section 9 about how the "ob", "rport" and Route and Record-Route headers (i.e., including the keep-XXX parameter) are used by a UA that=20 supports outbound procedures, when sending requests using Outbound (like INVITE for example). Also, it would be helpful to see an example where the outbound proxy is=20 not co-located with the Registrar, so we could see how the Path header is used, including the "ob" parameter (as per the procedures of 5.1). This stuff is non-trivial and would benefit greatly from an example flow (with the messages content). Distinguishing between 'ob' in Contact and in Path/Route seems important. In other words, a flow (with messages) illustrating what an edge proxy does for both registration and for further requests such as INVITE. ------ Finally, the procedures in 5.3 on "incoming" requests is not that clear on what it actually mean "on the wire". It says the following: For an incoming request, the proxy removes the Route header field value and forwards the request over the 'logical flow' identified by the flow token, that is known to deliver data to the specific target UA instance.=20 Does it just mean that the request will be forward on the same TCP or UDP flow, and=20 that there is no additional requirements? Nothing on the wire that will show that outbound is being used (Is the flow token supposed to be inserted by the Proxy)? On that front, message 8 in the example of section 9 has a flow token, where does it come from? This is very confusing since the Caller might not use Outbound, so where does this token come from, and what it is used for in this example? How is the token of the Callee given to the Caller??? It is also no clear from the example how the Caller knows to reattempt the INVITE to the secondary proxy (wouldn't this be handled in the terminating side's domain?).=20 There is no description of UAS requirements in the draft. Does it mean that there are none whatsoever? (I'm talking about a UAS that is using outbound receiving incoming requests). If so, there should be a UAS section stating so. Is it possible for example that incoming requests might be received by the UAS on different=20 flows (because of reboot for example)? In the same session?? _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Aug 05 12:04:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IHiZT-0005PD-I7; Sun, 05 Aug 2007 12:03:11 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IHiZS-0005P7-36 for sip-confirm+ok@megatron.ietf.org; Sun, 05 Aug 2007 12:03:10 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IHiZR-0005Oz-Nv for sip@ietf.org; Sun, 05 Aug 2007 12:03:09 -0400 Received: from endor.rfc3261.net ([212.112.227.208]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IHiZQ-0004yi-VU for sip@ietf.org; Sun, 05 Aug 2007 12:03:09 -0400 Received: from localhost (localhost [127.0.0.1]) by endor.rfc3261.net (Postfix) with ESMTP id A870526000B; Sun, 5 Aug 2007 18:03:07 +0200 (CEST) Received: from endor.rfc3261.net ([127.0.0.1]) by localhost (endor [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 01490-06; Sun, 5 Aug 2007 18:03:02 +0200 (CEST) Received: from dagobah (e179077218.adsl.alicedsl.de [85.179.77.218]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by endor.rfc3261.net (Postfix) with ESMTP id 2969E26000A; Sun, 5 Aug 2007 18:03:02 +0200 (CEST) From: Nils Ohlmeier To: sip@ietf.org, rohan@ekabal.com, fluffy@cisco.com Date: Sun, 5 Aug 2007 18:02:54 +0200 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200708051802.55505.lists@ohlmeier.org> X-Virus-Scanned: by amavisd-new (Debian) at endor.rfc3261.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Cc: Subject: [Sip] WGLC comments on sip-outbound-10 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hello, sorry for being with my comments. Please find one minor technical issue and several NITs below. Minor Technical: 9. Example Message Flow The 200 OK on page 28 contains no Path header, which should carry the ob and/or the keepalive URI parameters to allow the UA to detect that Oubound is supported and used. How can the UA detect that outbound is supported and used for this flow when it receives a 200 OK like this one? In the case there is an edge proxy included which supports outbound the 200 OK should have the Path header with the parameters. If the edge proxy does not support outbound, the Path header should not have the parameters. If the edge proxy does not even support the Path extension, outbound can not be supported either. But how does the UA detect that the Registrar supports and uses outbound in case there is no edge proxy involved? The easiest and simple solution to me would be that the Registrar has to include a Path header into the reply which points to itself and carries the required parameters. Another alternative would be to rely only on the Suported/Required header and do not look at the Path URI at all. Then the keepalive algorithm would be implicitly determined by the used transport, but that would also mean that there is no way for the Registrar to let the UA know that it supports the optional TCP Keepalive algorithm. And the Supported/Required header would have to be included into the reply by edge proxy (in case), which is, I think, against the normal usage of these headers. NITs: 1. Introduction "This specification allows SIP registration when the UA is behind such a firewall or NAT." Proposed improvement: This specification ensures that the UA if it is behind such a firewall or NAT is reachable by the registrar after the first successful initial registration. 2.1 Definitions "outbound-proxy-set A set of SIP URIs...." Proposed improvement: outbound-proxy-set: A set of SIP URIs... 3.2 Single Registrar and UA " REGISTER sip:example.com;keep-crlf SIP/2.0 Via: SIP/2.0/TCP 192.0.2.1;branch... ... Contact: ;reg-id=1;... " Why have Via and Contact different IPs? I assume this is a type and should look like this: REGISTER sip:example.com;keep-crlf SIP/2.0 Via: SIP/2.0/TCP 192.168.0.2;branch... ... Contact: ;reg-id=1;... 3.3 Multiple Connections from a User Agent "..., so mechanism like SRV can be used..." Proposed improvement: ..., so mechanism like DNS SRV can be used... 4.1 Instance ID Creation "... as the device knows no other UUIDs were generated at this time." Proposed improvement: ... as the device knows no other UUIDs were generated at this time on this device. 4.2.1 Registration by Other Instances Is the second paragraph about unregister only ment for this particular case or for all UAs supporting this draft? To me it semms at it is ment for all UAs, as the star Contact should match all bindings anyway. Otherwise it should be explained somewhere what a star Contact with an instance-id and/or reg-id means. 4.4 Detecting Flow Failure The last paragraph talks about tags in the URIs of the outbound-proxy-set. Are these tags are still used after the Chicago meeting? If so, then there should be a refence to chapter 12. 5.4 Edge Proxy Keepalive Handling Why is TCP Keepalive not mentioned in this section? I think it should mention that this an optional keepalive mechanism for the edge proxy. 6. Registrar Mechanisms: Processing REGISTER Requests Last paragraph on page 22: "First the registrar examines the first Path header field value, if any." Proposed improvement: First the registrar examines the first (bottom most) Path header field value, if any. 4th paragraph on page 23: "Furthermore, the Registrar MUST NOR include this option-tag..." Fix: Furthermore, the Registrar MUST NOR include this option-tag... 8. STUN Keeplalive Processing 1st paragraph on page 26: "Typically, a SIP node first sends a SIP request and waits to receive a final response (other than a 408 response) over a flow to a new target destination, before sending any STUN messages." Why should an UA start sending any STUN messages when it received any non-2xx reply? I think the sentence above should be limited to 2xx responses only as indication that the flow is "established" and the UA can send STUN messages now. 12.2 SIP/SIPS URI Parameters Why is there no Parameter for the optional TCP Keepalive? Or should the sections talking about TCP Keepalive as an optional alternative be deleted from the document? Cheers Nils Ohlmeier _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Aug 06 05:11:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IHycT-0000jz-P1; Mon, 06 Aug 2007 05:11:21 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IHycR-0000jW-5u for sip-confirm+ok@megatron.ietf.org; Mon, 06 Aug 2007 05:11:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IHycN-0000cd-2B; Mon, 06 Aug 2007 05:11:15 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IHycI-0000vL-41; Mon, 06 Aug 2007 05:11:15 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JMC004R5HEGCL@szxga03-in.huawei.com>; Mon, 06 Aug 2007 17:08:40 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JMC00165HEF3A@szxga03-in.huawei.com>; Mon, 06 Aug 2007 17:08:40 +0800 (CST) Received: from JAIMINCL5132 ([10.18.8.229]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JMC0051JHE3DQ@szxml03-in.huawei.com>; Mon, 06 Aug 2007 17:08:39 +0800 (CST) Date: Mon, 06 Aug 2007 14:38:26 +0530 From: Jaimin Pancholi To: SIP , SIPPING Message-id: <004101c7d809$5a2ca8d0$e508120a@china.huawei.com> Organization: huawei MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcfYCVkKfSNITH//Q6K7m0TpiCzLtw== X-Spam-Score: 1.2 (+) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Cc: Subject: [Sip] Is this call flow a race condition or RFC non comformance ?? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jaiminp@huawei.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1929808973==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1929808973== Content-type: multipart/alternative; boundary="Boundary_(ID_t0XniNqPl+/uJI4IyXOXUA)" This is a multi-part message in MIME format. --Boundary_(ID_t0XniNqPl+/uJI4IyXOXUA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Dear all, Is below call flow a race condition call flow or RFC non comformance ??? Caller Callee | | | | |(1) INVITE with offer 1 | |---------------------------->| | | | | |(2) 180 with answer 1 | |<----------------------------| | | | | |(3) PRACK | |---------------------------->| | | | | |(4) 200 PRACK | |<----------------------------| | | | | |(5) 200 OK for Invite | |<----------------------------| | | | | |(6) UPDATE with offer 2 | |<----------------------------| | | | | |(7) ACK for INVITE | |---------------------------->| | | | | |(8) 200 OK,UPDATE answer 2 | |<----------------------------| Regards Jaimin Email Privacy Declaration **************************************************************************** *********** This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! --Boundary_(ID_t0XniNqPl+/uJI4IyXOXUA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT Is this call flow a race condition or RFC non comformance ??

Dear all,
        Is below call flow a race condition call flow or RFC non comformance ???



                Caller                        Callee
                   |                             |
                   |                             |
                   |(1) INVITE with offer 1      |
                   |---------------------------->|
                   |                             |
                   |                             |
                   |(2) 180 with answer 1        |
                   |<----------------------------|
                   |                             |
                   |                             |
                   |(3) PRACK                    |
                   |---------------------------->|
                   |                             |
                   |                             |
                   |(4) 200 PRACK                |
                   |<----------------------------|
                   |                             |
                   |                             |
                   |(5) 200 OK for Invite        |
                   |<----------------------------|
                   |                             |
                   |                             |
                   |(6) UPDATE with offer 2      |
                   |<----------------------------|
                   |                             |
                   |                             |
                   |(7) ACK for INVITE           |
                   |---------------------------->|
                   |                             |
                   |                             |
                   |(8) 200 OK,UPDATE answer 2   |
                   |<----------------------------|


Regards
Jaimin

Email Privacy Declaration
***************************************************************************************
        This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!

--Boundary_(ID_t0XniNqPl+/uJI4IyXOXUA)-- --===============1929808973== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1929808973==-- From sip-bounces@ietf.org Mon Aug 06 18:47:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIBLd-0004J9-Oz; Mon, 06 Aug 2007 18:46:49 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IIBLc-0004J4-Sc for sip-confirm+ok@megatron.ietf.org; Mon, 06 Aug 2007 18:46:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIBLc-0004Iw-In for sip@ietf.org; Mon, 06 Aug 2007 18:46:48 -0400 Received: from py-out-1112.google.com ([64.233.166.180]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIBLb-0004yp-Bj for sip@ietf.org; Mon, 06 Aug 2007 18:46:48 -0400 Received: by py-out-1112.google.com with SMTP id f31so4657930pyh for ; Mon, 06 Aug 2007 15:46:47 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=AtwgLIKNHfU/vnSIGYlPcbYrMDbkcm4BSjG/t40Ban0UrZLS/LAl8F5eta/VnO9DYYGI2WfjGLfMHZlyYQFareCaAYK6uis7wNo62TmBEjfuevvCxQz82st+DaCMVFVeLRDZsTQYIC0YiS9A1nUBCiTWqtEEmmaxQq48rKkfRKw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=JgB0VOId2Y9JybmilOBEf5wHO/acTvZX4n4pwySxCdV/tn9c+hsu0o28XYaRb7uC90KBaGEDELrp08LvWMDN86iRWhTbC7/iK/UEunCuDD8IiYp9HxycHIOoLl/tDf/Pn/e7xjpqw7CZhnq0SImRRR8wYqtFKFuaclunc2dovlw= Received: by 10.65.156.2 with SMTP id i2mr9707326qbo.1186440406666; Mon, 06 Aug 2007 15:46:46 -0700 (PDT) Received: by 10.65.20.16 with HTTP; Mon, 6 Aug 2007 15:46:46 -0700 (PDT) Message-ID: Date: Mon, 6 Aug 2007 15:46:46 -0700 From: "Derek MacDonald" To: sip@ietf.org, rohan@ekabal.com, "Cullen Jennings" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: 8865fafdf5f60ff3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Cc: Subject: [Sip] WGLC comments on sip-outbound-10 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I've finished my review of outbound-10, mainly thinking about things from a client implementation & NAT traversal perspective. Major issues: The following issues are all one part of what I think is the core issue w/ outbound; the draft does not require normative behavior that will result in successful NAT traversal, although it does contain the necessary mechanisms for NAT traversal. In 4.2 and 4.3 it is stated that route-set creation is outside the scope of outbound. The behavior that is would work for NAT traversal in a simple deployment is described as an example in 4.2. >From 4.2: "Forming the route set for the request is outside the scope of this document, but typically results in sending the REGISTER such that the topmost Route header field contains a loose route to the outbound proxy URI." Are we really anticipating that an element will be inserted between the UA and the outbound proxy(s). Do we want to allow this? If there is such an element in the route set, it will either have to: Support outbound, which causes a single point of failure if there isn't a 1-1 correspondence with the edge proxies. If there is a 1-1 correspondence with the edge proxies, it is an edge proxy, so is should have just been configured as the outbound proxy. OR Transparently relay outbound, which seems like a very bad idea. I think we should change the text to something like: "While forming the route set for the request is outside the scope of this specification, the first element in the route set for a registration MUST be from the outbound-proxy-set in order to use this specification." Section 4.3 Discusses how a UA would send a request, but does not describe the basic behavior that would establish a dialog through a NAT. " When a UA is about to send a request, it first performs normal processing to select the next hop URI. The UA can use a variety of techniques to compute the route set and accordingly the next hop URI. Discussion of these techniques is outside the scope of this document but could include mechanisms specified in RFC 3608 [22] (Service Route) and [21]." If the next hop does not support outbound, and isn't an existing flow, a dialog establishing request will likely result in a route set which does not work through a NAT. The rport mechanism only provides NAT traversal for a single SIP response. "The UA performs normal DNS resolution on the next hop URI (as described in RFC 3263 [4]) to find a protocol, IP address, and port." As there is no mechanism to determine outbound support in other administrative domains, this lookup is only relevant to outbound if the UA knows next hop supports outbound. Later in the same paragraph: "If the UA cannot use one of the existing flows,then it SHOULD form a new flow by sending a datagram or opening a new connection to the next hop, as appropriate for the transport protocol." I was under the impression that flows are only created with REGISTER requests...is this incorrect? The crux of the issue is that to accomplish NAT traversal using outbound w/out extensions, the UA MUST send dialog creating requests using an existing flow(selected by round-robin for appropriate transport/etc). Furthermore, in 5.3, edge proxies MUST record route dialog creating requests. We need to change the base-level behaviour of outbound so NAT traversal just works, is this is a core requirement of outbound. Also: Note that if the UA wants its flow to work through NATs or firewalls it still needs to put the 'rport' parameter [10] in its Via header field value, and send from the port it is prepared to receive on. More general information about NAT traversal in SIP is described in [23]. should be removed. [23] is very out of date, and references outbound-01, and I believe some of the text is out of date. Rport is not relevant when flows are used, although it doesn't cause any harm. Questions/minor issues: 4.1: "The value of this parameter MUST be a URN [8]. One case where a UA may not want to include the URN in the sip.instance media feature tag..." Does this mean that a sip.instance feature tag is still included? If so, what does it contain? "As a result, the UA instance SHOULD provide lexically equivalent URNs in each registration it generates. " Why not MUST instead of SHOULD? Nits Explain why the CRLFCRLF & CRLF messages used for the PING/PONG don't break existing SIP implementations. I spent a lot of time looking through the grammar before I gave up and asked Rohan and pointed me to section 7.5 of 3261. I would reference this section in 3.5.1 and/or 4.4.2. 2.1 "reg-id: This refers to the value of a new header field parameter value for the Contact header field. When a UA registers multiple times, each simultaneous registration gets a unique reg-id value." change simultaneous to concurrent: "reg-id: This refers to the value of a new header field parameter value for the Contact header field. When a UA registers multiple times, each concurrent registration gets a unique reg-id value." 3.3 "If a UA has multiple flows, and one of the servers fails, the UA delays the specified time before trying to form a new connection to replace the flow to the server that failed." This implies that if the UA only has one flow, it retries immediately which doesn't match the behaviour described in 4.5. Maybe: "When a server fails the UA will delay before attempting to re-establish a flow, using the delays specified in section 4.5." 3.5 Change(awkward): "In this case, the server provides an indicator (the 'timed-keepalives' parameter) that the server requires the client to use the suggested timer values." to "In this case, the server indicates that the client must use the suggested timer values by including the timed-keepalives parameter." 4.1 "This means the value of the time component of the UUID can be arbitrarily selected to be any time less than the time when the device was manufactured. A time of 0 (as shown in the example in Section 3.2) is perfectly legal as long as the device knows no other UUIDs were generated at this time." I found this extremely confusing; I think it is saying that the time component isn't necessary(but can't be in the future) if the device already has a unique mac address it includes in the UUID. Why not just say that a time of 0 can be used if the device is guaranteed to have a unique MAC address at construction time? -Derek _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Aug 06 19:20:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIBry-0006Sq-Ky; Mon, 06 Aug 2007 19:20:14 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IIBrx-0006Sf-CG for sip-confirm+ok@megatron.ietf.org; Mon, 06 Aug 2007 19:20:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIBrx-0006SX-2J for sip@ietf.org; Mon, 06 Aug 2007 19:20:13 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIBrv-0006PM-E9 for sip@ietf.org; Mon, 06 Aug 2007 19:20:13 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l76NJm23009601; Tue, 7 Aug 2007 02:19:52 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Aug 2007 02:19:48 +0300 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Aug 2007 02:19:48 +0300 Received: from [10.162.253.53] (essapo-nirac25353.europe.nokia.com [10.162.253.53]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l76NJjG4014373; Tue, 7 Aug 2007 02:19:46 +0300 Message-ID: <46B7ABEB.50207@nokia.com> Date: Tue, 07 Aug 2007 02:16:59 +0300 From: Aki Niemi User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: "ext DRAGE, Keith (Keith)" Subject: Re: [Sip] RE: Correction: WGLC for draft-ietf-sip-outbound References: <46928F5F.3080502@softarmor.com> <46966F52.9040004@softarmor.com> <5D1A7985295922448D5550C94DE2918001473D89@DEEXC1U01.de.lucent.com> In-Reply-To: <5D1A7985295922448D5550C94DE2918001473D89@DEEXC1U01.de.lucent.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Aug 2007 23:19:48.0604 (UTC) FILETIME=[486FABC0:01C7D880] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 Cc: sip@ietf.org, Cullen Jennings , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Here are my WGLC comments to sip-outbound-10. There may be duplicates as I've only been following others' comments on the surface. --- #1 First, the title says: Managing Client Initiated Connections in the Session Initiation Protocol (SIP) yet, the draft is really about managing registrations, with failover and reliability. For example, it is not at all clear how one would go about implementing these techniques in, say, subscriptions (this is the issue Markus brought up recently with the config-framework) #2 URI parameters are confusing. o First, I don't understand why the keepalive params are needed at all. It's simple, really: if the UAC opens a TCP flow, it needs to use CRLF. If it opens a UDP flow, it needs to use STUN. Or am I missing something? (In fact, I would like to see TCP-keepalives removed completely, as that just hurts interop.) o Justification for 'timed-keepalives' Why does the UA need to know beforehand that it needs to use the default interval keepalive? Could this not be returned in the 200 OK instead? All in all, I don't see the reason that these parameters need to be pre-configured to the UA as the draft suggests. Seems they are either self-evident (based on transport), or something the registrar/edge-proxy could return in a header field or parameter at register-time. Much cleaner IMHO. o In 3.2. example message: REGISTER sip:example.com;keep-crlf SIP/2.0 Why does this parameter need to be in the R-URI? o In 4.3. says: The UAC MUST also include an "ob" parameter in the Contact URI if, and only if, the UAC is sending the request over a flow for which the Registrar applied outbound processing. Isn't 'ob' only inserted by edge-proxies, and to Path? Furthermore, how can the UA know that "the Registrar applied outbound processing" to a flow that is just about to be formed? o In 5.3 says: The Edge Proxy can use the presence of the "ob" parameter in the UAC's Contact URI to determine if it should add a flow token. Hmm. I thought it was the reg-id. #3 Implementation strategy How is it intended that outbound support be added to a typical single registrar/proxy deployment today? The spec intentionally leaves configuration of a proxy-set open, but somehow assumes that one exists in order to use outbound. Couldn't the UA just attempt a REGISTER via the default NAPTR/SRV and just include reg-id and instance-ID? This option should be made the default in the absence of a specific a priori configuration in Section 4.2/4.3. #4 Keepalive timer values Like I've said in the past that 2 mins for TCP is way too low. Sure, the UA can extend it, unless of course the proxy mandates it with timed-keepalive param. And of course the proxy wants high reliability, which means the UA is hosed probably more often than it would like to ;) My question is: where did this 2 minutes come from? Is it based on some hard data, like empirical evidence or user experience studies? If not, how about 14 minutes instead? Much better on the battery and should still play nice with the NATs. #5 Retry timer calculation formula In 4.5: wait-time = min( max-time, (base-time * (2 ^ consecutive-failures))) These times MAY be configurable in the UA. The three times are: o max-time with a default of 1800 seconds o base-time-all-fail with a default of 30 seconds o base-time-not-failed with a default of 90 seconds But there are only two unknowns pertaining to time in the equation (there is no base-time-all-fail, or base-time-not-failed -- just base-time that apparently is 30 sec...). #6 Definition of a ping or a pong It should be explained in the spec that a ping is double CRLF, or any other traffic. And same goes for a pong. I.e., the UA should only consider a flow dead if it receives no CRLF nor any other traffic within 10 seconds of sending the ping. #7 Very minor things: o The justification for choosing STUN as the UDP keepalive mechanism is a little misleading. It was *claimed* that STUN would be less of a load to proxies than a SIP OPTIONS (or similar). However, this was never proven in practice. There were also people saying that parsing SIP is not the bottleneck -- network or memory I/O is, and on that front, STUN and SIP are equal. If anything, a SIP+STUN parser might actually have worse performance. Just for the record -- I've no interest to revisit the decision -- just getting the facts right ;) o In 3.3 The UA is configured with multiple outbound proxy registration URIs. These URIs are configured into the UA through whatever the normal mechanism is to configure the proxy or registrar address in the UA. The registrar address is not supposed to be configured. It is learned from the AoR, the name behind the '@' sign. ;) That's all Cheers, Aki ext DRAGE, Keith (Keith) wrote: > A reminder of the ongoing WGLC on the above document > > This WGLC period runs through IETF and hopefully close August 6, 2007. > > That gives you about a week after the end of IETF - please schedule some time for doing this. > > Regards > > Keith > > >> -----Original Message----- >> From: Dean Willis [mailto:dean.willis@softarmor.com] >> Sent: Thursday, July 12, 2007 7:14 PM >> To: Dean Willis >> Cc: sip@ietf.org; Cullen Jennings; DRAGE, Keith (Keith) >> Subject: Correction: WGLC for draft-ietf-sip-outbound >> >> Dean Willis wrote: >>> I'd like to start a long working group last call for: >>> >>> http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-09.txt >>> >> My error. This should have referred to >> draft-ietf-sip-outbound-10, not -09. It was busy working its >> way through the posting system and I grabbed a pointer to the >> wrong one. >> >> Sorry about that, folks. >> >> -- >> Dean >> >> > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Aug 06 23:09:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIFQ7-0003nu-2N; Mon, 06 Aug 2007 23:07:43 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IIFQ5-0003no-BU for sip-confirm+ok@megatron.ietf.org; Mon, 06 Aug 2007 23:07:41 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIFQ5-0003ng-0l for sip@ietf.org; Mon, 06 Aug 2007 23:07:41 -0400 Received: from web15312.mail.cnb.yahoo.com ([203.209.230.42]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IIFQ3-0004s0-P4 for sip@ietf.org; Mon, 06 Aug 2007 23:07:40 -0400 Received: (qmail 62633 invoked by uid 60001); 7 Aug 2007 03:07:35 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.cn; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=HDrhTtvzodeJtkQPLGP2UL5ip3MDlJiFKpdH8dW8Fn1lDIbd+qG9AtEs8nSxr7xEy/rTBN86dBfkgFztaXnuP2hiyyj1rJ+P/azP15RpT/rwnhgZMp3WeJ+NmhHWsNs/EEVAgc4YRWGfOuMKPI8SnNY6XJUg54eL8hstAnRrz7A=; X-YMail-OSG: mWgNJDQVM1k6r2GrB0UnYFsOxLZF3jliWIir87Xg2.XpMaRIy8CVLSTfQOWOdiRe13DOo68duCN8cZeDWY0v1o4Vdni36cUf_j6WyFaCFJT9muslYHU- Received: from [123.112.12.99] by web15312.mail.cnb.yahoo.com via HTTP; Tue, 07 Aug 2007 11:07:35 CST Date: Tue, 7 Aug 2007 11:07:35 +0800 (CST) From: ji ma To: sip@ietf.org MIME-Version: 1.0 Message-ID: <740811.61616.qm@web15312.mail.cnb.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Subject: [Sip] Should 420 be returned when UAS(not server) can't support the extension? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1761322780==" Errors-To: sip-bounces@ietf.org --===============1761322780== Content-Type: multipart/alternative; boundary="0-420015855-1186456055=:61616" Content-Transfer-Encoding: 8bit --0-420015855-1186456055=:61616 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 8bit Hi folks: I have some doubt about whether a UAS which is not a server(such as a handphone) will return 420 Bad Extension when it doesn't support the extension specified in Require header. As 21.4.15 said: The server did not understand the protocol extension specified in a Proxy-Require (Section 20.29) or Require (Section 20.32) header field. The server MUST include a list of the unsupported extensions in an Unsupported header field in the response. UAC processing of this response is described in Section 8.1.3.5. So if not, which response should be returned? Regards, Ma Ji --------------------------------- ÇÀ×¢ÑÅ»¢Ãâ·ÑÓÊÏä3.5GÈÝÁ¿£¬20M¸½¼þ£¡ --0-420015855-1186456055=:61616 Content-Type: text/html; charset=gb2312 Content-Transfer-Encoding: 8bit
Hi folks:
 
    I have some doubt about whether a UAS which is not a server(such as a handphone) will return 420 Bad Extension when it doesn't support the extension specified in Require header.
 
As 21.4.15 said:
   The server did not understand the protocol extension specified in a
   Proxy-Require (Section 20.29) or Require (Section 20.32) header
   field.  The server MUST include a list of the unsupported extensions
   in an Unsupported header field in the response.  UAC processing of
   this response is described in Section 8.1.3.5.
 
So if not, which response should be returned?
 
 
 
Regards,
Ma Ji

ÇÀ×¢ÑÅ»¢Ãâ·ÑÓÊÏä3.5GÈÝÁ¿£¬20M¸½¼þ£¡ --0-420015855-1186456055=:61616-- --===============1761322780== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1761322780==-- From sip-bounces@ietf.org Tue Aug 07 01:00:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIHB9-0005Zd-LX; Tue, 07 Aug 2007 01:00:23 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IIHB7-0005OJ-St for sip-confirm+ok@megatron.ietf.org; Tue, 07 Aug 2007 01:00:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIHB7-0005ME-G9 for sip@ietf.org; Tue, 07 Aug 2007 01:00:21 -0400 Received: from gws04.mail.hcl.in ([203.105.186.20] helo=gws04.hcl.in) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IIHB1-00077P-3K for sip@ietf.org; Tue, 07 Aug 2007 01:00:21 -0400 Received: from gws04.hcl.in (gws04 [10.249.64.135]) by localhost.hcl.in (Postfix) with ESMTP id 60700360132 for ; Tue, 7 Aug 2007 10:27:58 +0530 (IST) Received: from chn-egw02-out.corp.hcl.in (unknown [10.249.64.38])by gws04.hcl.in (Postfix) with ESMTP id 3DFAB360124for ; Tue, 7 Aug 2007 10:27:58 +0530 (IST) Received: from CHN-HCLT-EVS02.HCLT.CORP.HCL.IN ([10.101.26.15]) by chn-egw02-out.corp.hcl.in with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Aug 2007 10:30:10 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 7 Aug 2007 10:28:39 +0530 Message-ID: <66E8AEE9980BB44CA5FCAD39EBA56AC602012E7B@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Authentication through WDS. Thread-Index: AcfYAhcrl+7B6CxORy2xd7DHb2YAyQArYFng From: "Anand Kumaravel, TLS-Chennai" To: X-OriginalArrivalTime: 07 Aug 2007 05:00:10.0301 (UTC) FILETIME=[D4B756D0:01C7D8AF] X-imss-version: 2.047 X-imss-result: Passed X-imss-scanInfo: M:P L:E SM:0 X-imss-tmaseResult: TT:0 TS:0.0000 TC:00 TRN:0 TV:3.6.1039(15346.003) X-imss-scores: Clean:94.02619 C:2 M:3 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 Subject: [Sip] Authentication through WDS. X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0484779662==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0484779662== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7D8AF.9EE138DD" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7D8AF.9EE138DD Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 =20 Hi All, We are planning to integrate authentication mechanism in SIP with Windows Active Directory (WDS)=2E Such that, when an UA sends its digest response for incoming 401/407, the proxy in some mechanism has to contact the active directory to confirm the authentication of the user=2E=20 But SIP supports authentication through digest and we are not sure whether the same is supported by WDS and we also learnt that WDS will not give the password but will only conform the correctness of the password given=2E =20 It will be helpful if anyone can through some light on how this can be achieved=2E =20 Thanks in advance, Anand, =20 DISCLAIMER: ---------------------------------------------------------------------------= -------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and= intended for the named recipient(s) only=2E It shall not attach any liability on the originator or HCL or its= affiliates=2E Any views or opinions presented in=20 this email are solely those of the author and may not necessarily reflect= the opinions of HCL or its affiliates=2E Any form of reproduction, dissemination, copying, disclosure, modification,= distribution and / or publication of=20 this message without the prior written consent of the author of this e-mail= is strictly prohibited=2E If you have=20 received this email in error please delete it and notify the sender= immediately=2E Before opening any mail and=20 attachments please check them for viruses and defect=2E ---------------------------------------------------------------------------= -------------------------------------------- ------_=_NextPart_001_01C7D8AF.9EE138DD Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

Hi All,

         &n= bsp;  We are planning to integrate authentication mechanism in SIP with Windows Active Directory (WDS)=2E

Such that, when an UA sends its digest response for= incoming 401/407, the proxy in some mechanism has to contact the active directory to= confirm the authentication of the user=2E

But SIP supports authentication through digest and we= are not sure whether the same is supported by WDS and we also learnt that WDS= will not give the password but will only conform the correctness of the password= given=2E

 

It will be helpful if anyone can through some light on= how this can be achieved=2E

 

Thanks in advance,

Anand,

 

DISCLAIMER:
---------------------------------------------------------------------------= --------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and= intended for the named recipient(s) only=2E
It shall not attach any liability on the originator or HCL or its= affiliates=2E Any views or opinions presented in
this email are solely those of the author and may not necessarily reflect= the opinions of HCL or its affiliates=2E
Any form of reproduction, dissemination, copying, disclosure, modification,= distribution and / or publication of
this message without the prior written consent of the author of this e-mail= is strictly prohibited=2E If you have
received this email in error please delete it and notify the sender= immediately=2E Before opening any mail and
attachments please check them for viruses and defect=2E

---------------------------------------------------------------------------= --------------------------------------------
------_=_NextPart_001_01C7D8AF.9EE138DD-- --===============0484779662== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0484779662==-- From sip-bounces@ietf.org Tue Aug 07 03:50:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIJpo-0006aE-6x; Tue, 07 Aug 2007 03:50:32 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IIJpn-0006a8-9h for sip-confirm+ok@megatron.ietf.org; Tue, 07 Aug 2007 03:50:31 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIJpm-0006a0-VE for sip@ietf.org; Tue, 07 Aug 2007 03:50:31 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IIJpm-0002gR-Bb for sip@ietf.org; Tue, 07 Aug 2007 03:50:30 -0400 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JME0009N8FOWJ@siemenscomms.co.uk> for sip@ietf.org; Tue, 07 Aug 2007 08:50:12 +0100 (BST) Date: Tue, 07 Aug 2007 08:50:27 +0100 From: "Elwell, John" Subject: RE: [Sip] Should 420 be returned when UAS(not server) can't support theextension? In-reply-to: <740811.61616.qm@web15312.mail.cnb.yahoo.com> To: ji ma , sip@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D026EACB@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: [Sip] Should 420 be returned when UAS(not server) can't support theextension? Thread-Index: AcfYoDaK4g40rTwdQZa7LUbDL7GBEgAJ1eTw Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <740811.61616.qm@web15312.mail.cnb.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2040876747==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============2040876747== Content-type: multipart/alternative; boundary="Boundary_(ID_tgYxqJY4zh9yoKrFAYqQ1A)" Content-class: urn:content-classes:message This is a multi-part message in MIME format. --Boundary_(ID_tgYxqJY4zh9yoKrFAYqQ1A) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable A UAS is a server - User Agent Server =20 John ________________________________ From: ji ma [mailto:mjhorse1984@yahoo.com.cn]=20 Sent: 07 August 2007 04:08 To: sip@ietf.org Subject: [Sip] Should 420 be returned when UAS(not server) can't = support theextension? =09 =09 Hi folks: =20 I have some doubt about whether a UAS which is not a server(such as = a handphone) will return 420 Bad Extension when it doesn't support the = extension specified in Require header. =20 As 21.4.15 said: The server did not understand the protocol extension specified in a Proxy-Require (Section 20.29) or Require (Section 20.32) header field. The server MUST include a list of the unsupported extensions in an Unsupported header field in the response. UAC processing of this response is described in Section 8.1.3.5. =20 So if not, which response should be returned? =20 =20 =20 Regards, Ma Ji =09 =09 ________________________________ = =C7=C0=D7=A2=D1=C5=BB=A2=C3=E2=B7=D1=D3=CA=CF=E43.5G=C8=DD=C1=BF=A3=AC20M= =B8=BD=BC=FE=A3=A1 =20 --Boundary_(ID_tgYxqJY4zh9yoKrFAYqQ1A) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable
A UAS is a server - User Agent = Server
 
John

From: ji ma = [mailto:mjhorse1984@yahoo.com.cn]=20
Sent: 07 August 2007 04:08
To:=20 sip@ietf.org
Subject: [Sip] Should 420 be returned when = UAS(not=20 server) can't support theextension?

Hi folks:
 
    I have some doubt about whether a UAS which is = not a=20 server(such as a handphone) will return 420 Bad Extension when = it doesn't=20 support the extension specified in Require header.
 
As 21.4.15 said:
   The = server=20 did not understand the protocol extension specified in = a
  =20 Proxy-Require (Section 20.29) or Require (Section 20.32)=20 header
   field.  The server MUST include a list of = the=20 unsupported extensions
   in an Unsupported header field = in the=20 response.  UAC processing of
   this response is = described=20 in Section 8.1.3.5.
 
So if not, which response should be returned?
 
 
 
Regards,
Ma Ji

=C7=C0=D7=A2=D1=C5=BB=A2=C3=E2=B7=D1=D3=CA=CF=E43.5G=C8=DD= =C1=BF=A3=AC20M=B8=BD=BC=FE=A3=A1=20 --Boundary_(ID_tgYxqJY4zh9yoKrFAYqQ1A)-- --===============2040876747== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============2040876747==-- From sip-bounces@ietf.org Tue Aug 07 03:53:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIJt2-0000SQ-EO; Tue, 07 Aug 2007 03:53:52 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IIJt0-0000SG-NY for sip-confirm+ok@megatron.ietf.org; Tue, 07 Aug 2007 03:53:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIJsz-0000S8-3r for sip@ietf.org; Tue, 07 Aug 2007 03:53:50 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIJsx-0007Cr-Jp for sip@ietf.org; Tue, 07 Aug 2007 03:53:49 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l777rSRg009771; Tue, 7 Aug 2007 10:53:41 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Aug 2007 10:53:00 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Aug 2007 10:53:00 +0300 Received: from [10.144.23.115] ([10.144.23.115]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Aug 2007 10:53:00 +0300 Message-ID: <46B824DC.4040405@nsn.com> Date: Tue, 07 Aug 2007 10:53:00 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "Anand Kumaravel, TLS-Chennai" Subject: Re: [Sip] Authentication through WDS. References: <66E8AEE9980BB44CA5FCAD39EBA56AC602012E7B@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> In-Reply-To: <66E8AEE9980BB44CA5FCAD39EBA56AC602012E7B@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Aug 2007 07:53:00.0292 (UTC) FILETIME=[F9B66440:01C7D8C7] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Anand: I know little about the Windows Active Directory, but perhaps I can throw some information that may give you some ideas. Deployments are using two centralized authentication servers: RADIUS or Diameter servers. When using a RADIUS/Diameter server, a SIP proxy server acts as a RADIUS/Diameter client, contacts the RADIUS/Diameter server with the user's credentials, which authenticates the user, and provides the appropriate response. The documents to look at are: - RFC 4590: RADIUS Extension for Digest Authentication - RFC 4740: Diameter SIP Application. I think are you looking at replacing any of these two RFCs by whatever protocol the Windows Active Directory use. /Miguel Anand Kumaravel, TLS-Chennai wrote: > > > > > Hi All, > > We are planning to integrate authentication mechanism in SIP > with Windows Active Directory (WDS). > > Such that, when an UA sends its digest response for incoming 401/407, > the proxy in some mechanism has to contact the active directory to > confirm the authentication of the user. > > But SIP supports authentication through digest and we are not sure > whether the same is supported by WDS and we also learnt that WDS will > not give the password but will only conform the correctness of the > password given. > > > > It will be helpful if anyone can through some light on how this can be > achieved. > > > > Thanks in advance, > > Anand, > > > > DISCLAIMER: > ----------------------------------------------------------------------------------------------------------------------- > > The contents of this e-mail and any attachment(s) are confidential and > intended for the named recipient(s) only. > It shall not attach any liability on the originator or HCL or its > affiliates. Any views or opinions presented in > this email are solely those of the author and may not necessarily > reflect the opinions of HCL or its affiliates. > Any form of reproduction, dissemination, copying, disclosure, > modification, distribution and / or publication of > this message without the prior written consent of the author of this > e-mail is strictly prohibited. If you have > received this email in error please delete it and notify the sender > immediately. Before opening any mail and > attachments please check them for viruses and defect. > > ----------------------------------------------------------------------------------------------------------------------- > > > ------------------------------------------------------------------------ > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Miguel A. Garcia tel:+358-50-4804586 Nokia Siemens Networks Espoo, 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 sip-bounces@ietf.org Tue Aug 07 10:57:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIQUb-000485-17; Tue, 07 Aug 2007 10:57:05 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IIQUZ-00046b-Hj for sip-confirm+ok@megatron.ietf.org; Tue, 07 Aug 2007 10:57:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIQUZ-00046O-7S for sip@ietf.org; Tue, 07 Aug 2007 10:57:03 -0400 Received: from tcmail23.telekom.de ([217.6.95.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIQUX-0006Zj-LV for sip@ietf.org; Tue, 07 Aug 2007 10:57:03 -0400 Received: from S4DE9JSAANM.ost.t-com.de (S4DE9JSAANM.ost.t-com.de [10.125.177.122]) by tcmail21.telekom.de with ESMTP; Tue, 7 Aug 2007 16:56:08 +0200 Received: from S4DE9JSAAIG.ost.t-com.de ([10.125.177.192]) by S4DE9JSAANM.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Aug 2007 16:56:08 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MIMEOLE: Produced By Microsoft Exchange V6.5 Subject: AW: [Sip] Authentication through WDS. Date: Tue, 7 Aug 2007 16:56:07 +0200 Message-Id: <1E4CCB2441C5C0409AD8A929482A09F31BB7E7@S4DE9JSAAIG.ost.t-com.de> In-Reply-To: <66E8AEE9980BB44CA5FCAD39EBA56AC602012E7B@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Authentication through WDS. Thread-Index: AcfYAhcrl+7B6CxORy2xd7DHb2YAyQArYFngABSpkWA= From: "Beck01, Wolfgang" To: , X-OriginalArrivalTime: 07 Aug 2007 14:56:08.0166 (UTC) FILETIME=[16108860:01C7D903] X-Spam-Score: -1.0 (-) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Anand wrote: > We are planning to integrate authentication mechanism in SIP with Windows Active Directory (WDS). WDS seems to be based on LDAP. http://www.apan.net/meetings/tokyo2006/presentation/ser-auth-radius-ldap .pdf describes a setup where the SIP proxy queries a RADIUS server (using RfC 4590 or an early version of the draft), which queries an LDAP server for the password. It might be possible to use FreeRadius with WDS that way. Not the most elegant solution. Wolfgang _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Aug 07 15:43:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIUxU-0007cP-K8; Tue, 07 Aug 2007 15:43:12 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IIUxQ-0007ax-Ek for sip-confirm+ok@megatron.ietf.org; Tue, 07 Aug 2007 15:43:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIUxP-0007am-4q for sip@ietf.org; Tue, 07 Aug 2007 15:43:08 -0400 Received: from estacado-pt.tunnel.tserv2.fmt.ipv6.he.net ([2001:470:1f03:266::2] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIUxM-0000l0-HC for sip@ietf.org; Tue, 07 Aug 2007 15:43:07 -0400 Received: from [172.17.2.60] ([172.17.2.60]) (authenticated bits=0) by vicuna.estacado.net (8.14.1/8.14.1) with ESMTP id l77JgsPr052360 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 7 Aug 2007 14:42:55 -0500 (CDT) (envelope-from bcampen@estacado.net) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D020638F@GBNTHT12009MSX.gb002.siemens.net> References: <0D5F89FAC29E2C41B98A6A762007F5D020638F@GBNTHT12009MSX.gb002.siemens.net> Message-Id: From: Byron Campen Subject: Re: [Sip] WGLC comments on sip-outbound-10 Date: Tue, 7 Aug 2007 14:42:51 -0500 To: Cullen Jennings , Rohan Mahy , SIP IETF X-Mailer: Apple Mail (2.752.3) X-Spam-Score: -1.4 (-) X-Scan-Signature: f1365f29d5c3f875a511b3c836c51021 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2065157995==" Errors-To: sip-bounces@ietf.org --===============2065157995== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-4--97338576; protocol="application/pkcs7-signature" --Apple-Mail-4--97338576 Content-Type: multipart/alternative; boundary=Apple-Mail-3--97342665 --Apple-Mail-3--97342665 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Re-sending this since it has been a while, and to get it in the same thread as some of the other reviews. ******************************************************************** Here's the notes from my first pass. NITS/editorial: Sec 3.2 "The UA can also include a reg-id parameter which..." Are we not assuming the UA is trying to do outbound? Sec 4.2 "This specification assumes the set is determined via any of a number of configuration mechanisms, and future specifications can define additional mechanisms such as using DNS to discover this set." Seems like this sentence is unnecessary. If you really feel the need to explicitly call out the fact that multiple mechanisms may exist, and that these mechanisms will be defined in future standards, you could maybe say something like: "The mechanism or mechanisms used to configure UAs are outside the scope of this specification, and will be defined in future specifications." If you feel the need to mention a configuration mechanism based on DNS, you might want to move it away from the statement that says "out of scope" ;) Sec 4.2.1 It is probably obvious that third-party registrations cannot use outbound, but it helps the flow if you lead off with this statement. Sec 4.3 "Unless there are privacy reason not to include an instance-id," Mixing singular and plural. Sec 4.4 "For UDP, the upper bound of 29 seconds was selected so that multiple STUN packets could be sent before 30 seconds based on information that many NATs have UDP timeouts as low as 30 seconds. " Kinda awkward. I think you could trim out the "so that multiple STUN packets could be sent before 30 seconds" without sacrificing clarity. eg. "For UDP, the upper bound of 29 seconds was selected based on information that many NATs have UDP timeouts as low as 30 seconds. " Sec 4.5 "...at least one consecutive keepalive response was received." "...at least two consecutive keepalive responses were received."? Sec 5.1 " When an Edge Proxy receives a registration request with a reg-id header parameter in the Contact header field, it needs to determine if it (the edge proxy) will have to be visited for any subsequent requests sent to the user agent identified in the Contact header field, or not. If the Edge Proxy determines that this is the case, it inserts its URI in a Path header field value as described in RFC 3327 [5]. If the Edge Proxy is the first SIP node after the UAC, it either MUST store a "flow token"--containing information about the flow from the previous hop--in its Path URI, or reject the request. The flow token MUST be an identifier that is unique to this network flow. The flow token MAY be placed in the userpart of the URI. In addition, the first node MUST include an 'ob' URI parameter in its Path header field value. If the Edge Proxy is not the first SIP node after the UAC it MUST NOT place an 'ob' URI parameter in a Path header field value. The Edge Proxy can determine if it is the first hop by examining the Via header field. " This is a little awkward/rambling. Here's my shot at making it easier to read. " When an Edge Proxy receives a registration request with a reg-id header parameter in the Contact header field, it must determine whether it is the first SIP node after the UAC. The Edge Proxy can determine if it is the first hop by examining the Via header field. If the edge proxy is the first SIP node after the UAC, it MUST insert a Path header field value, whose URI MUST contain both a flow-token and an 'ob' parameter, or it MUST reject the request. The flow token MUST be a unique identifier for the network flow from the previous hop, and MAY be placed in the userpart of the URI. If the Edge Proxy is not the first SIP node after the UAC, it MAY still insert a Path header field value as described in RFC 3327 [5], but this value MUST NOT contain an 'ob' URI param. " Sec 6, para 7 "The Registrar MUST include the 'outbound' option-tag (defined in Section (Section 12.1)) " Looks like an xref is not doing what you intended. Sec 6, para 7 "Furthermore, the Registrar MUST NOR include this option-tag..." Sec 6, para 7 "Note that the requirements in this section applies to... " Mixing singlar and plural. Sec 6, para 8 "To be compliant with this specification, registrars which can receive SIP requests directly from a UAC without intervening edge proxies MUST implement STUN NAT Keepalives on its SIP UDP ports as described in Section 8 and when it receives a double-CRLF sequence on a connection oriented transport such as TCP or SCTP, it MUST immediately respond with a single CRLF over the same connection." Awkward, how about: " Registrars that can receive SIP requests directly from a UAC (ie, without intervening edge proxies) are required to implement the same keepalive mechanisms as edge proxies (see Sec 5.4). " Sec 6, as a whole It felt like the logic for determining whether outbound processing should be done was excessively spread out in this section. I could propose alternate text if you like. Sec 7 " The proxy uses normal forwarding rules looking at the next-hop target of the message and the value of any stored Path header field vector in the registration binding to decide how to forward the request and populate the Route header in the request. If the proxy stored information about the flow over which it received the REGISTER for the binding, then the proxy MUST send the request over the same 'logical flow' saved with the binding that is known to deliver data to the specific target UA instance. " Awkward. How about: " When the Authoritative Proxy doubles as a registrar, targets may have flow information associated with them (see Sec 6). When forwarding a request to a target that is associated with a flow, the proxy MUST send the request over said flow. Otherwise, the proxy will forward the request as it would normally. " Minor technical: (Where should this go?) Probably should mention that an endpoint using outbound will not be able to target-refresh if the edge proxy uses Record-Routes to store flow-tokens (provided the Dialog was established over a flow). This is because the edge proxy would end up routing according to flow- tokens in the Route-Set, which is invariant (ie, not effected by a target-refresh at all). Sec 4.4.3 What if STUN requests are not answered? How many unanswered STUN requests must go by before the UA considers the flow dead? Will the occasional dropped UDP packet be sufficient evidence that the flow is dead? Sec 8 "When a URI is created that refers to a SIP node that supports STUN as described in this section, the 'keep-stun' URI parameter, as defined in Section 12 MUST be added to the URI." This can be interpreted as saying "If your server element supports STUN, every single URI you create that refers to it needs to have a keep-stun param." I don't know if this is what you intended. There might be valid reasons for not wanting to advertise STUN support on every URI you mint (indeed, not every such URI will be useful; what good will having 'keep-stun' in a Route header be, for example?) Sec 8.1 "When STUN is used together with SigComp [24] compressed SIP messages over the same flow, how the STUN messages are sent depends on the transport protocol. For UDP flows, the STUN messages are simply sent uncompressed, "outside" of SigComp." Since STUN is only used over UDP, we can get rid of the "depends on transport protocol" stuff. Major technical: No problems. Best regards, Byron Campen --Apple-Mail-3--97342665 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
= Re-sending this since it has been a while, and to get it in the = same thread as some of the other reviews.


Here's the notes from my first = pass.

NITS/editorial:

Sec = 3.2
"The UA can also include a = reg-id parameter which..."

Are we not assuming the UA is trying to do = outbound?

Sec 4.2
"This specification assumes the set
=A0=A0 is determined via any of a number of = configuration mechanisms, and
=A0=A0 future = specifications can define additional mechanisms such as using
=A0=A0 DNS to discover this set."

Seems like = this sentence is unnecessary. If you really feel the need to explicitly = call out the fact that multiple mechanisms may exist, and that these = mechanisms will be defined in future standards, you could maybe say = something like:

"The mechanism or mechanisms used to configure UAs = are outside the scope of this specification, and will be defined in = future specifications."

If you feel the need to mention a configuration = mechanism based on DNS, you might want to move it away from the = statement that says "out of scope" ;)
Sec 4.2.1
It is probably obvious that third-party = registrations cannot use outbound, but it helps the flow if you lead off = with this statement.

Sec 4.3
"Unless there are
=A0=A0 = privacy reason not to include an instance-id,"
Mixing singular and plural.

Sec = 4.4
"For UDP, the upper bound of = 29
=A0 =A0 =A0 seconds was selected so that = multiple STUN packets could be sent
=A0 =A0 =A0 = before 30 seconds based on information that many NATs have UDP
=A0 =A0 =A0 timeouts as low as 30 seconds.=A0 = "

Kinda = awkward. I think you could trim out the "so that multiple STUN packets = could be sent before 30 seconds" without sacrificing clarity.

eg.
"For UDP, the upper bound of 29
=A0 =A0 =A0 seconds was selected based on = information that many NATs have UDP
=A0 =A0 =A0 = timeouts as low as 30 seconds. "

Sec 4.5
"...at least one consecutive keepalive response was = received."

"...at least two consecutive keepalive responses = were received."?

Sec 5.1
"=A0=A0 When an Edge Proxy receives a registration = request with a reg-id
=A0=A0 header parameter in = the Contact header field, it needs to determine
=A0=A0 if it (the edge proxy) will have to be = visited for any subsequent
=A0=A0 = requests sent to the user agent identified in the Contact = header
=A0=A0 field, or not.=A0 If the = Edge Proxy determines that this is the case,
=A0=A0 it inserts its URI in a Path header field = value as described in RFC
=A0=A0 3327 = [5].=A0 If the Edge Proxy is the first SIP node after the UAC, = it
=A0=A0 either MUST store a "flow = token"--containing information about the
=A0=A0 = flow from the previous hop--in its Path URI, or reject the = request.
=A0=A0 The flow token MUST be an = identifier that is unique to this network
=A0=A0 = flow.=A0 The flow token MAY be placed in the userpart of the URI.=A0 = In
=A0=A0 addition, the first node MUST include an = 'ob' URI parameter in its
=A0=A0 Path = header field value.=A0 If the Edge Proxy is not the first SIP = node
=A0=A0 after the UAC it MUST NOT = place an 'ob' URI parameter in a Path
=A0=A0 = header field value.=A0 The Edge Proxy can determine if it is the = first
=A0=A0 hop by examining the Via = header field.
"
This is a little = awkward/rambling. Here's my shot at making it easier to read.

"=A0=A0 When = an Edge Proxy receives a registration request with a reg-id
=A0=A0 header parameter in the Contact header field, = it must determine
=A0=A0 whether it is the first = SIP node after the UAC. The Edge Proxy can
=A0=A0 = determine if it is the first hop by examining the Via header = field.

=A0=A0

=A0=A0 If the edge proxy is the first SIP node after = the UAC, it MUST insert
=A0=A0 a Path = header field value, whose URI MUST contain both a flow-token
=A0=A0 and an 'ob' parameter, or it MUST reject the = request. The flow token
=A0=A0 MUST = be a unique identifier for the network flow from the previous
=A0=A0 hop, and MAY be placed in the userpart of the = URI.

=A0=A0

=A0=A0 If the Edge Proxy is not the first SIP node = after the UAC, it MAY
=A0=A0 still insert a Path = header field value as described in RFC 3327 [5],
=A0=A0 but this value MUST NOT contain an 'ob' URI = param.
=A0=A0 "

Sec 6, = para 7
"The Registrar MUST include the = 'outbound' option-tag (defined in
=A0=A0 = Section (Section 12.1)) "

Looks like an xref is not doing what you = intended.

Sec 6, para 7
"Furthermore, the Registrar MUST NOR
=A0=A0 include this option-tag..."

Sec 6, = para 7
"Note that the requirements in = this section
=A0=A0 applies to... "
Mixing singlar and plural.

Sec 6, = para 8
"To be compliant with this = specification, registrars which can receive
=A0=A0 = SIP requests directly from a UAC without intervening edge = proxies
=A0=A0 MUST implement STUN NAT = Keepalives on its SIP UDP ports as described
=A0=A0 in Section 8 and when it receives a = double-CRLF sequence on a
=A0=A0 = connection oriented transport such as TCP or SCTP, it MUST
=A0=A0 immediately respond with a single CRLF over = the same connection."

Awkward, how about:
"
without intervening edge = proxies) are required to implement the same
"

Sec 6, as a whole

It felt like = the logic for determining whether outbound processing should be done was = excessively spread out in this section. I could propose alternate text = if you like.=A0 =A0 =A0=A0 =A0

Sec 7
"
=A0=A0 The proxy uses = normal forwarding rules looking at the next-hop target
=A0=A0 of the message and the value of any stored = Path header field vector
=A0=A0 in the = registration binding to decide how to forward the request and
=A0=A0 populate the Route header in the request.=A0 = If the proxy stored
=A0=A0 information about = the flow over which it received the REGISTER for
=A0=A0 the binding, then the proxy MUST send the = request over the same
=A0=A0 'logical flow' saved = with the binding that is known to deliver data
=A0=A0 to the specific target UA instance.
"

Awkward. How about:
"
=A0=A0 = When the Authoritative Proxy doubles as a registrar, targets may = have
=A0=A0 flow information = associated with them (see Sec 6). When forwarding a
=A0=A0 request to a target that is associated with a = flow, the proxy MUST
=A0=A0 send the request = over said flow. Otherwise, the proxy will forward
=A0=A0 the request as it would normally.
"

Minor technical:

(Where should = this go?)
Probably should mention that an = endpoint using outbound will not be able to target-refresh if the edge = proxy uses Record-Routes to store flow-tokens (provided the Dialog was = established over a flow). This is because the edge proxy would end up = routing according to flow-tokens in the Route-Set, which is invariant = (ie, not effected by a target-refresh at all).

Sec = 4.4.3
What if STUN requests are not = answered? How many unanswered STUN requests must go by before the UA = considers the flow dead? Will the occasional dropped UDP packet be = sufficient evidence that the flow is dead?
Sec 8
"When a URI is created that refers to a SIP node = that supports STUN as
=A0=A0 described in this = section, the 'keep-stun' URI parameter, as defined
=A0=A0 in Section 12 MUST be added to the = URI."

This can be interpreted as saying "If your server = element supports STUN, every single URI you create that refers to it = needs to have a keep-stun param." I don't know if this is what you = intended. There might be valid reasons for not wanting to advertise STUN = support on every URI you mint (indeed, not every such URI will be = useful; what good will having 'keep-stun' in a Route header be, for = example?)

Sec 8.1
"When STUN is used together with SigComp [24] = compressed SIP messages
=A0=A0 over = the same flow, how the STUN messages are sent depends on the
=A0=A0 transport protocol.=A0 For UDP flows, the = STUN messages are simply sent
=A0=A0 = uncompressed, "outside" of SigComp."

Since STUN is only used over UDP, we can get rid of = the "depends on transport protocol" stuff.

Major technical:

No = problems.


Best = regards,
Byron Campen

= --Apple-Mail-3--97342665-- --Apple-Mail-4--97338576 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGKTCCAuIw ggJLoAMCAQICEAda7Ce+sudhzrOd9CS5wJQwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDkyNTE0NDUzNloXDTA3MDkyNTE0NDUz NlowRjEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUYmNh bXBlbkBlc3RhY2Fkby5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDWxjwykU0M R1yTjA3db2wzExKsMhLa/mc2ekFkBP9BVXi4OHacKSZM3a9T0bWvPcw97ycBfDZX3q2prMRsPUep svJWA0wbiWyOtLzuQGWaQQ6rYbvYlRxil/teAJb1fAKdfFXIXXsiqcdHkhbFn/J7oSn1BCz6v9/v M1zgGNeMPIR34bo9A0hW+QZJxwkSg4KZHdaQ50WcKXtdHdBg46s+0bvDqNmmt7eP91UJk9aiyxyw ZdWVNxzF1oj+nfsnsaHv1py6l62Je82mHsvIZwdSAic1PtXVpU8QmkLJHPmkBEVtN/uHMQ95xgxi eFO5hbYuAT9f7V0ZGe7pUJBR3KwdAgMBAAGjMTAvMB8GA1UdEQQYMBaBFGJjYW1wZW5AZXN0YWNh ZG8ubmV0MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEAeJC75lz4KrtNdPOovb3fkqzD i2HXuOtYHCTOPMc5xJGLdqSF5sc8bwd4mIfevi9Ji4Ccj85A6qINQM/v4OjAvxPkwRwXey/YN6kl 19Te3Eh/t9l4zo2wPdbHTipyc8YJ0GAtT4/fwWiboW3+aquk8DGc7ityr9cdAYY1jAud7d0wggM/ MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2Vz dGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5n MSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWls QHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB AMSmPFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO 3cnwK4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gE f6e20TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6 MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNy bDALBgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4 MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYv wPQcUCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bG CE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDEDCCAwwCAQEwdjBiMQswCQYDVQQG EwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEAda7Ce+sudhzrOd9CS5wJQwCQYFKw4D AhoFAKCCAW8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwODA3 MTk0MjUxWjAjBgkqhkiG9w0BCQQxFgQUsU2bQhw3RSJ6m1hk+4M2YPhJP74wgYUGCSsGAQQBgjcQ BDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHWuwnvrLn Yc6znfQkucCUMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAhAHWuwnvrLnYc6znfQkucCUMA0GCSqGSIb3DQEBAQUABIIBAHxbZvrc 8xHnw4Q8ISe7Ni+4vDeX/GzdCQfLQon7Ojb9H4ZJpvc6b8JhgocAin8pmCbDvFevWWEjioypVS1X +/yBFFUecJZb6VybjLf1w8SE+727HDWlfVnvAWRnwncPt7+EBo8kF5Zn92cih8A/I/bPIqFSMEw4 vaLA4rHqUWiRZKw+TD7wdN6OAT7wleHfTPl08LkN8M900yz7SOtmuQk4a6NZ6mCQ4pwrxUH70FfA 2wotMg+hUTGR9TIAqXf3g8yNuTe7/AwE7tuxfa4WHQDEz8tRmxPkv1WYBBa8D4YpFrfCmY66x/Ju jlj8qU9LSZ8wYdb7C5SGf6kH/x7xblQAAAAAAAA= --Apple-Mail-4--97338576-- --===============2065157995== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============2065157995==-- From sip-bounces@ietf.org Tue Aug 07 16:58:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIW7j-0008Jb-MY; Tue, 07 Aug 2007 16:57:51 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IIW7i-0008JT-9P for sip-confirm+ok@megatron.ietf.org; Tue, 07 Aug 2007 16:57:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIW7h-0008JG-Vv for sip@ietf.org; Tue, 07 Aug 2007 16:57:49 -0400 Received: from alnrmhc15.comcast.net ([204.127.225.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIW7g-0002wk-Q3 for sip@ietf.org; Tue, 07 Aug 2007 16:57:49 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (alnrmhc15) with ESMTP id <20070807205748b1500a334te>; Tue, 7 Aug 2007 20:57:48 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l77Kvl8t013959 for ; Tue, 7 Aug 2007 16:57:47 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l77Kvle8013955; Tue, 7 Aug 2007 16:57:47 -0400 Date: Tue, 7 Aug 2007 16:57:47 -0400 Message-Id: <200708072057.l77Kvle8013955@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <740811.61616.qm@web15312.mail.cnb.yahoo.com> (mjhorse1984@yahoo.com.cn) Subject: Re: [Sip] Should 420 be returned when UAS(not server) can't support the extension? References: <740811.61616.qm@web15312.mail.cnb.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: ji ma I have some doubt about whether a UAS which is not a server (such as a handphone) will return 420 Bad Extension when it doesn't support the extension specified in Require header. In regard to SIP, "UAS" means "user agent server", which means "in regard to the SIP request under discussion, the user agent which receives the request and generates the response". Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Aug 08 14:22:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIq9W-0007YY-Dr; Wed, 08 Aug 2007 14:21:02 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IIq9V-0007Xq-7V for sip-confirm+ok@megatron.ietf.org; Wed, 08 Aug 2007 14:21:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIq9U-0007Xi-Tu for sip@ietf.org; Wed, 08 Aug 2007 14:21:00 -0400 Received: from rwcrmhc12.comcast.net ([216.148.227.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIq9T-0007pA-Mv for sip@ietf.org; Wed, 08 Aug 2007 14:21:00 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (rwcrmhc12) with ESMTP id <20070808182058m1200dic65e>; Wed, 8 Aug 2007 18:20:58 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l78IKv8t011060 for ; Wed, 8 Aug 2007 14:20:57 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l78IKvAp011056; Wed, 8 Aug 2007 14:20:57 -0400 Date: Wed, 8 Aug 2007 14:20:57 -0400 Message-Id: <200708081820.l78IKvAp011056@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <46A24E6F.1060402@cisco.com> (pkyzivat@cisco.com) Subject: Re: [Sip] Comment on draft-ietf-sip-fork-loop-fix-05 References: <46A13517.8000406@cisco.com> <200707211409.l6LE95fj009615@dragon.ariadne.com> <46A24E6F.1060402@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: Paul Kyzivat Yes, if the obfuscating proxy performs the loop checking based on its own Via. But if you have *two* obfuscating proxies in the loop then I think it becomes impossible to detect the loop. In a way, this is similar the a loop that includes both a sip leg and a PSTN leg. I don't have a good solution for either of these. I think that we can/should add a restriction to the text that is binding on "SBCs" to reduce the risks that they will unintentionally defeat loop-detection. Of course, that is inherently impossible, because the SBCs we are talking about are not proxies and don't have to follow any particular rules. But, IMHO, if we write a restriction that is workable, there will be some market pressure on SBC vendors "to be compliant with RFC xxxx" -- not to mention that we will give vendors some guidance on *how* to avoid defeating loop-detection, and I've discovered that even if it is "straightforward" that a problem exists and should be avoided, one cannot in general depend on software engineers to notice that without being told. Here is a first draft: For the purposes of this section, we define "SBC" as: A SIP agent (which may be a proxy or user agent) which primarily sends SIP requests and responses in reaction to receiving similar SIP requests and responses. An SBC is said to be conformant to this specification if, in any expected deployment, the universe of all SIP agents will be divided into a number of sets, which we call "regions", and each region possesses at least one of the following loop-detection properties: A) if all of the agents in the region are assumed to implement this RFC, no propagating chain of requests can pass through the same SIP agent in the region twice with the same routing information without being detected by the mechanism of this RFC (even if the chain passes through other regions in the meantime), B) a propagating chain of requests can never enter the region more than once from any other region while containig the same routing information, due to cooperation by the SIP agents in the region containing the SBC (by a mechanism outside the scope of this RFC), or C) the administrator of the SBC has positive knowledge that the technical and/or administrative configuration of the SIP agents in the region ensures that if a request enters the same SIP agent twice with the same routing information that it will be rejected as a looped request (by a mechanism outside the scope of this RFC). Normally, an SBC (and its redundant cohorts) will divide the universe into three regions: the SBC and its cohorts, the network "inside" that they protect, and the public Internet. There seem to be three ways to prevent loops within any region: (A) assume they implement loop-detection, and require the SBC to propagate the loop-detection information in requests when they enter/leave the region, (B) have the SBCs do it somehow, or (C) *know* that the SIP agents in the region implement some other form of loop detection. I would particularly like to know what SBC vendors think of this. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Aug 08 14:35:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIqLU-0001TR-44; Wed, 08 Aug 2007 14:33:24 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IIqLS-0001TL-BQ for sip-confirm+ok@megatron.ietf.org; Wed, 08 Aug 2007 14:33:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIqLS-0001T6-1r for sip@ietf.org; Wed, 08 Aug 2007 14:33:22 -0400 Received: from alnrmhc11.comcast.net ([204.127.225.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIqLR-00082K-Oz for sip@ietf.org; Wed, 08 Aug 2007 14:33:22 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (alnrmhc11) with ESMTP id <20070808183320b1100r15d4e>; Wed, 8 Aug 2007 18:33:21 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l78IXH8t011972 for ; Wed, 8 Aug 2007 14:33:17 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l78IXHtj011968; Wed, 8 Aug 2007 14:33:17 -0400 Date: Wed, 8 Aug 2007 14:33:17 -0400 Message-Id: <200708081833.l78IXHtj011968@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <468B12B7.2010806@cisco.com> (jdrosen@cisco.com) Subject: Re: [Sip] UA Loose Routing Issue #1: Backwards compatibility References: <466F5E26.2000709@cisco.com> <200706180229.l5I2TqN0008104@dragon.ariadne.com> <468B12B7.2010806@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org This is delayed, but I haven't heard of this point being addressed: From: Jonathan Rosenberg > On a more practical level, it only deals with one level of address > mapping, and it's not usable by a UA that doesn't implement the change > -- whereas I would expect that the optimal mechanism is one that > tweaks the behavior of the proxy doing the mapping, and requires no > change from any other system. If the purpose of this is to communicate the targeted URI from the terminating proxy to the UA, I don't see how any mechanism can work unless it is supported by that proxy and that UA. Any of the mechanisms mentioned or discussed (P-Called-Party-ID, To, History-Info) have this property. The property I'm looking for is "If the proxy applies the mechanism, but the UA doesn't understand it, the UA automatically processes the request as if the mechanism was not employed." If we carry the "retargeted AOR" in a URI parameter or header and modify the request-URI as now, we obtain this property. If we don't modify the request-URI, the proxy has to have accurate knowledge of which targets support UA Loose Routing and which don't. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Aug 08 14:37:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIqNl-0003jR-Do; Wed, 08 Aug 2007 14:35:45 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IIqNj-0003dj-RO for sip-confirm+ok@megatron.ietf.org; Wed, 08 Aug 2007 14:35:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIqNj-0003Zo-CS for sip@ietf.org; Wed, 08 Aug 2007 14:35:43 -0400 Received: from exprod6og51.obsmtp.com ([64.18.1.183]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IIqNi-0007X4-MV for sip@ietf.org; Wed, 08 Aug 2007 14:35:43 -0400 Received: from source ([192.150.20.142]) by exprod6ob51.postini.com ([64.18.5.12]) with SMTP; Wed, 08 Aug 2007 11:35:36 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l78IZYWs025565; Wed, 8 Aug 2007 11:35:35 -0700 (PDT) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l78IZX0c002605; Wed, 8 Aug 2007 11:35:34 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Aug 2007 11:35:33 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Comment on draft-ietf-sip-fork-loop-fix-05 Date: Wed, 8 Aug 2007 11:35:04 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22BCE34F@namail5.corp.adobe.com> In-Reply-To: <200708081820.l78IKvAp011056@dragon.ariadne.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Comment on draft-ietf-sip-fork-loop-fix-05 Thread-Index: AcfZ6PTH5amUgfB7QpO9JQOHl98gdAAAPP6A References: <46A13517.8000406@cisco.com><200707211409.l6LE95fj009615@dragon.ariadne.com><46A24E6F.1060402@cisco.com> <200708081820.l78IKvAp011056@dragon.ariadne.com> From: "Henry Sinnreich" To: , X-OriginalArrivalTime: 08 Aug 2007 18:35:33.0429 (UTC) FILETIME=[E795FE50:01C7D9EA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org The attached is a good example of why the SBC is not only a repeat of the NAT problem, but much worse. Will there be an SBC WGs similar to the MIDCOM and BEHAVE WGs? Or just brand the SBC as an Internet unfriendly device? One way around it is to make the IETF contributors read a "note well": We are here to implement and support the e2e principle and Internet transparency and not misuse the IETF resources for non-Internet network designs. Henry -----Original Message----- From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net]=20 Sent: Wednesday, August 08, 2007 1:21 PM To: sip@ietf.org Subject: Re: [Sip] Comment on draft-ietf-sip-fork-loop-fix-05 From: Paul Kyzivat Yes, if the obfuscating proxy performs the loop checking based on its own Via. But if you have *two* obfuscating proxies in the loop then I think it becomes impossible to detect the loop. In a way, this is similar the a loop that includes both a sip leg and a PSTN leg. I don't have a good solution for either of these. I think that we can/should add a restriction to the text that is binding on "SBCs" to reduce the risks that they will unintentionally defeat loop-detection. Of course, that is inherently impossible, because the SBCs we are talking about are not proxies and don't have to follow any particular rules. But, IMHO, if we write a restriction that is workable, there will be some market pressure on SBC vendors "to be compliant with RFC xxxx" -- not to mention that we will give vendors some guidance on *how* to avoid defeating loop-detection, and I've discovered that even if it is "straightforward" that a problem exists and should be avoided, one cannot in general depend on software engineers to notice that without being told. Here is a first draft: For the purposes of this section, we define "SBC" as: A SIP agent (which may be a proxy or user agent) which primarily sends SIP requests and responses in reaction to receiving similar SIP requests and responses. An SBC is said to be conformant to this specification if, in any expected deployment, the universe of all SIP agents will be divided into a number of sets, which we call "regions", and each region possesses at least one of the following loop-detection properties: A) if all of the agents in the region are assumed to implement this RFC, no propagating chain of requests can pass through the same SIP agent in the region twice with the same routing information without being detected by the mechanism of this RFC (even if the chain passes through other regions in the meantime), B) a propagating chain of requests can never enter the region more than once from any other region while containig the same routing information, due to cooperation by the SIP agents in the region containing the SBC (by a mechanism outside the scope of this RFC), or C) the administrator of the SBC has positive knowledge that the technical and/or administrative configuration of the SIP agents in the region ensures that if a request enters the same SIP agent twice with the same routing information that it will be rejected as a looped request (by a mechanism outside the scope of this RFC). Normally, an SBC (and its redundant cohorts) will divide the universe into three regions: the SBC and its cohorts, the network "inside" that they protect, and the public Internet. There seem to be three ways to prevent loops within any region: (A) assume they implement loop-detection, and require the SBC to propagate the loop-detection information in requests when they enter/leave the region, (B) have the SBCs do it somehow, or (C) *know* that the SIP agents in the region implement some other form of loop detection. I would particularly like to know what SBC vendors think of this. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Aug 08 15:04:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIqnz-0006Jj-N5; Wed, 08 Aug 2007 15:02:51 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IIqny-0006Ih-EM for sip-confirm+ok@megatron.ietf.org; Wed, 08 Aug 2007 15:02:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIqny-0006Gz-4A for sip@ietf.org; Wed, 08 Aug 2007 15:02:50 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIqnw-0000FT-M4 for sip@ietf.org; Wed, 08 Aug 2007 15:02:50 -0400 Received: from repmmr01.bea.com (repmmr01.bea.com [10.160.29.71]) by repmmg02.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l78J2kP9013212 for ; Wed, 8 Aug 2007 12:02:46 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr01.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l78J2dPG008665 for ; Wed, 8 Aug 2007 12:02:45 -0700 Received: from 172.24.29.206 ([172.24.29.206]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Wed, 8 Aug 2007 19:02:42 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Thu, 09 Aug 2007 04:02:39 +0900 From: Eric Burger To: "'sip'" Message-ID: Thread-Topic: draft-burger-sip-info-01 Thread-Index: AcfZ7rCA7xFzzEXhEdyMOgAWy4mm/w== Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [Sip] draft-burger-sip-info-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I haven't seen an announcement yet, but it is in the archives. http://www.ietf.org/internet-drafts/draft-burger-sip-info-01.txt Christer - open season on INFO's :-) I know some people said I should take out the Port 80 comment, but it is so elegant and real, I left it in. I'll probably move it to an appendix if it does not get an appendectomy. I did include a bunch of text on why MSCML used INFO, beyond it being the only obvious option, namely the elegance and ease of saying, "Do this on *my* leg," rather than saying "Do this on *that* leg." Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete 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 sip-bounces@ietf.org Wed Aug 08 15:24:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIr6a-0001Q7-Vg; Wed, 08 Aug 2007 15:22:04 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IIr6Z-0001Pp-PK for sip-confirm+ok@megatron.ietf.org; Wed, 08 Aug 2007 15:22:03 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIr6Z-0001Pg-De for sip@ietf.org; Wed, 08 Aug 2007 15:22:03 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IIr6Z-00007w-0I for sip@ietf.org; Wed, 08 Aug 2007 15:22:03 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 08 Aug 2007 15:22:02 -0400 X-IronPort-AV: i="4.19,237,1183348800"; d="scan'208"; a="67436892:sNHT48891766" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l78JM2PK005319; Wed, 8 Aug 2007 15:22:02 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l78JLgmx023302; Wed, 8 Aug 2007 19:22:02 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Aug 2007 15:21:52 -0400 Received: from [161.44.174.244] ([161.44.174.244]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Aug 2007 15:21:52 -0400 Message-ID: <46BA17CE.1000300@cisco.com> Date: Wed, 08 Aug 2007 15:21:50 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Dale.Worley@comcast.net Subject: Re: [Sip] UA Loose Routing Issue #1: Backwards compatibility References: <466F5E26.2000709@cisco.com> <200706180229.l5I2TqN0008104@dragon.ariadne.com> <468B12B7.2010806@cisco.com> <200708081833.l78IXHtj011968@dragon.ariadne.com> In-Reply-To: <200708081833.l78IXHtj011968@dragon.ariadne.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Aug 2007 19:21:52.0536 (UTC) FILETIME=[60101180:01C7D9F1] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2167; t=1186600922; x=1187464922; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20UA=20Loose=20Routing=20Issue=20#1=3A=20Backwa rds=20compatibility |Sender:=20 |To:=20Dale.Worley@comcast.net; bh=Q9oHoy7RBPB253DBULy/p38l5+6abhebD5g/wYpofbs=; b=TxmucKHRB1EKtdgIlYAUQGCD9xyS3Qi9tj6KydaHWCo3uNavga0gxXfmdvKsOL2bPK5CsSr3 H9d7LzbcWiqOrlDeXHF9T3o80m6p1tkM5U/VtrCA64HfPmwqdvd9+9bp; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dale, What problem are you trying to solve that Jonathan's proposal didn't solve? As proposed by him, the proxy wouldn't use loose routing in this case unless it knew that the UA supported it. (It learns based on the ;lr in the contact supplied with REGISTER.) The functional difference between that and P-Called-Party is that when the proxy uses P-Called-Party it supplies the information even to UAs that don't support it. While that doesn't cause any harm, it also doesn't provide any benefit. Paul Dale.Worley@comcast.net wrote: > This is delayed, but I haven't heard of this point being addressed: > > From: Jonathan Rosenberg > > > On a more practical level, it only deals with one level of address > > mapping, and it's not usable by a UA that doesn't implement the change > > -- whereas I would expect that the optimal mechanism is one that > > tweaks the behavior of the proxy doing the mapping, and requires no > > change from any other system. > > If the purpose of this is to communicate the targeted URI from the > terminating proxy to the UA, I don't see how any mechanism can work > unless it is supported by that proxy and that UA. Any of the mechanisms > mentioned or discussed (P-Called-Party-ID, To, History-Info) have this > property. > > The property I'm looking for is "If the proxy applies the mechanism, > but the UA doesn't understand it, the UA automatically processes the > request as if the mechanism was not employed." If we carry the > "retargeted AOR" in a URI parameter or header and modify the > request-URI as now, we obtain this property. If we don't modify the > request-URI, the proxy has to have accurate knowledge of which targets > support UA Loose Routing and which don't. > > Dale > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Aug 08 21:47:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIx5D-0003TK-0Y; Wed, 08 Aug 2007 21:45:03 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IIx5A-0003TB-OJ for sip-confirm+ok@megatron.ietf.org; Wed, 08 Aug 2007 21:45:00 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIx5A-0003Sz-Cl for sip@ietf.org; Wed, 08 Aug 2007 21:45:00 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IIx59-0006zB-A2 for sip@ietf.org; Wed, 08 Aug 2007 21:45:00 -0400 Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l791impY001398 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Aug 2007 20:44:49 -0500 (CDT) Received: from [127.0.0.1] (volkerh.lra.lucent.com [135.244.17.122]) by umail.lucent.com (8.13.8/TPES) with ESMTP id l791ijGg023642; Wed, 8 Aug 2007 20:44:48 -0500 (CDT) Message-ID: <46BA7185.6070401@bell-labs.com> Date: Wed, 08 Aug 2007 21:44:37 -0400 From: Volker Hilt User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: shida@ntt-at.com Subject: Re: [Sip] WGLC Review: draft-ietf-sip-session-policy-framework-01 References: <466EF33C.7080807@ntt-at.com> In-Reply-To: <466EF33C.7080807@ntt-at.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 2.8 (++) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd Cc: "sip@ietf.org List" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Shida, thanks much for reviewing this document. Comments inline. > > Clarifications needed: > ------ > C1) Section 4.4.1, 2nd para, 2nd last sentence. > - not receiving policy and not receiving any response the same thing? > > If not may want to clarify this. Clarified that a UA MAY continue with a session if the policy server is unreachable or returns a non-correctable error response. > C2) Section 4.4.1 The token is mentioned everywhere, but looking at > the event packages there is no token defined. Do you expect token to be > something implicit that administrator somehow configures the policy > server and UA so they implicitly know what token is and how to find it > in the policy provided by the policy server? I understand that token > itself may have flexibility in its value, but where to look for the > token SHOULD be specified explicitly. > A token can be delivered as part of the media policy data set (I just noticed that an element for the token is missing there!). I've added a reference to the media policy data set. > C3) Section 4.4.1 > For existing dialog, what is the impact of policy channel failing? > > Would it affect the whole dialog or just the usage? > > Currently it reads like it would affect the dialog which may not > be desirable. (Section 4.4.6 reads "This means > that, the UA MUST cancel or reject a pending INVITE transaction for > the session or terminate the session if it is already in progress." > > e.g) UAC tries to change the codec mid-dialog > sends the > new SDP to policy server > Policy server is offline or returns > global class error > > What happens now? I've added a similar wording as in C1) to Section 4.4.6. A UA SHOULD continue if the policy server is unreachable. > C4) Section 4.4.2 > Proxy's behavior on policy-id and token is completely missing. > paragraph 2 notes how proxy MUST NOT reject the request if the policy-id > contains the associated policy server's URI but on section 4.4.1, there > is enough text describing how some proxy may base their pass-through on > token, so I think text on proxy behavior surrounding token in this > section is an appropriate addition. > I've moved most of the text describing the use of the policy-id header in conjunction with tokens for routing from Section 4.4.1 to Section 4.4.2. This should also take care of nit N3. > C5) Section 4.4.2 > It may be appropriate to add some text on RR by proxy wanting to ensure > UA passes the same proxies/policy servers, rather than UA maintaining a > list of policy servers to contact mid-dialog. Good point. I think a proxy should RR to ensure that the UA keeps contacting its policy server for mid-dialog requests. I've added text for this to 4.4.2 > UA always contacting the > same policy servers contacted at the initial session setup, even after > the signaling path has changed seems unreasonable and ineffective. > > * I don't have a strong opinion on this, don't mind the current spec > but wondered if you considered this. I think the current draft does a poor job on explaining what a UA should do with the discovered policy servers. There a two things: a UA needs to set up the policy channel and disclose the current session description. Whenever the session description changes, it needs to use the policy channels (i.e. subscriptions) it has established to policy servers and disclose the new session description. In addition, it may need to set up a new policy channel if a new server URI is discovered. I've reorganized the policy channel section to better address this and moved sections 4.4.5 and 4.4.6 into this section. > C6) Section 4.4.3 As UAS does not use the policy-Id, text SHOULD be > added to mention that if the list of policy server changes in mid-dialog > that it should contact the policy servers again. (Text can be added > instead in section 4.4.5 - last paragraph encouraging the re-visit to > the policy servers) > > * This is not problematic with UAC as proxy would return 488 with > policy server URI, alerting the UAC that list of policy server that > need to be contacted have changed. > The UAS will learn about a changed list via the Policy-Contact header in incoming requests. Section 4.4.3 says that a UAS must contact the policy servers listed in the Policy-Contact header. Thus, if this list changes mid-dialog, the UAS will automatically contact the new list of policy servers. I've made the changes described in the nits below. Thanks much! Volker > > > > Nits/Editorials: > ------ > N1) Section 1, 1st para, 2nd sentence. > [page mode messaging is not divorced from the actual session] > > OLD: However, proxies are divorced from the actual sessions - audio, > video, and messaging - that SIP establishes. > > NEW: However, proxies are divorced from the actual sessions - audio, > video, and session mode messaging - that SIP establishes. > > N2) Section 1, 1st para, last sentence. > Text on S/MIME plays no roles here, its context seems kind of odd. I > believe the text only causes confusion thus should be removed. > > N3) Section 4.4.1, 4th - 6th para > Seems out of place. These paragraphs focus on policy-id usage and its > purpose, it should go into section 4.4.7.1. > > N4) Section 4.4.1, 5th para 2nd sentence. > [proxies > proxy] > > N5) Section 4.4.1, 5th para, last sentence. > [unnecessary "that"] > > OLD: combination that has configured the associated > NEW: combination has configured the associated > > N6) Section 4.4.2, 2nd para, 2nd sentence > [this policy server > associated policy server] > > OLD: The proxy SHOULD remove the Policy-Id header value for this > policy server from the Policy-Id header field before forwarding the > request. > NEW: The proxy SHOULD remove the Policy-Id header value for the > assocaited policy server from the Policy-Id header field before > forwarding the request. > N7) Section 4.4.6, 1st para, 1st sentence > [add MUST before apply] > > OLD: A UA compliant to this specification MUST contact the discovered > policy servers and apply session policies to an offer or answer > before using the offer or answer. > > NEW: A UA compliant to this specification MUST contact the discovered > policy servers and MUST apply session policies to an offer or answer > before using the offer or answer. > > N8) Section 4.4.6, last para > > OLD: A UA MUST inform the policy server when a session is terminated via > the policy channel. This enables a policy server to free all > resources it may have allocated for this session. A policy server > can indicate via the policy channel that it does not need to be > contacted at the end of a session. In this case, the UA SHOULD NOT > inform the policy server about the termination of the session. > > NEW: A UA MUST inform the policy server when a session is terminated via > the policy channel unless, a policy server > indicates via the policy channel that it does not need to be > contacted at the end of a session. This enables a policy server to > free all > resources it may have allocated for this session. > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Volker Hilt Bell Labs / Alcatel-Lucent phone: +1 732 888 7206 791 Holmdel-Keyport Rd email: volkerh@bell-labs.com Holmdel, NJ 07733 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Aug 09 05:19:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ48n-00088f-W4; Thu, 09 Aug 2007 05:17:13 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IJ48m-00088a-Aa for sip-confirm+ok@megatron.ietf.org; Thu, 09 Aug 2007 05:17:12 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ48l-00088S-Vh for sip@ietf.org; Thu, 09 Aug 2007 05:17:11 -0400 Received: from mailout2.samsung.com ([203.254.224.25]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IJ48l-0006LK-H2 for sip@ietf.org; Thu, 09 Aug 2007 05:17:11 -0400 Received: from epmmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JMI000D11QWYY@mailout2.samsung.com> for sip@ietf.org; Thu, 09 Aug 2007 18:16:09 +0900 (KST) Received: from mahesha ([107.108.70.26]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0JMI00L241QZ7S@mmp1.samsung.com> for sip@ietf.org; Thu, 09 Aug 2007 18:16:13 +0900 (KST) Date: Thu, 09 Aug 2007 14:53:26 +0530 From: Mahesh Subject: [SIP] Query on forming a Contact Predicate To: sip@ietf.org Message-id: <033101c7da66$f2272700$1a466c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0827243280==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0827243280== Content-type: multipart/alternative; boundary="Boundary_(ID_MFubCVUK3zg6GBHGeJncbw)" This is a multi-part message in MIME format. --Boundary_(ID_MFubCVUK3zg6GBHGeJncbw) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT hi Please How do i form the Contact Predicate for following Feature Set Predicate as per RFC 3840. & ( & (sip.audio) (sip.duplex=full) ) ( & (sip.audio) (sip.duplex=receive-only) ) regards Mahesh --Boundary_(ID_MFubCVUK3zg6GBHGeJncbw) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
hi
Please How do i form the Contact Predicate for following Feature Set Predicate
as per RFC 3840.
& ( & (sip.audio) (sip.duplex=full) )
    (  & (sip.audio) (sip.duplex=receive-only) )
 
 
 
regards
Mahesh
 
--Boundary_(ID_MFubCVUK3zg6GBHGeJncbw)-- --===============0827243280== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0827243280==-- From sip-bounces@ietf.org Thu Aug 09 05:56:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ4iy-0004pb-Ty; Thu, 09 Aug 2007 05:54:36 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IJ4ix-0004pH-E7 for sip-confirm+ok@megatron.ietf.org; Thu, 09 Aug 2007 05:54:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ4ix-0004p9-4G for sip@ietf.org; Thu, 09 Aug 2007 05:54:35 -0400 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJ4iv-00067k-9Y for sip@ietf.org; Thu, 09 Aug 2007 05:54:35 -0400 Received: from epmmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JMI000VI3IOYY@mailout2.samsung.com> for sip@ietf.org; Thu, 09 Aug 2007 18:54:24 +0900 (KST) Received: from mahesha ([107.108.70.26]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0JMI00LUX3IRDQ@mmp1.samsung.com> for sip@ietf.org; Thu, 09 Aug 2007 18:54:29 +0900 (KST) Date: Thu, 09 Aug 2007 15:31:44 +0530 From: Mahesh Subject: Re: [SIP] Query on forming a Contact Predicate To: sip@ietf.org Message-id: <034a01c7da6c$4b837ce0$1a466c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: <033101c7da66$f2272700$1a466c6b@sisodomain.com> X-Spam-Score: -4.0 (----) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0080795795==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0080795795== Content-type: multipart/alternative; boundary="Boundary_(ID_qWlm55Tj54g/qY29N427Rg)" This is a multi-part message in MIME format. --Boundary_(ID_qWlm55Tj54g/qY29N427Rg) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT oops!!! there is a mistake in the Feature Set Predicate. Its as follows & ( & (sip.audio) (sip.duplex=full) ) ( & (sip.video) (sip.duplex=receive-only) ) ----- Original Message ----- From: Mahesh To: sip@ietf.org Sent: Thursday, August 09, 2007 2:53 PM Subject: [SIP] Query on forming a Contact Predicate hi Please How do i form the Contact Predicate for following Feature Set Predicate as per RFC 3840. & ( & (sip.audio) (sip.duplex=full) ) ( & (sip.audio) (sip.duplex=receive-only) ) regards Mahesh ------------------------------------------------------------------------------ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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_qWlm55Tj54g/qY29N427Rg) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
oops!!! there is a mistake in the Feature Set Predicate.
Its as follows
& ( & (sip.audio) (sip.duplex=full) )
    (  & (sip.video) (sip.duplex=receive-only) )
----- Original Message -----
From: Mahesh
Sent: Thursday, August 09, 2007 2:53 PM
Subject: [SIP] Query on forming a Contact Predicate

hi
Please How do i form the Contact Predicate for following Feature Set Predicate
as per RFC 3840.
& ( & (sip.audio) (sip.duplex=full) )
    (  & (sip.audio) (sip.duplex=receive-only) )
 
 
 
regards
Mahesh
 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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_qWlm55Tj54g/qY29N427Rg)-- --===============0080795795== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0080795795==-- From sip-bounces@ietf.org Thu Aug 09 06:14:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ503-0002cs-6E; Thu, 09 Aug 2007 06:12:15 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IJ501-0002cg-Q9 for sip-confirm+ok@megatron.ietf.org; Thu, 09 Aug 2007 06:12:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ501-0002cX-EC for sip@ietf.org; Thu, 09 Aug 2007 06:12:13 -0400 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJ4zz-0006QV-LX for sip@ietf.org; Thu, 09 Aug 2007 06:12:13 -0400 Received: from epmmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JMI00B0J4C34B@mailout2.samsung.com> for sip@ietf.org; Thu, 09 Aug 2007 19:12:03 +0900 (KST) Received: from mahesha ([107.108.70.26]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0JMI00LLD4C68H@mmp2.samsung.com> for sip@ietf.org; Thu, 09 Aug 2007 19:12:07 +0900 (KST) Date: Thu, 09 Aug 2007 15:49:24 +0530 From: Mahesh Subject: [SIP] Query on draft-rosenberg-sip-app-media-tag-00 To: sip@ietf.org Message-id: <036701c7da6e$c32c5a30$1a466c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; reply-type=response; charset=iso-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: -4.0 (----) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dear Rosenberg, - My understanding is that sip.app-subtype indicates a particular application media sub-type used by some Applications. This understanding is mainly derived from following excerpt from the draft ------------------------------------------------------------------------ "Its value can be any registered or private MIME application sub-type. When included in the Contact header field of a REGISTER request, an agent SHOULD include all application subtypes that it can support as streaming formats. An application sub-type is supported if the user agent would be capable of processing an Session Description Protocol (SDP) [4] offer [2] that contained that sub-type as a format in the m-line of the SDP." -------------------------------------------------------------------------- - Therefor i would go ahead and state that a value of sip.app-subtype does not indicatea particular Application, instead the application media sub-type used by the application. For example: application/resource-lists+xml - Please acknowledge if my understanding is right. If understanding is right then i have following comments C1. It would be helpful to explicitly mention somewhere that ";+sip.app-subtype="greatgame,wboard" implies that 'greatgame' and 'wboard' are two application media sub-types used by the APplications rather than an indication or identification of Application itself. C2. It would be helpful to provide similar clarification in following part of the draft -------------------------------------------------------------------- "A consequence of this is that, as new streaming applications are defined (such as multiplayer games, whiteboard sessions, and so on, they SHOULD be defined using the SDP application stream, and utilize a MIME application sub-type." --------------------------------------------------------------------------- regards Mahesh > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Aug 09 14:37:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJCqa-00007L-86; Thu, 09 Aug 2007 14:35:00 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IJCqY-000074-Ue for sip-confirm+ok@megatron.ietf.org; Thu, 09 Aug 2007 14:34:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJCqY-00006v-Iv for sip@ietf.org; Thu, 09 Aug 2007 14:34:58 -0400 Received: from sccrmhc11.comcast.net ([63.240.77.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJCqX-0001CH-7j for sip@ietf.org; Thu, 09 Aug 2007 14:34:58 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (sccrmhc11) with ESMTP id <2007080918345601100ll5qae>; Thu, 9 Aug 2007 18:34:56 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l79IYt8t020172 for ; Thu, 9 Aug 2007 14:34:55 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l79IYtAf020168; Thu, 9 Aug 2007 14:34:55 -0400 Date: Thu, 9 Aug 2007 14:34:55 -0400 Message-Id: <200708091834.l79IYtAf020168@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <46BA17CE.1000300@cisco.com> (pkyzivat@cisco.com) Subject: Re: [Sip] UA Loose Routing Issue #1: Backwards compatibility References: <466F5E26.2000709@cisco.com> <200706180229.l5I2TqN0008104@dragon.ariadne.com> <468B12B7.2010806@cisco.com> <200708081833.l78IXHtj011968@dragon.ariadne.com> <46BA17CE.1000300@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: Paul Kyzivat What problem are you trying to solve that Jonathan's proposal didn't solve? It's to avoid complexifying SIP by adding variants that need to be negotiated between agents. We've already got a set of rules that let agents add information into messages so that it will be ignored by recipients that don't understand it. I think it is less desirable to add a tweak that is negotiated between two agents, such that properly interpreting and processing messages requires that you know whether "UA loose routing" is in effect or not. At the least, you have to beware of this alternative whenever you propose any further addendum to SIP. When the next such tweak comes along, you'll get a total of 4 combinations, etc. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Aug 10 07:09:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJSLa-0001M4-Vv; Fri, 10 Aug 2007 07:08:03 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IIg2N-0007Ag-7P for sip-confirm+ok@megatron.ietf.org; Wed, 08 Aug 2007 03:32:59 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIg2M-0007AY-Pq for sip@ietf.org; Wed, 08 Aug 2007 03:32:58 -0400 Received: from mailout1.samsung.com ([203.254.224.24]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IIg2M-00070g-92 for sip@ietf.org; Wed, 08 Aug 2007 03:32:58 -0400 Received: from epmmp1 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JMG000KG2AIE5@mailout1.samsung.com> for sip@ietf.org; Wed, 08 Aug 2007 16:32:42 +0900 (KST) Received: from mahesha ([107.108.70.26]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0JMG009CA2ANZY@mmp1.samsung.com> for sip@ietf.org; Wed, 08 Aug 2007 16:32:48 +0900 (KST) Date: Wed, 08 Aug 2007 13:10:02 +0530 From: Mahesh Subject: [SIP] Query on draft-rosenberg-sip-app-media-tag-00 To: sip@ietf.org Message-id: <026f01c7d98f$55885fe0$1a466c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; reply-type=original; charset=iso-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb X-Mailman-Approved-At: Fri, 10 Aug 2007 07:08:02 -0400 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dear Rosenberg, - My understanding is that sip.app-subtype indicates a particular application media sub-type used by some Applications. This understanding is mainly derived from following excerpt from the draft ------------------------------------------------------------------------ "Its value can be any registered or private MIME application sub-type. When included in the Contact header field of a REGISTER request, an agent SHOULD include all application subtypes that it can support as streaming formats. An application sub-type is supported if the user agent would be capable of processing an Session Description Protocol (SDP) [4] offer [2] that contained that sub-type as a format in the m-line of the SDP." -------------------------------------------------------------------------- - Therefor i would go ahead and state that a value of sip.app-subtype does not indicatea particular Application, instead the application media sub-type used by the application. For example: application/resource-lists+xml - Please acknowledge if my understanding is right. If understanding is right then i have following comments C1. It would be helpful to explicitly mention somewhere that ";+sip.app-subtype="greatgame,wboard" implies that 'greatgame' and 'wboard' are two application media sub-types used by the APplications rather than an indication or identification of Application itself. C2. It would be helpful to provide similar clarification in following part of the draft -------------------------------------------------------------------- "A consequence of this is that, as new streaming applications are defined (such as multiplayer games, whiteboard sessions, and so on, they SHOULD be defined using the SDP application stream, and utilize a MIME application sub-type." --------------------------------------------------------------------------- regards Mahesh _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Aug 10 17:17:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJbpK-00040V-Kc; Fri, 10 Aug 2007 17:15:22 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IJbpI-00040K-IU for sip-confirm+ok@megatron.ietf.org; Fri, 10 Aug 2007 17:15:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJbpI-00040C-8T for sip@ietf.org; Fri, 10 Aug 2007 17:15:20 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJbpG-0007rk-RY for sip@ietf.org; Fri, 10 Aug 2007 17:15:20 -0400 Received: from [65.65.155.30] (helo=[192.168.1.4]) by nylon.softarmor.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1IJbp2-0005iI-Ld for sip@ietf.org; Fri, 10 Aug 2007 16:15:18 -0500 Mime-Version: 1.0 (Apple Message framework v752.3) References: <20070809224732.C2BF73F446@pecan.tislabs.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Date: Fri, 10 Aug 2007 16:14:54 -0500 To: sip List X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 57b3d456dc4730784e7070d5c6b7d14f Subject: [Sip] Fwd: secdir of draft-ietf-sip-answermode-04.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Sandy Murphy did a good secdir review of the answermode draft that I'd like to share with the working group. In trying to answer some of the questions raised, I found myself stumbling against some of the more perplexing (to me, at least) parts of the SIP specs, especially subtle nuances in caller preferences. I'll also send my rather lengthy response, under separate cover. Begin forwarded message: From: sandy@tislabs.com (Sandy Murphy) Date: August 9, 2007 5:47:32 PM CDT To: aallen@rim.com, dean.willis@softarmor.com, drage@alcatel- lucent.com, fluffy@cisco.com, iesg@ietf.org, secdir@ietf.org Cc: sandy@tislabs.com Subject: secdir of draft-ietf-sip-answermode-04.txt I have reviewed this document (draft-ietf-sip-answermode-04.txt) as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. My apologies for not completing this review within the period of the last call. Note that I am not sending these comments to the ietf.org list. I note that few others commented on this draft during the last call period, so my late comments are more unwelcome, I am sure. This draft adds a new header type to SIP interactions, a header called Answer-Mode, which allows a UAS to request that the UAC automatically answer a call without waiting for user action for acceptance. The new feature is under user policy control, based on authenticated SIP identify. I have not found significant security shortcomings on this draft. The new feature presents obvious security vulnerabilities, which the authors have related with adequate detail. The security of the new feature relies on the authenticated identity, the security of the SIP security architecture, and the user's policy control over acceptance of automatic answer calls. I do believe that the authors have glossed over the level of risk of two discussed vulnerabilities. First, the SIP security architecture secures the hop-hop transfer of a SIP message, between UAS and outgoing proxy server, between proxy servers, and between incoming proxy server and UAS. The Answer-Mode header insertion, modification or deletion by proxy servers and the user dependence on the initiator's authenticated SIP identity provides (yet another?) opportunity for a mis-behaving proxy to damage the end system. As I note below, the draft says a proxy must not alter these headers, but does not address the insertion or deletion (that could be an unintended omission in the text). Second, the authors mention several denial of service attacks ("battery rundown", "forced busy"), but combine these with the "whoopee-cushion" attack in the category of "insertion attacks", and thereafter focus on the "whoopee-cushion" style playout in their discussion of insertions. That leads them to slight the seriousness of the insertion attacks. I believe that the authors should also note that automatic answer has another denial of service sort of impact - that of cost to the user. (Having recently received my first spam text message on my cell phone, which incurs financial cost for me, I am sensitive to this impact.) There is a suggestion in Sect 7.4 of a mandated policy that would prohibit (MUST NOT) auto answer when the media flow is outbound. It appears that this is not subject to user policy. It seems odd to create a new feature and then forbid its use. I have other comments, not related to security. One overall concern was the draft's inattention to error modes, when headers and parameters did not match as expected, etc. Also, other SIP specs of new headers (e.g., RFC3841, RFC3325, RFC4474) describe a new entry in the SIP header table (RFC3261, Table 2) that summarizes the header use (valid in request or response, mandatory or optional in methods, etc). Such a summary would be good here as well. Detailed comments: Sect 1, page 5: "Two different use cases converged to create the consensus", "The first key use", "The second use case", "Another representative use case was introduced during discussion" - Doesn't that make three different use cases? Unless two of these collapse to one? Or the authors are trying to distinguish use cases that created consensus from those raised during discussion? Sect 3, page 7: This sort of interaction generally occurs only during the formation of a dialog and its initial usage, and not during subsequent operations such as re-INVITE. What happens if these header fields appear in a mid-dialog (re-) INVITE (or ACK, CANCEL, whatever)? Sect 4 page 8: Each value of the Answer-Mode or Priv-Answer-Mode header field can include an optional parameter, "require". If present, this parameter indicates that the UAS would prefer that the UAC reject the request if the UAC is unwilling (perhaps due to policy) to answer in the mode requested, rather than answering in another mode. Doesn't this have UAS and UAC switched? If not, the authors should indicate more clearly why in this paragraph, the UAC is judging the request and the UAS is making the request and indicating its preference. Sect 4.1.1, page 8 UAS MUST NOT answer without user input in cases where the privacy or security of the user would be compromised as a result. How does the UAS know? Is this a per-method or per-application (however that might be determined) configuration in the UAS? Sect 4.1.1, page 9 A UAC supporting the Answer-Mode and Priv-Answer-Mode header fields indicates its support by including an option tag of "answermode" in the Supported header field of all requests it sends. In RFC 3261, sect 8.1.1.9 says that a Supported header SHOULD be included in all requests. Is this section expanding that to say that Supported MUST be included if the request includes an Answer-Mode? Section 4.1.2, page 9 To indicate that it supports the answer-mode negotiation feature, a UA includes an extensions parameter with a value that includes "answermode". Example: ;extensions="answermode,100rel,gruu" in the Contact: header field of its REGISTER requests. This usage of feature tags is described in [RFC3840]. RFC3840 says: The REGISTER request MAY contain a Require header field with the value "pref" if the client wants to be sure that the registrar understands the extensions defined in this specification. This means that the registrar will store the feature parameters, and make them available to elements accessing the location service within the domain. In the absence of the Require header field, a registrar that does not understand this extension will simply ignore the Contact header field parameters. This section does not mention a Require header of "pref" with respect to use of the "extensions" feature tag. So a registrar that did not understand the use of "extensions" would ignore the "extensions=answermode" in the Contact header - is this a matter for concern? I could see the chance that a contact might be selected even if the INVITE indicated that only contacts that understood answermode should be selected. If that is likely to be important in applications that stipulate , should the Require: pref be stipulated, or at least mentioned, here? RFC3840 also says: It is possible that other header fields and feature tags defined in the future may also overlap. When there exists a feature tag that describes a capability that can also be represented with a SIP header field, a UA MUST use the header field to describe the capability. A UA receiving a message that contains both the header field and the feature tag MUST use the header field, and not the feature tag. There are several header fields that define the answermode capability, including Supported, Require, and Answer-Mode. I am uncertain whether the above paragraph applies to the answermode capability, when a feature tag is included in Contact headers. But I think that the text of this draft ought to explicitly state that there was no overlap, or at least no conflict. Sect 4.1.3, page 9: A UAC supporting this specification includes an Answer-Mode or Priv- Answer-Mode header field in an INVITE where it wishes to influence the answering mode of the responding UAS. Note: this is meaningful only in initial or dialog-forming INVITE requests. Again - what if it is used in a re-INVITE? Is that an error? What if the original INVITE did not include an Answer-Mode header? Or the re-INVITE Answer-Mode is different from the initial Answer-Mode? Sect 4.1.3, page 10 To request that retargeting proxies in the path preferentially select targets that have indicated support for this extension in their registration, a UAC includes an Accept-Contact header field with an extensions parameter having a value of "answermode". This usage of Accept-Contact is described in [RFC3841]. This would normally be used in conjunction with the "Require: answermode" header field as described above. Example: Require: answermode Accept-Contact: *;extensions="answermode";methods="INVITE" Is it an error to use the extensions="answermode" if there is NOT a Require: answermode? What about including an when there is no Answer-Mode header? How about the final example: [RFC3841]. This would normally be used in conjunction with the "Require: answermode" header field as described above. Example: Require: answermode Accept-Contact: *;extensions="answermode"; methods="INVITE";require;explicit Is it OK to have if there is NOT a Require: answermode? I believe that the Require header is a directive to the eventual UAS and the Accept-Contact is a directive to retargeting proxies involved in the request, so if the retargetting proxy ignores the part (because it did not understand it) and chooses contacts that do not understand answermode, the Require parameter will still prevent the call from succeeding at the contact's UAS. Correct?. When the retargeting proxies do understand answermode, would the Require header be redundant in a request that also had an ? Sect 4.2.1, page 11 However, the serving proxies (proxies responsible for resolving an address-of-record into a registered contact) MAY exercise control over the requested answer mode, either inserting or deleting an Answer-Mode or Priv-Answer- Mode header field or altering the value of an existing header field . . . consequently proxies MUST NOT alter Answer-Mode or Priv-Answer-Mode header fields unless explicitly authorized to do so by an external agreement between the proxy operator and the user of the UA that the proxy is serving. First - Since the first text explicitly separates inserting and deleting from altering, it is unclear whether the "MUST NOT" extends to the insertion and deletion as well. Second - this "explicitly authorized" is not performed in the protocol, so it is not an active authorization, correct? If this is a matter of configuration of the proxy, it should be stated as such. This is a requirement of operational use, not a protocol implementation requirement. Sect 4.3.1, page 12-13 For a request having an Answer-Mode value of "Auto" and an Answer- Mode parameter of "require", the UAS SHOULD, if the calling party is authenticated and authorized for automatic answering, accept the request. The UAS MUST NOT allow "manual" answer of this request, but MAY reject it. If, for whatever reason, the UAS chooses not to accept the request automatically, the UAS MUST reject the request and SHOULD do so with a "403 (Forbidden)" response, and MAY include a reason phrase of "automatic answer forbidden" This text does not say what happens if the calling party is not authenticated and authorized for automatic answering. The previous paragraph, which discusses the Answer-Mode of Auto *without* the Require parameter, does discuss this case explicitly, so I noticed the absence here. In that previous paragraph, the unauthenticated, unauthorized call was subject to the rules of "Manual" calls, which might allow auto answer. In this case, is a similar treatment possible - that if the policy for Manual answermode calls allows auto answer, that the unauthenticated, unauthorized call could still be answered automatically? Nothing in the language here prohibits that, though it does prohibit a Manual answer. The S/MIME discussion in RFC3261 mentions cases where explicit guidance MUST be sought from the user regarding a certificate (see page 203), but I do not believe that there is a conflict between that RFC3261 guidance and this prohibition, because a UAS is not required to comply with a request for auto-answer. But I don't know if that was considered by the authors. I am unsure if the S/MIME processing could sometime following an answer by the UAS (RFC3261: "On future occasions... the UA MUST notify its user"), or if disturbing the user for S/MIME purposes would be considered to violate this prohibition against allowing manual answer. I'm not certain what use cases would motivate a prohibition against manual answer, so I can't judge whether the S/MIME notificatoin of the user would be a bad thing in those cases. Sect 4.3.2 The discussion of Priv-Answer-Mode points out that this feature allows the caller to choose whether to make a request using its elevated privileges or using normal privileges. This same behavior could be possible if a caller had multiple identities for the caller, could it not? No objection to using a separate call to indicate deliberate choice of use of the privilege, I just wondered if using multiple identities was considered. Section 6, page 16 None of the examples include a Supported header. As noted, Sect 4.1.1 implies that the Supported header is included in all requests. Section 7, page 17 The first part of this section lists several attacks, including spam, battery-rundown, and "forced busy". It later divides the attacks into insertion and interception. Later text focuses on the "whoopee-cushion" playout of inappropriate content in discussions of insertion attacks. But the denial of service aspect of battery-rundown and "forced busy" are neglected. So for example: It seems reasonable to consider the "bug-my-phone" attack as being in a different class (potentially far more severe) than the "whoopee- cushion" attack. This distinction suggests that security policy could be established in different and presumably less restrictive fashion for inbound media flows than for outbound media flows. When the user incurs cost or denial-of-service from accepted inbound media, I not agree that a less restrictive policy could be so easily assumed to be appropriate for insertion attacks on inbound media flows. Sect 7.2, page 19 This section discusses the mitigating factors of application design to the security concerns. Their first example says: In the most common use cases, the security aspects are somewhat mitigated by design aspects of the application. For example, in traditional telephony, the called party is alerted to the request (the phone rings), no media session is established without the acceptance of the called party (picking up the phone), and the media path is most commonly delivered to a single-user handset. Consequently, this application (although bidirectional) is relatively secure against both media insertion and media interception attacks of the sort enabled by the extensions in this document. The use of policy-free automatic-answering devices (like answering machines) and amplifiers (speakerphones and call-screening devices) weakens this defense. The traditional telephony application is relatively secure because the application precludes automatic answering, so the security vulnerability does not exist. If the message is that a good design defense against the new auto answer feature is not to use it, then this paragraph does present a good case, but not one that you would expect the authors to promote. Similar approaches apply to most applications. Insertion can be controlled (but not eliminated) by combining identity mechanisms with simple authorization policy, and interception can be effectively eliminated by combining strong identity mechanisms with aggressive authorization policy and/or user interaction. (This paragraph is another example of minimizing the threat of insertion attacks in comparison with interception attacks.) This is a section discussing Application Design. Is there a suggestion that authorization policy, whether simple or aggressive, would be a part of application design? Note below in Sect 7.4, the draft mandates (MUST NOT) certain policies. Is the intended usage that applications or UAs will have hardcoded policies -- policies are not under user control? Some users may not assess their risk as the policies mentioned here suggest. Sect 7.3, page 19: (editorial only) This section reads as if some section of text has been removed, with the remainder retaining vestiges of reference to the removed text. The extensions described in this document provide mechanisms by which a UAC can request that a UAS not deploy two of the five defensive mechanisms Which five defensive mechanisms? (10 lines later...) To recap, we have five defense mechanisms available at the application level: Oh, THOSE five defensive mechanisms. What do you mean "to recap"? There's been no discussion to recap. Unless you mean something like "From the discussion of the examples above, we can see there are five...". But I doubt it - the "limit I/O" defense is not mentioned anywhere else. Section 7.4, page 21 This section discusses "minimal policy requirement" User agents implementing this specification SHOULD NOT establish a session providing inbound media without explicit user acceptance where the requesting user is unknown, or is known and has not been granted authorization for such a session. This requirement is intended to prevent "SPAM broadcast" attacks" where unexpected and unwanted media is played out at a UAS . So the UA SHOULD NOT allow automatic answering for inbound media when the caller is not explicitly authorized. User agents implementing this specification MUST NOT establish a session providing outbound or bidirectional media sourced from the user agent without explicit user acceptance. Loopback media used for connectivity testing is not constrained by this requirement. This requirement is intended to assure that this extension can not be used to turn a UAS into a remote-controlled microphone (or "bug") without the knowledge of its user. Does this mandate that a UA always reject auto-answer when that might result in outbound media flows? So the user would not be able to override this policy? Doesn't that make "Answer-mode: auto" useful only for inbound media flows? This is certainly more secure, but I wonder at the specification of a feature that is mandated not to be used in about half the cases. Why bother? Why not specify the Auto answer mode for use only in outbound media flows if this policy requirement was to be placed on the system? ============================================================== Nits: p 6 o Alerting Mode includes behaviors in a SIP UA relating to to ^^ p 7 This syntax includes extension hooks, "token" for answer-modes values, ^^^^^^^^^^^^ ^^^^^^ either "answer-mode-value" or "Answer-Mode values" or "Answer-Mode's values" p 8 Manual: The UAS is asked to not accept ^^^^^^ not to (depending on how Draconian the RFC Editor adherence to grammar rules is) p 15 Consequently, UAS supporting this specification ^ a determination, and the default configuration SHOULD be to not include ^^^^^^ not to (depending on how Draconian the RFC Editor adherence to grammar rules is) p 21 intended to prevent "SPAM broadcast" attacks" where unexpected and ^ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Aug 13 01:52:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKSoF-0002C6-1P; Mon, 13 Aug 2007 01:49:47 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IKSoB-00026g-B0 for sip-confirm+ok@megatron.ietf.org; Mon, 13 Aug 2007 01:49:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKSoA-00026X-TL for sip@ietf.org; Mon, 13 Aug 2007 01:49:42 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IKSoA-0000rx-7r for sip@ietf.org; Mon, 13 Aug 2007 01:49:42 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l7D5nWXQ016052; Mon, 13 Aug 2007 00:49:32 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Aug 2007 00:49:32 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.29]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Aug 2007 07:49:28 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.5 Subject: RE: [Sip]RFC4916:the usage of connected identity in interdomain Date: Mon, 13 Aug 2007 07:49:28 +0200 Message-ID: <5D1A7985295922448D5550C94DE2918001570FA7@DEEXC1U01.de.lucent.com> In-Reply-To: <521911.36809.qm@web15313.mail.cnb.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip]RFC4916:the usage of connected identity in interdomain Thread-Index: AcfSmwpIwfA4oCxrT5iZxawQEwX5AAJFfjwg References: <0D5F89FAC29E2C41B98A6A762007F5D020620B@GBNTHT12009MSX.gb002.siemens.net> <521911.36809.qm@web15313.mail.cnb.yahoo.com> From: "DRAGE, Keith \(Keith\)" To: "ji ma" , "Elwell, John" , X-OriginalArrivalTime: 13 Aug 2007 05:49:28.0607 (UTC) FILETIME=[B67B82F0:01C7DD6D] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Just to note that the SIP working group has been round the response = problem once already and failed to find an acceptable solution. By all means put some new ideas in a draft, but please ready the = previous SIP working group proceedings and mailing list discussions = concerning this issue before submitting, and take these into account. Regards Keith =20 =20 ________________________________ From: ji ma [mailto:mjhorse1984@yahoo.com.cn]=20 Sent: Monday, July 30, 2007 12:15 PM To: Elwell, John; sip@ietf.org Subject: RE: [Sip]RFC4916:the usage of connected identity in = interdomain =09 =09 "Elwell, John" =D0=B4=B5=C0=A3=BA=20 Ma Ji, =09 See below. =09 John =09 > -----Original Message----- > From: ji ma [mailto:mjhorse1984@yahoo.com.cn]=20 > Sent: 30 July 2007 09:28 > To: sip@ietf.org > Subject: [Sip]RFC4916:the usage of connected identity in interdomain >=20 > Hi folks: >=20 > I have some questions after reading RFC4916, which=20 > descibes a solution of ensuring the identity of the UA that=20 > sends backward request after a dialog has formed. As far as=20 > I'm concerned, this specification is a supplement of RFC4474,=20 > which can only provide the validaty of the UA sending the=20 > request. However, RFC4916's 2 examples regarding to the its=20 > desciption only illustrate how to convey connected identity=20 > in an assumption that the caller and callee are in the same=20 > domain (example.com in particular), by using UPDATE messages=20 > which renew the From field of the sender. So my question is,=20 > can this specification resolve the authentication of the=20 > connected identity regarding to the scenories where the=20 > caller and callee are in different domains? > [Considering RFC4474, the authenticator will not be the=20 > responsible proxy for the request that contains a From field=20 > (bob@biloxi.example.com) that is different from its real=20 > identity (bob@chicago.example.com) ] [JRE] Although the examples show only a single domain, the RFC is = equally applicable when caller and callee are in different domains. Each = domain will provide its own authentication service. =09 >=20 > Another doubt I'm concerning about, is the content of=20 > last two paragraphs in page 3 of RFC4916, which is said as below: >=20 > The provision of the identity of the responder in a response > (commonly called "response identity") is outside the scope of this > document. >=20 > Note that even if identity were to be conveyed somehow in a > response, there would in general be difficulty=20 > authenticating the > UAS. Providing identity in a separate request allows normal > authentication techniques to be used. >=20 >=20 > I can't understand why it's difficult to authenticate=20 > response messages as I thought it could be authenticated in a=20 > way like the request it responses to(I don't know how much=20 > different in the process it should be regarding request and=20 > response) .So what's special for response? [JRE] SIP digest authentication is only specified for requests. In = particular, there is no mechanism for challenging a response. =09 >=20 > Regards, > Ma Ji =09 Thanks for reminding. When using connected identity,the sender has no = reason to use the previous identity the same as the From URI of the = request, who sends UPDATE which contains the new identity of the sender. =20 More, I deliberate that authenticating the validaty of the receiver in = a response(that means the To header) is also required, and so far I has = not see any draft nor maillist discussing it(maybe I missed), = considering the current mechanism is not enough for such issue, I thing = there should be some effort to be put to take this aspect into account. =20 Regards, Ma Ji ________________________________ = =C7=C0=D7=A2=D1=C5=BB=A2=C3=E2=B7=D1=D3=CA=CF=E43.5G=C8=DD=C1=BF=A3=AC20M= =B8=BD=BC=FE=A3=A1 =20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Aug 13 17:21:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKhK8-0001G6-Md; Mon, 13 Aug 2007 17:19:40 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IKhK7-0001FD-94 for sip-confirm+ok@megatron.ietf.org; Mon, 13 Aug 2007 17:19:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKhK6-0001DF-Pe for sip@ietf.org; Mon, 13 Aug 2007 17:19:38 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKhK5-00067I-Hd for sip@ietf.org; Mon, 13 Aug 2007 17:19:38 -0400 Received: from [65.65.155.30] (helo=[192.168.1.4]) by nylon.softarmor.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1IKhK4-0006Ar-R5; Mon, 13 Aug 2007 16:19:36 -0500 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <030FBE8B-B963-4EA1-A683-E4B25F538B19@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Date: Mon, 13 Aug 2007 16:19:21 -0500 To: sip List X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Sandy Murphy Subject: [Sip] Question on SIP Security considerations for future extensions X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I'm having quite an interesting conversation with Sandy Murphy (cc'd) who was tasked by sec-dir to review one of our drafts (draft-ietf-sip- answermode). This draft has some rather interesting security issues, since if implemented incorrectly and then abused it could allow an attacker to "bug your phone" -- that is, turn it into a remote listening device. Similar attacks could also be used to run up the victim's connectivity bill, run down the device's battery, aggravate the "voice hammer" DOS attack, and so on. This lead us into a discussion of the SIP security model in general. Most SIP practitioners who have been at it for awhile know that if the proxies we have decided to trust suddenly decide to get malicious, then we're very much at their mercy. They can do all sorts of things, including routing our media through interceptors, mangling SDP payloads, injecting (or blocking) instant messages, altering presence information, and so on. But this aspect of SIP is not obvious to naive implementors, or even to less naive security types. Maybe every SIP extension document should include a boiler-plate reminder about the sensitivity of proxies, then go on to enumerate and describe the new ways that malicious proxies (should there be such a thing) can wreak havoc using the extension being documented. what do you folks think? 1) Could a reasonable "How you could be violated by trusted proxies that turn rogue" boilerplate be drafted? 2) Would the practice of repeating this in drafts help or hurt us? 3) Would it be useful for us to document how each extension could be used by a rogue proxy? -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Aug 13 19:11:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKj2n-0000bD-Og; Mon, 13 Aug 2007 19:09:53 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IKj2l-0000b8-5e for sip-confirm+ok@megatron.ietf.org; Mon, 13 Aug 2007 19:09:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKj2k-0000b0-RT for sip@ietf.org; Mon, 13 Aug 2007 19:09:50 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IKj2k-0002EO-FL for sip@ietf.org; Mon, 13 Aug 2007 19:09:50 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 13 Aug 2007 16:09:47 -0700 X-IronPort-AV: i="4.19,256,1183359600"; d="scan'208"; a="199427197:sNHT44287713" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l7DN9lCa032632; Mon, 13 Aug 2007 16:09:47 -0700 Received: from dwingwxp01 ([10.32.240.198]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l7DN9cgB003133; Mon, 13 Aug 2007 23:09:47 GMT From: "Dan Wing" To: "'Dean Willis'" , "'sip List'" Subject: RE: [Sip] Question on SIP Security considerations for future extensions Date: Mon, 13 Aug 2007 16:09:35 -0700 Message-ID: <039a01c7ddff$09224bb0$c6f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <030FBE8B-B963-4EA1-A683-E4B25F538B19@softarmor.com> Thread-Index: Acfd77SWCdunx+cWQSWe4mnMpIrzagACm2hw DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1456; t=1187046587; x=1187910587; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20Question=20on=20SIP=20Security=20consideratio ns=20for=20future=20extensions |Sender:=20; bh=W8UIync4TJ2U+3QiolHltP7j+Lvch7nluY4DNNMJbWQ=; b=hBRlvIRJ7L0kHKNxg2aEeRH/Ap/7/vK6bhp45698rai58b0nUqCV4TJTOR/5KJm3iYH5rcn0 b9/ZJA7x4d1+CJ1WVpBFeKVdPZ0leZgOSdcJSYJ2oZrSTBq7wnYMhLgq; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: 'Sandy Murphy' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org ... > what do you folks think? > > 1) Could a reasonable "How you could be violated by trusted proxies > that turn rogue" boilerplate be drafted? > 2) Would the practice of repeating this in drafts help or hurt us? > 3) Would it be useful for us to document how each extension could be > used by a rogue proxy? In Chicago when I presented draft-wing-sip-identity-media, Cullen said transitive trust of the entire SIP network for Identity was fine, and RFC4474 was sufficient even with SBCs in the network. At the meeting, only Hadriel Kaplan said transitive trust for identity was not desirable with SBCs in the network. If identity can be spoofed by any trusted proxy in the SIP network you're connected to, you're going to be unable to gain strong identity that's needed for sip-answermode (defense mechanism #1 identified in section 7.3 of draft-ietf-sip-answermode-04) or even the strong identity needed to reliably display Caller-ID. However, based on the tepid response to sip-identity-media in Chicago, my conclusion is there is high comfort in the working group that proxies and SBCs do not go rogue. I found this surprising, and I continue to find this surprising. To your questions, I think such text would be valuable, but to really be useful we'd need an I-D that analyzed RFC3261 itself under the same microsocope. Such a document could start with the examples from your original post. -d _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Aug 13 19:56:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKjk4-0007gp-Gd; Mon, 13 Aug 2007 19:54:36 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IKjk3-0007gj-HL for sip-confirm+ok@megatron.ietf.org; Mon, 13 Aug 2007 19:54:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKjk3-0007gb-6u for sip@ietf.org; Mon, 13 Aug 2007 19:54:35 -0400 Received: from exprod6og52.obsmtp.com ([64.18.1.185]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IKjk2-0003PS-LA for sip@ietf.org; Mon, 13 Aug 2007 19:54:35 -0400 Received: from source ([192.150.11.134]) by exprod6ob52.postini.com ([64.18.5.12]) with SMTP; Mon, 13 Aug 2007 16:54:06 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l7DNqVot019660; Mon, 13 Aug 2007 16:52:35 -0700 (PDT) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l7DNpaI9025931; Mon, 13 Aug 2007 16:51:36 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Aug 2007 16:53:57 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Question on SIP Security considerations for futureextensions Date: Mon, 13 Aug 2007 16:52:03 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22C25781@namail5.corp.adobe.com> In-Reply-To: <039a01c7ddff$09224bb0$c6f0200a@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Question on SIP Security considerations for futureextensions Thread-Index: Acfd77SWCdunx+cWQSWe4mnMpIrzagACm2hwAAI6/CA= References: <030FBE8B-B963-4EA1-A683-E4B25F538B19@softarmor.com> <039a01c7ddff$09224bb0$c6f0200a@cisco.com> From: "Henry Sinnreich" To: "Dan Wing" , "Dean Willis" , "sip List" X-OriginalArrivalTime: 13 Aug 2007 23:53:57.0721 (UTC) FILETIME=[36B25C90:01C7DE05] X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: Sandy Murphy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dan, >there is high comfort in the working group that proxies and SBCs do not >go rogue. This is really not surprising given that nobody in the meeting was prepared to report on _measured_ incidents vs. voicing opinions. I share your concern since a stateful SBC, that also handles media is the ideal target for evil doers on the Internet. Where else would someone intercept phone calls and the signaling, all conveniently in one place? Now with peering, a questionable chain of trust develops that is even more likely to break. If there were only a way to collect incident reports... But maybe we are barking up the wrong tree: The purpose here is not security but usage billing and whenever possible, collecting roaming charges. Henry -----Original Message----- From: Dan Wing [mailto:dwing@cisco.com]=20 Sent: Monday, August 13, 2007 6:10 PM To: 'Dean Willis'; 'sip List' Cc: 'Sandy Murphy' Subject: RE: [Sip] Question on SIP Security considerations for futureextensions ... > what do you folks think? >=20 > 1) Could a reasonable "How you could be violated by trusted proxies =20 > that turn rogue" boilerplate be drafted? > 2) Would the practice of repeating this in drafts help or hurt us? > 3) Would it be useful for us to document how each extension could be =20 > used by a rogue proxy? In Chicago when I presented draft-wing-sip-identity-media, Cullen said transitive trust of the entire SIP network for Identity was=20 fine, and RFC4474 was sufficient even with SBCs in the network. At=20 the meeting, only Hadriel Kaplan said transitive trust for identity=20 was not desirable with SBCs in the network. If identity can be=20 spoofed by any trusted proxy in the SIP network you're connected=20 to, you're going to be unable to gain strong identity that's needed=20 for sip-answermode (defense mechanism #1 identified in section 7.3 of draft-ietf-sip-answermode-04) or even the strong identity needed to reliably display Caller-ID. However, based on the tepid response to sip-identity-media in Chicago, my conclusion is there is high comfort in the working=20 group that proxies and SBCs do not go rogue. I found this surprising, and I continue to find this surprising. To your questions, I think such text would be valuable, but to really be useful we'd need an I-D that analyzed RFC3261 itself under the same microsocope. Such a document could start with the examples from your original post. -d _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Aug 13 19:58:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKjmM-0001OZ-DU; Mon, 13 Aug 2007 19:56:58 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IKjmL-0001LT-Eo for sip-confirm+ok@megatron.ietf.org; Mon, 13 Aug 2007 19:56:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKjmL-0001K5-4H for sip@ietf.org; Mon, 13 Aug 2007 19:56:57 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKjmK-0003Yw-LJ for sip@ietf.org; Mon, 13 Aug 2007 19:56:57 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 13 Aug 2007 19:56:56 -0400 X-IronPort-AV: i="4.19,257,1183348800"; d="scan'208"; a="67899849:sNHT48654290" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l7DNuuDW029916; Mon, 13 Aug 2007 19:56:56 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l7DNulmd019255; Mon, 13 Aug 2007 23:56:48 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Aug 2007 19:56:47 -0400 Received: from [161.44.174.244] ([161.44.174.244]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Aug 2007 19:56:47 -0400 Message-ID: <46C0EFC0.7060509@cisco.com> Date: Mon, 13 Aug 2007 19:56:48 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] Question on SIP Security considerations for future extensions References: <030FBE8B-B963-4EA1-A683-E4B25F538B19@softarmor.com> In-Reply-To: <030FBE8B-B963-4EA1-A683-E4B25F538B19@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Aug 2007 23:56:47.0388 (UTC) FILETIME=[9BD37DC0:01C7DE05] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2176; t=1187049416; x=1187913416; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20Question=20on=20SIP=20Security=20consideratio ns=20for=20future=20extensions |Sender:=20 |To:=20Dean=20Willis=20; bh=HrancnZBC5rbP+/3QA8zsmK3qxy7Al40vW5yzzmfHk4=; b=sScvgKSQhppLNLQk5eSVQc/becVD8yfuTF7UVlT7t/98vDuln/I+kPnczmwr2dmJbDYcVFk/ yJ+AIzHZYnYgr0LThhrzLyoZvaAIv0Qgf1bSr8etpkfZ+tkhAJ/F4eZw; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: sip List , Sandy Murphy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Maybe such a policy would encourage the adoption of sipsec. Paul Dean Willis wrote: > > I'm having quite an interesting conversation with Sandy Murphy (cc'd) > who was tasked by sec-dir to review one of our drafts > (draft-ietf-sip-answermode). This draft has some rather interesting > security issues, since if implemented incorrectly and then abused it > could allow an attacker to "bug your phone" -- that is, turn it into a > remote listening device. Similar attacks could also be used to run up > the victim's connectivity bill, run down the device's battery, aggravate > the "voice hammer" DOS attack, and so on. > > This lead us into a discussion of the SIP security model in general. > Most SIP practitioners who have been at it for awhile know that if the > proxies we have decided to trust suddenly decide to get malicious, then > we're very much at their mercy. They can do all sorts of things, > including routing our media through interceptors, mangling SDP payloads, > injecting (or blocking) instant messages, altering presence information, > and so on. > > But this aspect of SIP is not obvious to naive implementors, or even to > less naive security types. > > Maybe every SIP extension document should include a boiler-plate > reminder about the sensitivity of proxies, then go on to enumerate and > describe the new ways that malicious proxies (should there be such a > thing) can wreak havoc using the extension being documented. > > what do you folks think? > > 1) Could a reasonable "How you could be violated by trusted proxies that > turn rogue" boilerplate be drafted? > 2) Would the practice of repeating this in drafts help or hurt us? > 3) Would it be useful for us to document how each extension could be > used by a rogue proxy? > > -- > Dean > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Aug 14 00:48:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKoHh-00025d-5A; Tue, 14 Aug 2007 00:45:37 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IKoHf-00025X-Hz for sip-confirm+ok@megatron.ietf.org; Tue, 14 Aug 2007 00:45:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKoHf-00025O-7m for sip@ietf.org; Tue, 14 Aug 2007 00:45:35 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IKoHe-0005Eg-Sy for sip@ietf.org; Tue, 14 Aug 2007 00:45:35 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 13 Aug 2007 21:45:34 -0700 X-IronPort-AV: i="4.19,257,1183359600"; d="scan'208"; a="170867215:sNHT46320606" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l7E4jYCt011083; Mon, 13 Aug 2007 21:45:34 -0700 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-5.cisco.com (8.12.10/8.12.6) with SMTP id l7E4jTiG013487; Tue, 14 Aug 2007 04:45:34 GMT In-Reply-To: <039a01c7ddff$09224bb0$c6f0200a@cisco.com> References: <039a01c7ddff$09224bb0$c6f0200a@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <030B1D85-B51F-435D-8125-A2D556A14022@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Question on SIP Security considerations for future extensions Date: Mon, 13 Aug 2007 21:44:12 -0700 To: Dan Wing X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=352; t=1187066734; x=1187930734; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[Sip]=20Question=20on=20SIP=20Security=20consideratio ns=20for=20future=20extensions |Sender:=20; bh=QzmcOSlC5eU2eCClyWwSmR5jXVO2QtsA1HS+G0vZfqk=; b=YQnct3Y8t/c7slxnrcQ3/QFbK1J7Jw8cRHwrvhnxrLE5q6LMZ4O+KY0WVo6TzVXEIXhQqrEc Y0L9kzaA8k5MEM6RZdjQMNHAQVrkjKYP+KRWGRA7zBpVbMbw0+uTQ5DO; Authentication-Results: sj-dkim-4; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: 'sip List' , 'Sandy Murphy' , 'Dean Willis' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Aug 13, 2007, at 4:09 PM, Dan Wing wrote: > Cullen > said transitive trust of the entire SIP network for Identity was > fine Uh, I don't think I exactly said that but if I did, I like to contradict myself now :-) Actually if I thought this, it seems that the From header would be fine and we would have no need for 4474 or 3325. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Aug 14 01:05:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKoYx-0006cm-UM; Tue, 14 Aug 2007 01:03:27 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IKoYw-0006ce-JB for sip-confirm+ok@megatron.ietf.org; Tue, 14 Aug 2007 01:03:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKoYw-0006cW-8V for sip@ietf.org; Tue, 14 Aug 2007 01:03:26 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IKoYv-0005jY-Nj for sip@ietf.org; Tue, 14 Aug 2007 01:03:26 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 13 Aug 2007 22:03:26 -0700 X-IronPort-AV: i="4.19,257,1183359600"; d="scan'208"; a="513198886:sNHT59909002" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l7E53Pgj031067; Mon, 13 Aug 2007 22:03:25 -0700 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-3.cisco.com (8.12.10/8.12.6) with SMTP id l7E53IgC014849; Tue, 14 Aug 2007 05:03:18 GMT In-Reply-To: <46C0EFC0.7060509@cisco.com> References: <030FBE8B-B963-4EA1-A683-E4B25F538B19@softarmor.com> <46C0EFC0.7060509@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5143C6A2-FBFC-4CA1-8931-64AB346C24BC@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Question on SIP Security considerations for future extensions Date: Mon, 13 Aug 2007 22:02:01 -0700 To: Paul Kyzivat X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3098; t=1187067805; x=1187931805; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[Sip]=20Question=20on=20SIP=20Security=20consideratio ns=20for=20future=20extensions |Sender:=20; bh=XhKhdaiYQD2ZKS3fWAd+K3SjpMtsPNax9m524SFgIeI=; b=UJcqJGEbrtGUOvXN5qe8YEQPdVxw+NDr8WvfAF0BnQX1m7NGfTLEjz8Pekjp/hiXf6MpX10B xn0XhfdNFbx3am5p/HjsA0sSPVPA8gJvJFHavYM3lNyZzNAs63kmD9f1sfjsFkKZxTV7nAEkmw kQznujMD2UAaGM3qsA7C90jqk=; Authentication-Results: sj-dkim-1; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: sip List , Sandy Murphy , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I will note that we do have security mechanism to provide confidentially over the bodies (but not headers) for attacks from proxies we do not have a trust relationship with - and this is one of the aspects used in determining if certain semantics might be better in a body or header. Cullen PS - I fail to see how sipsec will help with the basic problem of if Alice sends a call to a proxy and the proxy routes the call to some evil user instead of sending it to Bob. On Aug 13, 2007, at 4:56 PM, Paul Kyzivat wrote: > Maybe such a policy would encourage the adoption of sipsec. > > Paul > > Dean Willis wrote: >> I'm having quite an interesting conversation with Sandy Murphy >> (cc'd) who was tasked by sec-dir to review one of our drafts >> (draft-ietf-sip-answermode). This draft has some rather >> interesting security issues, since if implemented incorrectly and >> then abused it could allow an attacker to "bug your phone" -- that >> is, turn it into a remote listening device. Similar attacks could >> also be used to run up the victim's connectivity bill, run down >> the device's battery, aggravate the "voice hammer" DOS attack, and >> so on. >> This lead us into a discussion of the SIP security model in >> general. Most SIP practitioners who have been at it for awhile >> know that if the proxies we have decided to trust suddenly decide >> to get malicious, then we're very much at their mercy. They can do >> all sorts of things, including routing our media through >> interceptors, mangling SDP payloads, injecting (or blocking) >> instant messages, altering presence information, and so on. >> But this aspect of SIP is not obvious to naive implementors, or >> even to less naive security types. >> Maybe every SIP extension document should include a boiler-plate >> reminder about the sensitivity of proxies, then go on to enumerate >> and describe the new ways that malicious proxies (should there be >> such a thing) can wreak havoc using the extension being documented. >> what do you folks think? >> 1) Could a reasonable "How you could be violated by trusted >> proxies that turn rogue" boilerplate be drafted? >> 2) Would the practice of repeating this in drafts help or hurt us? >> 3) Would it be useful for us to document how each extension could >> be used by a rogue proxy? >> -- >> 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 sip-bounces@ietf.org Tue Aug 14 01:13:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKogr-000426-Kl; Tue, 14 Aug 2007 01:11:37 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IKogp-00041x-Jo for sip-confirm+ok@megatron.ietf.org; Tue, 14 Aug 2007 01:11:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKogp-00041p-6y for sip@ietf.org; Tue, 14 Aug 2007 01:11:35 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKogn-0004cU-VO for sip@ietf.org; Tue, 14 Aug 2007 01:11:35 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 13 Aug 2007 22:11:33 -0700 X-IronPort-AV: i="4.19,257,1183359600"; d="scan'208"; a="199564934:sNHT45153351" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l7E5BXJB019130; Mon, 13 Aug 2007 22:11:33 -0700 Received: from dwingwxp01 ([10.32.240.198]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l7E5BVa1023641; Tue, 14 Aug 2007 05:11:31 GMT From: "Dan Wing" To: "'Cullen Jennings'" Subject: RE: [Sip] Question on SIP Security considerations for future extensions Date: Mon, 13 Aug 2007 22:11:31 -0700 Message-ID: <042901c7de31$9457bc10$c6f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <030B1D85-B51F-435D-8125-A2D556A14022@cisco.com> Thread-Index: AcfeLfNKDXn/CjuPSGOWSVDWAkFaTQAAG8eA DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1737; t=1187068293; x=1187932293; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20Question=20on=20SIP=20Security=20consideratio ns=20for=20future=20extensions |Sender:=20; bh=7/kTQfIBv84GNVM5vS7nAktRuBPqwi0gLHpMoC+pvdc=; b=JSoEyGHjBLlrfX0jlbfHExJVO5HqO8vzT5a0b0eyReyQ2kmi7+NvDO8nS767/cyM1E9Ls7cP CWje98pEsl9PRmcawMl+JE3GOHDuz5/bF5fxJ9LHEKcBJjE59mbcg8EZ; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: 'sip List' , 'Sandy Murphy' , 'Dean Willis' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > > Cullen said transitive trust of the entire SIP network for > > Identity was fine > > Uh, I don't think I exactly said that but if I did, I like to > contradict myself now :-) Actually if I thought this, it seems that > the From header would be fine and we would have no need for 4474 or > 3325. RFC4474 and RFC3325 are useful and valuable and necessary. I have not said otherwise. Thing is, their applicability on the SIP networks being designed and deployed is limited, much as SIP's early design had UACs sending SIP directly to UASs and slowly proxies became necessary due to NATs, firewalls, network-provided QoS (via SDP snooping), and so on. I'm not sure why you removed ", and RFC4474 was sufficient even with SBCs in the network" from my sentence, as it was relevant to the meaning of my statement. As I explained in Chicago in the last timeslot in SIP, RFC4474 doesn't work if the Invite traverses SBCs that are not owned by the originating domain's authentication agent. SIP networks deployed and operating today have SBCs that aren't operated by the originating domain's authentication agent. Thus, I don't see how we get identity in a network with SBCs, except via transitive trust: I trust my provider to have validated the signature they received, who trusts the upstream provider to have validated the signature they received, and so on. This has security properties identical to using P-A-I between those domains. draft-ietf-sip-answermode is only one example of the significant need for identity in SIP. Without identity that works across SIP networks being built today, we can't provide the foundation for its necessary authorization mechanism. -d _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Aug 14 07:57:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKuyY-0000At-I8; Tue, 14 Aug 2007 07:54:18 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IKuyX-0000Am-2f for sip-confirm+ok@megatron.ietf.org; Tue, 14 Aug 2007 07:54:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKuyW-0000Ad-Na for sip@ietf.org; Tue, 14 Aug 2007 07:54:16 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IKuyW-0000Ub-5M for sip@ietf.org; Tue, 14 Aug 2007 07:54:16 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 14 Aug 2007 04:54:15 -0700 X-IronPort-AV: i="4.19,259,1183359600"; d="scan'208"; a="170900919:sNHT49851045" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l7EBsF3O014431; Tue, 14 Aug 2007 04:54:15 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l7EBs4Vx011564; Tue, 14 Aug 2007 11:54:07 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Aug 2007 07:54:05 -0400 Received: from [10.86.242.195] ([10.86.242.195]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Aug 2007 07:54:05 -0400 Message-ID: <46C197DC.9050001@cisco.com> Date: Tue, 14 Aug 2007 07:54:04 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [Sip] Question on SIP Security considerations for future extensions References: <030FBE8B-B963-4EA1-A683-E4B25F538B19@softarmor.com> <46C0EFC0.7060509@cisco.com> <5143C6A2-FBFC-4CA1-8931-64AB346C24BC@cisco.com> In-Reply-To: <5143C6A2-FBFC-4CA1-8931-64AB346C24BC@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Aug 2007 11:54:05.0385 (UTC) FILETIME=[D078AB90:01C7DE69] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3355; t=1187092455; x=1187956455; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20Question=20on=20SIP=20Security=20consideratio ns=20for=20future=20extensions |Sender:=20; bh=tU1DOURFSSk8pcxylgbnXviO8PAapOezD9xTEtFrDYg=; b=pNq66f6ZOa2ofsGMgICzKr8tvRQYKhPwlobeI6mycxFK4WmDshWycQZQFLpgHd7YfRadMJOR 4FUwisFfpZa7yQdwi5qCq09igEd8SOphvIw45G/GjmMSJddMmnt6BuxU; Authentication-Results: sj-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: sip List , Sandy Murphy , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Cullen Jennings wrote: > > I will note that we do have security mechanism to provide confidentially > over the bodies (but not headers) for attacks from proxies we do not > have a trust relationship with - and this is one of the aspects used in > determining if certain semantics might be better in a body or header. > > Cullen > > PS - I fail to see how sipsec will help with the basic problem of if > Alice sends a call to a proxy and the proxy routes the call to some evil > user instead of sending it to Bob. True. But I think that is a lesser problem, if you can determine you have reached the wrong person. I think it is a compromise people are willing to make - to find a callee. Paul > On Aug 13, 2007, at 4:56 PM, Paul Kyzivat wrote: > >> Maybe such a policy would encourage the adoption of sipsec. >> >> Paul >> >> Dean Willis wrote: >>> I'm having quite an interesting conversation with Sandy Murphy (cc'd) >>> who was tasked by sec-dir to review one of our drafts >>> (draft-ietf-sip-answermode). This draft has some rather interesting >>> security issues, since if implemented incorrectly and then abused it >>> could allow an attacker to "bug your phone" -- that is, turn it into >>> a remote listening device. Similar attacks could also be used to run >>> up the victim's connectivity bill, run down the device's battery, >>> aggravate the "voice hammer" DOS attack, and so on. >>> This lead us into a discussion of the SIP security model in general. >>> Most SIP practitioners who have been at it for awhile know that if >>> the proxies we have decided to trust suddenly decide to get >>> malicious, then we're very much at their mercy. They can do all sorts >>> of things, including routing our media through interceptors, mangling >>> SDP payloads, injecting (or blocking) instant messages, altering >>> presence information, and so on. >>> But this aspect of SIP is not obvious to naive implementors, or even >>> to less naive security types. >>> Maybe every SIP extension document should include a boiler-plate >>> reminder about the sensitivity of proxies, then go on to enumerate >>> and describe the new ways that malicious proxies (should there be >>> such a thing) can wreak havoc using the extension being documented. >>> what do you folks think? >>> 1) Could a reasonable "How you could be violated by trusted proxies >>> that turn rogue" boilerplate be drafted? >>> 2) Would the practice of repeating this in drafts help or hurt us? >>> 3) Would it be useful for us to document how each extension could be >>> used by a rogue proxy? >>> --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 sip-bounces@ietf.org Tue Aug 14 09:55:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKwpm-0003xa-3s; Tue, 14 Aug 2007 09:53:22 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IKwpk-0003wq-Hm for sip-confirm+ok@megatron.ietf.org; Tue, 14 Aug 2007 09:53:20 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKwpk-0003wh-6n for sip@ietf.org; Tue, 14 Aug 2007 09:53:20 -0400 Received: from imr1.ericy.com ([198.24.6.9]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IKwpj-0004uP-Gt for sip@ietf.org; Tue, 14 Aug 2007 09:53:20 -0400 Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id l7EDwnFZ013143; Tue, 14 Aug 2007 08:58:51 -0500 Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Aug 2007 08:53:15 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Question on SIP Security considerations for futureextensions Date: Tue, 14 Aug 2007 08:53:13 -0500 Message-ID: <2D7CEF7F8F759C4AB79D7C46666F329C015DB112@eusrcmw721.eamcs.ericsson.se> In-Reply-To: <46C197DC.9050001@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Question on SIP Security considerations for futureextensions Thread-Index: AcfeaeRI9DbwBRftTpqkaYDdu9xurgADZbUQ References: <030FBE8B-B963-4EA1-A683-E4B25F538B19@softarmor.com><46C0EFC0.7060509@cisco.com><5143C6A2-FBFC-4CA1-8931-64AB346C24BC@cisco.com> <46C197DC.9050001@cisco.com> From: "Arun Punj (WD/EUS)" To: "Paul Kyzivat" , "Cullen Jennings" X-OriginalArrivalTime: 14 Aug 2007 13:53:15.0820 (UTC) FILETIME=[767676C0:01C7DE7A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: sip List , Dean Willis , Sandy Murphy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Folks,=20 I have a simple question/comments see below. thanks Arunrajan -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Sent: Tuesday, August 14, 2007 7:54 AM To: Cullen Jennings Cc: sip List; Sandy Murphy; Dean Willis Subject: Re: [Sip] Question on SIP Security considerations for futureextensions Cullen Jennings wrote: >=20 > I will note that we do have security mechanism to provide confidentially=20 > over the bodies (but not headers) for attacks from proxies we do not=20 > have a trust relationship with - and this is one of the aspects used in=20 > determining if certain semantics might be better in a body or header. >=20 > Cullen >=20 > PS - I fail to see how sipsec will help with the basic problem of if=20 > Alice sends a call to a proxy and the proxy routes the call to some evil=20 > user instead of sending it to Bob. True. But I think that is a lesser problem, if you can determine you=20 have reached the wrong person. I think it is a compromise people are=20 willing to make - to find a callee. [ap]=20 Is there a way to find out that you have reached the wrong person? Because it would seem, that is the very basis of security, If alice calls bob, and is connected to charles, or worse is connected to bob through charles - the call is not secure. It would seem that RFC 4474, does not prevent this from happening and is kind of pointless for that reason. I have not read any of the sipsec work so maybe I am just being ignorant, right now.=20 As a general principle, I feel very uncomfortable with high level of *trust* in the network entities. I think a model like TLS/SSH where the endpoints verify each other is desirable ( If not imperative) for sip. That is caller/callee must be able to authenticate/prevent man in the middle with as little help from external entities as possible, maybe all I can trust is my proxy/HLR/Authenticationserver with each I have a PSK trust relationship. I understand this requires an extensive infrastructure support ( for certs/keys) etc specially if conference calls are to be supported, but that is all the more reason to start now. [\ap]=20 Paul > On Aug 13, 2007, at 4:56 PM, Paul Kyzivat wrote: >=20 >> Maybe such a policy would encourage the adoption of sipsec. >> >> Paul >> >> Dean Willis wrote: >>> I'm having quite an interesting conversation with Sandy Murphy (cc'd)=20 >>> who was tasked by sec-dir to review one of our drafts=20 >>> (draft-ietf-sip-answermode). This draft has some rather interesting=20 >>> security issues, since if implemented incorrectly and then abused it >>> could allow an attacker to "bug your phone" -- that is, turn it into >>> a remote listening device. Similar attacks could also be used to run >>> up the victim's connectivity bill, run down the device's battery,=20 >>> aggravate the "voice hammer" DOS attack, and so on. >>> This lead us into a discussion of the SIP security model in general. >>> Most SIP practitioners who have been at it for awhile know that if=20 >>> the proxies we have decided to trust suddenly decide to get=20 >>> malicious, then we're very much at their mercy. They can do all sorts=20 >>> of things, including routing our media through interceptors, mangling=20 >>> SDP payloads, injecting (or blocking) instant messages, altering=20 >>> presence information, and so on. >>> But this aspect of SIP is not obvious to naive implementors, or even >>> to less naive security types. >>> Maybe every SIP extension document should include a boiler-plate=20 >>> reminder about the sensitivity of proxies, then go on to enumerate=20 >>> and describe the new ways that malicious proxies (should there be=20 >>> such a thing) can wreak havoc using the extension being documented. >>> what do you folks think? >>> 1) Could a reasonable "How you could be violated by trusted proxies=20 >>> that turn rogue" boilerplate be drafted? >>> 2) Would the practice of repeating this in drafts help or hurt us? >>> 3) Would it be useful for us to document how each extension could be >>> used by a rogue proxy? >>> --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 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Aug 14 11:30:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKyJh-0005Vi-LR; Tue, 14 Aug 2007 11:28:21 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IKyJg-0005Vc-6X for sip-confirm+ok@megatron.ietf.org; Tue, 14 Aug 2007 11:28:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKyJf-0005VU-T8 for sip@ietf.org; Tue, 14 Aug 2007 11:28:19 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKyJe-0004e6-F2 for sip@ietf.org; Tue, 14 Aug 2007 11:28:19 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 14 Aug 2007 08:28:18 -0700 X-IronPort-AV: i="4.19,260,1183359600"; d="scan'208"; a="199866136:sNHT57877758" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l7EFSHI4013069; Tue, 14 Aug 2007 08:28:17 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l7EFRvWH018569; Tue, 14 Aug 2007 15:28:09 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Aug 2007 11:27:52 -0400 Received: from [161.44.174.244] ([161.44.174.244]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Aug 2007 11:27:52 -0400 Message-ID: <46C1C9FA.6000404@cisco.com> Date: Tue, 14 Aug 2007 11:27:54 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "Arun Punj (WD/EUS)" Subject: Re: [Sip] Question on SIP Security considerations for futureextensions References: <030FBE8B-B963-4EA1-A683-E4B25F538B19@softarmor.com><46C0EFC0.7060509@cisco.com><5143C6A2-FBFC-4CA1-8931-64AB346C24BC@cisco.com> <46C197DC.9050001@cisco.com> <2D7CEF7F8F759C4AB79D7C46666F329C015DB112@eusrcmw721.eamcs.ericsson.se> In-Reply-To: <2D7CEF7F8F759C4AB79D7C46666F329C015DB112@eusrcmw721.eamcs.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Aug 2007 15:27:52.0207 (UTC) FILETIME=[ADDA61F0:01C7DE87] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5878; t=1187105297; x=1187969297; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20Question=20on=20SIP=20Security=20consideratio ns=20for=20futureextensions |Sender:=20; bh=StacyatNgATons+64dbAv5pjkiPc2zQEH8XTidPTAto=; b=FnSTTqr7w7EJIOPa2oSk6Kw6BhDgyPtadrReA3aTICo6T8yMCuxdZch8E2coRh4UhXb/9wQ4 9zzctykHQnxwnGkApM6XLSVXP6wozXgOTKlFcxaYQdQylUd8hPV5+Q00; Authentication-Results: sj-dkim-3; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: Cullen Jennings , sip List , Sandy Murphy , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Arun Punj (WD/EUS) wrote: > Folks, > I have a simple question/comments see below. [snip] > [ap] > Is there a way to find out that you have reached the wrong person? Not in general. Its not well defined who the *right* person is if forwarding is involved. There have been proposals to push all forwarding/redirection back to the UAC, so that it can make its own decision is the new target is an acceptable target to it. I believe that is necessary to make sipsec work. The sipsec draft establishes an e2e TLS connection. This allows the cert of the UAS to be verified. Of course it will only work if the UAS *has* a cert that can be verified by the UAC, which brings up many issues of certificate management, etc. Its far from a done deal. > Because it would seem, that is the very basis of security, If alice > calls bob, and is connected to charles, or worse is connected to bob > through charles - the call is not secure. It would seem that RFC 4474, > does not > prevent this from happening and is kind of pointless for that reason. I > have not read any of the sipsec work so maybe I am just being ignorant, > right now. > > As a general principle, I feel very uncomfortable with high level of > *trust* in the network entities. I think a model like TLS/SSH where the > endpoints verify each other is desirable ( If not imperative) for sip. > That is caller/callee must be able to authenticate/prevent man in the > middle with as little help from external entities as possible, maybe all > I can trust is my proxy/HLR/Authenticationserver with each I have a PSK > trust relationship. Yeah, a lot of people share your concern. The need for proxies was motivated initially by the lack of fixed addresses for phones. Hence the need for registration and retargeting from an AOR to the address of the phone. However, this is pretty similar to not knowing what server you want to contact on the web. When you don't know you use a search engine to find some candidates. Then you can, if you wish, establish a secure connection to one of the candidates. In the end you can know you are talking to somebody who has rights to the address you are connected to. But you still have to trust a bunch of infrastructure to know that is who you want to be talking to. Paul > I understand this requires an extensive infrastructure support ( for > certs/keys) etc specially if conference calls are to be supported, but > that is all the more reason to start now. > > [\ap] > > Paul > >> On Aug 13, 2007, at 4:56 PM, Paul Kyzivat wrote: >> >>> Maybe such a policy would encourage the adoption of sipsec. >>> >>> Paul >>> >>> Dean Willis wrote: >>>> I'm having quite an interesting conversation with Sandy Murphy > (cc'd) >>>> who was tasked by sec-dir to review one of our drafts >>>> (draft-ietf-sip-answermode). This draft has some rather interesting >>>> security issues, since if implemented incorrectly and then abused it > >>>> could allow an attacker to "bug your phone" -- that is, turn it into > >>>> a remote listening device. Similar attacks could also be used to run > >>>> up the victim's connectivity bill, run down the device's battery, >>>> aggravate the "voice hammer" DOS attack, and so on. >>>> This lead us into a discussion of the SIP security model in general. > >>>> Most SIP practitioners who have been at it for awhile know that if >>>> the proxies we have decided to trust suddenly decide to get >>>> malicious, then we're very much at their mercy. They can do all > sorts >>>> of things, including routing our media through interceptors, > mangling >>>> SDP payloads, injecting (or blocking) instant messages, altering >>>> presence information, and so on. >>>> But this aspect of SIP is not obvious to naive implementors, or even > >>>> to less naive security types. >>>> Maybe every SIP extension document should include a boiler-plate >>>> reminder about the sensitivity of proxies, then go on to enumerate >>>> and describe the new ways that malicious proxies (should there be >>>> such a thing) can wreak havoc using the extension being documented. >>>> what do you folks think? >>>> 1) Could a reasonable "How you could be violated by trusted proxies >>>> that turn rogue" boilerplate be drafted? >>>> 2) Would the practice of repeating this in drafts help or hurt us? >>>> 3) Would it be useful for us to document how each extension could be > >>>> used by a rogue proxy? >>>> --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 > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Aug 14 12:12:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKyyE-0002jC-2A; Tue, 14 Aug 2007 12:10:14 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IKyyB-0002j7-Sj for sip-confirm+ok@megatron.ietf.org; Tue, 14 Aug 2007 12:10:11 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKyyB-0002iz-IS for sip@ietf.org; Tue, 14 Aug 2007 12:10:11 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IKyyB-0001dk-6X for sip@ietf.org; Tue, 14 Aug 2007 12:10:11 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id l7EGA5q9022649; Tue, 14 Aug 2007 11:10:05 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id l7EGA5a20774; Tue, 14 Aug 2007 11:10:05 -0500 (CDT) Message-ID: <46C1D3DD.5040608@alcatel-lucent.com> Date: Tue, 14 Aug 2007 11:10:05 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [Sip] Question on SIP Security considerations for future extensions References: <030FBE8B-B963-4EA1-A683-E4B25F538B19@softarmor.com> <46C0EFC0.7060509@cisco.com> <5143C6A2-FBFC-4CA1-8931-64AB346C24BC@cisco.com> In-Reply-To: <5143C6A2-FBFC-4CA1-8931-64AB346C24BC@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: sip List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Cullen Jennings wrote: > > I will note that we do have security mechanism to provide > confidentially over the bodies (but not headers) for attacks from > proxies we do not have a trust relationship with - and this is one of > the aspects used in determining if certain semantics might be better in > a body or header. > > Cullen > > PS - I fail to see how sipsec will help with the basic problem of if > Alice sends a call to a proxy and the proxy routes the call to some > evil user instead of sending it to Bob. The assumption in sipsec is that Bob has a X.509 cert that Alice verifies directly. It may be a self-signed cert, or it may be rooted in a common CA. If former, then a fingerprint could be exchanged a-priori between Alice and Bob. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Aug 14 12:19:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKz5s-0001vJ-L7; Tue, 14 Aug 2007 12:18:08 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IKz5r-0001ux-S8 for sip-confirm+ok@megatron.ietf.org; Tue, 14 Aug 2007 12:18:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKz5r-0001um-IT for sip@ietf.org; Tue, 14 Aug 2007 12:18:07 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKz5q-0007b3-AS for sip@ietf.org; Tue, 14 Aug 2007 12:18:07 -0400 Received: from [65.65.155.30] (helo=[192.168.1.2]) by nylon.softarmor.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1IKz5n-0007Py-DT; Tue, 14 Aug 2007 11:18:05 -0500 In-Reply-To: <5143C6A2-FBFC-4CA1-8931-64AB346C24BC@cisco.com> References: <030FBE8B-B963-4EA1-A683-E4B25F538B19@softarmor.com> <46C0EFC0.7060509@cisco.com> <5143C6A2-FBFC-4CA1-8931-64AB346C24BC@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Question on SIP Security considerations for future extensions Date: Tue, 14 Aug 2007 11:17:52 -0500 To: Cullen Jennings X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: sip List , Paul Kyzivat , Sandy Murphy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Aug 14, 2007, at 12:02 AM, Cullen Jennings wrote: > > I will note that we do have security mechanism to provide > confidentially over the bodies (but not headers) for attacks from > proxies we do not have a trust relationship with - and this is one > of the aspects used in determining if certain semantics might be > better in a body or header. > > Cullen > > PS - I fail to see how sipsec will help with the basic problem of > if Alice sends a call to a proxy and the proxy routes the call to > some evil user instead of sending it to Bob. Since the TLS connection of sipsec is established UA to UA, the evildoer in your example would have to have Bob's cert (aka "private key"). If the evildoer does not have Bob's cert, Alice will be able to tell that the evildoer is not Bob. Of course, this requires a workable public key infrastructure. But then we think we're getting one of those from draft-ietf-sip-certs, so maybe this is doable after all. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Aug 14 12:21:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKz7C-0002V8-2U; Tue, 14 Aug 2007 12:19:30 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IKz7A-0002V2-C2 for sip-confirm+ok@megatron.ietf.org; Tue, 14 Aug 2007 12:19:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKz7A-0002Uu-2Z for sip@ietf.org; Tue, 14 Aug 2007 12:19:28 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKz78-0007fC-TG for sip@ietf.org; Tue, 14 Aug 2007 12:19:28 -0400 Received: from [65.65.155.30] (helo=[192.168.1.2]) by nylon.softarmor.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1IKz78-0007QJ-JX; Tue, 14 Aug 2007 11:19:26 -0500 In-Reply-To: <5143C6A2-FBFC-4CA1-8931-64AB346C24BC@cisco.com> References: <030FBE8B-B963-4EA1-A683-E4B25F538B19@softarmor.com> <46C0EFC0.7060509@cisco.com> <5143C6A2-FBFC-4CA1-8931-64AB346C24BC@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <19E7C651-99BF-4D7E-B124-87E1A2284E81@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Question on SIP Security considerations for future extensions Date: Tue, 14 Aug 2007 11:19:15 -0500 To: Cullen Jennings X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: sip List , Paul Kyzivat , Sandy Murphy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Aug 14, 2007, at 12:02 AM, Cullen Jennings wrote: > > I will note that we do have security mechanism to provide > confidentially over the bodies (but not headers) for attacks from > proxies we do not have a trust relationship with - and this is one > of the aspects used in determining if certain semantics might be > better in a body or header. > And you've got working examples of this security mechanism in deployed networks? -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Aug 14 12:45:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKzUB-0004R4-5j; Tue, 14 Aug 2007 12:43:15 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IKzUA-0004Qz-9o for sip-confirm+ok@megatron.ietf.org; Tue, 14 Aug 2007 12:43:14 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKzU9-0004Qr-Vt for sip@ietf.org; Tue, 14 Aug 2007 12:43:14 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IKzU9-0003Jv-GO for sip@ietf.org; Tue, 14 Aug 2007 12:43:13 -0400 Received: from [65.65.155.30] (helo=[192.168.1.2]) by nylon.softarmor.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1IKzU8-0007Rp-Fl; Tue, 14 Aug 2007 11:43:12 -0500 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: sip List , "James M. Polk" From: Dean Willis Date: Tue, 14 Aug 2007 11:43:01 -0500 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Subject: [Sip] Questions on draft-polk-sip-rph-in-responses-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org The draft draft-polk-sip-rph-in-responses-00 allows UAS(es) to include resource priority headers in responses. I'm trying to figure out exactly what these headers really mean in responses. RFC 4412 explains what the RPH is used for in requests: 1. The request can be given elevated priority for access to PSTN gateway resources, such as trunk circuits. 2. The request can interrupt lower-priority requests at a user terminal, such as an IP phone. 3. The request can carry information from one multi-level priority domain in the telephone network (e.g., using the facilities of Q.735.3 [Q.735.3]) to another, without the SIP proxies themselves inspecting or modifying the header field. 4. In SIP proxies and back-to-back user agents, requests of higher priorities may displace existing signaling requests or bypass PSTN gateway capacity limits in effect for lower priorities. This all has to do with prioritizing the media channel that is being established by the request in-question. So what does it mean to have an RPH in a response? It doesn't seem that we're using the response to affect the priority of the media channel. Are we perhaps reporting the priority that was granted to the media channel on the assumption that the priority granted might differ from the priority requested? -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Aug 14 13:40:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IL0LZ-0001GL-UG; Tue, 14 Aug 2007 13:38:25 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IL0LY-0001GE-Ds for sip-confirm+ok@megatron.ietf.org; Tue, 14 Aug 2007 13:38:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IL0LY-0001G5-4O for sip@ietf.org; Tue, 14 Aug 2007 13:38:24 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IL0LW-0001PQ-UM for sip@ietf.org; Tue, 14 Aug 2007 13:38:24 -0400 Received: from dhcp89-089-119.bbn.com ([128.89.89.119] helo=[127.0.0.1]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1IL0LW-0000fx-4S for sip@ietf.org; Tue, 14 Aug 2007 13:38:22 -0400 Message-ID: <46C1E88E.3080207@bbn.com> Date: Tue, 14 Aug 2007 13:38:22 -0400 From: Matt Lepinski Organization: BBN User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip List Subject: Re: [Sip] Question on SIP Security considerations for future extensions References: <030FBE8B-B963-4EA1-A683-E4B25F538B19@softarmor.com> <46C0EFC0.7060509@cisco.com> <5143C6A2-FBFC-4CA1-8931-64AB346C24BC@cisco.com> <19E7C651-99BF-4D7E-B124-87E1A2284E81@softarmor.com> In-Reply-To: <19E7C651-99BF-4D7E-B124-87E1A2284E81@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org This is related to a point that someone [My apologies for not remember who] raised at the Chicago meeting: What problem will sipsec solve that existing (and not well deployed) security measures do not solve? Given that current transitive-trust models of security are well-deployed, my inclination is that it is important to provide guidence to on the strengths and weaknesses of transitive-trust models (in the hope that we can dissuade people from making false assumptions about the systems they are deploying). I'm less convinced that it's important to move forward with a brand new security measure, unless we have good reason to believe that it will be more effective than existing mechanisms. - Matt Lepinski :-> Dean Willis wrote: > > On Aug 14, 2007, at 12:02 AM, Cullen Jennings wrote: > >> >> I will note that we do have security mechanism to provide >> confidentially over the bodies (but not headers) for attacks from >> proxies we do not have a trust relationship with - and this is one >> of the aspects used in determining if certain semantics might be >> better in a body or header. >> > > And you've got working examples of this security mechanism in > deployed networks? > > -- > Dean > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Aug 14 14:16:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IL0u5-00023m-KV; Tue, 14 Aug 2007 14:14:05 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IL0u4-0001yh-3b for sip-confirm+ok@megatron.ietf.org; Tue, 14 Aug 2007 14:14:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IL0u3-0001yZ-PS for sip@ietf.org; Tue, 14 Aug 2007 14:14:03 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IL0u3-0005j2-9f for sip@ietf.org; Tue, 14 Aug 2007 14:14:03 -0400 Received: from [65.65.155.30] (helo=[192.168.1.2]) by nylon.softarmor.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1IL0u1-0007Zw-81; Tue, 14 Aug 2007 13:14:01 -0500 In-Reply-To: <46C1E264.5030607@bbn.com> References: <030FBE8B-B963-4EA1-A683-E4B25F538B19@softarmor.com> <46C0EFC0.7060509@cisco.com> <5143C6A2-FBFC-4CA1-8931-64AB346C24BC@cisco.com> <19E7C651-99BF-4D7E-B124-87E1A2284E81@softarmor.com> <46C1E264.5030607@bbn.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Question on SIP Security considerations for future extensions Date: Tue, 14 Aug 2007 13:13:47 -0500 To: Matt Lepinski X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: Cullen Jennings , sip List , Paul Kyzivat , Sandy Murphy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Aug 14, 2007, at 12:12 PM, Matt Lepinski wrote: > This is related to a point that someone [My apologies for not > remember who] raised at the Chicago meeting: > > What problem will sipsec solve that existing (and not well > deployed) security measures do not solve? The goal of SIPSEC is eliminating the requirement of transitive trust. We still have a reliance on request routing functionality to make the initial delivery of the CONNECT message, but after that the only attack that an intermediate proxy could launch would be to stop forwarding messages. This is much less insidious than subtly altering the contents of messages in order to delivery the appearance of normality when in fact an attack has been effected, or of disclosing sensitive elements of the messages to third parties so that attacks can be effected by those parties. While the documented-but-undeployed S/MIME approach appears to offer protection from proxies that subtly alter the bodies of messages, the protection for header-level alteration is weaker, and even in the best case a great deal of information potentially useful to attackers is visible to the proxies (and hence potentially compromised to attackers). SIPSEC appears to offer fairly complete integrity and privacy protection for all headers and body parts following the initial CONNECT message, and the initial CONNECT is designed to disclose as little sensitive information as possible. > Given that current transitive-trust models of security are well- > deployed, my inclination is that it is important to provide > guidance to on the strengths and weaknesses of transitive-trust > models (in the hope that we can dissuade people from making false > assumptions about the systems they are deploying). I'm less > convinced that it's important to move forward with a brand new > security measure, unless we have good reason to believe that it > will be more effective than existing mechanisms. > Yes, that's exactly the goal of the proposal that started this thread: to find a way to more completely describe the strengths and weaknesses of the current transitive trust models and then require new extensions to document how the extension interacts with those aspects of the operational environment. Whether we like the current operational environment or no, we still need to understand it very clearly, because it is real and we live in it today. More so, we need to clearly understand the security impacts of new extensions. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Aug 14 15:32:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IL26N-0005pj-He; Tue, 14 Aug 2007 15:30:51 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IL26M-0005pW-60 for sip-confirm+ok@megatron.ietf.org; Tue, 14 Aug 2007 15:30:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IL26L-0005pO-So for sip@ietf.org; Tue, 14 Aug 2007 15:30:49 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IL26K-0004Dz-LN for sip@ietf.org; Tue, 14 Aug 2007 15:30:49 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 14 Aug 2007 12:30:49 -0700 X-IronPort-AV: i="4.19,261,1183359600"; d="scan'208"; a="392206582:sNHT48612920" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l7EJUmpp016258; Tue, 14 Aug 2007 12:30:48 -0700 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-5.cisco.com (8.12.10/8.12.6) with SMTP id l7EJUgiG000018; Tue, 14 Aug 2007 19:30:46 GMT In-Reply-To: <46C1E264.5030607@bbn.com> References: <030FBE8B-B963-4EA1-A683-E4B25F538B19@softarmor.com> <46C0EFC0.7060509@cisco.com> <5143C6A2-FBFC-4CA1-8931-64AB346C24BC@cisco.com> <19E7C651-99BF-4D7E-B124-87E1A2284E81@softarmor.com> <46C1E264.5030607@bbn.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Question on SIP Security considerations for future extensions Date: Tue, 14 Aug 2007 12:29:25 -0700 To: Matt Lepinski X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1144; t=1187119848; x=1187983848; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[Sip]=20Question=20on=20SIP=20Security=20consideratio ns=20for=20future=09extensions |Sender:=20; bh=z+NNVXZn5BWdfox7kqwKQ0fYLXQgXHB/wfY780OEBCA=; b=VV4OLTqTJCUzKoTCYLtUHxS5/dQIjxPMRlum28UIrSeaPEmwHE2DY0u37DNGrLKUTqK+Ll0C E+eh6pu1+pxG211s0/q2x7jm9rZd9RIwf3m0oh8uAnn/EgMmCRYDZ0IuyXNMd00m+xowOPKJYx IzoJOka4/Dj7U776kDrd8Ehf8=; Authentication-Results: sj-dkim-1; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: sip List , Paul Kyzivat , Sandy Murphy , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Aug 14, 2007, at 10:12 AM, Matt Lepinski wrote: > This is related to a point that someone [My apologies for not > remember who] raised at the Chicago meeting: > > What problem will sipsec solve that existing (and not well > deployed) security measures do not solve? > > Given that current transitive-trust models of security are well- > deployed, my inclination is that it is important to provide > guidence to on the strengths and weaknesses of transitive-trust > models (in the hope that we can dissuade people from making false > assumptions about the systems they are deploying). I'm less > convinced that it's important to move forward with a brand new > security measure, unless we have good reason to believe that it > will be more effective than existing mechanisms. > > - Matt Lepinski :-> yes - that makes sense. The other thing that I think is important is considering sipsec is why is the proxy in the path in the first place? If the proxy does not need to see or change any of the headers why is the message traversing the proxy at all? 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 sip-bounces@ietf.org Tue Aug 14 17:16:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IL3iX-0002ce-E6; Tue, 14 Aug 2007 17:14:21 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IL3iV-0002Yo-TA for sip-confirm+ok@megatron.ietf.org; Tue, 14 Aug 2007 17:14:19 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IL3iV-0002Yg-CI for sip@ietf.org; Tue, 14 Aug 2007 17:14:19 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IL3iU-0001hv-Gk for sip@ietf.org; Tue, 14 Aug 2007 17:14:18 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id l7ELE1IR011833; Tue, 14 Aug 2007 16:14:01 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id l7ELE1a20737; Tue, 14 Aug 2007 16:14:01 -0500 (CDT) Message-ID: <46C21B19.8040507@alcatel-lucent.com> Date: Tue, 14 Aug 2007 16:14:01 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [Sip] Question on SIP Security considerations for future extensions References: <030FBE8B-B963-4EA1-A683-E4B25F538B19@softarmor.com> <46C0EFC0.7060509@cisco.com> <5143C6A2-FBFC-4CA1-8931-64AB346C24BC@cisco.com> <19E7C651-99BF-4D7E-B124-87E1A2284E81@softarmor.com> <46C1E264.5030607@bbn.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Cullen Jennings wrote: > The other thing that I think is important is considering sipsec is why > is the proxy in the path in the first place? If the proxy does not need > to see or change any of the headers why is the message traversing the > proxy at all? A couple of reasons: (a) routing across the normal SIP proxy mesh to reach the recipient (UAC may not know the specific network identifiers of the UAS), and (b) UAS may be behind a NAT/FW and not able to establish a direct communication with the UAC without a proxy. In private emails, Frank Miller has proposed an optimization to the proxy-routed sipsec model whereby the endpoints obtain a globally visible IP address (thru STUN or similar means) and then exchange signaling directly between them. We are currently debating this optimization among us before presenting it to a larger audience. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Aug 14 19:43:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IL60U-0001M9-PV; Tue, 14 Aug 2007 19:41:02 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IL60T-0001M4-Oq for sip-confirm+ok@megatron.ietf.org; Tue, 14 Aug 2007 19:41:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IL60T-0001Lv-FH for sip@ietf.org; Tue, 14 Aug 2007 19:41:01 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IL60S-0001kQ-72 for sip@ietf.org; Tue, 14 Aug 2007 19:41:01 -0400 Received: from [65.65.155.30] (helo=[192.168.1.2]) by nylon.softarmor.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1IL60R-0007vL-Cr; Tue, 14 Aug 2007 18:40:59 -0500 In-Reply-To: References: <030FBE8B-B963-4EA1-A683-E4B25F538B19@softarmor.com> <46C0EFC0.7060509@cisco.com> <5143C6A2-FBFC-4CA1-8931-64AB346C24BC@cisco.com> <19E7C651-99BF-4D7E-B124-87E1A2284E81@softarmor.com> <46C1E264.5030607@bbn.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8F8998A9-7EC4-4055-94D2-E364F5AC0C21@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: SIPSEC questions (Was Re: [Sip] Question on SIP Security considerations for future extensions) Date: Tue, 14 Aug 2007 18:40:48 -0500 To: Cullen Jennings X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Matt Lepinski , sip List , Paul Kyzivat , Sandy Murphy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Look, my question about security documentation for SIP extensions had nothing to do with SIPSEC and everything to do with documenting the current please-molest-me proxy-mediated transitive-faith-in-goodness I-believe-my-operator-cares-for-me model of SIP security. And we DO need to document this model better -- the question is how. So I'm changing the thread subject for further discussion on SIPSEC. On Aug 14, 2007, at 2:29 PM, Cullen Jennings wrote: > > The other thing that I think is important is considering sipsec is > why is the proxy in the path in the first place? If the proxy does > not need to see or change any of the headers why is the message > traversing the proxy at all? > see draft-ietf-sip-outbound. Outbound proxies do NOT really need to see or change any of the SIP headers. But they're very, very useful from a NAT traversal perspective. With SIPSEC, the outbound proxy sees CONNECT, routes it, then establishes a packet-forwarding channel. The UAs do keepalive on this channel. And everybody is happy and secure. Of course, we could probably have done the same thing with STUN relay, if we had a way to route STUN-relay requests or REGISTER contacts containing vectors of STUN relays. But we don't, yet. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Aug 15 02:03:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILBw2-0001aI-Ay; Wed, 15 Aug 2007 02:00:50 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1ILBvu-0001Vj-5O for sip-confirm+ok@megatron.ietf.org; Wed, 15 Aug 2007 02:00:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILBvt-0001VO-Nc for sip@ietf.org; Wed, 15 Aug 2007 02:00:41 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILBvt-0002dd-2p for sip@ietf.org; Wed, 15 Aug 2007 02:00:41 -0400 Received: from hkaplan [75.68.59.21] by acmepacket.com with ESMTP (SMTPD-9.10) id A68301D4; Wed, 15 Aug 2007 02:00:35 -0400 From: "Hadriel Kaplan" To: "'Dean Willis'" , "'Cullen Jennings'" References: <030FBE8B-B963-4EA1-A683-E4B25F538B19@softarmor.com> <46C0EFC0.7060509@cisco.com> <5143C6A2-FBFC-4CA1-8931-64AB346C24BC@cisco.com><19E7C651-99BF-4D7E-B124-87E1A2284E81@softarmor.com><46C1E264.5030607@bbn.com> <8F8998A9-7EC4-4055-94D2-E364F5AC0C21@softarmor.com> Subject: RE: SIPSEC questions (Was Re: [Sip] Question on SIP Securityconsiderations for future extensions) Date: Wed, 15 Aug 2007 02:00:02 -0400 Message-ID: <03e501c7df01$853087a0$800101df@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <8F8998A9-7EC4-4055-94D2-E364F5AC0C21@softarmor.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfezJxH21f24dhmQ3K1gADRxEnrCAAMbA1g X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: 'sip List' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I think Cullen was being facetious. Many of the hops along the path do not insert themselves purely to aid your UAC in finding the UAS. Otherwise they would mostly be stateless or redirect proxies. Obviously some do only that, but my guess is that's the exception not the rule. [flame retardant enabled] There are all forms of stateful proxies (and more) along the path between a UAC and UAS, and I seriously doubt their owners are interested in removing them from it. Ignoring all the things boxes do these days, even from a "security" perspective many of their owners see it in the complete reverse model - the endpoints are about the least secure thing they can imagine. No way are they letting John Doe's softphone-de-jour at wildwest.com exchange SIP directly with one of their SIP subscribers, pstn gateways, voicemail servers, etc. Seems to me that sort of thing is a fine argument/use for p2psip. -hadriel > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Tuesday, August 14, 2007 7:41 PM > To: Cullen Jennings > Cc: Matt Lepinski; sip List; Paul Kyzivat; Sandy Murphy > Subject: SIPSEC questions (Was Re: [Sip] Question on SIP > Securityconsiderations for future extensions) > > On Aug 14, 2007, at 2:29 PM, Cullen Jennings wrote: > > > > The other thing that I think is important is considering sipsec is > > why is the proxy in the path in the first place? If the proxy does > > not need to see or change any of the headers why is the message > > traversing the proxy at all? > > > > see draft-ietf-sip-outbound. > > Outbound proxies do NOT really need to see or change any of the SIP > headers. But they're very, very useful from a NAT traversal perspective. > > With SIPSEC, the outbound proxy sees CONNECT, routes it, then > establishes a packet-forwarding channel. The UAs do keepalive on this > channel. And everybody is happy and secure. > > Of course, we could probably have done the same thing with STUN > relay, if we had a way to route STUN-relay requests or REGISTER > contacts containing vectors of STUN relays. But we don't, yet. > > -- > Dean > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Aug 15 04:46:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILET9-0004o9-7Z; Wed, 15 Aug 2007 04:43:11 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IJyyB-0007Cb-It for sip-confirm+ok@megatron.ietf.org; Sat, 11 Aug 2007 17:58:03 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJyyB-0007CS-8L; Sat, 11 Aug 2007 17:58:03 -0400 Received: from mexforward.lss.emc.com ([128.222.32.20]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IJyyA-0001he-Ri; Sat, 11 Aug 2007 17:58:03 -0400 Received: from mailhub.lss.emc.com (nirah.lss.emc.com [10.254.144.13]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l7BLvmF2026576; Sat, 11 Aug 2007 17:57:48 -0400 (EDT) Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l7BLvjeV012406; Sat, 11 Aug 2007 17:57:46 -0400 (EDT) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.12]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 11 Aug 2007 17:57:45 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Sat, 11 Aug 2007 17:57:44 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Gen-ART review of draft-ietf-sip-ice-option-tag-02 Thread-Index: AcfcYqVOAAVM+AXARye7tYNCu7JXBw== To: , , X-OriginalArrivalTime: 11 Aug 2007 21:57:45.0692 (UTC) FILETIME=[A637A9C0:01C7DC62] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.7.6.21134 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -3, NO_REAL_NAME 0, __C230066_P5 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FRAUD_419_REFNUM 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d X-Mailman-Approved-At: Wed, 15 Aug 2007 04:43:10 -0400 Cc: fluffy@cisco.com, sip@ietf.org, drage@alcatel-lucent.com, Black_David@emc.com, dean.willis@softarmor.com Subject: [Sip] Gen-ART review of draft-ietf-sip-ice-option-tag-02 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jonathan, I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-sip-ice-option-tag-02 Reviewer: David Black Review Date: 11 August 2007 IETF LC End Date: 16 August 2007 Summary: This draft is ready for publication as a Proposed Standard RFC. Comments: This short draft defines a couple of SIP tags for ICE. It's in good shape. The only things I found are very minor: The "Unfortunately," word at the beginning of Section 3.1 should probably be removed. idnits 2.04.12 found an outdated reference: =3D=3D Outdated reference: A later version (-17) exists of draft-ietf-mmusic-ice-13 Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Aug 15 04:46:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILETO-0006ES-Rh; Wed, 15 Aug 2007 04:43:26 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IKzw7-0001Wo-6w for sip-confirm+ok@megatron.ietf.org; Tue, 14 Aug 2007 13:12:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKzw6-0001Wg-SP for sip@ietf.org; Tue, 14 Aug 2007 13:12:06 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IKzw6-0004FK-GQ for sip@ietf.org; Tue, 14 Aug 2007 13:12:06 -0400 Received: from dhcp89-089-119.bbn.com ([128.89.89.119] helo=[127.0.0.1]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1IKzw5-0000Fh-6L; Tue, 14 Aug 2007 13:12:06 -0400 Message-ID: <46C1E264.5030607@bbn.com> Date: Tue, 14 Aug 2007 13:12:04 -0400 From: Matt Lepinski Organization: BBN User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] Question on SIP Security considerations for future extensions References: <030FBE8B-B963-4EA1-A683-E4B25F538B19@softarmor.com> <46C0EFC0.7060509@cisco.com> <5143C6A2-FBFC-4CA1-8931-64AB346C24BC@cisco.com> <19E7C651-99BF-4D7E-B124-87E1A2284E81@softarmor.com> In-Reply-To: <19E7C651-99BF-4D7E-B124-87E1A2284E81@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 X-Mailman-Approved-At: Wed, 15 Aug 2007 04:43:25 -0400 Cc: Cullen Jennings , sip List , Paul Kyzivat , Sandy Murphy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org This is related to a point that someone [My apologies for not remember who] raised at the Chicago meeting: What problem will sipsec solve that existing (and not well deployed) security measures do not solve? Given that current transitive-trust models of security are well-deployed, my inclination is that it is important to provide guidence to on the strengths and weaknesses of transitive-trust models (in the hope that we can dissuade people from making false assumptions about the systems they are deploying). I'm less convinced that it's important to move forward with a brand new security measure, unless we have good reason to believe that it will be more effective than existing mechanisms. - Matt Lepinski :-> Dean Willis wrote: > > On Aug 14, 2007, at 12:02 AM, Cullen Jennings wrote: > >> >> I will note that we do have security mechanism to provide >> confidentially over the bodies (but not headers) for attacks from >> proxies we do not have a trust relationship with - and this is one >> of the aspects used in determining if certain semantics might be >> better in a body or header. >> > > And you've got working examples of this security mechanism in > deployed networks? > > -- > Dean > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Aug 15 10:40:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILK0c-00023T-9I; Wed, 15 Aug 2007 10:38:06 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1ILK0a-00023N-PP for sip-confirm+ok@megatron.ietf.org; Wed, 15 Aug 2007 10:38:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILK0a-00023F-Ek for sip@ietf.org; Wed, 15 Aug 2007 10:38:04 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ILK0Z-0004om-TN for sip@ietf.org; Wed, 15 Aug 2007 10:38:04 -0400 Received: from mail.bbn.com ([128.33.1.19]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1ILK0X-0005VN-3w; Wed, 15 Aug 2007 10:38:01 -0400 Received: from col-dhcp33-244-173.bbn.com ([128.33.244.173] helo=[127.0.0.1]) by mail.bbn.com with esmtp (Exim 4.67) (envelope-from ) id 1ILK0X-0001t7-57; Wed, 15 Aug 2007 10:38:01 -0400 Message-ID: <46C30FC5.7010704@bbn.com> Date: Wed, 15 Aug 2007 10:37:57 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] Question on SIP Security considerations for future extensions References: <030FBE8B-B963-4EA1-A683-E4B25F538B19@softarmor.com> In-Reply-To: <030FBE8B-B963-4EA1-A683-E4B25F538B19@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: sip List , Sandy Murphy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I'm replying to Dean's original message so that I'm not deep down in the thread, but I'd like to point to one of Dean's later comments: > Look, my question about security documentation for SIP extensions had > nothing to do with SIPSEC and everything to do with documenting the > current please-molest-me proxy-mediated transitive-faith-in-goodness > I-believe-my-operator-cares-for-me model of SIP security. And we DO > need to document this model better -- the question is how. Here's my proposal: First, we need to document the situation as it stands, given the proxy model and security mechanisms defined in RFC 3261 and relevant extensions. I.e., in the current system, here's the base (please-molest-me) model, here's what proxies can do to screw you up in this model, and here's the sorts of assurances you can get by employing some security features. Second, rather than requiring boilerplate in documents defining new extensions, they should comment on how the extension affects the model described in the above document -- either providing additional security (e.g., by limiting proxy capabilities like SIPSEC) or by introducing additional risks (e.g., by increasing proxy capabilities, like answer-mode). This discussion could be a required subsection of the Security Considerations section. I think that this would encourage people to give explicit consideration to the sorts of risks Sandy noted in the answer-mode draft, and to think about how they might fix or avoid them. --Richard Dean Willis wrote: > > I'm having quite an interesting conversation with Sandy Murphy (cc'd) > who was tasked by sec-dir to review one of our drafts > (draft-ietf-sip-answermode). This draft has some rather interesting > security issues, since if implemented incorrectly and then abused it > could allow an attacker to "bug your phone" -- that is, turn it into a > remote listening device. Similar attacks could also be used to run up > the victim's connectivity bill, run down the device's battery, aggravate > the "voice hammer" DOS attack, and so on. > > This lead us into a discussion of the SIP security model in general. > Most SIP practitioners who have been at it for awhile know that if the > proxies we have decided to trust suddenly decide to get malicious, then > we're very much at their mercy. They can do all sorts of things, > including routing our media through interceptors, mangling SDP payloads, > injecting (or blocking) instant messages, altering presence information, > and so on. > > But this aspect of SIP is not obvious to naive implementors, or even to > less naive security types. > > Maybe every SIP extension document should include a boiler-plate > reminder about the sensitivity of proxies, then go on to enumerate and > describe the new ways that malicious proxies (should there be such a > thing) can wreak havoc using the extension being documented. > > what do you folks think? > > 1) Could a reasonable "How you could be violated by trusted proxies that > turn rogue" boilerplate be drafted? > 2) Would the practice of repeating this in drafts help or hurt us? > 3) Would it be useful for us to document how each extension could be > used by a rogue proxy? > > -- > Dean > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Aug 15 10:59:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILKJg-0007QQ-3S; Wed, 15 Aug 2007 10:57:48 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1ILKJf-0007QD-Av for sip-confirm+ok@megatron.ietf.org; Wed, 15 Aug 2007 10:57:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILKJf-0007Q0-17 for sip@ietf.org; Wed, 15 Aug 2007 10:57:47 -0400 Received: from smapp00.siteprotect.com ([64.41.126.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILKJd-0007df-L8 for sip@ietf.org; Wed, 15 Aug 2007 10:57:46 -0400 Received: from localhost.localdomain (localhost [127.0.0.1]) by smapp00.siteprotect.com (Postfix) with ESMTP id 058EB2E8014; Wed, 15 Aug 2007 09:39:37 -0500 (CDT) MIME-Version: 1.0 From: "fwmiller@cornfed.com" To: Dean Willis , Richard Barnes Subject: Re: [Sip] Question on SIP Security considerations for future extensions Date: Wed, 15 Aug 2007 09:39:37 -0500 Message-Id: <9857.1187188777@cornfed.com> X-Mailer: AtMail 6.0 - 205.175.225.28 - fwmiller@cornfed.com X-Spam-Score: 1.7 (+) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Cc: sip List , Sandy Murphy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: fwmiller@cornfed.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0806427973==" Errors-To: sip-bounces@ietf.org --===============0806427973== Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="iso-8859-1"

 

With all due respect, I don't agree with this.  Its my opinion that= the current model is well-understood and unsatifactory for many applicatio= ns.  While I think its fine to spend some time clarifying the current = model, I don't think that should hold up the development of an end-to-end m= echanism as well.  That development can proceed in parallel and the si= psec draft is a good start in that direction.

To that end, after receiving the blessing of the majority of the authors= , I'm posting a proposal I made to them regarding a mod to the sipsec draft= that I believe would improve its ability to address true end-to-end securi= ty.

The idea is simple, rather than having the CONNECT message establish a "= tunnel" through a series of proxies, CONNECT is used to trade addressing in= formation between the UAs that then signal each other directly.  This = proposal was made as modifications to the sipsec draft.  The draft is = available as a standalone and as a diff to the current sipsec draft at the = following links.  Comments are hoped for...

Thanks,

FM

https://svn.resiprocate.org/rep/ietf-drafts/gurbani/sip-= sipsec/sipsec-fmiller/


http://too= ls.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=3Dhttp://svn.resiprocate.org/re= p/ietf-drafts/gurbani/sip-sipsec/draft-gurbani-sip-sipsec-01.txt&url2= =3Dhttp://svn.resiprocate.org/rep/ietf-drafts/gurbani/sip-sipsec/sipsec-fmi= ller/draft-gurbani-sip-sipsec-fmiller-00.txt

 




On Wed Aug 15 9:37 , Richard Barnes sent:

I'm replying to Dean'= s original message so that I'm not deep down in the
thread, but I'd like to point to one of Dean's later comments:

> Look, my question about security documentation for SIP extensions had<= BR> > nothing to do with SIPSEC and everything to do with documenting the
> current please-molest-me proxy-mediated transitive-faith-in-goodness > I-believe-my-operator-cares-for-me model of SIP security. And we DO
> need to document this model better -- the question is how.

Here's my proposal:

First, we need to document the situation as it stands, given the proxy
model and security mechanisms defined in RFC 3261 and relevant
extensions. I.e., in the current system, here's the base
(please-molest-me) model, here's what proxies can do to screw you up in
this model, and here's the sorts of assurances you can get by employing
some security features.

Second, rather than requiring boilerplate in documents defining new
extensions, they should comment on how the extension affects the model
described in the above document -- either providing additional security
(e.g., by limiting proxy capabilities like SIPSEC) or by introducing
additional risks (e.g., by increasing proxy capabilities, like
answer-mode). This discussion could be a required subsection of the
Security Considerations section.

I think that this would encourage people to give explicit consideration
to the sorts of risks Sandy noted in the answer-mode draft, and to think about how they might fix or avoid them.

--Richard







Dean Willis wrote:
>
> I'm having quite an interesting convers= ation with Sandy Murphy (cc'd)
> who was tasked by sec-dir to review one= of our drafts
> (draft-ietf-sip-answermode). This draft= has some rather interesting
> security issues, since if implemented i= ncorrectly and then abused it
> could allow an attacker to "bug your ph= one" -- that is, turn it into a
> remote listening device. Similar attack= s could also be used to run up
> the victim's connectivity bill, run dow= n the device's battery, aggravate
> the "voice hammer" DOS attack, and so o= n.
>
> This lead us into a discussion of the S= IP security model in general.
> Most SIP practitioners who have been at= it for awhile know that if the
> proxies we have decided to trust sudden= ly decide to get malicious, then
> we're very much at their mercy. They ca= n do all sorts of things,
> including routing our media through int= erceptors, mangling SDP payloads,
> injecting (or blocking) instant message= s, altering presence information,
> and so on.
>
> But this aspect of SIP is not obvious t= o naive implementors, or even to
> less naive security types.
>
> Maybe every SIP extension document shou= ld include a boiler-plate
> reminder about the sensitivity of proxi= es, then go on to enumerate and
> describe the new ways that malicious pr= oxies (should there be such a
> thing) can wreak havoc using the extens= ion being documented.
>
> what do you folks think?
>
> 1) Could a reasonable "How you could be= violated by trusted proxies that
> turn rogue" boilerplate be drafted?
> 2) Would the practice of repeating this= in drafts help or hurt us?
> 3) Would it be useful for us to documen= t how each extension could be
> used by a rogue proxy?
>
> --
> 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.columb= ia.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 sip= ping@ietf.org for new developments on the application of sip

= --===============0806427973== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0806427973==-- From sip-bounces@ietf.org Wed Aug 15 11:32:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILKpl-00070b-Vp; Wed, 15 Aug 2007 11:30:57 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1ILKpk-0006zx-Ek for sip-confirm+ok@megatron.ietf.org; Wed, 15 Aug 2007 11:30:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILKpk-0006zp-4x for sip@ietf.org; Wed, 15 Aug 2007 11:30:56 -0400 Received: from exprod6og50.obsmtp.com ([64.18.1.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILKph-0000Hf-Pi for sip@ietf.org; Wed, 15 Aug 2007 11:30:55 -0400 Received: from source ([192.150.20.142]) by exprod6ob50.postini.com ([64.18.5.12]) with SMTP; Wed, 15 Aug 2007 08:30:19 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l7FFUHWs001309; Wed, 15 Aug 2007 08:30:17 -0700 (PDT) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l7FFUA0e027083; Wed, 15 Aug 2007 08:30:12 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Aug 2007 08:30:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] Question on SIP Security considerations forfuture extensions Date: Wed, 15 Aug 2007 08:30:05 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22C6B3F3@namail5.corp.adobe.com> In-Reply-To: <9857.1187188777@cornfed.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Question on SIP Security considerations forfuture extensions Thread-Index: AcffTKmtZp5wgwQXQZqFzWm3PtEJeQABDbqw References: <9857.1187188777@cornfed.com> From: "Henry Sinnreich" To: , "Dean Willis" , "Richard Barnes" X-OriginalArrivalTime: 15 Aug 2007 15:30:10.0708 (UTC) FILETIME=[2AD1B540:01C7DF51] X-Spam-Score: -4.0 (----) X-Scan-Signature: 47f87af9e1d92eac54caf69b67f82b72 Cc: sip List , Sandy Murphy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1883582266==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1883582266== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7DF51.2A1BB1A1" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7DF51.2A1BB1A1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I fully agree here. Only e2e security is real security and SIPS cannot obfuscate this. =20 Thanks, Henry =20 ________________________________ From: fwmiller@cornfed.com [mailto:fwmiller@cornfed.com]=20 Sent: Wednesday, August 15, 2007 9:40 AM To: Dean Willis; Richard Barnes Cc: sip List; Sandy Murphy Subject: Re: [Sip] Question on SIP Security considerations forfuture extensions =20 =20 With all due respect, I don't agree with this. Its my opinion that the current model is well-understood and unsatifactory for many applications. While I think its fine to spend some time clarifying the current model, I don't think that should hold up the development of an end-to-end mechanism as well. That development can proceed in parallel and the sipsec draft is a good start in that direction. To that end, after receiving the blessing of the majority of the authors, I'm posting a proposal I made to them regarding a mod to the sipsec draft that I believe would improve its ability to address true end-to-end security. The idea is simple, rather than having the CONNECT message establish a "tunnel" through a series of proxies, CONNECT is used to trade addressing information between the UAs that then signal each other directly. This proposal was made as modifications to the sipsec draft. The draft is available as a standalone and as a diff to the current sipsec draft at the following links. Comments are hoped for... Thanks, FM https://svn.resiprocate.org/rep/ietf-drafts/gurbani/sip-sipsec/sipsec-fm iller/ http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=3Dhttp://svn.resipr= o cate.org/rep/ietf-drafts/gurbani/sip-sipsec/draft-gurbani-sip-sipsec-01. txt&url2=3Dhttp://svn.resiprocate.org/rep/ietf-drafts/gurbani/sip-sipsec/= s ipsec-fmiller/draft-gurbani-sip-sipsec-fmiller-00.txt =20 On Wed Aug 15 9:37 , Richard Barnes sent: I'm replying to Dean's original message so that I'm not deep down in the=20 thread, but I'd like to point to one of Dean's later comments: =09 > Look, my question about security documentation for SIP extensions had > nothing to do with SIPSEC and everything to do with documenting the > current please-molest-me proxy-mediated transitive-faith-in-goodness > I-believe-my-operator-cares-for-me model of SIP security. And we DO > need to document this model better -- the question is how. =09 Here's my proposal: =09 First, we need to document the situation as it stands, given the proxy=20 model and security mechanisms defined in RFC 3261 and relevant=20 extensions. I.e., in the current system, here's the base=20 (please-molest-me) model, here's what proxies can do to screw you up in=20 this model, and here's the sorts of assurances you can get by employing=20 some security features. =09 Second, rather than requiring boilerplate in documents defining new=20 extensions, they should comment on how the extension affects the model=20 described in the above document -- either providing additional security=20 (e.g., by limiting proxy capabilities like SIPSEC) or by introducing=20 additional risks (e.g., by increasing proxy capabilities, like=20 answer-mode). This discussion could be a required subsection of the=20 Security Considerations section. =09 I think that this would encourage people to give explicit consideration=20 to the sorts of risks Sandy noted in the answer-mode draft, and to think=20 about how they might fix or avoid them. =09 --Richard =09 =09 =09 =09 =09 =09 =09 Dean Willis wrote: >=20 > I'm having quite an interesting conversation with Sandy Murphy (cc'd)=20 > who was tasked by sec-dir to review one of our drafts=20 > (draft-ietf-sip-answermode). This draft has some rather interesting=20 > security issues, since if implemented incorrectly and then abused it=20 > could allow an attacker to "bug your phone" -- that is, turn it into a=20 > remote listening device. Similar attacks could also be used to run up=20 > the victim's connectivity bill, run down the device's battery, aggravate=20 > the "voice hammer" DOS attack, and so on. >=20 > This lead us into a discussion of the SIP security model in general.=20 > Most SIP practitioners who have been at it for awhile know that if the=20 > proxies we have decided to trust suddenly decide to get malicious, then=20 > we're very much at their mercy. They can do all sorts of things,=20 > including routing our media through interceptors, mangling SDP payloads,=20 > injecting (or blocking) instant messages, altering presence information,=20 > and so on. >=20 > But this aspect of SIP is not obvious to naive implementors, or even to=20 > less naive security types. >=20 > Maybe every SIP extension document should include a boiler-plate=20 > reminder about the sensitivity of proxies, then go on to enumerate and=20 > describe the new ways that malicious proxies (should there be such a=20 > thing) can wreak havoc using the extension being documented. >=20 > what do you folks think? >=20 > 1) Could a reasonable "How you could be violated by trusted proxies that=20 > turn rogue" boilerplate be drafted? > 2) Would the practice of repeating this in drafts help or hurt us? > 3) Would it be useful for us to document how each extension could be=20 > used by a rogue proxy? >=20 > --=20 > Dean >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip =20 > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 >=20 =09 =09 =09 =09 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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_01C7DF51.2A1BB1A1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I fully agree here. Only e2e = security is real security and SIPS cannot obfuscate = this.

 

Thanks, = Henry

 

From: = fwmiller@cornfed.com [mailto:fwmiller@cornfed.com]
Sent: Wednesday, August = 15, 2007 9:40 AM
To: Dean Willis; Richard = Barnes
Cc: sip List; Sandy = Murphy
Subject: Re: [Sip] = Question on SIP Security considerations forfuture = extensions

 

 

With all due respect, I don't agree with this.  Its my opinion that the = current model is well-understood and unsatifactory for many applications.  = While I think its fine to spend some time clarifying the current model, I don't = think that should hold up the development of an end-to-end mechanism as = well.  That development can proceed in parallel and the sipsec draft is a good = start in that direction.

To that end, after receiving the blessing of the majority of the authors, I'm = posting a proposal I made to them regarding a mod to the sipsec draft that I = believe would improve its ability to address true end-to-end = security.

The idea is simple, rather than having the CONNECT message establish a "tunnel" through a series of proxies, CONNECT is used to trade addressing information between the UAs that then signal each other directly.  This proposal was made as modifications to the sipsec draft.  The draft is available as a standalone and as a diff to the current sipsec draft at the following links.  Comments are hoped = for...

Thanks,

FM

https://svn.resiprocate.org/rep/ietf-drafts/gurbani/sip-si= psec/sipsec-fmiller/


http:= //tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=3Dhttp://svn.resiprocate= .org/rep/ietf-drafts/gurbani/sip-sipsec/draft-gurbani-sip-sipsec-01.txt&a= mp;url2=3Dhttp://svn.resiprocate.org/rep/ietf-drafts/gurbani/sip-sipsec/s= ipsec-fmiller/draft-gurbani-sip-sipsec-fmiller-00.txt

 




On Wed Aug 15 9:37 , Richard Barnes = sent:

I'm replying to Dean's original message so that I'm not deep = down in the
thread, but I'd like to point to one of Dean's later comments:

> Look, my question about security documentation for SIP extensions = had
> nothing to do with SIPSEC and everything to do with documenting = the
> current please-molest-me proxy-mediated = transitive-faith-in-goodness
> I-believe-my-operator-cares-for-me model of SIP security. And we = DO
> need to document this model better -- the question is how.

Here's my proposal:

First, we need to document the situation as it stands, given the proxy =
model and security mechanisms defined in RFC 3261 and relevant
extensions. I.e., in the current system, here's the base
(please-molest-me) model, here's what proxies can do to screw you up in =
this model, and here's the sorts of assurances you can get by employing =
some security features.

Second, rather than requiring boilerplate in documents defining new
extensions, they should comment on how the extension affects the model =
described in the above document -- either providing additional security =
(e.g., by limiting proxy capabilities like SIPSEC) or by introducing =
additional risks (e.g., by increasing proxy capabilities, like
answer-mode). This discussion could be a required subsection of the
Security Considerations section.

I think that this would encourage people to give explicit consideration =
to the sorts of risks Sandy noted in the answer-mode draft, and to think
about how they might fix or avoid them.

--Richard







Dean Willis wrote:
>
> I'm having quite an = interesting conversation with Sandy Murphy (cc'd)
> who was tasked by = sec-dir to review one of our drafts
> = (draft-ietf-sip-answermode). This draft has some rather interesting
> security issues, since = if implemented incorrectly and then abused it
> could allow an attacker = to "bug your phone" -- that is, turn it into a
> remote listening = device. Similar attacks could also be used to run up
> the victim's = connectivity bill, run down the device's battery, aggravate
> the "voice = hammer" DOS attack, and so on.
>
> This lead us into a = discussion of the SIP security model in general.
> Most SIP practitioners = who have been at it for awhile know that if the
> proxies we have decided = to trust suddenly decide to get malicious, then
> we're very much at = their mercy. They can do all sorts of things,
> including routing our = media through interceptors, mangling SDP payloads,
> injecting (or blocking) = instant messages, altering presence information,
> and so = on.
>
> But this aspect of SIP = is not obvious to naive implementors, or even to
> less naive security = types.
>
> Maybe every SIP = extension document should include a boiler-plate
> reminder about the = sensitivity of proxies, then go on to enumerate and
> describe the new ways = that malicious proxies (should there be such a
> thing) can wreak havoc = using the extension being documented.
>
> what do you folks = think?
>
> 1) Could a reasonable = "How you could be violated by trusted proxies that
> turn rogue" = boilerplate be drafted?
> 2) Would the practice = of repeating this in drafts help or hurt us?
> 3) Would it be useful = for us to document how each extension could be
> used by a rogue = proxy?
>
> --
> 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


------_=_NextPart_001_01C7DF51.2A1BB1A1-- --===============1883582266== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1883582266==-- From sip-bounces@ietf.org Wed Aug 15 12:20:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILLZp-0008MN-E8; Wed, 15 Aug 2007 12:18:33 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1ILLZn-0008MG-V7 for sip-confirm+ok@megatron.ietf.org; Wed, 15 Aug 2007 12:18:31 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILLZn-0008M6-F6 for sip@ietf.org; Wed, 15 Aug 2007 12:18:31 -0400 Received: from smtp3.versatel.nl ([62.58.50.90]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ILLZl-0008BH-4f for sip@ietf.org; Wed, 15 Aug 2007 12:18:31 -0400 Received: (qmail 27129 invoked by uid 0); 15 Aug 2007 16:18:05 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER) ([87.212.11.198]) (envelope-sender ) by smtp3.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 15 Aug 2007 16:18:05 -0000 Message-ID: <003601c7df57$e5e24ab0$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: References: <9857.1187188777@cornfed.com> Subject: SIPSEC comments (Was Re: [Sip] Question on SIP Security considerations forfuture extensions) Date: Wed, 15 Aug 2007 18:18:21 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7191030d885084e634ab0f488bcd9d53 Cc: sip List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1215803181==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1215803181== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0032_01C7DF68.A9403A20" This is a multi-part message in MIME format. ------=_NextPart_000_0032_01C7DF68.A9403A20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Frank, Some comments on the draft you refer to below: 1 - why insert (Proxy-)Require: sipsec? it will not work through currently deployed proxies, while section 6.6 does not require any new proxy behavior. Perhaps because 6.3 requires proxies to process mutulated responses, but 2 - why make the CONNECT response different than a normal SIP response? doing that makes it incompatible with current infrastructure, while providing little benefit 3 - section 6.5 UAS behavior should probably say that a Contact MUST be present in CONNECT response, and that it SHOULD be sips: 4 - would be nice to have a mechanism to encrypt the Contact URI in the response, specifically for the caller. An incoming request to a contact that was sent encrypted gives higher trust. At least it should be integrity protected somehow. 5 - would it be beneficial to make a link to the sip-certs work (http://www.ietf.org/internet-drafts/draft-ietf-sip-certs-04.txt)? For example, in the CONNECT method the caller could provide a reference to its certificate server (integrity-protected as part of the body for example) 6 - 6.3 should state that CONNECT is not a dialog creating request. Consequently, 6.5 should state that UAS MUST ignore any Record-Route headers present (and so not reflect them in the CONNECT response, although this might interfere with proxy functionality - but that's kind of the point, right?) 7 - You could consider providing guidance on information that is not relevant to the CONNECT request, but needed to make requests / responses well formed. For example, you could specify default values for To and From URIs (say anonymous@domain.invalid) 8 - Given that the Contact URIs need to be globally reachable (I guess how that is achieved should remain out of scope), they should be marked as (temporary?) GRUUs (i.e. include 'gr=xxx') Regards, Jeroen ----- Original Message ----- From: fwmiller@cornfed.com To: Dean Willis ; Richard Barnes Cc: sip List ; Sandy Murphy Sent: Wednesday, August 15, 2007 4:39 PM Subject: Re: [Sip] Question on SIP Security considerations forfuture extensions With all due respect, I don't agree with this. Its my opinion that the current model is well-understood and unsatifactory for many applications. While I think its fine to spend some time clarifying the current model, I don't think that should hold up the development of an end-to-end mechanism as well. That development can proceed in parallel and the sipsec draft is a good start in that direction. To that end, after receiving the blessing of the majority of the authors, I'm posting a proposal I made to them regarding a mod to the sipsec draft that I believe would improve its ability to address true end-to-end security. The idea is simple, rather than having the CONNECT message establish a "tunnel" through a series of proxies, CONNECT is used to trade addressing information between the UAs that then signal each other directly. This proposal was made as modifications to the sipsec draft. The draft is available as a standalone and as a diff to the current sipsec draft at the following links. Comments are hoped for... Thanks, FM https://svn.resiprocate.org/rep/ietf-drafts/gurbani/sip-sipsec/sipsec-fmiller/ http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=http://svn.resiprocate.org/rep/ietf-drafts/gurbani/sip-sipsec/draft-gurbani-sip-sipsec-01.txt&url2=http://svn.resiprocate.org/rep/ietf-drafts/gurbani/sip-sipsec/sipsec-fmiller/draft-gurbani-sip-sipsec-fmiller-00.txt On Wed Aug 15 9:37 , Richard Barnes sent: I'm replying to Dean's original message so that I'm not deep down in the thread, but I'd like to point to one of Dean's later comments: > Look, my question about security documentation for SIP extensions had > nothing to do with SIPSEC and everything to do with documenting the > current please-molest-me proxy-mediated transitive-faith-in-goodness > I-believe-my-operator-cares-for-me model of SIP security. And we DO > need to document this model better -- the question is how. Here's my proposal: First, we need to document the situation as it stands, given the proxy model and security mechanisms defined in RFC 3261 and relevant extensions. I.e., in the current system, here's the base (please-molest-me) model, here's what proxies can do to screw you up in this model, and here's the sorts of assurances you can get by employing some security features. Second, rather than requiring boilerplate in documents defining new extensions, they should comment on how the extension affects the model described in the above document -- either providing additional security (e.g., by limiting proxy capabilities like SIPSEC) or by introducing additional risks (e.g., by increasing proxy capabilities, like answer-mode). This discussion could be a required subsection of the Security Considerations section. I think that this would encourage people to give explicit consideration to the sorts of risks Sandy noted in the answer-mode draft, and to think about how they might fix or avoid them. --Richard Dean Willis wrote: > > I'm having quite an interesting conversation with Sandy Murphy (cc'd) > who was tasked by sec-dir to review one of our drafts > (draft-ietf-sip-answermode). This draft has some rather interesting > security issues, since if implemented incorrectly and then abused it > could allow an attacker to "bug your phone" -- that is, turn it into a > remote listening device. Similar attacks could also be used to run up > the victim's connectivity bill, run down the device's battery, aggravate > the "voice hammer" DOS attack, and so on. > > This lead us into a discussion of the SIP security model in general. > Most SIP practitioners who have been at it for awhile know that if the > proxies we have decided to trust suddenly decide to get malicious, then > we're very much at their mercy. They can do all sorts of things, > including routing our media through interceptors, mangling SDP payloads, > injecting (or blocking) instant messages, altering presence information, > and so on. > > But this aspect of SIP is not obvious to naive implementors, or even to > less naive security types. > > Maybe every SIP extension document should include a boiler-plate > reminder about the sensitivity of proxies, then go on to enumerate and > describe the new ways that malicious proxies (should there be such a > thing) can wreak havoc using the extension being documented. > > what do you folks think? > > 1) Could a reasonable "How you could be violated by trusted proxies that > turn rogue" boilerplate be drafted? > 2) Would the practice of repeating this in drafts help or hurt us? > 3) Would it be useful for us to document how each extension could be > used by a rogue proxy? > > -- > 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 ------=_NextPart_000_0032_01C7DF68.A9403A20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Frank,
 
Some comments on the draft you refer to = below:
 
1 - why insert (Proxy-)Require: sipsec? = it will not=20 work through currently deployed proxies, while section 6.6 does not = require any=20 new proxy behavior. Perhaps because 6.3 requires proxies to process = mutulated responses, but
 
2 - why make the CONNECT response = different than a=20 normal SIP response? doing that makes it incompatible with current=20 infrastructure, while providing little benefit
 
3 - section 6.5 UAS behavior should = probably say=20 that a Contact MUST be present in CONNECT response, and that it SHOULD = be=20 sips:
4 - would be nice to have a mechanism = to encrypt=20 the Contact URI in the response, specifically for the caller. An = incoming=20 request to a contact that was sent encrypted gives higher trust. At = least it=20 should be integrity protected somehow.
5 - would it be beneficial to make a = link to the=20 sip-certs work (= http://www.ietf.org/internet-drafts/draft-ietf-sip-certs-04.txt)?=20 For example, in the CONNECT method the caller could provide a reference = to its=20 certificate server (integrity-protected as part of the body for=20 example)
 
6 - 6.3 should state that CONNECT is = not a dialog=20 creating request. Consequently, 6.5 should state that UAS MUST ignore = any=20 Record-Route headers present (and so not reflect them in the CONNECT = response,=20 although this might interfere with proxy functionality - but that's kind = of the=20 point, right?)
 
7 - You could consider providing = guidance on=20 information that is not relevant to the CONNECT request, but needed to = make=20 requests / responses well formed. For example, you could specify default = values=20 for To and From URIs (say anonymous@domain.invalid)
 
8 - Given that the Contact URIs need to = be globally=20 reachable (I guess how that is achieved should remain out of scope), = they should=20 be marked as (temporary?) GRUUs (i.e. include 'gr=3Dxxx')
 
Regards,
Jeroen
 
----- Original Message -----
From:=20 fwmiller@cornfed.com
To: Dean Willis ; Richard = Barnes
Sent: Wednesday, August 15, = 2007 4:39=20 PM
Subject: Re: [Sip] Question on = SIP=20 Security considerations forfuture extensions

 

With all due respect, I don't agree with this.  Its my opinion = that=20 the current model is well-understood and unsatifactory for many=20 applications.  While I think its fine to spend some time = clarifying the=20 current model, I don't think that should hold up the development of an = end-to-end mechanism as well.  That development can proceed in = parallel=20 and the sipsec draft is a good start in that direction.

To that end, after receiving the blessing of the majority of the = authors,=20 I'm posting a proposal I made to them regarding a mod to the sipsec = draft that=20 I believe would improve its ability to address true end-to-end = security.

The idea is simple, rather than having the CONNECT message = establish a=20 "tunnel" through a series of proxies, CONNECT is used to trade = addressing=20 information between the UAs that then signal each other = directly.  This=20 proposal was made as modifications to the sipsec draft.  The = draft is=20 available as a standalone and as a diff to the current sipsec draft at = the=20 following links.  Comments are hoped for...

Thanks,

FM

https://svn.resiprocate.org/rep/ietf-drafts/gurbani/sip-si= psec/sipsec-fmiller/


http:= //tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=3Dhttp://svn.resiprocate= .org/rep/ietf-drafts/gurbani/sip-sipsec/draft-gurbani-sip-sipsec-01.txt&a= mp;url2=3Dhttp://svn.resiprocate.org/rep/ietf-drafts/gurbani/sip-sipsec/s= ipsec-fmiller/draft-gurbani-sip-sipsec-fmiller-00.txt

 




On Wed Aug 15 9:37 , Richard Barnes=20 sent:

I'm=20 replying to Dean's original message so that I'm not deep down in the =
thread, but I'd like to point to one of Dean's later=20 comments:

> Look, my question about security documentation = for SIP=20 extensions had
> nothing to do with SIPSEC and everything to = do with=20 documenting the
> current please-molest-me proxy-mediated=20 transitive-faith-in-goodness
> = I-believe-my-operator-cares-for-me=20 model of SIP security. And we DO
> need to document this model = better=20 -- the question is how.

Here's my proposal:

First, we = need to=20 document the situation as it stands, given the proxy
model and = security=20 mechanisms defined in RFC 3261 and relevant
extensions. I.e., in = the=20 current system, here's the base
(please-molest-me) model, here's = what=20 proxies can do to screw you up in
this model, and here's the = sorts of=20 assurances you can get by employing
some security=20 features.

Second, rather than requiring boilerplate in = documents=20 defining new
extensions, they should comment on how the = extension=20 affects the model
described in the above document -- either = providing=20 additional security
(e.g., by limiting proxy capabilities like = SIPSEC)=20 or by introducing
additional risks (e.g., by increasing proxy=20 capabilities, like
answer-mode). This discussion could be a = required=20 subsection of the
Security Considerations section.

I = think that=20 this would encourage people to give explicit consideration
to = the sorts=20 of risks Sandy noted in the answer-mode draft, and to think =
about how=20 they might fix or avoid=20 them.

--Richard







Dean Willis=20 wrote:
>
> I'm having quite an interesting = conversation=20 with Sandy Murphy (cc'd)
> who=20 was tasked by sec-dir to review one of our drafts
> (draft-ietf-sip-answermode). This = draft has some=20 rather interesting
> = security=20 issues, since if implemented incorrectly and then abused it =
> could allow an attacker to "bug your = phone" --=20 that is, turn it into a
> remote=20 listening device. Similar attacks could also be used to run up=20
> the victim's = connectivity bill,=20 run down the device's battery, aggravate
> the "voice hammer" DOS attack, and so=20 on.
>
> This lead us into a discussion of the = SIP=20 security model in general.
> Most=20 SIP practitioners who have been at it for awhile know that if the=20
> proxies we have = decided to=20 trust suddenly decide to get malicious, then
> we're very much at their mercy. They = can do all=20 sorts of things,
> = including=20 routing our media through interceptors, mangling SDP payloads,=20
> injecting (or = blocking) instant=20 messages, altering presence information,
> and so on.
>
> But=20 this aspect of SIP is not obvious to naive implementors, or even to=20
> less naive security=20 types.
> =
> Maybe every SIP extension document = should=20 include a boiler-plate
> reminder=20 about the sensitivity of proxies, then go on to enumerate and=20
> describe the new ways = that=20 malicious proxies (should there be such a
> thing) can wreak havoc using the = extension being=20 documented.
> =
> what do you folks = think?
>
> 1)=20 Could a reasonable "How you could be violated by trusted proxies = that=20
> turn rogue" = boilerplate be=20 drafted?
> 2) Would the = practice=20 of repeating this in drafts help or hurt us?
> 3) Would it be useful for us to = document how=20 each extension could be
> used by=20 a rogue proxy?
> =
> --
>=20 Dean
>
>
>=20
>=20 _______________________________________________
> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
= > This list is for NEW development of = the core SIP=20 Protocol
> Use sip-implementors@cs.columbia.edu=20 for questions on current sip
> Use=20 sipping@= ietf.org=20 for new developments on the application of sip
>
>=20 =




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

_______________________________________________
Sip mailing=20 list  https://www1.ietf.org/mailman/listinfo/sip
This list is = for NEW=20 development of the core SIP Protocol
Use = sip-implementors@cs.columbia.edu=20 for questions on current sip
Use sipping@ietf.org for new = developments on=20 the application of sip ------=_NextPart_000_0032_01C7DF68.A9403A20-- --===============1215803181== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1215803181==-- From sip-bounces@ietf.org Wed Aug 15 13:22:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILMYF-0002oP-Ve; Wed, 15 Aug 2007 13:20:59 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1ILMYE-0002oH-Kd for sip-confirm+ok@megatron.ietf.org; Wed, 15 Aug 2007 13:20:58 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILMYE-0002o9-8Y for sip@ietf.org; Wed, 15 Aug 2007 13:20:58 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ILMYC-0001cj-Fb for sip@ietf.org; Wed, 15 Aug 2007 13:20:58 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l7FHKi218717; Wed, 15 Aug 2007 17:20:44 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] Question on SIP Security considerations forfuture extensions Date: Wed, 15 Aug 2007 12:20:24 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF11A5C215@zrc2hxm0.corp.nortel.com> In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D22C6B3F3@namail5.corp.adobe.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Question on SIP Security considerations forfuture extensions Thread-Index: AcffTKmtZp5wgwQXQZqFzWm3PtEJeQABDbqwAAOkmnA= References: <9857.1187188777@cornfed.com> <24CCCC428EFEA2469BF046DB3C7A8D22C6B3F3@namail5.corp.adobe.com> From: "Francois Audet" To: "Henry Sinnreich" , , "Dean Willis" , "Richard Barnes" X-Spam-Score: 0.0 (/) X-Scan-Signature: a83e8b750067501be8b56bf02fb6582d Cc: sip List , Sandy Murphy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1294847489==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1294847489== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7DF60.9196C77C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7DF60.9196C77C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Actually, that is false in many cases. =20 It depends what you are trying to do, and who do you trust.=20 =20 There are many cases where I'd put a lot more trust in the proxies than "the guys at the end of the lines".=20 =20 Who has the responsibility for Security is really what should drive the solution. =20 An e2e model makes a lot of sense when the people that are engaged in the session are the ones with the incentive for the session to be secure. If Henry wants to talk to me, and we both want our session to be secure, then that's the right model. =20 An e2e model does not make any sense when the people that are engaged in the session don't care or are not savvy enough. For example, if I'm an Enteprise IT manager (or operator of a Government internal network), I may decide that I want all sessions between all my users to be secure despite them. As the IT manager, I'd be responsible if a rogue employee spies on collegue, regardless of how careless the other employees are. =20 I think it is important to be very clear on what we are trying to achieve when talking about e2e (sipsec) or hop-by-hop (sips). They are not meant to solve the same problem.=20 ________________________________ From: Henry Sinnreich [mailto:hsinnrei@adobe.com]=20 Sent: Wednesday, August 15, 2007 08:30 To: fwmiller@cornfed.com; Dean Willis; Richard Barnes Cc: sip List; Sandy Murphy Subject: RE: [Sip] Question on SIP Security considerations forfuture extensions =09 =09 I fully agree here. Only e2e security is real security and SIPS cannot obfuscate this. =20 Thanks, Henry =20 =09 ________________________________ From: fwmiller@cornfed.com [mailto:fwmiller@cornfed.com]=20 Sent: Wednesday, August 15, 2007 9:40 AM To: Dean Willis; Richard Barnes Cc: sip List; Sandy Murphy Subject: Re: [Sip] Question on SIP Security considerations forfuture extensions =20 =20 With all due respect, I don't agree with this. Its my opinion that the current model is well-understood and unsatifactory for many applications. While I think its fine to spend some time clarifying the current model, I don't think that should hold up the development of an end-to-end mechanism as well. That development can proceed in parallel and the sipsec draft is a good start in that direction. To that end, after receiving the blessing of the majority of the authors, I'm posting a proposal I made to them regarding a mod to the sipsec draft that I believe would improve its ability to address true end-to-end security. The idea is simple, rather than having the CONNECT message establish a "tunnel" through a series of proxies, CONNECT is used to trade addressing information between the UAs that then signal each other directly. This proposal was made as modifications to the sipsec draft. The draft is available as a standalone and as a diff to the current sipsec draft at the following links. Comments are hoped for... Thanks, FM =09 https://svn.resiprocate.org/rep/ietf-drafts/gurbani/sip-sipsec/sipsec-fm iller/ =09 =09 http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=3Dhttp://svn.resipr= o cate.org/rep/ietf-drafts/gurbani/sip-sipsec/draft-gurbani-sip-sipsec-01. txt&url2=3Dhttp://svn.resiprocate.org/rep/ietf-drafts/gurbani/sip-sipsec/= s ipsec-fmiller/draft-gurbani-sip-sipsec-fmiller-00.txt =20 =09 =09 =09 On Wed Aug 15 9:37 , Richard Barnes sent: I'm replying to Dean's original message so that I'm not deep down in the=20 thread, but I'd like to point to one of Dean's later comments: =09 > Look, my question about security documentation for SIP extensions had > nothing to do with SIPSEC and everything to do with documenting the > current please-molest-me proxy-mediated transitive-faith-in-goodness > I-believe-my-operator-cares-for-me model of SIP security. And we DO > need to document this model better -- the question is how. =09 Here's my proposal: =09 First, we need to document the situation as it stands, given the proxy=20 model and security mechanisms defined in RFC 3261 and relevant=20 extensions. I.e., in the current system, here's the base (please-molest-me) model, here's what proxies can do to screw you up in=20 this model, and here's the sorts of assurances you can get by employing=20 some security features. =09 Second, rather than requiring boilerplate in documents defining new=20 extensions, they should comment on how the extension affects the model=20 described in the above document -- either providing additional security=20 (e.g., by limiting proxy capabilities like SIPSEC) or by introducing=20 additional risks (e.g., by increasing proxy capabilities, like=20 answer-mode). This discussion could be a required subsection of the=20 Security Considerations section. =09 I think that this would encourage people to give explicit consideration=20 to the sorts of risks Sandy noted in the answer-mode draft, and to think=20 about how they might fix or avoid them. =09 --Richard =09 =09 =09 =09 =09 =09 =09 Dean Willis wrote: >=20 > I'm having quite an interesting conversation with Sandy Murphy (cc'd)=20 > who was tasked by sec-dir to review one of our drafts=20 > (draft-ietf-sip-answermode). This draft has some rather interesting=20 > security issues, since if implemented incorrectly and then abused it=20 > could allow an attacker to "bug your phone" -- that is, turn it into a=20 > remote listening device. Similar attacks could also be used to run up=20 > the victim's connectivity bill, run down the device's battery, aggravate=20 > the "voice hammer" DOS attack, and so on. >=20 > This lead us into a discussion of the SIP security model in general.=20 > Most SIP practitioners who have been at it for awhile know that if the=20 > proxies we have decided to trust suddenly decide to get malicious, then=20 > we're very much at their mercy. They can do all sorts of things,=20 > including routing our media through interceptors, mangling SDP payloads,=20 > injecting (or blocking) instant messages, altering presence information,=20 > and so on. >=20 > But this aspect of SIP is not obvious to naive implementors, or even to=20 > less naive security types. >=20 > Maybe every SIP extension document should include a boiler-plate=20 > reminder about the sensitivity of proxies, then go on to enumerate and=20 > describe the new ways that malicious proxies (should there be such a=20 > thing) can wreak havoc using the extension being documented. >=20 > what do you folks think? >=20 > 1) Could a reasonable "How you could be violated by trusted proxies that=20 > turn rogue" boilerplate be drafted? > 2) Would the practice of repeating this in drafts help or hurt us? > 3) Would it be useful for us to document how each extension could be=20 > used by a rogue proxy? >=20 > --=20 > Dean >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip =20 > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 >=20 =09 =09 =09 =09 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol 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_01C7DF60.9196C77C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Actually, that is false in many cases.
 
It=20 depends what you are trying to do, and who do you trust. =
 
There=20 are many cases where I'd put a lot more trust in the proxies than "the = guys at=20 the end of the lines".
 
Who=20 has the responsibility for Security is really what should drive the=20 solution.
 
An e2e=20 model makes a lot of sense when the people that are engaged in the = session are=20 the ones with the incentive for the session to be secure. If Henry wants = to talk=20 to me, and we both want our session to be secure, then that's the right=20 model.
 
An e2e=20 model does not make any sense when the people that are engaged in the = session=20 don't care or are not savvy enough. For example, if I'm an = Enteprise IT=20 manager (or operator of a Government internal network), I may decide = that I want=20 all sessions between all my users to be secure despite them. As the IT = manager,=20 I'd be responsible if a rogue employee spies on collegue, regardless of = how=20 careless the other employees are.
 
I=20 think it is important to be very clear on what we are trying to achieve = when=20 talking about e2e (sipsec) or hop-by-hop (sips). They are not meant to = solve the=20 same problem.

From: Henry Sinnreich=20 [mailto:hsinnrei@adobe.com]
Sent: Wednesday, August 15, = 2007=20 08:30
To: fwmiller@cornfed.com; Dean Willis; Richard=20 Barnes
Cc: sip List; Sandy Murphy
Subject: RE: = [Sip]=20 Question on SIP Security considerations forfuture=20 extensions

I fully = agree here.=20 Only e2e security is real security and SIPS cannot obfuscate=20 this.

 

Thanks,=20 Henry

 

From:=20 fwmiller@cornfed.com [mailto:fwmiller@cornfed.com]
Sent: Wednesday, August 15, = 2007 9:40=20 AM
To: Dean Willis; = Richard=20 Barnes
Cc: sip = List; Sandy=20 Murphy
Subject: Re: = [Sip]=20 Question on SIP Security considerations forfuture=20 extensions

 

 

With all=20 due respect, I don't agree with this.  Its my opinion that the = current=20 model is well-understood and unsatifactory for many = applications.  While=20 I think its fine to spend some time clarifying the current model, I = don't=20 think that should hold up the development of an end-to-end mechanism = as=20 well.  That development can proceed in parallel and the sipsec = draft is a=20 good start in that direction.

To that=20 end, after receiving the blessing of the majority of the authors, I'm = posting=20 a proposal I made to them regarding a mod to the sipsec draft that I = believe=20 would improve its ability to address true end-to-end=20 security.

The idea=20 is simple, rather than having the CONNECT message establish a "tunnel" = through=20 a series of proxies, CONNECT is used to trade addressing information = between=20 the UAs that then signal each other directly.  This proposal was = made as=20 modifications to the sipsec draft.  The draft is available as a=20 standalone and as a diff to the current sipsec draft at the following=20 links.  Comments are hoped for...

Thanks,

FM

https://svn.resiprocate.org/rep/ietf-drafts/gurbani/sip-si= psec/sipsec-fmiller/


http:= //tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=3Dhttp://svn.resiprocate= .org/rep/ietf-drafts/gurbani/sip-sipsec/draft-gurbani-sip-sipsec-01.txt&a= mp;url2=3Dhttp://svn.resiprocate.org/rep/ietf-drafts/gurbani/sip-sipsec/s= ipsec-fmiller/draft-gurbani-sip-sipsec-fmiller-00.txt

 




On Wed=20 Aug 15 9:37 , Richard Barnes=20 sent:

I'm replying to Dean's original message so = that I'm=20 not deep down in the
thread, but I'd like to point to one of = Dean's=20 later comments:

> Look, my question about security = documentation=20 for SIP extensions had
> nothing to do with SIPSEC and = everything to=20 do with documenting the
> current please-molest-me = proxy-mediated=20 transitive-faith-in-goodness
> = I-believe-my-operator-cares-for-me=20 model of SIP security. And we DO
> need to document this model = better=20 -- the question is how.

Here's my proposal:

First, we = need to=20 document the situation as it stands, given the proxy
model and = security=20 mechanisms defined in RFC 3261 and relevant
extensions. I.e., in = the=20 current system, here's the base
(please-molest-me) model, here's = what=20 proxies can do to screw you up in
this model, and here's the = sorts of=20 assurances you can get by employing
some security=20 features.

Second, rather than requiring boilerplate in = documents=20 defining new
extensions, they should comment on how the = extension=20 affects the model
described in the above document -- either = providing=20 additional security
(e.g., by limiting proxy capabilities like = SIPSEC)=20 or by introducing
additional risks (e.g., by increasing proxy=20 capabilities, like
answer-mode). This discussion could be a = required=20 subsection of the
Security Considerations section.

I = think that=20 this would encourage people to give explicit consideration
to = the sorts=20 of risks Sandy noted in the answer-mode = draft, and=20 to think
about how they might fix or avoid=20 them.

--Richard







Dean Willis=20 wrote:
>=20
> = I'm having=20 quite an interesting conversation with Sandy Murphy (cc'd)=20
> = who was=20 tasked by sec-dir to review one of our drafts =
> = (draft-ietf-sip-answermode). This=20 draft has some rather interesting
> security issues, since if implemented = incorrectly=20 and then abused it
> could allow an attacker to "bug your = phone" -- that=20 is, turn it into a
> remote listening device. Similar attacks = could also=20 be used to run up
> the victim's connectivity bill, run down = the=20 device's battery, aggravate
> the "voice hammer" DOS attack, and so=20 on.
>=20
> = This lead us=20 into a discussion of the SIP security model in general.=20
> = Most SIP=20 practitioners who have been at it for awhile know that if the=20
> = proxies we=20 have decided to trust suddenly decide to get malicious, then=20
> = we're very=20 much at their mercy. They can do all sorts of things,=20
> = including=20 routing our media through interceptors, mangling SDP payloads,=20
> = injecting=20 (or blocking) instant messages, altering presence information,=20
> = and so=20 on.
>=20
> = But this=20 aspect of SIP is not obvious to naive implementors, or even to=20
> = less naive=20 security types.
>
> Maybe every SIP extension document should = include a=20 boiler-plate
>=20 reminder about the sensitivity of proxies, then go on to enumerate = and=20
> = describe the=20 new ways that malicious proxies (should there be such a=20
> = thing) can=20 wreak havoc using the extension being = documented.
>
> what do you folks=20 think?
>=20
> = 1) Could a=20 reasonable "How you could be violated by trusted proxies that=20
> = turn rogue"=20 boilerplate be drafted?
> 2) Would the practice of repeating this in = drafts=20 help or hurt us?
> 3) Would it be useful for us to document = how each=20 extension could be
> used by a rogue = proxy?
>
> -- =
> = Dean
>
>
>
>=20 = _______________________________________________
> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip<= /FONT>
> This list is for NEW = development of=20 the core SIP Protocol
> Use sip-implementors@cs.columbia.edu=20 for questions on current sip
> Use sipping@= ietf.org=20 for new developments on the application of = sip
>
>=20 =




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


------_=_NextPart_001_01C7DF60.9196C77C-- --===============1294847489== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1294847489==-- From sip-bounces@ietf.org Wed Aug 15 13:25:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILMaS-0005En-3u; Wed, 15 Aug 2007 13:23:16 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1ILMaR-0005Ei-3G for sip-confirm+ok@megatron.ietf.org; Wed, 15 Aug 2007 13:23:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILMaQ-0005EX-Pj for sip@ietf.org; Wed, 15 Aug 2007 13:23:14 -0400 Received: from smtp3.versatel.nl ([62.58.50.90]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILMaP-0003Qo-68 for sip@ietf.org; Wed, 15 Aug 2007 13:23:14 -0400 Received: (qmail 7084 invoked by uid 0); 15 Aug 2007 17:22:49 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER) ([87.212.11.198]) (envelope-sender ) by smtp3.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 15 Aug 2007 17:22:49 -0000 Message-ID: <001701c7df60$f113ce50$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: References: <9857.1187188777@cornfed.com> <003601c7df57$e5e24ab0$0601a8c0@BEMBUSTER> Subject: Re: SIPSEC comments (Was Re: [Sip] Question on SIP Securityconsiderations forfuture extensions) Date: Wed, 15 Aug 2007 19:23:05 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: sip List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0581326828==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0581326828== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0013_01C7DF71.B45C39F0" This is a multi-part message in MIME format. ------=_NextPart_000_0013_01C7DF71.B45C39F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Frank, Elaborating on: 4 - would be nice to have a mechanism to encrypt the Contact URI in the response, specifically for the caller. An incoming request to a contact that was sent encrypted gives higher trust. At least it should be integrity protected somehow. Suppose the UAS would include a new header "Secure-Contact" containing a contact URI encrypted using a key that the caller passed in its CONNECT request. That would provide: - a means for the UAC to check the integrity of the contact - a means for the UAS to verify that the caller is the same as the party that CONNECTed before (i.e. by including some unique bits in the contact URI) - a way to avoid B2BUA elements blocking CONNECT by not forwarding the UAS Contact header Furthermore, the draft could talk about how the UAS could specify a different machine than itself, for example a proxy with which it maintains an outbound connection. This could be a different proxy than the one through which the CONNECT came in. It could also be a proxy with which the UAS maintains a non-SIP connection (say a VPN/IPSec connection). Such a proxy might not be able to present a certificate on behalf of the UAS, but at least it would provide a mechanism to side step the SIP proxy infrastructure Regards, Jeroen ------=_NextPart_000_0013_01C7DF71.B45C39F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Frank,
 
Elaborating on:
 
4 - would be nice to have a mechanism = to encrypt=20 the Contact URI in the response, specifically for the caller. An = incoming=20 request to a contact that was sent encrypted gives higher trust. At = least it=20 should be integrity protected somehow.
 
Suppose the UAS would include a new = header=20 "Secure-Contact" containing a contact URI encrypted using a key that the = caller=20 passed in its CONNECT request. That would provide:
- a means for the UAC to check the = integrity of the=20 contact
- a means for the UAS to verify that = the caller is=20 the same as the party that CONNECTed before (i.e. by including some = unique bits=20 in the contact URI)
- a way to avoid B2BUA elements = blocking CONNECT by=20 not forwarding the UAS Contact header
 
 
Furthermore, the draft could talk about = how the UAS=20 could specify a different machine than itself, for example a proxy with = which it=20 maintains an outbound connection. This could be a different proxy than = the one=20 through which the CONNECT came in. It could also be a proxy with = which the=20 UAS maintains a non-SIP connection (say a VPN/IPSec connection). = Such a proxy might not be able to present a = certificate on=20 behalf of the UAS, but at least it would provide a mechanism to side = step the=20 SIP proxy infrastructure
 
Regards,
Jeroen
------=_NextPart_000_0013_01C7DF71.B45C39F0-- --===============0581326828== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0581326828==-- From sip-bounces@ietf.org Wed Aug 15 13:28:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILMds-0008AF-W0; Wed, 15 Aug 2007 13:26:48 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1ILMdr-0008A8-7l for sip-confirm+ok@megatron.ietf.org; Wed, 15 Aug 2007 13:26:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILMdo-00089U-5r for sip@ietf.org; Wed, 15 Aug 2007 13:26:44 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILMdm-0003WI-Kx for sip@ietf.org; Wed, 15 Aug 2007 13:26:44 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l7FHQRQ01083; Wed, 15 Aug 2007 17:26:27 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] Question on SIP Security considerations for future extensions Date: Wed, 15 Aug 2007 12:26:25 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF11A5C22D@zrc2hxm0.corp.nortel.com> In-Reply-To: <9857.1187188777@cornfed.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Question on SIP Security considerations for future extensions Thread-Index: AcffTKsLXpgqlP1fRF67rHQkWUNi/QAFAATw References: <9857.1187188777@cornfed.com> From: "Francois Audet" To: , "Dean Willis" , "Richard Barnes" X-Spam-Score: 0.0 (/) X-Scan-Signature: 5df1f98f3253c63b673ea560243aa58f Cc: sip List , Sandy Murphy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0422471135==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0422471135== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7DF61.68E4BD36" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7DF61.68E4BD36 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I view this as an "optimization" of the original draft. =20 The real question is "Are there cases where the original draft would work, but not Frank's draft". At first glance, one may say, "yes, with symmetric NATs for example". But in this case, media wouldn't work either (unless you have a TURN server). If you have that luxyry, then it may be better. However, there are cases like IM that only use a signalling channel where the first draft would be simpler. =20 My gut feel is that we should try to use Frank's optimization when possible (i.e., when plain STUN works), and then decide if we keep the existing mechanism (tunnelling through proxies or use a seperate TURN server) later. =20 Interestingly enough, this is quite analogous to the ICE vs. "hole-punching" debate of a few weeks ago. ________________________________ From: fwmiller@cornfed.com [mailto:fwmiller@cornfed.com]=20 Sent: Wednesday, August 15, 2007 07:40 To: Dean Willis; Richard Barnes Cc: sip List; Sandy Murphy Subject: Re: [Sip] Question on SIP Security considerations for future extensions =09 =09 =20 With all due respect, I don't agree with this. Its my opinion that the current model is well-understood and unsatifactory for many applications. While I think its fine to spend some time clarifying the current model, I don't think that should hold up the development of an end-to-end mechanism as well. That development can proceed in parallel and the sipsec draft is a good start in that direction. To that end, after receiving the blessing of the majority of the authors, I'm posting a proposal I made to them regarding a mod to the sipsec draft that I believe would improve its ability to address true end-to-end security. The idea is simple, rather than having the CONNECT message establish a "tunnel" through a series of proxies, CONNECT is used to trade addressing information between the UAs that then signal each other directly. This proposal was made as modifications to the sipsec draft. The draft is available as a standalone and as a diff to the current sipsec draft at the following links. Comments are hoped for... Thanks, FM =09 https://svn.resiprocate.org/rep/ietf-drafts/gurbani/sip-sipsec/sipsec-fm iller/ =09 =09 http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=3Dhttp://svn.resipr= o cate.org/rep/ietf-drafts/gurbani/sip-sipsec/draft-gurbani-sip-sipsec-01. txt&url2=3Dhttp://svn.resiprocate.org/rep/ietf-drafts/gurbani/sip-sipsec/= s ipsec-fmiller/draft-gurbani-sip-sipsec-fmiller-00.txt =20 =09 =09 =09 On Wed Aug 15 9:37 , Richard Barnes sent: =09 =09 I'm replying to Dean's original message so that I'm not deep down in the=20 thread, but I'd like to point to one of Dean's later comments: =09 > Look, my question about security documentation for SIP extensions had > nothing to do with SIPSEC and everything to do with documenting the > current please-molest-me proxy-mediated transitive-faith-in-goodness > I-believe-my-operator-cares-for-me model of SIP security. And we DO > need to document this model better -- the question is how. =09 Here's my proposal: =09 First, we need to document the situation as it stands, given the proxy=20 model and security mechanisms defined in RFC 3261 and relevant=20 extensions. I.e., in the current system, here's the base (please-molest-me) model, here's what proxies can do to screw you up in=20 this model, and here's the sorts of assurances you can get by employing=20 some security features. =09 Second, rather than requiring boilerplate in documents defining new=20 extensions, they should comment on how the extension affects the model=20 described in the above document -- either providing additional security=20 (e.g., by limiting proxy capabilities like SIPSEC) or by introducing=20 additional risks (e.g., by increasing proxy capabilities, like=20 answer-mode). This discussion could be a required subsection of the=20 Security Considerations section. =09 I think that this would encourage people to give explicit consideration=20 to the sorts of risks Sandy noted in the answer-mode draft, and to think=20 about how they might fix or avoid them. =09 --Richard =09 =09 =09 =09 =09 =09 =09 Dean Willis wrote: >=20 > I'm having quite an interesting conversation with Sandy Murphy (cc'd)=20 > who was tasked by sec-dir to review one of our drafts=20 > (draft-ietf-sip-answermode). This draft has some rather interesting=20 > security issues, since if implemented incorrectly and then abused it=20 > could allow an attacker to "bug your phone" -- that is, turn it into a=20 > remote listening device. Similar attacks could also be used to run up=20 > the victim's connectivity bill, run down the device's battery, aggravate=20 > the "voice hammer" DOS attack, and so on. >=20 > This lead us into a discussion of the SIP security model in general.=20 > Most SIP practitioners who have been at it for awhile know that if the=20 > proxies we have decided to trust suddenly decide to get malicious, then=20 > we're very much at their mercy. They can do all sorts of things,=20 > including routing our media through interceptors, mangling SDP payloads,=20 > injecting (or blocking) instant messages, altering presence information,=20 > and so on. >=20 > But this aspect of SIP is not obvious to naive implementors, or even to=20 > less naive security types. >=20 > Maybe every SIP extension document should include a boiler-plate=20 > reminder about the sensitivity of proxies, then go on to enumerate and=20 > describe the new ways that malicious proxies (should there be such a=20 > thing) can wreak havoc using the extension being documented. >=20 > what do you folks think? >=20 > 1) Could a reasonable "How you could be violated by trusted proxies that=20 > turn rogue" boilerplate be drafted? > 2) Would the practice of repeating this in drafts help or hurt us? > 3) Would it be useful for us to document how each extension could be=20 > used by a rogue proxy? >=20 > --=20 > Dean >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip =20 > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 >=20 =09 =09 =09 =09 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip =09 ------_=_NextPart_001_01C7DF61.68E4BD36 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I view=20 this as an "optimization" of the original draft.
 
The=20 real question is "Are there cases where the original draft would work, = but not=20 Frank's draft". At first glance, one may say, "yes, with symmetric NATs = for=20 example". But in this case, media wouldn't work either (unless you have = a TURN=20 server). If you have that luxyry, then it may be better. However, there = are=20 cases like IM that only use a signalling channel where the first draft = would be=20 simpler.
 
My gut=20 feel is that we should try to use Frank's optimization when possible = (i.e., when=20 plain STUN works), and then decide if we keep the existing mechanism = (tunnelling=20 through proxies or use a seperate TURN server) = later.
 
Interestingly enough, this is quite analogous to the ICE vs.=20 "hole-punching" debate of a few weeks ago.

From: fwmiller@cornfed.com=20 [mailto:fwmiller@cornfed.com]
Sent: Wednesday, August 15, = 2007=20 07:40
To: Dean Willis; Richard Barnes
Cc: sip = List; Sandy=20 Murphy
Subject: Re: [Sip] Question on SIP Security = considerations=20 for future extensions

 

With all due respect, I don't agree with this.  Its my opinion = that=20 the current model is well-understood and unsatifactory for many=20 applications.  While I think its fine to spend some time = clarifying the=20 current model, I don't think that should hold up the development of an = end-to-end mechanism as well.  That development can proceed in = parallel=20 and the sipsec draft is a good start in that direction.

To that end, after receiving the blessing of the majority of the = authors,=20 I'm posting a proposal I made to them regarding a mod to the sipsec = draft that=20 I believe would improve its ability to address true end-to-end = security.

The idea is simple, rather than having the CONNECT message = establish a=20 "tunnel" through a series of proxies, CONNECT is used to trade = addressing=20 information between the UAs that then signal each other = directly.  This=20 proposal was made as modifications to the sipsec draft.  The = draft is=20 available as a standalone and as a diff to the current sipsec draft at = the=20 following links.  Comments are hoped for...

Thanks,

FM

https://svn.resiprocate.org/rep/ietf-drafts/gurbani/sip-si= psec/sipsec-fmiller/


http:= //tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=3Dhttp://svn.resiprocate= .org/rep/ietf-drafts/gurbani/sip-sipsec/draft-gurbani-sip-sipsec-01.txt&a= mp;url2=3Dhttp://svn.resiprocate.org/rep/ietf-drafts/gurbani/sip-sipsec/s= ipsec-fmiller/draft-gurbani-sip-sipsec-fmiller-00.txt

 




On Wed Aug 15 9:37 , Richard Barnes=20 sent:

I'm=20 replying to Dean's original message so that I'm not deep down in the =
thread, but I'd like to point to one of Dean's later=20 comments:

> Look, my question about security documentation = for SIP=20 extensions had
> nothing to do with SIPSEC and everything to = do with=20 documenting the
> current please-molest-me proxy-mediated=20 transitive-faith-in-goodness
> = I-believe-my-operator-cares-for-me=20 model of SIP security. And we DO
> need to document this model = better=20 -- the question is how.

Here's my proposal:

First, we = need to=20 document the situation as it stands, given the proxy
model and = security=20 mechanisms defined in RFC 3261 and relevant
extensions. I.e., in = the=20 current system, here's the base
(please-molest-me) model, here's = what=20 proxies can do to screw you up in
this model, and here's the = sorts of=20 assurances you can get by employing
some security=20 features.

Second, rather than requiring boilerplate in = documents=20 defining new
extensions, they should comment on how the = extension=20 affects the model
described in the above document -- either = providing=20 additional security
(e.g., by limiting proxy capabilities like = SIPSEC)=20 or by introducing
additional risks (e.g., by increasing proxy=20 capabilities, like
answer-mode). This discussion could be a = required=20 subsection of the
Security Considerations section.

I = think that=20 this would encourage people to give explicit consideration
to = the sorts=20 of risks Sandy noted in the answer-mode draft, and to think =
about how=20 they might fix or avoid=20 them.

--Richard







Dean Willis=20 wrote:
>
> I'm having quite an interesting = conversation=20 with Sandy Murphy (cc'd)
> who=20 was tasked by sec-dir to review one of our drafts
> (draft-ietf-sip-answermode). This = draft has some=20 rather interesting
> = security=20 issues, since if implemented incorrectly and then abused it =
> could allow an attacker to "bug your = phone" --=20 that is, turn it into a
> remote=20 listening device. Similar attacks could also be used to run up=20
> the victim's = connectivity bill,=20 run down the device's battery, aggravate
> the "voice hammer" DOS attack, and so=20 on.
>
> This lead us into a discussion of the = SIP=20 security model in general.
> Most=20 SIP practitioners who have been at it for awhile know that if the=20
> proxies we have = decided to=20 trust suddenly decide to get malicious, then
> we're very much at their mercy. They = can do all=20 sorts of things,
> = including=20 routing our media through interceptors, mangling SDP payloads,=20
> injecting (or = blocking) instant=20 messages, altering presence information,
> and so on.
>
> But=20 this aspect of SIP is not obvious to naive implementors, or even to=20
> less naive security=20 types.
> =
> Maybe every SIP extension document = should=20 include a boiler-plate
> reminder=20 about the sensitivity of proxies, then go on to enumerate and=20
> describe the new ways = that=20 malicious proxies (should there be such a
> thing) can wreak havoc using the = extension being=20 documented.
> =
> what do you folks = think?
>
> 1)=20 Could a reasonable "How you could be violated by trusted proxies = that=20
> turn rogue" = boilerplate be=20 drafted?
> 2) Would the = practice=20 of repeating this in drafts help or hurt us?
> 3) Would it be useful for us to = document how=20 each extension could be
> used by=20 a rogue proxy?
> =
> --
>=20 Dean
>
>
>=20
>=20 _______________________________________________
> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
= > This list is for NEW development of = the core SIP=20 Protocol
> Use sip-implementors@cs.columbia.edu=20 for questions on current sip
> Use=20 sipping@= ietf.org=20 for new developments on the application of sip
>
>=20 =




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

------_=_NextPart_001_01C7DF61.68E4BD36-- --===============0422471135== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0422471135==-- From sip-bounces@ietf.org Wed Aug 15 19:02:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILRqx-0007VF-VP; Wed, 15 Aug 2007 19:00:39 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1ILRqw-0007V9-F0 for sip-confirm+ok@megatron.ietf.org; Wed, 15 Aug 2007 19:00:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILRqw-0007V1-4z for sip@ietf.org; Wed, 15 Aug 2007 19:00:38 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILRqv-0005IV-Ap for sip@ietf.org; Wed, 15 Aug 2007 19:00:38 -0400 Received: from hkaplan [10.0.200.241] by acmepacket.com with ESMTP (SMTPD-9.10) id A58802FC; Wed, 15 Aug 2007 19:00:24 -0400 From: "Hadriel Kaplan" To: , "'Dean Willis'" , "'Richard Barnes'" References: <9857.1187188777@cornfed.com> Subject: RE: [Sip] Question on SIP Security considerations forfuture extensions Date: Wed, 15 Aug 2007 19:00:24 -0400 Message-ID: <056701c7df90$1050bd80$800101df@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <9857.1187188777@cornfed.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcffTKfaPyOBs6TKQZeBgh/e6k/muAAPU9rQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Cc: 'sip List' , 'Sandy Murphy' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Comment on the draft: I think you should specify exactly what the automated validity check of = the certificate is. AFAIK, it is rare for a user PC to have a cert with any useful identity signed by a well-known cert authority, and that=92s a = big roadblock for this thing. One thing you could do is use a similar trick = to what zrtp used, such as to have the application on each side present the user with a shortened string form of the fingerprint, for them to read = out to each other if they feel paranoid. At least that way self-signed certs could be useful in some cases. (won=92t work for IM though) =20 -hadriel ________________________________________ From: fwmiller@cornfed.com [mailto:fwmiller@cornfed.com]=20 Sent: Wednesday, August 15, 2007 10:40 AM To: Dean Willis; Richard Barnes Cc: sip List; Sandy Murphy Subject: Re: [Sip] Question on SIP Security considerations forfuture extensions =A0 With all due respect, I don't agree with this.=A0 Its my opinion that = the current model is well-understood and unsatifactory for many = applications.=A0 While I think its fine to spend some time clarifying the current model, = I don't think that should hold up the development of an end-to-end = mechanism as well.=A0 That development can proceed in parallel and the sipsec = draft is a good start in that direction. To that end, after receiving the blessing of the majority of the = authors, I'm posting a proposal I made to them regarding a mod to the sipsec = draft that I believe would improve its ability to address true end-to-end security. The idea is simple, rather than having the CONNECT message establish a "tunnel" through a series of proxies, CONNECT is used to trade = addressing information between the UAs that then signal each other directly.=A0 = This proposal was made as modifications to the sipsec draft.=A0 The draft is available as a standalone and as a diff to the current sipsec draft at = the following links.=A0 Comments are hoped for... Thanks, FM https://svn.resiprocate.org/rep/ietf-drafts/gurbani/sip-sipsec/sipsec-fmi= lle r/ http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=3Dhttp://svn.resipr= ocate .org/rep/ietf-drafts/gurbani/sip-sipsec/draft-gurbani-sip-sipsec-01.txt&u= rl2 =3Dhttp://svn.resiprocate.org/rep/ietf-drafts/gurbani/sip-sipsec/sipsec-f= mille r/draft-gurbani-sip-sipsec-fmiller-00.txt =A0 On Wed Aug 15 9:37 , Richard Barnes sent: I'm replying to Dean's original message so that I'm not deep down in the = thread, but I'd like to point to one of Dean's later comments: > Look, my question about security documentation for SIP extensions had > nothing to do with SIPSEC and everything to do with documenting the > current please-molest-me proxy-mediated transitive-faith-in-goodness > I-believe-my-operator-cares-for-me model of SIP security. And we DO > need to document this model better -- the question is how. Here's my proposal: First, we need to document the situation as it stands, given the proxy=20 model and security mechanisms defined in RFC 3261 and relevant=20 extensions. I.e., in the current system, here's the base=20 (please-molest-me) model, here's what proxies can do to screw you up in=20 this model, and here's the sorts of assurances you can get by employing=20 some security features. Second, rather than requiring boilerplate in documents defining new=20 extensions, they should comment on how the extension affects the model=20 described in the above document -- either providing additional security=20 (e.g., by limiting proxy capabilities like SIPSEC) or by introducing=20 additional risks (e.g., by increasing proxy capabilities, like=20 answer-mode). This discussion could be a required subsection of the=20 Security Considerations section. I think that this would encourage people to give explicit consideration=20 to the sorts of risks Sandy noted in the answer-mode draft, and to think = about how they might fix or avoid them. --Richard Dean Willis wrote: >=20 > I'm having quite an interesting conversation with Sandy Murphy (cc'd)=20 > who was tasked by sec-dir to review one of our drafts=20 > (draft-ietf-sip-answermode). This draft has some rather interesting=20 > security issues, since if implemented incorrectly and then abused it=20 > could allow an attacker to "bug your phone" -- that is, turn it into a = > remote listening device. Similar attacks could also be used to run up=20 > the victim's connectivity bill, run down the device's battery, = aggravate=20 > the "voice hammer" DOS attack, and so on. >=20 > This lead us into a discussion of the SIP security model in general.=20 > Most SIP practitioners who have been at it for awhile know that if the = > proxies we have decided to trust suddenly decide to get malicious, = then=20 > we're very much at their mercy. They can do all sorts of things,=20 > including routing our media through interceptors, mangling SDP = payloads,=20 > injecting (or blocking) instant messages, altering presence = information,=20 > and so on. >=20 > But this aspect of SIP is not obvious to naive implementors, or even = to=20 > less naive security types. >=20 > Maybe every SIP extension document should include a boiler-plate=20 > reminder about the sensitivity of proxies, then go on to enumerate and = > describe the new ways that malicious proxies (should there be such a=20 > thing) can wreak havoc using the extension being documented. >=20 > what do you folks think? >=20 > 1) Could a reasonable "How you could be violated by trusted proxies = that=20 > turn rogue" boilerplate be drafted? > 2) Would the practice of repeating this in drafts help or hurt us? > 3) Would it be useful for us to document how each extension could be=20 > used by a rogue proxy? >=20 > --=20 > Dean >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Aug 15 19:10:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILRzC-0006dD-4h; Wed, 15 Aug 2007 19:09:10 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1ILRzB-0006d8-0B for sip-confirm+ok@megatron.ietf.org; Wed, 15 Aug 2007 19:09:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILRzA-0006d0-Mm for sip@ietf.org; Wed, 15 Aug 2007 19:09:08 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILRz9-0005W9-B3 for sip@ietf.org; Wed, 15 Aug 2007 19:09:08 -0400 Received: from hkaplan [10.0.200.241] by acmepacket.com with ESMTP (SMTPD-9.10) id A792011C; Wed, 15 Aug 2007 19:09:06 -0400 From: "Hadriel Kaplan" To: "'Jeroen van Bemmel'" , References: <9857.1187188777@cornfed.com><003601c7df57$e5e24ab0$0601a8c0@BEMBUSTER> <001701c7df60$f113ce50$0601a8c0@BEMBUSTER> Subject: RE: SIPSEC comments (Was Re: [Sip] Question on SIPSecurityconsiderations forfuture extensions) Date: Wed, 15 Aug 2007 19:09:06 -0400 Message-ID: <056801c7df91$47bb2ed0$800101df@acmepacket.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <001701c7df60$f113ce50$0601a8c0@BEMBUSTER> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcffYPfDV6jSQMJ1QdOXJ3h+sFxnIgAL09NQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 89ebdf268eceaeaf784b3acb625dc20e Cc: 'sip List' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0106431712==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0106431712== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0569_01C7DF6F.C0A98ED0" This is a multi-part message in MIME format. ------=_NextPart_000_0569_01C7DF6F.C0A98ED0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I don't see how the contact encryption would prove anything about either side. A middle-man can just as easily use the key from the Connect message to encrypt its own contact URI. As for the last point, any b2bua or proxy wanting to block the Connect would simply block the Connect (reject it with a 420 or 501, for example). They don't need to muck with the contact. -hadriel _____ From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] Sent: Wednesday, August 15, 2007 1:23 PM To: fwmiller@cornfed.com Cc: sip List Subject: Re: SIPSEC comments (Was Re: [Sip] Question on SIPSecurityconsiderations forfuture extensions) Frank, Elaborating on: 4 - would be nice to have a mechanism to encrypt the Contact URI in the response, specifically for the caller. An incoming request to a contact that was sent encrypted gives higher trust. At least it should be integrity protected somehow. Suppose the UAS would include a new header "Secure-Contact" containing a contact URI encrypted using a key that the caller passed in its CONNECT request. That would provide: - a means for the UAC to check the integrity of the contact - a means for the UAS to verify that the caller is the same as the party that CONNECTed before (i.e. by including some unique bits in the contact URI) - a way to avoid B2BUA elements blocking CONNECT by not forwarding the UAS Contact header Furthermore, the draft could talk about how the UAS could specify a different machine than itself, for example a proxy with which it maintains an outbound connection. This could be a different proxy than the one through which the CONNECT came in. It could also be a proxy with which the UAS maintains a non-SIP connection (say a VPN/IPSec connection). Such a proxy might not be able to present a certificate on behalf of the UAS, but at least it would provide a mechanism to side step the SIP proxy infrastructure Regards, Jeroen ------=_NextPart_000_0569_01C7DF6F.C0A98ED0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I don’t see how the contact encryption would prove anything about either side.  A middle-man = can just as easily use the key from the Connect message to encrypt its own contact = URI. 

As for the last point, any b2bua or = proxy wanting to block the Connect would simply block the Connect (reject it with a = 420 or 501, for example).  They don’t need to muck with the = contact.

 

-hadriel

 

 

From: = Jeroen van Bemmel [mailto:jbemmel@zonnet.nl]
Sent: Wednesday, August = 15, 2007 1:23 PM
To: = fwmiller@cornfed.com
Cc: sip List
Subject: Re: SIPSEC = comments (Was Re: [Sip] Question on SIPSecurityconsiderations forfuture = extensions)

 

Frank,

 

Elaborating on:

 

4 - would be nice to have a mechanism to encrypt the = Contact URI in the response, specifically for the caller. An incoming request to = a contact that was sent encrypted gives higher trust. At least it should = be integrity protected somehow.

 

Suppose the UAS would include a new header "Secure-Contact" containing a contact URI encrypted using a = key that the caller passed in its CONNECT request. That would = provide:

- a means for the UAC to check the integrity of the = contact

- a means for the UAS to verify that the caller is = the same as the party that CONNECTed before (i.e. by including some unique bits = in the contact URI)

- a way to avoid B2BUA elements blocking CONNECT by = not forwarding the UAS Contact header

 

 

Furthermore, the draft could talk about how the UAS = could specify a different machine than itself, for example a proxy with which = it maintains an outbound connection. This could be a different proxy than = the one through which the CONNECT came in. It could also be a proxy with = which the UAS maintains a non-SIP connection (say a VPN/IPSec connection). Such a = proxy might not be able to present a certificate on behalf of the UAS, but at = least it would provide a mechanism to side step the SIP proxy = infrastructure

 

Regards,

Jeroen

------=_NextPart_000_0569_01C7DF6F.C0A98ED0-- --===============0106431712== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0106431712==-- From sip-bounces@ietf.org Wed Aug 15 19:27:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILSFE-0005aZ-IM; Wed, 15 Aug 2007 19:25:44 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1ILSFC-0005aT-MB for sip-confirm+ok@megatron.ietf.org; Wed, 15 Aug 2007 19:25:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILSFC-0005aL-CU for sip@ietf.org; Wed, 15 Aug 2007 19:25:42 -0400 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILSFA-0006Fc-FN for sip@ietf.org; Wed, 15 Aug 2007 19:25:42 -0400 Received: (qmail 2134 invoked by uid 0); 15 Aug 2007 23:26:51 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER) ([87.212.11.198]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 15 Aug 2007 23:26:51 -0000 Message-ID: <00f101c7df93$93cfbc80$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "Hadriel Kaplan" , References: <9857.1187188777@cornfed.com><003601c7df57$e5e24ab0$0601a8c0@BEMBUSTER> <001701c7df60$f113ce50$0601a8c0@BEMBUSTER> <056801c7df91$47bb2ed0$800101df@acmepacket.com> Subject: Re: SIPSEC comments (Was Re: [Sip] Question on SIPSecurityconsiderations forfuture extensions) Date: Thu, 16 Aug 2007 01:25:33 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: bdfdd9dd835c9bb499f7c92933fef080 Cc: 'sip List' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1516735324==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1516735324== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00ED_01C7DFA4.57240F00" This is a multi-part message in MIME format. ------=_NextPart_000_00ED_01C7DFA4.57240F00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hadriel, MITM encrypting its own URI: true, but it would not be able to determine which Contact URI the UAS proposed (it could be different from the UAS' own IP address+port). If the MITM would try to impersonate the caller while "guessing" the Contact, the UAS would detect that the request URI did not contain its magic bits. The UAS could formulate these bits such that it can correlate a request after CONNECT with an earlier CONNECT, and refuse all "out-of-the-blue" requests (and do things like enforce a maximum time interval, etc.) My point about the additional benefit of using a header different from "Contact", is that current B2BUA implementations (e.g. SBC) typically insert their own Contact. However, some do pass headers unknown to them, so a new header could survive a B2BUA that would otherwise unknowingly/unintentionally block a CONNECT. Regards, Jeroen ----- Original Message ----- From: Hadriel Kaplan To: 'Jeroen van Bemmel' ; fwmiller@cornfed.com Cc: 'sip List' Sent: Thursday, August 16, 2007 1:09 AM Subject: RE: SIPSEC comments (Was Re: [Sip] Question on SIPSecurityconsiderations forfuture extensions) I don't see how the contact encryption would prove anything about either side. A middle-man can just as easily use the key from the Connect message to encrypt its own contact URI. As for the last point, any b2bua or proxy wanting to block the Connect would simply block the Connect (reject it with a 420 or 501, for example). They don't need to muck with the contact. -hadriel ------------------------------------------------------------------------------ From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] Sent: Wednesday, August 15, 2007 1:23 PM To: fwmiller@cornfed.com Cc: sip List Subject: Re: SIPSEC comments (Was Re: [Sip] Question on SIPSecurityconsiderations forfuture extensions) Frank, Elaborating on: 4 - would be nice to have a mechanism to encrypt the Contact URI in the response, specifically for the caller. An incoming request to a contact that was sent encrypted gives higher trust. At least it should be integrity protected somehow. Suppose the UAS would include a new header "Secure-Contact" containing a contact URI encrypted using a key that the caller passed in its CONNECT request. That would provide: - a means for the UAC to check the integrity of the contact - a means for the UAS to verify that the caller is the same as the party that CONNECTed before (i.e. by including some unique bits in the contact URI) - a way to avoid B2BUA elements blocking CONNECT by not forwarding the UAS Contact header Furthermore, the draft could talk about how the UAS could specify a different machine than itself, for example a proxy with which it maintains an outbound connection. This could be a different proxy than the one through which the CONNECT came in. It could also be a proxy with which the UAS maintains a non-SIP connection (say a VPN/IPSec connection). Such a proxy might not be able to present a certificate on behalf of the UAS, but at least it would provide a mechanism to side step the SIP proxy infrastructure Regards, Jeroen ------=_NextPart_000_00ED_01C7DFA4.57240F00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hadriel,
 
MITM encrypting its own URI: true, but = it would not=20 be able to determine which Contact URI the UAS proposed (it could be = different=20 from the UAS' own IP address+port). If the MITM would try to impersonate = the=20 caller while "guessing" the Contact, the UAS would detect that the = request URI=20 did not contain its magic bits. The UAS could formulate these bits = such=20 that it can correlate a request after CONNECT with an earlier CONNECT, = and=20 refuse all "out-of-the-blue" requests (and do things like enforce a = maximum time=20 interval, etc.)
 
My point about the additional benefit = of using a=20 header different from "Contact", is that current B2BUA implementations = (e.g.=20 SBC) typically insert their own Contact. However, some do pass headers = unknown=20 to them, so a new header could survive a B2BUA that would otherwise=20 unknowingly/unintentionally block a CONNECT.
 
Regards,
Jeroen
 
----- Original Message -----
From:=20 Hadriel=20 Kaplan
To: 'Jeroen van Bemmel' ; fwmiller@cornfed.com
Sent: Thursday, August 16, 2007 = 1:09=20 AM
Subject: RE: SIPSEC comments = (Was Re:=20 [Sip] Question on SIPSecurityconsiderations forfuture = extensions)

I don=92t = see how the=20 contact encryption would prove anything about either side.  A = middle-man=20 can just as easily use the key from the Connect message to encrypt its = own=20 contact URI. 

As for the = last=20 point, any b2bua or proxy wanting to block the Connect would simply = block the=20 Connect (reject it with a 420 or 501, for example).  They don=92t = need to=20 muck with the contact.

 

-hadriel

 

 

From: Jeroen=20 van Bemmel [mailto:jbemmel@zonnet.nl]
Sent: Wednesday, August 15, = 2007 1:23=20 PM
To:=20 fwmiller@cornfed.com
Cc: sip=20 List
Subject: Re: = SIPSEC=20 comments (Was Re: [Sip] Question on SIPSecurityconsiderations = forfuture=20 extensions)

 

Frank,

 

Elaborating=20 on:

 

4 - would be nice to = have a=20 mechanism to encrypt the Contact URI in the response, specifically for = the=20 caller. An incoming request to a contact that was sent encrypted gives = higher=20 trust. At least it should be integrity protected somehow.=20

 

Suppose the UAS would = include a=20 new header "Secure-Contact" containing a contact URI encrypted using a = key=20 that the caller passed in its CONNECT request. That would=20 provide:

- a means for the UAC to = check the=20 integrity of the contact

- a means for the UAS to = verify=20 that the caller is the same as the party that CONNECTed before (i.e. = by=20 including some unique bits in the contact=20 URI)

- a way to avoid B2BUA = elements=20 blocking CONNECT by not forwarding the UAS Contact=20 header

 

 

Furthermore, the draft = could talk=20 about how the UAS could specify a different machine than itself, for = example a=20 proxy with which it maintains an outbound connection. This could be a=20 different proxy than the one through which the CONNECT came = in. It could=20 also be a proxy with which the UAS maintains a non-SIP connection (say = a=20 VPN/IPSec connection). Such a proxy might not be able to present a = certificate=20 on behalf of the UAS, but at least it would provide a mechanism to = side step=20 the SIP proxy infrastructure

 

Regards,

Jeroen

= ------=_NextPart_000_00ED_01C7DFA4.57240F00-- --===============1516735324== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1516735324==-- From sip-bounces@ietf.org Wed Aug 15 21:57:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILUaU-000271-Ft; Wed, 15 Aug 2007 21:55:50 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1ILUaT-00026w-32 for sip-confirm+ok@megatron.ietf.org; Wed, 15 Aug 2007 21:55:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILUaS-00026n-PH for sip@ietf.org; Wed, 15 Aug 2007 21:55:48 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILUaP-00038S-UH for sip@ietf.org; Wed, 15 Aug 2007 21:55:48 -0400 Received: from hkaplan [75.68.59.21] by acmepacket.com with ESMTP (SMTPD-9.10) id AE9F030C; Wed, 15 Aug 2007 21:55:43 -0400 From: "Hadriel Kaplan" To: "'Jeroen van Bemmel'" , References: <9857.1187188777@cornfed.com><003601c7df57$e5e24ab0$0601a8c0@BEMBUSTER> <001701c7df60$f113ce50$0601a8c0@BEMBUSTER> <056801c7df91$47bb2ed0$800101df@acmepacket.com> <00f101c7df93$93cfbc80$0601a8c0@BEMBUSTER> Subject: RE: SIPSEC comments (Was Re: [Sip] Question on SIPSecurityconsiderations forfuture extensions) Date: Wed, 15 Aug 2007 21:55:05 -0400 Message-ID: <059901c7dfa8$77a154f0$800101df@acmepacket.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <00f101c7df93$93cfbc80$0601a8c0@BEMBUSTER> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Acffk5eaV+MGZa0MS/aEkxLlek4LsgAEpCLw X-Spam-Score: 0.0 (/) X-Scan-Signature: dfec89f65e469387666e36fc1e4e3b22 Cc: 'sip List' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0996457770==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0996457770== Content-Type: multipart/alternative; boundary="----=_NextPart_000_059A_01C7DF86.F08FB4F0" This is a multi-part message in MIME format. ------=_NextPart_000_059A_01C7DF86.F08FB4F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit _____ From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] Sent: Wednesday, August 15, 2007 7:26 PM To: Hadriel Kaplan; fwmiller@cornfed.com Cc: 'sip List' Subject: Re: SIPSEC comments (Was Re: [Sip] Question on SIPSecurityconsiderations forfuture extensions) Hadriel, MITM encrypting its own URI: true, but it would not be able to determine which Contact URI the UAS proposed (it could be different from the UAS' own IP address+port). If the MITM would try to impersonate the caller while "guessing" the Contact, the UAS would detect that the request URI did not contain its magic bits. The UAS could formulate these bits such that it can correlate a request after CONNECT with an earlier CONNECT, and refuse all "out-of-the-blue" requests (and do things like enforce a maximum time interval, etc.) Ahh, I think I understand what you mean - essentially stick a timed cookie param in the contact-uri or this header so that the UAS knows the incoming Invite was from a previous Connect. So not really stopping a MITM as much as just un-authorized Invites? I don't think it really stops MITM because the MITM will get the 200 ok of the Connect and thus know the contact/req-uri to use for the Invite. It's really the cert verification before the Invite that would prevent MITM, and thus my question in another email of what that verification would be. One could actually have the UAC and UAS stick their cert fingerprint in the Connect header, so that the UAS/UAC can check the new TLS connection is from that previous Connect, before even receiving an Invite. (but it would still not stop a MITM unless there was some way to verify the cert's validity) My point about the additional benefit of using a header different from "Contact", is that current B2BUA implementations (e.g. SBC) typically insert their own Contact. However, some do pass headers unknown to them, so a new header could survive a B2BUA that would otherwise unknowingly/unintentionally block a CONNECT. Ahh, got it. But if a b2bua wanted to let the Connect happen it would get out of the way and not replace the contact. (but of course I don't think a b2bua would want to let that happen, because I don't think their owners would want to let it happen - and they have the control to stop it) Regards, Jeroen ----- Original Message ----- From: Hadriel Kaplan To: 'Jeroen van Bemmel' ; fwmiller@cornfed.com Cc: 'sip List' Sent: Thursday, August 16, 2007 1:09 AM Subject: RE: SIPSEC comments (Was Re: [Sip] Question on SIPSecurityconsiderations forfuture extensions) I don't see how the contact encryption would prove anything about either side. A middle-man can just as easily use the key from the Connect message to encrypt its own contact URI. As for the last point, any b2bua or proxy wanting to block the Connect would simply block the Connect (reject it with a 420 or 501, for example). They don't need to muck with the contact. -hadriel _____ From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] Sent: Wednesday, August 15, 2007 1:23 PM To: fwmiller@cornfed.com Cc: sip List Subject: Re: SIPSEC comments (Was Re: [Sip] Question on SIPSecurityconsiderations forfuture extensions) Frank, Elaborating on: 4 - would be nice to have a mechanism to encrypt the Contact URI in the response, specifically for the caller. An incoming request to a contact that was sent encrypted gives higher trust. At least it should be integrity protected somehow. Suppose the UAS would include a new header "Secure-Contact" containing a contact URI encrypted using a key that the caller passed in its CONNECT request. That would provide: - a means for the UAC to check the integrity of the contact - a means for the UAS to verify that the caller is the same as the party that CONNECTed before (i.e. by including some unique bits in the contact URI) - a way to avoid B2BUA elements blocking CONNECT by not forwarding the UAS Contact header Furthermore, the draft could talk about how the UAS could specify a different machine than itself, for example a proxy with which it maintains an outbound connection. This could be a different proxy than the one through which the CONNECT came in. It could also be a proxy with which the UAS maintains a non-SIP connection (say a VPN/IPSec connection). Such a proxy might not be able to present a certificate on behalf of the UAS, but at least it would provide a mechanism to side step the SIP proxy infrastructure Regards, Jeroen ------=_NextPart_000_059A_01C7DF86.F08FB4F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

From: = Jeroen van Bemmel [mailto:jbemmel@zonnet.nl]
Sent: Wednesday, August = 15, 2007 7:26 PM
To: Hadriel Kaplan; fwmiller@cornfed.com
Cc: 'sip List'
Subject: Re: SIPSEC = comments (Was Re: [Sip] Question on SIPSecurityconsiderations forfuture = extensions)

 

Hadriel,

 

MITM encrypting its own URI: true, but it would not = be able to determine which Contact URI the UAS proposed (it could be different = from the UAS' own IP address+port). If the MITM would try to impersonate the = caller while "guessing" the Contact, the UAS would detect that the = request URI did not contain its magic bits. The UAS could formulate these = bits such that it can correlate a request after CONNECT with an earlier = CONNECT, and refuse all "out-of-the-blue" requests (and do things like = enforce a maximum time interval, etc.)

 

Ahh, I think I understand what you = mean – essentially stick a timed cookie param in the contact-uri or this header = so that the UAS knows the incoming Invite was from a previous Connect. =  So not really stopping a MITM as much as just un-authorized Invites?  = I don’t think it really stops MITM because the MITM will get the 200 ok of the = Connect and thus know the contact/req-uri to use for the Invite. =  It’s really the cert verification before the Invite that would prevent MITM, = and thus my question in another email of what that verification would = be.  One could actually have the UAC and UAS stick their cert fingerprint in the = Connect header, so that the UAS/UAC can check the new TLS connection is from = that previous Connect, before even receiving an Invite. (but it would still = not stop a MITM unless there was some way to verify the cert’s = validity)

 

 

My point about the additional benefit of using a = header different from "Contact", is that current B2BUA = implementations (e.g. SBC) typically insert their own Contact. However, some do pass headers = unknown to them, so a new header could survive a B2BUA that would otherwise unknowingly/unintentionally block a = CONNECT.

 

=

Ahh, got it.  But if a b2bua = wanted to let the Connect happen it would get out of the way and not replace = the contact.  (but of course I don’t think a b2bua would want to = let that happen, because I don’t think their owners would want to let = it happen – and they have the control to stop = it)

 

 

Regards,

Jeroen

 

----- Original Message ----- =

Cc: 'sip List' =

Sent: = Thursday, August 16, 2007 1:09 AM

Subject: RE: = SIPSEC comments (Was Re: [Sip] Question on SIPSecurityconsiderations forfuture = extensions)

 

I don’t see how the contact encryption would prove anything about either side.  A middle-man = can just as easily use the key from the Connect message to encrypt its own = contact URI. 

As for the last point, any b2bua or = proxy wanting to block the Connect would simply block the Connect (reject it = with a 420 or 501, for example).  They don’t need to muck with the = contact.

 

-hadriel

 

 

From: = Jeroen van Bemmel [mailto:jbemmel@zonnet.nl]
Sent: Wednesday, August = 15, 2007 1:23 PM
To: = fwmiller@cornfed.com
Cc: sip List
Subject: Re: SIPSEC = comments (Was Re: [Sip] Question on SIPSecurityconsiderations forfuture = extensions)

 

Frank,

 

Elaborating on:

 

4 - would be nice to have a mechanism to encrypt the = Contact URI in the response, specifically for the caller. An incoming request to = a contact that was sent encrypted gives higher trust. At least it should = be integrity protected somehow.

 

Suppose the UAS would include a new header "Secure-Contact" containing a contact URI encrypted using a = key that the caller passed in its CONNECT request. That would = provide:

- a means for the UAC to check the integrity of the = contact

- a means for the UAS to verify that the caller is = the same as the party that CONNECTed before (i.e. by including some unique bits = in the contact URI)

- a way to avoid B2BUA elements blocking CONNECT by = not forwarding the UAS Contact header

 

 

Furthermore, the draft could talk about how the UAS = could specify a different machine than itself, for example a proxy with which = it maintains an outbound connection. This could be a different proxy than = the one through which the CONNECT came in. It could also be a proxy with = which the UAS maintains a non-SIP connection (say a VPN/IPSec connection). Such a = proxy might not be able to present a certificate on behalf of the UAS, but at = least it would provide a mechanism to side step the SIP proxy = infrastructure

 

Regards,

Jeroen

------=_NextPart_000_059A_01C7DF86.F08FB4F0-- --===============0996457770== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0996457770==-- From sip-bounces@ietf.org Thu Aug 16 00:31:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILWz6-0000Uf-46; Thu, 16 Aug 2007 00:29:24 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1ILWz4-0000UZ-PA for sip-confirm+ok@megatron.ietf.org; Thu, 16 Aug 2007 00:29:22 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILWz4-0000UR-C2 for sip@ietf.org; Thu, 16 Aug 2007 00:29:22 -0400 Received: from smtpauth00.csee.onr.siteprotect.com ([64.26.60.144]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ILWz3-0007x0-Rg for sip@ietf.org; Thu, 16 Aug 2007 00:29:22 -0400 Received: from cornfed (c-67-162-139-200.hsd1.co.comcast.net [67.162.139.200]) (Authenticated sender: fwmiller@cornfed.com) by smtpauth00.csee.onr.siteprotect.com (Postfix) with ESMTP id 54A3C758053; Wed, 15 Aug 2007 23:29:20 -0500 (CDT) From: "Frank W. Miller" To: "'Jeroen van Bemmel'" Subject: RE: SIPSEC comments (Was Re: [Sip] Question on SIP Security considerations forfuture extensions) Date: Wed, 15 Aug 2007 22:29:23 -0600 Message-ID: <009701c7dfbe$06473a20$6901a8c0@cornfed> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <003601c7df57$e5e24ab0$0601a8c0@BEMBUSTER> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: aafd3813f49c1dfb11e9623a3ab5d812 Cc: 'sip List' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1453424648==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1453424648== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0098_01C7DF8B.BBAF3B20" This is a multi-part message in MIME format. ------=_NextPart_000_0098_01C7DF8B.BBAF3B20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thanks for the comments. Let me first describe how we got to this point. Hopefully that will help when people start to make comments. When I read the sipsec draft, it struck me that there was the opportunity to provide a real end-to-end solution as I've proposed based on the CONNECT method. I contacted Vijay and asked for the XML for the draft. I spent some time sketching what I was thinking about within the context of the draft XML and sent it to Vijay, Francois, and Dean. I purposely did not fill in all the details because I suspected that there would be discussion about it and so wanted to wait until there was some indication that adding details would be fruitful. There has been some discussion as was alluded to by Francois in another email. Mainly, the question seems to be if this should be noted as an optimization to the originally proposed mechanism or should replace the originally proposed mechanism. All this took place in private emails among the four of us and I did not want to post it on the list until the authors were comfortable with that. So, when this discussion thread around security came up, it contained some interesting points that were relevant to the proposal. I asked the authors if it would be ok to post the links and they said fine and so here we are. All that said, my opinion would be similar to what Francois sent earlier. I believe this should be the default mechanism and that the proxy tunneling machinery, if kept at all, should be used only in situations where some network topology forces it. However, the draft belongs to the authors and they need to determine what happens next. If this change is incorporated, I would have opinions on the comments that you made and I'll respond inline here: Thanks, FM -----Original Message----- From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] Sent: Wednesday, August 15, 2007 10:18 AM To: fwmiller@cornfed.com Cc: sip List Subject: SIPSEC comments (Was Re: [Sip] Question on SIP Security considerations forfuture extensions) Frank, Some comments on the draft you refer to below: 1 - why insert (Proxy-)Require: sipsec? it will not work through currently deployed proxies, while section 6.6 does not require any new proxy behavior. Perhaps because 6.3 requires proxies to process mutulated responses, but FM: That's legacy from the original draft. We can revisit that I think. It may not make sense with this approach. 2 - why make the CONNECT response different than a normal SIP response? doing that makes it incompatible with current infrastructure, while providing little benefit FM: As mentioned, I was sketching the basics of the solutions. Specific responses can be changes as needed. 3 - section 6.5 UAS behavior should probably say that a Contact MUST be present in CONNECT response, and that it SHOULD be sips: FM: I agree. 4 - would be nice to have a mechanism to encrypt the Contact URI in the response, specifically for the caller. An incoming request to a contact that was sent encrypted gives higher trust. At least it should be integrity protected somehow. FM: I don't have strong feelings on this. I think that encrypting this URI might yield implementation complexity that may not buy much. 5 - would it be beneficial to make a link to the sip-certs work (http://www.ietf.org/internet-drafts/draft-ietf-sip-certs-04.txt)? For example, in the CONNECT method the caller could provide a reference to its certificate server (integrity-protected as part of the body for example) FM: I'm sure there will be lots of discussion about this. I do think that self-signing should be allowed so that parties that want to use it can. 6 - 6.3 should state that CONNECT is not a dialog creating request. Consequently, 6.5 should state that UAS MUST ignore any Record-Route headers present (and so not reflect them in the CONNECT response, although this might interfere with proxy functionality - but that's kind of the point, right?) FM: I agree. 7 - You could consider providing guidance on information that is not relevant to the CONNECT request, but needed to make requests / responses well formed. For example, you could specify default values for To and >From URIs (say anonymous@domain.invalid) FM: I think there is a lot more specification that needs to be done. 8 - Given that the Contact URIs need to be globally reachable (I guess how that is achieved should remain out of scope), they should be marked as (temporary?) GRUUs (i.e. include 'gr=xxx') FM: If there was ever an application for GRUUs, this has to be it. ------=_NextPart_000_0098_01C7DF8B.BBAF3B20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Thanks for the = comments.

 

Let me first describe how we got to = this point.  Hopefully that will = help when people start to make comments.

 

When I read the sipsec draft, it struck me that there was the opportunity to provide a real = end-to-end solution as I’ve proposed based on the CONNECT method.  I contacted Vijay and asked for = the XML for the draft.  I spent = some time sketching what I was thinking about within the context of the draft XML = and sent it to Vijay, Francois, and Dean.  I purposely did not fill in all the details because I suspected = that there would be discussion about it and so wanted to wait until there was = some indication that adding details would be fruitful.  There has been some discussion = as was alluded to by Francois in another email.  Mainly, the question seems to be if this should be noted as an optimization to the originally proposed mechanism or should replace the originally proposed mechanism.

 

All this took place in private = emails among the four of us and I did not want to post it on the list until the authors were comfortable with that.  So, when this discussion thread around security came up, it = contained some interesting points that were relevant to the proposal.  I asked the authors if it would = be ok to post the links and they said fine and so here we = are.

 

All that said, my opinion would be similar to what Francois sent earlier.  I believe this should be the = default mechanism and that the proxy tunneling machinery, if kept at all, should = be used only in situations where some network topology forces it.  However, the draft belongs to = the authors and they need to determine what happens next.  If this change is incorporated, = I would have opinions on the comments that you made and I’ll respond = inline here:

 

Thanks,

=

FM

 

 

-----Original = Message-----
From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl]
Sent: Wednesday, August = 15, 2007 10:18 AM
To: = fwmiller@cornfed.com
Cc: sip List
Subject: SIPSEC comments = (Was Re: [Sip] Question on SIP Security considerations forfuture = extensions)

 

Frank,

 

Some comments on the draft = you refer to below:

 

1 - why insert = (Proxy-)Require: sipsec? it will not work through currently deployed proxies, while = section 6.6 does not require any new proxy behavior. Perhaps because 6.3 = requires proxies to process mutulated responses, but

 

FM: That’s legacy from the = original draft.  We can revisit that = I think.  It may not make = sense with this approach.

 

 

2 - why make the CONNECT response different than a normal SIP response? doing = that makes it incompatible with current infrastructure, while providing = little benefit

 

=

FM: As mentioned, I was sketching = the basics of the solutions.  = Specific responses can be changes as needed.

 

3 - section 6.5 UAS behavior should probably say that a Contact MUST be present in = CONNECT response, and that it SHOULD be sips:

 

FM: I = agree.

 

4 - would be nice to have a mechanism to encrypt the Contact URI in the response, specifically for the caller. An incoming request to a contact that was = sent encrypted gives higher trust. At least it should be integrity protected somehow.

 

FM: I don’t have strong = feelings on this.  I think that = encrypting this URI might yield implementation complexity that may not buy = much.

 

5 - would it be beneficial to make a link to the sip-certs work (= http://www.ietf.org/internet-drafts/draft-ietf-sip-certs-04.txt)? For example, in the CONNECT method the caller could provide a reference = to its certificate server (integrity-protected as part of the body for = example)

 

FM: I’m sure there will be = lots of discussion about this.  I = do think that self-signing should be allowed so that parties that want to use it = can.

 

6 - 6.3 should state that = CONNECT is not a dialog creating request. Consequently, 6.5 should state that UAS = MUST ignore any Record-Route headers present (and so not reflect them in the = CONNECT response, although this might interfere with proxy functionality - but = that's kind of the point, right?)

 

=

FM: I = agree.

 

7 - You could consider = providing guidance on information that is not relevant to the CONNECT request, but = needed to make requests / responses well formed. For example, you could specify default values for To and From URIs (say anonymous@domain.invalid)

 

FM: I think there is a lot more specification that needs to be done.

 

8 - Given that the Contact = URIs need to be globally reachable (I guess how that is achieved should remain out = of scope), they should be marked as (temporary?) GRUUs (i.e. include = 'gr=3Dxxx')

 

FM: If there was ever an = application for GRUUs, this has to be = it.

 

 

------=_NextPart_000_0098_01C7DF8B.BBAF3B20-- --===============1453424648== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1453424648==-- From sip-bounces@ietf.org Thu Aug 16 09:00:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILewE-0008Oh-4q; Thu, 16 Aug 2007 08:58:58 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1ILewC-0008Ob-63 for sip-confirm+ok@megatron.ietf.org; Thu, 16 Aug 2007 08:58:56 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1ILewB-0008OS-Sw for sip@ietf.org; Thu, 16 Aug 2007 08:58:55 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILes3-0005KX-8q for sip@ietf.org; Thu, 16 Aug 2007 08:54:39 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1ILes2-0006SN-H8 for sip@ietf.org; Thu, 16 Aug 2007 08:54:38 -0400 Received: (qmail 27173 invoked by uid 0); 16 Aug 2007 12:54:37 -0000 Received: from 194.208.88.198 by www144.gmx.net with HTTP; Thu, 16 Aug 2007 14:54:36 +0200 (CEST) Content-Type: multipart/mixed; boundary="========GMX17051118726887741447" Date: Thu, 16 Aug 2007 14:54:37 +0200 From: "Guenther Sohler" Message-ID: <20070816125437.170510@gmx.net> MIME-Version: 1.0 To: sip@ietf.org X-Authenticated: #18210244 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 X-Provags-ID: V01U2FsdGVkX19MnM8xW51MgKYjtYcXLnKV8bS4xGwmng9htn91bI ATkDmqsEj3OLTW7iYE2ADETMz0LW2mONtW0A== X-GMX-UID: P3D3fq52MmA6f6+xfmBn4mA5MjQ1Nx2C X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 X-TMDA-Confirmed: Thu, 16 Aug 2007 08:58:55 -0400 Subject: [Sip] Problems with SIP implementation X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org --========GMX17051118726887741447 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Hallo Group, I am trying to implement my own sip stack. Registering works fine. But I dont get an answer to my "INVITE" request. The code is still quite small, so it should not be a problem to find the error. Its a quite simple state machine, which retires, if there is no response after 3 seconds Its attached to the mail The passwords/phone details are intentioanally wrong. No need to try them. Thank you for your help! Guenther -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kanns mit allen: http://www.gmx.net/de/go/multimessenger --========GMX17051118726887741447 Content-Type: application/x-compressed-tar; name="siptools.tgz" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="siptools.tgz" H4sIAJ5IxEYAA+0abXPaOLNfza/QuZOWtA7Y5i2BuHOEkJQpJZlArs9Nm2FcEOCesV1LJOnd9b8/ K8k2MpC3a9KbeR7vh8TeXa1WK2nfDHEC6vsuKT57OtABahWd/TdqFfMZ+wvPHB/BM0OvVg29XDZL FaCbVcN8hipPqFMCC0LtEKFnU+LPXBzeyOe5wDiZ/AyVfiaQeP/tBZ0VRkHwBHOwDa6Wb9x/s1yu 8f3Xa1UT/gC9XAIy0p9AlzX4P9//5443chdjjFQ4CYWZmsvlLn1njFqX9C2+zqOFR5yph8doNAMz vTpwPE08ARVt5/7KKY5HkdPIKRM/zDuW3nD2jWrDef16O6coJAiBPMkD82vzlaOpW7p5rWog5aNz sd3IoQiA/rFkXiALvfykv2zkvkdaHDpTTGjLdkdnmAS+R3BezB6/om0EOsRi3h9Whq3Bf9D7caVF r0GntPYzm8w+GtWL5bwc/bZp8PlL6wQzISSU4is0An0Wrk0xeptvGtvoVTGnsKk7nkPz6IWYHcHy BPo8GANvQtCQ4038woLgsEBomN+WES728tts6OaRal3VkHEznQsKse3OU6IF5jFkBzYhKdEckUgW Q48cz3bz3NyabI7YhPHZEgzC/Hz0TTY2uY3lXV43tUzdrPsc05k/jrSXMYn6t8pY2ufuqRahI8/D Xpc2koc/1FTmraYK41vxY9YSO6KhkvmoRvF8b4RlswjEo1pfWChW/QdMvXQw3Bv92276ySCJ/9z9 P80cd8R/o1QqSfG/CvRSpVrL4v/PgDj+7xM6dvzC7E1OxrjO5zQKoqntplALzwHG1YF2OE2hjkl3 RRR15lhGoH0/wB4hbnE+rjBC7vkYTxwPo/6gOWgPO73OQFH0FexZ+7jTH7TPFMW4gTJsng/eKuYK 9aTX7fTailJam+W3zgDw5eX0h+2D8+NcrlhEMaZ53O4NkNp3AliUmltBN7vd2l5FR7pZ0PcKZoml VPRbgIELgfNbjGicNbn+6A+ItsekTyFNmqIg9K+/LUJXxs18Qp1Axsy/eYv5ZxyyaLscaofUW8Gx hCIlHkK1/M7dr4zgaYKMgLiVmpmHSxkz8j2KPdoQ6wEXEvhh8kbBNcPzUafbRq/8RYwfEfwVVgBu FYEFOxAIGlG25+ErPigPbOB275sBwnB8TXHoxfJ4uGn87/rsx4SU/3+a8u8O/29UaiUzqf+NKvP/ ZcOsZP7/Z8B6/Ze+ROIW0tD2yBySSHH3JnOqoUKhIArAS3voQgxAdsDcD7wxi9K8HWjAB7fzuTNh vk/4USWqCNWdN0hltcZlhGAy7YBhYo5PHmN4jr2xMwG+SYTnqSO4E205Yo2kbo1gtGaU+Az2EGTk OWtcWBJMI99155IUzkDxPPho6vpF4/5LzOfvWOH29soa43qZzSatj68r0ve1xYhrSKO0jtLXFx+t nnnZuT2aQdjKM0xSyE/G2sS1pyxOOJE9WZTahthAF6En6c5lWFtjZmfOxxFMW3Ll0NEsLyFzCohX RjaRg3kdUIk0FvvR+eEpiygeHlHH934RtgGmeFutCQFdGKsQHsdLuaaIYpB23B+enp0MTlon3SHI 5YLiTH8ytiYOlB1+cmDEPHzl1mTkUTcPhjgaHrcHR12Jhv620Mmwd9I76J603gn8krvPuIX5eCms JCaEGdAvFuqdd7usK8KtoShJuEsnLGK+7+zPZ4jILEOQTRezpcx3hqdwXHG4tFlyY9V4AAvP9S1S 3xqjfue0CNlJtHG3mHFV1m+OXY9HF9l2cXmNz8Awmll/7s2Oy5/fDcGpH7X2wLFXqgfDQaXUOjiq tI1oNpHQ3GOu9/b1zpEfXtnhmNRRTV9b2FHoz+toXyzrV67Jmwa1p1Z6flPfNUu1vXLVjDSQOi8P Xf/AX53wx2VCbuPudA7rKMlY0/obu3umWTX3dqsw5QYjrsnr4691BLscy1M1lmvn+elbYwZnYY/o PVd1771rXwdOiGHbSlV9fePOQexOcwpOCvSEJfHEeZNmwLHTxd6UzupoXUyEuO2S8OS/Ll9Fuefw BunoxYu17puMltpbMlpqsTG8dKlXbyRiGiyvpRRMDHP3QrgJJeX21eSe3vd+KnGTKQ4NMUok7Fbi AlRB25BTs4GRsMf0HD/VddztO/4N5/Ek3uPR3cfD/MdTOZA7PMj9XIjE1VzA+Q+dP22WT9SjWpLX xZ49x9YndYt8UjVR9yZv3EMkb7Y7BQl0Nrfm44qG/MD+umBURmM3bilD3KQIccP65db85p7osnMc X8kNBt/kF9cdI08hsEvwundiCX4452ZB8ITYxz/k+lPHg+VDie7PAxdTzJZ1iUPKSn3qM8swRsmb /bMURjRfUgnMB8d1WSPbBf+KTEjPIQ8ck+VMxMU4yJviZWVW0bO5ORgIep27WinvVy+t2HYy1re2 CDJrUImW9soV6anTQ53TMkouUdyHuel8r4sm1spRlYkja3WC24VRS0eb9J9b9mLs+KhsgB9AZ4PT YvO3042cthXSYG4HdR2dtt6fF3dhQNHYyEighgjx6FKNEtvlWRPGjSLEr6yGnC++UOziie9BKTLf EDREq+qJsk19b7d0uKvvPTTb7GNC4DbsJH7H2N2QuYioIa743cHD2K2ZpgFx/pYTswn3GAnpBiv/ k5y01ex2h51DYzWolCqV8q6xVzMemJOK4/LPM9K7Lt2PVRRN1/Wv6qjZeqcd/N7WWs1eq93VhM5a 72TQOfpdO2sftc+0wxPt/PQQvIt2cjronPT6Wv/8oN866xy0tdMzJqDTOzpZm6C/4IrhMZwvXQ+x yw0RaiEOXHuEyY+lyoNvAa4jOwhcZ8R9e5GMgzWRqwEkyTOj+y7S3RuS7Q2dFrIyXDoAMt5S1bSH VlhkG+OJvXBpKhace394/pUnuhSg3i/rLQaIa9eglcGevy+bOowcB+Kkr5GQZ7Y3dnE4tF07nOdF w3rKOx8CU+HNC/6FI9/vHDe7Z++11BhOl1snUkNJ7l0nL1FbJdbcivEgJ62MLkmags3plQ3LSzoz 99cPhMjfBAgexvYYXvnhOJ8QYV+v4OAl79QPnNHy1aaUz8y+2xC6H+PfIBfWrTFRoAsfg15bal2N evuO9gWeGI8lJigQOIyU9fI+hfwILX8lwrjEWYt+LcJSFCbZYpSPzkU8Fn2CY8Z3HYo4xrAsyFjh 9VdU3jHKR/0CWZZYjFSUsUm/WEbjy/5yeOOL+IlKzLO+VOZCLS71S6KLFWc+bEbGEOkCk5qsOmSo SAluQkWaQP7QQuDQW5zZuIgEMomCUJg4IaFC6kv1JZMbEVxbwkfSE/FKxERmzgS4GsoKPvCDfKy9 SM44jfX1IvkRUdC+xzncd3bHYkZ+i5edxPQZWz1eSVuRnfqF+Ph0y3lafvTC9ph/u7rtJIG5lkcI 7SNDalIKAfwgJebIicMlSNLZioVJJ2sflSRhbAGMSCxCRrYXnTTjAnwfuM4XYm2SEML2x4gONOAE A0fq+rZ0v7cbqFhEg7PfO73jnEjVUYq/rBtJy0F4Q0CupNrJDUjqC2vTxY/uu/rhw4cdVhaBR2ZB AquaygfJrVZRAT1QCh+kbkzQU90YzvF943JNXb9ruUJEvOaVeURdkZog5oxjyzFUN8mvZCAfcZZh hkUZoctqsBEXYCWODNcCjejtvAooO7n8+fNiEn8zuJo5Ls5Lp2JTY1ioSkNrMsWU5GG4Rpw/sT9h j1Fuk3SrmQOi4Ya+8oavs/HOsl4++EGOEBpJIpjtIXizKwBY5l/N2EGmv2/IleT+Ds9L2IDldwwG yWcIYQ/lASuLHNBSY12gV5xNNENUkiSeivkmdmXntuPJHzeWeaFV0at6I8KJ7NFSjT2zYFR3C4Ze MFUmMpUzW6wrN4UDUbCpGg+Nk1FL1WumbtRK5dJuJaGy2h/ErmBZQ9FSe+8/DHqn704lNE/XQZJe NnUT6obyrlnVuSJr5W6HZ4Crx5DhIiets0Tg3/6ymEEGGWSQQQYZZJBBBhlkkEEGGWSQQQYZZJBB BhlkkEEGGWSQQQYZZJDBz4D/AqpuinMAUAAA --========GMX17051118726887741447 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --========GMX17051118726887741447-- From sip-bounces@ietf.org Fri Aug 17 02:02:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILutA-0003HJ-JC; Fri, 17 Aug 2007 02:00:52 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1ILut8-0003Gv-8z for sip-confirm+ok@megatron.ietf.org; Fri, 17 Aug 2007 02:00:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILut7-0003Gm-T8; Fri, 17 Aug 2007 02:00:49 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ILut7-00045P-AV; Fri, 17 Aug 2007 02:00:49 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l7H60Tuo024871; Fri, 17 Aug 2007 09:00:47 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Aug 2007 09:00:37 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Aug 2007 09:00:36 +0300 Received: from esdhcp041244.research.nokia.com ([172.21.41.244]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Aug 2007 09:00:35 +0300 From: =?utf-8?q?R=C3=A9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: "ext Iliff, Tina" Date: Fri, 17 Aug 2007 09:00:41 +0300 User-Agent: KMail/1.9.6 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200708170900.41623.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 17 Aug 2007 06:00:35.0835 (UTC) FILETIME=[EDD56CB0:01C7E093] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: sip@ietf.org, mmusic@ietf.org Subject: [Sip] Re: [Sipping] SDP offer/answer -- Port 9 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mmusic@ietf.org List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I think MMUSIC working group is a better place to discuss this. On Thursday 16 August 2007 18:59:39 ext Iliff, Tina wrote: > Hi! I have encountered an application in the "real world" which > provides port 9 in the SDP answer in the 200OK. The SDP m line > indicates RTP/AVP. I recognize that port 9 is acceptable if the SDP m > line indicates BFCP. My question is: Is port 9 acceptable for > RTP/AVP. In other words, should the original offerer send an ACK and > then immediate BYE indicating that it rejected the answer? Or....should > the offerer send an ACK, then send media to port 8? Port 9 is legal for any connection-oriented media transport. You are right= =20 however that it should not be used with RTP/AVP (=3D> UDP =3D> not=20 connection-oriented). Unless the SDP author wants the data really be sent t= o=20 port 9. > FYI. What I am actually seeing is that the answerer indicates port 9 in > the answer but sends a re-INVITE immediately after the ACK; however, the > originator/offerer does not accept the re-INVITE due to it is already in > the process of tearing down the call. > > Has anyone else seen this specific behavior or similar behavior? > > P.S. RFC2327 noted a range of 1024-65535 for RTP ports; however, > RFC4566 does not indicate a specific range. I think it's not the job of the SDP receiver to check the port numbers. If = the=20 sender wants to use port 9, why not afterall? Maybe it wants you to send to= =20 its discard service (makes sense if it's a send-only chatter bot). However, I would assume that in the case you describe, it would not actuall= y=20 work properly if you sent data to port 9 anyway. =2D-=20 R=C3=A9mi Denis-Courmont _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Aug 17 08:04:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IM0Wu-00008B-FS; Fri, 17 Aug 2007 08:02:16 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IM0Wt-000081-DX for sip-confirm+ok@megatron.ietf.org; Fri, 17 Aug 2007 08:02:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IM0Wt-00007t-3y for sip@ietf.org; Fri, 17 Aug 2007 08:02:15 -0400 Received: from nf-out-0910.google.com ([64.233.182.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IM0Wr-0001wr-Mb for sip@ietf.org; Fri, 17 Aug 2007 08:02:15 -0400 Received: by nf-out-0910.google.com with SMTP id c10so297320nfd for ; Fri, 17 Aug 2007 05:02:12 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=RTgH6B78ByisEbxwzIEz/A+R16AtPT7FGyL6Kvz+zgKwxMsCXRtDcNh5o+Uqs1OedYyiC69wj+uPwpIM/bklNwiDVvBn5iB57+J34709TvujdagMQuSTr5szHst/BIF9QOvHbcLbnHO+XUVOR0ewWM942M/8yKt695bZ7/XVtvA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=PsyW7Kq/dzNl8iLHi22/eT9VKIZa/92p8V6nurWy9JlBJe51HQZFnZV88Y3u0VXjCeF1qCgcmykTkh9d7xhSkSBkBLQg0DKj2bjnFOxAYNfzeBMnxnlBowOluNX1PDKo9EAPQES337eCZVqftcf9iqflYJNcFj8MV+KhIfM81P0= Received: by 10.86.3.2 with SMTP id 2mr2064573fgc.1187352132551; Fri, 17 Aug 2007 05:02:12 -0700 (PDT) Received: by 10.86.68.6 with HTTP; Fri, 17 Aug 2007 05:02:12 -0700 (PDT) Message-ID: Date: Fri, 17 Aug 2007 17:32:12 +0530 From: "Lokesh Agrawal" To: sip@ietf.org In-Reply-To: MIME-Version: 1.0 References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [Sip] Difference between DIALOG, SESSION and TRANSACTION X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0318046665==" Errors-To: sip-bounces@ietf.org --===============0318046665== Content-Type: multipart/alternative; boundary="----=_Part_50267_24419159.1187352132512" ------=_Part_50267_24419159.1187352132512 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi All, Can Any one tell me difference between DIALOG, SESSION and TRANSACTION. Please tell in detail with an example. Thanks and Regards Lokesh Agrawal ------=_Part_50267_24419159.1187352132512 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi All,

Can Any one tell me difference between DIALOG, SESSION and TRANSACTION.
Please tell in detail with an example.


Thanks and Regards
Lokesh Agrawal


------=_Part_50267_24419159.1187352132512-- --===============0318046665== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0318046665==-- From sip-bounces@ietf.org Fri Aug 17 09:57:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IM2J2-0008Gu-OQ; Fri, 17 Aug 2007 09:56:04 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IM2J0-00088H-Gw for sip-confirm+ok@megatron.ietf.org; Fri, 17 Aug 2007 09:56:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IM2J0-00085N-3Q for sip@ietf.org; Fri, 17 Aug 2007 09:56:02 -0400 Received: from an-out-0708.google.com ([209.85.132.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IM2Iz-0004nd-Gz for sip@ietf.org; Fri, 17 Aug 2007 09:56:02 -0400 Received: by an-out-0708.google.com with SMTP id c17so51067anc for ; Fri, 17 Aug 2007 06:56:01 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=O7ttYizxXBR7eze/qwmMhu6eiZAhyUiEDLXVRQPp7n1dB8JYOhcVhnNQN1F5HQS6GoCyKCWQWIKYJUdFFBTxORhKCxPF+dPIhwN1HFqwVFPHzBGSb4Il1wGC7MBNnKgDjr0OBpeSeEjX7NxINYfiQzXxqw4fS+KA5MZx5C6e4ME= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=ZNzpbY5vAbKoGLoulbIs7FzxhaK0XH9dvEz/eInz2jRbDyxZKr17ivnci10n2dYNlMHwvLMPAglO8eaFkF7xw9PI9lXoYbncf9uco29LiBUw+YgqUJyx0XNbFFHS5Ed5BZHqjKaktk+Rgk2tPVnEs8G3cGK4qQs8I3ycMITxM+Q= Received: by 10.90.81.14 with SMTP id e14mr4457070agb.1187358960682; Fri, 17 Aug 2007 06:56:00 -0700 (PDT) Received: by 10.100.46.13 with HTTP; Fri, 17 Aug 2007 06:56:00 -0700 (PDT) Message-ID: <52a9bccc0708170656m7bd38423l3b53003686870cd6@mail.gmail.com> Date: Fri, 17 Aug 2007 19:26:00 +0530 From: "Jagan Mohan" To: mmusic@ietf.org Subject: Re: [Sip] Re: [Sipping] SDP offer/answer -- Port 9 In-Reply-To: <200708170900.41623.remi.denis-courmont@nokia.com> MIME-Version: 1.0 References: <200708170900.41623.remi.denis-courmont@nokia.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: "ext Iliff, Tina" , sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2076165028==" Errors-To: sip-bounces@ietf.org --===============2076165028== Content-Type: multipart/alternative; boundary="----=_Part_88829_22964196.1187358960637" ------=_Part_88829_22964196.1187358960637 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline > > > Hi! I have encountered an application in the "real world" which > > provides port 9 in the SDP answer in the 200OK. The SDP m line > > indicates RTP/AVP. I recognize that port 9 is acceptable if the SDP m > > line indicates BFCP. My question is: Is port 9 acceptable for > > RTP/AVP. In other words, should the original offerer send an ACK and > > then immediate BYE indicating that it rejected the answer? Or....should > > > the offerer send an ACK, then send media to port 8? > > Port 9 is legal for any connection-oriented media transport. You are right > however that it should not be used with RTP/AVP (=> UDP => not > connection-oriented). Unless the SDP author wants the data really be sent > to > port 9. As per section 5.14 of RFC 4566, port 9 is perfectly fine but "a=rtcp:" line MUST be there in SDP. > FYI. What I am actually seeing is that the answerer indicates port 9 in > > the answer but sends a re-INVITE immediately after the ACK; however, the > > > originator/offerer does not accept the re-INVITE due to it is already in > > the process of tearing down the call. > > > > Has anyone else seen this specific behavior or similar behavior? > > > > P.S. RFC2327 noted a range of 1024-65535 for RTP ports; however, > > RFC4566 does not indicate a specific range. I would also like to know why the range of 1024-65535 was removed in RFC 4566. Regards, Jagan _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > ------=_Part_88829_22964196.1187358960637 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
> Hi!  I have encountered an application in the "real world"  which
> provides port 9 in the SDP answer in the 200OK.  The SDP m line
> indicates RTP/AVP.  I recognize that port 9 is acceptable if the SDP m
> line indicates BFCP.  My question is:   Is port 9 acceptable for
> RTP/AVP.  In other words, should the original offerer send an ACK and
> then immediate BYE indicating that it rejected the answer?  Or....should
> the offerer send an ACK, then send media to port 8?

Port 9 is legal for any connection-oriented media transport. You are right
however that it should not be used with RTP/AVP (=> UDP => not
connection-oriented). Unless the SDP author wants the data really be sent to
port 9.
 
As per section 5.14 of RFC 4566, port 9 is perfectly fine but "a=rtcp:" line MUST be there in SDP.

> FYI.  What I am actually seeing is that the answerer indicates port 9 in
> the answer but sends a re-INVITE immediately after the ACK; however, the
> originator/offerer does not accept the re-INVITE due to it is already in
> the process of tearing down the call.
>
> Has anyone else seen this specific behavior or similar behavior?
>
> P.S.  RFC2327 noted a range of 1024-65535 for RTP ports; however,
> RFC4566 does not indicate a specific range.
 
I would also like to know why the range of 1024-65535 was removed in RFC 4566.
 
Regards,
Jagan

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

------=_Part_88829_22964196.1187358960637-- --===============2076165028== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============2076165028==-- From sip-bounces@ietf.org Fri Aug 17 18:41:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IMATS-0002Ad-MY; Fri, 17 Aug 2007 18:39:22 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IMATR-0002AX-1v for sip-confirm+ok@megatron.ietf.org; Fri, 17 Aug 2007 18:39:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IMATQ-0002AN-K7 for sip@ietf.org; Fri, 17 Aug 2007 18:39:20 -0400 Received: from exprod6og55.obsmtp.com ([64.18.1.191]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IMATP-0001TX-KV for sip@ietf.org; Fri, 17 Aug 2007 18:39:20 -0400 Received: from source ([192.150.20.142]) by exprod6ob55.postini.com ([64.18.5.12]) with SMTP; Fri, 17 Aug 2007 15:38:46 PDT Received: from inner-relay-1.corp.adobe.com (inner-relay-1.corp.adobe.com [153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l7HMchJ2008205; Fri, 17 Aug 2007 15:38:43 -0700 (PDT) Received: from apacmail.pac.adobe.com (apacmail.pac.adobe.com [130.248.36.99]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l7HMaFcK017163; Fri, 17 Aug 2007 15:36:15 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by apacmail.pac.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 18 Aug 2007 07:38:40 +0900 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] Question on SIP Security considerations forfuture extensions Date: Fri, 17 Aug 2007 15:38:26 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223ADF97@namail5.corp.adobe.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF11A5C215@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Question on SIP Security considerations forfuture extensions Thread-Index: AcffTKmtZp5wgwQXQZqFzWm3PtEJeQABDbqwAAOkmnAAbvha4A== References: <9857.1187188777@cornfed.com> <24CCCC428EFEA2469BF046DB3C7A8D22C6B3F3@namail5.corp.adobe.com> <1ECE0EB50388174790F9694F77522CCF11A5C215@zrc2hxm0.corp.nortel.com> From: "Henry Sinnreich" To: "Francois Audet" , , "Dean Willis" , "Richard Barnes" X-OriginalArrivalTime: 17 Aug 2007 22:38:40.0665 (UTC) FILETIME=[5BF95090:01C7E11F] X-Spam-Score: 0.0 (/) X-Scan-Signature: dc60ea982e94509a7a8f1634aa16db79 Cc: sip List , Sandy Murphy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0565562063==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0565562063== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7E11F.534BD659" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7E11F.534BD659 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable >There are many cases where I'd put a lot more trust in the proxies than "the guys at the end of the lines".=20 =20 The guys are you and me :-) If it's an enterprise network, then the enterprise network is the endpoint and we agree here. =20 Now what about all those service provider networks in the middle? =20 Henry =20 ________________________________ From: Francois Audet [mailto:audet@nortel.com]=20 Sent: Wednesday, August 15, 2007 12:20 PM To: Henry Sinnreich; fwmiller@cornfed.com; Dean Willis; Richard Barnes Cc: sip List; Sandy Murphy Subject: RE: [Sip] Question on SIP Security considerations forfuture extensions =20 Actually, that is false in many cases. =20 It depends what you are trying to do, and who do you trust.=20 =20 There are many cases where I'd put a lot more trust in the proxies than "the guys at the end of the lines".=20 =20 Who has the responsibility for Security is really what should drive the solution. =20 An e2e model makes a lot of sense when the people that are engaged in the session are the ones with the incentive for the session to be secure. If Henry wants to talk to me, and we both want our session to be secure, then that's the right model. =20 An e2e model does not make any sense when the people that are engaged in the session don't care or are not savvy enough. For example, if I'm an Enteprise IT manager (or operator of a Government internal network), I may decide that I want all sessions between all my users to be secure despite them. As the IT manager, I'd be responsible if a rogue employee spies on collegue, regardless of how careless the other employees are. =20 I think it is important to be very clear on what we are trying to achieve when talking about e2e (sipsec) or hop-by-hop (sips). They are not meant to solve the same problem.=20 =20 =09 ________________________________ From: Henry Sinnreich [mailto:hsinnrei@adobe.com]=20 Sent: Wednesday, August 15, 2007 08:30 To: fwmiller@cornfed.com; Dean Willis; Richard Barnes Cc: sip List; Sandy Murphy Subject: RE: [Sip] Question on SIP Security considerations forfuture extensions I fully agree here. Only e2e security is real security and SIPS cannot obfuscate this. =20 Thanks, Henry =20 =09 ________________________________ From: fwmiller@cornfed.com [mailto:fwmiller@cornfed.com]=20 Sent: Wednesday, August 15, 2007 9:40 AM To: Dean Willis; Richard Barnes Cc: sip List; Sandy Murphy Subject: Re: [Sip] Question on SIP Security considerations forfuture extensions =20 =20 With all due respect, I don't agree with this. Its my opinion that the current model is well-understood and unsatifactory for many applications. While I think its fine to spend some time clarifying the current model, I don't think that should hold up the development of an end-to-end mechanism as well. That development can proceed in parallel and the sipsec draft is a good start in that direction. To that end, after receiving the blessing of the majority of the authors, I'm posting a proposal I made to them regarding a mod to the sipsec draft that I believe would improve its ability to address true end-to-end security. The idea is simple, rather than having the CONNECT message establish a "tunnel" through a series of proxies, CONNECT is used to trade addressing information between the UAs that then signal each other directly. This proposal was made as modifications to the sipsec draft. The draft is available as a standalone and as a diff to the current sipsec draft at the following links. Comments are hoped for... Thanks, FM =09 https://svn.resiprocate.org/rep/ietf-drafts/gurbani/sip-sipsec/sipsec-fm iller/ =09 =09 http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=3Dhttp://svn.resipr= o cate.org/rep/ietf-drafts/gurbani/sip-sipsec/draft-gurbani-sip-sipsec-01. txt&url2=3Dhttp://svn.resiprocate.org/rep/ietf-drafts/gurbani/sip-sipsec/= s ipsec-fmiller/draft-gurbani-sip-sipsec-fmiller-00.txt =20 =09 =09 =09 On Wed Aug 15 9:37 , Richard Barnes sent: I'm replying to Dean's original message so that I'm not deep down in the=20 thread, but I'd like to point to one of Dean's later comments: =09 > Look, my question about security documentation for SIP extensions had > nothing to do with SIPSEC and everything to do with documenting the > current please-molest-me proxy-mediated transitive-faith-in-goodness > I-believe-my-operator-cares-for-me model of SIP security. And we DO > need to document this model better -- the question is how. =09 Here's my proposal: =09 First, we need to document the situation as it stands, given the proxy=20 model and security mechanisms defined in RFC 3261 and relevant=20 extensions. I.e., in the current system, here's the base (please-molest-me) model, here's what proxies can do to screw you up in=20 this model, and here's the sorts of assurances you can get by employing=20 some security features. =09 Second, rather than requiring boilerplate in documents defining new=20 extensions, they should comment on how the extension affects the model=20 described in the above document -- either providing additional security=20 (e.g., by limiting proxy capabilities like SIPSEC) or by introducing=20 additional risks (e.g., by increasing proxy capabilities, like=20 answer-mode). This discussion could be a required subsection of the=20 Security Considerations section. =09 I think that this would encourage people to give explicit consideration=20 to the sorts of risks Sandy noted in the answer-mode draft, and to think=20 about how they might fix or avoid them. =09 --Richard =09 =09 =09 =09 =09 =09 =09 Dean Willis wrote: >=20 > I'm having quite an interesting conversation with Sandy Murphy (cc'd)=20 > who was tasked by sec-dir to review one of our drafts=20 > (draft-ietf-sip-answermode). This draft has some rather interesting=20 > security issues, since if implemented incorrectly and then abused it=20 > could allow an attacker to "bug your phone" -- that is, turn it into a=20 > remote listening device. Similar attacks could also be used to run up=20 > the victim's connectivity bill, run down the device's battery, aggravate=20 > the "voice hammer" DOS attack, and so on. >=20 > This lead us into a discussion of the SIP security model in general.=20 > Most SIP practitioners who have been at it for awhile know that if the=20 > proxies we have decided to trust suddenly decide to get malicious, then=20 > we're very much at their mercy. They can do all sorts of things,=20 > including routing our media through interceptors, mangling SDP payloads,=20 > injecting (or blocking) instant messages, altering presence information,=20 > and so on. >=20 > But this aspect of SIP is not obvious to naive implementors, or even to=20 > less naive security types. >=20 > Maybe every SIP extension document should include a boiler-plate=20 > reminder about the sensitivity of proxies, then go on to enumerate and=20 > describe the new ways that malicious proxies (should there be such a=20 > thing) can wreak havoc using the extension being documented. >=20 > what do you folks think? >=20 > 1) Could a reasonable "How you could be violated by trusted proxies that=20 > turn rogue" boilerplate be drafted? > 2) Would the practice of repeating this in drafts help or hurt us? > 3) Would it be useful for us to document how each extension could be=20 > used by a rogue proxy? >=20 > --=20 > Dean >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip =20 > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 >=20 =09 =09 =09 =09 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip =20 ------_=_NextPart_001_01C7E11F.534BD659 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

>There are many cases where = I'd put a lot more trust in the proxies than "the guys at the end of the lines".

 

The guys are you and me = J

If it’s an enterprise = network, then the enterprise network is the endpoint and we agree = here.

 

Now what about all those service = provider networks in the middle?

 

Henry

 

From: = Francois Audet [mailto:audet@nortel.com]
Sent: Wednesday, August = 15, 2007 12:20 PM
To: Henry Sinnreich; fwmiller@cornfed.com; Dean Willis; Richard Barnes
Cc: sip List; Sandy = Murphy
Subject: RE: [Sip] = Question on SIP Security considerations forfuture = extensions

 

Actually, that is false in many = cases.

 

It depends what you are trying to = do, and who do you trust.

 

There are many cases where I'd = put a lot more trust in the proxies than "the guys at the end of the lines".

 

Who has the responsibility for = Security is really what should drive the solution.

 

An e2e model makes a lot of sense = when the people that are engaged in the session are the ones with the = incentive for the session to be secure. If Henry wants to talk to me, and we both want = our session to be secure, then that's the right = model.

 

An e2e model does not make any = sense when the people that are engaged in the session don't care or are not = savvy enough. For example, if I'm an Enteprise IT manager (or operator of = a Government internal network), I may decide that I want all sessions = between all my users to be secure despite them. As the IT manager, I'd be = responsible if a rogue employee spies on collegue, regardless of how careless the other employees are.

 

I think it is important to be = very clear on what we are trying to achieve when talking about e2e (sipsec) or = hop-by-hop (sips). They are not meant to solve the same problem. =

 

From: Henry Sinnreich [mailto:hsinnrei@adobe.com]
Sent: Wednesday, August = 15, 2007 08:30
To: fwmiller@cornfed.com; = Dean Willis; Richard Barnes
Cc: sip List; Sandy = Murphy
Subject: RE: [Sip] = Question on SIP Security considerations forfuture = extensions

I fully agree here. Only e2e = security is real security and SIPS cannot obfuscate = this.

 

Thanks, = Henry

 

From: fwmiller@cornfed.com [mailto:fwmiller@cornfed.com]
Sent: Wednesday, August = 15, 2007 9:40 AM
To: Dean Willis; Richard = Barnes
Cc: sip List; Sandy = Murphy
Subject: Re: [Sip] = Question on SIP Security considerations forfuture = extensions

 

 

With all due respect, I don't agree with this.  Its my opinion that the = current model is well-understood and unsatifactory for many applications.  = While I think its fine to spend some time clarifying the current model, I don't = think that should hold up the development of an end-to-end mechanism as = well.  That development can proceed in parallel and the sipsec draft is a good = start in that direction.

To that end, after receiving the blessing of the majority of the authors, I'm = posting a proposal I made to them regarding a mod to the sipsec draft that I = believe would improve its ability to address true end-to-end = security.

The idea is simple, rather than having the CONNECT message establish a "tunnel" through a series of proxies, CONNECT is used to trade addressing information between the UAs that then signal each other directly.  This proposal was made as modifications to the sipsec = draft.  The draft is available as a standalone and as a diff to the current = sipsec draft at the following links.  Comments are hoped = for...

Thanks,

FM

https://svn.resiprocate.org/rep/ietf-drafts/gurbani/sip-si= psec/sipsec-fmiller/


http:= //tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=3Dhttp://svn.resiprocate= .org/rep/ietf-drafts/gurbani/sip-sipsec/draft-gurbani-sip-sipsec-01.txt&a= mp;url2=3Dhttp://svn.resiprocate.org/rep/ietf-drafts/gurbani/sip-sipsec/s= ipsec-fmiller/draft-gurbani-sip-sipsec-fmiller-00.txt

 




On Wed Aug 15 9:37 , Richard Barnes = sent:

I'm replying to Dean's original message so that I'm not deep = down in the
thread, but I'd like to point to one of Dean's later comments:

> Look, my question about security documentation for SIP extensions = had
> nothing to do with SIPSEC and everything to do with documenting = the
> current please-molest-me proxy-mediated = transitive-faith-in-goodness
> I-believe-my-operator-cares-for-me model of SIP security. And we = DO
> need to document this model better -- the question is how.

Here's my proposal:

First, we need to document the situation as it stands, given the proxy =
model and security mechanisms defined in RFC 3261 and relevant
extensions. I.e., in the current system, here's the base
(please-molest-me) model, here's what proxies can do to screw you up in =
this model, and here's the sorts of assurances you can get by employing =
some security features.

Second, rather than requiring boilerplate in documents defining new
extensions, they should comment on how the extension affects the model =
described in the above document -- either providing additional security =
(e.g., by limiting proxy capabilities like SIPSEC) or by introducing =
additional risks (e.g., by increasing proxy capabilities, like
answer-mode). This discussion could be a required subsection of the
Security Considerations section.

I think that this would encourage people to give explicit consideration =
to the sorts of risks Sandy noted in the answer-mode draft, and to think
about how they might fix or avoid them.

--Richard







Dean Willis wrote:
>
> I'm having quite an = interesting conversation with Sandy Murphy (cc'd)
> who was tasked by = sec-dir to review one of our drafts
> = (draft-ietf-sip-answermode). This draft has some rather interesting
> security issues, since = if implemented incorrectly and then abused it
> could allow an attacker = to "bug your phone" -- that is, turn it into a
> remote listening = device. Similar attacks could also be used to run up
> the victim's = connectivity bill, run down the device's battery, aggravate
> the "voice = hammer" DOS attack, and so on.
>
> This lead us into a = discussion of the SIP security model in general.
> Most SIP practitioners = who have been at it for awhile know that if the
> proxies we have decided = to trust suddenly decide to get malicious, then
> we're very much at = their mercy. They can do all sorts of things,
> including routing our = media through interceptors, mangling SDP payloads,
> injecting (or blocking) = instant messages, altering presence information,
> and so = on.
>
> But this aspect of SIP = is not obvious to naive implementors, or even to
> less naive security = types.
>
> Maybe every SIP = extension document should include a boiler-plate
> reminder about the = sensitivity of proxies, then go on to enumerate and
> describe the new ways = that malicious proxies (should there be such a
> thing) can wreak havoc = using the extension being documented.
>
> what do you folks = think?
>
> 1) Could a reasonable = "How you could be violated by trusted proxies that
> turn rogue" = boilerplate be drafted?
> 2) Would the practice = of repeating this in drafts help or hurt us?
> 3) Would it be useful = for us to document how each extension could be
> used by a rogue = proxy?
>
> --
> 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

 

------_=_NextPart_001_01C7E11F.534BD659-- --===============0565562063== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0565562063==-- From sip-bounces@ietf.org Fri Aug 17 18:44:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IMAWm-0004ts-UK; Fri, 17 Aug 2007 18:42:48 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IMAWk-0004oo-T9 for sip-confirm+ok@megatron.ietf.org; Fri, 17 Aug 2007 18:42:46 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IMAWi-0004oe-Hl for sip@ietf.org; Fri, 17 Aug 2007 18:42:45 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IMAWi-0001aY-8h for sip@ietf.org; Fri, 17 Aug 2007 18:42:44 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l7HMdID23592; Fri, 17 Aug 2007 22:39:18 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] Question on SIP Security considerations forfuture extensions Date: Fri, 17 Aug 2007 17:41:01 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF11AEB3BC@zrc2hxm0.corp.nortel.com> In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D223ADF97@namail5.corp.adobe.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Question on SIP Security considerations forfuture extensions Thread-Index: AcffTKmtZp5wgwQXQZqFzWm3PtEJeQABDbqwAAOkmnAAbvha4AABDTkg References: <9857.1187188777@cornfed.com> <24CCCC428EFEA2469BF046DB3C7A8D22C6B3F3@namail5.corp.adobe.com> <1ECE0EB50388174790F9694F77522CCF11A5C215@zrc2hxm0.corp.nortel.com> <24CCCC428EFEA2469BF046DB3C7A8D223ADF97@namail5.corp.adobe.com> From: "Francois Audet" To: "Henry Sinnreich" , , "Dean Willis" , "Richard Barnes" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb Cc: sip List , Sandy Murphy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1769445358==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1769445358== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7E11F.B1B2D2D3" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7E11F.B1B2D2D3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Which service providers in the middle? :^) =20 All that is needed is an IP network. ________________________________ From: Henry Sinnreich [mailto:hsinnrei@adobe.com]=20 Sent: Friday, August 17, 2007 15:38 To: Audet, Francois (SC100:3055); fwmiller@cornfed.com; Dean Willis; Richard Barnes Cc: sip List; Sandy Murphy Subject: RE: [Sip] Question on SIP Security considerations forfuture extensions =09 =09 >There are many cases where I'd put a lot more trust in the proxies than "the guys at the end of the lines".=20 =20 The guys are you and me :-) If it's an enterprise network, then the enterprise network is the endpoint and we agree here. =20 Now what about all those service provider networks in the middle? =20 Henry =20 ------_=_NextPart_001_01C7E11F.B1B2D2D3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Which=20 service providers in the middle? :^)
 
All=20 that is needed is an IP network.

From: Henry Sinnreich=20 [mailto:hsinnrei@adobe.com]
Sent: Friday, August 17, 2007=20 15:38
To: Audet, Francois (SC100:3055); = fwmiller@cornfed.com; Dean=20 Willis; Richard Barnes
Cc: sip List; Sandy = Murphy
Subject:=20 RE: [Sip] Question on SIP Security considerations forfuture=20 extensions

>There = are many=20 cases where I'd put a lot more trust in the proxies than "the guys at = the=20 end of the lines".

 

The guys = are you and=20 me J

If = it’s an enterprise=20 network, then the enterprise network is the endpoint and we agree=20 here.

 

Now what = about all=20 those service provider networks in the = middle?

 

Henry

 

------_=_NextPart_001_01C7E11F.B1B2D2D3-- --===============1769445358== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1769445358==-- From sip-bounces@ietf.org Sun Aug 19 14:26:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IMpRn-0008IO-Jy; Sun, 19 Aug 2007 14:24:23 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IMpRm-0008IF-GU for sip-confirm+ok@megatron.ietf.org; Sun, 19 Aug 2007 14:24:22 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IMpRl-0008I2-TH for sip@ietf.org; Sun, 19 Aug 2007 14:24:21 -0400 Received: from exprod6og53.obsmtp.com ([64.18.1.187]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IMpRl-0003cl-2t for sip@ietf.org; Sun, 19 Aug 2007 14:24:21 -0400 Received: from source ([192.150.20.142]) by exprod6ob53.postini.com ([64.18.5.12]) with SMTP; Sun, 19 Aug 2007 11:23:28 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l7JIN5J2008494; Sun, 19 Aug 2007 11:23:10 -0700 (PDT) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l7JIN0FV017869; Sun, 19 Aug 2007 11:23:00 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 19 Aug 2007 11:22:59 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] Question on SIP Security considerations forfuture extensions Date: Sun, 19 Aug 2007 11:18:33 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223ADF9C@namail5.corp.adobe.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF11AEB3BC@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Question on SIP Security considerations forfuture extensions Thread-Index: AcffTKmtZp5wgwQXQZqFzWm3PtEJeQABDbqwAAOkmnAAbvha4AABDTkgAFscFCA= References: <9857.1187188777@cornfed.com><24CCCC428EFEA2469BF046DB3C7A8D22C6B3F3@namail5.corp.adobe.com><1ECE0EB50388174790F9694F77522CCF11A5C215@zrc2hxm0.corp.nortel.com><24CCCC428EFEA2469BF046DB3C7A8D223ADF97@namail5.corp.adobe.com> <1ECE0EB50388174790F9694F77522CCF11AEB3BC@zrc2hxm0.corp.nortel.com> From: "Henry Sinnreich" To: "Francois Audet" , , "Dean Willis" , "Richard Barnes" X-OriginalArrivalTime: 19 Aug 2007 18:22:59.0440 (UTC) FILETIME=[F8B7A700:01C7E28D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f3b9db08b8c0fe2301a77f547096e31 Cc: sip List , Sandy Murphy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1264555711==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1264555711== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7E28D.F84E69F7" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7E28D.F84E69F7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Francois, thanks for the note! =20 Sorry, since I had forgotten the possibility of the private network proxy being compromised: =20 - If it is a financial institution , it is an open door to steal money, - If it is a law enforcement organization, the agents will get killed, - SIPS for proxies is just as bad for any private network as well as for service providers and their customers. =20 >From this perspective, any intermediary is either an invitation for some bad or outright dangerous behavior. =20 SIPS cannot obfuscate that the only security is e2e. Any intermediary is vulnerability. =20 Henry =20 ________________________________ From: Francois Audet [mailto:audet@nortel.com]=20 Sent: Friday, August 17, 2007 5:41 PM To: Henry Sinnreich; fwmiller@cornfed.com; Dean Willis; Richard Barnes Cc: sip List; Sandy Murphy Subject: RE: [Sip] Question on SIP Security considerations forfuture extensions =20 Which service providers in the middle? :^) =20 All that is needed is an IP network. =20 =09 ________________________________ From: Henry Sinnreich [mailto:hsinnrei@adobe.com]=20 Sent: Friday, August 17, 2007 15:38 To: Audet, Francois (SC100:3055); fwmiller@cornfed.com; Dean Willis; Richard Barnes Cc: sip List; Sandy Murphy Subject: RE: [Sip] Question on SIP Security considerations forfuture extensions >There are many cases where I'd put a lot more trust in the proxies than "the guys at the end of the lines".=20 =20 The guys are you and me :-) If it's an enterprise network, then the enterprise network is the endpoint and we agree here. =20 Now what about all those service provider networks in the middle? =20 Henry =20 ------_=_NextPart_001_01C7E28D.F84E69F7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Francois, thanks for the = note!

 

Sorry, since I had = forgotten the possibility of the private = network proxy being compromised:

 

-          If it is a financial institution , it is an open door to steal = money,

-          If it is a law enforcement organization, the agents will get killed,

-          SIPS for proxies is just as bad for any private network as well as for service = providers and their customers.

 

From this perspective, any = intermediary is either an invitation for some bad or outright dangerous = behavior.

 

SIPS cannot obfuscate that the only security is e2e. Any intermediary is = vulnerability.

 

Henry

 

From: = Francois Audet [mailto:audet@nortel.com]
Sent: Friday, August 17, = 2007 5:41 PM
To: Henry Sinnreich; fwmiller@cornfed.com; Dean Willis; Richard Barnes
Cc: sip List; Sandy = Murphy
Subject: RE: [Sip] = Question on SIP Security considerations forfuture = extensions

 

Which service providers in the = middle? :^)

 

All that is needed is an IP = network.

 

From: Henry Sinnreich [mailto:hsinnrei@adobe.com]
Sent: Friday, August 17, = 2007 15:38
To: Audet, Francois = (SC100:3055); fwmiller@cornfed.com; Dean Willis; Richard Barnes
Cc: sip List; Sandy = Murphy
Subject: RE: [Sip] = Question on SIP Security considerations forfuture = extensions

>There are many cases where = I'd put a lot more trust in the proxies than "the guys at the end of the lines".

 

The guys are you and me = J

If it’s an enterprise = network, then the enterprise network is the endpoint and we agree = here.

 

Now what about all those service = provider networks in the middle?

 

Henry

 

------_=_NextPart_001_01C7E28D.F84E69F7-- --===============1264555711== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1264555711==-- From sip-bounces@ietf.org Mon Aug 20 03:57:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN274-0005EE-1Q; Mon, 20 Aug 2007 03:55:50 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IN272-0005Dz-Al for sip-confirm+ok@megatron.ietf.org; Mon, 20 Aug 2007 03:55:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN26y-0005Dq-Iy for sip@ietf.org; Mon, 20 Aug 2007 03:55:44 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IN26w-0005Hl-Sd for sip@ietf.org; Mon, 20 Aug 2007 03:55:44 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l7K7tbjn021263 for ; Mon, 20 Aug 2007 10:55:41 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Aug 2007 10:55:29 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Aug 2007 10:55:29 +0300 Received: from [172.21.41.217] ([172.21.41.217]) by esebe105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Aug 2007 10:55:29 +0300 Message-ID: <46C948F1.7000503@nokia.com> Date: Mon, 20 Aug 2007 10:55:29 +0300 From: Jari Urpalainen User-Agent: Thunderbird 1.5.0.12 (X11/20070530) MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Aug 2007 07:55:29.0325 (UTC) FILETIME=[79E9C5D0:01C7E2FF] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [Sip] draft-urpalainen-sip-xcap-diff-event-02 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi all! I've updated . Element & attribute subscriptions were moved to i-d: . Resource selections are done by a flat URI list with the XCAP resource list format instead of the "path" header parameter, and some text nits have been done. The somewhat controversial initial sync problem still exists when patches are aggregated. It is however, proposed that we live with that now as it is a corner case which still can be handled with the proposed approach, any comments ? br, 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 sip-bounces@ietf.org Mon Aug 20 04:30:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN2cc-00034d-1u; Mon, 20 Aug 2007 04:28:26 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IN2ca-00034Y-B3 for sip-confirm+ok@megatron.ietf.org; Mon, 20 Aug 2007 04:28:24 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN2ca-00034P-0x for sip@ietf.org; Mon, 20 Aug 2007 04:28:24 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IN2cZ-0000eA-Kj for sip@ietf.org; Mon, 20 Aug 2007 04:28:23 -0400 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JN200C6KCUPEH@siemenscomms.co.uk> for sip@ietf.org; Mon, 20 Aug 2007 09:28:02 +0100 (BST) Date: Mon, 20 Aug 2007 09:28:16 +0100 From: "Elwell, John" To: sip@ietf.org, Mahy Rohan , Cullen Jennings Message-id: <0D5F89FAC29E2C41B98A6A762007F5D026F312@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: Question on sip-outbound-10 Thread-Index: AcfjBA5Y2ck7AsPCT1mdTwpANagJ8g== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Subject: [Sip] Question on sip-outbound-10 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org In section 4.3 "Sending requests" it states: "The UA performs normal DNS resolution on the next hop URI (as described in RFC 3263 [4]) to find a protocol, IP address, and port. For protocols that don't use TLS, if the UA has an existing flow to this IP address, and port with the correct protocol, then the UA MUST use the existing connection. For TLS protocols, there MUST also be a match between the host production in the next hop and one of the URIs contained in the subjectAltName in the peer certificate. If the UA cannot use one of the existing flows, then it SHOULD form a new flow by sending a datagram or opening a new connection to the next hop, as appropriate for the transport protocol." This seems to imply that the UA simply sends the request on a new flow, yet there are no proxy procedures defined for receiving a non-register request on a new flow. So perhaps what is intended is that UA should register again using the new flow, and then send the request on the new flow. Whatever the intention, it seems some clarification is required. John _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Aug 20 08:22:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN6FI-00015l-2M; Mon, 20 Aug 2007 08:20:36 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IN6FG-0000zH-4d for sip-confirm+ok@megatron.ietf.org; Mon, 20 Aug 2007 08:20:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN6FF-0000z2-RM for sip@ietf.org; Mon, 20 Aug 2007 08:20:33 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IN6FE-0001xs-9Y for sip@ietf.org; Mon, 20 Aug 2007 08:20:33 -0400 Received: (qmail 28803 invoked by uid 0); 20 Aug 2007 12:20:31 -0000 Received: from 194.208.88.198 by www167.gmx.net with HTTP; Mon, 20 Aug 2007 14:20:30 +0200 (CEST) Content-Type: text/plain; charset="us-ascii" Date: Mon, 20 Aug 2007 14:20:30 +0200 From: "Guenther Sohler" Message-ID: <20070820122030.47830@gmx.net> MIME-Version: 1.0 To: sip@ietf.org X-Authenticated: #18210244 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 X-Provags-ID: V01U2FsdGVkX1+EeIpcxeyEpJzOBcVDjlX+UXJUHA5rimXpJ1LAvl fDOwTGUnlhIYzkY0UtMM7RDg8Gu4jZvLHnhA== Content-Transfer-Encoding: 7bit X-GMX-UID: QfKoIsZza0A7JaWyYDAz6eA/Njh6dE4U X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [Sip] Building RTP Data X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hallo Group, I have been working on my self-written SIP phone. My Program can successfully register in an SIP Proxy and INVITE somebody, and the partners telephone definietly rings! I do NOT know, if I correctly sent the ACK message to the OK message. I do not know at all * HOW to build up the bidirectional RTP voice connection * which ip addresses/ports to build/send * how to form the RTP Data packets(i dont know the specialities when building voice rtp packets) Does anybody have a sample implementation which is so tiny so i could read and understand it in one step ? What I finally want to build is a phone, which is able to listen to 2 Numbers at the same time! Can somebody guide me a little while ? -- GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Aug 20 12:53:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INAU2-0002ip-M1; Mon, 20 Aug 2007 12:52:06 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1INAU1-0002if-AU for sip-confirm+ok@megatron.ietf.org; Mon, 20 Aug 2007 12:52:05 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INAU0-0002iP-UV for sip@ietf.org; Mon, 20 Aug 2007 12:52:05 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1INAU0-0005DL-If for sip@ietf.org; Mon, 20 Aug 2007 12:52:04 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l7KGpx129543; Mon, 20 Aug 2007 16:52:00 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] Question on SIP Security considerations forfuture extensions Date: Mon, 20 Aug 2007 11:51:56 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF11AEBBF1@zrc2hxm0.corp.nortel.com> In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D223ADF9C@namail5.corp.adobe.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Question on SIP Security considerations forfuture extensions Thread-Index: AcffTKmtZp5wgwQXQZqFzWm3PtEJeQABDbqwAAOkmnAAbvha4AABDTkgAFscFCAAL27vQA== References: <9857.1187188777@cornfed.com><24CCCC428EFEA2469BF046DB3C7A8D22C6B3F3@namail5.corp.adobe.com><1ECE0EB50388174790F9694F77522CCF11A5C215@zrc2hxm0.corp.nortel.com><24CCCC428EFEA2469BF046DB3C7A8D223ADF97@namail5.corp.adobe.com> <1ECE0EB50388174790F9694F77522CCF11AEB3BC@zrc2hxm0.corp.nortel.com> <24CCCC428EFEA2469BF046DB3C7A8D223ADF9C@namail5.corp.adobe.com> From: "Francois Audet" To: "Henry Sinnreich" , , "Dean Willis" , "Richard Barnes" X-Spam-Score: 0.0 (/) X-Scan-Signature: e3ebaaff3b3539efaf29ef65eea2aded Cc: sip List , Sandy Murphy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1829727276==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1829727276== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7E34A.6BA2D882" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7E34A.6BA2D882 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I don't know, but my proxie's administrator is a lot more competent and trusworthy at setting up security properly than the average Joe on the internet. And I don't know what IT person would be stupid enough to trust its users. =20 Now, perhaps savvy users would want their own overlay of end-to-end security. That would be fine too. =20 ________________________________ From: Henry Sinnreich [mailto:hsinnrei@adobe.com]=20 Sent: Sunday, August 19, 2007 11:19 To: Audet, Francois (SC100:3055); fwmiller@cornfed.com; Dean Willis; Richard Barnes Cc: sip List; Sandy Murphy Subject: RE: [Sip] Question on SIP Security considerations forfuture extensions =09 =09 Francois, thanks for the note! =20 Sorry, since I had forgotten the possibility of the private network proxy being compromised: =20 - If it is a financial institution , it is an open door to steal money, - If it is a law enforcement organization, the agents will get killed, - SIPS for proxies is just as bad for any private network as well as for service providers and their customers. =20 From this perspective, any intermediary is either an invitation for some bad or outright dangerous behavior. =20 SIPS cannot obfuscate that the only security is e2e. Any intermediary is vulnerability. =20 Henry =20 =09 ________________________________ From: Francois Audet [mailto:audet@nortel.com]=20 Sent: Friday, August 17, 2007 5:41 PM To: Henry Sinnreich; fwmiller@cornfed.com; Dean Willis; Richard Barnes Cc: sip List; Sandy Murphy Subject: RE: [Sip] Question on SIP Security considerations forfuture extensions =20 Which service providers in the middle? :^) =20 All that is needed is an IP network. =20 =09 ________________________________ From: Henry Sinnreich [mailto:hsinnrei@adobe.com]=20 Sent: Friday, August 17, 2007 15:38 To: Audet, Francois (SC100:3055); fwmiller@cornfed.com; Dean Willis; Richard Barnes Cc: sip List; Sandy Murphy Subject: RE: [Sip] Question on SIP Security considerations forfuture extensions >There are many cases where I'd put a lot more trust in the proxies than "the guys at the end of the lines".=20 =20 The guys are you and me :-) If it's an enterprise network, then the enterprise network is the endpoint and we agree here. =20 Now what about all those service provider networks in the middle? =20 Henry =20 ------_=_NextPart_001_01C7E34A.6BA2D882 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I=20 don't know, but my proxie's administrator is a lot more competent = and=20 trusworthy at setting up security properly than the average Joe on the = internet.=20 And I don't know what IT person would be stupid enough to trust its=20 users.
 
Now,=20 perhaps savvy users would want their own overlay of end-to-end security. = That=20 would be fine too.
 

From: Henry Sinnreich=20 [mailto:hsinnrei@adobe.com]
Sent: Sunday, August 19, 2007=20 11:19
To: Audet, Francois (SC100:3055); = fwmiller@cornfed.com; Dean=20 Willis; Richard Barnes
Cc: sip List; Sandy = Murphy
Subject:=20 RE: [Sip] Question on SIP Security considerations forfuture=20 extensions

Francois, = thanks for=20 the note!

 

Sorry, = since I had=20 forgotten the possibility = of the=20 private network proxy being compromised:

 

-         =20 If it is=20 a financial institution , it is an open door to steal=20 money,

-         =20 If it is=20 a law enforcement organization, the=20 agents will get killed,

-         =20 SIPS for=20 proxies is just as bad for any private network as well as for service=20 providers and their customers.

 

From this=20 perspective, any intermediary is either an invitation for some bad or = outright=20 dangerous behavior.

 

SIPS cannot = obfuscate=20 that the only security is e2e. Any intermediary is=20 vulnerability.

 

Henry

 

From:=20 Francois Audet [mailto:audet@nortel.com]
Sent: Friday, August 17, 2007 = 5:41=20 PM
To: Henry = Sinnreich;=20 fwmiller@cornfed.com; Dean Willis; Richard Barnes
Cc: sip List; Sandy = Murphy
Subject: RE: [Sip] Question on = SIP=20 Security considerations forfuture=20 extensions

 

Which = service=20 providers in the middle? :^)

 

All that = is needed=20 is an IP network.

 

From: Henry=20 Sinnreich [mailto:hsinnrei@adobe.com]
Sent: Friday, August 17, 2007 = 15:38
To: Audet, = Francois=20 (SC100:3055); fwmiller@cornfed.com; Dean Willis; Richard = Barnes
Cc: sip List; Sandy = Murphy
Subject: RE: [Sip] Question = on SIP=20 Security considerations forfuture = extensions

>There are=20 many cases where I'd put a lot more trust in the proxies than "the = guys at=20 the end of the lines".

 

The guys = are you=20 and me J

If = it’s an=20 enterprise network, then the enterprise network is the endpoint and = we agree=20 here.

 

Now what = about all=20 those service provider networks in the = middle?

 

Henry

 

------_=_NextPart_001_01C7E34A.6BA2D882-- --===============1829727276== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1829727276==-- From sip-bounces@ietf.org Mon Aug 20 18:33:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INFmF-00077e-LS; Mon, 20 Aug 2007 18:31:15 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1INFmE-00077K-5R for sip-confirm+ok@megatron.ietf.org; Mon, 20 Aug 2007 18:31:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INFmD-00077C-SB for sip@ietf.org; Mon, 20 Aug 2007 18:31:13 -0400 Received: from nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net ([2001:470:1f03:267::2] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INFmC-0003bI-IJ for sip@ietf.org; Mon, 20 Aug 2007 18:31:13 -0400 Received: from [172.17.1.65] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l7KMUtVt041916 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 20 Aug 2007 17:31:07 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <456B9FDA-0E25-4257-B946-FE5291216F0C@nostrum.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: IETF SIP List From: Robert Sparks Date: Mon, 20 Aug 2007 17:31:07 -0500 X-Mailer: Apple Mail (2.752.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.91.1/4014/Mon Aug 20 14:33:05 2007 on shaman.nostrum.com X-Virus-Status: Clean X-Spam-Score: -1.4 (-) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [Sip] SIPit 21 registration is open. X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org SIPit 21 will take place November 5 through 9, 2007 in Beijing, China. The event will be hosted by the BII Group and the Beijing University of Posts and Telecommunications. Registration will be $575 US Dollars per participant. See http://www.sipit.net for more information and to register. See you in Beijing! RjS _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Aug 21 03:01:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INNiB-000055-Ur; Tue, 21 Aug 2007 02:59:35 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1INNiA-0008Jc-CM for sip-confirm+ok@megatron.ietf.org; Tue, 21 Aug 2007 02:59:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INNiA-0008HM-1D for sip@ietf.org; Tue, 21 Aug 2007 02:59:34 -0400 Received: from web8404.mail.in.yahoo.com ([202.43.219.152]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1INNi9-00026s-AS for sip@ietf.org; Tue, 21 Aug 2007 02:59:33 -0400 Received: (qmail 65062 invoked by uid 60001); 21 Aug 2007 06:59:30 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=qnnl8oYSAcY3rL07lR+O4UIrf9wpfp5hj62che50tMcIPv7D6Yq2i2IVpmNVitsw15VT18CSXe9EC5eRrN+RRrLgHnN6a176hdTZj6rf0RlHxQ443U4toHLL2HlsXMLsQ4qLRe6n+yWDtrUIxR0KNU8af8gAZ9/0EOWy9F5WcWE=; X-YMail-OSG: oUxQDJoVM1m1nADENuzSm5TDkbTWrqreoEI1mtl4ECaBsubDOtfEV4viVVWAaKolT5agdvbWapBwP79ujeYwPK95O24g8rV2Ci4Rhb3ppmGvKqcYiUo- Received: from [121.241.96.5] by web8404.mail.in.yahoo.com via HTTP; Tue, 21 Aug 2007 07:59:30 BST Date: Tue, 21 Aug 2007 07:59:30 +0100 (BST) From: atul garg To: sip@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <834312.64786.qm@web8404.mail.in.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [Sip] dtmf and fax for SIP/SDP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, I want to know the details how dtmf digits and fax information(t.38 as well as passthrough) are passed in sip(infact in sdp) part. Some call flows will definitely be value added for me. regards shivalk Unlimited freedom, unlimited storage. Get it now, on http://help.yahoo.com/l/in/yahoo/mail/yahoomail/tools/tools-08.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 sip-bounces@ietf.org Tue Aug 21 09:12:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INTV9-0001n0-C7; Tue, 21 Aug 2007 09:10:31 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1INTV7-0001gT-BZ for sip-confirm+ok@megatron.ietf.org; Tue, 21 Aug 2007 09:10:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INTV6-0001e5-SV for sip@ietf.org; Tue, 21 Aug 2007 09:10:28 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1INTV6-000562-Ch for sip@ietf.org; Tue, 21 Aug 2007 09:10:28 -0400 Received: (qmail invoked by alias); 21 Aug 2007 13:10:27 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp048) with SMTP; 21 Aug 2007 15:10:27 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/PKBtMPr/PqLzLU63SHa9cH8a/FViKVtUlNtUb1p nkBjQAFqUyvB+1 Message-ID: <46CAE441.8080504@gmx.net> Date: Tue, 21 Aug 2007 15:10:25 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: ECRIT Subject: [Sip] draft-rosenberg-sip-ua-loose-route-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dear SIP WG members, during the ECRIT meeting we learned that the SIP working group "rejected" the concept described in draft-rosenberg-sip-ua-loose-route-01.txt. Could someone please give us more information about this decision as it impacts the work we do in ECRIT? Ciao Hannes _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Aug 22 17:23:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INxd7-0005a5-0c; Wed, 22 Aug 2007 17:20:45 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1INxd6-0005a0-CV for sip-confirm+ok@megatron.ietf.org; Wed, 22 Aug 2007 17:20:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INxd6-0005Zr-2u for sip@ietf.org; Wed, 22 Aug 2007 17:20:44 -0400 Received: from m5tmail1.m5t.com ([207.134.65.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INxd4-0003lf-HR for sip@ietf.org; Wed, 22 Aug 2007 17:20:44 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 22 Aug 2007 17:20:56 -0400 Message-ID: <6EF4CC794ECF2B409390605FDEA901222A53C7@m5tmail1.m5t.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-sip-sips-05 comments Thread-Index: AcflAlPeaQAf1rfYTy2exFTXvXFabA== From: "Eric Tremblay" To: "Francois Audet" X-Spam-Score: 0.0 (/) X-Scan-Signature: 6907f330301e69261fa73bed91449a20 Cc: sip List Subject: [Sip] draft-ietf-sip-sips-05 comments X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0362962347==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0362962347== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7E502.4B7FA90E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7E502.4B7FA90E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Salut Francois, I had a look at draft-ietf-sip-sips-05 and have a few comments. Apologies if some of these comments were already discussed. Section 3.2, the following paragraph: Furthermore, consider the problem of using SIPS inside a dialog. If a@A sends a request to b@B using a SIPS Request-URI, then, according to [RFC3261 ]/8.1.1.8, "the Contact header field MUST contain a SIPS URI as well". This means that b@B, upon sending a new Request within the dialog (e.g., a BYE or re-INVITE), will have to use a SIPS URI. If there is no Record-Route entry, or if the last Record-Route entry consist of a SIPS URI, this implies that b@B must understand SIPS in the first place, and must also support TLS. If the last Record-Route entry however is a sip URI, then b would be able to send requests without using TLS (but b would still have to be able to handle SIPS schemes when parsing the message). In either case, the Request-URI in the request from b@B to B would be a SIPS URI. According to 3261, the uri type found in the route is ignored if the request-uri is sips: "Independent of which URI is used as input to the procedures of [4], if the Request-URI specifies a SIPS resource, the UAC MUST follow the procedures of [4] as if the input URI were a SIPS URI." RFC3261, section 8.1.2 If my thinking is right, this possibly creates an odd situation if the last hop proxy is a 2543 implementation that does not do loose routing (do these still exist?). My take is that if the proxy is a loose router and inserts a "sip" route, at the UA sending a request, the request-uri is a "sips" URI, then TLS should be used. However, if the proxy is not a loose router and inserts a "sip" route, then at the UA sending a request, the request-URI will no longer be a "sips" URI but a "sip" URI, thus allowing a different resolution mechanism. I wonder if this is worth mentionning in the draft. End of 3.2: SIPS URIs can even be used in other protocols that allow for including SIPS URIs (e.g., HTML). Since HTML is not really a protocol, I would suggest the following sentence: SIPS URIs can even be used in other protocols and documents that allow for including SIPS URIs (e.g., HTML). Section 3.4: When [I-D.ietf-sip-outbound ] is used, a transport parameter in a REGISTER message would normally be ignored since the existing I guess you mean "a transport parameter in a Contact-URI of a REGISTER message..."? Section 4.1.2: If all the Contact header fields in a REGISTER are SIPS, a SIPS AOR MUST be used by the UAC in the REGISTER. Which AOR are we talking abou? I guess you mean here: "..., a SIPS AOR MUST be used in the To header of the REGISTER". It is confusing as there are two AORs in a REGISTER. The To and From, which can potentially be different. Does this whole paragraph applies to both From and To AORs? Best Regards, EricT ------_=_NextPart_001_01C7E502.4B7FA90E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable draft-ietf-sip-sips-05 comments

Salut = Francois,

I had a look at = draft-ietf-sip-sips-05 and have a few comments. Apologies if some of = these comments were already discussed.

Section 3.2, the = following paragraph:
   Furthermore, consider the problem of using SIPS inside = a dialog.  If
   a@A sends a request to b@B using a SIPS Request-URI, then, = according
   to [RFC3261]/8.1.1.8, "the Contact header field MUST = contain a SIPS
   URI as well".  This means that b@B, upon sending = a new Request within
   the dialog (e.g., a BYE or re-INVITE), will have to use a = SIPS URI.
   If there is no Record-Route entry, or if the last = Record-Route entry
   consist of a SIPS URI, this implies that b@B must = understand SIPS in
   the first place, and must also support TLS.  If the = last Record-Route
   entry however is a sip URI, then b would be able to send = requests
   without using TLS (but b would still have to be able to = handle SIPS
   schemes when parsing the message).  In either case, = the Request-URI
   in the request from b@B to B would be a SIPS = URI.

According to 3261, = the uri type found in the route is ignored if the request-uri is = sips:

"Independent of which URI is used as input to the procedures = of [4], if the
 Request-URI specifies a SIPS resource, the UAC MUST follow = the
 procedures of [4] as if the input URI were a SIPS URI." = RFC3261, section 8.1.2

If my thinking is = right, this possibly creates an odd situation if the last hop proxy is a = 2543 implementation that does not do loose routing (do these still = exist?). My take is that if the proxy is a loose router and inserts a = "sip" route, at the UA sending a request, the request-uri is a = "sips" URI, then TLS should be used. However, if the proxy is = not a loose router and inserts a "sip" route, then at the UA = sending a request, the request-URI will no longer be a "sips" = URI but a "sip" URI, thus allowing a different resolution = mechanism. I wonder if this is worth mentionning in the = draft.

End of = 3.2:

 SIPS = URIs can even be used in
   other protocols that allow for including SIPS URIs (e.g., = HTML).

Since HTML is not = really a protocol, I would suggest the following sentence:

 SIPS = URIs can even be used in
   other protocols and documents that allow = for including SIPS URIs (e.g., HTML).


Section = 3.4:
   When [I-D.ietf-sip-outbound] is used, a = transport parameter in a
   REGISTER message would normally be ignored since the = existing
I guess you mean = "a transport parameter in a Contact-URI of a REGISTER = message..."?


Section = 4.1.2:

If all the = Contact header fields in a REGISTER are SIPS, a SIPS AOR
   MUST be used by the UAC in the REGISTER.

Which AOR are we = talking abou? I guess you mean here: "…, a SIPS AOR MUST be = used in the To header of the REGISTER". It is confusing as there = are two AORs in a REGISTER. The To and From, which can potentially be = different. Does this whole paragraph applies to both From and To = AORs?


Best = Regards,

EricT




------_=_NextPart_001_01C7E502.4B7FA90E-- --===============0362962347== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0362962347==-- From sip-bounces@ietf.org Wed Aug 22 17:42:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INxwk-0000w3-Tf; Wed, 22 Aug 2007 17:41:02 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1INxwj-0000u1-4q for sip-confirm+ok@megatron.ietf.org; Wed, 22 Aug 2007 17:41:01 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INxwi-0000tB-Od for sip@ietf.org; Wed, 22 Aug 2007 17:41:00 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1INxwi-0002SZ-97 for sip@ietf.org; Wed, 22 Aug 2007 17:41:00 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l7MLevD13699; Wed, 22 Aug 2007 21:40:57 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 22 Aug 2007 16:40:50 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF11B8653D@zrc2hxm0.corp.nortel.com> In-Reply-To: <6EF4CC794ECF2B409390605FDEA901222A53C7@m5tmail1.m5t.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-sip-sips-05 comments Thread-Index: AcflAlPeaQAf1rfYTy2exFTXvXFabAAAOxxQ References: <6EF4CC794ECF2B409390605FDEA901222A53C7@m5tmail1.m5t.com> From: "Francois Audet" To: "Eric Tremblay" X-Spam-Score: 0.0 (/) X-Scan-Signature: b360bd6cb019c35178e5cf9eeb747a5c Cc: sip List Subject: [Sip] RE: draft-ietf-sip-sips-05 comments X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0424846450==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0424846450== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7E505.1D4C8833" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7E505.1D4C8833 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Marci. See below. =20 ________________________________ From: Eric Tremblay [mailto:etremblay@m5t.com]=20 Sent: Wednesday, August 22, 2007 14:21 To: Audet, Francois (SC100:3055) Cc: sip List Subject: draft-ietf-sip-sips-05 comments =09 =09 Salut Francois,=20 I had a look at draft-ietf-sip-sips-05 and have a few comments. Apologies if some of these comments were already discussed. Section 3.2, the following paragraph:=20 Furthermore, consider the problem of using SIPS inside a dialog. If a@A sends a request to b@B using a SIPS Request-URI, then, according to [RFC3261 ]/8.1.1.8, "the Contact header field MUST contain a SIPS URI as well". This means that b@B, upon sending a new Request within the dialog (e.g., a BYE or re-INVITE), will have to use a SIPS URI. If there is no Record-Route entry, or if the last Record-Route entry consist of a SIPS URI, this implies that b@B must understand SIPS in the first place, and must also support TLS. If the last Record-Route entry however is a sip URI, then b would be able to send requests without using TLS (but b would still have to be able to handle SIPS schemes when parsing the message). In either case, the Request-URI in the request from b@B to B would be a SIPS URI.=20 According to 3261, the uri type found in the route is ignored if the request-uri is sips:=20 "Independent of which URI is used as input to the procedures of [4], if the=20 Request-URI specifies a SIPS resource, the UAC MUST follow the=20 procedures of [4] as if the input URI were a SIPS URI." RFC3261, section 8.1.2=20 If my thinking is right, this possibly creates an odd situation if the last hop proxy is a 2543 implementation that does not do loose routing (do these still exist?). My take is that if the proxy is a loose router and inserts a "sip" route, at the UA sending a request, the request-uri is a "sips" URI, then TLS should be used. However, if the proxy is not a loose router and inserts a "sip" route, then at the UA sending a request, the request-URI will no longer be a "sips" URI but a "sip" URI, thus allowing a different resolution mechanism. I wonder if this is worth mentionning in the draft.=20 My vote is that this is too arcane to discuss. =20 End of 3.2:=20 SIPS URIs can even be used in other protocols that allow for including SIPS URIs (e.g., HTML).=20 Since HTML is not really a protocol, I would suggest the following sentence:=20 SIPS URIs can even be used in other protocols and documents that allow for including SIPS URIs (e.g., HTML).=20 O k. Will fix.=20 Section 3.4:=20 When [I-D.ietf-sip-outbound ] is used, a transport parameter in a REGISTER message would normally be ignored since the existing =09 I guess you mean "a transport parameter in a Contact-URI of a REGISTER message..."?=20 Y es, but this paragraph is being removed from the current version.=20 Section 4.1.2:=20 If all the Contact header fields in a REGISTER are SIPS, a SIPS AOR MUST be used by the UAC in the REGISTER.=20 Which AOR are we talking abou? I guess you mean here: "..., a SIPS AOR MUST be used in the To header of the REGISTER". It is confusing as there are two AORs in a REGISTER. The To and From, which can potentially be different. Does this whole paragraph applies to both From and To AORs? Y es, to both. I'll fix.=20 Best Regards,=20 EricT=20 ------_=_NextPart_001_01C7E505.1D4C8833 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable draft-ietf-sip-sips-05 comments
Marci.=20 See below.
 

From: Eric Tremblay = [mailto:etremblay@m5t.com]=20
Sent: Wednesday, August 22, 2007 14:21
To: Audet, = Francois (SC100:3055)
Cc: sip List
Subject:=20 draft-ietf-sip-sips-05 comments

Salut = Francois,

I had a look at=20 draft-ietf-sip-sips-05 and have a few comments. Apologies if some of = these=20 comments were already discussed.

Section 3.2, the = following=20 paragraph:
   Furthermore, consider the problem of using SIPS = inside a=20 dialog.  If
   a@A sends a request to b@B using a = SIPS=20 Request-URI, then, according
   to [RFC3261]/8.1.1.8, "the = Contact header=20 field MUST contain a SIPS
   URI as well".  This = means that=20 b@B, upon sending a new Request within
   the dialog = (e.g., a BYE=20 or re-INVITE), will have to use a SIPS URI.
   If there = is no=20 Record-Route entry, or if the last Record-Route entry
   = consist=20 of a SIPS URI, this implies that b@B must understand SIPS = in
  =20 the first place, and must also support TLS.  If the last=20 Record-Route
   entry however is a sip URI, then b would = be able=20 to send requests
   without using TLS (but b would still = have to=20 be able to handle SIPS
   schemes when parsing the=20 message).  In either case, the Request-URI
   in the = request=20 from b@B to B would be a SIPS URI.

According to 3261, = the uri type=20 found in the route is ignored if the request-uri is = sips:

"Independent = of which URI=20 is used as input to the procedures of [4], if the =
 Request-URI = specifies a SIPS=20 resource, the UAC MUST follow the
 procedures of [4] as if the input = URI were a=20 SIPS URI." RFC3261, section 8.1.2

If my thinking = is right,=20 this possibly creates an odd situation if the last hop proxy is a 2543 = implementation that does not do loose routing (do these still exist?). = My take=20 is that if the proxy is a loose router and inserts a "sip" route, at = the UA=20 sending a request, the request-uri is a "sips" URI, then TLS should be = used.=20 However, if the proxy is not a loose router and inserts a "sip" route, = then at=20 the UA sending a request, the request-URI will no longer be a "sips" = URI but a=20 "sip" URI, thus allowing a different resolution mechanism. I wonder if = this is=20 worth mentionning in the draft. 

My vote is that this is = too arcane=20 to discuss.  

End of = 3.2:

 SIPS = URIs can even=20 be used in
   other protocols that allow for including = SIPS URIs=20 (e.g., HTML).

Since HTML is not = really a=20 protocol, I would suggest the following sentence:

 SIPS = URIs can even=20 be used in
   other protocols and documents that = allow for=20 including SIPS URIs (e.g., HTML).

O k.=20 Will fix. 

Section = 3.4:=20
   When=20 [I-D.ietf-sip-outbound] is used, a transport parameter in=20 a
   REGISTER message would normally be ignored since the = existing

I guess you mean "a transport parameter in a = Contact-URI of=20 a REGISTER message..."?

Y es, but = this paragraph=20 is being removed from the current=20 version. 

Section = 4.1.2:

If all the = Contact header=20 fields in a REGISTER are SIPS, a SIPS AOR
   MUST be used = by the=20 UAC in the REGISTER.

Which AOR are we = talking abou? I=20 guess you mean here: "…, a SIPS AOR MUST be used in the To = header of the=20 REGISTER". It is confusing as there are two AORs in a REGISTER. The To = and=20 From, which can potentially be different. Does this whole paragraph = applies to=20 both From and To AORs?

Y es, to both. I'll = fix. 

Best = Regards,

EricT=20




------_=_NextPart_001_01C7E505.1D4C8833-- --===============0424846450== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0424846450==-- From sip-bounces@ietf.org Wed Aug 22 17:49:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INy2o-0005ht-6a; Wed, 22 Aug 2007 17:47:18 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1INy2m-0005ho-CY for sip-confirm+ok@megatron.ietf.org; Wed, 22 Aug 2007 17:47:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INy2m-0005hg-33 for sip@ietf.org; Wed, 22 Aug 2007 17:47:16 -0400 Received: from n9a.bullet.mail.re3.yahoo.com ([68.142.236.47]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1INy2l-000499-JJ for sip@ietf.org; Wed, 22 Aug 2007 17:47:16 -0400 Received: from [68.142.237.89] by n9.bullet.re3.yahoo.com with NNFMP; 22 Aug 2007 21:47:15 -0000 Received: from [66.196.101.133] by t5.bullet.re3.yahoo.com with NNFMP; 22 Aug 2007 21:47:08 -0000 Received: from [127.0.0.1] by rrr4.mail.re1.yahoo.com with NNFMP; 22 Aug 2007 21:46:47 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 971317.96078.bm@rrr4.mail.re1.yahoo.com Received: (qmail 13124 invoked by uid 60001); 22 Aug 2007 21:46:45 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=r8JLYs/gK3JPQJZGKkyAIlReguf3/xTaUDcCnsq+9hkCAoc+1FaVgZFWnbYdvsxxCaYU5nrLsrmWhDF6ejpfNIfGDwCB6UkowzXDpv30LfN0kIl2YjdbYQuJZHD9R3/S81tAMRp1Jyj5G/AF2iFRcFc3WxeDHAU7vVBTsGVPZ2I=; X-YMail-OSG: AuCA9ZIVM1nMtFgS7krQ0TNf2EwL1JM9uccIKHc9L92DQ0ev9er7oMtOIkUSHy3FTvSUbrK0S3edsT2Q Received: from [71.6.1.67] by web44905.mail.sp1.yahoo.com via HTTP; Wed, 22 Aug 2007 14:46:45 PDT X-Mailer: YahooMailRC/651.48 YahooMailWebService/0.7.119 Date: Wed, 22 Aug 2007 14:46:45 -0700 (PDT) From: Samir Srivastava Subject: Re: [Sip] draft-ietf-sip-sips-05 comments To: Eric Tremblay , Francois Audet MIME-Version: 1.0 Message-ID: <789722.12431.qm@web44905.mail.sp1.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: sip List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0667728336==" Errors-To: sip-bounces@ietf.org --===============0667728336== Content-Type: multipart/alternative; boundary="0-2027888229-1187819205=:12431" --0-2027888229-1187819205=:12431 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi,=0A=0A>If my thinking is right, this possibly creates an odd situation i= f the last hop proxy is a 2543 >implementation that does not do loose routi= ng (do these still exist?). My take is that if the proxy is a >loose router= and inserts a "sip" route, at the UA sending a request, the request-uri is= a "sips" URI, >then TLS should be used. However, if the proxy is not a loo= se router and inserts a "sip" route, then at >the UA sending a request, the= request-URI will no longer be a "sips" URI but a "sip" URI, thus allowing = >a different resolution mechanism. I wonder if this is worth mentionning in= the draft.=0A=0A2543 didn't specify the SIPS at the first place. Good luck= with explaining the loose / strict routing with SIPS. When I was leaving m= y last employer, my understanding was that SIPS is LARGELY broken and it wi= ll clarify what SIPS provides. I am still digging into the threads what mad= e it to be still seen as STANDARD track. If it is having just politically c= orrect answers for this, then I am going to keep silence and enjoy.=0A=0AOn= the e2e side of SIP work, it works well in CS applications, where server t= akes care of fulfilling the regulatory compliance of recording, tracking et= c. How it will be filled in tunnel of UA to UA? Then why we need proxy and = further why is record routing introduced? Or we don't care about FCC and ot= her countries regulatory boides. =0A=0AMy 2 Cents.=0A=0ASamir=0A=0A=0A = =0A______________________________________________________________________= ______________=0ABe a better Heartthrob. Get better relationship answers fr= om someone who knows. Yahoo! Answers - Check it out. =0Ahttp://answers.yaho= o.com/dir/?link=3Dlist&sid=3D396545433 --0-2027888229-1187819205=:12431 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable
Hi,
=0A
 
=0A
= >If my thinking is right,= this possibly creates an odd situation if the last hop proxy is a 2543 >= ;implementation that does not do loose routing (do these still exist?). My = take is that if the proxy is a >loose router and inserts a "sip" route, = at the UA sending a request, the request-uri is a "sips" URI, >then TLS = should be used. However, if the proxy is not a loose router and inserts a "= sip" route, then at >the UA sending a request, the request-URI will no l= onger be a "sips" URI but a "sip" URI, thus allowing >a different resolu= tion mechanism. I wonder if this is worth mentionning in the draft.<= /SPAN>
=0A
=0A

 

=0A

2543 didn't specify the SIPS at the firs= t place. Good luck with explaining the loose / strict routing with SIPS. Wh= en I was leaving my last employer, my understanding was that SIPS is LARGEL= Y broken and it will clarify what SIPS provides. I am still digging into th= e threads what made it to be still seen as STANDARD track. If it is having = just politically correct answers for this, then I am going to keep silence = and enjoy.

=0A

 

=0A

On the e2e side of SIP work, it works w= ell in CS applications, where server takes care of fulfilling the= regulatory compliance of recording, tracking etc. How it will be filled in= tunnel of UA to UA? Then why we need proxy and further why is record routi= ng introduced? Or we don't care about FCC and other countries reg= ulatory boides.

=0A

 

=0A

My 2 Cents.

=0A

 

= =0A

Samir


=0A
Looking for a deal? Find great prices on flights and hotels with Yahoo! FareChase.<= /body> --0-2027888229-1187819205=:12431-- --===============0667728336== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0667728336==-- From sip-bounces@ietf.org Fri Aug 24 07:04:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOWvd-0002bS-Sr; Fri, 24 Aug 2007 07:02:13 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IOWvc-0002bH-JD for sip-confirm+ok@megatron.ietf.org; Fri, 24 Aug 2007 07:02:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOWvc-0002b9-9d for sip@ietf.org; Fri, 24 Aug 2007 07:02:12 -0400 Received: from cluster-b.mailcontrol.com ([217.68.146.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IOWva-0005ad-M9 for sip@ietf.org; Fri, 24 Aug 2007 07:02:12 -0400 Received: from GBNEWP0758M.eu.ubiquity.net ([62.172.205.164]) by rly04b.srv.mailcontrol.com (MailControl) with ESMTP id l7OB1Fnk023763 for ; Fri, 24 Aug 2007 12:02:04 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 24 Aug 2007 12:01:29 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Multiple 'm=' lines Thread-Index: AcfmPiBq7j3AQo4qR1uheBvkUASZzA== From: "Chris Boulton" To: X-Scanned-By: MailControl A-07-08-00 (www.mailcontrol.com) on 10.66.0.114 X-Spam-Score: -0.0 (/) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 Subject: [Sip] Multiple 'm=' lines X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1355184944==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1355184944== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7E63E.1FCDDF18" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7E63E.1FCDDF18 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, =20 Just looking for a clarification which seems to be escaping me. I apologise if it's a trivial question. I have a scenario where a UAS receives an INVITE which has multiple media lines (m=3D). I realise that if the UAS maybe does not wish/or support one of the media lines then it can simply set the port to 0 and respond in the positive. My question is: What SIP error response code could the UAS use in this situation if the call can not proceed? I am currently working on a draft in the MediaCtrl work group where it would be useful to signal to the UAC that the lack of support for a media line was the reason for failure. I found the following from Paul K: =20 If you are unwilling to do the audio without the video, and are also unwilling to accept a session with no media at all, then the error you want to use is probably 488. The 415 error means you don't understand the media type of a required mime body part in the message. =20 Sorry if I am missing something. Just wondering if there is something missing here. I suppose the 488 could contain a message body as per RFC 3261. I'm not sure a 'Warning' header does the trick. =20 Thanks. =20 Chris. =20 =20 Information contained in this e-mail and any attachments are intended for t= he use of the addressee only, and may contain confidential information of U= biquity Software Corporation. All unauthorized use, disclosure or distribut= ion is strictly prohibited. If you are not the addressee, please notify th= e sender immediately and destroy all copies of this email. Ubiquity Softwar= e Corporation plc, a company registered under the laws of England and Wales= , Registration 2719723, registered offices at Eastern Business Park, Buildi= ng 3, Wern Fawr Lane, St. Mellons, Cardiff CF3 5EA, Wales, United Kingdom. ------_=_NextPart_001_01C7E63E.1FCDDF18 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 

Just looking for a clarification which seems to be escaping me.  I apologise if it’s a trivial question.  I ha= ve a scenario where a UAS receives an INVITE which has multiple media lines (m= =3D).  I realise that if the UAS maybe does not wish/or support one of the media lin= es then it can simply set the port to 0 and respond in the positive.  My question is: What SIP error response code could the UAS use in this situati= on if the call can not proceed?  I am currently working on a draft in the= MediaCtrl work group where it would be useful to signal to the UAC that the lack of support for a media line was the reason for failure.  I found the following from Paul K:

 

If you are unwilling t= o do the audio without the video, and are also unwilling to accept a session wit= h no media at all, then the error you want to use is probably 488. The 415 error means you don't understand the media type of a required mime body part in t= he message.

 

Sorry if I am mis= sing something. Just wondering if there is something missing here.  I suppo= se the 488 could contain a message body as per RFC 3261.  I’m not s= ure a ‘Warning’ header does the trick.

 

Thanks.

 

Chris.

 

 



Information contained in this e-mail and any attachments are intended fo= r the use of the addressee only, and may contain confidential information o= f Ubiquity Software Corporation. All unauthorized use, disclosure or distri= bution is strictly prohibited. If you are not the addressee, please notify = the sender immediately and destroy all copies of this email. Ubiquity Softw= are Corporation plc, a company registered under the laws of England and Wal= es, Registration 2719723, registered offices at Eastern Business Park, Buil= ding 3, Wern Fawr Lane, St. Mellons, Cardiff CF3 5EA, Wales, United Kingdom= .

 ------_=_NextPart_001_01C7E63E.1FCDDF18-- --===============1355184944== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1355184944==-- From sip-bounces@ietf.org Fri Aug 24 09:03:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOYmp-0006vs-BX; Fri, 24 Aug 2007 09:01:15 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IOYmn-0006vm-TS for sip-confirm+ok@megatron.ietf.org; Fri, 24 Aug 2007 09:01:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOYmn-0006ve-Im for sip@ietf.org; Fri, 24 Aug 2007 09:01:13 -0400 Received: from tcmail23.telekom.de ([217.6.95.237]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IOYmm-0002n7-VM for sip@ietf.org; Fri, 24 Aug 2007 09:01:13 -0400 Received: from S4DE9JSAANO.ost.t-com.de (S4DE9JSAANO.ost.t-com.de [10.125.177.105]) by tcmail21.telekom.de with ESMTP for sip@ietf.org; Fri, 24 Aug 2007 15:00:59 +0200 Received: from S4DE9JSAAMW.ost.t-com.de ([10.125.177.114]) by S4DE9JSAANO.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 24 Aug 2007 15:00:59 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 24 Aug 2007 15:00:58 +0200 Message-Id: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Extension of conference procedures Thread-Index: AcfmRaSVvP2Xwhw6S1+pjPclzKlS+gACApoA From: "Alexeitsev, D" To: X-OriginalArrivalTime: 24 Aug 2007 13:00:59.0140 (UTC) FILETIME=[D0FC9440:01C7E64E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Subject: [Sip] Extension of conference procedures X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I'd like to discuss the extension of the current conference procedures with the following functionality. 3GPP conference specifications are basing generally on the Conferencing Framework (RFC 4353) and for one possibility of inviting users to the confrence on draft-ietf-sip-uri-list-conferencing. =20 Using the conferencing framework, the following situation can occur when a user is invited to an ad-hoc conference: User A is in a dialog with user B, and decides to start a conference, for example using an INVITE request to the focus which includes a URI list with the URIs of the users which shall be added to the conference, incl. B. So when the INVITE request from the focus arrives at B, he is still in the original dialog with A, and so it depends on B if he accepts the 2nd INVITE and the conference can be established. At the last 3GPP CT1 meeting the idea of transporting dialog identifiers together with the URIs was introduced to solve this problem. Basing on the idea that the procedures at the conference server are extended in that way, that the conference server is aware of already established dialogs, the focus then has the possibility to send re-INVITES in the indicated dialogs and connect the media from the invited users to the conference bridge. In the URI list the dialogs can be indicated using the "?" mechanism according to subclause 19.1.1 of RFC 3261. Following example shows the proposed mechanism: INVITE Conference To: Conference From: A Require: recipient-list-invite=20 Content-Type: application/resource-lists+xml=20 Content-Disposition: recipient-list =20 =20 =20 =20 =20 Greetings, Denis Alexeitsev _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Aug 24 11:08:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOaja-0004b9-Rl; Fri, 24 Aug 2007 11:06:02 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IOajZ-0004aq-5E for sip-confirm+ok@megatron.ietf.org; Fri, 24 Aug 2007 11:06:01 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOajY-0004ah-Qn for sip@ietf.org; Fri, 24 Aug 2007 11:06:00 -0400 Received: from smtp2.versatel.nl ([62.58.50.89]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IOajY-0006Hm-1J for sip@ietf.org; Fri, 24 Aug 2007 11:06:00 -0400 Received: (qmail 28761 invoked by uid 0); 24 Aug 2007 15:05:57 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER) ([87.212.11.198]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 24 Aug 2007 15:05:57 -0000 Message-ID: <005801c7e660$43786100$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "Alexeitsev, D" , References: Subject: Re: [Sip] Extension of conference procedures Date: Fri, 24 Aug 2007 17:05:52 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Denis, If I understand your scenario, "focus" is a third party separate from A and B, right? (e.g. a conference server) In that case the focus is not a party in the A-B dialog, and would need more than Call-ID, From and To to be able to construct a reINVITE that B would accept as coming from A (e.g. CSeq). In any case, this looks like a very inelegant, hacked solution (as the conference server is basically spoofing) RFC4579 section 5.10 provides some insipration, as well as http://www.ietf.org/internet-drafts/draft-ietf-sipping-service-examples-13.txt scenario 2.5 For example, A could include a 'Replaces' header in the URI it includes in its conference URI list. Then the conference server would send a new (out-of-dialog) INVITE to B containing this Replaces header, and B would know that it is associated with the dialog it has with A (and can replace it, without ringing if the UA is constructed like that) The conference server should probably also include a Referred-By containing A's AoR, either automatically (i.e. copy from From header in INVITE) or included by A in the URI (former is better) Regards, Jeroen Alexeitsev, D wrote: > I'd like to discuss the extension of the current conference procedures > with the following functionality. > > 3GPP conference specifications are basing generally on the > Conferencing Framework (RFC 4353) and for one possibility of inviting > users to the confrence on draft-ietf-sip-uri-list-conferencing. > > Using the conferencing framework, the following situation can occur > when a user is invited to an ad-hoc conference: > User A is in a dialog with user B, and decides to start a conference, > for example using an INVITE request to the focus which includes a URI > list with the URIs of the users which shall be added to the > conference, incl. B. So when the INVITE request from the focus > arrives at B, he is still in the original dialog with A, and so it > depends on B if he accepts the 2nd INVITE and the conference can be > established. > > At the last 3GPP CT1 meeting the idea of transporting dialog > identifiers together with the URIs was introduced to solve this > problem. Basing on the idea that the procedures at the conference > server are extended in that way, that the conference server is aware > of already established dialogs, the focus then has the possibility to > send re-INVITES in the indicated dialogs and connect the media from > the invited users to the conference bridge. > In the URI list the dialogs can be indicated using the "?" mechanism > according to subclause 19.1.1 of RFC 3261. > > Following example shows the proposed mechanism: > > INVITE Conference > To: Conference > From: A > Require: recipient-list-invite > > Content-Type: application/resource-lists+xml > Content-Disposition: recipient-list > > > xmlns:cp="urn:ietf:params:xml:ns:copyControl"> > > cp:copyControl="to"/> > cp:copyControl="to"/> > > > > Greetings, > Denis Alexeitsev > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Aug 24 12:04:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IObca-0008In-Ve; Fri, 24 Aug 2007 12:02:52 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IObca-0008Id-5H for sip-confirm+ok@megatron.ietf.org; Fri, 24 Aug 2007 12:02:52 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IObcZ-0008IG-KG for sip@ietf.org; Fri, 24 Aug 2007 12:02:51 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IObcY-0007s1-In for sip@ietf.org; Fri, 24 Aug 2007 12:02:51 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 24 Aug 2007 09:02:50 -0700 X-IronPort-AV: i="4.19,305,1183359600"; d="scan'208"; a="205971645:sNHT58462605" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l7OG2np6019198; Fri, 24 Aug 2007 09:02:49 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l7OG2npC006500; Fri, 24 Aug 2007 16:02:49 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Aug 2007 09:02:49 -0700 Received: from [128.107.103.125] ([128.107.103.125]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Aug 2007 09:02:49 -0700 Message-ID: <46CF0139.2040402@cisco.com> Date: Fri, 24 Aug 2007 12:03:05 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Aki Niemi Subject: Re: [Sip] comments on draft-ietf-sip-subnot-etags-00 References: <46A60E86.7030209@cisco.com> <46A62A78.1030200@nokia.com> In-Reply-To: <46A62A78.1030200@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Aug 2007 16:02:49.0525 (UTC) FILETIME=[38153650:01C7E668] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7057; t=1187971369; x=1188835369; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Sip]=20comments=20on=20draft-ietf-sip-subnot-etags-0 0 |Sender:=20; bh=ylJsVO170OZZuBFLM9y7nuGNVXhdebrhVqSLP+QkX3A=; b=Z4rmVyYfsSDnVP2puOHvGMyjr5JpNdOhnzUmaLAT2eUSDtfkwVz3K0J0n00ByDiPObjqn3jN tEj9WfdhniZVQVX8X2OBf6ZbDocNAasn36VT5rqGP7PZLlds0BtUznrm/6Q3ASpsJxfFs7/9aw WOzag55/Tbp3MuSbu1wGr1BFE=; Authentication-Results: sj-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org sorry for the delay. More below: Aki Niemi wrote: > Hi Jonathan, > >>> NOTIFY request. The entity tag is unique for that particular >>> resource and event notification. >> You should clarify what it means to be unique for a resource *and* >> event notification. So this means if I fetch the resource with http >> it has a differnet entity tag? > > My working copy says: > > The entity-tag MUST be unique across all versions of all entities for > a resource. > > I think we should also add "...and event package" just to be clear. I'm not sure what that means. You mean, if the same object is delivered in multiple event packages? When does that happen? > > I think we should also add that the subscriber should never assume > that the entity-tags are shared between notification and, say, SIP > event publication or HTTP. Right, that would be a good clarification. The other issue is you need to be clear about what you mean by 'resource' in your text above. For example if two SIP URI are different but happen to resolve to the same user, is that the same resource and would the etags be the same? (I think no). > >>> The two types of conditions available for a SUBSCRIBE are a >>> Suppress- Body-If-Match and a Suppress-Notify-If-Match; each of >>> these header fields contains the last entity-tag seen by the >>> subscriber. If the condition evaluates to true, the first of >>> these conditions will instruct the notifier to suppress the body >>> of the next notification and the second the entire notification. >>> >> Is there a reason we need both? Could we just have >> Suppress-Body-If-Match and if the subscription state is anything >> besides active and the subscription duration anything different >> than the Expires in the request, a NOTIFY is sent without a body? > > This would be a very drastic simplification, and it would not work > for polling, which was one of the original use-cases. Well, if you change the rule to be that, no NOTIFY is sent at all if: 1. the subscription duration in the SUBSCRIBE was zero and the etags matched, 2. the subscription duration in the SUBSCRIBE is non-zero, the etags match, and the resulting subscription has a duration matching the expires time with a state of active i.e., if it 'works as asked', then there is no NOTIFY. > > In fact, another way of doing this is to *always* use > Suppress-Body-If-Match: * in refreshes, according to the current > draft. That will still send the NOTIFY, so I'm confused how that provides a single mechanism for covering body and NOTIFY suppression.. > > I still believe the ability to suppress the entire NOTIFY is a > valuable feature, but as Rohan pointed out, it may also have > backwards compatibility issues, as it is a more substantial change to > RFC3265. I am agreeing that suppressing the entire NOTIFY is a good feature. But you have to do it in cases where you are sure that the state is known to the client. > >>> There is also a wildcard entity-tag with a special value of "*" >>> that always matches. >> what is the use-case for this? >> >> * I think you can actually implement this without option tags. The >> presence of the Suppress-* header fields basically plays that role. >> Supported is needed if the UA is not asking for some feature in a >> request, but merely saying, its supported. > > The only reason it's there, actually, is for the subscriber to give a > hint to the notifier, that etags are supported. This is when a > SUBSCRIBE has no Suppress-*, i.e., it's the very first SUBSCRIBE. > > However, I agree it adds very, very little value. I'll remove it. Great, thanks. > >>> uppress-Body-If-Match: if this condition evaluates to true, the >>> notifier is instructed to suppress (i.e., remove) the body of the >>> first NOTIFY request following the SUBSCRIBE. If false, the >>> notifier follows the default behavior. >> Its not 'first' - its any subsequet NOTIFY whose body, had this >> specification not be in use, would contain the resource with that >> entity tag. > > Ahh, I see. Now I understand why Adam was seeing the overlap with > notify-pause. > > It's 'first' intentionally. The mechanism is supposed to only affect > the very NOTIFY that the SUBSCRIBE is about to generate. It could be > 'any subsequent' but would there be any reason that a notifier > replays notifications if there's no change? Sure, because of subscription state changes. > >>> Suppress-Notify-If-Match: if this condition evaluates to true, >>> the notifier is instructed to suppress (i.e., block) the entire >>> first NOTIFY request following the SUBSCRIBE, and instead send a >>> 204 (No Notification) response. If false, the notifier again >>> follows the default behavior. >> I don't think we need a new response code. What is the >> justification? > > It is to enable the subscriber to destroy its handle as soon as the > 204 is received, instead of keeping it indefinitely in case there is > a NOTIFY forthcoming (it may not ever come). OK, that needs to be clearer. > >> * Section 4 needs to cover handling of the response to SUBSCRIBE >> (what happens when a 204 comes), and NOTIFY (store entity tag). >> Also needs to handle what to do in the case where the notifier >> doesn't support the mechanism. > > I can add text to the numbered lists of 4.x sections about storing > the entity tags. The very last bullets of each of 4.x sections do > talk about what the subscriber is to do with the 204. Should there be > a sub-section in section 4 that has normative text on these though? Yes. Generally the right structure for extensions is something like: UA Behavior Sending Requests Processing Responses and you are mostly covering the sending of requests. > >>> A notifier MUST generate entity tags for each resource it is >>> responsible for. >>> >>> The views might correspond to different groups of users that have >>> varying levels of access rights to the resource state, or to >>> subscribers that have modified their subscription using event >>> notification filtering [11]. For example, in presence [6] >>> watchers may get different levels of accuracy in geolocation >>> information, based on the presentity's privacy settings. >> What do views have to do with this? > > Here view == entity, but clearly the view should be in double quotes, > as it's not a term that is clearly defined anywhere. However, The > next version will have section 5.1. strengthened to make this part of > the model (hopefully) clear. > OK. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Aug 24 12:29:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOc0b-0000tt-CO; Fri, 24 Aug 2007 12:27:41 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IOc0a-0000tn-Hd for sip-confirm+ok@megatron.ietf.org; Fri, 24 Aug 2007 12:27:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOc0a-0000tf-8C for sip@ietf.org; Fri, 24 Aug 2007 12:27:40 -0400 Received: from fk-out-0910.google.com ([209.85.128.191]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IOc0Z-0005tR-0R for sip@ietf.org; Fri, 24 Aug 2007 12:27:40 -0400 Received: by fk-out-0910.google.com with SMTP id z23so715114fkz for ; Fri, 24 Aug 2007 09:27:38 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=MgPb0aj80su6HNCaW7KoUmF+tBC+XSI3qXNYwuP1XXQ6kRPnaxZuokYdDNCsqXi2rb5x4u2kgpCCIf47Qm9sp9Kg8zEjIXK2GNlEIBUMXZuJAWJaXypuX+0IhvnPn0NmAcaP5+90TvVUkukOGokAs1eu+Ubmggl6I9GQiPWoh6k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=k6JNmpv1aBBCXPioIRiVpRlXh1K/rVT2niZOdpZcKkgDQxTeCUNv/BOMVT7tZSJYk2FlUz8RIvNzh9G0uxphccWZcAl2nZHE+J3fUByRLk7qnIMCBpckA1MrHN/3UGfBbXa0UnVmz5W7boVj9XJTg0etgSi0pWmosyixFAiFzk4= Received: by 10.82.111.8 with SMTP id j8mr7123542buc.1187972857808; Fri, 24 Aug 2007 09:27:37 -0700 (PDT) Received: by 10.82.178.8 with HTTP; Fri, 24 Aug 2007 09:27:37 -0700 (PDT) Message-ID: <18aed6e70708240927x5bf234f6q9dfd2ec5b7a7b8ce@mail.gmail.com> Date: Fri, 24 Aug 2007 21:57:37 +0530 From: "Arnab Biswas" To: sip@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [Sip] Challenges in SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1576257817==" Errors-To: sip-bounces@ietf.org --===============1576257817== Content-Type: multipart/alternative; boundary="----=_Part_177923_9624822.1187972857789" ------=_Part_177923_9624822.1187972857789 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, Sorry for posting such a question here. But I feel this is the best place to raise the question: What are the major challenges for SIP especially in the context of IP Multimedia Subsystem? Thanks, Arnab ------=_Part_177923_9624822.1187972857789 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi,
 
Sorry for posting such a question here.
But I feel this is the best place to raise the question: What are the major challenges for SIP especially in the context of IP Multimedia Subsystem?
 
Thanks,
Arnab
------=_Part_177923_9624822.1187972857789-- --===============1576257817== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1576257817==-- From sip-bounces@ietf.org Fri Aug 24 14:17:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOdh1-0001Dh-Uj; Fri, 24 Aug 2007 14:15:35 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IOdh0-00019i-4n for sip-confirm+ok@megatron.ietf.org; Fri, 24 Aug 2007 14:15:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOdgz-00017s-Kq; Fri, 24 Aug 2007 14:15:33 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IOdgz-0004iN-1k; Fri, 24 Aug 2007 14:15:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 9410E175A5; Fri, 24 Aug 2007 18:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IOdgT-0003ii-OR; Fri, 24 Aug 2007 14:15:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 24 Aug 2007 14:15:01 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-session-policy-framework-02.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org --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 : A Framework for Session Initiation Protocol (SIP) Session Policies Author(s) : V. Hilt, et al. Filename : draft-ietf-sip-session-policy-framework-02.txt Pages : 33 Date : 2007-8-24 Proxy servers play a central role as an intermediary in the Session Initiation Protocol (SIP) as they define and impact policies on call routing, rendezvous, and other call features. This document specifies a framework for SIP session policies that provides a standard mechanism by which a proxy can define or influence policies on sessions, such as the codecs or media types to be used. It defines a model, an overall architecture and new protocol mechanisms for session policies. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-session-policy-framework-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-session-policy-framework-02.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-session-policy-framework-02.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: <2007-8-24134601.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-session-policy-framework-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-session-policy-framework-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-8-24134601.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Fri Aug 24 16:17:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOfZ8-000714-BM; Fri, 24 Aug 2007 16:15:34 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IOfZ7-00070t-AS for sip-confirm+ok@megatron.ietf.org; Fri, 24 Aug 2007 16:15:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOfZ6-00070l-Vs; Fri, 24 Aug 2007 16:15:33 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IOfZ6-0001XJ-Jh; Fri, 24 Aug 2007 16:15:32 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 862A32AC25; Fri, 24 Aug 2007 20:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IOfYc-0007IP-AH; Fri, 24 Aug 2007 16:15:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 24 Aug 2007 16:15:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-sips-06.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org --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 use of the SIPS URI Scheme in the Session Initiation Protocol (SIP) Author(s) : F. Audet Filename : draft-ietf-sip-sips-06.txt Pages : 54 Date : 2007-8-24 This document provides clarifications and guidelines concerning the use of the SIPS URI scheme in the Session Initiation Protocol (SIP). It also makes normative changes to SIP. This document also provides a discussion of possible future steps in specification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-sips-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-sips-06.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-sips-06.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: <2007-8-24150609.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-sips-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-sips-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-8-24150609.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Sat Aug 25 23:24:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IP8hc-00014N-9y; Sat, 25 Aug 2007 23:22:16 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IP8ha-00014I-8K for sip-confirm+ok@megatron.ietf.org; Sat, 25 Aug 2007 23:22:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IP8hZ-00014A-Nu for sip@ietf.org; Sat, 25 Aug 2007 23:22:13 -0400 Received: from sccrmhc12.comcast.net ([204.127.200.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IP8hY-0000H0-JA for sip@ietf.org; Sat, 25 Aug 2007 23:22:13 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (sccrmhc12) with ESMTP id <2007082603221201200ds32qe>; Sun, 26 Aug 2007 03:22:12 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l7Q3MBFg029160 for ; Sat, 25 Aug 2007 23:22:11 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l7Q3MBoM029156; Sat, 25 Aug 2007 23:22:11 -0400 Date: Sat, 25 Aug 2007 23:22:11 -0400 Message-Id: <200708260322.l7Q3MBoM029156@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: (cboulton@ubiquity.net) Subject: Re: [Sip] Multiple 'm=' lines References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: "Chris Boulton" Just looking for a clarification which seems to be escaping me. I apologise if it's a trivial question. I have a scenario where a UAS receives an INVITE which has multiple media lines (m=3D). I realise that if the UAS maybe does not wish/or support one of the media lines then it can simply set the port to 0 and respond in the positive. My question is: What SIP error response code could the UAS use in this situation if the call can not proceed? I am currently working on a draft in the MediaCtrl work group where it would be useful to signal to the UAC that the lack of support for a media line was the reason for failure. I found the following from Paul K: If you are unwilling to do the audio without the video, and are also unwilling to accept a session with no media at all, then the error you want to use is probably 488. The 415 error means you don't understand the media type of a required mime body part in the message. Sorry if I am missing something. Just wondering if there is something missing here. I suppose the 488 could contain a message body as per RFC 3261. I'm not sure a 'Warning' header does the trick. You haven't explained what your problem is. In regard to Paul's answer, he is correct. The 415 response means "I did not understand the MIME media type of the body (carried in the Content-Type header)". The 488 response means "I understood the media description (the body), but it was unacceptable to me for establishing a dialog." In regard to multiple m- lines, you aren't thinking about the question correctly. The correct approach is to examine all the m- lines, and from that set, ignore any that describe media types that the UA is unable or unwilling to process. Then examine those that remain, and see if among them are enough media that the UA can establish communication. If the answer is yes, accept the call. If the answer is no (probably because no m- lines remain), send a 488 response. In general, you don't reject a call because one m- line is *not* something you can deal with, you reject a call because there is *no* m- line that *is* something you can deal with. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Aug 26 08:45:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPHSD-0007nS-Fn; Sun, 26 Aug 2007 08:42:57 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IPHSC-0007nM-7m for sip-confirm+ok@megatron.ietf.org; Sun, 26 Aug 2007 08:42:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPHSB-0007lR-TO for sip@ietf.org; Sun, 26 Aug 2007 08:42:55 -0400 Received: from tcmail23.telekom.de ([217.6.95.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IPHSA-0008RV-7J for sip@ietf.org; Sun, 26 Aug 2007 08:42:55 -0400 Received: from S4DE9JSAANM.ost.t-com.de (S4DE9JSAANM.ost.t-com.de [10.125.177.122]) by tcmail21.telekom.de with ESMTP; Sun, 26 Aug 2007 14:42:48 +0200 Received: from S4DE9JSAAHW.ost.t-com.de ([10.125.177.160]) by S4DE9JSAANM.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Sun, 26 Aug 2007 14:42:48 +0200 Subject: AW: [Sip] Extension of conference procedures MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 26 Aug 2007 14:42:47 +0200 Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-Id: In-Reply-To: <005801c7e660$43786100$0601a8c0@BEMBUSTER> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Extension of conference procedures Thread-Index: AcfmYJPlRHlq0SkwQK2m5Mktd5IqOwBd3TCA From: "Huelsemann, Martin" To: X-OriginalArrivalTime: 26 Aug 2007 12:42:48.0138 (UTC) FILETIME=[9B8662A0:01C7E7DE] X-Spam-Score: -1.0 (-) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Jeroen, the usage of the Replaces header is of course the best solution, it's = also described in the regarding 3GPP conferencing spec.=20 The disadvantage of the usage of the Repaces header is, that it puts = requirements on the UE of the invited user, it would have to support RFC = 3891. And if it supports, it really would have to accept the 2nd INVITE, = which is not mandatory according to RFC 3891 I think. Anyway what is needed in addition is a solution how also very simple = terminals (e. g. only supporting RFC 3261) can be invited to an ad-hoc = conference, whithout having to say to the invited user to please hang up = because there will be a call from the focus shortly.=20 Re-using an already established dialog at least at the first glance = seems to be a simply and invited UE independent solution. And as this = re-INVITE it wanted by at least one of the involved user, I would more = compare it to some kind of triggered 3rd party call control than to = spoofing. Of course as you said it would have to be made clear that the focus is = able to collect all the information needed for sending re-INVITEs = (proposed "?" mechanism usage, dialog event package, etc.). Regards, Martin > -----Urspr=FCngliche Nachricht----- > Von: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl]=20 > Gesendet: Freitag, 24. August 2007 17:06 > An: Alexeitsev, Denis; sip@ietf.org > Betreff: Re: [Sip] Extension of conference procedures >=20 >=20 > Denis, >=20 > If I understand your scenario, "focus" is a third party=20 > separate from A and=20 > B, right? (e.g. a conference server) >=20 > In that case the focus is not a party in the A-B dialog, and=20 > would need more=20 > than Call-ID, From and To to be able to construct a reINVITE=20 > that B would=20 > accept as coming from A (e.g. CSeq). In any case, this looks=20 > like a very=20 > inelegant, hacked solution (as the conference server is=20 > basically spoofing) >=20 > RFC4579 section 5.10 provides some insipration, as well as=20 > http://www.ietf.org/internet-drafts/draft-ietf-sipping-service > -examples-13.txt=20 > scenario 2.5 >=20 > For example, A could include a 'Replaces' header in the URI=20 > it includes in=20 > its conference URI list. Then the conference server would send a new=20 > (out-of-dialog) INVITE to B containing this Replaces header,=20 > and B would=20 > know that it is associated with the dialog it has with A (and=20 > can replace=20 > it, without ringing if the UA is constructed like that) >=20 > The conference server should probably also include a=20 > Referred-By containing=20 > A's AoR, either automatically (i.e. copy from From header in=20 > INVITE) or=20 > included by A in the URI (former is better) >=20 > Regards, > Jeroen >=20 > Alexeitsev, D wrote: > > I'd like to discuss the extension of the current conference=20 > procedures > > with the following functionality. > > > > 3GPP conference specifications are basing generally on the > > Conferencing Framework (RFC 4353) and for one possibility=20 > of inviting > > users to the confrence on draft-ietf-sip-uri-list-conferencing. > > > > Using the conferencing framework, the following situation can occur > > when a user is invited to an ad-hoc conference: > > User A is in a dialog with user B, and decides to start a=20 > conference, > > for example using an INVITE request to the focus which=20 > includes a URI > > list with the URIs of the users which shall be added to the > > conference, incl. B. So when the INVITE request from the focus > > arrives at B, he is still in the original dialog with A, and so it > > depends on B if he accepts the 2nd INVITE and the conference can be > > established. > > > > At the last 3GPP CT1 meeting the idea of transporting dialog > > identifiers together with the URIs was introduced to solve this > > problem. Basing on the idea that the procedures at the conference > > server are extended in that way, that the conference server is aware > > of already established dialogs, the focus then has the=20 > possibility to > > send re-INVITES in the indicated dialogs and connect the media from > > the invited users to the conference bridge. > > In the URI list the dialogs can be indicated using the "?" mechanism > > according to subclause 19.1.1 of RFC 3261. > > > > Following example shows the proposed mechanism: > > > > INVITE Conference > > To: Conference > > From: A > > Require: recipient-list-invite > > > > Content-Type: application/resource-lists+xml > > Content-Disposition: recipient-list > > > > > > > xmlns:cp=3D"urn:ietf:params:xml:ns:copyControl"> > > > > > cp:copyControl=3D"to"/> > > > cp:copyControl=3D"to"/> > > > > > > > > Greetings, > > Denis Alexeitsev > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip=20 >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Aug 26 09:25:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPI5y-00058J-3S; Sun, 26 Aug 2007 09:24:02 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IPI5w-000585-Ft for sip-confirm+ok@megatron.ietf.org; Sun, 26 Aug 2007 09:24:00 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPI5w-00057m-4u for sip@ietf.org; Sun, 26 Aug 2007 09:24:00 -0400 Received: from smtp1.versatel.nl ([62.58.50.88]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IPI5v-0001ei-17 for sip@ietf.org; Sun, 26 Aug 2007 09:23:59 -0400 Received: (qmail 31028 invoked by uid 0); 26 Aug 2007 13:25:09 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO [192.168.1.6]) ([87.212.11.198]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 26 Aug 2007 13:25:09 -0000 Message-ID: <46D17EE5.8020808@zonnet.nl> Date: Sun, 26 Aug 2007 15:23:49 +0200 From: Jeroen van Bemmel User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Huelsemann, Martin" Subject: Re: AW: [Sip] Extension of conference procedures References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Martin, Now it becomes more clear. So the requirement is to enable a scenario where a regular call is transformed into a conference call, assuming that the invitee only has a "pure RFC3261" client. More specifically: - to get a smooth user experience, the scenario must not cause the invitee's phone to ring, and/or ask the invitee for permission (acceptance is assumed to be implied) What if A would send the reINVITE (or UPDATE) itself, while filling in the SDP according to the media provided by the conference server (i.e. use codecs, media ports as received from the focus)? (trying to get the requirements more clear here) In practice, it may still be a challenge to get such "very simple terminals" to properly handle a change of media (i.e. new destination ip/port for sending, new source ip/port and RTP src id, and possibly different codecs) Regards, Jeroen Huelsemann, Martin wrote: > Hi Jeroen, > > the usage of the Replaces header is of course the best solution, it's also described in the regarding 3GPP conferencing spec. > The disadvantage of the usage of the Repaces header is, that it puts requirements on the UE of the invited user, it would have to support RFC 3891. And if it supports, it really would have to accept the 2nd INVITE, which is not mandatory according to RFC 3891 I think. > Anyway what is needed in addition is a solution how also very simple terminals (e. g. only supporting RFC 3261) can be invited to an ad-hoc conference, whithout having to say to the invited user to please hang up because there will be a call from the focus shortly. > > Re-using an already established dialog at least at the first glance seems to be a simply and invited UE independent solution. And as this re-INVITE it wanted by at least one of the involved user, I would more compare it to some kind of triggered 3rd party call control than to spoofing. > > Of course as you said it would have to be made clear that the focus is able to collect all the information needed for sending re-INVITEs (proposed "?" mechanism usage, dialog event package, etc.). > > > Regards, Martin > > > > > > >> -----Ursprüngliche Nachricht----- >> Von: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] >> Gesendet: Freitag, 24. August 2007 17:06 >> An: Alexeitsev, Denis; sip@ietf.org >> Betreff: Re: [Sip] Extension of conference procedures >> >> >> Denis, >> >> If I understand your scenario, "focus" is a third party >> separate from A and >> B, right? (e.g. a conference server) >> >> In that case the focus is not a party in the A-B dialog, and >> would need more >> than Call-ID, From and To to be able to construct a reINVITE >> that B would >> accept as coming from A (e.g. CSeq). In any case, this looks >> like a very >> inelegant, hacked solution (as the conference server is >> basically spoofing) >> >> RFC4579 section 5.10 provides some insipration, as well as >> http://www.ietf.org/internet-drafts/draft-ietf-sipping-service >> -examples-13.txt >> scenario 2.5 >> >> For example, A could include a 'Replaces' header in the URI >> it includes in >> its conference URI list. Then the conference server would send a new >> (out-of-dialog) INVITE to B containing this Replaces header, >> and B would >> know that it is associated with the dialog it has with A (and >> can replace >> it, without ringing if the UA is constructed like that) >> >> The conference server should probably also include a >> Referred-By containing >> A's AoR, either automatically (i.e. copy from From header in >> INVITE) or >> included by A in the URI (former is better) >> >> Regards, >> Jeroen >> >> Alexeitsev, D wrote: >> >>> I'd like to discuss the extension of the current conference >>> >> procedures >> >>> with the following functionality. >>> >>> 3GPP conference specifications are basing generally on the >>> Conferencing Framework (RFC 4353) and for one possibility >>> >> of inviting >> >>> users to the confrence on draft-ietf-sip-uri-list-conferencing. >>> >>> Using the conferencing framework, the following situation can occur >>> when a user is invited to an ad-hoc conference: >>> User A is in a dialog with user B, and decides to start a >>> >> conference, >> >>> for example using an INVITE request to the focus which >>> >> includes a URI >> >>> list with the URIs of the users which shall be added to the >>> conference, incl. B. So when the INVITE request from the focus >>> arrives at B, he is still in the original dialog with A, and so it >>> depends on B if he accepts the 2nd INVITE and the conference can be >>> established. >>> >>> At the last 3GPP CT1 meeting the idea of transporting dialog >>> identifiers together with the URIs was introduced to solve this >>> problem. Basing on the idea that the procedures at the conference >>> server are extended in that way, that the conference server is aware >>> of already established dialogs, the focus then has the >>> >> possibility to >> >>> send re-INVITES in the indicated dialogs and connect the media from >>> the invited users to the conference bridge. >>> In the URI list the dialogs can be indicated using the "?" mechanism >>> according to subclause 19.1.1 of RFC 3261. >>> >>> Following example shows the proposed mechanism: >>> >>> INVITE Conference >>> To: Conference >>> From: A >>> Require: recipient-list-invite >>> >>> Content-Type: application/resource-lists+xml >>> Content-Disposition: recipient-list >>> >>> >>> >> xmlns:cp="urn:ietf:params:xml:ns:copyControl"> >>> >>> >> cp:copyControl="to"/> >>> >> cp:copyControl="to"/> >>> >>> >>> >>> Greetings, >>> Denis Alexeitsev >>> >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip >>> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> >> > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Aug 26 14:36:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPMwI-0003fm-3v; Sun, 26 Aug 2007 14:34:22 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1INbPm-000070-I3 for sip-confirm+ok@megatron.ietf.org; Tue, 21 Aug 2007 17:37:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INbPm-00005r-81 for sip@ietf.org; Tue, 21 Aug 2007 17:37:30 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INbPk-0008Qf-R8 for sip@ietf.org; Tue, 21 Aug 2007 17:37:30 -0400 Received: from repmmr01.bea.com (repmmr01.bea.com [10.160.29.71]) by repmmg02.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l7LLbPtC030209 for ; Tue, 21 Aug 2007 14:37:25 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr01.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l7LLbNuI007294 for ; Tue, 21 Aug 2007 14:37:24 -0700 Received: from 172.24.28.189 ([172.24.28.189]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Tue, 21 Aug 2007 21:37:23 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Tue, 21 Aug 2007 17:37:22 -0400 From: Eric Burger To: "'sip'" Message-ID: Thread-Topic: INFO Thread-Index: AcfkO3T4s2cG+lAuEdy/WQAWy4mm/w== Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c X-Mailman-Approved-At: Sun, 26 Aug 2007 14:34:19 -0400 Subject: [Sip] INFO X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Since list traffic is down, how about something to spice things up? Any thoughts on http://www.ietf.org/internet-drafts/draft-burger-sip-info-01.txt ??? If you like it, say so. If you hate it, say so. Text welcome. Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete 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 sip-bounces@ietf.org Sun Aug 26 14:37:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPMxM-0005MT-Hp; Sun, 26 Aug 2007 14:35:28 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1INdRs-0000GR-UX for sip-confirm+ok@megatron.ietf.org; Tue, 21 Aug 2007 19:47:48 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1INdRs-0000GI-LH for sip@ietf.org; Tue, 21 Aug 2007 19:47:48 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INdGt-0001rj-Om for sip@ietf.org; Tue, 21 Aug 2007 19:36:27 -0400 Received: from mail1.vmobl.com ([205.239.227.29] helo=vscpsmgw05.vmuprod.local) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1INdGt-0008Jg-CK for sip@ietf.org; Tue, 21 Aug 2007 19:36:27 -0400 Received: from vscsmtp.vmobile-corp.com (mail2.vmobl.com [205.239.227.49]) by vscpsmgw05.vmuprod.local (Switch-3.2.5/Switch-3.2.2) with ESMTP id l7LNaPH0003585 for ; Tue, 21 Aug 2007 16:36:25 -0700 (PDT) Received: from vwcmxbk01.vmobile-corp.com (vwcmxbk01.vmobile-corp.com [10.1.33.60]) by vscsmtp.vmobile-corp.com (Switch-3.2.5/Switch-3.2.2) with ESMTP id l7LNaDoB019160 for ; Tue, 21 Aug 2007 16:36:24 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 21 Aug 2007 16:33:46 -0700 Message-ID: <648E1817B5F395409B5C6A8CEA708A3F613B37@vwcmxbk01.vmobile-corp.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SIP Recommended Call Flows for an MVNO? Thread-Index: AcfkS7fykhZlLTgwSwmzHXAf4FgqGw== From: "McFarland, Keith A." To: X-Spam-Score: 0.00% X-MASF: 0.00% X-Spam-Score: 0.0 (/) X-Scan-Signature: f2728948111f2edaaf8980b5b9de55af X-TMDA-Confirmed: Tue, 21 Aug 2007 19:47:48 -0400 X-Mailman-Approved-At: Sun, 26 Aug 2007 14:35:27 -0400 Subject: [Sip] SIP Recommended Call Flows for an MVNO? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0341934056==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0341934056== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7E44B.B85D1424" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7E44B.B85D1424 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, =20 I have been reviewing SIP documents at IETF and have come to the conclusion that there is not an exact recommended procedure to cover my desired use of the SIP implementation. As you can tell from my email address I am the voice architect at Virgin Mobile USA, LLC. I am currently, considering future implementations to interface with our prepaid rating engine. As part of this consideration I am evaluating leapfrog to IP call control versus an evolution within SS7. My preference is to move to SIP if possible. However, in an MVNO the use of SIP would vary slightly from the current best practices. I would envision the SIP proxy to be replaced with a SIP 3rd Party Call Authorization and Control Server. =20 This 3rd Party server does not sit in the middle of the SIP call flow (as does a proxy or 3pcc) but sits off to the side and other proxies (MSC or PSTN switches, in this case they act as SIP gateways) would call out to this 3rd party SIP server to get direction on voice call treatment. This call treatment could include just simple authorization to proceed, denial, redirection with or without special treatment etc. What I am trying to find is a best practices to cover this scenario. Perhaps it exists and you could just help me out by pointing me to the best practices document. If it doesn't, what are our options to go down the path to develop one? We are willing to move forward with an implementation of this but would prefer to do so with the support of a best practices or recommended practices from IETF. Having this would obviously benefit our efforts as we would have to work with multiple switch vendors for any modifications. Obviously, it would be more advantageous to these vendors to implement this if it is based off of recommended practices as the resale potential goes up. =20 =20 Appreciate your time, =20 =20 Keith A. McFarland Voice Architecture Manager Virgin Mobile USA, LLC 925-457-6536 =20 ------_=_NextPart_001_01C7E44B.B85D1424 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 

I have been reviewing SIP documents at IETF and have = come to the conclusion that there is not an exact recommended procedure to cover = my desired use of the SIP implementation. As you can tell from my email = address I am the voice architect at Virgin Mobile USA, LLC. I am currently, considering future implementations to interface with our prepaid rating = engine. As part of this consideration I am evaluating leapfrog to IP call = control versus an evolution within SS7. My preference is to move to SIP if = possible. However, in an MVNO the use of SIP would vary slightly from the current = best practices. I would envision the SIP proxy to be replaced with a SIP = 3rd Party Call Authorization and Control = Server.

 

This 3rd Party server does not sit in the = middle of the SIP call flow (as does a proxy or 3pcc) but sits off to the side = and other proxies (MSC or PSTN switches, in this case they act as SIP gateways) = would call out to this 3rd party SIP server to get direction on = voice call treatment. This call treatment could include just simple authorization = to proceed, denial, redirection with or without special treatment etc. What I am = trying to find is a best practices to cover this scenario. Perhaps it exists and = you could just help me out by pointing me to the best practices document. If = it doesn’t, what are our options to go down the path to develop one? = We are willing to move forward with an implementation of this but would prefer = to do so with the support of a best practices or recommended practices from = IETF. Having this would obviously benefit our efforts as we would have to work with = multiple switch vendors for any modifications. Obviously, it would be more = advantageous to these vendors to implement this if it is based off of recommended = practices as the resale potential goes up.

 

 

Appreciate your time,

 

 

Keith A. McFarland

Voice Architecture = Manager

Virgin Mobile USA, = LLC

925-457-6536 =   

------_=_NextPart_001_01C7E44B.B85D1424-- --===============0341934056== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0341934056==-- From sip-bounces@ietf.org Sun Aug 26 14:38:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPMyT-0008GM-Mf; Sun, 26 Aug 2007 14:36:37 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1ILhmn-0000Xa-8a for sip-confirm+ok@megatron.ietf.org; Thu, 16 Aug 2007 12:01:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILhmm-0000X7-If; Thu, 16 Aug 2007 12:01:24 -0400 Received: from pmesmtp03.mci.com ([199.249.20.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILhml-0002ZU-70; Thu, 16 Aug 2007 12:01:24 -0400 Received: from pmismtp04.wcomnet.com ([166.37.158.164]) by firewall.verizonbusiness.com (Iplanet MTA 5.2) with ESMTP id <0JMV00FBVJ6AXQ@firewall.verizonbusiness.com>; Thu, 16 Aug 2007 16:01:23 +0000 (GMT) Received: from pmismtp04.wcomnet.com ([127.0.0.1]) by pmismtp04.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with SMTP id <0JMV00FTGJ6AH3@pmismtp04.mcilink.com>; Thu, 16 Aug 2007 16:01:22 +0000 (GMT) Received: from ASHSRV140.mcilink.com ([153.39.68.166]) by pmismtp04.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with ESMTP id <0JMV00E3JJ6AM2@pmismtp04.mcilink.com>; Thu, 16 Aug 2007 16:01:22 +0000 (GMT) Received: from ASHEVS010.mcilink.com ([153.39.69.135]) by ASHSRV140.mcilink.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Aug 2007 16:01:22 +0000 Date: Thu, 16 Aug 2007 15:59:39 +0000 From: "Iliff, Tina" To: sipping@ietf.org, sip@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Thread-topic: SDP offer/answer -- Port 9 Thread-index: AcfgHnOQiZ+7lr8ZR4K4DHfKzCjl3g== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 16 Aug 2007 16:01:22.0942 (UTC) FILETIME=[B12BB1E0:01C7E01E] X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 X-Mailman-Approved-At: Sun, 26 Aug 2007 14:36:35 -0400 Cc: Subject: [Sip] SDP offer/answer -- Port 9 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0697139873==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0697139873== Content-type: multipart/alternative; boundary="----_=_NextPart_001_01C7E01E.B0A8211F" Content-class: urn:content-classes:message This is a multi-part message in MIME format. ------_=_NextPart_001_01C7E01E.B0A8211F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi! I have encountered an application in the "real world" which provides port 9 in the SDP answer in the 200OK. The SDP m line indicates RTP/AVP. I recognize that port 9 is acceptable if the SDP m line indicates BFCP. My question is: Is port 9 acceptable for RTP/AVP. In other words, should the original offerer send an ACK and then immediate BYE indicating that it rejected the answer? Or....should the offerer send an ACK, then send media to port 8? FYI. What I am actually seeing is that the answerer indicates port 9 in the answer but sends a re-INVITE immediately after the ACK; however, the originator/offerer does not accept the re-INVITE due to it is already in the process of tearing down the call. =20 Has anyone else seen this specific behavior or similar behavior? P.S. RFC2327 noted a range of 1024-65535 for RTP ports; however, RFC4566 does not indicate a specific range. Regards, Tina Iliff ------_=_NextPart_001_01C7E01E.B0A8211F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable SDP offer/answer -- Port 9

Hi!  I have = encountered an application in the "real world"  which = provides port 9 in the SDP answer in the 200OK.  The SDP m line = indicates RTP/AVP.  I recognize that port 9 is acceptable if the = SDP m line indicates BFCP.  My question is:   Is port 9 = acceptable for RTP/AVP.  In other words, should the original = offerer send an ACK and then immediate BYE indicating that it rejected = the answer?  Or….should the offerer send an ACK, then send = media to port 8?

FYI.  What I am = actually seeing is that the answerer indicates port 9 in the answer but = sends a re-INVITE immediately after the ACK; however, the = originator/offerer does not accept the re-INVITE due to it is already in = the process of tearing down the call.   

Has anyone else seen this = specific behavior or similar behavior?

P.S.  RFC2327 noted a = range of 1024-65535 for RTP ports; however, RFC4566 does not indicate a = specific range.

Regards,

Tina Iliff

------_=_NextPart_001_01C7E01E.B0A8211F-- --===============0697139873== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0697139873==-- From sip-bounces@ietf.org Sun Aug 26 14:42:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPN2I-0002Q2-Vm; Sun, 26 Aug 2007 14:40:34 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IPN2H-0002Pw-Qx for sip-confirm+ok@megatron.ietf.org; Sun, 26 Aug 2007 14:40:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPN2H-0002Oy-GG for sip@ietf.org; Sun, 26 Aug 2007 14:40:33 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IPN2G-0001Gj-Hi for sip@ietf.org; Sun, 26 Aug 2007 14:40:33 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l7QIeTd6024515 for ; Sun, 26 Aug 2007 13:40:29 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 26 Aug 2007 13:40:29 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.29]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 26 Aug 2007 20:40:26 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-session-policy-framework-02.txt Date: Sun, 26 Aug 2007 20:40:24 +0200 Message-ID: <5D1A7985295922448D5550C94DE29180015F4C10@DEEXC1U01.de.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] I-D ACTION:draft-ietf-sip-session-policy-framework-02.txt Thread-Index: Acfme0bWZ8jR/4dWR7S4r3LSpYtMhQBlO7LQ References: From: "DRAGE, Keith \(Keith\)" To: X-OriginalArrivalTime: 26 Aug 2007 18:40:26.0953 (UTC) FILETIME=[91F9B390:01C7E810] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org (As SIP WG co-chair) This version of the document would claim to address all the WGLC comments, and should therefore be ready for publication. Could I ask all people that addressed WGLC comments on this document to check that their comments have been addressed. If anyone else out there has a chance for a reread of the document, that would also be appropriate. Assuming that all is OK, we will be progressing the publication request for this document in a week or two. Regards Keith > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 > Sent: Friday, August 24, 2007 7:15 PM > To: i-d-announce@ietf.org > Cc: sip@ietf.org > Subject: [Sip] I-D=20 > ACTION:draft-ietf-sip-session-policy-framework-02.txt=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > This draft is a work item of the Session Initiation Protocol=20 > Working Group of the IETF. >=20 > Title : A Framework for Session Initiation=20 > Protocol (SIP) Session Policies > Author(s) : V. Hilt, et al. > Filename : draft-ietf-sip-session-policy-framework-02.txt > Pages : 33 > Date : 2007-8-24 > =09 > Proxy servers play a central role as an intermediary in the Session > Initiation Protocol (SIP) as they define and impact=20 > policies on call > routing, rendezvous, and other call features. This document > specifies a framework for SIP session policies that provides a > standard mechanism by which a proxy can define or=20 > influence policies > on sessions, such as the codecs or media types to be used. It > defines a model, an overall architecture and new protocol=20 > mechanisms > for session policies. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sip-session-pol > icy-framework-02.txt >=20 > To remove yourself from the I-D Announcement list, send a=20 > message to i-d-announce-request@ietf.org with the word=20 > unsubscribe in the body of the message.=20 > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. >=20 > Internet-Drafts are also available by anonymous FTP. Login=20 > with the username "anonymous" and a password of your e-mail=20 > address. After logging in, type "cd internet-drafts" and then=20 > "get draft-ietf-sip-session-policy-framework-02.txt". >=20 > A list of Internet-Drafts directories can be found in=20 > http://www.ietf.org/shadow.html or=20 > ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE=20 > /internet-drafts/draft-ietf-sip-session-policy-framework-02.txt". > =09 > 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=20 > 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. >=20 > Below is the data which will enable a MIME compliant mail=20 > reader implementation to automatically retrieve the ASCII=20 > version of the Internet-Draft. >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Aug 26 14:42:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPN2x-0002l5-9g; Sun, 26 Aug 2007 14:41:15 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IPN2v-0002kg-TC for sip-confirm+ok@megatron.ietf.org; Sun, 26 Aug 2007 14:41:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPN2v-0002kY-Iw for sip@ietf.org; Sun, 26 Aug 2007 14:41:13 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IPN2u-0001Hy-QW for sip@ietf.org; Sun, 26 Aug 2007 14:41:13 -0400 Received: (qmail invoked by alias); 26 Aug 2007 18:41:11 -0000 Received: from p54987ADA.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.122.218] by mail.gmx.net (mp028) with SMTP; 26 Aug 2007 20:41:11 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/SqA9pEpvSkEzmomf2XQU5zSL63MxoHgpcssv4aY GqQ2qchSLa16tN Message-ID: <46D1C942.7010501@gmx.net> Date: Sun, 26 Aug 2007 20:41:06 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: IETF SIP List Subject: Re: [Sip] draft-rosenberg-sip-ua-loose-route-01.txt References: <46CAE441.8080504@gmx.net> In-Reply-To: <46CAE441.8080504@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: ECRIT X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org No response received -- resend. Hannes Tschofenig wrote: > Dear SIP WG members, > > during the ECRIT meeting we learned that the SIP working group > "rejected" the concept described in > draft-rosenberg-sip-ua-loose-route-01.txt. > > Could someone please give us more information about this decision as > it impacts the work we do in ECRIT? > > Ciao > Hannes > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Aug 26 20:57:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPStJ-0008S1-Ty; Sun, 26 Aug 2007 20:55:41 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IPStI-0008Rw-6u for sip-confirm+ok@megatron.ietf.org; Sun, 26 Aug 2007 20:55:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPStH-0008Ro-Tg for sip@ietf.org; Sun, 26 Aug 2007 20:55:39 -0400 Received: from alnrmhc15.comcast.net ([206.18.177.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IPStG-0000Cj-Nc for sip@ietf.org; Sun, 26 Aug 2007 20:55:39 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (alnrmhc15) with ESMTP id <20070827005537b1500a5anse>; Mon, 27 Aug 2007 00:55:38 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l7R0tb4p031454 for ; Sun, 26 Aug 2007 20:55:37 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l7R0tbRL031450; Sun, 26 Aug 2007 20:55:37 -0400 Date: Sun, 26 Aug 2007 20:55:37 -0400 Message-Id: <200708270055.l7R0tbRL031450@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: (tina.iliff@verizonbusiness.com) Subject: Re: [Sip] SDP offer/answer -- Port 9 References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: "Iliff, Tina" Hi! I have encountered an application in the "real world" which provides port 9 in the SDP answer in the 200OK. The SDP m line indicates RTP/AVP. I recognize that port 9 is acceptable if the SDP m line indicates BFCP. My question is: Is port 9 acceptable for RTP/AVP. [...] P.S. RFC2327 noted a range of 1024-65535 for RTP ports; however, RFC4566 does not indicate a specific range. Since RFC 4566 is the latest standard and does not restrict the port number to a particular range, you should not restrict the port number. In addition, unless there is a specific functional reason, an application should never place a restriction on a port number supplied by the other end, regardless of the standard. More interesting is RFC 3550, in which the use of even/odd port number pairs is described for the corresponding RTP and RTCP streams: 11. RTP over Network and Transport Protocols RTP relies on the underlying protocol(s) to provide demultiplexing of RTP data and RTCP control streams. For UDP and similar protocols, RTP SHOULD use an even destination port number and the corresponding RTCP stream SHOULD use the next higher (odd) destination port number. For applications that take a single port number as a parameter and derive the RTP and RTCP port pair from that number, if an odd number is supplied then the application SHOULD replace that number with the next lower (even) number to use as the base of the port pair. So by default, specifying port 9 means that RTP is on port 8 and RTCP is on port 9. But SDP also allows the RTCP port to be specified separately. RFC 4566: 5.14. Media Descriptions ("m=") If non-contiguous ports are used or if they don't follow the parity rule of even RTP ports and odd RTCP ports, the "a=rtcp:" attribute MUST be used. And continuing with RFC 3550: For applications in which the RTP and RTCP destination port numbers are specified via explicit, separate parameters (using a signaling protocol or other means), the application MAY disregard the restrictions that the port numbers be even/odd and consecutive although the use of an even/odd port pair is still encouraged. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Aug 26 21:19:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPTEy-0002cY-8y; Sun, 26 Aug 2007 21:18:04 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IPTEx-0002cT-Kx for sip-confirm+ok@megatron.ietf.org; Sun, 26 Aug 2007 21:18:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPTEx-0002cL-BD for sip@ietf.org; Sun, 26 Aug 2007 21:18:03 -0400 Received: from alnrmhc14.comcast.net ([204.127.225.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IPTEw-0000hj-51 for sip@ietf.org; Sun, 26 Aug 2007 21:18:03 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (alnrmhc14) with ESMTP id <20070827011801b1400phjaee>; Mon, 27 Aug 2007 01:18:01 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l7R1I04p000599 for ; Sun, 26 Aug 2007 21:18:00 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l7R1I0Su000595; Sun, 26 Aug 2007 21:18:00 -0400 Date: Sun, 26 Aug 2007 21:18:00 -0400 Message-Id: <200708270118.l7R1I0Su000595@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <648E1817B5F395409B5C6A8CEA708A3F613B37@vwcmxbk01.vmobile-corp.com> (Keith.McFarland@virginmobileusa.com) Subject: Re: [Sip] SIP Recommended Call Flows for an MVNO? References: <648E1817B5F395409B5C6A8CEA708A3F613B37@vwcmxbk01.vmobile-corp.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: "McFarland, Keith A." This 3rd Party server does not sit in the middle of the SIP call flow (as does a proxy or 3pcc) but sits off to the side and other proxies (MSC or PSTN switches, in this case they act as SIP gateways) would call out to this 3rd party SIP server to get direction on voice call treatment. This call treatment could include just simple authorization to proceed, denial, redirection with or without special treatment etc. What I am trying to find is a best practices to cover this scenario. SIP allows a great many ways to process calls; I don't believe that there are many "best practices" because SIP is very flexible, and as long as system components follow the SIP rules, they can be truly mix-and-matched. One architecture you may want to consider is the one that the sipX open-source proxy uses (see http://www.sipfoundry.org): A call to sip:xxxx@example.com is routed (via RFC 3263 mechanisms) to a "forking proxy". The forking proxy, through a small number of configured rules, sends the call to the "redirector" (which also functions as the registrar for the domain). The redirector decides how the call should be processed, and effects that decision by sending a 302 redirection response back to the forking proxy. The forking proxy acts on the 302 to send the call to the various allowed destinations. The redirector is modularized, and produces responses which incorporate registered telephones for the URI, call forwarding, call park and pick-up, voice mail fallback, etc. The forking proxy is just a forking engine, and need have no understanding of the policy or routing logic, it just obeys the 302 that it is given. In sipX, all outgoing requests from the forking proxy are then sent to the "authorization proxy", which applies authorization rules, and then sends the requests to their destinations. This allows a separation of function: forking proxy - the forking logic redirector - routing decisions authorization proxy - authorization decisions The authorization proxy could be combined with the redirector without complicating the structure much. Only the authorization proxy participates in a call after it is set up (the redirector is not involved because it has given a 302 response and the forking proxy has sent the call elsewhere, the forking proxy does not Record-Route itself). Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Aug 26 21:54:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPTmp-0005qB-Sz; Sun, 26 Aug 2007 21:53:03 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IPTmo-0005pL-Qu for sip-confirm+ok@megatron.ietf.org; Sun, 26 Aug 2007 21:53:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPTmo-0005pD-HL for sip@ietf.org; Sun, 26 Aug 2007 21:53:02 -0400 Received: from rwcrmhc13.comcast.net ([216.148.227.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IPTmn-0001Gr-AC for sip@ietf.org; Sun, 26 Aug 2007 21:53:02 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (rwcrmhc13) with ESMTP id <20070827015259m13003hmqqe>; Mon, 27 Aug 2007 01:52:59 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l7R1qw4p003246 for ; Sun, 26 Aug 2007 21:52:58 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l7R1qwkG003242; Sun, 26 Aug 2007 21:52:58 -0400 Date: Sun, 26 Aug 2007 21:52:58 -0400 Message-Id: <200708270152.l7R1qwkG003242@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: (Martin.Huelsemann@t-com.net) Subject: Re: AW: [Sip] Extension of conference procedures References: X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: "Huelsemann, Martin" The disadvantage of the usage of the Repaces header is, that it puts requirements on the UE of the invited user, it would have to support RFC 3891. Why would you want to consider user agents that do not support Replaces? They would be unable to execute consultative transfers, call pick-ups, and many other features. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Aug 27 01:43:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPXLj-0005Gf-JB; Mon, 27 Aug 2007 01:41:19 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IPXLg-0005GM-Mj for sip-confirm+ok@megatron.ietf.org; Mon, 27 Aug 2007 01:41:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPXLg-0005GC-B2; Mon, 27 Aug 2007 01:41:16 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IPXLe-0007PG-W9; Mon, 27 Aug 2007 01:41:16 -0400 Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id l7R5f9tJ021949 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 27 Aug 2007 00:41:11 -0500 Message-ID: <46D264F9.6080101@softarmor.com> Date: Mon, 27 Aug 2007 00:45:29 -0500 From: Dean Willis User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [Ecrit] Re: [Sip] draft-rosenberg-sip-ua-loose-route-01.txt References: <46CAE441.8080504@gmx.net> <46D1C942.7010501@gmx.net> In-Reply-To: <46D1C942.7010501@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: IETF SIP List , ECRIT X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hannes Tschofenig wrote: > No response received -- resend. > > Hannes Tschofenig wrote: > >> Dear SIP WG members, >> >> during the ECRIT meeting we learned that the SIP working group >> "rejected" the concept described in >> draft-rosenberg-sip-ua-loose-route-01.txt. >> >> Could someone please give us more information about this decision as >> it impacts the work we do in ECRIT? I wouldn't say that UA Loose Route was "rejected" so much as "does not yet have consensus". This is in part influenced by "WG doesn't seem to have a compelling reason to make such a significant change." Perhaps ECRIT has a compelling reason? -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Aug 27 02:56:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPYUH-0002cG-Uo; Mon, 27 Aug 2007 02:54:13 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IPYUG-0002c2-Sn for sip-confirm+ok@megatron.ietf.org; Mon, 27 Aug 2007 02:54:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPYUB-0002bX-DY for sip@ietf.org; Mon, 27 Aug 2007 02:54:07 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IPYU9-00017P-R0 for sip@ietf.org; Mon, 27 Aug 2007 02:54:07 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l7R6rsFW005350; Mon, 27 Aug 2007 09:54:01 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Aug 2007 09:53:52 +0300 Received: from esebe106.NOE.Nokia.com ([172.21.143.51]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Aug 2007 09:53:52 +0300 Received: from [172.21.41.208] ([172.21.41.208]) by esebe106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Aug 2007 09:53:51 +0300 Message-ID: <46D274FF.3020307@nokia.com> Date: Mon, 27 Aug 2007 09:53:51 +0300 From: Aki Niemi Organization: Nokia User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: ext Jonathan Rosenberg Subject: Re: [Sip] comments on draft-ietf-sip-subnot-etags-00 References: <46A60E86.7030209@cisco.com> <46A62A78.1030200@nokia.com> <46CF0139.2040402@cisco.com> In-Reply-To: <46CF0139.2040402@cisco.com> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Aug 2007 06:53:51.0653 (UTC) FILETIME=[06D20D50:01C7E877] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Jonathan, There's a more substantial issue you raised which I'll cover in a separate email. I think what you suggest makes sense, but requires a bit of redesign. What I will do is submit the working version I have ready. At this point there's quite a backlog of fixes so it makes sense to get that out now. Then we can address the redesign issue. ext Jonathan Rosenberg wrote: >> The entity-tag MUST be unique across all versions of all entities for >> a resource. >> >> I think we should also add "...and event package" just to be clear. > > I'm not sure what that means. You mean, if the same object is delivered > in multiple event packages? When does that happen? I mean that entity-tags for presence can collide with entity-tags for the conference package. I think it makes sense to include the Event header field as being part of the entity. >> I think we should also add that the subscriber should never assume >> that the entity-tags are shared between notification and, say, SIP >> event publication or HTTP. > > Right, that would be a good clarification. > > The other issue is you need to be clear about what you mean by > 'resource' in your text above. For example if two SIP URI are different > but happen to resolve to the same user, is that the same resource and > would the etags be the same? (I think no). I have put in quite a bit of text around this, so let's defer this to when I get the new version out. I think this is now covered, and that there isn't a problem even if the entity-tags collide for notifications in subscriptions that were made to a different URI. >> I can add text to the numbered lists of 4.x sections about storing >> the entity tags. The very last bullets of each of 4.x sections do >> talk about what the subscriber is to do with the 204. Should there be >> a sub-section in section 4 that has normative text on these though? > > Yes. Generally the right structure for extensions is something like: > > UA Behavior > > Sending Requests > > > Processing Responses > > > and you are mostly covering the sending of requests. This is fixed in the upcoming version. 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 sip-bounces@ietf.org Mon Aug 27 03:39:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPZA6-0001Gs-1g; Mon, 27 Aug 2007 03:37:26 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IPZA5-0001Gn-93 for sip-confirm+ok@megatron.ietf.org; Mon, 27 Aug 2007 03:37:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPZA4-0001Gf-Vr for sip@ietf.org; Mon, 27 Aug 2007 03:37:24 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IPZA3-00024T-GK for sip@ietf.org; Mon, 27 Aug 2007 03:37:24 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l7R7b6Wc023507 for ; Mon, 27 Aug 2007 10:37:21 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Aug 2007 10:37:04 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Aug 2007 10:37:04 +0300 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Aug 2007 10:37:04 +0300 Received: from [172.21.41.208] (esdhcp041208.research.nokia.com [172.21.41.208]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l7R7b25I007303 for ; Mon, 27 Aug 2007 10:37:02 +0300 Message-ID: <46D27F1E.8090107@nokia.com> Date: Mon, 27 Aug 2007 10:37:02 +0300 From: Aki Niemi User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Aug 2007 07:37:04.0301 (UTC) FILETIME=[1028BDD0:01C7E87D] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Subject: [Sip] Subnot-etags: refactoring X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org All, Currently, the draft explicitly scopes the conditional notification mechanism to the very first NOTIFY that gets triggered by a SUBSCRIBE. Jonathan made a proposal to refactor the subnot-etags so that the mechanism would conditionally suppress either the entire notification or the notification body of any subsequent NOTIFY. For example, if the entity-tags match this would automatically suppress the NOTIFY immediately after a subscription refresh, as well as any NOTIFY bodies thereafter where the entity-tag has not changed, but e.g., the subscription state has. In practice, we would now only have a single "Suppress-If-Match" header field, and the notifier's behavior would be altered to suppress everything if the entity-tags match and there are no other reportable changes; otherwise if the entity-tags match but the subscription-state has changed, the notifier only suppresses the body. I think this is a great idea since both the efficiency of the mechanism increases (suppresses more redundant information), while the complexity actually decreases (there is now only a single behavior for the notifier to follow). However, this does require some pretty extensive changes to the draft, which makes this maybe more of a redesign after all ;). But I'm at least convinced this is what we should do, so I will go ahead and make those changes, unless someone vehemently disagrees. Objections? 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 sip-bounces@ietf.org Mon Aug 27 03:55:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPZPN-0000lJ-9J; Mon, 27 Aug 2007 03:53:13 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IPZPL-0000lE-7N for sip-confirm+ok@megatron.ietf.org; Mon, 27 Aug 2007 03:53:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPZPK-0000l6-UB for sip@ietf.org; Mon, 27 Aug 2007 03:53:10 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IPZPJ-0002Mz-4G for sip@ietf.org; Mon, 27 Aug 2007 03:53:10 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l7R7r6Us026874 for ; Mon, 27 Aug 2007 10:53:07 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Aug 2007 10:52:39 +0300 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Aug 2007 10:52:39 +0300 Received: from [172.21.41.208] (esdhcp041208.research.nokia.com [172.21.41.208]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l7R7qbOI025813 for ; Mon, 27 Aug 2007 10:52:38 +0300 Message-ID: <46D282C5.4000605@nokia.com> Date: Mon, 27 Aug 2007 10:52:37 +0300 From: Aki Niemi User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Aug 2007 07:52:39.0668 (UTC) FILETIME=[3DAE6B40:01C7E87F] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [Sip] Subnot-etags: new I-D version X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org All, I've submitted a -01 of the subnot-etags draft. You can fetch it from here until it appears in the archives: http://www.akiniemi.net/drafts/draft-ietf-sip-subnot-etags-01.html http://www.akiniemi.net/drafts/draft-ietf-sip-subnot-etags-01.txt 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 sip-bounces@ietf.org Mon Aug 27 06:01:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPbNQ-0005DM-0b; Mon, 27 Aug 2007 05:59:20 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IPbNO-0005DH-4m for sip-confirm+ok@megatron.ietf.org; Mon, 27 Aug 2007 05:59:18 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPbNN-0005D9-Pe for sip@ietf.org; Mon, 27 Aug 2007 05:59:17 -0400 Received: from tcmail23.telekom.de ([217.6.95.237]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IPbNM-0007uJ-M2 for sip@ietf.org; Mon, 27 Aug 2007 05:59:17 -0400 Received: from S4DE9JSAANO.ost.t-com.de (S4DE9JSAANO.ost.t-com.de [10.125.177.105]) by tcmail21.telekom.de with ESMTP; Mon, 27 Aug 2007 11:59:12 +0200 Received: from S4DE9JSAAHW.ost.t-com.de ([10.125.177.160]) by S4DE9JSAANO.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Aug 2007 11:59:11 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: AW: [Sip] Extension of conference procedures X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 27 Aug 2007 11:59:11 +0200 Message-Id: In-reply-to: <46D17EE5.8020808@zonnet.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: [Sip] Extension of conference procedures Thread-Index: Acfn6BpvoIlRzQ3TSY+JaTxjMgL1YgAogIlg From: "Huelsemann, Martin" To: X-OriginalArrivalTime: 27 Aug 2007 09:59:11.0819 (UTC) FILETIME=[EAF4B9B0:01C7E890] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7698d1420ecbbce1995432e99bb6d1a1 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, the pure RFC 3261 client won't be the normal case, of course. But there = might be networks with which you want to interwork where those simple = clients are existing. Okay, you got me, it's again the PSTN interworking. So let's say what is = needed is a fallback solution for this case. On the other hand, this fallback might be useful for a normal SIP client = which supports RFC3891, too, e.g. if there are problems with = authorization.=20 The user experience of the invitee should be exactly as you describe. If A sends the reINVITE / UPDATE himself that could be a solution, too. = The only thing is, can B then use all the conference features (e. g. = conference event package), when the focus has no knowledge on the = signalling level that B is connected to the conference bridge? Regards, Martin > -----Urspr=FCngliche Nachricht----- > Von: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl]=20 > Gesendet: Sonntag, 26. August 2007 15:24 > An: H=FClsemann, Martin > Cc: Alexeitsev, Denis; sip@ietf.org > Betreff: Re: AW: [Sip] Extension of conference procedures >=20 >=20 > Martin, >=20 > Now it becomes more clear. So the requirement is to enable a scenario=20 > where a regular call is transformed into a conference call, assuming=20 > that the invitee only has a "pure RFC3261" client. > More specifically: >=20 > - to get a smooth user experience, the scenario must not cause the=20 > invitee's phone to ring, and/or ask the invitee for permission=20 > (acceptance is assumed to be implied) >=20 > What if A would send the reINVITE (or UPDATE) itself, while=20 > filling in=20 > the SDP according to the media provided by the conference=20 > server (i.e.=20 > use codecs, media ports as received from the focus)? (trying=20 > to get the=20 > requirements more clear here) >=20 > In practice, it may still be a challenge to get such "very simple=20 > terminals" to properly handle a change of media (i.e. new destination=20 > ip/port for sending, new source ip/port and RTP src id, and possibly=20 > different codecs) >=20 > Regards, > Jeroen >=20 >=20 > Huelsemann, Martin wrote: > > Hi Jeroen, > > > > the usage of the Replaces header is of course the best=20 > solution, it's also described in the regarding 3GPP=20 > conferencing spec.=20 > > The disadvantage of the usage of the Repaces header is,=20 > that it puts requirements on the UE of the invited user, it=20 > would have to support RFC 3891. And if it supports, it really=20 > would have to accept the 2nd INVITE, which is not mandatory=20 > according to RFC 3891 I think. > > Anyway what is needed in addition is a solution how also=20 > very simple terminals (e. g. only supporting RFC 3261) can be=20 > invited to an ad-hoc conference, whithout having to say to=20 > the invited user to please hang up because there will be a=20 > call from the focus shortly.=20 > > > > Re-using an already established dialog at least at the=20 > first glance seems to be a simply and invited UE independent=20 > solution. And as this re-INVITE it wanted by at least one of=20 > the involved user, I would more compare it to some kind of=20 > triggered 3rd party call control than to spoofing. > > > > Of course as you said it would have to be made clear that=20 > the focus is able to collect all the information needed for=20 > sending re-INVITEs (proposed "?" mechanism usage, dialog=20 > event package, etc.). > > > > > > Regards, Martin > > > > > > > > > > > > =20 > >> -----Urspr=FCngliche Nachricht----- > >> Von: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl]=20 > >> Gesendet: Freitag, 24. August 2007 17:06 > >> An: Alexeitsev, Denis; sip@ietf.org > >> Betreff: Re: [Sip] Extension of conference procedures > >> > >> > >> Denis, > >> > >> If I understand your scenario, "focus" is a third party=20 > >> separate from A and=20 > >> B, right? (e.g. a conference server) > >> > >> In that case the focus is not a party in the A-B dialog, and=20 > >> would need more=20 > >> than Call-ID, From and To to be able to construct a reINVITE=20 > >> that B would=20 > >> accept as coming from A (e.g. CSeq). In any case, this looks=20 > >> like a very=20 > >> inelegant, hacked solution (as the conference server is=20 > >> basically spoofing) > >> > >> RFC4579 section 5.10 provides some insipration, as well as=20 > >> http://www.ietf.org/internet-drafts/draft-ietf-sipping-service > >> -examples-13.txt=20 > >> scenario 2.5 > >> > >> For example, A could include a 'Replaces' header in the URI=20 > >> it includes in=20 > >> its conference URI list. Then the conference server would=20 > send a new=20 > >> (out-of-dialog) INVITE to B containing this Replaces header,=20 > >> and B would=20 > >> know that it is associated with the dialog it has with A (and=20 > >> can replace=20 > >> it, without ringing if the UA is constructed like that) > >> > >> The conference server should probably also include a=20 > >> Referred-By containing=20 > >> A's AoR, either automatically (i.e. copy from From header in=20 > >> INVITE) or=20 > >> included by A in the URI (former is better) > >> > >> Regards, > >> Jeroen > >> > >> Alexeitsev, D wrote: > >> =20 > >>> I'd like to discuss the extension of the current conference=20 > >>> =20 > >> procedures > >> =20 > >>> with the following functionality. > >>> > >>> 3GPP conference specifications are basing generally on the > >>> Conferencing Framework (RFC 4353) and for one possibility=20 > >>> =20 > >> of inviting > >> =20 > >>> users to the confrence on draft-ietf-sip-uri-list-conferencing. > >>> > >>> Using the conferencing framework, the following situation=20 > can occur > >>> when a user is invited to an ad-hoc conference: > >>> User A is in a dialog with user B, and decides to start a=20 > >>> =20 > >> conference, > >> =20 > >>> for example using an INVITE request to the focus which=20 > >>> =20 > >> includes a URI > >> =20 > >>> list with the URIs of the users which shall be added to the > >>> conference, incl. B. So when the INVITE request from the focus > >>> arrives at B, he is still in the original dialog with A, and so it > >>> depends on B if he accepts the 2nd INVITE and the=20 > conference can be > >>> established. > >>> > >>> At the last 3GPP CT1 meeting the idea of transporting dialog > >>> identifiers together with the URIs was introduced to solve this > >>> problem. Basing on the idea that the procedures at the conference > >>> server are extended in that way, that the conference=20 > server is aware > >>> of already established dialogs, the focus then has the=20 > >>> =20 > >> possibility to > >> =20 > >>> send re-INVITES in the indicated dialogs and connect the=20 > media from > >>> the invited users to the conference bridge. > >>> In the URI list the dialogs can be indicated using the=20 > "?" mechanism > >>> according to subclause 19.1.1 of RFC 3261. > >>> > >>> Following example shows the proposed mechanism: > >>> > >>> INVITE Conference > >>> To: Conference > >>> From: A > >>> Require: recipient-list-invite > >>> > >>> Content-Type: application/resource-lists+xml > >>> Content-Disposition: recipient-list > >>> > >>> > >>> >>> xmlns:cp=3D"urn:ietf:params:xml:ns:copyControl"> > >>> > >>> >>> cp:copyControl=3D"to"/> > >>> >>> cp:copyControl=3D"to"/> > >>> > >>> > >>> > >>> Greetings, > >>> Denis Alexeitsev > >>> > >>> > >>> _______________________________________________ > >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>> This list is for NEW development of the core SIP Protocol > >>> Use sip-implementors@cs.columbia.edu for questions on current sip > >>> Use sipping@ietf.org for new developments on the=20 > application of sip=20 > >>> =20 > >> > >> _______________________________________________ > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol > >> Use sip-implementors@cs.columbia.edu for questions on current sip > >> Use sipping@ietf.org for new developments on the application of sip > >> > >> =20 > > > > =20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Aug 27 06:16:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPbcH-0001po-PK; Mon, 27 Aug 2007 06:14:41 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IPbcF-0001pO-Hb for sip-confirm+ok@megatron.ietf.org; Mon, 27 Aug 2007 06:14:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPbcF-0001pG-5u for sip@ietf.org; Mon, 27 Aug 2007 06:14:39 -0400 Received: from fw.polycom.co.il ([212.179.41.2] helo=isrexch01.israel.polycom.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IPbcD-0008Dn-7W for sip@ietf.org; Mon, 27 Aug 2007 06:14:38 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: AW: [Sip] Extension of conference procedures Date: Mon, 27 Aug 2007 13:15:53 +0300 Message-ID: <144ED8561CE90C41A3E5908EDECE315C04DE7868@IsrExch01.israel.polycom.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: [Sip] Extension of conference procedures Thread-Index: Acfn6BpvoIlRzQ3TSY+JaTxjMgL1YgAogIlgAAIl8iA= From: "Even, Roni" To: "Huelsemann, Martin" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 453b1bfcf0292bffe4cab90ba115f503 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, My view is that every solution where you only have A, B and a conference = server and B only supports RFC 3261 will have some limitation and will = be a hack.=20 The recommended way to do it is for A to send a Refer to B to the focus. Also asking that B supporting only RFC 3261 will support conference = event package is contradictory. B will not even be aware that it is in a = conference. Roni Even !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! A consensus means that everyone agrees to say collectively what no one = believes individually !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!=20 > -----Original Message----- > From: Huelsemann, Martin [mailto:Martin.Huelsemann@t-com.net] > Sent: Monday, August 27, 2007 12:59 PM > To: jbemmel@zonnet.nl > Cc: sip@ietf.org > Subject: AW: AW: [Sip] Extension of conference procedures >=20 > Hi, >=20 > the pure RFC 3261 client won't be the normal case, of course. But = there > might be networks with which you want to interwork where those simple > clients are existing. > Okay, you got me, it's again the PSTN interworking. So let's say what = is > needed is a fallback solution for this case. > On the other hand, this fallback might be useful for a normal SIP = client > which supports RFC3891, too, e.g. if there are problems with > authorization. >=20 > The user experience of the invitee should be exactly as you describe. >=20 > If A sends the reINVITE / UPDATE himself that could be a solution, = too. > The only thing is, can B then use all the conference features (e. g. > conference event package), when the focus has no knowledge on the > signalling level that B is connected to the conference bridge? >=20 > Regards, Martin >=20 >=20 >=20 >=20 >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > > Gesendet: Sonntag, 26. August 2007 15:24 > > An: H=FClsemann, Martin > > Cc: Alexeitsev, Denis; sip@ietf.org > > Betreff: Re: AW: [Sip] Extension of conference procedures > > > > > > Martin, > > > > Now it becomes more clear. So the requirement is to enable a = scenario > > where a regular call is transformed into a conference call, assuming > > that the invitee only has a "pure RFC3261" client. > > More specifically: > > > > - to get a smooth user experience, the scenario must not cause the > > invitee's phone to ring, and/or ask the invitee for permission > > (acceptance is assumed to be implied) > > > > What if A would send the reINVITE (or UPDATE) itself, while > > filling in > > the SDP according to the media provided by the conference > > server (i.e. > > use codecs, media ports as received from the focus)? (trying > > to get the > > requirements more clear here) > > > > In practice, it may still be a challenge to get such "very simple > > terminals" to properly handle a change of media (i.e. new = destination > > ip/port for sending, new source ip/port and RTP src id, and possibly > > different codecs) > > > > Regards, > > Jeroen > > > > > > Huelsemann, Martin wrote: > > > Hi Jeroen, > > > > > > the usage of the Replaces header is of course the best > > solution, it's also described in the regarding 3GPP > > conferencing spec. > > > The disadvantage of the usage of the Repaces header is, > > that it puts requirements on the UE of the invited user, it > > would have to support RFC 3891. And if it supports, it really > > would have to accept the 2nd INVITE, which is not mandatory > > according to RFC 3891 I think. > > > Anyway what is needed in addition is a solution how also > > very simple terminals (e. g. only supporting RFC 3261) can be > > invited to an ad-hoc conference, whithout having to say to > > the invited user to please hang up because there will be a > > call from the focus shortly. > > > > > > Re-using an already established dialog at least at the > > first glance seems to be a simply and invited UE independent > > solution. And as this re-INVITE it wanted by at least one of > > the involved user, I would more compare it to some kind of > > triggered 3rd party call control than to spoofing. > > > > > > Of course as you said it would have to be made clear that > > the focus is able to collect all the information needed for > > sending re-INVITEs (proposed "?" mechanism usage, dialog > > event package, etc.). > > > > > > > > > Regards, Martin > > > > > > > > > > > > > > > > > > > > >> -----Urspr=FCngliche Nachricht----- > > >> Von: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > > >> Gesendet: Freitag, 24. August 2007 17:06 > > >> An: Alexeitsev, Denis; sip@ietf.org > > >> Betreff: Re: [Sip] Extension of conference procedures > > >> > > >> > > >> Denis, > > >> > > >> If I understand your scenario, "focus" is a third party > > >> separate from A and > > >> B, right? (e.g. a conference server) > > >> > > >> In that case the focus is not a party in the A-B dialog, and > > >> would need more > > >> than Call-ID, From and To to be able to construct a reINVITE > > >> that B would > > >> accept as coming from A (e.g. CSeq). In any case, this looks > > >> like a very > > >> inelegant, hacked solution (as the conference server is > > >> basically spoofing) > > >> > > >> RFC4579 section 5.10 provides some insipration, as well as > > >> http://www.ietf.org/internet-drafts/draft-ietf-sipping-service > > >> -examples-13.txt > > >> scenario 2.5 > > >> > > >> For example, A could include a 'Replaces' header in the URI > > >> it includes in > > >> its conference URI list. Then the conference server would > > send a new > > >> (out-of-dialog) INVITE to B containing this Replaces header, > > >> and B would > > >> know that it is associated with the dialog it has with A (and > > >> can replace > > >> it, without ringing if the UA is constructed like that) > > >> > > >> The conference server should probably also include a > > >> Referred-By containing > > >> A's AoR, either automatically (i.e. copy from From header in > > >> INVITE) or > > >> included by A in the URI (former is better) > > >> > > >> Regards, > > >> Jeroen > > >> > > >> Alexeitsev, D wrote: > > >> > > >>> I'd like to discuss the extension of the current conference > > >>> > > >> procedures > > >> > > >>> with the following functionality. > > >>> > > >>> 3GPP conference specifications are basing generally on the > > >>> Conferencing Framework (RFC 4353) and for one possibility > > >>> > > >> of inviting > > >> > > >>> users to the confrence on draft-ietf-sip-uri-list-conferencing. > > >>> > > >>> Using the conferencing framework, the following situation > > can occur > > >>> when a user is invited to an ad-hoc conference: > > >>> User A is in a dialog with user B, and decides to start a > > >>> > > >> conference, > > >> > > >>> for example using an INVITE request to the focus which > > >>> > > >> includes a URI > > >> > > >>> list with the URIs of the users which shall be added to the > > >>> conference, incl. B. So when the INVITE request from the focus > > >>> arrives at B, he is still in the original dialog with A, and so = it > > >>> depends on B if he accepts the 2nd INVITE and the > > conference can be > > >>> established. > > >>> > > >>> At the last 3GPP CT1 meeting the idea of transporting dialog > > >>> identifiers together with the URIs was introduced to solve this > > >>> problem. Basing on the idea that the procedures at the = conference > > >>> server are extended in that way, that the conference > > server is aware > > >>> of already established dialogs, the focus then has the > > >>> > > >> possibility to > > >> > > >>> send re-INVITES in the indicated dialogs and connect the > > media from > > >>> the invited users to the conference bridge. > > >>> In the URI list the dialogs can be indicated using the > > "?" mechanism > > >>> according to subclause 19.1.1 of RFC 3261. > > >>> > > >>> Following example shows the proposed mechanism: > > >>> > > >>> INVITE Conference > > >>> To: Conference > > >>> From: A > > >>> Require: recipient-list-invite > > >>> > > >>> Content-Type: application/resource-lists+xml > > >>> Content-Disposition: recipient-list > > >>> > > >>> > > >>> > >>> xmlns:cp=3D"urn:ietf:params:xml:ns:copyControl"> > > >>> > > >>> > >>> cp:copyControl=3D"to"/> > > >>> > >>> cp:copyControl=3D"to"/> > > >>> > > >>> > > >>> > > >>> Greetings, > > >>> Denis Alexeitsev > > >>> > > >>> > > >>> _______________________________________________ > > >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > >>> This list is for NEW development of the core SIP 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 > > >> > > >> > > > > > > > > >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Aug 27 08:37:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPdoW-0004Im-4s; Mon, 27 Aug 2007 08:35:28 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IPdoV-0004Ib-Bs for sip-confirm+ok@megatron.ietf.org; Mon, 27 Aug 2007 08:35:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPdoV-0004IT-2Q for sip@ietf.org; Mon, 27 Aug 2007 08:35:27 -0400 Received: from mu-out-0910.google.com ([209.85.134.191]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IPdoS-0007YW-VN for sip@ietf.org; Mon, 27 Aug 2007 08:35:27 -0400 Received: by mu-out-0910.google.com with SMTP id w8so1963922mue for ; Mon, 27 Aug 2007 05:35:24 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=HGX2dECYNz6qWN3dkpMW0Nd5EcGg3MBN6OZ1Ubn34yOT5zrj92ywlwPcNAjDGxJj9p1utB5io7rifKx16ZuD0zk1E1kqbR4UiS0+0+CoOT8+EpoyWKtjtZebWPSfxIWZ7zD2dQreIxJJzGOrjYdLdAb7aNm/hr+xi2fU/oMUlTc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=oUI5iMbgv/6TvOlItMB8vI3hframLSdyXcWwhnI+f4FVAwxjtkshFGcsc6Dz81R0smLxbphRvKSYy59qszE4d9bJgkPpZmegZiiZcb3N2RmLoWpiEYyDK9G+oAzupOXjlCEO5ghkQ3bMtSVdQUzegcDhBj0X+xCNSo7liNySR6w= Received: by 10.82.158.12 with SMTP id g12mr14071947bue.1188218123611; Mon, 27 Aug 2007 05:35:23 -0700 (PDT) Received: by 10.82.108.10 with HTTP; Mon, 27 Aug 2007 05:35:23 -0700 (PDT) Message-ID: <317ceda50708270535i290e54c8m6966ba15c1ace89e@mail.gmail.com> Date: Mon, 27 Aug 2007 20:35:23 +0800 From: "Peili Xu" To: "Eric Burger" Subject: Re: [Sip] INFO In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Google-Sender-Auth: 57d9c9a79f0cdce4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Eric, Several cases I encounter to use INFO is for interworking with PSTN signaling, or simulate PSTN services at SIP entities such as SIP UA or SIP GW, which require mid-dialog information change. For such SIP entities, It's not always possible or required to support encapsulation of ISUP or QSIG package. Just some XML body with application info is enough and light-weight for this purpose. INFO is not an ideal tool for everything, but is an ideal tool for some thing. I'd prpose to at lease allow using INFO for interworking or simulation purpose with legacy system. Regards. Peili 2007/8/22, Eric Burger : > Since list traffic is down, how about something to spice things up? > > > Any thoughts on > > http://www.ietf.org/internet-drafts/draft-burger-sip-info-01.txt > > ??? > > If you like it, say so. If you hate it, say so. > > Text welcome. > > > Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete 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 > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Aug 27 10:47:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPfqB-0006hj-IH; Mon, 27 Aug 2007 10:45:19 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IPfqA-0006bq-5u for sip-confirm+ok@megatron.ietf.org; Mon, 27 Aug 2007 10:45:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPfq9-0006bG-SS for sip@ietf.org; Mon, 27 Aug 2007 10:45:17 -0400 Received: from nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net ([2001:470:1f03:267::2] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IPfq9-0002eZ-7s for sip@ietf.org; Mon, 27 Aug 2007 10:45:17 -0400 Received: from [172.17.1.65] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l7REj8H6072533 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 27 Aug 2007 09:45:10 -0500 (CDT) (envelope-from rjsparks@nostrum.com) In-Reply-To: <46D27F1E.8090107@nokia.com> References: <46D27F1E.8090107@nokia.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Sip] Subnot-etags: refactoring Date: Mon, 27 Aug 2007 09:45:06 -0500 To: Aki Niemi X-Mailer: Apple Mail (2.752.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.91.2/4074/Mon Aug 27 07:17:14 2007 on shaman.nostrum.com X-Virus-Status: Clean X-Spam-Score: -1.4 (-) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I'm still pretty uncomfortable with suppressing the entire NOTIFY for a refresh subscription. There are mechanics that involve the Subscription-State header and its possible extension that I fear we will interact with in unexpected ways. I will admit that all the specific instances of that I can think of right now you can work around by being really careful with the success response to the reSUBSCRIBE. Can anybody come up with a case (or imagine an extension) where the response to the reSUBSCRIBE won't have the right stuff? I'm ok with suppressing bodies of subsequent NOTIFYs. RjS On Aug 27, 2007, at 2:37 AM, Aki Niemi wrote: > All, > > Currently, the draft explicitly scopes the conditional notification > mechanism to the very first NOTIFY that gets triggered by a SUBSCRIBE. > Jonathan made a proposal to refactor the subnot-etags so that the > mechanism would conditionally suppress either the entire > notification or > the notification body of any subsequent NOTIFY. > > For example, if the entity-tags match this would automatically > suppress > the NOTIFY immediately after a subscription refresh, as well as any > NOTIFY bodies thereafter where the entity-tag has not changed, but > e.g., > the subscription state has. > > In practice, we would now only have a single "Suppress-If-Match" > header > field, and the notifier's behavior would be altered to suppress > everything if the entity-tags match and there are no other reportable > changes; otherwise if the entity-tags match but the subscription-state > has changed, the notifier only suppresses the body. > > I think this is a great idea since both the efficiency of the > mechanism > increases (suppresses more redundant information), while the > complexity > actually decreases (there is now only a single behavior for the > notifier > to follow). However, this does require some pretty extensive > changes to > the draft, which makes this maybe more of a redesign after all ;). > > But I'm at least convinced this is what we should do, so I will go > ahead > and make those changes, unless someone vehemently disagrees. > > Objections? > > 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 sip-bounces@ietf.org Mon Aug 27 11:06:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPg9D-0007ZV-LJ; Mon, 27 Aug 2007 11:04:59 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IPg9B-0007YM-0O for sip-confirm+ok@megatron.ietf.org; Mon, 27 Aug 2007 11:04:57 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPg99-0007X2-UV; Mon, 27 Aug 2007 11:04:56 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IPg98-00077c-Eg; Mon, 27 Aug 2007 11:04:55 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C8653207B1; Mon, 27 Aug 2007 17:04:47 +0200 (CEST) X-AuditID: c1b4fb3c-b1e82bb0000007e1-c3-46d2e80fde06 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9C94C20671; Mon, 27 Aug 2007 17:04:47 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Aug 2007 17:04:46 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Aug 2007 17:04:46 +0200 Message-ID: <46D2E80E.8000001@ericsson.com> Date: Mon, 27 Aug 2007 17:04:46 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Magnus Westerlund References: <46AF5370.9020304@ericsson.com> In-Reply-To: <46AF5370.9020304@ericsson.com> Content-Type: text/plain; charset=UTF-8; format=flowed X-OriginalArrivalTime: 27 Aug 2007 15:04:46.0546 (UTC) FILETIME=[9B4E0B20:01C7E8BB] X-Brightmail-Tracker: AAAAAA== Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 9f79b8e383fd3af2b1b5b1d0910f6094 Cc: sip@ietf.org, IETF SIPPING WG , tsvwg , NSIS Subject: [Sip] Re: Draft Liaison response to SG13 on Emergency Telecommunications X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, I have now updated this liaison reply to take the comments into account.=20 According to the ECRIT chairs they don't think what they are working is=20 related to the ongoing work Q.3/13 is working on. If you have any final=20 comments please provide them no later then the Wednesday 29th at 16.00 CE= ST. Magnus Westerlund Submission Date: , 2007 From: IETF Working groups TSVWG, NSIS, SIP and SIPPING To: Georges Sebek , Keith Knightson Cc: Magnus Westerlund , Lars Eggert , James Polk , Martin Stiemerling , John Loughney Dean Willis , Keith Drage , Mary Barnes , Gonzalo Camarillo , Scott Bradner , Kimberly King , Scott Brim Response Contact: TSV WG (tsv-chairs@tools.ietf.org) NSIS (nsis-chairs@tools.ietf.org) SIPPING (sipping-chairs@tools.ietf.org) SIP (sip-chairs@tools.ietf.org) =09 Purpose: Response to Liaison Request Deadline: None Title: Response to liaison request from ITU-T Study Group 13 work on=20 emergency telecommunications This is a response to the liaison request made by Q.3/13 regarding=20 emergency telecommunications (REF: NGN-GSI/DOC =E2=80=93 60 Rev.2). We wo= uld=20 first like to apologize for failing to meet the deadline in responding.=20 We do hope that the late answer still can be of some use. The liaison request was made to the following working groups (WG):=20 IEPREP, TSVWG, and NSIS. Since the request was sent the IEPREP WG has=20 concluded. In addition to the WGs from which information was requested,=20 we also think that work performed by the SIP and SIPPING WG may be of=20 relevance. Pursuant to ITU-T Study Group 13 request for information on relevant and=20 related work in the IETF regarding emergency communications, we list=20 below RFCs and works in progress that we feel may be of interest to your=20 group. Some of the completed work is Informational, and others are in=20 the category of Standards Track. Q.3/13 also requested that we keep you informed of any developments in=20 regards to emergency telecommunications. In those regards we would like=20 to make you aware that IETF mailing list participation and document=20 information is free and open to anyone, allowing participants in Q.3/13=20 to keep themselves informed of any developments. If Q.3/13 desire to get=20 further information about specific ongoing work, then please send a=20 liaison request to the responsible WG for those specific documents. The following list is divided under the associated working groups from=20 which the work has been done within the IETF. SIP Working Group RFC 4411 Title: Extending the Session Initiation Protocol (SIP) Reason Header for Preemption Events Abstract: This document proposes an IANA Registration extension to the Session Initiation Protocol (SIP) Reason Header to be included in a BYE Method Request as a result of a session preemption event, either at a user agent (UA), or somewhere in the network involving a reservation-based protocol such as the Resource ReSerVation Protocol (RSVP) or Next Steps in Signaling (NSIS). This document does not attempt to address routers failing in the packet path; instead, it addresses a deliberate tear down of a flow between UAs, and informs the terminated UA(s) with an indication of what occurred. RFC 4412 Title: Communications Resource Priority for the Session Initiation Protocol (SIP) Abstract: This document defines two new Session Initiation Protocol (SIP) header fields for communicating resource priority, namely, "Resource-Priority" and "Accept-Resource-Priority". The "Resource-Priority" header field can influence the behavior of SIP user agents (such as telephone gateways and IP telephones) and SIP proxies. It does not directly influence the forwarding behavior of IP routers. SIPPING Working Group The below two documents are proposed work items accepted to become IETF=20 WG items are likely of interest as they update RFC 4412. Work In Progress: draft-polk-sip-rph-in-responses-00 Title: Allowing SIP Resource Priority Header in SIP Responses Abstract: The Session Initiation Protocol (SIP) Resource Priority Header (RPH), in its current form, is ignored in SIP responses. This was a design choice during RFC 4412's development. This is now considered a bad design choice in certain scenarios. This document corrects RFC 4412's communications model by optionally allowing a SIP server or user agent client to process the Resource-Priority Header in a response. Work In Progress: draft-polk-sip-rph-new-namespaces--00 Title: New Session Initiation Protocol Resource-Priority Header Namespaces for=20 the Defense Information Systems Agency Abstract: This document creates additional Session Initiation Protocol Resource-Priority header namespaces, to be IANA registered. This document intends to update RFC 4412, as a Proposed Standard document if published by the RFC-Editor. IEPREP Working Group RFC 3487 Title: Requirements for Resource Priority Mechanisms for the Session Initiation Protocol (SIP) Abstract: This document summarizes requirements for prioritizing access to circuit-switched network, end system and proxy resources for emergency preparedness communications using the Session Initiation Protocol (SIP). RFC 3689 Title: General Requirements for Emergency Telecommunication Service (ETS) Abstract: This document presents a list of general requirements in support of Emergency Telecommunications Service (ETS). Solutions to these requirements are not presented in this document. Additional requirements pertaining to specific applications, or types of applications, are to be specified in separate document(s). RFC 3690 Title: IP Telephony Requirements for Emergency Telecommunication Service (ETS) Abstract: This document presents a list of requirements in support of Emergency Telecommunications Service (ETS) within the context of IP telephony. It is an extension to the general requirements presented in RFC 3689. Solutions to these requirements are not presented in this document. RFC 4190 Title: Framework for Supporting Emergency Telecommunications Service (ETS) in IP Telephony Abstract: This document presents a framework for supporting authorized, emergency-related communication within the context of IP telephony. We present a series of objectives that reflect a general view of how authorized emergency service, in line with the Emergency Telecommunications Service (ETS), should be realized within today's IP architecture and service models. From these objectives, we present a corresponding set of protocols and capabilities, which provide a more specific set of recommendations regarding existing IETF protocols. Finally, we present two scenarios that act as guiding models for the objectives and functions listed in this document. These models, coupled with an example of an existing service in the Public Switched Telephone Network (PSTN), contribute to a constrained solution space. RFC 4375 Title: Emergency Telecommunications Services (ETS) Requirements for a Single Administrative Domain Abstract: This document presents a list of requirements in support of Emergency Telecommunications Service (ETS) within a single administrative domain. This document focuses on a specific set of administrative constraints and scope. Solutions to these requirements are not presented in this document. TSV Working Group RFC 4542 Title: Implementing an Emergency Telecommunications Service (ETS) for Real-Time Services in the Internet Protocol Suite Abstract: RFCs 3689 and 3690 detail requirements for an Emergency Telecommunications Service (ETS), of which an Internet Emergency Preparedness Service (IEPS) would be a part. Some of these types of services require call preemption; others require call queuing or other mechanisms. IEPS requires a Call Admission Control (CAC) procedure and a Per Hop Behavior (PHB) for the data that meet the needs of this architecture. Such a CAC procedure and PHB is appropriate to any service that might use H.323 or SIP to set up real-time sessions. The key requirement is to guarantee an elevated probability of call completion to an authorized user in time of crisis. This document primarily discusses supporting ETS in the context of the US Government and NATO, because it focuses on the Multi-Level Precedence and Preemption (MLPP) and Government Emergency Telecommunication Service (GETS) standards. The architectures described here are applicable beyond these organizations. Work In Progress: draft-ietf-tsvwg-emergency-rsvp-03.txt Title: Resource ReSerVation Protovol (RSVP) Extensions for Emergency Services Abstract: An Emergency Telecommunications Service (ETS) requires the ability to provide an elevated probability of session establishment to an authorized user in times of network congestion (typically, during a crisis). When supported over the Internet Protocol suite, this may be facilitated through a network layer admission control solution, which supports prioritized access to resources (e.g., bandwidth). These resources may be explicitly set aside for emergency services, or they may be shared with other sessions. This document specifies RSVP extensions that can be used to support such an admission priority capability at the network layer. Note that these extensions represent one possible solution component in satisfying ETS requirements. Other solution components, or other solutions, are outside the scope of this document. NSIS Working Group Work In Progress: draft-ietf-nsis-qos-nslp-14.txt Title: NSLP for Quality-of-Service Signaling Abstract: This specification describes the NSIS Signaling Layer Protocol (NSLP)=20 for signaling QoS reservations in the Internet. It is in accordance=20 with the framework and requirements developed in NSIS. Together with=20 GIST, it provides functionality similar to RSVP and extends it. The QoS=20 NSLP is independent of the underlying QoS specification or architecture=20 and provides support for different reservation models. It is simplified=20 by the elimination of support for multicast flows. This specification=20 explains the overall protocol approach, design decisions made and=20 provides examples. It specifies object, message formats and processing=20 rules. Non-WG Documents Approved for publication: draft-carlberg-trip-attribute-rp-02.txt Title: TRIP Attribute for Resource Priority =09 Abstract: This document defines a new attribute for the TRIP protocol. The attribute associates protocols/services in the PSTN offering authorized prioritization during call setup that are reachable through a TRIP gateway. Current examples of preferential service in the PSTN are Government Emergency Telecommunications Service (GETS) in the U.S. and Government Telephone Preference Scheme (GTPS) in the U.K. The proposed attribute for TRIP is based on the NameSpace.Value tupple defined for the SIP resource Priority field. --=20 Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Aug 27 11:13:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPgFo-00029r-Ad; Mon, 27 Aug 2007 11:11:48 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IPgFl-00029h-K5 for sip-confirm+ok@megatron.ietf.org; Mon, 27 Aug 2007 11:11:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPgFl-00029Y-3X for sip@ietf.org; Mon, 27 Aug 2007 11:11:45 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IPgFj-0003eA-RZ for sip@ietf.org; Mon, 27 Aug 2007 11:11:45 -0400 Received: from [24.154.127.115] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1IPgFa-00054r-3q; Mon, 27 Aug 2007 10:11:34 -0500 From: "Brian Rosen" To: , References: <200708270152.l7R1qwkG003242@dragon.ariadne.com> Subject: RE: AW: [Sip] Extension of conference procedures Date: Mon, 27 Aug 2007 11:11:40 -0400 Message-ID: <058a01c7e8bc$935f9900$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <200708270152.l7R1qwkG003242@dragon.ariadne.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcfoTTv+D2YvV0UNQDW7MEbdx2bMxAAbu7Cg X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Yeah, and, coming soon, emergency call. Endpoints may have to be able to have a two way call to a call center upgraded to an emergency 3 way call using a bridge at a PSAP. This means all devices, effectively, will have to support 3891. This would occur when you call a call center that handles a wide range of help and the call center decides it needs to make the call an emergency call. It's hard to know in advance which devices may have a need to do this. Brian > -----Original Message----- > From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net] > Sent: Sunday, August 26, 2007 9:53 PM > To: sip@ietf.org > Subject: Re: AW: [Sip] Extension of conference procedures > > From: "Huelsemann, Martin" > > The disadvantage of the usage of the Repaces header is, that it > puts requirements on the UE of the invited user, it would have to > support RFC 3891. > > Why would you want to consider user agents that do not support > Replaces? They would be unable to execute consultative transfers, > call pick-ups, and many other features. > > Dale > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Aug 27 11:20:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPgMq-0003vZ-H9; Mon, 27 Aug 2007 11:19:04 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IPgMo-0003tx-UA for sip-confirm+ok@megatron.ietf.org; Mon, 27 Aug 2007 11:19:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPgMo-0003sp-Jk for sip@ietf.org; Mon, 27 Aug 2007 11:19:02 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IPgMn-0003tm-4T for sip@ietf.org; Mon, 27 Aug 2007 11:19:02 -0400 Received: from [24.154.127.115] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1IPgMd-0005rD-AB; Mon, 27 Aug 2007 10:18:51 -0500 From: "Brian Rosen" To: "'McFarland, Keith A.'" , References: <648E1817B5F395409B5C6A8CEA708A3F613B37@vwcmxbk01.vmobile-corp.com> Subject: RE: [Sip] SIP Recommended Call Flows for an MVNO? Date: Mon, 27 Aug 2007 11:18:57 -0400 Message-ID: <059001c7e8bd$97e66430$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <648E1817B5F395409B5C6A8CEA708A3F613B37@vwcmxbk01.vmobile-corp.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcfkS7fykhZlLTgwSwmzHXAf4FgqGwEcRtDQ X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 2bcdb6f0ba9636bf286b7e28ccb8bd9b Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0747750616==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0747750616== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0591_01C7E89C.10D4C430" This is a multi-part message in MIME format. ------=_NextPart_000_0591_01C7E89C.10D4C430 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Why do you want to turn SIP into an authorization service? Why wouldn't the actual proxy use something like a web service or other data query/response mechanism to ask your server what to do with the call? Are you anticipating deploying this in an IMS environment? If so, an application server can do what you want. In an non-IMS environment, every server implementation I've seen has some way to access an external authorization mechanism of one kind or another. That would be proprietary, but probably still the most appropriate response. If you WANT to be on the call path, then you have a real proxy server, and your proxy server would just respond with a redirect. I presume that "denial" is actually redirect to some announcement generator, so it's always a redirect one way or another. Brian _____ From: McFarland, Keith A. [mailto:Keith.McFarland@virginmobileusa.com] Sent: Tuesday, August 21, 2007 7:34 PM To: sip@ietf.org Subject: [Sip] SIP Recommended Call Flows for an MVNO? All, I have been reviewing SIP documents at IETF and have come to the conclusion that there is not an exact recommended procedure to cover my desired use of the SIP implementation. As you can tell from my email address I am the voice architect at Virgin Mobile USA, LLC. I am currently, considering future implementations to interface with our prepaid rating engine. As part of this consideration I am evaluating leapfrog to IP call control versus an evolution within SS7. My preference is to move to SIP if possible. However, in an MVNO the use of SIP would vary slightly from the current best practices. I would envision the SIP proxy to be replaced with a SIP 3rd Party Call Authorization and Control Server. This 3rd Party server does not sit in the middle of the SIP call flow (as does a proxy or 3pcc) but sits off to the side and other proxies (MSC or PSTN switches, in this case they act as SIP gateways) would call out to this 3rd party SIP server to get direction on voice call treatment. This call treatment could include just simple authorization to proceed, denial, redirection with or without special treatment etc. What I am trying to find is a best practices to cover this scenario. Perhaps it exists and you could just help me out by pointing me to the best practices document. If it doesn't, what are our options to go down the path to develop one? We are willing to move forward with an implementation of this but would prefer to do so with the support of a best practices or recommended practices from IETF. Having this would obviously benefit our efforts as we would have to work with multiple switch vendors for any modifications. Obviously, it would be more advantageous to these vendors to implement this if it is based off of recommended practices as the resale potential goes up. Appreciate your time, Keith A. McFarland Voice Architecture Manager Virgin Mobile USA, LLC 925-457-6536 ------=_NextPart_000_0591_01C7E89C.10D4C430 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Why do you want to turn SIP into an authorization service?  Why wouldn’t the actual proxy use = something like a web service or other data query/response mechanism to ask your = server what to do with the call?

 

Are you anticipating deploying this = in an IMS environment?  If so, an application server can do what you = want.  In an non-IMS environment, every server implementation I’ve seen = has some way to access an external authorization mechanism of one kind or = another.  That would be proprietary, but probably still the most appropriate = response.

 

If you WANT to be on the call path, = then you have a real proxy server, and your proxy server would just respond with = a redirect.  I presume that “denial” is actually redirect = to some announcement generator, so it’s always a redirect one way or another.

 

Brian

 

From: = McFarland, Keith A. [mailto:Keith.McFarland@virginmobileusa.com]
Sent: Tuesday, August 21, = 2007 7:34 PM
To: sip@ietf.org
Subject: [Sip] SIP = Recommended Call Flows for an MVNO?

 

All,

 

I have been reviewing SIP documents at IETF and have = come to the conclusion that there is not an exact recommended procedure to cover = my desired use of the SIP implementation. As you can tell from my email = address I am the voice architect at Virgin Mobile USA, LLC. I am currently, considering future implementations to interface with our prepaid rating = engine. As part of this consideration I am evaluating leapfrog to IP call = control versus an evolution within SS7. My preference is to move to SIP if = possible. However, in an MVNO the use of SIP would vary slightly from the current = best practices. I would envision the SIP proxy to be replaced with a SIP = 3rd Party Call Authorization and Control = Server.

 

This 3rd Party server does not sit in the = middle of the SIP call flow (as does a proxy or 3pcc) but sits off to the side and = other proxies (MSC or PSTN switches, in this case they act as SIP gateways) = would call out to this 3rd party SIP server to get direction on = voice call treatment. This call treatment could include just simple authorization = to proceed, denial, redirection with or without special treatment etc. What = I am trying to find is a best practices to cover this scenario. Perhaps it = exists and you could just help me out by pointing me to the best practices = document. If it doesn’t, what are our options to go down the path to develop = one? We are willing to move forward with an implementation of this but would = prefer to do so with the support of a best practices or recommended practices = from IETF. Having this would obviously benefit our efforts as we would have = to work with multiple switch vendors for any modifications. Obviously, it would = be more advantageous to these vendors to implement this if it is based off of recommended practices as the resale potential goes = up.

 

 

Appreciate your time,

 

 

Keith A. McFarland

Voice Architecture = Manager

Virgin Mobile USA, = LLC

925-457-6536 =   

------=_NextPart_000_0591_01C7E89C.10D4C430-- --===============0747750616== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0747750616==-- From sip-bounces@ietf.org Mon Aug 27 12:09:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPh7R-0003N7-JO; Mon, 27 Aug 2007 12:07:13 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IPh7R-0003N2-0t for sip-confirm+ok@megatron.ietf.org; Mon, 27 Aug 2007 12:07:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPh7Q-0003Mu-NY for sip@ietf.org; Mon, 27 Aug 2007 12:07:12 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IPh7P-0005B3-Gp for sip@ietf.org; Mon, 27 Aug 2007 12:07:12 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 27 Aug 2007 12:07:11 -0400 X-IronPort-AV: i="4.19,312,1183348800"; d="scan'208"; a="69182223:sNHT53510798" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l7RG7BXw004711; Mon, 27 Aug 2007 12:07:11 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l7RG72DL022551; Mon, 27 Aug 2007 16:07:11 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Aug 2007 12:06:54 -0400 Received: from [161.44.174.118] ([161.44.174.118]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Aug 2007 12:06:54 -0400 Message-ID: <46D2F69C.8010605@cisco.com> Date: Mon, 27 Aug 2007 12:06:52 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Dale.Worley@comcast.net Subject: Re: [Sip] SDP offer/answer -- Port 9 References: <200708270055.l7R0tbRL031450@dragon.ariadne.com> In-Reply-To: <200708270055.l7R0tbRL031450@dragon.ariadne.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Aug 2007 16:06:54.0329 (UTC) FILETIME=[493C9690:01C7E8C4] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3119; t=1188230831; x=1189094831; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20SDP=20offer/answer=20--=20Port=209 |Sender:=20 |To:=20Dale.Worley@comcast.net; bh=RUnJecJnsw3aNr/GQFg2TjdvE97mmCevTvxUS1KvQGs=; b=uYMQBzTD/WW+9+CTvefSlK02PuH6Tg5zSp8DeCCaj/oo9Ggc8YWry64qzpaoyZNhw1qzlbjH MIYIzsRBBc1hC3aVSYyTYVYqIBhokFwykHobVhS50NSloAW6YeUfQj0B; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I didn't notice anyone mention the particular significance of port 9. It is the "discard" port. I'm guessing the choice of this port isn't an accident. Rounding down to port 8, while correct if no a=rtcp is present, may not achieve the intended effect. I'm curious *why* port 9 is being used in the answer. Paul Dale.Worley@comcast.net wrote: > From: "Iliff, Tina" > > Hi! I have encountered an application in the "real world" which > provides port 9 in the SDP answer in the 200OK. The SDP m line > indicates RTP/AVP. I recognize that port 9 is acceptable if the SDP m > line indicates BFCP. My question is: Is port 9 acceptable for > RTP/AVP. [...] > > P.S. RFC2327 noted a range of 1024-65535 for RTP ports; however, > RFC4566 does not indicate a specific range. > > Since RFC 4566 is the latest standard and does not restrict the port > number to a particular range, you should not restrict the port number. > In addition, unless there is a specific functional reason, an > application should never place a restriction on a port number supplied > by the other end, regardless of the standard. > > More interesting is RFC 3550, in which the use of even/odd port number > pairs is described for the corresponding RTP and RTCP streams: > > 11. RTP over Network and Transport Protocols > > RTP relies on the underlying protocol(s) to provide demultiplexing of > RTP data and RTCP control streams. For UDP and similar protocols, > RTP SHOULD use an even destination port number and the corresponding > RTCP stream SHOULD use the next higher (odd) destination port number. > For applications that take a single port number as a parameter and > derive the RTP and RTCP port pair from that number, if an odd number > is supplied then the application SHOULD replace that number with the > next lower (even) number to use as the base of the port pair. > > So by default, specifying port 9 means that RTP is on port 8 and RTCP > is on port 9. But SDP also allows the RTCP port to be specified > separately. RFC 4566: > > 5.14. Media Descriptions ("m=") > > If non-contiguous ports are used or if they don't follow the > parity rule of even RTP ports and odd RTCP ports, the "a=rtcp:" > attribute MUST be used. > > And continuing with RFC 3550: > > For applications in which the RTP and RTCP destination port numbers > are specified via explicit, separate parameters (using a signaling > protocol or other means), the application MAY disregard the > restrictions that the port numbers be even/odd and consecutive > although the use of an even/odd port pair is still encouraged. > > Dale > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Aug 27 13:45:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPidK-0002Od-BJ; Mon, 27 Aug 2007 13:44:14 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IPidI-0002Jx-Cc for sip-confirm+ok@megatron.ietf.org; Mon, 27 Aug 2007 13:44:12 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPidG-0002Ii-Pa; Mon, 27 Aug 2007 13:44:10 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IPidF-0003fu-6e; Mon, 27 Aug 2007 13:44:10 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 27 Aug 2007 10:44:08 -0700 X-IronPort-AV: i="4.19,312,1183359600"; d="scan'208"; a="8948966:sNHT37752318" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l7RHi8I9018831; Mon, 27 Aug 2007 10:44:08 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l7RHi7lH024692; Mon, 27 Aug 2007 17:44:08 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Aug 2007 10:43:58 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.91.203]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Aug 2007 10:43:58 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 27 Aug 2007 12:43:56 -0500 To: Magnus Westerlund , Magnus Westerlund From: "James M. Polk" Subject: Re: [Sip] Re: Draft Liaison response to SG13 on Emergency Telecommunications In-Reply-To: <46D2E80E.8000001@ericsson.com> References: <46AF5370.9020304@ericsson.com> <46D2E80E.8000001@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Message-ID: X-OriginalArrivalTime: 27 Aug 2007 17:43:58.0357 (UTC) FILETIME=[D8A0BC50:01C7E8D1] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=13773; t=1188236648; x=1189100648; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Sip]=20Re=3A=20Draft=20Liaison=20response=20to=20SG1 3=20on=20Emergency=0A=20=20Telecommunications |Sender:=20; bh=sD60hnFy/1jeEK1NSSply5RPrbOwmB6enSRDS4sAZwA=; b=NJ5rCWq1ZGUUY+eJFusmZiG9HMDYbUGWMPHFX+snThPELoZWBHziyWTEWKUzwvNCia6c+Xib Su+2TerJMq4GI4YlehPPQ+olRzN0EU6a4fDGso7kncfj3xpvjujDn5RU; Authentication-Results: sj-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d8921dd2ebcb07edebf7bfaf4808c2ad Cc: sip@ietf.org, IETF SIPPING WG , tsvwg , NSIS X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Magnus comments in-line below about from which WG certain documents originated At 10:04 AM 8/27/2007, Magnus Westerlund wrote: >Hi, > >I have now updated this liaison reply to take=20 >the comments into account. According to the=20 >ECRIT chairs they don't think what they are=20 >working is related to the ongoing work Q.3/13 is=20 >working on. If you have any final comments=20 >please provide them no later then the Wednesday 29th at 16.00 CEST. > >Magnus Westerlund > > >Submission >Date: , 2007 > >From: IETF Working groups TSVWG, NSIS, SIP and SIPPING > >To: Georges Sebek , > Keith Knightson > >Cc: Magnus Westerlund , > Lars Eggert , > James Polk , > Martin Stiemerling , > John Loughney > Dean Willis , > Keith Drage , > Mary Barnes , > Gonzalo Camarillo , > Scott Bradner , > Kimberly King , > Scott Brim > >Response >Contact: TSV WG (tsv-chairs@tools.ietf.org) > NSIS (nsis-chairs@tools.ietf.org) > SIPPING (sipping-chairs@tools.ietf.org) > SIP (sip-chairs@tools.ietf.org) > >Purpose: Response to Liaison Request > >Deadline: None > >Title: Response to liaison request from ITU-T=20 >Study Group 13 work on emergency telecommunications > >This is a response to the liaison request made=20 >by Q.3/13 regarding emergency telecommunications=20 >(REF: NGN-GSI/DOC =AD 60 Rev.2). We woould first=20 >like to apologize for failing to meet the=20 >deadline in responding. We do hope that the late=20 >answer still can be of some use. > >The liaison request was made to the following=20 >working groups (WG): IEPREP, TSVWG, and NSIS.=20 >Since the request was sent the IEPREP WG has=20 >concluded. In addition to the WGs from which=20 >information was requested, we also think that=20 >work performed by the SIP and SIPPING WG may be of relevance. > >Pursuant to ITU-T Study Group 13 request for=20 >information on relevant and related work in the=20 >IETF regarding emergency communications, we list=20 >below RFCs and works in progress that we feel=20 >may be of interest to your group. Some of the=20 >completed work is Informational, and others are=20 >in the category of Standards Track. > >Q.3/13 also requested that we keep you informed=20 >of any developments in regards to emergency=20 >telecommunications. In those regards we would=20 >like to make you aware that IETF mailing list=20 >participation and document information is free=20 >and open to anyone, allowing participants in=20 >Q.3/13 to keep themselves informed of any=20 >developments. If Q.3/13 desire to get further=20 >information about specific ongoing work, then=20 >please send a liaison request to the responsible=20 >WG for those specific documents. > >The following list is divided under the=20 >associated working groups from which the work has been done within the= IETF. > > >SIP Working Group > >RFC 4411 RFC4411 is from SIPPING >Title: > Extending the Session Initiation Protocol (SIP) > Reason Header for Preemption Events > >Abstract: > This document proposes an IANA Registration extension to the Session > Initiation Protocol (SIP) Reason Header to be included in a BYE > Method Request as a result of a session preemption event, either at a > user agent (UA), or somewhere in the network involving a > reservation-based protocol such as the Resource ReSerVation Protocol > (RSVP) or Next Steps in Signaling (NSIS). This document does not > attempt to address routers failing in the packet path; instead, it > addresses a deliberate tear down of a flow between UAs, and informs > the terminated UA(s) with an indication of what occurred. > >RFC 4412 > >Title: > Communications Resource Priority for the Session Initiation > Protocol (SIP) > >Abstract: > This document defines two new Session Initiation Protocol (SIP) > header fields for communicating resource priority, namely, > "Resource-Priority" and "Accept-Resource-Priority". The > "Resource-Priority" header field can influence the behavior of SIP > user agents (such as telephone gateways and IP telephones) and SIP > proxies. It does not directly influence the forwarding behavior of > IP routers. > > > >SIPPING Working Group both IDs below are SIP WG items, not SIPPING > The below two documents are proposed=20 > work items accepted to become IETF WG items are=20 > likely of interest as they update RFC 4412. > >Work In Progress: draft-polk-sip-rph-in-responses-00 > >Title: >Allowing SIP Resource Priority Header in SIP Responses > >Abstract: > The Session Initiation Protocol (SIP) Resource Priority Header > (RPH), in its current form, is ignored in SIP responses. This was a > design choice during RFC 4412's development. This is now considered > a bad design choice in certain scenarios. This document corrects > RFC 4412's communications model by optionally allowing a SIP server > or user agent client to process the Resource-Priority Header in a > response. > >Work In Progress: draft-polk-sip-rph-new-namespaces--00 > >Title: >New Session Initiation Protocol=20 >Resource-Priority Header Namespaces for the Defense Information Systems= Agency > >Abstract: > This document creates additional Session Initiation Protocol > Resource-Priority header namespaces, to be IANA registered. This > document intends to update RFC 4412, as a Proposed Standard document > if published by the RFC-Editor. > >IEPREP Working Group > >RFC 3487 > >Title: > Requirements for Resource Priority Mechanisms for the > Session Initiation Protocol (SIP) > >Abstract: > This document summarizes requirements for prioritizing access to > circuit-switched network, end system and proxy resources for > emergency preparedness communications using the Session Initiation > Protocol (SIP). > >RFC 3689 > >Title: > General Requirements for > Emergency Telecommunication Service (ETS) > >Abstract: > This document presents a list of general requirements in support of > Emergency Telecommunications Service (ETS). Solutions to these > requirements are not presented in this document. Additional > requirements pertaining to specific applications, or types of > applications, are to be specified in separate document(s). > >RFC 3690 > >Title: > IP Telephony Requirements for > Emergency Telecommunication Service (ETS) > >Abstract: > This document presents a list of requirements in support of Emergency > Telecommunications Service (ETS) within the context of IP telephony. > It is an extension to the general requirements presented in RFC 3689. > Solutions to these requirements are not presented in this document. > >RFC 4190 > >Title: > Framework for Supporting Emergency Telecommunications > Service (ETS) in IP Telephony > >Abstract: > This document presents a framework for supporting authorized, > emergency-related communication within the context of IP telephony. > We present a series of objectives that reflect a general view of how > authorized emergency service, in line with the Emergency > Telecommunications Service (ETS), should be realized within today's > IP architecture and service models. From these objectives, we > present a corresponding set of protocols and capabilities, which > provide a more specific set of recommendations regarding existing > IETF protocols. Finally, we present two scenarios that act as > guiding models for the objectives and functions listed in this > document. These models, coupled with an example of an existing > service in the Public Switched Telephone Network (PSTN), contribute > to a constrained solution space. > >RFC 4375 > >Title: > Emergency Telecommunications Services (ETS) Requirements > for a Single Administrative Domain > >Abstract: > This document presents a list of requirements in support of Emergency > Telecommunications Service (ETS) within a single administrative > domain. This document focuses on a specific set of administrative > constraints and scope. Solutions to these requirements are not > presented in this document. > > >TSV Working Group > >RFC 4542 > >Title: > Implementing an Emergency Telecommunications Service (ETS) > for Real-Time Services in the Internet Protocol Suite > >Abstract: > RFCs 3689 and 3690 detail requirements for an Emergency > Telecommunications Service (ETS), of which an Internet Emergency > Preparedness Service (IEPS) would be a part. Some of these types of > services require call preemption; others require call queuing or > other mechanisms. IEPS requires a Call Admission Control (CAC) > procedure and a Per Hop Behavior (PHB) for the data that meet the > needs of this architecture. Such a CAC procedure and PHB is > appropriate to any service that might use H.323 or SIP to set up > real-time sessions. The key requirement is to guarantee an elevated > probability of call completion to an authorized user in time of > crisis. > > This document primarily discusses supporting ETS in the context of > the US Government and NATO, because it focuses on the Multi-Level > Precedence and Preemption (MLPP) and Government Emergency > Telecommunication Service (GETS) standards. The architectures > described here are applicable beyond these organizations. > >Work In Progress: draft-ietf-tsvwg-emergency-rsvp-03.txt > >Title: > Resource ReSerVation Protovol (RSVP) Extensions for > Emergency Services > >Abstract: > An Emergency Telecommunications Service (ETS) requires the ability to > provide an elevated probability of session establishment to an > authorized user in times of network congestion (typically, during a > crisis). When supported over the Internet Protocol suite, this may be > facilitated through a network layer admission control solution, which > supports prioritized access to resources (e.g., bandwidth). These > resources may be explicitly set aside for emergency services, or they > may be shared with other sessions. > > This document specifies RSVP extensions that can be used to support > such an admission priority capability at the network layer. Note that > these extensions represent one possible solution component in > satisfying ETS requirements. Other solution components, or other > solutions, are outside the scope of this document. > >NSIS Working Group > >Work In Progress: draft-ietf-nsis-qos-nslp-14.txt > >Title: >NSLP for Quality-of-Service Signaling > >Abstract: >This specification describes the NSIS Signaling=20 >Layer Protocol (NSLP) for signaling QoS=20 >reservations in the Internet. It is in=20 >accordance with the framework and requirements=20 >developed in NSIS. Together with GIST, it=20 >provides functionality similar to RSVP and=20 >extends it. The QoS NSLP is independent of the=20 >underlying QoS specification or architecture and=20 >provides support for different reservation=20 >models. It is simplified by the elimination of=20 >support for multicast flows. This specification=20 >explains the overall protocol approach, design=20 >decisions made and provides examples. It=20 >specifies object, message formats and processing rules. > >Non-WG Documents > > Approved for publication: draft-carlberg-trip-attribute-rp-02.txt > > Title: > TRIP Attribute for Resource Priority > >Abstract: > This document defines a new attribute for the TRIP protocol. The > attribute associates protocols/services in the PSTN offering > authorized prioritization during call setup that are reachable > through a TRIP gateway. Current examples of preferential service in > the PSTN are Government Emergency Telecommunications Service (GETS) > in the U.S. and Government Telephone Preference Scheme (GTPS) in the > U.K. The proposed attribute for TRIP is based on the NameSpace.Value > tupple defined for the SIP resource Priority field. > > > >-- > >Magnus Westerlund > >IETF Transport Area Director & TSVWG Chair >---------------------------------------------------------------------- >Multimedia Technologies, Ericsson Research EAB/TVM/M >---------------------------------------------------------------------- >Ericsson AB | Phone +46 8 4048287 >Torshamsgatan 23 | Fax +46 8 7575550 >S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >---------------------------------------------------------------------- > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Aug 27 13:56:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPinJ-0007am-R0; Mon, 27 Aug 2007 13:54:33 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IPinI-0007ae-OH for sip-confirm+ok@megatron.ietf.org; Mon, 27 Aug 2007 13:54:32 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPinI-0007aW-Da; Mon, 27 Aug 2007 13:54:32 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IPinI-00040u-07; Mon, 27 Aug 2007 13:54:32 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l7RHqLk23484; Mon, 27 Aug 2007 17:52:22 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Re: [Sip] draft-rosenberg-sip-ua-loose-route-01.txt Date: Mon, 27 Aug 2007 12:54:27 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF11C734E1@zrc2hxm0.corp.nortel.com> In-Reply-To: <46D264F9.6080101@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Re: [Sip] draft-rosenberg-sip-ua-loose-route-01.txt Thread-Index: AcfobP8d5kwYvd19RLqL4XAC1Z20ggAZSGsQ References: <46CAE441.8080504@gmx.net> <46D1C942.7010501@gmx.net> <46D264F9.6080101@softarmor.com> From: "Francois Audet" To: "Dean Willis" , "Hannes Tschofenig" X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: IETF SIP List , ECRIT X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Frankly, I tought the conclusion was to investigate if pros and cons of two approches: 1 - Loose route approach 2 - Having a header with the original target (P-Called-Party-ID, RFC 3455) > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: Sunday, August 26, 2007 22:45 > To: Hannes Tschofenig > Cc: IETF SIP List; ECRIT > Subject: Re: [Ecrit] Re: [Sip]=20 > draft-rosenberg-sip-ua-loose-route-01.txt >=20 > Hannes Tschofenig wrote: > > No response received -- resend. > >=20 > > Hannes Tschofenig wrote: > >=20 > >> Dear SIP WG members, > >> > >> during the ECRIT meeting we learned that the SIP working group=20 > >> "rejected" the concept described in=20 > >> draft-rosenberg-sip-ua-loose-route-01.txt. > >> > >> Could someone please give us more information about this=20 > decision as=20 > >> it impacts the work we do in ECRIT? >=20 > I wouldn't say that UA Loose Route was "rejected" so much as=20 > "does not yet have consensus". >=20 > This is in part influenced by "WG doesn't seem to have a=20 > compelling reason to make such a significant change." >=20 > Perhaps ECRIT has a compelling reason? >=20 > -- > Dean >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Aug 27 13:57:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPioZ-0000bj-PT; Mon, 27 Aug 2007 13:55:51 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IPioY-0000Yl-6f for sip-confirm+ok@megatron.ietf.org; Mon, 27 Aug 2007 13:55:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPioX-0000Yc-TP for sip@ietf.org; Mon, 27 Aug 2007 13:55:49 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IPioW-0008Pf-K7 for sip@ietf.org; Mon, 27 Aug 2007 13:55:49 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l7RHtjH16337 for ; Mon, 27 Aug 2007 17:55:46 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: FW: [Sip] I-D ACTION:draft-ietf-sip-sips-06.txt Date: Mon, 27 Aug 2007 12:55:44 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF11C734ED@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] I-D ACTION:draft-ietf-sip-sips-06.txt Thread-Index: Acfmi5SUatSZB9zFStOLdVR7MKpJ5QCR8k1Q From: "Francois Audet" To: "IETF SIP List" X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 > Sent: Friday, August 24, 2007 13:15 > To: i-d-announce@ietf.org > Cc: sip@ietf.org > Subject: [Sip] I-D ACTION:draft-ietf-sip-sips-06.txt >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > This draft is a work item of the Session Initiation Protocol=20 > Working Group of the IETF. >=20 > Title : The use of the SIPS URI Scheme in the=20 > Session Initiation Protocol (SIP) > Author(s) : F. Audet > Filename : draft-ietf-sip-sips-06.txt > Pages : 54 > Date : 2007-8-24 > =09 > This document provides clarifications and guidelines concerning the > use of the SIPS URI scheme in the Session Initiation=20 > Protocol (SIP). > It also makes normative changes to SIP. This document=20 > also provides > a discussion of possible future steps in specification. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sip-sips-06.txt >=20 > To remove yourself from the I-D Announcement list, send a=20 > message to i-d-announce-request@ietf.org with the word=20 > unsubscribe in the body of the message.=20 > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. >=20 > Internet-Drafts are also available by anonymous FTP. Login=20 > with the username "anonymous" and a password of your e-mail=20 > address. After logging in, type "cd internet-drafts" and then=20 > "get draft-ietf-sip-sips-06.txt". >=20 > A list of Internet-Drafts directories can be found in=20 > http://www.ietf.org/shadow.html or=20 > ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-sip-sips-06.txt". > =09 > 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=20 > 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. >=20 > Below is the data which will enable a MIME compliant mail=20 > reader implementation to automatically retrieve the ASCII=20 > version of the Internet-Draft. >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Aug 27 15:17:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPk3h-0007ro-5w; Mon, 27 Aug 2007 15:15:33 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IPk3g-0007rj-5w for sip-confirm+ok@megatron.ietf.org; Mon, 27 Aug 2007 15:15:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPk3f-0007rb-Sb for sip@ietf.org; Mon, 27 Aug 2007 15:15:31 -0400 Received: from smtp.mitel.com ([216.191.234.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IPk3e-0002Oo-Hr for sip@ietf.org; Mon, 27 Aug 2007 15:15:31 -0400 Received: from localhost (smtp.mitel.com [127.0.0.1]) by smtp.mitel.com (Postfix) with ESMTP id 0841D2C0AB; Mon, 27 Aug 2007 15:15:30 -0400 (EDT) X-Virus-Scanned: by amavisd-new (virusonly) at mitel.com Received: from smtp.mitel.com ([127.0.0.1]) by localhost (smtp.mitel.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BKrZr4KMtHwO; Mon, 27 Aug 2007 15:15:28 -0400 (EDT) Received: from kanmta01.mitel.com (kanmta01 [134.199.37.58]) by smtp.mitel.com (Postfix) with ESMTP id D7AA82C01E; Mon, 27 Aug 2007 15:15:28 -0400 (EDT) In-Reply-To: To: Eric Burger Subject: Re: [Sip] INFO MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: peter_blatherwick@mitel.com Date: Mon, 27 Aug 2007 15:15:25 -0400 X-MIMETrack: Serialize by Router on kanmta01/Mitel(Release 5.0.12 |February 13, 2003) at 08/27/2007 03:15:26 PM, Serialize complete at 08/27/2007 03:15:26 PM X-Spam-Score: 0.0 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f Cc: 'sip' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1841117004==" Errors-To: sip-bounces@ietf.org This is a multipart message in MIME format. --===============1841117004== Content-Type: multipart/alternative; boundary="=_alternative 0069C88E85257344_=" This is a multipart message in MIME format. --=_alternative 0069C88E85257344_= Content-Type: text/plain; charset="US-ASCII" Hi Eric, all, I assume the main intent of the post is to determine whether to proceed further on the INFO draft or not, and draw any significant early flames. > If you like it, say so. If you hate it, say so. I like it, and I hate it ;-) But, to be slightly more specific, while hopefully vague enough for misinterpretation... I support the overall effort. It is certainly useful to write down and clarify why INFO is bad in some regards. And it may be good in some other regards of course. This would remove disinformation and add concrete reasoning to any debates. Such debates have been fairly numerous, and for the most part pointlessly vague. I agree with most conclusions. BUT, looking especially at section 4, there are other similar uses which are equally valid and equivalent to SIP-T/QSig, notably transport of other end-end signalling such as DPNSS or similar. I believe that the doc should allow for the class of similar cases, ie say basically: "INFO is ok/good for its original intent, which is to carry end-end signalling between ends that understand common signalling other than SIP, and need it as part of their gateway (or other) functions". I also believe the document should be aimed at Informational, or possibly BCP, since it gives context, explanation and advice. Don't see the value in updating INFO Method RFC 2976, if that were to mean including the MUST NOTs of sec 4 in a rev of that spec or anything functionally equivalent to that. It could not be enforced in any way ("not the protocol police"). And besides the cat is already out of that bag anyway. -- Peter Eric Burger 21.08.07 17:37 To: "'sip'" cc: Subject: [Sip] INFO Since list traffic is down, how about something to spice things up? Any thoughts on http://www.ietf.org/internet-drafts/draft-burger-sip-info-01.txt ??? If you like it, say so. If you hate it, say so. Text welcome. Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete 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 --=_alternative 0069C88E85257344_= Content-Type: text/html; charset="US-ASCII"
Hi Eric, all,

I assume the main intent of the post is to determine whether to proceed further on the INFO draft or not, and draw any significant early flames.  

> If you like it, say so.  If you hate it, say so.

I like it, and I hate it ;-)    

But, to be slightly more specific, while hopefully vague enough for misinterpretation...    

I support the overall effort.  It is certainly useful to write down and clarify why INFO is bad in some regards.  And it may be good in some other regards of course.  This would remove disinformation and add concrete reasoning to any debates.  Such debates have been fairly numerous, and for the most part pointlessly vague.  

I agree with most conclusions.  BUT, looking especially at section 4, there are other similar uses which are equally valid and equivalent to SIP-T/QSig, notably transport of other end-end signalling such as DPNSS or similar.  I believe that the doc should allow for the class of similar cases, ie say basically: "INFO is ok/good for its original intent, which is to carry end-end signalling between ends that understand common signalling other than SIP, and need it as part of their gateway (or other) functions".  

I also believe the document should be aimed at Informational, or possibly BCP, since it gives context, explanation and advice.  Don't see the value in updating INFO Method RFC 2976, if that were to mean including the MUST NOTs of sec 4 in a rev of that spec or anything functionally equivalent to that.  It could not be enforced in any way ("not the protocol police").  And besides the cat is already out of that bag anyway.  

-- Peter




Eric Burger <eburger@bea.com>

21.08.07 17:37

       
        To:        "'sip'" <sip@ietf.org>
        cc:        
        Subject:        [Sip] INFO



Since list traffic is down, how about something to spice things up?


Any thoughts on

http://www.ietf.org/internet-drafts/draft-burger-sip-info-01.txt

???

If you like it, say so.  If you hate it, say so.

Text welcome.


Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete 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
--=_alternative 0069C88E85257344_=-- --===============1841117004== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1841117004==-- From sip-bounces@ietf.org Mon Aug 27 20:37:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPp3D-0006D2-Nw; Mon, 27 Aug 2007 20:35:23 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IPkZI-0006Xj-6a for sip-confirm+ok@megatron.ietf.org; Mon, 27 Aug 2007 15:48:12 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPkZH-0006Wv-Pk for sip@ietf.org; Mon, 27 Aug 2007 15:48:11 -0400 Received: from mail1.vmobl.com ([205.239.227.29] helo=vscpsmgw06.vmuprod.local) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IPkZH-0007rJ-97 for sip@ietf.org; Mon, 27 Aug 2007 15:48:11 -0400 Received: from vscsmtp.vmobile-corp.com (mail2.vmobl.com [205.239.227.49]) by vscpsmgw06.vmuprod.local (Switch-3.2.5/Switch-3.2.2) with ESMTP id l7RJm9X2010454 for ; Mon, 27 Aug 2007 12:48:09 -0700 (PDT) Received: from vwcmxbk01.vmobile-corp.com (vwcmxbk01.vmobile-corp.com [10.1.33.60]) by vscsmtp.vmobile-corp.com (Switch-3.2.5/Switch-3.2.2) with ESMTP id l7RJm2rA026011; Mon, 27 Aug 2007 12:48:07 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] SIP Recommended Call Flows for an MVNO? Date: Mon, 27 Aug 2007 12:38:46 -0700 Message-ID: <648E1817B5F395409B5C6A8CEA708A3F614128@vwcmxbk01.vmobile-corp.com> In-Reply-To: <059001c7e8bd$97e66430$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] SIP Recommended Call Flows for an MVNO? Thread-Index: AcfkS7fykhZlLTgwSwmzHXAf4FgqGwEcRtDQAAjcTdA= References: <648E1817B5F395409B5C6A8CEA708A3F613B37@vwcmxbk01.vmobile-corp.com> <059001c7e8bd$97e66430$640fa8c0@cis.neustar.com> From: "McFarland, Keith A." To: "Brian Rosen" , X-Spam-Score: 0.00% X-MASF: 0.00% X-Spam-Score: 0.0 (/) X-Scan-Signature: e52c6009a9b39871b75233310d7f3490 X-Mailman-Approved-At: Mon, 27 Aug 2007 20:35:22 -0400 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1717328754==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1717328754== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7E8E1.E312381C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7E8E1.E312381C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable To answer your question, yes I am considering the implementation in an IMS environment. I have theorized that an AS in that model would support this. However, I was looking for some best practices flows that define this. This would be of great benefit to have this when integrating with various MSC (from multiple vendors) or other points. Additionally, I don't envision a need to be on the call path necessary for setting up the two call legs but rather just queried and passed call information related to the call (one call leg per query) to perform real time authorization billing etc from those messages. It seemed to me that the natural evolution of the market place and that of SIP in general would include this call flow more commonly in the future and I was seeking out options of best recommended implementations. =20 The benefit to me of doing this via SIP is the natural evolution of this implementation to VoIP later. Additionally, all the existing messages and parameters necessary are defined in the SIP standard. =20 Thanks, =20 Keith A. McFarland =20 ________________________________ From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Monday, August 27, 2007 8:19 AM To: McFarland, Keith A.; sip@ietf.org Subject: RE: [Sip] SIP Recommended Call Flows for an MVNO? =20 Why do you want to turn SIP into an authorization service? Why wouldn't the actual proxy use something like a web service or other data query/response mechanism to ask your server what to do with the call? =20 Are you anticipating deploying this in an IMS environment? If so, an application server can do what you want. In an non-IMS environment, every server implementation I've seen has some way to access an external authorization mechanism of one kind or another. That would be proprietary, but probably still the most appropriate response. =20 If you WANT to be on the call path, then you have a real proxy server, and your proxy server would just respond with a redirect. I presume that "denial" is actually redirect to some announcement generator, so it's always a redirect one way or another. =20 Brian =20 ________________________________ From: McFarland, Keith A. [mailto:Keith.McFarland@virginmobileusa.com]=20 Sent: Tuesday, August 21, 2007 7:34 PM To: sip@ietf.org Subject: [Sip] SIP Recommended Call Flows for an MVNO? =20 All, =20 I have been reviewing SIP documents at IETF and have come to the conclusion that there is not an exact recommended procedure to cover my desired use of the SIP implementation. As you can tell from my email address I am the voice architect at Virgin Mobile USA, LLC. I am currently, considering future implementations to interface with our prepaid rating engine. As part of this consideration I am evaluating leapfrog to IP call control versus an evolution within SS7. My preference is to move to SIP if possible. However, in an MVNO the use of SIP would vary slightly from the current best practices. I would envision the SIP proxy to be replaced with a SIP 3rd Party Call Authorization and Control Server. =20 This 3rd Party server does not sit in the middle of the SIP call flow (as does a proxy or 3pcc) but sits off to the side and other proxies (MSC or PSTN switches, in this case they act as SIP gateways) would call out to this 3rd party SIP server to get direction on voice call treatment. This call treatment could include just simple authorization to proceed, denial, redirection with or without special treatment etc. What I am trying to find is a best practices to cover this scenario. Perhaps it exists and you could just help me out by pointing me to the best practices document. If it doesn't, what are our options to go down the path to develop one? We are willing to move forward with an implementation of this but would prefer to do so with the support of a best practices or recommended practices from IETF. Having this would obviously benefit our efforts as we would have to work with multiple switch vendors for any modifications. Obviously, it would be more advantageous to these vendors to implement this if it is based off of recommended practices as the resale potential goes up. =20 =20 Appreciate your time, =20 =20 Keith A. McFarland Voice Architecture Manager Virgin Mobile USA, LLC 925-457-6536 =20 ------_=_NextPart_001_01C7E8E1.E312381C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

To answer your question, yes I am considering the implementation in an IMS environment. I have theorized = that an AS in that model would support this. However, I was looking for some = best practices flows that define this. This would be of great benefit to have = this when integrating with various MSC (from multiple vendors) or other = points. Additionally, I don’t envision a need to be on the call path necessary for = setting up the two call legs but rather just queried and passed call information = related to the call (one call leg per query) to perform real time authorization = billing etc from those messages. It seemed to me that the natural evolution of = the market place and that of SIP in general would include this call flow = more commonly in the future and I was seeking out options of best recommended implementations.

 

The benefit to me of doing this via = SIP is the natural evolution of this implementation to VoIP later. = Additionally, all the existing messages and parameters necessary are defined in the SIP = standard.

 

Thanks,

=

 

Keith A. = McFarland

 

From: Brian = Rosen [mailto:br@brianrosen.net]
Sent: Monday, August 27, = 2007 8:19 AM
To: McFarland, Keith A.; sip@ietf.org
Subject: RE: [Sip] SIP = Recommended Call Flows for an MVNO?

 

Why do you want to turn SIP into an authorization service?  Why wouldn’t the actual proxy use = something like a web service or other data query/response mechanism to ask your = server what to do with the call?

 

Are you anticipating deploying this = in an IMS environment?  If so, an application server can do what you = want.  In an non-IMS environment, every server implementation I’ve seen = has some way to access an external authorization mechanism of one kind or = another.  That would be proprietary, but probably still the most appropriate = response.

 

If you WANT to be on the call path, = then you have a real proxy server, and your proxy server would just respond = with a redirect.  I presume that “denial” is actually redirect = to some announcement generator, so it’s always a redirect one way or another.

 

Brian

 

From: = McFarland, Keith A. [mailto:Keith.McFarland@virginmobileusa.com]
Sent: Tuesday, August 21, = 2007 7:34 PM
To: sip@ietf.org
Subject: [Sip] SIP = Recommended Call Flows for an MVNO?

 

All,

 

I have been reviewing SIP documents at IETF and have = come to the conclusion that there is not an exact recommended procedure to cover = my desired use of the SIP implementation. As you can tell from my email = address I am the voice architect at Virgin Mobile USA, LLC. I am currently, considering future implementations to interface with our prepaid rating = engine. As part of this consideration I am evaluating leapfrog to IP call = control versus an evolution within SS7. My preference is to move to SIP if = possible. However, in an MVNO the use of SIP would vary slightly from the current = best practices. I would envision the SIP proxy to be replaced with a SIP = 3rd Party Call Authorization and Control = Server.

 

This 3rd Party server does not sit in the = middle of the SIP call flow (as does a proxy or 3pcc) but sits off to the side = and other proxies (MSC or PSTN switches, in this case they act as SIP = gateways) would call out to this 3rd party SIP server to get direction = on voice call treatment. This call treatment could include just simple authorization to proceed, denial, redirection with or without special = treatment etc. What I am trying to find is a best practices to cover this = scenario. Perhaps it exists and you could just help me out by pointing me to the = best practices document. If it doesn’t, what are our options to go down = the path to develop one? We are willing to move forward with an = implementation of this but would prefer to do so with the support of a best practices or recommended practices from IETF. Having this would obviously benefit our efforts as we would have to work with multiple switch vendors for any modifications. Obviously, it would be more advantageous to these vendors = to implement this if it is based off of recommended practices as the resale potential goes up.

 

 

Appreciate your time,

 

 

Keith A. McFarland

Voice Architecture = Manager

Virgin Mobile USA, = LLC

925-457-6536 =   

------_=_NextPart_001_01C7E8E1.E312381C-- --===============1717328754== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1717328754==-- From sip-bounces@ietf.org Mon Aug 27 22:53:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPr7E-0004wG-RJ; Mon, 27 Aug 2007 22:47:40 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IPr7D-0004w0-Bf for sip-confirm+ok@megatron.ietf.org; Mon, 27 Aug 2007 22:47:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPr7C-0004uX-Jl; Mon, 27 Aug 2007 22:47:38 -0400 Received: from szxga04-in.huawei.com ([61.144.161.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IPr75-0005Bu-PM; Mon, 27 Aug 2007 22:47:38 -0400 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JNG008QUQDP63@szxga04-in.huawei.com>; Tue, 28 Aug 2007 10:46:37 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JNG00AUJQDOSI@szxga04-in.huawei.com>; Tue, 28 Aug 2007 10:46:37 +0800 (CST) Received: from x18916 ([10.85.28.238]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JNG0004YQDLZL@szxml03-in.huawei.com>; Tue, 28 Aug 2007 10:46:36 +0800 (CST) Date: Tue, 28 Aug 2007 10:46:31 +0800 From: Peili Xu Subject: RE: [Ecrit] Re: [Sip] draft-rosenberg-sip-ua-loose-route-01.txt In-reply-to: <1ECE0EB50388174790F9694F77522CCF11C734E1@zrc2hxm0.corp.nortel.com> To: 'Francois Audet' , 'Dean Willis' , 'Hannes Tschofenig' Message-id: <013a01c7e91d$a3ad3770$ee1c550a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-index: AcfobP8d5kwYvd19RLqL4XAC1Z20ggAZSGsQABKqaoA= X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: 'IETF SIP List' , 'ECRIT' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Yes, although there are comments and objections, I didn't aware of such consensus that the draft was totally objected by the WG. Actually, part of the solution is interesting to me. Assuming we could group the problem statements into 3 categories: a) conversion for contact binding; b) conversion for routing resolution and c) conversion for services. 1: I'd suggest using P-Called-Party-ID to for category a) problem and loose routing for the other 2. and I think Ecrit problem can be categoried as problem b or c. 2: When would proxy apply loose route after conversion for category b/c is subject to local policy or some kind of indication provided by external conversion/mapping service. 3: How to define a uri parameter for sub-address purpose is somewhat independent from the draft to me. But it's interesting. I'd suggest specifying it separately and with thorough considerations for how to implement sub-address like services in SIP. Cheers. Peili -----Original Message----- From: Francois Audet [mailto:audet@nortel.com] Sent: Tuesday, August 28, 2007 1:54 AM To: Dean Willis; Hannes Tschofenig Cc: IETF SIP List; ECRIT Subject: RE: [Ecrit] Re: [Sip] draft-rosenberg-sip-ua-loose-route-01.txt Frankly, I tought the conclusion was to investigate if pros and cons of two approches: 1 - Loose route approach 2 - Having a header with the original target (P-Called-Party-ID, RFC 3455) > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Sunday, August 26, 2007 22:45 > To: Hannes Tschofenig > Cc: IETF SIP List; ECRIT > Subject: Re: [Ecrit] Re: [Sip] > draft-rosenberg-sip-ua-loose-route-01.txt > > Hannes Tschofenig wrote: > > No response received -- resend. > > > > Hannes Tschofenig wrote: > > > >> Dear SIP WG members, > >> > >> during the ECRIT meeting we learned that the SIP working group > >> "rejected" the concept described in > >> draft-rosenberg-sip-ua-loose-route-01.txt. > >> > >> Could someone please give us more information about this > decision as > >> it impacts the work we do in ECRIT? > > I wouldn't say that UA Loose Route was "rejected" so much as "does not > yet have consensus". > > This is in part influenced by "WG doesn't seem to have a compelling > reason to make such a significant change." > > Perhaps ECRIT has a compelling reason? > > -- > 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 sip-bounces@ietf.org Tue Aug 28 03:35:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPva5-0007Bc-Iz; Tue, 28 Aug 2007 03:33:45 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IPva2-0007Au-QB for sip-confirm+ok@megatron.ietf.org; Tue, 28 Aug 2007 03:33:42 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPvZy-00078U-2t; Tue, 28 Aug 2007 03:33:38 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IPvZw-0008UK-Bj; Tue, 28 Aug 2007 03:33:37 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id B1B9C210F1; Tue, 28 Aug 2007 09:33:35 +0200 (CEST) X-AuditID: c1b4fb3e-b0835bb0000007e1-42-46d3cfcfa7e9 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 7CCBF203FB; Tue, 28 Aug 2007 09:33:35 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Aug 2007 09:33:35 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Aug 2007 09:33:35 +0200 Message-ID: <46D3CFCF.6070308@ericsson.com> Date: Tue, 28 Aug 2007 09:33:35 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 Subject: Re: [Tsvwg] Re: [Sip] Re: Draft Liaison response to SG13 on Emergency Telecommunications References: <46AF5370.9020304@ericsson.com> <46D2E80E.8000001@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed X-OriginalArrivalTime: 28 Aug 2007 07:33:35.0545 (UTC) FILETIME=[BE24DA90:01C7E945] X-Brightmail-Tracker: AAAAAA== Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.6 (+) X-Scan-Signature: 4d9ae72af46718088458d214998cc683 Cc: sip@ietf.org, dime@ietf.org, IETF SIPPING WG , tsvwg , NSIS X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi again, I have received some more comments. So here is an updated version adding=20 DIME documents and correcting origin of documents. Submission Date: , 2007 From: IETF Working groups TSVWG, NSIS, DIME, SIP and SIPPING To: Georges Sebek , Keith Knightson Cc: Magnus Westerlund , Lars Eggert , James Polk , Martin Stiemerling , John Loughney Dean Willis , Keith Drage , Mary Barnes , Gonzalo Camarillo , Scott Bradner , Kimberly King , Scott Brim , Hannes Tschofenig , David Frascone Response Contact: TSV WG (tsv-chairs@tools.ietf.org) NSIS (nsis-chairs@tools.ietf.org) SIPPING (sipping-chairs@tools.ietf.org) SIP (sip-chairs@tools.ietf.org) DIME (dime-chairs@tools.ietf.org) =09 Purpose: Response to Liaison Request Deadline: None Title: Response to liaison request from ITU-T Study Group 13 work on=20 emergency telecommunications This is a response to the liaison request made by Q.3/13 regarding=20 emergency telecommunications (REF: NGN-GSI/DOC =96 60 Rev.2). We would=20 first like to apologize for failing to meet the deadline in responding.=20 We do hope that the late answer still can be of some use. The liaison request was made to the following working groups (WG):=20 IEPREP, TSVWG, and NSIS. Since the request was sent the IEPREP WG has=20 concluded. In addition to the WGs from which information was requested,=20 we also think that work performed by the DIME, SIP and SIPPING WG may be=20 of relevance. Pursuant to ITU-T Study Group 13 request for information on relevant and=20 related work in the IETF regarding emergency communications, we list=20 below RFCs and works in progress that we feel may be of interest to your=20 group. Some of the completed work is Informational, and others are in=20 the category of Standards Track. Q.3/13 also requested that we keep you informed of any developments in=20 regards to emergency telecommunications. In those regards we would like=20 to make you aware that IETF mailing list participation and document=20 information is free and open to anyone, allowing participants in Q.3/13=20 to keep themselves informed of any developments. If Q.3/13 desire to get=20 further information about specific ongoing work, then please send a=20 liaison request to the responsible WG for those specific documents. The following list is divided under the associated working groups from=20 which the work has been done within the IETF. SIP Working Group RFC 4412 Title: Communications Resource Priority for the Session Initiation Protocol (SIP) Abstract: This document defines two new Session Initiation Protocol (SIP) header fields for communicating resource priority, namely, "Resource-Priority" and "Accept-Resource-Priority". The "Resource-Priority" header field can influence the behavior of SIP user agents (such as telephone gateways and IP telephones) and SIP proxies. It does not directly influence the forwarding behavior of IP routers. The below two documents are proposed work items accepted to become IETF=20 WG items are likely of interest as they update RFC 4412. Work In Progress: draft-polk-sip-rph-in-responses-00 Title: Allowing SIP Resource Priority Header in SIP Responses Abstract: The Session Initiation Protocol (SIP) Resource Priority Header (RPH), in its current form, is ignored in SIP responses. This was a design choice during RFC 4412's development. This is now considered a bad design choice in certain scenarios. This document corrects RFC 4412's communications model by optionally allowing a SIP server or user agent client to process the Resource-Priority Header in a response. Work In Progress: draft-polk-sip-rph-new-namespaces--00 Title: New Session Initiation Protocol Resource-Priority Header Namespaces for=20 the Defense Information Systems Agency Abstract: This document creates additional Session Initiation Protocol Resource-Priority header namespaces, to be IANA registered. This document intends to update RFC 4412, as a Proposed Standard document if published by the RFC-Editor. SIPPING Working Group RFC 4411 Title: Extending the Session Initiation Protocol (SIP) Reason Header for Preemption Events Abstract: This document proposes an IANA Registration extension to the Session Initiation Protocol (SIP) Reason Header to be included in a BYE Method Request as a result of a session preemption event, either at a user agent (UA), or somewhere in the network involving a reservation-based protocol such as the Resource ReSerVation Protocol (RSVP) or Next Steps in Signaling (NSIS). This document does not attempt to address routers failing in the packet path; instead, it addresses a deliberate tear down of a flow between UAs, and informs the terminated UA(s) with an indication of what occurred. IEPREP Working Group RFC 3487 Title: Requirements for Resource Priority Mechanisms for the Session Initiation Protocol (SIP) Abstract: This document summarizes requirements for prioritizing access to circuit-switched network, end system and proxy resources for emergency preparedness communications using the Session Initiation Protocol (SIP). RFC 3689 Title: General Requirements for Emergency Telecommunication Service (ETS) Abstract: This document presents a list of general requirements in support of Emergency Telecommunications Service (ETS). Solutions to these requirements are not presented in this document. Additional requirements pertaining to specific applications, or types of applications, are to be specified in separate document(s). RFC 3690 Title: IP Telephony Requirements for Emergency Telecommunication Service (ETS) Abstract: This document presents a list of requirements in support of Emergency Telecommunications Service (ETS) within the context of IP telephony. It is an extension to the general requirements presented in RFC 3689. Solutions to these requirements are not presented in this document. RFC 4190 Title: Framework for Supporting Emergency Telecommunications Service (ETS) in IP Telephony Abstract: This document presents a framework for supporting authorized, emergency-related communication within the context of IP telephony. We present a series of objectives that reflect a general view of how authorized emergency service, in line with the Emergency Telecommunications Service (ETS), should be realized within today's IP architecture and service models. From these objectives, we present a corresponding set of protocols and capabilities, which provide a more specific set of recommendations regarding existing IETF protocols. Finally, we present two scenarios that act as guiding models for the objectives and functions listed in this document. These models, coupled with an example of an existing service in the Public Switched Telephone Network (PSTN), contribute to a constrained solution space. RFC 4375 Title: Emergency Telecommunications Services (ETS) Requirements for a Single Administrative Domain Abstract: This document presents a list of requirements in support of Emergency Telecommunications Service (ETS) within a single administrative domain. This document focuses on a specific set of administrative constraints and scope. Solutions to these requirements are not presented in this document. TSV Working Group RFC 4542 Title: Implementing an Emergency Telecommunications Service (ETS) for Real-Time Services in the Internet Protocol Suite Abstract: RFCs 3689 and 3690 detail requirements for an Emergency Telecommunications Service (ETS), of which an Internet Emergency Preparedness Service (IEPS) would be a part. Some of these types of services require call preemption; others require call queuing or other mechanisms. IEPS requires a Call Admission Control (CAC) procedure and a Per Hop Behavior (PHB) for the data that meet the needs of this architecture. Such a CAC procedure and PHB is appropriate to any service that might use H.323 or SIP to set up real-time sessions. The key requirement is to guarantee an elevated probability of call completion to an authorized user in time of crisis. This document primarily discusses supporting ETS in the context of the US Government and NATO, because it focuses on the Multi-Level Precedence and Preemption (MLPP) and Government Emergency Telecommunication Service (GETS) standards. The architectures described here are applicable beyond these organizations. Work In Progress: draft-ietf-tsvwg-emergency-rsvp-03.txt Title: Resource ReSerVation Protovol (RSVP) Extensions for Emergency Services Abstract: An Emergency Telecommunications Service (ETS) requires the ability to provide an elevated probability of session establishment to an authorized user in times of network congestion (typically, during a crisis). When supported over the Internet Protocol suite, this may be facilitated through a network layer admission control solution, which supports prioritized access to resources (e.g., bandwidth). These resources may be explicitly set aside for emergency services, or they may be shared with other sessions. This document specifies RSVP extensions that can be used to support such an admission priority capability at the network layer. Note that these extensions represent one possible solution component in satisfying ETS requirements. Other solution components, or other solutions, are outside the scope of this document. NSIS Working Group Work In Progress: draft-ietf-nsis-qos-nslp-14.txt Title: NSLP for Quality-of-Service Signaling Abstract: This specification describes the NSIS Signaling Layer Protocol (NSLP)=20 for signaling QoS reservations in the Internet. It is in accordance=20 with the framework and requirements developed in NSIS. Together with=20 GIST, it provides functionality similar to RSVP and extends it. The QoS=20 NSLP is independent of the underlying QoS specification or architecture=20 and provides support for different reservation models. It is simplified=20 by the elimination of support for multicast flows. This specification=20 explains the overall protocol approach, design decisions made and=20 provides examples. It specifies object, message formats and processing=20 rules. DIME Working Group Work In Progress: draft-ietf-dime-diameter-qos-01.txt Title: Diameter Quality of Service Application Abstract: This document describes a Diameter application that performs Authentication, Authorization, and Accounting for Quality of Service (QoS) reservations. This protocol is used by elements along the path of a given application flow to authenticate a reservation request, ensure that the reservation is authorized, and to account for resources consumed during the lifetime of the application flow. Clients that implement the Diameter QoS application contact an authorizing entity/application server that is located somewhere in the network, allowing for a wide variety of flexible deployment models. Work In Progress: draft-ietf-dime-qos-parameters-00.txt Title: Quality of Service Parameters for Usage with the AAA Framework Abstract: This document defines a number of Quality of Service (QoS) parameters that can be reused for conveying QoS information within RADIUS and Diameter. The payloads used to carry these QoS parameters are opaque for the AAA client and the AAA server itself and interpreted by the respective Resource Management Function. Work In Progress: draft-ietf-dime-qos-attributes-01.txt Title: Quality of Service Attributes for Diameter and RADIUS Abstract: This document extends the functionality of the Diameter Base protocol and other Diameter applications with respect to their ability to convey Quality of Service information. The AVPs defined in this document are also available for Remote Authentication Dial In User Service (RADIUS). Non-WG Documents Approved for publication: draft-carlberg-trip-attribute-rp-02.txt Title: TRIP Attribute for Resource Priority =09 Abstract: This document defines a new attribute for the TRIP protocol. The attribute associates protocols/services in the PSTN offering authorized prioritization during call setup that are reachable through a TRIP gateway. Current examples of preferential service in the PSTN are Government Emergency Telecommunications Service (GETS) in the U.S. and Government Telephone Preference Scheme (GTPS) in the U.K. The proposed attribute for TRIP is based on the NameSpace.Value tupple defined for the SIP resource Priority field. Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Aug 28 03:57:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPvvT-0005q8-7X; Tue, 28 Aug 2007 03:55:51 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IPvvP-0005nO-EC for sip-confirm+ok@megatron.ietf.org; Tue, 28 Aug 2007 03:55:47 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPvvO-0005mj-4W; Tue, 28 Aug 2007 03:55:46 -0400 Received: from ccsmtpgate.mugla.edu.tr ([194.27.32.25] helo=ccsmtpgate.mu.edu.tr) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IPvvM-0000NA-1O; Tue, 28 Aug 2007 03:55:45 -0400 Received: from ccexc01.mu.edu.tr ([10.1.1.15]) by ccsmtpgate.mu.edu.tr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Aug 2007 11:01:48 +0300 Received: from mail pickup service by ccexc01.mu.edu.tr with Microsoft SMTPSVC; Tue, 28 Aug 2007 11:01:46 +0300 Received: from megatron.ietf.org ([156.154.16.145]) by ccsmtpgate.mu.edu.tr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Aug 2007 10:40:37 +0300 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPva6-0007Bz-N6; Tue, 28 Aug 2007 03:33:46 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IPva3-0007B5-6x for nsis-confirm+ok@megatron.ietf.org; Tue, 28 Aug 2007 03:33:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPvZy-00078U-2t; Tue, 28 Aug 2007 03:33:38 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IPvZw-0008UK-Bj; Tue, 28 Aug 2007 03:33:37 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id B1B9C210F1; Tue, 28 Aug 2007 09:33:35 +0200 (CEST) X-AuditID: c1b4fb3e-b0835bb0000007e1-42-46d3cfcfa7e9 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 7CCBF203FB; Tue, 28 Aug 2007 09:33:35 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Aug 2007 09:33:35 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Aug 2007 09:33:35 +0200 Message-ID: <46D3CFCF.6070308@ericsson.com> Date: Tue, 28 Aug 2007 09:33:35 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 References: <46AF5370.9020304@ericsson.com> <46D2E80E.8000001@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed X-OriginalArrivalTime: 28 Aug 2007 07:33:35.0545 (UTC) FILETIME=[BE24DA90:01C7E945] X-Brightmail-Tracker: AAAAAA== Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.6 (+) X-Scan-Signature: 4d9ae72af46718088458d214998cc683 Subject: [NSIS] Re: [Tsvwg] Re: [Sip] Re: Draft Liaison response to SG13 on Emergency Telecommunications X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-Spam-Score: 1.6 (+) X-Scan-Signature: 17cf8eab1d6bbd2874a56f9e3554d91d Cc: sip@ietf.org, IETF SIPPING WG , dime@ietf.org, tsvwg , NSIS X-BeenThere: sip@ietf.org List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi again, I have received some more comments. So here is an updated version adding=20 DIME documents and correcting origin of documents. Submission Date: , 2007 From: IETF Working groups TSVWG, NSIS, DIME, SIP and SIPPING To: Georges Sebek , Keith Knightson Cc: Magnus Westerlund , Lars Eggert , James Polk , Martin Stiemerling , John Loughney Dean Willis , Keith Drage , Mary Barnes , Gonzalo Camarillo , Scott Bradner , Kimberly King , Scott Brim , Hannes Tschofenig , David Frascone Response Contact: TSV WG (tsv-chairs@tools.ietf.org) NSIS (nsis-chairs@tools.ietf.org) SIPPING (sipping-chairs@tools.ietf.org) SIP (sip-chairs@tools.ietf.org) DIME (dime-chairs@tools.ietf.org) =09 Purpose: Response to Liaison Request Deadline: None Title: Response to liaison request from ITU-T Study Group 13 work on=20 emergency telecommunications This is a response to the liaison request made by Q.3/13 regarding=20 emergency telecommunications (REF: NGN-GSI/DOC =96 60 Rev.2). We would=20 first like to apologize for failing to meet the deadline in responding.=20 We do hope that the late answer still can be of some use. The liaison request was made to the following working groups (WG):=20 IEPREP, TSVWG, and NSIS. Since the request was sent the IEPREP WG has=20 concluded. In addition to the WGs from which information was requested,=20 we also think that work performed by the DIME, SIP and SIPPING WG may be=20 of relevance. Pursuant to ITU-T Study Group 13 request for information on relevant and=20 related work in the IETF regarding emergency communications, we list=20 below RFCs and works in progress that we feel may be of interest to your=20 group. Some of the completed work is Informational, and others are in=20 the category of Standards Track. Q.3/13 also requested that we keep you informed of any developments in=20 regards to emergency telecommunications. In those regards we would like=20 to make you aware that IETF mailing list participation and document=20 information is free and open to anyone, allowing participants in Q.3/13=20 to keep themselves informed of any developments. If Q.3/13 desire to get=20 further information about specific ongoing work, then please send a=20 liaison request to the responsible WG for those specific documents. The following list is divided under the associated working groups from=20 which the work has been done within the IETF. SIP Working Group RFC 4412 Title: Communications Resource Priority for the Session Initiation Protocol (SIP) Abstract: This document defines two new Session Initiation Protocol (SIP) header fields for communicating resource priority, namely, "Resource-Priority" and "Accept-Resource-Priority". The "Resource-Priority" header field can influence the behavior of SIP user agents (such as telephone gateways and IP telephones) and SIP proxies. It does not directly influence the forwarding behavior of IP routers. The below two documents are proposed work items accepted to become IETF=20 WG items are likely of interest as they update RFC 4412. Work In Progress: draft-polk-sip-rph-in-responses-00 Title: Allowing SIP Resource Priority Header in SIP Responses Abstract: The Session Initiation Protocol (SIP) Resource Priority Header (RPH), in its current form, is ignored in SIP responses. This was a design choice during RFC 4412's development. This is now considered a bad design choice in certain scenarios. This document corrects RFC 4412's communications model by optionally allowing a SIP server or user agent client to process the Resource-Priority Header in a response. Work In Progress: draft-polk-sip-rph-new-namespaces--00 Title: New Session Initiation Protocol Resource-Priority Header Namespaces for=20 the Defense Information Systems Agency Abstract: This document creates additional Session Initiation Protocol Resource-Priority header namespaces, to be IANA registered. This document intends to update RFC 4412, as a Proposed Standard document if published by the RFC-Editor. SIPPING Working Group RFC 4411 Title: Extending the Session Initiation Protocol (SIP) Reason Header for Preemption Events Abstract: This document proposes an IANA Registration extension to the Session Initiation Protocol (SIP) Reason Header to be included in a BYE Method Request as a result of a session preemption event, either at a user agent (UA), or somewhere in the network involving a reservation-based protocol such as the Resource ReSerVation Protocol (RSVP) or Next Steps in Signaling (NSIS). This document does not attempt to address routers failing in the packet path; instead, it addresses a deliberate tear down of a flow between UAs, and informs the terminated UA(s) with an indication of what occurred. IEPREP Working Group RFC 3487 Title: Requirements for Resource Priority Mechanisms for the Session Initiation Protocol (SIP) Abstract: This document summarizes requirements for prioritizing access to circuit-switched network, end system and proxy resources for emergency preparedness communications using the Session Initiation Protocol (SIP). RFC 3689 Title: General Requirements for Emergency Telecommunication Service (ETS) Abstract: This document presents a list of general requirements in support of Emergency Telecommunications Service (ETS). Solutions to these requirements are not presented in this document. Additional requirements pertaining to specific applications, or types of applications, are to be specified in separate document(s). RFC 3690 Title: IP Telephony Requirements for Emergency Telecommunication Service (ETS) Abstract: This document presents a list of requirements in support of Emergency Telecommunications Service (ETS) within the context of IP telephony. It is an extension to the general requirements presented in RFC 3689. Solutions to these requirements are not presented in this document. RFC 4190 Title: Framework for Supporting Emergency Telecommunications Service (ETS) in IP Telephony Abstract: This document presents a framework for supporting authorized, emergency-related communication within the context of IP telephony. We present a series of objectives that reflect a general view of how authorized emergency service, in line with the Emergency Telecommunications Service (ETS), should be realized within today's IP architecture and service models. From these objectives, we present a corresponding set of protocols and capabilities, which provide a more specific set of recommendations regarding existing IETF protocols. Finally, we present two scenarios that act as guiding models for the objectives and functions listed in this document. These models, coupled with an example of an existing service in the Public Switched Telephone Network (PSTN), contribute to a constrained solution space. RFC 4375 Title: Emergency Telecommunications Services (ETS) Requirements for a Single Administrative Domain Abstract: This document presents a list of requirements in support of Emergency Telecommunications Service (ETS) within a single administrative domain. This document focuses on a specific set of administrative constraints and scope. Solutions to these requirements are not presented in this document. TSV Working Group RFC 4542 Title: Implementing an Emergency Telecommunications Service (ETS) for Real-Time Services in the Internet Protocol Suite Abstract: RFCs 3689 and 3690 detail requirements for an Emergency Telecommunications Service (ETS), of which an Internet Emergency Preparedness Service (IEPS) would be a part. Some of these types of services require call preemption; others require call queuing or other mechanisms. IEPS requires a Call Admission Control (CAC) procedure and a Per Hop Behavior (PHB) for the data that meet the needs of this architecture. Such a CAC procedure and PHB is appropriate to any service that might use H.323 or SIP to set up real-time sessions. The key requirement is to guarantee an elevated probability of call completion to an authorized user in time of crisis. This document primarily discusses supporting ETS in the context of the US Government and NATO, because it focuses on the Multi-Level Precedence and Preemption (MLPP) and Government Emergency Telecommunication Service (GETS) standards. The architectures described here are applicable beyond these organizations. Work In Progress: draft-ietf-tsvwg-emergency-rsvp-03.txt Title: Resource ReSerVation Protovol (RSVP) Extensions for Emergency Services Abstract: An Emergency Telecommunications Service (ETS) requires the ability to provide an elevated probability of session establishment to an authorized user in times of network congestion (typically, during a crisis). When supported over the Internet Protocol suite, this may be facilitated through a network layer admission control solution, which supports prioritized access to resources (e.g., bandwidth). These resources may be explicitly set aside for emergency services, or they may be shared with other sessions. This document specifies RSVP extensions that can be used to support such an admission priority capability at the network layer. Note that these extensions represent one possible solution component in satisfying ETS requirements. Other solution components, or other solutions, are outside the scope of this document. NSIS Working Group Work In Progress: draft-ietf-nsis-qos-nslp-14.txt Title: NSLP for Quality-of-Service Signaling Abstract: This specification describes the NSIS Signaling Layer Protocol (NSLP)=20 for signaling QoS reservations in the Internet. It is in accordance=20 with the framework and requirements developed in NSIS. Together with=20 GIST, it provides functionality similar to RSVP and extends it. The QoS=20 NSLP is independent of the underlying QoS specification or architecture=20 and provides support for different reservation models. It is simplified=20 by the elimination of support for multicast flows. This specification=20 explains the overall protocol approach, design decisions made and=20 provides examples. It specifies object, message formats and processing=20 rules. DIME Working Group Work In Progress: draft-ietf-dime-diameter-qos-01.txt Title: Diameter Quality of Service Application Abstract: This document describes a Diameter application that performs Authentication, Authorization, and Accounting for Quality of Service (QoS) reservations. This protocol is used by elements along the path of a given application flow to authenticate a reservation request, ensure that the reservation is authorized, and to account for resources consumed during the lifetime of the application flow. Clients that implement the Diameter QoS application contact an authorizing entity/application server that is located somewhere in the network, allowing for a wide variety of flexible deployment models. Work In Progress: draft-ietf-dime-qos-parameters-00.txt Title: Quality of Service Parameters for Usage with the AAA Framework Abstract: This document defines a number of Quality of Service (QoS) parameters that can be reused for conveying QoS information within RADIUS and Diameter. The payloads used to carry these QoS parameters are opaque for the AAA client and the AAA server itself and interpreted by the respective Resource Management Function. Work In Progress: draft-ietf-dime-qos-attributes-01.txt Title: Quality of Service Attributes for Diameter and RADIUS Abstract: This document extends the functionality of the Diameter Base protocol and other Diameter applications with respect to their ability to convey Quality of Service information. The AVPs defined in this document are also available for Remote Authentication Dial In User Service (RADIUS). Non-WG Documents Approved for publication: draft-carlberg-trip-attribute-rp-02.txt Title: TRIP Attribute for Resource Priority =09 Abstract: This document defines a new attribute for the TRIP protocol. The attribute associates protocols/services in the PSTN offering authorized prioritization during call setup that are reachable through a TRIP gateway. Current examples of preferential service in the PSTN are Government Emergency Telecommunications Service (GETS) in the U.S. and Government Telephone Preference Scheme (GTPS) in the U.K. The proposed attribute for TRIP is based on the NameSpace.Value tupple defined for the SIP resource Priority field. Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Aug 28 03:57:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPvve-0006JD-CX; Tue, 28 Aug 2007 03:56:02 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IPvvS-0005pL-LO for sip-confirm+ok@megatron.ietf.org; Tue, 28 Aug 2007 03:55:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPvvQ-0005nY-97; Tue, 28 Aug 2007 03:55:48 -0400 Received: from ccsmtpgate.mugla.edu.tr ([194.27.32.25] helo=ccsmtpgate.mu.edu.tr) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IPvvO-0000NA-SI; Tue, 28 Aug 2007 03:55:48 -0400 Received: from ccexc01.mu.edu.tr ([10.1.1.15]) by ccsmtpgate.mu.edu.tr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Aug 2007 11:01:49 +0300 Received: from mail pickup service by ccexc01.mu.edu.tr with Microsoft SMTPSVC; Tue, 28 Aug 2007 11:01:46 +0300 Received: from megatron.ietf.org ([156.154.16.145]) by ccsmtpgate.mu.edu.tr with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Aug 2007 18:11:28 +0300 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPg9F-0007ci-8J; Mon, 27 Aug 2007 11:05:01 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IPg9B-0007Yn-Eq for nsis-confirm+ok@megatron.ietf.org; Mon, 27 Aug 2007 11:04:57 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPg99-0007X2-UV; Mon, 27 Aug 2007 11:04:56 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IPg98-00077c-Eg; Mon, 27 Aug 2007 11:04:55 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C8653207B1; Mon, 27 Aug 2007 17:04:47 +0200 (CEST) X-AuditID: c1b4fb3c-b1e82bb0000007e1-c3-46d2e80fde06 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9C94C20671; Mon, 27 Aug 2007 17:04:47 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Aug 2007 17:04:46 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Aug 2007 17:04:46 +0200 Message-ID: <46D2E80E.8000001@ericsson.com> Date: Mon, 27 Aug 2007 17:04:46 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Magnus Westerlund References: <46AF5370.9020304@ericsson.com> In-Reply-To: <46AF5370.9020304@ericsson.com> Content-Type: text/plain; charset=UTF-8; format=flowed X-OriginalArrivalTime: 27 Aug 2007 15:04:46.0546 (UTC) FILETIME=[9B4E0B20:01C7E8BB] X-Brightmail-Tracker: AAAAAA== Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 9f79b8e383fd3af2b1b5b1d0910f6094 X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 142a000676f5977e1797396caab8b611 Cc: sip@ietf.org, IETF SIPPING WG , tsvwg , NSIS Subject: [Sip] [NSIS] Re: Draft Liaison response to SG13 on Emergency Telecommunications X-BeenThere: sip@ietf.org List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, I have now updated this liaison reply to take the comments into account.=20 According to the ECRIT chairs they don't think what they are working is=20 related to the ongoing work Q.3/13 is working on. If you have any final=20 comments please provide them no later then the Wednesday 29th at 16.00 CE= ST. Magnus Westerlund Submission Date: , 2007 From: IETF Working groups TSVWG, NSIS, SIP and SIPPING To: Georges Sebek , Keith Knightson Cc: Magnus Westerlund , Lars Eggert , James Polk , Martin Stiemerling , John Loughney Dean Willis , Keith Drage , Mary Barnes , Gonzalo Camarillo , Scott Bradner , Kimberly King , Scott Brim Response Contact: TSV WG (tsv-chairs@tools.ietf.org) NSIS (nsis-chairs@tools.ietf.org) SIPPING (sipping-chairs@tools.ietf.org) SIP (sip-chairs@tools.ietf.org) =09 Purpose: Response to Liaison Request Deadline: None Title: Response to liaison request from ITU-T Study Group 13 work on=20 emergency telecommunications This is a response to the liaison request made by Q.3/13 regarding=20 emergency telecommunications (REF: NGN-GSI/DOC =E2=80=93 60 Rev.2). We wo= uld=20 first like to apologize for failing to meet the deadline in responding.=20 We do hope that the late answer still can be of some use. The liaison request was made to the following working groups (WG):=20 IEPREP, TSVWG, and NSIS. Since the request was sent the IEPREP WG has=20 concluded. In addition to the WGs from which information was requested,=20 we also think that work performed by the SIP and SIPPING WG may be of=20 relevance. Pursuant to ITU-T Study Group 13 request for information on relevant and=20 related work in the IETF regarding emergency communications, we list=20 below RFCs and works in progress that we feel may be of interest to your=20 group. Some of the completed work is Informational, and others are in=20 the category of Standards Track. Q.3/13 also requested that we keep you informed of any developments in=20 regards to emergency telecommunications. In those regards we would like=20 to make you aware that IETF mailing list participation and document=20 information is free and open to anyone, allowing participants in Q.3/13=20 to keep themselves informed of any developments. If Q.3/13 desire to get=20 further information about specific ongoing work, then please send a=20 liaison request to the responsible WG for those specific documents. The following list is divided under the associated working groups from=20 which the work has been done within the IETF. SIP Working Group RFC 4411 Title: Extending the Session Initiation Protocol (SIP) Reason Header for Preemption Events Abstract: This document proposes an IANA Registration extension to the Session Initiation Protocol (SIP) Reason Header to be included in a BYE Method Request as a result of a session preemption event, either at a user agent (UA), or somewhere in the network involving a reservation-based protocol such as the Resource ReSerVation Protocol (RSVP) or Next Steps in Signaling (NSIS). This document does not attempt to address routers failing in the packet path; instead, it addresses a deliberate tear down of a flow between UAs, and informs the terminated UA(s) with an indication of what occurred. RFC 4412 Title: Communications Resource Priority for the Session Initiation Protocol (SIP) Abstract: This document defines two new Session Initiation Protocol (SIP) header fields for communicating resource priority, namely, "Resource-Priority" and "Accept-Resource-Priority". The "Resource-Priority" header field can influence the behavior of SIP user agents (such as telephone gateways and IP telephones) and SIP proxies. It does not directly influence the forwarding behavior of IP routers. SIPPING Working Group The below two documents are proposed work items accepted to become IETF=20 WG items are likely of interest as they update RFC 4412. Work In Progress: draft-polk-sip-rph-in-responses-00 Title: Allowing SIP Resource Priority Header in SIP Responses Abstract: The Session Initiation Protocol (SIP) Resource Priority Header (RPH), in its current form, is ignored in SIP responses. This was a design choice during RFC 4412's development. This is now considered a bad design choice in certain scenarios. This document corrects RFC 4412's communications model by optionally allowing a SIP server or user agent client to process the Resource-Priority Header in a response. Work In Progress: draft-polk-sip-rph-new-namespaces--00 Title: New Session Initiation Protocol Resource-Priority Header Namespaces for=20 the Defense Information Systems Agency Abstract: This document creates additional Session Initiation Protocol Resource-Priority header namespaces, to be IANA registered. This document intends to update RFC 4412, as a Proposed Standard document if published by the RFC-Editor. IEPREP Working Group RFC 3487 Title: Requirements for Resource Priority Mechanisms for the Session Initiation Protocol (SIP) Abstract: This document summarizes requirements for prioritizing access to circuit-switched network, end system and proxy resources for emergency preparedness communications using the Session Initiation Protocol (SIP). RFC 3689 Title: General Requirements for Emergency Telecommunication Service (ETS) Abstract: This document presents a list of general requirements in support of Emergency Telecommunications Service (ETS). Solutions to these requirements are not presented in this document. Additional requirements pertaining to specific applications, or types of applications, are to be specified in separate document(s). RFC 3690 Title: IP Telephony Requirements for Emergency Telecommunication Service (ETS) Abstract: This document presents a list of requirements in support of Emergency Telecommunications Service (ETS) within the context of IP telephony. It is an extension to the general requirements presented in RFC 3689. Solutions to these requirements are not presented in this document. RFC 4190 Title: Framework for Supporting Emergency Telecommunications Service (ETS) in IP Telephony Abstract: This document presents a framework for supporting authorized, emergency-related communication within the context of IP telephony. We present a series of objectives that reflect a general view of how authorized emergency service, in line with the Emergency Telecommunications Service (ETS), should be realized within today's IP architecture and service models. From these objectives, we present a corresponding set of protocols and capabilities, which provide a more specific set of recommendations regarding existing IETF protocols. Finally, we present two scenarios that act as guiding models for the objectives and functions listed in this document. These models, coupled with an example of an existing service in the Public Switched Telephone Network (PSTN), contribute to a constrained solution space. RFC 4375 Title: Emergency Telecommunications Services (ETS) Requirements for a Single Administrative Domain Abstract: This document presents a list of requirements in support of Emergency Telecommunications Service (ETS) within a single administrative domain. This document focuses on a specific set of administrative constraints and scope. Solutions to these requirements are not presented in this document. TSV Working Group RFC 4542 Title: Implementing an Emergency Telecommunications Service (ETS) for Real-Time Services in the Internet Protocol Suite Abstract: RFCs 3689 and 3690 detail requirements for an Emergency Telecommunications Service (ETS), of which an Internet Emergency Preparedness Service (IEPS) would be a part. Some of these types of services require call preemption; others require call queuing or other mechanisms. IEPS requires a Call Admission Control (CAC) procedure and a Per Hop Behavior (PHB) for the data that meet the needs of this architecture. Such a CAC procedure and PHB is appropriate to any service that might use H.323 or SIP to set up real-time sessions. The key requirement is to guarantee an elevated probability of call completion to an authorized user in time of crisis. This document primarily discusses supporting ETS in the context of the US Government and NATO, because it focuses on the Multi-Level Precedence and Preemption (MLPP) and Government Emergency Telecommunication Service (GETS) standards. The architectures described here are applicable beyond these organizations. Work In Progress: draft-ietf-tsvwg-emergency-rsvp-03.txt Title: Resource ReSerVation Protovol (RSVP) Extensions for Emergency Services Abstract: An Emergency Telecommunications Service (ETS) requires the ability to provide an elevated probability of session establishment to an authorized user in times of network congestion (typically, during a crisis). When supported over the Internet Protocol suite, this may be facilitated through a network layer admission control solution, which supports prioritized access to resources (e.g., bandwidth). These resources may be explicitly set aside for emergency services, or they may be shared with other sessions. This document specifies RSVP extensions that can be used to support such an admission priority capability at the network layer. Note that these extensions represent one possible solution component in satisfying ETS requirements. Other solution components, or other solutions, are outside the scope of this document. NSIS Working Group Work In Progress: draft-ietf-nsis-qos-nslp-14.txt Title: NSLP for Quality-of-Service Signaling Abstract: This specification describes the NSIS Signaling Layer Protocol (NSLP)=20 for signaling QoS reservations in the Internet. It is in accordance=20 with the framework and requirements developed in NSIS. Together with=20 GIST, it provides functionality similar to RSVP and extends it. The QoS=20 NSLP is independent of the underlying QoS specification or architecture=20 and provides support for different reservation models. It is simplified=20 by the elimination of support for multicast flows. This specification=20 explains the overall protocol approach, design decisions made and=20 provides examples. It specifies object, message formats and processing=20 rules. Non-WG Documents Approved for publication: draft-carlberg-trip-attribute-rp-02.txt Title: TRIP Attribute for Resource Priority =09 Abstract: This document defines a new attribute for the TRIP protocol. The attribute associates protocols/services in the PSTN offering authorized prioritization during call setup that are reachable through a TRIP gateway. Current examples of preferential service in the PSTN are Government Emergency Telecommunications Service (GETS) in the U.S. and Government Telephone Preference Scheme (GTPS) in the U.K. The proposed attribute for TRIP is based on the NameSpace.Value tupple defined for the SIP resource Priority field. --=20 Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Aug 28 03:57:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPvvn-0006o7-Hn; Tue, 28 Aug 2007 03:56:11 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IPvvU-0005rd-Vk for sip-confirm+ok@megatron.ietf.org; Tue, 28 Aug 2007 03:55:52 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPvvS-0005pK-KJ; Tue, 28 Aug 2007 03:55:50 -0400 Received: from ccsmtpgate.mugla.edu.tr ([194.27.32.25] helo=ccsmtpgate.mu.edu.tr) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IPvvR-0000NA-3x; Tue, 28 Aug 2007 03:55:50 -0400 Received: from ccexc01.mu.edu.tr ([10.1.1.15]) by ccsmtpgate.mu.edu.tr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Aug 2007 11:01:49 +0300 Received: from mail pickup service by ccexc01.mu.edu.tr with Microsoft SMTPSVC; Tue, 28 Aug 2007 11:01:46 +0300 Received: from megatron.ietf.org ([156.154.16.145]) by ccsmtpgate.mu.edu.tr with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Aug 2007 20:50:36 +0300 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPidI-0002JZ-GW; Mon, 27 Aug 2007 13:44:12 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IPidH-0002Iw-5y for nsis-confirm+ok@megatron.ietf.org; Mon, 27 Aug 2007 13:44:11 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPidG-0002Ii-Pa; Mon, 27 Aug 2007 13:44:10 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IPidF-0003fu-6e; Mon, 27 Aug 2007 13:44:10 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 27 Aug 2007 10:44:08 -0700 X-IronPort-AV: i="4.19,312,1183359600"; d="scan'208"; a="8948966:sNHT37752318" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l7RHi8I9018831; Mon, 27 Aug 2007 10:44:08 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l7RHi7lH024692; Mon, 27 Aug 2007 17:44:08 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Aug 2007 10:43:58 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.91.203]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Aug 2007 10:43:58 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 27 Aug 2007 12:43:56 -0500 To: Magnus Westerlund , Magnus Westerlund From: "James M. Polk" In-Reply-To: <46D2E80E.8000001@ericsson.com> References: <46AF5370.9020304@ericsson.com> <46D2E80E.8000001@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Message-ID: X-OriginalArrivalTime: 27 Aug 2007 17:43:58.0357 (UTC) FILETIME=[D8A0BC50:01C7E8D1] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=13773; t=1188236648; x=1189100648; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Sip]=20Re=3A=20Draft=20Liaison=20response=20to=20SG1 3=20on=20Emergency=0A=20=20Telecommunications |Sender:=20; bh=sD60hnFy/1jeEK1NSSply5RPrbOwmB6enSRDS4sAZwA=; b=NJ5rCWq1ZGUUY+eJFusmZiG9HMDYbUGWMPHFX+snThPELoZWBHziyWTEWKUzwvNCia6c+Xib Su+2TerJMq4GI4YlehPPQ+olRzN0EU6a4fDGso7kncfj3xpvjujDn5RU; Authentication-Results: sj-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d8921dd2ebcb07edebf7bfaf4808c2ad Subject: [NSIS] Re: [Sip] Re: Draft Liaison response to SG13 on Emergency Telecommunications X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 96e0f8497f38c15fbfc8f6f315bcdecb Cc: sip@ietf.org, IETF SIPPING WG , tsvwg , NSIS X-BeenThere: sip@ietf.org List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Magnus comments in-line below about from which WG certain documents originated At 10:04 AM 8/27/2007, Magnus Westerlund wrote: >Hi, > >I have now updated this liaison reply to take=20 >the comments into account. According to the=20 >ECRIT chairs they don't think what they are=20 >working is related to the ongoing work Q.3/13 is=20 >working on. If you have any final comments=20 >please provide them no later then the Wednesday 29th at 16.00 CEST. > >Magnus Westerlund > > >Submission >Date: , 2007 > >From: IETF Working groups TSVWG, NSIS, SIP and SIPPING > >To: Georges Sebek , > Keith Knightson > >Cc: Magnus Westerlund , > Lars Eggert , > James Polk , > Martin Stiemerling , > John Loughney > Dean Willis , > Keith Drage , > Mary Barnes , > Gonzalo Camarillo , > Scott Bradner , > Kimberly King , > Scott Brim > >Response >Contact: TSV WG (tsv-chairs@tools.ietf.org) > NSIS (nsis-chairs@tools.ietf.org) > SIPPING (sipping-chairs@tools.ietf.org) > SIP (sip-chairs@tools.ietf.org) > >Purpose: Response to Liaison Request > >Deadline: None > >Title: Response to liaison request from ITU-T=20 >Study Group 13 work on emergency telecommunications > >This is a response to the liaison request made=20 >by Q.3/13 regarding emergency telecommunications=20 >(REF: NGN-GSI/DOC =AD 60 Rev.2). We woould first=20 >like to apologize for failing to meet the=20 >deadline in responding. We do hope that the late=20 >answer still can be of some use. > >The liaison request was made to the following=20 >working groups (WG): IEPREP, TSVWG, and NSIS.=20 >Since the request was sent the IEPREP WG has=20 >concluded. In addition to the WGs from which=20 >information was requested, we also think that=20 >work performed by the SIP and SIPPING WG may be of relevance. > >Pursuant to ITU-T Study Group 13 request for=20 >information on relevant and related work in the=20 >IETF regarding emergency communications, we list=20 >below RFCs and works in progress that we feel=20 >may be of interest to your group. Some of the=20 >completed work is Informational, and others are=20 >in the category of Standards Track. > >Q.3/13 also requested that we keep you informed=20 >of any developments in regards to emergency=20 >telecommunications. In those regards we would=20 >like to make you aware that IETF mailing list=20 >participation and document information is free=20 >and open to anyone, allowing participants in=20 >Q.3/13 to keep themselves informed of any=20 >developments. If Q.3/13 desire to get further=20 >information about specific ongoing work, then=20 >please send a liaison request to the responsible=20 >WG for those specific documents. > >The following list is divided under the=20 >associated working groups from which the work has been done within the= IETF. > > >SIP Working Group > >RFC 4411 RFC4411 is from SIPPING >Title: > Extending the Session Initiation Protocol (SIP) > Reason Header for Preemption Events > >Abstract: > This document proposes an IANA Registration extension to the Session > Initiation Protocol (SIP) Reason Header to be included in a BYE > Method Request as a result of a session preemption event, either at a > user agent (UA), or somewhere in the network involving a > reservation-based protocol such as the Resource ReSerVation Protocol > (RSVP) or Next Steps in Signaling (NSIS). This document does not > attempt to address routers failing in the packet path; instead, it > addresses a deliberate tear down of a flow between UAs, and informs > the terminated UA(s) with an indication of what occurred. > >RFC 4412 > >Title: > Communications Resource Priority for the Session Initiation > Protocol (SIP) > >Abstract: > This document defines two new Session Initiation Protocol (SIP) > header fields for communicating resource priority, namely, > "Resource-Priority" and "Accept-Resource-Priority". The > "Resource-Priority" header field can influence the behavior of SIP > user agents (such as telephone gateways and IP telephones) and SIP > proxies. It does not directly influence the forwarding behavior of > IP routers. > > > >SIPPING Working Group both IDs below are SIP WG items, not SIPPING > The below two documents are proposed=20 > work items accepted to become IETF WG items are=20 > likely of interest as they update RFC 4412. > >Work In Progress: draft-polk-sip-rph-in-responses-00 > >Title: >Allowing SIP Resource Priority Header in SIP Responses > >Abstract: > The Session Initiation Protocol (SIP) Resource Priority Header > (RPH), in its current form, is ignored in SIP responses. This was a > design choice during RFC 4412's development. This is now considered > a bad design choice in certain scenarios. This document corrects > RFC 4412's communications model by optionally allowing a SIP server > or user agent client to process the Resource-Priority Header in a > response. > >Work In Progress: draft-polk-sip-rph-new-namespaces--00 > >Title: >New Session Initiation Protocol=20 >Resource-Priority Header Namespaces for the Defense Information Systems= Agency > >Abstract: > This document creates additional Session Initiation Protocol > Resource-Priority header namespaces, to be IANA registered. This > document intends to update RFC 4412, as a Proposed Standard document > if published by the RFC-Editor. > >IEPREP Working Group > >RFC 3487 > >Title: > Requirements for Resource Priority Mechanisms for the > Session Initiation Protocol (SIP) > >Abstract: > This document summarizes requirements for prioritizing access to > circuit-switched network, end system and proxy resources for > emergency preparedness communications using the Session Initiation > Protocol (SIP). > >RFC 3689 > >Title: > General Requirements for > Emergency Telecommunication Service (ETS) > >Abstract: > This document presents a list of general requirements in support of > Emergency Telecommunications Service (ETS). Solutions to these > requirements are not presented in this document. Additional > requirements pertaining to specific applications, or types of > applications, are to be specified in separate document(s). > >RFC 3690 > >Title: > IP Telephony Requirements for > Emergency Telecommunication Service (ETS) > >Abstract: > This document presents a list of requirements in support of Emergency > Telecommunications Service (ETS) within the context of IP telephony. > It is an extension to the general requirements presented in RFC 3689. > Solutions to these requirements are not presented in this document. > >RFC 4190 > >Title: > Framework for Supporting Emergency Telecommunications > Service (ETS) in IP Telephony > >Abstract: > This document presents a framework for supporting authorized, > emergency-related communication within the context of IP telephony. > We present a series of objectives that reflect a general view of how > authorized emergency service, in line with the Emergency > Telecommunications Service (ETS), should be realized within today's > IP architecture and service models. From these objectives, we > present a corresponding set of protocols and capabilities, which > provide a more specific set of recommendations regarding existing > IETF protocols. Finally, we present two scenarios that act as > guiding models for the objectives and functions listed in this > document. These models, coupled with an example of an existing > service in the Public Switched Telephone Network (PSTN), contribute > to a constrained solution space. > >RFC 4375 > >Title: > Emergency Telecommunications Services (ETS) Requirements > for a Single Administrative Domain > >Abstract: > This document presents a list of requirements in support of Emergency > Telecommunications Service (ETS) within a single administrative > domain. This document focuses on a specific set of administrative > constraints and scope. Solutions to these requirements are not > presented in this document. > > >TSV Working Group > >RFC 4542 > >Title: > Implementing an Emergency Telecommunications Service (ETS) > for Real-Time Services in the Internet Protocol Suite > >Abstract: > RFCs 3689 and 3690 detail requirements for an Emergency > Telecommunications Service (ETS), of which an Internet Emergency > Preparedness Service (IEPS) would be a part. Some of these types of > services require call preemption; others require call queuing or > other mechanisms. IEPS requires a Call Admission Control (CAC) > procedure and a Per Hop Behavior (PHB) for the data that meet the > needs of this architecture. Such a CAC procedure and PHB is > appropriate to any service that might use H.323 or SIP to set up > real-time sessions. The key requirement is to guarantee an elevated > probability of call completion to an authorized user in time of > crisis. > > This document primarily discusses supporting ETS in the context of > the US Government and NATO, because it focuses on the Multi-Level > Precedence and Preemption (MLPP) and Government Emergency > Telecommunication Service (GETS) standards. The architectures > described here are applicable beyond these organizations. > >Work In Progress: draft-ietf-tsvwg-emergency-rsvp-03.txt > >Title: > Resource ReSerVation Protovol (RSVP) Extensions for > Emergency Services > >Abstract: > An Emergency Telecommunications Service (ETS) requires the ability to > provide an elevated probability of session establishment to an > authorized user in times of network congestion (typically, during a > crisis). When supported over the Internet Protocol suite, this may be > facilitated through a network layer admission control solution, which > supports prioritized access to resources (e.g., bandwidth). These > resources may be explicitly set aside for emergency services, or they > may be shared with other sessions. > > This document specifies RSVP extensions that can be used to support > such an admission priority capability at the network layer. Note that > these extensions represent one possible solution component in > satisfying ETS requirements. Other solution components, or other > solutions, are outside the scope of this document. > >NSIS Working Group > >Work In Progress: draft-ietf-nsis-qos-nslp-14.txt > >Title: >NSLP for Quality-of-Service Signaling > >Abstract: >This specification describes the NSIS Signaling=20 >Layer Protocol (NSLP) for signaling QoS=20 >reservations in the Internet. It is in=20 >accordance with the framework and requirements=20 >developed in NSIS. Together with GIST, it=20 >provides functionality similar to RSVP and=20 >extends it. The QoS NSLP is independent of the=20 >underlying QoS specification or architecture and=20 >provides support for different reservation=20 >models. It is simplified by the elimination of=20 >support for multicast flows. This specification=20 >explains the overall protocol approach, design=20 >decisions made and provides examples. It=20 >specifies object, message formats and processing rules. > >Non-WG Documents > > Approved for publication: draft-carlberg-trip-attribute-rp-02.txt > > Title: > TRIP Attribute for Resource Priority > >Abstract: > This document defines a new attribute for the TRIP protocol. The > attribute associates protocols/services in the PSTN offering > authorized prioritization during call setup that are reachable > through a TRIP gateway. Current examples of preferential service in > the PSTN are Government Emergency Telecommunications Service (GETS) > in the U.S. and Government Telephone Preference Scheme (GTPS) in the > U.K. The proposed attribute for TRIP is based on the NameSpace.Value > tupple defined for the SIP resource Priority field. > > > >-- > >Magnus Westerlund > >IETF Transport Area Director & TSVWG Chair >---------------------------------------------------------------------- >Multimedia Technologies, Ericsson Research EAB/TVM/M >---------------------------------------------------------------------- >Ericsson AB | Phone +46 8 4048287 >Torshamsgatan 23 | Fax +46 8 7575550 >S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >---------------------------------------------------------------------- > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Aug 28 14:01:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ5Lk-0004yT-7R; Tue, 28 Aug 2007 13:59:36 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IQ5Lh-0004xH-KX for sip-confirm+ok@megatron.ietf.org; Tue, 28 Aug 2007 13:59:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ5Lg-0004wc-Ac; Tue, 28 Aug 2007 13:59:32 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQ5Le-0000b0-OY; Tue, 28 Aug 2007 13:59:32 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 28 Aug 2007 10:59:29 -0700 X-IronPort-AV: i="4.19,317,1183359600"; d="scan'208"; a="15348078:sNHT40240212" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l7SHxTN2013270; Tue, 28 Aug 2007 10:59:29 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l7SHxClh008831; Tue, 28 Aug 2007 17:59:29 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Aug 2007 10:59:21 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.123.166]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Aug 2007 10:59:21 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 28 Aug 2007 12:59:22 -0500 To: Magnus Westerlund From: "James M. Polk" Subject: Re: [NSIS] Re: [Tsvwg] Re: [Sip] Re: Draft Liaison response to SG13 on Emergency Telecommunications In-Reply-To: <46D3CFCF.6070308@ericsson.com> References: <46AF5370.9020304@ericsson.com> <46D2E80E.8000001@ericsson.com> <46D3CFCF.6070308@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Message-ID: X-OriginalArrivalTime: 28 Aug 2007 17:59:21.0205 (UTC) FILETIME=[2919EA50:01C7E99D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=14975; t=1188323969; x=1189187969; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[NSIS]=20Re=3A=20[Tsvwg]=20Re=3A=20[Sip]=20Re=3A=20Dr aft=20Liaison=20response=20to=0A=20=20SG13=20on=20Emergency=20Telecommunic ations |Sender:=20; bh=m99wFMraDniP/oabHCb59sGhsw2Bm5NRjjTI8QPmPjQ=; b=bODCQI96h2iutBG4vGsYcbj1e/Oo4s0WfBpHF2E8WSTSIdETsS+MhpFOBid8YxpSICPCI97d sdgboM6xqHbePJ1KuM3XLQaNN2jxktMXOXQIgqArKt8G+EV6TaxcEWe+; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 89ebdf268eceaeaf784b3acb625dc20e Cc: sip@ietf.org, IETF SIPPING WG , dime@ietf.org, tsvwg , NSIS X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org this is good with me At 02:33 AM 8/28/2007, Magnus Westerlund wrote: >Hi again, > >I have received some more comments. So here is=20 >an updated version adding DIME documents and correcting origin of= documents. > > >Submission >Date: , 2007 > >From: IETF Working groups TSVWG, NSIS, DIME, SIP and SIPPING > >To: Georges Sebek , > Keith Knightson > >Cc: Magnus Westerlund , >Lars Eggert , >James Polk , >Martin Stiemerling , >John Loughney >Dean Willis , >Keith Drage , >Mary Barnes , >Gonzalo Camarillo , >Scott Bradner , >Kimberly King , >Scott Brim , >Hannes Tschofenig , >David Frascone > >Response >Contact: TSV WG (tsv-chairs@tools.ietf.org) > NSIS (nsis-chairs@tools.ietf.org) > SIPPING (sipping-chairs@tools.ietf.org) > SIP (sip-chairs@tools.ietf.org) > DIME (dime-chairs@tools.ietf.org) > >Purpose: Response to Liaison Request > >Deadline: None > >Title: Response to liaison request from ITU-T=20 >Study Group 13 work on emergency telecommunications > >This is a response to the liaison request made=20 >by Q.3/13 regarding emergency telecommunications=20 >(REF: NGN-GSI/DOC =AD 60 Rev.2). We would first=20 >like to apologize for failing to meet the=20 >deadline in responding. We do hope that the late=20 >answer still can be of some use. > >The liaison request was made to the following=20 >working groups (WG): IEPREP, TSVWG, and NSIS.=20 >Since the request was sent the IEPREP WG has=20 >concluded. In addition to the WGs from which=20 >information was requested, we also think that=20 >work performed by the DIME, SIP and SIPPING WG may be of relevance. > >Pursuant to ITU-T Study Group 13 request for=20 >information on relevant and related work in the=20 >IETF regarding emergency communications, we list=20 >below RFCs and works in progress that we feel=20 >may be of interest to your group. Some of the=20 >completed work is Informational, and others are=20 >in the category of Standards Track. > >Q.3/13 also requested that we keep you informed=20 >of any developments in regards to emergency=20 >telecommunications. In those regards we would=20 >like to make you aware that IETF mailing list=20 >participation and document information is free=20 >and open to anyone, allowing participants in=20 >Q.3/13 to keep themselves informed of any=20 >developments. If Q.3/13 desire to get further=20 >information about specific ongoing work, then=20 >please send a liaison request to the responsible=20 >WG for those specific documents. > >The following list is divided under the=20 >associated working groups from which the work has been done within the= IETF. > > >SIP Working Group > >RFC 4412 > >Title: > Communications Resource Priority for the Session Initiation > Protocol (SIP) > >Abstract: > This document defines two new Session Initiation Protocol (SIP) > header fields for communicating resource priority, namely, > "Resource-Priority" and "Accept-Resource-Priority". The > "Resource-Priority" header field can influence the behavior of SIP > user agents (such as telephone gateways and IP telephones) and SIP > proxies. It does not directly influence the forwarding behavior of > IP routers. > > The below two documents are proposed=20 > work items accepted to become IETF WG items are=20 > likely of interest as they update RFC 4412. > >Work In Progress: draft-polk-sip-rph-in-responses-00 > >Title: >Allowing SIP Resource Priority Header in SIP Responses > >Abstract: > The Session Initiation Protocol (SIP) Resource Priority Header > (RPH), in its current form, is ignored in SIP responses. This was a > design choice during RFC 4412's development. This is now considered > a bad design choice in certain scenarios. This document corrects > RFC 4412's communications model by optionally allowing a SIP server > or user agent client to process the Resource-Priority Header in a > response. > >Work In Progress: draft-polk-sip-rph-new-namespaces--00 > >Title: >New Session Initiation Protocol=20 >Resource-Priority Header Namespaces for the Defense Information Systems= Agency > >Abstract: > This document creates additional Session Initiation Protocol > Resource-Priority header namespaces, to be IANA registered. This > document intends to update RFC 4412, as a Proposed Standard document > if published by the RFC-Editor. > > > >SIPPING Working Group > >RFC 4411 > >Title: > Extending the Session Initiation Protocol (SIP) > Reason Header for Preemption Events > >Abstract: > This document proposes an IANA Registration extension to the Session > Initiation Protocol (SIP) Reason Header to be included in a BYE > Method Request as a result of a session preemption event, either at a > user agent (UA), or somewhere in the network involving a > reservation-based protocol such as the Resource ReSerVation Protocol > (RSVP) or Next Steps in Signaling (NSIS). This document does not > attempt to address routers failing in the packet path; instead, it > addresses a deliberate tear down of a flow between UAs, and informs > the terminated UA(s) with an indication of what occurred. > >IEPREP Working Group > >RFC 3487 > >Title: > Requirements for Resource Priority Mechanisms for the > Session Initiation Protocol (SIP) > >Abstract: > This document summarizes requirements for prioritizing access to > circuit-switched network, end system and proxy resources for > emergency preparedness communications using the Session Initiation > Protocol (SIP). > >RFC 3689 > >Title: > General Requirements for > Emergency Telecommunication Service (ETS) > >Abstract: > This document presents a list of general requirements in support of > Emergency Telecommunications Service (ETS). Solutions to these > requirements are not presented in this document. Additional > requirements pertaining to specific applications, or types of > applications, are to be specified in separate document(s). > >RFC 3690 > >Title: > IP Telephony Requirements for > Emergency Telecommunication Service (ETS) > >Abstract: > This document presents a list of requirements in support of Emergency > Telecommunications Service (ETS) within the context of IP telephony. > It is an extension to the general requirements presented in RFC 3689. > Solutions to these requirements are not presented in this document. > >RFC 4190 > >Title: > Framework for Supporting Emergency Telecommunications > Service (ETS) in IP Telephony > >Abstract: > This document presents a framework for supporting authorized, > emergency-related communication within the context of IP telephony. > We present a series of objectives that reflect a general view of how > authorized emergency service, in line with the Emergency > Telecommunications Service (ETS), should be realized within today's > IP architecture and service models. From these objectives, we > present a corresponding set of protocols and capabilities, which > provide a more specific set of recommendations regarding existing > IETF protocols. Finally, we present two scenarios that act as > guiding models for the objectives and functions listed in this > document. These models, coupled with an example of an existing > service in the Public Switched Telephone Network (PSTN), contribute > to a constrained solution space. > >RFC 4375 > >Title: > Emergency Telecommunications Services (ETS) Requirements > for a Single Administrative Domain > >Abstract: > This document presents a list of requirements in support of Emergency > Telecommunications Service (ETS) within a single administrative > domain. This document focuses on a specific set of administrative > constraints and scope. Solutions to these requirements are not > presented in this document. > > >TSV Working Group > >RFC 4542 > >Title: > Implementing an Emergency Telecommunications Service (ETS) > for Real-Time Services in the Internet Protocol Suite > >Abstract: > RFCs 3689 and 3690 detail requirements for an Emergency > Telecommunications Service (ETS), of which an Internet Emergency > Preparedness Service (IEPS) would be a part. Some of these types of > services require call preemption; others require call queuing or > other mechanisms. IEPS requires a Call Admission Control (CAC) > procedure and a Per Hop Behavior (PHB) for the data that meet the > needs of this architecture. Such a CAC procedure and PHB is > appropriate to any service that might use H.323 or SIP to set up > real-time sessions. The key requirement is to guarantee an elevated > probability of call completion to an authorized user in time of > crisis. > > This document primarily discusses supporting ETS in the context of > the US Government and NATO, because it focuses on the Multi-Level > Precedence and Preemption (MLPP) and Government Emergency > Telecommunication Service (GETS) standards. The architectures > described here are applicable beyond these organizations. > >Work In Progress: draft-ietf-tsvwg-emergency-rsvp-03.txt > >Title: > Resource ReSerVation Protovol (RSVP) Extensions for > Emergency Services > >Abstract: > An Emergency Telecommunications Service (ETS) requires the ability to > provide an elevated probability of session establishment to an > authorized user in times of network congestion (typically, during a > crisis). When supported over the Internet Protocol suite, this may be > facilitated through a network layer admission control solution, which > supports prioritized access to resources (e.g., bandwidth). These > resources may be explicitly set aside for emergency services, or they > may be shared with other sessions. > > This document specifies RSVP extensions that can be used to support > such an admission priority capability at the network layer. Note that > these extensions represent one possible solution component in > satisfying ETS requirements. Other solution components, or other > solutions, are outside the scope of this document. > >NSIS Working Group > >Work In Progress: draft-ietf-nsis-qos-nslp-14.txt > >Title: >NSLP for Quality-of-Service Signaling > >Abstract: >This specification describes the NSIS Signaling=20 >Layer Protocol (NSLP) for signaling QoS=20 >reservations in the Internet. It is in=20 >accordance with the framework and requirements=20 >developed in NSIS. Together with GIST, it=20 >provides functionality similar to RSVP and=20 >extends it. The QoS NSLP is independent of the=20 >underlying QoS specification or architecture and=20 >provides support for different reservation=20 >models. It is simplified by the elimination of=20 >support for multicast flows. This specification=20 >explains the overall protocol approach, design=20 >decisions made and provides examples. It=20 >specifies object, message formats and processing rules. > >DIME Working Group > >Work In Progress: draft-ietf-dime-diameter-qos-01.txt > >Title: > Diameter Quality of Service Application > >Abstract: > This document describes a Diameter application that performs > Authentication, Authorization, and Accounting for Quality of Service > (QoS) reservations. This protocol is used by elements along the path > of a given application flow to authenticate a reservation request, > ensure that the reservation is authorized, and to account for > resources consumed during the lifetime of the application flow. > Clients that implement the Diameter QoS application contact an > authorizing entity/application server that is located somewhere in > the network, allowing for a wide variety of flexible deployment > models. > >Work In Progress: draft-ietf-dime-qos-parameters-00.txt > >Title: > Quality of Service Parameters for Usage with the AAA Framework > >Abstract: > This document defines a number of Quality of Service (QoS) parameters > that can be reused for conveying QoS information within RADIUS and > Diameter. > > The payloads used to carry these QoS parameters are opaque for the > AAA client and the AAA server itself and interpreted by the > respective Resource Management Function. > >Work In Progress: draft-ietf-dime-qos-attributes-01.txt > >Title: > Quality of Service Attributes for Diameter and RADIUS > >Abstract: > This document extends the functionality of the Diameter Base protocol > and other Diameter applications with respect to their ability to > convey Quality of Service information. The AVPs defined in this > document are also available for Remote Authentication Dial In User > Service (RADIUS). > > >Non-WG Documents > > Approved for publication: draft-carlberg-trip-attribute-rp-02.txt > > Title: > TRIP Attribute for Resource Priority > >Abstract: > This document defines a new attribute for the TRIP protocol. The > attribute associates protocols/services in the PSTN offering > authorized prioritization during call setup that are reachable > through a TRIP gateway. Current examples of preferential service in > the PSTN are Government Emergency Telecommunications Service (GETS) > in the U.S. and Government Telephone Preference Scheme (GTPS) in the > U.K. The proposed attribute for TRIP is based on the NameSpace.Value > tupple defined for the SIP resource Priority field. > > > > >Magnus Westerlund > >IETF Transport Area Director & TSVWG Chair >---------------------------------------------------------------------- >Multimedia Technologies, Ericsson Research EAB/TVM/M >---------------------------------------------------------------------- >Ericsson AB | Phone +46 8 4048287 >Torshamsgatan 23 | Fax +46 8 7575550 >S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >---------------------------------------------------------------------- > > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Aug 29 06:07:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQKQZ-0000Zg-Jk; Wed, 29 Aug 2007 06:05:35 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IQKQX-0000V4-Dl for sip-confirm+ok@megatron.ietf.org; Wed, 29 Aug 2007 06:05:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQKQP-0000OO-SI for sip@ietf.org; Wed, 29 Aug 2007 06:05:27 -0400 Received: from tcmail23.telekom.de ([217.6.95.237]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQKQO-00039h-IN for sip@ietf.org; Wed, 29 Aug 2007 06:05:25 -0400 Received: from S4DE9JSAANM.ost.t-com.de (S4DE9JSAANM.ost.t-com.de [10.125.177.122]) by tcmail21.telekom.de with ESMTP; Wed, 29 Aug 2007 12:05:22 +0200 Received: from S4DE9JSAAHW.ost.t-com.de ([10.125.177.160]) by S4DE9JSAANM.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Aug 2007 12:05:17 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: AW: AW: [Sip] Extension of conference procedures Date: Wed, 29 Aug 2007 12:05:16 +0200 Message-Id: In-reply-to: <144ED8561CE90C41A3E5908EDECE315C04DE7868@IsrExch01.israel.polycom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: [Sip] Extension of conference procedures Thread-Index: Acfn6BpvoIlRzQ3TSY+JaTxjMgL1YgAogIlgAAIl8iAAXHmeQA== From: "Huelsemann, Martin" To: X-OriginalArrivalTime: 29 Aug 2007 10:05:17.0093 (UTC) FILETIME=[19809D50:01C7EA24] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9f79b8e383fd3af2b1b5b1d0910f6094 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, also for the scenario where A refers B to dial into a conference, the = problem is when B has a terminal not supporting REFER (or just doesn't = want to accept the REFER for some reasons), A cannot use the conference = service. Of course these simple terminals are not the desired use-case and there = will be limitations. But if there is a possible fallback solution that = at least increases the chance that A can use the service despite the = fact that B does not fulfill all the requirements for the service, I = think we should try to figure it out. Regards, Martin > -----Urspr=FCngliche Nachricht----- > Von: Even, Roni [mailto:roni.even@polycom.co.il]=20 > Gesendet: Montag, 27. August 2007 12:16 > An: H=FClsemann, Martin; jbemmel@zonnet.nl > Cc: sip@ietf.org > Betreff: RE: AW: [Sip] Extension of conference procedures >=20 >=20 > Hi, > My view is that every solution where you only have A, B and a=20 > conference server and B only supports RFC 3261 will have some=20 > limitation and will be a hack.=20 >=20 > The recommended way to do it is for A to send a Refer to B to=20 > the focus. >=20 > Also asking that B supporting only RFC 3261 will support=20 > conference event package is contradictory. B will not even be=20 > aware that it is in a conference. >=20 > Roni Even >=20 > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > A consensus means that everyone agrees to say collectively=20 > what no one believes individually > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!=20 >=20 > > -----Original Message----- > > From: Huelsemann, Martin [mailto:Martin.Huelsemann@t-com.net] > > Sent: Monday, August 27, 2007 12:59 PM > > To: jbemmel@zonnet.nl > > Cc: sip@ietf.org > > Subject: AW: AW: [Sip] Extension of conference procedures > >=20 > > Hi, > >=20 > > the pure RFC 3261 client won't be the normal case, of=20 > course. But there > > might be networks with which you want to interwork where=20 > those simple > > clients are existing. > > Okay, you got me, it's again the PSTN interworking. So=20 > let's say what is > > needed is a fallback solution for this case. > > On the other hand, this fallback might be useful for a=20 > normal SIP client > > which supports RFC3891, too, e.g. if there are problems with > > authorization. > >=20 > > The user experience of the invitee should be exactly as you=20 > describe. > >=20 > > If A sends the reINVITE / UPDATE himself that could be a=20 > solution, too. > > The only thing is, can B then use all the conference features (e. g. > > conference event package), when the focus has no knowledge on the > > signalling level that B is connected to the conference bridge? > >=20 > > Regards, Martin > >=20 > >=20 > >=20 > >=20 > >=20 > > > -----Urspr=FCngliche Nachricht----- > > > Von: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > > > Gesendet: Sonntag, 26. August 2007 15:24 > > > An: H=FClsemann, Martin > > > Cc: Alexeitsev, Denis; sip@ietf.org > > > Betreff: Re: AW: [Sip] Extension of conference procedures > > > > > > > > > Martin, > > > > > > Now it becomes more clear. So the requirement is to=20 > enable a scenario > > > where a regular call is transformed into a conference=20 > call, assuming > > > that the invitee only has a "pure RFC3261" client. > > > More specifically: > > > > > > - to get a smooth user experience, the scenario must not cause the > > > invitee's phone to ring, and/or ask the invitee for permission > > > (acceptance is assumed to be implied) > > > > > > What if A would send the reINVITE (or UPDATE) itself, while > > > filling in > > > the SDP according to the media provided by the conference > > > server (i.e. > > > use codecs, media ports as received from the focus)? (trying > > > to get the > > > requirements more clear here) > > > > > > In practice, it may still be a challenge to get such "very simple > > > terminals" to properly handle a change of media (i.e. new=20 > destination > > > ip/port for sending, new source ip/port and RTP src id,=20 > and possibly > > > different codecs) > > > > > > Regards, > > > Jeroen > > > > > > > > > Huelsemann, Martin wrote: > > > > Hi Jeroen, > > > > > > > > the usage of the Replaces header is of course the best > > > solution, it's also described in the regarding 3GPP > > > conferencing spec. > > > > The disadvantage of the usage of the Repaces header is, > > > that it puts requirements on the UE of the invited user, it > > > would have to support RFC 3891. And if it supports, it really > > > would have to accept the 2nd INVITE, which is not mandatory > > > according to RFC 3891 I think. > > > > Anyway what is needed in addition is a solution how also > > > very simple terminals (e. g. only supporting RFC 3261) can be > > > invited to an ad-hoc conference, whithout having to say to > > > the invited user to please hang up because there will be a > > > call from the focus shortly. > > > > > > > > Re-using an already established dialog at least at the > > > first glance seems to be a simply and invited UE independent > > > solution. And as this re-INVITE it wanted by at least one of > > > the involved user, I would more compare it to some kind of > > > triggered 3rd party call control than to spoofing. > > > > > > > > Of course as you said it would have to be made clear that > > > the focus is able to collect all the information needed for > > > sending re-INVITEs (proposed "?" mechanism usage, dialog > > > event package, etc.). > > > > > > > > > > > > Regards, Martin > > > > > > > > > > > > > > > > > > > > > > > > > > > >> -----Urspr=FCngliche Nachricht----- > > > >> Von: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > > > >> Gesendet: Freitag, 24. August 2007 17:06 > > > >> An: Alexeitsev, Denis; sip@ietf.org > > > >> Betreff: Re: [Sip] Extension of conference procedures > > > >> > > > >> > > > >> Denis, > > > >> > > > >> If I understand your scenario, "focus" is a third party > > > >> separate from A and > > > >> B, right? (e.g. a conference server) > > > >> > > > >> In that case the focus is not a party in the A-B dialog, and > > > >> would need more > > > >> than Call-ID, From and To to be able to construct a reINVITE > > > >> that B would > > > >> accept as coming from A (e.g. CSeq). In any case, this looks > > > >> like a very > > > >> inelegant, hacked solution (as the conference server is > > > >> basically spoofing) > > > >> > > > >> RFC4579 section 5.10 provides some insipration, as well as > > > >> http://www.ietf.org/internet-drafts/draft-ietf-sipping-service > > > >> -examples-13.txt > > > >> scenario 2.5 > > > >> > > > >> For example, A could include a 'Replaces' header in the URI > > > >> it includes in > > > >> its conference URI list. Then the conference server would > > > send a new > > > >> (out-of-dialog) INVITE to B containing this Replaces header, > > > >> and B would > > > >> know that it is associated with the dialog it has with A (and > > > >> can replace > > > >> it, without ringing if the UA is constructed like that) > > > >> > > > >> The conference server should probably also include a > > > >> Referred-By containing > > > >> A's AoR, either automatically (i.e. copy from From header in > > > >> INVITE) or > > > >> included by A in the URI (former is better) > > > >> > > > >> Regards, > > > >> Jeroen > > > >> > > > >> Alexeitsev, D wrote: > > > >> > > > >>> I'd like to discuss the extension of the current conference > > > >>> > > > >> procedures > > > >> > > > >>> with the following functionality. > > > >>> > > > >>> 3GPP conference specifications are basing generally on the > > > >>> Conferencing Framework (RFC 4353) and for one possibility > > > >>> > > > >> of inviting > > > >> > > > >>> users to the confrence on=20 > draft-ietf-sip-uri-list-conferencing. > > > >>> > > > >>> Using the conferencing framework, the following situation > > > can occur > > > >>> when a user is invited to an ad-hoc conference: > > > >>> User A is in a dialog with user B, and decides to start a > > > >>> > > > >> conference, > > > >> > > > >>> for example using an INVITE request to the focus which > > > >>> > > > >> includes a URI > > > >> > > > >>> list with the URIs of the users which shall be added to the > > > >>> conference, incl. B. So when the INVITE request from the focus > > > >>> arrives at B, he is still in the original dialog with=20 > A, and so it > > > >>> depends on B if he accepts the 2nd INVITE and the > > > conference can be > > > >>> established. > > > >>> > > > >>> At the last 3GPP CT1 meeting the idea of transporting dialog > > > >>> identifiers together with the URIs was introduced to=20 > solve this > > > >>> problem. Basing on the idea that the procedures at=20 > the conference > > > >>> server are extended in that way, that the conference > > > server is aware > > > >>> of already established dialogs, the focus then has the > > > >>> > > > >> possibility to > > > >> > > > >>> send re-INVITES in the indicated dialogs and connect the > > > media from > > > >>> the invited users to the conference bridge. > > > >>> In the URI list the dialogs can be indicated using the > > > "?" mechanism > > > >>> according to subclause 19.1.1 of RFC 3261. > > > >>> > > > >>> Following example shows the proposed mechanism: > > > >>> > > > >>> INVITE Conference > > > >>> To: Conference > > > >>> From: A > > > >>> Require: recipient-list-invite > > > >>> > > > >>> Content-Type: application/resource-lists+xml > > > >>> Content-Disposition: recipient-list > > > >>> > > > >>> > > > >>> > > >>> xmlns:cp=3D"urn:ietf:params:xml:ns:copyControl"> > > > >>> > > > >>> > > >>> cp:copyControl=3D"to"/> > > > >>> > > >>> cp:copyControl=3D"to"/> > > > >>> > > > >>> > > > >>> > > > >>> Greetings, > > > >>> Denis Alexeitsev > > > >>> > > > >>> > > > >>> _______________________________________________ > > > >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > >>> This list is for NEW development of the core SIP Protocol > > > >>> Use sip-implementors@cs.columbia.edu for questions on=20 > current sip > > > >>> Use sipping@ietf.org for 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=20 > current sip > > > >> Use sipping@ietf.org for new developments on the=20 > application of sip > > > >> > > > >> > > > > > > > > > > > > >=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Aug 29 06:12:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQKVu-0006jP-Ms; Wed, 29 Aug 2007 06:11:06 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IQKVs-0006jK-Ms for sip-confirm+ok@megatron.ietf.org; Wed, 29 Aug 2007 06:11:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQKVs-0006jC-Cp for sip@ietf.org; Wed, 29 Aug 2007 06:11:04 -0400 Received: from fw.polycom.co.il ([212.179.41.2] helo=isrexch01.israel.polycom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQKVq-0002f4-1J for sip@ietf.org; Wed, 29 Aug 2007 06:11:04 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: AW: [Sip] Extension of conference procedures Date: Wed, 29 Aug 2007 13:12:11 +0300 Message-ID: <144ED8561CE90C41A3E5908EDECE315C04DE7BC7@IsrExch01.israel.polycom.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: [Sip] Extension of conference procedures Thread-Index: Acfn6BpvoIlRzQ3TSY+JaTxjMgL1YgAogIlgAAIl8iAAXHmeQAAH++sQ From: "Even, Roni" To: "Huelsemann, Martin" X-Spam-Score: 0.0 (/) X-Scan-Signature: 731ea0e9f5725b67e634db1918f3b951 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, In this case, like in PSTN the switch does it. You have to decide who is = "smart" the network or the end device. A "simple" RFC 3261 only phone relies on a 3PCC or softswitch to manage = telephony services (not only conferencing) Roni Even > -----Original Message----- > From: Huelsemann, Martin [mailto:Martin.Huelsemann@t-com.net] > Sent: Wednesday, August 29, 2007 1:05 PM > To: Even, Roni > Cc: sip@ietf.org; jbemmel@zonnet.nl > Subject: AW: AW: [Sip] Extension of conference procedures >=20 > Hi, >=20 > also for the scenario where A refers B to dial into a conference, the > problem is when B has a terminal not supporting REFER (or just doesn't > want to accept the REFER for some reasons), A cannot use the = conference > service. >=20 > Of course these simple terminals are not the desired use-case and = there > will be limitations. But if there is a possible fallback solution that = at > least increases the chance that A can use the service despite the fact > that B does not fulfill all the requirements for the service, I think = we > should try to figure it out. >=20 > Regards, Martin >=20 >=20 >=20 >=20 >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: Even, Roni [mailto:roni.even@polycom.co.il] > > Gesendet: Montag, 27. August 2007 12:16 > > An: H=FClsemann, Martin; jbemmel@zonnet.nl > > Cc: sip@ietf.org > > Betreff: RE: AW: [Sip] Extension of conference procedures > > > > > > Hi, > > My view is that every solution where you only have A, B and a > > conference server and B only supports RFC 3261 will have some > > limitation and will be a hack. > > > > The recommended way to do it is for A to send a Refer to B to > > the focus. > > > > Also asking that B supporting only RFC 3261 will support > > conference event package is contradictory. B will not even be > > aware that it is in a conference. > > > > Roni Even > > > > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > > A consensus means that everyone agrees to say collectively > > what no one believes individually > > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > > > > > -----Original Message----- > > > From: Huelsemann, Martin [mailto:Martin.Huelsemann@t-com.net] > > > Sent: Monday, August 27, 2007 12:59 PM > > > To: jbemmel@zonnet.nl > > > Cc: sip@ietf.org > > > Subject: AW: AW: [Sip] Extension of conference procedures > > > > > > Hi, > > > > > > the pure RFC 3261 client won't be the normal case, of > > course. But there > > > might be networks with which you want to interwork where > > those simple > > > clients are existing. > > > Okay, you got me, it's again the PSTN interworking. So > > let's say what is > > > needed is a fallback solution for this case. > > > On the other hand, this fallback might be useful for a > > normal SIP client > > > which supports RFC3891, too, e.g. if there are problems with > > > authorization. > > > > > > The user experience of the invitee should be exactly as you > > describe. > > > > > > If A sends the reINVITE / UPDATE himself that could be a > > solution, too. > > > The only thing is, can B then use all the conference features (e. = g. > > > conference event package), when the focus has no knowledge on the > > > signalling level that B is connected to the conference bridge? > > > > > > Regards, Martin > > > > > > > > > > > > > > > > > > > -----Urspr=FCngliche Nachricht----- > > > > Von: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > > > > Gesendet: Sonntag, 26. August 2007 15:24 > > > > An: H=FClsemann, Martin > > > > Cc: Alexeitsev, Denis; sip@ietf.org > > > > Betreff: Re: AW: [Sip] Extension of conference procedures > > > > > > > > > > > > Martin, > > > > > > > > Now it becomes more clear. So the requirement is to > > enable a scenario > > > > where a regular call is transformed into a conference > > call, assuming > > > > that the invitee only has a "pure RFC3261" client. > > > > More specifically: > > > > > > > > - to get a smooth user experience, the scenario must not cause = the > > > > invitee's phone to ring, and/or ask the invitee for permission > > > > (acceptance is assumed to be implied) > > > > > > > > What if A would send the reINVITE (or UPDATE) itself, while > > > > filling in > > > > the SDP according to the media provided by the conference > > > > server (i.e. > > > > use codecs, media ports as received from the focus)? (trying > > > > to get the > > > > requirements more clear here) > > > > > > > > In practice, it may still be a challenge to get such "very = simple > > > > terminals" to properly handle a change of media (i.e. new > > destination > > > > ip/port for sending, new source ip/port and RTP src id, > > and possibly > > > > different codecs) > > > > > > > > Regards, > > > > Jeroen > > > > > > > > > > > > Huelsemann, Martin wrote: > > > > > Hi Jeroen, > > > > > > > > > > the usage of the Replaces header is of course the best > > > > solution, it's also described in the regarding 3GPP > > > > conferencing spec. > > > > > The disadvantage of the usage of the Repaces header is, > > > > that it puts requirements on the UE of the invited user, it > > > > would have to support RFC 3891. And if it supports, it really > > > > would have to accept the 2nd INVITE, which is not mandatory > > > > according to RFC 3891 I think. > > > > > Anyway what is needed in addition is a solution how also > > > > very simple terminals (e. g. only supporting RFC 3261) can be > > > > invited to an ad-hoc conference, whithout having to say to > > > > the invited user to please hang up because there will be a > > > > call from the focus shortly. > > > > > > > > > > Re-using an already established dialog at least at the > > > > first glance seems to be a simply and invited UE independent > > > > solution. And as this re-INVITE it wanted by at least one of > > > > the involved user, I would more compare it to some kind of > > > > triggered 3rd party call control than to spoofing. > > > > > > > > > > Of course as you said it would have to be made clear that > > > > the focus is able to collect all the information needed for > > > > sending re-INVITEs (proposed "?" mechanism usage, dialog > > > > event package, etc.). > > > > > > > > > > > > > > > Regards, Martin > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> -----Urspr=FCngliche Nachricht----- > > > > >> Von: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > > > > >> Gesendet: Freitag, 24. August 2007 17:06 > > > > >> An: Alexeitsev, Denis; sip@ietf.org > > > > >> Betreff: Re: [Sip] Extension of conference procedures > > > > >> > > > > >> > > > > >> Denis, > > > > >> > > > > >> If I understand your scenario, "focus" is a third party > > > > >> separate from A and > > > > >> B, right? (e.g. a conference server) > > > > >> > > > > >> In that case the focus is not a party in the A-B dialog, and > > > > >> would need more > > > > >> than Call-ID, From and To to be able to construct a reINVITE > > > > >> that B would > > > > >> accept as coming from A (e.g. CSeq). In any case, this looks > > > > >> like a very > > > > >> inelegant, hacked solution (as the conference server is > > > > >> basically spoofing) > > > > >> > > > > >> RFC4579 section 5.10 provides some insipration, as well as > > > > >> = http://www.ietf.org/internet-drafts/draft-ietf-sipping-service > > > > >> -examples-13.txt > > > > >> scenario 2.5 > > > > >> > > > > >> For example, A could include a 'Replaces' header in the URI > > > > >> it includes in > > > > >> its conference URI list. Then the conference server would > > > > send a new > > > > >> (out-of-dialog) INVITE to B containing this Replaces header, > > > > >> and B would > > > > >> know that it is associated with the dialog it has with A (and > > > > >> can replace > > > > >> it, without ringing if the UA is constructed like that) > > > > >> > > > > >> The conference server should probably also include a > > > > >> Referred-By containing > > > > >> A's AoR, either automatically (i.e. copy from From header in > > > > >> INVITE) or > > > > >> included by A in the URI (former is better) > > > > >> > > > > >> Regards, > > > > >> Jeroen > > > > >> > > > > >> Alexeitsev, D wrote: > > > > >> > > > > >>> I'd like to discuss the extension of the current conference > > > > >>> > > > > >> procedures > > > > >> > > > > >>> with the following functionality. > > > > >>> > > > > >>> 3GPP conference specifications are basing generally on the > > > > >>> Conferencing Framework (RFC 4353) and for one possibility > > > > >>> > > > > >> of inviting > > > > >> > > > > >>> users to the confrence on > > draft-ietf-sip-uri-list-conferencing. > > > > >>> > > > > >>> Using the conferencing framework, the following situation > > > > can occur > > > > >>> when a user is invited to an ad-hoc conference: > > > > >>> User A is in a dialog with user B, and decides to start a > > > > >>> > > > > >> conference, > > > > >> > > > > >>> for example using an INVITE request to the focus which > > > > >>> > > > > >> includes a URI > > > > >> > > > > >>> list with the URIs of the users which shall be added to the > > > > >>> conference, incl. B. So when the INVITE request from the = focus > > > > >>> arrives at B, he is still in the original dialog with > > A, and so it > > > > >>> depends on B if he accepts the 2nd INVITE and the > > > > conference can be > > > > >>> established. > > > > >>> > > > > >>> At the last 3GPP CT1 meeting the idea of transporting dialog > > > > >>> identifiers together with the URIs was introduced to > > solve this > > > > >>> problem. Basing on the idea that the procedures at > > the conference > > > > >>> server are extended in that way, that the conference > > > > server is aware > > > > >>> of already established dialogs, the focus then has the > > > > >>> > > > > >> possibility to > > > > >> > > > > >>> send re-INVITES in the indicated dialogs and connect the > > > > media from > > > > >>> the invited users to the conference bridge. > > > > >>> In the URI list the dialogs can be indicated using the > > > > "?" mechanism > > > > >>> according to subclause 19.1.1 of RFC 3261. > > > > >>> > > > > >>> Following example shows the proposed mechanism: > > > > >>> > > > > >>> INVITE Conference > > > > >>> To: Conference > > > > >>> From: A > > > > >>> Require: recipient-list-invite > > > > >>> > > > > >>> Content-Type: application/resource-lists+xml > > > > >>> Content-Disposition: recipient-list > > > > >>> > > > > >>> > > > > >>> > > > >>> xmlns:cp=3D"urn:ietf:params:xml:ns:copyControl"> > > > > >>> > > > > >>> > > > >>> cp:copyControl=3D"to"/> > > > > >>> > > > >>> cp:copyControl=3D"to"/> > > > > >>> > > > > >>> > > > > >>> > > > > >>> Greetings, > > > > >>> Denis Alexeitsev > > > > >>> > > > > >>> > > > > >>> _______________________________________________ > > > > >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > >>> This list is for NEW development of the core SIP Protocol > > > > >>> Use sip-implementors@cs.columbia.edu for questions on > > current sip > > > > >>> Use sipping@ietf.org for new developments on the > > > > application of sip > > > > >>> > > > > >> > > > > >> _______________________________________________ > > > > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > >> This list is for NEW development of the core SIP Protocol > > > > >> Use sip-implementors@cs.columbia.edu for questions on > > current sip > > > > >> Use sipping@ietf.org for new developments on the > > application of sip > > > > >> > > > > >> > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the application of = sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Aug 29 07:19:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQLY3-0003hF-6Q; Wed, 29 Aug 2007 07:17:23 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IQLY0-0003hA-WC for sip-confirm+ok@megatron.ietf.org; Wed, 29 Aug 2007 07:17:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQLY0-0003h1-MH for sip@ietf.org; Wed, 29 Aug 2007 07:17:20 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQLXz-00044t-BP for sip@ietf.org; Wed, 29 Aug 2007 07:17:20 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 95FA62022B for ; Wed, 29 Aug 2007 13:17:18 +0200 (CEST) X-AuditID: c1b4fb3e-af833bb0000007e1-2e-46d555bec068 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 7AD512013E for ; Wed, 29 Aug 2007 13:17:18 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Aug 2007 13:17:18 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Aug 2007 13:17:17 +0200 Received: from [131.160.36.58] (E000FB0F665DD.lmf.ericsson.se [131.160.36.58]) by mail.lmf.ericsson.se (Postfix) with ESMTP id BB2DE24D5 for ; Wed, 29 Aug 2007 14:17:17 +0300 (EEST) Message-ID: <46D555BD.4010400@ericsson.com> Date: Wed, 29 Aug 2007 14:17:17 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: sip Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Aug 2007 11:17:17.0540 (UTC) FILETIME=[28B08240:01C7EA2E] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [Sip] New revision of draft-ietf-sip-body-handling-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Folks, I have just submitted a new revision of the body handling draft. Until it appears on the archives, you can fetch it from: http://users.piuha.net/gonzalo/temp/draft-ietf-sip-body-handling-00.txt Per our discussions in Chicago, the draft now states that only body parts within the same 'multipart/related' can reference each other using cid URIs. If this is too restrictive, we could also allow using forward references in any context (with no 'multipart/related' at all). Comments? 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 sip-bounces@ietf.org Wed Aug 29 08:16:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQMRU-0002Xu-T4; Wed, 29 Aug 2007 08:14:40 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IQMRS-0002Xg-HD for sip-confirm+ok@megatron.ietf.org; Wed, 29 Aug 2007 08:14:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQMRR-0002XT-SJ for sip@ietf.org; Wed, 29 Aug 2007 08:14:37 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQMRR-0006Z2-DR for sip@ietf.org; Wed, 29 Aug 2007 08:14:37 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 29 Aug 2007 08:14:36 -0400 X-IronPort-AV: i="4.19,321,1183348800"; d="scan'208"; a="130286731:sNHT2787336638" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l7TCEZ3r025494; Wed, 29 Aug 2007 08:14:35 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l7TCEEQi004599; Wed, 29 Aug 2007 12:14:35 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Aug 2007 08:14:31 -0400 Received: from [10.86.240.28] ([10.86.240.28]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Aug 2007 08:14:31 -0400 Message-ID: <46D56325.7080704@cisco.com> Date: Wed, 29 Aug 2007 08:14:29 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Gonzalo Camarillo Subject: Re: [Sip] New revision of draft-ietf-sip-body-handling-00.txt References: <46D555BD.4010400@ericsson.com> In-Reply-To: <46D555BD.4010400@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Aug 2007 12:14:31.0073 (UTC) FILETIME=[273C1110:01C7EA36] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2509; t=1188389675; x=1189253675; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20New=20revision=20of=20draft-ietf-sip-body-han dling-00.txt |Sender:=20 |To:=20Gonzalo=20Camarillo=20; bh=JGAJnax5d+Nd00Us3Rn00fobUVphN0Kpd0KEQ9lMX58=; b=j59GJaBA0/ufbl+7V520XumDg5Nh0unMGTPu+pFF0feeGRVbtIrMgq6rnyIXrrZrlTNz/z3w XitUb52kk55ixrR36Ff4S0hopTI1jf42GMKNb8xJ8i9r646lwRPomxCB; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Gonzalo, Obviously we allow a "forward" reference from the sip message itself (which from a mime perspective are just a bunch of mime headers.) I think that establishes a precedent that needs to be continued. An example of why can be seen in sipfrag: If we had a valid sip response that had a reference into one of its body parts, then if that was turned into a sipfrag and stuffed into the body of a NOTIFY, then it must still be valid. I just did a quick scan of the new draft, so the following is a tentative comment, until I can read it more carefully: I think the draft is now saying that the decision about whether to process a body part according to a reference to it, or process independently, is decided based on whether a reference is found. We had this discussion before, and I think we agreed that wouldn't work well, and that instead we would have a special C-D type for body parts that are disposed of based on a reference. I don't think the introduction of issues related to multipart/related changes this. The obvious cases are when there is a single multipart/mixed containing some body parts. Some of those may be referenced from CID URIs in sip headers, and others (e.g. SDP) may stand on their own. It is entirely possible that a body part might be referenced from some extension header that the recipient doesn't understand. In that case it may erroneously decide to process the body part on its own, when it should instead have ignored it because the header isn't being processed. Thanks, Paul Gonzalo Camarillo wrote: > Folks, > > I have just submitted a new revision of the body handling draft. Until > it appears on the archives, you can fetch it from: > > http://users.piuha.net/gonzalo/temp/draft-ietf-sip-body-handling-00.txt > > Per our discussions in Chicago, the draft now states that only body > parts within the same 'multipart/related' can reference each other using > cid URIs. > > If this is too restrictive, we could also allow using forward references > in any context (with no 'multipart/related' at all). > > Comments? > > 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 > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Aug 29 08:59:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQN73-0005HT-HW; Wed, 29 Aug 2007 08:57:37 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IQN71-0005HN-Uy for sip-confirm+ok@megatron.ietf.org; Wed, 29 Aug 2007 08:57:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQN71-0005HE-Ep for sip@ietf.org; Wed, 29 Aug 2007 08:57:35 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQN70-0008TT-Mw for sip@ietf.org; Wed, 29 Aug 2007 08:57:35 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 29 Aug 2007 08:57:34 -0400 X-IronPort-AV: i="4.19,321,1183348800"; d="scan'208"; a="69415073:sNHT58975388" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l7TCvYsP028199; Wed, 29 Aug 2007 08:57:34 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l7TCvKDZ010220; Wed, 29 Aug 2007 12:57:34 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Aug 2007 08:57:30 -0400 Received: from [161.44.174.118] ([161.44.174.118]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Aug 2007 08:57:29 -0400 Message-ID: <46D56D39.6030300@cisco.com> Date: Wed, 29 Aug 2007 08:57:29 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Gonzalo Camarillo Subject: Re: [Sip] New revision of draft-ietf-sip-body-handling-00.txt References: <46D555BD.4010400@ericsson.com> <46D56325.7080704@cisco.com> In-Reply-To: <46D56325.7080704@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Aug 2007 12:57:29.0901 (UTC) FILETIME=[2855FDD0:01C7EA3C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4928; t=1188392254; x=1189256254; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20New=20revision=20of=20draft-ietf-sip-body-han dling-00.txt |Sender:=20 |To:=20Gonzalo=20Camarillo=20; bh=abSY+nd4KdIUyDDdDpYwe4lFrtg8h4Q2lydOaSMeUKw=; b=Wf9FlKtXW8pwypGfAmJhB+69BkPAa2neCHa9RCIlm88krJRve7uT0km/DV3F8VN4bf1HxzAw 1ybbiidiG/6LzusPFB/PvMqeDHKxPVpCeT7bu3DCCtAO+nIBmG9F84Xe; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org To clarify futher my last point below... What I am saying is that IMO body parts must always be processed according to their type and disposition, whether there are references to them or not. If there is a reference, and it is understood, then it can modify or supplement the processing, but if the reference is not recognized or understood then the other processing still occurs. If we want to support the possibility of a reference to a body part, where there is to be no processing of the body part when the reference is not understood, then we need a content-disposition that says "don't do anything with this unless you process a reference to it." An alternative is to simply assume there are no such cases, and warn people that use references to select a C-D for the referenced part that will have an appropriate result if the reference is not understood. For instance, we have both the Alert-Info header and the "alert" C-D. If you use an A-I with a CID reference, then you can use "alert" as the C-D of that part. In that case, the A-I header is redundant unless it contains something that modifies the processing. An example where the problem I am concerned about may exist is in draft-ietf-sip-location-conveyance-08. It has an example of a Geolocation header referencing a body part. There is no C-D header in the example, so by default it is "render;handling=required". And its C-T is application/pidf+xml. If a recipient of this message didn't understand the Geolocation header it would reach the conclusion that it should render the pidf. Its debatable whether that is the desired conclusion - I think not. IMO the intent is that if the Geolocation header isn't processed then the pidf should be ignored. So, IMO this body part ought to contain: Content-Disposition: by-reference;handling=optional (I don't care what name we use for the disposition, just that we have one.) Thanks, Paul Paul Kyzivat wrote: > Gonzalo, > > Obviously we allow a "forward" reference from the sip message itself > (which from a mime perspective are just a bunch of mime headers.) > > I think that establishes a precedent that needs to be continued. An > example of why can be seen in sipfrag: > > If we had a valid sip response that had a reference into one of its body > parts, then if that was turned into a sipfrag and stuffed into the body > of a NOTIFY, then it must still be valid. > > I just did a quick scan of the new draft, so the following is a > tentative comment, until I can read it more carefully: > > I think the draft is now saying that the decision about whether to > process a body part according to a reference to it, or process > independently, is decided based on whether a reference is found. We had > this discussion before, and I think we agreed that wouldn't work well, > and that instead we would have a special C-D type for body parts that > are disposed of based on a reference. > > I don't think the introduction of issues related to multipart/related > changes this. The obvious cases are when there is a single > multipart/mixed containing some body parts. Some of those may be > referenced from CID URIs in sip headers, and others (e.g. SDP) may stand > on their own. It is entirely possible that a body part might be > referenced from some extension header that the recipient doesn't > understand. In that case it may erroneously decide to process the body > part on its own, when it should instead have ignored it because the > header isn't being processed. > > Thanks, > Paul > > Gonzalo Camarillo wrote: >> Folks, >> >> I have just submitted a new revision of the body handling draft. Until >> it appears on the archives, you can fetch it from: >> >> http://users.piuha.net/gonzalo/temp/draft-ietf-sip-body-handling-00.txt >> >> Per our discussions in Chicago, the draft now states that only body >> parts within the same 'multipart/related' can reference each other >> using cid URIs. >> >> If this is too restrictive, we could also allow using forward >> references in any context (with no 'multipart/related' at all). >> >> Comments? >> >> 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 >> > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Aug 29 10:25:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQOSj-0004l3-Gd; Wed, 29 Aug 2007 10:24:05 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IQOSg-0004jB-Ub for sip-confirm+ok@megatron.ietf.org; Wed, 29 Aug 2007 10:24:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQOSf-0004fo-FK; Wed, 29 Aug 2007 10:24:01 -0400 Received: from ccsmtpgate.mugla.edu.tr ([194.27.32.25] helo=ccsmtpgate.mu.edu.tr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQOSa-00010l-6b; Wed, 29 Aug 2007 10:24:01 -0400 Received: from ccexc01.mu.edu.tr ([10.1.1.15]) by ccsmtpgate.mu.edu.tr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Aug 2007 17:29:36 +0300 Received: from mail pickup service by ccexc01.mu.edu.tr with Microsoft SMTPSVC; Wed, 29 Aug 2007 17:29:34 +0300 Received: from megatron.ietf.org ([156.154.16.145]) by ccsmtpgate.mu.edu.tr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Aug 2007 21:06:05 +0300 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ5Li-0004xP-0F; Tue, 28 Aug 2007 13:59:34 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IQ5Lg-0004wn-Mu for nsis-confirm+ok@megatron.ietf.org; Tue, 28 Aug 2007 13:59:32 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ5Lg-0004wc-Ac; Tue, 28 Aug 2007 13:59:32 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQ5Le-0000b0-OY; Tue, 28 Aug 2007 13:59:32 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 28 Aug 2007 10:59:29 -0700 X-IronPort-AV: i="4.19,317,1183359600"; d="scan'208"; a="15348078:sNHT40240212" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l7SHxTN2013270; Tue, 28 Aug 2007 10:59:29 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l7SHxClh008831; Tue, 28 Aug 2007 17:59:29 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Aug 2007 10:59:21 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.123.166]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Aug 2007 10:59:21 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 28 Aug 2007 12:59:22 -0500 To: Magnus Westerlund From: "James M. Polk" Subject: Re: [NSIS] Re: [Tsvwg] Re: [Sip] Re: Draft Liaison response to SG13 on Emergency Telecommunications In-Reply-To: <46D3CFCF.6070308@ericsson.com> References: <46AF5370.9020304@ericsson.com> <46D2E80E.8000001@ericsson.com> <46D3CFCF.6070308@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Message-ID: X-OriginalArrivalTime: 28 Aug 2007 17:59:21.0205 (UTC) FILETIME=[2919EA50:01C7E99D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=14975; t=1188323969; x=1189187969; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[NSIS]=20Re=3A=20[Tsvwg]=20Re=3A=20[Sip]=20Re=3A=20Dr aft=20Liaison=20response=20to=0A=20=20SG13=20on=20Emergency=20Telecommunic ations |Sender:=20; bh=m99wFMraDniP/oabHCb59sGhsw2Bm5NRjjTI8QPmPjQ=; b=bODCQI96h2iutBG4vGsYcbj1e/Oo4s0WfBpHF2E8WSTSIdETsS+MhpFOBid8YxpSICPCI97d sdgboM6xqHbePJ1KuM3XLQaNN2jxktMXOXQIgqArKt8G+EV6TaxcEWe+; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 89ebdf268eceaeaf784b3acb625dc20e X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 3dc828214e948ff35b815af10e94a823 Cc: sip@ietf.org, dime@ietf.org, IETF SIPPING WG , tsvwg , NSIS X-BeenThere: sip@ietf.org List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org this is good with me At 02:33 AM 8/28/2007, Magnus Westerlund wrote: >Hi again, > >I have received some more comments. So here is=20 >an updated version adding DIME documents and correcting origin of= documents. > > >Submission >Date: , 2007 > >From: IETF Working groups TSVWG, NSIS, DIME, SIP and SIPPING > >To: Georges Sebek , > Keith Knightson > >Cc: Magnus Westerlund , >Lars Eggert , >James Polk , >Martin Stiemerling , >John Loughney >Dean Willis , >Keith Drage , >Mary Barnes , >Gonzalo Camarillo , >Scott Bradner , >Kimberly King , >Scott Brim , >Hannes Tschofenig , >David Frascone > >Response >Contact: TSV WG (tsv-chairs@tools.ietf.org) > NSIS (nsis-chairs@tools.ietf.org) > SIPPING (sipping-chairs@tools.ietf.org) > SIP (sip-chairs@tools.ietf.org) > DIME (dime-chairs@tools.ietf.org) > >Purpose: Response to Liaison Request > >Deadline: None > >Title: Response to liaison request from ITU-T=20 >Study Group 13 work on emergency telecommunications > >This is a response to the liaison request made=20 >by Q.3/13 regarding emergency telecommunications=20 >(REF: NGN-GSI/DOC =AD 60 Rev.2). We would first=20 >like to apologize for failing to meet the=20 >deadline in responding. We do hope that the late=20 >answer still can be of some use. > >The liaison request was made to the following=20 >working groups (WG): IEPREP, TSVWG, and NSIS.=20 >Since the request was sent the IEPREP WG has=20 >concluded. In addition to the WGs from which=20 >information was requested, we also think that=20 >work performed by the DIME, SIP and SIPPING WG may be of relevance. > >Pursuant to ITU-T Study Group 13 request for=20 >information on relevant and related work in the=20 >IETF regarding emergency communications, we list=20 >below RFCs and works in progress that we feel=20 >may be of interest to your group. Some of the=20 >completed work is Informational, and others are=20 >in the category of Standards Track. > >Q.3/13 also requested that we keep you informed=20 >of any developments in regards to emergency=20 >telecommunications. In those regards we would=20 >like to make you aware that IETF mailing list=20 >participation and document information is free=20 >and open to anyone, allowing participants in=20 >Q.3/13 to keep themselves informed of any=20 >developments. If Q.3/13 desire to get further=20 >information about specific ongoing work, then=20 >please send a liaison request to the responsible=20 >WG for those specific documents. > >The following list is divided under the=20 >associated working groups from which the work has been done within the= IETF. > > >SIP Working Group > >RFC 4412 > >Title: > Communications Resource Priority for the Session Initiation > Protocol (SIP) > >Abstract: > This document defines two new Session Initiation Protocol (SIP) > header fields for communicating resource priority, namely, > "Resource-Priority" and "Accept-Resource-Priority". The > "Resource-Priority" header field can influence the behavior of SIP > user agents (such as telephone gateways and IP telephones) and SIP > proxies. It does not directly influence the forwarding behavior of > IP routers. > > The below two documents are proposed=20 > work items accepted to become IETF WG items are=20 > likely of interest as they update RFC 4412. > >Work In Progress: draft-polk-sip-rph-in-responses-00 > >Title: >Allowing SIP Resource Priority Header in SIP Responses > >Abstract: > The Session Initiation Protocol (SIP) Resource Priority Header > (RPH), in its current form, is ignored in SIP responses. This was a > design choice during RFC 4412's development. This is now considered > a bad design choice in certain scenarios. This document corrects > RFC 4412's communications model by optionally allowing a SIP server > or user agent client to process the Resource-Priority Header in a > response. > >Work In Progress: draft-polk-sip-rph-new-namespaces--00 > >Title: >New Session Initiation Protocol=20 >Resource-Priority Header Namespaces for the Defense Information Systems= Agency > >Abstract: > This document creates additional Session Initiation Protocol > Resource-Priority header namespaces, to be IANA registered. This > document intends to update RFC 4412, as a Proposed Standard document > if published by the RFC-Editor. > > > >SIPPING Working Group > >RFC 4411 > >Title: > Extending the Session Initiation Protocol (SIP) > Reason Header for Preemption Events > >Abstract: > This document proposes an IANA Registration extension to the Session > Initiation Protocol (SIP) Reason Header to be included in a BYE > Method Request as a result of a session preemption event, either at a > user agent (UA), or somewhere in the network involving a > reservation-based protocol such as the Resource ReSerVation Protocol > (RSVP) or Next Steps in Signaling (NSIS). This document does not > attempt to address routers failing in the packet path; instead, it > addresses a deliberate tear down of a flow between UAs, and informs > the terminated UA(s) with an indication of what occurred. > >IEPREP Working Group > >RFC 3487 > >Title: > Requirements for Resource Priority Mechanisms for the > Session Initiation Protocol (SIP) > >Abstract: > This document summarizes requirements for prioritizing access to > circuit-switched network, end system and proxy resources for > emergency preparedness communications using the Session Initiation > Protocol (SIP). > >RFC 3689 > >Title: > General Requirements for > Emergency Telecommunication Service (ETS) > >Abstract: > This document presents a list of general requirements in support of > Emergency Telecommunications Service (ETS). Solutions to these > requirements are not presented in this document. Additional > requirements pertaining to specific applications, or types of > applications, are to be specified in separate document(s). > >RFC 3690 > >Title: > IP Telephony Requirements for > Emergency Telecommunication Service (ETS) > >Abstract: > This document presents a list of requirements in support of Emergency > Telecommunications Service (ETS) within the context of IP telephony. > It is an extension to the general requirements presented in RFC 3689. > Solutions to these requirements are not presented in this document. > >RFC 4190 > >Title: > Framework for Supporting Emergency Telecommunications > Service (ETS) in IP Telephony > >Abstract: > This document presents a framework for supporting authorized, > emergency-related communication within the context of IP telephony. > We present a series of objectives that reflect a general view of how > authorized emergency service, in line with the Emergency > Telecommunications Service (ETS), should be realized within today's > IP architecture and service models. From these objectives, we > present a corresponding set of protocols and capabilities, which > provide a more specific set of recommendations regarding existing > IETF protocols. Finally, we present two scenarios that act as > guiding models for the objectives and functions listed in this > document. These models, coupled with an example of an existing > service in the Public Switched Telephone Network (PSTN), contribute > to a constrained solution space. > >RFC 4375 > >Title: > Emergency Telecommunications Services (ETS) Requirements > for a Single Administrative Domain > >Abstract: > This document presents a list of requirements in support of Emergency > Telecommunications Service (ETS) within a single administrative > domain. This document focuses on a specific set of administrative > constraints and scope. Solutions to these requirements are not > presented in this document. > > >TSV Working Group > >RFC 4542 > >Title: > Implementing an Emergency Telecommunications Service (ETS) > for Real-Time Services in the Internet Protocol Suite > >Abstract: > RFCs 3689 and 3690 detail requirements for an Emergency > Telecommunications Service (ETS), of which an Internet Emergency > Preparedness Service (IEPS) would be a part. Some of these types of > services require call preemption; others require call queuing or > other mechanisms. IEPS requires a Call Admission Control (CAC) > procedure and a Per Hop Behavior (PHB) for the data that meet the > needs of this architecture. Such a CAC procedure and PHB is > appropriate to any service that might use H.323 or SIP to set up > real-time sessions. The key requirement is to guarantee an elevated > probability of call completion to an authorized user in time of > crisis. > > This document primarily discusses supporting ETS in the context of > the US Government and NATO, because it focuses on the Multi-Level > Precedence and Preemption (MLPP) and Government Emergency > Telecommunication Service (GETS) standards. The architectures > described here are applicable beyond these organizations. > >Work In Progress: draft-ietf-tsvwg-emergency-rsvp-03.txt > >Title: > Resource ReSerVation Protovol (RSVP) Extensions for > Emergency Services > >Abstract: > An Emergency Telecommunications Service (ETS) requires the ability to > provide an elevated probability of session establishment to an > authorized user in times of network congestion (typically, during a > crisis). When supported over the Internet Protocol suite, this may be > facilitated through a network layer admission control solution, which > supports prioritized access to resources (e.g., bandwidth). These > resources may be explicitly set aside for emergency services, or they > may be shared with other sessions. > > This document specifies RSVP extensions that can be used to support > such an admission priority capability at the network layer. Note that > these extensions represent one possible solution component in > satisfying ETS requirements. Other solution components, or other > solutions, are outside the scope of this document. > >NSIS Working Group > >Work In Progress: draft-ietf-nsis-qos-nslp-14.txt > >Title: >NSLP for Quality-of-Service Signaling > >Abstract: >This specification describes the NSIS Signaling=20 >Layer Protocol (NSLP) for signaling QoS=20 >reservations in the Internet. It is in=20 >accordance with the framework and requirements=20 >developed in NSIS. Together with GIST, it=20 >provides functionality similar to RSVP and=20 >extends it. The QoS NSLP is independent of the=20 >underlying QoS specification or architecture and=20 >provides support for different reservation=20 >models. It is simplified by the elimination of=20 >support for multicast flows. This specification=20 >explains the overall protocol approach, design=20 >decisions made and provides examples. It=20 >specifies object, message formats and processing rules. > >DIME Working Group > >Work In Progress: draft-ietf-dime-diameter-qos-01.txt > >Title: > Diameter Quality of Service Application > >Abstract: > This document describes a Diameter application that performs > Authentication, Authorization, and Accounting for Quality of Service > (QoS) reservations. This protocol is used by elements along the path > of a given application flow to authenticate a reservation request, > ensure that the reservation is authorized, and to account for > resources consumed during the lifetime of the application flow. > Clients that implement the Diameter QoS application contact an > authorizing entity/application server that is located somewhere in > the network, allowing for a wide variety of flexible deployment > models. > >Work In Progress: draft-ietf-dime-qos-parameters-00.txt > >Title: > Quality of Service Parameters for Usage with the AAA Framework > >Abstract: > This document defines a number of Quality of Service (QoS) parameters > that can be reused for conveying QoS information within RADIUS and > Diameter. > > The payloads used to carry these QoS parameters are opaque for the > AAA client and the AAA server itself and interpreted by the > respective Resource Management Function. > >Work In Progress: draft-ietf-dime-qos-attributes-01.txt > >Title: > Quality of Service Attributes for Diameter and RADIUS > >Abstract: > This document extends the functionality of the Diameter Base protocol > and other Diameter applications with respect to their ability to > convey Quality of Service information. The AVPs defined in this > document are also available for Remote Authentication Dial In User > Service (RADIUS). > > >Non-WG Documents > > Approved for publication: draft-carlberg-trip-attribute-rp-02.txt > > Title: > TRIP Attribute for Resource Priority > >Abstract: > This document defines a new attribute for the TRIP protocol. The > attribute associates protocols/services in the PSTN offering > authorized prioritization during call setup that are reachable > through a TRIP gateway. Current examples of preferential service in > the PSTN are Government Emergency Telecommunications Service (GETS) > in the U.S. and Government Telephone Preference Scheme (GTPS) in the > U.K. The proposed attribute for TRIP is based on the NameSpace.Value > tupple defined for the SIP resource Priority field. > > > > >Magnus Westerlund > >IETF Transport Area Director & TSVWG Chair >---------------------------------------------------------------------- >Multimedia Technologies, Ericsson Research EAB/TVM/M >---------------------------------------------------------------------- >Ericsson AB | Phone +46 8 4048287 >Torshamsgatan 23 | Fax +46 8 7575550 >S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >---------------------------------------------------------------------- > > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Aug 29 10:36:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQOcz-0004O7-Cj; Wed, 29 Aug 2007 10:34:41 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IQOcy-0004O0-9J for sip-confirm+ok@megatron.ietf.org; Wed, 29 Aug 2007 10:34:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQOcx-0004Ns-Vs for sip@ietf.org; Wed, 29 Aug 2007 10:34:39 -0400 Received: from mu-out-0910.google.com ([209.85.134.185]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQOcw-0001Kj-FX for sip@ietf.org; Wed, 29 Aug 2007 10:34:39 -0400 Received: by mu-out-0910.google.com with SMTP id w8so240897mue for ; Wed, 29 Aug 2007 07:34:37 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=aUagHufoVhE7WtwoAPmue19BJPc4hy8P69436Evre0JPjxd32E/zGVqwVsK5aSQkg5m2oQh1HrFeNyUDZ7JdqNQ5F2ofD4NhxQUa2jkSSGem3qhhs0fXcw6RIyUw2t+SiK8DGevLypUlaFBwQQQ9ttgs+F1j7jhp8jUxyUvuJho= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Vt/mOBYuRlXQ3Eem5rJzrb+bC6CJAQkzpypzqhrQytTufge2Mr6J4ynwqpzPdBXCoNqgriyJyU9M/IJCxNQKgRz9RFOrQHi5LW18SmyT62p6Ymtxs2qcJiyVeMo9tKnGhF71dNoyDon6NQ093ODE2fQPsjn7K1gYk6ZpdF9KHUU= Received: by 10.82.170.2 with SMTP id s2mr1431398bue.1188396472271; Wed, 29 Aug 2007 07:07:52 -0700 (PDT) Received: by 10.82.108.10 with HTTP; Wed, 29 Aug 2007 07:07:52 -0700 (PDT) Message-ID: <317ceda50708290707o41400c0cnbde78f49c9ab18f6@mail.gmail.com> Date: Wed, 29 Aug 2007 22:07:52 +0800 From: "Peili Xu" To: "Even, Roni" Subject: Re: AW: [Sip] Extension of conference procedures In-Reply-To: <144ED8561CE90C41A3E5908EDECE315C04DE7BC7@IsrExch01.israel.polycom.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <144ED8561CE90C41A3E5908EDECE315C04DE7BC7@IsrExch01.israel.polycom.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: fca7d4b87f391aa4d413f865ce6efe79 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Martin, Denis, I agree with Roni that you may need to decide who is "smart". I guess you want to simulate the 3PTY services in PSTN, A make call to B, then A Hold B, then A Make Call to C, then A could do sth like hook flash to turn the call between A-B and A-C to an 3pty conference. later, A could still turn the conferece back to 2 independant call. You have some assumption that the AS who performs conference is on the path between A-B and A-C. And A could inform the AS to turn the call between A-B and A-C to a conference. If the assumption is correct, what you want is just to tell the AS which dialogs should be turned to conference by sending an INVITE with the related dialog information. If the above understanding is correct, I'd agree with the initial proposal from Denis. Just to convey the dialog information along with the URI-List. Peili 2007/8/29, Even, Roni : > > Hi, > In this case, like in PSTN the switch does it. You have to decide who is = "smart" the network or the end device. > A "simple" RFC 3261 only phone relies on a 3PCC or softswitch to manage t= elephony services (not only conferencing) > > Roni Even > > > -----Original Message----- > > From: Huelsemann, Martin [mailto:Martin.Huelsemann@t-com.net] > > Sent: Wednesday, August 29, 2007 1:05 PM > > To: Even, Roni > > Cc: sip@ietf.org; jbemmel@zonnet.nl > > Subject: AW: AW: [Sip] Extension of conference procedures > > > > Hi, > > > > also for the scenario where A refers B to dial into a conference, the > > problem is when B has a terminal not supporting REFER (or just doesn't > > want to accept the REFER for some reasons), A cannot use the conference > > service. > > > > Of course these simple terminals are not the desired use-case and there > > will be limitations. But if there is a possible fallback solution that = at > > least increases the chance that A can use the service despite the fact > > that B does not fulfill all the requirements for the service, I think w= e > > should try to figure it out. > > > > Regards, Martin > > > > > > > > > > > > > -----Urspr=FCngliche Nachricht----- > > > Von: Even, Roni [mailto:roni.even@polycom.co.il] > > > Gesendet: Montag, 27. August 2007 12:16 > > > An: H=FClsemann, Martin; jbemmel@zonnet.nl > > > Cc: sip@ietf.org > > > Betreff: RE: AW: [Sip] Extension of conference procedures > > > > > > > > > Hi, > > > My view is that every solution where you only have A, B and a > > > conference server and B only supports RFC 3261 will have some > > > limitation and will be a hack. > > > > > > The recommended way to do it is for A to send a Refer to B to > > > the focus. > > > > > > Also asking that B supporting only RFC 3261 will support > > > conference event package is contradictory. B will not even be > > > aware that it is in a conference. > > > > > > Roni Even > > > > > > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > > > A consensus means that everyone agrees to say collectively > > > what no one believes individually > > > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > > > > > > > -----Original Message----- > > > > From: Huelsemann, Martin [mailto:Martin.Huelsemann@t-com.net] > > > > Sent: Monday, August 27, 2007 12:59 PM > > > > To: jbemmel@zonnet.nl > > > > Cc: sip@ietf.org > > > > Subject: AW: AW: [Sip] Extension of conference procedures > > > > > > > > Hi, > > > > > > > > the pure RFC 3261 client won't be the normal case, of > > > course. But there > > > > might be networks with which you want to interwork where > > > those simple > > > > clients are existing. > > > > Okay, you got me, it's again the PSTN interworking. So > > > let's say what is > > > > needed is a fallback solution for this case. > > > > On the other hand, this fallback might be useful for a > > > normal SIP client > > > > which supports RFC3891, too, e.g. if there are problems with > > > > authorization. > > > > > > > > The user experience of the invitee should be exactly as you > > > describe. > > > > > > > > If A sends the reINVITE / UPDATE himself that could be a > > > solution, too. > > > > The only thing is, can B then use all the conference features (e. g= . > > > > conference event package), when the focus has no knowledge on the > > > > signalling level that B is connected to the conference bridge? > > > > > > > > Regards, Martin > > > > > > > > > > > > > > > > > > > > > > > > > -----Urspr=FCngliche Nachricht----- > > > > > Von: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > > > > > Gesendet: Sonntag, 26. August 2007 15:24 > > > > > An: H=FClsemann, Martin > > > > > Cc: Alexeitsev, Denis; sip@ietf.org > > > > > Betreff: Re: AW: [Sip] Extension of conference procedures > > > > > > > > > > > > > > > Martin, > > > > > > > > > > Now it becomes more clear. So the requirement is to > > > enable a scenario > > > > > where a regular call is transformed into a conference > > > call, assuming > > > > > that the invitee only has a "pure RFC3261" client. > > > > > More specifically: > > > > > > > > > > - to get a smooth user experience, the scenario must not cause th= e > > > > > invitee's phone to ring, and/or ask the invitee for permission > > > > > (acceptance is assumed to be implied) > > > > > > > > > > What if A would send the reINVITE (or UPDATE) itself, while > > > > > filling in > > > > > the SDP according to the media provided by the conference > > > > > server (i.e. > > > > > use codecs, media ports as received from the focus)? (trying > > > > > to get the > > > > > requirements more clear here) > > > > > > > > > > In practice, it may still be a challenge to get such "very simple > > > > > terminals" to properly handle a change of media (i.e. new > > > destination > > > > > ip/port for sending, new source ip/port and RTP src id, > > > and possibly > > > > > different codecs) > > > > > > > > > > Regards, > > > > > Jeroen > > > > > > > > > > > > > > > Huelsemann, Martin wrote: > > > > > > Hi Jeroen, > > > > > > > > > > > > the usage of the Replaces header is of course the best > > > > > solution, it's also described in the regarding 3GPP > > > > > conferencing spec. > > > > > > The disadvantage of the usage of the Repaces header is, > > > > > that it puts requirements on the UE of the invited user, it > > > > > would have to support RFC 3891. And if it supports, it really > > > > > would have to accept the 2nd INVITE, which is not mandatory > > > > > according to RFC 3891 I think. > > > > > > Anyway what is needed in addition is a solution how also > > > > > very simple terminals (e. g. only supporting RFC 3261) can be > > > > > invited to an ad-hoc conference, whithout having to say to > > > > > the invited user to please hang up because there will be a > > > > > call from the focus shortly. > > > > > > > > > > > > Re-using an already established dialog at least at the > > > > > first glance seems to be a simply and invited UE independent > > > > > solution. And as this re-INVITE it wanted by at least one of > > > > > the involved user, I would more compare it to some kind of > > > > > triggered 3rd party call control than to spoofing. > > > > > > > > > > > > Of course as you said it would have to be made clear that > > > > > the focus is able to collect all the information needed for > > > > > sending re-INVITEs (proposed "?" mechanism usage, dialog > > > > > event package, etc.). > > > > > > > > > > > > > > > > > > Regards, Martin > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> -----Urspr=FCngliche Nachricht----- > > > > > >> Von: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > > > > > >> Gesendet: Freitag, 24. August 2007 17:06 > > > > > >> An: Alexeitsev, Denis; sip@ietf.org > > > > > >> Betreff: Re: [Sip] Extension of conference procedures > > > > > >> > > > > > >> > > > > > >> Denis, > > > > > >> > > > > > >> If I understand your scenario, "focus" is a third party > > > > > >> separate from A and > > > > > >> B, right? (e.g. a conference server) > > > > > >> > > > > > >> In that case the focus is not a party in the A-B dialog, and > > > > > >> would need more > > > > > >> than Call-ID, From and To to be able to construct a reINVITE > > > > > >> that B would > > > > > >> accept as coming from A (e.g. CSeq). In any case, this looks > > > > > >> like a very > > > > > >> inelegant, hacked solution (as the conference server is > > > > > >> basically spoofing) > > > > > >> > > > > > >> RFC4579 section 5.10 provides some insipration, as well as > > > > > >> http://www.ietf.org/internet-drafts/draft-ietf-sipping-service > > > > > >> -examples-13.txt > > > > > >> scenario 2.5 > > > > > >> > > > > > >> For example, A could include a 'Replaces' header in the URI > > > > > >> it includes in > > > > > >> its conference URI list. Then the conference server would > > > > > send a new > > > > > >> (out-of-dialog) INVITE to B containing this Replaces header, > > > > > >> and B would > > > > > >> know that it is associated with the dialog it has with A (and > > > > > >> can replace > > > > > >> it, without ringing if the UA is constructed like that) > > > > > >> > > > > > >> The conference server should probably also include a > > > > > >> Referred-By containing > > > > > >> A's AoR, either automatically (i.e. copy from From header in > > > > > >> INVITE) or > > > > > >> included by A in the URI (former is better) > > > > > >> > > > > > >> Regards, > > > > > >> Jeroen > > > > > >> > > > > > >> Alexeitsev, D wrote: > > > > > >> > > > > > >>> I'd like to discuss the extension of the current conference > > > > > >>> > > > > > >> procedures > > > > > >> > > > > > >>> with the following functionality. > > > > > >>> > > > > > >>> 3GPP conference specifications are basing generally on the > > > > > >>> Conferencing Framework (RFC 4353) and for one possibility > > > > > >>> > > > > > >> of inviting > > > > > >> > > > > > >>> users to the confrence on > > > draft-ietf-sip-uri-list-conferencing. > > > > > >>> > > > > > >>> Using the conferencing framework, the following situation > > > > > can occur > > > > > >>> when a user is invited to an ad-hoc conference: > > > > > >>> User A is in a dialog with user B, and decides to start a > > > > > >>> > > > > > >> conference, > > > > > >> > > > > > >>> for example using an INVITE request to the focus which > > > > > >>> > > > > > >> includes a URI > > > > > >> > > > > > >>> list with the URIs of the users which shall be added to the > > > > > >>> conference, incl. B. So when the INVITE request from the focu= s > > > > > >>> arrives at B, he is still in the original dialog with > > > A, and so it > > > > > >>> depends on B if he accepts the 2nd INVITE and the > > > > > conference can be > > > > > >>> established. > > > > > >>> > > > > > >>> At the last 3GPP CT1 meeting the idea of transporting dialog > > > > > >>> identifiers together with the URIs was introduced to > > > solve this > > > > > >>> problem. Basing on the idea that the procedures at > > > the conference > > > > > >>> server are extended in that way, that the conference > > > > > server is aware > > > > > >>> of already established dialogs, the focus then has the > > > > > >>> > > > > > >> possibility to > > > > > >> > > > > > >>> send re-INVITES in the indicated dialogs and connect the > > > > > media from > > > > > >>> the invited users to the conference bridge. > > > > > >>> In the URI list the dialogs can be indicated using the > > > > > "?" mechanism > > > > > >>> according to subclause 19.1.1 of RFC 3261. > > > > > >>> > > > > > >>> Following example shows the proposed mechanism: > > > > > >>> > > > > > >>> INVITE Conference > > > > > >>> To: Conference > > > > > >>> From: A > > > > > >>> Require: recipient-list-invite > > > > > >>> > > > > > >>> Content-Type: application/resource-lists+xml > > > > > >>> Content-Disposition: recipient-list > > > > > >>> > > > > > >>> > > > > > >>> > > > > >>> xmlns:cp=3D"urn:ietf:params:xml:ns:copyControl"> > > > > > >>> > > > > > >>> > > > > >>> cp:copyControl=3D"to"/> > > > > > >>> > > > > >>> cp:copyControl=3D"to"/> > > > > > >>> > > > > > >>> > > > > > >>> > > > > > >>> Greetings, > > > > > >>> Denis Alexeitsev > > > > > >>> > > > > > >>> > > > > > >>> _______________________________________________ > > > > > >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > > >>> This list is for NEW development of the core SIP 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 sip-bounces@ietf.org Wed Aug 29 15:02:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQSm9-0002UZ-Ty; Wed, 29 Aug 2007 15:00:25 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IQSm5-0002T7-Bd for sip-confirm+ok@megatron.ietf.org; Wed, 29 Aug 2007 15:00:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQSm3-0002R5-Nh; Wed, 29 Aug 2007 15:00:20 -0400 Received: from wip-cdc-wd.wipro.com ([203.91.201.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQSm1-0002qs-QT; Wed, 29 Aug 2007 15:00:19 -0400 Received: from wip-cdc-wd.wipro.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id E9AD018089; Thu, 30 Aug 2007 00:30:32 +0530 (IST) Received: from blr-ec-bh01.wipro.com (blr-ec-bh01.wipro.com [10.201.50.91]) by wip-cdc-wd.wipro.com (Postfix) with ESMTP id DA34018086; Thu, 30 Aug 2007 00:30:32 +0530 (IST) Received: from KOL-SLK-MBX01.wipro.com ([10.141.1.182]) by blr-ec-bh01.wipro.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Aug 2007 00:30:50 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 30 Aug 2007 00:30:49 +0530 Message-ID: <70B22B83C930694D9639F7496C1786920DE9B9@KOL-SLK-MBX01.wipro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Reg] Diversion Header Thread-Index: AcfqbeqdLJEOLi4IQeeg5QcOeg0KRA== From: To: , X-OriginalArrivalTime: 29 Aug 2007 19:00:50.0073 (UTC) FILETIME=[EA404090:01C7EA6E] X-Spam-Score: 1.8 (+) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: Subject: [Sip] [Reg] Diversion Header X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0510875494==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0510875494== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7EA6E.E9DFA5E6" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7EA6E.E9DFA5E6 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 I need some clarification regarding the encoding syntax of SIP Diversion = header parameters reason & privacy .=20 =20 I am aware that Diversion header is replaced by History-Info, but I need = to support Diversion header for some network implementation.=20 =20 diversion-reason =3D "reason" "=3D" ( "unknown" | "user-busy" | "no-answer" | "unavailable" | "unconditional" | "time-of-day" | "do-not-disturb" | "deflection" | "follow-me" | "out-of-service" | "away" | token | quoted-string ) diversion-privacy =3D "privacy" "=3D" ( "full" | "name" | "uri" | "off" | token | quoted-string ) I like to know which is the correct syntax for the diversion-privacy & = diversion-reason parameter i.e.=20 =20 Diversion: ...;reason=3D"user-busy";privacy=3D"full" =20 or, =20 Diversion: ...;reason=3Duser-busy;privacy=3Dfull =20 Cheers, Subhodeep ------_=_NextPart_001_01C7EA6E.E9DFA5E6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A=
=0A=
Hi,
=0A=
 
=0A=
I need some clarification = regarding the encoding syntax of SIP Diversion header parameters reason = & privacy .
=0A=
 
=0A=
I am aware that Diversion = header is replaced by History-Info, but I need to support Diversion = header for some network implementation.
=0A=
 
=0A=
    diversion-reason =3D "reason" = "=3D"
          &nbs= p;         ( "unknown" | = "user-busy" | "no-answer" = |
           &n= bsp;          "unavailable" = | "unconditional" = |
           &n= bsp;          "time-of-day" = | "do-not-disturb" = |
           &n= bsp;          "deflection" = | "follow-me" = |
           &n= bsp;          = "out-of-service" | "away" = |
           &n= bsp;          token | = quoted-string )
=0A=
    diversion-privacy =3D "privacy" "=3D" ( = "full" | "name" = |
           &n= bsp;            = "uri" | "off" | token | quoted-string )
=0A=
I like to = know which is the correct syntax for the diversion-privacy & = diversion-reason parameter i.e.
=0A=
 
=0A=
Diversion: = ...;reason=3D"user-busy";privacy=3D"full"
=0A=
 
=0A=
or,
=0A=
 
=0A=
=0A=
Diversion: ...;reason=3Duser-busy;privacy=3Dfull
=0A=
 
=0A=
Cheers,
=0A=
Subhodeep
------_=_NextPart_001_01C7EA6E.E9DFA5E6-- --===============0510875494== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0510875494==-- From sip-bounces@ietf.org Wed Aug 29 15:06:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQSq1-0005gX-Kk; Wed, 29 Aug 2007 15:04:25 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IQSpu-0005Xl-4r for sip-confirm+ok@megatron.ietf.org; Wed, 29 Aug 2007 15:04:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQSpt-0005VJ-7P; Wed, 29 Aug 2007 15:04:17 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IQSpr-0002y4-QO; Wed, 29 Aug 2007 15:04:17 -0400 X-VirusChecked: Checked X-Env-Sender: ranjit@motorola.com X-Msg-Ref: server-9.tower-128.messagelabs.com!1188414254!16715842!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.189.100.102] Received: (qmail 14896 invoked from network); 29 Aug 2007 19:04:14 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-9.tower-128.messagelabs.com with SMTP; 29 Aug 2007 19:04:14 -0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id l7TJ4Ecs001868; Wed, 29 Aug 2007 12:04:14 -0700 (MST) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id l7TJ4CTF021521; Wed, 29 Aug 2007 14:04:13 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 30 Aug 2007 03:04:07 +0800 Message-ID: <750BBC72E178114F9DC4872EBFF29A5B04EDDA4D@ZMY16EXM66.ds.mot.com> In-Reply-To: <70B22B83C930694D9639F7496C1786920DE9B9@KOL-SLK-MBX01.wipro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] [Reg] Diversion Header thread-index: AcfqbeqdLJEOLi4IQeeg5QcOeg0KRAAAVllA References: <70B22B83C930694D9639F7496C1786920DE9B9@KOL-SLK-MBX01.wipro.com> From: "Avasarala Ranjit-A20990" To: , , X-Spam-Score: -4.0 (----) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Cc: Subject: [Sip] RE: [Sipping] [Reg] Diversion Header X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0131904438==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0131904438== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7EA6F.625BDA17" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7EA6F.625BDA17 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Subhodeep =20 The correct syntax would be: Diversion: ...;reason=3D"user-busy";privacy=3D"full" =20 Regards=20 Ranjit=20 =20 ________________________________ From: subhodeep.sarkar@wipro.com [mailto:subhodeep.sarkar@wipro.com]=20 Sent: Thursday, August 30, 2007 12:31 AM To: sip@ietf.org; sipping@ietf.org Subject: [Sipping] [Reg] Diversion Header Hi, =20 I need some clarification regarding the encoding syntax of SIP Diversion header parameters reason & privacy .=20 =20 I am aware that Diversion header is replaced by History-Info, but I need to support Diversion header for some network implementation.=20 =20 diversion-reason =3D "reason" "=3D" ( "unknown" | "user-busy" | "no-answer" | "unavailable" | "unconditional" | "time-of-day" | "do-not-disturb" | "deflection" | "follow-me" | "out-of-service" | "away" | token | quoted-string ) diversion-privacy =3D "privacy" "=3D" ( "full" | "name" | "uri" | "off" | token | quoted-string ) I like to know which is the correct syntax for the diversion-privacy & diversion-reason parameter i.e.=20 =20 Diversion: ...;reason=3D"user-busy";privacy=3D"full" =20 or, =20 Diversion: ...;reason=3Duser-busy;privacy=3Dfull =20 Cheers, Subhodeep ------_=_NextPart_001_01C7EA6F.625BDA17 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hi Subhodeep
 
The correct syntax would be: Diversion:=20 ...;reason=3D"user-busy";privacy=3D"full"
=
 

Regards
Ranjit

 

From: subhodeep.sarkar@wipro.com=20 [mailto:subhodeep.sarkar@wipro.com]
Sent: Thursday, August = 30, 2007=20 12:31 AM
To: sip@ietf.org; sipping@ietf.org
Subject: = [Sipping] [Reg] Diversion Header

Hi,
 
I need some clarification = regarding the=20 encoding syntax of SIP Diversion header parameters reason & = privacy .=20
 
I am aware that Diversion = header is=20 replaced by History-Info, but I need to support Diversion header for = some=20 network implementation.
 
   =20 diversion-reason =3D "reason"=20 "=3D"
          &nbs= p;        =20 ( "unknown" | "user-busy" | "no-answer"=20 |
           &n= bsp;         =20 "unavailable" | "unconditional"=20 |
           &n= bsp;         =20 "time-of-day" | "do-not-disturb"=20 |
           &n= bsp;         =20 "deflection" | "follow-me"=20 |
           &n= bsp;         =20 "out-of-service" | "away"=20 |
           &n= bsp;         =20 token | quoted-string )
    diversion-privacy =3D "privacy" "=3D" ( = "full" | "name"=20 |
           &n= bsp;           =20 "uri" | "off" | token | quoted-string )
I like to = know which is the=20 correct syntax for the diversion-privacy & diversion-reason = parameter i.e.=20
 
Diversion:=20 ...;reason=3D"user-busy";privacy=3D"full"
 
or,
 
Diversion:=20 ...;reason=3Duser-busy;privacy=3Dfull
 
Cheers,
Subhodeep
------_=_NextPart_001_01C7EA6F.625BDA17-- --===============0131904438== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0131904438==-- From sip-bounces@ietf.org Wed Aug 29 16:17:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQTx9-0000WO-R8; Wed, 29 Aug 2007 16:15:52 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IQTwN-0008RH-PT for sip-confirm+ok@megatron.ietf.org; Wed, 29 Aug 2007 16:15:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQTwN-0008R0-BL; Wed, 29 Aug 2007 16:15:03 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQTwM-0006ZD-5v; Wed, 29 Aug 2007 16:15:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 2662F328B6; Wed, 29 Aug 2007 20:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IQTwM-0004Bs-0O; Wed, 29 Aug 2007 16:15:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 29 Aug 2007 16:15:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-subnot-etags-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org --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 : An Extension to Session Initiation Protocol (SIP) Events for Conditional Event Notification Author(s) : A. Niemi Filename : draft-ietf-sip-subnot-etags-01.txt Pages : 25 Date : 2007-8-29 The Session Initiation Protocol (SIP) events framework enables receiving asynchronous notification of various events from other SIP user agents. This framework defines the procedures for creating, refreshing and terminating subscriptions, as well as fetching and periodic polling of resource state. These procedures have a serious deficiency in that they provide no tools to avoid replaying event notifications that have already been received by a user agent. This memo defines an extension to SIP events that allows the subscriber to condition the subscription request to whether the state has changed since the previous notification was received. When such a condition is true, either the body of a resulting event notification or the entire notification message is suppressed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-subnot-etags-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-subnot-etags-01.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-subnot-etags-01.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: <2007-8-29150450.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-subnot-etags-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-subnot-etags-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-8-29150450.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Thu Aug 30 01:08:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQcEK-0003YH-EB; Thu, 30 Aug 2007 01:06:08 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IQcEI-0003UR-Ue for sip-confirm+ok@megatron.ietf.org; Thu, 30 Aug 2007 01:06:06 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQcEI-0003TK-7q; Thu, 30 Aug 2007 01:06:06 -0400 Received: from antispam.nec-philips.com ([212.1.7.83]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQcEH-0001HE-84; Thu, 30 Aug 2007 01:06:06 -0400 X-AuditID: d4010752-ab6ecbb0000008b5-17-46d66b21b2fd Received: from NLMSEX4.np1.nec-philips.local (unknown [10.128.80.35]) by antispam.nec-philips.com (Symantec Mail Security) with ESMTP id D92E811DF; Thu, 30 Aug 2007 09:00:49 +0200 (CEST) Received: from NLMSEXCH01.NP1.NEC-Philips.local ([10.128.80.31]) by NLMSEX4.np1.nec-philips.local with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Aug 2007 07:06:03 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] RE: [Sipping] [Reg] Diversion Header Date: Thu, 30 Aug 2007 07:06:03 +0200 Message-ID: In-Reply-To: <750BBC72E178114F9DC4872EBFF29A5B04EDDA4D@ZMY16EXM66.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: [Sipping] [Reg] Diversion Header Thread-Index: AcfqbeqdLJEOLi4IQeeg5QcOeg0KRAAAVllAABT1thA= References: <70B22B83C930694D9639F7496C1786920DE9B9@KOL-SLK-MBX01.wipro.com> <750BBC72E178114F9DC4872EBFF29A5B04EDDA4D@ZMY16EXM66.ds.mot.com> From: "Derks, Frank" To: "Avasarala Ranjit-A20990" , , , X-OriginalArrivalTime: 30 Aug 2007 05:06:03.0468 (UTC) FILETIME=[76B898C0:01C7EAC3] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1756560671==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1756560671== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7EAC3.76CE6780" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7EAC3.76CE6780 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Ranjit, =20 Please be aware that the Diversion header never made it through the IETF standardisation process, which makes its use proprietary. Some manufacturers, among which Microsoft, use it however. The IETF-way of doing this would be to make use of the request history as per RFC4244. =20 Cheers, =20 Frabj ________________________________ From: Avasarala Ranjit-A20990 [mailto:ranjit@motorola.com]=20 Sent: 2007-Aug-29 21:04 To: subhodeep.sarkar@wipro.com; sip@ietf.org; sipping@ietf.org Subject: [Sip] RE: [Sipping] [Reg] Diversion Header Hi Subhodeep =20 The correct syntax would be: Diversion: ...;reason=3D"user-busy";privacy=3D"full" =20 Regards=20 Ranjit=20 =20 ________________________________ From: subhodeep.sarkar@wipro.com [mailto:subhodeep.sarkar@wipro.com]=20 Sent: Thursday, August 30, 2007 12:31 AM To: sip@ietf.org; sipping@ietf.org Subject: [Sipping] [Reg] Diversion Header Hi, =20 I need some clarification regarding the encoding syntax of SIP Diversion header parameters reason & privacy .=20 =20 I am aware that Diversion header is replaced by History-Info, but I need to support Diversion header for some network implementation.=20 =20 diversion-reason =3D "reason" "=3D" ( "unknown" | "user-busy" | "no-answer" | "unavailable" | "unconditional" | "time-of-day" | "do-not-disturb" | "deflection" | "follow-me" | "out-of-service" | "away" | token | quoted-string ) diversion-privacy =3D "privacy" "=3D" ( "full" | "name" | "uri" | "off" | token | quoted-string ) I like to know which is the correct syntax for the diversion-privacy & diversion-reason parameter i.e.=20 =20 Diversion: ...;reason=3D"user-busy";privacy=3D"full" =20 or, =20 Diversion: ...;reason=3Duser-busy;privacy=3Dfull =20 Cheers, Subhodeep ------_=_NextPart_001_01C7EAC3.76CE6780 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hi Ranjit,
 
Please be aware that the Diversion header never = made it=20 through the IETF standardisation process, which makes its=20 use proprietary. Some manufacturers, among which Microsoft, = use it=20 however. The IETF-way of doing this would be to make use of the request = history=20 as per RFC4244.
 
Cheers,
 
Frabj

From: Avasarala Ranjit-A20990=20 [mailto:ranjit@motorola.com]
Sent: 2007-Aug-29 = 21:04
To:=20 subhodeep.sarkar@wipro.com; sip@ietf.org; = sipping@ietf.org
Subject:=20 [Sip] RE: [Sipping] [Reg] Diversion Header

Hi Subhodeep
 
The correct syntax would be: Diversion:=20 ...;reason=3D"user-busy";privacy=3D"full"
=
 

Regards
Ranjit

 

From: subhodeep.sarkar@wipro.com=20 [mailto:subhodeep.sarkar@wipro.com]
Sent: Thursday, August = 30, 2007=20 12:31 AM
To: sip@ietf.org; sipping@ietf.org
Subject: = [Sipping] [Reg] Diversion Header

Hi,
 
I need some clarification = regarding the=20 encoding syntax of SIP Diversion header parameters reason & = privacy .=20
 
I am aware that Diversion = header is=20 replaced by History-Info, but I need to support Diversion header for = some=20 network implementation.
 
   =20 diversion-reason =3D "reason"=20 "=3D"
          &nbs= p;        =20 ( "unknown" | "user-busy" | "no-answer"=20 |
           &n= bsp;         =20 "unavailable" | "unconditional"=20 |
           &n= bsp;         =20 "time-of-day" | "do-not-disturb"=20 |
           &n= bsp;         =20 "deflection" | "follow-me"=20 |
           &n= bsp;         =20 "out-of-service" | "away"=20 |
           &n= bsp;         =20 token | quoted-string )
    diversion-privacy =3D "privacy" "=3D" ( = "full" | "name"=20 |
           &n= bsp;           =20 "uri" | "off" | token | quoted-string )
I like to = know which is the=20 correct syntax for the diversion-privacy & diversion-reason = parameter i.e.=20
 
Diversion:=20 ...;reason=3D"user-busy";privacy=3D"full"
 
or,
 
Diversion:=20 ...;reason=3Duser-busy;privacy=3Dfull
 
Cheers,
Subhodeep
------_=_NextPart_001_01C7EAC3.76CE6780-- --===============1756560671== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1756560671==-- From sip-bounces@ietf.org Thu Aug 30 01:17:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQcNO-0002zx-2U; Thu, 30 Aug 2007 01:15:30 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IQcNM-0002yZ-98 for sip-confirm+ok@megatron.ietf.org; Thu, 30 Aug 2007 01:15:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQcNL-0002ww-3T; Thu, 30 Aug 2007 01:15:27 -0400 Received: from harjus.tutpro.com ([192.98.100.3]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQcNK-0001Tg-Jg; Thu, 30 Aug 2007 01:15:26 -0400 Received: by harjus.tutpro.com (Postfix, from userid 1000) id 131A0AC328; Thu, 30 Aug 2007 08:15:25 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18134.21100.948307.418895@harjus.tutpro.com> Date: Thu, 30 Aug 2007 08:15:24 +0300 To: "Derks, Frank" Subject: RE: [Sip] RE: [Sipping] [Reg] Diversion Header In-Reply-To: References: <70B22B83C930694D9639F7496C1786920DE9B9@KOL-SLK-MBX01.wipro.com> <750BBC72E178114F9DC4872EBFF29A5B04EDDA4D@ZMY16EXM66.ds.mot.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: sip@ietf.org, sipping@ietf.org, subhodeep.sarkar@wipro.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Derks, Frank writes: > Please be aware that the Diversion header never made it through the IETF > standardisation process, which makes its use proprietary. Some > manufacturers, among which Microsoft, use it however. not only microsoft, but also cisco and many others. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Aug 30 02:09:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQdC8-0002Tb-2I; Thu, 30 Aug 2007 02:07:56 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IQdC5-0002R1-TI for sip-confirm+ok@megatron.ietf.org; Thu, 30 Aug 2007 02:07:53 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQdC5-0002Hi-Ds for sip@ietf.org; Thu, 30 Aug 2007 02:07:53 -0400 Received: from fw.polycom.co.il ([212.179.41.2] helo=isrexch01.israel.polycom.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQdC2-0002Xw-VW for sip@ietf.org; Thu, 30 Aug 2007 02:07:52 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: AW: [Sip] Extension of conference procedures Date: Thu, 30 Aug 2007 09:09:07 +0300 Message-ID: <144ED8561CE90C41A3E5908EDECE315C04DE7CFE@IsrExch01.israel.polycom.com> In-Reply-To: <317ceda50708290707o41400c0cnbde78f49c9ab18f6@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: [Sip] Extension of conference procedures Thread-Index: AcfqRhEX/Me4/dQsRM+wdqt5zk7CTAAhfFiA From: "Even, Roni" To: "Peili Xu" X-Spam-Score: 0.0 (/) X-Scan-Signature: dfc64cf6e4c6efdbf6b8f4c995df04df Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, I think you misunderstood what I menat by "smart". If there is a = softyswitch acting as a 3PCC, it controls the dialogs and can redirect = the media to the media server suppling the conference function. There is no need for A to give information about the dialog Roni Even > -----Original Message----- > From: Peili Xu [mailto:xupeili@gmail.com] > Sent: Wednesday, August 29, 2007 5:08 PM > To: Even, Roni > Cc: Huelsemann, Martin; sip@ietf.org > Subject: Re: AW: [Sip] Extension of conference procedures >=20 > Hi Martin, Denis, >=20 > I agree with Roni that you may need to decide who is "smart". >=20 > I guess you want to simulate the 3PTY services in PSTN, > A make call to B, > then A Hold B, > then A Make Call to C, > then A could do sth like hook flash to turn the call between A-B and > A-C to an 3pty conference. > later, A could still turn the conferece back to 2 independant call. >=20 > You have some assumption that the AS who performs conference > is on the path between A-B and A-C. And A could inform the AS to turn > the call between A-B and A-C to a conference. >=20 > If the assumption is correct, what you want is just to tell the AS > which dialogs should be turned to conference by sending an INVITE with > the related dialog information. >=20 > If the above understanding is correct, I'd agree with the initial > proposal from Denis. > Just to convey the dialog information along with the URI-List. >=20 > Peili >=20 >=20 >=20 > 2007/8/29, Even, Roni : > > > > Hi, > > In this case, like in PSTN the switch does it. You have to decide = who is > "smart" the network or the end device. > > A "simple" RFC 3261 only phone relies on a 3PCC or softswitch to = manage > telephony services (not only conferencing) > > > > Roni Even > > > > > -----Original Message----- > > > From: Huelsemann, Martin [mailto:Martin.Huelsemann@t-com.net] > > > Sent: Wednesday, August 29, 2007 1:05 PM > > > To: Even, Roni > > > Cc: sip@ietf.org; jbemmel@zonnet.nl > > > Subject: AW: AW: [Sip] Extension of conference procedures > > > > > > Hi, > > > > > > also for the scenario where A refers B to dial into a conference, = the > > > problem is when B has a terminal not supporting REFER (or just = doesn't > > > want to accept the REFER for some reasons), A cannot use the > conference > > > service. > > > > > > Of course these simple terminals are not the desired use-case and > there > > > will be limitations. But if there is a possible fallback solution = that > at > > > least increases the chance that A can use the service despite the = fact > > > that B does not fulfill all the requirements for the service, I = think > we > > > should try to figure it out. > > > > > > Regards, Martin > > > > > > > > > > > > > > > > > > > -----Urspr=FCngliche Nachricht----- > > > > Von: Even, Roni [mailto:roni.even@polycom.co.il] > > > > Gesendet: Montag, 27. August 2007 12:16 > > > > An: H=FClsemann, Martin; jbemmel@zonnet.nl > > > > Cc: sip@ietf.org > > > > Betreff: RE: AW: [Sip] Extension of conference procedures > > > > > > > > > > > > Hi, > > > > My view is that every solution where you only have A, B and a > > > > conference server and B only supports RFC 3261 will have some > > > > limitation and will be a hack. > > > > > > > > The recommended way to do it is for A to send a Refer to B to > > > > the focus. > > > > > > > > Also asking that B supporting only RFC 3261 will support > > > > conference event package is contradictory. B will not even be > > > > aware that it is in a conference. > > > > > > > > Roni Even > > > > > > > > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > > > > A consensus means that everyone agrees to say collectively > > > > what no one believes individually > > > > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > > > > > > > > > -----Original Message----- > > > > > From: Huelsemann, Martin [mailto:Martin.Huelsemann@t-com.net] > > > > > Sent: Monday, August 27, 2007 12:59 PM > > > > > To: jbemmel@zonnet.nl > > > > > Cc: sip@ietf.org > > > > > Subject: AW: AW: [Sip] Extension of conference procedures > > > > > > > > > > Hi, > > > > > > > > > > the pure RFC 3261 client won't be the normal case, of > > > > course. But there > > > > > might be networks with which you want to interwork where > > > > those simple > > > > > clients are existing. > > > > > Okay, you got me, it's again the PSTN interworking. So > > > > let's say what is > > > > > needed is a fallback solution for this case. > > > > > On the other hand, this fallback might be useful for a > > > > normal SIP client > > > > > which supports RFC3891, too, e.g. if there are problems with > > > > > authorization. > > > > > > > > > > The user experience of the invitee should be exactly as you > > > > describe. > > > > > > > > > > If A sends the reINVITE / UPDATE himself that could be a > > > > solution, too. > > > > > The only thing is, can B then use all the conference features = (e. > g. > > > > > conference event package), when the focus has no knowledge on = the > > > > > signalling level that B is connected to the conference bridge? > > > > > > > > > > Regards, Martin > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Urspr=FCngliche Nachricht----- > > > > > > Von: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > > > > > > Gesendet: Sonntag, 26. August 2007 15:24 > > > > > > An: H=FClsemann, Martin > > > > > > Cc: Alexeitsev, Denis; sip@ietf.org > > > > > > Betreff: Re: AW: [Sip] Extension of conference procedures > > > > > > > > > > > > > > > > > > Martin, > > > > > > > > > > > > Now it becomes more clear. So the requirement is to > > > > enable a scenario > > > > > > where a regular call is transformed into a conference > > > > call, assuming > > > > > > that the invitee only has a "pure RFC3261" client. > > > > > > More specifically: > > > > > > > > > > > > - to get a smooth user experience, the scenario must not = cause > the > > > > > > invitee's phone to ring, and/or ask the invitee for = permission > > > > > > (acceptance is assumed to be implied) > > > > > > > > > > > > What if A would send the reINVITE (or UPDATE) itself, while > > > > > > filling in > > > > > > the SDP according to the media provided by the conference > > > > > > server (i.e. > > > > > > use codecs, media ports as received from the focus)? (trying > > > > > > to get the > > > > > > requirements more clear here) > > > > > > > > > > > > In practice, it may still be a challenge to get such "very > simple > > > > > > terminals" to properly handle a change of media (i.e. new > > > > destination > > > > > > ip/port for sending, new source ip/port and RTP src id, > > > > and possibly > > > > > > different codecs) > > > > > > > > > > > > Regards, > > > > > > Jeroen > > > > > > > > > > > > > > > > > > Huelsemann, Martin wrote: > > > > > > > Hi Jeroen, > > > > > > > > > > > > > > the usage of the Replaces header is of course the best > > > > > > solution, it's also described in the regarding 3GPP > > > > > > conferencing spec. > > > > > > > The disadvantage of the usage of the Repaces header is, > > > > > > that it puts requirements on the UE of the invited user, it > > > > > > would have to support RFC 3891. And if it supports, it = really > > > > > > would have to accept the 2nd INVITE, which is not mandatory > > > > > > according to RFC 3891 I think. > > > > > > > Anyway what is needed in addition is a solution how also > > > > > > very simple terminals (e. g. only supporting RFC 3261) can = be > > > > > > invited to an ad-hoc conference, whithout having to say to > > > > > > the invited user to please hang up because there will be a > > > > > > call from the focus shortly. > > > > > > > > > > > > > > Re-using an already established dialog at least at the > > > > > > first glance seems to be a simply and invited UE independent > > > > > > solution. And as this re-INVITE it wanted by at least one of > > > > > > the involved user, I would more compare it to some kind of > > > > > > triggered 3rd party call control than to spoofing. > > > > > > > > > > > > > > Of course as you said it would have to be made clear that > > > > > > the focus is able to collect all the information needed for > > > > > > sending re-INVITEs (proposed "?" mechanism usage, dialog > > > > > > event package, etc.). > > > > > > > > > > > > > > > > > > > > > Regards, Martin > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> -----Urspr=FCngliche Nachricht----- > > > > > > >> Von: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > > > > > > >> Gesendet: Freitag, 24. August 2007 17:06 > > > > > > >> An: Alexeitsev, Denis; sip@ietf.org > > > > > > >> Betreff: Re: [Sip] Extension of conference procedures > > > > > > >> > > > > > > >> > > > > > > >> Denis, > > > > > > >> > > > > > > >> If I understand your scenario, "focus" is a third party > > > > > > >> separate from A and > > > > > > >> B, right? (e.g. a conference server) > > > > > > >> > > > > > > >> In that case the focus is not a party in the A-B dialog, = and > > > > > > >> would need more > > > > > > >> than Call-ID, From and To to be able to construct a = reINVITE > > > > > > >> that B would > > > > > > >> accept as coming from A (e.g. CSeq). In any case, this = looks > > > > > > >> like a very > > > > > > >> inelegant, hacked solution (as the conference server is > > > > > > >> basically spoofing) > > > > > > >> > > > > > > >> RFC4579 section 5.10 provides some insipration, as well = as > > > > > > >> http://www.ietf.org/internet-drafts/draft-ietf-sipping- > service > > > > > > >> -examples-13.txt > > > > > > >> scenario 2.5 > > > > > > >> > > > > > > >> For example, A could include a 'Replaces' header in the = URI > > > > > > >> it includes in > > > > > > >> its conference URI list. Then the conference server would > > > > > > send a new > > > > > > >> (out-of-dialog) INVITE to B containing this Replaces = header, > > > > > > >> and B would > > > > > > >> know that it is associated with the dialog it has with A = (and > > > > > > >> can replace > > > > > > >> it, without ringing if the UA is constructed like that) > > > > > > >> > > > > > > >> The conference server should probably also include a > > > > > > >> Referred-By containing > > > > > > >> A's AoR, either automatically (i.e. copy from From header = in > > > > > > >> INVITE) or > > > > > > >> included by A in the URI (former is better) > > > > > > >> > > > > > > >> Regards, > > > > > > >> Jeroen > > > > > > >> > > > > > > >> Alexeitsev, D wrote: > > > > > > >> > > > > > > >>> I'd like to discuss the extension of the current = conference > > > > > > >>> > > > > > > >> procedures > > > > > > >> > > > > > > >>> with the following functionality. > > > > > > >>> > > > > > > >>> 3GPP conference specifications are basing generally on = the > > > > > > >>> Conferencing Framework (RFC 4353) and for one = possibility > > > > > > >>> > > > > > > >> of inviting > > > > > > >> > > > > > > >>> users to the confrence on > > > > draft-ietf-sip-uri-list-conferencing. > > > > > > >>> > > > > > > >>> Using the conferencing framework, the following = situation > > > > > > can occur > > > > > > >>> when a user is invited to an ad-hoc conference: > > > > > > >>> User A is in a dialog with user B, and decides to start = a > > > > > > >>> > > > > > > >> conference, > > > > > > >> > > > > > > >>> for example using an INVITE request to the focus which > > > > > > >>> > > > > > > >> includes a URI > > > > > > >> > > > > > > >>> list with the URIs of the users which shall be added to = the > > > > > > >>> conference, incl. B. So when the INVITE request from the > focus > > > > > > >>> arrives at B, he is still in the original dialog with > > > > A, and so it > > > > > > >>> depends on B if he accepts the 2nd INVITE and the > > > > > > conference can be > > > > > > >>> established. > > > > > > >>> > > > > > > >>> At the last 3GPP CT1 meeting the idea of transporting = dialog > > > > > > >>> identifiers together with the URIs was introduced to > > > > solve this > > > > > > >>> problem. Basing on the idea that the procedures at > > > > the conference > > > > > > >>> server are extended in that way, that the conference > > > > > > server is aware > > > > > > >>> of already established dialogs, the focus then has the > > > > > > >>> > > > > > > >> possibility to > > > > > > >> > > > > > > >>> send re-INVITES in the indicated dialogs and connect the > > > > > > media from > > > > > > >>> the invited users to the conference bridge. > > > > > > >>> In the URI list the dialogs can be indicated using the > > > > > > "?" mechanism > > > > > > >>> according to subclause 19.1.1 of RFC 3261. > > > > > > >>> > > > > > > >>> Following example shows the proposed mechanism: > > > > > > >>> > > > > > > >>> INVITE Conference > > > > > > >>> To: Conference > > > > > > >>> From: A > > > > > > >>> Require: recipient-list-invite > > > > > > >>> > > > > > > >>> Content-Type: application/resource-lists+xml > > > > > > >>> Content-Disposition: recipient-list > > > > > > >>> > > > > > > >>> > > > > > > >>> lists" > > > > > > >>> xmlns:cp=3D"urn:ietf:params:xml:ns:copyControl"> > > > > > > >>> > > > > > > >>> > > > > > >>> cp:copyControl=3D"to"/> > > > > > > >>> > > > > > >>> cp:copyControl=3D"to"/> > > > > > > >>> > > > > > > >>> > > > > > > >>> > > > > > > >>> Greetings, > > > > > > >>> Denis Alexeitsev > > > > > > >>> > > > > > > >>> > > > > > > >>> _______________________________________________ > > > > > > >>> Sip mailing list = https://www1.ietf.org/mailman/listinfo/sip > > > > > > >>> This list is for NEW development of the core SIP = 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 sip-bounces@ietf.org Thu Aug 30 02:55:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQdui-0003Eb-0v; Thu, 30 Aug 2007 02:54:00 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IQduf-0003EV-JQ for sip-confirm+ok@megatron.ietf.org; Thu, 30 Aug 2007 02:53:57 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQduf-0003EN-4q for sip@ietf.org; Thu, 30 Aug 2007 02:53:57 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQdub-0004YF-OY for sip@ietf.org; Thu, 30 Aug 2007 02:53:57 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JNK00965R4NQR@szxga03-in.huawei.com> for sip@ietf.org; Thu, 30 Aug 2007 14:53:11 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JNK005NAR4KSA@szxga03-in.huawei.com> for sip@ietf.org; Thu, 30 Aug 2007 14:53:11 +0800 (CST) Received: from x18916 ([10.85.28.238]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JNK00MDRR4E89@szxml03-in.huawei.com> for sip@ietf.org; Thu, 30 Aug 2007 14:53:08 +0800 (CST) Date: Thu, 30 Aug 2007 14:53:02 +0800 From: Peili Xu Subject: RE: AW: [Sip] Extension of conference procedures In-reply-to: <144ED8561CE90C41A3E5908EDECE315C04DE7CFE@IsrExch01.israel.polycom.com> To: "'Even, Roni'" Message-id: <02b001c7ead2$68bb5e10$ee1c550a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Thread-index: AcfqRhEX/Me4/dQsRM+wdqt5zk7CTAAhfFiAAAFj5gA= X-Spam-Score: 0.0 (/) X-Scan-Signature: c021adebe99b05433d94f84a85f41df2 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Roni, Your case is even "smarter" than mine ;-) that's OK for me. But, I'm just wondering whether there is case that A has multiple on going dialogs with say B, C, D and only want to turn A-B and A-C to a conference then dialog information maybe needed. =20 I'd happy to hear clarification for this point from whom raise the requirements. Peili -----Original Message----- From: Even, Roni [mailto:roni.even@polycom.co.il]=20 Sent: Thursday, August 30, 2007 2:09 PM To: Peili Xu Cc: sip@ietf.org Subject: RE: AW: [Sip] Extension of conference procedures Hi, I think you misunderstood what I menat by "smart". If there is a softyswitch acting as a 3PCC, it controls the dialogs and can redirect the media to the media server suppling the conference function. There is no need for A to give information about the dialog Roni Even > -----Original Message----- > From: Peili Xu [mailto:xupeili@gmail.com] > Sent: Wednesday, August 29, 2007 5:08 PM > To: Even, Roni > Cc: Huelsemann, Martin; sip@ietf.org > Subject: Re: AW: [Sip] Extension of conference procedures >=20 > Hi Martin, Denis, >=20 > I agree with Roni that you may need to decide who is "smart". >=20 > I guess you want to simulate the 3PTY services in PSTN, A make call to=20 > B, then A Hold B, then A Make Call to C, then A could do sth like hook=20 > flash to turn the call between A-B and A-C to an 3pty conference. > later, A could still turn the conferece back to 2 independant call. >=20 > You have some assumption that the AS who performs conference is on the=20 > path between A-B and A-C. And A could inform the AS to turn the call=20 > between A-B and A-C to a conference. >=20 > If the assumption is correct, what you want is just to tell the AS=20 > which dialogs should be turned to conference by sending an INVITE with=20 > the related dialog information. >=20 > If the above understanding is correct, I'd agree with the initial=20 > proposal from Denis. > Just to convey the dialog information along with the URI-List. >=20 > Peili >=20 >=20 >=20 > 2007/8/29, Even, Roni : > > > > Hi, > > In this case, like in PSTN the switch does it. You have to decide=20 > > who is > "smart" the network or the end device. > > A "simple" RFC 3261 only phone relies on a 3PCC or softswitch to=20 > > manage > telephony services (not only conferencing) > > > > Roni Even > > > > > -----Original Message----- > > > From: Huelsemann, Martin [mailto:Martin.Huelsemann@t-com.net] > > > Sent: Wednesday, August 29, 2007 1:05 PM > > > To: Even, Roni > > > Cc: sip@ietf.org; jbemmel@zonnet.nl > > > Subject: AW: AW: [Sip] Extension of conference procedures > > > > > > Hi, > > > > > > also for the scenario where A refers B to dial into a conference,=20 > > > the problem is when B has a terminal not supporting REFER (or just=20 > > > doesn't want to accept the REFER for some reasons), A cannot use=20 > > > the > conference > > > service. > > > > > > Of course these simple terminals are not the desired use-case and > there > > > will be limitations. But if there is a possible fallback solution=20 > > > that > at > > > least increases the chance that A can use the service despite the=20 > > > fact that B does not fulfill all the requirements for the service,=20 > > > I think > we > > > should try to figure it out. > > > > > > Regards, Martin > > > > > > > > > > > > > > > > > > > -----Urspr=FCngliche Nachricht----- > > > > Von: Even, Roni [mailto:roni.even@polycom.co.il] > > > > Gesendet: Montag, 27. August 2007 12:16 > > > > An: H=FClsemann, Martin; jbemmel@zonnet.nl > > > > Cc: sip@ietf.org > > > > Betreff: RE: AW: [Sip] Extension of conference procedures > > > > > > > > > > > > Hi, > > > > My view is that every solution where you only have A, B and a=20 > > > > conference server and B only supports RFC 3261 will have some=20 > > > > limitation and will be a hack. > > > > > > > > The recommended way to do it is for A to send a Refer to B to=20 > > > > the focus. > > > > > > > > Also asking that B supporting only RFC 3261 will support=20 > > > > conference event package is contradictory. B will not even be=20 > > > > aware that it is in a conference. > > > > > > > > Roni Even > > > > > > > > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > > > > A consensus means that everyone agrees to say collectively what=20 > > > > no one believes individually !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > > > > > > > > > -----Original Message----- > > > > > From: Huelsemann, Martin [mailto:Martin.Huelsemann@t-com.net] > > > > > Sent: Monday, August 27, 2007 12:59 PM > > > > > To: jbemmel@zonnet.nl > > > > > Cc: sip@ietf.org > > > > > Subject: AW: AW: [Sip] Extension of conference procedures > > > > > > > > > > Hi, > > > > > > > > > > the pure RFC 3261 client won't be the normal case, of > > > > course. But there > > > > > might be networks with which you want to interwork where > > > > those simple > > > > > clients are existing. > > > > > Okay, you got me, it's again the PSTN interworking. So > > > > let's say what is > > > > > needed is a fallback solution for this case. > > > > > On the other hand, this fallback might be useful for a > > > > normal SIP client > > > > > which supports RFC3891, too, e.g. if there are problems with=20 > > > > > authorization. > > > > > > > > > > The user experience of the invitee should be exactly as you > > > > describe. > > > > > > > > > > If A sends the reINVITE / UPDATE himself that could be a > > > > solution, too. > > > > > The only thing is, can B then use all the conference features (e. > g. > > > > > conference event package), when the focus has no knowledge on=20 > > > > > the signalling level that B is connected to the conference bridge? > > > > > > > > > > Regards, Martin > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Urspr=FCngliche Nachricht----- > > > > > > Von: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > > > > > > Gesendet: Sonntag, 26. August 2007 15:24 > > > > > > An: H=FClsemann, Martin > > > > > > Cc: Alexeitsev, Denis; sip@ietf.org > > > > > > Betreff: Re: AW: [Sip] Extension of conference procedures > > > > > > > > > > > > > > > > > > Martin, > > > > > > > > > > > > Now it becomes more clear. So the requirement is to > > > > enable a scenario > > > > > > where a regular call is transformed into a conference > > > > call, assuming > > > > > > that the invitee only has a "pure RFC3261" client. > > > > > > More specifically: > > > > > > > > > > > > - to get a smooth user experience, the scenario must not=20 > > > > > > cause > the > > > > > > invitee's phone to ring, and/or ask the invitee for=20 > > > > > > permission (acceptance is assumed to be implied) > > > > > > > > > > > > What if A would send the reINVITE (or UPDATE) itself, while=20 > > > > > > filling in the SDP according to the media provided by the=20 > > > > > > conference server (i.e. > > > > > > use codecs, media ports as received from the focus)? (trying=20 > > > > > > to get the requirements more clear here) > > > > > > > > > > > > In practice, it may still be a challenge to get such "very > simple > > > > > > terminals" to properly handle a change of media (i.e. new > > > > destination > > > > > > ip/port for sending, new source ip/port and RTP src id, > > > > and possibly > > > > > > different codecs) > > > > > > > > > > > > Regards, > > > > > > Jeroen > > > > > > > > > > > > > > > > > > Huelsemann, Martin wrote: > > > > > > > Hi Jeroen, > > > > > > > > > > > > > > the usage of the Replaces header is of course the best > > > > > > solution, it's also described in the regarding 3GPP=20 > > > > > > conferencing spec. > > > > > > > The disadvantage of the usage of the Repaces header is, > > > > > > that it puts requirements on the UE of the invited user, it=20 > > > > > > would have to support RFC 3891. And if it supports, it=20 > > > > > > really would have to accept the 2nd INVITE, which is not=20 > > > > > > mandatory according to RFC 3891 I think. > > > > > > > Anyway what is needed in addition is a solution how also > > > > > > very simple terminals (e. g. only supporting RFC 3261) can=20 > > > > > > be invited to an ad-hoc conference, whithout having to say=20 > > > > > > to the invited user to please hang up because there will be=20 > > > > > > a call from the focus shortly. > > > > > > > > > > > > > > Re-using an already established dialog at least at the > > > > > > first glance seems to be a simply and invited UE independent=20 > > > > > > solution. And as this re-INVITE it wanted by at least one of=20 > > > > > > the involved user, I would more compare it to some kind of=20 > > > > > > triggered 3rd party call control than to spoofing. > > > > > > > > > > > > > > Of course as you said it would have to be made clear that > > > > > > the focus is able to collect all the information needed for=20 > > > > > > sending re-INVITEs (proposed "?" mechanism usage, dialog=20 > > > > > > event package, etc.). > > > > > > > > > > > > > > > > > > > > > Regards, Martin > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> -----Urspr=FCngliche Nachricht----- > > > > > > >> Von: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > > > > > > >> Gesendet: Freitag, 24. August 2007 17:06 > > > > > > >> An: Alexeitsev, Denis; sip@ietf.org > > > > > > >> Betreff: Re: [Sip] Extension of conference procedures > > > > > > >> > > > > > > >> > > > > > > >> Denis, > > > > > > >> > > > > > > >> If I understand your scenario, "focus" is a third party=20 > > > > > > >> separate from A and B, right? (e.g. a conference server) > > > > > > >> > > > > > > >> In that case the focus is not a party in the A-B dialog,=20 > > > > > > >> and would need more than Call-ID, From and To to be able=20 > > > > > > >> to construct a reINVITE that B would accept as coming=20 > > > > > > >> from A (e.g. CSeq). In any case, this looks like a very=20 > > > > > > >> inelegant, hacked solution (as the conference server is=20 > > > > > > >> basically spoofing) > > > > > > >> > > > > > > >> RFC4579 section 5.10 provides some insipration, as well=20 > > > > > > >> as > > > > > > >> http://www.ietf.org/internet-drafts/draft-ietf-sipping- > service > > > > > > >> -examples-13.txt > > > > > > >> scenario 2.5 > > > > > > >> > > > > > > >> For example, A could include a 'Replaces' header in the=20 > > > > > > >> URI it includes in its conference URI list. Then the=20 > > > > > > >> conference server would > > > > > > send a new > > > > > > >> (out-of-dialog) INVITE to B containing this Replaces=20 > > > > > > >> header, and B would know that it is associated with the=20 > > > > > > >> dialog it has with A (and can replace it, without ringing=20 > > > > > > >> if the UA is constructed like that) > > > > > > >> > > > > > > >> The conference server should probably also include a=20 > > > > > > >> Referred-By containing A's AoR, either automatically=20 > > > > > > >> (i.e. copy from From header in > > > > > > >> INVITE) or > > > > > > >> included by A in the URI (former is better) > > > > > > >> > > > > > > >> Regards, > > > > > > >> Jeroen > > > > > > >> > > > > > > >> Alexeitsev, D wrote: > > > > > > >> > > > > > > >>> I'd like to discuss the extension of the current=20 > > > > > > >>> conference > > > > > > >>> > > > > > > >> procedures > > > > > > >> > > > > > > >>> with the following functionality. > > > > > > >>> > > > > > > >>> 3GPP conference specifications are basing generally on=20 > > > > > > >>> the Conferencing Framework (RFC 4353) and for one=20 > > > > > > >>> possibility > > > > > > >>> > > > > > > >> of inviting > > > > > > >> > > > > > > >>> users to the confrence on > > > > draft-ietf-sip-uri-list-conferencing. > > > > > > >>> > > > > > > >>> Using the conferencing framework, the following=20 > > > > > > >>> situation > > > > > > can occur > > > > > > >>> when a user is invited to an ad-hoc conference: > > > > > > >>> User A is in a dialog with user B, and decides to start=20 > > > > > > >>> a > > > > > > >>> > > > > > > >> conference, > > > > > > >> > > > > > > >>> for example using an INVITE request to the focus which > > > > > > >>> > > > > > > >> includes a URI > > > > > > >> > > > > > > >>> list with the URIs of the users which shall be added to=20 > > > > > > >>> the conference, incl. B. So when the INVITE request from=20 > > > > > > >>> the > focus > > > > > > >>> arrives at B, he is still in the original dialog with > > > > A, and so it > > > > > > >>> depends on B if he accepts the 2nd INVITE and the > > > > > > conference can be > > > > > > >>> established. > > > > > > >>> > > > > > > >>> At the last 3GPP CT1 meeting the idea of transporting=20 > > > > > > >>> dialog identifiers together with the URIs was introduced=20 > > > > > > >>> to > > > > solve this > > > > > > >>> problem. Basing on the idea that the procedures at > > > > the conference > > > > > > >>> server are extended in that way, that the conference > > > > > > server is aware > > > > > > >>> of already established dialogs, the focus then has the > > > > > > >>> > > > > > > >> possibility to > > > > > > >> > > > > > > >>> send re-INVITES in the indicated dialogs and connect the > > > > > > media from > > > > > > >>> the invited users to the conference bridge. > > > > > > >>> In the URI list the dialogs can be indicated using the > > > > > > "?" mechanism > > > > > > >>> according to subclause 19.1.1 of RFC 3261. > > > > > > >>> > > > > > > >>> Following example shows the proposed mechanism: > > > > > > >>> > > > > > > >>> INVITE Conference > > > > > > >>> To: Conference > > > > > > >>> From: A > > > > > > >>> Require: recipient-list-invite > > > > > > >>> > > > > > > >>> Content-Type: application/resource-lists+xml > > > > > > >>> Content-Disposition: recipient-list > > > > > > >>> > > > > > > >>> > > > > > >>> xmlns=3D"urn:ietf:params:xml:ns:resource- > lists" > > > > > > >>> xmlns:cp=3D"urn:ietf:params:xml:ns:copyControl"> > > > > > > >>> > > > > > > >>> > > > > > >>> cp:copyControl=3D"to"/> > > > > > > >>> > > > > > >>> cp:copyControl=3D"to"/> > > > > > > >>> > > > > > > >>> > > > > > > >>> > > > > > > >>> Greetings, > > > > > > >>> Denis Alexeitsev > > > > > > >>> > > > > > > >>> > > > > > > >>> _______________________________________________ > > > > > > >>> Sip mailing list =20 > > > > > > >>> https://www1.ietf.org/mailman/listinfo/sip > > > > > > >>> 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 > > > > > > application of sip > > > > > > >>> > > > > > > >> > > > > > > >> _______________________________________________ > > > > > > >> Sip mailing list =20 > > > > > > >> https://www1.ietf.org/mailman/listinfo/sip > > > > > > >> This list is for NEW development of the core SIP Protocol=20 > > > > > > >> Use sip-implementors@cs.columbia.edu for questions on > > > > current sip > > > > > > >> Use sipping@ietf.org for new developments on the > > > > application of sip > > > > > > >> > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > > This list is for NEW development of the core SIP Protocol Use=20 > > > > > sip-implementors@cs.columbia.edu for questions on current sip=20 > > > > > Use sipping@ietf.org for new developments on the application=20 > > > > > of > sip > > > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Aug 30 03:28:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQeQN-0007vN-Ka; Thu, 30 Aug 2007 03:26:43 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IQeQM-0007vE-FO for sip-confirm+ok@megatron.ietf.org; Thu, 30 Aug 2007 03:26:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQeQM-0007v0-0j for sip@ietf.org; Thu, 30 Aug 2007 03:26:42 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQeQJ-0001ZW-Uj for sip@ietf.org; Thu, 30 Aug 2007 03:26:41 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l7U7QKRf026749; Thu, 30 Aug 2007 10:26:36 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Aug 2007 10:26:27 +0300 Received: from esebe106.NOE.Nokia.com ([172.21.143.51]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Aug 2007 10:26:27 +0300 Received: from [172.21.41.131] ([172.21.41.131]) by esebe106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Aug 2007 10:26:27 +0300 Message-ID: <46D67121.4030409@nokia.com> Date: Thu, 30 Aug 2007 10:26:25 +0300 From: Aki Niemi Organization: Nokia User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: ext Robert Sparks Subject: Re: [Sip] Subnot-etags: refactoring References: <46D27F1E.8090107@nokia.com> In-Reply-To: X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Aug 2007 07:26:27.0185 (UTC) FILETIME=[13A5CE10:01C7EAD7] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org ext Robert Sparks wrote: > I'm still pretty uncomfortable with suppressing the entire NOTIFY for > a refresh subscription. There are mechanics that involve the > Subscription-State > header and its possible extension that I fear we will interact with in > unexpected ways. The way this works now is that we are explicit on what is considered the "entity" and what is not. In the current version of the draft, we explicitly say that the "entity" is the event data in the body plus Content-* and Entity fields in the header. On the other hand, subscription state is *not* part of the entity, and therefore not covered by the entity-tag. This then gives the notifier three choices when it gets a SUBSCRIBE requesting for conditional notification. It will either: 1) report nothing (204 response) if neither entity nor subscription state have changed; 2) suppress the body if only the subscription state has changed; 3) send a full notify if the entity has changed So I think this solves your concern, since the notifier can always report the changes, even in the subscription refresh. Before, this was actually quite poorly defined. > I will admit that all the specific instances of that I can think of > right now you can work > around by being really careful with the success response to the > reSUBSCRIBE. Can > anybody come up with a case (or imagine an extension) where the response > to the > reSUBSCRIBE won't have the right stuff? I believe currently there are none. However, if in the future there are extensions that should be considered to be part of the "entity" or subscription state, then those event-packages would need to define this behavior. In practice, they would need to cover cases where changes in these additional header fields would trigger a NOTIFY without the body, or a NOTIFY with a body and a changed entity-tag. 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 sip-bounces@ietf.org Thu Aug 30 04:39:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQfWv-0005tO-HH; Thu, 30 Aug 2007 04:37:33 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IQfWt-0005tJ-SK for sip-confirm+ok@megatron.ietf.org; Thu, 30 Aug 2007 04:37:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQfWt-0005tB-BF for sip@ietf.org; Thu, 30 Aug 2007 04:37:31 -0400 Received: from tcmail23.telekom.de ([217.6.95.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQfWr-0003PP-JK for sip@ietf.org; Thu, 30 Aug 2007 04:37:31 -0400 Received: from S4DE9JSAANO.ost.t-com.de (S4DE9JSAANO.ost.t-com.de [10.125.177.105]) by tcmail21.telekom.de with ESMTP; Thu, 30 Aug 2007 10:37:28 +0200 Received: from S4DE9JSAAHW.ost.t-com.de ([10.125.177.160]) by S4DE9JSAANO.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Aug 2007 10:37:27 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: AW: AW: [Sip] Extension of conference procedures Date: Thu, 30 Aug 2007 10:37:26 +0200 Message-Id: In-reply-to: <02b001c7ead2$68bb5e10$ee1c550a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: [Sip] Extension of conference procedures Thread-Index: AcfqRhEX/Me4/dQsRM+wdqt5zk7CTAAhfFiAAAFj5gAAAntFIA== From: "Huelsemann, Martin" To: , X-OriginalArrivalTime: 30 Aug 2007 08:37:27.0354 (UTC) FILETIME=[FEE801A0:01C7EAE0] X-Spam-Score: -1.0 (-) X-Scan-Signature: 3b3673afe71d94a7551c8fbc5adb8948 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, I think especially for the case where A has several ongoing dialogs with = B and A wants only to include a certain of the dialogs into the = conference, he has to give some information in which of the dialogs the = AS shall start 3pcc procedures. Regards, Martin > -----Urspr=FCngliche Nachricht----- > Von: Peili Xu [mailto:xupeili@huawei.com]=20 > Gesendet: Donnerstag, 30. August 2007 08:53 > An: 'Even, Roni' > Cc: sip@ietf.org > Betreff: RE: AW: [Sip] Extension of conference procedures >=20 >=20 >=20 > Hi Roni, >=20 > Your case is even "smarter" than mine ;-) that's OK for > me. >=20 > But, I'm just wondering whether there is case that A has > multiple on going dialogs with say B, C, D and only want > to turn A-B and A-C to a conference then dialog > information maybe needed. =20 >=20 > I'd happy to hear clarification for this point from whom > raise the requirements. >=20 > Peili >=20 > -----Original Message----- > From: Even, Roni [mailto:roni.even@polycom.co.il]=20 > Sent: Thursday, August 30, 2007 2:09 PM > To: Peili Xu > Cc: sip@ietf.org > Subject: RE: AW: [Sip] Extension of conference > procedures >=20 >=20 >=20 > Hi, > I think you misunderstood what I menat by "smart". If > there is a softyswitch acting as a 3PCC, it controls the > dialogs and can redirect the media to the media server > suppling the conference function. > There is no need for A to give information about the > dialog >=20 > Roni Even >=20 > > -----Original Message----- > > From: Peili Xu [mailto:xupeili@gmail.com] > > Sent: Wednesday, August 29, 2007 5:08 PM > > To: Even, Roni > > Cc: Huelsemann, Martin; sip@ietf.org > > Subject: Re: AW: [Sip] Extension of conference > procedures > >=20 > > Hi Martin, Denis, > >=20 > > I agree with Roni that you may need to decide who is > "smart". > >=20 > > I guess you want to simulate the 3PTY services in > PSTN, A make call to=20 > > B, then A Hold B, then A Make Call to C, then A could > do sth like hook=20 > > flash to turn the call between A-B and A-C to an 3pty > conference. > > later, A could still turn the conferece back to 2 > independant call. > >=20 > > You have some assumption that the AS who performs > conference is on the=20 > > path between A-B and A-C. And A could inform the AS to > turn the call=20 > > between A-B and A-C to a conference. > >=20 > > If the assumption is correct, what you want is just to > tell the AS=20 > > which dialogs should be turned to conference by > sending an INVITE with=20 > > the related dialog information. > >=20 > > If the above understanding is correct, I'd agree with > the initial=20 > > proposal from Denis. > > Just to convey the dialog information along with the > URI-List. > >=20 > > Peili > >=20 > >=20 > >=20 > > 2007/8/29, Even, Roni : > > > > > > Hi, > > > In this case, like in PSTN the switch does it. You > have to decide=20 > > > who is > > "smart" the network or the end device. > > > A "simple" RFC 3261 only phone relies on a 3PCC or > softswitch to=20 > > > manage > > telephony services (not only conferencing) > > > > > > Roni Even > > > > > > > -----Original Message----- > > > > From: Huelsemann, Martin > [mailto:Martin.Huelsemann@t-com.net] > > > > Sent: Wednesday, August 29, 2007 1:05 PM > > > > To: Even, Roni > > > > Cc: sip@ietf.org; jbemmel@zonnet.nl > > > > Subject: AW: AW: [Sip] Extension of conference > procedures > > > > > > > > Hi, > > > > > > > > also for the scenario where A refers B to dial > into a conference,=20 > > > > the problem is when B has a terminal not > supporting REFER (or just=20 > > > > doesn't want to accept the REFER for some > reasons), A cannot use=20 > > > > the > > conference > > > > service. > > > > > > > > Of course these simple terminals are not the > desired use-case and > > there > > > > will be limitations. But if there is a possible > fallback solution=20 > > > > that > > at > > > > least increases the chance that A can use the > service despite the=20 > > > > fact that B does not fulfill all the requirements > for the service,=20 > > > > I think > > we > > > > should try to figure it out. > > > > > > > > Regards, Martin > > > > > > > > > > > > > > > > > > > > > > > > > -----Urspr=FCngliche Nachricht----- > > > > > Von: Even, Roni [mailto:roni.even@polycom.co.il] > > > > > Gesendet: Montag, 27. August 2007 12:16 > > > > > An: H=FClsemann, Martin; jbemmel@zonnet.nl > > > > > Cc: sip@ietf.org > > > > > Betreff: RE: AW: [Sip] Extension of conference > procedures > > > > > > > > > > > > > > > Hi, > > > > > My view is that every solution where you only > have A, B and a=20 > > > > > conference server and B only supports RFC 3261 > will have some=20 > > > > > limitation and will be a hack. > > > > > > > > > > The recommended way to do it is for A to send a > Refer to B to=20 > > > > > the focus. > > > > > > > > > > Also asking that B supporting only RFC 3261 will > support=20 > > > > > conference event package is contradictory. B > will not even be=20 > > > > > aware that it is in a conference. > > > > > > > > > > Roni Even > > > > > > > > > > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > > > > > A consensus means that everyone agrees to say > collectively what=20 > > > > > no one believes individually > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > > > > > > > > > > > -----Original Message----- > > > > > > From: Huelsemann, Martin > [mailto:Martin.Huelsemann@t-com.net] > > > > > > Sent: Monday, August 27, 2007 12:59 PM > > > > > > To: jbemmel@zonnet.nl > > > > > > Cc: sip@ietf.org > > > > > > Subject: AW: AW: [Sip] Extension of conference > procedures > > > > > > > > > > > > Hi, > > > > > > > > > > > > the pure RFC 3261 client won't be the normal > case, of > > > > > course. But there > > > > > > might be networks with which you want to > interwork where > > > > > those simple > > > > > > clients are existing. > > > > > > Okay, you got me, it's again the PSTN > interworking. So > > > > > let's say what is > > > > > > needed is a fallback solution for this case. > > > > > > On the other hand, this fallback might be > useful for a > > > > > normal SIP client > > > > > > which supports RFC3891, too, e.g. if there are > problems with=20 > > > > > > authorization. > > > > > > > > > > > > The user experience of the invitee should be > exactly as you > > > > > describe. > > > > > > > > > > > > If A sends the reINVITE / UPDATE himself that > could be a > > > > > solution, too. > > > > > > The only thing is, can B then use all the > conference features (e. > > g. > > > > > > conference event package), when the focus has > no knowledge on=20 > > > > > > the signalling level that B is connected to > the conference bridge? > > > > > > > > > > > > Regards, Martin > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Urspr=FCngliche Nachricht----- > > > > > > > Von: Jeroen van Bemmel > [mailto:jbemmel@zonnet.nl] > > > > > > > Gesendet: Sonntag, 26. August 2007 15:24 > > > > > > > An: H=FClsemann, Martin > > > > > > > Cc: Alexeitsev, Denis; sip@ietf.org > > > > > > > Betreff: Re: AW: [Sip] Extension of > conference procedures > > > > > > > > > > > > > > > > > > > > > Martin, > > > > > > > > > > > > > > Now it becomes more clear. So the > requirement is to > > > > > enable a scenario > > > > > > > where a regular call is transformed into a > conference > > > > > call, assuming > > > > > > > that the invitee only has a "pure RFC3261" > client. > > > > > > > More specifically: > > > > > > > > > > > > > > - to get a smooth user experience, the > scenario must not=20 > > > > > > > cause > > the > > > > > > > invitee's phone to ring, and/or ask the > invitee for=20 > > > > > > > permission (acceptance is assumed to be > implied) > > > > > > > > > > > > > > What if A would send the reINVITE (or > UPDATE) itself, while=20 > > > > > > > filling in the SDP according to the media > provided by the=20 > > > > > > > conference server (i.e. > > > > > > > use codecs, media ports as received from the > focus)? (trying=20 > > > > > > > to get the requirements more clear here) > > > > > > > > > > > > > > In practice, it may still be a challenge to > get such "very > > simple > > > > > > > terminals" to properly handle a change of > media (i.e. new > > > > > destination > > > > > > > ip/port for sending, new source ip/port and > RTP src id, > > > > > and possibly > > > > > > > different codecs) > > > > > > > > > > > > > > Regards, > > > > > > > Jeroen > > > > > > > > > > > > > > > > > > > > > Huelsemann, Martin wrote: > > > > > > > > Hi Jeroen, > > > > > > > > > > > > > > > > the usage of the Replaces header is of > course the best > > > > > > > solution, it's also described in the > regarding 3GPP=20 > > > > > > > conferencing spec. > > > > > > > > The disadvantage of the usage of the > Repaces header is, > > > > > > > that it puts requirements on the UE of the > invited user, it=20 > > > > > > > would have to support RFC 3891. And if it > supports, it=20 > > > > > > > really would have to accept the 2nd INVITE, > which is not=20 > > > > > > > mandatory according to RFC 3891 I think. > > > > > > > > Anyway what is needed in addition is a > solution how also > > > > > > > very simple terminals (e. g. only supporting > RFC 3261) can=20 > > > > > > > be invited to an ad-hoc conference, whithout > having to say=20 > > > > > > > to the invited user to please hang up > because there will be=20 > > > > > > > a call from the focus shortly. > > > > > > > > > > > > > > > > Re-using an already established dialog at > least at the > > > > > > > first glance seems to be a simply and > invited UE independent=20 > > > > > > > solution. And as this re-INVITE it wanted by > at least one of=20 > > > > > > > the involved user, I would more compare it > to some kind of=20 > > > > > > > triggered 3rd party call control than to > spoofing. > > > > > > > > > > > > > > > > Of course as you said it would have to be > made clear that > > > > > > > the focus is able to collect all the > information needed for=20 > > > > > > > sending re-INVITEs (proposed "?" mechanism > usage, dialog=20 > > > > > > > event package, etc.). > > > > > > > > > > > > > > > > > > > > > > > > Regards, Martin > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> -----Urspr=FCngliche Nachricht----- > > > > > > > >> Von: Jeroen van Bemmel > [mailto:jbemmel@zonnet.nl] > > > > > > > >> Gesendet: Freitag, 24. August 2007 17:06 > > > > > > > >> An: Alexeitsev, Denis; sip@ietf.org > > > > > > > >> Betreff: Re: [Sip] Extension of > conference procedures > > > > > > > >> > > > > > > > >> > > > > > > > >> Denis, > > > > > > > >> > > > > > > > >> If I understand your scenario, "focus" is > a third party=20 > > > > > > > >> separate from A and B, right? (e.g. a > conference server) > > > > > > > >> > > > > > > > >> In that case the focus is not a party in > the A-B dialog,=20 > > > > > > > >> and would need more than Call-ID, From > and To to be able=20 > > > > > > > >> to construct a reINVITE that B would > accept as coming=20 > > > > > > > >> from A (e.g. CSeq). In any case, this > looks like a very=20 > > > > > > > >> inelegant, hacked solution (as the > conference server is=20 > > > > > > > >> basically spoofing) > > > > > > > >> > > > > > > > >> RFC4579 section 5.10 provides some > insipration, as well=20 > > > > > > > >> as > > > > > > > >> > http://www.ietf.org/internet-drafts/draft-ietf-sipping- > > service > > > > > > > >> -examples-13.txt > > > > > > > >> scenario 2.5 > > > > > > > >> > > > > > > > >> For example, A could include a 'Replaces' > header in the=20 > > > > > > > >> URI it includes in its conference URI > list. Then the=20 > > > > > > > >> conference server would > > > > > > > send a new > > > > > > > >> (out-of-dialog) INVITE to B containing > this Replaces=20 > > > > > > > >> header, and B would know that it is > associated with the=20 > > > > > > > >> dialog it has with A (and can replace it, > without ringing=20 > > > > > > > >> if the UA is constructed like that) > > > > > > > >> > > > > > > > >> The conference server should probably > also include a=20 > > > > > > > >> Referred-By containing A's AoR, either > automatically=20 > > > > > > > >> (i.e. copy from From header in > > > > > > > >> INVITE) or > > > > > > > >> included by A in the URI (former is > better) > > > > > > > >> > > > > > > > >> Regards, > > > > > > > >> Jeroen > > > > > > > >> > > > > > > > >> Alexeitsev, D wrote: > > > > > > > >> > > > > > > > >>> I'd like to discuss the extension of the > current=20 > > > > > > > >>> conference > > > > > > > >>> > > > > > > > >> procedures > > > > > > > >> > > > > > > > >>> with the following functionality. > > > > > > > >>> > > > > > > > >>> 3GPP conference specifications are > basing generally on=20 > > > > > > > >>> the Conferencing Framework (RFC 4353) > and for one=20 > > > > > > > >>> possibility > > > > > > > >>> > > > > > > > >> of inviting > > > > > > > >> > > > > > > > >>> users to the confrence on > > > > > draft-ietf-sip-uri-list-conferencing. > > > > > > > >>> > > > > > > > >>> Using the conferencing framework, the > following=20 > > > > > > > >>> situation > > > > > > > can occur > > > > > > > >>> when a user is invited to an ad-hoc > conference: > > > > > > > >>> User A is in a dialog with user B, and > decides to start=20 > > > > > > > >>> a > > > > > > > >>> > > > > > > > >> conference, > > > > > > > >> > > > > > > > >>> for example using an INVITE request to > the focus which > > > > > > > >>> > > > > > > > >> includes a URI > > > > > > > >> > > > > > > > >>> list with the URIs of the users which > shall be added to=20 > > > > > > > >>> the conference, incl. B. So when the > INVITE request from=20 > > > > > > > >>> the > > focus > > > > > > > >>> arrives at B, he is still in the > original dialog with > > > > > A, and so it > > > > > > > >>> depends on B if he accepts the 2nd > INVITE and the > > > > > > > conference can be > > > > > > > >>> established. > > > > > > > >>> > > > > > > > >>> At the last 3GPP CT1 meeting the idea of > transporting=20 > > > > > > > >>> dialog identifiers together with the > URIs was introduced=20 > > > > > > > >>> to > > > > > solve this > > > > > > > >>> problem. Basing on the idea that the > procedures at > > > > > the conference > > > > > > > >>> server are extended in that way, that > the conference > > > > > > > server is aware > > > > > > > >>> of already established dialogs, the > focus then has the > > > > > > > >>> > > > > > > > >> possibility to > > > > > > > >> > > > > > > > >>> send re-INVITES in the indicated dialogs > and connect the > > > > > > > media from > > > > > > > >>> the invited users to the conference > bridge. > > > > > > > >>> In the URI list the dialogs can be > indicated using the > > > > > > > "?" mechanism > > > > > > > >>> according to subclause 19.1.1 of RFC > 3261. > > > > > > > >>> > > > > > > > >>> Following example shows the proposed > mechanism: > > > > > > > >>> > > > > > > > >>> INVITE Conference > > > > > > > >>> To: Conference > > > > > > > >>> From: A > > > > > > > >>> Require: recipient-list-invite > > > > > > > >>> > > > > > > > >>> Content-Type: > application/resource-lists+xml > > > > > > > >>> Content-Disposition: recipient-list > > > > > > > >>> > > > > > > > >>> > > > > > > > >>> xmlns=3D"urn:ietf:params:xml:ns:resource- > > lists" > > > > > > > >>> > xmlns:cp=3D"urn:ietf:params:xml:ns:copyControl"> > > > > > > > >>> > > > > > > > >>> uri=3D"B?Call-ID=3D1&From=3DA%3Btag%3Da&To=3DB%3Btag%3Db" > > > > > > > >>> cp:copyControl=3D"to"/> > > > > > > > >>> uri=3D"C?Call-ID=3D2&From=3DA%3Btag%3Da&To=3DC%3btag%3Dc" > > > > > > > >>> cp:copyControl=3D"to"/> > > > > > > > >>> > > > > > > > >>> > > > > > > > >>> > > > > > > > >>> Greetings, > > > > > > > >>> Denis Alexeitsev > > > > > > > >>> > > > > > > > >>> > > > > > > > >>> > _______________________________________________ > > > > > > > >>> Sip mailing list =20 > > > > > > > >>> > https://www1.ietf.org/mailman/listinfo/sip > > > > > > > >>> 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 > > > > > > > application of sip > > > > > > > >>> > > > > > > > >> > > > > > > > >> > _______________________________________________ > > > > > > > >> Sip mailing list =20 > > > > > > > >> > https://www1.ietf.org/mailman/listinfo/sip > > > > > > > >> This list is for NEW development of the > core SIP Protocol=20 > > > > > > > >> Use sip-implementors@cs.columbia.edu for > questions on > > > > > current sip > > > > > > > >> Use sipping@ietf.org for new developments > on the > > > > > application of sip > > > > > > > >> > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Sip mailing list > https://www1.ietf.org/mailman/listinfo/sip > > > > > > This list is for NEW development of the core > SIP Protocol Use=20 > > > > > > sip-implementors@cs.columbia.edu for questions > on current sip=20 > > > > > > Use sipping@ietf.org for new developments on > the application=20 > > > > > > of > > sip > > > > > > > > > > > > > > _______________________________________________ > > > Sip mailing list > https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP > Protocol Use=20 > > > sip-implementors@cs.columbia.edu for questions on > current sip Use=20 > > > sipping@ietf.org for new developments on the > application of sip > > > >=20 >=20 > _______________________________________________ > Sip mailing list > https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP > Protocol Use sip-implementors@cs.columbia.edu for > questions on current sip Use sipping@ietf.org for new > developments on the application of sip >=20 >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Aug 30 08:09:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQioU-00064y-Ic; Thu, 30 Aug 2007 08:07:54 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IQioS-00063N-S9 for sip-confirm+ok@megatron.ietf.org; Thu, 30 Aug 2007 08:07:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQioS-000626-59; Thu, 30 Aug 2007 08:07:52 -0400 Received: from out001.iad.hostedmail.net ([209.225.56.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQioQ-00014T-FI; Thu, 30 Aug 2007 08:07:52 -0400 Received: from ATL1VEXC020.usdom003.tco.tc ([10.158.7.31]) by out001.iad.hostedmail.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Aug 2007 08:07:43 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 30 Aug 2007 08:07:55 -0400 Message-ID: In-Reply-To: <0A7D7D6BC1EEF6489C3D0AE1B6B1619504C147C8@xmb-sjc-223.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] [Reg] Diversion Header Thread-Index: AcfqbeqdLJEOLi4IQeeg5QcOeg0KRAAAVllAAACv/gAAIpWNoA== From: "Brett Tate" To: , X-OriginalArrivalTime: 30 Aug 2007 12:07:43.0375 (UTC) FILETIME=[5EA409F0:01C7EAFE] X-Spam-Score: 0.0 (/) X-Scan-Signature: b360bd6cb019c35178e5cf9eeb747a5c Cc: Subject: [Sip] RE: [Sipping] [Reg] Diversion Header X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2056157678==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============2056157678== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7EAFE.5EA41270" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7EAFE.5EA41270 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Per the section 5 BNF representation, only parameter values that have non token characters need the quotes. Thus the use of the quotes for the privacy and screen values within the examples is not needed. =20 ________________________________ From: Vinay Pande (vipande) [mailto:vipande@cisco.com]=20 Sent: Wednesday, August 29, 2007 3:31 PM To: Avasarala Ranjit-A20990; subhodeep.sarkar@wipro.com; sip@ietf.org; sipping@ietf.org Subject: RE: [Sipping] [Reg] Diversion Header =09 =09 The examples mentioned in section 7.1 and voice-mail / ISUP examples of sec 9.2 / sec 10 in draft-08 show that the reason, counter and other headers need not be in quotes. Only the screen and privacy parameter values are shown in quotes.=20 =20 Sec 9.2 =09 SIP/2.0 302 Moved Temporarily Via: SIP/2.0/UDP p1.isp.com Via: SIP/2.0/UDP alice-pc.isp.com Contact: Voicemail@isp.com From: sip:alice@isp.com To: ;tag=3Duas1 Call-ID: 12345600@alice-pc.isp.com CSeq: 1 INVITE Diversion: ;reason=3Ddo-not-disturb Sec 10.3.5: =09 =09 |--INVITE tel:+19195551004----> | Diversion: | ;reason=3Duser-busy | ;screen=3D"yes" | ;privacy=3D"off" | Diversion: | ;reason=3Dunconditional | ;screen=3D"yes" | ;privacy=3D"full" =20 Thanks, Vinay =20 ________________________________ From: Avasarala Ranjit-A20990 [mailto:ranjit@motorola.com]=20 Sent: Wednesday, August 29, 2007 12:04 PM To: subhodeep.sarkar@wipro.com; sip@ietf.org; sipping@ietf.org Subject: RE: [Sipping] [Reg] Diversion Header =09 =09 Hi Subhodeep =20 The correct syntax would be: Diversion: ...;reason=3D"user-busy";privacy=3D"full" =20 Regards=20 Ranjit=20 =20 ________________________________ From: subhodeep.sarkar@wipro.com [mailto:subhodeep.sarkar@wipro.com]=20 Sent: Thursday, August 30, 2007 12:31 AM To: sip@ietf.org; sipping@ietf.org Subject: [Sipping] [Reg] Diversion Header =09 =09 Hi, =20 I need some clarification regarding the encoding syntax of SIP Diversion header parameters reason & privacy .=20 =20 I am aware that Diversion header is replaced by History-Info, but I need to support Diversion header for some network implementation.=20 =20 diversion-reason =3D "reason" "=3D" ( "unknown" | "user-busy" | "no-answer" | "unavailable" | "unconditional" | "time-of-day" | "do-not-disturb" | "deflection" | "follow-me" | "out-of-service" | "away" | token | quoted-string ) diversion-privacy =3D "privacy" "=3D" ( "full" | "name" | "uri" | "off" | token | quoted-string ) =09 I like to know which is the correct syntax for the diversion-privacy & diversion-reason parameter i.e.=20 =20 Diversion: ...;reason=3D"user-busy";privacy=3D"full" =20 or, =20 =09 Diversion: ...;reason=3Duser-busy;privacy=3Dfull =20 Cheers, Subhodeep ------_=_NextPart_001_01C7EAFE.5EA41270 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Per the section 5 BNF representation, = only=20 parameter values that have non token characters need the quotes.  = Thus the=20 use of the quotes for the privacy and screen values within the = examples is=20 not needed.
 

From: Vinay Pande (vipande)=20 [mailto:vipande@cisco.com]
Sent: Wednesday, August 29, 2007 = 3:31=20 PM
To: Avasarala Ranjit-A20990; subhodeep.sarkar@wipro.com;=20 sip@ietf.org; sipping@ietf.org
Subject: RE: [Sipping] [Reg]=20 Diversion Header

The examples mentioned in section 7.1 and = voice-mail /=20 ISUP examples of sec 9.2 / sec 10 in draft-0= 8 show=20 that the reason, counter and other headers need not be in quotes. = Only the screen and privacy parameter values are = shown in quotes.=20
 
Sec 9.2
     =
     SIP/2.0 302 Moved Temporarily
          Via: SIP/2.0/UDP p1.isp.com
          Via: SIP/2.0/UDP alice-pc.isp.com
          Contact: Voicemail@isp.com
          From: sip:alice@isp.com
          To: <sip:Bob@p1.isp.com>;tag=3Duas1
          Call-ID: 12345600@alice-pc.isp.com
          CSeq: 1 INVITE
          Diversion: <sip:Bob@uas1.isp.com>;reason=3Ddo-not-disturb
Sec =
10.3.5:
                                       =
|--INVITE tel:+19195551004---->
                                       |  Diversion: =
<tel:+19195551002>
                                       |    ;reason=3Duser-busy
                                       |    ;screen=3D"yes"
                                       |    ;privacy=3D"off"
                                       |  Diversion: =
<tel:+19195551001>
                                       |    =
;reason=3Dunconditional
                                       |    ;screen=3D"yes"
                                       |    =
;privacy=3D"full"
 
<= !-- Converted from text/plain format -->

Thanks,
Vinay

 

From: Avasarala Ranjit-A20990=20 [mailto:ranjit@motorola.com]
Sent: Wednesday, August 29, = 2007 12:04=20 PM
To: subhodeep.sarkar@wipro.com; sip@ietf.org;=20 sipping@ietf.org
Subject: RE: [Sipping] [Reg] Diversion=20 Header

Hi Subhodeep
 
The correct syntax would be: Diversion:=20 = ...;reason=3D"user-busy";privacy=3D"full"
=
 

Regards
Ranjit

 

From: subhodeep.sarkar@wipro.com=20 [mailto:subhodeep.sarkar@wipro.com]
Sent: Thursday, August = 30, 2007=20 12:31 AM
To: sip@ietf.org; = sipping@ietf.org
Subject:=20 [Sipping] [Reg] Diversion Header

Hi,
 
I need some clarification = regarding the=20 encoding syntax of SIP Diversion header parameters reason & = privacy .=20
 
I am aware that Diversion = header is=20 replaced by History-Info, but I need to support Diversion header for = some=20 network implementation.
 
   =20 diversion-reason =3D "reason"=20 = "=3D"
          &nbs= p;        =20 ( "unknown" | "user-busy" | "no-answer"=20 = |
           &n= bsp;         =20 "unavailable" | "unconditional"=20 = |
           &n= bsp;         =20 "time-of-day" | "do-not-disturb"=20 = |
           &n= bsp;         =20 "deflection" | "follow-me"=20 = |
           &n= bsp;         =20 "out-of-service" | "away"=20 = |
           &n= bsp;         =20 token | quoted-string )
    diversion-privacy =3D "privacy" "=3D" ( = "full" | "name"=20 = |
           &n= bsp;           =20 "uri" | "off" | token | quoted-string )
I like to = know which is=20 the correct syntax for the diversion-privacy & diversion-reason = parameter=20 i.e.
 
Diversion:=20 ...;reason=3D"user-busy";privacy=3D"full"
 
or,
 
Diversion:=20 ...;reason=3Duser-busy;privacy=3Dfull
 
Cheers,
Subhodeep
------_=_NextPart_001_01C7EAFE.5EA41270-- --===============2056157678== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============2056157678==-- From sip-bounces@ietf.org Thu Aug 30 08:59:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQjag-00089w-E6; Thu, 30 Aug 2007 08:57:42 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IQjae-00089f-NL for sip-confirm+ok@megatron.ietf.org; Thu, 30 Aug 2007 08:57:41 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQjae-00086R-B3; Thu, 30 Aug 2007 08:57:40 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQjad-0007gN-3v; Thu, 30 Aug 2007 08:57:40 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l7UCvKrV004007; Thu, 30 Aug 2007 07:57:36 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Aug 2007 07:57:25 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.29]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Aug 2007 14:57:22 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 30 Aug 2007 14:57:21 +0200 Message-ID: <5D1A7985295922448D5550C94DE29180015F581C@DEEXC1U01.de.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] [Reg] Diversion Header Thread-Index: AcfqbeqdLJEOLi4IQeeg5QcOeg0KRAAAVllAAACv/gAAIpWNoAACCkPw References: <0A7D7D6BC1EEF6489C3D0AE1B6B1619504C147C8@xmb-sjc-223.amer.cisco.com> From: "DRAGE, Keith \(Keith\)" To: "Brett Tate" , , X-OriginalArrivalTime: 30 Aug 2007 12:57:22.0600 (UTC) FILETIME=[4E65B280:01C7EB05] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: cd3d702b63698072ba67a75ce9e0fc9e Cc: Subject: [Sip] RE: [Sipping] [Reg] Diversion Header X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1796390516==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1796390516== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7EB05.4E3B90C8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7EB05.4E3B90C8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Can I just add a caveat here that as this was never a SIP WG item, only an author draft, you take the answers as you find them.=20 =20 The standards track SIP solution for this problem is the History-Info header, documented in RFC 4244 (with some content extras in RFC 4458). =20 Note also that the Diversion header is also NOT IANA registered, and there is nothing therefore that prevents an alternative usage of the same character string coming along in the future with different semantics. =20 regards =20 Keith ________________________________ From: Brett Tate [mailto:brett@broadsoft.com]=20 Sent: Thursday, August 30, 2007 1:08 PM To: sip@ietf.org; sipping@ietf.org Subject: RE: [Sipping] [Reg] Diversion Header =09 =09 Per the section 5 BNF representation, only parameter values that have non token characters need the quotes. Thus the use of the quotes for the privacy and screen values within the examples is not needed. =20 ________________________________ From: Vinay Pande (vipande) [mailto:vipande@cisco.com]=20 Sent: Wednesday, August 29, 2007 3:31 PM To: Avasarala Ranjit-A20990; subhodeep.sarkar@wipro.com; sip@ietf.org; sipping@ietf.org Subject: RE: [Sipping] [Reg] Diversion Header =09 =09 The examples mentioned in section 7.1 and voice-mail / ISUP examples of sec 9.2 / sec 10 in draft-08 show that the reason, counter and other headers need not be in quotes. Only the screen and privacy parameter values are shown in quotes.=20 =20 Sec 9.2 =09 SIP/2.0 302 Moved Temporarily Via: SIP/2.0/UDP p1.isp.com Via: SIP/2.0/UDP alice-pc.isp.com Contact: Voicemail@isp.com From: sip:alice@isp.com To: ;tag=3Duas1 Call-ID: 12345600@alice-pc.isp.com CSeq: 1 INVITE Diversion: ;reason=3Ddo-not-disturb Sec 10.3.5: =09 =09 |--INVITE tel:+19195551004----> | Diversion: | ;reason=3Duser-busy | ;screen=3D"yes" | ;privacy=3D"off" | Diversion: | ;reason=3Dunconditional | ;screen=3D"yes" | ;privacy=3D"full" =20 Thanks, Vinay =20 ________________________________ From: Avasarala Ranjit-A20990 [mailto:ranjit@motorola.com]=20 Sent: Wednesday, August 29, 2007 12:04 PM To: subhodeep.sarkar@wipro.com; sip@ietf.org; sipping@ietf.org Subject: RE: [Sipping] [Reg] Diversion Header =09 =09 Hi Subhodeep =20 The correct syntax would be: Diversion: ...;reason=3D"user-busy";privacy=3D"full" =20 Regards=20 Ranjit=20 =20 ________________________________ From: subhodeep.sarkar@wipro.com [mailto:subhodeep.sarkar@wipro.com]=20 Sent: Thursday, August 30, 2007 12:31 AM To: sip@ietf.org; sipping@ietf.org Subject: [Sipping] [Reg] Diversion Header =09 =09 Hi, =20 I need some clarification regarding the encoding syntax of SIP Diversion header parameters reason & privacy .=20 =20 I am aware that Diversion header is replaced by History-Info, but I need to support Diversion header for some network implementation.=20 =20 diversion-reason =3D "reason" "=3D" ( "unknown" | "user-busy" | "no-answer" | "unavailable" | "unconditional" | "time-of-day" | "do-not-disturb" | "deflection" | "follow-me" | "out-of-service" | "away" | token | quoted-string ) diversion-privacy =3D "privacy" "=3D" ( "full" | "name" | "uri" | "off" | token | quoted-string ) =09 I like to know which is the correct syntax for the diversion-privacy & diversion-reason parameter i.e.=20 =20 Diversion: ...;reason=3D"user-busy";privacy=3D"full" =20 or, =20 =09 Diversion: ...;reason=3Duser-busy;privacy=3Dfull =20 Cheers, Subhodeep ------_=_NextPart_001_01C7EB05.4E3B90C8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Can I just add a caveat here that as this was = never a SIP=20 WG item, only an author draft, you take the answers as you find them.=20
 
The standards track SIP solution for this = problem is the=20 History-Info header, documented in RFC 4244 (with some content extras in = RFC=20 4458).
 
Note also that the Diversion header is also NOT = IANA=20 registered, and there is nothing therefore that prevents an alternative = usage of=20 the same character string coming along in the future with different=20 semantics.
 
regards
 
Keith

From: Brett Tate = [mailto:brett@broadsoft.com]=20
Sent: Thursday, August 30, 2007 1:08 PM
To: = sip@ietf.org;=20 sipping@ietf.org
Subject: RE: [Sipping] [Reg] Diversion=20 Header

Per the section 5 BNF representation, = only=20 parameter values that have non token characters need the quotes.  = Thus=20 the use of the quotes for the privacy and screen values within the=20 examples is not needed.
 

From: Vinay Pande (vipande)=20 [mailto:vipande@cisco.com]
Sent: Wednesday, August 29, = 2007 3:31=20 PM
To: Avasarala Ranjit-A20990; = subhodeep.sarkar@wipro.com;=20 sip@ietf.org; sipping@ietf.org
Subject: RE: [Sipping] = [Reg]=20 Diversion Header

The examples mentioned in section 7.1 and = voice-mail /=20 ISUP examples of sec 9.2 / sec 10 in draft-0= 8 show=20 that the reason, counter and other headers need not be in = quotes.=20 Only the screen and privacy parameter values are = shown in=20 quotes.
 
Sec 9.2
   =
       SIP/2.0 302 Moved Temporarily
          Via: SIP/2.0/UDP p1.isp.com
          Via: SIP/2.0/UDP alice-pc.isp.com
          Contact: Voicemail@isp.com
          From: sip:alice@isp.com
          To: <sip:Bob@p1.isp.com>;tag=3Duas1
          Call-ID: 12345600@alice-pc.isp.com
          CSeq: 1 INVITE
          Diversion: <sip:Bob@uas1.isp.com>;reason=3Ddo-not-disturb
Sec =
10.3.5:
                                       =
|--INVITE tel:+19195551004---->
                                       |  Diversion: =
<tel:+19195551002>
                                       |    ;reason=3Duser-busy
                                       |    ;screen=3D"yes"
                                       |    ;privacy=3D"off"
                                       |  Diversion: =
<tel:+19195551001>
                                       |    =
;reason=3Dunconditional
                                       |    ;screen=3D"yes"
                                       |    =
;privacy=3D"full"
 
<= !-- Converted from text/plain format -->

Thanks,
Vinay

 

From: Avasarala Ranjit-A20990=20 [mailto:ranjit@motorola.com]
Sent: Wednesday, August 29, = 2007=20 12:04 PM
To: subhodeep.sarkar@wipro.com; sip@ietf.org;=20 sipping@ietf.org
Subject: RE: [Sipping] [Reg] Diversion=20 Header

Hi Subhodeep
 
The correct syntax would be: Diversion:=20 = ...;reason=3D"user-busy";privacy=3D"full"
=
 

Regards
Ranjit

 

From: subhodeep.sarkar@wipro.com = [mailto:subhodeep.sarkar@wipro.com]
Sent: Thursday, = August 30,=20 2007 12:31 AM
To: sip@ietf.org;=20 sipping@ietf.org
Subject: [Sipping] [Reg] Diversion=20 Header

Hi,
 
I need some = clarification regarding=20 the encoding syntax of SIP Diversion header parameters reason &=20 privacy .
 
I am aware that = Diversion header is=20 replaced by History-Info, but I need to support Diversion header for = some=20 network implementation.
 
    diversion-reason =3D "reason"=20 = "=3D"
          &nbs= p;        =20 ( "unknown" | "user-busy" | "no-answer"=20 = |
           &n= bsp;         =20 "unavailable" | "unconditional"=20 = |
           &n= bsp;         =20 "time-of-day" | "do-not-disturb"=20 = |
           &n= bsp;         =20 "deflection" | "follow-me"=20 = |
           &n= bsp;         =20 "out-of-service" | "away"=20 = |
           &n= bsp;         =20 token | quoted-string )
    diversion-privacy =3D "privacy" "=3D" ( = "full" |=20 "name"=20 = |
           &n= bsp;           =20 "uri" | "off" | token | quoted-string )
I like = to know which is=20 the correct syntax for the diversion-privacy & diversion-reason=20 parameter i.e.
 
Diversion:=20 ...;reason=3D"user-busy";privacy=3D"full"
 
or,
 
Diversion:=20 ...;reason=3Duser-busy;privacy=3Dfull
 
Cheers,
Subhodeep
------_=_NextPart_001_01C7EB05.4E3B90C8-- --===============1796390516== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1796390516==-- From sip-bounces@ietf.org Thu Aug 30 09:05:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQjgf-0005C0-9k; Thu, 30 Aug 2007 09:03:53 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IQjgd-0005Bp-Ft for sip-confirm+ok@megatron.ietf.org; Thu, 30 Aug 2007 09:03:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQjgd-0005BU-0z; Thu, 30 Aug 2007 09:03:51 -0400 Received: from ihemail3.lucent.com ([135.245.0.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQjgc-0007si-0g; Thu, 30 Aug 2007 09:03:50 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id l7UD3lYc023199; Thu, 30 Aug 2007 08:03:49 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Aug 2007 08:03:48 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.29]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Aug 2007 15:03:46 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-subnot-etags-01.txt Date: Thu, 30 Aug 2007 15:03:45 +0200 Message-ID: <5D1A7985295922448D5550C94DE29180015F5829@DEEXC1U01.de.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] I-D ACTION:draft-ietf-sip-subnot-etags-01.txt Thread-Index: AcfqeXIZYqPFH0x9SESxYBczcjpwqQAjHdQA References: From: "DRAGE, Keith \(Keith\)" To: , X-OriginalArrivalTime: 30 Aug 2007 13:03:46.0091 (UTC) FILETIME=[32F9C7B0:01C7EB06] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org (As WG chair) We are intending trying to start the WGLC on this document real soon. This is advance notice just to see that all the current technical issues raised in the last few months have been fixed to the commentors satisfaction. So if you have made a technical comment on this document, please check it is addressed, and if not, please raise back on the list in the next couple of days. Regards Keith > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 > Sent: Wednesday, August 29, 2007 9:15 PM > To: i-d-announce@ietf.org > Cc: sip@ietf.org > Subject: [Sip] I-D ACTION:draft-ietf-sip-subnot-etags-01.txt=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > This draft is a work item of the Session Initiation Protocol=20 > Working Group of the IETF. >=20 > Title : An Extension to Session Initiation=20 > Protocol (SIP) Events for Conditional Event Notification > Author(s) : A. Niemi > Filename : draft-ietf-sip-subnot-etags-01.txt > Pages : 25 > Date : 2007-8-29 > =09 > The Session Initiation Protocol (SIP) events framework enables > receiving asynchronous notification of various events from=20 > other SIP > user agents. This framework defines the procedures for creating, > refreshing and terminating subscriptions, as well as fetching and > periodic polling of resource state. These procedures have=20 > a serious > deficiency in that they provide no tools to avoid replaying event > notifications that have already been received by a user=20 > agent. This > memo defines an extension to SIP events that allows the=20 > subscriber to > condition the subscription request to whether the state has changed > since the previous notification was received. When such a=20 > condition > is true, either the body of a resulting event notification or the > entire notification message is suppressed. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sip-subnot-etags-01.txt >=20 > To remove yourself from the I-D Announcement list, send a=20 > message to i-d-announce-request@ietf.org with the word=20 > unsubscribe in the body of the message.=20 > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. >=20 > Internet-Drafts are also available by anonymous FTP. Login=20 > with the username "anonymous" and a password of your e-mail=20 > address. After logging in, type "cd internet-drafts" and then=20 > "get draft-ietf-sip-subnot-etags-01.txt". >=20 > A list of Internet-Drafts directories can be found in=20 > http://www.ietf.org/shadow.html or=20 > ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-sip-subnot-etags-01.txt". > =09 > 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=20 > 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. >=20 > Below is the data which will enable a MIME compliant mail=20 > reader implementation to automatically retrieve the ASCII=20 > version of the Internet-Draft. >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Aug 30 10:32:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQl2l-0002Tk-Hz; Thu, 30 Aug 2007 10:30:47 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IQl2j-0002FK-O0 for sip-confirm+ok@megatron.ietf.org; Thu, 30 Aug 2007 10:30:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQl2i-0002Dy-PT for sip@ietf.org; Thu, 30 Aug 2007 10:30:45 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQl2i-00029n-A2 for sip@ietf.org; Thu, 30 Aug 2007 10:30:44 -0400 Received: from [172.17.1.65] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l7UEUdiP080771 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 30 Aug 2007 09:30:40 -0500 (CDT) (envelope-from rjsparks@nostrum.com) In-Reply-To: <46D67121.4030409@nokia.com> References: <46D27F1E.8090107@nokia.com> <46D67121.4030409@nokia.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5D49593D-18C1-4B71-93E9-5A96A23201BB@nostrum.com> Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Sip] Subnot-etags: refactoring Date: Thu, 30 Aug 2007 09:30:34 -0500 To: Aki Niemi X-Mailer: Apple Mail (2.752.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.91.2/4108/Thu Aug 30 05:58:53 2007 on shaman.nostrum.com X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Ok - sounds like we're good then. I'll keep an eye on making sure this is clear to the implementor during LC review. RjS On Aug 30, 2007, at 2:26 AM, Aki Niemi wrote: > > > ext Robert Sparks wrote: >> I'm still pretty uncomfortable with suppressing the entire NOTIFY for >> a refresh subscription. There are mechanics that involve the >> Subscription-State >> header and its possible extension that I fear we will interact >> with in >> unexpected ways. > > The way this works now is that we are explicit on what is > considered the > "entity" and what is not. In the current version of the draft, we > explicitly say that the "entity" is the event data in the body plus > Content-* and Entity fields in the header. On the other hand, > subscription state is *not* part of the entity, and therefore not > covered by the entity-tag. > > This then gives the notifier three choices when it gets a SUBSCRIBE > requesting for conditional notification. It will either: > > 1) report nothing (204 response) if neither entity nor subscription > state have changed; > 2) suppress the body if only the subscription state has changed; > 3) send a full notify if the entity has changed > > So I think this solves your concern, since the notifier can always > report the changes, even in the subscription refresh. Before, this was > actually quite poorly defined. > >> I will admit that all the specific instances of that I can think of >> right now you can work >> around by being really careful with the success response to the >> reSUBSCRIBE. Can >> anybody come up with a case (or imagine an extension) where the >> response >> to the >> reSUBSCRIBE won't have the right stuff? > > I believe currently there are none. However, if in the future there > are > extensions that should be considered to be part of the "entity" or > subscription state, then those event-packages would need to define > this > behavior. In practice, they would need to cover cases where changes in > these additional header fields would trigger a NOTIFY without the > body, > or a NOTIFY with a body and a changed entity-tag. > > 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 sip-bounces@ietf.org Thu Aug 30 11:17:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQlje-0006d4-0g; Thu, 30 Aug 2007 11:15:06 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IQljb-0006cT-AO for sip-confirm+ok@megatron.ietf.org; Thu, 30 Aug 2007 11:15:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQljb-0006cL-0e; Thu, 30 Aug 2007 11:15:03 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQljZ-00070N-SO; Thu, 30 Aug 2007 11:15:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id D06B9328B9; Thu, 30 Aug 2007 15:15:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IQljZ-0001m8-OO; Thu, 30 Aug 2007 11:15:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 30 Aug 2007 11:15:01 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-body-handling-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org --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 : Message Body Handling in the Session Initiation Protocol (SIP) Author(s) : G. Camarillo Filename : draft-ietf-sip-body-handling-00.txt Pages : 13 Date : 2007-8-30 This document clarifies how message bodies are handled in SIP. Additionally, it discusses to which degree SIP user agents need to support MIME (Multipurpose Internet Mail Extensions)-encoding of body parts. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-body-handling-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-body-handling-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-ietf-sip-body-handling-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: <2007-8-30104704.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-body-handling-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-body-handling-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-8-30104704.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Thu Aug 30 18:05:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQs75-0004LR-3u; Thu, 30 Aug 2007 18:03:43 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IQs72-0004LH-PG for sip-confirm+ok@megatron.ietf.org; Thu, 30 Aug 2007 18:03:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQs72-0004L9-DE for sip@ietf.org; Thu, 30 Aug 2007 18:03:40 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQs71-0006RW-NJ for sip@ietf.org; Thu, 30 Aug 2007 18:03:40 -0400 Received: from repmmr01.bea.com (repmmr01.bea.com [10.160.29.71]) by repmmg02.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l7UM3Oav022399; Thu, 30 Aug 2007 15:03:24 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr01.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l7UM3M2w030751; Thu, 30 Aug 2007 15:03:22 -0700 Received: from 172.24.29.17 ([172.24.29.17]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Thu, 30 Aug 2007 22:03:22 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Thu, 30 Aug 2007 18:03:15 -0400 Subject: Re: [Sip] INFO From: Eric Burger To: Peili Xu Message-ID: Thread-Topic: [Sip] INFO Thread-Index: AcfopsS6ijL/eVSeR7OkrFxhvjEZ1wCqsuc+ In-Reply-To: <317ceda50708270535i290e54c8m6966ba15c1ace89e@mail.gmail.com> Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Saying, "OK for interworking" does not really say anything. If I come up with a really broken method for interworking, saying that it is for interworking does not make it correct. The problem is, how do the endpoints know they will be able to communicate? For the ISUP/Q.sig/DPNSS/mumble case, the endpoints know they will be able to interoperate because they know a'priori: they are configured to work. However, this means that the devices must be in the same administrative domain and configured properly. Said in a different manner, INFO works fine for non-inter-network use. It would be hard for the IETF to say, "Here is a non-IETF use. We will not use it. You cannot use it with anyone else. You cannot use it between manufacturers, unless you get them to agree to this use." That is a bit more of what we call the toxic waste warning that accompanies 3GPP specifications... On 8/27/07 8:35 AM, "Peili Xu" wrote: > Hi Eric, > > Several cases I encounter to use INFO is for interworking with PSTN signaling, > or simulate PSTN services at SIP entities such as SIP UA or SIP GW, > which require mid-dialog information change. > > For such SIP entities, It's not always possible or required to support > encapsulation of ISUP or QSIG package. Just some XML body with > application info is enough and light-weight for this purpose. > > > INFO is not an ideal tool for everything, but is an ideal tool for some thing. > > I'd prpose to at lease allow using INFO for interworking or simulation > purpose with legacy system. > > Regards. > Peili > > 2007/8/22, Eric Burger : >> Since list traffic is down, how about something to spice things up? >> >> >> Any thoughts on >> >> http://www.ietf.org/internet-drafts/draft-burger-sip-info-01.txt >> >> ??? >> >> If you like it, say so. If you hate it, say so. >> >> Text welcome. >> >> >> Notice: This email message, together with any attachments, may contain >> information of BEA Systems, Inc., its subsidiaries and affiliated >> entities, that may be confidential, proprietary, copyrighted and/or >> legally privileged, and is intended solely for the use of the individual or >> entity named in this message. If you are not the intended recipient, and have >> received this message in error, please immediately return this by email and >> then delete 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 >> > Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete 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 sip-bounces@ietf.org Fri Aug 31 00:19:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQxwF-0005Ez-1V; Fri, 31 Aug 2007 00:16:55 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IQxwD-0005Ed-BC for sip-confirm+ok@megatron.ietf.org; Fri, 31 Aug 2007 00:16:53 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQxwC-0005EK-LD; Fri, 31 Aug 2007 00:16:52 -0400 Received: from wip-cdc-wd.wipro.com ([203.91.201.26]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQxwB-0006Bj-O6; Fri, 31 Aug 2007 00:16:52 -0400 Received: from wip-cdc-wd.wipro.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 3785618058; Fri, 31 Aug 2007 09:47:12 +0530 (IST) Received: from blr-ec-bh01.wipro.com (blr-ec-bh01.wipro.com [10.201.50.91]) by wip-cdc-wd.wipro.com (Postfix) with ESMTP id 2780818053; Fri, 31 Aug 2007 09:47:12 +0530 (IST) Received: from PNE-HJN-MBX01.wipro.com ([10.111.50.182]) by blr-ec-bh01.wipro.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 31 Aug 2007 09:47:30 +0530 Received: from HJNPNE153336 ([10.111.14.31]) by PNE-HJN-MBX01.wipro.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 31 Aug 2007 09:47:30 +0530 From: "khushboo jain" To: , Date: Fri, 31 Aug 2007 09:48:29 +0530 Message-ID: <000d01c7eb85$fbde5c20$6f9098c6@HJNPNE153336> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcfrhfusQq2XwrtCRkuQO2FrGrHYxA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-OriginalArrivalTime: 31 Aug 2007 04:17:30.0464 (UTC) FILETIME=[D8D93600:01C7EB85] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: Subject: [Sip] push to talk without establishing dialog X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1994636126==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1994636126== Content-Type: multipart/alternative; boundary="----=_NextPart_000_000E_01C7EBB4.15969820" This is a multi-part message in MIME format. ------=_NextPart_000_000E_01C7EBB4.15969820 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I want to implement push to talk without using PTT server. I was thinking of sending notify directly to the called party. What will be the call flows like just after receiving 200 OK from called party and giving ACK, should the caller start speaking? Does this have advantages over sending INVITE? Thanks ------=_NextPart_000_000E_01C7EBB4.15969820 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
I want = to implement=20 push to talk without using PTT server.
I was = thinking=20 of sending notify directly to the called party.
What = will be the=20 call flows like just after receiving 200 OK from called party and giving = ACK,=20 should the caller start speaking?
Does = this have=20 advantages over sending INVITE?
 
Thanks  
<= /DIV> ------=_NextPart_000_000E_01C7EBB4.15969820-- --===============1994636126== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1994636126==-- From sip-bounces@ietf.org Fri Aug 31 01:59:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQzVK-0000Yy-4j; Fri, 31 Aug 2007 01:57:14 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IQzVI-0000Yt-Sl for sip-confirm+ok@megatron.ietf.org; Fri, 31 Aug 2007 01:57:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQzVI-0000Yj-4e for sip@ietf.org; Fri, 31 Aug 2007 01:57:12 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQzVH-0001rQ-Ns for sip@ietf.org; Fri, 31 Aug 2007 01:57:12 -0400 Received: from hkaplan [75.68.59.21] by acmepacket.com with ESMTP (SMTPD-9.10) id ADB60498; Fri, 31 Aug 2007 01:57:10 -0400 From: "Hadriel Kaplan" To: "'Eric Burger'" , "'sip'" References: Subject: RE: [Sip] INFO Date: Fri, 31 Aug 2007 01:41:26 -0400 Message-ID: <006e01c7eb91$9290b1d0$6401a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfkO3T4s2cG+lAuEdy/WQAWy4mm/wHUBx+w In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hey Eric, I read the draft and was especially interested in the claim that KPML consumed less bandwidth than INFO for DTMF. You cite an IEEE paper, but I don't think that's freely available. Can you summarize how you came to such a conclusion? When I do the numbers, KPML often loses... in some scenarios by a LOT. And it's not even just the extra bandwidth/messages, but also the state and processing horsepower. There is one scenario where KPML wins, for some SIP boxes but not others. Although that could all be because I either don't correctly understand the actual way KPML would be used, or because the use cases I am concerned with are not the same as those in your paper's analysis. -hadriel > -----Original Message----- > From: Eric Burger [mailto:eburger@bea.com] > Sent: Tuesday, August 21, 2007 5:37 PM > To: 'sip' > Subject: [Sip] INFO > > Since list traffic is down, how about something to spice things up? > > > Any thoughts on > > http://www.ietf.org/internet-drafts/draft-burger-sip-info-01.txt > > ??? > > If you like it, say so. If you hate it, say so. > > Text welcome. > > > Notice: This email message, together with any attachments, may contain > information of BEA Systems, Inc., its subsidiaries and affiliated > entities, that may be confidential, proprietary, copyrighted and/or > legally privileged, and is intended solely for the use of the individual > or entity named in this message. If you are not the intended recipient, > and have received this message in error, please immediately return this by > email and then delete 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Aug 31 02:33:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IR031-0004QF-6q; Fri, 31 Aug 2007 02:32:03 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IR030-0004QA-G9 for sip-confirm+ok@megatron.ietf.org; Fri, 31 Aug 2007 02:32:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IR030-0004Q2-6K for sip@ietf.org; Fri, 31 Aug 2007 02:32:02 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IR02y-0002V7-3O for sip@ietf.org; Fri, 31 Aug 2007 02:32:02 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JNM001QIKS5NB@szxga01-in.huawei.com> for sip@ietf.org; Fri, 31 Aug 2007 14:31:18 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JNM007AGKS4KX@szxga01-in.huawei.com> for sip@ietf.org; Fri, 31 Aug 2007 14:31:17 +0800 (CST) Received: from x18916 ([10.85.28.238]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JNM000O0KS15L@szxml03-in.huawei.com> for sip@ietf.org; Fri, 31 Aug 2007 14:31:16 +0800 (CST) Date: Fri, 31 Aug 2007 14:31:12 +0800 From: Peili Xu Subject: RE: [Sip] INFO In-reply-to: To: 'Eric Burger' Message-id: <000601c7eb98$86b9fa40$ee1c550a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-index: AcfopsS6ijL/eVSeR7OkrFxhvjEZ1wCqsuc+ABF4AvA= X-Spam-Score: 1.2 (+) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Cc: 'sip' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I fully understand your concern. But just to forbidden using INFO does not solve the "how do the endpoints know they will be able to communicate?" problem/requirement either. I'd suggest we first consider to find solution for the prolem then after that we can say "Don't use INFO for this, Use that solution." Do you think this is a more convising way? Peili -----Original Message----- From: Eric Burger [mailto:eburger@bea.com] Sent: Friday, August 31, 2007 6:03 AM To: Peili Xu Cc: sip Subject: Re: [Sip] INFO Saying, "OK for interworking" does not really say anything. If I come up with a really broken method for interworking, saying that it is for interworking does not make it correct. The problem is, how do the endpoints know they will be able to communicate? For the ISUP/Q.sig/DPNSS/mumble case, the endpoints know they will be able to interoperate because they know a'priori: they are configured to work. However, this means that the devices must be in the same administrative domain and configured properly. Said in a different manner, INFO works fine for non-inter-network use. It would be hard for the IETF to say, "Here is a non-IETF use. We will not use it. You cannot use it with anyone else. You cannot use it between manufacturers, unless you get them to agree to this use." That is a bit more of what we call the toxic waste warning that accompanies 3GPP specifications... On 8/27/07 8:35 AM, "Peili Xu" wrote: > Hi Eric, > > Several cases I encounter to use INFO is for interworking with PSTN > signaling, or simulate PSTN services at SIP entities such as SIP UA or > SIP GW, which require mid-dialog information change. > > For such SIP entities, It's not always possible or required to support > encapsulation of ISUP or QSIG package. Just some XML body with > application info is enough and light-weight for this purpose. > > > INFO is not an ideal tool for everything, but is an ideal tool for some thing. > > I'd prpose to at lease allow using INFO for interworking or simulation > purpose with legacy system. > > Regards. > Peili > > 2007/8/22, Eric Burger : >> Since list traffic is down, how about something to spice things up? >> >> >> Any thoughts on >> >> http://www.ietf.org/internet-drafts/draft-burger-sip-inf o-01.txt >> >> ??? >> >> If you like it, say so. If you hate it, say so. >> >> Text welcome. >> >> >> Notice: This email message, together with any attachments, may >> contain information of BEA Systems, Inc., its subsidiaries and >> affiliated entities, that may be confidential, proprietary, >> copyrighted and/or legally privileged, and is intended solely for >> the use of the individual or entity named in this message. If you are >> not the intended recipient, and have received this message in error, >> please immediately return this by email and then delete 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 >> > Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Aug 31 04:56:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IR2Gp-0004UG-ET; Fri, 31 Aug 2007 04:54:27 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IR2Gn-0004Ql-TR for sip-confirm+ok@megatron.ietf.org; Fri, 31 Aug 2007 04:54:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IR2Gn-0004Qd-Ju for sip@ietf.org; Fri, 31 Aug 2007 04:54:25 -0400 Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IR2Gm-0005p7-4P for sip@ietf.org; Fri, 31 Aug 2007 04:54:25 -0400 Received: from mail1.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id l7V8sNk6003859 for ; Fri, 31 Aug 2007 10:54:23 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id l7V8sMhO021685 for ; Fri, 31 Aug 2007 10:54:22 +0200 Received: from MCHP7I7A.ww002.siemens.net ([139.25.131.142]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 31 Aug 2007 10:54:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 31 Aug 2007 10:54:21 +0200 Message-ID: <454C097A8CB3F14BB73494D0CE053DBE22A4E3@MCHP7I7A.ww002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Allowed SIP Header Fileds Thread-Index: AcfrrIXz/SJoApuNQn213dJZCM+jLw== From: "Fries, Steffen" To: X-OriginalArrivalTime: 31 Aug 2007 08:54:17.0438 (UTC) FILETIME=[836057E0:01C7EBAC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: [Sip] Allowed SIP Header Fileds X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, just a question regarding the allowed SIP header field in RFC 3261. The = Table 2 in section 20 states the corresponding headers for = WWW-Authenticate and Authentication-Info but it does only state = Proxy-Authenticate. While RFC2617 stated the Proxy-Authentication-Info = header, RFC3261 does not. What is the reason for the removal and how is = the Proxy Authentication on client side (via digest authentication) to = be done in this case? Ciao Steffen > ------------------------------------------- > Steffen Fries =20 > Siemens AG, CT IC 3=09 > Otto-Hahn-Ring 6, 81730 Munich, Germany=20 > Phone: (+49) 89 / 636-53403, =20 > Fax : (+49) 89 / 636-48000 > email: Steffen.Fries@siemens.com > ------------------------------------------- Siemens Aktiengesellschaft: Vorsitzender des Aufsichtsrats: Gerhard = Cromme; Vorstand: Peter L=F6scher, Vorsitzender; Johannes Feldmayer, Heinrich = Hiesinger, Joe Kaeser, Rudi Lamprecht, Eduardo Montes, J=FCrgen = Radomski, Erich R. Reinhardt, Hermann Requardt, Uriel J. Sharef, Klaus = Wucherer Sitz der Gesellschaft: Berlin und M=FCnchen, Registergericht: Berlin Charlottenburg, HRB 12300, M=FCnchen, HRB 6684 WEEE-Reg.-Nr. DE 23691322 > ___________________________________________ >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Aug 31 06:16:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IR3WU-0005ms-1c; Fri, 31 Aug 2007 06:14:42 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IR3WS-0005mm-Sw for sip-confirm+ok@megatron.ietf.org; Fri, 31 Aug 2007 06:14:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IR3WS-0005me-Ha for sip@ietf.org; Fri, 31 Aug 2007 06:14:40 -0400 Received: from sea02-mxf01.citel.com ([205.234.66.116]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IR3WR-00072a-Sr for sip@ietf.org; Fri, 31 Aug 2007 06:14:40 -0400 Received: from [10.8.50.21] (helo=sea02-mxc01.citel.com) by sea02-mxf01.citel.com with smtp (Exim 4.43) id 1IR3Wt-0002nO-CA; Fri, 31 Aug 2007 03:15:07 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Allowed SIP Header Fileds Date: Fri, 31 Aug 2007 03:14:34 -0700 Message-ID: <0D4E483A0E6E0A46861409E5D6C2011CA13790@sea02-mxc01.citel.com> In-Reply-To: <454C097A8CB3F14BB73494D0CE053DBE22A4E3@MCHP7I7A.ww002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Allowed SIP Header Fileds Thread-Index: AcfrrIXz/SJoApuNQn213dJZCM+jLwACIpMg References: <454C097A8CB3F14BB73494D0CE053DBE22A4E3@MCHP7I7A.ww002.siemens.net> From: "Michael Procter" To: "Fries, Steffen" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Steffen, Proxy authentication on the client side is performed using the headers = 'Proxy-Authenticate' and 'Proxy-Authorization' in the same way as user = to-user authentication uses the headers 'WWW-Authenticate' and = 'Authorization'. The extra header 'Authentication-Info' is allowed by RFC3261 Section = 22.4, last paragraph: RFC 2543 did not allow usage of the Authentication-Info header field (it effectively used RFC 2069). However, we now allow usage of this header field, since it provides integrity checks over the bodies and provides mutual authentication. Authentication is possible with just the normal 2 headers. But other = benefits occur when using the third header (Authentication-Info) in the = user-to-user case, sufficient to make RFC3261 permit it. Presumably the = advantages were not sufficient for the comparable user-to-proxy case. Regards, Michael > -----Original Message----- > From: Fries, Steffen [mailto:steffen.fries@siemens.com] > Sent: 31 August 2007 09:54 > To: sip@ietf.org > Subject: [Sip] Allowed SIP Header Fileds >=20 > Hi, >=20 > just a question regarding the allowed SIP header field in RFC 3261. > The Table 2 in section 20 states the corresponding headers for WWW- > Authenticate and Authentication-Info but it does only state Proxy- > Authenticate. While RFC2617 stated the Proxy-Authentication-Info > header, RFC3261 does not. What is the reason for the removal and how > is the Proxy Authentication on client side (via digest authentication) > to be done in this case? >=20 > Ciao > Steffen >=20 >=20 > > ------------------------------------------- > > Steffen Fries > > Siemens AG, CT IC 3 > > Otto-Hahn-Ring 6, 81730 Munich, Germany > > Phone: (+49) 89 / 636-53403, > > Fax : (+49) 89 / 636-48000 > > email: Steffen.Fries@siemens.com > > ------------------------------------------- > Siemens Aktiengesellschaft: Vorsitzender des Aufsichtsrats: Gerhard > Cromme; > Vorstand: Peter L=F6scher, Vorsitzender; Johannes Feldmayer, Heinrich > Hiesinger, Joe Kaeser, Rudi Lamprecht, Eduardo Montes, J=FCrgen > Radomski, Erich R. Reinhardt, Hermann Requardt, Uriel J. Sharef, Klaus > Wucherer > Sitz der Gesellschaft: Berlin und M=FCnchen, > Registergericht: Berlin Charlottenburg, HRB 12300, M=FCnchen, HRB 6684 > WEEE-Reg.-Nr. DE 23691322 > > ___________________________________________ > > > > >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Aug 31 09:57:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IR6yD-0005FP-TA; Fri, 31 Aug 2007 09:55:33 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IR6yC-0005FE-8a for sip-confirm+ok@megatron.ietf.org; Fri, 31 Aug 2007 09:55:32 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IR6yB-0005Ey-Tj for sip@ietf.org; Fri, 31 Aug 2007 09:55:31 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IR6yB-0006GM-DW for sip@ietf.org; Fri, 31 Aug 2007 09:55:31 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 401E621537 for ; Fri, 31 Aug 2007 15:55:30 +0200 (CEST) X-AuditID: c1b4fb3e-ae831bb0000007e1-48-46d81dd29cb9 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 2BA5C21513 for ; Fri, 31 Aug 2007 15:55:30 +0200 (CEST) Received: from esealmw118.eemea.ericsson.se ([153.88.200.77]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 31 Aug 2007 15:55:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 31 Aug 2007 15:55:49 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Privacy and Referred-By header Thread-Index: AcfrHuKgjB3X56vcRt6chYMS0ryppQAtkwPA From: "Ian Elz (CV/ETL)" To: X-OriginalArrivalTime: 31 Aug 2007 13:55:29.0669 (UTC) FILETIME=[9743F350:01C7EBD6] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: [Sip] Privacy and Referred-By header X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I have been looking at RFC3892 (Referred-By) and RFC 3323 (Privacy) and have a query about how privacy of the Referred-By header can be specified. The problem is as follows: When an INVITE results from a REFER which contains a Referred-By header the privacy of the Referred-By can be specified by "Privacy: user" in the REFER. How is this handled in the subsequent INVITE ? If the Refer target does not set privacy when it constructs the INVITE then the Referred-By will not have privacy associated with it when it was requested in the REFER. If the privacy from the REFER is used in the INVITE then the Refer target information will also have privacy when this is not required. I have noted that for History headers that an extension to the Privacy header was included which allows the use of the 'history' value in the Privacy header and also allows a Header parameter of Privacy to be associated with the hi-targeted-to-uri to specify privacy for specific uri's. Does such a mechanism exist for Referred-By headers and if so what value should be used ? Ian Elz Office: + 44 24 764 35256 gsm: +44 7801723668 ian.elz@ericsson.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Aug 31 10:33:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IR7XT-0001zo-Rq; Fri, 31 Aug 2007 10:31:59 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IQxsN-0007d5-RE for sip-confirm+ok@megatron.ietf.org; Fri, 31 Aug 2007 00:12:55 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQxsN-0007cn-Em for sip@ietf.org; Fri, 31 Aug 2007 00:12:55 -0400 Received: from wip-cdc-wd.wipro.com ([203.91.201.26]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQxsK-00068B-Dn for sip@ietf.org; Fri, 31 Aug 2007 00:12:53 -0400 Received: from wip-cdc-wd.wipro.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id B482618058 for ; Fri, 31 Aug 2007 09:43:11 +0530 (IST) Received: from blr-ec-bh02.wipro.com (blr-ec-bh02.wipro.com [10.201.50.92]) by wip-cdc-wd.wipro.com (Postfix) with ESMTP id A5DD818053 for ; Fri, 31 Aug 2007 09:43:11 +0530 (IST) Received: from PNE-HJN-MBX01.wipro.com ([10.111.50.182]) by blr-ec-bh02.wipro.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 31 Aug 2007 09:43:14 +0530 Received: from HJNPNE153336 ([10.111.14.31]) by PNE-HJN-MBX01.wipro.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 31 Aug 2007 09:43:29 +0530 From: "khushboo jain" To: Date: Fri, 31 Aug 2007 09:44:28 +0530 Message-ID: <000801c7eb85$6c95c1c0$6f9098c6@HJNPNE153336> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcfrhWvg+IEn7UCuRBy7A4xJ1/NRqA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-OriginalArrivalTime: 31 Aug 2007 04:13:30.0106 (UTC) FILETIME=[49957DA0:01C7EB85] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 X-Mailman-Approved-At: Fri, 31 Aug 2007 10:31:58 -0400 Subject: [Sip] push to talk session without dialog X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1002898591==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1002898591== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C7EBB3.864DFDC0" This is a multi-part message in MIME format. ------=_NextPart_000_0009_01C7EBB3.864DFDC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I want to implement push to talk without using PTT server. I was thinking of sending notify directly to the called party. What will be the call flows like just after receiving 200 OK from called party and giving ACK, should the caller start speaking? Does this have advantages over sending INVITE? Thanks ------=_NextPart_000_0009_01C7EBB3.864DFDC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
I want = to implement=20 push to talk without using PTT server.
I was = thinking=20 of sending notify directly to the called party.
What = will be the=20 call flows like just after receiving 200 OK from called party and giving = ACK,=20 should the caller start speaking?
Does = this have=20 advantages over sending INVITE?
 
Thanks  
<= /HTML> ------=_NextPart_000_0009_01C7EBB3.864DFDC0-- --===============1002898591== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1002898591==-- From sip-bounces@ietf.org Fri Aug 31 11:30:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IR8QM-0000Vk-1O; Fri, 31 Aug 2007 11:28:42 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IR8QK-0000Ve-Jg for sip-confirm+ok@megatron.ietf.org; Fri, 31 Aug 2007 11:28:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IR8QK-0000VW-9n for sip@ietf.org; Fri, 31 Aug 2007 11:28:40 -0400 Received: from jes-fe2.zx.nl ([194.187.76.133]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IR8QI-0001KQ-U8 for sip@ietf.org; Fri, 31 Aug 2007 11:28:40 -0400 Received: from Inbox ([89.205.181.144]) by jes-fe2.zx.nl (Sun Java System Messaging Server 6.2-7.05 (built Sep 5 2006)) with ESMTP id <0JNN004WI9NHLK40@jes-fe2.zx.nl> for sip@ietf.org; Fri, 31 Aug 2007 17:28:37 +0200 (CEST) Date: Fri, 31 Aug 2007 17:28:35 +0200 From: Jeroen van Bemmel Subject: RE: [Sip] INFO To: Eric Burger , Peili Xu Message-id: <0JNN004WJ9NJLK40@jes-fe2.zx.nl> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Importance: normal X-Priority: 3 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Since INFO is mid-dialog, the endpoints can signal what they support. It do= es not need to be known a priori Regards, Jeroen -----Oorspronkelijk bericht ----- Van: "Eric Burger" Aan: "Peili Xu" CC: "sip" Verzonden: 31-8-07 00:03 Onderwerp: Re: [Sip] INFO Saying, "OK for interworking" does not really say anything. If I come up with a really broken method for interworking, saying that it is for interworking does not make it correct. The problem is, how do the endpoints know they will be able to communicate? For the ISUP/Q.sig/DPNSS/mumble case, the endpoints know they will be able to interoperate because they know a'priori: they are configured to work. However, this means that the devices must be in the same administrative domain and configured properly. Said in a different manner, INFO works fine for non-inter-network use. It would be hard for the IETF to say, "Here is a non-IETF use. We will not us= e it. You cannot use it with anyone else. You cannot use it between manufacturers, unless you get them to agree to this use." That is a bit more of what we call the toxic waste warning that accompanies 3GPP specifications... On 8/27/07 8:35 AM, "Peili Xu" wrote: > Hi Eric, >=20 > Several cases I encounter to use INFO is for interworking with PSTN signa= ling, > or simulate PSTN services at SIP entities such as SIP UA or SIP GW, > which require mid-dialog information change. >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Aug 31 11:35:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IR8VB-0002Rk-Rc; Fri, 31 Aug 2007 11:33:41 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IR8V9-0002On-M6 for sip-confirm+ok@megatron.ietf.org; Fri, 31 Aug 2007 11:33:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IR8V9-0002Of-CJ for sip@ietf.org; Fri, 31 Aug 2007 11:33:39 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IR8V8-0001Sx-2Q for sip@ietf.org; Fri, 31 Aug 2007 11:33:39 -0400 Received: from repmmr01.bea.com (repmmr01.bea.com [10.160.29.71]) by repmmg02.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l7VFXUhv010133; Fri, 31 Aug 2007 08:33:30 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr01.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l7VFXSRc003719; Fri, 31 Aug 2007 08:33:29 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: RE: [Sip] INFO Date: Fri, 31 Aug 2007 08:33:19 -0700 Message-ID: In-Reply-To: <0JNN004WJ9NJLK40@jes-fe2.zx.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO Thread-Index: Acfr46MgNk1GgFw7TiWLqdE1WfghRgAAJShw References: <0JNN004WJ9NJLK40@jes-fe2.zx.nl> From: "Eric Burger" To: "Jeroen van Bemmel" , "Peili Xu" x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org *How* do they signal what they support? In an INFO? -----Original Message----- From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] Sent: Friday, August 31, 2007 11:29 AM To: Eric Burger; Peili Xu Cc: sip Subject: RE: [Sip] INFO Since INFO is mid-dialog, the endpoints can signal what they support. It does not need to be known a priori Regards, Jeroen -----Oorspronkelijk bericht ----- Van: "Eric Burger" Aan: "Peili Xu" CC: "sip" Verzonden: 31-8-07 00:03 Onderwerp: Re: [Sip] INFO Saying, "OK for interworking" does not really say anything. If I come up with a really broken method for interworking, saying that it is for interworking does not make it correct. The problem is, how do the endpoints know they will be able to communicate? For the ISUP/Q.sig/DPNSS/mumble case, the endpoints know they will be able to interoperate because they know a'priori: they are configured to work. However, this means that the devices must be in the same administrative domain and configured properly. Said in a different manner, INFO works fine for non-inter-network use. It would be hard for the IETF to say, "Here is a non-IETF use. We will not use it. You cannot use it with anyone else. You cannot use it between manufacturers, unless you get them to agree to this use." That is a bit more of what we call the toxic waste warning that accompanies 3GPP specifications... On 8/27/07 8:35 AM, "Peili Xu" wrote: > Hi Eric, > > Several cases I encounter to use INFO is for interworking with PSTN > signaling, or simulate PSTN services at SIP entities such as SIP UA or > SIP GW, which require mid-dialog information change. > Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete 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 sip-bounces@ietf.org Fri Aug 31 12:03:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IR8wM-0007yX-4d; Fri, 31 Aug 2007 12:01:46 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IR8wK-0007m5-Nd for sip-confirm+ok@megatron.ietf.org; Fri, 31 Aug 2007 12:01:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IR8wK-0007jy-B5 for sip@ietf.org; Fri, 31 Aug 2007 12:01:44 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IR8wJ-0002Fy-4K for sip@ietf.org; Fri, 31 Aug 2007 12:01:44 -0400 Received: from hkaplan [10.0.200.241] by acmepacket.com with ESMTP (SMTPD-9.10) id AB5D0270; Fri, 31 Aug 2007 12:01:33 -0400 From: "Hadriel Kaplan" To: "'Eric Burger'" , "'Jeroen van Bemmel'" , "'Peili Xu'" References: <0JNN004WJ9NJLK40@jes-fe2.zx.nl> Subject: RE: [Sip] INFO Date: Fri, 31 Aug 2007 12:01:34 -0400 Message-ID: <012801c7ebe8$34150000$6401a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Acfr46MgNk1GgFw7TiWLqdE1WfghRgAAJShwAACqRlA= In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: 'sip' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I think he's saying it's something that could be resolved by standardization. (maybe) At least the way I read your draft, the draft makes arguments against INFO of two different types, as if they were of similar weight and impact - but that's not really the case. There is one set of problems with INFO that exist because of architectural issues, which are probably not fixable, and are generally damning. There is a separate set which are problems merely because no standard exists for how to address them, but they could be resolved. This latter type is not really a "Why INFO is bad in general", as much as a "what the current problems are with INFO that we should fix if we want to keep using INFO". -hadriel > -----Original Message----- > From: Eric Burger [mailto:eburger@bea.com] > Sent: Friday, August 31, 2007 11:33 AM > To: Jeroen van Bemmel; Peili Xu > Cc: sip > Subject: RE: [Sip] INFO > > *How* do they signal what they support? In an INFO? > > -----Original Message----- > From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > Sent: Friday, August 31, 2007 11:29 AM > To: Eric Burger; Peili Xu > Cc: sip > Subject: RE: [Sip] INFO > > Since INFO is mid-dialog, the endpoints can signal what they support. It > does not need to be known a priori > > Regards, > Jeroen > > -----Oorspronkelijk bericht ----- > Van: "Eric Burger" > Aan: "Peili Xu" > CC: "sip" > Verzonden: 31-8-07 00:03 > Onderwerp: Re: [Sip] INFO > > Saying, "OK for interworking" does not really say anything. If I come > up with a really broken method for interworking, saying that it is for > interworking does not make it correct. > > The problem is, how do the endpoints know they will be able to > communicate? > For the ISUP/Q.sig/DPNSS/mumble case, the endpoints know they will be > able to interoperate because they know a'priori: they are configured to > work. > However, this means that the devices must be in the same administrative > domain and configured properly. > > Said in a different manner, INFO works fine for non-inter-network use. > It would be hard for the IETF to say, "Here is a non-IETF use. We will > not use it. You cannot use it with anyone else. You cannot use it > between manufacturers, unless you get them to agree to this use." That > is a bit more of what we call the toxic waste warning that accompanies > 3GPP specifications... > > > On 8/27/07 8:35 AM, "Peili Xu" wrote: > > > Hi Eric, > > > > Several cases I encounter to use INFO is for interworking with PSTN > > signaling, or simulate PSTN services at SIP entities such as SIP UA or > > > SIP GW, which require mid-dialog information change. > > > > > Notice: This email message, together with any attachments, may contain > information of BEA Systems, Inc., its subsidiaries and affiliated > entities, that may be confidential, proprietary, copyrighted and/or > legally privileged, and is intended solely for the use of the individual > or entity named in this message. If you are not the intended recipient, > and have received this message in error, please immediately return this by > email and then delete 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip