From nobody Thu Sep 1 01:54:07 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3F8B12D877 for ; Thu, 1 Sep 2016 01:54:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 WlXdA1gXfypU for ; Thu, 1 Sep 2016 01:54:03 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86FDD12D892 for ; Thu, 1 Sep 2016 01:53:59 -0700 (PDT) X-AuditID: c1b4fb30-ea88e980000009f9-0b-57c7eca5cc80 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by (Symantec Mail Security) with SMTP id 7F.06.02553.5ACE7C75; Thu, 1 Sep 2016 10:53:57 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.211]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0301.000; Thu, 1 Sep 2016 10:53:56 +0200 From: Christer Holmberg To: "sipcore@ietf.org" Thread-Topic: AW: [sipcore] Using an INFO package in draft-ietf-ecrit-ecall-11 - Christer's compromise proposal Thread-Index: AQHSBC5ftgmMQ/YNK0CJFiBqGyMrZQ== Date: Thu, 1 Sep 2016 08:53:56 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="Windows-1252" Content-ID: <0FE30A3EF8BE24428860564ECDD8DF7E@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUyM2J7lO7SN8fDDR5/MbL4+mMTmwOjx5Il P5kCGKO4bFJSczLLUov07RK4Mo68VCzo5a14emgGUwPjFa4uRg4OCQETid2TdbsYuTiEBNYz Sux+380E4SxmlLjdfosZpIhNwEKi+592FyMnh4iApsTyb1vZQWxhgQKJTXcfsULECyWOvfzF BmHrSWw+vp0ZxGYRUJE4tWsHE4jNK2AlMeXVDrA4o4CYxPdTa8DizALiEreezAezJQQEJJbs Oc8MYYtKvHz8D2y+KNDM719nM0PcrCQxbWsaRKuBxPtz85khbGuJ5886WCFsbYllC18zQ6wV lDg58wnLBEaRWUi2zULSPgtJ+ywk7bOQtC9gZF3FKFqcWpyUm25kpJdalJlcXJyfp5eXWrKJ ERgNB7f8NtjB+PK54yFGAQ5GJR5eBenj4UKsiWXFlbmHGCU4mJVEeDe8BgrxpiRWVqUW5ccX leakFh9ilOZgURLn9X+pGC4kkJ5YkpqdmlqQWgSTZeLglGpgXLexaz5Hrt0Jm0CRx9fCumWO HhJQ9hJ8o+Xr9Oz1h8ndexa57EiamDR/qvhBnQQbt4KNncZ3crP9pr9w23Lzo7mcW+3BgIkz u+NTY9ZePq3cP9tWIZNLzvqOtuAlu++/JrM4x13MEsncdDeFPf9yyt3A56J394W91vMR/rrl 4Wrx9SobXOoSlViKMxINtZiLihMB+r0194ICAAA= Archived-At: Subject: Re: [sipcore] Using an INFO package in draft-ietf-ecrit-ecall-11 - Christer's compromise proposal X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 08:54:05 -0000 Hi, While I highly appreciate Dale=B9s input on the INFO issue, it seems like w= e won=B9t get much wider input from the SIPCORE community. So, in order to try to move forward, I would like to suggest a compromise proposal of my own. From a SIP message structure perspective it=B9s basically what Dale has suggested (and what I assumed was already stated in draft-ecall-11), but with a different approach when it comes to the documenting. First, the MSD is carried in an info package. Second, the main text in draft-ecall talks about using the info package mechanism for carrying the MSD in INFO. The main text does not talk about using the additional data mechanism. Third, and this is where my comprise proposal comes it, within the info package specification we add some text saying that while the semantics/context of the MSD MIME body is defined within the info package specification, in order to be aligned with the sending of MSD in non-INFO requests we use the content-disposition value reference-by and we include the Call-Info header field, as defined by Additional Data, in the INFO request. That way, we make it clear that we are using the info package mechanism for transporting MSD in INFO, but it still allows for usage of Call-Info in INFO.=20 Would people be ok with that? INFO example: Call-Info: ;purpose=3DemergencyCallData.eCall.MSD Content-Type: multipart/mixed;boundary=3D"theboundary" Content-Disposition: info-package --theboundary Content-Type: application/emergencyCallData.eCall.MSD+per Content-Dispostion: by-reference =8Btheboundary-- Regards, Christer From nobody Thu Sep 1 07:46:58 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6A6812D9DC for ; Thu, 1 Sep 2016 07:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 vskiu9G9PCz4 for ; Thu, 1 Sep 2016 07:46:55 -0700 (PDT) Received: from resqmta-ch2-02v.sys.comcast.net (resqmta-ch2-02v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92CDD12D5F9 for ; Thu, 1 Sep 2016 07:46:55 -0700 (PDT) Received: from resomta-ch2-02v.sys.comcast.net ([69.252.207.98]) by resqmta-ch2-02v.sys.comcast.net with SMTP id fTF3bPkfp0MKRfTGYbQGu5; Thu, 01 Sep 2016 14:46:54 +0000 Received: from hobgoblin.ariadne.com ([73.100.16.189]) by resomta-ch2-02v.sys.comcast.net with SMTP id fTGXbr0TYHQ26fTGYbcwLt; Thu, 01 Sep 2016 14:46:54 +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 u81EkrRW006926; Thu, 1 Sep 2016 10:46:53 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u81EkrmR006923; Thu, 1 Sep 2016 10:46:53 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Christer Holmberg In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BC7BD90@ESESSMB209.ericsson.se> (christer.holmberg@ericsson.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Thu, 01 Sep 2016 10:46:52 -0400 Message-ID: <87wpiv7k4j.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfGi8WxIuv39l3NPCLhCzcVnLN+z+TZsiA2STIIBQYc600V1/i+k4awKINkYHTwgtzQ71JW0Ax63nEVu1V/BPXhdnIPZdKrURK7pXZXv5KRPlrYnxQszc OKckb7Ua2Y8aHKkaI7Pb+og/BloSuH0NVwBtjdJJxgwwpt8RV8Q5V+emKHvGZK1E0hNvh8KiA6L5yDoRWJ7Irvum1/2VEndS9r2EJIxdriS7yA9Ggkc6zFLo Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] Using an INFO package in draft-ietf-ecrit-ecall-11 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 14:46:57 -0000 Christer Holmberg writes: > In general, if intermediaries are going to add content to INFO, and if > such information can only be added to specific INFO usages, the > intermediaries will have to look at the Info-Package header field (and > in some cases perhaps also look at the content) in order to figure out > what the INFO is all about. Yes, that must be the rule. But I don't see the particular rule stated in draft-ietf-ecrit-ecall-11, even though that draft introduces the mechanism for updating MSD, and thus updating Additional Data. RFC 7852 is also rather vague regarding which requests should have updated Additional Data added. Section 6.1 is generic: A URI to a block MAY be inserted in any SIP request or response method (most often INVITE or MESSAGE), using a Call-Info header field containing a 'purpose' value starting with 'EmergencyCallData', a dot ('.'), and the type of data available at the URI. but the examples seem to presuppose that it will only be done in INVITE requests. That processing seems to be expected to be bundled with all of the emergency-call-specific processing carriers already do for those INVITEs. > People want to use the Call-Info header field in INFO because it is > used in INVITE (and possibly other methods), but technically you don't > need it in order to get things to work if you are using an info > package. That's true. The only reason is to be consistent with how INVITEs are processed. Dale From nobody Thu Sep 1 08:12:35 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD84A12DA29 for ; Thu, 1 Sep 2016 08:12:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 QUKt9LtF4vBY for ; Thu, 1 Sep 2016 08:12:29 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28FF612DA0B for ; Thu, 1 Sep 2016 08:12:15 -0700 (PDT) X-AuditID: c1b4fb3a-0618b980000009bd-a1-57c8454e2035 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by (Symantec Mail Security) with SMTP id EC.03.02493.E4548C75; Thu, 1 Sep 2016 17:12:14 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.211]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0301.000; Thu, 1 Sep 2016 17:12:12 +0200 From: Christer Holmberg To: "Dale R. Worley" Thread-Topic: [sipcore] Using an INFO package in draft-ietf-ecrit-ecall-11 Thread-Index: AQHSBF+t+pjwWhmVIEetajd/MHhvMaBkvOSQ Date: Thu, 1 Sep 2016 15:12:12 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BC7F4A1@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4BC7BD90@ESESSMB209.ericsson.se> (christer.holmberg@ericsson.com) <87wpiv7k4j.fsf@hobgoblin.ariadne.com> In-Reply-To: <87wpiv7k4j.fsf@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.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyM2K7va6f64lwg20/lC2+/tjEZvHyRJkD k8fk/V+ZPZYs+ckUwBTFZZOSmpNZllqkb5fAlfG9p5mt4Chnxb5Tz1gbGI+ydzFyckgImEgs 2NHD0sXIxSEksJ5RYtrWKewQzmJGiXMfO9m6GDk42AQsJLr/aYOYIgKaEh0LckB6mYHMRzv3 MoGEhQU8JV6sLAAJiwh4Sdx+8ZAdwjaSeLzqPzOIzSKgIvHg9XNWkHJeAV+J+be0IRZNZ5TY 0jSFDaSGU8BYov1PNwuIzSggJvH91BomiFXiEreezGeCOFlAYsme88wQtqjEy8f/WCFsJYnG JU9YIep1JBbs/sQGYWtLLFv4GqyeV0BQ4uTMJywTGEVnIRk7C0nLLCQts5C0LGBkWcUoWpxa XJybbmSkl1qUmVxcnJ+nl5dasokRGCEHt/y22sF48LnjIUYBDkYlHt4EkxPhQqyJZcWVuYcY JTiYlUR47zoBhXhTEiurUovy44tKc1KLDzFKc7AoifP6v1QMFxJITyxJzU5NLUgtgskycXBK NTCqz7GP6Qu5z7moZZGRyI7dfY4HnBLOvhSM9TyxvvaDmdDs4kjrJ+cj7hyq2vtnp9jz8il3 971t/mH1WrZSjv/6Uf5fwj8teW+xcm9Rey3iIJOa9f38+395XvxLF3g0rV43u/faBi9h6bCz K3RNLpbvinaen338h5Nlm3lqUvlJlUyR0zIlqwSVWIozEg21mIuKEwHKx1vrjAIAAA== Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Using an INFO package in draft-ietf-ecrit-ecall-11 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 15:12:34 -0000 >> In general, if intermediaries are going to add content to INFO, and if=20 >> such information can only be added to specific INFO usages, the=20 >> intermediaries will have to look at the Info-Package header field (and=20 >> in some cases perhaps also look at the content) in order to figure out=20 >> what the INFO is all about. > > Yes, that must be the rule. But I don't see the particular rule stated i= n draft-ietf-ecrit-ecall-11, even though that draft introduces=20 > the mechanism for updating MSD, and thus updating Additional Data. There are no ecall requirements for intermediaries to insert any informatio= n. And, the MSD is sent from the endpoint, not from any intermediary. ... >> People want to use the Call-Info header field in INFO because it is=20 >> used in INVITE (and possibly other methods), but technically you don't=20 >> need it in order to get things to work if you are using an info=20 >> package. > > That's true. The only reason is to be consistent with how INVITEs are pr= ocessed. Yes.=20 But, I have proposed a compromise, where we would use an info package, but = still be able to insert Call-Info in the INFO request. Regards, Christer From nobody Thu Sep 1 08:52:14 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E89012D5D5 for ; Thu, 1 Sep 2016 08:52:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 VwMOPMHdANnG for ; Thu, 1 Sep 2016 08:52:07 -0700 (PDT) Received: from resqmta-po-03v.sys.comcast.net (resqmta-po-03v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5932512D548 for ; Thu, 1 Sep 2016 08:52:07 -0700 (PDT) Received: from resomta-po-03v.sys.comcast.net ([96.114.154.227]) by resqmta-po-03v.sys.comcast.net with SMTP id fUHLbxH1jzd8UfUHebMIhh; Thu, 01 Sep 2016 15:52:06 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-po-03v.sys.comcast.net with SMTP id fUHdbpBiZ6ohdfUHdbFcV4; Thu, 01 Sep 2016 15:52:05 +0000 To: sipcore@ietf.org References: From: Paul Kyzivat Message-ID: <8d1e594c-b218-73fa-01cb-4012b9268b2b@alum.mit.edu> Date: Thu, 1 Sep 2016 11:52:04 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfBJcBcZeBXt0W14ytaPRIIdtLUczUBTrZxztXy8j9mZ1dSR7ZTnPrrK1JSgssO219KbLemmo8uHbTUufeAA9llUj8UdRVJpZkwkZB7g5HZ8Ajju88PmF xpbNYePDDP5A+7+oXcirfscodD30LWqwD285/3RwpnbhuBcrf6nQYBUDqSJmj4FsoNH1JApb0m4W3g== Archived-At: Subject: Re: [sipcore] Using an INFO package in draft-ietf-ecrit-ecall-11 - Christer's compromise proposal X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 15:52:12 -0000 Christer, Your example is incomplete (e.g., multipart is specified but only one body part is shown), and I hesitate to comment without first seeing exactly what you mean. Can you please provide a complete example? Thanks, Paul On 9/1/16 4:53 AM, Christer Holmberg wrote: > Hi, > > While I highly appreciate Daleıs input on the INFO issue, it seems like we > wonıt get much wider input from the SIPCORE community. > > So, in order to try to move forward, I would like to suggest a compromise > proposal of my own. From a SIP message structure perspective itıs > basically what Dale has suggested (and what I assumed was already stated > in draft-ecall-11), but with a different approach when it comes to the > documenting. > > First, the MSD is carried in an info package. > > Second, the main text in draft-ecall talks about using the info package > mechanism for carrying the MSD in INFO. The main text does not talk about > using the additional data mechanism. > > Third, and this is where my comprise proposal comes it, within the info > package specification we add some text saying that while the > semantics/context of the MSD MIME body is defined within the info package > specification, in order to be aligned with the sending of MSD in non-INFO > requests we use the content-disposition value reference-by and we include > the Call-Info header field, as defined by Additional Data, in the INFO > request. > > That way, we make it clear that we are using the info package mechanism > for transporting MSD in INFO, but it still allows for usage of Call-Info > in INFO. > > Would people be ok with that? > > > INFO example: > > > Call-Info: ;purpose=emergencyCallData.eCall.MSD > Content-Type: multipart/mixed;boundary="theboundary" > Content-Disposition: info-package > > --theboundary > > Content-Type: application/emergencyCallData.eCall.MSD+per > Content-Dispostion: by-reference > > > > ‹theboundary-- > > Regards, > > Christer > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Thu Sep 1 08:54:05 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A815C12D788 for ; Thu, 1 Sep 2016 08:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 l_vRA62dfhcU for ; Thu, 1 Sep 2016 08:53:58 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D73B12D548 for ; Thu, 1 Sep 2016 08:53:57 -0700 (PDT) X-AuditID: c1b4fb25-ca31e98000001071-45-57c84f144c45 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by (Symantec Mail Security) with SMTP id B6.54.04209.41F48C75; Thu, 1 Sep 2016 17:53:56 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.211]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0301.000; Thu, 1 Sep 2016 17:53:54 +0200 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Using an INFO package in draft-ietf-ecrit-ecall-11 - Christer's compromise proposal Thread-Index: AQHSBC5ftgmMQ/YNK0CJFiBqGyMrZaBkp60AgAAhu3A= Date: Thu, 1 Sep 2016 15:53:54 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BC7F7EF@ESESSMB209.ericsson.se> References: <8d1e594c-b218-73fa-01cb-4012b9268b2b@alum.mit.edu> In-Reply-To: <8d1e594c-b218-73fa-01cb-4012b9268b2b@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrALMWRmVeSWpSXmKPExsUyM2K7qK6I/4lwgz+fJC1WbDjAavH1xyY2 ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSvjQlM/e8FU4YrWe0fZGxjP83cxcnJICJhI PF7TyNLFyMUhJLCeUaLjwX9WCGcxo8T/29uAHA4ONgELie5/2iANIgKBEleXTGAGsYUFciQW 73jPDBHPlbh37AUThG0l8bTtEwuIzSKgIvFv71R2EJtXwFfixPprjCC2kECBxMrT3awgNqeA g8S6nx/ZQGxGATGJ76fWgM1hFhCXuPVkPhPEoQISS/acZ4awRSVePv7HCmErSTQuecIKUa8n cWPqFDYIW1ti2cLXzBB7BSVOznzCMoFRZBaSsbOQtMxC0jILScsCRpZVjKLFqcVJuelGxnqp RZnJxcX5eXp5qSWbGIHxcHDLb9UdjJffOB5iFOBgVOLhTTA5ES7EmlhWXJl7iFGCg1lJhNfB ByjEm5JYWZValB9fVJqTWnyIUZqDRUmc1/+lYriQQHpiSWp2ampBahFMlomDU6qBUZzb/I/b PcUE1Tu7Flu2fm9+JHR8osNKo/UPtbYcutNw/8r8RZqBkoF/m3et/u68fanqQtU46w7+xjVZ gYuev+gv8fAt8DnZrjDh6qZbP8WNHUWvSMWncU+9p79e/dEdJlPfXQxSHgouW1s6dVv4GE53 1aUveX7DVu73+Z1fW+OOnpHre9parsRSnJFoqMVcVJwIAAoDquqDAgAA Archived-At: Subject: Re: [sipcore] Using an INFO package in draft-ietf-ecrit-ecall-11 - Christer's compromise proposal X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 15:54:04 -0000 Hi, >Your example is incomplete (e.g., multipart is specified but only one body= part is >shown), and I hesitate to comment without first seeing exactly wh= at you mean. Can >you please provide a complete example? My example shows an INFO only carrying MSD, so it is no incomplete. Regards, Christer On 9/1/16 4:53 AM, Christer Holmberg wrote: > Hi, > > While I highly appreciate Dale=B9s input on the INFO issue, it seems=20 > like we won=B9t get much wider input from the SIPCORE community. > > So, in order to try to move forward, I would like to suggest a=20 > compromise proposal of my own. From a SIP message structure=20 > perspective it=B9s basically what Dale has suggested (and what I assumed= =20 > was already stated in draft-ecall-11), but with a different approach=20 > when it comes to the documenting. > > First, the MSD is carried in an info package. > > Second, the main text in draft-ecall talks about using the info=20 > package mechanism for carrying the MSD in INFO. The main text does not=20 > talk about using the additional data mechanism. > > Third, and this is where my comprise proposal comes it, within the=20 > info package specification we add some text saying that while the=20 > semantics/context of the MSD MIME body is defined within the info=20 > package specification, in order to be aligned with the sending of MSD=20 > in non-INFO requests we use the content-disposition value reference-by=20 > and we include the Call-Info header field, as defined by Additional=20 > Data, in the INFO request. > > That way, we make it clear that we are using the info package=20 > mechanism for transporting MSD in INFO, but it still allows for usage=20 > of Call-Info in INFO. > > Would people be ok with that? > > > INFO example: > > > Call-Info: ;purpose=3DemergencyCallData.eCall.MSD > Content-Type: multipart/mixed;boundary=3D"theboundary" > Content-Disposition: info-package > > --theboundary > > Content-Type: application/emergencyCallData.eCall.MSD+per > Content-Dispostion: by-reference > > > > > Regards, > > Christer > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From nobody Thu Sep 1 09:24:54 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF80B12B02B for ; Thu, 1 Sep 2016 09:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 6LUJsuWPhsbC for ; Thu, 1 Sep 2016 09:24:51 -0700 (PDT) Received: from resqmta-ch2-04v.sys.comcast.net (resqmta-ch2-04v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9F3C12D1A9 for ; Thu, 1 Sep 2016 09:24:51 -0700 (PDT) Received: from resomta-ch2-19v.sys.comcast.net ([69.252.207.115]) by resqmta-ch2-04v.sys.comcast.net with SMTP id fUiwbPDrZ8PeafUnLbexTQ; Thu, 01 Sep 2016 16:24:51 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-19v.sys.comcast.net with SMTP id fUnKb6WQDinoRfUnKbZKsX; Thu, 01 Sep 2016 16:24:50 +0000 To: Christer Holmberg , "sipcore@ietf.org" References: <8d1e594c-b218-73fa-01cb-4012b9268b2b@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4BC7F7EF@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: Date: Thu, 1 Sep 2016 12:24:48 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BC7F7EF@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfGtWlMjcKybeGO47RGBBzLrn2RKueBM+33qE3H0oO1f4/Ts/mM7wq2TIe7kUeIYShuq+nW5ap5ZhXdaRC1NWLnAfSstE0ALv6Q+0Q8F1CfBpIK+durz0 D8HWwpO94xNV5ltPUV4FsWkbqDbY2mvyMtE8dDzAlySwHIQcSTrGaiUWIHmwIYC5yQaf7edTmvY/ajPFC2Mfw+hj/KfpBhE6R7VAjzUP3+xvlw1jS2MdAG8+ Archived-At: Subject: Re: [sipcore] Using an INFO package in draft-ietf-ecrit-ecall-11 - Christer's compromise proposal X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 16:24:53 -0000 On 9/1/16 11:53 AM, Christer Holmberg wrote: > Hi, > >> Your example is incomplete (e.g., multipart is specified but only one body part is >shown), and I hesitate to comment without first seeing exactly what you mean. Can >you please provide a complete example? > > My example shows an INFO only carrying MSD, so it is no incomplete. Oh, sorry. I misunderstood what you were doing. Yes, this is very much in the spirit of what Dale suggested. I think it is simply a degenerate form of it. IMO this is a valid combination of INFO and call-info. So, using this approach, what would be your message sequence including the request for an update of MSD? The prior approach was able to send the MSD on the response to the INFO that requested it, Or to send it attached to some message following that request. IIUC, in your approach here there will first be a response to the INFO request (no body) followed by another INFO in the other direction of the form you show here. Presupposing that all this was valid, would it still be valid for UA to send some unsolicited message in the dialog (e.g., UPDATE) with an MSD as additional-data? Thanks, Paul From nobody Thu Sep 1 09:32:30 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEA5212D5A3 for ; Thu, 1 Sep 2016 09:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 HIhNsM6Vtqgv for ; Thu, 1 Sep 2016 09:32:24 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49E7512D534 for ; Thu, 1 Sep 2016 09:32:24 -0700 (PDT) X-AuditID: c1b4fb3a-0618b980000009bd-0f-57c85816add5 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by (Symantec Mail Security) with SMTP id B1.B4.02493.61858C75; Thu, 1 Sep 2016 18:32:22 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.211]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0301.000; Thu, 1 Sep 2016 18:32:01 +0200 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Using an INFO package in draft-ietf-ecrit-ecall-11 - Christer's compromise proposal Thread-Index: AQHSBC5ftgmMQ/YNK0CJFiBqGyMrZaBkp60AgAAhu3D//+drAIAAIiHg Date: Thu, 1 Sep 2016 16:32:00 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BC7FBEE@ESESSMB209.ericsson.se> References: <8d1e594c-b218-73fa-01cb-4012b9268b2b@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4BC7F7EF@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrALMWRmVeSWpSXmKPExsUyM2K7pa5YxIlwg/mNehYrNhxgtfj6YxOb A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJWx87pGwQ3eilVbnjA2MD7g6mLk5JAQMJH4 dmUjcxcjF4eQwHpGiW27H7JDOIsZJbYu/8HYxcjBwSZgIdH9TxukQUQgUOLqkgnMILawQI7E 4h3vmSHiuRL3jr1ggrDdJO7eXcgIYrMIqEisnDqZDcTmFfCVWLBiLQvE/FeMEvOaPrCAJDgF HCRW318H1swoICbx/dQaMJtZQFzi1pP5TBCXCkgs2XOeGcIWlXj5+B8rhK0k0bjkCStEvY7E gt2f2CBsbYllC18zQywWlDg58wnLBEaRWUjGzkLSMgtJyywkLQsYWVYxihanFhfnphsZ6aUW ZSYXF+fn6eWllmxiBMbDwS2/rXYwHnzueIhRgINRiYc3weREuBBrYllxZe4hRgkOZiUR3oWh QCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8/i8Vw4UE0hNLUrNTUwtSi2CyTBycUg2M/fN0rbtf ti381F3ovs5SNcn8a7f1o1jLCwuWKcpOmfjln8x/K/awEkZ1X/nqZcnfRVfM/9dWrqcta83e ecdGLz91SsS1rZcaUq/NaOY5zLl1u7r3rK0tRvZTleO3L/g9+YStqFFDxeznOUufx9Qv4b4v PuvrXvGfhy4fr/5n2zr16VlJjqQfSizFGYmGWsxFxYkAalafx4MCAAA= Archived-At: Subject: Re: [sipcore] Using an INFO package in draft-ietf-ecrit-ecall-11 - Christer's compromise proposal X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 16:32:29 -0000 Hi, >>> Your example is incomplete (e.g., multipart is specified but only one b= ody part is shown), and I=20 >>> hesitate to comment without first seeing exactly what you mean. Can >yo= u please provide a complete example? >> >> My example shows an INFO only carrying MSD, so it is no incomplete. > > Oh, sorry. I misunderstood what you were doing. > > Yes, this is very much in the spirit of what Dale suggested. I think it i= s simply a degenerate form of it. IMO this is a valid combination of INFO a= nd call-info. Correct. My suggestion will mostly impact how we document everything. > So, using this approach, what would be your message sequence including th= e request for an update of MSD? > > The prior approach was able to send the MSD on the response to the INFO t= hat requested it, Or to send it attached > to some message following that request. IIUC, in your approach here there= will first be a response to the INFO request=20 > (no body) followed by another INFO in the other direction of the form you= show here. Correct. Formally we would be using an info package to carry the MSD, so th= e RFC 6086 rules apply (read: we only send MSD in INFO requests). > Presupposing that all this was valid, would it still be valid for UA to s= end some unsolicited message in the dialog (e.g., UPDATE) with an MSD as ad= ditional-data? I think is a separate question, not related to the INFO usage. But, to answ= er your question: in my opinion, if you are sending an UPDATE for whatever = valid reason, I think it is ok to include MSD as additional-data. But, I d= on't think one should send UPDATE just for the purpose of conveying MSD - f= or that one should use INFO. Regards, Christer From nobody Thu Sep 1 11:14:37 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C270F12D995 for ; Thu, 1 Sep 2016 11:14:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 HxLbvcJqLM3w for ; Thu, 1 Sep 2016 11:14:34 -0700 (PDT) Received: from resqmta-ch2-07v.sys.comcast.net (resqmta-ch2-07v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1FFE12D5C2 for ; Thu, 1 Sep 2016 11:14:34 -0700 (PDT) Received: from resomta-ch2-20v.sys.comcast.net ([69.252.207.116]) by resqmta-ch2-07v.sys.comcast.net with SMTP id fWTzbon7pff8qfWVWbIDTV; Thu, 01 Sep 2016 18:14:34 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-20v.sys.comcast.net with SMTP id fWVUb5NY7tzqtfWVVbXUCz; Thu, 01 Sep 2016 18:14:33 +0000 To: Christer Holmberg , "sipcore@ietf.org" References: <8d1e594c-b218-73fa-01cb-4012b9268b2b@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4BC7F7EF@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BC7FBEE@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: <39f9c421-30a8-b55b-ff9f-5e3cd6f8138a@alum.mit.edu> Date: Thu, 1 Sep 2016 14:14:31 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BC7FBEE@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfDkk9INMts8gwOB4PfLqh2gLssz0SG0xzvVC0zRyL6+Cy9vpQoWAAtsmj0+C7myHxBPmjRXhd+AQTgudaUrN8hfMRIZQtWAZoxZcJ7Pwy9AVKCgDUgOc gYxXUl7/OthiMZUCov8jYq+hs4ReOmf9nQiT0jgMCJCkBkN9Plpxo0ruMmUfJIABbiLkI0xVCFCvGu2ZQoO7hGX19LqSSC1zQf+VUzxqQIACApd+I4XS/ZOJ Archived-At: Subject: Re: [sipcore] Using an INFO package in draft-ietf-ecrit-ecall-11 - Christer's compromise proposal X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 18:14:36 -0000 OK, we are largely in agreement here. One comment inline. On 9/1/16 12:32 PM, Christer Holmberg wrote: > Hi, > >>>> Your example is incomplete (e.g., multipart is specified but only one body part is shown), and I >>>> hesitate to comment without first seeing exactly what you mean. Can >you please provide a complete example? >>> >>> My example shows an INFO only carrying MSD, so it is no incomplete. >> >> Oh, sorry. I misunderstood what you were doing. >> >> Yes, this is very much in the spirit of what Dale suggested. I think it is simply a degenerate form of it. IMO this is a valid combination of INFO and call-info. > > Correct. My suggestion will mostly impact how we document everything. > >> So, using this approach, what would be your message sequence including the request for an update of MSD? >> >> The prior approach was able to send the MSD on the response to the INFO that requested it, Or to send it attached >> to some message following that request. IIUC, in your approach here there will first be a response to the INFO request >> (no body) followed by another INFO in the other direction of the form you show here. > > Correct. Formally we would be using an info package to carry the MSD, so the RFC 6086 rules apply (read: we only send MSD in INFO requests). > >> Presupposing that all this was valid, would it still be valid for UA to send some unsolicited message in the dialog (e.g., UPDATE) with an MSD as additional-data? > > I think is a separate question, not related to the INFO usage. But, to answer your question: in my opinion, if you are sending an UPDATE for whatever valid reason, I think it is ok to include MSD as additional-data. But, I don't think one should send UPDATE just for the purpose of conveying MSD - for that one should use INFO. I agree it is a separate question. IIUC UPDATE may be used as a noop, good for testing the liveness of the path and the other end, better in some respects than OPTIONS. If somebody chooses to use one to attach something, I probably wouldn't object. Certainly when judging this from a black box perspective you can't know *why* the OPTIONS was sent. In the particular case of MSD, if it can either be sent with INFO as you propose, or with UPDATE, then I would probably recommend INFO. Thanks, Paul From nobody Thu Sep 1 11:29:28 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DCB512D995 for ; Thu, 1 Sep 2016 11:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 eYWgDDOSZHpP for ; Thu, 1 Sep 2016 11:29:25 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56B5812D616 for ; Thu, 1 Sep 2016 11:29:25 -0700 (PDT) X-AuditID: c1b4fb25-ca31e98000001071-59-57c87383c70d Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by (Symantec Mail Security) with SMTP id 3F.38.04209.38378C75; Thu, 1 Sep 2016 20:29:23 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.211]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0301.000; Thu, 1 Sep 2016 20:29:22 +0200 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Using an INFO package in draft-ietf-ecrit-ecall-11 - Christer's compromise proposal Thread-Index: AQHSBC5ftgmMQ/YNK0CJFiBqGyMrZaBkp60AgAAhu3D//+drAIAAIiHg///8hoCAACOUgA== Date: Thu, 1 Sep 2016 18:29:22 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BC7FEB6@ESESSMB209.ericsson.se> References: <8d1e594c-b218-73fa-01cb-4012b9268b2b@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4BC7F7EF@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BC7FBEE@ESESSMB209.ericsson.se> <39f9c421-30a8-b55b-ff9f-5e3cd6f8138a@alum.mit.edu> In-Reply-To: <39f9c421-30a8-b55b-ff9f-5e3cd6f8138a@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyM2K7vW5z8Ylwg7mfdCxWbDjAavH1xyY2 ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSvj08sdzAVbeSrWzLNsYHzM2cXIySEhYCKx //IrFhBbSGA9o8TZnVxdjFxA9mJGiR/b5zJ3MXJwsAlYSHT/0wapEREIlLi6ZAIziC0skCOx eMd7Zoh4rsS9Yy+YIOwwiaYjuxhBbBYBFYkJGzaBzecV8JV4seI2E8SuJ0wSC1ZVgIznFHCQ ONpYBhJmFBCT+H5qDVgJs4C4xK0n85kgzhSQWLLnPDOELSrx8vE/VghbSaJxyRNWiHodiQW7 P7FB2NoSyxa+ZoZYKyhxcuYTlgmMIrOQjJ2FpGUWkpZZSFoWMLKsYhQtTi1Oyk03MtZLLcpM Li7Oz9PLSy3ZxAiMhINbfqvuYLz8xvEQowAHoxIPb4LJiXAh1sSy4srcQ4wSHMxKIrxHi4BC vCmJlVWpRfnxRaU5qcWHGKU5WJTEef1fKoYLCaQnlqRmp6YWpBbBZJk4OKUaGG1OCKdMk52m 1tiw3dLCacLZ1R3N8sar5gjt47c/OJUhSa+Lb53Sk6rEuLcTJLuYpb1sfF8tXqw9z0Av8hi7 1XvnAy6BKu6/Z219y/437Hn02t3TTqxx1dh+Z753gfT165HR67q71kbumdndaLvGwf88e/CF 9MazN9Svvv7Vtuj5RNEFb+vDZiixFGckGmoxFxUnAgBarYyKgAIAAA== Archived-At: Subject: Re: [sipcore] Using an INFO package in draft-ietf-ecrit-ecall-11 - Christer's compromise proposal X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 18:29:27 -0000 Hi, ... >>> Presupposing that all this was valid, would it still be valid for UA to= send some unsolicited message in the dialog (e.g., UPDATE) with an MSD as = additional-data? >> >> I think is a separate question, not related to the INFO usage. But, to a= nswer your question: in my opinion, if=20 >> you are sending an UPDATE for whatever valid reason, I think it is ok to= include MSD as additional-data. But, I=20 >> don't think one should send UPDATE just for the purpose of conveying MSD= - for that one should use INFO. > > I agree it is a separate question. > > IIUC UPDATE may be used as a noop, good for testing the liveness of the p= ath and the other end, better in some=20 > respects than OPTIONS. If somebody chooses to use one to attach something= , I probably wouldn't object. Certainly=20 > when judging this from a black box perspective you can't know *why* the O= PTIONS was sent. In the particular case=20 > of MSD, if it can either be sent with INFO as you propose, or with UPDATE= , then I would probably recommend INFO. I would actually support MUST use INFO, unless you happen to send UPDATE fo= r some other purpose. I don't want people to start using UPDATE instead of = INFO, because that's not proper SIP, in my opinion. MSD is application info= rmation, and doesn't impact the SIP session state, so INFO shall be used. If someone wants to forbid usage of UPDATE for transporting MSD in *any* ci= rcumstance, and only allow INFO mid-session, I probably would not object to= that either :) Regards, Christer From nobody Thu Sep 1 11:52:58 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D37312D5FB for ; Thu, 1 Sep 2016 11:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 Jk9ZKpcy-qu5 for ; Thu, 1 Sep 2016 11:52:55 -0700 (PDT) Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 749FE12DAC9 for ; Thu, 1 Sep 2016 11:52:52 -0700 (PDT) Received: from resomta-ch2-13v.sys.comcast.net ([69.252.207.109]) by resqmta-ch2-05v.sys.comcast.net with SMTP id fX4gb43xQ2FGMfX6ZbGfsN; Thu, 01 Sep 2016 18:52:51 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-13v.sys.comcast.net with SMTP id fX6ZbybeFDFgBfX6ZbfxDM; Thu, 01 Sep 2016 18:52:51 +0000 To: Christer Holmberg , "sipcore@ietf.org" References: <8d1e594c-b218-73fa-01cb-4012b9268b2b@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4BC7F7EF@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BC7FBEE@ESESSMB209.ericsson.se> <39f9c421-30a8-b55b-ff9f-5e3cd6f8138a@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4BC7FEB6@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: Date: Thu, 1 Sep 2016 14:52:49 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BC7FEB6@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfHaryE4KhUHz9jK4hkUNdwseSOdSiLA0XIfoatlxTgfmzFQNp7B/R/+BzhKlHJQsdHO7SXXvrL3jkR5xV1zvMvxeN9Sm+w37WnFgwLHG4gcrehAbSL2B HdcKwohM4wb5D4uzR0UZor0HwEkZW4xqsakbvVFFdqoOYXRdn15VcJq8j9GqK7E7IdvEKLR1xC58r1kQO4tL59LpviGXufANCUX+DiRYXpFPwqrKW34ajj4Y Archived-At: Subject: Re: [sipcore] Using an INFO package in draft-ietf-ecrit-ecall-11 - Christer's compromise proposal X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 18:52:56 -0000 On 9/1/16 2:29 PM, Christer Holmberg wrote: > Hi, > > ... > >>>> Presupposing that all this was valid, would it still be valid for UA to send some unsolicited message in the dialog (e.g., UPDATE) with an MSD as additional-data? >>> >>> I think is a separate question, not related to the INFO usage. But, to answer your question: in my opinion, if >>> you are sending an UPDATE for whatever valid reason, I think it is ok to include MSD as additional-data. But, I >>> don't think one should send UPDATE just for the purpose of conveying MSD - for that one should use INFO. >> >> I agree it is a separate question. >> >> IIUC UPDATE may be used as a noop, good for testing the liveness of the path and the other end, better in some >> respects than OPTIONS. If somebody chooses to use one to attach something, I probably wouldn't object. Certainly >> when judging this from a black box perspective you can't know *why* the OPTIONS was sent. In the particular case >> of MSD, if it can either be sent with INFO as you propose, or with UPDATE, then I would probably recommend INFO. > > I would actually support MUST use INFO, unless you happen to send UPDATE for some other purpose. I don't want people to start using UPDATE instead of INFO, because that's not proper SIP, in my opinion. MSD is application information, and doesn't impact the SIP session state, so INFO shall be used. > > If someone wants to forbid usage of UPDATE for transporting MSD in *any* circumstance, and only allow INFO mid-session, I probably would not object to that either :) I guess you can forbid this usage for MSD if you wish, as part of the definition of MSD. I don't think you can forbid it for all uses of cid: in sip header fields. Thanks, Paul From nobody Thu Sep 1 12:15:36 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B30812D5CD for ; Thu, 1 Sep 2016 12:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 k757iH5_CtAl for ; Thu, 1 Sep 2016 12:15:33 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61D1B12D630 for ; Thu, 1 Sep 2016 12:15:33 -0700 (PDT) X-AuditID: c1b4fb3a-0618b980000009bd-39-57c87e53e7fc Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by (Symantec Mail Security) with SMTP id 4E.C2.02493.35E78C75; Thu, 1 Sep 2016 21:15:31 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.211]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0301.000; Thu, 1 Sep 2016 21:15:29 +0200 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Using an INFO package in draft-ietf-ecrit-ecall-11 - Christer's compromise proposal Thread-Index: AQHSBC5ftgmMQ/YNK0CJFiBqGyMrZaBkp60AgAAhu3D//+drAIAAIiHg///8hoCAACOUgP//5yCAAASj5kA= Date: Thu, 1 Sep 2016 19:15:28 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BC8003C@ESESSMB209.ericsson.se> References: <8d1e594c-b218-73fa-01cb-4012b9268b2b@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4BC7F7EF@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BC7FBEE@ESESSMB209.ericsson.se> <39f9c421-30a8-b55b-ff9f-5e3cd6f8138a@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4BC7FEB6@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrALMWRmVeSWpSXmKPExsUyM2K7t25w3Ylwg20PNCxWbDjAavH1xyY2 ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugStjyYR7bAWnOCt+fn/G1sC4n72LkZNDQsBE ovnTOcYuRi4OIYH1jBKzTx1nhXAWM0rcez2drYuRg4NNwEKi+582SIOIQKDE1SUTmEFsYYEc icU73jNDxHMl7h17wQRhJ0lM7dkBFmcRUJGYvOgcE8gYXgFfibdvfCHG32OWePPgJhtIDaeA g8T5SR1gvYwCYhLfT60Bs5kFxCVuPZnPBHGogMSSPeeZIWxRiZeP/7FC2EoSjUuesELU60gs 2P2JDcLWlli28DVYPa+AoMTJmU9YJjCKzEIydhaSlllIWmYhaVnAyLKKUbQ4tbg4N93ISC+1 KDO5uDg/Ty8vtWQTIzAeDm75bbWD8eBzx0OMAhyMSjy8CSYnwoVYE8uKK3MPMUpwMCuJ8JpV A4V4UxIrq1KL8uOLSnNSiw8xSnOwKInz+r9UDBcSSE8sSc1OTS1ILYLJMnFwSjUw2vX43c1+ vkR5z6dof6mdG5Yb8P71fP3tcYr1/4u6y+SvhpnN6wnbFDxR94jZVrk9W/b5r5MNvet18Yao Z0Qxv3WThulVjngT/9maYv+6btoeLZ51ImrlgauWxyYJTchbJbD60qIYyYJ1nYfEVSWuPDt8 TFXsrWZiyNMHnAvSCuXf9KZ3n58uoMRSnJFoqMVcVJwIALRn3seDAgAA Archived-At: Subject: Re: [sipcore] Using an INFO package in draft-ietf-ecrit-ecall-11 - Christer's compromise proposal X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 19:15:35 -0000 Hi, ... >> I would actually support MUST use INFO, unless you happen to send UPDATE= for some other=20 >> purpose. I don't want people to start using UPDATE instead of INFO, beca= use that's not proper=20 >> SIP, in my opinion. MSD is application information, and doesn't impact t= he SIP session state, so INFO shall be used. >> >> If someone wants to forbid usage of UPDATE for transporting MSD in=20 >> *any* circumstance, and only allow INFO mid-session, I probably would=20 >> not object to that either :) > > I guess you can forbid this usage for MSD if you wish, as part of the def= inition of MSD. ...or, in draft-ecrit-ecall we can say that MSD can only be sent in the ini= tial INVITE and INFOs. Also, the rate of INFOs can be "controlled" within the info package specifi= cation, but there is nowhere to do it for UPDATE. So, the more I think abou= t it, there more I think we should NOT allow MSD in UPDATE. I don't really = see a need for it, as MSD is not expected to be sent too often to begin wit= h. An UPDATE can of course be used to re-negotiate the supported info packages= , but that's a separate thing (which I don't think is needed for ecall). Regards, Christer From nobody Thu Sep 1 13:06:21 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0326912D733 for ; Thu, 1 Sep 2016 13:06:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.768 X-Spam-Level: X-Spam-Status: No, score=-4.768 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548] autolearn=ham autolearn_force=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 LmWmd8MqVUZn for ; Thu, 1 Sep 2016 13:06:18 -0700 (PDT) Received: from tcmail23.telekom.de (tcmail23.telekom.de [80.149.113.243]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DE4812B04E for ; Thu, 1 Sep 2016 13:06:17 -0700 (PDT) Received: from q4de8psa169.blf.telekom.de ([10.151.13.200]) by tcmail21.telekom.de with ESMTP/TLS/DHE-RSA-AES128-SHA; 01 Sep 2016 22:06:07 +0200 X-IronPort-AV: E=Sophos;i="5.30,268,1470693600"; d="scan'208";a="1134801579" Received: from he105661.emea1.cds.t-internal.com ([10.169.119.57]) by q4de8psazkj.blf.telekom.de with ESMTP/TLS/AES256-SHA; 01 Sep 2016 22:06:07 +0200 Received: from HE105660.EMEA1.cds.t-internal.com (10.169.119.56) by HE105661.emea1.cds.t-internal.com (10.169.119.57) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 1 Sep 2016 22:06:06 +0200 Received: from HE105660.EMEA1.cds.t-internal.com ([fe80::c5cd:6c67:9f4d:7318]) by HE105660.emea1.cds.t-internal.com ([fe80::c5cd:6c67:9f4d:7318%26]) with mapi id 15.00.1178.000; Thu, 1 Sep 2016 22:06:06 +0200 From: To: , , Thread-Topic: [sipcore] Using an INFO package in draft-ietf-ecrit-ecall-11 - Christer's compromise proposal Thread-Index: AQHSBC5ftgmMQ/YNK0CJFiBqGyMrZaBkp60AgAAhu3D//+drAIAAIiHg///8hoCAACOUgP//5yCAAASj5kAAAMR5IA== Date: Thu, 1 Sep 2016 20:06:06 +0000 Message-ID: <8720b72525514356baf494c77eb48a9a@HE105660.emea1.cds.t-internal.com> References: <8d1e594c-b218-73fa-01cb-4012b9268b2b@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4BC7F7EF@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BC7FBEE@ESESSMB209.ericsson.se> <39f9c421-30a8-b55b-ff9f-5e3cd6f8138a@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4BC7FEB6@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BC8003C@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BC8003C@ESESSMB209.ericsson.se> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.213.68.94] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sipcore] Using an INFO package in draft-ietf-ecrit-ecall-11 - Christer's compromise proposal X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 20:06:20 -0000 Hi Christer, >...or, in draft-ecrit-ecall we can say that MSD can only be sent in the in= itial INVITE and INFOs. That I would prefer, because I assume that we will have a lot of calls wher= e we even do not need any additional MSD send in the midcall (i.e. INFO).=20 So I would save an additional roundtrip in SIP to get the information. Best regards Roland -----Urspr=FCngliche Nachricht----- Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von Christer Holm= berg Gesendet: Donnerstag, 1. September 2016 21:15 An: Paul Kyzivat; sipcore@ietf.org Betreff: Re: [sipcore] Using an INFO package in draft-ietf-ecrit-ecall-11 -= Christer's compromise proposal Hi, ... >> I would actually support MUST use INFO, unless you happen to send=20 >> UPDATE for some other purpose. I don't want people to start using=20 >> UPDATE instead of INFO, because that's not proper SIP, in my opinion. MS= D is application information, and doesn't impact the SIP session state, so = INFO shall be used. >> >> If someone wants to forbid usage of UPDATE for transporting MSD in >> *any* circumstance, and only allow INFO mid-session, I probably would=20 >> not object to that either :) > > I guess you can forbid this usage for MSD if you wish, as part of the def= inition of MSD. ...or, in draft-ecrit-ecall we can say that MSD can only be sent in the ini= tial INVITE and INFOs. Also, the rate of INFOs can be "controlled" within the info package specifi= cation, but there is nowhere to do it for UPDATE. So, the more I think abou= t it, there more I think we should NOT allow MSD in UPDATE. I don't really = see a need for it, as MSD is not expected to be sent too often to begin wit= h. An UPDATE can of course be used to re-negotiate the supported info packages= , but that's a separate thing (which I don't think is needed for ecall). Regards, Christer _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From nobody Fri Sep 2 00:23:36 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 763CB12B061 for ; Fri, 2 Sep 2016 00:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 lEja7gzhnPMu for ; Fri, 2 Sep 2016 00:23:31 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE78412B05B for ; Fri, 2 Sep 2016 00:23:30 -0700 (PDT) X-AuditID: c1b4fb2d-903ff700000019a3-48-57c928ef9315 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by (Symantec Mail Security) with SMTP id 03.94.06563.FE829C75; Fri, 2 Sep 2016 09:23:28 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.211]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0301.000; Fri, 2 Sep 2016 09:23:27 +0200 From: Christer Holmberg To: "R.Jesske@telekom.de" , "pkyzivat@alum.mit.edu" , "sipcore@ietf.org" Thread-Topic: AW: [sipcore] Using an INFO package in draft-ietf-ecrit-ecall-11 - Christer's compromise proposal Thread-Index: AQHSBOrlRoc7djoJFkW2B3VIH1fFxg== Date: Fri, 2 Sep 2016 07:23:26 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <334BCE991811AA429513DE52E9E2F61D@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjkeLIzCtJLcpLzFFi42KZGbFdRfeDxslwgyczFS1WbDjAatF0p4vN 4uuPTWwOzB5/339g8liy5CeTR9tLhQDmKC6blNSczLLUIn27BK6MF9+XMBc8F6lYcPYfewPj E4EuRk4OCQETib7WN4xdjFwcQgLrGSWm/ZgA5SxmlFjwZRJbFyMHB5uAhUT3P22QuIhAJ6PE y4ctjCDdwgIFEpvuPmIFsUUECiWOvfzFBmHrSfy49oUdxGYRUJFY8GIeWD2vgJXEhsNHwOKM AmIS30+tYQKxmQXEJW49mc8EcZGAxJI955khbFGJl4//gc0XBZr5/etsqLiixNXpy6F69SRu TJ3CBmFbSxy6tpsdwtaWWLbwNTPEXkGJkzOfsExgFJmFZN0sJO2zkLTPQtI+C0n7AkbWVYyi xanFxbnpRsZ6qUWZycXF+Xl6eaklmxiBsXNwy2/dHYyrXzseYhTgYFTi4U0wOREuxJpYVlyZ e4hRgoNZSYT3pfrJcCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8/i8Vw4UE0hNLUrNTUwtSi2Cy TBycUg2MKXurXb++2ugbq3j99/IEdYP6nVOs5wd+KTxYO4f38/ET9Utz9abmL/hxc+PaHzrW 1r0Lt3fOn88Z9MiD23zLjCe8jmfevf+o5l36pnYua2idvNKNNNclbeGuWxWLTvBe7jYQrCnz OfPq7x6foyXyHv8/vU+Z7/OHl2V/uPuP8JVit9PCw14/V2Ipzkg01GIuKk4EAGL1zAyZAgAA Archived-At: Subject: Re: [sipcore] Using an INFO package in draft-ietf-ecrit-ecall-11 - Christer's compromise proposal X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 07:23:33 -0000 Hi Roland, I think everyone agrees that MSD can be sent in the initial INVITE. The question was whether we should allow MSD to be sent in mid-call UPDATEs, or whether one always has to use INFO. Personally I think one should only use INFO mid-call. UPDATEs are not meant to transport application information, and I believe the processing of UPDATEs also consume more resources than INFOs, since you have to check how/if the UPDATE affects the SIP state etc. Regards, Christer On 01/09/16 23:06, "R.Jesske@telekom.de" wrote: >Hi Christer, > >>...or, in draft-ecrit-ecall we can say that MSD can only be sent in the >>initial INVITE and INFOs. > >That I would prefer, because I assume that we will have a lot of calls >where we even do not need any additional MSD send in the midcall (i.e. >INFO).=20 > >So I would save an additional roundtrip in SIP to get the information. > >Best regards > >Roland > >-----Urspr=FCngliche Nachricht----- >Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von Christer >Holmberg >Gesendet: Donnerstag, 1. September 2016 21:15 >An: Paul Kyzivat; sipcore@ietf.org >Betreff: Re: [sipcore] Using an INFO package in draft-ietf-ecrit-ecall-11 >- Christer's compromise proposal > >Hi, > >... > >>> I would actually support MUST use INFO, unless you happen to send >>> UPDATE for some other purpose. I don't want people to start using >>> UPDATE instead of INFO, because that's not proper SIP, in my opinion. >>>MSD is application information, and doesn't impact the SIP session >>>state, so INFO shall be used. >>> >>> If someone wants to forbid usage of UPDATE for transporting MSD in >>> *any* circumstance, and only allow INFO mid-session, I probably would >>> not object to that either :) >> >> I guess you can forbid this usage for MSD if you wish, as part of the >>definition of MSD. > >...or, in draft-ecrit-ecall we can say that MSD can only be sent in the >initial INVITE and INFOs. > >Also, the rate of INFOs can be "controlled" within the info package >specification, but there is nowhere to do it for UPDATE. So, the more I >think about it, there more I think we should NOT allow MSD in UPDATE. I >don't really see a need for it, as MSD is not expected to be sent too >often to begin with. > >An UPDATE can of course be used to re-negotiate the supported info >packages, but that's a separate thing (which I don't think is needed for >ecall). > >Regards, > >Christer > >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore From nobody Fri Sep 2 02:45:38 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D63912B02F for ; Fri, 2 Sep 2016 02:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=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 1yj12IZIf3Ms for ; Fri, 2 Sep 2016 02:45:35 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1222112D0EB for ; Fri, 2 Sep 2016 02:45:33 -0700 (PDT) Received: (qmail 1163 invoked from network); 2 Sep 2016 11:38:51 +0200 Received: from p5dec2984.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.41.132) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 2 Sep 2016 11:38:51 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <87mvk2xbi7.fsf@hobgoblin.ariadne.com> Date: Fri, 2 Sep 2016 11:38:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <96CF8F38-E679-48C1-AC74-4169A359A096@kuehlewind.net> References: <87mvk2xbi7.fsf@hobgoblin.ariadne.com> To: "Dale R. Worley" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: sipcore@ietf.org, draft-ietf-sipcore-dns-dual-stack@ietf.org, iesg@ietf.org, sipcore-chairs@ietf.org Subject: Re: [sipcore] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Yes_on_draft-ietf-si?= =?utf-8?q?pcore-dns-dual-stack-07=3A_=28with_COMMENT=29?= X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 09:45:37 -0000 Hi Dale, that=E2=80=99s fine! Sorry for my late reply! Mirja > Am 24.08.2016 um 20:33 schrieb Dale R. Worley : >=20 > "Mirja Kuehlewind (IETF)" writes: >>>> And related to this question: Shouldn't it be named "multi-stack = client" >>>> instead of "dual-stack client"? >>>=20 >>> Strictly speaking, "multi-stack client" is more robust against the >>> possibility that a third address family is introduced. However, the >>> term "dual-stack" is what has been used in all of the discussions >>> regarding the transition to using IPv6, so we have continued its use = in >>> this draft in the narrative portions. OTOH, all of the normative = text >>> is written to operate correctly even if further address families are >>> introduced. >>=20 >> I noticed that the whole doc is written in a way that would correctly >> operate with new address families. That's we I suggested this >> change. I think that this term would be as easily understandable as >> the current dual-stack term. But I don=E2=80=99t have a strong = opinion, so >> please just use what you think is better. >=20 > We've kept the term "dual-stack" because that's what's been used in = all > the Happy Eyeballs-related discussions, but we've revised the > Terminology section to make it clear that "dual-stack" includes any > situation "where the client has access to multiple communication = methods > that have distinct addressing characteristics". >=20 > I've updated the draft -08. You can see the differences in > = https://www.ietf.org/rfcdiff?url1=3D3Ddraft-ietf-sipcore-dns-dual-stack-07= &ur=3D > = l2=3D3Dhttp://svn.resiprocate.org/rep/ietf-drafts/worley/draft-ietf-sipcor= e-d=3D > ns-dual-stack-08.txt > and the entire current draft in > = http://svn.resiprocate.org/rep/ietf-drafts/worley/draft-ietf-sipcore-dns-d= u=3D > al-stack-08.{txt,html} >=20 > Dale >=20 From nobody Fri Sep 2 14:05:30 2016 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D5B5D12D1E7; Fri, 2 Sep 2016 14:05:28 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.31.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147285032886.24758.8123244781565909431.idtracker@ietfa.amsl.com> Date: Fri, 02 Sep 2016 14:05:28 -0700 Archived-At: Cc: ben@nostrum.com, sipcore-chairs@ietf.org, sipcore@ietf.org, draft-ietf-sipcore-dns-dual-stack@ietf.org, The IESG , rfc-editor@rfc-editor.org Subject: [sipcore] Protocol Action: 'Locating Session Initiation Protocol (SIP) Servers in a Dual-Stack IP Network' to Proposed Standard (draft-ietf-sipcore-dns-dual-stack-08.txt) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 21:05:29 -0000 The IESG has approved the following document: - 'Locating Session Initiation Protocol (SIP) Servers in a Dual-Stack IP Network' (draft-ietf-sipcore-dns-dual-stack-08.txt) as Proposed Standard This document is the product of the Session Initiation Protocol Core Working Group. The IESG contact persons are Alexey Melnikov, Ben Campbell and Alissa Cooper. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-dns-dual-stack/ Technical Summary This document lays the groundwork for future "Happy Eyeballs"-style work on SIP by updating DNS procedures for SIP URI resolution rules in a way that clarifies behavior for SIP stacks that support both IPv4 and IPv6. Working Group Summary The document spent several years in the working group, with occasional bursts of activity. The final push to completion was performed over the past few months by a concerted effort of a new author, who both incorporated long-standing feedback from the working group and worked out some of the finer details of the document. No aspect of the discussion proved controversial. Document Quality The document received in-depth review from a small handful of working group participants, and the results of those reviews were incorporated into the final version. No implementations of the protocol described in the document are known to exist yet; however, some of the problems addressed by the draft have been concretely demonstrated at the SIPit 31 interop event (which also highlighted some previously unnoticed problems with dual-stack address resolution). Dan Wing provided expert review for interaction with "Happy Eyeballs" techniques. Personnel Adam Roach is the document shepherd. Ben Campbell is the responsible area director. From nobody Sat Sep 3 05:59:05 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CE9C12B05A for ; Sat, 3 Sep 2016 05:59:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 qEXALsT9RJAy for ; Sat, 3 Sep 2016 05:59:01 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69053127058 for ; Sat, 3 Sep 2016 05:59:01 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id A631992979752; Sat, 3 Sep 2016 12:48:43 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u83CmkC2021138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 3 Sep 2016 12:48:46 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u83Cmjdb013788 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 3 Sep 2016 14:48:45 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.50]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Sat, 3 Sep 2016 14:48:45 +0200 From: "Drage, Keith (Nokia - GB)" To: Christer Holmberg , Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Using an INFO package in draft-ietf-ecrit-ecall-11 - Christer's compromise proposal Thread-Index: AQHSBC5ftgmMQ/YNK0CJFiBqGyMrZaBkp60AgAAhu3D//+drAIAAIiHg///8hoCAACOUgP//5yCAAASj5kAAUsMbIA== Date: Sat, 3 Sep 2016 12:48:45 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADF6108D@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <8d1e594c-b218-73fa-01cb-4012b9268b2b@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4BC7F7EF@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BC7FBEE@ESESSMB209.ericsson.se> <39f9c421-30a8-b55b-ff9f-5e3cd6f8138a@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4BC7FEB6@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BC8003C@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BC8003C@ESESSMB209.ericsson.se> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sipcore] Using an INFO package in draft-ietf-ecrit-ecall-11 - Christer's compromise proposal X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Sep 2016 12:59:03 -0000 We need to distinguish between the "application" and the data transfer mech= anism. The ecall draft writes requirements for the "application", and that = can state that additional data MUST ONLY be used in initial INVITE and its = responses. I do support the "application" only using the Info package for all its othe= r data transfer requirements. Keith -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmb= erg Sent: 01 September 2016 20:15 To: Paul Kyzivat; sipcore@ietf.org Subject: Re: [sipcore] Using an INFO package in draft-ietf-ecrit-ecall-11 -= Christer's compromise proposal Hi, ... >> I would actually support MUST use INFO, unless you happen to send=20 >> UPDATE for some other purpose. I don't want people to start using=20 >> UPDATE instead of INFO, because that's not proper SIP, in my opinion. MS= D is application information, and doesn't impact the SIP session state, so = INFO shall be used. >> >> If someone wants to forbid usage of UPDATE for transporting MSD in >> *any* circumstance, and only allow INFO mid-session, I probably would=20 >> not object to that either :) > > I guess you can forbid this usage for MSD if you wish, as part of the def= inition of MSD. ...or, in draft-ecrit-ecall we can say that MSD can only be sent in the ini= tial INVITE and INFOs. Also, the rate of INFOs can be "controlled" within the info package specifi= cation, but there is nowhere to do it for UPDATE. So, the more I think abou= t it, there more I think we should NOT allow MSD in UPDATE. I don't really = see a need for it, as MSD is not expected to be sent too often to begin wit= h. An UPDATE can of course be used to re-negotiate the supported info packages= , but that's a separate thing (which I don't think is needed for ecall). Regards, Christer _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From nobody Sat Sep 3 05:59:09 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4B18127058 for ; Sat, 3 Sep 2016 05:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 z9mDKuqn05_w for ; Sat, 3 Sep 2016 05:59:01 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 691E812B04C for ; Sat, 3 Sep 2016 05:59:01 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 444C8A0F02F55; Sat, 3 Sep 2016 12:48:44 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u83CmkXY021141 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 3 Sep 2016 12:48:46 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u83Cmk03013793 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 3 Sep 2016 14:48:46 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.50]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Sat, 3 Sep 2016 14:48:46 +0200 From: "Drage, Keith (Nokia - GB)" To: Paul Kyzivat , Christer Holmberg , "sipcore@ietf.org" Thread-Topic: [sipcore] Using an INFO package in draft-ietf-ecrit-ecall-11 - Christer's compromise proposal Thread-Index: AQHSBC5ftgmMQ/YNK0CJFiBqGyMrZaBkp60AgAAhu3D//+drAIAAIiHg///8hoCAAsaDIA== Date: Sat, 3 Sep 2016 12:48:46 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADF61092@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <8d1e594c-b218-73fa-01cb-4012b9268b2b@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4BC7F7EF@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BC7FBEE@ESESSMB209.ericsson.se> <39f9c421-30a8-b55b-ff9f-5e3cd6f8138a@alum.mit.edu> In-Reply-To: <39f9c421-30a8-b55b-ff9f-5e3cd6f8138a@alum.mit.edu> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sipcore] Using an INFO package in draft-ietf-ecrit-ecall-11 - Christer's compromise proposal X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Sep 2016 12:59:05 -0000 >From my perspective I don't think we can call this a compromise until we un= derstand what the proposal requires in the error situations. So what happen= s at the recipient when: - a Call-Info is not included in the INFO request - an invalid Call-Info (i.e. pointing to some non-existent data element) is= included in the INFO request - a Call-Info is included that point to data associated with some other usa= ge, but none included for the ecrit data. In my view in all these cases the Info package data has been validly transf= erred. Is this the understanding in the proposal? Keith -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: 01 September 2016 19:15 To: Christer Holmberg; sipcore@ietf.org Subject: Re: [sipcore] Using an INFO package in draft-ietf-ecrit-ecall-11 -= Christer's compromise proposal OK, we are largely in agreement here. One comment inline. On 9/1/16 12:32 PM, Christer Holmberg wrote: > Hi, > >>>> Your example is incomplete (e.g., multipart is specified but only=20 >>>> one body part is shown), and I hesitate to comment without first seein= g exactly what you mean. Can >you please provide a complete example? >>> >>> My example shows an INFO only carrying MSD, so it is no incomplete. >> >> Oh, sorry. I misunderstood what you were doing. >> >> Yes, this is very much in the spirit of what Dale suggested. I think it = is simply a degenerate form of it. IMO this is a valid combination of INFO = and call-info. > > Correct. My suggestion will mostly impact how we document everything. > >> So, using this approach, what would be your message sequence including t= he request for an update of MSD? >> >> The prior approach was able to send the MSD on the response to the=20 >> INFO that requested it, Or to send it attached to some message=20 >> following that request. IIUC, in your approach here there will first be = a response to the INFO request (no body) followed by another INFO in the ot= her direction of the form you show here. > > Correct. Formally we would be using an info package to carry the MSD, so = the RFC 6086 rules apply (read: we only send MSD in INFO requests). > >> Presupposing that all this was valid, would it still be valid for UA to = send some unsolicited message in the dialog (e.g., UPDATE) with an MSD as a= dditional-data? > > I think is a separate question, not related to the INFO usage. But, to an= swer your question: in my opinion, if you are sending an UPDATE for whateve= r valid reason, I think it is ok to include MSD as additional-data. But, I= don't think one should send UPDATE just for the purpose of conveying MSD -= for that one should use INFO. I agree it is a separate question. IIUC UPDATE may be used as a noop, good for testing the liveness of the pat= h and the other end, better in some respects than OPTIONS. If somebody choo= ses to use one to attach something, I probably wouldn't object. Certainly w= hen judging this from a black box perspective you can't know *why* the OPTI= ONS was sent. In the particular case of MSD, if it can either be sent with = INFO as you propose, or with UPDATE, then I would probably recommend INFO. Thanks, Paul _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From nobody Sat Sep 3 08:06:40 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A915712D504 for ; Sat, 3 Sep 2016 08:06:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 kIcc2PKEkBbF for ; Sat, 3 Sep 2016 08:06:38 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A49AA12D1ED for ; Sat, 3 Sep 2016 08:06:37 -0700 (PDT) X-AuditID: c1b4fb25-8bfff70000001071-77-57cae6fb8fef Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by (Symantec Mail Security) with SMTP id AC.6D.04209.BF6EAC75; Sat, 3 Sep 2016 17:06:35 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.211]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0301.000; Sat, 3 Sep 2016 17:06:34 +0200 From: Christer Holmberg To: "Drage, Keith (Nokia - GB)" , Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Using an INFO package in draft-ietf-ecrit-ecall-11 - Christer's compromise proposal Thread-Index: AQHSBC5ftgmMQ/YNK0CJFiBqGyMrZaBkp60AgAAhu3D//+drAIAAIiHg///8hoCAAsaDIIAASi0Q Date: Sat, 3 Sep 2016 15:06:34 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BC83CAE@ESESSMB209.ericsson.se> References: <8d1e594c-b218-73fa-01cb-4012b9268b2b@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4BC7F7EF@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BC7FBEE@ESESSMB209.ericsson.se> <39f9c421-30a8-b55b-ff9f-5e3cd6f8138a@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8BADF61092@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADF61092@FR712WXCHMBA11.zeu.alcatel-lucent.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+NgFvrDLMWRmVeSWpSXmKPExsUyM2J7uO7vZ6fCDdYuNbLYsOU4i8WKDQdY Lb7+2MTmwOzx9/0HJo8lS34yedy9dYkpgDmKyyYlNSezLLVI3y6BK+PhlGOMBf0KFTNerWJt YLwl2cXIySEhYCLx6uZc1i5GLg4hgfWMEn/PrmOBcBYzSjz6tJGti5GDg03AQqL7nzZIXESg jVFix9pdLCDdwgI5Eot3vGcGsUUEciXuHXvBBGFHSRw8fgQsziKgInGu+ReYzSvgKzFh5ks2 iAXbmSU+/NvICJLgFIiVONbRzApiMwqISXw/tQZsELOAuMStJ/OZIE4VkFiy5zwzhC0q8fLx P1YIW0li0e3PUPU6Egt2f2KDsLUlli18DbVYUOLkzCcsExhFZiEZOwtJyywkLbOQtCxgZFnF KFqcWpyUm25krJdalJlcXJyfp5eXWrKJERgnB7f8Vt3BePmN4yFGAQ5GJR7eB60nw4VYE8uK K3MPMUpwMCuJ8L69dypciDclsbIqtSg/vqg0J7X4EKM0B4uSOK//S8VwIYH0xJLU7NTUgtQi mCwTB6dUA6PurleqInyZ2zV27hSwX5Oom7LlXcwU7ZeMrPv1jp865de/84br61kucTumH+T9 Kaja5NkrMVWcxXRKvsBNdv4jh3JVE8pWp3+JTGK6VbYuruMwr+oFtSls13LU1lSf/PNB9Pfp FqHaqZse/Hmf45Zy8cavHRPZJ8bbthaGZh75JuF0s7es+pASS3FGoqEWc1FxIgA0hPYrjwIA AA== Archived-At: Subject: Re: [sipcore] Using an INFO package in draft-ietf-ecrit-ecall-11 - Christer's compromise proposal X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Sep 2016 15:06:40 -0000 Hi, >From my perspective I don't think we can call this a compromise until we u= nderstand what the proposal requires in the error situations. So what happe= ns at the recipient >when: > >- a Call-Info is not included in the INFO request >- an invalid Call-Info (i.e. pointing to some non-existent data element) i= s included in the INFO request >- a Call-Info is included that point to data associated with some other us= age, but none included for the ecrit data. > > In my view in all these cases the Info package data has been validly tran= sferred. Is this the understanding in the proposal? Yes. I guess I should have made that more clear. In my proposal, we are using an Info Package to transfer the MSD, and the s= emantics etc are according to the info package specification. The Call-Info= etc is there for "convenience", for those who want/need it. So, when it comes to draft-ecall-11, the biggest change is to make sure tha= t the text talks about "using the info package mechanism" instead of "using= the Additional Data mechanism". The info package specification would then = state that the Call-Info etc can be included for convenience, but that they= don't overwrite the semantics etc associated with the info package. Regards, Christer -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: 01 September 2016 19:15 To: Christer Holmberg; sipcore@ietf.org Subject: Re: [sipcore] Using an INFO package in draft-ietf-ecrit-ecall-11 -= Christer's compromise proposal OK, we are largely in agreement here. One comment inline. On 9/1/16 12:32 PM, Christer Holmberg wrote: > Hi, > >>>> Your example is incomplete (e.g., multipart is specified but only=20 >>>> one body part is shown), and I hesitate to comment without first seein= g exactly what you mean. Can >you please provide a complete example? >>> >>> My example shows an INFO only carrying MSD, so it is no incomplete. >> >> Oh, sorry. I misunderstood what you were doing. >> >> Yes, this is very much in the spirit of what Dale suggested. I think it = is simply a degenerate form of it. IMO this is a valid combination of INFO = and call-info. > > Correct. My suggestion will mostly impact how we document everything. > >> So, using this approach, what would be your message sequence including t= he request for an update of MSD? >> >> The prior approach was able to send the MSD on the response to the=20 >> INFO that requested it, Or to send it attached to some message=20 >> following that request. IIUC, in your approach here there will first be = a response to the INFO request (no body) followed by another INFO in the ot= her direction of the form you show here. > > Correct. Formally we would be using an info package to carry the MSD, so = the RFC 6086 rules apply (read: we only send MSD in INFO requests). > >> Presupposing that all this was valid, would it still be valid for UA to = send some unsolicited message in the dialog (e.g., UPDATE) with an MSD as a= dditional-data? > > I think is a separate question, not related to the INFO usage. But, to an= swer your question: in my opinion, if you are sending an UPDATE for whateve= r valid reason, I think it is ok to include MSD as additional-data. But, I= don't think one should send UPDATE just for the purpose of conveying MSD -= for that one should use INFO. I agree it is a separate question. IIUC UPDATE may be used as a noop, good for testing the liveness of the pat= h and the other end, better in some respects than OPTIONS. If somebody choo= ses to use one to attach something, I probably wouldn't object. Certainly w= hen judging this from a black box perspective you can't know *why* the OPTI= ONS was sent. In the particular case of MSD, if it can either be sent with = INFO as you propose, or with UPDATE, then I would probably recommend INFO. Thanks, Paul _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From nobody Sun Sep 4 09:17:27 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDA5E12B259 for ; Sun, 4 Sep 2016 09:17:24 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -3.407 X-Spam-Level: X-Spam-Status: No, score=-3.407 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.508, WEIRD_PORT=0.001] autolearn=ham autolearn_force=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 k3u1spK2W877 for ; Sun, 4 Sep 2016 09:17:23 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id D146412B255 for ; Sun, 4 Sep 2016 09:17:22 -0700 (PDT) Received: from [100.44.92.128] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Sun, 4 Sep 2016 09:17:16 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <878tvk77k8.fsf@hobgoblin.ariadne.com> References: <878tvk77k8.fsf@hobgoblin.ariadne.com> X-Mailer: Eudora for Mac OS X Date: Sun, 4 Sep 2016 09:17:13 -0700 To: worley@ariadne.com (Dale R. Worley), sipcore@ietf.org From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 Archived-At: Subject: Re: [sipcore] Can an INFO contain a body related to, but not part of the INFO package? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Sep 2016 16:17:25 -0000 At 7:27 PM -0400 8/25/16, Dale R. Worley wrote: > BTW, what is the name of the draft in question? As far as I can tell, > it's draft-ietf-ecrit-ecall-11. Yes, that's correct. > Why do the example INFO requests in > that draft not have Info-Package headers, even though those are central > to the interpretation of an info package INFO request? Thanks for pointing this out. I'll fix it in the next revision. > > As I understand it: > > RFC 6086 allows an Info Package INFO request to contain the info package > data as either the entire message body, or as one part of a multipart > body. Which one applies is determined by the placement of a > "Content-Disposition: Info-Package" header, either in the message > headers or the headers of one part of the multipart body. The info > package part may itself be a multipart type. > > Any additional body parts of the multipart case SHOULD NOT be data that > is intrinsically associated with the data of the info package. The > words "not specifically associated with the INFO method and the > application concerned" aren't quite what one means, since the data is > *always* associated with "the application concerned" in some way. The > critical thing is that the data is not specifically associated with the > particular info package of this INFO request. That's my understanding as well. > > In ecrit communications, the callee can send an INFO info package > request which requests the caller and the transit networks to resend the > RFC 7852 Additional Data. That stimulates the caller to send an INFO > request for an info package (seemingly) called "ACK". The ACK info > package acknowledges that the caller has processed the Additional Data > refresh request. Also, the caller attaches to the INFO request its > current Additional Data. And the transit networks attach to the INFO > request their current Additional Data. The mechanism permits the PSAP (the callee) to request that the vehicle (the caller) send an updated MSD, which is RFC 7852 Additional Data. There is no mechanism to request that service providers or access networks resend their RFC 7852 Additional Data, and there is no expectation that service providers or access networks send updated data. The INFO package has associated data which can contain either a request or an ack. The package is currently called 'emergencyCallData.eCall.MSD' but might be renamed to something more generic, such as 'emergencyCallData.control' > > The question is, How is the updated Additional Data to be attached to > the INFO request? One choice is that it is attached as described in RFC > 7852, in the same way that it is attached to the INVITE request, as > additional body parts pointed to by Call-Info headers. The other choice > is that it is incorporated into the ACK info package. Yes, that is the choice. > > An additional question: It is clear how the caller detects that it must > resend its Additional Data. But how do the transit networks detect that > they must resend their Additional Data? Must they scan all transiting > INFO requests for use of the ACK info package? I suppose that only > requests to urn:service:sos:* URIs need be scanned. Transit networks do not resend their data, so there is no requirement nor expectation that they monitor INFO requests. > > The advantage of attaching the Additional Data in the RFC 7852 manner is > that the mechanism is already defined, and its implementation is already > required. > > The advantage of attaching the Additional Data as part of the ACK info > package is that it conforms to RFC 6086, since the Additional Data is > specifically intended to be attached to that INFO request, not just some > caller's request chosen at random within the dialog. > > Note: Suppose we define the ACK info package to *only* acknowledge > receiving and processing the request for resend, but allow the caller to > attach the Additional Data to any request it chooses. E.g., the caller > could send an UPDATE carrying the Additional Data followed by an INFO > informing the callee that it had resent the data. Then the Additional > Data would not be *part of* the ACK info package data and the RFC 7852 > method would not contravene RFC 6086 -- even if the caller *just > happened* to always attach the Additional Data to the INFO for the ACK > package. Exactly. That's the proposal floated by the authors a couple weeks ago. > > Or we could do it *both ways* at the *same time*... That's the proposal that Christer also sent to the list a few days ago. > > Here is an example INFO requesting resending the ecrit data, taken from > draft-ietf-ecrit-ecall-11. I've added "Info-Package: > emergencyCallData.eCall.MSD". > > INFO sip:+13145551111@example.com SIP/2.0 > To: ;tag=9fxced76sl > From: Exemplar PSAP > Call-ID: 3848276298220188511@atlanta.example.com > Call-Info: cid:3456789012@atlanta.example.com; > purpose=emergencyCallData.eCall.control; > Accept: application/sdp, application/pidf+xml, > application/emergencyCallData.eCall.control+xml, > application/emergencyCallData.eCall.MSD+per > CSeq: 41862 INFO > Info-Package: emergencyCallData.eCall.MSD > Recv-Info: emergencyCallData.eCall.MSD > Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, > SUBSCRIBE, NOTIFY, UPDATE > Content-Type: application/EmergencyCallData.eCall.control+xml > Content-ID: 3456789012@atlanta.example.com > Content-Disposition: info-package > > > xmlns="urn:ietf:params:xml:ns:EmergencyCallData:eCall:control" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation= > "urn:ietf:params:xml:ns:EmergencyCallData:eCall:control"> > > > > > > Here is the response INFO request that I propose, made by inserting the > Additional Data from an example in RFC 7852 to the response INFO request > in the draft: > > INFO urn:service:sos.ecall.automatic SIP/2.0 > To: urn:service:sos.ecall.automatic > From: ;tag=9fxced76sl > Call-ID: 3848276298220188511@atlanta.example.com > Call-Info: cid:4567890123@atlanta.example.com; > purpose=emergencyCallData.eCall.MSD; > Call-Info: > ;purpose=icon, > ;purpose=info, > > ;purpose=EmergencyCallData.ProviderInfo, > > ;purpose=EmergencyCallData.DeviceInfo > Geolocation: > Geolocation-Routing: yes > Accept: application/sdp, application/pidf+xml, > application/emergencyCallData.eCall.control+xml > CSeq: 51862 INFO > Info-Package: emergencyCallData.eCall.MSD > Recv-Info: emergencyCallData.eCall.MSD > Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, > SUBSCRIBE, NOTIFY, UPDATE > Content-Disposition: info-package > Content-Transfer-Encoding: binary > Content-Type: multipart/mixed; boundary=boundary1 > Content-Length: ... > > --boundary1 > Content-Type: application/emergencyCallData.eCall.MSD+per > Content-ID: 4567890123@atlanta.example.com > > ...MSD in ASN.1 PER encoding goes here... > > --boundary1 > Content-Type: application/EmergencyCallData.DeviceInfo+xml > Content-ID: <0123456789@atlanta.example.com> > Content-Disposition: by-reference;handling=optional > > > xmlns:dev= > "urn:ietf:params:xml:ns:EmergencyCallData:DeviceInfo"> > ... > > > --boundary1 > Content-Type: application/EmergencyCallData.ProviderInfo+xml > Content-ID: <1234567890@atlanta.example.com> > Content-Disposition: by-reference;handling=optional > > > xmlns:pi= > "urn:ietf:params:xml:ns:EmergencyCallData:ProviderInfo"> > ... > > --boundary1-- > > The point here is that the emergencyCallData.eCall.MSD info package is > defined to allow a multipart body and the body of this request is one > such. One part of the body is the > application/emergencyCallData.eCall.MSD+per, which presumably carries > the ACK semantics, and zero or more parts are > application/EmergencyCallData.ProviderInfo+xml, which carry the > Additional Data. This structure conforms to RFC 6086. (The Call-Info > headers that point to external resources are OK because they do not > involve additional body parts.) > > The application/EmergencyCallData.ProviderInfo+xml parts are pointed to > by Call-Info headers, conforming to RFC 7852. > > Note that the logic that inserts a > application/EmergencyCallData.ProviderInfo+xml part into the multipart > body which is the emergencyCallData.eCall.MSD info package is the same > as the logic which inserts such a part into an ecrit INVITE. Yes. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- A logician saves the life of a space alien and is rewarded with an offer to answer any question. After a thought he asks: What is the best question to ask and the correct answer to it? After a brief panic the alien consults her computer and says: The best question to ask is the one you just did and the correct answer to it is the one I gave. From nobody Mon Sep 5 12:06:22 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6470D12B08F for ; Mon, 5 Sep 2016 12:06:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.035 X-Spam-Level: X-Spam-Status: No, score=-0.035 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 APRkPmbBhxMA for ; Mon, 5 Sep 2016 12:06:07 -0700 (PDT) Received: from resqmta-ch2-12v.sys.comcast.net (resqmta-ch2-12v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9748612B029 for ; Mon, 5 Sep 2016 12:05:59 -0700 (PDT) Received: from resomta-ch2-15v.sys.comcast.net ([69.252.207.111]) by resqmta-ch2-12v.sys.comcast.net with SMTP id gzCub1yxqxBKTgzDRbtZBp; Mon, 05 Sep 2016 19:05:57 +0000 Received: from hobgoblin.ariadne.com ([73.100.16.189]) by resomta-ch2-15v.sys.comcast.net with SMTP id gzDPboSG1kiRvgzDQbKuAP; Mon, 05 Sep 2016 19:05:57 +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 u85J5t6K010631; Mon, 5 Sep 2016 15:05:55 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u85J5twS010628; Mon, 5 Sep 2016 15:05:55 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Randall Gellens In-Reply-To: (rg+ietf@randy.pensive.org) Sender: worley@ariadne.com (Dale R. Worley) Date: Mon, 05 Sep 2016 15:05:55 -0400 Message-ID: <87fupe4164.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfHdqoIKFV6+iBI/y2y8lNgkDwGr2FLSp4/K1VNCBoMemKHzzQSqcOVJ5WKFwq+ubh4Ju8KIUrYLjDNE7b2SZp3p7zleKXGD07A+xDU6xWX1LLh0ZBY9+ 97iBMPYm7qEtZk1HyDd6i5EfhbPaf8684sJBttPS93GbKikuKPO5D35+pZf/2eBcqUUyuucpn8gfWldnQ14zJ84ImtUsy50lhrU= Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] Can an INFO contain a body related to, but not part of the INFO package? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Sep 2016 19:06:21 -0000 Randall Gellens writes: > The mechanism permits the PSAP (the callee) to request that the > vehicle (the caller) send an updated MSD, which is RFC 7852 > Additional Data. There is no mechanism to request that service > providers or access networks resend their RFC 7852 Additional Data, > and there is no expectation that service providers or access networks > send updated data. (There may have been other statements of this principle.) That clears up that question of mine. Dale From nobody Mon Sep 19 11:42:42 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2259212B4DC for ; Mon, 19 Sep 2016 11:42:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.565 X-Spam-Level: X-Spam-Status: No, score=0.565 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665, TO_NO_BRKTS_PCNT=2.499] autolearn=no autolearn_force=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 mAzSSxT-vbOS for ; Mon, 19 Sep 2016 11:42:40 -0700 (PDT) Received: from resqmta-po-07v.sys.comcast.net (resqmta-po-07v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:166]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7D1312B4DA for ; Mon, 19 Sep 2016 11:42:39 -0700 (PDT) Received: from resomta-po-20v.sys.comcast.net ([96.114.154.244]) by resqmta-po-07v.sys.comcast.net with SMTP id m3W9bMkrcqbrLm3WZb0Gyq; Mon, 19 Sep 2016 18:42:39 +0000 Received: from hobgoblin.ariadne.com ([73.100.16.189]) by resomta-po-20v.sys.comcast.net with SMTP id m3WXbrJvZbEgpm3WYbuouL; Mon, 19 Sep 2016 18:42:39 +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 u8JIgbBj000974 for ; Mon, 19 Sep 2016 14:42:37 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u8JIgbc9000970; Mon, 19 Sep 2016 14:42:37 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: sipcore@ietf.org Sender: worley@ariadne.com (Dale R. Worley) Date: Mon, 19 Sep 2016 14:42:36 -0400 Message-ID: <87wpi7loir.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfH+F2Eb/86TJ938cvfpCUeTUl9NdfBwKDYWyIuCxb93gFReS3NKd5YWRaoS4BzDL1T005ZDR7BYupZN+JlJg5a2NShx7zhi1mTkZcbEMrfSdTiMrUomT SLmIjnmsYEgZXvgYFIYkEjn2cNdGz7Tii8L1/gDySfuutPOnO5C7L6dM66LfXOy7KgYig/PWs5FbBw== Archived-At: Subject: [sipcore] Call recovery X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2016 18:42:41 -0000 I talked to some people at SIPit about "call recovery", that is, how to resume a call when the interface through which the signaling and media are passing becomes unusable, but another interface is usable. (There is also the easier "make before break" case, when the old interface remains usable during the process of moving the call to the new interface, but it can be solved by any method that works for the "break before make" case.) It seems that the common method for call recovery is to send a re-INVITE for the dialog giving the address of the new interface as the local target URI. The limitation of re-INVITE is that it cannot change the route set, and so it requires that the first URI of the route set can be used as a single-hop address from the new interface. In general, there is a concern that the first route set URI may be an internal proxy in the carrier, and if the two interfaces attach to two last-mile carriers, that proxy may not be accessible from the new interface. Indeed, its URI may not be properly interpretable from the new interface. It seems to me that a better alternative is to send an INVITE-with-Replaces from the new interface to the remote target URI of dialog. This is effectively a consultative transfer to the new interface and changes the Call-Id. In order for this to work: The remote target is either the other endpoint of the call, or the first SBC in the signaling path. The remote target must support INVITE-with-Replaces. However, because INV/Rep is used to implement consultative transfers, it seems that essentially all remote targets must support it. According to the SIPit 31 summary, 72% of endpoints support replaces. (Presumably the support level for mature products in the market is higher.) In any case, the UA should learn during call setup whether the remote target supports INV/Rep via the "Supported: replaces" header. The remote target needs to act like a GRUU. Of necessity, the remote target reaches a UA that has access to the state of the dialog, but in addition, it needs to be globally routable. The executing UA should be able to determine whether the remote target is a GRUU by looking for the gr URI parameter. If the remote target is the other endpoint, the support for GRUU is weak. The SIPit 31 summary shows only 28% of the endpoints supporting GRUU. OTOH, 67% of proxies provide GRUU support. More likely, the remote target will be a B2BUA in a carrier network. In principle, it should be fairly easy for all first-hop B2BUAs to provide GRUU target URIs, but it adds another element of network engineering. Comments? Dale From nobody Tue Sep 20 13:52:24 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AC1712B991 for ; Tue, 20 Sep 2016 13:52:23 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 U5DcVtwld3bU for ; Tue, 20 Sep 2016 13:52:21 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DDE112B528 for ; Tue, 20 Sep 2016 13:52:20 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id w84so156350406wmg.1 for ; Tue, 20 Sep 2016 13:52:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=B3moDdffOMRPDmqmExqX5tWGDLjSCN4C/qN/12bswr0=; b=UfDvTriBqU97f25OewBgZbXNhoH6WYr2/8GBBjExzc+7A1GwdRyyCaXwtFmVktdFqf nRbOe3QGaUda5T1V7HI0VEudtQA7eGyqxRmUFCcZUqeAXQsUNKe5+mLHy/9TCTJBjNR8 bENYWU5QBvNf1DrT4sanq/qeEzRD/4WlkgTuHLh93bXPuKfb2l1ddeE5VXEJvDHzzcA2 b+b4UyeNC+IM3YU5qm6rYqJkgtgsnER4Q30+WrHsD3mh8npeBJxFjtfXwRRr1yDCOvAA J7NlxjhyxEf3vCKz3x5jiTE5BFDsc/AVGqI/cMoQVuUUhsXVVXJ2dAhXQnhvL6A7gJik KQwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=B3moDdffOMRPDmqmExqX5tWGDLjSCN4C/qN/12bswr0=; b=gBY4f6L3H7FI/n/Pqeu+a1XUVoP0lBLSmNdWL3EeZms9DGR+qfoOojThz9XcRVkAZa Vt8aM57mxzu/qusz15CxHQCTlXaniU0aKEtZ55p7hVr5DHB92jb6cIdP5Aeos2jBgbpw iukCvbTR7MhJriFGMUj5R0tST9n38wmv+TbVfSpbM1+zYcF2EoevdssYiv8jTFrDpOw5 OvXYzKHSQO+UgzB4GkCsPh5XTeUsxG6Yk+71aaMPYPuUHOG0DdVD/g29rUpjqgEhv1MQ bOWBSo0WwmaZvHM0c5aKLiSCK9sGEaZ6nSf2LIaIjZRCJJhaq6DfxluRsko8xnwZtVeW RwhQ== X-Gm-Message-State: AE9vXwPN8E0KYY8VJaFjxAv+I14dbWaAT05fkIWOXL1PTHPssroojZXK1+lRtnorcHUhr3KAsnw1sTf4uFndVA== X-Received: by 10.28.216.211 with SMTP id p202mr4701063wmg.85.1474404738821; Tue, 20 Sep 2016 13:52:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.114.194 with HTTP; Tue, 20 Sep 2016 13:52:18 -0700 (PDT) In-Reply-To: <87wpi7loir.fsf@hobgoblin.ariadne.com> References: <87wpi7loir.fsf@hobgoblin.ariadne.com> From: Ranjit Avasarala Date: Tue, 20 Sep 2016 15:52:18 -0500 Message-ID: To: "Dale R. Worley" Content-Type: multipart/alternative; boundary=001a1147127cb67500053cf69acf Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] Call recovery X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2016 20:52:23 -0000 --001a1147127cb67500053cf69acf Content-Type: text/plain; charset=UTF-8 I think by interfaces being unusable, you mean the interfaces are down? in that case if there is no response for the requests - after timeout the call ends. so how do you recover the call? I think we can max establish the call again once interfaces are up. Correct me if I am missing something Thanks Ranjit On Mon, Sep 19, 2016 at 1:42 PM, Dale R. Worley wrote: > I talked to some people at SIPit about "call recovery", that is, how to > resume a call when the interface through which the signaling and media > are passing becomes unusable, but another interface is usable. > > (There is also the easier "make before break" case, when the old > interface remains usable during the process of moving the call to the > new interface, but it can be solved by any method that works for the > "break before make" case.) > > It seems that the common method for call recovery is to send a re-INVITE > for the dialog giving the address of the new interface as the local > target URI. The limitation of re-INVITE is that it cannot change the > route set, and so it requires that the first URI of the route set can be > used as a single-hop address from the new interface. In general, there > is a concern that the first route set URI may be an internal proxy in > the carrier, and if the two interfaces attach to two last-mile carriers, > that proxy may not be accessible from the new interface. Indeed, its > URI may not be properly interpretable from the new interface. > > It seems to me that a better alternative is to send an > INVITE-with-Replaces from the new interface to the remote target URI of > dialog. This is effectively a consultative transfer to the new > interface and changes the Call-Id. In order for this to work: > > The remote target is either the other endpoint of the call, or the > first SBC in the signaling path. > > The remote target must support INVITE-with-Replaces. However, because > INV/Rep is used to implement consultative transfers, it seems that > essentially all remote targets must support it. > > According to the SIPit 31 summary, 72% of endpoints support replaces. > (Presumably the support level for mature products in the market is > higher.) > > In any case, the UA should learn during call setup whether the remote > target supports INV/Rep via the "Supported: replaces" header. > > The remote target needs to act like a GRUU. Of necessity, the remote > target reaches a UA that has access to the state of the dialog, but in > addition, it needs to be globally routable. The executing UA should be > able to determine whether the remote target is a GRUU by looking for the > gr URI parameter. > > If the remote target is the other endpoint, the support for GRUU is > weak. The SIPit 31 summary shows only 28% of the endpoints supporting > GRUU. OTOH, 67% of proxies provide GRUU support. > > More likely, the remote target will be a B2BUA in a carrier network. In > principle, it should be fairly easy for all first-hop B2BUAs to provide > GRUU target URIs, but it adds another element of network engineering. > > Comments? > > Dale > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --001a1147127cb67500053cf69acf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think by interfaces being unusable, you m= ean the interfaces are down? in that case if there is no response for the r= equests - after timeout the call ends. so how do you recover the call?=C2= =A0 I think we can max establish the call again once interfaces are up.
=
Correct me if I am missing something

Thanks
Ranjit

On Mon, Sep 19, 2016 at 1:42 PM, Dale R. Worley <worley@ariadne.com&= gt; wrote:
I talked to some people= at SIPit about "call recovery", that is, how to
resume a call when the interface through which the signaling and media
are passing becomes unusable, but another interface is usable.

(There is also the easier "make before break" case, when the old<= br> interface remains usable during the process of moving the call to the
new interface, but it can be solved by any method that works for the
"break before make" case.)

It seems that the common method for call recovery is to send a re-INVITE for the dialog giving the address of the new interface as the local
target URI.=C2=A0 The limitation of re-INVITE is that it cannot change the<= br> route set, and so it requires that the first URI of the route set can be used as a single-hop address from the new interface.=C2=A0 In general, ther= e
is a concern that the first route set URI may be an internal proxy in
the carrier, and if the two interfaces attach to two last-mile carriers, that proxy may not be accessible from the new interface.=C2=A0 Indeed, its<= br> URI may not be properly interpretable from the new interface.

It seems to me that a better alternative is to send an
INVITE-with-Replaces from the new interface to the remote target URI of
dialog.=C2=A0 This is effectively a consultative transfer to the new
interface and changes the Call-Id.=C2=A0 In order for this to work:

The remote target is either the other endpoint of the call, or the
first SBC in the signaling path.

The remote target must support INVITE-with-Replaces.=C2=A0 However, because=
INV/Rep is used to implement consultative transfers, it seems that
essentially all remote targets must support it.

According to the SIPit 31 summary, 72% of endpoints support replaces.
(Presumably the support level for mature products in the market is
higher.)

In any case, the UA should learn during call setup whether the remote
target supports INV/Rep via the "Supported: replaces" header.

The remote target needs to act like a GRUU.=C2=A0 Of necessity, the remote<= br> target reaches a UA that has access to the state of the dialog, but in
addition, it needs to be globally routable.=C2=A0 The executing UA should b= e
able to determine whether the remote target is a GRUU by looking for the gr URI parameter.

If the remote target is the other endpoint, the support for GRUU is
weak.=C2=A0 The SIPit 31 summary shows only 28% of the endpoints supporting=
GRUU.=C2=A0 OTOH, 67% of proxies provide GRUU support.

More likely, the remote target will be a B2BUA in a carrier network.=C2=A0 = In
principle, it should be fairly easy for all first-hop B2BUAs to provide
GRUU target URIs, but it adds another element of network engineering.

Comments?

Dale

_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore<= br>

--001a1147127cb67500053cf69acf-- From nobody Tue Sep 20 21:06:45 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC53512B566 for ; Tue, 20 Sep 2016 21:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 LoY8M6zsz9aO for ; Tue, 20 Sep 2016 21:05:51 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABFF812B550 for ; Tue, 20 Sep 2016 21:05:50 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id CFA61F9A5577E; Wed, 21 Sep 2016 04:05:47 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u8L45mHI019228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 Sep 2016 04:05:48 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u8L45mfS023086 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 21 Sep 2016 06:05:48 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.150]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0301.000; Wed, 21 Sep 2016 06:05:48 +0200 From: "Drage, Keith (Nokia - GB)" To: "Dale R. Worley" , "sipcore@ietf.org" Thread-Topic: [sipcore] Call recovery Thread-Index: AQHSEqWfeoDtssaprUiWbZYoqxqusKCCZNoQ Date: Wed, 21 Sep 2016 04:05:47 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADF80091@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <87wpi7loir.fsf@hobgoblin.ariadne.com> In-Reply-To: <87wpi7loir.fsf@hobgoblin.ariadne.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sipcore] Call recovery X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2016 04:06:29 -0000 If you want to follow this through, I suggest you look at 3GPP TS 24.237, w= here the scope is to replace a SIP connection where IP has disappeared, wit= h a CS connection, and other variants. (You may need to reference 3GPP TS 2= 3.237 for some architectural support). Keith -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Dale R. Worley Sent: 19 September 2016 19:43 To: sipcore@ietf.org Subject: [sipcore] Call recovery I talked to some people at SIPit about "call recovery", that is, how to res= ume a call when the interface through which the signaling and media are pas= sing becomes unusable, but another interface is usable. (There is also the easier "make before break" case, when the old interface = remains usable during the process of moving the call to the new interface, = but it can be solved by any method that works for the "break before make" c= ase.) It seems that the common method for call recovery is to send a re-INVITE fo= r the dialog giving the address of the new interface as the local target UR= I. The limitation of re-INVITE is that it cannot change the route set, and= so it requires that the first URI of the route set can be used as a single= -hop address from the new interface. In general, there is a concern that t= he first route set URI may be an internal proxy in the carrier, and if the = two interfaces attach to two last-mile carriers, that proxy may not be acce= ssible from the new interface. Indeed, its URI may not be properly interpr= etable from the new interface. It seems to me that a better alternative is to send an INVITE-with-Replaces= from the new interface to the remote target URI of dialog. This is effect= ively a consultative transfer to the new interface and changes the Call-Id.= In order for this to work: The remote target is either the other endpoint of the call, or the first SB= C in the signaling path. The remote target must support INVITE-with-Replaces. However, because INV/= Rep is used to implement consultative transfers, it seems that essentially = all remote targets must support it. According to the SIPit 31 summary, 72% of endpoints support replaces. (Presumably the support level for mature products in the market is higher.) In any case, the UA should learn during call setup whether the remote targe= t supports INV/Rep via the "Supported: replaces" header. The remote target needs to act like a GRUU. Of necessity, the remote targe= t reaches a UA that has access to the state of the dialog, but in addition,= it needs to be globally routable. The executing UA should be able to dete= rmine whether the remote target is a GRUU by looking for the gr URI paramet= er. If the remote target is the other endpoint, the support for GRUU is weak. = The SIPit 31 summary shows only 28% of the endpoints supporting GRUU. OTOH= , 67% of proxies provide GRUU support. More likely, the remote target will be a B2BUA in a carrier network. In pr= inciple, it should be fairly easy for all first-hop B2BUAs to provide GRUU = target URIs, but it adds another element of network engineering. Comments? Dale _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From nobody Wed Sep 21 05:18:49 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80D1B12B11D for ; Wed, 21 Sep 2016 05:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=broadsoft-com.20150623.gappssmtp.com 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 pz5OqFF3IFgL for ; Wed, 21 Sep 2016 05:18:46 -0700 (PDT) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 742D912B105 for ; Wed, 21 Sep 2016 05:18:46 -0700 (PDT) Received: by mail-lf0-x22d.google.com with SMTP id g62so38769833lfe.3 for ; Wed, 21 Sep 2016 05:18:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadsoft-com.20150623.gappssmtp.com; s=20150623; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to; bh=WBIhE6rps+UB7ToJKROL6q+9LTl1QaV5xy0gtILDXpU=; b=c1DKkHISXOZ4qg0Y3X7v7IUUI2LTLddrrGZf6GbILtbkIoUtqZqBMEFZa8GQn7+nbv wJODU+MT625NVvcsXSsCFeaNY1vr6ejmfrqHCRibGbRLT0cgzdPJjInCm5we6YT6/YEZ CXmaS4FCg1/JUGmEufgNQoqbncYEvbP92F7VJNwlqw6wRrrj5UsVF46gB12uLEF+QJQ5 FiK9JsRnY0BFnfhRO8EMpUnqD3gm38FWLaqrn9y0g2GOuZZx9NkaPyLZGMkV4wf1OjWj r7sCbGsBiq28Bs3x/A3JarkoP6P6kDHTDtyogTxzXHdLzSTATzawD91hkV+nrbxakVKq Nyow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to; bh=WBIhE6rps+UB7ToJKROL6q+9LTl1QaV5xy0gtILDXpU=; b=MomAieEn6rns7NU1B7RGCyqZ9pV0pZVoZnVXFHElpmUASP+gQUtj9xKeQhDOcdx2hw Nfok1C255E2I2QknuUzhMLgUsGk3sC4jOa37hucVhCpddi/3XAcMHQUQ6G2z3iZ7g1Im +SioX0ld3Vh8J5rg4XmKp4MnaPtXMQFOSfcT2VDC3BFsUtXJ8xvGQkfkdbf/EkcLxnhg ypyrp61XT0ymTChRRCdw3+E/VPd4kECUUFp4SzLwNTG0asqYoky+NPE2PdMA+bhZGyqa lEd5yEXIEiPcrzM2QQbZKSz4hvfiqV/uja0z5/V3irITUnwsWQy7sBxZeMolL/OLS3Mp 4VCw== X-Gm-Message-State: AE9vXwMs1U2xl0w3orVYqTmhLF+ITlt18ekEasir2qjgYYhIkLRLXceB8awGZoc9hJJZUYjQs494gc09YDspci14 X-Received: by 10.46.32.28 with SMTP id g28mr12524548ljg.40.1474460324520; Wed, 21 Sep 2016 05:18:44 -0700 (PDT) From: Brett Tate References: <87wpi7loir.fsf@hobgoblin.ariadne.com> In-Reply-To: <87wpi7loir.fsf@hobgoblin.ariadne.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKpET1o++x7XDR51SnSYzhOwSnDiZ7V04Ng Date: Wed, 21 Sep 2016 08:18:43 -0400 Message-ID: <851cb61e397414137e008c1374eb0727@mail.gmail.com> To: "Dale R. Worley" , sipcore@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [sipcore] Call recovery X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2016 12:18:48 -0000 Hi, > It seems to me that a better alternative is > to send an INVITE-with-Replaces from the new > interface to the remote target URI of dialog. > This is effectively a consultative transfer to > the new interface and changes the Call-Id. > Comments? Repost from sip-implementors... solutions using things like Replaces and REFER raise the typical concerns with authorization, security, billing, et cetera. For instance, see security section of RFC 3891. From nobody Wed Sep 21 07:43:10 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5565212B323 for ; Wed, 21 Sep 2016 07:43:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 T1X1qRf7iwNv for ; Wed, 21 Sep 2016 07:43:07 -0700 (PDT) Received: from resqmta-ch2-10v.sys.comcast.net (resqmta-ch2-10v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 039B412B33E for ; Wed, 21 Sep 2016 07:43:03 -0700 (PDT) Received: from resomta-ch2-19v.sys.comcast.net ([69.252.207.115]) by resqmta-ch2-10v.sys.comcast.net with SMTP id mijKbVVEARingmijnbkFem; Wed, 21 Sep 2016 14:43:03 +0000 Received: from hobgoblin.ariadne.com ([73.100.16.189]) by resomta-ch2-19v.sys.comcast.net with SMTP id mijlbMRpPlRdomijmbYRXq; Wed, 21 Sep 2016 14:43:03 +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 u8LEh1e6020930; Wed, 21 Sep 2016 10:43:01 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u8LEh1x2020927; Wed, 21 Sep 2016 10:43:01 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Ranjit Avasarala In-Reply-To: (ranjitkav0811@gmail.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 21 Sep 2016 10:43:00 -0400 Message-ID: <87a8f1iaa3.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfClzkX2R4uFZYZ50FQvSaApF4GdTv5y0Ka3B5mv7691DW7tnWtwUm2PUwDu2i9peYmu24BfMgAHgzXXNM4BbNoGyrCLFxfUPkyxYq3+SPbLEzMl87QRG ywKLKWL/QOIK9Vo9zHCLaAiAjmtp8q3Il9q3ZWTNBO3dl0OrvdwHVunI8PXmQFNfovrLOUSq9dL6y0XF9ok0V61U9KP4cGpP2Ug= Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] Call recovery X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2016 14:43:08 -0000 Ranjit Avasarala writes: > I think by interfaces being unusable, you mean the interfaces are down? in > that case if there is no response for the requests - after timeout the call > ends. so how do you recover the call? I think we can max establish the > call again once interfaces are up. The situation is where one interface of the UA goes down, but another interface (e.g., a different radio network) is available. The goal is to somehow re-route the call to use the interface that is up, before the call times out. Dale From nobody Wed Sep 21 08:18:18 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C57012B4CE for ; Wed, 21 Sep 2016 08:18:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 8CRFrhNcw2TB for ; Wed, 21 Sep 2016 08:18:15 -0700 (PDT) Received: from resqmta-ch2-03v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE75212B4CC for ; Wed, 21 Sep 2016 08:18:10 -0700 (PDT) Received: from resomta-ch2-04v.sys.comcast.net ([69.252.207.100]) by resqmta-ch2-03v.sys.comcast.net with SMTP id mjHEbRiqe8GkCmjHmb7f9r; Wed, 21 Sep 2016 15:18:10 +0000 Received: from hobgoblin.ariadne.com ([73.100.16.189]) by resomta-ch2-04v.sys.comcast.net with SMTP id mjHkbZYyQVK25mjHlbUTs4; Wed, 21 Sep 2016 15:18: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 u8LFI8iM023486; Wed, 21 Sep 2016 11:18:08 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u8LFI8fZ023483; Wed, 21 Sep 2016 11:18:08 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Brett Tate In-Reply-To: <851cb61e397414137e008c1374eb0727@mail.gmail.com> (brett@broadsoft.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 21 Sep 2016 11:18:08 -0400 Message-ID: <87vaxpgu33.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfGqyDpB20FNch6hZDhgZ29QfAd6P2aUOHN02xb80uH1ysIu1moM+6tJppkYr+/wk+86j1xxuWDBKaYV/4XsPoNK3Ou8lH8Ml21yv+z3t4JkpbqPQBskY IWOZAg99V12H5F2BIpbNTdOLPG5rFLexDzfBdlHrqXgvLaDWjVQPLvLB4u0yF5OXqwRp7Ks5K9OleYLTSG1AJLSx2mhBYfra5rU= Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] Call recovery X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2016 15:18:17 -0000 Brett Tate writes: > Repost from sip-implementors... solutions using things like Replaces and > REFER raise the typical concerns with authorization, security, billing, et > cetera. For instance, see security section of RFC 3891. I don't see authorization as much of a problem, because you can't apply an INVITE-with-Replaces to a call without knowing the INVITE carrying the Call-Id of the call it will affect. As for billing, the INVITE-with-Replaces, in order to work, has to reach the remote target of the original call, which in a typical carrier case, will be some B2BUA inside the carrier of the first leg of the original call. So that carrier doesn't lose the call, and can apply whatever billing policy it wants. (In an ideal world, that B2BUA would just proxy (without Record-Route) the INVITE through to the remote target of the next leg, taking itself out of the call entirely.) Dale From nobody Wed Sep 21 11:05:31 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC8A312B906 for ; Wed, 21 Sep 2016 11:05:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=broadsoft-com.20150623.gappssmtp.com 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 QIIUajUo7aA0 for ; Wed, 21 Sep 2016 11:05:26 -0700 (PDT) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAAC312B8B5 for ; Wed, 21 Sep 2016 11:05:25 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id l131so49243693lfl.2 for ; Wed, 21 Sep 2016 11:05:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadsoft-com.20150623.gappssmtp.com; s=20150623; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to; bh=gPvCioadT0wkspxrVbOHsB3s4RBS6wgRg8acj+dG4Tk=; b=1wt/VAge1Kp93HifmRplo5ahXknYtcTrjZWy7vKBI0MdoejGqeJBhrgpwpH73rBoCZ vuM8HSYJjaggDb3FPm7SuFe1RIyGbbB2L48iFjrHddeH/W5ktLfpaJUjJ0A6Odpqt/mh NpuWFdAR++58+OEs86JVRmb6LIPH49lUJyVSo/Kf4v5whH6cohjnbRJ8SUINDJPV2CGY QJC2nXys7Cpx5m2ZGFDDNsfKnpZiH/EdM4uITENkaVzH59cr3h9naNO5SFqUNWW7EORf M0cMZ3Zqq8aksn/6T34ShUUQnB8Z0KZKnzjWY3SMiGxx29qK9XGFjDnyJxC2ObcEe3Dv 8ORg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to; bh=gPvCioadT0wkspxrVbOHsB3s4RBS6wgRg8acj+dG4Tk=; b=DxPvRjrCCS9F//SO4n3E25o67s4YzdyTdTOk8UyZnwZUBY1E3cTqbXKPzMU/dpY8MJ +RPiK0DR2g6OVUMwI0r7dBnGqiaqW5ixuZzwcKkKaociXevfWJ9kmP3+OxycAv9rYVb9 NqfvbSRClms774M3Xlc2wqEc8X/ZaE7tdViAKY07Qoyvf7bGzARdhXITkxQ+O7sz7lV1 WtAZ46dxROtxvnh1YnqoO4PBT7O5P97pWV2ZogSGxylO0SpOscsppIu6PAAtXSIsHkGR YvvJ9flOw/yrwOZrhSteEoLj18AVj4/Hk/OnvonCYxNYM9dAmy0SXuxn/lCbemyPnpHQ 4N3A== X-Gm-Message-State: AE9vXwNkNJhG2oaPtO/+pngMArH3ek1sa7AiiVrEbkwtNvW/AKd/e8aWHnp1ZkFNxX26lHITUMncWkCxcl7YnKFX X-Received: by 10.46.0.158 with SMTP id e30mr15715959lji.60.1474481123977; Wed, 21 Sep 2016 11:05:23 -0700 (PDT) From: Brett Tate References: <851cb61e397414137e008c1374eb0727@mail.gmail.com> (brett@broadsoft.com) <87vaxpgu33.fsf@hobgoblin.ariadne.com> In-Reply-To: <87vaxpgu33.fsf@hobgoblin.ariadne.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFCk1zWhmNfrAcvKnbP/yeHLPaRCqGjEuLg Date: Wed, 21 Sep 2016 14:05:22 -0400 Message-ID: To: "Dale R. Worley" , sipcore@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [sipcore] Call recovery X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2016 18:05:30 -0000 Hi, > > Repost from sip-implementors... solutions using > > things like Replaces and REFER raise the typical > > concerns with authorization, security, billing, > > et cetera. For instance, see security section of > > RFC 3891. > > I don't see authorization as much of a problem, > because you can't apply an INVITE-with-Replaces to > a call without knowing the INVITE carrying the Call-Id > of the call it will affect. RFC 3891's security section discusses the non-trivial concept of legitimate authorization (and security impacts supporting RFC 3891). > As for billing, the INVITE-with-Replaces, in order > to work, has to reach the remote target of the > original call, which in a typical carrier case, will > be some B2BUA inside the carrier of the first leg of > the original call. So that carrier doesn't lose the > call, and can apply whatever billing policy it wants. That is the potential concern (although potentially irrelevant to IETF). Whoever sends and/or honors the INVITE with Replaces might not find the billing consequences to be acceptable. Thus they couldn't use the solution within some deployments/situations. > (In an ideal world, that B2BUA would just proxy (without > Record-Route) the INVITE through to the remote target > of the next leg, taking itself out of the call entirely.) Although some disagree, the operator/user might find it more ideal to keep the B2BUA within the path. The IMS solution appears to mandate adding Record-Route instead of replacing gruu Contact during call setup. If this means that the Application Server will be bypassed within some situations, it might impact/prevent some types of services provided by the Application Server. From nobody Tue Sep 27 12:09:54 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBC0412B255 for ; Tue, 27 Sep 2016 12:09:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.216 X-Spam-Level: X-Spam-Status: No, score=-4.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.316] autolearn=ham autolearn_force=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 828qWxVqIGRF for ; Tue, 27 Sep 2016 12:09:37 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51B9112B2CE for ; Tue, 27 Sep 2016 12:09:36 -0700 (PDT) Received: from unnumerable.local ([173.57.161.14]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u8RJ9ZFh035431 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK) for ; Tue, 27 Sep 2016 14:09:36 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [173.57.161.14] claimed to be unnumerable.local To: sipcore@ietf.org References: <006207b2b6efec957b88552bddedf60b@mail.gmail.com> From: Robert Sparks Message-ID: <4b4e18c5-92db-3246-119d-3c7ac55a3a42@nostrum.com> Date: Tue, 27 Sep 2016 14:09:35 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <006207b2b6efec957b88552bddedf60b@mail.gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sipcore] draft-sparks-sipcore-name-addr-guidance-00: comments X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2016 19:09:43 -0000 Returning to this thread: On 6/24/16 2:50 PM, Brett Tate wrote: > Hi, > > The following are some comments concerning > draft-sparks-sipcore-name-addr-guidance-00. > > Thanks, > Brett > > ------- > > 1) Abstract: "and at least one header field was missed" can potentially be > removed. The RFC 3261 section 20.31 mandate for Reply-To is the same as > the section 20.20 mandate for From. However, it was missing from the RFC > 3261 section 20 paragraph that this draft is updating. The "was missed" was referring to "To" as discussed in the introduction. > > 2) Section 7: Errata 3744 and 3894 are mentioned; however the draft > doesn't explicitly mention RFC 3325. RFC 3325 potentially should be > mentioned within section 3 (or elsewhere) even if this draft does not need > to update the RFC. We were already updating other Informational documents (5002, 5318 and 5502). After re-reading the threads, I'm convinced adding 3325 is the right thing to do. I've implemented Ben's suggestion for being clear that the update does not affect the updated documents' status. Just to triple-check that we hadn't missed any others, I did some extensive grepping and found these to add: 3892 (Referred-By), and 4508 (which copies the ABNF for Refer) Just to capture the work, the following RFCs contain header syntax, but do _not_ need the update, they avoided the problem by always requiring addr-spec: 3327 (Path), 3608 (Service-Route), 5503 (P-DCS-Trace-Party-ID), 5806 (Diversion), 7044 (History-Info), 7315 (P-Associated-URI, P-Called-Party-ID), 7544 (mapping diversion to history info). In response to other messages about standards track documents updating informational documents, it's happened many times before: rfc5494 updates rfc1329 rfc5494 updates rfc2176 rfc4519 updates rfc2377 rfc3698 updates rfc2798 rfc4519 updates rfc2798 rfc4524 updates rfc2798 rfc5785 updates rfc2818 rfc5080 updates rfc2866 rfc5080 updates rfc2869 rfc3977 updates rfc2980 rfc4643 updates rfc2980 rfc4644 updates rfc2980 rfc6048 updates rfc2980 rfc4112 updates rfc3106 rfc5462 updates rfc3272 rfc5462 updates rfc3469 rfc6233 updates rfc3563 rfc5462 updates rfc3564 rfc5080 updates rfc3579 rfc5462 updates rfc3985 rfc4548 updates rfc4048 rfc5095 updates rfc4294 rfc5246 updates rfc4492 rfc5865 updates rfc4542 rfc5865 updates rfc4594 rfc6309 updates rfc5410 rfc6309 updates rfc6043 rfc6435 updates rfc6371 rfc6672 updates rfc3363 rfc3575 updates rfc2868 rfc6960 updates rfc5912 rfc7268 updates rfc3580 rfc7303 updates rfc6839 rfc7230 updates rfc2818 rfc7274 updates rfc5921 rfc7162 updates rfc2683 rfc7146 updates rfc5047 rfc7146 updates rfc5045 rfc7143 updates rfc3721 rfc7459 updates rfc3693 rfc7852 updates rfc6443 rfc7919 updates rfc4492 > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Tue Sep 27 12:17:54 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F60012B00B for ; Tue, 27 Sep 2016 12:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.215 X-Spam-Level: X-Spam-Status: No, score=-4.215 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-2.316] autolearn=ham autolearn_force=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 gkhczS6z5-FF for ; Tue, 27 Sep 2016 12:17:51 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6C1C12B4A8 for ; Tue, 27 Sep 2016 12:17:50 -0700 (PDT) Received: from unnumerable.local ([173.57.161.14]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u8RJHn3o036627 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK) for ; Tue, 27 Sep 2016 14:17:50 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [173.57.161.14] claimed to be unnumerable.local References: <147500368140.4422.16542069489165716130.idtracker@ietfa.amsl.com> To: "sipcore@ietf.org" From: Robert Sparks X-Forwarded-Message-Id: <147500368140.4422.16542069489165716130.idtracker@ietfa.amsl.com> Message-ID: <8b3e9b2f-3c9d-05eb-9705-74ce7e70ae6d@nostrum.com> Date: Tue, 27 Sep 2016 14:17:49 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <147500368140.4422.16542069489165716130.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------582AD95442BA98A3DB3DBB24" Archived-At: Subject: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-name-addr-guidance-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2016 19:17:53 -0000 This is a multi-part message in MIME format. --------------582AD95442BA98A3DB3DBB24 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit See my recent response on list to Brett for what led to these changes. I think this is ready to go. RjS -------- Forwarded Message -------- Subject: New Version Notification for draft-sparks-sipcore-name-addr-guidance-01.txt Date: Tue, 27 Sep 2016 12:14:41 -0700 From: internet-drafts@ietf.org To: Robert Sparks A new version of I-D, draft-sparks-sipcore-name-addr-guidance-01.txt has been successfully submitted by Robert Sparks and posted to the IETF repository. Name: draft-sparks-sipcore-name-addr-guidance Revision: 01 Title: Clarifications for when to use the name-addr production in SIP messages Document date: 2016-09-27 Group: Individual Submission Pages: 6 URL: https://www.ietf.org/internet-drafts/draft-sparks-sipcore-name-addr-guidance-01.txt Status: https://datatracker.ietf.org/doc/draft-sparks-sipcore-name-addr-guidance/ Htmlized: https://tools.ietf.org/html/draft-sparks-sipcore-name-addr-guidance-01 Diff: https://www.ietf.org/rfcdiff?url2=draft-sparks-sipcore-name-addr-guidance-01 Abstract: RFC3261 constrained several SIP header fields whose grammar contains the "name-addr / addr-spec" alternative to use name-addr when certain characters appear. Unfortunately it expressed the constraints with prose copied into each header field definition, and at least one header field was missed. Further, the constraint has not been copied into documents defining extension headers whose grammar contains the alternative. This document updates RFC3261 to state the constraint generically, and clarifies that the constraint applies to all SIP header fields where there is a choice between using name-addr or addr-spec. It also updates those extension SIP header fields that use the alternative to clarify that the constraint applies (RFCs 3325, 3515, 3892, 4508, 5002, 5318, 5360, and 5502). Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------582AD95442BA98A3DB3DBB24 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

