From nobody Fri Sep 1 02:15:26 2017 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 73579133280; Fri, 1 Sep 2017 02:15:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sipcore@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.59.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150425731944.4583.15379080239728303339@ietfa.amsl.com> Date: Fri, 01 Sep 2017 02:15:19 -0700 Archived-At: Subject: [sipcore] I-D Action: draft-ietf-sipcore-content-id-09.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2017 09:15:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core WG of the IETF. Title : Content-ID header field in Session Initiation Protocol (SIP) Authors : Christer Holmberg Ivo Sedlacek Filename : draft-ietf-sipcore-content-id-09.txt Pages : 15 Date : 2017-09-01 Abstract: This document specifies the Content-ID header field for usage in the Session Initiation Protocol (SIP). The document also updates RFC 5621, which only allows a Content-ID URL to reference a body part that is part of a multipart message-body. This update enables a Content-ID URL to reference a complete message-body and metadata provided by some additional SIP header fields. This document updates RFC 5368 and RFC 6442, by clarifying their usage of the SIP Content-ID header field. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-content-id/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sipcore-content-id-09 https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-content-id-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-content-id-09 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Sep 1 02:20:55 2017 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 E0DD91320C9; Fri, 1 Sep 2017 02:20:53 -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 xamyqLp0moGu; Fri, 1 Sep 2017 02:20:51 -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 18EF6132E24; Fri, 1 Sep 2017 02:20:50 -0700 (PDT) X-AuditID: c1b4fb25-d31059c000005333-5d-59a926703e53 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 22.F6.21299.07629A95; Fri, 1 Sep 2017 11:20:49 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.194]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0352.000; Fri, 1 Sep 2017 11:20:48 +0200 From: Christer Holmberg To: Ben Campbell CC: Adam Roach , Eric Rescorla , The IESG , "sipcore@ietf.org" , "draft-ietf-sipcore-content-id@ietf.org" , "A. Jean Mahoney" , "sipcore-chairs@ietf.org" Thread-Topic: Draft new version: draft-content-id-09 Thread-Index: AQHTIwOYexi4+wEQX0+AMNxbu0pvpA== Date: Fri, 1 Sep 2017 09:20:47 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.4.170508 x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFIsWRmVeSWpSXmKPExsUyM2K7k26h2spIg3+fuC32/F3EbjG/8zS7 xemvM5gsVrw+x24x489EZouGzpWsFr2fFzJbfP2xic2Bw2PJkp9MHrN2PmHxmPy4jTmAOYrL JiU1J7MstUjfLoErY9LjbYwFnfIVLw+fZW5g/CzRxcjJISFgInFx7mPGLkYuDiGBI4wSJ9d1 sUM4ixkl7lxuY+li5OBgE7CQ6P6nDdIgIqAk8bx5KwuIzSywk0lieYcciC0soC+x50YbK0SN iUT/tF4mCFtPYvPBf2wgNouAisT695PBenkFrCXm/Z8OFmcUEJP4fmoNE8RMcYlbT+YzQRwn ILFkz3lmCFtU4uXjf6wg54gCzXy33xMirCjx8dU+RohWPYkbU6ewQdjWEg3PJ0OdqS2xbOFr Zoi1ghInZz5hmcAoOgvJtllI2mchaZ+FpH0WkvYFjKyrGEWLU4uTctONjPVSizKTi4vz8/Ty Uks2MQJj8OCW36o7GC+/cTzEKMDBqMTDe7V/RaQQa2JZcWXuIUYJDmYlEd6JSisjhXhTEiur Uovy44tKc1KLDzFKc7AoifM67rsQISSQnliSmp2aWpBaBJNl4uCUamC0yjkbZTtLQ94owZnD NiCuTHvileDDs+Rt5X5l+RfJq7Va+nWufx/7sUDwt7lsnrPn0hJO+S0HJL98nzLPx4z/qv2u CW2zBVg/aThz2q5xq+W599Hpomn3qmcCoZM8ZZ+waD2vKvw34/xVv1n7+rpjE1car61an/B7 k8GRXx/ePq75cJlZ7KQSS3FGoqEWc1FxIgBuWSyNvQIAAA== Archived-At: Subject: [sipcore] Draft new version: draft-content-id-09 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2017 09:20:54 -0000 Hi, Based on Ben=B9s comment, we=B9ve submitted a new version (-09) of draft-content-id. Regards, Christer On 01/09/17 00:27, "Ben Campbell" wrote: >Hi, > >I=B9m a little confused by the new text in section 1.6. (Apologies, I >realize that you proposed that text in email, but I somehow missed it at >the time.) > >> 1.6. Backward compatibility >>=20 >> If an existing specification explicitly defines the usage of a >> multipart message-body for carrying a single body part, that >> specification MUST be updated in order to allow usage of a non- >> multipart message-body for carrying the MIME entity, and for >> referencing the whole message-body using a Content-ID URL. >>=20 > > >Is the point of that to simply say that an update must occur, or that >implementations cannot use a non-multipart body unless such an update >occurs? If the former, I suggest dropping the normative language, for >example by replacing =B3MUST be=B2 with =B3should be=B2, since we can=B9t = really >make people update a specification, > >If the latter, I propose the following: > > "If an existing specification only defines the usage of a > multipart message-body for carrying a single body part to be referenced > by a Content-ID URL, , implementations MUST NOT carry the MIME entity > in a non-multipart message-body unless the specification is updated > to explicitly allow it.=B2 > >Ben. > > >> On Aug 31, 2017, at 6:34 AM, Christer Holmberg >> wrote: >>=20 >> Hi, >>=20 >> Based on the IESG reviews, we have submitted a new version (-08) of >>draft-content-id. >>=20 >> Note that we did NOT include any update to RFC 6080, because we >>double-checked the RFC6080 >> usage of Content-ID header field and we believe that: >>=20 >> - RFC6080 does NOT use the *SIP* Content-ID header; and >> - RFC6080 does NOT need to use the *SIP* Content-ID header. >>=20 >> Reasons: >>=20 >> RFC6080 uses Content-ID heaer field as follows: >>=20 >> --------------- >> For profile data delivered via content >> indirection, i.e., a pointer to a PCC, then the Content-ID MIME >> header, as described in [RFC4483], MUST be used for each profile >> document URI. >> --------------- >> and gives example as follows: >> --------------- >> NOTIFY sip:urn%3auuid%3a00000000-0000-1000-0000-00FF8D82EDCB >> @192.168.1.44 SIP/2.0 >> Event: ua-profile;effective-by=3D3600 >> From: sip:urn%3auuid%3a00000000-0000-1000-0000-00FF8D82EDCB@example.com >> ;tag=3Dabca >> To: sip:urn%3auuid%3a00000000-0000-1000-0000-00FF8D82EDCB@example.com >> ;tag=3D1234 >> Call-ID: 3573853342923422@192.0.2.44 >> CSeq: 322 NOTIFY >> Via: SIP/2.0/UDP 192.0.2.3; >> branch=3Dz9hG4bK1e3effada91dc37fd5a0c95cbf6767d0 >> MIME-Version: 1.0 >> Content-Type: message/external-body; access-type=3D"URL"; >> expiration=3D"Mon, 01 Jan 2010 09:00:00 UTC"; >> URL=3D"http://example.com/z100-000000000000.html"; >> size=3D9999; >> hash=3D10AB568E91245681AC1B >>=20 >> Content-Type: application/x-z100-device-profile >> Content-ID: <39EHF78SA@example.com> >> --------------- >>=20 >> The Content-ID header field above is NOT a *SIP* header field since it >>is placed *after* CRLF. >>=20 >> The Content-ID header field above is a part of the message-body. >>=20 >> Since the message-body is of message/external-body MIME type the >>semantic of the Content-ID header field above follows >> RFC2046 section 5.2.3 and RFC4483 section 5.6 - i.e. the Content-ID >>header field above is a MIME header field and is used by >> UAS to determine whether the content fetched from >>http://example.com/z100-000000000000.html has changed between >> UAC sending the SIP NOTIFY message and UAS receiving the SIP NOTIFY >>message. >>=20 >>=20 >> Regards, >>=20 >> Christer > From nobody Fri Sep 1 14:53:43 2017 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 141081345C4; Fri, 1 Sep 2017 14:53:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.02 X-Spam-Level: X-Spam-Status: No, score=0.02 tagged_above=-999 required=5 tests=[T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 TV2T1y6lfPN1; Fri, 1 Sep 2017 14:53:32 -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 D7FBC132DEF; Fri, 1 Sep 2017 14:53:32 -0700 (PDT) Received: from Orochi.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v81LrP56084889 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 1 Sep 2017 16:53:26 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Orochi.local To: Christer Holmberg , Ben Campbell Cc: Eric Rescorla , The IESG , "sipcore@ietf.org" , "draft-ietf-sipcore-content-id@ietf.org" , "A. Jean Mahoney" , "sipcore-chairs@ietf.org" References: From: Adam Roach Message-ID: Date: Fri, 1 Sep 2017 16:53:20 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [sipcore] Draft new version: draft-content-id-09 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2017 21:53:35 -0000 Thanks for adding new text describing the historical context. I think I was expecting something that bears a bit more on the "the old documents are broken, and this document fixes them" aspect; more along the lines of: > Some existing specifications, such as [RFC5368], contain examples that > show usage of a SIP Content-ID header field referencing a complete > message-body, even though such usage has never been specified. Many > implementors have interpreted these examples to indicate that such > usage is allowed by the corresponding specification, despite the > absence of language allowing it. This document updates the normative > language in the affected documents to explicitly allow such usage. /a On 9/1/17 04:20, Christer Holmberg wrote: > Hi, > > Based on Ben¹s comment, we¹ve submitted a new version (-09) of > draft-content-id. > > Regards, > > Christer > > > > On 01/09/17 00:27, "Ben Campbell" wrote: > >> Hi, >> >> I¹m a little confused by the new text in section 1.6. (Apologies, I >> realize that you proposed that text in email, but I somehow missed it at >> the time.) >> >>> 1.6. Backward compatibility >>> >>> If an existing specification explicitly defines the usage of a >>> multipart message-body for carrying a single body part, that >>> specification MUST be updated in order to allow usage of a non- >>> multipart message-body for carrying the MIME entity, and for >>> referencing the whole message-body using a Content-ID URL. >>> >> >> Is the point of that to simply say that an update must occur, or that >> implementations cannot use a non-multipart body unless such an update >> occurs? If the former, I suggest dropping the normative language, for >> example by replacing ³MUST be² with ³should be², since we can¹t really >> make people update a specification, >> >> If the latter, I propose the following: >> >> "If an existing specification only defines the usage of a >> multipart message-body for carrying a single body part to be referenced >> by a Content-ID URL, , implementations MUST NOT carry the MIME entity >> in a non-multipart message-body unless the specification is updated >> to explicitly allow it.² >> >> Ben. >> >> >>> On Aug 31, 2017, at 6:34 AM, Christer Holmberg >>> wrote: >>> >>> Hi, >>> >>> Based on the IESG reviews, we have submitted a new version (-08) of >>> draft-content-id. >>> >>> Note that we did NOT include any update to RFC 6080, because we >>> double-checked the RFC6080 >>> usage of Content-ID header field and we believe that: >>> >>> - RFC6080 does NOT use the *SIP* Content-ID header; and >>> - RFC6080 does NOT need to use the *SIP* Content-ID header. >>> >>> Reasons: >>> >>> RFC6080 uses Content-ID heaer field as follows: >>> >>> --------------- >>> For profile data delivered via content >>> indirection, i.e., a pointer to a PCC, then the Content-ID MIME >>> header, as described in [RFC4483], MUST be used for each profile >>> document URI. >>> --------------- >>> and gives example as follows: >>> --------------- >>> NOTIFY sip:urn%3auuid%3a00000000-0000-1000-0000-00FF8D82EDCB >>> @192.168.1.44 SIP/2.0 >>> Event: ua-profile;effective-by=3600 >>> From: sip:urn%3auuid%3a00000000-0000-1000-0000-00FF8D82EDCB@example.com >>> ;tag=abca >>> To: sip:urn%3auuid%3a00000000-0000-1000-0000-00FF8D82EDCB@example.com >>> ;tag=1234 >>> Call-ID: 3573853342923422@192.0.2.44 >>> CSeq: 322 NOTIFY >>> Via: SIP/2.0/UDP 192.0.2.3; >>> branch=z9hG4bK1e3effada91dc37fd5a0c95cbf6767d0 >>> MIME-Version: 1.0 >>> Content-Type: message/external-body; access-type="URL"; >>> expiration="Mon, 01 Jan 2010 09:00:00 UTC"; >>> URL="http://example.com/z100-000000000000.html"; >>> size=9999; >>> hash=10AB568E91245681AC1B >>> >>> Content-Type: application/x-z100-device-profile >>> Content-ID: <39EHF78SA@example.com> >>> --------------- >>> >>> The Content-ID header field above is NOT a *SIP* header field since it >>> is placed *after* CRLF. >>> >>> The Content-ID header field above is a part of the message-body. >>> >>> Since the message-body is of message/external-body MIME type the >>> semantic of the Content-ID header field above follows >>> RFC2046 section 5.2.3 and RFC4483 section 5.6 - i.e. the Content-ID >>> header field above is a MIME header field and is used by >>> UAS to determine whether the content fetched from >>> http://example.com/z100-000000000000.html has changed between >>> UAC sending the SIP NOTIFY message and UAS receiving the SIP NOTIFY >>> message. >>> >>> >>> Regards, >>> >>> Christer From nobody Sat Sep 2 00:22:19 2017 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 40C821347F9; Sat, 2 Sep 2017 00:22:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 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, URIBL_BLOCKED=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 xsG3Mmsx4MrJ; Sat, 2 Sep 2017 00:22:15 -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 4E2D11343AD; Sat, 2 Sep 2017 00:22:14 -0700 (PDT) X-AuditID: c1b4fb2d-11bff700000057a4-23-59aa5c24a625 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id F0.9E.22436.42C5AA95; Sat, 2 Sep 2017 09:22:12 +0200 (CEST) Received: from ESESSMB102.ericsson.se ([169.254.2.248]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0352.000; Sat, 2 Sep 2017 09:22:11 +0200 From: Christer Holmberg To: Adam Roach , Ben Campbell CC: Eric Rescorla , The IESG , "sipcore@ietf.org" , "draft-ietf-sipcore-content-id@ietf.org" , "A. Jean Mahoney" , "sipcore-chairs@ietf.org" Thread-Topic: Draft new version: draft-content-id-09 Thread-Index: AQHTIwOYexi4+wEQX0+AMNxbu0pvpKKgceQAgADAT6A= Date: Sat, 2 Sep 2017 07:22:11 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B5626E7C0@ESESSMB102.ericsson.se> References: 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.150] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDIsWRmVeSWpSXmKPExsUyM2K7qK5KzKpIg9WX1S32/F3EbjG/8zS7 xemvM5gsVrw+x24x489EZouGzpWsFr2fFzJbfP2xic2Bw2PJkp9MHrN2PmHxmPy4jTmAOYrL JiU1J7MstUjfLoEr4/TnGYwFl0wqvm7cx97AuMS4i5GTQ0LAROLL7VPsXYxcHEICRxglNs15 zAzhLGaU2LHkOWsXIwcHm4CFRPc/bZAGEQFHib/fmlhAapgFZjBJnLy1jRUkISxgLPG/vZsV oshEon9aLxOEbSXxqv83mM0ioCKx5zDETF4BX4mb0+RAwkICBRITl98CC3MK2Ets3hQOEmYU EJP4fmoNWCezgLjErSfzmSBuFpBYsuc8M4QtKvHy8T9WCFtJYsX2S4wgY5gFNCXW79KHaFWU mNL9kB3E5hUQlDg58wnLBEbRWUimzkLomIWkYxaSjgWMLKsYRYtTi4tz042M9VKLMpOLi/Pz 9PJSSzYxAuPs4JbfujsYV792PMQowMGoxMPrd3VlpBBrYllxZe4hRgkOZiUR3ha3VZFCvCmJ lVWpRfnxRaU5qcWHGKU5WJTEeR32XYgQEkhPLEnNTk0tSC2CyTJxcEo1MLLmTb+h+OlQMm/5 YSFHw5VTSwS5OXbf3R15xVex6j3bkdaXbZzmfC2zTt3J+dzyQ/dP05snrHdfrvhey3u10ZRv 0gq1hL21J+2zKhOu2LybuOT+dBYtTuf/X6e1rLVSerPbMf/9KUe+Kclf7ldMr5m2T+qI5cF8 voKgfw9zjzY2LWSceKtywx4lluKMREMt5qLiRADEy1XhrwIAAA== Archived-At: Subject: Re: [sipcore] Draft new version: draft-content-id-09 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Sep 2017 07:22:17 -0000 SGksDQoNCj5UaGFua3MgZm9yIGFkZGluZyBuZXcgdGV4dCBkZXNjcmliaW5nIHRoZSBoaXN0b3Jp Y2FsIGNvbnRleHQuIEkgdGhpbmsgSSB3YXMgZXhwZWN0aW5nID5zb21ldGhpbmcgdGhhdCBiZWFy cyBhIGJpdCBtb3JlIG9uIHRoZSAidGhlIG9sZCBkb2N1bWVudHMgYXJlIGJyb2tlbiwgYW5kIHRo aXMgPmRvY3VtZW50IGZpeGVzIHRoZW0iIGFzcGVjdDsgbW9yZSBhbG9uZyB0aGUgbGluZXMgb2Y6 DQo+DQo+IFNvbWUgZXhpc3Rpbmcgc3BlY2lmaWNhdGlvbnMsIHN1Y2ggYXMgW1JGQzUzNjhdLCBj b250YWluIGV4YW1wbGVzIHRoYXQgDQo+IHNob3cgdXNhZ2Ugb2YgYSBTSVAgQ29udGVudC1JRCBo ZWFkZXIgZmllbGQgcmVmZXJlbmNpbmcgYSBjb21wbGV0ZSANCj4gbWVzc2FnZS1ib2R5LCBldmVu IHRob3VnaCBzdWNoIHVzYWdlIGhhcyBuZXZlciBiZWVuIHNwZWNpZmllZC4gTWFueSANCj4gaW1w bGVtZW50b3JzIGhhdmUgaW50ZXJwcmV0ZWQgdGhlc2UgZXhhbXBsZXMgdG8gaW5kaWNhdGUgdGhh dCBzdWNoIA0KPiB1c2FnZSBpcyBhbGxvd2VkIGJ5IHRoZSBjb3JyZXNwb25kaW5nIHNwZWNpZmlj YXRpb24sIGRlc3BpdGUgdGhlIA0KPiBhYnNlbmNlIG9mIGxhbmd1YWdlIGFsbG93aW5nIGl0LiBU aGlzIGRvY3VtZW50IHVwZGF0ZXMgdGhlIG5vcm1hdGl2ZSANCj4gbGFuZ3VhZ2UgaW4gdGhlIGFm ZmVjdGVkIGRvY3VtZW50cyB0byBleHBsaWNpdGx5IGFsbG93IHN1Y2ggdXNhZ2UuDQoNCkxvb2tz IGdvb2QuIEkgd2lsbCBtb2RpZnkgYXMgc3VnZ2VzdGVkLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rl cg0KDQoNCg0KT24gOS8xLzE3IDA0OjIwLCBDaHJpc3RlciBIb2xtYmVyZyB3cm90ZToNCj4gSGks DQo+DQo+IEJhc2VkIG9uIEJlbsK5cyBjb21tZW50LCB3ZcK5dmUgc3VibWl0dGVkIGEgbmV3IHZl cnNpb24gKC0wOSkgb2YgDQo+IGRyYWZ0LWNvbnRlbnQtaWQuDQo+DQo+IFJlZ2FyZHMsDQo+DQo+ IENocmlzdGVyDQo+DQo+DQo+DQo+IE9uIDAxLzA5LzE3IDAwOjI3LCAiQmVuIENhbXBiZWxsIiA8 YmVuQG5vc3RydW0uY29tPiB3cm90ZToNCj4NCj4+IEhpLA0KPj4NCj4+IEnCuW0gYSBsaXR0bGUg Y29uZnVzZWQgYnkgdGhlIG5ldyB0ZXh0IGluIHNlY3Rpb24gMS42LiAoQXBvbG9naWVzLCBJIA0K Pj4gcmVhbGl6ZSB0aGF0IHlvdSBwcm9wb3NlZCB0aGF0IHRleHQgaW4gZW1haWwsIGJ1dCBJIHNv bWVob3cgbWlzc2VkIGl0IA0KPj4gYXQgdGhlIHRpbWUuKQ0KPj4NCj4+PiAxLjYuICBCYWNrd2Fy ZCBjb21wYXRpYmlsaXR5DQo+Pj4NCj4+PiAgICAgSWYgYW4gZXhpc3Rpbmcgc3BlY2lmaWNhdGlv biBleHBsaWNpdGx5IGRlZmluZXMgdGhlIHVzYWdlIG9mIGENCj4+PiAgICAgbXVsdGlwYXJ0IG1l c3NhZ2UtYm9keSBmb3IgY2FycnlpbmcgYSBzaW5nbGUgYm9keSBwYXJ0LCB0aGF0DQo+Pj4gICAg IHNwZWNpZmljYXRpb24gTVVTVCBiZSB1cGRhdGVkIGluIG9yZGVyIHRvIGFsbG93IHVzYWdlIG9m IGEgbm9uLQ0KPj4+ICAgICBtdWx0aXBhcnQgbWVzc2FnZS1ib2R5IGZvciBjYXJyeWluZyB0aGUg TUlNRSBlbnRpdHksIGFuZCBmb3INCj4+PiAgICAgcmVmZXJlbmNpbmcgdGhlIHdob2xlIG1lc3Nh Z2UtYm9keSB1c2luZyBhIENvbnRlbnQtSUQgVVJMLg0KPj4+DQo+Pg0KPj4gSXMgdGhlIHBvaW50 IG9mIHRoYXQgdG8gc2ltcGx5IHNheSB0aGF0IGFuIHVwZGF0ZSBtdXN0IG9jY3VyLCBvciB0aGF0 IA0KPj4gaW1wbGVtZW50YXRpb25zIGNhbm5vdCB1c2UgYSBub24tbXVsdGlwYXJ0IGJvZHkgdW5s ZXNzIHN1Y2ggYW4gdXBkYXRlIA0KPj4gb2NjdXJzPyBJZiB0aGUgZm9ybWVyLCBJIHN1Z2dlc3Qg ZHJvcHBpbmcgdGhlIG5vcm1hdGl2ZSBsYW5ndWFnZSwgZm9yIA0KPj4gZXhhbXBsZSBieSByZXBs YWNpbmcgwrNNVVNUIGJlwrIgd2l0aCDCs3Nob3VsZCBiZcKyLCBzaW5jZSB3ZSBjYW7CuXQgDQo+ PiByZWFsbHkgbWFrZSBwZW9wbGUgdXBkYXRlIGEgc3BlY2lmaWNhdGlvbiwNCj4+DQo+PiBJZiB0 aGUgbGF0dGVyLCBJIHByb3Bvc2UgdGhlIGZvbGxvd2luZzoNCj4+DQo+PiAgICJJZiBhbiBleGlz dGluZyBzcGVjaWZpY2F0aW9uIG9ubHkgZGVmaW5lcyB0aGUgdXNhZ2Ugb2YgYQ0KPj4gICAgbXVs dGlwYXJ0IG1lc3NhZ2UtYm9keSBmb3IgY2FycnlpbmcgYSBzaW5nbGUgYm9keSBwYXJ0IHRvIGJl IHJlZmVyZW5jZWQNCj4+ICAgIGJ5IGEgQ29udGVudC1JRCBVUkwsICwgaW1wbGVtZW50YXRpb25z IE1VU1QgTk9UIGNhcnJ5IHRoZSBNSU1FIGVudGl0eQ0KPj4gICAgaW4gYSBub24tbXVsdGlwYXJ0 IG1lc3NhZ2UtYm9keSB1bmxlc3MgdGhlIHNwZWNpZmljYXRpb24gaXMgdXBkYXRlZA0KPj4gICAg dG8gZXhwbGljaXRseSBhbGxvdyBpdC7Csg0KPj4NCj4+IEJlbi4NCj4+DQo+Pg0KPj4+IE9uIEF1 ZyAzMSwgMjAxNywgYXQgNjozNCBBTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgDQo+Pj4gPGNocmlzdGVy LmhvbG1iZXJnQGVyaWNzc29uLmNvbT4gd3JvdGU6DQo+Pj4NCj4+PiBIaSwNCj4+Pg0KPj4+IEJh c2VkIG9uIHRoZSBJRVNHIHJldmlld3MsIHdlIGhhdmUgc3VibWl0dGVkIGEgbmV3IHZlcnNpb24g KC0wOCkgb2YgDQo+Pj4gZHJhZnQtY29udGVudC1pZC4NCj4+Pg0KPj4+IE5vdGUgdGhhdCB3ZSBk aWQgTk9UIGluY2x1ZGUgYW55IHVwZGF0ZSB0byBSRkMgNjA4MCwgYmVjYXVzZSB3ZSANCj4+PiBk b3VibGUtY2hlY2tlZCB0aGUgUkZDNjA4MCB1c2FnZSBvZiBDb250ZW50LUlEIGhlYWRlciBmaWVs ZCBhbmQgd2UgDQo+Pj4gYmVsaWV2ZSB0aGF0Og0KPj4+DQo+Pj4gLSBSRkM2MDgwIGRvZXMgTk9U IHVzZSB0aGUgKlNJUCogQ29udGVudC1JRCBoZWFkZXI7IGFuZA0KPj4+IC0gUkZDNjA4MCBkb2Vz IE5PVCBuZWVkIHRvIHVzZSB0aGUgKlNJUCogQ29udGVudC1JRCBoZWFkZXIuDQo+Pj4NCj4+PiBS ZWFzb25zOg0KPj4+DQo+Pj4gUkZDNjA4MCB1c2VzIENvbnRlbnQtSUQgaGVhZXIgZmllbGQgYXMg Zm9sbG93czoNCj4+Pg0KPj4+IC0tLS0tLS0tLS0tLS0tLQ0KPj4+ICAgICBGb3IgcHJvZmlsZSBk YXRhIGRlbGl2ZXJlZCB2aWEgY29udGVudA0KPj4+ICAgICBpbmRpcmVjdGlvbiwgaS5lLiwgYSBw b2ludGVyIHRvIGEgUENDLCB0aGVuIHRoZSBDb250ZW50LUlEIE1JTUUNCj4+PiAgICAgaGVhZGVy LCBhcyBkZXNjcmliZWQgaW4gW1JGQzQ0ODNdLCBNVVNUIGJlIHVzZWQgZm9yIGVhY2ggcHJvZmls ZQ0KPj4+ICAgICBkb2N1bWVudCBVUkkuDQo+Pj4gLS0tLS0tLS0tLS0tLS0tDQo+Pj4gYW5kIGdp dmVzIGV4YW1wbGUgYXMgZm9sbG93czoNCj4+PiAtLS0tLS0tLS0tLS0tLS0NCj4+PiBOT1RJRlkg c2lwOnVybiUzYXV1aWQlM2EwMDAwMDAwMC0wMDAwLTEwMDAtMDAwMC0wMEZGOEQ4MkVEQ0INCj4+ PiAgICAgICAgICBAMTkyLjE2OC4xLjQ0IFNJUC8yLjANCj4+PiBFdmVudDogdWEtcHJvZmlsZTtl ZmZlY3RpdmUtYnk9MzYwMA0KPj4+IEZyb206IHNpcDp1cm4lM2F1dWlkJTNhMDAwMDAwMDAtMDAw MC0xMDAwLTAwMDAtMDBGRjhEODJFRENCQGV4YW1wbGUuY29tDQo+Pj4gICAgICAgICA7dGFnPWFi Y2ENCj4+PiBUbzogc2lwOnVybiUzYXV1aWQlM2EwMDAwMDAwMC0wMDAwLTEwMDAtMDAwMC0wMEZG OEQ4MkVEQ0JAZXhhbXBsZS5jb20NCj4+PiAgICAgICA7dGFnPTEyMzQNCj4+PiBDYWxsLUlEOiAz NTczODUzMzQyOTIzNDIyQDE5Mi4wLjIuNDQNCj4+PiBDU2VxOiAzMjIgTk9USUZZDQo+Pj4gVmlh OiBTSVAvMi4wL1VEUCAxOTIuMC4yLjM7DQo+Pj4gICAgIGJyYW5jaD16OWhHNGJLMWUzZWZmYWRh OTFkYzM3ZmQ1YTBjOTVjYmY2NzY3ZDANCj4+PiBNSU1FLVZlcnNpb246IDEuMA0KPj4+IENvbnRl bnQtVHlwZTogbWVzc2FnZS9leHRlcm5hbC1ib2R5OyBhY2Nlc3MtdHlwZT0iVVJMIjsNCj4+PiAg ICAgICAgICAgICAgICAgZXhwaXJhdGlvbj0iTW9uLCAwMSBKYW4gMjAxMCAwOTowMDowMCBVVEMi Ow0KPj4+ICAgICAgICAgICAgICAgICBVUkw9Imh0dHA6Ly9leGFtcGxlLmNvbS96MTAwLTAwMDAw MDAwMDAwMC5odG1sIjsNCj4+PiAgICAgICAgICAgICAgICAgc2l6ZT05OTk5Ow0KPj4+ICAgICAg ICAgICAgICAgICBoYXNoPTEwQUI1NjhFOTEyNDU2ODFBQzFCDQo+Pj4NCj4+PiBDb250ZW50LVR5 cGU6IGFwcGxpY2F0aW9uL3gtejEwMC1kZXZpY2UtcHJvZmlsZQ0KPj4+IENvbnRlbnQtSUQ6IDwz OUVIRjc4U0FAZXhhbXBsZS5jb20+DQo+Pj4gLS0tLS0tLS0tLS0tLS0tDQo+Pj4NCj4+PiBUaGUg Q29udGVudC1JRCBoZWFkZXIgZmllbGQgYWJvdmUgaXMgTk9UIGEgKlNJUCogaGVhZGVyIGZpZWxk IHNpbmNlIA0KPj4+IGl0IGlzIHBsYWNlZCAqYWZ0ZXIqIENSTEYuDQo+Pj4NCj4+PiBUaGUgQ29u dGVudC1JRCBoZWFkZXIgZmllbGQgYWJvdmUgaXMgYSBwYXJ0IG9mIHRoZSBtZXNzYWdlLWJvZHku DQo+Pj4NCj4+PiBTaW5jZSB0aGUgbWVzc2FnZS1ib2R5IGlzIG9mIG1lc3NhZ2UvZXh0ZXJuYWwt Ym9keSBNSU1FIHR5cGUgdGhlIA0KPj4+IHNlbWFudGljIG9mIHRoZSBDb250ZW50LUlEIGhlYWRl ciBmaWVsZCBhYm92ZSBmb2xsb3dzDQo+Pj4gUkZDMjA0NiBzZWN0aW9uIDUuMi4zIGFuZCBSRkM0 NDgzIHNlY3Rpb24gNS42IC0gaS5lLiB0aGUgQ29udGVudC1JRCANCj4+PiBoZWFkZXIgZmllbGQg YWJvdmUgaXMgYSBNSU1FIGhlYWRlciBmaWVsZCBhbmQgaXMgdXNlZCBieSBVQVMgdG8gDQo+Pj4g ZGV0ZXJtaW5lIHdoZXRoZXIgdGhlIGNvbnRlbnQgZmV0Y2hlZCBmcm9tIA0KPj4+IGh0dHA6Ly9l eGFtcGxlLmNvbS96MTAwLTAwMDAwMDAwMDAwMC5odG1sIGhhcyBjaGFuZ2VkIGJldHdlZW4gVUFD IA0KPj4+IHNlbmRpbmcgdGhlIFNJUCBOT1RJRlkgbWVzc2FnZSBhbmQgVUFTIHJlY2VpdmluZyB0 aGUgU0lQIE5PVElGWSANCj4+PiBtZXNzYWdlLg0KPj4+DQo+Pj4NCj4+PiBSZWdhcmRzLA0KPj4+ DQo+Pj4gQ2hyaXN0ZXINCg0KDQo= From nobody Sat Sep 2 11:17:06 2017 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 96274132FEF; Sat, 2 Sep 2017 11:16:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sipcore@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.59.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150437621955.6464.17051823398135663502@ietfa.amsl.com> Date: Sat, 02 Sep 2017 11:16:59 -0700 Archived-At: Subject: [sipcore] I-D Action: draft-ietf-sipcore-content-id-10.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Sep 2017 18:16:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core WG of the IETF. Title : Content-ID header field in Session Initiation Protocol (SIP) Authors : Christer Holmberg Ivo Sedlacek Filename : draft-ietf-sipcore-content-id-10.txt Pages : 15 Date : 2017-09-02 Abstract: This document specifies the Content-ID header field for usage in the Session Initiation Protocol (SIP). The document also updates RFC 5621, which only allows a Content-ID URL to reference a body part that is part of a multipart message-body. This update enables a Content-ID URL to reference a complete message-body and metadata provided by some additional SIP header fields. This document updates RFC 5368 and RFC 6442, by clarifying their usage of the SIP Content-ID header field. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-content-id/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sipcore-content-id-10 https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-content-id-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-content-id-10 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Sep 5 13:07:50 2017 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 708F6132E28; Tue, 5 Sep 2017 13:07:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.60.0 Auto-Submitted: auto-generated Precedence: bulk Cc: ben@nostrum.com, Jean Mahoney , sipcore-chairs@ietf.org, sipcore@ietf.org, mahoney@nostrum.com, The IESG , draft-ietf-sipcore-content-id@ietf.org, rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <150464206245.29944.11473642510862201535.idtracker@ietfa.amsl.com> Date: Tue, 05 Sep 2017 13:07:42 -0700 Archived-At: Subject: [sipcore] Protocol Action: 'Content-ID header field in Session Initiation Protocol (SIP)' to Proposed Standard (draft-ietf-sipcore-content-id-10.txt) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 20:07:43 -0000 The IESG has approved the following document: - 'Content-ID header field in Session Initiation Protocol (SIP)' (draft-ietf-sipcore-content-id-10.txt) as Proposed Standard This document is the product of the Session Initiation Protocol Core Working Group. The IESG contact persons are Adam Roach, Alexey Melnikov and Ben Campbell. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-content-id/ Technical Summary This document specifies the Content-ID header field for usage in the Session Initiation Protocol (SIP) to identify a complete message-body of a SIP message. The document also updates RFC 5621, to enable a Content-ID URL to reference a complete message-body and metadata provided by some additional SIP header fields. Working Group Summary Discussions about the Content-ID header field started in the ECRIT working group when the group identified cases where a request with a single message body also needs to include a Content-ID header field in the SIP message header to refer to the MIME entity, but the Content-ID header field was not actually a SIP header field, surprising some working group members. The authors brought the issue to the SIPCORE working group. There was consensus that this was an oversight in SIP. There was a discussion about perhaps adding all the Content-* MIME header fields as SIP header fields for completeness (SIP already has extended the some of the MIME header fields), but the working group decided to focus only on Content-ID since there wasn't a clear need for some of the others like Content-Transfer-Encoding. Document Quality This short document received detailed review from a handful of working group participants. The authors incorporated received feedback. Although the Document Shepherd is not aware of implementations, the Content-ID header field will be useful when transporting data for location conveyance and emergency calls. There may be implementations of Content-ID as a SIP header field since RFC 5368 shows Content-ID as a SIP header field in its examples. Personnel Jean Mahoney is the document shepherd. Ben Campbell is the responsible area director. From nobody Wed Sep 6 04:06:58 2017 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 85A9C13271F for ; Wed, 6 Sep 2017 04:06:56 -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 reKVJY_CsF0H for ; Wed, 6 Sep 2017 04:06:55 -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 1B351132811 for ; Wed, 6 Sep 2017 04:06:54 -0700 (PDT) X-AuditID: c1b4fb25-967ff70000005333-4e-59afd6cda452 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id E7.97.21299.DC6DFA95; Wed, 6 Sep 2017 13:06:53 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.194]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0352.000; Wed, 6 Sep 2017 13:06:52 +0200 From: Christer Holmberg To: "sipcore@ietf.org" Thread-Topic: Session-timer issue Thread-Index: AQHTJwA95Xe7gTczX0KOZ3DfWO32OA== Date: Wed, 6 Sep 2017 11:06:52 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.4.170508 x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrILMWRmVeSWpSXmKPExsUyM2J7lO7Za+sjDdafkrD4+mMTmwOjx5Il P5kCGKO4bFJSczLLUov07RK4Mn5MfchY8E6l4uTNTcwNjF+Uuxg5OSQETCSOHm9j6WLk4hAS OMIo0X/nFxuEs5hRYtnjBqAMBwebgIVE9z9tkAYRAU2J5d+2soPYwgIyEp//72WGiCtKNJ7d xwRh60ncvX2IDcRmEVCRuHNuIiuIzStgLfH06VywOKOAmMT3U2vA6pkFxCVuPZnPBHGQgMSS PeeZIWxRiZeP/7GCnCAKNPPdfk+IsJLEjw2XWCBatSS+/NjHBmFbSzz+9ZoVwlaUmNL9kB1i raDEyZlPWCYwisxCsm0WkvZZSNpnIWmfhaR9ASPrKkbR4tTipNx0I2O91KLM5OLi/Dy9vNSS TYzAiDi45bfqDsbLbxwPMQpwMCrx8DoeWh8pxJpYVlyZe4hRgoNZSYR3/WWgEG9KYmVValF+ fFFpTmrxIUZpDhYlcV7HfRcihATSE0tSs1NTC1KLYLJMHJxSDYwFhokqvz/23vM4YZv6uL0t 27vmnEXK5/NJ2+axHy/9cfT76viGnWbLNS//6b575XuIGB+Pi/3OHWsUri91COucytxx6s21 Y+KKc9U2ts/POfLV5OmFKcyLp7mH8BunJE4+qekonfr+I9usPXr9p99v778Z+Pst+7qJrCp7 J36aJWU3U3vL3hxOJZbijERDLeai4kQAQMBH14QCAAA= Archived-At: Subject: [sipcore] Session-timer issue X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 11:06:56 -0000 SGksDQoNClRoZSBmb2xsb3dpbmcgaXNzdWUgaGFzIGJlZW4gYXJvdW5kIGZvciBzb21lIHRpbWUg YWxyZWFkeSAodGhlcmUgaXMgYWxzbw0KYW4gZXJyYXRhICM0NzQ0KSwgYW5kIGFzIGl0IGNhdXNl cyBwcm9ibGVtcyAodGhlIElOVklURSBpcyByZWplY3RlZCB3aXRoIGENCjQ4MCByZXNwb25zZSkg aW4gZGVwbG95ZWQgbmV0d29ya3MsIHNvIEkgdGhpbmsgaXQgbmVlZHMgdG8gYmUgZml4ZWQuDQpQ ZW9wbGUgc2VlbSB0byBoYXZlIGRpZmZlcmVudCBvcGluaW9ucyBvbiB3aGljaCBub2RlIGlzIGFj dGluZyB3cm9uZ2x5LCBzbw0KSSBob3BlIHdlIGNhbiBzb3J0IGl0IG91dCA6KQ0KDQpCZWxvdyBp cyBhIGNhbGwgZmxvdyBzaG93aW5nIHRoZSBwcm9ibGVtOg0KDQoNClVBICAgICAgICAgICAgICAg IFByb3h5ICAgICAgICAgICAgICAgIEFTDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0+DQpJTlZJVEUg KCMxKQ0KU3VwcG9ydGVkOnRpbWVyDQpTRTpyZWZyZXNoZXI9dWFjDQoNCiAgICAgICAgICAgICAg ICAgICAgLS0tLS0tLS0tLS0tLS0tLS0tLT4NCiAgICAgICAgICAgICAgICAgICAgSU5WSVRFICgj MikNCiAgICAgICAgICAgICAgICAgICAgU3VwcG9ydGVkOnRpbWVyDQogICAgICAgICAgICAgICAg ICAgIFNFOnJlZnJlc2hlcj11YWMNCg0KDQogICAgICAgICAgICAgICAgICAgIDwtLS0tLS0tLS0t LS0tLS0tLS0tDQogICAgICAgICAgICAgICAgICAgIDE4eCAoIzMpDQoNCjwtLS0tLS0tLS0tLS0t LS0tLS0tDQoxOHggKCM0KQ0KDQorKysrKysgZWFybHkgZGlhbG9nIGVzdGFibGlzaGVkICsrKysr KysNCg0KICAgICAgICAgICAgICAgICAgICA8LS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgICAgICAg ICAgICAgICAgICBVUERBVEUgKCM1KQ0KICAgICAgICAgICAgICAgICAgICBTdXBwb3J0ZWQ6dGlt ZXINCiAgICAgICAgICAgICAgICAgICAgU0U6cmVmcmVzaGVyPXVhcw0KDQo8LS0tLS0tLS0tLS0t LS0tLS0tLQ0KVVBEQVRFICgjNikNClN1cHBvcnRlZDp0aW1lcg0KU0U6cmVmcmVzaGVyPXVhcw0K DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0+DQoyMDAgKFVQREFURSkgKCM3KQ0KDQogICAgICAgICAg ICAgICAgICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0+DQogICAgICAgICAgICAgICAgICAgIDIwMCAo VVBEQVRFKSAoIzgpDQogICAgICAgICAgICAgICAgICAgIFJlcXVpcmU6dGltZXINCiAgICAgICAg ICAgICAgICAgICAgU0U6cmVmcmVzaGVyPXVhYw0KDQoNCiAgICAgICAgICAgICAgICAgICAgPC0t LS0tLS0tLS0tLS0tLS0tLS0NCiAgICAgICAgICAgICAgICAgICAgNDgwIChJTlZJVEUpICgjOSkN Cg0KPC0tLS0tLS0tLS0tLS0tLS0tLS0NCjQ4MCAoSU5WSVRFICgjMTApDQoNCg0KDQoNCkEgZmV3 IHRoaW5ncyB0byBub3RlOg0KDQoNCk4xOglUaGUgMTh4IGRvZXMgbm90IGNvbnRhaW4gdGhlIFNF IChTZXNzaW9uLUV4cGlyZXMpIGhlYWRlciBmaWVsZCwNCiAgICAgICAgYmVjYXVzZSBhY2NvcmRp bmcgdG8gc2VjdGlvbiA0IG9mIFJGQyA0MDI4IHRoZSBoZWFkZXIgZmllbGQgaXMgb25seQ0KICAg ICAgICBhbGxvd2VkIGluIElOVklURSwgVVBEQVRFIGFuZCAyeHguIFNvLCB3aGVuIHRoZSBVUERB VEUgcmVxdWVzdA0KICAgICAgICAoIzUpIGlzIHNlbnQsIHRoZSBpbml0aWFsIHNlc3Npb24gdGlt ZXIgbmVnb3RpYXRpb24gaXMgc3RpbGwNCiAgICAgICAgb25nb2luZy4NCg0KDQpOMjoJVGhlIFVQ REFURSByZXF1ZXN0ICgjNSkgY29udGFpbnMgYSBTZXNzaW9uLUV4cGlyZXMgaGVhZGVyIGZpZWxk Lg0KICAgICAgICBTZWN0aW9uIDcuNCBvZiBSRkMgNDAyOCBzYXlzOg0KDQoJICAgICAiSW4gYSBz ZXNzaW9uIHJlZnJlc2ggcmVxdWVzdCBzZW50IHdpdGhpbiBhIGRpYWxvZyB3aXRoIGFuIGFjdGl2 ZQ0KCSAgICAgIHNlc3Npb24gdGltZXIsIHRoZSBTZXNzaW9uLUV4cGlyZXMgaGVhZGVyIGZpZWxk IFNIT1VMRCBiZSBwcmVzZW50LiINCg0KCU5vdywgYSBkaWFsb2cgKGVhcmx5KSBIQVMgYmVlbiBl c3RhYmxpc2hlZCB3aGVuIHRoZSBVUERBVEUgcmVxdWVzdCBpcw0KICAgICAgICBzZW50LCBidXQg YXMgdGhlIGluaXRpYWwgc2Vzc2lvbiB0aW1lciBuZWdvdGlhdGlvbiBpcyBzdGlsbA0KICAgICAg ICBvbmdvaW5nLCBJIGFzc3VtZSB0aGUgc2Vzc2lvbiB0aW1lciBpc26p9nQgeWV0ICJhY3RpdmUi Pw0KDQoNCk4zOglUaGUgVVBEQVRFIDIwMCByZXNwb25zZSAoIzcpIGRvZXMgbm90IGNvbnRhaW4g dGhlIFNlc3Npb24tRXhwaXJlcw0KICAgICAgICBoZWFkZXIgZmllbGQuIEl0IGlzIGFkZGVkIGJ5 IHRoZSBwcm94eSwgYmFzZWQgb24gdGhlIHByb2NlZHVyZXMgaW4NCiAgICAgICAgU2VjdGlvbiA4 LjIgb2YgUkZDIDQwMjg6DQoNCiAgICAgICAgICAgICAiQmVjYXVzZSB0aGVyZSBpcyBubyBTZXNz aW9uLUV4cGlyZXMgb3IgUmVxdWlyZSBoZWFkZXIgZmllbGQNCiAgICAgICAgICAgICAgaW4gdGhl IHJlc3BvbnNlLCB0aGUgcHJveHkga25vd3MgdGhhdCBpdCBpcyB0aGUgZmlyc3QNCiAgICAgICAg ICAgICAgc2Vzc2lvbi10aW1lci1hd2FyZSBwcm94eSB0byByZWNlaXZlIHRoZSByZXNwb25zZS4g VGhpcw0KcHJveHkgDQogICAgICAgICAgICAgIE1VU1QgaW5zZXJ0IGEgU2Vzc2lvbi1FeHBpcmVz IGhlYWRlciBmaWVsZCBpbnRvIHRoZSByZXNwb25zZQ0KICAgICAgICAgICAgICB3aXRoIHRoZSB2 YWx1ZSBpdCByZW1lbWJlcmVkIGZyb20gdGhlIGZvcndhcmRlZCByZXF1ZXN0LiBJdA0KTVVTVCAN CiAgICAgICAgICAgICAgc2V0IHRoZSB2YWx1ZSBvZiBUaGUgJ3JlZnJlc2hlcicgcGFyYW1ldGVy IHRvICd1YWMnLiBUaGUNCnByb3h5IE1VU1QgDQogICAgICAgICAgICAgIGFkZCB0aGUgJ3RpbWVy JyBvcHRpb24gdGFnIHRvIGFueSBSZXF1aXJlIGhlYWRlciBmaWVsZCBpbg0KdGhlIA0KICAgICAg ICAgICAgICByZXNwb25zZSwgYW5kIGlmIG5vbmUgd2FzIHByZXNlbnQsIGFkZCB0aGUgUmVxdWly ZSBoZWFkZXINCmZpZWxkIHdpdGgNCiAgICAgICAgICAgICAgdGhhdCB2YWx1ZSBiZWZvcmUgZm9y d2FyZGluZyBpdCB1cHN0cmVhbS4iDQoNCg0KTm93LCBvbmUgY291bGQgYXJndWUgdGhhdCB0aGUg VUEgc2hvdWxkIGluY2x1ZGUgc29tZXRoaW5nIGluIHRoZSBVUERBVEUNCnJlc3BvbnNlICgjNyks IGJ1dCBJIHRoaW5rIHRoYXQgaXMgbm90IGEgc29sdXRpb24gYXMgdGhlIFVBIG1heSBiZQ0KY29u ZnVzZWQuIA0KSW5zdGVhZCwgYmFzZWQgb24gbXkgdW5kZXJzdGFuZGluZyBvZiB0aGUgdGV4dCBp biBzZWN0aW9uIDcuNA0KKHNlZSBhYm92ZSkgdGhlIFVQREFURSByZXF1ZXN0ICgjNSkgc2hvdWxk IG5vdCBjb250YWluIGFueSBzZXNzaW9uIHRpbWVyDQppbmZvcm1hdGlvbi4gVGhpcyBpcyBhbHNv IG1vcmUgb3IgbGVzcyB3aGF0IHRoZSBlcnJhdGEgc3VnZ2VzdHMuDQoNCkNvbW1lbnRzPw0KDQpS ZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCg== From nobody Wed Sep 6 08:28:02 2017 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 85BFE132FC0 for ; Wed, 6 Sep 2017 08:28:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 L3GxDKT3sdsi for ; Wed, 6 Sep 2017 08:27:58 -0700 (PDT) Received: from alum-mailsec-scanner-3.mit.edu (alum-mailsec-scanner-3.mit.edu [18.7.68.14]) by ietfa.amsl.com (Postfix) with ESMTP id 1404C132E28 for ; Wed, 6 Sep 2017 08:27:57 -0700 (PDT) X-AuditID: 1207440e-be1ff70000007085-0e-59b013fd7a1a Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id C7.70.28805.DF310B95; Wed, 6 Sep 2017 11:27:57 -0400 (EDT) Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id v86FRuJ3025763 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Wed, 6 Sep 2017 11:27:56 -0400 To: sipcore@ietf.org References: From: Paul Kyzivat Message-ID: <4088ba93-36dd-6746-67ab-cf01bebb6cbe@alum.mit.edu> Date: Wed, 6 Sep 2017 11:27:56 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=euc-kr; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHIsWRmVeSWpSXmKPExsUixO6iqPtXeEOkwZFdwhZff2xic2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxrNFGgVdChUfey4xNjBuFu1i5OSQEDCRePfuBUsXIxeHkMAO Jon9635DOd+ZJP6uWsoEUiUsoCXR8eUQmC0iICLxbPo/NhBbSMBaYsGKq+wgNhtQzZxD/1lA bF4Be4npK/4zg9gsAioSl17sYASxRQXSJP7tPssIUSMocXLmE7B6TgEbiY9bfoPNYRYwl7i0 4QOULS5x68l8JghbXqJ562zmCYz8s5C0z0LSMgtJyywkLQsYWVYxyiXmlObq5iZm5hSnJusW Jyfm5aUW6Rrr5WaW6KWmlG5ihAQl3w7G9vUyhxgFOBiVeHgT/q+PFGJNLCuuzD3EKMnBpCTK e1kNKMSXlJ9SmZFYnBFfVJqTWnyIUYKDWUmE96bAhkgh3pTEyqrUonyYlDQHi5I4r9oSdT8h gfTEktTs1NSC1CKYrAwHh5IE72ohoEbBotT01Iq0zJwShDQTByfIcB6g4StBaniLCxJzizPT IfKnGHU5fs3c+oVJiCUvPy9VSpyXB5gOhARAijJK8+DmwJLJK0ZxoLeEebeAjOIBJiK4Sa+A ljABLal6uQZkSUkiQkqqgVElJLLpmnq6yVuZEymXV/700P/Cp171rCjVaELT//x9l4us1+jI 1lZ2J69eYezxSv18XOOzx2Zr/H7XFe2bt9w2MiNSsUqvTpZHfnd2S/jecpXUijimA9pvtNJc K62FOKPv9Fut0XgaGbpKhNXov1vsjNiQnb/W/mdpEM8wdBHa9v/BsgBnJZbijERDLeai4kQA J3jpuQEDAAA= Archived-At: Subject: Re: [sipcore] Session-timer issue X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 15:28:00 -0000 On 9/6/17 7:06 AM, Christer Holmberg wrote: > Hi, > > The following issue has been around for some time already (there is also > an errata #4744), and as it causes problems (the INVITE is rejected with a > 480 response) in deployed networks, so I think it needs to be fixed. > People seem to have different opinions on which node is acting wrongly, so > I hope we can sort it out :) This is an interesting problem. I agree that it is unclear exactly what ought to happen in this case. (But I don't understand why someone thinks a 480 is a good way to resolve it.) Thanks, Paul > Below is a call flow showing the problem: > > > UA Proxy AS > > -------------------> > INVITE (#1) > Supported:timer > SE:refresher=uac > > -------------------> > INVITE (#2) > Supported:timer > SE:refresher=uac > > > <------------------- > 18x (#3) > > <------------------- > 18x (#4) > > ++++++ early dialog established +++++++ > > <------------------- > UPDATE (#5) > Supported:timer > SE:refresher=uas > > <------------------- > UPDATE (#6) > Supported:timer > SE:refresher=uas > > > -------------------> > 200 (UPDATE) (#7) > > -------------------> > 200 (UPDATE) (#8) > Require:timer > SE:refresher=uac > > > <------------------- > 480 (INVITE) (#9) > > <------------------- > 480 (INVITE (#10) > > > > > A few things to note: > > > N1: The 18x does not contain the SE (Session-Expires) header field, > because according to section 4 of RFC 4028 the header field is only > allowed in INVITE, UPDATE and 2xx. So, when the UPDATE request > (#5) is sent, the initial session timer negotiation is still > ongoing. > > > N2: The UPDATE request (#5) contains a Session-Expires header field. > Section 7.4 of RFC 4028 says: > > "In a session refresh request sent within a dialog with an active > session timer, the Session-Expires header field SHOULD be present." > > Now, a dialog (early) HAS been established when the UPDATE request is > sent, but as the initial session timer negotiation is still > ongoing, I assume the session timer isn©öt yet "active"? > > > N3: The UPDATE 200 response (#7) does not contain the Session-Expires > header field. It is added by the proxy, based on the procedures in > Section 8.2 of RFC 4028: > > "Because there is no Session-Expires or Require header field > in the response, the proxy knows that it is the first > session-timer-aware proxy to receive the response. This > proxy > MUST insert a Session-Expires header field into the response > with the value it remembered from the forwarded request. It > MUST > set the value of The 'refresher' parameter to 'uac'. The > proxy MUST > add the 'timer' option tag to any Require header field in > the > response, and if none was present, add the Require header > field with > that value before forwarding it upstream." > > > Now, one could argue that the UA should include something in the UPDATE > response (#7), but I think that is not a solution as the UA may be > confused. > Instead, based on my understanding of the text in section 7.4 > (see above) the UPDATE request (#5) should not contain any session timer > information. This is also more or less what the errata suggests. > > Comments? > > Regards, > > Christer > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Thu Sep 7 02:33:55 2017 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 4C53F1326ED for ; Thu, 7 Sep 2017 02:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 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, URIBL_BLOCKED=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 57tZznB2d-p5 for ; Thu, 7 Sep 2017 02:33:54 -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 B0BED132ED0 for ; Thu, 7 Sep 2017 02:33:53 -0700 (PDT) X-AuditID: c1b4fb3a-9e1d49c0000051a3-5c-59b1127f923f Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 77.77.20899.F7211B95; Thu, 7 Sep 2017 11:33:51 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.194]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0352.000; Thu, 7 Sep 2017 11:33:51 +0200 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Session-timer issue Thread-Index: AQHTJwA95Xe7gTczX0KOZ3DfWO32OKKn2eUAgAFjC4A= Date: Thu, 7 Sep 2017 09:33:51 +0000 Message-ID: References: <4088ba93-36dd-6746-67ab-cf01bebb6cbe@alum.mit.edu> In-Reply-To: <4088ba93-36dd-6746-67ab-cf01bebb6cbe@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.4.170508 x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnkeLIzCtJLcpLzFFi42KZGbFdQrdeaGOkwZb9xhYrNhxgtfj6YxOb A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJVx6tZ91oIuo4rmpvoGxicGXYycHBICJhLP D69g7mLk4hASOMIoseVTCzNIQkhgMaPE+27dLkYODjYBC4nuf9ogYRGBQImrSyaAlQgLaEl0 fDnEBFIiIqAtcWSTB4RpJbF6lzhIBYuAisT16csYQWxeAWuJjkmTWSCGF0pMa7vMCmJzCjhI XGmaBGYzCohJfD+1hgnEZhYQl7j1ZD4TxJUCEkv2nGeGsEUlXj7+xwqySlRAT+Ldfk+IsKLE zrPtzBCtWhJffuxjg7CtJe5t/MsOYStKTOl+yA5xjqDEyZlPWCYwis1Csm0WkvZZSNpnIWmf haR9ASPrKkbR4tTi4tx0IyO91KLM5OLi/Dy9vNSSTYzAaDq45bfVDsaDzx0PMQpwMCrx8M76 uSFSiDWxrLgy9xCjBAezkgjvQ4aNkUK8KYmVValF+fFFpTmpxYcYpTlYlMR5HfZdiBASSE8s Sc1OTS1ILYLJMnFwSjUwzuy4IqLyfdsnYeZzsp3qs468fzh97k/vewfUVGdsXK6v5Xrkd9OU XYGNTPvF7Wc9OpMRvDJ394Uz2r49rRxah38obhbP7Wr7Pqdr0nGnL3l+aud0zVkFGfgeXr/U 9etovTT/t5nV999/WLDr9LW/vEHPoqdF92S6OW+9urFh7w6PnUd3WzVocyixFGckGmoxFxUn AgD6gpWHogIAAA== Archived-At: Subject: Re: [sipcore] Session-timer issue X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Sep 2017 09:33:55 -0000 SGksDQoNCj4+VGhlIGZvbGxvd2luZyBpc3N1ZSBoYXMgYmVlbiBhcm91bmQgZm9yIHNvbWUgdGlt ZSBhbHJlYWR5ICh0aGVyZSBpcyBhbHNvDQo+PiBhbiBlcnJhdGEgIzQ3NDQpLCBhbmQgYXMgaXQg Y2F1c2VzIHByb2JsZW1zICh0aGUgSU5WSVRFIGlzIHJlamVjdGVkDQo+PndpdGggYQ0KPj4gNDgw IHJlc3BvbnNlKSBpbiBkZXBsb3llZCBuZXR3b3Jrcywgc28gSSB0aGluayBpdCBuZWVkcyB0byBi ZSBmaXhlZC4NCj4+IFBlb3BsZSBzZWVtIHRvIGhhdmUgZGlmZmVyZW50IG9waW5pb25zIG9uIHdo aWNoIG5vZGUgaXMgYWN0aW5nIHdyb25nbHksDQo+PnNvDQo+PiBJIGhvcGUgd2UgY2FuIHNvcnQg aXQgb3V0IDopDQo+DQo+VGhpcyBpcyBhbiBpbnRlcmVzdGluZyBwcm9ibGVtLiBJIGFncmVlIHRo YXQgaXQgaXMgdW5jbGVhciBleGFjdGx5IHdoYXQNCj5vdWdodCB0byBoYXBwZW4gaW4gdGhpcyBj YXNlLiAoQnV0IEkgZG9uJ3QgdW5kZXJzdGFuZCB3aHkgc29tZW9uZSB0aGlua3MNCj5hIDQ4MCBp cyBhIGdvb2Qgd2F5IHRvIHJlc29sdmUgaXQuKQ0KDQpXaGV0aGVyIDQ4MCBpcyB0aGUgYmVzdCBz b2x1dGlvbiBvciBub3QgaXMgbm90IHRoZSBpc3N1ZSwgaW4gbXkgb3Bpbmlvbi4NCk9uZSBjb3Vs ZCBhbHNvIGNsYWltIHRoYXQgdGhlIFVQREFURSBzaG91bGQgYmUgcmVqZWN0ZWQuIEV0Yy4NCg0K VGhlIGlzc3VlIGlzIHRoYXQgdGhlcmUgaXMgYSBzZXNzaW9uLXRpbWVyIG5lZ290aWF0aW9uIKGw cmFjZSBjb25kaXRpb26hsSwNCmFuZCB3ZSBzaG91bGQgZm9yYmlkIHRoYXQgKHJlamVjdGluZyB0 aGUgVVBEQVRFIGNvdWxkIGJlIHBhcnQgb2Ygc3VjaA0Kc29sdXRpb24pLg0KDQpSZWdhcmRzLA0K DQpDaHJpc3Rlcg0KDQoNCg0KDQoNCj4NCj4JVGhhbmtzLA0KPglQYXVsDQo+DQo+PiBCZWxvdyBp cyBhIGNhbGwgZmxvdyBzaG93aW5nIHRoZSBwcm9ibGVtOg0KPj4gDQo+PiANCj4+IFVBICAgICAg ICAgICAgICAgIFByb3h5ICAgICAgICAgICAgICAgIEFTDQo+PiANCj4+IC0tLS0tLS0tLS0tLS0t LS0tLS0+DQo+PiBJTlZJVEUgKCMxKQ0KPj4gU3VwcG9ydGVkOnRpbWVyDQo+PiBTRTpyZWZyZXNo ZXI9dWFjDQo+PiANCj4+ICAgICAgICAgICAgICAgICAgICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0+ DQo+PiAgICAgICAgICAgICAgICAgICAgICBJTlZJVEUgKCMyKQ0KPj4gICAgICAgICAgICAgICAg ICAgICAgU3VwcG9ydGVkOnRpbWVyDQo+PiAgICAgICAgICAgICAgICAgICAgICBTRTpyZWZyZXNo ZXI9dWFjDQo+PiANCj4+IA0KPj4gICAgICAgICAgICAgICAgICAgICAgPC0tLS0tLS0tLS0tLS0t LS0tLS0NCj4+ICAgICAgICAgICAgICAgICAgICAgIDE4eCAoIzMpDQo+PiANCj4+IDwtLS0tLS0t LS0tLS0tLS0tLS0tDQo+PiAxOHggKCM0KQ0KPj4gDQo+PiArKysrKysgZWFybHkgZGlhbG9nIGVz dGFibGlzaGVkICsrKysrKysNCj4+IA0KPj4gICAgICAgICAgICAgICAgICAgICAgPC0tLS0tLS0t LS0tLS0tLS0tLS0NCj4+ICAgICAgICAgICAgICAgICAgICAgIFVQREFURSAoIzUpDQo+PiAgICAg ICAgICAgICAgICAgICAgICBTdXBwb3J0ZWQ6dGltZXINCj4+ICAgICAgICAgICAgICAgICAgICAg IFNFOnJlZnJlc2hlcj11YXMNCj4+IA0KPj4gPC0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+IFVQREFU RSAoIzYpDQo+PiBTdXBwb3J0ZWQ6dGltZXINCj4+IFNFOnJlZnJlc2hlcj11YXMNCj4+IA0KPj4g DQo+PiAtLS0tLS0tLS0tLS0tLS0tLS0tPg0KPj4gMjAwIChVUERBVEUpICgjNykNCj4+IA0KPj4g ICAgICAgICAgICAgICAgICAgICAgLS0tLS0tLS0tLS0tLS0tLS0tLT4NCj4+ICAgICAgICAgICAg ICAgICAgICAgIDIwMCAoVVBEQVRFKSAoIzgpDQo+PiAgICAgICAgICAgICAgICAgICAgICBSZXF1 aXJlOnRpbWVyDQo+PiAgICAgICAgICAgICAgICAgICAgICBTRTpyZWZyZXNoZXI9dWFjDQo+PiAN Cj4+IA0KPj4gICAgICAgICAgICAgICAgICAgICAgPC0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+ICAg ICAgICAgICAgICAgICAgICAgIDQ4MCAoSU5WSVRFKSAoIzkpDQo+PiANCj4+IDwtLS0tLS0tLS0t LS0tLS0tLS0tDQo+PiA0ODAgKElOVklURSAoIzEwKQ0KPj4gDQo+PiANCj4+IA0KPj4gDQo+PiBB IGZldyB0aGluZ3MgdG8gbm90ZToNCj4+IA0KPj4gDQo+PiBOMToJVGhlIDE4eCBkb2VzIG5vdCBj b250YWluIHRoZSBTRSAoU2Vzc2lvbi1FeHBpcmVzKSBoZWFkZXIgZmllbGQsDQo+PiAgICAgICAg ICBiZWNhdXNlIGFjY29yZGluZyB0byBzZWN0aW9uIDQgb2YgUkZDIDQwMjggdGhlIGhlYWRlciBm aWVsZCBpcw0KPj5vbmx5DQo+PiAgICAgICAgICBhbGxvd2VkIGluIElOVklURSwgVVBEQVRFIGFu ZCAyeHguIFNvLCB3aGVuIHRoZSBVUERBVEUgcmVxdWVzdA0KPj4gICAgICAgICAgKCM1KSBpcyBz ZW50LCB0aGUgaW5pdGlhbCBzZXNzaW9uIHRpbWVyIG5lZ290aWF0aW9uIGlzIHN0aWxsDQo+PiAg ICAgICAgICBvbmdvaW5nLg0KPj4gDQo+PiANCj4+IE4yOglUaGUgVVBEQVRFIHJlcXVlc3QgKCM1 KSBjb250YWlucyBhIFNlc3Npb24tRXhwaXJlcyBoZWFkZXIgZmllbGQuDQo+PiAgICAgICAgICBT ZWN0aW9uIDcuNCBvZiBSRkMgNDAyOCBzYXlzOg0KPj4gDQo+PiAJICAgICAiSW4gYSBzZXNzaW9u IHJlZnJlc2ggcmVxdWVzdCBzZW50IHdpdGhpbiBhIGRpYWxvZyB3aXRoIGFuIGFjdGl2ZQ0KPj4g CSAgICAgIHNlc3Npb24gdGltZXIsIHRoZSBTZXNzaW9uLUV4cGlyZXMgaGVhZGVyIGZpZWxkIFNI T1VMRCBiZQ0KPj5wcmVzZW50LiINCj4+IA0KPj4gCU5vdywgYSBkaWFsb2cgKGVhcmx5KSBIQVMg YmVlbiBlc3RhYmxpc2hlZCB3aGVuIHRoZSBVUERBVEUgcmVxdWVzdCBpcw0KPj4gICAgICAgICAg c2VudCwgYnV0IGFzIHRoZSBpbml0aWFsIHNlc3Npb24gdGltZXIgbmVnb3RpYXRpb24gaXMgc3Rp bGwNCj4+ICAgICAgICAgIG9uZ29pbmcsIEkgYXNzdW1lIHRoZSBzZXNzaW9uIHRpbWVyIGlzbqn2 dCB5ZXQgImFjdGl2ZSI/DQo+PiANCj4+IA0KPj4gTjM6CVRoZSBVUERBVEUgMjAwIHJlc3BvbnNl ICgjNykgZG9lcyBub3QgY29udGFpbiB0aGUgU2Vzc2lvbi1FeHBpcmVzDQo+PiAgICAgICAgICBo ZWFkZXIgZmllbGQuIEl0IGlzIGFkZGVkIGJ5IHRoZSBwcm94eSwgYmFzZWQgb24gdGhlDQo+PnBy b2NlZHVyZXMgaW4NCj4+ICAgICAgICAgIFNlY3Rpb24gOC4yIG9mIFJGQyA0MDI4Og0KPj4gDQo+ PiAgICAgICAgICAgICAgICJCZWNhdXNlIHRoZXJlIGlzIG5vIFNlc3Npb24tRXhwaXJlcyBvciBS ZXF1aXJlIGhlYWRlcg0KPj5maWVsZA0KPj4gICAgICAgICAgICAgICAgaW4gdGhlIHJlc3BvbnNl LCB0aGUgcHJveHkga25vd3MgdGhhdCBpdCBpcyB0aGUgZmlyc3QNCj4+ICAgICAgICAgICAgICAg IHNlc3Npb24tdGltZXItYXdhcmUgcHJveHkgdG8gcmVjZWl2ZSB0aGUgcmVzcG9uc2UuIFRoaXMN Cj4+IHByb3h5DQo+PiAgICAgICAgICAgICAgICBNVVNUIGluc2VydCBhIFNlc3Npb24tRXhwaXJl cyBoZWFkZXIgZmllbGQgaW50byB0aGUNCj4+cmVzcG9uc2UNCj4+ICAgICAgICAgICAgICAgIHdp dGggdGhlIHZhbHVlIGl0IHJlbWVtYmVyZWQgZnJvbSB0aGUgZm9yd2FyZGVkIHJlcXVlc3QuDQo+ Pkl0DQo+PiBNVVNUDQo+PiAgICAgICAgICAgICAgICBzZXQgdGhlIHZhbHVlIG9mIFRoZSAncmVm cmVzaGVyJyBwYXJhbWV0ZXIgdG8gJ3VhYycuIFRoZQ0KPj4gcHJveHkgTVVTVA0KPj4gICAgICAg ICAgICAgICAgYWRkIHRoZSAndGltZXInIG9wdGlvbiB0YWcgdG8gYW55IFJlcXVpcmUgaGVhZGVy IGZpZWxkIGluDQo+PiB0aGUNCj4+ICAgICAgICAgICAgICAgIHJlc3BvbnNlLCBhbmQgaWYgbm9u ZSB3YXMgcHJlc2VudCwgYWRkIHRoZSBSZXF1aXJlIGhlYWRlcg0KPj4gZmllbGQgd2l0aA0KPj4g ICAgICAgICAgICAgICAgdGhhdCB2YWx1ZSBiZWZvcmUgZm9yd2FyZGluZyBpdCB1cHN0cmVhbS4i DQo+PiANCj4+IA0KPj4gTm93LCBvbmUgY291bGQgYXJndWUgdGhhdCB0aGUgVUEgc2hvdWxkIGlu Y2x1ZGUgc29tZXRoaW5nIGluIHRoZSBVUERBVEUNCj4+IHJlc3BvbnNlICgjNyksIGJ1dCBJIHRo aW5rIHRoYXQgaXMgbm90IGEgc29sdXRpb24gYXMgdGhlIFVBIG1heSBiZQ0KPj4gY29uZnVzZWQu DQo+PiBJbnN0ZWFkLCBiYXNlZCBvbiBteSB1bmRlcnN0YW5kaW5nIG9mIHRoZSB0ZXh0IGluIHNl Y3Rpb24gNy40DQo+PiAoc2VlIGFib3ZlKSB0aGUgVVBEQVRFIHJlcXVlc3QgKCM1KSBzaG91bGQg bm90IGNvbnRhaW4gYW55IHNlc3Npb24gdGltZXINCj4+IGluZm9ybWF0aW9uLiBUaGlzIGlzIGFs c28gbW9yZSBvciBsZXNzIHdoYXQgdGhlIGVycmF0YSBzdWdnZXN0cy4NCj4+IA0KPj4gQ29tbWVu dHM/DQo+PiANCj4+IFJlZ2FyZHMsDQo+PiANCj4+IENocmlzdGVyDQo+PiANCj4+IA0KPj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IHNpcGNvcmUg bWFpbGluZyBsaXN0DQo+PiBzaXBjb3JlQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCj4+IA0KPg0KPl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+c2lwY29yZSBtYWlsaW5nIGxpc3QNCj5zaXBj b3JlQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBj b3JlDQoNCg== From nobody Thu Sep 7 04:30:53 2017 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 094A5132153 for ; Thu, 7 Sep 2017 04:30:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.319 X-Spam-Level: X-Spam-Status: No, score=-4.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de 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 cpSypSCvGI36 for ; Thu, 7 Sep 2017 04:30:50 -0700 (PDT) Received: from mailout13.telekom.de (MAILOUT13.telekom.de [80.149.113.181]) (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 5DDD2124B18 for ; Thu, 7 Sep 2017 04:30:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1504783849; x=1536319849; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=YeLDVzDNwx2x6r3bO6OK4LhkCaH1ijHiP1q1sd3brrQ=; b=e1/gvz4PlVqb2nDKEb9JxnGq7ssEUEjQmhrCO2GfuoIBCnYTgaIFuubk U1biUZTobwZzdOsCc5JhPlNozZtrcEu8h37f9Uq8MuHn4g47mmmAIs8HR k0fkJGG9R8VGS5kYPiKYJ/6t49ZiASCqeIa4fQt+s2qQIS1QpBXw0D8NH FRbNdACCZCYw6UAwm/bvjgPeKS3dz6LDUvPFZWVOQzib5CzSf/5bdvYJ8 Lj/y326l+IeoMlySO3HuCVljpjJzRYP0uHkcrYA0DFp40/BcbwKiEZdC5 bnzxqAS1TJSmJvO9VY8rhXihPvV5gC5ujxHU7sx/mT+Ywv2kf88SN0rtN Q==; Received: from qdec94.de.t-internal.com ([10.171.255.41]) by MAILOUT11.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Sep 2017 13:30:45 +0200 X-IronPort-AV: E=Sophos;i="5.42,358,1500933600"; d="scan'208";a="32290745" Received: from he105831.emea1.cds.t-internal.com ([10.169.119.34]) by QDEC97.de.t-internal.com with ESMTP/TLS/AES256-SHA; 07 Sep 2017 13:30:45 +0200 Received: from HE105828.EMEA1.cds.t-internal.com (10.169.119.31) by HE105831.emea1.cds.t-internal.com (10.169.119.34) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Thu, 7 Sep 2017 13:30:44 +0200 Received: from HE105828.EMEA1.cds.t-internal.com ([fe80::753e:c05:6c77:b585]) by HE105828.emea1.cds.t-internal.com ([fe80::753e:c05:6c77:b585%26]) with mapi id 15.00.1293.002; Thu, 7 Sep 2017 13:30:44 +0200 From: To: , , Thread-Topic: [sipcore] Session-timer issue Thread-Index: AQHTJwA95Xe7gTczX0KOZ3DfWO32OKKn2eUAgAFjC4CAAAyqUA== Date: Thu, 7 Sep 2017 11:30:44 +0000 Message-ID: <85c9c45d14b148fda06c2faadf91ec6f@HE105828.emea1.cds.t-internal.com> References: <4088ba93-36dd-6746-67ab-cf01bebb6cbe@alum.mit.edu> In-Reply-To: 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.157.162.67] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sipcore] Session-timer issue X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Sep 2017 11:30:52 -0000 Hi, seen from my point of view the UAC should ignore the Session timer proposal= within the UPDATE. As long as the negotiation is ongoing. Nevertheless we have also observed this curious session timer behavior in o= ur network. I think we need some clarifications to the RFC. Perhaps also to other secti= ons to make it more readable.=20 My experience is that people have problems in following how the session tim= er should work within a complex SIP networks (e.g. IMS). What is about updating the RFC4028.=20 Best Regards Roland > -----Urspr=FCngliche Nachricht----- > Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von Christer > Holmberg > Gesendet: Donnerstag, 7. September 2017 11:34 > An: Paul Kyzivat ; sipcore@ietf.org > Betreff: Re: [sipcore] Session-timer issue >=20 > Hi, >=20 > >>The following issue has been around for some time already (there is > >>also an errata #4744), and as it causes problems (the INVITE is > >>rejected with a > >> 480 response) in deployed networks, so I think it needs to be fixed. > >> People seem to have different opinions on which node is acting > >>wrongly, so I hope we can sort it out :) > > > >This is an interesting problem. I agree that it is unclear exactly what > >ought to happen in this case. (But I don't understand why someone > >thinks a 480 is a good way to resolve it.) >=20 > Whether 480 is the best solution or not is not the issue, in my opinion. > One could also claim that the UPDATE should be rejected. Etc. >=20 > The issue is that there is a session-timer negotiation "race condition", = and we > should forbid that (rejecting the UPDATE could be part of such solution). >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 > > > > Thanks, > > Paul > > > >> Below is a call flow showing the problem: > >> > >> > >> UA Proxy AS > >> > >> -------------------> > >> INVITE (#1) > >> Supported:timer > >> SE:refresher=3Duac > >> > >> -------------------> > >> INVITE (#2) > >> Supported:timer > >> SE:refresher=3Duac > >> > >> > >> <------------------- > >> 18x (#3) > >> > >> <------------------- > >> 18x (#4) > >> > >> ++++++ early dialog established +++++++ > >> > >> <------------------- > >> UPDATE (#5) > >> Supported:timer > >> SE:refresher=3Duas > >> > >> <------------------- > >> UPDATE (#6) > >> Supported:timer > >> SE:refresher=3Duas > >> > >> > >> -------------------> > >> 200 (UPDATE) (#7) > >> > >> -------------------> > >> 200 (UPDATE) (#8) > >> Require:timer > >> SE:refresher=3Duac > >> > >> > >> <------------------- > >> 480 (INVITE) (#9) > >> > >> <------------------- > >> 480 (INVITE (#10) > >> > >> > >> > >> > >> A few things to note: > >> > >> > >> N1: The 18x does not contain the SE (Session-Expires) header field, > >> because according to section 4 of RFC 4028 the header field > >>is only > >> allowed in INVITE, UPDATE and 2xx. So, when the UPDATE reques= t > >> (#5) is sent, the initial session timer negotiation is still > >> ongoing. > >> > >> > >> N2: The UPDATE request (#5) contains a Session-Expires header field. > >> Section 7.4 of RFC 4028 says: > >> > >> "In a session refresh request sent within a dialog with an activ= e > >> session timer, the Session-Expires header field SHOULD be > >>present." > >> > >> Now, a dialog (early) HAS been established when the UPDATE > request is > >> sent, but as the initial session timer negotiation is still > >> ongoing, I assume the session timer isn=B9t yet "active"? > >> > >> > >> N3: The UPDATE 200 response (#7) does not contain the Session-Expires > >> header field. It is added by the proxy, based on the > >>procedures in > >> Section 8.2 of RFC 4028: > >> > >> "Because there is no Session-Expires or Require header > >>field > >> in the response, the proxy knows that it is the first > >> session-timer-aware proxy to receive the response. > >>This proxy > >> MUST insert a Session-Expires header field into the > >>response > >> with the value it remembered from the forwarded request= . > >>It > >> MUST > >> set the value of The 'refresher' parameter to 'uac'. > >>The proxy MUST > >> add the 'timer' option tag to any Require header field > >>in the > >> response, and if none was present, add the Require > >>header field with > >> that value before forwarding it upstream." > >> > >> > >> Now, one could argue that the UA should include something in the > >> UPDATE response (#7), but I think that is not a solution as the UA > >> may be confused. > >> Instead, based on my understanding of the text in section 7.4 (see > >> above) the UPDATE request (#5) should not contain any session timer > >> information. This is also more or less what the errata suggests. > >> > >> Comments? > >> > >> 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 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Thu Sep 7 05:09:01 2017 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 1F19C1323B8 for ; Thu, 7 Sep 2017 05:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 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, URIBL_BLOCKED=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 E-x2WWqTXNwD for ; Thu, 7 Sep 2017 05:08:57 -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 893381321C9 for ; Thu, 7 Sep 2017 05:08:57 -0700 (PDT) X-AuditID: c1b4fb2d-4e93a9c0000057a4-99-59b136a8b346 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 25.14.22436.8A631B95; Thu, 7 Sep 2017 14:08:08 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.194]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0352.000; Thu, 7 Sep 2017 14:08:08 +0200 From: Christer Holmberg To: "R.Jesske@telekom.de" , "pkyzivat@alum.mit.edu" , "sipcore@ietf.org" Thread-Topic: AW: [sipcore] Session-timer issue Thread-Index: AQHTJ9H308LywevyKEK5gGy7KZtqLw== Date: Thu, 7 Sep 2017 12:08:07 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.4.170508 x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="windows-1254" Content-ID: <80F36D54F4901F45BB2EB2DE7F6BF4C4@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmkeLIzCtJLcpLzFFi42KZGbFdS/ea2cZIg3tvrC1WbDjAatF0p4vN 4uuPTWwOzB5/339g8liy5CeTR9tLhQDmKC6blNSczLLUIn27BK6Mja0PWAs2mlacmHWesYHx hloXIyeHhICJxP55C9i7GLk4hASOMEq8PfeMDcJZzChx9tpNoAwHB5uAhUT3P22QuIhAJ6PE y4ctjCDdwgJ6EssuPmMGsUUE9CX+fD7KDmHrSUy4N5UZpJdFQEVi3fNiEJNXwFri23d/kApG ATGJ76fWMIHYzALiEreezGeCuEdAYsme88wQtqjEy8f/WEFaRYEmvtvvCRFWkvix4RILRKuB xJFzN1khbGuJVwtboGxtiWULX4ON4RUQlDg58wnLBEaRWUi2zULSPgtJ+ywk7bOQtC9gZF3F KFqcWlycm25krJdalJlcXJyfp5eXWrKJERg1B7f81t3BuPq14yFGAQ5GJR7eKJONkUKsiWXF lbmHGCU4mJVEeDtAQrwpiZVVqUX58UWlOanFhxilOViUxHkd9l2IEBJITyxJzU5NLUgtgsky cXBKNTByLXg1PWFZ7a8ZHt//WoZtDH2evbw1WKH+04QZykejPSa946vbuZx54k/Gl3IGs5aI tW3xU92ybeN2vU0/9C53LVvZzGPcvVa7Y87cNr946Svl+5q6H5/6lt//0udDT9LOmQK6TzIv B1wtOyns81Dx160jG1PeG2T/M70m8uRtjfSNBzPnLoi+o8RSnJFoqMVcVJwIADPVcuuWAgAA Archived-At: Subject: Re: [sipcore] Session-timer issue X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Sep 2017 12:09:00 -0000 Hi, >seen from my point of view the UAC should ignore the Session timer >proposal within the UPDATE. >As long as the negotiation is ongoing. In the example below, it seems like the UAC DOES ignore it, since it doesn=92t included anything in the response. However, the Proxy adds the information. To prevent that, the UA would have to reject the UPDATE. Perhaps with a 491 response? I think one reason for the confusion is that RFC 4028 *DOES* say that the SE header field should be included in session refresh requests. I think we need to clarify that it shall not happen as long as the negotiation is ongoing. >Nevertheless we have also observed this curious session timer behavior in >our network. > >I think we need some clarifications to the RFC. Perhaps also to other >sections to make it more readable. >My experience is that people have problems in following how the session >timer should work within a complex SIP networks (e.g. IMS). > >What is about updating the RFC4028. I wonder whether we=92d find the people and energy for working on a bis :) = I HOPE we are able to make any needed corrections (once we agree what those would be) using an errata. Regards, Christer >> -----Urspr=FCngliche Nachricht----- >> Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von Christer >> Holmberg >> Gesendet: Donnerstag, 7. September 2017 11:34 >> An: Paul Kyzivat ; sipcore@ietf.org >> Betreff: Re: [sipcore] Session-timer issue >>=20 >> Hi, >>=20 >> >>The following issue has been around for some time already (there is >> >>also an errata #4744), and as it causes problems (the INVITE is >> >>rejected with a >> >> 480 response) in deployed networks, so I think it needs to be fixed. >> >> People seem to have different opinions on which node is acting >> >>wrongly, so I hope we can sort it out :) >> > >> >This is an interesting problem. I agree that it is unclear exactly what >> >ought to happen in this case. (But I don't understand why someone >> >thinks a 480 is a good way to resolve it.) >>=20 >> Whether 480 is the best solution or not is not the issue, in my opinion. >> One could also claim that the UPDATE should be rejected. Etc. >>=20 >> The issue is that there is a session-timer negotiation "race >>condition", and we >> should forbid that (rejecting the UPDATE could be part of such >>solution). >>=20 >> Regards, >>=20 >> Christer >>=20 >>=20 >>=20 >>=20 >>=20 >> > >> > Thanks, >> > Paul >> > >> >> Below is a call flow showing the problem: >> >> >> >> >> >> UA Proxy AS >> >> >> >> -------------------> >> >> INVITE (#1) >> >> Supported:timer >> >> SE:refresher=3Duac >> >> >> >> -------------------> >> >> INVITE (#2) >> >> Supported:timer >> >> SE:refresher=3Duac >> >> >> >> >> >> <------------------- >> >> 18x (#3) >> >> >> >> <------------------- >> >> 18x (#4) >> >> >> >> ++++++ early dialog established +++++++ >> >> >> >> <------------------- >> >> UPDATE (#5) >> >> Supported:timer >> >> SE:refresher=3Duas >> >> >> >> <------------------- >> >> UPDATE (#6) >> >> Supported:timer >> >> SE:refresher=3Duas >> >> >> >> >> >> -------------------> >> >> 200 (UPDATE) (#7) >> >> >> >> -------------------> >> >> 200 (UPDATE) (#8) >> >> Require:timer >> >> SE:refresher=3Duac >> >> >> >> >> >> <------------------- >> >> 480 (INVITE) (#9) >> >> >> >> <------------------- >> >> 480 (INVITE (#10) >> >> >> >> >> >> >> >> >> >> A few things to note: >> >> >> >> >> >> N1: The 18x does not contain the SE (Session-Expires) header field, >> >> because according to section 4 of RFC 4028 the header field >> >>is only >> >> allowed in INVITE, UPDATE and 2xx. So, when the UPDATE >>request >> >> (#5) is sent, the initial session timer negotiation is still >> >> ongoing. >> >> >> >> >> >> N2: The UPDATE request (#5) contains a Session-Expires header field. >> >> Section 7.4 of RFC 4028 says: >> >> >> >> "In a session refresh request sent within a dialog with an >>active >> >> session timer, the Session-Expires header field SHOULD be >> >>present." >> >> >> >> Now, a dialog (early) HAS been established when the UPDATE >> request is >> >> sent, but as the initial session timer negotiation is still >> >> ongoing, I assume the session timer isn=B9t yet "active"? >> >> >> >> >> >> N3: The UPDATE 200 response (#7) does not contain the Session-Expires >> >> header field. It is added by the proxy, based on the >> >>procedures in >> >> Section 8.2 of RFC 4028: >> >> >> >> "Because there is no Session-Expires or Require header >> >>field >> >> in the response, the proxy knows that it is the first >> >> session-timer-aware proxy to receive the response. >> >>This proxy >> >> MUST insert a Session-Expires header field into the >> >>response >> >> with the value it remembered from the forwarded >>request. >> >>It >> >> MUST >> >> set the value of The 'refresher' parameter to 'uac'. >> >>The proxy MUST >> >> add the 'timer' option tag to any Require header field >> >>in the >> >> response, and if none was present, add the Require >> >>header field with >> >> that value before forwarding it upstream." >> >> >> >> >> >> Now, one could argue that the UA should include something in the >> >> UPDATE response (#7), but I think that is not a solution as the UA >> >> may be confused. >> >> Instead, based on my understanding of the text in section 7.4 (see >> >> above) the UPDATE request (#5) should not contain any session timer >> >> information. This is also more or less what the errata suggests. >> >> >> >> Comments? >> >> >> >> 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 >>=20 >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore From nobody Thu Sep 7 09:11:01 2017 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 7C890132ECA for ; Thu, 7 Sep 2017 09:11:00 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] 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 5hFFsaqGY2yL for ; Thu, 7 Sep 2017 09:10:59 -0700 (PDT) Received: from resqmta-ch2-11v.sys.comcast.net (resqmta-ch2-11v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:43]) (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 E3272132D5C for ; Thu, 7 Sep 2017 09:10:58 -0700 (PDT) Received: from resomta-ch2-20v.sys.comcast.net ([69.252.207.116]) by resqmta-ch2-11v.sys.comcast.net with ESMTP id pzNudN5g0VhSzpzOLdq5jr; Thu, 07 Sep 2017 16:10:57 +0000 Received: from PaulKyzivatsMBP.localdomain ([24.62.227.142]) by resomta-ch2-20v.sys.comcast.net with SMTP id pzOKdaX1Y4jM0pzOLd3MIB; Thu, 07 Sep 2017 16:10:57 +0000 To: R.Jesske@telekom.de, christer.holmberg@ericsson.com, sipcore@ietf.org References: <4088ba93-36dd-6746-67ab-cf01bebb6cbe@alum.mit.edu> <85c9c45d14b148fda06c2faadf91ec6f@HE105828.emea1.cds.t-internal.com> From: Paul Kyzivat Message-ID: Date: Thu, 7 Sep 2017 12:10:56 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <85c9c45d14b148fda06c2faadf91ec6f@HE105828.emea1.cds.t-internal.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfFvDqMAM5Icnwl/tEzNhOZSQC3PGrBRTu5ezR4FPhPPItbapxoTvSN57A3ZFSkDiyslFoitw0DmU8P/l8fYGnfm2skKUKzjSzfeQM03AksfqMLgrUusX 8f84fAOxxzojTCc61niYJschs5Q1CYH6sBl4RhOANbeW549IXMh518XF1HurRSTcGsdiuhB9WH7FO+R+c7ENfZRZGyuRyb7+OmZXSGdIPpQNEcOJAHvPe0yN h/xcSF+yXd4tuPIuDyIIxsWx2HgvKJlO96AsoIbrZXk= Archived-At: Subject: Re: [sipcore] Session-timer issue X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Sep 2017 16:11:00 -0000 On 9/7/17 7:30 AM, R.Jesske@telekom.de wrote: > Hi, > seen from my point of view the UAC should ignore the Session timer proposal within the UPDATE. > As long as the negotiation is ongoing. > > Nevertheless we have also observed this curious session timer behavior in our network. > > I think we need some clarifications to the RFC. Perhaps also to other sections to make it more readable. > My experience is that people have problems in following how the session timer should work within a complex SIP networks (e.g. IMS). > > What is about updating the RFC4028. Like most of the older SIP RFCs, it probably deserves an update. The problem is whether going to the trouble will have any effect on implementations. I think the most we should hope to do is *clarify* in cases where there is ambiguity, so that when interoperability problems arise it is clear who needs to change. Thanks, Paul > Best Regards > > Roland > >> -----Ursprüngliche Nachricht----- >> Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von Christer >> Holmberg >> Gesendet: Donnerstag, 7. September 2017 11:34 >> An: Paul Kyzivat ; sipcore@ietf.org >> Betreff: Re: [sipcore] Session-timer issue >> >> Hi, >> >>>> The following issue has been around for some time already (there is >>>> also an errata #4744), and as it causes problems (the INVITE is >>>> rejected with a >>>> 480 response) in deployed networks, so I think it needs to be fixed. >>>> People seem to have different opinions on which node is acting >>>> wrongly, so I hope we can sort it out :) >>> >>> This is an interesting problem. I agree that it is unclear exactly what >>> ought to happen in this case. (But I don't understand why someone >>> thinks a 480 is a good way to resolve it.) >> >> Whether 480 is the best solution or not is not the issue, in my opinion. >> One could also claim that the UPDATE should be rejected. Etc. >> >> The issue is that there is a session-timer negotiation "race condition", and we >> should forbid that (rejecting the UPDATE could be part of such solution). >> >> Regards, >> >> Christer >> >> >> >> >> >>> >>> Thanks, >>> Paul >>> >>>> Below is a call flow showing the problem: >>>> >>>> >>>> UA Proxy AS >>>> >>>> -------------------> >>>> INVITE (#1) >>>> Supported:timer >>>> SE:refresher=uac >>>> >>>> -------------------> >>>> INVITE (#2) >>>> Supported:timer >>>> SE:refresher=uac >>>> >>>> >>>> <------------------- >>>> 18x (#3) >>>> >>>> <------------------- >>>> 18x (#4) >>>> >>>> ++++++ early dialog established +++++++ >>>> >>>> <------------------- >>>> UPDATE (#5) >>>> Supported:timer >>>> SE:refresher=uas >>>> >>>> <------------------- >>>> UPDATE (#6) >>>> Supported:timer >>>> SE:refresher=uas >>>> >>>> >>>> -------------------> >>>> 200 (UPDATE) (#7) >>>> >>>> -------------------> >>>> 200 (UPDATE) (#8) >>>> Require:timer >>>> SE:refresher=uac >>>> >>>> >>>> <------------------- >>>> 480 (INVITE) (#9) >>>> >>>> <------------------- >>>> 480 (INVITE (#10) >>>> >>>> >>>> >>>> >>>> A few things to note: >>>> >>>> >>>> N1: The 18x does not contain the SE (Session-Expires) header field, >>>> because according to section 4 of RFC 4028 the header field >>>> is only >>>> allowed in INVITE, UPDATE and 2xx. So, when the UPDATE request >>>> (#5) is sent, the initial session timer negotiation is still >>>> ongoing. >>>> >>>> >>>> N2: The UPDATE request (#5) contains a Session-Expires header field. >>>> Section 7.4 of RFC 4028 says: >>>> >>>> "In a session refresh request sent within a dialog with an active >>>> session timer, the Session-Expires header field SHOULD be >>>> present." >>>> >>>> Now, a dialog (early) HAS been established when the UPDATE >> request is >>>> sent, but as the initial session timer negotiation is still >>>> ongoing, I assume the session timer isn¹t yet "active"? >>>> >>>> >>>> N3: The UPDATE 200 response (#7) does not contain the Session-Expires >>>> header field. It is added by the proxy, based on the >>>> procedures in >>>> Section 8.2 of RFC 4028: >>>> >>>> "Because there is no Session-Expires or Require header >>>> field >>>> in the response, the proxy knows that it is the first >>>> session-timer-aware proxy to receive the response. >>>> This proxy >>>> MUST insert a Session-Expires header field into the >>>> response >>>> with the value it remembered from the forwarded request. >>>> It >>>> MUST >>>> set the value of The 'refresher' parameter to 'uac'. >>>> The proxy MUST >>>> add the 'timer' option tag to any Require header field >>>> in the >>>> response, and if none was present, add the Require >>>> header field with >>>> that value before forwarding it upstream." >>>> >>>> >>>> Now, one could argue that the UA should include something in the >>>> UPDATE response (#7), but I think that is not a solution as the UA >>>> may be confused. >>>> Instead, based on my understanding of the text in section 7.4 (see >>>> above) the UPDATE request (#5) should not contain any session timer >>>> information. This is also more or less what the errata suggests. >>>> >>>> Comments? >>>> >>>> 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 >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore > From nobody Thu Sep 7 09:38:34 2017 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 DA2DC132F37 for ; Thu, 7 Sep 2017 09:38:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 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, URIBL_BLOCKED=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 x_SfPM0bgtOr for ; Thu, 7 Sep 2017 09:38:30 -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 85DA5132CE9 for ; Thu, 7 Sep 2017 09:38:30 -0700 (PDT) X-AuditID: c1b4fb3a-617ff700000051a3-d5-59b17604707d Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id D7.48.20899.40671B95; Thu, 7 Sep 2017 18:38:28 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.194]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0352.000; Thu, 7 Sep 2017 18:38:28 +0200 From: Christer Holmberg To: Paul Kyzivat , "R.Jesske@telekom.de" , "sipcore@ietf.org" Thread-Topic: AW: [sipcore] Session-timer issue Thread-Index: AQHTJwA95Xe7gTczX0KOZ3DfWO32OKKn2eUAgAFjC4CAAAyqUIAALqQAgAAoIkA= Date: Thu, 7 Sep 2017 16:38:27 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B562A0358@ESESSMB109.ericsson.se> References: <4088ba93-36dd-6746-67ab-cf01bebb6cbe@alum.mit.edu> <85c9c45d14b148fda06c2faadf91ec6f@HE105828.emea1.cds.t-internal.com> 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.149] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKLMWRmVeSWpSXmKPExsUyM2K7hC5L2cZIg+a5ahYrNhxgtWi608Vm 8fXHJjYHZo+/7z8weSxZ8pPJo+2lQgBzFJdNSmpOZllqkb5dAldGz6EzbAWbPCouHl/K3sB4 xK2LkYNDQsBE4v8dtS5GLg4hgSOMEj8vnGCFcBYzStz7tpMZpIhNwEKi+592FyMnh4hAncT7 nmY2EFtYQE9iwsJzLBBxfYk/n4+yQ9h+Eh9X/mMCsVkEVCTef/nKCjKGV8BXYnWXJcT4BUwS l071sYHEOQUcJJ6sFgQpZxQQk/h+ag1YK7OAuMStJ/PBbAkBAYkle84zQ9iiEi8f/2OFsJUk 1h7ezgIyhllAU2L9Ln2IVkWJKd0Pwa7hFRCUODnzCcsERpFZSKbOQuiYhaRjFpKOBYwsqxhF i1OLi3PTjYz0Uosyk4uL8/P08lJLNjECI+Pglt9WOxgPPnc8xCjAwajEw7sjZ2OkEGtiWXFl 7iFGCQ5mJRHeHYVAId6UxMqq1KL8+KLSnNTiQ4zSHCxK4rwO+y5ECAmkJ5akZqemFqQWwWSZ ODilGhhDkspeZig+Tbq4vsbwekmW7IwHvCZTVwV7Pz9VvHPdpC9OkeKzSx+ZXlpX1NJ28p71 M7UnsfXb5aeEC5xc0CG90n6h2vrJ09d93xXE4fdGgyH7htLcrQLlH9w0VZo8FRgPLVrKYHJm 8ibjKJ+djFMTeT9uKUgpTS0KSAzQTC1Vb7G4IVhYu0yJpTgj0VCLuag4EQBDzqhJiAIAAA== Archived-At: Subject: Re: [sipcore] Session-timer issue X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Sep 2017 16:38:33 -0000 SGksDQoNCj4+IHNlZW4gZnJvbSBteSBwb2ludCBvZiB2aWV3IHRoZSBVQUMgc2hvdWxkIGlnbm9y ZSB0aGUgU2Vzc2lvbiB0aW1lciBwcm9wb3NhbCB3aXRoaW4gdGhlIFVQREFURS4NCj4+IEFzIGxv bmcgYXMgdGhlIG5lZ290aWF0aW9uIGlzICBvbmdvaW5nLg0KPj4gDQo+PiBOZXZlcnRoZWxlc3Mg d2UgaGF2ZSBhbHNvIG9ic2VydmVkIHRoaXMgY3VyaW91cyBzZXNzaW9uIHRpbWVyIGJlaGF2aW9y IGluIG91ciBuZXR3b3JrLg0KPj4gDQo+PiBJIHRoaW5rIHdlIG5lZWQgc29tZSBjbGFyaWZpY2F0 aW9ucyB0byB0aGUgUkZDLiBQZXJoYXBzIGFsc28gdG8gb3RoZXIgc2VjdGlvbnMgdG8gbWFrZSBp dCBtb3JlIHJlYWRhYmxlLg0KPj4gTXkgZXhwZXJpZW5jZSBpcyB0aGF0IHBlb3BsZSBoYXZlIHBy b2JsZW1zIGluIGZvbGxvd2luZyBob3cgdGhlIHNlc3Npb24gdGltZXIgc2hvdWxkIHdvcmsgd2l0 aGluIGEgY29tcGxleCBTSVAgbmV0d29ya3MgKGUuZy4gSU1TKS4NCj4+IA0KPj4gV2hhdCBpcyBh Ym91dCB1cGRhdGluZyB0aGUgUkZDNDAyOC4NCj4NCj4gTGlrZSBtb3N0IG9mIHRoZSBvbGRlciBT SVAgUkZDcywgaXQgcHJvYmFibHkgZGVzZXJ2ZXMgYW4gdXBkYXRlLiBUaGUgcHJvYmxlbSBpcyB3 aGV0aGVyIGdvaW5nIHRvIHRoZSB0cm91YmxlIHdpbGwgaGF2ZSBhbnkgZWZmZWN0IG9uIGltcGxl bWVudGF0aW9ucy4gSSB0aGluayB0aGUgbW9zdCB3ZSA+IHNob3VsZCBob3BlIHRvIGRvIGlzICpj bGFyaWZ5KiBpbiBjYXNlcyB3aGVyZSB0aGVyZSBpcyBhbWJpZ3VpdHksIHNvIHRoYXQgd2hlbiBp bnRlcm9wZXJhYmlsaXR5IHByb2JsZW1zIGFyaXNlIGl0IGlzIGNsZWFyIHdobyBuZWVkcyB0byBj aGFuZ2UuDQoNClllcy4gSW4gbXkgY2FzZSwgaW1wbGVtZW50YXRpb24ocykgV0lMTCBiZSBjaGFu Z2VkLiBUaGUgcXVlc3Rpb24gaXMgV0hJQ0ggaW1wbGVtZW50YXRpb24ocykgOikNCg0KU28sIG15 IHN1Z2dlc3Rpb24gd291bGQgYmU6DQoNCjEpCVNwZWNpZnkvY2xhcmlmeSB0aGF0IFNFIG11c3Qg bm90IGJlIHNlbnQgZHVyaW5nIHNlc3Npb24tdGltZXIgbmVnb3RpYXRpb24NCjIpCVNwZWNpZnkg dGhhdCBvbmUgbXVzdCBzZW5kIGEgNDkxIChvciBzb21lIG90aGVyIG1vcmUgYXBwcm9wcmlhdGUg Y29kZSkgcmVzcG9uc2UgaWYgcmVjZWl2aW5nIFNFIGR1cmluZyBzZXNzaW9uLXRpbWVyIG5lZ290 aWF0aW9uDQoNCkZvciB0aGUgYWJvdmUsIEkgdGhpbmsgd2UgY2FuIGRvIGl0IHVzaW5nIGFuIGVy cmF0YS4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQoNCj4+IC0tLS0tVXJzcHLDvG5nbGlj aGUgTmFjaHJpY2h0LS0tLS0NCj4+IFZvbjogc2lwY29yZSBbbWFpbHRvOnNpcGNvcmUtYm91bmNl c0BpZXRmLm9yZ10gSW0gQXVmdHJhZyB2b24gDQo+PiBDaHJpc3RlciBIb2xtYmVyZw0KPj4gR2Vz ZW5kZXQ6IERvbm5lcnN0YWcsIDcuIFNlcHRlbWJlciAyMDE3IDExOjM0DQo+PiBBbjogUGF1bCBL eXppdmF0IDxwa3l6aXZhdEBhbHVtLm1pdC5lZHU+OyBzaXBjb3JlQGlldGYub3JnDQo+PiBCZXRy ZWZmOiBSZTogW3NpcGNvcmVdIFNlc3Npb24tdGltZXIgaXNzdWUNCj4+DQo+PiBIaSwNCj4+DQo+ Pj4+IFRoZSBmb2xsb3dpbmcgaXNzdWUgaGFzIGJlZW4gYXJvdW5kIGZvciBzb21lIHRpbWUgYWxy ZWFkeSAodGhlcmUgaXMgDQo+Pj4+IGFsc28gIGFuIGVycmF0YSAjNDc0NCksIGFuZCBhcyBpdCBj YXVzZXMgcHJvYmxlbXMgKHRoZSBJTlZJVEUgaXMgDQo+Pj4+IHJlamVjdGVkIHdpdGggYQ0KPj4+ PiA0ODAgcmVzcG9uc2UpIGluIGRlcGxveWVkIG5ldHdvcmtzLCBzbyBJIHRoaW5rIGl0IG5lZWRz IHRvIGJlIGZpeGVkLg0KPj4+PiBQZW9wbGUgc2VlbSB0byBoYXZlIGRpZmZlcmVudCBvcGluaW9u cyBvbiB3aGljaCBub2RlIGlzIGFjdGluZyANCj4+Pj4gd3JvbmdseSwgc28gIEkgaG9wZSB3ZSBj YW4gc29ydCBpdCBvdXQgOikNCj4+Pg0KPj4+IFRoaXMgaXMgYW4gaW50ZXJlc3RpbmcgcHJvYmxl bS4gSSBhZ3JlZSB0aGF0IGl0IGlzIHVuY2xlYXIgZXhhY3RseSANCj4+PiB3aGF0IG91Z2h0IHRv IGhhcHBlbiBpbiB0aGlzIGNhc2UuIChCdXQgSSBkb24ndCB1bmRlcnN0YW5kIHdoeSANCj4+PiBz b21lb25lIHRoaW5rcyBhIDQ4MCBpcyBhIGdvb2Qgd2F5IHRvIHJlc29sdmUgaXQuKQ0KPj4NCj4+ IFdoZXRoZXIgNDgwIGlzIHRoZSBiZXN0IHNvbHV0aW9uIG9yIG5vdCBpcyBub3QgdGhlIGlzc3Vl LCBpbiBteSBvcGluaW9uLg0KPj4gT25lIGNvdWxkIGFsc28gY2xhaW0gdGhhdCB0aGUgVVBEQVRF IHNob3VsZCBiZSByZWplY3RlZC4gRXRjLg0KPj4NCj4+IFRoZSBpc3N1ZSBpcyB0aGF0IHRoZXJl IGlzIGEgc2Vzc2lvbi10aW1lciBuZWdvdGlhdGlvbiAicmFjZSANCj4+IGNvbmRpdGlvbiIsIGFu ZCB3ZSBzaG91bGQgZm9yYmlkIHRoYXQgKHJlamVjdGluZyB0aGUgVVBEQVRFIGNvdWxkIGJlIHBh cnQgb2Ygc3VjaCBzb2x1dGlvbikuDQo+Pg0KPj4gUmVnYXJkcywNCj4+DQo+PiBDaHJpc3Rlcg0K Pj4NCj4+DQo+Pg0KPj4NCj4+DQo+Pj4NCj4+PiAJVGhhbmtzLA0KPj4+IAlQYXVsDQo+Pj4NCj4+ Pj4gQmVsb3cgaXMgYSBjYWxsIGZsb3cgc2hvd2luZyB0aGUgcHJvYmxlbToNCj4+Pj4NCj4+Pj4N Cj4+Pj4gVUEgICAgICAgICAgICAgICAgUHJveHkgICAgICAgICAgICAgICAgQVMNCj4+Pj4NCj4+ Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLT4NCj4+Pj4gSU5WSVRFICgjMSkNCj4+Pj4gU3VwcG9ydGVk OnRpbWVyDQo+Pj4+IFNFOnJlZnJlc2hlcj11YWMNCj4+Pj4NCj4+Pj4gICAgICAgICAgICAgICAg ICAgICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0+DQo+Pj4+ICAgICAgICAgICAgICAgICAgICAgICBJ TlZJVEUgKCMyKQ0KPj4+PiAgICAgICAgICAgICAgICAgICAgICAgU3VwcG9ydGVkOnRpbWVyDQo+ Pj4+ICAgICAgICAgICAgICAgICAgICAgICBTRTpyZWZyZXNoZXI9dWFjDQo+Pj4+DQo+Pj4+DQo+ Pj4+ICAgICAgICAgICAgICAgICAgICAgICA8LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+PiAgICAg ICAgICAgICAgICAgICAgICAgMTh4ICgjMykNCj4+Pj4NCj4+Pj4gPC0tLS0tLS0tLS0tLS0tLS0t LS0NCj4+Pj4gMTh4ICgjNCkNCj4+Pj4NCj4+Pj4gKysrKysrIGVhcmx5IGRpYWxvZyBlc3RhYmxp c2hlZCArKysrKysrDQo+Pj4+DQo+Pj4+ICAgICAgICAgICAgICAgICAgICAgICA8LS0tLS0tLS0t LS0tLS0tLS0tLQ0KPj4+PiAgICAgICAgICAgICAgICAgICAgICAgVVBEQVRFICgjNSkNCj4+Pj4g ICAgICAgICAgICAgICAgICAgICAgIFN1cHBvcnRlZDp0aW1lcg0KPj4+PiAgICAgICAgICAgICAg ICAgICAgICAgU0U6cmVmcmVzaGVyPXVhcw0KPj4+Pg0KPj4+PiA8LS0tLS0tLS0tLS0tLS0tLS0t LQ0KPj4+PiBVUERBVEUgKCM2KQ0KPj4+PiBTdXBwb3J0ZWQ6dGltZXINCj4+Pj4gU0U6cmVmcmVz aGVyPXVhcw0KPj4+Pg0KPj4+Pg0KPj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tPg0KPj4+PiAyMDAg KFVQREFURSkgKCM3KQ0KPj4+Pg0KPj4+PiAgICAgICAgICAgICAgICAgICAgICAgLS0tLS0tLS0t LS0tLS0tLS0tLT4NCj4+Pj4gICAgICAgICAgICAgICAgICAgICAgIDIwMCAoVVBEQVRFKSAoIzgp DQo+Pj4+ICAgICAgICAgICAgICAgICAgICAgICBSZXF1aXJlOnRpbWVyDQo+Pj4+ICAgICAgICAg ICAgICAgICAgICAgICBTRTpyZWZyZXNoZXI9dWFjDQo+Pj4+DQo+Pj4+DQo+Pj4+ICAgICAgICAg ICAgICAgICAgICAgICA8LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+PiAgICAgICAgICAgICAgICAg ICAgICAgNDgwIChJTlZJVEUpICgjOSkNCj4+Pj4NCj4+Pj4gPC0tLS0tLS0tLS0tLS0tLS0tLS0N Cj4+Pj4gNDgwIChJTlZJVEUgKCMxMCkNCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4gQSBm ZXcgdGhpbmdzIHRvIG5vdGU6DQo+Pj4+DQo+Pj4+DQo+Pj4+IE4xOglUaGUgMTh4IGRvZXMgbm90 IGNvbnRhaW4gdGhlIFNFIChTZXNzaW9uLUV4cGlyZXMpIGhlYWRlciBmaWVsZCwNCj4+Pj4gICAg ICAgICAgIGJlY2F1c2UgYWNjb3JkaW5nIHRvIHNlY3Rpb24gNCBvZiBSRkMgNDAyOCB0aGUgaGVh ZGVyIA0KPj4+PiBmaWVsZCBpcyBvbmx5DQo+Pj4+ICAgICAgICAgICBhbGxvd2VkIGluIElOVklU RSwgVVBEQVRFIGFuZCAyeHguIFNvLCB3aGVuIHRoZSBVUERBVEUgcmVxdWVzdA0KPj4+PiAgICAg ICAgICAgKCM1KSBpcyBzZW50LCB0aGUgaW5pdGlhbCBzZXNzaW9uIHRpbWVyIG5lZ290aWF0aW9u IGlzIHN0aWxsDQo+Pj4+ICAgICAgICAgICBvbmdvaW5nLg0KPj4+Pg0KPj4+Pg0KPj4+PiBOMjoJ VGhlIFVQREFURSByZXF1ZXN0ICgjNSkgY29udGFpbnMgYSBTZXNzaW9uLUV4cGlyZXMgaGVhZGVy IGZpZWxkLg0KPj4+PiAgICAgICAgICAgU2VjdGlvbiA3LjQgb2YgUkZDIDQwMjggc2F5czoNCj4+ Pj4NCj4+Pj4gCSAgICAgIkluIGEgc2Vzc2lvbiByZWZyZXNoIHJlcXVlc3Qgc2VudCB3aXRoaW4g YSBkaWFsb2cgd2l0aCBhbiBhY3RpdmUNCj4+Pj4gCSAgICAgIHNlc3Npb24gdGltZXIsIHRoZSBT ZXNzaW9uLUV4cGlyZXMgaGVhZGVyIGZpZWxkIFNIT1VMRCBiZSANCj4+Pj4gcHJlc2VudC4iDQo+ Pj4+DQo+Pj4+IAlOb3csIGEgZGlhbG9nIChlYXJseSkgSEFTIGJlZW4gZXN0YWJsaXNoZWQgd2hl biB0aGUgVVBEQVRFDQo+PiByZXF1ZXN0IGlzDQo+Pj4+ICAgICAgICAgICBzZW50LCBidXQgYXMg dGhlIGluaXRpYWwgc2Vzc2lvbiB0aW1lciBuZWdvdGlhdGlvbiBpcyBzdGlsbA0KPj4+PiAgICAg ICAgICAgb25nb2luZywgSSBhc3N1bWUgdGhlIHNlc3Npb24gdGltZXIgaXNuwrl0IHlldCAiYWN0 aXZlIj8NCj4+Pj4NCj4+Pj4NCj4+Pj4gTjM6CVRoZSBVUERBVEUgMjAwIHJlc3BvbnNlICgjNykg ZG9lcyBub3QgY29udGFpbiB0aGUgU2Vzc2lvbi1FeHBpcmVzDQo+Pj4+ICAgICAgICAgICBoZWFk ZXIgZmllbGQuIEl0IGlzIGFkZGVkIGJ5IHRoZSBwcm94eSwgYmFzZWQgb24gdGhlIA0KPj4+PiBw cm9jZWR1cmVzIGluDQo+Pj4+ICAgICAgICAgICBTZWN0aW9uIDguMiBvZiBSRkMgNDAyODoNCj4+ Pj4NCj4+Pj4gICAgICAgICAgICAgICAgIkJlY2F1c2UgdGhlcmUgaXMgbm8gU2Vzc2lvbi1FeHBp cmVzIG9yIFJlcXVpcmUgDQo+Pj4+IGhlYWRlciBmaWVsZA0KPj4+PiAgICAgICAgICAgICAgICAg aW4gdGhlIHJlc3BvbnNlLCB0aGUgcHJveHkga25vd3MgdGhhdCBpdCBpcyB0aGUgZmlyc3QNCj4+ Pj4gICAgICAgICAgICAgICAgIHNlc3Npb24tdGltZXItYXdhcmUgcHJveHkgdG8gcmVjZWl2ZSB0 aGUgcmVzcG9uc2UuDQo+Pj4+IFRoaXMgIHByb3h5DQo+Pj4+ICAgICAgICAgICAgICAgICBNVVNU IGluc2VydCBhIFNlc3Npb24tRXhwaXJlcyBoZWFkZXIgZmllbGQgaW50byB0aGUgDQo+Pj4+IHJl c3BvbnNlDQo+Pj4+ICAgICAgICAgICAgICAgICB3aXRoIHRoZSB2YWx1ZSBpdCByZW1lbWJlcmVk IGZyb20gdGhlIGZvcndhcmRlZCByZXF1ZXN0Lg0KPj4+PiBJdA0KPj4+PiBNVVNUDQo+Pj4+ICAg ICAgICAgICAgICAgICBzZXQgdGhlIHZhbHVlIG9mIFRoZSAncmVmcmVzaGVyJyBwYXJhbWV0ZXIg dG8gJ3VhYycuDQo+Pj4+IFRoZSAgcHJveHkgTVVTVA0KPj4+PiAgICAgICAgICAgICAgICAgYWRk IHRoZSAndGltZXInIG9wdGlvbiB0YWcgdG8gYW55IFJlcXVpcmUgaGVhZGVyIA0KPj4+PiBmaWVs ZCBpbiAgdGhlDQo+Pj4+ICAgICAgICAgICAgICAgICByZXNwb25zZSwgYW5kIGlmIG5vbmUgd2Fz IHByZXNlbnQsIGFkZCB0aGUgUmVxdWlyZSANCj4+Pj4gaGVhZGVyICBmaWVsZCB3aXRoDQo+Pj4+ ICAgICAgICAgICAgICAgICB0aGF0IHZhbHVlIGJlZm9yZSBmb3J3YXJkaW5nIGl0IHVwc3RyZWFt LiINCj4+Pj4NCj4+Pj4NCj4+Pj4gTm93LCBvbmUgY291bGQgYXJndWUgdGhhdCB0aGUgVUEgc2hv dWxkIGluY2x1ZGUgc29tZXRoaW5nIGluIHRoZSANCj4+Pj4gVVBEQVRFIHJlc3BvbnNlICgjNyks IGJ1dCBJIHRoaW5rIHRoYXQgaXMgbm90IGEgc29sdXRpb24gYXMgdGhlIFVBIA0KPj4+PiBtYXkg YmUgY29uZnVzZWQuDQo+Pj4+IEluc3RlYWQsIGJhc2VkIG9uIG15IHVuZGVyc3RhbmRpbmcgb2Yg dGhlIHRleHQgaW4gc2VjdGlvbiA3LjQgKHNlZQ0KPj4+PiBhYm92ZSkgdGhlIFVQREFURSByZXF1 ZXN0ICgjNSkgc2hvdWxkIG5vdCBjb250YWluIGFueSBzZXNzaW9uIHRpbWVyIA0KPj4+PiBpbmZv cm1hdGlvbi4gVGhpcyBpcyBhbHNvIG1vcmUgb3IgbGVzcyB3aGF0IHRoZSBlcnJhdGEgc3VnZ2Vz dHMuDQo+Pj4+DQo+Pj4+IENvbW1lbnRzPw0KPj4+Pg0KPj4+PiBSZWdhcmRzLA0KPj4+Pg0KPj4+ PiBDaHJpc3Rlcg0KPj4+Pg0KPj4+Pg0KPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPj4+PiBzaXBjb3JlIG1haWxpbmcgbGlzdA0KPj4+PiBzaXBj b3JlQGlldGYub3JnDQo+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v c2lwY29yZQ0KPj4+Pg0KPj4+DQo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4+PiBzaXBjb3JlIG1haWxpbmcgbGlzdA0KPj4+IHNpcGNvcmVAaWV0 Zi5vcmcNCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUN Cj4+DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K Pj4gc2lwY29yZSBtYWlsaW5nIGxpc3QNCj4+IHNpcGNvcmVAaWV0Zi5vcmcNCj4+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZQ0KPiANCg0K From nobody Wed Sep 13 02:40:42 2017 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 7CB4E133018; Wed, 13 Sep 2017 02:40:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 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, URIBL_BLOCKED=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 l8VCeaSukBKu; Wed, 13 Sep 2017 02:40:39 -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 114581321A7; Wed, 13 Sep 2017 02:40:38 -0700 (PDT) X-AuditID: c1b4fb25-d31059c000005333-da-59b8fd14235e Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id B8.37.21299.41DF8B95; Wed, 13 Sep 2017 11:40:36 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.194]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0352.000; Wed, 13 Sep 2017 11:36:55 +0200 From: Christer Holmberg To: "sipcore@ietf.org" CC: "sipcore-chairs@ietf.org" , Ben Campbell Thread-Topic: Draft new: draft-holmberg-sipcore-sessiontimer-race-00 [was: Session-timer issue] Thread-Index: AQHTLHPWL1r8lrWpXUOfpdcCGedkLA== Date: Wed, 13 Sep 2017 09:36:55 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.6.170621 x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="windows-1254" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphkeLIzCtJLcpLzFFi42KZGbHdQ1fk745Ig0v7BCzmd55mt+j9vJDZ 4uuPTWwOzB5Llvxk8pi18wlLAFMUl01Kak5mWWqRvl0CV8atxw3sBQdtKx53bmZvYFyh18XI ySEhYCJx+fN5pi5GLg4hgSOMEvfvnmKGcJYwSuxY8paxi5GDg03AQqL7nzZIg4iApsTyb1vZ QcLMApESt7fVg4SFBWIkNszZywpRkijx79YiJghbT+L464PMIDaLgKrEnB2XGEFsXgFriTV/ 5rKD2IwCYhLfT60Bq2cWEJe49WQ+E8RtAhJL9pxnhrBFJV4+/gc2XxRo5uyNh1gg4ooS7U8b GCF6DSSOnLvJCmFbS0yY+okFwtaWWLbwNTPEXkGJkzOfsExgFJ2FZN0sJO2zkLTPQtI+C0n7 AkbWVYyixanFSbnpRsZ6qUWZycXF+Xl6eaklmxiBcXRwy2/VHYyX3zgeYhTgYFTi4X19Y0ek EGtiWXFl7iFGCQ5mJRHeY5+AQrwpiZVVqUX58UWlOanFhxilOViUxHkd912IEBJITyxJzU5N LUgtgskycXBKNTC6d3fWVmu47ZY1XNP/vvT9Rr2gk/rOn89nX/6Zv2elecrPbTmrH0dqanHI 3UrJUT2o+fn3y7MtuWdOrVLZsvtjLX/WcvfTH/mWicZw//t4WtfJpy47/OnGuOVXzFiY/d4f drQWbEt9aK/oEvauY6bpdAmDBerClVs9Zu6+fveP/K/Lx8OUsriVWIozEg21mIuKEwE9cPmL nwIAAA== Archived-At: Subject: [sipcore] Draft new: draft-holmberg-sipcore-sessiontimer-race-00 [was: Session-timer issue] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 09:40:41 -0000 Hi, I have submitted a draft, draft-holmberg-sipcore-sessiontimer-race-00, that describes the problem, and updates RFC 4028 based on the suggested solution presented earlier. Now, if people think an errata is more appropriate I have no problem with that. However, I think we DO need to fix this, because it is causing problems in deployed networks. https://www.ietf.org/id/draft-holmberg-sipcore-sessiontimer-race-00.txt For the GitHub folks: https://github.com/cdh4u/draft-sessiontimer-race Regards, Christer On 07/09/17 19:38, "sipcore on behalf of Christer Holmberg" wrote: >Hi, > >>> seen from my point of view the UAC should ignore the Session timer >>>proposal within the UPDATE. >>> As long as the negotiation is ongoing. >>>=20 >>> Nevertheless we have also observed this curious session timer behavior >>>in our network. >>>=20 >>> I think we need some clarifications to the RFC. Perhaps also to other >>>sections to make it more readable. >>> My experience is that people have problems in following how the >>>session timer should work within a complex SIP networks (e.g. IMS). >>>=20 >>> What is about updating the RFC4028. >> >> Like most of the older SIP RFCs, it probably deserves an update. The >>problem is whether going to the trouble will have any effect on >>implementations. I think the most we > should hope to do is *clarify* in >>cases where there is ambiguity, so that when interoperability problems >>arise it is clear who needs to change. > >Yes. In my case, implementation(s) WILL be changed. The question is WHICH >implementation(s) :) > >So, my suggestion would be: > >1) Specify/clarify that SE must not be sent during session-timer >negotiation >2) Specify that one must send a 491 (or some other more appropriate code) >response if receiving SE during session-timer negotiation > >For the above, I think we can do it using an errata. > >Regards, > >Christer > > > >>> -----Urspr=FCngliche Nachricht----- >>> Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von >>> Christer Holmberg >>> Gesendet: Donnerstag, 7. September 2017 11:34 >>> An: Paul Kyzivat ; sipcore@ietf.org >>> Betreff: Re: [sipcore] Session-timer issue >>> >>> Hi, >>> >>>>> The following issue has been around for some time already (there is >>>>> also an errata #4744), and as it causes problems (the INVITE is >>>>> rejected with a >>>>> 480 response) in deployed networks, so I think it needs to be fixed. >>>>> People seem to have different opinions on which node is acting >>>>> wrongly, so I hope we can sort it out :) >>>> >>>> This is an interesting problem. I agree that it is unclear exactly >>>> what ought to happen in this case. (But I don't understand why >>>> someone thinks a 480 is a good way to resolve it.) >>> >>> Whether 480 is the best solution or not is not the issue, in my >>>opinion. >>> One could also claim that the UPDATE should be rejected. Etc. >>> >>> The issue is that there is a session-timer negotiation "race >>> condition", and we should forbid that (rejecting the UPDATE could be >>>part of such solution). >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>> >>> >>>> >>>> Thanks, >>>> Paul >>>> >>>>> Below is a call flow showing the problem: >>>>> >>>>> >>>>> UA Proxy AS >>>>> >>>>> -------------------> >>>>> INVITE (#1) >>>>> Supported:timer >>>>> SE:refresher=3Duac >>>>> >>>>> -------------------> >>>>> INVITE (#2) >>>>> Supported:timer >>>>> SE:refresher=3Duac >>>>> >>>>> >>>>> <------------------- >>>>> 18x (#3) >>>>> >>>>> <------------------- >>>>> 18x (#4) >>>>> >>>>> ++++++ early dialog established +++++++ >>>>> >>>>> <------------------- >>>>> UPDATE (#5) >>>>> Supported:timer >>>>> SE:refresher=3Duas >>>>> >>>>> <------------------- >>>>> UPDATE (#6) >>>>> Supported:timer >>>>> SE:refresher=3Duas >>>>> >>>>> >>>>> -------------------> >>>>> 200 (UPDATE) (#7) >>>>> >>>>> -------------------> >>>>> 200 (UPDATE) (#8) >>>>> Require:timer >>>>> SE:refresher=3Duac >>>>> >>>>> >>>>> <------------------- >>>>> 480 (INVITE) (#9) >>>>> >>>>> <------------------- >>>>> 480 (INVITE (#10) >>>>> >>>>> >>>>> >>>>> >>>>> A few things to note: >>>>> >>>>> >>>>> N1: The 18x does not contain the SE (Session-Expires) header field, >>>>> because according to section 4 of RFC 4028 the header >>>>> field is only >>>>> allowed in INVITE, UPDATE and 2xx. So, when the UPDATE >>>>>request >>>>> (#5) is sent, the initial session timer negotiation is >>>>>still >>>>> ongoing. >>>>> >>>>> >>>>> N2: The UPDATE request (#5) contains a Session-Expires header field. >>>>> Section 7.4 of RFC 4028 says: >>>>> >>>>> "In a session refresh request sent within a dialog with an >>>>>active >>>>> session timer, the Session-Expires header field SHOULD be >>>>> present." >>>>> >>>>> Now, a dialog (early) HAS been established when the UPDATE >>> request is >>>>> sent, but as the initial session timer negotiation is still >>>>> ongoing, I assume the session timer isn=B9t yet "active"? >>>>> >>>>> >>>>> N3: The UPDATE 200 response (#7) does not contain the Session-Expires >>>>> header field. It is added by the proxy, based on the >>>>> procedures in >>>>> Section 8.2 of RFC 4028: >>>>> >>>>> "Because there is no Session-Expires or Require >>>>> header field >>>>> in the response, the proxy knows that it is the first >>>>> session-timer-aware proxy to receive the response. >>>>> This proxy >>>>> MUST insert a Session-Expires header field into the >>>>> response >>>>> with the value it remembered from the forwarded >>>>>request. >>>>> It >>>>> MUST >>>>> set the value of The 'refresher' parameter to 'uac'. >>>>> The proxy MUST >>>>> add the 'timer' option tag to any Require header >>>>> field in the >>>>> response, and if none was present, add the Require >>>>> header field with >>>>> that value before forwarding it upstream." >>>>> >>>>> >>>>> Now, one could argue that the UA should include something in the >>>>> UPDATE response (#7), but I think that is not a solution as the UA >>>>> may be confused. >>>>> Instead, based on my understanding of the text in section 7.4 (see >>>>> above) the UPDATE request (#5) should not contain any session timer >>>>> information. This is also more or less what the errata suggests. >>>>> >>>>> Comments? >>>>> >>>>> 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 >>> >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>=20 > >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore From nobody Wed Sep 13 05:29:43 2017 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 328911333C9; Wed, 13 Sep 2017 05:29:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=proximus.com header.b=wu7kHiMx; dkim=pass (1024-bit key) header.d=proximuscorp.onmicrosoft.com header.b=DL1FAw6s 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 KfBM2iO7SCKU; Wed, 13 Sep 2017 05:29:37 -0700 (PDT) Received: from mx28.belgacom.be (mx28.belgacom.be [213.181.45.238]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CCA31241F3; Wed, 13 Sep 2017 05:29:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=proximus.com; i=@proximus.com; q=dns/txt; s=dkim; t=1505305776; x=1536841776; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=S6Wo29y3jWSmh8sJyGJmTLqnTKU49fqVaziI4IsnkPs=; b=wu7kHiMxoZ5ab5Jek79kaB+2jslpW2dy5as286WbKMrIYTtmAsIpRxsV BX6B3Mw2xc+SFf+gSOxmRc+6C6XCRPuc67XOvW5/SJ+ivC/EWz2+qCB5V LNzgxas30WWZ7wdPRRxEmkgQFhttWioDHza9PSxQXTN+IZyhv6VPVT2A5 Y=; X-IronPort-AV: E=Sophos;i="5.42,387,1500933600"; d="scan'208";a="23778706" Received: from a07584.bgc.net ([10.120.80.100]) by mx28.belgacom.be with ESMTP; 13 Sep 2017 14:29:32 +0200 X-TM-IMSS-Message-ID: <89d9422b002552bb@proximus.com> Received: from A04024.BGC.NET ([10.120.135.25]) by proximus.com ([10.120.80.100]) with ESMTP (TREND IMSS SMTP Service 7.5) id 89d9422b002552bb ; Wed, 13 Sep 2017 14:29:31 +0200 Received: from A07614.BGC.NET (10.120.135.4) by A04024.BGC.NET (10.120.135.25) with Microsoft SMTP Server (TLS) id 14.3.339.0; Wed, 13 Sep 2017 14:29:31 +0200 Received: from A07614.BGC.NET (10.120.135.4) by A07614.BGC.NET (10.120.135.4) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.32; Wed, 13 Sep 2017 14:29:30 +0200 Received: from A07625.bgc.net (10.28.29.231) by A07614.BGC.NET (10.120.135.4) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.32 via Frontend Transport; Wed, 13 Sep 2017 14:29:30 +0200 Received: from EUR01-HE1-obe.outbound.protection.outlook.com (10.28.31.158) by outlook.proximus.com (10.28.31.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.669.32; Wed, 13 Sep 2017 14:28:57 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ProximusCorp.onmicrosoft.com; s=selector1-proximus-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=L4R6HlRQ0tycRa874j1mYzkwZ4+b8lQUHh7Ynl/r5xk=; b=DL1FAw6szAWfddyO6xR/crkBZaCNF2TKPfVjRWBPV2C8Vx1jc5D9FDzHmIA2/FXtfSe6X0mhRXhwC13hSYE1OBOWHTX5HwtqBnuHDTujnjR0Ht6vbCAcD2+4uOBN80VlatFAELFEWRjf3X9wc4J1pIhfCuySFmYkJYH4PZgpzj8= Received: from DB6PR0801MB1365.eurprd08.prod.outlook.com (10.168.11.141) by DB6PR0801MB2022.eurprd08.prod.outlook.com (10.168.86.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.11; Wed, 13 Sep 2017 12:28:57 +0000 Received: from DB6PR0801MB1365.eurprd08.prod.outlook.com ([fe80::f540:9bcd:71c4:ec01]) by DB6PR0801MB1365.eurprd08.prod.outlook.com ([fe80::f540:9bcd:71c4:ec01%14]) with mapi id 15.20.0056.010; Wed, 13 Sep 2017 12:28:56 +0000 From: "VAN GEEL Jan (SPC/CSP)" To: "sipcore@ietf.org" CC: "sipcore-chairs@ietf.org" Thread-Topic: Draft new: draft-holmberg-sipcore-sessiontimer-race-00 [was: Session-timer issue] Thread-Index: AQHTLHPWL1r8lrWpXUOfpdcCGedkLKKyvpOw Date: Wed, 13 Sep 2017 12:28:56 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=jan.van.geel@proximus.com; x-originating-ip: [195.238.28.144] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB6PR0801MB2022; 6:TsbMLzAVZryVJlL8zhg+HNKdo3Cnd+1cNZbWhiAS5O9/85iJGtAy0uNYU0gU9/p+Y1logPyyo30pA+0by6pc9VVebSQyiz1v7ZG9l3qPXvSwi+4oOKMkTaLtEEH0+4Gs8FloV+Sv0S1lG3NPALbdhGGlY8Z+YpzIqKhEBmbJt1OKVkyxz40f3ACeu2g/CjFKTkFFoGTL/7nZ9uP2rm3xUSvMAXL8euzLwjdCzgI6S/42j5RX4pAHA6cmOwexCwYjrO/tyTGZz4w0xKTh01NH+hlSuy3tCWZ6+8TEIllYIBaLbcIMPISVLfYWrLCQVgXlNiyjNgdAkM7ybIiSgDyqzw==; 5:wMnqelUqcJw+L6IHT2Vc9XsrhJe83Kp2Iy4McWmlJJesLUXmAlciVK5uIsdH9ZLUcwFNjzjm8VPz/zPZ4NYEWEk8ZlF4bsPz/CVNum1JwapLwIdI9pBEEieFhGamOvAHAltm6Z4vINyNlj1dHJsQdQ==; 24:6GQcXPF6LYVyLyqCaDCrgHl6q5vBcu73bXmgNPYGTVhG0+dgkulA2p822OT8J+3aRhGfygOD4HhcjoSm7Uo+BIXyNDNAb0ZDQthos7r0uWU=; 7:mrhUNFOMjJUXWcvCAde5tOmmWM2DlER9zdZ+aAWl6J8r8pgLVYvaR1wjtwiKOYrAu09REQJcXZie9OK4g5LyHetwElctscJI8zCtpw4TfnaTa3UEJP3OOh+rJAe07UMwCv39ynWouKgigsYiD72PSV/MDWRbZbiCRoZhRt9vPmamQg4fb53c3XwQ4v7UpXIJ/0EzTte1BZZGdqo6vEtxYZet9bajiMYwHI/u03oZ9PI= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 185042ce-285d-4d70-6168-08d4faa30104 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DB6PR0801MB2022; x-ms-traffictypediagnostic: DB6PR0801MB2022: x-exchange-antispam-report-test: UriScan:(37575265505322)(166708455590820)(174211160506117); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(3002001)(10201501046)(6041248)(20161123560025)(20161123558100)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB6PR0801MB2022; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB6PR0801MB2022; x-forefront-prvs: 042957ACD7 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(366002)(376002)(346002)(199003)(51444003)(24454002)(13464003)(189002)(53936002)(7696004)(101416001)(5660300001)(561944003)(102836003)(6116002)(76176999)(50986999)(54356999)(3846002)(2351001)(7736002)(33656002)(66066001)(450100002)(4326008)(110136004)(1720100001)(5250100002)(105586002)(106356001)(2501003)(8676002)(1730700003)(25786009)(305945005)(74316002)(81156014)(3280700002)(81166006)(6246003)(97736004)(68736007)(3660700001)(229853002)(6436002)(14454004)(6506006)(8936002)(86362001)(478600001)(966005)(2906002)(230783001)(316002)(2900100001)(189998001)(53546010)(2950100002)(5640700003)(55016002)(99286003)(6916009)(9686003)(6306002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB6PR0801MB2022; H:DB6PR0801MB1365.eurprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Sep 2017 12:28:56.8197 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: e7ab81b2-1e84-4bf7-9dcb-b6fec01ed138 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0801MB2022 X-TM-AS-MatchedID: 150567-139006-700755-300045-106660-704425-705861-704774-7 03747-704179-862818-705178-706649-139703-708196-139705-303086-700075-139010 -705901-703835-703782-702143-705232-700782-700752-702131-863828-705342-7053 88-712032-701202-702067-188198-709584-703788-703454-707410-701236-703712-86 3299-701604-702643-705075-701005-852748-705386-863263-850298-701618-700295- 700624-848414-707760-706109-706737-711432-121122-701099-700661-700107-70069 3-188038-863916-113221-711068-702367-710442-701527-700839-700759-707163-703 355-860163-700472-113237-704421-705102-700999-700104-701249-700047-700607-1 39702-148004-148051-20043-42000-42003 X-OriginatorOrg: proximus.com X-TM-AS-MML: disable Archived-At: Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-sessiontimer-race-00 [was: Session-timer issue] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 12:29:41 -0000 I support this draft Kind regards -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmb= erg Sent: Wednesday 13 September 2017 11:37 To: sipcore@ietf.org Cc: Ben Campbell ; sipcore-chairs@ietf.org Subject: [sipcore] Draft new: draft-holmberg-sipcore-sessiontimer-race-00 [= was: Session-timer issue] Hi, I have submitted a draft, draft-holmberg-sipcore-sessiontimer-race-00, that describes the problem, and updates RFC 4028 based on the suggested sol= ution presented earlier. Now, if people think an errata is more appropriate I have no problem with t= hat. However, I think we DO need to fix this, because it is causing problem= s in deployed networks. https://www.ietf.org/id/draft-holmberg-sipcore-sessiontimer-race-00.txt For the GitHub folks: https://github.com/cdh4u/draft-sessiontimer-race Regards, Christer On 07/09/17 19:38, "sipcore on behalf of Christer Holmberg" wrote: >Hi, > >>> seen from my point of view the UAC should ignore the Session timer >>>proposal within the UPDATE. >>> As long as the negotiation is ongoing. >>> >>> Nevertheless we have also observed this curious session timer >>>behavior in our network. >>> >>> I think we need some clarifications to the RFC. Perhaps also to >>>other sections to make it more readable. >>> My experience is that people have problems in following how the >>>session timer should work within a complex SIP networks (e.g. IMS). >>> >>> What is about updating the RFC4028. >> >> Like most of the older SIP RFCs, it probably deserves an update. The >>problem is whether going to the trouble will have any effect on >>implementations. I think the most we > should hope to do is *clarify* >>in cases where there is ambiguity, so that when interoperability >>problems arise it is clear who needs to change. > >Yes. In my case, implementation(s) WILL be changed. The question is >WHICH >implementation(s) :) > >So, my suggestion would be: > >1)Specify/clarify that SE must not be sent during session-timer >negotiation >2)Specify that one must send a 491 (or some other more appropriate code) >response if receiving SE during session-timer negotiation > >For the above, I think we can do it using an errata. > >Regards, > >Christer > > > >>> -----Urspr=FCngliche Nachricht----- >>> Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von >>> Christer Holmberg >>> Gesendet: Donnerstag, 7. September 2017 11:34 >>> An: Paul Kyzivat ; sipcore@ietf.org >>> Betreff: Re: [sipcore] Session-timer issue >>> >>> Hi, >>> >>>>> The following issue has been around for some time already (there >>>>> is also an errata #4744), and as it causes problems (the INVITE >>>>> is rejected with a >>>>> 480 response) in deployed networks, so I think it needs to be fixed. >>>>> People seem to have different opinions on which node is acting >>>>> wrongly, so I hope we can sort it out :) >>>> >>>> This is an interesting problem. I agree that it is unclear exactly >>>> what ought to happen in this case. (But I don't understand why >>>> someone thinks a 480 is a good way to resolve it.) >>> >>> Whether 480 is the best solution or not is not the issue, in my >>>opinion. >>> One could also claim that the UPDATE should be rejected. Etc. >>> >>> The issue is that there is a session-timer negotiation "race >>>condition", and we should forbid that (rejecting the UPDATE could be >>>part of such solution). >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>> >>> >>>> >>>> Thanks, >>>> Paul >>>> >>>>> Below is a call flow showing the problem: >>>>> >>>>> >>>>> UA Proxy AS >>>>> >>>>> -------------------> >>>>> INVITE (#1) >>>>> Supported:timer >>>>> SE:refresher=3Duac >>>>> >>>>> -------------------> >>>>> INVITE (#2) >>>>> Supported:timer >>>>> SE:refresher=3Duac >>>>> >>>>> >>>>> <------------------- >>>>> 18x (#3) >>>>> >>>>> <------------------- >>>>> 18x (#4) >>>>> >>>>> ++++++ early dialog established +++++++ >>>>> >>>>> <------------------- >>>>> UPDATE (#5) >>>>> Supported:timer >>>>> SE:refresher=3Duas >>>>> >>>>> <------------------- >>>>> UPDATE (#6) >>>>> Supported:timer >>>>> SE:refresher=3Duas >>>>> >>>>> >>>>> -------------------> >>>>> 200 (UPDATE) (#7) >>>>> >>>>> -------------------> >>>>> 200 (UPDATE) (#8) >>>>> Require:timer >>>>> SE:refresher=3Duac >>>>> >>>>> >>>>> <------------------- >>>>> 480 (INVITE) (#9) >>>>> >>>>> <------------------- >>>>> 480 (INVITE (#10) >>>>> >>>>> >>>>> >>>>> >>>>> A few things to note: >>>>> >>>>> >>>>> N1:The 18x does not contain the SE (Session-Expires) header field, >>>>> because according to section 4 of RFC 4028 the header >>>>>field is only >>>>> allowed in INVITE, UPDATE and 2xx. So, when the UPDATE >>>>>request >>>>> (#5) is sent, the initial session timer negotiation is >>>>>still >>>>> ongoing. >>>>> >>>>> >>>>> N2:The UPDATE request (#5) contains a Session-Expires header field. >>>>> Section 7.4 of RFC 4028 says: >>>>> >>>>> "In a session refresh request sent within a dialog with an >>>>>active >>>>> session timer, the Session-Expires header field SHOULD be >>>>>present." >>>>> >>>>> Now, a dialog (early) HAS been established when the UPDATE >>> request is >>>>> sent, but as the initial session timer negotiation is still >>>>> ongoing, I assume the session timer isn=B9t yet "active"? >>>>> >>>>> >>>>> N3:The UPDATE 200 response (#7) does not contain the Session-Expires >>>>> header field. It is added by the proxy, based on the >>>>> procedures in >>>>> Section 8.2 of RFC 4028: >>>>> >>>>> "Because there is no Session-Expires or Require >>>>>header field >>>>> in the response, the proxy knows that it is the first >>>>> session-timer-aware proxy to receive the response. >>>>> This proxy >>>>> MUST insert a Session-Expires header field into >>>>>the response >>>>> with the value it remembered from the forwarded >>>>>request. >>>>> It >>>>> MUST >>>>> set the value of The 'refresher' parameter to 'uac'. >>>>> The proxy MUST >>>>> add the 'timer' option tag to any Require header >>>>>field in the >>>>> response, and if none was present, add the Require >>>>>header field with >>>>> that value before forwarding it upstream." >>>>> >>>>> >>>>> Now, one could argue that the UA should include something in the >>>>> UPDATE response (#7), but I think that is not a solution as the UA >>>>> may be confused. >>>>> Instead, based on my understanding of the text in section 7.4 (see >>>>> above) the UPDATE request (#5) should not contain any session >>>>> timer information. This is also more or less what the errata suggests= . >>>>> >>>>> Comments? >>>>> >>>>> 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 >>> >>> _______________________________________________ >>> 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 _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore ________________________________ ***** Disclaimer ***** http://www.proximus.be/maildisclaimer From nobody Wed Sep 13 05:52:30 2017 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 B0AD9132A1A for ; Wed, 13 Sep 2017 05:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de 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 m8MGpmUknEmf for ; Wed, 13 Sep 2017 05:52:26 -0700 (PDT) Received: from mailout24.telekom.de (MAILOUT24.telekom.de [80.149.113.254]) (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 2425A1241F3 for ; Wed, 13 Sep 2017 05:52:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1505307146; x=1536843146; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=+jTNuYz7dQWqZU7uWBSTU4MxRPaC+ZZX8TsxnrMmjWo=; b=WPl8V9LGnoWB6m943TjCvjjgeyTD3wCYD1Nb2dvPXX4h1R4bieFxpRXl tYP2lOpuhDxbiDe7Xemdf8vi/OVCl9AeidV/GKtOGp5pLVcSgD/DEcgDm 0i3NPSxFdDzFFZ9HxABvhJHfWk/B3kmU1stn1Ht1wERQfut7O0YlgS370 hGGC5Vvjbc9w52lTwNRtNZLchrFX2VVbRkSf2u/6Mi0zo+Tx7j7KdsKyR Z08TXyMZ1waINcXzn+WIXQiS3+pKZDNioWMBsldgUEI5f8hBSkIWZXtGl QnggR5EQlbOxvKgfWP/lwsiqllW726rYZP96UTYSV/Nv7IKp73nOqfRDA w==; Received: from qdec94.de.t-internal.com ([10.171.255.41]) by MAILOUT21.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Sep 2017 14:52:22 +0200 X-IronPort-AV: E=Sophos;i="5.42,387,1500933600"; d="scan'208";a="34778022" Received: from he105828.emea1.cds.t-internal.com ([10.169.119.31]) by QDEC97.de.t-internal.com with ESMTP/TLS/AES256-SHA; 13 Sep 2017 14:52:22 +0200 Received: from HE105828.EMEA1.cds.t-internal.com (10.169.119.31) by HE105828.emea1.cds.t-internal.com (10.169.119.31) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Wed, 13 Sep 2017 14:52:22 +0200 Received: from HE105828.EMEA1.cds.t-internal.com ([fe80::753e:c05:6c77:b585]) by HE105828.emea1.cds.t-internal.com ([fe80::753e:c05:6c77:b585%26]) with mapi id 15.00.1293.002; Wed, 13 Sep 2017 14:52:22 +0200 From: To: , , Thread-Topic: AW: [sipcore] Session-timer issue Thread-Index: AQHTJ9H308LywevyKEK5gGy7KZtqL6KyzGwQ Date: Wed, 13 Sep 2017 12:52:22 +0000 Message-ID: References: In-Reply-To: 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.157.166.179] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sipcore] Session-timer issue X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 12:52:30 -0000 Hi Christer, I fully support your draft and I'm also willing to work on it. Due to the fact that we have also problems with the Session Timer which wil= l be solved with your proposals. Best Regards Roland > -----Urspr=FCngliche Nachricht----- > Von: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Gesendet: Donnerstag, 7. September 2017 14:08 > An: Jesske, Roland ; pkyzivat@alum.mit.edu; > sipcore@ietf.org > Betreff: Re: AW: [sipcore] Session-timer issue >=20 > Hi, >=20 > >seen from my point of view the UAC should ignore the Session timer > >proposal within the UPDATE. > >As long as the negotiation is ongoing. >=20 > In the example below, it seems like the UAC DOES ignore it, since it does= n't > included anything in the response. However, the Proxy adds the informatio= n. > To prevent that, the UA would have to reject the UPDATE. > Perhaps with a 491 response? >=20 > I think one reason for the confusion is that RFC 4028 *DOES* say that the= SE > header field should be included in session refresh requests. I think we n= eed > to clarify that it shall not happen as long as the negotiation is ongoing= . >=20 > >Nevertheless we have also observed this curious session timer behavior > >in our network. > > > >I think we need some clarifications to the RFC. Perhaps also to other > >sections to make it more readable. > >My experience is that people have problems in following how the session > >timer should work within a complex SIP networks (e.g. IMS). > > > >What is about updating the RFC4028. >=20 > I wonder whether we'd find the people and energy for working on a bis :) = I > HOPE we are able to make any needed corrections (once we agree what > those would be) using an errata. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 > >> -----Urspr=FCngliche Nachricht----- > >> Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von > >> Christer Holmberg > >> Gesendet: Donnerstag, 7. September 2017 11:34 > >> An: Paul Kyzivat ; sipcore@ietf.org > >> Betreff: Re: [sipcore] Session-timer issue > >> > >> Hi, > >> > >> >>The following issue has been around for some time already (there is > >> >>also an errata #4744), and as it causes problems (the INVITE is > >> >>rejected with a > >> >> 480 response) in deployed networks, so I think it needs to be fixed= . > >> >> People seem to have different opinions on which node is acting > >> >>wrongly, so I hope we can sort it out :) > >> > > >> >This is an interesting problem. I agree that it is unclear exactly > >> >what ought to happen in this case. (But I don't understand why > >> >someone thinks a 480 is a good way to resolve it.) > >> > >> Whether 480 is the best solution or not is not the issue, in my opinio= n. > >> One could also claim that the UPDATE should be rejected. Etc. > >> > >> The issue is that there is a session-timer negotiation "race > >>condition", and we should forbid that (rejecting the UPDATE could be > >>part of such solution). > >> > >> Regards, > >> > >> Christer > >> > >> > >> > >> > >> > >> > > >> > Thanks, > >> > Paul > >> > > >> >> Below is a call flow showing the problem: > >> >> > >> >> > >> >> UA Proxy AS > >> >> > >> >> -------------------> > >> >> INVITE (#1) > >> >> Supported:timer > >> >> SE:refresher=3Duac > >> >> > >> >> -------------------> > >> >> INVITE (#2) > >> >> Supported:timer > >> >> SE:refresher=3Duac > >> >> > >> >> > >> >> <------------------- > >> >> 18x (#3) > >> >> > >> >> <------------------- > >> >> 18x (#4) > >> >> > >> >> ++++++ early dialog established +++++++ > >> >> > >> >> <------------------- > >> >> UPDATE (#5) > >> >> Supported:timer > >> >> SE:refresher=3Duas > >> >> > >> >> <------------------- > >> >> UPDATE (#6) > >> >> Supported:timer > >> >> SE:refresher=3Duas > >> >> > >> >> > >> >> -------------------> > >> >> 200 (UPDATE) (#7) > >> >> > >> >> -------------------> > >> >> 200 (UPDATE) (#8) > >> >> Require:timer > >> >> SE:refresher=3Duac > >> >> > >> >> > >> >> <------------------- > >> >> 480 (INVITE) (#9) > >> >> > >> >> <------------------- > >> >> 480 (INVITE (#10) > >> >> > >> >> > >> >> > >> >> > >> >> A few things to note: > >> >> > >> >> > >> >> N1: The 18x does not contain the SE (Session-Expires) header > field, > >> >> because according to section 4 of RFC 4028 the header > >> >>field is only > >> >> allowed in INVITE, UPDATE and 2xx. So, when the UPDATE > >>request > >> >> (#5) is sent, the initial session timer negotiation is sti= ll > >> >> ongoing. > >> >> > >> >> > >> >> N2: The UPDATE request (#5) contains a Session-Expires header > field. > >> >> Section 7.4 of RFC 4028 says: > >> >> > >> >> "In a session refresh request sent within a dialog with an > >>active > >> >> session timer, the Session-Expires header field SHOULD be > >> >>present." > >> >> > >> >> Now, a dialog (early) HAS been established when the UPDATE > >> request is > >> >> sent, but as the initial session timer negotiation is stil= l > >> >> ongoing, I assume the session timer isn=B9t yet "active"? > >> >> > >> >> > >> >> N3: The UPDATE 200 response (#7) does not contain the Session- > Expires > >> >> header field. It is added by the proxy, based on the > >> >>procedures in > >> >> Section 8.2 of RFC 4028: > >> >> > >> >> "Because there is no Session-Expires or Require > >> >>header field > >> >> in the response, the proxy knows that it is the firs= t > >> >> session-timer-aware proxy to receive the response. > >> >>This proxy > >> >> MUST insert a Session-Expires header field into the > >> >>response > >> >> with the value it remembered from the forwarded > >>request. > >> >>It > >> >> MUST > >> >> set the value of The 'refresher' parameter to 'uac'. > >> >>The proxy MUST > >> >> add the 'timer' option tag to any Require header > >> >>field in the > >> >> response, and if none was present, add the Require > >> >>header field with > >> >> that value before forwarding it upstream." > >> >> > >> >> > >> >> Now, one could argue that the UA should include something in the > >> >> UPDATE response (#7), but I think that is not a solution as the UA > >> >> may be confused. > >> >> Instead, based on my understanding of the text in section 7.4 (see > >> >> above) the UPDATE request (#5) should not contain any session > >> >> timer information. This is also more or less what the errata sugges= ts. > >> >> > >> >> Comments? > >> >> > >> >> 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 > >> > >> _______________________________________________ > >> sipcore mailing list > >> sipcore@ietf.org > >> https://www.ietf.org/mailman/listinfo/sipcore From nobody Wed Sep 13 07:24:46 2017 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 0BEDE132FA7 for ; Wed, 13 Sep 2017 07:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 Py31NVgYMOgN for ; Wed, 13 Sep 2017 07:24:42 -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 752B8132F31 for ; Wed, 13 Sep 2017 07:24:42 -0700 (PDT) Received: from resomta-ch2-18v.sys.comcast.net ([69.252.207.114]) by resqmta-ch2-12v.sys.comcast.net with ESMTP id s8ZGddsH9jX7ks8andTfOB; Wed, 13 Sep 2017 14:24:41 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1505312681; bh=9R51kGGQDQGEQUBWs7a4/925gOJfCgnPJMAbIL7GA6U=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=oyvBRs+BKAyjcSNjYzkYErfFpPtejfszZWPvgLQLqSGYRDklnLFQsUZI1dgjMqLwI zIrsuND74K67Bs5iLcahsylqhoSwuM/ZlYrhvUfHEjFtTF600PcZZalNqFyPFTYdt7 TZRPIajpihE7lPwXowobEXyi3aw/b41ULiU/oKO/tCLXl/nnveN1DpCIHba3i70LDR OGvAu3H/047d3EGYkvg+YmdoYt3WKXJ1oJbcCyRrG2Z8kKMI5rd4CvQzX9au7D3jsU 1tY1zH+T7b3eQDqRZwsuo2bm1DfLVh5HK2NKNjexqcYs2Qp7K+5VImjuaqkO/Zo5Ut 2jTSq608mNrVg== Received: from PaulKyzivatsMBP.localdomain ([24.62.227.142]) by resomta-ch2-18v.sys.comcast.net with SMTP id s8amdi5I0xB6Ts8amdMj9E; Wed, 13 Sep 2017 14:24:41 +0000 To: sipcore@ietf.org References: From: Paul Kyzivat Message-ID: Date: Wed, 13 Sep 2017 10:24:40 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1254; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfCNMkLjLjx/imVmjtQhaVjJfzgIM69ZIDJPEcGeXw19oYLX8sDeoOoGgGezeGkBtonHVLyF+/f0hj82jFaMnh7VvP28J2mVlGEJumJKjbQs79V57040g Zx12tDcPm2cyXZhwIvGMfqmeH9dHCisuEHUrtK7IGrJLylrGPQ71qbk99mpL0XYZn/WlIbR+MOQ1qA== Archived-At: Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-sessiontimer-race-00 [was: Session-timer issue] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 14:24:45 -0000 Hi Christer, On 9/13/17 5:36 AM, Christer Holmberg wrote: > > Hi, > > I have submitted a draft, draft-holmberg-sipcore-sessiontimer-race-00, > that describes the problem, and updates RFC 4028 based on the suggested > solution presented earlier. > > Now, if people think an errata is more appropriate I have no problem with > that. However, I think we DO need to fix this, because it is causing > problems in deployed networks. > > https://www.ietf.org/id/draft-holmberg-sipcore-sessiontimer-race-00.txt I agree that something should be done about this. But it may be possible to make things clearer. The fuzzy area is whether there is an ongoing negotiation of a session timer, and the fuzzy point there is that the two sides might have different understandings of this due to race conditions. AFAICT the only way this comes up is when using UPDATE. There are two clearly distinct uses of UPDATE - within or outside an INVITE transaction. When one UA sends an UPDATE it has a clear understanding of which of these cases applies, and I think the recipient can also figure out which usage the sender thought it was. I'll propose that the session timer negotiation never be done with an UPDATE within an INVITE transaction. (Regardless of whether than INVITE is negotiating a session timer or not.) I think this resolves the problem that you have encountered. (Or we could require that the UPDATE and response care consistent session timer signaling with what is carried in the INVITE and its responses.) That still leaves the actual glare conditions where the two sides each try to start a new session timer negotiation concurrently. Those can properly be handled with 491 responses. This may result in some new cases for use of 491 and some ambiguity about that the 491 signifies. These might be clarified with a Reason header. Thanks, Paul > For the GitHub folks: https://github.com/cdh4u/draft-sessiontimer-race > > Regards, > > Christer > > > > > > > > On 07/09/17 19:38, "sipcore on behalf of Christer Holmberg" > > wrote: > >> Hi, >> >>>> seen from my point of view the UAC should ignore the Session timer >>>> proposal within the UPDATE. >>>> As long as the negotiation is ongoing. >>>> >>>> Nevertheless we have also observed this curious session timer behavior >>>> in our network. >>>> >>>> I think we need some clarifications to the RFC. Perhaps also to other >>>> sections to make it more readable. >>>> My experience is that people have problems in following how the >>>> session timer should work within a complex SIP networks (e.g. IMS). >>>> >>>> What is about updating the RFC4028. >>> >>> Like most of the older SIP RFCs, it probably deserves an update. The >>> problem is whether going to the trouble will have any effect on >>> implementations. I think the most we > should hope to do is *clarify* in >>> cases where there is ambiguity, so that when interoperability problems >>> arise it is clear who needs to change. >> >> Yes. In my case, implementation(s) WILL be changed. The question is WHICH >> implementation(s) :) >> >> So, my suggestion would be: >> >> 1) Specify/clarify that SE must not be sent during session-timer >> negotiation >> 2) Specify that one must send a 491 (or some other more appropriate code) >> response if receiving SE during session-timer negotiation >> >> For the above, I think we can do it using an errata. >> >> Regards, >> >> Christer >> >> >> >>>> -----Ursprüngliche Nachricht----- >>>> Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von >>>> Christer Holmberg >>>> Gesendet: Donnerstag, 7. September 2017 11:34 >>>> An: Paul Kyzivat ; sipcore@ietf.org >>>> Betreff: Re: [sipcore] Session-timer issue >>>> >>>> Hi, >>>> >>>>>> The following issue has been around for some time already (there is >>>>>> also an errata #4744), and as it causes problems (the INVITE is >>>>>> rejected with a >>>>>> 480 response) in deployed networks, so I think it needs to be fixed. >>>>>> People seem to have different opinions on which node is acting >>>>>> wrongly, so I hope we can sort it out :) >>>>> >>>>> This is an interesting problem. I agree that it is unclear exactly >>>>> what ought to happen in this case. (But I don't understand why >>>>> someone thinks a 480 is a good way to resolve it.) >>>> >>>> Whether 480 is the best solution or not is not the issue, in my >>>> opinion. >>>> One could also claim that the UPDATE should be rejected. Etc. >>>> >>>> The issue is that there is a session-timer negotiation "race >>>> condition", and we should forbid that (rejecting the UPDATE could be >>>> part of such solution). >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>>> Below is a call flow showing the problem: >>>>>> >>>>>> >>>>>> UA Proxy AS >>>>>> >>>>>> -------------------> >>>>>> INVITE (#1) >>>>>> Supported:timer >>>>>> SE:refresher=uac >>>>>> >>>>>> -------------------> >>>>>> INVITE (#2) >>>>>> Supported:timer >>>>>> SE:refresher=uac >>>>>> >>>>>> >>>>>> <------------------- >>>>>> 18x (#3) >>>>>> >>>>>> <------------------- >>>>>> 18x (#4) >>>>>> >>>>>> ++++++ early dialog established +++++++ >>>>>> >>>>>> <------------------- >>>>>> UPDATE (#5) >>>>>> Supported:timer >>>>>> SE:refresher=uas >>>>>> >>>>>> <------------------- >>>>>> UPDATE (#6) >>>>>> Supported:timer >>>>>> SE:refresher=uas >>>>>> >>>>>> >>>>>> -------------------> >>>>>> 200 (UPDATE) (#7) >>>>>> >>>>>> -------------------> >>>>>> 200 (UPDATE) (#8) >>>>>> Require:timer >>>>>> SE:refresher=uac >>>>>> >>>>>> >>>>>> <------------------- >>>>>> 480 (INVITE) (#9) >>>>>> >>>>>> <------------------- >>>>>> 480 (INVITE (#10) >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> A few things to note: >>>>>> >>>>>> >>>>>> N1: The 18x does not contain the SE (Session-Expires) header field, >>>>>> because according to section 4 of RFC 4028 the header >>>>>> field is only >>>>>> allowed in INVITE, UPDATE and 2xx. So, when the UPDATE >>>>>> request >>>>>> (#5) is sent, the initial session timer negotiation is >>>>>> still >>>>>> ongoing. >>>>>> >>>>>> >>>>>> N2: The UPDATE request (#5) contains a Session-Expires header field. >>>>>> Section 7.4 of RFC 4028 says: >>>>>> >>>>>> "In a session refresh request sent within a dialog with an >>>>>> active >>>>>> session timer, the Session-Expires header field SHOULD be >>>>>> present." >>>>>> >>>>>> Now, a dialog (early) HAS been established when the UPDATE >>>> request is >>>>>> sent, but as the initial session timer negotiation is still >>>>>> ongoing, I assume the session timer isn¹t yet "active"? >>>>>> >>>>>> >>>>>> N3: The UPDATE 200 response (#7) does not contain the Session-Expires >>>>>> header field. It is added by the proxy, based on the >>>>>> procedures in >>>>>> Section 8.2 of RFC 4028: >>>>>> >>>>>> "Because there is no Session-Expires or Require >>>>>> header field >>>>>> in the response, the proxy knows that it is the first >>>>>> session-timer-aware proxy to receive the response. >>>>>> This proxy >>>>>> MUST insert a Session-Expires header field into the >>>>>> response >>>>>> with the value it remembered from the forwarded >>>>>> request. >>>>>> It >>>>>> MUST >>>>>> set the value of The 'refresher' parameter to 'uac'. >>>>>> The proxy MUST >>>>>> add the 'timer' option tag to any Require header >>>>>> field in the >>>>>> response, and if none was present, add the Require >>>>>> header field with >>>>>> that value before forwarding it upstream." >>>>>> >>>>>> >>>>>> Now, one could argue that the UA should include something in the >>>>>> UPDATE response (#7), but I think that is not a solution as the UA >>>>>> may be confused. >>>>>> Instead, based on my understanding of the text in section 7.4 (see >>>>>> above) the UPDATE request (#5) should not contain any session timer >>>>>> information. This is also more or less what the errata suggests. >>>>>> >>>>>> Comments? >>>>>> >>>>>> 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 >>>> >>>> _______________________________________________ >>>> 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 > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Wed Sep 13 07:48:03 2017 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 E626113304E for ; Wed, 13 Sep 2017 07:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 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, URIBL_BLOCKED=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 1jvcCoAE_NEZ for ; Wed, 13 Sep 2017 07:47:59 -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 13A03133047 for ; Wed, 13 Sep 2017 07:47:58 -0700 (PDT) X-AuditID: c1b4fb3a-5ffff700000051a3-57-59b9451c662a Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id E8.88.20899.C1549B95; Wed, 13 Sep 2017 16:47:57 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.194]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0352.000; Wed, 13 Sep 2017 16:47:48 +0200 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Draft new: draft-holmberg-sipcore-sessiontimer-race-00 [was: Session-timer issue] Thread-Index: AQHTLHPWL1r8lrWpXUOfpdcCGedkLKKyvaMAgAA6LgA= Date: Wed, 13 Sep 2017 14:47:48 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.6.170621 x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="windows-1254" Content-ID: <76CC95A8B667D849BAD16946FF167DF8@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMIsWRmVeSWpSXmKPExsUyM2J7iK6s685Ig9YWXosHP3rZLL7+2MTm wOQx+fEcRo8lS34yBTBFcdmkpOZklqUW6dslcGXsfCRZsCW4out4I1MD4ymHLkZODgkBE4kV OzaydTFycQgJHGEEciayQzhLGCVuNiwGynBwsAlYSHT/0wZpEBEIkdj+8ygriC0skCXxZfJv Foh4tkTjj3fsELaVxNueRjYQm0VAVWLhrdXMIDavgLVE/+rfYHEhgQKJR+/PgMU5Bewl3m1e DTaTUUBM4vupNUwgNrOAuMStJ/OZIA4VkFiy5zwzhC0q8fLxP7B6UQE9idkbD7FAxBUldp5t Z4boNZA4cu4mK4RtLfHy9TR2CFtbYtnC11D3CEqcnPmEZQKj2Cwk62YhaZ+FpH0WkvZZSNoX MLKuYhQtTi0uzk03MtJLLcpMLi7Oz9PLSy3ZxAiMqoNbflvtYDz43PEQowAHoxIPb7H6zkgh 1sSy4srcQ4wSHMxKIrz7TIBCvCmJlVWpRfnxRaU5qcWHGKU5WJTEeR32XYgQEkhPLEnNTk0t SC2CyTJxcEo1MHa0vZ1409UjZFaQgcTjWjmnd9oW7zVnBFU5W51h/uyVFRNdviPZ7f0xjytq yzLfCi5f1D07fX/fjfxAsyrD2fNLPQKac+bXrjb7WqjVrj21z2Pzt9kJVU9+PLqRGTk1+NrS 1I2MXzR7P/tHnvnKvOjek46wkyWClSJ6kz2nmmx80ZRkl2FfocRSnJFoqMVcVJwIAL3qf82m AgAA Archived-At: Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-sessiontimer-race-00 [was: Session-timer issue] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 14:48:02 -0000 Hi Paul, >>I have submitted a draft, draft-holmberg-sipcore-sessiontimer-race-00, >> that describes the problem, and updates RFC 4028 based on the suggested >> solution presented earlier. >>=20 >> Now, if people think an errata is more appropriate I have no problem >>with >> that. However, I think we DO need to fix this, because it is causing >> problems in deployed networks. >>=20 >> https://www.ietf.org/id/draft-holmberg-sipcore-sessiontimer-race-00.txt > >I agree that something should be done about this. But it may be possible >to make things clearer. The fuzzy area is whether there is an ongoing >negotiation of a session timer, and the fuzzy point there is that the >two sides might have different understandings of this due to race >conditions. > >AFAICT the only way this comes up is when using UPDATE. There are two >clearly distinct uses of UPDATE - within or outside an INVITE >transaction. When one UA sends an UPDATE it has a clear understanding of >which of these cases applies, and I think the recipient can also figure >out which usage the sender thought it was. > >I'll propose that the session timer negotiation never be done with an >UPDATE within an INVITE transaction. (Regardless of whether than INVITE >is negotiating a session timer or not.) I think this resolves the >problem that you have encountered. (Or we could require that the UPDATE >and response care consistent session timer signaling with what is >carried in the INVITE and its responses.) If people are ok with simply disallowing UPDATE + Session-Expires while there is an ongoing (re-)INVITE transaction (no matter if the INVITE contained Session-Expires or not) I think that would be the easiest solution. At least I have never heard about a case where one would send INVITE without Session-Expires, and then send UPDATE + Session-Expires while the INVITE transaction is still ongoing. >That still leaves the actual glare conditions where the two sides each >try to start a new session timer negotiation concurrently. Those can >properly be handled with 491 responses. This may result in some new >cases for use of 491 and some ambiguity about that the 491 signifies. >These might be clarified with a Reason header. Correct. Regards, Christer >> For the GitHub folks: https://github.com/cdh4u/draft-sessiontimer-race >>=20 >> Regards, >>=20 >> Christer >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> On 07/09/17 19:38, "sipcore on behalf of Christer Holmberg" >> >> wrote: >>=20 >>> Hi, >>> >>>>> seen from my point of view the UAC should ignore the Session timer >>>>> proposal within the UPDATE. >>>>> As long as the negotiation is ongoing. >>>>> >>>>> Nevertheless we have also observed this curious session timer >>>>>behavior >>>>> in our network. >>>>> >>>>> I think we need some clarifications to the RFC. Perhaps also to other >>>>> sections to make it more readable. >>>>> My experience is that people have problems in following how the >>>>> session timer should work within a complex SIP networks (e.g. IMS). >>>>> >>>>> What is about updating the RFC4028. >>>> >>>> Like most of the older SIP RFCs, it probably deserves an update. The >>>> problem is whether going to the trouble will have any effect on >>>> implementations. I think the most we > should hope to do is *clarify* >>>>in >>>> cases where there is ambiguity, so that when interoperability problems >>>> arise it is clear who needs to change. >>> >>> Yes. In my case, implementation(s) WILL be changed. The question is >>>WHICH >>> implementation(s) :) >>> >>> So, my suggestion would be: >>> >>> 1) Specify/clarify that SE must not be sent during session-timer >>> negotiation >>> 2) Specify that one must send a 491 (or some other more appropriate >>>code) >>> response if receiving SE during session-timer negotiation >>> >>> For the above, I think we can do it using an errata. >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>>>> -----Urspr=FCngliche Nachricht----- >>>>> Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von >>>>> Christer Holmberg >>>>> Gesendet: Donnerstag, 7. September 2017 11:34 >>>>> An: Paul Kyzivat ; sipcore@ietf.org >>>>> Betreff: Re: [sipcore] Session-timer issue >>>>> >>>>> Hi, >>>>> >>>>>>> The following issue has been around for some time already (there is >>>>>>> also an errata #4744), and as it causes problems (the INVITE is >>>>>>> rejected with a >>>>>>> 480 response) in deployed networks, so I think it needs to be >>>>>>>fixed. >>>>>>> People seem to have different opinions on which node is acting >>>>>>> wrongly, so I hope we can sort it out :) >>>>>> >>>>>> This is an interesting problem. I agree that it is unclear exactly >>>>>> what ought to happen in this case. (But I don't understand why >>>>>> someone thinks a 480 is a good way to resolve it.) >>>>> >>>>> Whether 480 is the best solution or not is not the issue, in my >>>>> opinion. >>>>> One could also claim that the UPDATE should be rejected. Etc. >>>>> >>>>> The issue is that there is a session-timer negotiation "race >>>>> condition", and we should forbid that (rejecting the UPDATE could be >>>>> part of such solution). >>>>> >>>>> Regards, >>>>> >>>>> Christer >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> >>>>>>> Below is a call flow showing the problem: >>>>>>> >>>>>>> >>>>>>> UA Proxy AS >>>>>>> >>>>>>> -------------------> >>>>>>> INVITE (#1) >>>>>>> Supported:timer >>>>>>> SE:refresher=3Duac >>>>>>> >>>>>>> -------------------> >>>>>>> INVITE (#2) >>>>>>> Supported:timer >>>>>>> SE:refresher=3Duac >>>>>>> >>>>>>> >>>>>>> <------------------- >>>>>>> 18x (#3) >>>>>>> >>>>>>> <------------------- >>>>>>> 18x (#4) >>>>>>> >>>>>>> ++++++ early dialog established +++++++ >>>>>>> >>>>>>> <------------------- >>>>>>> UPDATE (#5) >>>>>>> Supported:timer >>>>>>> SE:refresher=3Duas >>>>>>> >>>>>>> <------------------- >>>>>>> UPDATE (#6) >>>>>>> Supported:timer >>>>>>> SE:refresher=3Duas >>>>>>> >>>>>>> >>>>>>> -------------------> >>>>>>> 200 (UPDATE) (#7) >>>>>>> >>>>>>> -------------------> >>>>>>> 200 (UPDATE) (#8) >>>>>>> Require:timer >>>>>>> SE:refresher=3Duac >>>>>>> >>>>>>> >>>>>>> <------------------- >>>>>>> 480 (INVITE) (#9) >>>>>>> >>>>>>> <------------------- >>>>>>> 480 (INVITE (#10) >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> A few things to note: >>>>>>> >>>>>>> >>>>>>> N1: The 18x does not contain the SE (Session-Expires) header field, >>>>>>> because according to section 4 of RFC 4028 the header >>>>>>> field is only >>>>>>> allowed in INVITE, UPDATE and 2xx. So, when the UPDATE >>>>>>> request >>>>>>> (#5) is sent, the initial session timer negotiation is >>>>>>> still >>>>>>> ongoing. >>>>>>> >>>>>>> >>>>>>> N2: The UPDATE request (#5) contains a Session-Expires header >>>>>>>field. >>>>>>> Section 7.4 of RFC 4028 says: >>>>>>> >>>>>>> "In a session refresh request sent within a dialog with an >>>>>>> active >>>>>>> session timer, the Session-Expires header field SHOULD be >>>>>>> present." >>>>>>> >>>>>>> Now, a dialog (early) HAS been established when the UPDATE >>>>> request is >>>>>>> sent, but as the initial session timer negotiation is >>>>>>>still >>>>>>> ongoing, I assume the session timer isn=B9t yet "active"= ? >>>>>>> >>>>>>> >>>>>>> N3: The UPDATE 200 response (#7) does not contain the >>>>>>>Session-Expires >>>>>>> header field. It is added by the proxy, based on the >>>>>>> procedures in >>>>>>> Section 8.2 of RFC 4028: >>>>>>> >>>>>>> "Because there is no Session-Expires or Require >>>>>>> header field >>>>>>> in the response, the proxy knows that it is the >>>>>>>first >>>>>>> session-timer-aware proxy to receive the response. >>>>>>> This proxy >>>>>>> MUST insert a Session-Expires header field into >>>>>>>the >>>>>>> response >>>>>>> with the value it remembered from the forwarded >>>>>>> request. >>>>>>> It >>>>>>> MUST >>>>>>> set the value of The 'refresher' parameter to >>>>>>>'uac'. >>>>>>> The proxy MUST >>>>>>> add the 'timer' option tag to any Require header >>>>>>> field in the >>>>>>> response, and if none was present, add the Require >>>>>>> header field with >>>>>>> that value before forwarding it upstream." >>>>>>> >>>>>>> >>>>>>> Now, one could argue that the UA should include something in the >>>>>>> UPDATE response (#7), but I think that is not a solution as the UA >>>>>>> may be confused. >>>>>>> Instead, based on my understanding of the text in section 7.4 (see >>>>>>> above) the UPDATE request (#5) should not contain any session timer >>>>>>> information. This is also more or less what the errata suggests. >>>>>>> >>>>>>> Comments? >>>>>>> >>>>>>> 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 >>>>> >>>>> _______________________________________________ >>>>> 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 >>=20 >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >>=20 > >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore From nobody Wed Sep 13 08:07:38 2017 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 1165C132DFB; Wed, 13 Sep 2017 08:07:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=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 UNg5OxfWlzIr; Wed, 13 Sep 2017 08:07:34 -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 6F4771326ED; Wed, 13 Sep 2017 08:07:34 -0700 (PDT) Received: from [10.0.1.82] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v8DF7TAS013028 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 13 Sep 2017 10:07:29 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.82] From: Ben Campbell Message-Id: <358E77DE-B0A9-4A42-9F5F-3A296B8B8E55@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_F60E5A93-B0FA-4855-99C4-825B71F229B6"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 13 Sep 2017 10:07:28 -0500 In-Reply-To: Cc: "sipcore@ietf.org" , "sipcore-chairs@ietf.org" To: Christer Holmberg References: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-sessiontimer-race-00 [was: Session-timer issue] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 15:07:37 -0000 --Apple-Mail=_F60E5A93-B0FA-4855-99C4-825B71F229B6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 My rule of thumb is that errata exist to fix places where the RFC does = not correctly reflect the intent of the WG at the time of publication. = They are not appropriate for cases where we learned from experience that = the text as originally intended itself has flaws. Which category does this fall into? It seems borderline. OTOH, you=E2=80=99= ve already created a draft :-) Ben. > On Sep 13, 2017, at 4:36 AM, Christer Holmberg = wrote: >=20 >=20 > Hi, >=20 > I have submitted a draft, draft-holmberg-sipcore-sessiontimer-race-00, > that describes the problem, and updates RFC 4028 based on the = suggested > solution presented earlier. >=20 > Now, if people think an errata is more appropriate I have no problem = with > that. However, I think we DO need to fix this, because it is causing > problems in deployed networks. >=20 > = https://www.ietf.org/id/draft-holmberg-sipcore-sessiontimer-race-00.txt >=20 >=20 > For the GitHub folks: https://github.com/cdh4u/draft-sessiontimer-race >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 >=20 >=20 > On 07/09/17 19:38, "sipcore on behalf of Christer Holmberg" > > wrote: >=20 >> Hi, >>=20 >>>> seen from my point of view the UAC should ignore the Session timer >>>> proposal within the UPDATE. >>>> As long as the negotiation is ongoing. >>>>=20 >>>> Nevertheless we have also observed this curious session timer = behavior >>>> in our network. >>>>=20 >>>> I think we need some clarifications to the RFC. Perhaps also to = other >>>> sections to make it more readable. >>>> My experience is that people have problems in following how the >>>> session timer should work within a complex SIP networks (e.g. IMS). >>>>=20 >>>> What is about updating the RFC4028. >>>=20 >>> Like most of the older SIP RFCs, it probably deserves an update. The >>> problem is whether going to the trouble will have any effect on >>> implementations. I think the most we > should hope to do is = *clarify* in >>> cases where there is ambiguity, so that when interoperability = problems >>> arise it is clear who needs to change. >>=20 >> Yes. In my case, implementation(s) WILL be changed. The question is = WHICH >> implementation(s) :) >>=20 >> So, my suggestion would be: >>=20 >> 1) Specify/clarify that SE must not be sent during session-timer >> negotiation >> 2) Specify that one must send a 491 (or some other more appropriate = code) >> response if receiving SE during session-timer negotiation >>=20 >> For the above, I think we can do it using an errata. >>=20 >> Regards, >>=20 >> Christer >>=20 >>=20 >>=20 >>>> -----Urspr=C3=BCngliche Nachricht----- >>>> Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von >>>> Christer Holmberg >>>> Gesendet: Donnerstag, 7. September 2017 11:34 >>>> An: Paul Kyzivat ; sipcore@ietf.org >>>> Betreff: Re: [sipcore] Session-timer issue >>>>=20 >>>> Hi, >>>>=20 >>>>>> The following issue has been around for some time already (there = is >>>>>> also an errata #4744), and as it causes problems (the INVITE is >>>>>> rejected with a >>>>>> 480 response) in deployed networks, so I think it needs to be = fixed. >>>>>> People seem to have different opinions on which node is acting >>>>>> wrongly, so I hope we can sort it out :) >>>>>=20 >>>>> This is an interesting problem. I agree that it is unclear exactly >>>>> what ought to happen in this case. (But I don't understand why >>>>> someone thinks a 480 is a good way to resolve it.) >>>>=20 >>>> Whether 480 is the best solution or not is not the issue, in my >>>> opinion. >>>> One could also claim that the UPDATE should be rejected. Etc. >>>>=20 >>>> The issue is that there is a session-timer negotiation "race >>>> condition", and we should forbid that (rejecting the UPDATE could = be >>>> part of such solution). >>>>=20 >>>> Regards, >>>>=20 >>>> Christer >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>>=20 >>>>> Thanks, >>>>> Paul >>>>>=20 >>>>>> Below is a call flow showing the problem: >>>>>>=20 >>>>>>=20 >>>>>> UA Proxy AS >>>>>>=20 >>>>>> -------------------> >>>>>> INVITE (#1) >>>>>> Supported:timer >>>>>> SE:refresher=3Duac >>>>>>=20 >>>>>> -------------------> >>>>>> INVITE (#2) >>>>>> Supported:timer >>>>>> SE:refresher=3Duac >>>>>>=20 >>>>>>=20 >>>>>> <------------------- >>>>>> 18x (#3) >>>>>>=20 >>>>>> <------------------- >>>>>> 18x (#4) >>>>>>=20 >>>>>> ++++++ early dialog established +++++++ >>>>>>=20 >>>>>> <------------------- >>>>>> UPDATE (#5) >>>>>> Supported:timer >>>>>> SE:refresher=3Duas >>>>>>=20 >>>>>> <------------------- >>>>>> UPDATE (#6) >>>>>> Supported:timer >>>>>> SE:refresher=3Duas >>>>>>=20 >>>>>>=20 >>>>>> -------------------> >>>>>> 200 (UPDATE) (#7) >>>>>>=20 >>>>>> -------------------> >>>>>> 200 (UPDATE) (#8) >>>>>> Require:timer >>>>>> SE:refresher=3Duac >>>>>>=20 >>>>>>=20 >>>>>> <------------------- >>>>>> 480 (INVITE) (#9) >>>>>>=20 >>>>>> <------------------- >>>>>> 480 (INVITE (#10) >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> A few things to note: >>>>>>=20 >>>>>>=20 >>>>>> N1: The 18x does not contain the SE (Session-Expires) header = field, >>>>>> because according to section 4 of RFC 4028 the header >>>>>> field is only >>>>>> allowed in INVITE, UPDATE and 2xx. So, when the UPDATE >>>>>> request >>>>>> (#5) is sent, the initial session timer negotiation is >>>>>> still >>>>>> ongoing. >>>>>>=20 >>>>>>=20 >>>>>> N2: The UPDATE request (#5) contains a Session-Expires = header field. >>>>>> Section 7.4 of RFC 4028 says: >>>>>>=20 >>>>>> "In a session refresh request sent within a dialog with an >>>>>> active >>>>>> session timer, the Session-Expires header field SHOULD be >>>>>> present." >>>>>>=20 >>>>>> Now, a dialog (early) HAS been established when the UPDATE >>>> request is >>>>>> sent, but as the initial session timer negotiation is = still >>>>>> ongoing, I assume the session timer isn=C2=B9t yet = "active"? >>>>>>=20 >>>>>>=20 >>>>>> N3: The UPDATE 200 response (#7) does not contain the = Session-Expires >>>>>> header field. It is added by the proxy, based on the >>>>>> procedures in >>>>>> Section 8.2 of RFC 4028: >>>>>>=20 >>>>>> "Because there is no Session-Expires or Require >>>>>> header field >>>>>> in the response, the proxy knows that it is the = first >>>>>> session-timer-aware proxy to receive the response. >>>>>> This proxy >>>>>> MUST insert a Session-Expires header field into = the >>>>>> response >>>>>> with the value it remembered from the forwarded >>>>>> request. >>>>>> It >>>>>> MUST >>>>>> set the value of The 'refresher' parameter to = 'uac'. >>>>>> The proxy MUST >>>>>> add the 'timer' option tag to any Require header >>>>>> field in the >>>>>> response, and if none was present, add the Require >>>>>> header field with >>>>>> that value before forwarding it upstream." >>>>>>=20 >>>>>>=20 >>>>>> Now, one could argue that the UA should include something in the >>>>>> UPDATE response (#7), but I think that is not a solution as the = UA >>>>>> may be confused. >>>>>> Instead, based on my understanding of the text in section 7.4 = (see >>>>>> above) the UPDATE request (#5) should not contain any session = timer >>>>>> information. This is also more or less what the errata suggests. >>>>>>=20 >>>>>> Comments? >>>>>>=20 >>>>>> Regards, >>>>>>=20 >>>>>> Christer >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> sipcore mailing list >>>>>> sipcore@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> sipcore mailing list >>>>> sipcore@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>=20 >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>>=20 >>=20 >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >=20 --Apple-Mail=_F60E5A93-B0FA-4855-99C4-825B71F229B6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZuUmwAAoJEIBWSmyV89QNYjAP/jYnx4fSzLTyq12QnosY33ZI sTpPo97qGaUZFNFD2u1+dL3CIYNPl5fdPqN2U2OtZKPCsbzo2bMmzJUl5vb/BKH5 HgHJBk4qUNJhkoFLyEeeXN1BTRX/Tcx/JHom9Pmmw2uCozZtlQle3/dgFvby8xOw Ph1ZnfEsQRXoGTNovaIn8zfPNLOgXXiao+QTJzB8tnkh0Hygf+81qqGKqvc8G9Yo 7p4uJhXW6uw9m7ipULCfiGjy+MSC8/sL6VTKbF1xN3UqgyHwCwcaeNss+Uj3u9fp yRC5uTsmz2BkeAorcApniDNdNdEVU4+gl9WIrMmuBKRdlOFQ6H4u4engkuRHv7WF KSU6CcYa88cDJmcEqe2sfnDnQEGw35Y5lAMBoTbiDO3PGumoneW9OOyMciWR9Fsa e3Zh+lXmU80XWrJesZDgf3YXODZ6o+1cP8GicqQ5yESLUuH5SS2Dhmiz5wMtBd4R bS/m1iRSKHBiU6VVNuiMDTaufbFGsJ4UO40FjWNIhZcsNI4Gj83cr4OhrXh+orE+ ymuOaX9UVtHwl79nnWk8/u+hulSgWAD7eeRqiaVwC+Cbdoxg8DXNfTpZ8MMzoCKh /l374kl+CMa/jyXn74kIgn5jMwZrBV5nTpyxAwE6QkzTivKMlNMwu1KLhx7e6H/W +UiPURTBQVy099Q9aedr =dunI -----END PGP SIGNATURE----- --Apple-Mail=_F60E5A93-B0FA-4855-99C4-825B71F229B6-- From nobody Wed Sep 13 11:49:08 2017 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 D8E64132ECB; Wed, 13 Sep 2017 11:49:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btinternet.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 mhFdZikVwQo4; Wed, 13 Sep 2017 11:49:05 -0700 (PDT) Received: from rgout01.bt.lon5.cpcloud.co.uk (rgout01.bt.lon5.cpcloud.co.uk [65.20.0.178]) by ietfa.amsl.com (Postfix) with ESMTP id 3B90713207A; Wed, 13 Sep 2017 11:49:05 -0700 (PDT) X-OWM-Source-IP: 10.110.12.1 () X-OWM-Env-Sender: nweinronk@btinternet.com Received: from webmail06.bt.ext.cpcloud.co.uk (10.110.12.1) by rgout01.bt.lon5.cpcloud.co.uk (9.0.019.13-1) (authenticated as nweinronk@btinternet.com) id 597450640552ED24; Wed, 13 Sep 2017 19:49:02 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btinternet.com; s=btcpcloud; t=1505328545; bh=NKF8PdazrLfM4sEtcHhZQQbaccRSljKqVfdhQIVNLq8=; h=Date:From:Reply-To:To:Cc:Message-ID:In-Reply-To:References:Subject:MIME-Version; b=nOVF/kOX3qXqdVQeKC0rQGSqHmRre236HfN/ojguNlzOO+g2oqzGY635CN36vjdjSFIZQvdN8LTxlN5YRGx1xXNhvYcuHQS6VQd3pSsuQJ22xU/d0NvHD2Zy/OScjhuJDx7BYQPWtD2dqfYSQJv6TMrlsrl0pM/d7YuzbxujPvo= Date: Wed, 13 Sep 2017 19:49:02 +0100 (BST) From: N WEINRONK Reply-To: nweinronk@btinternet.com To: christer.holmberg@ericsson.com, sipcore@ietf.org Cc: sipcore-chairs@ietf.org, ben@nostrum.com Message-ID: <897862.60769.1505328542331.JavaMail.defaultUser@defaultHost> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-CP-REPLY-ALL-UID: 50148 X-CP-REPLY-ALL-PATH: INBOX Importance: 3 (Normal) X-Priority: 3 (Normal) X-Client-IP: IPv4[109.159.164.68] Epoch[1505328542297] Archived-At: Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-sessiontimer-race-00 [was: Session-timer issue] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 18:49:08 -0000 I recently came across: https://www.rfc-editor.org/errata_search.php?eid=3D4744 Thanks, Nigel ----Original message---- >From : christer.holmberg@ericsson.com Date : 13/09/2017 - 10:36 (GMTDT) To : sipcore@ietf.org Cc : ben@nostrum.com, sipcore-chairs@ietf.org Subject : [sipcore] Draft new: draft-holmberg-sipcore-sessiontimer-race-00 = [was: Session-timer issue] Hi, I have submitted a draft, draft-holmberg-sipcore-sessiontimer-race-00, that describes the problem, and updates RFC 4028 based on the suggested solution presented earlier. Now, if people think an errata is more appropriate I have no problem with that. However, I think we DO need to fix this, because it is causing problems in deployed networks. https://www.ietf.org/id/draft-holmberg-sipcore-sessiontimer-race-00.txt For the GitHub folks: https://github.com/cdh4u/draft-sessiontimer-race Regards, Christer On 07/09/17 19:38, "sipcore on behalf of Christer Holmberg" wrote: >Hi, > >>> seen from my point of view the UAC should ignore the Session timer >>>proposal within the UPDATE. >>> As long as the negotiation is ongoing. >>>=20 >>> Nevertheless we have also observed this curious session timer behavior >>>in our network. >>>=20 >>> I think we need some clarifications to the RFC. Perhaps also to other >>>sections to make it more readable. >>> My experience is that people have problems in following how the >>>session timer should work within a complex SIP networks (e.g. IMS). >>>=20 >>> What is about updating the RFC4028. >> >> Like most of the older SIP RFCs, it probably deserves an update. The >>problem is whether going to the trouble will have any effect on >>implementations. I think the most we > should hope to do is *clarify* in >>cases where there is ambiguity, so that when interoperability problems >>arise it is clear who needs to change. > >Yes. In my case, implementation(s) WILL be changed. The question is WHICH >implementation(s) :) > >So, my suggestion would be: > >1)=09Specify/clarify that SE must not be sent during session-timer >negotiation >2)=09Specify that one must send a 491 (or some other more appropriate code= ) >response if receiving SE during session-timer negotiation > >For the above, I think we can do it using an errata. > >Regards, > >Christer > > > >>> -----Urspr=C3=BCngliche Nachricht----- >>> Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von >>> Christer Holmberg >>> Gesendet: Donnerstag, 7. September 2017 11:34 >>> An: Paul Kyzivat ; sipcore@ietf.org >>> Betreff: Re: [sipcore] Session-timer issue >>> >>> Hi, >>> >>>>> The following issue has been around for some time already (there is >>>>> also an errata #4744), and as it causes problems (the INVITE is >>>>> rejected with a >>>>> 480 response) in deployed networks, so I think it needs to be fixed. >>>>> People seem to have different opinions on which node is acting >>>>> wrongly, so I hope we can sort it out :) >>>> >>>> This is an interesting problem. I agree that it is unclear exactly >>>> what ought to happen in this case. (But I don't understand why >>>> someone thinks a 480 is a good way to resolve it.) >>> >>> Whether 480 is the best solution or not is not the issue, in my >>>opinion. >>> One could also claim that the UPDATE should be rejected. Etc. >>> >>> The issue is that there is a session-timer negotiation "race >>> condition", and we should forbid that (rejecting the UPDATE could be >>>part of such solution). >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>> >>> >>>> >>>> =09Thanks, >>>> =09Paul >>>> >>>>> Below is a call flow showing the problem: >>>>> >>>>> >>>>> UA Proxy AS >>>>> >>>>> -------------------> >>>>> INVITE (#1) >>>>> Supported:timer >>>>> SE:refresher=3Duac >>>>> >>>>> -------------------> >>>>> INVITE (#2) >>>>> Supported:timer >>>>> SE:refresher=3Duac >>>>> >>>>> >>>>> <------------------- >>>>> 18x (#3) >>>>> >>>>> <------------------- >>>>> 18x (#4) >>>>> >>>>> ++++++ early dialog established +++++++ >>>>> >>>>> <------------------- >>>>> UPDATE (#5) >>>>> Supported:timer >>>>> SE:refresher=3Duas >>>>> >>>>> <------------------- >>>>> UPDATE (#6) >>>>> Supported:timer >>>>> SE:refresher=3Duas >>>>> >>>>> >>>>> -------------------> >>>>> 200 (UPDATE) (#7) >>>>> >>>>> -------------------> >>>>> 200 (UPDATE) (#8) >>>>> Require:timer >>>>> SE:refresher=3Duac >>>>> >>>>> >>>>> <------------------- >>>>> 480 (INVITE) (#9) >>>>> >>>>> <------------------- >>>>> 480 (INVITE (#10) >>>>> >>>>> >>>>> >>>>> >>>>> A few things to note: >>>>> >>>>> >>>>> N1:=09The 18x does not contain the SE (Session-Expires) header field, >>>>> because according to section 4 of RFC 4028 the header >>>>> field is only >>>>> allowed in INVITE, UPDATE and 2xx. So, when the UPDATE >>>>>request >>>>> (#5) is sent, the initial session timer negotiation is >>>>>still >>>>> ongoing. >>>>> >>>>> >>>>> N2:=09The UPDATE request (#5) contains a Session-Expires header field= . >>>>> Section 7.4 of RFC 4028 says: >>>>> >>>>> =09 "In a session refresh request sent within a dialog with an >>>>>active >>>>> =09 session timer, the Session-Expires header field SHOULD be >>>>> present." >>>>> >>>>> =09Now, a dialog (early) HAS been established when the UPDATE >>> request is >>>>> sent, but as the initial session timer negotiation is still >>>>> ongoing, I assume the session timer isn=C2=B9t yet "active"= ? >>>>> >>>>> >>>>> N3:=09The UPDATE 200 response (#7) does not contain the Session-Expir= es >>>>> header field. It is added by the proxy, based on the >>>>> procedures in >>>>> Section 8.2 of RFC 4028: >>>>> >>>>> "Because there is no Session-Expires or Require >>>>> header field >>>>> in the response, the proxy knows that it is the first >>>>> session-timer-aware proxy to receive the response. >>>>> This proxy >>>>> MUST insert a Session-Expires header field into the >>>>> response >>>>> with the value it remembered from the forwarded >>>>>request. >>>>> It >>>>> MUST >>>>> set the value of The 'refresher' parameter to 'uac'. >>>>> The proxy MUST >>>>> add the 'timer' option tag to any Require header >>>>> field in the >>>>> response, and if none was present, add the Require >>>>> header field with >>>>> that value before forwarding it upstream." >>>>> >>>>> >>>>> Now, one could argue that the UA should include something in the >>>>> UPDATE response (#7), but I think that is not a solution as the UA >>>>> may be confused. >>>>> Instead, based on my understanding of the text in section 7.4 (see >>>>> above) the UPDATE request (#5) should not contain any session timer >>>>> information. This is also more or less what the errata suggests. >>>>> >>>>> Comments? >>>>> >>>>> 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 >>> >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>=20 > >_______________________________________________ >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 Wed Sep 13 11:55:33 2017 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 8FB61132D97; Wed, 13 Sep 2017 11:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 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, URIBL_BLOCKED=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 JWlPiW7o7NVW; Wed, 13 Sep 2017 11:55:29 -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 E398113207A; Wed, 13 Sep 2017 11:55:28 -0700 (PDT) X-AuditID: c1b4fb30-a5d009c000007145-65-59b97f1e7bbe Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 84.13.28997.E1F79B95; Wed, 13 Sep 2017 20:55:27 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.194]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0352.000; Wed, 13 Sep 2017 20:55:26 +0200 From: Christer Holmberg To: "nweinronk@btinternet.com" , "sipcore@ietf.org" CC: "sipcore-chairs@ietf.org" , "ben@nostrum.com" Thread-Topic: [sipcore] Draft new: draft-holmberg-sipcore-sessiontimer-race-00 [was: Session-timer issue] Thread-Index: AQHTLHPWL1r8lrWpXUOfpdcCGedkLKKzB4AAgAAi1dA= Date: Wed, 13 Sep 2017 18:55:26 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B562B0A48@ESESSMB109.ericsson.se> References: <897862.60769.1505328542331.JavaMail.defaultUser@defaultHost> In-Reply-To: <897862.60769.1505328542331.JavaMail.defaultUser@defaultHost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjkeLIzCtJLcpLzFFi42KZGbHdSVe+fmekwdmZbBbzO0+zW5xbsJfV ovfzQmaLrz82sTmweHyf9ZTFY8mSn0wes3Y+YQlgjuKySUnNySxLLdK3S+DKeLzvKGPBjpiK H3sKGxg7oroYOTgkBEwk9u9m7WLk4hASOMIoMW/WW6YuRk4gZwmjxKP7mSA1bAIWEt3/tEHC IgJJEofv7WUBsZkF4iTab91gBbGFBbIkWnoXs0LUZEs0/njHDmFbSVz61cMGYrMIqErMb/8C Np5XwFdiyqadjBCrqiU+fXgHVsMp4CWxZ/NvsBpGATGJ76fWMEHsEpe49WQ+mC0hICCxZM95 ZghbVOLl43+sELaSxIrtlxhBTmYW0JRYv0sfolVRYkr3Q3aItYISJ2c+YZnAKDoLydRZCB2z kHTMQtKxgJFlFaNocWpxUm66kZFealFmcnFxfp5eXmrJJkZg7Bzc8ttgB+PL546HGAU4GJV4 eDfl7owUYk0sK67MPcQowcGsJMJrVQ0U4k1JrKxKLcqPLyrNSS0+xCjNwaIkzuu470KEkEB6 YklqdmpqQWoRTJaJg1OqgbFeUPbpG4nURk+lpLtv/O1dDM5t3n5ViTX1Rb1z+YccF85Jj06f i02IfrNy6XaBA4xfzkbVvpJcfOwcz4MyxoMmwboBv4PdPxQzsy0u/aB6c8KOrXNvHjtrccDn jGm7Batj61wBk5LocA+Rpl9S1180SL4qexi+Ys92kxZ1qVWpq6YHbzK5UKrEUpyRaKjFXFSc CADvwZMImQIAAA== Archived-At: Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-sessiontimer-race-00 [was: Session-timer issue] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 18:55:31 -0000 SGkgTmlnZWwsDQoNCj5JIHJlY2VudGx5IGNhbWUgYWNyb3NzOg0KPg0KPmh0dHBzOi8vd3d3LnJm Yy1lZGl0b3Iub3JnL2VycmF0YV9zZWFyY2gucGhwP2VpZD00NzQ0DQoNClllcywgd2UgZmlsZWQg dGhpcyBlcnJhdGEgc29tZSB0aW1lIGJhY2suDQoNCkhvd2V2ZXIsIHdoZW4gSSBzdGFydGVkIHRv IGxvb2sgaW50byB0aGUgaXNzdWUgYWdhaW4sIEkgcmVhbGl6ZWQgdGhhdCBzb2x2aW5nIHRoZSBp c3N1ZSBtYXkgcmVxdWlyZSBhZGRpdGlvbmFsIGNoYW5nZXMgaW4gdGhlIFJGQywgYW5kIHRoYXQn cyB3aHkgSSBwdXQgdG9nZXRoZXIgdGhlIGRyYWZ0IDopDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVy DQoNCg0KLS0tLU9yaWdpbmFsIG1lc3NhZ2UtLS0tDQpGcm9tIDogY2hyaXN0ZXIuaG9sbWJlcmdA ZXJpY3Nzb24uY29tDQpEYXRlIDogMTMvMDkvMjAxNyAtIDEwOjM2IChHTVREVCkNClRvIDogc2lw Y29yZUBpZXRmLm9yZw0KQ2MgOiBiZW5Abm9zdHJ1bS5jb20sIHNpcGNvcmUtY2hhaXJzQGlldGYu b3JnIFN1YmplY3QgOiBbc2lwY29yZV0gRHJhZnQgbmV3OiBkcmFmdC1ob2xtYmVyZy1zaXBjb3Jl LXNlc3Npb250aW1lci1yYWNlLTAwIFt3YXM6IFNlc3Npb24tdGltZXIgaXNzdWVdDQoNCg0KSGks DQoNCkkgaGF2ZSBzdWJtaXR0ZWQgYSBkcmFmdCwgZHJhZnQtaG9sbWJlcmctc2lwY29yZS1zZXNz aW9udGltZXItcmFjZS0wMCwNCnRoYXQgZGVzY3JpYmVzIHRoZSBwcm9ibGVtLCBhbmQgdXBkYXRl cyBSRkMgNDAyOCBiYXNlZCBvbiB0aGUgc3VnZ2VzdGVkIHNvbHV0aW9uIHByZXNlbnRlZCBlYXJs aWVyLg0KDQpOb3csIGlmIHBlb3BsZSB0aGluayBhbiBlcnJhdGEgaXMgbW9yZSBhcHByb3ByaWF0 ZSBJIGhhdmUgbm8gcHJvYmxlbSB3aXRoIHRoYXQuIEhvd2V2ZXIsIEkgdGhpbmsgd2UgRE8gbmVl ZCB0byBmaXggdGhpcywgYmVjYXVzZSBpdCBpcyBjYXVzaW5nIHByb2JsZW1zIGluIGRlcGxveWVk IG5ldHdvcmtzLg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1ob2xtYmVyZy1zaXBj b3JlLXNlc3Npb250aW1lci1yYWNlLTAwLnR4dA0KDQoNCkZvciB0aGUgR2l0SHViIGZvbGtzOiBo dHRwczovL2dpdGh1Yi5jb20vY2RoNHUvZHJhZnQtc2Vzc2lvbnRpbWVyLXJhY2UNCg0KUmVnYXJk cywNCg0KQ2hyaXN0ZXINCg0KDQoNCg0KDQoNCg0KT24gMDcvMDkvMTcgMTk6MzgsICJzaXBjb3Jl IG9uIGJlaGFsZiBvZiBDaHJpc3RlciBIb2xtYmVyZyINCjxzaXBjb3JlLWJvdW5jZXNAaWV0Zi5v cmcgb24gYmVoYWxmIG9mIGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4NCndyb3RlOg0K DQo+SGksDQo+DQo+Pj4gc2VlbiBmcm9tIG15IHBvaW50IG9mIHZpZXcgdGhlIFVBQyBzaG91bGQg aWdub3JlIHRoZSBTZXNzaW9uIHRpbWVyIA0KPj4+cHJvcG9zYWwgd2l0aGluIHRoZSBVUERBVEUu DQo+Pj4gQXMgbG9uZyBhcyB0aGUgbmVnb3RpYXRpb24gaXMgIG9uZ29pbmcuDQo+Pj4gDQo+Pj4g TmV2ZXJ0aGVsZXNzIHdlIGhhdmUgYWxzbyBvYnNlcnZlZCB0aGlzIGN1cmlvdXMgc2Vzc2lvbiB0 aW1lciANCj4+PmJlaGF2aW9yIGluIG91ciBuZXR3b3JrLg0KPj4+IA0KPj4+IEkgdGhpbmsgd2Ug bmVlZCBzb21lIGNsYXJpZmljYXRpb25zIHRvIHRoZSBSRkMuIFBlcmhhcHMgYWxzbyB0byANCj4+ Pm90aGVyIHNlY3Rpb25zIHRvIG1ha2UgaXQgbW9yZSByZWFkYWJsZS4NCj4+PiBNeSBleHBlcmll bmNlIGlzIHRoYXQgcGVvcGxlIGhhdmUgcHJvYmxlbXMgaW4gZm9sbG93aW5nIGhvdyB0aGUgDQo+ Pj5zZXNzaW9uIHRpbWVyIHNob3VsZCB3b3JrIHdpdGhpbiBhIGNvbXBsZXggU0lQIG5ldHdvcmtz IChlLmcuIElNUykuDQo+Pj4gDQo+Pj4gV2hhdCBpcyBhYm91dCB1cGRhdGluZyB0aGUgUkZDNDAy OC4NCj4+DQo+PiBMaWtlIG1vc3Qgb2YgdGhlIG9sZGVyIFNJUCBSRkNzLCBpdCBwcm9iYWJseSBk ZXNlcnZlcyBhbiB1cGRhdGUuIFRoZSANCj4+cHJvYmxlbSBpcyB3aGV0aGVyIGdvaW5nIHRvIHRo ZSB0cm91YmxlIHdpbGwgaGF2ZSBhbnkgZWZmZWN0IG9uIA0KPj5pbXBsZW1lbnRhdGlvbnMuIEkg dGhpbmsgdGhlIG1vc3Qgd2UgPiBzaG91bGQgaG9wZSB0byBkbyBpcyAqY2xhcmlmeSogDQo+Pmlu IGNhc2VzIHdoZXJlIHRoZXJlIGlzIGFtYmlndWl0eSwgc28gdGhhdCB3aGVuIGludGVyb3BlcmFi aWxpdHkgDQo+PnByb2JsZW1zIGFyaXNlIGl0IGlzIGNsZWFyIHdobyBuZWVkcyB0byBjaGFuZ2Uu DQo+DQo+WWVzLiBJbiBteSBjYXNlLCBpbXBsZW1lbnRhdGlvbihzKSBXSUxMIGJlIGNoYW5nZWQu IFRoZSBxdWVzdGlvbiBpcyANCj5XSElDSA0KPmltcGxlbWVudGF0aW9uKHMpIDopDQo+DQo+U28s IG15IHN1Z2dlc3Rpb24gd291bGQgYmU6DQo+DQo+MSkJU3BlY2lmeS9jbGFyaWZ5IHRoYXQgU0Ug bXVzdCBub3QgYmUgc2VudCBkdXJpbmcgc2Vzc2lvbi10aW1lcg0KPm5lZ290aWF0aW9uDQo+MikJ U3BlY2lmeSB0aGF0IG9uZSBtdXN0IHNlbmQgYSA0OTEgKG9yIHNvbWUgb3RoZXIgbW9yZSBhcHBy b3ByaWF0ZSBjb2RlKQ0KPnJlc3BvbnNlIGlmIHJlY2VpdmluZyBTRSBkdXJpbmcgc2Vzc2lvbi10 aW1lciBuZWdvdGlhdGlvbg0KPg0KPkZvciB0aGUgYWJvdmUsIEkgdGhpbmsgd2UgY2FuIGRvIGl0 IHVzaW5nIGFuIGVycmF0YS4NCj4NCj5SZWdhcmRzLA0KPg0KPkNocmlzdGVyDQo+DQo+DQo+DQo+ Pj4gLS0tLS1VcnNwcsO8bmdsaWNoZSBOYWNocmljaHQtLS0tLQ0KPj4+IFZvbjogc2lwY29yZSBb bWFpbHRvOnNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZ10gSW0gQXVmdHJhZyB2b24gDQo+Pj4gQ2hy aXN0ZXIgSG9sbWJlcmcNCj4+PiBHZXNlbmRldDogRG9ubmVyc3RhZywgNy4gU2VwdGVtYmVyIDIw MTcgMTE6MzQNCj4+PiBBbjogUGF1bCBLeXppdmF0IDxwa3l6aXZhdEBhbHVtLm1pdC5lZHU+OyBz aXBjb3JlQGlldGYub3JnDQo+Pj4gQmV0cmVmZjogUmU6IFtzaXBjb3JlXSBTZXNzaW9uLXRpbWVy IGlzc3VlDQo+Pj4NCj4+PiBIaSwNCj4+Pg0KPj4+Pj4gVGhlIGZvbGxvd2luZyBpc3N1ZSBoYXMg YmVlbiBhcm91bmQgZm9yIHNvbWUgdGltZSBhbHJlYWR5ICh0aGVyZSANCj4+Pj4+IGlzIGFsc28g IGFuIGVycmF0YSAjNDc0NCksIGFuZCBhcyBpdCBjYXVzZXMgcHJvYmxlbXMgKHRoZSBJTlZJVEUg DQo+Pj4+PiBpcyByZWplY3RlZCB3aXRoIGENCj4+Pj4+IDQ4MCByZXNwb25zZSkgaW4gZGVwbG95 ZWQgbmV0d29ya3MsIHNvIEkgdGhpbmsgaXQgbmVlZHMgdG8gYmUgZml4ZWQuDQo+Pj4+PiBQZW9w bGUgc2VlbSB0byBoYXZlIGRpZmZlcmVudCBvcGluaW9ucyBvbiB3aGljaCBub2RlIGlzIGFjdGlu ZyANCj4+Pj4+IHdyb25nbHksIHNvICBJIGhvcGUgd2UgY2FuIHNvcnQgaXQgb3V0IDopDQo+Pj4+ DQo+Pj4+IFRoaXMgaXMgYW4gaW50ZXJlc3RpbmcgcHJvYmxlbS4gSSBhZ3JlZSB0aGF0IGl0IGlz IHVuY2xlYXIgZXhhY3RseSANCj4+Pj4gd2hhdCBvdWdodCB0byBoYXBwZW4gaW4gdGhpcyBjYXNl LiAoQnV0IEkgZG9uJ3QgdW5kZXJzdGFuZCB3aHkgDQo+Pj4+IHNvbWVvbmUgdGhpbmtzIGEgNDgw IGlzIGEgZ29vZCB3YXkgdG8gcmVzb2x2ZSBpdC4pDQo+Pj4NCj4+PiBXaGV0aGVyIDQ4MCBpcyB0 aGUgYmVzdCBzb2x1dGlvbiBvciBub3QgaXMgbm90IHRoZSBpc3N1ZSwgaW4gbXkgDQo+Pj5vcGlu aW9uLg0KPj4+IE9uZSBjb3VsZCBhbHNvIGNsYWltIHRoYXQgdGhlIFVQREFURSBzaG91bGQgYmUg cmVqZWN0ZWQuIEV0Yy4NCj4+Pg0KPj4+IFRoZSBpc3N1ZSBpcyB0aGF0IHRoZXJlIGlzIGEgc2Vz c2lvbi10aW1lciBuZWdvdGlhdGlvbiAicmFjZSAgDQo+Pj5jb25kaXRpb24iLCBhbmQgd2Ugc2hv dWxkIGZvcmJpZCB0aGF0IChyZWplY3RpbmcgdGhlIFVQREFURSBjb3VsZCBiZSANCj4+PnBhcnQg b2Ygc3VjaCBzb2x1dGlvbikuDQo+Pj4NCj4+PiBSZWdhcmRzLA0KPj4+DQo+Pj4gQ2hyaXN0ZXIN Cj4+Pg0KPj4+DQo+Pj4NCj4+Pg0KPj4+DQo+Pj4+DQo+Pj4+IAlUaGFua3MsDQo+Pj4+IAlQYXVs DQo+Pj4+DQo+Pj4+PiBCZWxvdyBpcyBhIGNhbGwgZmxvdyBzaG93aW5nIHRoZSBwcm9ibGVtOg0K Pj4+Pj4NCj4+Pj4+DQo+Pj4+PiBVQSAgICAgICAgICAgICAgICBQcm94eSAgICAgICAgICAgICAg ICBBUw0KPj4+Pj4NCj4+Pj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0+DQo+Pj4+PiBJTlZJVEUgKCMx KQ0KPj4+Pj4gU3VwcG9ydGVkOnRpbWVyDQo+Pj4+PiBTRTpyZWZyZXNoZXI9dWFjDQo+Pj4+Pg0K Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0+DQo+Pj4+PiAg ICAgICAgICAgICAgICAgICAgICAgSU5WSVRFICgjMikNCj4+Pj4+ICAgICAgICAgICAgICAgICAg ICAgICBTdXBwb3J0ZWQ6dGltZXINCj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICBTRTpyZWZy ZXNoZXI9dWFjDQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICA8LS0t LS0tLS0tLS0tLS0tLS0tLQ0KPj4+Pj4gICAgICAgICAgICAgICAgICAgICAgIDE4eCAoIzMpDQo+ Pj4+Pg0KPj4+Pj4gPC0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+Pj4+IDE4eCAoIzQpDQo+Pj4+Pg0K Pj4+Pj4gKysrKysrIGVhcmx5IGRpYWxvZyBlc3RhYmxpc2hlZCArKysrKysrDQo+Pj4+Pg0KPj4+ Pj4gICAgICAgICAgICAgICAgICAgICAgIDwtLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4+PiAgICAg ICAgICAgICAgICAgICAgICAgVVBEQVRFICgjNSkNCj4+Pj4+ICAgICAgICAgICAgICAgICAgICAg ICBTdXBwb3J0ZWQ6dGltZXINCj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICBTRTpyZWZyZXNo ZXI9dWFzDQo+Pj4+Pg0KPj4+Pj4gPC0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+Pj4+IFVQREFURSAo IzYpDQo+Pj4+PiBTdXBwb3J0ZWQ6dGltZXINCj4+Pj4+IFNFOnJlZnJlc2hlcj11YXMNCj4+Pj4+ DQo+Pj4+Pg0KPj4+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLT4NCj4+Pj4+IDIwMCAoVVBEQVRFKSAo IzcpDQo+Pj4+Pg0KPj4+Pj4gICAgICAgICAgICAgICAgICAgICAgIC0tLS0tLS0tLS0tLS0tLS0t LS0+DQo+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgMjAwIChVUERBVEUpICgjOCkNCj4+Pj4+ ICAgICAgICAgICAgICAgICAgICAgICBSZXF1aXJlOnRpbWVyDQo+Pj4+PiAgICAgICAgICAgICAg ICAgICAgICAgU0U6cmVmcmVzaGVyPXVhYw0KPj4+Pj4NCj4+Pj4+DQo+Pj4+PiAgICAgICAgICAg ICAgICAgICAgICAgPC0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+Pj4+ICAgICAgICAgICAgICAgICAg ICAgICA0ODAgKElOVklURSkgKCM5KQ0KPj4+Pj4NCj4+Pj4+IDwtLS0tLS0tLS0tLS0tLS0tLS0t DQo+Pj4+PiA0ODAgKElOVklURSAoIzEwKQ0KPj4+Pj4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4NCj4+ Pj4+IEEgZmV3IHRoaW5ncyB0byBub3RlOg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+PiBOMToJVGhlIDE4 eCBkb2VzIG5vdCBjb250YWluIHRoZSBTRSAoU2Vzc2lvbi1FeHBpcmVzKSBoZWFkZXIgZmllbGQs DQo+Pj4+PiAgICAgICAgICAgYmVjYXVzZSBhY2NvcmRpbmcgdG8gc2VjdGlvbiA0IG9mIFJGQyA0 MDI4IHRoZSBoZWFkZXIgIA0KPj4+Pj5maWVsZCBpcyBvbmx5DQo+Pj4+PiAgICAgICAgICAgYWxs b3dlZCBpbiBJTlZJVEUsIFVQREFURSBhbmQgMnh4LiBTbywgd2hlbiB0aGUgVVBEQVRFIA0KPj4+ Pj5yZXF1ZXN0DQo+Pj4+PiAgICAgICAgICAgKCM1KSBpcyBzZW50LCB0aGUgaW5pdGlhbCBzZXNz aW9uIHRpbWVyIG5lZ290aWF0aW9uIGlzIA0KPj4+Pj5zdGlsbA0KPj4+Pj4gICAgICAgICAgIG9u Z29pbmcuDQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+IE4yOglUaGUgVVBEQVRFIHJlcXVlc3QgKCM1KSBj b250YWlucyBhIFNlc3Npb24tRXhwaXJlcyBoZWFkZXIgZmllbGQuDQo+Pj4+PiAgICAgICAgICAg U2VjdGlvbiA3LjQgb2YgUkZDIDQwMjggc2F5czoNCj4+Pj4+DQo+Pj4+PiAJICAgICAiSW4gYSBz ZXNzaW9uIHJlZnJlc2ggcmVxdWVzdCBzZW50IHdpdGhpbiBhIGRpYWxvZyB3aXRoIGFuIA0KPj4+ Pj5hY3RpdmUNCj4+Pj4+IAkgICAgICBzZXNzaW9uIHRpbWVyLCB0aGUgU2Vzc2lvbi1FeHBpcmVz IGhlYWRlciBmaWVsZCBTSE9VTEQgYmUgIA0KPj4+Pj5wcmVzZW50LiINCj4+Pj4+DQo+Pj4+PiAJ Tm93LCBhIGRpYWxvZyAoZWFybHkpIEhBUyBiZWVuIGVzdGFibGlzaGVkIHdoZW4gdGhlIFVQREFU RQ0KPj4+IHJlcXVlc3QgaXMNCj4+Pj4+ICAgICAgICAgICBzZW50LCBidXQgYXMgdGhlIGluaXRp YWwgc2Vzc2lvbiB0aW1lciBuZWdvdGlhdGlvbiBpcyBzdGlsbA0KPj4+Pj4gICAgICAgICAgIG9u Z29pbmcsIEkgYXNzdW1lIHRoZSBzZXNzaW9uIHRpbWVyIGlzbsK5dCB5ZXQgImFjdGl2ZSI/DQo+ Pj4+Pg0KPj4+Pj4NCj4+Pj4+IE4zOglUaGUgVVBEQVRFIDIwMCByZXNwb25zZSAoIzcpIGRvZXMg bm90IGNvbnRhaW4gdGhlIFNlc3Npb24tRXhwaXJlcw0KPj4+Pj4gICAgICAgICAgIGhlYWRlciBm aWVsZC4gSXQgaXMgYWRkZWQgYnkgdGhlIHByb3h5LCBiYXNlZCBvbiB0aGUgDQo+Pj4+PiBwcm9j ZWR1cmVzIGluDQo+Pj4+PiAgICAgICAgICAgU2VjdGlvbiA4LjIgb2YgUkZDIDQwMjg6DQo+Pj4+ Pg0KPj4+Pj4gICAgICAgICAgICAgICAgIkJlY2F1c2UgdGhlcmUgaXMgbm8gU2Vzc2lvbi1FeHBp cmVzIG9yIFJlcXVpcmUgIA0KPj4+Pj5oZWFkZXIgZmllbGQNCj4+Pj4+ICAgICAgICAgICAgICAg ICBpbiB0aGUgcmVzcG9uc2UsIHRoZSBwcm94eSBrbm93cyB0aGF0IGl0IGlzIHRoZSBmaXJzdA0K Pj4+Pj4gICAgICAgICAgICAgICAgIHNlc3Npb24tdGltZXItYXdhcmUgcHJveHkgdG8gcmVjZWl2 ZSB0aGUgcmVzcG9uc2UuDQo+Pj4+PiBUaGlzICBwcm94eQ0KPj4+Pj4gICAgICAgICAgICAgICAg IE1VU1QgaW5zZXJ0IGEgU2Vzc2lvbi1FeHBpcmVzIGhlYWRlciBmaWVsZCBpbnRvIA0KPj4+Pj50 aGUgIHJlc3BvbnNlDQo+Pj4+PiAgICAgICAgICAgICAgICAgd2l0aCB0aGUgdmFsdWUgaXQgcmVt ZW1iZXJlZCBmcm9tIHRoZSBmb3J3YXJkZWQgDQo+Pj4+PnJlcXVlc3QuDQo+Pj4+PiBJdA0KPj4+ Pj4gTVVTVA0KPj4+Pj4gICAgICAgICAgICAgICAgIHNldCB0aGUgdmFsdWUgb2YgVGhlICdyZWZy ZXNoZXInIHBhcmFtZXRlciB0byAndWFjJy4NCj4+Pj4+IFRoZSAgcHJveHkgTVVTVA0KPj4+Pj4g ICAgICAgICAgICAgICAgIGFkZCB0aGUgJ3RpbWVyJyBvcHRpb24gdGFnIHRvIGFueSBSZXF1aXJl IGhlYWRlciAgDQo+Pj4+PmZpZWxkIGluICB0aGUNCj4+Pj4+ICAgICAgICAgICAgICAgICByZXNw b25zZSwgYW5kIGlmIG5vbmUgd2FzIHByZXNlbnQsIGFkZCB0aGUgUmVxdWlyZSAgDQo+Pj4+Pmhl YWRlciAgZmllbGQgd2l0aA0KPj4+Pj4gICAgICAgICAgICAgICAgIHRoYXQgdmFsdWUgYmVmb3Jl IGZvcndhcmRpbmcgaXQgdXBzdHJlYW0uIg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+PiBOb3csIG9uZSBj b3VsZCBhcmd1ZSB0aGF0IHRoZSBVQSBzaG91bGQgaW5jbHVkZSBzb21ldGhpbmcgaW4gdGhlIA0K Pj4+Pj4gVVBEQVRFIHJlc3BvbnNlICgjNyksIGJ1dCBJIHRoaW5rIHRoYXQgaXMgbm90IGEgc29s dXRpb24gYXMgdGhlIFVBIA0KPj4+Pj4gbWF5IGJlIGNvbmZ1c2VkLg0KPj4+Pj4gSW5zdGVhZCwg YmFzZWQgb24gbXkgdW5kZXJzdGFuZGluZyBvZiB0aGUgdGV4dCBpbiBzZWN0aW9uIDcuNCAoc2Vl DQo+Pj4+PiBhYm92ZSkgdGhlIFVQREFURSByZXF1ZXN0ICgjNSkgc2hvdWxkIG5vdCBjb250YWlu IGFueSBzZXNzaW9uIA0KPj4+Pj4gdGltZXIgaW5mb3JtYXRpb24uIFRoaXMgaXMgYWxzbyBtb3Jl IG9yIGxlc3Mgd2hhdCB0aGUgZXJyYXRhIHN1Z2dlc3RzLg0KPj4+Pj4NCj4+Pj4+IENvbW1lbnRz Pw0KPj4+Pj4NCj4+Pj4+IFJlZ2FyZHMsDQo+Pj4+Pg0KPj4+Pj4gQ2hyaXN0ZXINCj4+Pj4+DQo+ Pj4+Pg0KPj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4+Pj4+IHNpcGNvcmUgbWFpbGluZyBsaXN0DQo+Pj4+PiBzaXBjb3JlQGlldGYub3JnDQo+ Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCj4+Pj4+ DQo+Pj4+DQo+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+Pj4+IHNpcGNvcmUgbWFpbGluZyBsaXN0DQo+Pj4+IHNpcGNvcmVAaWV0Zi5vcmcNCj4+ Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlDQo+Pj4NCj4+ PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+IHNp cGNvcmUgbWFpbGluZyBsaXN0DQo+Pj4gc2lwY29yZUBpZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZQ0KPj4gDQo+DQo+X19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5zaXBjb3JlIG1haWxpbmcgbGlz dA0KPnNpcGNvcmVAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NpcGNvcmUNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCnNpcGNvcmUgbWFpbGluZyBsaXN0DQpzaXBjb3JlQGlldGYub3JnDQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCg0K From nobody Wed Sep 13 22:44:24 2017 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 8AA611321DE; Wed, 13 Sep 2017 22:44:23 -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 IZqP7_1tP1pB; Wed, 13 Sep 2017 22:44:21 -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 8162F126E64; Wed, 13 Sep 2017 22:44:20 -0700 (PDT) X-AuditID: c1b4fb25-967ff70000005333-38-59ba1732abb4 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id D7.36.21299.2371AB95; Thu, 14 Sep 2017 07:44:18 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.194]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0352.000; Thu, 14 Sep 2017 07:44:18 +0200 From: Christer Holmberg To: Ben Campbell CC: "sipcore@ietf.org" , "sipcore-chairs@ietf.org" Thread-Topic: Draft new: draft-holmberg-sipcore-sessiontimer-race-00 [was: Session-timer issue] Thread-Index: AQHTLHPWL1r8lrWpXUOfpdcCGedkLKKyyZgAgAEosQA= Date: Thu, 14 Sep 2017 05:44:18 +0000 Message-ID: References: <358E77DE-B0A9-4A42-9F5F-3A296B8B8E55@nostrum.com> In-Reply-To: <358E77DE-B0A9-4A42-9F5F-3A296B8B8E55@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.6.170621 x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="windows-1254" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMIsWRmVeSWpSXmKPExsUyM2K7tK6R+K5Ig0ePjSzmd55mt+j9vJDZ 4uuPTWwOzB5Llvxk8pi18wlLAFMUl01Kak5mWWqRvl0CV8aDT9fZCpq9Kt4fvM3awLjdsouR g0NCwESit6u4i5GLQ0jgCKNE17H/zBDOEkaJjc+XMoEUsQlYSHT/0+5i5OQQEVCSeN68lQXE ZhZIkLg84zUTiC0MZL+d9JQdoiZR4t+tRUwQtpXEia5usHoWAVWJ/zcuMIOM5BWwlvh+MwAk LCRQIPHu2xJGEJtTwF5i4+sPbCA2o4CYxPdTa5ggVolL3HoyH8yWEBCQWLLnPDOELSrx8vE/ VhBbVEBPYvbGQywQcSWJHxsuQZ1pIHHk3E1WCNtaYvvpVjYIW1ti2cLXYHN4BQQlTs58wjKB UXwWknWzkLTPQtI+C0n7LCTtCxhZVzGKFqcWJ+WmGxnrpRZlJhcX5+fp5aWWbGIERt3BLb9V dzBefuN4iFGAg1GJh9fy9s5IIdbEsuLK3EOMEhzMSiK84W+AQrwpiZVVqUX58UWlOanFhxil OViUxHkd912IEBJITyxJzU5NLUgtgskycXBKNTA6fp4/X5jTr0bDfNmrvLoTgaGySi3Rx6xF C5c905vtsmxlF+fLY47efqVnhC6093gXhUk9L/md4+kfb2I6dbGGzjFBvZlfeFLqly8I59yf /7xmu0JU2a0r1yIjuyold+1bdvBgxLM9Wvo72oX38zDNvWLuED959dvWStONYhtvtm9T1hS8 slyJpTgj0VCLuag4EQC6Bi+XtgIAAA== Archived-At: Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-sessiontimer-race-00 [was: Session-timer issue] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Sep 2017 05:44:23 -0000 Hi, >My rule of thumb is that errata exist to fix places where the RFC does >not correctly reflect the intent of the WG at the time of publication. >They are not appropriate for cases where we learned from experience that >the text as originally intended itself has flaws. > >Which category does this fall into? It seems borderline. OTOH, you=92ve >already created a draft :-) Initially I thought an errata would be enough, since we only suggested a small change to one paragraph. But, since we now suggest modifications to more paragraphs, and add some clarification procedures, we thought a draft would be more appropriate. Regards, Christer > >> On Sep 13, 2017, at 4:36 AM, Christer Holmberg >> wrote: >>=20 >>=20 >> Hi, >>=20 >> I have submitted a draft, draft-holmberg-sipcore-sessiontimer-race-00, >> that describes the problem, and updates RFC 4028 based on the suggested >> solution presented earlier. >>=20 >> Now, if people think an errata is more appropriate I have no problem >>with >> that. However, I think we DO need to fix this, because it is causing >> problems in deployed networks. >>=20 >> https://www.ietf.org/id/draft-holmberg-sipcore-sessiontimer-race-00.txt >>=20 >>=20 >> For the GitHub folks: https://github.com/cdh4u/draft-sessiontimer-race >>=20 >> Regards, >>=20 >> Christer >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> On 07/09/17 19:38, "sipcore on behalf of Christer Holmberg" >> >> wrote: >>=20 >>> Hi, >>>=20 >>>>> seen from my point of view the UAC should ignore the Session timer >>>>> proposal within the UPDATE. >>>>> As long as the negotiation is ongoing. >>>>>=20 >>>>> Nevertheless we have also observed this curious session timer >>>>>behavior >>>>> in our network. >>>>>=20 >>>>> I think we need some clarifications to the RFC. Perhaps also to other >>>>> sections to make it more readable. >>>>> My experience is that people have problems in following how the >>>>> session timer should work within a complex SIP networks (e.g. IMS). >>>>>=20 >>>>> What is about updating the RFC4028. >>>>=20 >>>> Like most of the older SIP RFCs, it probably deserves an update. The >>>> problem is whether going to the trouble will have any effect on >>>> implementations. I think the most we > should hope to do is *clarify* >>>>in >>>> cases where there is ambiguity, so that when interoperability problems >>>> arise it is clear who needs to change. >>>=20 >>> Yes. In my case, implementation(s) WILL be changed. The question is >>>WHICH >>> implementation(s) :) >>>=20 >>> So, my suggestion would be: >>>=20 >>> 1) Specify/clarify that SE must not be sent during session-timer >>> negotiation >>> 2) Specify that one must send a 491 (or some other more appropriate >>>code) >>> response if receiving SE during session-timer negotiation >>>=20 >>> For the above, I think we can do it using an errata. >>>=20 >>> Regards, >>>=20 >>> Christer >>>=20 >>>=20 >>>=20 >>>>> -----Urspr=FCngliche Nachricht----- >>>>> Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von >>>>> Christer Holmberg >>>>> Gesendet: Donnerstag, 7. September 2017 11:34 >>>>> An: Paul Kyzivat ; sipcore@ietf.org >>>>> Betreff: Re: [sipcore] Session-timer issue >>>>>=20 >>>>> Hi, >>>>>=20 >>>>>>> The following issue has been around for some time already (there is >>>>>>> also an errata #4744), and as it causes problems (the INVITE is >>>>>>> rejected with a >>>>>>> 480 response) in deployed networks, so I think it needs to be >>>>>>>fixed. >>>>>>> People seem to have different opinions on which node is acting >>>>>>> wrongly, so I hope we can sort it out :) >>>>>>=20 >>>>>> This is an interesting problem. I agree that it is unclear exactly >>>>>> what ought to happen in this case. (But I don't understand why >>>>>> someone thinks a 480 is a good way to resolve it.) >>>>>=20 >>>>> Whether 480 is the best solution or not is not the issue, in my >>>>> opinion. >>>>> One could also claim that the UPDATE should be rejected. Etc. >>>>>=20 >>>>> The issue is that there is a session-timer negotiation "race >>>>> condition", and we should forbid that (rejecting the UPDATE could be >>>>> part of such solution). >>>>>=20 >>>>> Regards, >>>>>=20 >>>>> Christer >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>> Thanks, >>>>>> Paul >>>>>>=20 >>>>>>> Below is a call flow showing the problem: >>>>>>>=20 >>>>>>>=20 >>>>>>> UA Proxy AS >>>>>>>=20 >>>>>>> -------------------> >>>>>>> INVITE (#1) >>>>>>> Supported:timer >>>>>>> SE:refresher=3Duac >>>>>>>=20 >>>>>>> -------------------> >>>>>>> INVITE (#2) >>>>>>> Supported:timer >>>>>>> SE:refresher=3Duac >>>>>>>=20 >>>>>>>=20 >>>>>>> <------------------- >>>>>>> 18x (#3) >>>>>>>=20 >>>>>>> <------------------- >>>>>>> 18x (#4) >>>>>>>=20 >>>>>>> ++++++ early dialog established +++++++ >>>>>>>=20 >>>>>>> <------------------- >>>>>>> UPDATE (#5) >>>>>>> Supported:timer >>>>>>> SE:refresher=3Duas >>>>>>>=20 >>>>>>> <------------------- >>>>>>> UPDATE (#6) >>>>>>> Supported:timer >>>>>>> SE:refresher=3Duas >>>>>>>=20 >>>>>>>=20 >>>>>>> -------------------> >>>>>>> 200 (UPDATE) (#7) >>>>>>>=20 >>>>>>> -------------------> >>>>>>> 200 (UPDATE) (#8) >>>>>>> Require:timer >>>>>>> SE:refresher=3Duac >>>>>>>=20 >>>>>>>=20 >>>>>>> <------------------- >>>>>>> 480 (INVITE) (#9) >>>>>>>=20 >>>>>>> <------------------- >>>>>>> 480 (INVITE (#10) >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> A few things to note: >>>>>>>=20 >>>>>>>=20 >>>>>>> N1: The 18x does not contain the SE (Session-Expires) header field, >>>>>>> because according to section 4 of RFC 4028 the header >>>>>>> field is only >>>>>>> allowed in INVITE, UPDATE and 2xx. So, when the UPDATE >>>>>>> request >>>>>>> (#5) is sent, the initial session timer negotiation is >>>>>>> still >>>>>>> ongoing. >>>>>>>=20 >>>>>>>=20 >>>>>>> N2: The UPDATE request (#5) contains a Session-Expires header >>>>>>>field. >>>>>>> Section 7.4 of RFC 4028 says: >>>>>>>=20 >>>>>>> "In a session refresh request sent within a dialog with an >>>>>>> active >>>>>>> session timer, the Session-Expires header field SHOULD be >>>>>>> present." >>>>>>>=20 >>>>>>> Now, a dialog (early) HAS been established when the UPDATE >>>>> request is >>>>>>> sent, but as the initial session timer negotiation is >>>>>>>still >>>>>>> ongoing, I assume the session timer isn=B9t yet "active"? >>>>>>>=20 >>>>>>>=20 >>>>>>> N3: The UPDATE 200 response (#7) does not contain the >>>>>>>Session-Expires >>>>>>> header field. It is added by the proxy, based on the >>>>>>> procedures in >>>>>>> Section 8.2 of RFC 4028: >>>>>>>=20 >>>>>>> "Because there is no Session-Expires or Require >>>>>>> header field >>>>>>> in the response, the proxy knows that it is the >>>>>>>first >>>>>>> session-timer-aware proxy to receive the response. >>>>>>> This proxy >>>>>>> MUST insert a Session-Expires header field into the >>>>>>> response >>>>>>> with the value it remembered from the forwarded >>>>>>> request. >>>>>>> It >>>>>>> MUST >>>>>>> set the value of The 'refresher' parameter to 'uac'. >>>>>>> The proxy MUST >>>>>>> add the 'timer' option tag to any Require header >>>>>>> field in the >>>>>>> response, and if none was present, add the Require >>>>>>> header field with >>>>>>> that value before forwarding it upstream." >>>>>>>=20 >>>>>>>=20 >>>>>>> Now, one could argue that the UA should include something in the >>>>>>> UPDATE response (#7), but I think that is not a solution as the UA >>>>>>> may be confused. >>>>>>> Instead, based on my understanding of the text in section 7.4 (see >>>>>>> above) the UPDATE request (#5) should not contain any session timer >>>>>>> information. This is also more or less what the errata suggests. >>>>>>>=20 >>>>>>> Comments? >>>>>>>=20 >>>>>>> Regards, >>>>>>>=20 >>>>>>> Christer >>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> sipcore mailing list >>>>>>> sipcore@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> sipcore mailing list >>>>>> sipcore@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>>=20 >>>>> _______________________________________________ >>>>> sipcore mailing list >>>>> sipcore@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>=20 >>>=20 >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>=20 > From nobody Wed Sep 13 23:56:27 2017 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 11C4E1321D8 for ; Wed, 13 Sep 2017 23:56:26 -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 jTaUcJGiWbgi for ; Wed, 13 Sep 2017 23:56:23 -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 38E05132F60 for ; Wed, 13 Sep 2017 23:56:23 -0700 (PDT) X-AuditID: c1b4fb2d-a4dff700000019be-f0-59ba2815cc41 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 56.D6.06590.5182AB95; Thu, 14 Sep 2017 08:56:21 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.194]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0352.000; Thu, 14 Sep 2017 08:56:20 +0200 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Draft new: draft-holmberg-sipcore-sessiontimer-race-00 [was: Session-timer issue] Thread-Index: AQHTLHPWL1r8lrWpXUOfpdcCGedkLKKyvaMAgAFIxgA= Date: Thu, 14 Sep 2017 06:56:20 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.6.170621 x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="windows-1254" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCIsWRmVeSWpSXmKPExsUyM2K7ma6oxq5Ig+4rShYPfvSyWXz9sYnN gclj8uM5jB5LlvxkCmCK4rJJSc3JLEst0rdL4Mp41zyBsWCVe8XXpz8YGxivmnUxcnJICJhI PJvazdrFyMUhJHCEUeLti4lsEM4SRokN/deAMhwcbAIWEt3/tEEaRARCJLb/PMoKYgsLZEl8 mfybBSKeLdH44x07hG0l0dJ+GsxmEVCVOLPtLVg9r4C1xN2Xe8DiQgIFEo/en2EGsTkF7CXe bV4NVsMoICbx/dQaJhCbWUBc4taT+UwQhwpILNlznhnCFpV4+fgfWL2ogJ7E7I2HWCDiihLt TxsYIXoNJI6cu8kKYVtLrL12GGqmtsSyha+ZIe4RlDg58wnLBEaxWUjWzULSPgtJ+ywk7bOQ tC9gZF3FKFqcWlycm25krJdalJlcXJyfp5eXWrKJERhXB7f81t3BuPq14yFGAQ5GJR7eizd3 RgqxJpYVV+YeYpTgYFYS4bVW3RUpxJuSWFmVWpQfX1Sak1p8iFGag0VJnNdh34UIIYH0xJLU 7NTUgtQimCwTB6dUA2O35uENT31OhO9+1BMurfQpaNKtZ1HehptufmhYJpXXKh07WyXX8mKb fzhHc6PApgOBGZEhyt/Yrt1hvKlzPOPvpxKxUvaXzreWBvTGqBxVPqetrnfxxgbxk+fjXTnP ntoqJz7hm9CZPI0VfFnr/BtiTosv1A9wvPhrkkaPiXiTkZ9zj8rJnUosxRmJhlrMRcWJAIa3 T+qnAgAA Archived-At: Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-sessiontimer-race-00 [was: Session-timer issue] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Sep 2017 06:56:26 -0000 Hi, =85 >I'll propose that the session timer negotiation never be done with an >UPDATE within an INVITE transaction. (Regardless of whether than INVITE >is negotiating a session timer or not.) I think this resolves the >problem that you have encountered. (Or we could require that the UPDATE >and response care consistent session timer signaling with what is >carried in the INVITE and its responses.) I had a chat with some product people, and they said that there actually ARE cases where the session timer is negotiated using UPDATE when the initial INVITE transaction is still ongoing. There are cases where the INVITE only contains Supported:timer, but the actual negotiation is done using UPDATE. Regards, Christer >> For the GitHub folks: https://github.com/cdh4u/draft-sessiontimer-race >>=20 >> Regards, >>=20 >> Christer >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> On 07/09/17 19:38, "sipcore on behalf of Christer Holmberg" >> >> wrote: >>=20 >>> Hi, >>> >>>>> seen from my point of view the UAC should ignore the Session timer >>>>> proposal within the UPDATE. >>>>> As long as the negotiation is ongoing. >>>>> >>>>> Nevertheless we have also observed this curious session timer >>>>>behavior >>>>> in our network. >>>>> >>>>> I think we need some clarifications to the RFC. Perhaps also to other >>>>> sections to make it more readable. >>>>> My experience is that people have problems in following how the >>>>> session timer should work within a complex SIP networks (e.g. IMS). >>>>> >>>>> What is about updating the RFC4028. >>>> >>>> Like most of the older SIP RFCs, it probably deserves an update. The >>>> problem is whether going to the trouble will have any effect on >>>> implementations. I think the most we > should hope to do is *clarify* >>>>in >>>> cases where there is ambiguity, so that when interoperability problems >>>> arise it is clear who needs to change. >>> >>> Yes. In my case, implementation(s) WILL be changed. The question is >>>WHICH >>> implementation(s) :) >>> >>> So, my suggestion would be: >>> >>> 1) Specify/clarify that SE must not be sent during session-timer >>> negotiation >>> 2) Specify that one must send a 491 (or some other more appropriate >>>code) >>> response if receiving SE during session-timer negotiation >>> >>> For the above, I think we can do it using an errata. >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>>>> -----Urspr=FCngliche Nachricht----- >>>>> Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von >>>>> Christer Holmberg >>>>> Gesendet: Donnerstag, 7. September 2017 11:34 >>>>> An: Paul Kyzivat ; sipcore@ietf.org >>>>> Betreff: Re: [sipcore] Session-timer issue >>>>> >>>>> Hi, >>>>> >>>>>>> The following issue has been around for some time already (there is >>>>>>> also an errata #4744), and as it causes problems (the INVITE is >>>>>>> rejected with a >>>>>>> 480 response) in deployed networks, so I think it needs to be >>>>>>>fixed. >>>>>>> People seem to have different opinions on which node is acting >>>>>>> wrongly, so I hope we can sort it out :) >>>>>> >>>>>> This is an interesting problem. I agree that it is unclear exactly >>>>>> what ought to happen in this case. (But I don't understand why >>>>>> someone thinks a 480 is a good way to resolve it.) >>>>> >>>>> Whether 480 is the best solution or not is not the issue, in my >>>>> opinion. >>>>> One could also claim that the UPDATE should be rejected. Etc. >>>>> >>>>> The issue is that there is a session-timer negotiation "race >>>>> condition", and we should forbid that (rejecting the UPDATE could be >>>>> part of such solution). >>>>> >>>>> Regards, >>>>> >>>>> Christer >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> >>>>>>> Below is a call flow showing the problem: >>>>>>> >>>>>>> >>>>>>> UA Proxy AS >>>>>>> >>>>>>> -------------------> >>>>>>> INVITE (#1) >>>>>>> Supported:timer >>>>>>> SE:refresher=3Duac >>>>>>> >>>>>>> -------------------> >>>>>>> INVITE (#2) >>>>>>> Supported:timer >>>>>>> SE:refresher=3Duac >>>>>>> >>>>>>> >>>>>>> <------------------- >>>>>>> 18x (#3) >>>>>>> >>>>>>> <------------------- >>>>>>> 18x (#4) >>>>>>> >>>>>>> ++++++ early dialog established +++++++ >>>>>>> >>>>>>> <------------------- >>>>>>> UPDATE (#5) >>>>>>> Supported:timer >>>>>>> SE:refresher=3Duas >>>>>>> >>>>>>> <------------------- >>>>>>> UPDATE (#6) >>>>>>> Supported:timer >>>>>>> SE:refresher=3Duas >>>>>>> >>>>>>> >>>>>>> -------------------> >>>>>>> 200 (UPDATE) (#7) >>>>>>> >>>>>>> -------------------> >>>>>>> 200 (UPDATE) (#8) >>>>>>> Require:timer >>>>>>> SE:refresher=3Duac >>>>>>> >>>>>>> >>>>>>> <------------------- >>>>>>> 480 (INVITE) (#9) >>>>>>> >>>>>>> <------------------- >>>>>>> 480 (INVITE (#10) >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> A few things to note: >>>>>>> >>>>>>> >>>>>>> N1: The 18x does not contain the SE (Session-Expires) header field, >>>>>>> because according to section 4 of RFC 4028 the header >>>>>>> field is only >>>>>>> allowed in INVITE, UPDATE and 2xx. So, when the UPDATE >>>>>>> request >>>>>>> (#5) is sent, the initial session timer negotiation is >>>>>>> still >>>>>>> ongoing. >>>>>>> >>>>>>> >>>>>>> N2: The UPDATE request (#5) contains a Session-Expires header >>>>>>>field. >>>>>>> Section 7.4 of RFC 4028 says: >>>>>>> >>>>>>> "In a session refresh request sent within a dialog with an >>>>>>> active >>>>>>> session timer, the Session-Expires header field SHOULD be >>>>>>> present." >>>>>>> >>>>>>> Now, a dialog (early) HAS been established when the UPDATE >>>>> request is >>>>>>> sent, but as the initial session timer negotiation is >>>>>>>still >>>>>>> ongoing, I assume the session timer isn=B9t yet "active"= ? >>>>>>> >>>>>>> >>>>>>> N3: The UPDATE 200 response (#7) does not contain the >>>>>>>Session-Expires >>>>>>> header field. It is added by the proxy, based on the >>>>>>> procedures in >>>>>>> Section 8.2 of RFC 4028: >>>>>>> >>>>>>> "Because there is no Session-Expires or Require >>>>>>> header field >>>>>>> in the response, the proxy knows that it is the >>>>>>>first >>>>>>> session-timer-aware proxy to receive the response. >>>>>>> This proxy >>>>>>> MUST insert a Session-Expires header field into >>>>>>>the >>>>>>> response >>>>>>> with the value it remembered from the forwarded >>>>>>> request. >>>>>>> It >>>>>>> MUST >>>>>>> set the value of The 'refresher' parameter to >>>>>>>'uac'. >>>>>>> The proxy MUST >>>>>>> add the 'timer' option tag to any Require header >>>>>>> field in the >>>>>>> response, and if none was present, add the Require >>>>>>> header field with >>>>>>> that value before forwarding it upstream." >>>>>>> >>>>>>> >>>>>>> Now, one could argue that the UA should include something in the >>>>>>> UPDATE response (#7), but I think that is not a solution as the UA >>>>>>> may be confused. >>>>>>> Instead, based on my understanding of the text in section 7.4 (see >>>>>>> above) the UPDATE request (#5) should not contain any session timer >>>>>>> information. This is also more or less what the errata suggests. >>>>>>> >>>>>>> Comments? >>>>>>> >>>>>>> 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 >>>>> >>>>> _______________________________________________ >>>>> 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 >>=20 >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >>=20 > >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore From nobody Thu Sep 14 08:11:28 2017 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 1E6FD13291C for ; Thu, 14 Sep 2017 08:11:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 oKuu8vdDNU3w for ; Thu, 14 Sep 2017 08:11:25 -0700 (PDT) Received: from alum-mailsec-scanner-8.mit.edu (alum-mailsec-scanner-8.mit.edu [18.7.68.20]) by ietfa.amsl.com (Postfix) with ESMTP id 11383126BF3 for ; Thu, 14 Sep 2017 08:11:24 -0700 (PDT) X-AuditID: 12074414-0d3ff70000006ddf-73-59ba9c1b5bfb Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 65.1A.28127.B1C9AB95; Thu, 14 Sep 2017 11:11:23 -0400 (EDT) Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id v8EFBMuf005185 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 14 Sep 2017 11:11:23 -0400 To: Christer Holmberg , "sipcore@ietf.org" References: From: Paul Kyzivat Message-ID: Date: Thu, 14 Sep 2017 11:11:22 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1254; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJIsWRmVeSWpSXmKPExsUixO6iqCs9Z1ekwbcHxhYXZh5mtPj6YxOb A5PHr69X2TyWLPnJFMAUxWWTkpqTWZZapG+XwJXR8ng7e0F3UMXcuSeZGxg77LsYOTkkBEwk Oj71sILYQgI7mCQ+XcjsYuQCsh8ySVyfe4wFJCEskCWx5utBRhBbRCBNomdiPztE0SJGiW3v 28CK2AS0JOYc+g9m8wrYS2xrfMgEYrMIqErM6Z8JZosCNf/bfZYRokZQ4uTMJ2D1nAI2Epcf LwGLMwvYSrxYMIEZwhaXuPVkPhOELS/RvHU28wRG/llI2mchaZmFpGUWkpYFjCyrGOUSc0pz dXMTM3OKU5N1i5MT8/JSi3Qt9HIzS/RSU0o3MUJCVWQH45GTcocYBTgYlXh4BSbsihRiTSwr rsw9xCjJwaQkyrtXd2ekEF9SfkplRmJxRnxRaU5q8SFGCQ5mJRFe14lA5bwpiZVVqUX5MClp DhYlcd5vi9X9hATSE0tSs1NTC1KLYLIyHBxKErznZwE1ChalpqdWpGXmlCCkmTg4QYbzAA33 BKnhLS5IzC3OTIfIn2LU5ejpufGHSYglLz8vVUqc1w+kSACkKKM0D24OLMW8YhQHekuYV3A2 UBUPMD3BTXoFtIQJaMmZ0ztAlpQkIqSkGhiT/FU25QketktMlwnK+xmX2n8yXMFuYfTRAruT LbFvvdN0mBRSzHNv7/6lsWzpSd/nWm/2im43tEoXum3m+U47tL+yYuNaRaO2PM6JKZNkTv2+ 6znhTvtFYeHGXzsm3zHaEpD46Y/f0Yt+v1e8+2TuemODckHdIxGHsOz7f63Xxr/P/Rk4i1OJ pTgj0VCLuag4EQA6rdYcDAMAAA== Archived-At: Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-sessiontimer-race-00 [was: Session-timer issue] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Sep 2017 15:11:27 -0000 Christer, On 9/14/17 2:56 AM, Christer Holmberg wrote: > Hi, > > … > >> I'll propose that the session timer negotiation never be done with an >> UPDATE within an INVITE transaction. (Regardless of whether than INVITE >> is negotiating a session timer or not.) I think this resolves the >> problem that you have encountered. (Or we could require that the UPDATE >> and response care consistent session timer signaling with what is >> carried in the INVITE and its responses.) > > I had a chat with some product people, and they said that there actually > ARE cases where the session timer is negotiated using UPDATE when the > initial INVITE transaction is still ongoing. There are cases where the > INVITE only contains Supported:timer, but the actual negotiation is done > using UPDATE. Interesting! (I wonder why.) That sequence itself presents some ambiguities. The way I have always described how the session timer negotiation works is that *every* INVITE and UPDATE transaction affects s-t - it either negotiates it *on* or else it negotiates it *off*. (IMO this makes it very easy to understand.) That presents issues when you have an update nested inside of an invite. In the case you describe I might expect that the update would negotiate the timer on, and then the completion of the invite would negotiate it off again. How would the case you describe work if a proxy inserted S-E in INVITE? In that case, the UAC doesn't know about it until the 2xx from the invite. Before then it might try enabling a timer using UPDATE. I am inclined to keep things simple by saying that the 2xx response to every INVITE or UPDATE redefines the state of the session timer, either on or off. That will of course break the use case you describe above. Thanks, Paul > Regards, > > Christer > > > > >>> For the GitHub folks: https://github.com/cdh4u/draft-sessiontimer-race >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>> >>> >>> >>> >>> On 07/09/17 19:38, "sipcore on behalf of Christer Holmberg" >>> >>> wrote: >>> >>>> Hi, >>>> >>>>>> seen from my point of view the UAC should ignore the Session timer >>>>>> proposal within the UPDATE. >>>>>> As long as the negotiation is ongoing. >>>>>> >>>>>> Nevertheless we have also observed this curious session timer >>>>>> behavior >>>>>> in our network. >>>>>> >>>>>> I think we need some clarifications to the RFC. Perhaps also to other >>>>>> sections to make it more readable. >>>>>> My experience is that people have problems in following how the >>>>>> session timer should work within a complex SIP networks (e.g. IMS). >>>>>> >>>>>> What is about updating the RFC4028. >>>>> >>>>> Like most of the older SIP RFCs, it probably deserves an update. The >>>>> problem is whether going to the trouble will have any effect on >>>>> implementations. I think the most we > should hope to do is *clarify* >>>>> in >>>>> cases where there is ambiguity, so that when interoperability problems >>>>> arise it is clear who needs to change. >>>> >>>> Yes. In my case, implementation(s) WILL be changed. The question is >>>> WHICH >>>> implementation(s) :) >>>> >>>> So, my suggestion would be: >>>> >>>> 1) Specify/clarify that SE must not be sent during session-timer >>>> negotiation >>>> 2) Specify that one must send a 491 (or some other more appropriate >>>> code) >>>> response if receiving SE during session-timer negotiation >>>> >>>> For the above, I think we can do it using an errata. >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> >>>> >>>>>> -----Ursprüngliche Nachricht----- >>>>>> Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von >>>>>> Christer Holmberg >>>>>> Gesendet: Donnerstag, 7. September 2017 11:34 >>>>>> An: Paul Kyzivat ; sipcore@ietf.org >>>>>> Betreff: Re: [sipcore] Session-timer issue >>>>>> >>>>>> Hi, >>>>>> >>>>>>>> The following issue has been around for some time already (there is >>>>>>>> also an errata #4744), and as it causes problems (the INVITE is >>>>>>>> rejected with a >>>>>>>> 480 response) in deployed networks, so I think it needs to be >>>>>>>> fixed. >>>>>>>> People seem to have different opinions on which node is acting >>>>>>>> wrongly, so I hope we can sort it out :) >>>>>>> >>>>>>> This is an interesting problem. I agree that it is unclear exactly >>>>>>> what ought to happen in this case. (But I don't understand why >>>>>>> someone thinks a 480 is a good way to resolve it.) >>>>>> >>>>>> Whether 480 is the best solution or not is not the issue, in my >>>>>> opinion. >>>>>> One could also claim that the UPDATE should be rejected. Etc. >>>>>> >>>>>> The issue is that there is a session-timer negotiation "race >>>>>> condition", and we should forbid that (rejecting the UPDATE could be >>>>>> part of such solution). >>>>>> >>>>>> Regards, >>>>>> >>>>>> Christer >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Paul >>>>>>> >>>>>>>> Below is a call flow showing the problem: >>>>>>>> >>>>>>>> >>>>>>>> UA Proxy AS >>>>>>>> >>>>>>>> -------------------> >>>>>>>> INVITE (#1) >>>>>>>> Supported:timer >>>>>>>> SE:refresher=uac >>>>>>>> >>>>>>>> -------------------> >>>>>>>> INVITE (#2) >>>>>>>> Supported:timer >>>>>>>> SE:refresher=uac >>>>>>>> >>>>>>>> >>>>>>>> <------------------- >>>>>>>> 18x (#3) >>>>>>>> >>>>>>>> <------------------- >>>>>>>> 18x (#4) >>>>>>>> >>>>>>>> ++++++ early dialog established +++++++ >>>>>>>> >>>>>>>> <------------------- >>>>>>>> UPDATE (#5) >>>>>>>> Supported:timer >>>>>>>> SE:refresher=uas >>>>>>>> >>>>>>>> <------------------- >>>>>>>> UPDATE (#6) >>>>>>>> Supported:timer >>>>>>>> SE:refresher=uas >>>>>>>> >>>>>>>> >>>>>>>> -------------------> >>>>>>>> 200 (UPDATE) (#7) >>>>>>>> >>>>>>>> -------------------> >>>>>>>> 200 (UPDATE) (#8) >>>>>>>> Require:timer >>>>>>>> SE:refresher=uac >>>>>>>> >>>>>>>> >>>>>>>> <------------------- >>>>>>>> 480 (INVITE) (#9) >>>>>>>> >>>>>>>> <------------------- >>>>>>>> 480 (INVITE (#10) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> A few things to note: >>>>>>>> >>>>>>>> >>>>>>>> N1: The 18x does not contain the SE (Session-Expires) header field, >>>>>>>> because according to section 4 of RFC 4028 the header >>>>>>>> field is only >>>>>>>> allowed in INVITE, UPDATE and 2xx. So, when the UPDATE >>>>>>>> request >>>>>>>> (#5) is sent, the initial session timer negotiation is >>>>>>>> still >>>>>>>> ongoing. >>>>>>>> >>>>>>>> >>>>>>>> N2: The UPDATE request (#5) contains a Session-Expires header >>>>>>>> field. >>>>>>>> Section 7.4 of RFC 4028 says: >>>>>>>> >>>>>>>> "In a session refresh request sent within a dialog with an >>>>>>>> active >>>>>>>> session timer, the Session-Expires header field SHOULD be >>>>>>>> present." >>>>>>>> >>>>>>>> Now, a dialog (early) HAS been established when the UPDATE >>>>>> request is >>>>>>>> sent, but as the initial session timer negotiation is >>>>>>>> still >>>>>>>> ongoing, I assume the session timer isn¹t yet "active"? >>>>>>>> >>>>>>>> >>>>>>>> N3: The UPDATE 200 response (#7) does not contain the >>>>>>>> Session-Expires >>>>>>>> header field. It is added by the proxy, based on the >>>>>>>> procedures in >>>>>>>> Section 8.2 of RFC 4028: >>>>>>>> >>>>>>>> "Because there is no Session-Expires or Require >>>>>>>> header field >>>>>>>> in the response, the proxy knows that it is the >>>>>>>> first >>>>>>>> session-timer-aware proxy to receive the response. >>>>>>>> This proxy >>>>>>>> MUST insert a Session-Expires header field into >>>>>>>> the >>>>>>>> response >>>>>>>> with the value it remembered from the forwarded >>>>>>>> request. >>>>>>>> It >>>>>>>> MUST >>>>>>>> set the value of The 'refresher' parameter to >>>>>>>> 'uac'. >>>>>>>> The proxy MUST >>>>>>>> add the 'timer' option tag to any Require header >>>>>>>> field in the >>>>>>>> response, and if none was present, add the Require >>>>>>>> header field with >>>>>>>> that value before forwarding it upstream." >>>>>>>> >>>>>>>> >>>>>>>> Now, one could argue that the UA should include something in the >>>>>>>> UPDATE response (#7), but I think that is not a solution as the UA >>>>>>>> may be confused. >>>>>>>> Instead, based on my understanding of the text in section 7.4 (see >>>>>>>> above) the UPDATE request (#5) should not contain any session timer >>>>>>>> information. This is also more or less what the errata suggests. >>>>>>>> >>>>>>>> Comments? >>>>>>>> >>>>>>>> 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 >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>> >>> _______________________________________________ >>> 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 Fri Sep 15 08:00:24 2017 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 18D69133409; Fri, 15 Sep 2017 08:00:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 iitlfdv-WkdW; Fri, 15 Sep 2017 08:00:21 -0700 (PDT) Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::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 1FBCB13344F; Fri, 15 Sep 2017 08:00:18 -0700 (PDT) Received: by mail-ua0-x22d.google.com with SMTP id s15so1375179uag.1; Fri, 15 Sep 2017 08:00:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/M1M7zJyQEdZkAyVEVKiZ307fNvSBWwPQK5Fb/cmufQ=; b=rFw5I3rUe8cHqGw8y97mYzx3WibCSOKJ9jaL8M2MrYtfEjy4DkadKEwCgwo+YObDIM GpGz+4zDZHTiVJL2scLpAqzEPrdVy5IooCeEQBsAuye8nyCw/dfd174NKI0iQ/ekT/vh eb5/KAAxz/RB+m+hGJw1X5uQaNJS4GN7d+NXgcFhdV9mYT3Dthm32dWUbFxJ/FGOMWUo SKykVhueUwO5JxKiJzscxs7C1ZZWlmoCYOkP8XbeaG1wtBKYe678oc70BjKhb0TItw1g 2BkFBMwdNICGAFJgYdNG4+8KNNht7HaL1m3pPKkA6XBuG2v5r2WJbbYRxZ5/2VpPgANJ dFQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/M1M7zJyQEdZkAyVEVKiZ307fNvSBWwPQK5Fb/cmufQ=; b=uArEhheyZbrGezEI1cRcx7+sZRlloZRkU++mvTZDBGb0dW7RfZkMSsRFWsM6CkB9/6 GwQoVM88a9PbhALeNvpvue2CWSz2ATkBsoE2+iQM0FBlJrryDf797KGYznfUM+MyFOZR D4uPDO/iNZU6MOGjgRouriuJ9Ro+C+cDZY4n+ZRSQefSiAOdP1BGUwh1r4w6Z01/AWfh 3gTcXdU8aH783vrMWSFOF1oLRQLzoBt557yi+NuYcL6mhYMjM24xZ8cFvce6g0XFPLaV BKW9RKsYxBhVGp8Ji4x49XG0pnvgIlOHU9X4t9F16UMllkm12QLQDWyXV3VxQCQ/2CKh qkUA== X-Gm-Message-State: AHPjjUjjieSgyKICrDZ5ST1k848Ul+gTKuvsFQ1AUFcAx3thr7zMJKQ3 GLzD1vVhJvBr6IaW5qq6XM8WNHSTJjuSXEaLeSvlCA== X-Google-Smtp-Source: AOwi7QDWDNA86siJdSYp7zxbozQPGCSRoS36HpnYJ9o2mVIB5+JykxiTh2ifgyOoQ1hGA1sp94l0Yx5ztQgTalFImh4= X-Received: by 10.176.22.109 with SMTP id l42mr22552515uae.196.1505487617061; Fri, 15 Sep 2017 08:00:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.91.152 with HTTP; Fri, 15 Sep 2017 08:00:16 -0700 (PDT) In-Reply-To: <764c7d0a66ed8fcfe17472219f8e64ac@mail.gmail.com> References: <764c7d0a66ed8fcfe17472219f8e64ac@mail.gmail.com> From: Rifaat Shekh-Yusef Date: Fri, 15 Sep 2017 11:00:16 -0400 Message-ID: To: Brett Tate Cc: "sipcore@ietf.org" , draft-yusef-sipcore-digest-scheme@ietf.org Content-Type: multipart/alternative; boundary="001a114563c4a0f98005593ba699" Archived-At: Subject: Re: [sipcore] draft-yusef-sipcore-digest-scheme-05: internationalization X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Sep 2017 15:00:23 -0000 --001a114563c4a0f98005593ba699 Content-Type: text/plain; charset="UTF-8" All, I am working on updating the Digest document, but I did not see any response to this email from Brett. Is there any interest in adding I18N support to the Digest document? Regards, Rifaat On Thu, Apr 27, 2017 at 8:38 AM, Brett Tate wrote: > Hi, > > Concerning draft-yusef-sipcore-digest-scheme-05, does RFC 7616 section 4 > "Internationalization Considerations" apply to SIP? If so, it potentially > should be mentioned within the draft. > > The following link from 2011 discusses some charset ambiguity within SIP > authentication. > > http://www.ietf.org/mail-archive/web/sipcore/current/msg04507.html > > Thanks, > Brett > --001a114563c4a0f98005593ba699 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All,

I am working on updating the Diges= t document, but I did not see any response to this email from Brett.
<= div>Is there any interest in adding I18N support to the Digest document?

Regards,
=C2=A0Rifaat

=

On Thu, Apr= 27, 2017 at 8:38 AM, Brett Tate <brett@broadsoft.com> wro= te:
Hi,

Concerning draft-yusef-sipcore-digest-scheme-05, does RFC 7616 section= 4
"Internationalization Considerations" apply to SIP?=C2=A0 If so, = it potentially
should be mentioned within the draft.

The following link from 2011 discusses some charset ambiguity within SIP authentication.

http://www.ietf.org/mail-arch= ive/web/sipcore/current/msg04507.html

Thanks,
Brett

--001a114563c4a0f98005593ba699-- From nobody Mon Sep 18 11:13:29 2017 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 A86681342C1 for ; Mon, 18 Sep 2017 11:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 nK-j-XIQDfzp for ; Mon, 18 Sep 2017 11:13:21 -0700 (PDT) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (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 E0D1C133211 for ; Mon, 18 Sep 2017 11:13:20 -0700 (PDT) Received: by mail-vk0-x233.google.com with SMTP id p204so697617vkp.7 for ; Mon, 18 Sep 2017 11:13:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=OzcMdVKVMD/EBUYL6SqmM8DSUZlDZfzvX1wasna8OC8=; b=rpuK/bxDLPEBwT5q3jFJ0bnAldKqCw3duxyIasKVmEO9s1z/ejsSo/1a7Yyfb+jNa8 uf37LSOffI/w+PJTxGcBIADsuPCS25TBx/VsDfysjEJtyRz66iZgcgsoatmJhRC+dPTs PUMlmOJWPRJxdi5+Ze/Mwz1iJvTbTtkyZ8HYTGMhPgI1swMcWNS5FEIqr8topc7FC3qj qj2lmuYud74ia8ox+yEOJJdAD5177NJyzLv8tOGy70ZTcqhagHw/80qaQqnHNBtPobBi dI7kjtTMOb0eLg2cw3MSf/bRo7hiVBFW4vCMWGvA0NaobM08Se7POpK8lg3pi3mVbE87 /H6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=OzcMdVKVMD/EBUYL6SqmM8DSUZlDZfzvX1wasna8OC8=; b=fCDzhSSsanGmAs6DZPJQYVwpylKYmL/uWw/RLEDJ8SNTZnH/EkqDNqmGnBnxtpd3uF 5M5J97XCSuoOBMTjQpyxwFKNvv+gLRFcNsXsfdneJeRUCqNzzWiKSI160jnMIfSktWbD E9q/jpsTeSyFZ7I/bEcZGPtT9fvRGErgDpFIYmRwrqXFlodcmndZhOiB1ToDtfpYfh5/ Kb2DG1+rMCnST3bWfss/GzE0njdziW1wnNTFTXjXnD+yMitjHYL+II03H3Bqtsb48v+d 6GeI+UDdLD8fwCCLNb6i2wZXQg1hUFShrDYeAim8pq9JrCtgI0vVqbEMYpc+fRAU7dhM Q9gA== X-Gm-Message-State: AHPjjUgkSvqzkNw2SOYP2LdwJtaPWVqH6t1o9sEj8lw4D/YDVUmTqgjM jFoULNafaXg5cyygACDnwYcNPtTMnQ227dSTXNboGjEq X-Google-Smtp-Source: AOwi7QDoNxz5sCwzcXw/H/l05Nwmdk5BPylZuh2UzbLyw/faKCEWJpZQj8f46SKDpaHHDiqU9GJ1lbbKSW4l5UENm+M= X-Received: by 10.31.63.199 with SMTP id m190mr26308049vka.47.1505758399676; Mon, 18 Sep 2017 11:13:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.91.152 with HTTP; Mon, 18 Sep 2017 11:13:19 -0700 (PDT) In-Reply-To: <150575802051.15584.14810825101894334715.idtracker@ietfa.amsl.com> References: <150575802051.15584.14810825101894334715.idtracker@ietfa.amsl.com> From: Rifaat Shekh-Yusef Date: Mon, 18 Sep 2017 14:13:19 -0400 Message-ID: To: "sipcore@ietf.org" Content-Type: multipart/alternative; boundary="001a114dbc7887c44f05597ab27f" Archived-At: Subject: [sipcore] Fwd: New Version Notification for draft-yusef-sipcore-digest-scheme-06.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Sep 2017 18:13:28 -0000 --001a114dbc7887c44f05597ab27f Content-Type: text/plain; charset="UTF-8" Hi, I have submitted a new version of the Digest document with few changes. The new version does not address the I18N issue, as I did not see much interest so far. I would appreciate any reviews and comments about this new version. Regards, Rifaat ---------- Forwarded message ---------- From: Date: Mon, Sep 18, 2017 at 2:07 PM Subject: New Version Notification for draft-yusef-sipcore-digest-scheme-06.txt To: Rifaat Shekh-Yusef A new version of I-D, draft-yusef-sipcore-digest-scheme-06.txt has been successfully submitted by Rifaat Shekh-Yusef and posted to the IETF repository. Name: draft-yusef-sipcore-digest-scheme Revision: 06 Title: The Session Initiation Protocol (SIP) Digest Authentication Scheme Document date: 2017-09-18 Group: Individual Submission Pages: 8 URL: https://www.ietf.org/internet-drafts/draft-yusef-sipcore- digest-scheme-06.txt Status: https://datatracker.ietf.org/doc/draft-yusef-sipcore- digest-scheme/ Htmlized: https://tools.ietf.org/html/draft-yusef-sipcore-digest- scheme-06 Htmlized: https://datatracker.ietf.org/doc/html/draft-yusef-sipcore- digest-scheme-06 Diff: https://www.ietf.org/rfcdiff?url2=draft-yusef-sipcore- digest-scheme-06 Abstract: This document updates the Digest Access Authentication scheme used by the Session Initiation Protocol (SIP) to add support for SHA2 digest algorithms to replace the MD5 algorithm. 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 --001a114dbc7887c44f05597ab27f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I have submitted a new version of t= he Digest document with few changes.
The new version does not add= ress the I18N issue, as I did not see much interest so far.

<= /div>
I would appreciate any reviews and comments about this new versio= n.

Regards,
=C2=A0Rifaat
<= br>

---------- Forwarded message -= ---------
From: <= ;internet-drafts@ietf.org&g= t;
Date: Mon, Sep 18, 2017 at 2:07 PM
Subject: New Version Not= ification for draft-yusef-sipcore-digest-scheme-06.txt
To: Rifaat Shekh-= Yusef <rifaat.ietf@gmail.com>



A new version of I-D, draft-yusef-sipcore-digest-scheme-06.txt
has been successfully submitted by Rifaat Shekh-Yusef and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-yusef-sipcore-digest-scheme
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A006
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The Session Initiation Protocol (S= IP) Digest Authentication Scheme
Document date:=C2=A0 2017-09-18
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 8
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-yuse= f-sipcore-digest-scheme-06.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-yusef-sipcore-dige= st-scheme/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0= https://tools.ietf.org/html/draft-yusef-sipcore-digest-scheme-06<= /a>
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-yusef-sipcore-= digest-scheme-06
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-yusef-sipc= ore-digest-scheme-06

Abstract:
=C2=A0 =C2=A0This document updates the Digest Access Authentication scheme = used by
=C2=A0 =C2=A0the Session Initiation Protocol (SIP) to add support for SHA2 = digest
=C2=A0 =C2=A0algorithms to replace the MD5 algorithm.




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

The IETF Secretariat


--001a114dbc7887c44f05597ab27f-- From nobody Tue Sep 19 06:33:15 2017 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 18D86134319 for ; Tue, 19 Sep 2017 06:33:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.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 UglS1r5xJR_e for ; Tue, 19 Sep 2017 06:33:11 -0700 (PDT) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (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 83A4013430C for ; Tue, 19 Sep 2017 06:33:11 -0700 (PDT) Received: by mail-qt0-x231.google.com with SMTP id o52so2196qtc.9 for ; Tue, 19 Sep 2017 06:33:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:message-id:date:to; bh=tpm3rdCtOxNOVcPICadl1e36vRg83A8HlUJJGKndZBw=; b=VABZDNJ+myWwDzNbOwM1P9vfJ+oNqQl37vvySi+acmloDPoaLc8XxRcKNyYVn3EwdG iBeA8NEYSmFP+Eg3DUpaILvogzpJc4OSdlm+Y/g5ZAcP0aQ0jsYL9DFGobg0tFmkeMgT Sai+vRcfZVEiDcbbuvP6cgX5PHFGlnFImDvEnq1qNQxP2l2fDoMJS9w28V4O/4BhNdAx 5X68WGYpV9OBPJUyHCauzdvIWDy4z7WlTPfUBy+5czgX91mVWxx3afE28PZ3aAYFCLF/ VsaHLPm3CE42bOBDu7CcWLZ8DEFOPPkW+ij8U0/BqYH861NNwEehph2pedOJAr2BzLT7 qqSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=tpm3rdCtOxNOVcPICadl1e36vRg83A8HlUJJGKndZBw=; b=NYuBPUaUEWnVnShc5J/GIDsNVFLAMH20/GC5zEGroyItbISwyGRp+ev+vDxxPLtnBy lzMCzMrvhieGwPlTWNIzqcO8TddY2lbTiHNKCrXs9/618v0CfkNWJjoBXFam1jFm9Dch gcF2dvpZdHxpZjpxTH8ZT924JlJopsxA4hRTNo0kLtZ2j6XZzeoHF71b724YB3bP4MIk 0Zid0qP3Q0Y6YHKlkgimphG3PWbQhM31EICKlLXpsKUdX6w+eiiQnC1/TPow/mkejU8t vB9UI0hoyXwXfjIPmT026rvkM/+ci1ezFcCMok8CZClvn/PsjPqGItl54sqCVxofKSvx w2Ww== X-Gm-Message-State: AHPjjUhQO3n+gyvm0CUDdk6g9yHhO4hgjr7hiP8bS+5URKuR2x8tMnNW ElXaR0iL7N5LsO2TCmKPaJml1FoLJtQ= X-Google-Smtp-Source: AOwi7QD7IS/jDj6JAtPmqwu+BLmlRLcVCKMc13mlxCaftOQTcW3Uyh5NHRVp68eXkprniE+LukLHow== X-Received: by 10.237.53.118 with SMTP id b51mr2140579qte.280.1505827990209; Tue, 19 Sep 2017 06:33:10 -0700 (PDT) Received: from [10.33.192.12] (neustar-sthide-nat1.neustar.biz. [156.154.81.54]) by smtp.gmail.com with ESMTPSA id q204sm6876097qke.37.2017.09.19.06.33.08 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Sep 2017 06:33:09 -0700 (PDT) From: Brian Rosen Content-Type: multipart/alternative; boundary="Apple-Mail=_C63147D1-355E-49AD-922C-B60B54387BFC" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: Date: Tue, 19 Sep 2017 09:33:06 -0400 To: sipcore@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [sipcore] Call For Adoption draft-holmberg-sipcore-sessiontimer-race X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 13:33:14 -0000 --Apple-Mail=_C63147D1-355E-49AD-922C-B60B54387BFC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii We propose to adopt draft-holmberg-sipcore-sessiontimer-race as a = sipcore document. Please provide comments by October 3. Brian = --Apple-Mail=_C63147D1-355E-49AD-922C-B60B54387BFC Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii We propose to adopt draft-holmberg-sipcore-sessiontimer-race as a sipcore document.  Please provide comments by October 3.

Brian <as co-chair>
--Apple-Mail=_C63147D1-355E-49AD-922C-B60B54387BFC-- From nobody Tue Sep 19 06:57:15 2017 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 DAF89134322 for ; Tue, 19 Sep 2017 06:57:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=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 DKl6gW8l6dVK for ; Tue, 19 Sep 2017 06:57:07 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 D878E132930 for ; Tue, 19 Sep 2017 06:57:07 -0700 (PDT) Received: from pps.filterd (m0053301.ppops.net [127.0.0.1]) by mx0a-00191d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v8JDuwwY002614; Tue, 19 Sep 2017 09:57:05 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by mx0a-00191d01.pphosted.com with ESMTP id 2d34evg9w8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 19 Sep 2017 09:57:04 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v8JDughS019379; Tue, 19 Sep 2017 09:56:42 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v8JDuWjQ019240 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 19 Sep 2017 09:56:35 -0400 Received: from MISOUT7MSGHUBAE.ITServices.sbc.com (MISOUT7MSGHUBAE.itservices.sbc.com [130.9.129.149]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Tue, 19 Sep 2017 13:56:18 GMT Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.123]) by MISOUT7MSGHUBAE.ITServices.sbc.com ([130.9.129.149]) with mapi id 14.03.0361.001; Tue, 19 Sep 2017 09:56:18 -0400 From: "DOLLY, MARTIN C" To: Brian Rosen , "sipcore@ietf.org" Thread-Topic: [sipcore] Call For Adoption draft-holmberg-sipcore-sessiontimer-race Thread-Index: AQHTMUvf7lr7KQOU7UG5u4kViw4yCKK8O3eA Date: Tue, 19 Sep 2017 13:56:17 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.225.220] Content-Type: multipart/alternative; boundary="_000_E42CCDDA6722744CB241677169E836565D543069MISOUT7MSGUSRDB_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-09-19_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1709190198 Archived-At: Subject: Re: [sipcore] Call For Adoption draft-holmberg-sipcore-sessiontimer-race X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 13:57:14 -0000 --_000_E42CCDDA6722744CB241677169E836565D543069MISOUT7MSGUSRDB_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable AT&T supports adoption. From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Tuesday, September 19, 2017 9:33 AM To: sipcore@ietf.org Subject: [sipcore] Call For Adoption draft-holmberg-sipcore-sessiontimer-ra= ce We propose to adopt draft-holmberg-sipcore-sessiontimer-race as a sipcore d= ocument. Please provide comments by October 3. Brian --_000_E42CCDDA6722744CB241677169E836565D543069MISOUT7MSGUSRDB_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

AT&T supports adoption.

 

From: sipcore [mailto:sipcore-bounce= s@ietf.org] On Behalf Of Brian Rosen
Sent: Tuesday, September 19, 2017 9:33 AM
To: sipcore@ietf.org
Subject: [sipcore] Call For Adoption draft-holmberg-sipcore-sessiont= imer-race

 

We propose to adopt draft-holmberg-sipcore-ses= siontimer-race as a sipcore document.  Please provide comments by= October 3.

 

Brian <as co-chair>

--_000_E42CCDDA6722744CB241677169E836565D543069MISOUT7MSGUSRDB_-- From nobody Tue Sep 19 07:04:26 2017 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 7138A133080 for ; Tue, 19 Sep 2017 07:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 P98N80F-VvRF for ; Tue, 19 Sep 2017 07:04:24 -0700 (PDT) Received: from alum-mailsec-scanner-7.mit.edu (alum-mailsec-scanner-7.mit.edu [18.7.68.19]) by ietfa.amsl.com (Postfix) with ESMTP id 1561D124F57 for ; Tue, 19 Sep 2017 07:04:23 -0700 (PDT) X-AuditID: 12074413-3a3ff70000007929-e8-59c123e70594 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id F8.3F.31017.7E321C95; Tue, 19 Sep 2017 10:04:23 -0400 (EDT) Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id v8JE4Mma024058 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 19 Sep 2017 10:04:23 -0400 To: sipcore@ietf.org References: From: Paul Kyzivat Message-ID: Date: Tue, 19 Sep 2017 10:04:22 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJIsWRmVeSWpSXmKPExsUixO6iqPtc+WCkwezb4hZff2xic2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxpU3YgUvmSp2r/nK2MC4iqmLkZNDQsBEYv7XV8xdjFwcQgI7 mCT+TbvDCuH8YJI4Oa+XDaRKWCBY4nv3A3YQW0RAROLZ9H9gcSEBR4mXJ3vA4mwCWhJzDv1n AbF5Bewlns+bC1TDwcEioCpxa5MrSFhUIE3i3+6zjBAlghInZz4BK+cUcJL49/QbK4jNLGAr cWfubmYIW1zi1pP5TBC2vETz1tnMExj5ZyFpn4WkZRaSlllIWhYwsqxilEvMKc3VzU3MzClO TdYtTk7My0st0jXXy80s0UtNKd3ECAlJ4R2Mu07KHWIU4GBU4uEVuLY/Uog1say4MvcQoyQH k5Ior7LCwUghvqT8lMqMxOKM+KLSnNTiQ4wSHMxKIrxaskA53pTEyqrUonyYlDQHi5I4r9oS dT8hgfTEktTs1NSC1CKYrAwHh5IEbw0w9oQEi1LTUyvSMnNKENJMHJwgw3mAhjeA1PAWFyTm FmemQ+RPMVpy3Hh4/Q8TR0/PDSC54+bdP0xCLHn5ealS4rwrlYAaBEAaMkrz4GbCUswrRnGg F4V5mUDG8gDTE9zUV0ALmYAWZm84ALKwJBEhJdXA6FzEnXz3bazkjpCuVyvO9rfvS/3IcWi9 WYw/i6BTz7JDYmckPe+94JvuyXL48uSFoc8KZfc2+i137W2Zl69z8olnyuTamtNHsrZWMyw2 yVKNd306Z7GN3u/OUAm3x4vaP22aZznfq4WX7cmNbtNNZzXdBPaeOcT/3KPrZqahtP30OOWJ IW+FlViKMxINtZiLihMBnNqVXgwDAAA= Archived-At: Subject: Re: [sipcore] Call For Adoption draft-holmberg-sipcore-sessiontimer-race X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 14:04:25 -0000 +1 On 9/19/17 9:33 AM, Brian Rosen wrote: > We propose to adopt draft-holmberg-sipcore-sessiontimer-race as a > sipcore document.  Please provide comments by October 3. > > Brian > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Tue Sep 19 09:41:24 2017 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 1DEC41331C1 for ; Tue, 19 Sep 2017 09:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.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 hBROAN5KXC1E for ; Tue, 19 Sep 2017 09:41:21 -0700 (PDT) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::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 7B26512895E for ; Tue, 19 Sep 2017 09:41:21 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id y126so163394itb.5 for ; Tue, 19 Sep 2017 09:41:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=Sxr4kvqOptF4C08SnEQU4/RodwtLm0BI2L4I5eBmpTM=; b=BN2BcNzUW/qb4cN+zScAxkmpquIEM2qRtsL/CVc5lU+yLWKRCsRwr/ogDPWU82lRie pAOX1iixkBbX/6DLl9w4sGJXqBknXDe6jv6WFXUi3pulfDF0RH1jlm4LVq+3qVslAniI ixek7keleVmubSP/j98fk49/NNRhXslzTh5ymyfxEIuuWPDeI5i8rX/4+AAZ7HRACXx4 oYb62ks6TG39VStby+AaTGJWpo7iKPNeoLiN4XJwIARzYYSj0ApDxl614LwPJVrbVE0v w362RfZdTQ2ilewvMVepIfuIbfU8E/MYsRWXrLUZrQphNjWVpvxU/VXtnLJiyDXYjJEb dTKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=Sxr4kvqOptF4C08SnEQU4/RodwtLm0BI2L4I5eBmpTM=; b=MmnJCp4igsc5Kkf+7wISPAdOPsfJyZKIhYNJPyahn8aq2YLGszNzBekXDmxFhVwT7R l+FsikvcVzAB/eprvwClxBJj9zrkwGTN1pWmiS3qhmwSj8R6NKg1BfYtEpUWkUDWTPYu Gqj+h2ixNA3V57Jrlw8qI+PS7DYxj3YzNfiScmLQDoMS//zkKa20OEiV29eVOF6d3j8D oubEV3z4VknepwwHsU6pwC/UWUM6KsV4Hyat+HeSuCuKC+r22Df9gCBJ7KAd2bV+6zLD A9nxPjteTr1B1rTBUu/ZnThrxolDE6SeVk1nh9TwKS8BfftsCk1L8pvnvCNq2zGcotBp volw== X-Gm-Message-State: AHPjjUgV/xDcWQsNJqzxkwzyibwIQPgNVFQUaPN86eIOBgExqcWsVclV 8l/os1ue+yYqVHqEaEx2L0o9HX9dlng= X-Google-Smtp-Source: AOwi7QBn4jwgPcIkAkT5TiwCA3RSvl1hMCH5GAnUtJs6fhaHowXP2cGztoVZ7bM1bdon2URqwJgdaA== X-Received: by 10.36.0.215 with SMTP id 206mr2468198ita.84.1505839280143; Tue, 19 Sep 2017 09:41:20 -0700 (PDT) Received: from [10.33.192.12] (neustar-sthide-nat1.neustar.biz. [156.154.81.54]) by smtp.gmail.com with ESMTPSA id o192sm1179266itc.27.2017.09.19.09.41.18 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Sep 2017 09:41:18 -0700 (PDT) From: Brian Rosen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <28BEFE89-D496-4A1B-8F75-99CFF4025374@brianrosen.net> Date: Tue, 19 Sep 2017 12:41:15 -0400 To: sipcore@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [sipcore] Is there interest in draft-johansson-sip-he-connection or not X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 16:41:23 -0000 This document has been hanging around for some time with no motion. Are work group members still interested in it, or should we abandon it? If you want it, please say so, and review/provide comments. Brian From nobody Tue Sep 19 13:21:43 2017 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 25A55134397 for ; Tue, 19 Sep 2017 13:21:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 YrJM-X_4LmHF for ; Tue, 19 Sep 2017 13:21:40 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A1A2134390 for ; Tue, 19 Sep 2017 13:21:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=768; q=dns/txt; s=iport; t=1505852500; x=1507062100; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=lJcNvNiX0qta3rYL3xjONY/SuhdPWioEP6NYbz460yM=; b=DY5JLA/WRnZyCB2u2LfrW6vJ5bDvhhDWnNVA2ppYZGkwIYDmsIfqJ1xP UEc3VdErK6SZw5ue0nbB+YhtH/+ZB6L3S4Ls6FoFvptYEr6ztwXIJDtfF 5hVmDMdzesZZcueCSPoj09QIwjTaLF5Yu+xf08BQ/qvzNPVNzsZ8ucyXg g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CeAADZe8FZ/5JdJa1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1pkbicHg26KII93gXSWJYISChgLhElPAhqEQT8YAQIBAQEBAQE?= =?us-ascii?q?BayiFGAEBAQECAQEBIRE6CwULAgEIDgoCAiYCAgIlCxUQAgQOBYorCBCoc4Ini?= =?us-ascii?q?x8BAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYEOgh2CAoFRgg8LgnKEe4MTL4IxBaE?= =?us-ascii?q?MApRUgXsYhWqKfZUKAhEZAYE4AR84gQ13FUkSAYcJdodrgQ8BAQE?= X-IronPort-AV: E=Sophos;i="5.42,418,1500940800"; d="scan'208";a="301083479" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Sep 2017 20:21:39 +0000 Received: from XCH-RCD-008.cisco.com (xch-rcd-008.cisco.com [173.37.102.18]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v8JKLdPM013673 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 19 Sep 2017 20:21:39 GMT Received: from xch-aln-009.cisco.com (173.36.7.19) by XCH-RCD-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 19 Sep 2017 15:21:39 -0500 Received: from xch-aln-009.cisco.com ([173.36.7.19]) by XCH-ALN-009.cisco.com ([173.36.7.19]) with mapi id 15.00.1263.000; Tue, 19 Sep 2017 15:21:38 -0500 From: "Gonzalo Salgueiro (gsalguei)" To: Brian Rosen CC: SIPCORE Thread-Topic: [sipcore] Is there interest in draft-johansson-sip-he-connection or not Thread-Index: AQHTMWYkPknTKMjYM0ys9ILfPXerbaK8+tAA Date: Tue, 19 Sep 2017 20:21:38 +0000 Message-ID: <3619DEC3-5307-45FA-B738-24BB5BD22F97@cisco.com> References: <28BEFE89-D496-4A1B-8F75-99CFF4025374@brianrosen.net> In-Reply-To: <28BEFE89-D496-4A1B-8F75-99CFF4025374@brianrosen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.215.186] Content-Type: text/plain; charset="utf-8" Content-ID: <00CF05EBB9186C4CA04B645F8ADACF39@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sipcore] Is there interest in draft-johansson-sip-he-connection or not X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 20:21:42 -0000 SeKAmWQgbGlrZSB0byBzZWUgdGhpcyB3b3JrIGdldCBmaW5pc2hlZCwgZXNwZWNpYWxseSBzaW5j ZSB0aGUgYnVsayBvZiB0aGUgd29yayBpcyBjb21wbGV0ZWQuDQoNCi1HDQoNCj4gT24gU2VwIDE5 LCAyMDE3LCBhdCAxMjo0MSBQTSwgQnJpYW4gUm9zZW4gPGJyQGJyaWFucm9zZW4ubmV0PiB3cm90 ZToNCj4gDQo+IFRoaXMgZG9jdW1lbnQgaGFzIGJlZW4gaGFuZ2luZyBhcm91bmQgZm9yIHNvbWUg dGltZSB3aXRoIG5vIG1vdGlvbi4NCj4gDQo+IEFyZSB3b3JrIGdyb3VwIG1lbWJlcnMgc3RpbGwg aW50ZXJlc3RlZCBpbiBpdCwgb3Igc2hvdWxkIHdlIGFiYW5kb24gaXQ/DQo+IA0KPiBJZiB5b3Ug d2FudCBpdCwgcGxlYXNlIHNheSBzbywgYW5kIHJldmlldy9wcm92aWRlIGNvbW1lbnRzLg0KPiAN Cj4gQnJpYW4NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+IHNpcGNvcmUgbWFpbGluZyBsaXN0DQo+IHNpcGNvcmVAaWV0Zi5vcmcNCj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlDQoNCg== From nobody Tue Sep 19 19:54:27 2017 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 D9A451321A1 for ; Tue, 19 Sep 2017 19:54:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=sonusnetworks.onmicrosoft.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 sXTST0JF8RCu for ; Tue, 19 Sep 2017 19:54:24 -0700 (PDT) Received: from us-smtp-delivery-126.mimecast.com (us-smtp-delivery-126.mimecast.com [216.205.24.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCEC2120724 for ; Tue, 19 Sep 2017 19:54:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=aEeXm6O/bkPOEu0s7B5nFua21F2gDG7trNN99/nv8zs=; b=BVW3RA2ZTqnAMLvO6k1iDPqiOuHkqZHi3BFlTZcE2fJTns695p0gH764yrFzbnwx6SYvGnyUqpkJURkMAPL0iUplPcYhIoGbmzz4X/SDPO6dNpPQDoINpIgidf51SpVps7Lpxs6vCJfDxXQdDTV/hKV6N9qPsUvrlqc8EjUOxh8= Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01lp0181.outbound.protection.outlook.com [216.32.180.181]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-91-WeHWB61fPMm66S7jNYUL_w-1; Tue, 19 Sep 2017 22:54:21 -0400 Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB2318.namprd03.prod.outlook.com (10.166.210.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Wed, 20 Sep 2017 02:54:20 +0000 Received: from SN2PR03MB2350.namprd03.prod.outlook.com ([fe80::d88f:793d:af1f:f651]) by SN2PR03MB2350.namprd03.prod.outlook.com ([fe80::d88f:793d:af1f:f651%18]) with mapi id 15.20.0077.009; Wed, 20 Sep 2017 02:54:20 +0000 From: "Asveren, Tolga" To: "Gonzalo Salgueiro (gsalguei)" , Brian Rosen CC: SIPCORE Thread-Topic: [sipcore] Is there interest in draft-johansson-sip-he-connection or not Thread-Index: AQHTMWYmMzM1736yPUugCDvesaGM4aK8pv4AgABtZCA= Date: Wed, 20 Sep 2017 02:54:19 +0000 Message-ID: References: <28BEFE89-D496-4A1B-8F75-99CFF4025374@brianrosen.net> <3619DEC3-5307-45FA-B738-24BB5BD22F97@cisco.com> In-Reply-To: <3619DEC3-5307-45FA-B738-24BB5BD22F97@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [73.29.18.75] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN2PR03MB2318; 20:5BjshHQKLfybd+SU8oobRiVy2kXa4DlminfIOpj/oqbJPo1qGrMVi13XHPQKPAyYiwUP56u6tFwb5hHCdRFUpHn7oVOIPox6kiaL7ARbS/3YETGc/AwBJH2isTqBYR6qHjAvlSmD8esoN8YAbVuLKjUvnXY/WQdTckw1DEG2m3U= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 3f6f5e64-7c12-4ec1-aa6f-08d4ffd2e41c x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:SN2PR03MB2318; x-ms-traffictypediagnostic: SN2PR03MB2318: x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(10201501046)(100000703101)(100105400095)(3002001)(93006095)(93001095)(6041248)(20161123562025)(20161123560025)(20161123564025)(20161123558100)(201703131423075)(201703061421075)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:SN2PR03MB2318; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:SN2PR03MB2318; x-forefront-prvs: 04362AC73B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(189002)(199003)(13464003)(24454002)(377454003)(101416001)(5660300001)(6246003)(86362001)(68736007)(9686003)(2906002)(305945005)(6306002)(53936002)(99286003)(55016002)(3280700002)(3660700001)(7736002)(966005)(6436002)(6506006)(14454004)(6116002)(110136005)(3846002)(508600001)(8936002)(76176999)(54356999)(102836003)(50986999)(8676002)(25786009)(81156014)(2950100002)(229853002)(66066001)(53546010)(7696004)(105586002)(106356001)(5250100002)(189998001)(33656002)(97736004)(230783001)(74316002)(2900100001)(4326008)(81166006); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB2318; H:SN2PR03MB2350.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Sep 2017 02:54:19.9506 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2318 X-MC-Unique: WeHWB61fPMm66S7jNYUL_w-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [sipcore] Is there interest in draft-johansson-sip-he-connection or not X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 02:54:26 -0000 SSB0aGluayBzdGlsbCBzb21lIGFkZGl0aW9ucy9pbXByb3ZlbWVudHMgYXJlIG5lZWRlZCBidXQg d291bGQgbGlrZSB0byBzZWUgaXQgZmluaXNoZWQuDQoNCkkgc3VwcG9ydCB0aGUgb3Bwb3J0dW5p c3RpYy9zaW1wbGlzdGljIGFwcHJvYWNoIG9mIHRoaXMgZG9jdW1lbnQuDQoNClRoYW5rcywNClRv bGdhDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBzaXBjb3JlIFttYWlsdG86 c2lwY29yZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgR29uemFsbyBTYWxndWVpcm8g KGdzYWxndWVpKQ0KU2VudDogVHVlc2RheSwgU2VwdGVtYmVyIDE5LCAyMDE3IDQ6MjIgUE0NClRv OiBCcmlhbiBSb3NlbiA8YnJAYnJpYW5yb3Nlbi5uZXQ+DQpDYzogU0lQQ09SRSA8c2lwY29yZUBp ZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbc2lwY29yZV0gSXMgdGhlcmUgaW50ZXJlc3QgaW4gZHJh ZnQtam9oYW5zc29uLXNpcC1oZS1jb25uZWN0aW9uIG9yIG5vdA0KDQpJ4oCZZCBsaWtlIHRvIHNl ZSB0aGlzIHdvcmsgZ2V0IGZpbmlzaGVkLCBlc3BlY2lhbGx5IHNpbmNlIHRoZSBidWxrIG9mIHRo ZSB3b3JrIGlzIGNvbXBsZXRlZC4NCg0KLUcNCg0KPiBPbiBTZXAgMTksIDIwMTcsIGF0IDEyOjQx IFBNLCBCcmlhbiBSb3NlbiA8YnJAYnJpYW5yb3Nlbi5uZXQ+IHdyb3RlOg0KPiANCj4gVGhpcyBk b2N1bWVudCBoYXMgYmVlbiBoYW5naW5nIGFyb3VuZCBmb3Igc29tZSB0aW1lIHdpdGggbm8gbW90 aW9uLg0KPiANCj4gQXJlIHdvcmsgZ3JvdXAgbWVtYmVycyBzdGlsbCBpbnRlcmVzdGVkIGluIGl0 LCBvciBzaG91bGQgd2UgYWJhbmRvbiBpdD8NCj4gDQo+IElmIHlvdSB3YW50IGl0LCBwbGVhc2Ug c2F5IHNvLCBhbmQgcmV2aWV3L3Byb3ZpZGUgY29tbWVudHMuDQo+IA0KPiBCcmlhbg0KPiANCj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gc2lwY29y ZSBtYWlsaW5nIGxpc3QNCj4gc2lwY29yZUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCnNpcGNvcmUgbWFpbGluZyBsaXN0DQpzaXBjb3JlQGlldGYu b3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCg== From nobody Tue Sep 19 22:06:44 2017 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 C8C3513303A for ; Tue, 19 Sep 2017 22:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de header.b=A88By9z9; dkim=pass (1024-bit key) header.d=telekom.onmicrosoft.de header.b=c/uxf5X7 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 kyvl3bNCvc8S for ; Tue, 19 Sep 2017 22:06:40 -0700 (PDT) Received: from mailout24.telekom.de (MAILOUT24.telekom.de [80.149.113.254]) (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 5741F132F2C for ; Tue, 19 Sep 2017 22:06:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1505884000; x=1537420000; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=7Ik46MicQPN1zGCJTEA16itO4gHGyJhW4CzgQKgMcmE=; b=A88By9z9R6X7bsJTg82K6ny9F/H4x4mn0u5SNvnl/AHFt/5ZhD2voV0d 9nAqLurnnLPeHAT2ZzVYP5idPeB1lTqS1l2gOn+G4XGzHqU2gE/PejAEz rK+k0iEQUF067pE4Dn3mP3t0WuhwUaLvCXFguUqy/eKQvx7zulV85x0KB dP9H9H9W73nqA3fYuwGEuf2gdBhe19s8GpQTxO04n1cBih/is8rh8bHyu ufc+6mFhHLQ8IEQ8htmp3OIA5kgbl7Hbc59DIRKIqS4yOZZonq899F6fW /kT1jU8e5/rDJYFLrnUXkzHdmzu3HA0w9JdGGwm2EItqBMSQlHu0q2bAg g==; Received: from qde8e4.de.t-internal.com ([10.171.255.33]) by MAILOUT21.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Sep 2017 07:06:36 +0200 X-IronPort-AV: E=Sophos;i="5.42,420,1500933600"; d="scan'208";a="82089428" Received: from he105708.emea1.cds.t-internal.com ([10.169.119.37]) by QDE8PP.de.t-internal.com with ESMTP/TLS/AES256-SHA; 20 Sep 2017 07:06:36 +0200 Received: from HE105704.EMEA1.cds.t-internal.com (10.169.119.21) by HE105708.emea1.cds.t-internal.com (10.169.119.37) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Wed, 20 Sep 2017 07:06:35 +0200 Received: from HE100181.emea1.cds.t-internal.com (10.171.40.15) by HE105704.EMEA1.cds.t-internal.com (10.169.119.21) with Microsoft SMTP Server (TLS) id 15.0.1293.2 via Frontend Transport; Wed, 20 Sep 2017 07:06:35 +0200 Received: from GER01-FRA-obe.outbound.protection.outlook.de (51.4.80.18) by O365mail02.telekom.de (172.30.0.235) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Wed, 20 Sep 2017 07:06:03 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.onmicrosoft.de; s=selector1-telekom-onmicrosoft-de; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=7Ik46MicQPN1zGCJTEA16itO4gHGyJhW4CzgQKgMcmE=; b=c/uxf5X7UOP++H5W3cvGcr5ccx8OepF2sy9ElbfElc9dA+MLvOAQSapYCHUs9il/LLJ0RdUoekxyLanZlnQ/gFgqBfWe1KUDwARyzIP3GCbUHtVpMwDAvT7jurtBQmGp6j1IwF4G7YTLDJnECL5PlyT8VazbEkHqTO67Jzoz8NY= Received: from FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE (10.158.133.13) by FRAPR01MB0482.DEUPRD01.PROD.OUTLOOK.DE (10.158.133.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.11; Wed, 20 Sep 2017 05:06:34 +0000 Received: from FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE ([fe80::d1:57a:9b07:65a0]) by FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE ([fe80::d1:57a:9b07:65a0%15]) with mapi id 15.20.0056.018; Wed, 20 Sep 2017 05:06:33 +0000 From: "Jesske, Roland" To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Call For Adoption draft-holmberg-sipcore-sessiontimer-race Thread-Index: AQHTMUvcl7luVkqjXkueOy99TuicOKK8HEQAgAEdjjA= Date: Wed, 20 Sep 2017 05:06:33 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=R.Jesske@telekom.de; x-originating-ip: [164.19.3.75] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; FRAPR01MB0482; 6:hF/Lwf1PbYXk4WcaHmssjStRTpefdT9vvc03sZqBUFhkARsjAJsRf72xRBmeFjpw4WwWZncumrMWHeotkl3/IybTH4pgpIJ6z8CYm7iPvmdKyq8bLQTtnxWedhWz1xw81qNKbu0Egg2ZRq+c4xFedzH8/WaovqXIWWysmHFHUDpw1H4g+EJFpgOKsB4Nj4TZOdvaG8tP8n3QY4zsvlJbl2Wg+4MD1DgmsNFAlk1A6n2SElZYpOY29vBeMkfdXHR0re8rTMrDKVn1zyH20XdXB3hNm2Cq5alTLUJ8YhYzJuaputFrRiTcM2tAthaAnsI1tSOd6KaKsag1jNVMqbF2Qw==; 5:dJnfUwe/1YggSEWqUGda8asS/gF6i0uBOXWoZdxFlwVOyHvIeBP+gfR2E76pj9HlVeWvZSq7ydzRL2cdTQnqoeq4MeMirJ1hmV51YhFoo6rSHw0gndUjOOBTDICKjA+XH/A/XVJBwKm2ypR5csuQBNsXlJV61j2NSC8Z/AXkvYY=; 24:PkxhnpLm4Qwo0yFPahKsZ48JSaOGYo1AzQhe0whCEQAG6rf8/w/3uHYWvX9E7Jeu+V4kFkNHBJvPsT+kpfkVXoyITx2OosVilkHlX8rsj5g=; 7:B5rP9d/FdMB0351XuXXEhFEktoLAqF9dt8XJfabtIO2mqUY9FzLufiVO8TW42lhREnuSm6IMY5IrIRpxIMTLorb3X4wjhlb3yABIBO52Ug08aBeijw0eEEzHmb6LNS8qxJM9j4mTzAMYA1r4PrgQkCY48bibgi6zCufNdMBeJ+GoNd/x9g5QForj+bvAvxQw1SGEQA1w/fDDCnRWkBQcpudjUKeVwDsujVpLVkMRuBA= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: a2c92089-c071-4519-904d-08d4ffe55cb5 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(300000502095)(300135100095)(22001)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:FRAPR01MB0482; x-ms-traffictypediagnostic: FRAPR01MB0482: x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3002001)(6041248)(20161123562025)(20161123558100)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:FRAPR01MB0482; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:FRAPR01MB0482; x-forefront-prvs: 04362AC73B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(377454003)(189002)(199003)(24454002)(81156014)(81166006)(8676002)(86362001)(55016002)(8936002)(230783001)(6306002)(9686003)(14454004)(966005)(53546010)(72206003)(2906002)(74482002)(3660700001)(3280700002)(478600001)(5250100002)(2501003)(106356001)(2171002)(53936002)(101416001)(105586002)(7736002)(2900100001)(7696004)(2950100002)(305945005)(97736004)(189998001)(66066001)(110136005)(68736007)(316002)(3846002)(102836003)(6116002)(76176999)(54356999)(50986999)(5660300001)(75402003)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:FRAPR01MB0482; H:FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: telekom.de does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Sep 2017 05:06:33.3297 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f X-MS-Exchange-Transport-CrossTenantHeadersStamped: FRAPR01MB0482 X-OriginatorOrg: telekom.de Archived-At: Subject: Re: [sipcore] Call For Adoption draft-holmberg-sipcore-sessiontimer-race X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 05:06:43 -0000 +1 > -----Urspr=FCngliche Nachricht----- > Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von Paul Kyziva= t > Gesendet: Dienstag, 19. September 2017 16:04 > An: sipcore@ietf.org > Betreff: Re: [sipcore] Call For Adoption draft-holmberg-sipcore-sessionti= mer- > race >=20 > +1 >=20 > On 9/19/17 9:33 AM, Brian Rosen wrote: > > We propose to adopt=A0draft-holmberg-sipcore-sessiontimer-race as a > > sipcore document. =A0Please provide comments=A0by October 3. > > > > Brian > > > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Tue Sep 19 22:09:51 2017 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 CC5F3132F2C for ; Tue, 19 Sep 2017 22:09:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.319 X-Spam-Level: X-Spam-Status: No, score=-4.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de header.b=ybrr6nzC; dkim=pass (1024-bit key) header.d=telekom.onmicrosoft.de header.b=IXKUSB4h 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 Pn9NGO5cmnFE for ; Tue, 19 Sep 2017 22:09:47 -0700 (PDT) Received: from mailout13.telekom.de (MAILOUT13.telekom.de [80.149.113.181]) (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 D2C711321A2 for ; Tue, 19 Sep 2017 22:09:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1505884187; x=1537420187; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=6fJS9SAVnxOi6ET1nzv/U/W1ouZjGoh0LNaC/D+X7aI=; b=ybrr6nzCaCsH3oWOPy2RCmeJNe/QxHaENT/UKHPHwtPmw+xljxjz98UZ JIRpwlL4LdL5fjHrHe/hMhl8aAD0IE35Itn7B7gSDClaIL2uP4k1mzaz3 oTTYirv1dxWZ36y9FxwYTk7eb5UWrksYQSSYGe3A2LN4DRZRWqRCT2gry NkZuLM1U4ZJ/AeI+Zgt0dd09Ctfz53R8fHUG/DSjDGrVE3qSj5PzUsovf BzzrkXY9yFVnhBihxyyHm4ifB2I8ojlXsdz8HIYLMYV8tJxMHZkhqNXp2 5bDfMvs8wsmWAl0LKgAq3Jk6MD0AxB/dkM7pZt5FT4PvdDaGO5fAn8HLg Q==; Received: from qde8e4.de.t-internal.com ([10.171.255.33]) by MAILOUT11.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Sep 2017 07:09:45 +0200 X-IronPort-AV: E=Sophos; i="5.42,420,1500933600"; d="scan'208,217"; a="82089953" Received: from he105872.emea1.cds.t-internal.com ([10.169.118.69]) by QDE8PP.de.t-internal.com with ESMTP/TLS/AES256-SHA; 20 Sep 2017 07:09:44 +0200 Received: from HE104854.EMEA1.cds.t-internal.com (10.169.118.17) by HE105872.emea1.cds.t-internal.com (10.169.118.69) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Wed, 20 Sep 2017 07:09:44 +0200 Received: from HE106564.emea1.cds.t-internal.com (10.171.40.16) by HE104854.EMEA1.cds.t-internal.com (10.169.118.17) with Microsoft SMTP Server (TLS) id 15.0.1293.2 via Frontend Transport; Wed, 20 Sep 2017 07:09:44 +0200 Received: from GER01-FRA-obe.outbound.protection.outlook.de (51.4.80.21) by O365mail01.telekom.de (172.30.0.234) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Wed, 20 Sep 2017 07:09:29 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.onmicrosoft.de; s=selector1-telekom-onmicrosoft-de; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=6fJS9SAVnxOi6ET1nzv/U/W1ouZjGoh0LNaC/D+X7aI=; b=IXKUSB4hUlWtBXEDfgR/6+WgEykrnGT9ZR3O6eKFuXvGhx9toGtewRqwOE+4ZKlijO06lEdLveFYTHm/r8O0yyxLngbe/muW6mawiGJ+++c0qRUCLSxbfIT1lcdEO7KO5AIF/QJA/FV1CXVKviMw16DcMgfg5+WiNVWm08yvfb0= Received: from FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE (10.158.133.13) by FRAPR01MB0482.DEUPRD01.PROD.OUTLOOK.DE (10.158.133.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.11; Wed, 20 Sep 2017 05:09:43 +0000 Received: from FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE ([fe80::d1:57a:9b07:65a0]) by FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE ([fe80::d1:57a:9b07:65a0%15]) with mapi id 15.20.0056.018; Wed, 20 Sep 2017 05:09:43 +0000 From: "Jesske, Roland" To: "sipcore@ietf.org" Thread-Topic: draft-winterbottom-sipcore-locparam-01.txt and Liaison Statement to IETF on location source parameter Thread-Index: AdMgpPpaGGJ4RYVmTLCLOQ8COa0QNgRKYIsg Date: Wed, 20 Sep 2017 05:09:43 +0000 Message-ID: References: <87cf2edcef014e268e000ef358cc3c2c@HE105828.emea1.cds.t-internal.com> In-Reply-To: <87cf2edcef014e268e000ef358cc3c2c@HE105828.emea1.cds.t-internal.com> Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=R.Jesske@telekom.de; x-originating-ip: [164.19.3.75] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; FRAPR01MB0482; 6:SG6SQ6NtY8YOhuisDjOfcQeml4wnudPMsVglPXvTpG/sYCXOQEfM/jvb6Yb/glXaQ08f0qNu/yXPgHzpz49N13PWoZm4ihBMEwUR1HUp0wwOhRONxajhANMxETS8uAq+T50vQeIGZk2aBc2uC4zHQJ+U8vdBHuz1tMREeqj5sVoWyP0J2ZWz44i3nXkmghLqSPJlHYiLi19EJv/4Cy1RZZnJfqc9J1VsRw4vSUGvy/wHp9t/kKPXUrRnBbqyxYTlW0Nxp3Jq6KyT/U+R4boAaJUEpmrYUGO0ZjGSIADhpM7e4QGEmPPD55Xnv/nS9Lwc9JMYdvKwvz2mHUmw/AjH3g==; 5:OqTW5/21JwbVj9YmNiWeDBnRwygLPD9ELKicui8WwSDR1Tjj79YN4q/JPVZO1a9eevXm1oKjcUqP/MjQbWhOKxpY55Mtw6Hp0G0aaQBMJJysdTmmMevXY+zvhi/bXvEauoMmbL1u+LEbu5oAQl3BBiVkCwv6m/AJh3L86bGwZAY=; 24:NpJDkdOgre7jmQWJNIHlLZVCKKctdB2xrVLRfzYO/o6Bz850X/fDMHYf9NrrlkSvTaEFqcajPrru/WeZPtfQF8jlXl4j/3aldqkGgh84mDI=; 7:XkF4bwwSu11f01QXyo/cLCmKiONT0u1v3yZqWwHEivVqs56MgP2O6sPvTnkwOwLa0qWFp50cjlA75ofmOfMayKhSuCF88kZrnQd7yG2fqzQDwB0D7JHyCqgL421fiyKCXNdQPcYKAd8/NOsZE8kE5g6ndbTPlFLnsrWCKuFZTsu5WHX6CnrQ++RndwOBrPwyf+ak9AJDAcXthyMUQPq9zMDvWwI9hS589JomyCB3zUk= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 76e697e8-6591-4264-d57d-08d4ffe5ce06 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(300000502095)(300135100095)(22001)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:FRAPR01MB0482; x-ms-traffictypediagnostic: FRAPR01MB0482: x-exchange-antispam-report-test: UriScan:(120809045254105)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3002001)(6041248)(20161123562025)(20161123558100)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:FRAPR01MB0482; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:FRAPR01MB0482; x-forefront-prvs: 04362AC73B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(189002)(199003)(81156014)(81166006)(1730700003)(8676002)(5640700003)(86362001)(345774005)(55016002)(8936002)(230783001)(236005)(6306002)(54896002)(9686003)(14454004)(966005)(413944005)(606006)(72206003)(2906002)(74482002)(3660700001)(3280700002)(478600001)(5250100002)(2501003)(106356001)(2351001)(53936002)(101416001)(105586002)(7736002)(2900100001)(7696004)(2950100002)(6916009)(5630700001)(97736004)(189998001)(66066001)(68736007)(316002)(3846002)(102836003)(790700001)(6116002)(76176999)(54356999)(50986999)(5660300001)(75402003)(33656002)(19627235001); DIR:OUT; SFP:1101; SCL:1; SRVR:FRAPR01MB0482; H:FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: telekom.de does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_FRAPR01MB04835E32A47072E2DFD00673F9610FRAPR01MB0483DEUP_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Sep 2017 05:09:43.3824 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f X-MS-Exchange-Transport-CrossTenantHeadersStamped: FRAPR01MB0482 X-OriginatorOrg: telekom.de Archived-At: Subject: Re: [sipcore] draft-winterbottom-sipcore-locparam-01.txt and Liaison Statement to IETF on location source parameter X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 05:09:50 -0000 --_000_FRAPR01MB04835E32A47072E2DFD00673F9610FRAPR01MB0483DEUP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, since I did not get any comments on our draft it look for me that people ar= e happy with the content. So I would like to ask the group for adoption of this draft. Best Regards Roland Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von Jesske, Rolan= d Gesendet: Dienstag, 29. August 2017 10:59 An: sipcore@ietf.org Betreff: [sipcore] draft-winterbottom-sipcore-locparam-01.txt and Liaison S= tatement to IETF on location source parameter Dear all, since I have uploaded the latest draft on draft-winterbottom-sipcore-locpar= am-01.txt and the last clarification on questions were given on 23. May I d= id not get any further comment. With a reference to this draft a Liaison from ETSI ( https://datatracker.ie= tf.org/liaison/1527/ ) is waiting for action. The liaison from ETSI is asking on the progress of the draft for their solu= tion on Emergency Call due to the Project of the European Union Mandate: M= 493. My question is, since we have no open questions, if we can now progress the= draft. Thank you for consideration. Best Regards Roland --_000_FRAPR01MB04835E32A47072E2DFD00673F9610FRAPR01MB0483DEUP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

since I did not get any comment= s on our draft it look for me that people are happy with the content.<= /o:p>

 

So I would like to ask the grou= p for adoption of this draft.

 

Best Regards<= /p>

 

Roland

 

Von: sipcore [mailto:sipcore-boun= ces@ietf.org] Im Auftrag von Jesske, Roland
Gesendet: Dienstag, 29. August 2017 10:59
An: sipcore@ietf.org
Betreff: [sipcore] draft-winterbottom-sipcore-locparam-01.txt and Li= aison Statement to IETF on location source parameter

 

Dear all,

since I have uploaded the lates= t draft on draft-winterbottom-sipcore-locparam-01.txt and the last clarific= ation on questions were given on 23. May I did not get any further comment.= 

 

With a reference to this dr=
aft a Liaison from ETSI ( h=
ttps://datatracker.ietf.org/liaison/1527/ ) is waiting for action.

 

The liaison from ETSI is as=
king on the progress of the draft for their solution on Emergency Call due =
to the Project of  the European Union Mandate: M493.=



My question is, since we ha=
ve no open questions, if we can now progress the draft. <=
/pre>

 

Thank you for consideration=
.


 

Best Regards


 

Roland 

 

 

 

 

 

 

 
--_000_FRAPR01MB04835E32A47072E2DFD00673F9610FRAPR01MB0483DEUP_-- From nobody Tue Sep 19 22:24:58 2017 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 8175D13301F for ; Tue, 19 Sep 2017 22:24:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de header.b=g4X3ntVW; dkim=pass (1024-bit key) header.d=telekom.onmicrosoft.de header.b=JPuiJlcP 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 uTecT6KBEo99 for ; Tue, 19 Sep 2017 22:24:55 -0700 (PDT) Received: from MAILOUT21.telekom.de (MAILOUT21.telekom.de [80.149.113.251]) (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 3D543132F2C for ; Tue, 19 Sep 2017 22:24:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1505885095; x=1537421095; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=3icyCUIpEXAVg0ijE2CXA8hdFFVWD0sZlwqD6NoyZhI=; b=g4X3ntVWj1UgIUcxyQ/E1UIX7ENxP5PCxQ0ovgaj4ibEq5J7BabL7PTR bljJpGeNHU9BJfqQP0eA33oCuMkYT5kJKgyjSt+VpFGOHpM3Ec1/2Z1Hb Z+xuiCf9OLZXdjGI8FSf/+0Uua+OHznq4+nBmw+ZqWed9sOrgkkDzhcTD rJypGInL3IiGjUROaRU8/Dqayw6Z+WNIGxg3qFWJ6QtnKJutFojF2SEXR 7IQrTJUM0FjWUp1TIhgEjxHja53rQ/yz9vPP8em7/J4gKxmp/zSdQu81Y gwMUPni4F1dtx1oAto63xFSGf3O5eY9mujwDfnqD4IBmYcNE5TPlpwJjh Q==; Received: from qde8e4.de.t-internal.com ([10.171.255.33]) by MAILOUT21.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Sep 2017 07:24:53 +0200 X-IronPort-AV: E=Sophos;i="5.42,420,1500933600"; d="scan'208";a="82094694" Received: from he105698.emea1.cds.t-internal.com ([10.169.119.27]) by QDE8PP.de.t-internal.com with ESMTP/TLS/AES256-SHA; 20 Sep 2017 07:24:53 +0200 Received: from HE105660.EMEA1.cds.t-internal.com (10.169.119.56) by HE105698.emea1.cds.t-internal.com (10.169.119.27) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Wed, 20 Sep 2017 07:24:53 +0200 Received: from HE100181.emea1.cds.t-internal.com (10.171.40.15) by HE105660.EMEA1.cds.t-internal.com (10.169.119.56) with Microsoft SMTP Server (TLS) id 15.0.1293.2 via Frontend Transport; Wed, 20 Sep 2017 07:24:53 +0200 Received: from GER01-LEJ-obe.outbound.protection.outlook.de (51.5.80.17) by O365mail02.telekom.de (172.30.0.235) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Wed, 20 Sep 2017 07:24:20 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.onmicrosoft.de; s=selector1-telekom-onmicrosoft-de; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=3icyCUIpEXAVg0ijE2CXA8hdFFVWD0sZlwqD6NoyZhI=; b=JPuiJlcP2DqqknbBroI7O1MMYRZuMb4qJ/lsgROBXzINvjvWyCoQKaMpil6w5wqV6RCx9HoF0/FDLTelUXoxHTHWJ9+RsfJ5e7ocF1rESC8l+q6++n1v63Y6AcJkgm6FGDzDP/cjmWkbvTi2tEBJiUTJjLQpmlw3M+Z/lrVldOw= Received: from FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE (10.158.133.13) by FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE (10.158.133.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.11; Wed, 20 Sep 2017 05:24:49 +0000 Received: from FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE ([fe80::d1:57a:9b07:65a0]) by FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE ([fe80::d1:57a:9b07:65a0%15]) with mapi id 15.20.0056.018; Wed, 20 Sep 2017 05:24:49 +0000 From: "Jesske, Roland" To: "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-reason-q850-loc-00.txt Thread-Index: AdMxz/gSHwns9Rd+Q2ur3wDOZdznMg== Date: Wed, 20 Sep 2017 05:24:49 +0000 Message-ID: Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=R.Jesske@telekom.de; x-originating-ip: [164.19.3.75] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; FRAPR01MB0483; 6:leuij4mc8PlDKB91fJerML+zAOqnh7iCckU08/ABo24sBmiOpJOc9iZCC2BfmUjutdTCjaHYlk1TxPU7e3jbGbpjo0yBltKd/qdj9goMk/PKPn4GYTNqJM8z+79dJvz1fCf3R/Wsth6ZXL2pMURdxXoTrpBHPG080g29gJc8I0sxCkyD1bytqOLQo8WzPUm9sDUBGop9qb41H3egIUDW5Ilj3wVffX1hERri/g5N40jWLN+g0W6mhefLaMPNqVqJtCenZXTybmzRgp9vZ4W3qdmoiP8E2r2OmABlXhx/K2DK+BkiyiXwaBYzrdp9xDynY3/F9HzvJw1QV5C4/aCwFw==; 5:rphL6Salfaa1RlJgOyKzcXU+fHSStdHM8O8RnT6LYJ5L5ureYJ0C/4lLEyHpRRZhktrKKlk4eaqkRjKeE8nK4TY5ZYZ0/doF8GVTtaNjuabbM2ECP7S92nZvGLRn2mdV99denCfOdZWvA9rw3IaiDNnVQ9YljsG5l+wPsVT79lw=; 24:9dn05JsIpE19kRScSXxa8CMNhjXVfowEJRdl6nvXbxDMQa0U7bhl32ADg+yTB2XvN4DsVzymbWQOlkqG4mFz2bzfCSrF9VhGTNQCpkOQV4A=; 7:LUYS47k/tBTpoeNsJqH3lummR43dPoYITuBSUWn5P43s8fknBUIQNI7kEcWF5Ok69T19V9L9LTPvTdY4aoVPTzsCOvTH0NBxvAHaNvUSsjbOAfFCIqH9wP6Fo/e5FdyheGdY0Y1PCnv9N0wDwQmToIuZaqiqZsIbZz9n7ntzQJc3zJ7fzVkZ3CwacfZ5clE6sMbORYbRKOCqLRN0raq5ZLGjFnPXilHLhOnS8vE6Wiw= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: ed86acb5-5f40-43c2-bd59-08d4ffe7ea22 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:FRAPR01MB0483; x-ms-traffictypediagnostic: FRAPR01MB0483: x-exchange-antispam-report-test: UriScan:(120809045254105); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(3002001)(6041248)(20161123562025)(20161123564025)(20161123558100)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:FRAPR01MB0483; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:FRAPR01MB0483; x-forefront-prvs: 04362AC73B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(346002)(377424004)(189002)(199003)(57704003)(97736004)(316002)(106356001)(5660300001)(3280700002)(4326008)(5640700003)(230783001)(66066001)(2351001)(101416001)(105586002)(74482002)(3660700001)(9686003)(55016002)(2900100001)(54906003)(6306002)(189998001)(5250100002)(53936002)(68736007)(2501003)(102836003)(6116002)(3846002)(72206003)(2906002)(1730700003)(6916009)(478600001)(81156014)(7736002)(7696004)(50986999)(81166006)(75402003)(966005)(413944005)(8936002)(33656002)(305945005)(8676002)(86362001)(14454004)(54356999); DIR:OUT; SFP:1101; SCL:1; SRVR:FRAPR01MB0483; H:FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: telekom.de does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Sep 2017 05:24:49.5818 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f X-MS-Exchange-Transport-CrossTenantHeadersStamped: FRAPR01MB0483 X-OriginatorOrg: telekom.de Archived-At: Subject: [sipcore] I-D Action: draft-ietf-sipcore-reason-q850-loc-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 05:24:57 -0000 Dear all, since the draft was published there were no more comments on the draft. My opinion is that the draft is ready for further proceeding. So I would like to ask if we could proceed with a WGLC. Or do we need any additional discussion? Thank you and Best Regards Roland > -----Urspr=FCngliche Nachricht----- > Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von internet- > drafts@ietf.org > Gesendet: Dienstag, 16. Mai 2017 19:10 > An: i-d-announce@ietf.org > Cc: sipcore@ietf.org > Betreff: [sipcore] I-D Action: draft-ietf-sipcore-reason-q850-loc-00.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Session Initiation Protocol Core of the = IETF. >=20 > Title : ISUP Cause Location Parameter for the SIP Reaso= n Header > Field > Author : Roland Jesske > Filename : draft-ietf-sipcore-reason-q850-loc-00.txt > Pages : 5 > Date : 2017-05-16 >=20 > Abstract: > The SIP Reason header field is defined for carrying ISUP cause values > as well as SIP response codes. Some services in SIP networks may > need to know the ISUP location where the call was released in the > PSTN network to correctly interpret the reason of release. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sipcore-reason-q850-loc/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-sipcore-reason-q850-loc-00 > https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-reason-q850-loc-= 00 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Tue Sep 19 23:59:58 2017 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 44E28133059 for ; Tue, 19 Sep 2017 23:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=proximus.com header.b=W1JtGq2O; dkim=pass (1024-bit key) header.d=proximuscorp.onmicrosoft.com header.b=VBzN1ab9 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 n8J_Rlcp1Vfh for ; Tue, 19 Sep 2017 23:59:52 -0700 (PDT) Received: from mx16.belgacom.be (mx16.belgacom.be [195.13.15.236]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E71D21331F6 for ; Tue, 19 Sep 2017 23:59:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=proximus.com; i=@proximus.com; q=dns/txt; s=dkim; t=1505890792; x=1537426792; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=Ae86JE8hwYIb4kKtHc5EtdQ8CuO+Ne3KSDWyN+e0p4E=; b=W1JtGq2OKC2G3uXhKOlxRGEzc7nBNUnkMZ5Z2g3Ix7O4eltfDrg8rURt kr2TGbG0QWxIk6TNzp+/aQbdyjlm5Fig9bACFbFOb3hak34TZQBRDLgn7 uqCJPOzB/icWz//LYXq63A8oYUOgwLJ3DNSGpL2RDhO+isul5NcB4m9SU Q=; X-IronPort-AV: E=Sophos; i="5.42,420,1500933600"; d="scan'208,217"; a="41232743" Received: from a07585.bgc.net ([10.121.80.39]) by mx16.belgacom.be with ESMTP; 20 Sep 2017 08:59:49 +0200 X-TM-IMSS-Message-ID: <02c336c00000c256@proximus.com> Received: from A04026.BGC.NET ([10.121.135.23]) by proximus.com ([10.121.80.39]) with ESMTP (TREND IMSS SMTP Service 7.5) id 02c336c00000c256 ; Wed, 20 Sep 2017 08:59:48 +0200 Received: from A07614.BGC.NET (10.120.135.4) by A04026.BGC.NET (10.121.135.23) with Microsoft SMTP Server (TLS) id 14.3.339.0; Wed, 20 Sep 2017 08:59:48 +0200 Received: from A07638.BGC.NET (10.121.80.46) by A07614.BGC.NET (10.120.135.4) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.32; Wed, 20 Sep 2017 08:59:47 +0200 Received: from A07622.bgc.net (10.26.29.230) by A07638.BGC.NET (10.121.80.46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.32 via Frontend Transport; Wed, 20 Sep 2017 08:59:47 +0200 Received: from EUR02-VE1-obe.outbound.protection.outlook.com (10.26.31.158) by outlook.proximus.com (10.26.31.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.669.32; Wed, 20 Sep 2017 08:59:46 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ProximusCorp.onmicrosoft.com; s=selector1-proximus-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=GDco3ozB7VVp8KmeMXUHB63Z/FXWVZlKTSpkmztl4e4=; b=VBzN1ab9iGQSxdVSvD4gZH3rqNnrfaKxA4b/VV+I7YsmtIMWfSWV4yln0QiOQhCE2JG3+2OM0lTGFpw+TXnHU7JtbvZinl44fAMuzSa2TVwso29XWzfPX6zYCjbLLkYY0B4+0tgj4bS59K/5vuPOnJiqhVgpkKZnUE2rOf89Ghw= Received: from DB6PR0801MB1365.eurprd08.prod.outlook.com (10.168.11.141) by DB6PR0801MB1271.eurprd08.prod.outlook.com (10.168.11.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.11; Wed, 20 Sep 2017 06:59:45 +0000 Received: from DB6PR0801MB1365.eurprd08.prod.outlook.com ([fe80::f540:9bcd:71c4:ec01]) by DB6PR0801MB1365.eurprd08.prod.outlook.com ([fe80::f540:9bcd:71c4:ec01%14]) with mapi id 15.20.0056.018; Wed, 20 Sep 2017 06:59:44 +0000 From: "VAN GEEL Jan (SPC/CSP)" To: "sipcore@ietf.org" Thread-Topic: [sipcore] Call For Adoption draft-holmberg-sipcore-sessiontimer-race Thread-Index: AQHTMUvrrBJuSjB0Qke13Ft7LREMRaK9WV8Q Date: Wed, 20 Sep 2017 06:59:44 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=jan.van.geel@proximus.com; x-originating-ip: [195.238.28.16] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB6PR0801MB1271; 6:QsI2MjOl/wWqRk3vW1KJm+HBsbRjPHh3wMFFAtWB0da/eeZatDmx0P2HAoFkXy8FBoH9f0ogIwXEtOvmqdrrgM2yD3MUNhzGffDYj6fwlu1nHuOJgX8QlIbA5sc4xITcYU7qp1rKvl1Tvn3R21Hm0+6dGzH3c88ebBimhhQBh/LbvGNEASl3JBG3DtKQCjCE4Opn3GFwOLDRPTsBF1EqilFs7M322AlC0DEDKHUcQxF/cuCO1lz/Otb18PLYPh8akACCRq6xIItmH2l59eRhAPslD7gqTms9/g1KRNFlAkbu23tZqNS9imNT24mMwuoj65iMSf6uFDYrWqtnCL0mog==; 5:xkFt46SBEZp8eEvD2qYnqiXz+iF0Rs07ogOlhRTQPQN+9Z3t+6uAEZKrligS+DPOTDQCQPZg8dMGt8WFcTzXFmAqArbiS9CQdOvjI6INweWQZ0v8zNgZC61vo4p+jdPYljEPzW01ito62Uw4zs2FLqgxOig9whLIvAsATReR1r8=; 24:ujjhChwtyeEqtE0VniNloiZV0/+2LPS/PuLjCUWJX2VC4eyfP7Ws2Ic2gJepmTagcsh9f8NartBHiSQ1U5Il4kLlHqSbXsFZlvui2eOSWE0=; 7:nCO+Tbs0LInQXV6VpliIqB/IO8zzg3Esg56qRstZRP7e/LqZiDUvZBWebIrI0CttPPbRw0ZxHinKQFSX9Dlm/7abDq4Dow8CsdnejuTWL+o1OODM7ZvuYR6cuk7zEgLvHmYWo1wim4Z3mcg2JOuctvGTPO0Vaz/uncr/N621mwAfIeqtOSlpovSqr4H5I+shTX0Jr3qtpq5AY97/p5LQl/vEf+xZdIHzvW4RrHIbNQw= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 5c327b17-20d3-480e-efd1-08d4fff52cbe x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DB6PR0801MB1271; x-ms-traffictypediagnostic: DB6PR0801MB1271: x-exchange-antispam-report-test: UriScan:(174211160506117)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3002001)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123562025)(20161123558100)(20161123560025)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB6PR0801MB1271; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB6PR0801MB1271; x-forefront-prvs: 04362AC73B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(199003)(189002)(74316002)(55016002)(6436002)(53546010)(14454004)(105586002)(6506006)(9686003)(229853002)(2501003)(99286003)(5250100002)(25786009)(2900100001)(66066001)(6916009)(2950100002)(316002)(5630700001)(106356001)(3660700001)(86362001)(97736004)(68736007)(478600001)(189998001)(3280700002)(790700001)(101416001)(8936002)(8676002)(7696004)(102836003)(33656002)(3846002)(6116002)(2351001)(50986999)(6306002)(54896002)(5640700003)(7736002)(2906002)(6246003)(53936002)(966005)(230783001)(1730700003)(81166006)(5660300001)(76176999)(54356999)(81156014); DIR:OUT; SFP:1101; SCL:1; SRVR:DB6PR0801MB1271; H:DB6PR0801MB1365.eurprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB6PR0801MB1365526DDB8F1DC735906C7EB5610DB6PR0801MB1365_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Sep 2017 06:59:44.7144 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: e7ab81b2-1e84-4bf7-9dcb-b6fec01ed138 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0801MB1271 X-OriginatorOrg: proximus.com X-TM-AS-MatchedID: 150567-854212-700755-106660-700693-706484-704416-705441-1 06230-707997-700473-700607-139702-708196-139704-113220-111604-188119-700362 -705718-700345-701827-700264-702497-704425-700732-701306-700450-709859-1880 38-111605-700074-303242-700537-700079-702638-188057-701012-111608-111603-11 1601-148004-148036-148050-20020-41000-42003 X-TM-AS-MML: disable Archived-At: Subject: Re: [sipcore] Call For Adoption draft-holmberg-sipcore-sessiontimer-race X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 06:59:56 -0000 --_000_DB6PR0801MB1365526DDB8F1DC735906C7EB5610DB6PR0801MB1365_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I support this draft From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Tuesday 19 September 2017 15:33 To: sipcore@ietf.org Subject: [sipcore] Call For Adoption draft-holmberg-sipcore-sessiontimer-ra= ce We propose to adopt draft-holmberg-sipcore-sessiontimer-race as a sipcore d= ocument. Please provide comments by October 3. Brian ________________________________ ***** Disclaimer ***** http://www.proximus.be/maildisclaimer --_000_DB6PR0801MB1365526DDB8F1DC735906C7EB5610DB6PR0801MB1365_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I support = this draft

 = ;

From: = sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Brian Rosen
Sent: Tuesday 19 September 2017 15:33
To: sipcore@ietf.org
Subject: [sipcore] Call For Adoption draft-holmberg-sipcore-sessiont= imer-race

 

We propose to adopt draft-holmberg-sipcore-ses= siontimer-race as a sipcore document.  Please provide comments by= October 3.

 

Brian <as co-chair>



***** Disclaimer *****
http://www.proximus.be/maildisclaimer
 --_000_DB6PR0801MB1365526DDB8F1DC735906C7EB5610DB6PR0801MB1365_-- From nobody Wed Sep 20 00:03:58 2017 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 1CFB91286C7 for ; Wed, 20 Sep 2017 00:03:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 I0tX2c0KtKus for ; Wed, 20 Sep 2017 00:03:54 -0700 (PDT) Received: from relais-inet.orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F160133059 for ; Wed, 20 Sep 2017 00:03:54 -0700 (PDT) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id 06EC1A024F for ; Wed, 20 Sep 2017 09:03:53 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.58]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id E2F191A007A for ; Wed, 20 Sep 2017 09:03:52 +0200 (CEST) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM33.corporate.adroot.infra.ftgroup ([fe80::3881:fc15:b4b2:9017%19]) with mapi id 14.03.0361.001; Wed, 20 Sep 2017 09:03:52 +0200 From: To: "sipcore@ietf.org" Thread-Topic: [sipcore] Call For Adoption draft-holmberg-sipcore-sessiontimer-race Thread-Index: AQHTMUvhqDtrYMN+W0CSlni8sp4u4qK8HEMAgAD8EoCAAEI00A== Date: Wed, 20 Sep 2017 07:03:51 +0000 Message-ID: <7822_1505891032_59C212D8_7822_400_1_8B970F90C584EA4E97D5BAAC9172DBB81D602A81@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sipcore] Call For Adoption draft-holmberg-sipcore-sessiontimer-race X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 07:03:56 -0000 +1 > -----Message d'origine----- > De=A0: sipcore [mailto:sipcore-bounces@ietf.org] De la part de Jesske, Ro= land > Envoy=E9=A0: mercredi 20 septembre 2017 07:07 > =C0=A0: Paul Kyzivat; sipcore@ietf.org > Objet=A0: Re: [sipcore] Call For Adoption draft-holmberg-sipcore-sessiont= imer-race >=20 > +1 >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von Paul > > Kyzivat > > Gesendet: Dienstag, 19. September 2017 16:04 > > An: sipcore@ietf.org > > Betreff: Re: [sipcore] Call For Adoption > > draft-holmberg-sipcore-sessiontimer- > > race > > > > +1 > > > > On 9/19/17 9:33 AM, Brian Rosen wrote: > > > We propose to adopt=A0draft-holmberg-sipcore-sessiontimer-race as a > > > sipcore document. =A0Please provide comments=A0by October 3. > > > > > > Brian > > > > > > > > > _______________________________________________ > > > 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 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Wed Sep 20 04:26:19 2017 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 5840A13234B for ; Wed, 20 Sep 2017 04:26:18 -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, RCVD_IN_DNSWL_LOW=-0.7, 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 iGJpL8DEeXkz for ; Wed, 20 Sep 2017 04:26:16 -0700 (PDT) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECD24133049 for ; Wed, 20 Sep 2017 04:26:15 -0700 (PDT) X-Spoof: Received: from xct101cnc.rim.net ([10.65.161.201]) by mhs211cnc.rim.net with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Sep 2017 07:26:08 -0400 Received: from XMB122CNC.rim.net ([fe80::28c6:fa1c:91c6:2e23]) by XCT101CNC.rim.net ([fe80::9c22:d9c:c906:c488%16]) with mapi id 14.03.0319.002; Wed, 20 Sep 2017 07:26:08 -0400 From: Andrew Allen To: "marianne.mohali@orange.com" , "sipcore@ietf.org" Thread-Topic: [sipcore] Call For Adoption draft-holmberg-sipcore-sessiontimer-race Thread-Index: AQHTMUvaIHJwMAdadkurfqolSET41qK8gNkAgAD8EYCAACDGgIAABjEA Date: Wed, 20 Sep 2017 11:26:08 +0000 Message-ID: References: <7822_1505891032_59C212D8_7822_400_1_8B970F90C584EA4E97D5BAAC9172DBB81D602A81@OPEXCLILMA4.corporate.adroot.infra.ftgroup> In-Reply-To: <7822_1505891032_59C212D8_7822_400_1_8B970F90C584EA4E97D5BAAC9172DBB81D602A81@OPEXCLILMA4.corporate.adroot.infra.ftgroup> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.249] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sipcore] Call For Adoption draft-holmberg-sipcore-sessiontimer-race X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 11:26:18 -0000 +1 -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of marianne.mohal= i@orange.com Sent: Wednesday, September 20, 2017 3:04 AM To: sipcore@ietf.org Subject: Re: [sipcore] Call For Adoption draft-holmberg-sipcore-sessiontime= r-race +1 > -----Message d'origine----- > De=A0: sipcore [mailto:sipcore-bounces@ietf.org] De la part de Jesske,=20 > Roland Envoy=E9=A0: mercredi 20 septembre 2017 07:07 =C0=A0: Paul Kyzivat= ;=20 > sipcore@ietf.org Objet=A0: Re: [sipcore] Call For Adoption=20 > draft-holmberg-sipcore-sessiontimer-race >=20 > +1 >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von Paul=20 > > Kyzivat > > Gesendet: Dienstag, 19. September 2017 16:04 > > An: sipcore@ietf.org > > Betreff: Re: [sipcore] Call For Adoption > > draft-holmberg-sipcore-sessiontimer- > > race > > > > +1 > > > > On 9/19/17 9:33 AM, Brian Rosen wrote: > > > We propose to adopt=A0draft-holmberg-sipcore-sessiontimer-race as a=20 > > > sipcore document. =A0Please provide comments=A0by October 3. > > > > > > Brian > > > > > > > > > _______________________________________________ > > > 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 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou = copies sans autorisation. Si vous avez recu ce message par erreur, veuillez= le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used= or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From nobody Wed Sep 20 04:46:26 2017 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 39069132031 for ; Wed, 20 Sep 2017 04:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, 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 IW4PBczzEFiH for ; Wed, 20 Sep 2017 04:46:23 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.161]) (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 28A19132EDA for ; Wed, 20 Sep 2017 04:46:22 -0700 (PDT) Received: from [195.245.230.51] by server-1.bemta-3.messagelabs.com id 01/F5-02048-C0552C95; Wed, 20 Sep 2017 11:46:20 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmleJIrShJLcpLzFFi42LR98zp0eUJPRR p8HcKp8XXH5vYHBg9liz5yRTAGMWamZeUX5HAmrHr+wr2gruSFcdPTGRuYGwQ62Lk4hAS2M4o MffOHhYI5zCjxMMd5xCc00eXQDmbGCXe/P3P3sXIwcEmYC8xY09MFyMnh4iApsTyb1vZQWxhg SCJznXb2SHiwRLHpj5lhrD9JFbs/MUCYrMIqErMaz3JAjKGVyBU4v2cMpCwkEADs8TZSbUgNq eAp8S/+Y/BWhkFZCW+NK4Gs5kFxCVuPZnPBGJLCAhILNlznhnCFpV4+fgfK0SNnsSNqVPYIGx tiWULX4PV8AoISpyc+YQFYpeqxL+Vi5gmMIrOQjJ2FpL2WUjaZyFpX8DIsopRozi1qCy1SNfI Ui+pKDM9oyQ3MTNH19DAWC83tbg4MT01JzGpWC85P3cTIzBi6hkYGHcwNu31O8QoycGkJMpbF XAoUogvKT+lMiOxOCO+qDQntfgQowwHh5IEr3sIUE6wKDU9tSItMwcYuzBpCQ4eJRHecJA0b3 FBYm5xZjpE6hSjLseOm3f/MAmx5OXnpUqJ86qCFAmAFGWU5sGNgKWRS4yyUsK8jAwMDEI8Bal FuZklqPKvGMU5GJWEeZNApvBk5pXAbXoFdAQT0BHZGw6AHFGSiJCSamCsyHSfu8WlZtURrXXy vgvqfuRoT6uVPv+u9ZKR5vVZ7aum/ly4zYrzXIT61TuFwu5LBfyKZZPabm4UNVhz9eNmZqU2Y 4v1jKm/Px46ffbJorbHBnkHn5ryd6oJ+F388T13biz7kyULN85wiI7ws5G+oZZ9c+Mbm9jI7G Mz1/UydOssUZft65JSYinOSDTUYi4qTgQAPDnJ/R4DAAA= X-Env-Sender: Peter.Dawes@vodafone.com X-Msg-Ref: server-9.tower-33.messagelabs.com!1505907960!121051781!8 X-Originating-IP: [47.73.108.140] X-StarScan-Received: X-StarScan-Version: 9.4.45; banners=-,-,- X-VirusChecked: Checked Received: (qmail 510 invoked from network); 20 Sep 2017 11:46:20 -0000 Received: from vgdpm14vr.vodafone.com (HELO voxe03hw.internal.vodafone.com) (47.73.108.140) by server-9.tower-33.messagelabs.com with AES256-SHA256 encrypted SMTP; 20 Sep 2017 11:46:20 -0000 Received: from VOEXH09W.internal.vodafone.com (47.73.211.207) by edge1.vodafone.com (195.232.244.48) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Wed, 20 Sep 2017 13:46:09 +0200 Received: from VOEXC03W.internal.vodafone.com (145.230.101.23) by VOEXH09W.internal.vodafone.com (47.73.211.207) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Wed, 20 Sep 2017 13:46:05 +0200 Received: from VOEXC16W.internal.vodafone.com (145.230.101.18) by VOEXC03W.internal.vodafone.com (145.230.101.23) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 20 Sep 2017 13:46:04 +0200 Received: from VOEXM31W.internal.vodafone.com ([169.254.7.54]) by voexc16w.internal.vodafone.com ([145.230.101.18]) with mapi id 14.03.0361.001; Wed, 20 Sep 2017 13:46:04 +0200 From: "Dawes, Peter, Vodafone Group" To: "sipcore@ietf.org" Thread-Topic: [sipcore] Call For Adoption draft-holmberg-sipcore-sessiontimer-race Thread-Index: AQHTMUvcl7luVkqjXkueOy99TuicOKK8HEQAgAEdjjD///9JgIAASUgAgAAmJ9A= Date: Wed, 20 Sep 2017 11:46:03 +0000 Message-ID: <4A4F136CBD0E0D44AE1EDE36C4CD9D99E16AFB8D@VOEXM31W.internal.vodafone.com> References: <7822_1505891032_59C212D8_7822_400_1_8B970F90C584EA4E97D5BAAC9172DBB81D602A81@OPEXCLILMA4.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sipcore] Call For Adoption draft-holmberg-sipcore-sessiontimer-race X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 11:46:25 -0000 +1 > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Andrew Allen > Sent: 20 September 2017 12:26 > To: marianne.mohali@orange.com; sipcore@ietf.org > Subject: Re: [sipcore] Call For Adoption draft-holmberg-sipcore- > sessiontimer-race >=20 > +1 >=20 > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of > marianne.mohali@orange.com > Sent: Wednesday, September 20, 2017 3:04 AM > To: sipcore@ietf.org > Subject: Re: [sipcore] Call For Adoption draft-holmberg-sipcore- > sessiontimer-race >=20 > +1 >=20 > > -----Message d'origine----- > > De=A0: sipcore [mailto:sipcore-bounces@ietf.org] De la part de Jesske, > > Roland Envoy=E9=A0: mercredi 20 septembre 2017 07:07 =C0=A0: Paul Kyziv= at; > > sipcore@ietf.org Objet=A0: Re: [sipcore] Call For Adoption > > draft-holmberg-sipcore-sessiontimer-race > > > > +1 > > > > > -----Urspr=FCngliche Nachricht----- > > > Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von Paul > > > Kyzivat > > > Gesendet: Dienstag, 19. September 2017 16:04 > > > An: sipcore@ietf.org > > > Betreff: Re: [sipcore] Call For Adoption > > > draft-holmberg-sipcore-sessiontimer- > > > race > > > > > > +1 > > > > > > On 9/19/17 9:33 AM, Brian Rosen wrote: > > > > We propose to adopt=A0draft-holmberg-sipcore-sessiontimer-race as a > > > > sipcore document. =A0Please provide comments=A0by October 3. > > > > > > > > Brian > > > > > > > > > > > > _______________________________________________ > > > > 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 > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore >=20 > __________________________________________________________ > __________________________________________________________ > _____ >=20 > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exp= loites > ou copies sans autorisation. Si vous avez recu ce message par erreur, veu= illez > le signaler a l'expediteur et le detruire ainsi que les pieces jointes. L= es > messages electroniques etant susceptibles d'alteration, Orange decline to= ute > responsabilite si ce message a ete altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged > information that may be protected by law; they should not be distributed, > used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete > this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n > modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Wed Sep 20 07:56:57 2017 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 E0E37124F57 for ; Wed, 20 Sep 2017 07:56:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 H565wd6EfEtK for ; Wed, 20 Sep 2017 07:56:49 -0700 (PDT) Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e:c05::236]) (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 8FC0913207A for ; Wed, 20 Sep 2017 07:56:49 -0700 (PDT) Received: by mail-pg0-x236.google.com with SMTP id u18so1823782pgo.0 for ; Wed, 20 Sep 2017 07:56:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0xACiZ3k6gUO9BRDEeGvQ5MNarx1MAVv8UEsb1SRwrg=; b=cGvXPw2d4jgDrm/Mmxg7gYOIEqWxWqRJH+jyZNJwTSoxbKum91Tr2u/2eZ4RWm4tA6 FBlnzOkx2pHfcBjwPScvlkqlDGIFSvLmVjMHL40Z4d1ntb/SvPK21UdEu1FQ3Vaqzkmu sznCFCRtE2vYtIUpDvnq8Y6e8CDSXSAPeD+LCQesLXj5wUgM6c3JMfgvOTpaKmNB93My nBOSE7e3XNeXv+qCemSoj+x/uf1nPa/FSnyWTvUep/4mUxlEQgWApJcCWPnS+q6yV6/L 7CkYCzFM6ZDSdCQJmDxjbXR8WfQGie/EBHJ2pUHQIf7Z4IqPsAttkGUPFtTk8prwLJeV yoew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0xACiZ3k6gUO9BRDEeGvQ5MNarx1MAVv8UEsb1SRwrg=; b=gJYxVUAzrAAl77oYcOiQftd7/mLft42uQ5vfOT1IuA61Krky+pMhEKQk3L6xgsvYCU YFsRIANPd3/sYnoJJmNDHH+NDVK99laUF2bEWhO9ZqM2fUpAmekAQTTHIKTlIQXQcxYW +uwPmHrpy2V/8sErNqyf9gA0pKq1xDVJOduYlwenXWb6jZ9N1r972BQMIrJeAxairklY DjTS1eri02idSDD3pliWGmCFv5aDtlIh19EmIbpDVj9QuefBWhhHmqNDFzoLTvw2+xw7 fO0lOdJBVhEB9Vld5aSZPLQK29SeGcj91HPxSzhRcQmnBLuaZhkWNkbcNFgWpykQR5QL nTcQ== X-Gm-Message-State: AHPjjUgNpyDY3vemE+KG+dewPNU/4smJzTbHy575HwXxhuT6j9VrHJit 7eiaCE+3WM3yvL3JKUoZ0FyrjBqRqGSyBgBy8lE= X-Google-Smtp-Source: AOwi7QCkah7P/H8s+Q9UU4zV8Uj3dK07RyAEctnklQ+sJjuUlI6lkbWQBol9Zq+ZMyYkqAq+GCdNkIKWyFb/hLrKfZM= X-Received: by 10.101.92.130 with SMTP id a2mr2441004pgt.94.1505919409174; Wed, 20 Sep 2017 07:56:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.137.174 with HTTP; Wed, 20 Sep 2017 07:56:48 -0700 (PDT) In-Reply-To: References: From: Ranjit Avasarala Date: Wed, 20 Sep 2017 09:56:48 -0500 Message-ID: To: Brian Rosen Cc: SIPCORE Content-Type: multipart/alternative; boundary="089e08268da071bee00559a02f23" Archived-At: Subject: Re: [sipcore] Call For Adoption draft-holmberg-sipcore-sessiontimer-race X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 14:56:51 -0000 --089e08268da071bee00559a02f23 Content-Type: text/plain; charset="UTF-8" +1 Regards Ranjit On Tue, Sep 19, 2017 at 8:33 AM, Brian Rosen wrote: > We propose to adopt draft-holmberg-sipcore-sessiontimer-race as a sipcore > document. Please provide comments by October 3. > > Brian > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > --089e08268da071bee00559a02f23 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1

Regards
Ranjit
=

On Tue, Sep 19, 2= 017 at 8:33 AM, Brian Rosen <br@brianrosen.net> wrote:
We propose to adopt=C2=A0draft-holmbe= rg-sipcore-sessiontimer-race as a sipcore document.=C2=A0 Please provi= de comments=C2=A0by October 3.

Brian <as co-chair>

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

--089e08268da071bee00559a02f23-- From nobody Wed Sep 20 11:22:24 2017 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 49366134288 for ; Wed, 20 Sep 2017 11:22:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 YQV5rkYBO8uX for ; Wed, 20 Sep 2017 11:22:21 -0700 (PDT) Received: from alum-mailsec-scanner-7.mit.edu (alum-mailsec-scanner-7.mit.edu [18.7.68.19]) by ietfa.amsl.com (Postfix) with ESMTP id 60BC713304E for ; Wed, 20 Sep 2017 11:22:12 -0700 (PDT) X-AuditID: 12074413-38bff70000007929-81-59c2b1d1fe0e Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 7A.86.31017.1D1B2C95; Wed, 20 Sep 2017 14:22:09 -0400 (EDT) Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id v8KIM80o014492 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Wed, 20 Sep 2017 14:22:09 -0400 To: sipcore@ietf.org References: From: Paul Kyzivat Message-ID: Date: Wed, 20 Sep 2017 14:22:08 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPIsWRmVeSWpSXmKPExsUixO6iqHtp46FIg4adTBZff2xic2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxsfNs1kL1otXzP28lq2B8bJQFyMnh4SAicSJtufsXYxcHEIC O5gkrj9pY4FwfjBJ9G3cygRSJSzgI/G0ZwobiC0iICLxbPo/MFtIIFpib/cfVhCbTUBLYs6h /ywgNq+AvcT5P18YQWwWAVWJa1sfMYPYogJpEv92n2WEqBGUODnzCVg9p0CMRPu5ZWA2s4CZ xLzND5khbHGJW0/mM0HY8hLNW2czT2Dkn4WkfRaSlllIWmYhaVnAyLKKUS4xpzRXNzcxM6c4 NVm3ODkxLy+1SNdcLzezRC81pXQTIyQshXcw7jopd4hRgINRiYc3wOpgpBBrYllxZe4hRkkO JiVR3rkbDkUK8SXlp1RmJBZnxBeV5qQWH2KU4GBWEuGtXwuU401JrKxKLcqHSUlzsCiJ86ot UfcTEkhPLEnNTk0tSC2CycpwcChJ8BaBDBUsSk1PrUjLzClBSDNxcIIM5wEaHg5Sw1tckJhb nJkOkT/FqMvR03PjD5MQS15+XqqUOK8HSJEASFFGaR7cHFg6ecUoDvSWMO9HkCoeYCqCm/QK aAkT0JLsDQdAlpQkIqSkGhg31UuVXPyxecGhHXWzpvu+Xt2X/2rFquu7K62OdVys8BPurmRa x7yF4W/Sp1M9Of273CwN/q7O4+/NucZeY8SZb9DZ/7JtQjDXeefCkkP+z+VqI+6e8xMvufBV 6q/2DBnOzcWexWKG20++CG9VSJ672EPh260MdpnlCjHmGl2eEaemRyVn8iqxFGckGmoxFxUn AgDT4k5lAgMAAA== Archived-At: Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-reason-q850-loc-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 18:22:23 -0000 Roland, On 9/20/17 1:24 AM, Jesske, Roland wrote: > Dear all, > since the draft was published there were no more comments on the draft. > My opinion is that the draft is ready for further proceeding. > So I would like to ask if we could proceed with a WGLC. > > Or do we need any additional discussion? I don't have major problems with this. My only question is about how the location values are defined, and whether other values might be valid now or in the future. I looked at Q.850 and found what seems to be the definition of these values in section 2.2.3. That section associates these labels with specific four-bit values, and marks four other values as "reserved for national use". It also says that "all other values are spare". (There are four of those.) IMO it would make sense to include some provision for specifying those other eight values, or a mechanism for including them in the future. Thanks, Paul > Thank you and Best Regards > > Roland > > >> -----Ursprüngliche Nachricht----- >> Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von internet- >> drafts@ietf.org >> Gesendet: Dienstag, 16. Mai 2017 19:10 >> An: i-d-announce@ietf.org >> Cc: sipcore@ietf.org >> Betreff: [sipcore] I-D Action: draft-ietf-sipcore-reason-q850-loc-00.txt >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the Session Initiation Protocol Core of the IETF. >> >> Title : ISUP Cause Location Parameter for the SIP Reason Header >> Field >> Author : Roland Jesske >> Filename : draft-ietf-sipcore-reason-q850-loc-00.txt >> Pages : 5 >> Date : 2017-05-16 >> >> Abstract: >> The SIP Reason header field is defined for carrying ISUP cause values >> as well as SIP response codes. Some services in SIP networks may >> need to know the ISUP location where the call was released in the >> PSTN network to correctly interpret the reason of release. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-sipcore-reason-q850-loc/ >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-sipcore-reason-q850-loc-00 >> https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-reason-q850-loc-00 >> >> >> 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. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> 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 Wed Sep 20 12:12:10 2017 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 1B7D21342FC for ; Wed, 20 Sep 2017 12:12:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 qvvUnK7DGzfj for ; Wed, 20 Sep 2017 12:12:07 -0700 (PDT) Received: from alum-mailsec-scanner-7.mit.edu (alum-mailsec-scanner-7.mit.edu [18.7.68.19]) by ietfa.amsl.com (Postfix) with ESMTP id E8682134312 for ; Wed, 20 Sep 2017 12:11:47 -0700 (PDT) X-AuditID: 12074413-3a3ff70000007929-b0-59c2bd73b93d Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 47.98.31017.37DB2C95; Wed, 20 Sep 2017 15:11:47 -0400 (EDT) Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id v8KJBjeK017270 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Wed, 20 Sep 2017 15:11:46 -0400 To: sipcore@ietf.org References: <87cf2edcef014e268e000ef358cc3c2c@HE105828.emea1.cds.t-internal.com> From: Paul Kyzivat Message-ID: Date: Wed, 20 Sep 2017 15:11:45 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPIsWRmVeSWpSXmKPExsUixO6iqFu891CkweFVghZff2xic2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxqK5agWH+StebLzD3sD4hbuLkZNDQsBE4seC3+xdjFwcQgI7 mCSuPpvNBuH8YJLYdus/M0iVsECdxOQXZ9lAbBEBEYln0/9BFS1ilJj6/S9YEZuAlsScQ/9Z QGxeAXuJrjtXGUFsFgFVic5vr8DiogJpEv92n2WEqBGUODnzCVicUyBG4vKf+UwgNrOArcSd ubuZIWxxiVtPYOLyEs1bZzNPYOSfhaR9FpKWWUhaZiFpWcDIsopRLjGnNFc3NzEzpzg1Wbc4 OTEvL7VI11wvN7NELzWldBMjJCyFdzDuOil3iFGAg1GJhzfA6mCkEGtiWXFl7iFGSQ4mJVHe zbsORQrxJeWnVGYkFmfEF5XmpBYfYpTgYFYS4X2xDSjHm5JYWZValA+TkuZgURLnVVui7ick kJ5YkpqdmlqQWgSTleHgUJLgXb8HqFGwKDU9tSItM6cEIc3EwQkynAdo+AWQGt7igsTc4sx0 iPwpRl2Onp4bf5iEWPLy81KlxHmf7wYqEgApyijNg5sDSyevGMWB3hLm/QEyigeYiuAmvQJa wgS0JHvDAZAlJYkIKakGxkkJOYVikfHrE97rnjjNYXKg/tNHrzregIK7nlNNrQ7u9901yaKi ouvAfamGuwaec9peM+zlWX0vcKXKa1WLWdz2Si/2VQdMVI1nV9K6x372//crGtFsp1wX/LzI yXnwdsHP3z8bH+4TLl+6R+/4m84tb8+u9Sjqc3osdFXvyOdC9u/reGZ+nq7EUpyRaKjFXFSc CADXZSxYAgMAAA== Archived-At: Subject: Re: [sipcore] draft-winterbottom-sipcore-locparam-01.txt and Liaison Statement to IETF on location source parameter X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 19:12:09 -0000 I'm ok with adopting this. A minor point on the content: The syntax of the new parameter is defined as: location-source = "loc-src=" (host / other-loc-src) other-loc-src = token But there is no definition of 'host'. I think the definition you are intending is actually 'hostname' as defined in 3261. Also, if "Only a fully qualified host name is valid" then what is the point of 'other-loc-src'? So I would suggest: location-source = "loc-src=" hostname hostname = Thanks, Paul On 9/20/17 1:09 AM, Jesske, Roland wrote: > Dear all, > > since I did not get any comments on our draft it look for me that people > are happy with the content. > > So I would like to ask the group for adoption of this draft. > > Best Regards > > Roland > > *Von:*sipcore [mailto:sipcore-bounces@ietf.org] *Im Auftrag von *Jesske, > Roland > *Gesendet:* Dienstag, 29. August 2017 10:59 > *An:* sipcore@ietf.org > *Betreff:* [sipcore] draft-winterbottom-sipcore-locparam-01.txt and > Liaison Statement to IETF on location source parameter > > Dear all, > > since I have uploaded the latest draft on > draft-winterbottom-sipcore-locparam-01.txt and the last clarification on > questions were given on 23. May I did not get any further comment. > > With a reference to this draft a Liaison from ETSI ( > https://datatracker.ietf.org/liaison/1527/ ) is waiting for action. > > The liaison from ETSI is asking on the progress of the draft for their > solution on Emergency Call due to the Project of  the European Union > Mandate: M493. > > My question is, since we have no open questions, if we can now progress > the draft. > > Thank you for consideration. > > Best Regards > > Roland > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Wed Sep 20 13:45:10 2017 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 26D121320D8 for ; Wed, 20 Sep 2017 13:45:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 g66ygFteU3Th for ; Wed, 20 Sep 2017 13:45:07 -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 B40771320B5 for ; Wed, 20 Sep 2017 13:45:06 -0700 (PDT) X-AuditID: c1b4fb3a-617ff700000051a3-00-59c2d3502467 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id A6.8B.20899.053D2C95; Wed, 20 Sep 2017 22:45:04 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.6]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0352.000; Wed, 20 Sep 2017 22:45:03 +0200 From: Christer Holmberg To: "Jesske, Roland" , "sipcore@ietf.org" Thread-Topic: draft-winterbottom-sipcore-locparam-01.txt and Liaison Statement to IETF on location source parameter Thread-Index: AdMgpPpaGGJ4RYVmTLCLOQ8COa0QNgRKYIsgACAyS3A= Date: Wed, 20 Sep 2017 20:45:03 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B562E74F9@ESESSMB109.ericsson.se> References: <87cf2edcef014e268e000ef358cc3c2c@HE105828.emea1.cds.t-internal.com> 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.150] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B562E74F9ESESSMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjkeLIzCtJLcpLzFFi42KZGbE9XDfg8qFIgyk7JC2a7nSxWXz9sYnN gcljyZKfTB5tLxUCmKK4bFJSczLLUov07RK4Mra+28pc8LqyYsX/VtYGxl/ZXYwcHBICJhK3 5qZ2MXJxCAkcYZSY92MGUxcjJ5CziFFixgxJkBo2AQuJ7n/aIGERgWCJz9N3sYPYwgIlEvs/ LWKGiJdK3H51iB3CtpJYufIs2BgWAVWJczdOgsV5BXwlPp37zASxC2j81O9/wZo5BWIkLv+Z D9bAKCAm8f3UGjCbWUBc4tYTiLiEgIDEkj3nmSFsUYmXj/+xQthKEiu2X2KEqM+XaLs3iQli maDEyZlPWCYwCs9CMmoWkrJZSMog4joSC3Z/YoOwtSWWLXzNDGOfOfCYCVl8ASP7KkbR4tTi 4tx0IyO91KLM5OLi/Dy9vNSSTYzA2Dm45bfVDsaDzx0PMQpwMCrx8L6MPRgpxJpYVlyZe4hR goNZSYR3wrlDkUK8KYmVValF+fFFpTmpxYcYpTlYlMR5HfZdiBASSE8sSc1OTS1ILYLJMnFw SjUwsq2LVtxwUJ55wtY7DyvbWzkqbrQ8Zv3Wfds29PPBTxnz/7469Ddlaf4Dh1XXi1y/GFb7 ZHgbKpoIMOcv4a2O+uMhcdVKIC6pJOfPF8OVqSKPtPW/3UxeEKsV0XpxBteVm5/9Zbg2/XJW fP7t79pna184JUwy/VpVL2wrUvr/yaoooQP23wW9lFiKMxINtZiLihMBc7abDpkCAAA= Archived-At: Subject: Re: [sipcore] draft-winterbottom-sipcore-locparam-01.txt and Liaison Statement to IETF on location source parameter X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 20:45:09 -0000 --_000_7594FB04B1934943A5C02806D1A2204B562E74F9ESESSMB109erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I am ok with the draft as such, but I have a few comments, in addition to t= hose given by Paul. First, there are some MUSTs and MUST NOTs, without any clear justification. For example: "Only a fully qualified host name is valid, an IP address MUST NOT be added= by an entity conforming with this specification." "A UE MUST NOT provide a loc-src parameter value." Second, "UE" is not an IETF term. You should use "UA". But still, I think y= ou need to be a little more clear what exactly you mean. Because, a B2BUA a= lso implements a "UA", but I assume you don't want to prevent it from using= the mechanism? Third, related to the first, why do you mandate the value to be a FQDN? Fourth, I am pretty sure the security folks are going to request more text = on the fact that you don't know whether the receiver of the parameter suppo= rts it or not, which means it might not be removed (and, thus, forwarded e.= g., to a non-trusted network). Regards, Christer From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Jesske, Roland Sent: 20 September 2017 07:10 To: sipcore@ietf.org Subject: Re: [sipcore] draft-winterbottom-sipcore-locparam-01.txt and Liais= on Statement to IETF on location source parameter Dear all, since I did not get any comments on our draft it look for me that people ar= e happy with the content. So I would like to ask the group for adoption of this draft. Best Regards Roland Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von Jesske, Rolan= d Gesendet: Dienstag, 29. August 2017 10:59 An: sipcore@ietf.org Betreff: [sipcore] draft-winterbottom-sipcore-locparam-01.txt and Liaison S= tatement to IETF on location source parameter Dear all, since I have uploaded the latest draft on draft-winterbottom-sipcore-locpar= am-01.txt and the last clarification on questions were given on 23. May I d= id not get any further comment. With a reference to this draft a Liaison from ETSI ( https://datatracker.ie= tf.org/liaison/1527/ ) is waiting for action. The liaison from ETSI is asking on the progress of the draft for their solu= tion on Emergency Call due to the Project of the European Union Mandate: M= 493. My question is, since we have no open questions, if we can now progress the= draft. Thank you for consideration. Best Regards Roland --_000_7594FB04B1934943A5C02806D1A2204B562E74F9ESESSMB109erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,<= /p>

 

I am ok with the draft= as such, but I have a few comments, in addition to those given by Paul.

 

First, there are some MUSTs and MUST NOTs, without an= y clear justification.

 

For example:

 

“Only a fully qualified host name is valid, an IP address MUST= NOT be added by an entity conforming with this specification.”<= /o:p>

 

“A UE MUST NOT provide a loc-src parameter value.”<= /o:p>

 

Second, “UE” is not an IETF term. You sho= uld use “UA”. But still, I think you need to be a little more c= lear what exactly you mean. Because, a B2BUA also implements a “UA”, but I assume you don’t want to prevent it from usi= ng the mechanism?

 

Third, related to the first, why do you mandate the v= alue to be a FQDN?

 

Fourth, I am pretty sure the security folks are going= to request more text on the fact that you don’t know whether the rec= eiver of the parameter supports it or not, which means it might not be removed (and, thus, forwarded e.g., to a non-trusted= network).

 

Regards,

 

Christer

 

 

 

 

From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Jesske, Roland
Sent: 20 September 2017 07:10
To: sipcore@ietf.org
Subject: Re: [sipcore] draft-winterbottom-sipcore-locparam-01.txt an= d Liaison Statement to IETF on location source parameter<= /p>

 

Dear all,

since I did not get any comment= s on our draft it look for me that people are happy with the content.<= /o:p>

 

So I would like to ask the grou= p for adoption of this draft.

 

Best Regards<= /p>

 

Roland

 

Von: sipc= ore [mailto:sipcore-bounces@iet= f.org] Im Auftrag von Jesske, Roland
Gesendet: Dienstag, 29. August 2017 10:59
An: sipcore@ietf.org
Betreff: [sipcore] draft-winterbottom-sipcore-locparam-01.txt and Li= aison Statement to IETF on location source parameter

 

Dear all,

since I have uploaded the lates= t draft on draft-winterbottom-sipcore-locparam-01.txt and the last clarific= ation on questions were given on 23. May I did not get any further comment.= 

 

With a reference to this dr=
aft a Liaison from ETSI ( h=
ttps://datatracker.ietf.org/liaison/1527/ ) is waiting for action.

 

The liaison from ETSI is as=
king on the progress of the draft for their solution on Emergency Call due =
to the Project of  the European Union Mandate: M493.=



My question is, since we ha=
ve no open questions, if we can now progress the draft. <=
/pre>

 

Thank you for consideration=
.


 

Best Regards


 

Roland 

 

 

 

 

 

 

 
--_000_7594FB04B1934943A5C02806D1A2204B562E74F9ESESSMB109erics_-- From nobody Thu Sep 21 03:23:33 2017 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 8020013484A for ; Thu, 21 Sep 2017 03:23:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.319 X-Spam-Level: X-Spam-Status: No, score=-4.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de header.b=9EiPvnR6; dkim=pass (1024-bit key) header.d=telekom.onmicrosoft.de header.b=C87cxdHa 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 2NO1LDA1WHJ4 for ; Thu, 21 Sep 2017 03:23:27 -0700 (PDT) Received: from mailout13.telekom.de (MAILOUT13.telekom.de [80.149.113.181]) (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 6C0FD134855 for ; Thu, 21 Sep 2017 03:23:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1505989405; x=1537525405; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=OOUqSzB6WVpPnvV+8ermqYwg3wAB54ePB6FHacvPKDc=; b=9EiPvnR6vA9VSA1fzvi1WZiFXganIDEPf9kzjvt6UFPXO4+PBVNVtdJo awucav212Nsh8I7oMTSw+4rPDz2mSnmLZlliDkMNTAcOyHjImGanq9rFD TQiqAWA5W9TIoIZoMkM61HL1TMS4EzPFteJqwrnpThKNO3Dx+lBCYfK1w EknNh8Pg4WCt2tdhbTEMgpGKV8I5lCY1UZxVfjB6XSe5cnP19IfZPn8Uw yeFw/0bw6iAv43zV9U/nfiXdlWD7W0Q5uZlJFjKaHTZC2/10gyPZ8tuZf gb4oSNPOBqm9MrESyYhvwfUVRsWawkemIuOLicDbQ2Hnl/B4B9KBvqCHs w==; Received: from qdezc2.de.t-internal.com ([10.171.255.37]) by MAILOUT11.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Sep 2017 12:23:23 +0200 X-IronPort-AV: E=Sophos;i="5.42,425,1500933600"; d="scan'208";a="667095389" Received: from he105762.emea1.cds.t-internal.com ([10.169.118.58]) by qde0ps.de.t-internal.com with ESMTP/TLS/AES256-SHA; 21 Sep 2017 12:23:22 +0200 Received: from HE101948.EMEA1.cds.t-internal.com (10.169.118.84) by HE105762.emea1.cds.t-internal.com (10.169.118.58) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Thu, 21 Sep 2017 12:23:22 +0200 Received: from HE106564.emea1.cds.t-internal.com (10.171.40.16) by HE101948.EMEA1.cds.t-internal.com (10.169.118.84) with Microsoft SMTP Server (TLS) id 15.0.1293.2 via Frontend Transport; Thu, 21 Sep 2017 12:23:22 +0200 Received: from GER01-LEJ-obe.outbound.protection.outlook.de (51.5.80.17) by O365mail01.telekom.de (172.30.0.234) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Thu, 21 Sep 2017 12:23:06 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.onmicrosoft.de; s=selector1-telekom-onmicrosoft-de; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=OOUqSzB6WVpPnvV+8ermqYwg3wAB54ePB6FHacvPKDc=; b=C87cxdHa7ahk5q6ZIBI8CcbL/sdF//uKUxbX5IyjxPp78cOaa4iLGqoO211fYTi9e+364xJ6imPMd4mTW21yKu7v/2d7zTTV2+AXkOYY7kDU+b4cTlBC8X2U8pGSoWfQFE9qfJnWn7mEX/KJSyXtcMb/GrXKR751HmzxkC8336M= Received: from FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE (10.158.133.13) by FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE (10.158.133.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.11; Thu, 21 Sep 2017 10:23:21 +0000 Received: from FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE ([fe80::d1:57a:9b07:65a0]) by FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE ([fe80::d1:57a:9b07:65a0%15]) with mapi id 15.20.0056.018; Thu, 21 Sep 2017 10:23:14 +0000 From: "Jesske, Roland" To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-reason-q850-loc-00.txt Thread-Index: AdMxz/gSHwns9Rd+Q2ur3wDOZdznMgAbWY0AAB95gqA= Date: Thu, 21 Sep 2017 10:23:14 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=R.Jesske@telekom.de; x-originating-ip: [164.19.3.236] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; FRAPR01MB0483; 6:F0UHus3Wi3qMhch9PYGTEx0M4vLXmE+FmzjQh9E2UxPTUkvr86gE7cbbyK7B8mt2YuKT/+YRaDoohUzpsruNehwtHI/d4zA5gfvD7VLN61ueUt7a/a2z8oq6cDGYb2I7u1GFw11BO2LUtbo3UEea1+w66aS6hy7GghJ/QFhNNZQEtr+H76/ymeHPY2abdToeV30i+jaHlU3GV5UoUC+ThdHOiLrxV2Vrgu08sN75tyb8bbTY2NhB3+VkrcqJkGJBtl7mkwjTzMaRirQ+5oyyRgBos1+c2GpoGTi+eBlCHqrdRHBdbRXMC4V0XCm2haOVUFnBfq6TFlEssQdCBssXcw==; 5:JIN6LKe0MPE62osCIkApkdrMmSCQlOndgJgnRK6qma//7WDs2gOHqUX+9DWXpFTygoh7oKK/+UEQqx70TqGxfmOxBfYsYvT484dy9sYevD2cTshe+8NJ0BFt7pGxQeBX3SoeZ/dGpsmbNloMkZXzuA==; 24:+uTlSkQ/55CWKIiAG6gpo7v7stSoViwBA1bqVHBzfCOjN7TLUC7B+ZkCxL/0cDbfNQJfUvx4U/JgRanaQ8iH+6+o54oGzifU7BhY157fh5w=; 7:EAbqqt65iXyL7eKHsvttYC3fyRuLpVXnugUMZN6WrKyoOBOY0b0h+leWw9kGq4qXaCj+8cWZY6sC7RTMUhS6ovZMHKqDOP5cCTGJhKYvbas2RtXpQStARVuDSzJtuvUsFyLLu4qe3n5lwm1i/yj+OQWhqAbXIRqeUWEP1XcdqIgYcxbOq7/XcrIuE4/iP1Gmf7uR8aq8c8ZWy2r8FDDKGZM8Z7DDG3T7b5Zqfw5gDLQ= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 56216be0-6667-4fb4-1214-08d500dac4e3 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:FRAPR01MB0483; x-ms-traffictypediagnostic: FRAPR01MB0483: x-exchange-antispam-report-test: UriScan:(120809045254105); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(3002001)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(6041248)(20161123560025)(20161123558100)(20161123564025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:FRAPR01MB0483; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:FRAPR01MB0483; x-forefront-prvs: 04371797A5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(346002)(189002)(76104003)(24454002)(377454003)(199003)(57704003)(377424004)(189998001)(3660700001)(561944003)(2906002)(66066001)(101416001)(5660300001)(106356001)(74482002)(316002)(7736002)(3280700002)(14454004)(72206003)(2950100002)(966005)(50986999)(76176999)(54356999)(305945005)(55016002)(53546010)(86362001)(5250100002)(110136005)(33656002)(478600001)(7696004)(68736007)(345774005)(2171002)(75402003)(2501003)(230783001)(2900100001)(97736004)(105586002)(6306002)(3846002)(81166006)(9686003)(102836003)(81156014)(6116002)(8936002)(8676002)(53936002); DIR:OUT; SFP:1101; SCL:1; SRVR:FRAPR01MB0483; H:FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: telekom.de does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Sep 2017 10:23:14.8098 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f X-MS-Exchange-Transport-CrossTenantHeadersStamped: FRAPR01MB0483 X-OriginatorOrg: telekom.de Archived-At: Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-reason-q850-loc-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Sep 2017 10:23:31 -0000 SGkgUGF1bCwNCnRoYW5rIHlvdSBmb3IgeW91ciBjb21tZW50Lg0KVGhlIGxhc3QgY2hhbmdlIG9m IFEuODUwIHdhcyAxNiBZZWFycyBhZ28gd2l0aGluIElUVS1ULg0KQW5kIHdoZW4gSSByZW1lbWJl ciBjb3JyZWN0bHkgdGhlIGxhc3QgcHJvcG9zYWwgb2YgYWRkaW5nIGxvY2F0aW9ucyB3aXRoaW4g US44NTAgKFVTL0FUVCBwcm9wb3NhbCkgd2FzIGFsc28gYXJvdW5kIDE1IHllYXJzIGFnbyBhbmQg d2FzIG5vdCBhY2NlcHRlZCBieSBJVFUtVC4NCg0KU2luY2Ugbm9ib2R5IHdpbGwgaW52ZXN0IG5v dCBhbnkgbG9uZ2VyIGluIElTVVAgbmV0d29ya3MgSSBzZWUgdGhlIGNoYW5jZSBvZiBhIG5ldyBJ U1VQIHBhcmFtZXRlciBhdCAwJS4NCkJ1dCBpZiBwZW9wbGUgZmVlbCBiZXR0ZXIgSSBjb3VsZCBh ZGQgYW4gdG9rZW4gZm9yIGFkZGluZyBmdXJ0aGVyIHZhbHVlcy4NCg0KU29tZXRoaW5nIGxpa2U6 DQpyZWFzb24tZXh0ZW5zaW9uID0vIGlzdXAtY2F1c2UtbG9jYXRpb24NCiAgIGlzdXAtY2F1c2Ut bG9jYXRpb24gPSAgImxvY2F0aW9uIiBFUVVBTCBzdHJpbmcvdG9rZW4NCg0KVG9rZW4gbWF5IGJl IHVzZWQgYnkgb3BlcmF0b3JzIHVzaW5nIG5hdGlvbmFsIGNvZGluZyBvciBhbiBmdXR1cmUgZXh0 ZW50aW9uIG9mIHRoZSBsb2NhdGlvbiB2YWx1ZSBieSBJVFUtVC4NCg0KV2hhdCBkbyB5b3UgdGhp bmsuDQoNClRoYW5rIHlvdSBhbmQgQmVzdCBSZWdhcmRzDQoNClJvbGFuZCANCg0KPiAtLS0tLVVy c3Byw7xuZ2xpY2hlIE5hY2hyaWNodC0tLS0tDQo+IFZvbjogc2lwY29yZSBbbWFpbHRvOnNpcGNv cmUtYm91bmNlc0BpZXRmLm9yZ10gSW0gQXVmdHJhZyB2b24gUGF1bCBLeXppdmF0DQo+IEdlc2Vu ZGV0OiBNaXR0d29jaCwgMjAuIFNlcHRlbWJlciAyMDE3IDIwOjIyDQo+IEFuOiBzaXBjb3JlQGll dGYub3JnDQo+IEJldHJlZmY6IFJlOiBbc2lwY29yZV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1z aXBjb3JlLXJlYXNvbi1xODUwLWxvYy0wMC50eHQNCj4gDQo+IFJvbGFuZCwNCj4gDQo+IE9uIDkv MjAvMTcgMToyNCBBTSwgSmVzc2tlLCBSb2xhbmQgd3JvdGU6DQo+ID4gRGVhciBhbGwsDQo+ID4g c2luY2UgdGhlIGRyYWZ0IHdhcyBwdWJsaXNoZWQgdGhlcmUgd2VyZSBubyBtb3JlIGNvbW1lbnRz IG9uIHRoZSBkcmFmdC4NCj4gPiBNeSBvcGluaW9uIGlzIHRoYXQgdGhlIGRyYWZ0IGlzIHJlYWR5 IGZvciBmdXJ0aGVyIHByb2NlZWRpbmcuDQo+ID4gU28gSSB3b3VsZCBsaWtlIHRvIGFzayBpZiB3 ZSBjb3VsZCBwcm9jZWVkIHdpdGggYSBXR0xDLg0KPiA+DQo+ID4gT3IgZG8gd2UgbmVlZCBhbnkg YWRkaXRpb25hbCBkaXNjdXNzaW9uPw0KPiANCj4gSSBkb24ndCBoYXZlIG1ham9yIHByb2JsZW1z IHdpdGggdGhpcy4gTXkgb25seSBxdWVzdGlvbiBpcyBhYm91dCBob3cgdGhlDQo+IGxvY2F0aW9u IHZhbHVlcyBhcmUgZGVmaW5lZCwgYW5kIHdoZXRoZXIgb3RoZXIgdmFsdWVzIG1pZ2h0IGJlIHZh bGlkIG5vdyBvcg0KPiBpbiB0aGUgZnV0dXJlLg0KPiANCj4gSSBsb29rZWQgYXQgUS44NTAgYW5k IGZvdW5kIHdoYXQgc2VlbXMgdG8gYmUgdGhlIGRlZmluaXRpb24gb2YgdGhlc2UgdmFsdWVzDQo+ IGluIHNlY3Rpb24gMi4yLjMuIFRoYXQgc2VjdGlvbiBhc3NvY2lhdGVzIHRoZXNlIGxhYmVscyB3 aXRoIHNwZWNpZmljIGZvdXItYml0DQo+IHZhbHVlcywgYW5kIG1hcmtzIGZvdXIgb3RoZXIgdmFs dWVzIGFzICJyZXNlcnZlZCBmb3IgbmF0aW9uYWwgdXNlIi4gSXQgYWxzbw0KPiBzYXlzIHRoYXQg ImFsbCBvdGhlciB2YWx1ZXMgYXJlIHNwYXJlIi4gKFRoZXJlIGFyZSBmb3VyIG9mIHRob3NlLikN Cj4gDQo+IElNTyBpdCB3b3VsZCBtYWtlIHNlbnNlIHRvIGluY2x1ZGUgc29tZSBwcm92aXNpb24g Zm9yIHNwZWNpZnlpbmcgdGhvc2UNCj4gb3RoZXIgZWlnaHQgdmFsdWVzLCBvciBhIG1lY2hhbmlz bSBmb3IgaW5jbHVkaW5nIHRoZW0gaW4gdGhlIGZ1dHVyZS4NCj4gDQo+IAlUaGFua3MsDQo+IAlQ YXVsDQo+IA0KPiA+IFRoYW5rIHlvdSBhbmQgQmVzdCBSZWdhcmRzDQo+ID4NCj4gPiBSb2xhbmQN Cj4gPg0KPiA+DQo+ID4+IC0tLS0tVXJzcHLDvG5nbGljaGUgTmFjaHJpY2h0LS0tLS0NCj4gPj4g Vm9uOiBzaXBjb3JlIFttYWlsdG86c2lwY29yZS1ib3VuY2VzQGlldGYub3JnXSBJbSBBdWZ0cmFn IHZvbg0KPiA+PiBpbnRlcm5ldC0gZHJhZnRzQGlldGYub3JnDQo+ID4+IEdlc2VuZGV0OiBEaWVu c3RhZywgMTYuIE1haSAyMDE3IDE5OjEwDQo+ID4+IEFuOiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmcN Cj4gPj4gQ2M6IHNpcGNvcmVAaWV0Zi5vcmcNCj4gPj4gQmV0cmVmZjogW3NpcGNvcmVdIEktRCBB Y3Rpb246DQo+ID4+IGRyYWZ0LWlldGYtc2lwY29yZS1yZWFzb24tcTg1MC1sb2MtMDAudHh0DQo+ ID4+DQo+ID4+DQo+ID4+IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRo ZSBvbi1saW5lIEludGVybmV0LURyYWZ0cw0KPiBkaXJlY3Rvcmllcy4NCj4gPj4gVGhpcyBkcmFm dCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgU2Vzc2lvbiBJbml0aWF0aW9uIFByb3RvY29sIENvcmUg b2YgdGhlIElFVEYuDQo+ID4+DQo+ID4+ICAgICAgICAgIFRpdGxlICAgICAgICAgICA6IElTVVAg Q2F1c2UgTG9jYXRpb24gUGFyYW1ldGVyIGZvciB0aGUgU0lQIFJlYXNvbiBIZWFkZXINCj4gPj4g RmllbGQNCj4gPj4gICAgICAgICAgQXV0aG9yICAgICAgICAgIDogUm9sYW5kIEplc3NrZQ0KPiA+ PiAJRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1zaXBjb3JlLXJlYXNvbi1xODUwLWxvYy0w MC50eHQNCj4gPj4gCVBhZ2VzICAgICAgICAgICA6IDUNCj4gPj4gCURhdGUgICAgICAgICAgICA6 IDIwMTctMDUtMTYNCj4gPj4NCj4gPj4gQWJzdHJhY3Q6DQo+ID4+ICAgICBUaGUgU0lQIFJlYXNv biBoZWFkZXIgZmllbGQgaXMgZGVmaW5lZCBmb3IgY2FycnlpbmcgSVNVUCBjYXVzZSB2YWx1ZXMN Cj4gPj4gICAgIGFzIHdlbGwgYXMgU0lQIHJlc3BvbnNlIGNvZGVzLiAgU29tZSBzZXJ2aWNlcyBp biBTSVAgbmV0d29ya3MgbWF5DQo+ID4+ICAgICBuZWVkIHRvIGtub3cgdGhlIElTVVAgbG9jYXRp b24gd2hlcmUgdGhlIGNhbGwgd2FzIHJlbGVhc2VkIGluIHRoZQ0KPiA+PiAgICAgUFNUTiBuZXR3 b3JrIHRvIGNvcnJlY3RseSBpbnRlcnByZXQgdGhlIHJlYXNvbiBvZiByZWxlYXNlLg0KPiA+Pg0K PiA+Pg0KPiA+PiBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFm dCBpczoNCj4gPj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1z aXBjb3JlLXJlYXNvbi1xODUwLWxvYy8NCj4gPj4NCj4gPj4gVGhlcmUgYXJlIGFsc28gaHRtbGl6 ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Og0KPiA+PiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi1zaXBjb3JlLXJlYXNvbi1xODUwLWxvYy0wMA0KPiA+PiBodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtc2lwY29yZS1yZWFzb24tcTg1 MC0NCj4gPj4gbG9jLTAwDQo+ID4+DQo+ID4+DQo+ID4+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5 IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mDQo+ID4+IHN1Ym1pc3Np b24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdA0K PiB0b29scy5pZXRmLm9yZy4NCj4gPj4NCj4gPj4gSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2 YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KPiA+PiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50 ZXJuZXQtZHJhZnRzLw0KPiA+Pg0KPiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiA+PiBzaXBjb3JlIG1haWxpbmcgbGlzdA0KPiA+PiBzaXBjb3Jl QGlldGYub3JnDQo+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lw Y29yZQ0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gPiBzaXBjb3JlIG1haWxpbmcgbGlzdA0KPiA+IHNpcGNvcmVAaWV0Zi5vcmcNCj4g PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCj4gPg0KPiAN Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gc2lw Y29yZSBtYWlsaW5nIGxpc3QNCj4gc2lwY29yZUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCg== From nobody Thu Sep 21 08:52:11 2017 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 D4584124F57 for ; Thu, 21 Sep 2017 08:52:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 r6mVSn6CniM5 for ; Thu, 21 Sep 2017 08:52:02 -0700 (PDT) Received: from alum-mailsec-scanner-6.mit.edu (alum-mailsec-scanner-6.mit.edu [18.7.68.18]) by ietfa.amsl.com (Postfix) with ESMTP id 2109813247A for ; Thu, 21 Sep 2017 08:52:02 -0700 (PDT) X-AuditID: 12074412-1fdff7000000748d-d5-59c3e020b440 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 64.62.29837.020E3C95; Thu, 21 Sep 2017 11:52:00 -0400 (EDT) Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id v8LFpxbU012109 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 21 Sep 2017 11:51:59 -0400 To: "Jesske, Roland" , "sipcore@ietf.org" References: From: Paul Kyzivat Message-ID: <12f8d596-49b2-78f0-bf10-832736d10902@alum.mit.edu> Date: Thu, 21 Sep 2017 11:51:58 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBIsWRmVeSWpSXmKPExsUixO6iqKvw4HCkwZ6DkhZNd7rYLL7+2MTm wOSxZMlPJo+2lwoBTFFcNimpOZllqUX6dglcGRu2zGApOKpWcff3F8YGxh75LkZODgkBE4kZ f1czdjFycQgJ7GCS2HLrLhOE85BJ4s+Jz+wgVcICQRJ33kwHquLgEBGIkrhzVhui5jGjxK9z P5lAatgEtCTmHPrPAmLzCthLzPnUBWazCKhKTL73ghHEFhVIk/i3+ywjRI2gxMmZT8BqOAVi JC5Me8AKYjMLmEnM2/yQGcIWl7j1ZD4ThC0v0bx1NvMERv5ZSNpnIWmZhaRlFpKWBYwsqxjl EnNKc3VzEzNzilOTdYuTE/PyUot0zfRyM0v0UlNKNzFCAlVoB+P6k3KHGAU4GJV4eA0OHo4U Yk0sK67MPcQoycGkJMpbeA8oxJeUn1KZkVicEV9UmpNafIhRgoNZSYR3/X2gHG9KYmVValE+ TEqag0VJnPfnYnU/IYH0xJLU7NTUgtQimKwMB4eSBO9KkEbBotT01Iq0zJwShDQTByfIcB6g 4TFgw4sLEnOLM9Mh8qcYdTl6em78YRJiycvPS5US500FuU4ApCijNA9uDizBvGIUB3pLmPcn SBUPMDnBTXoFtIQJaEn2hgMgS0oSEVJSDYzzVA5vv2vnEq+99IPj58wwXYVzVV2B35iP8Ir/ Yg4M3fMw1va78MobXbsu863YpvI82WumQYLY4fVfX0Vov7ey43ac9GzyxDTL7CaL73KbmPd8 mKK+by9Xaeeu0EOzMrOXSh+7fc5Ogklh8ww/lkJdPlHfoOx8trZ2vp0PTvZfu1x/7Msyn2Il luKMREMt5qLiRADUZVqYCwMAAA== Archived-At: Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-reason-q850-loc-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Sep 2017 15:52:09 -0000 On 9/21/17 6:23 AM, Jesske, Roland wrote: > Hi Paul, > thank you for your comment. > The last change of Q.850 was 16 Years ago within ITU-T. > And when I remember correctly the last proposal of adding locations within Q.850 (US/ATT proposal) was also around 15 years ago and was not accepted by ITU-T. > > Since nobody will invest not any longer in ISUP networks I see the chance of a new ISUP parameter at 0%. Yes, I understand. But it is conceivable that the other values (especially the ones for national use) might be in use somewhere. > But if people feel better I could add an token for adding further values. > > Something like: > reason-extension =/ isup-cause-location > isup-cause-location = "location" EQUAL string/token > > Token may be used by operators using national coding or an future extention of the location value by ITU-T. > > What do you think. Instead of that, how about just defining some tokens now for all the other code points. (E.g. NATIONAL-1, NATIONOAL-2, ... , RESERVED-1, RESERVED-2, ... *or* values that correspond directly to the binary coding, such as LOC-12, LOC-13, LOC-14, LOC-15). That way, if interworking comes across one of those it can be mapped bidirectionally to SIP. Thanks, Paul > Thank you and Best Regards > > Roland > >> -----Ursprüngliche Nachricht----- >> Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von Paul Kyzivat >> Gesendet: Mittwoch, 20. September 2017 20:22 >> An: sipcore@ietf.org >> Betreff: Re: [sipcore] I-D Action: draft-ietf-sipcore-reason-q850-loc-00.txt >> >> Roland, >> >> On 9/20/17 1:24 AM, Jesske, Roland wrote: >>> Dear all, >>> since the draft was published there were no more comments on the draft. >>> My opinion is that the draft is ready for further proceeding. >>> So I would like to ask if we could proceed with a WGLC. >>> >>> Or do we need any additional discussion? >> >> I don't have major problems with this. My only question is about how the >> location values are defined, and whether other values might be valid now or >> in the future. >> >> I looked at Q.850 and found what seems to be the definition of these values >> in section 2.2.3. That section associates these labels with specific four-bit >> values, and marks four other values as "reserved for national use". It also >> says that "all other values are spare". (There are four of those.) >> >> IMO it would make sense to include some provision for specifying those >> other eight values, or a mechanism for including them in the future. >> >> Thanks, >> Paul >> >>> Thank you and Best Regards >>> >>> Roland >>> >>> >>>> -----Ursprüngliche Nachricht----- >>>> Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von >>>> internet- drafts@ietf.org >>>> Gesendet: Dienstag, 16. Mai 2017 19:10 >>>> An: i-d-announce@ietf.org >>>> Cc: sipcore@ietf.org >>>> Betreff: [sipcore] I-D Action: >>>> draft-ietf-sipcore-reason-q850-loc-00.txt >>>> >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >>>> This draft is a work item of the Session Initiation Protocol Core of the IETF. >>>> >>>> Title : ISUP Cause Location Parameter for the SIP Reason Header >>>> Field >>>> Author : Roland Jesske >>>> Filename : draft-ietf-sipcore-reason-q850-loc-00.txt >>>> Pages : 5 >>>> Date : 2017-05-16 >>>> >>>> Abstract: >>>> The SIP Reason header field is defined for carrying ISUP cause values >>>> as well as SIP response codes. Some services in SIP networks may >>>> need to know the ISUP location where the call was released in the >>>> PSTN network to correctly interpret the reason of release. >>>> >>>> >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-sipcore-reason-q850-loc/ >>>> >>>> There are also htmlized versions available at: >>>> https://tools.ietf.org/html/draft-ietf-sipcore-reason-q850-loc-00 >>>> https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-reason-q850- >>>> loc-00 >>>> >>>> >>>> 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. >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> _______________________________________________ >>>> 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 >>> >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore From nobody Thu Sep 21 13:05:12 2017 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 B2ECE133063 for ; Thu, 21 Sep 2017 13:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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=comcast.net 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 oh7VOn6_aBAv for ; Thu, 21 Sep 2017 13:05:09 -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 0A475133065 for ; Thu, 21 Sep 2017 13:05:07 -0700 (PDT) Received: from resomta-ch2-18v.sys.comcast.net ([69.252.207.114]) by resqmta-ch2-04v.sys.comcast.net with ESMTP id v7h5dd7Z6w6EOv7idd7OiU; Thu, 21 Sep 2017 20:05:07 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1506024307; bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=; h=Received:Received:To:From:Subject:Message-ID:Date:MIME-Version: Content-Type; b=G4RjHy4zNmqfbdHp4zlWgMzKl3a7xC8MJIPD4iy8EVGkmzrp/Ym3aciGj9FEF/Zxm +Yh1N4lwRUt91E3BpCdwFW+xl1/nfz5mF0UsTjVm8t5AJBjVeX+HgJVxtkEUQkhsZI nXVd+MPyYXWERUALTZFg1CzZk2AVOGbTSNmX1Aw5+AB0HbnIzeOmhhyHItfmwePI5E CSkLmTeYVbCjHpZ9zwsApSC+UuBtr4gINlA6gXXYEMeKxU/mYCFGmJDz3hSZS3gRQa 5NxRxR7pbFkWqGOKW9W3ty168mPWiPmchUMk8SFgjZ2Q4x5mK8Jlmx9rjM5qrp9z5k p3YgRPa0hPoDg== Received: from PaulKyzivatsMBP.localdomain ([24.62.227.142]) by resomta-ch2-18v.sys.comcast.net with SMTP id v7icdM2JkxB6Tv7icdesUS; Thu, 21 Sep 2017 20:05:07 +0000 To: SIPCORE From: Paul Kyzivat Message-ID: <562b2a68-56ef-f55a-d518-57d41dc12eae@comcast.net> Date: Thu, 21 Sep 2017 16:05:05 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfK45rdi4mfGtMDKKURG+XEk5TYUETBI9oJmRYC0YUca35ywQSTUlB0YiabDsXm+eXB+Je4lfpumSLAaC99JfGFaRIRpy2/HVya0p5t9JT4Mxy36fJR2X AqswjxXGCm4tuGFs+AFjMDRs0gtqXKFEN0wLzkGZEd6yZJ7l7tf3bHc3UKiQF5MnYOhSkAKbYWSzvA== Archived-At: Subject: [sipcore] test - please ignore X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Sep 2017 20:05:11 -0000 From nobody Thu Sep 21 17:51:55 2017 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 A79521323F7 for ; Thu, 21 Sep 2017 17:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 yDXDK-eNtfOL for ; Thu, 21 Sep 2017 17:51:52 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (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 05285132331 for ; Thu, 21 Sep 2017 17:51:52 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id d16so14728398ioj.3 for ; Thu, 21 Sep 2017 17:51:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PP5Q0utQKXaf/bS231SF/rSmfJ/oU+ThUbyrKBNP38M=; b=ZqejN0/95yruk25WEjnn+u/8rL5Gy+JFYWInNVRkmaIx2CBk6pLlpfVRhocRoskPrC CjEGFx3339il49r49vKEIjkAWH0fLZXxfl5A+aIQ9XUDZDcqNrAdKyF4NzWG8wPxruJl FbDDZAq1GyI9Eq9qTeHkNjaL4wBTXiAsZoVAgjxYZsreo3wExBa+piICRKtpII5ua1eD 4BNz9VCadr/yOrFK9BW3xIoPQYtzSJ+50eJI2GHwSxcWUGONU0Xdqdp7lz8nRZ+jl7l6 HgBsfwtrSVjYF9Nq7AAy1Lb6DvgNWhBTG5ytjFEEymflubJs5viETa1G1iBCu6hA19oN ozBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PP5Q0utQKXaf/bS231SF/rSmfJ/oU+ThUbyrKBNP38M=; b=cJjtP1O60wCzm2wRo4fR1n7rudGLNeFsP8gBQMBCJaRlgmeKF3AnFtVNIaBaezKNup HwTCx2kzW3VIIB0PTMVfei7D5zojTeTcIRE8BXleo2tMdVIb84vNpqsD0R1yOALQ3zcD HF8EYI2+MCsNgiZ1lqBIQPH8jpyoXTMNwdO33KpM4CnrJDS717UBx+iMeiiPpw+QKQ+B Yh0gBOVyl3mclCorOWSlOfi+625+vgtj9du6xjf+51tTgecsgTztc/Nj/nlGoZoa2etQ GETXuvN1CaG6O72/XrGy0/giHB4UL6TBlFKKdq0RbiQgDfBYswALyRaIrev1Gm69LJOU mR2w== X-Gm-Message-State: AHPjjUjBMJBOqdCv+oEtdZmp5PemEdAbJrqeq3CEzF/k2GyEkgo4Uvyn 8qJDL43csbO+IBp11ibU9od+4isyLkd9AQFAASo= X-Google-Smtp-Source: AOwi7QC89bjEkGxgNDnUxfAzufhjVS90YTm3YN7I6X24fhvuhnGQeVffUOC1/cpdFUuSg1Jddam0wTGHXc4lvTo3p8s= X-Received: by 10.107.140.13 with SMTP id o13mr5103889iod.216.1506041511349; Thu, 21 Sep 2017 17:51:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.2.86.90 with HTTP; Thu, 21 Sep 2017 17:51:50 -0700 (PDT) In-Reply-To: References: From: Alberto Llamas Date: Fri, 22 Sep 2017 00:51:50 +0000 Message-ID: To: Brian Rosen Cc: sipcore@ietf.org Content-Type: multipart/alternative; boundary="94eb2c0561024d12800559bc9d5c" Archived-At: Subject: Re: [sipcore] Call For Adoption draft-holmberg-sipcore-sessiontimer-race X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Sep 2017 00:51:54 -0000 --94eb2c0561024d12800559bc9d5c Content-Type: text/plain; charset="UTF-8" +1 On Tue, Sep 19, 2017 at 1:33 PM, Brian Rosen wrote: > We propose to adopt draft-holmberg-sipcore-sessiontimer-race as a sipcore > document. Please provide comments by October 3. > > Brian > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > -- Alberto Llamas Telecommunications Engineer dCAP | KPAC | SSCA *"Internet is all about share"* --94eb2c0561024d12800559bc9d5c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1

On Tue, Sep 19, 2017 at 1:33 PM, Brian Rosen <= br@brianrosen.net> wrote:
We propose t= o adopt=C2=A0draft-holmberg-sipcore-sessiontimer-race as a sipcore doc= ument.=C2=A0 Please provide comments=C2=A0by October 3.

Brian <as co-chair>

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



--
=
Alberto Llamas
Telecommunications = Engineer
dCAP | KPAC | SSCA

=

"Internet is all about share"
<= /div>
--94eb2c0561024d12800559bc9d5c-- From nobody Thu Sep 21 22:30:32 2017 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 BC629134212 for ; Thu, 21 Sep 2017 22:30:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de header.b=4ex4sQ+o; dkim=pass (1024-bit key) header.d=telekom.onmicrosoft.de header.b=GmTUtOCX 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 Y9ooeGOmbCO5 for ; Thu, 21 Sep 2017 22:30:28 -0700 (PDT) Received: from mailout14.telekom.de (MAILOUT14.telekom.de [80.149.113.182]) (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 7D249133032 for ; Thu, 21 Sep 2017 22:30:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1506058227; x=1537594227; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Q7puMdSXlL81ZYyeSUpn17irW1QH0k9KjNkJmmPwmNs=; b=4ex4sQ+oteMrKcq+Z6rA0ca4a0znuGwMFyHkjbpuY9uNiHdMrhkZG7cL NlVyc9SFtUnAYtjxQ7y4hcTHeVHJJ+OWNug3JWXNP04J9blrhH+x824c6 eUcSKJ7pGGRWFn+5CmdCeLtvBp/UJnMGD1TPrMZJr4z3EQQzVHHNrpJvl jJzG8RwPtlB9AOWjr/N2VjXk4fGgxO+cxO5ZHK8uot6H7hBH4iHlnnM5E Vmp53H8kp0fj4odTjJkUgsnpBRRHqHlUJL7xdzLsOAHmm4pPNZ1nOuUGe KkFTUhItRaTsSI24jF//eiE3m/4CKMRdl7SeMV22AFWixkUgfA6ooBkXM g==; Received: from qdec94.de.t-internal.com ([10.171.255.41]) by MAILOUT11.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Sep 2017 07:30:24 +0200 X-IronPort-AV: E=Sophos;i="5.42,427,1500933600"; d="scan'208";a="38700569" Received: from he105883.emea1.cds.t-internal.com ([10.169.118.33]) by QDEC97.de.t-internal.com with ESMTP/TLS/AES256-SHA; 22 Sep 2017 07:30:24 +0200 Received: from HE105667.EMEA1.cds.t-internal.com (10.169.118.63) by HE105883.emea1.cds.t-internal.com (10.169.118.33) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Fri, 22 Sep 2017 07:30:24 +0200 Received: from HE106564.emea1.cds.t-internal.com (10.171.40.16) by HE105667.EMEA1.cds.t-internal.com (10.169.118.63) with Microsoft SMTP Server (TLS) id 15.0.1293.2 via Frontend Transport; Fri, 22 Sep 2017 07:30:24 +0200 Received: from GER01-FRA-obe.outbound.protection.outlook.de (51.4.80.16) by O365mail01.telekom.de (172.30.0.234) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Fri, 22 Sep 2017 07:30:07 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.onmicrosoft.de; s=selector1-telekom-onmicrosoft-de; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Q7puMdSXlL81ZYyeSUpn17irW1QH0k9KjNkJmmPwmNs=; b=GmTUtOCXadBI08soeZ3+NzclTMswojhGHVZRodl98qU8hbte8L60opmkcbl0s8A6antAzZVkH1R2dXPoKJfuzyvt4CG5+W0az/V3DXRgM567bmRELu/pxal837ia5oHv7Y+6dACgOxJvpCFTr7D/8n5Dlk6m5wvugey1kDfrkd4= Received: from FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE (10.158.133.13) by FRAPR01MB0482.DEUPRD01.PROD.OUTLOOK.DE (10.158.133.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.11; Fri, 22 Sep 2017 05:30:22 +0000 Received: from FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE ([fe80::d1:57a:9b07:65a0]) by FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE ([fe80::d1:57a:9b07:65a0%15]) with mapi id 15.20.0056.018; Fri, 22 Sep 2017 05:30:17 +0000 From: "Jesske, Roland" To: Paul Kyzivat , "sipcore@ietf.org" CC: James Winterbottom Thread-Topic: [sipcore] draft-winterbottom-sipcore-locparam-01.txt and Liaison Statement to IETF on location source parameter Thread-Index: AdMgpPpaGGJ4RYVmTLCLOQ8COa0QNgRKYIsgAB10C4AAR0rWgA== Date: Fri, 22 Sep 2017 05:30:16 +0000 Message-ID: References: <87cf2edcef014e268e000ef358cc3c2c@HE105828.emea1.cds.t-internal.com> In-Reply-To: Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=R.Jesske@telekom.de; x-originating-ip: [164.19.3.89] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; FRAPR01MB0482; 6:2gAYf2zGDAg4z17NV+zcaanaJfbxTB0e7rTQ6CBLfFBbhryLwb83CKpiqvEgCou03kGkiATQNAKaGa3qHkCAAR2vQ5MWRD/0YZ2ZkKxOF+r+Oi/Iys5iMwUAO6NgZ0UtiCqbkCqH36c41UrzkEuWFE2IY5WOrM/dd/Fxphh28es4IcfuQMmcPnPz2io2t5uAhdPbcJTKUsUdIHTF5YgbyhEoUkzTKZPV+w7JeNPnJDSWrOoBV8+Y/uXLU+JIBYmL76tb8jA16M6OOpRwhygFZcwFxktrLj6/Nu/2n6mpxdt565GtKzSqn05wwrfbckya5rqvpqZ5k864uptkqWliiw==; 5:gJbp2WLbqsiazDyd4D249hQ9YaMIsTNny6uU5vrTZoaQRC1Kovey797SxPvNKk0nWdY/7hZ+r1fVayoyDqNsGY1IAUhQg19TIAit+iIuq3PsdS9tRdH/AzARmAnV7hTxnhqrFZGqdshumSZj/JuIeA==; 24:eTQJtVnaBgZEAVhvSlr1nZnLtlWa8/p8bPF8aEsmMAN3lrhPyizO0uwBlNUBqQLAIwqxoV6Q1nwPCyNdhj3rMjN2XB6PD/NDtdmZpM45MEU=; 7:EY7YJHvILF+KiDrqoFAf7GpDfU7kC0RdeU0Trpb8CMjCaMopcJ2UeP+2V0veX3xTOjjyDDLNZKYEJjMO9TO4KAXoTk1KeDRoIXbeyCbpPzrYE94GV4S2KzRU73S0ge1t1FESl39u6hIJHDl26BLw4ZGYhWq+shexrYZfmMwXbdTBKOofpkGp8slf0/Av12XvI9DQDJtEWfYomGe+nfunPlIMry68kxj/EuxJeYHQN0Y= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 9f233021-6a04-4e8c-4ba0-08d5017b0221 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(300000502095)(300135100095)(22001)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:FRAPR01MB0482; x-ms-traffictypediagnostic: FRAPR01MB0482: x-exchange-antispam-report-test: UriScan:(120809045254105)(150554046322364); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(3002001)(10201501046)(93006095)(93001095)(6041248)(20161123564025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123555025)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:FRAPR01MB0482; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:FRAPR01MB0482; x-forefront-prvs: 0438F90F17 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(346002)(189002)(199003)(24454002)(377454003)(2906002)(189998001)(97736004)(74482002)(7696004)(110136005)(66066001)(2900100001)(316002)(3660700001)(966005)(86362001)(345774005)(53546010)(478600001)(5660300001)(5250100002)(72206003)(3280700002)(54356999)(9686003)(230783001)(305945005)(55016002)(6306002)(105586002)(6116002)(50986999)(14454004)(2501003)(106356001)(4326008)(76176999)(75402003)(101416001)(53936002)(7736002)(68736007)(3846002)(2171002)(81166006)(33656002)(81156014)(39060400002)(8676002)(102836003)(2950100002)(8936002); DIR:OUT; SFP:1101; SCL:1; SRVR:FRAPR01MB0482; H:FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: telekom.de does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Sep 2017 05:30:16.9572 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f X-MS-Exchange-Transport-CrossTenantHeadersStamped: FRAPR01MB0482 X-OriginatorOrg: telekom.de Archived-At: Subject: Re: [sipcore] draft-winterbottom-sipcore-locparam-01.txt and Liaison Statement to IETF on location source parameter X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Sep 2017 05:30:31 -0000 Hi Paul, Thank you for your comment. The addition of other-loc-src was discussed in the past and was added due t= o some requests not to restrict this parameter to a hostname. ETSI does only needs a hostname. So I have nothing against to change it as you have proposed it.=20 So If other people would like to keep this please speak up. Thank you and Best Regards Roland > -----Urspr=FCngliche Nachricht----- > Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von Paul Kyziva= t > Gesendet: Mittwoch, 20. September 2017 21:12 > An: sipcore@ietf.org > Betreff: Re: [sipcore] draft-winterbottom-sipcore-locparam-01.txt and > Liaison Statement to IETF on location source parameter >=20 > I'm ok with adopting this. >=20 > A minor point on the content: >=20 > The syntax of the new parameter is defined as: >=20 > location-source =3D "loc-src=3D" (host / other-loc-src) > other-loc-src =3D token >=20 > But there is no definition of 'host'. I think the definition you are inte= nding is > actually 'hostname' as defined in 3261. >=20 > Also, if "Only a fully qualified host name is valid" then what is the poi= nt of > 'other-loc-src'? >=20 > So I would suggest: >=20 > location-source =3D "loc-src=3D" hostname > hostname =3D >=20 > Thanks, > Paul >=20 >=20 > On 9/20/17 1:09 AM, Jesske, Roland wrote: > > Dear all, > > > > since I did not get any comments on our draft it look for me that > > people are happy with the content. > > > > So I would like to ask the group for adoption of this draft. > > > > Best Regards > > > > Roland > > > > *Von:*sipcore [mailto:sipcore-bounces@ietf.org] *Im Auftrag von > > *Jesske, Roland > > *Gesendet:* Dienstag, 29. August 2017 10:59 > > *An:* sipcore@ietf.org > > *Betreff:* [sipcore] draft-winterbottom-sipcore-locparam-01.txt and > > Liaison Statement to IETF on location source parameter > > > > Dear all, > > > > since I have uploaded the latest draft on > > draft-winterbottom-sipcore-locparam-01.txt and the last clarification > > on questions were given on 23. May I did not get any further comment. > > > > With a reference to this draft a Liaison from ETSI ( > > https://datatracker.ietf.org/liaison/1527/ ) is waiting for action. > > > > The liaison from ETSI is asking on the progress of the draft for their > > solution on Emergency Call due to the Project of=A0 the European Union > > Mandate: M493. > > > > My question is, since we have no open questions, if we can now > > progress the draft. > > > > Thank you for consideration. > > > > Best Regards > > > > Roland > > > > > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Thu Sep 21 23:24:14 2017 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 3629513307B for ; Thu, 21 Sep 2017 23:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=sonusnetworks.onmicrosoft.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 gO1fSy_APyLI for ; Thu, 21 Sep 2017 23:24:09 -0700 (PDT) Received: from us-smtp-delivery-126.mimecast.com (us-smtp-delivery-126.mimecast.com [63.128.21.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CFAA133187 for ; Thu, 21 Sep 2017 23:24:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/gDYn+D5+AhJyGKXprQyJBgtVRelednWIvq3Z4R4oB0=; b=DA3W1EUZ7OqxQCqA3kiWGfjFfi37Z/ByB82DU6VhD2DlgwWqXSuvs/Az9UrSA3LTg/jR61K/VzIn5SwWOjHpwfE1Dj9dPM4PUbnLpc+Wu2lUNzKb2swwA1nBg0iy780Sxyy0Jp55KoOeqR3VZBp9JYJSD3keMkVXGT/NqL+FN1w= Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01lp0179.outbound.protection.outlook.com [216.32.181.179]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-58-G2eyKz_LP4e9fq8mR15l8Q-1; Fri, 22 Sep 2017 02:24:05 -0400 Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Fri, 22 Sep 2017 06:24:03 +0000 Received: from SN2PR03MB2350.namprd03.prod.outlook.com ([fe80::d88f:793d:af1f:f651]) by SN2PR03MB2350.namprd03.prod.outlook.com ([fe80::d88f:793d:af1f:f651%18]) with mapi id 15.20.0077.011; Fri, 22 Sep 2017 06:24:03 +0000 From: "Asveren, Tolga" To: "Jesske, Roland" , Paul Kyzivat , "sipcore@ietf.org" CC: James Winterbottom Thread-Topic: [sipcore] draft-winterbottom-sipcore-locparam-01.txt and Liaison Statement to IETF on location source parameter Thread-Index: AdMgpPpaGGJ4RYVmTLCLOQ8COa0QNgRKYIsgAB10C4AAR0rWgAACcnLQ Date: Fri, 22 Sep 2017 06:24:03 +0000 Message-ID: References: <87cf2edcef014e268e000ef358cc3c2c@HE105828.emea1.cds.t-internal.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [73.29.18.75] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN2PR03MB2350; 20:ZKU45DZrFUj8xAb6C+ylXqPuJxxaK6T2wzuSPs+qv9KmQCc4T6vTLdIZjZyh93hxQLC9lAPvIIqMvvp4TCYbmc/1oC68pUQnEIMJW2+tp7Bfv9N+VtS9FE1YXee+giz2qBEpJmTmqOxx44RwMqqo0x9LNrjuUB1LIkBZDb4RKkg= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 6d19caec-e647-4c36-e5e3-08d501828523 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:SN2PR03MB2350; x-ms-traffictypediagnostic: SN2PR03MB2350: x-exchange-antispam-report-test: UriScan:(120809045254105)(150554046322364); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(6041248)(20161123555025)(20161123562025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:SN2PR03MB2350; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:SN2PR03MB2350; x-forefront-prvs: 0438F90F17 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(377454003)(199003)(24454002)(13464003)(189002)(33656002)(2950100002)(66066001)(5660300001)(68736007)(7696004)(345774005)(3846002)(102836003)(6246003)(6436002)(2171002)(39060400002)(101416001)(25786009)(6116002)(53936002)(4326008)(230783001)(9686003)(55016002)(76176999)(99286003)(50986999)(3280700002)(229853002)(54356999)(3660700001)(6506006)(106356001)(6306002)(105586002)(8676002)(2900100001)(93886005)(81166006)(81156014)(189998001)(305945005)(2906002)(7736002)(86362001)(8936002)(5250100002)(74316002)(97736004)(478600001)(316002)(110136005)(14454004)(2501003)(53546010)(966005); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB2350; H:SN2PR03MB2350.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Sep 2017 06:24:03.2485 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2350 X-MC-Unique: G2eyKz_LP4e9fq8mR15l8Q-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [sipcore] draft-winterbottom-sipcore-locparam-01.txt and Liaison Statement to IETF on location source parameter X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Sep 2017 06:24:12 -0000 I would prefer to keep the existing syntax. Not that I have an immediate us= e case at hand but you never know what future would bring. And it would be = a pity to have an extension draft just for something like this. Thanks, Tolga -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Jesske, Roland Sent: Friday, September 22, 2017 1:30 AM To: Paul Kyzivat ; sipcore@ietf.org Cc: James Winterbottom Subject: Re: [sipcore] draft-winterbottom-sipcore-locparam-01.txt and Liais= on Statement to IETF on location source parameter Hi Paul, Thank you for your comment. The addition of other-loc-src was discussed in the past and was added due t= o some requests not to restrict this parameter to a hostname. ETSI does only needs a hostname. So I have nothing against to change it as you have proposed it.=20 So If other people would like to keep this please speak up. Thank you and Best Regards Roland > -----Urspr=FCngliche Nachricht----- > Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von Paul=20 > Kyzivat > Gesendet: Mittwoch, 20. September 2017 21:12 > An: sipcore@ietf.org > Betreff: Re: [sipcore] draft-winterbottom-sipcore-locparam-01.txt and=20 > Liaison Statement to IETF on location source parameter >=20 > I'm ok with adopting this. >=20 > A minor point on the content: >=20 > The syntax of the new parameter is defined as: >=20 > location-source =3D "loc-src=3D" (host / other-loc-src) > other-loc-src =3D token >=20 > But there is no definition of 'host'. I think the definition you are=20 > intending is actually 'hostname' as defined in 3261. >=20 > Also, if "Only a fully qualified host name is valid" then what is the=20 > point of 'other-loc-src'? >=20 > So I would suggest: >=20 > location-source =3D "loc-src=3D" hostname > hostname =3D >=20 > =09Thanks, > =09Paul >=20 >=20 > On 9/20/17 1:09 AM, Jesske, Roland wrote: > > Dear all, > > > > since I did not get any comments on our draft it look for me that=20 > > people are happy with the content. > > > > So I would like to ask the group for adoption of this draft. > > > > Best Regards > > > > Roland > > > > *Von:*sipcore [mailto:sipcore-bounces@ietf.org] *Im Auftrag von=20 > > *Jesske, Roland > > *Gesendet:* Dienstag, 29. August 2017 10:59 > > *An:* sipcore@ietf.org > > *Betreff:* [sipcore] draft-winterbottom-sipcore-locparam-01.txt and=20 > > Liaison Statement to IETF on location source parameter > > > > Dear all, > > > > since I have uploaded the latest draft on=20 > > draft-winterbottom-sipcore-locparam-01.txt and the last=20 > > clarification on questions were given on 23. May I did not get any furt= her comment. > > > > With a reference to this draft a Liaison from ETSI (=20 > > https://datatracker.ietf.org/liaison/1527/ ) is waiting for action. > > > > The liaison from ETSI is asking on the progress of the draft for=20 > > their solution on Emergency Call due to the Project of=A0 the European= =20 > > Union > > Mandate: M493. > > > > My question is, since we have no open questions, if we can now=20 > > progress the draft. > > > > Thank you for consideration. > > > > Best Regards > > > > Roland > > > > > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > >=20 > _______________________________________________ > 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 Fri Sep 22 02:44:29 2017 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 A78FD1342CF for ; Fri, 22 Sep 2017 02:44:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de header.b=8I6gbUj/; dkim=pass (1024-bit key) header.d=telekom.onmicrosoft.de header.b=I7XwdJOt 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 Z0tUkRdIOOZm for ; Fri, 22 Sep 2017 02:44:25 -0700 (PDT) Received: from MAILOUT21.telekom.de (MAILOUT21.telekom.de [80.149.113.251]) (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 154A9133229 for ; Fri, 22 Sep 2017 02:44:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1506073465; x=1537609465; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=r4nFGuIGqApHVPkXqW/O3MC1+f2rqkdMrwlWRHsMb0Y=; b=8I6gbUj/iwJslhOXeUvSMDetupKXTqXDFrjX2br3TECdlQpiWLxK0j3W eAXnBgdniR/R41/TqrcV6PapmGsfUL1dbwzCjQgsVYpFV6BMVez8F9V+j ayU7ZkYmx/R2kdcpFE+onJioE/AoIhJFg+iTnVT4CnXZwSZ4xNXNRHea/ 3rpq52IHrJCTL4PcOtknUiF0evmuI54WhIVwWLDmwBNmZewaZeGYR0XqM 8qj+Pw7PvbeItoEDpIMK5J9AafrnDUdQMXA+i5TpvlXMvSpAFOIQZbuoc wNF7PH52XgFbPuv8snBYZjDD+nBDCsPjqjHSb+rOvPOK/Z2RhQm62xL1D A==; Received: from qdec94.de.t-internal.com ([10.171.255.41]) by MAILOUT21.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Sep 2017 11:44:22 +0200 X-IronPort-AV: E=Sophos;i="5.42,427,1500933600"; d="scan'208";a="38864978" Received: from he105662.emea1.cds.t-internal.com ([10.169.119.58]) by QDEC97.de.t-internal.com with ESMTP/TLS/AES256-SHA; 22 Sep 2017 11:44:22 +0200 Received: from HE105651.EMEA1.cds.t-internal.com (10.169.119.62) by HE105662.emea1.cds.t-internal.com (10.169.119.58) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Fri, 22 Sep 2017 11:44:22 +0200 Received: from HE100181.emea1.cds.t-internal.com (10.171.40.15) by HE105651.EMEA1.cds.t-internal.com (10.169.119.62) with Microsoft SMTP Server (TLS) id 15.0.1293.2 via Frontend Transport; Fri, 22 Sep 2017 11:44:22 +0200 Received: from GER01-FRA-obe.outbound.protection.outlook.de (51.4.80.18) by O365mail02.telekom.de (172.30.0.235) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Fri, 22 Sep 2017 11:43:49 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.onmicrosoft.de; s=selector1-telekom-onmicrosoft-de; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=r4nFGuIGqApHVPkXqW/O3MC1+f2rqkdMrwlWRHsMb0Y=; b=I7XwdJOtT5y1LnlStrcK9wlbDLRwV4H1Dd6YeCwhiPSghTUBc0tRVCScGaOEHo0PfQRONRxiVYBEo5d5+kiheTQhPKHI3KA5xnlSH3l2iF0SMnlnQJeLqtlT/v5fBh7QQYk3Ctcx1+yqnX7o8Zl8AXb8xln8jY5INFG4nXehOt8= Received: from FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE (10.158.133.13) by FRAPR01MB0481.DEUPRD01.PROD.OUTLOOK.DE (10.158.133.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.11; Fri, 22 Sep 2017 09:44:17 +0000 Received: from FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE ([fe80::d1:57a:9b07:65a0]) by FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE ([fe80::d1:57a:9b07:65a0%15]) with mapi id 15.20.0056.018; Fri, 22 Sep 2017 09:44:18 +0000 From: "Jesske, Roland" To: "Asveren, Tolga" , Paul Kyzivat , "sipcore@ietf.org" CC: James Winterbottom Thread-Topic: [sipcore] draft-winterbottom-sipcore-locparam-01.txt and Liaison Statement to IETF on location source parameter Thread-Index: AdMgpPpaGGJ4RYVmTLCLOQ8COa0QNgRKYIsgAB10C4AAR0rWgAACcnLQAAbTIhA= Date: Fri, 22 Sep 2017 09:44:17 +0000 Message-ID: References: <87cf2edcef014e268e000ef358cc3c2c@HE105828.emea1.cds.t-internal.com> In-Reply-To: Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=R.Jesske@telekom.de; x-originating-ip: [164.19.3.89] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; FRAPR01MB0481; 6:NqNa0R3jCuc6zbkVln3oe1qZxuTnfvBMI35hmnFsB/V3DWb8szw5NQiQfUiLd91UKzq4TT+vWm0VYfeWCmyfimm/5N4lPnu/SLMwytZai0WnwqNsCCbFoalByy3PEkBRYjUcB6QADm+jixt7BjC8gCGKbyCo7d3F7mndQlnegPsM/BhMrv32PUvihrlbE/BnK0TWqMsOkyiTbnTCNUanCm6tTNVA4Fs52vw7prpkd9Wp7dK9cqc4H8emJyROFFcaIBSLVcZmlJZPl2C9iHYzop//LpIkx26/9P5oLho+qHLexvh8ivLIW44f/O926anzGOtKLz3r+hfUYxNZ88MBFQ==; 5:vS909bdfNYctjsPqzdt49W6s6HSt6+zXp6aMejs9zRiLPhq4xYifsfNNoq9BO61znJ8WWDRUhs6sMkU1ehXHYJ3gsupElWNxn8Z8Zbsm+Wd4P8oIwdFY9YQQqJwurrP75L6RD40UbDBPAJxE0OAffQ==; 24:bdFn2puZLiRgGtFFfZcWhA+kSa/jksCKrn/potLdh5thE8+gGXSDZ4Sd7kzi79tsGXAKdzFWwpN2BfDTvzdkv5j8T7KEU1oBFJFTluLCWtA=; 7:RaCZoHFkttUWD7qp/u+X3AX3u0UVJQuEhVMLLQ/1jbfmeF+FIH8e4iu/69UKF5v12oV0jTCgvebGBLQCfccq5CoBt4OZad1/y6xrHqMuPNOGZiIO0zm7uG4rGYlmgC+0eij/NAnG3ERky5clQ0rs2IzZiroSAE1BZV5OgE7plIJjcb+ic3DO8pbxMvlytsaZ9NdC5+mjBjJBTtByszlG5vcw7B4EiZhHrPUgZpG1y6I= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: e5ef878f-4d03-4fd8-db79-08d5019e7e7a x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:FRAPR01MB0481; x-ms-traffictypediagnostic: FRAPR01MB0481: x-exchange-antispam-report-test: UriScan:(120809045254105)(150554046322364); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(100000703101)(100105400095)(6041248)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123555025)(20161123562025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:FRAPR01MB0481; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:FRAPR01MB0481; x-forefront-prvs: 0438F90F17 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(189002)(377454003)(199003)(24454002)(13464003)(5660300001)(53546010)(3280700002)(106356001)(105586002)(3660700001)(33656002)(2906002)(8676002)(7736002)(81156014)(81166006)(189998001)(5250100002)(68736007)(2501003)(305945005)(75402003)(2950100002)(8936002)(97736004)(14454004)(230783001)(110136005)(316002)(7696004)(74482002)(54356999)(76176999)(50986999)(2900100001)(86362001)(4326008)(39060400002)(102836003)(6116002)(3846002)(6306002)(55016002)(53936002)(2171002)(9686003)(478600001)(66066001)(101416001)(345774005)(93886005)(72206003)(966005); DIR:OUT; SFP:1101; SCL:1; SRVR:FRAPR01MB0481; H:FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: telekom.de does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Sep 2017 09:44:17.9984 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f X-MS-Exchange-Transport-CrossTenantHeadersStamped: FRAPR01MB0481 X-OriginatorOrg: telekom.de Archived-At: Subject: Re: [sipcore] draft-winterbottom-sipcore-locparam-01.txt and Liaison Statement to IETF on location source parameter X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Sep 2017 09:44:29 -0000 Hi, so I can let it as it is or add an additional note to mention that the toke= n is for future proof use. Also to address Pauls comment complete. I would propose then the following: location-source =3D "loc-src=3D" (hostname / other-loc-src) hostname =3D other-loc-src =3D token Figure 1: Location Source Thank you and Best regards Roland > -----Urspr=FCngliche Nachricht----- > Von: Asveren, Tolga [mailto:tasveren@sonusnet.com] > Gesendet: Freitag, 22. September 2017 08:24 > An: Jesske, Roland ; Paul Kyzivat > ; sipcore@ietf.org > Cc: James Winterbottom > Betreff: RE: [sipcore] draft-winterbottom-sipcore-locparam-01.txt and > Liaison Statement to IETF on location source parameter >=20 > I would prefer to keep the existing syntax. Not that I have an immediate = use > case at hand but you never know what future would bring. And it would be = a > pity to have an extension draft just for something like this. >=20 > Thanks, > Tolga >=20 > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Jesske, Rola= nd > Sent: Friday, September 22, 2017 1:30 AM > To: Paul Kyzivat ; sipcore@ietf.org > Cc: James Winterbottom > Subject: Re: [sipcore] draft-winterbottom-sipcore-locparam-01.txt and > Liaison Statement to IETF on location source parameter >=20 > Hi Paul, > Thank you for your comment. > The addition of other-loc-src was discussed in the past and was added due= to > some requests not to restrict this parameter to a hostname. > ETSI does only needs a hostname. >=20 > So I have nothing against to change it as you have proposed it. > So If other people would like to keep this please speak up. >=20 > Thank you and Best Regards >=20 > Roland >=20 >=20 >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von Paul > > Kyzivat > > Gesendet: Mittwoch, 20. September 2017 21:12 > > An: sipcore@ietf.org > > Betreff: Re: [sipcore] draft-winterbottom-sipcore-locparam-01.txt and > > Liaison Statement to IETF on location source parameter > > > > I'm ok with adopting this. > > > > A minor point on the content: > > > > The syntax of the new parameter is defined as: > > > > location-source =3D "loc-src=3D" (host / other-loc-src) > > other-loc-src =3D token > > > > But there is no definition of 'host'. I think the definition you are > > intending is actually 'hostname' as defined in 3261. > > > > Also, if "Only a fully qualified host name is valid" then what is the > > point of 'other-loc-src'? > > > > So I would suggest: > > > > location-source =3D "loc-src=3D" hostname > > hostname =3D > > > > Thanks, > > Paul > > > > > > On 9/20/17 1:09 AM, Jesske, Roland wrote: > > > Dear all, > > > > > > since I did not get any comments on our draft it look for me that > > > people are happy with the content. > > > > > > So I would like to ask the group for adoption of this draft. > > > > > > Best Regards > > > > > > Roland > > > > > > *Von:*sipcore [mailto:sipcore-bounces@ietf.org] *Im Auftrag von > > > *Jesske, Roland > > > *Gesendet:* Dienstag, 29. August 2017 10:59 > > > *An:* sipcore@ietf.org > > > *Betreff:* [sipcore] draft-winterbottom-sipcore-locparam-01.txt and > > > Liaison Statement to IETF on location source parameter > > > > > > Dear all, > > > > > > since I have uploaded the latest draft on > > > draft-winterbottom-sipcore-locparam-01.txt and the last > > > clarification on questions were given on 23. May I did not get any fu= rther > comment. > > > > > > With a reference to this draft a Liaison from ETSI ( > > > https://datatracker.ietf.org/liaison/1527/ ) is waiting for action. > > > > > > The liaison from ETSI is asking on the progress of the draft for > > > their solution on Emergency Call due to the Project of=A0 the Europea= n > > > Union > > > Mandate: M493. > > > > > > My question is, since we have no open questions, if we can now > > > progress the draft. > > > > > > Thank you for consideration. > > > > > > Best Regards > > > > > > Roland > > > > > > > > > > > > _______________________________________________ > > > 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 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Fri Sep 22 06:43:04 2017 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 A4AED134463 for ; Fri, 22 Sep 2017 06:43:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 EHQ1nniNgrIF for ; Fri, 22 Sep 2017 06:43:01 -0700 (PDT) Received: from alum-mailsec-scanner-1.mit.edu (alum-mailsec-scanner-1.mit.edu [18.7.68.12]) by ietfa.amsl.com (Postfix) with ESMTP id 04E84134467 for ; Fri, 22 Sep 2017 06:42:36 -0700 (PDT) X-AuditID: 1207440c-7e5ff7000000143e-f0-59c5134c90ea Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id E1.32.05182.C4315C95; Fri, 22 Sep 2017 09:42:36 -0400 (EDT) Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id v8MDgYa0011545 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 22 Sep 2017 09:42:35 -0400 To: "Jesske, Roland" , "Asveren, Tolga" , "sipcore@ietf.org" Cc: James Winterbottom References: <87cf2edcef014e268e000ef358cc3c2c@HE105828.emea1.cds.t-internal.com> From: Paul Kyzivat Message-ID: <6e9d3dd7-0c23-2896-8b3b-80bfdd462b92@alum.mit.edu> Date: Fri, 22 Sep 2017 09:42:34 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFKsWRmVeSWpSXmKPExsUixO6iqOsjfDTS4GeTuMW9TT9ZLJrudLFZ fP2xic1idud7JgcWj52z7rJ7LFnyk8nj0uf/7B5tLxUCWKK4bFJSczLLUov07RK4MvZ9u8pW 8EejouvFa+YGxhcKXYwcHBICJhLb1vJ0MXJxCAnsYJL4/eUMC4TzkEniwIQmNhBHWKCJUeLo xhPMII6IQD+jxOnp75i6GDk5mAXMJZrPdzBCtJxnljh1+AwrSIJNQEtizqH/LCA2r4C9xLu9 08DiLAKqEodmnAaLiwqkSfzbfZYRokZQ4uTMJ2BxToEYiecHj0EtMJOYt/khM4QtLnHryXyo uLxE89bZzBMYBWYhaZ+FpGUWkpZZSFoWMLKsYpRLzCnN1c1NzMwpTk3WLU5OzMtLLdI11MvN LNFLTSndxAgJdp4djN/WyRxiFOBgVOLhNTh4OFKINbGsuDL3EKMkB5OSKG+CwNFIIb6k/JTK jMTijPii0pzU4kOMEhzMSiK8R/8diRTiTUmsrEotyodJSXOwKInzqi5R9xMSSE8sSc1OTS1I LYLJynBwKEnw1gsBDRUsSk1PrUjLzClBSDNxcIIM5wEaHglSw1tckJhbnJkOkT/FqMvR03Pj D5MQS15+XqqUOG8eSJEASFFGaR7cHFiSesUoDvSWMC8XSBUPMMHBTXoFtIQJaEn5apAPiksS EVJSDYxlbiF1K+X1rm+5cDcqzcNSsSL5yIdbYnfitQ++6ryx8uaauty1D/6eYM4VKmDOPqK7 29dc5462iefF+ivpvZO5QkrUtl/dvmH6nrPiC7QWpK++0WTp0VEn7r64qmK6puy7k54dPo/3 l94Tf+bvNGWvyOrGj5JRO81u1x1eFOAr52au4mp3VkiJpTgj0VCLuag4EQDn/O/uLQMAAA== Archived-At: Subject: Re: [sipcore] draft-winterbottom-sipcore-locparam-01.txt and Liaison Statement to IETF on location source parameter X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Sep 2017 13:43:03 -0000 Roland, On 9/22/17 5:44 AM, Jesske, Roland wrote: > Hi, > so I can let it as it is or add an additional note to mention that the token is for future proof use. > > > Also to address Pauls comment complete. I would propose then the following: > > > location-source = "loc-src=" (hostname / other-loc-src) > hostname = > other-loc-src = token > > Figure 1: Location Source I'll be ok with this if you also include some text about the intent of other-loc-src. Is it intended only as a hook for future extension - requiring another document to define that usage? What should a recipient do if they receive this with something matching other-loc-src and don't understand that usage? > Thank you and Best regards > > Roland > >> -----Ursprüngliche Nachricht----- >> Von: Asveren, Tolga [mailto:tasveren@sonusnet.com] >> Gesendet: Freitag, 22. September 2017 08:24 >> An: Jesske, Roland ; Paul Kyzivat >> ; sipcore@ietf.org >> Cc: James Winterbottom >> Betreff: RE: [sipcore] draft-winterbottom-sipcore-locparam-01.txt and >> Liaison Statement to IETF on location source parameter >> >> I would prefer to keep the existing syntax. Not that I have an immediate use >> case at hand but you never know what future would bring. And it would be a >> pity to have an extension draft just for something like this. >> >> Thanks, >> Tolga >> >> -----Original Message----- >> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Jesske, Roland >> Sent: Friday, September 22, 2017 1:30 AM >> To: Paul Kyzivat ; sipcore@ietf.org >> Cc: James Winterbottom >> Subject: Re: [sipcore] draft-winterbottom-sipcore-locparam-01.txt and >> Liaison Statement to IETF on location source parameter >> >> Hi Paul, >> Thank you for your comment. >> The addition of other-loc-src was discussed in the past and was added due to >> some requests not to restrict this parameter to a hostname. >> ETSI does only needs a hostname. >> >> So I have nothing against to change it as you have proposed it. >> So If other people would like to keep this please speak up. >> >> Thank you and Best Regards >> >> Roland >> >> >> >>> -----Ursprüngliche Nachricht----- >>> Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von Paul >>> Kyzivat >>> Gesendet: Mittwoch, 20. September 2017 21:12 >>> An: sipcore@ietf.org >>> Betreff: Re: [sipcore] draft-winterbottom-sipcore-locparam-01.txt and >>> Liaison Statement to IETF on location source parameter >>> >>> I'm ok with adopting this. >>> >>> A minor point on the content: >>> >>> The syntax of the new parameter is defined as: >>> >>> location-source = "loc-src=" (host / other-loc-src) >>> other-loc-src = token >>> >>> But there is no definition of 'host'. I think the definition you are >>> intending is actually 'hostname' as defined in 3261. >>> >>> Also, if "Only a fully qualified host name is valid" then what is the >>> point of 'other-loc-src'? >>> >>> So I would suggest: >>> >>> location-source = "loc-src=" hostname >>> hostname = >>> >>> Thanks, >>> Paul >>> >>> >>> On 9/20/17 1:09 AM, Jesske, Roland wrote: >>>> Dear all, >>>> >>>> since I did not get any comments on our draft it look for me that >>>> people are happy with the content. >>>> >>>> So I would like to ask the group for adoption of this draft. >>>> >>>> Best Regards >>>> >>>> Roland >>>> >>>> *Von:*sipcore [mailto:sipcore-bounces@ietf.org] *Im Auftrag von >>>> *Jesske, Roland >>>> *Gesendet:* Dienstag, 29. August 2017 10:59 >>>> *An:* sipcore@ietf.org >>>> *Betreff:* [sipcore] draft-winterbottom-sipcore-locparam-01.txt and >>>> Liaison Statement to IETF on location source parameter >>>> >>>> Dear all, >>>> >>>> since I have uploaded the latest draft on >>>> draft-winterbottom-sipcore-locparam-01.txt and the last >>>> clarification on questions were given on 23. May I did not get any further >> comment. >>>> >>>> With a reference to this draft a Liaison from ETSI ( >>>> https://datatracker.ietf.org/liaison/1527/ ) is waiting for action. >>>> >>>> The liaison from ETSI is asking on the progress of the draft for >>>> their solution on Emergency Call due to the Project of  the European >>>> Union >>>> Mandate: M493. >>>> >>>> My question is, since we have no open questions, if we can now >>>> progress the draft. >>>> >>>> Thank you for consideration. >>>> >>>> Best Regards >>>> >>>> Roland >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore > > From nobody Fri Sep 22 10:21:13 2017 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 789AE134559 for ; Fri, 22 Sep 2017 10:21:11 -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 6U8rxYX1PrSI for ; Fri, 22 Sep 2017 10:21:09 -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 4907A134554 for ; Fri, 22 Sep 2017 10:21:09 -0700 (PDT) X-AuditID: c1b4fb30-683ff70000007145-b4-59c54683d201 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id E0.92.28997.38645C95; Fri, 22 Sep 2017 19:21:07 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.6]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0352.000; Fri, 22 Sep 2017 19:21:06 +0200 From: Christer Holmberg To: Paul Kyzivat , "Jesske, Roland" , "Asveren, Tolga" , "sipcore@ietf.org" CC: James Winterbottom Thread-Topic: [sipcore] draft-winterbottom-sipcore-locparam-01.txt and Liaison Statement to IETF on location source parameter Thread-Index: AdMgpPpaGGJ4RYVmTLCLOQ8COa0QNgRKYIsgABlDKYAAR+STAAAB4NyAAAb+OoAACFJrAAALyEVA Date: Fri, 22 Sep 2017 17:21:06 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B562F0504@ESESSMB109.ericsson.se> References: <87cf2edcef014e268e000ef358cc3c2c@HE105828.emea1.cds.t-internal.com> <6e9d3dd7-0c23-2896-8b3b-80bfdd462b92@alum.mit.edu> In-Reply-To: <6e9d3dd7-0c23-2896-8b3b-80bfdd462b92@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.154] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJIsWRmVeSWpSXmKPExsUyM2K7h26z29FIg+1PhS3ubfrJYrFiwwFW i6Y7XWwWX39sYrOY3fmeyYHV4+/7D0weO2fdZfdYsuQnk8elz//ZPdpeKgSwRnHZpKTmZJal FunbJXBlXNp+i62gx7Ji5cYFjA2MF8y7GDk5JARMJBr+rWbrYuTiEBI4wihxadZJJghnEaPE 6RtnmLsYOTjYBCwkuv9pg8RFBJYySqxd3ccE0s0sYC7xvH0rM4gtLFAnsaerC8wWEaiX+LBs OwuEHSWx+cYHVhCbRUBVYtaqX+wgNq+Ar8StTbehNreySBzu7gBr5hRwkJi7uocRxGYUEJP4 fmoN1DJxiVtP5jNBnC0gsWTPeWYIW1Ti5eN/rBC2ksSi25+ZQI5mFtCUWL9LH6JVUWJK90Oo vYISJ2c+YZnAKDoLydRZCB2zkHTMQtKxgJFlFaNocWpxUm66kZFealFmcnFxfp5eXmrJJkZg hB3c8ttgB+PL546HGAU4GJV4eDfoHo0UYk0sK67MPcQowcGsJMJb4QoU4k1JrKxKLcqPLyrN SS0+xCjNwaIkzuu470KEkEB6YklqdmpqQWoRTJaJg1OqgbHB6kDczu82b5mUvkpGs567wSXE 7sP4o1N6ipkmy8mNW9YcnPN+auN/GXWfJfNtn0zcvqCwZvY6BlGv0Ic/c+p5L5rKiPY9bn3N W9J4+3LoJKvmhdL31pXMmSTeH5vSLzXt2+TzSjrSVzSUHnJueHbJbfqqTMmzHftm1qiYTDlc wLL5IYvtCkUlluKMREMt5qLiRABUYxWzrAIAAA== Archived-At: Subject: Re: [sipcore] draft-winterbottom-sipcore-locparam-01.txt and Liaison Statement to IETF on location source parameter X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Sep 2017 17:21:11 -0000 SGksDQoNCj4+IEFsc28gdG8gYWRkcmVzcyBQYXVscyBjb21tZW50IGNvbXBsZXRlLiBJIHdvdWxk IHByb3Bvc2UgdGhlbiB0aGUgZm9sbG93aW5nOg0KPj4gDQo+PiANCj4+ICAgICAgICAgICAgbG9j YXRpb24tc291cmNlID0gImxvYy1zcmM9IiAoaG9zdG5hbWUgLyBvdGhlci1sb2Mtc3JjKQ0KPj4g ICAgICAgICAgICBob3N0bmFtZSA9IDxkZWZpbmVkIGluIFJGQzMyNjE+DQo+PiAgICAgICAgICAg IG90aGVyLWxvYy1zcmMgPSB0b2tlbg0KPj4gDQo+PiAgICAgICAgICAgICAgICAgICAgICAgICAg IEZpZ3VyZSAxOiBMb2NhdGlvbiBTb3VyY2UNCj4NCj5JJ2xsIGJlIG9rIHdpdGggdGhpcyBpZiB5 b3UgYWxzbyBpbmNsdWRlIHNvbWUgdGV4dCBhYm91dCB0aGUgaW50ZW50IG9mIG90aGVyLWxvYy1z cmMuIElzIGl0ID5pbnRlbmRlZCBvbmx5IGFzIGEgaG9vayBmb3IgZnV0dXJlIGV4dGVuc2lvbiAt IHJlcXVpcmluZyBhbm90aGVyIGRvY3VtZW50IHRvIGRlZmluZSB0aGF0ID51c2FnZT8gV2hhdCBz aG91bGQgYSByZWNpcGllbnQgZG8gaWYgdGhleSByZWNlaXZlIHRoaXMgd2l0aCBzb21ldGhpbmcg bWF0Y2hpbmcgb3RoZXItbG9jLT5zcmMgYW5kIGRvbid0IHVuZGVyc3RhbmQgdGhhdCB1c2FnZT8N Cg0KQXMgSSBpbmRpY2F0ZWQgaW4gbXkgY29tbWVudHMsIEknZCBsaWtlIHRvIHNlZSBzb21lIGp1 c3RpZmljYXRpb24gb24gd2h5IHdlIG1hbmRhdGUgYSBGUUROIHRvIGJlZ2luIHdpdGguDQoNClJl Z2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KDQo+PiAtLS0tLVVyc3Byw7xuZ2xpY2hlIE5hY2hyaWNo dC0tLS0tDQo+PiBWb246IEFzdmVyZW4sIFRvbGdhIFttYWlsdG86dGFzdmVyZW5Ac29udXNuZXQu Y29tXQ0KPj4gR2VzZW5kZXQ6IEZyZWl0YWcsIDIyLiBTZXB0ZW1iZXIgMjAxNyAwODoyNA0KPj4g QW46IEplc3NrZSwgUm9sYW5kIDxSLkplc3NrZUB0ZWxla29tLmRlPjsgUGF1bCBLeXppdmF0IA0K Pj4gPHBreXppdmF0QGFsdW0ubWl0LmVkdT47IHNpcGNvcmVAaWV0Zi5vcmcNCj4+IENjOiBKYW1l cyBXaW50ZXJib3R0b20gPGEuamFtZXMud2ludGVyYm90dG9tQGdtYWlsLmNvbT4NCj4+IEJldHJl ZmY6IFJFOiBbc2lwY29yZV0gZHJhZnQtd2ludGVyYm90dG9tLXNpcGNvcmUtbG9jcGFyYW0tMDEu dHh0IGFuZCANCj4+IExpYWlzb24gU3RhdGVtZW50IHRvIElFVEYgb24gbG9jYXRpb24gc291cmNl IHBhcmFtZXRlcg0KPj4NCj4+IEkgd291bGQgcHJlZmVyIHRvIGtlZXAgdGhlIGV4aXN0aW5nIHN5 bnRheC4gTm90IHRoYXQgSSBoYXZlIGFuIA0KPj4gaW1tZWRpYXRlIHVzZSBjYXNlIGF0IGhhbmQg YnV0IHlvdSBuZXZlciBrbm93IHdoYXQgZnV0dXJlIHdvdWxkIA0KPj4gYnJpbmcuIEFuZCBpdCB3 b3VsZCBiZSBhIHBpdHkgdG8gaGF2ZSBhbiBleHRlbnNpb24gZHJhZnQganVzdCBmb3Igc29tZXRo aW5nIGxpa2UgdGhpcy4NCj4+DQo+PiBUaGFua3MsDQo+PiBUb2xnYQ0KPj4NCj4+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9tOiBzaXBjb3JlIFttYWlsdG86c2lwY29yZS1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSmVzc2tlLCANCj4+IFJvbGFuZA0KPj4gU2VudDog RnJpZGF5LCBTZXB0ZW1iZXIgMjIsIDIwMTcgMTozMCBBTQ0KPj4gVG86IFBhdWwgS3l6aXZhdCA8 cGt5eml2YXRAYWx1bS5taXQuZWR1Pjsgc2lwY29yZUBpZXRmLm9yZw0KPj4gQ2M6IEphbWVzIFdp bnRlcmJvdHRvbSA8YS5qYW1lcy53aW50ZXJib3R0b21AZ21haWwuY29tPg0KPj4gU3ViamVjdDog UmU6IFtzaXBjb3JlXSBkcmFmdC13aW50ZXJib3R0b20tc2lwY29yZS1sb2NwYXJhbS0wMS50eHQg YW5kIA0KPj4gTGlhaXNvbiBTdGF0ZW1lbnQgdG8gSUVURiBvbiBsb2NhdGlvbiBzb3VyY2UgcGFy YW1ldGVyDQo+Pg0KPj4gSGkgUGF1bCwNCj4+IFRoYW5rIHlvdSBmb3IgeW91ciBjb21tZW50Lg0K Pj4gVGhlIGFkZGl0aW9uIG9mIG90aGVyLWxvYy1zcmMgd2FzIGRpc2N1c3NlZCBpbiB0aGUgcGFz dCBhbmQgd2FzIGFkZGVkIA0KPj4gZHVlIHRvIHNvbWUgcmVxdWVzdHMgbm90IHRvIHJlc3RyaWN0 IHRoaXMgcGFyYW1ldGVyIHRvIGEgaG9zdG5hbWUuDQo+PiBFVFNJIGRvZXMgb25seSBuZWVkcyBh IGhvc3RuYW1lLg0KPj4NCj4+IFNvIEkgaGF2ZSBub3RoaW5nIGFnYWluc3QgdG8gY2hhbmdlIGl0 IGFzIHlvdSBoYXZlIHByb3Bvc2VkIGl0Lg0KPj4gU28gSWYgb3RoZXIgcGVvcGxlIHdvdWxkIGxp a2UgdG8ga2VlcCB0aGlzIHBsZWFzZSBzcGVhayB1cC4NCj4+DQo+PiBUaGFuayB5b3UgYW5kIEJl c3QgUmVnYXJkcw0KPj4NCj4+IFJvbGFuZA0KPj4NCj4+DQo+Pg0KPj4+IC0tLS0tVXJzcHLDvG5n bGljaGUgTmFjaHJpY2h0LS0tLS0NCj4+PiBWb246IHNpcGNvcmUgW21haWx0bzpzaXBjb3JlLWJv dW5jZXNAaWV0Zi5vcmddIEltIEF1ZnRyYWcgdm9uIFBhdWwgDQo+Pj4gS3l6aXZhdA0KPj4+IEdl c2VuZGV0OiBNaXR0d29jaCwgMjAuIFNlcHRlbWJlciAyMDE3IDIxOjEyDQo+Pj4gQW46IHNpcGNv cmVAaWV0Zi5vcmcNCj4+PiBCZXRyZWZmOiBSZTogW3NpcGNvcmVdIGRyYWZ0LXdpbnRlcmJvdHRv bS1zaXBjb3JlLWxvY3BhcmFtLTAxLnR4dCANCj4+PiBhbmQgTGlhaXNvbiBTdGF0ZW1lbnQgdG8g SUVURiBvbiBsb2NhdGlvbiBzb3VyY2UgcGFyYW1ldGVyDQo+Pj4NCj4+PiBJJ20gb2sgd2l0aCBh ZG9wdGluZyB0aGlzLg0KPj4+DQo+Pj4gQSBtaW5vciBwb2ludCBvbiB0aGUgY29udGVudDoNCj4+ Pg0KPj4+IFRoZSBzeW50YXggb2YgdGhlIG5ldyBwYXJhbWV0ZXIgaXMgZGVmaW5lZCBhczoNCj4+ Pg0KPj4+ICAgICAgICAgICAgIGxvY2F0aW9uLXNvdXJjZSA9ICJsb2Mtc3JjPSIgKGhvc3QgLyBv dGhlci1sb2Mtc3JjKQ0KPj4+ICAgICAgICAgICAgIG90aGVyLWxvYy1zcmMgPSB0b2tlbg0KPj4+ DQo+Pj4gQnV0IHRoZXJlIGlzIG5vIGRlZmluaXRpb24gb2YgJ2hvc3QnLiBJIHRoaW5rIHRoZSBk ZWZpbml0aW9uIHlvdSBhcmUgDQo+Pj4gaW50ZW5kaW5nIGlzIGFjdHVhbGx5ICdob3N0bmFtZScg YXMgZGVmaW5lZCBpbiAzMjYxLg0KPj4+DQo+Pj4gQWxzbywgaWYgIk9ubHkgYSBmdWxseSBxdWFs aWZpZWQgaG9zdCBuYW1lIGlzIHZhbGlkIiB0aGVuIHdoYXQgaXMgDQo+Pj4gdGhlIHBvaW50IG9m ICdvdGhlci1sb2Mtc3JjJz8NCj4+Pg0KPj4+IFNvIEkgd291bGQgc3VnZ2VzdDoNCj4+Pg0KPj4+ ICAgICAgICAgICAgIGxvY2F0aW9uLXNvdXJjZSA9ICJsb2Mtc3JjPSIgaG9zdG5hbWUNCj4+PiAg ICAgICAgICAgICBob3N0bmFtZSA9IDxkZWZpbmVkIGluIFJGQzMyNjE+DQo+Pj4NCj4+PiAJVGhh bmtzLA0KPj4+IAlQYXVsDQo+Pj4NCj4+Pg0KPj4+IE9uIDkvMjAvMTcgMTowOSBBTSwgSmVzc2tl LCBSb2xhbmQgd3JvdGU6DQo+Pj4+IERlYXIgYWxsLA0KPj4+Pg0KPj4+PiBzaW5jZSBJIGRpZCBu b3QgZ2V0IGFueSBjb21tZW50cyBvbiBvdXIgZHJhZnQgaXQgbG9vayBmb3IgbWUgdGhhdCANCj4+ Pj4gcGVvcGxlIGFyZSBoYXBweSB3aXRoIHRoZSBjb250ZW50Lg0KPj4+Pg0KPj4+PiBTbyBJIHdv dWxkIGxpa2UgdG8gYXNrIHRoZSBncm91cCBmb3IgYWRvcHRpb24gb2YgdGhpcyBkcmFmdC4NCj4+ Pj4NCj4+Pj4gQmVzdCBSZWdhcmRzDQo+Pj4+DQo+Pj4+IFJvbGFuZA0KPj4+Pg0KPj4+PiAqVm9u OipzaXBjb3JlIFttYWlsdG86c2lwY29yZS1ib3VuY2VzQGlldGYub3JnXSAqSW0gQXVmdHJhZyB2 b24gDQo+Pj4+ICpKZXNza2UsIFJvbGFuZA0KPj4+PiAqR2VzZW5kZXQ6KiBEaWVuc3RhZywgMjku IEF1Z3VzdCAyMDE3IDEwOjU5DQo+Pj4+ICpBbjoqIHNpcGNvcmVAaWV0Zi5vcmcNCj4+Pj4gKkJl dHJlZmY6KiBbc2lwY29yZV0gZHJhZnQtd2ludGVyYm90dG9tLXNpcGNvcmUtbG9jcGFyYW0tMDEu dHh0IGFuZCANCj4+Pj4gTGlhaXNvbiBTdGF0ZW1lbnQgdG8gSUVURiBvbiBsb2NhdGlvbiBzb3Vy Y2UgcGFyYW1ldGVyDQo+Pj4+DQo+Pj4+IERlYXIgYWxsLA0KPj4+Pg0KPj4+PiBzaW5jZSBJIGhh dmUgdXBsb2FkZWQgdGhlIGxhdGVzdCBkcmFmdCBvbiANCj4+Pj4gZHJhZnQtd2ludGVyYm90dG9t LXNpcGNvcmUtbG9jcGFyYW0tMDEudHh0IGFuZCB0aGUgbGFzdCANCj4+Pj4gY2xhcmlmaWNhdGlv biBvbiBxdWVzdGlvbnMgd2VyZSBnaXZlbiBvbiAyMy4gTWF5IEkgZGlkIG5vdCBnZXQgYW55IA0K Pj4+PiBmdXJ0aGVyDQo+PiBjb21tZW50Lg0KPj4+Pg0KPj4+PiBXaXRoIGEgcmVmZXJlbmNlIHRv IHRoaXMgZHJhZnQgYSBMaWFpc29uIGZyb20gRVRTSSAoIA0KPj4+PiBodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2xpYWlzb24vMTUyNy8gKSBpcyB3YWl0aW5nIGZvciBhY3Rpb24uDQo+Pj4+ DQo+Pj4+IFRoZSBsaWFpc29uIGZyb20gRVRTSSBpcyBhc2tpbmcgb24gdGhlIHByb2dyZXNzIG9m IHRoZSBkcmFmdCBmb3IgDQo+Pj4+IHRoZWlyIHNvbHV0aW9uIG9uIEVtZXJnZW5jeSBDYWxsIGR1 ZSB0byB0aGUgUHJvamVjdCBvZsKgIHRoZSANCj4+Pj4gRXVyb3BlYW4gVW5pb24NCj4+Pj4gTWFu ZGF0ZTogTTQ5My4NCj4+Pj4NCj4+Pj4gTXkgcXVlc3Rpb24gaXMsIHNpbmNlIHdlIGhhdmUgbm8g b3BlbiBxdWVzdGlvbnMsIGlmIHdlIGNhbiBub3cgDQo+Pj4+IHByb2dyZXNzIHRoZSBkcmFmdC4N Cj4+Pj4NCj4+Pj4gVGhhbmsgeW91IGZvciBjb25zaWRlcmF0aW9uLg0KPj4+Pg0KPj4+PiBCZXN0 IFJlZ2FyZHMNCj4+Pj4NCj4+Pj4gUm9sYW5kDQo+Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+IHNpcGNvcmUg bWFpbGluZyBsaXN0DQo+Pj4+IHNpcGNvcmVAaWV0Zi5vcmcNCj4+Pj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlDQo+Pj4+DQo+Pj4NCj4+PiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+IHNpcGNvcmUgbWFpbGlu ZyBsaXN0DQo+Pj4gc2lwY29yZUBpZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc2lwY29yZQ0KPj4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+PiBzaXBjb3JlIG1haWxpbmcgbGlzdA0KPj4gc2lwY29y ZUBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBj b3JlDQo+IA0KPiANCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCnNpcGNvcmUgbWFpbGluZyBsaXN0DQpzaXBjb3JlQGlldGYub3JnDQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCg== From nobody Fri Sep 22 12:16:44 2017 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 F11E312895E for ; Fri, 22 Sep 2017 12:16:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 gUBBnNzA_eyp for ; Fri, 22 Sep 2017 12:16:41 -0700 (PDT) Received: from alum-mailsec-scanner-5.mit.edu (alum-mailsec-scanner-5.mit.edu [18.7.68.17]) by ietfa.amsl.com (Postfix) with ESMTP id D336E124207 for ; Fri, 22 Sep 2017 12:16:40 -0700 (PDT) X-AuditID: 12074411-f7dff70000007f0a-59-59c56197780a Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id B7.39.32522.79165C95; Fri, 22 Sep 2017 15:16:40 -0400 (EDT) Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id v8MJGc8s029311 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 22 Sep 2017 15:16:39 -0400 To: Christer Holmberg , "Jesske, Roland" , "Asveren, Tolga" , "sipcore@ietf.org" Cc: James Winterbottom References: <87cf2edcef014e268e000ef358cc3c2c@HE105828.emea1.cds.t-internal.com> <6e9d3dd7-0c23-2896-8b3b-80bfdd462b92@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B562F0504@ESESSMB109.ericsson.se> From: Paul Kyzivat Message-ID: <3f9dcb36-791c-6ce8-801c-49cce1a4772b@alum.mit.edu> Date: Fri, 22 Sep 2017 15:16:38 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B562F0504@ESESSMB109.ericsson.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrAKsWRmVeSWpSXmKPExsUixO6iqDsj8Wikwdt17Bb3Nv1ksbgw8zCj RdOdLjaLrz82sVnM7nzP5MDq8evrVTaPnbPusnssWfKTyePS5//sHm0vFQJYo7hsUlJzMstS i/TtErgyjrT/ZinYrFvx53hgA+NllS5GTg4JAROJ6y9Xs4PYQgI7mCR+zKvpYuQCsh8ySTyc 2sgCkhAWqJOY/OIsG4gtInCGUeLYIgcQm1nAXKL5fAcjRMNJFonuLReYQBJsAloScw79B2rm 4OAVsJd4czARJMwioCrx/sd+sGWiAmkS/3afZQSxeQUEJU7OfAK2i1PAT2LZ5idsEPPNJOZt fsgMYYtL3HoynwnClpdo3jqbeQKjwCwk7bOQtMxC0jILScsCRpZVjHKJOaW5urmJmTnFqcm6 xcmJeXmpRbqmermZJXqpKaWbGCGBL7iDccZJuUOMAhyMSjy8L5yPRgqxJpYVV+YeYpTkYFIS 5VVOAArxJeWnVGYkFmfEF5XmpBYfYpTgYFYS4b3vB5TjTUmsrEotyodJSXOwKInz8i1R9xMS SE8sSc1OTS1ILYLJynBwKEnwzgIZKliUmp5akZaZU4KQZuLgBBnOAzT8dRzI8OKCxNzizHSI /ClGXY6enht/mIRY8vLzUqXEeVtABgmAFGWU5sHNgSWsV4ziQG8J8yaDVPEAkx3cpFdAS5iA lpSvPgKypCQRISXVwBi//3XKoeJ+QcEQlS+s4Y9X/Xu7tFj4S8Ye9hO/XRacL7SuM9hzTeQf n+xzv9+uc/9vFlhb+sM6crnK6QfeQl2+Oeazbb1lT91aeWuS/88LO2x/lJx7uDRm0hTDeyWn pG9LXWsPuNhn9HNFj/aqjuSLTla/vopFT1dkLtqwPGxZQGgsz2+Pn0uVWIozEg21mIuKEwFG oeCBMwMAAA== Archived-At: Subject: Re: [sipcore] draft-winterbottom-sipcore-locparam-01.txt and Liaison Statement to IETF on location source parameter X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Sep 2017 19:16:43 -0000 On 9/22/17 1:21 PM, Christer Holmberg wrote: > Hi, > >>> Also to address Pauls comment complete. I would propose then the following: >>> >>> >>> location-source = "loc-src=" (hostname / other-loc-src) >>> hostname = >>> other-loc-src = token >>> >>> Figure 1: Location Source >> >> I'll be ok with this if you also include some text about the intent of other-loc-src. Is it >intended only as a hook for future extension - requiring another document to define that >usage? What should a recipient do if they receive this with something matching other-loc->src and don't understand that usage? > > As I indicated in my comments, I'd like to see some justification on why we mandate a FQDN to begin with. As opposed to *what*? Surely there ought to be some semantics to this. I presume it is to be an identifier of something, and presumably there then need to be rules for resolution/comparison/etc. Otherwise I could just enter XYZZY. Thanks, Paul > Regards, > > Christer > > > >>> -----Ursprüngliche Nachricht----- >>> Von: Asveren, Tolga [mailto:tasveren@sonusnet.com] >>> Gesendet: Freitag, 22. September 2017 08:24 >>> An: Jesske, Roland ; Paul Kyzivat >>> ; sipcore@ietf.org >>> Cc: James Winterbottom >>> Betreff: RE: [sipcore] draft-winterbottom-sipcore-locparam-01.txt and >>> Liaison Statement to IETF on location source parameter >>> >>> I would prefer to keep the existing syntax. Not that I have an >>> immediate use case at hand but you never know what future would >>> bring. And it would be a pity to have an extension draft just for something like this. >>> >>> Thanks, >>> Tolga >>> >>> -----Original Message----- >>> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Jesske, >>> Roland >>> Sent: Friday, September 22, 2017 1:30 AM >>> To: Paul Kyzivat ; sipcore@ietf.org >>> Cc: James Winterbottom >>> Subject: Re: [sipcore] draft-winterbottom-sipcore-locparam-01.txt and >>> Liaison Statement to IETF on location source parameter >>> >>> Hi Paul, >>> Thank you for your comment. >>> The addition of other-loc-src was discussed in the past and was added >>> due to some requests not to restrict this parameter to a hostname. >>> ETSI does only needs a hostname. >>> >>> So I have nothing against to change it as you have proposed it. >>> So If other people would like to keep this please speak up. >>> >>> Thank you and Best Regards >>> >>> Roland >>> >>> >>> >>>> -----Ursprüngliche Nachricht----- >>>> Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von Paul >>>> Kyzivat >>>> Gesendet: Mittwoch, 20. September 2017 21:12 >>>> An: sipcore@ietf.org >>>> Betreff: Re: [sipcore] draft-winterbottom-sipcore-locparam-01.txt >>>> and Liaison Statement to IETF on location source parameter >>>> >>>> I'm ok with adopting this. >>>> >>>> A minor point on the content: >>>> >>>> The syntax of the new parameter is defined as: >>>> >>>> location-source = "loc-src=" (host / other-loc-src) >>>> other-loc-src = token >>>> >>>> But there is no definition of 'host'. I think the definition you are >>>> intending is actually 'hostname' as defined in 3261. >>>> >>>> Also, if "Only a fully qualified host name is valid" then what is >>>> the point of 'other-loc-src'? >>>> >>>> So I would suggest: >>>> >>>> location-source = "loc-src=" hostname >>>> hostname = >>>> >>>> Thanks, >>>> Paul >>>> >>>> >>>> On 9/20/17 1:09 AM, Jesske, Roland wrote: >>>>> Dear all, >>>>> >>>>> since I did not get any comments on our draft it look for me that >>>>> people are happy with the content. >>>>> >>>>> So I would like to ask the group for adoption of this draft. >>>>> >>>>> Best Regards >>>>> >>>>> Roland >>>>> >>>>> *Von:*sipcore [mailto:sipcore-bounces@ietf.org] *Im Auftrag von >>>>> *Jesske, Roland >>>>> *Gesendet:* Dienstag, 29. August 2017 10:59 >>>>> *An:* sipcore@ietf.org >>>>> *Betreff:* [sipcore] draft-winterbottom-sipcore-locparam-01.txt and >>>>> Liaison Statement to IETF on location source parameter >>>>> >>>>> Dear all, >>>>> >>>>> since I have uploaded the latest draft on >>>>> draft-winterbottom-sipcore-locparam-01.txt and the last >>>>> clarification on questions were given on 23. May I did not get any >>>>> further >>> comment. >>>>> >>>>> With a reference to this draft a Liaison from ETSI ( >>>>> https://datatracker.ietf.org/liaison/1527/ ) is waiting for action. >>>>> >>>>> The liaison from ETSI is asking on the progress of the draft for >>>>> their solution on Emergency Call due to the Project of  the >>>>> European Union >>>>> Mandate: M493. >>>>> >>>>> My question is, since we have no open questions, if we can now >>>>> progress the draft. >>>>> >>>>> Thank you for consideration. >>>>> >>>>> Best Regards >>>>> >>>>> Roland >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >>> _______________________________________________ >>> 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 Fri Sep 22 12:31:30 2017 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 58E271345B2 for ; Fri, 22 Sep 2017 12:31: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 oaFB7NxZqXnf for ; Fri, 22 Sep 2017 12:31:26 -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 0E19D1321BB for ; Fri, 22 Sep 2017 12:31:25 -0700 (PDT) X-AuditID: c1b4fb3a-617ff700000051a3-58-59c5650c2450 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id AF.13.20899.C0565C95; Fri, 22 Sep 2017 21:31:24 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.6]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0352.000; Fri, 22 Sep 2017 21:31:23 +0200 From: Christer Holmberg To: Paul Kyzivat , "Jesske, Roland" , "Asveren, Tolga" , "sipcore@ietf.org" CC: James Winterbottom Thread-Topic: [sipcore] draft-winterbottom-sipcore-locparam-01.txt and Liaison Statement to IETF on location source parameter Thread-Index: AdMgpPpaGGJ4RYVmTLCLOQ8COa0QNgRKYIsgABlDKYAAR+STAAAB4NyAAAb+OoAACFJrAAALyEVA////FAD//9vp0A== Date: Fri, 22 Sep 2017 19:31:22 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B562F083C@ESESSMB109.ericsson.se> References: <87cf2edcef014e268e000ef358cc3c2c@HE105828.emea1.cds.t-internal.com> <6e9d3dd7-0c23-2896-8b3b-80bfdd462b92@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B562F0504@ESESSMB109.ericsson.se> <3f9dcb36-791c-6ce8-801c-49cce1a4772b@alum.mit.edu> In-Reply-To: <3f9dcb36-791c-6ce8-801c-49cce1a4772b@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.154] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBIsWRmVeSWpSXmKPExsUyM2K7qy5P6tFIgyXfxS3ubfrJYrFiwwFW i6Y7XWwWX39sYrOY3fmeyYHV4+/7D0weO2fdZfdYsuQnk8elz//ZPdpeKgSwRnHZpKTmZJal FunbJXBlLOw5z1ywxqHi2ePbbA2MN+y6GDk5JARMJDavaGYEsYUEjjBKtE+O7GLkArIXMUrM nnmdqYuRg4NNwEKi+582SFxEYCmjxNrVfUwgDcwC5hLP27cyg9jCAnUSe7q6wGwRgXqJD8u2 s0DYWRKr/q1gB7FZBFQlnk7fC7aMV8BXYuuOt2wQy/6zSEzddgKsmVPAQeLVmWOsIDajgJjE 91NroJaJS9x6Mp8J4moBiSV7zjND2KISLx//Y4WwlSQW3f4MdjSzgKbE+l36EK2KElO6H7JD 7BWUODnzCcsERtFZSKbOQuiYhaRjFpKOBYwsqxhFi1OLi3PTjYz0Uosyk4uL8/P08lJLNjEC 4+vglt9WOxgPPnc8xCjAwajEw3sg+WikEGtiWXFl7iFGCQ5mJRHevYlAId6UxMqq1KL8+KLS nNTiQ4zSHCxK4rwO+y5ECAmkJ5akZqemFqQWwWSZODilGhinRB48kqJ/p36+asnl+U9P/IvS nmWitUI8uH/nPX+5+6ZTeds/flKffXhKGm+5wbTj8n/yMtZc1bi/t97g5M1yzwlhp/J+FAZe VlZ0qky/aDjbk2Xv1e5g9aNP80Krj3z91fNAed3llF9he59r6J3YdLtW7P3dvAQr2YU912b8 3KH7Q8f49rkKJZbijERDLeai4kQAfOsoVqsCAAA= Archived-At: Subject: Re: [sipcore] draft-winterbottom-sipcore-locparam-01.txt and Liaison Statement to IETF on location source parameter X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Sep 2017 19:31:28 -0000 SGksDQoNCj4+Pj4gQWxzbyB0byBhZGRyZXNzIFBhdWxzIGNvbW1lbnQgY29tcGxldGUuIEkgd291 bGQgcHJvcG9zZSB0aGVuIHRoZSBmb2xsb3dpbmc6DQo+Pj4+DQo+Pj4+DQo+Pj4+ICAgICAgICAg ICAgIGxvY2F0aW9uLXNvdXJjZSA9ICJsb2Mtc3JjPSIgKGhvc3RuYW1lIC8gb3RoZXItbG9jLXNy YykNCj4+Pj4gICAgICAgICAgICAgaG9zdG5hbWUgPSA8ZGVmaW5lZCBpbiBSRkMzMjYxPg0KPj4+ PiAgICAgICAgICAgICBvdGhlci1sb2Mtc3JjID0gdG9rZW4NCj4+Pj4NCj4+Pj4gICAgICAgICAg ICAgICAgICAgICAgICAgICAgRmlndXJlIDE6IExvY2F0aW9uIFNvdXJjZQ0KPj4+DQo+Pj4gSSds bCBiZSBvayB3aXRoIHRoaXMgaWYgeW91IGFsc28gaW5jbHVkZSBzb21lIHRleHQgYWJvdXQgdGhl IGludGVudCBvZiBvdGhlci1sb2Mtc3JjLiBJcyBpdCBpbnRlbmRlZCBvbmx5IGFzIGEgaG9vayBm b3IgZnV0dXJlIGV4dGVuc2lvbiAtIHJlcXVpcmluZyBhbm90aGVyIGRvY3VtZW50IHRvIA0KPj4+ IGRlZmluZSB0aGF0IHVzYWdlPyBXaGF0IHNob3VsZCBhIHJlY2lwaWVudCBkbyBpZiB0aGV5IHJl Y2VpdmUgdGhpcyB3aXRoIHNvbWV0aGluZyBtYXRjaGluZyBvdGhlci1sb2MtPnNyYyBhbmQgZG9u J3QgdW5kZXJzdGFuZCB0aGF0IHVzYWdlPw0KPj4gDQo+PiBBcyBJIGluZGljYXRlZCBpbiBteSBj b21tZW50cywgSSdkIGxpa2UgdG8gc2VlIHNvbWUganVzdGlmaWNhdGlvbiBvbiB3aHkgd2UgbWFu ZGF0ZSBhIEZRRE4gdG8gYmVnaW4gd2l0aC4NCj4NCj4gQXMgb3Bwb3NlZCB0byAqd2hhdCo/DQo+ DQo+IFN1cmVseSB0aGVyZSBvdWdodCB0byBiZSBzb21lIHNlbWFudGljcyB0byB0aGlzLiBJIHBy ZXN1bWUgaXQgaXMgdG8gYmUgYW4gaWRlbnRpZmllciBvZiBzb21ldGhpbmcsIGFuZCBwcmVzdW1h Ymx5IHRoZXJlIHRoZW4gbmVlZCB0byBiZSBydWxlcyBmb3IgDQo+IHJlc29sdXRpb24vY29tcGFy aXNvbi9ldGMuDQoNCkJhc2VkIG9uIG15IHVuZGVyc3RhbmRpbmcgb2YgdGhlIGRyYWZ0IChwbGVh c2UgY29ycmVjdCBtZSBpZiBJJ20gd3JvbmcpLCBpdCdzIG9ubHkgYW4gaWRlbnRpZmllciB3aXRo aW4gYSB0cnVzdCBkb21haW4uIFdoYXQgbWF0dGVycyBpcyB0aGF0IGVudGl0aWVzIHdpdGhpbiB0 aGF0IHRydXN0IGRvbWFpbiB1bmRlcnN0YW5kIHRoZSBzZW1hbnRpY3MuDQoNCkJ1dCwgYXNzdW1p bmcgd2Ugd2FudCBzb21ldGhpbmcgInJlYWwiLCB3aHkgaXMgYW4gSVAgYWRkcmVzcyBub3QgYWxs b3dlZD8NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQoNCg0KPj4+IC0tLS0tVXJzcHLDvG5n bGljaGUgTmFjaHJpY2h0LS0tLS0NCj4+PiBWb246IEFzdmVyZW4sIFRvbGdhIFttYWlsdG86dGFz dmVyZW5Ac29udXNuZXQuY29tXQ0KPj4+IEdlc2VuZGV0OiBGcmVpdGFnLCAyMi4gU2VwdGVtYmVy IDIwMTcgMDg6MjQNCj4+PiBBbjogSmVzc2tlLCBSb2xhbmQgPFIuSmVzc2tlQHRlbGVrb20uZGU+ OyBQYXVsIEt5eml2YXQgDQo+Pj4gPHBreXppdmF0QGFsdW0ubWl0LmVkdT47IHNpcGNvcmVAaWV0 Zi5vcmcNCj4+PiBDYzogSmFtZXMgV2ludGVyYm90dG9tIDxhLmphbWVzLndpbnRlcmJvdHRvbUBn bWFpbC5jb20+DQo+Pj4gQmV0cmVmZjogUkU6IFtzaXBjb3JlXSBkcmFmdC13aW50ZXJib3R0b20t c2lwY29yZS1sb2NwYXJhbS0wMS50eHQgDQo+Pj4gYW5kIExpYWlzb24gU3RhdGVtZW50IHRvIElF VEYgb24gbG9jYXRpb24gc291cmNlIHBhcmFtZXRlcg0KPj4+DQo+Pj4gSSB3b3VsZCBwcmVmZXIg dG8ga2VlcCB0aGUgZXhpc3Rpbmcgc3ludGF4LiBOb3QgdGhhdCBJIGhhdmUgYW4gDQo+Pj4gaW1t ZWRpYXRlIHVzZSBjYXNlIGF0IGhhbmQgYnV0IHlvdSBuZXZlciBrbm93IHdoYXQgZnV0dXJlIHdv dWxkIA0KPj4+IGJyaW5nLiBBbmQgaXQgd291bGQgYmUgYSBwaXR5IHRvIGhhdmUgYW4gZXh0ZW5z aW9uIGRyYWZ0IGp1c3QgZm9yIHNvbWV0aGluZyBsaWtlIHRoaXMuDQo+Pj4NCj4+PiBUaGFua3Ms DQo+Pj4gVG9sZ2ENCj4+Pg0KPj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4gRnJv bTogc2lwY29yZSBbbWFpbHRvOnNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IEplc3NrZSwgDQo+Pj4gUm9sYW5kDQo+Pj4gU2VudDogRnJpZGF5LCBTZXB0ZW1iZXIgMjIsIDIw MTcgMTozMCBBTQ0KPj4+IFRvOiBQYXVsIEt5eml2YXQgPHBreXppdmF0QGFsdW0ubWl0LmVkdT47 IHNpcGNvcmVAaWV0Zi5vcmcNCj4+PiBDYzogSmFtZXMgV2ludGVyYm90dG9tIDxhLmphbWVzLndp bnRlcmJvdHRvbUBnbWFpbC5jb20+DQo+Pj4gU3ViamVjdDogUmU6IFtzaXBjb3JlXSBkcmFmdC13 aW50ZXJib3R0b20tc2lwY29yZS1sb2NwYXJhbS0wMS50eHQgDQo+Pj4gYW5kIExpYWlzb24gU3Rh dGVtZW50IHRvIElFVEYgb24gbG9jYXRpb24gc291cmNlIHBhcmFtZXRlcg0KPj4+DQo+Pj4gSGkg UGF1bCwNCj4+PiBUaGFuayB5b3UgZm9yIHlvdXIgY29tbWVudC4NCj4+PiBUaGUgYWRkaXRpb24g b2Ygb3RoZXItbG9jLXNyYyB3YXMgZGlzY3Vzc2VkIGluIHRoZSBwYXN0IGFuZCB3YXMgDQo+Pj4g YWRkZWQgZHVlIHRvIHNvbWUgcmVxdWVzdHMgbm90IHRvIHJlc3RyaWN0IHRoaXMgcGFyYW1ldGVy IHRvIGEgaG9zdG5hbWUuDQo+Pj4gRVRTSSBkb2VzIG9ubHkgbmVlZHMgYSBob3N0bmFtZS4NCj4+ Pg0KPj4+IFNvIEkgaGF2ZSBub3RoaW5nIGFnYWluc3QgdG8gY2hhbmdlIGl0IGFzIHlvdSBoYXZl IHByb3Bvc2VkIGl0Lg0KPj4+IFNvIElmIG90aGVyIHBlb3BsZSB3b3VsZCBsaWtlIHRvIGtlZXAg dGhpcyBwbGVhc2Ugc3BlYWsgdXAuDQo+Pj4NCj4+PiBUaGFuayB5b3UgYW5kIEJlc3QgUmVnYXJk cw0KPj4+DQo+Pj4gUm9sYW5kDQo+Pj4NCj4+Pg0KPj4+DQo+Pj4+IC0tLS0tVXJzcHLDvG5nbGlj aGUgTmFjaHJpY2h0LS0tLS0NCj4+Pj4gVm9uOiBzaXBjb3JlIFttYWlsdG86c2lwY29yZS1ib3Vu Y2VzQGlldGYub3JnXSBJbSBBdWZ0cmFnIHZvbiBQYXVsIA0KPj4+PiBLeXppdmF0DQo+Pj4+IEdl c2VuZGV0OiBNaXR0d29jaCwgMjAuIFNlcHRlbWJlciAyMDE3IDIxOjEyDQo+Pj4+IEFuOiBzaXBj b3JlQGlldGYub3JnDQo+Pj4+IEJldHJlZmY6IFJlOiBbc2lwY29yZV0gZHJhZnQtd2ludGVyYm90 dG9tLXNpcGNvcmUtbG9jcGFyYW0tMDEudHh0DQo+Pj4+IGFuZCBMaWFpc29uIFN0YXRlbWVudCB0 byBJRVRGIG9uIGxvY2F0aW9uIHNvdXJjZSBwYXJhbWV0ZXINCj4+Pj4NCj4+Pj4gSSdtIG9rIHdp dGggYWRvcHRpbmcgdGhpcy4NCj4+Pj4NCj4+Pj4gQSBtaW5vciBwb2ludCBvbiB0aGUgY29udGVu dDoNCj4+Pj4NCj4+Pj4gVGhlIHN5bnRheCBvZiB0aGUgbmV3IHBhcmFtZXRlciBpcyBkZWZpbmVk IGFzOg0KPj4+Pg0KPj4+PiAgICAgICAgICAgICAgbG9jYXRpb24tc291cmNlID0gImxvYy1zcmM9 IiAoaG9zdCAvIG90aGVyLWxvYy1zcmMpDQo+Pj4+ICAgICAgICAgICAgICBvdGhlci1sb2Mtc3Jj ID0gdG9rZW4NCj4+Pj4NCj4+Pj4gQnV0IHRoZXJlIGlzIG5vIGRlZmluaXRpb24gb2YgJ2hvc3Qn LiBJIHRoaW5rIHRoZSBkZWZpbml0aW9uIHlvdSANCj4+Pj4gYXJlIGludGVuZGluZyBpcyBhY3R1 YWxseSAnaG9zdG5hbWUnIGFzIGRlZmluZWQgaW4gMzI2MS4NCj4+Pj4NCj4+Pj4gQWxzbywgaWYg Ik9ubHkgYSBmdWxseSBxdWFsaWZpZWQgaG9zdCBuYW1lIGlzIHZhbGlkIiB0aGVuIHdoYXQgaXMg DQo+Pj4+IHRoZSBwb2ludCBvZiAnb3RoZXItbG9jLXNyYyc/DQo+Pj4+DQo+Pj4+IFNvIEkgd291 bGQgc3VnZ2VzdDoNCj4+Pj4NCj4+Pj4gICAgICAgICAgICAgIGxvY2F0aW9uLXNvdXJjZSA9ICJs b2Mtc3JjPSIgaG9zdG5hbWUNCj4+Pj4gICAgICAgICAgICAgIGhvc3RuYW1lID0gPGRlZmluZWQg aW4gUkZDMzI2MT4NCj4+Pj4NCj4+Pj4gCVRoYW5rcywNCj4+Pj4gCVBhdWwNCj4+Pj4NCj4+Pj4N Cj4+Pj4gT24gOS8yMC8xNyAxOjA5IEFNLCBKZXNza2UsIFJvbGFuZCB3cm90ZToNCj4+Pj4+IERl YXIgYWxsLA0KPj4+Pj4NCj4+Pj4+IHNpbmNlIEkgZGlkIG5vdCBnZXQgYW55IGNvbW1lbnRzIG9u IG91ciBkcmFmdCBpdCBsb29rIGZvciBtZSB0aGF0IA0KPj4+Pj4gcGVvcGxlIGFyZSBoYXBweSB3 aXRoIHRoZSBjb250ZW50Lg0KPj4+Pj4NCj4+Pj4+IFNvIEkgd291bGQgbGlrZSB0byBhc2sgdGhl IGdyb3VwIGZvciBhZG9wdGlvbiBvZiB0aGlzIGRyYWZ0Lg0KPj4+Pj4NCj4+Pj4+IEJlc3QgUmVn YXJkcw0KPj4+Pj4NCj4+Pj4+IFJvbGFuZA0KPj4+Pj4NCj4+Pj4+ICpWb246KnNpcGNvcmUgW21h aWx0bzpzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmddICpJbSBBdWZ0cmFnIHZvbiANCj4+Pj4+ICpK ZXNza2UsIFJvbGFuZA0KPj4+Pj4gKkdlc2VuZGV0OiogRGllbnN0YWcsIDI5LiBBdWd1c3QgMjAx NyAxMDo1OQ0KPj4+Pj4gKkFuOiogc2lwY29yZUBpZXRmLm9yZw0KPj4+Pj4gKkJldHJlZmY6KiBb c2lwY29yZV0gZHJhZnQtd2ludGVyYm90dG9tLXNpcGNvcmUtbG9jcGFyYW0tMDEudHh0IA0KPj4+ Pj4gYW5kIExpYWlzb24gU3RhdGVtZW50IHRvIElFVEYgb24gbG9jYXRpb24gc291cmNlIHBhcmFt ZXRlcg0KPj4+Pj4NCj4+Pj4+IERlYXIgYWxsLA0KPj4+Pj4NCj4+Pj4+IHNpbmNlIEkgaGF2ZSB1 cGxvYWRlZCB0aGUgbGF0ZXN0IGRyYWZ0IG9uIA0KPj4+Pj4gZHJhZnQtd2ludGVyYm90dG9tLXNp cGNvcmUtbG9jcGFyYW0tMDEudHh0IGFuZCB0aGUgbGFzdCANCj4+Pj4+IGNsYXJpZmljYXRpb24g b24gcXVlc3Rpb25zIHdlcmUgZ2l2ZW4gb24gMjMuIE1heSBJIGRpZCBub3QgZ2V0IGFueSANCj4+ Pj4+IGZ1cnRoZXINCj4+PiBjb21tZW50Lg0KPj4+Pj4NCj4+Pj4+IFdpdGggYSByZWZlcmVuY2Ug dG8gdGhpcyBkcmFmdCBhIExpYWlzb24gZnJvbSBFVFNJICggDQo+Pj4+PiBodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2xpYWlzb24vMTUyNy8gKSBpcyB3YWl0aW5nIGZvciBhY3Rpb24uDQo+ Pj4+Pg0KPj4+Pj4gVGhlIGxpYWlzb24gZnJvbSBFVFNJIGlzIGFza2luZyBvbiB0aGUgcHJvZ3Jl c3Mgb2YgdGhlIGRyYWZ0IGZvciANCj4+Pj4+IHRoZWlyIHNvbHV0aW9uIG9uIEVtZXJnZW5jeSBD YWxsIGR1ZSB0byB0aGUgUHJvamVjdCBvZsKgIHRoZSANCj4+Pj4+IEV1cm9wZWFuIFVuaW9uDQo+ Pj4+PiBNYW5kYXRlOiBNNDkzLg0KPj4+Pj4NCj4+Pj4+IE15IHF1ZXN0aW9uIGlzLCBzaW5jZSB3 ZSBoYXZlIG5vIG9wZW4gcXVlc3Rpb25zLCBpZiB3ZSBjYW4gbm93IA0KPj4+Pj4gcHJvZ3Jlc3Mg dGhlIGRyYWZ0Lg0KPj4+Pj4NCj4+Pj4+IFRoYW5rIHlvdSBmb3IgY29uc2lkZXJhdGlvbi4NCj4+ Pj4+DQo+Pj4+PiBCZXN0IFJlZ2FyZHMNCj4+Pj4+DQo+Pj4+PiBSb2xhbmQNCj4+Pj4+DQo+Pj4+ Pg0KPj4+Pj4NCj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+Pj4+PiBzaXBjb3JlIG1haWxpbmcgbGlzdA0KPj4+Pj4gc2lwY29yZUBpZXRmLm9y Zw0KPj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlDQo+ Pj4+Pg0KPj4+Pg0KPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPj4+PiBzaXBjb3JlIG1haWxpbmcgbGlzdA0KPj4+PiBzaXBjb3JlQGlldGYub3Jn DQo+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZQ0KPj4+ DQo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ PiBzaXBjb3JlIG1haWxpbmcgbGlzdA0KPj4+IHNpcGNvcmVAaWV0Zi5vcmcNCj4+PiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCj4+DQo+Pg0KPiANCj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gc2lwY29yZSBt YWlsaW5nIGxpc3QNCj4gc2lwY29yZUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCj4gDQoNCg== From nobody Fri Sep 22 19:27:11 2017 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 6F8F5124F57 for ; Fri, 22 Sep 2017 19:27:10 -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 qEqXdKujM4Du for ; Fri, 22 Sep 2017 19:27:09 -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 8087B1321C9 for ; Fri, 22 Sep 2017 19:27:09 -0700 (PDT) Received: from resomta-ch2-08v.sys.comcast.net ([69.252.207.104]) by resqmta-ch2-02v.sys.comcast.net with ESMTP id va9ndC1d6Sim6va9sdvQIL; Sat, 23 Sep 2017 02:27:08 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-08v.sys.comcast.net with SMTP id va9rdA4fLXNPSva9rdWf06; Sat, 23 Sep 2017 02:27:08 +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 v8N2R6OT026221; Fri, 22 Sep 2017 22:27:06 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v8N2R606026218; Fri, 22 Sep 2017 22:27:06 -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: Paul Kyzivat Cc: R.Jesske@telekom.de, sipcore@ietf.org In-Reply-To: <12f8d596-49b2-78f0-bf10-832736d10902@alum.mit.edu> (pkyzivat@alum.mit.edu) Sender: worley@ariadne.com (Dale R. Worley) Date: Fri, 22 Sep 2017 22:27:06 -0400 Message-ID: <87tvzub151.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfGU5Si7hrm/ALRX82NmoR9VDG2VUeGIL5XAkpU+KZAfiFEw0LtmeYDbWaRrzqYB/xmoMVzetwGSTOnPSiqbq7+jrM+b6HmyoZ9xPloJfvIGItdbL5xCd FY6Rhrujz0l/2Ipu/LX4n9iSBGjM18pcB/gvCOe73M4HUQ/deo2FupIfYhuEboY6YiJDAOaznlLua2EhcJXi+nyyFIzTGpgbjexMx3VeSDih4oqb9/wP0qOx Archived-At: Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-reason-q850-loc-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Sep 2017 02:27:10 -0000 Paul Kyzivat writes: > Instead of that, how about just defining some tokens now for all the > other code points. (E.g. NATIONAL-1, NATIONOAL-2, ... , RESERVED-1, > RESERVED-2, ... *or* values that correspond directly to the binary > coding, such as LOC-12, LOC-13, LOC-14, LOC-15). That way, if > interworking comes across one of those it can be mapped bidirectionally > to SIP. I can see the advantage of providing tokens for all of the Q.850 values, because as Paul says, somebody might be using them within a network. As Roland says, the Q.850 *system* is unlikely to be changed in the future, so we can provide a complete set of translations of all possible values. If somebody is using these values, they can interwork with SIP without asking either ITU-T or the IETF to provide a mapping. Dale From nobody Sun Sep 24 19:27:39 2017 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 CAD6C126B7E for ; Sun, 24 Sep 2017 19:27:36 -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 nlnQy4vDocHu for ; Sun, 24 Sep 2017 19:27:36 -0700 (PDT) Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (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 EF9CD126B6D for ; Sun, 24 Sep 2017 19:27:35 -0700 (PDT) Received: from resomta-ch2-11v.sys.comcast.net ([69.252.207.107]) by resqmta-ch2-08v.sys.comcast.net with ESMTP id wJ74dCEBE0RWWwJ7OdiXYx; Mon, 25 Sep 2017 02:27:34 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-11v.sys.comcast.net with SMTP id wJ7Md3Mi94GUKwJ7NdyRwa; Mon, 25 Sep 2017 02:27:34 +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 v8P2RWpE021157; Sun, 24 Sep 2017 22:27:32 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v8P2RVBk021154; Sun, 24 Sep 2017 22:27:31 -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: Paul Kyzivat Cc: christer.holmberg@ericsson.com, R.Jesske@telekom.de, tasveren@sonusnet.com, sipcore@ietf.org, a.james.winterbottom@gmail.com In-Reply-To: <3f9dcb36-791c-6ce8-801c-49cce1a4772b@alum.mit.edu> (pkyzivat@alum.mit.edu) Sender: worley@ariadne.com (Dale R. Worley) Date: Sun, 24 Sep 2017 22:27:31 -0400 Message-ID: <87377bbjho.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfICX6qAzwPCxD8U3ODR38cpCD/wprYzQjObr4csfs4iT5xzvvpP9GBAaZwuuv8qRu9oCEZiqp46sUc4RxJYsNBX9OP3tC/sbeEbDOGrqyzWwT4AY/usG io55kAY6OJnQzGFQuqu+MMaF38PvoEBZKMKGxcAUJ+pA+Ah823RksRFY5PfCGl9LnuJmtFUdHeNzdo+0mMkAfmJSl9hPH/j3jUhbW4amehqsdCXbum4Yr6aD 7NAPPJITuViiHNhYQA7uxq30yALP16l5MxGayWb/YV2USW5rKmUWHhz2yheey79OHEMy0EUaasTOLydPWip/wxMVW4nwe7YFhenDL5Lfh5bFeoXVPHcY8Dvs o0AAI9cZ Archived-At: Subject: Re: [sipcore] draft-winterbottom-sipcore-locparam-01.txt and Liaison Statement to IETF on location source parameter X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 02:27:37 -0000 Paul Kyzivat writes: > Surely there ought to be some semantics to this. I presume it is to be > an identifier of something, and presumably there then need to be rules > for resolution/comparison/etc. > > Otherwise I could just enter XYZZY. If usage is confined to a single administrative domain (which is what I think Christer is saying), there don't need to be general semantic rules. There don't even need to be general syntactic rules. Dale From nobody Sun Sep 24 23:30:57 2017 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 4982E126B6E for ; Sun, 24 Sep 2017 23:30:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de header.b=Z5XmYsYK; dkim=pass (1024-bit key) header.d=telekom.onmicrosoft.de header.b=uJOLb9Ae 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 LXzL4VA8Iryc for ; Sun, 24 Sep 2017 23:30:52 -0700 (PDT) Received: from mailout24.telekom.de (MAILOUT24.telekom.de [80.149.113.254]) (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 AED72126B6D for ; Sun, 24 Sep 2017 23:30:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1506321051; x=1537857051; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=w49n/b2mB94ytXCQXBIRXn3hjzfhsZ4WtZVCW7EIEew=; b=Z5XmYsYK5RzisBso+7ymqS+FezcPT4+4l98R7oljPFOhrdLeyiSFCU4A OWEyC3kzmmP7n9zY3dgVWccUNx+TntjO4NdNPaqX4D67iXufAPHOdXba5 F5kVfh8hMF5XEnJR8/0s0YVNg566ZYOef+vSq3eF2QcaeIH4ZO5ys1o35 0TfbqtqgBRoq+EORVEilS19OrgrokN3sWIPnICY3pWtnStkLJVQBZ6R0Y IyPtDjFBFB9X/FjC7cKJh4w/ELAjL0VFQr0mfmwZZ2utzQS+eFtEo/ibx NH1JE/VKmD5GoVcHvJBq0OEhaZ3RWL6bbzHHc4uQ1gYggMJwztGJCyBMc w==; Received: from q4de8psa169.blf.telekom.de ([10.151.13.200]) by MAILOUT21.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Sep 2017 08:30:48 +0200 X-IronPort-AV: E=Sophos;i="5.42,435,1500933600"; d="scan'208";a="1392087969" Received: from he106142.emea1.cds.t-internal.com ([10.169.119.76]) by q4de8psazkj.blf.telekom.de with ESMTP/TLS/AES256-SHA; 25 Sep 2017 08:30:48 +0200 Received: from HE106138.EMEA1.cds.t-internal.com (10.169.119.71) by HE106142.emea1.cds.t-internal.com (10.169.119.76) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Mon, 25 Sep 2017 08:30:48 +0200 Received: from HE100181.emea1.cds.t-internal.com (10.171.40.15) by HE106138.EMEA1.cds.t-internal.com (10.169.119.71) with Microsoft SMTP Server (TLS) id 15.0.1293.2 via Frontend Transport; Mon, 25 Sep 2017 08:30:48 +0200 Received: from GER01-FRA-obe.outbound.protection.outlook.de (51.4.80.18) by O365mail02.telekom.de (172.30.0.235) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Mon, 25 Sep 2017 08:30:17 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.onmicrosoft.de; s=selector1-telekom-onmicrosoft-de; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=w49n/b2mB94ytXCQXBIRXn3hjzfhsZ4WtZVCW7EIEew=; b=uJOLb9AeyIzapHf/drxIv1BjFTK7IiQUWhHYtd/jxigAjy6TGt03SFXTRd3vdEbDAse1XUiwIgvKhqWqdbkbvFCN8JzRksmqoaUq8Lc+qv641xzaDXm4H5sMA9mTXXQLEi6KIJR/+BOBwdXaDjJl27GbQqciUswfpE3XPjZzQk0= Received: from FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE (10.158.133.13) by FRAPR01MB0481.DEUPRD01.PROD.OUTLOOK.DE (10.158.133.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.11; Mon, 25 Sep 2017 06:30:44 +0000 Received: from FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE ([fe80::d1:57a:9b07:65a0]) by FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE ([fe80::d1:57a:9b07:65a0%15]) with mapi id 15.20.0056.018; Mon, 25 Sep 2017 06:30:44 +0000 From: "Jesske, Roland" To: "Dale R. Worley" , Paul Kyzivat CC: "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-reason-q850-loc-00.txt Thread-Index: AQHTNBNyHwns9Rd+Q2ur3wDOZdznMqLFIAvw Date: Mon, 25 Sep 2017 06:30:44 +0000 Message-ID: References: <12f8d596-49b2-78f0-bf10-832736d10902@alum.mit.edu> (pkyzivat@alum.mit.edu) <87tvzub151.fsf@hobgoblin.ariadne.com> In-Reply-To: <87tvzub151.fsf@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=R.Jesske@telekom.de; x-originating-ip: [164.19.3.109] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; FRAPR01MB0481; 6:MeYGIxvN65kwrtN7uNDwpiMRhxleq5YKt0PXVmbgA7uvusH89k++HUAP6mqI5q3htx6ADPf56evl5K3K36mTeXa6V3DdYsZKmuPIRUXDas29cr4Mki04t9x+2icyhXHiQoI6nAZr9jrNj0kRk6xOu83rexcilkrDSxxOv9Di2GEh+JSPQqLqLrXfaLXNLDrQZpsxro5rMpNIKNdwSbKiHoZvPt417LACXO+Hs3nPo+xGKeUUX/ow589mlnxtut1OxeVqpu+iu5TB/H0m6WXu+dEiIK69kECUzJh4GuybiaN8SBdwFLCT7eBCl93tZzVWmI52IN3p6N0hDv1t/XIgMA==; 5:ii2QqsL2qQo+Adm0uSga+iVgd1Lno+xNQsBCs2UCEuK0zLgSuk4WM7X8wD0YWZaDjed0CQEhUm5qfOjKjU2t1pbLDks4KWgoE0s+L/dEDI14ktKOnmLorwdVImKqFeZZKwHaFoI7SHpu9474mbYoZg==; 24:c5MUs5fQdw1ohXm2LDyV4BfLTPRJ2UMqKyMhjmp8ZVZGXKJJ4x8+G1lhZUinjlA/3oA6gLhG7eXTyDsbEWR/eT+VBCz6iAsZPgoa3iRFc3s=; 7:GutitHfwhxodhwjYC2P5Tr6GWgJDB8+nvN87jOwNv3mOLLG10IN5vJmrpJ3xxFS/F/0jE+kULeKdFeblI93TT5HKNUoVO7SdxA9cPIM6X+ZTHqJMKnEsc311iWypy4cg0NjDcLNOt4X2mm+/Hnf0LTEUGr5XFrzGt6yhx0c9+HSdUDRGvmzaf1EN0kJhdfJAdQBw409ntaoq988VgZDyId5uU4ucF36+3KSRzLfj2X0= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 236f85b8-9411-4907-65a0-08d503def39c x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:FRAPR01MB0481; x-ms-traffictypediagnostic: FRAPR01MB0481: x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(3002001)(6041248)(20161123562025)(20161123558100)(20161123555025)(20161123560025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:FRAPR01MB0481; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:FRAPR01MB0481; x-forefront-prvs: 04410E544A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39830400002)(346002)(376002)(189002)(199003)(2171002)(50986999)(6116002)(55016002)(6306002)(53936002)(54356999)(9686003)(102836003)(74482002)(76176999)(2900100001)(966005)(3846002)(101416001)(72206003)(33656002)(106356001)(3280700002)(2906002)(81156014)(3660700001)(5660300001)(97736004)(8936002)(478600001)(86362001)(4326008)(14454004)(2950100002)(66066001)(75402003)(110136005)(81166006)(7696004)(5250100002)(189998001)(230783001)(305945005)(68736007)(8676002)(316002)(105586002)(7736002); DIR:OUT; SFP:1101; SCL:1; SRVR:FRAPR01MB0481; H:FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: telekom.de does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Sep 2017 06:30:44.6748 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f X-MS-Exchange-Transport-CrossTenantHeadersStamped: FRAPR01MB0481 X-OriginatorOrg: telekom.de Archived-At: Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-reason-q850-loc-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 06:30:55 -0000 Hi Dale and Paul, You are right with the addition of such values, everybody has the possibili= ties to interwork it's own parameters for national/operator use. So I will change the table to: The following values shall be used as location: U for user=20 LPN for private network serving the local user LN for public network serving the local user=20 TN for transit network=20 RLN for public network serving the remote user=20 RPN for private network serving the remote user=20 INTL for international network=20 BI for network beyond interworking point LOC-12 Q.850 value reserved for national use LOC-13 Q.850 value reserved for national use LOC-14 Q.850 value reserved for national use LOC-15 Q.850 value reserved for national use Are You OK with that? Best Regards Roland > -----Urspr=FCngliche Nachricht----- > Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von Dale R. > Worley > Gesendet: Samstag, 23. September 2017 04:27 > An: Paul Kyzivat > Cc: sipcore@ietf.org; Jesske, Roland > Betreff: Re: [sipcore] I-D Action: draft-ietf-sipcore-reason-q850-loc-00.= txt >=20 > Paul Kyzivat writes: > > Instead of that, how about just defining some tokens now for all the > > other code points. (E.g. NATIONAL-1, NATIONOAL-2, ... , RESERVED-1, > > RESERVED-2, ... *or* values that correspond directly to the binary > > coding, such as LOC-12, LOC-13, LOC-14, LOC-15). That way, if > > interworking comes across one of those it can be mapped > > bidirectionally to SIP. >=20 > I can see the advantage of providing tokens for all of the Q.850 values, > because as Paul says, somebody might be using them within a network. As > Roland says, the Q.850 *system* is unlikely to be changed in the future, = so > we can provide a complete set of translations of all possible values. > If somebody is using these values, they can interwork with SIP without as= king > either ITU-T or the IETF to provide a mapping. >=20 > Dale >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Mon Sep 25 00:24:49 2017 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 475911321BB for ; Mon, 25 Sep 2017 00:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.721 X-Spam-Level: X-Spam-Status: No, score=-3.721 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, RCVD_IN_SORBS_SPAM=0.5, 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 KdjbrvjPgyn0 for ; Mon, 25 Sep 2017 00:24:47 -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 AAC96132026 for ; Mon, 25 Sep 2017 00:24:46 -0700 (PDT) X-AuditID: c1b4fb30-0adfd9c000001911-8d-59c8af3a8322 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id BE.AC.06417.A3FA8C95; Mon, 25 Sep 2017 09:24:42 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.6]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0352.000; Mon, 25 Sep 2017 09:24:41 +0200 From: Christer Holmberg To: "Dale R. Worley" , Paul Kyzivat CC: "R.Jesske@telekom.de" , "tasveren@sonusnet.com" , "sipcore@ietf.org" , "a.james.winterbottom@gmail.com" Thread-Topic: [sipcore] draft-winterbottom-sipcore-locparam-01.txt and Liaison Statement to IETF on location source parameter Thread-Index: AQHTNaXWGGJ4RYVmTLCLOQ8COa0QNqLFRauA Date: Mon, 25 Sep 2017 07:24:42 +0000 Message-ID: References: <3f9dcb36-791c-6ce8-801c-49cce1a4772b@alum.mit.edu> <87377bbjho.fsf@hobgoblin.ariadne.com> In-Reply-To: <87377bbjho.fsf@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <31C6FC82D61F61409B2C5030BD79ACF9@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrCIsWRmVeSWpSXmKPExsUyM2K7ga7N+hORBts/mlrc2/STxWLFhgOs Fk13utgsvv7YxGYxu/M9k8XLE2UObB5/339g8pi8/yuzx85Zd9k9liz5yeRx6fN/do+2lwoB bFFcNimpOZllqUX6dglcGd96DjMX9LJWtHdNZG1gbGbpYuTkkBAwkbi3+hWQzcUhJHCEUeLC tAnsIAkhgUWMEo+WSHYxcnCwCVhIdP/TBgmLCARKbOs6zQpSzyxwjlHia9desEHCAnUS+/sW MUMU1Ut8WLadBcI2kji3+BAjiM0ioCrx6c5eNhCbV8Ba4ubLycwQuzIkfn5dDmZzChhLXFv0 EKyGUUBM4vupNUwgNrOAuMStJ/OZII4WkFiy5zwzhC0q8fLxP1YQW1RAT2LDidvsEHFFiZ1n 25khevUkbkydwgbyCzPQ3i0PdCHC2hLLFr5mhjhHUOLkzCcsExjFZyHZNgtJ9yyE7llIumch 6V7AyLqKUbQ4tTgpN93ISC+1KDO5uDg/Ty8vtWQTIzBuD275bbCD8eVzx0OMAhyMSjy8GctO RAqxJpYVV+YeYpTgYFYS4T22GijEm5JYWZValB9fVJqTWnyIUZqDRUmc13HfhQghgfTEktTs 1NSC1CKYLBMHp1QDo8rcpEXePr+mH1dNXtr4Y4fB8jZbKxvNtS/Wdf5PuimkGBS4t6XmsuDv /uqH7GGHDh8pM/Bdougwz6b2D8fM6rk1c6WuLnVMOrz2wP7lflGvXGa1Jhz+/dnOacUK9Q2h 5Tf3Lr5zdTqbSbLpH8NLQQdPhq7a+05lqtKz0OVl/36+reiY5SC/bpsSS3FGoqEWc1FxIgCR iMGk1wIAAA== Archived-At: Subject: Re: [sipcore] draft-winterbottom-sipcore-locparam-01.txt and Liaison Statement to IETF on location source parameter X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 07:24:48 -0000 Hi, >>Surely there ought to be some semantics to this. I presume it is to be >> an identifier of something, and presumably there then need to be rules >> for resolution/comparison/etc. >> >> Otherwise I could just enter XYZZY. > >If usage is confined to a single administrative domain (which is what I >think Christer is saying), there don't need to be general semantic >rules. There don't even need to be general syntactic rules. Correct. And, again, if there something I=B9ve missed, and there is a reason for justifying a FQDN - fine. But, if so, I want that justification to be described in the draft. Regards, Christer From nobody Mon Sep 25 04:44:06 2017 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 8FDCE1342D0 for ; Mon, 25 Sep 2017 04:44:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.72 X-Spam-Level: X-Spam-Status: No, score=-3.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, 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 80NFGGjO2NFs for ; Mon, 25 Sep 2017 04:44:03 -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 A0EED134292 for ; Mon, 25 Sep 2017 04:44:02 -0700 (PDT) X-AuditID: c1b4fb2d-a4dff700000019be-6a-59c8ebf340bf Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id CE.9A.06590.3FBE8C95; Mon, 25 Sep 2017 13:43:48 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.6]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0352.000; Mon, 25 Sep 2017 13:43:47 +0200 From: Christer Holmberg To: "sipcore@ietf.org" Thread-Topic: SIP PUSH Thread-Index: AQHTNfOMhpjgVdXGfkOKwB3589Amaw== Date: Mon, 25 Sep 2017 11:43:47 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.18] Content-Type: multipart/alternative; boundary="_000_D5EEC7E322646christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUyM2K7uu6X1yciDW7/ZbH4+mMTmwOjx5Il P5kCGKO4bFJSczLLUov07RK4Mj7cXsZWsE+pYtGKaYwNjPtluhg5OCQETCSWnonpYuTiEBI4 wigx48N6ZghnEaPExj0bmUGK2AQsJLr/aXcxcnKICGhKLP+2lR3EFhYQlFj4qo0JIi4m8WvS DRYIW0/i5fkrjCCtLAKqEg0gqzg5eAWsJbYfnckKYjMClX8/tQaslVlAXOLWk/lgtoSAgMSS PeeZIWxRiZeP/4HViwKN3HDiNjtEXFHi46t9jBC9CRI7N11ihJgvKHFy5hOWCYxCs5CMnYWk bBaSMoi4gcT7c/OZIWxtiWULX0PZ+hIbv5xlhLCtJSY3/0FRs4CRYxWjaHFqcXFuupGxXmpR ZnJxcX6eXl5qySZGYJwc3PJbdwfj6teOhxgFOBiVeHjdX52IFGJNLCuuzD3EKMHBrCTCq/sE KMSbklhZlVqUH19UmpNafIhRmoNFSZzXYd+FCCGB9MSS1OzU1ILUIpgsEwenVAOjwfa3L079 D75n4WOrIrk/9OTH/9NvSnRpfnQPEU3cseNHx/ugLVu/5KQ+Y39dKi2tv3//e75O32Mloalr s1QWxzc+lJBg0dPyOSx5cNcahxhLtpQ9a3o/f9468zVXjt3b59oys4WqBDYvOCNky3jo9xq7 R5s7Dq2W7ffIKra/lPSYabXtzq2cSizFGYmGWsxFxYkAd2Qf/Y8CAAA= Archived-At: Subject: [sipcore] SIP PUSH X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 11:44:04 -0000 --_000_D5EEC7E322646christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, There is a problem with iOS SIP/VoIP applications (I understand the same is= coming to Android too): the application need to be =93woken up=94 using th= e Apple Push Mechanism, in order to e.g., be able to accept incoming INVITE= requests. In earlier iOS versions an incoming request could wake up the ap= plication. A solution has been discussed, where a SIP proxy (or some other network ent= ity) informs the Apple Push Server when an incoming call for Alice is comi= ng, the Apple Push Server wakes up Alice's UA VoIP application, which is th= en able to receive the INVITE request. In order to do this, the UA needs to provide some information (e.g., which = push server is used, the Alice=92s VoIP application specific push identifie= r etc) to the SIP network during registration. There is a real need for a solution in the market, and I know that people a= re looking at a number of different proprietary solutions =96 which can cau= se a real mess in the long run. Therefor I think it would be VERY important= to produce a standardised way of doing this. There IS a draft on this: https://tools.ietf.org/html/draft-ivanov-sipcore-pnsip-01 The draft uses URI parameters. We think that media feature tags should be u= sed instead. Also, we think at least one additional parameter is needed. Bu= t, in general we think the draft provides a good solution. I haven=92t managed to contact the draft author, as my e-mails are rejected= . But, if he is reading this, or if someone else is able to contact him, I= =92d like to get in contact with him :) Regards, Christer --_000_D5EEC7E322646christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

There is a problem with iOS SIP/VoIP applications (I understand the sa= me is coming to Android too): the application need to be =93woken up=94 usi= ng the Apple Push Mechanism, in order to e.g., be able to accept incoming I= NVITE requests. In earlier iOS versions an incoming request could wake up the application.

A solution has been discussed, where a SIP proxy (or some other networ= k entity) informs the Apple Push Server when an incoming call  for Ali= ce is coming, the Apple Push Server wakes up Alice's UA VoIP application, w= hich is then able to receive the INVITE request.

In order to do this, the UA needs to provide some information (e.g., w= hich push server is used, the Alice=92s VoIP application specific push iden= tifier etc) to the SIP network during registration.

There is a real need for a solution in the market, and I know that peo= ple are looking at a number of different proprietary solutions =96 which ca= n cause a real mess in the long run. Therefor I think it would be VERY impo= rtant to produce a standardised way of doing this.

There IS a draft on this:


The draft uses URI parameters. We think that media feature tags should= be used instead. Also, we think at least one additional parameter is neede= d. But, in general we think the draft provides a good solution.

I haven=92t managed to contact the draft author, as my e-mails are rej= ected. But, if he is reading this, or if someone else is able to contact hi= m, I=92d like to get in contact with him :)

Regards,

Christer

--_000_D5EEC7E322646christerholmbergericssoncom_-- From nobody Mon Sep 25 05:23:45 2017 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 BB2951342D6 for ; Mon, 25 Sep 2017 05:23:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=sonusnetworks.onmicrosoft.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 KxSR5deGr9P3 for ; Mon, 25 Sep 2017 05:23:41 -0700 (PDT) Received: from us-smtp-delivery-126.mimecast.com (us-smtp-delivery-126.mimecast.com [63.128.21.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC4F61342F0 for ; Mon, 25 Sep 2017 05:23:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=54u6ciG+7+/bmS9LwJwhK7OUQeWod/aCwWglz6kLJsk=; b=d7tmk4YhoTf2SndKik/q7iGo87XaibE2zMfcQdZI95X3uAhA9hmNan2KFXDJsVmkBg0I+KnMElUTv/CIKjenb2jLlwjzJSeG48N9XKvHEDw2A7jlLy8msS/njmaSu7Rh81EW72iE64wxwN7yFyfzSIrwqcDsVbM1/hsGpIphIbc= Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03lp0018.outbound.protection.outlook.com [207.46.163.18]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-186-6V_o4AiBMu6KHhLxkl7BXg-1; Mon, 25 Sep 2017 08:23:38 -0400 Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB2349.namprd03.prod.outlook.com (10.166.210.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Mon, 25 Sep 2017 12:23:35 +0000 Received: from SN2PR03MB2350.namprd03.prod.outlook.com ([fe80::d88f:793d:af1f:f651]) by SN2PR03MB2350.namprd03.prod.outlook.com ([fe80::d88f:793d:af1f:f651%18]) with mapi id 15.20.0077.011; Mon, 25 Sep 2017 12:23:35 +0000 From: "Asveren, Tolga" To: Christer Holmberg , "sipcore@ietf.org" Thread-Topic: SIP PUSH Thread-Index: AQHTNfOMhpjgVdXGfkOKwB3589Ama6LFhdJQ Date: Mon, 25 Sep 2017 12:23:35 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [73.29.18.75] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN2PR03MB2349; 20:/ug116xl1eSbTPmt9EWI7FE83Dj+rHXZ2MNVdiALXnl3f13RHjTK1PxHcmkA4nrUyIB0xta5ncuWG2AjrAP7JBCBAK3eoniM0wOeol9MM6kuGF7sk3yFgJRGMlco9EErhbOeKQaqmxPL9MBoi/Q5Zf40AKoo2D97Thxhwa4duII= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 152d336e-cd91-469b-6134-08d504103e81 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:SN2PR03MB2349; x-ms-traffictypediagnostic: SN2PR03MB2349: x-exchange-antispam-report-test: UriScan:(158342451672863)(278428928389397)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3002001)(6041248)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123558100)(20161123562025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:SN2PR03MB2349; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:SN2PR03MB2349; x-forefront-prvs: 04410E544A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39830400002)(346002)(376002)(199003)(189002)(377454003)(966005)(54896002)(2501003)(54356999)(6306002)(110136005)(76176999)(66066001)(221733001)(6246003)(33656002)(2900100001)(25786009)(14454004)(106356001)(9686003)(99286003)(53936002)(105586002)(50986999)(236005)(2906002)(101416001)(86362001)(55016002)(3280700002)(189998001)(5660300001)(3846002)(7116003)(3660700001)(8936002)(81166006)(8676002)(81156014)(7696004)(316002)(478600001)(3480700004)(229853002)(97736004)(19609705001)(5250100002)(74316002)(6116002)(6506006)(6436002)(53546010)(102836003)(7736002)(790700001)(68736007)(606006)(2950100002); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB2349; H:SN2PR03MB2350.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Sep 2017 12:23:35.5728 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2349 X-MC-Unique: 6V_o4AiBMu6KHhLxkl7BXg-1 Content-Type: multipart/alternative; boundary="_000_SN2PR03MB2350EFD2B7F9644453A431DCB27A0SN2PR03MB2350namp_" Archived-At: Subject: Re: [sipcore] SIP PUSH X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 12:23:44 -0000 --_000_SN2PR03MB2350EFD2B7F9644453A431DCB27A0SN2PR03MB2350namp_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable What is the advantage of this strategy v.s. Push Server communicating direc= tly with the SIP Proxy/Registrar etc... through a non-SIP, e.g. REST API ba= sed, interface? Thanks, Tolga From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmb= erg Sent: Monday, September 25, 2017 7:44 AM To: sipcore@ietf.org Subject: [sipcore] SIP PUSH Hi, There is a problem with iOS SIP/VoIP applications (I understand the same is= coming to Android too): the application need to be "woken up" using the Ap= ple Push Mechanism, in order to e.g., be able to accept incoming INVITE req= uests. In earlier iOS versions an incoming request could wake up the applic= ation. A solution has been discussed, where a SIP proxy (or some other network ent= ity) informs the Apple Push Server when an incoming call for Alice is comi= ng, the Apple Push Server wakes up Alice's UA VoIP application, which is th= en able to receive the INVITE request. In order to do this, the UA needs to provide some information (e.g., which = push server is used, the Alice's VoIP application specific push identifier = etc) to the SIP network during registration. There is a real need for a solution in the market, and I know that people a= re looking at a number of different proprietary solutions - which can cause= a real mess in the long run. Therefor I think it would be VERY important t= o produce a standardised way of doing this. There IS a draft on this: https://tools.ietf.org/html/draft-ivanov-sipcore-pnsip-01 The draft uses URI parameters. We think that media feature tags should be u= sed instead. Also, we think at least one additional parameter is needed. Bu= t, in general we think the draft provides a good solution. I haven't managed to contact the draft author, as my e-mails are rejected. = But, if he is reading this, or if someone else is able to contact him, I'd = like to get in contact with him :) Regards, Christer --_000_SN2PR03MB2350EFD2B7F9644453A431DCB27A0SN2PR03MB2350namp_ Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable

What is the advantage of this strategy v.s. Push Ser= ver communicating directly with the SIP Proxy/Registrar etc… through = a non-SIP, e.g. REST API based, interface?

 

Thanks,

Tolga

 

From: sipcore [mailto:sipcore-bounces@ietf.or= g] On Behalf Of Christer Holmberg
Sent: Monday, September 25, 2017 7:44 AM
To: sipcore@ietf.org
Subject: [sipcore] SIP PUSH

 

Hi,

&n= bsp;

There i= s a problem with iOS SIP/VoIP applications (I understand the same is coming= to Android too): the application need to be “woken up” using t= he Apple Push Mechanism, in order to e.g., be able to accept incoming INVITE requests. In earlier iOS versions an incoming re= quest could wake up the application.

&n= bsp;

A solut= ion has been discussed, where a SIP proxy (or some other network entity) in= forms the Apple Push Server when an incoming call  for Alice is coming= , the Apple Push Server wakes up Alice's UA VoIP application, which is then able to receive the INVITE request.

&n= bsp;

In orde= r to do this, the UA needs to provide some information (e.g., which push se= rver is used, the Alice’s VoIP application specific push identifier e= tc) to the SIP network during registration.

&n= bsp;

There i= s a real need for a solution in the market, and I know that people are look= ing at a number of different proprietary solutions – which can cause = a real mess in the long run. Therefor I think it would be VERY important to produce a standardised way of doing this.

&n= bsp;

There I= S a draft on this:

&n= bsp;

&n= bsp;

The dra= ft uses URI parameters. We think that media feature tags should be used ins= tead. Also, we think at least one additional parameter is needed. But, in g= eneral we think the draft provides a good solution.

&n= bsp;

I haven= ’t managed to contact the draft author, as my e-mails are rejected. B= ut, if he is reading this, or if someone else is able to contact him, IR= 17;d like to get in contact with him :)

&n= bsp;

Regards= ,

&n= bsp;

Christe= r

&n= bsp;

--_000_SN2PR03MB2350EFD2B7F9644453A431DCB27A0SN2PR03MB2350namp_-- From nobody Mon Sep 25 05:36:04 2017 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 55107133226 for ; Mon, 25 Sep 2017 05:36:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 TqN3VoGtkVc7 for ; Mon, 25 Sep 2017 05:36:01 -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 3D6011342D9 for ; Mon, 25 Sep 2017 05:36:00 -0700 (PDT) X-AuditID: c1b4fb25-967ff70000005333-bd-59c8f82ffd0a Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 49.3F.21299.F28F8C95; Mon, 25 Sep 2017 14:35:59 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.6]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0352.000; Mon, 25 Sep 2017 14:35:58 +0200 From: Christer Holmberg To: "Asveren, Tolga" , "sipcore@ietf.org" Thread-Topic: SIP PUSH Thread-Index: AQHTNfOMhpjgVdXGfkOKwB3589Ama6LFhdJQgAAWNAA= Date: Mon, 25 Sep 2017 12:35:58 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.19] Content-Type: multipart/alternative; boundary="_000_D5EED2B922666christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprPIsWRmVeSWpSXmKPExsUyM2J7oK7+jxORBhN6hSy+/tjEZjG78z2T A5PHkiU/mTwuff7PHsAUxWWTkpqTWZZapG+XwJWx/PsyloK+yIqORafZGhhP+HQxcnJICJhI bN42i62LkYtDSOAIo8T9P8uZIZxFjBLbm+8AORwcbAIWEt3/tEEaRARCJSY9aGQEsYUFRCWO nOtlhYiLSfyadIMFwraSeLwAZCgnB4uAqsTEOy1MIDavgLXE3PVLGCHm9zFKHDl8jx0kwSkQ KzF5cjtYAyPQoO+n1oA1MAuIS9x6Mp8J4lIBiSV7zjND2KISLx//A1ssKqAnseHEbXaIuKJE +9MGRpCbmQUSJI5dsYbYKyhxcuYTlgmMIrOQTJ2FUDULSRVEiYHE+3PzmSFsbYllC19D2foS G7+cZYSwgb75vYYNWc0CRo5VjKLFqcVJuelGxnqpRZnJxcX5eXp5qSWbGIHRdnDLb9UdjJff OB5iFOBgVOLhvfviRKQQa2JZcWXuIUYJDmYlEV7m70Ah3pTEyqrUovz4otKc1OJDjNIcLEri vI77LkQICaQnlqRmp6YWpBbBZJk4OKUaGCOvdCb4zdzosLXHxuJF33rmKI7TG5yTNk6dt1tA 59OsX09u9JwX2tXCo31ghaK/1FQTpXpGfTGuJVXO9vuupnr/kpYv448NyE7T2/vOM0Yu6tGs wwLP9V49KpRYuTn1pSOPio2V6my55Midrr/TJfbOWbFfb+o361V92+6GFHW52V9xX9n+W4ml OCPRUIu5qDgRADytAGSyAgAA Archived-At: Subject: Re: [sipcore] SIP PUSH X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 12:36:03 -0000 --_000_D5EED2B922666christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, >What is the advantage of this strategy v.s. Push Server communicating dire= ctly with the SIP Proxy/Registrar etc=85 through a non-SIP, e.g. REST API b= ased, interface? The Push Server DOES communicate with the SIP Proxy/Registrar using a non-S= IP interface. Those interfaces are provided by Apple (or whoever provides t= he push server), and we don=92t suggest to change those. When the SIP UA registers itself with the Push Server, it receives a unique= token. The SIP UA needs to inform the proxy about that token (and, inform = the proxy that it is an Apple token), so that the proxy can provide it to t= he Push Server when the incoming call comes. SO, what we need is a way for the SIP UA to provide the token to the proxy. Regards, Christer From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmb= erg Sent: Monday, September 25, 2017 7:44 AM To: sipcore@ietf.org Subject: [sipcore] SIP PUSH Hi, There is a problem with iOS SIP/VoIP applications (I understand the same is= coming to Android too): the application need to be =93woken up=94 using th= e Apple Push Mechanism, in order to e.g., be able to accept incoming INVITE= requests. In earlier iOS versions an incoming request could wake up the ap= plication. A solution has been discussed, where a SIP proxy (or some other network ent= ity) informs the Apple Push Server when an incoming call for Alice is comi= ng, the Apple Push Server wakes up Alice's UA VoIP application, which is th= en able to receive the INVITE request. In order to do this, the UA needs to provide some information (e.g., which = push server is used, the Alice=92s VoIP application specific push identifie= r etc) to the SIP network during registration. There is a real need for a solution in the market, and I know that people a= re looking at a number of different proprietary solutions =96 which can cau= se a real mess in the long run. Therefor I think it would be VERY important= to produce a standardised way of doing this. There IS a draft on this: https://tools.ietf.org/html/draft-ivanov-sipcore-pnsip-01 The draft uses URI parameters. We think that media feature tags should be u= sed instead. Also, we think at least one additional parameter is needed. Bu= t, in general we think the draft provides a good solution. I haven=92t managed to contact the draft author, as my e-mails are rejected= . But, if he is reading this, or if someone else is able to contact him, I= =92d like to get in contact with him :) Regards, Christer --_000_D5EED2B922666christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <1D733A3C5B837A45A359C4914571371D@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

>What is the advantage of this strategy v.s. Push= Server communicating directly with the SIP Proxy/Registrar etc=85 through = a non-SIP, e.g. REST API based, interface?

The Push Server DOES communicate with the SIP Proxy/Registrar using a = non-SIP interface. Those interfaces are provided by Apple (or whoever provi= des the push server), and we don=92t suggest to change those.

When the SIP UA registers itself with the Push Server, it receives a u= nique token. The SIP UA needs to inform the proxy about that token (and, in= form the proxy that it is an Apple token), so that the proxy can provide it= to the Push Server when the incoming call comes. 

SO, what we need is a way for the SIP UA to provide the token to the p= roxy.

Regards,

Christer

 

From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: Monday, September 25, 2017 7:44 AM
To: sipcore@ietf.org
Subject: [sipcore] SIP PUSH

 

Hi,

&n= bsp;

There i= s a problem with iOS SIP/VoIP applications (I understand the same is coming= to Android too): the application need to be =93woken up=94 using the Apple= Push Mechanism, in order to e.g., be able to accept incoming INVITE requests. In earlier iOS versions an incoming re= quest could wake up the application.

&n= bsp;

A solut= ion has been discussed, where a SIP proxy (or some other network entity) in= forms the Apple Push Server when an incoming call  for Alice is coming= , the Apple Push Server wakes up Alice's UA VoIP application, which is then able to receive the INVITE request.

&n= bsp;

In orde= r to do this, the UA needs to provide some information (e.g., which push se= rver is used, the Alice=92s VoIP application specific push identifier etc) = to the SIP network during registration.

&n= bsp;

There i= s a real need for a solution in the market, and I know that people are look= ing at a number of different proprietary solutions =96 which can cause a re= al mess in the long run. Therefor I think it would be VERY important to produce a standardised way of doing this.

&n= bsp;

There I= S a draft on this:

&n= bsp;

&n= bsp;

The dra= ft uses URI parameters. We think that media feature tags should be used ins= tead. Also, we think at least one additional parameter is needed. But, in g= eneral we think the draft provides a good solution.

&n= bsp;

I haven= =92t managed to contact the draft author, as my e-mails are rejected. But, = if he is reading this, or if someone else is able to contact him, I=92d lik= e to get in contact with him :)

&n= bsp;

Regards= ,

&n= bsp;

Christe= r

&n= bsp;

 --_000_D5EED2B922666christerholmbergericssoncom_-- From nobody Mon Sep 25 05:56:30 2017 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 000481342F8 for ; Mon, 25 Sep 2017 05:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 WOgupVSArIJT for ; Mon, 25 Sep 2017 05:56:26 -0700 (PDT) Received: from alum-mailsec-scanner-3.mit.edu (alum-mailsec-scanner-3.mit.edu [18.7.68.14]) by ietfa.amsl.com (Postfix) with ESMTP id 51FAB134224 for ; Mon, 25 Sep 2017 05:56:26 -0700 (PDT) X-AuditID: 1207440e-bf9ff70000007085-1c-59c8fcf986ad Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 36.36.28805.9FCF8C95; Mon, 25 Sep 2017 08:56:25 -0400 (EDT) Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id v8PCuNGS008314 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 25 Sep 2017 08:56:24 -0400 To: "Jesske, Roland" , "Dale R. Worley" Cc: "sipcore@ietf.org" References: <12f8d596-49b2-78f0-bf10-832736d10902@alum.mit.edu> <87tvzub151.fsf@hobgoblin.ariadne.com> From: Paul Kyzivat Message-ID: Date: Mon, 25 Sep 2017 08:56:23 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmleLIzCtJLcpLzFFi42IRYndR1P3550SkwZPtChZNd7rYLL7+2MRm 8fJEmQOzx+T9X5k9liz5yeTR9lIhgDmKyyYlNSezLLVI3y6BK2PvWbaCa0IV91e9YW1gbOTv YuTkkBAwkfhz9gc7iC0ksINJ4tzv9C5GLiD7IZPEt/urGUESwgJBEnfeTAezRQSiJC7MvQXW wCygKbF53QV2iIZdjBJHbp1gA0mwCWhJzDn0nwXE5hWwl9h/5QVzFyMHB4uAqsSq+WC9ogJp Ev92n2WEKBGUODnzCVg5p0CMxM2JX6Hmm0nM2/yQGcIWl7j1ZD4ThC0v0bx1NvMERoFZSNpn IWmZhaRlFpKWBYwsqxjlEnNKc3VzEzNzilOTdYuTE/PyUot0jfVyM0v0UlNKNzFCwplvB2P7 eplDjAIcjEo8vBH/jkcKsSaWFVfmHmKU5GBSEuW9y3ciUogvKT+lMiOxOCO+qDQntfgQowQH s5IIL/N3oBxvSmJlVWpRPkxKmoNFSZxXbYm6n5BAemJJanZqakFqEUxWhoNDSYJXHhi3QoJF qempFWmZOSUIaSYOTpDhPEDDf/8GGV5ckJhbnJkOkT/FqMvR03PjD5MQS15+XqqUOO8xkCIB kKKM0jy4ObA09IpRHOgtYV4dkHU8wBQGN+kV0BImoCW9U8GWlCQipKQaGF1PnD1zUKczJHWJ l2Nj4uGJ5zoF5U5Jn5jznP10W9EnOx2VWotYZdZFK5kTWudedr6lcuXyvMk+rn+XeuyUzP15 966aBkfVXkOzRr/XJz/+f3zgjs9Et5NzD+gICq/gWbY5f+ZnD8EStd7z/EKXr4jbTJicdc6o NGOd48GorZoJ22WW+S7ZukiJpTgj0VCLuag4EQAWNsflHgMAAA== Archived-At: Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-reason-q850-loc-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 12:56:28 -0000 On 9/25/17 2:30 AM, Jesske, Roland wrote: > Hi Dale and Paul, > You are right with the addition of such values, everybody has the possibilities to interwork it's own parameters for national/operator use. > So I will change the table to: > > The following values shall be used as location: > U for user > LPN for private network serving the local user > LN for public network serving the local user > TN for transit network > RLN for public network serving the remote user > RPN for private network serving the remote user > INTL for international network > BI for network beyond interworking point > LOC-12 Q.850 value reserved for national use > LOC-13 Q.850 value reserved for national use > LOC-14 Q.850 value reserved for national use > LOC-15 Q.850 value reserved for national use There are still 4 other values. I recommend covering them as well. Thanks, Paul > Are You OK with that? > > Best Regards > > Roland > > >> -----Ursprüngliche Nachricht----- >> Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von Dale R. >> Worley >> Gesendet: Samstag, 23. September 2017 04:27 >> An: Paul Kyzivat >> Cc: sipcore@ietf.org; Jesske, Roland >> Betreff: Re: [sipcore] I-D Action: draft-ietf-sipcore-reason-q850-loc-00.txt >> >> Paul Kyzivat writes: >>> Instead of that, how about just defining some tokens now for all the >>> other code points. (E.g. NATIONAL-1, NATIONOAL-2, ... , RESERVED-1, >>> RESERVED-2, ... *or* values that correspond directly to the binary >>> coding, such as LOC-12, LOC-13, LOC-14, LOC-15). That way, if >>> interworking comes across one of those it can be mapped >>> bidirectionally to SIP. >> >> I can see the advantage of providing tokens for all of the Q.850 values, >> because as Paul says, somebody might be using them within a network. As >> Roland says, the Q.850 *system* is unlikely to be changed in the future, so >> we can provide a complete set of translations of all possible values. >> If somebody is using these values, they can interwork with SIP without asking >> either ITU-T or the IETF to provide a mapping. >> >> Dale >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore > From nobody Mon Sep 25 06:01:52 2017 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 2651C1342F8 for ; Mon, 25 Sep 2017 06:01:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 kdykzhaGl3zN for ; Mon, 25 Sep 2017 06:01:50 -0700 (PDT) Received: from alum-mailsec-scanner-2.mit.edu (alum-mailsec-scanner-2.mit.edu [18.7.68.13]) by ietfa.amsl.com (Postfix) with ESMTP id DFC221342E8 for ; Mon, 25 Sep 2017 06:01:49 -0700 (PDT) X-AuditID: 1207440d-86bff70000000f42-b1-59c8fe3c4807 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id E4.3B.03906.C3EF8C95; Mon, 25 Sep 2017 09:01:49 -0400 (EDT) Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id v8PD1lU4008619 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 25 Sep 2017 09:01:47 -0400 To: "Dale R. Worley" Cc: christer.holmberg@ericsson.com, R.Jesske@telekom.de, tasveren@sonusnet.com, sipcore@ietf.org, a.james.winterbottom@gmail.com References: <87377bbjho.fsf@hobgoblin.ariadne.com> From: Paul Kyzivat Message-ID: Date: Mon, 25 Sep 2017 09:01:47 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <87377bbjho.fsf@hobgoblin.ariadne.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCKsWRmVeSWpSXmKPExsUixO6iqGv770SkwftOfot7m36yWFyYeZjR oulOF5vF1x+b2Cxmd75nsnh5osyBzWPy/q/MHr++XmXz2DnrLrvHkiU/mTwuff7P7tH2UiGA LYrLJiU1J7MstUjfLoEr493VdWwFc9gr1vz1aGC8x9rFyMEhIWAisWY1YxcjF4eQwA4miaaz q5ghnIdMEm9/7wdyODmEBeokJr84ywbSICKgKdGxIAekhlmgk1Hi0acnjCBxIQEjie3nq0HK 2QS0JOYc+s8CYvMK2Esc/T+DDcRmEVCVWHCgnxHEFhVIk/i3+ywjRI2gxMmZT8DqOQWMJa4t eghWzyxgJjFv80NmCFtc4taT+UwQtrzE9rdzmCcwCsxC0j4LScssJC2zkLQsYGRZxSiXmFOa q5ubmJlTnJqsW5ycmJeXWqRrpJebWaKXmlK6iRESCbw7GP+vkznEKMDBqMTDG/HveKQQa2JZ cWXuIUZJDiYlUd67fCcihfiS8lMqMxKLM+KLSnNSiw8xSnAwK4nwMn8HyvGmJFZWpRblw6Sk OViUxHnVlqj7CQmkJ5akZqemFqQWwWRlODiUJHh9/gI1ChalpqdWpGXmlCCkmTg4QYbzAA1X A6nhLS5IzC3OTIfIn2K05Ljx8PofJo6enhtA8tLD23+YhFjy8vNSpcR5//8BahAAacgozYOb CUtsrxjFgV4U5g0HGcsDTIpwU18BLWQCWtg7FWxhSSJCSqqBUXrzlobvp55JH1yao8s4efqV CRO+MB76ErPoQ9OUih9Mu2+Kaae72HS9eCex/86d3v1H9P8Kyk1+6sWm1lfK965xQ0PAG7/f uY++H1v75uCmlUekVLaKS07MZp89oUXXIVpoHWOd/qIn7ZVbntsbrD7bF3Cv8UAp58uF67Xl Mz43XjZZNSe2uUGJpTgj0VCLuag4EQCPfeUxRwMAAA== Archived-At: Subject: Re: [sipcore] draft-winterbottom-sipcore-locparam-01.txt and Liaison Statement to IETF on location source parameter X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 13:01:51 -0000 On 9/24/17 10:27 PM, Dale R. Worley wrote: > Paul Kyzivat writes: >> Surely there ought to be some semantics to this. I presume it is to be >> an identifier of something, and presumably there then need to be rules >> for resolution/comparison/etc. >> >> Otherwise I could just enter XYZZY. > > If usage is confined to a single administrative domain (which is what I > think Christer is saying), there don't need to be general semantic > rules. There don't even need to be general syntactic rules. The usage isn't *restricted* to IMS. It is simply defined with the expectation that they are the ones who need it. If others are allowed to use it then there need to be some rules to ensure mutual understanding. Otherwise this is just using sip to tunnel another protocol. The advantage of using FQDNs is that there are clear rules for assignment of those. Thanks, Paul From nobody Mon Sep 25 06:05:02 2017 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 32C4B1342F8 for ; Mon, 25 Sep 2017 06:05:01 -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 aCVtPuM24Fiz for ; Mon, 25 Sep 2017 06:05:00 -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 E805B1342E8 for ; Mon, 25 Sep 2017 06:04:59 -0700 (PDT) X-AuditID: c1b4fb25-967ff70000005333-ea-59c8fefa52e2 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 62.66.21299.AFEF8C95; Mon, 25 Sep 2017 15:04:58 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.6]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0352.000; Mon, 25 Sep 2017 15:04:57 +0200 From: Christer Holmberg To: Paul Kyzivat , "Dale R. Worley" CC: "R.Jesske@telekom.de" , "tasveren@sonusnet.com" , "sipcore@ietf.org" , "a.james.winterbottom@gmail.com" Thread-Topic: [sipcore] draft-winterbottom-sipcore-locparam-01.txt and Liaison Statement to IETF on location source parameter Thread-Index: AQHTNaXWGGJ4RYVmTLCLOQ8COa0QNqLFcBCAgAA0q4A= Date: Mon, 25 Sep 2017 13:04:57 +0000 Message-ID: References: <87377bbjho.fsf@hobgoblin.ariadne.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrCIsWRmVeSWpSXmKPExsUyM2K7k+6vfyciDc6eELK4t+kni8WKDQdY LZrudLFZfP2xic1idud7JouXJ8oc2Dz+vv/A5DF5/1dmj52z7rJ7LFnyk8nj0uf/7B5tLxUC 2KK4bFJSczLLUov07RK4Mg6cus9acI+9YlfXJdYGxolsXYycHBICJhK/rk1h72Lk4hASOMIo Me3VVhaQhJDAIkaJ6481uxg5ONgELCS6/2mDhEUEAiW6dh5jAqlnFjjHKPG1ay9YvbBAncT+ vkXMEEX1Eh+WbWcB6RURsJJYvdEGJMwioCqxv6cbrIRXwFri2fadzBCrMiT2nd7NBlLOKeAg 0bhOACTMKCAm8f3UGiYQm1lAXOLWk/lMECcLSCzZc54ZwhaVePn4HyuILSqgJ7HhxG12iLii RPvTBkaIXj2JG1OnsEHY1hIrl71hgbC1JZYtfA11jqDEyZlPWCYwis9Csm4WkvZZSNpnIWmf haR9ASPrKkbR4tTipNx0I2O91KLM5OLi/Dy9vNSSTYzAuD245bfqDsbLbxwPMQpwMCrx8N59 cSJSiDWxrLgy9xCjBAezkggv83egEG9KYmVValF+fFFpTmrxIUZpDhYlcV7HfRcihATSE0tS s1NTC1KLYLJMHJxSDYzxNw59ChQOf8Xx/OSHrKcrJX9wfRM0PtlgxSdpJrql3ydUk6HZtGjT gVMbvjE9P7Pp/aOU3zVcO/YIlQoJGcXGmL07WF0g7HcwasrC6YrqmQJit7jWfn8Yt1r20YbW ZwWMaQdaPReJzjKvtgoV1mLOMZCZHD/XqHRLDLtlvMO2UxFSyzoF1yuxFGckGmoxFxUnAgBh 4zUw1wIAAA== Archived-At: Subject: Re: [sipcore] draft-winterbottom-sipcore-locparam-01.txt and Liaison Statement to IETF on location source parameter X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 13:05:01 -0000 Hi, >>>Surely there ought to be some semantics to this. I presume it is to be >>> an identifier of something, and presumably there then need to be rules >>> for resolution/comparison/etc. >>> >>> Otherwise I could just enter XYZZY. >>=20 >> If usage is confined to a single administrative domain (which is what I >> think Christer is saying), there don't need to be general semantic >> rules. There don't even need to be general syntactic rules. > >The usage isn't *restricted* to IMS. It is simply defined with the >expectation that they are the ones who need it. If others are allowed to >use it then there need to be some rules to ensure mutual understanding. >Otherwise this is just using sip to tunnel another protocol. > >The advantage of using FQDNs is that there are clear rules for >assignment of those. I don=B9t think I said =B3IMS=B2 :) But, the draft DOES say that the identifier must only be used within a trusted domain. Regards, Christer From nobody Mon Sep 25 06:57:07 2017 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 DB66D134316 for ; Mon, 25 Sep 2017 06:57:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de header.b=UUgozDFT; dkim=pass (1024-bit key) header.d=telekom.onmicrosoft.de header.b=sCeAgNGB 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 5a8LJ3C2OTbw for ; Mon, 25 Sep 2017 06:57:02 -0700 (PDT) Received: from mailout13.telekom.de (MAILOUT13.telekom.de [80.149.113.181]) (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 5478D132D22 for ; Mon, 25 Sep 2017 06:57:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1506347821; x=1537883821; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=NBNn7CtvecMKVrVw08zZTQfhbOEFtIwg5kMTxRMW1po=; b=UUgozDFTTsSSZQvy8nCRfUvF/YHqptrJsiRpbljfGbiQL+S+upIdMIu9 oW55u34r+kFSp6iyIDfiW/AMOwN4wDNc9DwEx3Fj/SmmOvNpo8E7XahkX m2R51p+F0CZg+Q/BrUoQMspbxx81Ke3Q+M29dc3qCRpE1UeOqg80xP+1P tUytsyShR0f7eWdxi5YL9BdLjgqg7+BOjPsFPFRU3S6vdn3Lk214lyEou 24r26WbUEDdlc3Kyq2gciLpdKl1ssovzhrpaBIrKL/Kppv9FkWSgRFjx+ k2l6KhWr3T64U7Q8cBSB//qUywPGMx7NQ+Fcy1fhXGdK+RmqwCv2OM8Bl w==; Received: from qdezc2.de.t-internal.com ([10.171.255.37]) by MAILOUT11.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Sep 2017 15:56:57 +0200 X-IronPort-AV: E=Sophos;i="5.42,436,1500933600"; d="scan'208";a="668855704" Received: from he105886.emea1.cds.t-internal.com ([10.169.118.34]) by qde0ps.de.t-internal.com with ESMTP/TLS/AES256-SHA; 25 Sep 2017 15:56:57 +0200 Received: from HE105871.EMEA1.cds.t-internal.com (10.169.118.68) by HE105886.emea1.cds.t-internal.com (10.169.118.34) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Mon, 25 Sep 2017 15:56:56 +0200 Received: from HE106564.emea1.cds.t-internal.com (10.171.40.16) by HE105871.EMEA1.cds.t-internal.com (10.169.118.68) with Microsoft SMTP Server (TLS) id 15.0.1293.2 via Frontend Transport; Mon, 25 Sep 2017 15:56:56 +0200 Received: from GER01-LEJ-obe.outbound.protection.outlook.de (51.5.80.22) by O365mail01.telekom.de (172.30.0.234) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Mon, 25 Sep 2017 15:56:53 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.onmicrosoft.de; s=selector1-telekom-onmicrosoft-de; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=NBNn7CtvecMKVrVw08zZTQfhbOEFtIwg5kMTxRMW1po=; b=sCeAgNGBCemOLVK/OCS8vcEwHxtSasBPZk5E/otOljOC9pvYGKLos0sTRKG3S3Drj0lGX1i/OkDsbsAKIQAwk7Y9kA6DvxZ2LKOFYHdayAWCoZtb95U+U72Cm2HuZxcMfVlGKzDn9pnCpoVK7FWFyOTKIu8v7QDCdORTyxPZAD4= Received: from FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE (10.158.133.13) by FRAPR01MB0482.DEUPRD01.PROD.OUTLOOK.DE (10.158.133.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.11; Mon, 25 Sep 2017 13:56:43 +0000 Received: from FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE ([fe80::d1:57a:9b07:65a0]) by FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE ([fe80::d1:57a:9b07:65a0%15]) with mapi id 15.20.0056.018; Mon, 25 Sep 2017 13:56:37 +0000 From: "Jesske, Roland" To: Paul Kyzivat , "Dale R. Worley" CC: "sipcore@ietf.org" Thread-Topic: AW: [sipcore] I-D Action: draft-ietf-sipcore-reason-q850-loc-00.txt Thread-Index: AQHTNBNyHwns9Rd+Q2ur3wDOZdznMqLFIAvwgABzL4CAAA0H4A== Date: Mon, 25 Sep 2017 13:56:37 +0000 Message-ID: References: <12f8d596-49b2-78f0-bf10-832736d10902@alum.mit.edu> <87tvzub151.fsf@hobgoblin.ariadne.com> In-Reply-To: Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=R.Jesske@telekom.de; x-originating-ip: [164.19.3.109] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; FRAPR01MB0482; 6:e3qMu0LGmi+BgfvX7Yc1+487Ga9EEazmoVcP8OinNt6LEEOKdsDwIfFECsWszEfMBsFiE1ciVPr1FbCFZEx3ZYBGGQ8r5GYXDdtqoMAaCKbuLSVH4pmASBPQLHJW1jkFb67CfQ3UIf63CaJuYMIqusYPUAyBJoHRnHXwXA6QLPgdvxdX2sEWsnhPWTf0Xuqszcj4NNCeU3RZB6Cmbezyg3xNK9vzJ2FFOzb85aE2fwPHC41EfWHqUVYxAwZ3lBCjYcwU3sJq+B+mqw8r9K+rYGu4mYWYp26LOkvs4Q7pwK1Gbw6XIMtyOMwMsHbpg8dzVw1vSghoJxjYw/JJsH6t2w==; 5:uMdVHZ81yd3dNEdNj/nhQZKybEI5GKOzYYfj/Nq8b/r3fxy9zQ1qGuzCT73LjU38HU3tj9I+i/xv8J+EpMWWOzb97Ztb+dsbEviK3NcXsKtRsyMqRE7kcxC8O1TrL9PmMLnqT9ZPyrhjjGIcSBdFeQ==; 24:ZQL6rx8kM5sxkC12FHwW8Y7aQvD2mQ+O0uc2BO7Oi1vxRh7DjpOkQupRIFcYf5Y85hnEj1ucUVGKZ3L5+ymBt+vcMmGPMCeW841p8fXmQGQ=; 7:XoxVT4F9B1+XzeMqjVvn+044FjwKqjnnaiIq5dnBK5kCHPJgA9K7l8z1BTpSrB/a56tgdOlooyf8Ke+kHKfTifCuQJyMzpNa0skVnK32c4RveTJequWHiJ0hXqLApi20FJty2UGPRb1BweuGxvV4uSMIBBL/RgmF1ozprRVorQfr3MHt58Ftui/LhR9j9WenLgICIfVoFlyrjRWMgXj6BHy2ofcO2h9+iYowV+lVX5U= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: a13050b0-b1b4-40f7-6554-08d5041d3d98 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:FRAPR01MB0482; x-ms-traffictypediagnostic: FRAPR01MB0482: x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(6041248)(20161123564025)(20161123562025)(20161123560025)(20161123558100)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:FRAPR01MB0482; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:FRAPR01MB0482; x-forefront-prvs: 04410E544A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(377454003)(199003)(24454002)(189002)(2906002)(75402003)(4326008)(76176999)(106356001)(6306002)(55016002)(54356999)(9686003)(305945005)(50986999)(230783001)(6116002)(105586002)(14454004)(53936002)(7736002)(81156014)(68736007)(81166006)(3846002)(102836003)(8676002)(3280700002)(101416001)(2171002)(8936002)(33656002)(2950100002)(316002)(3660700001)(966005)(7696004)(97736004)(2900100001)(66066001)(86362001)(93886005)(110136005)(5250100002)(5660300001)(189998001)(74482002)(53546010)(72206003)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:FRAPR01MB0482; H:FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: telekom.de does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Sep 2017 13:56:37.5503 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f X-MS-Exchange-Transport-CrossTenantHeadersStamped: FRAPR01MB0482 X-OriginatorOrg: telekom.de Archived-At: Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-reason-q850-loc-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 13:57:06 -0000 SGkgUGF1bCwNCnllcyB5b3UgYXJlIHJpZ2h0Lg0KSSB3YXMgdG8gbGF6eSBpbiBsb29raW5nIGlu dG8gUS44NTAgd2hpY2ggZG9lcyBub3Qgd3JpdGUgb3V0IHRoZSBzcGFyZSB2YWx1ZXMuDQoNCjAg MCAwIDAgdXNlciAoVSkNCjAgMCAwIDEgcHJpdmF0ZSBuZXR3b3JrIHNlcnZpbmcgdGhlIGxvY2Fs IHVzZXIgKExQTikNCjAgMCAxIDAgcHVibGljIG5ldHdvcmsgc2VydmluZyB0aGUgbG9jYWwgdXNl ciAoTE4pDQowIDAgMSAxIHRyYW5zaXQgbmV0d29yayAoVE4pDQowIDEgMCAwIHB1YmxpYyBuZXR3 b3JrIHNlcnZpbmcgdGhlIHJlbW90ZSB1c2VyIChSTE4pDQowIDEgMCAxIHByaXZhdGUgbmV0d29y ayBzZXJ2aW5nIHRoZSByZW1vdGUgdXNlciAoUlBOKQ0KMCAxIDEgMSBpbnRlcm5hdGlvbmFsIG5l dHdvcmsgKElOVEwpDQoxIDAgMSAwIG5ldHdvcmsgYmV5b25kIGludGVyd29ya2luZyBwb2ludCAo QkkpDQoxIDEgMCAwIHJlc2VydmVkIGZvciBuYXRpb25hbCB1c2UNCjEgMSAwIDEgcmVzZXJ2ZWQg Zm9yIG5hdGlvbmFsIHVzZQ0KMSAxIDEgMCByZXNlcnZlZCBmb3IgbmF0aW9uYWwgdXNlDQoxIDEg MSAxIHJlc2VydmVkIGZvciBuYXRpb25hbCB1c2UNCg0KU28gSSB3YXMgbWlzc2luZyB0aGUgQml0 IHZhbHVlcyANCjAxMTANCjEwMDANCjEwMDENCg0KT2sgSSB3aWxsIHJld3JpdGUgYSBsaXR0bGUg bGlrZToNCg0KVSAgICBmb3IgdXNlciANCkxQTiAgZm9yIHByaXZhdGUgbmV0d29yayBzZXJ2aW5n IHRoZSBsb2NhbCB1c2VyDQpMTiAgIGZvciBwdWJsaWMgbmV0d29yayBzZXJ2aW5nIHRoZSBsb2Nh bCB1c2VyIA0KVE4gICAgICAgIGZvciB0cmFuc2l0IG5ldHdvcmsgDQpSTE4gIGZvciBwdWJsaWMg bmV0d29yayBzZXJ2aW5nIHRoZSByZW1vdGUgdXNlciANClJQTiAgZm9yIHByaXZhdGUgbmV0d29y ayBzZXJ2aW5nIHRoZSByZW1vdGUgdXNlciANClNwYXJlLTEgcmVmbGVjdGluZyBRODUwIGJpbmFy eSB2YWx1ZSAwIDEgMSAwDQpJTlRMIGZvciBpbnRlcm5hdGlvbmFsIG5ldHdvcmsgDQpTcGFyZS0y IHJlZmxlY3RpbmcgUTg1MCBiaW5hcnkgdmFsdWUgMSAwIDAgMA0KU3BhcmUtMyByZWZsZWN0aW5n IFE4NTAgYmluYXJ5IHZhbHVlIDEgMCAwIDENCkJJICAgZm9yIG5ldHdvcmsgYmV5b25kIGludGVy d29ya2luZyBwb2ludA0KTE9DLTEyICBRLjg1MCB2YWx1ZSByZXNlcnZlZCBmb3IgbmF0aW9uYWwg dXNlIHJlZmxlY3RpbmcgUTg1MCBiaW5hcnkgdmFsdWUgMSAwIDEgMA0KTE9DLTEzICBRLjg1MCB2 YWx1ZSByZXNlcnZlZCBmb3IgbmF0aW9uYWwgdXNlIHJlZmxlY3RpbmcgUTg1MCBiaW5hcnkgdmFs dWUgMSAwIDEgMQ0KTE9DLTE0ICBRLjg1MCB2YWx1ZSByZXNlcnZlZCBmb3IgbmF0aW9uYWwgdXNl IHVzZSByZWZsZWN0aW5nIFE4NTAgYmluYXJ5IHZhbHVlIDEgMSAxIDANCkxPQy0xNSAgUS44NTAg dmFsdWUgcmVzZXJ2ZWQgZm9yIG5hdGlvbmFsIHVzZSB1c2UgcmVmbGVjdGluZyBRODUwIGJpbmFy eSB2YWx1ZSAxIDEgMSAxDQoNClNvIEkgcHJvcG9zZSB0byB1c2UgdGhlIHZhbHVlcyBTcGFyZS0x LCAtMiBhbmQgLTMuDQpJIGhvcGUgSSBkaWQgbm90IG1pc3MgYW55IG1vcmUuDQoNCkJlc3QgUmVn YXJkcw0KDQpSb2xhbmQNCj4gLS0tLS1VcnNwcsO8bmdsaWNoZSBOYWNocmljaHQtLS0tLQ0KPiBW b246IFBhdWwgS3l6aXZhdCBbbWFpbHRvOnBreXppdmF0QGFsdW0ubWl0LmVkdV0NCj4gR2VzZW5k ZXQ6IE1vbnRhZywgMjUuIFNlcHRlbWJlciAyMDE3IDE0OjU2DQo+IEFuOiBKZXNza2UsIFJvbGFu ZCA8Ui5KZXNza2VAdGVsZWtvbS5kZT47IERhbGUgUi4gV29ybGV5DQo+IDx3b3JsZXlAYXJpYWRu ZS5jb20+DQo+IENjOiBzaXBjb3JlQGlldGYub3JnDQo+IEJldHJlZmY6IFJlOiBBVzogW3NpcGNv cmVdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtc2lwY29yZS1yZWFzb24tcTg1MC1sb2MtDQo+IDAw LnR4dA0KPiANCj4gT24gOS8yNS8xNyAyOjMwIEFNLCBKZXNza2UsIFJvbGFuZCB3cm90ZToNCj4g PiBIaSBEYWxlIGFuZCBQYXVsLA0KPiA+IFlvdSBhcmUgcmlnaHQgd2l0aCB0aGUgYWRkaXRpb24g b2Ygc3VjaCB2YWx1ZXMsIGV2ZXJ5Ym9keSBoYXMgdGhlDQo+IHBvc3NpYmlsaXRpZXMgdG8gaW50 ZXJ3b3JrIGl0J3Mgb3duIHBhcmFtZXRlcnMgZm9yIG5hdGlvbmFsL29wZXJhdG9yIHVzZS4NCj4g PiBTbyBJIHdpbGwgY2hhbmdlIHRoZSB0YWJsZSB0bzoNCj4gPg0KPiA+IFRoZSBmb2xsb3dpbmcg dmFsdWVzIHNoYWxsIGJlIHVzZWQgYXMgbG9jYXRpb246DQo+ID4gVSAgICBmb3IgdXNlcg0KPiA+ IExQTiAgZm9yIHByaXZhdGUgbmV0d29yayBzZXJ2aW5nIHRoZSBsb2NhbCB1c2VyDQo+ID4gTE4g ICBmb3IgcHVibGljIG5ldHdvcmsgc2VydmluZyB0aGUgbG9jYWwgdXNlcg0KPiA+IFROICAgICAg ICBmb3IgdHJhbnNpdCBuZXR3b3JrDQo+ID4gUkxOICBmb3IgcHVibGljIG5ldHdvcmsgc2Vydmlu ZyB0aGUgcmVtb3RlIHVzZXIgUlBOICBmb3IgcHJpdmF0ZQ0KPiA+IG5ldHdvcmsgc2VydmluZyB0 aGUgcmVtb3RlIHVzZXIgSU5UTCBmb3IgaW50ZXJuYXRpb25hbCBuZXR3b3JrDQo+ID4gQkkgICBm b3IgbmV0d29yayBiZXlvbmQgaW50ZXJ3b3JraW5nIHBvaW50DQo+ID4gTE9DLTEyICBRLjg1MCB2 YWx1ZSByZXNlcnZlZCBmb3IgbmF0aW9uYWwgdXNlDQo+ID4gTE9DLTEzICBRLjg1MCB2YWx1ZSBy ZXNlcnZlZCBmb3IgbmF0aW9uYWwgdXNlDQo+ID4gTE9DLTE0ICBRLjg1MCB2YWx1ZSByZXNlcnZl ZCBmb3IgbmF0aW9uYWwgdXNlDQo+ID4gTE9DLTE1ICBRLjg1MCB2YWx1ZSByZXNlcnZlZCBmb3Ig bmF0aW9uYWwgdXNlDQo+IA0KPiBUaGVyZSBhcmUgc3RpbGwgNCBvdGhlciB2YWx1ZXMuIEkgcmVj b21tZW5kIGNvdmVyaW5nIHRoZW0gYXMgd2VsbC4NCj4gDQo+IAlUaGFua3MsDQo+IAlQYXVsDQo+ IA0KPiA+IEFyZSBZb3UgT0sgd2l0aCB0aGF0Pw0KPiA+DQo+ID4gQmVzdCBSZWdhcmRzDQo+ID4N Cj4gPiBSb2xhbmQNCj4gPg0KPiA+DQo+ID4+IC0tLS0tVXJzcHLDvG5nbGljaGUgTmFjaHJpY2h0 LS0tLS0NCj4gPj4gVm9uOiBzaXBjb3JlIFttYWlsdG86c2lwY29yZS1ib3VuY2VzQGlldGYub3Jn XSBJbSBBdWZ0cmFnIHZvbiBEYWxlIFIuDQo+ID4+IFdvcmxleQ0KPiA+PiBHZXNlbmRldDogU2Ft c3RhZywgMjMuIFNlcHRlbWJlciAyMDE3IDA0OjI3DQo+ID4+IEFuOiBQYXVsIEt5eml2YXQgPHBr eXppdmF0QGFsdW0ubWl0LmVkdT4NCj4gPj4gQ2M6IHNpcGNvcmVAaWV0Zi5vcmc7IEplc3NrZSwg Um9sYW5kIDxSLkplc3NrZUB0ZWxla29tLmRlPg0KPiA+PiBCZXRyZWZmOiBSZTogW3NpcGNvcmVd IEktRCBBY3Rpb246DQo+ID4+IGRyYWZ0LWlldGYtc2lwY29yZS1yZWFzb24tcTg1MC1sb2MtMDAu dHh0DQo+ID4+DQo+ID4+IFBhdWwgS3l6aXZhdCA8cGt5eml2YXRAYWx1bS5taXQuZWR1PiB3cml0 ZXM6DQo+ID4+PiBJbnN0ZWFkIG9mIHRoYXQsIGhvdyBhYm91dCBqdXN0IGRlZmluaW5nIHNvbWUg dG9rZW5zIG5vdyBmb3IgYWxsIHRoZQ0KPiA+Pj4gb3RoZXIgY29kZSBwb2ludHMuIChFLmcuIE5B VElPTkFMLTEsIE5BVElPTk9BTC0yLCAuLi4gLCBSRVNFUlZFRC0xLA0KPiA+Pj4gUkVTRVJWRUQt MiwgLi4uICpvciogdmFsdWVzIHRoYXQgY29ycmVzcG9uZCBkaXJlY3RseSB0byB0aGUgYmluYXJ5 DQo+ID4+PiBjb2RpbmcsIHN1Y2ggYXMgTE9DLTEyLCBMT0MtMTMsIExPQy0xNCwgTE9DLTE1KS4g VGhhdCB3YXksIGlmDQo+ID4+PiBpbnRlcndvcmtpbmcgY29tZXMgYWNyb3NzIG9uZSBvZiB0aG9z ZSBpdCBjYW4gYmUgbWFwcGVkDQo+ID4+PiBiaWRpcmVjdGlvbmFsbHkgdG8gU0lQLg0KPiA+Pg0K PiA+PiBJIGNhbiBzZWUgdGhlIGFkdmFudGFnZSBvZiBwcm92aWRpbmcgdG9rZW5zIGZvciBhbGwg b2YgdGhlIFEuODUwDQo+ID4+IHZhbHVlcywgYmVjYXVzZSBhcyBQYXVsIHNheXMsIHNvbWVib2R5 IG1pZ2h0IGJlIHVzaW5nIHRoZW0gd2l0aGluIGENCj4gPj4gbmV0d29yay4gIEFzIFJvbGFuZCBz YXlzLCB0aGUgUS44NTAgKnN5c3RlbSogaXMgdW5saWtlbHkgdG8gYmUNCj4gPj4gY2hhbmdlZCBp biB0aGUgZnV0dXJlLCBzbyB3ZSBjYW4gcHJvdmlkZSBhIGNvbXBsZXRlIHNldCBvZiB0cmFuc2xh dGlvbnMgb2YNCj4gYWxsIHBvc3NpYmxlIHZhbHVlcy4NCj4gPj4gSWYgc29tZWJvZHkgaXMgdXNp bmcgdGhlc2UgdmFsdWVzLCB0aGV5IGNhbiBpbnRlcndvcmsgd2l0aCBTSVANCj4gPj4gd2l0aG91 dCBhc2tpbmcgZWl0aGVyIElUVS1UIG9yIHRoZSBJRVRGIHRvIHByb3ZpZGUgYSBtYXBwaW5nLg0K PiA+Pg0KPiA+PiBEYWxlDQo+ID4+DQo+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+ID4+IHNpcGNvcmUgbWFpbGluZyBsaXN0DQo+ID4+IHNpcGNv cmVAaWV0Zi5vcmcNCj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9z aXBjb3JlDQo+ID4NCg0K From nobody Mon Sep 25 07:48:19 2017 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 968C313448F for ; Mon, 25 Sep 2017 07:48:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=credil.org 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 UrAb8jamuyQb for ; Mon, 25 Sep 2017 07:48:17 -0700 (PDT) Received: from homiemail-a55.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2C17126BF3 for ; Mon, 25 Sep 2017 07:48:01 -0700 (PDT) Received: from homiemail-a55.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTP id 2BD8A68003C1C; Mon, 25 Sep 2017 07:48:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=credil.org; h=references :from:to:cc:subject:in-reply-to:date:message-id:mime-version :content-type:content-transfer-encoding; s=credil.org; bh=49PVH3 8Zo02n9BgS233WgAP5GV0=; b=kIdLKZwGDWX1tzpZOTblP0Ml/12MbsLve36ypp scqUMI0qErrXvYE0PkUL2eti97iNDpliZL6X0v1i4UTU1FHaGtRuyojOxxHUH94N LczLmiX9wnAxjZo04WknUQhHZ0vdWOj7zzfhOJ158VTnD+wmxultQ4QWIyV2noU6 myH1g= Received: from toki.strangled.net (ppp-199-167-117-191.storm.ca [199.167.117.191]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: justin@credil.org) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTPSA id C630168003C23; Mon, 25 Sep 2017 07:48:00 -0700 (PDT) References: User-agent: mu4e 0.9.17; emacs 25.0.50.3 From: Justin Hornosty To: Christer Holmberg Cc: "sipcore\@ietf.org" In-reply-to: Date: Mon, 25 Sep 2017 10:47:58 -0400 Message-ID: <87lgl2bzs1.fsf@toki.strangled.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [sipcore] SIP PUSH X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 14:48:19 -0000 Christer Holmberg writes: > There is a problem with iOS SIP/VoIP applications (I understand the sam= e is coming to Android too): the application need to be =E2=80=9Cwoken up= =E2=80=9D using the Apple Push Mechanism, in order to e.g., be able to ac= cept incoming INVITE requests. In earlier iOS versions an incoming reques= t could wake up the application. What is the situation with Android? Is the rational that Android and iOS want to stop app developers from writing poor keep alive / background services for the various messaging apps (that have the tendency to eat battery life and bandwidth) or am I missing something? -jjrh From nobody Mon Sep 25 08:05:35 2017 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 C662D13448E for ; Mon, 25 Sep 2017 08:05:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 y7Z5ZWGXJApB for ; Mon, 25 Sep 2017 08:05:32 -0700 (PDT) Received: from alum-mailsec-scanner-7.mit.edu (alum-mailsec-scanner-7.mit.edu [18.7.68.19]) by ietfa.amsl.com (Postfix) with ESMTP id D8D1B134496 for ; Mon, 25 Sep 2017 08:05:31 -0700 (PDT) X-AuditID: 12074413-38bff70000007929-13-59c91b3ac80a Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id BC.08.31017.A3B19C95; Mon, 25 Sep 2017 11:05:30 -0400 (EDT) Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id v8PF5TvI015390 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 25 Sep 2017 11:05:29 -0400 To: "Jesske, Roland" , "Dale R. Worley" Cc: "sipcore@ietf.org" References: <12f8d596-49b2-78f0-bf10-832736d10902@alum.mit.edu> <87tvzub151.fsf@hobgoblin.ariadne.com> From: Paul Kyzivat Message-ID: <009fd519-99db-1d7f-470a-efab4b88fc52@alum.mit.edu> Date: Mon, 25 Sep 2017 11:05:29 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplleLIzCtJLcpLzFFi42IRYndR1LWSPhlpsPugpUXTnS42i68/NrFZ vDxR5sDsMXn/V2aPJUt+Mnm0vVQIYI7isklJzcksSy3St0vgyljSs4ypYL9qxa6bdxgbGK/K djFyckgImEjs/rmUvYuRi0NIYAeTROPGKcwQzkMmifMPJjF1MXJwCAuEScx6IwTSICIQJXFh 7i12EJtZQFNi87oLUM2HmCS6VpxlBEmwCWhJzDn0nwXE5hWwlzi95wqYzSKgKnF96X5WEFtU IE3i326Iel4BQYmTM5+A1XAKxEhM3vgfaoGZxLzND5khbHGJW0/mM0HY8hLNW2czT2AUmIWk fRaSlllIWmYhaVnAyLKKUS4xpzRXNzcxM6c4NVm3ODkxLy+1SNdcLzezRC81pXQTIySkhXcw 7jopd4hRgINRiYe3gelkpBBrYllxZe4hRkkOJiVR3rt8JyKF+JLyUyozEosz4otKc1KLDzFK cDArifBe5wQq501JrKxKLcqHSUlzsCiJ86otUfcTEkhPLEnNTk0tSC2CycpwcChJ8JpIATUK FqWmp1akZeaUIKSZODhBhvMADW8AqeEtLkjMLc5Mh8ifYtTl6Om58YdJiCUvPy9VSpxXVhKo SACkKKM0D24OLBW9YhQHekuYVxJkFA8wjcFNegW0hAloSe/UEyBLShIRUlINjPYnrrdkH1a2 z51Sw7U9ZNHeNXNyWBqPnFO02L648k7I1s3b/jySvm1ebPx65VmTOVlxaxlefM+XUtv54+oX b8MW1YATDh4Tz7Ge3GP8V/KOrK6fUcEPu5O/KlUWbox78v+gYLvO56+i056eiN27SvKy6rHs R932s/5XPueatThW+OCd7na3h0pKLMUZiYZazEXFiQBNbu3HIAMAAA== Archived-At: Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-reason-q850-loc-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 15:05:34 -0000 On 9/25/17 9:56 AM, Jesske, Roland wrote: > Hi Paul, > yes you are right. > I was to lazy in looking into Q.850 which does not write out the spare values. > > 0 0 0 0 user (U) > 0 0 0 1 private network serving the local user (LPN) > 0 0 1 0 public network serving the local user (LN) > 0 0 1 1 transit network (TN) > 0 1 0 0 public network serving the remote user (RLN) > 0 1 0 1 private network serving the remote user (RPN) > 0 1 1 1 international network (INTL) > 1 0 1 0 network beyond interworking point (BI) > 1 1 0 0 reserved for national use > 1 1 0 1 reserved for national use > 1 1 1 0 reserved for national use > 1 1 1 1 reserved for national use > > So I was missing the Bit values > 0110 > 1000 > 1001 > > Ok I will rewrite a little like: > > U for user > LPN for private network serving the local user > LN for public network serving the local user > TN for transit network > RLN for public network serving the remote user > RPN for private network serving the remote user > Spare-1 reflecting Q850 binary value 0 1 1 0 > INTL for international network > Spare-2 reflecting Q850 binary value 1 0 0 0 > Spare-3 reflecting Q850 binary value 1 0 0 1 > BI for network beyond interworking point > LOC-12 Q.850 value reserved for national use reflecting Q850 binary value 1 0 1 0 > LOC-13 Q.850 value reserved for national use reflecting Q850 binary value 1 0 1 1 > LOC-14 Q.850 value reserved for national use use reflecting Q850 binary value 1 1 1 0 > LOC-15 Q.850 value reserved for national use use reflecting Q850 binary value 1 1 1 1 > > So I propose to use the values Spare-1, -2 and -3. > I hope I did not miss any more. Just count the values. If there aren't 16 then some are missing. You are still missing 1011. :-) Spare-4. You might want to make those upper case for consistency. Thanks, Paul > Best Regards > > Roland >> -----Ursprüngliche Nachricht----- >> Von: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Gesendet: Montag, 25. September 2017 14:56 >> An: Jesske, Roland ; Dale R. Worley >> >> Cc: sipcore@ietf.org >> Betreff: Re: AW: [sipcore] I-D Action: draft-ietf-sipcore-reason-q850-loc- >> 00.txt >> >> On 9/25/17 2:30 AM, Jesske, Roland wrote: >>> Hi Dale and Paul, >>> You are right with the addition of such values, everybody has the >> possibilities to interwork it's own parameters for national/operator use. >>> So I will change the table to: >>> >>> The following values shall be used as location: >>> U for user >>> LPN for private network serving the local user >>> LN for public network serving the local user >>> TN for transit network >>> RLN for public network serving the remote user RPN for private >>> network serving the remote user INTL for international network >>> BI for network beyond interworking point >>> LOC-12 Q.850 value reserved for national use >>> LOC-13 Q.850 value reserved for national use >>> LOC-14 Q.850 value reserved for national use >>> LOC-15 Q.850 value reserved for national use >> >> There are still 4 other values. I recommend covering them as well. >> >> Thanks, >> Paul >> >>> Are You OK with that? >>> >>> Best Regards >>> >>> Roland >>> >>> >>>> -----Ursprüngliche Nachricht----- >>>> Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von Dale R. >>>> Worley >>>> Gesendet: Samstag, 23. September 2017 04:27 >>>> An: Paul Kyzivat >>>> Cc: sipcore@ietf.org; Jesske, Roland >>>> Betreff: Re: [sipcore] I-D Action: >>>> draft-ietf-sipcore-reason-q850-loc-00.txt >>>> >>>> Paul Kyzivat writes: >>>>> Instead of that, how about just defining some tokens now for all the >>>>> other code points. (E.g. NATIONAL-1, NATIONOAL-2, ... , RESERVED-1, >>>>> RESERVED-2, ... *or* values that correspond directly to the binary >>>>> coding, such as LOC-12, LOC-13, LOC-14, LOC-15). That way, if >>>>> interworking comes across one of those it can be mapped >>>>> bidirectionally to SIP. >>>> >>>> I can see the advantage of providing tokens for all of the Q.850 >>>> values, because as Paul says, somebody might be using them within a >>>> network. As Roland says, the Q.850 *system* is unlikely to be >>>> changed in the future, so we can provide a complete set of translations of >> all possible values. >>>> If somebody is using these values, they can interwork with SIP >>>> without asking either ITU-T or the IETF to provide a mapping. >>>> >>>> Dale >>>> >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>> > From nobody Mon Sep 25 08:22:32 2017 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 08FA813448E for ; Mon, 25 Sep 2017 08:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=sonusnetworks.onmicrosoft.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 x-TglhMDCRrz for ; Mon, 25 Sep 2017 08:22:27 -0700 (PDT) Received: from us-smtp-delivery-126.mimecast.com (us-smtp-delivery-126.mimecast.com [63.128.21.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 816FB133087 for ; Mon, 25 Sep 2017 08:22:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=wxPpSEe/qf/Mcv3nPkPPIPrqhO0TCOgnqDegYOyl7Xw=; b=sxEM93+o1sj/EZp5zR5omfkwT5eChcwUYXJpKWB0QFydX5CL6+MNXO8mx0nF9ikYl3ArDW71+y+G0mdCxXbBVEmVSia9OSUkZUaqfugbm6UUOUOxBXl0jxwawlHLipR9DZ9sG8oggPpCOOTgsKp5t1sBdX0JCm1PhNDQ9o/mdpQ= Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02lp0050.outbound.protection.outlook.com [207.46.163.50]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-132-QAhVmq-UNzapZkt77OT-Pw-1; Mon, 25 Sep 2017 11:22:22 -0400 Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB2349.namprd03.prod.outlook.com (10.166.210.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Mon, 25 Sep 2017 15:22:21 +0000 Received: from SN2PR03MB2350.namprd03.prod.outlook.com ([fe80::d88f:793d:af1f:f651]) by SN2PR03MB2350.namprd03.prod.outlook.com ([fe80::d88f:793d:af1f:f651%18]) with mapi id 15.20.0077.011; Mon, 25 Sep 2017 15:22:20 +0000 From: "Asveren, Tolga" To: Christer Holmberg , "sipcore@ietf.org" Thread-Topic: SIP PUSH Thread-Index: AQHTNfOMhpjgVdXGfkOKwB3589Ama6LFhdJQgAAWNAD///iEgA== Date: Mon, 25 Sep 2017 15:22:20 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [73.29.18.75] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN2PR03MB2349; 20:0gV8mutYtrbsPEobjjcvS00FtIxFyhy6/KFQhBwviTF/BUB1PLzuRpUiNaOernrKGYriQAgAkGE18c0Cc2G7tgwGOUbeDq/4nwaf6XDLDhkdecqHsVQoSSoqUqiQSmxWNDlNXNXMu2IBqCFI57/P+FQWww6bWh5vCfFQpj/bf2Y= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: c1025fe3-4530-4634-df52-08d50429373a x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:SN2PR03MB2349; x-ms-traffictypediagnostic: SN2PR03MB2349: x-exchange-antispam-report-test: UriScan:(37575265505322)(158342451672863)(278428928389397)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3002001)(6041248)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123558100)(20161123562025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:SN2PR03MB2349; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:SN2PR03MB2349; x-forefront-prvs: 04410E544A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39830400002)(346002)(376002)(199003)(189002)(377454003)(54896002)(966005)(2501003)(54356999)(6306002)(76176999)(221733001)(66066001)(6246003)(25786009)(33656002)(2900100001)(14454004)(53936002)(106356001)(9686003)(99286003)(105586002)(50986999)(236005)(2906002)(101416001)(86362001)(110136005)(55016002)(3280700002)(189998001)(53546010)(5660300001)(3846002)(7116003)(3660700001)(8676002)(8936002)(81166006)(81156014)(7696004)(316002)(478600001)(3480700004)(229853002)(97736004)(5250100002)(19609705001)(6116002)(74316002)(6506006)(6436002)(7736002)(102836003)(790700001)(606006)(68736007)(2950100002); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB2349; H:SN2PR03MB2350.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Sep 2017 15:22:20.7849 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2349 X-MC-Unique: QAhVmq-UNzapZkt77OT-Pw-1 Content-Type: multipart/alternative; boundary="_000_SN2PR03MB2350FE22C471BEDC155B3DFEB27A0SN2PR03MB2350namp_" Archived-At: Subject: Re: [sipcore] SIP PUSH X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 15:22:30 -0000 --_000_SN2PR03MB2350FE22C471BEDC155B3DFEB27A0SN2PR03MB2350namp_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Why can't the AoR of the SIP UA -and a token if still necessary- be provide= d by the Push Server to the SIP Proxy directly (together with other informa= tion, e.g. what should trigger SIP Proxy to alert the Push Server)? All thi= s information can be sent from SIP UA to the Push Server AFAICS. Thanks, Tolga From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Monday, September 25, 2017 8:36 AM To: Asveren, Tolga ; sipcore@ietf.org Subject: Re: SIP PUSH Hi, >What is the advantage of this strategy v.s. Push Server communicating dire= ctly with the SIP Proxy/Registrar etc... through a non-SIP, e.g. REST API b= ased, interface? The Push Server DOES communicate with the SIP Proxy/Registrar using a non-S= IP interface. Those interfaces are provided by Apple (or whoever provides t= he push server), and we don't suggest to change those. When the SIP UA registers itself with the Push Server, it receives a unique= token. The SIP UA needs to inform the proxy about that token (and, inform = the proxy that it is an Apple token), so that the proxy can provide it to t= he Push Server when the incoming call comes. SO, what we need is a way for the SIP UA to provide the token to the proxy. Regards, Christer From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmb= erg Sent: Monday, September 25, 2017 7:44 AM To: sipcore@ietf.org Subject: [sipcore] SIP PUSH Hi, There is a problem with iOS SIP/VoIP applications (I understand the same is= coming to Android too): the application need to be "woken up" using the Ap= ple Push Mechanism, in order to e.g., be able to accept incoming INVITE req= uests. In earlier iOS versions an incoming request could wake up the applic= ation. A solution has been discussed, where a SIP proxy (or some other network ent= ity) informs the Apple Push Server when an incoming call for Alice is comi= ng, the Apple Push Server wakes up Alice's UA VoIP application, which is th= en able to receive the INVITE request. In order to do this, the UA needs to provide some information (e.g., which = push server is used, the Alice's VoIP application specific push identifier = etc) to the SIP network during registration. There is a real need for a solution in the market, and I know that people a= re looking at a number of different proprietary solutions - which can cause= a real mess in the long run. Therefor I think it would be VERY important t= o produce a standardised way of doing this. There IS a draft on this: https://tools.ietf.org/html/draft-ivanov-sipcore-pnsip-01 The draft uses URI parameters. We think that media feature tags should be u= sed instead. Also, we think at least one additional parameter is needed. Bu= t, in general we think the draft provides a good solution. I haven't managed to contact the draft author, as my e-mails are rejected. = But, if he is reading this, or if someone else is able to contact him, I'd = like to get in contact with him :) Regards, Christer --_000_SN2PR03MB2350FE22C471BEDC155B3DFEB27A0SN2PR03MB2350namp_ Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable

Why can’t the AoR of the SIP UA -and a token i= f still necessary- be provided by the Push Server to the SIP Proxy directly= (together with other information, e.g. what should trigger SIP Proxy to al= ert the Push Server)? All this information can be sent from SIP UA to the Push Server AFAICS.

 

Thanks,

Tolga

 

From: Christer Holmberg [mailto:christer.holm= berg@ericsson.com]
Sent: Monday, September 25, 2017 8:36 AM
To: Asveren, Tolga <tasveren@sonusnet.com>; sipcore@ietf.org Subject: Re: SIP PUSH

 

Hi,

&n= bsp;

>What is the advantag= e of this strategy v.s. Push Server communicating directly with the SIP Pro= xy/Registrar etc… through a non-SIP, e.g. REST API based, interface?<= o:p>

&n= bsp;

The Pus= h Server DOES communicate with the SIP Proxy/Registrar using a non-SIP inte= rface. Those interfaces are provided by Apple (or whoever provides the push= server), and we don’t suggest to change those.

&n= bsp;

When th= e SIP UA registers itself with the Push Server, it receives a unique token.= The SIP UA needs to inform the proxy about that token (and, inform the pro= xy that it is an Apple token), so that the proxy can provide it to the Push Server when the incoming call comes.&= nbsp;

&n= bsp;

SO, wha= t we need is a way for the SIP UA to provide the token to the proxy.

&n= bsp;

Regards= ,

&n= bsp;

Christe= r

&n= bsp;

 =

From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: Monday, September 25, 2017 7:44 AM
To: sipcore@ietf.org
Subject: [sipcore] SIP PUSH

 =

Hi,

 <= /span>

There i= s a problem with iOS SIP/VoIP applications (I understand the same is coming= to Android too): the application need to be “woken up” using t= he Apple Push Mechanism, in order to e.g., be able to accept incoming INVITE requests. In earlier iOS versions an incoming re= quest could wake up the application.

 <= /span>

A solut= ion has been discussed, where a SIP proxy (or some other network entity) in= forms the Apple Push Server when an incoming call  for Alice is coming= , the Apple Push Server wakes up Alice's UA VoIP application, which is then able to receive the INVITE request.

 <= /span>

In orde= r to do this, the UA needs to provide some information (e.g., which push se= rver is used, the Alice’s VoIP application specific push identifier e= tc) to the SIP network during registration.

 <= /span>

There i= s a real need for a solution in the market, and I know that people are look= ing at a number of different proprietary solutions – which can cause = a real mess in the long run. Therefor I think it would be VERY important to produce a standardised way of doing this.

 <= /span>

There I= S a draft on this:

 <= /span>

 <= /span>

The dra= ft uses URI parameters. We think that media feature tags should be used ins= tead. Also, we think at least one additional parameter is needed. But, in g= eneral we think the draft provides a good solution.

 <= /span>

I haven= ’t managed to contact the draft author, as my e-mails are rejected. B= ut, if he is reading this, or if someone else is able to contact him, IR= 17;d like to get in contact with him :)<= o:p>

 <= /span>

Regards= ,

 <= /span>

Christe= r

 <= /span>

--_000_SN2PR03MB2350FE22C471BEDC155B3DFEB27A0SN2PR03MB2350namp_-- From nobody Mon Sep 25 09:15:04 2017 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 338A21344BC for ; Mon, 25 Sep 2017 09:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.72 X-Spam-Level: X-Spam-Status: No, score=-3.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, 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 W1qwES3pbhs3 for ; Mon, 25 Sep 2017 09:15:00 -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 46B99132025 for ; Mon, 25 Sep 2017 09:14:59 -0700 (PDT) X-AuditID: c1b4fb2d-a65ff700000019be-a8-59c92b823ee9 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 29.84.06590.28B29C95; Mon, 25 Sep 2017 18:14:58 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.6]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0352.000; Mon, 25 Sep 2017 18:14:57 +0200 From: Christer Holmberg To: "Asveren, Tolga" , "sipcore@ietf.org" Thread-Topic: SIP PUSH Thread-Index: AQHTNfOMhpjgVdXGfkOKwB3589Ama6LFhdJQgAAWNAD///iEgIAALwNQ Date: Mon, 25 Sep 2017 16:14:57 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B562F6AE1@ESESSMB109.ericsson.se> References: 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.149] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B562F6AE1ESESSMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmkeLIzCtJLcpLzFFi42KZGbHdVbdJ+2SkwY7rEhZff2xis5jd+Z7J gcljyZKfTB6XPv9nD2CK4rJJSc3JLEst0rdL4Mo4e+ggU8G86YwVVz9/Z21g3N7M2MXIySEh YCKx//tC1i5GLg4hgSOMEj1rDjJDOIsYJab27ADKcHCwCVhIdP/TBmkQEQiVmPSgEaxZWEBU 4uttkGaQuJjEr0k3WCBsN4ktn64wgdgsAqoS598sA4vzCvhKvHqygBFi/mQmiWfHLoMN4hSI lWj9/YcdxGYEGvT91BqwZmYBcYlbT+YzQVwqILFkz3lmCFtU4uXjf6wQtpLE2sPbWSDq8yWO rnjODLFMUOLkzCcsExiFZyEZNQtJ2SwkZRBxHYkFuz+xQdjaEssWvmaGsc8ceMyELL6AkX0V o2hxanFxbrqRsV5qUWZycXF+nl5easkmRmAUHdzyW3cH4+rXjocYBTgYlXh4fRVORgqxJpYV V+YeYpTgYFYS4f2iChTiTUmsrEotyo8vKs1JLT7EKM3BoiTO67DvQoSQQHpiSWp2ampBahFM lomDU6qBUVZrxRfZD/OnrAtZlqO05r9OSLSMmW/lTX/mj5NuzFv5+MYfu3P305dvetu07SUb 28Gg/u3yS4v+TdsTZarlF/Bc6USMo/XBix6fn5vzn7y77WGr5u4kl1UP132v2e3R/ta/vO7L PaXvFh/mzm081rqE/W7V8mWaimUhPTXWRl7RD1zCZqmyeiqxFGckGmoxFxUnAgBay8VBngIA AA== Archived-At: Subject: Re: [sipcore] SIP PUSH X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 16:15:03 -0000 --_000_7594FB04B1934943A5C02806D1A2204B562F6AE1ESESSMB109erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, > Why can't the AoR of the SIP UA -and a token if still necessary- be provi= ded by the Push Server to the SIP Proxy > directly (together with other information, e.g. what should trigger SIP P= roxy to alert the Push Server)? I don't know if the push server can distribute the information to proxies. And, even if the proxy can distribute the information, it does not know whi= ch proxies each user is going to use. It would have to distribute the infor= mation of each user to each proxy. The idea is that the proxy that the user uses will have the token, and that= proxy will then send the token to the push server and ask it to wake up th= e user associated with the token. >All this information can be sent from SIP UA to the Push Server AFAICS. I don't know how much additional information you can send to the Push Serve= rs. And, if you start sending AoRs etc you may end up with privacy issues. = The idea is that the push server doesn't have any SIP user information - it= only knows to which device a token-id belongs. The suggested solution is very simple - the user simply provides the token = in the REGISTER request, and the proxy will store it. That should work for = all push servers. Regards, Christer From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Monday, September 25, 2017 8:36 AM To: Asveren, Tolga >; s= ipcore@ietf.org Subject: Re: SIP PUSH Hi, >What is the advantage of this strategy v.s. Push Server communicating dire= ctly with the SIP Proxy/Registrar etc... through a non-SIP, e.g. REST API b= ased, interface? The Push Server DOES communicate with the SIP Proxy/Registrar using a non-S= IP interface. Those interfaces are provided by Apple (or whoever provides t= he push server), and we don't suggest to change those. When the SIP UA registers itself with the Push Server, it receives a unique= token. The SIP UA needs to inform the proxy about that token (and, inform = the proxy that it is an Apple token), so that the proxy can provide it to t= he Push Server when the incoming call comes. SO, what we need is a way for the SIP UA to provide the token to the proxy. Regards, Christer From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmb= erg Sent: Monday, September 25, 2017 7:44 AM To: sipcore@ietf.org Subject: [sipcore] SIP PUSH Hi, There is a problem with iOS SIP/VoIP applications (I understand the same is= coming to Android too): the application need to be "woken up" using the Ap= ple Push Mechanism, in order to e.g., be able to accept incoming INVITE req= uests. In earlier iOS versions an incoming request could wake up the applic= ation. A solution has been discussed, where a SIP proxy (or some other network ent= ity) informs the Apple Push Server when an incoming call for Alice is comi= ng, the Apple Push Server wakes up Alice's UA VoIP application, which is th= en able to receive the INVITE request. In order to do this, the UA needs to provide some information (e.g., which = push server is used, the Alice's VoIP application specific push identifier = etc) to the SIP network during registration. There is a real need for a solution in the market, and I know that people a= re looking at a number of different proprietary solutions - which can cause= a real mess in the long run. Therefor I think it would be VERY important t= o produce a standardised way of doing this. There IS a draft on this: https://tools.ietf.org/html/draft-ivanov-sipcore-pnsip-01 The draft uses URI parameters. We think that media feature tags should be u= sed instead. Also, we think at least one additional parameter is needed. Bu= t, in general we think the draft provides a good solution. I haven't managed to contact the draft author, as my e-mails are rejected. = But, if he is reading this, or if someone else is able to contact him, I'd = like to get in contact with him :) Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B562F6AE1ESESSMB109erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

> Why can’t the AoR of= the SIP UA -and a token if still necessary- be provided by the Push Server= to the SIP Proxy

> directly (together with other information, e.g. what should trigger SIP P= roxy to alert the Push Server)?

 

I don’t know if the push = server can distribute the information to proxies.

 

And, even if the proxy can dist= ribute the information, it does not know which proxies each user is going t= o use. It would have to distribute the information of each user to each pro= xy.

 

The idea is that the proxy that= the user uses will have the token, and that proxy will then send the token= to the push server and ask it to wake up the user associated with the toke= n.

 

>All this information can be= sent from SIP UA to the Push Server AFAICS.

 

I don’t know how much add= itional information you can send to the Push Servers. And, if you start sen= ding AoRs etc you may end up with privacy issues. The idea is that the push= server doesn’t have any SIP user information – it only knows to which device a token-id belongs.

 

The suggested solution is very = simple – the user simply provides the token in the REGISTER request, = and the proxy will store it. That should work for all push servers.

 

Regards,

 

Christer

 

 

From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
Sent: Monday, September 25, 2017 8:36 AM
To: Asveren, Tolga <tasv= eren@sonusnet.com>; sipcore@ietf.org
Subject: Re: SIP PUSH

 

Hi,

 

>What = is the advantage of this strategy v.s. Push Server communicating directly w= ith the SIP Proxy/Registrar etc… through a non-SIP, e.g. REST API bas= ed, interface?

 

The Push Server DOES communicate with the SIP Proxy/Registrar using= a non-SIP interface. Those interfaces are provided by Apple (or whoever pr= ovides the push server), and we don’t suggest to change those.

 

When the SIP UA registers itself with the Push Server, it receives = a unique token. The SIP UA needs to inform the proxy about that token (and,= inform the proxy that it is an Apple token), so that the proxy can provide it to the Push Server when the incom= ing call comes. 

 

SO, what we need is a way for the SIP UA to provide the token to th= e proxy.

 

Regards,

 

Christer

 

 

From:<= /span> sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: Monday, September 25, 2017 7:44 AM
To: sipcore@ietf.org
Subject: [sipcore] SIP PUSH

 

Hi,

 =

There is a problem with iOS SIP/VoIP applications (I understand the= same is coming to Android too): the application need to be “woken up= ” using the Apple Push Mechanism, in order to e.g., be able to accept incoming INVITE requests. In earlier iOS versions = an incoming request could wake up the application.

 =

A solution has been discussed, where a SIP proxy (or some other net= work entity) informs the Apple Push Server when an incoming call  for = Alice is coming, the Apple Push Server wakes up Alice's UA VoIP application, which is then able to receive the INVITE r= equest.=

 =

In order to do this, the UA needs to provide some information (e.g.= , which push server is used, the Alice’s VoIP application specific pu= sh identifier etc) to the SIP network during registration.=

 =

There is a real need for a solution in the market, and I know that = people are looking at a number of different proprietary solutions – w= hich can cause a real mess in the long run. Therefor I think it would be VERY important to produce a standardised way = of doing this.=

 =

There IS a draft on this:

 =

 =

The draft uses URI parameters. We think that media feature tags sho= uld be used instead. Also, we think at least one additional parameter is ne= eded. But, in general we think the draft provides a good solution.

 =

I haven’t managed to contact the draft author, as my e-mails = are rejected. But, if he is reading this, or if someone else is able to con= tact him, I’d like to get in contact with him :)

 =

Regards,

 =

Christer

 =

--_000_7594FB04B1934943A5C02806D1A2204B562F6AE1ESESSMB109erics_-- From nobody Mon Sep 25 09:21:02 2017 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 75BC61344BC for ; Mon, 25 Sep 2017 09:21:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.721 X-Spam-Level: X-Spam-Status: No, score=-3.721 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, RCVD_IN_SORBS_SPAM=0.5, 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 ATkMAqyjxGKz for ; Mon, 25 Sep 2017 09:20:56 -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 D7AA0132025 for ; Mon, 25 Sep 2017 09:20:55 -0700 (PDT) X-AuditID: c1b4fb2d-a4dff700000019be-8e-59c92ce3ff6b Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id D9.75.06590.3EC29C95; Mon, 25 Sep 2017 18:20:51 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.6]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0352.000; Mon, 25 Sep 2017 18:20:51 +0200 From: Christer Holmberg To: Justin Hornosty CC: "sipcore@ietf.org" Thread-Topic: [sipcore] SIP PUSH Thread-Index: AQHTNfOMhpjgVdXGfkOKwB3589Ama6LFjSAAgAA6O2A= Date: Mon, 25 Sep 2017 16:20:50 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B562F6B3C@ESESSMB109.ericsson.se> References: <87lgl2bzs1.fsf@toki.strangled.net> In-Reply-To: <87lgl2bzs1.fsf@toki.strangled.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyM2J7lO5jnZORBmuv6FisvbmX1eLrj01s DkweP5/fZ/JYsuQnUwBTFJdNSmpOZllqkb5dAlfGoUmnmAvecFXcOfiCqYHxBFcXIyeHhICJ xILz0xlBbCGBI4wSTVv4IOxFjBIz/oZ2MXJwsAlYSHT/0wYJiwioS/R/fs8CYjMLaEo82rmX CcQWFpCX2LjuGCtEjYLEss55bBC2lcSvNX+YQWwWAVWJvu9zwep5BXwllqw8A7U2UaL//VFm kFWcAgYSrbPsQMKMAmIS30+tYYJYJS5x68l8JoiLBSSW7DnPDGGLSrx8/I8VwlaSWHt4OwvI GJDT1u/Sh2hVlJjS/ZAdYqugxMmZT1gmMIrOQjJ1FkLHLCQds5B0LGBkWcUoWpxaXJybbmSs l1qUmVxcnJ+nl5dasokRGB0Ht/zW3cG4+rXjIUYBDkYlHl5fhZORQqyJZcWVuYcYJTiYlUR4 v6gChXhTEiurUovy44tKc1KLDzFKc7AoifM67LsQISSQnliSmp2aWpBaBJNl4uCUamDUPXuy 40zY51v+xV+EC1ex31tapTiLf1r9pZjoggTXA1LmEvWKv+t+dZ69v44p49+L7x1LrGd0P7Lu 2yiY9nl7tMjiyKadOZtcm/+m13/RZlkv+u4Q17MUTeaoOImp1y9UBcy4JptlwPxlZt5rNsc9 Gdwvugy211T23vv+vKj/eKdRRW1X9w8lluKMREMt5qLiRABE4nUrigIAAA== Archived-At: Subject: Re: [sipcore] SIP PUSH X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 16:21:00 -0000 SGksDQoNCj4+IFRoZXJlIGlzIGEgcHJvYmxlbSB3aXRoIGlPUyBTSVAvVm9JUCBhcHBsaWNhdGlv bnMgKEkgdW5kZXJzdGFuZCB0aGUgc2FtZSBpcyBjb21pbmcgdG8gQW5kcm9pZCB0b28pOiB0aGUg YXBwbGljYXRpb24gbmVlZCB0byBiZSDigJx3b2tlbiB1cOKAnSB1c2luZyANCj4+IHRoZSBBcHBs ZSBQdXNoIE1lY2hhbmlzbSwgaW4gb3JkZXIgdG8gZS5nLiwgYmUgYWJsZSB0byBhY2NlcHQgaW5j b21pbmcgSU5WSVRFIHJlcXVlc3RzLiBJbiBlYXJsaWVyIGlPUyB2ZXJzaW9ucyBhbiBpbmNvbWlu ZyByZXF1ZXN0IGNvdWxkIHdha2UgdXAgdGhlIGFwcGxpY2F0aW9uLg0KPg0KPiBXaGF0IGlzIHRo ZSBzaXR1YXRpb24gd2l0aCBBbmRyb2lkPyANCg0KSSBkb24ndCBrbm93IC0gSSdkIGhhdmUgdG8g bG9vayB0aGF0IHVwLiBDdXJyZW50bHkgdGhlIHByb2JsZW0gaW4gdGhlIGZpZWxkIHNlZW1zIHRv IGJlIG1vc3RseSB3aXRoIGlPUy4NCg0KPiBJcyB0aGUgcmF0aW9uYWwgdGhhdCBBbmRyb2lkIGFu ZCBpT1Mgd2FudCB0byBzdG9wIGFwcCBkZXZlbG9wZXJzIGZyb20gd3JpdGluZyBwb29yIGtlZXAg YWxpdmUgLyBiYWNrZ3JvdW5kIHNlcnZpY2VzDQo+IGZvciB0aGUgdmFyaW91cyBtZXNzYWdpbmcg YXBwcyAodGhhdCBoYXZlIHRoZSB0ZW5kZW5jeSB0byBlYXQgYmF0dGVyeSBsaWZlIGFuZCBiYW5k d2lkdGgpIG9yIGFtIEkgbWlzc2luZyBzb21ldGhpbmc/DQoNCkkgd2lsbCBsZWF2ZSBzcGVjdWxh dGlvbnMgdG8gb3RoZXJzIChhbmQsIGlmIHlvdSBnb29nbGUgdGhlIGRpc2N1c3Npb24gZm9ydW1z LCB0aGVyZSBhcmUgbWFueSBwZW9wbGUgd2hvIGFyZSB1cHNldCBieSB0aGlzKSwgYnV0IHRoZSBv ZmZpY2lhbCByZWFzb24gY2FuIGJlIHJlYWQgaGVyZToNCg0KaHR0cHM6Ly9kZXZlbG9wZXIuYXBw bGUuY29tL2xpYnJhcnkvY29udGVudC9xYS9xYTE5MzgvX2luZGV4Lmh0bWwjLy9hcHBsZV9yZWYv ZG9jL3VpZC9EVFM0MDAxNzU2NA0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0K From nobody Mon Sep 25 09:54:30 2017 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 713A31344CA for ; Mon, 25 Sep 2017 09:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-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 GBaWW2Q_4KIX for ; Mon, 25 Sep 2017 09:54:25 -0700 (PDT) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) (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 D732D1344B4 for ; Mon, 25 Sep 2017 09:54:25 -0700 (PDT) Received: by mail-pf0-x233.google.com with SMTP id l188so4083726pfc.6 for ; Mon, 25 Sep 2017 09:54:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=W5+czYLVR4qqsiYZyeSsZYrywrDny1XmZVoR9AjMENo=; b=QY7zq+9zuFvdB7fV+urzbiUpOSbmXv96wMChqIg5Ws/zBsCRLo/ZB7TtfAh1NpHbFu HEY7B+0HRduxYSkpAYhoKrf/RGlwPTzM3vPWcR4vHQqZcRDVPymmpSPsA4k7InUkKmLk maRCCqLiyajkzk1V/vBplKFgjQgNqb3UTDGecjz1zDF5wePaVABXN+GVOpHREmfXXNWw WvKgPGfHmgILVWlaAfkaj/DnEX8WU4oxvMdn1BMG4gQzmR9MQg8GUAfyCEQkQag8+xv6 B93fpbwhTtMwlk/G/YTdrD6+4bpAoK929uLRhynRPgBvGG+XhEHsQj3g6kxkF59cyJmZ H8IA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=W5+czYLVR4qqsiYZyeSsZYrywrDny1XmZVoR9AjMENo=; b=FenoIE2WBjfcFv0nJmFGLThdmYNN9yVyVrzV13t6ENWoKS4y778sJSpo8MLnSKi1Xv 9gUOIzaWj4esWW/vRgQZe+T/qKX1nR7Q54YGoMUqpYFrqJHce82BcJXiiodMQ8WR+eYT rA9h5ELJi9P4vPMs566t2FzpIkjKuhStUnUAa3LDpjaIr/caj3Q0hihxtfCA6eBUyatR VFu/uVuyQ41QvX8QH7DxsLoD9I9ovI2SgNNaw3FMyZbHWupHQMFgazuLVHgU7hWhZw2e YGL2/JzQNLqh65Uhf6Jbz6POvTE4VgBYoBeUAG4RrQRxe5RX1uvtUEs96BFxqzNSktH9 zggg== X-Gm-Message-State: AHPjjUiyXmHHy1DLjCnyMprEUueGH36/wtMx5u1k6C88/dA1zJsxeRa4 h6RYx1e7q+A/oKfnO5xhCr2iWzmh X-Received: by 10.98.214.23 with SMTP id r23mr8208665pfg.195.1506358465233; Mon, 25 Sep 2017 09:54:25 -0700 (PDT) Received: from mail-pg0-f50.google.com (mail-pg0-f50.google.com. [74.125.83.50]) by smtp.gmail.com with ESMTPSA id r3sm10614766pgf.48.2017.09.25.09.54.24 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Sep 2017 09:54:24 -0700 (PDT) Received: by mail-pg0-f50.google.com with SMTP id b11so4293352pgn.12 for ; Mon, 25 Sep 2017 09:54:24 -0700 (PDT) X-Google-Smtp-Source: AOwi7QBKJJVRUIK4Ow97gVx/lrhgMHZ+qFFFg6NWtO216UwqoRlP4YcQLTL2BvNzRf2pch65yJ//P+b7uaIPiRzdT4I= X-Received: by 10.159.195.67 with SMTP id z3mr5734615pln.9.1506358464080; Mon, 25 Sep 2017 09:54:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.189.2 with HTTP; Mon, 25 Sep 2017 09:54:23 -0700 (PDT) In-Reply-To: <87lgl2bzs1.fsf@toki.strangled.net> References: <87lgl2bzs1.fsf@toki.strangled.net> From: Roman Shpount Date: Mon, 25 Sep 2017 12:54:23 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Justin Hornosty Cc: Christer Holmberg , "sipcore@ietf.org" Content-Type: multipart/alternative; boundary="f403043c2a2027f197055a066980" Archived-At: Subject: Re: [sipcore] SIP PUSH X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 16:54:27 -0000 --f403043c2a2027f197055a066980 Content-Type: text/plain; charset="UTF-8" On Mon, Sep 25, 2017 at 10:47 AM, Justin Hornosty wrote: > What is the situation with Android? Is the rational that Android and iOS > want to stop app developers from writing poor keep alive / background > services for the various messaging apps (that have the tendency to eat > battery life and bandwidth) or am I missing something? > > Android is more flexible, but recommended solution is https://firebase.google.com/products/cloud-messaging/ The main justification is extending battery life by reducing the number of applications running in the background. My question regarding this draft, would be, why would you write a SIP softphone for mobile operating system? You would generally be much better of writing a solution around a proprietary protocol such as Google Firebase or Apple Push. If you look at popular messaging applications (Whatsup, Slack, Facetime, etc), none of them used SIP and built something proprietary. Regards, _____________ Roman Shpount --f403043c2a2027f197055a066980 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Sep 25, 2017 at 10:47 AM, Justin Hornosty &l= t;justin@credil.org<= /a>> wrote:
What is the situation with Android? = Is the rational that Android and iOS
want to stop app developers from writing poor keep alive / background
services for the various messaging apps (that have the tendency to eat
battery life and bandwidth) or am I missing something?


=

The main justification is extending battery life by red= ucing the number of applications running in the background.

<= /div>
My question regarding this draft, would be, why would you write a= SIP softphone for mobile operating system? You would generally be much bet= ter of writing a solution around a proprietary protocol such as Google Fire= base or Apple Push. If you look at popular messaging applications (Whatsup,= Slack, Facetime, etc), none of them used SIP and built something proprieta= ry.

Regards,
_____________
Roman Shpount

--f403043c2a2027f197055a066980-- From nobody Mon Sep 25 10:01:44 2017 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 661BF1344E6 for ; Mon, 25 Sep 2017 10:01:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 LFOc57ckF4ce for ; Mon, 25 Sep 2017 10:01:42 -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 48240133065 for ; Mon, 25 Sep 2017 10:01:42 -0700 (PDT) Received: from Svantevit.roach.at (cpe-70-122-154-80.tx.res.rr.com [70.122.154.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v8PH1cQY006990 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 25 Sep 2017 12:01:39 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-154-80.tx.res.rr.com [70.122.154.80] claimed to be Svantevit.roach.at To: Roman Shpount , Justin Hornosty Cc: "sipcore@ietf.org" References: <87lgl2bzs1.fsf@toki.strangled.net> From: Adam Roach Message-ID: <6e28a4a9-21da-0671-0e0a-7af4537567dd@nostrum.com> Date: Mon, 25 Sep 2017 12:01:38 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [sipcore] SIP PUSH X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 17:01:43 -0000 On 9/25/17 11:54 AM, Roman Shpount wrote: > My question regarding this draft, would be, why would you write a SIP > softphone for mobile operating system? You would generally be much > better of writing a solution around a proprietary protocol such as > Google Firebase or Apple Push. If you look at popular messaging > applications (Whatsup, Slack, Facetime, etc), none of them used SIP > and built something proprietary. Because some people still want to do things in a way that interoperates among various implementations rather than locking the ecosystem up into a series of mutually non-interoperatble, privately-controlled, vertically-integrated applications. I mean, this is kind of the reason the IETF exists. /a From nobody Mon Sep 25 10:05:19 2017 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 7AAEE132949 for ; Mon, 25 Sep 2017 10:05:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.721 X-Spam-Level: X-Spam-Status: No, score=-3.721 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, RCVD_IN_SORBS_SPAM=0.5, 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 p5KfOxAwLs4H for ; Mon, 25 Sep 2017 10:05:13 -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 BBA34134503 for ; Mon, 25 Sep 2017 10:05:09 -0700 (PDT) X-AuditID: c1b4fb2d-a4dff700000019be-3d-59c93743abe7 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id B4.2C.06590.34739C95; Mon, 25 Sep 2017 19:05:08 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.6]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0352.000; Mon, 25 Sep 2017 19:05:07 +0200 From: Christer Holmberg To: Roman Shpount , Justin Hornosty CC: "sipcore@ietf.org" Thread-Topic: [sipcore] SIP PUSH Thread-Index: AQHTNfOMhpjgVdXGfkOKwB3589Ama6LFjSAAgAAjUoCAACMVMA== Date: Mon, 25 Sep 2017 17:05:07 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B562F6F4A@ESESSMB109.ericsson.se> References: <87lgl2bzs1.fsf@toki.strangled.net> 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpikeLIzCtJLcpLzFFi42KZGbE9StfF/GSkwetGdou1N/eyWsy4MJXZ 4uuPTWwOzB4/n99n8liy5CeTx60pBQHMUVw2Kak5mWWpRfp2CVwZk/7OYCpYwFtx59FqlgbG LzxdjJwcEgImEr2zP7J0MXJxCAkcYZS4ceoclLOIUeJm216mLkYODjYBC4nuf9ogDSICXhIf d89kArGZBTQlHu3cC2YLC8hLbFx3jBWiRkFiWec8NpBWEQEniQO3K0DCLAKqEmt+fwUr4RXw lfh3dDXUqhWMEuf2XmcEqecUCJQ41R0OUsMoICbx/dQaqFXiEreezGeCuFlAYsme88wQtqjE y8f/WCFsJYnGJU9YQcaAnLZ+lz5Eq6LElO6H7BBrBSVOznzCMoFRdBaSqbMQOmYh6ZiFpGMB I8sqRtHi1OLi3HQjY73Uoszk4uL8PL281JJNjMCYObjlt+4OxtWvHQ8xCnAwKvHw+iqcjBRi TSwrrsw9xCjBwawkwvtFFSjEm5JYWZValB9fVJqTWnyIUZqDRUmc12HfhQghgfTEktTs1NSC 1CKYLBMHp1QD45xj7vOnqP5tsdBeVSjZ/V/ycvy9+yu+MX2YtYqTZd/pcweWiLx/0RuzznXV 7Kt13buaQw2UncKeuB453GqVqhC18UB26qq/hxZ9FVI+9dek+MfWqSHLH932zNmzzFwvQHiG aIv+s59f4n4rL9T6wSViM2v9looeqYNb57LfPdTtqp9ccPJn3WclluKMREMt5qLiRADbMKT8 lQIAAA== Archived-At: Subject: Re: [sipcore] SIP PUSH X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 17:05:17 -0000 SGksDQoNCj4+IFdoYXQgaXMgdGhlIHNpdHVhdGlvbiB3aXRoIEFuZHJvaWQ/IElzIHRoZSByYXRp b25hbCB0aGF0IEFuZHJvaWQgYW5kIGlPUw0KPj4gd2FudCB0byBzdG9wIGFwcCBkZXZlbG9wZXJz IGZyb20gd3JpdGluZyBwb29yIGtlZXAgYWxpdmUgLyBiYWNrZ3JvdW5kDQo+PiBzZXJ2aWNlcyBm b3IgdGhlIHZhcmlvdXMgbWVzc2FnaW5nIGFwcHMgKHRoYXQgaGF2ZSB0aGUgdGVuZGVuY3kgdG8g ZWF0DQo+PiBiYXR0ZXJ5IGxpZmUgYW5kIGJhbmR3aWR0aCkgb3IgYW0gSSBtaXNzaW5nIHNvbWV0 aGluZz8NCj4NCj4gQW5kcm9pZCBpcyBtb3JlIGZsZXhpYmxlLCBidXQgcmVjb21tZW5kZWQgc29s dXRpb24gaXPCoGh0dHBzOi8vZmlyZWJhc2UuZ29vZ2xlLmNvbS9wcm9kdWN0cy9jbG91ZC1tZXNz YWdpbmcvDQo+DQo+IFRoZSBtYWluIGp1c3RpZmljYXRpb24gaXMgZXh0ZW5kaW5nIGJhdHRlcnkg bGlmZSBieSByZWR1Y2luZyB0aGUgbnVtYmVyIG9mIGFwcGxpY2F0aW9ucyBydW5uaW5nIGluIHRo ZSBiYWNrZ3JvdW5kLg0KPg0KPiBNeSBxdWVzdGlvbiByZWdhcmRpbmcgdGhpcyBkcmFmdCwgd291 bGQgYmUsIHdoeSB3b3VsZCB5b3Ugd3JpdGUgYSBTSVAgc29mdHBob25lIGZvciBtb2JpbGUgb3Bl cmF0aW5nIHN5c3RlbT8gWW91IA0KPiB3b3VsZCBnZW5lcmFsbHkgYmUgbXVjaCBiZXR0ZXIgb2Yg d3JpdGluZyBhIHNvbHV0aW9uIGFyb3VuZCBhIHByb3ByaWV0YXJ5IHByb3RvY29sIHN1Y2ggYXMg R29vZ2xlIEZpcmViYXNlIG9yIEFwcGxlIFB1c2guIA0KPiBJZiB5b3UgbG9vayBhdCBwb3B1bGFy IG1lc3NhZ2luZyBhcHBsaWNhdGlvbnMgKFdoYXRzdXAsIFNsYWNrLCBGYWNldGltZSwgZXRjKSwg bm9uZSBvZiB0aGVtIHVzZWQgU0lQIGFuZCBidWlsdCBzb21ldGhpbmcgDQo+IHByb3ByaWV0YXJ5 Lg0KDQpXaGF0IG1hdHRlcnMgaXMgdGhhdCB0aGVyZSBhcmUgU0lQLWJhc2VkIGFwcGxpY2F0aW9u cyBvdXQgdGhlcmUsIGFuZCBpZiB0aGVyZSBpcyBhIHByb2JsZW0gdG8gYmUgZml4ZWQgSSB0aGlu ayBpdCB3b3VsZCBiZSB2ZXJ5IHdlaXJkIGZvciB1cyB0byAiZml4IGl0IiBieSB0ZWxsaW5nIHBl b3BsZSB0byB1c2Ugc29tZXRoaW5nIGVsc2UgaW5zdGVhZC4uLiBXZSBzaG91bGQgYmUgZ2xhZCB0 aGF0IHBlb3BsZSB3YW50IHRvIHVzZSBTSVAsIGFuZCB0cnkgdG8gaGVscCB3aGVuIHRoZXJlIGlz IGEgcHJvYmxlbS4gDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg== From nobody Mon Sep 25 10:22:42 2017 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 206F213453A for ; Mon, 25 Sep 2017 10:22:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-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 kYjLlgHCBwdu for ; Mon, 25 Sep 2017 10:22:40 -0700 (PDT) Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e:c05::233]) (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 1FAD9134542 for ; Mon, 25 Sep 2017 10:22:11 -0700 (PDT) Received: by mail-pg0-x233.google.com with SMTP id c137so4344297pga.11 for ; Mon, 25 Sep 2017 10:22:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=X26xlcbuVkreak5rd1r3xo+XjlvxlNnH9mSBS8gWhmw=; b=yg6lNPTgqOAyblf8HTiwp1gghM57ZuN4yuToAD+CbyTBL9I/t2vB/sKsOBNo30MJP+ GvWUjNQu+tZjtda4yX3y2N32iSPeJyA0BW/JL0djkYAtKn9cP1BbWj441nZOc2CbensQ 9P1nY3s+3GQzKkiL1ssHTwjN/bz8o14myulSt7fmiXv1PNeXIeHdth2Eji0e3UzR8s+7 YU9mE+4l0hvbFGWboTfURnZcddSxDM3ojYkQsI0EQ+LPaWfxCLjXKb5bChnKh89NqQRe m2hlhkndGvulJEpjfN90oVh8nvjYA32eG4HCCHgsEN322nAihMrdj3j8jL7HN4Rp+NgQ geLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=X26xlcbuVkreak5rd1r3xo+XjlvxlNnH9mSBS8gWhmw=; b=IVOAdf4hmrH4Q1LEtCSyVDViU6lq2/eplX+TNc9DkXm1FZ6O/49vaAIVrQ3xkTLjkD 5ARR4N4fCbyZxZO7Yq13tlgORMCtkvWAUAmR6mMSorSEY5ZgQQRv8D+ylXSlFLZZObVa zov2xWJBzXuV0a2l7xWfgaEU3omuIZWHowur9VxWku+8uehUSP88sbgu8i2Kl2NWKG4E WaedVPJW04ixUbdUbSggHaCQhuvMrXyhV4PKbsn+L/fekRueDTxrHIhqJ2QZtskIUfjO Wi3QmQQMa0YqqSDGlWdo7M4OxWH1yzo5mNIfiC3hu4nmGwUKv63Jxk9mEP3iVvjt2sjW NjbA== X-Gm-Message-State: AHPjjUhkw70b1MgFsyNR1AZC/kCp5114pHpthH4Z5rHMME68BwNKLnqe P7AzfLmFxlTd5oo1vfyuYVD69nXa X-Received: by 10.159.208.5 with SMTP id a5mr1215434plp.436.1506360130489; Mon, 25 Sep 2017 10:22:10 -0700 (PDT) Received: from mail-pf0-f174.google.com (mail-pf0-f174.google.com. [209.85.192.174]) by smtp.gmail.com with ESMTPSA id b79sm12962184pfd.37.2017.09.25.10.22.09 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Sep 2017 10:22:09 -0700 (PDT) Received: by mail-pf0-f174.google.com with SMTP id p87so4119484pfj.9 for ; Mon, 25 Sep 2017 10:22:09 -0700 (PDT) X-Google-Smtp-Source: AOwi7QAKZYgnK3DP4bp5LKpo+r5wiywYc2BVVbsmvt4LvFWTj0OowBfu816Xxy+7UAr92+fNEfJG7X4kAb1/WcaNSQU= X-Received: by 10.98.166.10 with SMTP id t10mr8270694pfe.181.1506360129495; Mon, 25 Sep 2017 10:22:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.189.2 with HTTP; Mon, 25 Sep 2017 10:22:08 -0700 (PDT) In-Reply-To: <6e28a4a9-21da-0671-0e0a-7af4537567dd@nostrum.com> References: <87lgl2bzs1.fsf@toki.strangled.net> <6e28a4a9-21da-0671-0e0a-7af4537567dd@nostrum.com> From: Roman Shpount Date: Mon, 25 Sep 2017 13:22:08 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Adam Roach Cc: Justin Hornosty , "sipcore@ietf.org" Content-Type: multipart/alternative; boundary="001a11404c066c2d46055a06cc94" Archived-At: Subject: Re: [sipcore] SIP PUSH X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 17:22:41 -0000 --001a11404c066c2d46055a06cc94 Content-Type: text/plain; charset="UTF-8" On Mon, Sep 25, 2017 at 1:01 PM, Adam Roach wrote: > On 9/25/17 11:54 AM, Roman Shpount wrote: > >> My question regarding this draft, would be, why would you write a SIP >> softphone for mobile operating system? You would generally be much better >> of writing a solution around a proprietary protocol such as Google Firebase >> or Apple Push. If you look at popular messaging applications (Whatsup, >> Slack, Facetime, etc), none of them used SIP and built something >> proprietary. >> > > > Because some people still want to do things in a way that interoperates > among various implementations rather than locking the ecosystem up into a > series of mutually non-interoperatble, privately-controlled, > vertically-integrated applications. > > I mean, this is kind of the reason the IETF exists. The reason I am asking is two fold: 1. We are trying to build a signaling solution which is intended to work with proprietary push solutions which show no intent of becoming standardized. Whatever is designed, the client will continue to be proprietary unless standard PUSH protocol is designed and used. 2. There are serious scalability issues with current secure SIP implementations, which require client to maintain a persistent TLS connection to two independent proxies and send keep-alive messages on both connections. There was quite a bit of discussion of these issues but no interest to develop a solution. I have built several solutions which integrated SIP soft client with Apple Push and Android Firebase notifications. I would not build one now and use WebRTC client with proprietary signaling to the web application server instead. I would only use SIP for service interconnect with other providers or other back-end system components. Regards, _____________ Roman Shpount --001a11404c066c2d46055a06cc94 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Sep 25, 2017 at 1:01 PM, Adam Roach <adam@nostrum.com><= /span> wrote:
On 9/25/17 11:54 AM= , Roman Shpount wrote:
My question regarding this draft, would be, why would you write a SIP softp= hone for mobile operating system? You would generally be much better of wri= ting a solution around a proprietary protocol such as Google Firebase or Ap= ple Push. If you look at popular messaging applications (Whatsup, Slack, Fa= cetime, etc), none of them used SIP and built something proprietary.


 Because some people still want to do things in a way that interoperates amo= ng various implementations rather than locking the ecosystem up into a seri= es of mutually non-interoperatble, privately-controlled, vertically-integra= ted applications.

I mean, this is kind of the reason the IETF exists.

The reason I am asking is two fold:

1. We= are trying to build a signaling solution which is intended to work with pr= oprietary push solutions which show no intent of becoming standardized. Wha= tever is designed, the client will continue to be=C2=A0proprietary unless s= tandard PUSH protocol is designed and used.

2. The= re are serious scalability=C2=A0issues with current secure SIP implementati= ons, which require client to maintain a persistent TLS connection to two in= dependent proxies and send keep-alive messages on both connections. There w= as quite a bit of discussion of these issues but no interest to develop a s= olution.=C2=A0

I have built several solutions whic= h integrated SIP soft client with Apple Push and Android Firebase notificat= ions. I would not build one now and use WebRTC client with proprietary sign= aling to the web application server instead. I would only use SIP for servi= ce interconnect with other providers or other back-end system components.

Regards,
_= ____________
Roman Shpount
=C2=A0
--001a11404c066c2d46055a06cc94-- From nobody Mon Sep 25 11:07:51 2017 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 81161134526 for ; Mon, 25 Sep 2017 11:07:49 -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 xTmqXPWzAcWD for ; Mon, 25 Sep 2017 11:07:47 -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 E442A134533 for ; Mon, 25 Sep 2017 11:07:46 -0700 (PDT) X-AuditID: c1b4fb25-d31059c000005333-e2-59c945f0c090 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id A5.42.21299.0F549C95; Mon, 25 Sep 2017 20:07:45 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.6]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0352.000; Mon, 25 Sep 2017 20:07:43 +0200 From: Christer Holmberg To: Roman Shpount , Adam Roach CC: "sipcore@ietf.org" , Justin Hornosty Thread-Topic: [sipcore] SIP PUSH Thread-Index: AQHTNfOMhpjgVdXGfkOKwB3589Ama6LFjSAAgAAjUoCAAAIGAIAABboAgAAttIA= Date: Mon, 25 Sep 2017 18:07:42 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B562F70C7@ESESSMB109.ericsson.se> References: <87lgl2bzs1.fsf@toki.strangled.net> <6e28a4a9-21da-0671-0e0a-7af4537567dd@nostrum.com> 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphkeLIzCtJLcpLzFFi42KZGbHdVfej68lIg76pTBZ7/i5it1h7cy+r xYwLU5ktvv7YxObA4vHz+X0mjyVLfjJ5zNr5hMXj1pSCAJYoLpuU1JzMstQifbsEroxL/z6w FvxiqTh27z57A+MLli5GTg4JAROJs7NuMoHYQgJHGCWWfVDvYuQCshcxSuxtvM/YxcjBwSZg IdH9TxukRkTARWLx8k9gvcwCfhLL+3pYQWxhAXmJjeuOsULUKEgs65zHBtIqAlTT0q4FEmYR UJWYfu8eO4jNK+ArcezZPRaIVUuYJK5NbmMESXAKBEq0HZ4EZjMKiEl8P7WGCWKXuMStJ/OZ IG4WkFiy5zwzhC0q8fLxP1YIW0micckTVpC9zAKaEut36UO0KkpM6X4ItVdQ4uTMJywTGEVn IZk6C6FjFpKOWUg6FjCyrGIULU4tTspNNzLWSy3KTC4uzs/Ty0st2cQIjKODW36r7mC8/Mbx EKMAB6MSDy+n9clIIdbEsuLK3EOMEhzMSiK8lS5AId6UxMqq1KL8+KLSnNTiQ4zSHCxK4ryO +y5ECAmkJ5akZqemFqQWwWSZODilGhgLt3tYmbVb2DRMak6Kvs/+iaNocvSiTxNPbmyYyiPM /HPz7JcfTXQ/pnDy8j1exxznyffyocSKnfv9v1ZH8acUWgaePP5RO+Xb/Qiv+nklai7GW6at TJUXtfj77FH9We6IN645D4x3ft70RfTDnP1RK9JcOism+n1jETpzM+xh6F/LY/FTFzAosRRn JBpqMRcVJwIAK0WzYZ8CAAA= Archived-At: Subject: Re: [sipcore] SIP PUSH X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 18:07:49 -0000 SGksDQoNCuKApg0KDQo+IEkgaGF2ZSBidWlsdCBzZXZlcmFsIHNvbHV0aW9ucyB3aGljaCBpbnRl Z3JhdGVkIFNJUCBzb2Z0IGNsaWVudCB3aXRoIEFwcGxlIFB1c2ggYW5kIEFuZHJvaWQgRmlyZWJh c2Ugbm90aWZpY2F0aW9ucy4gDQo+IEkgd291bGQgbm90IGJ1aWxkIG9uZSBub3cgYW5kIHVzZSBX ZWJSVEMgY2xpZW50IHdpdGggcHJvcHJpZXRhcnkgc2lnbmFsaW5nIHRvIHRoZSB3ZWIgYXBwbGlj YXRpb24gc2VydmVyIGluc3RlYWQuIA0KPiBJIHdvdWxkIG9ubHkgdXNlIFNJUCBmb3Igc2Vydmlj ZSBpbnRlcmNvbm5lY3Qgd2l0aCBvdGhlciBwcm92aWRlcnMgb3Igb3RoZXIgYmFjay1lbmQgc3lz dGVtIGNvbXBvbmVudHMuDQoNCkFuZCB3aGlsZSBvdGhlcnMgbWFrZSBvdGhlciBjaG9pY2VzLCBu b2JvZHkgcHJldmVudHMgeW91IGZyb20gZG9pbmcgdGhhdCA6KQ0KDQpSZWdhcmRzLA0KDQpDaHJp c3Rlcg0K From nobody Mon Sep 25 13:25:48 2017 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 8240B13306A for ; Mon, 25 Sep 2017 13:25:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 CqpszMPNri3q for ; Mon, 25 Sep 2017 13:25:44 -0700 (PDT) Received: from alum-mailsec-scanner-6.mit.edu (alum-mailsec-scanner-6.mit.edu [18.7.68.18]) by ietfa.amsl.com (Postfix) with ESMTP id A350C13219F for ; Mon, 25 Sep 2017 13:25:44 -0700 (PDT) X-AuditID: 12074412-1fdff7000000748d-01-59c966469c2a Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 4C.32.29837.64669C95; Mon, 25 Sep 2017 16:25:42 -0400 (EDT) Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id v8PKPfuX001929 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 25 Sep 2017 16:25:42 -0400 To: sipcore@ietf.org References: From: Paul Kyzivat Message-ID: Date: Mon, 25 Sep 2017 16:25:41 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBIsWRmVeSWpSXmKPExsUixO6iqOuWdjLSYO0XOYuvPzaxOTB6LFny kymAMYrLJiU1J7MstUjfLoEr4/GKgoL1IhW3j/azNzB2CnQxcnJICJhIPDv1l7GLkYtDSGAH k8TbG1OYQRJCAj+YJI6e9wGxhQXkJR7MXMwEYosIiEg8m/6PDaLGWuL2nDksIDabgJbEnEP/ wWxeAXuJ97tPMoLYLAKqEkuXHgKzRQXSJP7tPssIUSMocXLmE6B6Dg5OARuJlp9ga5kFbCXu zN0NZYtL3HoynwnClpdo3jqbeQIj/ywk3bOQtMxC0jILScsCRpZVjHKJOaW5urmJmTnFqcm6 xcmJeXmpRbpmermZJXqpKaWbGCEBKbSDcf1JuUOMAhyMSjy8DUwnI4VYE8uKK3MPMUpyMCmJ 8t5MBArxJeWnVGYkFmfEF5XmpBYfYpTgYFYS4bVOBsrxpiRWVqUW5cOkpDlYlMR5fy5W9xMS SE8sSc1OTS1ILYLJynBwKEnwPkgBahQsSk1PrUjLzClBSDNxcIIM5wEavh+khre4IDG3ODMd In+K0ZKjp+fGHyaOTTfvAskN3x/8YRJiycvPS5US5/0L0iAA0pBRmgc3E5ZgXjGKA70ozOuZ ClTFA0xOcFNfAS1kAlrYO/UEyMKSRISUVAOjeTZf2S7BThGROelJ/3gvn2nStgi3cpqXb6L0 dtWdyzGLpmpvtjU0ebJupdDnHd/Oxp+pO25SUqtdIiddO+2reseld9/N+As3H5pY/3ZOSqY0 84SNiwLPPLnGG3128hcm9hW1JRPi90kl9pWb3i3t/rWcW1Mna8MX9rUXr77MjPt3TDlnhme6 EktxRqKhFnNRcSIAXBpK5wsDAAA= Archived-At: Subject: Re: [sipcore] SIP PUSH X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 20:25:46 -0000 The referenced draft only describes how the sip client communicates the push configuration to its proxy. But what happens after that? Presumably the proxy, when it receives certain incoming requests destined for the UA is expected to use the push configuration to cause the UA to receive a push notification. But how does that interact with processing of the incoming request by the proxy? Must the proxy defer forwarding the request until it gets some indication that the push has been acknowledged? How does that happen, and what is the time budget for it? (You can't buffer the request for very long.) ISTM that some of those mechanics need to be part and parcel of the mechanism. Thanks, Paul On 9/25/17 7:43 AM, Christer Holmberg wrote: > Hi, > > There is a problem with iOS SIP/VoIP applications (I understand the same > is coming to Android too): the application need to be “woken up” using > the Apple Push Mechanism, in order to e.g., be able to accept incoming > INVITE requests. In earlier iOS versions an incoming request could wake > up the application. > > A solution has been discussed, where a SIP proxy (or some other network > entity) informs the Apple Push Server when an incoming call  for Alice > is coming, the Apple Push Server wakes up Alice's UA VoIP application, > which is then able to receive the INVITE request. > > In order to do this, the UA needs to provide some information (e.g., > which push server is used, the Alice’s VoIP application specific push > identifier etc) to the SIP network during registration. > > There is a real need for a solution in the market, and I know that > people are looking at a number of different proprietary solutions – > which can cause a real mess in the long run. Therefor I think it would > be VERY important to produce a standardised way of doing this. > > There IS a draft on this: > > https://tools.ietf.org/html/draft-ivanov-sipcore-pnsip-01 > > The draft uses URI parameters. We think that media feature tags should > be used instead. Also, we think at least one additional parameter is > needed. But, in general we think the draft provides a good solution. > > I haven’t managed to contact the draft author, as my e-mails are > rejected. But, if he is reading this, or if someone else is able to > contact him, I’d like to get in contact with him :) > > Regards, > > Christer > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Mon Sep 25 13:43:51 2017 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 34D9F1345A7 for ; Mon, 25 Sep 2017 13:43:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.721 X-Spam-Level: X-Spam-Status: No, score=-3.721 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, RCVD_IN_SORBS_SPAM=0.5, 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 4trxUCWQJJ-U for ; Mon, 25 Sep 2017 13:43:48 -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 00B22132055 for ; Mon, 25 Sep 2017 13:43:43 -0700 (PDT) X-AuditID: c1b4fb30-cd5ff70000001911-c4-59c96a7ed0b4 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id E8.BB.06417.E7A69C95; Mon, 25 Sep 2017 22:43:42 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.6]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0352.000; Mon, 25 Sep 2017 22:43:41 +0200 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] SIP PUSH Thread-Index: AQHTNfOMhpjgVdXGfkOKwB3589Ama6LF63uAgAAjBTA= Date: Mon, 25 Sep 2017 20:43:41 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B562F7579@ESESSMB109.ericsson.se> References: 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.154] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrALMWRmVeSWpSXmKPExsUyM2K7qG5d1slIg6WbRCxWbDjAavH1xyY2 ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSuj/UA7a8EbyYp3966zNjB+Euli5OSQEDCR 2NvRx9jFyMUhJHCEUeLO5+/MEM4iRollJ++wdzFycLAJWEh0/9MGaRARCJS4umQCM4gtLCAv sXHdMVaIuILEss55bBC2lcS6t//AalgEVCWe7rkHVsMr4CvRfGYNmC0kUCix5PJlsBpOAQeJ SU+nMIHYjAJiEt9PrQGzmQXEJW49mc8EcaiAxJI955khbFGJl4//sULYShKLbn+GqteTuDF1 ChuErS2xbOFrZoi9ghInZz5hmcAoMgvJ2FlIWmYhaZmFpGUBI8sqRtHi1OKk3HQjI73Uoszk 4uL8PL281JJNjMB4OLjlt8EOxpfPHQ8xCnAwKvHwVoSdjBRiTSwrrsw9xCjBwawkwmudDBTi TUmsrEotyo8vKs1JLT7EKM3BoiTO67jvQoSQQHpiSWp2ampBahFMlomDU6qB0ZyfXaA1cv2B q2eOvlqZf/Lzhqfts18uvv0oLI/JZTHfUcnNZZftxTUv/T+QwWAlWZC3NvZ/4ZVKh3cHXPVs 3ZKX/9r/4/x+64A1WsdsOV7JGVyZdsdjl9xTz5V7dTMklz823G574ZxI1uXHBjGleZdcuK10 3D5c+fB05v6VS7e+YN5gfZaPK02JpTgj0VCLuag4EQC91La1gwIAAA== Archived-At: Subject: Re: [sipcore] SIP PUSH X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 20:43:50 -0000 Hi, >The referenced draft only describes how the sip client communicates the pu= sh configuration to its proxy. But what happens after that? Presumably the = proxy, when it >receives certain incoming requests destined for the UA is e= xpected to use the push configuration to cause the UA to receive a push not= ification. But how does that interact >with processing of the incoming requ= est by the proxy? Must the proxy defer forwarding the request until it gets= some indication that the push has been acknowledged? >How does that happen= , and what is the time budget for it?=20 >(You can't buffer the request for very long.) In theory you can buffer it as long as you would allow you to re-transmit t= he request before the transaction is considered failed. But, from what I've heard, the push mechanism is very fast, and my understa= nding is that people would buffer for a very short time - or not buffer at = all. After all, re-transmitting the request before the device can handle it= won't break anything - the package will most likely simply be dropped. It = also depends on which proxy contacts the push server, and how far the proxy= is from the device. Regards, Christer On 9/25/17 7:43 AM, Christer Holmberg wrote: > Hi, >=20 > There is a problem with iOS SIP/VoIP applications (I understand the=20 > same is coming to Android too): the application need to be "woken up"=20 > using the Apple Push Mechanism, in order to e.g., be able to accept=20 > incoming INVITE requests. In earlier iOS versions an incoming request=20 > could wake up the application. >=20 > A solution has been discussed, where a SIP proxy (or some other=20 > network > entity) informs the Apple Push Server when an incoming call =A0for Alice= =20 > is coming, the Apple Push Server wakes up Alice's UA VoIP application,=20 > which is then able to receive the INVITE request. >=20 > In order to do this, the UA needs to provide some information (e.g.,=20 > which push server is used, the Alice's VoIP application specific push=20 > identifier etc) to the SIP network during registration. >=20 > There is a real need for a solution in the market, and I know that=20 > people are looking at a number of different proprietary solutions -=20 > which can cause a real mess in the long run. Therefor I think it would=20 > be VERY important to produce a standardised way of doing this. >=20 > There IS a draft on this: >=20 > https://tools.ietf.org/html/draft-ivanov-sipcore-pnsip-01 >=20 > The draft uses URI parameters. We think that media feature tags should=20 > be used instead. Also, we think at least one additional parameter is=20 > needed. But, in general we think the draft provides a good solution. >=20 > I haven't managed to contact the draft author, as my e-mails are=20 > rejected. But, if he is reading this, or if someone else is able to=20 > contact him, I'd like to get in contact with him :) >=20 > Regards, >=20 > Christer >=20 >=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From nobody Mon Sep 25 14:03:54 2017 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 5EB3F1345A5 for ; Mon, 25 Sep 2017 14:03:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-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 SnaNj9z-IL1L for ; Mon, 25 Sep 2017 14:03:50 -0700 (PDT) Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::231]) (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 D3ECB13457B for ; Mon, 25 Sep 2017 14:03:50 -0700 (PDT) Received: by mail-pf0-x231.google.com with SMTP id n24so4429907pfk.5 for ; Mon, 25 Sep 2017 14:03:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5SJya9S5p7fqokU0u0Xk6Em7QJx/Eg4vQnxfOiWmRMA=; b=DLpRYOEEqaGM8UO2Qnl9ffTJXPiVyGdECjCSg/8f60Ns2jAytEVmeyqv1kVkfrePiq ey3XMEdN39yoEV2rPMTarXvsa6+/TMRFsGhRC4c/XGG4wyr+I1Iw9sUCmBghsKw7JNVU 2a06CrMP34UuLi5FEBe9wlUROwAZLjvclbEWEisq7gZWgKfdPp+upxEhhAdFNTnlH0uS 5VPmJajgbyfkNA39hN6Vz3AmHJcFd5m54pmFOU/eKa1Mq/mZpfH0s7gjF1z0l2iwqT/f a/9m82Gkc1zliYykN79UtSp56mfWRv3+qkO0cmutC/k50cw2xpyMZ8zqK8l9S1rnNt8w 8YaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5SJya9S5p7fqokU0u0Xk6Em7QJx/Eg4vQnxfOiWmRMA=; b=tmziCjdGna9mREBh9adXDgB4maKVatSecScGffpFX+SEUVA5iHqpvvfAsxdS0tSSaP HavK7L+gPWPsxJLqB1CVJ8saf8BvGOlAAnT2ybLHV8qAz72FFO3XUFFr4sgiu8v5uuc+ sqOPTyWTUGBYrXkYvjmNPNaxdR9f/4jqUykVSXrb/tHC2afKjeM1V1/qwubembOxlJIB GPvi74U8saeuVkB0I/qM5xiaVDtHn6/nSiXP+E+9Xn+S65FU9Myq6HTW5vRfekYjg/4i 7alHs7l8mpUqQAU6tHhAGcNB0xC78PY7WQO0NtjduW10KuGg3eq0q1wFesgDPjK7Y+qa JzCA== X-Gm-Message-State: AHPjjUiL6nib8LwHM6LFF132CtKrRUA2fQksZdKKmxuVhezlX3jKQ/MA 6sQgQiTvvXKsMM1Mi3VjVnbOT4Dy X-Received: by 10.84.133.193 with SMTP id f59mr8844392plf.332.1506373430214; Mon, 25 Sep 2017 14:03:50 -0700 (PDT) Received: from mail-pg0-f46.google.com (mail-pg0-f46.google.com. [74.125.83.46]) by smtp.gmail.com with ESMTPSA id p5sm12757584pgc.94.2017.09.25.14.03.49 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Sep 2017 14:03:49 -0700 (PDT) Received: by mail-pg0-f46.google.com with SMTP id u18so4708190pgo.0 for ; Mon, 25 Sep 2017 14:03:49 -0700 (PDT) X-Google-Smtp-Source: AOwi7QCnnMqosgweTLtCWS0b2CKlaS3Hc3qaVwMTVPVZZ6EU3n8QbWy5pPpbcG0XE6MjP4E/m99E6U2REyt0EcD41O0= X-Received: by 10.99.185.93 with SMTP id v29mr9030394pgo.32.1506373429181; Mon, 25 Sep 2017 14:03:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.189.2 with HTTP; Mon, 25 Sep 2017 14:03:48 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B562F7579@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B562F7579@ESESSMB109.ericsson.se> From: Roman Shpount Date: Mon, 25 Sep 2017 17:03:48 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Christer Holmberg Cc: Paul Kyzivat , "sipcore@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c1bac82254013055a09e513" Archived-At: Subject: Re: [sipcore] SIP PUSH X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 21:03:53 -0000 --94eb2c1bac82254013055a09e513 Content-Type: text/plain; charset="UTF-8" On Mon, Sep 25, 2017 at 4:43 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > >The referenced draft only describes how the sip client communicates the > push configuration to its proxy. But what happens after that? Presumably > the proxy, when it >receives certain incoming requests destined for the UA > is expected to use the push configuration to cause the UA to receive a push > notification. But how does that interact >with processing of the incoming > request by the proxy? Must the proxy defer forwarding the request until it > gets some indication that the push has been acknowledged? >How does that > happen, and what is the time budget for it? > >(You can't buffer the request for very long.) > > In theory you can buffer it as long as you would allow you to re-transmit > the request before the transaction is considered failed. > > But, from what I've heard, the push mechanism is very fast, and my > understanding is that people would buffer for a very short time - or not > buffer at all. After all, re-transmitting the request before the device can > handle it won't break anything - the package will most likely simply be > dropped. It also depends on which proxy contacts the push server, and how > far the proxy is from the device. > In the SIP/PUSH based solution that we have built, client registration was done through an HTTPS REST API call, which also performed other functions, such as loaded branding, feature, and account information for the mobile client. Incoming calls were received by B2BUA. B2BUA would periodically send 180 ringing to the origination party to keep the call active. It would also send the PUSH notification to the client with generated unique SIP URL. Client will receive PUSH notification and place a call to the generated unique SIP URL. B2BUA will receive the call (which, by the way was done with only ICE UDP and TCP host candidates to facilitate faster call setup) and bridge media between the two inbound calls. Once the call was established, call might get re-connected. If the call came from PSTN, it will continue with the media bridge. If the call came from another client, B2BUA would issue an offerless re-INVITE to the client, which will cause it to collect complete list of ICE candidates and go through a complete ICE renegotiation between two clients taking B2BUA media bridge out of the call path. During further optimization, SIP was replaced with proprietary call setup protocol, in which offer from B2BUA was sent in the PUSH notification. As you can see, large portions of this flow were proprietary, but I wanted to provide it for your reference. Regards, _____________ Roman Shpount --94eb2c1bac82254013055a09e513 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Sep 25, 2017 at 4:43 PM, Christer Holmberg &= lt;chri= ster.holmberg@ericsson.com> wrote:
>The referenced draft only describes how the sip client c= ommunicates the push configuration to its proxy. But what happens after tha= t? Presumably the proxy, when it >receives certain incoming requests des= tined for the UA is expected to use the push configuration to cause the UA = to receive a push notification. But how does that interact >with process= ing of the incoming request by the proxy? Must the proxy defer forwarding t= he request until it gets some indication that the push has been acknowledge= d? >How does that happen, and what is the time budget for it?
>(You can't buffer the request for very long.)

In theory you can buffer it as long as you would allow you to re-tra= nsmit the request before the transaction is considered failed.

But, from what I've heard, the push mechanism is very fast, and my unde= rstanding is that people would buffer for a very short time - or not buffer= at all. After all, re-transmitting the request before the device can handl= e it won't break anything - the package will most likely simply be drop= ped. It also depends on which proxy contacts the push server, and how far t= he proxy is from the device.

In the SIP= /PUSH based solution that we have built, client registration was done throu= gh an HTTPS REST API call, which also performed other functions, such as lo= aded branding, feature, and account information for the mobile client. Inco= ming calls were received by B2BUA. B2BUA would periodically send 180 ringin= g to the origination party to keep the call active. It would also send the = PUSH notification to the client with generated unique SIP URL. Client will = receive PUSH notification and place a call to the generated unique SIP URL.= B2BUA will receive the call (which, by the way was done with only ICE UDP = and TCP host candidates to facilitate faster call setup) and bridge media b= etween the two inbound calls. Once the call was established, call might get= re-connected. If the call came from PSTN, it will continue with the media = bridge. If the call came from another client, B2BUA would issue an offerles= s re-INVITE to the client, which will cause it to collect complete list of = ICE candidates and go through a complete ICE renegotiation between two clie= nts taking B2BUA media bridge out of the call path. During further optimiza= tion, SIP was replaced with proprietary call setup protocol, in which offer= from B2BUA was sent in the PUSH notification.

As = you can see, large portions of this flow were proprietary, but I wanted to = provide it for your reference.

Regards,
=
_____________
Roman Shpount
=C2=A0
--94eb2c1bac82254013055a09e513-- From nobody Mon Sep 25 19:00:20 2017 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 A7D09133018 for ; Mon, 25 Sep 2017 19:00:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.933 X-Spam-Level: X-Spam-Status: No, score=-1.933 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, URIBL_BLOCKED=0.001] 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 OfiwPe10ePgE for ; Mon, 25 Sep 2017 19:00:18 -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 69D3D120720 for ; Mon, 25 Sep 2017 19:00:17 -0700 (PDT) Received: from resomta-ch2-07v.sys.comcast.net ([69.252.207.103]) by resqmta-ch2-12v.sys.comcast.net with ESMTP id wfA3dB5cC0jePwfAXdmbB3; Tue, 26 Sep 2017 02:00:17 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-07v.sys.comcast.net with SMTP id wfAVdqxQHabRQwfAWd0cF4; Tue, 26 Sep 2017 02:00:16 +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 v8Q20Fim012363; Mon, 25 Sep 2017 22:00:15 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v8Q20EgS012360; Mon, 25 Sep 2017 22:00:14 -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 Cc: sipcore@ietf.org In-Reply-To: Sender: worley@ariadne.com (Dale R. Worley) Date: Mon, 25 Sep 2017 22:00:14 -0400 Message-ID: <87y3p29q35.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfOLmZpxhvOfHa5oPjIhNLIiuOLVmXxgeg1/KNSnMjrony3L6cCinabyjyuci/r2JgnVcmeeyAoAuGcD2+1hqvNigToERjNySz2sevc425cVHUAvdH3r9 9s3bs5aF962BjmuoDlyV02t+u8yeMIvn/Cu5eOjlPfbOnBFCwZb/l7VGBpGVa2CghcWuPFDdHQucA5cGWeO60DosxW1tqw2sutU= Archived-At: Subject: Re: [sipcore] SIP PUSH X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 02:00:19 -0000 Christer Holmberg writes: > There is a real need for a solution in the market, and I know that > people are looking at a number of different proprietary solutions -- > which can cause a real mess in the long run. Therefor I think it would > be VERY important to produce a standardised way of doing this. A fine sentiment, but isn't this *already* a gross, incompatible proprietary situation? The standardized way of "waking up" a SIP user agent is to ... *sent it an INVITE*. If the OS wants to restrict the number of applications that run in the background, it should provide a way for the application to tell it, "Monitor UDP port XXX and if something comes in on it, wake me up." (Actually, that's usually called "a recv() call to the ABI".) Dale From nobody Mon Sep 25 19:23:20 2017 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 D881C134640 for ; Mon, 25 Sep 2017 19:23:14 -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 bkM2dHFeYDfB for ; Mon, 25 Sep 2017 19:23:14 -0700 (PDT) Received: from resqmta-ch2-11v.sys.comcast.net (resqmta-ch2-11v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:43]) (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 003DB133054 for ; Mon, 25 Sep 2017 19:23:13 -0700 (PDT) Received: from resomta-ch2-09v.sys.comcast.net ([69.252.207.105]) by resqmta-ch2-11v.sys.comcast.net with ESMTP id wfVpdhFqYy6hywfWjdY3f3; Tue, 26 Sep 2017 02:23:13 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-09v.sys.comcast.net with SMTP id wfWhd2aP6wtG7wfWhdoo0F; Tue, 26 Sep 2017 02:23:12 +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 v8Q2NAqe013828; Mon, 25 Sep 2017 22:23:10 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v8Q2NAYS013825; Mon, 25 Sep 2017 22:23:10 -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: "Jesske\, Roland" Cc: pkyzivat@alum.mit.edu, sipcore@ietf.org In-Reply-To: (R.Jesske@telekom.de) Sender: worley@ariadne.com (Dale R. Worley) Date: Mon, 25 Sep 2017 22:23:10 -0400 Message-ID: <87mv5i9p0x.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfIX4Zmw+KJRgXeNine5nRcEyUKY0TiyMbKuKqj6gf+Lw6VZRiIfqNTT30b4rzji7TjlYhlpXc5VOsQC4ZK+PPn8z/WTeyS2jSrLRCGptB3ZHdLFlFB9E WEgFy0VbWWeFErthE9rUmjReMygqUr8zZa8W+ZrDspk+GVrTcJdiHCjecf2wEZP+0/prVg7tHqwpvuEDWyXPt0WRxPeiRABcCQW3Ir+uJEj12CDqfA5TL2at Archived-At: Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-reason-q850-loc-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 02:23:15 -0000 I'd favor naming all of the "extra" codes after their bit combinations: 0 0 0 0 user (U) 0 0 0 1 private network serving the local user (LPN) 0 0 1 0 public network serving the local user (LN) 0 0 1 1 transit network (TN) 0 1 0 0 public network serving the remote user (RLN) 0 1 0 1 private network serving the remote user (RPN) 0 1 1 0 LOC-6 0 1 1 1 international network (INTL) 1 0 0 0 LOC-8 1 0 0 1 LOC-9 1 0 1 0 network beyond interworking point (BI) 1 0 1 1 LOC-11 1 1 0 0 LOC-12 1 1 0 1 LOC-13 1 1 1 0 LOC-14 1 1 1 1 LOC-15 That makes the meaning of the extra codes obvious to users who don't regularly use them. (I assume people who understand ISUP will know the codes for U, LPN, etc.) But possibly that isn't compatible with the style by which ITU-T describes these codes. Dale From nobody Mon Sep 25 21:23:04 2017 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 2EDCE13219B for ; Mon, 25 Sep 2017 21:23:02 -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 fr1S2kXxlEHF for ; Mon, 25 Sep 2017 21:23:00 -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 9B3EC13235C for ; Mon, 25 Sep 2017 21:23:00 -0700 (PDT) X-AuditID: c1b4fb3a-617ff700000051a3-21-59c9d622a24f Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id F9.00.20899.226D9C95; Tue, 26 Sep 2017 06:22:58 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.6]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0352.000; Tue, 26 Sep 2017 06:22:08 +0200 From: Christer Holmberg To: "Dale R. Worley" CC: "sipcore@ietf.org" Thread-Topic: [sipcore] SIP PUSH Thread-Index: AQHTNfOMhpjgVdXGfkOKwB3589Ama6LGSPQAgABIhvA= Date: Tue, 26 Sep 2017 04:22:08 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B562F7B24@ESESSMB109.ericsson.se> References: <87y3p29q35.fsf@hobgoblin.ariadne.com> In-Reply-To: <87y3p29q35.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.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUyM2J7oK7StZORBreuW1h8/bGJzeLliTIH Jo/J+78yeyxZ8pMpgCmKyyYlNSezLLVI3y6BK+ProcNsBXfYKhre3GBpYFzC2sXIySEhYCLx aFEjkM3FISRwhFHi2YwLLBDOIkaJi6/mAGU4ONgELCS6/2mDmCICmhIdC3JAepmBzEc79zKB 2MIC8hIb1x0DmykioCCxrHMeG0S5lUT7ghiQMIuAqkTHoSmMIDavgK/EtZu7wWwhgRSJI4fv gpVzChhLvH+eDhJmFBCT+H5qDRPEJnGJW0/mM0FcLCCxZM95ZghbVOLl439QnyhJLLr9Gape R2LB7k9sELa2xLKFr5kh1gpKnJz5hGUCo+gsJGNnIWmZhaRlFpKWBYwsqxhFi1OLi3PTjYz0 Uosyk4uL8/P08lJLNjEC4+Pglt9WOxgPPnc8xCjAwajEw7vq6MlIIdbEsuLK3EOMEhzMSiK8 3ueBQrwpiZVVqUX58UWlOanFhxilOViUxHkd9l2IEBJITyxJzU5NLUgtgskycXBKNTCanLis 7tC3r11fdtHkd66MFqZ2msf9ivhiujWy3yw8HcAkflLiUUr5nV0d2xf8X2gVUixuU8/1id94 pvGpa/mP+jNmy/e5eO+Wv3FL/X1t8kqnY6/+7V0z7c2a3bnF7guT1789OZs3jPflLJOF7/cs 9DpoE57VNH2Nd+a5TRJXF/O1qOW0nNBXYinOSDTUYi4qTgQAxj9xM4sCAAA= Archived-At: Subject: Re: [sipcore] SIP PUSH X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 04:23:02 -0000 Hi, >> There is a real need for a solution in the market, and I know that=20 >> people are looking at a number of different proprietary solutions --=20 >> which can cause a real mess in the long run. Therefor I think it would=20 >> be VERY important to produce a standardised way of doing this. > > A fine sentiment, but isn't this *already* a gross, incompatible propriet= ary situation? The standardized way of "waking up" a=20 > SIP user agent is to ... *sent it an INVITE*. > > If the OS wants to restrict the number of applications that run in the ba= ckground, it should provide a way for the application=20 > to tell it, "Monitor UDP port XXX and if something comes in on it, wake m= e up." (Actually, that's usually called "a recv() call to the ABI".) Unfortunately, there is nothing we can do about that. Regards, Christer From nobody Mon Sep 25 21:54:40 2017 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 1E4621345BA for ; Mon, 25 Sep 2017 21:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 cuPKkY-1-FAD for ; Mon, 25 Sep 2017 21:54:36 -0700 (PDT) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (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 DC5B9126B7E for ; Mon, 25 Sep 2017 21:54:35 -0700 (PDT) Received: by mail-io0-x234.google.com with SMTP id d16so11695690ioj.3 for ; Mon, 25 Sep 2017 21:54:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/RgENsbGM+tdJmBLs2UUXpx76o/mMLlrTQmkRbzNEF4=; b=lzKMAS95XSz0Wj0QPrxDJ2bp5aAYl6+P6k/oriXfzidOQbkrRFMz6mzWsoFGx7pLFV RKZ1ozQmtk1eTFthNmqCvkcD4wMhbEaKBmkQnENyQMDP3Fu5ffe7HVEqe32HZPDuTxzU mLavbLmUBm93vd6YkKXVKvAx8kiQi5lPpidlDfNHdX1nkjcqZZrwxabG+YecwvHWSk9c kH2xdpvh6AOZkDJCkDnAi4bbEtpkOuyZK6QF2S9pq8pw7HpTsOnquQHfplqX8SGkIKWh xTOkRArZ1C4WE2Jfe7VOAPb2yKq//nPTO7iqpfEM8YPuJfQE4Vsq5W2HidEPngu2ZLm7 FV4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/RgENsbGM+tdJmBLs2UUXpx76o/mMLlrTQmkRbzNEF4=; b=eaUKQrd3Z6CAE5GgMj8thhvjuVY5RxrY1kYEt2YXyWv3PAPlp9RyluMwn2Sd5/gYsD wVQgMo3VrJVEdqp205fXmtbK/h9MBzJTJz1qqe0xVIZaS9DfeXx3o7gNih8pK8kzcFa7 xQq6pmcpYhW7iQcwJ2QWh+kz8a+pYv3aYhgqKMXVjEXtL+1lSvAe8HaVhZRmQNNGwId4 tNu9HL2qWhfsfTGfMicuAptyzcjYMIOCUIg/TIDVSajnof4TcTzTRjmfk8dltYSsVnlK FyX5niJ+P9VuIo05S/+ux8uvKSoA1fLx0WdbyGWxgObuEpCzuvEwNlLN9vjeD61w2b+Q 0H1A== X-Gm-Message-State: AHPjjUjSAJ0a6yKYR6ynrpFEAMOVr0Kw63W9IHsI9/xx2VcUAo2bbVPI 5OaVr7RGUl9EX/Y1YriWmTCxdz9GfF0TUc4UsK8= X-Google-Smtp-Source: AOwi7QAZLn26Rh6jn21uqLBm3kzb/x3lDQDQwMCu2uFKPoGT3KvDQv9vY4dVo8BxX9Qzb/Obth7HQl21IZPnjtg+8fg= X-Received: by 10.107.198.195 with SMTP id w186mr12958275iof.60.1506401675192; Mon, 25 Sep 2017 21:54:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.2.86.90 with HTTP; Mon, 25 Sep 2017 21:54:34 -0700 (PDT) In-Reply-To: References: From: Alberto Llamas Date: Tue, 26 Sep 2017 04:54:34 +0000 Message-ID: To: Christer Holmberg Cc: "sipcore@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c11f00ebd2f24055a10787d" Archived-At: Subject: Re: [sipcore] SIP PUSH X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 04:54:38 -0000 --94eb2c11f00ebd2f24055a10787d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I have seen approaches like maintaining a dummy call to the proxy server without having to use all the resources of the mobile client. During this call, a dummy RTP packet is sent as a keep-alive that is previously negotiated with the proxy server. This approach has been implemented under an IMS and Push to Talk service scenario. I think it could be taken as a source of inspiration and achieve standardization of a mechanism 100% SIP that allows us the desired goal. Regards, On Mon, Sep 25, 2017 at 11:43 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > There is a problem with iOS SIP/VoIP applications (I understand the same > is coming to Android too): the application need to be =E2=80=9Cwoken up= =E2=80=9D using the > Apple Push Mechanism, in order to e.g., be able to accept incoming INVITE > requests. In earlier iOS versions an incoming request could wake up the > application. > > A solution has been discussed, where a SIP proxy (or some other network > entity) informs the Apple Push Server when an incoming call for Alice is > coming, the Apple Push Server wakes up Alice's UA VoIP application, which > is then able to receive the INVITE request. > > In order to do this, the UA needs to provide some information (e.g., whic= h > push server is used, the Alice=E2=80=99s VoIP application specific push i= dentifier > etc) to the SIP network during registration. > > There is a real need for a solution in the market, and I know that people > are looking at a number of different proprietary solutions =E2=80=93 whic= h can > cause a real mess in the long run. Therefor I think it would be VERY > important to produce a standardised way of doing this. > > There IS a draft on this: > > https://tools.ietf.org/html/draft-ivanov-sipcore-pnsip-01 > > The draft uses URI parameters. We think that media feature tags should be > used instead. Also, we think at least one additional parameter is needed. > But, in general we think the draft provides a good solution. > > I haven=E2=80=99t managed to contact the draft author, as my e-mails are = rejected. > But, if he is reading this, or if someone else is able to contact him, I= =E2=80=99d > like to get in contact with him :) > > Regards, > > Christer > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > --=20 Alberto Llamas Telecommunications Engineer dCAP | KPAC | SSCA *"Internet is all about share"* --94eb2c11f00ebd2f24055a10787d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I have seen approaches like maintaining a dummy call = to the proxy server without having to use all the resources of the mobile c= lient. During this call, a dummy RTP packet is sent as a keep-alive that is= previously negotiated with the proxy server. This approach has been implem= ented under an IMS and Push to Talk service scenario.

<= div>I think it could be taken as a source of inspiration and achieve standa= rdization of a mechanism 100% SIP that allows us the desired goal.


Regards,

On Mon, Sep 25, 2017 at 11:43 AM, Christ= er Holmberg <christer.holmberg@ericsson.com> wr= ote:
Hi,

There is a problem with iOS SIP/VoIP applications (I understand the sa= me is coming to Android too): the application need to be =E2=80=9Cwoken up= =E2=80=9D using the Apple Push Mechanism, in order to e.g., be able to acce= pt incoming INVITE requests. In earlier iOS versions an incoming request could wake up the application.

A solution has been discussed, where a SIP proxy (or some other networ= k entity) informs the Apple Push Server when an incoming call =C2=A0for Ali= ce is coming, the Apple Push Server wakes up Alice's UA VoIP applicatio= n, which is then able to receive the INVITE request.

In order to do this, the UA needs to provide some information (e.g., w= hich push server is used, the Alice=E2=80=99s VoIP application specific pus= h identifier etc) to the SIP network during registration.

There is a real need for a solution in the market, and I know that peo= ple are looking at a number of different proprietary solutions =E2=80=93 wh= ich can cause a real mess in the long run. Therefor I think it would be VER= Y important to produce a standardised way of doing this.

There IS a draft on this:


The draft uses URI parameters. We think that media feature tags should= be used instead. Also, we think at least one additional parameter is neede= d. But, in general we think the draft provides a good solution.

I haven=E2=80=99t managed to contact the draft author, as my e-mails a= re rejected. But, if he is reading this, or if someone else is able to cont= act him, I=E2=80=99d like to get in contact with him :)

Regards,

Christer


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



--
=
Alberto Llamas
Telecommunications = Engineer
dCAP | KPAC | SSCA

=

"Internet is all about share"
<= /div>
--94eb2c11f00ebd2f24055a10787d-- From nobody Mon Sep 25 23:09:34 2017 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 6697B1321DC for ; Mon, 25 Sep 2017 23:09:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=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 xx67XBJwI7KI for ; Mon, 25 Sep 2017 23:09:30 -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 5787B1321C9 for ; Mon, 25 Sep 2017 23:09:30 -0700 (PDT) X-AuditID: c1b4fb3a-9e1d49c0000051a3-77-59c9ef187dd9 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 55.44.20899.81FE9C95; Tue, 26 Sep 2017 08:09:28 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.6]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0352.000; Tue, 26 Sep 2017 08:09:20 +0200 From: Christer Holmberg To: Alberto Llamas CC: "sipcore@ietf.org" Thread-Topic: [sipcore] SIP PUSH Thread-Index: AQHTNfOMhpjgVdXGfkOKwB3589Ama6LGeakAgABIqgA= Date: Tue, 26 Sep 2017 06:09:20 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_D5EFC98B22752christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDIsWRmVeSWpSXmKPExsUyM2J7iK7E+5ORBr1b5Cxmzj7MYvH1xyY2 ByaPnbPusnssWfKTKYApissmJTUnsyy1SN8ugSuj/0Mfc8Exn4ozv24wNjA+sO9i5OSQEDCR 2HroF3MXIxeHkMARRon268+gnEWMEptmLmXtYuTgYBOwkOj+pw3SICKgK7FpyXdGEJtZQFPi 0c69TCC2sIC8xIOZi5kgahQklnXOY4OwrSQ6ex8xg9gsAqoSL96cYgGxeQWsJfad3sQIsauJ UWLaky52kASnQKDE2ivrwBoYBcQkvp9awwSxTFzi1pP5TBBXC0gs2XOeGcIWlXj5+B8riC0q oCex4cRtdpCbJQQUJZb3y0G0JkicP7YAaq+gxMmZT1gmMIrOQjJ1FpKyWUjKIOIGEu/PzWeG sLUlli18DWXrS2z8cpYRwraWeD7rFyOymgWMHKsYRYtTi4tz042M9FKLMpOLi/Pz9PJSSzYx AuPw4JbfVjsYDz53PMQowMGoxMNbef9kpBBrYllxZe4hRgkOZiUR3uWvgUK8KYmVValF+fFF pTmpxYcYpTlYlMR5HfZdiBASSE8sSc1OTS1ILYLJMnFwSjUwzrpw9czaetU4v82F4s898h+G 5ulM0txRPvl59q21W85cPns3as3MLZdUOF3vVgjOYHW89fvyDP65ocG2mzY9Z7u+Q6rlycfq vt9fzWXLxH5sM8oyzl56+pNqjPuSpHcsj5M5Z688+vlqx+mbdy+utqm3elA31z1uxc69Hsd2 bvcvZPnq2fi/aaESS3FGoqEWc1FxIgCkwNQjvwIAAA== Archived-At: Subject: Re: [sipcore] SIP PUSH X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 06:09:32 -0000 --_000_D5EFC98B22752christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, > I have seen approaches like maintaining a dummy call to the proxy server = without having to use all the resources of the mobile client. During this c= all, a dummy RTP packet is > sent as a keep-alive that is previously negotiated with the proxy server.= This approach has been implemented under an IMS and Push to Talk service s= cenario. > > I think it could be taken as a source of inspiration and achieve standard= ization of a mechanism 100% SIP that allows us the desired goal. I have heard about solutions like to one above also. Personally, I don=92t = think it=92s sustainable. Even =93idle=94 sessions consume resources (devic= e, radio, core network etc), and assuming there is a valid reason for Apple= mandating push, I see no reason why we should try to go around it. Also, it might affect charging, and you would have to move such sessions in= mobile use-cases, you may have to define new functions to distinguish thes= e kind of sessions from =93normal=94 sessions that just happen to be idle, = etc etc etc. Also, not all SIP-based applications even use RTP. I think a push based mechanism is much more simple, with much less impact o= n the networks. Regards, Christer On Mon, Sep 25, 2017 at 11:43 AM, Christer Holmberg > wrote: Hi, There is a problem with iOS SIP/VoIP applications (I understand the same is= coming to Android too): the application need to be =93woken up=94 using th= e Apple Push Mechanism, in order to e.g., be able to accept incoming INVITE= requests. In earlier iOS versions an incoming request could wake up the ap= plication. A solution has been discussed, where a SIP proxy (or some other network ent= ity) informs the Apple Push Server when an incoming call for Alice is comi= ng, the Apple Push Server wakes up Alice's UA VoIP application, which is th= en able to receive the INVITE request. In order to do this, the UA needs to provide some information (e.g., which = push server is used, the Alice=92s VoIP application specific push identifie= r etc) to the SIP network during registration. There is a real need for a solution in the market, and I know that people a= re looking at a number of different proprietary solutions =96 which can cau= se a real mess in the long run. Therefor I think it would be VERY important= to produce a standardised way of doing this. There IS a draft on this: https://tools.ietf.org/html/draft-ivanov-sipcore-pnsip-01 The draft uses URI parameters. We think that media feature tags should be u= sed instead. Also, we think at least one additional parameter is needed. Bu= t, in general we think the draft provides a good solution. I haven=92t managed to contact the draft author, as my e-mails are rejected= . But, if he is reading this, or if someone else is able to contact him, I= =92d like to get in contact with him :) Regards, Christer _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore -- Alberto Llamas Telecommunications Engineer dCAP | KPAC | SSCA "Internet is all about share" --_000_D5EFC98B22752christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <86FD12B5B1B59F428DD0FF66A337A276@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

> I have seen approaches like maintaining a dummy call to the proxy= server without having to use all the resources of the mobile client. Durin= g this call, a dummy RTP packet is
> sent as a keep-alive that is previously negotiated with the proxy= server. This approach has been implemented under an IMS and Push to Talk s= ervice scenario.
>
> I think it could be taken as a source of inspiration and achieve = standardization of a mechanism 100% SIP that allows us the desired goal.

I have heard about solutions like to one above also. Personally, I don= =92t think it=92s sustainable. Even =93idle=94 sessions consume resources (= device, radio, core network etc), and assuming there is a valid reason for = Apple mandating push, I see no reason why we should try to go around it.

Also, it might affect charging, and you would have to move such sessio= ns in mobile use-cases, you may have to define new functions to distinguish= these kind of sessions from =93normal=94 sessions that just happen to be i= dle, etc etc etc. Also, not all SIP-based applications even use RTP. 

I think a push based mechanism is much more simple, with much less imp= act on the networks.

Regards,

Christer


On Mon, Sep 25, 2017 at 11:43 AM, Christer Holmb= erg <chr= ister.holmberg@ericsson.com> wrote:
Hi,

There is a problem with iOS SIP/VoIP applications (I understand the sa= me is coming to Android too): the application need to be =93woken up=94 usi= ng the Apple Push Mechanism, in order to e.g., be able to accept incoming I= NVITE requests. In earlier iOS versions an incoming request could wake up the application.

A solution has been discussed, where a SIP proxy (or some other networ= k entity) informs the Apple Push Server when an incoming call  for Ali= ce is coming, the Apple Push Server wakes up Alice's UA VoIP application, w= hich is then able to receive the INVITE request.

In order to do this, the UA needs to provide some information (e.g., w= hich push server is used, the Alice=92s VoIP application specific push iden= tifier etc) to the SIP network during registration.

There is a real need for a solution in the market, and I know that peo= ple are looking at a number of different proprietary solutions =96 which ca= n cause a real mess in the long run. Therefor I think it would be VERY impo= rtant to produce a standardised way of doing this.

There IS a draft on this:


The draft uses URI parameters. We think that media feature tags should= be used instead. Also, we think at least one additional parameter is neede= d. But, in general we think the draft provides a good solution.

I haven=92t managed to contact the draft author, as my e-mails are rej= ected. But, if he is reading this, or if someone else is able to contact hi= m, I=92d like to get in contact with him :)

Regards,

Christer


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



--
Alberto Llamas
Telecommunications Eng= ineer
dCAP | KPAC | SSCA



"Internet is all about share"
 --_000_D5EFC98B22752christerholmbergericssoncom_-- From nobody Tue Sep 26 04:49:32 2017 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 5E221132195 for ; Tue, 26 Sep 2017 04:49:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=genaker-net.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 dOXmUQ4ClQTM for ; Tue, 26 Sep 2017 04:49:28 -0700 (PDT) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (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 0EB7C132193 for ; Tue, 26 Sep 2017 04:49:28 -0700 (PDT) Received: by mail-it0-x235.google.com with SMTP id c195so2556006itb.1 for ; Tue, 26 Sep 2017 04:49:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=genaker-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+FEP4K3DfClG9UBTzbJocDK4TXkdYSc5/rCp4rSkG8A=; b=QDA7lYFCSNOM0fkDQr7ajhvhfgCUaKKXb+ECChsESo/0DQIUef5RtT6Fb6Xk+IO/Z2 sAmHDxatYdyayK14g+gNC5R/npU9JUKx94ESy/qxSXJJlRxErg4hcdC6UIymQhiH0l6n LpeSJ1H+X83G8gVJhRD6EAlWtZb5XIhmD5/kmwGZ8up0IMqt/SDyJQ4REJvN629jbFif oKEzrqSdyMsMzduU3QiyVFW2VzO/I+eowz9dSzqUr7q3zZuuDxr/x/idh5UfiRQ9WMK2 YrTJlzbLmplpxTXgt/Tjrw5t5PiE6NLQn+V8SAgRLalJWS856zENNa05jFdjUDdO2Vo0 Du1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+FEP4K3DfClG9UBTzbJocDK4TXkdYSc5/rCp4rSkG8A=; b=av2bS5OV0yQqZDxQ35CgQ6D7gQf6W3KudeGfNFvGxAguEB5nri/SoaKPUb3OPpBwhv aEWssH9EhQTV6jcTSejbQ7fSgTZebeEmSHbJiPE6gVV+Ua2lchBAnCAWV83riT2ZEUx5 5q0Pdz83uBynZtO0SYTotUbwZTmheWxLDyaaPQF6+mUkbaFMzp/zB9sYN2F744mfJijH GIUigpqF6ctBaHwr+QtuqUvt/rIp/75/i7SIVwXWkY6XuOMFXI1pQtlY7Q3a5lbjkfG8 0MjtqF8ZLr46ZLq2G/Jr5qCvRMxbGZLkLATF0Fxk/tSmbj4LaVw91LMJuDuwlxL/R8AI OWOQ== X-Gm-Message-State: AHPjjUhMQshQ7hGMDhUwGj7AjpEGeJz8tISBwe7l/NEs4bKn5DfnzjV2 hHk4a34ZUkLaCcpnD1RDhR0LD2IFvI41HOvGbLXqfA== X-Google-Smtp-Source: AOwi7QAdS8LKlZ5xJkzpg5D3JCwnGxE42GAqh+L1i3zmUDpI4bNRyKO/z6WVVuvT7DmIZNMYEH5AaJNLk5E9lYL+bRo= X-Received: by 10.36.17.196 with SMTP id 187mr5111830itf.101.1506426567114; Tue, 26 Sep 2017 04:49:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.2.33.11 with HTTP; Tue, 26 Sep 2017 04:49:26 -0700 (PDT) X-Originating-IP: [2.139.201.247] In-Reply-To: References: From: David Viamonte Date: Tue, 26 Sep 2017 13:49:26 +0200 Message-ID: To: Christer Holmberg Cc: Alberto Llamas , "sipcore@ietf.org" Content-Type: multipart/alternative; boundary="001a1143e83c69d7e4055a164448" Archived-At: Subject: Re: [sipcore] SIP PUSH X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 11:49:31 -0000 --001a1143e83c69d7e4055a164448 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I fully agree the problem exists. However my question is: is this the type of issue IETF should address? One can think that dealing with SIP interconnection with previous industry standards such as ISDN or ongoing standardization work (e.g.: 3GPP IMS and their corresponding evolution) are a matter of SDO standardization work (which BTW does not always occur in IETF). However we are talking in this case about a push mechanism developed by one specific company. IMHO IETF does not generally define how B2BUAs or SBCs *should* be internally built but rather what a standard IETF implementation expects from such entities (e.g.: RFC5853 or RFC7206). To me, such "black box" dont-you-worry-I-will-take-care-of-everything approach based on such push services represent a number of concerns, not only from privacy but also from scalability, availability and transparency perspective: in the end, when you deploy a system where the actual "delivery" of information relies in an uncontrolled third party, there is little you can commit on the system you are actually trying to build. So to me even though such a problem certainly exists, I am not sure it is the type of problem IETF *should* address. At least, the way of addressing the problem should not promote the adoption of proprietary push architectures, but rather the development of a more open approach to the problem, IMHO. My two cents, David Libre de virus. www.avast.com <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> On Tue, Sep 26, 2017 at 8:09 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > I have seen approaches like maintaining a dummy call to the proxy serve= r > without having to use all the resources of the mobile client. During this > call, a dummy RTP packet is > > sent as a keep-alive that is previously negotiated with the proxy > server. This approach has been implemented under an IMS and Push to Talk > service scenario. > > > > I think it could be taken as a source of inspiration and achieve > standardization of a mechanism 100% SIP that allows us the desired goal. > > I have heard about solutions like to one above also. Personally, I don=E2= =80=99t > think it=E2=80=99s sustainable. Even =E2=80=9Cidle=E2=80=9D sessions cons= ume resources (device, > radio, core network etc), and assuming there is a valid reason for Apple > mandating push, I see no reason why we should try to go around it. > > Also, it might affect charging, and you would have to move such sessions > in mobile use-cases, you may have to define new functions to distinguish > these kind of sessions from =E2=80=9Cnormal=E2=80=9D sessions that just h= appen to be idle, > etc etc etc. Also, not all SIP-based applications even use RTP. > > I think a push based mechanism is much more simple, with much less impact > on the networks. > > Regards, > > Christer > > > On Mon, Sep 25, 2017 at 11:43 AM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > >> Hi, >> >> There is a problem with iOS SIP/VoIP applications (I understand the same >> is coming to Android too): the application need to be =E2=80=9Cwoken up= =E2=80=9D using the >> Apple Push Mechanism, in order to e.g., be able to accept incoming INVIT= E >> requests. In earlier iOS versions an incoming request could wake up the >> application. >> >> A solution has been discussed, where a SIP proxy (or some other network >> entity) informs the Apple Push Server when an incoming call for Alice i= s >> coming, the Apple Push Server wakes up Alice's UA VoIP application, whic= h >> is then able to receive the INVITE request. >> >> In order to do this, the UA needs to provide some information (e.g., >> which push server is used, the Alice=E2=80=99s VoIP application specific= push >> identifier etc) to the SIP network during registration. >> >> There is a real need for a solution in the market, and I know that peopl= e >> are looking at a number of different proprietary solutions =E2=80=93 whi= ch can >> cause a real mess in the long run. Therefor I think it would be VERY >> important to produce a standardised way of doing this. >> >> There IS a draft on this: >> >> https://tools.ietf.org/html/draft-ivanov-sipcore-pnsip-01 >> >> The draft uses URI parameters. We think that media feature tags should b= e >> used instead. Also, we think at least one additional parameter is needed= . >> But, in general we think the draft provides a good solution. >> >> I haven=E2=80=99t managed to contact the draft author, as my e-mails are >> rejected. But, if he is reading this, or if someone else is able to cont= act >> him, I=E2=80=99d like to get in contact with him :) >> >> Regards, >> >> Christer >> >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> >> > > > -- > Alberto Llamas > Telecommunications Engineer > dCAP | KPAC | SSCA > > > > *"Internet is all about share"* > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > --001a1143e83c69d7e4055a164448 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I fully agree the problem exists.

Howev= er my question is: is this the type of issue IETF should address? One can t= hink that dealing with SIP interconnection with previous industry standards= such as ISDN or ongoing standardization work (e.g.: 3GPP IMS and their cor= responding evolution) are a matter of SDO standardization work (which BTW d= oes not always occur in IETF).

However we are talk= ing in this case about a push mechanism developed by one specific company.<= /div>

IMHO IETF does not generally define how B2BUAs or = SBCs *should* be internally built but rather what a standard IETF implement= ation expects from such entities (e.g.: RFC5853 or RFC7206).

=
To me, such "black box" dont-you-worry-I-will-take-car= e-of-everything approach based on such push services represent a number of = concerns, not only from privacy but also from scalability, availability and= transparency perspective: in the end, when you deploy a system where the a= ctual "delivery" of information relies in an uncontrolled third p= arty, there is little you can commit on the system you are actually trying = to build.

So to me even though such a problem cert= ainly exists, I am not sure it is the type of problem IETF *should* address= . At least, the way of addressing the problem should not promote the adopti= on of proprietary push architectures, but rather the development of a more = open approach to the problem, IMHO.

My two cents,<= /div>

David


3D"" Libre de virus. www.avast.com
=

On Tue,= Sep 26, 2017 at 8:09 AM, Christer Holmberg <christer.holmb= erg@ericsson.com> wrote:
Hi,

> I have seen approaches like maintaining a dummy call to the proxy= server without having to use all the resources of the mobile client. Durin= g this call, a dummy RTP packet is
> sent as a keep-alive that is previously negotiated with the proxy= server. This approach has been implemented under an IMS and Push to Talk s= ervice scenario.
>
> I think it could be taken as a source of inspiration and achieve = standardization of a mechanism 100% SIP that allows us the desired goal.

I have heard about solutions like to one above also. Personally= , I don=E2=80=99t think it=E2=80=99s sustainable. Even =E2=80=9Cidle=E2=80= =9D sessions consume resources (device, radio, core network etc), and assum= ing there is a valid reason for Apple mandating push, I see no reason why we should try to go around it.

Also, it might affect charging, and you would have to move such sessio= ns in mobile use-cases, you may have to define new functions to distinguish= these kind of sessions from =E2=80=9Cnormal=E2=80=9D sessions that just ha= ppen to be idle, etc etc etc. Also, not all SIP-based applications even use RTP.=C2=A0

I think a push based mechanism is much more simple, with much less imp= act on the networks.

Regards,

Christer


On Mon, Sep 25, 2017 at 11:43 AM, Christer Holmb= erg <chr= ister.holmberg@ericsson.com> wrote:
Hi,

There is a problem with iOS SIP/VoIP applications (I understand the sa= me is coming to Android too): the application need to be =E2=80=9Cwoken up= =E2=80=9D using the Apple Push Mechanism, in order to e.g., be able to acce= pt incoming INVITE requests. In earlier iOS versions an incoming request could wake up the application.

A solution has been discussed, where a SIP proxy (or some other networ= k entity) informs the Apple Push Server when an incoming call =C2=A0for Ali= ce is coming, the Apple Push Server wakes up Alice's UA VoIP applicatio= n, which is then able to receive the INVITE request.

In order to do this, the UA needs to provide some information (e.g., w= hich push server is used, the Alice=E2=80=99s VoIP application specific pus= h identifier etc) to the SIP network during registration.

There is a real need for a solution in the market, and I know that peo= ple are looking at a number of different proprietary solutions =E2=80=93 wh= ich can cause a real mess in the long run. Therefor I think it would be VER= Y important to produce a standardised way of doing this.

There IS a draft on this:


The draft uses URI parameters. We think that media feature tags should= be used instead. Also, we think at least one additional parameter is neede= d. But, in general we think the draft provides a good solution.

I haven=E2=80=99t managed to contact the draft author, as my e-mails a= re rejected. But, if he is reading this, or if someone else is able to cont= act him, I=E2=80=99d like to get in contact with him :)

Regards,

Christer


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



--
Alberto Llamas
Telecommunications Eng= ineer
dCAP | KPAC | SSCA



"Internet is all about share"

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

--001a1143e83c69d7e4055a164448-- From nobody Tue Sep 26 04:56:58 2017 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 C3421132195 for ; Tue, 26 Sep 2017 04:56:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.319 X-Spam-Level: X-Spam-Status: No, score=-4.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de header.b=EVBsgRpX; dkim=pass (1024-bit key) header.d=telekom.onmicrosoft.de header.b=sqT0kVKN 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 6XODtUoGbuR2 for ; Tue, 26 Sep 2017 04:56:54 -0700 (PDT) Received: from mailout13.telekom.de (MAILOUT13.telekom.de [80.149.113.181]) (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 D9E76126DD9 for ; Tue, 26 Sep 2017 04:56:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1506427014; x=1537963014; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=b29nPL9mni58/g7iFonLkAcYGtuqipbpe7VRaz/Bqzs=; b=EVBsgRpXVpdJhA/FksYDw2P16lf05SQUnldmQjpoJmWAu10apPQrjujN ORLo9dGJlJQOucRy5Kh+CX/PpsVZib/H4PCT8iFQhJpWFyOotHLXHgnxG rToIX/skIumMOZFrd0ESIPbUTnWmBsBUaqYFEoSwq9k7JRNF3+tPYTZ2I Ca8TzQqO2VhTyuSP5xFrX50uJ342CJKQI/Kw8614BESCL1zgUI3o9PFcp RH0XbGuHEtPvst+PQxF8wKSS5GchObeJMrQsVMBLntOTYvDL51BEN9Zx4 LjPkxJ/kx0G89SNaUjbOPrOcVCSHLgt44YBD37WCWBGNo6SGzutEUOBrl A==; Received: from qdezc2.de.t-internal.com ([10.171.255.37]) by MAILOUT11.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Sep 2017 13:56:51 +0200 X-IronPort-AV: E=Sophos;i="5.42,440,1500933600"; d="scan'208";a="669410866" Received: from he106140.emea1.cds.t-internal.com ([10.169.119.73]) by qde0ps.de.t-internal.com with ESMTP/TLS/AES256-SHA; 26 Sep 2017 13:56:48 +0200 Received: from HE105691.EMEA1.cds.t-internal.com (10.169.119.69) by HE106140.emea1.cds.t-internal.com (10.169.119.73) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Tue, 26 Sep 2017 13:56:48 +0200 Received: from HE100181.emea1.cds.t-internal.com (10.171.40.15) by HE105691.EMEA1.cds.t-internal.com (10.169.119.69) with Microsoft SMTP Server (TLS) id 15.0.1293.2 via Frontend Transport; Tue, 26 Sep 2017 13:56:48 +0200 Received: from GER01-LEJ-obe.outbound.protection.outlook.de (51.5.80.21) by O365mail02.telekom.de (172.30.0.235) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Tue, 26 Sep 2017 13:56:17 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.onmicrosoft.de; s=selector1-telekom-onmicrosoft-de; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=b29nPL9mni58/g7iFonLkAcYGtuqipbpe7VRaz/Bqzs=; b=sqT0kVKNzykzqQs4Jdg2A2ALzlEDIhMnyFhCiBaoGh2AVe9D32YlWIOpg5g67Lz/cxv/SduKMO2YMbkTk+HacWaszGXObgVzwrge2VCPdWpwMfS6bn1dsOAvgbGe95/WBLVfmFv2RXOvR3GHNtDCO5GfEHQM4yk2w1QfUK9H1go= Received: from FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE (10.158.133.13) by FRAPR01MB0481.DEUPRD01.PROD.OUTLOOK.DE (10.158.133.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.11; Tue, 26 Sep 2017 11:56:47 +0000 Received: from FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE ([fe80::d1:57a:9b07:65a0]) by FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE ([fe80::d1:57a:9b07:65a0%15]) with mapi id 15.20.0056.018; Tue, 26 Sep 2017 11:56:46 +0000 From: "Jesske, Roland" To: "Dale R. Worley" CC: "pkyzivat@alum.mit.edu" , "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-reason-q850-loc-00.txt Thread-Index: AQHTNm5lHwns9Rd+Q2ur3wDOZdznMqLHD5uA Date: Tue, 26 Sep 2017 11:56:46 +0000 Message-ID: References: (R.Jesske@telekom.de) <87mv5i9p0x.fsf@hobgoblin.ariadne.com> In-Reply-To: <87mv5i9p0x.fsf@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=R.Jesske@telekom.de; x-originating-ip: [164.19.3.109] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; FRAPR01MB0481; 6:cH4U21te6uMWBrVbnIuM3Uxk0sj5Sc2baaY0mwu8+FvRSwdW2wUIieTaSPmvCYNvpVVHzDjGsCx6zcLWWUikygaxJQdGcmWVLBZC3j/Q9Luac2Klzlbgl3UOIysrl15qSVLARHJiBPVOlgnE1w8QhZ8ZAHOdLRVSdsmy28xe2rA3p1ALcWo5lj0NpGM7VYDoR8D4TSF17PO9njvFdRgMH1etT+dH/xHvITAGOHt7bJZDWal2IoHXzYq2hMcwXxTO/G0PQkjhUIYugVXs63nh4dRz2S6cvWsCVmairVjzYoxi3daTfsKInrcVmHCNHSpCuKgSD1cjOMm6817Xi4sCng==; 5:/7mqsVavcKg9CdCnqr9bmP9wbv61s/ZPIB3eg2G3HcoyMnJIXUbDbg+KSC63oh3DdHusvwwpK2Ei3saLUxcl6WOYKTbMCXInI0+cAZKTdzQAtKZl/cZPGQkFBnHamLWRrf9Au6AJ4n3Wwl1Iv1tPMw==; 24:EyGtGTH4KYIP4W6FFWczIfqCwldbeIu2YRyxVJJ9cbP+I3qZkex4NHGqVpRAZ9NWJge+e1dVpxoxSZS5Dt6UzMTzst/D37b3rWAlDWvXXU0=; 7:iuzDYeiMXJE6Ysj2wckPGE/sXWFQRN7YiHk7HJuEQNGUoumD+EzMVcyig16Him5ZPMIY9Q+vlSJ0hm+nc/iKK0iI2ZlWk6JnbN2+5sBMbtsmRmI9VNPf8HfFPs32Qr2kYduyF3k2vFylb5aI2k6h7/xqeIyr0FMV8MMVpgqvvZaUD9ak4h4PiJGGDApUlBW008252WzObSUQMBKxGV+vBTeQkeVSfvTs7uEnJT2vLPc= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 093042d3-ca1d-45b4-e74b-08d504d5a9eb x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:FRAPR01MB0481; x-ms-traffictypediagnostic: FRAPR01MB0481: x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(100000703101)(100105400095)(6041248)(20161123560025)(20161123558100)(20161123555025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:FRAPR01MB0481; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:FRAPR01MB0481; x-forefront-prvs: 0442E569BC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(189002)(199003)(3846002)(478600001)(86362001)(4326008)(5660300001)(106356001)(97736004)(3280700002)(33656002)(81156014)(3660700001)(2906002)(8936002)(7696004)(105586002)(7736002)(189998001)(316002)(230783001)(54906003)(2950100002)(5250100002)(14454004)(68736007)(8676002)(305945005)(81166006)(9686003)(102836003)(53936002)(54356999)(76176999)(66066001)(75402003)(6916009)(55016002)(50986999)(74482002)(6116002)(101416001)(72206003)(2900100001); DIR:OUT; SFP:1101; SCL:1; SRVR:FRAPR01MB0481; H:FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: telekom.de does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Sep 2017 11:56:46.7210 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f X-MS-Exchange-Transport-CrossTenantHeadersStamped: FRAPR01MB0481 X-OriginatorOrg: telekom.de Archived-At: Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-reason-q850-loc-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 11:56:57 -0000 Hi Dale, for me it is no problem to go with that approach. So I will add an table within the draft the looks like: The following values shall be used as location: U for 0 0 0 0 user=20 LPN for 0 0 0 1 private network serving the local user LN for 0 0 1 0 public network serving the local user=20 TN for 0 0 1 1 transit network=20 RLN for 0 1 0 0 public network serving the remote user=20 RPN for 0 1 0 1 private network serving the remote user=20 LOC-6 for 0 1 1 0 Spare INTL for 0 1 1 1 international network=20 LOC-8 for 1 0 0 0 Spare LOC-9 for 1 0 0 1 Spare BI for 1 0 1 0 network beyond interworking point LOC-11 for 1 0 1 1 Spare LOC-12 for 1 1 0 0 Spare LOC-13 for 1 1 0 1 Spare LOC-14 for 1 1 1 0 Spare LOC-15 for 1 1 1 0 Spare Best Regards Roland > -----Urspr=FCngliche Nachricht----- > Von: Dale R. Worley [mailto:worley@ariadne.com] > Gesendet: Dienstag, 26. September 2017 04:23 > An: Jesske, Roland > Cc: pkyzivat@alum.mit.edu; sipcore@ietf.org > Betreff: Re: [sipcore] I-D Action: draft-ietf-sipcore-reason-q850-loc-00.= txt >=20 > I'd favor naming all of the "extra" codes after their bit combinations: >=20 > 0 0 0 0 user (U) > 0 0 0 1 private network serving the local user (LPN) > 0 0 1 0 public network serving the local user (LN) > 0 0 1 1 transit network (TN) > 0 1 0 0 public network serving the remote user (RLN) > 0 1 0 1 private network serving the remote user (RPN) > 0 1 1 0 LOC-6 > 0 1 1 1 international network (INTL) > 1 0 0 0 LOC-8 > 1 0 0 1 LOC-9 > 1 0 1 0 network beyond interworking point (BI) > 1 0 1 1 LOC-11 > 1 1 0 0 LOC-12 > 1 1 0 1 LOC-13 > 1 1 1 0 LOC-14 > 1 1 1 1 LOC-15 >=20 > That makes the meaning of the extra codes obvious to users who don't > regularly use them. (I assume people who understand ISUP will know the > codes for U, LPN, etc.) But possibly that isn't compatible with the styl= e by > which ITU-T describes these codes. >=20 > Dale From nobody Tue Sep 26 05:21:25 2017 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 32E67132944; Tue, 26 Sep 2017 05:21:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sipcore@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.62.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150642847815.13747.9462660551554792025@ietfa.amsl.com> Date: Tue, 26 Sep 2017 05:21:18 -0700 Archived-At: Subject: [sipcore] I-D Action: draft-ietf-sipcore-sip-authn-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 12:21:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core WG of the IETF. Title : Third-Party Authentication for Session Initiation Protocol (SIP) Authors : Rifaat Shekh-Yusef Christer Holmberg Victor Pascual Filename : draft-ietf-sipcore-sip-authn-01.txt Pages : 16 Date : 2017-09-26 Abstract: This document defines an authentication mechanism for SIP, that is based on the OAuth 2.0 and OpenID Connect Core 1.0 specifications, to enable the delegation of the user authentication to a dedicated third-party IdP entity that is separate from the SIP network elements that provide the SIP service. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-authn/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sipcore-sip-authn-01 https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-sip-authn-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-sip-authn-01 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Sep 26 05:27:41 2017 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 9D0A0133091; Tue, 26 Sep 2017 05:27:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 wFT29-I-gc2h; Tue, 26 Sep 2017 05:27:38 -0700 (PDT) Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::229]) (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 0088413307F; Tue, 26 Sep 2017 05:27:37 -0700 (PDT) Received: by mail-ua0-x229.google.com with SMTP id f44so6293693uaa.0; Tue, 26 Sep 2017 05:27:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=F5kCMSzD1SbRDnwncrE53S5Xjh+YiNd/ojHLkgq3+Aw=; b=CQl3oR3IbHs/76DrgROGnxC/R98rlGgGLjVmaWWKJSIKeL45NdOCESyugbQ87OiPYx GvbOIJ5+RZ6UfKNaFGpe2D6UV2IF441Mkwjlxsqxl2cMiyH912jerBz+Q1WL5SS6CE8F 9P9r8ls6etBxCoXtz76lID1o5bUfN+/5opornAtMsE3UwdmlvYsDg5vd3zwBqjR8zVOZ /6Yw3YqnGCnLd5suQ7UPZJaW58BIZVrGvlPTMz/Y498y5kJdz8aUC8IEQZJP4ddC9i3R l5CXL8M3X9DNekbh49k1dxQvBl0e2AxvdK3HVv9tfKb45blRLvB1O1rLUa4Vb/6qIuM0 l4SQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=F5kCMSzD1SbRDnwncrE53S5Xjh+YiNd/ojHLkgq3+Aw=; b=P6FCaRJwosLwCNqDlzDREyDcgHgqkyRoHik/AQ+4k5KLeAYCyEiTOlD/7giBu0Q1dc pHD9w39KYU3rAk5IFZhYQq7uneu6Z0GXuyRgGL3jfFWeJc+QvlUUE1JkGSMRZCgmh74m kED0eA0nRXWO1wzhdHzmzNQSqxG2nrMmrzNW8saByLP+B45VBcbNaB7ZpiVVlcd/HWY1 ZU1FsJoYV4zOk2mFoU40w5SoqhJwCYvTdi300UpkNGFkM6RSD1PE4nWBOHo7+nJxzfUf ysKQLcns9yg0k81WyedP8awNWkhTtAg9/+GLP1fy+cE18xevTjsfERTtHS+GbWVtSZcd wRPQ== X-Gm-Message-State: AHPjjUhstzZ15ukkza3DJqfkREhuRdFeY7jz1hmopTfWWmzzsjTTAht3 P1bnvON1M+Kt+NE1weXVHIyamX3chLKYbWC1gtXYiA== X-Google-Smtp-Source: AOwi7QClrOtX7T4zVEpwS21buqIrtxbrA5vZDcMB2sI6t0Ah40j3wujfC0KmpBy2IoA3uhmGXmxu89D0DyTViNzVuvA= X-Received: by 10.159.54.241 with SMTP id p104mr9842628uap.143.1506428856849; Tue, 26 Sep 2017 05:27:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.91.152 with HTTP; Tue, 26 Sep 2017 05:27:36 -0700 (PDT) In-Reply-To: <150642847815.13747.9462660551554792025@ietfa.amsl.com> References: <150642847815.13747.9462660551554792025@ietfa.amsl.com> From: Rifaat Shekh-Yusef Date: Tue, 26 Sep 2017 08:27:36 -0400 Message-ID: To: internet-drafts@ietf.org Cc: i-d-announce@ietf.org, "sipcore@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c0876f8e45a24055a16ccbd" Archived-At: Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-sip-authn-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 12:27:40 -0000 --94eb2c0876f8e45a24055a16ccbd Content-Type: text/plain; charset="UTF-8" All, We have just submitted a new version of the document. We have few open issues on which we would like to get feedback from the WG. We would appreciate any reviews, comments, and feedback on the open issues or any part of the document. Regards, Rifaat On Tue, Sep 26, 2017 at 8:21 AM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Session Initiation Protocol Core WG of > the IETF. > > Title : Third-Party Authentication for Session > Initiation Protocol (SIP) > Authors : Rifaat Shekh-Yusef > Christer Holmberg > Victor Pascual > Filename : draft-ietf-sipcore-sip-authn-01.txt > Pages : 16 > Date : 2017-09-26 > > Abstract: > This document defines an authentication mechanism for SIP, that is > based on the OAuth 2.0 and OpenID Connect Core 1.0 specifications, to > enable the delegation of the user authentication to a dedicated > third-party IdP entity that is separate from the SIP network elements > that provide the SIP service. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-authn/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-sipcore-sip-authn-01 > https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-sip-authn-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-sip-authn-01 > > > 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. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --94eb2c0876f8e45a24055a16ccbd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All,

We have just submitted a new versi= on of the document.
We have few open issues on which we would lik= e to get feedback from the WG.

We would appreciate= any reviews, comments, and feedback on the open issues or any part of the = document.

Regards,
=C2=A0Rifaat


On Tue, Sep 26, 2017 at 8:21 AM, <internet-drafts@ietf.org>= ; wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Session Initiation Protocol Core WG of the= IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Third-Party Authentication for Session Initiation Protocol (SIP)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Rifa= at Shekh-Yusef
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Christer Holmberg
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Victor Pascual
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-sipcore-sip-authn-01.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 16
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-09-26

Abstract:
=C2=A0 =C2=A0This document defines an authentication mechanism for SIP, tha= t is
=C2=A0 =C2=A0based on the OAuth 2.0 and OpenID Connect Core 1.0 specificati= ons, to
=C2=A0 =C2=A0enable the delegation of the user authentication to a dedicate= d
=C2=A0 =C2=A0third-party IdP entity that is separate from the SIP network e= lements
=C2=A0 =C2=A0that provide the SIP service.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/= draft-ietf-sipcore-sip-authn/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ie= tf-sipcore-sip-authn-01
https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-sip-authn-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipcore-sip-authn-01


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

--94eb2c0876f8e45a24055a16ccbd-- From nobody Tue Sep 26 05:28:50 2017 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 BBD741330BF for ; Tue, 26 Sep 2017 05:28:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=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 go8MtEZ2JrGa for ; Tue, 26 Sep 2017 05:28:47 -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 0229713307F for ; Tue, 26 Sep 2017 05:28:46 -0700 (PDT) X-AuditID: c1b4fb25-967ff70000005333-28-59ca47fc5324 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id C5.82.21299.CF74AC95; Tue, 26 Sep 2017 14:28:44 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.6]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0352.000; Tue, 26 Sep 2017 14:28:44 +0200 From: Christer Holmberg To: David Viamonte CC: Alberto Llamas , "sipcore@ietf.org" Thread-Topic: [sipcore] SIP PUSH Thread-Index: AQHTNfOMhpjgVdXGfkOKwB3589Ama6LGeakAgABIqgCAACtAAIAAPr4A Date: Tue, 26 Sep 2017 12:28:43 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.147] Content-Type: multipart/alternative; boundary="_000_D5F01D6E22982christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCIsWRmVeSWpSXmKPExsUyM2K7qO4f91ORBsc22ljMnH2YxeLDzqls Fl9/bGJzYPZYtmsno8fOWXfZPZYs+ckUwBzFZZOSmpNZllqkb5fAlfFj626Wgv2TGCuO/V7F 1sD4r6qLkZNDQsBEYsnv/8xdjFwcQgJHGCV+T3vFBOEsYpQ49W4NYxcjBwebgIVE9z9tkAYR AX2Jth39jCA2s0CYRMPRu0wgtrCAvMSDmYuZIGoUJJZ1zmODsN0kJt/qA6tnEVCVWPtwMlgN r4C1xM2uuewgtpDAb0aJz/dYQWxOgUCJZX8ngNUwCohJfD+1hglil7jErSfzmSCOFpBYsuc8 M4QtKvHy8T+wXlEBPYkNJ26zg5wsIaAkMW1rGojJLJAg8Wh+HsRWQYmTM5+wTGAUnYVk6CyE qllIqiBKDCTen5vPDGFrSyxb+BrK1pfY+OUsI4RtLXFn7nE2ZDULGDlWMYoWpxYn5aYbGeul FmUmFxfn5+nlpZZsYgTG5cEtv1V3MF5+43iIUYCDUYmHd5rFqUgh1sSy4srcQ4wSHMxKIrzf XYBCvCmJlVWpRfnxRaU5qcWHGKU5WJTEeR33XYgQEkhPLEnNTk0tSC2CyTJxcEo1MIZ42q8L eHjxlYbihZZJP0JUGyxfHpjsxu7YnVs695TJKab5Xo+vOW5Z/noxj0bksalS/97zX4mV45lW 7qF5Lem6jYJFcGJSDWN69/n9m3PcfpVdri/ee9V7U1CmYSvP79PptbOi/zckPWw9xmHNlf2V 38pzZswTZzchoYCpHw0v6GcENz+oU2Ipzkg01GIuKk4EAIE7bNfHAgAA Archived-At: Subject: Re: [sipcore] SIP PUSH X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 12:28:50 -0000 --_000_D5F01D6E22982christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, > I fully agree the problem exists. > > However my question is: is this the type of issue IETF should address? On= e can think that dealing with SIP interconnection with previous industry st= andards such as ISDN or ongoing standardization > work (e.g.: 3GPP IMS and their corresponding evolution) are a matter of S= DO standardization work (which BTW does not always occur in IETF). For sure this could be done elsewhere. But, while this is related to a spec= ific mobile OS, it is NOT related to a specific SIP network/architecture, w= hich is why I thought people might be interested to do it in IETF. > However we are talking in this case about a push mechanism developed by o= ne specific company. > > IMHO IETF does not generally define how B2BUAs or SBCs *should* be intern= ally built but rather what a standard IETF implementation expects from such= entities (e.g.: RFC5853 or RFC7206). The suggested mechanism doesn=92t require a B2BUAs or SBC. The push can be = triggered by a normal SIP proxy. > To me, such "black box" dont-you-worry-I-will-take-care-of-everything app= roach based on such push services represent a number of concerns, not only = from privacy but also from scalability, availability > and transparency perspective: in the end, when you deploy a system where = the actual "delivery" of information relies in an uncontrolled third party,= there is little you can commit on the system you are actually trying to bu= ild. Well, if people have issues with that, they shouldn=92t use iOS to begin wi= th, because there are many types of applications that use the push mechanis= m. Note that I am NOT suggesting that non-iOS applications would have to us= e the push mechanism. And, privacy is the main reason why we suggest that the only information se= nt to the push server by the proxy is the token id (which the push server h= as generated). The only thing the push server knows is that it needs to, fo= r some reason, wake up the user associated with the token id. > So to me even though such a problem certainly exists, I am not sure it is= the type of problem IETF *should* address. At least, the way of addressing= the problem should not promote > the adoption of proprietary push architectures, but rather the developmen= t of a more open approach to the problem, IMHO. I am not promoting adoption of the push architecture =96 I am promoting a m= echanism which would allow people to continue using SIP-based applications = in an environment that requires usage of the push architecture :) Regards, Christer [https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-anim= ated-no-repeat-v1.gif] Libre de = virus. www.avast.com On Tue, Sep 26, 2017 at 8:09 AM, Christer Holmberg > wrote: Hi, > I have seen approaches like maintaining a dummy call to the proxy server = without having to use all the resources of the mobile client. During this c= all, a dummy RTP packet is > sent as a keep-alive that is previously negotiated with the proxy server.= This approach has been implemented under an IMS and Push to Talk service s= cenario. > > I think it could be taken as a source of inspiration and achieve standard= ization of a mechanism 100% SIP that allows us the desired goal. I have heard about solutions like to one above also. Personally, I don=92t = think it=92s sustainable. Even =93idle=94 sessions consume resources (devic= e, radio, core network etc), and assuming there is a valid reason for Apple= mandating push, I see no reason why we should try to go around it. Also, it might affect charging, and you would have to move such sessions in= mobile use-cases, you may have to define new functions to distinguish thes= e kind of sessions from =93normal=94 sessions that just happen to be idle, = etc etc etc. Also, not all SIP-based applications even use RTP. I think a push based mechanism is much more simple, with much less impact o= n the networks. Regards, Christer On Mon, Sep 25, 2017 at 11:43 AM, Christer Holmberg > wrote: Hi, There is a problem with iOS SIP/VoIP applications (I understand the same is= coming to Android too): the application need to be =93woken up=94 using th= e Apple Push Mechanism, in order to e.g., be able to accept incoming INVITE= requests. In earlier iOS versions an incoming request could wake up the ap= plication. A solution has been discussed, where a SIP proxy (or some other network ent= ity) informs the Apple Push Server when an incoming call for Alice is comi= ng, the Apple Push Server wakes up Alice's UA VoIP application, which is th= en able to receive the INVITE request. In order to do this, the UA needs to provide some information (e.g., which = push server is used, the Alice=92s VoIP application specific push identifie= r etc) to the SIP network during registration. There is a real need for a solution in the market, and I know that people a= re looking at a number of different proprietary solutions =96 which can cau= se a real mess in the long run. Therefor I think it would be VERY important= to produce a standardised way of doing this. There IS a draft on this: https://tools.ietf.org/html/draft-ivanov-sipcore-pnsip-01 The draft uses URI parameters. We think that media feature tags should be u= sed instead. Also, we think at least one additional parameter is needed. Bu= t, in general we think the draft provides a good solution. I haven=92t managed to contact the draft author, as my e-mails are rejected= . But, if he is reading this, or if someone else is able to contact him, I= =92d like to get in contact with him :) Regards, Christer _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore -- Alberto Llamas Telecommunications Engineer dCAP | KPAC | SSCA "Internet is all about share" _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore --_000_D5F01D6E22982christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <52B6ED960AF24540A34EED1152080703@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

> I fully agree the problem exists.
>
> However my question is: is this the type of issue IETF should add= ress? One can think that dealing with SIP interconnection with previous ind= ustry standards such as ISDN or ongoing standardization
> work (e.g.: 3GPP IMS and their corresponding evolution) are a mat= ter of SDO standardization work (which BTW does not always occur in IETF).<= /div>

For sure this could be done elsewhere. But, while this is related to a= specific mobile OS, it is NOT related to a specific SIP network/architectu= re, which is why I thought people might be interested to do it in IETF.

> However we are talking in this case about a push mechanism develo= ped by one specific company.
>
> IMHO IETF does not generally define how B2BUAs or SBCs *should* b= e internally built but rather what a standard IETF implementation expects f= rom such entities (e.g.: RFC5853 or RFC7206).

The suggested mechanism doesn=92t require a B2BUAs or SBC. The push ca= n be triggered by a normal SIP proxy.

> To me, such "black box" dont-you-worry-I-will-take-care= -of-everything approach based on such push services represent a number of c= oncerns, not only from privacy but also from scalability, availability
> and transparency perspective: in the end, when you deploy a syste= m where the actual "delivery" of information relies in an uncontr= olled third party, there is little you can commit on the system you are act= ually trying to build.

Well, if people have issues with that, they shouldn=92t use iOS to beg= in with, because there are many types of applications that use the push mec= hanism. Note that I am NOT suggesting that non-iOS applications would have = to use the push mechanism.

And, privacy is the main reason why we suggest that the only informati= on sent to the push server by the proxy is the token id (which the push ser= ver has generated). The only thing the push server knows is that it needs t= o, for some reason, wake up the user associated with the token id.

> So to me even though such a problem certainly exists, I am not su= re it is the type of problem IETF *should* address. At least, the way of ad= dressing the problem should not promote
> the adoption of proprietary push architectures, but rather the de= velopment of a more open approach to the problem, IMHO.

I am not promoting adoption of the push architecture =96 I am promotin= g a mechanism which would allow people to continue using SIP-based applicat= ions in an environment that requires usage of the push architecture :)

Regards,

Christer






3D"" Libre de virus. www.avast.com
=

On Tue, Sep 26, 2017 at 8:09 AM, Christer Holmbe= rg <chr= ister.holmberg@ericsson.com> wrote:
Hi,

> I have seen approaches like maintaining a dummy call to the proxy= server without having to use all the resources of the mobile client. Durin= g this call, a dummy RTP packet is
> sent as a keep-alive that is previously negotiated with the proxy= server. This approach has been implemented under an IMS and Push to Talk s= ervice scenario.
>
> I think it could be taken as a source of inspiration and achieve = standardization of a mechanism 100% SIP that allows us the desired goal.

I have heard about solutions like to one above also. Personally, I don= =92t think it=92s sustainable. Even =93idle=94 sessions consume resources (= device, radio, core network etc), and assuming there is a valid reason for = Apple mandating push, I see no reason why we should try to go around it.

Also, it might affect charging, and you would have to move such sessio= ns in mobile use-cases, you may have to define new functions to distinguish= these kind of sessions from =93normal=94 sessions that just happen to be i= dle, etc etc etc. Also, not all SIP-based applications even use RTP. 

I think a push based mechanism is much more simple, with much less imp= act on the networks.

Regards,

Christer


On Mon, Sep 25, 2017 at 11:43 AM, Christer Holmb= erg <chr= ister.holmberg@ericsson.com> wrote:
Hi,

There is a problem with iOS SIP/VoIP applications (I understand the sa= me is coming to Android too): the application need to be =93woken up=94 usi= ng the Apple Push Mechanism, in order to e.g., be able to accept incoming I= NVITE requests. In earlier iOS versions an incoming request could wake up the application.

A solution has been discussed, where a SIP proxy (or some other networ= k entity) informs the Apple Push Server when an incoming call  for Ali= ce is coming, the Apple Push Server wakes up Alice's UA VoIP application, w= hich is then able to receive the INVITE request.

In order to do this, the UA needs to provide some information (e.g., w= hich push server is used, the Alice=92s VoIP application specific push iden= tifier etc) to the SIP network during registration.

There is a real need for a solution in the market, and I know that peo= ple are looking at a number of different proprietary solutions =96 which ca= n cause a real mess in the long run. Therefor I think it would be VERY impo= rtant to produce a standardised way of doing this.

There IS a draft on this:


The draft uses URI parameters. We think that media feature tags should= be used instead. Also, we think at least one additional parameter is neede= d. But, in general we think the draft provides a good solution.

I haven=92t managed to contact the draft author, as my e-mails are rej= ected. But, if he is reading this, or if someone else is able to contact hi= m, I=92d like to get in contact with him :)

Regards,

Christer


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



--
Alberto Llamas
Telecommunications Eng= ineer
dCAP | KPAC | SSCA



"Internet is all about share"

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

--_000_D5F01D6E22982christerholmbergericssoncom_-- From nobody Tue Sep 26 07:41:36 2017 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 03F04126B71 for ; Tue, 26 Sep 2017 07:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 3iZTw4ED05ch for ; Tue, 26 Sep 2017 07:41:33 -0700 (PDT) Received: from alum-mailsec-scanner-2.mit.edu (alum-mailsec-scanner-2.mit.edu [18.7.68.13]) by ietfa.amsl.com (Postfix) with ESMTP id B8226132A89 for ; Tue, 26 Sep 2017 07:41:33 -0700 (PDT) X-AuditID: 1207440d-853ff70000000f42-45-59ca671b57bb Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id CE.6D.03906.B176AC95; Tue, 26 Sep 2017 10:41:31 -0400 (EDT) Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id v8QEfUBf023288 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 26 Sep 2017 10:41:30 -0400 To: "Jesske, Roland" , "Dale R. Worley" Cc: "sipcore@ietf.org" References: <87mv5i9p0x.fsf@hobgoblin.ariadne.com> From: Paul Kyzivat Message-ID: <343c1941-b239-87fa-5584-5fe3039e45b5@alum.mit.edu> Date: Tue, 26 Sep 2017 10:41:29 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplleLIzCtJLcpLzFFi42IRYndR1JVJPxVpsPE/s0XTnS42i68/NrFZ vDxR5sDsMXn/V2aPJUt+Mnm0vVQIYI7isklJzcksSy3St0vgyrgy/TVLwUWBipO3LrA3MC7j 6WLk5JAQMJHofvuDuYuRi0NIYAeTxJb5X9hAEkICD5kk3n/lALGFBYIk7ryZzghiiwhESVyY e4sdxGYW0JTYvO4CO0TzNUaJWWtWM4Mk2AS0JOYc+s8CYvMK2Es8OfgVbCiLgKrEm0MbmEBs UYE0iX+7zzJC1AhKnJz5BKyeUyBGYvqhJkaIBWYS8zY/ZIawxSVuPZnPBGHLSzRvnc08gVFg FpL2WUhaZiFpmYWkZQEjyypGucSc0lzd3MTMnOLUZN3i5MS8vNQiXSO93MwSvdSU0k2MkJDm 3cH4f53MIUYBDkYlHl6GkFORQqyJZcWVuYcYJTmYlER5FeWAQnxJ+SmVGYnFGfFFpTmpxYcY JTiYlUR41WOBcrwpiZVVqUX5MClpDhYlcV61Jep+QgLpiSWp2ampBalFMFkZDg4lCd6gNKBG waLU9NSKtMycEoQ0EwcnyHAeoOHnQWp4iwsSc4sz0yHypxh1OXp6bvxhEmLJy89LlRLnFQMp EgApyijNg5sDS0WvGMWB3hLmlQCp4gGmMbhJr4CWMAEt6Z16AmRJSSJCSqqBcfa3HSm/1v1l LVg742lecIOyz6G3C4RaGVPUpPPeTRNk+JmycvWVfVsm1D+RfKbz6u/HxZw6jR+M/QVKUsw+ lydKXHXwT31zXvNoZ+fhsqv7Hu2o4Vzw2Tkp58/U/AVb1r8xPDPt2+eeHXe/fJiV/uIBf/sv hs2djpuUJiecq7M/Yrl2q97W36xKLMUZiYZazEXFiQBk85w4IAMAAA== Archived-At: Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-reason-q850-loc-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 14:41:35 -0000 WFM On 9/26/17 7:56 AM, Jesske, Roland wrote: > Hi Dale, > for me it is no problem to go with that approach. > So I will add an table within the draft the looks like: > > The following values shall be used as location: > U for 0 0 0 0 user > LPN for 0 0 0 1 private network serving the local user > LN for 0 0 1 0 public network serving the local user > TN for 0 0 1 1 transit network > RLN for 0 1 0 0 public network serving the remote user > RPN for 0 1 0 1 private network serving the remote user > LOC-6 for 0 1 1 0 Spare > INTL for 0 1 1 1 international network > LOC-8 for 1 0 0 0 Spare > LOC-9 for 1 0 0 1 Spare > BI for 1 0 1 0 network beyond interworking point > LOC-11 for 1 0 1 1 Spare > LOC-12 for 1 1 0 0 Spare > LOC-13 for 1 1 0 1 Spare > LOC-14 for 1 1 1 0 Spare > LOC-15 for 1 1 1 0 Spare > > Best Regards > > Roland > >> -----Ursprüngliche Nachricht----- >> Von: Dale R. Worley [mailto:worley@ariadne.com] >> Gesendet: Dienstag, 26. September 2017 04:23 >> An: Jesske, Roland >> Cc: pkyzivat@alum.mit.edu; sipcore@ietf.org >> Betreff: Re: [sipcore] I-D Action: draft-ietf-sipcore-reason-q850-loc-00.txt >> >> I'd favor naming all of the "extra" codes after their bit combinations: >> >> 0 0 0 0 user (U) >> 0 0 0 1 private network serving the local user (LPN) >> 0 0 1 0 public network serving the local user (LN) >> 0 0 1 1 transit network (TN) >> 0 1 0 0 public network serving the remote user (RLN) >> 0 1 0 1 private network serving the remote user (RPN) >> 0 1 1 0 LOC-6 >> 0 1 1 1 international network (INTL) >> 1 0 0 0 LOC-8 >> 1 0 0 1 LOC-9 >> 1 0 1 0 network beyond interworking point (BI) >> 1 0 1 1 LOC-11 >> 1 1 0 0 LOC-12 >> 1 1 0 1 LOC-13 >> 1 1 1 0 LOC-14 >> 1 1 1 1 LOC-15 >> >> That makes the meaning of the extra codes obvious to users who don't >> regularly use them. (I assume people who understand ISUP will know the >> codes for U, LPN, etc.) But possibly that isn't compatible with the style by >> which ITU-T describes these codes. >> >> Dale > From nobody Tue Sep 26 17:44:26 2017 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 9DFA11344CB for ; Tue, 26 Sep 2017 17:44:23 -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 4tMh49-PL9iX for ; Tue, 26 Sep 2017 17:44:22 -0700 (PDT) Received: from resqmta-ch2-06v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:38]) (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 74CB51344CE for ; Tue, 26 Sep 2017 17:44:22 -0700 (PDT) Received: from resomta-ch2-10v.sys.comcast.net ([69.252.207.106]) by resqmta-ch2-06v.sys.comcast.net with ESMTP id x0SXdT6LD6HEkx0Sbd1Awv; Wed, 27 Sep 2017 00:44:21 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-10v.sys.comcast.net with SMTP id x0SZdjwAzhHTKx0SadSjlT; Wed, 27 Sep 2017 00:44:20 +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 v8R0iIdP000495; Tue, 26 Sep 2017 20:44:18 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v8R0iIAl000492; Tue, 26 Sep 2017 20:44:18 -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: "Jesske\, Roland" Cc: sipcore@ietf.org In-Reply-To: (R.Jesske@telekom.de) Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 26 Sep 2017 20:44:17 -0400 Message-ID: <87h8vp9di6.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfFDgdUYvcvTtXXm4/kIPUsoXJUGskzZWPU0TmQPy4NXa3YGJ3RFlqij8O3wThI1/1534X917bihFf/mgi+SSFwuzEGsYZpDCqCo0BuhCaCIBUW19VnMj RRvW7tjYvDbwKi/yTZTU7o2Y8szcLRKsv+XSd5UKv2Rr9s9B4T0L0zm1QqrCDJacd8ABLGysdiNedg== Archived-At: Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-reason-q850-loc-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 00:44:24 -0000 "Jesske, Roland" writes: > for me it is no problem to go with that approach. > So I will add an table within the draft the looks like: > > The following values shall be used as location: > U for 0 0 0 0 user > LPN for 0 0 0 1 private network serving the local user > LN for 0 0 1 0 public network serving the local user > TN for 0 0 1 1 transit network > RLN for 0 1 0 0 public network serving the remote user > RPN for 0 1 0 1 private network serving the remote user > LOC-6 for 0 1 1 0 Spare > INTL for 0 1 1 1 international network > LOC-8 for 1 0 0 0 Spare > LOC-9 for 1 0 0 1 Spare > BI for 1 0 1 0 network beyond interworking point > LOC-11 for 1 0 1 1 Spare > LOC-12 for 1 1 0 0 Spare > LOC-13 for 1 1 0 1 Spare > LOC-14 for 1 1 1 0 Spare > LOC-15 for 1 1 1 0 Spare I don't want to push for this approach too hard -- if the ITU-T recommendations have any sort of names for these values, I would favor those. But if there are no pre-existing names or designations, naming them after the bit combinations seems the easiest to understand. Dale From nobody Tue Sep 26 17:57:57 2017 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 BADB91344D1 for ; Tue, 26 Sep 2017 17:57:55 -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 JR88qg7un6IK for ; Tue, 26 Sep 2017 17:57:55 -0700 (PDT) Received: from resqmta-ch2-09v.sys.comcast.net (resqmta-ch2-09v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:41]) (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 126001344CE for ; Tue, 26 Sep 2017 17:57:55 -0700 (PDT) Received: from resomta-ch2-05v.sys.comcast.net ([69.252.207.101]) by resqmta-ch2-09v.sys.comcast.net with ESMTP id x0fNdEtpvfL6vx0fhdfTgj; Wed, 27 Sep 2017 00:57:53 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-05v.sys.comcast.net with SMTP id x0fgdm15HjdGux0fhdJSkW; Wed, 27 Sep 2017 00:57:53 +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 v8R0vpod001449; Tue, 26 Sep 2017 20:57:51 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v8R0vpe0001445; Tue, 26 Sep 2017 20:57:51 -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 Cc: sipcore@ietf.org In-Reply-To: Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 26 Sep 2017 20:57:50 -0400 Message-ID: <87efqt9cvl.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfPvaYKjwVY2DD6DGmNhh+FA39xizlVu7ydgDdAasc7OS+gZ+k1GbFjp/Iiu5sPcmaPgRHDFUBNK4ver2bn2A02rOaWPk+LPfMpAMRJt9WGN8/PT7Y5yv ldks++P79T6tlu1S5RAH94ggpfGPKo9IenXcJev0uJyNMEH1IP0KvWDHPWSbMkooOYRHfCiaGi+TN4N4bzmGsWFOda2EBzxp08A= Archived-At: Subject: Re: [sipcore] SIP PUSH X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 00:57:56 -0000 Christer Holmberg writes: > There is a real need for a solution in the market, and I know that > people are looking at a number of different proprietary solutions -- > which can cause a real mess in the long run. Therefor I think it would > be VERY important to produce a standardised way of doing this. I know I'm being cranky about this, but MHO is that the market needs to be told -- loudly -- that what Apple has done is a Bad Idea. Yes, people will develop a variety of proprietary solutions, but that will increase the cost and inconvenience of interoperating with Apple's mistaken architecture. The goal is to get Apple to abandon this idea and implement something much closer to how Internet applications are supposed to work. Dale From nobody Tue Sep 26 18:03:26 2017 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 EED621344CB for ; Tue, 26 Sep 2017 18:03:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 ThdFKKeZAJfY for ; Tue, 26 Sep 2017 18:03:23 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::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 647C313232C for ; Tue, 26 Sep 2017 18:03:23 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id l74so14601508oih.1 for ; Tue, 26 Sep 2017 18:03:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qLlXgSPc1WOecbYi+t0iboVFVjXcE1A3+jeMdnF5f0Y=; b=t+wY+BQzhpV+e2O8GPK7uhzocCrTaxV0mZIxX+aGJGhAKEFkcVwFXelZq2gFplBpSm F8UqZdKrkPFWVUku2v8pqxVqqXLSL1RxhmmK4rIitBzLqlgpXy6aqwQc2ABfu2hE1GJG PL7QrpifKaPH18uWwEcR5Mc+1XzEtKZZODv1d1Rw7zf9YKjd8WUtgDDrVK/YKUYaVtKT GwAScpRSjmfHJax+opT3cdia7zGwPQ3dI6yH26DKStVu5qjId4hC+RtNlacyWp24vdV2 pr84pNZEjbSGFfly4QPA2uZNoTDqw18DPRlryADYKGqiGB581Qw3CxpIWxxQ1tsp3Ruh RdxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qLlXgSPc1WOecbYi+t0iboVFVjXcE1A3+jeMdnF5f0Y=; b=DBIazdTXvNJNnRmzFidlQQGWsAtul4Pg7a+8srzxNAvXpPrLWRr+iRsSk56seS7wY1 dhw5uKyLwjlD/8jriRmF/5SihPdbeyVcmIejr7c3iyD3uRIxjDT2juv7CEBSkTUorC7J Tgmce7DsR7gmTF2Gb4DLOLNIQc1R0VPSJ4JT0zr0tpaB7/7tSOJkMQEGnmomm9HNmz+N VZs2zExXzq352UE29ekf42RJ/mlBTQe14YkxmDdoe1vbaP0ySfLoSv2PK8qMElcWz/gF 35ylr1Hydu7bS019RRRNj1LgUNTjkd1jVhU9yFdzgn8NgsWiFi2aPa+nGJf3/j/Lrf6x BoTw== X-Gm-Message-State: AHPjjUjw7lthcB3dOsiMKJHohmjD5GfDkxNX8Z4/t2rc7ioPG9tlJOTx kMjJEeT62nMHsDBaeZNoC64Dkv/odkvJ77Pnd4hCEA== X-Google-Smtp-Source: AOwi7QC1ZlqcFlyDfBCbet9YP1UcklHLrSW5utLUysOPg6dRSj7/xolydUGaR7tegV8NW20rMiilTp/n0xFvhTQ5J74= X-Received: by 10.202.102.36 with SMTP id a36mr13093862oic.83.1506474202706; Tue, 26 Sep 2017 18:03:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.0.38 with HTTP; Tue, 26 Sep 2017 18:03:22 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Wed, 27 Sep 2017 11:03:22 +1000 Message-ID: To: Christer Holmberg Cc: "sipcore@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [sipcore] SIP PUSH X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 01:03:25 -0000 On Mon, Sep 25, 2017 at 9:43 PM, Christer Holmberg wrote: > There IS a draft on this: > > https://tools.ietf.org/html/draft-ivanov-sipcore-pnsip-01 > > The draft uses URI parameters. We think that media feature tags should be > used instead. Also, we think at least one additional parameter is needed. > But, in general we think the draft provides a good solution. I don't think that this is the right plan. I would prefer to see something that is compatible with web push. From nobody Tue Sep 26 22:03:07 2017 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 D98F8133074 for ; Tue, 26 Sep 2017 22:03:05 -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 xvUjCjuf4xNq for ; Tue, 26 Sep 2017 22:03:04 -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 2E04A1321CB for ; Tue, 26 Sep 2017 22:03:04 -0700 (PDT) X-AuditID: c1b4fb3a-9e1d49c0000051a3-d5-59cb31057974 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 3E.15.20899.5013BC95; Wed, 27 Sep 2017 07:03:01 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.6]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0352.000; Wed, 27 Sep 2017 07:02:49 +0200 From: Christer Holmberg To: Martin Thomson CC: "sipcore@ietf.org" Thread-Topic: [sipcore] SIP PUSH Thread-Index: AQHTNfOMhpjgVdXGfkOKwB3589Ama6LHy2UAgABkNQA= Date: Wed, 27 Sep 2017 05:02:49 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B562FE77B@ESESSMB109.ericsson.se> References: 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.150] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyM2K7oi6r4elIg4771hbXzvxjtPj6YxOb A5PHzll32T2WLPnJFMAUxWWTkpqTWZZapG+XwJUx+c9zloIbrBXfL/SwNDAeYe1i5OSQEDCR WLPqKGMXIxeHkMARRomzv1dCOYsYJV7v6QCq4uBgE7CQ6P6nDdIgIqArsejsA3YQm1lAU+LR zr1MILawgLzExnXHWCFqFCSWdc5jg7CtJNr2vgOzWQRUJY73HwazeQV8JZ6fPsQOsauJUeLC xmtgzZwCgRLnZ05hBLEZBcQkvp9awwSxTFzi1pP5TBBXC0gs2XOeGcIWlXj5+B/UN0oSK7Zf YgS5GeS49bv0IVoVJaZ0P2SH2CsocXLmE5YJjKKzkEydhdAxC0nHLCQdCxhZVjGKFqcWF+em GxnppRZlJhcX5+fp5aWWbGIERsnBLb+tdjAefO54iFGAg1GJh3eH3OlIIdbEsuLK3EOMEhzM SiK8ivxAId6UxMqq1KL8+KLSnNTiQ4zSHCxK4rwO+y5ECAmkJ5akZqemFqQWwWSZODilGhjL rcxNN735y9mhUDe7VoTR+cqhIvFKtyaWL5OXqkb/N+m23RS23Gd3rLfUvEazp6t74oXmsTSV TPlzKjlDbeOh++VlXE0fkv5dfR35keVzxbL3Vrp6Hf/Ob30hnxO048U7DeZj1rnfrCbs4d0U 8PDKHvN3wtv1pGpnmV6IlRLXb80/YN8q91uJpTgj0VCLuag4EQCBt1+ljgIAAA== Archived-At: Subject: Re: [sipcore] SIP PUSH X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 05:03:06 -0000 SGkgTWFydGluLA0KDQo+PiBUaGVyZSBJUyBhIGRyYWZ0IG9uIHRoaXM6DQo+Pg0KPj4gaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWl2YW5vdi1zaXBjb3JlLXBuc2lwLTAxDQo+Pg0K Pj4gVGhlIGRyYWZ0IHVzZXMgVVJJIHBhcmFtZXRlcnMuIFdlIHRoaW5rIHRoYXQgbWVkaWEgZmVh dHVyZSB0YWdzIHNob3VsZCANCj4+IGJlIHVzZWQgaW5zdGVhZC4gQWxzbywgd2UgdGhpbmsgYXQg bGVhc3Qgb25lIGFkZGl0aW9uYWwgcGFyYW1ldGVyIGlzIG5lZWRlZC4NCj4+IEJ1dCwgaW4gZ2Vu ZXJhbCB3ZSB0aGluayB0aGUgZHJhZnQgcHJvdmlkZXMgYSBnb29kIHNvbHV0aW9uLg0KPg0KPkkg ZG9uJ3QgdGhpbmsgdGhhdCB0aGlzIGlzIHRoZSByaWdodCBwbGFuLiAgSSB3b3VsZCBwcmVmZXIg dG8gc2VlIHNvbWV0aGluZyB0aGF0IGlzIGNvbXBhdGlibGUgPndpdGggd2ViIHB1c2guDQoNCldo eSB3b3VsZG4ndCB5b3UgYmUgYWJsZSB0byB1c2UgdGhpcyB3aXRoIHdlYiBwdXNoPw0KDQpSZWdh cmRzLA0KDQpDaHJpc3Rlcg0K From nobody Tue Sep 26 22:08:36 2017 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 BB5661321CB for ; Tue, 26 Sep 2017 22:08:34 -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 fIPQup3efmm5 for ; Tue, 26 Sep 2017 22:08: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 3DFAE13422B for ; Tue, 26 Sep 2017 22:08:33 -0700 (PDT) X-AuditID: c1b4fb3a-5ffff700000051a3-1c-59cb324f428f Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id B4.F5.20899.F423BC95; Wed, 27 Sep 2017 07:08:31 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.6]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0352.000; Wed, 27 Sep 2017 07:08:30 +0200 From: Christer Holmberg To: "Dale R. Worley" CC: "sipcore@ietf.org" Thread-Topic: [sipcore] SIP PUSH Thread-Index: AQHTNfOMhpjgVdXGfkOKwB3589Ama6LHydoAgABmFDA= Date: Wed, 27 Sep 2017 05:08:30 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B562FE7D6@ESESSMB109.ericsson.se> References: <87efqt9cvl.fsf@hobgoblin.ariadne.com> In-Reply-To: <87efqt9cvl.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.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyM2K7uq6/0elIg7XblC2+/tjEZvHyRJkD k8fk/V+ZPZYs+ckUwBTFZZOSmpNZllqkb5fAlfHkXSdbwRX2ivfPPzE2MHawdTFyckgImEi0 7tjF2MXIxSEkcIRR4mzrNlYIZxGjxO+dP4AyHBxsAhYS3f+0QUwRAU2JjgU5IL3MQOajnXuZ QGxhAXmJjeuOsYLYIgIKEss657FB2FYSF/e9YwexWQRUJT6dWscGMoZXwFdi844ykLCQQIpE 163DYK2cAsYSX24/ZAaxGQXEJL6fWsMEsUpc4taT+UwQJwtILNlznhnCFpV4+fgfK4StJLFi +yVGiHodiQW7P7FB2NoSyxa+BqvnFRCUODnzCcsERtFZSMbOQtIyC0nLLCQtCxhZVjGKFqcW F+emGxnppRZlJhcX5+fp5aWWbGIERsjBLb+tdjAefO54iFGAg1GJh3eH3OlIIdbEsuLK3EOM EhzMSiK8ivxAId6UxMqq1KL8+KLSnNTiQ4zSHCxK4rwO+y5ECAmkJ5akZqemFqQWwWSZODil GhjTp3039837/S+nbkW9q4qUtOXCKL48U1Uhm6YzV77vYmVbPX92s0ONo83KjNhcLfGSXBuu ZsXusFf372fE1j3+aMkQdf/R6pbnWXyLpgbw3as2ujcreHfVnpJ46UlsB/67JV/aePiewcKY y9uPGB/8Jl275H2ZU15vwzWR00tX5vr29ybttFFiKc5INNRiLipOBADEj442jAIAAA== Archived-At: Subject: Re: [sipcore] SIP PUSH X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 05:08:35 -0000 Hi, >> There is a real need for a solution in the market, and I know that=20 >> people are looking at a number of different proprietary solutions --=20 >> which can cause a real mess in the long run. Therefor I think it would=20 >> be VERY important to produce a standardised way of doing this. > > I know I'm being cranky about this, but MHO is that the market needs to b= e told -- loudly -- that what Apple has done is a Bad Idea. =20 > Yes, people will develop a variety of proprietary solutions, but that wil= l increase the cost and inconvenience of interoperating with=20 > Apple's mistaken architecture. The goal is to get Apple to abandon this = idea and implement something much closer to how Internet=20 > applications are supposed to work. Note that, while the Apples push service may be proprietary, IETF has publi= shed a web notification mechanism itself, so I assume it is ok for Internet= applications to use it... Regards, Christer From nobody Tue Sep 26 23:03:27 2017 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 5BAD0124B18 for ; Tue, 26 Sep 2017 23:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 pghIKd79Ar46 for ; Tue, 26 Sep 2017 23:03:24 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (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 304D9132055 for ; Tue, 26 Sep 2017 23:03:24 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id z73so15251362oia.2 for ; Tue, 26 Sep 2017 23:03:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HLPZXOkvj1oID1bE28VGb1zpFNB9SKhdSKdU+lbGl6A=; b=AA/GvN/dQMZX9D3MoR1YS7GoqOvW/AKUf1g8OpjCr+m4m7chxExdiFBl3ji3b0cPvX oqHHui7Pd+STVZK9aiP6B2hluwlfO3hAvkcmGjocPeYfUOtSTKUOVEvNbCmQwHbo2U7e 53xvyuD8stlyjPdeDoiUJJv5Q+D/xVo/1YdgIrVD+Oo1gxyT9T6hT+pZvx/KxyPDhizn Rkh6M/Mup58hXK/nIJOnJMwUOYw9MfGOnaozLnDzbGHPXPeU4fwDiY7tcUZURyGULH2U 1UY/GfBblgDle3LkytigbjsRhzkVwYsLccgpLjbJpIAKVWDjBGf2NQQ7k9z7Vmi50QpD VqWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HLPZXOkvj1oID1bE28VGb1zpFNB9SKhdSKdU+lbGl6A=; b=P2JG4SKFm9dBtBfQRkCA7l2oBV8oqijSKZG153FqCnh1ztkYyJAtIXbos+V4mAEjgJ aclq1Jm2csRoWQ8a5MQ+E5WQtQtXuLNtdPOyEbw357zrYZcoBCHRjhzmvTekKh8pOOFe pPF1JDAz7Ce+0kxHE6khaLgt9lHBUaX8Xhn08VstnVby1psKi3z2w4tY1EQrn6ju5Gm6 FKCgfxIdDX8KJY3TIDMj3g8w8gIMUTbEmoRDbw4sLGphYxFR95qPReALFgYEUyNmeQQ9 DLIrTjnNB2cvCa915huXg/6ab34LhtdLx1+lsDwv/dT6XyGC7QcgING2OsQ10XbsXMRT W69Q== X-Gm-Message-State: AMCzsaVZdpdU6Aa3bg20FN937gPYjW0cDZlpFTt4TpK1j6XoCaP1VJsl 2iKdcOu7q0YGhA/rCaXgwWW1jf8YbD4trAYzkMc= X-Google-Smtp-Source: AOwi7QAPk7orYbjMxcaK+xmgUTh2DdxlYSt/T2+Pyo4Fz4l3iw+Y6IPjDRX49Z6NHgea3Buf1TwVScu3361soyBbEQ0= X-Received: by 10.202.57.194 with SMTP id g185mr138266oia.390.1506492203598; Tue, 26 Sep 2017 23:03:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.0.38 with HTTP; Tue, 26 Sep 2017 23:03:22 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B562FE77B@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B562FE77B@ESESSMB109.ericsson.se> From: Martin Thomson Date: Wed, 27 Sep 2017 16:03:22 +1000 Message-ID: To: Christer Holmberg Cc: "sipcore@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [sipcore] SIP PUSH X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 06:03:25 -0000 On Wed, Sep 27, 2017 at 3:02 PM, Christer Holmberg wrote: > Why wouldn't you be able to use this with web push? The basics are almost right, but I think that you might want to consider draft-ietf-webpush-encryption. Having a pn-type is the bit that I didn't like. From nobody Tue Sep 26 23:56:40 2017 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 80760129A89 for ; Tue, 26 Sep 2017 23:56:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de header.b=QBuX/bhQ; dkim=pass (1024-bit key) header.d=telekom.onmicrosoft.de header.b=JQiJtjLU 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 nOgt5TTV4zQM for ; Tue, 26 Sep 2017 23:56:37 -0700 (PDT) Received: from MAILOUT21.telekom.de (MAILOUT21.telekom.de [80.149.113.251]) (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 C85AA1241F3 for ; Tue, 26 Sep 2017 23:56:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1506495397; x=1538031397; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=CoWEHNajquc/f+qivnp6yJEodIsl4ULE/+5T9HgWGrI=; b=QBuX/bhQj5R9or//4uSG8KX/qItdkCQYsEfRIKWYK7jJbUFeA/fj0IXY qOFfF8f0VHmfiqsDNo+QoWHMeyKomCkJfIWujSMb4xo8MPaCvUdk+thKZ ve7JSh3VwrI9WPq90bbkh9kdJ6DvEDJ6wNXWOsyY2Cm9cPghWqH2Wxvst wGNgMAvP+TDsKI+//H33ivbVTzHg4CA9hObv/NXQ9KkmcTnKQ/eqDjQ1H VPvvLc0Otu7t8hWYje6ZgMAIqztON18jI79/3DwnTN99G8ivyivDHznz9 eZKccpDQRGmVcjVX9Kz19bqMk3kZZ9Dj3H8OJqNF+0CB27f+uuSlDxH4+ A==; Received: from q4de8psa169.blf.telekom.de ([10.151.13.200]) by MAILOUT21.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Sep 2017 08:56:34 +0200 X-IronPort-AV: E=Sophos;i="5.42,443,1500933600"; d="scan'208";a="1393562321" Received: from he105651.emea1.cds.t-internal.com ([10.169.119.62]) by q4de8psazkj.blf.telekom.de with ESMTP/TLS/AES256-SHA; 27 Sep 2017 08:56:33 +0200 Received: from HE199744.EMEA1.cds.t-internal.com (10.169.119.52) by HE105651.emea1.cds.t-internal.com (10.169.119.62) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Wed, 27 Sep 2017 08:56:33 +0200 Received: from HE100181.emea1.cds.t-internal.com (10.171.40.15) by HE199744.EMEA1.cds.t-internal.com (10.169.119.52) with Microsoft SMTP Server (TLS) id 15.0.1293.2 via Frontend Transport; Wed, 27 Sep 2017 08:56:33 +0200 Received: from GER01-LEJ-obe.outbound.protection.outlook.de (51.5.80.22) by O365mail02.telekom.de (172.30.0.235) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Wed, 27 Sep 2017 08:56:02 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.onmicrosoft.de; s=selector1-telekom-onmicrosoft-de; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=CoWEHNajquc/f+qivnp6yJEodIsl4ULE/+5T9HgWGrI=; b=JQiJtjLUGpP3UV14A8x4UJ39RDijmjUKDXQVIuxlg6WhmLzZFytZm1qLPlbtvbsi0PCr0VpMjxOS4599LHa5Hhl3fupy1G1aWekwhNPrlw6B4HP6XxCY+EV9xk+lLlfgi3lJnOECvfAD1Fp0qbvH3IAlrLSOthNoKJRcuFfqS8I= Received: from FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE (10.158.133.13) by FRAPR01MB0484.DEUPRD01.PROD.OUTLOOK.DE (10.158.133.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.11; Wed, 27 Sep 2017 06:56:32 +0000 Received: from FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE ([fe80::d1:57a:9b07:65a0]) by FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE ([fe80::d1:57a:9b07:65a0%15]) with mapi id 15.20.0056.018; Wed, 27 Sep 2017 06:56:32 +0000 From: "Jesske, Roland" To: "Dale R. Worley" CC: "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-reason-q850-loc-00.txt Thread-Index: AQHTNym/Hwns9Rd+Q2ur3wDOZdznMqLITCFg Date: Wed, 27 Sep 2017 06:56:32 +0000 Message-ID: References: (R.Jesske@telekom.de) <87h8vp9di6.fsf@hobgoblin.ariadne.com> In-Reply-To: <87h8vp9di6.fsf@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=R.Jesske@telekom.de; x-originating-ip: [164.19.3.225] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; FRAPR01MB0484; 6:HNLx2fjKiLc90EAHDd+VMD4dAyv5yZVjMNRYLHKRnwUNZ0XrtVWuWw6Z7RRJ97WWVR6BmUHSv9/VlfQWqYxRpeKBvGq3f2tvYXE3+n6fyUzRZqy80MC8yZ/o7ebhZfFdv1AI/Cl3SEQLFtCJhEBX4eIer9KDGeHlJJRMp5aLTs2x7zda0KxSR8hGE4mYpo8GU9FIosljAs+p3vS7MvLhQd4f9pJymdZ+Teu4IXzEqyBRVz3oz/bNg0TbZs/2O0tcX8taN9NwPTgOjZofcj6MTmiKF+Fbi8qnA6Gfn/NyA8buwldnFvxn4VQOzRMwnWNjetgpby3ruwWR2ruxkPDnhQ==; 5:KyPlmfpBXOx7PcoKDOuMDof6wLHWJHRukjr0jHLfCZrXfnlIZfObhpuONfobo0twZBZefbIiYuoeboYtCcxwxT/3XfZJBfhSyyn9qU7hCeYI31rgfXk0fIhfgVxP5daNbGR2YIId8yHG0eAlF4PYsA==; 24:6KlmzsIn9zZJY7XrCqqMlL1Gh8rfTRKWwtes0VhGbuQM4nuA2TEVbBON1chXnhiKpP9PYPF34wNSEVmytXKjD+gbx/EQ8W3rhOTSZ1Wr3DA=; 7:H01cWdymmCtX4ZzIEW+CDZbkwFK9F3qPKBfVrhOGY8okA6lNcdlqqZDwnCXS/E8wSH+CmBXAy2H8YLZTV90PYcgFdqwKxKA4pfJrH1OuvHcrbgSm7sNQYhAUCrTksPGbM9UCL5x2OSFAvZDhZ0ObvET6lEHtnUR/cMCaSkogGR1ECXumYsfoKz3aHpx6NRPYbJd3MusK+mI8gmook4ShcAU/Fexl6Ok2nrA9Cy5+xtU= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: dd040009-6edc-4f56-c3cd-08d50574e2d6 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:FRAPR01MB0484; x-ms-traffictypediagnostic: FRAPR01MB0484: x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(100000703101)(100105400095)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123562025)(20161123560025)(20161123558100)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:FRAPR01MB0484; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:FRAPR01MB0484; x-forefront-prvs: 04433051BF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(346002)(199003)(189002)(7736002)(3280700002)(105586002)(81156014)(81166006)(106356001)(5250100002)(3846002)(8676002)(230783001)(50986999)(76176999)(102836003)(2900100001)(2906002)(478600001)(33656002)(5660300001)(6116002)(4326008)(54356999)(68736007)(8936002)(9686003)(3660700001)(53936002)(66066001)(305945005)(6916009)(7696004)(75402003)(101416001)(55016002)(72206003)(74482002)(86362001)(316002)(14454004)(2950100002)(189998001)(97736004); DIR:OUT; SFP:1101; SCL:1; SRVR:FRAPR01MB0484; H:FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: telekom.de does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Sep 2017 06:56:32.1926 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f X-MS-Exchange-Transport-CrossTenantHeadersStamped: FRAPR01MB0484 X-OriginatorOrg: telekom.de Archived-At: Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-reason-q850-loc-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 06:56:39 -0000 Hi Dale, I think in such a case the naming is not very important for interworking pu= rposes. I made a failure. The last 4 are reserved for national use. > > LOC-12 for 1 1 0 0 reserved for national use > > LOC-13 for 1 1 0 1 reserved for national use > > LOC-14 for 1 1 1 0 reserved for national use > > LOC-15 for 1 1 1 0 reserved for national use If nobody is against I will use the LOC values. Best Regards Roland > -----Urspr=FCngliche Nachricht----- > Von: Dale R. Worley [mailto:worley@ariadne.com] > Gesendet: Mittwoch, 27. September 2017 02:44 > An: Jesske, Roland > Cc: sipcore@ietf.org > Betreff: Re: [sipcore] I-D Action: draft-ietf-sipcore-reason-q850-loc-00.= txt >=20 > "Jesske, Roland" writes: > > for me it is no problem to go with that approach. > > So I will add an table within the draft the looks like: > > > > The following values shall be used as location: > > U for 0 0 0 0 user > > LPN for 0 0 0 1 private network serving the local user > > LN for 0 0 1 0 public network serving the local user > > TN for 0 0 1 1 transit network > > RLN for 0 1 0 0 public network serving the remote user > > RPN for 0 1 0 1 private network serving the remote user > > LOC-6 for 0 1 1 0 Spare > > INTL for 0 1 1 1 international network > > LOC-8 for 1 0 0 0 Spare > > LOC-9 for 1 0 0 1 Spare > > BI for 1 0 1 0 network beyond interworking point > > LOC-11 for 1 0 1 1 Spare >=20 > I don't want to push for this approach too hard -- if the ITU-T > recommendations have any sort of names for these values, I would favor > those. But if there are no pre-existing names or designations, naming th= em > after the bit combinations seems the easiest to understand. >=20 > Dale From nobody Wed Sep 27 00:04:13 2017 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 822A6129A89 for ; Wed, 27 Sep 2017 00:04:11 -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 gaFLjShGRZeT for ; Wed, 27 Sep 2017 00:04:10 -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 1842F126BF0 for ; Wed, 27 Sep 2017 00:04:09 -0700 (PDT) X-AuditID: c1b4fb2d-a4dff700000019be-f2-59cb4d678623 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id CB.7B.06590.76D4BC95; Wed, 27 Sep 2017 09:04:07 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.6]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0352.000; Wed, 27 Sep 2017 09:04:07 +0200 From: Christer Holmberg To: Martin Thomson CC: "sipcore@ietf.org" Thread-Topic: [sipcore] SIP PUSH Thread-Index: AQHTNfOMhpjgVdXGfkOKwB3589Ama6LHy2UAgABkNQD//++dAIAARLqA Date: Wed, 27 Sep 2017 07:04:06 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B562FE77B@ESESSMB109.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrAIsWRmVeSWpSXmKPExsUyM2K7n2667+lIg79nNS2unfnHaPH1xyY2 ByaPnbPusnssWfKTKYApissmJTUnsyy1SN8ugStj58JL7AXt7BUrPj1mbmC8wNrFyMkhIWAi ca37GksXIxeHkMARRol7k3+zQTiLGCXaZ34BynBwsAlYSHT/0wZpEBHQlVh09gE7iM0soCnx aOdeJhBbWEBe4sHMxUwQNQoSyzrnsUHYbhJfdrwFq2cRUJW4t+goG8hIXgFriV//mSFW9TJJ TDh6GayXUyBQ4tmFWWDHMQqISXw/tYYJYpe4xK0n85kgjhaQWLLnPDOELSrx8vE/sHpRAT2J DSdus0PEFSWuTl8O1asncWPqFDYI21qi4eQ1KFtbYtnC12BzeAUEJU7OfMIygVF8FpJ1s5C0 z0LSPgtJ+ywk7QsYWVcxihanFhfnphsZ66UWZSYXF+fn6eWllmxiBMbbwS2/dXcwrn7teIhR gINRiYfX0uZ0pBBrYllxZe4hRgkOZiUR3kXuQCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8Dvsu RAgJpCeWpGanphakFsFkmTg4pRoYF19dov3rYtDfc5ecA/fXc3ydsaXsQtCNeSvX2xd9NFi1 NGuaWeYXs1P/TYSPxa4OPZ/UVVxjVty5wjGYK4+1W3hq7PzSHd1m8Tnqdd2ivSfWP/11Ssuw gHe+mL/patn5L672n+Dh2PV9qqrRhFL2BGfRyOn2yen3ZObt9OP/Y1XAeYDz8+9aJZbijERD Leai4kQAnM08crMCAAA= Archived-At: Subject: Re: [sipcore] SIP PUSH X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 07:04:11 -0000 Hi Martin, >>Why wouldn't you be able to use this with web push? > >The basics are almost right, but I think that you might want to >consider draft-ietf-webpush-encryption. Having a pn-type is the bit >that I didn't like. pn-type is only an identifier used to inform which push service is used. But, if the information can be retrieved from elsewhere, e.g., from pn-uri, then pn-type may not be needed. Regarding draft-ietf-webpush-encryption, I see no reason to prevent it. If we need some additional parameter(s) to support it we can add it to the draft. But, I understand the information can also be included in the subscription URI (pn-uri). Note, though, that the SIP push proposal doesn=B9t mandate any payload in the push message. The proposal only uses the push service to wake up the application - the data is still sent in the SIP request. Regards, Christer From nobody Wed Sep 27 04:20:04 2017 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 21E37132D54 for ; Wed, 27 Sep 2017 04:20:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 8zDyRpjbcDdW for ; Wed, 27 Sep 2017 04:20:00 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (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 7A47C1320C9 for ; Wed, 27 Sep 2017 04:20:00 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id p187so2651682oif.4 for ; Wed, 27 Sep 2017 04:20:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=iLkkfN6meuJaDoiS1DAUPnOGaIGf2k2Su9d+c/+xnFU=; b=SLiAOY0Y6VoCvvKsmwR802kXwjprD38ob4lHgDI39QI+OXgN3XiGHl6trJ3z/5Z5tq q2Fe2K21pdXe0RLu4SREWi8SVLRoscrlx3aZb7+/2pORTWLMSulgkjp71DqY5bEqPmj4 DMMovzdTlVnbvWsMIssTVWAbCGjsQstSrjvtp2vWQTlaRxNITpsTat3S0GeDtrJob2vG gmZG2Azn4LO3QSz+f/4z0LGANZLlqkzezGIQw8xtsKl1g/QyYmIt7XblROMVr+LMTSSX eiRALjO5Lw2dTS0DpYTcBOYMufbI1LTcFkIaYEgQFpTcQTgGkwJCjlBpD5KrDvZHuM9p 22cA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=iLkkfN6meuJaDoiS1DAUPnOGaIGf2k2Su9d+c/+xnFU=; b=Fuwnr6VjY6VWN0gy6aYTwEjuuJsVTF7R011+rVHKyvHGuQBiJPAya40CycVFJfNTuX rlk2nG7ycKSSnKiA5KjUus9xy7PMG24LgyaNLlZgDqr3eDtnSg5PIWL4ywFeKz8YcP5P rwElPlJDgaLHYsD4CVk2TVOglVeAxnBn1MNT1EClxTMF0suDA2fWTdkZHecwd8XxMe8p UtHQug/OdkCterbGqvSlHsFVBjfEn1pIOL+Sg4Y+GkdDdVXlAjnr/II/gAUp/3xQOcRV +5RWmLFZognxQtGNIlZSWUS4hEEeQ3Mv+Cg/BBQunX1+SMpaWSn0NhqBjzwkm/TLLAfk 1iHA== X-Gm-Message-State: AHPjjUgOsRZKMlSq2WvRve9DiB7CwFHSJNIZ+/eIdU3cBG6Rmy3kpCeb 8vmOcWanS5YYrk2coteyKz3E6Fd4YS2rYnmFxNU= X-Google-Smtp-Source: AOwi7QDhIpsxqPAylrSfddOE6iEGdUP4SFrSPeu3BIlAQ3tXXhjI2bngaLDLbpGDhch3ZVEQi+HIHprG4iSMXdZUb8w= X-Received: by 10.157.84.47 with SMTP id j47mr655463oth.44.1506511199804; Wed, 27 Sep 2017 04:19:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.0.38 with HTTP; Wed, 27 Sep 2017 04:19:59 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B562FE77B@ESESSMB109.ericsson.se> From: Martin Thomson Date: Wed, 27 Sep 2017 21:19:59 +1000 Message-ID: To: Christer Holmberg Cc: "sipcore@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [sipcore] SIP PUSH X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 11:20:02 -0000 On Wed, Sep 27, 2017 at 5:04 PM, Christer Holmberg wrote: > Hi Martin, > >>>Why wouldn't you be able to use this with web push? >> >>The basics are almost right, but I think that you might want to >>consider draft-ietf-webpush-encryption. Having a pn-type is the bit >>that I didn't like. > > pn-type is only an identifier used to inform which push service is used. > But, if the information can be retrieved from elsewhere, e.g., from > pn-uri, then pn-type may not be needed. I don't see a use for it. Assuming that you use RFC 8030 that is. > Regarding draft-ietf-webpush-encryption, I see no reason to prevent it. I= f > we need some additional parameter(s) to support it we can add it to the > draft. But, I understand the information can also be included in the > subscription URI (pn-uri). It cannot. The URI is sent to the push service and the encryption parameters contain information that needs to be kept from the push service. > Note, though, that the SIP push proposal doesn=C2=B9t mandate any payload= in > the push message. The proposal only uses the push service to wake up the > application - the data is still sent in the SIP request. That is not at all clear from the draft. It seems like you could send the message in the push message, but those are typically space constrained and INVITES are rarely small, so a wakeup prod is probably the best and easiest solution. From nobody Wed Sep 27 05:17:35 2017 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 1F7F6134B03 for ; Wed, 27 Sep 2017 05:17:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 Oq6YcAcyde4r for ; Wed, 27 Sep 2017 05:17:27 -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 49CB7134A09 for ; Wed, 27 Sep 2017 05:13:17 -0700 (PDT) X-AuditID: c1b4fb25-967ff70000005333-b8-59cb95dbb221 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 52.7F.21299.BD59BC95; Wed, 27 Sep 2017 14:13:15 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.6]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0352.000; Wed, 27 Sep 2017 14:13:14 +0200 From: Christer Holmberg To: Martin Thomson CC: "sipcore@ietf.org" Thread-Topic: [sipcore] SIP PUSH Thread-Index: AQHTNfOMhpjgVdXGfkOKwB3589Ama6LHy2UAgABkNQD//++dAIAARLqAgAATvICAAELGAA== Date: Wed, 27 Sep 2017 12:13:14 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B562FE77B@ESESSMB109.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.146] Content-Type: multipart/alternative; boundary="_000_D5F16BF122BC6christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrLIsWRmVeSWpSXmKPExsUyM2K7ge7tqacjDdaeULS4duYfo8XXH5vY HJg8ds66y+6xZMlPpgCmKC6blNSczLLUIn27BK6MW1P/sRWc8KiY2XGKpYFxkk0XIyeHhICJ xOcX/WxdjFwcQgJHGCVevprDDOEsYpRYeK2XqYuRg4NNwEKi+582SIOIgK7EorMP2EFsZgFN iUc79zKB2MIC8hIPZi5mgqhRkFjWOY8Nwg6TmN60kwXEZhFQlfjfsocVxOYVsJbo3/udHWJX G7NE++K/YA2cAoESV/YdZQSxGQXEJL6fWsMEsUxc4taT+UwQVwtILNlznhnCFpV4+fgf2FBR AT2JDSdus0PElSR+bLjEAtGbILGpbwEjxGJBiZMzn7BMYBSdhWTsLCRls5CUQcQNJN6fm88M YWtLLFv4GsrWl9j45SwjhG0t8afrISuymgWMHKsYRYtTi5Ny042M9VKLMpOLi/Pz9PJSSzYx AiPx4JbfqjsYL79xPMQowMGoxMPLM+V0pBBrYllxZe4hRgkOZiUR3opOoBBvSmJlVWpRfnxR aU5q8SFGaQ4WJXFex30XIoQE0hNLUrNTUwtSi2CyTBycUg2M/O0nOpuO2267wxf8+5lc9JWV Asf+aK880Xgqf0ngE0bRPX1RYlvyTl6y/HkliOd88oMkbkWWZ84BZ8WzbTxSa/z3B4acecSi r1rwSGsq26a74v0BDtJvDG+IT1vBvPrJhqW3V/ZofXHfw5ETMqfssezXV2G2Fj9bFvFP/BGr se38VxnJ24nLlFiKMxINtZiLihMBEXAdSMACAAA= Archived-At: Subject: Re: [sipcore] SIP PUSH X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 12:17:34 -0000 --_000_D5F16BF122BC6christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, Why wouldn't you be able to use this with web push? The basics are almost right, but I think that you might want to consider draft-ietf-webpush-encryption. Having a pn-type is the bit that I didn't like. pn-type is only an identifier used to inform which push service is used. But, if the information can be retrieved from elsewhere, e.g., from pn-uri, then pn-type may not be needed. I don't see a use for it. Assuming that you use RFC 8030 that is. Well, Apple doesn=92t use RFC 8030 (AFAIK), but it seems like their URIs al= so contain =93apple.com=94, or something similar. But, as URIs may change over time, I thought that a =93static=94 pn-type wo= uld be useful. It would be optional. And, if only one push service is used = to begin with, it could be configured in the proxy sending the push message= s. Regarding draft-ietf-webpush-encryption, I see no reason to prevent it. If we need some additional parameter(s) to support it we can add it to the draft. But, I understand the information can also be included in the subscription URI (pn-uri). It cannot. The URI is sent to the push service and the encryption parameters contain information that needs to be kept from the push service. I assume the application would have to remove the information before using = the URI. draft-ietf-webpush-encryption does say: "2.1. Key and Secret Distribution The application using the subscription distributes the subscription public key and authentication secret to an authorized application server. This could be sent along with other subscription information that is provided by the user agent, such as the push subscription URI." But, again, we can add pn- parameters for distributing the information. I g= uess we could have something like pn-enckey and pn-encsec. Note, though, that the SIP push proposal doesn=B9t mandate any payload in the push message. The proposal only uses the push service to wake up the application - the data is still sent in the SIP request. That is not at all clear from the draft. I agree. Some other changes/additions are also needed. I wanted to give the original= author of the draft a chance to do it, but I haven=92t been able to contac= t him. So, if I don=92t hear from him, the idea would be that I submit my o= wn version of the draft. It seems like you could send the message in the push message, but those are typically space constrained and INVITES are rarely small, so a wakeup prod is probably the best and easiest solution. Correct. I have heard ideas where the INVITE request would be sent in the push messa= ge, and the associated responses would then be sent using SIP transport =96= which means that proxies could receive responses to requests they are not = aware of. Really ugly. One of the reason I think it would be important for us to standardise a mec= hanism is to (hopefully) discourage people from doing such kind of hacks, w= ithout any kind of interoperability. Regards, Christer --_000_D5F16BF122BC6christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <6FEEEBA6A3416448A025A3A79241D3F5@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

Why wouldn't you be able to use this with web push?

The basics are almost right, but I think that you might want to
consider draft-ietf-webpush-encryption.  Having a pn-type is= the bit
that I didn't like.

pn-type is only an identifier used to inform which push service is use= d.
But, if the information can be retrieved from elsewhere, e.g., from
pn-uri, then pn-type may not be needed.

I don't see a use for it.  Assuming that you use RFC 8030 th= at is.

Well, Apple doesn=92t use RFC 8030 (AFAIK), but it seems like their UR= Is also contain =93apple.com=94, or something similar.

But, as URIs may change over time, I thought that a =93static=94 pn-ty= pe would be useful. It would be optional. And, if only one push service is = used to begin with, it could be configured in the proxy sending the push me= ssages.


Regarding draft-ietf-webpush-encryption, I see no reason to prevent it= . If
we need some additional parameter(s) to support it we can add it to th= e
draft. But, I understand the information can also be included in the
subscription URI (pn-uri).

It cannot.  The URI is sent to the push service and the encr= yption
parameters contain information that needs to be kept from the push
service.

I assume the application would have to remove the information before u= sing the URI.

draft-ietf-webpush-encryption does say:

"2.1. Key and Secret Distribution

   The application using the subscription distributes the su= bscription
   public key and authentication secret to an authorized app= lication
   server. This could be sent along with other subscription = information
   that is provided by the user agent, such as the push s= ubscription
   URI."

But, again, we can add pn- parameters for distributing the information= . I guess we could have something like pn-enckey and pn-encsec.

Note, though, that the SIP push proposal doesn=B9t mandate any payload= in
the push message. The proposal only uses the push service to wake up t= he
application - the data is still sent in the SIP request.

That is not at all clear from the draft.  

I agree. 

Some other changes/additions are also needed. I wanted to give the ori= ginal author of the draft a chance to do it, but I haven=92t been able to c= ontact him. So, if I don=92t hear from him, the idea would be that I submit= my own version of the draft. 

It seems like you could send
the message in the push message, but those are typically space
constrained and INVITES are rarely small, so a wakeup prod is probably=
the best and easiest solution.

Correct. 

I have heard ideas where the INVITE request would be sent in the push = message, and the associated responses would then be sent using SIP transpor= t =96 which means that proxies could receive responses to requests they are= not aware of. Really ugly.

One of the reason I think it would be important for us to standardise = a mechanism is to (hopefully) discourage people from doing such kind of hac= ks, without any kind of interoperability.

Regards,

Christer

--_000_D5F16BF122BC6christerholmbergericssoncom_-- From nobody Wed Sep 27 15:31:01 2017 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 A6A341344AC; Wed, 27 Sep 2017 15:30:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sipcore@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.62.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150655145363.13772.14475426051879251657@ietfa.amsl.com> Date: Wed, 27 Sep 2017 15:30:53 -0700 Archived-At: Subject: [sipcore] I-D Action: draft-ietf-sipcore-originating-cdiv-parameter-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 22:30:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core WG of the IETF. Title : A P-Served-User Header Field Parameter for Originating CDIV session case in Session Initiation Protocol (SIP) Author : Marianne Mohali Filename : draft-ietf-sipcore-originating-cdiv-parameter-01.txt Pages : 13 Date : 2017-09-27 Abstract: This specification defines a new parameter of the P-Served-User header field in the Session Initiation Protocol (SIP). This new "orig-cdiv" parameter defines the session case used by a proxy when handling an originating session after Call Diversion (CDIV) services has been invoked for the served user. The P-Served-User header field is defined in RFC5502 to convey the identity of the served user and the session case that applies to this particular communication session and application invocation. This document updates RFC5502 to add the "originating after CDIV" session case and to provide more guidance for using the P-Served-User header field in IP networks that were missing in RFC5502. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-originating-cdiv-parameter/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sipcore-originating-cdiv-parameter-01 https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-originating-cdiv-parameter-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-originating-cdiv-parameter-01 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Sep 27 15:42:18 2017 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 7F3FC135152; Wed, 27 Sep 2017 15:42:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 RSVOwVlxOC78; Wed, 27 Sep 2017 15:42:16 -0700 (PDT) Received: from relais-inet.orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D749E1344AC; Wed, 27 Sep 2017 15:42:15 -0700 (PDT) Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id 2AB4F403F0; Thu, 28 Sep 2017 00:42:14 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.18]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id 133871C007D; Thu, 28 Sep 2017 00:42:14 +0200 (CEST) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM34.corporate.adroot.infra.ftgroup ([fe80::cba:56d0:a732:ef5a%19]) with mapi id 14.03.0361.001; Thu, 28 Sep 2017 00:42:13 +0200 From: To: "sipcore@ietf.org" , "sipcore-chairs@ietf.org" Thread-Topic: New version of draft-ietf-sipcore-originating-cdiv-parameter Thread-Index: AdM34N3+9AFoKjszRAuzrboUvBG86A== Date: Wed, 27 Sep 2017 22:42:13 +0000 Message-ID: <13529_1506552134_59CC2946_13529_466_1_8B970F90C584EA4E97D5BAAC9172DBB81D60CE6E@OPEXCLILMA4.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [sipcore] New version of draft-ietf-sipcore-originating-cdiv-parameter X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 22:42:17 -0000 Hi, Here is the -01 version of the working group document draft-ietf-sipcore-or= iginating-cdiv-parameter. In this version I have splitted the introduction section into the normal us= e case (as defined in RFC5502) and the problem statement by which it has be= en decided to propose an extension of the P-Served-User header. Call Flows section has also been added to illustrate usage of the new propo= sed session case. Review and comments are welcome. Best regards, Marianne The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-originating-cdiv-parame= ter/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sipcore-originating-cdiv-parameter-01 https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-originating-cdiv-p= arameter-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipcore-originating-cdiv-par= ameter-01 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Wed Sep 27 18:53:53 2017 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 0F26113523E for ; Wed, 27 Sep 2017 18:53:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.933 X-Spam-Level: X-Spam-Status: No, score=-1.933 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, URIBL_BLOCKED=0.001] 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 IeqwJ0ODKL-Y for ; Wed, 27 Sep 2017 18:53:51 -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 02C8813523D for ; Wed, 27 Sep 2017 18:53:50 -0700 (PDT) Received: from resomta-ch2-01v.sys.comcast.net ([69.252.207.97]) by resqmta-ch2-12v.sys.comcast.net with ESMTP id xO1NdqM0PDLUTxO1Nd5pye; Thu, 28 Sep 2017 01:53:49 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-01v.sys.comcast.net with SMTP id xO1LddvKoqsElxO1MdE4sv; Thu, 28 Sep 2017 01:53:49 +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 v8S1rlU0030533; Wed, 27 Sep 2017 21:53:47 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v8S1rkar030530; Wed, 27 Sep 2017 21:53:46 -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: worley@ariadne.com (Dale R. Worley) Cc: R.Jesske@telekom.de, sipcore@ietf.org In-Reply-To: <87h8vp9di6.fsf@hobgoblin.ariadne.com> (worley@ariadne.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 27 Sep 2017 21:53:46 -0400 Message-ID: <87r2ur8u6t.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfN5kPB5/MfB9/ffju1/PPMFq9vYFyfG84/n+bxWaiCMyv2Khf43EVTFv7D7D8WlNpW/tnfJhjAHzmHw8YWtr6QMioOJkkYg9qBedk1O4bTXT1sBXX26o icFfCIQIAGyR991Y8ZYIoH+oDozOoDqKYZq+oz4KJVFh4kVuQYxLqtS0t3IbRFwTzTrGX/GBsh1TNbzBii1/rjtCDrDdlP/whVfiuQ3ObFmdMkWxtMIhMxZ0 Archived-At: Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-reason-q850-loc-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 01:53:52 -0000 worley@ariadne.com (Dale R. Worley) writes: > I don't want to push for this approach too hard -- if the ITU-T > recommendations have any sort of names for these values, I would favor > those. But if there are no pre-existing names or designations, naming > them after the bit combinations seems the easiest to understand. My fault -- I forgot that I have a copy of Q.850 and can look up ITU-T's description/names for the location codes (clause 2.2.3). And while ITU-T does label codes 1100 through 1111 "reserved for national use", it does not provide distinguished names for them, not even "reserved for national use 1", "reserved for national use 2", etc. Dale From nobody Fri Sep 29 01:52:04 2017 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 A7A2C126D0C; Fri, 29 Sep 2017 01:51:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sipcore@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150667511763.14067.17235300359095515956@ietfa.amsl.com> Date: Fri, 29 Sep 2017 01:51:57 -0700 Archived-At: Subject: [sipcore] I-D Action: draft-ietf-sipcore-reason-q850-loc-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Sep 2017 08:51:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core WG of the IETF. Title : ISUP Cause Location Parameter for the SIP Reason Header Field Author : Roland Jesske Filename : draft-ietf-sipcore-reason-q850-loc-01.txt Pages : 6 Date : 2017-09-29 Abstract: The SIP Reason header field is defined for carrying ISUP cause values as well as SIP response codes. Some services in SIP networks may need to know the ISUP location where the call was released in the PSTN network to correctly interpret the reason of release. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-reason-q850-loc/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sipcore-reason-q850-loc-01 https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-reason-q850-loc-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-reason-q850-loc-01 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Sep 29 02:45:02 2017 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 852BA126D0C for ; Fri, 29 Sep 2017 02:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de header.b=4aq69Eu6; dkim=pass (1024-bit key) header.d=telekom.onmicrosoft.de header.b=RFFDcrzw 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 HjhSlfy1Dn84 for ; Fri, 29 Sep 2017 02:44:57 -0700 (PDT) Received: from mailout24.telekom.de (MAILOUT24.telekom.de [80.149.113.254]) (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 D72501241F3 for ; Fri, 29 Sep 2017 02:44:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1506678297; x=1538214297; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=BbjSuylStdYiY9h4g4TCK2KWh7xGtejSU9NZq5vq2Ik=; b=4aq69Eu6QMfo2CG4GYVeeUDdLMI2F3J2r9mSqkYRHAwNZwbeC+2ZCcEr 2tbXLZoPuA+MBHJ084yA8DkZjrAcOI/+kpeqtUHvjbWvGGbYAK/ODLPR2 8DEh8+EjJV4JvesD6+RH03F8au5ZO2V25K0xxD1UhUnECANk5efhYOi61 jehBSg5Qwq+TXE8kHoXSY/5DoZh2sJU1nPlJLCzoBiFQ5bcyCFbamLK15 bc1NyOqpCaaJI1s4GqASjGvcmIGVq/c16wEbKg7+kp8+ZyAnAwaRlTIk3 yCsJJQkzL7YcuiLY5MOljnZd/o9TARn2GkV5eN9jQQgLVpUsRsmMTKfss w==; Received: from qdec94.de.t-internal.com ([10.171.255.41]) by MAILOUT21.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Sep 2017 11:44:54 +0200 X-IronPort-AV: E=Sophos;i="5.42,452,1500933600"; d="scan'208";a="42339087" Received: from he101942.emea1.cds.t-internal.com ([10.169.119.82]) by QDEC97.de.t-internal.com with ESMTP/TLS/AES256-SHA; 29 Sep 2017 11:44:54 +0200 Received: from HE105704.EMEA1.cds.t-internal.com (10.169.119.21) by HE101942.emea1.cds.t-internal.com (10.169.119.82) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Fri, 29 Sep 2017 11:44:53 +0200 Received: from HE100181.emea1.cds.t-internal.com (10.171.40.15) by HE105704.EMEA1.cds.t-internal.com (10.169.119.21) with Microsoft SMTP Server (TLS) id 15.0.1293.2 via Frontend Transport; Fri, 29 Sep 2017 11:44:53 +0200 Received: from GER01-FRA-obe.outbound.protection.outlook.de (51.4.80.21) by O365mail02.telekom.de (172.30.0.235) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Fri, 29 Sep 2017 11:44:22 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.onmicrosoft.de; s=selector1-telekom-onmicrosoft-de; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=BbjSuylStdYiY9h4g4TCK2KWh7xGtejSU9NZq5vq2Ik=; b=RFFDcrzw/jV3lb49v9cQHVY73o1M6W25AipKScm/840zcmNf1O4xJSoN9A5CarVQra5NaIl8oFS0eSDMvPOGkyO2T3AwGUVBzXpWdbhKZuOOAn9Guh3W0muSILsxoDQB3OaRnbmpr1pB39YHIGQgZk3/Vk96p0dY3pRdGmbEDzE= Received: from FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE (10.158.133.13) by FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE (10.158.133.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.11; Fri, 29 Sep 2017 09:44:53 +0000 Received: from FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE ([fe80::d1:57a:9b07:65a0]) by FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE ([fe80::d1:57a:9b07:65a0%15]) with mapi id 15.20.0056.018; Fri, 29 Sep 2017 09:44:52 +0000 From: "Jesske, Roland" To: "sipcore@ietf.org" Thread-Topic: New Version Notification for draft-ietf-sipcore-reason-q850-loc-01.txt Thread-Index: AQHTOQA8WQRRnXbkGECh1ST5hShfq6LLmGYA Date: Fri, 29 Sep 2017 09:44:52 +0000 Message-ID: References: <150667511780.14067.5559536080355041849.idtracker@ietfa.amsl.com> In-Reply-To: <150667511780.14067.5559536080355041849.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=R.Jesske@telekom.de; x-originating-ip: [164.19.3.239] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; FRAPR01MB0483; 6:H19O/ROHNWFHDhoCU+VwhMa6vWqe14XPhu9wmf71gh3zOgpbZKNweRR3N7SMtIYoTrzZfZsgoCz/KPDVQaugIqmeJgYDJeI1kVZk61k8yGidPSai/enpun6plklWlyIY4kaHkVdhy/wWzmbFKCAXRzb/ci4IOv0SuYwH4W2ir9RwBEFKfSHbniZOnHB8RW/VLHmqcX13zVQjqxm8CcsmNNz5WJd3x5irU/gm7yQRrlNGCdOX00UJpRPzgsDGq9SEXmfC7zkIuqN+SMBcbeaSPsNYvQkInwbbjtJhYlTBG7SfvzOji4fdYgXrbu2hZhqrpKXi/25+6inzS/oTIw+UWw==; 5:uYce8T9nHexCh1XWgCTYZBlf0nindPztf3fMShBltebKj1GsEQxL/pjZJlKf5FEf2E545RQ3DVKfwnqtTsOUzJ1N1swrBIQ8v4tLHun9N+zE1s8uF1+5i1aRL5JW8ToKkAkIqqzd25T3elUN8fIZtA==; 24:SISxbTG/eP1d8N14/1xL+wVqasP3lVew/CGaI3vlxxnEixi6JTnTHp/IXhf8Zz73dK5/ihxz7uYEpRc13VbCUDunuf6fKGB5w7/cyOkr1x8=; 7:sJz9cRw03x5nhc4s+pGR1SiTFsFaAUqneCVnnxYM6yiHbdfTeqFnn81wm6D/hnCCH8VcjK1uN0yqtvGV5yjmioz/7gikItbvdNfpR+8IkgzqNS5mY1fZihdkleGUd/Bn3Sq4oO4q0EVvAgClPf94Mpsng4Ig1sSJFNOxwvyGd4b86Wl6J2qQR+TuTRBCDu2zfSSQzH6UINyuiLN+kD8bpX1I9HKiJCQXwaiwWttKT2c= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: ca3fe62e-9649-4b01-6618-08d5071ebc26 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:FRAPR01MB0483; x-ms-traffictypediagnostic: FRAPR01MB0483: x-exchange-antispam-report-test: UriScan:(120809045254105); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6041248)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123558100)(20161123560025)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:FRAPR01MB0483; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:FRAPR01MB0483; x-forefront-prvs: 0445A82F82 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(189002)(199003)(377424004)(2900100001)(54356999)(76176999)(106356001)(3660700001)(74482002)(2906002)(6306002)(5250100002)(55016002)(2351001)(101416001)(305945005)(2950100002)(189998001)(7736002)(72206003)(3280700002)(14454004)(97736004)(5640700003)(6916009)(50986999)(5660300001)(68736007)(7696004)(316002)(66066001)(75402003)(2501003)(33656002)(478600001)(230783001)(15650500001)(105586002)(8936002)(8676002)(53936002)(81156014)(86362001)(6116002)(3846002)(102836003)(966005)(9686003)(1730700003)(81166006); DIR:OUT; SFP:1101; SCL:1; SRVR:FRAPR01MB0483; H:FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: telekom.de does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Sep 2017 09:44:52.8745 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f X-MS-Exchange-Transport-CrossTenantHeadersStamped: FRAPR01MB0483 X-OriginatorOrg: telekom.de Archived-At: Subject: [sipcore] WG: New Version Notification for draft-ietf-sipcore-reason-q850-loc-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Sep 2017 09:45:00 -0000 SGksDQpub3cgSSBoYXZlIHVwbG9hZGVkIGEgbmV3IGRyYWZ0IHJlZmxlY3RpbmcgdGhlIGRpc2N1 c3Npb25zIHNvIGZhci4NClNvIGN1cnJlbnRseSBJIGhhdmUgdGFrZW4gdGhlIGdlbmVyYWwgYXBw cm9hY2ggdXNpbmcgdGhlIExPQy14eCBmb3IgYWxsIG1pc3NpbmcgdmFsdWVzLg0KSSBoYXZlIG5v dCBzdHJvbmcgb3BpbmlvbiBvbiBpdC4gU28gaWYgcGVvcGxlIHdvdWxkIGxpa2UgdG8gc2VlIGFu IGRpZmZlcmVudGlhdGlvbiBvbiB0aGUgIlNwYXJlIiBhbmQgIiByZXNlcnZlZCBmb3IgbmF0aW9u YWwgdXNlIg0KDQpTaW5jZSBJIGhhdmUgbm8gcmVhbCBwcmVmZXJlbmNlIEkgY2FuIGxpdmUgd2l0 aCBib3RoIGFwcHJvYWNoZXMuIFNvIGlmIG5vYm9keSB3b3VsZCBsaWtlIHRvIHNlZSBzb21ldGhp bmcgb3RoZXIgdGhhbiBJIGtlZXAgdGhlIGN1cnJlbnQgYXBwcm9hY2guDQoNCkJlc3QgUmVnYXJk cw0KDQpSb2xhbmQNCg0KLS0tLS1VcnNwcsO8bmdsaWNoZSBOYWNocmljaHQtLS0tLQ0KVm9uOiBp bnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmdd IA0KR2VzZW5kZXQ6IEZyZWl0YWcsIDI5LiBTZXB0ZW1iZXIgMjAxNyAxMDo1Mg0KQW46IEplc3Nr ZSwgUm9sYW5kIDxSLkplc3NrZUB0ZWxla29tLmRlPg0KQmV0cmVmZjogTmV3IFZlcnNpb24gTm90 aWZpY2F0aW9uIGZvciBkcmFmdC1pZXRmLXNpcGNvcmUtcmVhc29uLXE4NTAtbG9jLTAxLnR4dA0K DQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1pZXRmLXNpcGNvcmUtcmVhc29uLXE4NTAt bG9jLTAxLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBSb2xhbmQgSmVz c2tlIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0LWll dGYtc2lwY29yZS1yZWFzb24tcTg1MC1sb2MNClJldmlzaW9uOgkwMQ0KVGl0bGU6CQlJU1VQIENh dXNlIExvY2F0aW9uIFBhcmFtZXRlciBmb3IgdGhlIFNJUCBSZWFzb24gSGVhZGVyIEZpZWxkDQpE b2N1bWVudCBkYXRlOgkyMDE3LTA5LTI5DQpHcm91cDoJCXNpcGNvcmUNClBhZ2VzOgkJNg0KVVJM OiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1p ZXRmLXNpcGNvcmUtcmVhc29uLXE4NTAtbG9jLTAxLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtc2lwY29yZS1yZWFzb24tcTg1 MC1sb2MvDQpIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtc2lwY29yZS1yZWFzb24tcTg1MC1sb2MtMDENCkh0bWxpemVkOiAgICAgICBodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtc2lwY29yZS1yZWFzb24t cTg1MC1sb2MtMDENCkRpZmY6ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZm P3VybDI9ZHJhZnQtaWV0Zi1zaXBjb3JlLXJlYXNvbi1xODUwLWxvYy0wMQ0KDQpBYnN0cmFjdDoN CiAgIFRoZSBTSVAgUmVhc29uIGhlYWRlciBmaWVsZCBpcyBkZWZpbmVkIGZvciBjYXJyeWluZyBJ U1VQIGNhdXNlIHZhbHVlcw0KICAgYXMgd2VsbCBhcyBTSVAgcmVzcG9uc2UgY29kZXMuICBTb21l IHNlcnZpY2VzIGluIFNJUCBuZXR3b3JrcyBtYXkNCiAgIG5lZWQgdG8ga25vdyB0aGUgSVNVUCBs b2NhdGlvbiB3aGVyZSB0aGUgY2FsbCB3YXMgcmVsZWFzZWQgaW4gdGhlDQogICBQU1ROIG5ldHdv cmsgdG8gY29ycmVjdGx5IGludGVycHJldCB0aGUgcmVhc29uIG9mIHJlbGVhc2UuDQoNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEg Y291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBo dG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcu DQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From nobody Fri Sep 29 07:47:59 2017 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 8FA49132944 for ; Fri, 29 Sep 2017 07:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 4qOURqRfTUkI for ; Fri, 29 Sep 2017 07:47:57 -0700 (PDT) Received: from alum-mailsec-scanner-7.mit.edu (alum-mailsec-scanner-7.mit.edu [18.7.68.19]) by ietfa.amsl.com (Postfix) with ESMTP id 0AFF61320DC for ; Fri, 29 Sep 2017 07:47:56 -0700 (PDT) X-AuditID: 12074413-38bff70000007929-22-59ce5d1b517f Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 18.7B.31017.B1D5EC95; Fri, 29 Sep 2017 10:47:55 -0400 (EDT) Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id v8TElsgE011292 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Fri, 29 Sep 2017 10:47:55 -0400 To: sipcore@ietf.org References: <150667511763.14067.17235300359095515956@ietfa.amsl.com> From: Paul Kyzivat Message-ID: <2673fa78-e7d6-e5ce-2e42-637cf441eefc@alum.mit.edu> Date: Fri, 29 Sep 2017 10:47:54 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <150667511763.14067.17235300359095515956@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPIsWRmVeSWpSXmKPExsUixO6iqCsTey7SoP0ns8XXH5vYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVseFcN1vBHN6Kdx3f2RsYd3B1MXJySAiYSHS96WXuYuTiEBLY wSTxYdV3RgjnB5PEvwfb2EGqhAV8JB5PeAVmiwiISDyb/o8NxBYScJH4+vwuE4jNJqAlMefQ fxYQm1fAXmLLq4msIDaLgKrEt9/fwOKiAmkS/3afZYSoEZQ4OfMJWJxTwFXi+uqNYDazgJnE vM0PmSFscYlbT+YzQdjyEtvfzmGewMg/C0n7LCQts5C0zELSsoCRZRWjXGJOaa5ubmJmTnFq sm5xcmJeXmqRrrlebmaJXmpK6SZGSFgK72DcdVLuEKMAB6MSD2+Dx7lIIdbEsuLK3EOMkhxM SqK81lFAIb6k/JTKjMTijPii0pzU4kOMEhzMSiK80ZFAOd6UxMqq1KJ8mJQ0B4uSOK/aEnU/ IYH0xJLU7NTUgtQimKwMB4eSBG9BDFCjYFFqempFWmZOCUKaiYMTZDgP0HAzkBre4oLE3OLM dIj8KUZdjp6eG3+YhFjy8vNSpcR570YDFQmAFGWU5sHNgaWTV4ziQG8J89qDjOIBpiK4Sa+A ljABLZk88QzIkpJEhJRUA2NBr0J7CptyUorafI/NX/nYxfzl+IuWrGjzy7aIUH/evHaO04NV l+q8C4S/3y2zeX+Lt6GUf/vClScX+0UHvy45J5SbdvbsNZkY+Vf3AjpVzn7LCvf8qmt7bOWb +7lVKoon/aLOp9xZEsORcLYh6+X6f5xmW5hi3xxpKw46Mu9/s79MzR7N/0osxRmJhlrMRcWJ AM1C0+ICAwAA Archived-At: Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-reason-q850-loc-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Sep 2017 14:47:58 -0000 Looks good. On 9/29/17 4:51 AM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Session Initiation Protocol Core WG of the IETF. > > Title : ISUP Cause Location Parameter for the SIP Reason Header Field > Author : Roland Jesske > Filename : draft-ietf-sipcore-reason-q850-loc-01.txt > Pages : 6 > Date : 2017-09-29 > > Abstract: > The SIP Reason header field is defined for carrying ISUP cause values > as well as SIP response codes. Some services in SIP networks may > need to know the ISUP location where the call was released in the > PSTN network to correctly interpret the reason of release. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sipcore-reason-q850-loc/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-sipcore-reason-q850-loc-01 > https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-reason-q850-loc-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-reason-q850-loc-01 > > > 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. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Fri Sep 29 08:56:54 2017 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 CC27713330C; Fri, 29 Sep 2017 08:56:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: ben@nostrum.com, sipcore@ietf.org, brian.rosen@gmail.com, sipcore-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150670060382.14148.11811705451749020436.idtracker@ietfa.amsl.com> Date: Fri, 29 Sep 2017 08:56:43 -0700 Archived-At: Subject: [sipcore] sipcore - New Meeting Session Request for IETF 100 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Sep 2017 15:56:44 -0000 A new meeting session request has just been submitted by Brian Rosen, a Chair of the sipcore working group. --------------------------------------------------------- Working Group Name: Session Initiation Protocol Core Area Name: Applications and Real-Time Area Session Requester: Brian Rosen Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 50 Conflicts to Avoid: First Priority: stir perc dispatch rtcweb ice modern mmusic Second Priority: fud oauth netvc Third Priority: acme avtcore sipbrandy People who must be present: Ben Campbell Brian Rosen Jean Mahoney Resources Requested: Special Requests: --------------------------------------------------------- From nobody Fri Sep 29 17:35:38 2017 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 00F1C134304 for ; Fri, 29 Sep 2017 17:35:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.933 X-Spam-Level: X-Spam-Status: No, score=-1.933 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, URIBL_BLOCKED=0.001] 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 SU54ZA0V_YD9 for ; Fri, 29 Sep 2017 17:35:36 -0700 (PDT) Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (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 13E441342FF for ; Fri, 29 Sep 2017 17:35:36 -0700 (PDT) Received: from resomta-ch2-14v.sys.comcast.net ([69.252.207.110]) by resqmta-ch2-08v.sys.comcast.net with ESMTP id y5khdMisifGATy5kldJ1ZY; Sat, 30 Sep 2017 00:35:35 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-14v.sys.comcast.net with SMTP id y5kkd99HZCzrXy5kkdS7LS; Sat, 30 Sep 2017 00:35:35 +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 v8U0ZXnv013956 for ; Fri, 29 Sep 2017 20:35:33 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v8U0ZXC0013953; Fri, 29 Sep 2017 20:35:33 -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 In-Reply-To: <150667511763.14067.17235300359095515956@ietfa.amsl.com> (internet-drafts@ietf.org) Sender: worley@ariadne.com (Dale R. Worley) Date: Fri, 29 Sep 2017 20:35:32 -0400 Message-ID: <8760c181m3.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfBh6gy5sCjbCN60DunuX+8YXKyhmue0mtKL0VZczB9eqa4WLiZ0LUJ+xCVUbKIjwN2hSKQvfdcalFAJht1DOQvI2jkiVFizCKQ94Gi/d4XFZH6zeFkSF QVAKiCPhXVA3sBxECd8CNF4sSHpYCkZ3YzZHWoLX9Z8sVLfR6bS7ImYy Archived-At: Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-reason-q850-loc-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Sep 2017 00:35:37 -0000 internet-drafts@ietf.org writes: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Session Initiation Protocol Core WG of the IETF. > > Title : ISUP Cause Location Parameter for the SIP Reason Header Field > Author : Roland Jesske > Filename : draft-ietf-sipcore-reason-q850-loc-01.txt > Pages : 6 > Date : 2017-09-29 Looks good to me. Dale