From abhatnagar192006@gmail.com Sat Aug 1 06:47:52 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D3893A684C for ; Sat, 1 Aug 2009 06:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3X3RRdFRvfYw for ; Sat, 1 Aug 2009 06:47:51 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.240]) by core3.amsl.com (Postfix) with ESMTP id 22BB43A682D for ; Sat, 1 Aug 2009 06:47:50 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id c37so1242004anc.4 for ; Sat, 01 Aug 2009 06:47:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type; bh=Ku8R+OVLwDzs2KqtSiN2pLRk8p9FLIBFAED0J0bgRso=; b=v2qU2d0bped6r8046Rct9l/IzMdfvsLImyYUS1/oZDKgiimg0CszUw4h1KEC7ge8n+ axiaU4X0RiRSso7y+eBa8ziN/p2e/cb6NmTF8w+viEBByxdxFlmFxU/J4c0aw4hsCnUY WagERZ25nHymCfEMLNQ37IkaoKfNkpvmGnPi4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=k4FmRNkOWi0mOdFFJAVa8zwwEAVHA12lFb87uCCGUzYc81MkmgWaqJC76EJYPbjnmN 6AXGJER3pcO0zJ7f2NlCevBx6s+cEjRe0HubLDGsrqUd9IimvCRXH19rVoaqUK5+yUEr iOWvIZOwslc24IiZYv2is989BJ4h0gg7yfAPM= MIME-Version: 1.0 Received: by 10.100.196.17 with SMTP id t17mr3975428anf.20.1249134471127; Sat, 01 Aug 2009 06:47:51 -0700 (PDT) In-Reply-To: <5F063FC3F0C8F14E945465A68E63C43E9451DB@ex3-del1.synapse.com> References: <5F063FC3F0C8F14E945465A68E63C43E9451DB@ex3-del1.synapse.com> From: aayush bhatnagar Date: Sat, 1 Aug 2009 19:17:31 +0530 Message-ID: To: Karunesh Sharma Content-Type: multipart/alternative; boundary=0016e645a3d86da50b047014c8c1 Cc: sip@ietf.org Subject: Re: [Sip] SIP Dialog Match X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Aug 2009 13:47:52 -0000 --0016e645a3d86da50b047014c8c1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable It is possible..and is standardized. 'C' can 'logically' Join an existing dialog between 'A' (UAC) and 'B' (UAS), by including a Join header in the INVITE request. It may be a security concern to allow C to Join the existing dialog, but it can be a way to implement a call screening server (call tapping) for lawful interception services. For more details look here: http://www.rfc-editor.org/rfc/rfc3911.txt On Thu, Jul 30, 2009 at 09:28, Karunesh Sharma < Karunesh.Sharma@globallogic.com> wrote: > List: > > > > I am having a question about SIP dialog validation using src/dst ip. If > there is established sip dialog between =91A=92 & =91B=92 then can =91C= =92 who is not > party to existing dialog and who somehow knows all sip dialog identifiers > (Call-ID, To/From Tags) of the dialog between =91A=92 & =91B=92, sends ta= rget > refresh request with its own IP in contact. This is a typical call hijack= ing > case. If this is valid how to avoid that? Is Authentication is only way o= ut > or do we have other alternate as well? > > > > I didn=92t find anything on this in 3261 or other related RFCs. > > > > Thanks > > > > K$ > > _______________________ > > > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 aayush ---------------------------------------------------- "A philosopher always knows what to do...until it happens to him" --0016e645a3d86da50b047014c8c1 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable It is possible..and is standardized. 'C' can 'logically' Jo= in an existing dialog between 'A' (UAC) and 'B' (UAS), by i= ncluding a Join header in the INVITE request.

It may be = a security concern to allow C to Join the existing dialog, but it can be a = way to implement a call screening server (call tapping) for lawful intercep= tion services.

For more details look here:=A0http://www.rfc-editor.org/rfc/rfc3911.txt<= /div>

On Thu, Jul 30, 2009 at 09:28, Karunesh Sharma <Karunesh.Sharma@globallogic.co= m> wrote:

List:

=A0

I am having a question about SIP dialog validation using src/dst ip. If there is establis= hed sip dialog between =91A=92 & =91B=92 then can =91C=92 who is not party = to existing dialog and who somehow knows all sip dialog identifiers (Call-ID, To/From T= ags) of the dialog between =91A=92 & =91B=92, sends target refresh request w= ith its own IP in contact. This is a typical call hijacking case. If this is valid how = to avoid that? Is Authentication is only way out or do we have other alternate= as well?

=A0

I didn=92t find anything on this in 3261 or other related RFCs.

=A0

Thanks

=A0

K$

_______________________

=A0


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



--
aayush
----------------------------------------------------=
"A philosopher always knows what to do...until it happens to him"=
--0016e645a3d86da50b047014c8c1-- From dworley@nortel.com Sun Aug 2 14:41:26 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84B7B3A6857 for ; Sun, 2 Aug 2009 14:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.512 X-Spam-Level: X-Spam-Status: No, score=-6.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M3+XVec6buQt for ; Sun, 2 Aug 2009 14:41:25 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id DC8463A6BC4 for ; Sun, 2 Aug 2009 14:41:24 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n72LfJq15917; Sun, 2 Aug 2009 21:41:19 GMT Received: from [47.141.31.165] ([47.141.31.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 2 Aug 2009 17:41:18 -0400 From: "Dale Worley" To: aayush bhatnagar In-Reply-To: References: <5F063FC3F0C8F14E945465A68E63C43E9451DB@ex3-del1.synapse.com> Content-Type: text/plain; charset=utf-8 Organization: Nortel Networks Date: Sun, 02 Aug 2009 17:41:17 -0400 Message-Id: <1249249277.4106.1.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 02 Aug 2009 21:41:18.0351 (UTC) FILETIME=[F7F6E1F0:01CA13B9] Cc: sip@ietf.org, Karunesh Sharma Subject: Re: [Sip] SIP Dialog Match X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Aug 2009 21:41:26 -0000 > On Thu, Jul 30, 2009 at 09:28, Karunesh Sharma > wrote: > I am having a question about SIP dialog validation using > src/dst ip. If there is established sip dialog between =E2=80=98A= =E2=80=99 & > =E2=80=98B=E2=80=99 then can =E2=80=98C=E2=80=99 who is not party= to existing dialog and who > somehow knows all sip dialog identifiers (Call-ID, To/From > Tags) of the dialog between =E2=80=98A=E2=80=99 & =E2=80=98B=E2= =80=99, sends target refresh > request with its own IP in contact. This is a typical call > hijacking case. If this is valid how to avoid that? Is > Authentication is only way out or do we have other alternate > as well? For "basic" security, it is usually assumed that if an agent knows the dialog identifiers, then it has the right to manipulate the dialog. (See, e.g., the Replace and Join headers.) For stricter security, additional authentication mechanisms have to be deployed, but the IETF has not standardized any such mechanism. Dale From Karunesh.Sharma@globallogic.com Mon Aug 3 08:20:30 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CAB53A698A for ; Mon, 3 Aug 2009 08:20:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 64wldhHZAOZP for ; Mon, 3 Aug 2009 08:20:29 -0700 (PDT) Received: from emailsecurity-del1-1.globallogic.com (mx-del1-1.globallogic.com [202.174.92.25]) by core3.amsl.com (Postfix) with ESMTP id 69B2C3A6B6E for ; Mon, 3 Aug 2009 08:19:27 -0700 (PDT) Received: from emailsecurity-del1-1.globallogic.com (127.0.0.1) by emailsecurity-del1-1.globallogic.com (MlfMTA v3.2r9) id hervs20171su for ; Mon, 3 Aug 2009 20:48:22 +0530 (envelope-from ) Received: from ex3-del1.synapse.com ([172.16.2.34]) by emailsecurity-del1-1.globallogic.com (SonicWALL 7.0.1.1499) with ESMTP; Mon, 03 Aug 2009 20:48:22 +0530 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Mon, 3 Aug 2009 20:49:24 +0530 Message-ID: <5F063FC3F0C8F14E945465A68E63C43E945346@ex3-del1.synapse.com> In-Reply-To: <1249249277.4106.1.camel@victoria-pingtel-com.us.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] SIP Dialog Match Thread-Index: AcoTufx1ltplcvQKS2iTuHXoGTXUCQAk5JyA References: <5F063FC3F0C8F14E945465A68E63C43E9451DB@ex3-del1.synapse.com> <1249249277.4106.1.camel@victoria-pingtel-com.us.nortel.com> From: "Karunesh Sharma" To: "Dale Worley" , "aayush bhatnagar" X-Mlf-Version: 7.0.1.1499 X-Mlf-UniqueId: o200908031518220032504 Cc: sip@ietf.org Subject: Re: [Sip] SIP Dialog Match X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 15:20:30 -0000 V2hhdCBhYm91dCBzZW5kaW5nIElOVklURSB0byAnQicgJiBnZXR0aW5nIGFsbCByZXNwb25zZXMg KHdoaWNoIGluY2x1ZGVzIHByb3Zpc2lvbmFsIHJlc3BvbnNlIDF4eCkgZnJvbSAnQyc/DQoNCksk DQpfX19fX19fX19fX19fX19fX19fX19fXw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K RnJvbTogRGFsZSBXb3JsZXkgW21haWx0bzpkd29ybGV5QG5vcnRlbC5jb21dIA0KU2VudDogTW9u ZGF5LCBBdWd1c3QgMDMsIDIwMDkgMzoxMSBBTQ0KVG86IGFheXVzaCBiaGF0bmFnYXINCkNjOiBL YXJ1bmVzaCBTaGFybWE7IHNpcEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtTaXBdIFNJUCBEaWFs b2cgTWF0Y2gNCg0KDQo+IE9uIFRodSwgSnVsIDMwLCAyMDA5IGF0IDA5OjI4LCBLYXJ1bmVzaCBT aGFybWENCj4gPEthcnVuZXNoLlNoYXJtYUBnbG9iYWxsb2dpYy5jb20+IHdyb3RlOg0KDQo+ICAg ICAgICAgSSBhbSBoYXZpbmcgYSBxdWVzdGlvbiBhYm91dCBTSVAgZGlhbG9nIHZhbGlkYXRpb24g dXNpbmcNCj4gICAgICAgICBzcmMvZHN0IGlwLiBJZiB0aGVyZSBpcyBlc3RhYmxpc2hlZCBzaXAg ZGlhbG9nIGJldHdlZW4g4oCYQeKAmSAmDQo+ICAgICAgICAg4oCYQuKAmSB0aGVuIGNhbiDigJhD 4oCZIHdobyBpcyBub3QgcGFydHkgdG8gZXhpc3RpbmcgZGlhbG9nIGFuZCB3aG8NCj4gICAgICAg ICBzb21laG93IGtub3dzIGFsbCBzaXAgZGlhbG9nIGlkZW50aWZpZXJzIChDYWxsLUlELCBUby9G cm9tDQo+ICAgICAgICAgVGFncykgb2YgdGhlIGRpYWxvZyBiZXR3ZWVuIOKAmEHigJkgJiDigJhC 4oCZLCBzZW5kcyB0YXJnZXQgcmVmcmVzaA0KPiAgICAgICAgIHJlcXVlc3Qgd2l0aCBpdHMgb3du IElQIGluIGNvbnRhY3QuIFRoaXMgaXMgYSB0eXBpY2FsIGNhbGwNCj4gICAgICAgICBoaWphY2tp bmcgY2FzZS4gSWYgdGhpcyBpcyB2YWxpZCBob3cgdG8gYXZvaWQgdGhhdD8gSXMNCj4gICAgICAg ICBBdXRoZW50aWNhdGlvbiBpcyBvbmx5IHdheSBvdXQgb3IgZG8gd2UgaGF2ZSBvdGhlciBhbHRl cm5hdGUNCj4gICAgICAgICBhcyB3ZWxsPw0KDQpGb3IgImJhc2ljIiBzZWN1cml0eSwgaXQgaXMg dXN1YWxseSBhc3N1bWVkIHRoYXQgaWYgYW4gYWdlbnQga25vd3MgdGhlDQpkaWFsb2cgaWRlbnRp ZmllcnMsIHRoZW4gaXQgaGFzIHRoZSByaWdodCB0byBtYW5pcHVsYXRlIHRoZSBkaWFsb2cuDQoo U2VlLCBlLmcuLCB0aGUgUmVwbGFjZSBhbmQgSm9pbiBoZWFkZXJzLikgIEZvciBzdHJpY3RlciBz ZWN1cml0eSwNCmFkZGl0aW9uYWwgYXV0aGVudGljYXRpb24gbWVjaGFuaXNtcyBoYXZlIHRvIGJl IGRlcGxveWVkLCBidXQgdGhlIElFVEYNCmhhcyBub3Qgc3RhbmRhcmRpemVkIGFueSBzdWNoIG1l Y2hhbmlzbS4NCg0KRGFsZQ0KDQoNCg0K From dworley@nortel.com Mon Aug 3 08:25:06 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B66A3A6CD9 for ; Mon, 3 Aug 2009 08:25:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ruznWOlw8T-m for ; Mon, 3 Aug 2009 08:25:05 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 37A143A6D80 for ; Mon, 3 Aug 2009 08:25:04 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n73FMup03932; Mon, 3 Aug 2009 15:22:56 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Aug 2009 11:24:48 -0400 From: "Dale Worley" To: Karunesh Sharma In-Reply-To: <5F063FC3F0C8F14E945465A68E63C43E945346@ex3-del1.synapse.com> References: <5F063FC3F0C8F14E945465A68E63C43E9451DB@ex3-del1.synapse.com> <1249249277.4106.1.camel@victoria-pingtel-com.us.nortel.com> <5F063FC3F0C8F14E945465A68E63C43E945346@ex3-del1.synapse.com> Content-Type: text/plain Organization: Nortel Networks Date: Mon, 03 Aug 2009 11:24:48 -0400 Message-Id: <1249313088.3791.0.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Aug 2009 15:24:48.0781 (UTC) FILETIME=[89F1CBD0:01CA144E] Cc: sip@ietf.org Subject: Re: [Sip] SIP Dialog Match X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 15:25:06 -0000 On Mon, 2009-08-03 at 20:49 +0530, Karunesh Sharma wrote: > What about sending INVITE to 'B' & getting all responses (which > includes provisional response 1xx) from 'C'? I'm not sure what you mean. Dale From Karunesh.Sharma@globallogic.com Mon Aug 3 08:34:10 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 577823A67DB for ; Mon, 3 Aug 2009 08:34:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.255 X-Spam-Level: X-Spam-Status: No, score=-2.255 tagged_above=-999 required=5 tests=[AWL=0.345, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LaoC8+F6FO3q for ; Mon, 3 Aug 2009 08:34:09 -0700 (PDT) Received: from emailsecurity-del1-1.globallogic.com (mx-del1-1.globallogic.com [202.174.92.25]) by core3.amsl.com (Postfix) with ESMTP id 1E94F3A6E34 for ; Mon, 3 Aug 2009 08:33:49 -0700 (PDT) Received: from emailsecurity-del1-1.globallogic.com (127.0.0.1) by emailsecurity-del1-1.globallogic.com (MlfMTA v3.2r9) id hes1hs0171sk for ; Mon, 3 Aug 2009 21:02:43 +0530 (envelope-from ) Received: from ex3-del1.synapse.com ([172.16.2.34]) by emailsecurity-del1-1.globallogic.com (SonicWALL 7.0.1.1499) with ESMTP; Mon, 03 Aug 2009 21:02:41 +0530 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: Mon, 3 Aug 2009 21:03:36 +0530 Message-ID: <5F063FC3F0C8F14E945465A68E63C43E945347@ex3-del1.synapse.com> In-Reply-To: <1249313088.3791.0.camel@victoria-pingtel-com.us.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] SIP Dialog Match Thread-Index: AcoUTpRNgqxavu1pRLuBeOzVEaTEVQAALElw References: <5F063FC3F0C8F14E945465A68E63C43E9451DB@ex3-del1.synapse.com> <1249249277.4106.1.camel@victoria-pingtel-com.us.nortel.com> <5F063FC3F0C8F14E945465A68E63C43E945346@ex3-del1.synapse.com> <1249313088.3791.0.camel@victoria-pingtel-com.us.nortel.com> From: "Karunesh Sharma" To: "Dale Worley" X-Mlf-Version: 7.0.1.1499 X-Mlf-UniqueId: o200908031532410035736 Cc: sip@ietf.org Subject: Re: [Sip] SIP Dialog Match X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 15:34:10 -0000 Dale: Please see following trace 172.16.31.30 -> 10.0.4.6 SIP/SDP Request: INVITE sip:23235556@10.0.4.6, with session description 192.168.4.67 -> 172.16.31.30 SIP Status: 100 Trying 192.168.4.67 -> 172.16.31.30 SIP/SDP Status: 183 Session Progress, with session description 172.16.31.30 -> 192.168.4.67 SIP Request: PRACK sip:23235556@192.168.4.67:5060 192.168.4.67 -> 172.16.31.30 SIP Status: 200 OK 192.168.4.67 -> 172.16.31.30 SIP/SDP Status: 200 OK, with session description 172.16.31.30 -> 192.168.4.67 SIP Request: ACK sip:23235556@192.168.4.67:5060 192.168.4.67 -> 172.16.31.30 SIP Request: BYE sip:24098955@172.16.31.30:5060 172.16.31.30 (read as 'A') sent INVITE to 10.0.4.6 (read as 'B'). But somehow 192.168.4.67 (read as 'C') responds. Now 'A' knows nothing about 'C', but still based on SIP dialog identifiers 'A' accepts that. So is there any way to challenge or deny such rouge responses? I was reading one draft (http://ietfreport.isoc.org/idref/draft-cao-sip-response-identity/) but that is expired. K$ _______________________ -----Original Message----- From: Dale Worley [mailto:dworley@nortel.com]=20 Sent: Monday, August 03, 2009 8:55 PM To: Karunesh Sharma Cc: aayush bhatnagar; sip@ietf.org Subject: RE: [Sip] SIP Dialog Match On Mon, 2009-08-03 at 20:49 +0530, Karunesh Sharma wrote: > What about sending INVITE to 'B' & getting all responses (which > includes provisional response 1xx) from 'C'? I'm not sure what you mean. Dale From dworley@nortel.com Mon Aug 3 08:46:47 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E76A3A6E56 for ; Mon, 3 Aug 2009 08:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e2hAsLGDKR8W for ; Mon, 3 Aug 2009 08:46:46 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 9322B3A6E50 for ; Mon, 3 Aug 2009 08:46:46 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n73Fkda25427; Mon, 3 Aug 2009 15:46:39 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Aug 2009 11:46:39 -0400 From: "Dale Worley" To: Karunesh Sharma In-Reply-To: <5F063FC3F0C8F14E945465A68E63C43E945347@ex3-del1.synapse.com> References: <5F063FC3F0C8F14E945465A68E63C43E9451DB@ex3-del1.synapse.com> <1249249277.4106.1.camel@victoria-pingtel-com.us.nortel.com> <5F063FC3F0C8F14E945465A68E63C43E945346@ex3-del1.synapse.com> <1249313088.3791.0.camel@victoria-pingtel-com.us.nortel.com> <5F063FC3F0C8F14E945465A68E63C43E945347@ex3-del1.synapse.com> Content-Type: text/plain Organization: Nortel Networks Date: Mon, 03 Aug 2009 11:46:38 -0400 Message-Id: <1249314398.3791.5.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Aug 2009 15:46:39.0673 (UTC) FILETIME=[974C0A90:01CA1451] Cc: sip@ietf.org Subject: Re: [Sip] SIP Dialog Match X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 15:46:47 -0000 On Mon, 2009-08-03 at 21:03 +0530, Karunesh Sharma wrote: > 172.16.31.30 (read as 'A') sent INVITE to 10.0.4.6 (read as 'B'). But > somehow 192.168.4.67 (read as 'C') responds. Now 'A' knows nothing about > 'C', but still based on SIP dialog identifiers 'A' accepts that. > > So is there any way to challenge or deny such rouge responses? Have you inquired as to how C knows of the dialog identifiers, and why it is sending the responses? Dale From dworley@nortel.com Mon Aug 3 09:02:45 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1C9428C193 for ; Mon, 3 Aug 2009 09:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pivE7jFjHHro for ; Mon, 3 Aug 2009 09:02:45 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 0179528C1C9 for ; Mon, 3 Aug 2009 09:02:44 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n73G2da02237; Mon, 3 Aug 2009 16:02:39 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Aug 2009 12:02:38 -0400 From: "Dale Worley" To: Karunesh Sharma In-Reply-To: <5F063FC3F0C8F14E945465A68E63C43E945349@ex3-del1.synapse.com> References: <5F063FC3F0C8F14E945465A68E63C43E9451DB@ex3-del1.synapse.com> <1249249277.4106.1.camel@victoria-pingtel-com.us.nortel.com> <5F063FC3F0C8F14E945465A68E63C43E945346@ex3-del1.synapse.com> <1249313088.3791.0.camel@victoria-pingtel-com.us.nortel.com> <5F063FC3F0C8F14E945465A68E63C43E945347@ex3-del1.synapse.com> <1249314398.3791.5.camel@victoria-pingtel-com.us.nortel.com> <5F063FC3F0C8F14E945465A68E63C43E945349@ex3-del1.synapse.com> Content-Type: text/plain Organization: Nortel Networks Date: Mon, 03 Aug 2009 12:02:37 -0400 Message-Id: <1249315357.3791.7.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Aug 2009 16:02:38.0604 (UTC) FILETIME=[D2DD4CC0:01CA1453] Cc: sip@ietf.org Subject: Re: [Sip] SIP Dialog Match X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 16:02:45 -0000 On Mon, 2009-08-03 at 21:21 +0530, Karunesh Sharma wrote: > I am trying to get that info how 'C' has this dialog identifiers but I > was wondering this as a major security issue for any SIP network. If C can obtain the dialog identifiers but it is not supposed to be participating in the dialog, then that is a major security issue. Dale From dworley@nortel.com Mon Aug 3 09:04:57 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 583A728C0ED for ; Mon, 3 Aug 2009 09:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hqAJKuV7fPYq for ; Mon, 3 Aug 2009 09:04:56 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 6025C28C0FA for ; Mon, 3 Aug 2009 09:04:56 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n73G2vp13375; Mon, 3 Aug 2009 16:02:58 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Aug 2009 12:04:49 -0400 From: "Dale Worley" To: Karunesh Sharma In-Reply-To: <5F063FC3F0C8F14E945465A68E63C43E94534A@ex3-del1.synapse.com> References: <5F063FC3F0C8F14E945465A68E63C43E9451DB@ex3-del1.synapse.com> <1249249277.4106.1.camel@victoria-pingtel-com.us.nortel.com> <5F063FC3F0C8F14E945465A68E63C43E945346@ex3-del1.synapse.com> <1249313088.3791.0.camel@victoria-pingtel-com.us.nortel.com> <5F063FC3F0C8F14E945465A68E63C43E945347@ex3-del1.synapse.com> <1249314398.3791.5.camel@victoria-pingtel-com.us.nortel.com> <5F063FC3F0C8F14E945465A68E63C43E94534A@ex3-del1.synapse.com> Content-Type: text/plain Organization: Nortel Networks Date: Mon, 03 Aug 2009 12:04:49 -0400 Message-Id: <1249315489.3791.10.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Aug 2009 16:04:50.0029 (UTC) FILETIME=[213329D0:01CA1454] Cc: sip@ietf.org Subject: Re: [Sip] SIP Dialog Match X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 16:04:57 -0000 On Mon, 2009-08-03 at 21:28 +0530, Karunesh Sharma wrote: > Is this a valid behavior for scenario like 'Call-Forwarding'? In principle, the responses to a request should almost always come from the address to which the request was sent. But that is not usually enforced, and there may be good reasons why it isn't happening in a particular instance. In regard to an observed instance of this behavior, you must first determine the complete routing of the request in question and the reason for each routing step. Dale From Karunesh.Sharma@globallogic.com Mon Aug 3 09:22:30 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44AA728C1FD for ; Mon, 3 Aug 2009 09:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zLf-vTqkXW5k for ; Mon, 3 Aug 2009 09:22:29 -0700 (PDT) Received: from emailsecurity-del1-1.globallogic.com (mx-del1-1.globallogic.com [202.174.92.25]) by core3.amsl.com (Postfix) with ESMTP id 2D64628C1FF for ; Mon, 3 Aug 2009 09:22:28 -0700 (PDT) Received: from emailsecurity-del1-1.globallogic.com (127.0.0.1) by emailsecurity-del1-1.globallogic.com (MlfMTA v3.2r9) id hes78c0171sr for ; Mon, 3 Aug 2009 21:27:38 +0530 (envelope-from ) Received: from ex3-del1.synapse.com ([172.16.2.34]) by emailsecurity-del1-1.globallogic.com (SonicWALL 7.0.1.1499) with ESMTP; Mon, 03 Aug 2009 21:27:37 +0530 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: Mon, 3 Aug 2009 21:28:43 +0530 Message-ID: <5F063FC3F0C8F14E945465A68E63C43E94534A@ex3-del1.synapse.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] SIP Dialog Match Thread-Index: AcoUUZwEZrr9UtC8RwaZmKpaij2yeAAAG8zAAABKuFA= References: <5F063FC3F0C8F14E945465A68E63C43E9451DB@ex3-del1.synapse.com> <1249249277.4106.1.camel@victoria-pingtel-com.us.nortel.com> <5F063FC3F0C8F14E945465A68E63C43E945346@ex3-del1.synapse.com> <1249313088.3791.0.camel@victoria-pingtel-com.us.nortel.com> <5F063FC3F0C8F14E945465A68E63C43E945347@ex3-del1.synapse.com> <1249314398.3791.5.camel@victoria-pingtel-com.us.nortel.com> From: "Karunesh Sharma" To: "Dale Worley" X-Mlf-Version: 7.0.1.1499 X-Mlf-UniqueId: o200908031557370040314 Cc: sip@ietf.org Subject: Re: [Sip] SIP Dialog Match X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 16:22:30 -0000 Is this a valid behavior for scenario like 'Call-Forwarding'? K$ _______________________ -----Original Message----- From: Karunesh Sharma=20 Sent: Monday, August 03, 2009 9:22 PM To: 'Dale Worley' Cc: aayush bhatnagar; sip@ietf.org Subject: RE: [Sip] SIP Dialog Match I am trying to get that info how 'C' has this dialog identifiers but I was wondering this as a major security issue for any SIP network. K$ _______________________ -----Original Message----- From: Dale Worley [mailto:dworley@nortel.com]=20 Sent: Monday, August 03, 2009 9:17 PM To: Karunesh Sharma Cc: aayush bhatnagar; sip@ietf.org Subject: RE: [Sip] SIP Dialog Match On Mon, 2009-08-03 at 21:03 +0530, Karunesh Sharma wrote: > 172.16.31.30 (read as 'A') sent INVITE to 10.0.4.6 (read as 'B'). But > somehow 192.168.4.67 (read as 'C') responds. Now 'A' knows nothing about > 'C', but still based on SIP dialog identifiers 'A' accepts that. >=20 > So is there any way to challenge or deny such rouge responses? Have you inquired as to how C knows of the dialog identifiers, and why it is sending the responses? Dale From Karunesh.Sharma@globallogic.com Mon Aug 3 09:22:32 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A75EF28C0ED for ; Mon, 3 Aug 2009 09:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[AWL=0.268, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qnhRkNw0-aTM for ; Mon, 3 Aug 2009 09:22:32 -0700 (PDT) Received: from emailsecurity-del1-1.globallogic.com (mx-del1-1.globallogic.com [202.174.92.25]) by core3.amsl.com (Postfix) with ESMTP id 80B1E28C229 for ; Mon, 3 Aug 2009 09:22:31 -0700 (PDT) Received: from emailsecurity-del1-1.globallogic.com (127.0.0.1) by emailsecurity-del1-1.globallogic.com (MlfMTA v3.2r9) id hes78g0171s7 for ; Mon, 3 Aug 2009 21:20:38 +0530 (envelope-from ) Received: from ex3-del1.synapse.com ([172.16.2.34]) by emailsecurity-del1-1.globallogic.com (SonicWALL 7.0.1.1499) with ESMTP; Mon, 03 Aug 2009 21:20:37 +0530 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: Mon, 3 Aug 2009 21:21:43 +0530 Message-ID: <5F063FC3F0C8F14E945465A68E63C43E945349@ex3-del1.synapse.com> In-Reply-To: <1249314398.3791.5.camel@victoria-pingtel-com.us.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] SIP Dialog Match Thread-Index: AcoUUZwEZrr9UtC8RwaZmKpaij2yeAAAG8zA References: <5F063FC3F0C8F14E945465A68E63C43E9451DB@ex3-del1.synapse.com> <1249249277.4106.1.camel@victoria-pingtel-com.us.nortel.com> <5F063FC3F0C8F14E945465A68E63C43E945346@ex3-del1.synapse.com> <1249313088.3791.0.camel@victoria-pingtel-com.us.nortel.com> <5F063FC3F0C8F14E945465A68E63C43E945347@ex3-del1.synapse.com> <1249314398.3791.5.camel@victoria-pingtel-com.us.nortel.com> From: "Karunesh Sharma" To: "Dale Worley" X-Mlf-Version: 7.0.1.1499 X-Mlf-UniqueId: o200908031550370039269 Cc: sip@ietf.org Subject: Re: [Sip] SIP Dialog Match X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 16:22:32 -0000 I am trying to get that info how 'C' has this dialog identifiers but I was wondering this as a major security issue for any SIP network. K$ _______________________ -----Original Message----- From: Dale Worley [mailto:dworley@nortel.com]=20 Sent: Monday, August 03, 2009 9:17 PM To: Karunesh Sharma Cc: aayush bhatnagar; sip@ietf.org Subject: RE: [Sip] SIP Dialog Match On Mon, 2009-08-03 at 21:03 +0530, Karunesh Sharma wrote: > 172.16.31.30 (read as 'A') sent INVITE to 10.0.4.6 (read as 'B'). But > somehow 192.168.4.67 (read as 'C') responds. Now 'A' knows nothing about > 'C', but still based on SIP dialog identifiers 'A' accepts that. >=20 > So is there any way to challenge or deny such rouge responses? Have you inquired as to how C knows of the dialog identifiers, and why it is sending the responses? Dale From satyanarayana.t@motorola.com Mon Aug 3 09:35:00 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8A9728C1DB for ; Mon, 3 Aug 2009 09:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M-goKrc8PKeR for ; Mon, 3 Aug 2009 09:35:00 -0700 (PDT) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with ESMTP id 95C0728C28F for ; Mon, 3 Aug 2009 09:32:16 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: satyanarayana.t@motorola.com X-Msg-Ref: server-5.tower-153.messagelabs.com!1249317123!8257859!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 13447 invoked from network); 3 Aug 2009 16:32:04 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-5.tower-153.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 Aug 2009 16:32:04 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.14.3/8.14.3) with ESMTP id n73GW3fW013198 for ; Mon, 3 Aug 2009 09:32:03 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id n73GW3d6011069 for ; Mon, 3 Aug 2009 11:32:03 -0500 (CDT) Received: from ZMY16EXM67.ds.mot.com (zmy16exm67.ap.mot.com [10.179.4.27]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id n73GW1G4011061 for ; Mon, 3 Aug 2009 11:32:02 -0500 (CDT) 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: Tue, 4 Aug 2009 00:31:37 +0800 Message-ID: <3100473D52017B48B9068E079BE2A6E603FC10C6@ZMY16EXM67.ds.mot.com> In-Reply-To: <1249315489.3791.10.camel@victoria-pingtel-com.us.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] SIP Dialog Match Thread-Index: AcoUVDPfNaKNlIWVSVW07t6UXWMgGgAAuDRQ References: <5F063FC3F0C8F14E945465A68E63C43E9451DB@ex3-del1.synapse.com><1249249277.4106.1.camel@victoria-pingtel-com.us.nortel.com><5F063FC3F0C8F14E945465A68E63C43E945346@ex3-del1.synapse.com><1249313088.3791.0.camel@victoria-pingtel-com.us.nortel.com><5F063FC3F0C8F14E945465A68E63C43E945347@ex3-del1.synapse.com><1249314398.3791.5.camel@victoria-pingtel-com.us.nortel.com><5F063FC3F0C8F14E945465A68E63C43E94534A@ex3-del1.synapse.com> <1249315489.3791.10.camel@victoria-pingtel-com.us.nortel.com> From: "T Satyanarayana-A12694" To: "Dale Worley" , "Karunesh Sharma" X-CFilter-Loop: Reflected Cc: sip@ietf.org Subject: Re: [Sip] SIP Dialog Match X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 16:35:00 -0000 In short, if some one wants to fake another client, it is possible since the communication is in clear. If there are security concerns, then security mechanisms (privacy etc) should be used. -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Dale Worley Sent: Monday, August 03, 2009 9:35 PM To: Karunesh Sharma Cc: sip@ietf.org Subject: Re: [Sip] SIP Dialog Match On Mon, 2009-08-03 at 21:28 +0530, Karunesh Sharma wrote: > Is this a valid behavior for scenario like 'Call-Forwarding'? In principle, the responses to a request should almost always come from the address to which the request was sent. But that is not usually enforced, and there may be good reasons why it isn't happening in a particular instance. In regard to an observed instance of this behavior, you must first determine the complete routing of the request in question and the reason for each routing step. Dale _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From Karunesh.Sharma@globallogic.com Mon Aug 3 09:37:42 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 580C728C25F for ; Mon, 3 Aug 2009 09:37:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.358 X-Spam-Level: X-Spam-Status: No, score=-2.358 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id spNK0NWQeTJF for ; Mon, 3 Aug 2009 09:37:41 -0700 (PDT) Received: from emailsecurity-del1-1.globallogic.com (mx-del1-1.globallogic.com [202.174.92.25]) by core3.amsl.com (Postfix) with ESMTP id C186828C1D0 for ; Mon, 3 Aug 2009 09:35:06 -0700 (PDT) Received: from emailsecurity-del1-1.globallogic.com (127.0.0.1) by emailsecurity-del1-1.globallogic.com (MlfMTA v3.2r9) id hes8nm0171sh for ; Mon, 3 Aug 2009 22:04:02 +0530 (envelope-from ) Received: from ex3-del1.synapse.com ([172.16.2.34]) by emailsecurity-del1-1.globallogic.com (SonicWALL 7.0.1.1499) with ESMTP; Mon, 03 Aug 2009 22:04:02 +0530 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: Mon, 3 Aug 2009 22:05:00 +0530 Message-ID: <5F063FC3F0C8F14E945465A68E63C43E94534B@ex3-del1.synapse.com> In-Reply-To: <3100473D52017B48B9068E079BE2A6E603FC10C6@ZMY16EXM67.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] SIP Dialog Match Thread-Index: AcoUVDPfNaKNlIWVSVW07t6UXWMgGgAAuDRQAABKnlA= References: <5F063FC3F0C8F14E945465A68E63C43E9451DB@ex3-del1.synapse.com><1249249277.4106.1.camel@victoria-pingtel-com.us.nortel.com><5F063FC3F0C8F14E945465A68E63C43E945346@ex3-del1.synapse.com><1249313088.3791.0.camel@victoria-pingtel-com.us.nortel.com><5F063FC3F0C8F14E945465A68E63C43E945347@ex3-del1.synapse.com><1249314398.3791.5.camel@victoria-pingtel-com.us.nortel.com><5F063FC3F0C8F14E945465A68E63C43E94534A@ex3-del1.synapse.com> <1249315489.3791.10.camel@victoria-pingtel-com.us.nortel.com> <3100473D52017B48B9068E079BE2A6E603FC10C6@ZMY16EXM67.ds.mot.com> From: "Karunesh Sharma" To: "T Satyanarayana-A12694" , "Dale Worley" X-Mlf-Version: 7.0.1.1499 X-Mlf-UniqueId: o200908031634020045235 Cc: sip@ietf.org Subject: Re: [Sip] SIP Dialog Match X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 16:37:42 -0000 Are you talking about *privacy* headers? I fail to understand here how *privacy* header will help in such cases. K$ _______________________ -----Original Message----- From: T Satyanarayana-A12694 [mailto:satyanarayana.t@motorola.com]=20 Sent: Monday, August 03, 2009 10:02 PM To: Dale Worley; Karunesh Sharma Cc: sip@ietf.org Subject: RE: [Sip] SIP Dialog Match In short, if some one wants to fake another client, it is possible since the communication is in clear. If there are security concerns, then security mechanisms (privacy etc) should be used. -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Dale Worley Sent: Monday, August 03, 2009 9:35 PM To: Karunesh Sharma Cc: sip@ietf.org Subject: Re: [Sip] SIP Dialog Match On Mon, 2009-08-03 at 21:28 +0530, Karunesh Sharma wrote: > Is this a valid behavior for scenario like 'Call-Forwarding'? In principle, the responses to a request should almost always come from the address to which the request was sent. But that is not usually enforced, and there may be good reasons why it isn't happening in a particular instance. In regard to an observed instance of this behavior, you must first determine the complete routing of the request in question and the reason for each routing step. Dale _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From satyanarayana.t@motorola.com Mon Aug 3 09:38:24 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 285A628C288 for ; Mon, 3 Aug 2009 09:38:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mozo4ofNmgfn for ; Mon, 3 Aug 2009 09:38:23 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by core3.amsl.com (Postfix) with ESMTP id F413028C2FF for ; Mon, 3 Aug 2009 09:37:11 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: satyanarayana.t@motorola.com X-Msg-Ref: server-14.tower-119.messagelabs.com!1249317433!40483503!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 3694 invoked from network); 3 Aug 2009 16:37:13 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-14.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 Aug 2009 16:37:13 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.14.3/8.14.3) with ESMTP id n73GbCIZ013911 for ; Mon, 3 Aug 2009 09:37:12 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id n73GbCeC012034 for ; Mon, 3 Aug 2009 11:37:12 -0500 (CDT) Received: from ZMY16EXM67.ds.mot.com (zmy16exm67.ap.mot.com [10.179.4.27]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id n73GbAYw012013 for ; Mon, 3 Aug 2009 11:37:11 -0500 (CDT) 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: Tue, 4 Aug 2009 00:36:48 +0800 Message-ID: <3100473D52017B48B9068E079BE2A6E603FC10CA@ZMY16EXM67.ds.mot.com> In-Reply-To: <5F063FC3F0C8F14E945465A68E63C43E94534B@ex3-del1.synapse.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] SIP Dialog Match Thread-Index: AcoUVDPfNaKNlIWVSVW07t6UXWMgGgAAuDRQAABKnlAAABMqEA== References: <5F063FC3F0C8F14E945465A68E63C43E9451DB@ex3-del1.synapse.com><1249249277.4106.1.camel@victoria-pingtel-com.us.nortel.com><5F063FC3F0C8F14E945465A68E63C43E945346@ex3-del1.synapse.com><1249313088.3791.0.camel@victoria-pingtel-com.us.nortel.com><5F063FC3F0C8F14E945465A68E63C43E945347@ex3-del1.synapse.com><1249314398.3791.5.camel@victoria-pingtel-com.us.nortel.com><5F063FC3F0C8F14E945465A68E63C43E94534A@ex3-del1.synapse.com> <1249315489.3791.10.camel@victoria-pingtel-com.us.nortel.com> <3100473D52017B48B9068E079BE2A6E603FC10C6@ZMY16EXM67.ds.mot.com> <5F063FC3F0C8F14E945465A68E63C43E94534B@ex3-del1.synapse.com> From: "T Satyanarayana-A12694" To: "Karunesh Sharma" , "Dale Worley" X-CFilter-Loop: Reflected Cc: sip@ietf.org Subject: Re: [Sip] SIP Dialog Match X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 16:38:24 -0000 No, privacy using encryption. -----Original Message----- From: Karunesh Sharma [mailto:Karunesh.Sharma@globallogic.com]=20 Sent: Monday, August 03, 2009 10:05 PM To: T Satyanarayana-A12694; Dale Worley Cc: sip@ietf.org Subject: RE: [Sip] SIP Dialog Match Are you talking about *privacy* headers? I fail to understand here how *privacy* header will help in such cases. K$ _______________________ -----Original Message----- From: T Satyanarayana-A12694 [mailto:satyanarayana.t@motorola.com] Sent: Monday, August 03, 2009 10:02 PM To: Dale Worley; Karunesh Sharma Cc: sip@ietf.org Subject: RE: [Sip] SIP Dialog Match In short, if some one wants to fake another client, it is possible since the communication is in clear. If there are security concerns, then security mechanisms (privacy etc) should be used. -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Dale Worley Sent: Monday, August 03, 2009 9:35 PM To: Karunesh Sharma Cc: sip@ietf.org Subject: Re: [Sip] SIP Dialog Match On Mon, 2009-08-03 at 21:28 +0530, Karunesh Sharma wrote: > Is this a valid behavior for scenario like 'Call-Forwarding'? In principle, the responses to a request should almost always come from the address to which the request was sent. But that is not usually enforced, and there may be good reasons why it isn't happening in a particular instance. In regard to an observed instance of this behavior, you must first determine the complete routing of the request in question and the reason for each routing step. Dale _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From satyanarayana.t@motorola.com Mon Aug 3 09:49:47 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFC073A691F for ; Mon, 3 Aug 2009 09:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SSKrDdbcmuMm for ; Mon, 3 Aug 2009 09:49:46 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by core3.amsl.com (Postfix) with ESMTP id B59203A6B27 for ; Mon, 3 Aug 2009 09:49:46 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: satyanarayana.t@motorola.com X-Msg-Ref: server-7.tower-119.messagelabs.com!1249318188!30874719!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 459 invoked from network); 3 Aug 2009 16:49:48 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-7.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 Aug 2009 16:49:48 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.14.3/8.14.3) with ESMTP id n73GnlQF015843 for ; Mon, 3 Aug 2009 09:49:47 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id n73GnlVH014988 for ; Mon, 3 Aug 2009 11:49:47 -0500 (CDT) Received: from ZMY16EXM67.ds.mot.com (zmy16exm67.ap.mot.com [10.179.4.27]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id n73GnklW014985 for ; Mon, 3 Aug 2009 11:49:47 -0500 (CDT) 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: Tue, 4 Aug 2009 00:49:24 +0800 Message-ID: <3100473D52017B48B9068E079BE2A6E603FC10CC@ZMY16EXM67.ds.mot.com> In-Reply-To: <5F063FC3F0C8F14E945465A68E63C43E94534A@ex3-del1.synapse.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] SIP Dialog Match Thread-Index: AcoUUZwEZrr9UtC8RwaZmKpaij2yeAAAG8zAAABKuFAAAQDfwA== References: <5F063FC3F0C8F14E945465A68E63C43E9451DB@ex3-del1.synapse.com><1249249277.4106.1.camel@victoria-pingtel-com.us.nortel.com><5F063FC3F0C8F14E945465A68E63C43E945346@ex3-del1.synapse.com><1249313088.3791.0.camel@victoria-pingtel-com.us.nortel.com><5F063FC3F0C8F14E945465A68E63C43E945347@ex3-del1.synapse.com><1249314398.3791.5.camel@victoria-pingtel-com.us.nortel.com> <5F063FC3F0C8F14E945465A68E63C43E94534A@ex3-del1.synapse.com> From: "T Satyanarayana-A12694" To: "Karunesh Sharma" , "Dale Worley" X-CFilter-Loop: Reflected Cc: sip@ietf.org Subject: Re: [Sip] SIP Dialog Match X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 16:49:47 -0000 No, this isn't how it usually works. For call forwarding, there is usually a proxy (or a softswitch) which does it on behalf of B. However, if B chooses to do it himself: C (forwardee) gets it like a regular call from B (forwarding agent) and C doesn't reply to A - it replies to B. B then can shuffle the calls so that the call is directly between A and C (through a set of target refreshes). However, this is just hypothetical and not usually done in reality. Regards Satya T -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Karunesh Sharma Sent: Monday, August 03, 2009 9:29 PM To: Dale Worley Cc: sip@ietf.org Subject: Re: [Sip] SIP Dialog Match Is this a valid behavior for scenario like 'Call-Forwarding'? K$ _______________________ -----Original Message----- From: Karunesh Sharma Sent: Monday, August 03, 2009 9:22 PM To: 'Dale Worley' Cc: aayush bhatnagar; sip@ietf.org Subject: RE: [Sip] SIP Dialog Match I am trying to get that info how 'C' has this dialog identifiers but I was wondering this as a major security issue for any SIP network. K$ _______________________ -----Original Message----- From: Dale Worley [mailto:dworley@nortel.com] Sent: Monday, August 03, 2009 9:17 PM To: Karunesh Sharma Cc: aayush bhatnagar; sip@ietf.org Subject: RE: [Sip] SIP Dialog Match On Mon, 2009-08-03 at 21:03 +0530, Karunesh Sharma wrote: > 172.16.31.30 (read as 'A') sent INVITE to 10.0.4.6 (read as 'B'). But=20 > somehow 192.168.4.67 (read as 'C') responds. Now 'A' knows nothing about > 'C', but still based on SIP dialog identifiers 'A' accepts that. >=20 > So is there any way to challenge or deny such rouge responses? Have you inquired as to how C knows of the dialog identifiers, and why it is sending the responses? Dale _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From root@core3.amsl.com Tue Aug 4 14:00:01 2009 Return-Path: X-Original-To: sip@ietf.org Delivered-To: sip@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 5905728C449; Tue, 4 Aug 2009 14:00:00 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090804210001.5905728C449@core3.amsl.com> Date: Tue, 4 Aug 2009 14:00:01 -0700 (PDT) Cc: sip@ietf.org Subject: [Sip] I-D Action:draft-ietf-sip-record-route-fix-08.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2009 21:00:01 -0000 --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 : Addressing Record-Route issues in the Session Initiation Protocol (SIP) Author(s) : T. Froment, et al. Filename : draft-ietf-sip-record-route-fix-08.txt Pages : 26 Date : 2009-08-04 A typical function of a Session Initiation Protocol (SIP) Proxy is to insert a Record-Route header into initial, dialog creating requests in order to make subsequent, in-dialog requests pass through it. This header contains a SIP Uniform Resource Identifier (URI) indicating where and how the subsequent requests should be sent to reach the proxy. Like any SIP URI, it can contain SIP or SIPS schemes, IPv4 or IPv6 addresses, and URI parameters that could influence the routing such as the transport parameter (for example transport=tcp), or a compression indication like "comp=sigcomp". When a proxy has to change some of those parameters between its incoming and outgoing interfaces (multi-homed proxies, transport protocol switching or IPv4 to IPv6 scenarios...), the question arises on what should be put in Record-Route header(s). It is not possible to make one header have the characteristics of both interfaces at the same time. This document aims to clarify these scenarios and fix bugs already identified on this topic; it formally recommends the use of the double Record-Route technique as an alternative to the current RFC3261 text, which describes only a Record-Route rewriting solution. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-record-route-fix-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-sip-record-route-fix-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-08-04135038.I-D@ietf.org> --NextPart-- From ben.bonnaerens@alcatel-lucent.be Wed Aug 5 07:25:06 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0568A28C598 for ; Wed, 5 Aug 2009 07:25:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dumONe3FMAvT for ; Wed, 5 Aug 2009 07:25:05 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 98A5928C59A for ; Wed, 5 Aug 2009 07:23:51 -0700 (PDT) Received: from FRVELSBHS02.ad2.ad.alcatel.com (frvelsbhs02.dc-m.alcatel-lucent.com [155.132.6.74]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n75EN3JG026720; Wed, 5 Aug 2009 16:23:04 +0200 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.51]) by FRVELSBHS02.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Aug 2009 16:23:03 +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: Wed, 5 Aug 2009 16:23:02 +0200 Message-ID: <8144761F31F48D43AD53D09F5350E38004C00CE5@FRVELSMBS22.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-sip-record-route-fix-08 Changes Thread-Index: AcoV2D3o9zuX5uy0THC/DMS48GQffw== From: "BONNAERENS Ben" To: X-OriginalArrivalTime: 05 Aug 2009 14:23:03.0743 (UTC) FILETIME=[3E655CF0:01CA15D8] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Subject: [Sip] draft-ietf-sip-record-route-fix-08 Changes X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 14:25:06 -0000 Hi, version -08 of record-route fix has just been submitted. Change log: - Changed its status from BCP to PS, - Take into account IESG reviews and subsequent comments on the mailing lists,=20 they were summarized in Robert Sparks's document (rrf.txt),=20 so it has been integrated in version -08 with minor refactoring from the authors (me and Ben). The thoughest part was related to the SIP/SIPS question raised by Cullen (http://datatracker.ietf.org/idtracker/draft-ietf-sip-record-route-fix/c omment/98624/), so here is the text that was added in version -08 to answer this question: "Thus, if the transport protocol changed between its incoming and outgoing sides, the proxy SHOULD use the double Record-Route technique and SHOULD add a transport parameter to each of the Record-Route URIs it inserts. With the exception that if TLS is used as the transport protocol on either side of the proxy, the URI chosen to place in the Record-Route header field value reflecting the interface using TLS will need to leverage the [RFC3263] mechanisms to indicate that TLS must be used rather attempting to use the deprecated "transport=3Dtls" URI parameter. See [RFC3261] Section 26.2.2 and [I-D.ietf-sip-sips] Section 3.1.4 for more discussion." Brds, Thomas & Ben From root@core3.amsl.com Wed Aug 5 12:45:02 2009 Return-Path: X-Original-To: sip@ietf.org Delivered-To: sip@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 08F4428C65C; Wed, 5 Aug 2009 12:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090805194502.08F4428C65C@core3.amsl.com> Date: Wed, 5 Aug 2009 12:45:02 -0700 (PDT) Cc: sip@ietf.org Subject: [Sip] I-D Action:draft-ietf-sip-connect-reuse-14.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 19:45:02 -0000 --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 : Connection Reuse in the Session Initiation Protocol (SIP) Author(s) : V. Gurbani, et al. Filename : draft-ietf-sip-connect-reuse-14.txt Pages : 18 Date : 2009-08-05 This document enables a pair of communicating proxies to reuse a congestion-controlled connection between themselves for sending requests in the forward and backwards direction. Because the connection is essentially aliased for requests going in the backwards direction, reuse is predicated upon both the communicating endpoints authenticating themselves using X.509 certificates through TLS. For this reason, we only consider connection reuse for TLS over TCP and TLS over SCTP. This document also provides guidelines on connection reuse and virtual SIP servers and the interaction of connection reuse and DNS SRV lookups in SIP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-connect-reuse-14.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-sip-connect-reuse-14.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-08-05124141.I-D@ietf.org> --NextPart-- From vkg@alcatel-lucent.com Wed Aug 5 12:46:09 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D41AE28C5CB for ; Wed, 5 Aug 2009 12:46:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SKsRnd3NZA3X for ; Wed, 5 Aug 2009 12:46:05 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 44F1928C5DC for ; Wed, 5 Aug 2009 12:46:02 -0700 (PDT) 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 n75Jk4Bb013278 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 5 Aug 2009 14:46:04 -0500 (CDT) Received: from [135.185.236.17] (il0015vkg1.ih.lucent.com [135.185.236.17]) by umail.lucent.com (8.13.8/TPES) with ESMTP id n75Jk40K009621 for ; Wed, 5 Aug 2009 14:46:04 -0500 (CDT) Message-ID: <4A79E17C.6090209@alcatel-lucent.com> Date: Wed, 05 Aug 2009 14:46:04 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group 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-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Subject: [Sip] New version of connect-reuse issued, post IESG review X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 19:46:09 -0000 All: I have released a new version of connect-reuse that addresses the comments from IESG review. The new version (-14) can be accessed from: http://www.ietf.org/id/draft-ietf-sip-connect-reuse-14.txt Here is the list of changes resulting from the IESG review: - Changed ephemeral port numbers to be between 49152 and 65535, as suggested by IANA (comment from Gen-ART review.) - In S8.1 modified text to be more compatible with domain-certs. - In S8.1, the normative behavior in the first and third paragraphs seem to use "SHOULD" and "MUST" to describe the same behavior. Changed the MUST in the third paragraph to a SHOULD without any semantic loss. - In S8.2, changed some text that makes it mandatory to follow the authentication steps in S9.2. This change does not alter anything semantically. - In S9.1 and 9.2, updated section numbers pointing to RFC YYYY. - In S9.2, added 2 paragraphs on the impact of virtual servers and connection reuse on P1. Thank you, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} Web: http://ect.bell-labs.com/who/vkg/ From john.elwell@siemens-enterprise.com Thu Aug 6 00:36:55 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 943523A6C77 for ; Thu, 6 Aug 2009 00:36:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.502 X-Spam-Level: X-Spam-Status: No, score=-2.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6GkQv0Ue9efZ for ; Thu, 6 Aug 2009 00:36:54 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 73FD63A6902 for ; Thu, 6 Aug 2009 00:36:53 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KNY00C702HJ8N@siemenscomms.co.uk> for sip@ietf.org; Thu, 06 Aug 2009 08:36:55 +0100 (BST) Date: Thu, 06 Aug 2009 08:36:54 +0100 From: "Elwell, John" In-reply-to: <8144761F31F48D43AD53D09F5350E38004C00CE5@FRVELSMBS22.ad2.ad.alcatel.com> To: BONNAERENS Ben , sip@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D002393EA0@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: quoted-printable Thread-Topic: [Sip] draft-ietf-sip-record-route-fix-08 Changes Thread-Index: AcoV2D3o9zuX5uy0THC/DMS48GQffwAj7G0w Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <8144761F31F48D43AD53D09F5350E38004C00CE5@FRVELSMBS22.ad2.ad.alcatel.com> Subject: Re: [Sip] draft-ietf-sip-record-route-fix-08 Changes X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 07:36:55 -0000 Well, I know what this means, but will your average reader understand it? I think we are trying to say something along the lines that if the transport protocol changes you SHOULD use the double Record-Route technique, where the differences in transport protocol are reflected in different values of the transport parameter (udp/tcp/sctp) and/or different values of the URI scheme (sip/sips). Correct? John > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20 > Behalf Of BONNAERENS Ben > Sent: 05 August 2009 15:23 > To: sip@ietf.org > Subject: [Sip] draft-ietf-sip-record-route-fix-08 Changes >=20 > Hi, > version -08 of record-route fix has just been submitted. >=20 > Change log: > - Changed its status from BCP to PS, > - Take into account IESG reviews and subsequent comments on=20 > the mailing > lists,=20 > they were summarized in Robert Sparks's document (rrf.txt),=20 > so it has been integrated in version -08 with minor=20 > refactoring from the > authors (me and Ben). >=20 > The thoughest part was related to the SIP/SIPS question=20 > raised by Cullen > (http://datatracker.ietf.org/idtracker/draft-ietf-sip-record-r > oute-fix/c > omment/98624/), > so here is the text that was added in version -08 to answer this > question: > "Thus, if the transport protocol changed between its > incoming and outgoing sides, the proxy SHOULD use the double > Record-Route technique and SHOULD add a transport parameter to each > of the Record-Route URIs it inserts. With the exception that if TLS > is > used as the transport protocol on either side of the proxy, the URI > chosen to place in the Record-Route header field value=20 > reflecting the > interface using TLS will need to leverage the [RFC3263]=20 > mechanisms to > indicate that TLS must be used rather attempting to use the > deprecated > "transport=3Dtls" URI parameter. See [RFC3261] Section 26.2.2 and > [I-D.ietf-sip-sips] Section 3.1.4 for more discussion." >=20 > Brds, > Thomas & Ben > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 From Karunesh.Sharma@globallogic.com Fri Aug 7 06:07:13 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 205F73A6CE8 for ; Fri, 7 Aug 2009 06:07:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.38 X-Spam-Level: X-Spam-Status: No, score=-2.38 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DPy09NHou8FS for ; Fri, 7 Aug 2009 06:07:12 -0700 (PDT) Received: from emailsecurity-del1-1.globallogic.com (mx-del1-1.globallogic.com [202.174.92.25]) by core3.amsl.com (Postfix) with ESMTP id BAE0D3A6CFD for ; Fri, 7 Aug 2009 06:07:11 -0700 (PDT) Received: from emailsecurity-del1-1.globallogic.com (127.0.0.1) by emailsecurity-del1-1.globallogic.com (MlfMTA v3.2r9) id hfgjau0171si for ; Fri, 7 Aug 2009 18:35:47 +0530 (envelope-from ) Received: from ex3-del1.synapse.com ([172.16.2.34]) by emailsecurity-del1-1.globallogic.com (SonicWALL 7.0.1.1499) with ESMTP; Fri, 07 Aug 2009 18:35:47 +0530 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, 7 Aug 2009 18:37:11 +0530 Message-ID: <5F063FC3F0C8F14E945465A68E63C43E9454EF@ex3-del1.synapse.com> In-Reply-To: <1249315489.3791.10.camel@victoria-pingtel-com.us.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] SIP Dialog Match Thread-Index: AcoUVCXPEClx7WpKR+q3Mwth+b1Y2QDC2udw References: <5F063FC3F0C8F14E945465A68E63C43E9451DB@ex3-del1.synapse.com> <1249249277.4106.1.camel@victoria-pingtel-com.us.nortel.com> <5F063FC3F0C8F14E945465A68E63C43E945346@ex3-del1.synapse.com> <1249313088.3791.0.camel@victoria-pingtel-com.us.nortel.com> <5F063FC3F0C8F14E945465A68E63C43E945347@ex3-del1.synapse.com> <1249314398.3791.5.camel@victoria-pingtel-com.us.nortel.com> <5F063FC3F0C8F14E945465A68E63C43E94534A@ex3-del1.synapse.com> <1249315489.3791.10.camel@victoria-pingtel-com.us.nortel.com> From: "Karunesh Sharma" To: "Dale Worley" X-Mlf-Version: 7.0.1.1499 X-Mlf-UniqueId: o200908071305470034739 Cc: sip@ietf.org Subject: Re: [Sip] SIP Dialog Match X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2009 13:07:13 -0000 Dale: It's simple scenario where 'A' sent INVITE to 'B'. 'C' is man in middle captured the INVITE and sent the response back to 'A'. I wonder why no one ever had such case ever and why there is no established guidelines. K$ _______________________ -----Original Message----- From: Dale Worley [mailto:dworley@nortel.com]=20 Sent: Monday, August 03, 2009 9:35 PM To: Karunesh Sharma Cc: aayush bhatnagar; sip@ietf.org Subject: RE: [Sip] SIP Dialog Match On Mon, 2009-08-03 at 21:28 +0530, Karunesh Sharma wrote: > Is this a valid behavior for scenario like 'Call-Forwarding'? In principle, the responses to a request should almost always come from the address to which the request was sent. But that is not usually enforced, and there may be good reasons why it isn't happening in a particular instance. In regard to an observed instance of this behavior, you must first determine the complete routing of the request in question and the reason for each routing step. Dale From satyanarayana.t@motorola.com Fri Aug 7 06:29:43 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17A753A68BB for ; Fri, 7 Aug 2009 06:29:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9LhoU+fKf1Id for ; Fri, 7 Aug 2009 06:29:41 -0700 (PDT) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with ESMTP id A164F3A6A66 for ; Fri, 7 Aug 2009 06:29:08 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: satyanarayana.t@motorola.com X-Msg-Ref: server-8.tower-153.messagelabs.com!1249651746!9675944!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [136.182.1.12] Received: (qmail 28471 invoked from network); 7 Aug 2009 13:29:07 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (136.182.1.12) by server-8.tower-153.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Aug 2009 13:29:07 -0000 Received: from il27exr04.cig.mot.com (il27exr04.mot.com [10.17.196.73]) by motgate2.mot.com (8.14.3/8.14.3) with ESMTP id n77DT6QW022290 for ; Fri, 7 Aug 2009 06:29:06 -0700 (MST) Received: from il27vts03 (il27vts03.cig.mot.com [10.17.196.87]) by il27exr04.cig.mot.com (8.13.1/Vontu) with SMTP id n77DT6nQ004777 for ; Fri, 7 Aug 2009 08:29:06 -0500 (CDT) Received: from ZMY16EXM67.ds.mot.com (zmy16exm67.ap.mot.com [10.179.4.27]) by il27exr04.cig.mot.com (8.13.1/8.13.0) with ESMTP id n77DT4V4004763 for ; Fri, 7 Aug 2009 08:29:05 -0500 (CDT) 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, 7 Aug 2009 21:28:42 +0800 Message-ID: <3100473D52017B48B9068E079BE2A6E604005E29@ZMY16EXM67.ds.mot.com> In-Reply-To: <5F063FC3F0C8F14E945465A68E63C43E9454EF@ex3-del1.synapse.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] SIP Dialog Match Thread-Index: AcoUVCXPEClx7WpKR+q3Mwth+b1Y2QDC2udwAABHwlA= References: <5F063FC3F0C8F14E945465A68E63C43E9451DB@ex3-del1.synapse.com><1249249277.4106.1.camel@victoria-pingtel-com.us.nortel.com><5F063FC3F0C8F14E945465A68E63C43E945346@ex3-del1.synapse.com><1249313088.3791.0.camel@victoria-pingtel-com.us.nortel.com><5F063FC3F0C8F14E945465A68E63C43E945347@ex3-del1.synapse.com><1249314398.3791.5.camel@victoria-pingtel-com.us.nortel.com><5F063FC3F0C8F14E945465A68E63C43E94534A@ex3-del1.synapse.com><1249315489.3791.10.camel@victoria-pingtel-com.us.nortel.com> <5F063FC3F0C8F14E945465A68E63C43E9454EF@ex3-del1.synapse.com> From: "T Satyanarayana-A12694" To: "Karunesh Sharma" , "Dale Worley" X-CFilter-Loop: Reflected Cc: sip@ietf.org Subject: Re: [Sip] SIP Dialog Match X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2009 13:29:43 -0000 Well, strictly speaking, this is possible and most SIP networks are vulnerable to this. This is no different from HTTP or SMTP where this is possible. The guidelines (there could be others as well) to overcome this are: 1. Implement a known-good-source kind of logic where you accept responses coming only from a well known proxy. Ofcourse, this works only when there is a proxy and when the source IP address of the response itself is not modified. 2. Implement encryption (e.g. TLS) for signaling Regards Satya T -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Karunesh Sharma Sent: Friday, August 07, 2009 6:37 PM To: Dale Worley Cc: sip@ietf.org Subject: Re: [Sip] SIP Dialog Match Dale: It's simple scenario where 'A' sent INVITE to 'B'. 'C' is man in middle captured the INVITE and sent the response back to 'A'. I wonder why no one ever had such case ever and why there is no established guidelines. K$ _______________________ -----Original Message----- From: Dale Worley [mailto:dworley@nortel.com] Sent: Monday, August 03, 2009 9:35 PM To: Karunesh Sharma Cc: aayush bhatnagar; sip@ietf.org Subject: RE: [Sip] SIP Dialog Match On Mon, 2009-08-03 at 21:28 +0530, Karunesh Sharma wrote: > Is this a valid behavior for scenario like 'Call-Forwarding'? In principle, the responses to a request should almost always come from the address to which the request was sent. But that is not usually enforced, and there may be good reasons why it isn't happening in a particular instance. In regard to an observed instance of this behavior, you must first determine the complete routing of the request in question and the reason for each routing step. Dale _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sandipfloyd@gmail.com Thu Aug 6 07:46:26 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9DA728C140 for ; Thu, 6 Aug 2009 07:46:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZTkhHiCAduGc for ; Thu, 6 Aug 2009 07:46:25 -0700 (PDT) Received: from mail-gx0-f213.google.com (mail-gx0-f213.google.com [209.85.217.213]) by core3.amsl.com (Postfix) with ESMTP id 41B9028C13C for ; Thu, 6 Aug 2009 07:46:23 -0700 (PDT) Received: by gxk9 with SMTP id 9so1143944gxk.13 for ; Thu, 06 Aug 2009 07:46:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:from:date:message-id :subject:to:content-type; bh=q2VtG6sIhBW+ZMZymvVW6ik5F2sKsBmw1/Cpswp7EOg=; b=nLktnEhDlFyVjfCFj94y/+5LaoRia2QF05CtR0wDOePai72dWgNH8Rr9vh3P+T7Sjn Zj4JM1jDSLQ4a289WrClGMvTRSelKj0GK8q/OBVtnBgHhSH6JdD70EdgWdBk8DmyZ1Tz FlNRxESS4Ns2CNRJF4ZtOwHUElr2mlTRcL3No= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=pyp26kEiob6njk3fopREUnxEkF7b7DVqdr6d0bJ6W6Tw2RAtey8qav/fm91vW6lPSE pZX/07NSMI2ADnxNj9PKIm6JVqPZMQGJUoOhMTigRgDA6kEqRDs821iP9+1kPpRKjArk 9pi34MmgQQ2KnK9ZnzjxHyd3v7okq1mVtSSIs= MIME-Version: 1.0 Received: by 10.151.78.19 with SMTP id f19mr159659ybl.182.1249569971156; Thu, 06 Aug 2009 07:46:11 -0700 (PDT) From: sandip gangakhedkar Date: Thu, 6 Aug 2009 20:15:51 +0530 Message-ID: <6208da1a0908060745w259dd980qd79428affb6cc503@mail.gmail.com> To: sip@ietf.org Content-Type: multipart/alternative; boundary=0015174bdc4e40b8e504707a2e92 X-Mailman-Approved-At: Fri, 07 Aug 2009 06:33:25 -0700 Subject: [Sip] Contact header in 200 OK X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 17:05:11 -0000 --0015174bdc4e40b8e504707a2e92 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi all, I'd like to know if the Contact header is mandatory for a 200 OK response to an INVITE request. The RFC doesnt explicitly mention anything in this regard although a 200 OK is mandatory for a REGISTER request. If the originating endpoint receives the Contact header in the 180 Ringing response (which I assume is mandatory), then it knows the location of the remote endpoint, in which case the Contact header would be redundant in the 200 OK response. Waiting for some expert intervention.. :) Regards, -- Sandip Gangakhedkar Mobile:+91-97396-99916 Office: +91-80-4363-3899 Profile: http://www.linkedin.com/in/sandipg --0015174bdc4e40b8e504707a2e92 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi all,

I'd like to know if the Contact header is mandatory for a 200 OK response to an INVITE request.

The RFC doesnt explicitly mention anything in this regard although a 200 OK is mandatory for a REGISTER request.

If the originating endpoint receives the Contact header in the 180 Ringing response (which I assume is mandatory), then it knows the location of the remote endpoint, in which case the Contact header would be redundant in the 200 OK response.

Waiting for some expert intervention.. :)

Regards,
--
Sandip Gangakhedkar
Mobile:+91-97396-99916
Office: +91-80-4363-3899
Profile: http://www.linkedin.com/in/sandipg
--0015174bdc4e40b8e504707a2e92-- From satyanarayana.t@motorola.com Fri Aug 7 06:47:56 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B04CF3A6910 for ; Fri, 7 Aug 2009 06:47:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qDKd25SQd8ir for ; Fri, 7 Aug 2009 06:47:55 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by core3.amsl.com (Postfix) with ESMTP id 930553A6AB2 for ; Fri, 7 Aug 2009 06:47:55 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: satyanarayana.t@motorola.com X-Msg-Ref: server-5.tower-119.messagelabs.com!1249652876!33375219!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 28147 invoked from network); 7 Aug 2009 13:47:56 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-5.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Aug 2009 13:47:56 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.14.3/8.14.3) with ESMTP id n77Dluid004179 for ; Fri, 7 Aug 2009 06:47:56 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id n77Dlugi017836 for ; Fri, 7 Aug 2009 08:47:56 -0500 (CDT) Received: from ZMY16EXM67.ds.mot.com (zmy16exm67.ap.mot.com [10.179.4.27]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id n77Dlss2017830 for ; Fri, 7 Aug 2009 08:47:55 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA1765.9D36D972" Date: Fri, 7 Aug 2009 21:47:32 +0800 Message-ID: <3100473D52017B48B9068E079BE2A6E604005E36@ZMY16EXM67.ds.mot.com> In-Reply-To: <6208da1a0908060745w259dd980qd79428affb6cc503@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Contact header in 200 OK Thread-Index: AcoXY6zBTzIhY6idQvGtAJKb7UF2nQAAcUoA References: <6208da1a0908060745w259dd980qd79428affb6cc503@mail.gmail.com> From: "T Satyanarayana-A12694" To: "sandip gangakhedkar" , X-CFilter-Loop: Reflected Subject: Re: [Sip] Contact header in 200 OK X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2009 13:47:56 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA1765.9D36D972 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The RFC does mention this. In table 2, on page 162. =20 Header field where proxy ACK BYE CAN INV OPT REG ___________________________________________________________ Contact 2xx - - - m o o regards Satya T =20 ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of sandip gangakhedkar Sent: Thursday, August 06, 2009 8:16 PM To: sip@ietf.org Subject: [Sip] Contact header in 200 OK Hi all, I'd like to know if the Contact header is mandatory for a 200 OK response to an INVITE request.=20 The RFC doesnt explicitly mention anything in this regard although a 200 OK is mandatory for a REGISTER request. If the originating endpoint receives the Contact header in the 180 Ringing response (which I assume is mandatory), then it knows the location of the remote endpoint, in which case the Contact header would be redundant in the 200 OK response. Waiting for some expert intervention.. :)=20 Regards, --=20 Sandip Gangakhedkar Mobile:+91-97396-99916 Office: +91-80-4363-3899 Profile: http://www.linkedin.com/in/sandipg ------_=_NextPart_001_01CA1765.9D36D972 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
The RFC does mention this. In table 2, on page=20 162.
 
      Header=20 field          = where  =20 proxy ACK BYE CAN INV OPT REG
     =20 ___________________________________________________________
 &nbs= p;   =20 Contact           =     =20 2xx           = -  =20 -   -   m   o  =20 o
regards
Satya T
=

 
From: sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org] On Behalf Of sandip=20 gangakhedkar
Sent: Thursday, August 06, 2009 8:16 = PM
To:=20 sip@ietf.org
Subject: [Sip] Contact header in 200=20 OK

Hi all,

I'd like to know if the Contact header is = mandatory=20 for a 200 OK response to an INVITE request.

The RFC doesnt = explicitly=20 mention anything in this regard although a 200 OK is mandatory for a = REGISTER=20 request.

If the originating endpoint receives the Contact header = in the=20 180 Ringing response (which I assume is mandatory), then it knows the = location=20 of the remote endpoint, in which case the Contact header would be = redundant in=20 the 200 OK response.

Waiting for some expert intervention.. :)=20

Regards,
--
Sandip=20 Gangakhedkar
Mobile:+91-97396-99916
Office: = +91-80-4363-3899
Profile:=20 http://www.linkedin.com/in/sa= ndipg
------_=_NextPart_001_01CA1765.9D36D972-- From ben.bonnaerens@alcatel-lucent.be Fri Aug 7 06:57:45 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8AD03A6EAB for ; Fri, 7 Aug 2009 06:57:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9Nz-uOyGodE for ; Fri, 7 Aug 2009 06:57:44 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by core3.amsl.com (Postfix) with ESMTP id 828F528C1D3 for ; Fri, 7 Aug 2009 06:57:44 -0700 (PDT) Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.dc-m.alcatel-lucent.com [155.132.6.76]) by smail2.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n77Dv4P1011665; Fri, 7 Aug 2009 15:57:42 +0200 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.52]) by FRVELSBHS04.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 Aug 2009 15:57:20 +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, 7 Aug 2009 15:57:19 +0200 Message-ID: <8144761F31F48D43AD53D09F5350E38004C01534@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: A<0D5F89FAC29E2C41B98A6A762007F5D002393EA0@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-ietf-sip-record-route-fix-08 Changes Thread-Index: AcoV2D3o9zuX5uy0THC/DMS48GQffwAj7G0wAD7JfZA= References: <8144761F31F48D43AD53D09F5350E38004C00CE5@FRVELSMBS22.ad2.ad.alcatel.com> A<0D5F89FAC29E2C41B98A6A762007F5D002393EA0@GBNTHT12009MSX.gb002.siemens.net> From: "BONNAERENS Ben" To: "Elwell, John" , X-OriginalArrivalTime: 07 Aug 2009 13:57:20.0063 (UTC) FILETIME=[FB1DFCF0:01CA1766] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.80 Subject: Re: [Sip] draft-ietf-sip-record-route-fix-08 Changes X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2009 13:57:45 -0000 Hello John, > Well, I know what this means, but will your average reader=20 > understand it? I think we are trying to say something along=20 > the lines that if the transport protocol changes you SHOULD=20 > use the double Record-Route technique, where the differences=20 > in transport protocol are reflected in different values of=20 > the transport parameter (udp/tcp/sctp) and/or different=20 > values of the URI scheme (sip/sips). Correct? Your phrasing could lead to the understanding that we suggest that=20 only a sips URI can be used to identify the TLS interface which is not correct. As the current text suggests, can the TLS interface be identified by any URI (sip or sips ; excluding the deprecated transport=3Dtls parameter) that=20 resolves via RFC3263 procedures to the TLS transport. IMHO leaves your suggested phrasing more room for ambiguity compared to the current text. Best regards & thanks, Ben. =20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 > Sent: donderdag 6 augustus 2009 9:37 > To: BONNAERENS Ben; sip@ietf.org > Subject: RE: [Sip] draft-ietf-sip-record-route-fix-08 Changes >=20 > Well, I know what this means, but will your average reader=20 > understand it? I think we are trying to say something along=20 > the lines that if the transport protocol changes you SHOULD=20 > use the double Record-Route technique, where the differences=20 > in transport protocol are reflected in different values of=20 > the transport parameter (udp/tcp/sctp) and/or different=20 > values of the URI scheme (sip/sips). Correct? >=20 > John >=20 > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20 > Behalf Of=20 > > BONNAERENS Ben > > Sent: 05 August 2009 15:23 > > To: sip@ietf.org > > Subject: [Sip] draft-ietf-sip-record-route-fix-08 Changes > >=20 > > Hi, > > version -08 of record-route fix has just been submitted. > >=20 > > Change log: > > - Changed its status from BCP to PS, > > - Take into account IESG reviews and subsequent comments on the=20 > > mailing lists, they were summarized in Robert Sparks's document=20 > > (rrf.txt), so it has been integrated in version -08 with minor=20 > > refactoring from the authors (me and Ben). > >=20 > > The thoughest part was related to the SIP/SIPS question raised by=20 > > Cullen=20 > (http://datatracker.ietf.org/idtracker/draft-ietf-sip-record-r > > oute-fix/c > > omment/98624/), > > so here is the text that was added in version -08 to answer this > > question: > > "Thus, if the transport protocol changed between its > > incoming and outgoing sides, the proxy SHOULD use the double > > Record-Route technique and SHOULD add a transport=20 > parameter to each > > of the Record-Route URIs it inserts. With the exception=20 > that if TLS=20 > > is > > used as the transport protocol on either side of the=20 > proxy, the URI > > chosen to place in the Record-Route header field value=20 > reflecting=20 > > the > > interface using TLS will need to leverage the [RFC3263]=20 > mechanisms=20 > > to > > indicate that TLS must be used rather attempting to use the=20 > > deprecated > > "transport=3Dtls" URI parameter. See [RFC3261] Section 26.2.2 and > > [I-D.ietf-sip-sips] Section 3.1.4 for more discussion." > >=20 > > Brds, > > Thomas & Ben > > _______________________________________________ > > Sip mailing list https://www.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 From ygaziel@gmail.com Sat Aug 8 23:36:19 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 117443A69D1 for ; Sat, 8 Aug 2009 23:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.669 X-Spam-Level: X-Spam-Status: No, score=-1.669 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l0CijdHMiotx for ; Sat, 8 Aug 2009 23:36:18 -0700 (PDT) Received: from mail-ew0-f214.google.com (mail-ew0-f214.google.com [209.85.219.214]) by core3.amsl.com (Postfix) with ESMTP id 18AF73A6824 for ; Sat, 8 Aug 2009 23:36:17 -0700 (PDT) Received: by ewy10 with SMTP id 10so2388623ewy.37 for ; Sat, 08 Aug 2009 23:36:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=zujR3iLLNcaZfCDmqhIviFcHGhqdx961DebajZ8GzqA=; b=c0wdQHZL2Bz7hV3YgXzwvxiI42z6jG5c4uhAOVubNwgDynfnR71OeC/lXF71gqvZBv wIOB4AZU69bvA3GvoADPp36qWb6RaEx/Fe0CA1ExQqozAijysO2QKjIIB+xEQMIP641u /Uswt8f3VSHlQZMnTxgus3ap5+t3AlPf0ZQGo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=jIn3TpPfXz1PSnPzBpXT5Z/0BNyV5Zol+iuWqspFN7Vs5MiM9/UT2i7r7/CDkpV0Hp O8wzlmTqAt52Nx9zPR+PtvaGC6S9L77VUN0zB6+FmNY40DlrMivmImHJtIKcB3SIMx4J H6VODB1GuyKxDmN+bjHePtGx1V/HKzj3QiiZA= MIME-Version: 1.0 Received: by 10.210.51.10 with SMTP id y10mr1486193eby.4.1249799777915; Sat, 08 Aug 2009 23:36:17 -0700 (PDT) Date: Sun, 9 Aug 2009 09:36:17 +0300 Message-ID: From: Yoav Gaziel To: sip@ietf.org Content-Type: multipart/alternative; boundary=0015174bedcecd94860470afaf70 Subject: [Sip] Usage of the 'Route' header. X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2009 06:37:05 -0000 --0015174bedcecd94860470afaf70 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, Regarding the usage of the Route header. Must this header also appear in the RESPONSE to a request in which this header appeared, or we can rely on the 'Via' header for routing the response back to the sender? I've read the relevant RFC's and couldn't find an explicit reference for this matter. If someone can point me to the exact clause and RFC I'll be grateful. Also, an explicit authoritative answer would be much appreciated. (Note that i'm talking about the 'Route' field, and not the 'Record-Route' field for which there are alot of references in the RFCs) Thanks, Yoav. --0015174bedcecd94860470afaf70 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,
=A0
Regarding the usage of the Route header.=A0Must this header also appea= r in the RESPONSE to a request in which this header appeared, or we can rel= y on the 'Via' header for routing the response back to the sender?<= /div>
=A0
I've read the relevant RFC's and couldn't find an=A0explic= it=A0reference for this matter. If someone can point me to the exact clause= and RFC I'll be grateful. Also, an explicit authoritative answer would= be much=A0appreciated.
=A0
(Note that i'm talking about the 'Route' field, and not th= e 'Record-Route' field for which there are alot of references in th= e RFCs)
=A0
Thanks,
Yoav.
--0015174bedcecd94860470afaf70-- From christer.holmberg@ericsson.com Sun Aug 9 04:08:10 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB27F3A681E for ; Sun, 9 Aug 2009 04:08:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.469 X-Spam-Level: X-Spam-Status: No, score=-5.469 tagged_above=-999 required=5 tests=[AWL=0.779, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zk1tny4aWTwB for ; Sun, 9 Aug 2009 04:08:10 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id A8F743A68D1 for ; Sun, 9 Aug 2009 04:08:08 -0700 (PDT) X-AuditID: c1b4fb3c-b7b30ae000002b54-42-4a7eae19f03c Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 5F.9B.11092.91EAE7A4; Sun, 9 Aug 2009 13:08:09 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sun, 9 Aug 2009 13:07:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA18E1.A5BAEB2E" Date: Sun, 9 Aug 2009 13:07:56 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Usage of the 'Route' header. Thread-Index: AcoYu9fwiOHiKct/SjKqX9VxfHyHmgAJbBtw References: From: "Christer Holmberg" To: "Yoav Gaziel" , X-OriginalArrivalTime: 09 Aug 2009 11:07:57.0528 (UTC) FILETIME=[A699B580:01CA18E1] X-Brightmail-Tracker: AAAAAA== Subject: Re: [Sip] Usage of the 'Route' header. X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2009 11:08:10 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA18E1.A5BAEB2E Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi, =20 You always rely on the Via for routing responses back to the sender. You never rely on the Route header for routing responses. =20 Regards, =20 Christer ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Yoav Gaziel Sent: Sunday, August 09, 2009 9:36 AM To: sip@ietf.org Subject: [Sip] Usage of the 'Route' header. Hi, =20 Regarding the usage of the Route header. Must this header also appear in the RESPONSE to a request in which this header appeared, or we can rely on the 'Via' header for routing the response back to the sender? =20 I've read the relevant RFC's and couldn't find an explicit reference for this matter. If someone can point me to the exact clause and RFC I'll be grateful. Also, an explicit authoritative answer would be much appreciated. =20 (Note that i'm talking about the 'Route' field, and not the 'Record-Route' field for which there are alot of references in the RFCs) =20 Thanks, Yoav. ------_=_NextPart_001_01CA18E1.A5BAEB2E Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hi,
 
You always rely on the Via for routing = responses back to=20 the sender. You never rely on the Route header for routing=20 responses.
 
Regards,
 
Christer

From: sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org] On Behalf Of Yoav = Gaziel
Sent:=20 Sunday, August 09, 2009 9:36 AM
To: = sip@ietf.org
Subject:=20 [Sip] Usage of the 'Route' header.

Hi,
 
Regarding the usage of the Route header. Must this header also = appear=20 in the RESPONSE to a request in which this header appeared, or we can = rely on=20 the 'Via' header for routing the response back to the sender?
 
I've read the relevant RFC's and couldn't find=20 an explicit reference for this matter. If someone can point me = to the=20 exact clause and RFC I'll be grateful. Also, an explicit authoritative = answer=20 would be much appreciated.
 
(Note that i'm talking about the 'Route' field, and not the = 'Record-Route'=20 field for which there are alot of references in the RFCs)
 
Thanks,
Yoav.
------_=_NextPart_001_01CA18E1.A5BAEB2E-- From tzieleniewski@gmail.com Sun Aug 9 13:13:01 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E7BA3A6C5F for ; Sun, 9 Aug 2009 13:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PLnEhLNHOUAK for ; Sun, 9 Aug 2009 13:13:00 -0700 (PDT) Received: from mail-bw0-f219.google.com (mail-bw0-f219.google.com [209.85.218.219]) by core3.amsl.com (Postfix) with ESMTP id D838B3A693E for ; Sun, 9 Aug 2009 13:12:59 -0700 (PDT) Received: by bwz19 with SMTP id 19so2271331bwz.37 for ; Sun, 09 Aug 2009 13:13:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=EBQP+CV57stQUdi1QddmvMKoqHDlbfFLJdmvwpYvau4=; b=ddVCj9AQ8Xg8G+y07OR3XIpwMDdILsF8Zk9I+5mlSLO4QRF1NaoVGVaTb9HzGhYOIp T9RkqlrX2BtCGawJWJYbXsm1jcwq5GrLJl3+Ek8mMHWBT0Q1GhzP+qNNZHfs95yfeEhK zfmXqp6ENRHzIM6DHaNFWczY18mcObI6FYReM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=DNA/GgjCOziUSxN+chKX9WCUAyy0a4f9Lf1fgZzkSCXWv1e3awBLCcttFeUOJHnnro AxkE8MzoclZFF7m+WO8MXCnMOqDVquVPYq3gJmayG+FXd4uALx4J3rHtYI7ZJTxdVroo wMCBnlecttieKWv1otO5XLKmvsvtNt4YQls8Y= MIME-Version: 1.0 Received: by 10.223.124.147 with SMTP id u19mr756405far.28.1249848776481; Sun, 09 Aug 2009 13:12:56 -0700 (PDT) In-Reply-To: References: Date: Sun, 9 Aug 2009 22:12:56 +0200 Message-ID: <5fd52d7a0908091312j220bd9fvd690bf939740f4f7@mail.gmail.com> From: Tomasz Zieleniewski To: Yoav Gaziel Content-Type: multipart/alternative; boundary=001636c5a9bf587afb0470bb1855 Cc: sip@ietf.org Subject: Re: [Sip] Usage of the 'Route' header. X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2009 20:13:01 -0000 --001636c5a9bf587afb0470bb1855 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Yoav, Route header is used only for request routuing, responses have different procedures which utilize the Via header values. BTW some time ago I wrote a short post about Route header, might give u some more info. http://ictbackyard.com/?p=10 Kind regards, - Tomasz Zieleniewski 2009/8/9 Yoav Gaziel > Hi, > > Regarding the usage of the Route header. Must this header also appear in > the RESPONSE to a request in which this header appeared, or we can rely on > the 'Via' header for routing the response back to the sender? > > I've read the relevant RFC's and couldn't find an explicit reference for > this matter. If someone can point me to the exact clause and RFC I'll be > grateful. Also, an explicit authoritative answer would be much appreciated. > > (Note that i'm talking about the 'Route' field, and not the 'Record-Route' > field for which there are alot of references in the RFCs) > > Thanks, > Yoav. > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > --001636c5a9bf587afb0470bb1855 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Yoav,

Route header is used only for request routuing,
respons= es have different procedures which utilize the Via header values.
BTW so= me time ago I wrote a short post about Route header, might give u some more= info.
http://ictbackyard.com/?p=3D10

Kind regards,
- Tomasz Zieleniewski

2009/8/9 Yoav Gaziel <ygaziel@gmail.com>
=
Hi,
=A0
Regarding the usage of the Route header.=A0Must this header also appea= r in the RESPONSE to a request in which this header appeared, or we can rel= y on the 'Via' header for routing the response back to the sender?<= /div>
=A0
I've read the relevant RFC's and couldn't find an=A0explic= it=A0reference for this matter. If someone can point me to the exact clause= and RFC I'll be grateful. Also, an explicit authoritative answer would= be much=A0appreciated.
=A0
(Note that i'm talking about the 'Route' field, and not th= e 'Record-Route' field for which there are alot of references in th= e RFCs)
=A0
Thanks,
Yoav.

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

--001636c5a9bf587afb0470bb1855-- From dgoyal@tnsi.com Fri Aug 7 07:36:37 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD82B28C19A for ; Fri, 7 Aug 2009 07:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aoXcZQwrfazM for ; Fri, 7 Aug 2009 07:36:33 -0700 (PDT) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id 388833A6892 for ; Fri, 7 Aug 2009 07:36:32 -0700 (PDT) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.31563932; Fri, 07 Aug 2009 10:39:29 -0400 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.219]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Fri, 7 Aug 2009 10:36:05 -0400 From: "Goyal, Devki" To: sandip gangakhedkar , "sip@ietf.org" Date: Fri, 7 Aug 2009 10:36:04 -0400 Thread-Topic: [Sip] Contact header in 200 OK Thread-Index: AcoXY7gBHy7KIvftQyO5Hdlo1VUsCwACD8QA Message-ID: <754963199212404AB8E9CFCA6C3D0CDA0725BCA02C@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <6208da1a0908060745w259dd980qd79428affb6cc503@mail.gmail.com> In-Reply-To: <6208da1a0908060745w259dd980qd79428affb6cc503@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_754963199212404AB8E9CFCA6C3D0CDA0725BCA02CTNSMAILNAwin2_" MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 10 Aug 2009 04:51:49 -0700 Subject: Re: [Sip] Contact header in 200 OK X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2009 14:39:44 -0000 --_000_754963199212404AB8E9CFCA6C3D0CDA0725BCA02CTNSMAILNAwin2_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Sandip Why do you say that RFC doesn't talk about Contact for 200 OK response of I= NVITE? It says that Contact header is mandatory for INVITE response only. Header field where proxy ACK BYE CAN INV OPT REG Contact 2xx - - - m o o For OPTIONS, REGISTER it is optional and for rest of the messages (BYE, CAN= CEL ) it is forbidden. Regards Devki ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of sandi= p gangakhedkar Sent: Thursday, August 06, 2009 10:46 AM To: sip@ietf.org Subject: [Sip] Contact header in 200 OK Hi all, I'd like to know if the Contact header is mandatory for a 200 OK response t= o an INVITE request. The RFC doesnt explicitly mention anything in this regard although a 200 OK= is mandatory for a REGISTER request. If the originating endpoint receives the Contact header in the 180 Ringing = response (which I assume is mandatory), then it knows the location of the r= emote endpoint, in which case the Contact header would be redundant in the = 200 OK response. Waiting for some expert intervention.. :) Regards, -- Sandip Gangakhedkar Mobile:+91-97396-99916 Office: +91-80-4363-3899 Profile: http://www.linkedin.com/in/sandipg ________________________________ This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. --_000_754963199212404AB8E9CFCA6C3D0CDA0725BCA02CTNSMAILNAwin2_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Sandip<= /p>

Why do you say that RFC doesn’t = talk about Contact for 200 OK response of INVITE?<= /p>

It says that Contact header is mandato= ry for INVITE response only.

 

Header fie=
ld          where   =
proxy ACK BYE CAN INV OPT REG
Contact&nb=
sp;            =
   2xx          =
; -   -   -   m   o   o
 =
;
For OPTION=
S, REGISTER it is optional and for rest of the messages (BYE, CANCEL ) it i=
s forbidden.
 =
;
Regards
Devki

 

 

From: sip-= bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of sandip gangakhe= dkar
Sent: Thursday, August 06, 2= 009 10:46 AM
To: sip@ietf.org
Subject: [Sip] Contact heade= r in 200 OK

 

Hi all,

I'd like to know if the Contact header is mandatory for a 200 OK response t= o an INVITE request.

The RFC doesnt explicitly mention anything in this regard although a 200 OK= is mandatory for a REGISTER request.

If the originating endpoint receives the Contact header in the 180 Ringing = response (which I assume is mandatory), then it knows the location of the r= emote endpoint, in which case the Contact header would be redundant in the = 200 OK response.

Waiting for some expert intervention.. :)

Regards,
--
Sandip Gangakhedkar
Mobile:= +91-97396-99916
Office: +91-80-4363-3899
Profile: http://www.linkedin= .com/in/sandipg


This e-mail message is for t= he sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction Network Serv= ices.
Any unauthorised review, use, disclosure or distribution is prohibited. If = you
are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message.

 --_000_754963199212404AB8E9CFCA6C3D0CDA0725BCA02CTNSMAILNAwin2_-- From sandipfloyd@gmail.com Fri Aug 7 06:51:05 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9CD63A6910 for ; Fri, 7 Aug 2009 06:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gLwHq-T7Rtwu for ; Fri, 7 Aug 2009 06:51:04 -0700 (PDT) Received: from mail-yw0-f188.google.com (mail-yw0-f188.google.com [209.85.211.188]) by core3.amsl.com (Postfix) with ESMTP id B5C433A6907 for ; Fri, 7 Aug 2009 06:51:04 -0700 (PDT) Received: by ywh26 with SMTP id 26so2137414ywh.5 for ; Fri, 07 Aug 2009 06:51:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:content-type; bh=REzbhKmMA1kmkA4DrbmVQ9h/0v8lZcN9A5CrIczFdEI=; b=UmvB1gAh9Jx/2Q2AzGrH684AF06zYWp7KUzYPx/7u9PhOptZmNM9GpRsz7BAFLlDe1 /mvcCwnccXl8ZeDd9njIKTf+VBz51w2y6QTILA57K+TcGvp4YGt2kmeYWv0dmCwOKI+m YB6YU+VLFK/1pR6mEAuwGuK/iTPx5xxPGk4wc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=RMOhGwW6pUe+JlU5KDabD+5jMI/6Ca4+RBYrGXETCLfYAstpNqS391wQH3QP5GLtyk 2CKRCPHZMAVpfpo3iN6XLFSPI7kSMidm4SqXtROVXWNMr9+q/7RqBjsTDj5QVaVD8mtk 9RklWr+gq3Uo0+S1/fzH1zHJxOWscMow4zX9c= MIME-Version: 1.0 Received: by 10.150.51.13 with SMTP id y13mr2495747yby.155.1249653066221; Fri, 07 Aug 2009 06:51:06 -0700 (PDT) In-Reply-To: <3100473D52017B48B9068E079BE2A6E604005E36@ZMY16EXM67.ds.mot.com> References: <6208da1a0908060745w259dd980qd79428affb6cc503@mail.gmail.com> <3100473D52017B48B9068E079BE2A6E604005E36@ZMY16EXM67.ds.mot.com> From: sandip gangakhedkar Date: Fri, 7 Aug 2009 19:20:46 +0530 Message-ID: <6208da1a0908070650y28ce2296u88dba1d101c59ef7@mail.gmail.com> To: T Satyanarayana-A12694 , sip@ietf.org Content-Type: multipart/alternative; boundary=000e0cd4d51e1acad204708d870e X-Mailman-Approved-At: Mon, 10 Aug 2009 04:54:17 -0700 Subject: Re: [Sip] Contact header in 200 OK X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2009 13:51:06 -0000 --000e0cd4d51e1acad204708d870e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Satya, Thanks for the reply..didn't locate that table at first :) Regards, Sandip On Fri, Aug 7, 2009 at 7:17 PM, T Satyanarayana-A12694 < satyanarayana.t@motorola.com> wrote: > The RFC does mention this. In table 2, on page 162. > > Header field where proxy ACK BYE CAN INV OPT REG > ___________________________________________________________ > Contact 2xx - - - m o o > regards > Satya T > > > ------------------------------ > *From:* sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] *On Behalf Of *sandip > gangakhedkar > *Sent:* Thursday, August 06, 2009 8:16 PM > *To:* sip@ietf.org > *Subject:* [Sip] Contact header in 200 OK > > Hi all, > > I'd like to know if the Contact header is mandatory for a 200 OK response > to an INVITE request. > > The RFC doesnt explicitly mention anything in this regard although a 200 OK > is mandatory for a REGISTER request. > > If the originating endpoint receives the Contact header in the 180 Ringing > response (which I assume is mandatory), then it knows the location of the > remote endpoint, in which case the Contact header would be redundant in the > 200 OK response. > > Waiting for some expert intervention.. :) > > Regards, > -- > Sandip Gangakhedkar > Mobile:+91-97396-99916 > Office: +91-80-4363-3899 > Profile: http://www.linkedin.com/in/sandipg > --000e0cd4d51e1acad204708d870e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Satya,

Thanks for the reply..didn't locate that table at firs= t :)

Regards,

Sandip

On Fri= , Aug 7, 2009 at 7:17 PM, T Satyanarayana-A12694 <satyanarayana.t@motorola.com> wrote:
The RFC does mention this. In table 2, on page=20 162.
=A0
=A0=A0=A0= =A0=A0 Header=20 field=A0=A0=A0=A0=A0=A0=A0=A0=A0 where=A0=A0=20 proxy ACK BYE CAN INV OPT REG
=A0=A0=A0=A0=A0=20 ___________________________________________________________
=A0=A0=A0=A0= =A0=20 Contact=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=20 2xx=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -=A0=A0=20 -=A0=A0 -=A0=A0 m=A0=A0 o=A0=A0=20 o
regards
Satya=A0T

=A0
From: sip-bounces@ietf.org=20 [mailto:sip-bounc= es@ietf.org] On Behalf Of sandip=20 gangakhedkar
Sent: Thursday, August 06, 2009 8:16 PM
To:=20 sip@ietf.org
Su= bject: [Sip] Contact header in 200=20 OK

Hi all,

I'd like to know if the Contact header is man= datory=20 for a 200 OK response to an INVITE request.

The RFC doesnt explicit= ly=20 mention anything in this regard although a 200 OK is mandatory for a REGIST= ER=20 request.

If the originating endpoint receives the Contact header in = the=20 180 Ringing response (which I assume is mandatory), then it knows the locat= ion=20 of the remote endpoint, in which case the Contact header would be redundant= in=20 the 200 OK response.

Waiting for some expert intervention.. :)=20

Regards,
--
Sandip=20 Gangakhedkar
Mobile:+91-97396-99916
Office: +91-80-4363-3899
Profi= le:=20 http://www= .linkedin.com/in/sandipg


--000e0cd4d51e1acad204708d870e-- From dean.willis@softarmor.com Mon Aug 10 22:27:09 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7E583A6828 for ; Mon, 10 Aug 2009 22:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_93=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yQ4SoderqAbr for ; Mon, 10 Aug 2009 22:27:06 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 5D0223A63EB for ; Mon, 10 Aug 2009 22:27:06 -0700 (PDT) Received: from [192.168.2.102] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n7B5R7aB017852 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 11 Aug 2009 00:27:09 -0500 Message-ID: <4A810125.6070609@softarmor.com> Date: Tue, 11 Aug 2009 00:27:01 -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: multipart/mixed; boundary="------------020508030100090204010705" Subject: [Sip] Progress on draft-ietfsip-record-route-fix X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 05:27:09 -0000 This is a multi-part message in MIME format. --------------020508030100090204010705 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Please be advised of changes made as a result of IESG review: -------- Original Message -------- Subject: Re: DISCUSS: draft-ietf-sip-record-route-fix Date: Tue, 4 Aug 2009 23:04:35 +0200 From: thomas froment To: iesg@ietf.org, sip-chairs@tools.ietf.org, draft-ietf-sip-record-route-fix@tools.ietf.org CC: nils@ohlmeier.com References: <985094.76974.qm@web56801.mail.re3.yahoo.com> <4A5F59C7.5080500@softarmor.com> Hi, version -08 of record-route fix has just been submitted (should be athttp://tools.ietf.org/html/draft-ietf-sip-record-route-fix soon) Change log: - Changed its status from BCP to PS, - Take into account IESG reviews and subsequent comments on the mailing lists, they were summarized in Robert Sparks's document (rrf.txt), so it has been integrated in version -08 with minor refactoring from the authors (me and Ben). The thoughest part was related to the SIP/SIPS question raised by Cullen (http://datatracker.ietf.org/idtracker/draft-ietf-sip-record-route-fix/comment/98624/), so here is the text that was added in version -08 to answer this question: "Thus, if the transport protocol changed between its incoming and outgoing sides, the proxy SHOULD use the double Record-Route technique and SHOULD add a transport parameter to each of the Record-Route URIs it inserts. With the exception that if TLS is used as the transport protocol on either side of the proxy, the URI chosen to place in the Record-Route header field value reflecting the interface using TLS will need to leverage the [RFC3263] mechanisms to indicate that TLS must be used rather attempting to use the deprecated "transport=tls" URI parameter. See [RFC3261] Section 26.2.2 and [I-D.ietf-sip-sips] Section 3.1.4 for more discussion." Brds, Thomas --------------020508030100090204010705 Content-Type: text/plain; name="draft-ietf-sip-record-route-fix-08.txt" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="draft-ietf-sip-record-route-fix-08.txt" CgoKTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBULiBGcm9tZW50CkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAoVW5hZmZpbGlhdGVkKQpJbnRlbmRlZCBzdGF0 dXM6IFN0YW5kYXJkcyBUcmFjayAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQy4g TGViZWwKRXhwaXJlczogRmVicnVhcnkgNSwgMjAxMCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBCLiBCb25uYWVyZW5zCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBBbGNhdGVsLUx1Y2VudAogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQXVndXN0 IDQsIDIwMDkKCgpBZGRyZXNzaW5nIFJlY29yZC1Sb3V0ZSBpc3N1ZXMgaW4gdGhlIFNlc3Np b24gSW5pdGlhdGlvbiBQcm90b2NvbCAoU0lQKQogICAgICAgICAgICAgICAgICAgZHJhZnQt aWV0Zi1zaXAtcmVjb3JkLXJvdXRlLWZpeC0wOAoKU3RhdHVzIG9mIHRoaXMgTWVtbwoKICAg VGhpcyBJbnRlcm5ldC1EcmFmdCBpcyBzdWJtaXR0ZWQgdG8gSUVURiBpbiBmdWxsIGNvbmZv cm1hbmNlIHdpdGggdGhlCiAgIHByb3Zpc2lvbnMgb2YgQkNQIDc4IGFuZCBCQ1AgNzkuICBU aGlzIGRvY3VtZW50IG1heSBjb250YWluIG1hdGVyaWFsCiAgIGZyb20gSUVURiBEb2N1bWVu dHMgb3IgSUVURiBDb250cmlidXRpb25zIHB1Ymxpc2hlZCBvciBtYWRlIHB1YmxpY2x5CiAg IGF2YWlsYWJsZSBiZWZvcmUgTm92ZW1iZXIgMTAsIDIwMDguICBUaGUgcGVyc29uKHMpIGNv bnRyb2xsaW5nIHRoZQogICBjb3B5cmlnaHQgaW4gc29tZSBvZiB0aGlzIG1hdGVyaWFsIG1h eSBub3QgaGF2ZSBncmFudGVkIHRoZSBJRVRGCiAgIFRydXN0IHRoZSByaWdodCB0byBhbGxv dyBtb2RpZmljYXRpb25zIG9mIHN1Y2ggbWF0ZXJpYWwgb3V0c2lkZSB0aGUKICAgSUVURiBT dGFuZGFyZHMgUHJvY2Vzcy4gIFdpdGhvdXQgb2J0YWluaW5nIGFuIGFkZXF1YXRlIGxpY2Vu c2UgZnJvbQogICB0aGUgcGVyc29uKHMpIGNvbnRyb2xsaW5nIHRoZSBjb3B5cmlnaHQgaW4g c3VjaCBtYXRlcmlhbHMsIHRoaXMKICAgZG9jdW1lbnQgbWF5IG5vdCBiZSBtb2RpZmllZCBv dXRzaWRlIHRoZSBJRVRGIFN0YW5kYXJkcyBQcm9jZXNzLCBhbmQKICAgZGVyaXZhdGl2ZSB3 b3JrcyBvZiBpdCBtYXkgbm90IGJlIGNyZWF0ZWQgb3V0c2lkZSB0aGUgSUVURiBTdGFuZGFy ZHMKICAgUHJvY2VzcywgZXhjZXB0IHRvIGZvcm1hdCBpdCBmb3IgcHVibGljYXRpb24gYXMg YW4gUkZDIG9yIHRvCiAgIHRyYW5zbGF0ZSBpdCBpbnRvIGxhbmd1YWdlcyBvdGhlciB0aGFu IEVuZ2xpc2guCgogICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9m IHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZwogICBUYXNrIEZvcmNlIChJRVRGKSwgaXRzIGFy ZWFzLCBhbmQgaXRzIHdvcmtpbmcgZ3JvdXBzLiAgTm90ZSB0aGF0CiAgIG90aGVyIGdyb3Vw cyBtYXkgYWxzbyBkaXN0cmlidXRlIHdvcmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LQog ICBEcmFmdHMuCgogICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxp ZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBtb250aHMKICAgYW5kIG1heSBiZSB1cGRhdGVkLCBy ZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnkKICAgdGlt ZS4gIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZl cmVuY2UKICAgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMgIndvcmsg aW4gcHJvZ3Jlc3MuIgoKICAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC1EcmFmdHMg Y2FuIGJlIGFjY2Vzc2VkIGF0CiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaWV0Zi8xaWQtYWJz dHJhY3RzLnR4dC4KCiAgIFRoZSBsaXN0IG9mIEludGVybmV0LURyYWZ0IFNoYWRvdyBEaXJl Y3RvcmllcyBjYW4gYmUgYWNjZXNzZWQgYXQKICAgaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFk b3cuaHRtbC4KCiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBleHBpcmUgb24gRmVicnVh cnkgNSwgMjAxMC4KCkNvcHlyaWdodCBOb3RpY2UKCiAgIENvcHlyaWdodCAoYykgMjAwOSBJ RVRGIFRydXN0IGFuZCB0aGUgcGVyc29ucyBpZGVudGlmaWVkIGFzIHRoZQogICBkb2N1bWVu dCBhdXRob3JzLiAgQWxsIHJpZ2h0cyByZXNlcnZlZC4KCgoKRnJvbWVudCwgZXQgYWwuICAg ICAgICAgRXhwaXJlcyBGZWJydWFyeSA1LCAyMDEwICAgICAgICAgICAgICAgIFtQYWdlIDFd CgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICBTSVAgUmVjb3JkLVJvdXRlIGZpeCAgICAg ICAgICAgICAgIEF1Z3VzdCAyMDA5CgoKICAgVGhpcyBkb2N1bWVudCBpcyBzdWJqZWN0IHRv IEJDUCA3OCBhbmQgdGhlIElFVEYgVHJ1c3QncyBMZWdhbAogICBQcm92aXNpb25zIFJlbGF0 aW5nIHRvIElFVEYgRG9jdW1lbnRzIGluIGVmZmVjdCBvbiB0aGUgZGF0ZSBvZgogICBwdWJs aWNhdGlvbiBvZiB0aGlzIGRvY3VtZW50IChodHRwOi8vdHJ1c3RlZS5pZXRmLm9yZy9saWNl bnNlLWluZm8pLgogICBQbGVhc2UgcmV2aWV3IHRoZXNlIGRvY3VtZW50cyBjYXJlZnVsbHks IGFzIHRoZXkgZGVzY3JpYmUgeW91ciByaWdodHMKICAgYW5kIHJlc3RyaWN0aW9ucyB3aXRo IHJlc3BlY3QgdG8gdGhpcyBkb2N1bWVudC4KCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCkZyb21lbnQsIGV0IGFsLiAgICAgICAgIEV4cGlyZXMgRmVi cnVhcnkgNSwgMjAxMCAgICAgICAgICAgICAgICBbUGFnZSAyXQoMCkludGVybmV0LURyYWZ0 ICAgICAgICAgICAgU0lQIFJlY29yZC1Sb3V0ZSBmaXggICAgICAgICAgICAgICBBdWd1c3Qg MjAwOQoKCkFic3RyYWN0CgogICBBIHR5cGljYWwgZnVuY3Rpb24gb2YgYSBTZXNzaW9uIElu aXRpYXRpb24gUHJvdG9jb2wgKFNJUCkgUHJveHkgaXMgdG8KICAgaW5zZXJ0IGEgUmVjb3Jk LVJvdXRlIGhlYWRlciBpbnRvIGluaXRpYWwsIGRpYWxvZyBjcmVhdGluZyByZXF1ZXN0cwog ICBpbiBvcmRlciB0byBtYWtlIHN1YnNlcXVlbnQsIGluLWRpYWxvZyByZXF1ZXN0cyBwYXNz IHRocm91Z2ggaXQuCiAgIFRoaXMgaGVhZGVyIGNvbnRhaW5zIGEgU0lQIFVuaWZvcm0gUmVz b3VyY2UgSWRlbnRpZmllciAoVVJJKQogICBpbmRpY2F0aW5nIHdoZXJlIGFuZCBob3cgdGhl IHN1YnNlcXVlbnQgcmVxdWVzdHMgc2hvdWxkIGJlIHNlbnQgdG8KICAgcmVhY2ggdGhlIHBy b3h5LiAgTGlrZSBhbnkgU0lQIFVSSSwgaXQgY2FuIGNvbnRhaW4gU0lQIG9yIFNJUFMKICAg c2NoZW1lcywgSVB2NCBvciBJUHY2IGFkZHJlc3NlcywgYW5kIFVSSSBwYXJhbWV0ZXJzIHRo YXQgY291bGQKICAgaW5mbHVlbmNlIHRoZSByb3V0aW5nIHN1Y2ggYXMgdGhlIHRyYW5zcG9y dCBwYXJhbWV0ZXIgKGZvciBleGFtcGxlCiAgIHRyYW5zcG9ydD10Y3ApLCBvciBhIGNvbXBy ZXNzaW9uIGluZGljYXRpb24gbGlrZSAiY29tcD1zaWdjb21wIi4KICAgV2hlbiBhIHByb3h5 IGhhcyB0byBjaGFuZ2Ugc29tZSBvZiB0aG9zZSBwYXJhbWV0ZXJzIGJldHdlZW4gaXRzCiAg IGluY29taW5nIGFuZCBvdXRnb2luZyBpbnRlcmZhY2VzIChtdWx0aS1ob21lZCBwcm94aWVz LCB0cmFuc3BvcnQKICAgcHJvdG9jb2wgc3dpdGNoaW5nIG9yIElQdjQgdG8gSVB2NiBzY2Vu YXJpb3MuLi4pLCB0aGUgcXVlc3Rpb24gYXJpc2VzCiAgIG9uIHdoYXQgc2hvdWxkIGJlIHB1 dCBpbiBSZWNvcmQtUm91dGUgaGVhZGVyKHMpLiAgSXQgaXMgbm90IHBvc3NpYmxlCiAgIHRv IG1ha2Ugb25lIGhlYWRlciBoYXZlIHRoZSBjaGFyYWN0ZXJpc3RpY3Mgb2YgYm90aCBpbnRl cmZhY2VzIGF0IHRoZQogICBzYW1lIHRpbWUuICBUaGlzIGRvY3VtZW50IGFpbXMgdG8gY2xh cmlmeSB0aGVzZSBzY2VuYXJpb3MgYW5kIGZpeAogICBidWdzIGFscmVhZHkgaWRlbnRpZmll ZCBvbiB0aGlzIHRvcGljOyBpdCBmb3JtYWxseSByZWNvbW1lbmRzIHRoZSB1c2UKICAgb2Yg dGhlIGRvdWJsZSBSZWNvcmQtUm91dGUgdGVjaG5pcXVlIGFzIGFuIGFsdGVybmF0aXZlIHRv IHRoZSBjdXJyZW50CiAgIFJGQzMyNjEgdGV4dCwgd2hpY2ggZGVzY3JpYmVzIG9ubHkgYSBS ZWNvcmQtUm91dGUgcmV3cml0aW5nIHNvbHV0aW9uLgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKRnJvbWVudCwgZXQgYWwuICAgICAgICAgRXhwaXJlcyBGZWJydWFyeSA1LCAy MDEwICAgICAgICAgICAgICAgIFtQYWdlIDNdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAg ICBTSVAgUmVjb3JkLVJvdXRlIGZpeCAgICAgICAgICAgICAgIEF1Z3VzdCAyMDA5CgoKVGFi bGUgb2YgQ29udGVudHMKCiAgIDEuICBJbnRyb2R1Y3Rpb24gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNQogICAyLiAgVGVybWlub2xvZ3kg IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDYK ICAgMy4gIFByb2JsZW0gc3RhdGVtZW50ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuICA3CiAgICAgMy4xLiAgQmFja2dyb3VuZDogbXVsdGktaG9tZWQg cHJveGllcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNwogICAgIDMuMi4gIElkZW50 aWZpZWQgcHJvYmxlbXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g IDgKICAgNC4gIFJlY29yZC1Sb3V0ZSByZXdyaXRpbmcgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIDEwCiAgIDUuICBEb3VibGUgUmVjb3JkLVJvdXRpbmcgIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMQogICA2LiAgVXNhZ2Ug b2YgVHJhbnNwb3J0IHByb3RvY29sIHBhcmFtZXRlciAgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gMTUKICAgICA2LjEuICBVQSBpbXBsZW1lbnRhdGlvbnMgcHJvYmxlbXMgYW5kIHJlY29t bWVuZGF0aW9ucyAgLiAuIC4gLiAuIDE1CiAgICAgNi4yLiAgUHJveHkgaW1wbGVtZW50YXRp b25zIHByb2JsZW1zIGFuZCByZWNvbW1lbmRhdGlvbnMgLiAuIC4gLiAxOQogICA3LiAgQ29u Y2x1c2lvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gMjEKICAgOC4gIElBTkEgQ29uc2lkZXJhdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDIyCiAgIDkuICBTZWN1cml0eSBDb25zaWRlcmF0 aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyMwogICAxMC4g QWNrbm93bGVkZ21lbnRzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gMjQKICAgMTEuIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDI1CiAgICAgMTEuMS4gTm9ybWF0aXZlIFJl ZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyNQogICAg IDExLjIuIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gMjUKICAgQXV0aG9ycycgQWRkcmVzc2VzIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDI2CgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgpGcm9tZW50LCBldCBhbC4gICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDUs IDIwMTAgICAgICAgICAgICAgICAgW1BhZ2UgNF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAg ICAgIFNJUCBSZWNvcmQtUm91dGUgZml4ICAgICAgICAgICAgICAgQXVndXN0IDIwMDkKCgox LiAgSW50cm9kdWN0aW9uCgogICBPdmVyIHRoZSB5ZWFycywgaXQgaGFzIGJlZW4gbm90aWNl ZCBpbiBpbnRlcm9wZXJhYmlsaXR5IGV2ZW50cyBsaWtlCiAgIFNJUGl0LCB0aGF0IG1hbnkg aW1wbGVtZW50YXRpb25zIGhhZCBpbnRlcm9wZXJhYmlsaXR5IHByb2JsZW1zIGR1ZSB0bwog ICB2YXJpb3VzIFJlY29yZC1Sb3V0aW5nIGlzc3VlcyBvciBtaXNpbnRlcnByZXRhdGlvbnMg b2YgW1JGQzMyNjFdLCBpbgogICBwYXJ0aWN1bGFyIHdoZW4gYSBjaGFuZ2Ugb2NjdXJzIGJl dHdlZW4gdGhlIGluY29taW5nIGFuZCBvdXRnb2luZwogICBzaWRlcyBvZiBhIHByb3h5OiB0 cmFuc3BvcnQgcHJvdG9jb2wgc3dpdGNoaW5nLCAibXVsdGktaG9tZWQiIHByb3hpZXMKICAg KGluY2x1ZGluZyBJUHY0IHRvIElQdjYgaW50ZXJmYWNlIGNoYW5nZXMpLC4uLiAgTXVsdGlw bGUgZG9jdW1lbnRzCiAgIGhhdmUgYWRkcmVzc2VkIHRoZSBxdWVzdGlvbiwgZWFjaCBvZiB0 aGVtIGdlbmVyYWxseSBwcm92aWRpbmcgYW4KICAgYWRlcXVhdGUgcmVjb21tZW5kYXRpb24g Zm9yIGl0cyBzcGVjaWZpYyB1c2UgY2FzZSwgYnV0IG5vbmUgb2YgdGhlbQogICBnaXZlcyBh IGdlbmVyYWwgc29sdXRpb24gb3IgcHJvdmlkZXMgYSBjb2hlcmVudCBzZXQgb2YKICAgY2xh cmlmaWNhdGlvbnM6CgogICAgICAtIFtSRkMzNDg2XSwgc2VjdGlvbiA2LCBkZXNjcmliZXMg dGhlIGRvdWJsZSBSZWNvcmQtUm91dGluZyBhcyBhbgogICAgICBhbHRlcm5hdGl2ZSB0byB0 aGUgUmVjb3JkLVJvdXRlIHJld3JpdGluZyBpbiByZXNwb25zZXMuICBUaGlzCiAgICAgIGRv Y3VtZW50IGlzIGxpbWl0ZWQgaW4gc2NvcGUgdG8gdGhlICJjb21wPXNpZ2NvbXAiIHBhcmFt ZXRlciB3aGVuCiAgICAgIGRvaW5nIGNvbXByZXNzaW9uIHdpdGggU0lHQ09NUC4KCiAgICAg IC0gW1JGQzM2MDhdLCBzZWN0aW9uIDYuMiwgcmVjb21tZW5kcyB0aGUgdXNhZ2Ugb2YgZG91 YmxlIFJlY29yZC0KICAgICAgUm91dGluZyBpbnN0ZWFkIG9mIHRoZSByZXdyaXRpbmcgc29s dXRpb24gZGVzY3JpYmVkIGluIFtSRkMzMjYxXQogICAgICBmb3IgIkR1YWwtaG9tZWQiIHBy b3hpZXMuICBUaG9zZSBhcmUgZGVmaW5lZCBhcyAicHJveGllcyBjb25uZWN0ZWQKICAgICAg dG8gdHdvIChvciBtb3JlKSBkaWZmZXJlbnQgbmV0d29ya3Mgc3VjaCB0aGF0IHJlcXVlc3Rz IGFyZQogICAgICByZWNlaXZlZCBvbiBvbmUgaW50ZXJmYWNlIGFuZCBwcm94aWVkIG91dCB0 aHJvdWdoIGFub3RoZXIgbmV0d29yawogICAgICBpbnRlcmZhY2UiLgoKICAgICAgLSBbSS1E LmlldGYtc2lwcGluZy12Ni10cmFuc2l0aW9uXSwgc2VjdGlvbiAzLjEuMSwgbWFuZGF0ZXMg ZG91YmxlCiAgICAgIFJlY29yZC1Sb3V0aW5nIGZvciBtdWx0aS1ob21lZCBwcm94aWVzIGRv aW5nIElQdjQvSVB2NgogICAgICB0cmFuc2l0aW9ucywgd2hlbiB0aGUgcHJveHkgaW5zZXJ0 cyBJUCBhZGRyZXNzZXMgaW4gdGhlIFJlY29yZC0KICAgICAgUm91dGUgaGVhZGVyIFVSSS4K CiAgIFRoZSBvYnNlcnZlZCBpbnRlcm9wZXJhYmlsaXR5IHByb2JsZW1zIGNhbiBiZSBleHBs YWluZWQgYnkgdGhlIGZhY3QKICAgdGhhdCwgZGVzcGl0ZSB0aGVzZSBtdWx0aXBsZSBkb2N1 bWVudHMsIHRoZSBSRkMzMjYxIGRlc2NyaXB0aW9uIGhhcwogICBub3QgYmVlbiBjaGFuZ2Vk LCBhbmQgbWFueSBpbXBsZW1lbnRhdGlvbnMgZG9uJ3Qgc3VwcG9ydCBleHRlbnNpb25zCiAg IGxpa2UgU2VydmljZS1Sb3V0ZSAoW1JGQzM2MDhdKSBvciBTSUdDT01QKFtSRkMzNDg2XSku CgogICBUaGlzIGRvY3VtZW50IGFsc28gYWltcyB0byBjbGFyaWZ5IGlkZW50aWZpZWQgYnVn IHJlZmVyZW5jZWQgaW4KICAgW0JVRzY2NF0uICBJbiBwYXJ0aWN1bGFyLCBpdCB0YWtlcyBp bnRvIGFjY291bnQgW0JVRzY2NF0KICAgcmVjb21tZW5kYXRpb24sIHdoaWNoIHNheXMgdGhh dCAidGhlIGxhbmd1YWdlIHRoYXQgZGVzY3JpYmVzIHRoaXMsCiAgIG5lZWRzIHRvIGNsZWFy bHkgY2FwdHVyZSB0aGF0IHRoaXMgYXBwbGllcyB0byBhbGwgdHlwZXMgb2YgZGlmZmVyZW50 CiAgIGludGVyZmFjZSBvbiBlYWNoIHNpZGUgaXNzdWVzLCBpbmNsdWRpbmcgSVB2NCBvbiBv bmUgc2lkZSBhbmQgSVB2NiBvbgogICB0aGUgb3RoZXIiLgoKCgoKCgoKCgoKRnJvbWVudCwg ZXQgYWwuICAgICAgICAgRXhwaXJlcyBGZWJydWFyeSA1LCAyMDEwICAgICAgICAgICAgICAg IFtQYWdlIDVdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICBTSVAgUmVjb3JkLVJvdXRl IGZpeCAgICAgICAgICAgICAgIEF1Z3VzdCAyMDA5CgoKMi4gIFRlcm1pbm9sb2d5CgogICBU aGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwg IlNIQUxMIE5PVCIsCiAgICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIs ICJNQVkiLCBhbmQgIk9QVElPTkFMIiBpbiB0aGlzCiAgIGRvY3VtZW50IGFyZSB0byBiZSBp bnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4gUkZDIDIxMTkgW1JGQzIxMTldLgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKRnJvbWVudCwgZXQgYWwu ICAgICAgICAgRXhwaXJlcyBGZWJydWFyeSA1LCAyMDEwICAgICAgICAgICAgICAgIFtQYWdl IDZdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICBTSVAgUmVjb3JkLVJvdXRlIGZpeCAg ICAgICAgICAgICAgIEF1Z3VzdCAyMDA5CgoKMy4gIFByb2JsZW0gc3RhdGVtZW50CgozLjEu ICBCYWNrZ3JvdW5kOiBtdWx0aS1ob21lZCBwcm94aWVzCgogICBBIG11bHRpLWhvbWVkIHBy b3h5IGlzIGEgcHJveHkgY29ubmVjdGVkLCBsaWtlIGEgcm91dGVyLCB0byB0d28gb3IKICAg bW9yZSBkaWZmZXJlbnQgbmV0d29ya3MsIHdpdGggYW4gaW50ZXJmYWNlIGludG8gZWFjaCBu ZXR3b3JrLCBzdWNoCiAgIHRoYXQgdHJhZmZpYyBjb21lcyAiaW4iIG9uZSBuZXR3b3JrIGFu ZCBnb2VzICJvdXQiIGEgZGlmZmVyZW50IG9uZS4KICAgQSBzaW1wbGUgZXhhbXBsZSBpcyBz aG93biBoZXJlOgoKICAgICAgICAgICAgICAgICstLS0tLSsKICAgICAgICAgICAgICAgIHwg VUExIHwKICAgICAgICAgICAgICAgICstLSstLSsKICAgICAgICAgICAgICAgICAgIHwgLjY2 CiAgICAxOTIuMC4yLjY0LzI2ICB8CiAgIC0tLS0tLS0tLS0tLS0tLS0rLS0tKy0uLi4KICAg ICAgICAgICAgICAgICAgICAgICAgfAogICAgICAgICAgICAgICAgICAgICAgICB8IC42NQog ICAgICAgICAgICAgICAgICAgICAgKy0rLSsKICAgICAgICAgICAgICAgICAgICAgIHwgUCB8 CiAgICAgICAgICAgICAgICAgICAgICArLSstKwogICAgICAgICAgICAgICAgICAgICAgICB8 IC4xMjkKICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAxOTIuMC4yLjEyOC8y NgogICAgICAgICAgICAgICAgICAuLi4tLS0rLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfCAuMTMwCiAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0rLS0rCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICB8IFVBMiB8CiAgICAgICAgICAgICAgICAgICAg ICAgICAgICArLS0rLS0rCgoKICAgRmlndXJlIDE6IG11bHRpLWhvbWVkIHByb3h5IGlsbHVz dHJhdGlvbgoKICAgVUExIGhhcyBvbmUgaW50ZXJmYWNlIHdpdGggSVAgYWRkcmVzcyAxOTIu MC4yLjY2CgogICBUaGUgUHJveHkgUCBoYXMgdHdvIGludGVyZmFjZXMgYW5kIHR3byBhZGRy ZXNzZXM6CgogICAgICAtLTE5Mi4wLjIuNjUKCiAgICAgIC0tMTkyLjAuMi4xMjkKCiAgIFVB MiBoYXMgb25lIGludGVyZmFjZSB3aXRoIGFkZHJlc3MsIDE5Mi4wLjIuMTMwLiAgVGhlcmUg aXMKICAgcG90ZW50aWFsbHkgbm8gSVAgbGV2ZWwgcm91dGUgYmV0d2VlbiBVQTEgYW5kIFVB MiAocGluZ2luZyBvcgogICB0cmFjZXJvdXRlIGRvZXMgbm90IHdvcmsgYmV0d2VlbiB0aGVz ZSB0d28gaG9zdHMpLiAgVGhleSBsaXZlIGluCiAgIGVudGlyZWx5IGRpZmZlcmVudCBzdWJu ZXR3b3Jrcy4gIEJ1dCB0aGV5IGNhbiBzdGlsbCBleGNoYW5nZSBTSVAKICAgbWVzc2FnZXMs IGJlY2F1c2UgUCBpcyBhIFNJUCBQcm94eS4gIFRoaXMgd29ya3MgaW4gU0lQIGJlY2F1c2Ug UCBjYW4KICAgYXBwbHkgcmVjb3JkLXJvdXRpbmcuCgogICBJbiBtb3N0IGNhc2VzLCB0aGVy ZSBpcyBzdGlsbCBzb21lIElQIGNvbm5lY3Rpdml0eSBiZXR3ZWVuIFVBMSBhbmQKCgoKRnJv bWVudCwgZXQgYWwuICAgICAgICAgRXhwaXJlcyBGZWJydWFyeSA1LCAyMDEwICAgICAgICAg ICAgICAgIFtQYWdlIDddCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICBTSVAgUmVjb3Jk LVJvdXRlIGZpeCAgICAgICAgICAgICAgIEF1Z3VzdCAyMDA5CgoKICAgVUEyLCBidXQgU0lQ IHByb3h5IGhhcyB0byBtYW5hZ2UgdGhlIFNJUCB0cmFmZmljIGJldHdlZW4gdGhlIHR3bwog ICBkaWZmZXJlbnQgInNpZGVzIiwgZS5nLiB3aXRoIHR3byBkaWZmZXJlbnQgSVAgYWRkcmVz c2VzOyBvciBvbmUgc2lkZQogICB1c2luZyBTSUdDT01QIGFuZCB0aGUgb3RoZXIgc2lkZSBu b3QsIGV0Yy4uLgoKMy4yLiAgSWRlbnRpZmllZCBwcm9ibGVtcwoKICAgSGFuZGxpbmcgb2Yg dGhlIFJlY29yZC1Sb3V0ZSBoZWFkZXIgaW4gU0lQIFByb3hpZXMgaXMgc3BlY2lmaWVkIGJ5 CiAgIGZvbGxvd2luZyBzZWN0aW9ucyBvZiBbUkZDMzI2MV06CgogICBPbiB0aGUgcmVxdWVz dCBwcm9jZXNzaW5nIHNpZGUsIFtSRkMzMjYxXSwgaXRlbSA0IG9mIHNlY3Rpb24gMTYuNgog ICBzdGF0ZXMgdGhhdDoKCiAgICAgICJUaGUgVVJJIHBsYWNlZCBpbiB0aGUgUmVjb3JkLVJv dXRlIGhlYWRlciBmaWVsZCB2YWx1ZSBNVVNUIGJlIGEKICAgICAgU0lQIG9yIFNJUFMgVVJJ LiBbLi4uXSAgVGhlIFVSSSBTSE9VTEQgTk9UIGNvbnRhaW4gdGhlIHRyYW5zcG9ydAogICAg ICBwYXJhbWV0ZXIgdW5sZXNzIHRoZSBwcm94eSBoYXMga25vd2xlZGdlIChzdWNoIGFzIGlu IGEgcHJpdmF0ZQogICAgICBuZXR3b3JrKSB0aGF0IHRoZSBuZXh0IGRvd25zdHJlYW0gZWxl bWVudCB0aGF0IHdpbGwgYmUgaW4gdGhlIHBhdGgKICAgICAgb2Ygc3Vic2VxdWVudCByZXF1 ZXN0cyBzdXBwb3J0cyB0aGF0IHRyYW5zcG9ydC4iCgogICBGb2xsb3dpbmcgdGhpcyBzdGF0 ZW1lbnQsIGl0IGlzIG5vdCBjbGVhciBob3cgdG8gZGVjaWRlIHdoZW4gdGhlCiAgIHByb3h5 IHNob3VsZCBpbnNlcnQgdGhlIHRyYW5zcG9ydCBwcm90b2NvbCBwYXJhbWV0ZXIgaW4gdGhl IFJlY29yZC0KICAgUm91dGUgVVJJLgoKICAgT24gcmVzcG9uc2UgcHJvY2Vzc2luZyBzaWRl LCBbUkZDMzI2MV0gcmVjb21tZW5kcyBpbiBzdGVwIDggb2YKICAgc2VjdGlvbiAxNi43IHRo YXQ6CgogICAgICAiSWYgdGhlIHNlbGVjdGVkIHJlc3BvbnNlIGNvbnRhaW5zIGEgUmVjb3Jk LVJvdXRlIGhlYWRlciBmaWVsZAogICAgICB2YWx1ZSBvcmlnaW5hbGx5IHByb3ZpZGVkIGJ5 IHRoaXMgcHJveHksIHRoZSBwcm94eSBNQVkgY2hvb3NlIHRvCiAgICAgIHJld3JpdGUgdGhl IHZhbHVlIGJlZm9yZSBmb3J3YXJkaW5nIHRoZSByZXNwb25zZS4gIFRoaXMgYWxsb3dzIHRo ZQogICAgICBwcm94eSB0byBwcm92aWRlIGRpZmZlcmVudCBVUklzIGZvciBpdHNlbGYgdG8g dGhlIG5leHQgdXBzdHJlYW0KICAgICAgYW5kIGRvd25zdHJlYW0gZWxlbWVudHMuICBBIHBy b3h5IG1heSBjaG9vc2UgdG8gdXNlIHRoaXMgbWVjaGFuaXNtCiAgICAgIGZvciBhbnkgcmVh c29uLiAgRm9yIGluc3RhbmNlLCBpdCBpcyB1c2VmdWwgZm9yIG11bHRpLWhvbWVkIGhvc3Rz LgoKICAgICAgSWYgdGhlIHByb3h5IHJlY2VpdmVkIHRoZSByZXF1ZXN0IG92ZXIgVExTLCBh bmQgc2VudCBpdCBvdXQgb3ZlciBhCiAgICAgIG5vbi1UTFMgY29ubmVjdGlvbiwgdGhlIHBy b3h5IE1VU1QgcmV3cml0ZSB0aGUgVVJJIGluIHRoZSBSZWNvcmQtCiAgICAgIFJvdXRlIGhl YWRlciBmaWVsZCB0byBiZSBhIFNJUFMgVVJJIi4KCiAgIE5vdGUgdGhhdCBbSS1ELmlldGYt c2lwLXNpcHNdIGhhcyB3ZWFrZW5lZCB0aGUgU0lQL1NJUFMgVVJJIHJld3JpdGluZwogICBy ZXF1aXJlbWVudCBpbiB0aGUgUmVjb3JkLVJvdXRlIGhlYWRlciBieSByZW1vdmluZyB0aGlz IHNlY29uZAogICBwYXJhZ3JhcGguCgogICBJbmRlZWQsIFtSRkMzMjYxXSBzdWdnZXN0cyBy ZXdyaXRpbmcgdGhlIFJlY29yZC1Sb3V0ZSBoZWFkZXIgaW4KICAgcmVzcG9uc2VzLgoKICAg VGhpcyBsaXN0IGhpZ2hsaWdodHMgdGhlIHV0aWxpdHkgb2YgcmV3cml0aW5nIGFuZCBkb3Vi bGUgUmVjb3JkLQogICBSb3V0aW5nIHRlY2huaXF1ZXMgd2hpY2ggYXBwbHkgZm9yIGFueSBt dWx0aS1ob21lZCBwcm94eSB1c2UgY2FzZSwKICAgd2hlbmV2ZXIgdGhlIHByb3h5IGNoYW5n ZXMgaXRzIElQIGFkZHJlc3MsIHRoZSB0cmFuc3BvcnQgcHJvdG9jb2wgb3IKICAgdGhlIFVS SSBzY2hlbWUgYmV0d2VlbiBpbmNvbWluZyBhbmQgb3V0Z29pbmcgaW50ZXJmYWNlcy4gIFJl d3JpdGluZwogICBhbmQgZG91YmxlIFJlY29yZC1Sb3V0aW5nIGFyZSBkZXNjcmliZWQsIGNv bXBhcmVkIGFuZCBkaXNjdXNzZWQgaW4KCgoKRnJvbWVudCwgZXQgYWwuICAgICAgICAgRXhw aXJlcyBGZWJydWFyeSA1LCAyMDEwICAgICAgICAgICAgICAgIFtQYWdlIDhdCgwKSW50ZXJu ZXQtRHJhZnQgICAgICAgICAgICBTSVAgUmVjb3JkLVJvdXRlIGZpeCAgICAgICAgICAgICAg IEF1Z3VzdCAyMDA5CgoKICAgc2VjdGlvbnMgNCBhbmQgNTsgdGhlIHNwZWNpZmljIHF1ZXN0 aW9uIHRvIGluc2VydCBvciBub3QgdGhlCiAgIHRyYW5zcG9ydCBwYXJhbWV0ZXIgaW4gdGhl IFJlY29yZC1Sb3V0ZSBVUkkgaXMgdGhlbiBkaXNjdXNzZWQgaW4KICAgU2VjdGlvbiA2LgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgpGcm9tZW50 LCBldCBhbC4gICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDUsIDIwMTAgICAgICAgICAgICAg ICAgW1BhZ2UgOV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgIFNJUCBSZWNvcmQtUm91 dGUgZml4ICAgICAgICAgICAgICAgQXVndXN0IDIwMDkKCgo0LiAgUmVjb3JkLVJvdXRlIHJl d3JpdGluZwoKICAgQXMgZnJlcXVlbnRseSBvdXRsaW5lZCBpbiBJRVRGIG1haWxpbmcgbGlz dCBkaXNjdXNzaW9ucywgUmVjb3JkLVJvdXRlCiAgIHJld3JpdGluZyBpbiByZXNwb25zZXMg aXMgbm90IHRoZSBtb3N0IG9wdGltYWwgd2F5IG9mIGhhbmRsaW5nIG11bHRpLQogICBob21l ZCBhbmQgdHJhbnNwb3J0IHByb3RvY29sIHN3aXRjaGluZyBzaXR1YXRpb25zLiAgQWRkaXRp b25hbGx5LCB0aGUKICAgY29uc2VxdWVuY2Ugb2YgZG9pbmcgcmV3cml0aW5nIGlzIHRoYXQg dGhlIHJvdXRlIHNldCBzZWVuIGJ5IHRoZQogICBjYWxsZXIgaXMgZGlmZmVyZW50IGZyb20g dGhlIHJvdXRlIHNldCBzZWVuIGJ5IHRoZSBjYWxsZWUsIGFuZCB0aGlzCiAgIGhhcyBhdCBs ZWFzdCB0d28gbmVnYXRpdmUgaW1wbGljYXRpb25zOgoKICAgMSkgQ2FsbGVlIGNhbm5vdCBz aWduIHRoZSByb3V0ZSBzZXQsIGJlY2F1c2UgaXQgZ2V0cyBlZGl0ZWQgYnkgdGhlCiAgIHBy b3h5IGluIHRoZSByZXNwb25zZS4gIENvbnNlcXVlbnRseSwgZW5kLXRvLWVuZCBwcm90ZWN0 aW9uIG9mIHRoZQogICByb3V0ZSBzZXQgY2FuIG5vdCBiZSBzdXBwb3J0ZWQgYnkgdGhlIHBy b3RvY29sLiAgVGhpcyBtZWFucyB0aGUKICAgSW50ZXJuZXQncyBwcmluY2lwbGVzIG9mIG9w ZW5uZXNzIGFuZCBlbmQtdG8tZW5kIGNvbm5lY3Rpdml0eSBhcmUKICAgYnJva2VuLgoKICAg MikgQSBwcm94eSBtdXN0IGltcGxlbWVudCBzcGVjaWFsICJtdWx0aS1ob21lZCIgbG9naWMu ICBEdXJpbmcgdGhlCiAgIHJlcXVlc3QgZm9yd2FyZGluZyBwaGFzZSwgaXQgcGVyZm9ybXMg YW4gb3V0cHV0IGludGVyZmFjZSBjYWxjdWxhdGlvbgogICBhbmQgd3JpdGVzIGluZm9ybWF0 aW9uIHJlc29sdmluZyB0byB0aGUgb3V0cHV0IGludGVyZmFjZSBpbnRvIHRoZSBVUkkKICAg b2YgdGhlIFJlY29yZC1Sb3V0ZSBoZWFkZXIuICBXaGVuIGhhbmRsaW5nIHJlc3BvbnNlcywg dGhlIHByb3h5IG11c3QKICAgaW5zcGVjdCB0aGUgUmVjb3JkLVJvdXRlIGhlYWRlcihzKSwg bG9vayBmb3IgYW4gaW5wdXQgaW50ZXJmYWNlIGFuZAogICBzZWxlY3RpdmVseSBlZGl0IHRo ZW0gdG8gcmVmZXJlbmNlIHRoZSBjb3JyZWN0IG91dHB1dCBpbnRlcmZhY2UuCiAgIFNpbmNl IHRoaXMgbG9va3VwIGhhcyB0byBiZSBkb25lIGZvciBhbGwgcmVzcG9uc2VzIGZvcndhcmRl ZCBieSB0aGUKICAgcHJveHksIHRoaXMgdGVjaG5pcXVlIGltcGxpZXMgYSBDUFUgZHJhZy4K CiAgIFRoZXJlZm9yZSB0aGlzIGRvY3VtZW50IHJlY29tbWVuZHMgdXNpbmcgdGhlIGRvdWJs ZSBSZWNvcmQtUm91dGUKICAgYXBwcm9hY2ggdG8gYXZvaWRpbmcgcmV3cml0aW5nIHRoZSBS ZWNvcmQtUm91dGUuICBUaGlzIHJlY29tbWVuZGF0aW9uCiAgIGFwcGxpZXMgdG8gYWxsIHVz ZXMgb2YgUmVjb3JkLVJvdXRlIHJld3JpdGluZyBieSBwcm94aWVzLCBpbmNsdWRpbmcKICAg dHJhbnNwb3J0IHByb3RvY29sIHN3aXRjaGluZyBhbmQgbXVsdGktaG9tZWQgcHJveGllcy4K CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgpGcm9tZW50LCBldCBhbC4gICAgICAgICBFeHBpcmVz IEZlYnJ1YXJ5IDUsIDIwMTAgICAgICAgICAgICAgICBbUGFnZSAxMF0KDApJbnRlcm5ldC1E cmFmdCAgICAgICAgICAgIFNJUCBSZWNvcmQtUm91dGUgZml4ICAgICAgICAgICAgICAgQXVn dXN0IDIwMDkKCgo1LiAgRG91YmxlIFJlY29yZC1Sb3V0aW5nCgogICBUaGUgc2VyaW91cyBk cmF3YmFja3Mgb2YgdGhlIHJld3JpdGluZyB0ZWNobmlxdWUgZXhwbGFpbiB3aHkgdGhlCiAg IGRvdWJsZSBSZWNvcmQtUm91dGluZyBzb2x1dGlvbiBoYXMgY29uc2VxdWVudGx5IGJlZW4g cmVjb21tZW5kZWQgaW4KICAgU0lQIGV4dGVuc2lvbnMgbGlrZSBbUkZDMzQ4Nl0gb3IgW1JG QzM2MDhdLgoKICAgVGhpcyB0ZWNobmlxdWUgY29uc2lzdHMgb2YgaW5zZXJ0aW5nIGJlZm9y ZSBhbnkgZXhpc3RpbmcgUmVjb3JkLVJvdXRlCiAgIGhlYWRlciwgYSBSZWNvcmQtUm91dGUg aGVhZGVyIHdpdGggdGhlIFVSSSByZWZsZWN0aW5nIHRvIHRoZSBpbnB1dAogICBpbnRlcmZh Y2UsIGluY2x1ZGluZyBzY2hlbWVzIGFuZC9vciBVUkkgcGFyYW1ldGVycywgYW5kIHNlY29u ZGx5LCBhCiAgIFJlY29yZC1Sb3V0ZSBoZWFkZXIgd2l0aCB0aGUgVVJJIHJlZmxlY3Rpbmcg dG8gdGhlIG91dHB1dCBpbnRlcmZhY2UuCiAgIFdoZW4gcHJvY2Vzc2luZyB0aGUgcmVzcG9u c2UsIG5vIG1vZGlmaWNhdGlvbiBvZiB0aGUgcmVjb3JkZWQgcm91dGUKICAgaXMgcmVxdWly ZWQuICBUaGlzIGlzIGNvbXBsZXRlbHkgYmFja3dhcmQgY29tcGF0aWJsZSB3aXRoIFtSRkMz MjYxXS4KICAgR2VuZXJhbGx5IHNwZWFraW5nLCB0aGUgdGltZSBjb21wbGV4aXR5IHdpbGwg YmUgbGVzcyBpbiBkb3VibGUKICAgUmVjb3JkLVJvdXRpbmcgc2luY2Ugb24gcHJvY2Vzc2lu ZyB0aGUgcmVzcG9uc2UsIHRoZSBwcm94eSBkb2VzIG5vdAogICBoYXZlIHRvIGRvIGFueSBy ZXdyaXRlcyAoYW5kIHRodXMsIG5vIHNlYXJjaGluZykuICBNb3Jlb3ZlciwgdGhlCiAgIGhh bmRsaW5nIG9mIGluLWRpYWxvZyByZXF1ZXN0cyBhbmQgcmVzcG9uc2VzIHJlcXVpcmVzIG5v IHNwZWNpYWwKICAgaGFuZGxpbmcgYW55IG1vcmUuCgogICBXaGVuIGRvdWJsZSBSZWNvcmQt Um91dGluZywgdGhlIHByb3h5IHdpbGwgaGF2ZSB0byBoYW5kbGUgdGhlCiAgIHN1YnNlcXVl bnQgaW4tZGlhbG9nIHJlcXVlc3QocykgYXMgYSBzcGlyYWwsIGFuZCBjb25zZXF1ZW50bHkg ZGV2b3RlCiAgIHJlc291cmNlcyB0byBtYWludGFpbiB0cmFuc2FjdGlvbnMgcmVxdWlyZWQg dG8gaGFuZGxlIHRoZSBzcGlyYWwuCiAgIFdoYXQgaXMgY29uc2lkZXJlZCB0byBiZSBhIHNw aXJhbGxpbmcgcmVxdWVzdCBpcyBleHBsYWluZWQgaW4gU2VjdGlvbgogICA2IG9mIFtSRkMz MjYxXS4gIEluIG9yZGVyIHRvIGF2b2lkIGEgc3BpcmFsLCB0aGUgcHJveHkgY2FuIGJlIHNt YXJ0CiAgIGFuZCBzY2FuIGFuIGV4dHJhIFJvdXRlIGhlYWRlciBhaGVhZCB0byBkZXRlcm1p bmUgd2hldGhlciB0aGUgcmVxdWVzdAogICB3aWxsIHNwaXJhbCB0aHJvdWdoIGl0LiAgSWYg aXQgZG9lcywgaXQgY2FuIG9wdGltaXplIHRoZSBzZWNvbmQKICAgc3BpcmFsIHRocm91Z2gg aXRzZWxmLiAgRXZlbiB0aG91Z2ggdGhpcyBpcyBhbiBpbXBsZW1lbnRhdGlvbgogICBkZWNp c2lvbiwgaXQgaXMgbXVjaCBtb3JlIGVmZmljaWVudCB0byBhdm9pZCBzcGlyYWxpbmcuICBT bywgdGhpcwogICBtZWFucyBpbiBzZWN0aW9uIDE2LjQsICJSb3V0ZSBJbmZvcm1hdGlvbiBQ cmVwcm9jZXNzaW5nIiBbUkZDMzI2MV0sCiAgIGltcGxlbWVudG9ycyBjYW4gY2hvb3NlIHRo YXQgYSBwcm94eSBNQVkgcmVtb3ZlIHR3byBSb3V0ZSBoZWFkZXJzCiAgIGluc3RlYWQgb2Yg b25lIHdoZW4gdXNpbmcgdGhlIGRvdWJsZSBSZWNvcmQtUm91dGluZy4KCiAgIFRoZSBmb2xs b3dpbmcgZXhhbXBsZSBpcyBhbiBleHRlbnNpb24gb2YgdGhlIGV4YW1wbGUgZ2l2ZW4gaW4K ICAgW0ktRC5pZXRmLXNpcHBpbmctdjYtdHJhbnNpdGlvbl0uICBJdCBpbGx1c3RyYXRlcyBh IGJhc2ljIGNhbGwgZmxvdwogICB1c2luZyBkb3VibGUgUmVjb3JkLVJvdXRpbmcgaW4gYSBt dWx0aS1ob21lZCBJUHY0IHRvIElQdjYgcHJveHksIGFuZAogICBhbm5vdGF0ZXMgdGhlIGRp YWxvZyBzdGF0ZSBvbiBlYWNoIFVBLiAgSW4gdGhpcyBleGFtcGxlLCBwcm94eSBQMSwKICAg cmVzcG9uc2libGUgZm9yIHRoZSBkb21haW4gYmlsb3h5LmV4YW1wbGUuY29tLCByZWNlaXZl cyBhIHJlcXVlc3QKICAgZnJvbSBhbiBJUHY0LW9ubHkgdXBzdHJlYW0gY2xpZW50LiAgSXQg cHJveGllcyB0aGlzIHJlcXVlc3QgdG8gYW4KICAgSVB2Ni1vbmx5IGRvd25zdHJlYW0gc2Vy dmVyLiAgUHJveHkgUDEgaXMgcnVubmluZyBvbiBhIGR1YWwtc3RhY2sKICAgaG9zdDsgb24g dGhlIElQdjQgaW50ZXJmYWNlLCBpdCBoYXMgYW4gYWRkcmVzcyBvZiAxOTIuMC4yLjI1NCBh bmQgb24KICAgdGhlIElQdjYgaW50ZXJmYWNlLCBpdCBpcyBjb25maWd1cmVkIHdpdGggYW4g YWRkcmVzcyBvZiAyMDAxOmRiODo6MS4KICAgU29tZSBtYW5kYXRvcnkgU0lQIGhlYWRlcnMg aGF2ZSBiZWVuIG9taXR0ZWQgdG8gZWFzZSByZWFkYWJpbGl0eS4KCgoKCgoKCgoKCkZyb21l bnQsIGV0IGFsLiAgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgNSwgMjAxMCAgICAgICAgICAg ICAgIFtQYWdlIDExXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgU0lQIFJlY29yZC1S b3V0ZSBmaXggICAgICAgICAgICAgICBBdWd1c3QgMjAwOQoKCiAgICAgICAgICBVQTEgICAg ICAgICAgICAgIFByb3h5ICJQMSIgICAgICAgICAgICAgICBVQTIKICAgICAgICAgKElQdjQp ICAgICAgICAgICAgKElQdjQvSVB2NikgICAgICAgICAgICAgKElQdjYpCiAgICAgICAgICAg fCAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgfAogICAgICAgICAg IHwgICBGMSBJTlZJVEUgICAgICAgIHwgICAgICAgICAgICAgICAgICAgIHwKICAgICAgICAg ICB8LS0tLS0tLS0tLS0tLS0tLS0tLT58ICAgICAgRjIgSU5WSVRFICAgICB8CiAgICAgICAg ICAgfCAgICAgICAgICAgICAgICAgICAgfC0tLS0tLS0tLS0tLS0tLS0tLS0+fAogICAgICAg ICAgIHwgICAgMTAwIFRyeWluZyAgICAgIHwgICAgICAgICAgICAgICAgICAgIHwKICAgICAg ICAgICB8PC0tLS0tLS0tLS0tLS0tLS0tLS18ICAgICAgICAgICAgICAgICAgICB8CiAgICAg ICAgICAgfCAgICAgICAgICAgICAgICAgICAgfCAgICBGMyAyMDAgT0sgICAgICAgfAogICAg ICAgICAgIHwgICAgRjQgMjAwIE9LICAgICAgIHw8LS0tLS0tLS0tLS0tLS0tLS0tLXwKICAg ICAgICAgICB8PC0tLS0tLS0tLS0tLS0tLS0tLS18ICAgICAgICAgICAgICAgICAgICB8CiAg ICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgfAog ICAgICAgICAgIHwgICAgICAgRjUgQUNLICAgICAgIHwgICAgICAgICAgICAgICAgICAgIHwK ICAgICAgICAgICB8LS0tLS0tLS0tLS0tLS0tLS0tLT58ICAgICAgIEY2IEFDSyAgICAgICB8 CiAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgfC0tLS0tLS0tLS0tLS0tLS0tLS0+ fAogICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAg IHwKICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICB8ICAgICAgICBGNyBCWUUgICAg ICB8CiAgICAgICAgICAgfCAgICAgICBGOCBCWUUgICAgICAgfDwtLS0tLS0tLS0tLS0tLS0t LS0tfAogICAgICAgICAgIHw8LS0tLS0tLS0tLS0tLS0tLS0tLXwgICAgICAgICAgICAgICAg ICAgIHwKCiAgIEZpZ3VyZSAyOiBJUHY0IHRvIElQdjYgbXVsdGktaG9tZWQgcHJveHkgaWxs dXN0cmF0aW9uCgoKICAgIFVBMSAgICAgIFAxICAgICAgVUEyCgogICAgRjEgSU5WSVRFIFVB MSAtPiBQMSAoMTkyLjAuMi4yNTQ6NTA2MCkKCiAgICBJTlZJVEUgc2lwOmJvYkBiaWxveGku ZXhhbXBsZS5jb20gU0lQLzIuMAogICAgUm91dGU6IDxzaXA6MTkyLjAuMi4yNTQ6NTA2MDts cj4KICAgIEZyb206IEFsaWNlIDxzaXA6YWxpY2VAYXRsYW50YS5leGFtcGxlLmNvbT47dGFn PTEyMzQKICAgIFRvOiBCb2IgPHNpcDpib2JAYmlsb3hpLmV4YW1wbGUuY29tPgogICAgQ29u dGFjdDogPHNpcDphbGljZUAxOTIuMC4yLjE+CgogICAgICAgICAgICBGMiBJTlZJVEUgUDEg KDIwMDE6ZGI4OjoxKSAtPiBVQTIKCiAgICAgICAgICAgIElOVklURSBzaXA6Ym9iQGJpbG94 aS5leGFtcGxlLmNvbSBTSVAvMi4wCiAgICAgICAgICAgIFJlY29yZC1Sb3V0ZTogPHNpcDpb MjAwMTpkYjg6OjFdO2xyPgogICAgICAgICAgICBSZWNvcmQtUm91dGU6IDxzaXA6MTkyLjAu Mi4yNTQ6NTA2MDtscj4KICAgICAgICAgICAgRnJvbTogQWxpY2UgPHNpcDphbGljZUBhdGxh bnRhLmV4YW1wbGUuY29tPjt0YWc9MTIzNAogICAgICAgICAgICBUbzogQm9iIDxzaXA6Ym9i QGJpbG94aS5leGFtcGxlLmNvbT4KICAgICAgICAgICAgQ29udGFjdDogPHNpcDphbGljZUAx OTIuMC4yLjE+CgogICAgICAgICAgICAgICAgICAgIERpYWxvZyBTdGF0ZSBhdCBVQTI6CiAg ICAgICAgICAgICAgICAgICAgTG9jYWwgVVJJICAgICA9IHNpcDpib2JAYmlsb3hpLmV4YW1w bGUuY29tCiAgICAgICAgICAgICAgICAgICAgUmVtb3RlIFVSSSAgICA9IHNpcDphbGljZUBh dGxhbnRhLmV4YW1wbGUuY29tCiAgICAgICAgICAgICAgICAgICAgUmVtb3RlIHRhcmdldCA9 IHNpcDphbGljZUAxOTIuMC4yLjEKICAgICAgICAgICAgICAgICAgICBSb3V0ZSBTZXQgICAg ID0gc2lwOlsyMDAxOmRiODo6MV07bHIKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgc2lwOjE5Mi4wLjIuMjU0OjUwNjA6bHIKCgoKRnJvbWVudCwgZXQgYWwuICAgICAg ICAgRXhwaXJlcyBGZWJydWFyeSA1LCAyMDEwICAgICAgICAgICAgICAgW1BhZ2UgMTJdCgwK SW50ZXJuZXQtRHJhZnQgICAgICAgICAgICBTSVAgUmVjb3JkLVJvdXRlIGZpeCAgICAgICAg ICAgICAgIEF1Z3VzdCAyMDA5CgoKICAgICAgICAgICAgICAgICAgICBGMyAyMDAgT0sgVUEy IC0+IFAxICgyMDAxOmRiODo6MSkKCiAgICAgICAgICAgICAgICAgICAgU0lQLzIuMCAyMDAg T0sKICAgICAgICAgICAgICAgICAgICBSZWNvcmQtUm91dGU6IDxzaXA6WzIwMDE6ZGI4Ojox XTtscj4KICAgICAgICAgICAgICAgICAgICBSZWNvcmQtUm91dGU6IDxzaXA6MTkyLjAuMi4y NTQ6NTA2MDtscj4KICAgICAgICAgICAgICAgICAgICBGcm9tOiBBbGljZSA8c2lwOmFsaWNl QGF0bGFudGEuZXhhbXBsZS5jb20+O3RhZz0xMjM0CiAgICAgICAgICAgICAgICAgICAgVG86 IEJvYiA8c2lwOmJvYkBiaWxveGkuZXhhbXBsZS5jb20+O3RhZz00NTY3CiAgICAgICAgICAg ICAgICAgICAgQ29udGFjdDogPHNpcDpib2JAWzIwMDE6ZGI4OjozM10+CgogICAgICAgICAg ICBGNCAyMDAgT0sgUDEgLT4gVUExCgogICAgICAgICAgICBTSVAvMi4wIDIwMCBPSwogICAg ICAgICAgICBSZWNvcmQtUm91dGU6IDxzaXA6WzIwMDE6ZGI4OjoxXTtscj4KICAgICAgICAg ICAgUmVjb3JkLVJvdXRlOiA8c2lwOjE5Mi4wLjIuMjU0OjUwNjA7bHI+CiAgICAgICAgICAg IEZyb206IEFsaWNlIDxzaXA6YWxpY2VAYXRsYW50YS5leGFtcGxlLmNvbT47dGFnPTEyMzQK ICAgICAgICAgICAgVG86IEJvYiA8c2lwOmJvYkBiaWxveGkuZXhhbXBsZS5jb20+O3RhZz00 NTY3CiAgICAgICAgICAgIENvbnRhY3Q6IDxzaXA6Ym9iQFsyMDAxOmRiODo6MzNdPgoKICAg IERpYWxvZyBTdGF0ZSBhdCBVQTE6CiAgICBMb2NhbCBVUkkgICAgID0gc2lwOmFsaWNlQGF0 bGFudGEuZXhhbXBsZS5jb20KICAgIFJlbW90ZSBVUkkgICAgPSBzaXA6Ym9iQGJpbG94aS5l eGFtcGxlLmNvbQogICAgUmVtb3RlIHRhcmdldCA9IHNpcDpib2JAWzIwMDE6ZGI4OjozM10K ICAgIFJvdXRlIFNldCAgICAgPSBzaXA6MTkyLjAuMi4yNTQ6NTA2MDpscgogICAgICAgICAg ICAgICAgICAgIHNpcDpbMjAwMTpkYjg6OjFdO2xyCgogICAgRjUgQUNLIFVBMSAtPiBQMSAo MTkyLjAuMi4yNTQ6NTA2MCkKCiAgICBBQ0sgc2lwOmJvYkBbMjAwMTpkYjg6OjMzXSBTSVAv Mi4wCiAgICBSb3V0ZTogPHNpcDoxOTIuMC4yLjI1NDo1MDYwOmxyPgogICAgUm91dGU6IDxz aXA6WzIwMDE6ZGI4OjoxXTtscj4KICAgIEZyb206IEFsaWNlIDxzaXA6YWxpY2VAYXRsYW50 YS5leGFtcGxlLmNvbT47dGFnPTEyMzQKICAgIFRvOiBCb2IgPHNpcDpib2JAYmlsb3hpLmV4 YW1wbGUuY29tPjt0YWc9NDU2NwoKICAgICAgICAgICAgRjYgQUNLIFAxICgyMDAxOmRiODo6 MSkgLT4gVUEyCgogICAgICAgICAgICBBQ0sgc2lwOmJvYkBbMjAwMTpkYjg6OjMzXSBTSVAv Mi4wCiAgICAgICAgICAgIEZyb206IEFsaWNlIDxzaXA6YWxpY2VAYXRsYW50YS5leGFtcGxl LmNvbT47dGFnPTEyMzQKICAgICAgICAgICAgVG86IEJvYiA8c2lwOmJvYkBiaWxveGkuZXhh bXBsZS5jb20+O3RhZz00NTY3CiAgICAgICAgICAgIChib3RoIFJvdXRlIGhlYWRlcnMgaGF2 ZSBiZWVuIHJlbW92ZWQgYnkgdGhlIHByb3h5KQoKICAgICAgICAgICAgICAgICAgICBGNyBC WUUgVUEyIC0+IFAxICgyMDAxOmRiODo6MSkKCiAgICAgICAgICAgICAgICAgICAgQllFIHNp cDphbGljZUAxOTIuMC4yLjEgU0lQLzIuMAogICAgICAgICAgICAgICAgICAgIFJvdXRlOiA8 c2lwOlsyMDAxOmRiODo6MV07bHI+CiAgICAgICAgICAgICAgICAgICAgUm91dGU6IDxzaXA6 MTkyLjAuMi4yNTQ6NTA2MDpscj4KICAgICAgICAgICAgICAgICAgICBGcm9tOiBCb2IgPHNp cDpib2JAYmlsb3hpLmV4YW1wbGUuY29tPjt0YWc9NDU2NwogICAgICAgICAgICAgICAgICAg IFRvOiBBbGljZSA8c2lwOmFsaWNlQGF0bGFudGEuZXhhbXBsZS5jb20+O3RhZz0xMjM0CgoK CgpGcm9tZW50LCBldCBhbC4gICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDUsIDIwMTAgICAg ICAgICAgICAgICBbUGFnZSAxM10KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgIFNJUCBS ZWNvcmQtUm91dGUgZml4ICAgICAgICAgICAgICAgQXVndXN0IDIwMDkKCgogICAgICAgICAg ICBGOCBCWUUgUDEgKDE5Mi4wLjIuMjU0OjUwNjApIC0+IFVBMQoKICAgICAgICAgICAgQllF IHNpcDphbGljZUAxOTIuMC4yLjEgU0lQLzIuMAogICAgICAgICAgICBGcm9tOiBCb2IgPHNp cDpib2JAYmlsb3hpLmV4YW1wbGUuY29tPjt0YWc9NDU2NwogICAgICAgICAgICBUbzogQWxp Y2UgPHNpcDphbGljZUBhdGxhbnRhLmV4YW1wbGUuY29tPjt0YWc9MTIzNAoKCiAgIEZpZ3Vy ZSAzOiBNdWx0aS1ob21lZCBJUHY0IHRvIElQdjYgZG91YmxlIFJlY29yZC1Sb3V0aW5nIGls bHVzdHJhdGlvbgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK RnJvbWVudCwgZXQgYWwuICAgICAgICAgRXhwaXJlcyBGZWJydWFyeSA1LCAyMDEwICAgICAg ICAgICAgICAgW1BhZ2UgMTRdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICBTSVAgUmVj b3JkLVJvdXRlIGZpeCAgICAgICAgICAgICAgIEF1Z3VzdCAyMDA5CgoKNi4gIFVzYWdlIG9m IFRyYW5zcG9ydCBwcm90b2NvbCBwYXJhbWV0ZXIKCiAgIFRoaXMgc2VjdGlvbiBkZXNjcmli ZXMgYSBzZXQgb2YgcHJvYmxlbXMgdGhhdCBhcmUgcmVsYXRlZCB0byB0aGUKICAgdXNhZ2Ug b2YgdHJhbnNwb3J0IHByb3RvY29sIFVSSSBwYXJhbWV0ZXIgaW4gdGhlIFJlY29yZC1Sb3V0 ZSBoZWFkZXIuCiAgIEluIHNvbWUgY2lyY3Vtc3RhbmNlcyBpbnRlcm9wZXJhYmlsaXR5IHBy b2JsZW1zIG9jY3VyIGJlY2F1c2UgaXQgaXMKICAgbm90IGNsZWFyIHdoZXRoZXIgb3Igbm90 IHRvIGluY2x1ZGUgdGhlIHRyYW5zcG9ydCBwYXJhbWV0ZXIgb24gdGhlCiAgIFVSSSBvZiB0 aGUgUmVjb3JkLVJvdXRlIGhlYWRlci4gIFRoaXMgd2FzIGlkZW50aWZpZWQgYXMgYSBmcmVx dWVudAogICBwcm9ibGVtIGluIHBhc3QgU0lQaXQgZXZlbnRzLgoKICAgW1JGQzMyNjFdLCBz dGVwIDggb2Ygc2VjdGlvbiAxNi43IHNheXM6CgogICAgICAiVGhlIFVSSSBTSE9VTEQgTk9U IGNvbnRhaW4gdGhlIHRyYW5zcG9ydCBwYXJhbWV0ZXIgdW5sZXNzIHRoZQogICAgICBwcm94 eSBoYXMga25vd2xlZGdlIChzdWNoIGFzIGluIGEgcHJpdmF0ZSBuZXR3b3JrKSB0aGF0IHRo ZSBuZXh0CiAgICAgIGRvd25zdHJlYW0gZWxlbWVudCB0aGF0IHdpbGwgYmUgaW4gdGhlIHBh dGggb2Ygc3Vic2VxdWVudCByZXF1ZXN0cwogICAgICBzdXBwb3J0cyB0aGF0IHRyYW5zcG9y dC4iCgogICBUaGUgcHJlY2VkaW5nIHNlZW1zIHRvIGNvbmZ1c2UgaW1wbGVtZW50b3JzLCBy ZXN1bHRpbmcgaW4gcHJveGllcwogICB0aGF0IGluc2VydCBhIHNpbmdsZSBSZWNvcmQtUm91 dGUgd2l0aG91dCBhIHRyYW5zcG9ydCBVUkkgcGFyYW1ldGVyLAogICByZXN1bHRpbmcgaW4g dGhlIHByb2JsZW1zIGRlc2NyaWJlZCBpbiB0aGlzIHNlY3Rpb24uCgo2LjEuICBVQSBpbXBs ZW1lbnRhdGlvbnMgcHJvYmxlbXMgYW5kIHJlY29tbWVuZGF0aW9ucwoKICAgQ29uc2lkZXIg dGhlIGZvbGxvd2luZyBzY2VuYXJpbzogYSBTSVAgcHJveHksIGRvaW5nIFRDUCB0byBVRFAK ICAgdHJhbnNwb3J0IHByb3RvY29sIHN3aXRjaGluZy4KCiAgIEluIHRoaXMgZXhhbXBsZSwg cHJveHkgUDEsIHJlc3BvbnNpYmxlIGZvciB0aGUgZG9tYWluCiAgIGJpbG94eS5leGFtcGxl LmNvbSwgcmVjZWl2ZXMgYSByZXF1ZXN0IGZyb20gQWxpY2UgVUExIHdoaWNoIHVzZXMgVENQ LgogICBJdCBwcm94aWVzIHRoaXMgcmVxdWVzdCB0byBCb2IgVUEyIHdoaWNoIHJlZ2lzdGVy ZWQgd2l0aCBhIENvbnRhY3QKICAgc3BlY2lmeWluZyBVRFAgYXMgdHJhbnNwb3J0IHByb3Rv Y29sLiAgVGh1cywgUDEgcmVjZWl2ZXMgYW4gaW5pdGlhbAogICByZXF1ZXN0IGZyb20gQWxp Y2Ugb3ZlciBUQ1AgYW5kIGZvcndhcmRzIGl0IHRvIEJvYiBvdmVyIFVEUC4gIEZvcgogICBz dWJzZXF1ZW50IHJlcXVlc3RzLCBpdCBpcyBleHBlY3RlZCB0aGF0IFRDUCBjb3VsZCBjb250 aW51ZSB0byBiZQogICB1c2VkIGJldHdlZW4gQWxpY2UgYW5kIFAxLCBhbmQgVURQIGJldHdl ZW4gUDEgYW5kIEJvYiwgYnV0IHRoaXMgY2FuCiAgIG5vdCBoYXBwZW4gaWYgYSBudW1lcmlj IElQIGFkZHJlc3MgaXMgdXNlZCBhbmQgbm8gdHJhbnNwb3J0IHBhcmFtZXRlcgogICBpcyBz ZXQgb24gUmVjb3JkLVJvdXRlIFVSSS4gIFRoaXMgaGFwcGVucyBiZWNhdXNlIG9mIHByb2Nl ZHVyZXMKICAgZGVzY3JpYmVkIGluW1JGQzMyNjNdLiAgU29tZSBtYW5kYXRvcnkgU0lQIGhl YWRlcnMgaGF2ZSBiZWVuIG9taXR0ZWQKICAgdG8gZWFzZSByZWFkYWJpbGl0eS4KCgoKCgoK CgoKCgoKCgoKRnJvbWVudCwgZXQgYWwuICAgICAgICAgRXhwaXJlcyBGZWJydWFyeSA1LCAy MDEwICAgICAgICAgICAgICAgW1BhZ2UgMTVdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAg ICBTSVAgUmVjb3JkLVJvdXRlIGZpeCAgICAgICAgICAgICAgIEF1Z3VzdCAyMDA5CgoKICAg ICAgQWxpY2UgVUExID09PT09IFRDUCA9PT09PSBQcm94eSBQMSA9PT09PSBVRFAgPT09PT0g Qm9iIFVBMgogICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAg ICAgICAgICAgICAgICB8CiAgICAgICAgIHwgICAgICAgRjEgSU5WSVRFICAgICAgICB8ICAg ICAgICAgICAgICAgICAgICAgICAgIHwKICAgICAgICAgfC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tPnwgICAgICAgICBGMiBJTlZJVEUgICAgICAgfAogICAgICAgICB8ICAgICAgICAgICAg ICAgICAgICAgICAgfC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLT58CiAgICAgICAgIHwgICAg ICAxMDAgVHJ5aW5nICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICAg ICAgfDwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLXwgICAgICAgICAgICAgICAgICAgICAgICAg fAogICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgRjMgMjAwIE9L ICAgICAgICB8CiAgICAgICAgIHwgICAgICAgRjQgMjAwIE9LICAgICAgICB8PC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLXwKICAgICAgICAgfDwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLXwg ICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgICAgICB8ICAgICAgICAgICAgICAgICAg ICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICAgICAgIHwgICAgICAgIEY1 IEFDSyAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICAgICAgfC0t LShzZW50IG92ZXIgVURQKSBYLS0tPnwgICAgICAgICAgICBBQ0sgICAgICAgICAgfAogICAg ICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgfC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LT58CiAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAg ICAgICAgICAgIHwKICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAg ICAgRjYgQllFICAgICAgICAgfAogICAgICAgICB8ICAgICAgICAgIEJZRSAgICAgICAgICAg fDwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS18CiAgICAgICAgIHw8LS0tLS0tLS0tLS0tLS0t LS0tLS0tLS18ICAgICAgICAgICAgICAgICAgICAgICAgIHwKCiAgIEZpZ3VyZSA0OiBUQ1Ag dG8gVURQIHRyYW5zcG9ydCBwcm90b2NvbCBzd2l0Y2hpbmcgaXNzdWUgaWxsdXN0cmF0aW9u CgoKICAgRjEgSU5WSVRFIFVBMSAtPiBQMSAoMTkyLjAuMi4xL3RjcCkKCiAgIElOVklURSBz aXA6Ym9iQGJpbG94aS5leGFtcGxlLmNvbSBTSVAvMi4wCiAgIFJvdXRlOiA8c2lwOjE5Mi4w LjIuMTtscjt0cmFuc3BvcnQ9dGNwPgogICBGcm9tOiBBbGljZSA8c2lwOmFsaWNlQGF0bGFu dGEuZXhhbXBsZS5jb20+O3RhZz0xMjM0CiAgIFRvOiBCb2IgPHNpcDpib2JAYmlsb3hpLmV4 YW1wbGUuY29tPgogICBDb250YWN0OiA8c2lwOmFsaWNlQHVhMS5hdGxhbnRhLmV4YW1wbGUu Y29tO3RyYW5zcG9ydD10Y3A+CgogICAgICAgIEYyIElOVklURSBQMSAtPiBVQTIgKHVhMi5i aWxveGkuZXhhbXBsZS5jb20vdWRwKQoKICAgICAgICBJTlZJVEUgc2lwOmJvYkB1YTIuYmls b3hpLmV4YW1wbGUuY29tO3RyYW5zcG9ydD11ZHAgU0lQLzIuMAogICAgICAgIFJlY29yZC1S b3V0ZTogPHNpcDoxOTIuMC4yLjE7bHI+IChOTyB0cmFuc3BvcnQgcGFyYW0pCiAgICAgICAg RnJvbTogQWxpY2UgPHNpcDphbGljZUBhdGxhbnRhLmV4YW1wbGUuY29tPjt0YWc9MTIzNAog ICAgICAgIFRvOiBCb2IgPHNpcDpib2JAYmlsb3hpLmV4YW1wbGUuY29tPgogICAgICAgIENv bnRhY3Q6IDxzaXA6YWxpY2VAdWExLmF0bGFudGEuZXhhbXBsZS5jb207dHJhbnNwb3J0PXRj cD4KCiAgICAgICAgRGlhbG9nIFN0YXRlIGF0IFVBMjoKICAgICAgICBMb2NhbCBVUkkgICAg ID0gc2lwOmJvYkBiaWxveGkuZXhhbXBsZS5jb20KICAgICAgICBSZW1vdGUgVVJJICAgID0g c2lwOmFsaWNlQGF0bGFudGEuZXhhbXBsZS5jb20KICAgICAgICBSZW1vdGUgdGFyZ2V0ID0g c2lwOmFsaWNlQHVhMS5hdGxhbnRhLmV4YW1wbGUuY29tO3RyYW5zcG9ydD10Y3AKICAgICAg ICBSb3V0ZSBTZXQgICAgID0gc2lwOjE5Mi4wLjIuMTtscgoKICAgICAgICAgICAgIEYzIDIw MCBPSyBVQTIgLT4gUDEgKDE5Mi4wLjIuMS91ZHApCgogICAgICAgICAgICAgU0lQLzIuMCAy MDAgT0sKICAgICAgICAgICAgIFJlY29yZC1Sb3V0ZTogPHNpcDoxOTIuMC4yLjE7bHI+CgoK CkZyb21lbnQsIGV0IGFsLiAgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgNSwgMjAxMCAgICAg ICAgICAgICAgIFtQYWdlIDE2XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgU0lQIFJl Y29yZC1Sb3V0ZSBmaXggICAgICAgICAgICAgICBBdWd1c3QgMjAwOQoKCiAgICAgICAgICAg ICBGcm9tOiBBbGljZSA8c2lwOmFsaWNlQGF0bGFudGEuZXhhbXBsZS5jb20+O3RhZz0xMjM0 CiAgICAgICAgICAgICBUbzogQm9iIDxzaXA6Ym9iQGJpbG94aS5leGFtcGxlLmNvbT47dGFn PTQ1NjcKICAgICAgICAgICAgIENvbnRhY3Q6IDxzaXA6Ym9iQHVhMi5iaWxveGkuZXhhbXBs ZS5jb20+CgogICAgICAgIEY0IDIwMCBPSyBQMSAtPiBVQTEgKHVhMS5hdGxhbnRhLmV4YW1w bGUuY29tL3RjcCkKCiAgICAgICAgU0lQLzIuMCAyMDAgT0sKICAgICAgICBSZWNvcmQtUm91 dGU6IDxzaXA6MTkyLjAuMi4xO2xyPgogICAgICAgIEZyb206IEFsaWNlIDxzaXA6YWxpY2VA YXRsYW50YS5leGFtcGxlLmNvbT47dGFnPTEyMzQKICAgICAgICBUbzogQm9iIDxzaXA6Ym9i QGJpbG94aS5leGFtcGxlLmNvbT47dGFnPTQ1NjcKICAgICAgICBDb250YWN0OiA8c2lwOmJv YkB1YTIuYmlsb3hpLmV4YW1wbGUuY29tPgoKICAgRGlhbG9nIFN0YXRlIGF0IFVBMToKICAg TG9jYWwgVVJJICAgICA9IHNpcDphbGljZUBhdGxhbnRhLmV4YW1wbGUuY29tCiAgIFJlbW90 ZSBVUkkgICAgPSBzaXA6Ym9iQGJpbG94aS5leGFtcGxlLmNvbQogICBSZW1vdGUgdGFyZ2V0 ID0gc2lwOmJvYkB1YTIuYmlsb3hpLmV4YW1wbGUuY29tCiAgIFJvdXRlIFNldCAgICAgPSBz aXA6MTkyLjAuMi4xO2xyCgoKICAgRjUgQUNLIFVBMSAtPiBQMSAoMTkyLjAuMi4xL3VkcCkK CiAgIEFDSyBzaXA6Ym9iQHVhMi5iaWxveGkuZXhhbXBsZS5jb20gU0lQLzIuMAogICBSb3V0 ZTogPHNpcDoxOTIuMC4yLjE7bHI+CiAgIEZyb206IEFsaWNlIDxzaXA6YWxpY2VAYXRsYW50 YS5leGFtcGxlLmNvbT47dGFnPTEyMzQKICAgVG86IEJvYiA8c2lwOmJvYkBiaWxveGkuZXhh bXBsZS5jb20+O3RhZz00NTY3CgogICAgICAgICAgICAgRjYgQllFIFVBMiAtPiBQMSAoMTky LjAuMi4xL3VkcCkKCiAgICAgICAgICAgICBCWUUgc2lwOmFsaWNlQHVhMS5hdGxhbnRhLmV4 YW1wbGUuY29tO3RyYW5zcG9ydD10Y3AgU0lQLzIuMAogICAgICAgICAgICAgUm91dGU6IDxz aXA6MTkyLjAuMi4xO2xyPgogICAgICAgICAgICAgRnJvbTogQm9iIDxzaXA6Ym9iQGJpbG94 aS5leGFtcGxlLmNvbT47dGFnPTQ1NjcKICAgICAgICAgICAgIFRvOiBBbGljZSA8c2lwOmFs aWNlQGF0bGFudGEuZXhhbXBsZS5jb20+O3RhZz0xMjM0CgoKICAgRmlndXJlIDU6IFRDUCB0 byBVRFAgdHJhbnNwb3J0IHByb3RvY29sIHN3aXRjaGluZyBpc3N1ZSBkZXNjcmlwdGlvbgoK ICAgU2luY2UgdGhlIHByb3h5IFAxIGRvZXMgbm90IGluc2VydCBhbnkgdHJhbnNwb3J0IHBh cmFtZXRlciBpbiB0aGUKICAgUmVjb3JkLVJvdXRlIFVSSSwgc3Vic2VxdWVudCBpbi1kaWFs b2cgcmVxdWVzdHMgb2YgVUExLCBsaWtlIHRoZSBBQ0sKICAgc2VudCBpbiBGNSwgd2lsbCBi ZSBzZW50IGFjY29yZGluZyB0byB0aGUgYmVoYXZpb3VyIHNwZWNpZmllZCBpbgogICBzZWN0 aW9uIDEyLjIgKHJlcXVlc3RzIHdpdGhpbiBhIERpYWxvZykgb2YgW1JGQzMyNjFdLiAgVGhh dCBtZWFucwogICB0aGF0IHRoZSByb3V0ZXNldCBpcyB1c2VkLCBhbmQgdGhlbiwgYXBwbHlp bmcgW1JGQzMyNjNdLCB0aGUgUm91dGUKICAgInNpcDoxOTIuMC4yLjEiIHdpbGwgcmVzb2x2 ZSB0byBhIFVEUCB0cmFuc3BvcnQgYnkgZGVmYXVsdCAoc2luY2Ugbm8KICAgdHJhbnNwb3J0 IHBhcmFtZXRlciBpcyBwcmVzZW50IGhlcmUpLCBhbmQgbm8gTkFQVFIgcmVxdWVzdCB3aWxs IGJlCiAgIHBlcmZvcm1lZCBzaW5jZSB0aGlzIGlzIGEgbnVtZXJpYyBJUCBhZGRyZXNzLiAg SW4gZ2VuZXJhbCwgdGhlCiAgIGludGVyb3BlcmFiaWxpdHkgcHJvYmxlbXMgYXJpc2Ugd2hl biBVQTEgaXMgdHJ5aW5nIHRvIHNlbmQgdGhlIEFDSzoKICAgaXQgaXMgbm90IHJlYWR5IHRv IGNoYW5nZSBpdHMgdHJhbnNwb3J0IHByb3RvY29sIGZvciBhIG1pZC1kaWFsb2cKICAgcmVx dWVzdCBhbmQganVzdCBmYWlscyB0byBkbyBzbywgcmVxdWlyaW5nIHRoZSBwcm94eSBpbXBs ZW1lbnRvciB0bwogICBpbnNlcnQgdGhlIHRyYW5zcG9ydCBwcm90b2NvbCBpbiB0aGUgUmVj b3JkLVJvdXRlIFVSSS4KCgoKRnJvbWVudCwgZXQgYWwuICAgICAgICAgRXhwaXJlcyBGZWJy dWFyeSA1LCAyMDEwICAgICAgICAgICAgICAgW1BhZ2UgMTddCgwKSW50ZXJuZXQtRHJhZnQg ICAgICAgICAgICBTSVAgUmVjb3JkLVJvdXRlIGZpeCAgICAgICAgICAgICAgIEF1Z3VzdCAy MDA5CgoKICAgV2hhdCBoYXBwZW5zIGlmIHRoZSBwcm94eSBoYWQgcmVjb3JkLXJvdXRlZCBp dHMgbG9naWNhbCBuYW1lCiAgIChiaWxveGkuZXhhbXBsZS5jb20pPyAgSWYgVUExIGFuZCBV QTIgdXNlIFtSRkMzMjYzXSBwcm9jZWR1cmVzLCBpdAogICB3b3VsZCByZXNvbHZlIHRvIHRo ZSBzYW1lIHRyYW5zcG9ydCBvbiBib3RoIHNpZGVzIGFuZCBvbmx5IGlmIHRoZQogICByZXN1 bHRpbmcgdHJhbnNwb3J0IHdvdWxkIGJlIFVEUCB0cmFuc3BvcnQgcHJvdG9jb2wgc3dpdGNo aW5nIHdvdWxkCiAgIGhhdmUgYmVlbiBhdm9pZGVkIGFuZCB0aGUgc2NlbmFyaW8gd291bGQg d29yay4gIEhvd2V2ZXIsIGlmIG9uZSBvZgogICB0aGUgVUFzIHNlbmRzIGFuIGluaXRpYWwg cmVxdWVzdCB1c2luZyBhIGRpZmZlcmVudCB0cmFuc3BvcnQgdGhhbiB0aGUKICAgb25lIHJl dHJpZXZlZCBmcm9tIEROUywgdGhpcyBzY2VuYXJpbyBpcyBzdGlsbCBwcm9ibGVtYXRpYy4K CiAgIEluIHByYWN0aWNlLCB0aGVyZSBhcmUgbXVsdGlwbGUgc2l0dWF0aW9ucyB3aGVyZSBV QXMgaW1wbGVtZW50YXRpb25zCiAgIGRvbid0IHVzZSBsb2dpY2FsIG5hbWVzIGFuZCBOQVBU UiByZWNvcmRzIHdoZW4gc2VuZGluZyBhbiBpbml0aWFsCiAgIHJlcXVlc3QgdG8gYSBwcm94 eS4gIFRoaXMgaGFwcGVucywgZm9yIGluc3RhbmNlLCB3aGVuOgoKICAgMSkgVUFzIG9mZmVy IHRoZSBhYmlsaXR5IHRvICJjaG9vc2UiIHRoZSB0cmFuc3BvcnQgdG8gYmUgdXNlZCBmb3IK ICAgaW5pdGlhbCByZXF1ZXN0cywgZXZlbiBpZiB0aGV5IHN1cHBvcnQgW1JGQzMyNjNdLiAg VGhpcyBpcyBhIGZyZXF1ZW50CiAgIFVBIGZ1bmN0aW9uYWxpdHkgd2hpY2ggaXMganVzdGlm aWVkIGJ5IHRoZSBmb2xsb3dpbmcgdXNlIGNhc2VzOgoKICAgLSB3aGVuIGl0IGlzIG5vdCBw b3NzaWJsZSB0byBjaGFuZ2UgRE5TIHNlcnZlciBjb25maWd1cmF0aW9uIGFuZCB0aGUKICAg aW1wbGVtZW50YXRpb24gZG9lc24ndCBzdXBwb3J0IGFsbCB0aGUgdHJhbnNwb3J0IHByb3Rv Y29scyB0aGF0IGNvdWxkCiAgIGJlIGNvbmZpZ3VyZWQgYnkgZGVmYXVsdCBpbiBETlMgKGUu Zy46IFRMUykuCgogICAtIHdoZW4gdGhlIGVuZC11c2VyIHdhbnRzIHRvIGNob29zZSBoaXMg dHJhbnNwb3J0IHByb3RvY29sIGZvcgogICB3aGF0ZXZlciByZWFzb24uIGUuZzogbmVlZCB0 byBmb3JjZSBUQ1AsIGF2b2lkaW5nIFVEUCAvIGNvbmdlc3Rpb24sCiAgIHJldHJhbnNtaXNz aW9ucyBvciBmcmFnbWVudGF0aW9uLi4uCgogICBUaGlzIGFiaWxpdHkgdG8gZm9yY2UgdGhl IHRyYW5zcG9ydCBwcm90b2NvbCBpbiBVQSBmb3IgaW5pdGlhbAogICByZXF1ZXN0cyBTSE9V TEQgYmUgYXZvaWRlZDogc2VsZWN0aW5nIHRoZSB0cmFuc3BvcnQgcHJvdG9jb2wgaW4gdGhl CiAgIGNvbmZpZ3VyYXRpb24gb2YgYW4gb3V0Ym91bmQgcHJveHkgbWVhbnMgdGhhdCBbUkZD MzI2M10gcHJvY2VkdXJlIGlzCiAgIGJ5cGFzc2VkIGZvciBpbml0aWFsIHJlcXVlc3RzLiAg QXMgYSBjb25zZXF1ZW5jZSwgaWYgdGhlIHByb3h5CiAgIFJlY29yZC1Sb3V0ZWQgd2l0aCBu byB0cmFuc3BvcnQgcGFyYW1ldGVyIGFzIHJlY29tbWVuZGVkIGluCiAgIFtSRkMzMjYxXSwg dGhlIFVBIHdpbGwgYW55d2F5IGJlIGZvcmNlZCB0byB1c2UgdGhlIFtSRkMzMjYzXS0KICAg cHJlZmVycmVkIHRyYW5zcG9ydCBmb3Igc3Vic2VxdWVudCByZXF1ZXN0cywgd2hpY2ggbGVh ZHMgdG8gdGhlCiAgIHByb2JsZW1hdGljIHNjZW5hcmlvIGRlc2NyaWJlZCBpbiBGaWd1cmUg NC4KCiAgIDIpIFVBcyBkZWNpZGUgdG8gYWx3YXlzIGtlZXAgdGhlIHNhbWUgdHJhbnNwb3J0 IGZvciBhIGdpdmVuIGRpYWxvZy4KICAgVGhpcyBjaG9pY2UgaXMgZXJyYXRpYywgc2luY2Ug aWYgdGhlIHByb3h5IGlzIG5vdCByZWNvcmQtcm91dGluZywgdGhlCiAgIGNhbGxlZSBNQVkg cmVjZWl2ZSB0aGUgc3Vic2VxdWVudCByZXF1ZXN0IHRocm91Z2ggYSB0cmFuc3BvcnQgdGhh dCBpcwogICBub3QgdGhlIG9uZSBwdXQgaW4gaXRzIENvbnRhY3QuICBJZiBhIFVBIHJlYWxs eSB3YW50cyB0byBhdm9pZAogICB0cmFuc3BvcnQgcHJvdG9jb2wgc3dpdGNoaW5nIGJldHdl ZW4gaW5pdGlhbCBhbmQgc3Vic2VxdWVudCByZXF1ZXN0LAogICBpdCBTSE9VTEQgcmVseSBv biBETlMgcmVjb3JkcyBmb3IgdGhhdCwgYW5kIHRodXMgaXQgU0hPVUxEIGF2b2lkCiAgIGNv bmZpZ3VyaW5nIHN0YXRpY2FsbHkgdGhlIG91dGJvdW5kIHByb3h5IHdpdGggYSBudW1lcmlj IElQIGFkZHJlc3M6CiAgIGEgbG9naWNhbCBuYW1lLCB3aXRoIG5vIHRyYW5zcG9ydCBwYXJh bWV0ZXIgU0hPVUxEIGJlIHVzZWQgaW5zdGVhZC4KCiAgIDMpIFVBcyBkb24ndCBzdXBwb3J0 IFtSRkMzMjYzXSBhdCBhbGwsIG9yIGRvbid0IGhhdmUgYW55IEROUyBzZXJ2ZXIKICAgYXZh aWxhYmxlLiAgSW4gdGhhdCBjYXNlLCBhcyBpbGx1c3RyYXRlZCBwcmV2aW91c2x5LCBmb3Jj aW5nIFVBMSB0bwogICBzd2l0Y2ggZnJvbSBUQ1AgdG8gVURQIGJldHdlZW4gaW5pdGlhbCBy ZXF1ZXN0IGFuZCBzdWJzZXF1ZW50CiAgIHJlcXVlc3QocykgaXMgY2xlYXJseSBub3QgdGhl IGRlc2lyZWQgZGVmYXVsdCBiZWhhdmlvdXIsIGFuZCBpdAogICB0eXBpY2FsbHkgbGVhZHMg dG8gaW50ZXJvcGVyYWJpbGl0eSBwcm9ibGVtcy4gIFVBIGltcGxlbWVudGF0aW9ucwogICBT SE9VTEQgdGhlbiBiZSByZWFkeSB0byBjaGFuZ2UgdGhlIHRyYW5zcG9ydCBwcm90b2NvbCBi ZXR3ZWVuIGluaXRpYWwKCgoKRnJvbWVudCwgZXQgYWwuICAgICAgICAgRXhwaXJlcyBGZWJy dWFyeSA1LCAyMDEwICAgICAgICAgICAgICAgW1BhZ2UgMThdCgwKSW50ZXJuZXQtRHJhZnQg ICAgICAgICAgICBTSVAgUmVjb3JkLVJvdXRlIGZpeCAgICAgICAgICAgICAgIEF1Z3VzdCAy MDA5CgoKICAgYW5kIHN1YnNlcXVlbnQgcmVxdWVzdHMuICBJbiB0aGVvcnksIGFueSBVQSBv ciBwcm94eSB1c2luZyBVRFAgbXVzdAogICBhbHNvIGJlIHByZXBhcmVkIHRvIHVzZSBUQ1Ag Zm9yIHJlcXVlc3RzIHRoYXQgZXhjZWVkIHRoZSBzaXplIGxpbWl0CiAgIG9mIHBhdGggTVRV LCBhcyBkZXNjcmliZWQgaW4gc2VjdGlvbiAxOC4xLjEgb2YgW1JGQzMyNjFdLgoKNi4yLiAg UHJveHkgaW1wbGVtZW50YXRpb25zIHByb2JsZW1zIGFuZCByZWNvbW1lbmRhdGlvbnMKCiAg IEluIG9yZGVyIHRvIHByZXZlbnQgVUEgaW1wbGVtZW50YXRpb24gcHJvYmxlbXMsIGFuZCB0 byBtYWludGFpbiBhCiAgIHJlYXNvbmFibGUgbGV2ZWwgb2YgaW50ZXJvcGVyYWJpbGl0eSwg dGhlIHNpdHVhdGlvbiBjYW4gYmUgaW1wcm92ZWQKICAgb24gcHJveHkgc2lkZS4gIFRodXMs IGlmIHRoZSB0cmFuc3BvcnQgcHJvdG9jb2wgY2hhbmdlZCBiZXR3ZWVuIGl0cwogICBpbmNv bWluZyBhbmQgb3V0Z29pbmcgc2lkZXMsIHRoZSBwcm94eSBTSE9VTEQgdXNlIHRoZSBkb3Vi bGUgUmVjb3JkLQogICBSb3V0ZSB0ZWNobmlxdWUgYW5kIFNIT1VMRCBhZGQgYSB0cmFuc3Bv cnQgcGFyYW1ldGVyIHRvIGVhY2ggb2YgdGhlCiAgIFJlY29yZC1Sb3V0ZSBVUklzIGl0IGlu c2VydHMuICBXaXRoIHRoZSBleGNlcHRpb24gdGhhdCBpZiBUTFMgaXMgdXNlZAogICBhcyB0 aGUgdHJhbnNwb3J0IHByb3RvY29sIG9uIGVpdGhlciBzaWRlIG9mIHRoZSBwcm94eSwgdGhl IFVSSSBjaG9zZW4KICAgdG8gcGxhY2UgaW4gdGhlIFJlY29yZC1Sb3V0ZSBoZWFkZXIgZmll bGQgdmFsdWUgcmVmbGVjdGluZyB0aGUKICAgaW50ZXJmYWNlIHVzaW5nIFRMUyB3aWxsIG5l ZWQgdG8gbGV2ZXJhZ2UgdGhlIFtSRkMzMjYzXSBtZWNoYW5pc21zIHRvCiAgIGluZGljYXRl IHRoYXQgVExTIG11c3QgYmUgdXNlZCByYXRoZXIgYXR0ZW1wdGluZyB0byB1c2UgdGhlCiAg IGRlcHJlY2F0ZWQgInRyYW5zcG9ydD10bHMiIFVSSSBwYXJhbWV0ZXIuICBTZWUgW1JGQzMy NjFdIFNlY3Rpb24KICAgMjYuMi4yIGFuZCBbSS1ELmlldGYtc2lwLXNpcHNdIFNlY3Rpb24g My4xLjQgZm9yIG1vcmUgZGlzY3Vzc2lvbi4KICAgUmVjb3JkLVJvdXRlIFJld3JpdGluZyBN QVkgYWxzbyBiZSB1c2VkLiAgSG93ZXZlciwgdGhlIHJlY29tbWVuZGF0aW9uCiAgIHRvIHB1 dCBhIHRyYW5zcG9ydCBwcm90b2NvbCBwYXJhbWV0ZXIgb24gUmVjb3JkLVJvdXRlIFVSSSBk b2VzIG5vdAogICBhcHBseSB3aGVuIHRoZSBwcm94eSBoYXMgY2hhbmdlZCB0aGUgdHJhbnNw b3J0IHByb3RvY29sIGR1ZSB0byB0aGUKICAgc2l6ZSBvZiBVRFAgcmVxdWVzdHMgYXMgcGVy IHNlY3Rpb24gMTguMS4xIG9mIFtSRkMzMjYxXS4gIEFzIGFuCiAgIGlsbHVzdHJhdGlvbiBv ZiBwcmV2aW91cyBleGFtcGxlLCBpdCBtZWFucyBvbmUgb2YgdGhlIGZvbGxvd2luZwogICBw cm9jZXNzaW5nIHdpbGwgYmUgcGVyZm9ybWVkOgoKICAgLSBEb3VibGUgUmVjb3JkLVJvdXRp bmc6IHRoZSBwcm94eSBwdXRzIHR3byBSZWNvcmQtUm91dGUgaGVhZGVycy4KICAgVGhlIGZp cnN0IG9uZSBpcyBzZXQsIGluIHRoaXMgZXhhbXBsZSwgdG8gUmVjb3JkLVJvdXRlOiA8c2lw OgogICAxOTIuMC4yLjE7bHI7dHJhbnNwb3J0PXRjcD4sIHRoZSBzZWNvbmQgb25lIHRvIFJl Y29yZC1Sb3V0ZTogPHNpcDoKICAgMTkyLjAuMi4xO2xyPiB3aXRoIG5vIHRyYW5zcG9ydCwg b3Igd2l0aCB0cmFuc3BvcnQ9dWRwLCB3aGljaAogICBiYXNpY2FsbHkgbWVhbnMgdGhlIHNh bWUgdGhpbmcuCgogICAtIFJlY29yZC1Sb3V0ZSByZXdyaXRpbmcgb24gcmVzcG9uc2VzOiBp biB0aGUgSU5WSVRFIHJlcXVlc3Qgc2VudCBpbgogICBGMiwgcHJveHkgcHV0cyB0aGUgb3V0 Z29pbmcgdHJhbnNwb3J0IHByb3RvY29sIGluIHRoZSB0cmFuc3BvcnQKICAgcGFyYW1ldGVy IG9mIFJlY29yZC1Sb3V0ZSBVUkkuICBEb2luZyBzbywgVUEyIHdpbGwgY29ycmVjdGx5IHNl bmQgaXRzCiAgIEJZRSByZXF1ZXN0IGluIEY2IHVzaW5nIHRoZSBzYW1lIHRyYW5zcG9ydCBw cm90b2NvbCBhcyBwcmV2aW91cwogICBtZXNzYWdlcyBvZiB0aGUgc2FtZSBkaWFsb2cuICBQ cm94eSByZXdyaXRlcyB0aGUgUmVjb3JkLVJvdXRlIHdoZW4KICAgcHJvY2Vzc2luZyB0aGUg MjAwIE9LIHJlc3BvbnNlLCBjaGFuZ2luZyAib24gdGhlIGZseSIgdGhlIHRyYW5zcG9ydAog ICBwYXJhbWV0ZXIgdG8gInRyYW5zcG9ydD10Y3AiLCBzbyB0aGF0IHRoZSBSb3V0ZSBzZXQg d2lsbCBhcHBlYXIgdG8gYmUKICAgPHNpcDoxOTIuMC4yLjE7bHI7dHJhbnNwb3J0PXRjcD4g Zm9yIFVBMSBhbmQgPHNpcDoKICAgMTkyLjAuMi4xO2xyO3RyYW5zcG9ydD11ZHA+IGZvciBV QTIuCgogICBJdCBpcyBhIGNvbW1vbiBwcmFjdGljZSBpbiBwcm94eSBpbXBsZW1lbnRhdGlv bnMgdG8gc3VwcG9ydCBkb3VibGUKICAgUmVjb3JkLVJvdXRlIEFORCB0byBpbnNlcnQgdGhl IHRyYW5zcG9ydCBwYXJhbWV0ZXIgaW4gdGhlIFJlY29yZC0KICAgUm91dGUgVVJJLiAgVGhp cyBwcmFjdGljZSBpcyBhY2NlcHRhYmxlIGFzIGxvbmcgYXMgYWxsIFNJUCBlbGVtZW50cwog ICB0aGF0IG1heSBiZSBpbiB0aGUgcGF0aCBvZiBzdWJzZXF1ZW50IHJlcXVlc3RzIHN1cHBv cnQgdGhhdAogICB0cmFuc3BvcnQuICBUaGlzIHJlc3RyaWN0aW9uIG5lZWRzIGFuIGV4cGxh bmF0aW9uOiBsZXQncyBpbWFnaW5lIHlvdQogICBoYXZlIHR3byBwcm94aWVzIFAxIGF0ICJw MS5iaWxveGkuZXhhbXBsZS5jb20iIGFuZCBQMiBvbiB0aGUgcGF0aCBvZgogICBhbiBpbml0 aWFsIHJlcXVlc3QuICBQMSBpcyByZWNvcmQtcm91dGluZyBhbmQgY2hhbmdlcyB0aGUgdHJh bnNwb3J0CgoKCkZyb21lbnQsIGV0IGFsLiAgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgNSwg MjAxMCAgICAgICAgICAgICAgIFtQYWdlIDE5XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAg ICAgU0lQIFJlY29yZC1Sb3V0ZSBmaXggICAgICAgICAgICAgICBBdWd1c3QgMjAwOQoKCiAg IGZyb20gVURQIHRvIFNDVFAgYmVjYXVzZSBQMiBVUkkgcmVzb2x2ZXMgdG8gU0NUUCB0cmFu c3BvcnQgYXBwbHlpbmcKICAgW1JGQzMyNjNdLiAgQ29uc2VxdWVudGx5LCB0aGUgcHJveHkg UDEgaW5zZXJ0cyB0d28gUmVjb3JkLVJvdXRlCiAgIGhlYWRlcnM6CgogICBSZWNvcmQtUm91 dGU6IDxzaXA6cDEuYmlsb3hpLmV4YW1wbGUuY29tO3RyYW5zcG9ydD11ZHA+IGFuZAoKICAg UmVjb3JkLVJvdXRlOiA8c2lwOnAxLmJpbG94aS5leGFtcGxlLmNvbTt0cmFuc3BvcnQ9c2N0 cD4uCgogICBUaGUgcHJvYmxlbSBhcmlzZXMgaWYgUDIgaXMgbm90IHJlY29yZC1yb3V0aW5n LCBiZWNhdXNlIHRoZSBTSVAKICAgZWxlbWVudCBkb3duc3RyZWFtIG9mIFAyIHdpbGwgYmUg YXNrZWQgdG8gcmVhY2ggUDEgdXNpbmcgU0NUUAogICB0cmFuc3BvcnQgcHJvdG9jb2wgZm9y IGFueSBzdWJzZXF1ZW50LCBpbi1kaWFsb2cgcmVxdWVzdCBmcm9tIHRoZQogICBjYWxsZWUs IGFuZCB0aGlzIGRvd25zdHJlYW0gU0lQIGVsZW1lbnQgbWF5IG5vdCBzdXBwb3J0IHRoYXQK ICAgdHJhbnNwb3J0LgoKICAgSW4gb3JkZXIgdG8gaGFuZGxlIHRoaXMgc2l0dWF0aW9uLCB0 aGlzIGRvY3VtZW50IHJlY29tbWVuZHMgdGhhdCBhCiAgIHByb3h5IFNIT1VMRCBhcHBseSB0 aGUgZG91YmxlIFJlY29yZC1Sb3V0aW5nIHRlY2huaXF1ZSBhcyBzb29uIGFzIGl0CiAgIGNo YW5nZXMgdGhlIHRyYW5zcG9ydCBwcm90b2NvbCBiZXR3ZWVuIGl0cyBpbmNvbWluZyBhbmQg b3V0Z29pbmcKICAgc2lkZXMuICBJZiBwcm94eSBQMiBpbiB0aGUgZXhhbXBsZSBhYm92ZSB3 b3VsZCBmb2xsb3cgdGhpcwogICByZWNvbW1lbmRhdGlvbiwgaXQgd291bGQgcGVyZm9ybSBk b3VibGUgUmVjb3JkLVJvdXRpbmcgYW5kIHRoZQogICBkb3duc3RyZWFtIGVsZW1lbnQgd291 bGQgbm90IGJlIGZvcmNlZCB0byBzZW5kIHJlcXVlc3RzIG92ZXIgYQogICB0cmFuc3BvcnQg aXQgZG9lcyBub3Qgc3VwcG9ydC4KCiAgIEJ5IGV4dGVuc2lvbiwgYSBwcm94eSBTSE9VTEQg YWxzbyBpbnNlcnQgYSBSZWNvcmQtUm91dGUgaGVhZGVyIGZvcgogICBhbnkgbXVsdGktaG9t ZWQgc2l0dWF0aW9uIChhcyB0aGUgb25lcyBkZXNjcmliZWQgaW4gdGhpcyBkb2N1bWVudDsK ICAgc2NoZW1lIGNoYW5nZXMsIHNpZ2NvbXAsIElQdjQvSVB2NiwgdHJhbnNwb3J0IGNoYW5n ZXMuLi4pIHRoYXQgbWF5CiAgIGltcGFjdCB0aGUgcHJvY2Vzc2luZyBvZiBwcm94aWVzIGJl aW5nIG9uIHRoZSBwYXRoIG9mIHN1YnNlcXVlbnQKICAgcmVxdWVzdHMuCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCkZyb21lbnQsIGV0IGFsLiAgICAgICAgIEV4cGlyZXMgRmVicnVhcnkg NSwgMjAxMCAgICAgICAgICAgICAgIFtQYWdlIDIwXQoMCkludGVybmV0LURyYWZ0ICAgICAg ICAgICAgU0lQIFJlY29yZC1Sb3V0ZSBmaXggICAgICAgICAgICAgICBBdWd1c3QgMjAwOQoK CjcuICBDb25jbHVzaW9uCgogICBBcyBhIGNvbmNsdXNpb24gb2YgdGhpcyBkb2N1bWVudCwg aXQgaXMgdG8gbm90aWNlIHRoYXQ6CgogICAgICAtIFJlY29yZC1Sb3V0ZSByZXdyaXRpbmcg aXMgcHJlc2VudGVkIGFzIGEgdGVjaG5pcXVlIHRoYXQgTUFZIGJlCiAgICAgIHVzZWQsIHdp dGggdGhlIGRyYXdiYWNrcyBvdXRsaW5lZCBpbiBzZWN0aW9uIDQuCgogICAgICAtIERvdWJs ZSBSZWNvcmQtUm91dGluZyBpcyBwcmVzZW50ZWQgYXMgdGhlIHRlY2huaXF1ZSB0aGF0IFNI T1VMRAogICAgICBiZSB1c2VkLCBhbmQgaXMgZG9jdW1lbnRlZCBpbiBzZWN0aW9uIDUuCgog ICAgICAtIFJlY29yZC1Sb3V0ZSBoZWFkZXIgaW50ZXJvcGVyYWJpbGl0eSBwcm9ibGVtcyBv biB0cmFuc3BvcnQKICAgICAgcHJvdG9jb2wgc3dpdGNoaW5nIHNjZW5hcmlvcyBoYXZlIGJl ZW4gb3V0bGluZWQgYW5kIGRlc2NyaWJlZCBpbgogICAgICBzZWN0aW9uIDYuICBUaGlzIGxh c3Qgc2VjdGlvbiBnaXZlcyBzb21lIHJlY29tbWVuZGF0aW9ucyB0byBVQSBhbmQKICAgICAg cHJveHkgaW1wbGVtZW50YXRpb25zIHRvIGltcHJvdmUgdGhlIHNpdHVhdGlvbi4gIFByb3hp ZXMgU0hPVUxECiAgICAgIHVzZSBEb3VibGUgUmVjb3JkLVJvdXRpbmcgZm9yIGFueSBtdWx0 aS1ob21lZCBzaXR1YXRpb24gdGhhdCBNQVkKICAgICAgaW1wYWN0IHRoZSBmdXJ0aGVyIHBy b2Nlc3NpbmcsIGFuZCBTSE9VTEQgcHV0IHRyYW5zcG9ydCBwcm90b2NvbAogICAgICBwYXJh bWV0ZXJzIG9uIFJlY29yZC1Sb3V0ZSBVUkkgaW4gc29tZSBjaXJjdW1zdGFuY2VzLiAgVUFz IFNIT1VMRAogICAgICBOT1Qgb2ZmZXIgb3B0aW9ucyB0byBvdmVyd3JpdGUgdGhlIHRyYW5z cG9ydCBmb3IgaW5pdGlhbCByZXF1ZXN0cy4KICAgICAgRnVydGhlciwgVUFzIFNIT1VMRCBy ZWx5IG9uIEROUyB0byBleHByZXNzIHRoZWlyIGRlc2lyZWQgdHJhbnNwb3J0CiAgICAgIGFu ZCBTSE9VTEQgYXZvaWQgSVAgYWRkcmVzc2VzIHdpdGggdHJhbnNwb3J0IHBhcmFtZXRlcnMg aW4gdGhpcwogICAgICBjYXNlLiAgRmluYWxseSBVQXMgU0hPVUxEIGJlIHJlYWR5IHRvIHN3 aXRjaCB0cmFuc3BvcnQgYmV0d2VlbiB0aGUKICAgICAgaW5pdGlhbCByZXF1ZXN0IGFuZCBm dXJ0aGVyIGluLWRpYWxvZyBtZXNzYWdlcy4KCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgpGcm9tZW50LCBldCBhbC4gICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDUsIDIwMTAgICAg ICAgICAgICAgICBbUGFnZSAyMV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgIFNJUCBS ZWNvcmQtUm91dGUgZml4ICAgICAgICAgICAgICAgQXVndXN0IDIwMDkKCgo4LiAgSUFOQSBD b25zaWRlcmF0aW9ucwoKICAgVGhpcyBkb2N1bWVudCBkb2VzIG5vdCByZXF1aXJlIGFueSBh Y3Rpb25zIGJ5IElBTkEuCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCkZyb21lbnQsIGV0IGFsLiAgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgNSwg MjAxMCAgICAgICAgICAgICAgIFtQYWdlIDIyXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAg ICAgU0lQIFJlY29yZC1Sb3V0ZSBmaXggICAgICAgICAgICAgICBBdWd1c3QgMjAwOQoKCjku ICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucwoKICAgVGhlIHJlY29tbWVuZGF0aW9ucyBpbiB0 aGlzIGRvY3VtZW50IGRlc2NyaWJlIGEgd2F5IHRvIHVzZSB0aGUKICAgZXhpc3RpbmcgcHJv dG9jb2wgc3BlY2lmaWVkIGluIFJGQzMyNjEgcmF0aGVyIHRoYW4gaW50cm9kdWNpbmcgYW55 CiAgIG5ldyBwcm90b2NvbCBtZWNoYW5pc20uICBBcyBzdWNoLCB0aGV5IGRvIG5vdCBpbnRy b2R1Y2UgYW55IG5ldwogICBzZWN1cml0eSBjb25jZXJucywgYnV0IGFkZGl0aW9uYWwgY29u c2lkZXJhdGlvbiBvZiBhbHJlYWR5IGV4aXN0aW5nCiAgIGNvbmNlcm5zIGlzIHdhcnJhbnRl ZC4gIEluIHBhcnRpY3VsYXIsIHdoZW4gYSBtZXNzYWdlIGlzIHRyYW5zaXRpbmcKICAgdHdv IGludGVyZmFjZXMsIHRoZSBkb3VibGUgUmVjb3JkLVJvdXRlIHRlY2huaXF1ZSB3aWxsIGNh cnJ5CiAgIGluZm9ybWF0aW9uIGFib3V0IGJvdGggaW50ZXJmYWNlcyB0byBlYWNoIG9mIHRo ZSBpbnZvbHZlZCBlbmRwb2ludHMKICAgKGFuZCBhbnkgaW50ZXJtZWRpYXJpZXMgYmV0d2Vl biB0aGlzIHByb3h5IGFuZCB0aG9zZSBlbmRwb2ludHMpLAogICB3aGVyZSB0aGUgcmV3cml0 aW5nIHRlY2huaXF1ZSB3b3VsZCBvbmx5IGV4cG9zZSBpbmZvcm1hdGlvbiBhYm91dCB0aGUK ICAgaW50ZXJmYWNlIGNsb3Nlc3QgdG8gZWFjaCBnaXZlbiBlbmRwb2ludC4gIElmIGlzc3Vl cyBzdWNoIGFzIHRvcG9sb2d5CiAgIGhpZGluZyBvciBwcml2YWN5IChhcyBkZXNjcmliZWQg aW4gW1JGQzMzMjNdKSBhcmUgYSBjb25jZXJuLCB0aGUgVVJJCiAgIHZhbHVlcyBwbGFjZWQg aW4gdGhlIFJlY29yZC1Sb3V0ZSBmb3IgZWFjaCBpbnRlcmZhY2Ugc2hvdWxkIGJlCiAgIGNh cmVmdWxseSBjb25zdHJ1Y3RlZCB0byBhdm9pZCBleHBvc2luZyBtb3JlIGluZm9ybWF0aW9u IHRoYW4gd2FzCiAgIGludGVuZGVkLgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCkZyb21lbnQsIGV0IGFsLiAgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgNSwgMjAxMCAg ICAgICAgICAgICAgIFtQYWdlIDIzXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgU0lQ IFJlY29yZC1Sb3V0ZSBmaXggICAgICAgICAgICAgICBBdWd1c3QgMjAwOQoKCjEwLiAgQWNr bm93bGVkZ21lbnRzCgogICBEZWFuIFdpbGxpcyB3aG8gY29udHJpYnV0ZWQsIHRocm91Z2gg dGhlIG1haWxpbmcgbGlzdHMsIHRvIG1vc3Qgb2YKICAgdGhlIHByb2JsZW0gc3RhdGVtZW50 IGVsZW1lbnRzLiAgVmlqYXkgSy4gR3VyYmFuaSB3aG8gcHJvdmlkZWQKICAgaW1wb3J0YW50 IHJlZmVyZW5jZXMgYW5kIHN1YnN0YW50aWFsIG1vZGlmaWNhdGlvbnMuCgogICBKb2VsIFJl cGlxdWV0LCBSb2JlcnQgU3BhcmtzLCBKb25hdGhhbiBSb3NlbmJlcmcsIEN1bGxlbiBKZW5u aW5ncywKICAgSnVoYSBIZWluYW5lbiwgUGF1bCBLeXppdmF0LCBOaWxzIE9obG1laWVyLCBU aW0gUG9saywgRnJhbmNvaXMgQXVkZXQsCiAgIEFkcmlhbiBGYXJyZWwsIFJhbHBoIERyb21z LCBUb20gQmF0c2VsZSBZYW5uaWNrIEJvdXJnZXQgYW5kIEtlaXRoCiAgIERyYWdlIGZvciB0 aGVpciByZXZpZXdzIGFuZCBjb21tZW50cy4KCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgpGcm9tZW50LCBldCBhbC4gICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5 IDUsIDIwMTAgICAgICAgICAgICAgICBbUGFnZSAyNF0KDApJbnRlcm5ldC1EcmFmdCAgICAg ICAgICAgIFNJUCBSZWNvcmQtUm91dGUgZml4ICAgICAgICAgICAgICAgQXVndXN0IDIwMDkK CgoxMS4gIFJlZmVyZW5jZXMKCjExLjEuICBOb3JtYXRpdmUgUmVmZXJlbmNlcwoKICAgW0kt RC5pZXRmLXNpcC1zaXBzXQogICAgICAgICAgICAgIEF1ZGV0LCBGLiwgIlRoZSB1c2Ugb2Yg dGhlIFNJUFMgVVJJIFNjaGVtZSBpbiB0aGUgU2Vzc2lvbgogICAgICAgICAgICAgIEluaXRp YXRpb24gUHJvdG9jb2wgKFNJUCkiLCBkcmFmdC1pZXRmLXNpcC1zaXBzLTA5ICh3b3JrCiAg ICAgICAgICAgICAgaW4gcHJvZ3Jlc3MpLCBOb3ZlbWJlciAyMDA4LgoKICAgW1JGQzIxMTld ICBCcmFkbmVyLCBTLiwgIktleSB3b3JkcyBmb3IgdXNlIGluIFJGQ3MgdG8gSW5kaWNhdGUK ICAgICAgICAgICAgICBSZXF1aXJlbWVudCBMZXZlbHMiLCBNYXJjaCAxOTk3LgoKICAgW1JG QzMyNjFdICBSb3NlbmJlcmcsIEouLCBTY2h1bHpyaW5uZSwgSC4sIENhbWFyaWxsbywgRy4s IEpvaG5zdG9uLAogICAgICAgICAgICAgIEEuLCBQZXRlcnNvbiwgSi4sIFNwYXJrcywgUi4s IEhhbmRsZXksIE0uLCBhbmQgRS4KICAgICAgICAgICAgICBTY2hvb2xlciwgIlNJUDogU2Vz c2lvbiBJbml0aWF0aW9uIFByb3RvY29sIiwgUkZDIDMyNjEsCiAgICAgICAgICAgICAgSnVu ZSAyMDAyLgoKICAgW1JGQzMyNjNdICBSb3NlbmJlcmcsIEouIGFuZCBILiBTY2h1bHpyaW5u ZSwgIlNlc3Npb24gSW5pdGlhdGlvbgogICAgICAgICAgICAgIFByb3RvY29sIChTSVApOiBM b2NhdGluZyBTSVAgU2VydmVycyIsIFJGQyAzMjYzLAogICAgICAgICAgICAgIEp1bmUgMjAw Mi4KCiAgIFtSRkMzMzIzXSAgUGV0ZXJzb24sIEouLCAiQSBQcml2YWN5IE1lY2hhbmlzbSBm b3IgdGhlIFNlc3Npb24KICAgICAgICAgICAgICBJbml0aWF0aW9uIFByb3RvY29sIChTSVAp IiwgUkZDIDMzMjMsIE5vdmVtYmVyIDIwMDIuCgoxMS4yLiAgSW5mb3JtYXRpdmUgUmVmZXJl bmNlcwoKICAgW0JVRzY2NF0gICBTcGFya3MsIFJTLiwgIkJ1ZyA2NjQ6IERvdWJsZSByZWNv cmQgcm91dGluZywKICAgICAgICAgICAgICBodHRwOi8vYnVncy5zaXBpdC5uZXQvc2hvd19i dWcuY2dpP2lkPTY2NCIsIE9jdG9iZXIgMjAwMi4KCiAgIFtJLUQuaWV0Zi1zaXBwaW5nLXY2 LXRyYW5zaXRpb25dCiAgICAgICAgICAgICAgQ2FtYXJpbGxvLCBHLiwgIklQdjYgVHJhbnNp dGlvbiBpbiB0aGUgU2Vzc2lvbiBJbml0aWF0aW9uCiAgICAgICAgICAgICAgUHJvdG9jb2wg KFNJUCkiLCBkcmFmdC1pZXRmLXNpcHBpbmctdjYtdHJhbnNpdGlvbi0wNyAod29yawogICAg ICAgICAgICAgIGluIHByb2dyZXNzKSwgQXVndXN0IDIwMDcuCgogICBbUkZDMzQ4Nl0gIENh bWFyaWxsbywgRy4sICJDb21wcmVzc2luZyB0aGUgU2Vzc2lvbiBJbml0aWF0aW9uCiAgICAg ICAgICAgICAgUHJvdG9jb2wgKFNJUCkiLCBSRkMgMzQ4NiwgRmVicnVhcnkgMjAwMy4KCiAg IFtSRkMzNjA4XSAgV2lsbGlzLCBELiBhbmQgQi4gSG9lbmVpc2VuLCAiU2Vzc2lvbiBJbml0 aWF0aW9uIFByb3RvY29sCiAgICAgICAgICAgICAgKFNJUCkgRXh0ZW5zaW9uIEhlYWRlciBG aWVsZCBmb3IgU2VydmljZSBSb3V0ZSBEaXNjb3ZlcnkKICAgICAgICAgICAgICBEdXJpbmcg UmVnaXN0cmF0aW9uIiwgUkZDIDM2MDgsIE9jdG9iZXIgMjAwMy4KCgoKCgoKCgoKCgpGcm9t ZW50LCBldCBhbC4gICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDUsIDIwMTAgICAgICAgICAg ICAgICBbUGFnZSAyNV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgIFNJUCBSZWNvcmQt Um91dGUgZml4ICAgICAgICAgICAgICAgQXVndXN0IDIwMDkKCgpBdXRob3JzJyBBZGRyZXNz ZXMKCiAgIFRob21hcyBGcm9tZW50CiAgIChVbmFmZmlsaWF0ZWQpCiAgIDcgQ2xvcyBkdSBQ ZXJyYXkKICAgTG9uZ3BvbnQgc3VyIE9yZ2UgIDkxMzEwCiAgIEZyYW5jZQoKICAgRW1haWw6 IHRmcm9tZW50QHlhaG9vLmNvbQoKCiAgIENocmlzdG9waGUgTGViZWwKICAgQWxjYXRlbC1M dWNlbnQKICAgTGlldSBkaXQgTGUgTWFpbAogICBPcnZhdWx0ICA0NDcwOAogICBGcmFuY2UK CiAgIEVtYWlsOiBDaHJpc3RvcGhlLkxlYmVsQGFsY2F0ZWwtbHVjZW50LmZyCgoKICAgQmVu IEJvbm5hZXJlbnMKICAgQWxjYXRlbC1MdWNlbnQKICAgQ29wZXJuaWN1c2xhYW4gNTAKICAg QW50d2VycGVuICAyMDE4CiAgIEJlbGdpdW0KCiAgIEVtYWlsOiBiZW4uYm9ubmFlcmVuc0Bh bGNhdGVsLWx1Y2VudC5iZQoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgpGcm9tZW50LCBldCBh bC4gICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDUsIDIwMTAgICAgICAgICAgICAgICBbUGFn ZSAyNl0KDAoK --------------020508030100090204010705-- From john.elwell@siemens-enterprise.com Tue Aug 11 01:44:40 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 511A43A682D for ; Tue, 11 Aug 2009 01:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.153 X-Spam-Level: X-Spam-Status: No, score=-2.153 tagged_above=-999 required=5 tests=[AWL=-0.154, BAYES_00=-2.599, J_CHICKENPOX_93=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rcsfk8eMxRa4 for ; Tue, 11 Aug 2009 01:44:39 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 15E263A6A95 for ; Tue, 11 Aug 2009 01:43:56 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KO700690EXBFX@siemenscomms.co.uk> for sip@ietf.org; Tue, 11 Aug 2009 09:43:59 +0100 (BST) Date: Tue, 11 Aug 2009 09:43:57 +0100 From: "Elwell, John" In-reply-to: <8144761F31F48D43AD53D09F5350E38004C01534@FRVELSMBS22.ad2.ad.alcatel.com> To: BONNAERENS Ben , sip@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0023D22FA@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: quoted-printable Thread-Topic: [Sip] draft-ietf-sip-record-route-fix-08 Changes Thread-Index: AcoV2D3o9zuX5uy0THC/DMS48GQffwAj7G0wAD7JfZAAvwlgsA== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <8144761F31F48D43AD53D09F5350E38004C00CE5@FRVELSMBS22.ad2.ad.alcatel.com> A <0D5F89FAC29E2C41B98A6A762007F5D002393EA0@GBNTHT12009MSX.gb002.siemens.net> <8144761F31F48D43AD53D09F5350E38004C01534@FRVELSMBS22.ad2.ad.alcatel.com> Subject: Re: [Sip] draft-ietf-sip-record-route-fix-08 Changes X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 08:44:40 -0000 In that case, I obviously misunderstood the text in the current draft. What exactly is the meaning of "will need to leverage the [RFC3263] mechanisms"? John > -----Original Message----- > From: BONNAERENS Ben [mailto:ben.bonnaerens@alcatel-lucent.be]=20 > Sent: 07 August 2009 14:57 > To: Elwell, John; sip@ietf.org > Subject: RE: [Sip] draft-ietf-sip-record-route-fix-08 Changes >=20 > Hello John, >=20 > > Well, I know what this means, but will your average reader=20 > > understand it? I think we are trying to say something along=20 > > the lines that if the transport protocol changes you SHOULD=20 > > use the double Record-Route technique, where the differences=20 > > in transport protocol are reflected in different values of=20 > > the transport parameter (udp/tcp/sctp) and/or different=20 > > values of the URI scheme (sip/sips). Correct? >=20 > Your phrasing could lead to the understanding that we suggest that=20 > only a sips URI can be used to identify the TLS interface which is not > correct. > As the current text suggests, can the TLS interface be=20 > identified by any > URI > (sip or sips ; excluding the deprecated transport=3Dtls parameter) = that=20 > resolves via RFC3263 procedures to the TLS transport. >=20 > IMHO leaves your suggested phrasing more room for ambiguity > compared to the current text. >=20 > Best regards & thanks, >=20 > Ben. =20 >=20 > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 > > Sent: donderdag 6 augustus 2009 9:37 > > To: BONNAERENS Ben; sip@ietf.org > > Subject: RE: [Sip] draft-ietf-sip-record-route-fix-08 Changes > >=20 > > Well, I know what this means, but will your average reader=20 > > understand it? I think we are trying to say something along=20 > > the lines that if the transport protocol changes you SHOULD=20 > > use the double Record-Route technique, where the differences=20 > > in transport protocol are reflected in different values of=20 > > the transport parameter (udp/tcp/sctp) and/or different=20 > > values of the URI scheme (sip/sips). Correct? > >=20 > > John > >=20 > > > -----Original Message----- > > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20 > > Behalf Of=20 > > > BONNAERENS Ben > > > Sent: 05 August 2009 15:23 > > > To: sip@ietf.org > > > Subject: [Sip] draft-ietf-sip-record-route-fix-08 Changes > > >=20 > > > Hi, > > > version -08 of record-route fix has just been submitted. > > >=20 > > > Change log: > > > - Changed its status from BCP to PS, > > > - Take into account IESG reviews and subsequent comments on the=20 > > > mailing lists, they were summarized in Robert Sparks's document=20 > > > (rrf.txt), so it has been integrated in version -08 with minor=20 > > > refactoring from the authors (me and Ben). > > >=20 > > > The thoughest part was related to the SIP/SIPS question raised by=20 > > > Cullen=20 > > (http://datatracker.ietf.org/idtracker/draft-ietf-sip-record-r > > > oute-fix/c > > > omment/98624/), > > > so here is the text that was added in version -08 to answer this > > > question: > > > "Thus, if the transport protocol changed between its > > > incoming and outgoing sides, the proxy SHOULD use the double > > > Record-Route technique and SHOULD add a transport=20 > > parameter to each > > > of the Record-Route URIs it inserts. With the exception=20 > > that if TLS=20 > > > is > > > used as the transport protocol on either side of the=20 > > proxy, the URI > > > chosen to place in the Record-Route header field value=20 > > reflecting=20 > > > the > > > interface using TLS will need to leverage the [RFC3263]=20 > > mechanisms=20 > > > to > > > indicate that TLS must be used rather attempting to use the=20 > > > deprecated > > > "transport=3Dtls" URI parameter. See [RFC3261] Section 26.2.2 = and > > > [I-D.ietf-sip-sips] Section 3.1.4 for more discussion." > > >=20 > > > Brds, > > > Thomas & Ben > > > _______________________________________________ > > > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol Use=20 > > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > > sipping@ietf.org for new developments on the application of sip > > >=20 > >=20 >=20 From tzieleniewski@gmail.com Tue Aug 11 04:01:38 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 343FB3A63CB for ; Tue, 11 Aug 2009 04:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_93=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JYi97GRFQhnN for ; Tue, 11 Aug 2009 04:01:37 -0700 (PDT) Received: from mail-fx0-f226.google.com (mail-fx0-f226.google.com [209.85.220.226]) by core3.amsl.com (Postfix) with ESMTP id 603683A6358 for ; Tue, 11 Aug 2009 04:01:35 -0700 (PDT) Received: by fxm26 with SMTP id 26so1553694fxm.42 for ; Tue, 11 Aug 2009 04:01:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=amSp6S/0SHWvhSqqbU+6A7jQt+/jdxvaVjBQbZ3J9e0=; b=MgV6WTE4/XzQxKA+W+zYYrOtflkJxc6eYcZ14xNhocko9WNpncyT4wkSSZ3EsJX/hT XuerwVhR8AlVYCTgpN32+ijMxvyVSzDTOE/EcKban6jZL5F7zUOMqmxTnP8KLnwIvcBr E0Z0EEXFkBupQECF3Mb9k15z7QK31e8ZvbPhA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=sqrlPJRGh612526x0dlAwNL+IV8oWzjncXFOoY2gwYLwHNr4oS6GTusQBnG5FUKwiW pSwFfMFklSqU5wZeA9KGsWQsFKpz1cewjzAofRHLFwHkHbjPWY2gktccZL/2FvNTazO1 bWSfbDnWYiJbNkPLn6+Q5Jp46rnfQB8L2WLtY= MIME-Version: 1.0 Received: by 10.223.121.6 with SMTP id f6mr620471far.51.1249988497064; Tue, 11 Aug 2009 04:01:37 -0700 (PDT) In-Reply-To: <8144761F31F48D43AD53D09F5350E38004C01534@FRVELSMBS22.ad2.ad.alcatel.com> References: <8144761F31F48D43AD53D09F5350E38004C00CE5@FRVELSMBS22.ad2.ad.alcatel.com> <0D5F89FAC29E2C41B98A6A762007F5D002393EA0@GBNTHT12009MSX.gb002.siemens.net> <8144761F31F48D43AD53D09F5350E38004C01534@FRVELSMBS22.ad2.ad.alcatel.com> Date: Tue, 11 Aug 2009 13:01:36 +0200 Message-ID: <5fd52d7a0908110401lc151128v891ec1289927a05d@mail.gmail.com> From: Tomasz Zieleniewski To: BONNAERENS Ben Content-Type: multipart/alternative; boundary=001636c5bb7157420d0470dba0e6 Cc: sip@ietf.org Subject: Re: [Sip] draft-ietf-sip-record-route-fix-08 Changes X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 11:01:38 -0000 --001636c5bb7157420d0470dba0e6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello Ben, Can we say in other words that proxy in such case should indicate used TLS transport by inserting the sips URI in the Record-Route header instead of using transport=tls parameter. Kind regards, - Tomasz Zieleniewski 2009/8/7 BONNAERENS Ben > Hello John, > > > Well, I know what this means, but will your average reader > > understand it? I think we are trying to say something along > > the lines that if the transport protocol changes you SHOULD > > use the double Record-Route technique, where the differences > > in transport protocol are reflected in different values of > > the transport parameter (udp/tcp/sctp) and/or different > > values of the URI scheme (sip/sips). Correct? > > Your phrasing could lead to the understanding that we suggest that > only a sips URI can be used to identify the TLS interface which is not > correct. > As the current text suggests, can the TLS interface be identified by any > URI > (sip or sips ; excluding the deprecated transport=tls parameter) that > resolves via RFC3263 procedures to the TLS transport. > > IMHO leaves your suggested phrasing more room for ambiguity > compared to the current text. > > Best regards & thanks, > > Ben. > > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Sent: donderdag 6 augustus 2009 9:37 > > To: BONNAERENS Ben; sip@ietf.org > > Subject: RE: [Sip] draft-ietf-sip-record-route-fix-08 Changes > > > > Well, I know what this means, but will your average reader > > understand it? I think we are trying to say something along > > the lines that if the transport protocol changes you SHOULD > > use the double Record-Route technique, where the differences > > in transport protocol are reflected in different values of > > the transport parameter (udp/tcp/sctp) and/or different > > values of the URI scheme (sip/sips). Correct? > > > > John > > > > > -----Original Message----- > > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > > Behalf Of > > > BONNAERENS Ben > > > Sent: 05 August 2009 15:23 > > > To: sip@ietf.org > > > Subject: [Sip] draft-ietf-sip-record-route-fix-08 Changes > > > > > > Hi, > > > version -08 of record-route fix has just been submitted. > > > > > > Change log: > > > - Changed its status from BCP to PS, > > > - Take into account IESG reviews and subsequent comments on the > > > mailing lists, they were summarized in Robert Sparks's document > > > (rrf.txt), so it has been integrated in version -08 with minor > > > refactoring from the authors (me and Ben). > > > > > > The thoughest part was related to the SIP/SIPS question raised by > > > Cullen > > (http://datatracker.ietf.org/idtracker/draft-ietf-sip-record-r > > > oute-fix/c > > > omment/98624/), > > > so here is the text that was added in version -08 to answer this > > > question: > > > "Thus, if the transport protocol changed between its > > > incoming and outgoing sides, the proxy SHOULD use the double > > > Record-Route technique and SHOULD add a transport > > parameter to each > > > of the Record-Route URIs it inserts. With the exception > > that if TLS > > > is > > > used as the transport protocol on either side of the > > proxy, the URI > > > chosen to place in the Record-Route header field value > > reflecting > > > the > > > interface using TLS will need to leverage the [RFC3263] > > mechanisms > > > to > > > indicate that TLS must be used rather attempting to use the > > > deprecated > > > "transport=tls" URI parameter. See [RFC3261] Section 26.2.2 and > > > [I-D.ietf-sip-sips] Section 3.1.4 for more discussion." > > > > > > Brds, > > > Thomas & Ben > > > _______________________________________________ > > > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP 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://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > --001636c5bb7157420d0470dba0e6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello Ben,

Can we say in other words that proxy in such case should =
indicate used TLS transport by inserting the sips URI in the
Record= -Route header instead of using transport=3Dtls parameter.

Kind regar= ds,
- Tomasz Zieleniewski

2009/8/7 BONNAERENS= Ben <ben.bonnaerens@alcatel-lucent.be>
Hello John,

> Well, I know what this means, but will your average reader
> understand it? I think we are trying to say something along
> the lines that if the transport protocol changes you SHOULD
> use the double Record-Route technique, where the differences
> in transport protocol are reflected in different values of
> the transport parameter (udp/tcp/sctp) and/or different
> values of the URI scheme (sip/sips). Correct?

Your phrasing could lead to the understanding that we suggest that only a sips URI can be used to identify the TLS interface which is not
correct.
As the current text suggests, can the TLS interface be identified by any URI
(sip or sips ; excluding the deprecated transport=3Dtls parameter) that
resolves via RFC3263 procedures to the TLS transport.

IMHO leaves your suggested phrasing more room for ambiguity
compared to the current text.

Best regards & thanks,

Ben.

> -----Original Message-----
> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]
> Sent: donderdag 6 augustus 2009 9:37
> To: BONNAERENS Ben; sip@ietf.org > Subject: RE: [Sip] draft-ietf-sip-record-route-fix-08 Changes
>
> Well, I know what this means, but will your average reader
> understand it? I think we are trying to say something along
> the lines that if the transport protocol changes you SHOULD
> use the double Record-Route technique, where the differences
> in transport protocol are reflected in different values of
> the transport parameter (udp/tcp/sctp) and/or different
> values of the URI scheme (sip/sips). Correct?
>
> John
>
> > -----Original Message-----
> > From: sip-bounces@ietf.or= g [mailto:sip-bounces@ietf.org<= /a>] On
> Behalf Of
> > BONNAERENS Ben
> > Sent: 05 August 2009 15:23
> > To: sip@ietf.org
> > Subject: [Sip] draft-ietf-sip-record-route-fix-08 Changes
> >
> > Hi,
> > version -08 of record-route fix has just been submitted.
> >
> > Change log:
> > - Changed its status from BCP to PS,
> > - Take into account IESG reviews and subsequent comments on the > > mailing lists, they were summarized in Robert Sparks's docume= nt
> > (rrf.txt), so it has been integrated in version -08 with minor > > refactoring from the authors (me and Ben).
> >
> > The thoughest part was related to the SIP/SIPS question raised by=
> > Cullen
> (http://datatracker.ietf.org/idtracker/draft-ietf-sip= -record-r
> > oute-fix/c
> > omment/98624/),
> > so here is the text that was added in version -08 to answer this<= br> > > question:
> > "Thus, if the transport protocol changed between its
> > =A0 =A0incoming and outgoing sides, the proxy SHOULD use the doub= le
> > =A0 =A0Record-Route technique and SHOULD add a transport
> parameter to each
> > =A0 =A0of the Record-Route URIs it inserts. With the exception > that if TLS
> > is
> > =A0 =A0used as the transport protocol on either side of the
> proxy, the URI
> > =A0 =A0chosen to place in the Record-Route header field value
> reflecting
> > the
> > =A0 =A0interface using TLS will need to leverage the [RFC3263] > mechanisms
> > to
> > =A0 =A0indicate that TLS must be used rather attempting to use th= e
> > deprecated
> > =A0 =A0"transport=3Dtls" URI parameter. See [RFC3261] S= ection 26.2.2 and
> > =A0 =A0[I-D.ietf-sip-sips] Section 3.1.4 for more discussion.&quo= t;
> >
> > Brds,
> > Thomas & Ben
> > _______________________________________________
> > Sip mailing list =A0https://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use
> > sip-implement= ors@cs.columbia.edu for questions on current sip Use
> > sipping@ietf.org for new = developments on the application of sip
> >
>
_______________________________________________
Sip mailing list =A0https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs= .columbia.edu for questions on current sip
Use sipping@ietf.org for new develo= pments on the application of sip

--001636c5bb7157420d0470dba0e6-- From ben.bonnaerens@alcatel-lucent.be Tue Aug 11 04:44:43 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FACC3A67CC for ; Tue, 11 Aug 2009 04:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.799 X-Spam-Level: X-Spam-Status: No, score=-5.799 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DmIwE5W3Cbic for ; Tue, 11 Aug 2009 04:44:42 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id B4E623A70AE for ; Tue, 11 Aug 2009 04:44:27 -0700 (PDT) Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.dc-m.alcatel-lucent.com [155.132.6.76]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n7BBhlxU020171; Tue, 11 Aug 2009 13:43:51 +0200 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.51]) by FRVELSBHS04.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Aug 2009 13:43:48 +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: Tue, 11 Aug 2009 13:43:47 +0200 Message-ID: <8144761F31F48D43AD53D09F5350E38004C6042C@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0023D22FA@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-ietf-sip-record-route-fix-08 Changes Thread-Index: AcoV2D3o9zuX5uy0THC/DMS48GQffwAj7G0wAD7JfZAAvwlgsAAFs+Yg References: <8144761F31F48D43AD53D09F5350E38004C00CE5@FRVELSMBS22.ad2.ad.alcatel.com>A<0D5F89FAC29E2C41B98A6A762007F5D002393EA0@GBNTHT12009MSX.gb002.siemens.net><8144761F31F48D43AD53D09F5350E38004C01534@FRVELSMBS22.ad2.ad.alcatel.com> <0D5F89FAC29E2C41B98A6A762007F5D0023D22FA@GBNTHT12009MSX.gb002.siemens.net> From: "BONNAERENS Ben" To: "Elwell, John" X-OriginalArrivalTime: 11 Aug 2009 11:43:48.0547 (UTC) FILETIME=[FD88A930:01CA1A78] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Cc: sip@ietf.org Subject: Re: [Sip] draft-ietf-sip-record-route-fix-08 Changes X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 11:44:43 -0000 Hello John, What we are trying to say is that the URI, identifying the TLS interface, placed=20 in the Record-Route header must, after executing the RFC3263 DNS procedureson it,=20 result in the TLS transport being selected. This can be a sips URI or a sip URI (so called "best effort TLS" in [I-D.ietf-sip-sips] chapter 3.1.3)=20 but we suggest to not use the deprecated "transport=3Dtls" parameter. Best regards &Thanks, Ben=20 RFC3263 Chapter 4.1 " First, a client resolving a SIPS URI MUST discard any services that do not contain "SIPS" as the protocol in the service field. The converse is not true, however. A client resolving a SIP URI SHOULD retain records with "SIPS" as the protocol, if the client supports TLS." =20 > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20 > Behalf Of Elwell, John > Sent: dinsdag 11 augustus 2009 10:44 > To: BONNAERENS Ben; sip@ietf.org > Subject: Re: [Sip] draft-ietf-sip-record-route-fix-08 Changes >=20 > In that case, I obviously misunderstood the text in the current draft. > What exactly is the meaning of "will need to leverage the=20 > [RFC3263] mechanisms"? >=20 > John >=20 > > -----Original Message----- > > From: BONNAERENS Ben [mailto:ben.bonnaerens@alcatel-lucent.be] > > Sent: 07 August 2009 14:57 > > To: Elwell, John; sip@ietf.org > > Subject: RE: [Sip] draft-ietf-sip-record-route-fix-08 Changes > >=20 > > Hello John, > >=20 > > > Well, I know what this means, but will your average reader=20 > > > understand it? I think we are trying to say something along the=20 > > > lines that if the transport protocol changes you SHOULD use the=20 > > > double Record-Route technique, where the differences in transport=20 > > > protocol are reflected in different values of the transport=20 > > > parameter (udp/tcp/sctp) and/or different values of the=20 > URI scheme=20 > > > (sip/sips). Correct? > >=20 > > Your phrasing could lead to the understanding that we suggest that=20 > > only a sips URI can be used to identify the TLS interface=20 > which is not=20 > > correct. > > As the current text suggests, can the TLS interface be=20 > identified by=20 > > any URI (sip or sips ; excluding the deprecated transport=3Dtls=20 > > parameter) that resolves via RFC3263 procedures to the TLS=20 > transport. > >=20 > > IMHO leaves your suggested phrasing more room for ambiguity=20 > compared=20 > > to the current text. > >=20 > > Best regards & thanks, > >=20 > > Ben. =20 > >=20 > > > -----Original Message----- > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > Sent: donderdag 6 augustus 2009 9:37 > > > To: BONNAERENS Ben; sip@ietf.org > > > Subject: RE: [Sip] draft-ietf-sip-record-route-fix-08 Changes > > >=20 > > > Well, I know what this means, but will your average reader=20 > > > understand it? I think we are trying to say something along the=20 > > > lines that if the transport protocol changes you SHOULD use the=20 > > > double Record-Route technique, where the differences in transport=20 > > > protocol are reflected in different values of the transport=20 > > > parameter (udp/tcp/sctp) and/or different values of the=20 > URI scheme=20 > > > (sip/sips). Correct? > > >=20 > > > John > > >=20 > > > > -----Original Message----- > > > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > > > Behalf Of > > > > BONNAERENS Ben > > > > Sent: 05 August 2009 15:23 > > > > To: sip@ietf.org > > > > Subject: [Sip] draft-ietf-sip-record-route-fix-08 Changes > > > >=20 > > > > Hi, > > > > version -08 of record-route fix has just been submitted. > > > >=20 > > > > Change log: > > > > - Changed its status from BCP to PS, > > > > - Take into account IESG reviews and subsequent comments on the=20 > > > > mailing lists, they were summarized in Robert Sparks's document=20 > > > > (rrf.txt), so it has been integrated in version -08 with minor=20 > > > > refactoring from the authors (me and Ben). > > > >=20 > > > > The thoughest part was related to the SIP/SIPS question=20 > raised by=20 > > > > Cullen > > > (http://datatracker.ietf.org/idtracker/draft-ietf-sip-record-r > > > > oute-fix/c > > > > omment/98624/), > > > > so here is the text that was added in version -08 to answer this > > > > question: > > > > "Thus, if the transport protocol changed between its > > > > incoming and outgoing sides, the proxy SHOULD use the double > > > > Record-Route technique and SHOULD add a transport > > > parameter to each > > > > of the Record-Route URIs it inserts. With the exception > > > that if TLS > > > > is > > > > used as the transport protocol on either side of the > > > proxy, the URI > > > > chosen to place in the Record-Route header field value > > > reflecting > > > > the > > > > interface using TLS will need to leverage the [RFC3263] > > > mechanisms > > > > to > > > > indicate that TLS must be used rather attempting to use the=20 > > > > deprecated > > > > "transport=3Dtls" URI parameter. See [RFC3261] Section=20 > 26.2.2 and > > > > [I-D.ietf-sip-sips] Section 3.1.4 for more discussion." > > > >=20 > > > > Brds, > > > > Thomas & Ben > > > > _______________________________________________ > > > > Sip mailing list https://www.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=20 > current sip Use=20 > > > > sipping@ietf.org for new developments on the application of sip > > > >=20 > > >=20 > >=20 > _______________________________________________ > Sip mailing list https://www.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 From ben.bonnaerens@alcatel-lucent.be Tue Aug 11 05:11:36 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C46503A67ED for ; Tue, 11 Aug 2009 05:11:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.749 X-Spam-Level: X-Spam-Status: No, score=-5.749 tagged_above=-999 required=5 tests=[AWL=-0.101, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 51C2MsIF3Ywa for ; Tue, 11 Aug 2009 05:11:35 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id BBB6E3A67CC for ; Tue, 11 Aug 2009 05:11:34 -0700 (PDT) Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.dc-m.alcatel-lucent.com [155.132.6.77]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n7BBscI6026954; Tue, 11 Aug 2009 13:55:06 +0200 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.51]) by FRVELSBHS05.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Aug 2009 13:54:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA1A7A.8BD8D78B" Date: Tue, 11 Aug 2009 13:54:56 +0200 Message-ID: <8144761F31F48D43AD53D09F5350E38004C6043D@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <5fd52d7a0908110401lc151128v891ec1289927a05d@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-ietf-sip-record-route-fix-08 Changes Thread-Index: Acoacx76kQSzwVeeSDmbQJb3g3up8QABgHKw References: <8144761F31F48D43AD53D09F5350E38004C00CE5@FRVELSMBS22.ad2.ad.alcatel.com> <0D5F89FAC29E2C41B98A6A762007F5D002393EA0@GBNTHT12009MSX.gb002.siemens.net> <8144761F31F48D43AD53D09F5350E38004C01534@FRVELSMBS22.ad2.ad.alcatel.com> <5fd52d7a0908110401lc151128v891ec1289927a05d@mail.gmail.com> From: "BONNAERENS Ben" To: "Tomasz Zieleniewski" X-OriginalArrivalTime: 11 Aug 2009 11:54:57.0741 (UTC) FILETIME=[8C678FD0:01CA1A7A] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Cc: sip@ietf.org Subject: Re: [Sip] draft-ietf-sip-record-route-fix-08 Changes X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 12:11:36 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA1A7A.8BD8D78B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Tomasz, =20 It can be a sips URI but it is not restricted to sips. =20 For example a SIP URI resolving to the TLS transport after executing the RFC3263 procedures on it is possible. =20 Best regards & thanks, Ben. =20 RFC3263 Chapter 4.1 " First, a client resolving a SIPS URI MUST discard any services that do not contain "SIPS" as the protocol in the service field. The converse is not true, however. A client resolving a SIP URI SHOULD retain records with "SIPS" as the protocol, if the client supports TLS." =20 =20 [I-D.ietf-sip-sips] Section 3.1.3 ~ "best effort TLS" =20 =20 ________________________________ From: Tomasz Zieleniewski [mailto:tzieleniewski@gmail.com]=20 Sent: dinsdag 11 augustus 2009 13:02 To: BONNAERENS Ben Cc: Elwell, John; sip@ietf.org Subject: Re: [Sip] draft-ietf-sip-record-route-fix-08 Changes =09 =09 Hello Ben, =09 Can we say in other words that proxy in such case should=20 indicate used TLS transport by inserting the sips URI in the=20 Record-Route header instead of using transport=3Dtls parameter. =09 Kind regards, - Tomasz Zieleniewski =09 =09 2009/8/7 BONNAERENS Ben =09 Hello John, =09 > Well, I know what this means, but will your average reader > understand it? I think we are trying to say something along > the lines that if the transport protocol changes you SHOULD > use the double Record-Route technique, where the differences > in transport protocol are reflected in different values of > the transport parameter (udp/tcp/sctp) and/or different > values of the URI scheme (sip/sips). Correct? =09 =09 Your phrasing could lead to the understanding that we suggest that only a sips URI can be used to identify the TLS interface which is not correct. As the current text suggests, can the TLS interface be identified by any URI (sip or sips ; excluding the deprecated transport=3Dtls parameter) that resolves via RFC3263 procedures to the TLS transport. =09 IMHO leaves your suggested phrasing more room for ambiguity compared to the current text. =09 Best regards & thanks, =09 Ben. =09 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: donderdag 6 augustus 2009 9:37 > To: BONNAERENS Ben; sip@ietf.org > Subject: RE: [Sip] draft-ietf-sip-record-route-fix-08 Changes > > Well, I know what this means, but will your average reader > understand it? I think we are trying to say something along > the lines that if the transport protocol changes you SHOULD > use the double Record-Route technique, where the differences > in transport protocol are reflected in different values of > the transport parameter (udp/tcp/sctp) and/or different > values of the URI scheme (sip/sips). Correct? > > John > > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of > > BONNAERENS Ben > > Sent: 05 August 2009 15:23 > > To: sip@ietf.org > > Subject: [Sip] draft-ietf-sip-record-route-fix-08 Changes > > > > Hi, > > version -08 of record-route fix has just been submitted. > > > > Change log: > > - Changed its status from BCP to PS, > > - Take into account IESG reviews and subsequent comments on the > > mailing lists, they were summarized in Robert Sparks's document > > (rrf.txt), so it has been integrated in version -08 with minor > > refactoring from the authors (me and Ben). > > > > The thoughest part was related to the SIP/SIPS question raised by > > Cullen > (http://datatracker.ietf.org/idtracker/draft-ietf-sip-record-r > > oute-fix/c > > omment/98624/), > > so here is the text that was added in version -08 to answer this > > question: > > "Thus, if the transport protocol changed between its > > incoming and outgoing sides, the proxy SHOULD use the double > > Record-Route technique and SHOULD add a transport > parameter to each > > of the Record-Route URIs it inserts. With the exception > that if TLS > > is > > used as the transport protocol on either side of the > proxy, the URI > > chosen to place in the Record-Route header field value > reflecting > > the > > interface using TLS will need to leverage the [RFC3263] > mechanisms > > to > > indicate that TLS must be used rather attempting to use the > > deprecated > > "transport=3Dtls" URI parameter. See [RFC3261] Section 26.2.2 and > > [I-D.ietf-sip-sips] Section 3.1.4 for more discussion." > > > > Brds, > > Thomas & Ben > > _______________________________________________ > > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP 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://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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_01CA1A7A.8BD8D78B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hello Tomasz,
 
It can=20 be a sips URI but it is not restricted to sips.
 
For=20 example a SIP URI resolving to the TLS transport after executing=20 the
RFC3263 procedures on it is possible.
 
Best=20 regards & thanks,
Ben.
 
RFC3263 Chapter 4.1
"   First, a client resolving = a SIPS URI=20 MUST discard any services that
   do not contain "SIPS" as = the=20 protocol in the service field.  The
   converse is not = true,=20 however.  A client resolving a SIP URI SHOULD
   = retain=20 records with "SIPS" as the protocol, if the client = supports
  =20 TLS." 
 
[I-D.ietf-sip-sips] Section 3.1.3 ~ "best effort = TLS"
 
 

From: Tomasz Zieleniewski=20 [mailto:tzieleniewski@gmail.com]
Sent: dinsdag 11 augustus = 2009=20 13:02
To: BONNAERENS Ben
Cc: Elwell, John;=20 sip@ietf.org
Subject: Re: [Sip] = draft-ietf-sip-record-route-fix-08=20 Changes

Hello Ben,

Can we say in other words that proxy in = such case=20 should
indicate used TLS transport by inserting the sips URI in = the=20
Record-Route header instead of using transport=3Dtls = parameter.

Kind=20 regards,
- Tomasz Zieleniewski

2009/8/7 BONNAERENS Ben <ben.bonnaerens@alcatel-l= ucent.be>
Hello=20 John,

> Well, I know what this means, but will your = average=20 reader
> understand it? I think we are trying to say something = along
> the lines that if the transport protocol changes you=20 SHOULD
> use the double Record-Route technique, where the=20 differences
> in transport protocol are reflected in different = values=20 of
> the transport parameter (udp/tcp/sctp) and/or = different
>=20 values of the URI scheme (sip/sips). Correct?

Your = phrasing=20 could lead to the understanding that we suggest that
only a sips = URI can=20 be used to identify the TLS interface which is not
correct.
As = the=20 current text suggests, can the TLS interface be identified by=20 any
URI
(sip or sips ; excluding the deprecated = transport=3Dtls=20 parameter) that
resolves via RFC3263 procedures to the TLS=20 transport.

IMHO leaves your suggested phrasing more room for=20 ambiguity
compared to the current text.

Best regards & = thanks,

Ben.

> -----Original Message-----
> From: = Elwell, John=20 [mailto:john.elwell@siemens-en= terprise.com]
>=20 Sent: donderdag 6 augustus 2009 9:37
> To: BONNAERENS Ben; sip@ietf.org
> Subject: RE: = [Sip]=20 draft-ietf-sip-record-route-fix-08 Changes
>
> Well, I = know what=20 this means, but will your average reader
> understand it? I = think we=20 are trying to say something along
> the lines that if the = transport=20 protocol changes you SHOULD
> use the double Record-Route = technique,=20 where the differences
> in transport protocol are reflected in = different values of
> the transport parameter (udp/tcp/sctp) = and/or=20 different
> values of the URI scheme (sip/sips).=20 Correct?
>
> John
>
> > -----Original=20 Message-----
> > From: sip-bounces@ietf.org = [mailto:sip-bounces@ietf.org] = On
>=20 Behalf Of
> > BONNAERENS Ben
> > Sent: 05 August = 2009=20 15:23
> > To: sip@ietf.org
> > Subject: = [Sip]=20 draft-ietf-sip-record-route-fix-08 Changes
> >
> > = Hi,
> > version -08 of record-route fix has just been=20 submitted.
> >
> > Change log:
> > - = Changed its=20 status from BCP to PS,
> > - Take into account IESG reviews = and=20 subsequent comments on the
> > mailing lists, they were = summarized=20 in Robert Sparks's document
> > (rrf.txt), so it has been=20 integrated in version -08 with minor
> > refactoring from = the=20 authors (me and Ben).
> >
> > The thoughest part = was=20 related to the SIP/SIPS question raised by
> > = Cullen
> (http://datatracker.ietf.org/idtracker/draft-ietf-sip-reco= rd-r
>=20 > oute-fix/c
> > omment/98624/),
> > so here is = the=20 text that was added in version -08 to answer this
> >=20 question:
> > "Thus, if the transport protocol changed = between=20 its
> >    incoming and outgoing sides, the proxy = SHOULD=20 use the double
> >    Record-Route technique and = SHOULD=20 add a transport
> parameter to each
> >   =  of the=20 Record-Route URIs it inserts. With the exception
> that if = TLS
>=20 > is
> >    used as the transport protocol on = either=20 side of the
> proxy, the URI
> >    chosen = to place=20 in the Record-Route header field value
> reflecting
> = >=20 the
> >    interface using TLS will need to = leverage the=20 [RFC3263]
> mechanisms
> > to
> >  =20  indicate that TLS must be used rather attempting to use = the
>=20 > deprecated
> >    "transport=3Dtls" URI = parameter. See=20 [RFC3261] Section 26.2.2 and
> >   =  [I-D.ietf-sip-sips]=20 Section 3.1.4 for more discussion."
> >
> > = Brds,
>=20 > Thomas & Ben
> >=20 _______________________________________________
> > Sip = mailing=20 list  https://www.ietf.org/mailman/listinfo/sip
> = >=20 This list is for NEW development of the core SIP Protocol = Use
> >=20 sip-implementors@cs.colu= mbia.edu=20 for questions on current sip Use
> > sipping@ietf.org for new = developments on=20 the application of sip
>=20 = >
>
_______________________________________________
Sip=20 mailing list  https://www.ietf.org/mailman/listinfo/sip
This = list is=20 for NEW development of the core SIP Protocol
Use sip-implementors@cs.colu= mbia.edu=20 for questions on current sip
Use sipping@ietf.org for new = developments on=20 the application of=20 sip

------_=_NextPart_001_01CA1A7A.8BD8D78B-- From john.elwell@siemens-enterprise.com Tue Aug 11 05:25:23 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF3D13A7107 for ; Tue, 11 Aug 2009 05:25:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.147 X-Spam-Level: X-Spam-Status: No, score=-2.147 tagged_above=-999 required=5 tests=[AWL=-0.148, BAYES_00=-2.599, J_CHICKENPOX_93=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1zTpQFSYGp5U for ; Tue, 11 Aug 2009 05:25:22 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 8FB3C3A7104 for ; Tue, 11 Aug 2009 05:25:22 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KO700J7EOZON5@siemenscomms.co.uk> for sip@ietf.org; Tue, 11 Aug 2009 13:21:24 +0100 (BST) Date: Tue, 11 Aug 2009 13:21:10 +0100 From: "Elwell, John" In-reply-to: <8144761F31F48D43AD53D09F5350E38004C6042C@FRVELSMBS22.ad2.ad.alcatel.com> To: BONNAERENS Ben Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0023D2478@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: quoted-printable Thread-Topic: [Sip] draft-ietf-sip-record-route-fix-08 Changes Thread-Index: AcoV2D3o9zuX5uy0THC/DMS48GQffwAj7G0wAD7JfZAAvwlgsAAFs+YgAAHN4PA= Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <8144761F31F48D43AD53D09F5350E38004C00CE5@FRVELSMBS22.ad2.ad.alcatel.com> A <0D5F89FAC29E2C41B98A6A762007F5D002393EA0@GBNTHT12009MSX.gb002.siemens.net> <8144761F31F48D43AD53D09F5350E38004C01534@FRVELSMBS22.ad2.ad.alcatel.com> <0D5F89FAC29E2C41B98A6A762007F5D0023D22FA@GBNTHT12009MSX.gb002.siemens.net> <8144761F31F48D43AD53D09F5350E38004C6042C@FRVELSMBS22.ad2.ad.alcatel.com> Cc: sip@ietf.org Subject: Re: [Sip] draft-ietf-sip-record-route-fix-08 Changes X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 12:25:24 -0000 =20 > -----Original Message----- > From: BONNAERENS Ben [mailto:ben.bonnaerens@alcatel-lucent.be]=20 > Sent: 11 August 2009 12:44 > To: Elwell, John > Cc: sip@ietf.org; Thomas Froment > Subject: RE: [Sip] draft-ietf-sip-record-route-fix-08 Changes >=20 > Hello John, >=20 > What we are trying to say is that the URI, identifying the TLS > interface, placed=20 > in the Record-Route header must, after executing the RFC3263 DNS > procedureson it,=20 > result in the TLS transport being selected. >=20 > This can be a sips URI or a sip URI (so called "best effort TLS" in > [I-D.ietf-sip-sips] chapter 3.1.3)=20 > but we suggest to not use the deprecated "transport=3Dtls" parameter. [JRE] So if you want to ensure TLS, either you use a sips URI or you populate your DNS records such that a sip URI always resolves to TLS transport - correct? If so, I think the average reader would have a hard time deducing this from the present text. John >=20 > Best regards &Thanks, >=20 > Ben=20 >=20 > RFC3263 Chapter 4.1 > " First, a client resolving a SIPS URI MUST discard any=20 > services that > do not contain "SIPS" as the protocol in the service field. The > converse is not true, however. A client resolving a SIP URI SHOULD > retain records with "SIPS" as the protocol, if the client supports > TLS." =20 >=20 > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20 > > Behalf Of Elwell, John > > Sent: dinsdag 11 augustus 2009 10:44 > > To: BONNAERENS Ben; sip@ietf.org > > Subject: Re: [Sip] draft-ietf-sip-record-route-fix-08 Changes > >=20 > > In that case, I obviously misunderstood the text in the=20 > current draft. > > What exactly is the meaning of "will need to leverage the=20 > > [RFC3263] mechanisms"? > >=20 > > John > >=20 > > > -----Original Message----- > > > From: BONNAERENS Ben [mailto:ben.bonnaerens@alcatel-lucent.be] > > > Sent: 07 August 2009 14:57 > > > To: Elwell, John; sip@ietf.org > > > Subject: RE: [Sip] draft-ietf-sip-record-route-fix-08 Changes > > >=20 > > > Hello John, > > >=20 > > > > Well, I know what this means, but will your average reader=20 > > > > understand it? I think we are trying to say something along the=20 > > > > lines that if the transport protocol changes you SHOULD use the=20 > > > > double Record-Route technique, where the differences in=20 > transport=20 > > > > protocol are reflected in different values of the transport=20 > > > > parameter (udp/tcp/sctp) and/or different values of the=20 > > URI scheme=20 > > > > (sip/sips). Correct? > > >=20 > > > Your phrasing could lead to the understanding that we=20 > suggest that=20 > > > only a sips URI can be used to identify the TLS interface=20 > > which is not=20 > > > correct. > > > As the current text suggests, can the TLS interface be=20 > > identified by=20 > > > any URI (sip or sips ; excluding the deprecated transport=3Dtls=20 > > > parameter) that resolves via RFC3263 procedures to the TLS=20 > > transport. > > >=20 > > > IMHO leaves your suggested phrasing more room for ambiguity=20 > > compared=20 > > > to the current text. > > >=20 > > > Best regards & thanks, > > >=20 > > > Ben. =20 > > >=20 > > > > -----Original Message----- > > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > > Sent: donderdag 6 augustus 2009 9:37 > > > > To: BONNAERENS Ben; sip@ietf.org > > > > Subject: RE: [Sip] draft-ietf-sip-record-route-fix-08 Changes > > > >=20 > > > > Well, I know what this means, but will your average reader=20 > > > > understand it? I think we are trying to say something along the=20 > > > > lines that if the transport protocol changes you SHOULD use the=20 > > > > double Record-Route technique, where the differences in=20 > transport=20 > > > > protocol are reflected in different values of the transport=20 > > > > parameter (udp/tcp/sctp) and/or different values of the=20 > > URI scheme=20 > > > > (sip/sips). Correct? > > > >=20 > > > > John > > > >=20 > > > > > -----Original Message----- > > > > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > > > > Behalf Of > > > > > BONNAERENS Ben > > > > > Sent: 05 August 2009 15:23 > > > > > To: sip@ietf.org > > > > > Subject: [Sip] draft-ietf-sip-record-route-fix-08 Changes > > > > >=20 > > > > > Hi, > > > > > version -08 of record-route fix has just been submitted. > > > > >=20 > > > > > Change log: > > > > > - Changed its status from BCP to PS, > > > > > - Take into account IESG reviews and subsequent=20 > comments on the=20 > > > > > mailing lists, they were summarized in Robert=20 > Sparks's document=20 > > > > > (rrf.txt), so it has been integrated in version -08=20 > with minor=20 > > > > > refactoring from the authors (me and Ben). > > > > >=20 > > > > > The thoughest part was related to the SIP/SIPS question=20 > > raised by=20 > > > > > Cullen > > > > (http://datatracker.ietf.org/idtracker/draft-ietf-sip-record-r > > > > > oute-fix/c > > > > > omment/98624/), > > > > > so here is the text that was added in version -08 to=20 > answer this > > > > > question: > > > > > "Thus, if the transport protocol changed between its > > > > > incoming and outgoing sides, the proxy SHOULD use=20 > the double > > > > > Record-Route technique and SHOULD add a transport > > > > parameter to each > > > > > of the Record-Route URIs it inserts. With the exception > > > > that if TLS > > > > > is > > > > > used as the transport protocol on either side of the > > > > proxy, the URI > > > > > chosen to place in the Record-Route header field value > > > > reflecting > > > > > the > > > > > interface using TLS will need to leverage the [RFC3263] > > > > mechanisms > > > > > to > > > > > indicate that TLS must be used rather attempting=20 > to use the=20 > > > > > deprecated > > > > > "transport=3Dtls" URI parameter. See [RFC3261] Section=20 > > 26.2.2 and > > > > > [I-D.ietf-sip-sips] Section 3.1.4 for more discussion." > > > > >=20 > > > > > Brds, > > > > > Thomas & Ben > > > > > _______________________________________________ > > > > > Sip mailing list https://www.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=20 > > current sip Use=20 > > > > > sipping@ietf.org for new developments on the=20 > application of sip > > > > >=20 > > > >=20 > > >=20 > > _______________________________________________ > > Sip mailing list https://www.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 >=20 From brett@broadsoft.com Tue Aug 11 08:12:21 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED0CB3A67CC for ; Tue, 11 Aug 2009 08:12:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pE5WUalNeUwW for ; Tue, 11 Aug 2009 08:12:21 -0700 (PDT) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id 12D5D3A6B46 for ; Tue, 11 Aug 2009 08:12:20 -0700 (PDT) Received: from mbx02.citservers.local ([172.16.98.24]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Tue, 11 Aug 2009 08:11:30 -0700 From: Brett Tate To: "stlevy@cisco.com" , "sip@ietf.org" Date: Tue, 11 Aug 2009 08:11:30 -0700 Thread-Topic: draft-levy-sip-diversion-10: examples containing uselessly quoted values Thread-Index: AcoalgEj9ACDyt4MRKOBNz47nMF2Ew== Message-ID: <9B2A061A1137254BBE4F4B2CD843646A134C0D0C08@mbx02.citservers.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {1D4AF4E3-8D94-44E7-B555-C8713CCA1902} x-cr-hashedpuzzle: Dirk D/k/ FETI HTu7 Jw7Y K60B NyRT N0L9 Ojxd O/WI QA9H QrRT RDiK RL9t T8IF VenW; 2; cwBpAHAAQABpAGUAdABmAC4AbwByAGcAOwBzAHQAbABlAHYAeQBAAGMAaQBzAGMAbwAuAGMAbwBtAA==; Sosha1_v1; 7; {1D4AF4E3-8D94-44E7-B555-C8713CCA1902}; YgByAGUAdAB0AEAAYgByAG8AYQBkAHMAbwBmAHQALgBjAG8AbQA=; Tue, 11 Aug 2009 15:11:30 GMT; ZAByAGEAZgB0AC0AbABlAHYAeQAtAHMAaQBwAC0AZABpAHYAZQByAHMAaQBvAG4ALQAxADAAOgAgAGUAeABhAG0AcABsAGUAcwAgAGMAbwBuAHQAYQBpAG4AaQBuAGcAIAB1AHMAZQBsAGUAcwBzAGwAeQAgAHEAdQBvAHQAZQBkACAAdgBhAGwAdQBlAHMA acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Sip] draft-levy-sip-diversion-10: examples containing uselessly quoted values X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 15:12:22 -0000 Greetings, Concerning draft-levy-sip-diversion-10, several examples still contain quot= ed values which conflict with the need for quotes within the ABNF. This is= leading to frequent interop issues and ambiguity. Please remove the usele= ss quotes from the examples (my preference) or clearly indicate that a usel= essly quoted value is equivalent to the non quoted value. For example... diversion-screen ABNF shows quotes are not needed for yes an= d no. However examples (such as 10.3.5) include quotes for yes. Another example... diversion-privacy ABNF shows quotes are not needed for f= ull and off. However examples (such as 10.3.5) include quotes for full and= off. The 10.3.6 example contains open quote off without the close quote. Thanks, Brett From rjsparks@nostrum.com Tue Aug 11 18:35:04 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6BC33A6823 for ; Tue, 11 Aug 2009 18:35:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_93=0.6, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Gix1Q8bdw42 for ; Tue, 11 Aug 2009 18:35:03 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 47FEA3A6782 for ; Tue, 11 Aug 2009 18:35:02 -0700 (PDT) Received: from [192.168.2.2] (pool-173-71-46-184.dllstx.fios.verizon.net [173.71.46.184]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n7C1Z0cv043824 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 11 Aug 2009 20:35:00 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-Id: From: Robert Sparks To: "Elwell, John" In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0023D2478@GBNTHT12009MSX.gb002.siemens.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 11 Aug 2009 20:35:00 -0500 References: <8144761F31F48D43AD53D09F5350E38004C00CE5@FRVELSMBS22.ad2.ad.alcatel.com> A <0D5F89FAC29E2C41B98A6A762007F5D002393EA0@GBNTHT12009MSX.gb002.siemens.net> <8144761F31F48D43AD53D09F5350E38004C01534@FRVELSMBS22.ad2.ad.alcatel.com> <0D5F89FAC29E2C41B98A6A762007F5D0023D22FA@GBNTHT12009MSX.gb002.siemens.net> <8144761F31F48D43AD53D09F5350E38004C6042C@FRVELSMBS22.ad2.ad.alcatel.com> <0D5F89FAC29E2C41B98A6A762007F5D0023D2478@GBNTHT12009MSX.gb002.siemens.net> X-Mailer: Apple Mail (2.936) Received-SPF: pass (nostrum.com: 173.71.46.184 is authenticated by a trusted mechanism) Cc: sip@ietf.org, BONNAERENS Ben Subject: Re: [Sip] draft-ietf-sip-record-route-fix-08 Changes X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 01:35:05 -0000 John - Would this substitution address your concern? When TLS is used on the transport on either side of the proxy the URI chosen to place in the Record-Route header field value reflecting the interface using TLS will need to use a sips: URI or ensure that a sip: URI resolves (per the procedures of [RFC3263]) to using TLS rather than attempting to use the deprecated "transport=tls" URI parameter. See [RFC3261] Section 26.2.2 and [I-D.ietf-sip-sips] Section 3.1.4 for more discussion RjS On Aug 11, 2009, at 7:21 AM, Elwell, John wrote: > > >> -----Original Message----- >> From: BONNAERENS Ben [mailto:ben.bonnaerens@alcatel-lucent.be] >> Sent: 11 August 2009 12:44 >> To: Elwell, John >> Cc: sip@ietf.org; Thomas Froment >> Subject: RE: [Sip] draft-ietf-sip-record-route-fix-08 Changes >> >> Hello John, >> >> What we are trying to say is that the URI, identifying the TLS >> interface, placed >> in the Record-Route header must, after executing the RFC3263 DNS >> procedureson it, >> result in the TLS transport being selected. >> >> This can be a sips URI or a sip URI (so called "best effort TLS" in >> [I-D.ietf-sip-sips] chapter 3.1.3) >> but we suggest to not use the deprecated "transport=tls" parameter. > [JRE] So if you want to ensure TLS, either you use a sips URI or you > populate your DNS records such that a sip URI always resolves to TLS > transport - correct? > If so, I think the average reader would have a hard time deducing this > from the present text. > > John > >> >> Best regards &Thanks, >> >> Ben >> >> RFC3263 Chapter 4.1 >> " First, a client resolving a SIPS URI MUST discard any >> services that >> do not contain "SIPS" as the protocol in the service field. The >> converse is not true, however. A client resolving a SIP URI SHOULD >> retain records with "SIPS" as the protocol, if the client supports >> TLS." >> >>> -----Original Message----- >>> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On >>> Behalf Of Elwell, John >>> Sent: dinsdag 11 augustus 2009 10:44 >>> To: BONNAERENS Ben; sip@ietf.org >>> Subject: Re: [Sip] draft-ietf-sip-record-route-fix-08 Changes >>> >>> In that case, I obviously misunderstood the text in the >> current draft. >>> What exactly is the meaning of "will need to leverage the >>> [RFC3263] mechanisms"? >>> >>> John >>> >>>> -----Original Message----- >>>> From: BONNAERENS Ben [mailto:ben.bonnaerens@alcatel-lucent.be] >>>> Sent: 07 August 2009 14:57 >>>> To: Elwell, John; sip@ietf.org >>>> Subject: RE: [Sip] draft-ietf-sip-record-route-fix-08 Changes >>>> >>>> Hello John, >>>> >>>>> Well, I know what this means, but will your average reader >>>>> understand it? I think we are trying to say something along the >>>>> lines that if the transport protocol changes you SHOULD use the >>>>> double Record-Route technique, where the differences in >> transport >>>>> protocol are reflected in different values of the transport >>>>> parameter (udp/tcp/sctp) and/or different values of the >>> URI scheme >>>>> (sip/sips). Correct? >>>> >>>> Your phrasing could lead to the understanding that we >> suggest that >>>> only a sips URI can be used to identify the TLS interface >>> which is not >>>> correct. >>>> As the current text suggests, can the TLS interface be >>> identified by >>>> any URI (sip or sips ; excluding the deprecated transport=tls >>>> parameter) that resolves via RFC3263 procedures to the TLS >>> transport. >>>> >>>> IMHO leaves your suggested phrasing more room for ambiguity >>> compared >>>> to the current text. >>>> >>>> Best regards & thanks, >>>> >>>> Ben. >>>> >>>>> -----Original Message----- >>>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >>>>> Sent: donderdag 6 augustus 2009 9:37 >>>>> To: BONNAERENS Ben; sip@ietf.org >>>>> Subject: RE: [Sip] draft-ietf-sip-record-route-fix-08 Changes >>>>> >>>>> Well, I know what this means, but will your average reader >>>>> understand it? I think we are trying to say something along the >>>>> lines that if the transport protocol changes you SHOULD use the >>>>> double Record-Route technique, where the differences in >> transport >>>>> protocol are reflected in different values of the transport >>>>> parameter (udp/tcp/sctp) and/or different values of the >>> URI scheme >>>>> (sip/sips). Correct? >>>>> >>>>> John >>>>> >>>>>> -----Original Message----- >>>>>> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On >>>>> Behalf Of >>>>>> BONNAERENS Ben >>>>>> Sent: 05 August 2009 15:23 >>>>>> To: sip@ietf.org >>>>>> Subject: [Sip] draft-ietf-sip-record-route-fix-08 Changes >>>>>> >>>>>> Hi, >>>>>> version -08 of record-route fix has just been submitted. >>>>>> >>>>>> Change log: >>>>>> - Changed its status from BCP to PS, >>>>>> - Take into account IESG reviews and subsequent >> comments on the >>>>>> mailing lists, they were summarized in Robert >> Sparks's document >>>>>> (rrf.txt), so it has been integrated in version -08 >> with minor >>>>>> refactoring from the authors (me and Ben). >>>>>> >>>>>> The thoughest part was related to the SIP/SIPS question >>> raised by >>>>>> Cullen >>>>> (http://datatracker.ietf.org/idtracker/draft-ietf-sip-record-r >>>>>> oute-fix/c >>>>>> omment/98624/), >>>>>> so here is the text that was added in version -08 to >> answer this >>>>>> question: >>>>>> "Thus, if the transport protocol changed between its >>>>>> incoming and outgoing sides, the proxy SHOULD use >> the double >>>>>> Record-Route technique and SHOULD add a transport >>>>> parameter to each >>>>>> of the Record-Route URIs it inserts. With the exception >>>>> that if TLS >>>>>> is >>>>>> used as the transport protocol on either side of the >>>>> proxy, the URI >>>>>> chosen to place in the Record-Route header field value >>>>> reflecting >>>>>> the >>>>>> interface using TLS will need to leverage the [RFC3263] >>>>> mechanisms >>>>>> to >>>>>> indicate that TLS must be used rather attempting >> to use the >>>>>> deprecated >>>>>> "transport=tls" URI parameter. See [RFC3261] Section >>> 26.2.2 and >>>>>> [I-D.ietf-sip-sips] Section 3.1.4 for more discussion." >>>>>> >>>>>> Brds, >>>>>> Thomas & Ben >>>>>> _______________________________________________ >>>>>> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >>>>>> This list is for NEW development of the core SIP 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://www.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP 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://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip From john.elwell@siemens-enterprise.com Wed Aug 12 00:01:24 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D4B03A6A50 for ; Wed, 12 Aug 2009 00:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.125 X-Spam-Level: X-Spam-Status: No, score=-2.125 tagged_above=-999 required=5 tests=[AWL=-0.126, BAYES_00=-2.599, J_CHICKENPOX_93=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tNHx4at8FaNi for ; Wed, 12 Aug 2009 00:01:23 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id BB8B13A6A07 for ; Wed, 12 Aug 2009 00:01:22 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KO900FBE3XUHK@siemenscomms.co.uk> for sip@ietf.org; Wed, 12 Aug 2009 07:41:54 +0100 (BST) Date: Wed, 12 Aug 2009 07:41:52 +0100 From: "Elwell, John" In-reply-to: To: Robert Sparks Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0023D2664@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: quoted-printable Thread-Topic: [Sip] draft-ietf-sip-record-route-fix-08 Changes Thread-Index: Acoa7SSHyt4mbsH9QnSd3hakaItKZwAKqjHg Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <8144761F31F48D43AD53D09F5350E38004C00CE5@FRVELSMBS22.ad2.ad.alcatel.com> A <0D5F89FAC29E2C41B98A6A762007F5D002393EA0@GBNTHT12009MSX.gb002.siemens.net> <8144761F31F48D43AD53D09F5350E38004C01534@FRVELSMBS22.ad2.ad.alcatel.com> <0D5F89FAC29E2C41B98A6A762007F5D0023D22FA@GBNTHT12009MSX.gb002.siemens.net> <8144761F31F48D43AD53D09F5350E38004C6042C@FRVELSMBS22.ad2.ad.alcatel.com> <0D5F89FAC29E2C41B98A6A762007F5D0023D2478@GBNTHT12009MSX.gb002.siemens.net> Cc: sip@ietf.org, BONNAERENS Ben Subject: Re: [Sip] draft-ietf-sip-record-route-fix-08 Changes X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 07:01:24 -0000 Robert, Yes, that would be a lot better. Thanks. John =20 > -----Original Message----- > From: Robert Sparks [mailto:rjsparks@nostrum.com]=20 > Sent: 12 August 2009 02:35 > To: Elwell, John > Cc: BONNAERENS Ben; sip@ietf.org > Subject: Re: [Sip] draft-ietf-sip-record-route-fix-08 Changes >=20 > John - >=20 > Would this substitution address your concern? >=20 > When TLS is used on the transport on either side of the proxy =20 > the URI > chosen to place in the Record-Route header field value =20 > reflecting the > interface using TLS will need to use a sips: URI or=20 > ensure that =20 > a sip: > URI resolves (per the procedures of [RFC3263]) to using=20 > TLS rather > than attempting to use the deprecated "transport=3Dtls" URI =20 > parameter. > See [RFC3261] Section 26.2.2 and [I-D.ietf-sip-sips]=20 > Section 3.1.4 > for more discussion >=20 > RjS >=20 > On Aug 11, 2009, at 7:21 AM, Elwell, John wrote: >=20 > > > > > >> -----Original Message----- > >> From: BONNAERENS Ben [mailto:ben.bonnaerens@alcatel-lucent.be] > >> Sent: 11 August 2009 12:44 > >> To: Elwell, John > >> Cc: sip@ietf.org; Thomas Froment > >> Subject: RE: [Sip] draft-ietf-sip-record-route-fix-08 Changes > >> > >> Hello John, > >> > >> What we are trying to say is that the URI, identifying the TLS > >> interface, placed > >> in the Record-Route header must, after executing the RFC3263 DNS > >> procedureson it, > >> result in the TLS transport being selected. > >> > >> This can be a sips URI or a sip URI (so called "best effort TLS" in > >> [I-D.ietf-sip-sips] chapter 3.1.3) > >> but we suggest to not use the deprecated "transport=3Dtls" = parameter. > > [JRE] So if you want to ensure TLS, either you use a sips URI or you > > populate your DNS records such that a sip URI always resolves to TLS > > transport - correct? > > If so, I think the average reader would have a hard time=20 > deducing this > > from the present text. > > > > John > > > >> > >> Best regards &Thanks, > >> > >> Ben > >> > >> RFC3263 Chapter 4.1 > >> " First, a client resolving a SIPS URI MUST discard any > >> services that > >> do not contain "SIPS" as the protocol in the service field. The > >> converse is not true, however. A client resolving a SIP=20 > URI SHOULD > >> retain records with "SIPS" as the protocol, if the=20 > client supports > >> TLS." > >> > >>> -----Original Message----- > >>> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > >>> Behalf Of Elwell, John > >>> Sent: dinsdag 11 augustus 2009 10:44 > >>> To: BONNAERENS Ben; sip@ietf.org > >>> Subject: Re: [Sip] draft-ietf-sip-record-route-fix-08 Changes > >>> > >>> In that case, I obviously misunderstood the text in the > >> current draft. > >>> What exactly is the meaning of "will need to leverage the > >>> [RFC3263] mechanisms"? > >>> > >>> John > >>> > >>>> -----Original Message----- > >>>> From: BONNAERENS Ben [mailto:ben.bonnaerens@alcatel-lucent.be] > >>>> Sent: 07 August 2009 14:57 > >>>> To: Elwell, John; sip@ietf.org > >>>> Subject: RE: [Sip] draft-ietf-sip-record-route-fix-08 Changes > >>>> > >>>> Hello John, > >>>> > >>>>> Well, I know what this means, but will your average reader > >>>>> understand it? I think we are trying to say something along the > >>>>> lines that if the transport protocol changes you SHOULD use the > >>>>> double Record-Route technique, where the differences in > >> transport > >>>>> protocol are reflected in different values of the transport > >>>>> parameter (udp/tcp/sctp) and/or different values of the > >>> URI scheme > >>>>> (sip/sips). Correct? > >>>> > >>>> Your phrasing could lead to the understanding that we > >> suggest that > >>>> only a sips URI can be used to identify the TLS interface > >>> which is not > >>>> correct. > >>>> As the current text suggests, can the TLS interface be > >>> identified by > >>>> any URI (sip or sips ; excluding the deprecated transport=3Dtls > >>>> parameter) that resolves via RFC3263 procedures to the TLS > >>> transport. > >>>> > >>>> IMHO leaves your suggested phrasing more room for ambiguity > >>> compared > >>>> to the current text. > >>>> > >>>> Best regards & thanks, > >>>> > >>>> Ben. > >>>> > >>>>> -----Original Message----- > >>>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > >>>>> Sent: donderdag 6 augustus 2009 9:37 > >>>>> To: BONNAERENS Ben; sip@ietf.org > >>>>> Subject: RE: [Sip] draft-ietf-sip-record-route-fix-08 Changes > >>>>> > >>>>> Well, I know what this means, but will your average reader > >>>>> understand it? I think we are trying to say something along the > >>>>> lines that if the transport protocol changes you SHOULD use the > >>>>> double Record-Route technique, where the differences in > >> transport > >>>>> protocol are reflected in different values of the transport > >>>>> parameter (udp/tcp/sctp) and/or different values of the > >>> URI scheme > >>>>> (sip/sips). Correct? > >>>>> > >>>>> John > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > >>>>> Behalf Of > >>>>>> BONNAERENS Ben > >>>>>> Sent: 05 August 2009 15:23 > >>>>>> To: sip@ietf.org > >>>>>> Subject: [Sip] draft-ietf-sip-record-route-fix-08 Changes > >>>>>> > >>>>>> Hi, > >>>>>> version -08 of record-route fix has just been submitted. > >>>>>> > >>>>>> Change log: > >>>>>> - Changed its status from BCP to PS, > >>>>>> - Take into account IESG reviews and subsequent > >> comments on the > >>>>>> mailing lists, they were summarized in Robert > >> Sparks's document > >>>>>> (rrf.txt), so it has been integrated in version -08 > >> with minor > >>>>>> refactoring from the authors (me and Ben). > >>>>>> > >>>>>> The thoughest part was related to the SIP/SIPS question > >>> raised by > >>>>>> Cullen > >>>>> (http://datatracker.ietf.org/idtracker/draft-ietf-sip-record-r > >>>>>> oute-fix/c > >>>>>> omment/98624/), > >>>>>> so here is the text that was added in version -08 to > >> answer this > >>>>>> question: > >>>>>> "Thus, if the transport protocol changed between its > >>>>>> incoming and outgoing sides, the proxy SHOULD use > >> the double > >>>>>> Record-Route technique and SHOULD add a transport > >>>>> parameter to each > >>>>>> of the Record-Route URIs it inserts. With the exception > >>>>> that if TLS > >>>>>> is > >>>>>> used as the transport protocol on either side of the > >>>>> proxy, the URI > >>>>>> chosen to place in the Record-Route header field value > >>>>> reflecting > >>>>>> the > >>>>>> interface using TLS will need to leverage the [RFC3263] > >>>>> mechanisms > >>>>>> to > >>>>>> indicate that TLS must be used rather attempting > >> to use the > >>>>>> deprecated > >>>>>> "transport=3Dtls" URI parameter. See [RFC3261] Section > >>> 26.2.2 and > >>>>>> [I-D.ietf-sip-sips] Section 3.1.4 for more discussion." > >>>>>> > >>>>>> Brds, > >>>>>> Thomas & Ben > >>>>>> _______________________________________________ > >>>>>> Sip mailing list https://www.ietf.org/mailman/listinfo/sip > >>>>>> This list is for NEW development of the core SIP 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://www.ietf.org/mailman/listinfo/sip > >>> This list is for NEW development of 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 > >>> > >> > > _______________________________________________ > > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP 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 From root@core3.amsl.com Wed Aug 12 13:00:01 2009 Return-Path: X-Original-To: sip@ietf.org Delivered-To: sip@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id E91363A6A93; Wed, 12 Aug 2009 13:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090812200001.E91363A6A93@core3.amsl.com> Date: Wed, 12 Aug 2009 13:00:01 -0700 (PDT) Cc: sip@ietf.org Subject: [Sip] I-D Action:draft-ietf-sip-record-route-fix-09.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 20:00:02 -0000 --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 : Addressing Record-Route issues in the Session Initiation Protocol (SIP) Author(s) : T. Froment, et al. Filename : draft-ietf-sip-record-route-fix-09.txt Pages : 26 Date : 2009-08-12 A typical function of a Session Initiation Protocol (SIP) Proxy is to insert a Record-Route header into initial, dialog creating requests in order to make subsequent, in-dialog requests pass through it. This header contains a SIP Uniform Resource Identifier (URI) indicating where and how the subsequent requests should be sent to reach the proxy. Like any SIP URI, it can contain SIP or SIPS schemes, IPv4 or IPv6 addresses, and URI parameters that could influence the routing such as the transport parameter (for example transport=tcp), or a compression indication like "comp=sigcomp". When a proxy has to change some of those parameters between its incoming and outgoing interfaces (multi-homed proxies, transport protocol switching or IPv4 to IPv6 scenarios...), the question arises on what should be put in Record-Route header(s). It is not possible to make one header have the characteristics of both interfaces at the same time. This document aims to clarify these scenarios and fix bugs already identified on this topic; it formally recommends the use of the double Record-Route technique as an alternative to the current RFC3261 text, which describes only a Record-Route rewriting solution. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-record-route-fix-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-sip-record-route-fix-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-08-12125102.I-D@ietf.org> --NextPart-- From dean.willis@softarmor.com Wed Aug 12 13:00:15 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7768E3A6CCC for ; Wed, 12 Aug 2009 13:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oj1thW8EqZ-Q for ; Wed, 12 Aug 2009 13:00:14 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 557E43A67B7 for ; Wed, 12 Aug 2009 13:00:14 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n7CJgqDU003911 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 12 Aug 2009 14:46:34 -0500 Message-Id: From: Dean Willis To: Robert Sparks In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 12 Aug 2009 14:42:42 -0500 References: <8144761F31F48D43AD53D09F5350E38004C00CE5@FRVELSMBS22.ad2.ad.alcatel.com> A <0D5F89FAC29E2C41B98A6A762007F5D002393EA0@GBNTHT12009MSX.gb002.siemens.net> <8144761F31F48D43AD53D09F5350E38004C01534@FRVELSMBS22.ad2.ad.alcatel.com> <0D5F89FAC29E2C41B98A6A762007F5D0023D22FA@GBNTHT12009MSX.gb002.siemens.net> <8144761F31F48D43AD53D09F5350E38004C6042C@FRVELSMBS22.ad2.ad.alcatel.com> <0D5F89FAC29E2C41B98A6A762007F5D0023D2478@GBNTHT12009MSX.gb002.siemens.net> X-Mailer: Apple Mail (2.936) Cc: sip@ietf.org, BONNAERENS Ben Subject: Re: [Sip] draft-ietf-sip-record-route-fix-08 Changes X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 20:00:15 -0000 On Aug 11, 2009, at 8:35 PM, Robert Sparks wrote: > John - > > Would this substitution address your concern? > > When TLS is used on the transport on either side of the proxy > the URI > chosen to place in the Record-Route header field value > reflecting the > interface using TLS will need to use a sips: URI or ensure that > a sip: > URI resolves (per the procedures of [RFC3263]) to using TLS rather > than attempting to use the deprecated "transport=tls" URI > parameter. > See [RFC3261] Section 26.2.2 and [I-D.ietf-sip-sips] Section 3.1.4 > for more discussion > That makes my head hurt! Compound sentences should make sense even with clauses redacted. Let's play some games with this mind twister: First I'll try to scope the sub-clauses: > (When TLS is used (on the transport (on either side of the proxy))) > the URI (chosen to place (in the Record-Route header field value > (reflecting the interface using TLS))) will need to use a sips: URI > or ensure that a sip: URI resolves (per the procedures of [RFC3263]) > to using TLS (rather than attempting to use the deprecated > "transport=tls" URI parameter). > One reduction to see if it makes sense: > When TLS is used the URI chosen to place in the Record-Route header > field value will need to use a sips: URI or ensure that a sip: URI > resolves (per the procedures of [RFC3263]) to using TLS rather than > attempting to use the deprecated "transport=tls" URI parameter. Let's pull some smaller pieces out of this: > When TLS is used the URI chosen to place in the Record-Route header > field value will need to use a sips: URI. "chosen to place" is clumsy. Let's substitute "placed", add a comma for the subordination, and see if it gets better. > When TLS is used, the URI placed in the Record-Route header field > value will need to use a sips: URI. What does it mean for a URI to use a URI? I think perhaps it needs to BE a SIPS URI. Rewritten: > When TLS is used, the URI placed in the Record-Route header field > value will need to be a sips: URI. Now lets look at the other half of that clause: > When TLS is used, the URI placed in the Record-Route header field > value will need to ensure that a sip: URI resolves (per the > procedures of [RFC3263]) to using TLS rather than attempting to use > the deprecated "transport=tls" URI parameter. How does a URI ensure that a ensure something about a URI? Maybe you mean: > When TLS is used, the URI placed in the Record-Route header field > value MUST resolve (per the procedures of [RFC3263]) to using TLS > rather than attempting to use the deprecated "transport=tls" URI > parameter. I'm still stumbling over "resolve to using TLS rather than attempting to use the deprecated "transport=tls" URI parameter." So let's just lop off the sentence from "rather than . . ." and move that out. What's wrong with > When TLS is used, the URI placed in the Record-Route header field > value MUST resolve (per the procedures of [RFC3263]) to using TLS . Is "resolve to using TLS" the same thing as "resolve using TLS"? I think they're subtly different, but the complexity still scares me. I think we're trying to say that the application of RFC 3263 procedures to the URI must result in a next-hop that is reachable only by TLS. So let's try a rewrite based on these assumptions. How about this: > When TLS is used, the URI placed in the Record-Route header field > MUST encode a next-hop that will be reached using TLS. There are two > ways for this to work. The first way is for the URI placed in the > Record-Route to be a sips: URI. The second is for the URI placed in > the Record-Route to be constructed such that application of RFC > 3263 resolution procedures > to that URI produces a result reachable only using TLS. Proxies > compliant with this specification MUST NOT use a "transport=tls" > parameter on the URI placed in the Record-Route because the > "transport=tls" usage was deprecated by RFC 3261. Does that mean the same thing to you as the original megasentence did? -- Dean From rjsparks@nostrum.com Wed Aug 12 13:15:45 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99D4C3A6A83 for ; Wed, 12 Aug 2009 13:15:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SZ3zxOIk+9I5 for ; Wed, 12 Aug 2009 13:15:41 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 474D43A6942 for ; Wed, 12 Aug 2009 13:15:40 -0700 (PDT) Received: from dn3-232.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n7CKFMeb045688 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 12 Aug 2009 15:15:30 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-Id: From: Robert Sparks To: Dean Willis In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 12 Aug 2009 15:15:19 -0500 References: <8144761F31F48D43AD53D09F5350E38004C00CE5@FRVELSMBS22.ad2.ad.alcatel.com> A <0D5F89FAC29E2C41B98A6A762007F5D002393EA0@GBNTHT12009MSX.gb002.siemens.net> <8144761F31F48D43AD53D09F5350E38004C01534@FRVELSMBS22.ad2.ad.alcatel.com> <0D5F89FAC29E2C41B98A6A762007F5D0023D22FA@GBNTHT12009MSX.gb002.siemens.net> <8144761F31F48D43AD53D09F5350E38004C6042C@FRVELSMBS22.ad2.ad.alcatel.com> <0D5F89FAC29E2C41B98A6A762007F5D0023D2478@GBNTHT12009MSX.gb002.siemens.net> X-Mailer: Apple Mail (2.936) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: sip@ietf.org, BONNAERENS Ben Subject: Re: [Sip] draft-ietf-sip-record-route-fix-08 Changes X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 20:15:45 -0000 I skipped straight to the end (will come back and read how you got there later). But yes, I think the rewrite you have at the end says the the same thing. RjS On Aug 12, 2009, at 2:42 PM, Dean Willis wrote: > > On Aug 11, 2009, at 8:35 PM, Robert Sparks wrote: > >> John - >> >> Would this substitution address your concern? >> >> When TLS is used on the transport on either side of the proxy >> the URI >> chosen to place in the Record-Route header field value >> reflecting the >> interface using TLS will need to use a sips: URI or ensure that >> a sip: >> URI resolves (per the procedures of [RFC3263]) to using TLS rather >> than attempting to use the deprecated "transport=tls" URI >> parameter. >> See [RFC3261] Section 26.2.2 and [I-D.ietf-sip-sips] Section 3.1.4 >> for more discussion >> > > > That makes my head hurt! > > Compound sentences should make sense even with clauses redacted. > > Let's play some games with this mind twister: > > > First I'll try to scope the sub-clauses: > >> (When TLS is used (on the transport (on either side of the proxy))) >> the URI (chosen to place (in the Record-Route header field value >> (reflecting the interface using TLS))) will need to use a sips: URI >> or ensure that a sip: URI resolves (per the procedures of >> [RFC3263]) to using TLS (rather than attempting to use the >> deprecated "transport=tls" URI parameter). >> > > One reduction to see if it makes sense: > >> When TLS is used the URI chosen to place in the Record-Route header >> field value will need to use a sips: URI or ensure that a sip: URI >> resolves (per the procedures of [RFC3263]) to using TLS rather than >> attempting to use the deprecated "transport=tls" URI parameter. > > > Let's pull some smaller pieces out of this: > >> When TLS is used the URI chosen to place in the Record-Route header >> field value will need to use a sips: URI. > > > "chosen to place" is clumsy. Let's substitute "placed", add a comma > for the subordination, and see if it gets better. > >> When TLS is used, the URI placed in the Record-Route header field >> value will need to use a sips: URI. > > What does it mean for a URI to use a URI? I think perhaps it needs > to BE a SIPS URI. > > Rewritten: > >> When TLS is used, the URI placed in the Record-Route header field >> value will need to be a sips: URI. > > Now lets look at the other half of that clause: > >> When TLS is used, the URI placed in the Record-Route header field >> value will need to ensure that a sip: URI resolves (per the >> procedures of [RFC3263]) to using TLS rather than attempting to use >> the deprecated "transport=tls" URI parameter. > > > How does a URI ensure that a ensure something about a URI? > > Maybe you mean: > >> When TLS is used, the URI placed in the Record-Route header field >> value MUST resolve (per the procedures of [RFC3263]) to using TLS >> rather than attempting to use the deprecated "transport=tls" URI >> parameter. > > > I'm still stumbling over "resolve to using TLS rather than > attempting to use the deprecated "transport=tls" URI parameter." So > let's just lop off the sentence from "rather than . . ." and move > that out. > > What's wrong with > >> When TLS is used, the URI placed in the Record-Route header field >> value MUST resolve (per the procedures of [RFC3263]) to using TLS . > > Is "resolve to using TLS" the same thing as "resolve using TLS"? I > think they're subtly different, but the complexity still scares me. > I think we're trying to say that the application of RFC 3263 > procedures to the URI must result in a next-hop that is reachable > only by TLS. > > So let's try a rewrite based on these assumptions. How about this: > >> When TLS is used, the URI placed in the Record-Route header field >> MUST encode a next-hop that will be reached using TLS. There are >> two ways for this to work. The first way is for the URI placed in >> the Record-Route to be a sips: URI. The second is for the URI >> placed in the Record-Route to be constructed such that application >> of RFC 3263 resolution procedures >> to that URI produces a result reachable only using TLS. Proxies >> compliant with this specification MUST NOT use a "transport=tls" >> parameter on the URI placed in the Record-Route because the >> "transport=tls" usage was deprecated by RFC 3261. > > Does that mean the same thing to you as the original megasentence did? > > -- > Dean > > > From dean.willis@softarmor.com Wed Aug 12 13:18:02 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A9223A6A01 for ; Wed, 12 Aug 2009 13:18:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oZJL4WU+jtXn for ; Wed, 12 Aug 2009 13:18:01 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 01EC83A68F8 for ; Wed, 12 Aug 2009 13:18:00 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n7CKH9Pf004238 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 12 Aug 2009 15:17:11 -0500 Message-Id: <00CBDB5D-5BD3-437E-9369-FDB2587FF039@softarmor.com> From: Dean Willis To: Robert Sparks In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 12 Aug 2009 15:17:05 -0500 References: <8144761F31F48D43AD53D09F5350E38004C00CE5@FRVELSMBS22.ad2.ad.alcatel.com> A <0D5F89FAC29E2C41B98A6A762007F5D002393EA0@GBNTHT12009MSX.gb002.siemens.net> <8144761F31F48D43AD53D09F5350E38004C01534@FRVELSMBS22.ad2.ad.alcatel.com> <0D5F89FAC29E2C41B98A6A762007F5D0023D22FA@GBNTHT12009MSX.gb002.siemens.net> <8144761F31F48D43AD53D09F5350E38004C6042C@FRVELSMBS22.ad2.ad.alcatel.com> <0D5F89FAC29E2C41B98A6A762007F5D0023D2478@GBNTHT12009MSX.gb002.siemens.net> X-Mailer: Apple Mail (2.936) Cc: sip@ietf.org, BONNAERENS Ben Subject: Re: [Sip] draft-ietf-sip-record-route-fix-08 Changes X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 20:18:02 -0000 On Aug 11, 2009, at 8:35 PM, Robert Sparks wrote: > John - > > Would this substitution address your concern? > > When TLS is used on the transport on either side of the proxy the > URI > chosen to place in the Record-Route header field value reflecting > the > interface using TLS will need to use a sips: URI or ensure that a > sip: > URI resolves (per the procedures of [RFC3263]) to using TLS rather > than attempting to use the deprecated "transport=tls" URI > parameter. > See [RFC3261] Section 26.2.2 and [I-D.ietf-sip-sips] Section 3.1.4 > for more discussion > That makes my head hurt! Compound sentences should make sense even with clauses redacted. Let's play some games with this mind twister: First I'll try to scope the sub-clauses: > (When TLS is used (on the transport (on either side of the proxy))) > the URI (chosen to place (in the Record-Route header field value > (reflecting the interface using TLS))) will need to use a sips: URI > or ensure that a sip: URI resolves (per the procedures of [RFC3263]) > to using TLS (rather than attempting to use the deprecated > "transport=tls" URI parameter). > One reduction to see if it makes sense: > When TLS is used the URI chosen to place in the Record-Route header > field value will need to use a sips: URI or ensure that a sip: URI > resolves (per the procedures of [RFC3263]) to using TLS rather than > attempting to use the deprecated "transport=tls" URI parameter. Let's pull some smaller pieces out of this: > When TLS is used the URI chosen to place in the Record-Route header > field value will need to use a sips: URI. "chosen to place" is clumsy. Let's substitute "placed", add a comma for the subordination, and see if it gets better. > When TLS is used, the URI placed in the Record-Route header field > value will need to use a sips: URI. What does it mean for a URI to use a URI? I think perhaps it needs to BE a SIPS URI. Rewritten: > When TLS is used, the URI placed in the Record-Route header field > value will need to be a sips: URI. Now lets look at the other half of that clause: > When TLS is used, the URI placed in the Record-Route header field > value will need to ensure that a sip: URI resolves (per the > procedures of [RFC3263]) to using TLS rather than attempting to use > the deprecated "transport=tls" URI parameter. How does a URI ensure that a ensure something about a URI? Maybe you mean: > When TLS is used, the URI placed in the Record-Route header field > value MUST resolve (per the procedures of [RFC3263]) to using TLS > rather than attempting to use the deprecated "transport=tls" URI > parameter. I'm still stumbling over "resolve to using TLS rather than attempting to use the deprecated "transport=tls" URI parameter." So let's just lop off the sentence from "rather than . . ." and move that out. What's wrong with > When TLS is used, the URI placed in the Record-Route header field > value MUST resolve (per the procedures of [RFC3263]) to using TLS . Is "resolve to using TLS" the same thing as "resolve using TLS"? I think they're subtly different, but the complexity still scares me. I think we're trying to say that the application of RFC 3263 procedures to the URI must result in a next-hop that is reachable only by TLS. So let's try a rewrite based on these assumptions. How about this: > When TLS is used, the URI placed in the Record-Route header field > MUST encode a next-hop that will be reached using TLS. There are two > ways for this to work. The first way is for the URI placed in the > Record-Route to be a sips: URI. The second is for the URI placed in > the Record-Route to be constructed such that application of RFC > 3263 resolution procedures > to that URI produces a result reachable only using TLS. Proxies > compliant with this specification MUST NOT use a "transport=tls" > parameter on the URI placed in the Record-Route because the > "transport=tls" usage was deprecated by RFC 3261. Does that mean the same thing to you as the original megasentence did? -- Dean From john.elwell@siemens-enterprise.com Thu Aug 13 03:47:29 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C17A13A67FF for ; Thu, 13 Aug 2009 03:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.421 X-Spam-Level: X-Spam-Status: No, score=-2.421 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OzdL2fhlDB8k for ; Thu, 13 Aug 2009 03:47:28 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id E4C4D3A67AC for ; Thu, 13 Aug 2009 03:47:27 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KOB0010Y9RTFD@siemenscomms.co.uk> for sip@ietf.org; Thu, 13 Aug 2009 11:43:05 +0100 (BST) Date: Thu, 13 Aug 2009 11:42:51 +0100 From: "Elwell, John" In-reply-to: To: Robert Sparks , Dean Willis Message-id: <0D5F89FAC29E2C41B98A6A762007F5D00243080B@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: quoted-printable Thread-Topic: [Sip] draft-ietf-sip-record-route-fix-08 Changes Thread-Index: Acobia/H0iXbdeyATAes6YGoZbqMEgAeROXA Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <8144761F31F48D43AD53D09F5350E38004C00CE5@FRVELSMBS22.ad2.ad.alcatel.com> A <0D5F89FAC29E2C41B98A6A762007F5D002393EA0@GBNTHT12009MSX.gb002.siemens.net> <8144761F31F48D43AD53D09F5350E38004C01534@FRVELSMBS22.ad2.ad.alcatel.com> <0D5F89FAC29E2C41B98A6A762007F5D0023D22FA@GBNTHT12009MSX.gb002.siemens.net> <8144761F31F48D43AD53D09F5350E38004C6042C@FRVELSMBS22.ad2.ad.alcatel.com> <0D5F89FAC29E2C41B98A6A762007F5D0023D2478@GBNTHT12009MSX.gb002.siemens.net> Cc: sip@ietf.org, BONNAERENS Ben Subject: Re: [Sip] draft-ietf-sip-record-route-fix-08 Changes X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 10:47:29 -0000 OK for me too.=20 John > -----Original Message----- > From: Robert Sparks [mailto:rjsparks@nostrum.com]=20 > Sent: 12 August 2009 21:15 > To: Dean Willis > Cc: Elwell, John; sip@ietf.org; BONNAERENS Ben > Subject: Re: [Sip] draft-ietf-sip-record-route-fix-08 Changes >=20 > I skipped straight to the end (will come back and read how you got =20 > there later). > But yes, I think the rewrite you have at the end says the the same =20 > thing. >=20 > RjS > On Aug 12, 2009, at 2:42 PM, Dean Willis wrote: >=20 > > > > On Aug 11, 2009, at 8:35 PM, Robert Sparks wrote: > > > >> John - > >> > >> Would this substitution address your concern? > >> > >> When TLS is used on the transport on either side of the proxy =20 > >> the URI > >> chosen to place in the Record-Route header field value =20 > >> reflecting the > >> interface using TLS will need to use a sips: URI or=20 > ensure that =20 > >> a sip: > >> URI resolves (per the procedures of [RFC3263]) to using=20 > TLS rather > >> than attempting to use the deprecated "transport=3Dtls" URI =20 > >> parameter. > >> See [RFC3261] Section 26.2.2 and [I-D.ietf-sip-sips]=20 > Section 3.1.4 > >> for more discussion > >> > > > > > > That makes my head hurt! > > > > Compound sentences should make sense even with clauses redacted. > > > > Let's play some games with this mind twister: > > > > > > First I'll try to scope the sub-clauses: > > > >> (When TLS is used (on the transport (on either side of the=20 > proxy))) =20 > >> the URI (chosen to place (in the Record-Route header field value =20 > >> (reflecting the interface using TLS))) will need to use a=20 > sips: URI =20 > >> or ensure that a sip: URI resolves (per the procedures of =20 > >> [RFC3263]) to using TLS (rather than attempting to use the =20 > >> deprecated "transport=3Dtls" URI parameter). > >> > > > > One reduction to see if it makes sense: > > > >> When TLS is used the URI chosen to place in the=20 > Record-Route header =20 > >> field value will need to use a sips: URI or ensure that a=20 > sip: URI =20 > >> resolves (per the procedures of [RFC3263]) to using TLS=20 > rather than =20 > >> attempting to use the deprecated "transport=3Dtls" URI parameter. > > > > > > Let's pull some smaller pieces out of this: > > > >> When TLS is used the URI chosen to place in the=20 > Record-Route header =20 > >> field value will need to use a sips: URI. > > > > > > "chosen to place" is clumsy. Let's substitute "placed", add=20 > a comma =20 > > for the subordination, and see if it gets better. > > > >> When TLS is used, the URI placed in the Record-Route header field =20 > >> value will need to use a sips: URI. > > > > What does it mean for a URI to use a URI? I think perhaps it needs =20 > > to BE a SIPS URI. > > > > Rewritten: > > > >> When TLS is used, the URI placed in the Record-Route header field =20 > >> value will need to be a sips: URI. > > > > Now lets look at the other half of that clause: > > > >> When TLS is used, the URI placed in the Record-Route header field =20 > >> value will need to ensure that a sip: URI resolves (per the =20 > >> procedures of [RFC3263]) to using TLS rather than=20 > attempting to use =20 > >> the deprecated "transport=3Dtls" URI parameter. > > > > > > How does a URI ensure that a ensure something about a URI? > > > > Maybe you mean: > > > >> When TLS is used, the URI placed in the Record-Route header field =20 > >> value MUST resolve (per the procedures of [RFC3263]) to using TLS =20 > >> rather than attempting to use the deprecated "transport=3Dtls" URI = =20 > >> parameter. > > > > > > I'm still stumbling over "resolve to using TLS rather than =20 > > attempting to use the deprecated "transport=3Dtls" URI=20 > parameter." So =20 > > let's just lop off the sentence from "rather than . . ." and move =20 > > that out. > > > > What's wrong with > > > >> When TLS is used, the URI placed in the Record-Route header field =20 > >> value MUST resolve (per the procedures of [RFC3263]) to using TLS . > > > > Is "resolve to using TLS" the same thing as "resolve using TLS"? I =20 > > think they're subtly different, but the complexity still=20 > scares me. =20 > > I think we're trying to say that the application of RFC 3263 =20 > > procedures to the URI must result in a next-hop that is reachable =20 > > only by TLS. > > > > So let's try a rewrite based on these assumptions. How about this: > > > >> When TLS is used, the URI placed in the Record-Route header field =20 > >> MUST encode a next-hop that will be reached using TLS. There are =20 > >> two ways for this to work. The first way is for the URI placed in =20 > >> the Record-Route to be a sips: URI. The second is for the URI =20 > >> placed in the Record-Route to be constructed such that=20 > application =20 > >> of RFC 3263 resolution procedures > >> to that URI produces a result reachable only using TLS. Proxies =20 > >> compliant with this specification MUST NOT use a "transport=3Dtls" = > >> parameter on the URI placed in the Record-Route because the =20 > >> "transport=3Dtls" usage was deprecated by RFC 3261. > > > > Does that mean the same thing to you as the original=20 > megasentence did? > > > > -- > > Dean > > > > > > >=20 >=20 From ben.bonnaerens@alcatel-lucent.be Thu Aug 13 05:16:11 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0B2F3A6A8F for ; Thu, 13 Aug 2009 05:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.024 X-Spam-Level: X-Spam-Status: No, score=-6.024 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mCMxOIgyMFxJ for ; Thu, 13 Aug 2009 05:16:10 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by core3.amsl.com (Postfix) with ESMTP id 1A8933A6A63 for ; Thu, 13 Aug 2009 05:16:09 -0700 (PDT) Received: from FRVELSBHS03.ad2.ad.alcatel.com (frvelsbhs03.dc-m.alcatel-lucent.com [155.132.6.75]) by smail2.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n7DBl0C5020921; Thu, 13 Aug 2009 13:47:01 +0200 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.51]) by FRVELSBHS03.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 13 Aug 2009 13:47:00 +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: Thu, 13 Aug 2009 13:46:59 +0200 Message-ID: <8144761F31F48D43AD53D09F5350E38004C60C04@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <00CBDB5D-5BD3-437E-9369-FDB2587FF039@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-ietf-sip-record-route-fix-08 Changes Thread-Index: AcobieLqOkIJBNsbQwy8UbzazJdztAAfyxnQ References: <8144761F31F48D43AD53D09F5350E38004C00CE5@FRVELSMBS22.ad2.ad.alcatel.com> A <0D5F89FAC29E2C41B98A6A762007F5D002393EA0@GBNTHT12009MSX.gb002.siemens.net> <8144761F31F48D43AD53D09F5350E38004C01534@FRVELSMBS22.ad2.ad.alcatel.com> <0D5F89FAC29E2C41B98A6A762007F5D0023D22FA@GBNTHT12009MSX.gb002.siemens.net> <8144761F31F48D43AD53D09F5350E38004C6042C@FRVELSMBS22.ad2.ad.alcatel.com> <0D5F89FAC29E2C41B98A6A762007F5D0023D2478@GBNTHT12009MSX.gb002.siemens.net> <00CBDB5D-5BD3-437E-9369-FDB2587FF039@softarmor.com> From: "BONNAERENS Ben" To: "Dean Willis" , "Robert Sparks" X-OriginalArrivalTime: 13 Aug 2009 11:47:00.0214 (UTC) FILETIME=[C49A3960:01CA1C0B] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.80 Cc: sip@ietf.org Subject: Re: [Sip] draft-ietf-sip-record-route-fix-08 Changes X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 12:16:11 -0000 Hello Dean, Sorry to make your head hurt ;-) To me the -09 sentence was clear but I do think you have a point on the compound sentences. Still I would like to comment on the "only" in following sentence of the text you proposed: "The second is for the URI placed in the Record-Route to be constructed such that application of RFC =20 3263 resolution procedures to that URI produces a result reachable only using TLS." Why should that URI _only_ be reachable via TLS? The DNS for that URI can be populated with NAPTR records for multiple transports with TLS as preferred I assume. I would also replace "sips: URI" by "SIPS URI" to be consistent across the document. Resulting in following updated text: "When TLS is used on the transport on either side of the proxy, the URI placed in the Record-Route header field MUST encode=20 a next-hop that will be reached using TLS. There are two =20 ways for this to work. The first way is for the URI placed in the =20 Record-Route to be a SIPS URI.The second is for the URI placed in =20 the Record-Route to be constructed such that application of =20 [RFC3263] resolution procedures to that URI results in TLS being selected.=20 Proxies compliant with this specification MUST NOT use a = "transport=3Dtls" parameter on the URI placed in the Record-Route because the =20 "transport=3Dtls" usage was deprecated by RFC 3261." Can we agree on this text? Best regards & Thanks, Ben. > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: woensdag 12 augustus 2009 22:17 > To: Robert Sparks > Cc: Elwell, John; sip@ietf.org; BONNAERENS Ben > Subject: Re: [Sip] draft-ietf-sip-record-route-fix-08 Changes >=20 >=20 > On Aug 11, 2009, at 8:35 PM, Robert Sparks wrote: >=20 > > John - > > > > Would this substitution address your concern? > > > > When TLS is used on the transport on either side of the=20 > proxy the=20 > > URI > > chosen to place in the Record-Route header field value=20 > reflecting=20 > > the > > interface using TLS will need to use a sips: URI or ensure that a > > sip: > > URI resolves (per the procedures of [RFC3263]) to using=20 > TLS rather > > than attempting to use the deprecated "transport=3Dtls" URI=20 > > parameter. > > See [RFC3261] Section 26.2.2 and [I-D.ietf-sip-sips]=20 > Section 3.1.4 > > for more discussion > > >=20 >=20 > That makes my head hurt! >=20 > Compound sentences should make sense even with clauses redacted. >=20 > Let's play some games with this mind twister: >=20 >=20 > First I'll try to scope the sub-clauses: >=20 > > (When TLS is used (on the transport (on either side of the proxy)))=20 > > the URI (chosen to place (in the Record-Route header field value=20 > > (reflecting the interface using TLS))) will need to use a=20 > sips: URI or=20 > > ensure that a sip: URI resolves (per the procedures of [RFC3263]) > > to using TLS (rather than attempting to use the deprecated =20 > > "transport=3Dtls" URI parameter). > > >=20 > One reduction to see if it makes sense: >=20 > > When TLS is used the URI chosen to place in the Record-Route header=20 > > field value will need to use a sips: URI or ensure that a sip: URI=20 > > resolves (per the procedures of [RFC3263]) to using TLS rather than=20 > > attempting to use the deprecated "transport=3Dtls" URI parameter. >=20 >=20 > Let's pull some smaller pieces out of this: >=20 > > When TLS is used the URI chosen to place in the Record-Route header=20 > > field value will need to use a sips: URI. >=20 >=20 > "chosen to place" is clumsy. Let's substitute "placed", add a comma =20 > for the subordination, and see if it gets better. >=20 > > When TLS is used, the URI placed in the Record-Route header field =20 > > value will need to use a sips: URI. >=20 > What does it mean for a URI to use a URI? I think perhaps it=20 > needs to =20 > BE a SIPS URI. >=20 > Rewritten: >=20 > > When TLS is used, the URI placed in the Record-Route header field =20 > > value will need to be a sips: URI. >=20 > Now lets look at the other half of that clause: >=20 > > When TLS is used, the URI placed in the Record-Route header field =20 > > value will need to ensure that a sip: URI resolves (per the =20 > > procedures of [RFC3263]) to using TLS rather than=20 > attempting to use =20 > > the deprecated "transport=3Dtls" URI parameter. >=20 >=20 > How does a URI ensure that a ensure something about a URI? >=20 > Maybe you mean: >=20 > > When TLS is used, the URI placed in the Record-Route header field =20 > > value MUST resolve (per the procedures of [RFC3263]) to using TLS =20 > > rather than attempting to use the deprecated "transport=3Dtls" URI = > > parameter. >=20 >=20 > I'm still stumbling over "resolve to using TLS rather than=20 > attempting =20 > to use the deprecated "transport=3Dtls" URI parameter." So let's just = =20 > lop off the sentence from "rather than . . ." and move that out. >=20 > What's wrong with >=20 > > When TLS is used, the URI placed in the Record-Route header field =20 > > value MUST resolve (per the procedures of [RFC3263]) to using TLS . >=20 > Is "resolve to using TLS" the same thing as "resolve using TLS"? I =20 > think they're subtly different, but the complexity still=20 > scares me. I =20 > think we're trying to say that the application of RFC 3263=20 > procedures =20 > to the URI must result in a next-hop that is reachable only by TLS. >=20 > So let's try a rewrite based on these assumptions. How about this: >=20 > > When TLS is used, the URI placed in the Record-Route header field =20 > > MUST encode a next-hop that will be reached using TLS.=20 > There are two =20 > > ways for this to work. The first way is for the URI placed in the =20 > > Record-Route to be a sips: URI. The second is for the URI=20 > placed in =20 > > the Record-Route to be constructed such that application of RFC =20 > > 3263 resolution procedures > > to that URI produces a result reachable only using TLS. Proxies =20 > > compliant with this specification MUST NOT use a "transport=3Dtls" =20 > > parameter on the URI placed in the Record-Route because the =20 > > "transport=3Dtls" usage was deprecated by RFC 3261. >=20 > Does that mean the same thing to you as the original megasentence did? >=20 > -- > Dean >=20 >=20 >=20 >=20 From dean.willis@softarmor.com Thu Aug 13 14:15:15 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E51A3A6AC4 for ; Thu, 13 Aug 2009 14:15:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 75UXG5O4hFPM for ; Thu, 13 Aug 2009 14:15:14 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id DA55C3A693C for ; Thu, 13 Aug 2009 14:14:29 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n7DLCJFZ016057 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 13 Aug 2009 16:12:21 -0500 Message-Id: From: Dean Willis To: BONNAERENS Ben In-Reply-To: <8144761F31F48D43AD53D09F5350E38004C60C04@FRVELSMBS22.ad2.ad.alcatel.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 13 Aug 2009 16:12:13 -0500 References: <8144761F31F48D43AD53D09F5350E38004C00CE5@FRVELSMBS22.ad2.ad.alcatel.com> A <0D5F89FAC29E2C41B98A6A762007F5D002393EA0@GBNTHT12009MSX.gb002.siemens.net> <8144761F31F48D43AD53D09F5350E38004C01534@FRVELSMBS22.ad2.ad.alcatel.com> <0D5F89FAC29E2C41B98A6A762007F5D0023D22FA@GBNTHT12009MSX.gb002.siemens.net> <8144761F31F48D43AD53D09F5350E38004C6042C@FRVELSMBS22.ad2.ad.alcatel.com> <0D5F89FAC29E2C41B98A6A762007F5D0023D2478@GBNTHT12009MSX.gb002.siemens.net> <00CBDB5D-5BD3-437E-9369-FDB2587FF039@softarmor.com> <8144761F31F48D43AD53D09F5350E38004C60C04@FRVELSMBS22.ad2.ad.alcatel.com> X-Mailer: Apple Mail (2.936) Cc: sip@ietf.org Subject: Re: [Sip] draft-ietf-sip-record-route-fix-08 Changes X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 21:15:15 -0000 On Aug 13, 2009, at 6:46 AM, BONNAERENS Ben wrote: > Hello Dean, > > Sorry to make your head hurt ;-) > > To me the -09 sentence was clear but I do think you have a point on > the > compound sentences. > > Still I would like to comment on the "only" in following sentence of > the > text you proposed: > "The second is for the URI placed in the Record-Route to be > constructed > such that application of RFC > 3263 resolution procedures to that URI produces a result reachable > only > using TLS." > > Why should that URI _only_ be reachable via TLS? > The DNS for that URI can be populated with NAPTR records > for multiple transports with TLS as preferred I assume. > Dunno WHY it should say that; that's what I thought I read in the compound sentence I was trying to straighten out. Hmm. Could it be that since SIPS (draft-ietf-siip-sips) requires e2e TLS even more strongly than did 3261 for original sips URIs. So if a URI used in a record-route resolves both TLS and non-TLS, there's a possibility that the return stroke might not use TLS, thereby breaking the e2e TLS requirement. But your proposed wording change seems to have the same effect. > I would also replace "sips: URI" by "SIPS URI" to be consistent across > the document. > That makes sense; I responded in the wording I thought Robert had used. But consistency with the document would be preferred. Your usage is also consistent with draft-ietf-sip-sips. > Resulting in following updated text: > "When TLS is used on the transport on either side of the proxy, > the URI placed in the Record-Route header field MUST encode > a next-hop that will be reached using TLS. There are two > ways for this to work. The first way is for the URI placed in the > Record-Route to be a SIPS URI.The second is for the URI placed in > the Record-Route to be constructed such that application of > [RFC3263] resolution procedures to that URI results in TLS being > selected. > Proxies compliant with this specification MUST NOT use a > "transport=tls" > > parameter on the URI placed in the Record-Route because the > "transport=tls" usage was deprecated by RFC 3261." > > Can we agree on this text? Looks OK to me. -- Dean From gshaham@juniper.net Fri Aug 14 07:30:38 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C65B03A6AFE for ; Fri, 14 Aug 2009 07:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ofbqLyrC74iJ for ; Fri, 14 Aug 2009 07:30:37 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id 8879C3A6951 for ; Fri, 14 Aug 2009 07:30:37 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKSoV1CcXAbbEKCfnkoDbeMEXM61Mao8oz@postini.com; Fri, 14 Aug 2009 07:30:42 PDT Received: from emailfeemea1.jnpr.net (172.26.192.140) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server id 8.1.375.2; Fri, 14 Aug 2009 07:28:59 -0700 Received: from EMAILEMEA3.jnpr.net ([172.26.192.136]) by emailfeemea1.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 14 Aug 2009 15:28:57 +0100 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, 14 Aug 2009 15:28:53 +0100 Message-ID: <0E48B768805E4D44A70709C8AE09209003AFC4AE@EMAILEMEA3.jnpr.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-ietf-sip-record-route-fix-08 Changes Thread-Index: AcocW1POXnGZ5mj0R7ejDWF2oE9osQAjCzGQ References: <8144761F31F48D43AD53D09F5350E38004C00CE5@FRVELSMBS22.ad2.ad.alcatel.com>A<0D5F89FAC29E2C41B98A6A762007F5D002393EA0@GBNTHT12009MSX.gb002.siemens.net><8144761F31F48D43AD53D09F5350E38004C01534@FRVELSMBS22.ad2.ad.alcatel.com><0D5F89FAC29E2C41B98A6A762007F5D0023D22FA@GBNTHT12009MSX.gb002.siemens.net><8144761F31F48D43AD53D09F5350E38004C6042C@FRVELSMBS22.ad2.ad.alcatel.com><0D5F89FAC29E2C41B98A6A762007F5D0023D2478@GBNTHT12009MSX.gb002.siemens.net><00CBDB5D-5BD3-437E-9369-FDB2587FF039@softarmor.com><8144761F31F48D43AD53D09F5350E38004C60C04@FRVELSMBS22.ad2.ad.alcatel.com> From: Gilad Shaham To: "Dean Willis" , "BONNAERENS Ben" X-OriginalArrivalTime: 14 Aug 2009 14:28:57.0383 (UTC) FILETIME=[8EE64B70:01CA1CEB] Cc: sip@ietf.org Subject: Re: [Sip] draft-ietf-sip-record-route-fix-08 Changes X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 14:30:38 -0000 Hi Ben, I have also read the draft and everything was clear to me and seemed easy to read until I reached 6.1 and 6.2. One suggestion I have to make the text more readable is to separate the problem description from the solution. Meaning today it's: 1. Problem 1 & actions 2. Problem 2 & actions 3. Problem 3 & actions I'm proposing to change it to l. Problem 1 2. Problem 2 3. Problem 3 Describe each problem/scenario without describing the solution and give examples if needed. Following that provide all the recommended actions. Implementers should have an easy way to see and understand all the changes they require to conform to the RFC. For example, In RFC 4320 it's easy to follow through because it describes the changes very simply (the problems are described in more detail in RFC 4321). I'm not suggesting changing this draft into 2 RFCs, just asking to focus on the problems and then focus on the actions. In any case maybe there's a different solution for this and maybe it's just me, but I fear that if the text would not be clear enough then many vendors would have a hard time assessing the effort needed to implement it and thus the adoption rate of this spec would be affected. Final note - section 7 has a summary that may or may not provide all necessary actions, but I simply had a lot to go through in section 6 that I almost never reached section 7. Thanks, Gilad -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Dean Willis Sent: Friday, August 14, 2009 12:12 AM To: BONNAERENS Ben Cc: sip@ietf.org Subject: Re: [Sip] draft-ietf-sip-record-route-fix-08 Changes On Aug 13, 2009, at 6:46 AM, BONNAERENS Ben wrote: > Hello Dean, > > Sorry to make your head hurt ;-) > > To me the -09 sentence was clear but I do think you have a point on =20 > the > compound sentences. > > Still I would like to comment on the "only" in following sentence of =20 > the > text you proposed: > "The second is for the URI placed in the Record-Route to be =20 > constructed > such that application of RFC > 3263 resolution procedures to that URI produces a result reachable =20 > only > using TLS." > > Why should that URI _only_ be reachable via TLS? > The DNS for that URI can be populated with NAPTR records > for multiple transports with TLS as preferred I assume. > Dunno WHY it should say that; that's what I thought I read in the =20 compound sentence I was trying to straighten out. Hmm. Could it be that since SIPS (draft-ietf-siip-sips) requires e2e =20 TLS even more strongly than did 3261 for original sips URIs. So if a =20 URI used in a record-route resolves both TLS and non-TLS, there's a =20 possibility that the return stroke might not use TLS, thereby breaking =20 the e2e TLS requirement. But your proposed wording change seems to =20 have the same effect. > I would also replace "sips: URI" by "SIPS URI" to be consistent across > the document. > That makes sense; I responded in the wording I thought Robert had =20 used. But consistency with the document would be preferred. Your =20 usage is also consistent with draft-ietf-sip-sips. > Resulting in following updated text: > "When TLS is used on the transport on either side of the proxy, > the URI placed in the Record-Route header field MUST encode > a next-hop that will be reached using TLS. There are two > ways for this to work. The first way is for the URI placed in the > Record-Route to be a SIPS URI.The second is for the URI placed in > the Record-Route to be constructed such that application of > [RFC3263] resolution procedures to that URI results in TLS being > selected. > Proxies compliant with this specification MUST NOT use a =20 > "transport=3Dtls" > > parameter on the URI placed in the Record-Route because the > "transport=3Dtls" usage was deprecated by RFC 3261." > > Can we agree on this text? Looks OK to me. -- Dean _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From oej@edvina.net Fri Aug 14 07:31:48 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 101A53A6AA9 for ; Fri, 14 Aug 2009 07:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[AWL=0.340, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oHpgFgQKrzx0 for ; Fri, 14 Aug 2009 07:31:47 -0700 (PDT) Received: from ns.webway.se (ns.webway.se [87.96.134.125]) by core3.amsl.com (Postfix) with ESMTP id 4A5473A6951 for ; Fri, 14 Aug 2009 07:31:46 -0700 (PDT) Received: from [192.168.40.12] (unknown [192.168.40.12]) by ns.webway.se (Postfix) with ESMTP id 4D10D2846E; Fri, 14 Aug 2009 16:06:10 +0200 (CEST) From: "Olle E. Johansson" To: Dean Willis In-Reply-To: References: <8144761F31F48D43AD53D09F5350E38004C00CE5@FRVELSMBS22.ad2.ad.alcatel.com> A <0D5F89FAC29E2C41B98A6A762007F5D002393EA0@GBNTHT12009MSX.gb002.siemens.net> <8144761F31F48D43AD53D09F5350E38004C01534@FRVELSMBS22.ad2.ad.alcatel.com> <0D5F89FAC29E2C41B98A6A762007F5D0023D22FA@GBNTHT12009MSX.gb002.siemens.net> <8144761F31F48D43AD53D09F5350E38004C6042C@FRVELSMBS22.ad2.ad.alcatel.com> <0D5F89FAC29E2C41B98A6A762007F5D0023D2478@GBNTHT12009MSX.gb002.siemens.net> <00CBDB5D-5BD3-437E-9369-FDB2587FF039@softarmor.com> <8144761F31F48D43AD53D09F5350E38004C60C04@FRVELSMBS22.ad2.ad.alcatel.com> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 14 Aug 2009 16:31:48 +0200 X-Mailer: Apple Mail (2.936) Cc: sip@ietf.org, BONNAERENS Ben Subject: Re: [Sip] draft-ietf-sip-record-route-fix-08 Changes X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 14:31:48 -0000 13 aug 2009 kl. 23.12 skrev Dean Willis: > > > Hmm. Could it be that since SIPS (draft-ietf-siip-sips) requires e2e > TLS even more strongly than did 3261 for original sips URIs. So if a > URI used in a record-route resolves both TLS and non-TLS, there's a > possibility that the return stroke might not use TLS, thereby > breaking the e2e TLS requirement. But your proposed wording change > seems to have the same effect. > I did not read the draft as SIPS requiring e2e TLS. We still use proxys and have clear communication within the proxy. E2E to me is UAC -> UAS with encryption ALL the way and no middleman. Did I misunderstand? /O From rjsparks@nostrum.com Fri Aug 14 08:44:53 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7CA83A6C2D for ; Fri, 14 Aug 2009 08:44:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nVLQL7f6hQhs for ; Fri, 14 Aug 2009 08:44:52 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 288F928C0E2 for ; Fri, 14 Aug 2009 08:44:51 -0700 (PDT) Received: from dn3-232.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n7EFiofU051336 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 14 Aug 2009 10:44:50 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-Id: From: Robert Sparks To: Gilad Shaham In-Reply-To: <0E48B768805E4D44A70709C8AE09209003AFC4AE@EMAILEMEA3.jnpr.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 14 Aug 2009 10:44:49 -0500 References: <8144761F31F48D43AD53D09F5350E38004C00CE5@FRVELSMBS22.ad2.ad.alcatel.com>A<0D5F89FAC29E2C41B98A6A762007F5D002393EA0@GBNTHT12009MSX.gb002.siemens.net><8144761F31F48D43AD53D09F5350E38004C01534@FRVELSMBS22.ad2.ad.alcatel.com><0D5F89FAC29E2C41B98A6A762007F5D0023D22FA@GBNTHT12009MSX.gb002.siemens.net><8144761F31F48D43AD53D09F5350E38004C6042C@FRVELSMBS22.ad2.ad.alcatel.com><0D5F89FAC29E2C41B98A6A762007F5D0023D2478@GBNTHT12009MSX.gb002.siemens.net><00CBDB5D-5BD3-437E-9369-FDB2587FF039@softarmor.com><8144761F31F48D43AD53D09F5350E38004C60C04@FRVELSMBS22.ad2.ad.alcatel.com> <0E48B768805E4D44A70709C8AE09209003AFC4AE@EMAILEMEA3.jnpr.net> X-Mailer: Apple Mail (2.936) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: sip@ietf.org, BONNAERENS Ben , Dean Willis Subject: Re: [Sip] draft-ietf-sip-record-route-fix-08 Changes X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 15:44:53 -0000 Hi Gilad - This document is already very far along the process, we are doing fine- tuning based on IESG review and while I truly appreciate insight that will make a document more readable, it would not be appropriate to restructure the text at this time. I hope more reviewers of future documents show the same kind of concern for the implementer you exhibit here. RjS On Aug 14, 2009, at 9:28 AM, Gilad Shaham wrote: > Hi Ben, > > I have also read the draft and everything was clear to me and seemed > easy to read until I reached 6.1 and 6.2. > > One suggestion I have to make the text more readable is to separate > the > problem description from the solution. Meaning today it's: > > 1. Problem 1 & actions > 2. Problem 2 & actions > 3. Problem 3 & actions > > I'm proposing to change it to > l. Problem 1 > 2. Problem 2 > 3. Problem 3 > > Describe each problem/scenario without describing the solution and > give > examples if needed. > > Following that provide all the recommended actions. > > Implementers should have an easy way to see and understand all the > changes they require to conform to the RFC. For example, In RFC 4320 > it's easy to follow through because it describes the changes very > simply > (the problems are described in more detail in RFC 4321). I'm not > suggesting changing this draft into 2 RFCs, just asking to focus on > the > problems and then focus on the actions. > > In any case maybe there's a different solution for this and maybe it's > just me, but I fear that if the text would not be clear enough then > many > vendors would have a hard time assessing the effort needed to > implement > it and thus the adoption rate of this spec would be affected. > > Final note - section 7 has a summary that may or may not provide all > necessary actions, but I simply had a lot to go through in section 6 > that I almost never reached section 7. > > Thanks, > Gilad > > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > Dean Willis > Sent: Friday, August 14, 2009 12:12 AM > To: BONNAERENS Ben > Cc: sip@ietf.org > Subject: Re: [Sip] draft-ietf-sip-record-route-fix-08 Changes > > > On Aug 13, 2009, at 6:46 AM, BONNAERENS Ben wrote: > >> Hello Dean, >> >> Sorry to make your head hurt ;-) >> >> To me the -09 sentence was clear but I do think you have a point on >> the >> compound sentences. >> >> Still I would like to comment on the "only" in following sentence of >> the >> text you proposed: >> "The second is for the URI placed in the Record-Route to be >> constructed >> such that application of RFC >> 3263 resolution procedures to that URI produces a result reachable >> only >> using TLS." >> >> Why should that URI _only_ be reachable via TLS? >> The DNS for that URI can be populated with NAPTR records >> for multiple transports with TLS as preferred I assume. >> > > > Dunno WHY it should say that; that's what I thought I read in the > compound sentence I was trying to straighten out. > > Hmm. Could it be that since SIPS (draft-ietf-siip-sips) requires e2e > TLS even more strongly than did 3261 for original sips URIs. So if a > URI used in a record-route resolves both TLS and non-TLS, there's a > possibility that the return stroke might not use TLS, thereby breaking > the e2e TLS requirement. But your proposed wording change seems to > have the same effect. > > >> I would also replace "sips: URI" by "SIPS URI" to be consistent >> across >> the document. >> > > That makes sense; I responded in the wording I thought Robert had > used. But consistency with the document would be preferred. Your > usage is also consistent with draft-ietf-sip-sips. > >> Resulting in following updated text: >> "When TLS is used on the transport on either side of the proxy, >> the URI placed in the Record-Route header field MUST encode >> a next-hop that will be reached using TLS. There are two >> ways for this to work. The first way is for the URI placed in the >> Record-Route to be a SIPS URI.The second is for the URI placed in >> the Record-Route to be constructed such that application of >> [RFC3263] resolution procedures to that URI results in TLS being >> selected. >> Proxies compliant with this specification MUST NOT use a >> "transport=tls" >> >> parameter on the URI placed in the Record-Route because the >> "transport=tls" usage was deprecated by RFC 3261." >> >> Can we agree on this text? > > > Looks OK to me. > > -- > Dean > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip From root@core3.amsl.com Fri Aug 14 10:15:01 2009 Return-Path: X-Original-To: sip@ietf.org Delivered-To: sip@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 6565C3A6D68; Fri, 14 Aug 2009 10:15:00 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090814171501.6565C3A6D68@core3.amsl.com> Date: Fri, 14 Aug 2009 10:15:01 -0700 (PDT) Cc: sip@ietf.org Subject: [Sip] I-D Action:draft-ietf-sip-record-route-fix-10.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 17:15:01 -0000 --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 : Addressing Record-Route issues in the Session Initiation Protocol (SIP) Author(s) : T. Froment, et al. Filename : draft-ietf-sip-record-route-fix-10.txt Pages : 26 Date : 2009-08-14 A typical function of a Session Initiation Protocol (SIP) Proxy is to insert a Record-Route header into initial, dialog creating requests in order to make subsequent, in-dialog requests pass through it. This header contains a SIP Uniform Resource Identifier (URI) indicating where and how the subsequent requests should be sent to reach the proxy. Like any SIP URI, it can contain SIP or SIPS schemes, IPv4 or IPv6 addresses, and URI parameters that could influence the routing such as the transport parameter (for example transport=tcp), or a compression indication like "comp=sigcomp". When a proxy has to change some of those parameters between its incoming and outgoing interfaces (multi-homed proxies, transport protocol switching or IPv4 to IPv6 scenarios...), the question arises on what should be put in Record-Route header(s). It is not possible to make one header have the characteristics of both interfaces at the same time. This document aims to clarify these scenarios and fix bugs already identified on this topic; it formally recommends the use of the double Record-Route technique as an alternative to the current RFC3261 text, which describes only a Record-Route rewriting solution. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-record-route-fix-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-sip-record-route-fix-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-08-14100936.I-D@ietf.org> --NextPart-- From dean.willis@softarmor.com Sun Aug 16 19:32:22 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 651DE3A6843 for ; Sun, 16 Aug 2009 19:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DWHPEX-WcRBO for ; Sun, 16 Aug 2009 19:32:21 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 7565C3A6930 for ; Sun, 16 Aug 2009 19:32:21 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n7H2WDAK015776 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 16 Aug 2009 21:32:14 -0500 Message-Id: From: Dean Willis To: "Olle E. Johansson" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 16 Aug 2009 21:32:07 -0500 References: <8144761F31F48D43AD53D09F5350E38004C00CE5@FRVELSMBS22.ad2.ad.alcatel.com> A <0D5F89FAC29E2C41B98A6A762007F5D002393EA0@GBNTHT12009MSX.gb002.siemens.net> <8144761F31F48D43AD53D09F5350E38004C01534@FRVELSMBS22.ad2.ad.alcatel.com> <0D5F89FAC29E2C41B98A6A762007F5D0023D22FA@GBNTHT12009MSX.gb002.siemens.net> <8144761F31F48D43AD53D09F5350E38004C6042C@FRVELSMBS22.ad2.ad.alcatel.com> <0D5F89FAC29E2C41B98A6A762007F5D0023D2478@GBNTHT12009MSX.gb002.siemens.net> <00CBDB5D-5BD3-437E-9369-FDB2587FF039@softarmor.com> <8144761F31F48D43AD53D09F5350E38004C60C04@FRVELSMBS22.ad2.ad.alcatel.com> X-Mailer: Apple Mail (2.936) Cc: sip@ietf.org, BONNAERENS Ben Subject: Re: [Sip] draft-ietf-sip-record-route-fix-08 Changes X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 02:32:22 -0000 On Aug 14, 2009, at 9:31 AM, Olle E. Johansson wrote: > > 13 aug 2009 kl. 23.12 skrev Dean Willis: >> >> >> Hmm. Could it be that since SIPS (draft-ietf-siip-sips) requires >> e2e TLS even more strongly than did 3261 for original sips URIs. So >> if a URI used in a record-route resolves both TLS and non-TLS, >> there's a possibility that the return stroke might not use TLS, >> thereby breaking the e2e TLS requirement. But your proposed wording >> change seems to have the same effect. >> > > > I did not read the draft as SIPS requiring e2e TLS. We still use > proxys and have clear communication within the proxy. E2E to me is > UAC -> UAS with encryption ALL the way and no middleman. > > Did I misunderstand? It kind of on what you mean by "end to end". Draft-ietf-sip-sips requires that TLS be used on every hop whenever a SIPS URI is used, whereas RFC 3261 allowed an exemption for the "last hop". In the language of the discussion at the time, this was considered "end to end TLS" even though it wasn't "UA to UA TLS". Under 3261, one could legitimately double record route at a proxy performing contact routing with a first route entry having a SIPS URI and a second having a SIP URI. With draft-ietf-sip-sips, that behavior is forbidden if the result would be to fail to use TLS on the route-segment indicated with a SIPS URI. The record-route-fix document is essentially promoting a very special exception by noting that it is possible to construct a SIP URI such that resolution of the SIP URI using the procedures of RFC 3263 would guarantee that TLS is used, even though the URI itself is SIP instead of SIPS. Consequently, the working I suggested was intended to convey the idea that the "special SIP URI" MUST resolve only to TLS and MUST NOT resolve to a hop that would not use TLS, since the only case in which we RFC 3261 would have allowed us to not use TLS was deprecated by draft-ietf-sip-sips. -- Dean From ranjit@motorola.com Mon Aug 17 00:07:26 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1ABF63A6950; Mon, 17 Aug 2009 00:07:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.109 X-Spam-Level: X-Spam-Status: No, score=-5.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m4M0t9v4hxny; Mon, 17 Aug 2009 00:07:25 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by core3.amsl.com (Postfix) with ESMTP id 0884F3A684F; Mon, 17 Aug 2009 00:07:24 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: ranjit@motorola.com X-Msg-Ref: server-9.tower-119.messagelabs.com!1250492844!33537358!1 X-StarScan-Version: 6.1.3; banners=-,-,- X-Originating-IP: [136.182.1.15] Received: (qmail 671 invoked from network); 17 Aug 2009 07:07:24 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (136.182.1.15) by server-9.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 17 Aug 2009 07:07:24 -0000 Received: from il27exr03.cig.mot.com (il27exr03.mot.com [10.17.196.72]) by motgate5.mot.com (8.14.3/8.14.3) with ESMTP id n7H77N93000451; Mon, 17 Aug 2009 00:07:23 -0700 (MST) Received: from az10vts04.mot.com (il27vts04.cig.mot.com [10.17.196.88]) by il27exr03.cig.mot.com (8.13.1/Vontu) with SMTP id n7H77N1Y014207; Mon, 17 Aug 2009 02:07:23 -0500 (CDT) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il27exr03.cig.mot.com (8.13.1/8.13.0) with ESMTP id n7H77M57014195; Mon, 17 Aug 2009 02:07:22 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA1F09.50BDCE43" Date: Mon, 17 Aug 2009 15:06:59 +0800 Message-ID: <750BBC72E178114F9DC4872EBFF29A5B08A98101@ZMY16EXM66.ds.mot.com> In-Reply-To: <750BBC72E178114F9DC4872EBFF29A5B08434BC0@ZMY16EXM66.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New version of "draft-avasasarala-dispatch-comm-diversion-info" draft submitted Thread-Index: AcoPSGlfXjMN39SUTDiDCIozl/Ik3gPv+k6A References: <750BBC72E178114F9DC4872EBFF29A5B08434BC0@ZMY16EXM66.ds.mot.com> From: "Avasarala Ranjit-A20990" To: , X-CFilter-Loop: Reflected Subject: [Sip] New version of "draft-avasasarala-dispatch-comm-diversion-info" draft submitted X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 07:07:26 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA1F09.50BDCE43 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All=20 We have submitted an updated version of draft-avasasarala-dispatch-comm-diversion-info=20 It can be accessed at: http://www.ietf.org/internet-drafts/draft-avasarala-dispatch-comm-div-no tification-01.txt =20 This draft proposes a SIP Event package for Communication Diversions Notification Information and conforms to procedures and schema described in 3GPP TS 24.604.=20 Please review and comment Regards=20 Ranjit=20 ------_=_NextPart_001_01CA1F09.50BDCE43 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable New version of = "draft-avasasarala-dispatch-comm-diversion-info" draft submitted
Hi All=20

We have submitted an = updated version of=20 draft-avasasarala-dispatch-comm-diversion-info

It can be accessed = at: http://www.ietf.org/internet-drafts/draft-avasarala-dispatch-com= m-div-notification-01.txt

This draft = proposes a SIP=20 Event package for Communication Diversions Notification Information and = conforms=20 to procedures and schema described in 3GPP TS 24.604. 

Please review and=20 comment

Regards
Ranjit

------_=_NextPart_001_01CA1F09.50BDCE43-- From wwwrun@core3.amsl.com Mon Aug 17 11:43:12 2009 Return-Path: X-Original-To: sip@ietf.org Delivered-To: sip@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id A71CA3A6F74; Mon, 17 Aug 2009 11:43:12 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20090817184312.A71CA3A6F74@core3.amsl.com> Date: Mon, 17 Aug 2009 11:43:12 -0700 (PDT) Cc: sip mailing list , sip chair , Internet Architecture Board , RFC Editor Subject: [Sip] Protocol Action: 'An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Diff Event Package' to Proposed Standard X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 18:43:12 -0000 The IESG has approved the following document: - 'An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Diff Event Package ' as a Proposed Standard This document is the product of the Session Initiation Protocol Working Group. The IESG contact persons are Robert Sparks and Cullen Jennings. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-xcapevent-08.txt Technical Summary The XCAP (XML Configuration Access Protocol, RFC 4825) protocol provides for change control on structured data. This specification provides a SIP Event Paackage (RFC 3325) that can be used to monitor changes to an XCAP document. Change notifications may include differential changes expressed using the XCAP-Diff format described in draft-ietf-simple-xcap-diff. This specification also provides for initial synchronization between a stored version of an XCAP document and a remote copy being monitored using the protocol of thsi specification. Working Group Summary This specification developed out of the larger body of configuration management work related to SIP (RFC 3261). In particular, it relates to XCAP (RFC 4825) and the SIP Configuration Framework (draft-ietf-sipping-config-framework). The content of this specification was split off from the configuration framework document about two years ago, and has progressed independently. Document Quality There are existing implementations of earlier versions of the protocol, and a significant number of vendors have committed to implementation of the specification in the context of the Open Mobile Alliances's Push-to-Talk Over Cellularspecification. Adam Roach provided specific guidance and review on the SIP Event Package aspects of this specification. Personnel The Proto Shepherd is Dean Willis. RFC Editor Note (Relevant to version -08) These nits have been identified during /post IESG review: 1) Section 4.4 first paragraph second sentence: OLD: Only a simple subset of that format is required, a flat list of XCAP R-URIs. ^^^^^^ NEW: Only a simple subset of that format is required, a flat list of XCAP request URIs. 2) Section 4.4 last paragraph, last sentence: OLD: ( element) NEW: (where a element is selected) 3) Section 4.7, 5th paragraph, last sentence: OLD: In a corner case, NEW: In a corner case (such as when the XML prolog changes), 4) Section 4.7, 12th paragraph (end of page 10), 3rd sentence: OLD: list of XCAP R-URIs NEW: list of XCAP request URIs 5) Section 4.7, last paragraph, last sentence: (double not) OLD: does not not have ^^^ NEW: does not have 6) Section 5 last paragraph: (Replace with twice) OLD: Note that the resource-list "index" document included only the new ETag value, as the document existed during the subscription time. In the "pidf-manipulation" collection, there is only a single document for which the user has read privilege. The element exists ^ within the rls-services "index" document and its content is shown. Note also that the element was located using the Default ^ Document Namespace (no prefix in XCAP Node Selector value) although it has an "s" prefix in the source document. New: Note that the resource-list "index" document included only the new ETag value, as the document existed during the subscription time. In the "pidf-manipulation" collection, there is only a single document for which the user has read privilege. The element exists within the rls-services "index" document and its content is shown. Note also that the element was located using the Default Document Namespace (no prefix in XCAP Node Selector value) although it has an "s" prefix in the source document. 7) Appendix A - First paragraph: OLD: the SIP R-URIs of NEW: the SIP request URIs of From gshaham@juniper.net Mon Aug 17 17:20:35 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8527B28C1B7; Mon, 17 Aug 2009 17:20:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K9LjhfcMLBih; Mon, 17 Aug 2009 17:20:30 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by core3.amsl.com (Postfix) with ESMTP id 352B03A687B; Mon, 17 Aug 2009 17:20:30 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKSonz0oQP8vKoZImzDWvMuoyA6gOdVEG3@postini.com; Mon, 17 Aug 2009 17:20:35 PDT Received: from emailfeemea1.jnpr.net (172.26.192.140) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server id 8.1.375.2; Mon, 17 Aug 2009 17:20:16 -0700 Received: from EMAILEMEA3.jnpr.net ([172.26.192.136]) by emailfeemea1.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Aug 2009 01:20:14 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA1F99.A7AF652F" Date: Tue, 18 Aug 2009 01:20:10 +0100 Message-ID: <0E48B768805E4D44A70709C8AE09209003AFC6A4@EMAILEMEA3.jnpr.net> In-Reply-To: <750BBC72E178114F9DC4872EBFF29A5B08A98101@ZMY16EXM66.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] New version of"draft-avasasarala-dispatch-comm-diversion-info" draft submitted Thread-Index: AcoPSGlfXjMN39SUTDiDCIozl/Ik3gPv+k6AACM0FAA= References: <750BBC72E178114F9DC4872EBFF29A5B08434BC0@ZMY16EXM66.ds.mot.com> <750BBC72E178114F9DC4872EBFF29A5B08A98101@ZMY16EXM66.ds.mot.com> From: Gilad Shaham To: "Avasarala Ranjit-A20990" , , X-OriginalArrivalTime: 18 Aug 2009 00:20:14.0071 (UTC) FILETIME=[A7E48870:01CA1F99] Subject: Re: [Sip] New version of"draft-avasasarala-dispatch-comm-diversion-info" draft submitted X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 00:20:35 -0000 ------_=_NextPart_001_01CA1F99.A7AF652F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 See some comments =20 Page 5: "... For e.g. the subscriber wanted to diverted all incoming calls to voice-mail, between 3.00 p.m. to 4.00 p.m. Yet, by mistake she configures the time-duration as 3.00 to 4.00 p.m" Some of the sentence needs restructuring and I also don't fully understand the example. Is it AM-PM or wrong field was configured? =20 Page 12: What if time-range is missing? What should be the default? Sounds to me the default should be the current time with no end date. =20 Page 14: In Comm-div-info-selection-criteria there are several disable-* subsections, yet their text describes these element gives the subscriber option of adding information. Shouldn't this be for omitting information or alternatively, call these elements "enable-*" or did I misunderstand the purpose. =20 Page 16: Boss Should be Boss It might be also useful to see an example of periodic request. =20 Page 21: 503 is there, but I don't see 500. Some implementations will avoid 503 and use 500 due to discussion related to this http://tools.ietf.org/html/draft-hilt-sip-correction-503-01 (now expired, but still affected some vendor decisions). I might be able to think of some scenario that involves 502, but I assume this is a result of the diversion implementation itself so maybe that's the context of this discussion. =20 Thanks Gilad =20 ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Avasarala Ranjit-A20990 Sent: Monday, August 17, 2009 10:07 AM To: dispatch@ietf.org; sip@ietf.org Subject: [Sip] New version of"draft-avasasarala-dispatch-comm-diversion-info" draft submitted =20 Hi All=20 We have submitted an updated version of draft-avasasarala-dispatch-comm-diversion-info=20 It can be accessed at: http://www.ietf.org/internet-drafts/draft-avasarala-dispatch-comm-div-no tification-01.txt =20 This draft proposes a SIP Event package for Communication Diversions Notification Information and conforms to procedures and schema described in 3GPP TS 24.604.=20 Please review and comment Regards=20 Ranjit=20 ------_=_NextPart_001_01CA1F99.A7AF652F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable New version of "draft-avasasarala-dispatch-comm-diversion-info" draft = submitted

Hi,

 

See some = comments

 

Page = 5:

   “... For e.g. the =
subscriber wanted to diverted all incoming calls to =
voice-mail,
   between 3.00 p.m. to 4.00 =
p.m.  Yet, by mistake she configures =
the
   time-duration as 3.00 to 4.00 =
p.m”

Some of the sentence needs = restructuring and I also don’t fully understand the example. Is it AM-PM or = wrong field was configured?

 

Page = 12:

What if time-range is missing? What = should be the default? Sounds to me the default should be the current time with = no end date.

 

Page = 14:

In Comm-div-info-selection-criteria = there are several disable-* subsections, yet their text describes these = element gives the subscriber option of adding information. Shouldn’t this be for omitting information or alternatively, call these elements = “enable-*” or did I misunderstand the purpose.

 

Page = 16:

       &nbs=
p;     =
<user-name>Boss</originating-user-name>

Should = be

       &nbs=
p;     =
<user-name>Boss</user-name>

It might be also useful to see an = example of periodic request.

 

Page = 21:

503 is there, but I don’t see = 500. Some implementations will avoid 503 and use 500 due to discussion = related to this http= ://tools.ietf.org/html/draft-hilt-sip-correction-503-01 (now expired, but still affected some vendor decisions). I might be able = to think of some scenario that involves 502, but I assume this is a result = of the diversion implementation itself so maybe that’s the context of = this discussion.

 

Thanks

Gilad

 

From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Avasarala Ranjit-A20990
Sent: Monday, August 17, = 2009 10:07 AM
To: dispatch@ietf.org; sip@ietf.org
Subject: [Sip] New = version of"draft-avasasarala-dispatch-comm-diversion-info" draft = submitted

 

Hi All =

We have submitted an updated version of draft-avasasarala-dispatch-comm-diversion-info =

It can be accessed at: http://www.ietf.org/internet-drafts/draft-avasarala-dispatch-comm= -div-notification-01.txt

This draft proposes a SIP Event package for = Communication Diversions Notification Information and conforms to procedures and = schema described in 3GPP TS 24.604. 

Please review and comment

Regards
Ranjit

------_=_NextPart_001_01CA1F99.A7AF652F-- From manjax@cisco.com Mon Aug 17 23:51:35 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 696103A693D for ; Mon, 17 Aug 2009 23:51:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.989 X-Spam-Level: X-Spam-Status: No, score=-7.989 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, FAKE_REPLY_C=2.012, FH_RELAY_NODNS=1.451, FORGED_MUA_OUTLOOK=3.116, FORGED_OUTLOOK_TAGS=0.001, GB_H_PHARMACY=1, GB_I_LETTER=-2, GB_PHARMACY=1, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RDNS_NONE=0.1, SARE_FROM_DRUGS=1.666, SARE_SUB_INET_PHARM=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4KElfpg8YqZe for ; Mon, 17 Aug 2009 23:51:33 -0700 (PDT) Received: from ba1634ad525a4a7 (unknown [95.71.57.90]) by core3.amsl.com (Postfix) with SMTP id EAAD03A686C for ; Mon, 17 Aug 2009 23:51:31 -0700 (PDT) Message-ID: <20090818135142.2762.qmail@ba1634ad525a4a7> To: sip@ietf.org From: VIAGRA Inc. Date: Tue, 18 Aug 2009 10:51:42 +0300 MIME-Version: 1.0 Content-Type: multipart/related; boundary="@@BOUNDARY" 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 Subject: Re: [Sip] Pharmacy Online Sale 88% OFF! X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: sip@ietf.org List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 06:51:35 -0000 This is a multi-part message in MIME format. --@@BOUNDARY Content-Type: text/html; charset="windows-1251" Content-Transfer-Encoding: 8bit Welcome to WebMD
Welcome to WebMD
• Tue, 18 Aug 2009 10:51:42 +0300
New from WebMD: Dear sip@ietf.org! Sign-up today!

You are subscribed as sip@ietf.org.
View and manage your WebMD newsletter preferences.
Subscribe to more newsletters. Change/update your email address.

WebMD Privacy Policy
WebMD Office of Privacy
1175 Peachtree Street, Suite 2400, Atlanta, GA 30361
© 2009 WebMD, LLC. All rights reserved.
--@@BOUNDARY Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: 8bit New from WebMD: Dear sip@ietf.org!. Sign-up today! You are subscribed as sip@ietf.org. View and manage your WebMD newsletter preferences. Subscribe to more newsletters. Change/update your email address. WebMD Privacy Policy WebMD Office of Privacy 1175 Peachtree Street, Suite 2400, Atlanta, GA 30361 © 2009 WebMD, LLC. All rights reserved. --@@BOUNDARY-- From wwwrun@core3.amsl.com Tue Aug 18 10:47:53 2009 Return-Path: X-Original-To: sip@ietf.org Delivered-To: sip@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 310763A6A13; Tue, 18 Aug 2009 10:47:52 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20090818174753.310763A6A13@core3.amsl.com> Date: Tue, 18 Aug 2009 10:47:53 -0700 (PDT) Cc: sip mailing list , sip chair , Internet Architecture Board , RFC Editor Subject: [Sip] Protocol Action: 'Addressing Record-Route issues in the Session Initiation Protocol (SIP)' to Proposed Standard X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 17:47:53 -0000 The IESG has approved the following document: - 'Addressing Record-Route issues in the Session Initiation Protocol (SIP) ' as a Proposed Standard This document is the product of the Session Initiation Protocol Working Group. The IESG contact persons are Robert Sparks and Cullen Jennings. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-record-route-fix-10.txt Technical Summary Multi-homed SIP proxies (having two or more interfaces) raise special requirements when handling SIP requests that have different ingress and egress interfaces. One technique that has been widely deployed is to insert a single Record-Route header describing the egress interface. When another request in the same dialog then traverses the proxy in a reverse direction, the proxy must edit the headers to reflect the new egress interface. This document formalizes another technique that has also been widely deployed and found to be simpler and more effective. Using this technique, the proxy inserts two record-route headers, one for the ingress interface and one for the egress interface. This keeps the route symmetric, such that it can be traversed in the reverse direction without requiring examination and editing by the proxy, thereby reducing system complexity and processing load in the proxy. Working Group Summary There is very strong consensus around the recommendations in this document. The working group spent significant time debating whether to produce these recommendations as a set of corrections to RFC3261 or as a BCP with the latter result. Document Quality The practices documented here are significantly deployed and have been tested at many interoperability test events. Personnel Nils Ohlmeier is the Document Shepherd. Robert Sparks is the responsible Area Director. From sunil.bhagat@wipro.com Mon Aug 24 02:57:20 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9825B3A6914 for ; Mon, 24 Aug 2009 02:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.206 X-Spam-Level: * X-Spam-Status: No, score=1.206 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZyFOTBCkXTn for ; Mon, 24 Aug 2009 02:57:19 -0700 (PDT) Received: from wipro-blr-out01.wipro.com (wipro-blr-out01.wipro.com [203.91.198.74]) by core3.amsl.com (Postfix) with ESMTP id E68393A6852 for ; Mon, 24 Aug 2009 02:57:18 -0700 (PDT) X-AuditID: cb5bdd57-b7b38ae000004acd-9f-4a926401706c Received: from blr-ec-aa03.wipro.com ( [10.201.18.42]) by (Symantec Mail Security) with SMTP id 64.E8.19149.104629A4; Mon, 24 Aug 2009 15:27:21 +0530 (IST) Received: from blr-ec-bh02.wipro.com ([10.201.50.92]) by blr-ec-aa03.wipro.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 24 Aug 2009 15:27:21 +0530 Received: from BLR-EC-MBX02.wipro.com ([10.201.50.164]) by blr-ec-bh02.wipro.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 24 Aug 2009 15:27:21 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA24A1.45B0BC75" Date: Mon, 24 Aug 2009 15:25:28 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 200 OK response for hold with different media capabilities Thread-Index: AcokoQKQe+mOyhwPSHu8/UnNMvAJ0A== From: To: , , X-OriginalArrivalTime: 24 Aug 2009 09:57:21.0288 (UTC) FILETIME=[45CD0880:01CA24A1] X-Brightmail-Tracker: AAAAAQAAAZE= Subject: [Sip] 200 OK response for hold with different media capabilities X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2009 09:57:20 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA24A1.45B0BC75 Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Hi All, I have a small query related to HOLD request being sent out. For a hold request, can gateway respond with different media capabilities in 200 OK response? Is the HOLD treated as any normal Re-INVITE? Regards, Sunil. Please do not print this email unless it is absolutely necessary. =0A= =0A= The information contained in this electronic message and any attachments to= this message are intended for the exclusive use of the addressee(s) and may= contain proprietary, confidential or privileged information. If you are not= the intended recipient, you should not disseminate, distribute or copy this= e-mail. Please notify the sender immediately and destroy all copies of this= message and any attachments. =0A= =0A= WARNING: Computer viruses can be transmitted via email. The recipient should= check this email and any attachments for the presence of viruses. The compa= ny accepts no liability for any damage caused by any virus transmitted by th= is email. =0A= =0A= www.wipro.com ------_=_NextPart_001_01CA24A1.45B0BC75 Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable

Hi All,

 

I have a small query related to HOLD request being sent o= ut.

 

For a hold request, can gateway respond with different me= dia capabilities in 200 OK response?

 

Is the HOLD treated as any normal Re-INVITE?

 

Regards,

Sunil.

 

Please do not print this email unl= ess it is absolutely necessary.

=0A= =0A= =0A=

The information contained in this electronic message and any attachments= to this message are intended for the exclusive use of the addressee(s) and= may contain proprietary, confidential or privileged information. If you are= not the intended recipient, you should not disseminate, distribute or copy= this e-mail. Please notify the sender immediately and destroy all copies of= this message and any attachments.

=0A= =0A=

WARNING: Computer viruses can be transmitted via email. The recipient sho= uld check this email and any attachments for the presence of viruses. The co= mpany accepts no liability for any damage caused by any virus transmitted by= this email.

=0A=

=0A= www.wipro.com=0A=

------_=_NextPart_001_01CA24A1.45B0BC75-- From sunil.bhagat@wipro.com Mon Aug 24 03:12:22 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 223D93A6D87 for ; Mon, 24 Aug 2009 03:12:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.231 X-Spam-Level: X-Spam-Status: No, score=0.231 tagged_above=-999 required=5 tests=[AWL=0.976, BAYES_20=-0.74, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b0B9ljt69yqw for ; Mon, 24 Aug 2009 03:12:21 -0700 (PDT) Received: from wipro-blr-out01.wipro.com (wipro-blr-out01.wipro.com [203.91.198.74]) by core3.amsl.com (Postfix) with ESMTP id 0C8733A6852 for ; Mon, 24 Aug 2009 03:12:20 -0700 (PDT) X-AuditID: cb5bdd57-b7b38ae000004acd-a0-4a926401cf2c Received: from blr-ec-aa03.wipro.com ( [10.201.18.42]) by (Symantec Mail Security) with SMTP id 74.E8.19149.104629A4; Mon, 24 Aug 2009 15:27:21 +0530 (IST) Received: from blr-ec-bh02.wipro.com ([10.201.50.92]) by blr-ec-aa03.wipro.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 24 Aug 2009 15:27:21 +0530 Received: from BLR-EC-MBX02.wipro.com ([10.201.50.164]) by blr-ec-bh02.wipro.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 24 Aug 2009 15:27:21 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA24A1.45B0BC75" Date: Mon, 24 Aug 2009 15:25:28 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 200 OK response for hold with different media capabilities Thread-Index: AcokoQKQe+mOyhwPSHu8/UnNMvAJ0A== From: To: , , X-OriginalArrivalTime: 24 Aug 2009 09:57:21.0288 (UTC) FILETIME=[45CD0880:01CA24A1] X-Brightmail-Tracker: AAAAAA== Subject: [Sip] 200 OK response for hold with different media capabilities X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2009 10:12:22 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA24A1.45B0BC75 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, =20 I have a small query related to HOLD request being sent out. =20 For a hold request, can gateway respond with different media capabilities in 200 OK response? =20 Is the HOLD treated as any normal Re-INVITE? =20 Regards, Sunil. =20 ------_=_NextPart_001_01CA24A1.45B0BC75 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

 

I have a small query related to HOLD request being = sent out.

 

For a hold request, can gateway respond with = different media capabilities in 200 OK response?

 

Is the HOLD treated as any normal = Re-INVITE?

 

Regards,

Sunil.

 

------_=_NextPart_001_01CA24A1.45B0BC75-- From ranjit@motorola.com Mon Aug 24 04:04:51 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDAA03A6D22 for ; Mon, 24 Aug 2009 04:04:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.854 X-Spam-Level: X-Spam-Status: No, score=-5.854 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AYER+LWP3Xfp for ; Mon, 24 Aug 2009 04:04:50 -0700 (PDT) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with ESMTP id 45C4E3A6E23 for ; Mon, 24 Aug 2009 04:04:20 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: ranjit@motorola.com X-Msg-Ref: server-7.tower-153.messagelabs.com!1251111860!8536132!1 X-StarScan-Version: 6.1.3; banners=-,-,- X-Originating-IP: [136.182.1.15] Received: (qmail 10691 invoked from network); 24 Aug 2009 11:04:21 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (136.182.1.15) by server-7.tower-153.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 24 Aug 2009 11:04:21 -0000 Received: from il27exr04.cig.mot.com ([10.17.196.73]) by motgate5.mot.com (8.14.3/8.14.3) with ESMTP id n7OB4Gl1029238 for ; Mon, 24 Aug 2009 04:04:20 -0700 (MST) Received: from il27vts01 (il27vts01.cig.mot.com [10.17.196.85]) by il27exr04.cig.mot.com (8.13.1/Vontu) with SMTP id n7OB4G6Q019774 for ; Mon, 24 Aug 2009 06:04:16 -0500 (CDT) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il27exr04.cig.mot.com (8.13.1/8.13.0) with ESMTP id n7OB4Drq019755 for ; Mon, 24 Aug 2009 06:04:14 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA24AA.9CB99213" Date: Mon, 24 Aug 2009 19:04:11 +0800 Message-ID: <750BBC72E178114F9DC4872EBFF29A5B08E15FA3@ZMY16EXM66.ds.mot.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] 200 OK response for hold with different media capabilities Thread-Index: AcokoQKQe+mOyhwPSHu8/UnNMvAJ0AACXmGg References: From: "Avasarala Ranjit-A20990" To: , , , X-CFilter-Loop: Reflected Subject: Re: [Sip] 200 OK response for hold with different media capabilities X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2009 11:04:52 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA24AA.9CB99213 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable no it should not. For a Hold request, you do not send any media capabilities. U only change the existing media description lines to indicate HOLD. =20 Regards=20 Ranjit=20 =20 ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of sunil.bhagat@wipro.com Sent: Monday, August 24, 2009 3:25 PM To: sip@ietf.org; sip-implementors@lists.cs.columbia.edu; sip@core3.amsl.com Subject: [Sip] 200 OK response for hold with different media capabilities Hi All, =20 I have a small query related to HOLD request being sent out. =20 For a hold request, can gateway respond with different media capabilities in 200 OK response? =20 Is the HOLD treated as any normal Re-INVITE? =20 Regards, Sunil. =20 Please do not print this email unless it is absolutely necessary.=20 The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments.=20 WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.=20 www.wipro.com=20 ------_=_NextPart_001_01CA24AA.9CB99213 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
no it should not. For a Hold request, you do = not send any=20 media capabilities. U only change the existing media description lines = to=20 indicate HOLD.
 

Regards=20
Ranjit=20

 

From: sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org] On Behalf Of=20 sunil.bhagat@wipro.com
Sent: Monday, August 24, 2009 3:25=20 PM
To: sip@ietf.org; sip-implementors@lists.cs.columbia.edu;=20 sip@core3.amsl.com
Subject: [Sip] 200 OK response for hold = with=20 different media capabilities

Hi = All,

 

I have a small query = related to HOLD=20 request being sent out.

 

For a hold request, can = gateway=20 respond with different media capabilities in 200 OK=20 response?

 

Is the HOLD treated as any = normal=20 Re-INVITE?

 

Regards,

Sunil.

 

Please=20 do not print this email unless it is absolutely necessary. =

The information contained in this electronic message and any = attachments to=20 this message are intended for the exclusive use of the addressee(s) and = may=20 contain proprietary, confidential or privileged information. If you are = not the=20 intended recipient, you should not disseminate, distribute or copy this = e-mail.=20 Please notify the sender immediately and destroy all copies of this = message and=20 any attachments.

WARNING: Computer viruses can be transmitted via email. The recipient = should=20 check this email and any attachments for the presence of viruses. The = company=20 accepts no liability for any damage caused by any virus transmitted by = this=20 email.

www.wipro.com

------_=_NextPart_001_01CA24AA.9CB99213-- From ranjit@motorola.com Mon Aug 24 04:04:52 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0513B3A6E19 for ; Mon, 24 Aug 2009 04:04:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.226 X-Spam-Level: X-Spam-Status: No, score=-6.226 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q7mSa6Rrvc5I for ; Mon, 24 Aug 2009 04:04:51 -0700 (PDT) Received: from mail55.messagelabs.com (mail55.messagelabs.com [216.82.241.163]) by core3.amsl.com (Postfix) with ESMTP id CE9DC3A6E25 for ; Mon, 24 Aug 2009 04:04:31 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: ranjit@motorola.com X-Msg-Ref: server-5.tower-55.messagelabs.com!1251111876!29819397!1 X-StarScan-Version: 6.1.3; banners=-,-,- X-Originating-IP: [136.182.1.15] Received: (qmail 23665 invoked from network); 24 Aug 2009 11:04:36 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (136.182.1.15) by server-5.tower-55.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 24 Aug 2009 11:04:36 -0000 Received: from il27exr03.cig.mot.com (il27exr03.mot.com [10.17.196.72]) by motgate5.mot.com (8.14.3/8.14.3) with ESMTP id n7OB4aW6029313 for ; Mon, 24 Aug 2009 04:04:36 -0700 (MST) Received: from il27vts03 (il27vts03.cig.mot.com [10.17.196.87]) by il27exr03.cig.mot.com (8.13.1/Vontu) with SMTP id n7OB4Zp6024377 for ; Mon, 24 Aug 2009 06:04:35 -0500 (CDT) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il27exr03.cig.mot.com (8.13.1/8.13.0) with ESMTP id n7OB4YGI024362 for ; Mon, 24 Aug 2009 06:04:35 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA24AA.9CB99213" Date: Mon, 24 Aug 2009 19:04:11 +0800 Message-ID: <750BBC72E178114F9DC4872EBFF29A5B08E15FA3@ZMY16EXM66.ds.mot.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] 200 OK response for hold with different media capabilities Thread-Index: AcokoQKQe+mOyhwPSHu8/UnNMvAJ0AACXmGg References: From: "Avasarala Ranjit-A20990" To: , , , X-CFilter-Loop: Reflected Subject: Re: [Sip] 200 OK response for hold with different media capabilities X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2009 11:04:52 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA24AA.9CB99213 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable no it should not. For a Hold request, you do not send any media capabilities. U only change the existing media description lines to indicate HOLD. =20 Regards=20 Ranjit=20 =20 ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of sunil.bhagat@wipro.com Sent: Monday, August 24, 2009 3:25 PM To: sip@ietf.org; sip-implementors@lists.cs.columbia.edu; sip@core3.amsl.com Subject: [Sip] 200 OK response for hold with different media capabilities Hi All, =20 I have a small query related to HOLD request being sent out. =20 For a hold request, can gateway respond with different media capabilities in 200 OK response? =20 Is the HOLD treated as any normal Re-INVITE? =20 Regards, Sunil. =20 Please do not print this email unless it is absolutely necessary.=20 The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments.=20 WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.=20 www.wipro.com=20 ------_=_NextPart_001_01CA24AA.9CB99213 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
no it should not. For a Hold request, you do = not send any=20 media capabilities. U only change the existing media description lines = to=20 indicate HOLD.
 

Regards=20
Ranjit=20

 

From: sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org] On Behalf Of=20 sunil.bhagat@wipro.com
Sent: Monday, August 24, 2009 3:25=20 PM
To: sip@ietf.org; sip-implementors@lists.cs.columbia.edu;=20 sip@core3.amsl.com
Subject: [Sip] 200 OK response for hold = with=20 different media capabilities

Hi = All,

 

I have a small query = related to HOLD=20 request being sent out.

 

For a hold request, can = gateway=20 respond with different media capabilities in 200 OK=20 response?

 

Is the HOLD treated as any = normal=20 Re-INVITE?

 

Regards,

Sunil.

 

Please=20 do not print this email unless it is absolutely necessary. =

The information contained in this electronic message and any = attachments to=20 this message are intended for the exclusive use of the addressee(s) and = may=20 contain proprietary, confidential or privileged information. If you are = not the=20 intended recipient, you should not disseminate, distribute or copy this = e-mail.=20 Please notify the sender immediately and destroy all copies of this = message and=20 any attachments.

WARNING: Computer viruses can be transmitted via email. The recipient = should=20 check this email and any attachments for the presence of viruses. The = company=20 accepts no liability for any damage caused by any virus transmitted by = this=20 email.

www.wipro.com

------_=_NextPart_001_01CA24AA.9CB99213-- From vikram.chhibber@gmail.com Mon Aug 24 11:04:57 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 330C928C231 for ; Mon, 24 Aug 2009 11:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GdO3e3kN1yUX for ; Mon, 24 Aug 2009 11:04:56 -0700 (PDT) Received: from mail-vw0-f186.google.com (mail-vw0-f186.google.com [209.85.212.186]) by core3.amsl.com (Postfix) with ESMTP id 0042028C2FF for ; Mon, 24 Aug 2009 11:04:55 -0700 (PDT) Received: by vws16 with SMTP id 16so2085302vws.1 for ; Mon, 24 Aug 2009 11:05:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=gPPp6Hqai14uYYfhcsViuGA+91+FLL71R4s5Z3+b03g=; b=uhbrpd3jig0n/64CZZxulzNe//HgfJ6aeVY4L88gBmbWCOBdyjfQYZ/ICXj1emoUT7 kenG9aZ+Bifo9n6QtvridLa951DoW+kYcmLdCOa64II4N5JZ/HP8QwNuGXKLeokgCEs5 5xuKGUL6vDmQlgrXjDq64Ajid09t7NsFc4/XY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=IUaoEPz0+TWoSKQ4mttNOTOiw5PAYKhTkOO8JYZ65qazHW6O8AEe9CgI6U6oSUOouh 3cKMT5yM40tK/1yXEzuFFf0w4UeXE65X0GsbAGVREPAZxeTo9WZniW86MYb3KrwRBtaZ VWvZ6sM5+8ocYrLJfdKhLpri9RRVx0TW8zZGc= MIME-Version: 1.0 Received: by 10.220.89.25 with SMTP id c25mr5053215vcm.8.1251137101767; Mon, 24 Aug 2009 11:05:01 -0700 (PDT) In-Reply-To: References: Date: Mon, 24 Aug 2009 11:05:01 -0700 Message-ID: From: Vikram Chhibber To: sunil.bhagat@wipro.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org, sip@core3.amsl.com, sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip] 200 OK response for hold with different media capabilities X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2009 18:04:57 -0000 The gateway can respond with different media capabilities in 200 OK response for offer-less INVITE not for offer that we view as for hold. The gateway should create response as per rules defined in RFC 3264. As far as SIP signalling is concerned, hold INVITE request is treated as a regular re-INVITE request. On Mon, Aug 24, 2009 at 2:55 AM, wrote: > Hi All, > > > > I have a small query related to HOLD request being sent out. > > > > For a hold request, can gateway respond with different media capabilities= in > 200 OK response? > > > > Is the HOLD treated as any normal Re-INVITE? > > > > Regards, > > Sunil. > > > > Please do not print this email unless it is absolutely necessary. > > The information contained in this electronic message and any attachments = to > this message are intended for the exclusive use of the addressee(s) and m= ay > contain proprietary, confidential or privileged information. If you are n= ot > the intended recipient, you should not disseminate, distribute or copy th= is > e-mail. Please notify the sender immediately and destroy all copies of th= is > message and any attachments. > > WARNING: Computer viruses can be transmitted via email. The recipient sho= uld > check this email and any attachments for the presence of viruses. The > company accepts no liability for any damage caused by any virus transmitt= ed > by this email. > > www.wipro.com > > _______________________________________________ > Sip mailing list =A0https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > From vikram.chhibber@gmail.com Mon Aug 24 11:04:59 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AF123A6C24 for ; Mon, 24 Aug 2009 11:04:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hy1-lHZaO6WW for ; Mon, 24 Aug 2009 11:04:59 -0700 (PDT) Received: from mail-vw0-f196.google.com (mail-vw0-f196.google.com [209.85.212.196]) by core3.amsl.com (Postfix) with ESMTP id 9616828C30F for ; Mon, 24 Aug 2009 11:04:58 -0700 (PDT) Received: by vws34 with SMTP id 34so2257306vws.31 for ; Mon, 24 Aug 2009 11:05:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=gPPp6Hqai14uYYfhcsViuGA+91+FLL71R4s5Z3+b03g=; b=uhbrpd3jig0n/64CZZxulzNe//HgfJ6aeVY4L88gBmbWCOBdyjfQYZ/ICXj1emoUT7 kenG9aZ+Bifo9n6QtvridLa951DoW+kYcmLdCOa64II4N5JZ/HP8QwNuGXKLeokgCEs5 5xuKGUL6vDmQlgrXjDq64Ajid09t7NsFc4/XY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=IUaoEPz0+TWoSKQ4mttNOTOiw5PAYKhTkOO8JYZ65qazHW6O8AEe9CgI6U6oSUOouh 3cKMT5yM40tK/1yXEzuFFf0w4UeXE65X0GsbAGVREPAZxeTo9WZniW86MYb3KrwRBtaZ VWvZ6sM5+8ocYrLJfdKhLpri9RRVx0TW8zZGc= MIME-Version: 1.0 Received: by 10.220.89.25 with SMTP id c25mr5053215vcm.8.1251137101767; Mon, 24 Aug 2009 11:05:01 -0700 (PDT) In-Reply-To: References: Date: Mon, 24 Aug 2009 11:05:01 -0700 Message-ID: From: Vikram Chhibber To: sunil.bhagat@wipro.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org, sip@core3.amsl.com, sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip] 200 OK response for hold with different media capabilities X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2009 18:04:59 -0000 The gateway can respond with different media capabilities in 200 OK response for offer-less INVITE not for offer that we view as for hold. The gateway should create response as per rules defined in RFC 3264. As far as SIP signalling is concerned, hold INVITE request is treated as a regular re-INVITE request. On Mon, Aug 24, 2009 at 2:55 AM, wrote: > Hi All, > > > > I have a small query related to HOLD request being sent out. > > > > For a hold request, can gateway respond with different media capabilities= in > 200 OK response? > > > > Is the HOLD treated as any normal Re-INVITE? > > > > Regards, > > Sunil. > > > > Please do not print this email unless it is absolutely necessary. > > The information contained in this electronic message and any attachments = to > this message are intended for the exclusive use of the addressee(s) and m= ay > contain proprietary, confidential or privileged information. If you are n= ot > the intended recipient, you should not disseminate, distribute or copy th= is > e-mail. Please notify the sender immediately and destroy all copies of th= is > message and any attachments. > > WARNING: Computer viruses can be transmitted via email. The recipient sho= uld > check this email and any attachments for the presence of viruses. The > company accepts no liability for any damage caused by any virus transmitt= ed > by this email. > > www.wipro.com > > _______________________________________________ > Sip mailing list =A0https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > From pkyzivat@cisco.com Mon Aug 24 11:45:31 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 732A03A6DFD for ; Mon, 24 Aug 2009 11:45:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.275 X-Spam-Level: X-Spam-Status: No, score=-6.275 tagged_above=-999 required=5 tests=[AWL=0.324, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ayeP0w2V+2e for ; Mon, 24 Aug 2009 11:45:30 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 6CA2A3A6B92 for ; Mon, 24 Aug 2009 11:45:30 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAE98kkqrR7O6/2dsb2JhbADACYg3jlUFhBo X-IronPort-AV: E=Sophos;i="4.44,266,1249257600"; d="scan'208";a="198359726" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 24 Aug 2009 18:36:40 +0000 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 n7OIadIr002974; Mon, 24 Aug 2009 11:36:39 -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.13.8/8.14.3) with ESMTP id n7OIaY7v007372; Mon, 24 Aug 2009 18:36:39 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 24 Aug 2009 14:36:37 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 24 Aug 2009 14:36:36 -0400 Message-ID: <4A92DDB5.90400@cisco.com> Date: Mon, 24 Aug 2009 14:36:37 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Avasarala Ranjit-A20990 References: <750BBC72E178114F9DC4872EBFF29A5B08E15FA3@ZMY16EXM66.ds.mot.com> In-Reply-To: <750BBC72E178114F9DC4872EBFF29A5B08E15FA3@ZMY16EXM66.ds.mot.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Aug 2009 18:36:37.0005 (UTC) FILETIME=[D00E2BD0:01CA24E9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2340; t=1251138999; x=1252002999; 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-implementors]=20[Sip]=20200=20OK=2 0response=20for=20hold=20with=09different=0A=20media=20capab ilities |Sender:=20; bh=iPj4BJ/v9drQKPF20VPIz4mSivYwFwwf24KcK2LaTa4=; b=J9wvDWZwBOStJOYtULRCWNglZh6lzbqxdCe2jlQJaMw0xSOeuOSHHfkbEj 90sZag9df4Kr/O6kVGfHZLfXtu83lu3fSWnYQ5SnV3ONZ6B9spTRRSWhkVNn 9KQYoDUYhF; Authentication-Results: sj-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: sip@ietf.org, sunil.bhagat@wipro.com, sip@core3.amsl.com, sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip] [Sip-implementors] 200 OK response for hold with different media capabilities X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2009 18:45:31 -0000 Avasarala Ranjit-A20990 wrote: > no it should not. For a Hold request, you do not send any media > capabilities. U only change the existing media description lines to > indicate HOLD. I beg to differ. Technically there is no HOLD request. All there is is an offer that offers to change a media attribute, from sendrecv to sendonly or inactive, or from sendonly or recvonly to inactive. The response may change anything that is permitted to be changed in the answer, given the offer. So it may not add m-lines, but it can certainly change media addresses, and within limits may change media formats (codecs). Thanks, Paul > Regards > Ranjit > > > > ________________________________ > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > sunil.bhagat@wipro.com > Sent: Monday, August 24, 2009 3:25 PM > To: sip@ietf.org; sip-implementors@lists.cs.columbia.edu; > sip@core3.amsl.com > Subject: [Sip] 200 OK response for hold with different media > capabilities > > > > Hi All, > > > > I have a small query related to HOLD request being sent out. > > > > For a hold request, can gateway respond with different media > capabilities in 200 OK response? > > > > Is the HOLD treated as any normal Re-INVITE? > > > > Regards, > > Sunil. > > > > Please do not print this email unless it is absolutely necessary. > > The information contained in this electronic message and any attachments > to this message are intended for the exclusive use of the addressee(s) > and may contain proprietary, confidential or privileged information. If > you are not the intended recipient, you should not disseminate, > distribute or copy this e-mail. Please notify the sender immediately and > destroy all copies of this message and any attachments. > > WARNING: Computer viruses can be transmitted via email. The recipient > should check this email and any attachments for the presence of viruses. > The company accepts no liability for any damage caused by any virus > transmitted by this email. > > www.wipro.com > > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > From pkyzivat@cisco.com Mon Aug 24 11:46:31 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35BB528C146 for ; Mon, 24 Aug 2009 11:46:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.275 X-Spam-Level: X-Spam-Status: No, score=-6.275 tagged_above=-999 required=5 tests=[AWL=0.324, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O3IzrkTFN9KK for ; Mon, 24 Aug 2009 11:46:31 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id D02C63A6AE0 for ; Mon, 24 Aug 2009 11:46:30 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAE98kkqrR7O6/2dsb2JhbADACYg3jlUFhBo X-IronPort-AV: E=Sophos;i="4.44,266,1249257600"; d="scan'208";a="198359726" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 24 Aug 2009 18:36:40 +0000 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 n7OIadIr002974; Mon, 24 Aug 2009 11:36:39 -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.13.8/8.14.3) with ESMTP id n7OIaY7v007372; Mon, 24 Aug 2009 18:36:39 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 24 Aug 2009 14:36:37 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 24 Aug 2009 14:36:36 -0400 Message-ID: <4A92DDB5.90400@cisco.com> Date: Mon, 24 Aug 2009 14:36:37 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Avasarala Ranjit-A20990 References: <750BBC72E178114F9DC4872EBFF29A5B08E15FA3@ZMY16EXM66.ds.mot.com> In-Reply-To: <750BBC72E178114F9DC4872EBFF29A5B08E15FA3@ZMY16EXM66.ds.mot.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Aug 2009 18:36:37.0005 (UTC) FILETIME=[D00E2BD0:01CA24E9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2340; t=1251138999; x=1252002999; 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-implementors]=20[Sip]=20200=20OK=2 0response=20for=20hold=20with=09different=0A=20media=20capab ilities |Sender:=20; bh=iPj4BJ/v9drQKPF20VPIz4mSivYwFwwf24KcK2LaTa4=; b=J9wvDWZwBOStJOYtULRCWNglZh6lzbqxdCe2jlQJaMw0xSOeuOSHHfkbEj 90sZag9df4Kr/O6kVGfHZLfXtu83lu3fSWnYQ5SnV3ONZ6B9spTRRSWhkVNn 9KQYoDUYhF; Authentication-Results: sj-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: sip@ietf.org, sunil.bhagat@wipro.com, sip@core3.amsl.com, sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip] [Sip-implementors] 200 OK response for hold with different media capabilities X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2009 18:46:31 -0000 Avasarala Ranjit-A20990 wrote: > no it should not. For a Hold request, you do not send any media > capabilities. U only change the existing media description lines to > indicate HOLD. I beg to differ. Technically there is no HOLD request. All there is is an offer that offers to change a media attribute, from sendrecv to sendonly or inactive, or from sendonly or recvonly to inactive. The response may change anything that is permitted to be changed in the answer, given the offer. So it may not add m-lines, but it can certainly change media addresses, and within limits may change media formats (codecs). Thanks, Paul > Regards > Ranjit > > > > ________________________________ > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > sunil.bhagat@wipro.com > Sent: Monday, August 24, 2009 3:25 PM > To: sip@ietf.org; sip-implementors@lists.cs.columbia.edu; > sip@core3.amsl.com > Subject: [Sip] 200 OK response for hold with different media > capabilities > > > > Hi All, > > > > I have a small query related to HOLD request being sent out. > > > > For a hold request, can gateway respond with different media > capabilities in 200 OK response? > > > > Is the HOLD treated as any normal Re-INVITE? > > > > Regards, > > Sunil. > > > > Please do not print this email unless it is absolutely necessary. > > The information contained in this electronic message and any attachments > to this message are intended for the exclusive use of the addressee(s) > and may contain proprietary, confidential or privileged information. If > you are not the intended recipient, you should not disseminate, > distribute or copy this e-mail. Please notify the sender immediately and > destroy all copies of this message and any attachments. > > WARNING: Computer viruses can be transmitted via email. The recipient > should check this email and any attachments for the presence of viruses. > The company accepts no liability for any damage caused by any virus > transmitted by this email. > > www.wipro.com > > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > From ranjit@motorola.com Mon Aug 24 18:43:08 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED3E03A6E18 for ; Mon, 24 Aug 2009 18:43:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.35 X-Spam-Level: X-Spam-Status: No, score=-6.35 tagged_above=-999 required=5 tests=[AWL=0.249, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3R3NJ02ttH1t for ; Mon, 24 Aug 2009 18:43:07 -0700 (PDT) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with ESMTP id 088D73A6BAA for ; Mon, 24 Aug 2009 18:43:00 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: ranjit@motorola.com X-Msg-Ref: server-13.tower-153.messagelabs.com!1251164578!11418890!1 X-StarScan-Version: 6.1.3; banners=-,-,- X-Originating-IP: [136.182.1.15] Received: (qmail 26984 invoked from network); 25 Aug 2009 01:42:59 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (136.182.1.15) by server-13.tower-153.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 25 Aug 2009 01:42:59 -0000 Received: from il27exr03.cig.mot.com (il27exr03.mot.com [10.17.196.72]) by motgate5.mot.com (8.14.3/8.14.3) with ESMTP id n7P1gwr4014947 for ; Mon, 24 Aug 2009 18:42:58 -0700 (MST) Received: from az10vts04.mot.com (il27vts04.cig.mot.com [10.17.196.88]) by il27exr03.cig.mot.com (8.13.1/Vontu) with SMTP id n7P1gwrx018143 for ; Mon, 24 Aug 2009 20:42:58 -0500 (CDT) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il27exr03.cig.mot.com (8.13.1/8.13.0) with ESMTP id n7P1gunw018128 for ; Mon, 24 Aug 2009 20:42:57 -0500 (CDT) 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: Tue, 25 Aug 2009 09:42:55 +0800 Message-ID: <750BBC72E178114F9DC4872EBFF29A5B08E1606A@ZMY16EXM66.ds.mot.com> In-Reply-To: <4A92DDB5.90400@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip-implementors] [Sip] 200 OK response for hold with different media capabilities Thread-Index: Acok6xd4yF/6A8jXQF+O96O9sLkTEQAObRQg References: <750BBC72E178114F9DC4872EBFF29A5B08E15FA3@ZMY16EXM66.ds.mot.com> <4A92DDB5.90400@cisco.com> From: "Avasarala Ranjit-A20990" To: "Paul Kyzivat" X-CFilter-Loop: Reflected Cc: sip@ietf.org, sunil.bhagat@wipro.com, sip@core3.amsl.com, sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip] [Sip-implementors] 200 OK response for hold with different media capabilities X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2009 01:43:09 -0000 Hi Paul The HOLD request is nothing but a re INVITE request indicating HOLD. Could you give a use case where such a thing may happen? I have not come across any scenario where in the process of putting remote party on HOLD, media parameters like IP/codec getting changed. If this happens, then it cannot be considered a HOLD request. So how do u distinguish a HOLD request from a non HOLD one if in both the cases the media parameters (other than a=3D.....) change? Regards Ranjit -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Sent: Tuesday, August 25, 2009 12:07 AM To: Avasarala Ranjit-A20990 Cc: sunil.bhagat@wipro.com; sip@ietf.org; sip-implementors@lists.cs.columbia.edu; sip@core3.amsl.com Subject: Re: [Sip-implementors] [Sip] 200 OK response for hold with different media capabilities Avasarala Ranjit-A20990 wrote: > no it should not. For a Hold request, you do not send any media=20 > capabilities. U only change the existing media description lines to=20 > indicate HOLD. I beg to differ. Technically there is no HOLD request. All there is is an offer that offers to change a media attribute, from sendrecv to sendonly or inactive, or from sendonly or recvonly to inactive. The response may change anything that is permitted to be changed in the answer, given the offer. So it may not add m-lines, but it can certainly change media addresses, and within limits may change media formats (codecs). Thanks, Paul > Regards > Ranjit >=20 > =20 >=20 > ________________________________ >=20 > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of=20 > sunil.bhagat@wipro.com > Sent: Monday, August 24, 2009 3:25 PM > To: sip@ietf.org; sip-implementors@lists.cs.columbia.edu; > sip@core3.amsl.com > Subject: [Sip] 200 OK response for hold with different media=20 > capabilities >=20 >=20 >=20 > Hi All, >=20 > =20 >=20 > I have a small query related to HOLD request being sent out. >=20 > =20 >=20 > For a hold request, can gateway respond with different media=20 > capabilities in 200 OK response? >=20 > =20 >=20 > Is the HOLD treated as any normal Re-INVITE? >=20 > =20 >=20 > Regards, >=20 > Sunil. >=20 > =20 >=20 > Please do not print this email unless it is absolutely necessary.=20 >=20 > The information contained in this electronic message and any=20 > attachments to this message are intended for the exclusive use of the=20 > addressee(s) and may contain proprietary, confidential or privileged=20 > information. If you are not the intended recipient, you should not=20 > disseminate, distribute or copy this e-mail. Please notify the sender=20 > immediately and destroy all copies of this message and any attachments. >=20 > WARNING: Computer viruses can be transmitted via email. The recipient=20 > should check this email and any attachments for the presence of viruses. > The company accepts no liability for any damage caused by any virus=20 > transmitted by this email. >=20 > www.wipro.com >=20 > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors >=20 From ranjit@motorola.com Mon Aug 24 18:43:15 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F84128C170 for ; Mon, 24 Aug 2009 18:43:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.35 X-Spam-Level: X-Spam-Status: No, score=-6.35 tagged_above=-999 required=5 tests=[AWL=0.249, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J67P-x7se0Xy for ; Mon, 24 Aug 2009 18:43:15 -0700 (PDT) Received: from mail55.messagelabs.com (mail55.messagelabs.com [216.82.241.163]) by core3.amsl.com (Postfix) with ESMTP id BB3203A6DFB for ; Mon, 24 Aug 2009 18:43:14 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: ranjit@motorola.com X-Msg-Ref: server-11.tower-55.messagelabs.com!1251164599!33557619!1 X-StarScan-Version: 6.1.3; banners=-,-,- X-Originating-IP: [136.182.1.14] Received: (qmail 24556 invoked from network); 25 Aug 2009 01:43:20 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (136.182.1.14) by server-11.tower-55.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 25 Aug 2009 01:43:20 -0000 Received: from il27exr04.cig.mot.com (il27exr04.mot.com [10.17.196.73]) by motgate4.mot.com (8.14.3/8.14.3) with ESMTP id n7P1hJ3a004184 for ; Mon, 24 Aug 2009 18:43:19 -0700 (MST) Received: from il27vts01 (il27vts01.cig.mot.com [10.17.196.85]) by il27exr04.cig.mot.com (8.13.1/Vontu) with SMTP id n7P1hJ5M022625 for ; Mon, 24 Aug 2009 20:43:19 -0500 (CDT) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il27exr04.cig.mot.com (8.13.1/8.13.0) with ESMTP id n7P1hHDu022618 for ; Mon, 24 Aug 2009 20:43:18 -0500 (CDT) 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: Tue, 25 Aug 2009 09:42:55 +0800 Message-ID: <750BBC72E178114F9DC4872EBFF29A5B08E1606A@ZMY16EXM66.ds.mot.com> In-Reply-To: <4A92DDB5.90400@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip-implementors] [Sip] 200 OK response for hold with different media capabilities Thread-Index: Acok6xd4yF/6A8jXQF+O96O9sLkTEQAObRQg References: <750BBC72E178114F9DC4872EBFF29A5B08E15FA3@ZMY16EXM66.ds.mot.com> <4A92DDB5.90400@cisco.com> From: "Avasarala Ranjit-A20990" To: "Paul Kyzivat" X-CFilter-Loop: Reflected Cc: sip@ietf.org, sunil.bhagat@wipro.com, sip@core3.amsl.com, sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip] [Sip-implementors] 200 OK response for hold with different media capabilities X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2009 01:43:15 -0000 Hi Paul The HOLD request is nothing but a re INVITE request indicating HOLD. Could you give a use case where such a thing may happen? I have not come across any scenario where in the process of putting remote party on HOLD, media parameters like IP/codec getting changed. If this happens, then it cannot be considered a HOLD request. So how do u distinguish a HOLD request from a non HOLD one if in both the cases the media parameters (other than a=3D.....) change? Regards Ranjit -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Sent: Tuesday, August 25, 2009 12:07 AM To: Avasarala Ranjit-A20990 Cc: sunil.bhagat@wipro.com; sip@ietf.org; sip-implementors@lists.cs.columbia.edu; sip@core3.amsl.com Subject: Re: [Sip-implementors] [Sip] 200 OK response for hold with different media capabilities Avasarala Ranjit-A20990 wrote: > no it should not. For a Hold request, you do not send any media=20 > capabilities. U only change the existing media description lines to=20 > indicate HOLD. I beg to differ. Technically there is no HOLD request. All there is is an offer that offers to change a media attribute, from sendrecv to sendonly or inactive, or from sendonly or recvonly to inactive. The response may change anything that is permitted to be changed in the answer, given the offer. So it may not add m-lines, but it can certainly change media addresses, and within limits may change media formats (codecs). Thanks, Paul > Regards > Ranjit >=20 > =20 >=20 > ________________________________ >=20 > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of=20 > sunil.bhagat@wipro.com > Sent: Monday, August 24, 2009 3:25 PM > To: sip@ietf.org; sip-implementors@lists.cs.columbia.edu; > sip@core3.amsl.com > Subject: [Sip] 200 OK response for hold with different media=20 > capabilities >=20 >=20 >=20 > Hi All, >=20 > =20 >=20 > I have a small query related to HOLD request being sent out. >=20 > =20 >=20 > For a hold request, can gateway respond with different media=20 > capabilities in 200 OK response? >=20 > =20 >=20 > Is the HOLD treated as any normal Re-INVITE? >=20 > =20 >=20 > Regards, >=20 > Sunil. >=20 > =20 >=20 > Please do not print this email unless it is absolutely necessary.=20 >=20 > The information contained in this electronic message and any=20 > attachments to this message are intended for the exclusive use of the=20 > addressee(s) and may contain proprietary, confidential or privileged=20 > information. If you are not the intended recipient, you should not=20 > disseminate, distribute or copy this e-mail. Please notify the sender=20 > immediately and destroy all copies of this message and any attachments. >=20 > WARNING: Computer viruses can be transmitted via email. The recipient=20 > should check this email and any attachments for the presence of viruses. > The company accepts no liability for any damage caused by any virus=20 > transmitted by this email. >=20 > www.wipro.com >=20 > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors >=20 From ranjit@motorola.com Mon Aug 24 18:44:57 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F16E228C3B0 for ; Mon, 24 Aug 2009 18:44:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.412 X-Spam-Level: X-Spam-Status: No, score=-6.412 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zuMFa5T46Wvp for ; Mon, 24 Aug 2009 18:44:56 -0700 (PDT) Received: from mail55.messagelabs.com (mail55.messagelabs.com [216.82.241.163]) by core3.amsl.com (Postfix) with ESMTP id D4B1728C3FB for ; Mon, 24 Aug 2009 18:44:18 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: ranjit@motorola.com X-Msg-Ref: server-3.tower-55.messagelabs.com!1251164663!9982255!1 X-StarScan-Version: 6.1.3; banners=-,-,- X-Originating-IP: [136.182.1.13] Received: (qmail 25374 invoked from network); 25 Aug 2009 01:44:24 -0000 Received: from motgate3.mot.com (HELO motgate3.mot.com) (136.182.1.13) by server-3.tower-55.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 25 Aug 2009 01:44:24 -0000 Received: from il27exr03.cig.mot.com (il27exr03.mot.com [10.17.196.72]) by motgate3.mot.com (8.14.3/8.14.3) with ESMTP id n7P1iNRF021596 for ; Mon, 24 Aug 2009 18:44:23 -0700 (MST) Received: from il27vts02.mot.com (il27vts02.cig.mot.com [10.17.196.86]) by il27exr03.cig.mot.com (8.13.1/Vontu) with SMTP id n7P1iNZa018963 for ; Mon, 24 Aug 2009 20:44:23 -0500 (CDT) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il27exr03.cig.mot.com (8.13.1/8.13.0) with ESMTP id n7P1iLuY018949 for ; Mon, 24 Aug 2009 20:44:22 -0500 (CDT) 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: Tue, 25 Aug 2009 09:44:21 +0800 Message-ID: <750BBC72E178114F9DC4872EBFF29A5B08E1606E@ZMY16EXM66.ds.mot.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip-implementors] [Sip] 200 OK response for hold withdifferent media capabilities Thread-Index: Acok5XgHSk7UVCwhRUyrUgb7PhkzcAAP/jGw References: From: "Avasarala Ranjit-A20990" To: "Vikram Chhibber" , X-CFilter-Loop: Reflected Cc: sip@ietf.org, sip@core3.amsl.com, sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip] [Sip-implementors] 200 OK response for hold withdifferent media capabilities X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2009 01:44:57 -0000 Hi Vikram Gateway can respond with media capabilities to a offer less INVITE if it = is acting as a 3PCC, not otherwise. =20 Regards Ranjit -----Original Message----- From: sip-implementors-bounces@lists.cs.columbia.edu = [mailto:sip-implementors-bounces@lists.cs.columbia.edu] On Behalf Of = Vikram Chhibber Sent: Monday, August 24, 2009 11:35 PM To: sunil.bhagat@wipro.com Cc: sip@ietf.org; sip@core3.amsl.com; = sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] [Sip] 200 OK response for hold = withdifferent media capabilities The gateway can respond with different media capabilities in 200 OK = response for offer-less INVITE not for offer that we view as for hold. The gateway should create response as per rules defined in RFC 3264. As far as SIP signalling is concerned, hold INVITE request is treated as = a regular re-INVITE request. On Mon, Aug 24, 2009 at 2:55 AM, wrote: > Hi All, > > > > I have a small query related to HOLD request being sent out. > > > > For a hold request, can gateway respond with different media=20 > capabilities in 200 OK response? > > > > Is the HOLD treated as any normal Re-INVITE? > > > > Regards, > > Sunil. > > > > Please do not print this email unless it is absolutely necessary. > > The information contained in this electronic message and any=20 > attachments to this message are intended for the exclusive use of the=20 > addressee(s) and may contain proprietary, confidential or privileged=20 > information. If you are not the intended recipient, you should not=20 > disseminate, distribute or copy this e-mail. Please notify the sender=20 > immediately and destroy all copies of this message and any = attachments. > > WARNING: Computer viruses can be transmitted via email. The recipient=20 > should check this email and any attachments for the presence of=20 > viruses. The company accepts no liability for any damage caused by any = > virus transmitted by this email. > > www.wipro.com > > _______________________________________________ > Sip mailing list =A0https://www.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-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors From ranjit@motorola.com Mon Aug 24 18:44:57 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A62B528C3D5 for ; Mon, 24 Aug 2009 18:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.412 X-Spam-Level: X-Spam-Status: No, score=-6.412 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RRREn4iDklTK for ; Mon, 24 Aug 2009 18:44:57 -0700 (PDT) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with ESMTP id C6BA13A6EB9 for ; Mon, 24 Aug 2009 18:44:39 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: ranjit@motorola.com X-Msg-Ref: server-5.tower-128.messagelabs.com!1251164685!7766175!1 X-StarScan-Version: 6.1.3; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 30714 invoked from network); 25 Aug 2009 01:44:45 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-5.tower-128.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 25 Aug 2009 01:44:45 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.14.3/8.14.3) with ESMTP id n7P1iiCx021531 for ; Mon, 24 Aug 2009 18:44:44 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id n7P1iiFQ000034 for ; Mon, 24 Aug 2009 20:44:44 -0500 (CDT) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id n7P1igka000028 for ; Mon, 24 Aug 2009 20:44:43 -0500 (CDT) 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: Tue, 25 Aug 2009 09:44:21 +0800 Message-ID: <750BBC72E178114F9DC4872EBFF29A5B08E1606E@ZMY16EXM66.ds.mot.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip-implementors] [Sip] 200 OK response for hold withdifferent media capabilities Thread-Index: Acok5XgHSk7UVCwhRUyrUgb7PhkzcAAP/jGw References: From: "Avasarala Ranjit-A20990" To: "Vikram Chhibber" , X-CFilter-Loop: Reflected Cc: sip@ietf.org, sip@core3.amsl.com, sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip] [Sip-implementors] 200 OK response for hold withdifferent media capabilities X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2009 01:44:57 -0000 Hi Vikram Gateway can respond with media capabilities to a offer less INVITE if it = is acting as a 3PCC, not otherwise. =20 Regards Ranjit -----Original Message----- From: sip-implementors-bounces@lists.cs.columbia.edu = [mailto:sip-implementors-bounces@lists.cs.columbia.edu] On Behalf Of = Vikram Chhibber Sent: Monday, August 24, 2009 11:35 PM To: sunil.bhagat@wipro.com Cc: sip@ietf.org; sip@core3.amsl.com; = sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] [Sip] 200 OK response for hold = withdifferent media capabilities The gateway can respond with different media capabilities in 200 OK = response for offer-less INVITE not for offer that we view as for hold. The gateway should create response as per rules defined in RFC 3264. As far as SIP signalling is concerned, hold INVITE request is treated as = a regular re-INVITE request. On Mon, Aug 24, 2009 at 2:55 AM, wrote: > Hi All, > > > > I have a small query related to HOLD request being sent out. > > > > For a hold request, can gateway respond with different media=20 > capabilities in 200 OK response? > > > > Is the HOLD treated as any normal Re-INVITE? > > > > Regards, > > Sunil. > > > > Please do not print this email unless it is absolutely necessary. > > The information contained in this electronic message and any=20 > attachments to this message are intended for the exclusive use of the=20 > addressee(s) and may contain proprietary, confidential or privileged=20 > information. If you are not the intended recipient, you should not=20 > disseminate, distribute or copy this e-mail. Please notify the sender=20 > immediately and destroy all copies of this message and any = attachments. > > WARNING: Computer viruses can be transmitted via email. The recipient=20 > should check this email and any attachments for the presence of=20 > viruses. The company accepts no liability for any damage caused by any = > virus transmitted by this email. > > www.wipro.com > > _______________________________________________ > Sip mailing list =A0https://www.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-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors From abhatnagar192006@gmail.com Mon Aug 24 19:53:16 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE1793A6ECA for ; Mon, 24 Aug 2009 19:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.299, BAYES_00=-2.599, J_CHICKENPOX_75=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yeZj64burnRJ for ; Mon, 24 Aug 2009 19:53:15 -0700 (PDT) Received: from mail-yw0-f172.google.com (mail-yw0-f172.google.com [209.85.211.172]) by core3.amsl.com (Postfix) with ESMTP id 937D63A6862 for ; Mon, 24 Aug 2009 19:53:15 -0700 (PDT) Received: by ywh2 with SMTP id 2so6655523ywh.2 for ; Mon, 24 Aug 2009 19:53:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=RBQ3rVknttAcVmOS0+bSdR28kOF6BoeAtmaOz8OgZLQ=; b=avQ8AWe6M7hWXuywZPTaNi1++kGT3kmrzWs5XKFZE6IkOd+K06u4My9MNvifDByRlF xtE2dOvooj3576h4BAoE5zx94/zDNdejdw//4LBpG3DYe8vJbJLBc0bj5AexY9KNFLse 4AkBSezkLB21+oNxt799KyS6aRx7lMjR3nqc4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=RmNa+5pUACWVds41ixD86C5q1t9GK8aBTGJL8QBfpY27WbHqauG/pL8rsdRZrcLQUq tQj/EgFB+/iYCERR3NRan8rtuw/fzAuTgWghhJhJRunJbc8gZ01qGotRqdbI5thQf/wp ZjDpaQ2YV1QO9G2nY4ObfArLAGSkMkrQbvBX0= MIME-Version: 1.0 Received: by 10.101.113.6 with SMTP id q6mr5436243anm.179.1251168801384; Mon, 24 Aug 2009 19:53:21 -0700 (PDT) In-Reply-To: <750BBC72E178114F9DC4872EBFF29A5B08E1606E@ZMY16EXM66.ds.mot.com> References: <750BBC72E178114F9DC4872EBFF29A5B08E1606E@ZMY16EXM66.ds.mot.com> Date: Tue, 25 Aug 2009 02:53:21 +0000 Message-ID: From: aayush bhatnagar To: Avasarala Ranjit-A20990 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org, sunil.bhagat@wipro.com, sip@core3.amsl.com, sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip] [Sip-implementors] 200 OK response for hold withdifferent media capabilities X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2009 02:53:16 -0000 Once the media streams(which are encoded in a set of codecs negotiated earlier) have requested to be put on hold, then the answer should not try to change any media attributes or codecs (that were negotiated earlier). By providing a different codec set in response to a HOLD request would be equavalent to modifing the media characteristics of the current session, not putting the media on hold. On 25/08/2009, Avasarala Ranjit-A20990 wrote: > Hi Vikram > > Gateway can respond with media capabilities to a offer less INVITE if it = is > acting as a 3PCC, not otherwise. > > > Regards > Ranjit > > -----Original Message----- > From: sip-implementors-bounces@lists.cs.columbia.edu > [mailto:sip-implementors-bounces@lists.cs.columbia.edu] On Behalf Of Vikr= am > Chhibber > Sent: Monday, August 24, 2009 11:35 PM > To: sunil.bhagat@wipro.com > Cc: sip@ietf.org; sip@core3.amsl.com; sip-implementors@lists.cs.columbia.= edu > Subject: Re: [Sip-implementors] [Sip] 200 OK response for hold withdiffer= ent > media capabilities > > The gateway can respond with different media capabilities in 200 OK respo= nse > for offer-less INVITE not for offer that we view as for hold. > The gateway should create response as per rules defined in RFC 3264. > As far as SIP signalling is concerned, hold INVITE request is treated as = a > regular re-INVITE request. > > On Mon, Aug 24, 2009 at 2:55 AM, wrote: >> Hi All, >> >> >> >> I have a small query related to HOLD request being sent out. >> >> >> >> For a hold request, can gateway respond with different media >> capabilities in 200 OK response? >> >> >> >> Is the HOLD treated as any normal Re-INVITE? >> >> >> >> Regards, >> >> Sunil. >> >> >> >> Please do not print this email unless it is absolutely necessary. >> >> The information contained in this electronic message and any >> attachments to this message are intended for the exclusive use of the >> addressee(s) and may contain proprietary, confidential or privileged >> information. If you are not the intended recipient, you should not >> disseminate, distribute or copy this e-mail. Please notify the sender >> immediately and destroy all copies of this message and any attachments. >> >> WARNING: Computer viruses can be transmitted via email. The recipient >> should check this email and any attachments for the presence of >> viruses. The company accepts no liability for any damage caused by any >> virus transmitted by this email. >> >> www.wipro.com >> >> _______________________________________________ >> Sip mailing list =A0https://www.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP 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-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 aayush ---------------------------------------------------- "A philosopher always knows what to do...until it happens to him" From abhatnagar192006@gmail.com Mon Aug 24 19:53:18 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80EB328C3E9 for ; Mon, 24 Aug 2009 19:53:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.299, BAYES_00=-2.599, J_CHICKENPOX_75=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4W2FuURLkSVx for ; Mon, 24 Aug 2009 19:53:18 -0700 (PDT) Received: from mail-yw0-f174.google.com (mail-yw0-f174.google.com [209.85.211.174]) by core3.amsl.com (Postfix) with ESMTP id 3AC6128C3BA for ; Mon, 24 Aug 2009 19:53:18 -0700 (PDT) Received: by ywh4 with SMTP id 4so4027636ywh.17 for ; Mon, 24 Aug 2009 19:53:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=RBQ3rVknttAcVmOS0+bSdR28kOF6BoeAtmaOz8OgZLQ=; b=avQ8AWe6M7hWXuywZPTaNi1++kGT3kmrzWs5XKFZE6IkOd+K06u4My9MNvifDByRlF xtE2dOvooj3576h4BAoE5zx94/zDNdejdw//4LBpG3DYe8vJbJLBc0bj5AexY9KNFLse 4AkBSezkLB21+oNxt799KyS6aRx7lMjR3nqc4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=RmNa+5pUACWVds41ixD86C5q1t9GK8aBTGJL8QBfpY27WbHqauG/pL8rsdRZrcLQUq tQj/EgFB+/iYCERR3NRan8rtuw/fzAuTgWghhJhJRunJbc8gZ01qGotRqdbI5thQf/wp ZjDpaQ2YV1QO9G2nY4ObfArLAGSkMkrQbvBX0= MIME-Version: 1.0 Received: by 10.101.113.6 with SMTP id q6mr5436243anm.179.1251168801384; Mon, 24 Aug 2009 19:53:21 -0700 (PDT) In-Reply-To: <750BBC72E178114F9DC4872EBFF29A5B08E1606E@ZMY16EXM66.ds.mot.com> References: <750BBC72E178114F9DC4872EBFF29A5B08E1606E@ZMY16EXM66.ds.mot.com> Date: Tue, 25 Aug 2009 02:53:21 +0000 Message-ID: From: aayush bhatnagar To: Avasarala Ranjit-A20990 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org, sunil.bhagat@wipro.com, sip@core3.amsl.com, sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip] [Sip-implementors] 200 OK response for hold withdifferent media capabilities X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2009 02:53:18 -0000 Once the media streams(which are encoded in a set of codecs negotiated earlier) have requested to be put on hold, then the answer should not try to change any media attributes or codecs (that were negotiated earlier). By providing a different codec set in response to a HOLD request would be equavalent to modifing the media characteristics of the current session, not putting the media on hold. On 25/08/2009, Avasarala Ranjit-A20990 wrote: > Hi Vikram > > Gateway can respond with media capabilities to a offer less INVITE if it = is > acting as a 3PCC, not otherwise. > > > Regards > Ranjit > > -----Original Message----- > From: sip-implementors-bounces@lists.cs.columbia.edu > [mailto:sip-implementors-bounces@lists.cs.columbia.edu] On Behalf Of Vikr= am > Chhibber > Sent: Monday, August 24, 2009 11:35 PM > To: sunil.bhagat@wipro.com > Cc: sip@ietf.org; sip@core3.amsl.com; sip-implementors@lists.cs.columbia.= edu > Subject: Re: [Sip-implementors] [Sip] 200 OK response for hold withdiffer= ent > media capabilities > > The gateway can respond with different media capabilities in 200 OK respo= nse > for offer-less INVITE not for offer that we view as for hold. > The gateway should create response as per rules defined in RFC 3264. > As far as SIP signalling is concerned, hold INVITE request is treated as = a > regular re-INVITE request. > > On Mon, Aug 24, 2009 at 2:55 AM, wrote: >> Hi All, >> >> >> >> I have a small query related to HOLD request being sent out. >> >> >> >> For a hold request, can gateway respond with different media >> capabilities in 200 OK response? >> >> >> >> Is the HOLD treated as any normal Re-INVITE? >> >> >> >> Regards, >> >> Sunil. >> >> >> >> Please do not print this email unless it is absolutely necessary. >> >> The information contained in this electronic message and any >> attachments to this message are intended for the exclusive use of the >> addressee(s) and may contain proprietary, confidential or privileged >> information. If you are not the intended recipient, you should not >> disseminate, distribute or copy this e-mail. Please notify the sender >> immediately and destroy all copies of this message and any attachments. >> >> WARNING: Computer viruses can be transmitted via email. The recipient >> should check this email and any attachments for the presence of >> viruses. The company accepts no liability for any damage caused by any >> virus transmitted by this email. >> >> www.wipro.com >> >> _______________________________________________ >> Sip mailing list =A0https://www.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP 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-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 aayush ---------------------------------------------------- "A philosopher always knows what to do...until it happens to him" From vikram.chhibber@gmail.com Mon Aug 24 20:59:56 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CC7C28C25C for ; Mon, 24 Aug 2009 20:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5a0C5q5IdaKo for ; Mon, 24 Aug 2009 20:59:54 -0700 (PDT) Received: from mail-vw0-f196.google.com (mail-vw0-f196.google.com [209.85.212.196]) by core3.amsl.com (Postfix) with ESMTP id 8774128C424 for ; Mon, 24 Aug 2009 20:59:46 -0700 (PDT) Received: by vws34 with SMTP id 34so2596010vws.31 for ; Mon, 24 Aug 2009 20:59:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=UEc+l48tAdLGvXsTE3M0FboRjow7EvwDextkekALsRQ=; b=elVlilibsCzRveLp1v/qS8JALgd1xC4Ggm+xB2Mxl1FpXw+59hTfoABubmYJHcZcKr raUfRBAW7ia+Q0H+VCQnBkougJUAxG6ZyzXxKTLKFb7lhz5ew/kOgybgwWIY9+Z2Illd tNs1NFhgB+dFUL0G1SrvvWQwGcFKjuTBBRXNU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=rwlQ7eZ8ZOui/TkbZRuBlIkP+ry0DWK4OE3uAP7ffS/bVz3Fiq5lHrDhkCINxvtyYx qfC5WPYiocddXjVY36dKvzAfkagKp4K32G8Ynnca1Hdb+jyEEbGHRltQurS5E838veZl zIlFGpRNmCnBnGGSrZ05IhvopcauUyQ0YuXhs= MIME-Version: 1.0 Received: by 10.220.68.226 with SMTP id w34mr7200636vci.116.1251172789806; Mon, 24 Aug 2009 20:59:49 -0700 (PDT) In-Reply-To: <750BBC72E178114F9DC4872EBFF29A5B08E1606E@ZMY16EXM66.ds.mot.com> References: <750BBC72E178114F9DC4872EBFF29A5B08E1606E@ZMY16EXM66.ds.mot.com> Date: Mon, 24 Aug 2009 20:59:49 -0700 Message-ID: From: Vikram Chhibber To: Avasarala Ranjit-A20990 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org, sunil.bhagat@wipro.com, sip@core3.amsl.com, sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip] [Sip-implementors] 200 OK response for hold withdifferent media capabilities X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2009 03:59:56 -0000 On Mon, Aug 24, 2009 at 6:44 PM, Avasarala Ranjit-A20990 wrote: > Hi Vikram > > Gateway can respond with media capabilities to a offer less INVITE if it = is acting as a 3PCC, not otherwise. > This is exactly what I wrote in my mail. I would again emphasize Paul=92s comment. =93Hold=94 is application=92s interpretation of some values in SDP such as offer with a =3D sendonly/inactive. There is no such SDP called as hold SDP. Furthermore, this offer should be processed as a normal offer as there could be a change in IP/port, codecs or codecs attributes. > > Regards > Ranjit > > -----Original Message----- > From: sip-implementors-bounces@lists.cs.columbia.edu [mailto:sip-implemen= tors-bounces@lists.cs.columbia.edu] On Behalf Of Vikram Chhibber > Sent: Monday, August 24, 2009 11:35 PM > To: sunil.bhagat@wipro.com > Cc: sip@ietf.org; sip@core3.amsl.com; sip-implementors@lists.cs.columbia.= edu > Subject: Re: [Sip-implementors] [Sip] 200 OK response for hold withdiffer= ent media capabilities > > The gateway can respond with different media capabilities in 200 OK respo= nse for offer-less INVITE not for offer that we view as for hold. > The gateway should create response as per rules defined in RFC 3264. > As far as SIP signalling is concerned, hold INVITE request is treated as = a regular re-INVITE request. > > On Mon, Aug 24, 2009 at 2:55 AM, wrote: >> Hi All, >> >> >> >> I have a small query related to HOLD request being sent out. >> >> >> >> For a hold request, can gateway respond with different media >> capabilities in 200 OK response? >> >> >> >> Is the HOLD treated as any normal Re-INVITE? >> >> >> >> Regards, >> >> Sunil. >> >> >> >> Please do not print this email unless it is absolutely necessary. >> >> The information contained in this electronic message and any >> attachments to this message are intended for the exclusive use of the >> addressee(s) and may contain proprietary, confidential or privileged >> information. If you are not the intended recipient, you should not >> disseminate, distribute or copy this e-mail. Please notify the sender >> immediately and destroy all copies of this message and any attachments. >> >> WARNING: Computer viruses can be transmitted via email. The recipient >> should check this email and any attachments for the presence of >> viruses. The company accepts no liability for any damage caused by any >> virus transmitted by this email. >> >> www.wipro.com >> >> _______________________________________________ >> Sip mailing list =A0https://www.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP 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-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > From vikram.chhibber@gmail.com Mon Aug 24 21:03:13 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B820E3A6875 for ; Mon, 24 Aug 2009 21:03:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tmn9nJ7HGANl for ; Mon, 24 Aug 2009 21:03:12 -0700 (PDT) Received: from mail-vw0-f186.google.com (mail-vw0-f186.google.com [209.85.212.186]) by core3.amsl.com (Postfix) with ESMTP id 5E26D3A6E03 for ; Mon, 24 Aug 2009 21:03:12 -0700 (PDT) Received: by vws16 with SMTP id 16so2406380vws.1 for ; Mon, 24 Aug 2009 21:03:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=0xFpeI8KGDDuxzbTQfFwyN883nGoL02XZJaUwIOhGe8=; b=DMsrwl+nzMfUCOEKP/nGgPes+q8rDomKEd6pXZtq5REcO1rq7shIq5e/3CZY66QpRr B85dBpCoFroxiSvN95XPczdoZ4NHNsPvCKzscYklSqJxK/lgQYgE2I5RDEEozRDNfsFu MaLcR1AalKJEVC8d3CcatbggRl2Zm8FDQZmso= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=MiSBQN/CYLaX+jf+64tYncs+oZuMxqlGTnu9caEGacAxZMazmBy5cHIaV6+m97bzSS tndHvES54iZVODbrdjOhskDnuDK1IoiBkK50ZclZfSyqY25p9TpOq17USLr+w2DxWAcy CpGwlxy+gURb8UR6ZcBhZeYKIgsEqKtfynnaU= MIME-Version: 1.0 Received: by 10.220.105.149 with SMTP id t21mr6988598vco.34.1251172998062; Mon, 24 Aug 2009 21:03:18 -0700 (PDT) In-Reply-To: References: <750BBC72E178114F9DC4872EBFF29A5B08E1606E@ZMY16EXM66.ds.mot.com> Date: Mon, 24 Aug 2009 21:03:17 -0700 Message-ID: From: Vikram Chhibber To: Avasarala Ranjit-A20990 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org, sunil.bhagat@wipro.com, sip@core3.amsl.com, sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip] [Sip-implementors] 200 OK response for hold withdifferent media capabilities X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2009 04:03:13 -0000 >> Gateway can respond with media capabilities to a offer less INVITE if it= is acting as a 3PCC, not otherwise. A small correction here. I do not know what Gateway you are talking about here. For me, a gateway is a SIP end-point and would respond with its media capabilities for offer-less INVITE. On Mon, Aug 24, 2009 at 8:59 PM, Vikram Chhibber wrote: > On Mon, Aug 24, 2009 at 6:44 PM, Avasarala > Ranjit-A20990 wrote: >> Hi Vikram >> >> Gateway can respond with media capabilities to a offer less INVITE if it= is acting as a 3PCC, not otherwise. >> > This is exactly what I wrote in my mail. > I would again emphasize Paul=92s comment. =93Hold=94 is application=92s > interpretation of some values in SDP such as offer with a =3D > sendonly/inactive. There is no such SDP called as hold SDP. > Furthermore, =A0this offer should be processed as a normal offer as > there could be a change in IP/port, codecs or codecs attributes. >> >> Regards >> Ranjit >> >> -----Original Message----- >> From: sip-implementors-bounces@lists.cs.columbia.edu [mailto:sip-impleme= ntors-bounces@lists.cs.columbia.edu] On Behalf Of Vikram Chhibber >> Sent: Monday, August 24, 2009 11:35 PM >> To: sunil.bhagat@wipro.com >> Cc: sip@ietf.org; sip@core3.amsl.com; sip-implementors@lists.cs.columbia= .edu >> Subject: Re: [Sip-implementors] [Sip] 200 OK response for hold withdiffe= rent media capabilities >> >> The gateway can respond with different media capabilities in 200 OK resp= onse for offer-less INVITE not for offer that we view as for hold. >> The gateway should create response as per rules defined in RFC 3264. >> As far as SIP signalling is concerned, hold INVITE request is treated as= a regular re-INVITE request. >> >> On Mon, Aug 24, 2009 at 2:55 AM, wrote: >>> Hi All, >>> >>> >>> >>> I have a small query related to HOLD request being sent out. >>> >>> >>> >>> For a hold request, can gateway respond with different media >>> capabilities in 200 OK response? >>> >>> >>> >>> Is the HOLD treated as any normal Re-INVITE? >>> >>> >>> >>> Regards, >>> >>> Sunil. >>> >>> >>> >>> Please do not print this email unless it is absolutely necessary. >>> >>> The information contained in this electronic message and any >>> attachments to this message are intended for the exclusive use of the >>> addressee(s) and may contain proprietary, confidential or privileged >>> information. If you are not the intended recipient, you should not >>> disseminate, distribute or copy this e-mail. Please notify the sender >>> immediately and destroy all copies of this message and any attachments. >>> >>> WARNING: Computer viruses can be transmitted via email. The recipient >>> should check this email and any attachments for the presence of >>> viruses. The company accepts no liability for any damage caused by any >>> virus transmitted by this email. >>> >>> www.wipro.com >>> >>> _______________________________________________ >>> Sip mailing list =A0https://www.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP 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-implementors mailing list >> Sip-implementors@lists.cs.columbia.edu >> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors >> > From vikram.chhibber@gmail.com Mon Aug 24 21:03:15 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F6323A6EB3 for ; Mon, 24 Aug 2009 21:03:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ELXov+uDrRFx for ; Mon, 24 Aug 2009 21:03:15 -0700 (PDT) Received: from mail-vw0-f196.google.com (mail-vw0-f196.google.com [209.85.212.196]) by core3.amsl.com (Postfix) with ESMTP id 197DD3A6875 for ; Mon, 24 Aug 2009 21:03:14 -0700 (PDT) Received: by vws34 with SMTP id 34so2597280vws.31 for ; Mon, 24 Aug 2009 21:03:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=0xFpeI8KGDDuxzbTQfFwyN883nGoL02XZJaUwIOhGe8=; b=DMsrwl+nzMfUCOEKP/nGgPes+q8rDomKEd6pXZtq5REcO1rq7shIq5e/3CZY66QpRr B85dBpCoFroxiSvN95XPczdoZ4NHNsPvCKzscYklSqJxK/lgQYgE2I5RDEEozRDNfsFu MaLcR1AalKJEVC8d3CcatbggRl2Zm8FDQZmso= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=MiSBQN/CYLaX+jf+64tYncs+oZuMxqlGTnu9caEGacAxZMazmBy5cHIaV6+m97bzSS tndHvES54iZVODbrdjOhskDnuDK1IoiBkK50ZclZfSyqY25p9TpOq17USLr+w2DxWAcy CpGwlxy+gURb8UR6ZcBhZeYKIgsEqKtfynnaU= MIME-Version: 1.0 Received: by 10.220.105.149 with SMTP id t21mr6988598vco.34.1251172998062; Mon, 24 Aug 2009 21:03:18 -0700 (PDT) In-Reply-To: References: <750BBC72E178114F9DC4872EBFF29A5B08E1606E@ZMY16EXM66.ds.mot.com> Date: Mon, 24 Aug 2009 21:03:17 -0700 Message-ID: From: Vikram Chhibber To: Avasarala Ranjit-A20990 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org, sunil.bhagat@wipro.com, sip@core3.amsl.com, sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip] [Sip-implementors] 200 OK response for hold withdifferent media capabilities X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2009 04:03:15 -0000 >> Gateway can respond with media capabilities to a offer less INVITE if it= is acting as a 3PCC, not otherwise. A small correction here. I do not know what Gateway you are talking about here. For me, a gateway is a SIP end-point and would respond with its media capabilities for offer-less INVITE. On Mon, Aug 24, 2009 at 8:59 PM, Vikram Chhibber wrote: > On Mon, Aug 24, 2009 at 6:44 PM, Avasarala > Ranjit-A20990 wrote: >> Hi Vikram >> >> Gateway can respond with media capabilities to a offer less INVITE if it= is acting as a 3PCC, not otherwise. >> > This is exactly what I wrote in my mail. > I would again emphasize Paul=92s comment. =93Hold=94 is application=92s > interpretation of some values in SDP such as offer with a =3D > sendonly/inactive. There is no such SDP called as hold SDP. > Furthermore, =A0this offer should be processed as a normal offer as > there could be a change in IP/port, codecs or codecs attributes. >> >> Regards >> Ranjit >> >> -----Original Message----- >> From: sip-implementors-bounces@lists.cs.columbia.edu [mailto:sip-impleme= ntors-bounces@lists.cs.columbia.edu] On Behalf Of Vikram Chhibber >> Sent: Monday, August 24, 2009 11:35 PM >> To: sunil.bhagat@wipro.com >> Cc: sip@ietf.org; sip@core3.amsl.com; sip-implementors@lists.cs.columbia= .edu >> Subject: Re: [Sip-implementors] [Sip] 200 OK response for hold withdiffe= rent media capabilities >> >> The gateway can respond with different media capabilities in 200 OK resp= onse for offer-less INVITE not for offer that we view as for hold. >> The gateway should create response as per rules defined in RFC 3264. >> As far as SIP signalling is concerned, hold INVITE request is treated as= a regular re-INVITE request. >> >> On Mon, Aug 24, 2009 at 2:55 AM, wrote: >>> Hi All, >>> >>> >>> >>> I have a small query related to HOLD request being sent out. >>> >>> >>> >>> For a hold request, can gateway respond with different media >>> capabilities in 200 OK response? >>> >>> >>> >>> Is the HOLD treated as any normal Re-INVITE? >>> >>> >>> >>> Regards, >>> >>> Sunil. >>> >>> >>> >>> Please do not print this email unless it is absolutely necessary. >>> >>> The information contained in this electronic message and any >>> attachments to this message are intended for the exclusive use of the >>> addressee(s) and may contain proprietary, confidential or privileged >>> information. If you are not the intended recipient, you should not >>> disseminate, distribute or copy this e-mail. Please notify the sender >>> immediately and destroy all copies of this message and any attachments. >>> >>> WARNING: Computer viruses can be transmitted via email. The recipient >>> should check this email and any attachments for the presence of >>> viruses. The company accepts no liability for any damage caused by any >>> virus transmitted by this email. >>> >>> www.wipro.com >>> >>> _______________________________________________ >>> Sip mailing list =A0https://www.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP 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-implementors mailing list >> Sip-implementors@lists.cs.columbia.edu >> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors >> > From vikram.chhibber@gmail.com Mon Aug 24 21:06:08 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD6423A6F05 for ; Mon, 24 Aug 2009 21:06:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ozoeFg4VcnmH for ; Mon, 24 Aug 2009 21:06:08 -0700 (PDT) Received: from mail-vw0-f186.google.com (mail-vw0-f186.google.com [209.85.212.186]) by core3.amsl.com (Postfix) with ESMTP id 50D503A6F14 for ; Mon, 24 Aug 2009 21:05:04 -0700 (PDT) Received: by vws16 with SMTP id 16so2406981vws.1 for ; Mon, 24 Aug 2009 21:05:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=UEc+l48tAdLGvXsTE3M0FboRjow7EvwDextkekALsRQ=; b=elVlilibsCzRveLp1v/qS8JALgd1xC4Ggm+xB2Mxl1FpXw+59hTfoABubmYJHcZcKr raUfRBAW7ia+Q0H+VCQnBkougJUAxG6ZyzXxKTLKFb7lhz5ew/kOgybgwWIY9+Z2Illd tNs1NFhgB+dFUL0G1SrvvWQwGcFKjuTBBRXNU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=rwlQ7eZ8ZOui/TkbZRuBlIkP+ry0DWK4OE3uAP7ffS/bVz3Fiq5lHrDhkCINxvtyYx qfC5WPYiocddXjVY36dKvzAfkagKp4K32G8Ynnca1Hdb+jyEEbGHRltQurS5E838veZl zIlFGpRNmCnBnGGSrZ05IhvopcauUyQ0YuXhs= MIME-Version: 1.0 Received: by 10.220.68.226 with SMTP id w34mr7200636vci.116.1251172789806; Mon, 24 Aug 2009 20:59:49 -0700 (PDT) In-Reply-To: <750BBC72E178114F9DC4872EBFF29A5B08E1606E@ZMY16EXM66.ds.mot.com> References: <750BBC72E178114F9DC4872EBFF29A5B08E1606E@ZMY16EXM66.ds.mot.com> Date: Mon, 24 Aug 2009 20:59:49 -0700 Message-ID: From: Vikram Chhibber To: Avasarala Ranjit-A20990 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org, sunil.bhagat@wipro.com, sip@core3.amsl.com, sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip] [Sip-implementors] 200 OK response for hold withdifferent media capabilities X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2009 04:06:08 -0000 On Mon, Aug 24, 2009 at 6:44 PM, Avasarala Ranjit-A20990 wrote: > Hi Vikram > > Gateway can respond with media capabilities to a offer less INVITE if it = is acting as a 3PCC, not otherwise. > This is exactly what I wrote in my mail. I would again emphasize Paul=92s comment. =93Hold=94 is application=92s interpretation of some values in SDP such as offer with a =3D sendonly/inactive. There is no such SDP called as hold SDP. Furthermore, this offer should be processed as a normal offer as there could be a change in IP/port, codecs or codecs attributes. > > Regards > Ranjit > > -----Original Message----- > From: sip-implementors-bounces@lists.cs.columbia.edu [mailto:sip-implemen= tors-bounces@lists.cs.columbia.edu] On Behalf Of Vikram Chhibber > Sent: Monday, August 24, 2009 11:35 PM > To: sunil.bhagat@wipro.com > Cc: sip@ietf.org; sip@core3.amsl.com; sip-implementors@lists.cs.columbia.= edu > Subject: Re: [Sip-implementors] [Sip] 200 OK response for hold withdiffer= ent media capabilities > > The gateway can respond with different media capabilities in 200 OK respo= nse for offer-less INVITE not for offer that we view as for hold. > The gateway should create response as per rules defined in RFC 3264. > As far as SIP signalling is concerned, hold INVITE request is treated as = a regular re-INVITE request. > > On Mon, Aug 24, 2009 at 2:55 AM, wrote: >> Hi All, >> >> >> >> I have a small query related to HOLD request being sent out. >> >> >> >> For a hold request, can gateway respond with different media >> capabilities in 200 OK response? >> >> >> >> Is the HOLD treated as any normal Re-INVITE? >> >> >> >> Regards, >> >> Sunil. >> >> >> >> Please do not print this email unless it is absolutely necessary. >> >> The information contained in this electronic message and any >> attachments to this message are intended for the exclusive use of the >> addressee(s) and may contain proprietary, confidential or privileged >> information. If you are not the intended recipient, you should not >> disseminate, distribute or copy this e-mail. Please notify the sender >> immediately and destroy all copies of this message and any attachments. >> >> WARNING: Computer viruses can be transmitted via email. The recipient >> should check this email and any attachments for the presence of >> viruses. The company accepts no liability for any damage caused by any >> virus transmitted by this email. >> >> www.wipro.com >> >> _______________________________________________ >> Sip mailing list =A0https://www.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP 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-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > From pkyzivat@cisco.com Tue Aug 25 08:28:18 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAF603A6B61 for ; Tue, 25 Aug 2009 08:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.982 X-Spam-Level: X-Spam-Status: No, score=-5.982 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oU+ig-IvqvIn for ; Tue, 25 Aug 2009 08:28:17 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id A831528C0DD for ; Tue, 25 Aug 2009 08:28:17 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAFegk0qrR7PD/2dsb2JhbADAEIg5j2kFhBqBWIJp X-IronPort-AV: E=Sophos;i="4.44,272,1249257600"; d="scan'208";a="374890526" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 25 Aug 2009 15:28:24 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n7PFSOO5025787; Tue, 25 Aug 2009 08:28:24 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n7PFSIW0027513; Tue, 25 Aug 2009 15:28:23 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.3959); Tue, 25 Aug 2009 11:28:22 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 25 Aug 2009 11:28:22 -0400 Message-ID: <4A940315.2040203@cisco.com> Date: Tue, 25 Aug 2009 11:28:21 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Avasarala Ranjit-A20990 References: <750BBC72E178114F9DC4872EBFF29A5B08E15FA3@ZMY16EXM66.ds.mot.com> <4A92DDB5.90400@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B08E1606A@ZMY16EXM66.ds.mot.com> In-Reply-To: <750BBC72E178114F9DC4872EBFF29A5B08E1606A@ZMY16EXM66.ds.mot.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Aug 2009 15:28:22.0319 (UTC) FILETIME=[AE4F9BF0:01CA2598] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4900; t=1251214104; x=1252078104; 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-implementors]=20[Sip]=20200=20OK=2 0response=20for=20hold=20with=09different=0A=20media=20capab ilities |Sender:=20; bh=ugdB3CtknYzcp0luDbXpM0I/hKrDtJUf8+IzSWloclQ=; b=ct3e8TBgqc6OU1TocevNXCHsMku0Z9WwgnoFtcz6bxNrkegQ5kUgmKKyj3 wBGDhxRgagrnmFW6lkjoExn8bUvZ0FRaca4WpHFhNGFyKzVhlzPx3sYGzCX2 sZS74MBKcw; Authentication-Results: sj-dkim-3; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: sunil.bhagat@wipro.com, sip@core3.amsl.com, sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip] [Sip-implementors] 200 OK response for hold with different media capabilities X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2009 15:28:18 -0000 I'm removing the cross posting to the sip list. Cross posting is unpolite to those who subscribe to both lists. And this topic is appropriate to sip-implementors. Avasarala Ranjit-A20990 wrote: > Hi Paul > > The HOLD request is nothing but a re INVITE request indicating HOLD. There is no such thing as a reINVITE request that indicates *HOLD*. There are indications for sendrecv, sendonly, recvonly, and inactive. They are often used by UAs that have a HOLD feature, but they are also used for other purposes unrelated to HOLD features. When a UAC implements a HOLD feature by sending a reINVITE with a=sendonly, the UAS does not know that the reason for this change is because of a HOLD feature. It can only take the signaling at face value: "My peer wants to send me media, but doesn't want to receive it. Given that constraint, what do I want to do?" There can be many answers to that question. There are no rules that say: thou shalt not change media attributes in this case. > Could you give a use case where such a thing may happen? I have not come > across any scenario where in the process of putting remote party on > HOLD, media parameters like IP/codec getting changed. If this happens, > then it cannot be considered a HOLD request. Its probably good advice that in general when being presented with an offered change you should respond with an answer that makes the minimal changes on your part that are consistent with what was offered. But that behavior isn't required. I have heard of implementations that change media port on every reINVITE. Doesn't make sense to me, but maybe it did to them, and its within the rights of the implementor to do so. > So how do u distinguish a HOLD request from a non HOLD one if in both > the cases the media parameters (other than a=.....) change? As the recipient, you *don't* distinguish a HOLD request from a non HOLD one. You simply take things at face value without attempting to ascribe a reason for *why* they have happened. Thanks, Paul > Regards > Ranjit > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Tuesday, August 25, 2009 12:07 AM > To: Avasarala Ranjit-A20990 > Cc: sunil.bhagat@wipro.com; sip@ietf.org; > sip-implementors@lists.cs.columbia.edu; sip@core3.amsl.com > Subject: Re: [Sip-implementors] [Sip] 200 OK response for hold with > different media capabilities > > > > Avasarala Ranjit-A20990 wrote: >> no it should not. For a Hold request, you do not send any media >> capabilities. U only change the existing media description lines to >> indicate HOLD. > > I beg to differ. > > Technically there is no HOLD request. > All there is is an offer that offers to change a media attribute, from > sendrecv to sendonly or inactive, or from sendonly or recvonly to > inactive. > > The response may change anything that is permitted to be changed in the > answer, given the offer. So it may not add m-lines, but it can certainly > change media addresses, and within limits may change media formats > (codecs). > > Thanks, > Paul > >> Regards >> Ranjit >> >> >> >> ________________________________ >> >> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of >> sunil.bhagat@wipro.com >> Sent: Monday, August 24, 2009 3:25 PM >> To: sip@ietf.org; sip-implementors@lists.cs.columbia.edu; >> sip@core3.amsl.com >> Subject: [Sip] 200 OK response for hold with different media >> capabilities >> >> >> >> Hi All, >> >> >> >> I have a small query related to HOLD request being sent out. >> >> >> >> For a hold request, can gateway respond with different media >> capabilities in 200 OK response? >> >> >> >> Is the HOLD treated as any normal Re-INVITE? >> >> >> >> Regards, >> >> Sunil. >> >> >> >> Please do not print this email unless it is absolutely necessary. >> >> The information contained in this electronic message and any >> attachments to this message are intended for the exclusive use of the >> addressee(s) and may contain proprietary, confidential or privileged >> information. If you are not the intended recipient, you should not >> disseminate, distribute or copy this e-mail. Please notify the sender >> immediately and destroy all copies of this message and any > attachments. >> WARNING: Computer viruses can be transmitted via email. The recipient >> should check this email and any attachments for the presence of > viruses. >> The company accepts no liability for any damage caused by any virus >> transmitted by this email. >> >> www.wipro.com >> >> _______________________________________________ >> Sip-implementors mailing list >> Sip-implementors@lists.cs.columbia.edu >> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors >> > From srikanthv@motorola.com Thu Aug 27 07:59:03 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A4D03A63EC for ; Thu, 27 Aug 2009 07:59:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nYGDqj8NuqKT for ; Thu, 27 Aug 2009 07:59:02 -0700 (PDT) Received: from mail55.messagelabs.com (mail55.messagelabs.com [216.82.241.163]) by core3.amsl.com (Postfix) with ESMTP id 0C37628C61B for ; Thu, 27 Aug 2009 07:57:43 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: srikanthv@motorola.com X-Msg-Ref: server-13.tower-55.messagelabs.com!1251385069!97327324!1 X-StarScan-Version: 6.1.3; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 21606 invoked from network); 27 Aug 2009 14:57:49 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-13.tower-55.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 27 Aug 2009 14:57:49 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.14.3/8.14.3) with ESMTP id n7REvmpO001764 for ; Thu, 27 Aug 2009 07:57:48 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id n7REvmik004846 for ; Thu, 27 Aug 2009 09:57:48 -0500 (CDT) Received: from ZMY16EXM67.ds.mot.com (zmy16exm67.ap.mot.com [10.179.4.27]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id n7REvl7A004841 for ; Thu, 27 Aug 2009 09:57:48 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA2726.B083BE12" Date: Thu, 27 Aug 2009 22:57:22 +0800 Message-ID: <608D7BFF0D57794785CBC2C440BC4FA1058116D7@ZMY16EXM67.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question on draft-ietf-sip-outbound-20 draft: multiple flow creation Thread-Index: AconJq63dxYy8I81RQ26QF91DE+n/g== From: "Vavilapalli Srikanth-A19563" To: X-CFilter-Loop: Reflected Subject: [Sip] Question on draft-ietf-sip-outbound-20 draft: multiple flow creation X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2009 14:59:03 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA2726.B083BE12 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi =20 As specified in section 3.3/3.4 of draft-ietf-sip-outbound-20 draft, If a UA is configured with a outbound-proxy-set with two proxy uris: "sip:primary.example.com" and "sip:secondary.example.com" And for example, "sip:primary.example.com" got DNS resolved in to two SRV records "Host1" and "Host2" and "sip:secondary.example.com" got DNS resolved in to "Host3" and "Host4", Should UA create four FLOWs, One with each host OR just two FLOWs, one with each proxy URI(i.e one flow with either Host1 or Host2 and second flow with Host3 or Host4)? =20 Please clarify. =20 Regards Srikanth ------_=_NextPart_001_01CA2726.B083BE12 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi
 
As = specified in=20 section 3.3/3.4 of draft-ietf-sip-outbound-20 draft, If a UA is = configured with=20 a outbound-proxy-set with two proxy uris: "sip:primary.example.com" and=20 "sip:secondary.example.com" And for example, "sip:primary.example.com" = got DNS=20 resolved in to two SRV records "Host1" and "Host2" and=20 "sip:secondary.example.com" got DNS resolved in to "Host3" and "Host4", = Should=20 UA create four FLOWs, One with each host OR just two FLOWs, one = with each=20 proxy URI(i.e one flow with either Host1 or Host2 and second flow with = Host3 or=20 Host4)?
 
Please = clarify.
 
Regards
Srikanth
------_=_NextPart_001_01CA2726.B083BE12-- From AUDET@nortel.com Thu Aug 27 08:52:06 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D28123A6F8A for ; Thu, 27 Aug 2009 08:52:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.447 X-Spam-Level: X-Spam-Status: No, score=-6.447 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DhVbPGarNVMv for ; Thu, 27 Aug 2009 08:52:06 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id B88183A7014 for ; Thu, 27 Aug 2009 08:52:05 -0700 (PDT) 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 n7RFq9o24672; Thu, 27 Aug 2009 15:52:09 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA272E.50E2AD95" Date: Thu, 27 Aug 2009 10:51:59 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1FA69CD0@zrc2hxm0.corp.nortel.com> In-Reply-To: <608D7BFF0D57794785CBC2C440BC4FA1058116D7@ZMY16EXM67.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Question on draft-ietf-sip-outbound-20 draft: multiple flowcreation Thread-Index: AconJq63dxYy8I81RQ26QF91DE+n/gABw+Zw References: <608D7BFF0D57794785CBC2C440BC4FA1058116D7@ZMY16EXM67.ds.mot.com> From: "Francois Audet" To: "Vavilapalli Srikanth-A19563" , Subject: Re: [Sip] Question on draft-ietf-sip-outbound-20 draft: multiple flowcreation X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2009 15:52:06 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA272E.50E2AD95 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable You would have 2. One for primary, and one for secondary. For each one = of those, you would use normal RFC 3263 procedures for determining which = SRV record to use. ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of = Vavilapalli Srikanth-A19563 Sent: Thursday, August 27, 2009 07:57 To: sip@ietf.org Subject: [Sip] Question on draft-ietf-sip-outbound-20 draft: multiple = flowcreation =09 =09 Hi =20 As specified in section 3.3/3.4 of draft-ietf-sip-outbound-20 draft, If = a UA is configured with a outbound-proxy-set with two proxy uris: = "sip:primary.example.com" and "sip:secondary.example.com" And for = example, "sip:primary.example.com" got DNS resolved in to two SRV = records "Host1" and "Host2" and "sip:secondary.example.com" got DNS = resolved in to "Host3" and "Host4", Should UA create four FLOWs, One = with each host OR just two FLOWs, one with each proxy URI(i.e one flow = with either Host1 or Host2 and second flow with Host3 or Host4)? =20 Please clarify. =20 Regards Srikanth ------_=_NextPart_001_01CA272E.50E2AD95 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
You=20 would have 2. One for primary, and one for secondary. For = each one of=20 those, you would use normal RFC 3263 procedures for determining which = SRV record=20 to use.

From: sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org] On Behalf Of Vavilapalli=20 Srikanth-A19563
Sent: Thursday, August 27, 2009 = 07:57
To:=20 sip@ietf.org
Subject: [Sip] Question on = draft-ietf-sip-outbound-20=20 draft: multiple flowcreation

Hi
 
As = specified in=20 section 3.3/3.4 of draft-ietf-sip-outbound-20 draft, If a UA is = configured=20 with a outbound-proxy-set with two proxy uris: = "sip:primary.example.com" and=20 "sip:secondary.example.com" And for example, "sip:primary.example.com" = got DNS=20 resolved in to two SRV records "Host1" and "Host2" and=20 "sip:secondary.example.com" got DNS resolved in to "Host3" and = "Host4", Should=20 UA create four FLOWs, One with each host OR just two FLOWs, one = with each=20 proxy URI(i.e one flow with either Host1 or Host2 and second flow with = Host3=20 or Host4)?
 
Please=20 clarify.
 
Regards
Srikanth
------_=_NextPart_001_01CA272E.50E2AD95-- From srikanthv@motorola.com Fri Aug 28 07:46:19 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8257F28C32A for ; Fri, 28 Aug 2009 07:46:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6-lCR1R+f0HI for ; Fri, 28 Aug 2009 07:46:18 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by core3.amsl.com (Postfix) with ESMTP id 2810B3A6953 for ; Fri, 28 Aug 2009 07:46:17 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: srikanthv@motorola.com X-Msg-Ref: server-4.tower-119.messagelabs.com!1251470769!37735650!1 X-StarScan-Version: 6.1.3; banners=-,-,- X-Originating-IP: [136.182.1.15] Received: (qmail 5274 invoked from network); 28 Aug 2009 14:46:10 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (136.182.1.15) by server-4.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 28 Aug 2009 14:46:10 -0000 Received: from il27exr02.cig.mot.com (il27exr02.mot.com [10.17.196.71]) by motgate5.mot.com (8.14.3/8.14.3) with ESMTP id n7SEk5xF026393 for ; Fri, 28 Aug 2009 07:46:09 -0700 (MST) Received: from il27vts03 (il27vts03.cig.mot.com [10.17.196.87]) by il27exr02.cig.mot.com (8.13.1/Vontu) with SMTP id n7SEk4aD024153 for ; Fri, 28 Aug 2009 09:46:04 -0500 (CDT) Received: from ZMY16EXM67.ds.mot.com (zmy16exm67.ap.mot.com [10.179.4.27]) by il27exr02.cig.mot.com (8.13.1/8.13.0) with ESMTP id n7SEk2wi024122 for ; Fri, 28 Aug 2009 09:46:03 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA27EE.4366A02A" Date: Fri, 28 Aug 2009 22:46:02 +0800 Message-ID: <608D7BFF0D57794785CBC2C440BC4FA1058119A2@ZMY16EXM67.ds.mot.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1FA69CD0@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Question on draft-ietf-sip-outbound-20 draft: multiple flowcreation Thread-Index: AconJq63dxYy8I81RQ26QF91DE+n/gABw+ZwACQRbAA= References: <608D7BFF0D57794785CBC2C440BC4FA1058116D7@ZMY16EXM67.ds.mot.com> <1ECE0EB50388174790F9694F77522CCF1FA69CD0@zrc2hxm0.corp.nortel.com> From: "Vavilapalli Srikanth-A19563" To: "Francois Audet" , , , X-CFilter-Loop: Reflected Subject: Re: [Sip] Question on draft-ietf-sip-outbound-20 draft: multiple flowcreation X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 14:46:19 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA27EE.4366A02A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi =20 Thanks for the reply..One more of clarification required.. =20 So If UA wishes to create multiple transport flows with "sip:primary.example.com"(As specified in draft-ietf-sip-outbound-20#section-13 to honor RFC3261 requirement for message size greater than MTU), would it be OK it one FLOW lands on Host1 and other FLOW lands on Host2? =20 i.e for example if "sip:primary.example.com" got resolved into (IP1, Port1, TCP) -> (IP2, Port2, TCP) -> (IP2, Port2, UDP) -> (IP1, Port1, UDP) in that order, and if UA wises to create both TCP and UDP FLOWs with "sip:primary.example.com", then it starts creating TCP FLOW with (IP1, Port1, TCP) and can create a UDP FLOW with (IP2, Port2, UDP) based on RFC 3263 procedures. Is my understanding correct here?=20 =20 In the above example, if (IP1) is down/crashed for some reasons, then "sip:primary.example.com", can never use the TCP FLOW for transporting inbound messages to that UA (Even though the IP1 and IP2 are state synchronized) until User Agent detects the FLOW failure with (IP1) and re-create the TCP FLOW with (IP1 or IP2). Is my understanding correct here? =20 Please clarify.. =20 Regard Srikanth ________________________________ From: Francois Audet [mailto:audet@nortel.com]=20 Sent: Thursday, August 27, 2009 9:22 PM To: Vavilapalli Srikanth-A19563; sip@ietf.org Subject: RE: [Sip] Question on draft-ietf-sip-outbound-20 draft: multiple flowcreation You would have 2. One for primary, and one for secondary. For each one of those, you would use normal RFC 3263 procedures for determining which SRV record to use. ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Vavilapalli Srikanth-A19563 Sent: Thursday, August 27, 2009 07:57 To: sip@ietf.org Subject: [Sip] Question on draft-ietf-sip-outbound-20 draft: multiple flowcreation =09 =09 Hi =20 As specified in section 3.3/3.4 of draft-ietf-sip-outbound-20 draft, If a UA is configured with a outbound-proxy-set with two proxy uris: "sip:primary.example.com" and "sip:secondary.example.com" And for example, "sip:primary.example.com" got DNS resolved in to two SRV records "Host1" and "Host2" and "sip:secondary.example.com" got DNS resolved in to "Host3" and "Host4", Should UA create four FLOWs, One with each host OR just two FLOWs, one with each proxy URI(i.e one flow with either Host1 or Host2 and second flow with Host3 or Host4)? =20 Please clarify. =20 Regards Srikanth ------_=_NextPart_001_01CA27EE.4366A02A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi
 
Thanks for the reply..One more of = clarification=20 required..
 
So If UA wishes to create multiple transport = flows with=20 "sip:primary.example.com"(As specified in = draft-ietf-sip-outbound-20#section-13=20 to honor RFC3261 requirement for message size greater = than MTU), would=20 it be OK it one FLOW lands on Host1 and other FLOW lands on=20 Host2?
 
i.e for example if "sip:primary.example.com" = got=20 resolved into (IP1, Port1, TCP) -> (IP2, Port2, TCP) -> (IP2, = Port2, UDP)=20 -> (IP1, Port1, UDP) in that order, and if UA wises to create both = TCP and=20 UDP FLOWs with "sip:primary.example.com", then it starts creating TCP = FLOW with=20 (IP1, Port1, TCP) and can create a UDP FLOW with (IP2, Port2, UDP) based = on RFC=20 3263 procedures. Is my understanding correct here?
 
In the above example, if (IP1) is = down/crashed for some=20 reasons, then "sip:primary.example.com", can never use the TCP FLOW for=20 transporting inbound messages to that UA (Even though the IP1 and IP2 = are state=20 synchronized) until User Agent detects the FLOW failure with (IP1) and = re-create=20 the TCP FLOW with (IP1 or IP2). Is my understanding correct=20 here?
 
Please clarify..
 
Regard
Srikanth

From: Francois Audet = [mailto:audet@nortel.com]=20
Sent: Thursday, August 27, 2009 9:22 PM
To: = Vavilapalli=20 Srikanth-A19563; sip@ietf.org
Subject: RE: [Sip] Question on=20 draft-ietf-sip-outbound-20 draft: multiple = flowcreation

You=20 would have 2. One for primary, and one for secondary. For = each one of=20 those, you would use normal RFC 3263 procedures for determining which = SRV record=20 to use.

From: sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org] On Behalf Of Vavilapalli=20 Srikanth-A19563
Sent: Thursday, August 27, 2009 = 07:57
To:=20 sip@ietf.org
Subject: [Sip] Question on = draft-ietf-sip-outbound-20=20 draft: multiple flowcreation

Hi
 
As = specified in=20 section 3.3/3.4 of draft-ietf-sip-outbound-20 draft, If a UA is = configured=20 with a outbound-proxy-set with two proxy uris: = "sip:primary.example.com" and=20 "sip:secondary.example.com" And for example, "sip:primary.example.com" = got DNS=20 resolved in to two SRV records "Host1" and "Host2" and=20 "sip:secondary.example.com" got DNS resolved in to "Host3" and = "Host4", Should=20 UA create four FLOWs, One with each host OR just two FLOWs, one = with each=20 proxy URI(i.e one flow with either Host1 or Host2 and second flow with = Host3=20 or Host4)?
 
Please=20 clarify.
 
Regards
Srikanth
------_=_NextPart_001_01CA27EE.4366A02A-- From srikanthv@motorola.com Fri Aug 28 07:46:27 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 108CF28C3A1 for ; Fri, 28 Aug 2009 07:46:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PvQADfwcBkn2 for ; Fri, 28 Aug 2009 07:46:26 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by core3.amsl.com (Postfix) with ESMTP id 8B8ED3A6C81 for ; Fri, 28 Aug 2009 07:46:26 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: srikanthv@motorola.com X-Msg-Ref: server-11.tower-119.messagelabs.com!1251470789!34645767!1 X-StarScan-Version: 6.1.3; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 23059 invoked from network); 28 Aug 2009 14:46:30 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-11.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 28 Aug 2009 14:46:30 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.14.3/8.14.3) with ESMTP id n7SEkPSS000077 for ; Fri, 28 Aug 2009 07:46:29 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id n7SEkPFs020635 for ; Fri, 28 Aug 2009 09:46:25 -0500 (CDT) Received: from ZMY16EXM67.ds.mot.com (zmy16exm67.ap.mot.com [10.179.4.27]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id n7SEkNja020625 for ; Fri, 28 Aug 2009 09:46:24 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA27EE.4366A02A" Date: Fri, 28 Aug 2009 22:46:02 +0800 Message-ID: <608D7BFF0D57794785CBC2C440BC4FA1058119A2@ZMY16EXM67.ds.mot.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1FA69CD0@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Question on draft-ietf-sip-outbound-20 draft: multiple flowcreation Thread-Index: AconJq63dxYy8I81RQ26QF91DE+n/gABw+ZwACQRbAA= References: <608D7BFF0D57794785CBC2C440BC4FA1058116D7@ZMY16EXM67.ds.mot.com> <1ECE0EB50388174790F9694F77522CCF1FA69CD0@zrc2hxm0.corp.nortel.com> From: "Vavilapalli Srikanth-A19563" To: "Francois Audet" , , , X-CFilter-Loop: Reflected Subject: Re: [Sip] Question on draft-ietf-sip-outbound-20 draft: multiple flowcreation X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 14:46:27 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA27EE.4366A02A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi =20 Thanks for the reply..One more of clarification required.. =20 So If UA wishes to create multiple transport flows with "sip:primary.example.com"(As specified in draft-ietf-sip-outbound-20#section-13 to honor RFC3261 requirement for message size greater than MTU), would it be OK it one FLOW lands on Host1 and other FLOW lands on Host2? =20 i.e for example if "sip:primary.example.com" got resolved into (IP1, Port1, TCP) -> (IP2, Port2, TCP) -> (IP2, Port2, UDP) -> (IP1, Port1, UDP) in that order, and if UA wises to create both TCP and UDP FLOWs with "sip:primary.example.com", then it starts creating TCP FLOW with (IP1, Port1, TCP) and can create a UDP FLOW with (IP2, Port2, UDP) based on RFC 3263 procedures. Is my understanding correct here?=20 =20 In the above example, if (IP1) is down/crashed for some reasons, then "sip:primary.example.com", can never use the TCP FLOW for transporting inbound messages to that UA (Even though the IP1 and IP2 are state synchronized) until User Agent detects the FLOW failure with (IP1) and re-create the TCP FLOW with (IP1 or IP2). Is my understanding correct here? =20 Please clarify.. =20 Regard Srikanth ________________________________ From: Francois Audet [mailto:audet@nortel.com]=20 Sent: Thursday, August 27, 2009 9:22 PM To: Vavilapalli Srikanth-A19563; sip@ietf.org Subject: RE: [Sip] Question on draft-ietf-sip-outbound-20 draft: multiple flowcreation You would have 2. One for primary, and one for secondary. For each one of those, you would use normal RFC 3263 procedures for determining which SRV record to use. ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Vavilapalli Srikanth-A19563 Sent: Thursday, August 27, 2009 07:57 To: sip@ietf.org Subject: [Sip] Question on draft-ietf-sip-outbound-20 draft: multiple flowcreation =09 =09 Hi =20 As specified in section 3.3/3.4 of draft-ietf-sip-outbound-20 draft, If a UA is configured with a outbound-proxy-set with two proxy uris: "sip:primary.example.com" and "sip:secondary.example.com" And for example, "sip:primary.example.com" got DNS resolved in to two SRV records "Host1" and "Host2" and "sip:secondary.example.com" got DNS resolved in to "Host3" and "Host4", Should UA create four FLOWs, One with each host OR just two FLOWs, one with each proxy URI(i.e one flow with either Host1 or Host2 and second flow with Host3 or Host4)? =20 Please clarify. =20 Regards Srikanth ------_=_NextPart_001_01CA27EE.4366A02A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi
 
Thanks for the reply..One more of = clarification=20 required..
 
So If UA wishes to create multiple transport = flows with=20 "sip:primary.example.com"(As specified in = draft-ietf-sip-outbound-20#section-13=20 to honor RFC3261 requirement for message size greater = than MTU), would=20 it be OK it one FLOW lands on Host1 and other FLOW lands on=20 Host2?
 
i.e for example if "sip:primary.example.com" = got=20 resolved into (IP1, Port1, TCP) -> (IP2, Port2, TCP) -> (IP2, = Port2, UDP)=20 -> (IP1, Port1, UDP) in that order, and if UA wises to create both = TCP and=20 UDP FLOWs with "sip:primary.example.com", then it starts creating TCP = FLOW with=20 (IP1, Port1, TCP) and can create a UDP FLOW with (IP2, Port2, UDP) based = on RFC=20 3263 procedures. Is my understanding correct here?
 
In the above example, if (IP1) is = down/crashed for some=20 reasons, then "sip:primary.example.com", can never use the TCP FLOW for=20 transporting inbound messages to that UA (Even though the IP1 and IP2 = are state=20 synchronized) until User Agent detects the FLOW failure with (IP1) and = re-create=20 the TCP FLOW with (IP1 or IP2). Is my understanding correct=20 here?
 
Please clarify..
 
Regard
Srikanth

From: Francois Audet = [mailto:audet@nortel.com]=20
Sent: Thursday, August 27, 2009 9:22 PM
To: = Vavilapalli=20 Srikanth-A19563; sip@ietf.org
Subject: RE: [Sip] Question on=20 draft-ietf-sip-outbound-20 draft: multiple = flowcreation

You=20 would have 2. One for primary, and one for secondary. For = each one of=20 those, you would use normal RFC 3263 procedures for determining which = SRV record=20 to use.

From: sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org] On Behalf Of Vavilapalli=20 Srikanth-A19563
Sent: Thursday, August 27, 2009 = 07:57
To:=20 sip@ietf.org
Subject: [Sip] Question on = draft-ietf-sip-outbound-20=20 draft: multiple flowcreation

Hi
 
As = specified in=20 section 3.3/3.4 of draft-ietf-sip-outbound-20 draft, If a UA is = configured=20 with a outbound-proxy-set with two proxy uris: = "sip:primary.example.com" and=20 "sip:secondary.example.com" And for example, "sip:primary.example.com" = got DNS=20 resolved in to two SRV records "Host1" and "Host2" and=20 "sip:secondary.example.com" got DNS resolved in to "Host3" and = "Host4", Should=20 UA create four FLOWs, One with each host OR just two FLOWs, one = with each=20 proxy URI(i.e one flow with either Host1 or Host2 and second flow with = Host3=20 or Host4)?
 
Please=20 clarify.
 
Regards
Srikanth
------_=_NextPart_001_01CA27EE.4366A02A-- From AUDET@nortel.com Fri Aug 28 11:53:35 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07C5A3A6A67 for ; Fri, 28 Aug 2009 11:53:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.451 X-Spam-Level: X-Spam-Status: No, score=-6.451 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xvoRzeSGkz0c for ; Fri, 28 Aug 2009 11:53:33 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id A51EC3A6F90 for ; Fri, 28 Aug 2009 11:52:53 -0700 (PDT) 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 n7SIqrk28624; Fri, 28 Aug 2009 18:52:54 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA2810.B82636C3" Date: Fri, 28 Aug 2009 13:52:40 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1FB064B1@zrc2hxm0.corp.nortel.com> In-Reply-To: <608D7BFF0D57794785CBC2C440BC4FA1058119A2@ZMY16EXM67.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Question on draft-ietf-sip-outbound-20 draft: multipleflowcreation Thread-Index: AconJq63dxYy8I81RQ26QF91DE+n/gABw+ZwACQRbAAAFJ6AYA== References: <608D7BFF0D57794785CBC2C440BC4FA1058116D7@ZMY16EXM67.ds.mot.com><1ECE0EB50388174790F9694F77522CCF1FA69CD0@zrc2hxm0.corp.nortel.com> <608D7BFF0D57794785CBC2C440BC4FA1058119A2@ZMY16EXM67.ds.mot.com> From: "Francois Audet" To: "Vavilapalli Srikanth-A19563" , , , Subject: Re: [Sip] Question on draft-ietf-sip-outbound-20 draft: multipleflowcreation X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 18:53:35 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA2810.B82636C3 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I honestly don't know why anybody would want to do both UDP and TCP. =20 (In other words, if you set up a TCP flow, I don't see a benefit in also = setting up a UDP flow which you will have to maintain for keep alives). =20 ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of = Vavilapalli Srikanth-A19563 Sent: Friday, August 28, 2009 07:46 To: Audet, Francois (SC100:3055); sip@ietf.org; sip@core3.amsl.com; = sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip] Question on draft-ietf-sip-outbound-20 draft: = multipleflowcreation =09 =09 Hi =20 Thanks for the reply..One more of clarification required.. =20 So If UA wishes to create multiple transport flows with = "sip:primary.example.com"(As specified in = draft-ietf-sip-outbound-20#section-13 to honor RFC3261 requirement for = message size greater than MTU), would it be OK it one FLOW lands on = Host1 and other FLOW lands on Host2? =20 i.e for example if "sip:primary.example.com" got resolved into (IP1, = Port1, TCP) -> (IP2, Port2, TCP) -> (IP2, Port2, UDP) -> (IP1, Port1, = UDP) in that order, and if UA wises to create both TCP and UDP FLOWs = with "sip:primary.example.com", then it starts creating TCP FLOW with = (IP1, Port1, TCP) and can create a UDP FLOW with (IP2, Port2, UDP) based = on RFC 3263 procedures. Is my understanding correct here?=20 =20 In the above example, if (IP1) is down/crashed for some reasons, then = "sip:primary.example.com", can never use the TCP FLOW for transporting = inbound messages to that UA (Even though the IP1 and IP2 are state = synchronized) until User Agent detects the FLOW failure with (IP1) and = re-create the TCP FLOW with (IP1 or IP2). Is my understanding correct = here? =20 Please clarify.. =20 Regard Srikanth ________________________________ From: Francois Audet [mailto:audet@nortel.com]=20 Sent: Thursday, August 27, 2009 9:22 PM To: Vavilapalli Srikanth-A19563; sip@ietf.org Subject: RE: [Sip] Question on draft-ietf-sip-outbound-20 draft: = multiple flowcreation =09 =09 You would have 2. One for primary, and one for secondary. For each one = of those, you would use normal RFC 3263 procedures for determining which = SRV record to use. ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of = Vavilapalli Srikanth-A19563 Sent: Thursday, August 27, 2009 07:57 To: sip@ietf.org Subject: [Sip] Question on draft-ietf-sip-outbound-20 draft: multiple = flowcreation =09 =09 Hi =20 As specified in section 3.3/3.4 of draft-ietf-sip-outbound-20 draft, = If a UA is configured with a outbound-proxy-set with two proxy uris: = "sip:primary.example.com" and "sip:secondary.example.com" And for = example, "sip:primary.example.com" got DNS resolved in to two SRV = records "Host1" and "Host2" and "sip:secondary.example.com" got DNS = resolved in to "Host3" and "Host4", Should UA create four FLOWs, One = with each host OR just two FLOWs, one with each proxy URI(i.e one flow = with either Host1 or Host2 and second flow with Host3 or Host4)? =20 Please clarify. =20 Regards Srikanth ------_=_NextPart_001_01CA2810.B82636C3 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I=20 honestly don't know why anybody would want to do both UDP and=20 TCP.
 
(In=20 other words, if you set up a TCP flow, I don't see a benefit in also = setting up=20 a UDP flow which you will have to maintain for keep = alives).
 

From: sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org] On Behalf Of Vavilapalli=20 Srikanth-A19563
Sent: Friday, August 28, 2009 = 07:46
To:=20 Audet, Francois (SC100:3055); sip@ietf.org; sip@core3.amsl.com;=20 sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip] = Question=20 on draft-ietf-sip-outbound-20 draft: = multipleflowcreation

Hi
 
Thanks for the reply..One more of = clarification=20 required..
 
So If UA wishes to create multiple = transport flows=20 with "sip:primary.example.com"(As specified in=20 draft-ietf-sip-outbound-20#section-13 to honor RFC3261 requirement for = message=20 size greater than MTU), would it be OK it one FLOW lands on = Host1=20 and other FLOW lands on Host2?
 
i.e for example if = "sip:primary.example.com" got=20 resolved into (IP1, Port1, TCP) -> (IP2, Port2, TCP) -> (IP2, = Port2,=20 UDP) -> (IP1, Port1, UDP) in that order, and if UA wises to create = both TCP=20 and UDP FLOWs with "sip:primary.example.com", then it starts creating = TCP FLOW=20 with (IP1, Port1, TCP) and can create a UDP FLOW with (IP2, Port2, = UDP) based=20 on RFC 3263 procedures. Is my understanding correct here? =
 
In the above example, if (IP1) is = down/crashed for=20 some reasons, then "sip:primary.example.com", can never use the TCP = FLOW for=20 transporting inbound messages to that UA (Even though the IP1 and IP2 = are=20 state synchronized) until User Agent detects the FLOW failure with = (IP1) and=20 re-create the TCP FLOW with (IP1 or IP2). Is my understanding correct=20 here?
 
Please clarify..
 
Regard
Srikanth

From: Francois Audet = [mailto:audet@nortel.com]=20
Sent: Thursday, August 27, 2009 9:22 PM
To: = Vavilapalli=20 Srikanth-A19563; sip@ietf.org
Subject: RE: [Sip] Question on = draft-ietf-sip-outbound-20 draft: multiple = flowcreation

You=20 would have 2. One for primary, and one for secondary. For = each one of=20 those, you would use normal RFC 3263 procedures for determining which = SRV=20 record to use.

From: sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org] On Behalf Of Vavilapalli=20 Srikanth-A19563
Sent: Thursday, August 27, 2009=20 07:57
To: sip@ietf.org
Subject: [Sip] Question = on=20 draft-ietf-sip-outbound-20 draft: multiple = flowcreation

Hi
 
As = specified in=20 section 3.3/3.4 of draft-ietf-sip-outbound-20 draft, If a UA is = configured=20 with a outbound-proxy-set with two proxy uris: = "sip:primary.example.com" and=20 "sip:secondary.example.com" And for example, = "sip:primary.example.com" got=20 DNS resolved in to two SRV records "Host1" and "Host2" and=20 "sip:secondary.example.com" got DNS resolved in to "Host3" and = "Host4",=20 Should UA create four FLOWs, One with each host OR just two = FLOWs, one=20 with each proxy URI(i.e one flow with either Host1 or Host2 and = second flow=20 with Host3 or Host4)?
 
Please=20 clarify.
 
Regards
Srikanth
------_=_NextPart_001_01CA2810.B82636C3-- From AUDET@nortel.com Fri Aug 28 12:06:25 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B25433A71F1 for ; Fri, 28 Aug 2009 12:06:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.456 X-Spam-Level: X-Spam-Status: No, score=-6.456 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fiZjbLuIXs2j for ; Fri, 28 Aug 2009 12:06:24 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 0B0C83A71C9 for ; Fri, 28 Aug 2009 12:05:30 -0700 (PDT) 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 n7SIqrk28624; Fri, 28 Aug 2009 18:52:54 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA2810.B82636C3" Date: Fri, 28 Aug 2009 13:52:40 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1FB064B1@zrc2hxm0.corp.nortel.com> In-Reply-To: <608D7BFF0D57794785CBC2C440BC4FA1058119A2@ZMY16EXM67.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Question on draft-ietf-sip-outbound-20 draft: multipleflowcreation Thread-Index: AconJq63dxYy8I81RQ26QF91DE+n/gABw+ZwACQRbAAAFJ6AYA== References: <608D7BFF0D57794785CBC2C440BC4FA1058116D7@ZMY16EXM67.ds.mot.com><1ECE0EB50388174790F9694F77522CCF1FA69CD0@zrc2hxm0.corp.nortel.com> <608D7BFF0D57794785CBC2C440BC4FA1058119A2@ZMY16EXM67.ds.mot.com> From: "Francois Audet" To: "Vavilapalli Srikanth-A19563" , , , Subject: Re: [Sip] Question on draft-ietf-sip-outbound-20 draft: multipleflowcreation X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 19:06:25 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA2810.B82636C3 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I honestly don't know why anybody would want to do both UDP and TCP. =20 (In other words, if you set up a TCP flow, I don't see a benefit in also = setting up a UDP flow which you will have to maintain for keep alives). =20 ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of = Vavilapalli Srikanth-A19563 Sent: Friday, August 28, 2009 07:46 To: Audet, Francois (SC100:3055); sip@ietf.org; sip@core3.amsl.com; = sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip] Question on draft-ietf-sip-outbound-20 draft: = multipleflowcreation =09 =09 Hi =20 Thanks for the reply..One more of clarification required.. =20 So If UA wishes to create multiple transport flows with = "sip:primary.example.com"(As specified in = draft-ietf-sip-outbound-20#section-13 to honor RFC3261 requirement for = message size greater than MTU), would it be OK it one FLOW lands on = Host1 and other FLOW lands on Host2? =20 i.e for example if "sip:primary.example.com" got resolved into (IP1, = Port1, TCP) -> (IP2, Port2, TCP) -> (IP2, Port2, UDP) -> (IP1, Port1, = UDP) in that order, and if UA wises to create both TCP and UDP FLOWs = with "sip:primary.example.com", then it starts creating TCP FLOW with = (IP1, Port1, TCP) and can create a UDP FLOW with (IP2, Port2, UDP) based = on RFC 3263 procedures. Is my understanding correct here?=20 =20 In the above example, if (IP1) is down/crashed for some reasons, then = "sip:primary.example.com", can never use the TCP FLOW for transporting = inbound messages to that UA (Even though the IP1 and IP2 are state = synchronized) until User Agent detects the FLOW failure with (IP1) and = re-create the TCP FLOW with (IP1 or IP2). Is my understanding correct = here? =20 Please clarify.. =20 Regard Srikanth ________________________________ From: Francois Audet [mailto:audet@nortel.com]=20 Sent: Thursday, August 27, 2009 9:22 PM To: Vavilapalli Srikanth-A19563; sip@ietf.org Subject: RE: [Sip] Question on draft-ietf-sip-outbound-20 draft: = multiple flowcreation =09 =09 You would have 2. One for primary, and one for secondary. For each one = of those, you would use normal RFC 3263 procedures for determining which = SRV record to use. ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of = Vavilapalli Srikanth-A19563 Sent: Thursday, August 27, 2009 07:57 To: sip@ietf.org Subject: [Sip] Question on draft-ietf-sip-outbound-20 draft: multiple = flowcreation =09 =09 Hi =20 As specified in section 3.3/3.4 of draft-ietf-sip-outbound-20 draft, = If a UA is configured with a outbound-proxy-set with two proxy uris: = "sip:primary.example.com" and "sip:secondary.example.com" And for = example, "sip:primary.example.com" got DNS resolved in to two SRV = records "Host1" and "Host2" and "sip:secondary.example.com" got DNS = resolved in to "Host3" and "Host4", Should UA create four FLOWs, One = with each host OR just two FLOWs, one with each proxy URI(i.e one flow = with either Host1 or Host2 and second flow with Host3 or Host4)? =20 Please clarify. =20 Regards Srikanth ------_=_NextPart_001_01CA2810.B82636C3 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I=20 honestly don't know why anybody would want to do both UDP and=20 TCP.
 
(In=20 other words, if you set up a TCP flow, I don't see a benefit in also = setting up=20 a UDP flow which you will have to maintain for keep = alives).
 

From: sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org] On Behalf Of Vavilapalli=20 Srikanth-A19563
Sent: Friday, August 28, 2009 = 07:46
To:=20 Audet, Francois (SC100:3055); sip@ietf.org; sip@core3.amsl.com;=20 sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip] = Question=20 on draft-ietf-sip-outbound-20 draft: = multipleflowcreation

Hi
 
Thanks for the reply..One more of = clarification=20 required..
 
So If UA wishes to create multiple = transport flows=20 with "sip:primary.example.com"(As specified in=20 draft-ietf-sip-outbound-20#section-13 to honor RFC3261 requirement for = message=20 size greater than MTU), would it be OK it one FLOW lands on = Host1=20 and other FLOW lands on Host2?
 
i.e for example if = "sip:primary.example.com" got=20 resolved into (IP1, Port1, TCP) -> (IP2, Port2, TCP) -> (IP2, = Port2,=20 UDP) -> (IP1, Port1, UDP) in that order, and if UA wises to create = both TCP=20 and UDP FLOWs with "sip:primary.example.com", then it starts creating = TCP FLOW=20 with (IP1, Port1, TCP) and can create a UDP FLOW with (IP2, Port2, = UDP) based=20 on RFC 3263 procedures. Is my understanding correct here? =
 
In the above example, if (IP1) is = down/crashed for=20 some reasons, then "sip:primary.example.com", can never use the TCP = FLOW for=20 transporting inbound messages to that UA (Even though the IP1 and IP2 = are=20 state synchronized) until User Agent detects the FLOW failure with = (IP1) and=20 re-create the TCP FLOW with (IP1 or IP2). Is my understanding correct=20 here?
 
Please clarify..
 
Regard
Srikanth

From: Francois Audet = [mailto:audet@nortel.com]=20
Sent: Thursday, August 27, 2009 9:22 PM
To: = Vavilapalli=20 Srikanth-A19563; sip@ietf.org
Subject: RE: [Sip] Question on = draft-ietf-sip-outbound-20 draft: multiple = flowcreation

You=20 would have 2. One for primary, and one for secondary. For = each one of=20 those, you would use normal RFC 3263 procedures for determining which = SRV=20 record to use.

From: sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org] On Behalf Of Vavilapalli=20 Srikanth-A19563
Sent: Thursday, August 27, 2009=20 07:57
To: sip@ietf.org
Subject: [Sip] Question = on=20 draft-ietf-sip-outbound-20 draft: multiple = flowcreation

Hi
 
As = specified in=20 section 3.3/3.4 of draft-ietf-sip-outbound-20 draft, If a UA is = configured=20 with a outbound-proxy-set with two proxy uris: = "sip:primary.example.com" and=20 "sip:secondary.example.com" And for example, = "sip:primary.example.com" got=20 DNS resolved in to two SRV records "Host1" and "Host2" and=20 "sip:secondary.example.com" got DNS resolved in to "Host3" and = "Host4",=20 Should UA create four FLOWs, One with each host OR just two = FLOWs, one=20 with each proxy URI(i.e one flow with either Host1 or Host2 and = second flow=20 with Host3 or Host4)?
 
Please=20 clarify.
 
Regards
Srikanth
------_=_NextPart_001_01CA2810.B82636C3-- From srikanthv@motorola.com Mon Aug 31 07:34:14 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8848D3A6E62 for ; Mon, 31 Aug 2009 07:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gjei0xY9tFUY for ; Mon, 31 Aug 2009 07:34:13 -0700 (PDT) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with ESMTP id 5E34328C21C for ; Mon, 31 Aug 2009 07:33:52 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: srikanthv@motorola.com X-Msg-Ref: server-12.tower-128.messagelabs.com!1251729237!16801336!1 X-StarScan-Version: 6.1.3; banners=-,-,- X-Originating-IP: [136.182.1.15] Received: (qmail 1396 invoked from network); 31 Aug 2009 14:33:58 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (136.182.1.15) by server-12.tower-128.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 31 Aug 2009 14:33:58 -0000 Received: from il27exr01.cig.mot.com ([10.17.196.70]) by motgate5.mot.com (8.14.3/8.14.3) with ESMTP id n7VEXrbZ015049 for ; Mon, 31 Aug 2009 07:33:57 -0700 (MST) Received: from il27vts02.mot.com (il27vts02.cig.mot.com [10.17.196.86]) by il27exr01.cig.mot.com (8.13.1/Vontu) with SMTP id n7VEXqCM013488 for ; Mon, 31 Aug 2009 09:33:52 -0500 (CDT) Received: from ZMY16EXM67.ds.mot.com (zmy16exm67.ap.mot.com [10.179.4.27]) by il27exr01.cig.mot.com (8.13.1/8.13.0) with ESMTP id n7VEXlgu013423 for ; Mon, 31 Aug 2009 09:33:51 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA2A48.0C9B6CCA" Date: Mon, 31 Aug 2009 22:33:45 +0800 Message-ID: <608D7BFF0D57794785CBC2C440BC4FA105811D7C@ZMY16EXM67.ds.mot.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1FB064B1@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Question on draft-ietf-sip-outbound-20 draft: multipleflowcreation Thread-Index: AconJq63dxYy8I81RQ26QF91DE+n/gABw+ZwACQRbAAAFJ6AYACL/fUQ References: <608D7BFF0D57794785CBC2C440BC4FA1058116D7@ZMY16EXM67.ds.mot.com><1ECE0EB50388174790F9694F77522CCF1FA69CD0@zrc2hxm0.corp.nortel.com> <608D7BFF0D57794785CBC2C440BC4FA1058119A2@ZMY16EXM67.ds.mot.com> <1ECE0EB50388174790F9694F77522CCF1FB064B1@zrc2hxm0.corp.nortel.com> From: "Vavilapalli Srikanth-A19563" To: "Francois Audet" , , , X-CFilter-Loop: Reflected Subject: Re: [Sip] Question on draft-ietf-sip-outbound-20 draft: multipleflowcreation X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2009 14:34:14 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA2A48.0C9B6CCA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable True, UDP flow may not be required if TCP flow has been setup to route incoming traffic towards UA. But Won't it be an additional bonus if UA creates a UDP FLOW in addition to TCP FLOW, so that network can still reach the UA over the other transport FLOW when one FLOW is down (Unless if both FLOWs got created with same host and all the FLOWs connected to that host is down)?=20 =20 Also assume a UA has some local policy to prefer UDP transport over TCP to transmit the outgoing SIP messages of size less than MTU. In such scenarios, UA might want to establish both UDP and TCP FLOWs with the same edge proxy and keep alive both the connections and use the corresponding FLOW based on DNS lookup preferences and User's local policy preferences to transport outgoing messages. ________________________________ From: Francois Audet [mailto:audet@nortel.com]=20 Sent: Saturday, August 29, 2009 12:23 AM To: Vavilapalli Srikanth-A19563; sip@ietf.org; sip@core3.amsl.com; sip-implementors@lists.cs.columbia.edu Subject: RE: [Sip] Question on draft-ietf-sip-outbound-20 draft: multipleflowcreation I honestly don't know why anybody would want to do both UDP and TCP. =20 (In other words, if you set up a TCP flow, I don't see a benefit in also setting up a UDP flow which you will have to maintain for keep alives). =20 ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Vavilapalli Srikanth-A19563 Sent: Friday, August 28, 2009 07:46 To: Audet, Francois (SC100:3055); sip@ietf.org; sip@core3.amsl.com; sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip] Question on draft-ietf-sip-outbound-20 draft: multipleflowcreation =09 =09 Hi =20 Thanks for the reply..One more of clarification required.. =20 So If UA wishes to create multiple transport flows with "sip:primary.example.com"(As specified in draft-ietf-sip-outbound-20#section-13 to honor RFC3261 requirement for message size greater than MTU), would it be OK it one FLOW lands on Host1 and other FLOW lands on Host2? =20 i.e for example if "sip:primary.example.com" got resolved into (IP1, Port1, TCP) -> (IP2, Port2, TCP) -> (IP2, Port2, UDP) -> (IP1, Port1, UDP) in that order, and if UA wises to create both TCP and UDP FLOWs with "sip:primary.example.com", then it starts creating TCP FLOW with (IP1, Port1, TCP) and can create a UDP FLOW with (IP2, Port2, UDP) based on RFC 3263 procedures. Is my understanding correct here?=20 =20 In the above example, if (IP1) is down/crashed for some reasons, then "sip:primary.example.com", can never use the TCP FLOW for transporting inbound messages to that UA (Even though the IP1 and IP2 are state synchronized) until User Agent detects the FLOW failure with (IP1) and re-create the TCP FLOW with (IP1 or IP2). Is my understanding correct here? =20 Please clarify.. =20 Regard Srikanth ________________________________ From: Francois Audet [mailto:audet@nortel.com]=20 Sent: Thursday, August 27, 2009 9:22 PM To: Vavilapalli Srikanth-A19563; sip@ietf.org Subject: RE: [Sip] Question on draft-ietf-sip-outbound-20 draft: multiple flowcreation =09 =09 You would have 2. One for primary, and one for secondary. For each one of those, you would use normal RFC 3263 procedures for determining which SRV record to use. ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Vavilapalli Srikanth-A19563 Sent: Thursday, August 27, 2009 07:57 To: sip@ietf.org Subject: [Sip] Question on draft-ietf-sip-outbound-20 draft: multiple flowcreation =09 =09 Hi =20 As specified in section 3.3/3.4 of draft-ietf-sip-outbound-20 draft, If a UA is configured with a outbound-proxy-set with two proxy uris: "sip:primary.example.com" and "sip:secondary.example.com" And for example, "sip:primary.example.com" got DNS resolved in to two SRV records "Host1" and "Host2" and "sip:secondary.example.com" got DNS resolved in to "Host3" and "Host4", Should UA create four FLOWs, One with each host OR just two FLOWs, one with each proxy URI(i.e one flow with either Host1 or Host2 and second flow with Host3 or Host4)? =20 Please clarify. =20 Regards Srikanth ------_=_NextPart_001_01CA2A48.0C9B6CCA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
True, UDP flow may not be required if TCP flow = has been=20 setup to route incoming traffic towards UA. But Won't it be an = additional bonus=20 if UA creates a UDP FLOW in addition to TCP FLOW, so that network can = still=20 reach the UA over the other transport FLOW when one FLOW is down (Unless = if both=20 FLOWs got created with same host and all the FLOWs connected to=20 that host is down)? 
 
Also assume=20 a UA has some local policy to prefer UDP transport over TCP to = transmit the outgoing SIP messages of size less than MTU. In = such=20 scenarios, UA might want to establish both UDP and TCP FLOWs = with the=20 same edge proxy and keep alive both the connections and use the = corresponding=20 FLOW based on DNS lookup preferences and User's local policy preferences = to=20 transport outgoing messages.

From: Francois Audet = [mailto:audet@nortel.com]=20
Sent: Saturday, August 29, 2009 12:23 AM
To: = Vavilapalli=20 Srikanth-A19563; sip@ietf.org; sip@core3.amsl.com;=20 sip-implementors@lists.cs.columbia.edu
Subject: RE: [Sip] = Question on=20 draft-ietf-sip-outbound-20 draft: = multipleflowcreation

I=20 honestly don't know why anybody would want to do both UDP and=20 TCP.
 
(In=20 other words, if you set up a TCP flow, I don't see a benefit in also = setting up=20 a UDP flow which you will have to maintain for keep = alives).
 

From: sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org] On Behalf Of Vavilapalli=20 Srikanth-A19563
Sent: Friday, August 28, 2009 = 07:46
To:=20 Audet, Francois (SC100:3055); sip@ietf.org; sip@core3.amsl.com;=20 sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip] = Question=20 on draft-ietf-sip-outbound-20 draft: = multipleflowcreation

Hi
 
Thanks for the reply..One more of = clarification=20 required..
 
So If UA wishes to create multiple = transport flows=20 with "sip:primary.example.com"(As specified in=20 draft-ietf-sip-outbound-20#section-13 to honor RFC3261 requirement for = message=20 size greater than MTU), would it be OK it one FLOW lands on = Host1=20 and other FLOW lands on Host2?
 
i.e for example if = "sip:primary.example.com" got=20 resolved into (IP1, Port1, TCP) -> (IP2, Port2, TCP) -> (IP2, = Port2,=20 UDP) -> (IP1, Port1, UDP) in that order, and if UA wises to create = both TCP=20 and UDP FLOWs with "sip:primary.example.com", then it starts creating = TCP FLOW=20 with (IP1, Port1, TCP) and can create a UDP FLOW with (IP2, Port2, = UDP) based=20 on RFC 3263 procedures. Is my understanding correct here? =
 
In the above example, if (IP1) is = down/crashed for=20 some reasons, then "sip:primary.example.com", can never use the TCP = FLOW for=20 transporting inbound messages to that UA (Even though the IP1 and IP2 = are=20 state synchronized) until User Agent detects the FLOW failure with = (IP1) and=20 re-create the TCP FLOW with (IP1 or IP2). Is my understanding correct=20 here?
 
Please clarify..
 
Regard
Srikanth

From: Francois Audet = [mailto:audet@nortel.com]=20
Sent: Thursday, August 27, 2009 9:22 PM
To: = Vavilapalli=20 Srikanth-A19563; sip@ietf.org
Subject: RE: [Sip] Question on = draft-ietf-sip-outbound-20 draft: multiple = flowcreation

You=20 would have 2. One for primary, and one for secondary. For = each one of=20 those, you would use normal RFC 3263 procedures for determining which = SRV=20 record to use.

From: sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org] On Behalf Of Vavilapalli=20 Srikanth-A19563
Sent: Thursday, August 27, 2009=20 07:57
To: sip@ietf.org
Subject: [Sip] Question = on=20 draft-ietf-sip-outbound-20 draft: multiple = flowcreation

Hi
 
As = specified in=20 section 3.3/3.4 of draft-ietf-sip-outbound-20 draft, If a UA is = configured=20 with a outbound-proxy-set with two proxy uris: = "sip:primary.example.com" and=20 "sip:secondary.example.com" And for example, = "sip:primary.example.com" got=20 DNS resolved in to two SRV records "Host1" and "Host2" and=20 "sip:secondary.example.com" got DNS resolved in to "Host3" and = "Host4",=20 Should UA create four FLOWs, One with each host OR just two = FLOWs, one=20 with each proxy URI(i.e one flow with either Host1 or Host2 and = second flow=20 with Host3 or Host4)?
 
Please=20 clarify.
 
Regards
Srikanth
------_=_NextPart_001_01CA2A48.0C9B6CCA-- From srikanthv@motorola.com Mon Aug 31 07:34:19 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE9D53A68D1 for ; Mon, 31 Aug 2009 07:34:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0fYG4e6U5iLF for ; Mon, 31 Aug 2009 07:34:19 -0700 (PDT) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with ESMTP id 830F73A6E55 for ; Mon, 31 Aug 2009 07:34:09 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: srikanthv@motorola.com X-Msg-Ref: server-6.tower-128.messagelabs.com!1251729250!3522716!1 X-StarScan-Version: 6.1.3; banners=-,-,- X-Originating-IP: [136.182.1.13] Received: (qmail 12514 invoked from network); 31 Aug 2009 14:34:11 -0000 Received: from motgate3.mot.com (HELO motgate3.mot.com) (136.182.1.13) by server-6.tower-128.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 31 Aug 2009 14:34:11 -0000 Received: from il27exr04.cig.mot.com ([10.17.196.73]) by motgate3.mot.com (8.14.3/8.14.3) with ESMTP id n7VEYAjr024878 for ; Mon, 31 Aug 2009 07:34:10 -0700 (MST) Received: from az10vts04.mot.com (il27vts04.cig.mot.com [10.17.196.88]) by il27exr04.cig.mot.com (8.13.1/Vontu) with SMTP id n7VEYAJ1010235 for ; Mon, 31 Aug 2009 09:34:10 -0500 (CDT) Received: from ZMY16EXM67.ds.mot.com (zmy16exm67.ap.mot.com [10.179.4.27]) by il27exr04.cig.mot.com (8.13.1/8.13.0) with ESMTP id n7VEY8gi010203 for ; Mon, 31 Aug 2009 09:34:09 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA2A48.0C9B6CCA" Date: Mon, 31 Aug 2009 22:33:45 +0800 Message-ID: <608D7BFF0D57794785CBC2C440BC4FA105811D7C@ZMY16EXM67.ds.mot.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1FB064B1@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Question on draft-ietf-sip-outbound-20 draft: multipleflowcreation Thread-Index: AconJq63dxYy8I81RQ26QF91DE+n/gABw+ZwACQRbAAAFJ6AYACL/fUQ References: <608D7BFF0D57794785CBC2C440BC4FA1058116D7@ZMY16EXM67.ds.mot.com><1ECE0EB50388174790F9694F77522CCF1FA69CD0@zrc2hxm0.corp.nortel.com> <608D7BFF0D57794785CBC2C440BC4FA1058119A2@ZMY16EXM67.ds.mot.com> <1ECE0EB50388174790F9694F77522CCF1FB064B1@zrc2hxm0.corp.nortel.com> From: "Vavilapalli Srikanth-A19563" To: "Francois Audet" , , , X-CFilter-Loop: Reflected Subject: Re: [Sip] Question on draft-ietf-sip-outbound-20 draft: multipleflowcreation X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2009 14:34:20 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA2A48.0C9B6CCA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable True, UDP flow may not be required if TCP flow has been setup to route incoming traffic towards UA. But Won't it be an additional bonus if UA creates a UDP FLOW in addition to TCP FLOW, so that network can still reach the UA over the other transport FLOW when one FLOW is down (Unless if both FLOWs got created with same host and all the FLOWs connected to that host is down)?=20 =20 Also assume a UA has some local policy to prefer UDP transport over TCP to transmit the outgoing SIP messages of size less than MTU. In such scenarios, UA might want to establish both UDP and TCP FLOWs with the same edge proxy and keep alive both the connections and use the corresponding FLOW based on DNS lookup preferences and User's local policy preferences to transport outgoing messages. ________________________________ From: Francois Audet [mailto:audet@nortel.com]=20 Sent: Saturday, August 29, 2009 12:23 AM To: Vavilapalli Srikanth-A19563; sip@ietf.org; sip@core3.amsl.com; sip-implementors@lists.cs.columbia.edu Subject: RE: [Sip] Question on draft-ietf-sip-outbound-20 draft: multipleflowcreation I honestly don't know why anybody would want to do both UDP and TCP. =20 (In other words, if you set up a TCP flow, I don't see a benefit in also setting up a UDP flow which you will have to maintain for keep alives). =20 ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Vavilapalli Srikanth-A19563 Sent: Friday, August 28, 2009 07:46 To: Audet, Francois (SC100:3055); sip@ietf.org; sip@core3.amsl.com; sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip] Question on draft-ietf-sip-outbound-20 draft: multipleflowcreation =09 =09 Hi =20 Thanks for the reply..One more of clarification required.. =20 So If UA wishes to create multiple transport flows with "sip:primary.example.com"(As specified in draft-ietf-sip-outbound-20#section-13 to honor RFC3261 requirement for message size greater than MTU), would it be OK it one FLOW lands on Host1 and other FLOW lands on Host2? =20 i.e for example if "sip:primary.example.com" got resolved into (IP1, Port1, TCP) -> (IP2, Port2, TCP) -> (IP2, Port2, UDP) -> (IP1, Port1, UDP) in that order, and if UA wises to create both TCP and UDP FLOWs with "sip:primary.example.com", then it starts creating TCP FLOW with (IP1, Port1, TCP) and can create a UDP FLOW with (IP2, Port2, UDP) based on RFC 3263 procedures. Is my understanding correct here?=20 =20 In the above example, if (IP1) is down/crashed for some reasons, then "sip:primary.example.com", can never use the TCP FLOW for transporting inbound messages to that UA (Even though the IP1 and IP2 are state synchronized) until User Agent detects the FLOW failure with (IP1) and re-create the TCP FLOW with (IP1 or IP2). Is my understanding correct here? =20 Please clarify.. =20 Regard Srikanth ________________________________ From: Francois Audet [mailto:audet@nortel.com]=20 Sent: Thursday, August 27, 2009 9:22 PM To: Vavilapalli Srikanth-A19563; sip@ietf.org Subject: RE: [Sip] Question on draft-ietf-sip-outbound-20 draft: multiple flowcreation =09 =09 You would have 2. One for primary, and one for secondary. For each one of those, you would use normal RFC 3263 procedures for determining which SRV record to use. ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Vavilapalli Srikanth-A19563 Sent: Thursday, August 27, 2009 07:57 To: sip@ietf.org Subject: [Sip] Question on draft-ietf-sip-outbound-20 draft: multiple flowcreation =09 =09 Hi =20 As specified in section 3.3/3.4 of draft-ietf-sip-outbound-20 draft, If a UA is configured with a outbound-proxy-set with two proxy uris: "sip:primary.example.com" and "sip:secondary.example.com" And for example, "sip:primary.example.com" got DNS resolved in to two SRV records "Host1" and "Host2" and "sip:secondary.example.com" got DNS resolved in to "Host3" and "Host4", Should UA create four FLOWs, One with each host OR just two FLOWs, one with each proxy URI(i.e one flow with either Host1 or Host2 and second flow with Host3 or Host4)? =20 Please clarify. =20 Regards Srikanth ------_=_NextPart_001_01CA2A48.0C9B6CCA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
True, UDP flow may not be required if TCP flow = has been=20 setup to route incoming traffic towards UA. But Won't it be an = additional bonus=20 if UA creates a UDP FLOW in addition to TCP FLOW, so that network can = still=20 reach the UA over the other transport FLOW when one FLOW is down (Unless = if both=20 FLOWs got created with same host and all the FLOWs connected to=20 that host is down)? 
 
Also assume=20 a UA has some local policy to prefer UDP transport over TCP to = transmit the outgoing SIP messages of size less than MTU. In = such=20 scenarios, UA might want to establish both UDP and TCP FLOWs = with the=20 same edge proxy and keep alive both the connections and use the = corresponding=20 FLOW based on DNS lookup preferences and User's local policy preferences = to=20 transport outgoing messages.

From: Francois Audet = [mailto:audet@nortel.com]=20
Sent: Saturday, August 29, 2009 12:23 AM
To: = Vavilapalli=20 Srikanth-A19563; sip@ietf.org; sip@core3.amsl.com;=20 sip-implementors@lists.cs.columbia.edu
Subject: RE: [Sip] = Question on=20 draft-ietf-sip-outbound-20 draft: = multipleflowcreation

I=20 honestly don't know why anybody would want to do both UDP and=20 TCP.
 
(In=20 other words, if you set up a TCP flow, I don't see a benefit in also = setting up=20 a UDP flow which you will have to maintain for keep = alives).
 

From: sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org] On Behalf Of Vavilapalli=20 Srikanth-A19563
Sent: Friday, August 28, 2009 = 07:46
To:=20 Audet, Francois (SC100:3055); sip@ietf.org; sip@core3.amsl.com;=20 sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip] = Question=20 on draft-ietf-sip-outbound-20 draft: = multipleflowcreation

Hi
 
Thanks for the reply..One more of = clarification=20 required..
 
So If UA wishes to create multiple = transport flows=20 with "sip:primary.example.com"(As specified in=20 draft-ietf-sip-outbound-20#section-13 to honor RFC3261 requirement for = message=20 size greater than MTU), would it be OK it one FLOW lands on = Host1=20 and other FLOW lands on Host2?
 
i.e for example if = "sip:primary.example.com" got=20 resolved into (IP1, Port1, TCP) -> (IP2, Port2, TCP) -> (IP2, = Port2,=20 UDP) -> (IP1, Port1, UDP) in that order, and if UA wises to create = both TCP=20 and UDP FLOWs with "sip:primary.example.com", then it starts creating = TCP FLOW=20 with (IP1, Port1, TCP) and can create a UDP FLOW with (IP2, Port2, = UDP) based=20 on RFC 3263 procedures. Is my understanding correct here? =
 
In the above example, if (IP1) is = down/crashed for=20 some reasons, then "sip:primary.example.com", can never use the TCP = FLOW for=20 transporting inbound messages to that UA (Even though the IP1 and IP2 = are=20 state synchronized) until User Agent detects the FLOW failure with = (IP1) and=20 re-create the TCP FLOW with (IP1 or IP2). Is my understanding correct=20 here?
 
Please clarify..
 
Regard
Srikanth

From: Francois Audet = [mailto:audet@nortel.com]=20
Sent: Thursday, August 27, 2009 9:22 PM
To: = Vavilapalli=20 Srikanth-A19563; sip@ietf.org
Subject: RE: [Sip] Question on = draft-ietf-sip-outbound-20 draft: multiple = flowcreation

You=20 would have 2. One for primary, and one for secondary. For = each one of=20 those, you would use normal RFC 3263 procedures for determining which = SRV=20 record to use.

From: sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org] On Behalf Of Vavilapalli=20 Srikanth-A19563
Sent: Thursday, August 27, 2009=20 07:57
To: sip@ietf.org
Subject: [Sip] Question = on=20 draft-ietf-sip-outbound-20 draft: multiple = flowcreation

Hi
 
As = specified in=20 section 3.3/3.4 of draft-ietf-sip-outbound-20 draft, If a UA is = configured=20 with a outbound-proxy-set with two proxy uris: = "sip:primary.example.com" and=20 "sip:secondary.example.com" And for example, = "sip:primary.example.com" got=20 DNS resolved in to two SRV records "Host1" and "Host2" and=20 "sip:secondary.example.com" got DNS resolved in to "Host3" and = "Host4",=20 Should UA create four FLOWs, One with each host OR just two = FLOWs, one=20 with each proxy URI(i.e one flow with either Host1 or Host2 and = second flow=20 with Host3 or Host4)?
 
Please=20 clarify.
 
Regards
Srikanth
------_=_NextPart_001_01CA2A48.0C9B6CCA-- From scott.lawrence@nortel.com Mon Aug 31 09:31:05 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FFD628C39F for ; Mon, 31 Aug 2009 09:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.864 X-Spam-Level: X-Spam-Status: No, score=-5.864 tagged_above=-999 required=5 tests=[AWL=0.735, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ixzHaXFkzqCp for ; Mon, 31 Aug 2009 09:31:04 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 171CF28C399 for ; Mon, 31 Aug 2009 09:31:03 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n7VGV7118181; Mon, 31 Aug 2009 16:31:07 GMT Received: from [127.0.0.1] ([47.17.25.99]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 31 Aug 2009 12:31:06 -0400 From: "Scott Lawrence" To: Vavilapalli Srikanth-A19563 In-Reply-To: <608D7BFF0D57794785CBC2C440BC4FA105811D7C@ZMY16EXM67.ds.mot.com> References: <608D7BFF0D57794785CBC2C440BC4FA1058116D7@ZMY16EXM67.ds.mot.com> <1ECE0EB50388174790F9694F77522CCF1FA69CD0@zrc2hxm0.corp.nortel.com> <608D7BFF0D57794785CBC2C440BC4FA1058119A2@ZMY16EXM67.ds.mot.com> <1ECE0EB50388174790F9694F77522CCF1FB064B1@zrc2hxm0.corp.nortel.com> <608D7BFF0D57794785CBC2C440BC4FA105811D7C@ZMY16EXM67.ds.mot.com> Content-Type: text/plain Organization: Nortel Networks Date: Mon, 31 Aug 2009 12:31:05 -0400 Message-Id: <1251736265.19992.106.camel@scott> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 (2.24.5-2.fc10) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Aug 2009 16:31:06.0717 (UTC) FILETIME=[708BA8D0:01CA2A58] Cc: sip@ietf.org, Francois Audet , sip@core3.amsl.com, sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip] Question on draft-ietf-sip-outbound-20 draft: multipleflowcreation X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2009 16:31:05 -0000 On Mon, 2009-08-31 at 22:33 +0800, Vavilapalli Srikanth-A19563 wrote: > True, UDP flow may not be required if TCP flow has been setup to route > incoming traffic towards UA. But Won't it be an additional bonus if UA > creates a UDP FLOW in addition to TCP FLOW, so that network can still > reach the UA over the other transport FLOW when one FLOW is down > (Unless if both FLOWs got created with same host and all the FLOWs > connected to that host is down)? > > Also assume a UA has some local policy to prefer UDP transport over > TCP to transmit the outgoing SIP messages of size less than MTU. In > such scenarios, UA might want to establish both UDP and TCP FLOWs with > the same edge proxy and keep alive both the connections and use the > corresponding FLOW based on DNS lookup preferences and User's local > policy preferences to transport outgoing messages. That would not be a very sensible proxy if the phone is behind a NAT and supports TCP. From scott.lawrence@nortel.com Mon Aug 31 09:45:18 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10CDD3A6E7C for ; Mon, 31 Aug 2009 09:45:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.232 X-Spam-Level: X-Spam-Status: No, score=-6.232 tagged_above=-999 required=5 tests=[AWL=0.368, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oaLh0aaYZoOM for ; Mon, 31 Aug 2009 09:45:17 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 291153A6E7B for ; Mon, 31 Aug 2009 09:45:16 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n7VGV7118181; Mon, 31 Aug 2009 16:31:07 GMT Received: from [127.0.0.1] ([47.17.25.99]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 31 Aug 2009 12:31:06 -0400 From: "Scott Lawrence" To: Vavilapalli Srikanth-A19563 In-Reply-To: <608D7BFF0D57794785CBC2C440BC4FA105811D7C@ZMY16EXM67.ds.mot.com> References: <608D7BFF0D57794785CBC2C440BC4FA1058116D7@ZMY16EXM67.ds.mot.com> <1ECE0EB50388174790F9694F77522CCF1FA69CD0@zrc2hxm0.corp.nortel.com> <608D7BFF0D57794785CBC2C440BC4FA1058119A2@ZMY16EXM67.ds.mot.com> <1ECE0EB50388174790F9694F77522CCF1FB064B1@zrc2hxm0.corp.nortel.com> <608D7BFF0D57794785CBC2C440BC4FA105811D7C@ZMY16EXM67.ds.mot.com> Content-Type: text/plain Organization: Nortel Networks Date: Mon, 31 Aug 2009 12:31:05 -0400 Message-Id: <1251736265.19992.106.camel@scott> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 (2.24.5-2.fc10) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Aug 2009 16:31:06.0717 (UTC) FILETIME=[708BA8D0:01CA2A58] Cc: sip@ietf.org, Francois Audet , sip@core3.amsl.com, sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip] Question on draft-ietf-sip-outbound-20 draft: multipleflowcreation X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2009 16:45:18 -0000 On Mon, 2009-08-31 at 22:33 +0800, Vavilapalli Srikanth-A19563 wrote: > True, UDP flow may not be required if TCP flow has been setup to route > incoming traffic towards UA. But Won't it be an additional bonus if UA > creates a UDP FLOW in addition to TCP FLOW, so that network can still > reach the UA over the other transport FLOW when one FLOW is down > (Unless if both FLOWs got created with same host and all the FLOWs > connected to that host is down)? > > Also assume a UA has some local policy to prefer UDP transport over > TCP to transmit the outgoing SIP messages of size less than MTU. In > such scenarios, UA might want to establish both UDP and TCP FLOWs with > the same edge proxy and keep alive both the connections and use the > corresponding FLOW based on DNS lookup preferences and User's local > policy preferences to transport outgoing messages. That would not be a very sensible proxy if the phone is behind a NAT and supports TCP. From scott.lawrence@nortel.com Mon Aug 31 09:55:48 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 005373A6A0E for ; Mon, 31 Aug 2009 09:55:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.354 X-Spam-Level: X-Spam-Status: No, score=-6.354 tagged_above=-999 required=5 tests=[AWL=0.245, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eSXZwvDFzL7C for ; Mon, 31 Aug 2009 09:55:47 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 0F5BD3A68F5 for ; Mon, 31 Aug 2009 09:55:46 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n7VGrgY02551; Mon, 31 Aug 2009 16:53:42 GMT Received: from [127.0.0.1] ([47.17.25.99]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 31 Aug 2009 12:55:52 -0400 From: "Scott Lawrence" To: Vavilapalli Srikanth-A19563 In-Reply-To: <1251736265.19992.106.camel@scott> References: <608D7BFF0D57794785CBC2C440BC4FA1058116D7@ZMY16EXM67.ds.mot.com> <1ECE0EB50388174790F9694F77522CCF1FA69CD0@zrc2hxm0.corp.nortel.com> <608D7BFF0D57794785CBC2C440BC4FA1058119A2@ZMY16EXM67.ds.mot.com> <1ECE0EB50388174790F9694F77522CCF1FB064B1@zrc2hxm0.corp.nortel.com> <608D7BFF0D57794785CBC2C440BC4FA105811D7C@ZMY16EXM67.ds.mot.com> <1251736265.19992.106.camel@scott> Content-Type: text/plain Organization: Nortel Networks Date: Mon, 31 Aug 2009 12:55:51 -0400 Message-Id: <1251737751.19992.132.camel@scott> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 (2.24.5-2.fc10) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Aug 2009 16:55:52.0568 (UTC) FILETIME=[E62E8780:01CA2A5B] Cc: sip@ietf.org, Francois Audet , sip@core3.amsl.com, sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip] Question on draft-ietf-sip-outbound-20 draft: multipleflowcreation X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2009 16:55:48 -0000 On Mon, 2009-08-31 at 12:31 -0400, Scott Lawrence wrote: > On Mon, 2009-08-31 at 22:33 +0800, Vavilapalli Srikanth-A19563 wrote: > > True, UDP flow may not be required if TCP flow has been setup to route > > incoming traffic towards UA. But Won't it be an additional bonus if UA > > creates a UDP FLOW in addition to TCP FLOW, so that network can still > > reach the UA over the other transport FLOW when one FLOW is down > > (Unless if both FLOWs got created with same host and all the FLOWs > > connected to that host is down)? > > > > Also assume a UA has some local policy to prefer UDP transport over > > TCP to transmit the outgoing SIP messages of size less than MTU. In > > such scenarios, UA might want to establish both UDP and TCP FLOWs with > > the same edge proxy and keep alive both the connections and use the > > corresponding FLOW based on DNS lookup preferences and User's local > > policy preferences to transport outgoing messages. > > That would not be a very sensible proxy if the phone is behind a NAT and > supports TCP. s/proxy/policy/ From scott.lawrence@nortel.com Mon Aug 31 09:55:56 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AF2528C3B4 for ; Mon, 31 Aug 2009 09:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.354 X-Spam-Level: X-Spam-Status: No, score=-6.354 tagged_above=-999 required=5 tests=[AWL=0.245, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJTj-mpQO1xn for ; Mon, 31 Aug 2009 09:55:56 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 235FD3A6A0E for ; Mon, 31 Aug 2009 09:55:56 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n7VGrgY02551; Mon, 31 Aug 2009 16:53:42 GMT Received: from [127.0.0.1] ([47.17.25.99]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 31 Aug 2009 12:55:52 -0400 From: "Scott Lawrence" To: Vavilapalli Srikanth-A19563 In-Reply-To: <1251736265.19992.106.camel@scott> References: <608D7BFF0D57794785CBC2C440BC4FA1058116D7@ZMY16EXM67.ds.mot.com> <1ECE0EB50388174790F9694F77522CCF1FA69CD0@zrc2hxm0.corp.nortel.com> <608D7BFF0D57794785CBC2C440BC4FA1058119A2@ZMY16EXM67.ds.mot.com> <1ECE0EB50388174790F9694F77522CCF1FB064B1@zrc2hxm0.corp.nortel.com> <608D7BFF0D57794785CBC2C440BC4FA105811D7C@ZMY16EXM67.ds.mot.com> <1251736265.19992.106.camel@scott> Content-Type: text/plain Organization: Nortel Networks Date: Mon, 31 Aug 2009 12:55:51 -0400 Message-Id: <1251737751.19992.132.camel@scott> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 (2.24.5-2.fc10) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Aug 2009 16:55:52.0568 (UTC) FILETIME=[E62E8780:01CA2A5B] Cc: sip@ietf.org, Francois Audet , sip@core3.amsl.com, sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip] Question on draft-ietf-sip-outbound-20 draft: multipleflowcreation X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2009 16:55:56 -0000 On Mon, 2009-08-31 at 12:31 -0400, Scott Lawrence wrote: > On Mon, 2009-08-31 at 22:33 +0800, Vavilapalli Srikanth-A19563 wrote: > > True, UDP flow may not be required if TCP flow has been setup to route > > incoming traffic towards UA. But Won't it be an additional bonus if UA > > creates a UDP FLOW in addition to TCP FLOW, so that network can still > > reach the UA over the other transport FLOW when one FLOW is down > > (Unless if both FLOWs got created with same host and all the FLOWs > > connected to that host is down)? > > > > Also assume a UA has some local policy to prefer UDP transport over > > TCP to transmit the outgoing SIP messages of size less than MTU. In > > such scenarios, UA might want to establish both UDP and TCP FLOWs with > > the same edge proxy and keep alive both the connections and use the > > corresponding FLOW based on DNS lookup preferences and User's local > > policy preferences to transport outgoing messages. > > That would not be a very sensible proxy if the phone is behind a NAT and > supports TCP. s/proxy/policy/ From AUDET@nortel.com Mon Aug 31 10:11:02 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEB5A28C3DE for ; Mon, 31 Aug 2009 10:11:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.461 X-Spam-Level: X-Spam-Status: No, score=-6.461 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N51GtIWbwVCC for ; Mon, 31 Aug 2009 10:11:01 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 9437428C3E0 for ; Mon, 31 Aug 2009 10:11:01 -0700 (PDT) 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 n7VHB6101736; Mon, 31 Aug 2009 17:11:06 GMT 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: Mon, 31 Aug 2009 12:11:03 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1FB6CCE5@zrc2hxm0.corp.nortel.com> In-Reply-To: <1251737751.19992.132.camel@scott> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Question on draft-ietf-sip-outbound-20 draft: multipleflowcreation Thread-Index: AcoqW+jNRTPQ1zUnQEC3VhV8Ai+kcwAAd9Qg References: <608D7BFF0D57794785CBC2C440BC4FA1058116D7@ZMY16EXM67.ds.mot.com> <1ECE0EB50388174790F9694F77522CCF1FA69CD0@zrc2hxm0.corp.nortel.com> <608D7BFF0D57794785CBC2C440BC4FA1058119A2@ZMY16EXM67.ds.mot.com> <1ECE0EB50388174790F9694F77522CCF1FB064B1@zrc2hxm0.corp.nortel.com> <608D7BFF0D57794785CBC2C440BC4FA105811D7C@ZMY16EXM67.ds.mot.com> <1251736265.19992.106.camel@scott> <1251737751.19992.132.camel@scott> From: "Francois Audet" To: "Scott Lawrence" , "Vavilapalli Srikanth-A19563" Cc: sip@ietf.org, sip@core3.amsl.com, sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip] Question on draft-ietf-sip-outbound-20 draft: multipleflowcreation X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2009 17:11:02 -0000 I would tend to disagree that a policy of "Use UDP preferably and switch to TCP if message is too big" is a good policy. Especially considering that you'd have to keep the TCP connection alive anyways. I believe that always using the TCP connection in this case would make more sense. But it's definitively legal. > -----Original Message----- > From: Lawrence, Scott (BL60:9D30)=20 > Sent: Monday, August 31, 2009 09:56 > To: Vavilapalli Srikanth-A19563 > Cc: Audet, Francois (SC100:3055); sip@ietf.org;=20 > sip@core3.amsl.com; sip-implementors@lists.cs.columbia.edu > Subject: Re: [Sip] Question on draft-ietf-sip-outbound-20=20 > draft: multipleflowcreation >=20 > On Mon, 2009-08-31 at 12:31 -0400, Scott Lawrence wrote: > > On Mon, 2009-08-31 at 22:33 +0800, Vavilapalli=20 > Srikanth-A19563 wrote: > > > True, UDP flow may not be required if TCP flow has been setup to=20 > > > route incoming traffic towards UA. But Won't it be an additional=20 > > > bonus if UA creates a UDP FLOW in addition to TCP FLOW, so that=20 > > > network can still reach the UA over the other transport FLOW when=20 > > > one FLOW is down (Unless if both FLOWs got created with same host=20 > > > and all the FLOWs connected to that host is down)? > > > =20 > > > Also assume a UA has some local policy to prefer UDP=20 > transport over=20 > > > TCP to transmit the outgoing SIP messages of size less=20 > than MTU. In=20 > > > such scenarios, UA might want to establish both UDP and TCP FLOWs=20 > > > with the same edge proxy and keep alive both the=20 > connections and use=20 > > > the corresponding FLOW based on DNS lookup preferences and User's=20 > > > local policy preferences to transport outgoing messages. > >=20 > > That would not be a very sensible proxy if the phone is=20 > behind a NAT=20 > > and supports TCP. >=20 > s/proxy/policy/ >=20 >=20 >=20 >=20 From AUDET@nortel.com Mon Aug 31 10:15:20 2009 Return-Path: X-Original-To: sip@core3.amsl.com Delivered-To: sip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40C5D28C3E9 for ; Mon, 31 Aug 2009 10:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.461 X-Spam-Level: X-Spam-Status: No, score=-6.461 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Liyr+AkxYgYu for ; Mon, 31 Aug 2009 10:15:20 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id B2D4C28C3FA for ; Mon, 31 Aug 2009 10:15:19 -0700 (PDT) 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 n7VHB6101736; Mon, 31 Aug 2009 17:11:06 GMT 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: Mon, 31 Aug 2009 12:11:03 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1FB6CCE5@zrc2hxm0.corp.nortel.com> In-Reply-To: <1251737751.19992.132.camel@scott> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Question on draft-ietf-sip-outbound-20 draft: multipleflowcreation Thread-Index: AcoqW+jNRTPQ1zUnQEC3VhV8Ai+kcwAAd9Qg References: <608D7BFF0D57794785CBC2C440BC4FA1058116D7@ZMY16EXM67.ds.mot.com> <1ECE0EB50388174790F9694F77522CCF1FA69CD0@zrc2hxm0.corp.nortel.com> <608D7BFF0D57794785CBC2C440BC4FA1058119A2@ZMY16EXM67.ds.mot.com> <1ECE0EB50388174790F9694F77522CCF1FB064B1@zrc2hxm0.corp.nortel.com> <608D7BFF0D57794785CBC2C440BC4FA105811D7C@ZMY16EXM67.ds.mot.com> <1251736265.19992.106.camel@scott> <1251737751.19992.132.camel@scott> From: "Francois Audet" To: "Scott Lawrence" , "Vavilapalli Srikanth-A19563" Cc: sip@ietf.org, sip@core3.amsl.com, sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip] Question on draft-ietf-sip-outbound-20 draft: multipleflowcreation X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2009 17:15:20 -0000 I would tend to disagree that a policy of "Use UDP preferably and switch to TCP if message is too big" is a good policy. Especially considering that you'd have to keep the TCP connection alive anyways. I believe that always using the TCP connection in this case would make more sense. But it's definitively legal. > -----Original Message----- > From: Lawrence, Scott (BL60:9D30)=20 > Sent: Monday, August 31, 2009 09:56 > To: Vavilapalli Srikanth-A19563 > Cc: Audet, Francois (SC100:3055); sip@ietf.org;=20 > sip@core3.amsl.com; sip-implementors@lists.cs.columbia.edu > Subject: Re: [Sip] Question on draft-ietf-sip-outbound-20=20 > draft: multipleflowcreation >=20 > On Mon, 2009-08-31 at 12:31 -0400, Scott Lawrence wrote: > > On Mon, 2009-08-31 at 22:33 +0800, Vavilapalli=20 > Srikanth-A19563 wrote: > > > True, UDP flow may not be required if TCP flow has been setup to=20 > > > route incoming traffic towards UA. But Won't it be an additional=20 > > > bonus if UA creates a UDP FLOW in addition to TCP FLOW, so that=20 > > > network can still reach the UA over the other transport FLOW when=20 > > > one FLOW is down (Unless if both FLOWs got created with same host=20 > > > and all the FLOWs connected to that host is down)? > > > =20 > > > Also assume a UA has some local policy to prefer UDP=20 > transport over=20 > > > TCP to transmit the outgoing SIP messages of size less=20 > than MTU. In=20 > > > such scenarios, UA might want to establish both UDP and TCP FLOWs=20 > > > with the same edge proxy and keep alive both the=20 > connections and use=20 > > > the corresponding FLOW based on DNS lookup preferences and User's=20 > > > local policy preferences to transport outgoing messages. > >=20 > > That would not be a very sensible proxy if the phone is=20 > behind a NAT=20 > > and supports TCP. >=20 > s/proxy/policy/ >=20 >=20 >=20 >=20