See my recent response on list to Brett for what led to these changes.

I think this is ready to go.

RjS


-------- Forwarded Message --------
Subject: New Version Notification for draft-sparks-sipcore-name-addr-guidance-01.txt
Date: Tue, 27 Sep 2016 12:14:41 -0700
From: internet-drafts@ietf.org
To: Robert Sparks <rjsparks@nostrum.com> 


A new version of I-D, draft-sparks-sipcore-name-addr-guidance-01.txt
has been successfully submitted by Robert Sparks and posted to the
IETF repository.

Name:		draft-sparks-sipcore-name-addr-guidance
Revision:	01
Title:		Clarifications for when to use the name-addr production in SIP messages
Document date:	2016-09-27
Group:		Individual Submission
Pages:		6
URL:            https://www.ietf.org/internet-drafts/draft-sparks-sipcore-name-addr-guidance-01.txt
Status:         https://datatracker.ietf.org/doc/draft-sparks-sipcore-name-addr-guidance/
Htmlized:       https://tools.ietf.org/html/draft-sparks-sipcore-name-addr-guidance-01
Diff:           https://www.ietf.org/rfcdiff?url2=draft-sparks-sipcore-name-addr-guidance-01

Abstract:
   RFC3261 constrained several SIP header fields whose grammar contains
   the "name-addr / addr-spec" alternative to use name-addr when certain
   characters appear.  Unfortunately it expressed the constraints with
   prose copied into each header field definition, and at least one
   header field was missed.  Further, the constraint has not been copied
   into documents defining extension headers whose grammar contains the
   alternative.

   This document updates RFC3261 to state the constraint generically,
   and clarifies that the constraint applies to all SIP header fields
   where there is a choice between using name-addr or addr-spec.  It
   also updates those extension SIP header fields that use the
   alternative to clarify that the constraint applies (RFCs 3325, 3515,
   3892, 4508, 5002, 5318, 5360, and 5502).

                                                                                  


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat
--------------582AD95442BA98A3DB3DBB24-- From nobody Thu Sep 29 12:37:58 2016 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AFCD212B233; Thu, 29 Sep 2016 12:37:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.34.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147517787567.18581.10406975400991485328.idtracker@ietfa.amsl.com> Date: Thu, 29 Sep 2016 12:37:55 -0700 Archived-At: Cc: ben@nostrum.com, aroach@mozilla.com, sipcore@ietf.org, sipcore-chairs@ietf.org Subject: [sipcore] sipcore - Not having a session at IETF 97 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2016 19:37:56 -0000 Adam Roach, a chair of the sipcore working group, indicated that the sipcore working group does not plan to hold a session at IETF 97. This message was generated and sent by the IETF Meeting Session Request Tool. From nobody Thu Sep 29 16:41:55 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ABFA12B3F9; Thu, 29 Sep 2016 16:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.918 X-Spam-Level: X-Spam-Status: No, score=-104.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.316, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=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 G3v2Gr18MCRg; Thu, 29 Sep 2016 16:41:43 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C9C912B358; Thu, 29 Sep 2016 16:41:02 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 04EF5B8111C; Thu, 29 Sep 2016 16:41:02 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20160929234102.04EF5B8111C@rfc-editor.org> Date: Thu, 29 Sep 2016 16:41:02 -0700 (PDT) Archived-At: Cc: drafts-update-ref@iana.org, sipcore@ietf.org, rfc-editor@rfc-editor.org Subject: [sipcore] RFC 7984 on Locating Session Initiation Protocol (SIP) Servers in a Dual-Stack IP Network X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2016 23:41:49 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7984 Title: Locating Session Initiation Protocol (SIP) Servers in a Dual-Stack IP Network Author: O. Johansson, G. Salgueiro, V. Gurbani, D. Worley, Ed. Status: Standards Track Stream: IETF Date: September 2016 Mailbox: oej@edvina.net, gsalguei@cisco.com, vkg@bell-labs.com, worley@ariadne.com Pages: 10 Characters: 21246 Updates: RFC 3263 I-D Tag: draft-ietf-sipcore-dns-dual-stack-08.txt URL: https://www.rfc-editor.org/info/rfc7984 DOI: http://dx.doi.org/10.17487/RFC7984 RFC 3263 defines how a Session Initiation Protocol (SIP) implementation, given a SIP Uniform Resource Identifier (URI), should locate the next-hop SIP server using Domain Name System (DNS) procedures. As SIP networks increasingly transition from IPv4-only to dual-stack, a quality user experience must be ensured for dual- stack SIP implementations. This document updates the DNS procedures described in RFC 3263 for dual-stack SIP implementations in preparation for forthcoming specifications for applying "Happy Eyeballs" principles to SIP. 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 Official Internet Protocol Standards (https://www.rfc-editor.org/standards) 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 https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk 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 Sep 29 17:00:12 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB9712B0A1 for ; Thu, 29 Sep 2016 17:00:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 kJG3t9fHjUmW for ; Thu, 29 Sep 2016 17:00:09 -0700 (PDT) Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E51A12B09C for ; Thu, 29 Sep 2016 17:00:09 -0700 (PDT) Received: from resomta-ch2-03v.sys.comcast.net ([69.252.207.99]) by resqmta-ch2-05v.sys.comcast.net with SMTP id plElbkcAc2FGMplFIbbM5q; Fri, 30 Sep 2016 00:00:08 +0000 Received: from [192.168.1.110] ([73.186.127.100]) by resomta-ch2-03v.sys.comcast.net with SMTP id plFHbbSscCmQXplFIbOSdv; Fri, 30 Sep 2016 00:00:08 +0000 References: <20160929234102.04EF5B8111C@rfc-editor.org> To: SIPCORE From: Paul Kyzivat X-Forwarded-Message-Id: <20160929234102.04EF5B8111C@rfc-editor.org> Message-ID: <76f37cd4-e3ad-3f9a-a131-9884f34315f2@alum.mit.edu> Date: Thu, 29 Sep 2016 20:00:07 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <20160929234102.04EF5B8111C@rfc-editor.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfLxM3vZUhrCGw2irBGE7AHx8OkE6dH/57d1TywyJuwD76pTpbmu+f8w/DKhXb6jJOIxJqlDo/rqs9zT+C7ZgAI5eZhbNlv8gVI2nEwRilx0x2ikQ+GWe 4q1YCTBGakGBY0C/9hX+MP0EeToNlDOCBYQ5CQrbdIxGiFIhrtsFK4ah Archived-At: Subject: Re: [sipcore] RFC 7984 on Locating Session Initiation Protocol (SIP) Servers in a Dual-Stack IP Network X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2016 00:00:11 -0000 Congratulations on getting this finished! -------- Forwarded Message -------- Subject: [sipcore] RFC 7984 on Locating Session Initiation Protocol (SIP) Servers in a Dual-Stack IP Network Date: Thu, 29 Sep 2016 16:41:02 -0700 (PDT) From: rfc-editor@rfc-editor.org To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org CC: drafts-update-ref@iana.org, sipcore@ietf.org, rfc-editor@rfc-editor.org A new Request for Comments is now available in online RFC libraries. RFC 7984 Title: Locating Session Initiation Protocol (SIP) Servers in a Dual-Stack IP Network Author: O. Johansson, G. Salgueiro, V. Gurbani, D. Worley, Ed. Status: Standards Track Stream: IETF Date: September 2016 Mailbox: oej@edvina.net, gsalguei@cisco.com, vkg@bell-labs.com, worley@ariadne.com Pages: 10 Characters: 21246 Updates: RFC 3263 I-D Tag: draft-ietf-sipcore-dns-dual-stack-08.txt URL: https://www.rfc-editor.org/info/rfc7984 DOI: http://dx.doi.org/10.17487/RFC7984 RFC 3263 defines how a Session Initiation Protocol (SIP) implementation, given a SIP Uniform Resource Identifier (URI), should locate the next-hop SIP server using Domain Name System (DNS) procedures. As SIP networks increasingly transition from IPv4-only to dual-stack, a quality user experience must be ensured for dual- stack SIP implementations. This document updates the DNS procedures described in RFC 3263 for dual-stack SIP implementations in preparation for forthcoming specifications for applying "Happy Eyeballs" principles to SIP. 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 Official Internet Protocol Standards (https://www.rfc-editor.org/standards) 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 https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk 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 _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore