From nobody Tue Mar 4 03:23:13 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B8811A06E8; Tue, 4 Mar 2014 03:23:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j4qRdytzvzC0; Tue, 4 Mar 2014 03:23:10 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id 053DC1A06E5; Tue, 4 Mar 2014 03:23:10 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id D979F7FC38D; Tue, 4 Mar 2014 03:23:06 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20140304112306.D979F7FC38D@rfc-editor.org> Date: Tue, 4 Mar 2014 03:23:06 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/dNh6I-R6AKSWf4rkKR8Y6aD-n0c Cc: drafts-update-ref@iana.org, sipcore@ietf.org, rfc-editor@rfc-editor.org Subject: [sipcore] RFC 7134 on The Management Policy of the Resource Priority Header (RPH) Registry Changed to "IETF Review" X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 11:23:11 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7134 Title: The Management Policy of the Resource Priority Header (RPH) Registry Changed to "IETF Review" Author: B. Rosen Status: Standards Track Stream: IETF Date: March 2014 Mailbox: br@brianrosen.net Pages: 2 Characters: 3565 Updates: RFC4412 I-D Tag: draft-rosen-rph-reg-policy-01.txt URL: http://www.rfc-editor.org/rfc/rfc7134.txt RFC 4412 defines the "Resource-Priority Namespaces" and "Resource-Priority Priority-values" registries. The management policy of these registries is "Standards Action". This document normatively updates RFC 4412 to change the management policy of these registries to "IETF Review". This document is a product of the Session Initiation Protocol Core Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Tue Mar 4 06:53:41 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 388F71A00F1; Tue, 4 Mar 2014 06:53:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RK5NAG2p1-_6; Tue, 4 Mar 2014 06:53:34 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id 5F2CA1A00B9; Tue, 4 Mar 2014 06:53:34 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 25EF87FC38D; Tue, 4 Mar 2014 06:53:31 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20140304145331.25EF87FC38D@rfc-editor.org> Date: Tue, 4 Mar 2014 06:53:31 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/FNUezJKwofxXEOe_c7uvSh6oZH4 Cc: drafts-update-ref@iana.org, sipcore@ietf.org, rfc-editor@rfc-editor.org Subject: [sipcore] RFC 7131 on Session Initiation Protocol (SIP) History-Info Header Call Flow Examples X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 14:53:38 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7131 Title: Session Initiation Protocol (SIP) History-Info Header Call Flow Examples Author: M. Barnes, F. Audet, S. Schubert, H. van Elburg, C. Holmberg Status: Informational Stream: IETF Date: March 2014 Mailbox: mary.ietf.barnes@gmail.com, francois.audet@skype.net, shida@ntt-at.com, ietf.hanserik@gmail.com, christer.holmberg@ericsson.com Pages: 52 Characters: 93039 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-sipcore-rfc4244bis-callflows-08.txt URL: http://www.rfc-editor.org/rfc/rfc7131.txt This document describes use cases and documents call flows that require the History-Info header field to capture the Request-URIs as a Session Initiation Protocol (SIP) Request is retargeted. The use cases are described along with the corresponding call flow diagrams and messaging details. This document is a product of the Session Initiation Protocol Core Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Thu Mar 6 06:18:52 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C2BE1A03B3 for ; Thu, 6 Mar 2014 06:18:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.047 X-Spam-Level: X-Spam-Status: No, score=-15.047 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XUvDfxY8sCMu for ; Thu, 6 Mar 2014 06:18:49 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 4A9431A02F7 for ; Thu, 6 Mar 2014 06:18:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4225; q=dns/txt; s=iport; t=1394115523; x=1395325123; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ovz/KOE7GcLUASL/zbemXzdCYPyqwoQG4UbDHupTG9g=; b=jEthFC4mMBdDPuYFHC6O+Scf1tmlVZeceDd5qKMnDq2MSFdrbRZUg1Rb lPzWyfL4xxERNzMAn7fjsnxtRRyaT0mrUIEn0QU1Z16yZLrQt1oA5azST EF8wv0DjO8Z9vOvwm29/0cEJcH0gN9XSiXTKMCd6UnF/HzNx9ZaiJbMnZ c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiIFALeCGFOtJXHA/2dsb2JhbABagwaBBgzBH4EXFnSCJgEBBClQEAIBAgYEOwcyFBECBA4Fh3nPJheOWwYBgySBFASYPpIrgy2CKg X-IronPort-AV: E=Sophos;i="4.97,600,1389744000"; d="scan'208,217";a="308442149" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-2.cisco.com with ESMTP; 06 Mar 2014 14:18:43 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id s26EIhQ9022671 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Mar 2014 14:18:43 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.27]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Thu, 6 Mar 2014 08:18:42 -0600 From: "Gonzalo Salgueiro (gsalguei)" To: "Cullen Jennings (fluffy)" Thread-Topic: [sipcore] IPv6 in the sip core wg Thread-Index: AQHO92PvPaG9LxtinkCT+HMY0fMEHQ== Importance: high X-Priority: 1 Date: Thu, 6 Mar 2014 14:18:42 +0000 Message-ID: <53C92953-3CC0-4738-A41F-61EEF3853514@cisco.com> References: <52A7486E.2090005@alum.mit.edu> <26C3B24F-FCBE-4D10-ADD5-E28B6E95A8FB@edvina.net> <52A8CFC3.3080309@alum.mit.edu> <52A9F990.1030201@alum.mit.edu> <40B29D11-A4EE-4F7B-97C9-612313CFFB7E@cisco.com> <949EF20990823C4C85C18D59AA11AD8B0F858B@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B0F87DC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <52AB35A6.8030701@alum.mit.edu> <597D373F-6ACF-4D81-83F0-8CB5A08202E1@cisco.com> <52AF5C0C.9000206@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B0FA8CF@FR712WXCHMBA11.zeu.alcatel-lucent.com> <52B1D794.1080602@alum.mit.edu> <52DEF1ED.8040905@nostrum.com> <2AF35782-4049-4AD6-B1E6-A97171DB94EE@cisco.com> <52DEF76B.9050706@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.214.181] Content-Type: multipart/alternative; boundary="_000_53C929533CC04738A41F61EEF3853514ciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/H9SSFmpd_MjmpIvLhnJEL3TQ7JI Cc: Olle E Johansson , SIPCORE WG Subject: Re: [sipcore] IPv6 in the sip core wg X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 14:18:51 -0000 --_000_53C929533CC04738A41F61EEF3853514ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As per our discussion during the meeting... I propose we narrow the scope of the proposed milestone to better suit the = existing work. The following two word edit is proposed: OLD: June 2014 Request publication of procedures for dual-stack client and serv= er handling of SIP URIs June 2014 Request publication of DNS look-up procedures for dual-stack cli= ent and server handling of SIP URIs Are folks ok with this new text? After further study of SIP dual-stack gap= s, as Dan York proposed we do, we can add appropriately scoped milestones a= s they arise. Cheers, Gonzalo On Jan 21, 2014, at 10:42 PM, Cullen Jennings (fluffy) > wrote: works for me On Jan 21, 2014, at 3:40 PM, Adam Roach > wrote: On 1/21/14 16:24, Cullen Jennings (fluffy) wrote: No, that implies that 3263 and 6157 are wrong and products that implement n= eed to change - If you want that milestone, first you need to be able be cl= ear about what is wrong with 3263 or 6157. How about June 2014 Request publication of procedures for dual-stack client and serv= er handling of SIP URIs That runs the risk of being confused with what 6157 already does. How about= : June 2014 Request publication of Happy Eyeballs procedures for handling of= SIP URIs Which seems a fair summary of what Olle and Gonzalo's current document inte= nds to do. /a --_000_53C929533CC04738A41F61EEF3853514ciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <008EE2427E6F874F8AD1DF6FE6385C3B@emea.cisco.com> Content-Transfer-Encoding: quoted-printable As per our discussion during the meeting...

I propose we narrow the scope of the proposed milestone to better suit= the existing work.  The following two word edit is proposed:

OLD:

June 2014  Request publication of procedures for dual-stack clien= t and server handling of SIP URIs


June 2014  Request publication of DNS look-up procedures f= or dual-stack client and server handling of SIP URIs


Are folks ok with this new text?  After further study of SIP dual= -stack gaps, as Dan York proposed we do, we can add appropriately scoped mi= lestones as they arise.

Cheers,

Gonzalo


On Jan 21, 2014, at 10:42 PM, Cullen Jennings (fluffy) <fluffy@cisco.com> wrote:


works for me

On Jan 21, 2014, at 3:40 PM, Adam Roach <adam@nostrum.com> wrote:

On 1/21/14 16:24, Cullen Jennings (fluffy) wrote:=
No, that implies that 3263 and 6157 are wrong and= products that implement need to change - If you want that milestone, first= you need to be able be clear about what is wrong with 3263 or 6157. &= nbsp;How about

June 2014  Request publication of procedures= for dual-stack client and server handling of SIP URIs

That runs the risk of being confused with what 6157 already does. How about= :

 June 2014 Request publication of Happy Eyeballs procedures for handli= ng of SIP URIs

Which seems a fair summary of what Olle and Gonzalo's current document inte= nds to do.

/a


--_000_53C929533CC04738A41F61EEF3853514ciscocom_-- From nobody Thu Mar 6 06:25:52 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 159791A0290 for ; Thu, 6 Mar 2014 06:25:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.048 X-Spam-Level: X-Spam-Status: No, score=-115.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XPagkk_QmaeG for ; Thu, 6 Mar 2014 06:25:45 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 7F7141A00FE for ; Thu, 6 Mar 2014 06:25:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1700; q=dns/txt; s=iport; t=1394115942; x=1395325542; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=1jBcP54N10paLBz1bfCMG0002H8/Ygoo9ySVY+U7v8w=; b=a1k32VobVWNWqpmSDXxRXrOQjhmip6IRZzzmfgioVzOknEnj49pkpyGV 4lWA54/PbZi7/nsSICkjw1WkNF7TdXqK4AzxrhKUUpIfk8lBYw8LIw7D1 ORd5GIkfIHXB7rbn5wJWrSDSeiA2Sd0x/isJJsDcpzfBWpShkQ4OjPzMO s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFAJKEGFOtJV2b/2dsb2JhbABagwaBBgzBH4EXFnSCJQEBAQMBKRE/BQsCAQIGGB4QMiUCBA4Fh3EIzywXjigzB4MkgRQBA5g+kiuDLYIq X-IronPort-AV: E=Sophos;i="4.97,600,1389744000"; d="scan'208";a="308468557" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP; 06 Mar 2014 14:25:41 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s26EPfJk029386 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Mar 2014 14:25:41 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.113]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Thu, 6 Mar 2014 08:25:41 -0600 From: "Cullen Jennings (fluffy)" To: "Gonzalo Salgueiro (gsalguei)" Thread-Topic: [sipcore] IPv6 in the sip core wg Thread-Index: AQHO92PvPaG9LxtinkCT+HMY0fMEHZrVBgiA Importance: high X-Priority: 1 Date: Thu, 6 Mar 2014 14:25:40 +0000 Message-ID: <3EA081EC-5F3A-45B9-A27A-D7426B070909@cisco.com> References: <52A7486E.2090005@alum.mit.edu> <26C3B24F-FCBE-4D10-ADD5-E28B6E95A8FB@edvina.net> <52A8CFC3.3080309@alum.mit.edu> <52A9F990.1030201@alum.mit.edu> <40B29D11-A4EE-4F7B-97C9-612313CFFB7E@cisco.com> <949EF20990823C4C85C18D59AA11AD8B0F858B@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B0F87DC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <52AB35A6.8030701@alum.mit.edu> <597D373F-6ACF-4D81-83F0-8CB5A08202E1@cisco.com> <52AF5C0C.9000206@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B0FA8CF@FR712WXCHMBA11.zeu.alcatel-lucent.com> <52B1D794.1080602@alum.mit.edu> <52DEF1ED.8040905@nostrum.com> <2AF35782-4049-4AD6-B1E6-A97171DB94EE@cisco.com> <52DEF76B.9050706@nostrum.com> <53C92953-3CC0-4738-A41F-61EEF3853514@cisco.com> In-Reply-To: <53C92953-3CC0-4738-A41F-61EEF3853514@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.108.195] Content-Type: text/plain; charset="us-ascii" Content-ID: <6DEF00CC62445B4D9D11B2923EE40AC5@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/IM-DeOSwzLCp4txw7XQvNcC6v0Y Cc: Olle E Johansson , SIPCORE WG Subject: Re: [sipcore] IPv6 in the sip core wg X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 14:25:51 -0000 Works for me On Mar 6, 2014, at 2:18 PM, Gonzalo Salgueiro (gsalguei) wrote: > As per our discussion during the meeting... >=20 > I propose we narrow the scope of the proposed milestone to better suit th= e existing work. The following two word edit is proposed: >=20 > OLD: >=20 > June 2014 Request publication of procedures for dual-stack client and se= rver handling of SIP URIs >=20 >=20 > June 2014 Request publication of DNS look-up procedures for dual-stack c= lient and server handling of SIP URIs >=20 >=20 > Are folks ok with this new text? After further study of SIP dual-stack g= aps, as Dan York proposed we do, we can add appropriately scoped milestones= as they arise. >=20 > Cheers, >=20 > Gonzalo >=20 >=20 > On Jan 21, 2014, at 10:42 PM, Cullen Jennings (fluffy) = wrote: >=20 >>=20 >> works for me >>=20 >> On Jan 21, 2014, at 3:40 PM, Adam Roach wrote: >>=20 >>> On 1/21/14 16:24, Cullen Jennings (fluffy) wrote: >>>> No, that implies that 3263 and 6157 are wrong and products that implem= ent need to change - If you want that milestone, first you need to be able = be clear about what is wrong with 3263 or 6157. How about >>>>=20 >>>>> June 2014 Request publication of procedures for dual-stack client an= d server handling of SIP URIs >>>=20 >>> That runs the risk of being confused with what 6157 already does. How a= bout: >>>=20 >>> June 2014 Request publication of Happy Eyeballs procedures for handlin= g of SIP URIs >>>=20 >>> Which seems a fair summary of what Olle and Gonzalo's current document = intends to do. >>>=20 >>> /a >>=20 >=20 From nobody Thu Mar 6 06:31:11 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F240F1A03EC for ; Thu, 6 Mar 2014 06:31:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uKbgmLQ_x49C for ; Thu, 6 Mar 2014 06:31:03 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id ED2D81A00DC for ; Thu, 6 Mar 2014 06:31:02 -0800 (PST) Received: from wireless-v6.meeting.ietf.org (unknown [IPv6:2001:67c:370:160:bde9:4194:a7cf:318b]) by smtp7.webway.se (Postfix) with ESMTPA id 6B54D93C2A2; Thu, 6 Mar 2014 14:30:58 +0000 (UTC) Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Content-Type: text/plain; charset=us-ascii From: "Olle E. Johansson" X-Priority: 1 In-Reply-To: <3EA081EC-5F3A-45B9-A27A-D7426B070909@cisco.com> Date: Thu, 6 Mar 2014 14:30:58 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <52A7486E.2090005@alum.mit.edu> <26C3B24F-FCBE-4D10-ADD5-E28B6E95A8FB@edvina.net> <52A8CFC3.3080309@alum.mit.edu> <52A9F990.1030201@alum.mit.edu> <40B29D11-A4EE-4F7B-97C9-612313CFFB7E@cisco.com> <949EF20990823C4C85C18D59AA11AD8B0F858B@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B0F87DC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <52AB35A6.8030701@alum.mit.edu> <597D373F-6ACF-4D81-83F0-8CB5A08202E1@cisco.com> <52AF5C0C.9000206@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B0FA8CF@FR712WXCHMBA11.zeu.alcatel-lucent.com> <52B1D794.1080602@alum.mit.edu> <52DEF1ED.8040905@nostrum.com> <2AF35782-4049-4AD6-B1E6-A97171DB94EE@cisco.com> <52DEF76B.90 50706@nostrum.com> <53C92953-3CC0-4738-A41F-61EEF3853514@cisco.com> <3EA081EC-5F3A-45B9-A27A-D7426B070909@cisco.com> To: "Cullen Jennings (fluffy)" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/ai7sUk-P4rCECqEwvAfsUPLkoBQ Cc: SIPCORE WG , Olle E Johansson , "Gonzalo Salgueiro \(gsalguei\)" Subject: Re: [sipcore] IPv6 in the sip core wg X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 14:31:06 -0000 Ok for me. /O On 06 Mar 2014, at 14:25, Cullen Jennings (fluffy) = wrote: >=20 > Works for me >=20 > On Mar 6, 2014, at 2:18 PM, Gonzalo Salgueiro (gsalguei) = wrote: >=20 >> As per our discussion during the meeting... >>=20 >> I propose we narrow the scope of the proposed milestone to better = suit the existing work. The following two word edit is proposed: >>=20 >> OLD: >>=20 >> June 2014 Request publication of procedures for dual-stack client = and server handling of SIP URIs >>=20 >>=20 >> June 2014 Request publication of DNS look-up procedures for = dual-stack client and server handling of SIP URIs >>=20 >>=20 >> Are folks ok with this new text? After further study of SIP = dual-stack gaps, as Dan York proposed we do, we can add appropriately = scoped milestones as they arise. >>=20 >> Cheers, >>=20 >> Gonzalo >>=20 >>=20 >> On Jan 21, 2014, at 10:42 PM, Cullen Jennings (fluffy) = wrote: >>=20 >>>=20 >>> works for me >>>=20 >>> On Jan 21, 2014, at 3:40 PM, Adam Roach wrote: >>>=20 >>>> On 1/21/14 16:24, Cullen Jennings (fluffy) wrote: >>>>> No, that implies that 3263 and 6157 are wrong and products that = implement need to change - If you want that milestone, first you need to = be able be clear about what is wrong with 3263 or 6157. How about >>>>>=20 >>>>>> June 2014 Request publication of procedures for dual-stack = client and server handling of SIP URIs >>>>=20 >>>> That runs the risk of being confused with what 6157 already does. = How about: >>>>=20 >>>> June 2014 Request publication of Happy Eyeballs procedures for = handling of SIP URIs >>>>=20 >>>> Which seems a fair summary of what Olle and Gonzalo's current = document intends to do. >>>>=20 >>>> /a >>>=20 >>=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Tue Mar 11 09:19:01 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E8F41A0782 for ; Tue, 11 Mar 2014 09:18:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uljcnFiDvz0N for ; Tue, 11 Mar 2014 09:18:57 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id A86381A0780 for ; Tue, 11 Mar 2014 09:18:56 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id BBB37374648; Tue, 11 Mar 2014 17:18:50 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 89FF338407E; Tue, 11 Mar 2014 17:18:50 +0100 (CET) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Tue, 11 Mar 2014 17:18:50 +0100 From: To: "Mary Barnes (mary.ietf.barnes@gmail.com)" , "Shida Schubert (shida@agnada.com)" , "Christer Holmberg (christer.holmberg@ericsson.com)" Thread-Topic: [sipcore] Inconcistency between RFC 7044 and RFC7131 Thread-Index: Ac89RYg/Z0DspSmyTq+ibXY7knGtiA== Date: Tue, 11 Mar 2014 16:18:49 +0000 Message-ID: <26837_1394554730_531F376A_26837_9133_1_8B970F90C584EA4E97D5BAAC9172DBB81420EDEF@PEXCVZYM12.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: multipart/alternative; boundary="_000_8B970F90C584EA4E97D5BAAC9172DBB81420EDEFPEXCVZYM12corpo_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.3.11.95118 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/o2hNwWVof5j0CusyDKk6vjcViyQ Cc: "sipcore@ietf.org" Subject: [sipcore] Inconcistency between RFC 7044 and RFC7131 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 16:18:59 -0000 --_000_8B970F90C584EA4E97D5BAAC9172DBB81420EDEFPEXCVZYM12corpo_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, Checking the 2 published RFCs I identified an inconsistency regarding the P= BX Voicemail use case recommendation between RFC 7044 and RFC 7131: RFC 7044 states: 12.1. PBX Voicemail The original target is determined by finding the first hi-entry tagged with "rc" and using the hi-entry referenced by the index of the "rc" header field parameter as the target for determining the appropriate mailbox. RFC 7131 states: =A73.6 PBX Voicemail Example: The original target is determined by finding the first hi-entry tagged with "rc" or "mp" and using the hi-entry referenced by the index of "rc" or "mp" header field parameter as the target for determining the appropriate mailbox. Hum hum... I think RFC 7131 is correct. Is that right? Best Regards, Marianne ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_8B970F90C584EA4E97D5BAAC9172DBB81420EDEFPEXCVZYM12corpo_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello,

 

Checking the 2 published RFCs I identified an incons= istency regarding the PBX Voicemail use case recommendation between RFC 704= 4 and RFC 7131:

 

RFC 7044 states:

12.1.  PBX Voicemail
The original target is determined by finding the first hi-entry
   tagged with "rc" and using the hi-entry referen=
ced by the index of
   the "rc" header field parameter as the target f=
or determining the
   appropriate mailbox.

 

RFC 7131 states:

=A73.6 PBX Voicemail Example:

The original target is determined by finding the first

   hi-entry tagged with "rc" or "= mp" and using the hi-entry referenced

   by the index of "rc" or "mp&qu= ot; header field parameter as the target for

   determining the appropriate mailbox.

 

Hum hum… I think RFC 7131 is correct. Is that = right?

 

Best Regards,

Marianne

 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_8B970F90C584EA4E97D5BAAC9172DBB81420EDEFPEXCVZYM12corpo_-- From nobody Wed Mar 12 11:20:47 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40F931A0736; Wed, 12 Mar 2014 11:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.446 X-Spam-Level: X-Spam-Status: No, score=-2.446 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZrIoZy7Trrbz; Wed, 12 Mar 2014 11:20:41 -0700 (PDT) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id D73631A058E; Wed, 12 Mar 2014 11:20:40 -0700 (PDT) Received: from xct102cnc.rim.net ([10.65.161.202]) by mhs214cnc.rim.net with ESMTP/TLS/AES128-SHA; 12 Mar 2014 14:20:19 -0400 Received: from XMB122CNC.rim.net ([fe80::28c6:fa1c:91c6:2e23]) by XCT102CNC.rim.net ([fe80::2066:5d4f:8c45:af55%17]) with mapi id 14.03.0174.001; Wed, 12 Mar 2014 14:20:18 -0400 From: Andrew Allen To: "dispatch@ietf.org" , "straw@ietf.org" , "SIPCORE (sipcore@ietf.org)" Thread-Topic: draft-allen-dispatch-routing-out-of-dialog-request-00 posted Thread-Index: Ac89dJaprbnFDofWSDGBbfkVqnqeng== Date: Wed, 12 Mar 2014 18:20:18 +0000 Message-ID: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.249] Content-Type: multipart/alternative; boundary="_000_BBF5DDFE515C3946BC18D733B20DAD23398A1743XMB122CNCrimnet_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/JES8x3c-6EJUFQ4yFc6aGXWY_Cs Subject: [sipcore] draft-allen-dispatch-routing-out-of-dialog-request-00 posted X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 18:20:43 -0000 --_000_BBF5DDFE515C3946BC18D733B20DAD23398A1743XMB122CNCrimnet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have submitted a draft that discusses the problem posed by B2BUA intermed= iaries for out of dialog requests that are related to another dialog and id= entifies some possible solutions. It can be found at: http://www.ietf.org/id/draft-allen-dispatch-routing-out-of-dialog-request-0= 0.txt I would like to receive comments on this and a view as to where such work s= hould be dispatched to. Andrew --_000_BBF5DDFE515C3946BC18D733B20DAD23398A1743XMB122CNCrimnet_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

I have submitted a draft that discusses the problem = posed by B2BUA intermediaries for out of dialog requests that are related t= o another dialog and identifies some possible solutions.

 

It can be found at:

 

http://www.ietf.org/id/draft-allen= -dispatch-routing-out-of-dialog-request-00.txt

 

 

I would like to receive comments on this and a view = as to where such work should be dispatched to.

 

Andrew

--_000_BBF5DDFE515C3946BC18D733B20DAD23398A1743XMB122CNCrimnet_-- From nobody Wed Mar 12 11:38:21 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B9521A0778; Wed, 12 Mar 2014 11:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YyXOy5omoYE3; Wed, 12 Mar 2014 11:38:16 -0700 (PDT) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 1AB331A0755; Wed, 12 Mar 2014 11:38:15 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id b13so5558916wgh.17 for ; Wed, 12 Mar 2014 11:38:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=E02OeViH9tIzJP2EswZ8QbzRiMRCnc+X90sBcBUu6V0=; b=o2eESwK0cMo+WI8Bv01YuQ7qtKQWU8ArvLT3kKgZba/flSddvwIUtnV0MkQ25kCMLi UDBCcpgxZ5ireH1k/WR92My22ttTkvPeBVxTjEc7T+9Hx1iAqYmtqQiLhwIEIDM06/ba zcL/+0jf3od9yS6Ap1tA36oPgGOJC//Cb/2G8YQCtOovyXaJDZUQztJvskzZl8EogVdc W9Zyjg6f2TI9Cx+1lkRor8DoNi/5LFLRDMZkGDvpcbGx+vsHnshwXFFrK5GgrLUMbTJT q8BY1gfOeWvesQ+M3bgVZHsbhC8iMF3ACdkqxF1Srx60Qt1t0NaeNYraB7eggonnZpDF QELQ== MIME-Version: 1.0 X-Received: by 10.194.21.193 with SMTP id x1mr42129046wje.33.1394649489363; Wed, 12 Mar 2014 11:38:09 -0700 (PDT) Received: by 10.216.10.6 with HTTP; Wed, 12 Mar 2014 11:38:09 -0700 (PDT) In-Reply-To: References: Date: Wed, 12 Mar 2014 13:38:09 -0500 Message-ID: From: Mary Barnes To: Andrew Allen Content-Type: multipart/alternative; boundary=047d7b5d561066586f04f46d23eb Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/aiPnK8qlxbLRINVhqdOgV5JYidQ Cc: "dispatch@ietf.org" , "SIPCORE \(sipcore@ietf.org\)" , "straw@ietf.org" Subject: Re: [sipcore] draft-allen-dispatch-routing-out-of-dialog-request-00 posted X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 18:38:19 -0000 --047d7b5d561066586f04f46d23eb Content-Type: text/plain; charset=ISO-8859-1 Please do NOT crosspost. If you want this document to be considered by the DISPATCH WG process, then please keep the discussion there. Right now, this email is cached with my SIPCORE WG emails since the IETF mailing lists do NOT send duplicate messages. So it's very likely that I will miss any discussion that might be relevant to making a decision in the DISPATCH WG. The right thing to do is to have the discussion on the DISPATCH WG mailing list and send a note to any related WGs that the discussion is underway on the DISPATCH WG mailing list. Thanks, Mary. On Wed, Mar 12, 2014 at 1:20 PM, Andrew Allen wrote: > > > I have submitted a draft that discusses the problem posed by B2BUA > intermediaries for out of dialog requests that are related to another > dialog and identifies some possible solutions. > > > > It can be found at: > > > > > http://www.ietf.org/id/draft-allen-dispatch-routing-out-of-dialog-request-00.txt > > > > > > I would like to receive comments on this and a view as to where such work > should be dispatched to. > > > > Andrew > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > --047d7b5d561066586f04f46d23eb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Please do NOT crosspost. =A0If you want this document to b= e considered by the DISPATCH WG process, then please keep the discussion th= ere. =A0Right now, this email is cached with my SIPCORE WG emails since the= IETF mailing lists do NOT send duplicate messages. =A0So it's very lik= ely that I will miss any discussion that might be relevant to making a deci= sion in the DISPATCH WG. =A0The right thing to do is to have the discussion= on the DISPATCH WG mailing list and send a note to any related WGs that th= e discussion is underway on the DISPATCH WG mailing list.

Thanks,
Mary.=A0


On Wed, Mar 12, 2014 at 1:20 PM, An= drew Allen <aallen@blackberry.com> wrote:

=A0

I have submitted a draft that discusses the problem = posed by B2BUA intermediaries for out of dialog requests that are related t= o another dialog and identifies some possible solutions.

=A0

It can be found at:

=A0

http://www.ietf.= org/id/draft-allen-dispatch-routing-out-of-dialog-request-00.txt=

=A0

=A0

I would like to receive comments on this and a view = as to where such work should be dispatched to.

=A0

Andrew


_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore


--047d7b5d561066586f04f46d23eb-- From nobody Mon Mar 17 08:56:35 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15E8B1A01BE; Mon, 17 Mar 2014 08:56:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mIBWuykT44X1; Mon, 17 Mar 2014 08:56:31 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id 71BCB1A0427; Mon, 17 Mar 2014 08:56:30 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id k14so4825975wgh.35 for ; Mon, 17 Mar 2014 08:56:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=dxDhWX+nTHBcx3viYU82BVQdga0GnekkY3jtjVcx6ws=; b=mRd1X8sv9X0TTMaa0kn+OAt1ghCpr0G5e8DsLptzaHlcdKUDC7clCvOuJg/GyaNllL Be0ENST/3glckVTXFSAsT2aqrDW0T1PeeXW6xyi493XxNx7TCKNnbpTwoRPoPRC/p9TR YHrNLVX2KfTS9/fbaLpBFKUmEWbxNU9tlTQ/SW4I9jNFClzswoQ+KR/P/leO1TPqO1Ea i8b1X1uiF3O7/17Ogc6CiW1hzUrynoSWUy1GPzf3HGGAr3MLB99SBxmYZNsLl0olC2xQ ROC4I741THMVBhc65lvc/dLuybL6ZzvANJCChAxqZ4OZvRwfPkFryLmhOcnGhZMLbVo3 RsQw== MIME-Version: 1.0 X-Received: by 10.180.20.176 with SMTP id o16mr10244450wie.7.1395071782079; Mon, 17 Mar 2014 08:56:22 -0700 (PDT) Received: by 10.216.10.6 with HTTP; Mon, 17 Mar 2014 08:56:22 -0700 (PDT) Date: Mon, 17 Mar 2014 10:56:22 -0500 Message-ID: From: Mary Barnes To: "rai@ietf.org" Content-Type: multipart/alternative; boundary=bcaec53f35f501d2c604f4cf76ff Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/c8Kuw3Aeh4ZHNV1x3FNU9X2fz2M Cc: DISPATCH , SIPCORE Subject: [sipcore] Passing of Francois Audet X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 15:56:33 -0000 --bcaec53f35f501d2c604f4cf76ff Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable A number of you all will remember Francois Audet, who was a colleague of mine at Nortel and a regular IETF attendee (until he went to Skype ;) He was a co-author on the recently published 4244bis drafts. He unfortunately lost his battle with cancer on Friday. I have received the following information from a family friend via Facebook: Thanks for all your support messages, both on & offline. I've talked to Genevi=E8ve over the week-end, and she reminded me that ther= e is just no real treatment of Brain Tumors, and that form of cancer is growing at some alarming rate. She agreed that the best support message would be to sponsor the research, for which donations can be made as a memorial gift for Francois Audet. I've selected a few organizations: - Stanford Brain Tumor Center (http://medicalgiving.stanford.edu/, this is where Fran=E7ois was treated. Make sure to indicate the Brain Tumor Center = as the recipient). - UCSF Brain Tumor Center ( https://makeagift.ucsf.edu/site/SPageServer?pagename=3DA1_API_GordonMurrayG= ivingForm&ACode=3DB2934 ) - National Brain Tumor Society (http://www.braintumor.org/) Note that he also left behind a son, Olivier. That's all the information I have at this point. Regards, Mary. --bcaec53f35f501d2c604f4cf76ff Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
A number of you all will remember Francois Audet, who was = a colleague of mine at Nortel and a regular IETF attendee (until he went to= Skype ;) =A0He was a co-author on the recently published 4244bis drafts. = =A0He unfortunately lost his battle with cancer on Friday. =A0I have receiv= ed the following information from a family friend via Facebook:

Thanks for all your support messages, both on & off= line.
I've talked to Genevi=E8ve over the week-end, and she r= eminded me that there is just no real treatment of Brain Tumors, and that f= orm of cancer is growing at some alarming rate.
She agreed that the best support message would be to sponsor the resea= rch, for which donations can be made as a memorial gift for Francois Audet.=
I've selected a few organizations:
- Stanford Brai= n Tumor Center (http://medic= algiving.stanford.edu/, this is where Fran=E7ois was treated. Make sure= to indicate the Brain Tumor Center as the recipient).
- National Brain Tumor Society (http://www.braintumor.org/)

Note that h= e also left behind a son, Olivier.=A0

That's a= ll the information I have at this point.=A0

Regards,
Mary.
--bcaec53f35f501d2c604f4cf76ff-- From nobody Mon Mar 17 10:40:13 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A7181A045B; Mon, 17 Mar 2014 10:40:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3APE5dMeHQPU; Mon, 17 Mar 2014 10:40:08 -0700 (PDT) Received: from ukel19pa21.eemsg.mail.mil (ukel19pa21.eemsg.mail.mil [214.24.22.89]) by ietfa.amsl.com (Postfix) with ESMTP id 44B2D1A044C; Mon, 17 Mar 2014 10:40:07 -0700 (PDT) X-EEMSG-Attachment-filename: smime.p7s Received: from edge-cols.mail.mil ([131.64.100.13]) by ukel19pa21.eemsg.mail.mil with ESMTP; 17 Mar 2014 17:39:58 +0000 Received: from UCOLHP3M.easf.csd.disa.mil (131.64.100.152) by edge-cols.mail.mil (131.64.100.13) with Microsoft SMTP Server (TLS) id 14.3.174.1; Mon, 17 Mar 2014 17:39:58 +0000 Received: from UCOLHP9B.easf.csd.disa.mil ([169.254.10.200]) by UCOLHP3M.easf.csd.disa.mil ([131.64.100.152]) with mapi id 14.03.0174.001; Mon, 17 Mar 2014 17:39:57 +0000 From: "Roy, Radhika R CIV USARMY (US)" To: Mary Barnes , "rai@ietf.org" Thread-Topic: [sipcore] Passing of Francois Audet (UNCLASSIFIED) Thread-Index: AQHPQfl9rgjNnFJblkm0fVDvrCcaUJrlia6g Date: Mon, 17 Mar 2014 17:39:57 +0000 Message-ID: <8486C8728176924BAF5BDB2F7D7EEDDF55B35D3B@ucolhp9b.easf.csd.disa.mil> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [131.64.201.79] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_001D_01CF41E6.5F9B98F0" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/YIyzYwzOlCXuHuXsmQZMmj9CzkI Cc: DISPATCH , SIPCORE Subject: Re: [sipcore] Passing of Francois Audet (UNCLASSIFIED) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 17:40:11 -0000 ------=_NextPart_000_001D_01CF41E6.5F9B98F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Classification: UNCLASSIFIED Caveats: NONE Hi, Marry and all: My heartfelt prayer to God for resting his soul in Heaven! My heartfelt sympathy to his son Oliver and family as we all is a part of this = eternal cycle! I would know him since the mid-1990s while he used to participate in ATM Forum and a liaison to the ITU-T H.323 WG. His crystal clear voice and technical explanations has kept amazing me and all others since his last breath! Best regards, Radhika -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Mary Barnes Sent: Monday, March 17, 2014 11:56 AM To: rai@ietf.org Cc: DISPATCH; SIPCORE Subject: [sipcore] Passing of Francois Audet A number of you all will remember Francois Audet, who was a colleague of mine at Nortel and a regular IETF attendee (until he went to Skype ;) = He was a co-author on the recently published 4244bis drafts. He = unfortunately lost his battle with cancer on Friday. I have received the following information from a family friend via Facebook: Thanks for all your support messages, both on & offline. I've talked to Genevi=E8ve over the week-end, and she reminded me that = there is just no real treatment of Brain Tumors, and that form of cancer is growing at some alarming rate. She agreed that the best support message would be to sponsor the = research, for which donations can be made as a memorial gift for Francois Audet. I've selected a few organizations: - Stanford Brain Tumor Center (http://medicalgiving.stanford.edu/, this = is where Fran=E7ois was treated. Make sure to indicate the Brain Tumor = Center as the recipient). - UCSF Brain Tumor Center (https://makeagift.ucsf.edu/site/SPageServer?pagename=3DA1_API_GordonMurr= ayGiv ingForm&ACode=3DB2934) - National Brain Tumor Society (http://www.braintumor.org/) Note that he also left behind a son, Olivier.=20 That's all the information I have at this point.=20 Regards, Mary. Classification: UNCLASSIFIED Caveats: NONE ------=_NextPart_000_001D_01CF41E6.5F9B98F0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISizCCA3Aw ggJYoAMCAQICAQUwDQYJKoZIhvcNAQEFBQAwWzELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4g R292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxFjAUBgNVBAMTDURvRCBSb290 IENBIDIwHhcNMDQxMjEzMTUwMDEwWhcNMjkxMjA1MTUwMDEwWjBbMQswCQYDVQQGEwJVUzEYMBYG A1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEWMBQGA1UE AxMNRG9EIFJvb3QgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMAswfaNO6z/ PzzWcb64dCIH7HBBFfyrQOMHqsHD2J/+2kw6vz/I2Ch7SzYBwKxFJcPSDgqPhRhkED0aE3Aqb47X 3I2Ts0EPOCHNravCPSoF01cRNw3NjFH5k+PMRkkhjhS0zcsUPjjNcjHuqxLyZeo0LlZd/+5jdctt upE0/J7z9C0cvlDEQt9ZiP9qs/qobD3LVnFxBZa7n4DlgEVZZ0Gw68OtYKSAdQYXnA70Q+CZDhv7 f/WzzLKBgrH9MsG4vkGkZLVgOlpRMIzO3kEsGUdcSRBkuXSph0GvfW66wbihv2UxOgRn+bW7jpKK AGO4seaMOF+D/1DVO6Jda7IQzGMCAwEAAaM/MD0wHQYDVR0OBBYEFEl0uwxeunr+AlTve6DGlcYJ gHCWMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBQUAA4IBAQCYkY0/ ici79cBpcyk7Nay6swh2PXAJkumERCEBfRR2G+5RbB2NFTctezFp9JpEuK9GzDT6I8sDJxnSgyF1 K+fgG5km3IRAleio0sz2WFxm7z9KlxCCHboKot1bBiudp2RO6y4BNaS0PxOtVeTVc6hpmxHxmPIx Hm9A1Ph4n46RoG9wBJBmqgYrzuF6krV94eDRluehOi3MsZ0fBUTth5nTTRpwOcEEDOV+2fGv1yAO 8SJ6JaRzmcw/pAcnlqiile2CuRbTnguHwsHyiPVi32jfx7xpUe2xXNxUVCkPCTmarAPB2wxNrm8K ehZJ8b+R0jiU0/aVLLdsyUK2jcqQjYXZMIIEtzCCA5+gAwIBAgIDHzzKMA0GCSqGSIb3DQEBBQUA MF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEM MAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjkwHhcNMTIwOTIwMDAwMDAwWhcN MTUwOTE5MjM1OTU5WjB5MQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQww CgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEMMAoGA1UECxMDVVNBMSYwJAYDVQQDEx1ST1kuUkFE SElLQS5SQU5KQU4uMTI5MTkzOTgwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKw9 ymde30NtacDt8neYCBWDyA+Hlsk3dNwV23IVgH7vSWJx4zCFT5ojDHACm3lthvOOtJ0CzkjwQy8V hEHvL0eK03hZy0hJrZxQSYcao7Y0Yv9yDAFvxa6LJ1fUImUj9edMf1l08LZkjh3ybs20Bk+MLySR 9F/flRzjtCwVUeqq8NS3to4nPXSIgViP6H0YJrBjf9IDZQGgcO8LxLbNENOWrXILeCCCngnHBgHV lJWak9YndpMOs+CeLXk5oUV8xUAM/UjyS+/gFCjABBRt30VJVN6pqARmIht850iK8TDeqlWwF3O9 eQBBwKQPJ7nVl0kmGItYGoYb+4t2Mkwalh8CAwEAAaOCAWIwggFeMB8GA1UdIwQYMBaAFLhDg2Qh eu5wgd6l3gxgKId4rl54MDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly9jcmwuZGlzYS5taWwvY3Js L0RPREVNQUlMQ0FfMjkuY3JsMA4GA1UdDwEB/wQEAwIFIDAjBgNVHSAEHDAaMAsGCWCGSAFlAgEL CTALBglghkgBZQIBCxMwHQYDVR0OBBYEFGRWf703swy+9hvoDujsb+ZPwC9MMGgGCCsGAQUFBwEB BFwwWjA2BggrBgEFBQcwAoYqaHR0cDovL2NybC5kaXNhLm1pbC9zaWduL0RPREVNQUlMQ0FfMjku Y2VyMCAGCCsGAQUFBzABhhRodHRwOi8vb2NzcC5kaXNhLm1pbDAkBgNVHREEHTAbgRlyYWRoaWth LnIucm95QHVzLmFybXkubWlsMBsGA1UdCQQUMBIwEAYIKwYBBQUHCQQxBBMCVVMwDQYJKoZIhvcN AQEFBQADggEBAE9PU63Rc/bneYoxI6sAZi+oXBiwneOiI03+J3pSZWIbwrOnj7qGoH5ZoeO+dZ8E wvKszd+vacYnO8SqEXsvIKvBGPchKg1oV5b24+tCSeiCXtcX5EDtpJQGS4W9G+7r7f+mdEHU0NuF NI7HNHRY/q4C+FGhchPoKPcKeyWxJMwp+9NJQsx1AoC5isvydZHHlNkV917dLMuMEqyCCAAbJAOp 8SDQTiiIVa1I7NlMSlkzNRUtFoO9nsEttMH699V9JH5jcwWPlWdyb5B6yRzoM/iFsI/hA9pHHukh iWVul3FX/6Ez8Jt/A1j/CFsl3S2y2TBRCdqIQEP+/H6j4RFxa9MwggUCMIID6qADAgECAgMfPMkw DQYJKoZIhvcNAQEFBQAwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEM MAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOTAeFw0x MjA5MjAwMDAwMDBaFw0xNTA5MTkyMzU5NTlaMHkxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMu IEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMQwwCgYDVQQLEwNVU0ExJjAk BgNVBAMTHVJPWS5SQURISUtBLlJBTkpBTi4xMjkxOTM5ODAxMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAyr7Ttduf1mHx22erLvkwPOZL02imdiimrmXITVrdUHsynK383NY6a4ye07Jm b0spr8hzmfM6JSCEgtbZevWfJg4NmNDjEEe53+7EvEMRHfh46GGxOckj98QmQwngbQaAIcKI1gJd Do2vB3mOtFp5hNKqsxibZAvpPb3OsR762vrx2QYQX+p8+psLwe95CSt56IfC39GZD+Otus3Sq1Ma 9e0NdRhqg5ch8FYpL2ONbmEw9+DTqk24Zh2lQuOvpo4FhpvXnNghCS4CfuiE6YgvKdombc1BGT5u rkDFep5IH7Rk7EnK4CVVzNq3gxT0B+hDoJT0AuQfrkxI9223mUJoywIDAQABo4IBrTCCAakwHwYD VR0jBBgwFoAUuEODZCF67nCB3qXeDGAoh3iuXngwOgYDVR0fBDMwMTAvoC2gK4YpaHR0cDovL2Ny bC5kaXNhLm1pbC9jcmwvRE9ERU1BSUxDQV8yOS5jcmwwDgYDVR0PAQH/BAQDAgbAMCMGA1UdIAQc MBowCwYJYIZIAWUCAQsJMAsGCWCGSAFlAgELEzAdBgNVHQ4EFgQUrV8KnskfJHURS19In/mX0d2y 9pgwaAYIKwYBBQUHAQEEXDBaMDYGCCsGAQUFBzAChipodHRwOi8vY3JsLmRpc2EubWlsL3NpZ24v RE9ERU1BSUxDQV8yOS5jZXIwIAYIKwYBBQUHMAGGFGh0dHA6Ly9vY3NwLmRpc2EubWlsMEQGA1Ud EQQ9MDuBGXJhZGhpa2Euci5yb3lAdXMuYXJteS5taWygHgYKKwYBBAGCNxQCA6AQDA4xMjkxOTM5 ODAxQG1pbDAbBgNVHQkEFDASMBAGCCsGAQUFBwkEMQQTAlVTMCkGA1UdJQQiMCAGCisGAQQBgjcU AgIGCCsGAQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQUFAAOCAQEAggVw28drobHRF6Zr7wQZ G/ShO0BE6jEddlmlqj9ln2mC5HoTTXkl2ZOqjUoh2Wq2d55KvbZk9b73bIzWK+RnnoU+zOHagyB/ VnEbSpdofTm50zJYISK7Ws92KCt8viNetFkS2CTNSc302cqmwejpTwKAxkLDM0wU7ECNopN87F0O vPU2AJnITH32PrAvTVOeCxsDdEnzzXYxvKtNE5K6zBVVumSOGLMfnyFAq+4dlhg7i25B8Goh+fIF eRGiwxsXOyEMPalWHt5wWDDmUlIK0Qmg95mZ7f6UJCmj15zzSxgliR+JyVlFGH6/HYzIAU4lv8b5 uU5qyxANtVCvuGDruDCCBVIwggQ6oAMCAQICAgG4MA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJ MRYwFAYDVQQDEw1Eb0QgUm9vdCBDQSAyMB4XDTExMDkwODE2MDIxNFoXDTE3MDkwODE2MDIxNFow XTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9EMQww CgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAJJiL0HCIAAWBlVkn72niBVugptIwYV3vQKrDNnxK2CBAbo+dXCOEqanOISQ s+lAgBLcaspRza0thhDMRLwOxVg4GbIUMiVBVFhcQw7IbHMPwwwYGBYEmlI9gaJxzjwyAJ9xVbr4 zjZ3HiG3KJTnPT6m9sB6MWCRKJd3IlDyxpNushvFQcb5oTf7EL/aVqb7Uk1fv+/Elnco5TL/6OEY zENSGKyNd5pyTOidA16wou/k3dLn5qemUq3hmAiWSkPMcz1Loo2J79yCTLhKgCRlKx6RgvUE9nIf VxhAF/A5UbaP84k7Z/dYTkq82vkOwcAMvfMIcfiDD8kugJX0hQ7OrqkCAwEAAaOCAhwwggIYMA4G A1UdDwEB/wQEAwIBhjAfBgNVHSMEGDAWgBRJdLsMXrp6/gJU73ugxpXGCYBwljAdBgNVHQ4EFgQU uEODZCF67nCB3qXeDGAoh3iuXngwEgYDVR0TAQH/BAgwBgEB/wIBADAMBgNVHSQEBTADgAEAMGYG A1UdIARfMF0wCwYJYIZIAWUCAQsFMAsGCWCGSAFlAgELCTALBglghkgBZQIBCxEwCwYJYIZIAWUC AQsSMAsGCWCGSAFlAgELEzAMBgpghkgBZQMCAQMaMAwGCmCGSAFlAwIBAxswNwYDVR0fBDAwLjAs oCqgKIYmaHR0cDovL2NybC5kaXNhLm1pbC9jcmwvRE9EUk9PVENBMi5jcmwwggEBBggrBgEFBQcB AQSB9DCB8TA6BggrBgEFBQcwAoYuaHR0cDovL2NybC5kaXNhLm1pbC9pc3N1ZWR0by9ET0RST09U Q0EyX0lULnA3YzAgBggrBgEFBQcwAYYUaHR0cDovL29jc3AuZGlzYS5taWwwgZAGCCsGAQUFBzAC hoGDbGRhcDovL2NybC5nZHMuZGlzYS5taWwvY24lM2REb0QlMjBSb290JTIwQ0ElMjAyJTJjb3Ul M2RQS0klMmNvdSUzZERvRCUyY28lM2RVLlMuJTIwR292ZXJubWVudCUyY2MlM2RVUz9jcm9zc0Nl cnRpZmljYXRlUGFpcjtiaW5hcnkwDQYJKoZIhvcNAQEFBQADggEBACxrLHk12/AeHId7q+HoaWo3 i9t6T1VgaZUvU53GykO21DeR1gNdflqxuB33noHTrlBUMKRvSy67FBsXqlwQ05R6MTmWpFR59elW LlXDGxbqqgLIz1H3MoEixjQ6qc2aqkiTx+n7HjJ+ccR28EVUEh1V6r1cMoc6rpOabpkiX6hRNe6y U2Bf9k9FuBaEHWVVzRXKEAEfqdKcp1eRo9fnsIY9LfSJOtjJd3BQxmzv8uuY+BCqPdrIXCmtzrhz SUyhkrvm7c26ghpjIRll9AYZv4Oqc+XTG7GY/0Xf+0nMc+ji5weWADHpf9kkCOfKRHpIBsNC2D/5 eYelN5IWqYQgkmMxggMyMIIDLgIBATBkMF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdv dmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwg Q0EtMjkCAx88yTAJBgUrDgMCGgUAoIIBozAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNDAzMTcxNzM5NTFaMCMGCSqGSIb3DQEJBDEWBBTFVTtEfzO2kl2UKeJWiZ3l KbjICjBYBgkqhkiG9w0BCQ8xSzBJMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMC BzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTBzBgkrBgEEAYI3EAQxZjBkMF0x CzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoG A1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjkCAx88yjB1BgsqhkiG9w0BCRACCzFm oGQwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9E MQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOQIDHzzKMA0GCSqGSIb3DQEB AQUABIIBABHDtBxVZFPC375ZKXUYAX3d4ipdlPqouA7qyjLVxSUFEbo+pE4+F+Olq3z0f/q74Xbd +QjBrqm7S3AZXUmXLaMOfMMi0D57yZqp5S8GTckANbyrjVbMJstBR5w+zh5vP7OeYrXHm1+dBoFR 4yyUdJFKlHDhBCO4KfY/sQ4cxJqAp/TqvOUi73VThLAQ3lXWVdkejmJzL0QDMjxNYkhY9DxK1IjL KnQpRNue5vPhclH+MJ4PRzZTZb2F7/Rr/cJSleXX2AguQFlLtigacLSAAZVyH2NY2pd/lsPua7s+ ChSs5/y883O+MRyhX+QbvCuFKuNkfjkYYexqFB3aWGgPw8wAAAAAAAA= ------=_NextPart_000_001D_01CF41E6.5F9B98F0-- From nobody Tue Mar 18 12:22:20 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59F3E1A0455; Tue, 18 Mar 2014 11:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wq0pHSNiTaiU; Tue, 18 Mar 2014 11:55:20 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id EF75F1A040E; Tue, 18 Mar 2014 11:55:19 -0700 (PDT) Received: by mail-ie0-f170.google.com with SMTP id rd18so7754508iec.29 for ; Tue, 18 Mar 2014 11:55:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Vsh4R66xnTXYwiaxXjlQCYDFYbJycZQ8BDJobYZAQxU=; b=s04BGDzN6dqE9osQNyf+fWwSrWlGehVI3XttoMTNRST9vHMCsEzwf3A9wJPscMkowc u/iPt/tTGM3zXY75EcuemR1T2tZ/9yD6kDJae6DKt+nhl+j1YgsOKLGbfdWl3ZEtZGaH b9LHx7sRXpAdaA9gWosdRxpqt7PaL8/00o92gAXEO/vlkTsyEu3vp2iawa6nybQKrQkO l2hxEMvyG5HhGyzcF2J3Vv6X3HVmvY0dfxzSLg9sXml6cic7Y/g9M+sK3uF1mKDKtOIV RoiOB2GWC7vXDhh2kipObNPTL+jVY8QUpq3lT1Cfgjyg5m4IqDLbHovikwNqy0tyDKTS 3ulw== X-Received: by 10.42.61.4 with SMTP id s4mr3201464ich.58.1395168911013; Tue, 18 Mar 2014 11:55:11 -0700 (PDT) Received: from [192.168.0.102] (dsl-173-206-145-184.tor.primus.ca. [173.206.145.184]) by mx.google.com with ESMTPSA id an1sm28567628igc.0.2014.03.18.11.54.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 18 Mar 2014 11:54:54 -0700 (PDT) Message-ID: <5328967B.9020104@gmail.com> Date: Tue, 18 Mar 2014 14:54:51 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "rai@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/gSid_Pa0K9CTNipj5EupgI1NvEk X-Mailman-Approved-At: Tue, 18 Mar 2014 12:22:14 -0700 Cc: DISPATCH , SIPCORE Subject: Re: [sipcore] [dispatch] Passing of Francois Audet X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 18:55:21 -0000 I'm really sorry to hear this. I worked with Francois on H.323 in particular, he representing the enterprise side and I the carrier side of the business. I was aware of his previous work with the ATM Forum, and of course, we both turned to SIP eventually. Beyond being a pleasure to work with, Francois was probably one of the most competent standards representatives I've ever known. I'm sure he brought the same competence and focus to his PLM job at Skype, however long that lasted given his illness. My condolences to his present friends and family. Tom Taylor On 17/03/2014 11:56 AM, Mary Barnes wrote: > A number of you all will remember Francois Audet, who was a colleague of > mine at Nortel and a regular IETF attendee (until he went to Skype ;) He > was a co-author on the recently published 4244bis drafts. He unfortunately > lost his battle with cancer on Friday. I have received the following > information from a family friend via Facebook: ... From nobody Thu Mar 20 10:48:45 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 046681A0700; Thu, 20 Mar 2014 10:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.115 X-Spam-Level: X-Spam-Status: No, score=-2.115 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vYuqohEwKX9p; Thu, 20 Mar 2014 10:48:30 -0700 (PDT) Received: from nostrum.com (raven.nostrum.com [69.55.229.100]) by ietfa.amsl.com (Postfix) with ESMTP id 5A52A1A0790; Thu, 20 Mar 2014 10:48:30 -0700 (PDT) Received: from unnumerable.local (pool-173-71-10-88.dllstx.fios.verizon.net [173.71.10.88]) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s2KHl5Di080514 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK); Thu, 20 Mar 2014 12:47:06 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-173-71-10-88.dllstx.fios.verizon.net [173.71.10.88] claimed to be unnumerable.local Message-ID: <532B299C.3070909@nostrum.com> Date: Thu, 20 Mar 2014 12:47:08 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: dispatch@ietf.org, mmusic@ietf.org, rtcweb@ietf.org, avt@ietf.org, sipcore@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/uob2a2jNtAna-yLP7LXbaMnhy9o Subject: [sipcore] Registration for SIPit 31 is open X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: rai@ietf.org List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 17:48:32 -0000 (Please forgive the crosspost, and reply only to the rai list): Please see From nobody Thu Mar 20 12:17:40 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A1B31A03D5 for ; Thu, 20 Mar 2014 12:17:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.9 X-Spam-Level: X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_BACKHAIR_21=1] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XbOb55_PFGDH for ; Thu, 20 Mar 2014 12:17:33 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id 438141A034F for ; Thu, 20 Mar 2014 12:17:33 -0700 (PDT) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta06.westchester.pa.mail.comcast.net with comcast id ftcE1n0010mv7h056vHQ0r; Thu, 20 Mar 2014 19:17:24 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta11.westchester.pa.mail.comcast.net with comcast id fvHP1n00S1KKtkw3XvHPhd; Thu, 20 Mar 2014 19:17:24 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s2KJHM2q023795 for ; Thu, 20 Mar 2014 15:17:22 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s2KJHMon023792; Thu, 20 Mar 2014 15:17:22 -0400 Date: Thu, 20 Mar 2014 15:17:22 -0400 Message-Id: <201403201917.s2KJHMon023792@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: sipcore@ietf.org In-reply-to: <5320C5CC.7040806@alum.mit.edu> (pkyzivat@alum.mit.edu) References: <5320C5CC.7040806@alum.mit.edu> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1395343044; bh=0tO9QWMKCm/zIZplzI1Kg++fe6z9ny4c5m3IDKYanHE=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=e4g4VJa/LN+88mnFGv2xl+HOBbG8/PGKhaYfqXVyrfK5mueJBPQ6KTg6E64aI7AM2 3RCBPoHmKKORbyrTnbVkJGndD8qbPbgRMIzw34kErAUODCjvNVJZqoGYrdPbv5A6Rj hGcfJiy9OeVLS7vt5h78lN/QVcjY1cuuD6P8m5X4IOJmsWC8MEEqI/6DC3IZpK4g79 zVVAYzrWOOfkcPiIApxW5JiTomqeNdsDy4sg16/oLhO/BO1W5zUylasK+HJ4a5TY26 AnjLetZ8f7htb1/ZeOF2k2W7jmRXefewM9jGDaPyjNuTwWh1bwn8JNo0Dlo/g6q3qb Wtl6ccUGEba7Q== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/3sqYqjF_PsLQ9osmSNfvQwAB3_w Subject: [sipcore] Problems with GRUUs (was: Comments on draft-allen-dispatch-routing-out-of-dialog-request-00) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 19:17:35 -0000 > From: Paul Kyzivat > > I read this draft as well as the referenced draft > draft-kaplan-dispatch-gruu-problematic-00 (which somehow slipped by > without my noticing.) There is a thread that we all participated in starting at https://www.ietf.org/mail-archive/web/dispatch/current/msg02682.html. Unfortunately, the discussion wasn't very conclusive and there was no -01 version to clarify ambiguities or maintain interest. Let me comment on the discussion of draft-kaplan-dispatch-gruu-problematic-00 first: There was an inconclusive discussion of the meaning of "globally routable". After thinking about it for a bit more, I think that we need to qualify the term "globally routable", and doing so will make a number of issues clearer further on. The central question is, what is this "global" of which we speak? After all, there are parts of the Internet from/to which SIP messages are blocked, and so in principle there are *no* truly globally-routable URIs. What we have to think about is area within which a URI is routable. To make this useful, we look an area, which we can call a "garden", that is closed with regard to SIP operations: A. SIP dialogs cannot have one endpoint inside the garden and one endpoint outside the garden. B. Identifiers (including Call-Ids and Contact URIs) cannot leak from inside the garden to outside the garden. (A garden can be a set of hosts or a set of host network interfaces, or possibly even finer distinctions.) (A draft of message used the term "universe", but SIP probably isn't ready for multiple universes connected by B2BUAs.) Note that a true B2BUA may have one interface inside a garden and one interface outside the garden, because all dialogs that it handles are terminated at one interface, and a coupled but distinct dialog is initiated at the other interface. When we label a URI as a GRUU, the needed property is that it is globally routed *within the garden within which the GRUU exists*. (My understanding is:) In particular, the concatenation of all 3GPP provider networks is a garden, because dialogs may neither exit nor enter the the 3GPP walled garden, and the GRUUs that 3GPP entities construct are globally routable within that garden. Thus, these are true GRUUs (within the 3GPP garden). Now, back to draft-kaplan-dispatch-gruu-problematic-00 itself: 3. Problems with Access Proxies This section of the draft discusses several problems, the first of which is where (1) a UA A accesses an authoritative proxy AP via an edge proxy EP, (2) UA A uses its GRUU as its Contact URI, and (3) the far-end UA B makes a request within the dialog. The dialog-forming request from A to B will typically have these headers: A EP AP B -----------> Contact: sip:a@example.com;gr=xxx ---------------> Contact: sip:a@example.com;gr=xxx Record-Route: ---------------> Contact: sip:a@example.com;gr=xxx Record-Route: Record-Route: Because the GRUU must be translated by AP, a request from B to A within the dialog takes an unintended route: A EP AP B <-------------- METHOD sip:a@example.com;gr=xxx Route: Route: <--------------- METHOD sip:a@example.com;gr=xxx Route: ---------------> METHOD sip:a@example.com;gr=xxx <--------------- METHOD sip:10.1.1.1 Route: <------------ METHOD sip:10.1.1.1 As the draft says: The obvious solution is for the originating UA (Alice) to insert a Record-Route of her actual/real registered Contact-URI in the dialog-forming request. Arguably this should have been the model from the beginning for [RFC5627]. The effect is that for in-dialog use, the contact URI contained in the first Record-Route is used as the ultimate target of the request, but for out-of-dialog use, the GRUU is used: A EP AP B -----------> Contact: sip:a@example.com;gr=xxx Record-Route: ---------------> Contact: sip:a@example.com;gr=xxx Record-Route: Record-Route: ---------------> Contact: sip:a@example.com;gr=xxx Record-Route: Record-Route: Record-Route: A subsequenct in-dialog request is routed properly: <-------------- METHOD sip:a@example.com;gr=xxx Route: Route: Route: <--------------- METHOD sip:a@example.com;gr=xxx Route: Route: <------------ METHOD sip:a@example.com;gr=xxx Route: (UA A, upon receiving the request, recognizes the remaining Route URI as containing its own URI, and also recognizes the request-URI as being its own URI.) But an out-of-dialog request to A's Contact uses the GRUU: <-------------- METHOD sip:a@example.com;gr=xxx <--------------- METHOD sip:10.1.1.1 Route: <------------ METHOD sip:10.1.1.1 In regard to practical deployments where UAs use GRUUs but not implement this fix, the draft continues: An uglier but sometimes easier to deploy solution is for the Access Proxy to insert a Record-Route in the dialog-forming request on the originating UA's (Alice's) behalf, using the Via information as a pseudo-Contact. This latter method has issues if the originating UA is not directly communicating with the Access Proxy (i.e., if there is another Proxy in-between). Access Proxies which are B2BUAs with registration caching (e.g., SBC's) can insert a Record-Route of the matched registered contact, instead, to avoid such issues. The second problem raised in this section is where the edge proxy is not a proxy but rather a B2BUA, which in a quasi-proxy manner replaces the Contact in A's dialog-forming request with its own Contact sip:alias-a@ep.example.com, but maintains a mapping from sip:alias-a@ep.example.com to the original Contact URI. Assuming that this is the only change in the scenario, it results in the same sort of poor routing: A EP AP B -----------> Contact: sip:a@example.com;gr=xxx ---------------> Contact: sip:alias-a@ep.example.com ---------------> Contact: sip:alias-a@ep.example.com Record-Route: <-------------- METHOD sip:alias-a@ep.example.com <--------------- METHOD sip:alias-a@ep.example.com ---------------> METHOD sip:a@example.com;gr=xxx <--------------- METHOD sip:10.1.1.1 Route: <------------ METHOD sip:10.1.1.1 However, if UA A adds a protective Record-Route to its dialog-forming request (or if EP adds one for it), and that route is maintained as part of the mapping of sip:alias-a@ep.example.com, the desired behavior is obtained: A EP AP B -----------> Contact: sip:a@example.com;gr=xxx Record-Route: ---------------> Contact: sip:alias-a@ep.example.com ---------------> Contact: sip:alias-a@ep.example.com Record-Route: <-------------- METHOD sip:alias-a@ep.example.com Route: <--------------- METHOD sip:alias-a@ep.example.com <------------ METHOD sip:a@example.com;gr=xxx Route: However, there is a third problem posed which strikes closer to the essential questions about GRUUs: This type of scenario actually occurred in initial deployments. In the initial deployment case, the Access Proxy was not inserting a Record-Route of itself, but was instead a B2BUA inserting a new Contact-URI of itself, which it mapped back to the original (GRUU) Contact-URI. The authoritative Registrar-Proxy never sees the GRUU Contact nor a Record-Route. Therefore, in the initial deployment, the B2BUA received its own Contact URI in the Request-URI of the BYE, mapped it to "sip:alice@example.com;gr=foo", and failed to resolve that because it did not have any special/new handling for GRUUs. Using the call flow immediately above here for reference, this scenario is when EP translated sip:alias-a@ep.example.com into sip:a@example.com;gr=xxx, EP was unable to resolve the new URI at all. How could that come about? After all, EP has an interface that can talk to the proxy for domain example.com, and presumably sees suitable DNS records. By default, the result would be one of the annoying "looping" flows. What seems to be implied is that EP, *on its external interface*, cannot see any resolution for domain example.com, that is, there is no ingress SIP router for the domain example.com from that part of the internet. And this is not an unusual possibility in deployment. But comparing this scenario to my long-winded discussion of "gardens" above, what is going on is that {EP<-->AP<-->B} is one garden, and {A<-->EP} is a second garden -- and the GRUUs for example.com aren't routable in the second, "exterior" garden. Thus, the problem is not that the GRUU isn't globally routable per se, but rather that UA A was allowed to learn of a (purported) GRUU *that wasn't routable in the garden in which it sits*. So what we see is that there is an additional requirement on B2BUAs that sit on garden boundaries: They have to make sure that a GRUU cannot leak into a garden within which it is not routable. In the above scenario, EP must be responsible for removing the GRUUs from registration responses to A, because the network on which A sits cannot route those GRUUs. Once A cannot see its GRUU, it doesn't use it as its Contact URI. Of course, this makes the administrator of EP responsible for knowing which networks that it is attached to can route URIs for the domain in question, but presumably that's part of his job. And for that matter, with access to a network, one can experimentally determine whether SIP requests addressed to a particular domain work or not, and where they are routed to (for the first hop). A further case is discussed: Even if the Access Proxy had been Record-Routing, however, it would have failed in certain cases. A request from Alice to Bob need not go to any Proxy with access to the Registration database. For example, Access Proxies can typically route calls for Emergency numbers directly to gateways/peers, or Bob could simply be a conference server known to the Access Proxy to which it can route directly. In such cases, no authoritative Registrar-Proxy would be in the path to perform the mid-dialog Request-URI rewriting. Neither [RFC3261] nor [RFC5627] require all requests from a UA to route through that UA's authoritative Registrar-Proxy, and yet that is the only way a GRUU model could work as currently defined. This situation works correctly for within-dialog requests because they do not require resolving the GRUU: A EP AP B -----------> Contact: sip:a@example.com;gr=xxx Record-Route: ---------------> Contact: sip:a@example.com;gr=xxx Record-Route: Record-Route: ---------------> Contact: sip:a@example.com;gr=xxx Record-Route: Record-Route: <----------------------------- METHOD sip:a@example.com;gr=xxx Route: Route: <------------ METHOD sip:a@example.com;gr=xxx Route: and if the destination is in a location where example.com is properly resolvable, out-of-dialog requests to A's Contact are routed to AP (due to their URI) and are resolved by AP: <-------------- METHOD sip:a@example.com;gr=xxx <--------------- METHOD sip:10.1.1.1 Route: <------------ METHOD sip:10.1.1.1 But if B is in a location where example.com is not resolvable, the out-of-dialog request would fail. Assuming EP is a proxy, in that situation A and B are in the same garden (because a dialog can travel from one to the other), and since the garden containing A and B cannot resolve the purported GRUU, UA A should not have been allowed to see the GRUU. If EP is a full B2BUA, then {EP<-->B} is a garden within which the GRUU is not routable, and the B2BUA is responsible for not presenting it as the Contact of the EP-to-B dialog. Dale From nobody Thu Mar 20 12:19:52 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1314E1A0721 for ; Thu, 20 Mar 2014 12:19:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aT5BcObUj8On for ; Thu, 20 Mar 2014 12:19:48 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id C70851A06EA for ; Thu, 20 Mar 2014 12:19:47 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta01.westchester.pa.mail.comcast.net with comcast id fq4F1n0051ap0As51vKeq8; Thu, 20 Mar 2014 19:19:38 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta22.westchester.pa.mail.comcast.net with comcast id fvKe1n00D1KKtkw3ivKekK; Thu, 20 Mar 2014 19:19:38 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s2KJJbCF023911 for ; Thu, 20 Mar 2014 15:19:37 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s2KJJbGs023908; Thu, 20 Mar 2014 15:19:37 -0400 Date: Thu, 20 Mar 2014 15:19:37 -0400 Message-Id: <201403201919.s2KJJbGs023908@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: sipcore@ietf.org In-reply-to: <5320C5CC.7040806@alum.mit.edu> (pkyzivat@alum.mit.edu) References: <5320C5CC.7040806@alum.mit.edu> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1395343178; bh=9xM9+uYNGn1Oj9VOZp3BDEPEkiL9bTZeTkgOPauyRjg=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=Uc/zbKL4PTBkJk5SgawthbvjA2cf/Sg6i0YVnx1wojiwXBfwJoX735Iukf7VVHPIa x516DgxoTwId8nfLm2Ax/zLFGUDlx8CLybXbyFfoCAzCkSyxmGjNArIDV8aCEeB0AF 2e4O7TXYO3i3t0E3kp9QCjxVFiokx7iCwEn7NiKRIzDsGy680x2+XHj/Dq4HYu2LOj Rwz9ZrE1Z6NeNz8Uz/8pz/taaHBaPFJX/BOHN48NvGnBTaKBWm3TK9WL1bB8hdUex/ 9i3uqyZixRQCQ3WD6YljcgVmIDmHPmcT3kOlyhglloJ97/SXAi5r6t7LYdNMvnnIlg wHW3Tq5Wg3U3w== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/4wT8QiLeDtCnPBpCWTlBLq55IEw Subject: [sipcore] Problems with GRUUs (was: Comments on draft-allen-dispatch-routing-out-of-dialog-request-00) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 19:19:50 -0000 To continue with the analysis of draft-kaplan-dispatch-gruu-problematic-00: 4. Problems with B2BUAs To summarize this case: Because B2BUAs replace the Contact URI of forwarded requests, the final SIP UAS will not receive the GRUU of the original UAC, and may not receive a GRUU at all. The Contact URI it receives will be the URI of the last B2BUA crossed before the request reached the UAS, which may not be a GRUU nor have GRUU properties. the Contact URI may contain an IP Address or hostname which is not reachable from everywhere on the Internet, and/or it may only be usable for the duration of the dialog its request created. Attempts have been made to resolve this by having B2BUAs not change the Contact URI if it is a GRUU (i.e., has a 'gr' param). [...] However passing GRUUs through a B2BUA can only be done in very specific conditions, and often with unforeseen consequences. Since any future out-of-dialog requests may use the GRUU as their target, the B2BUA cannot expect to receive such requests if the GRUU is not its own URI. [...] In particular, if the B2BUA changed the Call-ID or tags of the original dialog, as many do, then an out-of-dialog REFER or INVITE with Replaces header won't work if it reaches the UA without passing through the same B2BUA, because the dialog identifiers of the Replaces won't be fixed by the B2BUA to match what the UA expects. [...] Fundamentally, it is not logical for most B2BUAs to "pass on" a GRUU. [...] One option is for the B2UA to generate a self-made GRUU of its own, which it can map to the Contact URI it received. Unfortunately, by definition such a GRUU's de-referenced B2BUA must be publicly reachable on the public Internet, by *any device that receives it*, on both IPv4 and IPv6. Such is almost never the case, cannot be known in advance, and may cause more issues than it solves. With reference to the previous discussion of "gardens", if the B2BUA wants to provide the outgoing request with a GRUU Contact, and the B2BUA wants to be in the routing of any additional dialog established by sending a request to the outgoing GRUU, then the B2BUA must provide one of its own GRUUs as the Contact. Critically, that GRUU must be globally routable *within to the garden into which the outgoing request is being sent*, and presumably the B2BUA can arrange for that to be true. (If there is no DNS name that routes to the B2BUA within that garden, then of course the B2BUA cannot create such a GRUU. But of course in that situation, there is no way for the B2BUA to provide a GRUU Contact.) (Note that by the analysis in the previous message, there should also be a Record-Route header providing an IP address URI for the B2BUA, unless the B2BUA is a target for its GRUU's domain name.) In regard to IPv4 vs. IPv6, see the discussion of sectin 5.3. The draft continues with this observation: 5. Problems with Global Reachability In theory, creating a GRUU which is not globally routable is simply a user error or system defect, however in practice it's difficult if not impossible for the system or user to know a priori whether a GRUU is globally routable or not. The essential point of the solution is that while it is impossible for an entity that looks at an apparent GRUU to tell if the URI is routable, entities that allow URIs to move between gardens are responsible for ensuring that an apparent GRUU is globally routable within the garden to which it is being sent. 5.1. Access-Restricted Domains In practice, even if they use SIP on the public Internet, most SIP domains are access-restricted, meaning only authorized subscriber UAs and known peers are allowed to send requests into the domain. Any SIP request from unauthorized agents are rejected or discarded. Presumably, this is a situation in which the external interfaces of the domain and its "authorized subscriber UAs and known peers" form a garden, because clearly it is not intended for dialogs to reach from those to any other destination on the Internet. Thus, as long as the domain's name has proper DNS records visible globally, and we are willing to have out-of-dialog requests to GRUUs to pass into the domain to its registrar, proper GRUUs can be constructed for the domain and the exterior garden. There is a messier case where the set of "authorized subscriber UAs and known peers" do not form a garden, because they are allowed to make calls to other UAs which are not in the authorized set. But in that case, some call transfer scenarios fail regardless of the URIs that are being used, because the two UAs to be connected are not permitted to contact each other. 5.2. Routing-Restricted Domains The problem with using GRUUs is not that routing-restricted domains can't provide GRUUs to its UAs for use as Contact-URIs in outbound requests - technically they could if they were not also access- restricted, although most if not all routing-restricted domains are also access-restricted. The real problem is that SIP requests *sent to* the routing-restricted domain can't use GRUUs for Contact-URIs, because the routing-restricted domain itself cannot de-reference a GRUU unless the GRUU's domain happens to be one it can route to based on its local policies. Since there is virtually no way for the originating or receiving domain to know where a GRUU used in a Contact-URI may end up going to, or what the local policies of a domain that attempts to de-reference the GRUU are, they can't be used anytime safely. This is a scenario that needs further explanation. As far as I understand it, it's true that there is "no way for the originating or receiving domain to know where a GRUU used in a Contact-URI may end up going to", but the same is true of any other Contact URI. There is an unspoken assumption that there is an alternative way of constructing Contact URIs that does not have these problems, but that alternative way is not described. 5.3. IPv6 Reachability The stipulation for GRUUs in [RFC5627] is that they be globally reachable on the "public Internet". Unfortunately, there are *two* public Internets: one using IPv4 and one using IPv6. One of the non-obvious implications of "global reachability" is that the domain of the GRUU must be reachable on both, because the GRUU may be passed on to IPv6-only UAs or domains, or vice-versa. In regard to IPv4 vs. IPv6, the administrators must decide whether the relevant garden includes IPv6-only devices, and for that matter IPv4-only devices. If it is desired to be able to use GRUUs in a garden that contains both IPv6-only devices and IPv4-only devices, SIP listening entities must be established for each protocol, and suitable DNS records must point to them. 6. Alternatives to GRUU Alternatively, some B2BUAs can generate "Global Contacts", [...] But since "Global Contacts" are not described, I cannot comment on them. Dale From nobody Thu Mar 20 13:20:34 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD0941A073B for ; Thu, 20 Mar 2014 13:20:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Sxo3FffDA4P for ; Thu, 20 Mar 2014 13:20:30 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 162191A048C for ; Thu, 20 Mar 2014 13:20:30 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s2KKK9uC010863 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 20 Mar 2014 20:20:10 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s2KKK8Kn009749 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Mar 2014 20:20:08 GMT Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s2KKK89T016038; Thu, 20 Mar 2014 20:20:08 GMT Received: from [10.0.1.12] (/66.31.4.61) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 20 Mar 2014 13:20:08 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Hadriel Kaplan In-Reply-To: <201403201917.s2KJHMon023792@hobgoblin.ariadne.com> Date: Thu, 20 Mar 2014 16:20:06 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9788DA1B-7B38-4DB3-BF7E-3DE7E69B4C47@oracle.com> References: <5320C5CC.7040806@alum.mit.edu> <201403201917.s2KJHMon023792@hobgoblin.ariadne.com> To: "Dale R. Worley" X-Mailer: Apple Mail (2.1874) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/ui2kjehk7wl3GCDGB9V9lDJFO-g Cc: sipcore@ietf.org Subject: Re: [sipcore] Problems with GRUUs X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 20:20:32 -0000 I'm still reading and digesting your emails, but thought I'd try to = comment on any smaller bits I can now... On Mar 20, 2014, at 3:17 PM, Dale R. Worley wrote: > (My understanding is:) In particular, the concatenation of all 3GPP > provider networks is a garden, because dialogs may neither exit nor > enter the the 3GPP walled garden, and the GRUUs that 3GPP entities > construct are globally routable within that garden. Thus, these are > true GRUUs (within the 3GPP garden). Not as far as I know. In certain situations that might be true - for = example providers inter-connected through a common exchange network such = as GSMA IPX might be able to use their own GRUUs amongst each other = maybe - but in the classic scenario no: 3GPP provider-A may not have a = direct connection to, nor route to, nor accept requests directly from, = 3GPP Provider-Z. Especially if Provider-A and Provider-Z are in = different countries. Even in the IPX case, a request from Provider-A's egress SBC, to = Provider-B through Provider-B's ingress SBC, to some endpoint inside = Provider-B... the endpoint cannot send an out-of-dialog request, using a = received Provider-A GRUU Contact, directly to Provider-A. It must go to = Provider-B's SBC first. (and this is a simplified scenario - in practice = the initial dialog will have crossed through various B2BUAs inside = Provider-B, and out-of-dialog ones need to go through *them* too) -hadriel From nobody Thu Mar 20 13:28:14 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1991E1A074E for ; Thu, 20 Mar 2014 13:28:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LHP0d1pEJhge for ; Thu, 20 Mar 2014 13:28:10 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 6A8571A073B for ; Thu, 20 Mar 2014 13:28:10 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s2KKRqna013588 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 20 Mar 2014 20:27:52 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s2KKRo6v003215 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Mar 2014 20:27:51 GMT Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s2KKRoMa005006; Thu, 20 Mar 2014 20:27:50 GMT Received: from [10.0.1.12] (/66.31.4.61) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 20 Mar 2014 13:27:50 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Hadriel Kaplan In-Reply-To: <201403201917.s2KJHMon023792@hobgoblin.ariadne.com> Date: Thu, 20 Mar 2014 16:27:43 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6F93E9EE-B2F6-4D17-99D3-070CD7321FC7@oracle.com> References: <5320C5CC.7040806@alum.mit.edu> <201403201917.s2KJHMon023792@hobgoblin.ariadne.com> To: "Dale R. Worley" X-Mailer: Apple Mail (2.1874) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/Vk-d8J0JAGiCjXHZhfNf-s1j2fk Cc: sipcore@ietf.org Subject: Re: [sipcore] Problems with GRUUs (was: Comments on draft-allen-dispatch-routing-out-of-dialog-request-00) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 20:28:12 -0000 On Mar 20, 2014, at 3:17 PM, Dale R. Worley wrote: > The central question is, what is this "global" of which we speak? > After all, there are parts of the Internet from/to which SIP messages > are blocked, and so in principle there are *no* truly > globally-routable URIs. >=20 > What we have to think about is area within which a URI is routable. > To make this useful, we look an area, which we can call a "garden", > that is closed with regard to SIP operations: >=20 > A. SIP dialogs cannot have one endpoint inside the garden and one > endpoint outside the garden. >=20 > B. Identifiers (including Call-Ids and Contact URIs) cannot leak = from > inside the garden to outside the garden. >=20 > (A garden can be a set of hosts or a set of host network interfaces, > or possibly even finer distinctions.) >=20 > (A draft of message used the term "universe", but SIP probably isn't > ready for multiple universes connected by B2BUAs.) >=20 > Note that a true B2BUA may have one interface inside a garden and > one interface outside the garden, because all dialogs that it > handles are terminated at one interface, and a coupled but distinct > dialog is initiated at the other interface. >=20 > When we label a URI as a GRUU, the needed property is that it is > globally routed *within the garden within which the GRUU exists*. Then GRUUs serve no practical purpose, because the above definition is = what just any plane-Jane RFC 3261 Contact URI already accomplishes. The = whole *point* of defining the GRUU mechanism was to have a Contact URI = which could be used to reach a specific endpoint from *anywhere*. = Right? If we're going to constrain the scope of what "anywhere" means, to boil = down to: "so long as we can talk to each other", then we've done nothing = but added a 'gr' param to a URI, afaict. Or am I misunderstanding you? -hadriel From nobody Thu Mar 20 19:00:06 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 896161A0835 for ; Thu, 20 Mar 2014 19:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c52KTPVM0Y5M for ; Thu, 20 Mar 2014 19:00:01 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id 90FE71A04B8 for ; Thu, 20 Mar 2014 19:00:01 -0700 (PDT) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta06.westchester.pa.mail.comcast.net with comcast id g1qm1n0030xGWP8561zsvU; Fri, 21 Mar 2014 01:59:52 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta12.westchester.pa.mail.comcast.net with comcast id g1zr1n00Y1KKtkw3Y1zr3F; Fri, 21 Mar 2014 01:59:52 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s2L1xpBc012825 for ; Thu, 20 Mar 2014 21:59:51 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s2L1xo4W012824; Thu, 20 Mar 2014 21:59:50 -0400 Date: Thu, 20 Mar 2014 21:59:50 -0400 Message-Id: <201403210159.s2L1xo4W012824@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: sipcore@ietf.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1395367192; bh=a7Aj6DagjqhYsrv31aBt1/UJeUBxM0dU4EmJieorZ9w=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=VAs4CwnXnKrw7K1OibzEpz7ARDhkirDjtmP8ALPylI726NGlnmD0aMrSu4hJDSYp3 iNX1H0FWlwq7iNsvimOpBxLxq/ItLgwS/aq73TstsUKDHL7bTuP46ZE1BH3YzE71ip VqH2wWqY4HG4SK1E9C9c7fazNjmAEwQFJcdek4MkTE03a4ngQ3pE27l7gnfl6l4QJ9 SWTsLA3HRXLRmktzXyumY9uC2I+KL8qsfxpEwnKGYtkGWLRnANx6jUcjmvb1FO1dKb hkAXV7qcUH1dpjVCHUR1j4L+dfA6AlJWbqzg9MZ0E2Ipf9noYJyADmUTIkbriioI2/ BQdiglrUzL8og== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/R6SjyqVDZix2M3ARObV_sk_TSN8 Subject: [sipcore] Comments on draft-allen-dispatch-routing-out-of-dialog-request-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Mar 2014 02:00:03 -0000 To get back to the main item of business, draft-allen-dispatch-routing-out-of-dialog-request-00: In general, it would be useful to see examples of the failures that we are trying to prevent, and examples of how the failures are prevented by the new mechanism(s). One reason is that failures often depend fairly sensitively on the details of the intended call flow, so it's difficult to know that one is addressing the same scenario that the draft is. Also, generally, it would be useful to perform some sort of interoperability analysis on any new mechanisms to verify that they don't impose a burden on entities that are outside of the administrative domains that deploy a new mechanism. However, if REFER and SUBSCRIBE requests are sent outside the related existing dialog then the requests will not be routed by the manipulating B2BUA and thus will either [...] fail to arrive at the remote UA due to URI manipulations or fail at the remote UA because parameters in the request (e.g Target-Dialog, Replaces, Refer-To URI, etc) do not match the values at the remote UAS. Of course, if either (1) the B2BUA must be included in any additional dialog, or (2) the B2BUA changes the dialog identifiers, then the B2BUA has to place one of its URIs as the Contact URI. But if it does so, it will then see any out-of-dialog requests, it can then adjust the request appropriately before passing it along. For instance, set up a call from A to B: A EP B -----------> INVITE sip:b@example.com Call-Id: P Contact: sip:a@example.com ---------------> INVITE sip:b@example.com Call-Id: Q Contact: sip:a-external@ep.example.com <--------------- 200 OK Call-Id: Q Contact: sip:b@example.com <----------- 200 OK Call-Id: P Contact: sip:b-internal@ep.example.com Now A sends an out-of-dialog REFER to B to cause it to transfer to C. The REFER gets routed to EP because A uses the alias for B that EP provided. Additionally, EP translates the Target-Dialog header. And if EP desires to be in the new dialog that will be created, it can translate the Refer-To header as well: -----------> REFER sip:b-internal@ep.example.com Call-Id: R Contact: sip:a@example.com Target-Dialog: P;local-tag=xxx;remote-tag=xxx Refer-To: sip:c@example.com ---------------> REFER sip:b@ep.example.com Call-Id: S Contact: sip:a-external@ep.example.com Target-Dialog: Q;local-tag=xxx;remote-tag=xxx Refer-To: sip:c-external@ep.example.com <--------------- INVITE sip:c-external@ep.example.com Call-Id: T Contact: sip:b@example.com --------------------------------------> INVITE sip:c@example.com Call-Id: U Contact: sip:b-external@ep.example.com Returning to the draft: One way B2BUAs have have addressed this problem is by acting as two UAs back-to-back with the Contact URI being overwritten to be the URI of the B2BUA. However this means that GRUU of the UA is overwritten by the B2BUA and the meaning of the Contact header field parameters becomes obscure. Do the Contact header field parameters reflect the capabilities of the Contact address (i.e the B2BUA) or do they reflect the capabilities of the remote UA? If they relect the capabilities of the B2BUA then the identfication of the capabilities of the remote UAS has been lost. If they reflect the capabilities of the remote UA then they falsely identify that the B2BUA contact address has the capabilities of the remote UA. (BTW, aren't Contact header field parameters described by RFC 3840 rather than RFC 6809 (which is your reference)?) Assuming that the B2BUA is largely transparent to SIP requests and SDP, then the capabilities of the B2BUA contact address *are the same* as the capabilities of the remote UA. If the remote UA advertises "video" then the B2BUA contact also has video capabilities, etc. Of course, if the B2BUA is somehow restricting or editing what passes through, then it must properly edit the Contact parameters to remove any capabilities that it is blocking. Dale From nobody Fri Mar 21 11:20:12 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 473131A0A21 for ; Fri, 21 Mar 2014 11:20:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b1zzVhbuu_eS for ; Fri, 21 Mar 2014 11:20:07 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 594841A0A23 for ; Fri, 21 Mar 2014 11:20:05 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta02.westchester.pa.mail.comcast.net with comcast id gE0k1n00C1ZXKqc51JKvtL; Fri, 21 Mar 2014 18:19:55 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta21.westchester.pa.mail.comcast.net with comcast id gJKv1n00N1KKtkw3hJKvBe; Fri, 21 Mar 2014 18:19:55 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s2LIJsas006670; Fri, 21 Mar 2014 14:19:54 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s2LIJs6x006669; Fri, 21 Mar 2014 14:19:54 -0400 Date: Fri, 21 Mar 2014 14:19:54 -0400 Message-Id: <201403211819.s2LIJs6x006669@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Hadriel Kaplan In-reply-to: <6F93E9EE-B2F6-4D17-99D3-070CD7321FC7@oracle.com> (hadriel.kaplan@oracle.com) References: <5320C5CC.7040806@alum.mit.edu> <201403201917.s2KJHMon023792@hobgoblin.ariadne.com> <6F93E9EE-B2F6-4D17-99D3-070CD7321FC7@oracle.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1395425995; bh=TnzBCvOka88cFkMqt9CzczbIBCH+mSY7y37c5uULTdM=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=MippGzzJ0WBD/dV871lAeytMHPQr4L7uOFRiT3jzJMnIEVKW/B2PnYGSIgGWAgcFh dP0jVx54MU95gCgBKzq3ss9EjP7GvdWXmnh/QrKnayR4I/CGHJP+11SBNZNW1NDi5u HT8EZe25F+brjpL24QO4pWyoRn/12y5PNZDsvZ2+EU7mg7X6pbhoR8Mrid6AagG0uK y5Wy/mdRuo3qB8f3JjYWMUtRakgkfwl1qOmCQ6Vvgq5YMnQ3SDKkUuBNgq27uzVGro /xXcXFrYtBGyrwzWIQLLh1EaN9jxeaO5RwiS2M8yQAYiyTbvIegaZ4TBFx4jYTFk+E eNn0zYcTWkluQ== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/Jh7H28pcP5zYAnnpc2UuIT3A2Iw Cc: sipcore@ietf.org Subject: Re: [sipcore] Problems with GRUUs (was: Comments on draft-allen-dispatch-routing-out-of-dialog-request-00) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Mar 2014 18:20:10 -0000 > From: Hadriel Kaplan > > > When we label a URI as a GRUU, the needed property is that it is > > globally routed *within the garden within which the GRUU exists*. > > Then GRUUs serve no practical purpose, because the above definition > is what just any plane-Jane RFC 3261 Contact URI already > accomplishes. The whole *point* of defining the GRUU mechanism was > to have a Contact URI which could be used to reach a specific > endpoint from *anywhere*. Right? > > If we're going to constrain the scope of what "anywhere" means, to > boil down to: "so long as we can talk to each other", then we've > done nothing but added a 'gr' param to a URI, afaict. > > Or am I misunderstanding you? You're misunderstanding me, but the distinction is tricky, and it's possible that I haven't forumulated it with sufficient accuracy. The critical point of a GRUU is that *if an entity can see that URI* then *that entity can use it for contacting that UA*. Now, in a flat, end-to-end network, that's nearly the same as the old definition. (In parts of the network that aren't accessible to SIP at all, there is no entity that can see the URI, and so the fact that they can't contact the UA is irrelevant.) What makes this interesting is the situation where the network is partitioned by SBCs, that is, where SIP traffic can get from one garden to another only by passing through an SBC. Even if the GRUUs for the selected domain work fine in one garden (ex. the interior of the organization), they might not be usable at all in the other garden (ex. the public internet). But the fact that the GRUU works fine in one garden is an interesting fact, and they work just like one would hope within that garden. What raises gardens from just being subsets of the network is that URIs can be carried from one entity to another in various ways, so a garden has to be "sealed off" from the rest of the network in a way that prevents URIs (and dialog identifiers) from leaking out of the garden. Functionally, the point is that SBCs have to be aware, for each network segment that it is connected to, whether GRUU URIs for its domain are valid there, and censor (or otherwise revise) GRUUs that would otherwise be propagated into segments they are not valid for. Dale From nobody Fri Mar 21 11:53:41 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B06001A0A39 for ; Fri, 21 Mar 2014 11:53:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bhn-J5j5ZE1p for ; Fri, 21 Mar 2014 11:53:38 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 6FBCD1A0790 for ; Fri, 21 Mar 2014 11:53:37 -0700 (PDT) X-AuditID: c1b4fb38-b7f418e000001099-08-532c8aa7eb12 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 11.03.04249.7AA8C235; Fri, 21 Mar 2014 19:53:27 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.213]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.02.0387.000; Fri, 21 Mar 2014 19:53:27 +0100 From: Christer Holmberg To: "Dale R. Worley" , Hadriel Kaplan Thread-Topic: [sipcore] Problems with GRUUs (was: Comments on draft-allen-dispatch-routing-out-of-dialog-request-00) Thread-Index: AQHPRHEMi4KCo6zVyEC7CJ/U9Nl245rqXAuAgAF/cdeAAAjGEA== Date: Fri, 21 Mar 2014 18:53:26 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D25A485@ESESSMB209.ericsson.se> References: <5320C5CC.7040806@alum.mit.edu> <201403201917.s2KJHMon023792@hobgoblin.ariadne.com> <6F93E9EE-B2F6-4D17-99D3-070CD7321FC7@oracle.com> <201403211819.s2LIJs6x006669@hobgoblin.ariadne.com> In-Reply-To: <201403211819.s2LIJs6x006669@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrELMWRmVeSWpSXmKPExsUyM+Jvje7yLp1gg6035C0+bfrEbPH1xyY2 i5cnyhyYPSbv/8rssWTJTyaPj09vsQQwR3HZpKTmZJalFunbJXBlHHu2lr1gHV9F78HkBsZN 3F2MnBwSAiYS+4//YoSwxSQu3FvP1sXIxSEkcIRR4sStx8wgCSGBJYwSh6fadjFycLAJWEh0 /9MGCYsIhEvs+XOQHcRmFtCUeLRzLxNIibBAqcTKg5UQJWUS756+YwEJiwg4Sey5Fg8SZhFQ lTh6+AELiM0r4Cvxbup8dohFpxklOuaagdicAg4SPyZ+ALuMEeiy76fWMEFsEpe49WQ+E8TF AhJL9pxnhrBFJV4+/scKYStJLLr9GapeR2LB7k9sELa2xLKFr5kh9gpKnJz5hGUCo9gsJGNn IWmZhaRlFpKWBYwsqxg5ilOLk3LTjQw2MQLj5eCW3xY7GC//tTnEKM3BoiTO+/Gtc5CQQHpi SWp2ampBalF8UWlOavEhRiYOTqkGxvTotMerG8+fPHRSke9784ErXUm9Uk5Hg51vzP2f/Fbm dp2fztEt5XFxHXsdXWcv/xOx4dfcn2f5/8wveuL69QKvxYuif1Lbn2dp/0pdV/JZaIpBRPmL 0PUGN8715NVenOQ5PU9lhvZcr7f/nGOV9ER+qiyTDZeepOO960HYZta/Jw/UbThTWKnEUpyR aKjFXFScCAB+7EhLZQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/8245XoRNRcicv8scKg3WyqeOOYs Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Problems with GRUUs (was: Comments on draft-allen-dispatch-routing-out-of-dialog-request-00) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Mar 2014 18:53:40 -0000 Hi, >> Then GRUUs serve no practical purpose, because the above definition is=20 >> what just any plane-Jane RFC 3261 Contact URI already accomplishes. =20 >> The whole *point* of defining the GRUU mechanism was to have a Contact=20 >> URI which could be used to reach a specific endpoint from *anywhere*. =20 >> Right? >>=20 >> If we're going to constrain the scope of what "anywhere" means, to=20 >> boil down to: "so long as we can talk to each other", then we've done=20 >> nothing but added a 'gr' param to a URI, afaict. >>=20 >> Or am I misunderstanding you? > >You're misunderstanding me, but the distinction is tricky, and it's possib= le that I haven't >forumulated it with sufficient accuracy. > >The critical point of a GRUU is that *if an entity can see that URI* then = *that entity can use it for >contacting that UA*. Now, in a flat, end-to-e= nd network, that's nearly the same as the old >definition. (In parts of th= e network that aren't accessible to SIP at all, there is no entity that can= see >the URI, and so the fact that they can't contact the UA is irrelevant= .) > >What makes this interesting is the situation where the network is partitio= ned by SBCs, that is, where >SIP traffic can get from one garden to another= only by passing through an SBC. Even if the GRUUs >for the selected domai= n work fine in one garden (ex. the interior of the organization), they migh= t >not be usable at all in the other garden (ex. the public internet). But= the fact that the GRUU works >fine in one garden is an interesting fact, a= nd they work just like one would hope within that garden. ...and that's the reason such GRUUs shouldn't be passed into the other gard= en to begin with - and it's the reason why B2BUAs often remove/overwrite th= em. Regards, Christer From nobody Fri Mar 21 12:05:23 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE39B1A0A23 for ; Fri, 21 Mar 2014 12:05:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U7xpUo17zncF for ; Fri, 21 Mar 2014 12:05:21 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 560AE1A0A1D for ; Fri, 21 Mar 2014 12:05:21 -0700 (PDT) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta03.westchester.pa.mail.comcast.net with comcast id gB6m1n0020Fqzac53K5Bsd; Fri, 21 Mar 2014 19:05:11 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta08.westchester.pa.mail.comcast.net with comcast id gK5B1n00F1KKtkw3UK5BrG; Fri, 21 Mar 2014 19:05:11 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s2LJ5AWm009184; Fri, 21 Mar 2014 15:05:10 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s2LJ5ADq009183; Fri, 21 Mar 2014 15:05:10 -0400 Date: Fri, 21 Mar 2014 15:05:10 -0400 Message-Id: <201403211905.s2LJ5ADq009183@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Hadriel Kaplan In-reply-to: <7F8BCA35-A22D-4911-8C2A-0433727E14FE@oracle.com> (hadriel.kaplan@oracle.com) References: <7F8BCA35-A22D-4911-8C2A-0433727E14FE@oracle.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1395428711; bh=CsVhdCEAmafk6YZuWR3JNE/ciX6o1b9OocE6aHhubLY=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=i3TRdr7aZlMkzBD8CorlJtFLUG0Eie7KhG1VJroSChS4DWawura+M/aMfsd06SPQU H8YfwFBFwiJQdIdxpIFLVyDm/+iS98+2b/ZOVHLQf8Pkrm8zEcZTpDPN8qlOzfhgUG AKHQjnRVvHzAYH2X2X23xZACv7jiD/D8iEfuoOSKMUl5DHq0MAyi0GOTqvlDhJroLv kk0n9eCuThNYtGTh2y5lfGApetV2IKSs0PouxoiqUWjtGAh/miCffz//1euzxGwaUV qu64lyjkNS6EaOo8Nl7MlcAATSt/4DjKLEH9+Xxw42XAJExqUEzKlffQEyiMkQK9lW vnrcOKL9CuMIQ== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/Wa4l3cgFzC47bluDExKh2G2uU8I Cc: sipcore@ietf.org Subject: Re: [sipcore] [dispatch] Comments on draft-allen-dispatch-routing-out-of-dialog-request-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Mar 2014 19:05:23 -0000 [moved from Dispatch] > From: Hadriel Kaplan > > On Mar 16, 2014, at 8:54 PM, Andrew Allen wrote: > > Having B2BUAs only include feature tags they understand to my view > means no innovation and no new services. B2BUAs have then become the > switches of old needing all to be updated or reconfigured to support > any new services. > > Yup, and that's exactly the right thing to happen. It's what most > IMS operators actually should *want* to happen as well. > It's really not a bad thing to want service stability. You can do it whichever way you prefer. The B2BUA can copy all of the feature tags if it is also transparent (proxy-like) enough that it isn't goint to hinder any new features. But if the B2BUA wants to enforce stability, and goes to the effort to edit the SIP/SDP in detail, then it should perform the corresponding editing of the feature tags. Dale From nobody Fri Mar 21 12:09:24 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 793B91A0A1F for ; Fri, 21 Mar 2014 12:09:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VgK9_TSMcyXa for ; Fri, 21 Mar 2014 12:09:20 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id EAC151A0A16 for ; Fri, 21 Mar 2014 12:09:19 -0700 (PDT) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta06.westchester.pa.mail.comcast.net with comcast id gFXu1n00A0EZKEL56K9AGr; Fri, 21 Mar 2014 19:09:10 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta01.westchester.pa.mail.comcast.net with comcast id gK9A1n0041KKtkw3MK9AtL; Fri, 21 Mar 2014 19:09:10 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s2LJ94gs009405; Fri, 21 Mar 2014 15:09:04 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s2LJ94e3009404; Fri, 21 Mar 2014 15:09:04 -0400 Date: Fri, 21 Mar 2014 15:09:04 -0400 Message-Id: <201403211909.s2LJ94e3009404@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Andrew Allen In-reply-to: (aallen@blackberry.com) References: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1395428950; bh=4ok4eEMot4Yfkj3QNoXozcKIvXxRF6eyxtn4el85k/o=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=Z0XDFMSQVP6+MbPufO20FhC62fDyBoEeXUGousC9XH408zD3OJzEVReGNdF5Kid+D 1pv+bmHqvgw0eOlaP1F1nBTiVqTJEgV/YiomcLpqoiRdTkWIA0GqEkhLvkEdJbJEaJ hUFF9y1HH2znv67IW626DDVPVjEqpaqCGsTv/g7HHdCy33Oagm6qDwvJ70COAhUJS9 UFsOcvSc9QeZtzh04P/n7xFnX1KgatWKiULiOfpnorUXbXSLt4a2dNv4Bk07stowrx JgG1+7BWBqapOmxrTSL0pySL6V/rBmZkLDYhSN2AaXUcfuHg5DtkFuPtlwaBcf96lS MMyF2TUvuinog== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/-vWPJY8gdHGb5YgzRqufF5sJ4zo Cc: sipcore@ietf.org Subject: Re: [sipcore] [dispatch] Comments on draft-allen-dispatch-routing-out-of-dialog-request-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Mar 2014 19:09:22 -0000 [moved from Dispatch] > From: Andrew Allen > > In addition as I state in my draft modifying the Contact header > field means either the media feature tags of the remote UA are lost > or the B2BUA is saying if you send a request to this address > (including potentially after this session has ended) you can expect > that this feature is supported. Yes, but ... The Contact URI that the B2BUA uses is really a stand-in for the "real" Contact URI. That is, the B2BUA has to use *different* Contact URIs depending for each original Contact URI. But it has to be doing that already if out-of-dialog requests are going to work at all. If the B2BUA receives an OOD REFER, it has to know which destination "on the other side" to send the REFER to, and it has only the request-URI to tell it that. But if you are using different Contact URIs for each actual destination, then it isn't confusing to provide different media feature tags for diffent Contact URIs. Dale From nobody Fri Mar 21 12:32:11 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 925751A0A1D for ; Fri, 21 Mar 2014 12:32:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dd2ye7GK2dm5 for ; Fri, 21 Mar 2014 12:32:06 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id E75331A09FD for ; Fri, 21 Mar 2014 12:32:05 -0700 (PDT) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta08.westchester.pa.mail.comcast.net with comcast id gBkG1n0031swQuc58KXwjy; Fri, 21 Mar 2014 19:31:56 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta15.westchester.pa.mail.comcast.net with comcast id gKXv1n0141KKtkw3bKXwxK; Fri, 21 Mar 2014 19:31:56 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s2LJVts0010648; Fri, 21 Mar 2014 15:31:55 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s2LJVs4B010647; Fri, 21 Mar 2014 15:31:54 -0400 Date: Fri, 21 Mar 2014 15:31:54 -0400 Message-Id: <201403211931.s2LJVs4B010647@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Hadriel Kaplan In-reply-to: <430D6703-6B3A-4E23-AC66-53B1DE68EAE9@oracle.com> (hadriel.kaplan@oracle.com) References: <5320C5CC.7040806@alum.mit.edu> <5320E329.5000209@alum.mit.edu> <430D6703-6B3A-4E23-AC66-53B1DE68EAE9@oracle.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1395430316; bh=RFXWeApDNcTNks7zPQfPtpp/oBZ6zsBb12UWFwqdj9c=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=p5uyuZ3zeAVCTy9Zy+Req01rXDzijLUFO5r9ilo6FYV88vKrLP9UZwMNBoQJGyIxP txNIEjgHDoJfWrchrd2q8M0Jw1GvXwkNSaGlIk52vprAF+v9FcF6Pj+yq+EdRUXn2V wjwBEOGihGvlDYJY2EwHeVoJXH64UmZEYZSbsJb8I8mGoCItKwqeVS+2NxotVxbuMA QDujLD8A6xVgTPzhpdzWfuWGaJFXywCdrbAovLs3vwMLuzpkyIpDcDHOU3BY72yS/X 3b1etDcV2Bf8UOpmx3GX9ftQ5RRH6gcNNCDL1bCyCI6vNLo544Tse1vxwNkkbkdkz3 TKLrcvVMODt/w== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/Rh4wm4QTkX7FYLY5J8gW8JOmVM0 Cc: sipcore@ietf.org Subject: Re: [sipcore] [dispatch] Comments on draft-allen-dispatch-routing-out-of-dialog-request-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Mar 2014 19:32:08 -0000 [moved from Dispatch] > From: Hadriel Kaplan > There is no problem I know of, so long as you do NOT use GRUUs, or > ignore the 'gr' param and just behave like they're normal contact > URIs. I'm curious what you mean by "just behave like they're normal contact URIs". My understanding is that the contact URI is used for whatever it's used for *because* it's the contact URI. If it's marked as a GRUU, that presumably is a hint that your odds of success are higher, but what would you do differently? As far as I know, the one change is that if the contact URI is marked as a GRUU, the UA is more likely to attempt to send REFERs for the dialog out-of-dialog. As you say in draft-kaplan-dispatch-gruu-problematic-00: Furthermore, [RFC5589] prescribes sending a REFER outside of the INVITE dialog if a GRUU is available, since with a GRUU the Transferor "knows the Contact URI is routable outside the dialog". and in RFC 5589: As a result, if the Transferee supports the target-dialog extension and the Transferor knows the Contact URI is routable outside the dialog, the REFER SHOULD be sent in a new dialog. If the nature of the Contact URI is not known or if support for the target-dialog extension is not known, the REFER SHOULD be sent inside the existing dialog. A Transferee MUST be prepared to receive a REFER either inside or outside a dialog. One way that a Transferor could know that a Contact URI is routable outside a dialog is by validation (e.g., sending an OPTIONS and receiving a response) or if it satisfies the properties described in the GRUU specification [SIP-GRUU]. Is this the entirety of what you mean by "behaving as if it's a GRUU"? In your draft, you also write: Instead, a logically similar model has been successfully deployed using "Global Contacts", which are Contact URIs having the properties of a GRUU, but not being a GRUU in syntax (i.e., without a 'gr' param, and not indicating an AoR). This has the benefit that downstream B2BUAs/UAs will not treat the Contact as a special GRUU case. Global Contacts are not always valid after their dialog is terminated, but it remains to be seen if this will cause problems in the future. Currently the main use-case for GRUU-like properties is for call-transfer scenarios, for which dialog lifetime is sufficient. Could you give us some detail as to what a "global contact" is and how it works? Dale From nobody Fri Mar 21 13:09:08 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 924021A0A1E for ; Fri, 21 Mar 2014 13:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.235 X-Spam-Level: X-Spam-Status: No, score=-0.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_BACKHAIR_21=1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hkVapX_haybf for ; Fri, 21 Mar 2014 13:08:46 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id AEC7A1A0A10 for ; Fri, 21 Mar 2014 13:08:38 -0700 (PDT) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta02.westchester.pa.mail.comcast.net with comcast id gBQE1n00417dt5G51L8VtB; Fri, 21 Mar 2014 20:08:29 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta13.westchester.pa.mail.comcast.net with comcast id gL8U1n01B3ZTu2S3ZL8VTM; Fri, 21 Mar 2014 20:08:29 +0000 Message-ID: <532C9C3C.9080200@alum.mit.edu> Date: Fri, 21 Mar 2014 16:08:28 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: sipcore@ietf.org References: <5320C5CC.7040806@alum.mit.edu> <201403201917.s2KJHMon023792@hobgoblin.ariadne.com> In-Reply-To: <201403201917.s2KJHMon023792@hobgoblin.ariadne.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1395432509; bh=vX4a5Z8IKUFOBtcmLKrZqZmIdJS1dH3KoJntA4ZPN28=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=NEikYPThntHZVehUOSo1E89UT6vQvmuaq/i+8DaB+QEhuQUzqsZwhc5yPdC5jAwnI 5a0AaceUy3puKmIl3mv/n21Y5vHVwi38uZlBBkud9rcA1vr4o85ZDcYafHG6xyy4DD TuQfGB1YuOGep9s2MjlBr06L8iRaVIU4ZIWb9RPgGEmHIZAaCTUG+6wypCpoyZ7Dg2 t0xw9yZYimY1lH5VEdv7OF7RlU2Z2fkmAPz8NXZNSxubO4CGW7qwcp4bY8zGVpZjdc GYzRfYzKmBCW35N2CYPlnkSi2VK/obGqq2LzVjTy58w339uSxCWyLqpgb08fpqIACJ 0GUbg5nv6PeWA== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/OkX-MiOgrs1wjq1kKRgp0dBMSds Subject: Re: [sipcore] Problems with GRUUs X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Mar 2014 20:08:50 -0000 Dale, I don't know if I agree with your definitions here. I see two distinct issues here: - uniqueness of addresses (both DNS and IP) - reachability IMO, when we are talking about gruus, what we are really talking about is primarily global uniqueness. The registrar-provided gruus are intended to *help* with this for devices behind NATs, so that they can get a globally unique address. Even with globally unique addresses there is no guarantee of reachability. Some devices may have a policy about who may reach them, and how. If their globally reachable address is used some other way they may block the request. And they may utilize intermediaries to help them enforce the policy. I don't think SIP considers such behavior wrong. But, if UA-B intends that it be possible for UA-A to be able to send out-of-dialog requests to it, then when it provides a contact address, it should provide one that will *work* for UA-A to reach UA-B out-of-dialog. This should be part of the sip contract, and GRUU is an assistance to achieving that. If UA-B doesn't want to be reached except in-dialog, then this doesn't apply. But then it must accept that many features won't work, because those may well require out-of-dialog access. Thanks, Paul On 3/20/14 3:17 PM, Dale R. Worley wrote: >> From: Paul Kyzivat >> >> I read this draft as well as the referenced draft >> draft-kaplan-dispatch-gruu-problematic-00 (which somehow slipped by >> without my noticing.) > > There is a thread that we all participated in starting at > https://www.ietf.org/mail-archive/web/dispatch/current/msg02682.html. > Unfortunately, the discussion wasn't very conclusive and there was no > -01 version to clarify ambiguities or maintain interest. > > Let me comment on the discussion of > draft-kaplan-dispatch-gruu-problematic-00 first: > > There was an inconclusive discussion of the meaning of "globally > routable". After thinking about it for a bit more, I think that we > need to qualify the term "globally routable", and doing so will make a > number of issues clearer further on. > > The central question is, what is this "global" of which we speak? > After all, there are parts of the Internet from/to which SIP messages > are blocked, and so in principle there are *no* truly > globally-routable URIs. > > What we have to think about is area within which a URI is routable. > To make this useful, we look an area, which we can call a "garden", > that is closed with regard to SIP operations: > > A. SIP dialogs cannot have one endpoint inside the garden and one > endpoint outside the garden. > > B. Identifiers (including Call-Ids and Contact URIs) cannot leak from > inside the garden to outside the garden. > > (A garden can be a set of hosts or a set of host network interfaces, > or possibly even finer distinctions.) > > (A draft of message used the term "universe", but SIP probably isn't > ready for multiple universes connected by B2BUAs.) > > Note that a true B2BUA may have one interface inside a garden and > one interface outside the garden, because all dialogs that it > handles are terminated at one interface, and a coupled but distinct > dialog is initiated at the other interface. > > When we label a URI as a GRUU, the needed property is that it is > globally routed *within the garden within which the GRUU exists*. > > (My understanding is:) In particular, the concatenation of all 3GPP > provider networks is a garden, because dialogs may neither exit nor > enter the the 3GPP walled garden, and the GRUUs that 3GPP entities > construct are globally routable within that garden. Thus, these are > true GRUUs (within the 3GPP garden). > > Now, back to draft-kaplan-dispatch-gruu-problematic-00 itself: > > 3. Problems with Access Proxies > > This section of the draft discusses several problems, the first of > which is where (1) a UA A accesses an authoritative proxy AP via an > edge proxy EP, (2) UA A uses its GRUU as its Contact URI, and (3) > the far-end UA B makes a request within the dialog. > > The dialog-forming request from A to B will typically have these > headers: > > A EP AP B > -----------> > Contact: sip:a@example.com;gr=xxx > ---------------> > Contact: sip:a@example.com;gr=xxx > Record-Route: > ---------------> > Contact: sip:a@example.com;gr=xxx > Record-Route: > Record-Route: > > Because the GRUU must be translated by AP, a request from B to A > within the dialog takes an unintended route: > > A EP AP B > <-------------- > METHOD sip:a@example.com;gr=xxx > Route: > Route: > <--------------- > METHOD sip:a@example.com;gr=xxx > Route: > ---------------> > METHOD sip:a@example.com;gr=xxx > <--------------- > METHOD sip:10.1.1.1 > Route: > <------------ > METHOD sip:10.1.1.1 > > As the draft says: > > The obvious solution is for the originating UA (Alice) to insert a > Record-Route of her actual/real registered Contact-URI in the > dialog-forming request. Arguably this should have been the model > from the beginning for [RFC5627]. > > The effect is that for in-dialog use, the contact URI contained in the > first Record-Route is used as the ultimate target of the request, but > for out-of-dialog use, the GRUU is used: > > A EP AP B > -----------> > Contact: sip:a@example.com;gr=xxx > Record-Route: > ---------------> > Contact: sip:a@example.com;gr=xxx > Record-Route: > Record-Route: > ---------------> > Contact: sip:a@example.com;gr=xxx > Record-Route: > Record-Route: > Record-Route: > > A subsequenct in-dialog request is routed properly: > <-------------- > METHOD sip:a@example.com;gr=xxx > Route: > Route: > Route: > <--------------- > METHOD sip:a@example.com;gr=xxx > Route: > Route: > <------------ > METHOD sip:a@example.com;gr=xxx > Route: > > (UA A, upon receiving the request, recognizes the remaining Route URI > as containing its own URI, and also recognizes the request-URI as > being its own URI.) > > But an out-of-dialog request to A's Contact uses the GRUU: > <-------------- > METHOD sip:a@example.com;gr=xxx > <--------------- > METHOD sip:10.1.1.1 > Route: > <------------ > METHOD sip:10.1.1.1 > > In regard to practical deployments where UAs use GRUUs but not > implement this fix, the draft continues: > > An uglier but sometimes easier to > deploy solution is for the Access Proxy to insert a Record-Route in > the dialog-forming request on the originating UA's (Alice's) behalf, > using the Via information as a pseudo-Contact. This latter method > has issues if the originating UA is not directly communicating with > the Access Proxy (i.e., if there is another Proxy in-between). > Access Proxies which are B2BUAs with registration caching (e.g., > SBC's) can insert a Record-Route of the matched registered contact, > instead, to avoid such issues. > > The second problem raised in this section is where the edge proxy is > not a proxy but rather a B2BUA, which in a quasi-proxy manner replaces > the Contact in A's dialog-forming request with its own Contact > sip:alias-a@ep.example.com, but maintains a mapping from > sip:alias-a@ep.example.com to the original Contact URI. > > Assuming that this is the only change in the scenario, it results in > the same sort of poor routing: > > A EP AP B > -----------> > Contact: sip:a@example.com;gr=xxx > ---------------> > Contact: sip:alias-a@ep.example.com > ---------------> > Contact: sip:alias-a@ep.example.com > Record-Route: > <-------------- > METHOD sip:alias-a@ep.example.com > <--------------- > METHOD sip:alias-a@ep.example.com > ---------------> > METHOD sip:a@example.com;gr=xxx > <--------------- > METHOD sip:10.1.1.1 > Route: > <------------ > METHOD sip:10.1.1.1 > > However, if UA A adds a protective Record-Route to its dialog-forming > request (or if EP adds one for it), and that route is maintained as > part of the mapping of sip:alias-a@ep.example.com, the desired > behavior is obtained: > > A EP AP B > -----------> > Contact: sip:a@example.com;gr=xxx > Record-Route: > ---------------> > Contact: sip:alias-a@ep.example.com > ---------------> > Contact: sip:alias-a@ep.example.com > Record-Route: > <-------------- > METHOD sip:alias-a@ep.example.com > Route: > <--------------- > METHOD sip:alias-a@ep.example.com > <------------ > METHOD sip:a@example.com;gr=xxx > Route: > > However, there is a third problem posed which strikes closer to the > essential questions about GRUUs: > > This type of scenario actually occurred in initial deployments. In > the initial deployment case, the Access Proxy was not inserting a > Record-Route of itself, but was instead a B2BUA inserting a new > Contact-URI of itself, which it mapped back to the original (GRUU) > Contact-URI. The authoritative Registrar-Proxy never sees the GRUU > Contact nor a Record-Route. Therefore, in the initial deployment, > the B2BUA received its own Contact URI in the Request-URI of the > BYE, mapped it to "sip:alice@example.com;gr=foo", and failed to > resolve that because it did not have any special/new handling for > GRUUs. > > Using the call flow immediately above here for reference, this > scenario is when EP translated sip:alias-a@ep.example.com into > sip:a@example.com;gr=xxx, EP was unable to resolve the new URI at all. > How could that come about? After all, EP has an interface that can > talk to the proxy for domain example.com, and presumably sees suitable > DNS records. By default, the result would be one of the annoying > "looping" flows. > > What seems to be implied is that EP, *on its external interface*, > cannot see any resolution for domain example.com, that is, there is no > ingress SIP router for the domain example.com from that part of the > internet. And this is not an unusual possibility in deployment. But > comparing this scenario to my long-winded discussion of "gardens" > above, what is going on is that {EP<-->AP<-->B} is one garden, and > {A<-->EP} is a second garden -- and the GRUUs for example.com aren't > routable in the second, "exterior" garden. > > Thus, the problem is not that the GRUU isn't globally routable per se, > but rather that UA A was allowed to learn of a (purported) GRUU *that > wasn't routable in the garden in which it sits*. > > So what we see is that there is an additional requirement on B2BUAs > that sit on garden boundaries: They have to make sure that a GRUU > cannot leak into a garden within which it is not routable. > > In the above scenario, EP must be responsible for removing the GRUUs > from registration responses to A, because the network on which A sits > cannot route those GRUUs. Once A cannot see its GRUU, it doesn't use > it as its Contact URI. > > Of course, this makes the administrator of EP responsible for knowing > which networks that it is attached to can route URIs for the domain in > question, but presumably that's part of his job. And for that matter, > with access to a network, one can experimentally determine whether SIP > requests addressed to a particular domain work or not, and where they > are routed to (for the first hop). > > A further case is discussed: > > Even if the Access Proxy had been Record-Routing, however, it would > have failed in certain cases. A request from Alice to Bob need not > go to any Proxy with access to the Registration database. For > example, Access Proxies can typically route calls for Emergency > numbers directly to gateways/peers, or Bob could simply be a > conference server known to the Access Proxy to which it can route > directly. In such cases, no authoritative Registrar-Proxy would be > in the path to perform the mid-dialog Request-URI rewriting. > Neither [RFC3261] nor [RFC5627] require all requests from a UA to > route through that UA's authoritative Registrar-Proxy, and yet that > is the only way a GRUU model could work as currently defined. > > This situation works correctly for within-dialog requests because they > do not require resolving the GRUU: > > A EP AP B > -----------> > Contact: sip:a@example.com;gr=xxx > Record-Route: > ---------------> > Contact: sip:a@example.com;gr=xxx > Record-Route: > Record-Route: > ---------------> > Contact: sip:a@example.com;gr=xxx > Record-Route: > Record-Route: > > <----------------------------- > METHOD sip:a@example.com;gr=xxx > Route: > Route: > <------------ > METHOD sip:a@example.com;gr=xxx > Route: > > and if the destination is in a location where example.com is properly > resolvable, out-of-dialog requests to A's Contact are routed to AP > (due to their URI) and are resolved by AP: > > <-------------- > METHOD sip:a@example.com;gr=xxx > <--------------- > METHOD sip:10.1.1.1 > Route: > <------------ > METHOD sip:10.1.1.1 > > But if B is in a location where example.com is not resolvable, the > out-of-dialog request would fail. Assuming EP is a proxy, in that > situation A and B are in the same garden (because a dialog can travel > from one to the other), and since the garden containing A and B cannot > resolve the purported GRUU, UA A should not have been allowed to see > the GRUU. If EP is a full B2BUA, then {EP<-->B} is a garden within > which the GRUU is not routable, and the B2BUA is responsible for not > presenting it as the Contact of the EP-to-B dialog. > > Dale > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Fri Mar 21 14:37:14 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCE811A07F8 for ; Fri, 21 Mar 2014 14:37:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2r6_ro5_Zq-4 for ; Fri, 21 Mar 2014 14:37:10 -0700 (PDT) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id 68AA21A0753 for ; Fri, 21 Mar 2014 14:37:10 -0700 (PDT) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta14.westchester.pa.mail.comcast.net with comcast id gMLQ1n0071GhbT85EMd0cP; Fri, 21 Mar 2014 21:37:00 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta07.westchester.pa.mail.comcast.net with comcast id gMd01n00q3ZTu2S3TMd0m3; Fri, 21 Mar 2014 21:37:00 +0000 Message-ID: <532CB0FC.7010306@alum.mit.edu> Date: Fri, 21 Mar 2014 17:37:00 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: SIPCORE Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1395437820; bh=nXjqMSRrmj3Yqtzqq8HwITv7IK/kQB1TUfqt4aiX+lI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=laoqBDXguELLSxfovbXXynMBeoC6VEqFwXMGGXKWtEege48JDdBS3tQqNf6nVCJi/ gOkcrT9H5hbDLkFHuvQe9C5sQd78HyG7d6gmOwJtv8w/tHGvNXao/u09I+G2AAkRM6 qaUaGZ2+1KaeWse5NMvelryVqCEHrvBOhYetm9No/9qBLDnWI0edTFsLWqwGth8xCH NAiyrjJ6xOv4UNEOpHZpi3JCUs1TKlmbfTs2zkBdPcfujuwI4GY7tZMb10tItgW0aF RYUP9LwrCu5MRiyaLKbY4c8ZIBFlGehUvTx3PdkX4Puwi+ZIZDnKF+fHF7a1vgfNMH obMbksEHPA6MA== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/lyRbyt41BW6DrOHpDCpZunuposI Subject: [sipcore] SIPCORE Minutes, IETF89, March 2014 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Mar 2014 21:37:12 -0000 The raw notes from the SIPCORE sessions, along with a summary of conclusions and action items have been posted for the IETF89 proceedings. You can find them at: https://datatracker.ietf.org/secr/proceedings/89/sipcore I've included the summary below. Please note the action items! Thanks, Paul =================== Conclusions & Action Items =================== * Errata on 3325: Conclusion: No objection to interpretation given by chairs. Action: Agree to clarify that it is allowed, but not required, to interpret these characters when not enclosed in <>. * draft-johansson-dispatch-dane-sip: Conclusion: Few present understood the issue. Many were confused. Action: Olle to send use cases to the list. * draft-yusef-sipcore-digest-scheme: Conclusion: Don't fix Digest, fix Authentication Action: Those who think fixing digest is insufficient should send use cases to the sipcore mailing list. * draft-johansson-sip-dual-stack Action: split the action item into two: one for the DNS part, and another for the remainder of Happy Eyeballs. Discuss the milestone text on the list. Action: call for adoption of draft-johansson-dispatch-dane-sip on the list for the DNS part. * RFC 6665 Dialog Re-Use with REFER Conclusion: Much objection to need for GRUU to solve this problem. Action: Robert Sparks and Adam Roach to write a new draft updating RFC3515 (REFER) for consistency with RFC6665. Action: Continue discussion on list. (Especially those who object to described approach.) From nobody Sat Mar 22 00:33:19 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B945A1A0746 for ; Sat, 22 Mar 2014 00:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z5dHy7EYKXHn for ; Sat, 22 Mar 2014 00:33:15 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id C76D11A0083 for ; Sat, 22 Mar 2014 00:33:12 -0700 (PDT) Received: from [192.168.40.10] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 1B0D993C1AF; Sat, 22 Mar 2014 07:32:56 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: "Olle E. Johansson" In-Reply-To: <532CB0FC.7010306@alum.mit.edu> Date: Sat, 22 Mar 2014 08:33:02 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <532CB0FC.7010306@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/ELwW2tnbYcGmmjVPo72jjsz7ZhQ Cc: SIPCORE , Olle E Johansson Subject: Re: [sipcore] SIPCORE Minutes, IETF89, March 2014 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Mar 2014 07:33:17 -0000 On 21 Mar 2014, at 22:37, Paul Kyzivat wrote: > The raw notes from the SIPCORE sessions, along with a summary of = conclusions and action items have been posted for the IETF89 = proceedings. You can find them at: >=20 > https://datatracker.ietf.org/secr/proceedings/89/sipcore >=20 > I've included the summary below. Please note the action items! >=20 > Thanks, > Paul >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Conclusions = & Action Items =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > * Errata on 3325: >=20 > Conclusion: No objection to interpretation given by chairs. >=20 > Action: Agree to clarify that it is allowed, but not required, to = interpret these characters when not enclosed in <>. >=20 > * draft-johansson-dispatch-dane-sip: >=20 > Conclusion: Few present understood the issue. Many were confused. >=20 > Action: Olle to send use cases to the list. I don't think the confusion was about use cases at all or whether we = need DANE or not - it was about whether the DANE group documents was = enough, if this is just a bump in the TLS stack or if we actually need to do = something in SIPcore. Some people claimed we need to do zero, nothing, nada. Some people (including me) claims we = do need to document this, especially since the SIP Domain certificate RFC is an update to RFC 3261 = and DANE usage changes the certificate contents. The DANE group is very clear that we do need to document our usage. Wes = Hardaker pointed that out several times during the discussion. It's documented in the DANE SRV = drafts too. >=20 > * draft-yusef-sipcore-digest-scheme: >=20 > Conclusion: Don't fix Digest, fix Authentication >=20 > Action: Those who think fixing digest is insufficient should send use = cases to the sipcore mailing list. >=20 > * draft-johansson-sip-dual-stack >=20 > Action: split the action item into two: one for the DNS part, and = another for the remainder of Happy Eyeballs. Discuss the milestone text = on the list. >=20 > Action: call for adoption of draft-johansson-dispatch-dane-sip on the = list for the DNS part. Our draft only includes the DNS part so the full draft can be adopted as = is. THere's no draft covering the Happy Eyeballs part yet. /O >=20 > * RFC 6665 Dialog Re-Use with REFER >=20 > Conclusion: Much objection to need for GRUU to solve this problem. >=20 > Action: Robert Sparks and Adam Roach to write a new draft updating = RFC3515 (REFER) for consistency with RFC6665. > Action: Continue discussion on list. (Especially those who object to = described approach.) >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Sat Mar 22 02:14:14 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA6DC1A0934 for ; Sat, 22 Mar 2014 02:14:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQhgIUkeE06l for ; Sat, 22 Mar 2014 02:14:11 -0700 (PDT) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 35A091A039D for ; Sat, 22 Mar 2014 02:14:10 -0700 (PDT) X-AuditID: c1b4fb32-b7f4c8e0000012f5-25-532d54583aab Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id F5.35.04853.8545D235; Sat, 22 Mar 2014 10:14:00 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.213]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0387.000; Sat, 22 Mar 2014 10:13:59 +0100 From: Christer Holmberg To: Paul Kyzivat Thread-Topic: [sipcore] SIPCORE Minutes, IETF89, March 2014 - RFC 6665 Dialog Re-Use with REFER Thread-Index: Ac9Frr0SResGn9r+Qrio5EzTCgJZRw== Date: Sat, 22 Mar 2014 09:13:59 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D25AC86@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrELMWRmVeSWpSXmKPExsUyM+JvjW5EiG6wwdothhYrNhxgtfj6YxOb A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJWxdfYFloIZHBU/LsxhamA8xNbFyMkhIWAi MfHsShYIW0ziwr31YHEhgROMEm/fOEDYSxglPv2o6mLk4GATsJDo/qcNYooIaEhM2qoGUsEs ICdx/cNGsE5hgQSJ57/+MoHYIgKJEsdmH2aHsPUk7t9fwwjSyiKgKnH9lz9ImFfAV2LuzH2M IDYj0AHfT61hghgpLnHryXwmiMMEJJbsOc8MYYtKvHz8jxXCVpJYe3g7C0S9jsSC3Z/YIGxt iWULXzNDzBeUODnzCcsERpFZSMbOQtIyC0nLLCQtCxhZVjFKFqcWF+emGxno5abnluilFmUm Fxfn5+kVp25iBMbDwS2/jXYwntxjf4hRmoNFSZz3OmtNkJBAemJJanZqakFqUXxRaU5q8SFG Jg5OqQZGnis6tlO9WtnFbTyPcHIp6n/3fdcT3vrX8WPtp7CYyNmyzvm6m/3+vc+0XXog16Om acsCvnmsm2X0//O6PM87tLD/retxDpHb6R8umAsU3LNYm/tXaHXfzjaDB07bjlx6yunp3ZJv /S+RI2J3UMWDdGG+x/YCi06efs1l9kU8TEjLOXPOkhglluKMREMt5qLiRADRFcsPVQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/XU4x52-IN0FswNygvKlguaxwgZY Cc: SIPCORE Subject: Re: [sipcore] SIPCORE Minutes, IETF89, March 2014 - RFC 6665 Dialog Re-Use with REFER X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Mar 2014 09:14:13 -0000 Hi, > * RFC 6665 Dialog Re-Use with REFER >=20 > Conclusion: Much objection to need for GRUU to solve this problem. >=20 > Action: Robert Sparks and Adam Roach to write a new draft updating RFC351= 5 (REFER) for consistency with RFC6665. > Action: Continue discussion on list. (Especially those who object to=20 > described approach.) I realize this is supposed to be a summary, but I think some parts are miss= ing. First, I am not sure what is meant by "need for GRUU to solve this problems= ".=20 Eventhough GRUU, and whether 3515 needs to be updated, was discussed, the o= ther part of the discussion was not so much about GRUU - it was more about = usage of in-dialog REFERs when the sender "knows" that receiver will use no= refersub.=20 Related to that, I think it would be good to mention that there were sugges= tions about deprecating implicit registrations all together, and defining a= new nofersub-must-support-AND-use option-tag, but that no conclusions were= made. Thanks! Regards, Christer From nobody Sat Mar 22 08:51:34 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A45181A09A5 for ; Sat, 22 Mar 2014 08:51:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.511 X-Spam-Level: X-Spam-Status: No, score=-1.511 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ticw1titZfWN for ; Sat, 22 Mar 2014 08:51:31 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 15E7D1A099A for ; Sat, 22 Mar 2014 08:51:31 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s2MFpLXi031315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 22 Mar 2014 15:51:22 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s2MFpJaS026245 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 22 Mar 2014 15:51:19 GMT Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s2MFpJ66026238; Sat, 22 Mar 2014 15:51:19 GMT Received: from [10.0.1.12] (/66.31.4.61) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 22 Mar 2014 08:51:18 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Hadriel Kaplan In-Reply-To: <201403211819.s2LIJs6x006669@hobgoblin.ariadne.com> Date: Sat, 22 Mar 2014 11:51:17 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5320C5CC.7040806@alum.mit.edu> <201403201917.s2KJHMon023792@hobgoblin.ariadne.com> <6F93E9EE-B2F6-4D17-99D3-070CD7321FC7@oracle.com> <201403211819.s2LIJs6x006669@hobgoblin.ariadne.com> To: "Dale R. Worley" X-Mailer: Apple Mail (2.1874) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/ZSSU0Fcw9S_JoChWYprKOhOLK1M Cc: sipcore@ietf.org Subject: Re: [sipcore] Problems with GRUUs (was: Comments on draft-allen-dispatch-routing-out-of-dialog-request-00) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Mar 2014 15:51:32 -0000 On Mar 21, 2014, at 2:19 PM, Dale R. Worley wrote: >> From: Hadriel Kaplan >>=20 >>> When we label a URI as a GRUU, the needed property is that it is >>> globally routed *within the garden within which the GRUU exists*. >>=20 >> Then GRUUs serve no practical purpose, because the above definition >> is what just any plane-Jane RFC 3261 Contact URI already >> accomplishes. The whole *point* of defining the GRUU mechanism was >> to have a Contact URI which could be used to reach a specific >> endpoint from *anywhere*. Right? >>=20 >> If we're going to constrain the scope of what "anywhere" means, to >> boil down to: "so long as we can talk to each other", then we've >> done nothing but added a 'gr' param to a URI, afaict. >>=20 >> Or am I misunderstanding you? >=20 > You're misunderstanding me, but the distinction is tricky, and it's > possible that I haven't forumulated it with sufficient accuracy. >=20 > The critical point of a GRUU is that *if an entity can see that URI* > then *that entity can use it for contacting that UA*. OK, I'm following you now I think. I think the difference is just that: = such a GRUU contact could be used instead of an AoR target, whereas a = 3261 Contact couldn't (safely) be used as an AoR target. (ie, in = out-of-dialog requests) Yes? > Functionally, the point is that SBCs have to be aware, for each > network segment that it is connected to, whether GRUU URIs for its > domain are valid there, and censor (or otherwise revise) GRUUs that > would otherwise be propagated into segments they are not valid for. That's not very practical. It requires the admin to know things which = they are unlikely to know, or to know accurately enough to be safe and = not cause problems in scenarios they did not foresee. And it's not just = SBCs - we're talking basically all B2BUAs. -hadriel From nobody Sat Mar 22 09:24:54 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEC371A09B5 for ; Sat, 22 Mar 2014 09:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lo94WaYMcZGb for ; Sat, 22 Mar 2014 09:24:51 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id B256B1A09C2 for ; Sat, 22 Mar 2014 09:24:51 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s2MGOgNW020639 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 22 Mar 2014 16:24:43 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s2MGOfJI009300 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 22 Mar 2014 16:24:42 GMT Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s2MGOfRF009296; Sat, 22 Mar 2014 16:24:41 GMT Received: from [10.0.1.12] (/66.31.4.61) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 22 Mar 2014 09:24:41 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Hadriel Kaplan In-Reply-To: <201403211931.s2LJVs4B010647@hobgoblin.ariadne.com> Date: Sat, 22 Mar 2014 12:24:39 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5320C5CC.7040806@alum.mit.edu> <5320E329.5000209@alum.mit.edu> <430D6703-6B3A-4E23-AC66-53B1DE68EAE9@oracle.com> <201403211931.s2LJVs4B010647@hobgoblin.ariadne.com> To: "Dale R. Worley" X-Mailer: Apple Mail (2.1874) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/YiGK9U65dc7h_hD26RGUR6J5-1s Cc: sipcore@ietf.org Subject: Re: [sipcore] [dispatch] Comments on draft-allen-dispatch-routing-out-of-dialog-request-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Mar 2014 16:24:53 -0000 On Mar 21, 2014, at 3:31 PM, Dale R. Worley wrote: > [moved from Dispatch] >=20 >> From: Hadriel Kaplan >=20 >> There is no problem I know of, so long as you do NOT use GRUUs, or >> ignore the 'gr' param and just behave like they're normal contact >> URIs. >=20 > I'm curious what you mean by "just behave like they're normal contact > URIs". My understanding is that the contact URI is used for whatever > it's used for *because* it's the contact URI. If it's marked as a > GRUU, that presumably is a hint that your odds of success are higher, > but what would you do differently? You would send out-of-dialog REFERs, and you could (in theory) store the = GRUU for future use indefinitely, such as in an address book. > In your draft, you also write: >=20 > Instead, a logically similar model has been successfully deployed=20 > using "Global Contacts", which are Contact URIs having the=20 > properties of a GRUU, but not being a GRUU in syntax (i.e., without=20= > a 'gr' param, and not indicating an AoR). This has the benefit that=20= > downstream B2BUAs/UAs will not treat the Contact as a special GRUU=20= > case. Global Contacts are not always valid after their dialog is=20 > terminated, but it remains to be seen if this will cause problems in=20= > the future. Currently the main use-case for GRUU-like properties is=20= > for call-transfer scenarios, for which dialog lifetime is=20 > sufficient.=20 >=20 > Could you give us some detail as to what a "global contact" is and how > it works? It's just a Contact URI that encodes information in itself such that = it's uniquely related to the original Contact for the original dialog. So if an SBC gets a INVITE with a Contact URI of 'sip:alice@foo.com', = then the new Contact URI the SBC uses in its out-going INVITE could be = something like 'sip:akcjbaidch@sbc1.foo.com', whereas one from = 'sip:bob@foo.com' would produce 'sip:ucdhwbcu@sbc1.foo.com' or whatever. = (although it may not be a hostname, but an IP instead) The userinfo portion has sufficient information for the SBC to figure = out which original Contact URI to use as a target for an out-of-dialog = request (or to match to some internal dialog state). In other words = it's a way of minting a "garden-scoped" GRUU basically, but without = using a 'gr' param so downstream nodes don't behave differently than = before. -hadriel From nobody Sat Mar 22 09:29:54 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 890FA1A0769 for ; Sat, 22 Mar 2014 09:29:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.511 X-Spam-Level: X-Spam-Status: No, score=-1.511 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xDWihd1EclaE for ; Sat, 22 Mar 2014 09:29:51 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 39AF21A073F for ; Sat, 22 Mar 2014 09:29:51 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s2MGTnKd023716 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 22 Mar 2014 16:29:49 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s2MGTm32013271 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 22 Mar 2014 16:29:49 GMT Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s2MGTmP1013262; Sat, 22 Mar 2014 16:29:48 GMT Received: from [10.0.1.12] (/66.31.4.61) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 22 Mar 2014 09:29:48 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Hadriel Kaplan In-Reply-To: <532C9C3C.9080200@alum.mit.edu> Date: Sat, 22 Mar 2014 12:29:46 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5320C5CC.7040806@alum.mit.edu> <201403201917.s2KJHMon023792@hobgoblin.ariadne.com> <532C9C3C.9080200@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1874) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/EC9SH22nfIAZd6_K_JfLucSqrIg Cc: sipcore@ietf.org Subject: Re: [sipcore] Problems with GRUUs X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Mar 2014 16:29:52 -0000 On Mar 21, 2014, at 4:08 PM, Paul Kyzivat wrote: > I see two distinct issues here: >=20 > - uniqueness of addresses (both DNS and IP) > - reachability >=20 > IMO, when we are talking about gruus, what we are really talking about = is primarily global uniqueness. The registrar-provided gruus are = intended to *help* with this for devices behind NATs, so that they can = get a globally unique address. >=20 > Even with globally unique addresses there is no guarantee of = reachability. Some devices may have a policy about who may reach them, = and how. If their globally reachable address is used some other way they = may block the request. And they may utilize intermediaries to help them = enforce the policy. I don't think SIP considers such behavior wrong. >=20 > But, if UA-B intends that it be possible for UA-A to be able to send = out-of-dialog requests to it, then when it provides a contact address, = it should provide one that will *work* for UA-A to reach UA-B = out-of-dialog. This should be part of the sip contract, and GRUU is an = assistance to achieving that. And how could UA-B possibly know whether a URI it provides is usable by = UA-A?? We're talking machines, not God. :) Even UA-B's Registrar, and the human operator of UA-B's domain, don't = actually know whether UA-A can use it if UA-A isn't in their domain. -hadriel From nobody Sat Mar 22 14:16:41 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F1B41A0A08 for ; Sat, 22 Mar 2014 14:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K6LXnouBf9r9 for ; Sat, 22 Mar 2014 14:16:38 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 0C5671A0A06 for ; Sat, 22 Mar 2014 14:16:37 -0700 (PDT) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta03.westchester.pa.mail.comcast.net with comcast id gl5Z1n0050ldTLk53lGdRD; Sat, 22 Mar 2014 21:16:37 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta04.westchester.pa.mail.comcast.net with comcast id glGd1n00Z3ZTu2S01lGdsC; Sat, 22 Mar 2014 21:16:37 +0000 Message-ID: <532DFDB5.3080506@alum.mit.edu> Date: Sat, 22 Mar 2014 17:16:37 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Hadriel Kaplan References: <5320C5CC.7040806@alum.mit.edu> <201403201917.s2KJHMon023792@hobgoblin.ariadne.com> <532C9C3C.9080200@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1395522997; bh=PxPncA0qUukP9/N7uPXYoj0iqPIBUg0n/y0mfaOaboE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=D+KTG+Su4H3Mgp9KAoqumoTIKR83yjeCxPpBqfJ+WIaXm0z0CjXv5cofn+zhc4zDB 9k31oEE4upBAZQlXSdrvdtuGN/LuOcrdBOlb7iDauU7h75XyY+ye1VAuqymgEfoMZC tDZUBjJzPbmpx/yllWSgqDfkyiQQgcb9v2svtpQXi5qMjG2lpZBlZsDlk8pUerhREt UFPUpju7ZJ5x1aF9Bz0da8LeZftZqjAXKdpm2ueBwUYox3JnBjUTKpZ9Y9SGxi9tET eT0AVb54uIYaTeS3wAmTKBlnUAcikEvqsOz74389AJC3il8juJHeGgYnlPORD1PDzE l4DT5DC8Y4CVw== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/O2BAvwwUfWcm9LXaSdSMAOuJzn0 Cc: sipcore@ietf.org Subject: Re: [sipcore] Problems with GRUUs X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Mar 2014 21:16:39 -0000 On 3/22/14 12:29 PM, Hadriel Kaplan wrote: > > On Mar 21, 2014, at 4:08 PM, Paul Kyzivat wrote: > >> I see two distinct issues here: >> >> - uniqueness of addresses (both DNS and IP) >> - reachability >> >> IMO, when we are talking about gruus, what we are really talking about is primarily global uniqueness. The registrar-provided gruus are intended to *help* with this for devices behind NATs, so that they can get a globally unique address. >> >> Even with globally unique addresses there is no guarantee of reachability. Some devices may have a policy about who may reach them, and how. If their globally reachable address is used some other way they may block the request. And they may utilize intermediaries to help them enforce the policy. I don't think SIP considers such behavior wrong. >> >> But, if UA-B intends that it be possible for UA-A to be able to send out-of-dialog requests to it, then when it provides a contact address, it should provide one that will *work* for UA-A to reach UA-B out-of-dialog. This should be part of the sip contract, and GRUU is an assistance to achieving that. > > And how could UA-B possibly know whether a URI it provides is usable by UA-A?? We're talking machines, not God. :) OK, maybe I didn't phrase that well. UA-B can't be expected to do anything special to deal with restrictions that may be imposed on UA- by virtue of UA-A's environment. What I meant was that UA-B needs to provide a contact that deals with any limitations imposed by UA-B's environment. IOW, UA-B should be handing out a contact that can be successfully used out of dialog by UA-A if UA-A resides directly on the public internet. > Even UA-B's Registrar, and the human operator of UA-B's domain, don't actually know whether UA-A can use it if UA-A isn't in their domain. If we have two UA's each in restricted domains/gardens, then each side should be doing the necessary fixups. And each doesn't need to do it directly - it can be delegated to other servers in its environment. AFAIK that *is* (more or less) the model that SBCs are aiming for. But apparently preserving global out-of-dialog routability isn't always being observed. IMO, saying "we only preserve in-dialog signaling" doesn't cut it. I expect your servers *can* do this, but it is up to operators to configure them properly to do so. If so, maybe it is more of an issue of operator training - e.g. BCPs. Thanks, Paul From nobody Sun Mar 23 12:58:35 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C110D1A09BF for ; Sun, 23 Mar 2014 12:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95L-EPm5a2uq for ; Sun, 23 Mar 2014 12:58:31 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id 920F41A09AE for ; Sun, 23 Mar 2014 12:58:31 -0700 (PDT) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta04.westchester.pa.mail.comcast.net with comcast id h6rJ1n0010mv7h0547yW7X; Sun, 23 Mar 2014 19:58:30 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta11.westchester.pa.mail.comcast.net with comcast id h7yW1n00H3ZTu2S3X7yW0r; Sun, 23 Mar 2014 19:58:30 +0000 Message-ID: <532F3CE6.1010301@alum.mit.edu> Date: Sun, 23 Mar 2014 15:58:30 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "Olle E. Johansson" References: <532CB0FC.7010306@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1395604710; bh=vMyMktKY3gMaFkDZ5ul0Y+tHeEhJ7IKrd6eWvUZKyOo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=RwzrRGHFgmWr/tysCdR718AmKJxWb2ME9jkghqL1W96r1pWluJG9jretye5eh6N4P P6q7qeqfn7b2NwgXNzVJetlOmxt/pNCpAEvjEKlD4t4+KkkDQtK4Tq0CD32b9WM6Sk sJfjy2Vm8obqKwlX0BAFmeBgqGZGtUaq5Ax9pG0k9vjkJUiHCRL7Bia1leuG7mIjoY SZ2DU+BLTaG0sLkWMuC8iajTC23pQ44CVpJakOMwMbovdNW+TGoZGz0koazQgqBcXw SKMK6b74ndPJQcJecMMVsHp5N6m2/xLXe5ZDL2vXmKC2uK8kj6o2k0IUafriJdJ66F QeYA6VRDEuoCg== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/9DVJbcBNHyWwzGGKky9KMlTHBq8 Cc: SIPCORE Subject: [sipcore] Actions for DANE SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2014 19:58:33 -0000 On 3/22/14 3:33 AM, Olle E. Johansson wrote: >> * draft-johansson-dispatch-dane-sip: >> >> Conclusion: Few present understood the issue. Many were confused. >> >> Action: Olle to send use cases to the list. > I don't think the confusion was about use cases at all or whether we need DANE or not - it was about whether the DANE group documents was enough, > if this is just a bump in the TLS stack or if we actually need to do something in SIPcore. Some people claimed > we need to do zero, nothing, nada. Some people (including me) claims we do need to document this, > especially since the SIP Domain certificate RFC is an update to RFC 3261 and DANE usage changes > the certificate contents. > > The DANE group is very clear that we do need to document our usage. Wes Hardaker pointed that out > several times during the discussion. It's documented in the DANE SRV drafts too. OK. Maybe "use cases" isn't a proper characterization of what we need. But clearly we have a problem around lack of understanding. And it isn't entirely clear exactly *what* people lack an understanding of. My guess is that we have people with a range of understandings of DANE. And so a range of understandings of what we need to do. IMO the starting point is to clarify why DANE is important to SIP. I see a couple of reasons, neither specific to sip, but relevant to sip: - reliance on DNSSEC is more trustworthy than reliance on CAs - server certificates are more easily managed than domain certs I think your draft would benefit by having a section specifically addressing this. But it might be helpful to have some list discussion on it before you update the draft. Once we get past "why DANE?", we then get to "what do we need to do before we can use DANE with sip?" Your draft addresses that, but obviously some people disagree on how much needs to be specified, and how much can be had by reference to existing generic documents. I doubt that big changes are needed in what you have already for this, but maybe it can be clarified to address the concerns that were raised - to make it crystal clear. Referencing the the explicit places where the generic DANE documents say that we must document the sip-specific usage would help here. Does this match your understanding of what happened? If so, I'll tweak the actions to agree. Thanks, Paul From nobody Tue Mar 25 08:41:55 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6D051A01B1; Tue, 25 Mar 2014 08:41:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FHDaj3ze_6mF; Tue, 25 Mar 2014 08:41:27 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 017D81A019F; Tue, 25 Mar 2014 08:41:26 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id bs8so3556487wib.3 for ; Tue, 25 Mar 2014 08:41:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=//M9RLOYx/v1jPDy/ssGXtOZTUi1Ni/eAedx14SBSaw=; b=wvFXhLPCoB7rq3LwadmBTw042n0u8/qsR4vRhNXoxBM214CD10hshzO2TULe3FzAck /16kQ0plNyDEKW/5grtgV6ZlAKnjyIZLPekcLVhERVSTIPdduc798aMni0mVe4qeHE4u r73KKdkE4fUXqJnCFoAe2XnPkKPn4XYI/G6aGgquwMDXhQzm6/eJvjUi6x8nvBSYp/lk QdV0tcl7vGHke+ofPU3s5npmObpWh+3pnV2ATXiHM6sX9colrY9yw2pUQBwqpYcKFnvT KXDjp//Ghk0wlaFeNr25vcExbgIO5lALDTXrFaFCGVnVL3WPFjnrDgdHSoI6ZSFa+5zA jAWQ== MIME-Version: 1.0 X-Received: by 10.180.20.176 with SMTP id o16mr24063111wie.7.1395762085382; Tue, 25 Mar 2014 08:41:25 -0700 (PDT) Received: by 10.216.10.6 with HTTP; Tue, 25 Mar 2014 08:41:25 -0700 (PDT) Date: Tue, 25 Mar 2014 10:41:25 -0500 Message-ID: From: Mary Barnes To: "rai@ietf.org" Content-Type: multipart/alternative; boundary=bcaec53f35f54a501b04f5702fe4 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/c3OUDFlgmsfXRDQ_TC-M_v5Za5E Cc: DISPATCH , SIPCORE Subject: [sipcore] Passing of Francois Audet - Additional information X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 15:41:31 -0000 --bcaec53f35f54a501b04f5702fe4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all, I have some additional information to share that I thought would be of interest to a number of people. 1) There have been some queries as to specifically how one can help the family directly. A Special Needs Trust has been established for Francois' son, Olivier. This fund will be used to offset the costs of Olivier's treatments that aren't covered by medical insurance or other funding. If you are interested in making a donation to this fund, please contact me directly for further details. 2) The funeral is scheduled as follows: Saturday, April 5 at 14:00 hours, at the funeral Cooperative in the Outaouais, 95 boulevard Cit=E9-des-Jeunes, Gatineau (QC) J8Y 6 X 3 3) If you have any photos of Francois from meetings, etc, can you please forward those to me? I am putting together a scrapbook for Olivier. Also, if you want to include a personal note, please send that. Thanks for all your support, Mary. On Mon, Mar 17, 2014 at 10:56 AM, Mary Barnes w= rote: > A number of you all will remember Francois Audet, who was a colleague of > mine at Nortel and a regular IETF attendee (until he went to Skype ;) He > was a co-author on the recently published 4244bis drafts. He unfortunate= ly > lost his battle with cancer on Friday. I have received the following > information from a family friend via Facebook: > > Thanks for all your support messages, both on & offline. > I've talked to Genevi=E8ve over the week-end, and she reminded me that th= ere > is just no real treatment of Brain Tumors, and that form of cancer is > growing at some alarming rate. > She agreed that the best support message would be to sponsor the research= , > for which donations can be made as a memorial gift for Francois Audet. > I've selected a few organizations: > - Stanford Brain Tumor Center (http://medicalgiving.stanford.edu/, this > is where Fran=E7ois was treated. Make sure to indicate the Brain Tumor Ce= nter > as the recipient). > - UCSF Brain Tumor Center ( > https://makeagift.ucsf.edu/site/SPageServer?pagename=3DA1_API_GordonMurra= yGivingForm&ACode=3DB2934 > ) > - National Brain Tumor Society (http://www.braintumor.org/) > > Note that he also left behind a son, Olivier. > > That's all the information I have at this point. > > Regards, > Mary. > --bcaec53f35f54a501b04f5702fe4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,

I have some additional informat= ion to share that I thought would be of interest to a number of people.

1) There have been some queries as to specifically ho= w one can help the family directly. =A0A Special Needs Trust has been estab= lished for Francois' son, Olivier. This fund will be used to offset the= costs of Olivier's treatments that aren't covered by medical insur= ance or other funding. =A0If you are interested in making a donation to thi= s fund, please contact me directly for further details.

2) The funeral is scheduled as follows:
Saturd= ay, April 5 at 14:00 hours, at the funeral Cooperative in the Outaouais, 95= boulevard Cit=E9-des-Jeunes, Gatineau (QC) J8Y 6 X 3

3) If you have any photos of Francois from meetin= gs, etc, can you please forward those to me? =A0I am putting together a scr= apbook for Olivier. Also, if you want to include a personal note, please se= nd that. =A0

Thanks for all your support,
Mary.=A0
=A0=A0


= On Mon, Mar 17, 2014 at 10:56 AM, Mary Barnes <mary.ietf.barnes@g= mail.com> wrote:
A number of you all will remember Francois Audet, who was a colleague of mi= ne at Nortel and a regular IETF attendee (until he went to Skype ;) =A0He w= as a co-author on the recently published 4244bis drafts. =A0He unfortunatel= y lost his battle with cancer on Friday. =A0I have received the following i= nformation from a family friend via Facebook:

Thanks for all your support messages, both on & off= line.
I've talked to Genevi=E8ve over the week-end, and she r= eminded me that there is just no real treatment of Brain Tumors, and that f= orm of cancer is growing at some alarming rate.
She agreed that the best support message would be to sponsor the resea= rch, for which donations can be made as a memorial gift for Francois Audet.=
I've selected a few organizations:
- Stanford Brai= n Tumor Center (http://medicalgiving.stanford.edu/, this is where Fran=E7ois was = treated. Make sure to indicate the Brain Tumor Center as the recipient).
- National Brain Tumor Society (http://www.braintumor.org/)

Note that he also left behind a son, Olivier.=A0

That's all the information I have at this point.=A0

Regards,
Mary.

--bcaec53f35f54a501b04f5702fe4-- From nobody Thu Mar 27 09:40:03 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C6531A06C3; Thu, 27 Mar 2014 09:40:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0j0lAGL5fKUb; Thu, 27 Mar 2014 09:39:58 -0700 (PDT) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 3700F1A0332; Thu, 27 Mar 2014 09:39:58 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id x48so1926035wes.38 for ; Thu, 27 Mar 2014 09:39:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=jlD4MlHfIkmEs5De+vypvdkY0WPg+pBwIjj6AMDh6ew=; b=GQhfJzpiBwE7gFslfoE2ydxHVo6qtYptiRGUbR1KTk0Mva/K1/sKzj3Fb1MGkCmnqC Hzw4jhT3b+SMNZWfOZDgUiDB9WDWJf6TvAWa/MZvyoV7ntmffeL/1Nm80yN3ERzE4Oz5 yvIJ9IzuweHWY5mW4wXvcGZxq98OgkPRzZVkunbVzK6n9YAbkRqw9iOaGAGfT+tz5DDX BkkyMmWp4HKlb5x1kEowiflRgsXfOHDGgu79ciGKpYpCMi/HB8QxBJzdDZiHE9D7F0te 93O/9+zNbcGrkWH2tcf6sNVuL0bxYggQi7aCNQpPUUFm4oKmDlcSTUTjyfbQqcRkxmPE 0jnQ== MIME-Version: 1.0 X-Received: by 10.180.20.176 with SMTP id o16mr40623910wie.7.1395938395440; Thu, 27 Mar 2014 09:39:55 -0700 (PDT) Received: by 10.216.10.6 with HTTP; Thu, 27 Mar 2014 09:39:55 -0700 (PDT) In-Reply-To: <532B2896.6090502@nostrum.com> References: <532B2896.6090502@nostrum.com> Date: Thu, 27 Mar 2014 11:39:55 -0500 Message-ID: From: Mary Barnes To: SIPCORE , DISPATCH Content-Type: multipart/alternative; boundary=bcaec53f35f5304c7904f5993cb7 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/4IaN146yl4UHsdtsV20Duf6R-Eo Subject: [sipcore] Fwd: [RAI] SIPit 31 registration is open X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 16:40:01 -0000 --bcaec53f35f5304c7904f5993cb7 Content-Type: text/plain; charset=ISO-8859-1 I didn't see this hit either SIPCORE or DISPATCH WG mailing lists and I know that the RAI mailing list has far fewer subscribers than these other two lists. Obviously, don't reply to this message on these other lists. ---------- Forwarded message ---------- From: Robert Sparks Date: Thu, Mar 20, 2014 at 12:42 PM Subject: [RAI] SIPit 31 registration is open To: rai@ietf.org SIPit 31 will be held in Nice, France Sep 28 - Oct 3, 2014. The event will be hosted by ETSI. More information, and the registration page, is available at Please take advantage of the opportunity to register early. In addition to the normal team-to-team testing at the event, we will be concentrating on several specific interoperability areas: * Nat and Firewall Traversal using Outbound, TURN, and STUN * RTCWeb * Advanced Video scenarios * Use of TLS and DTLS If you're planning to attend and have other areas you would like have a multi-team focus session around, please let me know. RjS _______________________________________________ RAI mailing list RAI@ietf.org https://www.ietf.org/mailman/listinfo/rai --bcaec53f35f5304c7904f5993cb7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I didn't see this hit either SIPCORE or DISPATCH WG ma= iling lists and I know that the RAI mailing list has far fewer subscribers = than these other two lists.

Obviously, don't reply t= o this message on these other lists.=A0

---------- Forwarded message ----------
F= rom: Robert Sparks <= rjsparks@nostrum.com>=
Date: Thu, Mar 20, 2014 at 12:42 PM
Subject: [RAI] SIPit 31 registration= is open
To: rai@ietf.org

SIPit 31 will be held in Nice, France Sep 28 - Oct 3, 2014.
The event will be hosted by ETSI.

More information, and the registration page, =A0is available at
<http://www.etsi.org/news-events/events/750-sipit-31&= gt;
Please take advantage of the opportunity to register early.

In addition to the normal team-to-team testing at the event,
we will be concentrating on several specific interoperability areas:
* Nat and Firewall Traversal using Outbound, TURN, and STUN
* RTCWeb
* Advanced Video scenarios
* Use of TLS and DTLS

If you're planning to attend and have other areas you would like
have a multi-team focus session around, please let me know.

RjS

_______________________________________________
RAI mailing list
RAI@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/rai

--bcaec53f35f5304c7904f5993cb7-- From nobody Mon Mar 31 12:13:25 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E9641A6F63 for ; Mon, 31 Mar 2014 12:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1cWqxd-mnVbD for ; Mon, 31 Mar 2014 12:13:12 -0700 (PDT) Received: from qmta11.emeryville.ca.mail.comcast.net (qmta11.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:211]) by ietfa.amsl.com (Postfix) with ESMTP id DA5501A6F11 for ; Mon, 31 Mar 2014 12:13:12 -0700 (PDT) Received: from omta11.emeryville.ca.mail.comcast.net ([76.96.30.36]) by qmta11.emeryville.ca.mail.comcast.net with comcast id kGcn1n0030mlR8UABKD9y2; Mon, 31 Mar 2014 19:13:09 +0000 Received: from hobgoblin.ariadne.com ([174.61.171.170]) by omta11.emeryville.ca.mail.comcast.net with comcast id kKCo1n0023gwEm68XKCtzr; Mon, 31 Mar 2014 19:13:09 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s2VJC6M3017441 for ; Mon, 31 Mar 2014 15:12:32 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s2VJC6E2017435; Mon, 31 Mar 2014 15:12:06 -0400 Date: Mon, 31 Mar 2014 15:12:06 -0400 Message-Id: <201403311912.s2VJC6E2017435@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: sipcore@ietf.org In-reply-to: <7594FB04B1934943A5C02806D1A2204B1D215FD7@ESESSMB209.ericsson.se> (christer.holmberg@ericsson.com) References: <5320C5CC.7040806@alum.mit.edu> <5320E329.5000209@alum.mit.edu> <430D6703-6B3A-4E23-AC66-53B1DE68EAE9@oracle.com> <5321C834.9000309@alum.mit.edu> <48BAD8BC-14D6-4338-A3CF-FEF74370C4B9@oracle.com> <5323548D.3060407@alum.mit.edu>, <00C069FD01E0324C9FFCADF539701DB3BBF41FC5@sc9-ex2k10mb1.corp.yaanatech.com> <7594FB04B1934943A5C02806D1A2204B1D215FD7@ESESSMB209.ericsson.se> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1396293189; bh=e0z/x7h0fMS3izisK51TatMhjUTnIk5qAamzoW9RXTM=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=YUo9m+mCxencQ5WYBE3IhrkNStjsuwnBC2K0sYYVtT+06qx5BBQaGC98zn4TGNApz mB8GmHRDw8I3Y0DPkMEcZ0d09GvXfxOZpWJdYhQ19jVA7dXfGyRl6GAVQO0OdrYQOj P+GTwhNmDXoduR/VqRx1RoZhxmgr1Gfx0762VS3fzS4KJi4VrOC6WP63B9iKzTzDzn 3bxs+xJ0w00j4rbXnHWF97mSCz62k7Ue8TLp6zFaQCd01FJSNjMx3ZFIwhEssmAH7Y HOLTktGstm3BGXaZgtM/4VFx6ne82IYROhivS8Qvlr1gar1nYs5WnM9XgtHj2zp5k1 oOtgf+7AM9Q2A== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/G_z0yUBYR4ZAY5ig4Bc2xrb2oxM Subject: Re: [sipcore] [dispatch] Comments on draft-allen-dispatch-routing-out-of-dialog-request-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 19:13:19 -0000 > On Mar 13, 2014, at 11:01 AM, Paul Kyzivat wrote: > The problem is when call flows break even when all the participants are > legitimate - when the providers are creating a walled garden that only works > for the specific call flows they have anticipated and made specific > provision for. That breaks innovation, and drives things like webrtc. > On 3/13/14 2:10 PM, Hadriel Kaplan wrote: > > You realize the irony in that last statement right? Webrtc is > by-definition a walled-garden. :) Hmmm, I read that as "when the providers are creating a walled garden that only works for the specific call flows they have anticipated and made specific provision for. That [sort of thinking] drives things like webrtc." > From: Michael Hammer > > The real irony would be if the WebRTC servers interconnected to each other > using a widely-available IMS and thereby become more open. > > One walled-garden turning the other walled-garden inside out. :) > From: Christer Holmberg > > Well, your dream is about to become true, as 3GPP is currently > defining WebRTC access to IMS :) OK, *now* my head is starting to hurt! Dale From nobody Mon Mar 31 12:36:26 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 460561A6FC6 for ; Mon, 31 Mar 2014 12:36:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gvt_BqYxmG6V for ; Mon, 31 Mar 2014 12:36:22 -0700 (PDT) Received: from qmta08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:80]) by ietfa.amsl.com (Postfix) with ESMTP id 3CF811A6FC1 for ; Mon, 31 Mar 2014 12:36:22 -0700 (PDT) Received: from omta16.emeryville.ca.mail.comcast.net ([76.96.30.72]) by qmta08.emeryville.ca.mail.comcast.net with comcast id kFeY1n0041ZMdJ4A8KcKdp; Mon, 31 Mar 2014 19:36:19 +0000 Received: from hobgoblin.ariadne.com ([174.61.171.170]) by omta16.emeryville.ca.mail.comcast.net with comcast id kKbx1n00T3gwEm68cKc3oC; Mon, 31 Mar 2014 19:36:18 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s2VJZ6g8020021; Mon, 31 Mar 2014 15:35:31 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s2VJZ5Z2020020; Mon, 31 Mar 2014 15:35:05 -0400 Date: Mon, 31 Mar 2014 15:35:05 -0400 Message-Id: <201403311935.s2VJZ5Z2020020@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Christer Holmberg In-reply-to: <7594FB04B1934943A5C02806D1A2204B1D25660B@ESESSMB209.ericsson.se> (christer.holmberg@ericsson.com) References: <5320C5CC.7040806@alum.mit.edu> <5320E329.5000209@alum.mit.edu> <430D6703-6B3A-4E23-AC66-53B1DE68EAE9@oracle.com> <5321C834.9000309@alum.mit.edu> <53234C1B.3020308@alum.mit.edu>, <58E29237-C56F-4312-B2DD-EDE3C2842081@oracle.com> <7594FB04B1934943A5C02806D1A2204B1D215FBC@ESESSMB209.ericsson.se> <0956401D-93D6-4253-B05E-8898A36112C5@oracle.com> <532704FD.1030603@alum.mit.edu> <201403192143.s2JLh6FF012885@hobgoblin.ariadne.com>, <532B1655.2050002@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D25660B@ESESSMB209.ericsson.se> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1396294579; bh=ZSQgmJ2U4q61Ef6fZGy3SAo8IbUBlERbNDVjxjdJVXU=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=dWVyNC+xeRZ99Qx4YZWOLHTfWMvPf2ujlvHpVN5eC4HV7q5uw/5hKbA/JbA6+UNX9 xC5ci5Qa9DYVafTPB9eZ9tNEc5YueoYQW8nngVGLiGXS16MnirYtezGzB3bxrEUsbq rQolMCxZyHnJ+r7bUUklVGKW1aSrOqOQrhnLGoTTUR7h5dkqHBYfWnUIwUJkwMBqpW NxRuGpblolUlt2LT7cU7bE8ONnYnIFUEfWauozBRoS8jbJNHfMpYXcPLf8gRYYdaAZ gsqh0EtjN+12W61TTwE9mYhHWyGnEnwJofS6Qojg6NxoaCxsm27BaZpMBx56bAM/Ow LJ4S3stqIOwaQ== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/eN9L2hvAPtRTireOR8BogoijAJY Cc: sipcore@ietf.org Subject: Re: [sipcore] [dispatch] draft-allen-dispatch-routing-out-of-dialog-request-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 19:36:24 -0000 > From: Christer Holmberg > > If the [deliverable] would be an SBC BCP document, I guess it could also > be done in STRAW. It makes sense to me that to the degree that the conclusion/consensus is recommendations about SBC procedures, we should coordinate with STRAW, or transfer the work entirely to STRAW. (Are there any members of the STRAW mailing list who aren't members of the SIPCORE mailing list?) Dale