From nobody Mon Mar 5 06:14:04 2018 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 B87EF12D7F2; Mon, 5 Mar 2018 06:13:54 -0800 (PST) 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.74.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152025923464.14616.3652723669244846858@ietfa.amsl.com> Date: Mon, 05 Mar 2018 06:13:54 -0800 Archived-At: Subject: [sipcore] I-D Action: draft-ietf-sipcore-sessiontimer-race-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: Mon, 05 Mar 2018 14:13:55 -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 : Session Initiation Protocol (SIP) Session Timer Glare Handling Author : Christer Holmberg Filename : draft-ietf-sipcore-sessiontimer-race-01.txt Pages : 7 Date : 2018-03-05 Abstract: This document updates RFC 4028, by clarifying the procedures for negotiating usage of the Session Initiation Protocol (SIP) session timer mechansim, in order to avoid a race condition where both endpoints trigger simultaneous negotiations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-sessiontimer-race/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sipcore-sessiontimer-race-01 https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-sessiontimer-race-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-sessiontimer-race-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 Mon Mar 5 08:12:10 2018 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 BF72912D94C for ; Mon, 5 Mar 2018 08:12:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 EmUHeRR9dw6c for ; Mon, 5 Mar 2018 08:12:07 -0800 (PST) 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 08B1712D94A for ; Mon, 5 Mar 2018 08:11:29 -0800 (PST) X-AuditID: 1207440d-98bff70000000c05-00-5a9d6c2d9934 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 3A.0D.03077.E2C6D9A5; Mon, 5 Mar 2018 11:11:26 -0500 (EST) 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 w25GBODh002118 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 5 Mar 2018 11:11:25 -0500 To: sipcore@ietf.org References: <152025923464.14616.3652723669244846858@ietfa.amsl.com> From: Paul Kyzivat Message-ID: <45ebda0e-9d23-6338-072b-e6a0142342d1@alum.mit.edu> Date: Mon, 5 Mar 2018 11:11:24 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <152025923464.14616.3652723669244846858@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKIsWRmVeSWpSXmKPExsUixO6iqKufMzfK4Fk3s8XXH5vYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8afvJnvBaYGKw9t72RsY+3m7GDk5JARMJPqfT2TuYuTiEBLY wSQx+fM2JgjnO5PEx9cL2ECqhAX8JGbtXMoIYosIiEg8m/4PLC4k4CxxfOEiVhCbTUBLYs6h /ywgNq+AvcTZNzPA6lkEVCSuta5lArFFBdIkXj3bwQxRIyhxcuYTsHpOAReJ879bwGxmATOJ eZsfMkPY4hK3nsxngrDlJba/ncM8gZF/FpL2WUhaZiFpmYWkZQEjyypGucSc0lzd3MTMnOLU ZN3i5MS8vNQiXSO93MwSvdSU0k2MkLDk3cH4f53MIUYBDkYlHt4NHnOjhFgTy4orcw8xSnIw KYnyWiYChfiS8lMqMxKLM+KLSnNSiw8xSnAwK4nw1kUC5XhTEiurUovyYVLSHCxK4rxqS9T9 hATSE0tSs1NTC1KLYLIyHBxKErxy2UCNgkWp6akVaZk5JQhpJg5OkOE8QMNjQGp4iwsSc4sz 0yHypxiNOVouPmlj5rjx4nUbsxBLXn5eqpQ476ssoFIBkNKM0jy4abDU8opRHOg5Yd5zIFU8 wLQEN+8V0ComoFXn784BWVWSiJCSamCMLVO5F8q38+E9xZz0VwprqgRtjp5/+bh0Q9/mToEE kYjwR++nL/BZ96/ozGfzhxFvu/8whrc5C1yd1fDy/YM+q+nv20rv1RlNnaXS/lD0nFrKz+Bt aasY7pb0yf57tKp1VQn7h39/Js/wN3Pm+XL64vkcLRXDKOPpW/k/6cRV/H2uekHmQ/o1JZbi jERDLeai4kQAySEC6AgDAAA= Archived-At: Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-sessiontimer-race-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: Mon, 05 Mar 2018 16:12:09 -0000 Christer, So far I have only skimmed the draft. (I *will* read it more carefully later.) A couple of comments: 1) Examples of the cases you are trying to clarify would be helpful. 2) in 3.1, am I right in concluding this is to cover the situation introduced by section 3.2? But doesn't this also eliminate the mechanism for overtly turning off session timer by sending an invite without session-expires? Thanks, Paul On 3/5/18 9:13 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 : Session Initiation Protocol (SIP) Session Timer Glare Handling > Author : Christer Holmberg > Filename : draft-ietf-sipcore-sessiontimer-race-01.txt > Pages : 7 > Date : 2018-03-05 > > Abstract: > This document updates RFC 4028, by clarifying the procedures for > negotiating usage of the Session Initiation Protocol (SIP) session > timer mechansim, in order to avoid a race condition where both > endpoints trigger simultaneous negotiations. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sipcore-sessiontimer-race/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-sipcore-sessiontimer-race-01 > https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-sessiontimer-race-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-sessiontimer-race-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 Mon Mar 5 08:41:54 2018 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 5F29512DA46 for ; Mon, 5 Mar 2018 08:41:52 -0800 (PST) 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, 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=ericsson.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 kBQZztWHb1Pu for ; Mon, 5 Mar 2018 08:41:49 -0800 (PST) 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 0687712E852 for ; Mon, 5 Mar 2018 08:41:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1520268106; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=0nirifb5lpkAhLlsia/3d1QdU3964+BXA4Sn75tem6g=; b=cydR5A+yyFd4Qaogd4nxcr3z7PnfBTXV1jgINbxpAEM3V/641XIKfzS654VpR7JZ MGVrxnyI0A9o0H6ovjECxTP6J+G/1LhLC6koEqi3R/TJgOXYPlTPNzA9KLWPPXl2 Joygs2m8uKUWmUqCsb9qgEUVJcwogS4liZBGfX0TGK8=; X-AuditID: c1b4fb3a-728f89c0000067b4-4f-5a9d734a76b4 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 60.A4.26548.A437D9A5; Mon, 5 Mar 2018 17:41:46 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.82]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0352.000; Mon, 5 Mar 2018 17:41:41 +0100 From: Christer Holmberg To: Paul Kyzivat CC: "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-sessiontimer-race-01.txt Thread-Index: AQHTtIw7p1ptmF8ozkitn+4GNAHNCKPBv1oAgAAZOjc= Date: Mon, 5 Mar 2018 16:41:41 +0000 Message-ID: <446AD2FF-49DE-4D9E-8B76-6CD066BA94C2@ericsson.com> References: <152025923464.14616.3652723669244846858@ietfa.amsl.com>, <45ebda0e-9d23-6338-072b-e6a0142342d1@alum.mit.edu> In-Reply-To: <45ebda0e-9d23-6338-072b-e6a0142342d1@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_446AD2FF49DE4D9E8B766CD066BA94C2ericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplkeLIzCtJLcpLzFFi42KZGbFdQtereG6UwZqdphYrNhxgtfj6YxOb A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJUx+/AftoIH7hV3P89ha2DssO9i5OSQEDCR mNdxh6mLkYtDSOAwo8T+kwugnEWMEjvOHGfsYuTgYBOwkOj+pw1iighoSEzaqgbSyyygKfFo 514mEFtYIEBi78zprBAlgRKfdhuDhEUErCRmvTrPBBJmEVCR2PbbFSTMK2AvcXpJDyOILSRQ LrG98QSYzSngILH+y2KwiYwCYhLfT61hgtgkLnHryXwmiIsFJJbsOc8MYYtKvHz8jxWiJlli 7cE+Roj5ghInZz5hmcAoPAtJ+ywkZbOQlEHEdSQW7P7EBmFrSyxb+JoZxj5z4DETsvgCRvZV jKLFqcXFuelGRnqpRZnJxcX5eXp5qSWbGIGRc3DLb6sdjAefOx5iFOBgVOLh7UyYGyXEmlhW XJl7iFGCg1lJhLcuEijEm5JYWZValB9fVJqTWnyIUZqDRUmc1ynNIkpIID2xJDU7NbUgtQgm y8TBKdXAmLVs3RkHvnNZf234T8nE76432OtqvPHwB85kmZNRsys31ac/kHA4ySfVf99CdBqn zbKfq1zP7LSu+NH+svRpmSRfQUPJFY3Lcatku14XifLkc53bFPBRzS/bTu3ZKrbs6uQoluyZ pr0KX4IYjqtEcuVmPTzCwmpyvHXNdKbzUbaTjt9gLLuixFKckWioxVxUnAgAqv1fypgCAAA= Archived-At: Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-sessiontimer-race-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: Mon, 05 Mar 2018 16:41:52 -0000 --_000_446AD2FF49DE4D9E8B766CD066BA94C2ericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I forgot to mention that the new version is only because the previous one w= as about to expire, so apart from the year there should be no changes. Sorr= y for that. I will provide some suggestions regarding how to move forward soon. Regards, Christer Sent from my iPhone On 5 Mar 2018, at 18.12, Paul Kyzivat > wrote: Christer, So far I have only skimmed the draft. (I *will* read it more carefully late= r.) A couple of comments: 1) Examples of the cases you are trying to clarify would be helpful. 2) in 3.1, am I right in concluding this is to cover the situation introduced by section 3.2? But doesn't this also eliminate the mechanism for overtly turning off session timer by sending an invite without session-expires? Thanks, Paul On 3/5/18 9:13 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. Title : Session Initiation Protocol (SIP) Session Timer G= lare Handling Author : Christer Holmberg Filename : draft-ietf-sipcore-sessiontimer-race-01.txt Pages : 7 Date : 2018-03-05 Abstract: This document updates RFC 4028, by clarifying the procedures for negotiating usage of the Session Initiation Protocol (SIP) session timer mechansim, in order to avoid a race condition where both endpoints trigger simultaneous negotiations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-sessiontimer-race/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sipcore-sessiontimer-race-01 https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-sessiontimer-race-= 01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipcore-sessiontimer-race-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 _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore --_000_446AD2FF49DE4D9E8B766CD066BA94C2ericssoncom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi,

I forgot to mention that the new version is only because the previous = one was about to expire, so apart from the year there should be no changes.= Sorry for that.

I will provide some suggestions regarding how to move forward soon.

Regards,

Christer

Sent from my iPhone

On 5 Mar 2018, at 18.12, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

Christer,

So far I have only skimmed the draft. (I *will* read it more carefull= y later.) A couple of comments:

1) Examples of the cases you are trying to clarify would be helpful.<= /span>

2) in 3.1, am I right in concluding this is to cover the situation
  introduced by section 3.2?  But doesn't this also el= iminate the
  mechanism for overtly turning off session timer by sendin= g an
  invite without session-expires?

   Thanks,
   Paul

On 3/5/18 9:13 AM, intern= et-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 In= itiation Protocol Core WG of the IETF.
       &= nbsp;Title           : Se= ssion Initiation Protocol (SIP) Session Timer Glare Handling
       &= nbsp;Author          : Christe= r Holmberg
   Filename    &nb= sp;   : draft-ietf-sipcore-sessiontimer-race-01.txt
   Pages     =       : 7
   Date     &= nbsp;      : 2018-03-05
Abstract:
   This document updates RFC= 4028, by clarifying the procedures for
   negotiating usage of the = Session Initiation Protocol (SIP) session
   timer mechansim, in order= to avoid a race condition where both
   endpoints trigger simulta= neous negotiations.
The IETF datatracker status page for this d= raft is:
https://datatracker.ietf.org/doc/dr= aft-ietf-sipcore-sessiontimer-race/
There are also htmlized versions available = at:
https://tools.ietf.org/html/draft-ietf= -sipcore-sessiontimer-race-01
https://datatracker.ietf.org= /doc/html/draft-ietf-sipcore-sessiontimer-race-01
A diff from the previous version is availab= le at:
https://www.ietf.org/rfcdiff?u= rl2=3Ddraft-ietf-sipcore-sessiontimer-race-01
Please note that it may take a couple of mi= nutes from the time of submission
until the htmlized version and diff are ava= ilable at tools.ietf.org.
Internet-Drafts are also available by anony= mous 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
--_000_446AD2FF49DE4D9E8B766CD066BA94C2ericssoncom_-- From nobody Thu Mar 8 19:03:56 2018 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 461A9126CD8 for ; Thu, 8 Mar 2018 19:03:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.684 X-Spam-Level: X-Spam-Status: No, score=-1.684 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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 I-QRDfJZa2WE for ; Thu, 8 Mar 2018 19:03:54 -0800 (PST) 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 56BF91200E5 for ; Thu, 8 Mar 2018 19:03:54 -0800 (PST) Received: from resomta-ch2-01v.sys.comcast.net ([69.252.207.97]) by resqmta-ch2-12v.sys.comcast.net with ESMTP id u8K1eqiLMlAzJu8K1eTrlA; Fri, 09 Mar 2018 03:03:53 +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 u8JzeOUDKLLZNu8K0ehcpP; Fri, 09 Mar 2018 03:03:52 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id w2933okN024096; Thu, 8 Mar 2018 22:03:50 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id w2933nLK024093; Thu, 8 Mar 2018 22:03:49 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Roman Shpount Cc: sipcore@ietf.org In-Reply-To: (roman@telurix.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Thu, 08 Mar 2018 22:03:49 -0500 Message-ID: <87r2ou2bmy.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfBjbGgDAdZeQ5m7zjJ2kIM4A/PBO/2MYby2vOXgX8XM36hzm2blVwd38W1qPlsR8kHLlLnFjtAK6U6J7yxb7T6GNxTCwILISzXNDg63ajknLwPfB0cLR Cd/5ooY7kAB4Zuh1jYeuNJqo4DK5+lS1k0VMGPF6iVp97chMzlyU6vO5oleUV9St5eHlxX7tes7l8w== Archived-At: Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-sip-push - SIP combine with push implementation experience 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, 09 Mar 2018 03:03:55 -0000 Roman Shpount writes: > [much interesting and informative material] > As far as Registration expiration is concerned, for SIP-push it is needed > to specify the minimum allowed registration expires interval otherwise > there is not enough time for a SIP-push notification to complete and > registration request to be sent before registration expires. We have used a > minimum expires value of 90 seconds and failed all registrations with all > lower expires non-zero values. I would expect in situations where the UA desires to power down when it is not in use, it would be very desirable to use long registrations. However, you describe allowing a registration interval of 90 seconds, which seems very short. Can you explain the scenarios in which such a short registration is desirable? Dale From nobody Thu Mar 8 19:14:14 2018 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 C9115126B6E for ; Thu, 8 Mar 2018 19:14:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.685 X-Spam-Level: X-Spam-Status: No, score=-1.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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 P2vLo47yyfvZ for ; Thu, 8 Mar 2018 19:14:12 -0800 (PST) Received: from resqmta-ch2-03v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3D8D1200E5 for ; Thu, 8 Mar 2018 19:14:11 -0800 (PST) Received: from resomta-ch2-03v.sys.comcast.net ([69.252.207.99]) by resqmta-ch2-03v.sys.comcast.net with ESMTP id u8T3ecUio8TrNu8TyeAzJH; Fri, 09 Mar 2018 03:14:10 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-03v.sys.comcast.net with SMTP id u8TxeOuUmoFrIu8Tye5cPz; Fri, 09 Mar 2018 03:14:10 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id w293E8a6025161; Thu, 8 Mar 2018 22:14:08 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id w293E8bb025158; Thu, 8 Mar 2018 22:14:08 -0500 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: Michael.Arnold@metaswitch.com, sipcore@ietf.org, roman@telurix.com In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C176CF9@ESESSMB109.ericsson.se> (christer.holmberg@ericsson.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Thu, 08 Mar 2018 22:14:07 -0500 Message-ID: <87o9jy2b5s.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfAfwCA3nnZio4vaNmhCteE00rbl4pLYMo67IG68pdVGctxdjslYnHglfmV9cMZylbxnSC3BVeJil3VID83B2ZkG35NKjb3Tbqclw+anHttauyGgyzr4Y AvqLU4CeI5rZOryFJMu/uXAZwxcq1vHr9uZmOdupQmKAqHEVtRj5kTOZzC6KShmM9GlyvOM3J2G57yX/hq0B4W5llkHaflGzZde11wgyJQlLMhBTaMRQBQ4O zIXJXPzZyungXREJYxw/vnw1wkM6RtV1D4ELdB2xDtw= Archived-At: Subject: Re: [sipcore] Comments on draft-ietf-sipcore-sip-push-04 - Timer triggered REGISTER requests - Pull request 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, 09 Mar 2018 03:14:13 -0000 I wrote a long message, trying to work out which components of the SIP system know which elements of the entire reregistration delay when a UA using sip-push needs to wake up to reregister. Unfortunately, given that the re-REGISTER may easily be rejected with a 401, requiring the UA to send another REGISTER, the process is messy enough there's no way to come up with a neat formula that lets the UA register optimally just before its registration expires. So I'm abandoning that attempt, and suggesting that we specify that the system should always allow "enough" time for the UA to reregister. I believe that the value of 120 seconds has been recommended, and that seems sufficient to me. My assumption is that registrations will be for as long as 1 hour, as in wired SIP systems. OTOH, Roman mentions registrations as short as 90 seconds, which makes handling reregistrations more difficult. I'd like to hear more about that case. Dale From nobody Thu Mar 8 19:21:20 2018 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 9B79F1200E5 for ; Thu, 8 Mar 2018 19:21:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 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, URIBL_BLOCKED=0.001] 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 OktOP_umWflO for ; Thu, 8 Mar 2018 19:21:16 -0800 (PST) Received: from mail-pl0-x235.google.com (mail-pl0-x235.google.com [IPv6:2607:f8b0:400e:c01::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 02AE7126B6E for ; Thu, 8 Mar 2018 19:21:16 -0800 (PST) Received: by mail-pl0-x235.google.com with SMTP id f23-v6so4532641plr.10 for ; Thu, 08 Mar 2018 19:21:15 -0800 (PST) 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=GwL5AOLmXW2ZZWetA8oKcCkP8dWa+vgI1AY7w3QRxsI=; b=dEi532Qtz117rvoj3WemOw8EF61ZFLAEd1mnCJuTTz4ExQkKD1msrTP1WffG9HubSJ K8o+UHqt4VjWNlBgCG2ylN38tKkcjYpcEIiI8dKxxXN3YnbTovntX3J2kYPqN12sFuTP l29lx7rdWHXp9DDguGIuoXPlhKj4DD+rkMW0iRoiHFybWpmTRA4l34di/P91wsNgvf2w V9zvnkQ87SRo8V+Cc+H6q2DZ59hQVAGNLr/DIsAt430sKlIPdbxx3x47rSw8kDBZ5ZKn vCV8UsLA4ZGY9mhCXozbgf8+zc/Z57N/1u5NpaqABDIYXcgq4Kt0CHZuMlV5xA6yS801 H2Lg== 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=GwL5AOLmXW2ZZWetA8oKcCkP8dWa+vgI1AY7w3QRxsI=; b=CdggE/yvgwkugrkhX2PkoKGJn6ZuiXAnATZ1BfN3HLY2yljb78czwRBcGPb//pJfwl yAbHpnMIKrHBylJxqtcwFLpN6J3wOOxAPtnUDYWliEf7Q4XMkmwfwugwv4dCu7xvXgpv Frae6ZrDYO/LFo6+h1N4DrM1IDm+i8VbETdiDsxGDPyve1drca1zxeHBYKsj9SaLW17+ qg7756DGDRjDAS20MEtSFeaidNEzTx0dvgBzlQ+fmCfW0S9YU1ijqpU5H0khPfrrf0wI 2ARmpbrT0+kAFKB+BlmACSqcirY/D9XbbAnlIzwzDnAZWqTQiJKS1tryonlo2omme4OR hW+Q== X-Gm-Message-State: APf1xPD8qrxrtNvjzSXay+eFNp5muXGWtEO7sZs3qmbwKz+55kYceNqR k0mYcBMTJRL0DFhJsvV0XL78FZ4j X-Google-Smtp-Source: AG47ELvyWj94MofoH7rWd+EAQtmRljhTE0SQMZ6dAUmBFoRuwjBH9ThXbK7SEHTm4Wem2wdAbIT/ig== X-Received: by 2002:a17:902:8214:: with SMTP id x20-v6mr25767916pln.182.1520565675442; Thu, 08 Mar 2018 19:21:15 -0800 (PST) Received: from mail-pg0-f45.google.com (mail-pg0-f45.google.com. [74.125.83.45]) by smtp.gmail.com with ESMTPSA id z28sm128691pgc.69.2018.03.08.19.21.14 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Mar 2018 19:21:14 -0800 (PST) Received: by mail-pg0-f45.google.com with SMTP id y8so3065242pgr.9 for ; Thu, 08 Mar 2018 19:21:14 -0800 (PST) X-Received: by 10.99.116.67 with SMTP id e3mr22651031pgn.265.1520565674374; Thu, 08 Mar 2018 19:21:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.229.71 with HTTP; Thu, 8 Mar 2018 19:21:13 -0800 (PST) In-Reply-To: <87o9jy2b5s.fsf@hobgoblin.ariadne.com> References: <7594FB04B1934943A5C02806D1A2204B6C176CF9@ESESSMB109.ericsson.se> <87o9jy2b5s.fsf@hobgoblin.ariadne.com> From: Roman Shpount Date: Thu, 8 Mar 2018 22:21:13 -0500 X-Gmail-Original-Message-ID: Message-ID: To: "Dale R. Worley" Cc: Christer Holmberg , Mickey Arnold , SIPCORE Content-Type: multipart/alternative; boundary="f403045cdcece0fcf10566f24894" Archived-At: Subject: Re: [sipcore] Comments on draft-ietf-sipcore-sip-push-04 - Timer triggered REGISTER requests - Pull request 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, 09 Mar 2018 03:21:17 -0000 --f403045cdcece0fcf10566f24894 Content-Type: text/plain; charset="UTF-8" Dale, All I said that for the sip PUSH to work, a reasonable minimal Registration duration is required. I wrote that most likely you would not be able to implement re-registrations triggering using push notifications if registration expiration is less then 90 seconds. My suggestion was: 1. If push notifications are used, minimal Registration expiration of 90 seconds (can be longer) is enforced. 2. Push notification is sent either 30 seconds or 1/3 of the registration expiration interval before registration expiration, whichever is longer 3. If client want's to re-Register on its own, it needs to send re-registration after 1/2 of the expiration period. Finally, I know that push notification content is not currently used for anything, but it would be really beneficial to at least be able to send a new nonce value, which will allow to avoid 401 and Registration re-transmission. Regards, _____________ Roman Shpount On Thu, Mar 8, 2018 at 10:14 PM, Dale R. Worley wrote: > I wrote a long message, trying to work out which components of the SIP > system know which elements of the entire reregistration delay when a UA > using sip-push needs to wake up to reregister. Unfortunately, given > that the re-REGISTER may easily be rejected with a 401, requiring the UA > to send another REGISTER, the process is messy enough there's no way to > come up with a neat formula that lets the UA register optimally just > before its registration expires. > > So I'm abandoning that attempt, and suggesting that we specify that the > system should always allow "enough" time for the UA to reregister. I > believe that the value of 120 seconds has been recommended, and that > seems sufficient to me. > > My assumption is that registrations will be for as long as 1 hour, as in > wired SIP systems. OTOH, Roman mentions registrations as short as 90 > seconds, which makes handling reregistrations more difficult. I'd like > to hear more about that case. > > Dale > --f403045cdcece0fcf10566f24894 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dale,

All I said that for the sip PUSH = to work, a reasonable minimal Registration duration is required. I wrote th= at most likely you would not be able to implement re-registrations triggeri= ng using push notifications if registration expiration is less then 90 seco= nds.

My suggestion was:

1= . If push notifications are used, minimal Registration expiration of 90 sec= onds (can be longer) is enforced.
2. Push notification is sent ei= ther 30 seconds or 1/3 of the registration expiration interval before regis= tration expiration, whichever is longer
3. If client want's t= o re-Register on its own, it needs to send re-registration after 1/2 of the= expiration period.

Finally, I know that push noti= fication content is not currently used for anything, but it would be really= beneficial to at least be able to send a new nonce value, which will allow= to avoid 401 and Registration re-transmission.

Re= gards,

_____________Roman Shpount

On Thu, Mar 8, 2018 at 10:14 PM, Dale R. Wor= ley <worley@ariadne.com> wrote:
I wrote a long message, trying to work out which components of the S= IP
system know which elements of the entire reregistration delay when a UA
using sip-push needs to wake up to reregister.=C2=A0 Unfortunately, given that the re-REGISTER may easily be rejected with a 401, requiring the UA to send another REGISTER, the process is messy enough there's no way to=
come up with a neat formula that lets the UA register optimally just
before its registration expires.

So I'm abandoning that attempt, and suggesting that we specify that the=
system should always allow "enough" time for the UA to reregister= .=C2=A0 I
believe that the value of 120 seconds has been recommended, and that
seems sufficient to me.

My assumption is that registrations will be for as long as 1 hour, as in wired SIP systems.=C2=A0 OTOH, Roman mentions registrations as short as 90<= br> seconds, which makes handling reregistrations more difficult.=C2=A0 I'd= like
to hear more about that case.

Dale

--f403045cdcece0fcf10566f24894-- From nobody Thu Mar 8 19:22:35 2018 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 DD637126B6E for ; Thu, 8 Mar 2018 19:22:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.684 X-Spam-Level: X-Spam-Status: No, score=-1.684 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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 GcZ0DMsdnwEz for ; Thu, 8 Mar 2018 19:22:33 -0800 (PST) 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 299F81200E5 for ; Thu, 8 Mar 2018 19:22:33 -0800 (PST) Received: from resomta-ch2-15v.sys.comcast.net ([69.252.207.111]) by resqmta-ch2-12v.sys.comcast.net with ESMTP id u8bpeqjqZlAzJu8c4eTuN7; Fri, 09 Mar 2018 03:22:32 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-15v.sys.comcast.net with SMTP id u8c2eah3Dveoeu8c3eRDap; Fri, 09 Mar 2018 03:22:31 +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 w293MUjP025983; Thu, 8 Mar 2018 22:22:30 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id w293MUnl025978; Thu, 8 Mar 2018 22:22:30 -0500 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: <7594FB04B1934943A5C02806D1A2204B6C176C9E@ESESSMB109.ericsson.se> (christer.holmberg@ericsson.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Thu, 08 Mar 2018 22:22:29 -0500 Message-ID: <87k1um2aru.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfJ9bjtNlj171+pGLuVbJguMKBTrrf9h8gaqFVmoSnzEviu1L7sOhWtrYGou5dgwlSpz7KAvaIuOP+MLF52U9j9NgggxwDryTRWdo0OUSnr0nJxjeHNiE sN71rXq9IteOAjyFbVTGXO3gXbwxFN2GX5lw/RUXky32MmXr21jhxC7qMlP1fAGPfVDDSBwVSbjNDxWqYy+ojebNcPx+xjtKheI= Archived-At: Subject: Re: [sipcore] SIP-push -- Where is the "proxy"? 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, 09 Mar 2018 03:22:34 -0000 Christer Holmberg writes: > The assumption is that the proxy is able to retrieve the needed > registration information, either by being in the path of the REGISTER > (which is the case in all scenarios I am aware of), or retrieving the > information using some other mechanism. It seems to me that the difficult case is not when the proxy retrieves the registration information, but that the proxy must know when the re-REGISTER has been sent. On one hand, as you say, the proxy can be in the path of the REGISTER. That requires that the proxy be "near" the registrar, so that any REGISTER for the AOR will necessarily pass through the proxy as well. But that pretty much requires that the proxy be attached to the registrar, as otherwise REGISTERs can take routes to the registrar that miss the proxy. (I particularly imagine the WiFi/cellular use case that Roman mentions, which has been a huge market target for over 10 years. In that case, the phone can easily re-REGISTER on an entirely different network than it was previously registered through.) But if the proxy is "near the edge", it needs a way to wait for the re-REGISTER that doesn't require it to process the re-REGISTER. I think that this can be done by it subscribing to the 'reg' package for the AOR, but that requires that the R-URI that it sees in the incoming request to somehow carry the AOR. OTOH, perhaps we will just limit sip-push implementations to require that the proxy be very near the registrar, if not entirely integrated with it. In that case, the design can be simplified, probably even more than it is now. Dale From nobody Thu Mar 8 19:24:08 2018 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 8960B126B6E for ; Thu, 8 Mar 2018 19:24:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 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, URIBL_BLOCKED=0.001] 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 w1EMuaXGxWdg for ; Thu, 8 Mar 2018 19:24:05 -0800 (PST) Received: from mail-pl0-x230.google.com (mail-pl0-x230.google.com [IPv6:2607:f8b0:400e:c01::230]) (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 681C91200E5 for ; Thu, 8 Mar 2018 19:24:05 -0800 (PST) Received: by mail-pl0-x230.google.com with SMTP id 9-v6so4532565ple.11 for ; Thu, 08 Mar 2018 19:24:05 -0800 (PST) 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=zc3akc85OfVdurY/FvmqxFdpXfQrfcHhQaPY40Nl0XU=; b=knqCJgqBaEYTOWs+QwlDJLo4lsTYC09I3UU+nn+/B2yZ9wctjp3utCQrwJwA6Zcpnj gMHVKPLF1X2dvreY42w1Zahkyb7jL4I6/YGgDIL1u/yNcFhis9jdB9eazCPZJyu7tA1a TjPdenSuS3SnHeTZrxTA9LOvuGXs+QTT+hPos8DE6jg24gTUk1/iqf7XH74g5V5VFjhq y7Bk9BCE2zMaYUhdcHtO5uIx3Rk7zwF+zXOJuGQ0Mkh/SG0rCke6vp8Q1ceA1ENJvI/y ofQCBSOLHJLt3oxgnFD3T8c6jjWrs9lyLGL02poSSwH2JAXTy4O3cFYgK4+NJDfSujzW 46xQ== 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=zc3akc85OfVdurY/FvmqxFdpXfQrfcHhQaPY40Nl0XU=; b=Vabc3FBbiwDL+mOTbPsRndO4pjjxAb0uzDoShEgodZg0Gme6obq6Ug+JdR8igyykRd W/ID5iPAUYFUHQ6fDuXd2ytiAE0dt6v87tdydO8Wh64NvGyUez/DxtNGZduY6JXjlstk 0thB3ifdIRY51zHZ6o18R9iVjsWXekUpfrqusUOM9hr+EoX+cL2t3F+mfIwfKjnwnOeH 5l/Hw2VHt+TSkYR6VVo8+xVX6YWuuY4fE1AdcVtdw2rtPoaN4uc1hBayXR4Va0XrCRZW ikBS8fuXOrtAWupkfKGIPmKt7rg8PHAU51vAsb8ivvF5/vyBYlmpBp7xY0rc0AHh1ivW HT3g== X-Gm-Message-State: APf1xPCAhTs5x62PS8+QepDtugJjpGv3ObaCkhZJtgoc9aBfs0+71LCa Nmt/BmUrpPq7uJxU7G089NiKLIgQ X-Google-Smtp-Source: AG47ELtAbY4QmMZfhbBBFb2ibkW1qlDuqyWlmLRcftXeAQ+5OjaMz1uX8ov7h/zP9je+/jp95+SOsg== X-Received: by 2002:a17:902:6985:: with SMTP id l5-v6mr26788268plk.14.1520565844845; Thu, 08 Mar 2018 19:24:04 -0800 (PST) Received: from mail-pl0-f45.google.com (mail-pl0-f45.google.com. [209.85.160.45]) by smtp.gmail.com with ESMTPSA id s67sm174169pfg.104.2018.03.08.19.24.04 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Mar 2018 19:24:04 -0800 (PST) Received: by mail-pl0-f45.google.com with SMTP id y8-v6so4515561pll.13 for ; Thu, 08 Mar 2018 19:24:04 -0800 (PST) X-Received: by 2002:a17:902:6943:: with SMTP id k3-v6mr18995144plt.214.1520565844202; Thu, 08 Mar 2018 19:24:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.229.71 with HTTP; Thu, 8 Mar 2018 19:24:03 -0800 (PST) In-Reply-To: <87r2ou2bmy.fsf@hobgoblin.ariadne.com> References: <87r2ou2bmy.fsf@hobgoblin.ariadne.com> From: Roman Shpount Date: Thu, 8 Mar 2018 22:24:03 -0500 X-Gmail-Original-Message-ID: Message-ID: To: "Dale R. Worley" Cc: SIPCORE Content-Type: multipart/alternative; boundary="000000000000005a840566f25391" Archived-At: Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-sip-push - SIP combine with push implementation experience 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, 09 Mar 2018 03:24:06 -0000 --000000000000005a840566f25391 Content-Type: text/plain; charset="UTF-8" Dale, I said that we did not allow registrations with expires value less then 90 seconds. Normally much larger expires values (1 hour) were used. This was done since if registration expiration interval is too short, there is not enough time to send push notification and for registration transaction to complete before registration expires. Regards, _____________ Roman Shpount On Thu, Mar 8, 2018 at 10:03 PM, Dale R. Worley wrote: > Roman Shpount writes: > > [much interesting and informative material] > > As far as Registration expiration is concerned, for SIP-push it is needed > > to specify the minimum allowed registration expires interval otherwise > > there is not enough time for a SIP-push notification to complete and > > registration request to be sent before registration expires. We have > used a > > minimum expires value of 90 seconds and failed all registrations with all > > lower expires non-zero values. > > I would expect in situations where the UA desires to power down when it > is not in use, it would be very desirable to use long registrations. > However, you describe allowing a registration interval of 90 seconds, > which seems very short. Can you explain the scenarios in which such a > short registration is desirable? > > Dale > --000000000000005a840566f25391 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dale,

I said that we did not allow regi= strations with expires value less then 90 seconds. Normally much larger exp= ires values (1 hour) were used.

This was done sinc= e if registration expiration interval is too short, there is not enough tim= e to send push notification and for registration transaction to complete be= fore registration expires.

Regards,

_____________
Roman Shpount
<= /div>
On Thu, Mar 8, 2018 at 10:03 PM, Dale R. Wor= ley <worley@ariadne.com> wrote:
Roman Shpount <roman@telurix= .com> writes:
> [much interesting and informative material]
> As far as Registration expiration is concerned, for S= IP-push it is needed
> to specify the minimum allowed registration expires interval otherwise=
> there is not enough time for a SIP-push notification to complete and > registration request to be sent before registration expires. We have u= sed a
> minimum expires value of 90 seconds and failed all registrations with = all
> lower expires non-zero values.

I would expect in situations where the UA desires to power down when= it
is not in use, it would be very desirable to use long registrations.
However, you describe allowing a registration interval of 90 seconds,
which seems very short.=C2=A0 Can you explain the scenarios in which such a=
short registration is desirable?

Dale

--000000000000005a840566f25391-- From nobody Thu Mar 8 21:55:28 2018 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 29AB7126DEE for ; Thu, 8 Mar 2018 21:55:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 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, URIBL_BLOCKED=0.001] 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 afq9qpdoZa-W for ; Thu, 8 Mar 2018 21:55:25 -0800 (PST) Received: from mail-pl0-x230.google.com (mail-pl0-x230.google.com [IPv6:2607:f8b0:400e:c01::230]) (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 1436D1242EA for ; Thu, 8 Mar 2018 21:55:25 -0800 (PST) Received: by mail-pl0-x230.google.com with SMTP id w22-v6so4732617pll.2 for ; Thu, 08 Mar 2018 21:55:24 -0800 (PST) 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=m0wtB94uZnSb9neJuRjUF0L9jdDhbW7VtETjIyxrfds=; b=Ff+EP0QLBqoV9bvI0f+BPp+D+evAW29V3Nrab4pNmknFSecBI+bYlxxYi/UJu37aNk bsBvLTuQ3Kn+p2LPJDLMcgetRNJe2RkXnZPcS3nQSRtQrL2/pAxUMWmPfItOF0xxJTgN Vp9gkD1VZ9jJm03+m6viSfls8kVeL1Y2IFNVtEy6xpKyWL1y91GhY6nSv5xjIqFQYe9C P7L6LzQOxNXZ4elUt+PokRb4RhUR8BYB5yH1utS7IGbPk2FIS9fD3bTaZTDjlFxdUkN2 p2Jxftfvfg2QCPq7VwIkhJdCLhVPUl4DgwJ7W0+JipTotftQ8E/BVUHEItsoA3esnaSJ OHqQ== 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=m0wtB94uZnSb9neJuRjUF0L9jdDhbW7VtETjIyxrfds=; b=VPNFX14O2bDb0kDtW9iezKi7sWadSipF4ifo62YjYoJCphh1pbnlPZ+OyBjmG2jLqN pJckPn+P1xiPhdgSJAvPPP4JKt9KxWkOagCstMoHYfSspT3ZP1q5/4CU8+Nntv/mX8hg PA236aktRBDU/sF0iBQOwDCyh469642eq6oX7hYlq1le2IUXLLTOVD5Yyv8+QAzxGQgB ny3EBPQC1SjyKTB4255dTnwhXHJjOnBnYWpK4nLtr2h/tFi+ErWak2Hl8+OfsGTHx0zw RmnWmZVIjLuexYHCtTSD7CSyy8D6bT7vzFQbvxfzc1RUfOWxYOxERBv/BsrT9t73cw2v KkuQ== X-Gm-Message-State: APf1xPAZDOVGmNbhxK6EL7MizqX5fxmGSdaOVU+rRiv7XhacZ+J8/wpU eTpUv9ZROWAW9wc5WLjYn3u8zuME X-Google-Smtp-Source: AG47ELt19NEf1bwZ97riY6gDBoXRJ4omNF03n/UpzjL5bG7YU1usfZmi1Vmo/Wm9gti2kybYNDnhZg== X-Received: by 2002:a17:902:62:: with SMTP id 89-v6mr26535602pla.178.1520574924541; Thu, 08 Mar 2018 21:55:24 -0800 (PST) Received: from mail-pl0-f53.google.com (mail-pl0-f53.google.com. [209.85.160.53]) by smtp.gmail.com with ESMTPSA id f186sm945526pfc.86.2018.03.08.21.55.23 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Mar 2018 21:55:23 -0800 (PST) Received: by mail-pl0-f53.google.com with SMTP id d9-v6so4725242plo.8 for ; Thu, 08 Mar 2018 21:55:23 -0800 (PST) X-Received: by 2002:a17:902:8c93:: with SMTP id t19-v6mr26341325plo.304.1520574923342; Thu, 08 Mar 2018 21:55:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.229.71 with HTTP; Thu, 8 Mar 2018 21:55:22 -0800 (PST) In-Reply-To: <87k1um2aru.fsf@hobgoblin.ariadne.com> References: <7594FB04B1934943A5C02806D1A2204B6C176C9E@ESESSMB109.ericsson.se> <87k1um2aru.fsf@hobgoblin.ariadne.com> From: Roman Shpount Date: Fri, 9 Mar 2018 00:55:22 -0500 X-Gmail-Original-Message-ID: Message-ID: To: "Dale R. Worley" Cc: Christer Holmberg , SIPCORE Content-Type: multipart/alternative; boundary="0000000000002909670566f470c0" Archived-At: Subject: Re: [sipcore] SIP-push -- Where is the "proxy"? 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, 09 Mar 2018 05:55:27 -0000 --0000000000002909670566f470c0 Content-Type: text/plain; charset="UTF-8" Dale, I suggest you go through RFC 5626 since it addresses most of your questions. SIP-push should really be an update for RFC 5626 which optimizes the connection maintenance process when no calls are in process and push notifications are available. While calls are in process plain RFC 5626 procedures and flow maintenance is used. Regards, _____________ Roman Shpount On Thu, Mar 8, 2018 at 10:22 PM, Dale R. Worley wrote: > Christer Holmberg writes: > > The assumption is that the proxy is able to retrieve the needed > > registration information, either by being in the path of the REGISTER > > (which is the case in all scenarios I am aware of), or retrieving the > > information using some other mechanism. > > It seems to me that the difficult case is not when the proxy retrieves > the registration information, but that the proxy must know when the > re-REGISTER has been sent. > > On one hand, as you say, the proxy can be in the path of the REGISTER. > That requires that the proxy be "near" the registrar, so that any > REGISTER for the AOR will necessarily pass through the proxy as well. > But that pretty much requires that the proxy be attached to the > registrar, as otherwise REGISTERs can take routes to the registrar that > miss the proxy. > > (I particularly imagine the WiFi/cellular use case that Roman mentions, > which has been a huge market target for over 10 years. In that case, > the phone can easily re-REGISTER on an entirely different network than > it was previously registered through.) > > But if the proxy is "near the edge", it needs a way to wait for the > re-REGISTER that doesn't require it to process the re-REGISTER. I think > that this can be done by it subscribing to the 'reg' package for the > AOR, but that requires that the R-URI that it sees in the incoming > request to somehow carry the AOR. > > OTOH, perhaps we will just limit sip-push implementations to require > that the proxy be very near the registrar, if not entirely integrated > with it. In that case, the design can be simplified, probably even more > than it is now. > > Dale > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --0000000000002909670566f470c0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dale,

I suggest you go through RFC 5626= since it addresses most of your questions. SIP-push should really be an up= date for RFC 5626 which optimizes the connection maintenance process when n= o calls are in process and push notifications are available. While calls ar= e in process plain RFC 5626 procedures and flow maintenance is used.
<= div>
Regards,

_____________
Roman Shpount

On Thu, Mar 8, 2018 at 10:22 PM, Dale R. Wor= ley <worley@ariadne.com> wrote:
Christer Holmberg <christer.holmberg@ericsson.com> writes:
> The assumption is that the proxy is able to retrieve the needed
> registration information, either by being in the path of the REGISTER<= br> > (which is the case in all scenarios I am aware of), or retrieving the<= br> > information using some other mechanism.

It seems to me that the difficult case is not when the proxy retrieves
the registration information, but that the proxy must know when the
re-REGISTER has been sent.

On one hand, as you say, the proxy can be in the path of the REGISTER.
That requires that the proxy be "near" the registrar, so that any=
REGISTER for the AOR will necessarily pass through the proxy as well.
But that pretty much requires that the proxy be attached to the
registrar, as otherwise REGISTERs can take routes to the registrar that
miss the proxy.

(I particularly imagine the WiFi/cellular use case that Roman mentions,
which has been a huge market target for over 10 years.=C2=A0 In that case,<= br> the phone can easily re-REGISTER on an entirely different network than
it was previously registered through.)

But if the proxy is "near the edge", it needs a way to wait for t= he
re-REGISTER that doesn't require it to process the re-REGISTER.=C2=A0 I= think
that this can be done by it subscribing to the 'reg' package for th= e
AOR, but that requires that the R-URI that it sees in the incoming
request to somehow carry the AOR.

OTOH, perhaps we will just limit sip-push implementations to require
that the proxy be very near the registrar, if not entirely integrated
with it.=C2=A0 In that case, the design can be simplified, probably even mo= re
than it is now.

Dale

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

--0000000000002909670566f470c0-- From nobody Thu Mar 8 23:31:46 2018 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 ACDF9124D6C for ; Thu, 8 Mar 2018 23:31:45 -0800 (PST) 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_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=ericsson.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 96zZFFyrP8i4 for ; Thu, 8 Mar 2018 23:31:44 -0800 (PST) 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 BCFF31201FA for ; Thu, 8 Mar 2018 23:31:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1520580701; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ZpnYTpEvgqsVEGrfhY+HIQDdYgiF80M0MYjndiTkrwo=; b=BlCGCkiZZ3ISexls+mizJwp7Im1wpiRhsngcXU1diQQnSZaWRAKZizXH/A1NT4v9 raR6btC9QUVXNJznxvlQsf0FNrhyaw3TekdmyMmTh86UkabGJS0Dt7/+rRgDxofr gZzQaM3+VETg4bY7tzD76jUHIK+yAWDjp8fSzLQYWeM=; X-AuditID: c1b4fb2d-499ff70000005540-d6-5aa2385d82d0 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 2A.B7.21824.D5832AA5; Fri, 9 Mar 2018 08:31:41 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.82]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0352.000; Fri, 9 Mar 2018 08:31:40 +0100 From: Christer Holmberg To: Roman Shpount , "Dale R. Worley" CC: Mickey Arnold , SIPCORE Thread-Topic: [sipcore] Comments on draft-ietf-sipcore-sip-push-04 - Timer triggered REGISTER requests - Pull request Thread-Index: AQHTt1SywWl5nPEb/UO5+61cRMUEaqPHK+2AgABnhIA= Date: Fri, 9 Mar 2018 07:31:40 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B6C176CF9@ESESSMB109.ericsson.se> <87o9jy2b5s.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.20] Content-Type: multipart/alternative; boundary="_000_D6C804092C5C1christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLIsWRmVeSWpSXmKPExsUyM2K7pW6sxaIog655mhaHWzayW8y4MJXZ 4uuPTWwWL0+UObB4TN7/ldljyZKfTB5Hb85l9rg1pSCAJYrLJiU1J7MstUjfLoErY0/ve9aC tWYVd7dwNjBO1e1i5OSQEDCR2Pt8K2sXIxeHkMBhRoknl6+zQTiLGCX+/p/M3MXIwcEmYCHR /U8bpEFEwEei+/QmZhCbWcBX4tavF0wgtrBAmcSkW2tZIWrKJTbvv8QMYVtJHD23GsxmEVCR 2N2xggXE5hWwltj2YTnU4r2MEjO+HmADSXAKBEqce9YNNpRRQEzi+6k1TBDLxCVuPZnPBHG1 gMSSPeeZIWxRiZeP/4EtFhXQk9hw4jY7RFxR4ur05VC9CRI3GxewQSwWlDg58wnLBEbRWUjG zkJSNgtJGUTcQOL9ufnMELa2xLKFr6FsfYmNX84yzgIGETPQP6dflyIrWcDIsYpRtDi1uDg3 3chYL7UoM7m4OD9PLy+1ZBMjMFIPbvmtu4Nx9WvHQ4wCHIxKPLyRWouihFgTy4orcw8xSnAw K4nwnlq5MEqINyWxsiq1KD++qDQntfgQozQHi5I470lP3ighgfTEktTs1NSC1CKYLBMHp1QD 43JRe3NH/tVeVyUaf11pNeG4+kSTsWxxxE8hFQ9RFhclLb6N0wud3Jd7Wpg8iApNjixhFypf Kie1q31uY7vfl8798neLztg9YDq57LTTd4G7+g1SCvcPf2d5IOXEs7FoAWt0XLFg8q2ghIWi tXHSF6+f5bi+y2VBuGHrpQjzHEt/l1WaWm+UWIozEg21mIuKEwF/oNxn0AIAAA== Archived-At: Subject: Re: [sipcore] Comments on draft-ietf-sipcore-sip-push-04 - Timer triggered REGISTER requests - Pull request 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, 09 Mar 2018 07:31:45 -0000 --_000_D6C804092C5C1christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, >All I said that for the sip PUSH to work, a reasonable minimal Registratio= n duration is required. I wrote that most likely you would not be able to i= mplement re-registrations triggering using push notifications if registrati= on expiration is less then 90 seconds. > >My suggestion was: > >1. If push notifications are used, minimal Registration expiration of 90 s= econds (can be longer) is enforced. >2. Push notification is sent either 30 seconds or 1/3 of the registration = expiration interval before registration expiration, whichever is longer >3. If client want's to re-Register on its own, it needs to send re-registr= ation after 1/2 of the expiration period. > >Finally, I know that push notification content is not currently used for a= nything, but it would be really beneficial to at least be able to send a ne= w nonce value, which will allow to avoid 401 and Registration re-transmissi= on. We decided early that we are not going to send =93SIP information=94 in the= push notifications. I would NOT like to change that at this point. Also, I= have received off-line questions regarding sending other kind of SIP infor= mation in push notifications too, so we could easily open a Pandora=92s box= . Having said that, if someone thinks that using push notifications for trans= porting SIP information he/she can write a draft about that, which consider= s the type of information, the encoding, the privacy/security consideration= s etc etc. Regards, Christer On Thu, Mar 8, 2018 at 10:14 PM, Dale R. Worley > wrote: I wrote a long message, trying to work out which components of the SIP system know which elements of the entire reregistration delay when a UA using sip-push needs to wake up to reregister. Unfortunately, given that the re-REGISTER may easily be rejected with a 401, requiring the UA to send another REGISTER, the process is messy enough there's no way to come up with a neat formula that lets the UA register optimally just before its registration expires. So I'm abandoning that attempt, and suggesting that we specify that the system should always allow "enough" time for the UA to reregister. I believe that the value of 120 seconds has been recommended, and that seems sufficient to me. My assumption is that registrations will be for as long as 1 hour, as in wired SIP systems. OTOH, Roman mentions registrations as short as 90 seconds, which makes handling reregistrations more difficult. I'd like to hear more about that case. Dale --_000_D6C804092C5C1christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <991120F2C98B8B4492E5C16C8B61EA2E@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

>All I said that for the sip PUSH to work, a reasonable minimal Reg= istration duration is required. I wrote that most likely you would not be a= ble to implement re-registrations triggering using push notifications if re= gistration expiration is less then 90 seconds.
>
>My suggestion was:
>
>1. If push notifications are used, minimal Registration expiration= of 90 seconds (can be longer) is enforced.
>2. Push notification is sent either 30 seconds or 1/3 of the regis= tration expiration interval before registration expiration, whichever is lo= nger
>3. If client want's to re-Register on its own, it needs to send re= -registration after 1/2 of the expiration period.
>
>Finally, I know that push notification content is not currently us= ed for anything, but it would be really beneficial to at least be able to s= end a new nonce value, which will allow to avoid 401 and Registration re-tr= ansmission.

We decided early that we are not going to send =93SIP information=94 i= n the push notifications. I would NOT like to change that at this point. Al= so, I have received off-line questions regarding sending other kind of SIP = information in push notifications too, so we could easily open a Pandora=92s box.

Having said that, if someone thinks that using push notifications for = transporting SIP information he/she can write a draft about that, which con= siders the type of information, the encoding, the privacy/security consider= ations etc etc.

Regards,

Christer






On Thu, Mar 8, 2018 at 10:14 PM, Dale R. Worley = <worley@ariadne.= com> wrote:
I wrote a long message, trying to work out which components of the SIP
system know which elements of the entire reregistration delay when a UA
using sip-push needs to wake up to reregister.  Unfortunately, given that the re-REGISTER may easily be rejected with a 401, requiring the UA to send another REGISTER, the process is messy enough there's no way to
come up with a neat formula that lets the UA register optimally just
before its registration expires.

So I'm abandoning that attempt, and suggesting that we specify that the
system should always allow "enough" time for the UA to reregister= .  I
believe that the value of 120 seconds has been recommended, and that
seems sufficient to me.

My assumption is that registrations will be for as long as 1 hour, as in wired SIP systems.  OTOH, Roman mentions registrations as short as 90<= br> seconds, which makes handling reregistrations more difficult.  I'd lik= e
to hear more about that case.

Dale

 --_000_D6C804092C5C1christerholmbergericssoncom_-- From nobody Thu Mar 8 23:34:35 2018 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 108BC124D6C for ; Thu, 8 Mar 2018 23:34:34 -0800 (PST) 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, 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=ericsson.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 NkQXD4wjVqVZ for ; Thu, 8 Mar 2018 23:34:33 -0800 (PST) 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 9FC291201FA for ; Thu, 8 Mar 2018 23:34:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1520580870; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=wzVnpuFjpCIQZXczWvBUVvpHgXz0kUq89YHJLURt5L8=; b=NO7Mf+sTz+QEQ5pYG+6UaYCTEgECc2EwyU6nGOOSyUQzxisPtqspDLDmInnfAZxv XoVMbRaLjsxnyi/a1RNLMUlMG6E6g4YFp9qp2Qsn6tIHMGuTCGDjf2Fo9tbxJnk1 kqzNXCIEqGf9DWRlYK2GHa9cU8YRhelin5/pnBf8y+M=; X-AuditID: c1b4fb25-44ba69c000002d5f-f7-5aa23906ea96 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id DC.23.11615.60932AA5; Fri, 9 Mar 2018 08:34:30 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.82]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0352.000; Fri, 9 Mar 2018 08:34:17 +0100 From: Christer Holmberg To: "Dale R. Worley" CC: "sipcore@ietf.org" Thread-Topic: [sipcore] SIP-push -- Where is the "proxy"? Thread-Index: AQHTt1XgZYFxcgCRtEqguU5KmsZDWqPHlCoA Date: Fri, 9 Mar 2018 07:34:17 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B6C176C9E@ESESSMB109.ericsson.se> <87k1um2aru.fsf@hobgoblin.ariadne.com> In-Reply-To: <87k1um2aru.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.20] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <4A537116CAAB2F488D7E382C662AFE92@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDIsWRmVeSWpSXmKPExsUyM2J7oC6b5aIog6XnVCy+/tjEZvHyRJkD k8fk/V+ZPZYs+ckUwBTFZZOSmpNZllqkb5fAlbFkyW2Wgjn8FW8utTM1MM7m6WLk5JAQMJFo eb2JrYuRi0NI4DCjxKyVy5ggnEWMEh/nLWTpYuTgYBOwkOj+pw1iighoSnQsyAHpZQYyH+3c ywRiCwNVfNq7mhXEFhGwlOhtfs8CYRtJbPs5gxHEZhFQkfh8YwkzyBheAWuJnW11IGEhgTKJ xq6brCBhTgFjib/P/EDCjAJiEt9PrWGC2CQucevJfCaIiwUkluw5zwxhi0q8fPwPbKuogJ7E hhO32SHiihJXpy+H6tWTuDF1ChuEbS1x+slZRghbW2LZwtdgc3gFBCVOznzCMoFRfBaSdbOQ tM9C0j4LSfssJO0LGFlXMYoWpxYn5aYbGeulFmUmFxfn5+nlpZZsYgTG2cEtv1V3MF5+43iI UYCDUYmHt1h7UZQQa2JZcWXuIUYJDmYlEd5TKxdGCfGmJFZWpRblxxeV5qQWH2KU5mBREued I9weJSSQnliSmp2aWpBaBJNl4uCUamDUcj3898jutoupXXJ7GT44napJ0J7I+KRcqZXr0ts3 J3Il7cLncn0UPXGiw9v8icydMtvSbhVVk8Opq64F3C0pfB3w8o+uZ8KJTOYD7ztMW39fUjma fKwj40SgKcPhd+oHHzAZP+II+rXqz9TPj/zZ3/zP2ViXxrT51ZHYr/8VLPdcuHnxrNoXJZbi jERDLeai4kQAqrVsha8CAAA= Archived-At: Subject: Re: [sipcore] SIP-push -- Where is the "proxy"? 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, 09 Mar 2018 07:34:34 -0000 Hi, >Christer Holmberg writes: >> The assumption is that the proxy is able to retrieve the needed >> registration information, either by being in the path of the REGISTER >> (which is the case in all scenarios I am aware of), or retrieving the >> information using some other mechanism. > >It seems to me that the difficult case is not when the proxy retrieves >the registration information, but that the proxy must know when the >re-REGISTER has been sent. > >On one hand, as you say, the proxy can be in the path of the REGISTER. >That requires that the proxy be "near" the registrar, so that any >REGISTER for the AOR will necessarily pass through the proxy as well. >But that pretty much requires that the proxy be attached to the >registrar, as otherwise REGISTERs can take routes to the registrar that >miss the proxy. > >(I particularly imagine the WiFi/cellular use case that Roman mentions, >which has been a huge market target for over 10 years. In that case, >the phone can easily re-REGISTER on an entirely different network than >it was previously registered through.) > >But if the proxy is "near the edge", it needs a way to wait for the >re-REGISTER that doesn't require it to process the re-REGISTER. I think >that this can be done by it subscribing to the 'reg' package for the >AOR, but that requires that the R-URI that it sees in the incoming >request to somehow carry the AOR. > >OTOH, perhaps we will just limit sip-push implementations to require >that the proxy be very near the registrar, if not entirely integrated >with it. In that case, the design can be simplified, probably even more >than it is now. I think what we now have is what the industry is requesting at the moment. Later, if there is a need to have the proxy =B3out-of-path=B2 etc, we can define new parameters etc needed for that in a separate draft. Regards, Christer From nobody Thu Mar 8 23:37:19 2018 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 408051271FD for ; Thu, 8 Mar 2018 23:37:18 -0800 (PST) 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_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=ericsson.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 W2XE39w7bXEJ for ; Thu, 8 Mar 2018 23:37:17 -0800 (PST) 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 ACAF51201FA for ; Thu, 8 Mar 2018 23:37:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1520581022; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=SMsgIHZCOZnNA+4X73bCNue+255W9nqpaKQJYppEf0c=; b=OgGRzxo8FvSjGP6aKG0UrEyl9U80kGZf8iiaAUR0TVwPlEiUielti722gRHaulEm KTmvbqEk0e00uQTilBELOC7YMBlcFYOoOkacntyHJCnhDxAYYeUd+52T71NQ2Hy+ 96aHJ5DU5cv0po7vcC5f6joPa2freBJKnfNB6vfP8D8=; X-AuditID: c1b4fb30-3b1ff70000004778-43-5aa2399e8695 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 4F.38.18296.E9932AA5; Fri, 9 Mar 2018 08:37:02 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.82]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0352.000; Fri, 9 Mar 2018 08:37:02 +0100 From: Christer Holmberg To: Roman Shpount , "Dale R. Worley" CC: SIPCORE Thread-Topic: [sipcore] WGLC: draft-ietf-sipcore-sip-push - SIP combine with push implementation experience Thread-Index: AQHTt1NGl76yt04slk6ZfmoBfrcW86PHLLqAgABoOQA= Date: Fri, 9 Mar 2018 07:37:02 +0000 Message-ID: References: <87r2ou2bmy.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.147] Content-Type: multipart/alternative; boundary="_000_D6C805B02C5D3christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrHIsWRmVeSWpSXmKPExsUyM2J7uO48y0VRBo93WVvMuDCV2eLrj01s Fi9PlDkwe0ze/5XZY8mSn0wet6YUBDBHcdmkpOZklqUW6dslcGU8WrGfpWC2WkXj4S7WBsYJ Cl2MnBwSAiYSpxs/sXcxcnEICRxmlFjVPZERwlnEKNG+dwWQw8HBJmAh0f1PG6RBRMBHovv0 JmYQm1lATuL6h41sICXCAjkS/Xf8QUwRgVyJ1y+4IEwriR/X0kCKWQRUJP4uvsYEYvMKWEvs mbYbbIiQwAFGiU+HxUBsToFAiUcHP7KB2IwCYhLfT61hglgkLnHryXwmiIsFJJbsOc8MYYtK vHz8jxXEFhXQk9hw4jY7yFoJASWJaVvTQExmgQSJc8eUILYKSpyc+YRlAqPoLCRDZyFUzUJS BVFiIPH+3HxmCFtbYtnC11C2vsTGL2cZIWxriZcHX7Ahq1nAyLGKUbQ4tTgpN93ISC+1KDO5 uDg/Ty8vtWQTIzAWD275bbCD8eVzx0OMAhyMSjy8PdqLooRYE8uKK3MPMUpwMCuJ8J5auTBK iDclsbIqtSg/vqg0J7X4EKM0B4uSOO9JT94oIYH0xJLU7NTUgtQimCwTB6dUA+O8E/NWshcX z+BIr++Ncwr8u+9i740bbzqiJwuzn1p++Tffom919Vrn/xd9nRm3MuPsqk11fm+W3y3lcWkJ 9zlnujE55NjB542bLx/XFmmT+FPm6N9S4jgheV2AT8JhEaPf53SOnI85GpvrIpgfHrtW9NjW 0G8qTGIVZzos53yVc5+n9GbJ/ndKLMUZiYZazEXFiQDCHeZCwQIAAA== Archived-At: Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-sip-push - SIP combine with push implementation experience 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, 09 Mar 2018 07:37:18 -0000 --_000_D6C805B02C5D3christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Roman, >I said that we did not allow registrations with expires value less then 90= seconds. Normally much larger expires values (1 hour) were used. > >This was done since if registration expiration interval is too short, ther= e is not enough time to send push notification and for registration transac= tion to complete before registration expires. Just to clarify, do you want me to add some text to the draft? If so, pleas= e provide the text. Personally, the only time I=92ve seen short re-registration intervals is wh= en the re-registrations are used to maintain NAT bindings. But that=92s not= the case here. Regards, Christer On Thu, Mar 8, 2018 at 10:03 PM, Dale R. Worley > wrote: Roman Shpount > writes: > [much interesting and informative material] > As far as Registration expiration is concerned, for SIP-push it is needed > to specify the minimum allowed registration expires interval otherwise > there is not enough time for a SIP-push notification to complete and > registration request to be sent before registration expires. We have used= a > minimum expires value of 90 seconds and failed all registrations with all > lower expires non-zero values. I would expect in situations where the UA desires to power down when it is not in use, it would be very desirable to use long registrations. However, you describe allowing a registration interval of 90 seconds, which seems very short. Can you explain the scenarios in which such a short registration is desirable? Dale --_000_D6C805B02C5D3christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <5DB524468553464B8D054D3FEBE7341C@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi Roman,

>I said that we did not allow registrations with expires value less= then 90 seconds. Normally much larger expires values (1 hour) were used.
>
>This was done since if registration expiration interval is too sho= rt, there is not enough time to send push notification and for registration= transaction to complete before registration expires.

Just to clarify, do you want me to add some text to the draft? If so, = please provide the text.

Personally, the only time I=92ve seen short re-registration intervals = is when the re-registrations are used to maintain NAT bindings. But that=92= s not the case here.

Regards,

Christer





On Thu, Mar 8, 2018 at 10:03 PM, Dale R. Worley = <worley@ariadne.= com> wrote:
Roman Shpount <roman@telurix.com> writes:
> [much interesting and informative material]
> As far as Registration expiration is concerned, for S= IP-push it is needed
> to specify the minimum allowed registration expires interval otherwise=
> there is not enough time for a SIP-push notification to complete and > registration request to be sent before registration expires. We have u= sed a
> minimum expires value of 90 seconds and failed all registrations with = all
> lower expires non-zero values.

I would expect in situations where the UA desires to power down when= it
is not in use, it would be very desirable to use long registrations.
However, you describe allowing a registration interval of 90 seconds,
which seems very short.  Can you explain the scenarios in which such a=
short registration is desirable?

Dale

 --_000_D6C805B02C5D3christerholmbergericssoncom_-- From nobody Mon Mar 12 06:52:18 2018 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 64751126D73 for ; Mon, 12 Mar 2018 06:52:16 -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, 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 UwyGqKMiCi8H for ; Mon, 12 Mar 2018 06:52:14 -0700 (PDT) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (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 D6513124B0A for ; Mon, 12 Mar 2018 06:52:13 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id l191-v6so23350087lfe.1 for ; Mon, 12 Mar 2018 06:52:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=sfcNJasIQXrzso0PZ+0g0udVjwOZC6rhjWdmcfAi/xc=; b=oYv1g04mqJe+YC8kzRMSPqEDVHjELdc6RmHt5n49Xh7kSsTfHOFcUaZh7hIP0pBSOh cg18eEoNpGpBOH8Ge0u9uG9xD18iKiX8jrwSOTv6EAuz7e9y7uBaMIYWumAP4us++B0V aHY8CYgnHdrI/hOShwJw7AA3ESYz/ICe0F+fJRhv0U42GAObvMaIBHMq5IaN2aeHEKlg x16oTSxMh31GYW5OvovLF+eLHgMIlI0V2mVjd4Wk/n4knLng7U5dqvxdHgQrQtwgk407 c+eeVvgR7QGr332PNwOHRBowCipylrwybTHY5Z6KZi8NeOd5moymAr0xTVi17bP+Z2qn 3Lbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=sfcNJasIQXrzso0PZ+0g0udVjwOZC6rhjWdmcfAi/xc=; b=LqU/+/P5b+MIylousx3LbR7QDP7SzXI6PP7xf28QNFkYmRs4F9V9raRJunQSLRDHxP 7/2boLUJaNYK2Ze5OPIJikPTwhxk4tyMdggYVMpIvtm7qQzxOsh0LxnMiAfj4IDw52ah bJ++IfekCvw2szeHqBsMHVQF94/Hnz8cr7UpmvutX7P6v3KOqd9yac8cYpRPYe1LMd0L PQeinA+u9/MPe4+iMxIuH265DO4l83Ul5jw7Z+qsuV5QEbWs91Zb96VNDpDdl9VmDneP oo8egjlziP0gaZ+HLCjPfa/ZqQALhqSA69bkyQeqVPThXodDBGQUoq9nc00rYgc8SQSn io8A== X-Gm-Message-State: AElRT7Eh4R2qlmqDE6bIyDK46LaM85V2k/TLgaBeWcm68xz8fUkPS0Rn xNav8bfNxd/KyGJOZ51643dMNvWMtkOxkWfNG/s1nw== X-Google-Smtp-Source: AG47ELsRbZHkQMENbP4e1v66vt/oMWU+bxDwreWuZeF6xlHZ5iP8456PCh4fTxXrsLlx031oE1xeu+s6DoCBA1Ideuo= X-Received: by 2002:a19:9bd3:: with SMTP id d202-v6mr5396050lfe.125.1520862731798; Mon, 12 Mar 2018 06:52:11 -0700 (PDT) MIME-Version: 1.0 From: Brian Rosen Date: Mon, 12 Mar 2018 13:52:01 +0000 Message-ID: To: SIPCORE Content-Type: multipart/alternative; boundary="000000000000e1c67b0567377250" Archived-At: Subject: [sipcore] -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, 12 Mar 2018 13:52:16 -0000 --000000000000e1c67b0567377250 Content-Type: text/plain; charset="UTF-8" There was a lot of discussion during the WGLC on push. Does everyone think their issues are dealt with satisfactorily I the latest draft? Brian --000000000000e1c67b0567377250 Content-Type: text/html; charset="UTF-8"
There was a lot of discussion during the WGLC on push. Does everyone think their issues are dealt with satisfactorily I the latest draft?

Brian
--000000000000e1c67b0567377250-- From nobody Mon Mar 12 07:14:56 2018 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 8FD4E126C22 for ; Mon, 12 Mar 2018 07:14:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 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_NONE=-0.0001, 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=metaswitch.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 nxV8n_N8VsiY for ; Mon, 12 Mar 2018 07:14:53 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0115.outbound.protection.outlook.com [104.47.42.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4AEC124217 for ; Mon, 12 Mar 2018 07:14:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metaswitch.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Dcrcltz1yDj31tbiukoJLXqSpiYzwIJBKFWIZ9Mhay8=; b=MmbPsUyWDAI3XgFoVKz3kcmw3ZPi4pvF3Ept33Hagx0eG1jx5ZbnM3fcSHgRqhPtxHtu8scnVBWNCd5v5z0pFvkKJ95QayKuE6A8374K3Cz+kTBHYWpu9AB489Uie2A2Wu9+iqXoV98kl5UkQrZHFlf5R850J/lNbVL4CJoRm8g= Received: from CY1PR02MB1262.namprd02.prod.outlook.com (10.163.16.155) by CY1PR02MB1215.namprd02.prod.outlook.com (10.163.16.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.567.14; Mon, 12 Mar 2018 14:14:51 +0000 Received: from CY1PR02MB1262.namprd02.prod.outlook.com ([fe80::d183:cc2a:6116:80df]) by CY1PR02MB1262.namprd02.prod.outlook.com ([fe80::d183:cc2a:6116:80df%14]) with mapi id 15.20.0567.018; Mon, 12 Mar 2018 14:14:51 +0000 From: Mickey Arnold To: Brian Rosen CC: "sipcore@ietf.org" Thread-Topic: [sipcore] -push Thread-Index: AQHTuglY4zNbd40Kj0OgtPHdPC20pqPMo1SQ Date: Mon, 12 Mar 2018 14:14:16 +0000 Deferred-Delivery: Mon, 12 Mar 2018 14:13:55 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Arnold@metaswitch.com; x-originating-ip: [2620:104:4000:206e:dde:d486:bb56:d80d] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY1PR02MB1215; 7:aqNtT2TwtG22eQm6xyZomKtU/kL7eDUJFnC3iq8XBGZkZyenaltRRNNrfw1qF7DR+/+Y98M5zb1iiWS/TZZGs8uuorvV+0RTwGSdZfjSzEDEnh5VBDYwN77T3U8GVuWpJnSVlmOKquVpRerQVB9qqwLQ8zoaCVv/xwEPPAOSZE31LjH/J9soMJd0S378Wnwp0kyORwnfR09LFjtSqjIegnu9r9U006v82nHHG58wRfUKhqxEmEC7KRefblifK0f4 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 80201c72-6104-4c88-9f85-08d588239ef6 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:CY1PR02MB1215; x-ms-traffictypediagnostic: CY1PR02MB1215: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(48300812402016)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(3231220)(944501244)(52105095)(10201501046)(6041310)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123560045)(20161123564045)(6072148)(201708071742011); SRVR:CY1PR02MB1215; BCL:0; PCL:0; RULEID:; SRVR:CY1PR02MB1215; x-forefront-prvs: 06098A2863 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(396003)(39380400002)(366004)(346002)(39850400004)(199004)(189003)(6436002)(7696005)(76176011)(229853002)(3660700001)(3280700002)(25786009)(106356001)(5660300001)(99286004)(6116002)(316002)(790700001)(478600001)(72206003)(14454004)(2900100001)(46003)(6506007)(6306002)(54896002)(186003)(8936002)(55016002)(9686003)(81166006)(5250100002)(8676002)(2906002)(74316002)(2950100002)(4326008)(102836004)(6246003)(68736007)(6916009)(97736004)(53546011)(81156014)(86362001)(6666003)(105586002)(9326002)(33656002)(53936002)(7736002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR02MB1215; H:CY1PR02MB1262.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: metaswitch.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: mywXCzbWmyeCWuMrJK0qNxw6KntKuw+ekhOakTAg0ugYrn0hR7tCqzmoOJgEKFhplnrHsFvsyeRW488FL9Zxy9IbY0lY6P8TFR/vkE49uim+YiLqkFvRn3WF+Z7Bk6Ch4WE1Lz98UzXsW+TCgfXKnMv38hBVnKMAiGzm/gFpzMAxo+qC7plnwVN1wWU4vZx9gQnIHj+9dAQlKU5hFhvXYTzShml+VxZlAXVkN0/EWoHrpDnnqhaMvWm6Kix/SlrET6/8mekxuIL4/QCSq0gBDUYfE8g2vMG/aIVPUohBKd2ZOL8RNkCxsaRg/Yz/jKdRA0Gdc8qblEjdE1zX42dtGQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR02MB1262C4794FB7B433495C3961E9D30CY1PR02MB1262namp_" MIME-Version: 1.0 X-OriginatorOrg: metaswitch.com X-MS-Exchange-CrossTenant-Network-Message-Id: 80201c72-6104-4c88-9f85-08d588239ef6 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Mar 2018 14:14:51.3113 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR02MB1215 Archived-At: Subject: Re: [sipcore] -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, 12 Mar 2018 14:14:55 -0000 --_000_CY1PR02MB1262C4794FB7B433495C3961E9D30CY1PR02MB1262namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQnJpYW4sDQoNClRoZSBsYXRlc3QgZHJhZnQgYWRkcmVzc2VzIGFsbCBpc3N1ZXMgYW5kIGNv bmNlcm5zIEkgcmFpc2VkIGR1cmluZyBXR0xDLg0KDQpUaGFua3MsIE1pY2tleQ0KDQpGcm9tOiBz aXBjb3JlIFttYWlsdG86c2lwY29yZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQnJp YW4gUm9zZW4NClNlbnQ6IDEyIE1hcmNoIDIwMTggMTM6NTINClRvOiBTSVBDT1JFIDxzaXBjb3Jl QGlldGYub3JnPg0KU3ViamVjdDogW3NpcGNvcmVdIC1wdXNoDQoNClRoZXJlIHdhcyBhIGxvdCBv ZiBkaXNjdXNzaW9uIGR1cmluZyB0aGUgV0dMQyBvbiBwdXNoLiBEb2VzIGV2ZXJ5b25lIHRoaW5r IHRoZWlyIGlzc3VlcyBhcmUgZGVhbHQgd2l0aCBzYXRpc2ZhY3RvcmlseSBJIHRoZSBsYXRlc3Qg ZHJhZnQ/DQoNCkJyaWFuDQo= --_000_CY1PR02MB1262C4794FB7B433495C3961E9D30CY1PR02MB1262namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBz cGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBs aS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7 DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5 bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2Ug V29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIu MHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iIzA1NjNDMSIgdmxpbms9 IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGkgQnJpYW4s PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPlRoZSBsYXRlc3QgZHJhZnQgYWRkcmVzc2VzIGFsbCBpc3N1ZXMgYW5kIGNv bmNlcm5zIEkgcmFpc2VkIGR1cmluZyBXR0xDLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaGFua3MsIE1pY2tleTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBzaXBjb3JlIFtt YWlsdG86c2lwY29yZS1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5Ccmlh biBSb3Nlbjxicj4NCjxiPlNlbnQ6PC9iPiAxMiBNYXJjaCAyMDE4IDEzOjUyPGJyPg0KPGI+VG86 PC9iPiBTSVBDT1JFICZsdDtzaXBjb3JlQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9i PiBbc2lwY29yZV0gLXB1c2g8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5U aGVyZSB3YXMgYSBsb3Qgb2YgZGlzY3Vzc2lvbiBkdXJpbmcgdGhlIFdHTEMgb24gcHVzaC4gRG9l cyBldmVyeW9uZSB0aGluayB0aGVpciBpc3N1ZXMgYXJlIGRlYWx0IHdpdGggc2F0aXNmYWN0b3Jp bHkgSSB0aGUgbGF0ZXN0IGRyYWZ0PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5CcmlhbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_CY1PR02MB1262C4794FB7B433495C3961E9D30CY1PR02MB1262namp_-- From nobody Mon Mar 12 07:34:28 2018 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 9A19B126DC2 for ; Mon, 12 Mar 2018 07:34:26 -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, FREEMAIL_FROM=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 BtMs6YZbSwni for ; Mon, 12 Mar 2018 07:34:25 -0700 (PDT) Received: from mail-ot0-x232.google.com (mail-ot0-x232.google.com [IPv6:2607:f8b0:4003:c0f::232]) (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 5CC7B124217 for ; Mon, 12 Mar 2018 07:34:25 -0700 (PDT) Received: by mail-ot0-x232.google.com with SMTP id y11so15479629otg.0 for ; Mon, 12 Mar 2018 07:34:25 -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=fWvaoYIxOMPpsrB2C7KQdRsR/nD7TanGc3lOwleXYTg=; b=LxZHfyVmK43MDq1n1UNVoyPKc0DmD+/OSK5JO7sjWGPKPW+zWVDDcLnnRKkQDJc+yi XVwXOoZ+ubN5Kb9sdL4aImnSf4CfqkZ8AqzIMgn5YhKo+MhoIQBpfK+3muZdkBTFB0Ww DhQTSYXqNSKImbGSyLukdWqzaMv0GJah0lNHf1YbUxVapHv477A1DiwthiEcyIw+3dXv zJBw0qIl2fA5Z+lZh/R92E9HLbiBJD7yLKnoxOt9qzKjMT5hK7SZgHfA1QlW2dWPJxHF gKw44Bf85RIM/UjMqr5hA9K1sHOHKmX7BKoHXBOFvaG0/vjaXcnsWEJJ1j0W8lK1G/Qs 1i/g== 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=fWvaoYIxOMPpsrB2C7KQdRsR/nD7TanGc3lOwleXYTg=; b=alOphd5bn1j8JQla+sccvI66rJ8wxOAuEkYQ4cAu2diZ+wrMqwUAnXJnAx0OeGQmSa l7WCJhB81Gw4xwWBJx2bIIlBW7oZKG9hDWeMrq0lhLZ7LGnh9X4sHC8mx5X4DBcoXg5l elGpxrClfKqUkcVWPsVh2b6i297rpA2JwjjutT8mnJa4j+dRHGplYGCR0JfP9TRJX7ZA 852vE71iDl7q1Fuyp32f8P+hT1zTvM7YlY7ITZrPoL862jP99eE/Yw71T5XVbNbnnVBG KHkFyrZY/bzpC/MlQs4v/Cv4BOQIzbDQJBa4RhlkL9qwQIQ8rtB5OCOOaXXitchaESkT eKKg== X-Gm-Message-State: AElRT7Ff9JXtmmth/v7Ek1OPGIL76daTflkO+wZZIExqNnXprnHq0bdw 7NEAx1Q33UCuWPrn/cffbSrcwj23mmbhDd/LLWdndw== X-Google-Smtp-Source: AG47ELuygjjg+OVu0M0naimoHcDZE7LrPc0M4YTE+6kjF21aHWegJGfPNwJYRF5tKfTS3PI1LxEZK9wOISWN82IxsEk= X-Received: by 10.157.32.114 with SMTP id n105mr5202292ota.394.1520865264656; Mon, 12 Mar 2018 07:34:24 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:1055:0:0:0:0:0 with HTTP; Mon, 12 Mar 2018 07:34:23 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Mon, 12 Mar 2018 14:34:23 +0000 Message-ID: To: Brian Rosen Cc: SIPCORE Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [sipcore] -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, 12 Mar 2018 14:34:27 -0000 My concerns about there only being proprietary push service providers remain. On Mon, Mar 12, 2018 at 1:52 PM, Brian Rosen wrote: > There was a lot of discussion during the WGLC on push. Does everyone think > their issues are dealt with satisfactorily I the latest draft? > > Brian > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Mon Mar 12 08:02:21 2018 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 852EC126D05 for ; Mon, 12 Mar 2018 08:02:19 -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 wT5ETF_gxoqX for ; Mon, 12 Mar 2018 08:02:18 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::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 C678F1201FA for ; Mon, 12 Mar 2018 08:02:17 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id o25so11703228qkl.7 for ; Mon, 12 Mar 2018 08:02:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PrrQCKQHMWPeDoK0i1Pvj87ybAtqZkUs/q1MwVQQq6c=; b=MYmvNozB+jH3av6425pAJSPhaz2vm8iT+2ocDX8hWWhpdDN8J4SlOLfiwssZ7qzoxb 3989+Qrz+epyG0C6C7SDdyhnok4ZmENHb2tkMWCSY1P31IIguh2kYlhfa1rypp4Ci/56 f+WGryxHD/hnB+VWdbOnLQlGNZulTFjl48UD1CJxKNgiMlnJ63GQMoqbjqOfgQ/uHMjK LVsrmkmPnF3Q4YYodMQb9bN3iChWH2cMqxi6Jwqnb8wsUS6w3wj9gb9Ht5r4DxouVlLU 4xzMyTxixXraBWH3pn9OrcjwehZnuojMOlQ6Ez6d69zS5SLNMreo+2Buxy4QEQZBf4+H damg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PrrQCKQHMWPeDoK0i1Pvj87ybAtqZkUs/q1MwVQQq6c=; b=EwQhGqx7QvSt579tDf8VrjA+UvQSCFLLL6KMS/ocsXJJ8a3gSTbNcpzIarRZVtefI+ iHxbseRyIyqXiET3fcnzXa0d0ads9uz9WtJa0pbbV/dTEaD21ht2FbQxvmqSvACGRLhW Dn6bGdyHY0sNsYohIR7UbRRNfKrqGZdtDxc4fBF/z+XjEkRBhlc7yzcw8d9Au9r7MR93 48PNLmE/O1suGs31wvcotQHTlkUM5qv4DPDpxUb2oNeRMwm3BYuaVO9m8CY246pI1+tW 8ENAUYbb+Kk1DpqPxY9NS59Yg6XNN91QdJP9cxzy1MAk5sJtABOP5dHvvnDcYdJwPm3P Ef6g== X-Gm-Message-State: AElRT7GWmCm2ohY1LavgCY0TpyLncx3V6rZgdKNLCwfOV9nO+OkMOFaX vc4riQzKntG7RRQkoqsbORuoF5LvwBg= X-Google-Smtp-Source: AG47ELsgM3btlMsNS6ejfnmkB7JeGH57hW2msgXj5lufvR/l/1vjk/tgXWufkpCj5I7emnGLSiI9NA== X-Received: by 10.55.118.6 with SMTP id r6mr12472231qkc.211.1520866936809; Mon, 12 Mar 2018 08:02:16 -0700 (PDT) Received: from [192.168.0.21] (cpe-66-108-233-234.nyc.res.rr.com. [66.108.233.234]) by smtp.gmail.com with ESMTPSA id s31sm5523403qts.42.2018.03.12.08.02.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Mar 2018 08:02:15 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Brian Rosen In-Reply-To: Date: Mon, 12 Mar 2018 11:02:25 -0400 Cc: SIPCORE Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Martin Thomson X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [sipcore] -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, 12 Mar 2018 15:02:19 -0000 Can we explore that a bit: The =E2=80=9Cnon-proprietary=E2=80=9D that exists is RFC8030. But the implementations of 8030 would need other things to work. So to make sip-push work with 8030 would mean a bunch of other = mechanisms. Is there actual need (i.e. implementations) for 8030 based push? Otherwise, while I understand your concern, it would seem that someone = other than Christer should, if they want to, write a draft that would = extend push to work with 8030 in practical implementations, pulling in = other work to make it actually work. Or did I miss something? My writeup will reflect this objection, so the = IESG will be aware of it. Brian > On Mar 12, 2018, at 10:34 AM, Martin Thomson = wrote: >=20 > My concerns about there only being proprietary push service providers = remain. >=20 > On Mon, Mar 12, 2018 at 1:52 PM, Brian Rosen = wrote: >> There was a lot of discussion during the WGLC on push. Does everyone = think >> their issues are dealt with satisfactorily I the latest draft? >>=20 >> Brian >>=20 >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >>=20 From nobody Mon Mar 12 08:11:56 2018 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 63DE11205F0 for ; Mon, 12 Mar 2018 08:11:54 -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, FREEMAIL_FROM=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 El4Ru8NlaMzh for ; Mon, 12 Mar 2018 08:11:53 -0700 (PDT) Received: from mail-ot0-x234.google.com (mail-ot0-x234.google.com [IPv6:2607:f8b0:4003:c0f::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 D2CE21201FA for ; Mon, 12 Mar 2018 08:11:52 -0700 (PDT) Received: by mail-ot0-x234.google.com with SMTP id m22so15596253otf.10 for ; Mon, 12 Mar 2018 08:11:52 -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=BcgCmAcXAO19YWpo1Mje+FF30uvaZtv6cla8HMtStb8=; b=Wfobp0xY8RtgmiO+xPYfJXGwp226p2SwF3mzbD7K3sA1HRU/Q2m8XqvGTRsKzuIROf y5m2V+n8Bk2lJeDQ9y9IAG/vF2rmrxRDUHWQy/WJguLarZIR7n0yXu2caehrFbiGzySk /lRQvDI9GgWw0FFkRZpAsnjCyD3vrKNbQppL8e78e56RO94j9Ow1CBYehWtF1oPnULB9 frIoe2d9YSKT7M0kZFxjY86jWHB6+i2hs1urb1asBV2EMUnW1bRDCo7PlFtkPHEBYQ/j dSi2qXsig5SOfWyyH2ebuyQuVaMlY4cRTtMHTePqBaQDBc8sdjlV/AW8EyaG5uFIjv3S Yi4A== 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=BcgCmAcXAO19YWpo1Mje+FF30uvaZtv6cla8HMtStb8=; b=CF/HNeClpmbifgCLP1z2fEN76xqkrrBXFn98O6PWBKTjXTTyrpTW29uhbOwjAKCcao MwAr9ov8VccWlCWPSoD12g6fQHT4nlyFUi47TxHJKe3a08Z/442Fa1o4K5jpWna3pg9p 1tMb1HDeo4RbUxJtSD/wCRWirKAzmx5puF3+/zDxM/8w2XEUY9fUYP0/vkAUoEA0+e5V wRJN9cr9cZJrJLL8YxSfy9wXHmCrpRabIAdlZk+QnUuFPqjvabsA0jpUgD+1bvvh860g adYMZ+TUVN9pwEZdI0N3MfvcZvcJIjWpDY1hXF7rooU/IGd4F0Xb223iyYhZcnXdfbai by9w== X-Gm-Message-State: AElRT7HRzGmscvU593bkVuSPN1opyuQEXWaAamJl65hleA7RvkYfXltE AVRzw9mW3h0+a/t0oNtUsRQ8RH1D7F2HSDnQmlCLsw== X-Google-Smtp-Source: AG47ELsD6tQD+LOkGfvatyvdTlj28Y0nq6e384jPt47nxBuCFO/l1ELioH0C4MmO80i7zayqb0+H7D95Wo+2N6UVCnE= X-Received: by 10.157.12.229 with SMTP id o34mr5962369otd.352.1520867512034; Mon, 12 Mar 2018 08:11:52 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:1055:0:0:0:0:0 with HTTP; Mon, 12 Mar 2018 08:11:51 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Mon, 12 Mar 2018 15:11:51 +0000 Message-ID: To: Brian Rosen Cc: SIPCORE Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [sipcore] -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, 12 Mar 2018 15:11:54 -0000 You could implement a SIP UA in a browser. I don't know whether this WebRTC thing will take off, but it seems both plausible and useful. What "other things" do you refer to specifically? I think that it just wor= ks. The pieces that 8030 needs are partly in place. Christer added a VAPID reference. He removed the additional elements necessary to convey keys. I think that was because this is only a poke and the poke carries no information (and therefore, by 8030, does not need all the encryption bits). I object pretty strongly to this work defining proprietary-only solutions when a standardized solution exists. On Mon, Mar 12, 2018 at 3:02 PM, Brian Rosen wrote: > Can we explore that a bit: > The =E2=80=9Cnon-proprietary=E2=80=9D that exists is RFC8030. > But the implementations of 8030 would need other things to work. > So to make sip-push work with 8030 would mean a bunch of other mechanisms= . > > Is there actual need (i.e. implementations) for 8030 based push? > > Otherwise, while I understand your concern, it would seem that someone ot= her than Christer should, if they want to, write a draft that would extend = push to work with 8030 in practical implementations, pulling in other work = to make it actually work. > > Or did I miss something? My writeup will reflect this objection, so the = IESG will be aware of it. > > Brian > >> On Mar 12, 2018, at 10:34 AM, Martin Thomson = wrote: >> >> My concerns about there only being proprietary push service providers re= main. >> >> On Mon, Mar 12, 2018 at 1:52 PM, Brian Rosen wrote: >>> There was a lot of discussion during the WGLC on push. Does everyone th= ink >>> their issues are dealt with satisfactorily I the latest draft? >>> >>> Brian >>> >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> > From nobody Mon Mar 12 08:24:36 2018 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 48D96124217 for ; Mon, 12 Mar 2018 08:24:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 xBVGg5Fk4pfk for ; Mon, 12 Mar 2018 08:24:33 -0700 (PDT) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (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 7A17C1201FA for ; Mon, 12 Mar 2018 08:24:33 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id a23so7824008qtm.4 for ; Mon, 12 Mar 2018 08:24:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Vho5wWJWodBbBGJ1Rmu1taCZGZwmDkEuU///NM1YHq8=; b=c8h+pcN684iaZMLObNC7+BDp0wNllJPXRQlwlPlFIb8ylWmxsoNE4iBG7nGVnC7o9Y zGf/KAC60PonxyRRFczrDQ1gR8cVRkUtTYXjJMSQCWvNONtkEXqs5a8XuxMW9qoRRRK0 cJ1Q0k7o2jVqstmy2IlbfEsETqbuKoLgoIyAvLwySvczCvbf4Ze+8Aq7DB0LbarXNqVX kEVa5AQU9Qxji+H+m1RAmKQgTrJtSASmnvl+uTVnWZ2md+JusfCfy88LhfSumXpVAlQN Ddyk4xpprxX64u2X8jF0KizGeP6x1kHgScxt5f03nGVutpL1rJOjch6jNzIpMay+SMiC q5AQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Vho5wWJWodBbBGJ1Rmu1taCZGZwmDkEuU///NM1YHq8=; b=Li9GMtSUEFmaz89jReo/XVzKWif1n/5yfvJBUULT6gOoNPd/ZoHY2ljuaZ+H9RHUs7 zTEjdaT1jDvhi8nwp0WJko1RVkzpC3dGeWW1+uvmJI8CQMzd12oeVUZkRYpuLYnuEwLb jXPVG7mFW8r57ifkv8SMXiLVtG/l/K1qlDfh5xSwOOCWdbhdyYYAe8PxF4Nf0sC8K++R 7wicbzh2q9z6Mcb9r4C1a1Ur2Sq9jvTLpvxey6zIc+kjwXuBoWyfI5JIa4SqaLtwDeB6 kF8Xu9q3R+SxCj+peUhDzlvepPzNtV/9jje8yvaJCYPvI/OUot3nVvfjf9ibtm3HyDnj ee9Q== X-Gm-Message-State: AElRT7H+cIqFvLs4uMb8gP12tmdY+EuIF1ufBKScV4Jo+garqcgUT+us JdgNlxXn24wAt1hR7EWlMcnUwLz9upI= X-Google-Smtp-Source: AG47ELv8MhXAU1pr3IT6xaIXxqJsuOBCKOcFpEibqci1MTvwH9gpBSTM50Vz1k3+MRvk4CxUca8fiA== X-Received: by 10.200.46.51 with SMTP id r48mr4280645qta.8.1520868272444; Mon, 12 Mar 2018 08:24:32 -0700 (PDT) Received: from [192.168.0.21] (cpe-66-108-233-234.nyc.res.rr.com. [66.108.233.234]) by smtp.gmail.com with ESMTPSA id k67sm5526607qkh.95.2018.03.12.08.24.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Mar 2018 08:24:31 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Brian Rosen In-Reply-To: Date: Mon, 12 Mar 2018 11:24:41 -0400 Cc: SIPCORE Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Martin Thomson X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [sipcore] -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, 12 Mar 2018 15:24:35 -0000 My confusion: the reference was to RFC8292, but that=E2=80=99s VAPID and = it=E2=80=99s in there. Given VAPID is covered, what would we need beyond an explicit reference = to 8030? Brian > On Mar 12, 2018, at 11:11 AM, Martin Thomson = wrote: >=20 > You could implement a SIP UA in a browser. I don't know whether this > WebRTC thing will take off, but it seems both plausible and useful. >=20 > What "other things" do you refer to specifically? I think that it = just works. >=20 > The pieces that 8030 needs are partly in place. Christer added a > VAPID reference. He removed the additional elements necessary to > convey keys. I think that was because this is only a poke and the poke > carries no information (and therefore, by 8030, does not need all the > encryption bits). >=20 > I object pretty strongly to this work defining proprietary-only > solutions when a standardized solution exists. >=20 > On Mon, Mar 12, 2018 at 3:02 PM, Brian Rosen = wrote: >> Can we explore that a bit: >> The =E2=80=9Cnon-proprietary=E2=80=9D that exists is RFC8030. >> But the implementations of 8030 would need other things to work. >> So to make sip-push work with 8030 would mean a bunch of other = mechanisms. >>=20 >> Is there actual need (i.e. implementations) for 8030 based push? >>=20 >> Otherwise, while I understand your concern, it would seem that = someone other than Christer should, if they want to, write a draft that = would extend push to work with 8030 in practical implementations, = pulling in other work to make it actually work. >>=20 >> Or did I miss something? My writeup will reflect this objection, so = the IESG will be aware of it. >>=20 >> Brian >>=20 >>> On Mar 12, 2018, at 10:34 AM, Martin Thomson = wrote: >>>=20 >>> My concerns about there only being proprietary push service = providers remain. >>>=20 >>> On Mon, Mar 12, 2018 at 1:52 PM, Brian Rosen = wrote: >>>> There was a lot of discussion during the WGLC on push. Does = everyone think >>>> their issues are dealt with satisfactorily I the latest draft? >>>>=20 >>>> Brian >>>>=20 >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>=20 >>=20 From nobody Mon Mar 12 08:28:27 2018 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 7E9E4126D05 for ; Mon, 12 Mar 2018 08:28:25 -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, FREEMAIL_FROM=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 OrDCroo6dN33 for ; Mon, 12 Mar 2018 08:28:15 -0700 (PDT) Received: from mail-ot0-x236.google.com (mail-ot0-x236.google.com [IPv6:2607:f8b0:4003:c0f::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 DECD1120227 for ; Mon, 12 Mar 2018 08:28:14 -0700 (PDT) Received: by mail-ot0-x236.google.com with SMTP id 108so15670441otv.3 for ; Mon, 12 Mar 2018 08:28:14 -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=uIP80G+sJv27Z/IZ0jXC+zewVrCtG6myBryOtchCnJc=; b=Rl3sFxbUxwHfiO/6J7xjhjZF6mZmXpNuWeSxRa4OlICuYMX0OkloP7L8X50EEVxfV0 fmWypP2cseVREk5BfRyuOZDujW+KgUP8OjpeLeRpmpge+DCRcJn7EPNgvCf/QalPMMiJ 6ZiScP6ZIilKntwYw42oy7MqBWIjHSvROJovQBIVsKbJCFU/n5XOGPmvx7i1prpPxmeu FSh6R1qbV2KA1Ozu92+IF87TXew7lNxpLs1IgOP6OjULPD7s6Czaw52KgmGIB6SENPaF Kylw++t3jUbU8pna6KQCZ+Hrp1z52qaAr4u0rkM5KHNx3SnxEe+cpt3OtIb1jaBh+bXy zqsg== 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=uIP80G+sJv27Z/IZ0jXC+zewVrCtG6myBryOtchCnJc=; b=Atgi3fe/QTef+D+I7CzQenqiBRDIYxiSN79U5IHZXuFkIuqM7+MOrAIgeydZ22kfoi AI72O7aYs8dv4Js24TUZZAyA7MtkRJFlWo5kpQXWQYU16exqtwAKSR5dXMPHgNoFOlWr 3KTJQK0exrT5RbC3K7gHvyui4L88/V/xJQ+sQigpmXodJ7mNSvAcsmroMkQJS98zDB3r aAB3H89xSbVK94ugu2E/6gN38IkMcB04hs+bmRWQns+UNeZcuqz3zcLTdsOZXlZoTbhl vTV37DbsjtA23ubiKGeBtHQKJF3ZEqLGsa8hnSCOnpOIH1yTdEuvJ/1YD8tSB7lasGca UB6Q== X-Gm-Message-State: AElRT7Gxa3d5y2wYXlXsUc3zCJatyLV1A2aMytGslfrjG6tMLW9XWo8Y 6ggHLqSElP0GNr26cAb9XDUMOQWAr1TaB/8YYjqXrxMC X-Google-Smtp-Source: AG47ELv+ktMJ6Ae7YF3C5z2XgWJVa5zMWP2W26awiJwHGvJeEu7HnOxOublZerpu/yJK79eLQGP+zC2YJUng1Axiq40= X-Received: by 10.157.41.99 with SMTP id d90mr5297587otb.396.1520868494292; Mon, 12 Mar 2018 08:28:14 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:1055:0:0:0:0:0 with HTTP; Mon, 12 Mar 2018 08:28:13 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Mon, 12 Mar 2018 15:28:13 +0000 Message-ID: To: Brian Rosen Cc: SIPCORE Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [sipcore] -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, 12 Mar 2018 15:28:25 -0000 On Mon, Mar 12, 2018 at 3:24 PM, Brian Rosen wrote: > My confusion: the reference was to RFC8292, but that=E2=80=99s VAPID and = it=E2=80=99s in there. > > Given VAPID is covered, what would we need beyond an explicit reference t= o 8030? A definition for pn-provider is probably all right now. Plus a paragraph of text to support it. I'd probably add an explanation for why the encryption pieces aren't needed. From nobody Mon Mar 12 08:30:13 2018 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 C8A49126D05 for ; Mon, 12 Mar 2018 08:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 o2OxNIVK_Elm for ; Mon, 12 Mar 2018 08:30:10 -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 0818C120227 for ; Mon, 12 Mar 2018 08:30:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1520868608; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=4zH4e0XS2jcePNnAm7tY19OeRuflXgc07CeWJlpK6c4=; b=fL8pOAZmZOqoCrxjGnBjV+Cm/CZQismwn/2ITyVjyWB42ujrVOYSckL4fO+NBvB1 gtE3Kjyu1eNovAZgWR5ccivpj7zuaSJif+w9/9QEy/Jl4ibtqAzERcGc6iYNYrbF It+osYEdq7o+arwwpHEzyWFUwuqQglLCx/OA+njnISc=; X-AuditID: c1b4fb30-799639c000004778-95-5aa69d006301 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 61.05.18296.00D96AA5; Mon, 12 Mar 2018 16:30:08 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.172]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0382.000; Mon, 12 Mar 2018 16:30:07 +0100 From: Christer Holmberg To: Martin Thomson , Brian Rosen CC: SIPCORE Thread-Topic: [sipcore] -push Thread-Index: AQHTuglY2BEOxxfeoUSBwdrzyq2mqaPMmZeAgAAH1YCAAAKjgIAAE3cQ Date: Mon, 12 Mar 2018 15:30:06 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B6C1F1FC6@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.163] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpikeLIzCtJLcpLzFFi42KZGbFdXZdh7rIogxeXRSye3p/GZnHtzD9G i68/NrE5MHvc//aX3WPnrLvsHkuW/GQKYI7isklJzcksSy3St0vgyjh4ZhtLwQzZitUvVrM0 MO6Q6WLk5JAQMJGYNGk7WxcjF4eQwGFGiU+bzjFCOEsYJeZv/QGU4eBgE7CQ6P6nDdIgIuAn 0d74gxnEZhaQk7j+YSNYibCAjMS5Z0IQJbISDYdXsEPYbhK7ls9iASlhEVCV6J4XDxLmFfCV WLHxJTvEpmlMEh23+8FqOAUCJWbsNgCpYRQQk/h+ag0TxCZxiVtP5jNBnCwgsWTPeWYIW1Ti 5eN/rBC2ksTyaVvYQcYwC2hKrN+lD9GqKDGl+yE7xFpBiZMzn7BMYBSdhWTqLISOWUg6ZiHp WMDIsopRtDi1OCk33chIL7UoM7m4OD9PLy+1ZBMjMGYObvltsIPx5XPHQ4wCHIxKPLx97cui hFgTy4orcw8xSnAwK4nw+k8FCvGmJFZWpRblxxeV5qQWH2KU5mBREuc96ckbJSSQnliSmp2a WpBaBJNl4uCUamDsTXHZeU/7vNXE06zqJ5PCU4MtYp49Kb18nkXR3X6WTLZK3IboCv38gD3b Vjf+bnY9doX52zwuvUCxj///2LEdOmshJz3N4ISrp2Tzs0mqWQFJKxcosOWabWn+tPyoiGOH SuHBt1G8eW12LBH7HQq2XKi/3LNjxXGp6OIcC64vXYy3z3UVFiuxFGckGmoxFxUnAgDWZih3 lQIAAA== Archived-At: Subject: Re: [sipcore] -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, 12 Mar 2018 15:30:12 -0000 SGkgTWFydGluLA0KDQpZb3UgcHJldmlvdXNseSBzYWlkICJGQ00gc3VwcG9ydHMgUkZDIDgwMzAi LiBJIHRob3VnaHQgdGhhdCBtZWFudCB0aGF0IEZDTSBpcyBiYXNlZCBvbiBSRkMgODAzMCwgaS5l LiBhIHN0YW5kYXJkaXplZCBzb2x1dGlvbiA6KQ0KDQpCdXQsIEkgaGF2ZSBubyBwcm9ibGVtIHRv IGluY2x1ZGUgYSByZWdpc3RyYXRpb24gZm9yIGEgZ2VuZXJpYyAiUkZDODAzMCIgc2VydmljZS4N Cg0KU2luY2UgeW91IGFyZSB0aGUgYXV0aG9yIG9mIFJGQyA4MDMwLCBhcmUgeW91IGFibGUgdG8g cHV0IHByb3ZpZGUgdGhlIHJlZ2lzdHJhdGlvbiBpbmZvcm1hdGlvbj8gU2VlIHNlY3Rpb25zIDkg YW5kIDEwIGZvciBleGFtcGxlcy4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQoNCg0KDQoN Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBzaXBjb3JlIFttYWlsdG86c2lwY29y ZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWFydGluIFRob21zb24NClNlbnQ6IDEy IE1hcmNoIDIwMTggMTc6MTINClRvOiBCcmlhbiBSb3NlbiA8YnJAYnJpYW5yb3Nlbi5uZXQ+DQpD YzogU0lQQ09SRSA8c2lwY29yZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbc2lwY29yZV0gLXB1 c2gNCg0KWW91IGNvdWxkIGltcGxlbWVudCBhIFNJUCBVQSBpbiBhIGJyb3dzZXIuICBJIGRvbid0 IGtub3cgd2hldGhlciB0aGlzIFdlYlJUQyB0aGluZyB3aWxsIHRha2Ugb2ZmLCBidXQgaXQgc2Vl bXMgYm90aCBwbGF1c2libGUgYW5kIHVzZWZ1bC4NCg0KV2hhdCAib3RoZXIgdGhpbmdzIiBkbyB5 b3UgcmVmZXIgdG8gc3BlY2lmaWNhbGx5PyAgSSB0aGluayB0aGF0IGl0IGp1c3Qgd29ya3MuDQoN ClRoZSBwaWVjZXMgdGhhdCA4MDMwIG5lZWRzIGFyZSBwYXJ0bHkgaW4gcGxhY2UuICBDaHJpc3Rl ciBhZGRlZCBhIFZBUElEIHJlZmVyZW5jZS4gIEhlIHJlbW92ZWQgdGhlIGFkZGl0aW9uYWwgZWxl bWVudHMgbmVjZXNzYXJ5IHRvIGNvbnZleSBrZXlzLiBJIHRoaW5rIHRoYXQgd2FzIGJlY2F1c2Ug dGhpcyBpcyBvbmx5IGEgcG9rZSBhbmQgdGhlIHBva2UgY2FycmllcyBubyBpbmZvcm1hdGlvbiAo YW5kIHRoZXJlZm9yZSwgYnkgODAzMCwgZG9lcyBub3QgbmVlZCBhbGwgdGhlIGVuY3J5cHRpb24g Yml0cykuDQoNCkkgb2JqZWN0IHByZXR0eSBzdHJvbmdseSB0byB0aGlzIHdvcmsgZGVmaW5pbmcg cHJvcHJpZXRhcnktb25seSBzb2x1dGlvbnMgd2hlbiBhIHN0YW5kYXJkaXplZCBzb2x1dGlvbiBl eGlzdHMuDQoNCk9uIE1vbiwgTWFyIDEyLCAyMDE4IGF0IDM6MDIgUE0sIEJyaWFuIFJvc2VuIDxi ckBicmlhbnJvc2VuLm5ldD4gd3JvdGU6DQo+IENhbiB3ZSBleHBsb3JlIHRoYXQgYSBiaXQ6DQo+ IFRoZSDigJxub24tcHJvcHJpZXRhcnnigJ0gdGhhdCBleGlzdHMgaXMgUkZDODAzMC4NCj4gQnV0 IHRoZSBpbXBsZW1lbnRhdGlvbnMgb2YgODAzMCB3b3VsZCBuZWVkIG90aGVyIHRoaW5ncyB0byB3 b3JrLg0KPiBTbyB0byBtYWtlIHNpcC1wdXNoIHdvcmsgd2l0aCA4MDMwIHdvdWxkIG1lYW4gYSBi dW5jaCBvZiBvdGhlciBtZWNoYW5pc21zLg0KPg0KPiBJcyB0aGVyZSBhY3R1YWwgbmVlZCAoaS5l LiBpbXBsZW1lbnRhdGlvbnMpIGZvciA4MDMwIGJhc2VkIHB1c2g/DQo+DQo+IE90aGVyd2lzZSwg d2hpbGUgSSB1bmRlcnN0YW5kIHlvdXIgY29uY2VybiwgaXQgd291bGQgc2VlbSB0aGF0IHNvbWVv bmUgb3RoZXIgdGhhbiBDaHJpc3RlciBzaG91bGQsIGlmIHRoZXkgd2FudCB0bywgd3JpdGUgYSBk cmFmdCB0aGF0IHdvdWxkIGV4dGVuZCBwdXNoIHRvIHdvcmsgd2l0aCA4MDMwIGluIHByYWN0aWNh bCBpbXBsZW1lbnRhdGlvbnMsIHB1bGxpbmcgaW4gb3RoZXIgd29yayB0byBtYWtlIGl0IGFjdHVh bGx5IHdvcmsuDQo+DQo+IE9yIGRpZCBJIG1pc3Mgc29tZXRoaW5nPyAgTXkgd3JpdGV1cCB3aWxs IHJlZmxlY3QgdGhpcyBvYmplY3Rpb24sIHNvIHRoZSBJRVNHIHdpbGwgYmUgYXdhcmUgb2YgaXQu DQo+DQo+IEJyaWFuDQo+DQo+PiBPbiBNYXIgMTIsIDIwMTgsIGF0IDEwOjM0IEFNLCBNYXJ0aW4g VGhvbXNvbiA8bWFydGluLnRob21zb25AZ21haWwuY29tPiB3cm90ZToNCj4+DQo+PiBNeSBjb25j ZXJucyBhYm91dCB0aGVyZSBvbmx5IGJlaW5nIHByb3ByaWV0YXJ5IHB1c2ggc2VydmljZSBwcm92 aWRlcnMgcmVtYWluLg0KPj4NCj4+IE9uIE1vbiwgTWFyIDEyLCAyMDE4IGF0IDE6NTIgUE0sIEJy aWFuIFJvc2VuIDxickBicmlhbnJvc2VuLm5ldD4gd3JvdGU6DQo+Pj4gVGhlcmUgd2FzIGEgbG90 IG9mIGRpc2N1c3Npb24gZHVyaW5nIHRoZSBXR0xDIG9uIHB1c2guIERvZXMgZXZlcnlvbmUgDQo+ Pj4gdGhpbmsgdGhlaXIgaXNzdWVzIGFyZSBkZWFsdCB3aXRoIHNhdGlzZmFjdG9yaWx5IEkgdGhl IGxhdGVzdCBkcmFmdD8NCj4+Pg0KPj4+IEJyaWFuDQo+Pj4NCj4+PiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+IHNpcGNvcmUgbWFpbGluZyBsaXN0 DQo+Pj4gc2lwY29yZUBpZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vc2lwY29yZQ0KPj4+DQo+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpzaXBjb3JlIG1haWxpbmcgbGlzdA0Kc2lwY29yZUBpZXRmLm9y Zw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlDQo= From nobody Mon Mar 12 08:34:51 2018 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 62871126D05 for ; Mon, 12 Mar 2018 08:34:41 -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, FREEMAIL_FROM=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 FRWwTtespIci for ; Mon, 12 Mar 2018 08:34:38 -0700 (PDT) Received: from mail-ot0-x22b.google.com (mail-ot0-x22b.google.com [IPv6:2607:f8b0:4003:c0f::22b]) (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 DBB54126BF0 for ; Mon, 12 Mar 2018 08:34:37 -0700 (PDT) Received: by mail-ot0-x22b.google.com with SMTP id n74so15700942ota.1 for ; Mon, 12 Mar 2018 08:34: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:content-transfer-encoding; bh=PfG/ErDJbrkobBjBwMk7E1jLiO0Nd5kP0rrXrKNREkQ=; b=MCz/hQibHg51jf4FDUA6SN+v2XnQoMTFng5ClvBCO2pmZNOdy7yDr6hyauz/eQkqU/ +tfLLdmI+3Stv1B1p5waPQVCg0cwhFy6nBI4P20o64mtU6Tz0qGZb7xDERAlCD9w8dXZ oO7AGXbNd5rrJs6l1Omyt/dKQo4wmZhAPG9mdjRmGUcowreY59rQ+Wxmc7/BkKff+ipE 49qw7dTWFyN8PC5jLGQBB0VAJeNado8Ie4PcMxM1PeqEZ9IGOn84/h+LdzPPVJ0zIfUF 0LmV+V1aw+EYGELqEQrdIijdleWCxdRVPS35fKac/P2SHL2Gq+gLnCTAFbWkEIwtt32b UoAw== 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=PfG/ErDJbrkobBjBwMk7E1jLiO0Nd5kP0rrXrKNREkQ=; b=UFm9aHPSYjTAEY2jDKzGt22mWge21RgBTNCYJ7NVRE84YtY5O/FBCRCuu6byGGrue7 6VzfNkRil0z0M0itL/71vFZQdUWZWR7juwuduk7SUQ2vjAUslKExlzuiY18kSHGy0g8q mAjxgnWV4Rx9+jODjkL14ocb/gotYmWEKMTO7arle//ZLSSHbNXzMBDWOPoLoMm9iAlO GeE3/uYDg3i2Y+zTtb7SrA3wI9xwD11wHocGPqLpEFmg9Ikjm+0niFYoQlUBcBqWJHZe XDyVS9I/tZJfIE7/tkxCHNqiKml+HfM5j97Dg+Vbnys4n9rcyLlRrmi+IStDolKijTzI 5awA== X-Gm-Message-State: AElRT7G/lEOlAJOGJIIgglX1FuG4bFxJRUxUhlD7UPenX9VQt3rDFd9e LUGCft1iw/ik9PB8REGKpxKjnd0et5NAbdUlRJw= X-Google-Smtp-Source: AG47ELvx61i7PxheoOKX1KiiYRVc3DEIEVc0OzEQa7yMamoXRRm/73UptLLvGkONkm+A0a8BvAEXBn+GF3A81Pdod/c= X-Received: by 10.157.0.74 with SMTP id 68mr5433162ota.392.1520868877151; Mon, 12 Mar 2018 08:34:37 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:1055:0:0:0:0:0 with HTTP; Mon, 12 Mar 2018 08:34:36 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C1F1FC6@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B6C1F1FC6@ESESSMB109.ericsson.se> From: Martin Thomson Date: Mon, 12 Mar 2018 15:34:36 +0000 Message-ID: To: Christer Holmberg Cc: Brian Rosen , SIPCORE Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [sipcore] -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, 12 Mar 2018 15:34:41 -0000 FCM supports 8030 in addition to its proprietary interface(s). ~~~ The value of the pn-provider URI parameter is "webpush". The value of the pn-param URI parameter is the subscription URI. The pn-prid URI parameter is not used and MUST be ignored if present. See RFC 8030 for details. Note that encryption for web push [RFC8291] is not used, therefore parameters for message encryption are not defined in this specification. Web push permits the sending of a push message without a payload without encryption. On Mon, Mar 12, 2018 at 3:30 PM, Christer Holmberg wrote: > Hi Martin, > > You previously said "FCM supports RFC 8030". I thought that meant that FC= M is based on RFC 8030, i.e. a standardized solution :) > > But, I have no problem to include a registration for a generic "RFC8030" = service. > > Since you are the author of RFC 8030, are you able to put provide the reg= istration information? See sections 9 and 10 for examples. > > Regards, > > Christer > > > > > > > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Martin Thoms= on > Sent: 12 March 2018 17:12 > To: Brian Rosen > Cc: SIPCORE > Subject: Re: [sipcore] -push > > You could implement a SIP UA in a browser. I don't know whether this Web= RTC thing will take off, but it seems both plausible and useful. > > What "other things" do you refer to specifically? I think that it just w= orks. > > The pieces that 8030 needs are partly in place. Christer added a VAPID r= eference. He removed the additional elements necessary to convey keys. I t= hink that was because this is only a poke and the poke carries no informati= on (and therefore, by 8030, does not need all the encryption bits). > > I object pretty strongly to this work defining proprietary-only solutions= when a standardized solution exists. > > On Mon, Mar 12, 2018 at 3:02 PM, Brian Rosen wrote: >> Can we explore that a bit: >> The =E2=80=9Cnon-proprietary=E2=80=9D that exists is RFC8030. >> But the implementations of 8030 would need other things to work. >> So to make sip-push work with 8030 would mean a bunch of other mechanism= s. >> >> Is there actual need (i.e. implementations) for 8030 based push? >> >> Otherwise, while I understand your concern, it would seem that someone o= ther than Christer should, if they want to, write a draft that would extend= push to work with 8030 in practical implementations, pulling in other work= to make it actually work. >> >> Or did I miss something? My writeup will reflect this objection, so the= IESG will be aware of it. >> >> Brian >> >>> On Mar 12, 2018, at 10:34 AM, Martin Thomson = wrote: >>> >>> My concerns about there only being proprietary push service providers r= emain. >>> >>> On Mon, Mar 12, 2018 at 1:52 PM, Brian Rosen wrote: >>>> There was a lot of discussion during the WGLC on push. Does everyone >>>> think their issues are dealt with satisfactorily I the latest draft? >>>> >>>> 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 From nobody Mon Mar 12 08:36:32 2018 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 D811C126D05 for ; Mon, 12 Mar 2018 08:36:31 -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 ToDNheV_CTRg for ; Mon, 12 Mar 2018 08:36:28 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::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 A3DD6120227 for ; Mon, 12 Mar 2018 08:36:28 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id j4so11868539qke.10 for ; Mon, 12 Mar 2018 08:36:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=RnzGJp/d7WqmQjcvSzdNijIF9OycxWj8WJvWybGtrFI=; b=LeaJLJ4w1iKUV7pdhtVYUDb3JK6oRSi+hRIjNDIYP+CYTWCmHfRcS023+FteQuX+1+ ZBdLrilqKG0nIwifKSvRsSijJIbeD+Dz1noXXfoyyUFlGskkFl3QYdit+83jFfKtHoMi qrPluh9r998x1+K10sv7Qv9AxNwPffU3cHMHQZgvCOYzOWpHA+4mBU6tWd1F944Lc680 c8wTsAs/NUIZMVXqQMmVIflnE5gh6GhMgnwBE5NEfy0IEhYzD2kuqDt3MqiIFBFspWKp bD62ZP+/FuGbic+E7nejUpVALOTeouSTlD5e7UaX5/a495BHYrBYsCBk1ZF1ndY4Fs7x ZXzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=RnzGJp/d7WqmQjcvSzdNijIF9OycxWj8WJvWybGtrFI=; b=EffbFfgUqTRqh2r9v6sfXh+GzUlXwDvLyVIvlPzR8Duf6Ul/esRsVznafbxmuail/f 7pBsau/QGUh76baVxwj0ilHVgDzddbqcl2aRnYxKl59zBAps8GT3HFR+M5shBGqFfPtu bvOFDd5zs8TegkEIqb3kk7qjjhcKLGaTZeI3o0Ia0f3wsPTiUepfxbaa/YBZkBPxYSBz TjaGdqFWinxf+BvOwMlvrXWzH/FhwJ/Dw0UfCqaOS4mWHm4RDolokFT+xPmvIwty0bpP ujtcZ33ZjlgrTDMTfCwToxwUWcepCFVlrRV0/PJtvxkyk6J9fZr2hF5DLUtZdmXAJ8Dm 8sAA== X-Gm-Message-State: AElRT7GTnXbTTviOxhjWA+b0N6+fcxPu6maXvhwhLK30Alz/e5z5xHAO oirFGVCc4o/vmiCnFy28YdEstA== X-Google-Smtp-Source: AG47ELv2gVf18zKOKpBQ8q073hCWAdipqUxRXTMddXrwxkD44+1/krldydkbNV20SjZp7i9m/PvEXw== X-Received: by 10.55.169.207 with SMTP id s198mr2551814qke.96.1520868987669; Mon, 12 Mar 2018 08:36:27 -0700 (PDT) Received: from [192.168.0.21] (cpe-66-108-233-234.nyc.res.rr.com. [66.108.233.234]) by smtp.gmail.com with ESMTPSA id s3sm5512316qte.95.2018.03.12.08.36.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Mar 2018 08:36:26 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Brian Rosen In-Reply-To: Date: Mon, 12 Mar 2018 11:36:36 -0400 Cc: Christer Holmberg , SIPCORE Content-Transfer-Encoding: quoted-printable Message-Id: <72C1D6DE-B67A-4241-ACA8-F9C46D5C4C11@brianrosen.net> References: <7594FB04B1934943A5C02806D1A2204B6C1F1FC6@ESESSMB109.ericsson.se> To: Martin Thomson X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [sipcore] -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, 12 Mar 2018 15:36:32 -0000 If that gets into the draft, what else do we need? Brian > On Mar 12, 2018, at 11:34 AM, Martin Thomson = wrote: >=20 > FCM supports 8030 in addition to its proprietary interface(s). >=20 > ~~~ >=20 > The value of the pn-provider URI parameter is "webpush". >=20 > The value of the pn-param URI parameter is the subscription URI. >=20 > The pn-prid URI parameter is not used and MUST be ignored if = present. >=20 > See RFC 8030 for details. Note that encryption for web push > [RFC8291] is not used, therefore parameters for message encryption are > not defined in this specification. Web push permits the sending of a > push message without a payload without encryption. >=20 > On Mon, Mar 12, 2018 at 3:30 PM, Christer Holmberg > wrote: >> Hi Martin, >>=20 >> You previously said "FCM supports RFC 8030". I thought that meant = that FCM is based on RFC 8030, i.e. a standardized solution :) >>=20 >> But, I have no problem to include a registration for a generic = "RFC8030" service. >>=20 >> Since you are the author of RFC 8030, are you able to put provide the = registration information? See sections 9 and 10 for examples. >>=20 >> Regards, >>=20 >> Christer >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> -----Original Message----- >> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Martin = Thomson >> Sent: 12 March 2018 17:12 >> To: Brian Rosen >> Cc: SIPCORE >> Subject: Re: [sipcore] -push >>=20 >> You could implement a SIP UA in a browser. I don't know whether this = WebRTC thing will take off, but it seems both plausible and useful. >>=20 >> What "other things" do you refer to specifically? I think that it = just works. >>=20 >> The pieces that 8030 needs are partly in place. Christer added a = VAPID reference. He removed the additional elements necessary to convey = keys. I think that was because this is only a poke and the poke carries = no information (and therefore, by 8030, does not need all the encryption = bits). >>=20 >> I object pretty strongly to this work defining proprietary-only = solutions when a standardized solution exists. >>=20 >> On Mon, Mar 12, 2018 at 3:02 PM, Brian Rosen = wrote: >>> Can we explore that a bit: >>> The =E2=80=9Cnon-proprietary=E2=80=9D that exists is RFC8030. >>> But the implementations of 8030 would need other things to work. >>> So to make sip-push work with 8030 would mean a bunch of other = mechanisms. >>>=20 >>> Is there actual need (i.e. implementations) for 8030 based push? >>>=20 >>> Otherwise, while I understand your concern, it would seem that = someone other than Christer should, if they want to, write a draft that = would extend push to work with 8030 in practical implementations, = pulling in other work to make it actually work. >>>=20 >>> Or did I miss something? My writeup will reflect this objection, so = the IESG will be aware of it. >>>=20 >>> Brian >>>=20 >>>> On Mar 12, 2018, at 10:34 AM, Martin Thomson = wrote: >>>>=20 >>>> My concerns about there only being proprietary push service = providers remain. >>>>=20 >>>> On Mon, Mar 12, 2018 at 1:52 PM, Brian Rosen = wrote: >>>>> There was a lot of discussion during the WGLC on push. Does = everyone >>>>> think their issues are dealt with satisfactorily I the latest = draft? >>>>>=20 >>>>> Brian >>>>>=20 >>>>> _______________________________________________ >>>>> sipcore mailing list >>>>> sipcore@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>>=20 >>>=20 >>=20 >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore From nobody Mon Mar 12 08:36:54 2018 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 36FD5129BBF for ; Mon, 12 Mar 2018 08:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 RnYkkt0pD-ft for ; Mon, 12 Mar 2018 08:36:46 -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 40237126D05 for ; Mon, 12 Mar 2018 08:36:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1520869001; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=gxV0YOQgQ/QRrdU4pgqSQgEENZt34Ip18Ce7kbocCDY=; b=Obo1lbpVl/IK4JGqTQXZlX1X6h0EuS5m7Es3Iikzu3c2i2MxmrSEOoZ4AvnbbGyh 1kTxB4BCKVFeV3oZxyoipsumDdpeVauXWQmicBhwjvGhQrQXip0OtO22aS7kCiYz ujP9M8f7K+50a3ozYDwfwMXNbe+hrPtBImPefPTaxdI=; X-AuditID: c1b4fb2d-4b1ff70000005540-cf-5aa69e89d6ef Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 8E.07.21824.98E96AA5; Mon, 12 Mar 2018 16:36:41 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.172]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0382.000; Mon, 12 Mar 2018 16:36:40 +0100 From: Christer Holmberg To: Martin Thomson CC: Brian Rosen , SIPCORE Thread-Topic: [sipcore] -push Thread-Index: AQHTuglY2BEOxxfeoUSBwdrzyq2mqaPMmZeAgAAH1YCAAAKjgIAAE3cQ///y5ACAABEvsA== Date: Mon, 12 Mar 2018 15:36:41 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B6C1F1FFD@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B6C1F1FC6@ESESSMB109.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.163] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmkeLIzCtJLcpLzFFi42KZGbFdXbdz3rIog909ShZP709js7h25h+j xdcfm9gcmD3uf/vL7rFz1l12jyVLfjIFMEdx2aSk5mSWpRbp2yVwZZx/voipYJFGxfNjr1kb GOeodzFyckgImEh0LvrF1sXIxSEkcJhRYmvXRhYIZwmjxOlDz5i6GDk42AQsJLr/aYM0iAjo Siw6+4AdJMwsYC9x5LEfiCksICNx7pkQRIWsRMPhFewQdpjEvsvHGEFsFgFViWenZzOD2LwC vhLbTl9lhNi0kFli6sUOFpAEp0CgxN4/e8CaGQXEJL6fWsMEYjMLiEvcejKfCeJmAYkle84z Q9iiEi8f/2OFsJUklk/bAnWapsT6XfoQrYoSU7ofskPsFZQ4OfMJywRG0VlIps5C6JiFpGMW ko4FjCyrGEWLU4uLc9ONjPVSizKTi4vz8/TyUks2MQKj5uCW37o7GFe/djzEKMDBqMTD29Kx LEqINbGsuDL3EKMEB7OSCK//VKAQb0piZVVqUX58UWlOavEhRmkOFiVx3pOevFFCAumJJanZ qakFqUUwWSYOTqkGxmUdRy+amrxdGCD8QlCf/9M//4/6QXq7017Vrak7VShjGc0/aU5Sh0/2 zhk6WXvehfl9UbWeXciStNd/M2d12XSPoPtKKpfeJJpfMdH/Pqd558q1HZeXNZ7Sm8Vd0Fq+ PPGbmumHL+7ylvyzHJ2VZ2wIO3j8Idf2awu+KJ3hCimVl+oIkn0dosRSnJFoqMVcVJwIAJYF wmyWAgAA Archived-At: Subject: Re: [sipcore] -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, 12 Mar 2018 15:36:49 -0000 VGhhbmtzISA6KQ0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KRnJvbTogTWFydGluIFRob21zb24gW21haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFp bC5jb21dIA0KU2VudDogMTIgTWFyY2ggMjAxOCAxNzozNQ0KVG86IENocmlzdGVyIEhvbG1iZXJn IDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+DQpDYzogQnJpYW4gUm9zZW4gPGJyQGJy aWFucm9zZW4ubmV0PjsgU0lQQ09SRSA8c2lwY29yZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBb c2lwY29yZV0gLXB1c2gNCg0KRkNNIHN1cHBvcnRzIDgwMzAgaW4gYWRkaXRpb24gdG8gaXRzIHBy b3ByaWV0YXJ5IGludGVyZmFjZShzKS4NCg0Kfn5+DQoNCiAgIFRoZSB2YWx1ZSBvZiB0aGUgcG4t cHJvdmlkZXIgVVJJIHBhcmFtZXRlciBpcyAid2VicHVzaCIuDQoNCiAgIFRoZSB2YWx1ZSBvZiB0 aGUgcG4tcGFyYW0gVVJJIHBhcmFtZXRlciBpcyB0aGUgc3Vic2NyaXB0aW9uIFVSSS4NCg0KICAg IFRoZSBwbi1wcmlkIFVSSSBwYXJhbWV0ZXIgaXMgbm90IHVzZWQgYW5kIE1VU1QgYmUgaWdub3Jl ZCBpZiBwcmVzZW50Lg0KDQogICAgU2VlIFJGQyA4MDMwIGZvciBkZXRhaWxzLiAgTm90ZSB0aGF0 IGVuY3J5cHRpb24gZm9yIHdlYiBwdXNoIFtSRkM4MjkxXSBpcyBub3QgdXNlZCwgdGhlcmVmb3Jl IHBhcmFtZXRlcnMgZm9yIG1lc3NhZ2UgZW5jcnlwdGlvbiBhcmUgbm90IGRlZmluZWQgaW4gdGhp cyBzcGVjaWZpY2F0aW9uLiAgV2ViIHB1c2ggcGVybWl0cyB0aGUgc2VuZGluZyBvZiBhIHB1c2gg bWVzc2FnZSB3aXRob3V0IGEgcGF5bG9hZCB3aXRob3V0IGVuY3J5cHRpb24uDQoNCk9uIE1vbiwg TWFyIDEyLCAyMDE4IGF0IDM6MzAgUE0sIENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xt YmVyZ0Blcmljc3Nvbi5jb20+IHdyb3RlOg0KPiBIaSBNYXJ0aW4sDQo+DQo+IFlvdSBwcmV2aW91 c2x5IHNhaWQgIkZDTSBzdXBwb3J0cyBSRkMgODAzMCIuIEkgdGhvdWdodCB0aGF0IG1lYW50IHRo YXQgDQo+IEZDTSBpcyBiYXNlZCBvbiBSRkMgODAzMCwgaS5lLiBhIHN0YW5kYXJkaXplZCBzb2x1 dGlvbiA6KQ0KPg0KPiBCdXQsIEkgaGF2ZSBubyBwcm9ibGVtIHRvIGluY2x1ZGUgYSByZWdpc3Ry YXRpb24gZm9yIGEgZ2VuZXJpYyAiUkZDODAzMCIgc2VydmljZS4NCj4NCj4gU2luY2UgeW91IGFy ZSB0aGUgYXV0aG9yIG9mIFJGQyA4MDMwLCBhcmUgeW91IGFibGUgdG8gcHV0IHByb3ZpZGUgdGhl IHJlZ2lzdHJhdGlvbiBpbmZvcm1hdGlvbj8gU2VlIHNlY3Rpb25zIDkgYW5kIDEwIGZvciBleGFt cGxlcy4NCj4NCj4gUmVnYXJkcywNCj4NCj4gQ2hyaXN0ZXINCj4NCj4NCj4NCj4NCj4NCj4NCj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogc2lwY29yZSBbbWFpbHRvOnNpcGNv cmUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1hcnRpbiANCj4gVGhvbXNvbg0KPiBT ZW50OiAxMiBNYXJjaCAyMDE4IDE3OjEyDQo+IFRvOiBCcmlhbiBSb3NlbiA8YnJAYnJpYW5yb3Nl bi5uZXQ+DQo+IENjOiBTSVBDT1JFIDxzaXBjb3JlQGlldGYub3JnPg0KPiBTdWJqZWN0OiBSZTog W3NpcGNvcmVdIC1wdXNoDQo+DQo+IFlvdSBjb3VsZCBpbXBsZW1lbnQgYSBTSVAgVUEgaW4gYSBi cm93c2VyLiAgSSBkb24ndCBrbm93IHdoZXRoZXIgdGhpcyBXZWJSVEMgdGhpbmcgd2lsbCB0YWtl IG9mZiwgYnV0IGl0IHNlZW1zIGJvdGggcGxhdXNpYmxlIGFuZCB1c2VmdWwuDQo+DQo+IFdoYXQg Im90aGVyIHRoaW5ncyIgZG8geW91IHJlZmVyIHRvIHNwZWNpZmljYWxseT8gIEkgdGhpbmsgdGhh dCBpdCBqdXN0IHdvcmtzLg0KPg0KPiBUaGUgcGllY2VzIHRoYXQgODAzMCBuZWVkcyBhcmUgcGFy dGx5IGluIHBsYWNlLiAgQ2hyaXN0ZXIgYWRkZWQgYSBWQVBJRCByZWZlcmVuY2UuICBIZSByZW1v dmVkIHRoZSBhZGRpdGlvbmFsIGVsZW1lbnRzIG5lY2Vzc2FyeSB0byBjb252ZXkga2V5cy4gSSB0 aGluayB0aGF0IHdhcyBiZWNhdXNlIHRoaXMgaXMgb25seSBhIHBva2UgYW5kIHRoZSBwb2tlIGNh cnJpZXMgbm8gaW5mb3JtYXRpb24gKGFuZCB0aGVyZWZvcmUsIGJ5IDgwMzAsIGRvZXMgbm90IG5l ZWQgYWxsIHRoZSBlbmNyeXB0aW9uIGJpdHMpLg0KPg0KPiBJIG9iamVjdCBwcmV0dHkgc3Ryb25n bHkgdG8gdGhpcyB3b3JrIGRlZmluaW5nIHByb3ByaWV0YXJ5LW9ubHkgc29sdXRpb25zIHdoZW4g YSBzdGFuZGFyZGl6ZWQgc29sdXRpb24gZXhpc3RzLg0KPg0KPiBPbiBNb24sIE1hciAxMiwgMjAx OCBhdCAzOjAyIFBNLCBCcmlhbiBSb3NlbiA8YnJAYnJpYW5yb3Nlbi5uZXQ+IHdyb3RlOg0KPj4g Q2FuIHdlIGV4cGxvcmUgdGhhdCBhIGJpdDoNCj4+IFRoZSDigJxub24tcHJvcHJpZXRhcnnigJ0g dGhhdCBleGlzdHMgaXMgUkZDODAzMC4NCj4+IEJ1dCB0aGUgaW1wbGVtZW50YXRpb25zIG9mIDgw MzAgd291bGQgbmVlZCBvdGhlciB0aGluZ3MgdG8gd29yay4NCj4+IFNvIHRvIG1ha2Ugc2lwLXB1 c2ggd29yayB3aXRoIDgwMzAgd291bGQgbWVhbiBhIGJ1bmNoIG9mIG90aGVyIG1lY2hhbmlzbXMu DQo+Pg0KPj4gSXMgdGhlcmUgYWN0dWFsIG5lZWQgKGkuZS4gaW1wbGVtZW50YXRpb25zKSBmb3Ig ODAzMCBiYXNlZCBwdXNoPw0KPj4NCj4+IE90aGVyd2lzZSwgd2hpbGUgSSB1bmRlcnN0YW5kIHlv dXIgY29uY2VybiwgaXQgd291bGQgc2VlbSB0aGF0IHNvbWVvbmUgb3RoZXIgdGhhbiBDaHJpc3Rl ciBzaG91bGQsIGlmIHRoZXkgd2FudCB0bywgd3JpdGUgYSBkcmFmdCB0aGF0IHdvdWxkIGV4dGVu ZCBwdXNoIHRvIHdvcmsgd2l0aCA4MDMwIGluIHByYWN0aWNhbCBpbXBsZW1lbnRhdGlvbnMsIHB1 bGxpbmcgaW4gb3RoZXIgd29yayB0byBtYWtlIGl0IGFjdHVhbGx5IHdvcmsuDQo+Pg0KPj4gT3Ig ZGlkIEkgbWlzcyBzb21ldGhpbmc/ICBNeSB3cml0ZXVwIHdpbGwgcmVmbGVjdCB0aGlzIG9iamVj dGlvbiwgc28gdGhlIElFU0cgd2lsbCBiZSBhd2FyZSBvZiBpdC4NCj4+DQo+PiBCcmlhbg0KPj4N Cj4+PiBPbiBNYXIgMTIsIDIwMTgsIGF0IDEwOjM0IEFNLCBNYXJ0aW4gVGhvbXNvbiA8bWFydGlu LnRob21zb25AZ21haWwuY29tPiB3cm90ZToNCj4+Pg0KPj4+IE15IGNvbmNlcm5zIGFib3V0IHRo ZXJlIG9ubHkgYmVpbmcgcHJvcHJpZXRhcnkgcHVzaCBzZXJ2aWNlIHByb3ZpZGVycyByZW1haW4u DQo+Pj4NCj4+PiBPbiBNb24sIE1hciAxMiwgMjAxOCBhdCAxOjUyIFBNLCBCcmlhbiBSb3NlbiA8 YnJAYnJpYW5yb3Nlbi5uZXQ+IHdyb3RlOg0KPj4+PiBUaGVyZSB3YXMgYSBsb3Qgb2YgZGlzY3Vz c2lvbiBkdXJpbmcgdGhlIFdHTEMgb24gcHVzaC4gRG9lcyANCj4+Pj4gZXZlcnlvbmUgdGhpbmsg dGhlaXIgaXNzdWVzIGFyZSBkZWFsdCB3aXRoIHNhdGlzZmFjdG9yaWx5IEkgdGhlIGxhdGVzdCBk cmFmdD8NCj4+Pj4NCj4+Pj4gQnJpYW4NCj4+Pj4NCj4+Pj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4gc2lwY29yZSBtYWlsaW5nIGxpc3QNCj4+ Pj4gc2lwY29yZUBpZXRmLm9yZw0KPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NpcGNvcmUNCj4+Pj4NCj4+DQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+IHNpcGNvcmUgbWFpbGluZyBsaXN0DQo+IHNpcGNvcmVA aWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3Jl DQo= From nobody Mon Mar 12 08:38:30 2018 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 6D2E3126DED for ; Mon, 12 Mar 2018 08:38:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 UkTNXNdr5mJf for ; Mon, 12 Mar 2018 08:38:22 -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 CA568120227 for ; Mon, 12 Mar 2018 08:38:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1520869100; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=5oTEGfmPKA3sncfdhaVH/UBvMN3UuqI3ajs2ZkX6XGo=; b=cU6+/mRzxdQQcvoKUoREvCdnna7v2i5zFtILHDXaLGUSLd4aRrYZ6NEFjyitSmVy +pduqKOfQ0lrVwhi6HLWTwNlW7qPckBIc9KrVl6665dUCU95YVsh0vdyNeqn2hkc e9cxJoS1fu7KaJbILkE7VMV61ZEvq3Yisg7ZDhu+cSU=; X-AuditID: c1b4fb2d-87c029c000005540-ef-5aa69eeb7f6b Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id D1.B7.21824.BEE96AA5; Mon, 12 Mar 2018 16:38:20 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.172]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0382.000; Mon, 12 Mar 2018 16:38:19 +0100 From: Christer Holmberg To: Brian Rosen , Martin Thomson CC: SIPCORE Thread-Topic: [sipcore] -push Thread-Index: AQHTuglY2BEOxxfeoUSBwdrzyq2mqaPMmZeAgAAH1YCAAAKjgIAAE3cQ///y5ACAAACPAIAAEOxg Date: Mon, 12 Mar 2018 15:38:19 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B6C1F2029@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B6C1F1FC6@ESESSMB109.ericsson.se> <72C1D6DE-B67A-4241-ACA8-F9C46D5C4C11@brianrosen.net> In-Reply-To: <72C1D6DE-B67A-4241-ACA8-F9C46D5C4C11@brianrosen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.163] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpikeLIzCtJLcpLzFFi42KZGbE9RPfNvGVRBh97uSye3p/GZnHtzD9G i68/NrE5MHvc//aX3WPnrLvsHkuW/GQKYI7isklJzcksSy3St0vgyli2gq3glGbFw9fHmRoY D2h0MXJySAiYSKx9c56ti5GLQ0jgMKPEpen7WSCcJYwSt26vZOxi5OBgE7CQ6P6nDdIgIuAn sav7PiuIzSwgJ3H9w0Y2kBJhARmJc8+EIEpkJRoOr2CHsKMkPrR/AytnEVCVePN/BlicV8BX ouF1LzOILSRwk1niSj8viM0p4CSx5PJjRhCbUUBM4vupNUwQq8Qlbj2ZzwRxs4DEkj3nmSFs UYmXj/+xQthKEsunbWEHOYdZQFNi/S59iFZFiSndD6HWCkqcnPmEZQKj6CwkU2chdMxC0jEL SccCRpZVjKLFqcXFuelGxnqpRZnJxcX5eXp5qSWbGIExc3DLb90djKtfOx5iFOBgVOLhbelY FiXEmlhWXJl7iFGCg1lJhNd/KlCINyWxsiq1KD++qDQntfgQozQHi5I470lP3ighgfTEktTs 1NSC1CKYLBMHp1QDY3+x/KTHH7dqzGfUVVgiYbjI4O7OJQ7z+kI2n/z4apNu+e6+lbP/GW5T ORxwM0z1i+gG4+1CQf4e071Chf4Yvn4e0aFc3N8RHXTh8/aHUTrH7CWuNdw7EVa+9uppLzNu kWkPlovMEhNeuzdmymOed9/jXrhsXsl4cOoGXtH5zPPV2NYZ66Y9Wa3EUpyRaKjFXFScCACE dFKulQIAAA== Archived-At: Subject: Re: [sipcore] -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, 12 Mar 2018 15:38:28 -0000 SGkgQnJpYW4sDQoNCj5JZiB0aGF0IGdldHMgaW50byB0aGUgZHJhZnQsIHdoYXQgZWxzZSBkbyB3 ZSBuZWVkPw0KDQpJIHdpbGwgYWRkIGEgbmV3IHNlY3Rpb24gKHNpbWlsYXIgdG8gc2VjdGlvbnMg OSBhbmQgMTApLCBhbmQgYWRkICJ3ZWJwdXNoIiB0byB0aGUgdGFibGUgaW4gc2VjdGlvbiAxMi41 Lg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCj4gT24gTWFyIDEyLCAyMDE4LCBhdCAxMToz NCBBTSwgTWFydGluIFRob21zb24gPG1hcnRpbi50aG9tc29uQGdtYWlsLmNvbT4gd3JvdGU6DQo+ IA0KPiBGQ00gc3VwcG9ydHMgODAzMCBpbiBhZGRpdGlvbiB0byBpdHMgcHJvcHJpZXRhcnkgaW50 ZXJmYWNlKHMpLg0KPiANCj4gfn5+DQo+IA0KPiAgIFRoZSB2YWx1ZSBvZiB0aGUgcG4tcHJvdmlk ZXIgVVJJIHBhcmFtZXRlciBpcyAid2VicHVzaCIuDQo+IA0KPiAgIFRoZSB2YWx1ZSBvZiB0aGUg cG4tcGFyYW0gVVJJIHBhcmFtZXRlciBpcyB0aGUgc3Vic2NyaXB0aW9uIFVSSS4NCj4gDQo+ICAg IFRoZSBwbi1wcmlkIFVSSSBwYXJhbWV0ZXIgaXMgbm90IHVzZWQgYW5kIE1VU1QgYmUgaWdub3Jl ZCBpZiBwcmVzZW50Lg0KPiANCj4gICAgU2VlIFJGQyA4MDMwIGZvciBkZXRhaWxzLiAgTm90ZSB0 aGF0IGVuY3J5cHRpb24gZm9yIHdlYiBwdXNoIA0KPiBbUkZDODI5MV0gaXMgbm90IHVzZWQsIHRo ZXJlZm9yZSBwYXJhbWV0ZXJzIGZvciBtZXNzYWdlIGVuY3J5cHRpb24gYXJlIA0KPiBub3QgZGVm aW5lZCBpbiB0aGlzIHNwZWNpZmljYXRpb24uICBXZWIgcHVzaCBwZXJtaXRzIHRoZSBzZW5kaW5n IG9mIGEgDQo+IHB1c2ggbWVzc2FnZSB3aXRob3V0IGEgcGF5bG9hZCB3aXRob3V0IGVuY3J5cHRp b24uDQo+IA0KPiBPbiBNb24sIE1hciAxMiwgMjAxOCBhdCAzOjMwIFBNLCBDaHJpc3RlciBIb2xt YmVyZyANCj4gPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4gd3JvdGU6DQo+PiBIaSBN YXJ0aW4sDQo+PiANCj4+IFlvdSBwcmV2aW91c2x5IHNhaWQgIkZDTSBzdXBwb3J0cyBSRkMgODAz MCIuIEkgdGhvdWdodCB0aGF0IG1lYW50IA0KPj4gdGhhdCBGQ00gaXMgYmFzZWQgb24gUkZDIDgw MzAsIGkuZS4gYSBzdGFuZGFyZGl6ZWQgc29sdXRpb24gOikNCj4+IA0KPj4gQnV0LCBJIGhhdmUg bm8gcHJvYmxlbSB0byBpbmNsdWRlIGEgcmVnaXN0cmF0aW9uIGZvciBhIGdlbmVyaWMgIlJGQzgw MzAiIHNlcnZpY2UuDQo+PiANCj4+IFNpbmNlIHlvdSBhcmUgdGhlIGF1dGhvciBvZiBSRkMgODAz MCwgYXJlIHlvdSBhYmxlIHRvIHB1dCBwcm92aWRlIHRoZSByZWdpc3RyYXRpb24gaW5mb3JtYXRp b24/IFNlZSBzZWN0aW9ucyA5IGFuZCAxMCBmb3IgZXhhbXBsZXMuDQo+PiANCj4+IFJlZ2FyZHMs DQo+PiANCj4+IENocmlzdGVyDQo+PiANCj4+IA0KPj4gDQo+PiANCj4+IA0KPj4gDQo+PiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogc2lwY29yZSBbbWFpbHRvOnNpcGNvcmUt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1hcnRpbiANCj4+IFRob21zb24NCj4+IFNl bnQ6IDEyIE1hcmNoIDIwMTggMTc6MTINCj4+IFRvOiBCcmlhbiBSb3NlbiA8YnJAYnJpYW5yb3Nl bi5uZXQ+DQo+PiBDYzogU0lQQ09SRSA8c2lwY29yZUBpZXRmLm9yZz4NCj4+IFN1YmplY3Q6IFJl OiBbc2lwY29yZV0gLXB1c2gNCj4+IA0KPj4gWW91IGNvdWxkIGltcGxlbWVudCBhIFNJUCBVQSBp biBhIGJyb3dzZXIuICBJIGRvbid0IGtub3cgd2hldGhlciB0aGlzIFdlYlJUQyB0aGluZyB3aWxs IHRha2Ugb2ZmLCBidXQgaXQgc2VlbXMgYm90aCBwbGF1c2libGUgYW5kIHVzZWZ1bC4NCj4+IA0K Pj4gV2hhdCAib3RoZXIgdGhpbmdzIiBkbyB5b3UgcmVmZXIgdG8gc3BlY2lmaWNhbGx5PyAgSSB0 aGluayB0aGF0IGl0IGp1c3Qgd29ya3MuDQo+PiANCj4+IFRoZSBwaWVjZXMgdGhhdCA4MDMwIG5l ZWRzIGFyZSBwYXJ0bHkgaW4gcGxhY2UuICBDaHJpc3RlciBhZGRlZCBhIFZBUElEIHJlZmVyZW5j ZS4gIEhlIHJlbW92ZWQgdGhlIGFkZGl0aW9uYWwgZWxlbWVudHMgbmVjZXNzYXJ5IHRvIGNvbnZl eSBrZXlzLiBJIHRoaW5rIHRoYXQgd2FzIGJlY2F1c2UgdGhpcyBpcyBvbmx5IGEgcG9rZSBhbmQg dGhlIHBva2UgY2FycmllcyBubyBpbmZvcm1hdGlvbiAoYW5kIHRoZXJlZm9yZSwgYnkgODAzMCwg ZG9lcyBub3QgbmVlZCBhbGwgdGhlIGVuY3J5cHRpb24gYml0cykuDQo+PiANCj4+IEkgb2JqZWN0 IHByZXR0eSBzdHJvbmdseSB0byB0aGlzIHdvcmsgZGVmaW5pbmcgcHJvcHJpZXRhcnktb25seSBz b2x1dGlvbnMgd2hlbiBhIHN0YW5kYXJkaXplZCBzb2x1dGlvbiBleGlzdHMuDQo+PiANCj4+IE9u IE1vbiwgTWFyIDEyLCAyMDE4IGF0IDM6MDIgUE0sIEJyaWFuIFJvc2VuIDxickBicmlhbnJvc2Vu Lm5ldD4gd3JvdGU6DQo+Pj4gQ2FuIHdlIGV4cGxvcmUgdGhhdCBhIGJpdDoNCj4+PiBUaGUg4oCc bm9uLXByb3ByaWV0YXJ54oCdIHRoYXQgZXhpc3RzIGlzIFJGQzgwMzAuDQo+Pj4gQnV0IHRoZSBp bXBsZW1lbnRhdGlvbnMgb2YgODAzMCB3b3VsZCBuZWVkIG90aGVyIHRoaW5ncyB0byB3b3JrLg0K Pj4+IFNvIHRvIG1ha2Ugc2lwLXB1c2ggd29yayB3aXRoIDgwMzAgd291bGQgbWVhbiBhIGJ1bmNo IG9mIG90aGVyIG1lY2hhbmlzbXMuDQo+Pj4gDQo+Pj4gSXMgdGhlcmUgYWN0dWFsIG5lZWQgKGku ZS4gaW1wbGVtZW50YXRpb25zKSBmb3IgODAzMCBiYXNlZCBwdXNoPw0KPj4+IA0KPj4+IE90aGVy d2lzZSwgd2hpbGUgSSB1bmRlcnN0YW5kIHlvdXIgY29uY2VybiwgaXQgd291bGQgc2VlbSB0aGF0 IHNvbWVvbmUgb3RoZXIgdGhhbiBDaHJpc3RlciBzaG91bGQsIGlmIHRoZXkgd2FudCB0bywgd3Jp dGUgYSBkcmFmdCB0aGF0IHdvdWxkIGV4dGVuZCBwdXNoIHRvIHdvcmsgd2l0aCA4MDMwIGluIHBy YWN0aWNhbCBpbXBsZW1lbnRhdGlvbnMsIHB1bGxpbmcgaW4gb3RoZXIgd29yayB0byBtYWtlIGl0 IGFjdHVhbGx5IHdvcmsuDQo+Pj4gDQo+Pj4gT3IgZGlkIEkgbWlzcyBzb21ldGhpbmc/ICBNeSB3 cml0ZXVwIHdpbGwgcmVmbGVjdCB0aGlzIG9iamVjdGlvbiwgc28gdGhlIElFU0cgd2lsbCBiZSBh d2FyZSBvZiBpdC4NCj4+PiANCj4+PiBCcmlhbg0KPj4+IA0KPj4+PiBPbiBNYXIgMTIsIDIwMTgs IGF0IDEwOjM0IEFNLCBNYXJ0aW4gVGhvbXNvbiA8bWFydGluLnRob21zb25AZ21haWwuY29tPiB3 cm90ZToNCj4+Pj4gDQo+Pj4+IE15IGNvbmNlcm5zIGFib3V0IHRoZXJlIG9ubHkgYmVpbmcgcHJv cHJpZXRhcnkgcHVzaCBzZXJ2aWNlIHByb3ZpZGVycyByZW1haW4uDQo+Pj4+IA0KPj4+PiBPbiBN b24sIE1hciAxMiwgMjAxOCBhdCAxOjUyIFBNLCBCcmlhbiBSb3NlbiA8YnJAYnJpYW5yb3Nlbi5u ZXQ+IHdyb3RlOg0KPj4+Pj4gVGhlcmUgd2FzIGEgbG90IG9mIGRpc2N1c3Npb24gZHVyaW5nIHRo ZSBXR0xDIG9uIHB1c2guIERvZXMgDQo+Pj4+PiBldmVyeW9uZSB0aGluayB0aGVpciBpc3N1ZXMg YXJlIGRlYWx0IHdpdGggc2F0aXNmYWN0b3JpbHkgSSB0aGUgbGF0ZXN0IGRyYWZ0Pw0KPj4+Pj4g DQo+Pj4+PiBCcmlhbg0KPj4+Pj4gDQo+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPj4+Pj4gc2lwY29yZSBtYWlsaW5nIGxpc3QNCj4+Pj4+IHNp cGNvcmVAaWV0Zi5vcmcNCj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc2lwY29yZQ0KPj4+Pj4gDQo+Pj4gDQo+PiANCj4+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBzaXBjb3JlIG1haWxpbmcgbGlzdA0KPj4gc2lw Y29yZUBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9z aXBjb3JlDQoNCg== From nobody Mon Mar 12 08:39:26 2018 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 0039B126D05 for ; Mon, 12 Mar 2018 08:39: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 DqZt-8XREPPx for ; Mon, 12 Mar 2018 08:39:22 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::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 CCFEB120227 for ; Mon, 12 Mar 2018 08:39:21 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id u73so12654913oie.3 for ; Mon, 12 Mar 2018 08:39:21 -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=F33QP9n83iWw5wGAXUMzqfgbKaYVHdXURaANdPTmBLA=; b=pPtVSMOYhDcBPe1NJrKSc8UzFwe8vSkTSS15nabtG6bpcW2naEFxZKT5x8r3MILBng s8Le4SpjYPPxxheykxWg1HiOOUImRY4Mh9UkhXXjC5U+bsHIJAagkHxHS855DZnKR9zD 1HULViTFyqMSGeoIly4qWLaUObn/WDwBS5SgDGSs/UqlYbpMPmGs9nuxWl32RNZuAMje jy6zzbAN/JrDbxmDu3h/rtQayeQyeCidkWffwXlYNR/BkfqiqMkAYJ+moJtMrbYLrjqL GYlnn/b5Nbpxa2rfRparVroObwF7fQ/sBtT5AHjb4NABWHct9JmGwLiLj6EjGeoJG0HG KCFQ== 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=F33QP9n83iWw5wGAXUMzqfgbKaYVHdXURaANdPTmBLA=; b=pE6RtAKRHamL/ZRwD6niAsnkoOnlQDZr9c371vutG+8ofrs2XPZFRxNXw7JVxNzeOD k/zv5gBguWzho8fbOy8nYf6OU+InkVwHsKuzp85a2vtnrH1bBl7v7J2qYGMzpXAvDr8z 4tjzz9JJi1QZu2txw5vDFoAKNJNcWCrIJVlCZrR+OoVQZJCkp1qf4CLbQ1J2NPwjB8S2 roh21qMdnqnsp24cff8oeQzzDpvUm0TlkxL23EOxlJfp6CvyH/buj76aXcJJILhzZCqH DPqHwx5/hi5yMfMfZqtx1QTa2FMZPL6NUJFOdd5P8uP5FLXHZaaHuV0+Zka6U0x96iqg tDbA== X-Gm-Message-State: AElRT7FH04GD6swKwlbrSQWDDTc7Im4vqXX4T5hIvys3n0iZ9XvvS7hP w3x3aiIjjkJKi//pId9vyvtu7nzUe6rSwIpkcS7jog== X-Google-Smtp-Source: AG47ELtWxdLtV1YgVLG4VHVyJFQRyJac0PzhV9oVligi57xfwoWMkDfex8GiO3nxqD15GmAMV08qzwqt5UOM0LQR04E= X-Received: by 10.202.84.132 with SMTP id i126mr4872231oib.295.1520869161146; Mon, 12 Mar 2018 08:39:21 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:1055:0:0:0:0:0 with HTTP; Mon, 12 Mar 2018 08:39:20 -0700 (PDT) In-Reply-To: <72C1D6DE-B67A-4241-ACA8-F9C46D5C4C11@brianrosen.net> References: <7594FB04B1934943A5C02806D1A2204B6C1F1FC6@ESESSMB109.ericsson.se> <72C1D6DE-B67A-4241-ACA8-F9C46D5C4C11@brianrosen.net> From: Martin Thomson Date: Mon, 12 Mar 2018 15:39:20 +0000 Message-ID: To: Brian Rosen Cc: Christer Holmberg , SIPCORE Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [sipcore] -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, 12 Mar 2018 15:39:24 -0000 I'd have to do a proper review. And since I just flew half way around the planet, I'm not sure when that happens. On Mon, Mar 12, 2018 at 3:36 PM, Brian Rosen wrote: > If that gets into the draft, what else do we need? > > Brian > >> On Mar 12, 2018, at 11:34 AM, Martin Thomson = wrote: >> >> FCM supports 8030 in addition to its proprietary interface(s). >> >> ~~~ >> >> The value of the pn-provider URI parameter is "webpush". >> >> The value of the pn-param URI parameter is the subscription URI. >> >> The pn-prid URI parameter is not used and MUST be ignored if present. >> >> See RFC 8030 for details. Note that encryption for web push >> [RFC8291] is not used, therefore parameters for message encryption are >> not defined in this specification. Web push permits the sending of a >> push message without a payload without encryption. >> >> On Mon, Mar 12, 2018 at 3:30 PM, Christer Holmberg >> wrote: >>> Hi Martin, >>> >>> You previously said "FCM supports RFC 8030". I thought that meant that = FCM is based on RFC 8030, i.e. a standardized solution :) >>> >>> But, I have no problem to include a registration for a generic "RFC8030= " service. >>> >>> Since you are the author of RFC 8030, are you able to put provide the r= egistration information? See sections 9 and 10 for examples. >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>> >>> >>> >>> -----Original Message----- >>> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Martin Tho= mson >>> Sent: 12 March 2018 17:12 >>> To: Brian Rosen >>> Cc: SIPCORE >>> Subject: Re: [sipcore] -push >>> >>> You could implement a SIP UA in a browser. I don't know whether this W= ebRTC thing will take off, but it seems both plausible and useful. >>> >>> What "other things" do you refer to specifically? I think that it just= works. >>> >>> The pieces that 8030 needs are partly in place. Christer added a VAPID= reference. He removed the additional elements necessary to convey keys. I= think that was because this is only a poke and the poke carries no informa= tion (and therefore, by 8030, does not need all the encryption bits). >>> >>> I object pretty strongly to this work defining proprietary-only solutio= ns when a standardized solution exists. >>> >>> On Mon, Mar 12, 2018 at 3:02 PM, Brian Rosen wrote: >>>> Can we explore that a bit: >>>> The =E2=80=9Cnon-proprietary=E2=80=9D that exists is RFC8030. >>>> But the implementations of 8030 would need other things to work. >>>> So to make sip-push work with 8030 would mean a bunch of other mechani= sms. >>>> >>>> Is there actual need (i.e. implementations) for 8030 based push? >>>> >>>> Otherwise, while I understand your concern, it would seem that someone= other than Christer should, if they want to, write a draft that would exte= nd push to work with 8030 in practical implementations, pulling in other wo= rk to make it actually work. >>>> >>>> Or did I miss something? My writeup will reflect this objection, so t= he IESG will be aware of it. >>>> >>>> Brian >>>> >>>>> On Mar 12, 2018, at 10:34 AM, Martin Thomson wrote: >>>>> >>>>> My concerns about there only being proprietary push service providers= remain. >>>>> >>>>> On Mon, Mar 12, 2018 at 1:52 PM, Brian Rosen wrot= e: >>>>>> There was a lot of discussion during the WGLC on push. Does everyone >>>>>> think their issues are dealt with satisfactorily I the latest draft? >>>>>> >>>>>> 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 > From nobody Mon Mar 12 08:39:57 2018 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 38532120227 for ; Mon, 12 Mar 2018 08:39:51 -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, 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 0SYmHb4_Wkfw for ; Mon, 12 Mar 2018 08:39:49 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (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 5C3D9126DEE for ; Mon, 12 Mar 2018 08:39:49 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id b198so2705409qkg.9 for ; Mon, 12 Mar 2018 08:39:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=4kFvHs38j2oiGXn5wHJVqOSyMqTaHAPPkEAWLUaJUoU=; b=JtKCAvLI9uXfF/nmkltuvZmXy9NKyppCxvYnOn20UARnWQJgpsjh+lGtfOVPaRqP2+ UYmCigLAAkvyf8zYtO7M4E4z7m+N9Cqhho5yIzAbsGLBxTwvpCe6cI/L7Nq6U/AktwxM 5XV+3dMgBi9CQKmMo8nHur/h8PiV3FT1s1gBD25Ncw93KeIy2WHlDVGv4ArNRJJtkbI1 5HtrqIfcXAk2iMFk4exh52XWQy2cp2VvioS6BhK30DvDp9ihVnoP1HJH5K6B9uNIKZRU xf/F1IjIjQBJC0rSd3ZaO734TAgs+S9CPJSBzba5tAU6739uJnvMT9iXOvRPsXiNUh60 B0Rg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=4kFvHs38j2oiGXn5wHJVqOSyMqTaHAPPkEAWLUaJUoU=; b=PG+c4d9GKrE8AjsJAesdPVvF5xGn0akskvQ0JVmwrD+97Og5nCQ6rUeTkpCgJjbfxG PgOPwGYT9NgcUVxyPw6fo8SL+PZBd/fgHGZBgzVfUw6JSdxVCJ/ie+Ohjh/YAcYcnvnq 8hWGapti2w2iMhwrNM48EHdrxDY9dqYRBK52CV16/j2JR1kH7UuBIhvCgv+doUQo0NNf blMn2sK7SyFyKO43bOxh8nADWkU+P/r03CsdS9/WtAYbtmjN3QpHdHhk1DwEHMHnwOOe OR2JlyFPCDtRdEGYBGQnnaqkFIzENmxNAyry/cSy0XQZamOjtmvGpdb/QbxWNNKJZT4C cEMQ== X-Gm-Message-State: AElRT7GrfJcH8q4LFeOgaYFDloX3cYnua/CKMtE9B6VHi3/VtGl7hnIk L7gSkaNdf5x3DGukJBHL4VVY5w== X-Google-Smtp-Source: AG47ELvs4ImXapokx9e7nHhJI+4kpQ7tsbtu4WIOyTtKu7DnQBziL9jHEyBCXA8PzB2REDGWfFn9eg== X-Received: by 10.55.149.129 with SMTP id x123mr11563917qkd.254.1520869188318; Mon, 12 Mar 2018 08:39:48 -0700 (PDT) Received: from [192.168.0.21] (cpe-66-108-233-234.nyc.res.rr.com. [66.108.233.234]) by smtp.gmail.com with ESMTPSA id u71sm5355487qki.51.2018.03.12.08.39.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Mar 2018 08:39:46 -0700 (PDT) From: Brian Rosen Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_E79EFC83-EFF5-4FCD-810E-2A2BF34BB177" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 12 Mar 2018 11:39:57 -0400 In-Reply-To: <446AD2FF-49DE-4D9E-8B76-6CD066BA94C2@ericsson.com> Cc: Paul Kyzivat , "sipcore@ietf.org" To: Christer Holmberg References: <152025923464.14616.3652723669244846858@ietfa.amsl.com> <45ebda0e-9d23-6338-072b-e6a0142342d1@alum.mit.edu> <446AD2FF-49DE-4D9E-8B76-6CD066BA94C2@ericsson.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-sessiontimer-race-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: Mon, 12 Mar 2018 15:39:51 -0000 --Apple-Mail=_E79EFC83-EFF5-4FCD-810E-2A2BF34BB177 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Chairs want this draft finished. We have an hour, and if we can finish it, let=E2=80=99s do it. If it is = finished, let=E2=80=99s get it on the approval path. I need to publish the agenda today. Brian > On Mar 5, 2018, at 11:41 AM, Christer Holmberg = wrote: >=20 > Hi, >=20 > I forgot to mention that the new version is only because the previous = one was about to expire, so apart from the year there should be no = changes. Sorry for that. >=20 > I will provide some suggestions regarding how to move forward soon. >=20 > Regards, >=20 > Christer >=20 > Sent from my iPhone >=20 > On 5 Mar 2018, at 18.12, Paul Kyzivat > wrote: >=20 >> Christer, >>=20 >> So far I have only skimmed the draft. (I *will* read it more = carefully later.) A couple of comments: >>=20 >> 1) Examples of the cases you are trying to clarify would be helpful. >>=20 >> 2) in 3.1, am I right in concluding this is to cover the situation >> introduced by section 3.2? But doesn't this also eliminate the >> mechanism for overtly turning off session timer by sending an >> invite without session-expires? >>=20 >> Thanks, >> Paul >>=20 >> On 3/5/18 9:13 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 : Session Initiation Protocol (SIP) Session = Timer Glare Handling >>> Author : Christer Holmberg >>> Filename : draft-ietf-sipcore-sessiontimer-race-01.txt >>> Pages : 7 >>> Date : 2018-03-05 >>> Abstract: >>> This document updates RFC 4028, by clarifying the procedures for >>> negotiating usage of the Session Initiation Protocol (SIP) = session >>> timer mechansim, in order to avoid a race condition where both >>> endpoints trigger simultaneous negotiations. >>> The IETF datatracker status page for this draft is: >>> = https://datatracker.ietf.org/doc/draft-ietf-sipcore-sessiontimer-race/ = >>> There are also htmlized versions available at: >>> https://tools.ietf.org/html/draft-ietf-sipcore-sessiontimer-race-01 = >>> = https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-sessiontimer-race= -01 = >>> A diff from the previous version is available at: >>> = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipcore-sessiontimer-race-0= 1 = >>> 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 = >>=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 --Apple-Mail=_E79EFC83-EFF5-4FCD-810E-2A2BF34BB177 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Chairs want this draft finished.

We have an hour, and if we can finish = it, let=E2=80=99s do it.  If it is finished, let=E2=80=99s get it = on the approval path.

I need to publish the agenda today.

Brian

On Mar 5, 2018, at 11:41 AM, Christer = Holmberg <christer.holmberg@ericsson.com> wrote:

Hi,

I forgot to mention that the new version is only because = the previous one was about to expire, so apart from the year there = should be no changes. Sorry for that.

I will provide some suggestions regarding how to move = forward soon.

Regards,

Christer

Sent from my iPhone

On 5 Mar 2018, at 18.12, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

Christer,

So far I have only skimmed the draft. (I *will* read it = more carefully later.) A couple of comments:

1) Examples of the cases you are trying to clarify = would be helpful.

2) in 3.1, am I right in concluding this is to cover = the situation
  introduced by section 3.2?  But = doesn't this also eliminate the
  mechanism for overtly turning off session = timer by sending an
  invite without session-expires?

   Thanks,
   Paul

On 3/5/18 9:13 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 =           : Session = Initiation Protocol (SIP) Session Timer Glare Handling
        Author =          : Christer = Holmberg
  =  Filename        : = draft-ietf-sipcore-sessiontimer-race-01.txt
   Pages =           : = 7
   Date =            : = 2018-03-05
Abstract:
   This document updates RFC 4028, by = clarifying the procedures for
   negotiating usage of the Session Initiation = Protocol (SIP) session
   timer mechansim, in order to avoid a race = condition where both
   endpoints trigger simultaneous = negotiations.
The IETF = datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-sipcore-sessiontime= r-race/
There are also = htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-sipcore-sessiontimer-rac= e-01
https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-sessio= ntimer-race-01
A diff from the = previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipcore-sessiont= imer-race-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

_______________________________________________ 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

= --Apple-Mail=_E79EFC83-EFF5-4FCD-810E-2A2BF34BB177-- From nobody Mon Mar 12 08:40:39 2018 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 E3E32120227 for ; Mon, 12 Mar 2018 08:40:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 YZFRtxICDoAK for ; Mon, 12 Mar 2018 08:40:37 -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 07276126DED for ; Mon, 12 Mar 2018 08:40:37 -0700 (PDT) Received: by mail-qt0-x231.google.com with SMTP id z14so19275437qti.2 for ; Mon, 12 Mar 2018 08:40:36 -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=qEdv9Jl1LSmNbyJtzRzhOf+z3i8jlxZKec7KNCkHnpQ=; b=kcpl2LmwnKxwJ71NjkL8KsYHwAemqKG3sEu+4mPUMODgDM4DzOFY8IaSKivbni6PUS WuMZaGIvbEs873Vgx+S1PgvkSdxC7GOKVENweguTv89HZJn1ot/UUKsS3d9pMwc7ugRo kClA4AZHdla0m1O2QtgQrCIKMOT1YT/48nPx7b63MomoOW1dm+hoF3100PDH0ZZLT9G4 XQcZgP47V5vquAyVYmYBpHcHIitjxn4Two5jz9v9DiHLWIIOUkxEGaHB5rkPpYzlanMN 5Dv/HQB6m/HwNQRFqfsPfTK85s/LfAibC92VV7cx0PkjPi3iVuWUJrN9m7+dnerCMUsw K8VA== 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=qEdv9Jl1LSmNbyJtzRzhOf+z3i8jlxZKec7KNCkHnpQ=; b=iQgOcI6vQwYjo+COLdVew5eW095LPB6UKAP771GIRhxJYFzkUKF/LMjpWwhdh78obJ KRocoIlILE5wtYGYducPRjk+gjTUO4eyYFKa8GmsJoeLVrLPkfdiup6Mbx5vNjWBL1a7 LO/XuSy5Eq14XWi93tsdsHqon9rwcfdGMKNt8fKnQy/78tqGCkKPnYs1spaAYPz9+W32 8MF3Sp0ReAdxnhZlhwTjb7jx67bb5sJVIKylP/YMqTP3pGlQfoTEcRenYCZr6rxMp/NI A5QWRvPF5dYre++uOiMSp/YiS2zcPTGSZnnffEk6/D1pHEHkjxl6t47SJCpBzFqeYNWH kqTA== X-Gm-Message-State: AElRT7Fne2nsw+sO8+vHynoQSQv+NYDrLL1J5ibfe1yJ2vGRYP1yUsdR WOQkk495ABKsrBl8cXhvBhN7XnTaB4A= X-Google-Smtp-Source: AG47ELvQT/ysX68o2H3K+5SFI98uj7/Ix72RsIoxFjdde+8cyT7NlHQpJAE/l6NE0Kp2KZ/KjFuiPA== X-Received: by 10.237.40.34 with SMTP id r31mr12993321qtd.330.1520869235712; Mon, 12 Mar 2018 08:40:35 -0700 (PDT) Received: from [192.168.0.21] (cpe-66-108-233-234.nyc.res.rr.com. [66.108.233.234]) by smtp.gmail.com with ESMTPSA id u71sm5355487qki.51.2018.03.12.08.40.34 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Mar 2018 08:40:34 -0700 (PDT) From: Brian Rosen Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <3D823505-A721-4B97-B636-969767F4E964@brianrosen.net> Date: Mon, 12 Mar 2018 11:40:45 -0400 To: SIPCORE X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [sipcore] Agenda requests 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, 12 Mar 2018 15:40:38 -0000 We=E2=80=99re a bit behind, but any agenda requests for London? Need to = hear from you today. Brian= From nobody Mon Mar 12 08:41:18 2018 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 CB4C8127599 for ; Mon, 12 Mar 2018 08:41:16 -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 h4pH7c6uVnAF for ; Mon, 12 Mar 2018 08:41:15 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::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 64DF7126D05 for ; Mon, 12 Mar 2018 08:41:15 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id f84so6435951qke.12 for ; Mon, 12 Mar 2018 08:41:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=M8Onvmd/etvuo8jLC//SZHWAIKuXBJGQnzxQ17gAbZo=; b=FZhFXN81jQiBd++0g18pPuDF4r2amewreHGi02Wl9ffGNIkUDI7BpERU7xIwYF71uH jDAKhXNTL/Rj8/mqAjIlCeu1cOi26Y1GCR+z/vvLlMv8LzoO/2T+Igm7uZXgeyJDw/RN QPgVZYVGNd9DFN+p7EGllzIB5AvhlJ02UW8A2SHIM8Z9Cg/GbdXzlRC4D6ibs5+H50GX V5otWRAMayEX5mNNPDfztZdPB+nTdiDNRpNn7G5jtGZGp9kshW2Fqwco+p+xNGgFRBc1 KNY8tPu72Aq0ZIrSXaDG+HoFAwW9gbsLxjz1oafKLngpfay6MiwbjdqlfBem9jNUtqkP rt2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=M8Onvmd/etvuo8jLC//SZHWAIKuXBJGQnzxQ17gAbZo=; b=GH5Pymp6GDDpyIsoWP4jnFWs5IHviJ9Ukgm+5O+gC4ErLGRDN9imrd/eTqMCHaOQfA MF6BG1ACAd4VBSLkfhRf7lp58p6YYe9/JDB4oDVmedr4Rj7T5kbSVcAugxxDb7nanwol choLzId76EYkIYPhb1vDnmyH9DDdqTH8xrn6vCS5FWxFq7BTfXdMHWztHlxY8Ql9RRIC x8F2Icy93QSN0xMkFnDVicOuaT+O3gQsLYRDvqCfTSgxFzlIXL+WulK/hDdPuMxVWUR4 RZPOrZOC+ANBkf8PXrdQZzVItcIswbGojSXG76og4zioyg7bcIHG8DLQNBP5OQX6tAij yIbQ== X-Gm-Message-State: AElRT7GpLSo1vPE7v0YGgEVZG54CmH1l8Gc4R/5H3HrXm6USrc6oz5qk K/ymaS7BFIree9/vtLnvfNA3Zw== X-Google-Smtp-Source: AG47ELvEjVYNo5TvGgAknn1WTmBmFHmSigQ30fnROAP9BbUwr6lArnwG3dPFEajokF1qj5lL7esSLA== X-Received: by 10.55.179.130 with SMTP id c124mr8144462qkf.193.1520869274489; Mon, 12 Mar 2018 08:41:14 -0700 (PDT) Received: from [192.168.0.21] (cpe-66-108-233-234.nyc.res.rr.com. [66.108.233.234]) by smtp.gmail.com with ESMTPSA id u71sm5355487qki.51.2018.03.12.08.41.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Mar 2018 08:41:13 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Brian Rosen In-Reply-To: Date: Mon, 12 Mar 2018 11:41:23 -0400 Cc: Christer Holmberg , SIPCORE Content-Transfer-Encoding: quoted-printable Message-Id: <5CBE3F28-B619-4463-8CBD-59BD634BF120@brianrosen.net> References: <7594FB04B1934943A5C02806D1A2204B6C1F1FC6@ESESSMB109.ericsson.se> <72C1D6DE-B67A-4241-ACA8-F9C46D5C4C11@brianrosen.net> To: Martin Thomson X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [sipcore] -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, 12 Mar 2018 15:41:17 -0000 Okay. When it=E2=80=99s out, and you can do so, please let us know. Brian > On Mar 12, 2018, at 11:39 AM, Martin Thomson = wrote: >=20 > I'd have to do a proper review. And since I just flew half way around > the planet, I'm not sure when that happens. >=20 > On Mon, Mar 12, 2018 at 3:36 PM, Brian Rosen = wrote: >> If that gets into the draft, what else do we need? >>=20 >> Brian >>=20 >>> On Mar 12, 2018, at 11:34 AM, Martin Thomson = wrote: >>>=20 >>> FCM supports 8030 in addition to its proprietary interface(s). >>>=20 >>> ~~~ >>>=20 >>> The value of the pn-provider URI parameter is "webpush". >>>=20 >>> The value of the pn-param URI parameter is the subscription URI. >>>=20 >>> The pn-prid URI parameter is not used and MUST be ignored if = present. >>>=20 >>> See RFC 8030 for details. Note that encryption for web push >>> [RFC8291] is not used, therefore parameters for message encryption = are >>> not defined in this specification. Web push permits the sending of = a >>> push message without a payload without encryption. >>>=20 >>> On Mon, Mar 12, 2018 at 3:30 PM, Christer Holmberg >>> wrote: >>>> Hi Martin, >>>>=20 >>>> You previously said "FCM supports RFC 8030". I thought that meant = that FCM is based on RFC 8030, i.e. a standardized solution :) >>>>=20 >>>> But, I have no problem to include a registration for a generic = "RFC8030" service. >>>>=20 >>>> Since you are the author of RFC 8030, are you able to put provide = the registration information? See sections 9 and 10 for examples. >>>>=20 >>>> Regards, >>>>=20 >>>> Christer >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Martin = Thomson >>>> Sent: 12 March 2018 17:12 >>>> To: Brian Rosen >>>> Cc: SIPCORE >>>> Subject: Re: [sipcore] -push >>>>=20 >>>> You could implement a SIP UA in a browser. I don't know whether = this WebRTC thing will take off, but it seems both plausible and useful. >>>>=20 >>>> What "other things" do you refer to specifically? I think that it = just works. >>>>=20 >>>> The pieces that 8030 needs are partly in place. Christer added a = VAPID reference. He removed the additional elements necessary to convey = keys. I think that was because this is only a poke and the poke carries = no information (and therefore, by 8030, does not need all the encryption = bits). >>>>=20 >>>> I object pretty strongly to this work defining proprietary-only = solutions when a standardized solution exists. >>>>=20 >>>> On Mon, Mar 12, 2018 at 3:02 PM, Brian Rosen = wrote: >>>>> Can we explore that a bit: >>>>> The =E2=80=9Cnon-proprietary=E2=80=9D that exists is RFC8030. >>>>> But the implementations of 8030 would need other things to work. >>>>> So to make sip-push work with 8030 would mean a bunch of other = mechanisms. >>>>>=20 >>>>> Is there actual need (i.e. implementations) for 8030 based push? >>>>>=20 >>>>> Otherwise, while I understand your concern, it would seem that = someone other than Christer should, if they want to, write a draft that = would extend push to work with 8030 in practical implementations, = pulling in other work to make it actually work. >>>>>=20 >>>>> Or did I miss something? My writeup will reflect this objection, = so the IESG will be aware of it. >>>>>=20 >>>>> Brian >>>>>=20 >>>>>> On Mar 12, 2018, at 10:34 AM, Martin Thomson = wrote: >>>>>>=20 >>>>>> My concerns about there only being proprietary push service = providers remain. >>>>>>=20 >>>>>> On Mon, Mar 12, 2018 at 1:52 PM, Brian Rosen = wrote: >>>>>>> There was a lot of discussion during the WGLC on push. Does = everyone >>>>>>> think their issues are dealt with satisfactorily I the latest = draft? >>>>>>>=20 >>>>>>> Brian >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> sipcore mailing list >>>>>>> sipcore@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>>>>=20 >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>=20 From nobody Mon Mar 12 08:48:39 2018 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 B9081124D37 for ; Mon, 12 Mar 2018 08:48:25 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-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=ericsson.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 5jcsiKcAugA5 for ; Mon, 12 Mar 2018 08:48:23 -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 2C82C127869 for ; Mon, 12 Mar 2018 08:48:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1520869701; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=+a39LkAISlSw0D7UIk9u3dtoR8mvygFe8h0tdfgqMZE=; b=e210OZMtL17u/uL/CtsQzqANQrshDRRao1JrwZJtPE9+GSa0MP2qDmSzRrZZYP/M qkOtUloKWaxome6OWpiBq4dN7o8zoSUkc178j8ioYIw9hjWtlMTUWTJ8HUoRUVMH FJc80nqUUHEjjGTvGYB6R2WbjYdsNtt6tRAi+LbcHAs=; X-AuditID: c1b4fb3a-35fff700000067b4-a9-5aa6a145bef7 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id BE.8E.26548.541A6AA5; Mon, 12 Mar 2018 16:48:21 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.172]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0382.000; Mon, 12 Mar 2018 16:48:20 +0100 From: Christer Holmberg To: Brian Rosen CC: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-sessiontimer-race-01.txt Thread-Index: AQHTtIw7p1ptmF8ozkitn+4GNAHNCKPBv1oAgAAZOjeACt5PgIAAEmRA Date: Mon, 12 Mar 2018 15:48:20 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B6C1F208C@ESESSMB109.ericsson.se> References: <152025923464.14616.3652723669244846858@ietfa.amsl.com> <45ebda0e-9d23-6338-072b-e6a0142342d1@alum.mit.edu> <446AD2FF-49DE-4D9E-8B76-6CD066BA94C2@ericsson.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.163] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B6C1F208CESESSMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHIsWRmVeSWpSXmKPExsUyM2K7oq7rwmVRBqfvCFo8vT+NzWLFhgOs Fl9/bGJzYPb4+/4Dk8f9b3/ZPZYs+ckUwBzFZZOSmpNZllqkb5fAlfGyaR9jwbFdjBVnnnxh amA8s5Wxi5GTQ0LARGLW+4lMXYxcHEIChxklpj9bAuUsYZSYc/o1axcjBwebgIVE9z9tkAYR AWWJnbc62UHCzAKBEvdaxUHCwgIBEr13O9hAwiJA4U+7jSGq3SQWvNnBDmKzCKhKHHi1nRXE 5hXwlfh/+B87xKbnjBKz3y4AK+IUcJJYueEYG4jNKCAm8f3UGiYQm1lAXOLWk/lMEDcLSCzZ c54ZwhaVePn4HyuErSSxfNoWdoj6fIl7F74zQiwTlDg58wnLBEaRWUhGzUJSNgtJ2SywzzQl 1u/ShyhRlJjS/ZAdwtaQaJ0zlx1ZfAEj+ypG0eLU4uLcdCMjvdSizOTi4vw8vbzUkk2MwFg7 uOW31Q7Gg88dDzEKcDAq8fD2L1gWJcSaWFZcmXuIUYKDWUmE138qUIg3JbGyKrUoP76oNCe1 +BCjNAeLkjivU5pFlJBAemJJanZqakFqEUyWiYNTqoExY13vn2+6vCV3U/yqt8tYzV7jnnnt 8t033+XT/07UZsta+7o0TDL3Y0zV2hOyu1Qedhzp35QtacHD0a6aySGTtb7T7kbZU0euDdEn ll7Kasy6fqX0cmi04FPpm1nZUg32CeevXClOW2F07WfJEfULr9MXi1YJepS/ev33+xrtrwuD C17l8q5WYinOSDTUYi4qTgQAWC7vQLECAAA= Archived-At: Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-sessiontimer-race-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: Mon, 12 Mar 2018 15:48:26 -0000 --_000_7594FB04B1934943A5C02806D1A2204B6C1F208CESESSMB109erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNClNpbmNlIHRoZXJlIGFyZSBjdXJyZW50bHkgbm8gb3BlbiBpc3N1ZXMsIEkgZG9u4oCZ dCB0aGluayB3ZSBuZWVkIHRvIGRpc2N1c3MgaXQgaW4gTG9uZG9uLg0KDQpNeSBzdWdnZXN0aW9u IHdvdWxkIGJlIHRvIG1vdmUgaXQgZm9yd2FyZC4gVGhlbiwgaWYgTWFydGluIChvciBzb21lb25l IGVsc2UpIGZpbmRzIHNvbWUgbWFqb3IgaXNzdWUgd2XigJlsbCBkZWFsIHdpdGggdGhvc2UgKGFu ZCwgaWYgbmVlZGVkLCB3ZSBjYW4gYWx3YXlzIGJyaW5nIGl0IGJhY2sgdG8gdGhlIFdHKS4NCg0K UmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQoNCkZyb206IEJyaWFuIFJvc2VuIFttYWlsdG86YnJA YnJpYW5yb3Nlbi5uZXRdDQpTZW50OiAxMiBNYXJjaCAyMDE4IDE3OjQwDQpUbzogQ2hyaXN0ZXIg SG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4NCkNjOiBQYXVsIEt5eml2 YXQgPHBreXppdmF0QGFsdW0ubWl0LmVkdT47IHNpcGNvcmVAaWV0Zi5vcmcNClN1YmplY3Q6IFJl OiBbc2lwY29yZV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1zaXBjb3JlLXNlc3Npb250aW1lci1y YWNlLTAxLnR4dA0KDQpDaGFpcnMgd2FudCB0aGlzIGRyYWZ0IGZpbmlzaGVkLg0KDQpXZSBoYXZl IGFuIGhvdXIsIGFuZCBpZiB3ZSBjYW4gZmluaXNoIGl0LCBsZXTigJlzIGRvIGl0LiAgSWYgaXQg aXMgZmluaXNoZWQsIGxldOKAmXMgZ2V0IGl0IG9uIHRoZSBhcHByb3ZhbCBwYXRoLg0KDQpJIG5l ZWQgdG8gcHVibGlzaCB0aGUgYWdlbmRhIHRvZGF5Lg0KDQpCcmlhbg0KDQpPbiBNYXIgNSwgMjAx OCwgYXQgMTE6NDEgQU0sIENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmlj c3Nvbi5jb208bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4+IHdyb3RlOg0K DQpIaSwNCg0KSSBmb3Jnb3QgdG8gbWVudGlvbiB0aGF0IHRoZSBuZXcgdmVyc2lvbiBpcyBvbmx5 IGJlY2F1c2UgdGhlIHByZXZpb3VzIG9uZSB3YXMgYWJvdXQgdG8gZXhwaXJlLCBzbyBhcGFydCBm cm9tIHRoZSB5ZWFyIHRoZXJlIHNob3VsZCBiZSBubyBjaGFuZ2VzLiBTb3JyeSBmb3IgdGhhdC4N Cg0KSSB3aWxsIHByb3ZpZGUgc29tZSBzdWdnZXN0aW9ucyByZWdhcmRpbmcgaG93IHRvIG1vdmUg Zm9yd2FyZCBzb29uLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KU2VudCBmcm9tIG15IGlQaG9u ZQ0KDQpPbiA1IE1hciAyMDE4LCBhdCAxOC4xMiwgUGF1bCBLeXppdmF0IDxwa3l6aXZhdEBhbHVt Lm1pdC5lZHU8bWFpbHRvOnBreXppdmF0QGFsdW0ubWl0LmVkdT4+IHdyb3RlOg0KQ2hyaXN0ZXIs DQoNClNvIGZhciBJIGhhdmUgb25seSBza2ltbWVkIHRoZSBkcmFmdC4gKEkgKndpbGwqIHJlYWQg aXQgbW9yZSBjYXJlZnVsbHkgbGF0ZXIuKSBBIGNvdXBsZSBvZiBjb21tZW50czoNCg0KMSkgRXhh bXBsZXMgb2YgdGhlIGNhc2VzIHlvdSBhcmUgdHJ5aW5nIHRvIGNsYXJpZnkgd291bGQgYmUgaGVs cGZ1bC4NCg0KMikgaW4gMy4xLCBhbSBJIHJpZ2h0IGluIGNvbmNsdWRpbmcgdGhpcyBpcyB0byBj b3ZlciB0aGUgc2l0dWF0aW9uDQogIGludHJvZHVjZWQgYnkgc2VjdGlvbiAzLjI/ICBCdXQgZG9l c24ndCB0aGlzIGFsc28gZWxpbWluYXRlIHRoZQ0KICBtZWNoYW5pc20gZm9yIG92ZXJ0bHkgdHVy bmluZyBvZmYgc2Vzc2lvbiB0aW1lciBieSBzZW5kaW5nIGFuDQogIGludml0ZSB3aXRob3V0IHNl c3Npb24tZXhwaXJlcz8NCg0KICAgVGhhbmtzLA0KICAgUGF1bA0KDQpPbiAzLzUvMTggOToxMyBB TSwgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5v cmc+IHdyb3RlOg0KDQpBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUg b24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQpUaGlzIGRyYWZ0IGlzIGEgd29y ayBpdGVtIG9mIHRoZSBTZXNzaW9uIEluaXRpYXRpb24gUHJvdG9jb2wgQ29yZSBXRyBvZiB0aGUg SUVURi4NCiAgICAgICAgVGl0bGUgICAgICAgICAgIDogU2Vzc2lvbiBJbml0aWF0aW9uIFByb3Rv Y29sIChTSVApIFNlc3Npb24gVGltZXIgR2xhcmUgSGFuZGxpbmcNCiAgICAgICAgQXV0aG9yICAg ICAgICAgIDogQ2hyaXN0ZXIgSG9sbWJlcmcNCiAgIEZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWll dGYtc2lwY29yZS1zZXNzaW9udGltZXItcmFjZS0wMS50eHQNCiAgIFBhZ2VzICAgICAgICAgICA6 IDcNCiAgIERhdGUgICAgICAgICAgICA6IDIwMTgtMDMtMDUNCkFic3RyYWN0Og0KICAgVGhpcyBk b2N1bWVudCB1cGRhdGVzIFJGQyA0MDI4LCBieSBjbGFyaWZ5aW5nIHRoZSBwcm9jZWR1cmVzIGZv cg0KICAgbmVnb3RpYXRpbmcgdXNhZ2Ugb2YgdGhlIFNlc3Npb24gSW5pdGlhdGlvbiBQcm90b2Nv bCAoU0lQKSBzZXNzaW9uDQogICB0aW1lciBtZWNoYW5zaW0sIGluIG9yZGVyIHRvIGF2b2lkIGEg cmFjZSBjb25kaXRpb24gd2hlcmUgYm90aA0KICAgZW5kcG9pbnRzIHRyaWdnZXIgc2ltdWx0YW5l b3VzIG5lZ290aWF0aW9ucy4NClRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0 aGlzIGRyYWZ0IGlzOg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0 Zi1zaXBjb3JlLXNlc3Npb250aW1lci1yYWNlLw0KVGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQgdmVy c2lvbnMgYXZhaWxhYmxlIGF0Og0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtc2lwY29yZS1zZXNzaW9udGltZXItcmFjZS0wMQ0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLXNpcGNvcmUtc2Vzc2lvbnRpbWVyLXJhY2UtMDENCkEg ZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCmh0dHBzOi8v d3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXNpcGNvcmUtc2Vzc2lvbnRpbWVy LXJhY2UtMDENClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRl cyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9u IGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmc8aHR0cDovL3Rvb2xzLmll dGYub3JnLz4uDQpJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91 cyBGVFAgYXQ6DQpmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNpcGNvcmUgbWFpbGluZyBs aXN0DQpzaXBjb3JlQGlldGYub3JnPG1haWx0bzpzaXBjb3JlQGlldGYub3JnPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzaXBjb3JlIG1haWxpbmcgbGlzdA0Kc2lw Y29yZUBpZXRmLm9yZzxtYWlsdG86c2lwY29yZUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCnNpcGNvcmUgbWFpbGluZyBsaXN0DQpzaXBjb3JlQGlldGYu b3JnPG1haWx0bzpzaXBjb3JlQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9zaXBjb3JlDQoNCg== --_000_7594FB04B1934943A5C02806D1A2204B6C1F208CESESSMB109erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBw dCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48 L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0i ZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9 ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8 L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8 ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkhpLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+U2luY2UgdGhlcmUgYXJlIGN1cnJl bnRseSBubyBvcGVuIGlzc3VlcywgSSBkb27igJl0IHRoaW5rIHdlIG5lZWQgdG8gZGlzY3VzcyBp dCBpbiBMb25kb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5NeSBz dWdnZXN0aW9uIHdvdWxkIGJlIHRvIG1vdmUgaXQgZm9yd2FyZC4gVGhlbiwgaWYgTWFydGluIChv ciBzb21lb25lIGVsc2UpIGZpbmRzIHNvbWUgbWFqb3IgaXNzdWUgd2XigJlsbCBkZWFsIHdpdGgg dGhvc2UgKGFuZCwgaWYNCiBuZWVkZWQsIHdlIGNhbiBhbHdheXMgYnJpbmcgaXQgYmFjayB0byB0 aGUgV0cpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+UmVnYXJkcyw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkNocmlzdGVyPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20g MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gQnJpYW4g Um9zZW4gW21haWx0bzpickBicmlhbnJvc2VuLm5ldF0NCjxicj4NCjxiPlNlbnQ6PC9iPiAxMiBN YXJjaCAyMDE4IDE3OjQwPGJyPg0KPGI+VG86PC9iPiBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7Y2hy aXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gUGF1bCBLeXpp dmF0ICZsdDtwa3l6aXZhdEBhbHVtLm1pdC5lZHUmZ3Q7OyBzaXBjb3JlQGlldGYub3JnPGJyPg0K PGI+U3ViamVjdDo8L2I+IFJlOiBbc2lwY29yZV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1zaXBj b3JlLXNlc3Npb250aW1lci1yYWNlLTAxLnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkNoYWlycyB3YW50IHRoaXMgZHJhZnQgZmluaXNoZWQuPG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSBoYXZlIGFuIGhvdXIs IGFuZCBpZiB3ZSBjYW4gZmluaXNoIGl0LCBsZXTigJlzIGRvIGl0LiAmbmJzcDtJZiBpdCBpcyBm aW5pc2hlZCwgbGV04oCZcyBnZXQgaXQgb24gdGhlIGFwcHJvdmFsIHBhdGguPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgbmVlZCB0byBwdWJs aXNoIHRoZSBhZ2VuZGEgdG9kYXkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkJyaWFuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNYXIgNSwgMjAxOCwgYXQg MTE6NDEgQU0sIENocmlzdGVyIEhvbG1iZXJnICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIu aG9sbWJlcmdAZXJpY3Nzb24uY29tIj5jaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208L2E+ Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkhpLCA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZm9y Z290IHRvIG1lbnRpb24gdGhhdCB0aGUgbmV3IHZlcnNpb24gaXMgb25seSBiZWNhdXNlIHRoZSBw cmV2aW91cyBvbmUgd2FzIGFib3V0IHRvIGV4cGlyZSwgc28gYXBhcnQgZnJvbSB0aGUgeWVhciB0 aGVyZSBzaG91bGQgYmUgbm8gY2hhbmdlcy4gU29ycnkgZm9yIHRoYXQuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgd2lsbCBwcm92aWRlIHNv bWUgc3VnZ2VzdGlvbnMgcmVnYXJkaW5nIGhvdyB0byBtb3ZlIGZvcndhcmQgc29vbi48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkcyw8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5DaHJpc3RlcjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNlbnQgZnJvbSBteSBpUGhvbmU8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+PGJyPg0KT24gNSBNYXIgMjAxOCwgYXQgMTguMTIsIFBhdWwgS3l6aXZhdCAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnBreXppdmF0QGFsdW0ubWl0LmVkdSI+cGt5eml2YXRAYWx1bS5taXQu ZWR1PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkNocmlzdGVyLDxicj4NCjxicj4NClNvIGZhciBJIGhhdmUgb25seSBz a2ltbWVkIHRoZSBkcmFmdC4gKEkgKndpbGwqIHJlYWQgaXQgbW9yZSBjYXJlZnVsbHkgbGF0ZXIu KSBBIGNvdXBsZSBvZiBjb21tZW50czo8YnI+DQo8YnI+DQoxKSBFeGFtcGxlcyBvZiB0aGUgY2Fz ZXMgeW91IGFyZSB0cnlpbmcgdG8gY2xhcmlmeSB3b3VsZCBiZSBoZWxwZnVsLjxicj4NCjxicj4N CjIpIGluIDMuMSwgYW0gSSByaWdodCBpbiBjb25jbHVkaW5nIHRoaXMgaXMgdG8gY292ZXIgdGhl IHNpdHVhdGlvbjxicj4NCiZuYnNwOyZuYnNwO2ludHJvZHVjZWQgYnkgc2VjdGlvbiAzLjI/ICZu YnNwO0J1dCBkb2Vzbid0IHRoaXMgYWxzbyBlbGltaW5hdGUgdGhlPGJyPg0KJm5ic3A7Jm5ic3A7 bWVjaGFuaXNtIGZvciBvdmVydGx5IHR1cm5pbmcgb2ZmIHNlc3Npb24gdGltZXIgYnkgc2VuZGlu ZyBhbjxicj4NCiZuYnNwOyZuYnNwO2ludml0ZSB3aXRob3V0IHNlc3Npb24tZXhwaXJlcz88YnI+ DQo8YnI+DQombmJzcDsgJm5ic3A7VGhhbmtzLDxicj4NCiZuYnNwOyAmbmJzcDtQYXVsPGJyPg0K PGJyPg0KT24gMy81LzE4IDk6MTMgQU0sIDxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmciPmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvYT4gd3JvdGU6PGJyPg0KPGJyPg0K PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkEgTmV3IEludGVybmV0LURy YWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rv cmllcy48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+VGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgU2Vzc2lvbiBJbml0aWF0aW9uIFBy b3RvY29sIENvcmUgV0cgb2YgdGhlIElFVEYuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwO1RpdGxlICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzogU2Vzc2lvbiBJbml0aWF0aW9uIFByb3RvY29sIChT SVApIFNlc3Npb24gVGltZXIgR2xhcmUgSGFuZGxpbmc8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2tx dW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7QXV0aG9yICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzogQ2hyaXN0ZXIgSG9sbWJlcmc8bzpwPjwvbzpwPjwv cD4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO0Zp bGVuYW1lICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzogZHJhZnQt aWV0Zi1zaXBjb3JlLXNlc3Npb250aW1lci1yYWNlLTAxLnR4dDxvOnA+PC9vOnA+PC9wPg0KPC9i bG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7UGFnZXMgJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 OiA3PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOyAmbmJzcDtEYXRlICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzogMjAxOC0wMy0wNTxvOnA+PC9vOnA+PC9wPg0K PC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BYnN0cmFjdDo8bzpwPjwvbzpw PjwvcD4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7VGhpcyBkb2N1bWVudCB1cGRhdGVzIFJGQyA0MDI4LCBieSBjbGFyaWZ5aW5nIHRoZSBw cm9jZWR1cmVzIGZvcjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDtuZWdvdGlhdGluZyB1c2FnZSBvZiB0aGUgU2Vz c2lvbiBJbml0aWF0aW9uIFByb3RvY29sIChTSVApIHNlc3Npb248bzpwPjwvbzpwPjwvcD4NCjwv YmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7dGlt ZXIgbWVjaGFuc2ltLCBpbiBvcmRlciB0byBhdm9pZCBhIHJhY2UgY29uZGl0aW9uIHdoZXJlIGJv dGg8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7ZW5kcG9pbnRzIHRyaWdnZXIgc2ltdWx0YW5lb3VzIG5lZ290aWF0 aW9ucy48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+VGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6PG86 cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhy ZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtc2lwY29yZS1z ZXNzaW9udGltZXItcmFjZS8iPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWlldGYtc2lwY29yZS1zZXNzaW9udGltZXItcmFjZS88L2E+PG86cD48L286cD48L3A+DQo8L2Js b2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZXJlIGFyZSBhbHNvIGh0bWxpemVk IHZlcnNpb25zIGF2YWlsYWJsZSBhdDo8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtc2lwY29yZS1zZXNzaW9udGltZXItcmFjZS0wMSI+aHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtc2lwY29yZS1zZXNzaW9udGltZXItcmFjZS0wMTwvYT48 bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEg aHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLXNp cGNvcmUtc2Vzc2lvbnRpbWVyLXJhY2UtMDEiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2h0bWwvZHJhZnQtaWV0Zi1zaXBjb3JlLXNlc3Npb250aW1lci1yYWNlLTAxPC9hPjxvOnA+ PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BIGRpZmYg ZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6PG86cD48L286cD48L3A+ DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXNpcGNvcmUtc2Vzc2lvbnRpbWVy LXJhY2UtMDEiPmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXNp cGNvcmUtc2Vzc2lvbnRpbWVyLXJhY2UtMDE8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVv dGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2Ug YSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb248bzpwPjwvbzpw PjwvcD4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dW50aWwgdGhlIGh0 bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCA8YSBocmVmPSJodHRwOi8v dG9vbHMuaWV0Zi5vcmcvIj4NCnRvb2xzLmlldGYub3JnPC9hPi48bzpwPjwvbzpwPjwvcD4NCjwv YmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW50ZXJuZXQtRHJhZnRzIGFyZSBh bHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0OjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9j a3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJmdHA6Ly9mdHAuaWV0Zi5v cmcvaW50ZXJuZXQtZHJhZnRzLyI+ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy88 L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286 cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnNpcGNvcmUgbWFp bGluZyBsaXN0PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxhIGhyZWY9Im1haWx0bzpzaXBjb3JlQGlldGYub3JnIj5zaXBjb3JlQGlldGYub3Jn PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUi Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZTwvYT48bzpwPjwv bzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0Kc2lwY29yZSBt YWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86c2lwY29yZUBpZXRmLm9yZyI+c2lwY29y ZUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3NpcGNvcmUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v c2lwY29yZTwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPg0Kc2lwY29yZSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBo cmVmPSJtYWlsdG86c2lwY29yZUBpZXRmLm9yZyI+c2lwY29yZUBpZXRmLm9yZzwvYT48YnI+DQo8 YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZTwvYT48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_7594FB04B1934943A5C02806D1A2204B6C1F208CESESSMB109erics_-- From nobody Mon Mar 12 10:12:54 2018 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 94813126579 for ; Mon, 12 Mar 2018 10:12:52 -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 gNX9rbWvY5za for ; Mon, 12 Mar 2018 10:12:51 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76F171200C5 for ; Mon, 12 Mar 2018 10:12:51 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id o25so12218454qkl.7 for ; Mon, 12 Mar 2018 10:12:51 -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=ZhXx9Gt8HpVI4sDhbaT1gXO9uN7WtQGofTh9AbfRQy8=; b=T7K8rjvhCcF5nsPAPi5IFdcodmCWflmeaNc0Y5c+FY7L3ZwZjEVm35zY0a4EFq/zRy 7WK7KN7cov1+k8BSD47Ohm7nqHdOBo3eZhVH8T6Ivi4dy99eidtXMsRvlQ4NPoW+SYHZ HhU5atSbzo7Fg9ki/LXJkqgyF8NzG5O+ocgUSh2LA5uKwJ2auMRQytlXWabL+QKUzHEe ve2E3jr08DlAKxuNx4/gPYYLPdYsOtJWSdcFsjockOl78vcfJZ0t4hzqn4hMkySbqpZa DlYEN9dtQVWkxpUr8pyUerPGfPJYUvoqZ0p8hIdzMHvAiTwMKM4tP5ORQuylX+uATjel NDiA== 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=ZhXx9Gt8HpVI4sDhbaT1gXO9uN7WtQGofTh9AbfRQy8=; b=Kk9LGUgY/qDVe8HaEv7nN51dmBETFyKhgbBcvxpbuo4FN+/REBzbulhiDhDB11Nih1 iziaZGQVEZaOXujZ8By+mGBk1T1hRnH5yLuGEgx9dkoPmU9lrD6wA8yN/P+PS50Tf4yR MAejWic896Tou8alWmMQIS6C5szZOb+F5ayABIWIO/zPvNnKXvKL+/NHo0EnG5+Qtn38 LONV6EcEksCU6SGOCCORjWSrhzymXvKsmKUzbiAkBlmFVvbw7pFtXfgVH7E8UKsmePMx tkjxnLG7eBHihgRrwwoJOThe3PbKWrEzvkEc1XhKjPmKBmfUaGEfOigUL06Bcgipuj6f tGfw== X-Gm-Message-State: AElRT7HQ1t8ClkW/IKaJhEyRTVDX368M9eKyRI1nWvxfQCRtKqVFtIwC UM48ry31ImCD/Ylnv9nFiCJ5XDF941M= X-Google-Smtp-Source: AG47ELsLrB4W7t2+ggXhHkW+gMAgitzF5xOWmtEcPRwwSqx9azn/tzfLFz4u0vXmSVsJraImGEGf6w== X-Received: by 10.55.196.2 with SMTP id d2mr8821324qki.223.1520874770283; Mon, 12 Mar 2018 10:12:50 -0700 (PDT) Received: from [172.20.10.2] (83.sub-174-201-10.myvzw.com. [174.201.10.83]) by smtp.gmail.com with ESMTPSA id p19sm5501077qtk.74.2018.03.12.10.12.48 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Mar 2018 10:12:49 -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: <3CE7DE98-7B8C-4D43-A83A-8CF3D1C00A69@brianrosen.net> Date: Mon, 12 Mar 2018 13:12:47 -0400 To: SIPCORE X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [sipcore] session-timer-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: Mon, 12 Mar 2018 17:12:53 -0000 Does anyone think there are remaining issues on this draft? Brian From nobody Mon Mar 12 10:55:58 2018 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 4E6D5126579 for ; Mon, 12 Mar 2018 10:55:57 -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 WvBzVyH3oQkK for ; Mon, 12 Mar 2018 10:55:55 -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 612AE1200C5 for ; Mon, 12 Mar 2018 10:55:55 -0700 (PDT) Received: by mail-pf0-x233.google.com with SMTP id h19so4671471pfd.12 for ; Mon, 12 Mar 2018 10:55:55 -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=il7sqshPWoXZPWBSREgT8k+PYR4yRUGQVghiUJD4lTc=; b=p+r71rdP//N721l51iw8jRbivFEoBHCMtQ7OZkIiZNkkAjBTQq9K3akD23T0CZ00DO EEVHwfyXTa/XgImVUKhHM1mH2INRGeOWVF6mJxSEQrvxVmlKaIHtvEDridmeU+26vJpr B0N2DrhtrMvL8nMzkVZd1w+L5qhnoJtVYUP26MFYcrYYdVDiHxG85jJaMrzOQvUn8lrz Azksop6r6dcQX0PLEo7GryrqnmrkAr3MH7CAEXNsuZPUgXKhiMZol/MiqygZN0FwGT+f 5ZcYYuJVcZ4ox3xdazZHAumDtaHhFMishDg47GATTy8AOhHsTmxFpP/mmEl2JCpUkaHC pTOg== 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=il7sqshPWoXZPWBSREgT8k+PYR4yRUGQVghiUJD4lTc=; b=mGY7nvNbOcVNMNBPJL4oSKr9N2kdzwaOlZgIymdw5pU5VckFD4OsZ40z6mVs0z00bN ohMXIC5D8OPFm1bb2wL8wT3m+VXqc9fA50h5bGGww73qO8Usc/jjCAneOusXd57OpL7M zsM8hrL0cfyIGPaNfAUcLUdUTfG5ZoPG6LacwGSO83jxXfcv2ITM3O44OtYHSga3YgoX LAaXWPz5XJCCdjdwZP9rvs5m7x/pIl6qtFj9tdZKn2e0cM+lCwr4uXtZYXeC6ADFY6Tj xj/hpGx4Fp1ooqr0uY4GO2EFEnO679M7qvlqecPxIDABBZdMBHzra/9AFq29WC1ZDO6R 6msA== X-Gm-Message-State: AElRT7FKDDsmg4Knze76rW8ZAcwlqL/AV7bvocBC6uKi6RKQT656o50m OruwS0pOJD/2mbl0Kc6K1DzgLF7U X-Google-Smtp-Source: AG47ELugkDjQInXBY5auQSJ1q+c3694yTEDCeAApYrytkYW9d70ZaRTS0zgAxTr3aQ6EfP4naFmrvg== X-Received: by 10.99.98.196 with SMTP id w187mr5433299pgb.307.1520877354646; Mon, 12 Mar 2018 10:55:54 -0700 (PDT) Received: from mail-pl0-f46.google.com (mail-pl0-f46.google.com. [209.85.160.46]) by smtp.gmail.com with ESMTPSA id t8sm14746011pgu.48.2018.03.12.10.55.53 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Mar 2018 10:55:53 -0700 (PDT) Received: by mail-pl0-f46.google.com with SMTP id 61-v6so9759293plf.3 for ; Mon, 12 Mar 2018 10:55:53 -0700 (PDT) X-Received: by 2002:a17:902:2cc1:: with SMTP id n59-v6mr8818567plb.215.1520877353654; Mon, 12 Mar 2018 10:55:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.163.70 with HTTP; Mon, 12 Mar 2018 10:55:53 -0700 (PDT) In-Reply-To: References: From: Roman Shpount Date: Mon, 12 Mar 2018 13:55:53 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Brian Rosen Cc: SIPCORE Content-Type: multipart/alternative; boundary="0000000000006960f105673adad6" Archived-At: Subject: Re: [sipcore] -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, 12 Mar 2018 17:55:57 -0000 --0000000000006960f105673adad6 Content-Type: text/plain; charset="UTF-8" Hi All, I have couple of issues with this darft: The first minor issue, is regarding what is supposed to happen when registration expires interval is too short for push notification to be successfully delivered. For instance should proxy refuse registrations with expires set to value which is too small or should it not enabled push support? Specifically, what happens when a new Registration with Expires less then 120 is received by the proxy? If the group agrees what should happen here (refuse registration, refuse push support, do not send push notification), I can write a pull request. The bigger issue for me is regarding how this draft interacts with RFC 5626. Is this a replacement, independent document, or an update? I think SIP push should really be used in conjunction with RFC 5626 and new draft should update how RFC 5626 flows are managed. Specifically, section 5.3.2 should not be about initial dialog or stand-alone requests. It should be tied to the existence of RFC 5626 flows to the client UA. If flow exists, then it should be used for the request. If no flow is present, SIP push notification should be initiated to create the flow. At the same time, procedures in RFC 5626 for flow maintenance and recovery should be updated to use sip push. Regards, _____________ Roman Shpount On Mon, Mar 12, 2018 at 9:52 AM, Brian Rosen wrote: > There was a lot of discussion during the WGLC on push. Does everyone think > their issues are dealt with satisfactorily I the latest draft? > > Brian > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > --0000000000006960f105673adad6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All,

I have couple of iss= ues with this darft:

The first minor issue, is reg= arding what is supposed to happen when registration expires interval is too= short for push notification to be successfully delivered. For instance sho= uld proxy refuse registrations with expires set to value which is too small= or should it not enabled push support? Specifically, what happens when a n= ew Registration with Expires less then 120 is received by the proxy? If the= group agrees what should happen here (refuse registration, refuse push sup= port, do not send push notification), I can write a pull request.

The bigger issue for me is=C2=A0 regarding how this draft i= nteracts with RFC 5626. Is this a replacement, independent document, or an = update?

I think SIP push should really be used in = conjunction with RFC 5626 and new draft should update how RFC 5626 flows ar= e managed. Specifically, section 5.3.2 should not be about initial dialog o= r stand-alone requests. It should be tied to the existence of RFC 5626 flow= s to the client UA. If flow exists, then it should be used for the request.= If no flow is present, SIP push notification should be initiated to create= the flow. At the same time, procedures in RFC 5626 for flow maintenance an= d recovery should be updated to use sip push.

Rega= rds,

_____________
R= oman Shpount

On Mon, Mar 12, 2018 at 9:52 AM, Brian Rosen= <br@brianrosen.net> wrote:
There was a lot of discussion during the WGLC on push. = Does everyone think their issues are dealt with satisfactorily I the latest= draft?

Brian

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

--0000000000006960f105673adad6-- From nobody Mon Mar 12 11:11:11 2018 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 35B9812D86B for ; Mon, 12 Mar 2018 11:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 UpKgiA45W4pU for ; Mon, 12 Mar 2018 11:10:57 -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 780B21200B9 for ; Mon, 12 Mar 2018 11:10:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1520878253; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Z0snE/C2B18Xzp2xqd9/jrztU1whh2HrzN9z/hua72o=; b=ZVmV62Sb3eAcie7n6qq7QTyIl5jI/ZLFvlugXLyDp4tYLLhR9jh0mfSyewUqwtgh ic77yO7z9QStI/hCp9+SWx2MzZdJp0H9x9Cmt5vNcGWP0hgih5JZZuOutjBWhZsM W1tAfJFf0E6OqdFTZKkiV0QD7nr+t48WtIEJ5C/vpYs=; X-AuditID: c1b4fb3a-347ff700000067b4-6f-5aa6c2ad9459 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 81.C7.26548.DA2C6AA5; Mon, 12 Mar 2018 19:10:53 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.172]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0382.000; Mon, 12 Mar 2018 19:10:42 +0100 From: Christer Holmberg To: Roman Shpount , Brian Rosen CC: SIPCORE Thread-Topic: [sipcore] -push Thread-Index: AQHTuglY2BEOxxfeoUSBwdrzyq2mqaPM0eOAgAASBwA= Date: Mon, 12 Mar 2018 18:10:42 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B6C1F249B@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.162] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmkeLIzCtJLcpLzFFi42KZGbE9UHftoWVRBi++61s8vT+NzWLGhanM Fl9/bGJzYPa4/+0vu8eSJT+ZPG5NKQhgjuKySUnNySxLLdK3S+DK+H//DFtBh0TF2jl3mRoY d4h3MXJySAiYSBw51sfWxcjFISRwmFHi16QDLBDOEkaJtS1dQA4HB5uAhUT3P22QBhEBN4lt C5uYQWxmATmJ6x82soGUCAvISJx7JgRRIivRcHgFO4RtJXFh012wchYBVYl5z1exgti8Ar4S Kzq7mCBWTWeUOPRlIiNIglMgUOL0zxNMIDajgJjE91NrmCB2iUvcejKfCeJoAYkle84zQ9ii Ei8f/2OFsJUknv5fwgRyD7OApsT6XfoQrYoSU7ofskPsFZQ4OfMJywRG0VlIps5C6JiFpGMW ko4FjCyrGEWLU4uLc9ONjPRSizKTi4vz8/TyUks2MQKj5uCW31Y7GA8+dzzEKMDBqMTDm7hr WZQQa2JZcWXuIUYJDmYlEd6FO4FCvCmJlVWpRfnxRaU5qcWHGKU5WJTEeZ3SLKKEBNITS1Kz U1MLUotgskwcnFINjBW7pDNKFDWU+HZGLqgxzC7cLH/owk7R+lL/N/4i4fzcAVoBybwlP49z MDKV3F5SvqRsz/1+jd9x5w52TDm2Ol4+27WPrcKJIWepXF3gnAUe51bNf7Pr2I9K3Y5Vikca vC7eT76eUvTl6JGS37GbxPKOHsr+xF61cnq+3wRTBYmGGxMjMpy2K7EUZyQaajEXFScCAP8Y lNmWAgAA Archived-At: Subject: Re: [sipcore] -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, 12 Mar 2018 18:11:05 -0000 SGksDQoNCj5JIGhhdmUgY291cGxlIG9mIGlzc3VlcyB3aXRoIHRoaXMgZGFyZnQ6DQo+DQo+IFRo ZSBmaXJzdCBtaW5vciBpc3N1ZSwgaXMgcmVnYXJkaW5nIHdoYXQgaXMgc3VwcG9zZWQgdG8gaGFw cGVuIHdoZW4gcmVnaXN0cmF0aW9uIGV4cGlyZXMgaW50ZXJ2YWwgaXMgdG9vIA0KPiBzaG9ydCBm b3IgcHVzaCBub3RpZmljYXRpb24gdG8gYmUgc3VjY2Vzc2Z1bGx5IGRlbGl2ZXJlZC4gRm9yIGlu c3RhbmNlIHNob3VsZCBwcm94eSByZWZ1c2UgcmVnaXN0cmF0aW9ucyB3aXRoIA0KPiBleHBpcmVz IHNldCB0byB2YWx1ZSB3aGljaCBpcyB0b28gc21hbGwgb3Igc2hvdWxkIGl0IG5vdCBlbmFibGVk IHB1c2ggc3VwcG9ydD8gU3BlY2lmaWNhbGx5LCB3aGF0IGhhcHBlbnMgDQo+IHdoZW4gYSBuZXcg UmVnaXN0cmF0aW9uIHdpdGggRXhwaXJlcyBsZXNzIHRoZW4gMTIwIGlzIHJlY2VpdmVkIGJ5IHRo ZSBwcm94eT8gSWYgdGhlIGdyb3VwIGFncmVlcyB3aGF0IHNob3VsZCANCj4gaGFwcGVuIGhlcmUg KHJlZnVzZSByZWdpc3RyYXRpb24sIHJlZnVzZSBwdXNoIHN1cHBvcnQsIGRvIG5vdCBzZW5kIHB1 c2ggbm90aWZpY2F0aW9uKSwgSSBjYW4gd3JpdGUgYSBwdWxsIHJlcXVlc3QuDQoNCk15IHN1Z2dl c3Rpb24gaXMgdG8gZWl0aGVyIHJlZnVzZSB0aGUgcmVnaXN0cmF0aW9uLCBvciByZWZ1c2UgcHVz aCBzdXBwb3J0LCBiYXNlZCBvbiBsb2NhbCBwb2xpY3kuDQoNCkkgZG9uJ3QgdGhpbmsgd2Ugc2hv dWxkIG5lZ290aWF0ZSBwdXNoLCBidXQgdGhlbiBub3Qgc2VuZCBwdXNoIG5vdGlmaWNhdGlvbi4N Cg0KLS0tDQoNCj4gVGhlIGJpZ2dlciBpc3N1ZSBmb3IgbWUgaXPCoCByZWdhcmRpbmcgaG93IHRo aXMgZHJhZnQgaW50ZXJhY3RzIHdpdGggUkZDIDU2MjYuIElzIHRoaXMgYSByZXBsYWNlbWVudCwg aW5kZXBlbmRlbnQgZG9jdW1lbnQsIG9yIGFuIHVwZGF0ZT8NCg0KVGhpcyBpcyBhbiBpbmRlcGVu ZGVudCBkb2N1bWVudC4NCg0KPiBJIHRoaW5rIFNJUCBwdXNoIHNob3VsZCByZWFsbHkgYmUgdXNl ZCBpbiBjb25qdW5jdGlvbiB3aXRoIFJGQyA1NjI2IGFuZCBuZXcgZHJhZnQgc2hvdWxkIHVwZGF0 ZSBob3cgUkZDIDU2MjYgZmxvd3MgYXJlIA0KPiBtYW5hZ2VkLiBTcGVjaWZpY2FsbHksIHNlY3Rp b24gNS4zLjIgc2hvdWxkIG5vdCBiZSBhYm91dCBpbml0aWFsIGRpYWxvZyBvciBzdGFuZC1hbG9u ZSByZXF1ZXN0cy4gSXQgc2hvdWxkIGJlIHRpZWQgdG8gdGhlIGV4aXN0ZW5jZSANCj4gb2YgUkZD IDU2MjYgZmxvd3MgdG8gdGhlIGNsaWVudCBVQS4gSWYgZmxvdyBleGlzdHMsIHRoZW4gaXQgc2hv dWxkIGJlIHVzZWQgZm9yIHRoZSByZXF1ZXN0LiBJZiBubyBmbG93IGlzIHByZXNlbnQsIFNJUCBw dXNoIG5vdGlmaWNhdGlvbiANCj4gc2hvdWxkIGJlIGluaXRpYXRlZCB0byBjcmVhdGUgdGhlIGZs b3cuIEF0IHRoZSBzYW1lIHRpbWUsIHByb2NlZHVyZXMgaW4gUkZDIDU2MjYgZm9yIGZsb3cgbWFp bnRlbmFuY2UgYW5kIHJlY292ZXJ5IHNob3VsZCBiZSANCj4gdXBkYXRlZCB0byB1c2Ugc2lwIHB1 c2guDQoNCllvdSBkb24ndCBuZWVkIFJGQyA1NjI2IGluIG9yZGVyIHRvIHVzZSBwdXNoLCBhbmQg dGhlIGRyYWZ0IHdhcyBuZXZlciBpbnRlbmRlZCB0byB1cGRhdGUgUkZDIDU2MjYuDQoNCkhhdmlu ZyBzYWlkIHRoYXQsIGlmIHRoZXJlIGlzIGludGVyZXN0LCB3ZSBjYW4gd3JpdGUgYSBzZXBhcmF0 ZSBkcmFmdCBvbiB1c2luZyBwdXNoIHRvZ2V0aGVyIHdpdGggUkZDIDU2MjYsIGFuZCBkZXNjcmli ZSBob3cgdGhlIGV4aXN0ZW5jZS9ub24tZXhpc3RlbmNlIG9mIGZsb3dzIGNhbiBpbXBhY3QgcHVz aCBub3RpZmljYXRpb25zLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCk9uIE1vbiwgTWFyIDEyLCAyMDE4IGF0IDk6NTIgQU0sIEJyaWFuIFJvc2VuIDxickBi cmlhbnJvc2VuLm5ldD4gd3JvdGU6DQpUaGVyZSB3YXMgYSBsb3Qgb2YgZGlzY3Vzc2lvbiBkdXJp bmcgdGhlIFdHTEMgb24gcHVzaC4gRG9lcyBldmVyeW9uZSB0aGluayB0aGVpciBpc3N1ZXMgYXJl IGRlYWx0IHdpdGggc2F0aXNmYWN0b3JpbHkgSSB0aGUgbGF0ZXN0IGRyYWZ0Pw0KDQpCcmlhbg0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc2lwY29y ZSBtYWlsaW5nIGxpc3QNCnNpcGNvcmVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc2lwY29yZQ0KDQo= From nobody Mon Mar 12 11:33:28 2018 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 C1DD712426E for ; Mon, 12 Mar 2018 11:33:26 -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 gSYNK34jOpBE for ; Mon, 12 Mar 2018 11:33:24 -0700 (PDT) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (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 CAD1F1200F1 for ; Mon, 12 Mar 2018 11:33:24 -0700 (PDT) Received: by mail-pf0-x22e.google.com with SMTP id f80so4724264pfa.8 for ; Mon, 12 Mar 2018 11:33:24 -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=HJ7s5Hl83UNp82GdQKPY95y9vbJefgDBRsOmg2Tr8TM=; b=wYrWe9ImLtlE7jWXXndPE1CS4AX2hTdlTT3uaWWBnUlNHinAT7gQMQ7SyRHXWvFW8N XaHR46q9dub67DJKQbX3ikP0kmdeNRU+627vP3ajdtkpp1HSCQmCQE5NiONnirnvt3TT Ve2epvATK+4FVKFblEuBRxlGpSHwPK5fwHMGsXTlV7jpgj5yEzZ4SUh9llAVaoOT2/ow ynL/PVeC/YZ3kFrtcl16UYAqEp4E7Ho6btNnOWU61cJbM32pMnfl49Rn1YaPqsCQ7EyJ /FE4ChN6L4jRo2Zhq6JP16FKnaSd4zdO7hheKSMnxk1reNYS6Bd2XLCm5c87ct5FKRk9 5izw== 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=HJ7s5Hl83UNp82GdQKPY95y9vbJefgDBRsOmg2Tr8TM=; b=d4DAy/44X3bs/ZAOIe4AmoFd4HM7abNq23Er2Du3gvoyJx9munBrax++hY4Cd6k7zx nZkfNB2u8Vf1bIF5QCcoPEyYBplMTttjVmCxBhmDxebLZ4xdg9OXnRlXmodzCg4ehItx eurPFmBie06Zu3xR4lh5yZltUfJm38se4pr4yM5WDAEhS5ynLLWVqoL701qibK4ba/3I /PFflDd8ZtRKL8uY/vSKvVQm9Y67T/m8kenNlTGKUeJOxgyZsGUnR5K8Pmg5SfUmx7OF x4tyIzD1VAGkaJaTc/0YlF1ZmRXs+KUEcrk5FGikKwTqwyuuFpaNqEUZdJx+JrSjbqeY tKcw== X-Gm-Message-State: AElRT7FZZMnJEDURprMDLtggZ5znM7p7LAcAHGlunCsdPq8cHCo0a0bl 4C2wBITWkWfqzGgly+QOxVPmtnwG X-Google-Smtp-Source: AG47ELtMwZQ2DkG7qIPg0DEBw5K9yKGkGzD6hXw2efOPqTyZXlnTl8a8oMAp3NOstkt/EoCG8+e8WQ== X-Received: by 10.99.97.138 with SMTP id v132mr7314696pgb.138.1520879604000; Mon, 12 Mar 2018 11:33:24 -0700 (PDT) Received: from mail-pl0-f53.google.com (mail-pl0-f53.google.com. [209.85.160.53]) by smtp.gmail.com with ESMTPSA id 76sm17934170pfp.53.2018.03.12.11.33.23 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Mar 2018 11:33:23 -0700 (PDT) Received: by mail-pl0-f53.google.com with SMTP id u13-v6so9824132plq.1 for ; Mon, 12 Mar 2018 11:33:23 -0700 (PDT) X-Received: by 2002:a17:902:d891:: with SMTP id b17-v6mr9195646plz.241.1520879603264; Mon, 12 Mar 2018 11:33:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.163.70 with HTTP; Mon, 12 Mar 2018 11:33:22 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C1F249B@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B6C1F249B@ESESSMB109.ericsson.se> From: Roman Shpount Date: Mon, 12 Mar 2018 14:33:22 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Christer Holmberg Cc: Brian Rosen , SIPCORE Content-Type: multipart/alternative; boundary="0000000000007fb1ca05673b6034" Archived-At: Subject: Re: [sipcore] -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, 12 Mar 2018 18:33:27 -0000 --0000000000007fb1ca05673b6034 Content-Type: text/plain; charset="UTF-8" On Mon, Mar 12, 2018 at 2:10 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > > The first minor issue, is regarding what is supposed to happen when > registration expires interval is too > > short for push notification to be successfully delivered. For instance > should proxy refuse registrations with > > expires set to value which is too small or should it not enabled push > support? Specifically, what happens > > when a new Registration with Expires less then 120 is received by the > proxy? If the group agrees what should > > happen here (refuse registration, refuse push support, do not send push > notification), I can write a pull request. > > My suggestion is to either refuse the registration, or refuse push > support, based on local policy. Do you need me to write a pull request or would you add the appropriate text? > The bigger issue for me is regarding how this draft interacts with RFC > 5626. Is this a replacement, independent document, or an update? > > This is an independent document. I can see that treating this as an independent document helps moving this draft to completion quicker, so this is a good reason to keep this independent. > > I think SIP push should really be used in conjunction with RFC 5626 and > new draft should update how RFC 5626 flows are > > managed. Specifically, section 5.3.2 should not be about initial dialog > or stand-alone requests. It should be tied to the existence > > of RFC 5626 flows to the client UA. If flow exists, then it should be > used for the request. If no flow is present, SIP push notification > > should be initiated to create the flow. At the same time, procedures in > RFC 5626 for flow maintenance and recovery should be > > updated to use sip push. > > You don't need RFC 5626 in order to use push, and the draft was never > intended to update RFC 5626. > > Having said that, if there is interest, we can write a separate draft on > using push together with RFC 5626, and describe how the > existence/non-existence of flows can impact push notifications. > Do you think sip push would ever be used without RFC 5626 or would these two be always deployed together? As it stands, I think these documents are not consistent with each other and RFC 5626 needs an update to make it work with sip push. Regards, _____________ Roman Shpount --0000000000007fb1ca05673b6034 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Mar 12, 2018 at 2:10 PM, Christer Holmberg &= lt;chri= ster.holmberg@ericsson.com> wrote:
> The first minor issue, is regarding what is supposed to= happen when registration expires interval is too
> short for push notification to be successfully delivered. For instance= should proxy refuse registrations with
> expires set to value which is too small or should it not enabled push = support? Specifically, what happens
> when a new Registration with Expires less then 120 is received by the = proxy? If the group agrees what should
> happen here (refuse registration, refuse push support, do not send pus= h notification), I can write a pull request.

My suggestion is to either refuse the registration, or refuse push s= upport, based on local policy.
=C2=A0
Do you nee= d me to write a pull request or would you add the appropriate text?


> The bigger issue for me is=C2=A0 regarding how this draft interacts wi= th RFC 5626. Is this a replacement, independent document, or an update?

This is an independent document.

I c= an see that treating this as an independent document helps moving this draf= t to completion quicker, so this is a good reason to keep this independent.= =C2=A0
=C2=A0
> I think SIP push should really be used in conjunction with RFC 5626 an= d new draft should update how RFC 5626 flows are
> managed. Specifically, section 5.3.2 should not be about initial dialo= g or stand-alone requests. It should be tied to the existence
> of RFC 5626 flows to the client UA. If flow exists, then it should be = used for the request. If no flow is present, SIP push notification
> should be initiated to create the flow. At the same time, procedures i= n RFC 5626 for flow maintenance and recovery should be
> updated to use sip push.

You don't need RFC 5626 in order to use push, and the draft was = never intended to update RFC 5626.

Having said that, if there is interest, we can write a separate draft on us= ing push together with RFC 5626, and describe how the existence/non-existen= ce of flows can impact push notifications.

<= div>Do you think sip push would ever be used without RFC 5626 or would thes= e two be always deployed together? As it stands, I think these documents ar= e not consistent with each other and RFC 5626 needs an update to make it wo= rk with sip push.

Regards,
<= div class=3D"gmail_signature">_____________
Roman Shpount
=C2=A0
--0000000000007fb1ca05673b6034-- From nobody Mon Mar 12 11:34:44 2018 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 9CD72126BFD for ; Mon, 12 Mar 2018 11:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 usTyEI7eAQho for ; Mon, 12 Mar 2018 11:34:41 -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 613401200F1 for ; Mon, 12 Mar 2018 11:34:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1520879679; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=iI5bwvBvv9X2lqcT5hCCTt+l8sLw6lOjwHRQs0UFAiU=; b=Zb6CUYtDZRgGxUlC1M0K4UK8uPNnzIaNR0yrFrUxSUXLKkNyhOGaazOlYd8Xm7FJ b2/ATqPPYxUIaikvRINfHQVdJ5bc/bYWUsJxc+1opXyguL/jA/O/54Wi1wIaB0ef xkIjxvY9V0h5qWll3K0rX9i7MnQMWWR4eNC/N1BjH0o=; X-AuditID: c1b4fb30-799639c000004778-ed-5aa6c83f0e18 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 39.71.18296.F38C6AA5; Mon, 12 Mar 2018 19:34:39 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.172]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0382.000; Mon, 12 Mar 2018 19:34:03 +0100 From: Christer Holmberg To: Martin Thomson CC: Brian Rosen , SIPCORE Thread-Topic: [sipcore] -push Thread-Index: AQHTuglY2BEOxxfeoUSBwdrzyq2mqaPMmZeAgAAH1YCAAAKjgIAAE3cQ///y5ACAAEJykA== Date: Mon, 12 Mar 2018 18:34:03 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B6C1F25AE@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B6C1F1FC6@ESESSMB109.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.162] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmkeLIzCtJLcpLzFFi42KZGbHdVdf+xLIogxs/dCye3p/GZnHtzD9G i68/NrE5MHvc//aX3WPnrLvsHkuW/GQKYI7isklJzcksSy3St0vgymjc0MlS8E2r4uqeN2wN jC80uxg5OSQETCTWtDxk62Lk4hASOMwosbv9GAuEs4RRouPAPeYuRg4ONgELie5/2iANIgK6 EovOPmAHCTML2EsceewHYgoLyEiceyYEUSEr0XB4BTuEHSbx4MoKVhCbRUBVYmHLEhYQm1fA V6LtaB8rxKaFzBJTL3aAJTgFAiX2/tkD1swoICbx/dQaJhCbWUBc4taT+UwQNwtILNlznhnC FpV4+fgfK4StJPH0/xImiNM0Jdbv0odoVZSY0v2QHWKvoMTJmU9YJjCKzkIydRZCxywkHbOQ dCxgZFnFKFqcWpyUm25kpJdalJlcXJyfp5eXWrKJERg1B7f8NtjB+PK54yFGAQ5GJR7eWzuW RQmxJpYVV+YeYpTgYFYS4V24EyjEm5JYWZValB9fVJqTWnyIUZqDRUmc96Qnb5SQQHpiSWp2 ampBahFMlomDU6qBUT7Pw8D3yPKSZcayh1/nOd4+ftl+o8PbIEO/czJFC7s+t67339z3um3l ivnJ7x/OcY49+HvPjwuaR9elr2v60Sbx+nnqymKeaW2XUlfmnHd5uGLxt5wTDFosAu0fyrnC jh/+JdH8uHl9y9wXnx+t1izOthT5+KVq45U/8c8e3TlnUvZMNzuA/4wSS3FGoqEWc1FxIgD0 O6y/lgIAAA== Archived-At: Subject: Re: [sipcore] -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, 12 Mar 2018 18:34:43 -0000 SGksDQoNCkkgaGF2ZSBjcmVhdGVkIGEgcHVsbCByZXF1ZXN0LCBhZGRpbmcgd2VicHVzaC4NCg0K SSBoYWQgYSBsb29rIGF0IFJGQyA4MDMwLCBhbmQgSSBtb2RpZmllZCB0aGUgaW5mb3JtYXRpb24g dGhhdCBpcyBhZGRlZCB0byBwbi1wcmlkIGFuZCBwbi1wYXJhbSwgYmVjYXVzZSBJIHRoaW5rIGJv dGggYXJlIG5lZWRlZC4gUGxlYXNlIGhhdmUgYSBsb29rLg0KDQpodHRwczovL2dpdGh1Yi5jb20v Y2RoNHUvZHJhZnQtc2lwLXB1c2gvcHVsbC8xNA0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoN Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBNYXJ0aW4gVGhvbXNvbiBbbWFpbHRv Om1hcnRpbi50aG9tc29uQGdtYWlsLmNvbV0gDQpTZW50OiAxMiBNYXJjaCAyMDE4IDE3OjM1DQpU bzogQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4NCkNj OiBCcmlhbiBSb3NlbiA8YnJAYnJpYW5yb3Nlbi5uZXQ+OyBTSVBDT1JFIDxzaXBjb3JlQGlldGYu b3JnPg0KU3ViamVjdDogUmU6IFtzaXBjb3JlXSAtcHVzaA0KDQpGQ00gc3VwcG9ydHMgODAzMCBp biBhZGRpdGlvbiB0byBpdHMgcHJvcHJpZXRhcnkgaW50ZXJmYWNlKHMpLg0KDQp+fn4NCg0KICAg VGhlIHZhbHVlIG9mIHRoZSBwbi1wcm92aWRlciBVUkkgcGFyYW1ldGVyIGlzICJ3ZWJwdXNoIi4N Cg0KICAgVGhlIHZhbHVlIG9mIHRoZSBwbi1wYXJhbSBVUkkgcGFyYW1ldGVyIGlzIHRoZSBzdWJz Y3JpcHRpb24gVVJJLg0KDQogICAgVGhlIHBuLXByaWQgVVJJIHBhcmFtZXRlciBpcyBub3QgdXNl ZCBhbmQgTVVTVCBiZSBpZ25vcmVkIGlmIHByZXNlbnQuDQoNCiAgICBTZWUgUkZDIDgwMzAgZm9y IGRldGFpbHMuICBOb3RlIHRoYXQgZW5jcnlwdGlvbiBmb3Igd2ViIHB1c2ggW1JGQzgyOTFdIGlz IG5vdCB1c2VkLCB0aGVyZWZvcmUgcGFyYW1ldGVycyBmb3IgbWVzc2FnZSBlbmNyeXB0aW9uIGFy ZSBub3QgZGVmaW5lZCBpbiB0aGlzIHNwZWNpZmljYXRpb24uICBXZWIgcHVzaCBwZXJtaXRzIHRo ZSBzZW5kaW5nIG9mIGEgcHVzaCBtZXNzYWdlIHdpdGhvdXQgYSBwYXlsb2FkIHdpdGhvdXQgZW5j cnlwdGlvbi4NCg0KT24gTW9uLCBNYXIgMTIsIDIwMTggYXQgMzozMCBQTSwgQ2hyaXN0ZXIgSG9s bWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4gd3JvdGU6DQo+IEhpIE1hcnRp biwNCj4NCj4gWW91IHByZXZpb3VzbHkgc2FpZCAiRkNNIHN1cHBvcnRzIFJGQyA4MDMwIi4gSSB0 aG91Z2h0IHRoYXQgbWVhbnQgdGhhdCANCj4gRkNNIGlzIGJhc2VkIG9uIFJGQyA4MDMwLCBpLmUu IGEgc3RhbmRhcmRpemVkIHNvbHV0aW9uIDopDQo+DQo+IEJ1dCwgSSBoYXZlIG5vIHByb2JsZW0g dG8gaW5jbHVkZSBhIHJlZ2lzdHJhdGlvbiBmb3IgYSBnZW5lcmljICJSRkM4MDMwIiBzZXJ2aWNl Lg0KPg0KPiBTaW5jZSB5b3UgYXJlIHRoZSBhdXRob3Igb2YgUkZDIDgwMzAsIGFyZSB5b3UgYWJs ZSB0byBwdXQgcHJvdmlkZSB0aGUgcmVnaXN0cmF0aW9uIGluZm9ybWF0aW9uPyBTZWUgc2VjdGlv bnMgOSBhbmQgMTAgZm9yIGV4YW1wbGVzLg0KPg0KPiBSZWdhcmRzLA0KPg0KPiBDaHJpc3Rlcg0K Pg0KPg0KPg0KPg0KPg0KPg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBz aXBjb3JlIFttYWlsdG86c2lwY29yZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWFy dGluIA0KPiBUaG9tc29uDQo+IFNlbnQ6IDEyIE1hcmNoIDIwMTggMTc6MTINCj4gVG86IEJyaWFu IFJvc2VuIDxickBicmlhbnJvc2VuLm5ldD4NCj4gQ2M6IFNJUENPUkUgPHNpcGNvcmVAaWV0Zi5v cmc+DQo+IFN1YmplY3Q6IFJlOiBbc2lwY29yZV0gLXB1c2gNCj4NCj4gWW91IGNvdWxkIGltcGxl bWVudCBhIFNJUCBVQSBpbiBhIGJyb3dzZXIuICBJIGRvbid0IGtub3cgd2hldGhlciB0aGlzIFdl YlJUQyB0aGluZyB3aWxsIHRha2Ugb2ZmLCBidXQgaXQgc2VlbXMgYm90aCBwbGF1c2libGUgYW5k IHVzZWZ1bC4NCj4NCj4gV2hhdCAib3RoZXIgdGhpbmdzIiBkbyB5b3UgcmVmZXIgdG8gc3BlY2lm aWNhbGx5PyAgSSB0aGluayB0aGF0IGl0IGp1c3Qgd29ya3MuDQo+DQo+IFRoZSBwaWVjZXMgdGhh dCA4MDMwIG5lZWRzIGFyZSBwYXJ0bHkgaW4gcGxhY2UuICBDaHJpc3RlciBhZGRlZCBhIFZBUElE IHJlZmVyZW5jZS4gIEhlIHJlbW92ZWQgdGhlIGFkZGl0aW9uYWwgZWxlbWVudHMgbmVjZXNzYXJ5 IHRvIGNvbnZleSBrZXlzLiBJIHRoaW5rIHRoYXQgd2FzIGJlY2F1c2UgdGhpcyBpcyBvbmx5IGEg cG9rZSBhbmQgdGhlIHBva2UgY2FycmllcyBubyBpbmZvcm1hdGlvbiAoYW5kIHRoZXJlZm9yZSwg YnkgODAzMCwgZG9lcyBub3QgbmVlZCBhbGwgdGhlIGVuY3J5cHRpb24gYml0cykuDQo+DQo+IEkg b2JqZWN0IHByZXR0eSBzdHJvbmdseSB0byB0aGlzIHdvcmsgZGVmaW5pbmcgcHJvcHJpZXRhcnkt b25seSBzb2x1dGlvbnMgd2hlbiBhIHN0YW5kYXJkaXplZCBzb2x1dGlvbiBleGlzdHMuDQo+DQo+ IE9uIE1vbiwgTWFyIDEyLCAyMDE4IGF0IDM6MDIgUE0sIEJyaWFuIFJvc2VuIDxickBicmlhbnJv c2VuLm5ldD4gd3JvdGU6DQo+PiBDYW4gd2UgZXhwbG9yZSB0aGF0IGEgYml0Og0KPj4gVGhlIOKA nG5vbi1wcm9wcmlldGFyeeKAnSB0aGF0IGV4aXN0cyBpcyBSRkM4MDMwLg0KPj4gQnV0IHRoZSBp bXBsZW1lbnRhdGlvbnMgb2YgODAzMCB3b3VsZCBuZWVkIG90aGVyIHRoaW5ncyB0byB3b3JrLg0K Pj4gU28gdG8gbWFrZSBzaXAtcHVzaCB3b3JrIHdpdGggODAzMCB3b3VsZCBtZWFuIGEgYnVuY2gg b2Ygb3RoZXIgbWVjaGFuaXNtcy4NCj4+DQo+PiBJcyB0aGVyZSBhY3R1YWwgbmVlZCAoaS5lLiBp bXBsZW1lbnRhdGlvbnMpIGZvciA4MDMwIGJhc2VkIHB1c2g/DQo+Pg0KPj4gT3RoZXJ3aXNlLCB3 aGlsZSBJIHVuZGVyc3RhbmQgeW91ciBjb25jZXJuLCBpdCB3b3VsZCBzZWVtIHRoYXQgc29tZW9u ZSBvdGhlciB0aGFuIENocmlzdGVyIHNob3VsZCwgaWYgdGhleSB3YW50IHRvLCB3cml0ZSBhIGRy YWZ0IHRoYXQgd291bGQgZXh0ZW5kIHB1c2ggdG8gd29yayB3aXRoIDgwMzAgaW4gcHJhY3RpY2Fs IGltcGxlbWVudGF0aW9ucywgcHVsbGluZyBpbiBvdGhlciB3b3JrIHRvIG1ha2UgaXQgYWN0dWFs bHkgd29yay4NCj4+DQo+PiBPciBkaWQgSSBtaXNzIHNvbWV0aGluZz8gIE15IHdyaXRldXAgd2ls bCByZWZsZWN0IHRoaXMgb2JqZWN0aW9uLCBzbyB0aGUgSUVTRyB3aWxsIGJlIGF3YXJlIG9mIGl0 Lg0KPj4NCj4+IEJyaWFuDQo+Pg0KPj4+IE9uIE1hciAxMiwgMjAxOCwgYXQgMTA6MzQgQU0sIE1h cnRpbiBUaG9tc29uIDxtYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20+IHdyb3RlOg0KPj4+DQo+Pj4g TXkgY29uY2VybnMgYWJvdXQgdGhlcmUgb25seSBiZWluZyBwcm9wcmlldGFyeSBwdXNoIHNlcnZp Y2UgcHJvdmlkZXJzIHJlbWFpbi4NCj4+Pg0KPj4+IE9uIE1vbiwgTWFyIDEyLCAyMDE4IGF0IDE6 NTIgUE0sIEJyaWFuIFJvc2VuIDxickBicmlhbnJvc2VuLm5ldD4gd3JvdGU6DQo+Pj4+IFRoZXJl IHdhcyBhIGxvdCBvZiBkaXNjdXNzaW9uIGR1cmluZyB0aGUgV0dMQyBvbiBwdXNoLiBEb2VzIA0K Pj4+PiBldmVyeW9uZSB0aGluayB0aGVpciBpc3N1ZXMgYXJlIGRlYWx0IHdpdGggc2F0aXNmYWN0 b3JpbHkgSSB0aGUgbGF0ZXN0IGRyYWZ0Pw0KPj4+Pg0KPj4+PiBCcmlhbg0KPj4+Pg0KPj4+PiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+PiBzaXBj b3JlIG1haWxpbmcgbGlzdA0KPj4+PiBzaXBjb3JlQGlldGYub3JnDQo+Pj4+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZQ0KPj4+Pg0KPj4NCj4NCj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gc2lwY29yZSBtYWls aW5nIGxpc3QNCj4gc2lwY29yZUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NpcGNvcmUNCg== From nobody Mon Mar 12 11:44:07 2018 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 A5ABB126C3D for ; Mon, 12 Mar 2018 11:44:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 tfdhCCgicbOY for ; Mon, 12 Mar 2018 11:44:05 -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 CAADD124207 for ; Mon, 12 Mar 2018 11:44:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1520880243; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=LWWP1v4DXELxyVnJ6ePPqxEBA9eBaRi5jvk96ds9fkg=; b=AdHuVJ1ij2JJyrK7v6wiK/cE6CjhLgVs3upN6u6hGc+NyAopdC9tzZyumBSb/hqx XmujqY3BPXPJnGvz6F/eLWeU8xyNKvbKC8stmSW/VDuk5y8IB3tqh4mmhxF821ov Z5dhLVBnJDQc+mlc66lIcJ+em6vQK0jsxY1Ncb7fxK4=; X-AuditID: c1b4fb3a-347ff700000067b4-63-5aa6ca725397 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 23.24.26548.27AC6AA5; Mon, 12 Mar 2018 19:44:03 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.172]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0382.000; Mon, 12 Mar 2018 19:44:02 +0100 From: Christer Holmberg To: Roman Shpount CC: Brian Rosen , SIPCORE Thread-Topic: [sipcore] -push Thread-Index: AQHTuglY2BEOxxfeoUSBwdrzyq2mqaPM0eOAgAASBwD///hyAIAAERhA Date: Mon, 12 Mar 2018 18:44:02 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B6C1F2614@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B6C1F249B@ESESSMB109.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.162] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgkeLIzCtJLcpLzFFi42KZGbFdUbf41LIogxUPGC2e3p/GZjHjwlRm i68/NrE5MHvc//aX3WPJkp9MHremFAQwR3HZpKTmZJalFunbJXBl3J7fz1jwQLri5YuwBsYW 6S5GDg4JAROJHQ9Duxi5OIQEDjNK/L92nwnCWcIosblpPxNIEZuAhUT3P+0uRk4OEQFVib/f J4OFmQXsJY489gMxhQVkJM49E4KokJVoOLyCHcJ2k9iz4iAjiM0C1LntbydYnFfAV+Ly+wOs EJsWMUks3TSdGSTBKRAo8X37JDCbUUBM4vupNUwgNrOAuMStJ/PBbAkBAYkle84zQ9iiEi8f /2OFsJUknv5fAnWapsT6XfoQrYoSU7ofQu0VlDg58wnLBEbRWUimzkLomIWkYxaSjgWMLKsY RYtTi4tz042M9FKLMpOLi/Pz9PJSSzYxAuPl4JbfVjsYDz53PMQowMGoxMObuGtZlBBrYllx Ze4hRgkOZiUR3oU7gUK8KYmVValF+fFFpTmpxYcYpTlYlMR5ndIsooQE0hNLUrNTUwtSi2Cy TBycUg2McheN9pkt83yx1aKn/8iUHOX0NsegF2dvPX2RdaHhaSbThcywZ3dv6P9hULW27zEr ktpxzWer34P4coGqhtK7cqG966InsBxiOOe/7oHl0U0CnEs/FsioHH9ps8++qMBPUyZvllzY 89x4AXYJFYbrz78e/6r/rOfPZnHnmO8f0msutU83UvmixFKckWioxVxUnAgAkTYEFpMCAAA= Archived-At: Subject: Re: [sipcore] -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, 12 Mar 2018 18:44:06 -0000 SGksDQoNCj4+PiBUaGUgZmlyc3QgbWlub3IgaXNzdWUsIGlzIHJlZ2FyZGluZyB3aGF0IGlzIHN1 cHBvc2VkIHRvIGhhcHBlbiB3aGVuIHJlZ2lzdHJhdGlvbiBleHBpcmVzIGludGVydmFsIGlzIHRv bw0KPj4+IHNob3J0IGZvciBwdXNoIG5vdGlmaWNhdGlvbiB0byBiZSBzdWNjZXNzZnVsbHkgZGVs aXZlcmVkLiBGb3IgaW5zdGFuY2Ugc2hvdWxkIHByb3h5IHJlZnVzZSByZWdpc3RyYXRpb25zIHdp dGgNCj4+PiBleHBpcmVzIHNldCB0byB2YWx1ZSB3aGljaCBpcyB0b28gc21hbGwgb3Igc2hvdWxk IGl0IG5vdCBlbmFibGVkIHB1c2ggc3VwcG9ydD8gU3BlY2lmaWNhbGx5LCB3aGF0IGhhcHBlbnMN Cj4+PiB3aGVuIGEgbmV3IFJlZ2lzdHJhdGlvbiB3aXRoIEV4cGlyZXMgbGVzcyB0aGVuIDEyMCBp cyByZWNlaXZlZCBieSB0aGUgcHJveHk/IElmIHRoZSBncm91cCBhZ3JlZXMgd2hhdCBzaG91bGQN Cj4+PiBoYXBwZW4gaGVyZSAocmVmdXNlIHJlZ2lzdHJhdGlvbiwgcmVmdXNlIHB1c2ggc3VwcG9y dCwgZG8gbm90IHNlbmQgcHVzaCBub3RpZmljYXRpb24pLCBJIGNhbiB3cml0ZSBhIHB1bGwgcmVx dWVzdC4NCj4+Pg0KPj4gTXkgc3VnZ2VzdGlvbiBpcyB0byBlaXRoZXIgcmVmdXNlIHRoZSByZWdp c3RyYXRpb24sIG9yIHJlZnVzZSBwdXNoIHN1cHBvcnQsIGJhc2VkIG9uIGxvY2FsIHBvbGljeS4N Cj7CoA0KPiBEbyB5b3UgbmVlZCBtZSB0byB3cml0ZSBhIHB1bGwgcmVxdWVzdCBvciB3b3VsZCB5 b3UgYWRkIHRoZSBhcHByb3ByaWF0ZSB0ZXh0Pw0KDQpJIGFzc3VtZSBpdCdzIGp1c3QgYSBmZXcg c2VudGVuY2VzIGluIG9uZSBwbGFjZSwgc28gSSBndWVzcyB5b3UgY2FuIHByb3ZpZGUgdGV4dCBp biBhbiBlLW1haWwgcmVwbHkuDQoNCihCdXQsIGlmIHlvdSBwcmVmZXIgYSBwdWxsIHJlcXVlc3Qs IHRoYXQgd29ya3MgdG9vKS4NCg0KLS0tDQoNCj4+IFRoZSBiaWdnZXIgaXNzdWUgZm9yIG1lIGlz wqAgcmVnYXJkaW5nIGhvdyB0aGlzIGRyYWZ0IGludGVyYWN0cyB3aXRoIFJGQyA1NjI2LiBJcyB0 aGlzIGEgcmVwbGFjZW1lbnQsIGluZGVwZW5kZW50IGRvY3VtZW50LCBvciBhbiB1cGRhdGU/DQo+ DQo+IFRoaXMgaXMgYW4gaW5kZXBlbmRlbnQgZG9jdW1lbnQuDQo+DQo+IEkgY2FuIHNlZSB0aGF0 IHRyZWF0aW5nIHRoaXMgYXMgYW4gaW5kZXBlbmRlbnQgZG9jdW1lbnQgaGVscHMgbW92aW5nIHRo aXMgZHJhZnQgdG8gY29tcGxldGlvbiBxdWlja2VyLCBzbyB0aGlzIGlzIGEgZ29vZCByZWFzb24g dG8ga2VlcCB0aGlzIGluZGVwZW5kZW50LsKgDQoNClRoYW5rcyENCg0KPj4gSSB0aGluayBTSVAg cHVzaCBzaG91bGQgcmVhbGx5IGJlIHVzZWQgaW4gY29uanVuY3Rpb24gd2l0aCBSRkMgNTYyNiBh bmQgbmV3IGRyYWZ0IHNob3VsZCB1cGRhdGUgaG93IFJGQyA1NjI2IGZsb3dzIGFyZQ0KPj4gbWFu YWdlZC4gU3BlY2lmaWNhbGx5LCBzZWN0aW9uIDUuMy4yIHNob3VsZCBub3QgYmUgYWJvdXQgaW5p dGlhbCBkaWFsb2cgb3Igc3RhbmQtYWxvbmUgcmVxdWVzdHMuIEl0IHNob3VsZCBiZSB0aWVkIHRv IHRoZSBleGlzdGVuY2UNCj4+IG9mIFJGQyA1NjI2IGZsb3dzIHRvIHRoZSBjbGllbnQgVUEuIElm IGZsb3cgZXhpc3RzLCB0aGVuIGl0IHNob3VsZCBiZSB1c2VkIGZvciB0aGUgcmVxdWVzdC4gSWYg bm8gZmxvdyBpcyBwcmVzZW50LCBTSVAgcHVzaCBub3RpZmljYXRpb24NCj4+IHNob3VsZCBiZSBp bml0aWF0ZWQgdG8gY3JlYXRlIHRoZSBmbG93LiBBdCB0aGUgc2FtZSB0aW1lLCBwcm9jZWR1cmVz IGluIFJGQyA1NjI2IGZvciBmbG93IG1haW50ZW5hbmNlIGFuZCByZWNvdmVyeSBzaG91bGQgYmUN Cj4+IHVwZGF0ZWQgdG8gdXNlIHNpcCBwdXNoLg0KPg0KPiBZb3UgZG9uJ3QgbmVlZCBSRkMgNTYy NiBpbiBvcmRlciB0byB1c2UgcHVzaCwgYW5kIHRoZSBkcmFmdCB3YXMgbmV2ZXIgaW50ZW5kZWQg dG8gdXBkYXRlIFJGQyA1NjI2Lg0KPg0KPj4gSGF2aW5nIHNhaWQgdGhhdCwgaWYgdGhlcmUgaXMg aW50ZXJlc3QsIHdlIGNhbiB3cml0ZSBhIHNlcGFyYXRlIGRyYWZ0IG9uIHVzaW5nIHB1c2ggdG9n ZXRoZXIgd2l0aCBSRkMgNTYyNiwgYW5kIGRlc2NyaWJlIA0KPj4gaG93IHRoZSBleGlzdGVuY2Uv bm9uLWV4aXN0ZW5jZSBvZiBmbG93cyBjYW4gaW1wYWN0IHB1c2ggbm90aWZpY2F0aW9ucy4NCj4N Cj4gRG8geW91IHRoaW5rIHNpcCBwdXNoIHdvdWxkIGV2ZXIgYmUgdXNlZCB3aXRob3V0IFJGQyA1 NjI2IG9yIHdvdWxkIHRoZXNlIHR3byBiZSBhbHdheXMgZGVwbG95ZWQgdG9nZXRoZXI/IA0KDQpJ IEtOT1cgdGhhdCBzaXAgcHVzaCB3aWxsIGJlIHVzZWQgd2l0aG91dCBSRkMgNTYyNiA6KQ0KDQo+ IEFzIGl0IHN0YW5kcywgSSB0aGluayB0aGVzZSBkb2N1bWVudHMgYXJlIG5vdCBjb25zaXN0ZW50 IHdpdGggZWFjaCBvdGhlciBhbmQgUkZDIDU2MjYgbmVlZHMgYW4gdXBkYXRlIHRvIG1ha2UgaXQg d29yayB3aXRoIHNpcCBwdXNoLg0KDQpXZSB3b3VsZCBoYXZlIHRvIGxvb2sgaW50byB0aGF0LCBh bmQgdGhlIGJlc3Qgd2F5IGFzIGZhciBhcyBkb2N1bWVudGF0aW9uIGlzIGNvbmNlcm5lZC4NCg0K UmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KwqANCg== From nobody Mon Mar 12 12:29:41 2018 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 B3C6C126C3D for ; Mon, 12 Mar 2018 12:29:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 WfIlqoa3_frU for ; Mon, 12 Mar 2018 12:29:38 -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 379F7126BFD for ; Mon, 12 Mar 2018 12:29:38 -0700 (PDT) X-AuditID: 12074411-c5fff70000006443-1c-5aa6d521a841 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 0B.DC.25667.125D6AA5; Mon, 12 Mar 2018 15:29:37 -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 w2CJTZRZ002802 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 12 Mar 2018 15:29:37 -0400 To: sipcore@ietf.org References: <3CE7DE98-7B8C-4D43-A83A-8CF3D1C00A69@brianrosen.net> From: Paul Kyzivat Message-ID: Date: Mon, 12 Mar 2018 15:29:35 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <3CE7DE98-7B8C-4D43-A83A-8CF3D1C00A69@brianrosen.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPIsWRmVeSWpSXmKPExsUixO6iqKt4dVmUwf1NchZff2xic2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxr5/DSwFWxgrnq05x9TAOIexi5GTQ0LARKLpwT32LkYuDiGB HUwSjztvM4EkhAR+MEncW6sMYgsLaEq0HLrMDmKLCIhIPJv+j62LkQOoxlHi9vNAkDCbgJbE nEP/WUBsXgF7iUUfp4LNZxFQlTi/8C4ziC0qkCZxqXkrM0SNoMTJmU/A6jkFnCRWf/4PtpZZ wExi3uaHzBC2uMStJ/Oh4vIS29/OYZ7AyD8LSfssJC2zkLTMQtKygJFlFaNcYk5prm5uYmZO cWqybnFyYl5eapGuqV5uZoleakrpJkZISAruYJxxUu4QowAHoxIPb0frsigh1sSy4srcQ4yS HExKorzJ3EAhvqT8lMqMxOKM+KLSnNTiQ4wSHMxKIrwLdwLleFMSK6tSi/JhUtIcLErivHxL 1P2EBNITS1KzU1MLUotgsjIcHEoSvHFXgBoFi1LTUyvSMnNKENJMHJwgw3mAhr+8DDK8uCAx tzgzHSJ/itGeY8One23MHG0rnwDJlosg8saL123MQix5+XmpUuK8pSBtAiBtGaV5cJNh6eYV ozjQo8K8lSAH8ABTFdzsV0BrmYDWXjmxBGRtSSJCSqqBUUZ1Mduqro/avU9amzazvj8gcWr6 XtaXk6r41t7SrryhY/1cZbr8gfJ9Uw6WqfycaXbcnfl41gr7o9JvHiqcPfjrclaZ0Jo/TzjW mVtf+K59P1Zx+jn2zFsyn35bvKlmSZt3J87VnXNCmXP4jQnlsal5gTe63X40CS49mb3S1Nlu Wfvj709knimxFGckGmoxFxUnAgC1KdMJEgMAAA== Archived-At: Subject: Re: [sipcore] session-timer-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: Mon, 12 Mar 2018 19:29:39 -0000 On 3/12/18 1:12 PM, Brian Rosen wrote: > Does anyone think there are remaining issues on this draft? https://mailarchive.ietf.org/arch/msg/sipcore/72wUBwqZtDPjeWFASd2gCWajdbA From nobody Mon Mar 12 12:50:50 2018 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 2B5BC126D0C for ; Mon, 12 Mar 2018 12:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 MqaRQMzwczrB for ; Mon, 12 Mar 2018 12:50:47 -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 43D07126C3D for ; Mon, 12 Mar 2018 12:50:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1520884245; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=6NmmYnEsPCPmgh72Qm20nuHgDrfFftpSVTm0XT8AgTc=; b=NFeyGqdoiixerrm5McJexb4myd6UtWok0MF5x0X/T4JidHNF6oDtMeB1W+1KP7dg ZAc5ww3/CGeJ4IY/vNOKnkwE7ECx4s2TeAzuyNBRM5t/pS7/6UbJJBD7ZGPiwSCp rRPTUZ0EKANoTHdjXRv+f6A/RPRI8Hm+/4+tnmu9yl0=; X-AuditID: c1b4fb3a-347ff700000067b4-73-5aa6da143010 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 7D.57.26548.41AD6AA5; Mon, 12 Mar 2018 20:50:45 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.172]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0382.000; Mon, 12 Mar 2018 20:50:44 +0100 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] session-timer-race Thread-Index: AQHTuiVeVFZW0zgnD02IRMVStdHQA6PM69mAgAAV/2A= Date: Mon, 12 Mar 2018 19:50:43 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B6C1F2866@ESESSMB109.ericsson.se> References: <3CE7DE98-7B8C-4D43-A83A-8CF3D1C00A69@brianrosen.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.162] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUyM2K7ma7orWVRBvevs1us2HCA1eLrj01s Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAlfGrL9vmQsesVbsnLWQuYHxI0sXIyeHhICJ xIppr5lBbCGBw4wSL2ZwdzFyAdlLGCVufF3P1MXIwcEmYCHR/U8bpEZEIFDi6pIJYPXCApoS s8/tYYaIa0lsfrIbyraSeN13lh3EZhFQlTiy/zQriM0r4CvRu281G8Sucok5Z2eA1XAKOEhs 3XMerJdRQEzi+6k1TCA2s4C4xK0n85kg7hSQWAJVIyEgKvHy8T9WCFtJ4un/JVD1OhILdn9i g7C1JZYthPiLV0BQ4uTMJywTGEVmIRk7C0nLLCQts5C0LGBkWcUoWpxaXJybbmSkl1qUmVxc nJ+nl5dasokRGA0Ht/y22sF48LnjIUYBDkYlHt5bF5dFCbEmlhVX5h5ilOBgVhLhXbgTKMSb klhZlVqUH19UmpNafIhRmoNFSZzXKc0iSkggPbEkNTs1tSC1CCbLxMEp1cDYPvVOWzkXg3Z6 F8/qHc1C63+fn+f/P2Br2/Uw1zPWvkKpwrY1izz9nmhWLvKauirLouHmoTs/tK9PMNz+c+2L h1lRL+xXneTIkVCXbF+13Gvxnb/n5lXkMzkmLsv5fWW6osy3jryA/a+SvU7PLsivreGqEQm4 qno4a4/umtXOH0XXfKqr8t6sxFKckWioxVxUnAgAFzUob4ICAAA= Archived-At: Subject: Re: [sipcore] session-timer-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: Mon, 12 Mar 2018 19:50:49 -0000 Hi, Just to clarify: there still are issues.=20 Unfortunately most of my time lately has been consumed by finalizing ICEbis= , but I will re-start the session-timer discussion very soon :) Regards, Christer -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: 12 March 2018 21:30 To: sipcore@ietf.org Subject: Re: [sipcore] session-timer-race On 3/12/18 1:12 PM, Brian Rosen wrote: > Does anyone think there are remaining issues on this draft? https://mailarchive.ietf.org/arch/msg/sipcore/72wUBwqZtDPjeWFASd2gCWajdbA _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From nobody Mon Mar 12 18:09:56 2018 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 0248D1242F7 for ; Mon, 12 Mar 2018 18:09:55 -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, T_RP_MATCHES_RCVD=-0.01, 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 pn4ViLZ2bGNl for ; Mon, 12 Mar 2018 18:09:53 -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 B769612420B for ; Mon, 12 Mar 2018 18:09:53 -0700 (PDT) Received: from [10.0.1.91] (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 w2D19hv8054463 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 12 Mar 2018 20:09:44 -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.91] From: Ben Campbell Message-Id: <1631D04A-5182-4069-88EF-21032FEE763B@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_D18C2565-A421-4B06-91AB-08CCFA778764"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Mon, 12 Mar 2018 20:09:42 -0500 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C1F2866@ESESSMB109.ericsson.se> Cc: Paul Kyzivat , "sipcore@ietf.org" To: Christer Holmberg References: <3CE7DE98-7B8C-4D43-A83A-8CF3D1C00A69@brianrosen.net> <7594FB04B1934943A5C02806D1A2204B6C1F2866@ESESSMB109.ericsson.se> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [sipcore] session-timer-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, 13 Mar 2018 01:09:55 -0000 --Apple-Mail=_D18C2565-A421-4B06-91AB-08CCFA778764 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I=E2=80=99m confused. Is there not a parallel thread where you said = there are no open issues and we should progress the draft? Are both = talking about the same draft? Is the discussion restart likely to happen in time to have a discussion = in London? I gather the alternative is to cancel the session. Thanks, Ben. > On Mar 12, 2018, at 2:50 PM, Christer Holmberg = wrote: >=20 > Hi, >=20 > Just to clarify: there still are issues. >=20 > Unfortunately most of my time lately has been consumed by finalizing = ICEbis, but I will re-start the session-timer discussion very soon :) >=20 > Regards, >=20 > Christer >=20 > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul = Kyzivat > Sent: 12 March 2018 21:30 > To: sipcore@ietf.org > Subject: Re: [sipcore] session-timer-race >=20 > On 3/12/18 1:12 PM, Brian Rosen wrote: >> Does anyone think there are remaining issues on this draft? >=20 > = https://mailarchive.ietf.org/arch/msg/sipcore/72wUBwqZtDPjeWFASd2gCWajdbA >=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 --Apple-Mail=_D18C2565-A421-4B06-91AB-08CCFA778764 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 iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlqnJNYACgkQgFZKbJXz 1A2/RxAAsPkTFP3W5ZgF0dEwOua3pS+NHaiGXLavoEWOgLHQ+WvF0sMF3Z2gL7xj 3OmyLwmbcdlI2VwWPuoJEoEWSAH4B2wHt+bVItUETKjkoH+OV6B//GqC5GCGcob8 lkjKuhjYqUdkKvOofzl7dnelukY1Lnu5UONZR9QnHsVUeqjqamdkNsFCWCd8r4g5 KCL+fF/P/mrG/DUJY9Y9q4o+MPx/seO289XAMsFcPL8om032zOKF2/p8EdmIUIYA 7EjvowqgVDohvku9mFxvySMVNjeauW1yCFVWr/OWn0ZE2sClRV1Z7CXbc1N5Nbhn eS8FUhWStjl1WzT0Ktbu17toe8sL8gYHq6SLtDk7bbXCoR/tniZYWDpJDJ5uGyCV jJJqzqCm/Lk2GW9iDGx+gQSZVHKxVM8fX6GxXfh7ZLbN8tLmkbNfTJ4gUdrmmZL0 EmgoK9D+Y8poGTvR+OJz1+EQwWL7/PeG1KLx61uhUinCzICcGh5FrxN4eHJCswaN Ti2fn3zysSMItJcp2aC2ULCiBT4NDbM7XHu5aurlJHLb92aaVLxlrPeiTSmOZpbp XDmQrmAQrCuFiHYWUR9KlEbt6FiLyVC/u9Ni+fRvb00Nb0Qz2RhZe3mIro5z4yCh Jba81y6laEyoXYmZjDAh5qZD8RX608nsl1OzDiS9x7PpQS1Iarw= =CYif -----END PGP SIGNATURE----- --Apple-Mail=_D18C2565-A421-4B06-91AB-08CCFA778764-- From nobody Tue Mar 13 00:11:06 2018 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 4D20C12AAB6 for ; Tue, 13 Mar 2018 00:11: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_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=ericsson.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 xJ0a2bBYVl2E for ; Tue, 13 Mar 2018 00:11: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 7688D126DCA for ; Tue, 13 Mar 2018 00:11:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1520925061; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=BbcCCXljqkilePCWy0GXpoTEUxIrAXuiq39qds8iCmE=; b=PYnnjeqDLPiHKKP4cojGW2IUBK8/jPntLt4ciNa2z14L0xc32eqMZybAy8FJqVb4 /Qe3koR10m27xikLtZ5BWqjGBB1oA6BDeN0IkDE8q+2PQfZ5crJrhQ0MqEQjxYw1 HlnJQUafxHNRv42zS4luUrdWAwVDLYvCemUBBr1LURs=; X-AuditID: c1b4fb2d-87c029c000005540-74-5aa77985e7ad Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id A9.93.21824.58977AA5; Tue, 13 Mar 2018 08:11:01 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.172]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0382.000; Tue, 13 Mar 2018 08:10:56 +0100 From: Christer Holmberg To: Ben Campbell CC: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] session-timer-race Thread-Index: AQHTuiVeVFZW0zgnD02IRMVStdHQA6PM69mAgAAV/2CAAEkIAIAAhoEA Date: Tue, 13 Mar 2018 07:10:56 +0000 Message-ID: References: <3CE7DE98-7B8C-4D43-A83A-8CF3D1C00A69@brianrosen.net> <7594FB04B1934943A5C02806D1A2204B6C1F2866@ESESSMB109.ericsson.se> <1631D04A-5182-4069-88EF-21032FEE763B@nostrum.com> In-Reply-To: <1631D04A-5182-4069-88EF-21032FEE763B@nostrum.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.17] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <3BF40282364DAF41868B8D8A122EC3EB@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOIsWRmVeSWpSXmKPExsUyM2K7k25r5fIog7MtmhbzO0+zW6zYcIDV 4uuPTWwOzB5/339g8liy5CeTx6ydT1gCmKO4bFJSczLLUov07RK4Ms6vfMdY8IinYsHbP0wN jAe5uhg5OSQETCSezrjHDGILCRxmlLi/va6LkQvIXsIo8eP9WcYuRg4ONgELie5/2iA1IgJK Es+bt7KAhJkFAiXutYqDhIUFNCVaDl1mhyjRktj8ZDczhO0mcXfKXLByFgFViaZtOSBhXgFr iYOn1jFDbPrAKNF28BobSIJTwF7i/L5nrCA2o4CYxPdTa5hAbGYBcYlbT+YzQZwsILFkz3lm CFtU4uXjf2D1ogJ6EhtO3GYH2SUhoCixvF8OolVP4sbUKWwQtrXEnUuX2CFsbYllC18zQ9wj KHFy5hOWCYzis5Bsm4WkfRaS9llI2mchaV/AyLqKUbQ4tbg4N93IWC+1KDO5uDg/Ty8vtWQT IzD6Dm75rbuDcfVrx0OMAhyMSjy8DBXLo4RYE8uKK3MPMUpwMCuJ8Cr/XxYlxJuSWFmVWpQf X1Sak1p8iFGag0VJnPekJ2+UkEB6YklqdmpqQWoRTJaJg1OqgVFZ+kLb7aRt57fq3lhnlPrf 6W4Ae1HNVfFkowblRMddqkwTXxz0Su5VzQyV/bllYc7NFM9HB3lUT6y/pHU3K6L2VMDjT3cd VzJXRIdofZJ9p5WoaFlzwMsxhG/etIA2xhkeEvZOPzocyhhy216pf1qyn+eBgdmX3TqZdnf1 Db4wX719omi/jRJLcUaioRZzUXEiAIq3Hei6AgAA Archived-At: Subject: Re: [sipcore] session-timer-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, 13 Mar 2018 07:11:05 -0000 Hi Ben, >I=B9m confused. Is there not a parallel thread where you said there are no >open issues and we should progress the draft? Are both talking about the >same draft? That was SIP Push :) >Is the discussion restart likely to happen in time to have a discussion >in London? I gather the alternative is to cancel the session. I don=B9t think we need to have a discussion in London. My plan is to restart the discussion asap, and likely also organise a phone call for interested parties. Regards, Christer >> On Mar 12, 2018, at 2:50 PM, Christer Holmberg >> wrote: >>=20 >> Hi, >>=20 >> Just to clarify: there still are issues. >>=20 >> Unfortunately most of my time lately has been consumed by finalizing >>ICEbis, but I will re-start the session-timer discussion very soon :) >>=20 >> Regards, >>=20 >> Christer >>=20 >> -----Original Message----- >> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul >>Kyzivat >> Sent: 12 March 2018 21:30 >> To: sipcore@ietf.org >> Subject: Re: [sipcore] session-timer-race >>=20 >> On 3/12/18 1:12 PM, Brian Rosen wrote: >>> Does anyone think there are remaining issues on this draft? >>=20 >>=20 >>https://mailarchive.ietf.org/arch/msg/sipcore/72wUBwqZtDPjeWFASd2gCWajdbA >>=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 Tue Mar 13 00:18:24 2018 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 0919D12D775 for ; Tue, 13 Mar 2018 00:18:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, T_RP_MATCHES_RCVD=-0.01, 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 J1Vygz5iNzDQ for ; Tue, 13 Mar 2018 00:18:20 -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 8034B12D0C3 for ; Tue, 13 Mar 2018 00:18:20 -0700 (PDT) Received: from [10.0.1.94] (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 w2D7IFl4013525 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 13 Mar 2018 02:18:16 -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.94] Content-Type: multipart/alternative; boundary=Apple-Mail-8639E733-C02B-4B1B-B0B4-79128BFFB611 Mime-Version: 1.0 (1.0) From: Ben Campbell X-Mailer: iPad Mail (15D100) In-Reply-To: Date: Tue, 13 Mar 2018 02:18:15 -0500 Cc: "sipcore@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: References: <3CE7DE98-7B8C-4D43-A83A-8CF3D1C00A69@brianrosen.net> <7594FB04B1934943A5C02806D1A2204B6C1F2866@ESESSMB109.ericsson.se> <1631D04A-5182-4069-88EF-21032FEE763B@nostrum.com> To: Christer Holmberg Archived-At: Subject: Re: [sipcore] session-timer-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, 13 Mar 2018 07:18:23 -0000 --Apple-Mail-8639E733-C02B-4B1B-B0B4-79128BFFB611 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On Mar 13, 2018, at 2:10 AM, Christer Holmberg wrote: >=20 > Hi Ben, >=20 >> I=C2=B9m confused. Is there not a parallel thread where you said there ar= e no >> open issues and we should progress the draft? Are both talking about the >> same draft? >=20 > That was SIP Push :) This one? https://mailarchive.ietf.org/arch/msg/sipcore/QTbGVRszcidMEVQSj0FZ= u-cCBVU Maybe we crossed the streams... >=20 >> Is the discussion restart likely to happen in time to have a discussion >> in London? I gather the alternative is to cancel the session. >=20 > I don=C2=B9t think we need to have a discussion in London. My plan is to > restart the discussion asap, and likely also organise a phone call for > interested parties. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >>> On Mar 12, 2018, at 2:50 PM, Christer Holmberg >>> wrote: >>>=20 >>> Hi, >>>=20 >>> Just to clarify: there still are issues. >>>=20 >>> Unfortunately most of my time lately has been consumed by finalizing >>> ICEbis, but I will re-start the session-timer discussion very soon :) >>>=20 >>> Regards, >>>=20 >>> Christer >>>=20 >>> -----Original Message----- >>> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul >>> Kyzivat >>> Sent: 12 March 2018 21:30 >>> To: sipcore@ietf.org >>> Subject: Re: [sipcore] session-timer-race >>>=20 >>>> On 3/12/18 1:12 PM, Brian Rosen wrote: >>>> Does anyone think there are remaining issues on this draft? >>>=20 >>>=20 >>> https://mailarchive.ietf.org/arch/msg/sipcore/72wUBwqZtDPjeWFASd2gCWajdb= A >>>=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 --Apple-Mail-8639E733-C02B-4B1B-B0B4-79128BFFB611 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


On Mar 1= 3, 2018, at 2:10 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

=
Hi Ben,

I=C2=B9m confused. Is there not a parallel threa= d where you said there are no
open issues and we should progress the draft? Are both talking abou= t the
same draft?

That was SIP Push :)

Maybe we crossed the streams...


Is the discussion r= estart likely to happen in time to have a discussion
=
in London? I gather the alternative is to ca= ncel the session.

I don=C2=B9t= think we need to have a discussion in London. My plan is to
restart the discussion asap, and likely also organise a phone call for
interested parties.

Regards,

Christer




On Mar 12, 2018, at 2:50 PM, Christer Holmberg
<christer.= holmberg@ericsson.com> wrote:

Hi= ,

Just to clarify: there still are issue= s.

Unfortunately most of my time lately h= as been consumed by finalizing
ICEbis, but I will re-start= the session-timer discussion very soon :)

Regards,
<= blockquote type=3D"cite">
Christer

-----Original Message-----
From: sipcor= e [mailto:sipcore-bounces@ietf.o= rg] On Behalf Of Paul
Kyzivat
<= /blockquote>
Sent: 1= 2 March 2018 21:30
To: sipcore@ietf.org
Subject: Re: [sipcore] session-timer-= race

On 3/12/18 1:12 PM, Brian Rosen wr= ote:
Does anyone think there are= remaining issues on this draft?

<= /blockquote>

https://mailarchive.ietf.org/arch/msg/si= pcore/72wUBwqZtDPjeWFASd2gCWajdbA

_= ______________________________________________
sipcore mai= ling 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/li= stinfo/sipcore
= --Apple-Mail-8639E733-C02B-4B1B-B0B4-79128BFFB611-- From nobody Tue Mar 13 00:27:29 2018 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 1470612D775 for ; Tue, 13 Mar 2018 00:27:27 -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, 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=ericsson.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 s9s7Y6NOhWD5 for ; Tue, 13 Mar 2018 00:27:25 -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 4045512D0C3 for ; Tue, 13 Mar 2018 00:27:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1520926043; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=d3a1SVE4UIi7Sk4ee3m14tvCiEnSxAhQ5BpJx2/46r4=; b=MY2NPHbbiYMceRGuQAuZfgqtcgtiNKmaqfObcVDfJugiKOtQ4rLgglKWZbB6rp7t wDQ99Jhc6YD5zxtiM9XKw9ECVupxrOZ5ZdWKk9LUxTRwt5DsRt9Aak7EsP7DGBr1 INgQEaXClsxP0eDWtS5eIDZSjWka90FYgDfEHsEBRuY=; X-AuditID: c1b4fb2d-499ff70000005540-bc-5aa77d5b0444 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id B2.8B.21824.B5D77AA5; Tue, 13 Mar 2018 08:27:23 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.172]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0382.000; Tue, 13 Mar 2018 08:27:22 +0100 From: Christer Holmberg To: Ben Campbell CC: "sipcore@ietf.org" Thread-Topic: [sipcore] session-timer-race Thread-Index: AQHTuiVeVFZW0zgnD02IRMVStdHQA6PM69mAgAAV/2CAAEkIAIAAhoEA///geICAACQfAA== Date: Tue, 13 Mar 2018 07:27:22 +0000 Message-ID: References: <3CE7DE98-7B8C-4D43-A83A-8CF3D1C00A69@brianrosen.net> <7594FB04B1934943A5C02806D1A2204B6C1F2866@ESESSMB109.ericsson.se> <1631D04A-5182-4069-88EF-21032FEE763B@nostrum.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+NgFprHIsWRmVeSWpSXmKPExsUyM2K7um507fIog46byhbzO0+zW3z9sYnN gcljyZKfTB6zdj5hCWCK4rJJSc3JLEst0rdL4Mq4vNWmYBdvxeUX5Q2MV7m6GDk5JARMJO7s fMvYxcjFISRwmFHiwf7P7BDOEkaJ26+/sHUxcnCwCVhIdP/TBmkQEVCSeN68lQXEZhbQlHi0 cy8TiC0MZLccuswOUaMlsfnJbmaQVhGBMImey0ogYRYBVYlfp/cwg9i8AtYSrXvnQO29ziSx /+RjNpAEp4C9xIP7ExlBbEYBMYnvp9YwQewSl7j1ZD4TxNECEkv2nGeGsEUlXj7+xwpiiwro SWw4cZsdIq4o0f60gRGiV0/ixtQpbBC2tUTX5P1QcW2JZQtfQx0kKHFy5hOWCYzis5Csm4Wk fRaS9llI2mchaV/AyLqKUbQ4tbg4N93IWC+1KDO5uDg/Ty8vtWQTIzDWDm75rbuDcfVrx0OM AhyMSjy8DBXLo4RYE8uKK3MPMUpwMCuJ8Cr/XxYlxJuSWFmVWpQfX1Sak1p8iFGag0VJnPek J2+UkEB6YklqdmpqQWoRTJaJg1OqgdG9VqJh+ULTfw+jDrl9U0vu6njHo5LqKV10oJq3RmtX 1Jsney4E28Z7+RbudVY5MWflGsl9NpLtexVdgiZOr9u9+u/lx/MvF0qJOZ19wv+obbHOedEp TxdY32nQtVT5OPVW4rv9UoK75N4esi7J3j/5uIra/OYtRr4XThjuqjRSf54l5FWQIKzEUpyR aKjFXFScCACIVNqHsQIAAA== Archived-At: Subject: Re: [sipcore] session-timer-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, 13 Mar 2018 07:27:27 -0000 >>> I=B9m confused. Is there not a parallel thread where you said there are >>>no >>> open issues and we should progress the draft? Are both talking about >>>the >>> same draft? >> >> That was SIP Push :) > > This one?=20 >https://mailarchive.ietf.org/arch/msg/sipcore/QTbGVRszcidMEVQSj0FZu-cCBVU > > Maybe we crossed the streams... DOH! Ok, that was my mistake. Still, I was talking about SIP Push :) So, just to verify: session-timer-race is NOT yet ready to be moved forward. Regards, Christer On Mar 12, 2018, at 2:50 PM, Christer Holmberg wrote: Hi, Just to clarify: there still are issues. Unfortunately most of my time lately has been consumed by finalizing ICEbis, but I will re-start the session-timer discussion very soon :) Regards, Christer -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: 12 March 2018 21:30 To: sipcore@ietf.org Subject: Re: [sipcore] session-timer-race On 3/12/18 1:12 PM, Brian Rosen wrote: Does anyone think there are remaining issues on this draft? https://mailarchive.ietf.org/arch/msg/sipcore/72wUBwqZtDPjeWFASd2gCWajdbA _______________________________________________ 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 Tue Mar 13 03:55:07 2018 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 DC7A412D77E for ; Tue, 13 Mar 2018 03:55:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 zPymUm9lAQ1n for ; Tue, 13 Mar 2018 03:55:04 -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 8D3FC127201 for ; Tue, 13 Mar 2018 03:55:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1520938502; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=QFJq7KK5J7ggmpdnF2gGKN8tFKn3VQQ8qDrKO0V2ZLQ=; b=Q45tsxV4NmqWhwKrcZ/6+kwjnaA7/Fnc4oTGR3MxxP9F0zaD8SMkPDyzHOebomU/ B+80eHbJZ3/KGkzLoQwoX/+U+5zqU4RCDIOFNF/xABF1adnLHBBz1KEU7eGbnfx8 o7LIdZogb9eqz5Kx6juqq4gd893YOzpOJAbmtKfqgAY=; X-AuditID: c1b4fb2d-87c029c000005540-40-5aa7ae069cad Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 14.62.21824.60EA7AA5; Tue, 13 Mar 2018 11:55:02 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.172]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0382.000; Tue, 13 Mar 2018 11:55:02 +0100 From: Christer Holmberg To: Christer Holmberg , Roman Shpount CC: SIPCORE Thread-Topic: [sipcore] -push Thread-Index: AQHTuglY2BEOxxfeoUSBwdrzyq2mqaPM0eOAgAASBwD///hyAIAAERhAgAEiwIA= Date: Tue, 13 Mar 2018 10:55:01 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B6C1F249B@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C1F2614@ESESSMB109.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C1F2614@ESESSMB109.ericsson.se> 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: text/plain; charset="iso-8859-1" Content-ID: <06070AB874F095408A4651CE54FB67C5@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDIsWRmVeSWpSXmKPExsUyM2K7tC7buuVRBkuvmVnMuDCV2eLrj01s DkweS5b8ZPK4NaUggCmKyyYlNSezLLVI3y6BK2Pqra0sBTP4KxpPfmJqYJzA08XIwSEhYCKx /b5BFyMXh5DAYUaJvlP32CGcJYwS67/NZwEpYhOwkOj+p93FyMkhIhAt8eHDAiYQm1lATuL6 h41sILawgIzEtfaLTBA1shINh1ewQ9h+EitX9IPVsAioSjx4dAPM5hWwljj/9Q0zxK5nTBIT l71hAUlwAjUs/LcXrJlRQEzi+6k1UMvEJW49mQ9mSwgISCzZc54ZwhaVePn4HyuILSqgJ7Hh xG12iMcUJZb3y0G06kncmDqFDSTMDLR3a0MIRFhbYtnC18wQ5whKnJz5hGUCo/gsJMtmIeme hdA9C0n3LCTdCxhZVzGKFqcWF+emGxnrpRZlJhcX5+fp5aWWbGIExtnBLb91dzCufu14iFGA g1GJhzdw5fIoIdbEsuLK3EOMEhzMSiK8Zj1AId6UxMqq1KL8+KLSnNTiQ4zSHCxK4rwnPXmj hATSE0tSs1NTC1KLYLJMHJxSDYy9p6a/nnYk8N2JWZcsX/Ps8ZRmTmeX8LA6Jvi9TkVK5smG 2ealGpd9uswXuU54sv5tvUjI21AX1QN/jeaZJjd+zf+3pV3K/uBeM9X+z9K7Ra7d2TLh9M5l CTe0D/b+zzyUyHggXvH5vEW7/x/jYlBTiGj4xDmrOZP5knfhTf3dh92XaKytObRLiaU4I9FQ i7moOBEAOtGnva8CAAA= Archived-At: Subject: Re: [sipcore] -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, 13 Mar 2018 10:55:06 -0000 Hi, >>>>The first minor issue, is regarding what is supposed to happen when >>>>registration expires interval is too >>>> short for push notification to be successfully delivered. For >>>>instance should proxy refuse registrations with >>>> expires set to value which is too small or should it not enabled push >>>>support? Specifically, what happens >>>> when a new Registration with Expires less then 120 is received by the >>>>proxy? If the group agrees what should >>>> happen here (refuse registration, refuse push support, do not send >>>>push notification), I can write a pull request. >>>> >>> My suggestion is to either refuse the registration, or refuse push >>>support, based on local policy. >>=20 >> Do you need me to write a pull request or would you add the appropriate >>text? > >I assume it's just a few sentences in one place, so I guess you can >provide text in an e-mail reply. > >(But, if you prefer a pull request, that works too). What about the following text: "If the proxy considers the requested registration expiration interval (RFC3261) to be too short, the proxy MUST either send a 423 (Internal Too Brief) response to the REGISTER request or skip the rest of the procedures in this section, and process the REGISTER request using normal SIP procedures. Similarly, when the proxy receives a 2xx response to the REGISTER request, if the proxy considers the registration expiration internal indicated by the registrar too short, the proxy MUST NOT insert a Feature-Caps header field with a 'sip.pns' feature-capability indicator in the response, and the Proxy MUST NOT request push notifications associated with the registration. NOTE: A registration expiration interval is considered too short if the interval is smaller than the time prior to expiration when the proxy requests a push notification.= =B2 Regards, Christer From nobody Tue Mar 13 04:17:46 2018 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 ADD6F12D810 for ; Tue, 13 Mar 2018 04:17:45 -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, 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=ericsson.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 QaYDlRoCqdoj for ; Tue, 13 Mar 2018 04:17:44 -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 14D4A127275 for ; Tue, 13 Mar 2018 04:17:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1520939861; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=clibqoriSzHhT6IAjwnWEHqj0lD8v36WGPtSNYQdRjA=; b=JcBm8MF8E9AuDLd/uea2TZy/TQ3mDk49B8gJohiowN5+f0/WfC9iYCI7V5Rb3BEd AHMomvgrJoqlMn9zpTqb1/RujW+tOk9WtszsE7pTPf8NoSnN39em8pDcrX8AmTgF mj9/2g0nHwoYis2NnCBbON32E951c1EgItbPBXskSSw=; X-AuditID: c1b4fb3a-728f89c0000067b4-53-5aa7b355b060 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 64.80.26548.553B7AA5; Tue, 13 Mar 2018 12:17:41 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.172]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0382.000; Tue, 13 Mar 2018 12:17:33 +0100 From: Christer Holmberg To: Christer Holmberg , Roman Shpount CC: SIPCORE Thread-Topic: [sipcore] -push Thread-Index: AQHTuglY2BEOxxfeoUSBwdrzyq2mqaPM0eOAgAASBwD///hyAIAAERhAgAEiwICAAAZMgA== Date: Tue, 13 Mar 2018 11:17:33 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B6C1F249B@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C1F2614@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.18] Content-Type: text/plain; charset="euc-kr" Content-ID: <8655FEF64186A148AB77EA6FAADA092C@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrAIsWRmVeSWpSXmKPExsUyM2K7k27o5uVRBs1vLCxmXJjKbPH1xyY2 ByaPJUt+MnncmlIQwBTFZZOSmpNZllqkb5fAlfF4Uh9TwR3uil2/u1kaGLdwdzFyckgImEjs 3viCpYuRi0NI4DCjxKKFWxkhnCWMEl3TvgNlODjYBCwkuv9pgzSICERLfPiwgAnEZhaQk7j+ YSMbiC0sICNxrf0iE0SNrETD4RXsEHaYxO0t88HiLAKqEj8mLwar5xWwljj4YQUrxK4ZzBIH l88DK+IUsJGYseEkmM0oICbx/dQaqGXiEreeQAySEBCQWLLnPDOELSrx8vE/VhBbVEBPYsOJ 2+wQcUWJj6/2MUL0akl8+bGPDcK2lji1cR07hK0oMaX7ITvEQYISJ2c+YZnAKD4LybpZSNpn IWmfhaR9FpL2BYysqxhFi1OLi3PTjYz0Uosyk4uL8/P08lJLNjEC4+3glt9WOxgPPnc8xCjA wajEw3tp5fIoIdbEsuLK3EOMEhzMSiK8Zj1AId6UxMqq1KL8+KLSnNTiQ4zSHCxK4rxOaRZR QgLpiSWp2ampBalFMFkmDk6pBsYcHXPdW//lz/boHld64MzZx/RAZc3Ed0fCFXxW/HWOEtln Lv3VtWfCpKM8fWUfvznvjF24fcPvhtO/l8c57/zILPo80fzsVubABf+XHDg/3/EzG3vEtq37 rWN7Xrw6/qatvODvjrm9OTGMzZvL6yYLZAbtLN7Wyb/Lbc/szR16Br3fuWQeJb5TYinOSDTU Yi4qTgQAaP5v+rMCAAA= Archived-At: Subject: Re: [sipcore] -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, 13 Mar 2018 11:17:46 -0000 UHVsbCByZXF1ZXN0Og0KDQpodHRwczovL2dpdGh1Yi5jb20vY2RoNHUvZHJhZnQtc2lwLXB1c2gv cHVsbC8xNQ0KDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KT24gMTMvMDMvMTggMTI6NTUs ICJDaHJpc3RlciBIb2xtYmVyZyIgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4NCndy b3RlOg0KDQo+SWYgdGhlIHByb3h5IGNvbnNpZGVycyB0aGUgcmVxdWVzdGVkIHJlZ2lzdHJhdGlv biBleHBpcmF0aW9uIGludGVydmFsDQo+KFJGQzMyNjEpIHRvIGJlIHRvbyBzaG9ydCwgdGhlDQo+ ICAgIHByb3h5IE1VU1QgZWl0aGVyIHNlbmQgYSA0MjMgKEludGVybmFsIFRvbyBCcmllZikgcmVz cG9uc2UgdG8gdGhlDQo+UkVHSVNURVIgcmVxdWVzdCBvciBza2lwIHRoZSByZXN0DQo+ICAgIG9m IHRoZSBwcm9jZWR1cmVzIGluIHRoaXMgc2VjdGlvbiwgYW5kIHByb2Nlc3MgdGhlIFJFR0lTVEVS IHJlcXVlc3QNCj51c2luZyBub3JtYWwgU0lQIHByb2NlZHVyZXMuDQo+ICAgIFNpbWlsYXJseSwg d2hlbiB0aGUgcHJveHkgcmVjZWl2ZXMgYSAyeHggcmVzcG9uc2UgdG8gdGhlIFJFR0lTVEVSDQo+ cmVxdWVzdCwgaWYgdGhlIHByb3h5IGNvbnNpZGVycw0KPiAgICB0aGUgcmVnaXN0cmF0aW9uIGV4 cGlyYXRpb24gaW50ZXJuYWwgaW5kaWNhdGVkIGJ5IHRoZSByZWdpc3RyYXIgdG9vDQo+c2hvcnQs IHRoZSBwcm94eSBNVVNUIE5PVCBpbnNlcnQNCj4gICAgYSBGZWF0dXJlLUNhcHMgaGVhZGVyIGZp ZWxkIHdpdGggYSAnc2lwLnBucycgZmVhdHVyZS1jYXBhYmlsaXR5DQo+aW5kaWNhdG9yIGluIHRo ZSByZXNwb25zZSwgYW5kIHRoZQ0KPiAgICBQcm94eSBNVVNUIE5PVCByZXF1ZXN0IHB1c2ggbm90 aWZpY2F0aW9ucyBhc3NvY2lhdGVkIHdpdGggdGhlDQo+cmVnaXN0cmF0aW9uLg0KPg0KPiAgICBO T1RFOiBBIHJlZ2lzdHJhdGlvbiBleHBpcmF0aW9uIGludGVydmFsIGlzIGNvbnNpZGVyZWQgdG9v IHNob3J0IGlmDQo+dGhlIGludGVydmFsIGlzIHNtYWxsZXIgdGhhbiB0aGUNCj4gICAgdGltZSBw cmlvciB0byBleHBpcmF0aW9uIHdoZW4gdGhlIHByb3h5IHJlcXVlc3RzIGEgcHVzaCBub3RpZmlj YXRpb24uqfcNCg0K From nobody Tue Mar 13 10:33:56 2018 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 F17651276AF for ; Tue, 13 Mar 2018 10:33:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 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, URIBL_BLOCKED=0.001] 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 9mHkXEteJSfq for ; Tue, 13 Mar 2018 10:33:52 -0700 (PDT) Received: from mail-pl0-x22b.google.com (mail-pl0-x22b.google.com [IPv6:2607:f8b0:400e:c01::22b]) (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 0B88912741D for ; Tue, 13 Mar 2018 10:33:52 -0700 (PDT) Received: by mail-pl0-x22b.google.com with SMTP id w15-v6so201999plq.9 for ; Tue, 13 Mar 2018 10:33:52 -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=BgqjUYGv3Khv9+JsFn32Dz5lJcebMZ4g6qu2gmMOiBc=; b=PFUJMTEegqZgmJPDNQVwLeCgR1YiV+cNFoAbkfex31uEbj1IPQRV1tRuc38Nc11IeZ CRwqYyvOc2RYnNXZdMlC5CHD0tIPkchaXuPvAoHLJzfAvNowt0LLWQnYsFvEnzReHPnD ph9FtzKrlf5e8DkTmQ4z4JE/7QEEzoNS9GAjuHQXuxxHVlTT+mdW1U3QfmRcuohTHdOl 45DxvWccGY9HBmDftbGqUTp7kn9kFbvJIdujMROIBVBkR5VTLu65MJVG4JXm53eDXSnh BLy04hO1FzIS2Q0R7ITlob5v7i7lmc/1xPq14GDqUwxto2QATKWZjpDYyjwYINt5JczL ZqIA== 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=BgqjUYGv3Khv9+JsFn32Dz5lJcebMZ4g6qu2gmMOiBc=; b=STumhUpMHwNZ9VyHm3UgeEEj8usSOvP/SryfUi061/zi0IzEhYoqGw+lhBqzPjy5Vl qDrfWpntNtWjpwzOQDCuf2BIGaIfOC4VyUHTjpmwIRkvvTKMpX9iVNY+5j5c+DG+JVHk h4iKtpR34MQwjABjikGxESKreRQAnAcc83XFcPtQlSgzuJtYROL3yQ6RvQiZh/lSZ4gV GLzUC8vytgT+DweNNF1QtIqHi3qTgerfi+STbcYn67py4/U3sfYrkzNtbrhY6gNq9NCJ 7UO/q9pGlIkjCnZjOaUAWxEdlJ/0TQ7J9HwAbrAeY4IBjD4QkEFYBDnBxCdEy1k9RBxH MMCQ== X-Gm-Message-State: AElRT7HL13PcCX3V48WXAASlR7i7TMg9I9Ysxl2k35UXjWCsiCqm9Cip Oaegw5ylHU9pW0S17xDQqHkI/Tkk X-Google-Smtp-Source: AG47ELt9RgXLsU5aiiRlw4R7IToYHMyXMM45h1l/c3sDZimD9/MM8rLz3887jQVZI9zy7qr7B834ZQ== X-Received: by 2002:a17:902:8:: with SMTP id 8-v6mr1231564pla.291.1520962431085; Tue, 13 Mar 2018 10:33:51 -0700 (PDT) Received: from mail-pl0-f52.google.com (mail-pl0-f52.google.com. [209.85.160.52]) by smtp.gmail.com with ESMTPSA id i125sm1370901pfe.176.2018.03.13.10.33.49 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Mar 2018 10:33:49 -0700 (PDT) Received: by mail-pl0-f52.google.com with SMTP id f23-v6so199838plr.10 for ; Tue, 13 Mar 2018 10:33:49 -0700 (PDT) X-Received: by 2002:a17:902:be0a:: with SMTP id r10-v6mr393385pls.221.1520962429564; Tue, 13 Mar 2018 10:33:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.163.70 with HTTP; Tue, 13 Mar 2018 10:33:49 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B6C1F249B@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C1F2614@ESESSMB109.ericsson.se> From: Roman Shpount Date: Tue, 13 Mar 2018 13:33:49 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Christer Holmberg Cc: SIPCORE Content-Type: multipart/alternative; boundary="00000000000054bdb205674ea9e3" Archived-At: Subject: Re: [sipcore] -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, 13 Mar 2018 17:33:54 -0000 --00000000000054bdb205674ea9e3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Looks good. This clears all my issues for this draft. Regards, _____________ Roman Shpount On Tue, Mar 13, 2018 at 7:17 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Pull request: > > https://github.com/cdh4u/draft-sip-push/pull/15 > > > Regards, > > Christer > > > On 13/03/18 12:55, "Christer Holmberg" > wrote: > > >If the proxy considers the requested registration expiration interval > >(RFC3261) to be too short, the > > proxy MUST either send a 423 (Internal Too Brief) response to the > >REGISTER request or skip the rest > > of the procedures in this section, and process the REGISTER request > >using normal SIP procedures. > > Similarly, when the proxy receives a 2xx response to the REGISTER > >request, if the proxy considers > > the registration expiration internal indicated by the registrar too > >short, the proxy MUST NOT insert > > a Feature-Caps header field with a 'sip.pns' feature-capability > >indicator in the response, and the > > Proxy MUST NOT request push notifications associated with the > >registration. > > > > NOTE: A registration expiration interval is considered too short if > >the interval is smaller than the > > time prior to expiration when the proxy requests a push notification= .=C2=B2 > > --00000000000054bdb205674ea9e3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Looks good.
This clears all my issues f= or this draft.

Regards,

_____________
Roman Shpount

On Tue, Mar 13, 2018 at 7:17 AM, Christer Ho= lmberg <christer.holmberg@ericsson.com> wrote:<= br>
Pull request:

https://github.com/cdh4u/draft-sip-push/pull/15<= /a>


Regards,

Christer


On 13/03/18 12:55, "Christer Holmberg" <christer.holmberg@ericsson.com>
wrote:

>If the proxy considers the requested registration expiration interval >(RFC3261) to be too short, the
>=C2=A0 =C2=A0 proxy MUST either send a 423 (Internal Too Brief) respons= e to the
>REGISTER request or skip the rest
>=C2=A0 =C2=A0 of the procedures in this section, and process the REGIST= ER request
>using normal SIP procedures.
>=C2=A0 =C2=A0 Similarly, when the proxy receives a 2xx response to the = REGISTER
>request, if the proxy considers
>=C2=A0 =C2=A0 the registration expiration internal indicated by the reg= istrar too
>short, the proxy MUST NOT insert
>=C2=A0 =C2=A0 a Feature-Caps header field with a 'sip.pns' feat= ure-capability
>indicator in the response, and the
>=C2=A0 =C2=A0 Proxy MUST NOT request push notifications associated with= the
>registration.
>
>=C2=A0 =C2=A0 NOTE: A registration expiration interval is considered to= o short if
>the interval is smaller than the
>=C2=A0 =C2=A0 time prior to expiration when the proxy requests a push n= otification.=C2=B2


--00000000000054bdb205674ea9e3-- From nobody Tue Mar 13 11:57:08 2018 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 2D86612D86C for ; Tue, 13 Mar 2018 11:57:07 -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, 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=ericsson.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 cHSSXGVtDjNG for ; Tue, 13 Mar 2018 11:57:05 -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 F087D129C6C for ; Tue, 13 Mar 2018 11:57:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1520967423; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=/Jvzzdy8Tr8NBoTZTc4F2WlGEMU3jO8TfRSIE3bdUbI=; b=ZAFEQF++/DSpkna7h2bolNESZ0czts1RVswwaC626UZO66qMbvVCfx9FjWmqS2CM WhCKTPedYKeKkS3f4ThQdP3RTTozswZoqs929zW2sUbWVR8mi5FeqgRyFfyV7/CK K4m7sM99IcfdzEZQtg15xn5b8HI5GMPfI3EiIq85w78=; X-AuditID: c1b4fb3a-728f89c0000067b4-28-5aa81effeb94 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 44.97.26548.FFE18AA5; Tue, 13 Mar 2018 19:57:03 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.172]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0382.000; Tue, 13 Mar 2018 19:57:02 +0100 From: Christer Holmberg To: Roman Shpount CC: SIPCORE Thread-Topic: [sipcore] -push Thread-Index: AQHTuglY2BEOxxfeoUSBwdrzyq2mqaPM0eOAgAASBwD///hyAIAAERhAgAEiwICAAAZMgIAAR46AgAAn9RA= Date: Tue, 13 Mar 2018 18:57:02 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B6C200872@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B6C1F249B@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C1F2614@ESESSMB109.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.170] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B6C200872ESESSMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAIsWRmVeSWpSXmKPExsUyM2K7h+5/uRVRBr8uClvMuDCV2eLrj01s DkweS5b8ZPK4NaUggCmKyyYlNSezLLVI3y6BK6N/x3PGgiWBFedfvWVtYGzx72Lk4JAQMJH4 Ncuqi5GLQ0jgMKPEhNZ3zF2MnEDOEkaJ9r5SkBo2AQuJ7n/aIGERAVWJv98nM4HYzAJyEtc/ bGQDKREWkJE490wIokRWouHwCnYIO0li1b9NrCA2C1Drm/6FYK28Ar4SE/snskKsncgi0Xdm KSNIglMgUOLf6UVgRYwCYhLfT62B2iUucevJfDBbQkBAYsme88wQtqjEy8f/WCFsJYkzm56z QNTnS3za+oYZYpmgxMmZT1gmMIrMQjJqFpKyWUjKZgG9wyygKbF+lz5EiaLElO6H7BC2hkTr nLnsyOILGNlXMYoWpxYX56YbGemlFmUmFxfn5+nlpZZsYgTG08Etv612MB587niIUYCDUYmH N5lnRZQQa2JZcWXuIUYJDmYlEd6tMkAh3pTEyqrUovz4otKc1OJDjNIcLErivE5pFlFCAumJ JanZqakFqUUwWSYOTqkGxgTJ9ri96dMeL9/geX9ybUTYI8fL38+76Onku7jHxv6YpPeNYcGe a69emARIL6o+Ipt3N9OpIZB30zTD7a/iQqztJt8+3SK9xJZ/5lSmlR/btbu79aJnV9mcNefO 9Ej20Ajkv5mp96youZjh4zWptp3KO/de6TPSOqXhK1TwKumDnv2Df3zdSizFGYmGWsxFxYkA cUPthaMCAAA= Archived-At: Subject: Re: [sipcore] -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, 13 Mar 2018 18:57:07 -0000 --_000_7594FB04B1934943A5C02806D1A2204B6C200872ESESSMB109erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzLCBSb21hbiENCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KRnJvbTogUm9tYW4gU2hw b3VudCBbbWFpbHRvOnJvbWFuQHRlbHVyaXguY29tXQ0KU2VudDogMTMgTWFyY2ggMjAxOCAxOToz NA0KVG86IENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+ DQpDYzogU0lQQ09SRSA8c2lwY29yZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbc2lwY29yZV0g LXB1c2gNCg0KTG9va3MgZ29vZC4NClRoaXMgY2xlYXJzIGFsbCBteSBpc3N1ZXMgZm9yIHRoaXMg ZHJhZnQuDQoNClJlZ2FyZHMsDQoNCl9fX19fX19fX19fX18NClJvbWFuIFNocG91bnQNCg0KT24g VHVlLCBNYXIgMTMsIDIwMTggYXQgNzoxNyBBTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVy LmhvbG1iZXJnQGVyaWNzc29uLmNvbTxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24u Y29tPj4gd3JvdGU6DQpQdWxsIHJlcXVlc3Q6DQoNCmh0dHBzOi8vZ2l0aHViLmNvbS9jZGg0dS9k cmFmdC1zaXAtcHVzaC9wdWxsLzE1DQoNCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQpPbiAx My8wMy8xOCAxMjo1NSwgIkNocmlzdGVyIEhvbG1iZXJnIiA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJp Y3Nzb24uY29tPG1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+Pg0Kd3JvdGU6 DQoNCj5JZiB0aGUgcHJveHkgY29uc2lkZXJzIHRoZSByZXF1ZXN0ZWQgcmVnaXN0cmF0aW9uIGV4 cGlyYXRpb24gaW50ZXJ2YWwNCj4oUkZDMzI2MSkgdG8gYmUgdG9vIHNob3J0LCB0aGUNCj4gICAg cHJveHkgTVVTVCBlaXRoZXIgc2VuZCBhIDQyMyAoSW50ZXJuYWwgVG9vIEJyaWVmKSByZXNwb25z ZSB0byB0aGUNCj5SRUdJU1RFUiByZXF1ZXN0IG9yIHNraXAgdGhlIHJlc3QNCj4gICAgb2YgdGhl IHByb2NlZHVyZXMgaW4gdGhpcyBzZWN0aW9uLCBhbmQgcHJvY2VzcyB0aGUgUkVHSVNURVIgcmVx dWVzdA0KPnVzaW5nIG5vcm1hbCBTSVAgcHJvY2VkdXJlcy4NCj4gICAgU2ltaWxhcmx5LCB3aGVu IHRoZSBwcm94eSByZWNlaXZlcyBhIDJ4eCByZXNwb25zZSB0byB0aGUgUkVHSVNURVINCj5yZXF1 ZXN0LCBpZiB0aGUgcHJveHkgY29uc2lkZXJzDQo+ICAgIHRoZSByZWdpc3RyYXRpb24gZXhwaXJh dGlvbiBpbnRlcm5hbCBpbmRpY2F0ZWQgYnkgdGhlIHJlZ2lzdHJhciB0b28NCj5zaG9ydCwgdGhl IHByb3h5IE1VU1QgTk9UIGluc2VydA0KPiAgICBhIEZlYXR1cmUtQ2FwcyBoZWFkZXIgZmllbGQg d2l0aCBhICdzaXAucG5zJyBmZWF0dXJlLWNhcGFiaWxpdHkNCj5pbmRpY2F0b3IgaW4gdGhlIHJl c3BvbnNlLCBhbmQgdGhlDQo+ICAgIFByb3h5IE1VU1QgTk9UIHJlcXVlc3QgcHVzaCBub3RpZmlj YXRpb25zIGFzc29jaWF0ZWQgd2l0aCB0aGUNCj5yZWdpc3RyYXRpb24uDQo+DQo+ICAgIE5PVEU6 IEEgcmVnaXN0cmF0aW9uIGV4cGlyYXRpb24gaW50ZXJ2YWwgaXMgY29uc2lkZXJlZCB0b28gc2hv cnQgaWYNCj50aGUgaW50ZXJ2YWwgaXMgc21hbGxlciB0aGFuIHRoZQ0KPiAgICB0aW1lIHByaW9y IHRvIGV4cGlyYXRpb24gd2hlbiB0aGUgcHJveHkgcmVxdWVzdHMgYSBwdXNoIG5vdGlmaWNhdGlv bi7Csg0KDQo= --_000_7594FB04B1934943A5C02806D1A2204B6C200872ESESSMB109erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K CW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaGFua3MsIFJvbWFuITxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+UmVnYXJkcyw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkNocmlzdGVyPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj4gUm9tYW4gU2hwb3VudCBbbWFpbHRvOnJvbWFuQHRlbHVyaXguY29tXQ0K PGJyPg0KPGI+U2VudDo8L2I+IDEzIE1hcmNoIDIwMTggMTk6MzQ8YnI+DQo8Yj5Ubzo8L2I+IENo cmlzdGVyIEhvbG1iZXJnICZsdDtjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20mZ3Q7PGJy Pg0KPGI+Q2M6PC9iPiBTSVBDT1JFICZsdDtzaXBjb3JlQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1 YmplY3Q6PC9iPiBSZTogW3NpcGNvcmVdIC1wdXNoPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkxvb2tzIGdvb2QuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGNsZWFycyBhbGwgbXkgaXNzdWVzIGZvciB0 aGlzIGRyYWZ0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fXzxicj4NClJvbWFu IFNocG91bnQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5P biBUdWUsIE1hciAxMywgMjAxOCBhdCA3OjE3IEFNLCBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7PGEg aHJlZj0ibWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlB1bGwgcmVxdWVzdDo8 YnI+DQo8YnI+DQo8YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vY2RoNHUvZHJhZnQtc2lwLXB1 c2gvcHVsbC8xNSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZ2l0aHViLmNvbS9jZGg0dS9kcmFm dC1zaXAtcHVzaC9wdWxsLzE1PC9hPjxicj4NCjxicj4NCjxicj4NClJlZ2FyZHMsPGJyPg0KPGJy Pg0KQ2hyaXN0ZXI8YnI+DQo8YnI+DQo8YnI+DQpPbiAxMy8wMy8xOCAxMjo1NSwgJnF1b3Q7Q2hy aXN0ZXIgSG9sbWJlcmcmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVy Z0Blcmljc3Nvbi5jb20iPmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTwvYT4mZ3Q7PGJy Pg0Kd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KJmd0O0lmIHRoZSBwcm94eSBj b25zaWRlcnMgdGhlIHJlcXVlc3RlZCByZWdpc3RyYXRpb24gZXhwaXJhdGlvbiBpbnRlcnZhbDxi cj4NCiZndDsoUkZDMzI2MSkgdG8gYmUgdG9vIHNob3J0LCB0aGU8YnI+DQomZ3Q7Jm5ic3A7ICZu YnNwOyBwcm94eSBNVVNUIGVpdGhlciBzZW5kIGEgNDIzIChJbnRlcm5hbCBUb28gQnJpZWYpIHJl c3BvbnNlIHRvIHRoZTxicj4NCiZndDtSRUdJU1RFUiByZXF1ZXN0IG9yIHNraXAgdGhlIHJlc3Q8 YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyBvZiB0aGUgcHJvY2VkdXJlcyBpbiB0aGlzIHNlY3Rpb24s IGFuZCBwcm9jZXNzIHRoZSBSRUdJU1RFUiByZXF1ZXN0PGJyPg0KJmd0O3VzaW5nIG5vcm1hbCBT SVAgcHJvY2VkdXJlcy48YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyBTaW1pbGFybHksIHdoZW4gdGhl IHByb3h5IHJlY2VpdmVzIGEgMnh4IHJlc3BvbnNlIHRvIHRoZSBSRUdJU1RFUjxicj4NCiZndDty ZXF1ZXN0LCBpZiB0aGUgcHJveHkgY29uc2lkZXJzPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgdGhl IHJlZ2lzdHJhdGlvbiBleHBpcmF0aW9uIGludGVybmFsIGluZGljYXRlZCBieSB0aGUgcmVnaXN0 cmFyIHRvbzxicj4NCiZndDtzaG9ydCwgdGhlIHByb3h5IE1VU1QgTk9UIGluc2VydDxicj4NCiZn dDsmbmJzcDsgJm5ic3A7IGEgRmVhdHVyZS1DYXBzIGhlYWRlciBmaWVsZCB3aXRoIGEgJ3NpcC5w bnMnIGZlYXR1cmUtY2FwYWJpbGl0eTxicj4NCiZndDtpbmRpY2F0b3IgaW4gdGhlIHJlc3BvbnNl LCBhbmQgdGhlPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgUHJveHkgTVVTVCBOT1QgcmVxdWVzdCBw dXNoIG5vdGlmaWNhdGlvbnMgYXNzb2NpYXRlZCB3aXRoIHRoZTxicj4NCiZndDtyZWdpc3RyYXRp b24uPGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7IE5PVEU6IEEgcmVnaXN0cmF0aW9u IGV4cGlyYXRpb24gaW50ZXJ2YWwgaXMgY29uc2lkZXJlZCB0b28gc2hvcnQgaWY8YnI+DQomZ3Q7 dGhlIGludGVydmFsIGlzIHNtYWxsZXIgdGhhbiB0aGU8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyB0 aW1lIHByaW9yIHRvIGV4cGlyYXRpb24gd2hlbiB0aGUgcHJveHkgcmVxdWVzdHMgYSBwdXNoIG5v dGlmaWNhdGlvbi7CsjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_7594FB04B1934943A5C02806D1A2204B6C200872ESESSMB109erics_-- From nobody Wed Mar 14 19:18:47 2018 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 745EE12702E for ; Wed, 14 Mar 2018 19:18:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.685 X-Spam-Level: X-Spam-Status: No, score=-1.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 ssyBNldqvFOr for ; Wed, 14 Mar 2018 19:18:45 -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 8FD191242F7 for ; Wed, 14 Mar 2018 19:18:45 -0700 (PDT) Received: from resomta-ch2-02v.sys.comcast.net ([69.252.207.98]) by resqmta-ch2-04v.sys.comcast.net with ESMTP id wITSeFKgZR4DYwITceNpWc; Thu, 15 Mar 2018 02:18:44 +0000 Received: from hobgoblin.ariadne.com ([65.96.206.41]) by resomta-ch2-02v.sys.comcast.net with SMTP id wITaegKF6RZWhwITbegbuk; Thu, 15 Mar 2018 02:18:44 +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 w2F2IfRJ016412; Wed, 14 Mar 2018 22:18:41 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id w2F2IegM016405; Wed, 14 Mar 2018 22:18:40 -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: Roman Shpount Cc: Michael.Arnold@metaswitch.com, sipcore@ietf.org In-Reply-To: (roman@telurix.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 14 Mar 2018 22:18:40 -0400 Message-ID: <877eqe13pb.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfNeMCOVlGDw/cpQhQ1n6HyICiasEdTJFr7+/6P1q076m5GBd2nfAdvLn6l4Ew+rdjrfpWbGoxh2AJAtZtNXyA3AaAxiIsr4eNaTgKS3TbRnfOycnPcJA kmr/ePoXWRMQTIpsW9Xf13tq487yyZmcbvCz9U/b0l3fCMyMoKnrf6MYtRCcpCczDorXLPupIuElRQtHzd8DCa1M1t9IwCkB/35CfMYGP3u0JKvXl5t4Tx0M gjNaHWouIPpbFWPX1pvioQ== Archived-At: Subject: Re: [sipcore] Comments on draft-ietf-sipcore-sip-push-04 - Timer triggered REGISTER requests - Pull request 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, 15 Mar 2018 02:18:46 -0000 Roman Shpount writes: > My suggestion was: > > 1. If push notifications are used, minimal Registration expiration of 90 > seconds (can be longer) is enforced. > 2. Push notification is sent either 30 seconds or 1/3 of the registration > expiration interval before registration expiration, whichever is longer > 3. If client want's to re-Register on its own, it needs to send > re-registration after 1/2 of the expiration period. OK, that makes sense to me. > Finally, I know that push notification content is not currently used for > anything, but it would be really beneficial to at least be able to send a > new nonce value, which will allow to avoid 401 and Registration > re-transmission. As Christer says, it's probably best not to include that in this draft, but describe it as an extension to make systems more efficient. Dale From nobody Thu Mar 15 06:19:26 2018 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 C2837129515 for ; Thu, 15 Mar 2018 06:19:24 -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 1Xui2l2LJoAB for ; Thu, 15 Mar 2018 06:19:22 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::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 1EE0E1242EA for ; Thu, 15 Mar 2018 06:19:22 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id o25so7208113qkl.7 for ; Thu, 15 Mar 2018 06:19:22 -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=/CF/hCbeEQ1IG0B1t4ncN2Y5t1itqJhSVPg1E7lOJ/k=; b=vXEXmq3MFi8XCpo+etI4TBmvge8y5Jf35JRJW30D06mpWCWYDJISDOTNU9hY0kjscb V1nmvD3n1PcyS7AR5x/fm2qRPvPEUJsRMQ9733eHIle62+AiIbxxEfYLxyCzbWjuIwkD v8gDFVitH9Bu7Co0vdimSTbKAREg0J6lEiPCs8v0cGVsjm2+un9LROfpF45UewQQkjCJ ymL4NXY4W6BL/4JgCVpvPNiXR98hg040qOAYQ+vxJ/rXbULJbj9t8OFbZEzVJD8WZsKw Sa82HGAu/CV0lJQi8Cvpx2Fk15OKRFlDJ4sZCv4rsltkDB2Ksuifvr7tgIvW9MaxOgyC CUHQ== 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=/CF/hCbeEQ1IG0B1t4ncN2Y5t1itqJhSVPg1E7lOJ/k=; b=BDuIBs6K3j6G6JgZfgT3DU9InXP4XfAVBZsngPBEyp7Qm58sZZPNgco24s6R71vIYu G8zNRyX2u1uKW3wPRAynTKkVwzU0zGSxmszS5epx7fhHfTztodQRAKexsLOlQc+46BYM zDXwOO1w/GTy8RM59Enkw9nUGbkUJ9vGXRrt/zBcfTBT76B5k/WKsyvv+jCXrN9Bm0BR RQbUEMrCQGxKoyhGeGztkiFEsEDjHxUFWEhI9py2DUeedpaGz/zRo0y3mOZWj09o2SgX qMml31aej4MuWqMd2up0jaRC5YxVAi2o8HjrNCSWkee/t2yCoVlTk4VBhlION+IcRTV5 CKZg== X-Gm-Message-State: AElRT7FtdtoPVSUgumUFpnMsEj9fG+dJwAQPB1FXLkDDRpxKrmdHRy9Y xXVLW75GYObFpjqh1uVDU4y0wIq+bWqeBd0y4ug= X-Google-Smtp-Source: AG47ELvRI1RLTalfZvY/s3AedDcmZYXFWwxCSd+S5yvpcY79YH4nWmkU8g6WPEuk6OcoifXXvdgNC+rmObIur2kd9oo= X-Received: by 10.55.19.154 with SMTP id 26mr8861837qkt.172.1521119961275; Thu, 15 Mar 2018 06:19:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.224.208 with HTTP; Thu, 15 Mar 2018 06:19:20 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C1F208C@ESESSMB109.ericsson.se> References: <152025923464.14616.3652723669244846858@ietfa.amsl.com> <45ebda0e-9d23-6338-072b-e6a0142342d1@alum.mit.edu> <446AD2FF-49DE-4D9E-8B76-6CD066BA94C2@ericsson.com> <7594FB04B1934943A5C02806D1A2204B6C1F208C@ESESSMB109.ericsson.se> From: Yehoshua Gev Date: Thu, 15 Mar 2018 15:19:20 +0200 Message-ID: To: Christer Holmberg Cc: "sipcore@ietf.org" Content-Type: multipart/alternative; boundary="001a113f7cdaf3e4e505677356ae" Archived-At: Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-sessiontimer-race-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: Thu, 15 Mar 2018 13:19:25 -0000 --001a113f7cdaf3e4e505677356ae Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Two minor typos I noticed: 3. Section 3.2 NEW TEXT: "ongoing INVIET transaction" should be "ongoing INVITE transaction". 2. Section 3.4 NEW TEXT: "there is on ongoing negotiation" should be "there is an ongoing negotiation". Yehoshua On Mon, Mar 12, 2018 at 5:48 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > > Since there are currently no open issues, I don=E2=80=99t think we need t= o discuss > it in London. > > > > My suggestion would be to move it forward. Then, if Martin (or someone > else) finds some major issue we=E2=80=99ll deal with those (and, if neede= d, we can > always bring it back to the WG). > > > > Regards, > > > > Christer > > > > > > > > *From:* Brian Rosen [mailto:br@brianrosen.net] > *Sent:* 12 March 2018 17:40 > *To:* Christer Holmberg > *Cc:* Paul Kyzivat ; sipcore@ietf.org > *Subject:* Re: [sipcore] I-D Action: draft-ietf-sipcore- > sessiontimer-race-01.txt > > > > Chairs want this draft finished. > > > > We have an hour, and if we can finish it, let=E2=80=99s do it. If it is = finished, > let=E2=80=99s get it on the approval path. > > > > I need to publish the agenda today. > > > > Brian > > > > On Mar 5, 2018, at 11:41 AM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > > > > Hi, > > > > I forgot to mention that the new version is only because the previous one > was about to expire, so apart from the year there should be no changes. > Sorry for that. > > > > I will provide some suggestions regarding how to move forward soon. > > > > Regards, > > > > Christer > > Sent from my iPhone > > > On 5 Mar 2018, at 18.12, Paul Kyzivat wrote: > > Christer, > > So far I have only skimmed the draft. (I *will* read it more carefully > later.) A couple of comments: > > 1) Examples of the cases you are trying to clarify would be helpful. > > 2) in 3.1, am I right in concluding this is to cover the situation > introduced by section 3.2? But doesn't this also eliminate the > mechanism for overtly turning off session timer by sending an > invite without session-expires? > > Thanks, > Paul > > On 3/5/18 9:13 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 : Session Initiation Protocol (SIP) Session Timer > Glare Handling > > Author : Christer Holmberg > > Filename : draft-ietf-sipcore-sessiontimer-race-01.txt > > Pages : 7 > > Date : 2018-03-05 > > Abstract: > > This document updates RFC 4028, by clarifying the procedures for > > negotiating usage of the Session Initiation Protocol (SIP) session > > timer mechansim, in order to avoid a race condition where both > > endpoints trigger simultaneous negotiations. > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-sipcore-sessiontimer-race/ > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-sipcore-sessiontimer-race-01 > > https://datatracker.ietf.org/doc/html/draft-ietf-sipcore- > sessiontimer-race-01 > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipcore-sessiontimer-race-= 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 > > > _______________________________________________ > 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 > > --001a113f7cdaf3e4e505677356ae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Two minor typos I noticed:
3. Section 3.2 NEW TEXT: "ongoing INVIET transaction" should be "ongoing INVITE transaction&quo= t;.
2. Section 3.4 NEW TEXT: "there is on ongoing negotiation" should = be "there = is an ongoing negotiation".


Yehoshua


On Mon, Mar 12, 2018 at 5:48 PM, Chri= ster Holmberg <christer.holmberg@ericsson.com> = wrote:

Hi,

=C2=A0

Since there are currently no open iss= ues, I don=E2=80=99t think we need to discuss it in London.

=C2=A0

My suggestion would be to move it for= ward. Then, if Martin (or someone else) finds some major issue we=E2=80=99l= l deal with those (and, if needed, we can always bring it back to the WG).

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

=C2=A0

=C2=A0

From: = Brian Rosen [mailto:= br@brianrosen.net]
Sent: 12 March 2018 17:40
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: Paul Kyzivat <pkyzivat@alum.mit.edu>; sipcore@ietf.org
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-sessionti= mer-race-01.txt

=C2=A0

Chairs want this draft finished.

=C2=A0

We have an hour, and if we can finish it, let=E2=80= =99s do it.=C2=A0 If it is finished, let=E2=80=99s get it on the approval p= ath.

=C2=A0

I need to publish the agenda today.

=C2=A0

Brian

=C2=A0

On Mar 5, 2018, at 11:41 AM, Christer Holmberg <<= a href=3D"mailto:christer.holmberg@ericsson.com" target=3D"_blank">christer= .holmberg@ericsson.com> wrote:

=C2=A0

Hi,

=C2=A0

I forgot to mention that the new version is only bec= ause the previous one was about to expire, so apart from the year there sho= uld be no changes. Sorry for that.

=C2=A0

I will provide some suggestions regarding how to mov= e forward soon.

=C2=A0

Regards,

=C2=A0

Christer

Sent from my iPhone


On 5 Mar 2018, at 18.12, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

Christer,

So far I have only skimmed the draft. (I *will* read it more carefully late= r.) A couple of comments:

1) Examples of the cases you are trying to clarify would be helpful.

2) in 3.1, am I right in concluding this is to cover the situation
=C2=A0=C2=A0introduced by section 3.2?=C2=A0 But doesn't this also elim= inate the
=C2=A0=C2=A0mechanism for overtly turning off session timer by sending an =C2=A0=C2=A0invite without session-expires?

=C2=A0 =C2=A0Thanks,
=C2=A0 =C2=A0Paul

On 3/5/18 9:13 AM, internet-drafts@ietf.org wrote:

A New Internet-Draft is available from the on-line I= nternet-Drafts directories.

This draft is a work item of the Session Initiation = Protocol Core WG of the IETF.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Titl= e =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: Session Ini= tiation Protocol (SIP) Session Timer Glare Handling

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Auth= or =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: Christer Holmber= g

=C2=A0 =C2=A0Filename =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0: draft-ietf-sipcore-sessiontimer-race-01.txt

=C2=A0 =C2=A0Pages =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0: 7

=C2=A0 =C2=A0Date =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: 2018-03-05

Abstract:

=C2=A0=C2=A0=C2=A0This document updates RFC 4028, by= clarifying the procedures for

=C2=A0=C2=A0=C2=A0negotiating usage of the Session I= nitiation Protocol (SIP) session

=C2=A0=C2=A0=C2=A0timer mechansim, in order to avoid= a race condition where both

=C2=A0=C2=A0=C2=A0endpoints trigger simultaneous neg= otiations.

The IETF datatracker status page for this draft is:<= u>

https://datatracker.ietf.o= rg/doc/draft-ietf-sipcore-sessiontimer-race/

There are also htmlized versions available at:

https://tools.ietf.org/html/<= wbr>draft-ietf-sipcore-sessiontimer-race-01

https://datatracker= .ietf.org/doc/html/draft-ietf-sipcore-sessiontimer-race-01=

A diff from the previous version is available at:=

https://www.ietf.org/= rfcdiff?url2=3Ddraft-ietf-sipcore-sessiontimer-race-01=

Please note that it may take a couple of minutes fro= m 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<= /a>


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

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

=C2=A0


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

--001a113f7cdaf3e4e505677356ae-- From nobody Thu Mar 15 06:28:54 2018 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 60928129C59 for ; Thu, 15 Mar 2018 06:28:52 -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, 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=ericsson.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 xL363xovWFKN for ; Thu, 15 Mar 2018 06:28:51 -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 B31CE129C53 for ; Thu, 15 Mar 2018 06:28:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1521120529; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=hjKD2hxoV86kpI6tDBd/VO6xmb5WjbpuYduM3mw5Swo=; b=ULCQPZTj+38nFbsEQGa30ve2nIL5wmZSyPwYpboBCka7OBrH8lb6bAsQwJOCVP+y Tj2wL6vb4scn8uASz5va+Ad6QiimFoaAb+0RL+vnCr8RQm+AK3m8T9edNYGM630I 0zzDmjFE7Y/ytL1x5Xk4wSa1WVUCeQPHOcZkioqJVqE=; X-AuditID: c1b4fb30-703ff7000000095a-1b-5aaa75107331 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id D5.FC.02394.0157AAA5; Thu, 15 Mar 2018 14:28:49 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.172]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0382.000; Thu, 15 Mar 2018 14:28:48 +0100 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-sessiontimer-race-01.txt Thread-Index: AQHTtIw7p1ptmF8ozkitn+4GNAHNCKPBv1oAgA+ZWKA= Date: Thu, 15 Mar 2018 13:28:48 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B6C205377@ESESSMB109.ericsson.se> References: <152025923464.14616.3652723669244846858@ietfa.amsl.com> <45ebda0e-9d23-6338-072b-e6a0142342d1@alum.mit.edu> In-Reply-To: <45ebda0e-9d23-6338-072b-e6a0142342d1@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.168] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyM2J7oK5g6aoog79zWCxWbDjAavH1xyY2 ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSvj2BnjgjMiFS3Pn7I1MO4X6GLk5JAQMJHY eOUAcxcjF4eQwGFGifdP3zODJIQEljBKfHsf0cXIwcEmYCHR/U8bJCwiEChxdckEsBJhgQCJ 3rsdbCAlIPFPu40hSqwkTn09yQgSZhFQlTgwJwTE5BXwlTjfxwgxu1Liw8Q2VhCbU8BBYv2X xUwgNqOAmMT3U2vAbGYBcYlbT+YzQRwpILFkz3lmCFtU4uXjf6wQtpJEz/17UPU6Egt2f2KD sLUlli18DVbPKyAocXLmE5YJjCKzkIydhaRlFpKWWUhaFjCyrGIULU4tTspNNzLSSy3KTC4u zs/Ty0st2cQIjIKDW34b7GB8+dzxEKMAB6MSD69wzKooIdbEsuLK3EOMEhzMSiK8PgVAId6U xMqq1KL8+KLSnNTiQ4zSHCxK4rwnPXmjhATSE0tSs1NTC1KLYLJMHJxSDYxJOy7qO+msVDxs Ym791c858nCD2ruN30M4P/6RPnEpZ45jpPXSCU88k1+3WhzzFom5P3GP6/5F/7w2Tsx/Faij xCq8p+5GevCaYz+VPr7j8XvsdS3d0sDxU0dTYo6I/ixLj7zQ5RME7Lia0jdysjD+KLJS3/W8 TzeeU3aZo97BBwrqax8FXFBiKc5INNRiLipOBABDYRWmfgIAAA== Archived-At: Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-sessiontimer-race-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: Thu, 15 Mar 2018 13:28:52 -0000 Hi Paul, > So far I have only skimmed the draft. (I *will* read it more carefully > later.) A couple of comments: > > 1) Examples of the cases you are trying to clarify would be helpful. I will include that in the presentation, and in the next version of the dra= ft. Meanwhile, please take a look at the original e-mail I sent to the list: https://www.ietf.org/mail-archive/web/sipcore/current/msg08096.html --- > 2) in 3.1, am I right in concluding this is to cover the situation > introduced by section 3.2? But doesn't this also eliminate the > mechanism for overtly turning off session timer by sending an > invite without session-expires? I don't think so. Can you explain how you come to that conclusion? Regards, Christer On 3/5/18 9:13 AM, internet-drafts@ietf.org wrote: >=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 WG of t= he IETF. >=20 > Title : Session Initiation Protocol (SIP) Session Time= r Glare Handling > Author : Christer Holmberg > Filename : draft-ietf-sipcore-sessiontimer-race-01.txt > Pages : 7 > Date : 2018-03-05 >=20 > Abstract: > This document updates RFC 4028, by clarifying the procedures for > negotiating usage of the Session Initiation Protocol (SIP) session > timer mechansim, in order to avoid a race condition where both > endpoints trigger simultaneous negotiations. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sipcore-sessiontimer-race/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-sipcore-sessiontimer-race-01 > https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-sessiontimer- > race-01 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipcore-sessiontimer-race > -01 >=20 >=20 > Please note that it may take a couple of minutes from the time of=20 > submission until the htmlized version and diff are available at tools.iet= f.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 >=20 _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From nobody Thu Mar 15 06:48:53 2018 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 D7BD0129C70 for ; Thu, 15 Mar 2018 06:48:51 -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, T_RP_MATCHES_RCVD=-0.01, 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 HAdpdNgI_eeb for ; Thu, 15 Mar 2018 06:48:50 -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 CA6FC129C6A for ; Thu, 15 Mar 2018 06:48:50 -0700 (PDT) Received: from mutabilis-2.local ([47.186.15.50]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w2FDmn2B055646 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 15 Mar 2018 08:48:50 -0500 (CDT) (envelope-from mahoney@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [47.186.15.50] claimed to be mutabilis-2.local To: sipcore@ietf.org References: <2042e582-808e-f832-0ee2-d91f0ba0e417@nostrum.com> From: "A. Jean Mahoney" Message-ID: Date: Thu, 15 Mar 2018 08:48:51 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <2042e582-808e-f832-0ee2-d91f0ba0e417@nostrum.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sipcore] WGLC: 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: Thu, 15 Mar 2018 13:48:52 -0000 Hi all, This draft received no feedback during WGLC. We need at least some indication that WG participants have read the draft. If you have read it and you think that the draft is ready, please explicitly state that on list. Thanks! Jean On 2/19/18 3:02 PM, A. Jean Mahoney wrote: > Hi all, > > Working Group Last Call starts today for > draft-ietf-sipcore-originating-cdiv-parameter. > > https://datatracker.ietf.org/doc/draft-ietf-sipcore-originating-cdiv-parameter/ > > > Although this draft has received WG support, this draft has not received > much in the way of feedback. Please provide feedback to the sipcore > mailing list by Monday, March 5th. > > Thanks! > > Jean > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Thu Mar 15 08:05:27 2018 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 E24ED124D6C for ; Thu, 15 Mar 2018 08:05:25 -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, 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=ericsson.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 y9G9Du-VHcet for ; Thu, 15 Mar 2018 08:05:24 -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 3EFCF12D87C for ; Thu, 15 Mar 2018 08:05:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1521126321; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=sTTZPtnJqY72ZXzE8fbhgDFqfxm4NzmIaDGtZQ3k7rY=; b=aTh1pgK46FdV91081yjloFAziLwSULdD74wYbE5j2zum87XT19NilQ/lX/F8rNGO V/I8FTiBvVmFrDQ/r3EYPCv6apRK0QljryQBA3A92lmyVPuxJXgHtdLk5OJgZZlB 5/oR7yTLCI6w+sAQh5Xbh8kQTqg3YRfMF8ToDZUBMaI=; X-AuditID: c1b4fb2d-87c029c000005540-b7-5aaa8bb097dc Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 0E.40.21824.0BB8AAA5; Thu, 15 Mar 2018 16:05:21 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.172]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0382.000; Thu, 15 Mar 2018 16:05:20 +0100 From: Christer Holmberg To: "A. Jean Mahoney" , "sipcore@ietf.org" Thread-Topic: [sipcore] WGLC: draft-ietf-sipcore-originating-cdiv-parameter Thread-Index: AQHTvGRdanzjh21F0ke6nq+Sj+BP5KPRY53w Date: Thu, 15 Mar 2018 15:05:20 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B6C205863@ESESSMB109.ericsson.se> References: <2042e582-808e-f832-0ee2-d91f0ba0e417@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.172] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRmVeSWpSXmKPExsUyM2K7tO7G7lVRBud38lg0dK5ktfj6YxOb A5PHkiU/mTxm7XzCEsAUxWWTkpqTWZZapG+XwJWxY/Y0toKzXBVzLu1lb2B8xtHFyMkhIWAi 8eXzPdYuRi4OIYHDjBITmq5DOUsYJZZemcncxcjBwSZgIdH9TxukQUQgRGLljU52EFtYwEui 61U3WImIgLfEy2dcECVGEquvvgErYRFQlXi37hoziM0r4Cvxe/JXNhBbSKBY4uDTi2BxTgF7 if2PfoLFGQXEJL6fWsMEYjMLiEvcejKfCeJOAYkle84zQ9iiEi8f/2MFWSshoCTRMJMFolxH YsHuT2wQtrbEsoWvodYKSpyc+YRlAqPILCRTZyFpmYWkZRaSlgWMLKsYRYtTi4tz042M9VKL MpOLi/Pz9PJSSzYxAmPh4JbfujsYV792PMQowMGoxMPrGr0qSog1say4MvcQowQHs5IIr08B UIg3JbGyKrUoP76oNCe1+BCjNAeLkjjvSU/eKCGB9MSS1OzU1ILUIpgsEwenVANjyFauqn7/ qSlvPkvuerDAbZu8XUQij2TPBHetev3Jz+9PPJK99eyd7T3bLTtdj1iyyS86fsNG281KPOiA 9qfpDHbTbCKP9p+apPOabYXs604F1oa+zc9nnbv5turp+Rf1QY26WSIqj3/Vs7dNjt07SeeH j+BTec9Cr95rX84c8XLL3M3+/c5EJZbijERDLeai4kQA7zg0loECAAA= Archived-At: Subject: Re: [sipcore] WGLC: 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: Thu, 15 Mar 2018 15:05:26 -0000 Hi, I have read it previously, but I will re-read it today :) Regards, Christer -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of A. Jean Mahone= y Sent: 15 March 2018 15:49 To: sipcore@ietf.org Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-originating-cdiv-parameter Hi all, This draft received no feedback during WGLC. We need at least some indicati= on that WG participants have read the draft. If you have read it and you th= ink that the draft is ready, please explicitly state that on list. Thanks! Jean On 2/19/18 3:02 PM, A. Jean Mahoney wrote: > Hi all, >=20 > Working Group Last Call starts today for=20 > draft-ietf-sipcore-originating-cdiv-parameter. >=20 > https://datatracker.ietf.org/doc/draft-ietf-sipcore-originating-cdiv-p > arameter/ >=20 >=20 > Although this draft has received WG support, this draft has not=20 > received much in the way of feedback. Please provide feedback to the=20 > sipcore mailing list by Monday, March 5th. >=20 > Thanks! >=20 > Jean >=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 Thu Mar 15 08:43:08 2018 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 D73761273E2 for ; Thu, 15 Mar 2018 08:43:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 0WXpx_MBn08G for ; Thu, 15 Mar 2018 08:43:05 -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 B349B12711E for ; Thu, 15 Mar 2018 08:43:05 -0700 (PDT) X-AuditID: 12074412-c9dff70000000b7d-8d-5aaa9488fa96 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 0E.EE.02941.8849AAA5; Thu, 15 Mar 2018 11:43:04 -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 w2FFh3ua032001 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Thu, 15 Mar 2018 11:43:04 -0400 To: sipcore@ietf.org References: <2042e582-808e-f832-0ee2-d91f0ba0e417@nostrum.com> From: Paul Kyzivat Message-ID: Date: Thu, 15 Mar 2018 11:43:03 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBIsWRmVeSWpSXmKPExsUixO6iqNsxZVWUwfqbphZff2xic2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxtmljYwFBzgqNh1dx97AeJKti5GTQ0LAROLYtUUsXYxcHEIC O5gkXh6/ywqSEBL4wSTx+HV0FyMHh7CAl0T7GW6QsIiAiMSz6f/YIEqKJQ4+vcgMYrMJaEnM OfSfBaScV8BeomkjF0iYRUBVYu+3s2AlogJpEpeat4LZvAKCEidnPmEBsTmByvc/+gk2klnA TGLe5ofMELa4xK0n85kgbHmJ7W/nME9g5J+FpH0WkpZZSFpmIWlZwMiyilEuMac0Vzc3MTOn ODVZtzg5MS8vtUjXTC83s0QvNaV0EyMkIIV2MK4/KXeIUYCDUYmHN6N5VZQQa2JZcWXuIUZJ DiYlUd6OcqAQX1J+SmVGYnFGfFFpTmrxIUYJDmYlEd4r3UA53pTEyqrUonyYlDQHi5I478/F 6n5CAumJJanZqakFqUUwWRkODiUJ3tTJQI2CRanpqRVpmTklCGkmDk6Q4TxAw5smgQwvLkjM Lc5Mh8ifYrTkaLn4pI2ZY9ejl0DyxovXbcxCLHn5ealS4rwcIEMFQBoySvPgZsISzCtGcaAX hXkngFTxAJMT3NRXQAuZgBZmblsBsrAkESEl1cB4yEa+d3upkbS8xKdlN0X7vMI5owLlJ4fX +qX+NBZSl24WMDK3CwySD7nJ+7GCZen76m7rwmXfMoWMHMRWPEzalPMjreyvPXufolyRqvuV yC2LU5YsNN8bkxC5p1H892vTKonQDZvZ80LDfJ2XdTmoKvX5TH/d6bO97U/FG/cPOkkJfXN4 lViKMxINtZiLihMBqimWUwsDAAA= Archived-At: Subject: Re: [sipcore] WGLC: 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: Thu, 15 Mar 2018 15:43:07 -0000 On 3/15/18 9:48 AM, A. Jean Mahoney wrote: > Hi all, > > This draft received no feedback during WGLC. We need at least some > indication that WG participants have read the draft. If you have read it > and you think that the draft is ready, please explicitly state that on > list. I have read the document. In terms of form I think this document is ready. I do find it somewhat disturbing that the document is so very IMS-dependent. It feels like it ought to be a 3gpp document rather than an IETF document. You can't really fully understand this document without a detailed understanding of the functioning of IMS. (My very old understanding of IMS is sufficient for me to get the gist of it, but not the details.) This has to be an IETF document because it is revising a sip header field. IMO it would be better to simply say that this is only applicable in an IMS environment and leave all the details of how it works to IMS documents. But that is a question of style. So I won't object to the document in the current form. Thanks, Paul From nobody Thu Mar 15 10:55:21 2018 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 E522512D80E for ; Thu, 15 Mar 2018 10:55:20 -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, 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=ericsson.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 0QGyZiodhGGS for ; Thu, 15 Mar 2018 10:55:19 -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 D772512DA00 for ; Thu, 15 Mar 2018 10:55:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1521136516; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=gRTavXlB3wPEUIpBuXCueXVgJyLNNiWq0R/6r03VLY4=; b=ENflcB3rggrom797ytnkQjxokYU2LDfaUm6yz0/3pcQbNygAX1KyQvnPZ00rQDR3 zpMjKkfy7n9oFAa54xcehG5O8M68In+I5700A/Maav47lLcEVgFaV5/zVx3m7/ro bOYIrah0zavpBX4JgozlqQYy3HeaecddLq7w3FGD+kk=; X-AuditID: c1b4fb2d-87c029c000005540-8c-5aaab3848548 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 99.DB.21824.483BAAA5; Thu, 15 Mar 2018 18:55:16 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.172]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0382.000; Thu, 15 Mar 2018 18:55:13 +0100 From: Christer Holmberg To: "A. Jean Mahoney" , "sipcore@ietf.org" Thread-Topic: [sipcore] WGLC: draft-ietf-sipcore-originating-cdiv-parameter Thread-Index: AQHTvGRdanzjh21F0ke6nq+Sj+BP5KPRhQ0Q Date: Thu, 15 Mar 2018 17:55:13 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B6C205F43@ESESSMB109.ericsson.se> References: <2042e582-808e-f832-0ee2-d91f0ba0e417@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.169] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUyM2K7qG7L5lVRBmfbtS0aOleyWnz9sYnN gcljyZKfTB6zdj5hCWCK4rJJSc3JLEst0rdL4Mo4vucUc8EnlYq+pi8sDYzzZbsYOTkkBEwk Zm/cwd7FyMUhJHCYUWLT33YoZwmjxIyLnaxdjBwcbAIWEt3/tEEaRARCJFbe6GQHsYUFvCS6 XnUzg5SICHhLvHzGBVFiJPH50V+wEhYBVYmJj1aygti8Ar4SXw88ZwaxhQSKJQ4+vQhmcwrY S+x/9JMNxGYUEJP4fmoNE4jNLCAucevJfCaIOwUkluw5zwxhi0q8fPyPFcJWkjjZvZkFol5H YsHuT2wQtrbEsoWvmSH2CkqcnPmEZQKjyCwkY2chaZmFpGUWkpYFjCyrGEWLU4uLc9ONjPVS izKTi4vz8/TyUks2MQKj4eCW37o7GFe/djzEKMDBqMTDW7ZsVZQQa2JZcWXuIUYJDmYlEd4r 3UAh3pTEyqrUovz4otKc1OJDjNIcLErivCc9eaOEBNITS1KzU1MLUotgskwcnFINjGaGl9/f jvDXi8qJlnv3NL2yxEHOiGnXtk2S1g9FdITNwvYvFH/yNuW9McNfa494xpmT0h7fSW3ML5pQ mWF24/nV+uA71+17jA9NSd+iav+FY7pO1O6+xpoikx91+yUtlmn8KRU0PdUhd1Hgk0v2FIPm sqZbNfxm1w8wHWgWkPT5Khsl/YRHiaU4I9FQi7moOBEA/SG7hYICAAA= Archived-At: Subject: Re: [sipcore] WGLC: 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: Thu, 15 Mar 2018 17:55:21 -0000 Hi, I have reviewed the document, and technically I have no issues. However, do have some editorial comments that the author may want to consid= er: --- Q1: In general, you may want to check that you use consistent terminology. For = example, you sometimes say "AS", sometimes "Application Server". My suggest= ion is to say "AS (Application Server)" on first occurrence, and thereafter= "AS". --- Q2: In general, in many place of the document you say things like "The P-Served= -User header field is defined in [RFC5502]". I think it is enough to simply= say "The P-Served-User header field [RFC5502]"=20 --- Q3: In the Abstract, I think some of the sentences should move location. In add= ition, you repeat some of the things twice. I suggest something like the following: =20 "The P-Served-User header field [RFC5502] is used to convey the identity= of the served user and the session case that applies to this particular communication session a= nd application invocation." This specification defines a new P-Served-User header field parameter, "= orid-cdiv". =20 The parameter conveys the session case used by a proxy when handling an = originating=20 session after Call Diversion (CDIV) services has been invoked for the se= rved user.=20 --- Q4: Since the draft also fixes the ABNF in RFC 5502, I think it would be good t= o indicate that already in the Abstract and Introduction. Similarly, the document seems to clarify some of the RFC 5502 procedures, s= o that would also be good to mention. --- Q5: In Section 1.1: s/The P-Served-User header field was defined in [RFC5502] to address/ The P= -Served-User header field [RFC5502] was defined in to address/ --- Q6: In Section 1.1, the text says that the P-Served-User header field was defin= ed to "address an issue", but it doesn't say what the "issue" is. I suggest= to simply say what the header field was defined based on a requirement fro= m 3GPP, in order to convey blah blah blah. --- Q7: In Section 2, do you need to first sentence in the first paragraph? Isn't t= hat covered in the Applicability section? --- Q8: In Section 2: s/For a terminating call, when receiving the initial INVITE request, the S-= CSCF will determine that.../When the S-CSCF receives the initial INVITE req= uest for a terminating call, it will determine that... --- Q9: In Section 2, I think it would be more clear to describe the different step= s taken by the S-CSCF and AS using a numbered bullet list. Then you may not= need all the "Next", "After that", etc. --- Q10: In Section 2, the last part starts with: "This document also provides the following guidance that reminds or clarifi= es the P-Served-User handling that are missing in [RFC5502]:" I think this text should be in a separate section: "Clarification of RFC 55= 02 procedures", or something. --- Q11: In Section 2: s/is forbidden to be repeated/MUST NOT be repeated --- Q12: In Section 2, you say "tagged thanks to the mp-param header". I suggest to = use another word than "thanks to". "using" perhaps? --- Q13: In Section 2: s/The PServedUser-value remains/The P-Served-User header field value remain= s --- Q14: Would it be good to put the "Applicability" section BEFORE the current Sect= ion 2? --- Regards, Christer -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of A. Jean Mahone= y Sent: 15 March 2018 15:49 To: sipcore@ietf.org Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-originating-cdiv-parameter Hi all, This draft received no feedback during WGLC. We need at least some indicati= on that WG participants have read the draft. If you have read it and you th= ink that the draft is ready, please explicitly state that on list. Thanks! Jean On 2/19/18 3:02 PM, A. Jean Mahoney wrote: > Hi all, >=20 > Working Group Last Call starts today for=20 > draft-ietf-sipcore-originating-cdiv-parameter. >=20 > https://datatracker.ietf.org/doc/draft-ietf-sipcore-originating-cdiv-p > arameter/ >=20 >=20 > Although this draft has received WG support, this draft has not=20 > received much in the way of feedback. Please provide feedback to the=20 > sipcore mailing list by Monday, March 5th. >=20 > Thanks! >=20 > Jean >=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 Thu Mar 15 11:08:25 2018 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 2398612E054; Thu, 15 Mar 2018 11:08:21 -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.75.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152113730103.12236.16040607705923600601@ietfa.amsl.com> Date: Thu, 15 Mar 2018 11:08:21 -0700 Archived-At: Subject: [sipcore] I-D Action: draft-ietf-sipcore-sip-push-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: Thu, 15 Mar 2018 18:08:23 -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 : Push Notification with the Session Initiation Protocol (SIP) Authors : Christer Holmberg Michael Arnold Filename : draft-ietf-sipcore-sip-push-09.txt Pages : 24 Date : 2018-03-15 Abstract: This document describes how a Push Notification Service (PNS) can be used to awake suspended Session Initiation Protocol (SIP) User Agents (UAs), for the UA to be able to receive and send SIP requests. The document defines new SIP URI parameters and new feature-capability indicators that can be used in SIP messages to indicate support of the mechanism defined in this document, to exchange PNS information between the SIP User Agent (UA) and the SIP entity that will request push notifications towards the UA, and to trigger such push notification requests. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-push/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sipcore-sip-push-09 https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-sip-push-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-sip-push-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 Thu Mar 15 11:15:07 2018 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 DDB8012DA06 for ; Thu, 15 Mar 2018 11:15:04 -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_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=ericsson.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 yoDQMC3JYi3S for ; Thu, 15 Mar 2018 11:15:03 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF3921252BA for ; Thu, 15 Mar 2018 11:15:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1521137701; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=0tEaUGl4uF+0EUcx/bOWXJNOkku3wONd9a3aSh/7sgQ=; b=SQ/nDMNs+TY/5mpA0qt9stpqMgFerd+cvQHHodCiQzeFVRrGFoD9R0Uwx16uujvC 2W2UFIjjmkxb1AvWIHnPj6CwoKJ3g1LxWuWY0NCldVhtZ81W3Gt7/3QPzEQ01FW2 YY8u40vKdgM4LbzxqUimHe/Z9Mlei3QTuTskYimF/P8=; X-AuditID: c1b4fb30-6ebff7000000095a-6c-5aaab8257eed Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id CB.8E.02394.528BAAA5; Thu, 15 Mar 2018 19:15:01 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.172]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0382.000; Thu, 15 Mar 2018 19:15:00 +0100 From: Christer Holmberg To: "sipcore@ietf.org" Thread-Topic: Draft new version: sip-push-09 Thread-Index: AdO8iRaPpGP3abnGRKaHXjllGOaAcw== Date: Thu, 15 Mar 2018 18:15:00 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B6C20603B@ESESSMB109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.169] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B6C20603BESESSMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrGLMWRmVeSWpSXmKPExsUyM2K7hK7qjlVRBh39QhZff2xic2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXRseSk+wFnTIVTdOWsDUwdkt2MXJySAiYSNx8epG1i5GLQ0jg MKPE33ltTBDOEkaJw6vfMHYxcnCwCVhIdP/TBmkQEdCUWP5tKzuILSygLvH87CkmiLiOxIul 9xkhbD2J5xNWg9WwCKhKfF+wEizOK+ArMWlNIyuIzSggJvH91BqwXmYBcYlbT+YzQRwkILFk z3lmCFtU4uXjf6wQtpLEye7NLBD1+RK3Zs9lhZgpKHFy5hOWCYyCs5CMmoWkbBaSMoi4jsSC 3Z/YIGxtiWULXzPD2GcOPGZCFl/AyL6KUbQ4tTgpN93ISC+1KDO5uDg/Ty8vtWQTIzD0D275 bbCD8eVzx0OMAhyMSjy875esihJiTSwrrsw9xCjBwawkwnulGyjEm5JYWZValB9fVJqTWnyI UZqDRUmc96Qnb5SQQHpiSWp2ampBahFMlomDU6qB0SLQPGnN+46Fzi77JiXVvvWMODHjbpcm w7p0oQvu10W2XX4WISX+paL3Vp5r6rZVqaaHvs8pszr6qPrXnt0b61b/WzuPX25OhmhQcoaB 7Y3Ut3FeR9408E/00dHoZnPRPxm/8IFaQcnb+MCS8q706sIb2jyb7ySIlFY/v/r2WXHpQY8b 3zK4lViKMxINtZiLihMBR/RFbnkCAAA= Archived-At: Subject: [sipcore] Draft new version: sip-push-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: Thu, 15 Mar 2018 18:15:05 -0000 --_000_7594FB04B1934943A5C02806D1A2204B6C20603BESESSMB109erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Based on the comments from Martin and Roman, and submitted a new version (-= 09) of draft-sip-push. The following pull requests were merged and implemented in the new version: https://github.com/cdh4u/draft-sip-push/pull/15 https://github.com/cdh4u/draft-sip-push/pull/14 Thanks to everyone who provided comments! :) Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B6C20603BESESSMB109erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Based on the comments from Martin and Roman, and sub= mitted a new version (-09) of draft-sip-push.

 

The following pull requests were merged and implemen= ted in the new version:

 

https://github.com/cdh4u/draft-sip-push/pull/15

 

https://github.com/cdh4u/draft-sip-push/pull/14

 

Thanks to everyone who provided comments! :)

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B6C20603BESESSMB109erics_-- From nobody Thu Mar 15 13:23:30 2018 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 B3445126B72 for ; Thu, 15 Mar 2018 13:23:28 -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 5IqyTTUz4S01 for ; Thu, 15 Mar 2018 13:23:25 -0700 (PDT) Received: from us-smtp-delivery-181.mimecast.com (us-smtp-delivery-181.mimecast.com [216.205.24.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C27F1205F0 for ; Thu, 15 Mar 2018 13:23:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-rbbn-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=3yWt6M4YjVu9nAVXF5KLujJf7VPuw1re8k93C/Jex0Y=; b=NTHP8KUHRRa4WGs+H0upZqZULEOVG558R2i5lNBQxCIG5jfA1mtnDleR5OqSWl/kd4o9rt2ftCa42yEDYuEeVOGkBDY2Q8cMjnfBme9nDlXUbxZmlEHU+ulzAY4Nd9Zn4ph/7Ihkqoae7PY0kKDYooQfYA9A+X54uDlhpD2Wqac= Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01lp0175.outbound.protection.outlook.com [216.32.180.175]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-89-YhdDq_frNli-r5or--VCFQ-1; Thu, 15 Mar 2018 16:23:23 -0400 Received: from CY4PR03MB3160.namprd03.prod.outlook.com (10.171.245.165) by CY4PR03MB2743.namprd03.prod.outlook.com (10.173.38.9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.588.14; Thu, 15 Mar 2018 20:23:22 +0000 Received: from CY4PR03MB3160.namprd03.prod.outlook.com ([fe80::34a3:3001:f444:3072]) by CY4PR03MB3160.namprd03.prod.outlook.com ([fe80::34a3:3001:f444:3072%13]) with mapi id 15.20.0588.013; Thu, 15 Mar 2018 20:23:22 +0000 From: "Asveren, Tolga" To: "sipcore@ietf.org" Thread-Topic: WGLC: draft-ietf-sipcore-originating-cdiv-parameter Thread-Index: AdO8mvHNh2Fu7WwWT5iDJ4VxNB0Ygw== Date: Thu, 15 Mar 2018 20:23:21 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [73.29.251.142] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR03MB2743; 20:TsKoG256+mePbJQgG9wZIX3EmGbfsJ9dI2KjcmoUUJWvyxG5rDSkit6BmuaG3PAaYzgUcJVc6nwGNkBJ9lgGEazEa5UuWcLmueTyOuiD0lsnzo/E8kF507oqnfsKnTIwQdUDXD+JFIibNXDSaiLdaSG+cqjOrlVTSVgwKjCm+4c= x-ms-office365-filtering-correlation-id: 4519ce79-a571-4dc5-5e1a-08d58ab29926 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:CY4PR03MB2743; x-ms-traffictypediagnostic: CY4PR03MB2743: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(3231221)(944501244)(52105095)(93006095)(93001095)(6041310)(20161123564045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(6072148)(201708071742011); SRVR:CY4PR03MB2743; BCL:0; PCL:0; RULEID:; SRVR:CY4PR03MB2743; x-forefront-prvs: 0612E553B4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(366004)(396003)(39380400002)(346002)(39860400002)(189003)(199004)(106356001)(6916009)(74316002)(5630700001)(86362001)(478600001)(2351001)(19609705001)(33656002)(7696005)(6306002)(54896002)(9686003)(53936002)(14454004)(316002)(66066001)(68736007)(5660300001)(5640700003)(97736004)(55016002)(3846002)(6436002)(99286004)(6116002)(186003)(26005)(2906002)(8936002)(7736002)(6506007)(790700001)(3280700002)(25786009)(105586002)(102836004)(5250100002)(1730700003)(81166006)(3660700001)(81156014)(8676002)(2900100001)(2501003); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR03MB2743; H:CY4PR03MB3160.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; x-microsoft-antispam-message-info: Uhp1+OxalCxwY4myrS7s9h+ZjiBD+8ZMmiHHQlOz2EGX/O9C7QLtX7Rva42G74ug3KcQ0R5CA40lvpZ8WonOMiD1lHMw7efBfIUReS4Giy6AXAf1vlg3XAByR0JaSL7J5mlWbRnV3H7fxyiG+ZC+ylzX1NdGxhs2PSceI9/NtZCtVk77kYkfG6FrFF+q+xVK9TRWC+q2dZvEN/nTUOMVtXzXFw+8w1iNQAOHGqhoLDHVs4ul548VPCthLbBAjvhAx0ZAykFDT4wu1gpbbe4LhixEp6m/NMNNrtqsqi4jVCSUtWcfOFHJ47Gc5AILQk0Wh5zEk0rcDUAfL8QJme2uSw== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: rbbn.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4519ce79-a571-4dc5-5e1a-08d58ab29926 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Mar 2018 20:23:21.9939 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR03MB2743 X-MC-Unique: YhdDq_frNli-r5or--VCFQ-1 Content-Type: multipart/alternative; boundary="_000_CY4PR03MB31601B709A5A753A3290B03FA5D00CY4PR03MB3160namp_" Archived-At: Subject: [sipcore] WGLC: 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: Thu, 15 Mar 2018 20:23:29 -0000 --_000_CY4PR03MB31601B709A5A753A3290B03FA5D00CY4PR03MB3160namp_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 SSByZXZpZXdlZCB0aGUgZHJhZnQgYW5kIGhhdmUgbm8gdGVjaG5pY2FsIGlzc3VlcyB3aXRoIGl0 IGV4Y2VwdCBvbmUgcXVlc3Rpb246DQoNCklzIGl0IGVudmlzaW9uZWQgdGhhdCB0aGVyZSB3b3Vs ZC9jb3VsZCBiZSBhIG5lZWQgZm9yIHRlcm0tY2RpdiBhcyB3ZWxsIHRvIHRyaWdnZXIgYSBkaWZm ZXJlbnQgc2VydmljZSBzZXQgaWYgdGhlIHRhcmdldCBpcyBkZXRlcm1pbmVkIGFmdGVyIGRpdmVy c2lvbj8gSXQgbWF5IGJlIGJldHRlciB0byBkZWZpbmUgaXQgbm93IHJhdGhlciB0aGFuIGhhdmlu ZyB5ZXQgYW5vdGhlciBkcmFmdCwgYXQgbGVhc3QgdG8gYmUgZnV0dXJlIHByb29mLg0KDQpUaGFu a3MsDQpUb2xnYQ0K --_000_CY4PR03MB31601B709A5A753A3290B03FA5D00CY4PR03MB3160namp_ Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGlu O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk YXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0K PGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgcmV2aWV3ZWQgdGhlIGRy YWZ0IGFuZCBoYXZlIG5vIHRlY2huaWNhbCBpc3N1ZXMgd2l0aCBpdCBleGNlcHQgb25lIHF1ZXN0 aW9uOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JcyBpdCBlbnZpc2lvbmVkIHRoYXQgdGhlcmUg d291bGQvY291bGQgYmUgYSBuZWVkIGZvciB0ZXJtLWNkaXYgYXMgd2VsbCB0byB0cmlnZ2VyIGEg ZGlmZmVyZW50IHNlcnZpY2Ugc2V0IGlmIHRoZSB0YXJnZXQgaXMgZGV0ZXJtaW5lZCBhZnRlciBk aXZlcnNpb24/IEl0IG1heSBiZSBiZXR0ZXIgdG8gZGVmaW5lIGl0IG5vdyByYXRoZXIgdGhhbiBo YXZpbmcgeWV0IGFub3RoZXIgZHJhZnQsIGF0IGxlYXN0IHRvDQogYmUgZnV0dXJlIHByb29mLjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5Ub2xnYTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_CY4PR03MB31601B709A5A753A3290B03FA5D00CY4PR03MB3160namp_-- From nobody Thu Mar 15 19:00:38 2018 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 2EEFB129C6B for ; Thu, 15 Mar 2018 19:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.686 X-Spam-Level: X-Spam-Status: No, score=-1.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 vNHY_ltugi3T for ; Thu, 15 Mar 2018 19:00:36 -0700 (PDT) Received: from resqmta-ch2-01v.sys.comcast.net (resqmta-ch2-01v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:33]) (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 443031200B9 for ; Thu, 15 Mar 2018 19:00:36 -0700 (PDT) Received: from resomta-ch2-02v.sys.comcast.net ([69.252.207.98]) by resqmta-ch2-01v.sys.comcast.net with ESMTP id wefUewBJguciZwefbeZZmn; Fri, 16 Mar 2018 02:00:35 +0000 Received: from hobgoblin.ariadne.com ([65.96.206.41]) by resomta-ch2-02v.sys.comcast.net with SMTP id wefZelu2eRZWhwefaeiepg; Fri, 16 Mar 2018 02:00: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 w2G20YAD021462; Thu, 15 Mar 2018 22:00:34 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id w2G20YNL021459; Thu, 15 Mar 2018 22:00:34 -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: Thu, 15 Mar 2018 22:00:34 -0400 Message-ID: <87muz8zsn1.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfEhUDG6qr6oysDKUdv2VcffW/8eNNl/1NzfiwvYqF9rIKSAVj85iUj7FWi0qy7CzjKo9PTr79tuEkO6CFjWsIHP8Cqx69y1igtOPJBJRbbE7zJcra8A3 SdIBgI5VN2qXBfstg6UHISSfuKdRhZEZcmfbYJfhmWD3DsBIeR8Vt+NhdgxmAPtZBsS+SeE5fOydW/1cyT8Qq/y54COW4Oj0BpDr1JI7pKg0aE8GcxlbfHrz Archived-At: Subject: Re: [sipcore] SIP-push -- Where is the "proxy"? 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, 16 Mar 2018 02:00:37 -0000 Christer Holmberg writes: > I think what we now have is what the industry is requesting at the > moment. > > Later, if there is a need to have the proxy 'out-of-path' etc, we can > define new parameters etc needed for that in a separate draft. I can agree with this as a general concept, but I have qualms: The current version doesn't seem to specifically enunciate the situation in which the problem is being solved, so it's hard to judge whether it is the best solution we can devise for the problem. That is, I get the feeling that the draft was more devised to document *a* solution that works for some reasonably large problem area, rather than consciously ensuring it is the best solution we can devise for a well-defined problem space. In particular, though I've got to get caught up on it, it seems like a number of features of the solution are directly driven by a perceived distance between the registrar and the proxy that is implementing sip-push, but at the same time, the handling of re-REGISTER requires that there be little or no distance between the registrar and the implementing proxy. Dale From nobody Fri Mar 16 01:05:46 2018 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 1D67E126CBF for ; Fri, 16 Mar 2018 01:05:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.11 X-Spam-Level: X-Spam-Status: No, score=-4.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, 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_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 jMvQuF0gu7g3 for ; Fri, 16 Mar 2018 01:05:42 -0700 (PDT) Received: from us-smtp-delivery-181.mimecast.com (us-smtp-delivery-181.mimecast.com [63.128.21.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A8C21243FE for ; Fri, 16 Mar 2018 01:05:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-rbbn-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=BrxyqzpYIMvazHCYMBPmUPalaRonkbnqreaVN0uh2mg=; b=DQLKBz/Gdl3cHCgnPivdq4mB/EwLNjx8d05jfdVX7ldrg9sm8SLrs2+kKhfk5Fhpdr0h/LGFM11UcYHPcyAMamiC/BR7o457T/g8anTosynmldJpZbo64sZIzo+giEpVDSvte+KKh7BMjufdkLls5karoUnZsz37WRJnMDitGTU= Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01lp0184.outbound.protection.outlook.com [216.32.180.184]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-214-pbQcd8RRNHGb4ALPC-K3ig-1; Fri, 16 Mar 2018 04:05:39 -0400 Received: from CY4PR03MB3160.namprd03.prod.outlook.com (10.171.245.165) by CY4PR03MB3190.namprd03.prod.outlook.com (10.171.244.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.588.14; Fri, 16 Mar 2018 08:05:36 +0000 Received: from CY4PR03MB3160.namprd03.prod.outlook.com ([fe80::34a3:3001:f444:3072]) by CY4PR03MB3160.namprd03.prod.outlook.com ([fe80::34a3:3001:f444:3072%13]) with mapi id 15.20.0588.016; Fri, 16 Mar 2018 08:05:36 +0000 From: "Asveren, Tolga" To: "sipcore@ietf.org" Thread-Topic: WGLC: draft-ietf-sipcore-originating-cdiv-parameter Thread-Index: AdO8mvHNh2Fu7WwWT5iDJ4VxNB0YgwAP3GCg Date: Fri, 16 Mar 2018 08:05:36 +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.251.142] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR03MB3190; 7:tGJUQTVEoKft5AnhBLrGwPL2HSphT0QInXmeKsZ6SyuYjnHA48/jX2gysIgP9Fa7Spgaz+LFelifzQ/Bp37rv3NTgbhXuk4KExDAhvRPnpHjp5GzekMscwYOfdNvwTeDG821kJ/dtwUVV/y+h78bFEImu0APbwdk2qYd2oM5Ff4ZHJSdd6TnmKr8Kck4w4vjZH5IAgjakB89Z52NnN3aO6hL8Sg0T6ABYiobrCvKDy1geRL4+1tBNQQ/Dnc3K0R3; 20:bTwDKAuEpyHRSYQ55LFBmliVarTpzbXPwunatAGxfYPvfEW3T7xmCJGB9tATLtB+v6HtEVW+gnHkPh6GnoxphXMrEFpnl1CdN+0S9UFUCc/JUidN4Q8a+3ZT2XHH3eqlFx/4hRl2Z4WUomSGOLQiB9fUsDwa8P1m4oM8ZOTPTaQ= x-ms-office365-filtering-correlation-id: 120a15bb-14ac-44bf-6231-08d58b14b351 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:CY4PR03MB3190; x-ms-traffictypediagnostic: CY4PR03MB3190: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(131327999870524)(259379197776797)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231221)(944501244)(52105095)(3002001)(10201501046)(6041310)(20161123562045)(20161123564045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(6072148)(201708071742011); SRVR:CY4PR03MB3190; BCL:0; PCL:0; RULEID:; SRVR:CY4PR03MB3190; x-forefront-prvs: 0613912E23 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(39380400002)(366004)(39860400002)(346002)(396003)(199004)(189003)(3660700001)(6116002)(5630700001)(790700001)(25786009)(3846002)(14454004)(105586002)(1730700003)(66066001)(8676002)(81166006)(5660300001)(2900100001)(68736007)(8936002)(33656002)(478600001)(5250100002)(2501003)(81156014)(186003)(53546011)(6436002)(19609705001)(3280700002)(106356001)(97736004)(2906002)(99286004)(6246003)(2351001)(26005)(5640700003)(229853002)(6506007)(316002)(102836004)(7736002)(54896002)(6306002)(55016002)(9686003)(7696005)(76176011)(86362001)(53936002)(6916009)(74316002)(2950100002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR03MB3190; H:CY4PR03MB3160.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-microsoft-antispam-message-info: yT6A532foZZvx6DrnI9BR8GFV1kegbWQY1B4pStVsn26l8w3UKPZpuBThRKY57bdfnJAGCEwyaqm8QbmpU3NfN71rDko8A0C52OTk+Ey2Q5xvAI8ZsDjb1PIutd0E2NI4ksSewNDjjcgV8VyJNisI+/2qLvXlIJIakx1oAU1EXot+PcN+JT2BrMADgue2Ms9C+EgPujyd4cDWSMuUOH19+WN4LYOLOmtmBgGYDNSLIRoArCo2TspsT8OIheTTpHd741ynAmWzvMvDbU+vX8ye3GqMlE9Z8dJs8Bk3B867dl/KCauvzJ/Jb4jH4RQWkhKbaRIR0fq49USdALuGFZolA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: rbbn.com X-MS-Exchange-CrossTenant-Network-Message-Id: 120a15bb-14ac-44bf-6231-08d58b14b351 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Mar 2018 08:05:36.5761 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR03MB3190 X-MC-Unique: pbQcd8RRNHGb4ALPC-K3ig-1 Content-Type: multipart/alternative; boundary="_000_CY4PR03MB316007E3545EB4BDBD4B1D2DA5D70CY4PR03MB3160namp_" Archived-At: Subject: Re: [sipcore] WGLC: 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: Fri, 16 Mar 2018 08:05:45 -0000 --_000_CY4PR03MB316007E3545EB4BDBD4B1D2DA5D70CY4PR03MB3160namp_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 U29tZSBtb3JlIG11c2luZ3MgZnJvbSBjb25jZXB0dWFsIHBlcnNwZWN0aXZlOg0KDQpTSVAgcHJv dmlkZXMgYSB0b29sYm94IHRvIHByb3ZpZGUgc2VydmljZXMuIEFuZCB5ZXMsIHRoZXJlIGlzIHNv bWUgc3BlY2lhbCAoaWYgSSBtYXkgc2F5IOKAnGZhdm9yZWTigJ0pIHN0YXR1cyBvZiAzR1BQIHdo ZW4gaXQgY29tZXMgdG8gU0lQIHN0YW5kYXJkaXphdGlvbi4gT1RPSCwgZG9lcyB0aGUgYXBwcm9h Y2ggdGFrZW4gYnkgUkZDNTUwMiBnbyBhIGxpdHRsZSBiaXQgdG9vIGZhciBpbiB0ZXJtcyBvZiBv dmVyLWRlZmluaW5nIHRoZSBnZW5lcmljIFNJUCB0b29sYm94Pw0KDQpBbiBhbHRlcm5hdGl2ZSBj b3VsZCBiZSB0byBkZWZpbmUgYSBoZWFkZXIvcGFyYW1ldGVyIHdoaWNoIHJlZmVycyB0byBhIOKA nHNjZW5hcmlv4oCdIGluIGFuIGFic3RyYWN0IHdheSAod2l0aCBhIGdlbmVyaWMgc3ludGF4KSBh bmQgbGV0IG90aGVyIHN0YW5kYXJkcyBmb3JhIGRlZmluZSB0aGUgdmFsdWVzIHRoZXkgd291bGQg bGlrZSB0byB1c2UgYW5kL29yIHJlbHkgb24gY29uZmlndXJhdGlvbiBhbGlnbm1lbnQgYmV0d2Vl biByZWxldmFudCBlbGVtZW50cywgZS5nLiBTLUNTQ0YvSFNTL0FTLiBDb25zaWRlcmluZyB3aGVy ZSB3ZSBhcmUgcmlnaHQgbm93ICh0aGF0IFJGQzU1MDIgaXMgYWxyZWFkeSB0aGVyZSkgdGhpcyBh cHByb2FjaCBwcmFjdGljYWxseSB3b3VsZCBtZWFuIHRoYXQgZHJhZnQtaWV0Zi1zaXBjb3JlLW9y aWdpbmF0aW5nLWNkaXYtcGFyYW1ldGVyIGlzIG5vdCBkZWZpbmVkIGFuZCBQLVNlcnZlZC1Vc2Vy IHNlcnZlZC11c2VyLXBhcm0gaXMgZXh0ZW5kZWQgYnkgb3RoZXJzIGFzIG5lZWRlZCAoYXMgaXQg YWxsb3dzIHRoYXQpLg0KDQpPdGhlcndpc2UsIHRoZXJlIHdvdWxkL2NvdWxkIGJlIHRoZSBuZWVk IHRvIGtlZXAgYWRkaW5nIG5ldyB2YWx1ZXMgaW4gZGlmZmVyZW50IElFVEYgc3BlY2lmaWNhdGlv bnMgdGhlIG1vcmUg4oCcZGVwbG95bWVudCBtb2RlbCBzcGVjaWZpYyB1c2UgY2FzZXPigJ0gYXJl IG5lZWRlZC9kaXNjb3ZlcmVkL2ludmVudGVkLg0KDQpUaGFua3MsDQpUb2xnYQ0KRnJvbTogQXN2 ZXJlbiwgVG9sZ2ENClNlbnQ6IFRodXJzZGF5LCBNYXJjaCAxNSwgMjAxOCA0OjIzIFBNDQpUbzog c2lwY29yZUBpZXRmLm9yZw0KU3ViamVjdDogV0dMQzogZHJhZnQtaWV0Zi1zaXBjb3JlLW9yaWdp bmF0aW5nLWNkaXYtcGFyYW1ldGVyDQoNCkkgcmV2aWV3ZWQgdGhlIGRyYWZ0IGFuZCBoYXZlIG5v IHRlY2huaWNhbCBpc3N1ZXMgd2l0aCBpdCBleGNlcHQgb25lIHF1ZXN0aW9uOg0KDQpJcyBpdCBl bnZpc2lvbmVkIHRoYXQgdGhlcmUgd291bGQvY291bGQgYmUgYSBuZWVkIGZvciB0ZXJtLWNkaXYg YXMgd2VsbCB0byB0cmlnZ2VyIGEgZGlmZmVyZW50IHNlcnZpY2Ugc2V0IGlmIHRoZSB0YXJnZXQg aXMgZGV0ZXJtaW5lZCBhZnRlciBkaXZlcnNpb24/IEl0IG1heSBiZSBiZXR0ZXIgdG8gZGVmaW5l IGl0IG5vdyByYXRoZXIgdGhhbiBoYXZpbmcgeWV0IGFub3RoZXIgZHJhZnQsIGF0IGxlYXN0IHRv IGJlIGZ1dHVyZSBwcm9vZi4NCg0KVGhhbmtzLA0KVG9sZ2ENCg== --_000_CY4PR03MB316007E3545EB4BDBD4B1D2DA5D70CY4PR03MB3160namp_ Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJ Y29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAy NiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+ DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5n PSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2Vj dGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U29tZSBtb3JlIG11c2luZ3MgZnJvbSBjb25j ZXB0dWFsIHBlcnNwZWN0aXZlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TSVAgcHJvdmlkZXMg YSB0b29sYm94IHRvIHByb3ZpZGUgc2VydmljZXMuIEFuZCB5ZXMsIHRoZXJlIGlzIHNvbWUgc3Bl Y2lhbCAoaWYgSSBtYXkgc2F5IOKAnGZhdm9yZWTigJ0pIHN0YXR1cyBvZiAzR1BQIHdoZW4gaXQg Y29tZXMgdG8gU0lQIHN0YW5kYXJkaXphdGlvbi4gT1RPSCwgZG9lcyB0aGUgYXBwcm9hY2ggdGFr ZW4gYnkgUkZDNTUwMiBnbyBhIGxpdHRsZSBiaXQgdG9vIGZhciBpbiB0ZXJtcyBvZiBvdmVyLWRl ZmluaW5nDQogdGhlIGdlbmVyaWMgU0lQIHRvb2xib3g/PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkFuIGFsdGVybmF0aXZlIGNvdWxkIGJlIHRvIGRlZmluZSBhIGhlYWRlci9wYXJhbWV0ZXIgd2hp Y2ggcmVmZXJzIHRvIGEg4oCcc2NlbmFyaW/igJ0gaW4gYW4gYWJzdHJhY3Qgd2F5ICh3aXRoIGEg Z2VuZXJpYyBzeW50YXgpIGFuZCBsZXQgb3RoZXIgc3RhbmRhcmRzIGZvcmEgZGVmaW5lIHRoZSB2 YWx1ZXMgdGhleSB3b3VsZCBsaWtlIHRvIHVzZSBhbmQvb3IgcmVseSBvbiBjb25maWd1cmF0aW9u IGFsaWdubWVudCBiZXR3ZWVuDQogcmVsZXZhbnQgZWxlbWVudHMsIGUuZy4gUy1DU0NGL0hTUy9B Uy4gQ29uc2lkZXJpbmcgd2hlcmUgd2UgYXJlIHJpZ2h0IG5vdyAodGhhdCBSRkM1NTAyIGlzIGFs cmVhZHkgdGhlcmUpIHRoaXMgYXBwcm9hY2ggcHJhY3RpY2FsbHkgd291bGQgbWVhbiB0aGF0IGRy YWZ0LWlldGYtc2lwY29yZS1vcmlnaW5hdGluZy1jZGl2LXBhcmFtZXRlciBpcyBub3QgZGVmaW5l ZCBhbmQgUC1TZXJ2ZWQtVXNlciBzZXJ2ZWQtdXNlci1wYXJtIGlzIGV4dGVuZGVkDQogYnkgb3Ro ZXJzIGFzIG5lZWRlZCAoYXMgaXQgYWxsb3dzIHRoYXQpLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5PdGhlcndpc2UsIHRoZXJlIHdvdWxkL2NvdWxkIGJlIHRoZSBuZWVkIHRvIGtlZXAgYWRkaW5n IG5ldyB2YWx1ZXMgaW4gZGlmZmVyZW50IElFVEYgc3BlY2lmaWNhdGlvbnMgdGhlIG1vcmUg4oCc ZGVwbG95bWVudCBtb2RlbCBzcGVjaWZpYyB1c2UgY2FzZXPigJ0gYXJlIG5lZWRlZC9kaXNjb3Zl cmVkL2ludmVudGVkLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MsPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ub2xnYTxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRk aW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9i PiBBc3ZlcmVuLCBUb2xnYSA8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIE1hcmNoIDE1LCAy MDE4IDQ6MjMgUE08YnI+DQo8Yj5Ubzo8L2I+IHNpcGNvcmVAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gV0dMQzogZHJhZnQtaWV0Zi1zaXBjb3JlLW9yaWdpbmF0aW5nLWNkaXYtcGFyYW1l dGVyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHJldmlld2VkIHRo ZSBkcmFmdCBhbmQgaGF2ZSBubyB0ZWNobmljYWwgaXNzdWVzIHdpdGggaXQgZXhjZXB0IG9uZSBx dWVzdGlvbjo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXMgaXQgZW52aXNpb25lZCB0aGF0IHRo ZXJlIHdvdWxkL2NvdWxkIGJlIGEgbmVlZCBmb3IgdGVybS1jZGl2IGFzIHdlbGwgdG8gdHJpZ2dl ciBhIGRpZmZlcmVudCBzZXJ2aWNlIHNldCBpZiB0aGUgdGFyZ2V0IGlzIGRldGVybWluZWQgYWZ0 ZXIgZGl2ZXJzaW9uPyBJdCBtYXkgYmUgYmV0dGVyIHRvIGRlZmluZSBpdCBub3cgcmF0aGVyIHRo YW4gaGF2aW5nIHlldCBhbm90aGVyIGRyYWZ0LCBhdCBsZWFzdCB0bw0KIGJlIGZ1dHVyZSBwcm9v Zi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+VG9sZ2E8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_CY4PR03MB316007E3545EB4BDBD4B1D2DA5D70CY4PR03MB3160namp_-- From nobody Fri Mar 16 04:03:53 2018 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 74994126CB6 for ; Fri, 16 Mar 2018 04:03:51 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-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=ericsson.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 djDHK_waIU6u for ; Fri, 16 Mar 2018 04:03:50 -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 7FCC2126BF7 for ; Fri, 16 Mar 2018 04:03:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1521198227; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=BlXsnd2IZRmYlDFQTUEgteLyPPuPxEesIWyLBIpIbnQ=; b=NGTd8MB2VqYq8fJKYzfGCD9E8Lm5NnYw6qVIxYr0a7FoIaz9OQ3BhjLOq2bJwnKD GKhA7tgJzEkJN5g3CwqxHsdQUQBpyxWsM+HQjMYa6r26T8Bn0GetNAvyUgX0BEyv 66oJBBGqekJyaGHGE1n4Tk6CG5P2zRbciapvvQV5spc=; X-AuditID: c1b4fb3a-728f89c0000067b4-29-5aaba493ea9f Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 02.94.26548.394ABAA5; Fri, 16 Mar 2018 12:03:47 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.172]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0382.000; Fri, 16 Mar 2018 12:03:13 +0100 From: Christer Holmberg To: "Asveren, Tolga" , "sipcore@ietf.org" Thread-Topic: WGLC: draft-ietf-sipcore-originating-cdiv-parameter Thread-Index: AdO8mvHNh2Fu7WwWT5iDJ4VxNB0YgwAP3GCgAA7g1HA= Date: Fri, 16 Mar 2018 11:03:12 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B6C207220@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.165] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B6C207220ESESSMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplkeLIzCtJLcpLzFFi42KZGbHdT3fyktVRBtOaDCy+/tjEZrF++Td2 ByaPJUt+MnnsmTOJMYApissmJTUnsyy1SN8ugStj5l61gn/xFT0LbrI0MG6I7WLk5JAQMJGY 3/yNvYuRi0NI4DCjxLVdS5khnCWMEne6b7F1MXJwsAlYSHT/0wZpEBEIlHg/5xwriC0s4CBx recUI0TcUaL53U9mCNtKYsPXPrAaFgFViY3PN7OAjOEV8JWYPscAYvx6oF3HXjOCxDkFYiWm HcoDKWcUEJP4fmoNE4jNLCAucevJfCaIOwUkluw5zwxhi0q8fPyPFcJWkph1ayNUfb7Ejbvf 2UBsXgFBiZMzn7BMYBSehWTULCRls5CUzQK6gllAU2L9Ln2IEkWJKd0P2SFsDYnWOXPZkcUX MLKvYhQtTi0uzk03MtJLLcpMLi7Oz9PLSy3ZxAiMnINbflvtYDz43PEQowAHoxIP75vZq6OE WBPLiitzDzFKcDArifBazgQK8aYkVlalFuXHF5XmpBYfYpTmYFES53VKs4gSEkhPLEnNTk0t SC2CyTJxcEo1ME7k+rxc4krkTzfRsFfeLL2Oux+ufB+WL/tdz9ZvXVflWeMp3aJsObU1HbKW URcfmLFdnGI9r/CoTaizmH/rhYPyCTPiNz7J4XfnVllWPuFD59mTPwJ//tnkFm8qmPI87Ybs v+7kLe/XL8qZz2PvX6QalBp1dKf4AtHKhY9+THSP1LdcWbB4uRJLcUaioRZzUXEiAM0WKX+Y AgAA Archived-At: Subject: Re: [sipcore] WGLC: 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: Fri, 16 Mar 2018 11:03:51 -0000 --_000_7594FB04B1934943A5C02806D1A2204B6C207220ESESSMB109erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCldlIGNhbiBmb3Igc3VyZSBkaXNjdXNzIGhvdyBleHRlbnNpb25zIGFuZCB2YWx1ZXMg bmVlZGVkIGJ5IDNHUFAgYXJlIGhhbmRsZWQgaW4gdGhlIGZ1dHVyZS4gQnV0LCBhcyBmYXIgYXMg dGhpcyBkcmFmdCBpcyBjb25jZXJuZWQsIHdlIHNob3VsZCBmb2xsb3cgdGhlIHByb2NlZHVyZXMg d2UgY3VycmVudGx5IGhhdmUsIGFuZCBub3cgaG9sZCB0aGUgZHJhZnQgd2hpbGUgd2UgZmlndXJl IG91dCBob3cvaWYgdGhvc2UgcHJvY2VkdXJlcyBjYW4gYmUgY2hhbmdlZC4NCg0KUmVnYXJkcywN Cg0KQ2hyaXN0ZXINCg0KRnJvbTogc2lwY29yZSBbbWFpbHRvOnNpcGNvcmUtYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIEFzdmVyZW4sIFRvbGdhDQpTZW50OiAxNiBNYXJjaCAyMDE4IDEw OjA2DQpUbzogc2lwY29yZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtzaXBjb3JlXSBXR0xDOiBk cmFmdC1pZXRmLXNpcGNvcmUtb3JpZ2luYXRpbmctY2Rpdi1wYXJhbWV0ZXINCg0KU29tZSBtb3Jl IG11c2luZ3MgZnJvbSBjb25jZXB0dWFsIHBlcnNwZWN0aXZlOg0KDQpTSVAgcHJvdmlkZXMgYSB0 b29sYm94IHRvIHByb3ZpZGUgc2VydmljZXMuIEFuZCB5ZXMsIHRoZXJlIGlzIHNvbWUgc3BlY2lh bCAoaWYgSSBtYXkgc2F5IOKAnGZhdm9yZWTigJ0pIHN0YXR1cyBvZiAzR1BQIHdoZW4gaXQgY29t ZXMgdG8gU0lQIHN0YW5kYXJkaXphdGlvbi4gT1RPSCwgZG9lcyB0aGUgYXBwcm9hY2ggdGFrZW4g YnkgUkZDNTUwMiBnbyBhIGxpdHRsZSBiaXQgdG9vIGZhciBpbiB0ZXJtcyBvZiBvdmVyLWRlZmlu aW5nIHRoZSBnZW5lcmljIFNJUCB0b29sYm94Pw0KDQpBbiBhbHRlcm5hdGl2ZSBjb3VsZCBiZSB0 byBkZWZpbmUgYSBoZWFkZXIvcGFyYW1ldGVyIHdoaWNoIHJlZmVycyB0byBhIOKAnHNjZW5hcmlv 4oCdIGluIGFuIGFic3RyYWN0IHdheSAod2l0aCBhIGdlbmVyaWMgc3ludGF4KSBhbmQgbGV0IG90 aGVyIHN0YW5kYXJkcyBmb3JhIGRlZmluZSB0aGUgdmFsdWVzIHRoZXkgd291bGQgbGlrZSB0byB1 c2UgYW5kL29yIHJlbHkgb24gY29uZmlndXJhdGlvbiBhbGlnbm1lbnQgYmV0d2VlbiByZWxldmFu dCBlbGVtZW50cywgZS5nLiBTLUNTQ0YvSFNTL0FTLiBDb25zaWRlcmluZyB3aGVyZSB3ZSBhcmUg cmlnaHQgbm93ICh0aGF0IFJGQzU1MDIgaXMgYWxyZWFkeSB0aGVyZSkgdGhpcyBhcHByb2FjaCBw cmFjdGljYWxseSB3b3VsZCBtZWFuIHRoYXQgZHJhZnQtaWV0Zi1zaXBjb3JlLW9yaWdpbmF0aW5n LWNkaXYtcGFyYW1ldGVyIGlzIG5vdCBkZWZpbmVkIGFuZCBQLVNlcnZlZC1Vc2VyIHNlcnZlZC11 c2VyLXBhcm0gaXMgZXh0ZW5kZWQgYnkgb3RoZXJzIGFzIG5lZWRlZCAoYXMgaXQgYWxsb3dzIHRo YXQpLg0KDQpPdGhlcndpc2UsIHRoZXJlIHdvdWxkL2NvdWxkIGJlIHRoZSBuZWVkIHRvIGtlZXAg YWRkaW5nIG5ldyB2YWx1ZXMgaW4gZGlmZmVyZW50IElFVEYgc3BlY2lmaWNhdGlvbnMgdGhlIG1v cmUg4oCcZGVwbG95bWVudCBtb2RlbCBzcGVjaWZpYyB1c2UgY2FzZXPigJ0gYXJlIG5lZWRlZC9k aXNjb3ZlcmVkL2ludmVudGVkLg0KDQpUaGFua3MsDQpUb2xnYQ0KRnJvbTogQXN2ZXJlbiwgVG9s Z2ENClNlbnQ6IFRodXJzZGF5LCBNYXJjaCAxNSwgMjAxOCA0OjIzIFBNDQpUbzogc2lwY29yZUBp ZXRmLm9yZzxtYWlsdG86c2lwY29yZUBpZXRmLm9yZz4NClN1YmplY3Q6IFdHTEM6IGRyYWZ0LWll dGYtc2lwY29yZS1vcmlnaW5hdGluZy1jZGl2LXBhcmFtZXRlcg0KDQpJIHJldmlld2VkIHRoZSBk cmFmdCBhbmQgaGF2ZSBubyB0ZWNobmljYWwgaXNzdWVzIHdpdGggaXQgZXhjZXB0IG9uZSBxdWVz dGlvbjoNCg0KSXMgaXQgZW52aXNpb25lZCB0aGF0IHRoZXJlIHdvdWxkL2NvdWxkIGJlIGEgbmVl ZCBmb3IgdGVybS1jZGl2IGFzIHdlbGwgdG8gdHJpZ2dlciBhIGRpZmZlcmVudCBzZXJ2aWNlIHNl dCBpZiB0aGUgdGFyZ2V0IGlzIGRldGVybWluZWQgYWZ0ZXIgZGl2ZXJzaW9uPyBJdCBtYXkgYmUg YmV0dGVyIHRvIGRlZmluZSBpdCBub3cgcmF0aGVyIHRoYW4gaGF2aW5nIHlldCBhbm90aGVyIGRy YWZ0LCBhdCBsZWFzdCB0byBiZSBmdXR1cmUgcHJvb2YuDQoNClRoYW5rcywNClRvbGdhDQo= --_000_7594FB04B1934943A5C02806D1A2204B6C207220ESESSMB109erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6 d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0 OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv bnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIu MHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0 aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4N CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlv dXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286 c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1H QiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Q7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+V2UgY2FuIGZvciBzdXJlIGRpc2N1c3MgaG93IGV4dGVuc2lvbnMgYW5kIHZhbHVlcyBuZWVk ZWQgYnkgM0dQUCBhcmUgaGFuZGxlZCBpbiB0aGUgZnV0dXJlLiBCdXQsIGFzIGZhciBhcyB0aGlz IGRyYWZ0IGlzIGNvbmNlcm5lZCwgd2Ugc2hvdWxkIGZvbGxvdyB0aGUgcHJvY2VkdXJlcyB3ZSBj dXJyZW50bHkgaGF2ZSwNCiBhbmQgbm93IGhvbGQgdGhlIGRyYWZ0IHdoaWxlIHdlIGZpZ3VyZSBv dXQgaG93L2lmIHRob3NlIHByb2NlZHVyZXMgY2FuIGJlIGNoYW5nZWQuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Q7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEO21zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+Q2hyaXN0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEO21z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9w Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFF MSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIGxhbmc9IkVOLVVTIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMi PiBzaXBjb3JlIFttYWlsdG86c2lwY29yZS1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxm IE9mIDwvYj5Bc3ZlcmVuLCBUb2xnYTxicj4NCjxiPlNlbnQ6PC9iPiAxNiBNYXJjaCAyMDE4IDEw OjA2PGJyPg0KPGI+VG86PC9iPiBzaXBjb3JlQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+ IFJlOiBbc2lwY29yZV0gV0dMQzogZHJhZnQtaWV0Zi1zaXBjb3JlLW9yaWdpbmF0aW5nLWNkaXYt cGFyYW1ldGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPlNvbWUgbW9yZSBtdXNpbmdzIGZyb20gY29uY2VwdHVhbCBwZXJz cGVjdGl2ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlNJUCBwcm92aWRlcyBhIHRvb2xib3ggdG8gcHJv dmlkZSBzZXJ2aWNlcy4gQW5kIHllcywgdGhlcmUgaXMgc29tZSBzcGVjaWFsIChpZiBJIG1heSBz YXkg4oCcZmF2b3JlZOKAnSkgc3RhdHVzIG9mIDNHUFAgd2hlbiBpdCBjb21lcyB0byBTSVAgc3Rh bmRhcmRpemF0aW9uLiBPVE9ILCBkb2VzIHRoZSBhcHByb2FjaCB0YWtlbiBieSBSRkM1NTAyIGdv IGEgbGl0dGxlIGJpdCB0b28gZmFyDQogaW4gdGVybXMgb2Ygb3Zlci1kZWZpbmluZyB0aGUgZ2Vu ZXJpYyBTSVAgdG9vbGJveD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkFuIGFsdGVybmF0aXZlIGNvdWxk IGJlIHRvIGRlZmluZSBhIGhlYWRlci9wYXJhbWV0ZXIgd2hpY2ggcmVmZXJzIHRvIGEg4oCcc2Nl bmFyaW/igJ0gaW4gYW4gYWJzdHJhY3Qgd2F5ICh3aXRoIGEgZ2VuZXJpYyBzeW50YXgpIGFuZCBs ZXQgb3RoZXIgc3RhbmRhcmRzIGZvcmEgZGVmaW5lIHRoZSB2YWx1ZXMgdGhleSB3b3VsZCBsaWtl IHRvIHVzZSBhbmQvb3IgcmVseSBvbiBjb25maWd1cmF0aW9uDQogYWxpZ25tZW50IGJldHdlZW4g cmVsZXZhbnQgZWxlbWVudHMsIGUuZy4gUy1DU0NGL0hTUy9BUy4gQ29uc2lkZXJpbmcgd2hlcmUg d2UgYXJlIHJpZ2h0IG5vdyAodGhhdCBSRkM1NTAyIGlzIGFscmVhZHkgdGhlcmUpIHRoaXMgYXBw cm9hY2ggcHJhY3RpY2FsbHkgd291bGQgbWVhbiB0aGF0IGRyYWZ0LWlldGYtc2lwY29yZS1vcmln aW5hdGluZy1jZGl2LXBhcmFtZXRlciBpcyBub3QgZGVmaW5lZCBhbmQgUC1TZXJ2ZWQtVXNlciBz ZXJ2ZWQtdXNlci1wYXJtDQogaXMgZXh0ZW5kZWQgYnkgb3RoZXJzIGFzIG5lZWRlZCAoYXMgaXQg YWxsb3dzIHRoYXQpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+T3RoZXJ3aXNlLCB0aGVyZSB3b3VsZC9j b3VsZCBiZSB0aGUgbmVlZCB0byBrZWVwIGFkZGluZyBuZXcgdmFsdWVzIGluIGRpZmZlcmVudCBJ RVRGIHNwZWNpZmljYXRpb25zIHRoZSBtb3JlIOKAnGRlcGxveW1lbnQgbW9kZWwgc3BlY2lmaWMg dXNlIGNhc2Vz4oCdIGFyZSBuZWVkZWQvZGlzY292ZXJlZC9pbnZlbnRlZC48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+VG9sZ2E8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g bGFuZz0iRU4tVVMiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IEFzdmVyZW4s IFRvbGdhDQo8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIE1hcmNoIDE1LCAyMDE4IDQ6MjMg UE08YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzpzaXBjb3JlQGlldGYub3JnIj5zaXBj b3JlQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBXR0xDOiBkcmFmdC1pZXRmLXNp cGNvcmUtb3JpZ2luYXRpbmctY2Rpdi1wYXJhbWV0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj5JIHJldmlld2VkIHRoZSBkcmFmdCBhbmQgaGF2ZSBubyB0ZWNobmljYWwgaXNz dWVzIHdpdGggaXQgZXhjZXB0IG9uZSBxdWVzdGlvbjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPklzIGl0 IGVudmlzaW9uZWQgdGhhdCB0aGVyZSB3b3VsZC9jb3VsZCBiZSBhIG5lZWQgZm9yIHRlcm0tY2Rp diBhcyB3ZWxsIHRvIHRyaWdnZXIgYSBkaWZmZXJlbnQgc2VydmljZSBzZXQgaWYgdGhlIHRhcmdl dCBpcyBkZXRlcm1pbmVkIGFmdGVyIGRpdmVyc2lvbj8gSXQgbWF5IGJlIGJldHRlciB0byBkZWZp bmUgaXQgbm93IHJhdGhlciB0aGFuIGhhdmluZyB5ZXQgYW5vdGhlcg0KIGRyYWZ0LCBhdCBsZWFz dCB0byBiZSBmdXR1cmUgcHJvb2YuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGFua3MsPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRv bGdhPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7594FB04B1934943A5C02806D1A2204B6C207220ESESSMB109erics_-- From nobody Fri Mar 16 04:26:57 2018 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 8E30B127735 for ; Fri, 16 Mar 2018 04:26:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.63 X-Spam-Level: X-Spam-Status: No, score=-2.63 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 ZiTON6nYYfz8 for ; Fri, 16 Mar 2018 04:26:54 -0700 (PDT) Received: from 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 24445126BF7 for ; Fri, 16 Mar 2018 04:26:54 -0700 (PDT) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id 5B27D20978; Fri, 16 Mar 2018 12:26:52 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.66]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 38F4020077; Fri, 16 Mar 2018 12:26:52 +0100 (CET) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILMA1.corporate.adroot.infra.ftgroup ([fe80::95e2:eb4b:3053:fabf%19]) with mapi id 14.03.0382.000; Fri, 16 Mar 2018 12:26:52 +0100 From: To: "Asveren, Tolga" , "sipcore@ietf.org" Thread-Topic: WGLC: draft-ietf-sipcore-originating-cdiv-parameter Thread-Index: AdO8mvHNh2Fu7WwWT5iDJ4VxNB0YgwAP3GCgAArG/7A= Date: Fri, 16 Mar 2018 11:26:51 +0000 Message-ID: <24496_1521199612_5AABA9FC_24496_87_1_8B970F90C584EA4E97D5BAAC9172DBB81D70AC30@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.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sipcore] WGLC: 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: Fri, 16 Mar 2018 11:26:55 -0000 SGkgVG9sZ2EsDQoNCkZpcnN0LCB0aGFuayB5b3UgZm9yIHRoZSByZXZpZXcgb2YgdGhlIGRyYWZ0 Lg0KVG8gYW5zd2VyIHRvIHRoZSBxdWVzdGlvbiBpbiB5b3VyIGZpcnN0IGVtYWlsLCBvbmNlIGEg ZGl2ZXJzaW9uIGhhcyBiZWVuIHByb2Nlc3NlZCwgdGhlIG91dGdvaW5nIGxlZyB3aWxsIGdvIHRv IHRoZSBkaXZlcnNpb24gdGFyZ2V0IGJ1dCBiZWZvcmUgdGhhdCwgdGhlIHNlc3Npb24gY2FzZSBv ZiB0aGUgc2VydmVkLXVzZXIgaGFzIGJlZW4gY2hhbmdlZCB3aXRoIHRoZSBmb2xsb3dpbmcgcXVl c3Rpb25zOiB3aG8gaXMgdGhlIG9yaWdpbmF0aW5nIHBhcnR5PyB0aGUgY2FsbGVyIG9yIHRoZSBk aXZlcnRpbmcgdXNlcj8gRG9lcyBwcml2YWN5IG9mIHRoZSBkaXZlcnRpbmcgdXNlciBhcHBsaWVz PyBkbyB3ZSBuZWVkIHRvIGNoZWNrIHRoZSBiYXJyaW5nIHNlcnZpY2Ugb2YgdGhlIGRpdmVydGlu ZyB1c2VyIGZvciBvdXRnb2luZyBjYWxscz8gT1RPSCwgdGhlIGNhbGxlciByZW1haW4gdGhlIHNh bWUgYW5kIGl0cyBvcmlnaW5hdGluZyBzZXJ2aWNlcyBzaG91bGQgc3RpbGwgYXBwbHkuIEZvciB0 aGF0IHBhcnRpY3VsYXIgc2l0dWF0aW9uIHNvbWV3aGVyZSBiZXR3ZWVuIHRlcm1pbmF0aW5nIGFu ZCBvcmlnaW5hdGluZywgdGhlIGRyYWZ0IHByb3Bvc2VzIHRvIGV4dGVuZCB0aGUgUC1TZXJ2ZWQt dXNlci4gDQpBdCB0aGUgZGl2ZXJ0ZWQtdG8gdXNlciBsZXZlbCwgaXQgaXMgZGlmZmVyZW50OiBJ dCBtYXkgaW5kZWVkIGJlIHBvc3NpYmxlIHRvIHRyaWdnZXIgYSBzcGVjaWZpYyBzZXJ2aWNlIGZv ciB0aGUgdGVybWluYXRpbmctYWZ0ZXItZGl2ZXJzaW9uIGJ1dCB0aGlzIGlzIG5vdCBhIG5ldyB0 eXBlIHNlc3Npb24gY2FzZS4gQXQgdGhlIHRlcm1pbmF0aW5nIHNpZGUsIHRoZSBzZXJ2ZWQgdXNl ciByZW1haW5zIHRoZSB0ZXJtaW5hdGluZyB1c2VyIGFuZCBvbmx5IGl0cyB0ZXJtaW5hdGluZyBz ZXJ2aWNlcyBoYXZlIHRvIGJlIHRyaWdnZXJlZC4gT2YgY291cnNlLCB0ZXJtaW5hdGluZyBzZXJ2 aWNlcyBiYXNlZCBvbiB0aGUgb3JpZ2luYXRpbmcgcGFydHkgaWRlbnRpdHkgYXJlIGFmZmVjdGVk IGJ5IHRoZSBjYWxsIGRpdmVyc2lvbiBzaW5jZSB3ZSBjYW4gZGlzY3VzcyBvbiB3aG8gaXMgdGhl IG9yaWdpbmF0aW5nIHBhcnR5IGJ1dCB0aGlzIGlzIG1vcmUgYSBtYXR0ZXIgb2Ygc2VydmljZSBp bnRlcmFjdGlvbi4gVGhlIHNlcnZlZC11c2VyIGlzIHRoZSBkaXZlcnNpb24gdGFyZ2V0IGFuZCB0 aGUgc2Vzc2lvbiBjYXNlIGlzIHRlcm1pbmF0aW5nIGFuZCBpdCB3aWxsIG5vdCBjaGFuZ2UgKGV4 Y2VwdCBpZiB0aGVyZSBpcyBhbm90aGVyIGNhbGwgZGl2ZXJzaW9uIDspLiBKdXN0IHRvIGxldCB5 b3Uga25vdywgdGhlcmUgaXMgYSBzZXJ2aWNlIHRvIHJlamVjdCBpbmNvbWluZyBmb3J3YXJkZWQg Y2FsbHMgYW5kIHRoZSB0cmlnZ2VyIGZvciB0aGlzIHNwZWNpZmljIGtpbmQgb2YgYmFycmluZyBp cyB0aGUgcHJlc2VuY2Ugb2YgYSBkaXZlcnRpbmcgdXNlciBpZGVudGl0eSBpbiB0aGUgaW5jb21p bmcgSU5WSVRFIHJlcXVlc3QuIEl0IGlzIGp1c3QgYSBjcml0ZXJpb24gKGFzIGZvciBhbGwgYmFy cmluZyBzZXJ2aWNlcykuIA0KDQpBYm91dCB5b3VyIGNvbW1lbnQgb24gdGhlIHdheSBTSVAgaGVh ZGVycyBhcmUgZXh0ZW5kZWQsIElNTywgcnVsZXMgZm9yIHN0YW5kYXJkaXphdGlvbiBwcm9jZXNz IG9mIFNJUCBhcmUgaGVyZSBmb3IgeWVhcnMgYW5kIGl0IGlzIG5vdCB0aGUgZ29vZCB0aW1lIHRv IGNoYW5nZSB0aGF0LiBUbyBiZSB0cmFuc3BhcmVudCwgdGhpcyBleHRlbnNpb24gd2FzIGZpcnN0 IGRlZmluZWQgb25seSB3aXRoaW4gM0dQUCBzcGVjaWZpY2F0aW9uIGJlY2F1c2UgdGhlcmUgd2Fz IGEgc2VydmljZSBuZWVkIGJlaGluZC4gQmVjYXVzZSBpdCB3YXMgYW4gZXh0ZW5zaW9uIG9mIGFu IFJGQyBhbmQgdGhlIHdhcyB0aGUgc3ludGF4IG9mIHRoZSBoZWFkZXIgaXMgZGVzaWduZWQsIHRo ZSBleHRlbnNpb24gaXMgdG8gYmUgZG9uZSBpbiBJRVRGLiBXZSBjYW4gZGlzY3VzcyB0aGF0IGJ1 dCB3ZSBhcmUgYXQgdGhlIGVuZCBvZiBTSVAgcHJvdG9jb2wgZXh0ZW5zaW9uIHByb2Nlc3MuLi4N CkZpbmFsbHksIFJGQzU1MDIgZGVmaW5lcyBhIOKAnHByaXZhdGXigJ0gKFAtICkgaGVhZGVyIHNv IGl0IGlzIG5vdCBzdXJwcmlzaW5nIHRoYXQgaXRzIGV4dGVuc2lvbiBhcyBhIDNHUFAgZmxhdm9y IOKYug0KDQpCZXN0IHJlZ2FyZHMsDQpNYXJpYW5uZQ0KDQoNCkRlwqA6IHNpcGNvcmUgW21haWx0 bzpzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgQXN2ZXJlbiwgVG9sZ2EN CkVudm95w6nCoDogdmVuZHJlZGkgMTYgbWFycyAyMDE4IDA5OjA2DQrDgMKgOiBzaXBjb3JlQGll dGYub3JnDQpPYmpldMKgOiBSZTogW3NpcGNvcmVdIFdHTEM6IGRyYWZ0LWlldGYtc2lwY29yZS1v cmlnaW5hdGluZy1jZGl2LXBhcmFtZXRlcg0KDQpTb21lIG1vcmUgbXVzaW5ncyBmcm9tIGNvbmNl cHR1YWwgcGVyc3BlY3RpdmU6DQoNClNJUCBwcm92aWRlcyBhIHRvb2xib3ggdG8gcHJvdmlkZSBz ZXJ2aWNlcy4gQW5kIHllcywgdGhlcmUgaXMgc29tZSBzcGVjaWFsIChpZiBJIG1heSBzYXkg4oCc ZmF2b3JlZOKAnSkgc3RhdHVzIG9mIDNHUFAgd2hlbiBpdCBjb21lcyB0byBTSVAgc3RhbmRhcmRp emF0aW9uLiBPVE9ILCBkb2VzIHRoZSBhcHByb2FjaCB0YWtlbiBieSBSRkM1NTAyIGdvIGEgbGl0 dGxlIGJpdCB0b28gZmFyIGluIHRlcm1zIG9mIG92ZXItZGVmaW5pbmcgdGhlIGdlbmVyaWMgU0lQ IHRvb2xib3g/DQoNCkFuIGFsdGVybmF0aXZlIGNvdWxkIGJlIHRvIGRlZmluZSBhIGhlYWRlci9w YXJhbWV0ZXIgd2hpY2ggcmVmZXJzIHRvIGEg4oCcc2NlbmFyaW/igJ0gaW4gYW4gYWJzdHJhY3Qg d2F5ICh3aXRoIGEgZ2VuZXJpYyBzeW50YXgpIGFuZCBsZXQgb3RoZXIgc3RhbmRhcmRzIGZvcmEg ZGVmaW5lIHRoZSB2YWx1ZXMgdGhleSB3b3VsZCBsaWtlIHRvIHVzZSBhbmQvb3IgcmVseSBvbiBj b25maWd1cmF0aW9uIGFsaWdubWVudCBiZXR3ZWVuIHJlbGV2YW50IGVsZW1lbnRzLCBlLmcuIFMt Q1NDRi9IU1MvQVMuIENvbnNpZGVyaW5nIHdoZXJlIHdlIGFyZSByaWdodCBub3cgKHRoYXQgUkZD NTUwMiBpcyBhbHJlYWR5IHRoZXJlKSB0aGlzIGFwcHJvYWNoIHByYWN0aWNhbGx5IHdvdWxkIG1l YW4gdGhhdCBkcmFmdC1pZXRmLXNpcGNvcmUtb3JpZ2luYXRpbmctY2Rpdi1wYXJhbWV0ZXIgaXMg bm90IGRlZmluZWQgYW5kIFAtU2VydmVkLVVzZXIgc2VydmVkLXVzZXItcGFybSBpcyBleHRlbmRl ZCBieSBvdGhlcnMgYXMgbmVlZGVkIChhcyBpdCBhbGxvd3MgdGhhdCkuDQoNCk90aGVyd2lzZSwg dGhlcmUgd291bGQvY291bGQgYmUgdGhlIG5lZWQgdG8ga2VlcCBhZGRpbmcgbmV3IHZhbHVlcyBp biBkaWZmZXJlbnQgSUVURiBzcGVjaWZpY2F0aW9ucyB0aGUgbW9yZSDigJxkZXBsb3ltZW50IG1v ZGVsIHNwZWNpZmljIHVzZSBjYXNlc+KAnSBhcmUgbmVlZGVkL2Rpc2NvdmVyZWQvaW52ZW50ZWQu DQoNClRoYW5rcywNClRvbGdhDQpGcm9tOiBBc3ZlcmVuLCBUb2xnYSANClNlbnQ6IFRodXJzZGF5 LCBNYXJjaCAxNSwgMjAxOCA0OjIzIFBNDQpUbzogc2lwY29yZUBpZXRmLm9yZw0KU3ViamVjdDog V0dMQzogZHJhZnQtaWV0Zi1zaXBjb3JlLW9yaWdpbmF0aW5nLWNkaXYtcGFyYW1ldGVyDQoNCkkg cmV2aWV3ZWQgdGhlIGRyYWZ0IGFuZCBoYXZlIG5vIHRlY2huaWNhbCBpc3N1ZXMgd2l0aCBpdCBl eGNlcHQgb25lIHF1ZXN0aW9uOg0KDQpJcyBpdCBlbnZpc2lvbmVkIHRoYXQgdGhlcmUgd291bGQv Y291bGQgYmUgYSBuZWVkIGZvciB0ZXJtLWNkaXYgYXMgd2VsbCB0byB0cmlnZ2VyIGEgZGlmZmVy ZW50IHNlcnZpY2Ugc2V0IGlmIHRoZSB0YXJnZXQgaXMgZGV0ZXJtaW5lZCBhZnRlciBkaXZlcnNp b24/IEl0IG1heSBiZSBiZXR0ZXIgdG8gZGVmaW5lIGl0IG5vdyByYXRoZXIgdGhhbiBoYXZpbmcg eWV0IGFub3RoZXIgZHJhZnQsIGF0IGxlYXN0IHRvIGJlIGZ1dHVyZSBwcm9vZi4NCg0KVGhhbmtz LA0KVG9sZ2ENCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2 ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVn aWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBj b3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFy IGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVp cmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1 ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUg cmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFs c2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRh aW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJv dGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNv cGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1h aWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVz c2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5n ZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hh bmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KCg== From nobody Fri Mar 16 05:25:17 2018 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 77B6F127909 for ; Fri, 16 Mar 2018 05:25:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.11 X-Spam-Level: X-Spam-Status: No, score=-4.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, 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_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 4TvsBkYCEchH for ; Fri, 16 Mar 2018 05:25:12 -0700 (PDT) Received: from us-smtp-delivery-181.mimecast.com (us-smtp-delivery-181.mimecast.com [63.128.21.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2ABE4127867 for ; Fri, 16 Mar 2018 05:25:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-rbbn-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=2d3LMzWIWvTRmGzAAV+UNa3iWvWKSIUBJfW10BSRLs4=; b=FPfHOsOdUDiREHguKlrpGJ4PX6WZ069o8VhSmuA/oDqCMKvTVsqAJJxHfkrQsobibnt2KCZp5pJ0+GmUgMmI1obeUTiZmdz/SHNi2xM8tEbCm/OtatCnEHQgq/RNfnrQ1xTPxA1yGE3WZVW6wowiLCHpVkEfy6pVaWQ0E1U1huU= Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03lp0048.outbound.protection.outlook.com [216.32.180.48]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-172-H-IFHbeyPCK9HFrCMesQTA-1; Fri, 16 Mar 2018 08:25:09 -0400 Received: from CY4PR03MB3160.namprd03.prod.outlook.com (10.171.245.165) by CY4PR03MB3157.namprd03.prod.outlook.com (10.171.245.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.567.14; Fri, 16 Mar 2018 12:25:08 +0000 Received: from CY4PR03MB3160.namprd03.prod.outlook.com ([fe80::34a3:3001:f444:3072]) by CY4PR03MB3160.namprd03.prod.outlook.com ([fe80::34a3:3001:f444:3072%13]) with mapi id 15.20.0588.016; Fri, 16 Mar 2018 12:25:07 +0000 From: "Asveren, Tolga" To: "marianne.mohali@orange.com" , "sipcore@ietf.org" Thread-Topic: WGLC: draft-ietf-sipcore-originating-cdiv-parameter Thread-Index: AdO8mvHNh2Fu7WwWT5iDJ4VxNB0YgwAP3GCgAArG/7AABt3bAA== Date: Fri, 16 Mar 2018 12:25:07 +0000 Message-ID: References: <24496_1521199612_5AABA9FC_24496_87_1_8B970F90C584EA4E97D5BAAC9172DBB81D70AC30@OPEXCLILMA4.corporate.adroot.infra.ftgroup> In-Reply-To: <24496_1521199612_5AABA9FC_24496_87_1_8B970F90C584EA4E97D5BAAC9172DBB81D70AC30@OPEXCLILMA4.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [73.29.251.142] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR03MB3157; 7:MB5jBzZsRK9DuCQAR+6vMfnvO18vc0YxeBQrIiB3J9aujAzVKCcIkOFD+/sN/CjjVcMC+Go/oaAAol1mxz8r+GXqB1xwQqe1kIPUvBiKvG7TKtiDOTpS4zaJE5/zCgUaSQgqKhXBolL8PJ+4S+t8G5ZviTu8DQpDXZF4W63u+Njyjg09gxYol50Kt0OnENgYu+G8+S+cAT+JKlBOc1J6WZvhWYjJSkbmfHCEdRKTFRAbK5Gbf8HQ8UzdmR6toJll; 20:xU7k1S01qk3fxTh8Mh+8vPMIIpYNpiyiKpJT+T4KLib9VZQQ0S085fh0dzEoCFQXeeaTdoe3FKVRHXl4iH/DQshbdi8iTzUl7j7sDSB0I8UomYI89kV4XkLVWodvXo5EfrUYRLq/AC2UKf+mVNfghoO+8tAzp8jbN0F52FIc3kw= x-ms-office365-filtering-correlation-id: fad8aeb3-c7c9-4afe-f525-08d58b38f487 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:CY4PR03MB3157; x-ms-traffictypediagnostic: CY4PR03MB3157: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(131327999870524)(259379197776797)(18271650672692)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(3231221)(944501244)(52105095)(93006095)(93001095)(6041310)(20161123564045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(6072148)(201708071742011); SRVR:CY4PR03MB3157; BCL:0; PCL:0; RULEID:; SRVR:CY4PR03MB3157; x-forefront-prvs: 0613912E23 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(366004)(376002)(346002)(39380400002)(39860400002)(199004)(189003)(57704003)(6246003)(74316002)(229853002)(5660300001)(110136005)(9686003)(3660700001)(316002)(9326002)(2950100002)(86362001)(3280700002)(5250100002)(66066001)(59450400001)(2501003)(55016002)(54896002)(6306002)(5890100001)(2906002)(3846002)(53936002)(76176011)(7736002)(6116002)(790700001)(6506007)(97736004)(53546011)(25786009)(7696005)(2900100001)(99286004)(105586002)(478600001)(236005)(186003)(26005)(102836004)(6436002)(19609705001)(8936002)(345774005)(33656002)(81166006)(81156014)(8676002)(14454004)(68736007)(106356001); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR03MB3157; H:CY4PR03MB3160.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-microsoft-antispam-message-info: 88+x3YoW0oWLAT2vj7i2OuUDNbRTK2PYXooUGRIAAUAU0qXa7885EAp0ht7UNP768lggayvw+D+epojHZBlQ2NrhGtblz8lYnLdLlZ5SeHlLzuqI41YV6ZA/kv2J92CUJTxYQ4jD3KVVYf/7YTI3IYSzP/ERxu67aLPMkqJ55IJUL/uU9JF9HpL3reHDpu8JLplW7vxOhPOdt7Ewv7pWUa75Tya0u28CtZ65VKl8b9EyINUkNIRg1zNqIwZCpGFXnWyQwuAR+NcfbmnYfgfEkWUV6a7sDEZt5z6fdGTjafCYeBGEM9REH6qCetfQHz0aQ0wYkNWAL5htJhvyENtdcQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: rbbn.com X-MS-Exchange-CrossTenant-Network-Message-Id: fad8aeb3-c7c9-4afe-f525-08d58b38f487 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Mar 2018 12:25:07.8679 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR03MB3157 X-MC-Unique: H-IFHbeyPCK9HFrCMesQTA-1 Content-Type: multipart/alternative; boundary="_000_CY4PR03MB3160F44A869C93785D832B47A5D70CY4PR03MB3160namp_" Archived-At: Subject: Re: [sipcore] WGLC: 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: Fri, 16 Mar 2018 12:25:16 -0000 --_000_CY4PR03MB3160F44A869C93785D832B47A5D70CY4PR03MB3160namp_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 SGkgTWFyaWFubmUsDQoNClRoYW5rIHlvdSBmb3IgdGhlIGRldGFpbGVkIGV4cGxhbmF0aW9uIG9m IHRoZSBzZXJ2aWNlLiBZZXMsIHRoYXQgaXMgc29tZXRoaW5nIHVzZWQgdG9kYXkuIEJ1dCBob3cg Y291bGQgd2Uga25vdyB0aGF0IHRoZXJlIHdvdWxkbuKAmXQgYmUgYW55IHNlcnZpY2VzIHdoaWNo IHdvdWxkIGJlIHRyaWdnZXJlZC9ub3QgdHJpZ2dlcmVkIG9uIHRoZSBkaXZlcnRpbmcgcGFydHkg YmFzZWQgb24gd2hldGhlciBpdCBpcyB0aGUgb3JpZ2luYWwgaW5pdGlhdG9yIG9mIHRoZSBjYWxs IG9yIGp1c3QgdGhlIGRpdmVydGVyPyBUaGF0IGl0IGlzIG5vdCBuZWVkZWQgdG9kYXkgLWJ5IGEg Y2VydGFpbiBkZXBsb3ltZW50IG1vZGVsLSwgb3IgdGhhdCB5b3UoYW5kIEkpIGFyZSBub3QgYXdh cmUgb2YgaXQgZG9lcyBub3QgbmVjZXNzYXJpbHkgbWVhbiBpdCB3b3VsZG7igJl0L2lzIGFscmVh ZHkgdXNlZCBzb21ld2hlcmUgaW4gdGhlIHVuaXZlcnNlIG9mIHJlYWwgdGltZSBzZXNzaW9ucy4N Cg0KVGhlIHNoaXAgZm9yIGEgbW9yZSBnZW5lcmljIGZyYW1ld29yayB0byBmYWNpbGl0YXRlIOKA nHNjZW5hcmlvIGJhc2VkIHNlcnZpY2UgaW52b2NhdGlvbi9pbnRlcmFjdGlvbuKAnSBtYXkgaGF2 ZSBzYWlsZWQgYnV0IGF0IGEgbWluaW11bSBJIHdvdWxkIHN1Z2dlc3QgYWRkaW5nIOKAnHRlcm0t Y2RpduKAnSBhcyB3ZWxsLg0KDQpUaGFua3MsDQpUb2xnYQ0KDQpGcm9tOiBtYXJpYW5uZS5tb2hh bGlAb3JhbmdlLmNvbSA8bWFyaWFubmUubW9oYWxpQG9yYW5nZS5jb20+DQpTZW50OiBGcmlkYXks IE1hcmNoIDE2LCAyMDE4IDc6MjcgQU0NClRvOiBBc3ZlcmVuLCBUb2xnYSA8dGFzdmVyZW5AcmJi bi5jb20+OyBzaXBjb3JlQGlldGYub3JnDQpTdWJqZWN0OiBSRTogV0dMQzogZHJhZnQtaWV0Zi1z aXBjb3JlLW9yaWdpbmF0aW5nLWNkaXYtcGFyYW1ldGVyDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpOT1RJQ0U6IFRoaXMgZW1haWwgd2FzIHJlY2VpdmVkIGZyb20gYW4gRVhU RVJOQUwgc2VuZGVyDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpIaSBUb2xn YSwNCg0KRmlyc3QsIHRoYW5rIHlvdSBmb3IgdGhlIHJldmlldyBvZiB0aGUgZHJhZnQuDQpUbyBh bnN3ZXIgdG8gdGhlIHF1ZXN0aW9uIGluIHlvdXIgZmlyc3QgZW1haWwsIG9uY2UgYSBkaXZlcnNp b24gaGFzIGJlZW4gcHJvY2Vzc2VkLCB0aGUgb3V0Z29pbmcgbGVnIHdpbGwgZ28gdG8gdGhlIGRp dmVyc2lvbiB0YXJnZXQgYnV0IGJlZm9yZSB0aGF0LCB0aGUgc2Vzc2lvbiBjYXNlIG9mIHRoZSBz ZXJ2ZWQtdXNlciBoYXMgYmVlbiBjaGFuZ2VkIHdpdGggdGhlIGZvbGxvd2luZyBxdWVzdGlvbnM6 IHdobyBpcyB0aGUgb3JpZ2luYXRpbmcgcGFydHk/IHRoZSBjYWxsZXIgb3IgdGhlIGRpdmVydGlu ZyB1c2VyPyBEb2VzIHByaXZhY3kgb2YgdGhlIGRpdmVydGluZyB1c2VyIGFwcGxpZXM/IGRvIHdl IG5lZWQgdG8gY2hlY2sgdGhlIGJhcnJpbmcgc2VydmljZSBvZiB0aGUgZGl2ZXJ0aW5nIHVzZXIg Zm9yIG91dGdvaW5nIGNhbGxzPyBPVE9ILCB0aGUgY2FsbGVyIHJlbWFpbiB0aGUgc2FtZSBhbmQg aXRzIG9yaWdpbmF0aW5nIHNlcnZpY2VzIHNob3VsZCBzdGlsbCBhcHBseS4gRm9yIHRoYXQgcGFy dGljdWxhciBzaXR1YXRpb24gc29tZXdoZXJlIGJldHdlZW4gdGVybWluYXRpbmcgYW5kIG9yaWdp bmF0aW5nLCB0aGUgZHJhZnQgcHJvcG9zZXMgdG8gZXh0ZW5kIHRoZSBQLVNlcnZlZC11c2VyLg0K QXQgdGhlIGRpdmVydGVkLXRvIHVzZXIgbGV2ZWwsIGl0IGlzIGRpZmZlcmVudDogSXQgbWF5IGlu ZGVlZCBiZSBwb3NzaWJsZSB0byB0cmlnZ2VyIGEgc3BlY2lmaWMgc2VydmljZSBmb3IgdGhlIHRl cm1pbmF0aW5nLWFmdGVyLWRpdmVyc2lvbiBidXQgdGhpcyBpcyBub3QgYSBuZXcgdHlwZSBzZXNz aW9uIGNhc2UuIEF0IHRoZSB0ZXJtaW5hdGluZyBzaWRlLCB0aGUgc2VydmVkIHVzZXIgcmVtYWlu cyB0aGUgdGVybWluYXRpbmcgdXNlciBhbmQgb25seSBpdHMgdGVybWluYXRpbmcgc2VydmljZXMg aGF2ZSB0byBiZSB0cmlnZ2VyZWQuIE9mIGNvdXJzZSwgdGVybWluYXRpbmcgc2VydmljZXMgYmFz ZWQgb24gdGhlIG9yaWdpbmF0aW5nIHBhcnR5IGlkZW50aXR5IGFyZSBhZmZlY3RlZCBieSB0aGUg Y2FsbCBkaXZlcnNpb24gc2luY2Ugd2UgY2FuIGRpc2N1c3Mgb24gd2hvIGlzIHRoZSBvcmlnaW5h dGluZyBwYXJ0eSBidXQgdGhpcyBpcyBtb3JlIGEgbWF0dGVyIG9mIHNlcnZpY2UgaW50ZXJhY3Rp b24uIFRoZSBzZXJ2ZWQtdXNlciBpcyB0aGUgZGl2ZXJzaW9uIHRhcmdldCBhbmQgdGhlIHNlc3Np b24gY2FzZSBpcyB0ZXJtaW5hdGluZyBhbmQgaXQgd2lsbCBub3QgY2hhbmdlIChleGNlcHQgaWYg dGhlcmUgaXMgYW5vdGhlciBjYWxsIGRpdmVyc2lvbiA7KS4gSnVzdCB0byBsZXQgeW91IGtub3cs IHRoZXJlIGlzIGEgc2VydmljZSB0byByZWplY3QgaW5jb21pbmcgZm9yd2FyZGVkIGNhbGxzIGFu ZCB0aGUgdHJpZ2dlciBmb3IgdGhpcyBzcGVjaWZpYyBraW5kIG9mIGJhcnJpbmcgaXMgdGhlIHBy ZXNlbmNlIG9mIGEgZGl2ZXJ0aW5nIHVzZXIgaWRlbnRpdHkgaW4gdGhlIGluY29taW5nIElOVklU RSByZXF1ZXN0LiBJdCBpcyBqdXN0IGEgY3JpdGVyaW9uIChhcyBmb3IgYWxsIGJhcnJpbmcgc2Vy dmljZXMpLg0KDQpBYm91dCB5b3VyIGNvbW1lbnQgb24gdGhlIHdheSBTSVAgaGVhZGVycyBhcmUg ZXh0ZW5kZWQsIElNTywgcnVsZXMgZm9yIHN0YW5kYXJkaXphdGlvbiBwcm9jZXNzIG9mIFNJUCBh cmUgaGVyZSBmb3IgeWVhcnMgYW5kIGl0IGlzIG5vdCB0aGUgZ29vZCB0aW1lIHRvIGNoYW5nZSB0 aGF0LiBUbyBiZSB0cmFuc3BhcmVudCwgdGhpcyBleHRlbnNpb24gd2FzIGZpcnN0IGRlZmluZWQg b25seSB3aXRoaW4gM0dQUCBzcGVjaWZpY2F0aW9uIGJlY2F1c2UgdGhlcmUgd2FzIGEgc2Vydmlj ZSBuZWVkIGJlaGluZC4gQmVjYXVzZSBpdCB3YXMgYW4gZXh0ZW5zaW9uIG9mIGFuIFJGQyBhbmQg dGhlIHdhcyB0aGUgc3ludGF4IG9mIHRoZSBoZWFkZXIgaXMgZGVzaWduZWQsIHRoZSBleHRlbnNp b24gaXMgdG8gYmUgZG9uZSBpbiBJRVRGLiBXZSBjYW4gZGlzY3VzcyB0aGF0IGJ1dCB3ZSBhcmUg YXQgdGhlIGVuZCBvZiBTSVAgcHJvdG9jb2wgZXh0ZW5zaW9uIHByb2Nlc3MuLi4NCkZpbmFsbHks IFJGQzU1MDIgZGVmaW5lcyBhIOKAnHByaXZhdGXigJ0gKFAtICkgaGVhZGVyIHNvIGl0IGlzIG5v dCBzdXJwcmlzaW5nIHRoYXQgaXRzIGV4dGVuc2lvbiBhcyBhIDNHUFAgZmxhdm9yIOKYug0KDQpC ZXN0IHJlZ2FyZHMsDQpNYXJpYW5uZQ0KDQoNCkRlIDogc2lwY29yZSBbbWFpbHRvOnNpcGNvcmUt Ym91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBBc3ZlcmVuLCBUb2xnYQ0KRW52b3nDqSA6 IHZlbmRyZWRpIDE2IG1hcnMgMjAxOCAwOTowNg0Kw4AgOiBzaXBjb3JlQGlldGYub3JnPG1haWx0 bzpzaXBjb3JlQGlldGYub3JnPg0KT2JqZXQgOiBSZTogW3NpcGNvcmVdIFdHTEM6IGRyYWZ0LWll dGYtc2lwY29yZS1vcmlnaW5hdGluZy1jZGl2LXBhcmFtZXRlcg0KDQpTb21lIG1vcmUgbXVzaW5n cyBmcm9tIGNvbmNlcHR1YWwgcGVyc3BlY3RpdmU6DQoNClNJUCBwcm92aWRlcyBhIHRvb2xib3gg dG8gcHJvdmlkZSBzZXJ2aWNlcy4gQW5kIHllcywgdGhlcmUgaXMgc29tZSBzcGVjaWFsIChpZiBJ IG1heSBzYXkg4oCcZmF2b3JlZOKAnSkgc3RhdHVzIG9mIDNHUFAgd2hlbiBpdCBjb21lcyB0byBT SVAgc3RhbmRhcmRpemF0aW9uLiBPVE9ILCBkb2VzIHRoZSBhcHByb2FjaCB0YWtlbiBieSBSRkM1 NTAyIGdvIGEgbGl0dGxlIGJpdCB0b28gZmFyIGluIHRlcm1zIG9mIG92ZXItZGVmaW5pbmcgdGhl IGdlbmVyaWMgU0lQIHRvb2xib3g/DQoNCkFuIGFsdGVybmF0aXZlIGNvdWxkIGJlIHRvIGRlZmlu ZSBhIGhlYWRlci9wYXJhbWV0ZXIgd2hpY2ggcmVmZXJzIHRvIGEg4oCcc2NlbmFyaW/igJ0gaW4g YW4gYWJzdHJhY3Qgd2F5ICh3aXRoIGEgZ2VuZXJpYyBzeW50YXgpIGFuZCBsZXQgb3RoZXIgc3Rh bmRhcmRzIGZvcmEgZGVmaW5lIHRoZSB2YWx1ZXMgdGhleSB3b3VsZCBsaWtlIHRvIHVzZSBhbmQv b3IgcmVseSBvbiBjb25maWd1cmF0aW9uIGFsaWdubWVudCBiZXR3ZWVuIHJlbGV2YW50IGVsZW1l bnRzLCBlLmcuIFMtQ1NDRi9IU1MvQVMuIENvbnNpZGVyaW5nIHdoZXJlIHdlIGFyZSByaWdodCBu b3cgKHRoYXQgUkZDNTUwMiBpcyBhbHJlYWR5IHRoZXJlKSB0aGlzIGFwcHJvYWNoIHByYWN0aWNh bGx5IHdvdWxkIG1lYW4gdGhhdCBkcmFmdC1pZXRmLXNpcGNvcmUtb3JpZ2luYXRpbmctY2Rpdi1w YXJhbWV0ZXIgaXMgbm90IGRlZmluZWQgYW5kIFAtU2VydmVkLVVzZXIgc2VydmVkLXVzZXItcGFy bSBpcyBleHRlbmRlZCBieSBvdGhlcnMgYXMgbmVlZGVkIChhcyBpdCBhbGxvd3MgdGhhdCkuDQoN Ck90aGVyd2lzZSwgdGhlcmUgd291bGQvY291bGQgYmUgdGhlIG5lZWQgdG8ga2VlcCBhZGRpbmcg bmV3IHZhbHVlcyBpbiBkaWZmZXJlbnQgSUVURiBzcGVjaWZpY2F0aW9ucyB0aGUgbW9yZSDigJxk ZXBsb3ltZW50IG1vZGVsIHNwZWNpZmljIHVzZSBjYXNlc+KAnSBhcmUgbmVlZGVkL2Rpc2NvdmVy ZWQvaW52ZW50ZWQuDQoNClRoYW5rcywNClRvbGdhDQpGcm9tOiBBc3ZlcmVuLCBUb2xnYQ0KU2Vu dDogVGh1cnNkYXksIE1hcmNoIDE1LCAyMDE4IDQ6MjMgUE0NClRvOiBzaXBjb3JlQGlldGYub3Jn PG1haWx0bzpzaXBjb3JlQGlldGYub3JnPg0KU3ViamVjdDogV0dMQzogZHJhZnQtaWV0Zi1zaXBj b3JlLW9yaWdpbmF0aW5nLWNkaXYtcGFyYW1ldGVyDQoNCkkgcmV2aWV3ZWQgdGhlIGRyYWZ0IGFu ZCBoYXZlIG5vIHRlY2huaWNhbCBpc3N1ZXMgd2l0aCBpdCBleGNlcHQgb25lIHF1ZXN0aW9uOg0K DQpJcyBpdCBlbnZpc2lvbmVkIHRoYXQgdGhlcmUgd291bGQvY291bGQgYmUgYSBuZWVkIGZvciB0 ZXJtLWNkaXYgYXMgd2VsbCB0byB0cmlnZ2VyIGEgZGlmZmVyZW50IHNlcnZpY2Ugc2V0IGlmIHRo ZSB0YXJnZXQgaXMgZGV0ZXJtaW5lZCBhZnRlciBkaXZlcnNpb24/IEl0IG1heSBiZSBiZXR0ZXIg dG8gZGVmaW5lIGl0IG5vdyByYXRoZXIgdGhhbiBoYXZpbmcgeWV0IGFub3RoZXIgZHJhZnQsIGF0 IGxlYXN0IHRvIGJlIGZ1dHVyZSBwcm9vZi4NCg0KVGhhbmtzLA0KVG9sZ2ENCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K DQpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBp bmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50 IGRvbmMNCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jp c2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6 IGxlIHNpZ25hbGVyDQphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVz IHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0 aWJsZXMgZCdhbHRlcmF0aW9uLA0KT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUg c2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0K DQpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRp YWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3 Ow0KdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0 IGF1dGhvcmlzYXRpb24uDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9y LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0 cyBhdHRhY2htZW50cy4NCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBs aWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZh bHNpZmllZC4NClRoYW5rIHlvdS4NCg0K --_000_CY4PR03MB3160F44A869C93785D832B47A5D70CY4PR03MB3160namp_ Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlNlZ29lIFVJ IEVtb2ppIjsNCglwYW5vc2UtMToyIDExIDUgMiA0IDIgNCAyIDIgMzt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBl cmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1h bDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRv Ow0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFy Z2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2lu ZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDEx LjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9u MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwv eG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQg djpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hh cGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIg bGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgTWFyaWFubmUsPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlRoYW5rIHlvdSBmb3IgdGhlIGRldGFpbGVkIGV4cGxhbmF0aW9uIG9mIHRoZSBzZXJ2aWNlLiBZ ZXMsIHRoYXQgaXMgc29tZXRoaW5nIHVzZWQgdG9kYXkuIEJ1dCBob3cgY291bGQgd2Uga25vdyB0 aGF0IHRoZXJlIHdvdWxkbuKAmXQgYmUgYW55IHNlcnZpY2VzIHdoaWNoIHdvdWxkIGJlIHRyaWdn ZXJlZC9ub3QgdHJpZ2dlcmVkIG9uIHRoZSBkaXZlcnRpbmcgcGFydHkgYmFzZWQgb24gd2hldGhl ciBpdCBpcyB0aGUNCiBvcmlnaW5hbCBpbml0aWF0b3Igb2YgdGhlIGNhbGwgb3IganVzdCB0aGUg ZGl2ZXJ0ZXI/IFRoYXQgaXQgaXMgbm90IG5lZWRlZCB0b2RheSAtYnkgYSBjZXJ0YWluIGRlcGxv eW1lbnQgbW9kZWwtLCBvciB0aGF0IHlvdShhbmQgSSkgYXJlIG5vdCBhd2FyZSBvZiBpdCBkb2Vz IG5vdCBuZWNlc3NhcmlseSBtZWFuIGl0IHdvdWxkbuKAmXQvaXMgYWxyZWFkeSB1c2VkIHNvbWV3 aGVyZSBpbiB0aGUgdW5pdmVyc2Ugb2YgcmVhbCB0aW1lIHNlc3Npb25zLg0KPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlRoZSBzaGlwIGZvciBhIG1vcmUgZ2VuZXJpYyBmcmFtZXdvcmsgdG8gZmFj aWxpdGF0ZSDigJxzY2VuYXJpbyBiYXNlZCBzZXJ2aWNlIGludm9jYXRpb24vaW50ZXJhY3Rpb27i gJ0gbWF5IGhhdmUgc2FpbGVkIGJ1dCBhdCBhIG1pbmltdW0gSSB3b3VsZCBzdWdnZXN0IGFkZGlu ZyDigJx0ZXJtLWNkaXbigJ0gYXMgd2VsbC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtz LDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VG9sZ2E8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRk aW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9i PiBtYXJpYW5uZS5tb2hhbGlAb3JhbmdlLmNvbSAmbHQ7bWFyaWFubmUubW9oYWxpQG9yYW5nZS5j b20mZ3Q7DQo8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBNYXJjaCAxNiwgMjAxOCA3OjI3IEFN PGJyPg0KPGI+VG86PC9iPiBBc3ZlcmVuLCBUb2xnYSAmbHQ7dGFzdmVyZW5AcmJibi5jb20mZ3Q7 OyBzaXBjb3JlQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBXR0xDOiBkcmFmdC1p ZXRmLXNpcGNvcmUtb3JpZ2luYXRpbmctY2Rpdi1wYXJhbWV0ZXI8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246 Y2VudGVyIj4NCjxociBzaXplPSIyIiB3aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5PVElDRTogVGhpcyBlbWFpbCB3YXMgcmVjZWl2ZWQg ZnJvbSBhbiBFWFRFUk5BTCBzZW5kZXI8bzpwPjwvbzpwPjwvcD4NCjxkaXYgY2xhc3M9Ik1zb05v cm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj4NCjxociBzaXpl PSIyIiB3aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KSGkgVG9sZ2EsPGJyPg0K PGJyPg0KRmlyc3QsIHRoYW5rIHlvdSBmb3IgdGhlIHJldmlldyBvZiB0aGUgZHJhZnQuPGJyPg0K VG8gYW5zd2VyIHRvIHRoZSBxdWVzdGlvbiBpbiB5b3VyIGZpcnN0IGVtYWlsLCBvbmNlIGEgZGl2 ZXJzaW9uIGhhcyBiZWVuIHByb2Nlc3NlZCwgdGhlIG91dGdvaW5nIGxlZyB3aWxsIGdvIHRvIHRo ZSBkaXZlcnNpb24gdGFyZ2V0IGJ1dCBiZWZvcmUgdGhhdCwgdGhlIHNlc3Npb24gY2FzZSBvZiB0 aGUgc2VydmVkLXVzZXIgaGFzIGJlZW4gY2hhbmdlZCB3aXRoIHRoZSBmb2xsb3dpbmcgcXVlc3Rp b25zOiB3aG8gaXMgdGhlIG9yaWdpbmF0aW5nIHBhcnR5Pw0KIHRoZSBjYWxsZXIgb3IgdGhlIGRp dmVydGluZyB1c2VyPyBEb2VzIHByaXZhY3kgb2YgdGhlIGRpdmVydGluZyB1c2VyIGFwcGxpZXM/ IGRvIHdlIG5lZWQgdG8gY2hlY2sgdGhlIGJhcnJpbmcgc2VydmljZSBvZiB0aGUgZGl2ZXJ0aW5n IHVzZXIgZm9yIG91dGdvaW5nIGNhbGxzPyBPVE9ILCB0aGUgY2FsbGVyIHJlbWFpbiB0aGUgc2Ft ZSBhbmQgaXRzIG9yaWdpbmF0aW5nIHNlcnZpY2VzIHNob3VsZCBzdGlsbCBhcHBseS4gRm9yIHRo YXQgcGFydGljdWxhcg0KIHNpdHVhdGlvbiBzb21ld2hlcmUgYmV0d2VlbiB0ZXJtaW5hdGluZyBh bmQgb3JpZ2luYXRpbmcsIHRoZSBkcmFmdCBwcm9wb3NlcyB0byBleHRlbmQgdGhlIFAtU2VydmVk LXVzZXIuDQo8YnI+DQpBdCB0aGUgZGl2ZXJ0ZWQtdG8gdXNlciBsZXZlbCwgaXQgaXMgZGlmZmVy ZW50OiBJdCBtYXkgaW5kZWVkIGJlIHBvc3NpYmxlIHRvIHRyaWdnZXIgYSBzcGVjaWZpYyBzZXJ2 aWNlIGZvciB0aGUgdGVybWluYXRpbmctYWZ0ZXItZGl2ZXJzaW9uIGJ1dCB0aGlzIGlzIG5vdCBh IG5ldyB0eXBlIHNlc3Npb24gY2FzZS4gQXQgdGhlIHRlcm1pbmF0aW5nIHNpZGUsIHRoZSBzZXJ2 ZWQgdXNlciByZW1haW5zIHRoZSB0ZXJtaW5hdGluZyB1c2VyIGFuZCBvbmx5DQogaXRzIHRlcm1p bmF0aW5nIHNlcnZpY2VzIGhhdmUgdG8gYmUgdHJpZ2dlcmVkLiBPZiBjb3Vyc2UsIHRlcm1pbmF0 aW5nIHNlcnZpY2VzIGJhc2VkIG9uIHRoZSBvcmlnaW5hdGluZyBwYXJ0eSBpZGVudGl0eSBhcmUg YWZmZWN0ZWQgYnkgdGhlIGNhbGwgZGl2ZXJzaW9uIHNpbmNlIHdlIGNhbiBkaXNjdXNzIG9uIHdo byBpcyB0aGUgb3JpZ2luYXRpbmcgcGFydHkgYnV0IHRoaXMgaXMgbW9yZSBhIG1hdHRlciBvZiBz ZXJ2aWNlIGludGVyYWN0aW9uLg0KIFRoZSBzZXJ2ZWQtdXNlciBpcyB0aGUgZGl2ZXJzaW9uIHRh cmdldCBhbmQgdGhlIHNlc3Npb24gY2FzZSBpcyB0ZXJtaW5hdGluZyBhbmQgaXQgd2lsbCBub3Qg Y2hhbmdlIChleGNlcHQgaWYgdGhlcmUgaXMgYW5vdGhlciBjYWxsIGRpdmVyc2lvbiA7KS4gSnVz dCB0byBsZXQgeW91IGtub3csIHRoZXJlIGlzIGEgc2VydmljZSB0byByZWplY3QgaW5jb21pbmcg Zm9yd2FyZGVkIGNhbGxzIGFuZCB0aGUgdHJpZ2dlciBmb3IgdGhpcyBzcGVjaWZpYw0KIGtpbmQg b2YgYmFycmluZyBpcyB0aGUgcHJlc2VuY2Ugb2YgYSBkaXZlcnRpbmcgdXNlciBpZGVudGl0eSBp biB0aGUgaW5jb21pbmcgSU5WSVRFIHJlcXVlc3QuIEl0IGlzIGp1c3QgYSBjcml0ZXJpb24gKGFz IGZvciBhbGwgYmFycmluZyBzZXJ2aWNlcykuDQo8YnI+DQo8YnI+DQpBYm91dCB5b3VyIGNvbW1l bnQgb24gdGhlIHdheSBTSVAgaGVhZGVycyBhcmUgZXh0ZW5kZWQsIElNTywgcnVsZXMgZm9yIHN0 YW5kYXJkaXphdGlvbiBwcm9jZXNzIG9mIFNJUCBhcmUgaGVyZSBmb3IgeWVhcnMgYW5kIGl0IGlz IG5vdCB0aGUgZ29vZCB0aW1lIHRvIGNoYW5nZSB0aGF0LiBUbyBiZSB0cmFuc3BhcmVudCwgdGhp cyBleHRlbnNpb24gd2FzIGZpcnN0IGRlZmluZWQgb25seSB3aXRoaW4gM0dQUCBzcGVjaWZpY2F0 aW9uIGJlY2F1c2UgdGhlcmUNCiB3YXMgYSBzZXJ2aWNlIG5lZWQgYmVoaW5kLiBCZWNhdXNlIGl0 IHdhcyBhbiBleHRlbnNpb24gb2YgYW4gUkZDIGFuZCB0aGUgd2FzIHRoZSBzeW50YXggb2YgdGhl IGhlYWRlciBpcyBkZXNpZ25lZCwgdGhlIGV4dGVuc2lvbiBpcyB0byBiZSBkb25lIGluIElFVEYu IFdlIGNhbiBkaXNjdXNzIHRoYXQgYnV0IHdlIGFyZSBhdCB0aGUgZW5kIG9mIFNJUCBwcm90b2Nv bCBleHRlbnNpb24gcHJvY2Vzcy4uLjxicj4NCkZpbmFsbHksIFJGQzU1MDIgZGVmaW5lcyBhIOKA nHByaXZhdGXigJ0gKFAtICkgaGVhZGVyIHNvIGl0IGlzIG5vdCBzdXJwcmlzaW5nIHRoYXQgaXRz IGV4dGVuc2lvbiBhcyBhIDNHUFAgZmxhdm9yDQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7U2Vnb2UgVUkgRW1vamkmcXVvdDssc2Fucy1zZXJpZiI+4pi6PC9zcGFuPjxicj4NCjxicj4N CkJlc3QgcmVnYXJkcyw8YnI+DQpNYXJpYW5uZTxicj4NCjxicj4NCjxicj4NCkRlJm5ic3A7OiBz aXBjb3JlIFs8YSBocmVmPSJtYWlsdG86c2lwY29yZS1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86 c2lwY29yZS1ib3VuY2VzQGlldGYub3JnPC9hPl0gRGUgbGEgcGFydCBkZSBBc3ZlcmVuLCBUb2xn YTxicj4NCkVudm95w6kmbmJzcDs6IHZlbmRyZWRpIDE2IG1hcnMgMjAxOCAwOTowNjxicj4NCsOA Jm5ic3A7OiA8YSBocmVmPSJtYWlsdG86c2lwY29yZUBpZXRmLm9yZyI+c2lwY29yZUBpZXRmLm9y ZzwvYT48YnI+DQpPYmpldCZuYnNwOzogUmU6IFtzaXBjb3JlXSBXR0xDOiBkcmFmdC1pZXRmLXNp cGNvcmUtb3JpZ2luYXRpbmctY2Rpdi1wYXJhbWV0ZXI8YnI+DQo8YnI+DQpTb21lIG1vcmUgbXVz aW5ncyBmcm9tIGNvbmNlcHR1YWwgcGVyc3BlY3RpdmU6PGJyPg0KPGJyPg0KU0lQIHByb3ZpZGVz IGEgdG9vbGJveCB0byBwcm92aWRlIHNlcnZpY2VzLiBBbmQgeWVzLCB0aGVyZSBpcyBzb21lIHNw ZWNpYWwgKGlmIEkgbWF5IHNheSDigJxmYXZvcmVk4oCdKSBzdGF0dXMgb2YgM0dQUCB3aGVuIGl0 IGNvbWVzIHRvIFNJUCBzdGFuZGFyZGl6YXRpb24uIE9UT0gsIGRvZXMgdGhlIGFwcHJvYWNoIHRh a2VuIGJ5IFJGQzU1MDIgZ28gYSBsaXR0bGUgYml0IHRvbyBmYXIgaW4gdGVybXMgb2Ygb3Zlci1k ZWZpbmluZyB0aGUgZ2VuZXJpYyBTSVANCiB0b29sYm94Pzxicj4NCjxicj4NCkFuIGFsdGVybmF0 aXZlIGNvdWxkIGJlIHRvIGRlZmluZSBhIGhlYWRlci9wYXJhbWV0ZXIgd2hpY2ggcmVmZXJzIHRv IGEg4oCcc2NlbmFyaW/igJ0gaW4gYW4gYWJzdHJhY3Qgd2F5ICh3aXRoIGEgZ2VuZXJpYyBzeW50 YXgpIGFuZCBsZXQgb3RoZXIgc3RhbmRhcmRzIGZvcmEgZGVmaW5lIHRoZSB2YWx1ZXMgdGhleSB3 b3VsZCBsaWtlIHRvIHVzZSBhbmQvb3IgcmVseSBvbiBjb25maWd1cmF0aW9uIGFsaWdubWVudCBi ZXR3ZWVuIHJlbGV2YW50IGVsZW1lbnRzLA0KIGUuZy4gUy1DU0NGL0hTUy9BUy4gQ29uc2lkZXJp bmcgd2hlcmUgd2UgYXJlIHJpZ2h0IG5vdyAodGhhdCBSRkM1NTAyIGlzIGFscmVhZHkgdGhlcmUp IHRoaXMgYXBwcm9hY2ggcHJhY3RpY2FsbHkgd291bGQgbWVhbiB0aGF0IGRyYWZ0LWlldGYtc2lw Y29yZS1vcmlnaW5hdGluZy1jZGl2LXBhcmFtZXRlciBpcyBub3QgZGVmaW5lZCBhbmQgUC1TZXJ2 ZWQtVXNlciBzZXJ2ZWQtdXNlci1wYXJtIGlzIGV4dGVuZGVkIGJ5IG90aGVycyBhcyBuZWVkZWQN CiAoYXMgaXQgYWxsb3dzIHRoYXQpLjxicj4NCjxicj4NCk90aGVyd2lzZSwgdGhlcmUgd291bGQv Y291bGQgYmUgdGhlIG5lZWQgdG8ga2VlcCBhZGRpbmcgbmV3IHZhbHVlcyBpbiBkaWZmZXJlbnQg SUVURiBzcGVjaWZpY2F0aW9ucyB0aGUgbW9yZSDigJxkZXBsb3ltZW50IG1vZGVsIHNwZWNpZmlj IHVzZSBjYXNlc+KAnSBhcmUgbmVlZGVkL2Rpc2NvdmVyZWQvaW52ZW50ZWQuPGJyPg0KPGJyPg0K VGhhbmtzLDxicj4NClRvbGdhPGJyPg0KRnJvbTogQXN2ZXJlbiwgVG9sZ2EgPGJyPg0KU2VudDog VGh1cnNkYXksIE1hcmNoIDE1LCAyMDE4IDQ6MjMgUE08YnI+DQpUbzogPGEgaHJlZj0ibWFpbHRv OnNpcGNvcmVAaWV0Zi5vcmciPnNpcGNvcmVAaWV0Zi5vcmc8L2E+PGJyPg0KU3ViamVjdDogV0dM QzogZHJhZnQtaWV0Zi1zaXBjb3JlLW9yaWdpbmF0aW5nLWNkaXYtcGFyYW1ldGVyPGJyPg0KPGJy Pg0KSSByZXZpZXdlZCB0aGUgZHJhZnQgYW5kIGhhdmUgbm8gdGVjaG5pY2FsIGlzc3VlcyB3aXRo IGl0IGV4Y2VwdCBvbmUgcXVlc3Rpb246PGJyPg0KPGJyPg0KSXMgaXQgZW52aXNpb25lZCB0aGF0 IHRoZXJlIHdvdWxkL2NvdWxkIGJlIGEgbmVlZCBmb3IgdGVybS1jZGl2IGFzIHdlbGwgdG8gdHJp Z2dlciBhIGRpZmZlcmVudCBzZXJ2aWNlIHNldCBpZiB0aGUgdGFyZ2V0IGlzIGRldGVybWluZWQg YWZ0ZXIgZGl2ZXJzaW9uPyBJdCBtYXkgYmUgYmV0dGVyIHRvIGRlZmluZSBpdCBub3cgcmF0aGVy IHRoYW4gaGF2aW5nIHlldCBhbm90aGVyIGRyYWZ0LCBhdCBsZWFzdCB0byBiZSBmdXR1cmUgcHJv b2YuPGJyPg0KPGJyPg0KVGhhbmtzLDxicj4NClRvbGdhPGJyPg0KPGJyPg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4N Cjxicj4NCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIg ZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRv aXZlbnQgZG9uYzxicj4NCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNh bnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIs IHZldWlsbGV6IGxlIHNpZ25hbGVyPGJyPg0KYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUg YWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMg ZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiw8YnI+DQpPcmFuZ2UgZGVjbGluZSB0b3V0 ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBm YWxzaWZpZS4gTWVyY2kuPGJyPg0KPGJyPg0KVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVu dHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhh dCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzs8YnI+DQp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJp YnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi48YnI+DQpJZiB5b3Ug aGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5k ZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy48YnI+DQpBcyBl bWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0 aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuPGJyPg0KVGhhbmsg eW91Ljxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_CY4PR03MB3160F44A869C93785D832B47A5D70CY4PR03MB3160namp_-- From nobody Fri Mar 16 07:18:33 2018 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 03CCF127286 for ; Fri, 16 Mar 2018 07:18:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.629 X-Spam-Level: X-Spam-Status: No, score=-2.629 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, T_RP_MATCHES_RCVD=-0.01, 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 AEAdKnDubaRj for ; Fri, 16 Mar 2018 07:18:29 -0700 (PDT) Received: from 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 5FE8A126B6E for ; Fri, 16 Mar 2018 07:18:29 -0700 (PDT) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id AF38D408E5; Fri, 16 Mar 2018 15:18:27 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.13]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id 8DDB31A0059; Fri, 16 Mar 2018 15:18:27 +0100 (CET) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM6D.corporate.adroot.infra.ftgroup ([fe80::54f9:a6c3:c013:cbc7%19]) with mapi id 14.03.0382.000; Fri, 16 Mar 2018 15:18:27 +0100 From: To: "Asveren, Tolga" , "sipcore@ietf.org" Thread-Topic: WGLC: draft-ietf-sipcore-originating-cdiv-parameter Thread-Index: AdO8mvHNh2Fu7WwWT5iDJ4VxNB0YgwAP3GCgAArG/7AABt3bAAADWXtw Date: Fri, 16 Mar 2018 14:18:26 +0000 Message-ID: <11272_1521209907_5AABD233_11272_147_2_8B970F90C584EA4E97D5BAAC9172DBB81D70B5E7@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: <24496_1521199612_5AABA9FC_24496_87_1_8B970F90C584EA4E97D5BAAC9172DBB81D70AC30@OPEXCLILMA4.corporate.adroot.infra.ftgroup> 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.6] Content-Type: multipart/alternative; boundary="_000_8B970F90C584EA4E97D5BAAC9172DBB81D70B5E7OPEXCLILMA4corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [sipcore] WGLC: 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: Fri, 16 Mar 2018 14:18:32 -0000 --_000_8B970F90C584EA4E97D5BAAC9172DBB81D70B5E7OPEXCLILMA4corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SXQgaXMgdHJ1ZSB0aGF0IHdlIGNvdWxkIGNvbnNpZGVyIHRoaXMg4oCcdGVybS1jZGl24oCdIGNh c2UgaW4gdGhlIEktRCB0byBoYXZlIGEgc3ltbWV0cmljIHZhbHVlIGV2ZW4gaWYgZm9yIG5vdyBu byDigJxuZWVk4oCdIGhhcyBiZWVuIGlkZW50aWZpZWQuDQpJIGNhbiB3b3JrIG9uIHRoaXMgYWRk aW5nIHRvIHRoZSBJLUQuDQoNCkFueSBvdGhlciB2aWV3cyBvbiBpbnRyb2R1Y2luZyB0aGUgc2Vz c2lvbiBjYXNlIOKAnHRlcm0tY2RpduKAnSB0b28/DQoNCkJSLA0KTWFyaWFubmUNCg0KRGUgOiBB c3ZlcmVuLCBUb2xnYSBbbWFpbHRvOnRhc3ZlcmVuQHJiYm4uY29tXQ0KRW52b3nDqSA6IHZlbmRy ZWRpIDE2IG1hcnMgMjAxOCAxMzoyNQ0Kw4AgOiBNT0hBTEkgTWFyaWFubmUgSU1UL09MTjsgc2lw Y29yZUBpZXRmLm9yZw0KT2JqZXQgOiBSRTogV0dMQzogZHJhZnQtaWV0Zi1zaXBjb3JlLW9yaWdp bmF0aW5nLWNkaXYtcGFyYW1ldGVyDQoNCkhpIE1hcmlhbm5lLA0KDQpUaGFuayB5b3UgZm9yIHRo ZSBkZXRhaWxlZCBleHBsYW5hdGlvbiBvZiB0aGUgc2VydmljZS4gWWVzLCB0aGF0IGlzIHNvbWV0 aGluZyB1c2VkIHRvZGF5LiBCdXQgaG93IGNvdWxkIHdlIGtub3cgdGhhdCB0aGVyZSB3b3VsZG7i gJl0IGJlIGFueSBzZXJ2aWNlcyB3aGljaCB3b3VsZCBiZSB0cmlnZ2VyZWQvbm90IHRyaWdnZXJl ZCBvbiB0aGUgZGl2ZXJ0aW5nIHBhcnR5IGJhc2VkIG9uIHdoZXRoZXIgaXQgaXMgdGhlIG9yaWdp bmFsIGluaXRpYXRvciBvZiB0aGUgY2FsbCBvciBqdXN0IHRoZSBkaXZlcnRlcj8gVGhhdCBpdCBp cyBub3QgbmVlZGVkIHRvZGF5IC1ieSBhIGNlcnRhaW4gZGVwbG95bWVudCBtb2RlbC0sIG9yIHRo YXQgeW91KGFuZCBJKSBhcmUgbm90IGF3YXJlIG9mIGl0IGRvZXMgbm90IG5lY2Vzc2FyaWx5IG1l YW4gaXQgd291bGRu4oCZdC9pcyBhbHJlYWR5IHVzZWQgc29tZXdoZXJlIGluIHRoZSB1bml2ZXJz ZSBvZiByZWFsIHRpbWUgc2Vzc2lvbnMuDQoNClRoZSBzaGlwIGZvciBhIG1vcmUgZ2VuZXJpYyBm cmFtZXdvcmsgdG8gZmFjaWxpdGF0ZSDigJxzY2VuYXJpbyBiYXNlZCBzZXJ2aWNlIGludm9jYXRp b24vaW50ZXJhY3Rpb27igJ0gbWF5IGhhdmUgc2FpbGVkIGJ1dCBhdCBhIG1pbmltdW0gSSB3b3Vs ZCBzdWdnZXN0IGFkZGluZyDigJx0ZXJtLWNkaXbigJ0gYXMgd2VsbC4NCg0KVGhhbmtzLA0KVG9s Z2ENCg0KRnJvbTogbWFyaWFubmUubW9oYWxpQG9yYW5nZS5jb208bWFpbHRvOm1hcmlhbm5lLm1v aGFsaUBvcmFuZ2UuY29tPiA8bWFyaWFubmUubW9oYWxpQG9yYW5nZS5jb208bWFpbHRvOm1hcmlh bm5lLm1vaGFsaUBvcmFuZ2UuY29tPj4NClNlbnQ6IEZyaWRheSwgTWFyY2ggMTYsIDIwMTggNzoy NyBBTQ0KVG86IEFzdmVyZW4sIFRvbGdhIDx0YXN2ZXJlbkByYmJuLmNvbTxtYWlsdG86dGFzdmVy ZW5AcmJibi5jb20+Pjsgc2lwY29yZUBpZXRmLm9yZzxtYWlsdG86c2lwY29yZUBpZXRmLm9yZz4N ClN1YmplY3Q6IFJFOiBXR0xDOiBkcmFmdC1pZXRmLXNpcGNvcmUtb3JpZ2luYXRpbmctY2Rpdi1w YXJhbWV0ZXINCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk5PVElDRTogVGhp cyBlbWFpbCB3YXMgcmVjZWl2ZWQgZnJvbSBhbiBFWFRFUk5BTCBzZW5kZXINCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQoNCkhpIFRvbGdhLA0KDQpGaXJzdCwgdGhhbmsgeW91IGZv ciB0aGUgcmV2aWV3IG9mIHRoZSBkcmFmdC4NClRvIGFuc3dlciB0byB0aGUgcXVlc3Rpb24gaW4g eW91ciBmaXJzdCBlbWFpbCwgb25jZSBhIGRpdmVyc2lvbiBoYXMgYmVlbiBwcm9jZXNzZWQsIHRo ZSBvdXRnb2luZyBsZWcgd2lsbCBnbyB0byB0aGUgZGl2ZXJzaW9uIHRhcmdldCBidXQgYmVmb3Jl IHRoYXQsIHRoZSBzZXNzaW9uIGNhc2Ugb2YgdGhlIHNlcnZlZC11c2VyIGhhcyBiZWVuIGNoYW5n ZWQgd2l0aCB0aGUgZm9sbG93aW5nIHF1ZXN0aW9uczogd2hvIGlzIHRoZSBvcmlnaW5hdGluZyBw YXJ0eT8gdGhlIGNhbGxlciBvciB0aGUgZGl2ZXJ0aW5nIHVzZXI/IERvZXMgcHJpdmFjeSBvZiB0 aGUgZGl2ZXJ0aW5nIHVzZXIgYXBwbGllcz8gZG8gd2UgbmVlZCB0byBjaGVjayB0aGUgYmFycmlu ZyBzZXJ2aWNlIG9mIHRoZSBkaXZlcnRpbmcgdXNlciBmb3Igb3V0Z29pbmcgY2FsbHM/IE9UT0gs IHRoZSBjYWxsZXIgcmVtYWluIHRoZSBzYW1lIGFuZCBpdHMgb3JpZ2luYXRpbmcgc2VydmljZXMg c2hvdWxkIHN0aWxsIGFwcGx5LiBGb3IgdGhhdCBwYXJ0aWN1bGFyIHNpdHVhdGlvbiBzb21ld2hl cmUgYmV0d2VlbiB0ZXJtaW5hdGluZyBhbmQgb3JpZ2luYXRpbmcsIHRoZSBkcmFmdCBwcm9wb3Nl cyB0byBleHRlbmQgdGhlIFAtU2VydmVkLXVzZXIuDQpBdCB0aGUgZGl2ZXJ0ZWQtdG8gdXNlciBs ZXZlbCwgaXQgaXMgZGlmZmVyZW50OiBJdCBtYXkgaW5kZWVkIGJlIHBvc3NpYmxlIHRvIHRyaWdn ZXIgYSBzcGVjaWZpYyBzZXJ2aWNlIGZvciB0aGUgdGVybWluYXRpbmctYWZ0ZXItZGl2ZXJzaW9u IGJ1dCB0aGlzIGlzIG5vdCBhIG5ldyB0eXBlIHNlc3Npb24gY2FzZS4gQXQgdGhlIHRlcm1pbmF0 aW5nIHNpZGUsIHRoZSBzZXJ2ZWQgdXNlciByZW1haW5zIHRoZSB0ZXJtaW5hdGluZyB1c2VyIGFu ZCBvbmx5IGl0cyB0ZXJtaW5hdGluZyBzZXJ2aWNlcyBoYXZlIHRvIGJlIHRyaWdnZXJlZC4gT2Yg Y291cnNlLCB0ZXJtaW5hdGluZyBzZXJ2aWNlcyBiYXNlZCBvbiB0aGUgb3JpZ2luYXRpbmcgcGFy dHkgaWRlbnRpdHkgYXJlIGFmZmVjdGVkIGJ5IHRoZSBjYWxsIGRpdmVyc2lvbiBzaW5jZSB3ZSBj YW4gZGlzY3VzcyBvbiB3aG8gaXMgdGhlIG9yaWdpbmF0aW5nIHBhcnR5IGJ1dCB0aGlzIGlzIG1v cmUgYSBtYXR0ZXIgb2Ygc2VydmljZSBpbnRlcmFjdGlvbi4gVGhlIHNlcnZlZC11c2VyIGlzIHRo ZSBkaXZlcnNpb24gdGFyZ2V0IGFuZCB0aGUgc2Vzc2lvbiBjYXNlIGlzIHRlcm1pbmF0aW5nIGFu ZCBpdCB3aWxsIG5vdCBjaGFuZ2UgKGV4Y2VwdCBpZiB0aGVyZSBpcyBhbm90aGVyIGNhbGwgZGl2 ZXJzaW9uIDspLiBKdXN0IHRvIGxldCB5b3Uga25vdywgdGhlcmUgaXMgYSBzZXJ2aWNlIHRvIHJl amVjdCBpbmNvbWluZyBmb3J3YXJkZWQgY2FsbHMgYW5kIHRoZSB0cmlnZ2VyIGZvciB0aGlzIHNw ZWNpZmljIGtpbmQgb2YgYmFycmluZyBpcyB0aGUgcHJlc2VuY2Ugb2YgYSBkaXZlcnRpbmcgdXNl ciBpZGVudGl0eSBpbiB0aGUgaW5jb21pbmcgSU5WSVRFIHJlcXVlc3QuIEl0IGlzIGp1c3QgYSBj cml0ZXJpb24gKGFzIGZvciBhbGwgYmFycmluZyBzZXJ2aWNlcykuDQoNCkFib3V0IHlvdXIgY29t bWVudCBvbiB0aGUgd2F5IFNJUCBoZWFkZXJzIGFyZSBleHRlbmRlZCwgSU1PLCBydWxlcyBmb3Ig c3RhbmRhcmRpemF0aW9uIHByb2Nlc3Mgb2YgU0lQIGFyZSBoZXJlIGZvciB5ZWFycyBhbmQgaXQg aXMgbm90IHRoZSBnb29kIHRpbWUgdG8gY2hhbmdlIHRoYXQuIFRvIGJlIHRyYW5zcGFyZW50LCB0 aGlzIGV4dGVuc2lvbiB3YXMgZmlyc3QgZGVmaW5lZCBvbmx5IHdpdGhpbiAzR1BQIHNwZWNpZmlj YXRpb24gYmVjYXVzZSB0aGVyZSB3YXMgYSBzZXJ2aWNlIG5lZWQgYmVoaW5kLiBCZWNhdXNlIGl0 IHdhcyBhbiBleHRlbnNpb24gb2YgYW4gUkZDIGFuZCB0aGUgd2FzIHRoZSBzeW50YXggb2YgdGhl IGhlYWRlciBpcyBkZXNpZ25lZCwgdGhlIGV4dGVuc2lvbiBpcyB0byBiZSBkb25lIGluIElFVEYu IFdlIGNhbiBkaXNjdXNzIHRoYXQgYnV0IHdlIGFyZSBhdCB0aGUgZW5kIG9mIFNJUCBwcm90b2Nv bCBleHRlbnNpb24gcHJvY2Vzcy4uLg0KRmluYWxseSwgUkZDNTUwMiBkZWZpbmVzIGEg4oCccHJp dmF0ZeKAnSAoUC0gKSBoZWFkZXIgc28gaXQgaXMgbm90IHN1cnByaXNpbmcgdGhhdCBpdHMgZXh0 ZW5zaW9uIGFzIGEgM0dQUCBmbGF2b3Ig4pi6DQoNCkJlc3QgcmVnYXJkcywNCk1hcmlhbm5lDQoN Cg0KRGUgOiBzaXBjb3JlIFttYWlsdG86c2lwY29yZS1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBw YXJ0IGRlIEFzdmVyZW4sIFRvbGdhDQpFbnZvecOpIDogdmVuZHJlZGkgMTYgbWFycyAyMDE4IDA5 OjA2DQrDgCA6IHNpcGNvcmVAaWV0Zi5vcmc8bWFpbHRvOnNpcGNvcmVAaWV0Zi5vcmc+DQpPYmpl dCA6IFJlOiBbc2lwY29yZV0gV0dMQzogZHJhZnQtaWV0Zi1zaXBjb3JlLW9yaWdpbmF0aW5nLWNk aXYtcGFyYW1ldGVyDQoNClNvbWUgbW9yZSBtdXNpbmdzIGZyb20gY29uY2VwdHVhbCBwZXJzcGVj dGl2ZToNCg0KU0lQIHByb3ZpZGVzIGEgdG9vbGJveCB0byBwcm92aWRlIHNlcnZpY2VzLiBBbmQg eWVzLCB0aGVyZSBpcyBzb21lIHNwZWNpYWwgKGlmIEkgbWF5IHNheSDigJxmYXZvcmVk4oCdKSBz dGF0dXMgb2YgM0dQUCB3aGVuIGl0IGNvbWVzIHRvIFNJUCBzdGFuZGFyZGl6YXRpb24uIE9UT0gs IGRvZXMgdGhlIGFwcHJvYWNoIHRha2VuIGJ5IFJGQzU1MDIgZ28gYSBsaXR0bGUgYml0IHRvbyBm YXIgaW4gdGVybXMgb2Ygb3Zlci1kZWZpbmluZyB0aGUgZ2VuZXJpYyBTSVAgdG9vbGJveD8NCg0K QW4gYWx0ZXJuYXRpdmUgY291bGQgYmUgdG8gZGVmaW5lIGEgaGVhZGVyL3BhcmFtZXRlciB3aGlj aCByZWZlcnMgdG8gYSDigJxzY2VuYXJpb+KAnSBpbiBhbiBhYnN0cmFjdCB3YXkgKHdpdGggYSBn ZW5lcmljIHN5bnRheCkgYW5kIGxldCBvdGhlciBzdGFuZGFyZHMgZm9yYSBkZWZpbmUgdGhlIHZh bHVlcyB0aGV5IHdvdWxkIGxpa2UgdG8gdXNlIGFuZC9vciByZWx5IG9uIGNvbmZpZ3VyYXRpb24g YWxpZ25tZW50IGJldHdlZW4gcmVsZXZhbnQgZWxlbWVudHMsIGUuZy4gUy1DU0NGL0hTUy9BUy4g Q29uc2lkZXJpbmcgd2hlcmUgd2UgYXJlIHJpZ2h0IG5vdyAodGhhdCBSRkM1NTAyIGlzIGFscmVh ZHkgdGhlcmUpIHRoaXMgYXBwcm9hY2ggcHJhY3RpY2FsbHkgd291bGQgbWVhbiB0aGF0IGRyYWZ0 LWlldGYtc2lwY29yZS1vcmlnaW5hdGluZy1jZGl2LXBhcmFtZXRlciBpcyBub3QgZGVmaW5lZCBh bmQgUC1TZXJ2ZWQtVXNlciBzZXJ2ZWQtdXNlci1wYXJtIGlzIGV4dGVuZGVkIGJ5IG90aGVycyBh cyBuZWVkZWQgKGFzIGl0IGFsbG93cyB0aGF0KS4NCg0KT3RoZXJ3aXNlLCB0aGVyZSB3b3VsZC9j b3VsZCBiZSB0aGUgbmVlZCB0byBrZWVwIGFkZGluZyBuZXcgdmFsdWVzIGluIGRpZmZlcmVudCBJ RVRGIHNwZWNpZmljYXRpb25zIHRoZSBtb3JlIOKAnGRlcGxveW1lbnQgbW9kZWwgc3BlY2lmaWMg dXNlIGNhc2Vz4oCdIGFyZSBuZWVkZWQvZGlzY292ZXJlZC9pbnZlbnRlZC4NCg0KVGhhbmtzLA0K VG9sZ2ENCkZyb206IEFzdmVyZW4sIFRvbGdhDQpTZW50OiBUaHVyc2RheSwgTWFyY2ggMTUsIDIw MTggNDoyMyBQTQ0KVG86IHNpcGNvcmVAaWV0Zi5vcmc8bWFpbHRvOnNpcGNvcmVAaWV0Zi5vcmc+ DQpTdWJqZWN0OiBXR0xDOiBkcmFmdC1pZXRmLXNpcGNvcmUtb3JpZ2luYXRpbmctY2Rpdi1wYXJh bWV0ZXINCg0KSSByZXZpZXdlZCB0aGUgZHJhZnQgYW5kIGhhdmUgbm8gdGVjaG5pY2FsIGlzc3Vl cyB3aXRoIGl0IGV4Y2VwdCBvbmUgcXVlc3Rpb246DQoNCklzIGl0IGVudmlzaW9uZWQgdGhhdCB0 aGVyZSB3b3VsZC9jb3VsZCBiZSBhIG5lZWQgZm9yIHRlcm0tY2RpdiBhcyB3ZWxsIHRvIHRyaWdn ZXIgYSBkaWZmZXJlbnQgc2VydmljZSBzZXQgaWYgdGhlIHRhcmdldCBpcyBkZXRlcm1pbmVkIGFm dGVyIGRpdmVyc2lvbj8gSXQgbWF5IGJlIGJldHRlciB0byBkZWZpbmUgaXQgbm93IHJhdGhlciB0 aGFuIGhhdmluZyB5ZXQgYW5vdGhlciBkcmFmdCwgYXQgbGVhc3QgdG8gYmUgZnV0dXJlIHByb29m Lg0KDQpUaGFua3MsDQpUb2xnYQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNl cyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxs ZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYw0KcGFzIGV0cmUgZGlmZnVzZXMs IGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1 IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXINCmEgbCdleHBlZGl0 ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNz YWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sDQpPcmFu Z2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVy ZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQoNClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0 dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0 aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7DQp0aGV5IHNob3VsZCBub3QgYmUgZGlz dHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4NCklmIHlvdSBo YXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRl ciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KQXMgZW1haWxz IG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBo YXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KVGhhbmsgeW91Lg0KCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIg ZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRv aXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1 dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVp bGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUg bGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNj ZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0 ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2ku CgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRp YWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3 Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQg YXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwg cGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMg YXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFi bGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNp ZmllZC4KVGhhbmsgeW91LgoK --_000_8B970F90C584EA4E97D5BAAC9172DBB81D70B5E7OPEXCLILMA4corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQg MyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiU2Vnb2UgVUkgU3ltYm9s IjsNCglwYW5vc2UtMToyIDExIDUgMiA0IDIgNCAyIDIgMzt9DQovKiBTdHlsZSBEZWZpbml0aW9u cyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46 MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGlu aw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlRleHRlIGRlIGJ1bGxl cyBDYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KcC5tc29ub3Jt YWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29u b3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCglt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXpl OjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1h aWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUx OQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQXJpYWwi LCJzYW5zLXNlcmlmIjsNCgljb2xvcjpibGFjazsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9u dC1zdHlsZTpub3JtYWw7fQ0Kc3Bhbi5UZXh0ZWRlYnVsbGVzQ2FyDQoJe21zby1zdHlsZS1uYW1l OiJUZXh0ZSBkZSBidWxsZXMgQ2FyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IlRleHRlIGRlIGJ1bGxlcyI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3 OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJG UiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6YmxhY2siPkl0IGlzIHRydWUgdGhhdCB3ZSBjb3VsZCBjb25zaWRlciB0aGlz IOKAnHRlcm0tY2RpduKAnSBjYXNlIGluIHRoZSBJLUQgdG8gaGF2ZSBhIHN5bW1ldHJpYyB2YWx1 ZSBldmVuIGlmIGZvciBub3cgbm8g4oCcbmVlZOKAnSBoYXMgYmVlbiBpZGVudGlmaWVkLg0KPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkkgY2FuIHdvcmsgb24gdGhpcyBh ZGRpbmcgdG8gdGhlIEktRC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkFueSBvdGhlciB2 aWV3cyBvbiBpbnRyb2R1Y2luZyB0aGUgc2Vzc2lvbiBjYXNlIOKAnHRlcm0tY2RpduKAnSB0b28/ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5CUiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjpibGFjayI+TWFyaWFubmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0 Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0 REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RGUmbmJzcDs6PC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEFzdmVyZW4sIFRvbGdhIFttYWlsdG86dGFzdmVyZW5A cmJibi5jb21dDQo8YnI+DQo8Yj5FbnZvecOpJm5ic3A7OjwvYj4gdmVuZHJlZGkgMTYgbWFycyAy MDE4IDEzOjI1PGJyPg0KPGI+w4AmbmJzcDs6PC9iPiBNT0hBTEkgTWFyaWFubmUgSU1UL09MTjsg c2lwY29yZUBpZXRmLm9yZzxicj4NCjxiPk9iamV0Jm5ic3A7OjwvYj4gUkU6IFdHTEM6IGRyYWZ0 LWlldGYtc2lwY29yZS1vcmlnaW5hdGluZy1jZGl2LXBhcmFtZXRlcjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5IaSBNYXJp YW5uZSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoYW5rIHlvdSBmb3IgdGhlIGRldGFpbGVkIGV4cGxh bmF0aW9uIG9mIHRoZSBzZXJ2aWNlLiBZZXMsIHRoYXQgaXMgc29tZXRoaW5nIHVzZWQgdG9kYXku IEJ1dCBob3cgY291bGQgd2Uga25vdyB0aGF0IHRoZXJlIHdvdWxkbuKAmXQgYmUgYW55IHNlcnZp Y2VzIHdoaWNoIHdvdWxkIGJlIHRyaWdnZXJlZC9ub3QgdHJpZ2dlcmVkIG9uIHRoZSBkaXZlcnRp bmcgcGFydHkgYmFzZWQgb24NCiB3aGV0aGVyIGl0IGlzIHRoZSBvcmlnaW5hbCBpbml0aWF0b3Ig b2YgdGhlIGNhbGwgb3IganVzdCB0aGUgZGl2ZXJ0ZXI/IFRoYXQgaXQgaXMgbm90IG5lZWRlZCB0 b2RheSAtYnkgYSBjZXJ0YWluIGRlcGxveW1lbnQgbW9kZWwtLCBvciB0aGF0IHlvdShhbmQgSSkg YXJlIG5vdCBhd2FyZSBvZiBpdCBkb2VzIG5vdCBuZWNlc3NhcmlseSBtZWFuIGl0IHdvdWxkbuKA mXQvaXMgYWxyZWFkeSB1c2VkIHNvbWV3aGVyZSBpbiB0aGUgdW5pdmVyc2Ugb2YgcmVhbA0KIHRp bWUgc2Vzc2lvbnMuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhlIHNoaXAgZm9yIGEgbW9yZSBnZW5l cmljIGZyYW1ld29yayB0byBmYWNpbGl0YXRlIOKAnHNjZW5hcmlvIGJhc2VkIHNlcnZpY2UgaW52 b2NhdGlvbi9pbnRlcmFjdGlvbuKAnSBtYXkgaGF2ZSBzYWlsZWQgYnV0IGF0IGEgbWluaW11bSBJ IHdvdWxkIHN1Z2dlc3QgYWRkaW5nIOKAnHRlcm0tY2RpduKAnSBhcyB3ZWxsLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5Ub2xnYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj RTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJF Ti1VUyI+IDxhIGhyZWY9Im1haWx0bzptYXJpYW5uZS5tb2hhbGlAb3JhbmdlLmNvbSI+DQptYXJp YW5uZS5tb2hhbGlAb3JhbmdlLmNvbTwvYT4gJmx0OzxhIGhyZWY9Im1haWx0bzptYXJpYW5uZS5t b2hhbGlAb3JhbmdlLmNvbSI+bWFyaWFubmUubW9oYWxpQG9yYW5nZS5jb208L2E+Jmd0Ow0KPGJy Pg0KPGI+U2VudDo8L2I+IEZyaWRheSwgTWFyY2ggMTYsIDIwMTggNzoyNyBBTTxicj4NCjxiPlRv OjwvYj4gQXN2ZXJlbiwgVG9sZ2EgJmx0OzxhIGhyZWY9Im1haWx0bzp0YXN2ZXJlbkByYmJuLmNv bSI+dGFzdmVyZW5AcmJibi5jb208L2E+Jmd0OzsNCjxhIGhyZWY9Im1haWx0bzpzaXBjb3JlQGll dGYub3JnIj5zaXBjb3JlQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogV0dM QzogZHJhZnQtaWV0Zi1zaXBjb3JlLW9yaWdpbmF0aW5nLWNkaXYtcGFyYW1ldGVyPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IGNsYXNzPSJN c29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlciI+PHNwYW4g bGFuZz0iRU4tVVMiPg0KPGhyIHNpemU9IjIiIHdpZHRoPSIxMDAlIiBhbGlnbj0iY2VudGVyIj4N Cjwvc3Bhbj48L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5O T1RJQ0U6IFRoaXMgZW1haWwgd2FzIHJlY2VpdmVkIGZyb20gYW4gRVhURVJOQUwgc2VuZGVyPG86 cD48L286cD48L3NwYW4+PC9wPg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVy IiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPjxzcGFuIGxhbmc9IkVOLVVTIj4NCjxociBzaXpl PSIyIiB3aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+DQo8L3NwYW4+PC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVO LVVTIj48YnI+DQpIaSBUb2xnYSw8YnI+DQo8YnI+DQpGaXJzdCwgdGhhbmsgeW91IGZvciB0aGUg cmV2aWV3IG9mIHRoZSBkcmFmdC48YnI+DQpUbyBhbnN3ZXIgdG8gdGhlIHF1ZXN0aW9uIGluIHlv dXIgZmlyc3QgZW1haWwsIG9uY2UgYSBkaXZlcnNpb24gaGFzIGJlZW4gcHJvY2Vzc2VkLCB0aGUg b3V0Z29pbmcgbGVnIHdpbGwgZ28gdG8gdGhlIGRpdmVyc2lvbiB0YXJnZXQgYnV0IGJlZm9yZSB0 aGF0LCB0aGUgc2Vzc2lvbiBjYXNlIG9mIHRoZSBzZXJ2ZWQtdXNlciBoYXMgYmVlbiBjaGFuZ2Vk IHdpdGggdGhlIGZvbGxvd2luZyBxdWVzdGlvbnM6IHdobyBpcyB0aGUgb3JpZ2luYXRpbmcgcGFy dHk/DQogdGhlIGNhbGxlciBvciB0aGUgZGl2ZXJ0aW5nIHVzZXI/IERvZXMgcHJpdmFjeSBvZiB0 aGUgZGl2ZXJ0aW5nIHVzZXIgYXBwbGllcz8gZG8gd2UgbmVlZCB0byBjaGVjayB0aGUgYmFycmlu ZyBzZXJ2aWNlIG9mIHRoZSBkaXZlcnRpbmcgdXNlciBmb3Igb3V0Z29pbmcgY2FsbHM/IE9UT0gs IHRoZSBjYWxsZXIgcmVtYWluIHRoZSBzYW1lIGFuZCBpdHMgb3JpZ2luYXRpbmcgc2VydmljZXMg c2hvdWxkIHN0aWxsIGFwcGx5LiBGb3IgdGhhdCBwYXJ0aWN1bGFyDQogc2l0dWF0aW9uIHNvbWV3 aGVyZSBiZXR3ZWVuIHRlcm1pbmF0aW5nIGFuZCBvcmlnaW5hdGluZywgdGhlIGRyYWZ0IHByb3Bv c2VzIHRvIGV4dGVuZCB0aGUgUC1TZXJ2ZWQtdXNlci4NCjxicj4NCkF0IHRoZSBkaXZlcnRlZC10 byB1c2VyIGxldmVsLCBpdCBpcyBkaWZmZXJlbnQ6IEl0IG1heSBpbmRlZWQgYmUgcG9zc2libGUg dG8gdHJpZ2dlciBhIHNwZWNpZmljIHNlcnZpY2UgZm9yIHRoZSB0ZXJtaW5hdGluZy1hZnRlci1k aXZlcnNpb24gYnV0IHRoaXMgaXMgbm90IGEgbmV3IHR5cGUgc2Vzc2lvbiBjYXNlLiBBdCB0aGUg dGVybWluYXRpbmcgc2lkZSwgdGhlIHNlcnZlZCB1c2VyIHJlbWFpbnMgdGhlIHRlcm1pbmF0aW5n IHVzZXIgYW5kIG9ubHkNCiBpdHMgdGVybWluYXRpbmcgc2VydmljZXMgaGF2ZSB0byBiZSB0cmln Z2VyZWQuIE9mIGNvdXJzZSwgdGVybWluYXRpbmcgc2VydmljZXMgYmFzZWQgb24gdGhlIG9yaWdp bmF0aW5nIHBhcnR5IGlkZW50aXR5IGFyZSBhZmZlY3RlZCBieSB0aGUgY2FsbCBkaXZlcnNpb24g c2luY2Ugd2UgY2FuIGRpc2N1c3Mgb24gd2hvIGlzIHRoZSBvcmlnaW5hdGluZyBwYXJ0eSBidXQg dGhpcyBpcyBtb3JlIGEgbWF0dGVyIG9mIHNlcnZpY2UgaW50ZXJhY3Rpb24uDQogVGhlIHNlcnZl ZC11c2VyIGlzIHRoZSBkaXZlcnNpb24gdGFyZ2V0IGFuZCB0aGUgc2Vzc2lvbiBjYXNlIGlzIHRl cm1pbmF0aW5nIGFuZCBpdCB3aWxsIG5vdCBjaGFuZ2UgKGV4Y2VwdCBpZiB0aGVyZSBpcyBhbm90 aGVyIGNhbGwgZGl2ZXJzaW9uIDspLiBKdXN0IHRvIGxldCB5b3Uga25vdywgdGhlcmUgaXMgYSBz ZXJ2aWNlIHRvIHJlamVjdCBpbmNvbWluZyBmb3J3YXJkZWQgY2FsbHMgYW5kIHRoZSB0cmlnZ2Vy IGZvciB0aGlzIHNwZWNpZmljDQoga2luZCBvZiBiYXJyaW5nIGlzIHRoZSBwcmVzZW5jZSBvZiBh IGRpdmVydGluZyB1c2VyIGlkZW50aXR5IGluIHRoZSBpbmNvbWluZyBJTlZJVEUgcmVxdWVzdC4g SXQgaXMganVzdCBhIGNyaXRlcmlvbiAoYXMgZm9yIGFsbCBiYXJyaW5nIHNlcnZpY2VzKS4NCjxi cj4NCjxicj4NCkFib3V0IHlvdXIgY29tbWVudCBvbiB0aGUgd2F5IFNJUCBoZWFkZXJzIGFyZSBl eHRlbmRlZCwgSU1PLCBydWxlcyBmb3Igc3RhbmRhcmRpemF0aW9uIHByb2Nlc3Mgb2YgU0lQIGFy ZSBoZXJlIGZvciB5ZWFycyBhbmQgaXQgaXMgbm90IHRoZSBnb29kIHRpbWUgdG8gY2hhbmdlIHRo YXQuIFRvIGJlIHRyYW5zcGFyZW50LCB0aGlzIGV4dGVuc2lvbiB3YXMgZmlyc3QgZGVmaW5lZCBv bmx5IHdpdGhpbiAzR1BQIHNwZWNpZmljYXRpb24gYmVjYXVzZSB0aGVyZQ0KIHdhcyBhIHNlcnZp Y2UgbmVlZCBiZWhpbmQuIEJlY2F1c2UgaXQgd2FzIGFuIGV4dGVuc2lvbiBvZiBhbiBSRkMgYW5k IHRoZSB3YXMgdGhlIHN5bnRheCBvZiB0aGUgaGVhZGVyIGlzIGRlc2lnbmVkLCB0aGUgZXh0ZW5z aW9uIGlzIHRvIGJlIGRvbmUgaW4gSUVURi4gV2UgY2FuIGRpc2N1c3MgdGhhdCBidXQgd2UgYXJl IGF0IHRoZSBlbmQgb2YgU0lQIHByb3RvY29sIGV4dGVuc2lvbiBwcm9jZXNzLi4uPGJyPg0KRmlu YWxseSwgUkZDNTUwMiBkZWZpbmVzIGEg4oCccHJpdmF0ZeKAnSAoUC0gKSBoZWFkZXIgc28gaXQg aXMgbm90IHN1cnByaXNpbmcgdGhhdCBpdHMgZXh0ZW5zaW9uIGFzIGEgM0dQUCBmbGF2b3INCjwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJ IFN5bWJvbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij7imLo8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiPjxicj4NCjxicj4NCkJlc3QgcmVnYXJkcyw8YnI+DQpNYXJpYW5uZTxicj4NCjxi cj4NCjxicj4NCkRlJm5ic3A7OiBzaXBjb3JlIFs8YSBocmVmPSJtYWlsdG86c2lwY29yZS1ib3Vu Y2VzQGlldGYub3JnIj5tYWlsdG86c2lwY29yZS1ib3VuY2VzQGlldGYub3JnPC9hPl0gRGUgbGEg cGFydCBkZSBBc3ZlcmVuLCBUb2xnYTxicj4NCkVudm95w6kmbmJzcDs6IHZlbmRyZWRpIDE2IG1h cnMgMjAxOCAwOTowNjxicj4NCsOAJm5ic3A7OiA8YSBocmVmPSJtYWlsdG86c2lwY29yZUBpZXRm Lm9yZyI+c2lwY29yZUBpZXRmLm9yZzwvYT48YnI+DQpPYmpldCZuYnNwOzogUmU6IFtzaXBjb3Jl XSBXR0xDOiBkcmFmdC1pZXRmLXNpcGNvcmUtb3JpZ2luYXRpbmctY2Rpdi1wYXJhbWV0ZXI8YnI+ DQo8YnI+DQpTb21lIG1vcmUgbXVzaW5ncyBmcm9tIGNvbmNlcHR1YWwgcGVyc3BlY3RpdmU6PGJy Pg0KPGJyPg0KU0lQIHByb3ZpZGVzIGEgdG9vbGJveCB0byBwcm92aWRlIHNlcnZpY2VzLiBBbmQg eWVzLCB0aGVyZSBpcyBzb21lIHNwZWNpYWwgKGlmIEkgbWF5IHNheSDigJxmYXZvcmVk4oCdKSBz dGF0dXMgb2YgM0dQUCB3aGVuIGl0IGNvbWVzIHRvIFNJUCBzdGFuZGFyZGl6YXRpb24uIE9UT0gs IGRvZXMgdGhlIGFwcHJvYWNoIHRha2VuIGJ5IFJGQzU1MDIgZ28gYSBsaXR0bGUgYml0IHRvbyBm YXIgaW4gdGVybXMgb2Ygb3Zlci1kZWZpbmluZyB0aGUgZ2VuZXJpYyBTSVANCiB0b29sYm94Pzxi cj4NCjxicj4NCkFuIGFsdGVybmF0aXZlIGNvdWxkIGJlIHRvIGRlZmluZSBhIGhlYWRlci9wYXJh bWV0ZXIgd2hpY2ggcmVmZXJzIHRvIGEg4oCcc2NlbmFyaW/igJ0gaW4gYW4gYWJzdHJhY3Qgd2F5 ICh3aXRoIGEgZ2VuZXJpYyBzeW50YXgpIGFuZCBsZXQgb3RoZXIgc3RhbmRhcmRzIGZvcmEgZGVm aW5lIHRoZSB2YWx1ZXMgdGhleSB3b3VsZCBsaWtlIHRvIHVzZSBhbmQvb3IgcmVseSBvbiBjb25m aWd1cmF0aW9uIGFsaWdubWVudCBiZXR3ZWVuIHJlbGV2YW50IGVsZW1lbnRzLA0KIGUuZy4gUy1D U0NGL0hTUy9BUy4gQ29uc2lkZXJpbmcgd2hlcmUgd2UgYXJlIHJpZ2h0IG5vdyAodGhhdCBSRkM1 NTAyIGlzIGFscmVhZHkgdGhlcmUpIHRoaXMgYXBwcm9hY2ggcHJhY3RpY2FsbHkgd291bGQgbWVh biB0aGF0IGRyYWZ0LWlldGYtc2lwY29yZS1vcmlnaW5hdGluZy1jZGl2LXBhcmFtZXRlciBpcyBu b3QgZGVmaW5lZCBhbmQgUC1TZXJ2ZWQtVXNlciBzZXJ2ZWQtdXNlci1wYXJtIGlzIGV4dGVuZGVk IGJ5IG90aGVycyBhcyBuZWVkZWQNCiAoYXMgaXQgYWxsb3dzIHRoYXQpLjxicj4NCjxicj4NCk90 aGVyd2lzZSwgdGhlcmUgd291bGQvY291bGQgYmUgdGhlIG5lZWQgdG8ga2VlcCBhZGRpbmcgbmV3 IHZhbHVlcyBpbiBkaWZmZXJlbnQgSUVURiBzcGVjaWZpY2F0aW9ucyB0aGUgbW9yZSDigJxkZXBs b3ltZW50IG1vZGVsIHNwZWNpZmljIHVzZSBjYXNlc+KAnSBhcmUgbmVlZGVkL2Rpc2NvdmVyZWQv aW52ZW50ZWQuPGJyPg0KPGJyPg0KVGhhbmtzLDxicj4NClRvbGdhPGJyPg0KRnJvbTogQXN2ZXJl biwgVG9sZ2EgPGJyPg0KU2VudDogVGh1cnNkYXksIE1hcmNoIDE1LCAyMDE4IDQ6MjMgUE08YnI+ DQpUbzogPGEgaHJlZj0ibWFpbHRvOnNpcGNvcmVAaWV0Zi5vcmciPnNpcGNvcmVAaWV0Zi5vcmc8 L2E+PGJyPg0KU3ViamVjdDogV0dMQzogZHJhZnQtaWV0Zi1zaXBjb3JlLW9yaWdpbmF0aW5nLWNk aXYtcGFyYW1ldGVyPGJyPg0KPGJyPg0KSSByZXZpZXdlZCB0aGUgZHJhZnQgYW5kIGhhdmUgbm8g dGVjaG5pY2FsIGlzc3VlcyB3aXRoIGl0IGV4Y2VwdCBvbmUgcXVlc3Rpb246PGJyPg0KPGJyPg0K SXMgaXQgZW52aXNpb25lZCB0aGF0IHRoZXJlIHdvdWxkL2NvdWxkIGJlIGEgbmVlZCBmb3IgdGVy bS1jZGl2IGFzIHdlbGwgdG8gdHJpZ2dlciBhIGRpZmZlcmVudCBzZXJ2aWNlIHNldCBpZiB0aGUg dGFyZ2V0IGlzIGRldGVybWluZWQgYWZ0ZXIgZGl2ZXJzaW9uPyBJdCBtYXkgYmUgYmV0dGVyIHRv IGRlZmluZSBpdCBub3cgcmF0aGVyIHRoYW4gaGF2aW5nIHlldCBhbm90aGVyIGRyYWZ0LCBhdCBs ZWFzdCB0byBiZSBmdXR1cmUgcHJvb2YuPGJyPg0KPGJyPg0KVGhhbmtzLDxicj4NClRvbGdhPGJy Pg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj4NCjxicj4NCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2lu dGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3Ug cHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYzxicj4NCnBhcyBldHJlIGRpZmZ1c2VzLCBl eHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBj ZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyPGJyPg0KYSBsJ2V4cGVk aXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1l c3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiw8YnI+ DQpPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRl IGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuPGJyPg0KPGJyPg0KVGhpcyBtZXNz YWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZp bGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzs8YnI+DQp0aGV5 IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9y aXNhdGlvbi48YnI+DQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBw bGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBh dHRhY2htZW50cy48YnI+DQpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3Qg bGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBm YWxzaWZpZWQuPGJyPg0KVGhhbmsgeW91LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8UFJFPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBl dXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmls ZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91 IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBw YXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRy dWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25p cXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0 ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBm YWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29u dGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBw cm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3Ig Y29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBl bWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBt ZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3Jh bmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBj aGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91Lgo8L1BSRT48L2JvZHk+DQo8L2h0bWw+DQo= --_000_8B970F90C584EA4E97D5BAAC9172DBB81D70B5E7OPEXCLILMA4corp_-- From nobody Sat Mar 17 05:48:15 2018 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 8892C12778E for ; Sat, 17 Mar 2018 05:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.685 X-Spam-Level: X-Spam-Status: No, score=-1.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 g7GguGckHojg for ; Sat, 17 Mar 2018 05:48:13 -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 6DFF8127077 for ; Sat, 17 Mar 2018 05:48:13 -0700 (PDT) Received: from resomta-ch2-05v.sys.comcast.net ([69.252.207.101]) by resqmta-ch2-09v.sys.comcast.net with ESMTP id xBFEeLjZa4Y6CxBFseErgs; Sat, 17 Mar 2018 12:48:12 +0000 Received: from hobgoblin.ariadne.com ([65.96.206.41]) by resomta-ch2-05v.sys.comcast.net with SMTP id xBFqeFKSytpSJxBFrecXL5; Sat, 17 Mar 2018 12:48: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 w2HCmAUd010426; Sat, 17 Mar 2018 08:48:10 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id w2HCmApN010421; Sat, 17 Mar 2018 08:48: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: Brian Rosen Cc: sipcore@ietf.org In-Reply-To: (br@brianrosen.net) Sender: worley@ariadne.com (Dale R. Worley) Date: Sat, 17 Mar 2018 08:48:10 -0400 Message-ID: <87vadu6f79.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfJxdNJJPPL3toF2KZPfy3KOVOmjrhbcOd3hsLYwT8PUuillcfFuQ6mwxoCeEOgNjwPlUrZoHVEeVAm6WaSaL2DNung7IZfxYCC5EfmZhsBg1DNoc0oRe OTVjMDXDR5Qucz6D1GaapsF6giMgHTzmIJAKmwNQw3Yg7BjPz4hDC5Ht41M8qGk9/pzeNqUU9EplaTbijf9Fn1QTxsLGTWQrrn0= Archived-At: Subject: Re: [sipcore] -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: Sat, 17 Mar 2018 12:48:14 -0000 Brian Rosen writes: > There was a lot of discussion during the WGLC on push. Does everyone think > their issues are dealt with satisfactorily I the latest draft? In my mind there are a considerable number of open issues. Part of the problem is that I'm just not caught up on the conversation, but I'm pretty sure that another part is that I don't see the problem space we're addressing clearly, and quickly looking at the latest draft, I don't see that it lays out the constraints that the solution has to work within. Because of that vagueness, I am not comfortable with some of the less-elegant/consistent parts of the proposal are truly needed, that we may be able to produce a better mechanism. The first step to solving this is for me to get caught up on the discussion, which I am starting to to. However, one open point is this question I had, which I don't think has been sufficiently addressed. The problem is that the current scheme requires that the implementing proxy be able to see any re-REGISTER that the device produces, which argues that the proxy must be very central to the SIP service for the SIP domain. And yet some aspects of the scheme seem to be required only because the proxy is *not* central to the SIP service, in particular, that the proxy has no visibility into the AOR to which an incoming request is directed. This suggests that the proxy is "downstream" from the domain's redirector, which seems to be in conflice that the proxy can see evern REGISTER for the domain. Re: [sipcore] SIP-push -- Where is the "proxy"? Date: Thu, 08 Mar 2018 22:22:29 -0500 On one hand, as you say, the proxy can be in the path of the REGISTER. That requires that the proxy be "near" the registrar, so that any REGISTER for the AOR will necessarily pass through the proxy as well. But that pretty much requires that the proxy be attached to the registrar, as otherwise REGISTERs can take routes to the registrar that miss the proxy. (I particularly imagine the WiFi/cellular use case that Roman mentions, which has been a huge market target for over 10 years. In that case, the phone can easily re-REGISTER on an entirely different network than it was previously registered through.) But if the proxy is "near the edge", it needs a way to wait for the re-REGISTER that doesn't require it to process the re-REGISTER. I think that this can be done by it subscribing to the 'reg' package for the AOR, but that requires that the R-URI that it sees in the incoming request to somehow carry the AOR. Dale From nobody Sat Mar 17 06:08:52 2018 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 52C7C127867 for ; Sat, 17 Mar 2018 06:08:50 -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, 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=ericsson.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 gpY14T3XQGqA for ; Sat, 17 Mar 2018 06:08:48 -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 6085A12783A for ; Sat, 17 Mar 2018 06:08:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1521292126; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=+t6KJnNPu76y3VCum+APJqzfxMh/RTJaG0BEJQTgE/k=; b=f0E+DLma9UQOcKl5gWIRbY4ELWEx1yp8w7Tfd/d8LiszqZ5XRHqZL6RXBLvSabIB enQ4BdD4lffzVJYjLqFqUGdKeLorLJD8LEbVI9/zPXaXW8B/1OP22BG4StEh/NW0 DS1YMKA8O3Od30U1h3r2kTkU1BoHQraz42cqTbIJQsU=; X-AuditID: c1b4fb3a-347ff700000067b4-f1-5aad135ece20 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id B2.93.26548.E531DAA5; Sat, 17 Mar 2018 14:08:46 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.172]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0382.000; Sat, 17 Mar 2018 14:08:45 +0100 From: Christer Holmberg To: "Dale R. Worley" , Brian Rosen CC: "sipcore@ietf.org" Thread-Topic: [sipcore] -push Thread-Index: AQHTve47Py/tNoXQAEGEEsOh9dr45qPUY7Nw Date: Sat, 17 Mar 2018 13:08:46 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B6C209642@ESESSMB109.ericsson.se> References: (br@brianrosen.net) <87vadu6f79.fsf@hobgoblin.ariadne.com> In-Reply-To: <87vadu6f79.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.168] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphkeLIzCtJLcpLzFFi42KZGbHdQDdOeG2UwYq3yhZP709js/j6YxOb xcsTZQ7MHpP3f2X2uP/tL7vHkiU/mQKYo7hsUlJzMstSi/TtErgyLi/uYC2YIVVx/ug+xgbG vSJdjBwcEgImEhcnxHUxcnEICRxmlGhY/Z0NwlnCKNH8awYbSBGbgIVE9z/tLkZODhEBL4lt F/8zg9jMApoSj3buZQIpERaQkTj3TAiiRFai4fAKdgjbSGLz5E1sIDaLgKpE25kFrCA2r4Cv xOm1/5ghVvUySrRMagWbySlgLLF+yTwwm1FATOL7qTVMELvEJW49mQ9mSwgISCzZc54ZwhaV ePn4HyuErSTRc/8eVL2OxILdn9ggbG2JZQtfM0MsFpQ4OfMJywRG0VlIxs5C0jILScssJC0L GFlWMYoWpxYX56YbGemlFmUmFxfn5+nlpZZsYgTGzcEtv612MB587niIUYCDUYmH9zXH2igh 1sSy4srcQ4wSHMxKIryLFqyJEuJNSaysSi3Kjy8qzUktPsQozcGiJM7rlGYRJSSQnliSmp2a WpBaBJNl4uCUamA0nDxjrotyc9tqxreOoQu5GbNfsM2VeRGUKCDlIBmiV/zGS8TOq/Yzm0GG 1j/xkk2Hyn+HeE2+tVXcOu1XdLJnfOdN5qC/y18byDzmK+ps+x7yp3XWyftaiua/ovzf2bRr xc08tkb78xSRaT3fLZfemC/978G//VtO7pi/ZO/76jipyTWztB4rsRRnJBpqMRcVJwIAy5RA WJcCAAA= Archived-At: Subject: Re: [sipcore] -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: Sat, 17 Mar 2018 13:08:50 -0000 Hi, > In my mind there are a considerable number of open issues. Part of the p= roblem is that I'm just not caught > up on the conversation, but I'm pretty sure that another part is that I d= on't see the problem space we're addressing=20 > clearly, and quickly looking at the latest draft, I don't see that it lay= s out the constraints that the solution has to work=20 > within. Because of that vagueness, I am not comfortable with some of the= less-elegant/consistent parts of the proposal=20 > are truly needed, that we may be able to produce a better mechanism. > > The first step to solving this is for me to get caught up on the discussi= on, which I am starting to to. > > However, one open point is this question I had, which I don't think has b= een sufficiently addressed. The problem is that > the current scheme requires that the implementing proxy be able to see an= y re-REGISTER that the device produces, which=20 > argues that the proxy must be very central to the SIP service for the SIP= domain. And yet some aspects of the scheme seem=20 > to be required only because the proxy is *not* central to the SIP service= , in particular, that the proxy has no visibility into the=20 > AOR to which an incoming request is directed. This suggests that the pro= xy is "downstream" from the domain's redirector,=20 > which seems to be in conflice that the proxy can see evern REGISTER for t= he domain. It has been the assumption from day one that the proxy is either part of th= e registrar, or somehow access to registration information in order to know= when re-registration push notifications are to be requested (the proxy is = not able to request re-register push notifications if it doesn't know when = the registration is about to expire). That fits all planned deployments tha= t I am aware of. Having said that, as I indicated earlier, it is always possible to define a= dditional URI parameters etc in order to provide additional information to = the proxy. But that can be done in a separate draft. Regards, Christer Re: [sipcore] SIP-push -- Where is the "proxy"? Date: Thu, 08 Mar 2018 22:22:29 -0500 On one hand, as you say, the proxy can be in the path of the REGISTER. That requires that the proxy be "near" the registrar, so that any REGISTER for the AOR will necessarily pass through the proxy as well. But that pretty much requires that the proxy be attached to the registrar, as otherwise REGISTERs can take routes to the registrar that miss the proxy. (I particularly imagine the WiFi/cellular use case that Roman mentions, which has been a huge market target for over 10 years. In that case, the phone can easily re-REGISTER on an entirely different network than it was previously registered through.) But if the proxy is "near the edge", it needs a way to wait for the re-REGISTER that doesn't require it to process the re-REGISTER. I thin= k that this can be done by it subscribing to the 'reg' package for the AOR, but that requires that the R-URI that it sees in the incoming request to somehow carry the AOR. Dale _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From nobody Sun Mar 18 05:29:51 2018 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 7F33E127871 for ; Sun, 18 Mar 2018 05:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.686 X-Spam-Level: X-Spam-Status: No, score=-1.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 3EUQXT_UIHvN for ; Sun, 18 Mar 2018 05:29:45 -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 875F512778E for ; Sun, 18 Mar 2018 05:29:45 -0700 (PDT) Received: from resomta-ch2-19v.sys.comcast.net ([69.252.207.115]) by resqmta-ch2-09v.sys.comcast.net with ESMTP id xXRTeYbtzBANoxXRYeGL3u; Sun, 18 Mar 2018 12:29:44 +0000 Received: from hobgoblin.ariadne.com ([65.96.206.41]) by resomta-ch2-19v.sys.comcast.net with SMTP id xXRXemTeJrKtjxXRXeCmmx; Sun, 18 Mar 2018 12:29:44 +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 w2ICThMN019361; Sun, 18 Mar 2018 08:29:43 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id w2ICTh8w019358; Sun, 18 Mar 2018 08:29:43 -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: "A. Jean Mahoney" Cc: sipcore@ietf.org In-Reply-To: (mahoney@nostrum.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Sun, 18 Mar 2018 08:29:43 -0400 Message-ID: <87muz55zyg.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfCzqMDHRmsMES00eTCJ7OYSIKq/XmfzAU0eO2zNLDLclIdk20/pUcVLBTWDoM+72xjHHJoq1rwQI6P5SRafIAeUmVE5E6X/y3FHiLhbArn3WiuK1QrhA qr9XlbvtsN9cKf3xGAnMr25zK3z9IxVrhlQ4yMFBH6YGaHxwPMuZDevf8AHqtES4Ne8G8M6uQpqIZw82FBDjRJ7d9MuK4W4TBPI= Archived-At: Subject: Re: [sipcore] WGLC: 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: Sun, 18 Mar 2018 12:29:47 -0000 "A. Jean Mahoney" writes: > This draft received no feedback during WGLC. We need at least some > indication that WG participants have read the draft. If you have read it > and you think that the draft is ready, please explicitly state that on > list. I support approving this draft. I have read this draft during some of its previous periods of discussion, including the period leading up to WGLC (around 2 Feb 2018). At that time I noted that while the proposed syntax is not as regular as I'd like, the proposed syntax is already deployed in the real world, and the best cost/benefit is to not change it. Also, I have a suggestion for improving how the syntax is presented. The current (-01) ABNF includes: sessioncase-param = 1("sescase" EQUAL 1("orig" / "term")/ orig-cdiv) registration-state-param = "regstate" EQUAL 1("unreg" / "reg") whereas it is more conventional to express that in this manner: sessioncase-param = "sescase" EQUAL ("orig" / "term") / orig-cdiv registration-state-param = "regstate" EQUAL ("unreg" / "reg") Dale From nobody Sun Mar 18 07:03:01 2018 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 765A812711A for ; Sun, 18 Mar 2018 07:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.686 X-Spam-Level: X-Spam-Status: No, score=-1.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 kzQSNhnI_W2H for ; Sun, 18 Mar 2018 07:02:58 -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 71B03126C0F for ; Sun, 18 Mar 2018 07:02:58 -0700 (PDT) Received: from resomta-ch2-09v.sys.comcast.net ([69.252.207.105]) by resqmta-ch2-02v.sys.comcast.net with ESMTP id xYtae60p4DxbqxYtletuMq; Sun, 18 Mar 2018 14:02:57 +0000 Received: from hobgoblin.ariadne.com ([65.96.206.41]) by resomta-ch2-09v.sys.comcast.net with SMTP id xYtkeZ5X8pGaqxYtkexASd; Sun, 18 Mar 2018 14:02:57 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id w2IE2uk8026666 for ; Sun, 18 Mar 2018 10:02:56 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id w2IE2tWS026660; Sun, 18 Mar 2018 10:02:55 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: sipcore@ietf.org Sender: worley@ariadne.com (Dale R. Worley) Date: Sun, 18 Mar 2018 10:02:55 -0400 Message-ID: <87in9t5vn4.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfG19pCWmgFT/H7o/Tav1QMAxXamA1lo7pmeyWgRCelyvQmcAOttlYJ2NCEoo27x2EGQ080PK8i9SJTOI45uQoJeKmueije/1p9aISW4Kpi2Ch0wwbo4j 751QXhPch/DRWnXArIqIX+bTYMSr5V/LinKVCzFCkqXv/OsLPv/oI942 Archived-At: Subject: [sipcore] More comments regarding draft-ietf-sipcore-sip-push-08 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: Sun, 18 Mar 2018 14:03:00 -0000 Catching up on the work, I've gone through draft-ietf-sipcore-sip-push-08, and here are some small technical issues and editorial matters: sec 5.2 makes it sound like the proxy is required to wake up the UA if the registration is close to expiration, even if the UA registered with sip.pnsreg and the proxy responded with sip.pnsreg. Is that intended? Because it sounds like the behavior of the proxy does not change based on sip.pnsreg -- it wakes up the UA if the registration is near expiration. In which case, what does sip.pnsreg do? As compared with sec 4, where sip.pnsreg seems to be the way that the UA and the proxy negotiate which one of them is reponsible for timing registrations. 5.3.1. REGISTER Request Otherwise, if the pn-provider SIP URI parameter identifies a PNS that the proxy does not support, or if the REGISTER request does not contain all additional information required for the specific PNS, the proxy MUST either forward the request (e.g., if the proxy knows that a downstream proxy supports the PNS) or send a SIP 555 (Push Notification Service Not Supported) response to the REGISTER request. If the proxy sends a SIP 555 (Push Notification Service Not Supported) response, the proxy SHOULD insert a Feature-Caps header field with a 'sip.pns' feature-capability indicator in the response, identifying each PNS that the proxy supports. I think you want to add: If the proxy receives a SIP 555 response to a REGISTER that it forwarded, it SHOULD insert such a 'sip.pns' feature-capability in the response before forwarding it to the UA, or if a 'sip.pns' feature-capability indicator already exists in the response, it SHOULD add to the indicator identifications of each PNS that the proxy supports that is not already present in the indicator. That way, if an upstream proxy generates a 555 response that lists one PNS, then this proxy can add to sip.pns the tag for the PNS that it supports, and the UA will be informed of both PNSs. It might be worth splitting the error code for "push notification service not supported" (section 5.3.1) from "push notification failed" (section 5.3.2). Given that the proposed text for 555 doesn't actually describe the usage in section 5.3.2, perhaps that usage should be changed to 556. More editorial items: sec 1 The UA will provide the PRID to the SIP proxy that will request push notifications towards the UA in a REGISTER request. "in a REGISTER request" seems to be not well anchored here, as it seems like it might attach to either "provide" or "request". Perhaps this is clearer: The UA will use a REGISTER request to provide the PRID to the SIP proxy that will request push notifications towards the UA. sec 4 In addition, if the response contains a Feature-Caps header field with a 'sip.vapid' feature-capability indicator, the UA can use the Voluntary Application Server Identification VAPID) mechanism [RFC8292] to restrict push notifications to the proxy (assuming that the PNS supports VAPID). I think you want to be more explict that 'sip.vapid' only indicates that the proxy supports VAPID. Perhaps: In addition, if the response contains a Feature-Caps header field with a 'sip.vapid' feature-capability indicator, the proxy supports use of the Voluntary Application Server Identification VAPID) mechanism [RFC8292] to restrict push notifications to the proxy. However, the use of VAPID also requires that the PNS supports VAPID, and determining that is the responsibility of the UA, not the proxy. 5.2. Trigger Periodic Re-registration The proxy either needs to be the SIP registrar, or the proxy needs to retrieve the information from the registrar using some other mechanism. Such mechanisms are outside the scope of this document. I think that "other" should be removed. Since there is no preceding mechanism mentioned, the mechanism mentioned in this sentence cannot be "other" relative to a preceding mechanism. Dale From nobody Sun Mar 18 13:18:40 2018 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 7F1D6126D73 for ; Sun, 18 Mar 2018 13:18:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 PN9vg2QyVec3 for ; Sun, 18 Mar 2018 13:18:29 -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 6140612AF84 for ; Sun, 18 Mar 2018 13:18:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1521404305; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=am+IsjuFOOBscNGUku407gdI5qPW0eprZD8xezP3ivw=; b=N4Sp9J95X3i02TCwYT2evoxUVNpbIi2Osf8eYRSSbvNAKwK5P2+XL00ecTf9BpGA QXrDiUOUbbN6HOItFyK+eu1NAKUuCFyL+W7sAo65HcpPo6CVlKssDmjX3FHS6rzc /jDY8IkM39O8p8fLiI60DKWsM18CXGX7bze6wIjDacE=; X-AuditID: c1b4fb2d-4b1ff70000005540-1d-5aaec9913316 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id A4.64.21824.199CEAA5; Sun, 18 Mar 2018 21:18:25 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.172]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0382.000; Sun, 18 Mar 2018 21:18:24 +0100 From: Christer Holmberg To: "Dale R. Worley" , "sipcore@ietf.org" Thread-Topic: [sipcore] More comments regarding draft-ietf-sipcore-sip-push-08 Thread-Index: AQHTvsHWpHdPl++8tEKnx3EX2XPJQqPWGYcw Date: Sun, 18 Mar 2018 20:18:23 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B6C20DC77@ESESSMB109.ericsson.se> References: <87in9t5vn4.fsf@hobgoblin.ariadne.com> In-Reply-To: <87in9t5vn4.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.166] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUyM2K7qO7Ek+uiDPqW8Vt8/bGJzeLliTIH Jo/J+78yeyxZ8pMpgCmKyyYlNSezLLVI3y6BK+POyoOMBb1qFa2Pj7M0MP6Q7WLk5JAQMJHo +PyYtYuRi0NI4DCjxOStv5kgnCWMEl8XPARyODjYBCwkuv9pgzSICARJbOpcwQxiCwv4Svyf f4wJIh4g0bHuBguEbSSx9EYzWA2LgKrEo33zWUFsXqD6hpOXwGwhoJqzzUcYQWxOAWOJwyef sYHYjAJiEt9PrQGbySwgLnHryXwmiEMFJJbsOc8MYYtKvHz8jxXCVpI4ehpiJrOAjsSC3Z/Y IGxtiWULXzND7BWUODnzCcsERpFZSMbOQtIyC0nLLCQtCxhZVjGKFqcWF+emGxnrpRZlJhcX 5+fp5aWWbGIERsPBLb91dzCufu14iFGAg1GJhzf/xLooIdbEsuLK3EOMEhzMSiK87nuBQrwp iZVVqUX58UWlOanFhxilOViUxHlPevJGCQmkJ5akZqemFqQWwWSZODilGhibRN4/e599xcBB 3nz9yUAu2YJNJ++UHn4vyiBY/vrLZYE5znZliyKl+o7uMeE8pNVjE1xScGW3zw1h1tX3L5XK Xn/NYNvFPlmveMvdj48PFKTeUlvWprezpnRKK9Oz+xHWx3aKH0wRn1c3gVtmDqfR9GkKL7X6 xQR/dX9QjWd60cSrt7/1kYYSS3FGoqEWc1FxIgBQAYHuggIAAA== Archived-At: Subject: Re: [sipcore] More comments regarding draft-ietf-sipcore-sip-push-08 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: Sun, 18 Mar 2018 20:18:37 -0000 Hi Dale, Thanks for your review! Please see inline. > sec 5.2 makes it sound like the proxy is required to wake up the UA if th= e registration is=20 >close to expiration, even if the UA registered with sip.pnsreg and the pro= xy responded=20 >with sip.pnsreg. Is that intended? Because it sounds like the behavior o= f the proxy does=20 >not change based on sip.pnsreg -- it wakes up the UA if the registration i= s near expiration. =20 >In which case, what does sip.pnsreg do? As compared with sec 4, where sip= .pnsreg seems=20 >to be the way that the UA and the proxy negotiate which one of them is rep= onsible for=20 >timing registrations. The difference in proxy behaviour is that, in case of sip.pnsreg, the proxy= waits until the "last minute" (120 seconds) for a re-registration before i= t triggers a notification request. This should only happen in error cases, = where the UA has indicated that it will send re-registrations but don't. In= normal cases the UA will send re-registrations, and there will be no need = for the proxy to request push notifications. > 5.3.1. REGISTER Request > > Otherwise, if the pn-provider SIP URI parameter identifies a PNS that > the proxy does not support, or if the REGISTER request does not > contain all additional information required for the specific PNS, the > proxy MUST either forward the request (e.g., if the proxy knows that > a downstream proxy supports the PNS) or send a SIP 555 (Push > Notification Service Not Supported) response to the REGISTER request. > If the proxy sends a SIP 555 (Push Notification Service Not > Supported) response, the proxy SHOULD insert a Feature-Caps header > field with a 'sip.pns' feature-capability indicator in the response, > identifying each PNS that the proxy supports. > > I think you want to add: > > If the proxy receives a SIP 555 response to a REGISTER that it > forwarded, it SHOULD insert such a 'sip.pns' feature-capability in > the response before forwarding it to the UA, or if a 'sip.pns' > feature-capability indicator already exists in the response, it > SHOULD add to the indicator identifications of each PNS that the > proxy supports that is not already present in the indicator. > > That way, if an upstream proxy generates a 555 response that lists one PN= S, then=20 > this proxy can add to sip.pns the tag for the PNS that it supports, and t= he UA will=20 > be informed of both PNSs. Good point. We can do that. > It might be worth splitting the error code for "push notification service= not supported" (section 5.3.1)=20 > from "push notification failed" (section 5.3.2). Given that the proposed= text for 555 doesn't actually=20 > describe the usage in section 5.3.2, perhaps that usage should be changed= to 556. I agree that would be useful. We can do that. > More editorial items: > > sec 1 > > The UA will provide the PRID to the SIP proxy that will request push > notifications towards the UA in a REGISTER request. > > "in a REGISTER request" seems to be not well anchored here, as it seems l= ike it might attach to either "provide" or "request". Perhaps this is clea= rer: > > The UA will use a REGISTER request to > provide the PRID to the SIP proxy that will request push > notifications towards the UA. Looks good. I will change as suggested. > sec 4 > > In addition, if the response contains a Feature-Caps header field > with a 'sip.vapid' feature-capability indicator, the UA can use the > Voluntary Application Server Identification VAPID) mechanism > [RFC8292] to restrict push notifications to the proxy (assuming that > the PNS supports VAPID). > > I think you want to be more explict that 'sip.vapid' only indicates that = the proxy supports VAPID. Perhaps: > > In addition, if the response contains a Feature-Caps header field > with a 'sip.vapid' feature-capability indicator, the proxy supports > use of the Voluntary Application Server Identification VAPID) > mechanism [RFC8292] to restrict push notifications to the proxy. > However, the use of VAPID also requires that the PNS supports > VAPID, and determining that is the responsibility of the UA, not > the proxy. Looks good. I will change as suggested. > 5.2. Trigger Periodic Re-registration > > The proxy either needs to be the SIP registrar, or the proxy needs to > retrieve the information from the registrar using some other > mechanism. Such mechanisms are outside the scope of this document. > > I think that "other" should be removed. Since there is no preceding mech= anism=20 > mentioned, the mechanism mentioned in this sentence cannot be "other" rel= ative=20 > to a preceding mechanism. I can remove "other". Thanks! Regards, Christer From nobody Mon Mar 19 02:26:35 2018 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 2DF46126DEE for ; Mon, 19 Mar 2018 02:26:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.686 X-Spam-Level: X-Spam-Status: No, score=-1.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 7-OIeu_0K_jP for ; Mon, 19 Mar 2018 02:26:33 -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 33410124B18 for ; Mon, 19 Mar 2018 02:26:33 -0700 (PDT) Received: from resomta-ch2-10v.sys.comcast.net ([69.252.207.106]) by resqmta-ch2-11v.sys.comcast.net with ESMTP id xr3keo1ONpYnCxr3neYe9z; Mon, 19 Mar 2018 09:26:31 +0000 Received: from hobgoblin.ariadne.com ([65.96.206.41]) by resomta-ch2-10v.sys.comcast.net with SMTP id xr3QeGG6Gk1Njxr3Re3LLU; Mon, 19 Mar 2018 09:26:09 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id w2J9Q8wh027281 for ; Mon, 19 Mar 2018 05:26:08 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id w2J9Q8BU027278; Mon, 19 Mar 2018 05:26:08 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: sipcore@ietf.org Sender: worley@ariadne.com (Dale R. Worley) Date: Mon, 19 Mar 2018 05:26:08 -0400 Message-ID: <87woy84dsf.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfDVuP/uugeauSVwWLt1ZwgZ83HxFXHQ9pOpoRAAadbTXYDi8eRFIYB4IbtQjatSOCmwbMF1E2yhyCPkxLTwGjMcifjvk4qndz+HfnzB1MuREOtWnjWLE NzsLcns+5GHqmljtBF2H9IkBzixryqtWvW0GOZnKysWo0FCxnnhNMuA9 Archived-At: Subject: [sipcore] sip-push: Recongizing the re-REGISTER 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, 19 Mar 2018 09:26:34 -0000 When there is an incoming request for a UA using sip-push, this paragraph in section 5.3.2 describes how it is to be processes: The push notification will trigger the UA to send a re-registration REGISTER request. The proxy will process the REGISTER request and the associated response as described in Section 5.3.1. In case of a 2xx response to the REGISTER request, once the proxy has forwarded the REGISTER response towards the UA, if the contact in the REGISTER response matches the Request-URI of the SIP request to be forwarded, the proxy can also forward the SIP request towards the UA, using normal SIP procedures. If the contact of the most recent REGISTER 2xx response and Request-URI do not match, the proxy MUST reject the SIP request with a 404 (Not Found) response. The last sentence, in particular, assumes that the proxy can reliably recognize which REGISTER request was sent by the UA, but the section doesn't describe how it does that. This needs to be spelled out, as almost all elements of the registration can change over time. In particular, the IP address can change as the UA moves between networks, or even sections of one network, and the PNS information may change (as detailed elsewhere in the draft). I can think of a number of approaches to this recognition, but they all seem to have deficiencies that block the use of sip-push in situations that I can imagine would want to use it. Dale From nobody Mon Mar 19 02:50:42 2018 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 4757412751F for ; Mon, 19 Mar 2018 02:50:41 -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_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=ericsson.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 ku0nBKoFYzPt for ; Mon, 19 Mar 2018 02:50:40 -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 DCA121270B4 for ; Mon, 19 Mar 2018 02:50:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1521453038; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=GbnQFHbWroV6fspR4y/3FV5axfa5XxD8iQhNZW0enMg=; b=MdoowxEuscNTWzqsze9ZSjG9ZzOQSn40FDPojOaQaBXbk7z36/umBbWMR3pEjZBG gR1Gl6smkBVEHheZy/RzGJehKqXczx6uJKDDYlaHdJWd11AgbEESij7OepOoKNF0 3VoKrYlq15ySzfwh66WYVheOZE+RofTzxP9UZkNcoew=; X-AuditID: c1b4fb2d-87c029c000005540-96-5aaf87eec8d4 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 7C.EA.21824.EE78FAA5; Mon, 19 Mar 2018 10:50:38 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.172]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0382.000; Mon, 19 Mar 2018 10:50:37 +0100 From: Christer Holmberg To: "sipcore@ietf.org" Thread-Topic: IETF#101: Session-timer slides Thread-Index: AdO/ZxYTW+Gr+7RqQ8muZoBFJ0+Hig== Date: Mon, 19 Mar 2018 09:50:36 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B6C20E97D@ESESSMB109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.164] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B6C20E97DESESSMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrGLMWRmVeSWpSXmKPExsUyM2J7lO679vVRBi2feS2+/tjE5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujOk9N9kKpktXXF7Xw9rAOEGii5GTQ0LARGLaoWdsXYxcHEIC hxklfsx4xw7hLGGUePl1PmMXIwcHm4CFRPc/bZAGEQFNieXftrKD2MIC6hJtF6YwQ8R1JD5M nMMKYetJzPn3CqyGRUBVYmFbA5jNK+Arcb7hCBOIzSggJvH91Bowm1lAXOLWk/lMEAcJSCzZ c54ZwhaVePn4HyuErSRx9ssUNoj6fInevrUsEDMFJU7OfMIygVFwFpJRs5CUzUJSBhHXkViw +xMbhK0tsWzha2YY+8yBx0zI4gsY2VcxihanFhfnphsZ66UWZSYXF+fn6eWllmxiBIb+wS2/ dXcwrn7teIhRgINRiYf3ZvX6KCHWxLLiytxDjBIczEoivE+vrIsS4k1JrKxKLcqPLyrNSS0+ xCjNwaIkznvSkzdKSCA9sSQ1OzW1ILUIJsvEwSnVwLjU7Yb+5RfHl2467/pG8mBfb7t3vae1 cFtZyJvus9lp0Yc6/8fEvk+7/1BEW6WOd8+Sl7qOblfMf6y/ZjfZcZ8mw85GpYObzQwWzHea 89JTyDLc9OjNVTWpn3+9e/WiykXygb4tx+5Z/W3/2tqVzrwITknc+e6Hyprvb1iMe9KFNJ7W LNMtuajEUpyRaKjFXFScCAA6CpZDeQIAAA== Archived-At: Subject: [sipcore] IETF#101: Session-timer slides 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, 19 Mar 2018 09:50:41 -0000 --_000_7594FB04B1934943A5C02806D1A2204B6C20E97DESESSMB109erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, As some people are going to participate remotely, before I upload the slide= s I have put the current version on GitHub. https://github.com/cdh4u/draft-sessiontimer-race/blob/master/IETF101_SIPCOR= E_SESSION-RACE.pdf We will discuss the technical stuff during the meeting, but if there is som= ething you think could be clarified then please let me know. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B6C20E97DESESSMB109erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

As some people are going to participate remotely, be= fore I upload the slides I have put the current version on GitHub.

 

https://github.com/cd= h4u/draft-sessiontimer-race/blob/master/IETF101_SIPCORE_SESSION-RACE.pdf

 

We will discuss the technical stuff during the meeti= ng, but if there is something you think could be clarified then please let = me know.

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B6C20E97DESESSMB109erics_-- From nobody Mon Mar 19 03:19:58 2018 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 602E3126DC2 for ; Mon, 19 Mar 2018 03:19:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 N1UHa43WToqI for ; Mon, 19 Mar 2018 03:19:55 -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 11A8A126CE8 for ; Mon, 19 Mar 2018 03:19:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1521454793; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=GUowagaS1vWVWK7imFT2eRD+BdQfswcwDZ8P365diug=; b=B1EOl6h847D/DfrCi9tCzs1JstRdG3j3Yb5LWv7gP20lQVBZAsRvM98M91NTeoSW Gtof8sLnVisuIoZ070VfNxMlAoAAd53gsqTdkY288sG7OoaQDF0zJy/gLkkxUXVg L0k/SiainZE1vVhpJoTc6tDqtuhhQ/IaiooVdX9jxFQ=; X-AuditID: c1b4fb30-6ebff7000000095a-60-5aaf8ec9d16a Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 65.F4.02394.9CE8FAA5; Mon, 19 Mar 2018 11:19:53 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.172]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0382.000; Mon, 19 Mar 2018 11:19:52 +0100 From: Christer Holmberg To: "Dale R. Worley" , "sipcore@ietf.org" Thread-Topic: [sipcore] sip-push: Recongizing the re-REGISTER Thread-Index: AQHTv2Rio3oD+jI3TEmHjc9qC5tyLaPXU5xw Date: Mon, 19 Mar 2018 10:19:52 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B6C20EADA@ESESSMB109.ericsson.se> References: <87woy84dsf.fsf@hobgoblin.ariadne.com> In-Reply-To: <87woy84dsf.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.164] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyM2K7ru7JvvVRBj+XCFp8/bGJzeLliTIH Jo/J+78yeyxZ8pMpgCmKyyYlNSezLLVI3y6BK+Pvo71sBTv5KlY+PsHSwLiKu4uRk0NCwERi z/8/TCC2kMBhRomWlw5djFxA9hJGiXUdn1i6GDk42AQsJLr/aYPUiAgESWzqXMEMYgsL2Ei0 XjzPChG3lZi8bAoTSLmIgJFEz3JZkDCLgKpE56rzbCA2r4CvRM/ejYwQq4wkLv15BraWU8BY YuKBRywgNqOAmMT3U2vA4swC4hK3nsxngjhTQGLJnvPMELaoxMvH/1ghbCWJs1+msEHU60gs 2P0JytaWWLbwNTPEXkGJkzOfsExgFJmFZOwsJC2zkLTMQtKygJFlFaNocWpxUm66kZFealFm cnFxfp5eXmrJJkZgJBzc8ttgB+PL546HGAU4GJV4eLNq1kcJsSaWFVfmHmKU4GBWEuF9emVd lBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXHek568UUIC6YklqdmpqQWpRTBZJg5OqQbGebvWpKSk Xlsn2HL6V9H8fYmamUs/ptxL9/wbMMOVK/7V3vZVOo7db/JfHufnvTbtoF3dV6n8T0If335k yDjY/1nrwSWLvxcKDsoxL9vs9aX+2RKDSfvcLlq9C8jllzUp6MiKOp+8Mjn7TNuUhdc0qmJY Uop1pTmE10Uzx0xgtJy/6kWO/FQxJZbijERDLeai4kQA9tRAHYACAAA= Archived-At: Subject: Re: [sipcore] sip-push: Recongizing the re-REGISTER 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, 19 Mar 2018 10:19:56 -0000 Hi Dale, Please see inline: > When there is an incoming request for a UA using sip-push, this paragraph= =20 > in section 5.3.2 describes how it is to be processes: > > The push notification will trigger the UA to send a re-registration > REGISTER request. The proxy will process the REGISTER request and > the associated response as described in Section 5.3.1. In case of a > 2xx response to the REGISTER request, once the proxy has forwarded > the REGISTER response towards the UA, if the contact in the REGISTER > response matches the Request-URI of the SIP request to be forwarded, > the proxy can also forward the SIP request towards the UA, using > normal SIP procedures. If the contact of the most recent REGISTER > 2xx response and Request-URI do not match, the proxy MUST reject the > SIP request with a 404 (Not Found) response. > > The last sentence, in particular, assumes that the proxy can reliably rec= ognize which REGISTER=20 > request was sent by the UA, but the section doesn't describe how it does = that. This needs to be=20 > spelled out, as almost all elements of the registration can change over t= ime. In particular, the IP=20 > address can change as the UA moves between networks, or even sections of = one network, and the=20 > PNS information may change (as detailed elsewhere in the draft). Note that the case where the R-URI and registered contact won't match is wh= en the registrar forwards an INVITE towards the proxy at the same time when= the UA sends a re-registration with a new contact. So, the R-URI of the IN= VITE will contain the "old" contact, while the 200 OK response to the REGIS= TER will contain the new contact. As far as matching the INVITE with the REGISTER, you can use the pn- parame= ters for that. Regards, Christer From nobody Mon Mar 19 04:55:20 2018 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 5A01212741D for ; Mon, 19 Mar 2018 04:55:19 -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, 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=ericsson.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 pTPp5jcjCp_o for ; Mon, 19 Mar 2018 04:55:18 -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 1488C124234 for ; Mon, 19 Mar 2018 04:55:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1521460516; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=kU1EcmlaWu9wzaHzPKreYhMZuE5jHEsxOI9YWouDMpA=; b=ByPwJMRgeqD/AZM5ehtWP1mOYO1lN/DNeIBbRg1Nj0yBnc07/rNswWy8Gt/9a9Cs 8zHbuNbyl+8FTpt8GUS1PgoIDrycBCg+GkMZdGQbjoGGzbrX+5C5c+k2Q0sV3DTB 0Ey2tlgSYPY7ThZipshUQx5RGiIrxc1jhbcYx0D6xQc=; X-AuditID: c1b4fb25-681ff70000006222-65-5aafa524a3f3 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id BB.4B.25122.425AFAA5; Mon, 19 Mar 2018 12:55:16 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.172]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0382.000; Mon, 19 Mar 2018 12:55:15 +0100 From: Christer Holmberg To: Christer Holmberg , "Dale R. Worley" , "sipcore@ietf.org" Thread-Topic: [sipcore] More comments regarding draft-ietf-sipcore-sip-push-08 - Pull request Thread-Index: AdO/eQ5I7FzMU/CISw2Amr+GohnAOw== Date: Mon, 19 Mar 2018 11:55:15 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B6C20F1F8@ESESSMB109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.164] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBLMWRmVeSWpSXmKPExsUyM2J7lK7K0vVRBjdPSFl8/bGJzeLliTIH Jo/J+78yeyxZ8pMpgCmKyyYlNSezLLVI3y6BK+P31o3sBd+4K7o7XrA1MO7j7GLk5JAQMJH4 8uEbSxcjF4eQwGFGib3TWpghnCWMEitfNzN1MXJwsAlYSHT/0waJiwi0MUrcuNnIDNItLBAn ce7zBhYQW0QgXmLV4WmMELaexM4nG1hBbBYBVYmFU9+B2bwCvhJbn2wFq2EUEJP4fmoNE4jN LCAucevJfCaIiwQkluw5zwxhi0q8fPyPFcJWkjj7ZQobRL2OxILdn6BsbYllC18zQ8wXlDg5 8wnLBEahWUjGzkLSMgtJyywkLQsYWVYxihanFiflphsZ66UWZSYXF+fn6eWllmxiBIb3wS2/ VXcwXn7jeIhRgINRiYf3yMT1UUKsiWXFlbmHGCU4mJVEeJ9eWRclxJuSWFmVWpQfX1Sak1p8 iFGag0VJnHeOcHuUkEB6YklqdmpqQWoRTJaJg1OqgTFsiWCe3bzLt1i9Qm3u3olelqn9hEss 88OlzynaypsmxpxkYGiU1HmZs1P0jWjhNfV9Iiy3J6/0s9j+yyntuFLTEuvfDFcdp1ldPvNU z55LQcJ//berF4o6bIX+vjVocWiRPjnX0bv/Kt/8w7uXqOpEhmrVqs2fu+yVoP7B+24J0/rU Guo14pVYijMSDbWYi4oTAYxnkKprAgAA Archived-At: Subject: Re: [sipcore] More comments regarding draft-ietf-sipcore-sip-push-08 - Pull request 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, 19 Mar 2018 11:55:19 -0000 Hi, I have created a pull request based on Dale's comments. https://github.com/cdh4u/draft-sip-push/pull/16 However, below is one change I previously agreed to, but realized it goes a= gainst the original intention: ... >> sec 4 >> >> In addition, if the response contains a Feature-Caps header field >> with a 'sip.vapid' feature-capability indicator, the UA can use the >> Voluntary Application Server Identification VAPID) mechanism >> [RFC8292] to restrict push notifications to the proxy (assuming that >> the PNS supports VAPID). >> >> I think you want to be more explict that 'sip.vapid' only indicates that= the=20 >> proxy supports VAPID. Perhaps: >> >> In addition, if the response contains a Feature-Caps header field >> with a 'sip.vapid' feature-capability indicator, the proxy supports >> use of the Voluntary Application Server Identification VAPID) >> mechanism [RFC8292] to restrict push notifications to the proxy. >> However, the use of VAPID also requires that the PNS supports >> VAPID, and determining that is the responsibility of the UA, not >> the proxy. My original assumption was that the proxy will indicate support of VAPID if= it knows that the PNS supports VAPID. That is indicated in "will use", but= I guess that the text could be clarified. "if the proxy supports the VAPID mechanism, knows that the mechanism is sup= ported by the PNS, and the proxy will use the mechanism, the proxy MUST..." Regards, Christer From nobody Mon Mar 19 08:27:04 2018 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 7F4EC127863 for ; Mon, 19 Mar 2018 08:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 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, URIBL_BLOCKED=0.001] 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 yBz-rtnzb51z for ; Mon, 19 Mar 2018 08:27:01 -0700 (PDT) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3579812E76A for ; Mon, 19 Mar 2018 08:26:58 -0700 (PDT) Received: by mail-pf0-x22c.google.com with SMTP id y186so7148314pfb.2 for ; Mon, 19 Mar 2018 08:26:58 -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=yqfOK/sQmBp5vb9zQ5jY53rKMOHzdNCHekw7beECxH4=; b=eRjStccdi9BS/jBDUWhmi6LOlogxE8HBwGI9/WHoF6ZbUWNcDpjvLGqi0ExIU1E4Y8 /rYdupSFTN7m+BRgYHz1EgH9Gq29ULpA3GIhXNS8GUU3NZc6pmY+8ZfKzR0Jrq4PzJJF kw/Sml1wPd+0hoHrLqGumfBjJyWpcwYer//DG6C+R1OuQfdhU4AS22CIOIm9Ek6wVugq yHPjU9vvY0GjRN9mzN/lq2PBZ/Tikz8uno7if8idhHIR/4CvOwzOC3l378G8qF0k4ZRC jWZq5kkk9GuHFpYnEU6hMa8cG+CLrSIVAwM71t/Glr79S2EHdevpWsF+TvpS6yAjnRhP RaYA== 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=yqfOK/sQmBp5vb9zQ5jY53rKMOHzdNCHekw7beECxH4=; b=VDCWkJFaMeIYciyYyk5/8hFOaRsbh1D7Lb53yC/k9J0zGyU+eT16UvklLeaKQMyazM ZRIs0X4L2J2RO937yf3iMWjRlP3G8kh20AJYv5+yfPCh7gqI9GTCXOy9ngBvau2wNJin BQZZgmmfFKqRHl9yndODSQIiEsYcvPFX0DZtpLYfvgLpVmzj3ib6CKJDJCw/2/NcZh82 gIIo/e40wI1fvKFphHCiIhFko1PPYZI/EHXoWCbNGvaXqTXeviNDnnVEkTwTdkp14c6X OEZ29fC+dYed9nfajkSFSKGvpf179ZAMBGdkQBu7+3yUi2EU1fbhucuv24UVN+bNijG2 RaaA== X-Gm-Message-State: AElRT7HCx2un1QBoy75awdNbXp9z/JcZi4xRPc10VdVvqlYUN1q3s+MC Jdkh+fLJdL+QOVouhNUm8nFmCb1g X-Google-Smtp-Source: AG47ELsHvQiP5bIC4Rx4BqtsgO2f7MgOumVbHe+tDn97AzXnH/U9gMCpLkb0GDUnfN+XkoUNH9M9UA== X-Received: by 10.98.134.10 with SMTP id x10mr10599062pfd.78.1521473217634; Mon, 19 Mar 2018 08:26:57 -0700 (PDT) Received: from mail-pl0-f47.google.com (mail-pl0-f47.google.com. [209.85.160.47]) by smtp.gmail.com with ESMTPSA id m13sm460745pgs.25.2018.03.19.08.26.56 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Mar 2018 08:26:56 -0700 (PDT) Received: by mail-pl0-f47.google.com with SMTP id c11-v6so10429224plo.0 for ; Mon, 19 Mar 2018 08:26:56 -0700 (PDT) X-Received: by 2002:a17:902:ab84:: with SMTP id f4-v6mr13184153plr.239.1521473216323; Mon, 19 Mar 2018 08:26:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.156.15 with HTTP; Mon, 19 Mar 2018 08:26:55 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C20EADA@ESESSMB109.ericsson.se> References: <87woy84dsf.fsf@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B6C20EADA@ESESSMB109.ericsson.se> From: Roman Shpount Date: Mon, 19 Mar 2018 11:26:55 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Christer Holmberg Cc: "Dale R. Worley" , "sipcore@ietf.org" Content-Type: multipart/alternative; boundary="0000000000009825590567c59658" Archived-At: Subject: Re: [sipcore] sip-push: Recongizing the re-REGISTER 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, 19 Mar 2018 15:27:03 -0000 --0000000000009825590567c59658 Content-Type: text/plain; charset="UTF-8" On Mon, Mar 19, 2018 at 6:19 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi Dale, > > Please see inline: > > > When there is an incoming request for a UA using sip-push, this paragraph > > in section 5.3.2 describes how it is to be processes: > > > > The push notification will trigger the UA to send a re-registration > > REGISTER request. The proxy will process the REGISTER request and > > the associated response as described in Section 5.3.1. In case of a > > 2xx response to the REGISTER request, once the proxy has forwarded > > the REGISTER response towards the UA, if the contact in the REGISTER > > response matches the Request-URI of the SIP request to be forwarded, > > the proxy can also forward the SIP request towards the UA, using > > normal SIP procedures. If the contact of the most recent REGISTER > > 2xx response and Request-URI do not match, the proxy MUST reject the > > SIP request with a 404 (Not Found) response. > > > > The last sentence, in particular, assumes that the proxy can reliably > recognize which REGISTER > > request was sent by the UA, but the section doesn't describe how it does > that. This needs to be > > spelled out, as almost all elements of the registration can change over > time. In particular, the IP > > address can change as the UA moves between networks, or even sections of > one network, and the > > PNS information may change (as detailed elsewhere in the draft). > > Note that the case where the R-URI and registered contact won't match is > when the registrar forwards an INVITE towards the proxy at the same time > when the UA sends a re-registration with a new contact. So, the R-URI of > the INVITE will contain the "old" contact, while the 200 OK response to the > REGISTER will contain the new contact. > > As far as matching the INVITE with the REGISTER, you can use the pn- > parameters for that. > Would this be better implemented by using RFC 3327 Path registration extension? SIP Push proxy can include a parameter in the Path URL so that it can match the inbound registration with all the requests that Registrar will send for this registration. Regards, _____________ Roman Shpount --0000000000009825590567c59658 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Dale,

Please see inline:

> When there is an incoming request for a UA using sip-push, this paragr= aph
> in section 5.3.2 describes how it is to be processes:
>
>=C2=A0 =C2=A0The push notification will trigger the UA to send a re-reg= istration
>=C2=A0 =C2=A0REGISTER request.=C2=A0 The proxy will process the REGISTE= R request and
>=C2=A0 =C2=A0the associated response as described in Section 5.3.1.=C2= =A0 In case of a
>=C2=A0 =C2=A02xx response to the REGISTER request, once the proxy has f= orwarded
>=C2=A0 =C2=A0the REGISTER response towards the UA, if the contact in th= e REGISTER
>=C2=A0 =C2=A0response matches the Request-URI of the SIP request to be = forwarded,
>=C2=A0 =C2=A0the proxy can also forward the SIP request towards the UA,= using
>=C2=A0 =C2=A0normal SIP procedures.=C2=A0 If the contact of the most re= cent REGISTER
>=C2=A0 =C2=A02xx response and Request-URI do not match, the proxy MUST = reject the
>=C2=A0 =C2=A0SIP request with a 404 (Not Found) response.
>
> The last sentence, in particular, assumes that the proxy can reliably = recognize which REGISTER
> request was sent by the UA, but the section doesn't describe how i= t does that.=C2=A0 This needs to be
> spelled out, as almost all elements of the registration can change ove= r time.=C2=A0 In particular, the IP
> address can change as the UA moves between networks, or even sections = of one network, and the
> PNS information may change (as detailed elsewhere in the draft).

Note that the case where the R-URI and registered contact won't = match is when the registrar forwards an INVITE towards the proxy at the sam= e time when the UA sends a re-registration with a new contact. So, the R-UR= I of the INVITE will contain the "old" contact, while the 200 OK = response to the REGISTER will contain the new contact.

As far as matching the INVITE with the REGISTER, you can use the pn- parame= ters for that.

Would this be better implemen= ted by using RFC 3327 Path registration extension? SIP Push proxy can inclu= de a parameter in the Path URL so that it can match the inbound registratio= n with all the requests that Registrar will send for this registration.

Regards,<= br>
<= div class=3D"gmail_signature">_____________
Roman Shpount
=C2=A0
--0000000000009825590567c59658-- From nobody Mon Mar 19 09:48:42 2018 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 7DF5E127201 for ; Mon, 19 Mar 2018 09:48:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 n_boK4GRsXFG for ; Mon, 19 Mar 2018 09:48: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 1D81C128959 for ; Mon, 19 Mar 2018 09:48:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1521478111; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=NhOs7v6o/kvMby9JnQZxFz6KoHxHDlX4U/vzmjHti48=; b=C6UmC3YevdbwLl+ugWBiqMqGryH/8qlLDvdf7q7or6LviUa3PxljaMM6VpmN4SvZ nsktS4c5N37jWjGLW8E3IQjEz+YtOyQ+GlQKZK3a3y5LQ7ueaqoczAK73rSf2hwH Ul0REV/tg4giRdM62tCOhRCycJL7p64kSdDbpzEvQyE=; X-AuditID: c1b4fb3a-347ff700000067b4-77-5aafe9df96fc Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 13.97.26548.FD9EFAA5; Mon, 19 Mar 2018 17:48:31 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.172]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0382.000; Mon, 19 Mar 2018 17:48:30 +0100 From: Christer Holmberg To: Roman Shpount CC: "Dale R. Worley" , "sipcore@ietf.org" Thread-Topic: [sipcore] sip-push: Recongizing the re-REGISTER Thread-Index: AQHTv2Rio3oD+jI3TEmHjc9qC5tyLaPXU5xwgABKRICAACM1cA== Date: Mon, 19 Mar 2018 16:48:30 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B6C20FF2A@ESESSMB109.ericsson.se> References: <87woy84dsf.fsf@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B6C20EADA@ESESSMB109.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.171] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpikeLIzCtJLcpLzFFi42KZGbFdUff+y/VRBpOuSFvMuDCV2eLrj01s Fi9PlDkwe0ze/5XZY8mSn0wet6YUBDBHcdmkpOZklqUW6dslcGXMu3WOqeCbZMXrztXsDYwL JLsYOTkkBEwk/rXdY+1i5OIQEjjMKLH03BY2CGcJo8T8+d/Zuxg5ONgELCS6/2mDNIgIqEr8 /T6ZCcRmFgiSaP68ghHEFhawkWi9eJ4VosZWYvKyKUwQtpNE7+87LCBjWIB6e/bIgIR5BXwl 7re9YIJYtZdR4sTRG8wgCU6BQIlj3w+D2YwCYhLfT62B2iUucevJfCaIowUkluw5zwxhi0q8 fPyPFcJWkjjxsJEZZBezgKbE+l36EK2KElO6H7JD7BWUODnzCcsERtFZSKbOQuiYhaRjFpKO BYwsqxhFi1OLi3PTjYz0Uosyk4uL8/P08lJLNjECY+bglt9WOxgPPnc8xCjAwajEw5t0c32U EGtiWXFl7iFGCQ5mJRHep1fWRQnxpiRWVqUW5ccXleakFh9ilOZgURLndUqziBISSE8sSc1O TS1ILYLJMnFwSjUwxpw7wtKzpirr09uz5i9slAW5l9wVysnYc0qt6fz939edpq2Yecld7492 pfVX/SeXt1vaHg9ROdVx/nf/jKe7dly5o3Mxv1tmetzkWStz9Bd2Vgl0XbiT7Fmyplnyq3jI D7eLEw/y7TtbuHrF8rxJnN4vb0yrDp3ge+Xzq4j96ua7Pl/+F5PitUmJpTgj0VCLuag4EQA2 gWVwlQIAAA== Archived-At: Subject: Re: [sipcore] sip-push: Recongizing the re-REGISTER 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, 19 Mar 2018 16:48:37 -0000 SGksDQoNCj4+IFdoZW4gdGhlcmUgaXMgYW4gaW5jb21pbmcgcmVxdWVzdCBmb3IgYSBVQSB1c2lu ZyBzaXAtcHVzaCwgdGhpcyBwYXJhZ3JhcGgNCj4+IGluIHNlY3Rpb24gNS4zLjIgZGVzY3JpYmVz IGhvdyBpdCBpcyB0byBiZSBwcm9jZXNzZXM6DQo+Pg0KPj7CoCDCoFRoZSBwdXNoIG5vdGlmaWNh dGlvbiB3aWxsIHRyaWdnZXIgdGhlIFVBIHRvIHNlbmQgYSByZS1yZWdpc3RyYXRpb24NCj4+wqAg wqBSRUdJU1RFUiByZXF1ZXN0LsKgIFRoZSBwcm94eSB3aWxsIHByb2Nlc3MgdGhlIFJFR0lTVEVS IHJlcXVlc3QgYW5kDQo+PsKgIMKgdGhlIGFzc29jaWF0ZWQgcmVzcG9uc2UgYXMgZGVzY3JpYmVk IGluIFNlY3Rpb24gNS4zLjEuwqAgSW4gY2FzZSBvZiBhDQo+PsKgIMKgMnh4IHJlc3BvbnNlIHRv IHRoZSBSRUdJU1RFUiByZXF1ZXN0LCBvbmNlIHRoZSBwcm94eSBoYXMgZm9yd2FyZGVkDQo+PsKg IMKgdGhlIFJFR0lTVEVSIHJlc3BvbnNlIHRvd2FyZHMgdGhlIFVBLCBpZiB0aGUgY29udGFjdCBp biB0aGUgUkVHSVNURVINCj4+wqAgwqByZXNwb25zZSBtYXRjaGVzIHRoZSBSZXF1ZXN0LVVSSSBv ZiB0aGUgU0lQIHJlcXVlc3QgdG8gYmUgZm9yd2FyZGVkLA0KPj7CoCDCoHRoZSBwcm94eSBjYW4g YWxzbyBmb3J3YXJkIHRoZSBTSVAgcmVxdWVzdCB0b3dhcmRzIHRoZSBVQSwgdXNpbmcNCj4+wqAg wqBub3JtYWwgU0lQIHByb2NlZHVyZXMuwqAgSWYgdGhlIGNvbnRhY3Qgb2YgdGhlIG1vc3QgcmVj ZW50IFJFR0lTVEVSDQo+PsKgIMKgMnh4IHJlc3BvbnNlIGFuZCBSZXF1ZXN0LVVSSSBkbyBub3Qg bWF0Y2gsIHRoZSBwcm94eSBNVVNUIHJlamVjdCB0aGUNCj4+wqAgwqBTSVAgcmVxdWVzdCB3aXRo IGEgNDA0IChOb3QgRm91bmQpIHJlc3BvbnNlLg0KPj4NCj4+IFRoZSBsYXN0IHNlbnRlbmNlLCBp biBwYXJ0aWN1bGFyLCBhc3N1bWVzIHRoYXQgdGhlIHByb3h5IGNhbiByZWxpYWJseSByZWNvZ25p emUgd2hpY2ggUkVHSVNURVINCj4+IHJlcXVlc3Qgd2FzIHNlbnQgYnkgdGhlIFVBLCBidXQgdGhl IHNlY3Rpb24gZG9lc24ndCBkZXNjcmliZSBob3cgaXQgZG9lcyB0aGF0LsKgIFRoaXMgbmVlZHMg dG8gYmUNCj4+IHNwZWxsZWQgb3V0LCBhcyBhbG1vc3QgYWxsIGVsZW1lbnRzIG9mIHRoZSByZWdp c3RyYXRpb24gY2FuIGNoYW5nZSBvdmVyIHRpbWUuwqAgSW4gcGFydGljdWxhciwgdGhlIElQDQo+ PiBhZGRyZXNzIGNhbiBjaGFuZ2UgYXMgdGhlIFVBIG1vdmVzIGJldHdlZW4gbmV0d29ya3MsIG9y IGV2ZW4gc2VjdGlvbnMgb2Ygb25lIG5ldHdvcmssIGFuZCB0aGUNCj4+IFBOUyBpbmZvcm1hdGlv biBtYXkgY2hhbmdlIChhcyBkZXRhaWxlZCBlbHNld2hlcmUgaW4gdGhlIGRyYWZ0KS4NCj4+DQo+ PiBOb3RlIHRoYXQgdGhlIGNhc2Ugd2hlcmUgdGhlIFItVVJJIGFuZCByZWdpc3RlcmVkIGNvbnRh Y3Qgd29uJ3QgbWF0Y2ggaXMgd2hlbiB0aGUgcmVnaXN0cmFyIGZvcndhcmRzIGFuIA0KPj4gSU5W SVRFIHRvd2FyZHMgdGhlIHByb3h5IGF0IHRoZSBzYW1lIHRpbWUgd2hlbiB0aGUgVUEgc2VuZHMg YSByZS1yZWdpc3RyYXRpb24gd2l0aCBhIG5ldyBjb250YWN0LiBTbywgdGhlIA0KPj4gUi1VUkkg b2YgdGhlIElOVklURSB3aWxsIGNvbnRhaW4gdGhlICJvbGQiIGNvbnRhY3QsIHdoaWxlIHRoZSAy MDAgT0sgcmVzcG9uc2UgdG8gdGhlIFJFR0lTVEVSIHdpbGwgY29udGFpbiANCj4+IHRoZSBuZXcg Y29udGFjdC4NCj4+DQo+PiBBcyBmYXIgYXMgbWF0Y2hpbmcgdGhlIElOVklURSB3aXRoIHRoZSBS RUdJU1RFUiwgeW91IGNhbiB1c2UgdGhlIHBuLSBwYXJhbWV0ZXJzIGZvciB0aGF0Lg0KPg0KPiBX b3VsZCB0aGlzIGJlIGJldHRlciBpbXBsZW1lbnRlZCBieSB1c2luZyBSRkMgMzMyNyBQYXRoIHJl Z2lzdHJhdGlvbiBleHRlbnNpb24/IFNJUCBQdXNoIHByb3h5IGNhbg0KPiBpbmNsdWRlIGEgcGFy YW1ldGVyIGluIHRoZSBQYXRoIFVSTCBzbyB0aGF0IGl0IGNhbiBtYXRjaCB0aGUgaW5ib3VuZCBy ZWdpc3RyYXRpb24gd2l0aCBhbGwgdGhlIHJlcXVlc3RzDQo+IHRoYXQgUmVnaXN0cmFyIHdpbGwg c2VuZCBmb3IgdGhpcyByZWdpc3RyYXRpb24uDQoNCldoeSB3b3VsZCB0aGF0IGJlICJiZXR0ZXIi PyANCg0KSSBhbSBub3QgZXZlbiBzdXJlIGhvdyBpdCB3b3VsZCB3b3JrLiBXaGVuIHRoZSBwcm94 eSByZWNlaXZlcyBhbiBJTlZJVEUsIGFuZCByZXF1ZXN0cyBhIHB1c2ggbm90aWZpY2F0aW9uLCB0 aGUgUkVHSVNURVIgZnJvbSB0aGUgVUEgaXMgbm90IGdvaW5nIHRvIGNvbnRhaW4gdGhlIFBhdGgg aW5mb3JtYXRpb24uIA0KDQpJbiBhZGRpdGlvbiwgdXNhZ2Ugb2YgUGF0aCByZXF1aXJlcyBzdXBw b3J0IGJ5IHRoZSByZWdpc3RyYXIuDQoNClVzYWdlIG9mIHBuLSBwYXJhbWV0ZXIgd29ya3MgZmlu ZS4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg== From nobody Mon Mar 19 11:17:42 2018 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 BD39812D873 for ; Mon, 19 Mar 2018 11:17:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 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, URIBL_BLOCKED=0.001] 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 8Yhgk5Ox9LKQ for ; Mon, 19 Mar 2018 11:17:39 -0700 (PDT) Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e:c05::230]) (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 1C2B612946D for ; Mon, 19 Mar 2018 11:17:39 -0700 (PDT) Received: by mail-pg0-x230.google.com with SMTP id m24so1547415pgv.8 for ; Mon, 19 Mar 2018 11:17:39 -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=zs8JXOH+Fq+XBGJfGPmolTnZCWJvXZk4fIBReNAjSjM=; b=zvar3PdXDVw4dHIylvL3thLudHwQb2KTU9pDGq969j3iuPuPUsf62sl8VXEkU1HqLd 1qvGf0hdqevkmMetBrEkJMrMTIbTYvCHx7cqUOVDFDCxt8uxE4gfardFjuTXp22flrCk 6dtxTH79gq7RNIhAUi5VPR/nmuhdnL//Csxin0Y1iBGEljs36si5WrSy1lYocZ67yqgL iyFSO719NmQmdCPNHEXR247YfUmdb8mZzt7JfUu0F9O2WS6RQ5FhGBSIyDrs0Kn0Cds1 BOjtsP8qnqKx8IuAK2A0rglTkh1HUFuBti9sA1xknRr19twuOzszfH5FKGld70WL4WMk IcGQ== 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=zs8JXOH+Fq+XBGJfGPmolTnZCWJvXZk4fIBReNAjSjM=; b=kbKOn/d9rCICoy+phkxZUpBHF0r1iamYtbQbXkDL+yPxQJd+qYN6aBxQrOQsK3/W0/ IfzdZKmSg8y/jyQKvEGIUOhRFN8Nchg0yiqPymWbtflFbtaqppcM2oP74qnisYMUoD4s oFqWG/pLmEqCAacK0uYoHRooRzgFTIapvg8LpY5vtAR4szxon8dRZjDlmV2jMIEOxJbH /cJo/12d/K0nx+Ht74F830q008Tk1O1U4YqDCObek6QET8bt2V3IRStSnEOOJjM+R29x OcILMvYQaKyeG+5o0wM7xPSMSsL0Fko5FHQ23NxzAwasNdWEQSRHECXe/99ZwDH4iRLB 4++A== X-Gm-Message-State: AElRT7H4AIpitAn1sQvR4FU2XSIygQTeNq8DaBKFK7kegUAN0M8jC+8L /9/IJM5v/voHzWkL/cJKuu0ZlHhN X-Google-Smtp-Source: AG47ELvLl0XY0wLe/um39X75xjS3e/Igy9a+kY+sQxvTEDevI/EBjA5Hwg+kLCH7H/ly3HaCVAZD6Q== X-Received: by 10.98.15.92 with SMTP id x89mr4459903pfi.7.1521483458350; Mon, 19 Mar 2018 11:17:38 -0700 (PDT) Received: from mail-pl0-f49.google.com (mail-pl0-f49.google.com. [209.85.160.49]) by smtp.gmail.com with ESMTPSA id i12sm920337pgr.9.2018.03.19.11.17.36 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Mar 2018 11:17:36 -0700 (PDT) Received: by mail-pl0-f49.google.com with SMTP id f23-v6so10739509plr.10 for ; Mon, 19 Mar 2018 11:17:36 -0700 (PDT) X-Received: by 2002:a17:902:8b82:: with SMTP id ay2-v6mr13163911plb.12.1521483456386; Mon, 19 Mar 2018 11:17:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.156.15 with HTTP; Mon, 19 Mar 2018 11:17:35 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C20FF2A@ESESSMB109.ericsson.se> References: <87woy84dsf.fsf@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B6C20EADA@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C20FF2A@ESESSMB109.ericsson.se> From: Roman Shpount Date: Mon, 19 Mar 2018 14:17:35 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Christer Holmberg Cc: "Dale R. Worley" , "sipcore@ietf.org" Content-Type: multipart/alternative; boundary="000000000000f31ba90567c7f856" Archived-At: Subject: Re: [sipcore] sip-push: Recongizing the re-REGISTER 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, 19 Mar 2018 18:17:42 -0000 --000000000000f31ba90567c7f856 Content-Type: text/plain; charset="UTF-8" On Mon, Mar 19, 2018 at 12:48 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > >> When there is an incoming request for a UA using sip-push, this > paragraph > >> in section 5.3.2 describes how it is to be processes: > >> > >> The push notification will trigger the UA to send a re-registration > >> REGISTER request. The proxy will process the REGISTER request and > >> the associated response as described in Section 5.3.1. In case of a > >> 2xx response to the REGISTER request, once the proxy has forwarded > >> the REGISTER response towards the UA, if the contact in the REGISTER > >> response matches the Request-URI of the SIP request to be forwarded, > >> the proxy can also forward the SIP request towards the UA, using > >> normal SIP procedures. If the contact of the most recent REGISTER > >> 2xx response and Request-URI do not match, the proxy MUST reject the > >> SIP request with a 404 (Not Found) response. > >> > >> The last sentence, in particular, assumes that the proxy can reliably > recognize which REGISTER > >> request was sent by the UA, but the section doesn't describe how it > does that. This needs to be > >> spelled out, as almost all elements of the registration can change over > time. In particular, the IP > >> address can change as the UA moves between networks, or even sections > of one network, and the > >> PNS information may change (as detailed elsewhere in the draft). > >> > >> Note that the case where the R-URI and registered contact won't match > is when the registrar forwards an > >> INVITE towards the proxy at the same time when the UA sends a > re-registration with a new contact. So, the > >> R-URI of the INVITE will contain the "old" contact, while the 200 OK > response to the REGISTER will contain > >> the new contact. > >> > >> As far as matching the INVITE with the REGISTER, you can use the pn- > parameters for that. > > > > Would this be better implemented by using RFC 3327 Path registration > extension? SIP Push proxy can > > include a parameter in the Path URL so that it can match the inbound > registration with all the requests > > that Registrar will send for this registration. > > Why would that be "better"? > > I am not even sure how it would work. When the proxy receives an INVITE, > and requests a push notification, the REGISTER from the UA is not going to > contain the Path information. > > In addition, usage of Path requires support by the registrar. > > Usage of pn- parameter works fine. > > We might also be talking about different things. I was talking about matching of dialog creating request received by the edge proxy with an existing registration. You might also be talking about matching the new Registration from the client to the pending dialog creating request. Our implementation was based on SIP Outbound and supported sip.instance and registration path extensions from the start. When registration was received from client UA, flow from the UA was stored in-memory on the edge proxy together with sip-instance, reg-id, and push notification information. Key for this in-memory DB entry was inserted in opaque parameter in Path header added to registration message. When new request was received by the edge proxy, the same opaque parameter would be present in the Route header. Edge proxy would lookup if active flow was still present to the UA. If the flow was present, the message would be immediately sent. If no flow was present, message was queued in the in-memory DB on this flow entry and new push notification was triggered. When new Registration was received, it was matched against the in-memory DB based on sip-instance and reg-id. When 200 OK for this Registration was received, flow information for this flow entry would get updated and if queued message were stored on this flow entry they will be sent to UA. This is, of cause simplified, since our implementation also dealt with sip flow expiration and flow probation (from the time Registration was received until 200 OK was received from the registrar flow was stored but not used). >From implementation stand point I see two possible ways SIP push can be implemented: 1. An implementation where edge proxy and registration server are part of the same system. They use an internal mechanism to exchange data about registration, push, and queued SIP messages. It would also likely assume that only one UA is registered per AOR. In this case registration is matched to pending requests using AOR. SIP Outbound is not used and NAT binding is maintained during the call using SIP Session timer with short expiration time. This implenetation will not track flows to the UA, and will likely need to use push for each dialog creating or non-dialog message. 2. An implementation where edge proxy and registration server are separate and communicate through standard communication mechanisms. For this registration path extension and sip-instance are used to associate dialog creating and non-dialog messages with registrations and push parameters. This implementation would deal with multiple registrations per AOR and clients changing IPs. It would also use SIP Outbound keep alive to maintain flows to the client when client UA is active and only use SIP Push to re-establish flows when SIP UA is suspended. I think SIP Outbound implementation is better since it is more efficient and deals with more scenarios (client IP changes). Path extension is pretty much required if separate edge proxies are used with separate Registration server. I see how "simpler" solution can be developed for an integrated edge proxy and registrar, but when these component are separate, something like Path extension and sip.instance will be needed. Regards, _____________ Roman Shpount --000000000000f31ba90567c7f856 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Mon, Mar 19, 2018 at 12:48 PM, Christer Ho= lmberg <christer.holmberg@ericsson.com> wr= ote:
Hi,

>> When there is an incoming request for a UA using sip-push, this pa= ragraph
>> in section 5.3.2 describes how it is to be processes:
>>
>>=C2=A0 =C2=A0The push notification will trigger the UA to send a re= -registration
>>=C2=A0 =C2=A0REGISTER request.=C2=A0 The proxy will process the REG= ISTER request and
>>=C2=A0 =C2=A0the associated response as described in Section 5.3.1.= =C2=A0 In case of a
>>=C2=A0 =C2=A02xx response to the REGISTER request, once the proxy h= as forwarded
>>=C2=A0 =C2=A0the REGISTER response towards the UA, if the contact i= n the REGISTER
>>=C2=A0 =C2=A0response matches the Request-URI of the SIP request to= be forwarded,
>>=C2=A0 =C2=A0the proxy can also forward the SIP request towards the= UA, using
>>=C2=A0 =C2=A0normal SIP procedures.=C2=A0 If the contact of the mos= t recent REGISTER
>>=C2=A0 =C2=A02xx response and Request-URI do not match, the proxy M= UST reject the
>>=C2=A0 =C2=A0SIP request with a 404 (Not Found) response.
>>
>> The last sentence, in particular, assumes that the proxy can relia= bly recognize which REGISTER
>> request was sent by the UA, but the section doesn't describe h= ow it does that.=C2=A0 This needs to be
>> spelled out, as almost all elements of the registration can change= over time.=C2=A0 In particular, the IP
>> address can change as the UA moves between networks, or even secti= ons of one network, and the
>> PNS information may change (as detailed elsewhere in the draft). >>
>> Note that the case where the R-URI and registered contact won'= t match is when the registrar forwards an
>> INVITE towards the proxy at the same time when the UA sends a re-r= egistration with a new contact. So, the
>> R-URI of the INVITE will contain the "old" contact, whil= e the 200 OK response to the REGISTER will contain
>> the new contact.
>>
>> As far as matching the INVITE with the REGISTER, you can use the p= n- parameters for that.
>
> Would this be better implemented by using RFC 3327 Path registration e= xtension? SIP Push proxy can
> include a parameter in the Path URL so that it can match the inbound r= egistration with all the requests
> that Registrar will send for this registration.

Why would that be "better"?

I am not even sure how it would work. When the proxy receives an INVITE, an= d requests a push notification, the REGISTER from the UA is not going to co= ntain the Path information.

In addition, usage of Path requires support by the registrar.

Usage of pn- parameter works fine.


We might also be talking about differe= nt things. I was talking about matching of dialog creating request received= by the edge proxy with an existing registration. You might also be talking= about matching the new Registration from the client to the pending dialog = creating request.

Our implementation was based= on SIP Outbound and supported sip.instance and registration path extension= s from the start. When registration was received from client UA, flow from = the UA was stored in-memory on the edge proxy together with sip-instance, r= eg-id, and push notification information. Key for this in-memory DB entry w= as inserted in opaque parameter in Path header added to registration messag= e. When new request was received by the edge proxy, the same opaque paramet= er would be present in the Route header. Edge proxy would lookup if active = flow was still present to the UA. If the flow was present, the message woul= d be immediately sent. If no flow was present, message was queued in the in= -memory DB on this flow entry and new push notification was triggered. When= new Registration was received, it was matched against the in-memory DB bas= ed on sip-instance and reg-id. When 200 OK for this Registration was receiv= ed, flow information for this flow entry would get updated and if queued me= ssage were stored on this flow entry they will be sent to UA. This is, of c= ause simplified, since our implementation also dealt with sip flow expirati= on and flow probation (from the time Registration was received until 200 OK= was received from the registrar flow was stored but not used).
<= br>
From implementation stand point I s= ee two possible ways SIP push can be implemented:

1. An imp= lementation where edge proxy and registration server are part of the same s= ystem. They use an internal mechanism to exchange data about registration, = push, and queued SIP messages. It would also likely assume that only one UA= is registered per AOR. In this case registration is matched to pending req= uests using AOR. SIP Outbound is not used and NAT binding is maintained dur= ing the call using SIP Session timer with short expiration time. This imple= netation will not track flows to the UA, and will likely need to use push f= or each dialog creating or non-dialog message.

2. An implem= entation where edge proxy and registration server are separate and communic= ate through standard communication mechanisms. For this registration path e= xtension and sip-instance are used to associate dialog creating and non-dia= log messages with registrations and push parameters. This implementation wo= uld deal with multiple registrations per AOR and clients changing IPs. It w= ould also use SIP Outbound keep alive to maintain flows to the client when = client UA is active and only use SIP Push to re-establish flows when SIP UA= is suspended.=C2=A0

=
I= think SIP Outbound implementation is better since it is more efficient and= deals with more scenarios (client IP changes). Path extension is pretty mu= ch required if separate edge proxies are used with separate Registration se= rver. I see how "simpler" solution can be developed for an integr= ated edge proxy and registrar, but when these component are separate, somet= hing like Path extension and sip.instance will be needed.

<= /span>
Regards,
<= div class=3D"m_-6035714632276319801gmail_signature">_____________
Roman = Shpount

=C2=A0
--000000000000f31ba90567c7f856-- From nobody Mon Mar 19 22:14:53 2018 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 3B803120713 for ; Mon, 19 Mar 2018 22:14:52 -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, 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 Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 7E6XFb2pheI4 for ; Mon, 19 Mar 2018 22:14:49 -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 3AF56120454 for ; Mon, 19 Mar 2018 22:14:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1521522887; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=l87CyodNNGRJUxiKgZJJb/bXJLf79jsEdtBlNgEDyGc=; b=MI9xzlguQiJFu7zHV1N86ISQF35Ho71OdhhcV57M+yiYCkpRgq9rdM3RHMk/r99C 6pINlIV77oKFNGHoddQ9QV7uj0/dyYVO477RwzXLhg7FcQUU5sBXjUm7Wu8doKJC D73cQnKHH+kuivIuwNZA+6kwhV96Aef8paW8avbwMFo=; X-AuditID: c1b4fb30-703ff7000000095a-03-5ab098c6d65b Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 22.F4.02394.6C890BA5; Tue, 20 Mar 2018 06:14:47 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.172]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0382.000; Tue, 20 Mar 2018 06:14:46 +0100 From: Christer Holmberg To: Roman Shpount CC: "Dale R. Worley" , "sipcore@ietf.org" Thread-Topic: [sipcore] sip-push: Recongizing the re-REGISTER Thread-Index: AQHTv2Rio3oD+jI3TEmHjc9qC5tyLaPXU5xwgABKRICAACM1cIAADHqAgADGJdA= Date: Tue, 20 Mar 2018 05:14:45 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B6C210E26@ESESSMB109.ericsson.se> References: <87woy84dsf.fsf@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B6C20EADA@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C20FF2A@ESESSMB109.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.170] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B6C210E26ESESSMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHIsWRmVeSWpSXmKPExsUyM2K7q+7xGRuiDDp7mSxmXJjKbPH1xyY2 i5cnyhyYPSbv/8rssWTJTyaPW1MKApijuGxSUnMyy1KL9O0SuDL2/PrKVHDtPGPFvIa1LA2M M04xdjFyckgImEg8XNzM1MXIxSEkcJhRYtGz/4wQzhJGiYXrr7F2MXJwsAlYSHT/0wZpEBFQ lfj7fTITiM0sECTR/HkF2CBhARuJ1ovnWSFqbCUmL5vCBGH7SZzu3sIOYrMA9S7uXscGYvMK +Eq0TjkLtfgEk8TUhXvAmjkFAiUW3JsD1swoICbx/dQaqGXiEreezGeCuFpAYsme88wQtqjE y8f/WCFsJYkzm56zQNTnS8yc8IwdYpmgxMmZT1gmMIrMQjJqFpKyWUjKZgG9zCygKbF+lz5E iaLElO6H7BC2hkTrnLnsyOILGNlXMYoWpxYn5aYbGemlFmUmFxfn5+nlpZZsYgTG2sEtvw12 ML587niIUYCDUYmH9+60DVFCrIllxZW5hxglOJiVRHjVo4FCvCmJlVWpRfnxRaU5qcWHGKU5 WJTEeU968kYJCaQnlqRmp6YWpBbBZJk4OKUaGJdWXN765Omap2EX1BlEA8TbtgT+eJsvKTmn /rTI3KrYqyHXaxecvaSqedg3rzG2cOHd1MaXv3ySzGau3MC2O3mD6OU3sd/WpCjeq9Iz4/V8 cWu37psNRTqf5TedytRX4/FbvEf0d7TqzopZf7yeRAnU3ntWEpJwKuIof7zb5i/BNprijT+7 mZVYijMSDbWYi4oTAWAz5D6xAgAA Archived-At: Subject: Re: [sipcore] sip-push: Recongizing the re-REGISTER 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, 20 Mar 2018 05:14:52 -0000 --_000_7594FB04B1934943A5C02806D1A2204B6C210E26ESESSMB109erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUm9tYW4sDQoNClRoYW5rIHlvdSBmb3IgeW91ciBjbGFyaWZpY2F0aW9uIQ0KDQpBcyB3ZSBh Z3JlZWQgZWFybGllciwgd2UgY291bGQgd3JpdGUgYSBzZXBhcmF0ZSBvbiBob3cgdG8gdXNlIFB1 c2ggdG9nZXRoZXIgd2l0aCBPdXRib3VuZCAoYW5kIHRoZSBleHRlbnNpb25zIGV0YyBhc3NvY2lh dGVkIHdpdGggT3V0Ym91bmQpLiBUaGUgY29yZSBkcmFmdCBkb2VzIGFsbG93IGZvcndhcmRpbmcg dGhlIHJlcXVlc3Qgd2l0aG91dCByZXF1ZXN0aW5nIGEgcHVzaCBub3RpZmljYXRpb24gaXQg4oCc aGFzIGtub3dsZWRnZeKAnSB0aGF0IHRoZSBTSVAgVUEgaXMgYXdha2UsIGFuZCB1c2FnZSBvZiBP dXRib3VuZCBpcyBvbmUgbWVjaGFuaXNtIGZvciBwcm92aWRpbmcgc3VjaCBrbm93bGVkZ2UuDQoN ClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCkZyb206IFJvbWFuIFNocG91bnQgW21haWx0bzpyb21h bkB0ZWx1cml4LmNvbV0NClNlbnQ6IDE5IE1hcmNoIDIwMTggMjA6MTgNClRvOiBDaHJpc3RlciBI b2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPg0KQ2M6IERhbGUgUi4gV29y bGV5IDx3b3JsZXlAYXJpYWRuZS5jb20+OyBzaXBjb3JlQGlldGYub3JnDQpTdWJqZWN0OiBSZTog W3NpcGNvcmVdIHNpcC1wdXNoOiBSZWNvbmdpemluZyB0aGUgcmUtUkVHSVNURVINCg0KDQpPbiBN b24sIE1hciAxOSwgMjAxOCBhdCAxMjo0OCBQTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVy LmhvbG1iZXJnQGVyaWNzc29uLmNvbTxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24u Y29tPj4gd3JvdGU6DQpIaSwNCg0KPj4gV2hlbiB0aGVyZSBpcyBhbiBpbmNvbWluZyByZXF1ZXN0 IGZvciBhIFVBIHVzaW5nIHNpcC1wdXNoLCB0aGlzIHBhcmFncmFwaA0KPj4gaW4gc2VjdGlvbiA1 LjMuMiBkZXNjcmliZXMgaG93IGl0IGlzIHRvIGJlIHByb2Nlc3NlczoNCj4+DQo+PiAgIFRoZSBw dXNoIG5vdGlmaWNhdGlvbiB3aWxsIHRyaWdnZXIgdGhlIFVBIHRvIHNlbmQgYSByZS1yZWdpc3Ry YXRpb24NCj4+ICAgUkVHSVNURVIgcmVxdWVzdC4gIFRoZSBwcm94eSB3aWxsIHByb2Nlc3MgdGhl IFJFR0lTVEVSIHJlcXVlc3QgYW5kDQo+PiAgIHRoZSBhc3NvY2lhdGVkIHJlc3BvbnNlIGFzIGRl c2NyaWJlZCBpbiBTZWN0aW9uIDUuMy4xLiAgSW4gY2FzZSBvZiBhDQo+PiAgIDJ4eCByZXNwb25z ZSB0byB0aGUgUkVHSVNURVIgcmVxdWVzdCwgb25jZSB0aGUgcHJveHkgaGFzIGZvcndhcmRlZA0K Pj4gICB0aGUgUkVHSVNURVIgcmVzcG9uc2UgdG93YXJkcyB0aGUgVUEsIGlmIHRoZSBjb250YWN0 IGluIHRoZSBSRUdJU1RFUg0KPj4gICByZXNwb25zZSBtYXRjaGVzIHRoZSBSZXF1ZXN0LVVSSSBv ZiB0aGUgU0lQIHJlcXVlc3QgdG8gYmUgZm9yd2FyZGVkLA0KPj4gICB0aGUgcHJveHkgY2FuIGFs c28gZm9yd2FyZCB0aGUgU0lQIHJlcXVlc3QgdG93YXJkcyB0aGUgVUEsIHVzaW5nDQo+PiAgIG5v cm1hbCBTSVAgcHJvY2VkdXJlcy4gIElmIHRoZSBjb250YWN0IG9mIHRoZSBtb3N0IHJlY2VudCBS RUdJU1RFUg0KPj4gICAyeHggcmVzcG9uc2UgYW5kIFJlcXVlc3QtVVJJIGRvIG5vdCBtYXRjaCwg dGhlIHByb3h5IE1VU1QgcmVqZWN0IHRoZQ0KPj4gICBTSVAgcmVxdWVzdCB3aXRoIGEgNDA0IChO b3QgRm91bmQpIHJlc3BvbnNlLg0KPj4NCj4+IFRoZSBsYXN0IHNlbnRlbmNlLCBpbiBwYXJ0aWN1 bGFyLCBhc3N1bWVzIHRoYXQgdGhlIHByb3h5IGNhbiByZWxpYWJseSByZWNvZ25pemUgd2hpY2gg UkVHSVNURVINCj4+IHJlcXVlc3Qgd2FzIHNlbnQgYnkgdGhlIFVBLCBidXQgdGhlIHNlY3Rpb24g ZG9lc24ndCBkZXNjcmliZSBob3cgaXQgZG9lcyB0aGF0LiAgVGhpcyBuZWVkcyB0byBiZQ0KPj4g c3BlbGxlZCBvdXQsIGFzIGFsbW9zdCBhbGwgZWxlbWVudHMgb2YgdGhlIHJlZ2lzdHJhdGlvbiBj YW4gY2hhbmdlIG92ZXIgdGltZS4gIEluIHBhcnRpY3VsYXIsIHRoZSBJUA0KPj4gYWRkcmVzcyBj YW4gY2hhbmdlIGFzIHRoZSBVQSBtb3ZlcyBiZXR3ZWVuIG5ldHdvcmtzLCBvciBldmVuIHNlY3Rp b25zIG9mIG9uZSBuZXR3b3JrLCBhbmQgdGhlDQo+PiBQTlMgaW5mb3JtYXRpb24gbWF5IGNoYW5n ZSAoYXMgZGV0YWlsZWQgZWxzZXdoZXJlIGluIHRoZSBkcmFmdCkuDQo+Pg0KPj4gTm90ZSB0aGF0 IHRoZSBjYXNlIHdoZXJlIHRoZSBSLVVSSSBhbmQgcmVnaXN0ZXJlZCBjb250YWN0IHdvbid0IG1h dGNoIGlzIHdoZW4gdGhlIHJlZ2lzdHJhciBmb3J3YXJkcyBhbg0KPj4gSU5WSVRFIHRvd2FyZHMg dGhlIHByb3h5IGF0IHRoZSBzYW1lIHRpbWUgd2hlbiB0aGUgVUEgc2VuZHMgYSByZS1yZWdpc3Ry YXRpb24gd2l0aCBhIG5ldyBjb250YWN0LiBTbywgdGhlDQo+PiBSLVVSSSBvZiB0aGUgSU5WSVRF IHdpbGwgY29udGFpbiB0aGUgIm9sZCIgY29udGFjdCwgd2hpbGUgdGhlIDIwMCBPSyByZXNwb25z ZSB0byB0aGUgUkVHSVNURVIgd2lsbCBjb250YWluDQo+PiB0aGUgbmV3IGNvbnRhY3QuDQo+Pg0K Pj4gQXMgZmFyIGFzIG1hdGNoaW5nIHRoZSBJTlZJVEUgd2l0aCB0aGUgUkVHSVNURVIsIHlvdSBj YW4gdXNlIHRoZSBwbi0gcGFyYW1ldGVycyBmb3IgdGhhdC4NCj4NCj4gV291bGQgdGhpcyBiZSBi ZXR0ZXIgaW1wbGVtZW50ZWQgYnkgdXNpbmcgUkZDIDMzMjcgUGF0aCByZWdpc3RyYXRpb24gZXh0 ZW5zaW9uPyBTSVAgUHVzaCBwcm94eSBjYW4NCj4gaW5jbHVkZSBhIHBhcmFtZXRlciBpbiB0aGUg UGF0aCBVUkwgc28gdGhhdCBpdCBjYW4gbWF0Y2ggdGhlIGluYm91bmQgcmVnaXN0cmF0aW9uIHdp dGggYWxsIHRoZSByZXF1ZXN0cw0KPiB0aGF0IFJlZ2lzdHJhciB3aWxsIHNlbmQgZm9yIHRoaXMg cmVnaXN0cmF0aW9uLg0KV2h5IHdvdWxkIHRoYXQgYmUgImJldHRlciI/DQoNCkkgYW0gbm90IGV2 ZW4gc3VyZSBob3cgaXQgd291bGQgd29yay4gV2hlbiB0aGUgcHJveHkgcmVjZWl2ZXMgYW4gSU5W SVRFLCBhbmQgcmVxdWVzdHMgYSBwdXNoIG5vdGlmaWNhdGlvbiwgdGhlIFJFR0lTVEVSIGZyb20g dGhlIFVBIGlzIG5vdCBnb2luZyB0byBjb250YWluIHRoZSBQYXRoIGluZm9ybWF0aW9uLg0KDQpJ biBhZGRpdGlvbiwgdXNhZ2Ugb2YgUGF0aCByZXF1aXJlcyBzdXBwb3J0IGJ5IHRoZSByZWdpc3Ry YXIuDQoNClVzYWdlIG9mIHBuLSBwYXJhbWV0ZXIgd29ya3MgZmluZS4NCg0KV2UgbWlnaHQgYWxz byBiZSB0YWxraW5nIGFib3V0IGRpZmZlcmVudCB0aGluZ3MuIEkgd2FzIHRhbGtpbmcgYWJvdXQg bWF0Y2hpbmcgb2YgZGlhbG9nIGNyZWF0aW5nIHJlcXVlc3QgcmVjZWl2ZWQgYnkgdGhlIGVkZ2Ug cHJveHkgd2l0aCBhbiBleGlzdGluZyByZWdpc3RyYXRpb24uIFlvdSBtaWdodCBhbHNvIGJlIHRh bGtpbmcgYWJvdXQgbWF0Y2hpbmcgdGhlIG5ldyBSZWdpc3RyYXRpb24gZnJvbSB0aGUgY2xpZW50 IHRvIHRoZSBwZW5kaW5nIGRpYWxvZyBjcmVhdGluZyByZXF1ZXN0Lg0KDQpPdXIgaW1wbGVtZW50 YXRpb24gd2FzIGJhc2VkIG9uIFNJUCBPdXRib3VuZCBhbmQgc3VwcG9ydGVkIHNpcC5pbnN0YW5j ZSBhbmQgcmVnaXN0cmF0aW9uIHBhdGggZXh0ZW5zaW9ucyBmcm9tIHRoZSBzdGFydC4gV2hlbiBy ZWdpc3RyYXRpb24gd2FzIHJlY2VpdmVkIGZyb20gY2xpZW50IFVBLCBmbG93IGZyb20gdGhlIFVB IHdhcyBzdG9yZWQgaW4tbWVtb3J5IG9uIHRoZSBlZGdlIHByb3h5IHRvZ2V0aGVyIHdpdGggc2lw LWluc3RhbmNlLCByZWctaWQsIGFuZCBwdXNoIG5vdGlmaWNhdGlvbiBpbmZvcm1hdGlvbi4gS2V5 IGZvciB0aGlzIGluLW1lbW9yeSBEQiBlbnRyeSB3YXMgaW5zZXJ0ZWQgaW4gb3BhcXVlIHBhcmFt ZXRlciBpbiBQYXRoIGhlYWRlciBhZGRlZCB0byByZWdpc3RyYXRpb24gbWVzc2FnZS4gV2hlbiBu ZXcgcmVxdWVzdCB3YXMgcmVjZWl2ZWQgYnkgdGhlIGVkZ2UgcHJveHksIHRoZSBzYW1lIG9wYXF1 ZSBwYXJhbWV0ZXIgd291bGQgYmUgcHJlc2VudCBpbiB0aGUgUm91dGUgaGVhZGVyLiBFZGdlIHBy b3h5IHdvdWxkIGxvb2t1cCBpZiBhY3RpdmUgZmxvdyB3YXMgc3RpbGwgcHJlc2VudCB0byB0aGUg VUEuIElmIHRoZSBmbG93IHdhcyBwcmVzZW50LCB0aGUgbWVzc2FnZSB3b3VsZCBiZSBpbW1lZGlh dGVseSBzZW50LiBJZiBubyBmbG93IHdhcyBwcmVzZW50LCBtZXNzYWdlIHdhcyBxdWV1ZWQgaW4g dGhlIGluLW1lbW9yeSBEQiBvbiB0aGlzIGZsb3cgZW50cnkgYW5kIG5ldyBwdXNoIG5vdGlmaWNh dGlvbiB3YXMgdHJpZ2dlcmVkLiBXaGVuIG5ldyBSZWdpc3RyYXRpb24gd2FzIHJlY2VpdmVkLCBp dCB3YXMgbWF0Y2hlZCBhZ2FpbnN0IHRoZSBpbi1tZW1vcnkgREIgYmFzZWQgb24gc2lwLWluc3Rh bmNlIGFuZCByZWctaWQuIFdoZW4gMjAwIE9LIGZvciB0aGlzIFJlZ2lzdHJhdGlvbiB3YXMgcmVj ZWl2ZWQsIGZsb3cgaW5mb3JtYXRpb24gZm9yIHRoaXMgZmxvdyBlbnRyeSB3b3VsZCBnZXQgdXBk YXRlZCBhbmQgaWYgcXVldWVkIG1lc3NhZ2Ugd2VyZSBzdG9yZWQgb24gdGhpcyBmbG93IGVudHJ5 IHRoZXkgd2lsbCBiZSBzZW50IHRvIFVBLiBUaGlzIGlzLCBvZiBjYXVzZSBzaW1wbGlmaWVkLCBz aW5jZSBvdXIgaW1wbGVtZW50YXRpb24gYWxzbyBkZWFsdCB3aXRoIHNpcCBmbG93IGV4cGlyYXRp b24gYW5kIGZsb3cgcHJvYmF0aW9uIChmcm9tIHRoZSB0aW1lIFJlZ2lzdHJhdGlvbiB3YXMgcmVj ZWl2ZWQgdW50aWwgMjAwIE9LIHdhcyByZWNlaXZlZCBmcm9tIHRoZSByZWdpc3RyYXIgZmxvdyB3 YXMgc3RvcmVkIGJ1dCBub3QgdXNlZCkuDQoNCkZyb20gaW1wbGVtZW50YXRpb24gc3RhbmQgcG9p bnQgSSBzZWUgdHdvIHBvc3NpYmxlIHdheXMgU0lQIHB1c2ggY2FuIGJlIGltcGxlbWVudGVkOg0K DQoxLiBBbiBpbXBsZW1lbnRhdGlvbiB3aGVyZSBlZGdlIHByb3h5IGFuZCByZWdpc3RyYXRpb24g c2VydmVyIGFyZSBwYXJ0IG9mIHRoZSBzYW1lIHN5c3RlbS4gVGhleSB1c2UgYW4gaW50ZXJuYWwg bWVjaGFuaXNtIHRvIGV4Y2hhbmdlIGRhdGEgYWJvdXQgcmVnaXN0cmF0aW9uLCBwdXNoLCBhbmQg cXVldWVkIFNJUCBtZXNzYWdlcy4gSXQgd291bGQgYWxzbyBsaWtlbHkgYXNzdW1lIHRoYXQgb25s eSBvbmUgVUEgaXMgcmVnaXN0ZXJlZCBwZXIgQU9SLiBJbiB0aGlzIGNhc2UgcmVnaXN0cmF0aW9u IGlzIG1hdGNoZWQgdG8gcGVuZGluZyByZXF1ZXN0cyB1c2luZyBBT1IuIFNJUCBPdXRib3VuZCBp cyBub3QgdXNlZCBhbmQgTkFUIGJpbmRpbmcgaXMgbWFpbnRhaW5lZCBkdXJpbmcgdGhlIGNhbGwg dXNpbmcgU0lQIFNlc3Npb24gdGltZXIgd2l0aCBzaG9ydCBleHBpcmF0aW9uIHRpbWUuIFRoaXMg aW1wbGVuZXRhdGlvbiB3aWxsIG5vdCB0cmFjayBmbG93cyB0byB0aGUgVUEsIGFuZCB3aWxsIGxp a2VseSBuZWVkIHRvIHVzZSBwdXNoIGZvciBlYWNoIGRpYWxvZyBjcmVhdGluZyBvciBub24tZGlh bG9nIG1lc3NhZ2UuDQoNCjIuIEFuIGltcGxlbWVudGF0aW9uIHdoZXJlIGVkZ2UgcHJveHkgYW5k IHJlZ2lzdHJhdGlvbiBzZXJ2ZXIgYXJlIHNlcGFyYXRlIGFuZCBjb21tdW5pY2F0ZSB0aHJvdWdo IHN0YW5kYXJkIGNvbW11bmljYXRpb24gbWVjaGFuaXNtcy4gRm9yIHRoaXMgcmVnaXN0cmF0aW9u IHBhdGggZXh0ZW5zaW9uIGFuZCBzaXAtaW5zdGFuY2UgYXJlIHVzZWQgdG8gYXNzb2NpYXRlIGRp YWxvZyBjcmVhdGluZyBhbmQgbm9uLWRpYWxvZyBtZXNzYWdlcyB3aXRoIHJlZ2lzdHJhdGlvbnMg YW5kIHB1c2ggcGFyYW1ldGVycy4gVGhpcyBpbXBsZW1lbnRhdGlvbiB3b3VsZCBkZWFsIHdpdGgg bXVsdGlwbGUgcmVnaXN0cmF0aW9ucyBwZXIgQU9SIGFuZCBjbGllbnRzIGNoYW5naW5nIElQcy4g SXQgd291bGQgYWxzbyB1c2UgU0lQIE91dGJvdW5kIGtlZXAgYWxpdmUgdG8gbWFpbnRhaW4gZmxv d3MgdG8gdGhlIGNsaWVudCB3aGVuIGNsaWVudCBVQSBpcyBhY3RpdmUgYW5kIG9ubHkgdXNlIFNJ UCBQdXNoIHRvIHJlLWVzdGFibGlzaCBmbG93cyB3aGVuIFNJUCBVQSBpcyBzdXNwZW5kZWQuDQoN CkkgdGhpbmsgU0lQIE91dGJvdW5kIGltcGxlbWVudGF0aW9uIGlzIGJldHRlciBzaW5jZSBpdCBp cyBtb3JlIGVmZmljaWVudCBhbmQgZGVhbHMgd2l0aCBtb3JlIHNjZW5hcmlvcyAoY2xpZW50IElQ IGNoYW5nZXMpLiBQYXRoIGV4dGVuc2lvbiBpcyBwcmV0dHkgbXVjaCByZXF1aXJlZCBpZiBzZXBh cmF0ZSBlZGdlIHByb3hpZXMgYXJlIHVzZWQgd2l0aCBzZXBhcmF0ZSBSZWdpc3RyYXRpb24gc2Vy dmVyLiBJIHNlZSBob3cgInNpbXBsZXIiIHNvbHV0aW9uIGNhbiBiZSBkZXZlbG9wZWQgZm9yIGFu IGludGVncmF0ZWQgZWRnZSBwcm94eSBhbmQgcmVnaXN0cmFyLCBidXQgd2hlbiB0aGVzZSBjb21w b25lbnQgYXJlIHNlcGFyYXRlLCBzb21ldGhpbmcgbGlrZSBQYXRoIGV4dGVuc2lvbiBhbmQgc2lw Lmluc3RhbmNlIHdpbGwgYmUgbmVlZGVkLg0KDQpSZWdhcmRzLA0KX19fX19fX19fX19fXw0KUm9t YW4gU2hwb3VudA0KDQoNCg== --_000_7594FB04B1934943A5C02806D1A2204B6C210E26ESESSMB109erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K CW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSBSb21hbiw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRoYW5rIHlvdSBmb3IgeW91ciBjbGFyaWZp Y2F0aW9uITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+QXMgd2UgYWdy ZWVkIGVhcmxpZXIsIHdlIGNvdWxkIHdyaXRlIGEgc2VwYXJhdGUgb24gaG93IHRvIHVzZSBQdXNo IHRvZ2V0aGVyIHdpdGggT3V0Ym91bmQgKGFuZCB0aGUgZXh0ZW5zaW9ucyBldGMgYXNzb2NpYXRl ZCB3aXRoIE91dGJvdW5kKS4NCiBUaGUgY29yZSBkcmFmdCBkb2VzIGFsbG93IGZvcndhcmRpbmcg dGhlIHJlcXVlc3Qgd2l0aG91dCByZXF1ZXN0aW5nIGEgcHVzaCBub3RpZmljYXRpb24gaXQg4oCc aGFzIGtub3dsZWRnZeKAnSB0aGF0IHRoZSBTSVAgVUEgaXMgYXdha2UsIGFuZCB1c2FnZSBvZiBP dXRib3VuZCBpcyBvbmUgbWVjaGFuaXNtIGZvciBwcm92aWRpbmcgc3VjaCBrbm93bGVkZ2UuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5SZWdhcmRzLDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Q2hyaXN0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPiBSb21hbiBTaHBvdW50IFttYWlsdG86cm9tYW5AdGVsdXJpeC5jb21d DQo8YnI+DQo8Yj5TZW50OjwvYj4gMTkgTWFyY2ggMjAxOCAyMDoxODxicj4NCjxiPlRvOjwvYj4g Q2hyaXN0ZXIgSG9sbWJlcmcgJmx0O2NocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSZndDs8 YnI+DQo8Yj5DYzo8L2I+IERhbGUgUi4gV29ybGV5ICZsdDt3b3JsZXlAYXJpYWRuZS5jb20mZ3Q7 OyBzaXBjb3JlQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbc2lwY29yZV0gc2lw LXB1c2g6IFJlY29uZ2l6aW5nIHRoZSByZS1SRUdJU1RFUjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIE1h ciAxOSwgMjAxOCBhdCAxMjo0OCBQTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgJmx0OzxhIGhyZWY9Im1h aWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5jaHJp c3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSw8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu MHB0Ij48YnI+DQomZ3Q7Jmd0OyBXaGVuIHRoZXJlIGlzIGFuIGluY29taW5nIHJlcXVlc3QgZm9y IGEgVUEgdXNpbmcgc2lwLXB1c2gsIHRoaXMgcGFyYWdyYXBoPGJyPg0KJmd0OyZndDsgaW4gc2Vj dGlvbiA1LjMuMiBkZXNjcmliZXMgaG93IGl0IGlzIHRvIGJlIHByb2Nlc3Nlczo8YnI+DQomZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwO1RoZSBwdXNoIG5vdGlmaWNhdGlvbiB3aWxs IHRyaWdnZXIgdGhlIFVBIHRvIHNlbmQgYSByZS1yZWdpc3RyYXRpb248YnI+DQomZ3Q7Jmd0OyZu YnNwOyAmbmJzcDtSRUdJU1RFUiByZXF1ZXN0LiZuYnNwOyBUaGUgcHJveHkgd2lsbCBwcm9jZXNz IHRoZSBSRUdJU1RFUiByZXF1ZXN0IGFuZDxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwO3RoZSBh c3NvY2lhdGVkIHJlc3BvbnNlIGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDUuMy4xLiZuYnNwOyBJ biBjYXNlIG9mIGE8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsyeHggcmVzcG9uc2UgdG8gdGhl IFJFR0lTVEVSIHJlcXVlc3QsIG9uY2UgdGhlIHByb3h5IGhhcyBmb3J3YXJkZWQ8YnI+DQomZ3Q7 Jmd0OyZuYnNwOyAmbmJzcDt0aGUgUkVHSVNURVIgcmVzcG9uc2UgdG93YXJkcyB0aGUgVUEsIGlm IHRoZSBjb250YWN0IGluIHRoZSBSRUdJU1RFUjxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwO3Jl c3BvbnNlIG1hdGNoZXMgdGhlIFJlcXVlc3QtVVJJIG9mIHRoZSBTSVAgcmVxdWVzdCB0byBiZSBm b3J3YXJkZWQsPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7dGhlIHByb3h5IGNhbiBhbHNvIGZv cndhcmQgdGhlIFNJUCByZXF1ZXN0IHRvd2FyZHMgdGhlIFVBLCB1c2luZzxicj4NCiZndDsmZ3Q7 Jm5ic3A7ICZuYnNwO25vcm1hbCBTSVAgcHJvY2VkdXJlcy4mbmJzcDsgSWYgdGhlIGNvbnRhY3Qg b2YgdGhlIG1vc3QgcmVjZW50IFJFR0lTVEVSPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7Mnh4 IHJlc3BvbnNlIGFuZCBSZXF1ZXN0LVVSSSBkbyBub3QgbWF0Y2gsIHRoZSBwcm94eSBNVVNUIHJl amVjdCB0aGU8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDtTSVAgcmVxdWVzdCB3aXRoIGEgNDA0 IChOb3QgRm91bmQpIHJlc3BvbnNlLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgVGhlIGxh c3Qgc2VudGVuY2UsIGluIHBhcnRpY3VsYXIsIGFzc3VtZXMgdGhhdCB0aGUgcHJveHkgY2FuIHJl bGlhYmx5IHJlY29nbml6ZSB3aGljaCBSRUdJU1RFUjxicj4NCiZndDsmZ3Q7IHJlcXVlc3Qgd2Fz IHNlbnQgYnkgdGhlIFVBLCBidXQgdGhlIHNlY3Rpb24gZG9lc24ndCBkZXNjcmliZSBob3cgaXQg ZG9lcyB0aGF0LiZuYnNwOyBUaGlzIG5lZWRzIHRvIGJlPGJyPg0KJmd0OyZndDsgc3BlbGxlZCBv dXQsIGFzIGFsbW9zdCBhbGwgZWxlbWVudHMgb2YgdGhlIHJlZ2lzdHJhdGlvbiBjYW4gY2hhbmdl IG92ZXIgdGltZS4mbmJzcDsgSW4gcGFydGljdWxhciwgdGhlIElQPGJyPg0KJmd0OyZndDsgYWRk cmVzcyBjYW4gY2hhbmdlIGFzIHRoZSBVQSBtb3ZlcyBiZXR3ZWVuIG5ldHdvcmtzLCBvciBldmVu IHNlY3Rpb25zIG9mIG9uZSBuZXR3b3JrLCBhbmQgdGhlPGJyPg0KJmd0OyZndDsgUE5TIGluZm9y bWF0aW9uIG1heSBjaGFuZ2UgKGFzIGRldGFpbGVkIGVsc2V3aGVyZSBpbiB0aGUgZHJhZnQpLjxi cj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgTm90ZSB0aGF0IHRoZSBjYXNlIHdoZXJlIHRoZSBS LVVSSSBhbmQgcmVnaXN0ZXJlZCBjb250YWN0IHdvbid0IG1hdGNoIGlzIHdoZW4gdGhlIHJlZ2lz dHJhciBmb3J3YXJkcyBhbjxicj4NCiZndDsmZ3Q7IElOVklURSB0b3dhcmRzIHRoZSBwcm94eSBh dCB0aGUgc2FtZSB0aW1lIHdoZW4gdGhlIFVBIHNlbmRzIGEgcmUtcmVnaXN0cmF0aW9uIHdpdGgg YSBuZXcgY29udGFjdC4gU28sIHRoZTxicj4NCiZndDsmZ3Q7IFItVVJJIG9mIHRoZSBJTlZJVEUg d2lsbCBjb250YWluIHRoZSAmcXVvdDtvbGQmcXVvdDsgY29udGFjdCwgd2hpbGUgdGhlIDIwMCBP SyByZXNwb25zZSB0byB0aGUgUkVHSVNURVIgd2lsbCBjb250YWluPGJyPg0KJmd0OyZndDsgdGhl IG5ldyBjb250YWN0Ljxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgQXMgZmFyIGFzIG1hdGNo aW5nIHRoZSBJTlZJVEUgd2l0aCB0aGUgUkVHSVNURVIsIHlvdSBjYW4gdXNlIHRoZSBwbi0gcGFy YW1ldGVycyBmb3IgdGhhdC48YnI+DQomZ3Q7PGJyPg0KJmd0OyBXb3VsZCB0aGlzIGJlIGJldHRl ciBpbXBsZW1lbnRlZCBieSB1c2luZyBSRkMgMzMyNyBQYXRoIHJlZ2lzdHJhdGlvbiBleHRlbnNp b24/IFNJUCBQdXNoIHByb3h5IGNhbjxicj4NCiZndDsgaW5jbHVkZSBhIHBhcmFtZXRlciBpbiB0 aGUgUGF0aCBVUkwgc28gdGhhdCBpdCBjYW4gbWF0Y2ggdGhlIGluYm91bmQgcmVnaXN0cmF0aW9u IHdpdGggYWxsIHRoZSByZXF1ZXN0czxicj4NCiZndDsgdGhhdCBSZWdpc3RyYXIgd2lsbCBzZW5k IGZvciB0aGlzIHJlZ2lzdHJhdGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPldoeSB3b3Vs ZCB0aGF0IGJlICZxdW90O2JldHRlciZxdW90Oz88YnI+DQo8YnI+DQpJIGFtIG5vdCBldmVuIHN1 cmUgaG93IGl0IHdvdWxkIHdvcmsuIFdoZW4gdGhlIHByb3h5IHJlY2VpdmVzIGFuIElOVklURSwg YW5kIHJlcXVlc3RzIGEgcHVzaCBub3RpZmljYXRpb24sIHRoZSBSRUdJU1RFUiBmcm9tIHRoZSBV QSBpcyBub3QgZ29pbmcgdG8gY29udGFpbiB0aGUgUGF0aCBpbmZvcm1hdGlvbi48YnI+DQo8YnI+ DQpJbiBhZGRpdGlvbiwgdXNhZ2Ugb2YgUGF0aCByZXF1aXJlcyBzdXBwb3J0IGJ5IHRoZSByZWdp c3RyYXIuPGJyPg0KPGJyPg0KVXNhZ2Ugb2YgcG4tIHBhcmFtZXRlciB3b3JrcyBmaW5lLjxvOnA+ PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ V2UgbWlnaHQgYWxzbyBiZSB0YWxraW5nIGFib3V0IGRpZmZlcmVudCB0aGluZ3MuIEkgd2FzIHRh bGtpbmcgYWJvdXQgbWF0Y2hpbmcgb2YgZGlhbG9nIGNyZWF0aW5nIHJlcXVlc3QgcmVjZWl2ZWQg YnkgdGhlIGVkZ2UgcHJveHkgd2l0aCBhbiBleGlzdGluZyByZWdpc3RyYXRpb24uIFlvdSBtaWdo dCBhbHNvIGJlIHRhbGtpbmcgYWJvdXQgbWF0Y2hpbmcgdGhlIG5ldyBSZWdpc3RyYXRpb24gZnJv bSB0aGUgY2xpZW50DQogdG8gdGhlIHBlbmRpbmcgZGlhbG9nIGNyZWF0aW5nIHJlcXVlc3QuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk91ciBp bXBsZW1lbnRhdGlvbiB3YXMgYmFzZWQgb24gU0lQIE91dGJvdW5kIGFuZCBzdXBwb3J0ZWQgc2lw Lmluc3RhbmNlIGFuZCByZWdpc3RyYXRpb24gcGF0aCBleHRlbnNpb25zIGZyb20gdGhlIHN0YXJ0 LiBXaGVuIHJlZ2lzdHJhdGlvbiB3YXMgcmVjZWl2ZWQgZnJvbSBjbGllbnQgVUEsIGZsb3cgZnJv bSB0aGUgVUEgd2FzIHN0b3JlZCBpbi1tZW1vcnkgb24gdGhlIGVkZ2UgcHJveHkgdG9nZXRoZXIg d2l0aA0KIHNpcC1pbnN0YW5jZSwgcmVnLWlkLCBhbmQgcHVzaCBub3RpZmljYXRpb24gaW5mb3Jt YXRpb24uIEtleSBmb3IgdGhpcyBpbi1tZW1vcnkgREIgZW50cnkgd2FzIGluc2VydGVkIGluIG9w YXF1ZSBwYXJhbWV0ZXIgaW4gUGF0aCBoZWFkZXIgYWRkZWQgdG8gcmVnaXN0cmF0aW9uIG1lc3Nh Z2UuIFdoZW4gbmV3IHJlcXVlc3Qgd2FzIHJlY2VpdmVkIGJ5IHRoZSBlZGdlIHByb3h5LCB0aGUg c2FtZSBvcGFxdWUgcGFyYW1ldGVyIHdvdWxkIGJlIHByZXNlbnQNCiBpbiB0aGUgUm91dGUgaGVh ZGVyLiBFZGdlIHByb3h5IHdvdWxkIGxvb2t1cCBpZiBhY3RpdmUgZmxvdyB3YXMgc3RpbGwgcHJl c2VudCB0byB0aGUgVUEuIElmIHRoZSBmbG93IHdhcyBwcmVzZW50LCB0aGUgbWVzc2FnZSB3b3Vs ZCBiZSBpbW1lZGlhdGVseSBzZW50LiBJZiBubyBmbG93IHdhcyBwcmVzZW50LCBtZXNzYWdlIHdh cyBxdWV1ZWQgaW4gdGhlIGluLW1lbW9yeSBEQiBvbiB0aGlzIGZsb3cgZW50cnkgYW5kIG5ldyBw dXNoIG5vdGlmaWNhdGlvbg0KIHdhcyB0cmlnZ2VyZWQuIFdoZW4gbmV3IFJlZ2lzdHJhdGlvbiB3 YXMgcmVjZWl2ZWQsIGl0IHdhcyBtYXRjaGVkIGFnYWluc3QgdGhlIGluLW1lbW9yeSBEQiBiYXNl ZCBvbiBzaXAtaW5zdGFuY2UgYW5kIHJlZy1pZC4gV2hlbiAyMDAgT0sgZm9yIHRoaXMgUmVnaXN0 cmF0aW9uIHdhcyByZWNlaXZlZCwgZmxvdyBpbmZvcm1hdGlvbiBmb3IgdGhpcyBmbG93IGVudHJ5 IHdvdWxkIGdldCB1cGRhdGVkIGFuZCBpZiBxdWV1ZWQgbWVzc2FnZSB3ZXJlIHN0b3JlZA0KIG9u IHRoaXMgZmxvdyBlbnRyeSB0aGV5IHdpbGwgYmUgc2VudCB0byBVQS4gVGhpcyBpcywgb2YgY2F1 c2Ugc2ltcGxpZmllZCwgc2luY2Ugb3VyIGltcGxlbWVudGF0aW9uIGFsc28gZGVhbHQgd2l0aCBz aXAgZmxvdyBleHBpcmF0aW9uIGFuZCBmbG93IHByb2JhdGlvbiAoZnJvbSB0aGUgdGltZSBSZWdp c3RyYXRpb24gd2FzIHJlY2VpdmVkIHVudGlsIDIwMCBPSyB3YXMgcmVjZWl2ZWQgZnJvbSB0aGUg cmVnaXN0cmFyIGZsb3cgd2FzIHN0b3JlZA0KIGJ1dCBub3QgdXNlZCkuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyMjIyMjI7YmFja2dy b3VuZDp3aGl0ZSI+RnJvbSBpbXBsZW1lbnRhdGlvbiBzdGFuZCBwb2ludCBJIHNlZSB0d28gcG9z c2libGUgd2F5cyBTSVAgcHVzaCBjYW4gYmUgaW1wbGVtZW50ZWQ6PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjIyMjIyO2Jh Y2tncm91bmQ6d2hpdGUiPjEuIEFuIGltcGxlbWVudGF0aW9uIHdoZXJlIGVkZ2UgcHJveHkgYW5k IHJlZ2lzdHJhdGlvbiBzZXJ2ZXIgYXJlIHBhcnQgb2YgdGhlIHNhbWUgc3lzdGVtLiBUaGV5IHVz ZSBhbiBpbnRlcm5hbCBtZWNoYW5pc20gdG8gZXhjaGFuZ2UgZGF0YSBhYm91dCByZWdpc3RyYXRp b24sIHB1c2gsDQogYW5kIHF1ZXVlZCBTSVAgbWVzc2FnZXMuIEl0IHdvdWxkIGFsc28gbGlrZWx5 IGFzc3VtZSB0aGF0IG9ubHkgb25lIFVBIGlzIHJlZ2lzdGVyZWQgcGVyIEFPUi4gSW4gdGhpcyBj YXNlIHJlZ2lzdHJhdGlvbiBpcyBtYXRjaGVkIHRvIHBlbmRpbmcgcmVxdWVzdHMgdXNpbmcgQU9S LiBTSVAgT3V0Ym91bmQgaXMgbm90IHVzZWQgYW5kIE5BVCBiaW5kaW5nIGlzIG1haW50YWluZWQg ZHVyaW5nIHRoZSBjYWxsIHVzaW5nIFNJUCBTZXNzaW9uIHRpbWVyDQogd2l0aCBzaG9ydCBleHBp cmF0aW9uIHRpbWUuIFRoaXMgaW1wbGVuZXRhdGlvbiB3aWxsIG5vdCB0cmFjayBmbG93cyB0byB0 aGUgVUEsIGFuZCB3aWxsIGxpa2VseSBuZWVkIHRvIHVzZSBwdXNoIGZvciBlYWNoIGRpYWxvZyBj cmVhdGluZyBvciBub24tZGlhbG9nIG1lc3NhZ2UuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjIyMjIyO2JhY2tncm91bmQ6 d2hpdGUiPjIuIEFuIGltcGxlbWVudGF0aW9uIHdoZXJlIGVkZ2UgcHJveHkgYW5kIHJlZ2lzdHJh dGlvbiBzZXJ2ZXIgYXJlIHNlcGFyYXRlIGFuZCBjb21tdW5pY2F0ZSB0aHJvdWdoIHN0YW5kYXJk IGNvbW11bmljYXRpb24gbWVjaGFuaXNtcy4gRm9yIHRoaXMgcmVnaXN0cmF0aW9uIHBhdGgNCiBl eHRlbnNpb24gYW5kIHNpcC1pbnN0YW5jZSBhcmUgdXNlZCB0byBhc3NvY2lhdGUgZGlhbG9nIGNy ZWF0aW5nIGFuZCBub24tZGlhbG9nIG1lc3NhZ2VzIHdpdGggcmVnaXN0cmF0aW9ucyBhbmQgcHVz aCBwYXJhbWV0ZXJzLiBUaGlzIGltcGxlbWVudGF0aW9uIHdvdWxkIGRlYWwgd2l0aCBtdWx0aXBs ZSByZWdpc3RyYXRpb25zIHBlciBBT1IgYW5kIGNsaWVudHMgY2hhbmdpbmcgSVBzLiBJdCB3b3Vs ZCBhbHNvIHVzZSBTSVAgT3V0Ym91bmQga2VlcA0KIGFsaXZlIHRvIG1haW50YWluIGZsb3dzIHRv IHRoZSBjbGllbnQgd2hlbiBjbGllbnQgVUEgaXMgYWN0aXZlIGFuZCBvbmx5IHVzZSBTSVAgUHVz aCB0byByZS1lc3RhYmxpc2ggZmxvd3Mgd2hlbiBTSVAgVUEgaXMgc3VzcGVuZGVkLiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjIyMjIyO2JhY2tncm91bmQ6 d2hpdGUiPkkgdGhpbmsgU0lQIE91dGJvdW5kIGltcGxlbWVudGF0aW9uIGlzIGJldHRlciBzaW5j ZSBpdCBpcyBtb3JlIGVmZmljaWVudCBhbmQgZGVhbHMgd2l0aCBtb3JlIHNjZW5hcmlvcyAoY2xp ZW50IElQIGNoYW5nZXMpLiBQYXRoIGV4dGVuc2lvbg0KIGlzIHByZXR0eSBtdWNoIHJlcXVpcmVk IGlmIHNlcGFyYXRlIGVkZ2UgcHJveGllcyBhcmUgdXNlZCB3aXRoIHNlcGFyYXRlIFJlZ2lzdHJh dGlvbiBzZXJ2ZXIuIEkgc2VlIGhvdyAmcXVvdDtzaW1wbGVyJnF1b3Q7IHNvbHV0aW9uIGNhbiBi ZSBkZXZlbG9wZWQgZm9yIGFuIGludGVncmF0ZWQgZWRnZSBwcm94eSBhbmQgcmVnaXN0cmFyLCBi dXQgd2hlbiB0aGVzZSBjb21wb25lbnQgYXJlIHNlcGFyYXRlLCBzb21ldGhpbmcgbGlrZSBQYXRo IGV4dGVuc2lvbiBhbmQNCiBzaXAuaW5zdGFuY2Ugd2lsbCBiZSBuZWVkZWQuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMyMjIyMjI7YmFja2dyb3VuZDp3aGl0ZSI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMjIyMjIyO2JhY2tncm91bmQ6d2hpdGUiPlJlZ2FyZHMsPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzIyMjIyMiI+X19fX19fX19fX19fXzxicj4N ClJvbWFuIFNocG91bnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_7594FB04B1934943A5C02806D1A2204B6C210E26ESESSMB109erics_-- From nobody Tue Mar 20 01:10:41 2018 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 2EEA9126B6D for ; Tue, 20 Mar 2018 01:10:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.686 X-Spam-Level: X-Spam-Status: No, score=-1.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 cw-r8rVGscMl for ; Tue, 20 Mar 2018 01:10:39 -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 4471B1201F2 for ; Tue, 20 Mar 2018 01:10:39 -0700 (PDT) Received: from resomta-ch2-08v.sys.comcast.net ([69.252.207.104]) by resqmta-ch2-09v.sys.comcast.net with ESMTP id yCLtebUdcBANoyCLteLUD8; Tue, 20 Mar 2018 08:10:38 +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 yCLsepZd2sz7RyCLteMppd; Tue, 20 Mar 2018 08:10:37 +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 w2K8AZws029495; Tue, 20 Mar 2018 04:10:35 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id w2K8AZ6c029492; Tue, 20 Mar 2018 04:10:35 -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: <7594FB04B1934943A5C02806D1A2204B6C20EADA@ESESSMB109.ericsson.se> (christer.holmberg@ericsson.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 20 Mar 2018 04:10:35 -0400 Message-ID: <87efkfyxok.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfAyLMxbXr6kUmlVnCPyQYEpOCC6qqdirOWKHo7xO/GnIgJ3m9b2LdpndAiAnJeGxhyHVXYrelnNiFV6WbSXoFUbGSl9JbiINnm6VMyH07BjzAMpxBA3u ZEcF3RNlj/EIpCoxj0/kSfGwk1+EYBUCSgundMJ2DXmDH72LBVhcbML2qkdU+2JY5HYMGGoRvjxcVwkTsQBBnyD9Yd8UrhKeFOo= Archived-At: Subject: Re: [sipcore] sip-push: Recongizing the re-REGISTER 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, 20 Mar 2018 08:10:40 -0000 Christer Holmberg writes: [taking points out of order] > As far as matching the INVITE with the REGISTER, you can use the pn- > parameters for that. That makes sense, but as I said before, "This needs to be spelled out, as almost all elements of the registration can change over time." The current text doesn't really specify what the proxy needs to do. > Note that the case where the R-URI and registered contact won't match > is when the registrar forwards an INVITE towards the proxy at the same > time when the UA sends a re-registration with a new contact. So, the > R-URI of the INVITE will contain the "old" contact, while the 200 OK > response to the REGISTER will contain the new contact. Yes, that's one of my primary concerns, as I don't see any guarantee that a newly awakend UA can obtain the same IP address as it had before. I gather that in the environment you're currently working in, that's the case, but it seems like we want to avoid designing that restriction into the mechanism. Dale From nobody Tue Mar 20 01:13:37 2018 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 AF8771201F2 for ; Tue, 20 Mar 2018 01:13:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.686 X-Spam-Level: X-Spam-Status: No, score=-1.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 uCfslTdV-xPi for ; Tue, 20 Mar 2018 01:13:35 -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 CFE91124207 for ; Tue, 20 Mar 2018 01:13:35 -0700 (PDT) Received: from resomta-ch2-01v.sys.comcast.net ([69.252.207.97]) by resqmta-ch2-11v.sys.comcast.net with ESMTP id yCOiepgxwpYnCyCOkebsMg; Tue, 20 Mar 2018 08:13:34 +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 yCOjetoA2wxAPyCOkeyd34; Tue, 20 Mar 2018 08:13: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 w2K8DXRB029608; Tue, 20 Mar 2018 04:13:33 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id w2K8DW8m029605; Tue, 20 Mar 2018 04:13:32 -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: Roman Shpount Cc: christer.holmberg@ericsson.com, sipcore@ietf.org In-Reply-To: (roman@telurix.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 20 Mar 2018 04:13:31 -0400 Message-ID: <87bmfjyxjo.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfIIzSMvc9qrTDUZRXtxSoG2HJhvbzMJ2e7l+xnlkao4hvLOonaitewcEKm8aTeL/pOClF/PfHaefEtpUfQd41VnhJJpsItyW/p4IfYuKGeW0NujJTN2Z K8HptL2DpOaDBDXyRIjrClZFXvIF4OWcHkQvIzKlbuhtUxE3g4X0lGwRespK/e4REs2Qv66UWadOmpKhYiGlZDJVwtzwQNZVpyXaUX9/e6CNtEZttTTWTRNk Archived-At: Subject: Re: [sipcore] sip-push: Recongizing the re-REGISTER 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, 20 Mar 2018 08:13:37 -0000 Roman Shpount writes: > 2. An implementation where edge proxy and registration server are separate > and communicate through standard communication mechanisms. Finally, we have a concrete example of when "the proxy" is "far" from the registrar. I'm going to have to read through your example carefully! Dale From nobody Tue Mar 20 02:54:12 2018 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 F3CED124235 for ; Tue, 20 Mar 2018 02:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 l1yPz_PCKQsF for ; Tue, 20 Mar 2018 02:54: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 6B0781200F1 for ; Tue, 20 Mar 2018 02:54:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1521539647; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=EJvnnfYVBCDMcTW2O9GLRfp/9qILXkUCHXGbWXwxWQQ=; b=GZsorxSEYzQo8RkILl0ITM6u34JlX3RIslXoOGkpDszcy1iV/cfmcToBSvaxkaNt O+Zj856c5AcaiMg5RPe1idKl7WHVPIpMzeAIkyNoOrGgNwqET9rgan91jgET7DGn tAbOsatRLJpylmmNhcpierv/FJfrC055MekLAXmQG9c=; X-AuditID: c1b4fb30-6ebff7000000095a-b5-5ab0da3f32c7 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id D1.FF.02394.F3AD0BA5; Tue, 20 Mar 2018 10:54:07 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.172]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0382.000; Tue, 20 Mar 2018 10:54:06 +0100 From: Christer Holmberg To: "Dale R. Worley" CC: "sipcore@ietf.org" Thread-Topic: [sipcore] sip-push: Recongizing the re-REGISTER Thread-Index: AQHTwCLso3oD+jI3TEmHjc9qC5tyLaPY4UDQ Date: Tue, 20 Mar 2018 09:54:06 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B6C21168B@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B6C20EADA@ESESSMB109.ericsson.se> (christer.holmberg@ericsson.com) <87efkfyxok.fsf@hobgoblin.ariadne.com> In-Reply-To: <87efkfyxok.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.164] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyM2K7uq79rQ1RBu9Wylh8/bGJzeLliTIH Jo/J+78yeyxZ8pMpgCmKyyYlNSezLLVI3y6BK2P/6kWMBQ+4K16+3sDYwDiHs4uRk0NCwERi 6YEupi5GLg4hgcOMEu9fP2WDcJYwSjzrusrexcjBwSZgIdH9TxvEFBHQlOhYkAPSywxkPtq5 lwnEFhawkWi9eJ4VxBYRsJWYvGwKE4RtJLHr5At2EJtFQFXi2v8WsBpeAV+Jt48ns0Ksms4o cfntKbAEp4CxRMuj5WA2o4CYxPdTa5gglolL3HoynwniaAGJJXvOM0PYohIvH/9jhbCVJM5+ mcIGUa8jsWD3JyhbW2LZwtfMEIsFJU7OfMIygVF0FpKxs5C0zELSMgtJywJGllWMosWpxUm5 6UZGeqlFmcnFxfl5enmpJZsYgVFycMtvgx2ML587HmIU4GBU4uF9fmZDlBBrYllxZe4hRgkO ZiURXvVooBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXHek568UUIC6YklqdmpqQWpRTBZJg5OqQZG Cf/C2MV96U/vWGQKPJt+ZerEsHaJc7cnHt5h+WyRaaqN29P9y7mZlT1uHVQ2TlzU1xZzI+CY n9PRj9P1xSImro/peX3+f58ut0q1b2qJ5/sZZyadq73Bmvqx77TIQ4FPuj8lczNjbwVGWx74 +NnX4T/LtaqvQsISq5M/BemJua98ciT0QmugEktxRqKhFnNRcSIAsAd56I4CAAA= Archived-At: Subject: Re: [sipcore] sip-push: Recongizing the re-REGISTER 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, 20 Mar 2018 09:54:11 -0000 Hi, >> As far as matching the INVITE with the REGISTER, you can use the pn-=20 >> parameters for that. > >That makes sense, but as I said before, "This needs to be spelled out, as = almost all >elements of the registration can change over time." The curren= t text doesn't really specify >what the proxy needs to do. I agree. I will add text. It seems like I forgot to say that in my previous= reply :) >> Note that the case where the R-URI and registered contact won't match=20 >> is when the registrar forwards an INVITE towards the proxy at the same=20 >> time when the UA sends a re-registration with a new contact. So, the=20 >> R-URI of the INVITE will contain the "old" contact, while the 200 OK=20 >> response to the REGISTER will contain the new contact. > >Yes, that's one of my primary concerns, as I don't see any guarantee that = a newly awakend >UA can obtain the same IP address as it had before. I gat= her that in the environment >you're currently working in, that's the case, = but it seems like we want to avoid designing >that restriction into the mec= hanism. As we know, if the IP address changes the request is rejected by the proxy = with 556. Then, the registrar can of course be smart enough to figure out w= hat is going on, so when it receives the 556 response it places the new con= tact in the R-URI of the INVITE and tries to send it towards the UA again. = But I don't think we need to specify such behaviour. Regards, Christer From nobody Tue Mar 20 07:58:09 2018 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 D0F1412E8D1 for ; Tue, 20 Mar 2018 07:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 GhDSTI68uJ8M for ; Tue, 20 Mar 2018 07:58:02 -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 A2DAA12D881 for ; Tue, 20 Mar 2018 07:58:02 -0700 (PDT) X-AuditID: 1207440c-e35ff70000000ab3-89-5ab12176b4df 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 58.FF.02739.77121BA5; Tue, 20 Mar 2018 10:57:59 -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 w2KEvv6w001074 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 20 Mar 2018 10:57:58 -0400 To: sipcore@ietf.org References: <7594FB04B1934943A5C02806D1A2204B6C20E97D@ESESSMB109.ericsson.se> From: Paul Kyzivat Message-ID: <4fb49fec-a63e-3375-fa92-bf33f756db96@alum.mit.edu> Date: Tue, 20 Mar 2018 10:57:56 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C20E97D@ESESSMB109.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFIsWRmVeSWpSXmKPExsUixO6iqFuhuDHKYN5/QYuvPzaxOTB6LFny kymAMYrLJiU1J7MstUjfLoEr4+u5acwFW7gqJs6exd7AuJ6ji5GTQ0LARGJl7wXWLkYuDiGB HUwSz7afhXJ+MEn8mNHA3sXIwSEsYCrx5KgNSIOIgIjEs+n/2EBsIQFfiddv+sFsNgEtiTmH /rOA2LwC9hJPN05kBrFZBFQlZvz5DBYXFUiTuNS8lRmiRlDi5MwnYHFOAT+JXx/2MYLYzAK2 Enfm7maGsMUlbj2ZzwRhy0tsfzuHeQIj/ywk7bOQtMxC0jILScsCRpZVjHKJOaW5urmJmTnF qcm6xcmJeXmpRbqGermZJXqpKaWbGCFBybOD8ds6mUOMAhyMSjy8EyQ2RgmxJpYVV+YeYpTk YFIS5e38tSFKiC8pP6UyI7E4I76oNCe1+BCjBAezkghvpgJQOW9KYmVValE+TEqag0VJnFd1 ibqfkEB6YklqdmpqQWoRTFaGg0NJgrcQpFGwKDU9tSItM6cEIc3EwQkynAdo+D15kOHFBYm5 xZnpEPlTjJYcq9Y+bGPmaLn4BEjeePG6jVmIJS8/L1VKnLcWZKgASENGaR7cTFiSecUoDvSi MK8CSBUPMEHBTX0FtJAJaGH2zA0gC0sSEVJSDYxLVu97M4v1t80qGdkIi0vPayc8XeDJ2Sfk paYpMrlz7h3Hr5v43skJarwoPP28YKm/sYp3/qWPJZx2tp48Ad9tC08kNst69iyKdzBz3Ltw sveqIxOaTlgH8EW023x+mN4a6iWxYP7pr7LW67R2H5r/5fUPv2vHfGRrDBq8GXUdz3ziT7K5 JKLEUpyRaKjFXFScCAAOtSoDDQMAAA== Archived-At: Subject: Re: [sipcore] IETF#101: Session-timer slides 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, 20 Mar 2018 14:58:07 -0000 Christer, On 3/19/18 5:50 AM, Christer Holmberg wrote: > Hi, > > As some people are going to participate remotely, before I upload the > slides I have put the current version on GitHub. > > https://github.com/cdh4u/draft-sessiontimer-race/blob/master/IETF101_SIPCORE_SESSION-RACE.pdf > > We will discuss the technical stuff during the meeting, but if there is > something you think could be clarified then please let me know. I went and reviewed the draft and rfc again, and I still think the fix in your 3.1 (to section 7.2 of 4028) is over broad. Consider a case where a session timer has already been established between Alice and Bob. We are mid-dialog and there are no transactions in progress. Now Alice decides she wants to disable the session timer. How can she do that? Following 4028, she does that by sending an INVITE or UPDATE with no Session-Expires. The response to that also has no Session-Expires, and then session timer is cancelled. But with your revision, because the request did not contain Session-Expires, the response does not cancel the session timer. To avoid the problem, the behavior of leaving a s-t running after receiving a response without Session-Expires must be limited to UPDATE transactions embedded within INVITE transactions. Thanks, Paul From nobody Tue Mar 20 08:35:17 2018 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 D0A09127077 for ; Tue, 20 Mar 2018 08:35:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 joizce9CdIQF for ; Tue, 20 Mar 2018 08:35:14 -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 12D57126579 for ; Tue, 20 Mar 2018 08:35:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1521560112; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=JbtXjAqUTTxeMmE2Jakv27oo20uyxcF8x21E3KVNmSA=; b=IJ0O6FOTkEIuePizYfDnqbz7ekVCJ2ACxBf/NbvKGcsA7k1nMBubQkpzF2WDxA4N +71Ot4Fz2Blr5JUZHnxGefoOpAefrLUYWCzehtPpRzJNPM5MXQGUTcEnV3vUKqgc 1qKyUN2s54kWs+JLSEBaYFJq+s9QpeCZcr4Mriy9k7A=; X-AuditID: c1b4fb30-6ebff7000000095a-b2-5ab12a300591 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 14.AC.02394.03A21BA5; Tue, 20 Mar 2018 16:35:12 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.172]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0382.000; Tue, 20 Mar 2018 16:35:11 +0100 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] IETF#101: Session-timer slides Thread-Index: AdO/ZxYTW+Gr+7RqQ8muZoBFJ0+HigA7FxwAAALkA5A= Date: Tue, 20 Mar 2018 15:35:10 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B6C212F94@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B6C20E97D@ESESSMB109.ericsson.se> <4fb49fec-a63e-3375-fa92-bf33f756db96@alum.mit.edu> In-Reply-To: <4fb49fec-a63e-3375-fa92-bf33f756db96@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.170] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUyM2J7iK6B1sYog977fBYrNhxgtfj6YxOb A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJXRfPkLS0EnX8WK+5dZGhhXcHcxcnJICJhI HJr+jRHEFhI4zCix6TpvFyMXkL2EUeL01I1MXYwcHGwCFhLd/7RBakQEAiWuLpnADGILC5hK zD/6lBkibibx5u9edgjbSuLfr+NgNouAqsSibz9YQWxeAV+Jz5cusULsamaUmPtGHcTmFHCQ 2PfiLlg9o4CYxPdTa5hAbGYBcYlbT+YzQdwpILFkz3lmCFtU4uXjf6wQtpLEmU3PWSDqdSQW 7P7EBmFrSyxb+JoZYq+gxMmZT1gmMIrMQjJ2FpKWWUhaZiFpWcDIsopRtDi1OCk33chIL7Uo M7m4OD9PLy+1ZBMjMBoObvltsIPx5XPHQ4wCHIxKPLxlihujhFgTy4orcw8xSnAwK4nwZioA hXhTEiurUovy44tKc1KLDzFKc7AoifOe9OSNEhJITyxJzU5NLUgtgskycXBKNTAymUyuDWdc LJt0bYLpfbs33C8edltb9ZeUv4hdxGGqYBITtVhA6uGHvaoRG8w3L1TfFLfopxq3xc7Lpw0d d7z7eWsp24FXEqc10qdEBp/fasoeEtYZc2X6avZA9cvO+xac7mB3jw512LXzGPvk/Zv2mq6O +58mz9o9/3eL9Uq34w8q6wr2iCkrsRRnJBpqMRcVJwIAFDHRpYICAAA= Archived-At: Subject: Re: [sipcore] IETF#101: Session-timer slides 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, 20 Mar 2018 15:35:16 -0000 Hi Paul, >> As some people are going to participate remotely, before I upload the=20 >> slides I have put the current version on GitHub. >>=20 >> https://github.com/cdh4u/draft-sessiontimer-race/blob/master/IETF101_S >> IPCORE_SESSION-RACE.pdf >>=20 >> We will discuss the technical stuff during the meeting, but if there=20 >> is something you think could be clarified then please let me know. > > I went and reviewed the draft and rfc again, and I still think the fix in= your 3.1 (to section 7.2 of 4028) is over broad. > > Consider a case where a session timer has already been established betwee= n Alice and Bob.=20 > We are mid-dialog and there are no transactions in progress. Now Alice de= cides she wants to disable the session timer. > > How can she do that? Following 4028, she does that by sending an INVITE o= r UPDATE with no Session-Expires.=20 > The response to that also has no Session-Expires, and then session timer = is cancelled. > > But with your revision, because the request did not contain Session-Expir= es, the response does not cancel the session timer. If that's what the text is saying, we need to fix it. My intention is not t= o remove the generic ability to remove the session-timer. Note, though, that I am not going to discuss the text at the meeting. The f= ocus will be on the overall principle. Once we can agree on that, we'll sor= t out the text. > To avoid the problem, the behavior of leaving a s-t running after receivi= ng a response without Session-Expires must be=20 > limited to UPDATE transactions embedded within INVITE transactions. Correct. I think the focus shall be on UPDATE transactions that take place = within INVITE transactions (or, during session-timer negotiations). Regards, Christer From nobody Tue Mar 20 20:05:45 2018 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 974ED124205 for ; Tue, 20 Mar 2018 20:05:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.47 X-Spam-Level: X-Spam-Status: No, score=0.47 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665, TO_NO_BRKTS_PCNT=2.155, 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 zMpOuSdDVur7 for ; Tue, 20 Mar 2018 20:05:41 -0700 (PDT) Received: from resqmta-ch2-03v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE855127876 for ; Tue, 20 Mar 2018 20:05:41 -0700 (PDT) Received: from resomta-ch2-19v.sys.comcast.net ([69.252.207.115]) by resqmta-ch2-03v.sys.comcast.net with ESMTP id yU46esUCPI2m3yU4KelMRv; Wed, 21 Mar 2018 03:05:40 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-19v.sys.comcast.net with SMTP id yU4Je8yTw8pS6yU4JezbFW; Wed, 21 Mar 2018 03:05:40 +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 w2L35c7K012385 for ; Tue, 20 Mar 2018 23:05:38 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id w2L35cva012382; Tue, 20 Mar 2018 23:05:38 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: sipcore@ietf.org Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 20 Mar 2018 23:05:38 -0400 Message-ID: <877eq6yvp9.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfIAypRO8phI2te5kfywuAuHzv97rNefFajq49if+xOc6sYR24wUw8J93OYiNPXxF+d5gXUFHcFNqFZCIwcM7yhK5OfxaUUbUfXG4IVKV2TXtuWvvASm9 NEXi7h6HLpYvH8g7M3qdVeeRwZ/r6motFsWcgi4yKuGqgQJSeJS/LhRO Archived-At: Subject: [sipcore] Allowing "far" proxies in 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, 21 Mar 2018 03:05:43 -0000 I'm thinking that with a few extensions to the current scheme, we could enable sip-push to support "far" proxies, that is, proxies that do not have a close connection to the registrar/redirector of the SIP domain, proxies that (1) cannot be assured of seeing all reregistrations for the AOR, and (2) have no non-standardized way of accessing the registrar. I see supporting "far" proxies quite desirable not only because it broadens the architectures that we support, but also because if "far" proxies are used, the pn-* information *must* be communicated from the UA to the registrar and hence to the implementing proxy using URI parameters of the contact URI -- because that is the only available data path. Without supporting "far" proxies, it is equally easy to use header parameters on the Contact headers of the REGISTER request, and it is an architecturally cleaner use of SIP. Thus, demanding to support "far" proxies alleviates my most persistent objection to the current scheme. This approach seems to be upward-compatible with the current scheme, as an implementation of the current scheme only needs to be changed by adding generation of the pn-aor parameter in registered contact URIs. What I have NOT yet done is see whether this paradigm supports the architectures that Roman has recently mentioned. I anticipate doing that as a reality check. There is a requirement that there be only one registration for a given AOR with particular values of pn-provider/pn-prid/pn-parameter. So a UA can use one PNS subscription for registrations to several AORs, but two different UAs (presumably on the same device) can't use the same PNS subscription when registering to the same AOR. This is, I think, a little looser than the current scheme, which requires that pn-provider/pn-prid/pn-parameter be unique for every registration. The updated behaviors are: When the UA registers, it attaches to the contact URI not only pn-provider/pn-prid/pn-parameter but also pn-aor, which contains the userinfo and hostport parts of the AOR being registered. (E.g., "1234@example.com", which is the AOR with the URI scheme omitted, encoded as "1234%40example.com', because "@" is not allowed in URI parameters.) When the proxy receives an incoming request (whose request URI contains pn-provider and pn-prid), then it must (with certain exceptions) trigger a push notification (using pn-provider, pn-prid, and pn-param). Then it must monitor the status of the registration for the AOR listed in the pn-aor parameter that has the values of pn-provider/pn-prid/pn-parameter, waiting for a reregistration with those properties. It can do this by any method it chooses, including: - Due to the network architecture, it is assured that it is in the path of any such re-REGISTER, and can monitor responses to such REGISTERs. - It can subscribe to 'reg' events for the AOR, waiting for increase in the 'cseq' attribute of the appropriate 'contact' element. When the proxy determines that a reregistration has been done, if the contact URI of the registration is the same as the request URI of the pending request, it must forward the request based on that URI. If a reregistration has been done but the contact URI of the registration is now different than the request URI of the pending request, the proxy MAY reject the request with a 404 response, or it MAY redirect the request to the new contact URI. If no reregistration is done, the proxy MUST reject the request with a 404 response. This updates the example in section 1 to: REGISTER sip:alice@example.com SIP/2.0 Via: SIP/2.0/TCP alicemobile.example.com:5060;branch=z9hG4bKnashds7 Max-Forwards: 70 To: Alice From: Alice ;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: Expires: 7200 Content-Length: 0 It would be helpful if the 'contact' element of 'reg' events (RFC 3680) was extended with an optional attribute 'last-reg', which is the number of seconds since the contact was last updated. This allows a subscriber to directly determine that the UA is awake (due to having recently enough sent a re-REGISTER) and implement If the proxy has knowledge that the UA is awake, and that the UA is able to receive the SIP request without first sending a REGISTER request, the proxy MAY choose to not request a push notification towards the UA (and wait for the associated REGISTER request and 2xx response) before it tries to forward the SIP request towards the UA. This is particularly useful if the proxy has seen a reregistration with a different contact URI and has forwarded the request to a second implementing proxy. If the second proxy subscribes to 'reg' events for the pn-aor, it could tell from the 'last-reg' attribute that the UA is still awake and could skip sending another PNS request to the UA before forwarding the request to the UA. From nobody Wed Mar 21 09:40:54 2018 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 A058712741D for ; Wed, 21 Mar 2018 09:40:52 -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, 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=ericsson.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 f6p2Gp2FJecF for ; Wed, 21 Mar 2018 09:40:45 -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 58EBF126CC7 for ; Wed, 21 Mar 2018 09:40:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1521650443; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=bHrkkACGWW8UWaFWz0LOvvFQ1NYueFuLsjstekILdso=; b=HYNbHMduYPXokb7sDGfyTv0+sCtD91UVG0qRaIsFfXxaJZYQY0epuO92J35ne1V+ Cuo869K66FwhuKFmFPRWdXxw/cQMFbAfAjJS0pSSd6yf4bzAVRPiGsBlSYmocJe7 sVKd7Vb4j63RnUxoYdFMFpw50oeJ7si/w/lQywKcQ/s=; X-AuditID: c1b4fb3a-a61ff70000003647-6c-5ab28b0bd68b Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id F6.2A.13895.B0B82BA5; Wed, 21 Mar 2018 17:40:43 +0100 (CET) Received: from ESESSMB102.ericsson.se ([169.254.2.50]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0382.000; Wed, 21 Mar 2018 17:40:43 +0100 From: Christer Holmberg To: "Dale R. Worley" , "sipcore@ietf.org" Thread-Topic: [sipcore] Allowing "far" proxies in sip-push Thread-Index: AQHTwMGDGhUC9DuUvUqlF78QsGKB3KPavN9w Date: Wed, 21 Mar 2018 16:40:42 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B72DF5CB7@ESESSMB102.ericsson.se> References: <877eq6yvp9.fsf@hobgoblin.ariadne.com> In-Reply-To: <877eq6yvp9.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.164] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyM2K7qy5396YogxezNC2+/tjEZvHyRJkD k8fk/V+ZPZYs+ckUwBTFZZOSmpNZllqkb5fAlTHj/zrmgm6zirMXLzE3MG7X7mLk5JAQMJH4 /vgGWxcjF4eQwGFGifunLrNDOIsZJWYeWMHcxcjBwSZgIdH9D6xBRCBIYlMnSJiTQ1jAUmL2 revMEHEriRc/Z7CAlIsIGEk8faUNYrIIqErMuOwEUsEr4CuxZNkHdhBbCKjixsaXTCA2p4Cx xO4tU8HijAJiEt9PrQGLMwuIS9x6Mp8J4kwBiSV7zjND2KISLx//Y4WwlSTOfpnCBlGvI7Fg 9ycoW1ti2cLXzBB7BSVOznzCMoFRZBaSsbOQtMxC0jILScsCRpZVjKLFqcXFuelGRnqpRZnJ xcX5eXp5qSWbGIGRcHDLb6sdjAefOx5iFOBgVOLhzWvYFCXEmlhWXJl7iFGCg1lJhHfb541R QrwpiZVVqUX58UWlOanFhxilOViUxHmd0iyihATSE0tSs1NTC1KLYLJMHJxSDYxZjOfu/RJa oyZcND95S10ow8U7j44u1jSZ4D61ZHMCu1yGdEqS2PzIfQu1fq4V856V+3vRwz4RbdtHDbGX 5PjunAqepphlcD6z5PfxWXz/Wlz//XlcLMJ5/Rxj2dm7015oZji0TmytbJ8Xf652T4lWqb7c 43N7Ej3aj96NTnddZHzz1dFJK/2UWIozEg21mIuKEwExmxKsgAIAAA== Archived-At: Subject: Re: [sipcore] Allowing "far" proxies in 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, 21 Mar 2018 16:40:53 -0000 Hi, I am not aware of any case where the proxy (no matter whether it is "far" o= r "near") would not receive the REGISTER/re-REGISTER requests.=20 Also, in your "Due to the network architecture..." sentence you seem to imp= ly that the proxy would not receive the initial REGISTER (which is the reas= on pn-aor is needed), but it could receive the re-REGISTER requests. I have= never heard about such use-case. Also, if the proxy does not receive the re-REGISTER request, there may be N= AT issues when the proxy is trying to forward the request (since there is n= o re-REGISTER, Outbound keep-alive etc opening the pin hole). Also, any proxy (no matter whether it is "far" or "near") can use the 'reg'= event package in order to figure out the status of a registration. But, if we want to cover your proxy-out-of-path scenario, we can do that in= a separate draft (similar to the Outbound case). Because, based on the tex= t above, I think it requires a little more thinking than simply defining a = new pn-aor parameter. As I said when this work started, there is an industr= y need for a solution now, the window for providing a standard solution is = narrow, and the assumptions in the current version of the draft meet need. Regards, Christer > I'm thinking that with a few extensions to the current scheme, we could e= nable sip-push to support "far" proxies, that is, proxies > that do not have a close connection to the registrar/redirector of the SI= P domain, proxies that (1) cannot be assured of seeing all > reregistrations for the AOR, and (2) have no non-standardized way of acce= ssing the registrar. > > I see supporting "far" proxies quite desirable not only because it broade= ns the architectures that we support, but also because if "far" > proxies are used, the pn-* information *must* be communicated from the UA= to the registrar and hence to the implementing proxy=20 > using URI parameters of the contact URI -- because that is the only avail= able data path. Without supporting "far" proxies, it is equally=20 > easy to use header parameters on the Contact headers of the REGISTER requ= est, and it is an architecturally cleaner use of SIP. Thus,=20 > demanding to support "far" proxies alleviates my most persistent objectio= n to the current scheme. > > This approach seems to be upward-compatible with the current scheme, as a= n implementation of the current scheme only needs to > be changed by adding generation of the pn-aor parameter in registered con= tact URIs. > > What I have NOT yet done is see whether this paradigm supports the archit= ectures that Roman has recently mentioned. =20 > I anticipate doing that as a reality check. > > There is a requirement that there be only one registration for a given AO= R with particular values of=20 > pn-provider/pn-prid/pn-parameter. So a UA can use one PNS subscription f= or registrations to several=20 > AORs, but two different UAs (presumably on the same device) can't use the= same PNS subscription when=20 > registering to the same AOR. This is, I think, a little looser than the = current scheme, which requires that=20 > pn-provider/pn-prid/pn-parameter be unique for every registration. > > The updated behaviors are: > > When the UA registers, it attaches to the contact URI not only pn-provide= r/pn-prid/pn-parameter but=20 > also pn-aor, which contains the userinfo and hostport parts of the AOR be= ing registered.=20 > (E.g., "1234@example.com", which is the AOR with the URI scheme omitted, = encoded as=20 > "1234%40example.com', because "@" is not allowed in URI parameters.) > > When the proxy receives an incoming request (whose request URI contains p= n-provider and pn-prid), then it must (with certain > exceptions) trigger a push notification (using pn-provider, pn-prid, and = pn-param). Then it must monitor the status of the=20 > registration for the AOR listed in the pn-aor parameter that has the valu= es of pn-provider/pn-prid/pn-parameter, waiting for=20 > a reregistration with those properties. It can do this by any method it = chooses, including: > >- Due to the network architecture, it is assured that it is in the > path of any such re-REGISTER, and can monitor responses to such > REGISTERs. > > - It can subscribe to 'reg' events for the AOR, waiting for increase in > the 'cseq' attribute of the appropriate 'contact' element. > >When the proxy determines that a reregistration has been done, if the cont= act URI of the registration is the same as >the request URI of the pending request, it must forward the request based = on that URI. If a reregistration has been=20 >done but the contact URI of the registration is now different than the req= uest URI of the pending request, the proxy=20 >MAY reject the request with a 404 response, or it MAY redirect the request= to the new contact URI. If no reregistration=20 >is done, the proxy MUST reject the request with a 404 response. > >This updates the example in section 1 to: > > REGISTER sip:alice@example.com SIP/2.0 > Via: SIP/2.0/TCP alicemobile.example.com:5060;branch=3Dz9hG4bKnashds7 > Max-Forwards: 70 > To: Alice > From: Alice ;tag=3D456248 > Call-ID: 843817637684230@998sdasdh09 > CSeq: 1826 REGISTER > Contact: pn-provider=3Dacme; > pn-param=3Dacme-param; > pn-prid=3DZTY4ZDJlMzODE1NmUgKi0K; > pn-aor=3Dalice%40example.com> > Expires: 7200 > Content-Length: 0 > > It would be helpful if the 'contact' element of 'reg' events (RFC > 3680) was extended with an optional attribute 'last-reg', which is the nu= mber=20 > of seconds since the contact was last updated. This allows a subscriber = to directly=20 > determine that the UA is awake (due to having recently enough sent a re-R= EGISTER) and implement > > If the proxy has knowledge that the UA is awake, and that the UA is > able to receive the SIP request without first sending a REGISTER > request, the proxy MAY choose to not request a push notification > towards the UA (and wait for the associated REGISTER request and 2xx > response) before it tries to forward the SIP request towards the UA. > > This is particularly useful if the proxy has seen a reregistration with a= different contact URI and has=20 > forwarded the request to a second implementing proxy. If the second prox= y subscribes to 'reg' events=20 > for the pn-aor, it could tell from the 'last-reg' attribute that the UA i= s still awake and could skip sending=20 > another PNS request to the UA before forwarding the request to the UA. _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From nobody Wed Mar 21 10:54:45 2018 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 4B8FD12762F for ; Wed, 21 Mar 2018 10:54:43 -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=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 9IODPF2qcZHP for ; Wed, 21 Mar 2018 10:54:41 -0700 (PDT) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::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 0F1EE12EC15 for ; Wed, 21 Mar 2018 10:54:27 -0700 (PDT) Received: by mail-vk0-x229.google.com with SMTP id y127so3614789vky.9 for ; Wed, 21 Mar 2018 10:54:27 -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=T4Y6TNTi42ahSqegZ1kQ69pO5ioA7qucMS0jqU4LR5E=; b=INblqCvMpnlPA3GpmO6VIvgyXzxHXkjMQyS1fgG4r0KXSOB/2L/UIFeVw6sq39lMGO q7qZDQwvs38oCKnjFeq23Rt7mHDudByIL7YpEOm5ripGuWjMC539/BQO2FAi89bQ/4OQ uGzfqHvRGzuGL4mVCyBCW6c25aiFDD/ZBDZI6DmMpCEhfj1mgKCQPN6ruvhv3XG9wltE zkd++S2TtJqasjNmHZspnIsdgQdKF2GzNI20J9yVrdVsmD8fOupc30KYTzR04E76CUD4 QJXb7a4ASJkLTreGd11/9P/WG1BRZWcZzxAU9zdEDEys2ZQkDX4Bj8A4qxm+9SKodjpU SwRA== 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=T4Y6TNTi42ahSqegZ1kQ69pO5ioA7qucMS0jqU4LR5E=; b=JsqMODXLMSJQui9V8SKQmukZ7G86UYoT8UIZAl5+zvsDFlvAZkRhB6x7uM55tAV4sC wMrbhZDb3YcQEhFoRS3rA9M65fDlpDS8hTCA41wldFNKFdps1Cf61rL0Y8VQ6HSexT6F /TM9XBakCHTzS050aprqeu8lXpsHcUccMCwjM0DGVPrYf4KMM8B40dx0RTAI5JCK/6YW RPtZBVvI6FeM9pWEftzPBNZ+1NXtwEXrqwYyu6U+4ei6ktmWAIh29VMJgZVCS7aaakIp KzSRwl5nCgI29Aa4IGQP/dojcNw7gflQ0xY5QmCvPkV7aOrvHgn+7h6U4KHd7sgzmYmc 2++g== X-Gm-Message-State: AElRT7GQkeiYA9LIOnAf+uZUK9ozFXgthlDH3ciP4//RXGCszZ47tGKU EgXrK7E1ihSwJb9PcHApQGnRg5ykHn1JxPCmySw= X-Google-Smtp-Source: AG47ELsc7ezdBv+RyugBJLOsWaifNb0LGsxGYCDCatQfkiI/hDIccTKpxWObsxPs80GSOqU+05/TOwFMPR4KpKbsvLo= X-Received: by 10.31.83.197 with SMTP id h188mr13735281vkb.84.1521654866199; Wed, 21 Mar 2018 10:54:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.50.68 with HTTP; Wed, 21 Mar 2018 10:54:25 -0700 (PDT) In-Reply-To: <87vaexg01a.fsf@hobgoblin.ariadne.com> References: <87vaexg01a.fsf@hobgoblin.ariadne.com> From: Andy Hutton Date: Wed, 21 Mar 2018 17:54:25 +0000 Message-ID: To: "Dale R. Worley" Cc: Christer Holmberg , rifaat.sy@gmail.com, SIPCORE Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [sipcore] ABNF: request-digest: 32 characters, only 32 characters and nothing but 32 characters? 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, 21 Mar 2018 17:54:43 -0000 I would also like to see draft-yusef-sipcore-digest-scheme adopted. Andy On 16 February 2018 at 02:07, Dale R. Worley wrote: > Christer Holmberg writes: >> I realised that Rifaat's draft actually updates the ABNF (by removing the >> 32 characters restriction), so we wouldn't need anything in addition to >> that. > > I was going to say, What is the name of the draft?, but it's > draft-yusef-sipcore-digest-scheme, which is dated last September, which > is probably why I remember it. > > It not only updates the ABNF in RFC 3261, it also connects it with RFC > 7611. > > ---> So, I call for adoption of draft-yusef-sipcore-digest-scheme as a > WG draft. > > Dale > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Wed Mar 21 14:49:17 2018 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 036EB124D6C for ; Wed, 21 Mar 2018 14:49:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 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, URIBL_BLOCKED=0.001, WEIRD_PORT=0.001] 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 TaEDn8qoRB-U for ; Wed, 21 Mar 2018 14:49:13 -0700 (PDT) Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e:c05::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 34B53127342 for ; Wed, 21 Mar 2018 14:49:13 -0700 (PDT) Received: by mail-pg0-x235.google.com with SMTP id f10so2297457pgs.9 for ; Wed, 21 Mar 2018 14:49:13 -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=TpD/GKg0ZT7dvziXfO8YYaqJQIq3N12seI6ncvHPQPY=; b=IuaqnSPMBUWY4blJhsVRWiXRr6WVhrgcdEBJ+C9W7y4irE9P7c4DCE/a2q4j506yid uDoYLao4bnipCHMRvniDZPKfWIgQLcPYIXwZlvngY3mL9twHv+oBwYzyE/qPHYXRU4tk upSeRwvax6l5gudt029e77xfJfhjyDGEj6XHyjFlH8vXDrrEBTHHk/2PcRU/ZhKv/RGa HoJi6Agas64MtMoGk2v37eKnRknH7NUWn0Pugq4wB/QmjPLOedN84bv8SaclQuWJwkn+ 53nxy1zVXIaZhNwj/WfLUn+iKqTwtSqcVTwk1VxjPQ6agGNE9+Bqp0gkDeSrZ5lJDqxp qeeQ== 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=TpD/GKg0ZT7dvziXfO8YYaqJQIq3N12seI6ncvHPQPY=; b=byXbp418Yit/t4UZfqbMKQF3ihkOPCzjhaqHlCQBGnFzFxbH/e0iQoZoDeN485i6ZP F2vV3eILU8IY05SMRoSOY/31BPKA/xOLmqpoOsmvQ1KD6nC81T7j4wF6p6rbpgYzhltj TOc9+CmpatF/7ykaeIp/ycP3rr7hf8x0bn9G1CU+r1Sv5ni7tDZXIIU7n9YswBlFrxTe RqFaXJ5uVLHE1qymxbtltfIPHpz2cikQYIkA8xyYBoM8tQ/giC+9kO7jWHki5DX03v93 S4agdGk4kDNiipjV1kZTcGA23TqaTMfwZZcS8BTzaT0hvd/GnH0gX7sD3blmKTlAFzfU yUsw== X-Gm-Message-State: AElRT7HPWASwty6ZpaHBnczkmnflCFW9bNMIVP8di8W1CuG2TdDDIXYH n/rb4tbElePohfsMCub2czM529y3 X-Google-Smtp-Source: AG47ELtiVC/JGade5xVx9+HOB9Zo+VQThxkVd6r9ATIleANOd+vxCxrjFNnEbyQcOJJx9XkJD6z+CQ== X-Received: by 10.98.247.9 with SMTP id h9mr18228657pfi.212.1521668952408; Wed, 21 Mar 2018 14:49:12 -0700 (PDT) Received: from mail-pg0-f49.google.com (mail-pg0-f49.google.com. [74.125.83.49]) by smtp.gmail.com with ESMTPSA id n13sm11345922pfg.45.2018.03.21.14.49.11 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Mar 2018 14:49:11 -0700 (PDT) Received: by mail-pg0-f49.google.com with SMTP id n11so2463008pgp.4 for ; Wed, 21 Mar 2018 14:49:11 -0700 (PDT) X-Received: by 10.98.10.156 with SMTP id 28mr10290263pfk.33.1521668950906; Wed, 21 Mar 2018 14:49:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.156.15 with HTTP; Wed, 21 Mar 2018 14:49:10 -0700 (PDT) In-Reply-To: <877eq6yvp9.fsf@hobgoblin.ariadne.com> References: <877eq6yvp9.fsf@hobgoblin.ariadne.com> From: Roman Shpount Date: Wed, 21 Mar 2018 17:49:10 -0400 X-Gmail-Original-Message-ID: Message-ID: To: "Dale R. Worley" Cc: SIPCORE Content-Type: multipart/alternative; boundary="001a1143227c48dd200567f3295c" Archived-At: Subject: Re: [sipcore] Allowing "far" proxies in 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, 21 Mar 2018 21:49:16 -0000 --001a1143227c48dd200567f3295c Content-Type: text/plain; charset="UTF-8" Dale, How does "far" proxy gets the request from registration server when new dialog creating request is sent to the registrar (AOR)? How does registration server knows it needs to send messages to edge proxy and not to the UA Contact? The standard way to do it is to use Path header which will cause registration server to insert the Route header for edge proxy. The "hack" to do this is for proxy to modify registration contact when forwarding message to the registrar and replace it with proxy address with some parameters. What are you proposing here? Regards, _____________ Roman Shpount On Tue, Mar 20, 2018 at 11:05 PM, Dale R. Worley wrote: > I'm thinking that with a few extensions to the current scheme, we > could enable sip-push to support "far" proxies, that is, proxies that > do not have a close connection to the registrar/redirector of the SIP > domain, proxies that (1) cannot be assured of seeing all > reregistrations for the AOR, and (2) have no non-standardized way of > accessing the registrar. > > I see supporting "far" proxies quite desirable not only because it > broadens the architectures that we support, but also because if "far" > proxies are used, the pn-* information *must* be communicated from the > UA to the registrar and hence to the implementing proxy using URI > parameters of the contact URI -- because that is the only available > data path. Without supporting "far" proxies, it is equally easy to > use header parameters on the Contact headers of the REGISTER request, > and it is an architecturally cleaner use of SIP. Thus, demanding to > support "far" proxies alleviates my most persistent objection to the > current scheme. > > This approach seems to be upward-compatible with the current scheme, as > an implementation of the current scheme only needs to be changed by > adding generation of the pn-aor parameter in registered contact URIs. > > What I have NOT yet done is see whether this paradigm supports the > architectures that Roman has recently mentioned. I anticipate doing > that as a reality check. > > There is a requirement that there be only one registration for a given > AOR with particular values of pn-provider/pn-prid/pn-parameter. So a > UA can use one PNS subscription for registrations to several AORs, > but two different UAs (presumably on the same device) can't use the > same PNS subscription when registering to the same AOR. This is, I > think, a little looser than the current scheme, which requires that > pn-provider/pn-prid/pn-parameter be unique for every registration. > > The updated behaviors are: > > When the UA registers, it attaches to the contact URI not only > pn-provider/pn-prid/pn-parameter but also pn-aor, which contains the > userinfo and hostport parts of the AOR being registered. (E.g., > "1234@example.com", which is the AOR with the URI scheme omitted, > encoded as "1234%40example.com', because "@" is not allowed in URI > parameters.) > > When the proxy receives an incoming request (whose request URI > contains pn-provider and pn-prid), then it must (with certain > exceptions) trigger a push notification (using pn-provider, pn-prid, > and pn-param). Then it must monitor the status of the registration > for the AOR listed in the pn-aor parameter that has the values of > pn-provider/pn-prid/pn-parameter, waiting for a reregistration with > those properties. It can do this by any method it chooses, including: > > - Due to the network architecture, it is assured that it is in the > path of any such re-REGISTER, and can monitor responses to such > REGISTERs. > > - It can subscribe to 'reg' events for the AOR, waiting for increase in > the 'cseq' attribute of the appropriate 'contact' element. > > When the proxy determines that a reregistration has been done, if the > contact URI of the registration is the same as the request URI of the > pending request, it must forward the request based on that URI. If a > reregistration has been done but the contact URI of the registration > is now different than the request URI of the pending request, the > proxy MAY reject the request with a 404 response, or it MAY redirect > the request to the new contact URI. If no reregistration is done, the > proxy MUST reject the request with a 404 response. > > This updates the example in section 1 to: > > REGISTER sip:alice@example.com SIP/2.0 > Via: SIP/2.0/TCP alicemobile.example.com:5060;branch=z9hG4bKnashds7 > Max-Forwards: 70 > To: Alice > From: Alice ;tag=456248 > Call-ID: 843817637684230@998sdasdh09 > CSeq: 1826 REGISTER > Contact: pn-provider=acme; > pn-param=acme-param; > pn-prid=ZTY4ZDJlMzODE1NmUgKi0K; > pn-aor=alice%40example.com> > Expires: 7200 > Content-Length: 0 > > It would be helpful if the 'contact' element of 'reg' events (RFC > 3680) was extended with an optional attribute 'last-reg', which is the > number of seconds since the contact was last updated. This allows a > subscriber to directly determine that the UA is awake (due to having > recently enough sent a re-REGISTER) and implement > > If the proxy has knowledge that the UA is awake, and that the UA is > able to receive the SIP request without first sending a REGISTER > request, the proxy MAY choose to not request a push notification > towards the UA (and wait for the associated REGISTER request and 2xx > response) before it tries to forward the SIP request towards the UA. > > This is particularly useful if the proxy has seen a reregistration > with a different contact URI and has forwarded the request to a second > implementing proxy. If the second proxy subscribes to 'reg' events > for the pn-aor, it could tell from the 'last-reg' attribute that the > UA is still awake and could skip sending another PNS request to the > UA before forwarding the request to the UA. > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --001a1143227c48dd200567f3295c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dale,

How does "far" proxy ge= ts the request from registration server when new dialog creating request is= sent to the registrar (AOR)? How does registration server knows it needs t= o send messages to edge proxy and not to the UA Contact?

The standard way to do it is to use Path header which will cause reg= istration server to insert the Route header for edge proxy.
The &= quot;hack" to do this is for proxy to modify registration contact when= forwarding message to the registrar and replace it with proxy address with= some parameters.

What are you proposing here?

Regards,

_____________
Roman Shpount

On Tue, Mar 20, 2018 at 11:05 PM, Dale R. Wo= rley <worley@ariadne.com> wrote:
I'm thinking that with a few extensions to the current scheme, = we
could enable sip-push to support "far" proxies, that is, proxies = that
do not have a close connection to the registrar/redirector of the SIP
domain, proxies that (1) cannot be assured of seeing all
reregistrations for the AOR, and (2) have no non-standardized way of
accessing the registrar.

I see supporting "far" proxies quite desirable not only because i= t
broadens the architectures that we support, but also because if "far&q= uot;
proxies are used, the pn-* information *must* be communicated from the
UA to the registrar and hence to the implementing proxy using URI
parameters of the contact URI -- because that is the only available
data path.=C2=A0 Without supporting "far" proxies, it is equally = easy to
use header parameters on the Contact headers of the REGISTER request,
and it is an architecturally cleaner use of SIP.=C2=A0 Thus, demanding to support "far" proxies alleviates my most persistent objection to = the
current scheme.

This approach seems to be upward-compatible with the current scheme, as
an implementation of the current scheme only needs to be changed by
adding generation of the pn-aor parameter in registered contact URIs.

What I have NOT yet done is see whether this paradigm supports the
architectures that Roman has recently mentioned.=C2=A0 I anticipate doing that as a reality check.

There is a requirement that there be only one registration for a given
AOR with particular values of pn-provider/pn-prid/pn-parameter.=C2=A0 = So a
UA can use one PNS subscription for registrations to several AORs,
but two different UAs (presumably on the same device) can't use the
same PNS subscription when registering to the same AOR.=C2=A0 This is, I think, a little looser than the current scheme, which requires that
pn-provider/pn-prid/pn-parameter be unique for every registration.

The updated behaviors are:

When the UA registers, it attaches to the contact URI not only
pn-provider/pn-prid/pn-parameter but also pn-aor, which contains the userinfo and hostport parts of the AOR being registered.=C2=A0 (E.g.,
"1234@example.com", which= is the AOR with the URI scheme omitted,
encoded as "1234%40example.com', because "@" is not allow= ed in URI
parameters.)

When the proxy receives an incoming request (whose request URI
contains pn-provider and pn-prid), then it must (with certain
exceptions) trigger a push notification (using pn-provider, pn-prid,
and pn-param).=C2=A0 Then it must monitor the status of the registration for the AOR listed in the pn-aor parameter that has the values of
pn-provider/pn-prid/pn-parameter, waiting for a reregistration with those properties.=C2=A0 It can do this by any method it chooses, including:=

- Due to the network architecture, it is assured that it is in the
=C2=A0 path of any such re-REGISTER, and can monitor responses to such
=C2=A0 REGISTERs.

- It can subscribe to 'reg' events for the AOR, waiting for increas= e in
=C2=A0 the 'cseq' attribute of the appropriate 'contact' el= ement.

When the proxy determines that a reregistration has been done, if the
contact URI of the registration is the same as the request URI of the
pending request, it must forward the request based on that URI.=C2=A0 If a<= br> reregistration has been done but the contact URI of the registration
is now different than the request URI of the pending request, the
proxy MAY reject the request with a 404 response, or it MAY redirect
the request to the new contact URI.=C2=A0 If no reregistration is done, the=
proxy MUST reject the request with a 404 response.

This updates the example in section 1 to:

=C2=A0 =C2=A0 =C2=A0REGISTER sip= :alice@example.com SIP/2.0
=C2=A0 =C2=A0 =C2=A0Via: SIP/2.0/TCP alicemobile.example.com:5060;branch=3Dz9hG4bKnashds7
=C2=A0 =C2=A0 =C2=A0Max-Forwards: 70
=C2=A0 =C2=A0 =C2=A0To: Alice <sip:alice@example.com>
=C2=A0 =C2=A0 =C2=A0From: Alice <sip:alice@example.com>;tag=3D456248
=C2=A0 =C2=A0 =C2=A0Call-ID: 843817637684230@998sdasdh09
=C2=A0 =C2=A0 =C2=A0CSeq: 1826 REGISTER
=C2=A0 =C2=A0 =C2=A0Contact: <sip:alice@alicemobile.example.com;
=C2=A0 =C2=A0 =C2=A0 =C2=A0pn-provider=3Dacme;
=C2=A0 =C2=A0 =C2=A0 =C2=A0pn-param=3Dacme-param;
=C2=A0 =C2=A0 =C2=A0 =C2=A0pn-prid=3DZTY4ZDJlMzODE1NmUgKi0K;
=C2=A0 =C2=A0 =C2=A0 =C2=A0pn-aor=3Dalice%40example.com>
=C2=A0 =C2=A0 =C2=A0Expires: 7200
=C2=A0 =C2=A0 =C2=A0Content-Length: 0

It would be helpful if the 'contact' element of 'reg' event= s (RFC
3680) was extended with an optional attribute 'last-reg', which is = the
number of seconds since the contact was last updated.=C2=A0 This allows a subscriber to directly determine that the UA is awake (due to having
recently enough sent a re-REGISTER) and implement

=C2=A0 =C2=A0If the proxy has knowledge that the UA is awake, and that the = UA is
=C2=A0 =C2=A0able to receive the SIP request without first sending a REGIST= ER
=C2=A0 =C2=A0request, the proxy MAY choose to not request a push notificati= on
=C2=A0 =C2=A0towards the UA (and wait for the associated REGISTER request a= nd 2xx
=C2=A0 =C2=A0response) before it tries to forward the SIP request towards t= he UA.

This is particularly useful if the proxy has seen a reregistration
with a different contact URI and has forwarded the request to a second
implementing proxy.=C2=A0 If the second proxy subscribes to 'reg' e= vents
for the pn-aor, it could tell from the 'last-reg' attribute that th= e
UA is still awake and could skip sending another PNS request to the
UA before forwarding the request to the UA.

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

--001a1143227c48dd200567f3295c-- From nobody Wed Mar 21 20:18:48 2018 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 D1D4C12D80F for ; Wed, 21 Mar 2018 20:18:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.686 X-Spam-Level: X-Spam-Status: No, score=-1.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 PlFu-CGSyk4V for ; Wed, 21 Mar 2018 20:18:42 -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 B8E0012D7EF for ; Wed, 21 Mar 2018 20:18:42 -0700 (PDT) Received: from resomta-ch2-01v.sys.comcast.net ([69.252.207.97]) by resqmta-ch2-06v.sys.comcast.net with ESMTP id yqkLe0J1uKNfxyqkTew4RB; Thu, 22 Mar 2018 03:18:41 +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 yqkRe419ywxAPyqkSe4XAi; Thu, 22 Mar 2018 03:18:41 +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 w2M3IcUR012059; Wed, 21 Mar 2018 23:18:38 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id w2M3IcAD012056; Wed, 21 Mar 2018 23:18:38 -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: Roman Shpount Cc: christer.holmberg@ericsson.com, sipcore@ietf.org In-Reply-To: (roman@telurix.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 21 Mar 2018 23:18:38 -0400 Message-ID: <87k1u4yf01.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfKXfCt47iqsM6kUqRWseMu/cv1c/W/W9mMuoltDLBP+b/YpgNyWSwuiiTxocpq8t+6DB7/gEhkKnB55PPFSv59j9dsI/b8N3TLQ0SMVNJyxlpWy4AGXk GFHeDlSjPdWARVXK35ShxDbkmhDiYSqvOkv0zqtvxZvqb+1rpsm/LYxuTx/L8K3rJ/J62mETtOIOHldJwyAlkE1Ah2oSpzZNIbR6HEdeu7vp4wik64x0eaXw Archived-At: Subject: Re: [sipcore] sip-push: Recongizing the re-REGISTER 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, 22 Mar 2018 03:18:47 -0000 Roman Shpount writes: > 2. An implementation where edge proxy and registration server are separate > and communicate through standard communication mechanisms. For this > registration path extension and sip-instance are used to associate dialog > creating and non-dialog messages with registrations and push parameters. > This implementation would deal with multiple registrations per AOR and > clients changing IPs. It would also use SIP Outbound keep alive to maintain > flows to the client when client UA is active and only use SIP Push to > re-establish flows when SIP UA is suspended. My conception is that in this case, where the implementing proxy and registration server are separate, and so the implementing proxy can be viewed as an edge proxy, we are adding a further complication: When the UA awakens, its new REGISTER may go through a *different* edge proxy (and may register different contact URI). I believe that that case is unavoidable when we have proxy separation. I also believe that we can accommodate this situation with minimal changes in the draft. The mechanism I've proposed is similar to the system you describe, with the pn-provider/pn-prid taking the place of the opaque parameter, and matching between the REGISTER and the incoming request done by pn-provider/pn-prid rather than sip-instance/reg-id. However, I do believe that what I have written is not sufficient for situations where the UA is using SIP Outbound, and needs to be updated to support SIP Outbound. I suspect that this only requires elaborating the conditions for "recognizing the matching REGISTER". Dale From nobody Wed Mar 21 20:26:44 2018 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 E755C12D80F for ; Wed, 21 Mar 2018 20:26:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.686 X-Spam-Level: X-Spam-Status: No, score=-1.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 Ky5UhtTjW53F for ; Wed, 21 Mar 2018 20:26:42 -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 3146912D7EF for ; Wed, 21 Mar 2018 20:26:42 -0700 (PDT) Received: from resomta-ch2-19v.sys.comcast.net ([69.252.207.115]) by resqmta-ch2-06v.sys.comcast.net with ESMTP id yqs0e0JRXKNfxyqsDew4xn; Thu, 22 Mar 2018 03:26:41 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-19v.sys.comcast.net with SMTP id yqsCeE1zq8pS6yqsDe1prC; Thu, 22 Mar 2018 03:26:41 +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 w2M3QdG9012428; Wed, 21 Mar 2018 23:26:39 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id w2M3Qd9j012425; Wed, 21 Mar 2018 23:26:39 -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: Roman Shpount Cc: sipcore@ietf.org In-Reply-To: (roman@telurix.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 21 Mar 2018 23:26:39 -0400 Message-ID: <87fu4syemo.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfCMPRcFAV62Xq0itAQ3vRCFlwtw2pMHds+qrP+jmg4UuDe3Rc5vuhmE7YVGtovQaQR6eEgGXQHu5elc/ciLKTmUhPb6WxS89BuH0HYoia+TfXvGBPu4s dz+15ho9cFaB9b+bO+aa+itsowhnZ/XFnM+IQYFGzvgqZ3evm6y9sXpF5SdBI6dAFLK2Kc6ElbjCmA== Archived-At: Subject: Re: [sipcore] Allowing "far" proxies in 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: Thu, 22 Mar 2018 03:26:43 -0000 Roman Shpount writes: > How does "far" proxy gets the request from registration server when new > dialog creating request is sent to the registrar (AOR)? How does > registration server knows it needs to send messages to edge proxy and not > to the UA Contact? > > The standard way to do it is to use Path header which will cause > registration server to insert the Route header for edge proxy. > The "hack" to do this is for proxy to modify registration contact when > forwarding message to the registrar and replace it with proxy address with > some parameters. True, the standard and general way to ensure that a proxy is on the path for an intial request is for the registration to use a Path header. However, it is also possible that the proxy is "naturally" on the path from the SIP domain's redirector to the contact URI, that is, when the redirector sends the request to the contact URI, it will pass through the proxy. I believe that this latter pattern is what is envisioned in the current draft. Indeed, the current draft seems to assume that every initial request forwarded by the redirector will pass through the same proxy. What makes the more general situation complicated is that when the UA awakens, its re-registration may pass through a different edge proxy, changing the Path of the registration. Dale From nobody Wed Mar 21 20:32:23 2018 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 4EF1712D7EF for ; Wed, 21 Mar 2018 20:32:21 -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 RFgAzLGxbpgY for ; Wed, 21 Mar 2018 20:32:19 -0700 (PDT) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::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 C02E112D873 for ; Wed, 21 Mar 2018 20:32:19 -0700 (PDT) Received: by mail-pf0-x236.google.com with SMTP id f80so2844114pfa.8 for ; Wed, 21 Mar 2018 20:32:19 -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=AXEytgrPHb/ZFDQc3NtKhZytnGRHKTQuIdORiryqT/w=; b=Kv+dqf7eQUpoN4CcUuG5WfcDhpudsiKEvr8xLM+jKA1p5EFuHGAqIdREpeOinu5de/ jV8lITC8BKhv3cnZLb8sxk0F/WeUW6yFWamOqY5sD9fGN/c7oOGdjYm1kZb5G1ntLuY6 AAV3PrgeqvAOL+ON5udwtNQoaydvPxzEpp28dJJE9Hlpp4Yvt3iTVqebOTyrM8ujCaWH V6i1fwcKx/EhkXorGaFtokUUrB4Z3wBYIyYJ9MYtJmcnYedRv2Wng+g+Dj0b+5V6a6ku fFEyn6OHi4dGU4Mk/qaF+6hiTp9YnBDqXWL4DaTiWqvvvImTu/vyFRLc/w82k0bbdatl OpDQ== 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=AXEytgrPHb/ZFDQc3NtKhZytnGRHKTQuIdORiryqT/w=; b=U/lyU1TwN2VVpwilBnK1Y0vdRl+Jeee2ip2QsXJlifCsd/MzZ5ZzSNUoUBhhuARl/o ej8xg0S/LLc1qcwbJ180i2+QIE/rW3SYYuOn05OWJruo8p7mCnZIbSUPZrKUjU4jH9km wpNtOXaWjTo4wgFavHTZQIUKE3j5etsHPC/i6u5Jw0KqmAq0CCwQcaFWyaXH3q4PN1I3 f9tyacpnC932ZpBLdmJAYGgG0MsLhz1KHI/7NtblEDYk0gSpSMNkM8B2fs3ROQpplzHo 11MF7wx0w2+r/04X+cQDoiQLfxOgNiLzEPHN6764J07Lhu2hKiBrS3WF5RlULMAMI8Ya 75JQ== X-Gm-Message-State: AElRT7ExbLIKgKYIPNvKA2/OArIW4lvf+viVleRH0VpIKPLxnEJ3ej1v bP1l1DBrZkoNYj96snKzG8lSx3B0 X-Google-Smtp-Source: AG47ELuAFwA3q30jCi2iFJEtuEeqINF9BjUAVcj3sq56fk7Du0cjtPYuw6y8kpaoywjXfVEr7K+p3A== X-Received: by 10.99.49.143 with SMTP id x137mr17097341pgx.424.1521689539278; Wed, 21 Mar 2018 20:32:19 -0700 (PDT) Received: from mail-pf0-f169.google.com (mail-pf0-f169.google.com. [209.85.192.169]) by smtp.gmail.com with ESMTPSA id k3sm3520112pfc.1.2018.03.21.20.32.18 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Mar 2018 20:32:18 -0700 (PDT) Received: by mail-pf0-f169.google.com with SMTP id j20so2852981pfi.1 for ; Wed, 21 Mar 2018 20:32:18 -0700 (PDT) X-Received: by 10.98.161.10 with SMTP id b10mr18888692pff.240.1521689538333; Wed, 21 Mar 2018 20:32:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.156.15 with HTTP; Wed, 21 Mar 2018 20:32:17 -0700 (PDT) In-Reply-To: <87k1u4yf01.fsf@hobgoblin.ariadne.com> References: <87k1u4yf01.fsf@hobgoblin.ariadne.com> From: Roman Shpount Date: Wed, 21 Mar 2018 23:32:17 -0400 X-Gmail-Original-Message-ID: Message-ID: To: "Dale R. Worley" Cc: Christer Holmberg , SIPCORE Content-Type: multipart/alternative; boundary="f40304381c986413540567f7f45d" Archived-At: Subject: Re: [sipcore] sip-push: Recongizing the re-REGISTER 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, 22 Mar 2018 03:32:21 -0000 --f40304381c986413540567f7f45d Content-Type: text/plain; charset="UTF-8" On Wed, Mar 21, 2018 at 11:18 PM, Dale R. Worley wrote: > My conception is that in this case, where the implementing proxy and > registration server are separate, and so the implementing proxy can be > viewed as an edge proxy, we are adding a further complication: When the > UA awakens, its new REGISTER may go through a *different* edge proxy > (and may register different contact URI). > I am fairly sure that if SIP UA goes through different edge proxies when it wakes then non of the current NAT traversal solutions will work. I think the best way to address this in SIP Push draft is to spell out that this is not supported. Fixing this in general case that you are describing is fairly hard, since it will require the edge SIP proxy, when it gets a new registration, to communicate with all the other edge proxies and check if they have any queued SIP messages waiting for the connection from this client. Regards, _____________ Roman Shpount --f40304381c986413540567f7f45d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Wed, Mar 21, 2018 at 11:18 PM, Dale R. Worley = <worley@ariadne.= com> wrote:
My conception i= s that in this case, where the implementing proxy and
registration server are separate, and so the implementing proxy can be
viewed as an edge proxy, we are adding a further complication:=C2=A0 When t= he
UA awakens, its new REGISTER may go through a *different* edge proxy
(and may register different contact URI).

I am fairly sure that if SIP UA goes through different edge proxies when= it wakes then non of the current NAT traversal solutions will work. I thin= k the best way to address this in SIP Push draft is to spell out that this = is not supported.

Fixing this in general case that= you are describing is fairly hard, since it will require the edge SIP prox= y, when it gets a new registration, to communicate with all the other edge = proxies and check if they have any queued SIP messages waiting for the conn= ection from this client.=C2=A0

Regards,
<= div class=3D"gmail_signature">_____________
Roman Shpount
=C2=A0
--f40304381c986413540567f7f45d-- From nobody Wed Mar 21 20:34:12 2018 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 E711012D87D for ; Wed, 21 Mar 2018 20:34:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.686 X-Spam-Level: X-Spam-Status: No, score=-1.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 hrdzRhwT90SR for ; Wed, 21 Mar 2018 20:34:10 -0700 (PDT) Received: from resqmta-ch2-03v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C4F512D877 for ; Wed, 21 Mar 2018 20:34:10 -0700 (PDT) Received: from resomta-ch2-12v.sys.comcast.net ([69.252.207.108]) by resqmta-ch2-03v.sys.comcast.net with ESMTP id yqzLeuBVgI2m3yqzReocs5; Thu, 22 Mar 2018 03:34:09 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-12v.sys.comcast.net with SMTP id yqzPe11jqb7rVyqzQeemMz; Thu, 22 Mar 2018 03:34: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 w2M3Y7sp012727; Wed, 21 Mar 2018 23:34:07 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id w2M3Y6GB012724; Wed, 21 Mar 2018 23:34: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: Christer Holmberg Cc: sipcore@ietf.org In-Reply-To: <7594FB04B1934943A5C02806D1A2204B72DF5CB7@ESESSMB102.ericsson.se> (christer.holmberg@ericsson.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 21 Mar 2018 23:34:06 -0400 Message-ID: <87bmfgyea9.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfBZOmrhwmcU1Uth4hxCie039lYnKbtav2T8TxhmqOals1fvMox2w32SCgcN9XKkIBxM61ofE21p0XmFnTfdHUjLML6zXqcUBvOhWGomv/3hcJWqiLsLl UdVPdqoTgrcGcBz3ZySXfAFKMo4gVvzixJ1R9ZPCyCIxw6ItXo7Ue2pBo0/DZ1dtFyDyKH+DXlHrsmWSuXy3rP3z0XZHdSJ/IQ8= Archived-At: Subject: Re: [sipcore] Allowing "far" proxies in 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: Thu, 22 Mar 2018 03:34:11 -0000 Christer Holmberg writes: [out of order] > But, if we want to cover your proxy-out-of-path scenario, we can do > that in a separate draft (similar to the Outbound case). Because, > based on the text above, I think it requires a little more thinking > than simply defining a new pn-aor parameter. As I said when this work > started, there is an industry need for a solution now, the window for > providing a standard solution is narrow, and the assumptions in the > current version of the draft meet need. I intensely dislike the scenario of "The industry needs a solution now, and this is what the industry has implemented, and so we must approve it." This is a situation where the IETF cannot maintain quality control over what it approves. In this particular case, my opinion is that the use of URI-parameters is architecturally undesirable. (Compare that in RFC 5626, reg-id and +sip.instance are header parameters.) The *only* reason to make the URI parameters is scenarios where the implementing proxy is far enough from the registrar that the only information it has in the incoming request is the contact URI. > I am not aware of any case where the proxy (no matter whether it is > "far" or "near") would not receive the REGISTER/re-REGISTER requests. OK, but I can easily construct such cases. > Also, in your "Due to the network architecture..." sentence you seem > to imply that the proxy would not receive the initial REGISTER (which > is the reason pn-aor is needed), but it could receive the re-REGISTER > requests. I have never heard about such use-case. The proxy must have received a register at some time in the past, or otherwise it would not be receiving the incoming request now. But if the proxy is any sort of "edge proxy", there's no reason to assume that it must receive the re-REGISTER. > Also, if the proxy does not receive the re-REGISTER request, there may > be NAT issues when the proxy is trying to forward the request (since > there is no re-REGISTER, Outbound keep-alive etc opening the pin > hole). Ah, but if the proxy knows that the re-REGISTER has happened, then the NAT must have been taken care of. In that case, it can forward the request to the *new* contact URI. Dale From nobody Wed Mar 21 20:36:58 2018 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 8151112D873 for ; Wed, 21 Mar 2018 20:36:57 -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 p1zQsNXeVyd0 for ; Wed, 21 Mar 2018 20:36:56 -0700 (PDT) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) (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 1E72012D7EC for ; Wed, 21 Mar 2018 20:36:56 -0700 (PDT) Received: by mail-pf0-x22b.google.com with SMTP id j2so2848025pff.10 for ; Wed, 21 Mar 2018 20:36:56 -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=U0cZa/+1DNjFQ5a76HofeLYDPwbFkcssGyeYioyOVZ4=; b=b9RoBQG/V/+CeIHJ/B97wqyycmJs0rKyzj0fzUySR/fpGSHBm7wsdG7W1ipAVJ3+25 iX3rEpYFwRDxi08+dtAdCmi7sZs/6ritaj4c+gNWf9FacKZazE3VTfgQnTlTnVGTYnFM BNb1/tYn9Do90rFhNptnZD0TP2VuP6wG1afNYr/x6zzZZsW1H5FXIdlx2II0eIJPz2PG 5gGK9lP2/4cyToY44TjG8a7MiMaFLEk8TceuC0mXdMGpHCzwgKhFOZoo3R6dWaxE+/TJ d4AMMvp8exuXqQX+T0IgWun2BnLGaBlhg82A6L+CnJ3f4uGWi86aZNRPjibL7Nw+viDI x83A== 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=U0cZa/+1DNjFQ5a76HofeLYDPwbFkcssGyeYioyOVZ4=; b=sIgCE+lo5CiyBHX/D6feyg05Z+9sj3x3PdJPKheagmnl68Japmd371ijBBhOWJvFB/ Xy69GWehcQTBeBvjGumPt62SWM0OYRGmilYRSMNEYRC9MKK1NgX5/t3jrV8yrm6v61c/ +CqSCo4KwW8mlXd0WyK0RVmVqkcy+zyT0l5GO2DTqRPqjL/+W773Aj3oMmMco24wSTTr O0Z+PQ0xZB6R4Ecig5+iEF0GWNGwC5KXuYtkzXgF5YelYLyVD6nJCBteH8Uy2AsOanoD YQfYpAndgBhz989gDpF43LppVJObHAl6fWGNAwm+APEm7CsINMvwfO0PC0/2hCIoI59r Ji0g== X-Gm-Message-State: AElRT7HHGWyCksi0TJzgc3F28PtOfbcg36de0gsNOTTiaO5lB3gl3lEr +ANbuBpIOQXWC6Hc+Qlw11lYtJ3i X-Google-Smtp-Source: AG47ELt5Bqh0tslllv+A8x6muzwGG1g4UtXMk0k1Ri8fw4YvlqYtigX5R/ZOUjfZq2RPhqtPVvlZtw== X-Received: by 10.98.3.66 with SMTP id 63mr19153009pfd.177.1521689815595; Wed, 21 Mar 2018 20:36:55 -0700 (PDT) Received: from mail-pl0-f54.google.com (mail-pl0-f54.google.com. [209.85.160.54]) by smtp.gmail.com with ESMTPSA id y18sm10023346pfe.67.2018.03.21.20.36.55 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Mar 2018 20:36:55 -0700 (PDT) Received: by mail-pl0-f54.google.com with SMTP id k22-v6so4484897pls.6 for ; Wed, 21 Mar 2018 20:36:55 -0700 (PDT) X-Received: by 2002:a17:902:d892:: with SMTP id b18-v6mr23656285plz.241.1521689814894; Wed, 21 Mar 2018 20:36:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.156.15 with HTTP; Wed, 21 Mar 2018 20:36:54 -0700 (PDT) In-Reply-To: <87fu4syemo.fsf@hobgoblin.ariadne.com> References: <87fu4syemo.fsf@hobgoblin.ariadne.com> From: Roman Shpount Date: Wed, 21 Mar 2018 23:36:54 -0400 X-Gmail-Original-Message-ID: Message-ID: To: "Dale R. Worley" Cc: SIPCORE Content-Type: multipart/alternative; boundary="000000000000e00cbf0567f80432" Archived-At: Subject: Re: [sipcore] Allowing "far" proxies in 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: Thu, 22 Mar 2018 03:36:57 -0000 --000000000000e00cbf0567f80432 Content-Type: text/plain; charset="UTF-8" On Wed, Mar 21, 2018 at 11:26 PM, Dale R. Worley wrote: > What makes the more general situation complicated is that when the UA > awakens, its re-registration may pass through a different edge proxy, > changing the Path of the registration. > I think this breaks SIP Outbound as well since I think it assumes that when flow is recovered it is recovered on the same edge proxy. I think we can mandate that the same edge proxy must be used for re-registrations as a limitation for the SIP push draft. Regards, _____________ Roman Shpount --000000000000e00cbf0567f80432 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Mar 21, 2018 at 11:26 PM, D= ale R. Worley <worley@ariadne.com> wrote:
What makes the more= general situation complicated is that when the UA
awakens, its re-registration may pass through a different edge proxy,
changing the Path of the registration.

= I think this breaks SIP Outbound as well since I think it assumes that when= flow is recovered it is recovered on the same edge proxy.=C2=A0
=
I think we can mandate that the same edge proxy must be used= for re-registrations as a limitation for the SIP push draft.
Regards,
<= div class=3D"gmail_signature">_____________
Roman Shpount
=C2=A0
--000000000000e00cbf0567f80432-- From nobody Wed Mar 21 22:22:02 2018 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 48F6E12422F for ; Wed, 21 Mar 2018 22:22:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 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_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 sgsZO569cU74 for ; Wed, 21 Mar 2018 22:21:58 -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 4E52D1201F8 for ; Wed, 21 Mar 2018 22:21:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1521696116; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=H9IBI/QzDzOrtRnbdWgOglMbCqshkPnLqKuJy2dHzCM=; b=TJszk0yZkh0lhUWovmkvQm2GCF+yOs3OQdsODcXCWrdSiMkqbBjSlpqLKUbr9UMu 4A3/yz/cxaBodxk5zhxX0KmydFtQaD68K3tLHY926Y26l6VunnAgZVT9wnb06y1U cxF1+ohBFjofzTqVcvpyo/EPQMarX3v6WM5ZbTSe3P8=; X-AuditID: c1b4fb3a-a61ff70000003647-ae-5ab33d7482da Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 9F.E0.13895.47D33BA5; Thu, 22 Mar 2018 06:21:56 +0100 (CET) Received: from ESESSMB102.ericsson.se ([169.254.2.50]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0382.000; Thu, 22 Mar 2018 06:21:55 +0100 From: Christer Holmberg To: "Dale R. Worley" CC: "sipcore@ietf.org" Thread-Topic: [sipcore] Allowing "far" proxies in sip-push Thread-Index: AQHTwY6hGhUC9DuUvUqlF78QsGKB3KPbrguA Date: Thu, 22 Mar 2018 05:21:55 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B72DF84D9@ESESSMB102.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B72DF5CB7@ESESSMB102.ericsson.se> (christer.holmberg@ericsson.com) <87bmfgyea9.fsf@hobgoblin.ariadne.com> In-Reply-To: <87bmfgyea9.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.169] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUyM2K7h26J7eYog6WPlC2+/tjEZvHyRJkD k8fk/V+ZPZYs+ckUwBTFZZOSmpNZllqkb5fAlXH0ahdbwULZisOPdzA1MG4U72Lk5JAQMJH4 vnsPcxcjF4eQwGFGibWHDrBAOIsZJWY/+QCU4eBgE7CQ6P6nDWKKCGhKdCzIAellBjIf7dzL BGILC1hKzL51nRnEFhGwknjxcwYLRLmRRMtaL5Awi4CqxJSOA2wgNq+Ar8SbZ9eh1k5nlJg0 8RMjSIJTwFhi0dudrCA2o4CYxPdTa5ggdolL3HoynwniZgGJJXvOM0PYohIvH/9jhbCVJE52 b2aBqNeRWLD7ExuErS2xbOFrZojFghInZz5hmcAoOgvJ2FlIWmYhaZmFpGUBI8sqRtHi1OLi 3HQjI73Uoszk4uL8PL281JJNjMAYObjlt9UOxoPPHQ8xCnAwKvHwlmhujhJiTSwrrsw9xCjB wawkwnsIJMSbklhZlVqUH19UmpNafIhRmoNFSZzXKc0iSkggPbEkNTs1tSC1CCbLxMEp1cCY GXuQs6S2fZtjyDu+3IUyrz48yLO9w5P8uOeq8G6HlNKnpgsf73Zh/XXgZ8B5xuAW/iiR/IXu h9lcD0ou50xfaryw4uO/9MKeO/tXHJvnzWn5w2HHxqyT7p+dnacIGFr35QQx2fvePNLLWP4r 4cI9z0fpLxd5Kkd+l834kM5h4T/tr8jMiv9KLMUZiYZazEXFiQAXVtRGjQIAAA== Archived-At: Subject: Re: [sipcore] Allowing "far" proxies in 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: Thu, 22 Mar 2018 05:22:00 -0000 Hi, >> But, if we want to cover your proxy-out-of-path scenario, we can do=20 >> that in a separate draft (similar to the Outbound case). Because,=20 >> based on the text above, I think it requires a little more thinking=20 >> than simply defining a new pn-aor parameter. As I said when this work=20 >> started, there is an industry need for a solution now, the window for=20 >> providing a standard solution is narrow, and the assumptions in the=20 >> current version of the draft meet need. > > I intensely dislike the scenario of "The industry needs a solution now, a= nd this is what the > industry has implemented, and so we must approve it."= This is a situation where the IETF > cannot maintain quality control over= what it approves. This is not what the industry has implemented yet - this is what we are try= ing to get the industry to implement, instead of all kind of different prop= rietary solutions that I have seen flying around. My point is that this is not a new fancy feature that operators "may implem= ent at some point in the future" - it is a feature that is needed now. And, as you have said yourself, your suggested extension does not change th= e basic mechanism. =20 >In this particular case, my opinion is that the use of URI-parameters is a= rchitecturally >undesirable. (Compare that in RFC 5626, reg-id and >+sip.instance are header parameters.) The *only* reason to make the URI >parameters is scenarios where the implementing proxy is far enough from th= e registrar >that the only information it has in the incoming request is th= e contact URI. A proxy can be "far" from the registrar even if it receives the REGISTER/re= -REGISTER requests.=20 Even in your suggestion the proxy needs to be aware of the registration sta= tus. The only extra seems to be that the proxy does not receive all REGISTE= R/re-REGISTER requests. >> I am not aware of any case where the proxy (no matter whether it is=20 >> "far" or "near") would not receive the REGISTER/re-REGISTER requests. > > OK, but I can easily construct such cases. That is why I am suggestion we write it down in a separate draft. I think t= here would be a need for call flows showing your scenario(s), you were talk= ing about extending the 'reg' event package etc... >> Also, in your "Due to the network architecture..." sentence you seem=20 >> to imply that the proxy would not receive the initial REGISTER (which=20 >> is the reason pn-aor is needed), but it could receive the re-REGISTER=20 >> requests. I have never heard about such use-case. > >The proxy must have received a register at some time in the past, or other= wise it would >not be receiving the incoming request now. But if the proxy= is any sort of "edge proxy", >there's no reason to assume that it must rec= eive the re-REGISTER. Even without push, I have never heard of about such scenarios. REGISTERs an= d re-REGISTERs always traverse the same path. Even with Outbound, REGISTERs= /re-REGISTERs associated with a given flow traverse the same path. >> Also, if the proxy does not receive the re-REGISTER request, there may=20 >> be NAT issues when the proxy is trying to forward the request (since=20 >> there is no re-REGISTER, Outbound keep-alive etc opening the pin=20 >> hole). > > Ah, but if the proxy knows that the re-REGISTER has happened, then the NA= T must have=20 > been taken care of. In that case, it can forward the request to the *new= * contact URI. Sure, but depending on the NAT that doesn't mean that requests from the pro= xy will be allowed through the binding - only request from the IP address o= f whoever received the re-REGISTER will. Regards, Christer From nobody Thu Mar 22 05:41:05 2018 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 D95A412D7FC for ; Thu, 22 Mar 2018 05:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.686 X-Spam-Level: X-Spam-Status: No, score=-1.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 xNoCgDVodkf8 for ; Thu, 22 Mar 2018 05:41:02 -0700 (PDT) Received: from resqmta-ch2-03v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53A71124319 for ; Thu, 22 Mar 2018 05:41:02 -0700 (PDT) Received: from resomta-ch2-02v.sys.comcast.net ([69.252.207.98]) by resqmta-ch2-03v.sys.comcast.net with ESMTP id yzWQeucBlI2m3yzWfep9CB; Thu, 22 Mar 2018 12:41:01 +0000 Received: from hobgoblin.ariadne.com ([65.96.206.41]) by resomta-ch2-02v.sys.comcast.net with SMTP id yzWdezwrmbdGJyzWeeatbV; Thu, 22 Mar 2018 12:41:01 +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 w2MCexTf005812; Thu, 22 Mar 2018 08:40:59 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id w2MBqI1v002620; Thu, 22 Mar 2018 07:52: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: Roman Shpount Cc: christer.holmberg@ericsson.com, sipcore@ietf.org In-Reply-To: (roman@telurix.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Thu, 22 Mar 2018 07:52:17 -0400 Message-ID: <87r2ocwcni.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfO+gICGbDSqP0uvyTh9ITtDpZGd2N3vsydqtde92C+ME0OynX9+vKos6UZHOqFl0LtVRDjp/yAxp0LXeBauocF6q7edrMkxPj9ysaUVwVZQ9YR43mOXs oY6qDA6Fo2Qr6nQsHuxnW7XjJ6rID//vCUN01NQmvLfT4TIY1Z2wk+I16Oh01M7Dp8nZoMtK0sTM7NH6WI1cp3cE1XcvG8SLKXqNtMPygYjQwQ7OAykyDqGJ lcBgRmBysmwNjkRcXscl+g== Archived-At: Subject: Re: [sipcore] sip-push: Recongizing the re-REGISTER 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, 22 Mar 2018 12:41:04 -0000 It seems to me that sip-push and SIP Outbound can be used together, with SIP Outbound's edge proxies being sip-push's implementing proxies. Operationally, the complication is that when the UA awakens, it may establish flows with different edge proxies. The proxy that awakened the UA needs to recognize this and forward the incoming request to the correct edge proxy. Conceptually this isn't hard, but it seems like some machinery needs to be added to the proposal to handle it. When the proxy is processing an incoming request, it needs to know which registration to monitor. To do that, it needs to know the AOR, which is carried in pn-aor. It needs to know the UA identity, which is effectively carried in pn-provider/pn-prid (and these two determine the sip.instance, so sip.instance need not be carried directly). It also needs to know the reg-id, but we seem to have no mechanism for carrying that. So it seems like we'd need to add a pn-reg-id parameter for carrying the reg-id value. Given that information, the proxy can identify the correct registration in the reg event package, which looks something like this: sip:bob@192.0.2.2;transport=tcp;pn-provider=acme;pn-param=acme-param;pn-prid=ZTY4ZDJlMzODE1NmUgKi0K;pn-aor=bob%40example.com;pn-reg-id=1 1 <urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF> sip:bob@192.0.2.2;transport=tcp;pn-provider=acme;pn-param=acme-param;pn-prid=ZTY4ZDJlMzODE1NmUgKi0K;pn-aor=bob%40example.com;pn-reg-id=2 2 <urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF> The AOR allows the proxy to retrieve the correct event information, the pn-prid et al. allows it to identify the s for the UA in question, and the s allow it to select from those s the one registration which was used to forward this incoming request. But when the proxy monitors , when the contact is updated (the cseq attribute increases), the proxy can observe whether the has changed, but it has no way to monitor whether the Path in the REGISTER request has changed. If the Path has changed, the proxy needs to either 404 the request, or re-route it by removing any remaining Route headers, and then forwarding it to the path (new Path URIs, new contact URI). Or alternatively, it can forward it to the AOR, and have the domain's redirector send the request through the correct path to the correct edge proxy. I can think of two ways for the proxy to deal with a changing Path. 1. Extend the reg event package to have a way to carry the Path information. If the registrar implements Path (RFC 3327), it is recording this information already, so it shouldn't be difficult to add this to the event package. 2. If the Path has *not* changed, the edge proxy is likely to process the REGISTER and its response. So if the proxy monitors the event package and watches for REGISTERs, it can determine whether the Path stayed the same (REGISTER was also seen) versus the Path changes (REGISER was not seen). If the Path changed, it can forward the request to the AOR for re-forwarding. Dale From nobody Thu Mar 22 05:41:13 2018 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 627CD124319 for ; Thu, 22 Mar 2018 05:41:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.686 X-Spam-Level: X-Spam-Status: No, score=-1.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 79Agrx_OIqF4 for ; Thu, 22 Mar 2018 05:41:03 -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 0743212D7F8 for ; Thu, 22 Mar 2018 05:41:02 -0700 (PDT) Received: from resomta-ch2-12v.sys.comcast.net ([69.252.207.108]) by resqmta-ch2-08v.sys.comcast.net with ESMTP id yzWVe3mO72JtHyzWgexZrE; Thu, 22 Mar 2018 12:41:02 +0000 Received: from hobgoblin.ariadne.com ([65.96.206.41]) by resomta-ch2-12v.sys.comcast.net with SMTP id yzWee2a82b7rVyzWfefACG; Thu, 22 Mar 2018 12:41:02 +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 w2MCexTl005812; Thu, 22 Mar 2018 08:41:00 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id w2MBInn2001068; Thu, 22 Mar 2018 07:18:49 -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: <7594FB04B1934943A5C02806D1A2204B72DF5CB7@ESESSMB102.ericsson.se> (christer.holmberg@ericsson.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Thu, 22 Mar 2018 07:18:49 -0400 Message-ID: <87woy4we7a.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfDbLHnzsYJWrgVQw8Zfjnv9GfsfH9zt+ME54jLXuSKuybRDFdyHYgaP4CIE/S3b6dVSVzPmQtgyMeDt4CbTAvZ3IAV3ZUYlAReJuTEnbe39ROuQmuFpl 4mGcWs5uy5gfEaqB1QSZ9/GUZh3f1Qqxrf3XABTB/wu5j/pHl95LkXIjTNUGsxNzUPmZO2C4qzUoeYk/3ExaL+XVC7lA0eXi5ZQjmoFkmc0YVdBS9TTpLY/c Archived-At: Subject: Re: [sipcore] Allowing "far" proxies in 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: Thu, 22 Mar 2018 12:41:04 -0000 Christer Holmberg writes: > Also, any proxy (no matter whether it is "far" or "near") can use the > 'reg' event package in order to figure out the status of a > registration. That's true in theory, but in the present scheme, the proxy doesn't know the AOR to subscribe to in order to obtain the 'reg' events -- it only has the contact URI, and there's no algorithm for deriving the AOR from the contact URI. Carrying the AOR to the implementing proxy is what the pn-aor parameter is designed to do. Dale From nobody Thu Mar 22 05:44:27 2018 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 7E5AC126CE8 for ; Thu, 22 Mar 2018 05:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 FrnLYb9UmLBb for ; Thu, 22 Mar 2018 05:44:24 -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 09A21124319 for ; Thu, 22 Mar 2018 05:44:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1521722662; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=cCNoJJI8JQEEaabamEOtztmG5oYQ+vGUFs7g+ynh/tA=; b=KUMtUSKfEqrCESig02huC2AgPXdtVNQNszfdDWoM+Rx9jwf2T5a/Cxm0t+/M6Nrm OVQeL3gp0TfGKjLb2ERoVcnOid6DCbooxGTE/iHz2EI/UC4o7i70Bx9zwaSx7FZA 6vM4s9PXoBa1bRXpOeGRGnMK5D2187TNdfrIPqL6CXY=; X-AuditID: c1b4fb30-81c549c00000197d-44-5ab3a52611a4 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id A5.96.06525.625A3BA5; Thu, 22 Mar 2018 13:44:22 +0100 (CET) Received: from ESESSMB102.ericsson.se ([169.254.2.50]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0382.000; Thu, 22 Mar 2018 13:44:21 +0100 From: Christer Holmberg To: "Dale R. Worley" CC: "sipcore@ietf.org" Thread-Topic: [sipcore] Allowing "far" proxies in sip-push Thread-Index: AQHTwc+MGhUC9DuUvUqlF78QsGKB3KPcMzaQ Date: Thu, 22 Mar 2018 12:44:20 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B72DFC21D@ESESSMB102.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B72DF5CB7@ESESSMB102.ericsson.se> (christer.holmberg@ericsson.com) <87woy4we7a.fsf@hobgoblin.ariadne.com> In-Reply-To: <87woy4we7a.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.170] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyM2K7uq7a0s1RBgd+CVh8/bGJzeLliTIH Jo/J+78yeyxZ8pMpgCmKyyYlNSezLLVI3y6BK+PcrCUsBddZKr4c7WZqYLzM3MXIySEhYCKx 59IR9i5GLg4hgcOMEot/H4RyFjNKnPy6mbWLkYODTcBCovufNogpIqAp0bEgB6SXGch8tHMv E4gtLGApMfvWdbCZIgJWEi9+zmCBsI0k5u3ZwAZiswioShw5dJARxOYV8JV4sfgW1KrpjBIt t/vYQRKcAsYSq+4fBWtmFBCT+H5qDRPEMnGJW0/mM0EcLSCxZM95qAdEJV4+/scKYStJnNn0 nAWiXkdiwe5PbBC2tsSyha+ZIRYLSpyc+YRlAqPoLCRjZyFpmYWkZRaSlgWMLKsYRYtTi5Ny 042M9FKLMpOLi/Pz9PJSSzYxAqPk4JbfBjsYXz53PMQowMGoxMPr3705Sog1say4MvcQowQH s5II7yFNoBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXFeCz+glEB6YklqdmpqQWoRTJaJg1OqgXHW 9ESZSY3hxWJ5OhvaLgaKKB3yPh33NPGnnpeItk72nO58fpMZizb2erU1rDp6MKb68KktCuFz RUxLX/x5u/YjV8acdcVXCmsnti34/2I797eHu8T0mt3Y8sImH5c85bz9lZfi2tt7dl2NY0/s fNZyMktvU83l0Gl3b0Q+T5TtfbJvh021oJsSS3FGoqEWc1FxIgAWv89QjgIAAA== Archived-At: Subject: Re: [sipcore] Allowing "far" proxies in 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: Thu, 22 Mar 2018 12:44:25 -0000 Hi, >> Also, any proxy (no matter whether it is "far" or "near") can use the=20 >> 'reg' event package in order to figure out the status of a=20 >> registration. > >That's true in theory, but in the present scheme, the proxy doesn't know t= he AOR to >subscribe to in order to obtain the 'reg' events -- it only has = the contact URI, and there's >no algorithm for deriving the AOR from the co= ntact URI. Carrying the AOR to the >implementing proxy is what the pn-aor = parameter is designed to do. Doesn't the proxy get the AOR from the REGISTER request? Regards, Christer From nobody Thu Mar 22 07:33:14 2018 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 E70811200C5 for ; Thu, 22 Mar 2018 07:33:13 -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, 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 Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 B552kOrGaLD5 for ; Thu, 22 Mar 2018 07:33:10 -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 B2721126DFB for ; Thu, 22 Mar 2018 07:33:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1521729182; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Te8p281DMFJh3Y/nZQxuP01QMousdZsmYo6FmOsJwO8=; b=awblD2kd1q1xKYjXHY/NRdQXCmygGSP83+TFogQgG5HXl/8S3iUJSInIzstKBInc jrVQidLW+IiRCuYKYeSX/PrvrNfl3+OFxzXpPyO0j1DQQTmGDZQ63AW0v1ap9Nhc w0zabR0VrfpJzQ/fHZFfpV4B3JSGlsYBIABRiYMW3Qc=; X-AuditID: c1b4fb30-81c549c00000197d-53-5ab3be9e7802 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 1A.CF.06525.E9EB3BA5; Thu, 22 Mar 2018 15:33:02 +0100 (CET) Received: from ESESSMB102.ericsson.se ([169.254.2.50]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0382.000; Thu, 22 Mar 2018 15:33:00 +0100 From: Christer Holmberg To: "Dale R. Worley" CC: Roman Shpount , "sipcore@ietf.org" Thread-Topic: [sipcore] sip-push: Recongizing the re-REGISTER Thread-Index: AQHTwdQ5o3oD+jI3TEmHjc9qC5tyLaPcUbEm Date: Thu, 22 Mar 2018 14:32:59 +0000 Message-ID: <3D364F5D-A6E1-40B5-AEA9-560D7B9CB0AD@ericsson.com> References: (roman@telurix.com),<87r2ocwcni.fsf@hobgoblin.ariadne.com> In-Reply-To: <87r2ocwcni.fsf@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_3D364F5DA6E140B5AEA9560D7B9CB0ADericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAIsWRmVeSWpSXmKPExsUyM2K7ou68fZujDL4eMbGYcWEqs8XXH5vY LF6eKHNg9pi8/yuzx5IlP5k8bk0pCGCO4rJJSc3JLEst0rdL4Mr4NmkTW8Hj9Io5fTPZGhjv RnYxcnJICJhIrL/7lKmLkYtDSOAwo8TF41tYIZzFjBJ7O1cAORwcbAIWEt3/tEFMEQFNiY4F OSC9zAI+End2vGUFsYUFbCSuvb7EBmKLCNhKTF42hQnCNpLoXnkELM4ioCrx/vs8ZhCbV8Be 4vrTVqhVvYwSR3tWgxVxChhLNHz5BWYzCohJfD+1hglimbjErSfzmSCOFpBYsuc8M4QtKvHy 8T9WiJpkiUdTPrFCLBCUODnzCcsERuFZSNpnISmbhaQMIq4jsWD3JzYIW1ti2cLXzDD2mQOP mZDFFzCyr2IULU4tTspNNzLSSy3KTC4uzs/Ty0st2cQIjKeDW34b7GB8+dzxEKMAB6MSD6/K 0s1RQqyJZcWVuYcYJTiYlUR489cChXhTEiurUovy44tKc1KLDzFKc7AoifNa+AGlBNITS1Kz U1MLUotgskwcnFINjJts9a9+2FPG+4vFbq9IlPvSye7/Z+3qvf7UgNPxodCOU8yztgozLJB5 O8dny8/Y6xudD3SfyLq3wUYkwHP6VNc0Gdfd1xdvmaWlL7x/u6qnr9PX50prkrnEt01+eZil Q5Tt65K73LOv3Za5vuLTJmGGHQt/rmpOM3j5519b7zruqg4BT0ujebOUWIozEg21mIuKEwEs HqipowIAAA== Archived-At: Subject: Re: [sipcore] sip-push: Recongizing the re-REGISTER 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, 22 Mar 2018 14:33:14 -0000 --_000_3D364F5DA6E140B5AEA9560D7B9CB0ADericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Dale, I may not agree with everything below, but the things you talk about below = will be covered in draft-push-with-outbound. Regards, Christer Sent from my iPhone On 22 Mar 2018, at 12.41, Dale R. Worley > wrote: It seems to me that sip-push and SIP Outbound can be used together, with SIP Outbound's edge proxies being sip-push's implementing proxies. Operationally, the complication is that when the UA awakens, it may establish flows with different edge proxies. The proxy that awakened the UA needs to recognize this and forward the incoming request to the correct edge proxy. Conceptually this isn't hard, but it seems like some machinery needs to be added to the proposal to handle it. When the proxy is processing an incoming request, it needs to know which registration to monitor. To do that, it needs to know the AOR, which is carried in pn-aor. It needs to know the UA identity, which is effectively carried in pn-provider/pn-prid (and these two determine the sip.instance, so sip.instance need not be carried directly). It also needs to know the reg-id, but we seem to have no mechanism for carrying that. So it seems like we'd need to add a pn-reg-id parameter for carrying the reg-id value. Given that information, the proxy can identify the correct registration in the reg event package, which looks something like this: sip:bob@192.0.2.2;transport=3Dtcp;pn-provider=3Dacm= e;pn-param=3Dacme-param;pn-prid=3DZTY4ZDJlMzODE1NmUgKi0K;pn-aor=3Dbob%40exa= mple.com;pn-reg-id=3D1 1 <urn:uuid:00000000-= 0000-1000-8000-AABBCCDDEEFF> sip:bob@192.0.2.2;transport=3Dtcp;pn-provider=3Dacm= e;pn-param=3Dacme-param;pn-prid=3DZTY4ZDJlMzODE1NmUgKi0K;pn-aor=3Dbob%40exa= mple.com;pn-reg-id=3D2 2 <urn:uuid:00000000-= 0000-1000-8000-AABBCCDDEEFF> The AOR allows the proxy to retrieve the correct event information, the pn-prid et al. allows it to identify the s for the UA in question, and the s allow it to select from those s the one registration which was used to forward this incoming request. But when the proxy monitors , when the contact is updated (the cseq attribute increases), the proxy can observe whether the has changed, but it has no way to monitor whether the Path in the REGISTER request has changed. If the Path has changed, the proxy needs to either 404 the request, or re-route it by removing any remaining Route headers, and then forwarding it to the path (new Path URIs, new contact URI). Or alternatively, it can forward it to the AOR, and have the domain's redirector send the request through the correct path to the correct edge proxy. I can think of two ways for the proxy to deal with a changing Path. 1. Extend the reg event package to have a way to carry the Path information. If the registrar implements Path (RFC 3327), it is recording this information already, so it shouldn't be difficult to add this to the event package. 2. If the Path has *not* changed, the edge proxy is likely to process the REGISTER and its response. So if the proxy monitors the event package and watches for REGISTERs, it can determine whether the Path stayed the same (REGISTER was also seen) versus the Path changes (REGISER was not seen). If the Path changed, it can forward the request to the AOR for re-forwarding. Dale --_000_3D364F5DA6E140B5AEA9560D7B9CB0ADericssoncom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Dale,

I may not agree with everything below, but the things you talk about b= elow will be covered in draft-push-with-outbound.

Regards,

Christer


Sent from my iPhone

On 22 Mar 2018, at 12.41, Dale R. Worley <worley@ariadne.com> wrote:

It seems to me that sip-push and SIP Outbound can be used togeth= er, with
SIP Outbound's edge proxies being sip-push's implementing proxies.
Operationally, the complication is that when the UA awakens, it may
establish flows with different edge proxies.  The proxy that awa= kened
the UA needs to recognize this and forward the incoming request to th= e
correct edge proxy.

Conceptually this isn't hard, but it seems like some machinery needs = to
be added to the proposal to handle it.  When the proxy is proces= sing an
incoming request, it needs to know which registration to monitor. &nb= sp;To do
that, it needs to know the AOR, which is carried in pn-aor.  It = needs to
know the UA identity, which is effectively carried in
pn-provider/pn-prid (and these two determine the sip.instance, so
sip.instance need not be carried directly).  It also needs to kn= ow the
reg-id, but we seem to have no mechanism for carrying that.  So = it seems
like we'd need to add a pn-reg-id parameter for carrying the reg-id
value.

Given that information, the proxy can identify the correct registrati= on
in the reg event package, which looks something like this:

  <?xml version=3D"1.0"?>
      <reginfo xmlns=3D"urn:iet= f:params:xml:ns:reginfo"
          xmlns:xsi= =3D"http://www.w= 3.org/2001/XMLSchema-instance"
           &nb= sp;       version=3D"0" state= =3D"full">
        <registration aor= =3D"sip:bob@example.com" id= =3D"as9"
           &nb= sp;          state=3D&quo= t;active">
          <conta= ct id=3D"76" state=3D"active" event=3D"registered&= quot;
           &nb= sp;       duration-registered=3D"73= 22" cseq=3D"123">
           &nb= sp;       <uri>sip:bob@192.0.2.2;transport=3Dtcp;pn-provider=3Dacme;pn-param=3Dacme-p= aram;pn-prid=3DZTY4ZDJlMzODE1NmUgKi0K;pn-aor=3Dbob%40example.com;pn-reg-id= =3D1</uri>
             &= nbsp; <unknown-param name=3D"reg-id">1</unknown-par= am>
             &= nbsp; <unknown-param name=3D"+sip.instance">&l= t;urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF&gt;</unknown-param&g= t;
          </cont= act>
          <conta= ct id=3D"77" state=3D"active" event=3D"registered&= quot;
           &nb= sp;       duration-registered=3D"70= 13" cseq=3D"456">
           &nb= sp;       <uri>sip:bob@192.0.2.2;transport=3Dtcp;pn-provider=3Dacme;pn-param=3Dacme-p= aram;pn-prid=3DZTY4ZDJlMzODE1NmUgKi0K;pn-aor=3Dbob%40example.com;pn-reg-id= =3D2</uri>
             &= nbsp; <unknown-param name=3D"reg-id">2</unknown-par= am>
             &= nbsp; <unknown-param name=3D"+sip.instance">&l= t;urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF&gt;</unknown-param&g= t;
          </cont= act>
        </registration>=
      </reginfo>

The AOR allows the proxy to retrieve the correct event information, t= he
pn-prid et al. allows it to identify the <contact>s for the UA = in
question, and the <unknown-param name=3D"reg-id">s al= low it to select from
those <contact>s the one registration which was used to forward= this
incoming request.

But when the proxy monitors <contact id=3D"76">, when= the contact is
updated (the cseq attribute increases), the proxy can observe whether=
the <uri> has changed, but it has no way to monitor whether the= Path in
the REGISTER request has changed.

If the Path has changed, the proxy needs to either 404 the request, o= r
re-route it by removing any remaining Route headers, and then forward= ing
it to the path (new Path URIs, new contact URI).  Or alternative= ly, it
can forward it to the AOR, and have the domain's redirector send the<= /span>
request through the correct path to the correct edge proxy.
I can think of two ways for the proxy to deal with a changing Path.

1. Extend the reg event package to have a way to carry the Path
information.  If the registrar implements Path (RFC 3327), it is=
recording this information already, so it shouldn't be difficult to a= dd
this to the event package.

2. If the Path has *not* changed, the edge proxy is likely to process=
the REGISTER and its response.  So if the proxy monitors the eve= nt
package and watches for REGISTERs, it can determine whether the Path<= /span>
stayed the same (REGISTER was also seen) versus the Path changes
(REGISER was not seen).  If the Path changed, it can forward the= request
to the AOR for re-forwarding.

Dale
--_000_3D364F5DA6E140B5AEA9560D7B9CB0ADericssoncom_-- From nobody Thu Mar 22 08:15:27 2018 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 A6F3D12D883 for ; Thu, 22 Mar 2018 08:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 ouXrHRqCjy1w for ; Thu, 22 Mar 2018 08:15:24 -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 390F1126D05 for ; Thu, 22 Mar 2018 08:15:24 -0700 (PDT) X-AuditID: 1207440e-affff70000005298-22-5ab3c8893023 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 71.07.21144.A88C3BA5; Thu, 22 Mar 2018 11:15:22 -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 w2MFFKAq026235 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Thu, 22 Mar 2018 11:15:21 -0400 To: SIPCORE From: Paul Kyzivat Message-ID: <949dba9e-33b7-66b9-1b16-d25902f65367@alum.mit.edu> Date: Thu, 22 Mar 2018 11:15:20 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrNIsWRmVeSWpSXmKPExsUixO6iqNt1YnOUwd9DxhZff2xic2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxo/fzSwFe0QqNszdxtjA+Jq/i5GTQ0LARKLh4iq2LkYuDiGB HUwSh9aeZIVwfjBJXH6/gbmLkYNDREBOYvaNGJAGNgEtiTmH/rOA2MICUhJPPk5lBynhFbCX OLdBACTMIqAq8Wn+XLASUYE0iUvNW5lBbF4BQYmTM5+AxZkFzCTmbX7IDGGLS9x6Mp8JwpaX 2P52DvMERt5ZSFpmIWmZhaRlFpKWBYwsqxjlEnNKc3VzEzNzilOTdYuTE/PyUot0jfVyM0v0 UlNKNzFCQoxvB2P7eplDjAIcjEo8vBk5m6KEWBPLiitzDzFKcjApifJ+egEU4kvKT6nMSCzO iC8qzUktPsQowcGsJMKbv3ZzlBBvSmJlVWpRPkxKmoNFSZxXbYm6n5BAemJJanZqakFqEUxW hoNDSYL3wHGgRsGi1PTUirTMnBKENBMHJ8hwHqDh/4+BDC8uSMwtzkyHyJ9iNOZoufikjZnj xovXbcxCLHn5ealS4ryVIOMEQEozSvPgpsHSxCtGcaDnhHlvgVTxAFMM3LxXQKuYgFZlz9wA sqokESEl1cDYfd5V3PWu2v2dny5Wnj6e/uxX3sycFMHFyrpq7r92Pje8+qn609WvTXc3nz/e 7FDY8WHLy7afSvfDfqbwxczNrw6Y8e+5TfRV88s50gaTZatlI96lhzyWj/3303Lqp04d++NX I+o3LOWqadp8kmer5rq5oQ/OqkSIBFg1pE9pfeBktczzl26SEktxRqKhFnNRcSIAwU1Lr+4C AAA= Archived-At: Subject: [sipcore] session-timer fix 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, 22 Mar 2018 15:15:26 -0000 Here is the primary use case flow that has been reported as the motivating case for the draft. (I've reformatted it for ease in typing.) 1) UA->Proxy: INVITE/SE:uac 2) Proxy->AS: INVITE/SE:uac 3) AS->Proxy: 18x/no-SE 4) Proxy->UA: 18x/no-SE 5) AS->Proxy: UPDATE/SE:uas 6) Proxy->UA: UPDATE/SE:uas 7) UA->Proxy: 200(UPDATE)/no-SE 8) Proxy->AS: 200(UPDATE)/SE:uac 9) AS->Proxy: 480(INVITE) 10) Proxy->UA: 480(INVITE) Some observations on the above: - in (5) the AS includes SE in the UPDATE, while in (7) the UA doesn't include SE in the response to the UPDATE. This seems to reflect a difference of opinion by the implementors of the UA and AS about what 4028 expects in this situation. This ambiguity needs to be resolved, and will require changes in some implementations. - The 480 in (9) is caused by the AS objecting to the "uac" in (8) because it is in conflict with the "uas" in (5). This in turn is caused by the proxy including the "uac" in (8) because it is following the rules and thinks that the UA doesn't support S-T. This of course isn't the situation. - There has been some discussion about whether the "uas" value in (5) is consistent with the "uac" value in (1). I think it is, since the uac/uas roles are relative to the direction of the individual request, and (5) is going in the opposite direction of (1). But this doesn't seem to affect the rest of the analysis. If the refresher in the UPDATE was inconsistent with that in the INVITE then I would expect the UA to send an error response to the UPDATE. ISTM that at least part of the fix for this must be to fix the ambiguity about whether SE is to be included in an UPDATE and its response that are embedded in an INVITE transaction. The existing draft does address this one way. Another way to address it would be to require SE to be included in both the UPDATE and its response, in a way consistent with what was in the INVITE and will eventually be in the response to the INVITE. A much different way would be to require that the timer negotiation in an INVITE be completed in the first reliable response to the INVITE, either 2xx or reliable 1xx. Then any UPDATE that followed within the transaction would presumably start a new timer negotiation. I'll also observe that this entire discussion has focused on the negotiation of the refresher. But there is a comparable issue around negotiating the duration of the timer. That ought to be sorted out as part of the same fix. Thanks, Paul From nobody Fri Mar 23 13:48:40 2018 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 74D7312DA2C for ; Fri, 23 Mar 2018 13:48:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 f_yeTMu014TY for ; Fri, 23 Mar 2018 13:48:36 -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 59E3D120726 for ; Fri, 23 Mar 2018 13:48:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1521838114; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ATMf82Lm5P20iwKi5Karui78uXKMyTdIDOjCxse0iaU=; b=W85tk/0c4KFuQsp7abgQR/faasUBMqEnEJnBzRMvH7su4Dktr/MNBxWoC9b0JIbS n+lShiBWgR5eMmSnZsqI+hK7HGtOylhWf6GS4VrCdoHwNQKbPhdEqEf01mG6juTx 3zaGf6dBwTetxPdQfzXLw80nCU+Jpa1BuxGZJqzQIDw=; X-AuditID: c1b4fb3a-a61ff70000003647-89-5ab568226982 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 56.0C.13895.22865BA5; Fri, 23 Mar 2018 21:48:34 +0100 (CET) Received: from ESESSMB102.ericsson.se ([169.254.2.50]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0382.000; Fri, 23 Mar 2018 21:48:33 +0100 From: Christer Holmberg To: Paul Kyzivat , SIPCORE Thread-Topic: [sipcore] session-timer fix Thread-Index: AQHTwfCeyHYsx4XVTkSHOLQKDcONKqPdSEtw Date: Fri, 23 Mar 2018 20:48:32 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B72E06C39@ESESSMB102.ericsson.se> References: <949dba9e-33b7-66b9-1b16-d25902f65367@alum.mit.edu> In-Reply-To: <949dba9e-33b7-66b9-1b16-d25902f65367@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.168] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyM2K7tK5SxtYogz9LRS1WbDjAavH1xyY2 ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSvjbF8XW8F6yYrWrpVsDYyHhbsYOTgkBEwk Nl/N7WLk4hASOMwocerNR6YuRk4gZzGjxOsHciA1bAIWEt3/tEHCIgIuEku6jzCD2MICGhJb Xz9ihYhrSvyZvYEZwjaSWDN5JjuIzSKgKrFoyh8WEJtXwFfi9bbHTCAjhQTsJT6uSgIJcwo4 SPyZdQ9sDKOAmMT3U2vALmAWEJe49WQ+mC0hICCxZM95ZghbVOLl43+sELaSRM/9e1D1OhIL dn9ig7C1JZYtfM0MsVZQ4uTMJywTGEVmIRk7C0nLLCQts5C0LGBkWcUoWpxaXJybbmSkl1qU mVxcnJ+nl5dasokRGAkHt/y22sF48LnjIUYBDkYlHt6naVujhFgTy4orcw8xSnAwK4nwntID CvGmJFZWpRblxxeV5qQWH2KU5mBREud1SrOIEhJITyxJzU5NLUgtgskycXBKNTCyn/8mojVV cBLrHj3hHdefsJ0zD+2x38zkJBh1oIF7LXdK4L5L8w9oF/3YzWFzL8B3wboax0tLvj1M4f7t ICNh5rDHvfav5P2DeofMn38y4vjCcvbO310hWQtuh17NqNPep2vNdyR8+2/l56c074fnPZUN qWxerKQ01aoi59kTezv3ZM3Ug3+VWIozEg21mIuKEwHI872egAIAAA== Archived-At: Subject: Re: [sipcore] session-timer fix 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, 23 Mar 2018 20:48:38 -0000 Hi Paul, You say (and it was indicated in the meeting): "I think it is, since the uac/uas roles are relative to the direction of the individual request," Assuming that the AS and UA are implemented that way, the problem still occ= urs when the AS receives (8), where the refresher=20 >Here is the primary use case flow that has been reported as the motivating= case for the draft. (I've reformatted it for ease in typing.) > > 1) UA->Proxy: INVITE/SE:uac > 2) Proxy->AS: INVITE/SE:uac > 3) AS->Proxy: 18x/no-SE > 4) Proxy->UA: 18x/no-SE > 5) AS->Proxy: UPDATE/SE:uas > 6) Proxy->UA: UPDATE/SE:uas > 7) UA->Proxy: 200(UPDATE)/no-SE > 8) Proxy->AS: 200(UPDATE)/SE:uac > 9) AS->Proxy: 480(INVITE) > 10) Proxy->UA: 480(INVITE) > >Some observations on the above: > >- in (5) the AS includes SE in the UPDATE, while in (7) the UA > doesn't include SE in the response to the UPDATE. This seems > to reflect a difference of opinion by the implementors of > the UA and AS about what 4028 expects in this situation. > This ambiguity needs to be resolved, and will require changes > in some implementations. Correct. This is a case where UPDATE is received while the S-T negotiation = is still ongoing. > - The 480 in (9) is caused by the AS objecting to the "uac" > in (8) because it is in conflict with the "uas" in (5). > This in turn is caused by the proxy including the "uac" > in (8) because it is following the rules and thinks that > the UA doesn't support S-T. This of course isn't the > situation. Shouldn't the proxy know that the UA supports S-T, due to (1)? > - There has been some discussion about whether the "uas" > value in (5) is consistent with the "uac" value in (1). > I think it is, since the uac/uas roles are relative to > the direction of the individual request, and (5) is > going in the opposite direction of (1). Let's assume it is like that. > But this > doesn't seem to affect the rest of the analysis. > If the refresher in the UPDATE was inconsistent with > that in the INVITE then I would expect the UA to send > an error response to the UPDATE. > > ISTM that at least part of the fix for this must be to fix the ambiguity = about whether SE is to be included in an=20 > UPDATE and its response that are embedded in an INVITE transaction. The e= xisting draft does address this one way. Yes. > Another way to address it would be to require SE to be included in both t= he UPDATE and its response, in a way=20 > consistent with what was in the INVITE and will eventually be in the resp= onse to the INVITE. Yes. > A much different way would be to require that the timer negotiation in an= INVITE be completed in the first reliable > response to the INVITE, either 2xx or reliable 1xx. Then any UPDATE that = followed within the transaction would=20 > presumably start a new timer negotiation. Yes. > I'll also observe that this entire discussion has focused on the negotiat= ion of the refresher. But there is a comparable > issue around negotiating the duration of the timer. That ought to be sort= ed out as part of the same fix. Yes. Regards, Christer From nobody Sun Mar 25 06:50:22 2018 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 A646C126C19 for ; Sun, 25 Mar 2018 06:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.685 X-Spam-Level: X-Spam-Status: No, score=-1.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 nfhmQBvk88mG for ; Sun, 25 Mar 2018 06:50:20 -0700 (PDT) Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5295A1205D3 for ; Sun, 25 Mar 2018 06:50:20 -0700 (PDT) Received: from resomta-ch2-09v.sys.comcast.net ([69.252.207.105]) by resqmta-ch2-05v.sys.comcast.net with ESMTP id 062Nfq7LMs8BA062NfwIyU; Sun, 25 Mar 2018 13:50:19 +0000 Received: from hobgoblin.ariadne.com ([65.96.206.41]) by resomta-ch2-09v.sys.comcast.net with SMTP id 062LfiKvyzJJU062Mf53gL; Sun, 25 Mar 2018 13:50:19 +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 w2PDoHnD007298; Sun, 25 Mar 2018 09:50:17 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id w2PDoGbg007295; Sun, 25 Mar 2018 09:50:16 -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, roman@telurix.com In-Reply-To: <3D364F5D-A6E1-40B5-AEA9-560D7B9CB0AD@ericsson.com> (christer.holmberg@ericsson.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Sun, 25 Mar 2018 09:50:16 -0400 Message-ID: <87woy0tgbr.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfCGqKUZq8bPVq4MDcUdMQea7eOtnSmt+o6pRsUXmLqRMu8Y9d05VD4YqzVtpXMuJ1NN+vfAKr06reENbUt5iE8Nb/qcKSV/KVliLtaWLtz0M+VM+W1fJ y8/+gMKyiS3G3V71bwK51Zfsjb4naaGHjf9T4xrXD7uaBvgqZnn2A9T8TLU+iZgH2Hk8TXjen5bvYv5q8JU1ZrwDXCOdRJHzZVUDPPBELaexT8UUGc71wCyl Tm0rNdX102Hm8CJZ9AoWlw== Archived-At: Subject: Re: [sipcore] sip-push: Recongizing the re-REGISTER 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: Sun, 25 Mar 2018 13:50:22 -0000 Christer Holmberg writes: > I may not agree with everything below, but the things you talk about > below will be covered in draft-push-with-outbound. It's not clear to me what assures that it those topics will be covered in "draft-push-with-outbound". Are you saying that you will be writing that draft? Dale From nobody Sun Mar 25 08:51:51 2018 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 4EBBC126DD9 for ; Sun, 25 Mar 2018 08:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 8RY6n8UhkD5e for ; Sun, 25 Mar 2018 08:51:48 -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 7664B1200F1 for ; Sun, 25 Mar 2018 08:51:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1521993106; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=7dFakWrqbWYbuJ0frzi9kJ+FqZ+U+DSuDijhC115hUA=; b=HDs0Bj/L5ayKFOKC74fCl7dxDtxbwfNBqji7Z2+AZ2a8VEcQkzuBLdBi+m3ZICkz 5hKOt6HDNYrU5e9kudnVeNNNgqcfN1Omu7yjvK5YSrdylhfdOm/ipFstqwrwBIVr 359zzREnuFn69SXO4yZZaicJ2U7u3KVKFIrUZJP2+dQ=; X-AuditID: c1b4fb2d-4b1ff70000005540-23-5ab7c592149c Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 80.37.21824.295C7BA5; Sun, 25 Mar 2018 17:51:46 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.115]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0382.000; Sun, 25 Mar 2018 17:51:45 +0200 From: Christer Holmberg To: "Dale R. Worley" CC: "sipcore@ietf.org" , "roman@telurix.com" Thread-Topic: [sipcore] sip-push: Recongizing the re-REGISTER Thread-Index: AQHTxEA0o3oD+jI3TEmHjc9qC5tyLaPhGTeQ Date: Sun, 25 Mar 2018 15:51:45 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B72E1AF44@ESESSMB109.ericsson.se> References: <3D364F5D-A6E1-40B5-AEA9-560D7B9CB0AD@ericsson.com> (christer.holmberg@ericsson.com) <87woy0tgbr.fsf@hobgoblin.ariadne.com> In-Reply-To: <87woy0tgbr.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.164] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmkeLIzCtJLcpLzFFi42KZGbFdS3fS0e1RBo3X+C1mXJjKbPH1xyY2 i5cnyhyYPSbv/8rssWTJTyaPW1MKApijuGxSUnMyy1KL9O0SuDL+rL/EWDCNueLImZnsDYx7 mboYOTkkBEwkmrZsYeti5OIQEjjCKLFv5jIWCGcJo0Tb5/lAVRwcbAIWEt3/tEFMEQFNiY4F OSC9zAIhEhvuPQebIyxgI9F68TwriC0iYCsxedkUJohyI4l9n2VBwiwCqhL/P0xiA7F5BXwl Jvc+hNrUySgx/8ETsDmcAsYSi54dACtiFBCT+H5qDRPELnGJW0/mQ90sILFkz3lmCFtU4uXj f6wQtpLE2S9T2CDqdSQW7P4EZWtLLFv4mhlisaDEyZlPWCYwis5CMnYWkpZZSFpmIWlZwMiy ilG0OLW4ODfdyFgvtSgzubg4P08vL7VkEyMwag5u+a27g3H1a8dDjAIcjEo8vLpbt0cJsSaW FVfmHmKU4GBWEuGVcQcK8aYkVlalFuXHF5XmpBYfYpTmYFES5z3pyRslJJCeWJKanZpakFoE k2Xi4JRqYGR3SFjzzebiGw9z5eIln7x5OB6sCX9q+kXqa/W5/bs6fizktNE7L+HA096XfDdu ZsqqmqSCeYGa2g7/3y4/8vTH+uZLiy7ft7igrdne61T+kefbrTfBty5PsFnsWWjt1lB9XdPG mHPhEtkZL12u8v9tNjtzqf/vgaJyjw8F4dxuJ0oEfOp3TFRiKc5INNRiLipOBAB/8k0algIA AA== Archived-At: Subject: Re: [sipcore] sip-push: Recongizing the re-REGISTER 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: Sun, 25 Mar 2018 15:51:50 -0000 Hi, >> I may not agree with everything below, but the things you talk about=20 >> below will be covered in draft-push-with-outbound. > > It's not clear to me what assures that it those topics will be covered in= "draft-push-with- > outbound". Are you saying that you will be writing that draft? I definitely would, because I do think it can become a useful feature. Regards, Christer From nobody Sun Mar 25 16:32:01 2018 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 5EBE21243F6 for ; Sun, 25 Mar 2018 16:31:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.686 X-Spam-Level: X-Spam-Status: No, score=-1.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 8L21MO84DAEF for ; Sun, 25 Mar 2018 16:31:57 -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 38E541204DA for ; Sun, 25 Mar 2018 16:31:56 -0700 (PDT) Received: from resomta-ch2-18v.sys.comcast.net ([69.252.207.114]) by resqmta-ch2-12v.sys.comcast.net with ESMTP id 0F6tf4KlgpRAJ0F7DffKIb; Sun, 25 Mar 2018 23:31:55 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-18v.sys.comcast.net with SMTP id 0F7Cfv8e40dXT0F7DfXJZu; Sun, 25 Mar 2018 23:31:55 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id w2PNVsAn007034 for ; Sun, 25 Mar 2018 19:31:54 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id w2PL1jrb031154; Sun, 25 Mar 2018 17:01:45 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: sipcore@ietf.org Sender: worley@ariadne.com (Dale R. Worley) Date: Sun, 25 Mar 2018 17:01:45 -0400 Message-ID: <87efk7uax2.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfAzJ9uznPGkVfEFuBD8joVpRoUI+5iKytKD8C/jMPbz+hGDhBnaCSj1tTDrCUWMNty3Esd82AjRgAxDxGWdwoHJu+RfNoe7vbgeugTdLAXhsNJOXqjlA acqtjs6sNWwJtmYvVpBhS9KyFvYXIXvrwUrPIZ7+IHOTAjeZCj/5r2N3 Archived-At: Subject: [sipcore] Organizing the sip-push work 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: Sun, 25 Mar 2018 23:31:58 -0000 Casting up accounts from the recent discussions, it seems to me that the various mechanisms can be divided into no less than *five* tranches, as diagrammed below. I recommend that we carry forward tranches 1 and 2 in draft-ietf-sipcore-sip-push, and tranches 3, 4, and 5 in another draft, oriented toward "supporting SIP Outbound with SIP Push". I particularly desire to incorporate tranche 2 (the "pn-aor" parameter, and allowing certain alternative behaviors by implementing proxies) into the current draft, because: 1) It is a small extension of -08, where the UAs add one further URI parameter. 2) It is upward-compatible from implementations of -08. 3) It allows implementation by "far" proxies, including edge proxies, and supports UAs acquiring different addresses when they awaken. 4) The support for "far" proxies establishes an architectural requirement that the pn-* parameters must be URI parameters (which would otherwise be a poor architectural choice). tranche 1 as in draft-ietf-sipcore-sip-push-08 implemented by: implementing proxies, UAs supporting SIP Push enables: current implementations, "near" proxies, no requirement for non-std. communication with registrar | | upward compatible with | v tranche 2 plus: pn-aor parameter implemented by: UAs supporting SIP Push, optionally by implementing proxies enables: "far" proxies, implementation by edge proxies, changing UA addresses (NAT traversal) | | upward compatible with | v tranche 3 plus: pn-reg-id parameter implemented by: UAs supporting SIP Push with SIP Outbound, implementing proxies supporting SIP Outbound enables: SIP Push combined with SIP Outbound | | upward compatible with | v tranche 4 plus: 'reg' event package extension 'path' element to report the Path header implemented by: registrars, optionally by proxies enables: SIP Push combined with SIP Outbound without having to watch for re-REGISTER or re-dispatch to the AOR | | independently upward compatible from tranche 1 | v tranche 5 plus: 'reg' event package extension 'last-reg' which is the number of seconds since the contact was last updated implemented by: registrars, optionally by proxies enables: implementing proxies do not need to send PN if the UA has recently reregistered Dale From nobody Sun Mar 25 16:32:05 2018 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 128141243F6 for ; Sun, 25 Mar 2018 16:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.685 X-Spam-Level: X-Spam-Status: No, score=-1.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 Y1TjvMfjNpoH for ; Sun, 25 Mar 2018 16:31:57 -0700 (PDT) Received: from resqmta-ch2-07v.sys.comcast.net (resqmta-ch2-07v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA64C1242EA for ; Sun, 25 Mar 2018 16:31:57 -0700 (PDT) Received: from resomta-ch2-17v.sys.comcast.net ([69.252.207.113]) by resqmta-ch2-07v.sys.comcast.net with ESMTP id 0F7AfywLOmnw40F7Ffyd08; Sun, 25 Mar 2018 23:31:57 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-17v.sys.comcast.net with SMTP id 0F7EfAfwVXFxc0F7EfaB2G; Sun, 25 Mar 2018 23:31:56 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id w2PNVsAr007034 for ; Sun, 25 Mar 2018 19:31:56 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id w2PKRNSZ029370; Sun, 25 Mar 2018 16:27:23 -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: <7594FB04B1934943A5C02806D1A2204B72DFC21D@ESESSMB102.ericsson.se> (christer.holmberg@ericsson.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Sun, 25 Mar 2018 16:27:22 -0400 Message-ID: <87lgefucid.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfEb+9X1b46gqCncbvFzoe09qHtSFA8KtaM+2eFVed6utpWVDqHt9RcAElTfS8NjVUl5RAjLClgd7gaWKCs8mVgr1SnV74DWFvA2yT474OUEpxp/W654c Z73GPNPIqz/1amJnsxvN2plAlgwaiwhoNC0KPYM4xg8xH8FBuSg126t2 Archived-At: Subject: Re: [sipcore] Allowing "far" proxies in 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: Sun, 25 Mar 2018 23:31:59 -0000 Christer Holmberg writes: >>> Also, any proxy (no matter whether it is "far" or "near") can use the >>> 'reg' event package in order to figure out the status of a >>> registration. > Doesn't the proxy get the AOR from the REGISTER request? The point of the proxy subscribing to reg events is so that it isn't required to see the re-REGISTER. There are several cases for that. The most significant one is the first, enabling "far" proxy network architectures. 1) One case is a "far" proxy, that is, far away from the registrar. If the UA is awakened, and sends a REGISTER to the registrar, the UA may be attached to the network in a differnt location, and the "far" proxy may not be on the path of the REGISTER request. 2) One case is a matter of design, when the proxy doesn't want to examine the message traffic for REGISTER requests. Instead, it can subscribe to the appropriate reg events. 3) Another possibility is if we can update reg events to report "last-reg", the length of time since the last registration. If the proxy subscribes to reg events for the correct AOR, it can determine if the UA has recently re-registered, and if so, it can omit sending a notification. Dale From nobody Sun Mar 25 16:32:11 2018 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 B97431242EA for ; Sun, 25 Mar 2018 16:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.685 X-Spam-Level: X-Spam-Status: No, score=-1.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 4zXgWiyr7zuk for ; Sun, 25 Mar 2018 16:31:58 -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 9CD041204DA for ; Sun, 25 Mar 2018 16:31:58 -0700 (PDT) Received: from resomta-ch2-15v.sys.comcast.net ([69.252.207.111]) by resqmta-ch2-06v.sys.comcast.net with ESMTP id 0F6hfTawewb2v0F7FfS6fc; Sun, 25 Mar 2018 23:31:57 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-15v.sys.comcast.net with SMTP id 0F7EfiQaCA1BJ0F7FfjRzN; Sun, 25 Mar 2018 23:31:57 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id w2PNVsAt007034; Sun, 25 Mar 2018 19:31:57 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id w2PKdpZA030000; Sun, 25 Mar 2018 16:39: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: Roman Shpount Cc: christer.holmberg@ericsson.com, sipcore@ietf.org In-Reply-To: (roman@telurix.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Sun, 25 Mar 2018 16:39:51 -0400 Message-ID: <87in9jubxk.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfCuzCWeaLawxaO6V0FYqAvwaqw9zJdSb2lk8NXlPKzAVIgIK/1CJ9tUzmxK4sHaim1slgR1PFGJYn351n68mZIaIqFenzIXzQ+YGiVzptt0pqh522x6B zxA0wXhGEnJRc+0NIVDCglp1ZOAJsxSSTTnHzG9tdifj99TmHsfsGja2OW9BvafhQ8UCvbn04YKNFA== Archived-At: Subject: Re: [sipcore] sip-push: Recongizing the re-REGISTER 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: Sun, 25 Mar 2018 23:32:00 -0000 Roman Shpount writes: > I am fairly sure that if SIP UA goes through different edge proxies when it > wakes then non of the current NAT traversal solutions will work. I think > the best way to address this in SIP Push draft is to spell out that this is > not supported. > > Fixing this in general case that you are describing is fairly hard, since > it will require the edge SIP proxy, when it gets a new registration, to > communicate with all the other edge proxies and check if they have any > queued SIP messages waiting for the connection from this client. After thinking about this case, I think it's simpler to fix than it first appears. I've given a fairly detailed first draft in another message, but the essence is that when the UA awakens and connects to a new edge proxy, it then sends a re-REGISTER. That REGISTER lands on the registrar, causing the 'cseq' parameter in the reg event package to increase. Any edge proxy that is queueing an initial request for the UA is watching that reg event package, and thus it sees 'cseq' being incremented. At that point, there are multiple techniques for delivering the queued requests, but the simplest is for the proxies that are queueing them to forward them to the original AOR. The requests return to the SIP domain's redirector, which sends them to the edge proxy that the UA is currently connected to, which knows that the UA is awake (by one method or another) and forwards the requests to the UA. Dale From nobody Sun Mar 25 17:52:23 2018 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 68107126DCA for ; Sun, 25 Mar 2018 17:52:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.686 X-Spam-Level: X-Spam-Status: No, score=-1.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 YUrbIQPjQ1y9 for ; Sun, 25 Mar 2018 17:52:21 -0700 (PDT) Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61B3B1242EA for ; Sun, 25 Mar 2018 17:52:21 -0700 (PDT) Received: from resomta-ch2-11v.sys.comcast.net ([69.252.207.107]) by resqmta-ch2-05v.sys.comcast.net with ESMTP id 0GMxfquzXs8BA0GN2fxcIh; Mon, 26 Mar 2018 00:52:20 +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 0GN1facDkiSdl0GN1fOTOX; Mon, 26 Mar 2018 00:52: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 w2Q0qJ5p011996; Sun, 25 Mar 2018 20:52:19 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id w2Q0qIXH011993; Sun, 25 Mar 2018 20:52: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: Christer Holmberg Cc: sipcore@ietf.org In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C20DC77@ESESSMB109.ericsson.se> (christer.holmberg@ericsson.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Sun, 25 Mar 2018 20:52:18 -0400 Message-ID: <87605ju08t.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfNyiHAqMDVCZJjHIUxkshM4+IvAlauK/KziL6EiZos9HaGlt1ONiGBo4spGlYUi5yhFElxuAt413MNgiJMGqFE9hsB9TOH8Jc4SRhYgqNR7qJXkElGfi ETJupT9GZqV6qGYOhtq9DYZ0aoHKcE+7Yx2HBxzksWwHqTTpIEiYXvv7rlrWJ604T1EZoAfP4ez30nJbuPr/K0uVSGOd6kpils4= Archived-At: Subject: Re: [sipcore] More comments regarding draft-ietf-sipcore-sip-push-08 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, 26 Mar 2018 00:52:22 -0000 Christer Holmberg writes: >> sec 5.2 makes it sound like the proxy is required to wake up the UA >>if the registration is close to expiration, even if the UA registered >>with sip.pnsreg and the proxy responded with sip.pnsreg. Is that >>intended? Because it sounds like the behavior of the proxy does not >>change based on sip.pnsreg -- it wakes up the UA if the registration >>is near expiration. In which case, what does sip.pnsreg do? As >>compared with sec 4, where sip.pnsreg seems to be the way that the UA >>and the proxy negotiate which one of them is reponsible for timing >>registrations. > > The difference in proxy behaviour is that, in case of sip.pnsreg, the > proxy waits until the "last minute" (120 seconds) for a > re-registration before it triggers a notification request. This should > only happen in error cases, where the UA has indicated that it will > send re-registrations but don't. In normal cases the UA will send > re-registrations, and there will be no need for the proxy to request > push notifications. I can understand that. But it seems to me that it would be better to soften this to MAY rather than MUST, so that if the proxy and UA negotiate sip.pnsreg, then the proxy doesn't need to keep state to monitor registration refreshes. Dale From nobody Mon Mar 26 00:21:46 2018 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 B7B20124C27 for ; Mon, 26 Mar 2018 00:21:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 e5QyygbQE2lI for ; Mon, 26 Mar 2018 00:21:43 -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 C5B9B126BF6 for ; Mon, 26 Mar 2018 00:21:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1522048900; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=d2vb9riXSwl1DjTDwWNWDQJ5SYGhCQqogkIQqZMX82g=; b=aLAUTJtzsF9PlRbcCDgg40WtzD87ls/yU/7+4BUCXyxHIbukEkDg4Q3ABG7H3LvB jONuwOe07wSS3u+B/rj9eKvXw3QUPsimVF+xl1IkjvwUlP/yZuE31YQaNQVFiI1w NErpy3SrFiyUoV+JjIh0H6uIVMCp/2BFKemdGRc/QcE=; X-AuditID: c1b4fb3a-e26ef9c000003647-a0-5ab89f84b26e Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id FC.35.13895.48F98BA5; Mon, 26 Mar 2018 09:21:40 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.115]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0382.000; Mon, 26 Mar 2018 09:21:34 +0200 From: Christer Holmberg To: "Dale R. Worley" CC: "sipcore@ietf.org" Thread-Topic: [sipcore] More comments regarding draft-ietf-sipcore-sip-push-08 Thread-Index: AQHTxJyzwvY/cWenN06lkBY104F72qPiLe+A Date: Mon, 26 Mar 2018 07:21:33 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B6C20DC77@ESESSMB109.ericsson.se> <87605ju08t.fsf@hobgoblin.ariadne.com> In-Reply-To: <87605ju08t.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: [131.160.50.130] Content-Type: text/plain; charset="us-ascii" Content-ID: <3194AB52A87C3B4EBB85C4C689C0521E@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDIsWRmVeSWpSXmKPExsUyM2K7q27L/B1RBpvPilh8/bGJzeLliTIH Jo/J+78yeyxZ8pMpgCmKyyYlNSezLLVI3y6BK2NLWytbwVGuivWftzI3MG7n6GLk5JAQMJFY 0H6XuYuRi0NI4AijRMPZg1DOEkaJpbePsHcxcnCwCVhIdP/TBjFFBDQlOhbkgPQyA5mPdu5l ArGFBXwlnm+/zwxiiwgESHSsu8ECYRtJdPxZDxZnEVCVuP1mHiPIGF4Ba4meNYogYSGBMon3 52+ygdicAsYScx4eAxvJKCAm8f3UGiaIVeISt57MZ4I4WUBiyZ7zzBC2qMTLx/9YQWxRAT2J DSdugx0sIaAkcXuDE0SrjsSC3Z/YIGxriamt06BGakssW/gabAyvgKDEyZlPWCYwis9Csm0W kvZZSNpnIWmfhaR9ASPrKkbR4tTi4tx0IyO91KLM5OLi/Dy9vNSSTYzAODu45bfVDsaDzx0P MQpwMCrx8O6evCNKiDWxrLgy9xCjBAezkgivjPv2KCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8 TmkWUUIC6YklqdmpqQWpRTBZJg5OqQZGOT7Gly/XhTXvMGzjS3Fhm2233jr5tqnmk13vZJf/ WjU5br2K64eC4k/1Jy7MOWffeNc29kh50gmFsxOtYyv/OdctKI6p7t5l4SIYwMIT/3/2Jd+r zoWTZvBEcHu8++rkMSspzzNJ5LKQn7JHecbU7ODM0HMajyQ3vl6SdTVE0MlNXeTpaS4lluKM REMt5qLiRAAbqmd7rwIAAA== Archived-At: Subject: Re: [sipcore] More comments regarding draft-ietf-sipcore-sip-push-08 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, 26 Mar 2018 07:21:45 -0000 Hi, >>>sec 5.2 makes it sound like the proxy is required to wake up the UA >>>if the registration is close to expiration, even if the UA registered >>>with sip.pnsreg and the proxy responded with sip.pnsreg. Is that >>>intended? Because it sounds like the behavior of the proxy does not >>>change based on sip.pnsreg -- it wakes up the UA if the registration >>>is near expiration. In which case, what does sip.pnsreg do? As >>>compared with sec 4, where sip.pnsreg seems to be the way that the UA >>>and the proxy negotiate which one of them is reponsible for timing >>>registrations. >> >> The difference in proxy behaviour is that, in case of sip.pnsreg, the >> proxy waits until the "last minute" (120 seconds) for a >> re-registration before it triggers a notification request. This should >> only happen in error cases, where the UA has indicated that it will >> send re-registrations but don't. In normal cases the UA will send >> re-registrations, and there will be no need for the proxy to request >> push notifications. > >I can understand that. But it seems to me that it would be better to >soften this to MAY rather than MUST, so that if the proxy and UA >negotiate sip.pnsreg, then the proxy doesn't need to keep state to >monitor registration refreshes. I can change to MAY. Regards, Christer From nobody Mon Mar 26 00:27:03 2018 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 AAC7F1243F6; Mon, 26 Mar 2018 00:26: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.76.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152204921765.3023.6393029284055432315@ietfa.amsl.com> Date: Mon, 26 Mar 2018 00:26:57 -0700 Archived-At: Subject: [sipcore] I-D Action: draft-ietf-sipcore-sip-push-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: Mon, 26 Mar 2018 07:26: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 : Push Notification with the Session Initiation Protocol (SIP) Authors : Christer Holmberg Michael Arnold Filename : draft-ietf-sipcore-sip-push-10.txt Pages : 25 Date : 2018-03-26 Abstract: This document describes how a Push Notification Service (PNS) can be used to awake suspended Session Initiation Protocol (SIP) User Agents (UAs), for the UA to be able to receive and send SIP requests. The document defines new SIP URI parameters and new feature-capability indicators that can be used in SIP messages to indicate support of the mechanism defined in this document, to exchange PNS information between the SIP User Agent (UA) and the SIP entity that will request push notifications towards the UA, and to trigger such push notification requests. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-push/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sipcore-sip-push-10 https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-sip-push-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-sip-push-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 Mon Mar 26 00:28:16 2018 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 9CB841243F6 for ; Mon, 26 Mar 2018 00:28:15 -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, 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=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 9zCW5azbScUa for ; Mon, 26 Mar 2018 00:28:14 -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 061A1126E01 for ; Mon, 26 Mar 2018 00:28:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1522049282; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=3E2jGPL/L3W7qOgNPMxOYTwlFXwmExTgjYv7MrG2R8E=; b=CmsbtBW+EgMADhPbzLbyX9ltffcH+iJy0IKgH3zZQHZhVGt16236oaSZp3ay0O4b cr0YW7ziK7n+JVMCtY/b9p4cLeRe8g9MdjjFvrBZqMs2Nl7UtDLfcgjCgY33r4Oh 1aNGx+miG+CyuSD05juF/nw2GrSRGou2OJWxBy8xsLE=; X-AuditID: c1b4fb2d-4b1ff70000005540-84-5ab8a1029d79 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 36.32.21824.201A8BA5; Mon, 26 Mar 2018 09:28:02 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.115]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0382.000; Mon, 26 Mar 2018 09:28:01 +0200 From: Christer Holmberg To: "sipcore@ietf.org" CC: "sipcore-chairs@ietf.org" Thread-Topic: Draft new version: sip-push-10 Thread-Index: AQHTxNP492Y2TFUhyk2UdLLcUkWnwA== Date: Mon, 26 Mar 2018 07:28:01 +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: [131.160.50.130] Content-Type: multipart/alternative; boundary="_000_D6DE7BE22D028christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjkeLIzCtJLcpLzFFi42KZGbHdT5dp4Y4og3PrpSx6Py9ktvj6YxOb A5PHkiU/mQIYo7hsUlJzMstSi/TtErgydrVeZCpYwVPx9+1UtgbGK1xdjJwcEgImEqf+L2Lv YuTiEBI4wiixe8FJJghnCaPE4WsbWLsYOTjYBCwkuv9pgzSICGhKLP+2lR3EZhYwl2jrbmEB sYUF1CUaf05ig6jRkbhy7xEThK0n8fzONmYQm0VAVaLj4UYwm1fAWuL5hSNgNqOAmMT3U2uY IGaKS9x6Mp8J4jgBiSV7zjND2KISLx//YwWxRYFmbjhxmx3kNAkBJYnbG5wgWhMk+jqns0GM F5Q4OfMJywRG4VlIps5CUjYLSRlE3EDi/bn5zBC2tsSyha+hbH2JjV/OMkLY1hK7mhewIqtZ wMixilG0OLW4ODfdyFgvtSgzubg4P08vL7VkEyMwlg5u+a27g3H1a8dDjAIcjEo8vIZTdkQJ sSaWFVfmHmKU4GBWEuHlmw8U4k1JrKxKLcqPLyrNSS0+xCjNwaIkznvSkzdKSCA9sSQ1OzW1 ILUIJsvEwSnVwNhbYe7SZbBtFptxlhGf0t371jfWTsyO2Hg6wH+Zxl62lreuEtJndl9R+K28 9Zb7sjWLHattDs74LJHvXhtbrXHOVPsEZ0myxMZkTUu91++/crrbMYka7gyaLrjzpZ1arRJD if1Ug+UbDG/WNPFaNtvvuHDn036zk4xdMRkLJN4v5lx2zzTPXImlOCPRUIu5qDgRACiXW9Wh AgAA Archived-At: Subject: [sipcore] Draft new version: sip-push-10 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, 26 Mar 2018 07:28:15 -0000 --_000_D6DE7BE22D028christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, Based on Dale=92s comments, I have submitted a new version (-10) of sip-pus= h. The main changes are: * 556 response code added * VAPID clarified The following pull request was merged for the new version: https://github.com/cdh4u/draft-sip-push/pull/16 Regards, Christer --_000_D6DE7BE22D028christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <19122406D30B7549A14A579E7B0A9470@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

Based on Dale=92s comments, I have submitted a new version (-10) of si= p-push.

The main changes are:
  • 556 response code added
  • VAPID clarified
The following pull request was merged for the new version:


Regards,

Christer
--_000_D6DE7BE22D028christerholmbergericssoncom_-- From nobody Mon Mar 26 00:44:34 2018 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 03D2D1243F6 for ; Mon, 26 Mar 2018 00:44:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 9dE6RrLDkLJY for ; Mon, 26 Mar 2018 00:44:31 -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 4239E1200C5 for ; Mon, 26 Mar 2018 00:44:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1522050269; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=gbASBMK8kN4dSk+VhRsJMtALwLs5niIkdezEbZAG4Ls=; b=LNyGpqkQgYHApypuv+M7qJrrSPPUscyKQDtj3wznvjoNe1+wNzuGXEKjP7jKZFrG EqrlM5FZ4MQE0GvS1oUoYgOknZXPxp7Kd3aofwwPT+hJL0i7Wllenz2i8iUYxZ5U t3KaY2yRvr0ItwN34R2bTwQQWr/J/quXkKyRjjBTFDw=; X-AuditID: c1b4fb3a-e26ef9c000003647-df-5ab8a4ddebff Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id F8.AA.13895.DD4A8BA5; Mon, 26 Mar 2018 09:44:29 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.115]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0382.000; Mon, 26 Mar 2018 09:44:27 +0200 From: Christer Holmberg To: "Dale R. Worley" , Roman Shpount CC: "sipcore@ietf.org" Thread-Topic: [sipcore] sip-push: Recongizing the re-REGISTER Thread-Index: AQHTxHlso3oD+jI3TEmHjc9qC5tyLaPiNJ0A Date: Mon, 26 Mar 2018 07:44:27 +0000 Message-ID: References: <87in9jubxk.fsf@hobgoblin.ariadne.com> In-Reply-To: <87in9jubxk.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: [131.160.50.130] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <57E843F19C30B342ABB7753A02A2D542@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKIsWRmVeSWpSXmKPExsUyM2K7ru7dJTuiDFqfqFjMuDCV2eLrj01s Fi9PlDkwe0ze/5XZY8mSn0wet6YUBDBHcdmkpOZklqUW6dslcGVMuvKcpWCXQMWbs4INjJN4 uxg5OSQETCS6fuxh7mLk4hASOMIocfzPYkYIZwmjxOy3m4EyHBxsAhYS3f+0QRpEBHwktnx+ zgZiMwtoSjzauZcJxBYWsJG49voSG0SNrcTkZVOYQFpFBIwkpi8oBgmzCKhK/GjcCFbOK2At MflHEzOILSRQKbG/u5cVxOYUMJb41f4GLM4oICbx/dQaJohV4hK3nsxngrhZQGLJnvPMELao xMvH/8B6RQX0JDacuM0OslZCQEni9gYniFY9iRtTp0BdbC3xZdYBqJHaEssWvmaGOEdQ4uTM JywTGMVnIdk2C0n7LCTts5C0z0LSvoCRdRWjaHFqcXFuupGRXmpRZnJxcX6eXl5qySZGYOQd 3PLbagfjweeOhxgFOBiVeHh3T94RJcSaWFZcmXuIUYKDWUmEl28+UIg3JbGyKrUoP76oNCe1 +BCjNAeLkjivU5pFlJBAemJJanZqakFqEUyWiYNTqoGx7d6pNJ05kZyh0cu1dnI/jNke0BsY r77018UZ0rl2iS02a69cbI8xXZuz6cSHq1eiT4obmkpM37Bgz5X0iN0n6gXy+dS5FsWUXtmx 80v6ov+zcoMZ5u1ev5/30fQ/7PG1n4rz33yXOuVsn7lGx/6oSdjCw6c3PzBntJbv/Jx+1uP8 7ObuujtTlFiKMxINtZiLihMBC8gsZrgCAAA= Archived-At: Subject: Re: [sipcore] sip-push: Recongizing the re-REGISTER 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, 26 Mar 2018 07:44:33 -0000 >> >>I am fairly sure that if SIP UA goes through different edge proxies when >>it >> wakes then non of the current NAT traversal solutions will work. I think >> the best way to address this in SIP Push draft is to spell out that >>this is >> not supported. >> >> Fixing this in general case that you are describing is fairly hard, >>since >> it will require the edge SIP proxy, when it gets a new registration, to >> communicate with all the other edge proxies and check if they have any >> queued SIP messages waiting for the connection from this client. > >After thinking about this case, I think it's simpler to fix than it >first appears. I've given a fairly detailed first draft in another >message, but the essence is that when the UA awakens and connects to a >new edge proxy, it then sends a re-REGISTER. That REGISTER lands on the >registrar, causing the 'cseq' parameter in the reg event package to >increase. How do you know that the =B3new=B2 edge proxy supports SIP push to begin wi= th? The support is negotiated during registration, and if you want to register via multiple proxies you should use Outbound. Also note that RFC 3261 says that re-registrations SHOULD be sent to the same network address as the original registration. So, if you want start sending re-registrations =B3all over=B2 I think that goes beyond SIP push. >Any edge proxy that is queueing an initial request for the UA is >watching that reg event package, and thus it sees 'cseq' being >incremented. At that point, there are multiple techniques for >delivering the queued requests, but the simplest is for the proxies that >are queueing them to forward them to the original AOR. The requests >return to the SIP domain's redirector, which sends them to the edge >proxy that the UA is currently connected to, which knows that the UA is >awake (by one method or another) and forwards the requests to the UA. What is the =B3SIP domain=B9s redirector=B2? It is really difficult for me to picture your scenario, so please provide call flows. Regards, Christer From nobody Mon Mar 26 00:52:40 2018 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 85618126DED for ; Mon, 26 Mar 2018 00:52:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 qCGX8iSusozX for ; Mon, 26 Mar 2018 00:52:37 -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 1551F1200C5 for ; Mon, 26 Mar 2018 00:52:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1522050754; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=xSaByDhQIN+HxG+CCGHQXfe9G/NpKouJYJHNc65DG/E=; b=dbi2quu4MarvHpoY0J69kwI70Ii9QUWfAmis4E7wbTePwHoMKMWGuKXrWxgC7Uyi QLBSof9XTbVbFGCuDxrMOE8TB+Bz1MtmdeNM1eDppL8JyqrwVWyEBhrmGA4rpXhy Wc6rM6x0heicMMWvhmG0x0hAKChzp8Om64atBFO+614=; X-AuditID: c1b4fb3a-e26ef9c000003647-2d-5ab8a6c26c36 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id F0.AC.13895.2C6A8BA5; Mon, 26 Mar 2018 09:52:34 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.115]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0382.000; Mon, 26 Mar 2018 09:52:17 +0200 From: Christer Holmberg To: "Dale R. Worley" CC: "sipcore@ietf.org" Thread-Topic: [sipcore] Allowing "far" proxies in sip-push Thread-Index: AQHTxJF3tXbL9R2Rm0CEL7RGHvLb/qPiNp0A Date: Mon, 26 Mar 2018 07:52:16 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B72DFC21D@ESESSMB102.ericsson.se> <87lgefucid.fsf@hobgoblin.ariadne.com> In-Reply-To: <87lgefucid.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: [131.160.50.130] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNIsWRmVeSWpSXmKPExsUyM2K7iu6hZTuiDGY/Frf4+mMTm8XLE2UO TB6T939l9liy5CdTAFMUl01Kak5mWWqRvl0CV8azK89ZCw7wVtw6soKpgfEVVxcjJ4eEgInE 267ZbF2MXBxCAkcYJbZsXM4I4SxhlHgzawdzFyMHB5uAhUT3P20QU0RAU6JjQQ5ILzOQ+Wjn XiYQW1jAUuLthxPsILaIgJXEi58zWCDKjSQ2LAXrZBFQldh9gg2kglfAWuLUm+dgnUICZRJN rzYzgticAsYSLxtvsILYjAJiEt9PrWGC2CQucevJfCaIiwUkluw5zwxhi0q8fPwPrF5UQE9i w4nb7CCrJASUJG5vcIJo1ZFYsPsTG4RtLfHqdiM7hK0tsWzha2aIcwQlTs58wjKBUXwWkm2z kLTPQtI+C0n7LCTtCxhZVzGKFqcWF+emGxnppRZlJhcX5+fp5aWWbGIERtnBLb+tdjAefO54 iFGAg1GJh3f35B1RQqyJZcWVuYcYJTiYlUR4+eYDhXhTEiurUovy44tKc1KLDzFKc7AoifM6 pVlECQmkJ5akZqemFqQWwWSZODilGhhZRI4fubSEcemGkMsd7/r9zh87My3I2a3ugiGrqqSw eqXGoh8zldZN2x/Bsu+mP5vxgb6vM64sfmbfpvbY5mzoys7ZO6YdVz9y1rGp/h27vN+C3o4G +Y3KnEsWiKt0Pva0/LVeQca56x/P81Wfxcw2Vq9/rcXBePwIX870eHt1w1qW/KyK0gwlluKM REMt5qLiRACOZvlLrgIAAA== Archived-At: Subject: Re: [sipcore] Allowing "far" proxies in 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, 26 Mar 2018 07:52:38 -0000 Hi, I suggest that the scenarios are described in a separate draft. It is not only about defining a new pn- parameter - in my opinion it requires call flows in order to understand the whole underlying concept, it requires procedures, it requires the reg-event extension, it requires additional NAT traversal considerations, etc etc etc. Regards, Christer =20 On 25/03/18 23:27, "Dale R. Worley" wrote: >Christer Holmberg writes: >>>> Also, any proxy (no matter whether it is "far" or "near") can use the >>>> 'reg' event package in order to figure out the status of a >>>> registration. > >> Doesn't the proxy get the AOR from the REGISTER request? > >The point of the proxy subscribing to reg events is so that it isn't >required to see the re-REGISTER. There are several cases for that. The >most significant one is the first, enabling "far" proxy network >architectures. > >1) One case is a "far" proxy, that is, far away from the registrar. If >the UA is awakened, and sends a REGISTER to the registrar, the UA may be >attached to the network in a differnt location, and the "far" proxy may >not be on the path of the REGISTER request. > >2) One case is a matter of design, when the proxy doesn't want to >examine the message traffic for REGISTER requests. Instead, it can >subscribe to the appropriate reg events. > >3) Another possibility is if we can update reg events to report >"last-reg", the length of time since the last registration. If the >proxy subscribes to reg events for the correct AOR, it can determine if >the UA has recently re-registered, and if so, it can omit sending a >notification. > >Dale From nobody Mon Mar 26 00:56:46 2018 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 BD02F126DED for ; Mon, 26 Mar 2018 00:56:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 x4Wc3h3dhXGd for ; Mon, 26 Mar 2018 00:56:43 -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 CD3D41200C5 for ; Mon, 26 Mar 2018 00:56:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1522051001; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=rXk6fIU5DPEdFKos/chXBYD+kAN+5ePKCPs8RueuUrY=; b=dEWl0V7G5VyW8XXmVRtY4ywV56EQ710kB50zna96VCWEyt5W3uRdMax0ZGB04Vyo IguPGU+2JJuCFdRmgPGQu0l8hnYwbHWL3R5K907kFRUQS9tT9rUYmRAp9RPxJvYj NSooc8vklO3F+DDbztT7CX/q9JTlPyUhzwIBgTb+Wls=; X-AuditID: c1b4fb30-433ff7000000197d-87-5ab8a7b89684 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 6D.13.06525.8B7A8BA5; Mon, 26 Mar 2018 09:56:41 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.115]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0382.000; Mon, 26 Mar 2018 09:56:40 +0200 From: Christer Holmberg To: "Dale R. Worley" , "sipcore@ietf.org" Thread-Topic: [sipcore] Organizing the sip-push work Thread-Index: AQHTxJF9bn6JSPnBLEOaVvnC2712C6PiN9aA Date: Mon, 26 Mar 2018 07:56:39 +0000 Message-ID: References: <87efk7uax2.fsf@hobgoblin.ariadne.com> In-Reply-To: <87efk7uax2.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: [131.160.50.130] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <2E794F7A40815A45B1103287452A5824@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplkeLIzCtJLcpLzFFi42KZGbFdWnfn8h1RBpPa2Cy+/tjEZvHyRJkD k8fk/V+ZPZYs+ckUwBTFZZOSmpNZllqkb5fAlbF0RkrBJImKl6e3sjUwLhfuYuTkkBAwkdh3 bS5LFyMXh5DAEUaJy7s+s4AkhASWMEpMOmHdxcjBwSZgIdH9TxskLCIQJLGpcwUziC0sYCxx dtJPVpASEaA5P68UQ5QYSUyae5AVxGYRUJXY+v8VG4jNK2At8W7lRWaI6UYSHTOOgNmcQGO2 Tb/PCGIzCohJfD+1hgnEZhYQl7j1ZD4TxJkCEkv2nGeGsEUlXj7+BzZfVEBPYsOJ2+wgJ0gI KEnc3uAE0aoncWPqFDaQMDPQ2j2/fSDC2hLLFr5mhrhGUOLkzCcsExjFZiFZNgtJ9yyE7llI umch6V7AyLqKUbQ4tTgpN93ISC+1KDO5uDg/Ty8vtWQTIzCSDm75bbCD8eVzx0OMAhyMSjy8 SVN2RAmxJpYVV+YeYpTgYFYS4eWbDxTiTUmsrEotyo8vKs1JLT7EKM3BoiTOa+G3OUpIID2x JDU7NbUgtQgmy8TBKdXAuMBzb9wy9nXz589f3GU28XWG6oxfBtMSo3XL/1VX+d+qcOXT2K55 Pq9pyryLp3yqqh+8t7P/p/935bJZl1YdWrR9TcYW8d25HQrZJcVvuPiUrk1Y2tK2R8/wnc0T a+0Z2/aKzn47p8M/0vde5NM2ey/nf3ca9zd6TKpaFrl5w/+EU9LHLB251yuxFGckGmoxFxUn AgCRoF1UoAIAAA== Archived-At: Subject: Re: [sipcore] Organizing the sip-push work 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, 26 Mar 2018 07:56:45 -0000 Hi, I don=B9t think that tranche 2 is a =B3small extension of -08=B2, since I t= hink it requires more than just defining a pn-aor parameter. So, as it is an extension, my suggestion is to define it in a separate draft. If you DO think it is a small extension, such draft should be short and easy to put together :). Regards, Christer On 26/03/18 00:01, "sipcore on behalf of Dale R. Worley" wrote: >Casting up accounts from the recent discussions, it seems to me that the >various mechanisms can be divided into no less than *five* tranches, as >diagrammed below. > >I recommend that we carry forward tranches 1 and 2 in >draft-ietf-sipcore-sip-push, and tranches 3, 4, and 5 in another draft, >oriented toward "supporting SIP Outbound with SIP Push". > >I particularly desire to incorporate tranche 2 (the "pn-aor" parameter, >and allowing certain alternative behaviors by implementing proxies) into >the current draft, because: >1) It is a small extension of -08, where the UAs add one further URI >parameter. >2) It is upward-compatible from implementations of -08. >3) It allows implementation by "far" proxies, including edge proxies, >and supports UAs acquiring different addresses when they awaken. >4) The support for "far" proxies establishes an architectural >requirement that the pn-* parameters must be URI parameters (which would >otherwise be a poor architectural choice). > > >tranche 1 as in draft-ietf-sipcore-sip-push-08 > implemented by: implementing proxies, UAs supporting SIP Push > enables: current implementations, "near" proxies, > no requirement for non-std. communication with registrar > | > | upward compatible with > | > v >tranche 2 plus: pn-aor parameter > implemented by: UAs supporting SIP Push, optionally by > implementing proxies > enables: "far" proxies, implementation by edge proxies, > changing UA addresses (NAT traversal) > | > | upward compatible with > | > v >tranche 3 plus: pn-reg-id parameter > implemented by: UAs supporting SIP Push with SIP Outbound, > implementing proxies supporting SIP Outbound > enables: SIP Push combined with SIP Outbound > | > | upward compatible with > | > v >tranche 4 plus: 'reg' event package extension 'path' element to report > the Path header > implemented by: registrars, optionally by proxies > enables: SIP Push combined with SIP Outbound without having > to watch for re-REGISTER or re-dispatch to the AOR > > > | > | independently upward compatible from tranche 1 > | > v >tranche 5 plus: 'reg' event package extension 'last-reg' which is the > number of seconds since the contact was last updated > implemented by: registrars, optionally by proxies > enables: implementing proxies do not need to send PN if > the UA has recently reregistered > >Dale > >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore From nobody Mon Mar 26 05:57:44 2018 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 BE30F1201FA for ; Mon, 26 Mar 2018 05:57:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 RIpCTS2eWpEH for ; Mon, 26 Mar 2018 05:57:39 -0700 (PDT) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (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 6D5A8127201 for ; Mon, 26 Mar 2018 05:57:39 -0700 (PDT) Received: by mail-qt0-x232.google.com with SMTP id l18so3083676qtj.1 for ; Mon, 26 Mar 2018 05:57:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ail6r5XcRHOD4iw8Tja++zmRm8P+3BPEWhhMtvLPLxw=; b=irTLF8gq20uK7COr/7vRcvcBWB1XgGovvO8ebdT0O9z29cefWG1pWOaqdAPw4NLsnm dVZLoEwJgp1E+o2k24WY1V174iv3kLcfUBOzhKNsIXrSYLJndsQQ61m1JPTBM8f15Hgz PsE6S80ZOmXO4MlVZT+PQ671vlnDA88tuL0JqHLa/WX+VbAeLzDU9HyZ4HnlVMWIQkLn +FNEe/RE39Q8bb4TaYw+7ELfrJ6ZmkRgyG72sJxZLvXfAGggsX2qYrtmSMYDP8aWqBsa U2AICl4vkseq6xmFCSM7UTN/jytTwUikUwYZlMGp3EbVWylDx3+B1ncRtUpaGpNZgvu3 v8Dg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ail6r5XcRHOD4iw8Tja++zmRm8P+3BPEWhhMtvLPLxw=; b=pQY2BmYM8QcoiMPMTK4+OmfAGBe3bIBhnz8igYh2ZCIM2sFhd6f+yzH3PRHKMX+rx3 DyqddoL4QlcrhUl1nMhumdbXUA+CcGpQXze0hCWQCBJI8AX5Gcv6WQL0w6wvYr8do+2D NeFrg5/LueiIY+7tBYVxV9HE9xdu8XlasjHYrwAgBg6VhcUaFKBo5jWeWwqturLk4vjU 8VRkkbmO9hM5jzLGSziPyvE74URNGwgZ+F7kc68A8Nx0SUFMmwO9v8/PT2Qrtq/hAvui dhieZ4+R45Rsh4PFgbiN3MjBOB7efRZzzLvo1PXE8voFWXEw0WQOnjGUEUeI02JVojrn Ghsw== X-Gm-Message-State: AElRT7HuRtXGagtHKm1PbEmspSVjpt7wF6uUGbMy10rq4xNtu0AS4FfR 9+yYuS9+pDErW3yNd79uIMPKSVOmmwU= X-Google-Smtp-Source: AG47ELuuwIGA0+Dqf9XeJXqaFg0PdnzynrWgt+ce36wNSSPns8P8KlAv5eOfDlj8uXUSozsFI04few== X-Received: by 10.200.35.48 with SMTP id a45mr42218877qta.311.1522069058440; Mon, 26 Mar 2018 05:57:38 -0700 (PDT) Received: from brosen-mac.lan (dynamic-acs-72-23-220-128.zoominternet.net. [72.23.220.128]) by smtp.gmail.com with ESMTPSA id x49sm11515792qth.62.2018.03.26.05.57.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Mar 2018 05:57:37 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Brian Rosen In-Reply-To: <87efk7uax2.fsf@hobgoblin.ariadne.com> Date: Mon, 26 Mar 2018 08:57:22 -0400 Cc: sipcore@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <87efk7uax2.fsf@hobgoblin.ariadne.com> To: "Dale R. Worley" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [sipcore] Organizing the sip-push work 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, 26 Mar 2018 12:57:43 -0000 This is getting complicated fast. Are there actual use cases for tranches 2-5? I understand the actual = use case for what Christer=E2=80=99s draft does. I kind of get the need = for interaction between PUSH and Outbound, although it=E2=80=99s not = clear to me that there is an existing or planned implementation that = needs it. More of a theoretic problem. Let=E2=80=99s look more closely at Tranch 2: why does this case exist? = Why is the proxy changing it=E2=80=99s address and not re-registering? = Are you aware of implementations that do this, need PUSH and wouldn=E2=80=99= t work with the existing text? =20 Chairs would like this draft to finish shortly. There seems to be a = disconnect between you and the guy writing the text on how necessary and = complicated it is to support =E2=80=9Cfar=E2=80=9D proxies. We=E2=80=99re= okay with a follow up draft dealing with interactions between PUSH and = Outbound, but what do we really need to do to get this draft out the = door and useful to implementors? Brian > On Mar 25, 2018, at 5:01 PM, Dale R. Worley = wrote: >=20 > Casting up accounts from the recent discussions, it seems to me that = the > various mechanisms can be divided into no less than *five* tranches, = as > diagrammed below. >=20 > I recommend that we carry forward tranches 1 and 2 in > draft-ietf-sipcore-sip-push, and tranches 3, 4, and 5 in another = draft, > oriented toward "supporting SIP Outbound with SIP Push". >=20 > I particularly desire to incorporate tranche 2 (the "pn-aor" = parameter, > and allowing certain alternative behaviors by implementing proxies) = into > the current draft, because: > 1) It is a small extension of -08, where the UAs add one further URI > parameter. > 2) It is upward-compatible from implementations of -08. > 3) It allows implementation by "far" proxies, including edge proxies, > and supports UAs acquiring different addresses when they awaken. > 4) The support for "far" proxies establishes an architectural > requirement that the pn-* parameters must be URI parameters (which = would > otherwise be a poor architectural choice). >=20 >=20 > tranche 1 as in draft-ietf-sipcore-sip-push-08 > implemented by: implementing proxies, UAs supporting SIP = Push > enables: current implementations, "near" proxies, > no requirement for non-std. communication with = registrar > | > | upward compatible with > | > v > tranche 2 plus: pn-aor parameter > implemented by: UAs supporting SIP Push, optionally by > implementing proxies > enables: "far" proxies, implementation by edge proxies, > changing UA addresses (NAT traversal) > | > | upward compatible with > | > v > tranche 3 plus: pn-reg-id parameter > implemented by: UAs supporting SIP Push with SIP = Outbound, > implementing proxies supporting SIP Outbound > enables: SIP Push combined with SIP Outbound > | > | upward compatible with > | > v > tranche 4 plus: 'reg' event package extension 'path' element to = report > the Path header > implemented by: registrars, optionally by proxies > enables: SIP Push combined with SIP Outbound without = having > to watch for re-REGISTER or re-dispatch to the = AOR >=20 >=20 > | > | independently upward compatible from tranche 1 > | > v > tranche 5 plus: 'reg' event package extension 'last-reg' which is = the > number of seconds since the contact was last = updated > implemented by: registrars, optionally by proxies > enables: implementing proxies do not need to send PN if > the UA has recently reregistered >=20 > Dale >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Mon Mar 26 11:00:48 2018 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 8D08B1277BB for ; Mon, 26 Mar 2018 11:00:47 -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 ierKzD433I6J for ; Mon, 26 Mar 2018 11:00:45 -0700 (PDT) Received: from mail-pg0-x22c.google.com (mail-pg0-x22c.google.com [IPv6:2607:f8b0:400e:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E55F126CC4 for ; Mon, 26 Mar 2018 11:00:45 -0700 (PDT) Received: by mail-pg0-x22c.google.com with SMTP id f10so7398950pgs.9 for ; Mon, 26 Mar 2018 11:00:45 -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=GT3S2lBAnu4xbZPjSkpogBk0gO5slLMLV2HZIBAdZGU=; b=QfvAD+O7HgVot04RI7JeDquRSdUHdsOaQ9Ps+hTbv6O097F/JeMygQr5jQzeydGb13 yWGwxd6/fYNKdX370wa3O6xPOcC57Ozz8vRSMOnGhmn9HVQQgozt9SkOsTn/CMbh0ntc xr+FlNGHG4igNWF5LFyE6vCoeuHB/Vc3lguDN/df011hMTv3Sf2Ho3bJAy+o74268PCB IcRGZiSPOgsuqcf/sZt9YbQuUWHagJ2BpWgtj5YJusyfC5IS0u2uNoye3VeK/YjImdEW jFl9GDTjtkwO8WOfBVrfzDiuhf7do36SmJAAbGG7FBdKtMghnDmaj3yfl/+9GxLT6iTq +qTw== 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=GT3S2lBAnu4xbZPjSkpogBk0gO5slLMLV2HZIBAdZGU=; b=L6z9NDQzAwBbozYtUhZ5ltjUK9NP8OvhAumdCleK78cVfRwlrvOP4cQWsD/tOwNxmc 1uxpl5b9DYbYHEXWJgsRrp+SbWk7NMGceCluD2g6woH0+Ybd0E1zKywKzDOuK6qX9VIu hBGZtFWIKId/B8NPZDcYdsLxJkhJ6VDJoFe7BEWiG6COQba35EoFmD3ORvAyH5g5MyU4 62S4/tsoxeESFVSnScZ1KU67kvyeeFDgBqYR4BaLYKiy6JXosXa23yAQuGF9h2VitFOn jBNcedxeqeZ2KvSHuv7LNpZ7V8Y4m0hTdTDdMBKfUrYqrLe+7fdgmy2LiCqHmY8dHsYm JMjg== X-Gm-Message-State: AElRT7GVGNJEOxUGFVtGS0z41jYmyUr2AcihomOBCSDZNe3alxP3gtx+ RjrMmywBmUjhE4AV7F1H7P4yJorq X-Google-Smtp-Source: AG47ELuVPjsqn/++RrcSX6FbJg8hS7WdLYvWSSLHWJ3554mar5EXDjXdw7TCtt3H0/U+Hxffd2vPXQ== X-Received: by 10.99.95.144 with SMTP id t138mr28356423pgb.94.1522087244159; Mon, 26 Mar 2018 11:00:44 -0700 (PDT) Received: from mail-pl0-f49.google.com (mail-pl0-f49.google.com. [209.85.160.49]) by smtp.gmail.com with ESMTPSA id 81sm9208485pfl.92.2018.03.26.11.00.43 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Mar 2018 11:00:43 -0700 (PDT) Received: by mail-pl0-f49.google.com with SMTP id n15-v6so12409973plp.12 for ; Mon, 26 Mar 2018 11:00:43 -0700 (PDT) X-Received: by 2002:a17:902:8b82:: with SMTP id ay2-v6mr40742591plb.12.1522087243095; Mon, 26 Mar 2018 11:00:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.241.132 with HTTP; Mon, 26 Mar 2018 11:00:42 -0700 (PDT) In-Reply-To: References: <87efk7uax2.fsf@hobgoblin.ariadne.com> From: Roman Shpount Date: Mon, 26 Mar 2018 14:00:42 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Brian Rosen Cc: "Dale R. Worley" , SIPCORE Content-Type: multipart/alternative; boundary="00000000000071261e0568548dbb" Archived-At: Subject: Re: [sipcore] Organizing the sip-push work 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, 26 Mar 2018 18:00:47 -0000 --00000000000071261e0568548dbb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Brian, We had an existing implementation which have combined Push and Outbound for a fairly large number of mobile end points. Since most of the mobile clients are behind NAT and require SIPS, SIP Outbound and Push are commonly deployed together. Our deployment was not based on the current SIP Push draft, but it was not theoretical. This being said, I agree with Christer that defining how SIP Outbound works with Push belongs to a new draft. Regards, _____________ Roman Shpount On Mon, Mar 26, 2018 at 8:57 AM, Brian Rosen wrote: > This is getting complicated fast. > > Are there actual use cases for tranches 2-5? I understand the actual use > case for what Christer=E2=80=99s draft does. I kind of get the need for > interaction between PUSH and Outbound, although it=E2=80=99s not clear to= me that > there is an existing or planned implementation that needs it. More of a > theoretic problem. > > Let=E2=80=99s look more closely at Tranch 2: why does this case exist? W= hy is the > proxy changing it=E2=80=99s address and not re-registering? Are you awa= re of > implementations that do this, need PUSH and wouldn=E2=80=99t work with th= e existing > text? > > Chairs would like this draft to finish shortly. There seems to be a > disconnect between you and the guy writing the text on how necessary and > complicated it is to support =E2=80=9Cfar=E2=80=9D proxies. We=E2=80=99r= e okay with a follow up > draft dealing with interactions between PUSH and Outbound, but what do we > really need to do to get this draft out the door and useful to implemento= rs? > > Brian > > > On Mar 25, 2018, at 5:01 PM, Dale R. Worley wrote: > > > > Casting up accounts from the recent discussions, it seems to me that th= e > > various mechanisms can be divided into no less than *five* tranches, as > > diagrammed below. > > > > I recommend that we carry forward tranches 1 and 2 in > > draft-ietf-sipcore-sip-push, and tranches 3, 4, and 5 in another draft, > > oriented toward "supporting SIP Outbound with SIP Push". > > > > I particularly desire to incorporate tranche 2 (the "pn-aor" parameter, > > and allowing certain alternative behaviors by implementing proxies) int= o > > the current draft, because: > > 1) It is a small extension of -08, where the UAs add one further URI > > parameter. > > 2) It is upward-compatible from implementations of -08. > > 3) It allows implementation by "far" proxies, including edge proxies, > > and supports UAs acquiring different addresses when they awaken. > > 4) The support for "far" proxies establishes an architectural > > requirement that the pn-* parameters must be URI parameters (which woul= d > > otherwise be a poor architectural choice). > > > > > > tranche 1 as in draft-ietf-sipcore-sip-push-08 > > implemented by: implementing proxies, UAs supporting SIP > Push > > enables: current implementations, "near" proxies, > > no requirement for non-std. communication with > registrar > > | > > | upward compatible with > > | > > v > > tranche 2 plus: pn-aor parameter > > implemented by: UAs supporting SIP Push, optionally by > > implementing proxies > > enables: "far" proxies, implementation by edge proxies, > > changing UA addresses (NAT traversal) > > | > > | upward compatible with > > | > > v > > tranche 3 plus: pn-reg-id parameter > > implemented by: UAs supporting SIP Push with SIP Outbound= , > > implementing proxies supporting SIP Outbound > > enables: SIP Push combined with SIP Outbound > > | > > | upward compatible with > > | > > v > > tranche 4 plus: 'reg' event package extension 'path' element to > report > > the Path header > > implemented by: registrars, optionally by proxies > > enables: SIP Push combined with SIP Outbound without havi= ng > > to watch for re-REGISTER or re-dispatch to the AO= R > > > > > > | > > | independently upward compatible from tranche 1 > > | > > v > > tranche 5 plus: 'reg' event package extension 'last-reg' which is t= he > > number of seconds since the contact was last > updated > > implemented by: registrars, optionally by proxies > > enables: implementing proxies do not need to send PN if > > the UA has recently reregistered > > > > Dale > > > > _______________________________________________ > > 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 > --00000000000071261e0568548dbb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Brian,

We had an existing implementatio= n which have combined Push and Outbound for a fairly large number of mobile= end points. Since most of the mobile clients are behind NAT and require SI= PS, SIP Outbound and Push are commonly deployed together. Our deployment wa= s not based on the current SIP Push draft, but it was not theoretical. This= being said, I agree with Christer that defining how SIP Outbound works wit= h Push belongs to a new draft.

Regards,

_____________
Roman Shpount

On Mon, Mar 26, 2018 at 8:57 AM, Brian Rosen= <br@brianrosen.net> wrote:

Brian

> On Mar 25, 2018, at 5:01 PM, Dale R. Worley <worley@ariadne.com> wrote:
>
> Casting up accounts from the recent discussions, it seems to me that t= he
> various mechanisms can be divided into no less than *five* tranches, a= s
> diagrammed below.
>
> I recommend that we carry forward tranches 1 and 2 in
> draft-ietf-sipcore-sip-push, and tranches 3, 4, and 5 in another draft= ,
> oriented toward "supporting SIP Outbound with SIP Push".
>
> I particularly desire to incorporate tranche 2 (the "pn-aor"= parameter,
> and allowing certain alternative behaviors by implementing proxies) in= to
> the current draft, because:
> 1) It is a small extension of -08, where the UAs add one further URI > parameter.
> 2) It is upward-compatible from implementations of -08.
> 3) It allows implementation by "far" proxies, including edge= proxies,
> and supports UAs acquiring different addresses when they awaken.
> 4) The support for "far" proxies establishes an architectura= l
> requirement that the pn-* parameters must be URI parameters (which wou= ld
> otherwise be a poor architectural choice).
>
>
> tranche 1=C2=A0 =C2=A0 =C2=A0as in draft-ietf-sipcore-sip-push-08
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0implemented by: = implementing proxies, UAs supporting SIP Push
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enables: current= implementations, "near" proxies,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0no requirement for non-std. communication with registrar
>=C2=A0 =C2=A0|
>=C2=A0 =C2=A0| upward compatible with
>=C2=A0 =C2=A0|
>=C2=A0 =C2=A0v
> tranche 2=C2=A0 =C2=A0 =C2=A0plus: pn-aor parameter
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0implemented by: = UAs supporting SIP Push, optionally by
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0implementing proxies
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enables: "f= ar" proxies, implementation by edge proxies,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0changing UA addresses (NAT traversal)
>=C2=A0 =C2=A0|
>=C2=A0 =C2=A0| upward compatible with
>=C2=A0 =C2=A0|
>=C2=A0 =C2=A0v
> tranche 3=C2=A0 =C2=A0 =C2=A0plus: pn-reg-id parameter
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0implemented by: = UAs supporting SIP Push with SIP Outbound,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0implementing proxies supporting SIP Outbound
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enables: SIP Pus= h combined with SIP Outbound
>=C2=A0 =C2=A0|
>=C2=A0 =C2=A0| upward compatible with
>=C2=A0 =C2=A0|
>=C2=A0 =C2=A0v
> tranche 4=C2=A0 =C2=A0 =C2=A0plus: 'reg' event package extensi= on 'path' element to report
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0the Path header
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0implemented by: = registrars, optionally by proxies
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enables: SIP Pus= h combined with SIP Outbound without having
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0to watch for re-REGISTER or re-dispatch to the AOR
>
>
>=C2=A0 =C2=A0|
>=C2=A0 =C2=A0| independently upward compatible from tranche 1
>=C2=A0 =C2=A0|
>=C2=A0 =C2=A0v
> tranche 5=C2=A0 =C2=A0 =C2=A0plus: 'reg' event package extensi= on 'last-reg' which is the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0number of seconds since the contact was last updated
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0implemented by: = registrars, optionally by proxies
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enables: impleme= nting proxies do not need to send PN if
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0the UA has recently reregistered
>
> Dale
>
> _______________________________________________
> 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<= br>

--00000000000071261e0568548dbb-- From nobody Mon Mar 26 11:13:14 2018 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 C2E8C127136 for ; Mon, 26 Mar 2018 11:13:12 -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, 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 4M_aNiDxPbg4 for ; Mon, 26 Mar 2018 11:13:10 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (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 F0E98129C56 for ; Mon, 26 Mar 2018 11:13:08 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id v68so6405105ywg.13 for ; Mon, 26 Mar 2018 11:13:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=w29TyjQRUZmDcVFSc2h/98vhlvEB5oy70zEHLl6WgOs=; b=cNcUp20iU7FUhEKC1WgInuZL426KXyG5yOgNPWZmkpKjlkgZD711wXcSnQefuUyeFM 3tnBk6BGQFzwS8w/VcAP/rr82ODziC+LLqqqKOGvb5rm0ioRAInRGxXNK+QgVX8Kj0DG FvuAeb0KxbfrblSbH53JGOh215ss5rN3LZX+qZd1EXzlqwBOMp878y/G2BSWOyH9Irls ltAFgexXStmcCbzokg+Nx+rO/qoxbL3UvM8sTCIHtDDBAjmiu+ZUIXT/xvAP/kSz0ju7 AhMQ2rqjzld0y0agCosxn4MpKPJTP9Bq/MdPjn+U289TVaFUpmsYm0GwqCn8sItUxM+H Uujw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=w29TyjQRUZmDcVFSc2h/98vhlvEB5oy70zEHLl6WgOs=; b=iPjE8iXreDQtI/xD/rFiKZAXcO/hvi/fBZ446ZDFAKeIL8bURttxrUj0YRHdA4HBY4 0Zm8Sa5jQjqwKgL/RydIH5eFEX28oysK0hjuB5n5d0Axnp6Zr9Vgi2/AoEa4f0fga65j SZkrWGErpftCGy4++SHyADl0Vfk0VoRe1VaRAhHNh4/Fesf8sdNPPc8myA1DiwD42/ta DQjLFbekWPGgtLHcRm1VwgxyP2etvMnkev9aK0CfIT9QR71yMjkaPRJTDsZ/wybWdLGp Gs+dl0hkBvHtMVLw1tq13Ja5l8yzoeyXgNpZmgK0+cQpq7uY6dcaPy+Altz+9AoY8nQt Z7bg== X-Gm-Message-State: AElRT7EBsrZu/NxkseQ87DPqqEw9fW4DAhHbmGFpg/95CY0gMtBP5CDe 1Q7u5IZsQW7ixhRXImnkCN54ew== X-Google-Smtp-Source: AG47ELswy+V+KVDPJ4QYVq+nRWoLwGP/ECbUJPfhOEjG4dhV/UJ+kvtIaDgxs266zZT+jeQEAjZsRQ== X-Received: by 10.129.107.11 with SMTP id g11mr23570976ywc.459.1522087987950; Mon, 26 Mar 2018 11:13:07 -0700 (PDT) Received: from [10.96.40.72] (neustar-sthide-nat1.neustar.biz. [156.154.81.54]) by smtp.gmail.com with ESMTPSA id x15sm6092753ywj.19.2018.03.26.11.13.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Mar 2018 11:13:06 -0700 (PDT) From: Brian Rosen Message-Id: <9BA4FCE3-7E5F-479E-828A-1658C93688B9@brianrosen.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_0F31F592-FAE6-4CA1-8549-5ACF1CDC8DD4" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 26 Mar 2018 14:13:05 -0400 In-Reply-To: Cc: "Dale R. Worley" , SIPCORE To: Roman Shpount References: <87efk7uax2.fsf@hobgoblin.ariadne.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [sipcore] Organizing the sip-push work 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, 26 Mar 2018 18:13:13 -0000 --Apple-Mail=_0F31F592-FAE6-4CA1-8549-5ACF1CDC8DD4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Okay, that=E2=80=99s helpful - the new draft would address a real = deployment (albeit you did something pre-standards). =20 But you don=E2=80=99t know of anything that would match what Dale called = =E2=80=9CTranche 2=E2=80=9D, requiring the pn-aor and what Christer = thinks is a bunch of text changes? Brian > On Mar 26, 2018, at 2:00 PM, Roman Shpount wrote: >=20 > Brian, >=20 > We had an existing implementation which have combined Push and = Outbound for a fairly large number of mobile end points. Since most of = the mobile clients are behind NAT and require SIPS, SIP Outbound and = Push are commonly deployed together. Our deployment was not based on the = current SIP Push draft, but it was not theoretical. This being said, I = agree with Christer that defining how SIP Outbound works with Push = belongs to a new draft. >=20 > Regards, >=20 > _____________ > Roman Shpount >=20 > On Mon, Mar 26, 2018 at 8:57 AM, Brian Rosen > wrote: > This is getting complicated fast. >=20 > Are there actual use cases for tranches 2-5? I understand the actual = use case for what Christer=E2=80=99s draft does. I kind of get the need = for interaction between PUSH and Outbound, although it=E2=80=99s not = clear to me that there is an existing or planned implementation that = needs it. More of a theoretic problem. >=20 > Let=E2=80=99s look more closely at Tranch 2: why does this case exist? = Why is the proxy changing it=E2=80=99s address and not re-registering? = Are you aware of implementations that do this, need PUSH and wouldn=E2=80= =99t work with the existing text? >=20 > Chairs would like this draft to finish shortly. There seems to be a = disconnect between you and the guy writing the text on how necessary and = complicated it is to support =E2=80=9Cfar=E2=80=9D proxies. We=E2=80=99re= okay with a follow up draft dealing with interactions between PUSH and = Outbound, but what do we really need to do to get this draft out the = door and useful to implementors? >=20 > Brian >=20 > > On Mar 25, 2018, at 5:01 PM, Dale R. Worley > wrote: > > > > Casting up accounts from the recent discussions, it seems to me that = the > > various mechanisms can be divided into no less than *five* tranches, = as > > diagrammed below. > > > > I recommend that we carry forward tranches 1 and 2 in > > draft-ietf-sipcore-sip-push, and tranches 3, 4, and 5 in another = draft, > > oriented toward "supporting SIP Outbound with SIP Push". > > > > I particularly desire to incorporate tranche 2 (the "pn-aor" = parameter, > > and allowing certain alternative behaviors by implementing proxies) = into > > the current draft, because: > > 1) It is a small extension of -08, where the UAs add one further URI > > parameter. > > 2) It is upward-compatible from implementations of -08. > > 3) It allows implementation by "far" proxies, including edge = proxies, > > and supports UAs acquiring different addresses when they awaken. > > 4) The support for "far" proxies establishes an architectural > > requirement that the pn-* parameters must be URI parameters (which = would > > otherwise be a poor architectural choice). > > > > > > tranche 1 as in draft-ietf-sipcore-sip-push-08 > > implemented by: implementing proxies, UAs supporting = SIP Push > > enables: current implementations, "near" proxies, > > no requirement for non-std. communication with = registrar > > | > > | upward compatible with > > | > > v > > tranche 2 plus: pn-aor parameter > > implemented by: UAs supporting SIP Push, optionally by > > implementing proxies > > enables: "far" proxies, implementation by edge = proxies, > > changing UA addresses (NAT traversal) > > | > > | upward compatible with > > | > > v > > tranche 3 plus: pn-reg-id parameter > > implemented by: UAs supporting SIP Push with SIP = Outbound, > > implementing proxies supporting SIP Outbound > > enables: SIP Push combined with SIP Outbound > > | > > | upward compatible with > > | > > v > > tranche 4 plus: 'reg' event package extension 'path' element to = report > > the Path header > > implemented by: registrars, optionally by proxies > > enables: SIP Push combined with SIP Outbound without = having > > to watch for re-REGISTER or re-dispatch to the = AOR > > > > > > | > > | independently upward compatible from tranche 1 > > | > > v > > tranche 5 plus: 'reg' event package extension 'last-reg' which = is the > > number of seconds since the contact was last = updated > > implemented by: registrars, optionally by proxies > > enables: implementing proxies do not need to send PN = if > > the UA has recently reregistered > > > > Dale > > > > _______________________________________________ > > 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 --Apple-Mail=_0F31F592-FAE6-4CA1-8549-5ACF1CDC8DD4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Okay, that=E2=80=99s helpful - the new draft would address a = real deployment (albeit you did something pre-standards).  

But you don=E2=80=99t = know of anything that would match what Dale called =E2=80=9CTranche = 2=E2=80=9D, requiring the pn-aor and what Christer thinks is a bunch of = text changes?

Brian

On Mar 26, 2018, at 2:00 PM, = Roman Shpount <roman@telurix.com> wrote:

Brian,

We = had an existing implementation which have combined Push and Outbound for = a fairly large number of mobile end points. Since most of the mobile = clients are behind NAT and require SIPS, SIP Outbound and Push are = commonly deployed together. Our deployment was not based on the current = SIP Push draft, but it was not theoretical. This being said, I agree = with Christer that defining how SIP Outbound works with Push belongs to = a new draft.

Regards,

_____________
Roman = Shpount

On Mon, Mar 26, 2018 at 8:57 = AM, Brian Rosen <br@brianrosen.net> wrote:
This is getting = complicated fast.

Are there actual use cases for tranches 2-5?  I understand the = actual use case for what Christer=E2=80=99s draft does.  I kind of = get the need for interaction between PUSH and Outbound, although it=E2=80=99= s not clear to me that there is an existing or planned implementation = that needs it. More of a theoretic problem.

Let=E2=80=99s look more closely at Tranch 2: why does this case = exist?  Why is the proxy changing it=E2=80=99s address and not = re-registering?   Are you aware of implementations that do = this, need PUSH and wouldn=E2=80=99t work with the existing text?

Chairs would like this draft to finish shortly.  There seems to be = a disconnect between you and the guy writing the text on how necessary = and complicated it is to support =E2=80=9Cfar=E2=80=9D proxies.  = We=E2=80=99re okay with a follow up draft dealing with interactions = between PUSH and Outbound, but what do we really need to do to get this = draft out the door and useful to implementors?

Brian

> On Mar 25, 2018, at 5:01 PM, Dale R. Worley <worley@ariadne.com> = wrote:
>
> Casting up accounts from the recent discussions, it seems to me = that the
> various mechanisms can be divided into no less than *five* = tranches, as
> diagrammed below.
>
> I recommend that we carry forward tranches 1 and 2 in
> draft-ietf-sipcore-sip-push, and tranches 3, 4, and 5 in another = draft,
> oriented toward "supporting SIP Outbound with SIP Push".
>
> I particularly desire to incorporate tranche 2 (the "pn-aor" = parameter,
> and allowing certain alternative behaviors by implementing proxies) = into
> the current draft, because:
> 1) It is a small extension of -08, where the UAs add one further = URI
> parameter.
> 2) It is upward-compatible from implementations of -08.
> 3) It allows implementation by "far" proxies, including edge = proxies,
> and supports UAs acquiring different addresses when they awaken.
> 4) The support for "far" proxies establishes an architectural
> requirement that the pn-* parameters must be URI parameters (which = would
> otherwise be a poor architectural choice).
>
>
> tranche 1     as in = draft-ietf-sipcore-sip-push-08
>               implemented = by: implementing proxies, UAs supporting SIP Push
>               enables: = current implementations, "near" proxies,
>                  =      no requirement for non-std. communication with = registrar
>   |
>   | upward compatible with
>   |
>   v
> tranche 2     plus: pn-aor parameter
>               implemented = by: UAs supporting SIP Push, optionally by
>                  =      implementing proxies
>               enables: = "far" proxies, implementation by edge proxies,
>                  =      changing UA addresses (NAT traversal)
>   |
>   | upward compatible with
>   |
>   v
> tranche 3     plus: pn-reg-id parameter
= >               implemented = by: UAs supporting SIP Push with SIP Outbound,
>                  =      implementing proxies supporting SIP Outbound
>               enables: SIP = Push combined with SIP Outbound
>   |
>   | upward compatible with
>   |
>   v
> tranche 4     plus: 'reg' event package extension = 'path' element to report
>                  =      the Path header
>               implemented = by: registrars, optionally by proxies
>               enables: SIP = Push combined with SIP Outbound without having
>                  =      to watch for re-REGISTER or re-dispatch to the = AOR
>
>
>   |
>   | independently upward compatible from tranche 1
>   |
>   v
> tranche 5     plus: 'reg' event package extension = 'last-reg' which is the
>                  =      number of seconds since the contact was last = updated
>               implemented = by: registrars, optionally by proxies
>               enables: = implementing proxies do not need to send PN if
>                  =      the UA has recently reregistered
>
> Dale
>
> _______________________________________________
> 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


= --Apple-Mail=_0F31F592-FAE6-4CA1-8549-5ACF1CDC8DD4-- From nobody Mon Mar 26 11:17:24 2018 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 530BB126D05 for ; Mon, 26 Mar 2018 11:17:22 -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 E9i4rmZhGiTL for ; Mon, 26 Mar 2018 11:17:19 -0700 (PDT) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::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 990AF126CE8 for ; Mon, 26 Mar 2018 11:17:19 -0700 (PDT) Received: by mail-pf0-x234.google.com with SMTP id v66so5370480pfv.7 for ; Mon, 26 Mar 2018 11:17:19 -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=GK8tjxhtypl6CcHBNbQ7XSwoOTGeE06xIgVCRLBaCYk=; b=S0FM9aA4Fg0j0f95Kpdbkvk4X2/vO9yyoSX6BauWKhjgCelgCPGBi6bM5QfhCieEB9 Eov2D7cma5gDWLs03zf+ZpmDDdwpUlDhbMzmG6PIUNKjEqTfekeaqbBsrm6OlNdoo/gY xB7Rr1vMV5vu4cHwKeOHBTUT5DzZEsBNgNa6uaRbhAJ+1CMwBQE80IP6pTI5Ny+M6axH 5lQ7jqog98b+K4+FQI7Pu81Pwwt+zXITpqwgNy0EKyu40zLl7IvkmEx+dMgzw9JyYfF6 tcarpE6ZzwK3HEMSbWp4uavC38JVJ/i5k2OZhqga685w2V3I8/qdFM4VPKFAn+LIx+Fi XdXQ== 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=GK8tjxhtypl6CcHBNbQ7XSwoOTGeE06xIgVCRLBaCYk=; b=kEVY07+PDNkcOgOT7LXAHGp4Li0JE2gq+VfvFwYlUz1dle5ezG9yptzvmEq+7w8eI6 8R/lx7e3kiH5yLLfjCjFR3yIJCXWsdI424fjBZXKwKnIoeBcamw/6N9npwDLzjSILmho lkFfJA9IPNPzb3DUwUxbM2SUNQ5tUw58ZIF2eZ/1I8bLUbrPVnPjOh0lgl+GiINmACz1 bIilCuv0z8bITu+umjbgusqZQGQLLimOy1O82wOIxUnMIf2+S5Fw1Nf3HTYPn6DkS6oy TyUYLbYwsWZrk5H8VtRbjQw6t9iRArKD9zNWJvhPLl0k8TZt9JRUyH5Vz2xPTYH1Pc4h 6oNw== X-Gm-Message-State: AElRT7FUyTwaEr6lJP5h6kptY38Ip0Dj+r//zcK6h3Tf00R4+hm+Swz6 2NC8gXW7jIKU3OE/ZrGXKulgbFaq X-Google-Smtp-Source: AG47ELv69PQx+jKintsAWK0XOttjeKXGhjeSdy8rYRczPvP4YAfyYoB1e+hddR4KxI3eUG3pOCmwMA== X-Received: by 10.99.95.75 with SMTP id t72mr9184091pgb.411.1522088238927; Mon, 26 Mar 2018 11:17:18 -0700 (PDT) Received: from mail-pf0-f173.google.com (mail-pf0-f173.google.com. [209.85.192.173]) by smtp.gmail.com with ESMTPSA id a76sm14223774pfc.97.2018.03.26.11.17.18 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Mar 2018 11:17:18 -0700 (PDT) Received: by mail-pf0-f173.google.com with SMTP id v66so5370442pfv.7 for ; Mon, 26 Mar 2018 11:17:18 -0700 (PDT) X-Received: by 10.99.110.129 with SMTP id j123mr19986895pgc.65.1522088237779; Mon, 26 Mar 2018 11:17:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.241.132 with HTTP; Mon, 26 Mar 2018 11:17:16 -0700 (PDT) In-Reply-To: <9BA4FCE3-7E5F-479E-828A-1658C93688B9@brianrosen.net> References: <87efk7uax2.fsf@hobgoblin.ariadne.com> <9BA4FCE3-7E5F-479E-828A-1658C93688B9@brianrosen.net> From: Roman Shpount Date: Mon, 26 Mar 2018 14:17:16 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Brian Rosen Cc: "Dale R. Worley" , SIPCORE Content-Type: multipart/alternative; boundary="94eb2c19e0c6bad4eb056854c840" Archived-At: Subject: Re: [sipcore] Organizing the sip-push work 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, 26 Mar 2018 18:17:22 -0000 --94eb2c19e0c6bad4eb056854c840 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Brian, I have mentioned this before to Dale -- I do not know of the use case for Dale's " Tranche 2" Regards, _____________ Roman Shpount On Mon, Mar 26, 2018 at 2:13 PM, Brian Rosen wrote: > Okay, that=E2=80=99s helpful - the new draft would address a real deploym= ent > (albeit you did something pre-standards). > > But you don=E2=80=99t know of anything that would match what Dale called = =E2=80=9CTranche > 2=E2=80=9D, requiring the pn-aor and what Christer thinks is a bunch of t= ext > changes? > > Brian > > On Mar 26, 2018, at 2:00 PM, Roman Shpount wrote: > > Brian, > > We had an existing implementation which have combined Push and Outbound > for a fairly large number of mobile end points. Since most of the mobile > clients are behind NAT and require SIPS, SIP Outbound and Push are common= ly > deployed together. Our deployment was not based on the current SIP Push > draft, but it was not theoretical. This being said, I agree with Christer > that defining how SIP Outbound works with Push belongs to a new draft. > > Regards, > > _____________ > Roman Shpount > > On Mon, Mar 26, 2018 at 8:57 AM, Brian Rosen wrote: > >> This is getting complicated fast. >> >> Are there actual use cases for tranches 2-5? I understand the actual us= e >> case for what Christer=E2=80=99s draft does. I kind of get the need for >> interaction between PUSH and Outbound, although it=E2=80=99s not clear t= o me that >> there is an existing or planned implementation that needs it. More of a >> theoretic problem. >> >> Let=E2=80=99s look more closely at Tranch 2: why does this case exist? = Why is >> the proxy changing it=E2=80=99s address and not re-registering? Are yo= u aware of >> implementations that do this, need PUSH and wouldn=E2=80=99t work with t= he existing >> text? >> >> Chairs would like this draft to finish shortly. There seems to be a >> disconnect between you and the guy writing the text on how necessary and >> complicated it is to support =E2=80=9Cfar=E2=80=9D proxies. We=E2=80=99= re okay with a follow up >> draft dealing with interactions between PUSH and Outbound, but what do w= e >> really need to do to get this draft out the door and useful to implement= ors? >> >> Brian >> >> > On Mar 25, 2018, at 5:01 PM, Dale R. Worley wrote= : >> > >> > Casting up accounts from the recent discussions, it seems to me that t= he >> > various mechanisms can be divided into no less than *five* tranches, a= s >> > diagrammed below. >> > >> > I recommend that we carry forward tranches 1 and 2 in >> > draft-ietf-sipcore-sip-push, and tranches 3, 4, and 5 in another draft= , >> > oriented toward "supporting SIP Outbound with SIP Push". >> > >> > I particularly desire to incorporate tranche 2 (the "pn-aor" parameter= , >> > and allowing certain alternative behaviors by implementing proxies) in= to >> > the current draft, because: >> > 1) It is a small extension of -08, where the UAs add one further URI >> > parameter. >> > 2) It is upward-compatible from implementations of -08. >> > 3) It allows implementation by "far" proxies, including edge proxies, >> > and supports UAs acquiring different addresses when they awaken. >> > 4) The support for "far" proxies establishes an architectural >> > requirement that the pn-* parameters must be URI parameters (which wou= ld >> > otherwise be a poor architectural choice). >> > >> > >> > tranche 1 as in draft-ietf-sipcore-sip-push-08 >> > implemented by: implementing proxies, UAs supporting SIP >> Push >> > enables: current implementations, "near" proxies, >> > no requirement for non-std. communication with >> registrar >> > | >> > | upward compatible with >> > | >> > v >> > tranche 2 plus: pn-aor parameter >> > implemented by: UAs supporting SIP Push, optionally by >> > implementing proxies >> > enables: "far" proxies, implementation by edge proxies, >> > changing UA addresses (NAT traversal) >> > | >> > | upward compatible with >> > | >> > v >> > tranche 3 plus: pn-reg-id parameter >> > implemented by: UAs supporting SIP Push with SIP Outboun= d, >> > implementing proxies supporting SIP Outbound >> > enables: SIP Push combined with SIP Outbound >> > | >> > | upward compatible with >> > | >> > v >> > tranche 4 plus: 'reg' event package extension 'path' element to >> report >> > the Path header >> > implemented by: registrars, optionally by proxies >> > enables: SIP Push combined with SIP Outbound without >> having >> > to watch for re-REGISTER or re-dispatch to the A= OR >> > >> > >> > | >> > | independently upward compatible from tranche 1 >> > | >> > v >> > tranche 5 plus: 'reg' event package extension 'last-reg' which is >> the >> > number of seconds since the contact was last >> updated >> > implemented by: registrars, optionally by proxies >> > enables: implementing proxies do not need to send PN if >> > the UA has recently reregistered >> > >> > Dale >> > >> > _______________________________________________ >> > 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 >> > > > --94eb2c19e0c6bad4eb056854c840 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Brian,

I have mentioned this before to = Dale -- I do not know of the use case for Dale's=C2=A0" Tranche 2"

Regards,
_____________
Roman Shpount

On Mon, Mar 26, 2018 at 2:13 PM, Brian Rosen= <br@brianrosen.net> wrote:
Okay, that=E2=80=99s helpful - the ne= w draft would address a real deployment (albeit you did something pre-stand= ards). =C2=A0

But you don=E2=80=99t know of anything tha= t would match what Dale called =E2=80=9CTranche 2=E2=80=9D, requiring the p= n-aor and what Christer thinks is a bunch of text changes?

Brian
<= /span>

O= n Mar 26, 2018, at 2:00 PM, Roman Shpount <roman@telurix.com> wrote:

= Brian,

We had an existing implementation which have comb= ined Push and Outbound for a fairly large number of mobile end points. Sinc= e most of the mobile clients are behind NAT and require SIPS, SIP Outbound = and Push are commonly deployed together. Our deployment was not based on th= e current SIP Push draft, but it was not theoretical. This being said, I ag= ree with Christer that defining how SIP Outbound works with Push belongs to= a new draft.

Regards,

_____________
Roman Shpou= nt

On Mon, Mar 26, 2018 at 8:57 AM, Brian Rosen= <br@brianrosen.net> wrote:

Brian

> On Mar 25, 2018, at 5:01 PM, Dale R. Worley <worley@ariadne.com> wrote:
>
> Casting up accounts from the recent discussions, it seems to me that t= he
> various mechanisms can be divided into no less than *five* tranches, a= s
> diagrammed below.
>
> I recommend that we carry forward tranches 1 and 2 in
> draft-ietf-sipcore-sip-push, and tranches 3, 4, and 5 in another draft= ,
> oriented toward "supporting SIP Outbound with SIP Push".
>
> I particularly desire to incorporate tranche 2 (the "pn-aor"= parameter,
> and allowing certain alternative behaviors by implementing proxies) in= to
> the current draft, because:
> 1) It is a small extension of -08, where the UAs add one further URI > parameter.
> 2) It is upward-compatible from implementations of -08.
> 3) It allows implementation by "far" proxies, including edge= proxies,
> and supports UAs acquiring different addresses when they awaken.
> 4) The support for "far" proxies establishes an architectura= l
> requirement that the pn-* parameters must be URI parameters (which wou= ld
> otherwise be a poor architectural choice).
>
>
> tranche 1=C2=A0 =C2=A0 =C2=A0as in draft-ietf-sipcore-sip-push-08
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0implemented by: = implementing proxies, UAs supporting SIP Push
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enables: current= implementations, "near" proxies,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0no requirement for non-std. communication with registrar
>=C2=A0 =C2=A0|
>=C2=A0 =C2=A0| upward compatible with
>=C2=A0 =C2=A0|
>=C2=A0 =C2=A0v
> tranche 2=C2=A0 =C2=A0 =C2=A0plus: pn-aor parameter
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0implemented by: = UAs supporting SIP Push, optionally by
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0implementing proxies
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enables: "f= ar" proxies, implementation by edge proxies,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0changing UA addresses (NAT traversal)
>=C2=A0 =C2=A0|
>=C2=A0 =C2=A0| upward compatible with
>=C2=A0 =C2=A0|
>=C2=A0 =C2=A0v
> tranche 3=C2=A0 =C2=A0 =C2=A0plus: pn-reg-id parameter
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0implemented by: = UAs supporting SIP Push with SIP Outbound,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0implementing proxies supporting SIP Outbound
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enables: SIP Pus= h combined with SIP Outbound
>=C2=A0 =C2=A0|
>=C2=A0 =C2=A0| upward compatible with
>=C2=A0 =C2=A0|
>=C2=A0 =C2=A0v
> tranche 4=C2=A0 =C2=A0 =C2=A0plus: 'reg' event package extensi= on 'path' element to report
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0the Path header
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0implemented by: = registrars, optionally by proxies
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enables: SIP Pus= h combined with SIP Outbound without having
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0to watch for re-REGISTER or re-dispatch to the AOR
>
>
>=C2=A0 =C2=A0|
>=C2=A0 =C2=A0| independently upward compatible from tranche 1
>=C2=A0 =C2=A0|
>=C2=A0 =C2=A0v
> tranche 5=C2=A0 =C2=A0 =C2=A0plus: 'reg' event package extensi= on 'last-reg' which is the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0number of seconds since the contact was last updated
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0implemented by: = registrars, optionally by proxies
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enables: impleme= nting proxies do not need to send PN if
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0the UA has recently reregistered
>
> Dale
>
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org=
> https://www.ietf.org/mailman/listinfo/sipcore=

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


--94eb2c19e0c6bad4eb056854c840-- From nobody Tue Mar 27 03:18:54 2018 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 241631200B9 for ; Tue, 27 Mar 2018 03:18:53 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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=metaswitch.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 2azbRG-9VcI8 for ; Tue, 27 Mar 2018 03:18:49 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0117.outbound.protection.outlook.com [104.47.42.117]) (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 80A9012D88D for ; Tue, 27 Mar 2018 03:18:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metaswitch.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Zr1HhRcsRV8V5q9NfvEinfJuE2JRjAgZpEZtw8F8zPc=; b=hlp1HddImrVQkQO2VxK8ZvbfSM0Uf25IZi6JLw1Iepiz15p+S+3UEOECjndGbU8HXwzO+h2jiXhBNL33JTC4l8K8PKooING/P7A8PIsP7cyABvRHLPvOJEWjGzIbyex8mdzkbv+5TbrT/cNFglybqJNlc3y72Sx7Pxoi6ecarFg= Received: from CY1PR02MB1262.namprd02.prod.outlook.com (10.163.16.155) by CY1PR02MB2139.namprd02.prod.outlook.com (10.166.190.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.609.10; Tue, 27 Mar 2018 10:18:47 +0000 Received: from CY1PR02MB1262.namprd02.prod.outlook.com ([fe80::2089:ae79:db04:11a4]) by CY1PR02MB1262.namprd02.prod.outlook.com ([fe80::2089:ae79:db04:11a4%13]) with mapi id 15.20.0609.012; Tue, 27 Mar 2018 10:18:47 +0000 From: Mickey Arnold To: Roman Shpount , Brian Rosen CC: "Dale R. Worley" , SIPCORE Thread-Topic: [sipcore] Organizing the sip-push work Thread-Index: AQHTxJF9OfygunbOikaa/wGhOaTal6PietIAgABUwQCAAAN1gIAAASsAgAEG48A= Date: Tue, 27 Mar 2018 10:18:31 +0000 Deferred-Delivery: Tue, 27 Mar 2018 10:17:50 +0000 Message-ID: References: <87efk7uax2.fsf@hobgoblin.ariadne.com> <9BA4FCE3-7E5F-479E-828A-1658C93688B9@brianrosen.net> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Arnold@metaswitch.com; x-originating-ip: [2620:104:4000:206e:f45c:bfbd:fae9:c5fc] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY1PR02MB2139; 7:Fcz3neJ1Uly/tIiduqerkrIdE2HN+otrgEcNi8Gm5FxAdJB+ssnqlBsXEcOzDtIdfuCN44W7+rjBMI61StDC5ovGWqUtcv8z8i3jZQmT2QvCk0tbgVWIIVN9AogTBPJlQ43yW7MJnqOV123KKrWM9iOh6YB7ywkHZ9ZCQw3+BaoeYb910Q+JTtbx/tGaJiGcmgQ0DU++M5Q8zXI0QtAUIMioG8iNP7JzknOGb7IEIDhKsm7L+X27ub05g1wlLMjo x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: fb9db94f-0e1a-4963-b727-08d593cc20aa x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:CY1PR02MB2139; x-ms-traffictypediagnostic: CY1PR02MB2139: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(48300812402016)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(3231221)(944501327)(52105095)(10201501046)(3002001)(93006095)(93001095)(6041310)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(20161123560045)(6072148)(201708071742011); SRVR:CY1PR02MB2139; BCL:0; PCL:0; RULEID:; SRVR:CY1PR02MB2139; x-forefront-prvs: 0624A2429E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(346002)(366004)(396003)(376002)(39850400004)(39380400002)(189003)(199004)(11346002)(8676002)(3280700002)(97736004)(186003)(2906002)(4326008)(7736002)(46003)(2900100001)(81166006)(102836004)(74316002)(93886005)(486005)(76176011)(486005)(229853002)(446003)(5250100002)(25786009)(53546011)(81156014)(6506007)(316002)(478600001)(606006)(72206003)(54906003)(110136005)(86362001)(8936002)(6246003)(99286004)(236005)(105586002)(6436002)(55016002)(68736007)(6116002)(966005)(3660700001)(33656002)(53936002)(54896002)(6666003)(6306002)(14454004)(106356001)(9686003)(476003)(790700001)(5660300001)(7696005)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR02MB2139; H:CY1PR02MB1262.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: metaswitch.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 4SpgnsgfQM5XO6m801xuXAxYOE4FemERqGLioT2rW9Bp+F8Gg5rR8M+o/3H+sbxOA4wEiScF+rYh0lev+3uZy6r2I6S+103aIIjL548571tQoux2CNz6RXD2tl5Bru9m4n1FbnG2/yTDvkztrhIcLoaJXJuqgbiZS4eouTW28YNAeLTKlo4IOx6Y2r6CY1bw6S/rLvaQRlmT3O/wYEIP78ZD/EIuuPIJK98a86L4vkJHH1FsFSDQE0fDxVw+TexhgBLbxFgY188Gu3tHPOa5EQV9NFyfWCKWk0P1yBaZ5IqQn5HjLkcAJnK6hrakQjDSh5fJvHPQyUKaJTU3O6cvgg== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR02MB12627138F1DE5EB4E5D735D6E9AC0CY1PR02MB1262namp_" MIME-Version: 1.0 X-OriginatorOrg: metaswitch.com X-MS-Exchange-CrossTenant-Network-Message-Id: fb9db94f-0e1a-4963-b727-08d593cc20aa X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Mar 2018 10:18:47.1744 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR02MB2139 Archived-At: Subject: Re: [sipcore] Organizing the sip-push work 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, 27 Mar 2018 10:18:53 -0000 --_000_CY1PR02MB12627138F1DE5EB4E5D735D6E9AC0CY1PR02MB1262namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QnJpYW4sDQoNCkp1c3QgdG8gYWRkIG15IHRob3VnaHRzIG9uIHRoaXMuDQoNCkkgY2FuIHNlZSBh IGNvbmNlcHR1YWwgYmVuZWZpdCB0byBoYXZpbmcgc29tZSBzb3J0IG9mIG1lY2hhbmlzbSBmb3Ig YmVpbmcgYWJsZSB0byBkaXN0cmlidXRlIHB1c2ggUHJveHlzIGFjcm9zcyBhIG5ldHdvcmsgd2hp Y2ggSSBiZWxpZXZlIGlzIHdoYXQgRGFsZSBpcyBhaW1pbmcgdG8gYWRkcmVzcyBpbiDigJxUcmFu Y2hlIDLigJ0gdXNpbmcg4oCcRmFyIFByb3h5c+KAnS4NCg0KSG93ZXZlciwgbGlrZSBSb21hbiBh bmQgQ2hyaXN0ZXIgSSBkb27igJl0IHNlZSBhIHVzZSBjYXNlIGZvciB0aGlzIHRoYXQgY2Fu4oCZ dCBiZSBhZGRyZXNzZWQgdXNpbmcgdGhlIGN1cnJlbnQgZHJhZnQuIEkgYWxzbyB0aGluayBpdCB3 aWxsIGJlIHF1aXRlIGNvbXBsZXggdG8gc3BlY2lmeSBhbmQgdGhhdCBpdCBzaG91bGQgbm90IGJl IGluY2x1ZGVkIGluIHRoZSBiYXNlIGRyYWZ0Lg0KDQpUaGFua3MsIE1pY2tleQ0KDQpGcm9tOiBz aXBjb3JlIFttYWlsdG86c2lwY29yZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUm9t YW4gU2hwb3VudA0KU2VudDogMjYgTWFyY2ggMjAxOCAxOToxNw0KVG86IEJyaWFuIFJvc2VuIDxi ckBicmlhbnJvc2VuLm5ldD4NCkNjOiBEYWxlIFIuIFdvcmxleSA8d29ybGV5QGFyaWFkbmUuY29t PjsgU0lQQ09SRSA8c2lwY29yZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbc2lwY29yZV0gT3Jn YW5pemluZyB0aGUgc2lwLXB1c2ggd29yaw0KDQpCcmlhbiwNCg0KSSBoYXZlIG1lbnRpb25lZCB0 aGlzIGJlZm9yZSB0byBEYWxlIC0tIEkgZG8gbm90IGtub3cgb2YgdGhlIHVzZSBjYXNlIGZvciBE YWxlJ3MgIiBUcmFuY2hlIDIiDQoNClJlZ2FyZHMsDQpfX19fX19fX19fX19fDQpSb21hbiBTaHBv dW50DQoNCk9uIE1vbiwgTWFyIDI2LCAyMDE4IGF0IDI6MTMgUE0sIEJyaWFuIFJvc2VuIDxickBi cmlhbnJvc2VuLm5ldDxtYWlsdG86YnJAYnJpYW5yb3Nlbi5uZXQ+PiB3cm90ZToNCk9rYXksIHRo YXTigJlzIGhlbHBmdWwgLSB0aGUgbmV3IGRyYWZ0IHdvdWxkIGFkZHJlc3MgYSByZWFsIGRlcGxv eW1lbnQgKGFsYmVpdCB5b3UgZGlkIHNvbWV0aGluZyBwcmUtc3RhbmRhcmRzKS4NCg0KQnV0IHlv dSBkb27igJl0IGtub3cgb2YgYW55dGhpbmcgdGhhdCB3b3VsZCBtYXRjaCB3aGF0IERhbGUgY2Fs bGVkIOKAnFRyYW5jaGUgMuKAnSwgcmVxdWlyaW5nIHRoZSBwbi1hb3IgYW5kIHdoYXQgQ2hyaXN0 ZXIgdGhpbmtzIGlzIGEgYnVuY2ggb2YgdGV4dCBjaGFuZ2VzPw0KDQpCcmlhbg0KDQpPbiBNYXIg MjYsIDIwMTgsIGF0IDI6MDAgUE0sIFJvbWFuIFNocG91bnQgPHJvbWFuQHRlbHVyaXguY29tPG1h aWx0bzpyb21hbkB0ZWx1cml4LmNvbT4+IHdyb3RlOg0KDQpCcmlhbiwNCg0KV2UgaGFkIGFuIGV4 aXN0aW5nIGltcGxlbWVudGF0aW9uIHdoaWNoIGhhdmUgY29tYmluZWQgUHVzaCBhbmQgT3V0Ym91 bmQgZm9yIGEgZmFpcmx5IGxhcmdlIG51bWJlciBvZiBtb2JpbGUgZW5kIHBvaW50cy4gU2luY2Ug bW9zdCBvZiB0aGUgbW9iaWxlIGNsaWVudHMgYXJlIGJlaGluZCBOQVQgYW5kIHJlcXVpcmUgU0lQ UywgU0lQIE91dGJvdW5kIGFuZCBQdXNoIGFyZSBjb21tb25seSBkZXBsb3llZCB0b2dldGhlci4g T3VyIGRlcGxveW1lbnQgd2FzIG5vdCBiYXNlZCBvbiB0aGUgY3VycmVudCBTSVAgUHVzaCBkcmFm dCwgYnV0IGl0IHdhcyBub3QgdGhlb3JldGljYWwuIFRoaXMgYmVpbmcgc2FpZCwgSSBhZ3JlZSB3 aXRoIENocmlzdGVyIHRoYXQgZGVmaW5pbmcgaG93IFNJUCBPdXRib3VuZCB3b3JrcyB3aXRoIFB1 c2ggYmVsb25ncyB0byBhIG5ldyBkcmFmdC4NCg0KUmVnYXJkcywNCg0KX19fX19fX19fX19fXw0K Um9tYW4gU2hwb3VudA0KDQpPbiBNb24sIE1hciAyNiwgMjAxOCBhdCA4OjU3IEFNLCBCcmlhbiBS b3NlbiA8YnJAYnJpYW5yb3Nlbi5uZXQ8bWFpbHRvOmJyQGJyaWFucm9zZW4ubmV0Pj4gd3JvdGU6 DQpUaGlzIGlzIGdldHRpbmcgY29tcGxpY2F0ZWQgZmFzdC4NCg0KQXJlIHRoZXJlIGFjdHVhbCB1 c2UgY2FzZXMgZm9yIHRyYW5jaGVzIDItNT8gIEkgdW5kZXJzdGFuZCB0aGUgYWN0dWFsIHVzZSBj YXNlIGZvciB3aGF0IENocmlzdGVy4oCZcyBkcmFmdCBkb2VzLiAgSSBraW5kIG9mIGdldCB0aGUg bmVlZCBmb3IgaW50ZXJhY3Rpb24gYmV0d2VlbiBQVVNIIGFuZCBPdXRib3VuZCwgYWx0aG91Z2gg aXTigJlzIG5vdCBjbGVhciB0byBtZSB0aGF0IHRoZXJlIGlzIGFuIGV4aXN0aW5nIG9yIHBsYW5u ZWQgaW1wbGVtZW50YXRpb24gdGhhdCBuZWVkcyBpdC4gTW9yZSBvZiBhIHRoZW9yZXRpYyBwcm9i bGVtLg0KDQpMZXTigJlzIGxvb2sgbW9yZSBjbG9zZWx5IGF0IFRyYW5jaCAyOiB3aHkgZG9lcyB0 aGlzIGNhc2UgZXhpc3Q/ICBXaHkgaXMgdGhlIHByb3h5IGNoYW5naW5nIGl04oCZcyBhZGRyZXNz IGFuZCBub3QgcmUtcmVnaXN0ZXJpbmc/ICAgQXJlIHlvdSBhd2FyZSBvZiBpbXBsZW1lbnRhdGlv bnMgdGhhdCBkbyB0aGlzLCBuZWVkIFBVU0ggYW5kIHdvdWxkbuKAmXQgd29yayB3aXRoIHRoZSBl eGlzdGluZyB0ZXh0Pw0KDQpDaGFpcnMgd291bGQgbGlrZSB0aGlzIGRyYWZ0IHRvIGZpbmlzaCBz aG9ydGx5LiAgVGhlcmUgc2VlbXMgdG8gYmUgYSBkaXNjb25uZWN0IGJldHdlZW4geW91IGFuZCB0 aGUgZ3V5IHdyaXRpbmcgdGhlIHRleHQgb24gaG93IG5lY2Vzc2FyeSBhbmQgY29tcGxpY2F0ZWQg aXQgaXMgdG8gc3VwcG9ydCDigJxmYXLigJ0gcHJveGllcy4gIFdl4oCZcmUgb2theSB3aXRoIGEg Zm9sbG93IHVwIGRyYWZ0IGRlYWxpbmcgd2l0aCBpbnRlcmFjdGlvbnMgYmV0d2VlbiBQVVNIIGFu ZCBPdXRib3VuZCwgYnV0IHdoYXQgZG8gd2UgcmVhbGx5IG5lZWQgdG8gZG8gdG8gZ2V0IHRoaXMg ZHJhZnQgb3V0IHRoZSBkb29yIGFuZCB1c2VmdWwgdG8gaW1wbGVtZW50b3JzPw0KDQpCcmlhbg0K DQo+IE9uIE1hciAyNSwgMjAxOCwgYXQgNTowMSBQTSwgRGFsZSBSLiBXb3JsZXkgPHdvcmxleUBh cmlhZG5lLmNvbTxtYWlsdG86d29ybGV5QGFyaWFkbmUuY29tPj4gd3JvdGU6DQo+DQo+IENhc3Rp bmcgdXAgYWNjb3VudHMgZnJvbSB0aGUgcmVjZW50IGRpc2N1c3Npb25zLCBpdCBzZWVtcyB0byBt ZSB0aGF0IHRoZQ0KPiB2YXJpb3VzIG1lY2hhbmlzbXMgY2FuIGJlIGRpdmlkZWQgaW50byBubyBs ZXNzIHRoYW4gKmZpdmUqIHRyYW5jaGVzLCBhcw0KPiBkaWFncmFtbWVkIGJlbG93Lg0KPg0KPiBJ IHJlY29tbWVuZCB0aGF0IHdlIGNhcnJ5IGZvcndhcmQgdHJhbmNoZXMgMSBhbmQgMiBpbg0KPiBk cmFmdC1pZXRmLXNpcGNvcmUtc2lwLXB1c2gsIGFuZCB0cmFuY2hlcyAzLCA0LCBhbmQgNSBpbiBh bm90aGVyIGRyYWZ0LA0KPiBvcmllbnRlZCB0b3dhcmQgInN1cHBvcnRpbmcgU0lQIE91dGJvdW5k IHdpdGggU0lQIFB1c2giLg0KPg0KPiBJIHBhcnRpY3VsYXJseSBkZXNpcmUgdG8gaW5jb3Jwb3Jh dGUgdHJhbmNoZSAyICh0aGUgInBuLWFvciIgcGFyYW1ldGVyLA0KPiBhbmQgYWxsb3dpbmcgY2Vy dGFpbiBhbHRlcm5hdGl2ZSBiZWhhdmlvcnMgYnkgaW1wbGVtZW50aW5nIHByb3hpZXMpIGludG8N Cj4gdGhlIGN1cnJlbnQgZHJhZnQsIGJlY2F1c2U6DQo+IDEpIEl0IGlzIGEgc21hbGwgZXh0ZW5z aW9uIG9mIC0wOCwgd2hlcmUgdGhlIFVBcyBhZGQgb25lIGZ1cnRoZXIgVVJJDQo+IHBhcmFtZXRl ci4NCj4gMikgSXQgaXMgdXB3YXJkLWNvbXBhdGlibGUgZnJvbSBpbXBsZW1lbnRhdGlvbnMgb2Yg LTA4Lg0KPiAzKSBJdCBhbGxvd3MgaW1wbGVtZW50YXRpb24gYnkgImZhciIgcHJveGllcywgaW5j bHVkaW5nIGVkZ2UgcHJveGllcywNCj4gYW5kIHN1cHBvcnRzIFVBcyBhY3F1aXJpbmcgZGlmZmVy ZW50IGFkZHJlc3NlcyB3aGVuIHRoZXkgYXdha2VuLg0KPiA0KSBUaGUgc3VwcG9ydCBmb3IgImZh ciIgcHJveGllcyBlc3RhYmxpc2hlcyBhbiBhcmNoaXRlY3R1cmFsDQo+IHJlcXVpcmVtZW50IHRo YXQgdGhlIHBuLSogcGFyYW1ldGVycyBtdXN0IGJlIFVSSSBwYXJhbWV0ZXJzICh3aGljaCB3b3Vs ZA0KPiBvdGhlcndpc2UgYmUgYSBwb29yIGFyY2hpdGVjdHVyYWwgY2hvaWNlKS4NCj4NCj4NCj4g dHJhbmNoZSAxICAgICBhcyBpbiBkcmFmdC1pZXRmLXNpcGNvcmUtc2lwLXB1c2gtMDgNCj4gICAg ICAgICAgICAgICBpbXBsZW1lbnRlZCBieTogaW1wbGVtZW50aW5nIHByb3hpZXMsIFVBcyBzdXBw b3J0aW5nIFNJUCBQdXNoDQo+ICAgICAgICAgICAgICAgZW5hYmxlczogY3VycmVudCBpbXBsZW1l bnRhdGlvbnMsICJuZWFyIiBwcm94aWVzLA0KPiAgICAgICAgICAgICAgICAgICAgICAgbm8gcmVx dWlyZW1lbnQgZm9yIG5vbi1zdGQuIGNvbW11bmljYXRpb24gd2l0aCByZWdpc3RyYXINCj4gICB8 DQo+ICAgfCB1cHdhcmQgY29tcGF0aWJsZSB3aXRoDQo+ICAgfA0KPiAgIHYNCj4gdHJhbmNoZSAy ICAgICBwbHVzOiBwbi1hb3IgcGFyYW1ldGVyDQo+ICAgICAgICAgICAgICAgaW1wbGVtZW50ZWQg Ynk6IFVBcyBzdXBwb3J0aW5nIFNJUCBQdXNoLCBvcHRpb25hbGx5IGJ5DQo+ICAgICAgICAgICAg ICAgICAgICAgICBpbXBsZW1lbnRpbmcgcHJveGllcw0KPiAgICAgICAgICAgICAgIGVuYWJsZXM6 ICJmYXIiIHByb3hpZXMsIGltcGxlbWVudGF0aW9uIGJ5IGVkZ2UgcHJveGllcywNCj4gICAgICAg ICAgICAgICAgICAgICAgIGNoYW5naW5nIFVBIGFkZHJlc3NlcyAoTkFUIHRyYXZlcnNhbCkNCj4g ICB8DQo+ICAgfCB1cHdhcmQgY29tcGF0aWJsZSB3aXRoDQo+ICAgfA0KPiAgIHYNCj4gdHJhbmNo ZSAzICAgICBwbHVzOiBwbi1yZWctaWQgcGFyYW1ldGVyDQo+ICAgICAgICAgICAgICAgaW1wbGVt ZW50ZWQgYnk6IFVBcyBzdXBwb3J0aW5nIFNJUCBQdXNoIHdpdGggU0lQIE91dGJvdW5kLA0KPiAg ICAgICAgICAgICAgICAgICAgICAgaW1wbGVtZW50aW5nIHByb3hpZXMgc3VwcG9ydGluZyBTSVAg T3V0Ym91bmQNCj4gICAgICAgICAgICAgICBlbmFibGVzOiBTSVAgUHVzaCBjb21iaW5lZCB3aXRo IFNJUCBPdXRib3VuZA0KPiAgIHwNCj4gICB8IHVwd2FyZCBjb21wYXRpYmxlIHdpdGgNCj4gICB8 DQo+ICAgdg0KPiB0cmFuY2hlIDQgICAgIHBsdXM6ICdyZWcnIGV2ZW50IHBhY2thZ2UgZXh0ZW5z aW9uICdwYXRoJyBlbGVtZW50IHRvIHJlcG9ydA0KPiAgICAgICAgICAgICAgICAgICAgICAgdGhl IFBhdGggaGVhZGVyDQo+ICAgICAgICAgICAgICAgaW1wbGVtZW50ZWQgYnk6IHJlZ2lzdHJhcnMs IG9wdGlvbmFsbHkgYnkgcHJveGllcw0KPiAgICAgICAgICAgICAgIGVuYWJsZXM6IFNJUCBQdXNo IGNvbWJpbmVkIHdpdGggU0lQIE91dGJvdW5kIHdpdGhvdXQgaGF2aW5nDQo+ICAgICAgICAgICAg ICAgICAgICAgICB0byB3YXRjaCBmb3IgcmUtUkVHSVNURVIgb3IgcmUtZGlzcGF0Y2ggdG8gdGhl IEFPUg0KPg0KPg0KPiAgIHwNCj4gICB8IGluZGVwZW5kZW50bHkgdXB3YXJkIGNvbXBhdGlibGUg ZnJvbSB0cmFuY2hlIDENCj4gICB8DQo+ICAgdg0KPiB0cmFuY2hlIDUgICAgIHBsdXM6ICdyZWcn IGV2ZW50IHBhY2thZ2UgZXh0ZW5zaW9uICdsYXN0LXJlZycgd2hpY2ggaXMgdGhlDQo+ICAgICAg ICAgICAgICAgICAgICAgICBudW1iZXIgb2Ygc2Vjb25kcyBzaW5jZSB0aGUgY29udGFjdCB3YXMg bGFzdCB1cGRhdGVkDQo+ICAgICAgICAgICAgICAgaW1wbGVtZW50ZWQgYnk6IHJlZ2lzdHJhcnMs IG9wdGlvbmFsbHkgYnkgcHJveGllcw0KPiAgICAgICAgICAgICAgIGVuYWJsZXM6IGltcGxlbWVu dGluZyBwcm94aWVzIGRvIG5vdCBuZWVkIHRvIHNlbmQgUE4gaWYNCj4gICAgICAgICAgICAgICAg ICAgICAgIHRoZSBVQSBoYXMgcmVjZW50bHkgcmVyZWdpc3RlcmVkDQo+DQo+IERhbGUNCj4NCj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gc2lwY29y ZSBtYWlsaW5nIGxpc3QNCj4gc2lwY29yZUBpZXRmLm9yZzxtYWlsdG86c2lwY29yZUBpZXRmLm9y Zz4NCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzaXBjb3JlIG1h aWxpbmcgbGlzdA0Kc2lwY29yZUBpZXRmLm9yZzxtYWlsdG86c2lwY29yZUBpZXRmLm9yZz4NCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZQ0KDQoNCg0K --_000_CY1PR02MB12627138F1DE5EB4E5D735D6E9AC0CY1PR02MB1262namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uaG9lbnpiDQoJe21z by1zdHlsZS1uYW1lOmhvZW56Yjt9DQpzcGFuLm0tNzM1MDYwMTIxODM5MjAxODE1NWhvZW56Yg0K CXttc28tc3R5bGUtbmFtZTptXy03MzUwNjAxMjE4MzkyMDE4MTU1aG9lbnpiO30NCnNwYW4uRW1h aWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1 bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcy LjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5Ccmlhbiw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ SnVzdCB0byBhZGQgbXkgdGhvdWdodHMgb24gdGhpcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SSBjYW4gc2VlIGEg Y29uY2VwdHVhbCBiZW5lZml0IHRvIGhhdmluZyBzb21lIHNvcnQgb2YgbWVjaGFuaXNtIGZvciBi ZWluZyBhYmxlIHRvIGRpc3RyaWJ1dGUgcHVzaCBQcm94eXMgYWNyb3NzIGEgbmV0d29yayB3aGlj aCBJIGJlbGlldmUgaXMgd2hhdA0KIERhbGUgaXMgYWltaW5nIHRvIGFkZHJlc3MgaW4g4oCcVHJh bmNoZSAy4oCdIHVzaW5nIOKAnEZhciBQcm94eXPigJ0uPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkhvd2V2ZXIsIGxp a2UgUm9tYW4gYW5kIENocmlzdGVyIEkgZG9u4oCZdCBzZWUgYSB1c2UgY2FzZSBmb3IgdGhpcyB0 aGF0IGNhbuKAmXQgYmUgYWRkcmVzc2VkIHVzaW5nIHRoZSBjdXJyZW50IGRyYWZ0LiBJIGFsc28g dGhpbmsgaXQgd2lsbCBiZSBxdWl0ZSBjb21wbGV4DQogdG8gc3BlY2lmeSBhbmQgdGhhdCBpdCBz aG91bGQgbm90IGJlIGluY2x1ZGVkIGluIHRoZSBiYXNlIGRyYWZ0LjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaGFu a3MsIE1pY2tleTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PiBzaXBjb3JlIFttYWlsdG86c2lwY29yZS1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxm IE9mIDwvYj5Sb21hbiBTaHBvdW50PGJyPg0KPGI+U2VudDo8L2I+IDI2IE1hcmNoIDIwMTggMTk6 MTc8YnI+DQo8Yj5Ubzo8L2I+IEJyaWFuIFJvc2VuICZsdDtickBicmlhbnJvc2VuLm5ldCZndDs8 YnI+DQo8Yj5DYzo8L2I+IERhbGUgUi4gV29ybGV5ICZsdDt3b3JsZXlAYXJpYWRuZS5jb20mZ3Q7 OyBTSVBDT1JFICZsdDtzaXBjb3JlQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBS ZTogW3NpcGNvcmVdIE9yZ2FuaXppbmcgdGhlIHNpcC1wdXNoIHdvcms8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ccmlhbiw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkkgaGF2ZSBtZW50aW9uZWQgdGhpcyBiZWZvcmUgdG8gRGFsZSAt LSBJIGRvIG5vdCBrbm93IG9mIHRoZSB1c2UgY2FzZSBmb3IgRGFsZSdzJm5ic3A7JnF1b3Q7DQo8 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2s7YmFja2dyb3VuZDp3aGl0ZSI+DQpUcmFuY2hlIDImcXVv dDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Y29sb3I6YmxhY2siPlJlZ2FyZHMs PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+X19fX19fX19fX19fXzxicj4NClJvbWFuIFNocG91bnQ8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIE1hciAyNiwgMjAxOCBhdCAy OjEzIFBNLCBCcmlhbiBSb3NlbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJyQGJyaWFucm9zZW4ubmV0 IiB0YXJnZXQ9Il9ibGFuayI+YnJAYnJpYW5yb3Nlbi5uZXQ8L2E+Jmd0OyB3cm90ZTo8bzpwPjwv bzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44 cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T2theSwg dGhhdOKAmXMgaGVscGZ1bCAtIHRoZSBuZXcgZHJhZnQgd291bGQgYWRkcmVzcyBhIHJlYWwgZGVw bG95bWVudCAoYWxiZWl0IHlvdSBkaWQgc29tZXRoaW5nIHByZS1zdGFuZGFyZHMpLiAmbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJ1dCB5b3UgZG9u 4oCZdCBrbm93IG9mIGFueXRoaW5nIHRoYXQgd291bGQgbWF0Y2ggd2hhdCBEYWxlIGNhbGxlZCDi gJxUcmFuY2hlIDLigJ0sIHJlcXVpcmluZyB0aGUgcG4tYW9yIGFuZCB3aGF0IENocmlzdGVyIHRo aW5rcyBpcyBhIGJ1bmNoIG9mIHRleHQgY2hhbmdlcz88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+QnJpYW48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk9uIE1hciAyNiwgMjAxOCwgYXQgMjowMCBQTSwgUm9tYW4gU2hwb3VudCAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnJvbWFuQHRlbHVyaXguY29tIiB0YXJnZXQ9Il9ibGFuayI+cm9tYW5AdGVsdXJp eC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkJyaWFuLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+V2UgaGFkIGFuIGV4aXN0aW5nIGltcGxlbWVudGF0aW9uIHdoaWNoIGhhdmUgY29tYmlu ZWQgUHVzaCBhbmQgT3V0Ym91bmQgZm9yIGEgZmFpcmx5IGxhcmdlIG51bWJlciBvZiBtb2JpbGUg ZW5kIHBvaW50cy4gU2luY2UgbW9zdCBvZiB0aGUgbW9iaWxlIGNsaWVudHMgYXJlIGJlaGluZCBO QVQgYW5kIHJlcXVpcmUgU0lQUywgU0lQIE91dGJvdW5kIGFuZCBQdXNoIGFyZSBjb21tb25seSBk ZXBsb3llZCB0b2dldGhlci4NCiBPdXIgZGVwbG95bWVudCB3YXMgbm90IGJhc2VkIG9uIHRoZSBj dXJyZW50IFNJUCBQdXNoIGRyYWZ0LCBidXQgaXQgd2FzIG5vdCB0aGVvcmV0aWNhbC4gVGhpcyBi ZWluZyBzYWlkLCBJIGFncmVlIHdpdGggQ2hyaXN0ZXIgdGhhdCBkZWZpbmluZyBob3cgU0lQIE91 dGJvdW5kIHdvcmtzIHdpdGggUHVzaCBiZWxvbmdzIHRvIGEgbmV3IGRyYWZ0LjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRzLDxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+X19fX19fX19fX19fXzxicj4NClJvbWFuIFNocG91bnQ8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIE1hciAyNiwgMjAxOCBh dCA4OjU3IEFNLCBCcmlhbiBSb3NlbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJyQGJyaWFucm9zZW4u bmV0IiB0YXJnZXQ9Il9ibGFuayI+YnJAYnJpYW5yb3Nlbi5uZXQ8L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6 NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGlzIGdl dHRpbmcgY29tcGxpY2F0ZWQgZmFzdC48YnI+DQo8YnI+DQpBcmUgdGhlcmUgYWN0dWFsIHVzZSBj YXNlcyBmb3IgdHJhbmNoZXMgMi01PyZuYnNwOyBJIHVuZGVyc3RhbmQgdGhlIGFjdHVhbCB1c2Ug Y2FzZSBmb3Igd2hhdCBDaHJpc3RlcuKAmXMgZHJhZnQgZG9lcy4mbmJzcDsgSSBraW5kIG9mIGdl dCB0aGUgbmVlZCBmb3IgaW50ZXJhY3Rpb24gYmV0d2VlbiBQVVNIIGFuZCBPdXRib3VuZCwgYWx0 aG91Z2ggaXTigJlzIG5vdCBjbGVhciB0byBtZSB0aGF0IHRoZXJlIGlzIGFuIGV4aXN0aW5nIG9y IHBsYW5uZWQgaW1wbGVtZW50YXRpb24NCiB0aGF0IG5lZWRzIGl0LiBNb3JlIG9mIGEgdGhlb3Jl dGljIHByb2JsZW0uPGJyPg0KPGJyPg0KTGV04oCZcyBsb29rIG1vcmUgY2xvc2VseSBhdCBUcmFu Y2ggMjogd2h5IGRvZXMgdGhpcyBjYXNlIGV4aXN0PyZuYnNwOyBXaHkgaXMgdGhlIHByb3h5IGNo YW5naW5nIGl04oCZcyBhZGRyZXNzIGFuZCBub3QgcmUtcmVnaXN0ZXJpbmc/Jm5ic3A7ICZuYnNw O0FyZSB5b3UgYXdhcmUgb2YgaW1wbGVtZW50YXRpb25zIHRoYXQgZG8gdGhpcywgbmVlZCBQVVNI IGFuZCB3b3VsZG7igJl0IHdvcmsgd2l0aCB0aGUgZXhpc3RpbmcgdGV4dD88YnI+DQo8YnI+DQpD aGFpcnMgd291bGQgbGlrZSB0aGlzIGRyYWZ0IHRvIGZpbmlzaCBzaG9ydGx5LiZuYnNwOyBUaGVy ZSBzZWVtcyB0byBiZSBhIGRpc2Nvbm5lY3QgYmV0d2VlbiB5b3UgYW5kIHRoZSBndXkgd3JpdGlu ZyB0aGUgdGV4dCBvbiBob3cgbmVjZXNzYXJ5IGFuZCBjb21wbGljYXRlZCBpdCBpcyB0byBzdXBw b3J0IOKAnGZhcuKAnSBwcm94aWVzLiZuYnNwOyBXZeKAmXJlIG9rYXkgd2l0aCBhIGZvbGxvdyB1 cCBkcmFmdCBkZWFsaW5nIHdpdGggaW50ZXJhY3Rpb25zIGJldHdlZW4gUFVTSA0KIGFuZCBPdXRi b3VuZCwgYnV0IHdoYXQgZG8gd2UgcmVhbGx5IG5lZWQgdG8gZG8gdG8gZ2V0IHRoaXMgZHJhZnQg b3V0IHRoZSBkb29yIGFuZCB1c2VmdWwgdG8gaW1wbGVtZW50b3JzPzxicj4NCjxzcGFuIHN0eWxl PSJjb2xvcjojODg4ODg4Ij48YnI+DQo8c3BhbiBjbGFzcz0ibS03MzUwNjAxMjE4MzkyMDE4MTU1 aG9lbnpiIj5Ccmlhbjwvc3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCiZndDsgT24gTWFyIDI1LCAyMDE4LCBhdCA1OjAx IFBNLCBEYWxlIFIuIFdvcmxleSAmbHQ7PGEgaHJlZj0ibWFpbHRvOndvcmxleUBhcmlhZG5lLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPndvcmxleUBhcmlhZG5lLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4N CiZndDs8YnI+DQomZ3Q7IENhc3RpbmcgdXAgYWNjb3VudHMgZnJvbSB0aGUgcmVjZW50IGRpc2N1 c3Npb25zLCBpdCBzZWVtcyB0byBtZSB0aGF0IHRoZTxicj4NCiZndDsgdmFyaW91cyBtZWNoYW5p c21zIGNhbiBiZSBkaXZpZGVkIGludG8gbm8gbGVzcyB0aGFuICpmaXZlKiB0cmFuY2hlcywgYXM8 YnI+DQomZ3Q7IGRpYWdyYW1tZWQgYmVsb3cuPGJyPg0KJmd0Ozxicj4NCiZndDsgSSByZWNvbW1l bmQgdGhhdCB3ZSBjYXJyeSBmb3J3YXJkIHRyYW5jaGVzIDEgYW5kIDIgaW48YnI+DQomZ3Q7IGRy YWZ0LWlldGYtc2lwY29yZS1zaXAtcHVzaCwgYW5kIHRyYW5jaGVzIDMsIDQsIGFuZCA1IGluIGFu b3RoZXIgZHJhZnQsPGJyPg0KJmd0OyBvcmllbnRlZCB0b3dhcmQgJnF1b3Q7c3VwcG9ydGluZyBT SVAgT3V0Ym91bmQgd2l0aCBTSVAgUHVzaCZxdW90Oy48YnI+DQomZ3Q7PGJyPg0KJmd0OyBJIHBh cnRpY3VsYXJseSBkZXNpcmUgdG8gaW5jb3Jwb3JhdGUgdHJhbmNoZSAyICh0aGUgJnF1b3Q7cG4t YW9yJnF1b3Q7IHBhcmFtZXRlciw8YnI+DQomZ3Q7IGFuZCBhbGxvd2luZyBjZXJ0YWluIGFsdGVy bmF0aXZlIGJlaGF2aW9ycyBieSBpbXBsZW1lbnRpbmcgcHJveGllcykgaW50bzxicj4NCiZndDsg dGhlIGN1cnJlbnQgZHJhZnQsIGJlY2F1c2U6PGJyPg0KJmd0OyAxKSBJdCBpcyBhIHNtYWxsIGV4 dGVuc2lvbiBvZiAtMDgsIHdoZXJlIHRoZSBVQXMgYWRkIG9uZSBmdXJ0aGVyIFVSSTxicj4NCiZn dDsgcGFyYW1ldGVyLjxicj4NCiZndDsgMikgSXQgaXMgdXB3YXJkLWNvbXBhdGlibGUgZnJvbSBp bXBsZW1lbnRhdGlvbnMgb2YgLTA4Ljxicj4NCiZndDsgMykgSXQgYWxsb3dzIGltcGxlbWVudGF0 aW9uIGJ5ICZxdW90O2ZhciZxdW90OyBwcm94aWVzLCBpbmNsdWRpbmcgZWRnZSBwcm94aWVzLDxi cj4NCiZndDsgYW5kIHN1cHBvcnRzIFVBcyBhY3F1aXJpbmcgZGlmZmVyZW50IGFkZHJlc3NlcyB3 aGVuIHRoZXkgYXdha2VuLjxicj4NCiZndDsgNCkgVGhlIHN1cHBvcnQgZm9yICZxdW90O2ZhciZx dW90OyBwcm94aWVzIGVzdGFibGlzaGVzIGFuIGFyY2hpdGVjdHVyYWw8YnI+DQomZ3Q7IHJlcXVp cmVtZW50IHRoYXQgdGhlIHBuLSogcGFyYW1ldGVycyBtdXN0IGJlIFVSSSBwYXJhbWV0ZXJzICh3 aGljaCB3b3VsZDxicj4NCiZndDsgb3RoZXJ3aXNlIGJlIGEgcG9vciBhcmNoaXRlY3R1cmFsIGNo b2ljZSkuPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IHRyYW5jaGUgMSZuYnNwOyAmbmJz cDsgJm5ic3A7YXMgaW4gZHJhZnQtaWV0Zi1zaXBjb3JlLXNpcC1wdXNoLTA4PGJyPg0KJmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtpbXBs ZW1lbnRlZCBieTogaW1wbGVtZW50aW5nIHByb3hpZXMsIFVBcyBzdXBwb3J0aW5nIFNJUCBQdXNo PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDtlbmFibGVzOiBjdXJyZW50IGltcGxlbWVudGF0aW9ucywgJnF1b3Q7bmVhciZxdW90 OyBwcm94aWVzLDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO25vIHJlcXVpcmVt ZW50IGZvciBub24tc3RkLiBjb21tdW5pY2F0aW9uIHdpdGggcmVnaXN0cmFyPGJyPg0KJmd0OyZu YnNwOyAmbmJzcDt8PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDt8IHVwd2FyZCBjb21wYXRpYmxlIHdp dGg8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwO3w8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwO3Y8YnI+DQom Z3Q7IHRyYW5jaGUgMiZuYnNwOyAmbmJzcDsgJm5ic3A7cGx1czogcG4tYW9yIHBhcmFtZXRlcjxi cj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7aW1wbGVtZW50ZWQgYnk6IFVBcyBzdXBwb3J0aW5nIFNJUCBQdXNoLCBvcHRpb25hbGx5 IGJ5PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7aW1wbGVtZW50aW5nIHByb3hp ZXM8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO2VuYWJsZXM6ICZxdW90O2ZhciZxdW90OyBwcm94aWVzLCBpbXBsZW1lbnRhdGlv biBieSBlZGdlIHByb3hpZXMsPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Y2hh bmdpbmcgVUEgYWRkcmVzc2VzIChOQVQgdHJhdmVyc2FsKTxicj4NCiZndDsmbmJzcDsgJm5ic3A7 fDxicj4NCiZndDsmbmJzcDsgJm5ic3A7fCB1cHdhcmQgY29tcGF0aWJsZSB3aXRoPGJyPg0KJmd0 OyZuYnNwOyAmbmJzcDt8PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDt2PGJyPg0KJmd0OyB0cmFuY2hl IDMmbmJzcDsgJm5ic3A7ICZuYnNwO3BsdXM6IHBuLXJlZy1pZCBwYXJhbWV0ZXI8YnI+DQomZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2lt cGxlbWVudGVkIGJ5OiBVQXMgc3VwcG9ydGluZyBTSVAgUHVzaCB3aXRoIFNJUCBPdXRib3VuZCw8 YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtpbXBsZW1lbnRpbmcgcHJveGllcyBz dXBwb3J0aW5nIFNJUCBPdXRib3VuZDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZW5hYmxlczogU0lQIFB1c2ggY29tYmluZWQg d2l0aCBTSVAgT3V0Ym91bmQ8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwO3w8YnI+DQomZ3Q7Jm5ic3A7 ICZuYnNwO3wgdXB3YXJkIGNvbXBhdGlibGUgd2l0aDxicj4NCiZndDsmbmJzcDsgJm5ic3A7fDxi cj4NCiZndDsmbmJzcDsgJm5ic3A7djxicj4NCiZndDsgdHJhbmNoZSA0Jm5ic3A7ICZuYnNwOyAm bmJzcDtwbHVzOiAncmVnJyBldmVudCBwYWNrYWdlIGV4dGVuc2lvbiAncGF0aCcgZWxlbWVudCB0 byByZXBvcnQ8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt0aGUgUGF0aCBoZWFk ZXI8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO2ltcGxlbWVudGVkIGJ5OiByZWdpc3RyYXJzLCBvcHRpb25hbGx5IGJ5IHByb3hp ZXM8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO2VuYWJsZXM6IFNJUCBQdXNoIGNvbWJpbmVkIHdpdGggU0lQIE91dGJvdW5kIHdp dGhvdXQgaGF2aW5nPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7dG8gd2F0Y2gg Zm9yIHJlLVJFR0lTVEVSIG9yIHJlLWRpc3BhdGNoIHRvIHRoZSBBT1I8YnI+DQomZ3Q7PGJyPg0K Jmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7fDxicj4NCiZndDsmbmJzcDsgJm5ic3A7fCBpbmRl cGVuZGVudGx5IHVwd2FyZCBjb21wYXRpYmxlIGZyb20gdHJhbmNoZSAxPGJyPg0KJmd0OyZuYnNw OyAmbmJzcDt8PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDt2PGJyPg0KJmd0OyB0cmFuY2hlIDUmbmJz cDsgJm5ic3A7ICZuYnNwO3BsdXM6ICdyZWcnIGV2ZW50IHBhY2thZ2UgZXh0ZW5zaW9uICdsYXN0 LXJlZycgd2hpY2ggaXMgdGhlPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7bnVt YmVyIG9mIHNlY29uZHMgc2luY2UgdGhlIGNvbnRhY3Qgd2FzIGxhc3QgdXBkYXRlZDxicj4NCiZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 aW1wbGVtZW50ZWQgYnk6IHJlZ2lzdHJhcnMsIG9wdGlvbmFsbHkgYnkgcHJveGllczxicj4NCiZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ZW5hYmxlczogaW1wbGVtZW50aW5nIHByb3hpZXMgZG8gbm90IG5lZWQgdG8gc2VuZCBQTiBpZjxi cj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3RoZSBVQSBoYXMgcmVjZW50bHkgcmVy ZWdpc3RlcmVkPGJyPg0KJmd0Ozxicj4NCiZndDsgRGFsZTxicj4NCiZndDs8YnI+DQomZ3Q7IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBz aXBjb3JlIG1haWxpbmcgbGlzdDxicj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOnNpcGNvcmVAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zaXBjb3JlQGlldGYub3JnPC9hPjxicj4NCiZndDsgPGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlIiB0YXJn ZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3Jl PC9hPjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPg0Kc2lwY29yZSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86c2lw Y29yZUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNpcGNvcmVAaWV0Zi5vcmc8L2E+PGJyPg0K PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlIiB0 YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBj b3JlPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CY1PR02MB12627138F1DE5EB4E5D735D6E9AC0CY1PR02MB1262namp_-- From nobody Tue Mar 27 06:27:14 2018 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 02C8212DA14 for ; Tue, 27 Mar 2018 06:27:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 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, URIBL_BLOCKED=0.001] 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 xVG5eXO1emwo for ; Tue, 27 Mar 2018 06:27:01 -0700 (PDT) Received: from mail-yb0-x22e.google.com (mail-yb0-x22e.google.com [IPv6:2607:f8b0:4002:c09::22e]) (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 B69901273B1 for ; Tue, 27 Mar 2018 06:27:00 -0700 (PDT) Received: by mail-yb0-x22e.google.com with SMTP id e3-v6so7617716ybk.1 for ; Tue, 27 Mar 2018 06:27:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=BkThnZWWr8pPj/rkp/F3z2pDfvcDBAKkg9U4+eYejBg=; b=PS//u62PPRr8W3xr6z1eWa0Jv4gIyl08k2Ysh87sOXCrMKJai8PKXGcCtM+sWQrCRu Z0tD9yZ1J7aFD3zm2QGvpu4sca/ZlvXqBzIpSAxEJPYSUrfv68otqoiu/eW36HDoc9ry WnJwSBQ2niqEoshuDpNfsWv4H7pT28zsO5ZZ/oRnbsoscdXyU8qfqBNDC3Rrw/PjVrPg /zUsZYrLpgznQ3YOMZYvlrBODRrrY0BuBX/KUOhldZxmbopFJ2N6tw4Yh6l5xRD2MsnE /II7U8z3PHqPtSXYiDLumYIB7I69UEj/Pds8e0QfRC6ntOCJnIPn+0z66ZJ56MSZWyoO yqVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=BkThnZWWr8pPj/rkp/F3z2pDfvcDBAKkg9U4+eYejBg=; b=NL3K0r4r27L0v85z3gz0RQI3H1Q9GGEvtejP9ZQw8N18avxxQ/73YgA0vnSXGzaZ5H Kb31aS8bGWRRIArtqgaMkscX24O9slV0y6+azwXCrvXyGmTZl1xZcEG7VWz1fobzWzqS yScJzgH8+0arXJJb1A6XuSlA45rcjQEkJLCYoP/FeaK6XjpTbJti8ggoYKp8t1N9Vta8 wps40mRUozeQJTiWUfYkJFdST+ZBFKBEDGt7B2wq7yUKkITH36ka0sq9iApBDcFiB6Kr ugINsigCHj88rd5AxoG6z7JgawP71Y2KslGqTtDLO7HuuE4qAHNh/8/yiIJNfrIAuxBC NBgA== X-Gm-Message-State: AElRT7EDDO+DQbihtN/zB1FDo9MA0s/ZXC09VYO8KnMN8/j14YC8BN6c 6uNcS9odQSlfdMrgDKonP/Y9zPx9beo= X-Google-Smtp-Source: AIpwx4+6IyfzTvlJ+B6o5aKVukY0m+B61a8o77m3ay6+XcS6ibf6RqjsgXDHVJtmmKbtKWXpj0EUpQ== X-Received: by 2002:a25:3844:: with SMTP id f65-v6mr4717410yba.357.1522157219694; Tue, 27 Mar 2018 06:26:59 -0700 (PDT) Received: from [10.96.40.72] (neustar-sthide-nat1.neustar.biz. [156.154.81.54]) by smtp.gmail.com with ESMTPSA id f203sm422355ywa.39.2018.03.27.06.26.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Mar 2018 06:26:58 -0700 (PDT) From: Brian Rosen Message-Id: <00002FE0-4756-4C0C-A6EB-C7A4D69871CE@brianrosen.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_D383E4E5-A2B7-4F2B-BE5C-72CF48D5333E" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 27 Mar 2018 09:26:56 -0400 In-Reply-To: Cc: Roman Shpount , "Dale R. Worley" , SIPCORE To: Mickey Arnold References: <87efk7uax2.fsf@hobgoblin.ariadne.com> <9BA4FCE3-7E5F-479E-828A-1658C93688B9@brianrosen.net> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [sipcore] Organizing the sip-push work 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, 27 Mar 2018 13:27:07 -0000 --Apple-Mail=_D383E4E5-A2B7-4F2B-BE5C-72CF48D5333E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks Mickey. Does anyone have an actual use case for =E2=80=9CTranche 2=E2=80=9D? If = not, I=E2=80=99m inclined to recommend that Christer proceed without it. I think there is more than sufficient interest in the interaction of = PUSH and Outbound, and we=E2=80=99ll make sure that is addressed in = another draft. I=E2=80=99d like to get this draft moving through = approval processes soon. If someone (Dale) wanted to contribute text to = that draft for Tranche 2, we would of course consider it. Brian > On Mar 27, 2018, at 6:18 AM, Mickey Arnold = wrote: >=20 > Brian, > =20 > Just to add my thoughts on this. > =20 > I can see a conceptual benefit to having some sort of mechanism for = being able to distribute push Proxys across a network which I believe is = what Dale is aiming to address in =E2=80=9CTranche 2=E2=80=9D using = =E2=80=9CFar Proxys=E2=80=9D. > =20 > However, like Roman and Christer I don=E2=80=99t see a use case for = this that can=E2=80=99t be addressed using the current draft. I also = think it will be quite complex to specify and that it should not be = included in the base draft. > =20 > Thanks, Mickey > =20 > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Roman = Shpount > Sent: 26 March 2018 19:17 > To: Brian Rosen > Cc: Dale R. Worley ; SIPCORE > Subject: Re: [sipcore] Organizing the sip-push work > =20 > Brian, > =20 > I have mentioned this before to Dale -- I do not know of the use case = for Dale's " Tranche 2" > =20 > Regards, > _____________ > Roman Shpount > =20 > On Mon, Mar 26, 2018 at 2:13 PM, Brian Rosen > wrote: > Okay, that=E2=80=99s helpful - the new draft would address a real = deployment (albeit you did something pre-standards). =20 > =20 > But you don=E2=80=99t know of anything that would match what Dale = called =E2=80=9CTranche 2=E2=80=9D, requiring the pn-aor and what = Christer thinks is a bunch of text changes? > =20 > Brian > =20 > On Mar 26, 2018, at 2:00 PM, Roman Shpount > wrote: > =20 > Brian, > =20 > We had an existing implementation which have combined Push and = Outbound for a fairly large number of mobile end points. Since most of = the mobile clients are behind NAT and require SIPS, SIP Outbound and = Push are commonly deployed together. Our deployment was not based on the = current SIP Push draft, but it was not theoretical. This being said, I = agree with Christer that defining how SIP Outbound works with Push = belongs to a new draft. > =20 > Regards, >=20 > _____________ > Roman Shpount > =20 > On Mon, Mar 26, 2018 at 8:57 AM, Brian Rosen > wrote: > This is getting complicated fast. >=20 > Are there actual use cases for tranches 2-5? I understand the actual = use case for what Christer=E2=80=99s draft does. I kind of get the need = for interaction between PUSH and Outbound, although it=E2=80=99s not = clear to me that there is an existing or planned implementation that = needs it. More of a theoretic problem. >=20 > Let=E2=80=99s look more closely at Tranch 2: why does this case exist? = Why is the proxy changing it=E2=80=99s address and not re-registering? = Are you aware of implementations that do this, need PUSH and wouldn=E2=80= =99t work with the existing text? >=20 > Chairs would like this draft to finish shortly. There seems to be a = disconnect between you and the guy writing the text on how necessary and = complicated it is to support =E2=80=9Cfar=E2=80=9D proxies. We=E2=80=99re= okay with a follow up draft dealing with interactions between PUSH and = Outbound, but what do we really need to do to get this draft out the = door and useful to implementors? >=20 > Brian >=20 > > On Mar 25, 2018, at 5:01 PM, Dale R. Worley > wrote: > > > > Casting up accounts from the recent discussions, it seems to me that = the > > various mechanisms can be divided into no less than *five* tranches, = as > > diagrammed below. > > > > I recommend that we carry forward tranches 1 and 2 in > > draft-ietf-sipcore-sip-push, and tranches 3, 4, and 5 in another = draft, > > oriented toward "supporting SIP Outbound with SIP Push". > > > > I particularly desire to incorporate tranche 2 (the "pn-aor" = parameter, > > and allowing certain alternative behaviors by implementing proxies) = into > > the current draft, because: > > 1) It is a small extension of -08, where the UAs add one further URI > > parameter. > > 2) It is upward-compatible from implementations of -08. > > 3) It allows implementation by "far" proxies, including edge = proxies, > > and supports UAs acquiring different addresses when they awaken. > > 4) The support for "far" proxies establishes an architectural > > requirement that the pn-* parameters must be URI parameters (which = would > > otherwise be a poor architectural choice). > > > > > > tranche 1 as in draft-ietf-sipcore-sip-push-08 > > implemented by: implementing proxies, UAs supporting = SIP Push > > enables: current implementations, "near" proxies, > > no requirement for non-std. communication with = registrar > > | > > | upward compatible with > > | > > v > > tranche 2 plus: pn-aor parameter > > implemented by: UAs supporting SIP Push, optionally by > > implementing proxies > > enables: "far" proxies, implementation by edge = proxies, > > changing UA addresses (NAT traversal) > > | > > | upward compatible with > > | > > v > > tranche 3 plus: pn-reg-id parameter > > implemented by: UAs supporting SIP Push with SIP = Outbound, > > implementing proxies supporting SIP Outbound > > enables: SIP Push combined with SIP Outbound > > | > > | upward compatible with > > | > > v > > tranche 4 plus: 'reg' event package extension 'path' element to = report > > the Path header > > implemented by: registrars, optionally by proxies > > enables: SIP Push combined with SIP Outbound without = having > > to watch for re-REGISTER or re-dispatch to the = AOR > > > > > > | > > | independently upward compatible from tranche 1 > > | > > v > > tranche 5 plus: 'reg' event package extension 'last-reg' which = is the > > number of seconds since the contact was last = updated > > implemented by: registrars, optionally by proxies > > enables: implementing proxies do not need to send PN = if > > the UA has recently reregistered > > > > Dale > > > > _______________________________________________ > > 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 > =20 --Apple-Mail=_D383E4E5-A2B7-4F2B-BE5C-72CF48D5333E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks Mickey.

Does anyone have an actual use case for =E2=80=9CTranche = 2=E2=80=9D?  If not, I=E2=80=99m inclined to recommend that = Christer proceed without it.

I think there is more than sufficient = interest in the interaction of PUSH and Outbound, and we=E2=80=99ll make = sure that is addressed in another draft.  I=E2=80=99d like to get = this draft moving through approval processes soon.  If someone = (Dale) wanted to contribute text to that draft for Tranche 2, we would = of course consider it.

Brian

On = Mar 27, 2018, at 6:18 AM, Mickey Arnold <Michael.Arnold@metaswitch.com> wrote:

Brian,

 

Just to add my thoughts on this.

 

I can see a conceptual benefit to = having some sort of mechanism for being able to distribute push Proxys = across a network which I believe is what Dale is aiming to address in =E2=80=9CTranche 2=E2=80=9D using =E2=80=9CF= ar Proxys=E2=80=9D.

 

However, like Roman and Christer I = don=E2=80=99t see a use case for this that can=E2=80=99t be addressed = using the current draft. I also think it will be quite complex to specify and that it should not be included in the base draft.

 

Thanks, Mickey

 

From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Roman Shpount
Sent: 26 March 2018 19:17
To: Brian Rosen <br@brianrosen.net>
Cc: Dale R. Worley <worley@ariadne.com>; = SIPCORE <sipcore@ietf.org>
Subject: Re: [sipcore] Organizing the sip-push = work

 

Brian,

 

I have mentioned this before to = Dale -- I do not know of the use case for Dale's " Tranche 2"

 

Regards,

_____________
Roman Shpount

 

On Mon, Mar 26, 2018 at 2:13 PM, = Brian Rosen <br@brianrosen.net> wrote:

Okay, that=E2=80=99s helpful - = the new draft would address a real deployment (albeit you did something = pre-standards).  

 

But you don=E2=80=99t know of = anything that would match what Dale called =E2=80=9CTranche 2=E2=80=9D, = requiring the pn-aor and what Christer thinks is a bunch of text = changes?

 

Brian

 

On Mar 26, 2018, at 2:00 PM, = Roman Shpount <roman@telurix.com> wrote:

 

Brian,

 

We had an existing implementation = which have combined Push and Outbound for a fairly large number of = mobile end points. Since most of the mobile clients are behind NAT and = require SIPS, SIP Outbound and Push are commonly deployed together. Our deployment was not based on the current SIP Push draft, but it was = not theoretical. This being said, I agree with Christer that defining = how SIP Outbound works with Push belongs to a new draft.

 

Regards,


_____________
Roman Shpount

 

On Mon, Mar 26, 2018 at 8:57 AM, = Brian Rosen <br@brianrosen.net> wrote:

This is getting complicated fast.

Are there actual use cases for tranches 2-5?  I understand the = actual use case for what Christer=E2=80=99s draft does.  I kind of = get the need for interaction between PUSH and Outbound, although it=E2=80=99= s not clear to me that there is an existing or planned implementation that needs it. More of a theoretic problem.

Let=E2=80=99s look more closely at Tranch 2: why does this case = exist?  Why is the proxy changing it=E2=80=99s address and not = re-registering?   Are you aware of implementations that do = this, need PUSH and wouldn=E2=80=99t work with the existing text?

Chairs would like this draft to finish shortly.  There seems to be = a disconnect between you and the guy writing the text on how necessary = and complicated it is to support =E2=80=9Cfar=E2=80=9D proxies.  = We=E2=80=99re okay with a follow up draft dealing with interactions = between PUSH and Outbound, but what do we really need to do to get this draft out = the door and useful to implementors?

Brian


> On Mar 25, 2018, at 5:01 PM, Dale R. Worley <worley@ariadne.com> wrote:
>
> Casting up accounts from the recent discussions, it seems to me = that the
> various mechanisms can be divided into no less than *five* = tranches, as
> diagrammed below.
>
> I recommend that we carry forward tranches 1 and 2 in
> draft-ietf-sipcore-sip-push, and tranches 3, 4, and 5 in another = draft,
> oriented toward "supporting SIP Outbound with SIP Push".
>
> I particularly desire to incorporate tranche 2 (the "pn-aor" = parameter,
> and allowing certain alternative behaviors by implementing proxies) = into
> the current draft, because:
> 1) It is a small extension of -08, where the UAs add one further = URI
> parameter.
> 2) It is upward-compatible from implementations of -08.
> 3) It allows implementation by "far" proxies, including edge = proxies,
> and supports UAs acquiring different addresses when they awaken.
> 4) The support for "far" proxies establishes an architectural
> requirement that the pn-* parameters must be URI parameters (which = would
> otherwise be a poor architectural choice).
>
>
> tranche 1     as in = draft-ietf-sipcore-sip-push-08
>               implemented = by: implementing proxies, UAs supporting SIP Push
>               enables: = current implementations, "near" proxies,
>                  =      no requirement for non-std. communication with = registrar
>   |
>   | upward compatible with
>   |
>   v
> tranche 2     plus: pn-aor parameter
>               implemented = by: UAs supporting SIP Push, optionally by
>                  =      implementing proxies
>               enables: = "far" proxies, implementation by edge proxies,
>                  =      changing UA addresses (NAT traversal)
>   |
>   | upward compatible with
>   |
>   v
> tranche 3     plus: pn-reg-id parameter
= >               implemented = by: UAs supporting SIP Push with SIP Outbound,
>                  =      implementing proxies supporting SIP Outbound
>               enables: SIP = Push combined with SIP Outbound
>   |
>   | upward compatible with
>   |
>   v
> tranche 4     plus: 'reg' event package extension = 'path' element to report
>                  =      the Path header
>               implemented = by: registrars, optionally by proxies
>               enables: SIP = Push combined with SIP Outbound without having
>                  =      to watch for re-REGISTER or re-dispatch to the = AOR
>
>
>   |
>   | independently upward compatible from tranche 1
>   |
>   v
> tranche 5     plus: 'reg' event package extension = 'last-reg' which is the
>                  =      number of seconds since the contact was last = updated
>               implemented = by: registrars, optionally by proxies
>               enables: = implementing proxies do not need to send PN if
>                  =      the UA has recently reregistered
>
> Dale
>
> _______________________________________________
> 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

 

 

 


= --Apple-Mail=_D383E4E5-A2B7-4F2B-BE5C-72CF48D5333E-- From nobody Wed Mar 28 02:31:27 2018 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 116F2126BF6 for ; Wed, 28 Mar 2018 02:31:25 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 xtAwFiCRfL0I for ; Wed, 28 Mar 2018 02:31:21 -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 29716124C27 for ; Wed, 28 Mar 2018 02:31:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1522229479; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=kS+K1T+i2ayGDpMScVNJ8xrmjfSna+/x5U5L7977s0s=; b=ZfLbTCyGVZuTUF46w+lXorv7u+lEbWID24D173+OYr5HmIA79t79cSgfhSZbC7O5 hqGk5jm3v5dfbhekNF0z29uvJAuEbrc64lBgeHrKfPhsUnl4vfEi1cPvVEmujGpx hfF2q5VbJmhEHYAn7i5dvvoajALwILcEJdRJZZxtHr0=; X-AuditID: c1b4fb3a-0efff70000007691-7e-5abb60e770fc Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id C9.3D.30353.7E06BBA5; Wed, 28 Mar 2018 11:31:19 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.115]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0382.000; Wed, 28 Mar 2018 11:31:18 +0200 From: Christer Holmberg To: Brian Rosen , Mickey Arnold CC: "Dale R. Worley" , SIPCORE , "Roman Shpount" Thread-Topic: [sipcore] Organizing the sip-push work Thread-Index: AQHTxJF9bn6JSPnBLEOaVvnC2712C6PiWUsAgABUwACAAAN2gIAAASsAgAEMkoCAADSlAIABgxQA Date: Wed, 28 Mar 2018 09:31:18 +0000 Message-ID: References: <87efk7uax2.fsf@hobgoblin.ariadne.com> <9BA4FCE3-7E5F-479E-828A-1658C93688B9@brianrosen.net> <00002FE0-4756-4C0C-A6EB-C7A4D69871CE@brianrosen.net> In-Reply-To: <00002FE0-4756-4C0C-A6EB-C7A4D69871CE@brianrosen.net> 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: [131.160.50.130] Content-Type: multipart/alternative; boundary="_000_D6E13A432D2D6christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrOIsWRmVeSWpSXmKPExsUyM2K7tO7zhN1RBgcmylg8vT+NzeJwy0Z2 ixkXpjJbfP2xic3i5YkyB1aPyfu/Mnvc//aX3WPJkp9MHkdvzmX2uDWlIIA1issmJTUnsyy1 SN8ugSvjxpY7LAVbHzFWXLz/gqWBcfsBxi5GTg4JAROJGXtb2bsYuTiEBI4wSry+eQEsISSw hFFi1ReuLkYODjYBC4nuf9ogYRGBEInNxx+wg9jMAjkS5/bMZQaxhQWMJc5O+skKUi4CNPPn lWKI8iiJpn3zWUFsFgFVif0b5oCV8ApYS6x7IQSxdTezxO4LD8C2cgo4SWxZuIoJxGYUEJP4 fmoNE8QqcYlbT+YzQZwsILFkz3lmCFtU4uXjf2DzRQX0JDacuM0OMl9CQEni9gYniNYEidl7 jrCA2LwCghInZz5hmcAoOgvJ1FlIymYhKYOIG0i8PzefGcLWlli28DWUrS+x8ctZRgjbWuLE o3soahYwcqxiFC1OLS7OTTcy0kstykwuLs7P08tLLdnECIzeg1t+W+1gPPjc8RCjAAejEg+v kPfuKCHWxLLiytxDjBIczEoivO81gEK8KYmVValF+fFFpTmpxYcYpTlYlMR5ndIsooQE0hNL UrNTUwtSi2CyTBycUg2MZjxvJbfEHV8wW2rVRo0w32c1yTE3vP1Pqxp0f46Qatvhl/3ddb1c 2txHRU1/TC9tdbrd++WSjemOhS9OMa5gEq5Z6Gt3Uzn6lWG05i8JSWdx/9lX3O8sqJ+x5qix 9GymqwE1VvJdztf2Lk9nf7DtxgQH2xd3UhUrlNcfWhuxtaTyZtWySWsnKrEUZyQaajEXFScC AHhCOPvaAgAA Archived-At: Subject: Re: [sipcore] Organizing the sip-push work 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, 28 Mar 2018 09:31:25 -0000 --_000_D6E13A432D2D6christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, Every operator that I have been in contact with regarding this have indicat= ed that the currently defined mechanism works for them. So, again, I=92d be happy to discuss and participate in the work on extensi= ons (I have already done some sketching for an Outbound extension), but I a= lso think they should be defined in separate drafts, as they would require = quite a bit of text and discussions. Regards, Christer From: sipcore > o= n behalf of Brian Rosen > Date: Tuesday 27 March 2018 at 16:26 To: Mickey Arnold > Cc: Dale Worley >, "sipcore@i= etf.org" >, Roman Shpount > Subject: Re: [sipcore] Organizing the sip-push work Thanks Mickey. Does anyone have an actual use case for =93Tranche 2=94? If not, I=92m inc= lined to recommend that Christer proceed without it. I think there is more than sufficient interest in the interaction of PUSH a= nd Outbound, and we=92ll make sure that is addressed in another draft. I= =92d like to get this draft moving through approval processes soon. If som= eone (Dale) wanted to contribute text to that draft for Tranche 2, we would= of course consider it. Brian On Mar 27, 2018, at 6:18 AM, Mickey Arnold > wrote: Brian, Just to add my thoughts on this. I can see a conceptual benefit to having some sort of mechanism for being a= ble to distribute push Proxys across a network which I believe is what Dale= is aiming to address in =93Tranche 2=94 using =93Far Proxys=94. However, like Roman and Christer I don=92t see a use case for this that can= =92t be addressed using the current draft. I also think it will be quite co= mplex to specify and that it should not be included in the base draft. Thanks, Mickey From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Roman Shpount Sent: 26 March 2018 19:17 To: Brian Rosen > Cc: Dale R. Worley >; SIPCORE= > Subject: Re: [sipcore] Organizing the sip-push work Brian, I have mentioned this before to Dale -- I do not know of the use case for D= ale's " Tranche 2" Regards, _____________ Roman Shpount On Mon, Mar 26, 2018 at 2:13 PM, Brian Rosen > wrote: Okay, that=92s helpful - the new draft would address a real deployment (alb= eit you did something pre-standards). But you don=92t know of anything that would match what Dale called =93Tranc= he 2=94, requiring the pn-aor and what Christer thinks is a bunch of text c= hanges? Brian On Mar 26, 2018, at 2:00 PM, Roman Shpount > wrote: Brian, We had an existing implementation which have combined Push and Outbound for= a fairly large number of mobile end points. Since most of the mobile clien= ts are behind NAT and require SIPS, SIP Outbound and Push are commonly depl= oyed together. Our deployment was not based on the current SIP Push draft, = but it was not theoretical. This being said, I agree with Christer that def= ining how SIP Outbound works with Push belongs to a new draft. Regards, _____________ Roman Shpount On Mon, Mar 26, 2018 at 8:57 AM, Brian Rosen > wrote: This is getting complicated fast. Are there actual use cases for tranches 2-5? I understand the actual use c= ase for what Christer=92s draft does. I kind of get the need for interacti= on between PUSH and Outbound, although it=92s not clear to me that there is= an existing or planned implementation that needs it. More of a theoretic p= roblem. Let=92s look more closely at Tranch 2: why does this case exist? Why is th= e proxy changing it=92s address and not re-registering? Are you aware of = implementations that do this, need PUSH and wouldn=92t work with the existi= ng text? Chairs would like this draft to finish shortly. There seems to be a discon= nect between you and the guy writing the text on how necessary and complica= ted it is to support =93far=94 proxies. We=92re okay with a follow up draf= t dealing with interactions between PUSH and Outbound, but what do we reall= y need to do to get this draft out the door and useful to implementors? Brian > On Mar 25, 2018, at 5:01 PM, Dale R. Worley > wrote: > > Casting up accounts from the recent discussions, it seems to me that the > various mechanisms can be divided into no less than *five* tranches, as > diagrammed below. > > I recommend that we carry forward tranches 1 and 2 in > draft-ietf-sipcore-sip-push, and tranches 3, 4, and 5 in another draft, > oriented toward "supporting SIP Outbound with SIP Push". > > I particularly desire to incorporate tranche 2 (the "pn-aor" parameter, > and allowing certain alternative behaviors by implementing proxies) into > the current draft, because: > 1) It is a small extension of -08, where the UAs add one further URI > parameter. > 2) It is upward-compatible from implementations of -08. > 3) It allows implementation by "far" proxies, including edge proxies, > and supports UAs acquiring different addresses when they awaken. > 4) The support for "far" proxies establishes an architectural > requirement that the pn-* parameters must be URI parameters (which would > otherwise be a poor architectural choice). > > > tranche 1 as in draft-ietf-sipcore-sip-push-08 > implemented by: implementing proxies, UAs supporting SIP Pu= sh > enables: current implementations, "near" proxies, > no requirement for non-std. communication with regi= strar > | > | upward compatible with > | > v > tranche 2 plus: pn-aor parameter > implemented by: UAs supporting SIP Push, optionally by > implementing proxies > enables: "far" proxies, implementation by edge proxies, > changing UA addresses (NAT traversal) > | > | upward compatible with > | > v > tranche 3 plus: pn-reg-id parameter > implemented by: UAs supporting SIP Push with SIP Outbound, > implementing proxies supporting SIP Outbound > enables: SIP Push combined with SIP Outbound > | > | upward compatible with > | > v > tranche 4 plus: 'reg' event package extension 'path' element to repor= t > the Path header > implemented by: registrars, optionally by proxies > enables: SIP Push combined with SIP Outbound without having > to watch for re-REGISTER or re-dispatch to the AOR > > > | > | independently upward compatible from tranche 1 > | > v > tranche 5 plus: 'reg' event package extension 'last-reg' which is the > number of seconds since the contact was last update= d > implemented by: registrars, optionally by proxies > enables: implementing proxies do not need to send PN if > the UA has recently reregistered > > Dale > > _______________________________________________ > 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 --_000_D6E13A432D2D6christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

Every operator that I have been in contact with regarding this have in= dicated that the currently defined mechanism works for them.

So, again, I=92d be happy to discuss and participate in the work on ex= tensions (I have already done some sketching for an Outbound extension), bu= t I also think they should be defined in separate drafts, as they would req= uire quite a bit of text and discussions.

Regards,

Christer

From: sipcore <sipcore-bounces@ietf.org> on behalf of Br= ian Rosen <br@brianrosen.net>= ;
Date: Tuesday 27 March 2018 at 16:2= 6
To: Mickey Arnold <Michael.Arnold@metaswitch.com> Cc: Dale Worley <worley@ariadne.com>, "sipcore@ietf.org" <sipcore@ietf.org>, Roman Shpount <roman@telurix.com>
Subject: Re: [sipcore] Organizing t= he sip-push work

Thanks Mickey.

Does anyone have an actual use case for =93Tranche 2=94? &n= bsp;If not, I=92m inclined to recommend that Christer proceed without it.

I think there is more than sufficient interest in the inter= action of PUSH and Outbound, and we=92ll make sure that is addressed in ano= ther draft.  I=92d like to get this draft moving through approval proc= esses soon.  If someone (Dale) wanted to contribute text to that draft for Tranche 2, we would of course consider it.

Brian

On Mar 27, 2018, at 6:18 AM, Mickey Arnold <Michael.Arnold@metaswitch.c= om> wrote:

Brian,

 

Just to add m= y thoughts on this.

 

I can see a c= onceptual benefit to having some sort of mechanism for being able to distri= bute push Proxys across a network which I believe is what Dale is aiming to address in =93Tranche 2=94 using =93Far Proxys= =94.

 

However, like= Roman and Christer I don=92t see a use case for this that can=92t be addre= ssed using the current draft. I also think it will be quite complex to specify and that it should not be included in the base dr= aft.

 

Thanks, Micke= y

 

From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Roman Shpount
Sent: 26 March 2018 19:17
To: Brian Rosen <br@brianrosen.net>
Cc: Dale R. Worley <worley@ariadne.com>; SIPCORE <sipcore@ietf.org>
Subject: Re: [sipcore] Organizing the sip-push work

 

Brian,

 

I have mentioned this before to Dale -- I do not kno= w of the use case for Dale's " Tranche 2"

 

Regards= ,

_____________
Roman Shpount

 

On Mon, Mar 26, 2018 at 2:13 PM, Brian Rosen <br@brianrose= n.net> wrote:

Okay, that=92s helpful - the new draft would address= a real deployment (albeit you did something pre-standards).  

 

But you don=92t know of anything that would match wh= at Dale called =93Tranche 2=94, requiring the pn-aor and what Christer thin= ks is a bunch of text changes?

 

Brian

 

On Mar 26, 2018, at 2:00 PM, Roman Shpount <roman@telurix.= com> wrote:

 

Brian,

 

We had an existing implementation which have combine= d Push and Outbound for a fairly large number of mobile end points. Since m= ost of the mobile clients are behind NAT and require SIPS, SIP Outbound and= Push are commonly deployed together. Our deployment was not based on the current SIP Push draft, but it was not= theoretical. This being said, I agree with Christer that defining how SIP = Outbound works with Push belongs to a new draft.

 

Regards,


_____________
Roman Shpount

 

On Mon, Mar 26, 2018 at 8:57 AM, Brian Rosen <br@brianrose= n.net> wrote:

This is getting complicated fast.

Are there actual use cases for tranches 2-5?  I understand the actual = use case for what Christer=92s draft does.  I kind of get the need for= interaction between PUSH and Outbound, although it=92s not clear to me tha= t there is an existing or planned implementation that needs it. More of a theoretic problem.

Let=92s look more closely at Tranch 2: why does this case exist?  Why = is the proxy changing it=92s address and not re-registering?   Ar= e you aware of implementations that do this, need PUSH and wouldn=92t work = with the existing text?

Chairs would like this draft to finish shortly.  There seems to be a d= isconnect between you and the guy writing the text on how necessary and com= plicated it is to support =93far=94 proxies.  We=92re okay with a foll= ow up draft dealing with interactions between PUSH and Outbound, but what do we really need to do to get this draft out the d= oor and useful to implementors?

Brian


> On Mar 25, 2018, at 5:01 PM, Dale R. Worley <worley@ariadne.com> wro= te:
>
> Casting up accounts from the recent discussions, it seems to me that t= he
> various mechanisms can be divided into no less than *five* tranches, a= s
> diagrammed below.
>
> I recommend that we carry forward tranches 1 and 2 in
> draft-ietf-sipcore-sip-push, and tranches 3, 4, and 5 in another draft= ,
> oriented toward "supporting SIP Outbound with SIP Push".
>
> I particularly desire to incorporate tranche 2 (the "pn-aor"= parameter,
> and allowing certain alternative behaviors by implementing proxies) in= to
> the current draft, because:
> 1) It is a small extension of -08, where the UAs add one further URI > parameter.
> 2) It is upward-compatible from implementations of -08.
> 3) It allows implementation by "far" proxies, including edge= proxies,
> and supports UAs acquiring different addresses when they awaken.
> 4) The support for "far" proxies establishes an architectura= l
> requirement that the pn-* parameters must be URI parameters (which wou= ld
> otherwise be a poor architectural choice).
>
>
> tranche 1     as in draft-ietf-sipcore-sip-push-08
>               implemented by: = implementing proxies, UAs supporting SIP Push
>               enables: current= implementations, "near" proxies,
>                    &= nbsp;  no requirement for non-std. communication with registrar
>   |
>   | upward compatible with
>   |
>   v
> tranche 2     plus: pn-aor parameter
>               implemented by: = UAs supporting SIP Push, optionally by
>                    &= nbsp;  implementing proxies
>               enables: "f= ar" proxies, implementation by edge proxies,
>                    &= nbsp;  changing UA addresses (NAT traversal)
>   |
>   | upward compatible with
>   |
>   v
> tranche 3     plus: pn-reg-id parameter
>               implemented by: = UAs supporting SIP Push with SIP Outbound,
>                    &= nbsp;  implementing proxies supporting SIP Outbound
>               enables: SIP Pus= h combined with SIP Outbound
>   |
>   | upward compatible with
>   |
>   v
> tranche 4     plus: 'reg' event package extension 'path= ' element to report
>                    &= nbsp;  the Path header
>               implemented by: = registrars, optionally by proxies
>               enables: SIP Pus= h combined with SIP Outbound without having
>                    &= nbsp;  to watch for re-REGISTER or re-dispatch to the AOR
>
>
>   |
>   | independently upward compatible from tranche 1
>   |
>   v
> tranche 5     plus: 'reg' event package extension 'last= -reg' which is the
>                    &= nbsp;  number of seconds since the contact was last updated
>               implemented by: = registrars, optionally by proxies
>               enables: impleme= nting proxies do not need to send PN if
>                    &= nbsp;  the UA has recently reregistered
>
> Dale
>
> _______________________________________________
> sipcore mailing list
> sipco= re@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore

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

 

 

 


--_000_D6E13A432D2D6christerholmbergericssoncom_-- From nobody Wed Mar 28 04:57:14 2018 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 340711267BB for ; Wed, 28 Mar 2018 04:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 kK4GDNgCrWhd for ; Wed, 28 Mar 2018 04:57:09 -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 B8546126E01 for ; Wed, 28 Mar 2018 04:57:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1522238227; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=BC/adT6iHP+tKdVY69fqnKwm6MQlHwIshc42ZlQTrX4=; b=bddZnSutYb51uf07FG5Mwm86ACRkSOdcIfN+Mf4RZJ6IrePGf6Z07VIZcJMBhLk3 VQB2RDj2Q6Ki4Rm6rI5I6Ln/aeh2A1toh5dgtuZ7NcoqQp2FBHJ3shgVsMppQI1L IT/AxILOYZpt+N49t4w2fyraMRwH4nPIkI6dwKlQhE4=; X-AuditID: c1b4fb25-efa4b9c000000e6d-9b-5abb831239d7 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id E4.15.03693.2138BBA5; Wed, 28 Mar 2018 13:57:07 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.115]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0382.000; Wed, 28 Mar 2018 13:56:15 +0200 From: Christer Holmberg To: Christer Holmberg , Paul Kyzivat , SIPCORE Thread-Topic: [sipcore] session-timer fix Thread-Index: AQHTwfCeyHYsx4XVTkSHOLQKDcONKqPdSEtwgAhcbAA= Date: Wed, 28 Mar 2018 11:56:14 +0000 Message-ID: References: <949dba9e-33b7-66b9-1b16-d25902f65367@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B72E06C39@ESESSMB102.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B72E06C39@ESESSMB102.ericsson.se> 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: [131.160.50.130] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAIsWRmVeSWpSXmKPExsUyM2K7rq5w8+4og0eX2SxWbDjAavH1xyY2 ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugStj7oP1jAXblSqOrS9sYOyV7mLk4JAQMJF4 99i8i5GLQ0jgCKPEv5urmSGcJYwSnzvPsIMUsQlYSHT/0+5i5OQQEaiS2HTqNiuILSygIbF/ 7U82iLimxJ/ZG5hBykUErCTOb5cDCbMIqEoc33ieCcTmFbCW2HzxO1irkEAzo8TJE/IgNqeA n8Si7vdgYxgFxCS+n1oDVs8sIC5x68l8MFtCQEBiyZ7zzBC2qMTLx//A5ogK6ElsOHGbHeIV JYnbG5wgWvUkbkydwgZhW0tM2DgNaqS2xLKFr5khzhGUODnzCcsERrFZSLbNQtI+C0n7LCTt s5C0L2BkXcUoWpxanJSbbmSsl1qUmVxcnJ+nl5dasokRGE8Ht/xW3cF4+Y3jIUYBDkYlHl6u qt1RQqyJZcWVuYcYJTiYlUR432sAhXhTEiurUovy44tKc1KLDzFKc7AoifM+NN8cJSSQnliS mp2aWpBaBJNl4uCUamDMarfILGeblSdxcIFN95SJUjv2mF903VPBOlvZ8uqtN/4zczti5ORK WAw+FVyr3Hf1gOksF+mAGevqD7ryGPWrnjv4NLnmn/E301N7pmh5RBTf97M8Va4cLFqoMmf6 0ffxew+afU5OnrpBdkmk2utFfO+URALVHRM2u4ionqqzijW166kT5FNiKc5INNRiLipOBACM X5AwowIAAA== Archived-At: Subject: Re: [sipcore] session-timer fix 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, 28 Mar 2018 11:57:11 -0000 Hi, Ok, I checked some old e-mails, and had a chat with the internal people that informed me about the problem. The UPDATE request with refresher=3Duas is *NOT* the problem. They have the same assumption as Paul, Jonathan etc - the value is indicated per transaction. So, UPDATE with refresher=3Duas is ok. My apologies for mixing that up. It=B9s the UPDATE 200 OK response, where the proxy inserts refresher=3Duac, that causes the problem. So, one alternative would be to allow UPDATE requests/responses sent while the s-t negotiation is ongoing are handled as defined in RFC 4028, but that the refresher value must not be changed. In the case below, that means that the UA needs to include s-t information in the UPDATE response (message #7). Regards, Christer On 23/03/18 22:48, "sipcore on behalf of Christer Holmberg" wrote: >Hi Paul, > >You say (and it was indicated in the meeting): > > "I think it is, since the uac/uas roles are relative to > the direction of the individual request," > >Assuming that the AS and UA are implemented that way, the problem still >occurs when the AS receives (8), where the refresher > > > > >>Here is the primary use case flow that has been reported as the >>motivating case for the draft. (I've reformatted it for ease in typing.) >> >> 1) UA->Proxy: INVITE/SE:uac >> 2) Proxy->AS: INVITE/SE:uac >> 3) AS->Proxy: 18x/no-SE >> 4) Proxy->UA: 18x/no-SE >> 5) AS->Proxy: UPDATE/SE:uas >> 6) Proxy->UA: UPDATE/SE:uas >> 7) UA->Proxy: 200(UPDATE)/no-SE >> 8) Proxy->AS: 200(UPDATE)/SE:uac >> 9) AS->Proxy: 480(INVITE) >> 10) Proxy->UA: 480(INVITE) >> >>Some observations on the above: >> >>- in (5) the AS includes SE in the UPDATE, while in (7) the UA >> doesn't include SE in the response to the UPDATE. This seems >> to reflect a difference of opinion by the implementors of >> the UA and AS about what 4028 expects in this situation. >> This ambiguity needs to be resolved, and will require changes >> in some implementations. > >Correct. This is a case where UPDATE is received while the S-T >negotiation is still ongoing. > >> - The 480 in (9) is caused by the AS objecting to the "uac" >> in (8) because it is in conflict with the "uas" in (5). >> This in turn is caused by the proxy including the "uac" >> in (8) because it is following the rules and thinks that >> the UA doesn't support S-T. This of course isn't the >> situation. > >Shouldn't the proxy know that the UA supports S-T, due to (1)? > >> - There has been some discussion about whether the "uas" >> value in (5) is consistent with the "uac" value in (1). >> I think it is, since the uac/uas roles are relative to >> the direction of the individual request, and (5) is >> going in the opposite direction of (1). > >Let's assume it is like that. > >> But this >> doesn't seem to affect the rest of the analysis. >> If the refresher in the UPDATE was inconsistent with >> that in the INVITE then I would expect the UA to send >> an error response to the UPDATE. >> >> ISTM that at least part of the fix for this must be to fix the >>ambiguity about whether SE is to be included in an >> UPDATE and its response that are embedded in an INVITE transaction. The >>existing draft does address this one way. > >Yes. > >> Another way to address it would be to require SE to be included in both >>the UPDATE and its response, in a way >> consistent with what was in the INVITE and will eventually be in the >>response to the INVITE. > >Yes. > >> A much different way would be to require that the timer negotiation in >>an INVITE be completed in the first reliable >> response to the INVITE, either 2xx or reliable 1xx. Then any UPDATE >>that followed within the transaction would >> presumably start a new timer negotiation. > >Yes. > >> I'll also observe that this entire discussion has focused on the >>negotiation of the refresher. But there is a comparable >> issue around negotiating the duration of the timer. That ought to be >>sorted out as part of the same fix. > >Yes. > >Regards, > >Christer > >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore From nobody Wed Mar 28 08:46:49 2018 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 F20A512420B for ; Wed, 28 Mar 2018 08:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 LgbOsw8yjWUY for ; Wed, 28 Mar 2018 08:46:44 -0700 (PDT) Received: from orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67B6B120047 for ; Wed, 28 Mar 2018 08:46:44 -0700 (PDT) Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) by opfedar25.francetelecom.fr (ESMTP service) with ESMTP id B5EC51209FA; Wed, 28 Mar 2018 17:46:42 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.13]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id 93D3F180075; Wed, 28 Mar 2018 17:46:42 +0200 (CEST) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM6D.corporate.adroot.infra.ftgroup ([fe80::54f9:a6c3:c013:cbc7%19]) with mapi id 14.03.0382.000; Wed, 28 Mar 2018 17:46:42 +0200 From: To: "Asveren, Tolga" , "sipcore@ietf.org" Thread-Topic: WGLC: draft-ietf-sipcore-originating-cdiv-parameter Thread-Index: AdO8mvHNh2Fu7WwWT5iDJ4VxNB0YgwAP3GCgAArG/7AABt3bAAADWXtwAl77MaA= Date: Wed, 28 Mar 2018 15:46:41 +0000 Message-ID: <21553_1522252002_5ABBB8E2_21553_183_1_8B970F90C584EA4E97D5BAAC9172DBB849C9699E@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: <24496_1521199612_5AABA9FC_24496_87_1_8B970F90C584EA4E97D5BAAC9172DBB81D70AC30@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <11272_1521209907_5AABD233_11272_147_2_8B970F90C584EA4E97D5BAAC9172DBB81D70B5E7@OPEXCLILMA4.corporate.adroot.infra.ftgroup> In-Reply-To: <11272_1521209907_5AABD233_11272_147_2_8B970F90C584EA4E97D5BAAC9172DBB81D70B5E7@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.2] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sipcore] WGLC: 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, 28 Mar 2018 15:46:47 -0000 SGkgVG9sZ2EsIGFsbCwNCg0KUmVnYXJkaW5nIHlvdXIgbGFzdCBjb21tZW50IGFuZCBhZnRlciBh IHNlY29uZCB0aG91Z2h0LCBJIGRvbid0IGtub3cgaWYgdGhlcmUgaXMgYSBuZWVkIGZvciB0aGUg InRlcm0tY2RpdiIgY2FzZSB5b3UgcHJvcG9zZSBleGNlcHQgdG8gYmUgc3ltbWV0cmljYWwuIA0K SSB3b3VsZCBsaWtlIHRvIGhhdmUgbW9yZSBmZWVkYmFjayBiZWZvcmUgYWRkaW5nIGEgdXNlIGNh c2UsIGNoYW5naW5nIHRoZSBuYW1lIGFuZCBzY29wZSBvZiB0aGUgZHJhZnQgd2hpbGUgaXQgaXMg bm93IHVuZGVyIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIHN0YXR1cy4gDQpUaGUgbmFtZSBvZiB0 aGUgZHJhZnQgaXMgIm9yaWdpbmF0aW5nLWNkaXYiIGFuZCBpdHMgbW90aXZhdGlvbiBmcm9tIHRo ZSBiZWdpbm5pbmcgd2FzIHRoZSAib3JpZy1jZGl2IiB1c2UgY2FzZS4NCg0KQmVzdCByZWdhcmRz LA0KTWFyaWFubmUNCg0KDQpEZcKgOiBzaXBjb3JlIFttYWlsdG86c2lwY29yZS1ib3VuY2VzQGll dGYub3JnXSBEZSBsYSBwYXJ0IGRlIG1hcmlhbm5lLm1vaGFsaUBvcmFuZ2UuY29tDQpFbnZvecOp wqA6IHZlbmRyZWRpIDE2IG1hcnMgMjAxOCAxNToxOA0Kw4DCoDogQXN2ZXJlbiwgVG9sZ2E7IHNp cGNvcmVAaWV0Zi5vcmcNCk9iamV0wqA6IFJlOiBbc2lwY29yZV0gV0dMQzogZHJhZnQtaWV0Zi1z aXBjb3JlLW9yaWdpbmF0aW5nLWNkaXYtcGFyYW1ldGVyDQoNCkl0IGlzIHRydWUgdGhhdCB3ZSBj b3VsZCBjb25zaWRlciB0aGlzIOKAnHRlcm0tY2RpduKAnSBjYXNlIGluIHRoZSBJLUQgdG8gaGF2 ZSBhIHN5bW1ldHJpYyB2YWx1ZSBldmVuIGlmIGZvciBub3cgbm8g4oCcbmVlZOKAnSBoYXMgYmVl biBpZGVudGlmaWVkLiANCkkgY2FuIHdvcmsgb24gdGhpcyBhZGRpbmcgdG8gdGhlIEktRC4NCg0K QW55IG90aGVyIHZpZXdzIG9uIGludHJvZHVjaW5nIHRoZSBzZXNzaW9uIGNhc2Ug4oCcdGVybS1j ZGl24oCdIHRvbz8NCg0KQlIsDQpNYXJpYW5uZQ0KDQpEZcKgOiBBc3ZlcmVuLCBUb2xnYSBbbWFp bHRvOnRhc3ZlcmVuQHJiYm4uY29tXSANCkVudm95w6nCoDogdmVuZHJlZGkgMTYgbWFycyAyMDE4 IDEzOjI1DQrDgMKgOiBNT0hBTEkgTWFyaWFubmUgSU1UL09MTjsgc2lwY29yZUBpZXRmLm9yZw0K T2JqZXTCoDogUkU6IFdHTEM6IGRyYWZ0LWlldGYtc2lwY29yZS1vcmlnaW5hdGluZy1jZGl2LXBh cmFtZXRlcg0KDQpIaSBNYXJpYW5uZSwNCg0KVGhhbmsgeW91IGZvciB0aGUgZGV0YWlsZWQgZXhw bGFuYXRpb24gb2YgdGhlIHNlcnZpY2UuIFllcywgdGhhdCBpcyBzb21ldGhpbmcgdXNlZCB0b2Rh eS4gQnV0IGhvdyBjb3VsZCB3ZSBrbm93IHRoYXQgdGhlcmUgd291bGRu4oCZdCBiZSBhbnkgc2Vy dmljZXMgd2hpY2ggd291bGQgYmUgdHJpZ2dlcmVkL25vdCB0cmlnZ2VyZWQgb24gdGhlIGRpdmVy dGluZyBwYXJ0eSBiYXNlZCBvbiB3aGV0aGVyIGl0IGlzIHRoZSBvcmlnaW5hbCBpbml0aWF0b3Ig b2YgdGhlIGNhbGwgb3IganVzdCB0aGUgZGl2ZXJ0ZXI/IFRoYXQgaXQgaXMgbm90IG5lZWRlZCB0 b2RheSAtYnkgYSBjZXJ0YWluIGRlcGxveW1lbnQgbW9kZWwtLCBvciB0aGF0IHlvdShhbmQgSSkg YXJlIG5vdCBhd2FyZSBvZiBpdCBkb2VzIG5vdCBuZWNlc3NhcmlseSBtZWFuIGl0IHdvdWxkbuKA mXQvaXMgYWxyZWFkeSB1c2VkIHNvbWV3aGVyZSBpbiB0aGUgdW5pdmVyc2Ugb2YgcmVhbCB0aW1l IHNlc3Npb25zLiANCg0KVGhlIHNoaXAgZm9yIGEgbW9yZSBnZW5lcmljIGZyYW1ld29yayB0byBm YWNpbGl0YXRlIOKAnHNjZW5hcmlvIGJhc2VkIHNlcnZpY2UgaW52b2NhdGlvbi9pbnRlcmFjdGlv buKAnSBtYXkgaGF2ZSBzYWlsZWQgYnV0IGF0IGEgbWluaW11bSBJIHdvdWxkIHN1Z2dlc3QgYWRk aW5nIOKAnHRlcm0tY2RpduKAnSBhcyB3ZWxsLg0KDQpUaGFua3MsDQpUb2xnYQ0KDQpGcm9tOiBt YXJpYW5uZS5tb2hhbGlAb3JhbmdlLmNvbSA8bWFyaWFubmUubW9oYWxpQG9yYW5nZS5jb20+IA0K U2VudDogRnJpZGF5LCBNYXJjaCAxNiwgMjAxOCA3OjI3IEFNDQpUbzogQXN2ZXJlbiwgVG9sZ2Eg PHRhc3ZlcmVuQHJiYm4uY29tPjsgc2lwY29yZUBpZXRmLm9yZw0KU3ViamVjdDogUkU6IFdHTEM6 IGRyYWZ0LWlldGYtc2lwY29yZS1vcmlnaW5hdGluZy1jZGl2LXBhcmFtZXRlcg0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpOT1RJQ0U6IFRoaXMgZW1haWwgd2Fz IHJlY2VpdmVkIGZyb20gYW4gRVhURVJOQUwgc2VuZGVyDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQoNCkhpIFRvbGdhLA0KDQpGaXJzdCwgdGhhbmsgeW91IGZvciB0 aGUgcmV2aWV3IG9mIHRoZSBkcmFmdC4NClRvIGFuc3dlciB0byB0aGUgcXVlc3Rpb24gaW4geW91 ciBmaXJzdCBlbWFpbCwgb25jZSBhIGRpdmVyc2lvbiBoYXMgYmVlbiBwcm9jZXNzZWQsIHRoZSBv dXRnb2luZyBsZWcgd2lsbCBnbyB0byB0aGUgZGl2ZXJzaW9uIHRhcmdldCBidXQgYmVmb3JlIHRo YXQsIHRoZSBzZXNzaW9uIGNhc2Ugb2YgdGhlIHNlcnZlZC11c2VyIGhhcyBiZWVuIGNoYW5nZWQg d2l0aCB0aGUgZm9sbG93aW5nIHF1ZXN0aW9uczogd2hvIGlzIHRoZSBvcmlnaW5hdGluZyBwYXJ0 eT8gdGhlIGNhbGxlciBvciB0aGUgZGl2ZXJ0aW5nIHVzZXI/IERvZXMgcHJpdmFjeSBvZiB0aGUg ZGl2ZXJ0aW5nIHVzZXIgYXBwbGllcz8gZG8gd2UgbmVlZCB0byBjaGVjayB0aGUgYmFycmluZyBz ZXJ2aWNlIG9mIHRoZSBkaXZlcnRpbmcgdXNlciBmb3Igb3V0Z29pbmcgY2FsbHM/IE9UT0gsIHRo ZSBjYWxsZXIgcmVtYWluIHRoZSBzYW1lIGFuZCBpdHMgb3JpZ2luYXRpbmcgc2VydmljZXMgc2hv dWxkIHN0aWxsIGFwcGx5LiBGb3IgdGhhdCBwYXJ0aWN1bGFyIHNpdHVhdGlvbiBzb21ld2hlcmUg YmV0d2VlbiB0ZXJtaW5hdGluZyBhbmQgb3JpZ2luYXRpbmcsIHRoZSBkcmFmdCBwcm9wb3NlcyB0 byBleHRlbmQgdGhlIFAtU2VydmVkLXVzZXIuIA0KQXQgdGhlIGRpdmVydGVkLXRvIHVzZXIgbGV2 ZWwsIGl0IGlzIGRpZmZlcmVudDogSXQgbWF5IGluZGVlZCBiZSBwb3NzaWJsZSB0byB0cmlnZ2Vy IGEgc3BlY2lmaWMgc2VydmljZSBmb3IgdGhlIHRlcm1pbmF0aW5nLWFmdGVyLWRpdmVyc2lvbiBi dXQgdGhpcyBpcyBub3QgYSBuZXcgdHlwZSBzZXNzaW9uIGNhc2UuIEF0IHRoZSB0ZXJtaW5hdGlu ZyBzaWRlLCB0aGUgc2VydmVkIHVzZXIgcmVtYWlucyB0aGUgdGVybWluYXRpbmcgdXNlciBhbmQg b25seSBpdHMgdGVybWluYXRpbmcgc2VydmljZXMgaGF2ZSB0byBiZSB0cmlnZ2VyZWQuIE9mIGNv dXJzZSwgdGVybWluYXRpbmcgc2VydmljZXMgYmFzZWQgb24gdGhlIG9yaWdpbmF0aW5nIHBhcnR5 IGlkZW50aXR5IGFyZSBhZmZlY3RlZCBieSB0aGUgY2FsbCBkaXZlcnNpb24gc2luY2Ugd2UgY2Fu IGRpc2N1c3Mgb24gd2hvIGlzIHRoZSBvcmlnaW5hdGluZyBwYXJ0eSBidXQgdGhpcyBpcyBtb3Jl IGEgbWF0dGVyIG9mIHNlcnZpY2UgaW50ZXJhY3Rpb24uIFRoZSBzZXJ2ZWQtdXNlciBpcyB0aGUg ZGl2ZXJzaW9uIHRhcmdldCBhbmQgdGhlIHNlc3Npb24gY2FzZSBpcyB0ZXJtaW5hdGluZyBhbmQg aXQgd2lsbCBub3QgY2hhbmdlIChleGNlcHQgaWYgdGhlcmUgaXMgYW5vdGhlciBjYWxsIGRpdmVy c2lvbiA7KS4gSnVzdCB0byBsZXQgeW91IGtub3csIHRoZXJlIGlzIGEgc2VydmljZSB0byByZWpl Y3QgaW5jb21pbmcgZm9yd2FyZGVkIGNhbGxzIGFuZCB0aGUgdHJpZ2dlciBmb3IgdGhpcyBzcGVj aWZpYyBraW5kIG9mIGJhcnJpbmcgaXMgdGhlIHByZXNlbmNlIG9mIGEgZGl2ZXJ0aW5nIHVzZXIg aWRlbnRpdHkgaW4gdGhlIGluY29taW5nIElOVklURSByZXF1ZXN0LiBJdCBpcyBqdXN0IGEgY3Jp dGVyaW9uIChhcyBmb3IgYWxsIGJhcnJpbmcgc2VydmljZXMpLiANCg0KQWJvdXQgeW91ciBjb21t ZW50IG9uIHRoZSB3YXkgU0lQIGhlYWRlcnMgYXJlIGV4dGVuZGVkLCBJTU8sIHJ1bGVzIGZvciBz dGFuZGFyZGl6YXRpb24gcHJvY2VzcyBvZiBTSVAgYXJlIGhlcmUgZm9yIHllYXJzIGFuZCBpdCBp cyBub3QgdGhlIGdvb2QgdGltZSB0byBjaGFuZ2UgdGhhdC4gVG8gYmUgdHJhbnNwYXJlbnQsIHRo aXMgZXh0ZW5zaW9uIHdhcyBmaXJzdCBkZWZpbmVkIG9ubHkgd2l0aGluIDNHUFAgc3BlY2lmaWNh dGlvbiBiZWNhdXNlIHRoZXJlIHdhcyBhIHNlcnZpY2UgbmVlZCBiZWhpbmQuIEJlY2F1c2UgaXQg d2FzIGFuIGV4dGVuc2lvbiBvZiBhbiBSRkMgYW5kIHRoZSB3YXMgdGhlIHN5bnRheCBvZiB0aGUg aGVhZGVyIGlzIGRlc2lnbmVkLCB0aGUgZXh0ZW5zaW9uIGlzIHRvIGJlIGRvbmUgaW4gSUVURi4g V2UgY2FuIGRpc2N1c3MgdGhhdCBidXQgd2UgYXJlIGF0IHRoZSBlbmQgb2YgU0lQIHByb3RvY29s IGV4dGVuc2lvbiBwcm9jZXNzLi4uDQpGaW5hbGx5LCBSRkM1NTAyIGRlZmluZXMgYSDigJxwcml2 YXRl4oCdIChQLSApIGhlYWRlciBzbyBpdCBpcyBub3Qgc3VycHJpc2luZyB0aGF0IGl0cyBleHRl bnNpb24gYXMgYSAzR1BQIGZsYXZvciDimLoNCg0KQmVzdCByZWdhcmRzLA0KTWFyaWFubmUNCg0K DQpEZcKgOiBzaXBjb3JlIFttYWlsdG86c2lwY29yZS1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBw YXJ0IGRlIEFzdmVyZW4sIFRvbGdhDQpFbnZvecOpwqA6IHZlbmRyZWRpIDE2IG1hcnMgMjAxOCAw OTowNg0Kw4DCoDogc2lwY29yZUBpZXRmLm9yZw0KT2JqZXTCoDogUmU6IFtzaXBjb3JlXSBXR0xD OiBkcmFmdC1pZXRmLXNpcGNvcmUtb3JpZ2luYXRpbmctY2Rpdi1wYXJhbWV0ZXINCg0KU29tZSBt b3JlIG11c2luZ3MgZnJvbSBjb25jZXB0dWFsIHBlcnNwZWN0aXZlOg0KDQpTSVAgcHJvdmlkZXMg YSB0b29sYm94IHRvIHByb3ZpZGUgc2VydmljZXMuIEFuZCB5ZXMsIHRoZXJlIGlzIHNvbWUgc3Bl Y2lhbCAoaWYgSSBtYXkgc2F5IOKAnGZhdm9yZWTigJ0pIHN0YXR1cyBvZiAzR1BQIHdoZW4gaXQg Y29tZXMgdG8gU0lQIHN0YW5kYXJkaXphdGlvbi4gT1RPSCwgZG9lcyB0aGUgYXBwcm9hY2ggdGFr ZW4gYnkgUkZDNTUwMiBnbyBhIGxpdHRsZSBiaXQgdG9vIGZhciBpbiB0ZXJtcyBvZiBvdmVyLWRl ZmluaW5nIHRoZSBnZW5lcmljIFNJUCB0b29sYm94Pw0KDQpBbiBhbHRlcm5hdGl2ZSBjb3VsZCBi ZSB0byBkZWZpbmUgYSBoZWFkZXIvcGFyYW1ldGVyIHdoaWNoIHJlZmVycyB0byBhIOKAnHNjZW5h cmlv4oCdIGluIGFuIGFic3RyYWN0IHdheSAod2l0aCBhIGdlbmVyaWMgc3ludGF4KSBhbmQgbGV0 IG90aGVyIHN0YW5kYXJkcyBmb3JhIGRlZmluZSB0aGUgdmFsdWVzIHRoZXkgd291bGQgbGlrZSB0 byB1c2UgYW5kL29yIHJlbHkgb24gY29uZmlndXJhdGlvbiBhbGlnbm1lbnQgYmV0d2VlbiByZWxl dmFudCBlbGVtZW50cywgZS5nLiBTLUNTQ0YvSFNTL0FTLiBDb25zaWRlcmluZyB3aGVyZSB3ZSBh cmUgcmlnaHQgbm93ICh0aGF0IFJGQzU1MDIgaXMgYWxyZWFkeSB0aGVyZSkgdGhpcyBhcHByb2Fj aCBwcmFjdGljYWxseSB3b3VsZCBtZWFuIHRoYXQgZHJhZnQtaWV0Zi1zaXBjb3JlLW9yaWdpbmF0 aW5nLWNkaXYtcGFyYW1ldGVyIGlzIG5vdCBkZWZpbmVkIGFuZCBQLVNlcnZlZC1Vc2VyIHNlcnZl ZC11c2VyLXBhcm0gaXMgZXh0ZW5kZWQgYnkgb3RoZXJzIGFzIG5lZWRlZCAoYXMgaXQgYWxsb3dz IHRoYXQpLg0KDQpPdGhlcndpc2UsIHRoZXJlIHdvdWxkL2NvdWxkIGJlIHRoZSBuZWVkIHRvIGtl ZXAgYWRkaW5nIG5ldyB2YWx1ZXMgaW4gZGlmZmVyZW50IElFVEYgc3BlY2lmaWNhdGlvbnMgdGhl IG1vcmUg4oCcZGVwbG95bWVudCBtb2RlbCBzcGVjaWZpYyB1c2UgY2FzZXPigJ0gYXJlIG5lZWRl ZC9kaXNjb3ZlcmVkL2ludmVudGVkLg0KDQpUaGFua3MsDQpUb2xnYQ0KRnJvbTogQXN2ZXJlbiwg VG9sZ2EgDQpTZW50OiBUaHVyc2RheSwgTWFyY2ggMTUsIDIwMTggNDoyMyBQTQ0KVG86IHNpcGNv cmVAaWV0Zi5vcmcNClN1YmplY3Q6IFdHTEM6IGRyYWZ0LWlldGYtc2lwY29yZS1vcmlnaW5hdGlu Zy1jZGl2LXBhcmFtZXRlcg0KDQpJIHJldmlld2VkIHRoZSBkcmFmdCBhbmQgaGF2ZSBubyB0ZWNo bmljYWwgaXNzdWVzIHdpdGggaXQgZXhjZXB0IG9uZSBxdWVzdGlvbjoNCg0KSXMgaXQgZW52aXNp b25lZCB0aGF0IHRoZXJlIHdvdWxkL2NvdWxkIGJlIGEgbmVlZCBmb3IgdGVybS1jZGl2IGFzIHdl bGwgdG8gdHJpZ2dlciBhIGRpZmZlcmVudCBzZXJ2aWNlIHNldCBpZiB0aGUgdGFyZ2V0IGlzIGRl dGVybWluZWQgYWZ0ZXIgZGl2ZXJzaW9uPyBJdCBtYXkgYmUgYmV0dGVyIHRvIGRlZmluZSBpdCBu b3cgcmF0aGVyIHRoYW4gaGF2aW5nIHlldCBhbm90aGVyIGRyYWZ0LCBhdCBsZWFzdCB0byBiZSBm dXR1cmUgcHJvb2YuDQoNClRoYW5rcywNClRvbGdhDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KQ2UgbWVzc2FnZSBl dCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNv bmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jDQpwYXMgZXRy ZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91 cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcg0K YSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRl cy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJh dGlvbiwNCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2Ug YSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCg0KVGhpcyBtZXNzYWdl IGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVn ZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsNCnRoZXkgc2hvdWxk IG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9u Lg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlm eSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMu DQpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNz YWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQpUaGFu ayB5b3UuDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQoNCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZl bnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdp ZWVzIGV0IG5lIGRvaXZlbnQgZG9uYw0KcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBj b3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFy IGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXINCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1 aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlx dWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sDQpPcmFuZ2UgZGVjbGluZSB0b3V0 ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBm YWxzaWZpZS4gTWVyY2kuDQoNClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBj b250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJl IHByb3RlY3RlZCBieSBsYXc7DQp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQg b3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4NCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRo aXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRo aXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVk LCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZp ZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KVGhhbmsgeW91Lg0KCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3Nh Z2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9u cyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMg ZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kg dm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxl cgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2lu dGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRl cmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdl IGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2Ug YW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdl ZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBu b3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4K SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0 aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFz IGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2Vz IHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91 LgoK From nobody Wed Mar 28 08:57:21 2018 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 B12961273B1 for ; Wed, 28 Mar 2018 08:57:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 XCnkHIdpSHaj for ; Wed, 28 Mar 2018 08:57:17 -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 88D7F127369 for ; Wed, 28 Mar 2018 08:57:17 -0700 (PDT) X-AuditID: 1207440d-a8dff70000007998-73-5abbbb5a9484 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 C6.C6.31128.B5BBBBA5; Wed, 28 Mar 2018 11:57:15 -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 w2SFvD6I006468 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 28 Mar 2018 11:57:14 -0400 To: Christer Holmberg , SIPCORE References: <949dba9e-33b7-66b9-1b16-d25902f65367@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B72E06C39@ESESSMB102.ericsson.se> From: Paul Kyzivat Message-ID: Date: Wed, 28 Mar 2018 11:57:13 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.6.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+NgFvrHIsWRmVeSWpSXmKPExsUixO6iqBuze3eUwaKr7BYXZh5mtPj6YxOb A5PHr69X2TyWLPnJFMAUxWWTkpqTWZZapG+XwJXxbPUG5oI9mhVrXp9naWCcpdDFyMkhIWAi cfHDFsYuRi4OIYEdTBJ3L7YxQTgPmSQO7/3MClIlLKAhsX/tT7YuRg4OEYFoiW9LRSBqtjJK bJpxEqyGTUBLYs6h/ywgNq+AvcSRh+fYQepZBFQlTsyUBQmLCqRJXGreygxRIihxcuYTsHJO ARuJU+0/wMYwC5hJzNv8kBnCFpe49WQ+E4QtL9G8dTbzBEb+WUjaZyFpmYWkZRaSlgWMLKsY 5RJzSnN1cxMzc4pTk3WLkxPz8lKLdI30cjNL9FJTSjcxQgKVdwfj/3UyhxgFOBiVeHgtFu2O EmJNLCuuzD3EKMnBpCTK+3QGUIgvKT+lMiOxOCO+qDQntfgQowQHs5II73sNoBxvSmJlVWpR PkxKmoNFSZxXbYm6n5BAemJJanZqakFqEUxWhoNDSYI3chdQo2BRanpqRVpmTglCmomDE2Q4 D9BwYZAa3uKCxNzizHSI/ClGY46Wi0/amDluvHjdxizEkpeflyolzisFUioAUppRmgc3DZZs XjGKAz0nzKsGUsUDTFRw814BrWICWrWtaQfIqpJEhJRUA2OBYvbOyx6Gz0uvTTcqvSReUJTV P6fbRrheupez2OnKDOFiZrvvE+vWnV3BKbWe84qwWyf/3vd6jn4R7ZPeJZ73fetZ6zZ9u4vA 7Dcxpg2FZ4KeN360nu5Y3p3rf2vJVL8wly9tGc6/r/xok+7t3rWTOSI1PfJyotybQLFDPpJa fpParXQvKrEUZyQaajEXFScCAEjxA7URAwAA Archived-At: Subject: Re: [sipcore] session-timer fix 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, 28 Mar 2018 15:57:20 -0000 On 3/28/18 7:56 AM, Christer Holmberg wrote: > > Hi, > > Ok, I checked some old e-mails, and had a chat with the internal people > that informed me about the problem. > > The UPDATE request with refresher=uas is *NOT* the problem. They have the > same assumption as Paul, Jonathan etc - the value is indicated per > transaction. So, UPDATE with refresher=uas is ok. My apologies for mixing > that up. > > It¹s the UPDATE 200 OK response, where the proxy inserts refresher=uac, > that causes the problem. > > So, one alternative would be to allow UPDATE requests/responses sent while > the s-t negotiation is ongoing are handled as defined in RFC 4028, but > that the refresher value must not be changed. > > In the case below, that means that the UA needs to include s-t information > in the UPDATE response (message #7). That seems like a simpler and cleaner fix, at least for this case. To go that way we need to consider other cases. In particular, is the UA *required* to include the s-t stuff in the UPDATE if it supports s-t? What if the UA had omitted the refresher in the INVITE? Presumably then the AS chooses and puts its choice in the UPDATE. And once s-e in invite has been responded to with an s-e in an UPDATE, does that finish the negotiation? Then do subsequent messages within the invite transaction and embedded UPDATES repeat the agreed upon result? Or can they do the negotiation over? Thanks, Paul > Regards, > > Christer > > > > > > > On 23/03/18 22:48, "sipcore on behalf of Christer Holmberg" > > wrote: > >> Hi Paul, >> >> You say (and it was indicated in the meeting): >> >> "I think it is, since the uac/uas roles are relative to >> the direction of the individual request," >> >> Assuming that the AS and UA are implemented that way, the problem still >> occurs when the AS receives (8), where the refresher >> >> >> >> >>> Here is the primary use case flow that has been reported as the >>> motivating case for the draft. (I've reformatted it for ease in typing.) >>> >>> 1) UA->Proxy: INVITE/SE:uac >>> 2) Proxy->AS: INVITE/SE:uac >>> 3) AS->Proxy: 18x/no-SE >>> 4) Proxy->UA: 18x/no-SE >>> 5) AS->Proxy: UPDATE/SE:uas >>> 6) Proxy->UA: UPDATE/SE:uas >>> 7) UA->Proxy: 200(UPDATE)/no-SE >>> 8) Proxy->AS: 200(UPDATE)/SE:uac >>> 9) AS->Proxy: 480(INVITE) >>> 10) Proxy->UA: 480(INVITE) >>> >>> Some observations on the above: >>> >>> - in (5) the AS includes SE in the UPDATE, while in (7) the UA >>> doesn't include SE in the response to the UPDATE. This seems >>> to reflect a difference of opinion by the implementors of >>> the UA and AS about what 4028 expects in this situation. >>> This ambiguity needs to be resolved, and will require changes >>> in some implementations. >> >> Correct. This is a case where UPDATE is received while the S-T >> negotiation is still ongoing. >> >>> - The 480 in (9) is caused by the AS objecting to the "uac" >>> in (8) because it is in conflict with the "uas" in (5). >>> This in turn is caused by the proxy including the "uac" >>> in (8) because it is following the rules and thinks that >>> the UA doesn't support S-T. This of course isn't the >>> situation. >> >> Shouldn't the proxy know that the UA supports S-T, due to (1)? >> >>> - There has been some discussion about whether the "uas" >>> value in (5) is consistent with the "uac" value in (1). >>> I think it is, since the uac/uas roles are relative to >>> the direction of the individual request, and (5) is >>> going in the opposite direction of (1). >> >> Let's assume it is like that. >> >>> But this >>> doesn't seem to affect the rest of the analysis. >>> If the refresher in the UPDATE was inconsistent with >>> that in the INVITE then I would expect the UA to send >>> an error response to the UPDATE. >>> >>> ISTM that at least part of the fix for this must be to fix the >>> ambiguity about whether SE is to be included in an >>> UPDATE and its response that are embedded in an INVITE transaction. The >>> existing draft does address this one way. >> >> Yes. >> >>> Another way to address it would be to require SE to be included in both >>> the UPDATE and its response, in a way >>> consistent with what was in the INVITE and will eventually be in the >>> response to the INVITE. >> >> Yes. >> >>> A much different way would be to require that the timer negotiation in >>> an INVITE be completed in the first reliable >>> response to the INVITE, either 2xx or reliable 1xx. Then any UPDATE >>> that followed within the transaction would >>> presumably start a new timer negotiation. >> >> Yes. >> >>> I'll also observe that this entire discussion has focused on the >>> negotiation of the refresher. But there is a comparable >>> issue around negotiating the duration of the timer. That ought to be >>> sorted out as part of the same fix. >> >> Yes. >> >> Regards, >> >> Christer >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore > > From nobody Wed Mar 28 10:13:39 2018 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 279F41243F6 for ; Wed, 28 Mar 2018 10:13:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 l6t1435B8OUR for ; Wed, 28 Mar 2018 10:13:35 -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 84AFD1243F3 for ; Wed, 28 Mar 2018 10:13:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1522257213; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=fPoq9TpfI/uAUICYR6n1PRCnuWPRwahLs1h8Xw/B540=; b=hIwwnuK99OvaHwD2tZqyZb+dp3P3rVODi4mUZ5N8u1FPEDVPcx2TOKppAgnPDoAU 2N/GHwu3k47Hb7oih3FLOJEEAx/uZgJKCljQuAJ8EuQLJp1mOYplZO7Ac7sp0duC b/omyPKD+hTETDnYjDvN+QkWRNwUuKgnU+UGW68EtQw=; X-AuditID: c1b4fb25-d69a99c000004653-b8-5abbcd3ddc68 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id CD.28.18003.D3DCBBA5; Wed, 28 Mar 2018 19:13:33 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.115]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0382.000; Wed, 28 Mar 2018 19:13:17 +0200 From: Christer Holmberg To: Paul Kyzivat , SIPCORE Thread-Topic: [sipcore] session-timer fix Thread-Index: AQHTwfCeyHYsx4XVTkSHOLQKDcONKqPdSEtwgAhcbACAABDAgIAANGeA Date: Wed, 28 Mar 2018 17:13:17 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B72E37EC9@ESESSMB109.ericsson.se> References: <949dba9e-33b7-66b9-1b16-d25902f65367@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B72E06C39@ESESSMB102.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.164] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyM2K7t67t2d1RBtOfa1ms2HCA1eLrj01s Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAlfG+44VTAWP7CpOL3rM2MA4xbaLkZNDQsBE 4vOJdexdjFwcQgJHGCX6J65gB0kICSxhlFiymbuLkYODTcBCovufNkhYRMBFYkn3EWYQW1hA Q2Lr60esEHFNiT+zNzBD2G4SL7bcB7NZBFQlNhzcwAIyhlfAV6J7vhPEqteMEttnPQGr4RRw kNgzYwLYHEYBMYnvp9YwgdjMAuISt57MZ4K4U0BiyZ7zzBC2qMTLx/9YIWwlibNfprCBzGcG umH9Ln2IVkWJKd0PwT7hFRCUODnzCcsERpFZSKbOQuiYhaRjFpKOBYwsqxhFi1OLk3LTjYz1 Uosyk4uL8/P08lJLNjECI+Hglt+qOxgvv3E8xCjAwajEw5u6eneUEGtiWXFl7iFGCQ5mJRHe 9xpAId6UxMqq1KL8+KLSnNTiQ4zSHCxK4rwPzTdHCQmkJ5akZqemFqQWwWSZODilGhj5GlP6 ljL0zorcsbT5ZgJnxKWlkWynth6SiK6I712YfCvaNKTko1Cfz3uDUz8OaF/6nFhRwr05b06r qF/uqZj0yB1fK/q+6a3WWNhVZ9hXGTXdjNcsUOZC6aoPHP9qLr4sWn9r3nbVGXFh/zZZnTBt u7xp3vP7co8y/rKovVGatslAtaD8/TElluKMREMt5qLiRACPb3MmgAIAAA== Archived-At: Subject: Re: [sipcore] session-timer fix 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, 28 Mar 2018 17:13:38 -0000 SGksDQoNCj4+IE9rLCBJIGNoZWNrZWQgc29tZSBvbGQgZS1tYWlscywgYW5kIGhhZCBhIGNoYXQg d2l0aCB0aGUgaW50ZXJuYWwgDQo+PiBwZW9wbGUgdGhhdCBpbmZvcm1lZCBtZSBhYm91dCB0aGUg cHJvYmxlbS4NCj4+IA0KPj4gVGhlIFVQREFURSByZXF1ZXN0IHdpdGggcmVmcmVzaGVyPXVhcyBp cyAqTk9UKiB0aGUgcHJvYmxlbS4gVGhleSBoYXZlIA0KPj4gdGhlIHNhbWUgYXNzdW1wdGlvbiBh cyBQYXVsLCBKb25hdGhhbiBldGMgLSB0aGUgdmFsdWUgaXMgaW5kaWNhdGVkIHBlciANCj4+IHRy YW5zYWN0aW9uLiBTbywgVVBEQVRFIHdpdGggcmVmcmVzaGVyPXVhcyBpcyBvay4gTXkgYXBvbG9n aWVzIGZvciANCj4+IG1peGluZyB0aGF0IHVwLg0KPj4gDQo+PiBJdMK5cyB0aGUgVVBEQVRFIDIw MCBPSyByZXNwb25zZSwgd2hlcmUgdGhlIHByb3h5IGluc2VydHMgDQo+PiByZWZyZXNoZXI9dWFj LCB0aGF0IGNhdXNlcyB0aGUgcHJvYmxlbS4NCj4+IA0KPj4gU28sIG9uZSBhbHRlcm5hdGl2ZSB3 b3VsZCBiZSB0byBhbGxvdyBVUERBVEUgcmVxdWVzdHMvcmVzcG9uc2VzIHNlbnQgDQo+PiB3aGls ZSB0aGUgcy10IG5lZ290aWF0aW9uIGlzIG9uZ29pbmcgYXJlIGhhbmRsZWQgYXMgZGVmaW5lZCBp biBSRkMgDQo+PiA0MDI4LCBidXQgdGhhdCB0aGUgcmVmcmVzaGVyIHZhbHVlIG11c3Qgbm90IGJl IGNoYW5nZWQuDQo+PiANCj4+IEluIHRoZSBjYXNlIGJlbG93LCB0aGF0IG1lYW5zIHRoYXQgdGhl IFVBIG5lZWRzIHRvIGluY2x1ZGUgcy10IA0KPj4gaW5mb3JtYXRpb24gaW4gdGhlIFVQREFURSBy ZXNwb25zZSAobWVzc2FnZSAjNykuDQo+DQo+IFRoYXQgc2VlbXMgbGlrZSBhIHNpbXBsZXIgYW5k IGNsZWFuZXIgZml4LCBhdCBsZWFzdCBmb3IgdGhpcyBjYXNlLg0KPg0KPiBUbyBnbyB0aGF0IHdh eSB3ZSBuZWVkIHRvIGNvbnNpZGVyIG90aGVyIGNhc2VzLg0KPg0KPiBJbiBwYXJ0aWN1bGFyLCBp cyB0aGUgVUEgKnJlcXVpcmVkKiB0byBpbmNsdWRlIHRoZSBzLXQgc3R1ZmYgaW4gdGhlIFVQREFU RSBpZiBpdCBzdXBwb3J0cyBzLXQ/DQoNCk1pbi1TRSBpcyBjdXJyZW50bHkgTVVTVC4NCg0KU2Vz c2lvbi1FeHBpcmVzIGlzIGN1cnJlbnRseSBTSE9VTEQuIEkgZ3Vlc3Mgd2UgY291bGQgY2hhbmdl IHRoYXQgdG8gTVVTVC4NCg0KPiBXaGF0IGlmIHRoZSBVQSBoYWQgb21pdHRlZCB0aGUgcmVmcmVz aGVyIGluIHRoZSBJTlZJVEU/IFByZXN1bWFibHkgdGhlbiB0aGUgQVMgY2hvb3NlcyBhbmQgcHV0 cyBpdHMgY2hvaWNlIGluIHRoZSBVUERBVEUuDQo+DQo+IEFuZCBvbmNlIHMtZSBpbiBpbnZpdGUg aGFzIGJlZW4gcmVzcG9uZGVkIHRvIHdpdGggYW4gcy1lIGluIGFuIFVQREFURSwgZG9lcyB0aGF0 IGZpbmlzaCB0aGUgbmVnb3RpYXRpb24/DQoNClllcy4gVGhlIElOVklURSB0cmFuc2FjdGlvbiBp dHNlbGYgZG9lcyBub3QgbWF0dGVyIC0gaXQgZGVwZW5kcyBvbiB3aGV0aGVyIHMtZSBpcyBuZWdv dGlhdGVkIHdpdGhpbiB0aGUgSU5WSVRFIHRyYW5zYWN0aW9uIG9yIG5vdCB0aGF0IG1hdHRlcnMu IElmIHRoZXJlIGlzIG5vIHMtZSBuZWdvdGlhdGlvbiBpbiB0aGUgSU5WSVRFIHRyYW5zYWN0aW9u LCB0aGUgVVBEQVRFIGlzIHRyZWF0ZWQgYXMgYW55IG1pZC1kaWFsb2cgcmVxdWVzdCBhcyBmYXIg YXMgcy1lIGlzIGNvbmNlcm5lZC4NCg0KPiBUaGVuIGRvIHN1YnNlcXVlbnQgbWVzc2FnZXMgd2l0 aGluIHRoZSBpbnZpdGUgdHJhbnNhY3Rpb24gYW5kIGVtYmVkZGVkIFVQREFURVMgcmVwZWF0IHRo ZSBhZ3JlZWQgdXBvbiByZXN1bHQ/IA0KPiBPciBjYW4gdGhleSBkbyB0aGUgbmVnb3RpYXRpb24g b3Zlcj8NCg0KU2luY2UgdGhlcmUgaXMgbm8gb25nb2luZyBzLWUgbmVnb3RpYXRpb24sIEkgc2Vl IG5vIHJlYXNvbiB3aHkgdGhleSBjYW4ndC4NCg0KSW4gZ2VuZXJhbCwgdW5sZXNzIHN1Y2ggdGV4 dCBhbHJlYWR5IGV4aXN0LCBJIHRoaW5rIHdlIHNob3VsZCByZWNvbW1lbmQgYWdhaW5zdCByZS1u ZWdvdGlhdGluZyAsIHVubGVzcyB0aGVyZSBpcyBhIGdvb2QgcmVhc29uIGZvciBpdC4NCg0KUmVn YXJkcywNCg0KQ2hyaXN0ZXINCg0KDQoNCj4gT24gMjMvMDMvMTggMjI6NDgsICJzaXBjb3JlIG9u IGJlaGFsZiBvZiBDaHJpc3RlciBIb2xtYmVyZyINCj4gPHNpcGNvcmUtYm91bmNlc0BpZXRmLm9y ZyBvbiBiZWhhbGYgb2YgY2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPg0KPiB3cm90ZToN Cj4gDQo+PiBIaSBQYXVsLA0KPj4NCj4+IFlvdSBzYXkgKGFuZCBpdCB3YXMgaW5kaWNhdGVkIGlu IHRoZSBtZWV0aW5nKToNCj4+DQo+PiAgICAiSSB0aGluayBpdCBpcywgc2luY2UgdGhlIHVhYy91 YXMgcm9sZXMgYXJlIHJlbGF0aXZlIHRvDQo+PiAgICB0aGUgZGlyZWN0aW9uIG9mIHRoZSBpbmRp dmlkdWFsIHJlcXVlc3QsIg0KPj4NCj4+IEFzc3VtaW5nIHRoYXQgdGhlIEFTIGFuZCBVQSBhcmUg aW1wbGVtZW50ZWQgdGhhdCB3YXksIHRoZSBwcm9ibGVtIA0KPj4gc3RpbGwgb2NjdXJzIHdoZW4g dGhlIEFTIHJlY2VpdmVzICg4KSwgd2hlcmUgdGhlIHJlZnJlc2hlcg0KPj4NCj4+DQo+Pg0KPj4N Cj4+PiBIZXJlIGlzIHRoZSBwcmltYXJ5IHVzZSBjYXNlIGZsb3cgdGhhdCBoYXMgYmVlbiByZXBv cnRlZCBhcyB0aGUgDQo+Pj4gbW90aXZhdGluZyBjYXNlIGZvciB0aGUgZHJhZnQuIChJJ3ZlIHJl Zm9ybWF0dGVkIGl0IGZvciBlYXNlIGluIA0KPj4+IHR5cGluZy4pDQo+Pj4NCj4+PiAgIDEpIFVB LT5Qcm94eTogSU5WSVRFL1NFOnVhYw0KPj4+ICAgMikgUHJveHktPkFTOiBJTlZJVEUvU0U6dWFj DQo+Pj4gICAzKSBBUy0+UHJveHk6IDE4eC9uby1TRQ0KPj4+ICAgNCkgUHJveHktPlVBOiAxOHgv bm8tU0UNCj4+PiAgIDUpIEFTLT5Qcm94eTogVVBEQVRFL1NFOnVhcw0KPj4+ICAgNikgUHJveHkt PlVBOiBVUERBVEUvU0U6dWFzDQo+Pj4gICA3KSBVQS0+UHJveHk6IDIwMChVUERBVEUpL25vLVNF DQo+Pj4gICA4KSBQcm94eS0+QVM6IDIwMChVUERBVEUpL1NFOnVhYw0KPj4+ICAgOSkgQVMtPlBy b3h5OiA0ODAoSU5WSVRFKQ0KPj4+IDEwKSBQcm94eS0+VUE6IDQ4MChJTlZJVEUpDQo+Pj4NCj4+ PiBTb21lIG9ic2VydmF0aW9ucyBvbiB0aGUgYWJvdmU6DQo+Pj4NCj4+PiAtIGluICg1KSB0aGUg QVMgaW5jbHVkZXMgU0UgaW4gdGhlIFVQREFURSwgd2hpbGUgaW4gKDcpIHRoZSBVQQ0KPj4+ICAg IGRvZXNuJ3QgaW5jbHVkZSBTRSBpbiB0aGUgcmVzcG9uc2UgdG8gdGhlIFVQREFURS4gVGhpcyBz ZWVtcw0KPj4+ICAgIHRvIHJlZmxlY3QgYSBkaWZmZXJlbmNlIG9mIG9waW5pb24gYnkgdGhlIGlt cGxlbWVudG9ycyBvZg0KPj4+ICAgIHRoZSBVQSBhbmQgQVMgYWJvdXQgd2hhdCA0MDI4IGV4cGVj dHMgaW4gdGhpcyBzaXR1YXRpb24uDQo+Pj4gICAgVGhpcyBhbWJpZ3VpdHkgbmVlZHMgdG8gYmUg cmVzb2x2ZWQsIGFuZCB3aWxsIHJlcXVpcmUgY2hhbmdlcw0KPj4+ICAgIGluIHNvbWUgaW1wbGVt ZW50YXRpb25zLg0KPj4NCj4+IENvcnJlY3QuIFRoaXMgaXMgYSBjYXNlIHdoZXJlIFVQREFURSBp cyByZWNlaXZlZCB3aGlsZSB0aGUgUy1UIA0KPj4gbmVnb3RpYXRpb24gaXMgc3RpbGwgb25nb2lu Zy4NCj4+DQo+Pj4gLSBUaGUgNDgwIGluICg5KSBpcyBjYXVzZWQgYnkgdGhlIEFTIG9iamVjdGlu ZyB0byB0aGUgInVhYyINCj4+PiAgICBpbiAoOCkgYmVjYXVzZSBpdCBpcyBpbiBjb25mbGljdCB3 aXRoIHRoZSAidWFzIiBpbiAoNSkuDQo+Pj4gICAgVGhpcyBpbiB0dXJuIGlzIGNhdXNlZCBieSB0 aGUgcHJveHkgaW5jbHVkaW5nIHRoZSAidWFjIg0KPj4+ICAgIGluICg4KSBiZWNhdXNlIGl0IGlz IGZvbGxvd2luZyB0aGUgcnVsZXMgYW5kIHRoaW5rcyB0aGF0DQo+Pj4gICAgdGhlIFVBIGRvZXNu J3Qgc3VwcG9ydCBTLVQuIFRoaXMgb2YgY291cnNlIGlzbid0IHRoZQ0KPj4+ICAgIHNpdHVhdGlv bi4NCj4+DQo+PiBTaG91bGRuJ3QgdGhlIHByb3h5IGtub3cgdGhhdCB0aGUgVUEgc3VwcG9ydHMg Uy1ULCBkdWUgdG8gKDEpPw0KPj4NCj4+PiAtIFRoZXJlIGhhcyBiZWVuIHNvbWUgZGlzY3Vzc2lv biBhYm91dCB3aGV0aGVyIHRoZSAidWFzIg0KPj4+ICAgIHZhbHVlIGluICg1KSBpcyBjb25zaXN0 ZW50IHdpdGggdGhlICJ1YWMiIHZhbHVlIGluICgxKS4NCj4+PiAgICBJIHRoaW5rIGl0IGlzLCBz aW5jZSB0aGUgdWFjL3VhcyByb2xlcyBhcmUgcmVsYXRpdmUgdG8NCj4+PiAgICB0aGUgZGlyZWN0 aW9uIG9mIHRoZSBpbmRpdmlkdWFsIHJlcXVlc3QsIGFuZCAoNSkgaXMNCj4+PiAgICBnb2luZyBp biB0aGUgb3Bwb3NpdGUgZGlyZWN0aW9uIG9mICgxKS4NCj4+DQo+PiBMZXQncyBhc3N1bWUgaXQg aXMgbGlrZSB0aGF0Lg0KPj4NCj4+PiBCdXQgdGhpcw0KPj4+ICAgIGRvZXNuJ3Qgc2VlbSB0byBh ZmZlY3QgdGhlIHJlc3Qgb2YgdGhlIGFuYWx5c2lzLg0KPj4+ICAgIElmIHRoZSByZWZyZXNoZXIg aW4gdGhlIFVQREFURSB3YXMgaW5jb25zaXN0ZW50IHdpdGgNCj4+PiAgICB0aGF0IGluIHRoZSBJ TlZJVEUgdGhlbiBJIHdvdWxkIGV4cGVjdCB0aGUgVUEgdG8gc2VuZA0KPj4+ICAgIGFuIGVycm9y IHJlc3BvbnNlIHRvIHRoZSBVUERBVEUuDQo+Pj4NCj4+PiBJU1RNIHRoYXQgYXQgbGVhc3QgcGFy dCBvZiB0aGUgZml4IGZvciB0aGlzIG11c3QgYmUgdG8gZml4IHRoZSANCj4+PiBhbWJpZ3VpdHkg YWJvdXQgd2hldGhlciBTRSBpcyB0byBiZSBpbmNsdWRlZCBpbiBhbiBVUERBVEUgYW5kIGl0cyAN Cj4+PiByZXNwb25zZSB0aGF0IGFyZSBlbWJlZGRlZCBpbiBhbiBJTlZJVEUgdHJhbnNhY3Rpb24u IFRoZSBleGlzdGluZyANCj4+PiBkcmFmdCBkb2VzIGFkZHJlc3MgdGhpcyBvbmUgd2F5Lg0KPj4N Cj4+IFllcy4NCj4+DQo+Pj4gQW5vdGhlciB3YXkgdG8gYWRkcmVzcyBpdCB3b3VsZCBiZSB0byBy ZXF1aXJlIFNFIHRvIGJlIGluY2x1ZGVkIGluIA0KPj4+IGJvdGggdGhlIFVQREFURSBhbmQgaXRz IHJlc3BvbnNlLCBpbiBhIHdheSBjb25zaXN0ZW50IHdpdGggd2hhdCB3YXMgDQo+Pj4gaW4gdGhl IElOVklURSBhbmQgd2lsbCBldmVudHVhbGx5IGJlIGluIHRoZSByZXNwb25zZSB0byB0aGUgSU5W SVRFLg0KPj4NCj4+IFllcy4NCj4+DQo+Pj4gQSBtdWNoIGRpZmZlcmVudCB3YXkgd291bGQgYmUg dG8gcmVxdWlyZSB0aGF0IHRoZSB0aW1lciBuZWdvdGlhdGlvbiANCj4+PiBpbiBhbiBJTlZJVEUg YmUgY29tcGxldGVkIGluIHRoZSBmaXJzdCByZWxpYWJsZSByZXNwb25zZSB0byB0aGUgDQo+Pj4g SU5WSVRFLCBlaXRoZXIgMnh4IG9yIHJlbGlhYmxlIDF4eC4gVGhlbiBhbnkgVVBEQVRFIHRoYXQg Zm9sbG93ZWQgDQo+Pj4gd2l0aGluIHRoZSB0cmFuc2FjdGlvbiB3b3VsZCBwcmVzdW1hYmx5IHN0 YXJ0IGEgbmV3IHRpbWVyIA0KPj4+IG5lZ290aWF0aW9uLg0KPj4NCj4+IFllcy4NCj4+DQo+Pj4g SSdsbCBhbHNvIG9ic2VydmUgdGhhdCB0aGlzIGVudGlyZSBkaXNjdXNzaW9uIGhhcyBmb2N1c2Vk IG9uIHRoZSANCj4+PiBuZWdvdGlhdGlvbiBvZiB0aGUgcmVmcmVzaGVyLiBCdXQgdGhlcmUgaXMg YSBjb21wYXJhYmxlIGlzc3VlIGFyb3VuZCANCj4+PiBuZWdvdGlhdGluZyB0aGUgZHVyYXRpb24g b2YgdGhlIHRpbWVyLiBUaGF0IG91Z2h0IHRvIGJlIHNvcnRlZCBvdXQgDQo+Pj4gYXMgcGFydCBv ZiB0aGUgc2FtZSBmaXguDQo+Pg0KPj4gWWVzLg0KPj4NCj4+IFJlZ2FyZHMsDQo+Pg0KPj4gQ2hy aXN0ZXINCj4+DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPj4gc2lwY29yZSBtYWlsaW5nIGxpc3QNCj4+IHNpcGNvcmVAaWV0Zi5vcmcNCj4+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZQ0KPiANCj4gDQoNCg== From nobody Wed Mar 28 10:43:06 2018 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 05283126C89 for ; Wed, 28 Mar 2018 10:43:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 3EEZWLmQ1ZSx for ; Wed, 28 Mar 2018 10:43:01 -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 47C1B1243F3 for ; Wed, 28 Mar 2018 10:43:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1522258979; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=4m9F9wEKKoX3Y6QtCGPLWyvyR0wKX7AflvADe5dgGn0=; b=TNrioKspT+eCfHvRLZL7QS21LTxrqlppoaYKLw7fgveU47wgnO7VEu3L36FTMkGN 2+TKs0WnGt/eO9I3IPkK0XLOPWdc4hCGJh4qiJU8EsVqBzkCBWcE+QYxytQveoXc TpTsZLPQqd3KbvEyMi35GgCsHoDOhvWKepexfxh00gA=; X-AuditID: c1b4fb2d-6dc359c00000236d-2b-5abbd423dece Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 04.2E.09069.324DBBA5; Wed, 28 Mar 2018 19:42:59 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.115]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0382.000; Wed, 28 Mar 2018 19:42:33 +0200 From: Christer Holmberg To: "marianne.mohali@orange.com" , "Asveren, Tolga" , "sipcore@ietf.org" Thread-Topic: WGLC: draft-ietf-sipcore-originating-cdiv-parameter Thread-Index: AdO8mvHNh2Fu7WwWT5iDJ4VxNB0YgwAP3GCgAArG/7AABt3bAAADWXtwAl77MaAABFtcoA== Date: Wed, 28 Mar 2018 17:42:32 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B72E37FC9@ESESSMB109.ericsson.se> References: <24496_1521199612_5AABA9FC_24496_87_1_8B970F90C584EA4E97D5BAAC9172DBB81D70AC30@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <11272_1521209907_5AABD233_11272_147_2_8B970F90C584EA4E97D5BAAC9172DBB81D70B5E7@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <21553_1522252002_5ABBB8E2_21553_183_1_8B970F90C584EA4E97D5BAAC9172DBB849C9699E@OPEXCLILMA4.corporate.adroot.infra.ftgroup> In-Reply-To: <21553_1522252002_5ABBB8E2_21553_183_1_8B970F90C584EA4E97D5BAAC9172DBB849C9699E@OPEXCLILMA4.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.164] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUyM2K7tK7yld1RBtuWS1psa97HZPH1xyY2 i/XLv7E7MHssWfKTyaPl2Uk2jz1zJjEGMEdx2aSk5mSWpRbp2yVwZbS3zWMraMmpWHnpL2sD 44LMLkYODgkBE4mG65FdjJwcQgJHGCVuvXXrYuQCspcwSqy+/p4JpIZNwEKi+582SFxEoIdR 4s3JHiaQBmEBB4lrPacYQWwRAUeJ5nc/mUHqRQTCJKav8AAJswioSsyf38YGYvMK+Epcbz3A BDH/N4vEpdu3mUEcToEORok9P2ewgFQxCohJfD+1BmwBs4C4xK0n88FsCQEBiSV7zjND2KIS Lx//Y4WwlSTOfpnCBrKYWUBTYv0ufYhWRYkp3Q/ZIRYLSpyc+YRlAqPILCRTZyF0zELSMQtJ xwJGllWMosWpxcW56UbGeqlFmcnFxfl5enmpJZsYgfFxcMtv3R2Mq187HmIU4GBU4uHVW707 Sog1say4MvcQowQHs5II73sNoBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXHek568UUIC6Yklqdmp qQWpRTBZJg5OqQbGaTvvqnpU7TEPWf8w+c77ku7pUoZzMz/JXDzMsv76BN+TOW8ExCZLSbOd Pe1/OebnQ8FLd7J+69oqr6rUt9pTbesX2fJPK893ev2CKIE79l9yfru6Ly0wLv6t+OOn1u6N zz7GnHxS8SIlorh3k/nDC98P2+Ul7o/3+c479fDWf0f3Wn2e3DRRQomlOCPRUIu5qDgRAIB6 awaLAgAA Archived-At: Subject: Re: [sipcore] WGLC: 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, 28 Mar 2018 17:43:05 -0000 SGksDQoNCk15IGdlbmVyYWwgb3Bpbmlvbiwgbm90IHNwZWNpZmljIHRvIHRoaXMgZHJhZnQsIGlz IHRoYXQgd2Ugc2hvdWxkIGF2b2lkIGFkZGluZyBuZXcgZnVuY3Rpb25hbGl0eSBhdCBXR0xDIC0g dW5sZXNzIGl0IGlzIG5lZWRlZCBmb3IgdGhlIGV4aXN0aW5nIGZ1bmN0aW9uYWxpdHkuDQoNCklu IHRoaXMgY2FzZSwgb25jZSBvcmlkLWRpdiBoYXMgYmVlbiBwdWJsaXNoZWQsIEkgYXNzdW1lIGl0 IHdvdWxkIG5vdCBiZSB2ZXJ5IGRpZmZpY3VsdCB0byBwcm9kdWNlIGEgc2VwYXJhdGUgdGVybS1k aXYgZHJhZnQsIGlmIHRoZXJlIGlzIGludGVyZXN0Lg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0K DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBzaXBjb3JlIFttYWlsdG86c2lw Y29yZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgbWFyaWFubmUubW9oYWxpQG9yYW5n ZS5jb20NClNlbnQ6IDI4IE1hcmNoIDIwMTggMTc6NDcNClRvOiBBc3ZlcmVuLCBUb2xnYSA8dGFz dmVyZW5AcmJibi5jb20+OyBzaXBjb3JlQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3NpcGNvcmVd IFdHTEM6IGRyYWZ0LWlldGYtc2lwY29yZS1vcmlnaW5hdGluZy1jZGl2LXBhcmFtZXRlcg0KDQpI aSBUb2xnYSwgYWxsLA0KDQpSZWdhcmRpbmcgeW91ciBsYXN0IGNvbW1lbnQgYW5kIGFmdGVyIGEg c2Vjb25kIHRob3VnaHQsIEkgZG9uJ3Qga25vdyBpZiB0aGVyZSBpcyBhIG5lZWQgZm9yIHRoZSAi dGVybS1jZGl2IiBjYXNlIHlvdSBwcm9wb3NlIGV4Y2VwdCB0byBiZSBzeW1tZXRyaWNhbC4gDQpJ IHdvdWxkIGxpa2UgdG8gaGF2ZSBtb3JlIGZlZWRiYWNrIGJlZm9yZSBhZGRpbmcgYSB1c2UgY2Fz ZSwgY2hhbmdpbmcgdGhlIG5hbWUgYW5kIHNjb3BlIG9mIHRoZSBkcmFmdCB3aGlsZSBpdCBpcyBu b3cgdW5kZXIgd29ya2luZyBncm91cCBsYXN0IGNhbGwgc3RhdHVzLiANClRoZSBuYW1lIG9mIHRo ZSBkcmFmdCBpcyAib3JpZ2luYXRpbmctY2RpdiIgYW5kIGl0cyBtb3RpdmF0aW9uIGZyb20gdGhl IGJlZ2lubmluZyB3YXMgdGhlICJvcmlnLWNkaXYiIHVzZSBjYXNlLg0KDQpCZXN0IHJlZ2FyZHMs DQpNYXJpYW5uZQ0KDQoNCkRlwqA6IHNpcGNvcmUgW21haWx0bzpzaXBjb3JlLWJvdW5jZXNAaWV0 Zi5vcmddIERlIGxhIHBhcnQgZGUgbWFyaWFubmUubW9oYWxpQG9yYW5nZS5jb20gRW52b3nDqcKg OiB2ZW5kcmVkaSAxNiBtYXJzIDIwMTggMTU6MTggw4DCoDogQXN2ZXJlbiwgVG9sZ2E7IHNpcGNv cmVAaWV0Zi5vcmcgT2JqZXTCoDogUmU6IFtzaXBjb3JlXSBXR0xDOiBkcmFmdC1pZXRmLXNpcGNv cmUtb3JpZ2luYXRpbmctY2Rpdi1wYXJhbWV0ZXINCg0KSXQgaXMgdHJ1ZSB0aGF0IHdlIGNvdWxk IGNvbnNpZGVyIHRoaXMg4oCcdGVybS1jZGl24oCdIGNhc2UgaW4gdGhlIEktRCB0byBoYXZlIGEg c3ltbWV0cmljIHZhbHVlIGV2ZW4gaWYgZm9yIG5vdyBubyDigJxuZWVk4oCdIGhhcyBiZWVuIGlk ZW50aWZpZWQuIA0KSSBjYW4gd29yayBvbiB0aGlzIGFkZGluZyB0byB0aGUgSS1ELg0KDQpBbnkg b3RoZXIgdmlld3Mgb24gaW50cm9kdWNpbmcgdGhlIHNlc3Npb24gY2FzZSDigJx0ZXJtLWNkaXbi gJ0gdG9vPw0KDQpCUiwNCk1hcmlhbm5lDQoNCkRlwqA6IEFzdmVyZW4sIFRvbGdhIFttYWlsdG86 dGFzdmVyZW5AcmJibi5jb21dIEVudm95w6nCoDogdmVuZHJlZGkgMTYgbWFycyAyMDE4IDEzOjI1 IMOAwqA6IE1PSEFMSSBNYXJpYW5uZSBJTVQvT0xOOyBzaXBjb3JlQGlldGYub3JnIE9iamV0wqA6 IFJFOiBXR0xDOiBkcmFmdC1pZXRmLXNpcGNvcmUtb3JpZ2luYXRpbmctY2Rpdi1wYXJhbWV0ZXIN Cg0KSGkgTWFyaWFubmUsDQoNClRoYW5rIHlvdSBmb3IgdGhlIGRldGFpbGVkIGV4cGxhbmF0aW9u IG9mIHRoZSBzZXJ2aWNlLiBZZXMsIHRoYXQgaXMgc29tZXRoaW5nIHVzZWQgdG9kYXkuIEJ1dCBo b3cgY291bGQgd2Uga25vdyB0aGF0IHRoZXJlIHdvdWxkbuKAmXQgYmUgYW55IHNlcnZpY2VzIHdo aWNoIHdvdWxkIGJlIHRyaWdnZXJlZC9ub3QgdHJpZ2dlcmVkIG9uIHRoZSBkaXZlcnRpbmcgcGFy dHkgYmFzZWQgb24gd2hldGhlciBpdCBpcyB0aGUgb3JpZ2luYWwgaW5pdGlhdG9yIG9mIHRoZSBj YWxsIG9yIGp1c3QgdGhlIGRpdmVydGVyPyBUaGF0IGl0IGlzIG5vdCBuZWVkZWQgdG9kYXkgLWJ5 IGEgY2VydGFpbiBkZXBsb3ltZW50IG1vZGVsLSwgb3IgdGhhdCB5b3UoYW5kIEkpIGFyZSBub3Qg YXdhcmUgb2YgaXQgZG9lcyBub3QgbmVjZXNzYXJpbHkgbWVhbiBpdCB3b3VsZG7igJl0L2lzIGFs cmVhZHkgdXNlZCBzb21ld2hlcmUgaW4gdGhlIHVuaXZlcnNlIG9mIHJlYWwgdGltZSBzZXNzaW9u cy4gDQoNClRoZSBzaGlwIGZvciBhIG1vcmUgZ2VuZXJpYyBmcmFtZXdvcmsgdG8gZmFjaWxpdGF0 ZSDigJxzY2VuYXJpbyBiYXNlZCBzZXJ2aWNlIGludm9jYXRpb24vaW50ZXJhY3Rpb27igJ0gbWF5 IGhhdmUgc2FpbGVkIGJ1dCBhdCBhIG1pbmltdW0gSSB3b3VsZCBzdWdnZXN0IGFkZGluZyDigJx0 ZXJtLWNkaXbigJ0gYXMgd2VsbC4NCg0KVGhhbmtzLA0KVG9sZ2ENCg0KRnJvbTogbWFyaWFubmUu bW9oYWxpQG9yYW5nZS5jb20gPG1hcmlhbm5lLm1vaGFsaUBvcmFuZ2UuY29tPg0KU2VudDogRnJp ZGF5LCBNYXJjaCAxNiwgMjAxOCA3OjI3IEFNDQpUbzogQXN2ZXJlbiwgVG9sZ2EgPHRhc3ZlcmVu QHJiYm4uY29tPjsgc2lwY29yZUBpZXRmLm9yZw0KU3ViamVjdDogUkU6IFdHTEM6IGRyYWZ0LWll dGYtc2lwY29yZS1vcmlnaW5hdGluZy1jZGl2LXBhcmFtZXRlcg0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpOT1RJQ0U6IFRoaXMgZW1haWwgd2FzIHJlY2VpdmVk IGZyb20gYW4gRVhURVJOQUwgc2VuZGVyIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCg0KSGkgVG9sZ2EsDQoNCkZpcnN0LCB0aGFuayB5b3UgZm9yIHRoZSByZXZpZXcg b2YgdGhlIGRyYWZ0Lg0KVG8gYW5zd2VyIHRvIHRoZSBxdWVzdGlvbiBpbiB5b3VyIGZpcnN0IGVt YWlsLCBvbmNlIGEgZGl2ZXJzaW9uIGhhcyBiZWVuIHByb2Nlc3NlZCwgdGhlIG91dGdvaW5nIGxl ZyB3aWxsIGdvIHRvIHRoZSBkaXZlcnNpb24gdGFyZ2V0IGJ1dCBiZWZvcmUgdGhhdCwgdGhlIHNl c3Npb24gY2FzZSBvZiB0aGUgc2VydmVkLXVzZXIgaGFzIGJlZW4gY2hhbmdlZCB3aXRoIHRoZSBm b2xsb3dpbmcgcXVlc3Rpb25zOiB3aG8gaXMgdGhlIG9yaWdpbmF0aW5nIHBhcnR5PyB0aGUgY2Fs bGVyIG9yIHRoZSBkaXZlcnRpbmcgdXNlcj8gRG9lcyBwcml2YWN5IG9mIHRoZSBkaXZlcnRpbmcg dXNlciBhcHBsaWVzPyBkbyB3ZSBuZWVkIHRvIGNoZWNrIHRoZSBiYXJyaW5nIHNlcnZpY2Ugb2Yg dGhlIGRpdmVydGluZyB1c2VyIGZvciBvdXRnb2luZyBjYWxscz8gT1RPSCwgdGhlIGNhbGxlciBy ZW1haW4gdGhlIHNhbWUgYW5kIGl0cyBvcmlnaW5hdGluZyBzZXJ2aWNlcyBzaG91bGQgc3RpbGwg YXBwbHkuIEZvciB0aGF0IHBhcnRpY3VsYXIgc2l0dWF0aW9uIHNvbWV3aGVyZSBiZXR3ZWVuIHRl cm1pbmF0aW5nIGFuZCBvcmlnaW5hdGluZywgdGhlIGRyYWZ0IHByb3Bvc2VzIHRvIGV4dGVuZCB0 aGUgUC1TZXJ2ZWQtdXNlci4gDQpBdCB0aGUgZGl2ZXJ0ZWQtdG8gdXNlciBsZXZlbCwgaXQgaXMg ZGlmZmVyZW50OiBJdCBtYXkgaW5kZWVkIGJlIHBvc3NpYmxlIHRvIHRyaWdnZXIgYSBzcGVjaWZp YyBzZXJ2aWNlIGZvciB0aGUgdGVybWluYXRpbmctYWZ0ZXItZGl2ZXJzaW9uIGJ1dCB0aGlzIGlz IG5vdCBhIG5ldyB0eXBlIHNlc3Npb24gY2FzZS4gQXQgdGhlIHRlcm1pbmF0aW5nIHNpZGUsIHRo ZSBzZXJ2ZWQgdXNlciByZW1haW5zIHRoZSB0ZXJtaW5hdGluZyB1c2VyIGFuZCBvbmx5IGl0cyB0 ZXJtaW5hdGluZyBzZXJ2aWNlcyBoYXZlIHRvIGJlIHRyaWdnZXJlZC4gT2YgY291cnNlLCB0ZXJt aW5hdGluZyBzZXJ2aWNlcyBiYXNlZCBvbiB0aGUgb3JpZ2luYXRpbmcgcGFydHkgaWRlbnRpdHkg YXJlIGFmZmVjdGVkIGJ5IHRoZSBjYWxsIGRpdmVyc2lvbiBzaW5jZSB3ZSBjYW4gZGlzY3VzcyBv biB3aG8gaXMgdGhlIG9yaWdpbmF0aW5nIHBhcnR5IGJ1dCB0aGlzIGlzIG1vcmUgYSBtYXR0ZXIg b2Ygc2VydmljZSBpbnRlcmFjdGlvbi4gVGhlIHNlcnZlZC11c2VyIGlzIHRoZSBkaXZlcnNpb24g dGFyZ2V0IGFuZCB0aGUgc2Vzc2lvbiBjYXNlIGlzIHRlcm1pbmF0aW5nIGFuZCBpdCB3aWxsIG5v dCBjaGFuZ2UgKGV4Y2VwdCBpZiB0aGVyZSBpcyBhbm90aGVyIGNhbGwgZGl2ZXJzaW9uIDspLiBK dXN0IHRvIGxldCB5b3Uga25vdywgdGhlcmUgaXMgYSBzZXJ2aWNlIHRvIHJlamVjdCBpbmNvbWlu ZyBmb3J3YXJkZWQgY2FsbHMgYW5kIHRoZSB0cmlnZ2VyIGZvciB0aGlzIHNwZWNpZmljIGtpbmQg b2YgYmFycmluZyBpcyB0aGUgcHJlc2VuY2Ugb2YgYSBkaXZlcnRpbmcgdXNlciBpZGVudGl0eSBp biB0aGUgaW5jb21pbmcgSU5WSVRFIHJlcXVlc3QuIEl0IGlzIGp1c3QgYSBjcml0ZXJpb24gKGFz IGZvciBhbGwgYmFycmluZyBzZXJ2aWNlcykuIA0KDQpBYm91dCB5b3VyIGNvbW1lbnQgb24gdGhl IHdheSBTSVAgaGVhZGVycyBhcmUgZXh0ZW5kZWQsIElNTywgcnVsZXMgZm9yIHN0YW5kYXJkaXph dGlvbiBwcm9jZXNzIG9mIFNJUCBhcmUgaGVyZSBmb3IgeWVhcnMgYW5kIGl0IGlzIG5vdCB0aGUg Z29vZCB0aW1lIHRvIGNoYW5nZSB0aGF0LiBUbyBiZSB0cmFuc3BhcmVudCwgdGhpcyBleHRlbnNp b24gd2FzIGZpcnN0IGRlZmluZWQgb25seSB3aXRoaW4gM0dQUCBzcGVjaWZpY2F0aW9uIGJlY2F1 c2UgdGhlcmUgd2FzIGEgc2VydmljZSBuZWVkIGJlaGluZC4gQmVjYXVzZSBpdCB3YXMgYW4gZXh0 ZW5zaW9uIG9mIGFuIFJGQyBhbmQgdGhlIHdhcyB0aGUgc3ludGF4IG9mIHRoZSBoZWFkZXIgaXMg ZGVzaWduZWQsIHRoZSBleHRlbnNpb24gaXMgdG8gYmUgZG9uZSBpbiBJRVRGLiBXZSBjYW4gZGlz Y3VzcyB0aGF0IGJ1dCB3ZSBhcmUgYXQgdGhlIGVuZCBvZiBTSVAgcHJvdG9jb2wgZXh0ZW5zaW9u IHByb2Nlc3MuLi4NCkZpbmFsbHksIFJGQzU1MDIgZGVmaW5lcyBhIOKAnHByaXZhdGXigJ0gKFAt ICkgaGVhZGVyIHNvIGl0IGlzIG5vdCBzdXJwcmlzaW5nIHRoYXQgaXRzIGV4dGVuc2lvbiBhcyBh IDNHUFAgZmxhdm9yIOKYug0KDQpCZXN0IHJlZ2FyZHMsDQpNYXJpYW5uZQ0KDQoNCkRlwqA6IHNp cGNvcmUgW21haWx0bzpzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgQXN2 ZXJlbiwgVG9sZ2EgRW52b3nDqcKgOiB2ZW5kcmVkaSAxNiBtYXJzIDIwMTggMDk6MDYgw4DCoDog c2lwY29yZUBpZXRmLm9yZyBPYmpldMKgOiBSZTogW3NpcGNvcmVdIFdHTEM6IGRyYWZ0LWlldGYt c2lwY29yZS1vcmlnaW5hdGluZy1jZGl2LXBhcmFtZXRlcg0KDQpTb21lIG1vcmUgbXVzaW5ncyBm cm9tIGNvbmNlcHR1YWwgcGVyc3BlY3RpdmU6DQoNClNJUCBwcm92aWRlcyBhIHRvb2xib3ggdG8g cHJvdmlkZSBzZXJ2aWNlcy4gQW5kIHllcywgdGhlcmUgaXMgc29tZSBzcGVjaWFsIChpZiBJIG1h eSBzYXkg4oCcZmF2b3JlZOKAnSkgc3RhdHVzIG9mIDNHUFAgd2hlbiBpdCBjb21lcyB0byBTSVAg c3RhbmRhcmRpemF0aW9uLiBPVE9ILCBkb2VzIHRoZSBhcHByb2FjaCB0YWtlbiBieSBSRkM1NTAy IGdvIGEgbGl0dGxlIGJpdCB0b28gZmFyIGluIHRlcm1zIG9mIG92ZXItZGVmaW5pbmcgdGhlIGdl bmVyaWMgU0lQIHRvb2xib3g/DQoNCkFuIGFsdGVybmF0aXZlIGNvdWxkIGJlIHRvIGRlZmluZSBh IGhlYWRlci9wYXJhbWV0ZXIgd2hpY2ggcmVmZXJzIHRvIGEg4oCcc2NlbmFyaW/igJ0gaW4gYW4g YWJzdHJhY3Qgd2F5ICh3aXRoIGEgZ2VuZXJpYyBzeW50YXgpIGFuZCBsZXQgb3RoZXIgc3RhbmRh cmRzIGZvcmEgZGVmaW5lIHRoZSB2YWx1ZXMgdGhleSB3b3VsZCBsaWtlIHRvIHVzZSBhbmQvb3Ig cmVseSBvbiBjb25maWd1cmF0aW9uIGFsaWdubWVudCBiZXR3ZWVuIHJlbGV2YW50IGVsZW1lbnRz LCBlLmcuIFMtQ1NDRi9IU1MvQVMuIENvbnNpZGVyaW5nIHdoZXJlIHdlIGFyZSByaWdodCBub3cg KHRoYXQgUkZDNTUwMiBpcyBhbHJlYWR5IHRoZXJlKSB0aGlzIGFwcHJvYWNoIHByYWN0aWNhbGx5 IHdvdWxkIG1lYW4gdGhhdCBkcmFmdC1pZXRmLXNpcGNvcmUtb3JpZ2luYXRpbmctY2Rpdi1wYXJh bWV0ZXIgaXMgbm90IGRlZmluZWQgYW5kIFAtU2VydmVkLVVzZXIgc2VydmVkLXVzZXItcGFybSBp cyBleHRlbmRlZCBieSBvdGhlcnMgYXMgbmVlZGVkIChhcyBpdCBhbGxvd3MgdGhhdCkuDQoNCk90 aGVyd2lzZSwgdGhlcmUgd291bGQvY291bGQgYmUgdGhlIG5lZWQgdG8ga2VlcCBhZGRpbmcgbmV3 IHZhbHVlcyBpbiBkaWZmZXJlbnQgSUVURiBzcGVjaWZpY2F0aW9ucyB0aGUgbW9yZSDigJxkZXBs b3ltZW50IG1vZGVsIHNwZWNpZmljIHVzZSBjYXNlc+KAnSBhcmUgbmVlZGVkL2Rpc2NvdmVyZWQv aW52ZW50ZWQuDQoNClRoYW5rcywNClRvbGdhDQpGcm9tOiBBc3ZlcmVuLCBUb2xnYQ0KU2VudDog VGh1cnNkYXksIE1hcmNoIDE1LCAyMDE4IDQ6MjMgUE0NClRvOiBzaXBjb3JlQGlldGYub3JnDQpT dWJqZWN0OiBXR0xDOiBkcmFmdC1pZXRmLXNpcGNvcmUtb3JpZ2luYXRpbmctY2Rpdi1wYXJhbWV0 ZXINCg0KSSByZXZpZXdlZCB0aGUgZHJhZnQgYW5kIGhhdmUgbm8gdGVjaG5pY2FsIGlzc3VlcyB3 aXRoIGl0IGV4Y2VwdCBvbmUgcXVlc3Rpb246DQoNCklzIGl0IGVudmlzaW9uZWQgdGhhdCB0aGVy ZSB3b3VsZC9jb3VsZCBiZSBhIG5lZWQgZm9yIHRlcm0tY2RpdiBhcyB3ZWxsIHRvIHRyaWdnZXIg YSBkaWZmZXJlbnQgc2VydmljZSBzZXQgaWYgdGhlIHRhcmdldCBpcyBkZXRlcm1pbmVkIGFmdGVy IGRpdmVyc2lvbj8gSXQgbWF5IGJlIGJldHRlciB0byBkZWZpbmUgaXQgbm93IHJhdGhlciB0aGFu IGhhdmluZyB5ZXQgYW5vdGhlciBkcmFmdCwgYXQgbGVhc3QgdG8gYmUgZnV0dXJlIHByb29mLg0K DQpUaGFua3MsDQpUb2xnYQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBq b2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMg b3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYyBwYXMgZXRyZSBkaWZmdXNlcywgZXhw bG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2Ug bWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlciBhIGwnZXhwZWRpdGV1ciBl dCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMg ZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLCBPcmFuZ2UgZGVj bGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVm b3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQoNClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1l bnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRo YXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7IHRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRl ZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KSWYgeW91IGhhdmUgcmVj ZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBk ZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQpBcyBlbWFpbHMgbWF5IGJl IGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVl biBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQpUaGFuayB5b3UuDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoN CkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGlu Zm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQg ZG9uYyBwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNh dGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBs ZSBzaWduYWxlciBhIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBp ZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJs ZXMgZCdhbHRlcmF0aW9uLCBPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBj ZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQoNClRo aXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBv ciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7IHRo ZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRo b3Jpc2F0aW9uLg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxl YXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0 YWNobWVudHMuDQpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxl IGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZp ZWQuDQpUaGFuayB5b3UuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpv aW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBv dSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jIHBhcyBldHJlIGRpZmZ1c2VzLCBleHBs b2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBt ZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyIGEgbCdleHBlZGl0ZXVyIGV0 IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBl bGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sIE9yYW5nZSBkZWNs aW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZv cm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCg0KVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVu dHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhh dCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsgdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVk LCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQpJZiB5b3UgaGF2ZSByZWNl aXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRl bGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCkFzIGVtYWlscyBtYXkgYmUg YWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVu IG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NClRoYW5rIHlvdS4NCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNpcGNvcmUgbWFpbGluZyBs aXN0DQpzaXBjb3JlQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NpcGNvcmUNCg== From nobody Wed Mar 28 13:06:24 2018 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 ACE9B126DC2 for ; Wed, 28 Mar 2018 13:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 sPVOfsDssEWs for ; Wed, 28 Mar 2018 13:06:21 -0700 (PDT) Received: from alum-mailsec-scanner-4.mit.edu (alum-mailsec-scanner-4.mit.edu [18.7.68.15]) by ietfa.amsl.com (Postfix) with ESMTP id DC04D120227 for ; Wed, 28 Mar 2018 13:06:20 -0700 (PDT) X-AuditID: 1207440f-557ff700000068d7-95-5abbf5b99e3a 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-4.mit.edu (Symantec Messaging Gateway) with SMTP id DB.8D.26839.9B5FBBA5; Wed, 28 Mar 2018 16:06:18 -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 w2SK6FwS022015 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 28 Mar 2018 16:06:16 -0400 To: Christer Holmberg , SIPCORE References: <949dba9e-33b7-66b9-1b16-d25902f65367@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B72E06C39@ESESSMB102.ericsson.se> <7594FB04B1934943A5C02806D1A2204B72E37EC9@ESESSMB109.ericsson.se> From: Paul Kyzivat Message-ID: <9d3fd31a-af1b-3328-23e6-05c11e7978f0@alum.mit.edu> Date: Wed, 28 Mar 2018 16:06:15 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B72E37EC9@ESESSMB109.ericsson.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPIsWRmVeSWpSXmKPExsUixO6iqLvr6+4og6n7dSwuzDzMaPH1xyY2 ByaPX1+vsnksWfKTKYApissmJTUnsyy1SN8ugStj75b9LAVLLCueXTvH3MD4VaeLkZNDQsBE Yv6NJ0xdjFwcQgI7mCTmL5vCCuE8ZJL4v+cXK0iVsICGxP61P9m6GDk4RASiJb4tFYGoWc8k 0T/nBiNIDZuAlsScQ/9ZQGxeAXuJZ7cPgMVZBFQlvuw5wg5iiwqkSVxq3soMUSMocXLmE7B6 TgE/iRcH5oLVMAuYSczb/JAZwhaXuPVkPhOELS/RvHU28wRG/llI2mchaZmFpGUWkpYFjCyr GOUSc0pzdXMTM3OKU5N1i5MT8/JSi3RN9HIzS/RSU0o3MUJClX8HY9d6mUOMAhyMSjy8Fot2 RwmxJpYVV+YeYpTkYFIS5T38BijEl5SfUpmRWJwRX1Sak1p8iFGCg1lJhPe9BlCONyWxsiq1 KB8mJc3BoiTOq75E3U9IID2xJDU7NbUgtQgmK8PBoSTBKwyMSSHBotT01Iq0zJwShDQTByfI cB6g4TM/gwwvLkjMLc5Mh8ifYjTmmPK8v4eZY8qSaT3MQix5+XmpUuK8q74AlQqAlGaU5sFN g6WbV4ziQM8J8yqCVPEAUxXcvFdAq5iAVm1r2gGyqiQRISXVwDjl02O5K9rJ4rMOVAaKL8+o tK6cco19J1vCzxWXkye6v1XO3/H2Knvf3xiravepyvlPfWdZpoW0CfAy1EutM5hx8tDT4gcc Lg5nC5bEWL4/KX9glXYyY3JY2JVr92S0GNeGvzstntyw43Fp7YvwhIqDVb95Z6w89Icnsldx lt+C1Ydl2j7YsiuxFGckGmoxFxUnAgCnVSPNEgMAAA== Archived-At: Subject: Re: [sipcore] session-timer fix 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, 28 Mar 2018 20:06:24 -0000 On 3/28/18 1:13 PM, Christer Holmberg wrote: > Hi, > >>> Ok, I checked some old e-mails, and had a chat with the internal >>> people that informed me about the problem. >>> >>> The UPDATE request with refresher=uas is *NOT* the problem. They have >>> the same assumption as Paul, Jonathan etc - the value is indicated per >>> transaction. So, UPDATE with refresher=uas is ok. My apologies for >>> mixing that up. >>> >>> It¹s the UPDATE 200 OK response, where the proxy inserts >>> refresher=uac, that causes the problem. >>> >>> So, one alternative would be to allow UPDATE requests/responses sent >>> while the s-t negotiation is ongoing are handled as defined in RFC >>> 4028, but that the refresher value must not be changed. >>> >>> In the case below, that means that the UA needs to include s-t >>> information in the UPDATE response (message #7). >> >> That seems like a simpler and cleaner fix, at least for this case. >> >> To go that way we need to consider other cases. >> >> In particular, is the UA *required* to include the s-t stuff in the UPDATE if it supports s-t? > > Min-SE is currently MUST. > > Session-Expires is currently SHOULD. I guess we could change that to MUST. > >> What if the UA had omitted the refresher in the INVITE? Presumably then the AS chooses and puts its choice in the UPDATE. >> >> And once s-e in invite has been responded to with an s-e in an UPDATE, does that finish the negotiation? > > Yes. The INVITE transaction itself does not matter - it depends on whether s-e is negotiated within the INVITE transaction or not that matters. If there is no s-e negotiation in the INVITE transaction, the UPDATE is treated as any mid-dialog request as far as s-e is concerned. > >> Then do subsequent messages within the invite transaction and embedded UPDATES repeat the agreed upon result? >> Or can they do the negotiation over? > > Since there is no ongoing s-e negotiation, I see no reason why they can't. > > In general, unless such text already exist, I think we should recommend against re-negotiating , unless there is a good reason for it. I guess I didn't make my concerns clear. ISTM we could use O/A rules as a *model* here: A negotiation initiated in an INVITE can be completed in a reliable response to the INVITE. Or it can be completed in an UPDATE. Once complete, another negotiation is forbidden within the same INVITE transaction. I guess we would change the rules a bit in that we don't allow the negotiation to be completed in a reliable provisional. (I would like to permit that, but I think it might be a step too far for compatibility.) But, if we forbid further negotiation within the same INVITE, what do we do instead if there are further UPDATEs? With O/A we can just leave the offers out. With s-t, leaving it out normally means negotiating it off. So either we change that (which we have already explored), or else I guess we "negotiate" again but agree to only repeat what has already been negotiated. (And if we make that rule, what do we do if it is violated? Especially, what if a proxy violates it?) Alternately, once the s-t negotiation has completed, we could simply allow another negotiation to be initiated within the same invite transaction, even though it seems like a stupid thing to do. Thanks, Paul > Regards, > > Christer > > > >> On 23/03/18 22:48, "sipcore on behalf of Christer Holmberg" >> >> wrote: >> >>> Hi Paul, >>> >>> You say (and it was indicated in the meeting): >>> >>> "I think it is, since the uac/uas roles are relative to >>> the direction of the individual request," >>> >>> Assuming that the AS and UA are implemented that way, the problem >>> still occurs when the AS receives (8), where the refresher >>> >>> >>> >>> >>>> Here is the primary use case flow that has been reported as the >>>> motivating case for the draft. (I've reformatted it for ease in >>>> typing.) >>>> >>>> 1) UA->Proxy: INVITE/SE:uac >>>> 2) Proxy->AS: INVITE/SE:uac >>>> 3) AS->Proxy: 18x/no-SE >>>> 4) Proxy->UA: 18x/no-SE >>>> 5) AS->Proxy: UPDATE/SE:uas >>>> 6) Proxy->UA: UPDATE/SE:uas >>>> 7) UA->Proxy: 200(UPDATE)/no-SE >>>> 8) Proxy->AS: 200(UPDATE)/SE:uac >>>> 9) AS->Proxy: 480(INVITE) >>>> 10) Proxy->UA: 480(INVITE) >>>> >>>> Some observations on the above: >>>> >>>> - in (5) the AS includes SE in the UPDATE, while in (7) the UA >>>> doesn't include SE in the response to the UPDATE. This seems >>>> to reflect a difference of opinion by the implementors of >>>> the UA and AS about what 4028 expects in this situation. >>>> This ambiguity needs to be resolved, and will require changes >>>> in some implementations. >>> >>> Correct. This is a case where UPDATE is received while the S-T >>> negotiation is still ongoing. >>> >>>> - The 480 in (9) is caused by the AS objecting to the "uac" >>>> in (8) because it is in conflict with the "uas" in (5). >>>> This in turn is caused by the proxy including the "uac" >>>> in (8) because it is following the rules and thinks that >>>> the UA doesn't support S-T. This of course isn't the >>>> situation. >>> >>> Shouldn't the proxy know that the UA supports S-T, due to (1)? >>> >>>> - There has been some discussion about whether the "uas" >>>> value in (5) is consistent with the "uac" value in (1). >>>> I think it is, since the uac/uas roles are relative to >>>> the direction of the individual request, and (5) is >>>> going in the opposite direction of (1). >>> >>> Let's assume it is like that. >>> >>>> But this >>>> doesn't seem to affect the rest of the analysis. >>>> If the refresher in the UPDATE was inconsistent with >>>> that in the INVITE then I would expect the UA to send >>>> an error response to the UPDATE. >>>> >>>> ISTM that at least part of the fix for this must be to fix the >>>> ambiguity about whether SE is to be included in an UPDATE and its >>>> response that are embedded in an INVITE transaction. The existing >>>> draft does address this one way. >>> >>> Yes. >>> >>>> Another way to address it would be to require SE to be included in >>>> both the UPDATE and its response, in a way consistent with what was >>>> in the INVITE and will eventually be in the response to the INVITE. >>> >>> Yes. >>> >>>> A much different way would be to require that the timer negotiation >>>> in an INVITE be completed in the first reliable response to the >>>> INVITE, either 2xx or reliable 1xx. Then any UPDATE that followed >>>> within the transaction would presumably start a new timer >>>> negotiation. >>> >>> Yes. >>> >>>> I'll also observe that this entire discussion has focused on the >>>> negotiation of the refresher. But there is a comparable issue around >>>> negotiating the duration of the timer. That ought to be sorted out >>>> as part of the same fix. >>> >>> Yes. >>> >>> Regards, >>> >>> Christer >>> >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >> >> > From nobody Wed Mar 28 13:51:52 2018 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 2C14A126DFB for ; Wed, 28 Mar 2018 13:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 2AMafS9GW61b for ; Wed, 28 Mar 2018 13:51:48 -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 453B9126DC2 for ; Wed, 28 Mar 2018 13:51:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1522270306; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=fsHjN+KEN0SiArGuge7I1lW73cK2OowEx0CAX56joz0=; b=SNNzGnmKrXnYtfUbXG0050CNt+IvOOYIr2ttX+uFRHOweHXi8UKdF4BNt2rknJpI jOVNDxPULGLphEt63Dbg1M0G4KF7MJt6/mAqviIkVa/lk/LiBO4sb7kJfqQkZmQB NHXcxxLaR3BEGkJ95nLo9aI0qArGKBs7RMzHlBxHvbY=; X-AuditID: c1b4fb3a-e21ff70000005d56-a1-5abc00620f72 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id BB.E0.23894.2600CBA5; Wed, 28 Mar 2018 22:51:46 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.115]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0382.000; Wed, 28 Mar 2018 22:51:45 +0200 From: Christer Holmberg To: Paul Kyzivat , SIPCORE Thread-Topic: [sipcore] session-timer fix Thread-Index: AQHTwfCeyHYsx4XVTkSHOLQKDcONKqPdSEtwgAhcbACAABDAgIAANGeAgAARLYCAACxJgA== Date: Wed, 28 Mar 2018 20:51:45 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B72E38364@ESESSMB109.ericsson.se> References: <949dba9e-33b7-66b9-1b16-d25902f65367@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B72E06C39@ESESSMB102.ericsson.se> <7594FB04B1934943A5C02806D1A2204B72E37EC9@ESESSMB109.ericsson.se> <9d3fd31a-af1b-3328-23e6-05c11e7978f0@alum.mit.edu> In-Reply-To: <9d3fd31a-af1b-3328-23e6-05c11e7978f0@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.172] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyM2K7sW4Sw54og5n7ZCxWbDjAavH1xyY2 ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSujYYd3wZOQim8v/RsYzwR1MXJySAiYSPzq bmHrYuTiEBI4wihx7dkFJghnCaPEq7aF7F2MHBxsAhYS3f+0QRpEBFwklnQfYQaxhQU0JLa+ fsQKEdeU+DN7AzOEHSaxculpJhCbRUBVovvJaUYQm1fAV2LT6hZmiPlPmST6JnwEa+YUcJB4 sbOBDcRmFBCT+H5qDVgzs4C4xK0n85kgLhWQWLLnPDOELSrx8vE/VpDbJASUJBpmsoCYzEA3 rN+lD9GpKDGl+yE7xFpBiZMzn7BMYBSZhWToLISOWUg6ZiHpWMDIsopRtDi1uDg33chIL7Uo M7m4OD9PLy+1ZBMjMA4ObvlttYPx4HPHQ4wCHIxKPLw533ZHCbEmlhVX5h5ilOBgVhLhfa8B FOJNSaysSi3Kjy8qzUktPsQozcGiJM7rlGYRJSSQnliSmp2aWpBaBJNl4uCUamAUlJFe9r/g Ysufcxt5z3atM7vk9sh03sGYq+Wt8deYbrzaXa7SrWu3ZavNsd8eRu0v8l4r9iZYBGnZ+Qd4 Pb7aMUv1YkMyD5fRQaa0x+0S89oSjp5dzxJX9vtKYtaPZYtDtRPvKRqphtiWr3n5MMJrvXRv OM+aqLvSvCIK5ROz33P/u6Ow6r0SS3FGoqEWc1FxIgDSjR4kfwIAAA== Archived-At: Subject: Re: [sipcore] session-timer fix 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, 28 Mar 2018 20:51:51 -0000 SGksDQoNCj4+Pj4gT2ssIEkgY2hlY2tlZCBzb21lIG9sZCBlLW1haWxzLCBhbmQgaGFkIGEgY2hh dCB3aXRoIHRoZSBpbnRlcm5hbCANCj4+Pj4gcGVvcGxlIHRoYXQgaW5mb3JtZWQgbWUgYWJvdXQg dGhlIHByb2JsZW0uDQo+Pj4+DQo+Pj4+IFRoZSBVUERBVEUgcmVxdWVzdCB3aXRoIHJlZnJlc2hl cj11YXMgaXMgKk5PVCogdGhlIHByb2JsZW0uIFRoZXkgDQo+Pj4+IGhhdmUgdGhlIHNhbWUgYXNz dW1wdGlvbiBhcyBQYXVsLCBKb25hdGhhbiBldGMgLSB0aGUgdmFsdWUgaXMgDQo+Pj4+IGluZGlj YXRlZCBwZXIgdHJhbnNhY3Rpb24uIFNvLCBVUERBVEUgd2l0aCByZWZyZXNoZXI9dWFzIGlzIG9r LiBNeSANCj4+Pj4gYXBvbG9naWVzIGZvciBtaXhpbmcgdGhhdCB1cC4NCj4+Pj4NCj4+Pj4gSXTC uXMgdGhlIFVQREFURSAyMDAgT0sgcmVzcG9uc2UsIHdoZXJlIHRoZSBwcm94eSBpbnNlcnRzIA0K Pj4+PiByZWZyZXNoZXI9dWFjLCB0aGF0IGNhdXNlcyB0aGUgcHJvYmxlbS4NCj4+Pj4NCj4+Pj4g U28sIG9uZSBhbHRlcm5hdGl2ZSB3b3VsZCBiZSB0byBhbGxvdyBVUERBVEUgcmVxdWVzdHMvcmVz cG9uc2VzIHNlbnQgDQo+Pj4+IHdoaWxlIHRoZSBzLXQgbmVnb3RpYXRpb24gaXMgb25nb2luZyBh cmUgaGFuZGxlZCBhcyBkZWZpbmVkIGluIFJGQyANCj4+Pj4gNDAyOCwgYnV0IHRoYXQgdGhlIHJl ZnJlc2hlciB2YWx1ZSBtdXN0IG5vdCBiZSBjaGFuZ2VkLg0KPj4+Pg0KPj4+PiBJbiB0aGUgY2Fz ZSBiZWxvdywgdGhhdCBtZWFucyB0aGF0IHRoZSBVQSBuZWVkcyB0byBpbmNsdWRlIHMtdCANCj4+ Pj4gaW5mb3JtYXRpb24gaW4gdGhlIFVQREFURSByZXNwb25zZSAobWVzc2FnZSAjNykuDQo+Pj4N Cj4+PiBUaGF0IHNlZW1zIGxpa2UgYSBzaW1wbGVyIGFuZCBjbGVhbmVyIGZpeCwgYXQgbGVhc3Qg Zm9yIHRoaXMgY2FzZS4NCj4+Pg0KPj4+IFRvIGdvIHRoYXQgd2F5IHdlIG5lZWQgdG8gY29uc2lk ZXIgb3RoZXIgY2FzZXMuDQo+Pj4NCj4+PiBJbiBwYXJ0aWN1bGFyLCBpcyB0aGUgVUEgKnJlcXVp cmVkKiB0byBpbmNsdWRlIHRoZSBzLXQgc3R1ZmYgaW4gdGhlIFVQREFURSBpZiBpdCBzdXBwb3J0 cyBzLXQ/DQo+PiANCj4+IE1pbi1TRSBpcyBjdXJyZW50bHkgTVVTVC4NCj4+IA0KPj4gU2Vzc2lv bi1FeHBpcmVzIGlzIGN1cnJlbnRseSBTSE9VTEQuIEkgZ3Vlc3Mgd2UgY291bGQgY2hhbmdlIHRo YXQgdG8gTVVTVC4NCj4+IA0KPj4+IFdoYXQgaWYgdGhlIFVBIGhhZCBvbWl0dGVkIHRoZSByZWZy ZXNoZXIgaW4gdGhlIElOVklURT8gUHJlc3VtYWJseSB0aGVuIHRoZSBBUyBjaG9vc2VzIGFuZCBw dXRzIGl0cyBjaG9pY2UgaW4gdGhlIFVQREFURS4NCj4+Pg0KPj4+IEFuZCBvbmNlIHMtZSBpbiBp bnZpdGUgaGFzIGJlZW4gcmVzcG9uZGVkIHRvIHdpdGggYW4gcy1lIGluIGFuIFVQREFURSwgZG9l cyB0aGF0IGZpbmlzaCB0aGUgbmVnb3RpYXRpb24/DQo+PiANCj4+IFllcy4gVGhlIElOVklURSB0 cmFuc2FjdGlvbiBpdHNlbGYgZG9lcyBub3QgbWF0dGVyIC0gaXQgZGVwZW5kcyBvbiB3aGV0aGVy IHMtZSBpcyBuZWdvdGlhdGVkIHdpdGhpbiB0aGUgSU5WSVRFIA0KPj4gdHJhbnNhY3Rpb24gb3Ig bm90IHRoYXQgbWF0dGVycy4gSWYgdGhlcmUgaXMgbm8gcy1lIG5lZ290aWF0aW9uIGluIHRoZSBJ TlZJVEUgdHJhbnNhY3Rpb24sIHRoZSBVUERBVEUgaXMgdHJlYXRlZCBhcyANCj4+IGFueSBtaWQt ZGlhbG9nIHJlcXVlc3QgYXMgZmFyIGFzIHMtZSBpcyBjb25jZXJuZWQuDQo+PiANCj4+PiBUaGVu IGRvIHN1YnNlcXVlbnQgbWVzc2FnZXMgd2l0aGluIHRoZSBpbnZpdGUgdHJhbnNhY3Rpb24gYW5k IGVtYmVkZGVkIFVQREFURVMgcmVwZWF0IHRoZSBhZ3JlZWQgdXBvbiByZXN1bHQ/DQo+Pj4gT3Ig Y2FuIHRoZXkgZG8gdGhlIG5lZ290aWF0aW9uIG92ZXI/DQo+PiANCj4+IFNpbmNlIHRoZXJlIGlz IG5vIG9uZ29pbmcgcy1lIG5lZ290aWF0aW9uLCBJIHNlZSBubyByZWFzb24gd2h5IHRoZXkgY2Fu J3QuDQo+PiANCj4+IEluIGdlbmVyYWwsIHVubGVzcyBzdWNoIHRleHQgYWxyZWFkeSBleGlzdCwg SSB0aGluayB3ZSBzaG91bGQgcmVjb21tZW5kIGFnYWluc3QgcmUtbmVnb3RpYXRpbmcgLCB1bmxl c3MgdGhlcmUgaXMgYSBnb29kIHJlYXNvbiBmb3IgaXQuDQo+DQo+IEkgZ3Vlc3MgSSBkaWRuJ3Qg bWFrZSBteSBjb25jZXJucyBjbGVhci4NCj4NCj4gSVNUTSB3ZSBjb3VsZCB1c2UgTy9BIHJ1bGVz IGFzIGEgKm1vZGVsKiBoZXJlOg0KPg0KPiBBIG5lZ290aWF0aW9uIGluaXRpYXRlZCBpbiBhbiBJ TlZJVEUgY2FuIGJlIGNvbXBsZXRlZCBpbiBhIHJlbGlhYmxlIHJlc3BvbnNlIHRvIHRoZSBJTlZJ VEUuIE9yIGl0IGNhbiBiZSBjb21wbGV0ZWQgaW4gYW4gVVBEQVRFLiANCj4gT25jZSBjb21wbGV0 ZSwgYW5vdGhlciBuZWdvdGlhdGlvbiBpcyBmb3JiaWRkZW4gd2l0aGluIHRoZSBzYW1lIElOVklU RSB0cmFuc2FjdGlvbi4gSSBndWVzcyB3ZSB3b3VsZCBjaGFuZ2UgdGhlIHJ1bGVzIGEgYml0IGlu IA0KPiB0aGF0IHdlIGRvbid0IGFsbG93IHRoZSBuZWdvdGlhdGlvbiB0byBiZSBjb21wbGV0ZWQg aW4gYSByZWxpYWJsZSBwcm92aXNpb25hbC4gKEkgd291bGQgbGlrZSB0byBwZXJtaXQgdGhhdCwg YnV0IEkgdGhpbmsgaXQgbWlnaHQgYmUgYSBzdGVwIHRvbyBmYXIgZm9yDQo+IGNvbXBhdGliaWxp dHkuKQ0KPg0KPiBCdXQsIGlmIHdlIGZvcmJpZCBmdXJ0aGVyIG5lZ290aWF0aW9uIHdpdGhpbiB0 aGUgc2FtZSBJTlZJVEUsIHdoYXQgZG8gd2UgZG8gaW5zdGVhZCBpZiB0aGVyZSBhcmUgZnVydGhl ciBVUERBVEVzPyBXaXRoIE8vQSB3ZSBjYW4ganVzdCBsZWF2ZSB0aGUgb2ZmZXJzIG91dC4gDQo+ IFdpdGggcy10LCBsZWF2aW5nIGl0IG91dCBub3JtYWxseSBtZWFucyBuZWdvdGlhdGluZyBpdCBv ZmYuIA0KPiBTbyBlaXRoZXIgd2UgY2hhbmdlIHRoYXQgKHdoaWNoIHdlIGhhdmUgYWxyZWFkeSBl eHBsb3JlZCksIG9yIGVsc2UgSSBndWVzcyB3ZSAibmVnb3RpYXRlIiBhZ2FpbiBidXQgYWdyZWUg dG8gb25seSByZXBlYXQgd2hhdCBoYXMgYWxyZWFkeSBiZWVuIA0KPiBuZWdvdGlhdGVkLiAoQW5k IGlmIHdlIG1ha2UgdGhhdCBydWxlLCB3aGF0IGRvIHdlIGRvIGlmIGl0IGlzIHZpb2xhdGVkPyBF c3BlY2lhbGx5LCB3aGF0IGlmIGEgcHJveHkgdmlvbGF0ZXMgaXQ/KQ0KDQpNeSBpZGVhIHdhcyB0 aGF0LCBpZiBVUERBVEVzIGFyZSBzZW5kIGR1cmluZyBhbiBvbmdvaW5nIElOVklURSBzLXQgbmVn b3RpYXRpb24sIHRoZSBzLXQgaW5mb3JtYXRpb24gaW4gdGhlIFVQREFURXMgbXVzdCByZWZsZWN0 IHRoZSBvbmdvaW5nIG5lZ290aWF0aW9uIChzaW1pbGFyIGFzIHNlbmRpbmcgU0RQIGluIGFuIHVu cmVsaWFibGUgMTh4IC0gaXQgaXMgbm90IHJlYWxseSBhbiBhbnN3ZXIsIGJ1dCBpdCBtdXN0IGJl IGEgY29weSBvZiB0aGUgdG8tYmUtc2VudC1hbnN3ZXIpLiBTbywgaW4gbXkgZXhhbXBsZSwgdGhl IHMtdCBpbmZvcm1hdGlvbiBpbiB0aGUgVVBEQVRFIHJlcXVlc3QgZnJvbSB0aGUgQVMgbXVzdCBy ZWZsZWN0IHdoYXQgdGhlIEFTIHdpbGwgZXZlbnR1YWxseSBzZW5kIGluIHRoZSAyMDAgT0sgdG8g dGhlIElOVklURS4gQW5kLCB0aGUgcy10IGluZm9ybWF0aW9uIGluIHRoZSBVUERBVEUgcmVzcG9u c2UgZnJvbSB0aGUgVUEgbXVzdCByZWZsZWN0IHdoYXQgdGhlIFVBIHNlbnQgaW4gdGhlIElOVklU RS4gDQoNCj4gQWx0ZXJuYXRlbHksIG9uY2UgdGhlIHMtdCBuZWdvdGlhdGlvbiBoYXMgY29tcGxl dGVkLCB3ZSBjb3VsZCBzaW1wbHkgYWxsb3cgYW5vdGhlciBuZWdvdGlhdGlvbiB0byBiZSBpbml0 aWF0ZWQgd2l0aGluIHRoZSBzYW1lDQo+IGludml0ZSB0cmFuc2FjdGlvbiwgZXZlbiB0aG91Z2gg aXQgc2VlbXMgbGlrZSBhIHN0dXBpZCB0aGluZyB0byBkby4NCg0KSSBhZ3JlZS4NCg0KUmVnYXJk cywNCg0KQ2hyaXN0ZXINCg0KDQoNCg0KPiBSZWdhcmRzLA0KPiANCj4gQ2hyaXN0ZXINCj4gDQo+ IA0KPiANCj4+IE9uIDIzLzAzLzE4IDIyOjQ4LCAic2lwY29yZSBvbiBiZWhhbGYgb2YgQ2hyaXN0 ZXIgSG9sbWJlcmciDQo+PiA8c2lwY29yZS1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiAN Cj4+IGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4NCj4+IHdyb3RlOg0KPj4NCj4+PiBI aSBQYXVsLA0KPj4+DQo+Pj4gWW91IHNheSAoYW5kIGl0IHdhcyBpbmRpY2F0ZWQgaW4gdGhlIG1l ZXRpbmcpOg0KPj4+DQo+Pj4gICAgICJJIHRoaW5rIGl0IGlzLCBzaW5jZSB0aGUgdWFjL3VhcyBy b2xlcyBhcmUgcmVsYXRpdmUgdG8NCj4+PiAgICAgdGhlIGRpcmVjdGlvbiBvZiB0aGUgaW5kaXZp ZHVhbCByZXF1ZXN0LCINCj4+Pg0KPj4+IEFzc3VtaW5nIHRoYXQgdGhlIEFTIGFuZCBVQSBhcmUg aW1wbGVtZW50ZWQgdGhhdCB3YXksIHRoZSBwcm9ibGVtIA0KPj4+IHN0aWxsIG9jY3VycyB3aGVu IHRoZSBBUyByZWNlaXZlcyAoOCksIHdoZXJlIHRoZSByZWZyZXNoZXINCj4+Pg0KPj4+DQo+Pj4N Cj4+Pg0KPj4+PiBIZXJlIGlzIHRoZSBwcmltYXJ5IHVzZSBjYXNlIGZsb3cgdGhhdCBoYXMgYmVl biByZXBvcnRlZCBhcyB0aGUgDQo+Pj4+IG1vdGl2YXRpbmcgY2FzZSBmb3IgdGhlIGRyYWZ0LiAo SSd2ZSByZWZvcm1hdHRlZCBpdCBmb3IgZWFzZSBpbg0KPj4+PiB0eXBpbmcuKQ0KPj4+Pg0KPj4+ PiAgICAxKSBVQS0+UHJveHk6IElOVklURS9TRTp1YWMNCj4+Pj4gICAgMikgUHJveHktPkFTOiBJ TlZJVEUvU0U6dWFjDQo+Pj4+ICAgIDMpIEFTLT5Qcm94eTogMTh4L25vLVNFDQo+Pj4+ICAgIDQp IFByb3h5LT5VQTogMTh4L25vLVNFDQo+Pj4+ICAgIDUpIEFTLT5Qcm94eTogVVBEQVRFL1NFOnVh cw0KPj4+PiAgICA2KSBQcm94eS0+VUE6IFVQREFURS9TRTp1YXMNCj4+Pj4gICAgNykgVUEtPlBy b3h5OiAyMDAoVVBEQVRFKS9uby1TRQ0KPj4+PiAgICA4KSBQcm94eS0+QVM6IDIwMChVUERBVEUp L1NFOnVhYw0KPj4+PiAgICA5KSBBUy0+UHJveHk6IDQ4MChJTlZJVEUpDQo+Pj4+IDEwKSBQcm94 eS0+VUE6IDQ4MChJTlZJVEUpDQo+Pj4+DQo+Pj4+IFNvbWUgb2JzZXJ2YXRpb25zIG9uIHRoZSBh Ym92ZToNCj4+Pj4NCj4+Pj4gLSBpbiAoNSkgdGhlIEFTIGluY2x1ZGVzIFNFIGluIHRoZSBVUERB VEUsIHdoaWxlIGluICg3KSB0aGUgVUENCj4+Pj4gICAgIGRvZXNuJ3QgaW5jbHVkZSBTRSBpbiB0 aGUgcmVzcG9uc2UgdG8gdGhlIFVQREFURS4gVGhpcyBzZWVtcw0KPj4+PiAgICAgdG8gcmVmbGVj dCBhIGRpZmZlcmVuY2Ugb2Ygb3BpbmlvbiBieSB0aGUgaW1wbGVtZW50b3JzIG9mDQo+Pj4+ICAg ICB0aGUgVUEgYW5kIEFTIGFib3V0IHdoYXQgNDAyOCBleHBlY3RzIGluIHRoaXMgc2l0dWF0aW9u Lg0KPj4+PiAgICAgVGhpcyBhbWJpZ3VpdHkgbmVlZHMgdG8gYmUgcmVzb2x2ZWQsIGFuZCB3aWxs IHJlcXVpcmUgY2hhbmdlcw0KPj4+PiAgICAgaW4gc29tZSBpbXBsZW1lbnRhdGlvbnMuDQo+Pj4N Cj4+PiBDb3JyZWN0LiBUaGlzIGlzIGEgY2FzZSB3aGVyZSBVUERBVEUgaXMgcmVjZWl2ZWQgd2hp bGUgdGhlIFMtVCANCj4+PiBuZWdvdGlhdGlvbiBpcyBzdGlsbCBvbmdvaW5nLg0KPj4+DQo+Pj4+ IC0gVGhlIDQ4MCBpbiAoOSkgaXMgY2F1c2VkIGJ5IHRoZSBBUyBvYmplY3RpbmcgdG8gdGhlICJ1 YWMiDQo+Pj4+ICAgICBpbiAoOCkgYmVjYXVzZSBpdCBpcyBpbiBjb25mbGljdCB3aXRoIHRoZSAi dWFzIiBpbiAoNSkuDQo+Pj4+ICAgICBUaGlzIGluIHR1cm4gaXMgY2F1c2VkIGJ5IHRoZSBwcm94 eSBpbmNsdWRpbmcgdGhlICJ1YWMiDQo+Pj4+ICAgICBpbiAoOCkgYmVjYXVzZSBpdCBpcyBmb2xs b3dpbmcgdGhlIHJ1bGVzIGFuZCB0aGlua3MgdGhhdA0KPj4+PiAgICAgdGhlIFVBIGRvZXNuJ3Qg c3VwcG9ydCBTLVQuIFRoaXMgb2YgY291cnNlIGlzbid0IHRoZQ0KPj4+PiAgICAgc2l0dWF0aW9u Lg0KPj4+DQo+Pj4gU2hvdWxkbid0IHRoZSBwcm94eSBrbm93IHRoYXQgdGhlIFVBIHN1cHBvcnRz IFMtVCwgZHVlIHRvICgxKT8NCj4+Pg0KPj4+PiAtIFRoZXJlIGhhcyBiZWVuIHNvbWUgZGlzY3Vz c2lvbiBhYm91dCB3aGV0aGVyIHRoZSAidWFzIg0KPj4+PiAgICAgdmFsdWUgaW4gKDUpIGlzIGNv bnNpc3RlbnQgd2l0aCB0aGUgInVhYyIgdmFsdWUgaW4gKDEpLg0KPj4+PiAgICAgSSB0aGluayBp dCBpcywgc2luY2UgdGhlIHVhYy91YXMgcm9sZXMgYXJlIHJlbGF0aXZlIHRvDQo+Pj4+ICAgICB0 aGUgZGlyZWN0aW9uIG9mIHRoZSBpbmRpdmlkdWFsIHJlcXVlc3QsIGFuZCAoNSkgaXMNCj4+Pj4g ICAgIGdvaW5nIGluIHRoZSBvcHBvc2l0ZSBkaXJlY3Rpb24gb2YgKDEpLg0KPj4+DQo+Pj4gTGV0 J3MgYXNzdW1lIGl0IGlzIGxpa2UgdGhhdC4NCj4+Pg0KPj4+PiBCdXQgdGhpcw0KPj4+PiAgICAg ZG9lc24ndCBzZWVtIHRvIGFmZmVjdCB0aGUgcmVzdCBvZiB0aGUgYW5hbHlzaXMuDQo+Pj4+ICAg ICBJZiB0aGUgcmVmcmVzaGVyIGluIHRoZSBVUERBVEUgd2FzIGluY29uc2lzdGVudCB3aXRoDQo+ Pj4+ICAgICB0aGF0IGluIHRoZSBJTlZJVEUgdGhlbiBJIHdvdWxkIGV4cGVjdCB0aGUgVUEgdG8g c2VuZA0KPj4+PiAgICAgYW4gZXJyb3IgcmVzcG9uc2UgdG8gdGhlIFVQREFURS4NCj4+Pj4NCj4+ Pj4gSVNUTSB0aGF0IGF0IGxlYXN0IHBhcnQgb2YgdGhlIGZpeCBmb3IgdGhpcyBtdXN0IGJlIHRv IGZpeCB0aGUgDQo+Pj4+IGFtYmlndWl0eSBhYm91dCB3aGV0aGVyIFNFIGlzIHRvIGJlIGluY2x1 ZGVkIGluIGFuIFVQREFURSBhbmQgaXRzIA0KPj4+PiByZXNwb25zZSB0aGF0IGFyZSBlbWJlZGRl ZCBpbiBhbiBJTlZJVEUgdHJhbnNhY3Rpb24uIFRoZSBleGlzdGluZyANCj4+Pj4gZHJhZnQgZG9l cyBhZGRyZXNzIHRoaXMgb25lIHdheS4NCj4+Pg0KPj4+IFllcy4NCj4+Pg0KPj4+PiBBbm90aGVy IHdheSB0byBhZGRyZXNzIGl0IHdvdWxkIGJlIHRvIHJlcXVpcmUgU0UgdG8gYmUgaW5jbHVkZWQg aW4gDQo+Pj4+IGJvdGggdGhlIFVQREFURSBhbmQgaXRzIHJlc3BvbnNlLCBpbiBhIHdheSBjb25z aXN0ZW50IHdpdGggd2hhdCB3YXMgDQo+Pj4+IGluIHRoZSBJTlZJVEUgYW5kIHdpbGwgZXZlbnR1 YWxseSBiZSBpbiB0aGUgcmVzcG9uc2UgdG8gdGhlIElOVklURS4NCj4+Pg0KPj4+IFllcy4NCj4+ Pg0KPj4+PiBBIG11Y2ggZGlmZmVyZW50IHdheSB3b3VsZCBiZSB0byByZXF1aXJlIHRoYXQgdGhl IHRpbWVyIG5lZ290aWF0aW9uIA0KPj4+PiBpbiBhbiBJTlZJVEUgYmUgY29tcGxldGVkIGluIHRo ZSBmaXJzdCByZWxpYWJsZSByZXNwb25zZSB0byB0aGUgDQo+Pj4+IElOVklURSwgZWl0aGVyIDJ4 eCBvciByZWxpYWJsZSAxeHguIFRoZW4gYW55IFVQREFURSB0aGF0IGZvbGxvd2VkIA0KPj4+PiB3 aXRoaW4gdGhlIHRyYW5zYWN0aW9uIHdvdWxkIHByZXN1bWFibHkgc3RhcnQgYSBuZXcgdGltZXIg DQo+Pj4+IG5lZ290aWF0aW9uLg0KPj4+DQo+Pj4gWWVzLg0KPj4+DQo+Pj4+IEknbGwgYWxzbyBv YnNlcnZlIHRoYXQgdGhpcyBlbnRpcmUgZGlzY3Vzc2lvbiBoYXMgZm9jdXNlZCBvbiB0aGUgDQo+ Pj4+IG5lZ290aWF0aW9uIG9mIHRoZSByZWZyZXNoZXIuIEJ1dCB0aGVyZSBpcyBhIGNvbXBhcmFi bGUgaXNzdWUgDQo+Pj4+IGFyb3VuZCBuZWdvdGlhdGluZyB0aGUgZHVyYXRpb24gb2YgdGhlIHRp bWVyLiBUaGF0IG91Z2h0IHRvIGJlIA0KPj4+PiBzb3J0ZWQgb3V0IGFzIHBhcnQgb2YgdGhlIHNh bWUgZml4Lg0KPj4+DQo+Pj4gWWVzLg0KPj4+DQo+Pj4gUmVnYXJkcywNCj4+Pg0KPj4+IENocmlz dGVyDQo+Pj4NCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPj4+IHNpcGNvcmUgbWFpbGluZyBsaXN0DQo+Pj4gc2lwY29yZUBpZXRmLm9yZw0KPj4+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZQ0KPj4NCj4+DQo+ IA0KDQo= From nobody Wed Mar 28 14:51:41 2018 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 9AF31126D74 for ; Wed, 28 Mar 2018 14:51:38 -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 qC-ygObRuwML for ; Wed, 28 Mar 2018 14:51:34 -0700 (PDT) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) (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 5DFBB127775 for ; Wed, 28 Mar 2018 14:51:34 -0700 (PDT) Received: by mail-pf0-x22b.google.com with SMTP id q9so1752978pff.1 for ; Wed, 28 Mar 2018 14:51:34 -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=JEEkojxF2qSg+hsTUV+KGlndmAWKzFkyyvtQ7WSgDK4=; b=Gjw0302V3U6RmaSvXKDXFv1aUemc8UQEIIj5iSQYrFvIw+IRmKd6yDBaWCu+IZdFMt Yj2qSrQctikyIPyWTd9wZ3i0lHXe1LLvhGiWvkuJtOazrifBb1eCX9gAJCi3VUXklHxj RTBU1KuhScN7tFFUhcbLw05EDw7lakmiNfOGBjM9hkcHQ3Uiz0QCBr/OB049I5xASc0l t1qtupvNpU5UQqkgdlb4hZl/dKWj98DLjY7O9OVxI+xzNY08Iat6E0EiBu7j9UnDhn/R zaXKSGv0r01pHUfx0wMHZOxtVOZtP3Ljjr8Cv9ZEPeV93ejGkRB9SvygcvV/emCQnhes 9N7Q== 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=JEEkojxF2qSg+hsTUV+KGlndmAWKzFkyyvtQ7WSgDK4=; b=UuNxDPrYhGVzYZTbw9iL+C8qYqUbmpPRLGyloRB0gV0P5w2cRbsZzM2vKbrD+/YSPv xb8T+lwZLG6LuCEj3YHUlm/62HYrF9xng+uDW5VB08E8vbjgE1eB8HiyZvNxewBAuY/T wBrHFBvypdZHVS/+GMXI2h4GpIB2KMsaeVvj5nw39C++SDQei7+BE+GwrxaV9kBYCs2i rRWJV1kW5Eq8KIm3HVaX2nJ2zupX+3FJM+1yaAUVdD++Nl7hhitD1hcTDJ1uyvFQLPHB wlReGYpfwyCwXEyJa2b1VbdS+d2IL5TskfVjyDZa+ZEq8GHqJWonNQ35bn+Ze+epTw6f TnOQ== X-Gm-Message-State: AElRT7GobE3sDK8GGXalTy6Bhin5KJSrJ0PDleYCHd0rZzU0VLiY201P 06Xfw/elgUKijIHlj9dxPv5oJhFp X-Google-Smtp-Source: AIpwx4+uCYyUR42vaeyZrjTshifHwGTw+lLHXwBa4U0FUPFrzLGM2UvTtd5VkWCtn5XIcK3dg/+0Pw== X-Received: by 2002:a17:902:b10c:: with SMTP id q12-v6mr5370122plr.399.1522273893507; Wed, 28 Mar 2018 14:51:33 -0700 (PDT) Received: from mail-pf0-f179.google.com (mail-pf0-f179.google.com. [209.85.192.179]) by smtp.gmail.com with ESMTPSA id z6sm8901340pfe.9.2018.03.28.14.51.31 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Mar 2018 14:51:31 -0700 (PDT) Received: by mail-pf0-f179.google.com with SMTP id g14so1746529pfh.3 for ; Wed, 28 Mar 2018 14:51:31 -0700 (PDT) X-Received: by 10.98.10.156 with SMTP id 28mr4269094pfk.33.1522273890709; Wed, 28 Mar 2018 14:51:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.241.132 with HTTP; Wed, 28 Mar 2018 14:51:29 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B72E38364@ESESSMB109.ericsson.se> References: <949dba9e-33b7-66b9-1b16-d25902f65367@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B72E06C39@ESESSMB102.ericsson.se> <7594FB04B1934943A5C02806D1A2204B72E37EC9@ESESSMB109.ericsson.se> <9d3fd31a-af1b-3328-23e6-05c11e7978f0@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B72E38364@ESESSMB109.ericsson.se> From: Roman Shpount Date: Wed, 28 Mar 2018 17:51:29 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Christer Holmberg , Paul Kyzivat Cc: SIPCORE Content-Type: multipart/alternative; boundary="001a1143227c81b5250568800231" Archived-At: Subject: Re: [sipcore] session-timer fix 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, 28 Mar 2018 21:51:39 -0000 --001a1143227c81b5250568800231 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Paul and Christer, First of all, I agree that in the initial scenario, UA in step 7 should have responded with S-E:uas in 200 OK for Update. Furthermore, if UA in step 7 did respond without S-E, or with S-E:uac, AS should not have sent 480 in step 9. It should have sent S-E:uas. Generally, what I am proposing is that, S-E header should be generated based on the S-E status when request or response is generated. If there are multiple inter-lapping transactions S-E state can change and S-E state in the response should be set to the S-E value when response is generated, not when the original request is received. In case of your example, S-E state in step 9 should be based on results of the UPDATE transaction, not the initial INVITE. This is why it should be sent to S-E:uas. Furthermore, we should restrict (with SHOULD, not MUST since existing UA already violate this) that UA should avoid generating requests which will change the current S-E status when another transaction which negotiates S-E is in progress. Specifically, in the example provided, UPDATE in step 5 should be generated with S-E:uas (as it was correctly generated in your example). Responses generated when another transaction is in progress should be generated in a way that avoids changing the current S-E status (response in step 7 should have been S-E:uas). Finally, even with all of these restrictions there are situations when S-E status is unclear due to timing. For instance when UPDATE changing the S-E status is sent at roughly the same time as 200 OK for an INVITE. In this case, UA cannot distinguish Scenario A: 1) UA->AS: INVITE/SE 2) AS->UA: UPDATE/SE:uac 3) UA-> AS: 200(UPDATE)/SE:uac 4) AS-> UA : 200(INVITE) /SE:uac and Scenario B: 1) UA->AS: INVITE/SE 2) AS-> UA : 200(INVITE) /SE:uac 3) AS->UA: UPDATE/SE:uac 4) UA-> AS: 200(UPDATE)/SE:uac Between those two scenarios, either AS or UA becomes a refresher based on the message delivery timing. These scenarios do not violate any of the proposed rules and can be encount= ered with existing SIP implementations. Also, these ambiguity cannot be resolved with refusing UPDATE request with retry after since UA does not know that 200 OK and UPDATE are sent close together. My suggestion is to specify that 200 OK changing S-E status MUST NOT be sent when UPDATE transaction is in progress. UPDATE changing S-E status MUST NOT be sent when 200 OK was sent but ACK was not yet received. I would be very interested if you can think of other, more robust ways to detect and deal with this situation which require modifications only for one of the SIP UA. Regards, _____________ Roman Shpount On Wed, Mar 28, 2018 at 4:51 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > >>>> Ok, I checked some old e-mails, and had a chat with the internal > >>>> people that informed me about the problem. > >>>> > >>>> The UPDATE request with refresher=3Duas is *NOT* the problem. They > >>>> have the same assumption as Paul, Jonathan etc - the value is > >>>> indicated per transaction. So, UPDATE with refresher=3Duas is ok. My > >>>> apologies for mixing that up. > >>>> > >>>> It=C2=B9s the UPDATE 200 OK response, where the proxy inserts > >>>> refresher=3Duac, that causes the problem. > >>>> > >>>> So, one alternative would be to allow UPDATE requests/responses sent > >>>> while the s-t negotiation is ongoing are handled as defined in RFC > >>>> 4028, but that the refresher value must not be changed. > >>>> > >>>> In the case below, that means that the UA needs to include s-t > >>>> information in the UPDATE response (message #7). > >>> > >>> That seems like a simpler and cleaner fix, at least for this case. > >>> > >>> To go that way we need to consider other cases. > >>> > >>> In particular, is the UA *required* to include the s-t stuff in the > UPDATE if it supports s-t? > >> > >> Min-SE is currently MUST. > >> > >> Session-Expires is currently SHOULD. I guess we could change that to > MUST. > >> > >>> What if the UA had omitted the refresher in the INVITE? Presumably > then the AS chooses and puts its choice in the UPDATE. > >>> > >>> And once s-e in invite has been responded to with an s-e in an UPDATE= , > does that finish the negotiation? > >> > >> Yes. The INVITE transaction itself does not matter - it depends on > whether s-e is negotiated within the INVITE > >> transaction or not that matters. If there is no s-e negotiation in the > INVITE transaction, the UPDATE is treated as > >> any mid-dialog request as far as s-e is concerned. > >> > >>> Then do subsequent messages within the invite transaction and embedde= d > UPDATES repeat the agreed upon result? > >>> Or can they do the negotiation over? > >> > >> Since there is no ongoing s-e negotiation, I see no reason why they > can't. > >> > >> In general, unless such text already exist, I think we should recommen= d > against re-negotiating , unless there is a good reason for it. > > > > I guess I didn't make my concerns clear. > > > > ISTM we could use O/A rules as a *model* here: > > > > A negotiation initiated in an INVITE can be completed in a reliable > response to the INVITE. Or it can be completed in an UPDATE. > > Once complete, another negotiation is forbidden within the same INVITE > transaction. I guess we would change the rules a bit in > > that we don't allow the negotiation to be completed in a reliable > provisional. (I would like to permit that, but I think it might be a step > too far for > > compatibility.) > > > > But, if we forbid further negotiation within the same INVITE, what do w= e > do instead if there are further UPDATEs? With O/A we can just leave the > offers out. > > With s-t, leaving it out normally means negotiating it off. > > So either we change that (which we have already explored), or else I > guess we "negotiate" again but agree to only repeat what has already been > > negotiated. (And if we make that rule, what do we do if it is violated? > Especially, what if a proxy violates it?) > > My idea was that, if UPDATEs are send during an ongoing INVITE s-t > negotiation, the s-t information in the UPDATEs must reflect the ongoing > negotiation (similar as sending SDP in an unreliable 18x - it is not real= ly > an answer, but it must be a copy of the to-be-sent-answer). So, in my > example, the s-t information in the UPDATE request from the AS must refle= ct > what the AS will eventually send in the 200 OK to the INVITE. And, the s-= t > information in the UPDATE response from the UA must reflect what the UA > sent in the INVITE. > > > Alternately, once the s-t negotiation has completed, we could simply > allow another negotiation to be initiated within the same > > invite transaction, even though it seems like a stupid thing to do. > > I agree. > > Regards, > > Christer > > > > > > Regards, > > > > Christer > > > > > > > >> On 23/03/18 22:48, "sipcore on behalf of Christer Holmberg" > >> >> christer.holmberg@ericsson.com> > >> wrote: > >> > >>> Hi Paul, > >>> > >>> You say (and it was indicated in the meeting): > >>> > >>> "I think it is, since the uac/uas roles are relative to > >>> the direction of the individual request," > >>> > >>> Assuming that the AS and UA are implemented that way, the problem > >>> still occurs when the AS receives (8), where the refresher > >>> > >>> > >>> > >>> > >>>> Here is the primary use case flow that has been reported as the > >>>> motivating case for the draft. (I've reformatted it for ease in > >>>> typing.) > >>>> > >>>> 1) UA->Proxy: INVITE/SE:uac > >>>> 2) Proxy->AS: INVITE/SE:uac > >>>> 3) AS->Proxy: 18x/no-SE > >>>> 4) Proxy->UA: 18x/no-SE > >>>> 5) AS->Proxy: UPDATE/SE:uas > >>>> 6) Proxy->UA: UPDATE/SE:uas > >>>> 7) UA->Proxy: 200(UPDATE)/no-SE > >>>> 8) Proxy->AS: 200(UPDATE)/SE:uac > >>>> 9) AS->Proxy: 480(INVITE) > >>>> 10) Proxy->UA: 480(INVITE) > >>>> > >>>> Some observations on the above: > >>>> > >>>> - in (5) the AS includes SE in the UPDATE, while in (7) the UA > >>>> doesn't include SE in the response to the UPDATE. This seems > >>>> to reflect a difference of opinion by the implementors of > >>>> the UA and AS about what 4028 expects in this situation. > >>>> This ambiguity needs to be resolved, and will require changes > >>>> in some implementations. > >>> > >>> Correct. This is a case where UPDATE is received while the S-T > >>> negotiation is still ongoing. > >>> > >>>> - The 480 in (9) is caused by the AS objecting to the "uac" > >>>> in (8) because it is in conflict with the "uas" in (5). > >>>> This in turn is caused by the proxy including the "uac" > >>>> in (8) because it is following the rules and thinks that > >>>> the UA doesn't support S-T. This of course isn't the > >>>> situation. > >>> > >>> Shouldn't the proxy know that the UA supports S-T, due to (1)? > >>> > >>>> - There has been some discussion about whether the "uas" > >>>> value in (5) is consistent with the "uac" value in (1). > >>>> I think it is, since the uac/uas roles are relative to > >>>> the direction of the individual request, and (5) is > >>>> going in the opposite direction of (1). > >>> > >>> Let's assume it is like that. > >>> > >>>> But this > >>>> doesn't seem to affect the rest of the analysis. > >>>> If the refresher in the UPDATE was inconsistent with > >>>> that in the INVITE then I would expect the UA to send > >>>> an error response to the UPDATE. > >>>> > >>>> ISTM that at least part of the fix for this must be to fix the > >>>> ambiguity about whether SE is to be included in an UPDATE and its > >>>> response that are embedded in an INVITE transaction. The existing > >>>> draft does address this one way. > >>> > >>> Yes. > >>> > >>>> Another way to address it would be to require SE to be included in > >>>> both the UPDATE and its response, in a way consistent with what was > >>>> in the INVITE and will eventually be in the response to the INVITE. > >>> > >>> Yes. > >>> > >>>> A much different way would be to require that the timer negotiation > >>>> in an INVITE be completed in the first reliable response to the > >>>> INVITE, either 2xx or reliable 1xx. Then any UPDATE that followed > >>>> within the transaction would presumably start a new timer > >>>> negotiation. > >>> > >>> Yes. > >>> > >>>> I'll also observe that this entire discussion has focused on the > >>>> negotiation of the refresher. But there is a comparable issue > >>>> around negotiating the duration of the timer. That ought to be > >>>> sorted out as part of the same fix. > >>> > >>> Yes. > >>> > >>> 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 > --001a1143227c81b5250568800231 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Paul and Christer,

First of all, I agre= e that in the initial scenario, UA in step 7 should have responded with S-E= :uas in 200 OK for Update.

Furthermore, if UA in s= tep 7 did respond without S-E, or with S-E:uac, AS should not have sent 480= in step 9. It should have sent S-E:uas.

Generally= , what I am proposing is that, S-E header should be generated based on the = S-E status when request or response is generated. If there are multiple int= er-lapping transactions S-E state can change and S-E state in the response = should be set to the S-E value when response is generated, not when the ori= ginal request is received. In case of your example, S-E state in step 9 sho= uld be based on results of the UPDATE transaction, not the initial INVITE. = This is why it should be sent to S-E:uas.

Furtherm= ore, we should restrict (with SHOULD, not MUST since existing UA already vi= olate this) that UA should avoid generating requests which will change the = current S-E status when another transaction which negotiates S-E is in prog= ress. Specifically, in the example provided, UPDATE in step 5 should be gen= erated with S-E:uas (as it was correctly generated in your example). Respon= ses generated when another transaction is in progress should be generated i= n a way that avoids changing the current S-E status (response in step 7 sho= uld have been=C2=A0 S-E:uas).

Finally, even with all = of these restrictions there are situations when S-E status is unclear due t= o timing. For instance when UPDATE changing the S-E status is sent at rough= ly the same time as 200 OK for an INVITE. In this case, UA cannot distingui= sh

Scenario A:
1) UA->AS: INVITE/SE
2= ) AS->UA: UPDATE/SE:uac
3) UA-> AS: 200(UPDATE)/SE:u= ac
4) AS-> UA : 200(INVITE) /SE:uac=C2=A0

an= d

=
Scenario B:
1) UA->AS: INVITE/SE
2= ) AS->=C2=A0UA=C2=A0: 200(INVITE)=C2=A0/SE:uac= =C2=A0
3) AS->UA: UPDATE/SE:uac
4) UA->=C2=A0AS: 200(UPDATE)/SE:uac=C2=A0=

Between those two scenarios, eithe= r AS or UA becomes a refresher based on the message delivery timing.=

= These scenarios do not violate any of the proposed rules and ca= n be=C2=A0encountered with existing SIP implementations. Also, these amb= iguity cannot be resolved with refusing UPDATE request with retry after sin= ce UA does not know that 200 OK and UPDATE are sent close together.<= /font>

My suggestion is to specify that 200 OK ch= anging S-E status MUST NOT be sent when UPDATE transaction is in progress. = UPDATE changing S-E status MUST NOT be sent when 200 OK was sent but ACK wa= s not yet received.
=
I would be very= interested if you can think of other, more robust ways to detect and deal = with this situation which require modifications only for one of the SIP UA.=

<= /div>
Regards,
=

_____________
Roman Shpount

On Wed, Mar 28, 2018 at 4:51 PM, Christer Ho= lmberg <christer.holmberg@ericsson.com> wrote:<= br>
H= i,

>>>> Ok, I checked some old e-mails, and had a chat with the in= ternal
>>>> people that informed me about the problem.
>>>>
>>>> The UPDATE request with refresher=3Duas is *NOT* the probl= em. They
>>>> have the same assumption as Paul, Jonathan etc - the value= is
>>>> indicated per transaction. So, UPDATE with refresher=3Duas= is ok. My
>>>> apologies for mixing that up.
>>>>
>>>> It=C2=B9s the UPDATE 200 OK response, where the proxy inse= rts
>>>> refresher=3Duac, that causes the problem.
>>>>
>>>> So, one alternative would be to allow UPDATE requests/resp= onses sent
>>>> while the s-t negotiation is ongoing are handled as define= d in RFC
>>>> 4028, but that the refresher value must not be changed. >>>>
>>>> In the case below, that means that the UA needs to include= s-t
>>>> information in the UPDATE response (message #7).
>>>
>>> That seems like a simpler and cleaner fix, at least for this c= ase.
>>>
>>> To go that way we need to consider other cases.
>>>
>>> In particular, is the UA *required* to include the s-t stuff i= n the UPDATE if it supports s-t?
>>
>> Min-SE is currently MUST.
>>
>> Session-Expires is currently SHOULD. I guess we could change that = to MUST.
>>
>>> What if the UA had omitted the refresher in the INVITE? Presum= ably then the AS chooses and puts its choice in the UPDATE.
>>>
>>> And once s-e in invite has been responded to with an s-e in an= UPDATE, does that finish the negotiation?
>>
>> Yes. The INVITE transaction itself does not matter - it depends on= whether s-e is negotiated within the INVITE
>> transaction or not that matters. If there is no s-e negotiation in= the INVITE transaction, the UPDATE is treated as
>> any mid-dialog request as far as s-e is concerned.
>>
>>> Then do subsequent messages within the invite transaction and = embedded UPDATES repeat the agreed upon result?
>>> Or can they do the negotiation over?
>>
>> Since there is no ongoing s-e negotiation, I see no reason why the= y can't.
>>
>> In general, unless such text already exist, I think we should reco= mmend against re-negotiating , unless there is a good reason for it.
>
> I guess I didn't make my concerns clear.
>
> ISTM we could use O/A rules as a *model* here:
>
> A negotiation initiated in an INVITE can be completed in a reliable re= sponse to the INVITE. Or it can be completed in an UPDATE.
> Once complete, another negotiation is forbidden within the same INVITE= transaction. I guess we would change the rules a bit in
> that we don't allow the negotiation to be completed in a reliable = provisional. (I would like to permit that, but I think it might be a step t= oo far for
> compatibility.)
>
> But, if we forbid further negotiation within the same INVITE, what do = we do instead if there are further UPDATEs? With O/A we can just leave the = offers out.
> With s-t, leaving it out normally means negotiating it off.
> So either we change that (which we have already explored), or else I g= uess we "negotiate" again but agree to only repeat what has alrea= dy been
> negotiated. (And if we make that rule, what do we do if it is violated= ? Especially, what if a proxy violates it?)

My idea was that, if UPDATEs are send during an ongoing INVITE = s-t negotiation, the s-t information in the UPDATEs must reflect the ongoin= g negotiation (similar as sending SDP in an unreliable 18x - it is not real= ly an answer, but it must be a copy of the to-be-sent-answer). So, in my ex= ample, the s-t information in the UPDATE request from the AS must reflect w= hat the AS will eventually send in the 200 OK to the INVITE. And, the s-t i= nformation in the UPDATE response from the UA must reflect what the UA sent= in the INVITE.

> Alternately, once the s-t negotiation has completed, we could simply a= llow another negotiation to be initiated within the same
> invite transaction, even though it seems like a stupid thing to do.
I agree.

Regards,

Christer




> Regards,
>
> Christer
>
>
>
>> On 23/03/18 22:48, "sipcore on behalf of Christer Holmberg&qu= ot;
>> <sipcore-bounces@ie= tf.org on behalf of
>> christer.holmber= g@ericsson.com>
>> wrote:
>>
>>> Hi Paul,
>>>
>>> You say (and it was indicated in the meeting):
>>>
>>>=C2=A0 =C2=A0 =C2=A0"I think it is, since the uac/uas role= s are relative to
>>>=C2=A0 =C2=A0 =C2=A0the direction of the individual request,&qu= ot;
>>>
>>> Assuming that the AS and UA are implemented that way, the prob= lem
>>> still occurs when the AS receives (8), where the refresher
>>>
>>>
>>>
>>>
>>>> Here is the primary use case flow that has been reported a= s the
>>>> motivating case for the draft. (I've reformatted it fo= r ease in
>>>> typing.)
>>>>
>>>>=C2=A0 =C2=A0 1) UA->Proxy: INVITE/SE:uac
>>>>=C2=A0 =C2=A0 2) Proxy->AS: INVITE/SE:uac
>>>>=C2=A0 =C2=A0 3) AS->Proxy: 18x/no-SE
>>>>=C2=A0 =C2=A0 4) Proxy->UA: 18x/no-SE
>>>>=C2=A0 =C2=A0 5) AS->Proxy: UPDATE/SE:uas
>>>>=C2=A0 =C2=A0 6) Proxy->UA: UPDATE/SE:uas
>>>>=C2=A0 =C2=A0 7) UA->Proxy: 200(UPDATE)/no-SE
>>>>=C2=A0 =C2=A0 8) Proxy->AS: 200(UPDATE)/SE:uac
>>>>=C2=A0 =C2=A0 9) AS->Proxy: 480(INVITE)
>>>> 10) Proxy->UA: 480(INVITE)
>>>>
>>>> Some observations on the above:
>>>>
>>>> - in (5) the AS includes SE in the UPDATE, while in (7) th= e UA
>>>>=C2=A0 =C2=A0 =C2=A0doesn't include SE in the response = to the UPDATE. This seems
>>>>=C2=A0 =C2=A0 =C2=A0to reflect a difference of opinion by t= he implementors of
>>>>=C2=A0 =C2=A0 =C2=A0the UA and AS about what 4028 expects i= n this situation.
>>>>=C2=A0 =C2=A0 =C2=A0This ambiguity needs to be resolved, an= d will require changes
>>>>=C2=A0 =C2=A0 =C2=A0in some implementations.
>>>
>>> Correct. This is a case where UPDATE is received while the S-T=
>>> negotiation is still ongoing.
>>>
>>>> - The 480 in (9) is caused by the AS objecting to the &quo= t;uac"
>>>>=C2=A0 =C2=A0 =C2=A0in (8) because it is in conflict with t= he "uas" in (5).
>>>>=C2=A0 =C2=A0 =C2=A0This in turn is caused by the proxy inc= luding the "uac"
>>>>=C2=A0 =C2=A0 =C2=A0in (8) because it is following the rule= s and thinks that
>>>>=C2=A0 =C2=A0 =C2=A0the UA doesn't support S-T. This of= course isn't the
>>>>=C2=A0 =C2=A0 =C2=A0situation.
>>>
>>> Shouldn't the proxy know that the UA supports S-T, due to = (1)?
>>>
>>>> - There has been some discussion about whether the "u= as"
>>>>=C2=A0 =C2=A0 =C2=A0value in (5) is consistent with the &qu= ot;uac" value in (1).
>>>>=C2=A0 =C2=A0 =C2=A0I think it is, since the uac/uas roles = are relative to
>>>>=C2=A0 =C2=A0 =C2=A0the direction of the individual request= , and (5) is
>>>>=C2=A0 =C2=A0 =C2=A0going in the opposite direction of (1).=
>>>
>>> Let's assume it is like that.
>>>
>>>> But this
>>>>=C2=A0 =C2=A0 =C2=A0doesn't seem to affect the rest of = the analysis.
>>>>=C2=A0 =C2=A0 =C2=A0If the refresher in the UPDATE was inco= nsistent with
>>>>=C2=A0 =C2=A0 =C2=A0that in the INVITE then I would expect = the UA to send
>>>>=C2=A0 =C2=A0 =C2=A0an error response to the UPDATE.
>>>>
>>>> ISTM that at least part of the fix for this must be to fix= the
>>>> ambiguity about whether SE is to be included in an UPDATE = and its
>>>> response that are embedded in an INVITE transaction. The e= xisting
>>>> draft does address this one way.
>>>
>>> Yes.
>>>
>>>> Another way to address it would be to require SE to be inc= luded in
>>>> both the UPDATE and its response, in a way consistent with= what was
>>>> in the INVITE and will eventually be in the response to th= e INVITE.
>>>
>>> Yes.
>>>
>>>> A much different way would be to require that the timer ne= gotiation
>>>> in an INVITE be completed in the first reliable response t= o the
>>>> INVITE, either 2xx or reliable 1xx. Then any UPDATE that f= ollowed
>>>> within the transaction would presumably start a new timer<= br> >>>> negotiation.
>>>
>>> Yes.
>>>
>>>> I'll also observe that this entire discussion has focu= sed on the
>>>> negotiation of the refresher. But there is a comparable is= sue
>>>> around negotiating the duration of the timer. That ought t= o be
>>>> sorted out as part of the same fix.
>>>
>>> Yes.
>>>
>>> Regards,
>>>
>>> Christer
>>>
>>> _______________________________________________
>>> sipcore mailing list
>>> sipcore@ietf.org
>>> https://www.ietf.org/mailman/listinf= o/sipcore
>>
>>
>

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

--001a1143227c81b5250568800231-- From nobody Wed Mar 28 23:17:28 2018 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 D565F12D7EA for ; Wed, 28 Mar 2018 23:17:26 -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, FREEMAIL_FROM=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 xUevyvXdnbqm for ; Wed, 28 Mar 2018 23:17:24 -0700 (PDT) Received: from mail-ot0-x22c.google.com (mail-ot0-x22c.google.com [IPv6:2607:f8b0:4003:c0f::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FA70124D6C for ; Wed, 28 Mar 2018 23:17:24 -0700 (PDT) Received: by mail-ot0-x22c.google.com with SMTP id 23-v6so5334672otj.0 for ; Wed, 28 Mar 2018 23:17:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=CCRAsgToQgHhPW/nCZZa8hOuTGRXgak+R+4BB5wHWkU=; b=hE4mxw3cMAfVO1oe/uF1vYDVoDMyneRlZgWLHC2TKQd9QbKbzUxzvX8Ygd01JH7V3a ula8T2nGYsFv04teA/9B/z8NnMqJOsHH+1xcbWyIjydjS+siFVhgeFZrjcIqyFfQKveU 4KAELr6oshdxbGcmpZXIXAfXTyjtkLj22HZLmfHe+bjvOn+80juznKoHww8TS2SexkVa +B4jBVP4iDoXuLPt4iKqtWzUFbIE91P9cRM6iw8z0y6oR8FzBaxlzffU3yxKKC/Gwy/m dsxwwl3y1oi7+M/2nfSmjX6nucKs7W14KMqeEiQIrZ9s/rjhLs58K0geBXATC9s0ivzl 8ftw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=CCRAsgToQgHhPW/nCZZa8hOuTGRXgak+R+4BB5wHWkU=; b=QlLl00EzozN1kKMB+WWrP9+BpbXpQN7TgSRJNDqsKz7Z9+yRLPWs7KtqlXz+3vMhQx mhsud5I7eBBc6eOe++Q1TI6FPruYR7CPizGCiQHQYmfwYgGR1XJ6eCbSUWco1t6Q7GS5 5NDMf0b88YuQVtQH672k2vCmOI/cpZL+38hS50AQcWB+at0yNc0P8EULyQVFQEy7crYZ JxBXY3BuCYHMi2NFW8WEeQdDvLEpxWAqycX2orf4fRhHM4uJ8w6Yrsx7FnryGbgFvloM rRX0RE8Oj5PvpCx5AZKfjW/44/JHJ8aZyFzZ9RCg+r3XgP+vLx5V+oYDh6K2V+71fmXC KKqw== X-Gm-Message-State: AElRT7HeqA+X/TmfsnqUk/7KzWjjqYZ1cmNjmLPbzd5eveCHkn7gJ9dG gu+f/QN7FVqSvazvDvLIHMckUGur4wlXNtwXNF8Kfqd7 X-Google-Smtp-Source: AIpwx4+if/9UMn5bfn8deme+Gg4n+P2pDYasSFOjsL7OMvSvcsblgf5Kqx9vDNi1Gp3l68PcE6oXplY9Ipntu5QrQCs= X-Received: by 2002:a9d:2963:: with SMTP id d90-v6mr3750463otb.396.1522304243412; Wed, 28 Mar 2018 23:17:23 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:ac7:0:0:0:0:0 with HTTP; Wed, 28 Mar 2018 23:17:22 -0700 (PDT) From: Martin Thomson Date: Thu, 29 Mar 2018 17:17:22 +1100 Message-ID: To: SIPCORE Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [sipcore] Review of sip-push-10 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, 29 Mar 2018 06:17:27 -0000 I really don't know what to make of this draft. On the one hand, it's clearly a sensible addition to the protocol based on the current environment. But then it's also clearly doing nothing but further entrenching the two dominant proprietary push service platforms. I also found the prose a little hard to follow. Some restructuring might go a long way to improving clarity. The description of RFC 8292 integration isn't particularly helpful. Does the UA register once, discover that the Proxy/Registrar supports vapid, then re-register immediately? None of that is well-described. The document talks in passing about its assumptions about the push message, but never actually states the requirements on that message. Please add a clear description of what the message is. For instance, is any message sufficient? Or does the message have to be empty? What would it mean to receive a message with a payload? An important limitation of APNS and FCM here is that a single app can't hold multiple contexts, therefore any message it receives will cause re-registration even if the message was for other purposes ("Scarves, 5% off until Monday!", bam). You should document that. Section 4: Can a UA include Feature-Caps on its own? Maybe it doesn't want to do all the push service stuff until it knows that the server supports the features it needs (vapid for example). Section 5.3.1: I don't understand the relevance of all the 423-related text here. Maybe it's a lack of clarity about the expected processing model. FWIW, the only thing of value in this very long paragraph is that sip.pns is not to be included with a 423. However, I would argue the opposite and that sip.pns is most valuable in a 423. For example, a UA knows that it only stays alive for a short time, so it conservatively creates registrations with a short duration. That's not very useful, but the UA might expect to only be available while the app is in the foreground where it is able to refresh frequently. However, if it receives a signal from the proxy/registrar that indicates push support (in a 423 perhaps), it might be inspired to extend the registration and rely on push. How would a proxy decide to send a 555 response or ignore the push information in the REGISTER request? Why would a proxy add Feature-Caps instead of just stripping out the push parameters? (That's probably a consequence of my ignorance of REGISTER procedures, but I am curious.) Why does the Feature-Caps need a value? The downstream proxy only needs to know that push is taken care of, not which push is in use. Is it just for symmetry with the downstream notification? What value does the parameter take? The pn-provider label? Section 5.3.2: Why include so much text here? If the proxy considers the UA to be registered - and only challenged with respect to active connectivity - then normal SIP processing applies with only one tweak: send a push message and wait until the registration is restored. The idea that the proxy might be able to correlate a REGISTER request that includes a different contact URI with this new transaction/dialog is a little baffling - either the registration is restored with the right contact, or the registration doesn't happen and message delivery will ultimately time out and fail. In this regard, the only text you need is the timeout text you have near the end of this section. Section 6 contains no information. If anything, you can use NAT as further justification for use of a push notification service, but it doesn't warrant an entire section. Section 7.5: I don't understand the purpose behind sip.pnsreg is defined here. How is this different than, say, the usual registration expiration logic? Maybe this goes back to the basic registration logic. Nits: Section 7.6: typo: indciates Section 11: "When Firebase..." seems to be copy-pasta s/push URI/push subscription URI/ I don't think that you need to include a URI for RFC 8030. From nobody Thu Mar 29 00:45:26 2018 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 CD65012708C for ; Thu, 29 Mar 2018 00:45:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 K81WGIlS0xyu for ; Thu, 29 Mar 2018 00:45: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 BA2A31201F8 for ; Thu, 29 Mar 2018 00:45:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1522309520; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=eCnfajzjLaH5T4YCZjUDvwp4zID14brmyYMPe4ZAOAM=; b=Y5ABxPrNbKM/3knMWNBkvETIcT8PKFe51C6++MM/uGP42mlAvaCCodifPK1ZZln3 M40dJY+DjCiOqifNXmb1FXrTafNGQYy3Qe/G1Kv7/Z9n4hl4ynyRpTQgIqfExB2i RAiTWwVINBMEe38sx0IJ0zg9xuXSy5rfnffuELsm/0Y=; X-AuditID: c1b4fb2d-6dc359c00000236d-f1-5abc99908082 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id E8.90.09069.0999CBA5; Thu, 29 Mar 2018 09:45:20 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.115]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0382.000; Thu, 29 Mar 2018 09:41:48 +0200 From: Christer Holmberg To: Martin Thomson , SIPCORE Thread-Topic: [sipcore] Review of sip-push-10 - Martin's comments Thread-Index: AQHTxzFk+pt5NUbw9Eqs6AfOyXoE1w== Date: Thu, 29 Mar 2018 07:41: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: [131.160.50.130] Content-Type: text/plain; charset="Windows-1252" Content-ID: <367E9914E265294BB0235A33A4982217@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUyM2K7je6EmXuiDK5N0be4duYfo8XXH5vY HJg8ds66y+6xZMlPpgCmKC6blNSczLLUIn27BK6Mqc0/2Qt+6FVsnfyMpYFxlWoXIyeHhICJ xJYz3SxdjFwcQgJHGCXaZu1ihnCWMEo8/bCFtYuRg4NNwEKi+582SIOIgKfE/VVrGUHCwgIO EtNazUBMEQFHieV/WCEq9CT2N69nBrFZBFQlLnyayAJSwitgLfF0MwdImFFATOL7qTVMIDaz gLjErSfzmSCuEZBYsuc8M4QtKvHy8T+wkaJAIzecuM0OMkZCQEni9gYniFYDiffn5jND2NYS nd9PQ9naEssWvgazeQUEJU7OfMIygVFkFpJts5C0z0LSPgtJ+ywk7QsYWVcxihanFhfnphsZ 66UWZSYXF+fn6eWllmxiBMbHwS2/dXcwrn7teIhRgINRiYe3qHVPlBBrYllxZe4hRgkOZiUR 3vcau6OEeFMSK6tSi/Lji0pzUosPMUpzsCiJ85705I0SEkhPLEnNTk0tSC2CyTJxcEo1MHp+ vOHewh/SW3nx9kfXG+Kerae/XbeRmGA2902Tmf+key+tC4qP6t+7+6TR/8PCqq1n8wubEk75 TedbJvD+DcMit3lLxDfe+rGY23XSX5vGvX1z953i01my+VsV/9slp5tu+7afnv7QeYZowQGL Q2u0XnC0+Mz56jPbdYH3Hx3BM+95TxX9sn+vxFKckWioxVxUnAgAwbH4y4sCAAA= Archived-At: Subject: Re: [sipcore] Review of sip-push-10 - Martin's comments 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, 29 Mar 2018 07:45:25 -0000 Hi Martin, Thank You for the review! Please see inline. >I also found the prose a little hard to follow. Some restructuring >might go a long way to improving clarity. > >The description of RFC 8292 integration isn't particularly helpful. >Does the UA register once, discover that the Proxy/Registrar supports >vapid, then re-register immediately? None of that is well-described. I think this is related to your comment on Section 4. See below. --- >The document talks in passing about its assumptions about the push >message, but never actually states the requirements on that message. >Please add a clear description of what the message is. For instance, >is any message sufficient? Or does the message have to be empty? >What would it mean to receive a message with a payload? The text does say that the proxy MUST NOT include any payload. Only the push notification itself is used. >An important limitation of APNS and FCM here is that a single app >can't hold multiple contexts, therefore any message it receives will >cause re-registration even if the message was for other purposes >("Scarves, 5% off until Monday!", bam). You should document that. Ok, I will look into that. --- >Section 4: >Can a UA include Feature-Caps on its own? Maybe it doesn't want to do >all the push service stuff until it knows that the server supports the >features it needs (vapid for example). A UA cannot include a Feature-Caps. But, we could define a sip.pns media feature tag, that a UA can include to indicate generic support of SIP Push, but it would not be used to request usage of SIP Push. Then, when the proxy receives it, it would return the normal information about what it supports, but it would not yet start requesting push notifications. --- >Section 5.3.1: >I don't understand the relevance of all the 423-related text here. >Maybe it's a lack of clarity about the expected processing model. >FWIW, the only thing of value in this very long paragraph is that >sip.pns is not to be included with a 423. > >However, I would argue the opposite and that sip.pns is most valuable >in a 423. The text does not say that sip.pns is not included in 423. But, the text does not say that sip.pns IS included either, so I can add text about that. >For example, a UA knows that it only stays alive for a >short time, so it conservatively creates registrations with a short >duration. That's not very useful, but the UA might expect to only be >available while the app is in the foreground where it is able to >refresh frequently. However, if it receives a signal from the >proxy/registrar that indicates push support (in a 423 perhaps), it >might be inspired to extend the registration and rely on push. > >How would a proxy decide to send a 555 response or ignore the push >information in the REGISTER request? Local configuration. >Why would a proxy add Feature-Caps instead of just stripping out the >push parameters? (That's probably a consequence of my ignorance of >REGISTER procedures, but I am curious.) Why does the Feature-Caps >need a value? The downstream proxy only needs to know that push is >taken care of, not which push is in use. Is it just for symmetry with >the downstream notification? There is no technical reson for including a value - it is enough to inform the downstream proxy that push is taken care of. It=B9s just for information. I can add a note indicating that. >What value does the parameter take? The pn-provider label? Yes. --- >Section 5.3.2: >Why include so much text here? If the proxy considers the UA to be >registered - and only challenged with respect to active connectivity - >then normal SIP processing applies with only one tweak: send a push >message and wait until the registration is restored. > >The idea that the proxy might be able to correlate a REGISTER request >that includes a different contact URI with this new transaction/dialog >is a little baffling - either the registration is restored with the >right contact, or the registration doesn't happen and message delivery >will ultimately time out and fail. The text covers the =B3race condition=B2 case where the UA changes its cont= act as the same time as the proxy receives a request towards the UA, using the old contact. The request should not be forwarded towards the UA using the old contact. >In this regard, the only text you need is the timeout text you have near >the end of this section. In this case I disagree. I think the text is needed. In addition to the =B3race condition=B2 and timeout cases, it also specifies that the proxy ne= eds to wait for the REGISTER response before forwarding the request, and what the proxy does in case of a non-2xx REGISTER response. --- >Section 6 contains no information. If anything, you can use NAT as >further justification for use of a push notification service, but it >doesn't warrant an entire section. I suggest to move the first paragraph to Section 4, and second paragraph to Section 5.3.2. --- >Section 7.5: >I don't understand the purpose behind sip.pnsreg is defined here. How >is this different than, say, the usual registration expiration logic? >Maybe this goes back to the basic registration logic. It is used to indicate that a UA can use e.g., internal timers to send periodic re-registrations, but still want to use SIP Push when there are incoming requests. --- >Nits: >Section 7.6: typo: indciates Will fix. --- >Section 11: "When Firebase..." seems to be copy-pasta Will fix. =B3When Generic Event Delivery Using HTTP Push is used,=8A" >s/push URI/push subscription URI/ "push URI=B2 terminology is more common in RFC 8030, so that=B9s why I used it. But I can replace it with =B3push subscription URI=B2. >I don't think that you need to include a URI for RFC 8030. I=B9ll remove it. Regards, Christer From nobody Thu Mar 29 04:08:14 2018 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 A326B12D93F for ; Thu, 29 Mar 2018 04:08:12 -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_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=ericsson.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 TnVGVm1RcdOL for ; Thu, 29 Mar 2018 04:08:09 -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 116F4126B7E for ; Thu, 29 Mar 2018 04:08:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1522321687; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=2PuHhTi6bJpTcwXzK1dggC7TwQFHNtJAL2lfmKfrJ6w=; b=B91OjGF0M9ePwwW1AWFOpoA4FKePywLAadF/Gwy/sZeNEA/XnZLbZgCWs2IA2H0X rK0h3y2Qm1qMnxuqIu4DohaRZQpXWkvDVA2TUfjVGSLXQ8wzy4zY7Rl6nHQob+4U HPER696Ea6Zqn4CrB6+GbCdh2KIZNnrvMnFmOhTPyCQ=; X-AuditID: c1b4fb2d-1f6969c0000073d9-b9-5abcc91754f0 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id DE.9C.29657.719CCBA5; Thu, 29 Mar 2018 13:08:07 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.115]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0382.000; Thu, 29 Mar 2018 13:07:57 +0200 From: Christer Holmberg To: Roman Shpount , Paul Kyzivat CC: SIPCORE Thread-Topic: [sipcore] session-timer fix Thread-Index: AQHTwfCeyHYsx4XVTkSHOLQKDcONKqPdSEtwgAhcbACAABDAgIAANGeAgAARLYCAACxJgP//8R6AgAERIAA= Date: Thu, 29 Mar 2018 11:07:57 +0000 Message-ID: References: <949dba9e-33b7-66b9-1b16-d25902f65367@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B72E06C39@ESESSMB102.ericsson.se> <7594FB04B1934943A5C02806D1A2204B72E37EC9@ESESSMB109.ericsson.se> <9d3fd31a-af1b-3328-23e6-05c11e7978f0@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B72E38364@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: [131.160.50.130] Content-Type: multipart/alternative; boundary="_000_D6E276C42D43Dchristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMIsWRmVeSWpSXmKPExsUyM2K7t674yT1RBguvC1is2HCA1WLGhanM Fl9/bGJzYPb4+/4Dk8eSJT+ZPG5NKQhgjuKySUnNySxLLdK3S+DKWDX/BnvBjSdMFc8fzmFr YJy5k6mLkZNDQsBE4uf3U8xdjFwcQgJHGCV+nzzGAuEsYZSY2viAvYuRg4NNwEKi+582SIOI gLdEX18HO4jNLCAncf3DRjYQW1hAQ2L/2p9sEDWaEn9mb2CGsJMkpkxbzgwyhkVAVWLBR0WQ MK+AtcTEF09ZQGwhgQ/MEudbnUFsToFAiZ+vehhBbEYBMYnvp9YwQawSl7j1ZD7UzQISS/ac Z4awRSVePv7HCmKLCuhJbDhxG+xiCQElidsbnEBMZoEEiZN36yG2CkqcnPmEZQKj6CwkQ2ch VM1CUgVRYiDx/tx8ZghbW2LZwtdQtr7Exi9nGSFsa4krV3awIatZwMixilG0OLW4ODfdyFgv tSgzubg4P08vL7VkEyMwKg9u+a27g3H1a8dDjAIcjEo8vHqr9kQJsSaWFVfmHmKU4GBWEuF9 r7E7Sog3JbGyKrUoP76oNCe1+BCjNAeLkjhEtUB6YklqdmpqQWoRTJaJg1OqgTHeuCVCYaWm 3UJPl1c8s9sfN9j3lPh97M0/Ib58ym4BFgv9rfp2bfJvj05ceW7p20SNbxuCTNJk+2Xjt7pm SEkk/3z3q6GSbc6tuyw+1//KTxQ9LrYjXl2EYb8q0+trj0xW6PZfU3MwEzZ3c/3hecVOooOl N6fgZvS7INkgxa+5Hb8VFYM/K7EUZyQaajEXFScCADtLeGzGAgAA Archived-At: Subject: Re: [sipcore] session-timer fix 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, 29 Mar 2018 11:08:13 -0000 --_000_D6E276C42D43Dchristerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Roman, > First of all, I agree that in the initial scenario, UA in step 7 should h= ave responded with S-E:uas in 200 OK for Update. > > Furthermore, if UA in step 7 did respond without S-E, or with S-E:uac, AS= should not have sent 480 in step 9. It should have sent S-E:uas. > > Generally, what I am proposing is that, S-E header should be generated ba= sed on the S-E status when request or response is generated. If there are m= ultiple inter-lapping transactions S-E state can change and > S-E state in the response should be set to the S-E value when response is= generated, not when the original request is received. In case of your exam= ple, S-E state in step 9 should be based on results of the UPDATE > transaction, not the initial INVITE. This is why it should be sent to S-E= :uas. > > Furthermore, we should restrict (with SHOULD, not MUST since existing UA = already violate this) that UA should avoid generating requests which will c= hange the current S-E status when another transaction which negotiates S-E = is in progress. > Specifically, in the example provided, UPDATE in step 5 should be generat= ed with S-E:uas (as it was correctly generated in your example). Responses = generated when another transaction is in progress should be generated in a = way that avoids > changing the current S-E status (response in step 7 should have been S-E= :has). > > >Finally, even with all of these restrictions there are situations when S-E= status is unclear due to timing. For instance when UPDATE changing the S-E= status is sent at roughly the same time as 200 OK for an INVITE. In this c= ase, UA cannot distinguish > >Scenario A: >1) UA->AS: INVITE/SE >2) AS->UA: UPDATE/SE:uac >3) UA-> AS: 200(UPDATE)/SE:uac >4) AS-> UA : 200(INVITE) /SE:uac > >and > >Scenario B: >1) UA->AS: INVITE/SE >2) AS-> UA : 200(INVITE) /SE:uac >3) AS->UA: UPDATE/SE:uac >4) UA-> AS: 200(UPDATE)/SE:uac > > Between those two scenarios, either AS or UA becomes a refresher based on= the message delivery timing. Why would the AS send SE:mac in message 4)? > > These scenarios do not violate any of the proposed rules and can be encou= ntered with existing SIP implementations. Also, these ambiguity cannot be r= esolved with refusing UPDATE request with retry after since UA does not kno= w that 200 OK and UPDATE are sent close together. > > My suggestion is to specify that 200 OK changing S-E status MUST NOT be s= ent when UPDATE transaction is in progress. UPDATE changing S-E status MUST= NOT be sent when 200 OK was sent but ACK was not yet received. > > I would be very interested if you can think of other, more robust ways to= detect and deal with this situation which require modifications only for o= ne of the SIP UA. I am not sure whether your suggestion is any different than mine: UPDATE re= quests/responses sent within an going INVITE s-e negotiation must not chang= e the roles =96 they must reflect whatever was sent in the INVITE request a= nd will be sent in the 200 (INVITE) response. Regards, Christer On Wed, Mar 28, 2018 at 4:51 PM, Christer Holmberg > wrote: Hi, >>>> Ok, I checked some old e-mails, and had a chat with the internal >>>> people that informed me about the problem. >>>> >>>> The UPDATE request with refresher=3Duas is *NOT* the problem. They >>>> have the same assumption as Paul, Jonathan etc - the value is >>>> indicated per transaction. So, UPDATE with refresher=3Duas is ok. My >>>> apologies for mixing that up. >>>> >>>> It=B9s the UPDATE 200 OK response, where the proxy inserts >>>> refresher=3Duac, that causes the problem. >>>> >>>> So, one alternative would be to allow UPDATE requests/responses sent >>>> while the s-t negotiation is ongoing are handled as defined in RFC >>>> 4028, but that the refresher value must not be changed. >>>> >>>> In the case below, that means that the UA needs to include s-t >>>> information in the UPDATE response (message #7). >>> >>> That seems like a simpler and cleaner fix, at least for this case. >>> >>> To go that way we need to consider other cases. >>> >>> In particular, is the UA *required* to include the s-t stuff in the UPD= ATE if it supports s-t? >> >> Min-SE is currently MUST. >> >> Session-Expires is currently SHOULD. I guess we could change that to MUS= T. >> >>> What if the UA had omitted the refresher in the INVITE? Presumably then= the AS chooses and puts its choice in the UPDATE. >>> >>> And once s-e in invite has been responded to with an s-e in an UPDATE, = does that finish the negotiation? >> >> Yes. The INVITE transaction itself does not matter - it depends on wheth= er s-e is negotiated within the INVITE >> transaction or not that matters. If there is no s-e negotiation in the I= NVITE transaction, the UPDATE is treated as >> any mid-dialog request as far as s-e is concerned. >> >>> Then do subsequent messages within the invite transaction and embedded = UPDATES repeat the agreed upon result? >>> Or can they do the negotiation over? >> >> Since there is no ongoing s-e negotiation, I see no reason why they can'= t. >> >> In general, unless such text already exist, I think we should recommend = against re-negotiating , unless there is a good reason for it. > > I guess I didn't make my concerns clear. > > ISTM we could use O/A rules as a *model* here: > > A negotiation initiated in an INVITE can be completed in a reliable respo= nse to the INVITE. Or it can be completed in an UPDATE. > Once complete, another negotiation is forbidden within the same INVITE tr= ansaction. I guess we would change the rules a bit in > that we don't allow the negotiation to be completed in a reliable provisi= onal. (I would like to permit that, but I think it might be a step too far = for > compatibility.) > > But, if we forbid further negotiation within the same INVITE, what do we = do instead if there are further UPDATEs? With O/A we can just leave the off= ers out. > With s-t, leaving it out normally means negotiating it off. > So either we change that (which we have already explored), or else I gues= s we "negotiate" again but agree to only repeat what has already been > negotiated. (And if we make that rule, what do we do if it is violated? E= specially, what if a proxy violates it?) My idea was that, if UPDATEs are send during an ongoing INVITE s-t negotiat= ion, the s-t information in the UPDATEs must reflect the ongoing negotiatio= n (similar as sending SDP in an unreliable 18x - it is not really an answer= , but it must be a copy of the to-be-sent-answer). So, in my example, the s= -t information in the UPDATE request from the AS must reflect what the AS w= ill eventually send in the 200 OK to the INVITE. And, the s-t information i= n the UPDATE response from the UA must reflect what the UA sent in the INVI= TE. > Alternately, once the s-t negotiation has completed, we could simply allo= w another negotiation to be initiated within the same > invite transaction, even though it seems like a stupid thing to do. I agree. Regards, Christer > Regards, > > Christer > > > >> On 23/03/18 22:48, "sipcore on behalf of Christer Holmberg" >> on behalf of >> christer.holmberg@ericsson.com> >> wrote: >> >>> Hi Paul, >>> >>> You say (and it was indicated in the meeting): >>> >>> "I think it is, since the uac/uas roles are relative to >>> the direction of the individual request," >>> >>> Assuming that the AS and UA are implemented that way, the problem >>> still occurs when the AS receives (8), where the refresher >>> >>> >>> >>> >>>> Here is the primary use case flow that has been reported as the >>>> motivating case for the draft. (I've reformatted it for ease in >>>> typing.) >>>> >>>> 1) UA->Proxy: INVITE/SE:uac >>>> 2) Proxy->AS: INVITE/SE:uac >>>> 3) AS->Proxy: 18x/no-SE >>>> 4) Proxy->UA: 18x/no-SE >>>> 5) AS->Proxy: UPDATE/SE:uas >>>> 6) Proxy->UA: UPDATE/SE:uas >>>> 7) UA->Proxy: 200(UPDATE)/no-SE >>>> 8) Proxy->AS: 200(UPDATE)/SE:uac >>>> 9) AS->Proxy: 480(INVITE) >>>> 10) Proxy->UA: 480(INVITE) >>>> >>>> Some observations on the above: >>>> >>>> - in (5) the AS includes SE in the UPDATE, while in (7) the UA >>>> doesn't include SE in the response to the UPDATE. This seems >>>> to reflect a difference of opinion by the implementors of >>>> the UA and AS about what 4028 expects in this situation. >>>> This ambiguity needs to be resolved, and will require changes >>>> in some implementations. >>> >>> Correct. This is a case where UPDATE is received while the S-T >>> negotiation is still ongoing. >>> >>>> - The 480 in (9) is caused by the AS objecting to the "uac" >>>> in (8) because it is in conflict with the "uas" in (5). >>>> This in turn is caused by the proxy including the "uac" >>>> in (8) because it is following the rules and thinks that >>>> the UA doesn't support S-T. This of course isn't the >>>> situation. >>> >>> Shouldn't the proxy know that the UA supports S-T, due to (1)? >>> >>>> - There has been some discussion about whether the "uas" >>>> value in (5) is consistent with the "uac" value in (1). >>>> I think it is, since the uac/uas roles are relative to >>>> the direction of the individual request, and (5) is >>>> going in the opposite direction of (1). >>> >>> Let's assume it is like that. >>> >>>> But this >>>> doesn't seem to affect the rest of the analysis. >>>> If the refresher in the UPDATE was inconsistent with >>>> that in the INVITE then I would expect the UA to send >>>> an error response to the UPDATE. >>>> >>>> ISTM that at least part of the fix for this must be to fix the >>>> ambiguity about whether SE is to be included in an UPDATE and its >>>> response that are embedded in an INVITE transaction. The existing >>>> draft does address this one way. >>> >>> Yes. >>> >>>> Another way to address it would be to require SE to be included in >>>> both the UPDATE and its response, in a way consistent with what was >>>> in the INVITE and will eventually be in the response to the INVITE. >>> >>> Yes. >>> >>>> A much different way would be to require that the timer negotiation >>>> in an INVITE be completed in the first reliable response to the >>>> INVITE, either 2xx or reliable 1xx. Then any UPDATE that followed >>>> within the transaction would presumably start a new timer >>>> negotiation. >>> >>> Yes. >>> >>>> I'll also observe that this entire discussion has focused on the >>>> negotiation of the refresher. But there is a comparable issue >>>> around negotiating the duration of the timer. That ought to be >>>> sorted out as part of the same fix. >>> >>> Yes. >>> >>> 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 --_000_D6E276C42D43Dchristerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <7BAA5C5D40CC0B4797E35837B50ACB4D@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi Roman,

> First of all, I agree that in the initial scenario, UA in step 7 = should have responded with S-E:uas in 200 OK for Update.
>
> Furthermore, if UA in step 7 did respond without S-E, or with S-E= :uac, AS should not have sent 480 in step 9. It should have sent S-E:uas.
>
> Generally, what I am proposing is that, S-E header should be gene= rated based on the S-E status when request or response is generated. If the= re are multiple inter-lapping transactions S-E state can change and
> S-E state in the response should be set to the S-E value when res= ponse is generated, not when the original request is received. In case of y= our example, S-E state in step 9 should be based on results of the UPDATE&n= bsp;
> transaction, not the initial INVITE. This is why it should be sen= t to S-E:uas.
>
> Furthermore, we should restrict (with SHOULD, not MUST since exis= ting UA already violate this) that UA should avoid generating requests whic= h will change the current S-E status when another transaction which negotia= tes S-E is in progress.
> Specifically, in the example provided, UPDATE in step 5 should be= generated with S-E:uas (as it was correctly generated in your example). Re= sponses generated when another transaction is in progress should be generat= ed in a way that avoids 
> changing the current S-E status (response in step 7 should have b= een  S-E:has).
>
>
>Finally, even with all of these restrictions there are situations when S-E status i= s unclear due to timing. For instance when UPDATE changing the S-E status i= s sent at roughly the same time as 200 OK for an INVITE. In this case, UA c= annot distinguish
>
>Scenario A:
>1) UA->AS: INVITE/SE
>2) AS->UA: UPDATE/SE:uac
>3) UA-> AS: 200(UPDATE)/SE:uac
>4) AS-> UA : 200(INVITE) /SE:uac 
>
>and
>
>Scenario B:
>1) UA->AS: INVITE/SE
>2) AS-> UA : 200(INVITE) /SE:uac=  
>3) AS->UA: UPDATE/SE:uac
>4) UA-> AS: 200(UPDATE)/SE:uac 
>
> Between those two scenarios, either AS or UA becomes a refresher based on the message delivery timing.<= /span>

Why would the AS send SE:mac in message 4)?
>
> These scenarios do not violate any of the proposed rules and can be encountered with exis= ting SIP implementations. Also, these ambiguity cannot be resolved with ref= using UPDATE request with retry after since UA does not know that 200 OK and UPDATE are sent close together.
>
> My suggestion is to specify that 200 OK changing S-E status MUST NOT be se= nt when UPDATE transaction is in progress. UPDATE changing S-E status MUST = NOT be sent when 200 OK was sent but ACK was not yet received.
>
> I would be very interested if you can think of other, more robust ways to = detect and deal with this situation which require modifications only for on= e of the SIP UA.

I am not sure whether your suggestion is any different than mine: UPDA= TE requests/responses sent within an going INVITE s-e negotiation must not = change the roles =96 they must reflect whatever was sent in the INVITE requ= est and will be sent in the 200 (INVITE) response.

Regards,

Christer





On Wed, Mar 28, 2018 at 4:51 PM, Christer Holmbe= rg <chr= ister.holmberg@ericsson.com> wrote:
Hi,

>>>> Ok, I checked some old e-mails, and had a chat with the in= ternal
>>>> people that informed me about the problem.
>>>>
>>>> The UPDATE request with refresher=3Duas is *NOT* the probl= em. They
>>>> have the same assumption as Paul, Jonathan etc - the value= is
>>>> indicated per transaction. So, UPDATE with refresher=3Duas= is ok. My
>>>> apologies for mixing that up.
>>>>
>>>> It=B9s the UPDATE 200 OK response, where the proxy inserts=
>>>> refresher=3Duac, that causes the problem.
>>>>
>>>> So, one alternative would be to allow UPDATE requests/resp= onses sent
>>>> while the s-t negotiation is ongoing are handled as define= d in RFC
>>>> 4028, but that the refresher value must not be changed. >>>>
>>>> In the case below, that means that the UA needs to include= s-t
>>>> information in the UPDATE response (message #7).
>>>
>>> That seems like a simpler and cleaner fix, at least for this c= ase.
>>>
>>> To go that way we need to consider other cases.
>>>
>>> In particular, is the UA *required* to include the s-t stuff i= n the UPDATE if it supports s-t?
>>
>> Min-SE is currently MUST.
>>
>> Session-Expires is currently SHOULD. I guess we could change that = to MUST.
>>
>>> What if the UA had omitted the refresher in the INVITE? Presum= ably then the AS chooses and puts its choice in the UPDATE.
>>>
>>> And once s-e in invite has been responded to with an s-e in an= UPDATE, does that finish the negotiation?
>>
>> Yes. The INVITE transaction itself does not matter - it depends on= whether s-e is negotiated within the INVITE
>> transaction or not that matters. If there is no s-e negotiation in= the INVITE transaction, the UPDATE is treated as
>> any mid-dialog request as far as s-e is concerned.
>>
>>> Then do subsequent messages within the invite transaction and = embedded UPDATES repeat the agreed upon result?
>>> Or can they do the negotiation over?
>>
>> Since there is no ongoing s-e negotiation, I see no reason why the= y can't.
>>
>> In general, unless such text already exist, I think we should reco= mmend against re-negotiating , unless there is a good reason for it.
>
> I guess I didn't make my concerns clear.
>
> ISTM we could use O/A rules as a *model* here:
>
> A negotiation initiated in an INVITE can be completed in a reliable re= sponse to the INVITE. Or it can be completed in an UPDATE.
> Once complete, another negotiation is forbidden within the same INVITE= transaction. I guess we would change the rules a bit in
> that we don't allow the negotiation to be completed in a reliable prov= isional. (I would like to permit that, but I think it might be a step too f= ar for
> compatibility.)
>
> But, if we forbid further negotiation within the same INVITE, what do = we do instead if there are further UPDATEs? With O/A we can just leave the = offers out.
> With s-t, leaving it out normally means negotiating it off.
> So either we change that (which we have already explored), or else I g= uess we "negotiate" again but agree to only repeat what has alrea= dy been
> negotiated. (And if we make that rule, what do we do if it is violated= ? Especially, what if a proxy violates it?)

My idea was that, if UPDATEs are send during an ongoing INVITE s-t negotiat= ion, the s-t information in the UPDATEs must reflect the ongoing negotiatio= n (similar as sending SDP in an unreliable 18x - it is not really an answer= , but it must be a copy of the to-be-sent-answer). So, in my example, the s-t information in the UPDATE request from the AS m= ust reflect what the AS will eventually send in the 200 OK to the INVITE. A= nd, the s-t information in the UPDATE response from the UA must reflect wha= t the UA sent in the INVITE.

> Alternately, once the s-t negotiation has completed, we could simply a= llow another negotiation to be initiated within the same
> invite transaction, even though it seems like a stupid thing to do.
I agree.

Regards,

Christer




> Regards,
>
> Christer
>
>
>
>> On 23/03/18 22:48, "sipcore on behalf of Christer Holmberg&qu= ot;
>> <sipcore-bounces@ie= tf.org on behalf of
>> christer.holmber= g@ericsson.com>
>> wrote:
>>
>>> Hi Paul,
>>>
>>> You say (and it was indicated in the meeting):
>>>
>>>     "I think it is, since the uac/uas role= s are relative to
>>>     the direction of the individual request,&qu= ot;
>>>
>>> Assuming that the AS and UA are implemented that way, the prob= lem
>>> still occurs when the AS receives (8), where the refresher
>>>
>>>
>>>
>>>
>>>> Here is the primary use case flow that has been reported a= s the
>>>> motivating case for the draft. (I've reformatted it for ea= se in
>>>> typing.)
>>>>
>>>>    1) UA->Proxy: INVITE/SE:uac
>>>>    2) Proxy->AS: INVITE/SE:uac
>>>>    3) AS->Proxy: 18x/no-SE
>>>>    4) Proxy->UA: 18x/no-SE
>>>>    5) AS->Proxy: UPDATE/SE:uas
>>>>    6) Proxy->UA: UPDATE/SE:uas
>>>>    7) UA->Proxy: 200(UPDATE)/no-SE
>>>>    8) Proxy->AS: 200(UPDATE)/SE:uac
>>>>    9) AS->Proxy: 480(INVITE)
>>>> 10) Proxy->UA: 480(INVITE)
>>>>
>>>> Some observations on the above:
>>>>
>>>> - in (5) the AS includes SE in the UPDATE, while in (7) th= e UA
>>>>     doesn't include SE in the response to t= he UPDATE. This seems
>>>>     to reflect a difference of opinion by t= he implementors of
>>>>     the UA and AS about what 4028 expects i= n this situation.
>>>>     This ambiguity needs to be resolved, an= d will require changes
>>>>     in some implementations.
>>>
>>> Correct. This is a case where UPDATE is received while the S-T=
>>> negotiation is still ongoing.
>>>
>>>> - The 480 in (9) is caused by the AS objecting to the &quo= t;uac"
>>>>     in (8) because it is in conflict with t= he "uas" in (5).
>>>>     This in turn is caused by the proxy inc= luding the "uac"
>>>>     in (8) because it is following the rule= s and thinks that
>>>>     the UA doesn't support S-T. This of cou= rse isn't the
>>>>     situation.
>>>
>>> Shouldn't the proxy know that the UA supports S-T, due to (1)?=
>>>
>>>> - There has been some discussion about whether the "u= as"
>>>>     value in (5) is consistent with the &qu= ot;uac" value in (1).
>>>>     I think it is, since the uac/uas roles = are relative to
>>>>     the direction of the individual request= , and (5) is
>>>>     going in the opposite direction of (1).=
>>>
>>> Let's assume it is like that.
>>>
>>>> But this
>>>>     doesn't seem to affect the rest of the = analysis.
>>>>     If the refresher in the UPDATE was inco= nsistent with
>>>>     that in the INVITE then I would expect = the UA to send
>>>>     an error response to the UPDATE.
>>>>
>>>> ISTM that at least part of the fix for this must be to fix= the
>>>> ambiguity about whether SE is to be included in an UPDATE = and its
>>>> response that are embedded in an INVITE transaction. The e= xisting
>>>> draft does address this one way.
>>>
>>> Yes.
>>>
>>>> Another way to address it would be to require SE to be inc= luded in
>>>> both the UPDATE and its response, in a way consistent with= what was
>>>> in the INVITE and will eventually be in the response to th= e INVITE.
>>>
>>> Yes.
>>>
>>>> A much different way would be to require that the timer ne= gotiation
>>>> in an INVITE be completed in the first reliable response t= o the
>>>> INVITE, either 2xx or reliable 1xx. Then any UPDATE that f= ollowed
>>>> within the transaction would presumably start a new timer<= br> >>>> negotiation.
>>>
>>> Yes.
>>>
>>>> I'll also observe that this entire discussion has focused = on the
>>>> negotiation of the refresher. But there is a comparable is= sue
>>>> around negotiating the duration of the timer. That ought t= o be
>>>> sorted out as part of the same fix.
>>>
>>> Yes.
>>>
>>> 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<= br>

--_000_D6E276C42D43Dchristerholmbergericssoncom_-- From nobody Thu Mar 29 04:38:11 2018 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 BF6D512DA05 for ; Thu, 29 Mar 2018 04:38:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 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, URIBL_BLOCKED=0.001] 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 MyzNaKctrVtr for ; Thu, 29 Mar 2018 04:38:05 -0700 (PDT) Received: from us-smtp-delivery-181.mimecast.com (us-smtp-delivery-181.mimecast.com [216.205.24.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C11AA12DA01 for ; Thu, 29 Mar 2018 04:38:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-rbbn-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=juwG3kvePyR0FUpLWMDXecTwT7eN61m1JBXfVHZUztQ=; b=lkjc6CNVQHqxdhxBwiHjsUO5YRAkRNA+JvtOUWazolHfXCqWrESJvEVZ9Opx7FPh2FzeAxIiqeQ32Apxrpkc0cThEBOgmcG7lR6g2S2i3iA9Mh2tCMXfqliqzPZLxOlJhYzuurL1/egR0uvMIlTAuFUGddtB025gEBFHelj1+/4= Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01lp0182.outbound.protection.outlook.com [216.32.180.182]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-73-5BNZ1OO9NlyO6cqs9IJT7A-1; Thu, 29 Mar 2018 07:37:57 -0400 Received: from CY4PR03MB3160.namprd03.prod.outlook.com (10.171.245.165) by CY4PR03MB2551.namprd03.prod.outlook.com (10.173.41.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.609.10; Thu, 29 Mar 2018 11:37:55 +0000 Received: from CY4PR03MB3160.namprd03.prod.outlook.com ([fe80::d8f0:24ac:4222:be23]) by CY4PR03MB3160.namprd03.prod.outlook.com ([fe80::d8f0:24ac:4222:be23%13]) with mapi id 15.20.0609.012; Thu, 29 Mar 2018 11:37:55 +0000 From: "Asveren, Tolga" To: Christer Holmberg , "marianne.mohali@orange.com" , "sipcore@ietf.org" Thread-Topic: WGLC: draft-ietf-sipcore-originating-cdiv-parameter Thread-Index: AdO8mvHNh2Fu7WwWT5iDJ4VxNB0YgwAP3GCgAArG/7AABt3bAAADWXtwAl77MaAABFtcoAAlTA0A Date: Thu, 29 Mar 2018 11:37:55 +0000 Message-ID: References: <24496_1521199612_5AABA9FC_24496_87_1_8B970F90C584EA4E97D5BAAC9172DBB81D70AC30@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <11272_1521209907_5AABD233_11272_147_2_8B970F90C584EA4E97D5BAAC9172DBB81D70B5E7@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <21553_1522252002_5ABBB8E2_21553_183_1_8B970F90C584EA4E97D5BAAC9172DBB849C9699E@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <7594FB04B1934943A5C02806D1A2204B72E37FC9@ESESSMB109.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B72E37FC9@ESESSMB109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [73.29.251.142] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR03MB2551; 7:Qs7HFmKGACGOougcWtdJi4RKfZQ0rxPJLZZBNmsbUtWECpLvRnsXKydnDBR02o1/hTN1OhyWqvHqSfj8K0deuCua4S5txRTrO1wnl+c78ZldKBUPHw2Fi7qdfHO6RxdrazoKXUpw0/ltlKlsbOKy0WBzOD/a+/W2R4kGLnuojjd6cHnU3pOT4isZ415FaNhEDvJUD9T5zA3xe8n/jpR6wY58okhGbRmvtwvjoMYKx64wEK8EI18BZprlZJFMVYpF; 20:I0AAoNV6C1FRDiYDeD7ANeKnTGORxlP3R25a1g1VaRcCr/71TsOF0ZMuQKnZXrXE1XJ+i7EECZ/J4rv4/LTM1iSK8Kl9SOYZ213B9EmpRVyQoycvPfMWsX83N37btP+es6wEC+y3DBGuvrysJcx6/3Ls7tFqzwUimOPQhgvUcq0= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 44f37a1a-cdd2-4926-02eb-08d5956983ac x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:CY4PR03MB2551; x-ms-traffictypediagnostic: CY4PR03MB2551: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(28532068793085)(131327999870524)(259379197776797)(18271650672692)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231221)(944501327)(52105095)(3002001)(93006095)(93001095)(10201501046)(6041310)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123558120)(20161123564045)(6072148)(201708071742011); SRVR:CY4PR03MB2551; BCL:0; PCL:0; RULEID:; SRVR:CY4PR03MB2551; x-forefront-prvs: 0626C21B10 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(366004)(39380400002)(39860400002)(346002)(396003)(57704003)(199004)(189003)(13464003)(2201001)(5660300001)(5250100002)(6346003)(11346002)(110136005)(446003)(8676002)(7736002)(74316002)(93886005)(102836004)(6436002)(186003)(86362001)(53936002)(606006)(476003)(7696005)(486005)(26005)(6246003)(5890100001)(59450400001)(54896002)(99286004)(55016002)(6306002)(345774005)(2501003)(76176011)(236005)(9686003)(486005)(8936002)(478600001)(81156014)(25786009)(81166006)(229853002)(97736004)(2906002)(14454004)(53546011)(6506007)(68736007)(790700001)(33656002)(966005)(66066001)(316002)(2900100001)(3846002)(106356001)(6116002)(105586002)(19609705001)(3280700002)(3660700001); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR03MB2551; H:CY4PR03MB3160.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-microsoft-antispam-message-info: bwYzqVg2sG7zVlMUGik2pNutDnbOoj5EHdt273Cw/rFE6ZFecTDvptVFXKnkK74do6fWQ0/ANlz/Y5o4uuhCVF1dMSZw1d19nbvES5P8XwNH5NyRAy6b6bVr+T/YkfEJwhl8mYSiPWQmT9f+gODQ+OsHj/S+3Cak+mYB/ZhSNQQzcEGWN2wUVPkA1X8ewO+CIajcsBzpMLfzEdOfGYBWPOxWToGnVuXjgn3kH2l5xH4SynR38pNKt7gkYlOpQ0bPqrsAnKr/MHonL5JLRb39/Fmi23o7L4qG/17SlV27TXGDgDVFvk0gvuBtw//+z/S3SDhQGxWsCIFuVA/QV1z0yQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: rbbn.com X-MS-Exchange-CrossTenant-Network-Message-Id: 44f37a1a-cdd2-4926-02eb-08d5956983ac X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Mar 2018 11:37:55.4892 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR03MB2551 X-MC-Unique: 5BNZ1OO9NlyO6cqs9IJT7A-1 Content-Type: multipart/alternative; boundary="_000_CY4PR03MB3160DC8161CD67336793040EA5A20CY4PR03MB3160namp_" Archived-At: Subject: Re: [sipcore] WGLC: 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: Thu, 29 Mar 2018 11:38:10 -0000 --_000_CY4PR03MB3160DC8161CD67336793040EA5A20CY4PR03MB3160namp_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 QWx0aG91Z2ggSSBhbHNvIGFncmVlIHRoYXQgaXQgaXMgcHJlZmVyYWJsZSB0byBrZWVwIGNoYW5j ZXMgbGltaXRlZCBkdXJpbmcgV0dMQywgdGhpcyBpbiBwcmluY2lwbGUgc2hvdWxkbuKAmXQgbWVh biB0aGF0IHdlIG91Z2h0IHRvIGF2b2lkIHdoYXQgbWFrZXMgc2Vuc2UgZm9yIHRoZSBzYWtlIG9m IOKAnHB1c2hpbmcgaXQgZm9yd2FyZCB3aXRob3V0IGhhc3NsZeKAnS4NCg0KQXMgSSBhbHJlYWR5 IGluZGljYXRlZCBiZWZvcmUsIEkgdGhpbmsgdGhlIGlkZWEgb2YgZW51bWVyYXRpbmcgZGlmZmVy ZW50IHNjZW5hcmlvIGNvbWJpbmF0aW9ucyBpbiBJRVRGLCB3aGljaCBkbyBub3QgcGVydGFpbiB0 byBhY3R1YWwgU0lQIHNlbWFudGljcyBhdCBhbGwsIGlzIG5vdCBhbiBlbGVnYW50IGlkZWEgSU1I Ty4gTm90IGRlZmluaW5nIGFueSB2YWx1ZXMgYW5kIGV4cGVjdGluZyB1c2Ugb2YgKGlmIG5lZWRl ZCBtdWx0aXBsZSkgZ2VuZXJpYy1wYXJhbXMgZm9yIFAtU2VydmVkLVVzZXIgY291bGQgaGF2ZSBi ZWVuIGEgY2xlYW5lciBhcHByb2FjaC4gQWN0dWFsIHZhbHVlcyB3b3VsZCBiZSBkZWZpbmVkIGJ5 IG90aGVyIHN0YW5kYXJkIGZvcmEuDQoNCkZvciBhIHVzZSBjYXNlIGZvciB0ZXJtLWNkaXY6IOKA nERvIG5vdCBkaXZlcnQgaWYgYWxyZWFkeSBkaXZlcnRlZOKAnSwg4oCcaW5kaWNhdGUgaW4gY2Fs bCByZWNvcmRzIHRoYXQgY2FsbCBpcyBkaXZlcnRlZOKAnSAoZm9yIGV4YW1wbGUgdG8gYXBwbHkg YSBkaWZmZXJlbnQgY2hhcmdpbmcgc2NoZW1lKSBjb3VsZCBiZSBhcHBsaWNhYmxlLg0KDQpBcyBh IGZpbmFsIHdvcmQ6IEkgYW0gbm90IHJlbGlnaW91cyBhYm91dCB0aGlzLCBpdCBhbnlob3cgd291 bGRu4oCZdCBmaXggYSBicm9rZW4gbW9kZWwgKGhvbmVzdGx5IEkgcmF0aGVyIHdvdWxkIHByZWZl ciB0aGF0IHRoaXMgZHJhZnQgaXMgd2l0aGRyYXduIGFuZCBhIG5ldyBkcmFmdCBpcyBzdWJtaXR0 ZWQgZXhwbGFpbmluZyB0aGF0IHVzZSBjYXNlcyByZXF1aXJpbmcgbmV3IFAtU2VydmVkLVVzZXIg cGFyYW1ldGVyIHZhbHVlcyBzaG91bGQgdXNlIHRoZSBnZW5lcmljLXBhcmFtIGV4dGVuc2lvbiku IE5vbmV0aGVsZXNzLCBpdCAgc3RpbGwgc291bmRzIG1vcmUgcmVhc29uYWJsZSB0byBtZSB0byBh ZGQgaXQgdGhhbiBub3QuDQoNClNvLCBJIHdpbGwgbGVhdmUgaXQgaGVyZSBhbmQgaG9wZSB0aGUg YXV0aG9ycyB3b3VsZCB0aGluayBjYXJlZnVsbHkvaW4gYSBub24tYmlhc2VkIHdheSBhbmQgZGVj aWRlIGZvciB0aGUgYmVzdCBjb3Vyc2UuDQoNClRoYW5rcywNClRvbGdhDQoNCkZyb206IENocmlz dGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+DQpTZW50OiBXZWRu ZXNkYXksIE1hcmNoIDI4LCAyMDE4IDE6NDMgUE0NClRvOiBtYXJpYW5uZS5tb2hhbGlAb3Jhbmdl LmNvbTsgQXN2ZXJlbiwgVG9sZ2EgPHRhc3ZlcmVuQHJiYm4uY29tPjsgc2lwY29yZUBpZXRmLm9y Zw0KU3ViamVjdDogUkU6IFdHTEM6IGRyYWZ0LWlldGYtc2lwY29yZS1vcmlnaW5hdGluZy1jZGl2 LXBhcmFtZXRlcg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KTk9USUNFOiBU aGlzIGVtYWlsIHdhcyByZWNlaXZlZCBmcm9tIGFuIEVYVEVSTkFMIHNlbmRlcg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCg0KSGksDQoNCk15IGdlbmVyYWwgb3Bpbmlvbiwgbm90 IHNwZWNpZmljIHRvIHRoaXMgZHJhZnQsIGlzIHRoYXQgd2Ugc2hvdWxkIGF2b2lkIGFkZGluZyBu ZXcgZnVuY3Rpb25hbGl0eSBhdCBXR0xDIC0gdW5sZXNzIGl0IGlzIG5lZWRlZCBmb3IgdGhlIGV4 aXN0aW5nIGZ1bmN0aW9uYWxpdHkuDQoNCkluIHRoaXMgY2FzZSwgb25jZSBvcmlkLWRpdiBoYXMg YmVlbiBwdWJsaXNoZWQsIEkgYXNzdW1lIGl0IHdvdWxkIG5vdCBiZSB2ZXJ5IGRpZmZpY3VsdCB0 byBwcm9kdWNlIGEgc2VwYXJhdGUgdGVybS1kaXYgZHJhZnQsIGlmIHRoZXJlIGlzIGludGVyZXN0 Lg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQpGcm9tOiBzaXBjb3JlIFttYWlsdG86c2lwY29yZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgbWFyaWFubmUubW9oYWxpQG9yYW5nZS5jb208bWFpbHRvOm1hcmlhbm5lLm1vaGFsaUBv cmFuZ2UuY29tPg0KU2VudDogMjggTWFyY2ggMjAxOCAxNzo0Nw0KVG86IEFzdmVyZW4sIFRvbGdh IDx0YXN2ZXJlbkByYmJuLmNvbTxtYWlsdG86dGFzdmVyZW5AcmJibi5jb20+Pjsgc2lwY29yZUBp ZXRmLm9yZzxtYWlsdG86c2lwY29yZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbc2lwY29yZV0g V0dMQzogZHJhZnQtaWV0Zi1zaXBjb3JlLW9yaWdpbmF0aW5nLWNkaXYtcGFyYW1ldGVyDQoNCkhp IFRvbGdhLCBhbGwsDQoNClJlZ2FyZGluZyB5b3VyIGxhc3QgY29tbWVudCBhbmQgYWZ0ZXIgYSBz ZWNvbmQgdGhvdWdodCwgSSBkb24ndCBrbm93IGlmIHRoZXJlIGlzIGEgbmVlZCBmb3IgdGhlICJ0 ZXJtLWNkaXYiIGNhc2UgeW91IHByb3Bvc2UgZXhjZXB0IHRvIGJlIHN5bW1ldHJpY2FsLg0KSSB3 b3VsZCBsaWtlIHRvIGhhdmUgbW9yZSBmZWVkYmFjayBiZWZvcmUgYWRkaW5nIGEgdXNlIGNhc2Us IGNoYW5naW5nIHRoZSBuYW1lIGFuZCBzY29wZSBvZiB0aGUgZHJhZnQgd2hpbGUgaXQgaXMgbm93 IHVuZGVyIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIHN0YXR1cy4NClRoZSBuYW1lIG9mIHRoZSBk cmFmdCBpcyAib3JpZ2luYXRpbmctY2RpdiIgYW5kIGl0cyBtb3RpdmF0aW9uIGZyb20gdGhlIGJl Z2lubmluZyB3YXMgdGhlICJvcmlnLWNkaXYiIHVzZSBjYXNlLg0KDQpCZXN0IHJlZ2FyZHMsDQpN YXJpYW5uZQ0KDQoNCkRlIDogc2lwY29yZSBbbWFpbHRvOnNpcGNvcmUtYm91bmNlc0BpZXRmLm9y Z10gRGUgbGEgcGFydCBkZSBtYXJpYW5uZS5tb2hhbGlAb3JhbmdlLmNvbTxtYWlsdG86bWFyaWFu bmUubW9oYWxpQG9yYW5nZS5jb20+IEVudm95w6kgOiB2ZW5kcmVkaSAxNiBtYXJzIDIwMTggMTU6 MTggw4AgOiBBc3ZlcmVuLCBUb2xnYTsgc2lwY29yZUBpZXRmLm9yZzxtYWlsdG86c2lwY29yZUBp ZXRmLm9yZz4gT2JqZXQgOiBSZTogW3NpcGNvcmVdIFdHTEM6IGRyYWZ0LWlldGYtc2lwY29yZS1v cmlnaW5hdGluZy1jZGl2LXBhcmFtZXRlcg0KDQpJdCBpcyB0cnVlIHRoYXQgd2UgY291bGQgY29u c2lkZXIgdGhpcyDigJx0ZXJtLWNkaXbigJ0gY2FzZSBpbiB0aGUgSS1EIHRvIGhhdmUgYSBzeW1t ZXRyaWMgdmFsdWUgZXZlbiBpZiBmb3Igbm93IG5vIOKAnG5lZWTigJ0gaGFzIGJlZW4gaWRlbnRp ZmllZC4NCkkgY2FuIHdvcmsgb24gdGhpcyBhZGRpbmcgdG8gdGhlIEktRC4NCg0KQW55IG90aGVy IHZpZXdzIG9uIGludHJvZHVjaW5nIHRoZSBzZXNzaW9uIGNhc2Ug4oCcdGVybS1jZGl24oCdIHRv bz8NCg0KQlIsDQpNYXJpYW5uZQ0KDQpEZSA6IEFzdmVyZW4sIFRvbGdhIFttYWlsdG86dGFzdmVy ZW5AcmJibi5jb21dIEVudm95w6kgOiB2ZW5kcmVkaSAxNiBtYXJzIDIwMTggMTM6MjUgw4AgOiBN T0hBTEkgTWFyaWFubmUgSU1UL09MTjsgc2lwY29yZUBpZXRmLm9yZzxtYWlsdG86c2lwY29yZUBp ZXRmLm9yZz4gT2JqZXQgOiBSRTogV0dMQzogZHJhZnQtaWV0Zi1zaXBjb3JlLW9yaWdpbmF0aW5n LWNkaXYtcGFyYW1ldGVyDQoNCkhpIE1hcmlhbm5lLA0KDQpUaGFuayB5b3UgZm9yIHRoZSBkZXRh aWxlZCBleHBsYW5hdGlvbiBvZiB0aGUgc2VydmljZS4gWWVzLCB0aGF0IGlzIHNvbWV0aGluZyB1 c2VkIHRvZGF5LiBCdXQgaG93IGNvdWxkIHdlIGtub3cgdGhhdCB0aGVyZSB3b3VsZG7igJl0IGJl IGFueSBzZXJ2aWNlcyB3aGljaCB3b3VsZCBiZSB0cmlnZ2VyZWQvbm90IHRyaWdnZXJlZCBvbiB0 aGUgZGl2ZXJ0aW5nIHBhcnR5IGJhc2VkIG9uIHdoZXRoZXIgaXQgaXMgdGhlIG9yaWdpbmFsIGlu aXRpYXRvciBvZiB0aGUgY2FsbCBvciBqdXN0IHRoZSBkaXZlcnRlcj8gVGhhdCBpdCBpcyBub3Qg bmVlZGVkIHRvZGF5IC1ieSBhIGNlcnRhaW4gZGVwbG95bWVudCBtb2RlbC0sIG9yIHRoYXQgeW91 KGFuZCBJKSBhcmUgbm90IGF3YXJlIG9mIGl0IGRvZXMgbm90IG5lY2Vzc2FyaWx5IG1lYW4gaXQg d291bGRu4oCZdC9pcyBhbHJlYWR5IHVzZWQgc29tZXdoZXJlIGluIHRoZSB1bml2ZXJzZSBvZiBy ZWFsIHRpbWUgc2Vzc2lvbnMuDQoNClRoZSBzaGlwIGZvciBhIG1vcmUgZ2VuZXJpYyBmcmFtZXdv cmsgdG8gZmFjaWxpdGF0ZSDigJxzY2VuYXJpbyBiYXNlZCBzZXJ2aWNlIGludm9jYXRpb24vaW50 ZXJhY3Rpb27igJ0gbWF5IGhhdmUgc2FpbGVkIGJ1dCBhdCBhIG1pbmltdW0gSSB3b3VsZCBzdWdn ZXN0IGFkZGluZyDigJx0ZXJtLWNkaXbigJ0gYXMgd2VsbC4NCg0KVGhhbmtzLA0KVG9sZ2ENCg0K RnJvbTogbWFyaWFubmUubW9oYWxpQG9yYW5nZS5jb208bWFpbHRvOm1hcmlhbm5lLm1vaGFsaUBv cmFuZ2UuY29tPiA8bWFyaWFubmUubW9oYWxpQG9yYW5nZS5jb208bWFpbHRvOm1hcmlhbm5lLm1v aGFsaUBvcmFuZ2UuY29tPj4NClNlbnQ6IEZyaWRheSwgTWFyY2ggMTYsIDIwMTggNzoyNyBBTQ0K VG86IEFzdmVyZW4sIFRvbGdhIDx0YXN2ZXJlbkByYmJuLmNvbTxtYWlsdG86dGFzdmVyZW5AcmJi bi5jb20+Pjsgc2lwY29yZUBpZXRmLm9yZzxtYWlsdG86c2lwY29yZUBpZXRmLm9yZz4NClN1Ympl Y3Q6IFJFOiBXR0xDOiBkcmFmdC1pZXRmLXNpcGNvcmUtb3JpZ2luYXRpbmctY2Rpdi1wYXJhbWV0 ZXINCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KTk9USUNFOiBU aGlzIGVtYWlsIHdhcyByZWNlaXZlZCBmcm9tIGFuIEVYVEVSTkFMIHNlbmRlciBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkhpIFRvbGdhLA0KDQpGaXJzdCwgdGhh bmsgeW91IGZvciB0aGUgcmV2aWV3IG9mIHRoZSBkcmFmdC4NClRvIGFuc3dlciB0byB0aGUgcXVl c3Rpb24gaW4geW91ciBmaXJzdCBlbWFpbCwgb25jZSBhIGRpdmVyc2lvbiBoYXMgYmVlbiBwcm9j ZXNzZWQsIHRoZSBvdXRnb2luZyBsZWcgd2lsbCBnbyB0byB0aGUgZGl2ZXJzaW9uIHRhcmdldCBi dXQgYmVmb3JlIHRoYXQsIHRoZSBzZXNzaW9uIGNhc2Ugb2YgdGhlIHNlcnZlZC11c2VyIGhhcyBi ZWVuIGNoYW5nZWQgd2l0aCB0aGUgZm9sbG93aW5nIHF1ZXN0aW9uczogd2hvIGlzIHRoZSBvcmln aW5hdGluZyBwYXJ0eT8gdGhlIGNhbGxlciBvciB0aGUgZGl2ZXJ0aW5nIHVzZXI/IERvZXMgcHJp dmFjeSBvZiB0aGUgZGl2ZXJ0aW5nIHVzZXIgYXBwbGllcz8gZG8gd2UgbmVlZCB0byBjaGVjayB0 aGUgYmFycmluZyBzZXJ2aWNlIG9mIHRoZSBkaXZlcnRpbmcgdXNlciBmb3Igb3V0Z29pbmcgY2Fs bHM/IE9UT0gsIHRoZSBjYWxsZXIgcmVtYWluIHRoZSBzYW1lIGFuZCBpdHMgb3JpZ2luYXRpbmcg c2VydmljZXMgc2hvdWxkIHN0aWxsIGFwcGx5LiBGb3IgdGhhdCBwYXJ0aWN1bGFyIHNpdHVhdGlv biBzb21ld2hlcmUgYmV0d2VlbiB0ZXJtaW5hdGluZyBhbmQgb3JpZ2luYXRpbmcsIHRoZSBkcmFm dCBwcm9wb3NlcyB0byBleHRlbmQgdGhlIFAtU2VydmVkLXVzZXIuDQpBdCB0aGUgZGl2ZXJ0ZWQt dG8gdXNlciBsZXZlbCwgaXQgaXMgZGlmZmVyZW50OiBJdCBtYXkgaW5kZWVkIGJlIHBvc3NpYmxl IHRvIHRyaWdnZXIgYSBzcGVjaWZpYyBzZXJ2aWNlIGZvciB0aGUgdGVybWluYXRpbmctYWZ0ZXIt ZGl2ZXJzaW9uIGJ1dCB0aGlzIGlzIG5vdCBhIG5ldyB0eXBlIHNlc3Npb24gY2FzZS4gQXQgdGhl IHRlcm1pbmF0aW5nIHNpZGUsIHRoZSBzZXJ2ZWQgdXNlciByZW1haW5zIHRoZSB0ZXJtaW5hdGlu ZyB1c2VyIGFuZCBvbmx5IGl0cyB0ZXJtaW5hdGluZyBzZXJ2aWNlcyBoYXZlIHRvIGJlIHRyaWdn ZXJlZC4gT2YgY291cnNlLCB0ZXJtaW5hdGluZyBzZXJ2aWNlcyBiYXNlZCBvbiB0aGUgb3JpZ2lu YXRpbmcgcGFydHkgaWRlbnRpdHkgYXJlIGFmZmVjdGVkIGJ5IHRoZSBjYWxsIGRpdmVyc2lvbiBz aW5jZSB3ZSBjYW4gZGlzY3VzcyBvbiB3aG8gaXMgdGhlIG9yaWdpbmF0aW5nIHBhcnR5IGJ1dCB0 aGlzIGlzIG1vcmUgYSBtYXR0ZXIgb2Ygc2VydmljZSBpbnRlcmFjdGlvbi4gVGhlIHNlcnZlZC11 c2VyIGlzIHRoZSBkaXZlcnNpb24gdGFyZ2V0IGFuZCB0aGUgc2Vzc2lvbiBjYXNlIGlzIHRlcm1p bmF0aW5nIGFuZCBpdCB3aWxsIG5vdCBjaGFuZ2UgKGV4Y2VwdCBpZiB0aGVyZSBpcyBhbm90aGVy IGNhbGwgZGl2ZXJzaW9uIDspLiBKdXN0IHRvIGxldCB5b3Uga25vdywgdGhlcmUgaXMgYSBzZXJ2 aWNlIHRvIHJlamVjdCBpbmNvbWluZyBmb3J3YXJkZWQgY2FsbHMgYW5kIHRoZSB0cmlnZ2VyIGZv ciB0aGlzIHNwZWNpZmljIGtpbmQgb2YgYmFycmluZyBpcyB0aGUgcHJlc2VuY2Ugb2YgYSBkaXZl cnRpbmcgdXNlciBpZGVudGl0eSBpbiB0aGUgaW5jb21pbmcgSU5WSVRFIHJlcXVlc3QuIEl0IGlz IGp1c3QgYSBjcml0ZXJpb24gKGFzIGZvciBhbGwgYmFycmluZyBzZXJ2aWNlcykuDQoNCkFib3V0 IHlvdXIgY29tbWVudCBvbiB0aGUgd2F5IFNJUCBoZWFkZXJzIGFyZSBleHRlbmRlZCwgSU1PLCBy dWxlcyBmb3Igc3RhbmRhcmRpemF0aW9uIHByb2Nlc3Mgb2YgU0lQIGFyZSBoZXJlIGZvciB5ZWFy cyBhbmQgaXQgaXMgbm90IHRoZSBnb29kIHRpbWUgdG8gY2hhbmdlIHRoYXQuIFRvIGJlIHRyYW5z cGFyZW50LCB0aGlzIGV4dGVuc2lvbiB3YXMgZmlyc3QgZGVmaW5lZCBvbmx5IHdpdGhpbiAzR1BQ IHNwZWNpZmljYXRpb24gYmVjYXVzZSB0aGVyZSB3YXMgYSBzZXJ2aWNlIG5lZWQgYmVoaW5kLiBC ZWNhdXNlIGl0IHdhcyBhbiBleHRlbnNpb24gb2YgYW4gUkZDIGFuZCB0aGUgd2FzIHRoZSBzeW50 YXggb2YgdGhlIGhlYWRlciBpcyBkZXNpZ25lZCwgdGhlIGV4dGVuc2lvbiBpcyB0byBiZSBkb25l IGluIElFVEYuIFdlIGNhbiBkaXNjdXNzIHRoYXQgYnV0IHdlIGFyZSBhdCB0aGUgZW5kIG9mIFNJ UCBwcm90b2NvbCBleHRlbnNpb24gcHJvY2Vzcy4uLg0KRmluYWxseSwgUkZDNTUwMiBkZWZpbmVz IGEg4oCccHJpdmF0ZeKAnSAoUC0gKSBoZWFkZXIgc28gaXQgaXMgbm90IHN1cnByaXNpbmcgdGhh dCBpdHMgZXh0ZW5zaW9uIGFzIGEgM0dQUCBmbGF2b3Ig4pi6DQoNCkJlc3QgcmVnYXJkcywNCk1h cmlhbm5lDQoNCg0KRGUgOiBzaXBjb3JlIFttYWlsdG86c2lwY29yZS1ib3VuY2VzQGlldGYub3Jn XSBEZSBsYSBwYXJ0IGRlIEFzdmVyZW4sIFRvbGdhIEVudm95w6kgOiB2ZW5kcmVkaSAxNiBtYXJz IDIwMTggMDk6MDYgw4AgOiBzaXBjb3JlQGlldGYub3JnPG1haWx0bzpzaXBjb3JlQGlldGYub3Jn PiBPYmpldCA6IFJlOiBbc2lwY29yZV0gV0dMQzogZHJhZnQtaWV0Zi1zaXBjb3JlLW9yaWdpbmF0 aW5nLWNkaXYtcGFyYW1ldGVyDQoNClNvbWUgbW9yZSBtdXNpbmdzIGZyb20gY29uY2VwdHVhbCBw ZXJzcGVjdGl2ZToNCg0KU0lQIHByb3ZpZGVzIGEgdG9vbGJveCB0byBwcm92aWRlIHNlcnZpY2Vz LiBBbmQgeWVzLCB0aGVyZSBpcyBzb21lIHNwZWNpYWwgKGlmIEkgbWF5IHNheSDigJxmYXZvcmVk 4oCdKSBzdGF0dXMgb2YgM0dQUCB3aGVuIGl0IGNvbWVzIHRvIFNJUCBzdGFuZGFyZGl6YXRpb24u IE9UT0gsIGRvZXMgdGhlIGFwcHJvYWNoIHRha2VuIGJ5IFJGQzU1MDIgZ28gYSBsaXR0bGUgYml0 IHRvbyBmYXIgaW4gdGVybXMgb2Ygb3Zlci1kZWZpbmluZyB0aGUgZ2VuZXJpYyBTSVAgdG9vbGJv eD8NCg0KQW4gYWx0ZXJuYXRpdmUgY291bGQgYmUgdG8gZGVmaW5lIGEgaGVhZGVyL3BhcmFtZXRl ciB3aGljaCByZWZlcnMgdG8gYSDigJxzY2VuYXJpb+KAnSBpbiBhbiBhYnN0cmFjdCB3YXkgKHdp dGggYSBnZW5lcmljIHN5bnRheCkgYW5kIGxldCBvdGhlciBzdGFuZGFyZHMgZm9yYSBkZWZpbmUg dGhlIHZhbHVlcyB0aGV5IHdvdWxkIGxpa2UgdG8gdXNlIGFuZC9vciByZWx5IG9uIGNvbmZpZ3Vy YXRpb24gYWxpZ25tZW50IGJldHdlZW4gcmVsZXZhbnQgZWxlbWVudHMsIGUuZy4gUy1DU0NGL0hT Uy9BUy4gQ29uc2lkZXJpbmcgd2hlcmUgd2UgYXJlIHJpZ2h0IG5vdyAodGhhdCBSRkM1NTAyIGlz IGFscmVhZHkgdGhlcmUpIHRoaXMgYXBwcm9hY2ggcHJhY3RpY2FsbHkgd291bGQgbWVhbiB0aGF0 IGRyYWZ0LWlldGYtc2lwY29yZS1vcmlnaW5hdGluZy1jZGl2LXBhcmFtZXRlciBpcyBub3QgZGVm aW5lZCBhbmQgUC1TZXJ2ZWQtVXNlciBzZXJ2ZWQtdXNlci1wYXJtIGlzIGV4dGVuZGVkIGJ5IG90 aGVycyBhcyBuZWVkZWQgKGFzIGl0IGFsbG93cyB0aGF0KS4NCg0KT3RoZXJ3aXNlLCB0aGVyZSB3 b3VsZC9jb3VsZCBiZSB0aGUgbmVlZCB0byBrZWVwIGFkZGluZyBuZXcgdmFsdWVzIGluIGRpZmZl cmVudCBJRVRGIHNwZWNpZmljYXRpb25zIHRoZSBtb3JlIOKAnGRlcGxveW1lbnQgbW9kZWwgc3Bl Y2lmaWMgdXNlIGNhc2Vz4oCdIGFyZSBuZWVkZWQvZGlzY292ZXJlZC9pbnZlbnRlZC4NCg0KVGhh bmtzLA0KVG9sZ2ENCkZyb206IEFzdmVyZW4sIFRvbGdhDQpTZW50OiBUaHVyc2RheSwgTWFyY2gg MTUsIDIwMTggNDoyMyBQTQ0KVG86IHNpcGNvcmVAaWV0Zi5vcmc8bWFpbHRvOnNpcGNvcmVAaWV0 Zi5vcmc+DQpTdWJqZWN0OiBXR0xDOiBkcmFmdC1pZXRmLXNpcGNvcmUtb3JpZ2luYXRpbmctY2Rp di1wYXJhbWV0ZXINCg0KSSByZXZpZXdlZCB0aGUgZHJhZnQgYW5kIGhhdmUgbm8gdGVjaG5pY2Fs IGlzc3VlcyB3aXRoIGl0IGV4Y2VwdCBvbmUgcXVlc3Rpb246DQoNCklzIGl0IGVudmlzaW9uZWQg dGhhdCB0aGVyZSB3b3VsZC9jb3VsZCBiZSBhIG5lZWQgZm9yIHRlcm0tY2RpdiBhcyB3ZWxsIHRv IHRyaWdnZXIgYSBkaWZmZXJlbnQgc2VydmljZSBzZXQgaWYgdGhlIHRhcmdldCBpcyBkZXRlcm1p bmVkIGFmdGVyIGRpdmVyc2lvbj8gSXQgbWF5IGJlIGJldHRlciB0byBkZWZpbmUgaXQgbm93IHJh dGhlciB0aGFuIGhhdmluZyB5ZXQgYW5vdGhlciBkcmFmdCwgYXQgbGVhc3QgdG8gYmUgZnV0dXJl IHByb29mLg0KDQpUaGFua3MsDQpUb2xnYQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkNlIG1lc3NhZ2UgZXQgc2Vz IHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRl bnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYyBwYXMgZXRyZSBkaWZm dXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6 IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlciBhIGwnZXhw ZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMg bWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLCBP cmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFs dGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQoNClRoaXMgbWVzc2FnZSBhbmQgaXRz IGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9y bWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7IHRoZXkgc2hvdWxkIG5vdCBiZSBk aXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KSWYgeW91 IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2Vu ZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQpBcyBlbWFp bHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0 IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQpUaGFuayB5b3UuDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQoNCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVu aXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5l IGRvaXZlbnQgZG9uYyBwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5z IGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2 ZXVpbGxleiBsZSBzaWduYWxlciBhIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBx dWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBz dXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLCBPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJp bGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVy Y2kuDQoNClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZp ZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBi eSBsYXc7IHRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0 aG91dCBhdXRob3Jpc2F0aW9uLg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBl cnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFu ZCBpdHMgYXR0YWNobWVudHMuDQpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBu b3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBv ciBmYWxzaWZpZWQuDQpUaGFuayB5b3UuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KQ2UgbWVzc2FnZSBldCBzZXMg cGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVu dGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jIHBhcyBldHJlIGRpZmZ1 c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXog cmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyIGEgbCdleHBl ZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBt ZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sIE9y YW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0 ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCg0KVGhpcyBtZXNzYWdlIGFuZCBpdHMg YXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3Jt YXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsgdGhleSBzaG91bGQgbm90IGJlIGRp c3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQpJZiB5b3Ug aGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5k ZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCkFzIGVtYWls cyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQg aGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NClRoYW5rIHlvdS4NCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNpcGNvcmUg bWFpbGluZyBsaXN0DQpzaXBjb3JlQGlldGYub3JnPG1haWx0bzpzaXBjb3JlQGlldGYub3JnPg0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlDQo= --_000_CY4PR03MB3160DC8161CD67336793040EA5A20CY4PR03MB3160namp_ Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlNlZ29lIFVJ IEVtb2ppIjsNCglwYW5vc2UtMToyIDExIDUgMiA0IDIgNCAyIDIgMzt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBl cmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1h bDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRv Ow0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFy Z2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2lu ZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDEx LjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9u MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwv eG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQg djpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hh cGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIg bGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+QWx0aG91Z2ggSSBhbHNvIGFncmVlIHRoYXQgaXQgaXMgcHJl ZmVyYWJsZSB0byBrZWVwIGNoYW5jZXMgbGltaXRlZCBkdXJpbmcgV0dMQywgdGhpcyBpbiBwcmlu Y2lwbGUgc2hvdWxkbuKAmXQgbWVhbiB0aGF0IHdlIG91Z2h0IHRvIGF2b2lkIHdoYXQgbWFrZXMg c2Vuc2UgZm9yIHRoZSBzYWtlIG9mIOKAnHB1c2hpbmcgaXQgZm9yd2FyZCB3aXRob3V0IGhhc3Ns ZeKAnS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXMgSSBhbHJlYWR5IGluZGljYXRlZCBiZWZv cmUsIEkgdGhpbmsgdGhlIGlkZWEgb2YgZW51bWVyYXRpbmcgZGlmZmVyZW50IHNjZW5hcmlvIGNv bWJpbmF0aW9ucyBpbiBJRVRGLCB3aGljaCBkbyBub3QgcGVydGFpbiB0byBhY3R1YWwgU0lQIHNl bWFudGljcyBhdCBhbGwsIGlzIG5vdCBhbiBlbGVnYW50IGlkZWEgSU1ITy4gTm90IGRlZmluaW5n IGFueSB2YWx1ZXMgYW5kIGV4cGVjdGluZyB1c2Ugb2YgKGlmIG5lZWRlZA0KIG11bHRpcGxlKSBn ZW5lcmljLXBhcmFtcyBmb3IgUC1TZXJ2ZWQtVXNlciBjb3VsZCBoYXZlIGJlZW4gYSBjbGVhbmVy IGFwcHJvYWNoLiBBY3R1YWwgdmFsdWVzIHdvdWxkIGJlIGRlZmluZWQgYnkgb3RoZXIgc3RhbmRh cmQgZm9yYS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Rm9yIGEgdXNlIGNhc2UgZm9yIHRlcm0t Y2Rpdjog4oCcRG8gbm90IGRpdmVydCBpZiBhbHJlYWR5IGRpdmVydGVk4oCdLCDigJxpbmRpY2F0 ZSBpbiBjYWxsIHJlY29yZHMgdGhhdCBjYWxsIGlzIGRpdmVydGVk4oCdIChmb3IgZXhhbXBsZSB0 byBhcHBseSBhIGRpZmZlcmVudCBjaGFyZ2luZyBzY2hlbWUpIGNvdWxkIGJlIGFwcGxpY2FibGUu PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFzIGEgZmluYWwgd29yZDogSSBhbSBub3QgcmVsaWdp b3VzIGFib3V0IHRoaXMsIGl0IGFueWhvdyB3b3VsZG7igJl0IGZpeCBhIGJyb2tlbiBtb2RlbCAo aG9uZXN0bHkgSSByYXRoZXIgd291bGQgcHJlZmVyIHRoYXQgdGhpcyBkcmFmdCBpcyB3aXRoZHJh d24gYW5kIGEgbmV3IGRyYWZ0IGlzIHN1Ym1pdHRlZCBleHBsYWluaW5nIHRoYXQgdXNlIGNhc2Vz IHJlcXVpcmluZyBuZXcgUC1TZXJ2ZWQtVXNlciBwYXJhbWV0ZXINCiB2YWx1ZXMgc2hvdWxkIHVz ZSB0aGUgZ2VuZXJpYy1wYXJhbSBleHRlbnNpb24pLiBOb25ldGhlbGVzcywgaXQmbmJzcDsgc3Rp bGwgc291bmRzIG1vcmUgcmVhc29uYWJsZSB0byBtZSB0byBhZGQgaXQgdGhhbiBub3QuDQo8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+U28sIEkgd2lsbCBsZWF2ZSBpdCBoZXJlIGFuZCBob3BlIHRo ZSBhdXRob3JzIHdvdWxkIHRoaW5rIGNhcmVmdWxseS9pbiBhIG5vbi1iaWFzZWQgd2F5IGFuZCBk ZWNpZGUgZm9yIHRoZSBiZXN0IGNvdXJzZS4gJm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRvbGdhPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IENocmlzdGVyIEhvbG1iZXJnICZsdDtj aHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20mZ3Q7DQo8YnI+DQo8Yj5TZW50OjwvYj4gV2Vk bmVzZGF5LCBNYXJjaCAyOCwgMjAxOCAxOjQzIFBNPGJyPg0KPGI+VG86PC9iPiBtYXJpYW5uZS5t b2hhbGlAb3JhbmdlLmNvbTsgQXN2ZXJlbiwgVG9sZ2EgJmx0O3Rhc3ZlcmVuQHJiYm4uY29tJmd0 Ozsgc2lwY29yZUBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogV0dMQzogZHJhZnQt aWV0Zi1zaXBjb3JlLW9yaWdpbmF0aW5nLWNkaXYtcGFyYW1ldGVyPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWdu OmNlbnRlciI+DQo8aHIgc2l6ZT0iMiIgd2lkdGg9IjEwMCUiIGFsaWduPSJjZW50ZXIiPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5OT1RJQ0U6IFRoaXMgZW1haWwgd2FzIHJlY2VpdmVk IGZyb20gYW4gRVhURVJOQUwgc2VuZGVyPG86cD48L286cD48L3A+DQo8ZGl2IGNsYXNzPSJNc29O b3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlciI+DQo8aHIgc2l6 ZT0iMiIgd2lkdGg9IjEwMCUiIGFsaWduPSJjZW50ZXIiPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48YnI+DQpIaSw8YnI+DQo8YnI+DQpNeSBnZW5lcmFsIG9waW5pb24sIG5vdCBzcGVj aWZpYyB0byB0aGlzIGRyYWZ0LCBpcyB0aGF0IHdlIHNob3VsZCBhdm9pZCBhZGRpbmcgbmV3IGZ1 bmN0aW9uYWxpdHkgYXQgV0dMQyAtIHVubGVzcyBpdCBpcyBuZWVkZWQgZm9yIHRoZSBleGlzdGlu ZyBmdW5jdGlvbmFsaXR5Ljxicj4NCjxicj4NCkluIHRoaXMgY2FzZSwgb25jZSBvcmlkLWRpdiBo YXMgYmVlbiBwdWJsaXNoZWQsIEkgYXNzdW1lIGl0IHdvdWxkIG5vdCBiZSB2ZXJ5IGRpZmZpY3Vs dCB0byBwcm9kdWNlIGEgc2VwYXJhdGUgdGVybS1kaXYgZHJhZnQsIGlmIHRoZXJlIGlzIGludGVy ZXN0Ljxicj4NCjxicj4NClJlZ2FyZHMsPGJyPg0KPGJyPg0KQ2hyaXN0ZXI8YnI+DQo8YnI+DQo8 YnI+DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IHNpcGNvcmUgWzxhIGhy ZWY9Im1haWx0bzpzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpzaXBjb3JlLWJvdW5j ZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YNCjxhIGhyZWY9Im1haWx0bzptYXJpYW5uZS5t b2hhbGlAb3JhbmdlLmNvbSI+bWFyaWFubmUubW9oYWxpQG9yYW5nZS5jb208L2E+PGJyPg0KU2Vu dDogMjggTWFyY2ggMjAxOCAxNzo0Nzxicj4NClRvOiBBc3ZlcmVuLCBUb2xnYSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnRhc3ZlcmVuQHJiYm4uY29tIj50YXN2ZXJlbkByYmJuLmNvbTwvYT4mZ3Q7OyA8 YSBocmVmPSJtYWlsdG86c2lwY29yZUBpZXRmLm9yZyI+DQpzaXBjb3JlQGlldGYub3JnPC9hPjxi cj4NClN1YmplY3Q6IFJlOiBbc2lwY29yZV0gV0dMQzogZHJhZnQtaWV0Zi1zaXBjb3JlLW9yaWdp bmF0aW5nLWNkaXYtcGFyYW1ldGVyPGJyPg0KPGJyPg0KSGkgVG9sZ2EsIGFsbCw8YnI+DQo8YnI+ DQpSZWdhcmRpbmcgeW91ciBsYXN0IGNvbW1lbnQgYW5kIGFmdGVyIGEgc2Vjb25kIHRob3VnaHQs IEkgZG9uJ3Qga25vdyBpZiB0aGVyZSBpcyBhIG5lZWQgZm9yIHRoZSAmcXVvdDt0ZXJtLWNkaXYm cXVvdDsgY2FzZSB5b3UgcHJvcG9zZSBleGNlcHQgdG8gYmUgc3ltbWV0cmljYWwuDQo8YnI+DQpJ IHdvdWxkIGxpa2UgdG8gaGF2ZSBtb3JlIGZlZWRiYWNrIGJlZm9yZSBhZGRpbmcgYSB1c2UgY2Fz ZSwgY2hhbmdpbmcgdGhlIG5hbWUgYW5kIHNjb3BlIG9mIHRoZSBkcmFmdCB3aGlsZSBpdCBpcyBu b3cgdW5kZXIgd29ya2luZyBncm91cCBsYXN0IGNhbGwgc3RhdHVzLg0KPGJyPg0KVGhlIG5hbWUg b2YgdGhlIGRyYWZ0IGlzICZxdW90O29yaWdpbmF0aW5nLWNkaXYmcXVvdDsgYW5kIGl0cyBtb3Rp dmF0aW9uIGZyb20gdGhlIGJlZ2lubmluZyB3YXMgdGhlICZxdW90O29yaWctY2RpdiZxdW90OyB1 c2UgY2FzZS48YnI+DQo8YnI+DQpCZXN0IHJlZ2FyZHMsPGJyPg0KTWFyaWFubmU8YnI+DQo8YnI+ DQo8YnI+DQpEZSZuYnNwOzogc2lwY29yZSBbPGEgaHJlZj0ibWFpbHRvOnNpcGNvcmUtYm91bmNl c0BpZXRmLm9yZyI+bWFpbHRvOnNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZzwvYT5dIERlIGxhIHBh cnQgZGUNCjxhIGhyZWY9Im1haWx0bzptYXJpYW5uZS5tb2hhbGlAb3JhbmdlLmNvbSI+bWFyaWFu bmUubW9oYWxpQG9yYW5nZS5jb208L2E+IEVudm95w6kmbmJzcDs6IHZlbmRyZWRpIDE2IG1hcnMg MjAxOCAxNToxOCDDgCZuYnNwOzogQXN2ZXJlbiwgVG9sZ2E7DQo8YSBocmVmPSJtYWlsdG86c2lw Y29yZUBpZXRmLm9yZyI+c2lwY29yZUBpZXRmLm9yZzwvYT4gT2JqZXQmbmJzcDs6IFJlOiBbc2lw Y29yZV0gV0dMQzogZHJhZnQtaWV0Zi1zaXBjb3JlLW9yaWdpbmF0aW5nLWNkaXYtcGFyYW1ldGVy PGJyPg0KPGJyPg0KSXQgaXMgdHJ1ZSB0aGF0IHdlIGNvdWxkIGNvbnNpZGVyIHRoaXMg4oCcdGVy bS1jZGl24oCdIGNhc2UgaW4gdGhlIEktRCB0byBoYXZlIGEgc3ltbWV0cmljIHZhbHVlIGV2ZW4g aWYgZm9yIG5vdyBubyDigJxuZWVk4oCdIGhhcyBiZWVuIGlkZW50aWZpZWQuDQo8YnI+DQpJIGNh biB3b3JrIG9uIHRoaXMgYWRkaW5nIHRvIHRoZSBJLUQuPGJyPg0KPGJyPg0KQW55IG90aGVyIHZp ZXdzIG9uIGludHJvZHVjaW5nIHRoZSBzZXNzaW9uIGNhc2Ug4oCcdGVybS1jZGl24oCdIHRvbz88 YnI+DQo8YnI+DQpCUiw8YnI+DQpNYXJpYW5uZTxicj4NCjxicj4NCkRlJm5ic3A7OiBBc3ZlcmVu LCBUb2xnYSBbPGEgaHJlZj0ibWFpbHRvOnRhc3ZlcmVuQHJiYm4uY29tIj5tYWlsdG86dGFzdmVy ZW5AcmJibi5jb208L2E+XSBFbnZvecOpJm5ic3A7OiB2ZW5kcmVkaSAxNiBtYXJzIDIwMTggMTM6 MjUgw4AmbmJzcDs6IE1PSEFMSSBNYXJpYW5uZSBJTVQvT0xOOw0KPGEgaHJlZj0ibWFpbHRvOnNp cGNvcmVAaWV0Zi5vcmciPnNpcGNvcmVAaWV0Zi5vcmc8L2E+IE9iamV0Jm5ic3A7OiBSRTogV0dM QzogZHJhZnQtaWV0Zi1zaXBjb3JlLW9yaWdpbmF0aW5nLWNkaXYtcGFyYW1ldGVyPGJyPg0KPGJy Pg0KSGkgTWFyaWFubmUsPGJyPg0KPGJyPg0KVGhhbmsgeW91IGZvciB0aGUgZGV0YWlsZWQgZXhw bGFuYXRpb24gb2YgdGhlIHNlcnZpY2UuIFllcywgdGhhdCBpcyBzb21ldGhpbmcgdXNlZCB0b2Rh eS4gQnV0IGhvdyBjb3VsZCB3ZSBrbm93IHRoYXQgdGhlcmUgd291bGRu4oCZdCBiZSBhbnkgc2Vy dmljZXMgd2hpY2ggd291bGQgYmUgdHJpZ2dlcmVkL25vdCB0cmlnZ2VyZWQgb24gdGhlIGRpdmVy dGluZyBwYXJ0eSBiYXNlZCBvbiB3aGV0aGVyIGl0IGlzIHRoZSBvcmlnaW5hbCBpbml0aWF0b3Ig b2YNCiB0aGUgY2FsbCBvciBqdXN0IHRoZSBkaXZlcnRlcj8gVGhhdCBpdCBpcyBub3QgbmVlZGVk IHRvZGF5IC1ieSBhIGNlcnRhaW4gZGVwbG95bWVudCBtb2RlbC0sIG9yIHRoYXQgeW91KGFuZCBJ KSBhcmUgbm90IGF3YXJlIG9mIGl0IGRvZXMgbm90IG5lY2Vzc2FyaWx5IG1lYW4gaXQgd291bGRu 4oCZdC9pcyBhbHJlYWR5IHVzZWQgc29tZXdoZXJlIGluIHRoZSB1bml2ZXJzZSBvZiByZWFsIHRp bWUgc2Vzc2lvbnMuDQo8YnI+DQo8YnI+DQpUaGUgc2hpcCBmb3IgYSBtb3JlIGdlbmVyaWMgZnJh bWV3b3JrIHRvIGZhY2lsaXRhdGUg4oCcc2NlbmFyaW8gYmFzZWQgc2VydmljZSBpbnZvY2F0aW9u L2ludGVyYWN0aW9u4oCdIG1heSBoYXZlIHNhaWxlZCBidXQgYXQgYSBtaW5pbXVtIEkgd291bGQg c3VnZ2VzdCBhZGRpbmcg4oCcdGVybS1jZGl24oCdIGFzIHdlbGwuPGJyPg0KPGJyPg0KVGhhbmtz LDxicj4NClRvbGdhPGJyPg0KPGJyPg0KRnJvbTogPGEgaHJlZj0ibWFpbHRvOm1hcmlhbm5lLm1v aGFsaUBvcmFuZ2UuY29tIj5tYXJpYW5uZS5tb2hhbGlAb3JhbmdlLmNvbTwvYT4gJmx0OzxhIGhy ZWY9Im1haWx0bzptYXJpYW5uZS5tb2hhbGlAb3JhbmdlLmNvbSI+bWFyaWFubmUubW9oYWxpQG9y YW5nZS5jb208L2E+Jmd0Ozxicj4NClNlbnQ6IEZyaWRheSwgTWFyY2ggMTYsIDIwMTggNzoyNyBB TTxicj4NClRvOiBBc3ZlcmVuLCBUb2xnYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRhc3ZlcmVuQHJi Ym4uY29tIj50YXN2ZXJlbkByYmJuLmNvbTwvYT4mZ3Q7OyA8YSBocmVmPSJtYWlsdG86c2lwY29y ZUBpZXRmLm9yZyI+DQpzaXBjb3JlQGlldGYub3JnPC9hPjxicj4NClN1YmplY3Q6IFJFOiBXR0xD OiBkcmFmdC1pZXRmLXNpcGNvcmUtb3JpZ2luYXRpbmctY2Rpdi1wYXJhbWV0ZXI8YnI+DQo8YnI+ DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KTk9USUNFOiBU aGlzIGVtYWlsIHdhcyByZWNlaXZlZCBmcm9tIGFuIEVYVEVSTkFMIHNlbmRlciBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KPGJyPg0KSGkgVG9sZ2EsPGJyPg0K PGJyPg0KRmlyc3QsIHRoYW5rIHlvdSBmb3IgdGhlIHJldmlldyBvZiB0aGUgZHJhZnQuPGJyPg0K VG8gYW5zd2VyIHRvIHRoZSBxdWVzdGlvbiBpbiB5b3VyIGZpcnN0IGVtYWlsLCBvbmNlIGEgZGl2 ZXJzaW9uIGhhcyBiZWVuIHByb2Nlc3NlZCwgdGhlIG91dGdvaW5nIGxlZyB3aWxsIGdvIHRvIHRo ZSBkaXZlcnNpb24gdGFyZ2V0IGJ1dCBiZWZvcmUgdGhhdCwgdGhlIHNlc3Npb24gY2FzZSBvZiB0 aGUgc2VydmVkLXVzZXIgaGFzIGJlZW4gY2hhbmdlZCB3aXRoIHRoZSBmb2xsb3dpbmcgcXVlc3Rp b25zOiB3aG8gaXMgdGhlIG9yaWdpbmF0aW5nIHBhcnR5Pw0KIHRoZSBjYWxsZXIgb3IgdGhlIGRp dmVydGluZyB1c2VyPyBEb2VzIHByaXZhY3kgb2YgdGhlIGRpdmVydGluZyB1c2VyIGFwcGxpZXM/ IGRvIHdlIG5lZWQgdG8gY2hlY2sgdGhlIGJhcnJpbmcgc2VydmljZSBvZiB0aGUgZGl2ZXJ0aW5n IHVzZXIgZm9yIG91dGdvaW5nIGNhbGxzPyBPVE9ILCB0aGUgY2FsbGVyIHJlbWFpbiB0aGUgc2Ft ZSBhbmQgaXRzIG9yaWdpbmF0aW5nIHNlcnZpY2VzIHNob3VsZCBzdGlsbCBhcHBseS4gRm9yIHRo YXQgcGFydGljdWxhcg0KIHNpdHVhdGlvbiBzb21ld2hlcmUgYmV0d2VlbiB0ZXJtaW5hdGluZyBh bmQgb3JpZ2luYXRpbmcsIHRoZSBkcmFmdCBwcm9wb3NlcyB0byBleHRlbmQgdGhlIFAtU2VydmVk LXVzZXIuDQo8YnI+DQpBdCB0aGUgZGl2ZXJ0ZWQtdG8gdXNlciBsZXZlbCwgaXQgaXMgZGlmZmVy ZW50OiBJdCBtYXkgaW5kZWVkIGJlIHBvc3NpYmxlIHRvIHRyaWdnZXIgYSBzcGVjaWZpYyBzZXJ2 aWNlIGZvciB0aGUgdGVybWluYXRpbmctYWZ0ZXItZGl2ZXJzaW9uIGJ1dCB0aGlzIGlzIG5vdCBh IG5ldyB0eXBlIHNlc3Npb24gY2FzZS4gQXQgdGhlIHRlcm1pbmF0aW5nIHNpZGUsIHRoZSBzZXJ2 ZWQgdXNlciByZW1haW5zIHRoZSB0ZXJtaW5hdGluZyB1c2VyIGFuZCBvbmx5DQogaXRzIHRlcm1p bmF0aW5nIHNlcnZpY2VzIGhhdmUgdG8gYmUgdHJpZ2dlcmVkLiBPZiBjb3Vyc2UsIHRlcm1pbmF0 aW5nIHNlcnZpY2VzIGJhc2VkIG9uIHRoZSBvcmlnaW5hdGluZyBwYXJ0eSBpZGVudGl0eSBhcmUg YWZmZWN0ZWQgYnkgdGhlIGNhbGwgZGl2ZXJzaW9uIHNpbmNlIHdlIGNhbiBkaXNjdXNzIG9uIHdo byBpcyB0aGUgb3JpZ2luYXRpbmcgcGFydHkgYnV0IHRoaXMgaXMgbW9yZSBhIG1hdHRlciBvZiBz ZXJ2aWNlIGludGVyYWN0aW9uLg0KIFRoZSBzZXJ2ZWQtdXNlciBpcyB0aGUgZGl2ZXJzaW9uIHRh cmdldCBhbmQgdGhlIHNlc3Npb24gY2FzZSBpcyB0ZXJtaW5hdGluZyBhbmQgaXQgd2lsbCBub3Qg Y2hhbmdlIChleGNlcHQgaWYgdGhlcmUgaXMgYW5vdGhlciBjYWxsIGRpdmVyc2lvbiA7KS4gSnVz dCB0byBsZXQgeW91IGtub3csIHRoZXJlIGlzIGEgc2VydmljZSB0byByZWplY3QgaW5jb21pbmcg Zm9yd2FyZGVkIGNhbGxzIGFuZCB0aGUgdHJpZ2dlciBmb3IgdGhpcyBzcGVjaWZpYw0KIGtpbmQg b2YgYmFycmluZyBpcyB0aGUgcHJlc2VuY2Ugb2YgYSBkaXZlcnRpbmcgdXNlciBpZGVudGl0eSBp biB0aGUgaW5jb21pbmcgSU5WSVRFIHJlcXVlc3QuIEl0IGlzIGp1c3QgYSBjcml0ZXJpb24gKGFz IGZvciBhbGwgYmFycmluZyBzZXJ2aWNlcykuDQo8YnI+DQo8YnI+DQpBYm91dCB5b3VyIGNvbW1l bnQgb24gdGhlIHdheSBTSVAgaGVhZGVycyBhcmUgZXh0ZW5kZWQsIElNTywgcnVsZXMgZm9yIHN0 YW5kYXJkaXphdGlvbiBwcm9jZXNzIG9mIFNJUCBhcmUgaGVyZSBmb3IgeWVhcnMgYW5kIGl0IGlz IG5vdCB0aGUgZ29vZCB0aW1lIHRvIGNoYW5nZSB0aGF0LiBUbyBiZSB0cmFuc3BhcmVudCwgdGhp cyBleHRlbnNpb24gd2FzIGZpcnN0IGRlZmluZWQgb25seSB3aXRoaW4gM0dQUCBzcGVjaWZpY2F0 aW9uIGJlY2F1c2UgdGhlcmUNCiB3YXMgYSBzZXJ2aWNlIG5lZWQgYmVoaW5kLiBCZWNhdXNlIGl0 IHdhcyBhbiBleHRlbnNpb24gb2YgYW4gUkZDIGFuZCB0aGUgd2FzIHRoZSBzeW50YXggb2YgdGhl IGhlYWRlciBpcyBkZXNpZ25lZCwgdGhlIGV4dGVuc2lvbiBpcyB0byBiZSBkb25lIGluIElFVEYu IFdlIGNhbiBkaXNjdXNzIHRoYXQgYnV0IHdlIGFyZSBhdCB0aGUgZW5kIG9mIFNJUCBwcm90b2Nv bCBleHRlbnNpb24gcHJvY2Vzcy4uLjxicj4NCkZpbmFsbHksIFJGQzU1MDIgZGVmaW5lcyBhIOKA nHByaXZhdGXigJ0gKFAtICkgaGVhZGVyIHNvIGl0IGlzIG5vdCBzdXJwcmlzaW5nIHRoYXQgaXRz IGV4dGVuc2lvbiBhcyBhIDNHUFAgZmxhdm9yDQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7U2Vnb2UgVUkgRW1vamkmcXVvdDssc2Fucy1zZXJpZiI+4pi6PC9zcGFuPjxicj4NCjxicj4N CkJlc3QgcmVnYXJkcyw8YnI+DQpNYXJpYW5uZTxicj4NCjxicj4NCjxicj4NCkRlJm5ic3A7OiBz aXBjb3JlIFs8YSBocmVmPSJtYWlsdG86c2lwY29yZS1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86 c2lwY29yZS1ib3VuY2VzQGlldGYub3JnPC9hPl0gRGUgbGEgcGFydCBkZSBBc3ZlcmVuLCBUb2xn YSBFbnZvecOpJm5ic3A7OiB2ZW5kcmVkaSAxNiBtYXJzIDIwMTggMDk6MDYgw4AmbmJzcDs6DQo8 YSBocmVmPSJtYWlsdG86c2lwY29yZUBpZXRmLm9yZyI+c2lwY29yZUBpZXRmLm9yZzwvYT4gT2Jq ZXQmbmJzcDs6IFJlOiBbc2lwY29yZV0gV0dMQzogZHJhZnQtaWV0Zi1zaXBjb3JlLW9yaWdpbmF0 aW5nLWNkaXYtcGFyYW1ldGVyPGJyPg0KPGJyPg0KU29tZSBtb3JlIG11c2luZ3MgZnJvbSBjb25j ZXB0dWFsIHBlcnNwZWN0aXZlOjxicj4NCjxicj4NClNJUCBwcm92aWRlcyBhIHRvb2xib3ggdG8g cHJvdmlkZSBzZXJ2aWNlcy4gQW5kIHllcywgdGhlcmUgaXMgc29tZSBzcGVjaWFsIChpZiBJIG1h eSBzYXkg4oCcZmF2b3JlZOKAnSkgc3RhdHVzIG9mIDNHUFAgd2hlbiBpdCBjb21lcyB0byBTSVAg c3RhbmRhcmRpemF0aW9uLiBPVE9ILCBkb2VzIHRoZSBhcHByb2FjaCB0YWtlbiBieSBSRkM1NTAy IGdvIGEgbGl0dGxlIGJpdCB0b28gZmFyIGluIHRlcm1zIG9mIG92ZXItZGVmaW5pbmcgdGhlIGdl bmVyaWMgU0lQDQogdG9vbGJveD88YnI+DQo8YnI+DQpBbiBhbHRlcm5hdGl2ZSBjb3VsZCBiZSB0 byBkZWZpbmUgYSBoZWFkZXIvcGFyYW1ldGVyIHdoaWNoIHJlZmVycyB0byBhIOKAnHNjZW5hcmlv 4oCdIGluIGFuIGFic3RyYWN0IHdheSAod2l0aCBhIGdlbmVyaWMgc3ludGF4KSBhbmQgbGV0IG90 aGVyIHN0YW5kYXJkcyBmb3JhIGRlZmluZSB0aGUgdmFsdWVzIHRoZXkgd291bGQgbGlrZSB0byB1 c2UgYW5kL29yIHJlbHkgb24gY29uZmlndXJhdGlvbiBhbGlnbm1lbnQgYmV0d2VlbiByZWxldmFu dCBlbGVtZW50cywNCiBlLmcuIFMtQ1NDRi9IU1MvQVMuIENvbnNpZGVyaW5nIHdoZXJlIHdlIGFy ZSByaWdodCBub3cgKHRoYXQgUkZDNTUwMiBpcyBhbHJlYWR5IHRoZXJlKSB0aGlzIGFwcHJvYWNo IHByYWN0aWNhbGx5IHdvdWxkIG1lYW4gdGhhdCBkcmFmdC1pZXRmLXNpcGNvcmUtb3JpZ2luYXRp bmctY2Rpdi1wYXJhbWV0ZXIgaXMgbm90IGRlZmluZWQgYW5kIFAtU2VydmVkLVVzZXIgc2VydmVk LXVzZXItcGFybSBpcyBleHRlbmRlZCBieSBvdGhlcnMgYXMgbmVlZGVkDQogKGFzIGl0IGFsbG93 cyB0aGF0KS48YnI+DQo8YnI+DQpPdGhlcndpc2UsIHRoZXJlIHdvdWxkL2NvdWxkIGJlIHRoZSBu ZWVkIHRvIGtlZXAgYWRkaW5nIG5ldyB2YWx1ZXMgaW4gZGlmZmVyZW50IElFVEYgc3BlY2lmaWNh dGlvbnMgdGhlIG1vcmUg4oCcZGVwbG95bWVudCBtb2RlbCBzcGVjaWZpYyB1c2UgY2FzZXPigJ0g YXJlIG5lZWRlZC9kaXNjb3ZlcmVkL2ludmVudGVkLjxicj4NCjxicj4NClRoYW5rcyw8YnI+DQpU b2xnYTxicj4NCkZyb206IEFzdmVyZW4sIFRvbGdhPGJyPg0KU2VudDogVGh1cnNkYXksIE1hcmNo IDE1LCAyMDE4IDQ6MjMgUE08YnI+DQpUbzogPGEgaHJlZj0ibWFpbHRvOnNpcGNvcmVAaWV0Zi5v cmciPnNpcGNvcmVAaWV0Zi5vcmc8L2E+PGJyPg0KU3ViamVjdDogV0dMQzogZHJhZnQtaWV0Zi1z aXBjb3JlLW9yaWdpbmF0aW5nLWNkaXYtcGFyYW1ldGVyPGJyPg0KPGJyPg0KSSByZXZpZXdlZCB0 aGUgZHJhZnQgYW5kIGhhdmUgbm8gdGVjaG5pY2FsIGlzc3VlcyB3aXRoIGl0IGV4Y2VwdCBvbmUg cXVlc3Rpb246PGJyPg0KPGJyPg0KSXMgaXQgZW52aXNpb25lZCB0aGF0IHRoZXJlIHdvdWxkL2Nv dWxkIGJlIGEgbmVlZCBmb3IgdGVybS1jZGl2IGFzIHdlbGwgdG8gdHJpZ2dlciBhIGRpZmZlcmVu dCBzZXJ2aWNlIHNldCBpZiB0aGUgdGFyZ2V0IGlzIGRldGVybWluZWQgYWZ0ZXIgZGl2ZXJzaW9u PyBJdCBtYXkgYmUgYmV0dGVyIHRvIGRlZmluZSBpdCBub3cgcmF0aGVyIHRoYW4gaGF2aW5nIHll dCBhbm90aGVyIGRyYWZ0LCBhdCBsZWFzdCB0byBiZSBmdXR1cmUgcHJvb2YuPGJyPg0KPGJyPg0K VGhhbmtzLDxicj4NClRvbGdhPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCjxicj4NCkNlIG1lc3Nh Z2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9u cyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYyBwYXMg ZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kg dm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxl ciBhIGwnZXhwZWRpdGV1ciBldCBsZQ0KIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpv aW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2Fs dGVyYXRpb24sIE9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3Nh Z2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS48YnI+DQo8YnI+DQpU aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwg b3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3OyB0 aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0 aG9yaXNhdGlvbi48YnI+DQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9y LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0 cyBhdHRhY2htZW50cy48YnI+DQpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBu b3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBv ciBmYWxzaWZpZWQuPGJyPg0KVGhhbmsgeW91Ljxicj4NCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQo8YnI+DQpDZSBt ZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1h dGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMg cGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24u IFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2ln bmFsZXIgYSBsJ2V4cGVkaXRldXIgZXQgbGUNCiBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNl cyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMg ZCdhbHRlcmF0aW9uLCBPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBt ZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuPGJyPg0KPGJy Pg0KVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50 aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxh dzsgdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0 IGF1dGhvcmlzYXRpb24uPGJyPg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBl cnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFu ZCBpdHMgYXR0YWNobWVudHMuPGJyPg0KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2Ug aXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5n ZWQgb3IgZmFsc2lmaWVkLjxicj4NClRoYW5rIHlvdS48YnI+DQo8YnI+DQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0K PGJyPg0KQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBk ZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9p dmVudCBkb25jIHBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0 b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWls bGV6IGxlIHNpZ25hbGVyIGEgbCdleHBlZGl0ZXVyIGV0IGxlDQogZGV0cnVpcmUgYWluc2kgcXVl IGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3Vz Y2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwgT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxp dGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNp Ljxicj4NCjxicj4NClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWlu IGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3Rl Y3RlZCBieSBsYXc7IHRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3Bp ZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLjxicj4NCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMg ZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMg bWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLjxicj4NCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJl ZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlm aWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC48YnI+DQpUaGFuayB5b3UuPGJyPg0KPGJyPg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpzaXBjb3Jl IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpzaXBjb3JlQGlldGYub3JnIj5zaXBj b3JlQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc2lwY29yZSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vc2lwY29yZTwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CY4PR03MB3160DC8161CD67336793040EA5A20CY4PR03MB3160namp_-- From nobody Thu Mar 29 08:21:30 2018 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 09C7F126BF0 for ; Thu, 29 Mar 2018 08:21:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 MqmV6e7cakdS for ; Thu, 29 Mar 2018 08:21:26 -0700 (PDT) Received: from alum-mailsec-scanner-4.mit.edu (alum-mailsec-scanner-4.mit.edu [18.7.68.15]) by ietfa.amsl.com (Postfix) with ESMTP id D74B1127241 for ; Thu, 29 Mar 2018 08:21:22 -0700 (PDT) X-AuditID: 1207440f-557ff700000068d7-53-5abd046f1b48 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-4.mit.edu (Symantec Messaging Gateway) with SMTP id 5C.16.26839.0740DBA5; Thu, 29 Mar 2018 11:21:20 -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 w2TFLIjx019950 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 29 Mar 2018 11:21:19 -0400 To: Christer Holmberg , Roman Shpount Cc: SIPCORE References: <949dba9e-33b7-66b9-1b16-d25902f65367@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B72E06C39@ESESSMB102.ericsson.se> <7594FB04B1934943A5C02806D1A2204B72E37EC9@ESESSMB109.ericsson.se> <9d3fd31a-af1b-3328-23e6-05c11e7978f0@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B72E38364@ESESSMB109.ericsson.se> From: Paul Kyzivat Message-ID: <336c062b-9d08-d62d-7740-e550015555bd@alum.mit.edu> Date: Thu, 29 Mar 2018 11:21:18 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.6.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+NgFupjleLIzCtJLcpLzFFi42IRYndR1C1k2RtlsPeBhMWFmYcZLWZcmMps 8fXHJjYHZo9fX6+yeSxZ8pPJ49aUggDmKC6blNSczLLUIn27BK6Mc4fXsRf8KKrYtX4yWwNj e1gXIyeHhICJxOXGuWxdjFwcQgI7mCRuXG5nhXAeMkk0nX7IClIlLKAhsX/tT6AqDg4RgSSJ Y90lIGFmATmJtct3sUPUL2KR2PvrBzNIgk1AS2LOof8sIDavgL3EifWz2UBsFgFVifWPVjGB 2KICaRKXmrcyQ9QISpyc+QSsnlPARmLR8cOMEAtsJe7M3c0MYYtL3HoynwnClpdo3jqbeQKj wCwk7bOQtMxC0jILScsCRpZVjHKJOaW5urmJmTnFqcm6xcmJeXmpRbomermZJXqpKaWbGCFB zb+DsWu9zCFGAQ5GJR5eBWCwC7EmlhVX5h5ilORgUhLlTTm3J0qILyk/pTIjsTgjvqg0J7X4 EKMEB7OSCO97jd1RQrwpiZVVqUX5MClpDhYlcV71Jep+QgLpiSWp2ampBalFMFkZDg4lCd5/ zEB7BItS01Mr0jJzShDSTBycIMN5gIZfBKnhLS5IzC3OTIfIn2LU5ZjyvL+HWYglLz8vVUqc VxfkYAGQoozSPLg5sGT0ilEc6C1hXnmQUTzARAY36RXQEiagJSI1e0CWlCQipKQaGBXLLD3u zHs5zbdO+UjtpsenbC94uQZP1Js0jefr97zrd6ac2Vtov+bM4cwM+5qrrfmHJ/yyz92/yr7h VNPvzTMWx139x1VoWqQ408A45caxwiXrmHs2HHwwy65e6u77fPcHRe5u83brFzctOd3Fx9WT ZLzuhMZtTQm5/PvMYisSVgcsex8/uUiJpTgj0VCLuag4EQA8OswNIQMAAA== Archived-At: Subject: Re: [sipcore] session-timer fix 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, 29 Mar 2018 15:21:29 -0000 ISTM an important question is: when does the result of this negotiation take effect? Whenever that is, it overrides an prior s-t (or non-s-t), and presumably can no longer be rolled back if a (re)invite fails. This matters, because it establishes when the timer will expire. For instance, if there is s-t in invite, and response to it in UPDATE, does the new timer start then? Or does it only start when the invite transaction is complete? If it starts as soon as the response is sent in the UPDATE, then what is the significance of additional s-t headers in subsequent messages until the invite transaction is complete? They could be forbidden, or required to match the first "response", or we could allow them to carry out a completely new negotiation. If it only starts when the invite transaction is complete, then any subsequent s-e and min-s-e could again be forbidden, or required to match the first "response", or carry out a completely new negotiation that, when completed would override the earlier negotiated value. But in this case, if the invite fails, none of that would change the s-t state in effect prior to the invite. More inline On 3/29/18 7:07 AM, Christer Holmberg wrote: > Hi Roman, > >> First of all, I agree that in the initial scenario, UA in step 7 should have responded with S-E:uas in 200 OK for Update. >> >> Furthermore, if UA in step 7 did respond without S-E, or with S-E:uac, AS should not have sent 480 in step 9. It should have sent S-E:uas. > > >> Generally, what I am proposing is that, S-E header should be generated based on the S-E status when request or response is generated. If there are multiple inter-lapping transactions S-E state can change and > > S-E state in the response should be set to the S-E value when > response is generated, not when the original request is received. In > case of your example, S-E state in step 9 should be based on results of > the UPDATE > > transaction, not the initial INVITE. This is why it should be sent to > S-E:uas. > > >> Furthermore, we should restrict (with SHOULD, not MUST since existing UA already violate this) that UA should avoid generating requests which will change the current S-E status when another transaction which negotiates S-E is in progress. > > Specifically, in the example provided, UPDATE in step 5 should be > generated with S-E:uas (as it was correctly generated in your example). > Responses generated when another transaction is in progress should be > generated in a way that avoids > > changing the current S-E status (response in step 7 should have been > S-E:has). Because the time value in the s-e is a duration, rather than a data-time, there is the question of when the conversion to date-time is done. If it is done when the s-e header is sent/received, then sending a exact copy of that same header still constitutes a change to the s-e status. >>Finally, even with all of these restrictions there are situations when S-E > status is unclear due to timing. For instance when UPDATE changing the > S-E status is sent at roughly the same time as 200 OK for an INVITE. In > this case, UA cannot distinguish >> >>Scenario A: >>1) UA->AS: INVITE/SE >>2) AS->UA: UPDATE/SE:uac >>3) UA-> AS: 200(UPDATE)/SE:uac >>4) AS-> UA : 200(INVITE) /SE:uac >> >>and >> >>Scenario B: >>1) UA->AS: INVITE/SE >>2) AS->UA: 200(INVITE)/SE:uac >>3) AS->UA: UPDATE/SE:uac >>4) UA->AS: 200(UPDATE)/SE:uac >> >> Between those two scenarios, either AS or UA becomes a refresher based on the message delivery timing. I don't think it scenario A should be valid. The UA indicates in (1) that it wants the AS to choose who is refresher. I don't think it should be able to change its mind about that. This is what is causing the problem. > Why would the AS send SE:mac in message 4)? >> >> These scenarios do not violate any of the proposed rules and can be encountered with existing > SIP implementations. Also, these ambiguity cannot be resolved with > refusing UPDATE request with retry after since UA does not know that 200 > OK and UPDATE are sent close together. >> >> My suggestion is to specify that 200 OK changing S-E status MUST NOT > be sent when UPDATE transaction is in progress. UPDATE changing S-E > status MUST NOT be sent when 200 OK was sent but ACK was not yet received. My comment above at least partly fixes this. This ambiguity would also be fixed if we said that the new timer takes effect as soon as the "s-e-answer" is sent/received. Thanks, Paul >> I would be very interested if you can think of other, more robust ways > to detect and deal with this situation which require modifications only > for one of the SIP UA. > > I am not sure whether your suggestion is any different than mine: UPDATE > requests/responses sent within an going INVITE s-e negotiation must not > change the roles – they must reflect whatever was sent in the INVITE > request and will be sent in the 200 (INVITE) response. > > Regards, > > Christer > > > > > > On Wed, Mar 28, 2018 at 4:51 PM, Christer Holmberg > > > wrote: > > Hi, > > >>>> Ok, I checked some old e-mails, and had a chat with the internal > >>>> people that informed me about the problem. > >>>> > >>>> The UPDATE request with refresher=uas is *NOT* the problem. They > >>>> have the same assumption as Paul, Jonathan etc - the value is > >>>> indicated per transaction. So, UPDATE with refresher=uas is ok. My > >>>> apologies for mixing that up. > >>>> > >>>> It¹s the UPDATE 200 OK response, where the proxy inserts > >>>> refresher=uac, that causes the problem. > >>>> > >>>> So, one alternative would be to allow UPDATE requests/responses sent > >>>> while the s-t negotiation is ongoing are handled as defined in RFC > >>>> 4028, but that the refresher value must not be changed. > >>>> > >>>> In the case below, that means that the UA needs to include s-t > >>>> information in the UPDATE response (message #7). > >>> > >>> That seems like a simpler and cleaner fix, at least for this case. > >>> > >>> To go that way we need to consider other cases. > >>> > >>> In particular, is the UA *required* to include the s-t stuff in the UPDATE if it supports s-t? > >> > >> Min-SE is currently MUST. > >> > >> Session-Expires is currently SHOULD. I guess we could change that to MUST. > >> > >>> What if the UA had omitted the refresher in the INVITE? Presumably then the AS chooses and puts its choice in the UPDATE. > >>> > >>> And once s-e in invite has been responded to with an s-e in an UPDATE, does that finish the negotiation? > >> > >> Yes. The INVITE transaction itself does not matter - it depends on whether s-e is negotiated within the INVITE > >> transaction or not that matters. If there is no s-e negotiation in the INVITE transaction, the UPDATE is treated as > >> any mid-dialog request as far as s-e is concerned. > >> > >>> Then do subsequent messages within the invite transaction and embedded UPDATES repeat the agreed upon result? > >>> Or can they do the negotiation over? > >> > >> Since there is no ongoing s-e negotiation, I see no reason why they can't. > >> > >> In general, unless such text already exist, I think we should recommend against re-negotiating , unless there is a good reason for it. > > > > I guess I didn't make my concerns clear. > > > > ISTM we could use O/A rules as a *model* here: > > > > A negotiation initiated in an INVITE can be completed in a reliable response to the INVITE. Or it can be completed in an UPDATE. > > Once complete, another negotiation is forbidden within the same INVITE transaction. I guess we would change the rules a bit in > > that we don't allow the negotiation to be completed in a reliable provisional. (I would like to permit that, but I think it might be a step too far for > > compatibility.) > > > > But, if we forbid further negotiation within the same INVITE, what do we do instead if there are further UPDATEs? With O/A we can just leave the offers out. > > With s-t, leaving it out normally means negotiating it off. > > So either we change that (which we have already explored), or else I guess we "negotiate" again but agree to only repeat what has already been > > negotiated. (And if we make that rule, what do we do if it is violated? Especially, what if a proxy violates it?) > > My idea was that, if UPDATEs are send during an ongoing INVITE s-t > negotiation, the s-t information in the UPDATEs must reflect the > ongoing negotiation (similar as sending SDP in an unreliable 18x - > it is not really an answer, but it must be a copy of the > to-be-sent-answer). So, in my example, the s-t information in the > UPDATE request from the AS must reflect what the AS will eventually > send in the 200 OK to the INVITE. And, the s-t information in the > UPDATE response from the UA must reflect what the UA sent in the INVITE. > > > Alternately, once the s-t negotiation has completed, we could simply allow another negotiation to be initiated within the same > > invite transaction, even though it seems like a stupid thing to do. > > I agree. > > Regards, > > Christer > > > > > > Regards, > > > > Christer > > > > > > > >> On 23/03/18 22:48, "sipcore on behalf of Christer Holmberg" > >> on behalf of > >> christer.holmberg@ericsson.com > > >> wrote: > >> > >>> Hi Paul, > >>> > >>> You say (and it was indicated in the meeting): > >>> > >>>     "I think it is, since the uac/uas roles are relative to > >>>     the direction of the individual request," > >>> > >>> Assuming that the AS and UA are implemented that way, the problem > >>> still occurs when the AS receives (8), where the refresher > >>> > >>> > >>> > >>> > >>>> Here is the primary use case flow that has been reported as the > >>>> motivating case for the draft. (I've reformatted it for ease in > >>>> typing.) > >>>> > >>>>    1) UA->Proxy: INVITE/SE:uac > >>>>    2) Proxy->AS: INVITE/SE:uac > >>>>    3) AS->Proxy: 18x/no-SE > >>>>    4) Proxy->UA: 18x/no-SE > >>>>    5) AS->Proxy: UPDATE/SE:uas > >>>>    6) Proxy->UA: UPDATE/SE:uas > >>>>    7) UA->Proxy: 200(UPDATE)/no-SE > >>>>    8) Proxy->AS: 200(UPDATE)/SE:uac > >>>>    9) AS->Proxy: 480(INVITE) > >>>> 10) Proxy->UA: 480(INVITE) > >>>> > >>>> Some observations on the above: > >>>> > >>>> - in (5) the AS includes SE in the UPDATE, while in (7) the UA > >>>>     doesn't include SE in the response to the UPDATE. This seems > >>>>     to reflect a difference of opinion by the implementors of > >>>>     the UA and AS about what 4028 expects in this situation. > >>>>     This ambiguity needs to be resolved, and will require changes > >>>>     in some implementations. > >>> > >>> Correct. This is a case where UPDATE is received while the S-T > >>> negotiation is still ongoing. > >>> > >>>> - The 480 in (9) is caused by the AS objecting to the "uac" > >>>>     in (8) because it is in conflict with the "uas" in (5). > >>>>     This in turn is caused by the proxy including the "uac" > >>>>     in (8) because it is following the rules and thinks that > >>>>     the UA doesn't support S-T. This of course isn't the > >>>>     situation. > >>> > >>> Shouldn't the proxy know that the UA supports S-T, due to (1)? > >>> > >>>> - There has been some discussion about whether the "uas" > >>>>     value in (5) is consistent with the "uac" value in (1). > >>>>     I think it is, since the uac/uas roles are relative to > >>>>     the direction of the individual request, and (5) is > >>>>     going in the opposite direction of (1). > >>> > >>> Let's assume it is like that. > >>> > >>>> But this > >>>>     doesn't seem to affect the rest of the analysis. > >>>>     If the refresher in the UPDATE was inconsistent with > >>>>     that in the INVITE then I would expect the UA to send > >>>>     an error response to the UPDATE. > >>>> > >>>> ISTM that at least part of the fix for this must be to fix the > >>>> ambiguity about whether SE is to be included in an UPDATE and its > >>>> response that are embedded in an INVITE transaction. The existing > >>>> draft does address this one way. > >>> > >>> Yes. > >>> > >>>> Another way to address it would be to require SE to be included in > >>>> both the UPDATE and its response, in a way consistent with what was > >>>> in the INVITE and will eventually be in the response to the INVITE. > >>> > >>> Yes. > >>> > >>>> A much different way would be to require that the timer negotiation > >>>> in an INVITE be completed in the first reliable response to the > >>>> INVITE, either 2xx or reliable 1xx. Then any UPDATE that followed > >>>> within the transaction would presumably start a new timer > >>>> negotiation. > >>> > >>> Yes. > >>> > >>>> I'll also observe that this entire discussion has focused on the > >>>> negotiation of the refresher. But there is a comparable issue > >>>> around negotiating the duration of the timer. That ought to be > >>>> sorted out as part of the same fix. > >>> > >>> Yes. > >>> > >>> Regards, > >>> > >>> Christer > >>> > >>> _______________________________________________ > >>> sipcore mailing list > >>> sipcore@ietf.org > >>> https://www.ietf.org/mailman/listinfo/sipcore > > >> > >> > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > > From nobody Thu Mar 29 08:57:40 2018 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 84EF212DA46 for ; Thu, 29 Mar 2018 08:57:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 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, URIBL_BLOCKED=0.001] 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 102LJtxsCyuB for ; Thu, 29 Mar 2018 08:57:36 -0700 (PDT) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::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 AB49E12DA44 for ; Thu, 29 Mar 2018 08:57:36 -0700 (PDT) Received: by mail-pf0-x236.google.com with SMTP id j2so3513213pff.10 for ; Thu, 29 Mar 2018 08:57:36 -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=kobh0udjDOe48hN54eJeyo5xhlksypOiph3mAlu4wT4=; b=Tuj2X4ENSzSvlZXsygCaaaWdMxmgnGXfyY5wqk8YdZiVBczTrd0o5Lid6iBnPEEh/D PV6/X1DxdXYPt6OXgsdBlSkU5d5SMor3G92hiz0U2LzzepzrbSZf8ZWHxtdu6KGxNZ+O iQN11p3N86NUkuuvhSuz+QvLsKTmM6yCFsR4nmUKlgn1Pgiz8AI2ce0b0Qy+vsxSDZYg JtZE7I9iZXdb1Kv+5DX+xmDtCEk35vZX5tTD5BW+gNR1kPteZ1Lf8OVX01WPDWxC/IGc uGkrj9nlMA3UAtixIPZEcCxHVj4V/NGX/woq7Jgds55cLSn9N0ToIL6SEwHZTCIos+mz z/OQ== 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=kobh0udjDOe48hN54eJeyo5xhlksypOiph3mAlu4wT4=; b=qSJBgLz5WYC74wG/3SbERMfZ+ZBe+udYtcnHbGKPuxfDYfthf6T/4skTlvW9n+Dw6M ADfZXazGi5hwzBFVz97HA6wr7zt+cxVolujXneEM70/LlwQPUHE9+7oYgzPpWm4DwHze jejVx2/lTlxfc+7zBIyr9zSvGVDOXbFC4Kv1Heu5bee1OvXEuGEhWZ0V7BARqbmgyGSN JHJDmaDS+37e7lNq5DYn8Bkd0EXpPJAvMtvsICewJZs8pUplme7tZZ8/E87PRAICKGMU 4wiR/QoC+KtqRdCFK1uVn3sBQdwdLrNLt3iIv/GxbAJe6SulcsF+GmNGalcY/FG4I9bs KxBQ== X-Gm-Message-State: AElRT7GsG7Q4/PheSlj43bKwnaQ+fxZPZZGykzEoAZT5ON4wT60z33aD hUjFasU3mo95qVQfU5I4p4si380B X-Google-Smtp-Source: AIpwx481lxJ0sSvr3dOl+tE7Ux9z2saicIxPK8r7hpyvvvG2VzPeKRyxpMNvSIuVvXyZTDbC6nZZWQ== X-Received: by 10.99.126.87 with SMTP id o23mr5924876pgn.350.1522339056000; Thu, 29 Mar 2018 08:57:36 -0700 (PDT) Received: from mail-pf0-f178.google.com (mail-pf0-f178.google.com. [209.85.192.178]) by smtp.gmail.com with ESMTPSA id a4sm15813662pfj.107.2018.03.29.08.57.34 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Mar 2018 08:57:34 -0700 (PDT) Received: by mail-pf0-f178.google.com with SMTP id h69so3514987pfe.13 for ; Thu, 29 Mar 2018 08:57:34 -0700 (PDT) X-Received: by 2002:a17:902:8548:: with SMTP id d8-v6mr4008291plo.241.1522339054392; Thu, 29 Mar 2018 08:57:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.241.132 with HTTP; Thu, 29 Mar 2018 08:57:33 -0700 (PDT) In-Reply-To: References: <949dba9e-33b7-66b9-1b16-d25902f65367@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B72E06C39@ESESSMB102.ericsson.se> <7594FB04B1934943A5C02806D1A2204B72E37EC9@ESESSMB109.ericsson.se> <9d3fd31a-af1b-3328-23e6-05c11e7978f0@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B72E38364@ESESSMB109.ericsson.se> From: Roman Shpount Date: Thu, 29 Mar 2018 11:57:33 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Christer Holmberg Cc: Paul Kyzivat , SIPCORE Content-Type: multipart/alternative; boundary="000000000000909beb05688f2e50" Archived-At: Subject: Re: [sipcore] session-timer fix 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, 29 Mar 2018 15:57:38 -0000 --000000000000909beb05688f2e50 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Mar 29, 2018 at 7:07 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > >Scenario A: > >1) UA->AS: INVITE/SE > >2) AS->UA: UPDATE/SE:uac > >3) UA-> AS: 200(UPDATE)/SE:uac > >4) AS-> UA : 200(INVITE) /SE:uac > > > >and > > > >Scenario B: > >1) UA->AS: INVITE/SE > >2) AS-> UA : 200(INVITE) /SE:uac > >3) AS->UA: UPDATE/SE:uac > >4) UA-> AS: 200(UPDATE)/SE:uac > > > > Between those two scenarios, either AS or UA becomes a refresher based > on the message delivery timing. > > Why would the AS send SE:mac in message 4)? > Scenario A is not entirely legal but Scenario B can look like Scenario A due to message re-order. Scenario B is legal and can happen when let's say B2BUA is switching a call to a new destination right after the INVITE transaction was completed and needs for some reason to change S-E role at the same time. > I am not sure whether your suggestion is any different than mine: UPDATE > requests/responses sent within an going INVITE s-e negotiation must not > change the roles =E2=80=93 they must reflect whatever was sent in the INV= ITE > request and will be sent in the 200 (INVITE) response. > I agree with your suggestion except that I think UPDATE requests/responses sent within an going INVITE s-e negotiation SHOULD NOT change the roles. Furthermore there are existing implementations that break this restriction, so we need to define how compliant implementations should handle such requests. Refusing UPDATE is not always an option since, for instance in my Scenario A, UA does not know S-E: header value for 200 OK in advance. I just think UA should not hang up the call when 200 OK in step 4 with non-matching S-E is received and deal with this situation gracefully. Regards, _______________ Roman Shpount --000000000000909beb05688f2e50 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Mar 29, 2018 at 7:07 AM, Ch= rister Holmberg <christer.holmberg@ericsson.com> wrote:
>Scenario A:
>1) UA->AS: INVITE/SE
>2) AS->UA: UPDATE/SE:uac
>3) UA-> AS: 200(UPDATE)/SE:uac
>4) AS-> UA : 200(INVITE) /SE:uac=C2=A0
>
>and
>
>Scenario B:
>1) UA->AS: INVITE/SE
>2) AS->=C2=A0UA=C2=A0: 200(INVITE)=C2=A0/SE:uac= =C2=A0
>3) AS->UA: UPDATE/SE:uac
>4) UA->=C2=A0AS: 200(UPDATE)/SE:uac=C2=A0
>
> Between those two scenarios, either AS or UA becomes a refresher based on the message delivery timing.<= /span>

Why would the AS send SE:mac in message 4)?

Scenario A is not entirely legal but Scenario B ca= n look like Scenario A due to message re-order. Scenario B is legal and can= happen when let's say B2BUA is switching a call to a new destination r= ight after the INVITE transaction was completed and needs for some reason t= o change S-E role at the same time.
=C2=A0=C2=A0
I am not sure whether your suggestion is any different than mine: UPDA= TE requests/responses sent within an going INVITE s-e negotiation must not = change the roles =E2=80=93 they must reflect whatever was sent in the INVIT= E request and will be sent in the 200 (INVITE) response.

I agr= ee with your suggestion except that I think =C2=A0UPDATE requests/responses= sent within an going INVITE s-e negotiation SHOULD NOT change the roles. F= urthermore there are existing implementations that break this restriction, = so we need to define how compliant implementations should handle such reque= sts. Refusing UPDATE is not always an option since, for instance in my Scen= ario A, UA does not know S-E: header value for 200 OK in advance. I just th= ink UA should not hang up the call when 200 OK in step 4 with non-matching = S-E is received and deal with this situation gracefully.

Regards,
_______= ________
Roman Shpount
--000000000000909beb05688f2e50-- From nobody Thu Mar 29 09:20:28 2018 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 4720312DA68 for ; Thu, 29 Mar 2018 09:20: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 58NMuYXLGrCO for ; Thu, 29 Mar 2018 09:20:25 -0700 (PDT) Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::22e]) (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 6DE4412DA12 for ; Thu, 29 Mar 2018 09:20:25 -0700 (PDT) Received: by mail-pg0-x22e.google.com with SMTP id i124so3367231pgc.10 for ; Thu, 29 Mar 2018 09:20: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=KeMtMuqTQ0TFGmnkZVWmt2dyzZEJ0Agth0UwqR6EcTc=; b=Vn5ekKDpXYomMezpyssuXY06BljWLZWYPdyhq7S4ceKgoMUxCj/OEK2LlEGZgJ8vvu jpdImcBBZfCp2bCq1rexFZIDyiOtp/4SJHYB/Sb8B5uiHnpkVDYMNf73p+bFx1KsCroQ ZTxyJXTjEqRXj689+3iuTp84BPEyCWsBXzx4/1pWvnbv3K8RtMaYrmqECKUxmwGUKygJ HKW1fhe+4HIf6d8yfuCMT9Rc4sEEDNF40X+8ajGVraeXg0bN+tMyTO00iUr7r1az/1DM 0unBj1MyVtiDv+fwKQbqrXXx07SklXUyz01OCDjik08A0HHffvhL0wDJxpGo3pRtUAWu 9bMQ== 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=KeMtMuqTQ0TFGmnkZVWmt2dyzZEJ0Agth0UwqR6EcTc=; b=ZoyLYLF/iZ6vhvObaVHqLcoY/y3w0vhn7u1nognpzl+qXcmkFsafAoMNqb6zD91U61 b5Afevh8ex+pyD80L4n9GGJXL9K6GymjFp5QuVnssZahAeeuOBd4WsvJrMDxcjKoW3wu KZEG8Ql7xEZ/ynVyQEIpR7tHIRrUq1t6/IVL8eeptYcv7Xw8Uhiy5GXyHFTE1RuUZY1I 6QlZ+wOMMn4opLQPjd/9EwW8PzMBLh4XToG0ju7Tb6vFlOHjLVdgtdaWrKSg8KeQtf5t NtGpg6IG/eetH3MsTbS0QkiBbPzekFDrFiA7aJXnR6TMLfiWqI3G4c2GI+A9GgTXDYvn QAcw== X-Gm-Message-State: AElRT7HAb6pzqqw6IvaQ2Xdlwe+1ueHtolgJStbm8PLdS2FYlH7s+VxV TQajX0rjG3Z0xJuMwfnZBvLo7YKz X-Google-Smtp-Source: AIpwx49JTqmDxqSh2yQA7nw7PF1A+k8K7A+2CUNasuf5AsSSrUGj/S+OQP68T89CKCjJxosMbL6pyg== X-Received: by 10.98.155.12 with SMTP id r12mr6860382pfd.15.1522340424778; Thu, 29 Mar 2018 09:20:24 -0700 (PDT) Received: from mail-pg0-f51.google.com (mail-pg0-f51.google.com. [74.125.83.51]) by smtp.gmail.com with ESMTPSA id e23sm12404634pfi.76.2018.03.29.09.20.24 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Mar 2018 09:20:24 -0700 (PDT) Received: by mail-pg0-f51.google.com with SMTP id i124so3367181pgc.10 for ; Thu, 29 Mar 2018 09:20:24 -0700 (PDT) X-Received: by 2002:a17:902:8b82:: with SMTP id ay2-v6mr8859298plb.12.1522340423816; Thu, 29 Mar 2018 09:20:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.241.132 with HTTP; Thu, 29 Mar 2018 09:20:23 -0700 (PDT) In-Reply-To: <336c062b-9d08-d62d-7740-e550015555bd@alum.mit.edu> References: <949dba9e-33b7-66b9-1b16-d25902f65367@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B72E06C39@ESESSMB102.ericsson.se> <7594FB04B1934943A5C02806D1A2204B72E37EC9@ESESSMB109.ericsson.se> <9d3fd31a-af1b-3328-23e6-05c11e7978f0@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B72E38364@ESESSMB109.ericsson.se> <336c062b-9d08-d62d-7740-e550015555bd@alum.mit.edu> From: Roman Shpount Date: Thu, 29 Mar 2018 12:20:23 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Paul Kyzivat Cc: Christer Holmberg , SIPCORE Content-Type: multipart/alternative; boundary="000000000000305ef105688f8057" Archived-At: Subject: Re: [sipcore] session-timer fix 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, 29 Mar 2018 16:20:27 -0000 --000000000000305ef105688f8057 Content-Type: text/plain; charset="UTF-8" Hi Paul, On Thu, Mar 29, 2018 at 11:21 AM, Paul Kyzivat wrote: > ISTM an important question is: when does the result of this negotiation > take effect? Whenever that is, it overrides an prior s-t (or non-s-t), and > presumably can no longer be rolled back if a (re)invite fails. This > matters, because it establishes when the timer will expire. > I think the negotiation takes place when success response is sent or received. UPDATE within INVITE transaction are two different S-E negotiations. For instance, if there is s-t in invite, and response to it in UPDATE, does > the new timer start then? Or does it only start when the invite transaction > is complete? > There is no response for S-T in INVITE in UPDATE request. These are two independent negotiations. What I meant by S-T state is refresher role and expiration duration. Timer starts when success message is sent or received. New timer starts on each successful response message even if S-E refresher role or expiration duration did not change. > If it starts as soon as the response is sent in the UPDATE, then what is > the significance of additional s-t headers in subsequent messages until the > invite transaction is complete? They could be forbidden, or required to > match the first "response", or we could allow them to carry out a > completely new negotiation. > As I have said, I think S-E timer should start when success response is sent or received. For UPDATE within INVITE transaction timer starts first on UPDATE success response and then restarted on INVITE success response. UPDATE transactions within INVITE transaction can negotiate S-T. One valid example is as follows: 1) UA->AS: INVITE/supported:timer 2) AS->UA: 183(INVITE) 3) UA->AS: UPDATE/SE:uac 4) AS-> UA: 200(UPDATE)/SE:uac 5) AS-> UA : 200(INVITE) /SE:uac Initial INVITE indicates support for session timer but no session expiration. UPDATE initiates initiates the session timer expiration which is accepted by AS. TImer starts when message in step 4 is sent/received. S-T is renegotiated when message in step 5 is sent received and timer is restarted even though SE header is exactly the same in steps 4 and 5 and refresher and SE duration did not change. Because the time value in the s-e is a duration, rather than a data-time, > there is the question of when the conversion to date-time is done. If it is > done when the s-e header is sent/received, then sending a exact copy of > that same header still constitutes a change to the s-e status. > As I have mentioned above, what I meant by s-t state is refresher role and expiration duration. These SHOULD NOT be changed by UPDATE messages within the INVITE transaction. TImer is re-started with current expiration duration whenever any success response is sent or received. > > Scenario A: >>> >> 1) UA->AS: INVITE/SE >>> 2) AS->UA: UPDATE/SE:uac >>> 3) UA-> AS: 200(UPDATE)/SE:uac >>> 4) AS-> UA : 200(INVITE) /SE:uac >>> >>> and >>> >>> Scenario B: >>> 1) UA->AS: INVITE/SE >>> 2) AS->UA: 200(INVITE)/SE:uac >>> 3) AS->UA: UPDATE/SE:uac >>> 4) UA->AS: 200(UPDATE)/SE:uac >>> >>> Between those two scenarios, either AS or UA becomes a refresher based >>> on the message delivery timing. >>> >> > I don't think it scenario A should be valid. The UA indicates in (1) that > it wants the AS to choose who is refresher. I don't think it should be able > to change its mind about that. This is what is causing the problem. Scenario B can end up looking like scenario A due to message re-order. Scenario B is legal and can happen when let's say B2BUA is switching a call to a new destination right after the INVITE transaction was completed and needs for some reason to change S-E role at the same time. Furthermore, Scenario A can happen with legacy SIP implementations and I think we need to provide guidance how this should be gracefully handled. Regards, ______________ Roman Shpount --000000000000305ef105688f8057 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Paul,

<= div>
On Th= u, Mar 29, 2018 at 11:21 AM, Paul Kyzivat <pkyzivat@alum.mit.edu&g= t; wrote:
ISTM an important question is: when does the result of this = negotiation take effect? Whenever that is, it overrides an prior s-t (or no= n-s-t), and presumably can no longer be rolled back if a (re)invite fails. = This matters, because it establishes when the timer will expire.

I think the negotiation takes place when success = response is sent or received. UPDATE within INVITE transaction are two diff= erent S-E negotiations.=C2=A0

For instance, if there is s-t in invite, and response to it in UPDATE= , does the new timer start then? Or does it only start when the invite tran= saction is complete?

There is no respon= se for S-T in INVITE in UPDATE request. These are two independent negotiati= ons.

What I meant by S-T state is refresher role a= nd expiration duration. Timer starts when success message is sent or receiv= ed. New timer starts on each successful response message even if S-E refres= her role or expiration duration did not change.
=C2=A0
If it starts as soon as the response is sent in t= he UPDATE, then what is the significance of additional s-t headers in subse= quent messages until the invite transaction is complete? They could be forb= idden, or required to match the first "response", or we could all= ow them to carry out a completely new negotiation.
=C2= =A0
As I have said, I think S-E timer should start when success r= esponse is sent or received. For UPDATE within INVITE transaction timer sta= rts first on UPDATE success response and then restarted on INVITE success r= esponse. UPDATE transactions within INVITE transaction can negotiate S-T.

One valid example is as follows:

1)=C2=A0 UA->AS: INVITE/supported:timer=
2)=C2=A0 AS->UA: 183(INVITE)
3)=C2=A0 UA= ->AS: UPDATE/SE:uac
4)=C2=A0 AS-> UA: 2= 00(UPDATE)/SE:uac
5)=C2=A0 AS-> UA : 200(I= NVITE) /SE:uac

Initial INVITE indicates support for session = timer but no session expiration. UPDATE initiates initiates the session tim= er expiration which is accepted by AS.=C2=A0 TImer starts when message in s= tep 4 is sent/received. S-T is renegotiated when message in step 5 is sent = received and timer is restarted even though SE header is exactly the same i= n steps 4 and 5 and refresher and SE duration did not change.
Because the time value in the s-e is = a duration, rather than a data-time, there is the question of when the conv= ersion to date-time is done. If it is done when the s-e header is sent/rece= ived, then sending a exact copy of that same header still constitutes a cha= nge to the s-e status.

As I have mentio= ned above, what I meant by s-t state is=C2=A0=C2=A0
Scenario=C2=A0 A:
1)=C2=A0 UA->AS: INVITE/SE
2)=C2=A0 AS->UA: UPDATE/SE:uac
3)=C2=A0 UA-> AS: 200(UPDATE)/SE:uac
4)=C2=A0 AS-> UA : 200(INVITE) /SE:uac

and

Scenario=C2=A0 B:
1)=C2=A0 UA->AS: INVITE/SE
 2)=C2=A0 AS->UA: 200(INVITE)/SE:uac
3)=C2=A0 AS->UA: UPDATE/SE:uac
4)=C2=A0 UA->AS: 200(UPDATE)/SE:uac

Between those two scenarios,=C2=A0 either AS or UA becomes a refresher base= d on the message delivery timing.

I don't think it scenario A should be valid. The UA indicates in (1) th= at it wants the AS to choose who is refresher. I don't think it should = be able to change its mind about that. This is what is causing the problem.=

Scenario B can end up looking like scenari= o A due to message re-order.=C2=A0 Scenario B is legal and can happen when let's s= ay B2BUA is switching a call to a new destination right after the INVITE tr= ansaction was completed and needs for some reason to change S-E role at the= same time. Furthermore, Scenario A can happen with legacy SIP implementati= ons and I think we need to provide guidance how this should be gracefully h= andled.

Regards,
______________
Roman Shpount
--000000000000305ef105688f8057-- From nobody Fri Mar 30 05:19:34 2018 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 27C8F12D7EF for ; Fri, 30 Mar 2018 05:19:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 PcDVsqPXvFu4 for ; Fri, 30 Mar 2018 05:19:32 -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 9AC38126BF6 for ; Fri, 30 Mar 2018 05:19:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1522412369; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=zB7pwa6geNgpV2yYSzjkcY9jCnO/B58LGvCGsA3lIPI=; b=hQs8qxoH7eE9N2dUcma90CkWxb43n8flg0+CRYCbjZYVo4GwUfOA0dFHQSFEzey8 DjXWnEW2j9p7+H3lDGSLSkFbCoJzIvzpXdxnUukOuScuWiTygknf2B8raO6xN8sc lHtjdokEDt3gaRhXcMmN/MdZNemi/zdvjjqY0igD0WY=; X-AuditID: c1b4fb3a-e39ff70000005d56-55-5abe2b5197a2 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 5D.BD.23894.15B2EBA5; Fri, 30 Mar 2018 14:19:29 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.115]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0382.000; Fri, 30 Mar 2018 14:19:28 +0200 From: Christer Holmberg To: Roman Shpount , Paul Kyzivat CC: SIPCORE Thread-Topic: [sipcore] session-timer fix Thread-Index: AQHTwfCeyHYsx4XVTkSHOLQKDcONKqPdSEtwgAhcbACAABDAgIAANGeAgAARLYCAACxJgP//8R6AgAERIACAABQxAIAAEIGAgAFu7qA= Date: Fri, 30 Mar 2018 12:19:28 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B72E3D2D7@ESESSMB109.ericsson.se> References: <949dba9e-33b7-66b9-1b16-d25902f65367@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B72E06C39@ESESSMB102.ericsson.se> <7594FB04B1934943A5C02806D1A2204B72E37EC9@ESESSMB109.ericsson.se> <9d3fd31a-af1b-3328-23e6-05c11e7978f0@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B72E38364@ESESSMB109.ericsson.se> <336c062b-9d08-d62d-7740-e550015555bd@alum.mit.edu> 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.172] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmkeLIzCtJLcpLzFFi42KZGbFdUTdQe1+UwalN2hYrNhxgtZhxYSqz xdcfm9gcmD3+vv/A5LFkyU8mj1tTCgKYo7hsUlJzMstSi/TtErgypu6dxlxwiK2i5eFslgbG NWxdjJwcEgImEtt332LpYuTiEBI4wijxef5LdghnCaPExaVHgao4ONgELCS6/2mDNIgIeEv0 9XWwg9jMAnIS1z9sBBskLKAhsfX1I1aIGk2JP7M3MEPYZRKXexaC1bMIqEr8n7uOEcTmFfCV OLC6gRFi13xWiSWXbjCBJDgFAiVW9vwBa2YUEJP4fmoNE8QycYlbT+YzQVwtILFkz3lmCFtU 4uXjf6wgd0oIKEk0zGQBMZmBbli/Sx+iU1FiSvdDdoi1ghInZz5hmcAoOgvJ0FkIHbOQdMxC 0rGAkWUVo2hxanFxbrqRkV5qUWZycXF+nl5easkmRmDUHNzy22oH48HnjocYBTgYlXh44yX3 RQmxJpYVV+YeYpTgYFYS4bU6uTdKiDclsbIqtSg/vqg0J7X4EKM0B4uSOK9TmkWUkEB6Yklq dmpqQWoRTJaJg1OqgdEgVeSuil7C1DUvs00rL4qnXuCZaa5qKeAy6dzjeYLv5SsNfQw59Q5e cq66JGl8X2zxitVufzOvNp8W4PorsMNcRC7h2GbTXVmzbK4H2YadvR0TFCfafJzpW9JengUS v8Vub5b96J0iv9PCsm57xj6hlV3Fc1/0ruWyq3xk05UTeUrhxq7zjUosxRmJhlrMRcWJADu+ ruSWAgAA Archived-At: Subject: Re: [sipcore] session-timer fix 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, 30 Mar 2018 12:19:33 -0000 SGksDQoNCj4+IElTVE0gYW4gaW1wb3J0YW50IHF1ZXN0aW9uIGlzOiB3aGVuIGRvZXMgdGhlIHJl c3VsdCBvZiB0aGlzIG5lZ290aWF0aW9uIHRha2UgZWZmZWN0PyBXaGVuZXZlciANCj4+IHRoYXQg aXMsIGl0IG92ZXJyaWRlcyBhbiBwcmlvciBzLXQgKG9yIG5vbi1zLXQpLCBhbmQgcHJlc3VtYWJs eSBjYW4gbm8gbG9uZ2VyIGJlIHJvbGxlZCBiYWNrIGlmIGEgKHJlKWludml0ZSBmYWlscy4gDQo+ PiBUaGlzIG1hdHRlcnMsIGJlY2F1c2UgaXQgZXN0YWJsaXNoZXMgd2hlbiB0aGUgdGltZXIgd2ls bCBleHBpcmUuDQo+DQo+IEkgdGhpbmsgdGhlIG5lZ290aWF0aW9uIHRha2VzIHBsYWNlIHdoZW4g c3VjY2VzcyByZXNwb25zZSBpcyBzZW50IG9yIHJlY2VpdmVkLiBVUERBVEUgd2l0aGluIElOVklU RSB0cmFuc2FjdGlvbiBhcmUgdHdvIGRpZmZlcmVudCBTLUUgbmVnb3RpYXRpb25zLsKgDQoNCkkg YWdyZWUuIEkgZG9uJ3QgdGhpbmsgYSBzLWUgbmVnb3RpYXRpb24gc2hvdWxkIHNwYW4gbXVsdGlw bGUgU0lQIHRyYW5zYWN0aW9ucy4gVGhhdCB3b3VsZCBjb21wbGljYXRlIHRoaW5ncyBldmVuIGZ1 cnRoZXIsIElNTy4uLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0K From nobody Fri Mar 30 09:35:00 2018 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 5E533124F57 for ; Fri, 30 Mar 2018 09:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 TKwAnqWWAroP for ; Fri, 30 Mar 2018 09:34:59 -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 3001A1201FA for ; Fri, 30 Mar 2018 09:34:58 -0700 (PDT) X-AuditID: 12074414-361ff70000000a41-ac-5abe67315080 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 18.09.02625.1376EBA5; Fri, 30 Mar 2018 12:34: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 w2UGYuUn007820 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 30 Mar 2018 12:34:57 -0400 To: Christer Holmberg , Roman Shpount Cc: SIPCORE References: <949dba9e-33b7-66b9-1b16-d25902f65367@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B72E06C39@ESESSMB102.ericsson.se> <7594FB04B1934943A5C02806D1A2204B72E37EC9@ESESSMB109.ericsson.se> <9d3fd31a-af1b-3328-23e6-05c11e7978f0@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B72E38364@ESESSMB109.ericsson.se> <336c062b-9d08-d62d-7740-e550015555bd@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B72E3D2D7@ESESSMB109.ericsson.se> From: Paul Kyzivat Message-ID: Date: Fri, 30 Mar 2018 12:34:56 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B72E3D2D7@ESESSMB109.ericsson.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmleLIzCtJLcpLzFFi42IRYndR1DVM3xdl8OakksWFmYcZLWZcmMps 8fXHJjYHZo9fX6+yeSxZ8pPJ49aUggDmKC6blNSczLLUIn27BK6MOVdrC76wVRx48ZS1gfEM axcjB4eEgInE6YUcXYxcHEICO5gkdp2/wQbhPGSS+HjzJHsXIyeHsICGxP61P9lAGkQEkiSO dZeAhJkF5CTWLt/FDlH/mFVi1ddVbCAJNgEtiTmH/rOA1PMK2Ev8XxYHEmYRUJXYt28NI4gt KpAmcal5KzOIzSsgKHFy5hMWEJtTwE9i7Ym/TBDzzSTmbX7IDGGLS9x6Mh8qLi+x/e0c5gmM ArOQtM9C0jILScssJC0LGFlWMcol5pTm6uYmZuYUpybrFicn5uWlFula6OVmluilppRuYoSE s8gOxiMn5Q4xCnAwKvHwMsTvixJiTSwrrsw9xCjJwaQkylsoAhTiS8pPqcxILM6ILyrNSS0+ xCjBwawkwmt1cm+UEG9KYmVValE+TEqag0VJnJfZBCglkJ5YkpqdmlqQWgSTleHgUJLgDUkD GipYlJqeWpGWmVOCkGbi4AQZzgM0nBmkhre4IDG3ODMdIn+KUZdjyvP+HmYhlrz8vFQpcd4M kCIBkKKM0jy4ObA09IpRHOgtYd5OkCoeYAqDm/QKaAkT0BKRmj0gS0oSEVJSDYwSP2eU9ouz SQuoyTdxTfj80+e7fbOk/pbOp7fOueUmuoSWz3nJZPjAe83sM4dig9Z9idhiY6uym+U3p/nu z9LnnpyfVtI/MzTo8c+tk8rTVdTSij+k8H5WLZIx1X3w8GwVn+gKqXQXyVudSzekXTmePv2r QuT++6zaH/c5K4tb+J1e8CuVO0OJpTgj0VCLuag4EQC0si2HHgMAAA== Archived-At: Subject: Re: [sipcore] session-timer fix 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, 30 Mar 2018 16:35:00 -0000 On 3/30/18 8:19 AM, Christer Holmberg wrote: > Hi, > >>> ISTM an important question is: when does the result of this negotiation take effect? Whenever >>> that is, it overrides an prior s-t (or non-s-t), and presumably can no longer be rolled back if a (re)invite fails. >>> This matters, because it establishes when the timer will expire. >> >> I think the negotiation takes place when success response is sent or received. UPDATE within INVITE transaction are two different S-E negotiations. > > I agree. I don't think a s-e negotiation should span multiple SIP transactions. That would complicate things even further, IMO... I don't understand what you mean here. If you offer s-e in invite, and then send an update (which is another transaction) with s-e, then ISTM you necessarily have an s-e negotiation spanning multiple sip transactions. Thanks, Paul From nobody Fri Mar 30 09:43:08 2018 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 9CF3D124F57 for ; Fri, 30 Mar 2018 09:43:07 -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 O1ihpgTGbLFa for ; Fri, 30 Mar 2018 09:43:06 -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 08B801201FA for ; Fri, 30 Mar 2018 09:43:06 -0700 (PDT) Received: by mail-pf0-x233.google.com with SMTP id y66so5674118pfi.7 for ; Fri, 30 Mar 2018 09:43:06 -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=QSFhrqLuB4G8s2x+AkGxpAegCfeYbB4n5D7HzMgtjrU=; b=TPffCojRfJcp6DAMDk09LOVlpLdZ8WNS1hIQv6h1bNMi4lhWvAx7RX/ggvOFocrsJp Gq2D5vRcuXHYVVUBjkhx2gANe8V5hwEQVwjztGFXhfd+u9M+mY6q0JT+0RwsameirgYh scx+VVvBd1zgzvdnwWgAIHdHMvrKxNB7W3A4B0f2l9DayYZ9N/dpQbKPb0uCZSxLd7qs TXRwg6njtzE0x55g0/TbPzS0gtklUFKdx/QS9awkOf7yUz4ogpU4Oizrvc8pv8CdXlba xJVPI+AulMBOfB2F5tl+0Ycp6L4oOD68jCSZPb/AqXq9+qB3px+xI0me2B9VFILhWxTa bs7A== 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=QSFhrqLuB4G8s2x+AkGxpAegCfeYbB4n5D7HzMgtjrU=; b=qUniv4YECY60Qy+fznpRlQ2h7wkKWrL91Ld+BvJ8cYySEFaUSY0FTh+RnMZOb/+2i/ La0zEHtc5Et3kfiUP23HwxcelZzS0cxEzG3gNBT/rocFgh5CDs6dpfmkD7oGLXLva+YJ SBXcjP81v3XsoTGk6hsRntvF2+Red/oZdVSUEy/HwJuP37GoxuCZipxvL4xYrZ44G7Wz qm5U7eww21gCWrqIR5f7XJARfkh0rO/mhm31mA9VjpJNVxHXxeKbmaAldLkO7NXWA4Zz iEEN0sHoXYxdbq6m+5ya2IkeL2nCPHty1kJtyEPdaJNmKzKBWShN/Cif24l29FUm/4FH gJjA== X-Gm-Message-State: AElRT7Fc84gKZzuODYOa6G7BVoSZtqQGdoMcj8oX1t43/pNNf4e5s6j2 Tj7znkq2GdFCk+n8EB4ZJbOmRMap X-Google-Smtp-Source: AIpwx4+15IxlLhmYndfCojMhNIHkSpVgSgm0xYhdn93Hobefy3NkcswuMnbTgvjBDJvJk7RtBKNSgQ== X-Received: by 10.98.36.76 with SMTP id r73mr8452249pfj.108.1522428185436; Fri, 30 Mar 2018 09:43:05 -0700 (PDT) Received: from mail-pg0-f47.google.com (mail-pg0-f47.google.com. [74.125.83.47]) by smtp.gmail.com with ESMTPSA id 67sm16244960pfz.57.2018.03.30.09.43.04 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 30 Mar 2018 09:43:04 -0700 (PDT) Received: by mail-pg0-f47.google.com with SMTP id h3so1281548pgq.7 for ; Fri, 30 Mar 2018 09:43:04 -0700 (PDT) X-Received: by 10.98.11.144 with SMTP id 16mr10328216pfl.228.1522428184289; Fri, 30 Mar 2018 09:43:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.241.132 with HTTP; Fri, 30 Mar 2018 09:43:03 -0700 (PDT) In-Reply-To: References: <949dba9e-33b7-66b9-1b16-d25902f65367@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B72E06C39@ESESSMB102.ericsson.se> <7594FB04B1934943A5C02806D1A2204B72E37EC9@ESESSMB109.ericsson.se> <9d3fd31a-af1b-3328-23e6-05c11e7978f0@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B72E38364@ESESSMB109.ericsson.se> <336c062b-9d08-d62d-7740-e550015555bd@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B72E3D2D7@ESESSMB109.ericsson.se> From: Roman Shpount Date: Fri, 30 Mar 2018 12:43:03 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Paul Kyzivat Cc: Christer Holmberg , SIPCORE Content-Type: multipart/alternative; boundary="001a1145b8fe1ee63f0568a3efa6" Archived-At: Subject: Re: [sipcore] session-timer fix 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, 30 Mar 2018 16:43:07 -0000 --001a1145b8fe1ee63f0568a3efa6 Content-Type: text/plain; charset="UTF-8" On Fri, Mar 30, 2018 at 12:34 PM, Paul Kyzivat wrote: > On 3/30/18 8:19 AM, Christer Holmberg wrote: > >> I think the negotiation takes place when success response is sent or >>> received. UPDATE within INVITE transaction are two different S-E >>> negotiations. >>> >> >> I agree. I don't think a s-e negotiation should span multiple SIP >> transactions. That would complicate things even further, IMO... >> > > I don't understand what you mean here. If you offer s-e in invite, and > then send an update (which is another transaction) with s-e, then ISTM you > necessarily have an s-e negotiation spanning multiple sip transactions. > I think having multiple transaction going on at the same time means multiple S-T negotiations. Each negotiation takes effect when final success response for this transaction is sent. For instance here: 1) UA->AS: INVITE/supported:timer 2) AS->UA: 183(INVITE) 3) UA->AS: UPDATE/SE:uac 4) AS-> UA: 200(UPDATE)/SE:uac 5) UA->AS: UPDATE/SE:uac 6) AS-> UA: 200(UPDATE)/SE:uac 7) AS-> UA : 200(INVITE) /SE:uac There are 3 S-T negotiations: 2 for UPDATE transactions and 1 for INVITE. Session timer is (re-)started 3 times: in steps 4, 6, and 7. Also, as things are defined now, each of these transactions (both UPDATES and the INVITE) can change refresher role and session expires interval. Each of those changes takes effect when final success response is either sent or relieved in steps 4, 6, and 7. Regards, _____________ Roman Shpount --001a1145b8fe1ee63f0568a3efa6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Mar 30, 2018 at 12:34 PM, P= aul Kyzivat <pkyzivat@alum.mit.edu> wrote:
On 3/30/18 8:19 AM, Christer Holmberg wrote:
I think the n= egotiation takes place when success response is sent or received. UPDATE wi= thin INVITE transaction are two different S-E negotiations.

I agree. I don't think a s-e negotiation should span multiple SIP trans= actions. That would complicate things even further, IMO...

 I don't understand what you mean here. If you offer s-e in invite, and = then send an update (which is another transaction) with s-e, then ISTM you = necessarily have an s-e negotiation spanning multiple sip transactions.
=

I think having multiple transaction going = on at the same time means multiple S-T negotiations. Each negotiation takes= effect when final success response for this transaction is sent.

For instance here:

1)=C2=A0 UA->AS: INVITE/supported:timer=
2)=C2=A0 AS->UA: 183(I= NVITE)
3)=C2=A0 UA->AS: UPDATE/SE:uac
= 4)=C2=A0 AS-> UA: 200(UPDATE)/SE:uac
5)=C2=A0 UA->AS: UPDATE/SE:uac
6)=C2=A0 AS-> UA: 200(UPDATE)/SE:uac
7)=C2=A0 AS-> UA := 200(INVITE) /SE:uac=C2=A0

There are 3 S-T negotiations: 2 for UPDATE transac= tions and 1 for INVITE. Session timer is (re-)started 3 times: in steps 4, = 6, and 7.

=
Also, as things are defined now, each of these transacti= ons (both UPDATES and the INVITE) can change refresher role and session exp= ires interval. Each of those changes takes effect when final success respon= se is either sent or relieved in steps 4, 6, and 7.

Regards,=C2=A0<= /span>
<= div class=3D"gmail_signature">_____________
Roman Shpount
=C2=A0
--001a1145b8fe1ee63f0568a3efa6-- From nobody Sat Mar 31 08:32:43 2018 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 9024D12D880 for ; Sat, 31 Mar 2018 08:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 0trKrb8vwAR9 for ; Sat, 31 Mar 2018 08:32:40 -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 E440712D881 for ; Sat, 31 Mar 2018 08:32:39 -0700 (PDT) X-AuditID: 12074411-c85ff70000002b0e-e5-5abfaa16ac72 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 AA.51.11022.61AAFBA5; Sat, 31 Mar 2018 11:32:38 -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 w2VFWann013413 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 31 Mar 2018 11:32:37 -0400 To: Roman Shpount Cc: Christer Holmberg , SIPCORE References: <949dba9e-33b7-66b9-1b16-d25902f65367@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B72E06C39@ESESSMB102.ericsson.se> <7594FB04B1934943A5C02806D1A2204B72E37EC9@ESESSMB109.ericsson.se> <9d3fd31a-af1b-3328-23e6-05c11e7978f0@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B72E38364@ESESSMB109.ericsson.se> <336c062b-9d08-d62d-7740-e550015555bd@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B72E3D2D7@ESESSMB109.ericsson.se> From: Paul Kyzivat Message-ID: <7a1d0005-4deb-afaf-3cce-d96d998e4702@alum.mit.edu> Date: Sat, 31 Mar 2018 11:32:36 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.6.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+NgFprKKsWRmVeSWpSXmKPExsUixO6iqCu2an+UwZHXvBYXZh5mtJhxYSqz xdcfm9gcmD1+fb3K5rFkyU8mj1tTCgKYo7hsUlJzMstSi/TtErgyLu6/yVTwVLDiW/Mm5gbG C7xdjJwcEgImEudXvGXqYuTiEBLYwSRxtvMzK4TzkEmidfkRVpAqYQENif1rf7KB2CICqhJ/ v09mArGZBaIlWv9/ZYNoeMAm0XCsCayITUBLYs6h/ywgNq+AvcSuB7vBGliAmt99Owk2VFQg TeJS81ZmiBpBiZMzn4DVcwoESkyYfwNqgZnEvM0PmSFscYlbT+ZDxeUlmrfOZp7AKDALSfss JC2zkLTMQtKygJFlFaNcYk5prm5uYmZOcWqybnFyYl5eapGuqV5uZoleakrpJkZIWAvuYJxx Uu4QowAHoxIPL0P8vigh1sSy4srcQ4ySHExKorx5bUAhvqT8lMqMxOKM+KLSnNTiQ4wSHMxK IrxiSfujhHhTEiurUovyYVLSHCxK4rzMJnujhATSE0tSs1NTC1KLYLIyHBxKErz6K4EaBYtS 01Mr0jJzShDSTBycIMN5gIYfWwEyvLggMbc4Mx0if4rRmGPK8/4eZo5PD6f2MAux5OXnpUqJ 81aAjBMAKc0ozYObBktNrxjFgZ4T5l0DMpAHmNbg5r0CWsUEtEqkZg/IqpJEhJRUA+OK4Ff9 lw1/Tum6sG9eV/jhwDX8yc9XaNt/VuzgOel1Kn25R4z45VhZhZnJa5q5dxXJeu9p7zzu6r9z WfaDDJXTffMKp5Qsdv3OEtg6g/HVs+87M+L7M+eeqr3OwtY08dCdU+me4q++P9gZ/DUqc3PZ fp1zWVI7Vy4WNxfgyrA1iTd9v1rH4YESS3FGoqEWc1FxIgAFZuIwKAMAAA== Archived-At: Subject: Re: [sipcore] session-timer fix 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, 31 Mar 2018 15:32:42 -0000 See below. On 3/30/18 12:43 PM, Roman Shpount wrote: > On Fri, Mar 30, 2018 at 12:34 PM, Paul Kyzivat > wrote: > > On 3/30/18 8:19 AM, Christer Holmberg wrote: > > I think the negotiation takes place when success response is > sent or received. UPDATE within INVITE transaction are two > different S-E negotiations. > > > I agree. I don't think a s-e negotiation should span multiple > SIP transactions. That would complicate things even further, IMO... > > > I don't understand what you mean here. If you offer s-e in invite, > and then send an update (which is another transaction) with s-e, > then ISTM you necessarily have an s-e negotiation spanning multiple > sip transactions. > > > I think having multiple transaction going on at the same time means > multiple S-T negotiations. Each negotiation takes effect when final > success response for this transaction is sent. > > For instance here: > > 1)  UA->AS: INVITE/supported:timer > 2)  AS->UA: 183(INVITE) > 3)  UA->AS: UPDATE/SE:uac > 4)  AS-> UA: 200(UPDATE)/SE:uac > 5)  UA->AS: UPDATE/SE:uac > 6)  AS-> UA: 200(UPDATE)/SE:uac > 7)  AS-> UA : 200(INVITE) /SE:uac > > There are 3 S-T negotiations: 2 for UPDATE transactions and 1 for > INVITE. Session timer is (re-)started 3 times: in steps 4, 6, and 7. > > Also, as things are defined now, each of these transactions (both > UPDATES and the INVITE) can change refresher role and session expires > interval. Each of those changes takes effect when final success response > is either sent or relieved in steps 4, 6, and 7. I'll grant you that this definition is unambiguous. But it seems nonsensical in practice. It means that the s-t negotiated by an UPDATE within an INVITE will never extend beyond the end of the invite transaction. This is true even if the INVITE did not include s-e, because in that case the end of the invite transaction will turn off the s-t. A problem here is that 4028 provided no way to do an invite or update that leaves the s-t state untouched. If we had that then it would make all of this simpler. Thanks, Paul From nobody Sat Mar 31 12:04:35 2018 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 F0160126C2F for ; Sat, 31 Mar 2018 12:04:33 -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 U_rKBmiGdLii for ; Sat, 31 Mar 2018 12:04:32 -0700 (PDT) Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::22e]) (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 2A27B1200A0 for ; Sat, 31 Mar 2018 12:04:31 -0700 (PDT) Received: by mail-pg0-x22e.google.com with SMTP id b9so6963328pgf.6 for ; Sat, 31 Mar 2018 12:04:31 -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=HxGn+5Xq+TbBgiskiDBK1sejGNNd+KhcmwZgDF2x7v4=; b=mHHJdlUdpsSyJh7ZQrmzX9CtmpUYCaYHa1vGCFrb+jOwlwZgrXjB9oWSIYPlmjXIAg 6K00wbcktKk3mXP78ypRyLkUS7ff4TdXd/WsJ+nURNbtFY6/znP6jBvlh2kRE+fam0Fy A+tdQ2if9sJcyHB++6RcyKA5vUI6bBz7c8bvdmRdXrGrDUrWbdSek5WXadwivknoxsb5 GbA3Q8aRB/h2OdYXd0Q6wT8yfr4hTG9Ai50irPpCgWq7HCNOkltHHleiAAMmEKfqWjO0 tr5yKOUPrLwsrk6s/RPixOFJTJ2LQgfjb4+OcM2wrNlGZ5OoI/4ZIWTQQVKuLYr5d+at GByw== 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=HxGn+5Xq+TbBgiskiDBK1sejGNNd+KhcmwZgDF2x7v4=; b=r7MPc87jU0zt+QaOvbmq4Mu1eiOM+KlXlevXmujiqTM1dxgDhtgtpcbdY9HQKcDp7Y 6MbkTsse/frbvFA3bnF42PqEKiN6krSpqY06X8oUFRF1uvTk0rk6vRfLhT1Oe0UwoJ1x 7N6oZVeu/6G/R7x0bCUEMvcaWo6MXhX2gURXapUVPypZXWFSKWAQtGWaNRz6H4DBlE5l S7t/ELrH7raBf/UGn1zSvJdP0caAHSq9u2dz1E/kD2Mp8hHVTR6FDTF/S8U+aHdPEDc3 38BDCnnf+ZbRvHxqvNGmctqTnYFYOhrbfvhZ9QILaUyJIrmursaJh8wR2V8iNlozKGrU dXew== X-Gm-Message-State: AElRT7G8G4HsncT9GJkf74uStwdbDe+hSrcB3AfkrLYXLdGa7O0G+q9x nNIDaFwqpNCdgoQzxDl08JzHNwsi X-Google-Smtp-Source: AIpwx48zY6W86X1bqYwdjMt+IzzSmsZ/FRAHcwzi8JuY+XaFvrOvurTFwT/KclAPSpIQaxQQWDgQsg== X-Received: by 10.99.96.210 with SMTP id u201mr2531332pgb.124.1522523071408; Sat, 31 Mar 2018 12:04:31 -0700 (PDT) Received: from mail-pf0-f171.google.com (mail-pf0-f171.google.com. [209.85.192.171]) by smtp.gmail.com with ESMTPSA id z78sm22246062pfd.23.2018.03.31.12.04.29 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 31 Mar 2018 12:04:30 -0700 (PDT) Received: by mail-pf0-f171.google.com with SMTP id j2so7416131pff.10 for ; Sat, 31 Mar 2018 12:04:29 -0700 (PDT) X-Received: by 2002:a17:902:8548:: with SMTP id d8-v6mr3973548plo.241.1522523069790; Sat, 31 Mar 2018 12:04:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.241.132 with HTTP; Sat, 31 Mar 2018 12:04:29 -0700 (PDT) In-Reply-To: <7a1d0005-4deb-afaf-3cce-d96d998e4702@alum.mit.edu> References: <949dba9e-33b7-66b9-1b16-d25902f65367@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B72E06C39@ESESSMB102.ericsson.se> <7594FB04B1934943A5C02806D1A2204B72E37EC9@ESESSMB109.ericsson.se> <9d3fd31a-af1b-3328-23e6-05c11e7978f0@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B72E38364@ESESSMB109.ericsson.se> <336c062b-9d08-d62d-7740-e550015555bd@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B72E3D2D7@ESESSMB109.ericsson.se> <7a1d0005-4deb-afaf-3cce-d96d998e4702@alum.mit.edu> From: Roman Shpount Date: Sat, 31 Mar 2018 15:04:29 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Paul Kyzivat Cc: Christer Holmberg , SIPCORE Content-Type: multipart/alternative; boundary="000000000000bcc11f0568ba06ed" Archived-At: Subject: Re: [sipcore] session-timer fix 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, 31 Mar 2018 19:04:34 -0000 --000000000000bcc11f0568ba06ed Content-Type: text/plain; charset="UTF-8" On Sat, Mar 31, 2018 at 11:32 AM, Paul Kyzivat wrote: > I'll grant you that this definition is unambiguous. But it seems > nonsensical in practice. It means that the s-t negotiated by an UPDATE > within an INVITE will never extend beyond the end of the invite > transaction. This is true even if the INVITE did not include s-e, because > in that case the end of the invite transaction will turn off the s-t. > I think there is a slight point of confusion here. Normally initial INVITE sent by UA does not include S-E. This INVITE includes Supported: timer and potentially Min-SE. S-E header is added by either proxy or answering UA. It is the INVITE success response which results in S-T negotiation. The only way for an offering agent to turn off S-T is to sent an INVITE or UPDATE without S-E and Supported: timer. The situation I am describing here is a bit extreme but not nonsensical. There are existing UA that can send the initial INVITE and then send an UPDATE during this transaction to negotiate S-T. The purpose of the UPDATE transactions is to negotiate S-T (refresher and expires) early, before INVITE transaction was completed, similar to early media. Well behaving UA should simply send the current S-T state (refresher and expires), in subsequent transactions embedded in the INVITE transaction or in INVITE transaction final success response. This will initiate a timer re-start but, I would say, this is within the spirit of session timer, since UA and proxies got a recent message indicating that dialog is still active and timer can continue. > A problem here is that 4028 provided no way to do an invite or update that > leaves the s-t state untouched. If we had that then it would make all of > this simpler. > I fully agree here. Unfortunately, since there is no way to send invite or updates without changing s-t state untouched, the next best thing is to recommend that in case s-t state should not be changed, INVITE or UPDATE requests and success responses SHOULD include currently negotiated refresher and expires. Regards. _____________ Roman Shpount --000000000000bcc11f0568ba06ed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Mar 31, 2018 at 11:32 AM, P= aul Kyzivat <pkyzivat@alum.mit.edu> wrote:
I'll grant = you that this definition is unambiguous. But it seems nonsensical in practi= ce. It means that the s-t negotiated by an UPDATE within an INVITE will nev= er extend beyond the end of the invite transaction. This is true even if th= e INVITE did not include s-e, because in that case the end of the invite tr= ansaction will turn off the s-t.

I thin= k there is a slight point of confusion here. Normally initial INVITE sent b= y UA does not include S-E. This INVITE includes Supported: timer and potent= ially Min-SE. S-E header is added by either proxy or answering UA. It is th= e INVITE success response which results in S-T negotiation. The only way fo= r an offering agent to turn off S-T is to sent an INVITE or UPDATE without = S-E and Supported: timer.

The situation I am descr= ibing here is a bit extreme but not nonsensical. There are existing UA that= can send the initial INVITE and then send an UPDATE during this transactio= n to negotiate S-T. The purpose of the UPDATE transactions is to negotiate = S-T (refresher and expires) early, before INVITE transaction was completed,= similar to early media. Well behaving UA should simply send the current S-= T state (refresher and expires), in subsequent tr= ansactions embedded in the INVITE transaction or in INVITE transaction fina= l success response. This will initiate a timer re-start but, I would say, t= his is within the spirit of session timer, since UA and proxies got a recen= t message indicating that dialog is still active and timer can continue.
=C2=A0
A problem here is= that 4028 provided no way to do an invite or update that leaves the s-t st= ate untouched. If we had that then it would make all of this simpler.

I fully agree here. Unfortunately, since the= re is no way to send invite or updates without changing s-t state untouched= , the next best thing is to recommend that in case s-t state should not be = changed, INVITE or UPDATE requests and success responses SHOULD include cur= rently negotiated refresher and expires.

Regards.<= /div>
<= div class=3D"gmail_signature">_____________
Roman Shpount
=C2=A0
--000000000000bcc11f0568ba06ed-- From nobody Sat Mar 31 15:02:58 2018 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 B34C2126B6E for ; Sat, 31 Mar 2018 15:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 WXtNd8RDUkXd for ; Sat, 31 Mar 2018 15:02:56 -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 1BD03120725 for ; Sat, 31 Mar 2018 15:02:55 -0700 (PDT) X-AuditID: 12074413-153ff70000000195-53-5ac0058e3e09 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 E9.18.00405.E8500CA5; Sat, 31 Mar 2018 18:02:54 -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 w2VM2qSO001576 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 31 Mar 2018 18:02:53 -0400 To: Roman Shpount Cc: Christer Holmberg , SIPCORE References: <949dba9e-33b7-66b9-1b16-d25902f65367@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B72E06C39@ESESSMB102.ericsson.se> <7594FB04B1934943A5C02806D1A2204B72E37EC9@ESESSMB109.ericsson.se> <9d3fd31a-af1b-3328-23e6-05c11e7978f0@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B72E38364@ESESSMB109.ericsson.se> <336c062b-9d08-d62d-7740-e550015555bd@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B72E3D2D7@ESESSMB109.ericsson.se> <7a1d0005-4deb-afaf-3cce-d96d998e4702@alum.mit.edu> From: Paul Kyzivat Message-ID: <7815f93a-c7cc-5b31-8395-ff9cf3d31303@alum.mit.edu> Date: Sat, 31 Mar 2018 18:02:52 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFKsWRmVeSWpSXmKPExsUixO6iqNvHeiDK4PZ9aYsLMw8zWsy4MJXZ 4uuPTWwOzB6/vl5l81iy5CeTx60pBQHMUVw2Kak5mWWpRfp2CVwZVz+eZyzYKF2x8fMD5gbG LaJdjJwcEgImEgt3TWLrYuTiEBLYwSRx8EwrE4TzkEnizcrdrCBVwgIaEvvX/mQDsUUEVCX+ fp/MBGIzC0RLtP7/CtV9l11iz6mz7CAJNgEtiTmH/rN0MXJw8ArYS1zeKg0SZgHq/bF5GViJ qECaxKXmrcwgNq+AoMTJmU9YQGxOgUCJf13/oeabSczb/JAZwhaXuPVkPlRcXmL72znMExgF ZiFpn4WkZRaSlllIWhYwsqxilEvMKc3VzU3MzClOTdYtTk7My0st0jXXy80s0UtNKd3ECAlq 4R2Mu07KHWIU4GBU4uHluLs/Sog1say4MvcQoyQHk5Iob17bvighvqT8lMqMxOKM+KLSnNTi Q4wSHMxKIrynGA9ECfGmJFZWpRblw6SkOViUxHmZTfZGCQmkJ5akZqemFqQWwWRlODiUJHjP sgA1ChalpqdWpGXmlCCkmTg4QYbzAA2fB1LDW1yQmFucmQ6RP8VoyTHleX8PM0fH+ylA8tjl aT3MQix5+XmpUuK8s0EaBEAaMkrz4GbCktQrRnGgF4V5bUGqeIAJDm7qK6CFTEALRWr2gCws SURISTUwuibXiKy5/2fzHK9k/v+HYn6yTlocvSljIkNmd0aAeo3t7EUFws++hnvGra9gXBpS 8v4Yo4DZhp3FJ1YWFP//MPvouvvSE758+VFwxW/G4a7v1soRZ0KXvzmo/3vhJLdkA78Kwd5N 2u/mqD87LStx+lGPwWrDlSpnixPq/dWaOhwnd/nV8yn2K7EUZyQaajEXFScCAJyIK8stAwAA Archived-At: Subject: Re: [sipcore] session-timer fix 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, 31 Mar 2018 22:02:58 -0000 On 3/31/18 3:04 PM, Roman Shpount wrote: > On Sat, Mar 31, 2018 at 11:32 AM, Paul Kyzivat > wrote: > > I'll grant you that this definition is unambiguous. But it seems > nonsensical in practice. It means that the s-t negotiated by an > UPDATE within an INVITE will never extend beyond the end of the > invite transaction. This is true even if the INVITE did not include > s-e, because in that case the end of the invite transaction will > turn off the s-t. > > > I think there is a slight point of confusion here. Normally initial > INVITE sent by UA does not include S-E. This INVITE includes Supported: > timer and potentially Min-SE. S-E header is added by either proxy or > answering UA. It is the INVITE success response which results in S-T > negotiation. The only way for an offering agent to turn off S-T is to > sent an INVITE or UPDATE without S-E and Supported: timer. OK, sorry, I agree. The sender of an INVITE can't both indicate support for timer and force it not to be used. > The situation I am describing here is a bit extreme but not nonsensical. > There are existing UA that can send the initial INVITE and then send an > UPDATE during this transaction to negotiate S-T. The purpose of the > UPDATE transactions is to negotiate S-T (refresher and expires) early, > before INVITE transaction was completed, similar to early media. Well > behaving UA should simply send the current S-T state (refresher and > expires), in subsequent transactions embedded in the INVITE transaction > or in INVITE transaction final success response. This will initiate a > timer re-start but, I would say, this is within the spirit of session > timer, since UA and proxies got a recent message indicating that dialog > is still active and timer can continue. Then IIUC you are saying that if a s-t has been negotiated by a UPDATE within an INVITE then the UAS for the INVITE SHOULD send the same values in the 200 INVITE as were in the last 200 UPDATE. (If there had been no Supported:timer in the INVITE then I guess we presume that there is to be no s-t negotiation in UPDATEs either.) I suspect there are cases possible here, where a s-e expiration value that is compatible with the INVITE is incompatible with the UPDATE. These would be pathological, but ought to be investigated before we are done. While writing this response I realized another flaw in 4028. The rules for generating subsequent refreshes seem to assume that once it has been determined that both ends support s-t that this will continue to be true. For instance this must be so when the refresh request says refresher=uas. But in the presence of a B2BUA that passes s-t through rather than managing each side separately, after a 3pcc transfer this may not be true. Thanks, Paul > A problem here is that 4028 provided no way to do an invite or > update that leaves the s-t state untouched. If we had that then it > would make all of this simpler. > > > I fully agree here. Unfortunately, since there is no way to send invite > or updates without changing s-t state untouched, the next best thing is > to recommend that in case s-t state should not be changed, INVITE or > UPDATE requests and success responses SHOULD include currently > negotiated refresher and expires. > > Regards. > _____________ > Roman Shpount >