From oej@edvina.net Thu May 2 00:31:58 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 174EB21F890F for ; Thu, 2 May 2013 00:31:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.605 X-Spam-Level: X-Spam-Status: No, score=-1.605 tagged_above=-999 required=5 tests=[AWL=-0.795, BAYES_05=-1.11, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9xWMMHuQMTLA for ; Thu, 2 May 2013 00:31:57 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 4D27521F86D3 for ; Thu, 2 May 2013 00:31:53 -0700 (PDT) Received: from [192.168.40.5] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id E269C93C1AF; Thu, 2 May 2013 07:31:50 +0000 (UTC) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: "Olle E. Johansson" In-Reply-To: Date: Thu, 2 May 2013 09:31:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <339625C1-F16E-429F-BA62-066F6F6B3B51@edvina.net> <6360A039-E87A-4872-A480-587FC9F84D2F@edvina.net> To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1503) Cc: "dispatch@ietf.org list" Subject: Re: [dispatch] SIP outbound and in-dialog requests X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 07:31:58 -0000 30 apr 2013 kl. 11:41 skrev I=F1aki Baz Castillo : > 2013/4/30 Olle E. Johansson : >> Is this the only response that is out there? To break RFC 3261 and = apply a >> route change to an existing dialog? >=20 > Is not cool enough? :) >=20 > Right, RFC 5627 should say "something" about it. >=20 The question is what to do here. And how much the draft for SIP over WebSockets rely on Outbound. Do we = need to solve this issue before moving ahead with that draft? /O= From jmillan@aliax.net Thu May 2 03:02:42 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65AC321F8605 for ; Thu, 2 May 2013 03:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K6Vkq2odYPjD for ; Thu, 2 May 2013 03:02:41 -0700 (PDT) Received: from mail-vb0-x230.google.com (mail-vb0-x230.google.com [IPv6:2607:f8b0:400c:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id 6F24321F854D for ; Thu, 2 May 2013 03:02:41 -0700 (PDT) Received: by mail-vb0-f48.google.com with SMTP id q16so297248vbe.21 for ; Thu, 02 May 2013 03:02:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=526l7xjuxPQWISXc6wVCZ4Tm00yTqtnq5MY19K4wiBU=; b=mzTqmdrC0rDZVZ7FlH3EMHyKrqTUWfmKGwYI5IdirNrXMO/Xu+s0O6UCvywjVf6C29 IP0xiLbbdbwY4ts/BR04MBR+EsrtK1viaTTDWBRvhALqpz1lKnFJFLIoincxaHGldPoQ xrsF/9L0nyp7M52xvj6QZRn4ekccDoAH3RXHRi6dlzhZvwOzE0EzSbX7fgA76q5hC5JE X3B5TbJYJbtblmfB93aAZq5xy2nRd1yh0HpJoTFxLtcpSSBMPR3pANljwy8RJBBfh4C2 eUZ43cfe4U+KYss5O2DL1taBaothIrh46dVfjqVsJa/YMHRIwIofOeJyaU+l4ppATc+1 OQng== MIME-Version: 1.0 X-Received: by 10.220.159.130 with SMTP id j2mr1889668vcx.57.1367488960746; Thu, 02 May 2013 03:02:40 -0700 (PDT) Received: by 10.220.110.14 with HTTP; Thu, 2 May 2013 03:02:40 -0700 (PDT) In-Reply-To: References: <339625C1-F16E-429F-BA62-066F6F6B3B51@edvina.net> <6360A039-E87A-4872-A480-587FC9F84D2F@edvina.net> Date: Thu, 2 May 2013 12:02:40 +0200 Message-ID: From: =?UTF-8?B?Sm9zw6kgTHVpcyBNaWxsw6Fu?= To: "Olle E. Johansson" Content-Type: multipart/alternative; boundary=047d7b672666bd67c504dbb9557d X-Gm-Message-State: ALoCoQkptbMM9bvi2nNUlTMLNl8m97W3DFvdsEn9dGdGsaBmXUN7Gn9T48SrqArUYiVlMAK5Jd0G Cc: "dispatch@ietf.org list" Subject: Re: [dispatch] SIP outbound and in-dialog requests X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 10:02:42 -0000 --047d7b672666bd67c504dbb9557d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi all, 2013/5/2 Olle E. Johansson > > 30 apr 2013 kl. 11:41 skrev I=C3=B1aki Baz Castillo : > > > 2013/4/30 Olle E. Johansson : > >> Is this the only response that is out there? To break RFC 3261 and > apply a > >> route change to an existing dialog? > > > > Is not cool enough? :) > > > > Right, RFC 5627 should say "something" about it. > > > > The question is what to do here. > > And how much the draft for SIP over WebSockets rely on Outbound. Do we > need to solve this issue before moving ahead with that draft? > Extracted from RFC 5626, chapter 7: ``` The proxy uses the next-hop target of the message and the value of any stored Path header field vector in the registration binding to decide how to forward and populate the Route header in the request. If the proxy is co-located with the registrar and stored information about the flow to the UA that created the binding, then the proxy MUST send the request over the same 'logical flow' saved with the binding, since that flow is known to deliver data to the specific target UA instance's network flow that was saved with the binding. ``` Which means that a newly created registration binding (following the procedures defined in chapter 4.4) will contain the PATH route with the new and valid flow token, and such 'logical flow' MUST be used instead of that in the Route header(s). Hence, the Route header(s) pointing to the old and deprecated 'logical flow' is replaced with the new one gathered from the registration after the flow failure. I don't feel like this could affect in any way the use of Outbound for any transport. Regards. > > /O > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --=20 Jos=C3=A9 Luis Mill=C3=A1n --047d7b672666bd67c504dbb9557d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,


2013/5/2 Olle E. Johansson <oej@edvina.net>

30 apr 2013 kl. 11:41 skrev I=C3=B1aki Baz Castillo <ibc@aliax.net>:

> 2013/4/30 Olle E. Johansson <oej@= edvina.net>:
>> Is this the only response that is out there? To break RFC 3261 and= apply a
>> route change to an existing dialog?
>
> Is not cool enough? :)
>
> Right, RFC 5627 should say "something" about it.
>

The question is what to do here.

And how much the draft for SIP over WebSockets rely on Outbound. Do we need= to solve this issue before moving ahead with that draft?
<= div>
Extracted from RFC 5626, chapter 7:

```
The prox=
y uses the next-hop target of the message and the value of
   any stored Path header field vector in the registration binding to
   decide how to forward and populate the Route header in the request.
   If the proxy is co-located with the registrar and stored information
   about the flow to the UA that created the binding, then the proxy
   MUST send the request over the same 'logical flow' saved with th=
e
   binding, since that flow is known to deliver data to the specific
   target UA instance's network flow that was saved with the binding.

```=C2=A0

Which me= ans that a newly created registration binding (following the procedures def= ined in chapter 4.4) will contain the PATH route with the new and valid flo= w token, and such 'logical flow' MUST be used instead of that in th= e Route header(s). Hence, the Route header(s) pointing to the old and depre= cated 'logical flow' is replaced with the new one gathered from the= registration after the flow failure.

I don't feel like this could affect in any wa= y the use of Outbound for any transport.=C2=A0

Regards.
=C2=A0

/O
___________________________= ____________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch



--
= Jos=C3=A9 Luis Mill=C3=A1n --047d7b672666bd67c504dbb9557d-- From worley@shell01.TheWorld.com Thu May 2 11:42:11 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50C2821F91A0 for ; Thu, 2 May 2013 11:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.92 X-Spam-Level: X-Spam-Status: No, score=-2.92 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tYciVelwkHZT for ; Thu, 2 May 2013 11:42:05 -0700 (PDT) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 9755321F91CE for ; Thu, 2 May 2013 11:42:02 -0700 (PDT) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r42IfQW4005929; Thu, 2 May 2013 14:41:29 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r42IfQij3991701; Thu, 2 May 2013 14:41:26 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r42IfPm53999515; Thu, 2 May 2013 14:41:25 -0400 (EDT) Date: Thu, 2 May 2013 14:41:25 -0400 (EDT) Message-Id: <201305021841.r42IfPm53999515@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: "Olle E. Johansson" In-reply-to: <6360A039-E87A-4872-A480-587FC9F84D2F@edvina.net> (oej@edvina.net) References: <339625C1-F16E-429F-BA62-066F6F6B3B51@edvina.net> <6360A039-E87A-4872-A480-587FC9F84D2F@edvina.net> Cc: dispatch@ietf.org Subject: Re: [dispatch] SIP outbound and in-dialog requests X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 18:42:11 -0000 > From: "Olle E. Johansson" > > Is this the only response that is out there? To break RFC 3261 and > apply a route change to an existing dialog? > Or follow RFC 3261 and let the dialog fail? I've worked on an implementation of SIP Outbound (that wasn't completed), and my memory is that the problem you describe is not solved in the RFCs. Dale From worley@shell01.TheWorld.com Thu May 2 11:42:32 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFF3221F9298 for ; Thu, 2 May 2013 11:42:32 -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=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mzwu2PAqE1iV for ; Thu, 2 May 2013 11:42:27 -0700 (PDT) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id E620121F91D9 for ; Thu, 2 May 2013 11:42:12 -0700 (PDT) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r42Ig3RR027228; Thu, 2 May 2013 14:42:05 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r42Ig2p73998930; Thu, 2 May 2013 14:42:02 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r42Ig2DO3979809; Thu, 2 May 2013 14:42:02 -0400 (EDT) Date: Thu, 2 May 2013 14:42:02 -0400 (EDT) Message-Id: <201305021842.r42Ig2DO3979809@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Jose Luis Millan In-reply-to: (jmillan@aliax.net) References: <339625C1-F16E-429F-BA62-066F6F6B3B51@edvina.net> <6360A039-E87A-4872-A480-587FC9F84D2F@edvina.net> Cc: dispatch@ietf.org Subject: Re: [dispatch] SIP outbound and in-dialog requests X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 18:42:32 -0000 > From: JosC) Luis MillC!n > > Extracted from RFC 5626, chapter 7: > > ``` > > The proxy uses the next-hop target of the message and the value of > any stored Path header field vector in the registration binding to > decide how to forward and populate the Route header in the request. > If the proxy is co-located with the registrar and stored information > about the flow to the UA that created the binding, then the proxy > MUST send the request over the same 'logical flow' saved with the > binding, since that flow is known to deliver data to the specific > target UA instance's network flow that was saved with the binding. It appears to me that this procedure is to be carried out only in the circumstances described in the paragraph at the beginning of section 7: When a proxy uses the location service to look up a registration binding and then proxies a request to a particular contact, it selects a contact to use normally, with a few additional rules: That is, it only applies when the proxy is looking up a registration binding == the next-hop address is the AOR. Dale From ibc@aliax.net Thu May 2 11:49:37 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D79621F8F32 for ; Thu, 2 May 2013 11:49:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.077 X-Spam-Level: X-Spam-Status: No, score=-2.077 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_51=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IrWunf+FwFp5 for ; Thu, 2 May 2013 11:49:33 -0700 (PDT) Received: from mail-vc0-f170.google.com (mail-vc0-f170.google.com [209.85.220.170]) by ietfa.amsl.com (Postfix) with ESMTP id DE14821F8F2C for ; Thu, 2 May 2013 11:49:32 -0700 (PDT) Received: by mail-vc0-f170.google.com with SMTP id gf12so813846vcb.29 for ; Thu, 02 May 2013 11:49:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=m1MHvZRG4fZnuQARTRNCqyUcZJrkNc8l2NVj54krGFM=; b=cIwdo5Aj+yJQbECb4U+92EjY6hTnIvkcjYz3usFGMqLbrUsUDUVp0vgwqmevUJUB3y 4Dl+TrE8QRX/pMSNOmX2Z7mb68QWYit2qiVlhqIkRjdKZYFCk36qt2nlJBwu2TZzWLjm UUqv0ZUvKWm7GHYNu4yXr9hQUJES1ZkC6dU6ltAyr/NOgMkwL+L4TsVLKYM8rWtlPLQw vr+8LH6/DxEOuzNfbFkSeadv24nafXGAjakxLQAkx8eMjP3IBRlAoEuDQzv64oVzl59e 17iNn1hQGXqPqgSBz7WRDiDDFVIb4vTfSpJAFa+W0Z54k4+g8XUg0UTzuUtsTMMxXYgY 2ymw== MIME-Version: 1.0 X-Received: by 10.220.68.13 with SMTP id t13mr692437vci.24.1367520571965; Thu, 02 May 2013 11:49:31 -0700 (PDT) Received: by 10.58.236.70 with HTTP; Thu, 2 May 2013 11:49:31 -0700 (PDT) Received: by 10.58.236.70 with HTTP; Thu, 2 May 2013 11:49:31 -0700 (PDT) In-Reply-To: <201305021842.r42Ig2DO3979809@shell01.TheWorld.com> References: <339625C1-F16E-429F-BA62-066F6F6B3B51@edvina.net> <6360A039-E87A-4872-A480-587FC9F84D2F@edvina.net> <201305021842.r42Ig2DO3979809@shell01.TheWorld.com> Date: Thu, 2 May 2013 20:49:31 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: "Dale R. Worley" Content-Type: multipart/alternative; boundary=047d7b343d34ea584a04dbc0b13d X-Gm-Message-State: ALoCoQk8xz09V4Tt3d+jDLB1DZKkoyGirkxVNEjGUCijqVoLbbU2yvV4bOPxAZXWM0k+7/iWOH+z Cc: dispatch@ietf.org Subject: Re: [dispatch] SIP outbound and in-dialog requests X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 18:49:37 -0000 --047d7b343d34ea584a04dbc0b13d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable When GRUU is used in the INVITE/200 Contact, the proxy+registrar should also perform GRUU based registration lookup so IMHO the procedure below also applies, and it means thar the route set could be changed during a dialog if the peer re-registered again after a connection break (so its connection gets a new Outboud flow token id). This is the issue being discussed here: the route set is changed since within the dialog the registrar gets the new Path containing a new flow token and thus the Route it adds is different than the original route set. -- I=C3=B1aki Baz Castillo El 02/05/2013 20:42, "Dale R. Worley" escribi=C3=B3: > > From: JosC) Luis MillC!n > > > > Extracted from RFC 5626, chapter 7: > > > > ``` > > > > The proxy uses the next-hop target of the message and the value of > > any stored Path header field vector in the registration binding to > > decide how to forward and populate the Route header in the request. > > If the proxy is co-located with the registrar and stored information > > about the flow to the UA that created the binding, then the proxy > > MUST send the request over the same 'logical flow' saved with the > > binding, since that flow is known to deliver data to the specific > > target UA instance's network flow that was saved with the binding. > > It appears to me that this procedure is to be carried out only in the > circumstances described in the paragraph at the beginning of section > 7: > > When a proxy uses the location service to look up a registration > binding and then proxies a request to a particular contact, it > selects a contact to use normally, with a few additional rules: > > That is, it only applies when the proxy is looking up a registration > binding =3D=3D the next-hop address is the AOR. > > Dale > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --047d7b343d34ea584a04dbc0b13d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

When GRUU is used in the INVITE/200 Contact, the proxy+regis= trar should also perform GRUU based registration lookup so IMHO the procedu= re below also applies, and it means thar the route set could be changed dur= ing a dialog if the peer re-registered again after a connection break (so i= ts connection gets a new Outboud flow token id). This is the issue being di= scussed here: the route set is changed since within the dialog the registra= r gets the new Path containing a new flow token and thus the Route it adds = is different than the original route set.

--
I=C3=B1aki Baz Castillo
<ibc@aliax.net>

El 02/05/2013 20:42, "Dale R. Worley" = <worley@ariadne.com> escrib= i=C3=B3:
> From: JosC) Luis MillC!n <jmil= lan@aliax.net>
>
> Extracted from RFC 5626, chapter 7:
>
> ```
>
> =C2=A0 =C2=A0The proxy uses the next-hop target of the message and the= value of
> =C2=A0 =C2=A0any stored Path header field vector in the registration b= inding to
> =C2=A0 =C2=A0decide how to forward and populate the Route header in th= e request.
> =C2=A0 =C2=A0If the proxy is co-located with the registrar and stored = information
> =C2=A0 =C2=A0about the flow to the UA that created the binding, then t= he proxy
> =C2=A0 =C2=A0MUST send the request over the same 'logical flow'= ; saved with the
> =C2=A0 =C2=A0binding, since that flow is known to deliver data to the = specific
> =C2=A0 =C2=A0target UA instance's network flow that was saved with= the binding.

It appears to me that this procedure is to be carried out only in the
circumstances described in the paragraph at the beginning of section
7:

=C2=A0 =C2=A0When a proxy uses the location service to look up a registrati= on
=C2=A0 =C2=A0binding and then proxies a request to a particular contact, it=
=C2=A0 =C2=A0selects a contact to use normally, with a few additional rules= :

That is, it only applies when the proxy is looking up a registration
binding =3D=3D the next-hop address is the AOR.

Dale
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
--047d7b343d34ea584a04dbc0b13d-- From worley@shell01.TheWorld.com Thu May 2 18:16:07 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3F7121F8540 for ; Thu, 2 May 2013 18:16:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.772 X-Spam-Level: X-Spam-Status: No, score=-1.772 tagged_above=-999 required=5 tests=[AWL=-1.058, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619, SARE_OBFU_PART_CIA=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ipS5BYr-DW8 for ; Thu, 2 May 2013 18:16:02 -0700 (PDT) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id 0110421F9003 for ; Thu, 2 May 2013 18:16:01 -0700 (PDT) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r431FSu8025547; Thu, 2 May 2013 21:15:30 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r431FRth4004828; Thu, 2 May 2013 21:15:28 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r431FRoS4006275; Thu, 2 May 2013 21:15:27 -0400 (EDT) Date: Thu, 2 May 2013 21:15:27 -0400 (EDT) Message-Id: <201305030115.r431FRoS4006275@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: IC1aki Baz Castillo In-reply-to: (ibc@aliax.net) References: <339625C1-F16E-429F-BA62-066F6F6B3B51@edvina.net> <6360A039-E87A-4872-A480-587FC9F84D2F@edvina.net> <201305021842.r42Ig2DO3979809@shell01.TheWorld.com> Cc: dispatch@ietf.org Subject: Re: [dispatch] SIP outbound and in-dialog requests X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 01:16:08 -0000 > From: IC1aki Baz Castillo > > When GRUU is used in the INVITE/200 Contact, the proxy+registrar should > also perform GRUU based registration lookup so IMHO the procedure below > also applies, and it means thar the route set could be changed during a > dialog if the peer re-registered again after a connection break (so its > connection gets a new Outboud flow token id). This is the issue being > discussed here: the route set is changed since within the dialog the > registrar gets the new Path containing a new flow token and thus the Route > it adds is different than the original route set. Ah, OK, now I recall. The new flow will be used *if* the UA uses its GRUU as its Contact. Dale From stpeter@stpeter.im Thu May 2 19:06:42 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BED0E21F905B for ; Thu, 2 May 2013 19:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c2lz4HN7tLcg for ; Thu, 2 May 2013 19:06:38 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 3674621F912C for ; Thu, 2 May 2013 19:06:32 -0700 (PDT) Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 987F84001C for ; Thu, 2 May 2013 20:17:52 -0600 (MDT) Message-ID: <51831BA6.2080001@stpeter.im> Date: Thu, 02 May 2013 20:06:30 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "dispatch@ietf.org list" References: <20130503020508.23712.80437.idtracker@ietfa.amsl.com> In-Reply-To: <20130503020508.23712.80437.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5.1 X-Forwarded-Message-Id: <20130503020508.23712.80437.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [dispatch] Fwd: I-D Action: draft-saintandre-sip-xmpp-groupchat-03.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 02:06:42 -0000 FYI, Saul and I have submitted -03 of this interworking I-D... -------- Original Message -------- Subject: I-D Action: draft-saintandre-sip-xmpp-groupchat-03.txt Date: Thu, 02 May 2013 19:05:08 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Groupchat Author(s) : Peter Saint-Andre Salvatore Loreto Saul Ibarra Fabio Forno Filename : draft-saintandre-sip-xmpp-groupchat-03.txt Pages : 28 Date : 2013-05-02 Abstract: This document defines a bidirectional protocol mapping for the exchange of instant messages in the context of a multiparty chat session among users of the Session Initiation Protocol (SIP) and users of the Extensible Messaging and Presence Protocol (XMPP). Specifically, this document defines a mapping between the XMPP Multi- User Chat (MUC) extension and the SIP-based Message Session Relay Protocol (MSRP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-saintandre-sip-xmpp-groupchat There's also a htmlized version available at: http://tools.ietf.org/html/draft-saintandre-sip-xmpp-groupchat-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-saintandre-sip-xmpp-groupchat-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From Markus.Isomaki@nokia.com Fri May 3 04:16:57 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A7A721F95EA for ; Fri, 3 May 2013 04:16:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.391 X-Spam-Level: X-Spam-Status: No, score=-5.391 tagged_above=-999 required=5 tests=[AWL=0.337, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_MLH_Stock1=0.87] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6-8-t4ZaJe3i for ; Fri, 3 May 2013 04:16:51 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 6E8BA21F95E6 for ; Fri, 3 May 2013 04:16:50 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-sa02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r43BGiG8015637 for ; Fri, 3 May 2013 14:16:49 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.61]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 3 May 2013 14:16:46 +0300 Received: from 008-AM1MPN1-042.mgdnok.nokia.com ([169.254.2.144]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.02.0328.011; Fri, 3 May 2013 11:16:46 +0000 From: To: Thread-Topic: New mailing list for the proposed SIP-to-XMPP (STOX) WG technical discussions Thread-Index: Ac5H74STGUKe1UKDQHORqKnsjcd9/w== Date: Fri, 3 May 2013 11:16:45 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None; x-titus-version: 3.5.9.3 x-headerinfofordlp: None x-tituslabs-classificationhash-30: 0Ywc1/TmJmZP14okFmB8GMd8Xehk+cvfBfEd3KpxcUGh/F1G/EtNvyjF+e9tYh2QDr14hifrzQTKlSmwy+r3G+GJ3NFsQjKj4nqcuvVJcJL6Sek9+VNqWSO9nLu+Z/8Ypi0LxIY7MXOB4MyfkCBLNG4ODLvETek9CPvjMUt4i12CqMgJOlcP3vvatgsjfZzk4yWJFMrBE4dpMLZ0YzZ2s5f7+Ic/BbKdHzkdhOK53Tl6g5OAsyMAIt24VRP7biYbWQxYpzmLmxtOAXciGUe8Qst6jCxYdo147nP8wKgPYt4= x-originating-ip: [172.21.81.160] Content-Type: multipart/alternative; boundary="_000_E44893DD4E290745BB608EB23FDDB76209FD1D23008AM1MPN1042mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 03 May 2013 11:16:46.0582 (UTC) FILETIME=[B2FA3160:01CE47EF] X-Nokia-AV: Clean Subject: [dispatch] New mailing list for the proposed SIP-to-XMPP (STOX) WG technical discussions X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 11:16:57 -0000 --_000_E44893DD4E290745BB608EB23FDDB76209FD1D23008AM1MPN1042mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, The proposed SIP-to-XMPP (STOX) WG is still in the chartering phase, please= see: http://datatracker.ietf.org/wg/stox/charter/ However, there are already various related drafts, like the '-groupchat' (s= ee below) and all the others starting with 'draft-saintandre-sip-xmpp-', th= at people are working on. In order to offload the related technical discuss= ion from DISPATCH list, we have created a dedicated STOX list (stox@ietf.or= g) for that purpose. You can subscribe to it at: https://www.ietf.org/mailman/listinfo/stox So, everyone interested in the SIP-to-XMPP topic, please subscribe to the S= TOX list and use that for the further discussion, such as commenting on the= '-groupchat' draft, from now on. If and when STOX becomes an official RAI = WG, the same list will continue as a WG list. Regards, Markus -----Original Message----- From: dispatch-bounces@ietf.org [mailto:d= ispatch-bounces@ietf.org] On Behalf Of ext Peter Saint-Andre Sent: 03 May, 2013 05:07 To: dispatch@ietf.org list Subject: [dispatch] Fwd: I-D Action: draft-saintandre-sip-xmpp-groupchat-03= .txt FYI, Saul and I have submitted -03 of this interworking I-D... -------- Original Message -------- Subject: I-D Action: draft-saintandre-sip-xmpp-groupchat-03.txt Date: Thu, 02 May 2013 19:05:08 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Interworking between the Session Initiati= on Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Groupchat Author(s) : Peter Saint-Andre Salvatore Loreto Saul Ibarra Fabio Forno Filename : draft-saintandre-sip-xmpp-groupchat-03.tx= t Pages : 28 Date : 2013-05-02 Abstract: This document defines a bidirectional protocol mapping for the exchange of instant messages in the context of a multiparty chat session among users of the Session Initiation Protocol (SIP) and users of the Extensible Messaging and Presence Protocol (XMPP). Specifically, this document defines a mapping between the XMPP Multi- User Chat (MUC) extension and the SIP-based Message Session Relay Protocol (MSRP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-saintandre-sip-xmpp-groupchat There's also a htmlized version available at: http://tools.ietf.org/html/draft-saintandre-sip-xmpp-groupchat-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-saintandre-sip-xmpp-groupchat-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ie= tf.org/ietf/1shadow-sites.txt _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --_000_E44893DD4E290745BB608EB23FDDB76209FD1D23008AM1MPN1042mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

The proposed SIP-to-XMPP (STOX) WG is still in th= e chartering phase, please see:

http://datatracker.ietf.org/wg/stox/charter/

 

However, there are already various related drafts= , like the '-groupchat' (see below) and all the others starting with 'draft= -saintandre-sip-xmpp-', that people are working on. In order to offload the= related technical discussion from DISPATCH list, we have created a dedicated STOX list (stox@ietf.org) for that purpose.

 

You can subscribe to it at:

https://www.ietf.org/mailman/listinfo/stox

 

So, everyone interested in the SIP-to-XMPP topic,= please subscribe to the STOX list and use that for the further discussion,= such as commenting on the '-groupchat' draft, from now on. If and when STO= X becomes an official RAI WG, the same list will continue as a WG list.

 

Regards,

        &= nbsp;       Markus

 

 

-----Original Message-----

From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of ext Peter Saint-Andre=

Sent: 03 May, 2013 05:07

To: dispatch= @ietf.org list

Subject: [dispatch] Fwd: I-D Action: draft-sainta= ndre-sip-xmpp-groupchat-03.txt

 

FYI, Saul and I have submitted -03 of this interw= orking I-D...

 

 

-------- Original Message --------

Subject: I-D Action: draft-saintandre-sip-xmpp-gr= oupchat-03.txt

Date: Thu, 02 May 2013 19:05:08 -0700<= /p>

From: internet-drafts@ietf.org

Reply-To: internet-drafts@ietf.org

To: i-d-= announce@ietf.org

 

 

A New Internet-Draft is available from the on-lin= e Internet-Drafts directories.

 

 

        &= nbsp;       Title    &nbs= p;      : Interworking between the Session Initiat= ion Protocol

(SIP) and the Extensible Messaging and Presence P= rotocol (XMPP): Groupchat

        &= nbsp;       Author(s)    =    : Peter Saint-Andre

        &= nbsp;           &nbs= p;     Salvatore Loreto

        &= nbsp;           &nbs= p;     Saul Ibarra

        &= nbsp;           &nbs= p;     Fabio Forno

        &= nbsp;       Filename    &= nbsp;   : draft-saintandre-sip-xmpp-groupchat-03.txt

        &= nbsp;       Pages    &nbs= p;      : 28

        &= nbsp;       Date     = ;       : 2013-05-02

 

Abstract:

   This document defines a bidirectiona= l protocol mapping for the

   exchange of instant messages in the = context of a multiparty chat

   session among users of the Session I= nitiation Protocol (SIP) and

   users of the Extensible Messaging an= d Presence Protocol (XMPP).

   Specifically, this document defines = a mapping between the XMPP Multi-

   User Chat (MUC) extension and the SI= P-based Message Session Relay

   Protocol (MSRP).

 

 

The IETF datatracker status page for this draft i= s:

https://datatracker.ietf.org/doc/draft-sain= tandre-sip-xmpp-groupchat

 

There's also a htmlized version available at:

http://tools.ietf.org/html/draft-saintandre-si= p-xmpp-groupchat-03

 

A diff from the previous version is available at:=

http://www.ietf.org/rfcdiff?url2=3Ddra= ft-saintandre-sip-xmpp-groupchat-03

 

 

Internet-Drafts are also available by anonymous F= TP at:

f= tp://ftp.ietf.org/internet-drafts/

 

_______________________________________________

I-D-Announce mailing list

I-D-Anno= unce@ietf.org

https://www.ietf.org/mailman/listinfo/i-d-announce

Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

 

 

_______________________________________________

dispatch mailing list

dispatch@iet= f.org

https://www.ietf.org/mailman/listinfo/dispatch

 

 

--_000_E44893DD4E290745BB608EB23FDDB76209FD1D23008AM1MPN1042mg_-- From stpeter@stpeter.im Fri May 3 05:47:23 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 910CF21F9635 for ; Fri, 3 May 2013 05:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.164 X-Spam-Level: X-Spam-Status: No, score=-102.164 tagged_above=-999 required=5 tests=[AWL=-0.435, BAYES_00=-2.599, SARE_MLH_Stock1=0.87, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rayDeU1j1vkt for ; Fri, 3 May 2013 05:47:17 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id A48D521F9634 for ; Fri, 3 May 2013 05:47:17 -0700 (PDT) Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 56B5640010; Fri, 3 May 2013 06:58:39 -0600 (MDT) Message-ID: <5183B1D4.8010600@stpeter.im> Date: Fri, 03 May 2013 06:47:16 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Markus.Isomaki@nokia.com References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org Subject: Re: [dispatch] New mailing list for the proposed SIP-to-XMPP (STOX) WG technical discussions X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 12:47:23 -0000 On 5/3/13 5:16 AM, Markus.Isomaki@nokia.com wrote: > So, everyone interested in the SIP-to-XMPP topic, please subscribe to > the STOX list and use that for the further discussion, such as > commenting on the '-groupchat' draft, from now on. If and when STOX > becomes an official RAI WG, the same list will continue as a WG list. Thanks, Markus. There are a few dispatch@ietf.org email threads still open about these documents, but I still reply to those on the stox@ietf.org list. Peter From prvs=68353fe77e=christer.holmberg@ericsson.com Fri May 3 06:23:07 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B31021F95E5 for ; Fri, 3 May 2013 06:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.022 X-Spam-Level: X-Spam-Status: No, score=-5.022 tagged_above=-999 required=5 tests=[AWL=-1.039, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_PART_CIA=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6NW-qRaaf+S4 for ; Fri, 3 May 2013 06:23:02 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 486AB21F92A5 for ; Fri, 3 May 2013 06:23:00 -0700 (PDT) X-AuditID: c1b4fb2d-b7f536d000006e05-8f-5183ba33e4bb Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id B2.99.28165.33AB3815; Fri, 3 May 2013 15:22:59 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.02.0328.009; Fri, 3 May 2013 15:22:58 +0200 From: Christer Holmberg To: "Dale R. Worley" , IC1aki Baz Castillo Thread-Topic: [dispatch] SIP outbound and in-dialog requests Thread-Index: AQHOR5uxaZW6BfvFUkyNBG2wEi4qB5jzclcw Date: Fri, 3 May 2013 13:22:58 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C36B55D@ESESSMB209.ericsson.se> References: <339625C1-F16E-429F-BA62-066F6F6B3B51@edvina.net> <6360A039-E87A-4872-A480-587FC9F84D2F@edvina.net> <201305021842.r42Ig2DO3979809@shell01.TheWorld.com> <201305030115.r431FRoS4006275@shell01.TheWorld.com> In-Reply-To: <201305030115.r431FRoS4006275@shell01.TheWorld.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrFLMWRmVeSWpSXmKPExsUyM+Jvra7xruZAg7a3khZLJy1gtZi+z8bi 5YkyB2aPcw3v2T0m7//K7LFkyU+mAOYobpukxJKy4Mz0PH27BO6MHbN3sRdc56r4d/M5cwPj NY4uRk4OCQETiVV757BA2GISF+6tZ+ti5OIQEjjMKPF7wUQmkISQwGJGiXVb87oYOTjYBCwk uv9pg4RFBPwkmldMZwexmQW0Jf5fX8cIYgsLWEt8OdTOBlFjI3FsL0RcRMBIoqvnL5jNIqAi 8evPZrBeXgFfiUm/PrND7F3BKnF01nOwBKeAg8SfaS9YQWxGoOO+n1rDBLFMXOLWk/lMEEcL SCzZc54ZwhaVePn4HyuErShxdfpyqHodiQW7P7HBHLps4WtmiMWCEidnPmGZwCg2C8nYWUha ZiFpmYWkZQEjyypG9tzEzJz0csNNjMCoObjlt+4OxlPnRA4xSnOwKInzJnE1BgoJpCeWpGan phakFsUXleakFh9iZOLgBBFcUg2MbHcd9oudOfNk45WMuPiM7vfGny7ZslTtWyIWJqGlmfO5 7hX76mvdtu89dLgXz7i88OTqDcaJXCeX+m8+3B8WPyPKzUWSf4r4ReVH9xy9jZwiO3UPFTy8 f63Ja4t3Hlt66Wfv5JCJD/cGXpYrDux/rbkzbkmStcWFeydKwtZ8kVw2e5/vTz5xJZbijERD Leai4kQA5S5nmG0CAAA= Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP outbound and in-dialog requests X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 13:23:07 -0000 Hi, Perhaps this could work in some cases, but as Inaki said: it breaks RFC 326= 1, and RFC 5626. Only for new dialogs can a new flow (read: route set) be s= elected. Regards, Christer -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Dale R. Worley Sent: 3. toukokuuta 2013 4:15 To: IC1aki Baz Castillo Cc: dispatch@ietf.org Subject: Re: [dispatch] SIP outbound and in-dialog requests > From: IC1aki Baz Castillo >=20 > When GRUU is used in the INVITE/200 Contact, the proxy+registrar=20 > should also perform GRUU based registration lookup so IMHO the=20 > procedure below also applies, and it means thar the route set could be=20 > changed during a dialog if the peer re-registered again after a=20 > connection break (so its connection gets a new Outboud flow token id).=20 > This is the issue being discussed here: the route set is changed since=20 > within the dialog the registrar gets the new Path containing a new=20 > flow token and thus the Route it adds is different than the original rout= e set. Ah, OK, now I recall. The new flow will be used *if* the UA uses its GRUU = as its Contact. Dale _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From ibc@aliax.net Fri May 3 06:54:28 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D10CE21F890F for ; Fri, 3 May 2013 06:54:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ECMx7g6fN-pS for ; Fri, 3 May 2013 06:54:14 -0700 (PDT) Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA2421F9657 for ; Fri, 3 May 2013 06:54:13 -0700 (PDT) Received: by mail-qc0-f179.google.com with SMTP id b40so737333qcq.10 for ; Fri, 03 May 2013 06:54:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=EmaW52ZfZ2mcQnxSZlfZ4ZoE2ZD/sOmE55v11JJYRs0=; b=LKC2aGndmSeerE1m9hIXWOglV5nNa21krtMyJO8GVXQRq2NQwd/f2pxJffi+KbxP0s DpMbIE3qiMkM/sotl/Xhozj/1lKZzs9GeLzUeyR80TaNn0jQTbmc1nTMbQyLv4ed/z06 PdO0nFj5RO7cmX8mp+x12hyRHXtjz1O/XPz0TJ/OfVGEjd4As3ZbHpSUBGUGtcpe+f60 immv9cMi3jIZZbf6GmqWCv4E8cOBMVHLNuRJxqwQ6xYAssVkgx8Gc+4L8u5rqset6BPi +E9s7vZbKhoOXOCuNhAbPyjLamTv5K64PBnRl4pe3MAxe19wrb+/UiWympPBufUJ/09H wiOw== X-Received: by 10.224.66.136 with SMTP id n8mr12754687qai.84.1367589252709; Fri, 03 May 2013 06:54:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.81.175 with HTTP; Fri, 3 May 2013 06:53:52 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C36B55D@ESESSMB209.ericsson.se> References: <339625C1-F16E-429F-BA62-066F6F6B3B51@edvina.net> <6360A039-E87A-4872-A480-587FC9F84D2F@edvina.net> <201305021842.r42Ig2DO3979809@shell01.TheWorld.com> <201305030115.r431FRoS4006275@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C36B55D@ESESSMB209.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Fri, 3 May 2013 15:53:52 +0200 Message-ID: To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmxB8j5Ha+RS5cAM8qrrp81hcEmdtAT4N+1gSWFRHFRxlp56M5pokZcgiYzg2jHT3rKMUi4 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP outbound and in-dialog requests X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 13:54:29 -0000 2013/5/3 Christer Holmberg : > Perhaps this could work in some cases, but as Inaki said: it breaks RFC 3= 261, and RFC 5626. Only for new dialogs can a new flow (read: route set) be= selected. So we loose the capability of receiving an in-dialog request once our NATed TCP connection has been disconnected (regardless we have reconnected and re-registered again). That is really really sad. -- I=C3=B1aki Baz Castillo From prvs=88353e42bc=christer.holmberg@ericsson.com Fri May 3 10:45:07 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C09521F962C for ; Fri, 3 May 2013 10:45:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.35 X-Spam-Level: X-Spam-Status: No, score=-3.35 tagged_above=-999 required=5 tests=[HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SABFtUnqop26 for ; Fri, 3 May 2013 10:45:00 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id A900821F8B5F for ; Fri, 3 May 2013 10:42:26 -0700 (PDT) X-AuditID: c1b4fb25-b7f396d000007d06-c1-5183f701f591 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 7C.D0.32006.107F3815; Fri, 3 May 2013 19:42:25 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.02.0328.009; Fri, 3 May 2013 19:42:25 +0200 From: Christer Holmberg To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Thread-Topic: [dispatch] SIP outbound and in-dialog requests Thread-Index: AQHOR5uxaZW6BfvFUkyNBG2wEi4qB5jzclcw///oNACAAGEnyA== Date: Fri, 3 May 2013 17:42:24 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C36B6BF@ESESSMB209.ericsson.se> References: <339625C1-F16E-429F-BA62-066F6F6B3B51@edvina.net> <6360A039-E87A-4872-A480-587FC9F84D2F@edvina.net> <201305021842.r42Ig2DO3979809@shell01.TheWorld.com> <201305030115.r431FRoS4006275@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C36B55D@ESESSMB209.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrJLMWRmVeSWpSXmKPExsUyM+JvrS7j9+ZAg90TzCyWTlrAajF9n43F yxNlDswe5xres3tM3v+V2WPJkp9MAcxR3DZJiSVlwZnpefp2CdwZHfe2sxVsZa74fGkeYwPj RaYuRg4OCQETiQ9P3boYOYFMMYkL99azdTFycQgJHGaUWNy8nBnCWcwo0Xn7NDNIA5uAhUT3 P22QBhEBS4kbc28yg9jMAiESfy9cZwKxhQWsJb4cameDqLGROLZ3HSOE7SRx7t5+RpAxLAIq Ev1/xEDCvAK+Eoen9ECt2sgmseh5NztIglMgUOL/4RtgMxmBjvt+ag0TxC5xiVtP5jNBHC0g sWTPeWYIW1Ti5eN/rBC2okT70wZGiHo9iRtTp7BB2NoSyxa+ZoZYLChxcuYTlgmMYrOQjJ2F pGUWkpZZSFoWMLKsYmTPTczMSS832sQIjJmDW36r7mC8c07kEKM0B4uSOG8yV2OgkEB6Yklq dmpqQWpRfFFpTmrxIUYmDk4QwSXVwOjfGPrY73Wdevj668y6LwIeM7Aw+Sx6O22H4HJZuwtf Td/O2cF1LWFj6rTep57KnbEvAoOdn3UZ7tHQnF7RIS++1krFgMdCqU17idYnyc5j7uyNr2ff /Pb2sHPn3ATbvVrdvxPMLe67618KPyXH+ChXYefi5/NtqmO+xRisNK719d/eobeDSYmlOCPR UIu5qDgRADEByt9sAgAA Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP outbound and in-dialog requests X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 17:45:07 -0000 Hi, >> Perhaps this could work in some cases, but as Inaki said: it breaks RFC = 3261, and RFC 5626. Only for new dialogs can a new flow (read: route set) b= e selected. > > So we loose the capability of receiving an in-dialog request once our > NATed TCP connection has been disconnected (regardless we have > reconnected and re-registered again). > > That is really really sad. C'est la SIP :) Regards, Christer From worley@shell01.TheWorld.com Fri May 3 11:02:10 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F128521F9663 for ; Fri, 3 May 2013 11:02:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.117 X-Spam-Level: X-Spam-Status: No, score=0.117 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=1.117] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R0q4zqCdki5J for ; Fri, 3 May 2013 11:02:04 -0700 (PDT) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id 5AA8221F962D for ; Fri, 3 May 2013 11:02:02 -0700 (PDT) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r43I1f5b011915; Fri, 3 May 2013 14:01:43 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r43I1ed54033076; Fri, 3 May 2013 14:01:40 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r43I1cSY4050203; Fri, 3 May 2013 14:01:38 -0400 (EDT) Date: Fri, 3 May 2013 14:01:38 -0400 (EDT) Message-Id: <201305031801.r43I1cSY4050203@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Christer Holmberg In-reply-to: <7594FB04B1934943A5C02806D1A2204B1C36B55D@ESESSMB209.ericsson.se> (christer.holmberg@ericsson.com) References: <339625C1-F16E-429F-BA62-066F6F6B3B51@edvina.net> <6360A039-E87A-4872-A480-587FC9F84D2F@edvina.net> <201305021842.r42Ig2DO3979809@shell01.TheWorld.com> <201305030115.r431FRoS4006275@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C36B55D@ESESSMB209.ericsson.se> Cc: dispatch@ietf.org Subject: Re: [dispatch] SIP outbound and in-dialog requests X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 18:02:10 -0000 > From: Christer Holmberg > > Perhaps this could work in some cases, but as Inaki said: it breaks > RFC 3261, and RFC 5626. Only for new dialogs can a new flow (read: > route set) be selected. The trouble seems to be that when the dialog is established, the particular flow from the proxy to the UA is Record-Routed. If the UA uses a GRUU as its Contact URI, a Record-Route isn't needed to record the particular route, since the GRUU can be resolved when each in-dialog request is processed. Dale From prvs=88353e42bc=christer.holmberg@ericsson.com Fri May 3 12:39:50 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B14A521F8EFE for ; Fri, 3 May 2013 12:39:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.8 X-Spam-Level: X-Spam-Status: No, score=-4.8 tagged_above=-999 required=5 tests=[AWL=1.449, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dRk7tVYlWLhR for ; Fri, 3 May 2013 12:39:44 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 0E51721F8F5C for ; Fri, 3 May 2013 12:39:43 -0700 (PDT) X-AuditID: c1b4fb25-b7f396d000007d06-bd-5184127ec02d Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 0A.D5.32006.E7214815; Fri, 3 May 2013 21:39:43 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.02.0328.009; Fri, 3 May 2013 21:39:42 +0200 From: Christer Holmberg To: "Dale R. Worley" Thread-Topic: [dispatch] SIP outbound and in-dialog requests Thread-Index: AQHOR5uxaZW6BfvFUkyNBG2wEi4qB5jzclcwgABPfmKAABoxwg== Date: Fri, 3 May 2013 19:39:41 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C36B7BA@ESESSMB209.ericsson.se> References: <339625C1-F16E-429F-BA62-066F6F6B3B51@edvina.net> <6360A039-E87A-4872-A480-587FC9F84D2F@edvina.net> <201305021842.r42Ig2DO3979809@shell01.TheWorld.com> <201305030115.r431FRoS4006275@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C36B55D@ESESSMB209.ericsson.se>, <201305031801.r43I1cSY4050203@shell01.TheWorld.com> In-Reply-To: <201305031801.r43I1cSY4050203@shell01.TheWorld.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrILMWRmVeSWpSXmKPExsUyM+JvrW69UEugwc19zBZLJy1gtXh5osyB yWPy/q/MHkuW/GQKYIritklKLCkLzkzP07dL4M44c2URa8FHlorr31vZGxifM3cxcnJICJhI vH52mQXCFpO4cG89WxcjF4eQwGFGic23tjJBOIsZJZ5vug+U4eBgE7CQ6P6nDWKKCGhKdCzI AellFtCW+H99HSOILSxgLfHlUDsbiC0iYCNxbC9EXETASeLszwlgu1gEVCQWrz8DVsMr4Cux puE+M8SqBWwSX7YdBzuOU8BBovvrd3YQmxHouO+n1jBBLBOXuPVkPhPE0QISS/ach3pGVOLl 43+sELaixM6z7cwQ9ToSC3Z/YoM5dNnC18wQiwUlTs58wjKBUWwWkrGzkLTMQtIyC0nLAkaW VYzsuYmZOenlRpsYgTFycMtv1R2Md86JHGKU5mBREudN5moMFBJITyxJzU5NLUgtii8qzUkt PsTIxMEJIrikGhin5uWlJdVlrf/Wy8+7xqUvmiM0ziX/ytldWd8+fmfnrOG2iJxW15cU8ONs 7ezCaqZqhr5JTht55eu2/K10vKV292vDzFNlbGtn/6p69H7lp6qpIi6cPI7z25cLHS06HH7b 9oquvPOzTY+m/JRdq3/G23bOjDW5e/hcM26o39k1QfaATmjCEQ4lluKMREMt5qLiRABQlg75 ZAIAAA== Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP outbound and in-dialog requests X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 19:39:50 -0000 Hi, >> Perhaps this could work in some cases, but as Inaki said: it breaks >> RFC 3261, and RFC 5626. Only for new dialogs can a new flow (read: >> route set) be selected. > > The trouble seems to be that when the dialog is established, the > particular flow from the proxy to the UA is Record-Routed. If the UA > uses a GRUU as its Contact URI, a Record-Route isn't needed to record > the particular route, since the GRUU can be resolved when each > in-dialog request is processed. The in-dialog requests need to traverse the edge proxy, so the edge proxy n= eeds to Record-Route. Regards, Christer From klaus.mailinglists@pernau.at Mon May 6 00:33:53 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0740B21F8E96 for ; Mon, 6 May 2013 00:33:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.53 X-Spam-Level: X-Spam-Status: No, score=-0.53 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, J_CHICKENPOX_51=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PpTstduX+T+r for ; Mon, 6 May 2013 00:33:48 -0700 (PDT) Received: from ds3000.pernau.at (ds3000.pernau.at [88.198.53.113]) by ietfa.amsl.com (Postfix) with ESMTP id 199D221F8E04 for ; Mon, 6 May 2013 00:33:48 -0700 (PDT) Received: from [10.10.0.51] (nat.labs.nic.at [83.136.33.3]) by ds3000.pernau.at (Postfix) with ESMTPSA id 9DEBB1088004; Mon, 6 May 2013 09:33:46 +0200 (CEST) Message-ID: <51875CDA.6020800@pernau.at> Date: Mon, 06 May 2013 09:33:46 +0200 From: Klaus Darilion User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= References: <339625C1-F16E-429F-BA62-066F6F6B3B51@edvina.net> <6360A039-E87A-4872-A480-587FC9F84D2F@edvina.net> <201305021842.r42Ig2DO3979809@shell01.TheWorld.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: dispatch@ietf.org Subject: Re: [dispatch] SIP outbound and in-dialog requests X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 07:33:53 -0000 It seems that technically it would be possible to change the in-dialog route-set, but all nodes need to be prepared for that and switch to the new route-set, and this also implies that the Path-vector is identical to the INVITE-route-set (which may not be the case in big setups). Further, you are always talking about registrar->user agent requests - but of course there may be user agent -> registrar requests that may swap flows. regards Klaus On 02.05.2013 20:49, Iñaki Baz Castillo wrote: > When GRUU is used in the INVITE/200 Contact, the proxy+registrar should > also perform GRUU based registration lookup so IMHO the procedure below > also applies, and it means thar the route set could be changed during a > dialog if the peer re-registered again after a connection break (so its > connection gets a new Outboud flow token id). This is the issue being > discussed here: the route set is changed since within the dialog the > registrar gets the new Path containing a new flow token and thus the > Route it adds is different than the original route set. > > -- > Iñaki Baz Castillo > > > > El 02/05/2013 20:42, "Dale R. Worley" > escribió: > > > From: JosC) Luis MillC!n > > > > > Extracted from RFC 5626, chapter 7: > > > > ``` > > > > The proxy uses the next-hop target of the message and the value of > > any stored Path header field vector in the registration binding to > > decide how to forward and populate the Route header in the > request. > > If the proxy is co-located with the registrar and stored > information > > about the flow to the UA that created the binding, then the proxy > > MUST send the request over the same 'logical flow' saved with the > > binding, since that flow is known to deliver data to the specific > > target UA instance's network flow that was saved with the binding. > > It appears to me that this procedure is to be carried out only in the > circumstances described in the paragraph at the beginning of section > 7: > > When a proxy uses the location service to look up a registration > binding and then proxies a request to a particular contact, it > selects a contact to use normally, with a few additional rules: > > That is, it only applies when the proxy is looking up a registration > binding == the next-hop address is the AOR. > > Dale > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From prvs=183820c6e0=christer.holmberg@ericsson.com Mon May 6 01:49:37 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C432C21F8F24 for ; Mon, 6 May 2013 01:49:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.074 X-Spam-Level: X-Spam-Status: No, score=-5.074 tagged_above=-999 required=5 tests=[AWL=0.275, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_51=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k46MCzLJBlCK for ; Mon, 6 May 2013 01:49:32 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 070B621F8F41 for ; Mon, 6 May 2013 01:49:31 -0700 (PDT) X-AuditID: c1b4fb2d-b7f536d000006e05-88-51876e96639b Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id F1.E7.28165.69E67815; Mon, 6 May 2013 10:49:26 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.02.0328.009; Mon, 6 May 2013 10:49:25 +0200 From: Christer Holmberg To: Klaus Darilion , =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Thread-Topic: [dispatch] SIP outbound and in-dialog requests Thread-Index: AQHOR2S8aZW6BfvFUkyNBG2wEi4qB5jyGz+AgAWMhQCAAChCsA== Date: Mon, 6 May 2013 08:49:25 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C36BE0E@ESESSMB209.ericsson.se> References: <339625C1-F16E-429F-BA62-066F6F6B3B51@edvina.net> <6360A039-E87A-4872-A480-587FC9F84D2F@edvina.net> <201305021842.r42Ig2DO3979809@shell01.TheWorld.com> <51875CDA.6020800@pernau.at> In-Reply-To: <51875CDA.6020800@pernau.at> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrNLMWRmVeSWpSXmKPExsUyM+Jvre60vPZAg73X1C2WTlrAajF9n43F wuWbmRyYPc41vGf3WLLkJ5PH3ndtjAHMUdw2SYklZcGZ6Xn6dgncGVNWX2cv6JWumPjuHFsD 40uRLkZODgkBE4n+reuZIWwxiQv31rN1MXJxCAkcZpQ49+MNlLOYUaJt2hWWLkYODjYBC4nu f9ogDSICWRLrT85nAbGZBbQl/l9fxwhiCwtYS3w51M4GUWMjcWwvRFxEwEmiZWYvWD2LgIrE gvW/mEBsXgFfia+rDzFB7JrIKjHtbTcryC5OAU2J1mvmIDWMQMd9P7WGCWKXuMStJ/OZII4W kFiy5zzUA6ISLx//Y4WwFSWuTl8OVa8ncWPqFDaYO5ctfM0MsVdQ4uTMJywTGMVmIRk7C0nL LCQts5C0LGBkWcXInpuYmZNebriJERg3B7f81t3BeOqcyCFGaQ4WJXHeJK7GQCGB9MSS1OzU 1ILUovii0pzU4kOMTBycIIJLqoFxNtupS1vn3Hy12fb4ZWW5ZRn1EmriG1RrhLa4a2apz5Y1 2LqjX+HLk+L/q7UFxX98XG7irP7oM7PXGpPV/UzyP7/0nb2YIvrDoSIxxjO/9s9qT5Gnu3Ja Wj3vZ4dyLnj4z/Or9brUJM4PubXO0VNmNUiaZDIwtdrKXvz51I75oaNlwLsEAzElluKMREMt 5qLiRABR7eKTbgIAAA== Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP outbound and in-dialog requests X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 08:49:37 -0000 Hi, > It seems that technically it would be possible to change the in-dialog ro= ute-set, but all nodes need to be prepared for that=20 > and switch to the new route-set, and this also implies that the Path-vect= or is identical to the INVITE-route-set (which may not be the case in big s= etups).=20 > Further, you are always talking about registrar->user agent requests - bu= t of course there may be user agent -> registrar requests that may swap flo= ws. It is of course possible to transfer/replace the dialog, and hence create a= new route set (as part of the new dialog), but if you want to do that with= out affecting the other endpoint you of course need B2BUA functionality in = the network. Regards, Christer On 02.05.2013 20:49, I=F1aki Baz Castillo wrote: > When GRUU is used in the INVITE/200 Contact, the proxy+registrar=20 > should also perform GRUU based registration lookup so IMHO the=20 > procedure below also applies, and it means thar the route set could be=20 > changed during a dialog if the peer re-registered again after a=20 > connection break (so its connection gets a new Outboud flow token id).=20 > This is the issue being discussed here: the route set is changed since=20 > within the dialog the registrar gets the new Path containing a new=20 > flow token and thus the Route it adds is different than the original rout= e set. > > -- > I=F1aki Baz Castillo > > > > El 02/05/2013 20:42, "Dale R. Worley" > escribi=F3: > > > From: JosC) Luis MillC!n > > > > > Extracted from RFC 5626, chapter 7: > > > > ``` > > > > The proxy uses the next-hop target of the message and the value= of > > any stored Path header field vector in the registration binding= to > > decide how to forward and populate the Route header in the > request. > > If the proxy is co-located with the registrar and stored > information > > about the flow to the UA that created the binding, then the pro= xy > > MUST send the request over the same 'logical flow' saved with t= he > > binding, since that flow is known to deliver data to the specif= ic > > target UA instance's network flow that was saved with the bindi= ng. > > It appears to me that this procedure is to be carried out only in the > circumstances described in the paragraph at the beginning of section > 7: > > When a proxy uses the location service to look up a registration > binding and then proxies a request to a particular contact, it > selects a contact to use normally, with a few additional rules: > > That is, it only applies when the proxy is looking up a registration > binding =3D=3D the next-hop address is the AOR. > > Dale > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From oej@edvina.net Mon May 6 01:55:05 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E819C21F8C33 for ; Mon, 6 May 2013 01:55:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_51=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MmfPAEtV-+KT for ; Mon, 6 May 2013 01:55:05 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id C51FE21F84A6 for ; Mon, 6 May 2013 01:55:03 -0700 (PDT) Received: from [IPv6:2001:16d8:cc57:1000::42:1005] (unknown [IPv6:2001:16d8:cc57:1000::42:1005]) by smtp7.webway.se (Postfix) with ESMTPA id 8082193C2A1; Mon, 6 May 2013 08:55:01 +0000 (UTC) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: "Olle E. Johansson" In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C36BE0E@ESESSMB209.ericsson.se> Date: Mon, 6 May 2013 10:55:00 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <59D83BB5-1EE1-421E-A1D7-18C772E466B1@edvina.net> References: <339625C1-F16E-429F-BA62-066F6F6B3B51@edvina.net> <6360A039-E87A-4872-A480-587FC9F84D2F@edvina.net> <201305021842.r42Ig2DO3979809@shell01.TheWorld.com> <51875CDA.6020800@pernau.at> <7594FB04B1934943A5C02806D1A2204B1C36BE0E@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1503) Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP outbound and in-dialog requests X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 08:55:06 -0000 6 maj 2013 kl. 10:49 skrev Christer Holmberg = : > Hi, >=20 >> It seems that technically it would be possible to change the = in-dialog route-set, but all nodes need to be prepared for that=20 >> and switch to the new route-set, and this also implies that the = Path-vector is identical to the INVITE-route-set (which may not be the = case in big setups).=20 >> Further, you are always talking about registrar->user agent requests = - but of course there may be user agent -> registrar requests that may = swap flows. >=20 > It is of course possible to transfer/replace the dialog, and hence = create a new route set (as part of the new dialog), but if you want to = do that without affecting the other endpoint you of course need B2BUA = functionality in the network. It seems to me that Outbound only handles dialog-forming requests, but = currently can't handle survival of a dialog between two or more flows between the UA and the edge proxy. That's something = that needs to be fixed. /O >=20 > Regards, >=20 > Christer >=20 >=20 > On 02.05.2013 20:49, I=F1aki Baz Castillo wrote: >> When GRUU is used in the INVITE/200 Contact, the proxy+registrar=20 >> should also perform GRUU based registration lookup so IMHO the=20 >> procedure below also applies, and it means thar the route set could = be=20 >> changed during a dialog if the peer re-registered again after a=20 >> connection break (so its connection gets a new Outboud flow token = id).=20 >> This is the issue being discussed here: the route set is changed = since=20 >> within the dialog the registrar gets the new Path containing a new=20 >> flow token and thus the Route it adds is different than the original = route set. >>=20 >> -- >> I=F1aki Baz Castillo >> > >>=20 >> El 02/05/2013 20:42, "Dale R. Worley" > > escribi=F3: >>=20 >>> From: JosC) Luis MillC!n > > >>>=20 >>> Extracted from RFC 5626, chapter 7: >>>=20 >>> ``` >>>=20 >>> The proxy uses the next-hop target of the message and the value of >>> any stored Path header field vector in the registration binding to >>> decide how to forward and populate the Route header in the >> request. >>> If the proxy is co-located with the registrar and stored >> information >>> about the flow to the UA that created the binding, then the proxy >>> MUST send the request over the same 'logical flow' saved with the >>> binding, since that flow is known to deliver data to the specific >>> target UA instance's network flow that was saved with the binding. >>=20 >> It appears to me that this procedure is to be carried out only in = the >> circumstances described in the paragraph at the beginning of = section >> 7: >>=20 >> When a proxy uses the location service to look up a = registration >> binding and then proxies a request to a particular contact, it >> selects a contact to use normally, with a few additional = rules: >>=20 >> That is, it only applies when the proxy is looking up a = registration >> binding =3D=3D the next-hop address is the AOR. >>=20 >> Dale >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >>=20 >>=20 >>=20 >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >>=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From ibc@aliax.net Mon May 6 06:44:33 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6872D21F90F1 for ; Mon, 6 May 2013 06:44:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YbOJGzoB4R9p for ; Mon, 6 May 2013 06:44:27 -0700 (PDT) Received: from mail-qe0-f51.google.com (mail-qe0-f51.google.com [209.85.128.51]) by ietfa.amsl.com (Postfix) with ESMTP id EAC6F21F90EB for ; Mon, 6 May 2013 06:44:26 -0700 (PDT) Received: by mail-qe0-f51.google.com with SMTP id x7so2072001qeu.10 for ; Mon, 06 May 2013 06:44:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=6TbdkvKDFcF+DWO07e9+pVvHgSZDhHjyWUTJ50a8rXA=; b=QrS+Q5/p88zCvQLsqP4vBvanzP4phLPW7/NqZx1wFF5yZ7tN1tYcU23AdIKcsEsln3 PgeU95DJ7qTJwX4jJOIvg9ZojmNYyoePCV/ga2/oRE0OG8vwZ83cPvwW1mneJOWMq0qT RogW3Ck8Lep/AyzZipzpZA2/ThbhXBsyodF/kjFUNw+0b0ckxeY8ekjFn5vv/Mjj9IdZ tQ+q/HGN93JzUpCyDn5nqgAGdz8rtunUxGMt7E3UKvH6IWKNhVPEoyD0bUvBwRIyPp64 8dDuwrdpnjDejaooHVREkl5aSOP4GowX4hjPHxpmUoSrqt/2YUxNlukoJC5lGnrcb26r E0yA== X-Received: by 10.224.182.136 with SMTP id cc8mr18185789qab.10.1367847866305; Mon, 06 May 2013 06:44:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.81.175 with HTTP; Mon, 6 May 2013 06:44:06 -0700 (PDT) In-Reply-To: <59D83BB5-1EE1-421E-A1D7-18C772E466B1@edvina.net> References: <339625C1-F16E-429F-BA62-066F6F6B3B51@edvina.net> <6360A039-E87A-4872-A480-587FC9F84D2F@edvina.net> <201305021842.r42Ig2DO3979809@shell01.TheWorld.com> <51875CDA.6020800@pernau.at> <7594FB04B1934943A5C02806D1A2204B1C36BE0E@ESESSMB209.ericsson.se> <59D83BB5-1EE1-421E-A1D7-18C772E466B1@edvina.net> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 6 May 2013 15:44:06 +0200 Message-ID: To: "Olle E. Johansson" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkYxj70D5UEfIhJRV+Tc1JJsnSQBQnb4+pnYylaKZwdBzDJZ2Y6gyAfEfgd5x1wtxQfDJk4 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP outbound and in-dialog requests X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 13:44:33 -0000 2013/5/6 Olle E. Johansson : > It seems to me that Outbound only handles dialog-forming requests, but cu= rrently can't handle survival of a dialog between > two or more flows between the UA and the edge proxy. That's something tha= t needs to be fixed. Right, let me please simplify this issue with an example: Alice --- REGISTRAR --- EDGE --- Bob - Bob registers with GRUU through EDGE Proxy which performs Path. - Alice calls Bob. - Bob disconnectes, connects again and sends a new REGISTER. - EDGE sets a new outbound flow token in the Path header. The new binding (with new Path) replaces the previous one in the location DB. - Alice sends BYE to Bob. The BYE arrives to REGISTRAR which performs lookup for the binding of the GRUU URI of the BYE, and retrieves the new binding of Bob, so adds such a Route to the request, which now looks as follows: BYE sip:bob@billoxi.com;gr=3Dqweasdzxc Route: (removed by REGISTRAR) Route: Route: (removed by REGSISTRAR OR NOT ????) - Of course here RFC 3261 is violated since the route set is changed. However endpoints will not realize of it since EDGE would remove both remaining Route headers before routing the request to Bob, but for that to work, REGISTRAR should previously also remove the EDGE-BOB-OLD-PATH Route header (otherwise EDGE Proxy would try to route via the old closed connection). Well, we have here a pain of Route headers added by intermediary proxies within a dialog, which seems ugly. We need a solution: 1) Is the above allowed by RFC 5626/5627 or not? 2) How to avoid it? In case a new registration modifies the binding (including Path header with outbound flow token), nothing prevents the registrar to use the new binding for an in-dialog request, but it violates RFC 3261 (route set changed). 3) Anyhow endpoints will never see the new Route set so, does this violate 3261 or not? 4) and anyhow... the REGISTRAR (see example above) needs to remove the Route header pointing to next step before it inserts a new one due to the binding lookup and Path retrieval. Otherwise the request arrives to the EDGE proxy with two Route (with Flow-Token) headers pointing to it. All of this is really unclear. I hope there is an answer that allows a dialog to remain alive once the NATted TCP connection of an endpoint is closed during the dialog. Otherwise, nobody cared about mobile intermittent networks when RFC 5626/5627 were written? Regards. -- I=C3=B1aki Baz Castillo From oej@edvina.net Mon May 6 07:21:11 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C305C21F9359 for ; Mon, 6 May 2013 07:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.15 X-Spam-Level: X-Spam-Status: No, score=-2.15 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gp+9K+nVu+JV for ; Mon, 6 May 2013 07:21:11 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id B9F4A21F9357 for ; Mon, 6 May 2013 07:21:05 -0700 (PDT) Received: from [192.168.40.5] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id AA28D93C1AF; Mon, 6 May 2013 14:21:04 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: "Olle E. Johansson" In-Reply-To: Date: Mon, 6 May 2013 16:21:05 +0200 Content-Transfer-Encoding: 7bit Message-Id: <30FFD300-C7F8-4DDA-B936-F32F403F6135@edvina.net> References: <339625C1-F16E-429F-BA62-066F6F6B3B51@edvina.net> <6360A039-E87A-4872-A480-587FC9F84D2F@edvina.net> <201305021842.r42Ig2DO3979809@shell01.TheWorld.com> <51875CDA.6020800@pernau.at> <7594FB04B1934943A5C02806D1A2204B1C36BE0E@ESESSMB209.ericsson.se> <59D83BB5-1EE1-421E-A1D7-18C772E466B1@edvina.net> To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1503) Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP outbound and in-dialog requests - changing route set X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 14:21:11 -0000 > > > 3) Anyhow endpoints will never see the new Route set so, does this > violate 3261 or not? > That's interesting. Just to quote RFC 3261 for information: 12.2 : "Requests within a dialog MAY contain Record-Route and Contact header fields. However, these requests do not cause the dialog's route set to be modified, although they may modify the remote target URI." "Target refresh requests only update the dialog's remote target URI, and not the route set formed from the Record-Route. Updating the latter would introduce severe backwards compatibility problems with RFC 2543-compliant systems." Section 12.2.1 Opens up for sending to alternate addresses, without changing the route set. There's a discussion about using a new contact header to update the IP address by using a target refresh. 12.2.1.1 ends with " Subject to certain restrictions, they allow the request to be sent to an alternate address (such as a default outbound proxy not represented in the route set)." If the first route header from the UA point of view is a DNS name, the situation seems easier to handle. The DNS name resolves to the set of edge proxys. The contact can be a gruu. Maybe avoiding to use IP in record-route headers is a possible solution that allows us to retarget. Any thoughts? /O From ibc@aliax.net Mon May 6 08:16:05 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65ADB21F8FAB for ; Mon, 6 May 2013 08:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f5Un-XGirAe4 for ; Mon, 6 May 2013 08:16:00 -0700 (PDT) Received: from mail-qe0-f52.google.com (mail-qe0-f52.google.com [209.85.128.52]) by ietfa.amsl.com (Postfix) with ESMTP id 31C5D21F859B for ; Mon, 6 May 2013 08:15:59 -0700 (PDT) Received: by mail-qe0-f52.google.com with SMTP id nd7so2085352qeb.25 for ; Mon, 06 May 2013 08:15:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=x8M/jY+c9OUcm1t+leJv2mtLeKXZ6bCU1qj5hQNTgtw=; b=mQ1WIovmDsySY2shLAWkplHGdNshBPN7TpwuG2DCOsvQ+WW6JTi7+522MIw8ezAE8d QG7i6hpr4TZ1iwIKJhw8VH3k2leQPd4ATuy9XxIkV4dXIHToA9mQbCAaWzjYG773iNwW bz0ADnGw3BeswTaXmyN+1PjZ5rvcvYqRkKx8RF3Xlmy7bbZSFX8AyN9Xylm6vYLIPrSS O+6xaGKwGLxROPYf2TLpfL7vEuyHe9bEFAnxFj/aVTCpF10xbkuCNgMymIPcYP4rrkH/ BUFZxYhHFnBedbCOTQrK+rBNB/qIPV3q+d5FvtnXDU2Eba/x+kStsIzRO7UPKdBdJ9GF 1rMw== X-Received: by 10.229.150.199 with SMTP id z7mr1173037qcv.25.1367853359263; Mon, 06 May 2013 08:15:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.81.175 with HTTP; Mon, 6 May 2013 08:15:39 -0700 (PDT) In-Reply-To: <30FFD300-C7F8-4DDA-B936-F32F403F6135@edvina.net> References: <339625C1-F16E-429F-BA62-066F6F6B3B51@edvina.net> <6360A039-E87A-4872-A480-587FC9F84D2F@edvina.net> <201305021842.r42Ig2DO3979809@shell01.TheWorld.com> <51875CDA.6020800@pernau.at> <7594FB04B1934943A5C02806D1A2204B1C36BE0E@ESESSMB209.ericsson.se> <59D83BB5-1EE1-421E-A1D7-18C772E466B1@edvina.net> <30FFD300-C7F8-4DDA-B936-F32F403F6135@edvina.net> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 6 May 2013 17:15:39 +0200 Message-ID: To: "Olle E. Johansson" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmZN0bLzF6IMI5yUunbD2Nh52GAczpN0QJsfLU/JT0WewITVCzKh0USATMhADK+SYeF86/C Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP outbound and in-dialog requests - changing route set X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 15:16:05 -0000 2013/5/6 Olle E. Johansson : >> >> >> 3) Anyhow endpoints will never see the new Route set so, does this >> violate 3261 or not? >> > That's interesting. Just to quote RFC 3261 for information: > > 12.2 : "Requests within a dialog MAY contain Record-Route and Contact hea= der > fields. However, these requests do not cause the dialog's route set > to be modified, although they may modify the remote target URI." > > "Target refresh requests only update the dialog's remote target URI, > and not the route set formed from the Record-Route. Updating the > latter would introduce severe backwards compatibility problems with > RFC 2543-compliant systems." I don't care RFC 2543 old devices, even less taking into account that they will never see a modified Route set (as explained in my previous mail). > Section 12.2.1 Opens up for sending to alternate addresses, > without changing the route set. There's a discussion about using > a new contact header to update the IP address by using a target > refresh. > > > 12.2.1.1 ends with " Subject to certain restrictions, they allow the requ= est > to be sent to an alternate address (such as a default outbound > proxy not represented in the route set)." > > If the first route header from the UA point of view is a DNS name, > the situation seems easier to handle. The DNS name resolves > to the set of edge proxys. The contact can be a gruu. > > Maybe avoiding to use IP in record-route headers is a possible solution > that allows us to retarget. > > Any thoughts? Honestly I don't think that is the problem cause of the problem to solve. Here the real problem is that an endpoint can re-register via another TCP connection and also through another EDGE proxy and thus, the Path header arriving to the registrar will change (both the Outbound flow token identifer and the EDGE address). Later, when the registrar does lookup for the GRUU request URI of an indialog request, it will retrieve a different path so route set is modified (but endpoints will not realize of it). The main and primary question is: Can a registrar perform GRUU registration lookup for an *in-dialog* request or not? and if so, should it add a Route header with the value of the Path header associated to the retrieved binding? (note that such a Route was already present in the in-dialog request due to the already formed route set, so we have a duplicated Route header, or the old value + the new one). -- I=C3=B1aki Baz Castillo From prvs=8838a43c77=aallen@blackberry.com Mon May 6 08:20:38 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6D0521F8DA6 for ; Mon, 6 May 2013 08:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.202 X-Spam-Level: X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 88QrnOLY5y8g for ; Mon, 6 May 2013 08:20:34 -0700 (PDT) Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id 63C9F21F8E49 for ; Mon, 6 May 2013 08:20:34 -0700 (PDT) X-AuditID: 0a412830-b7fea6d000001de5-17-5187ca373cf2 Received: from XCT105ADS.rim.net (xct105ads.rim.net [10.67.111.46]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mhs061cnc.rim.net (SBG) with SMTP id F4.F7.07653.83AC7815; Mon, 6 May 2013 10:20:24 -0500 (CDT) Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT105ADS.rim.net ([fe80::2d01:2041:eea3:819b%22]) with mapi id 14.02.0328.009; Mon, 6 May 2013 10:20:23 -0500 From: Andrew Allen To: "dispatch@ietf.org" Thread-Topic: New Versions of draft-montemurro-gsma-imei-urn and draft-allen-dispatch-imei-urn-as-instanceid and new draft draft-allen-dispatch-poc-instanceid-usage Thread-Index: Ac5KbHuyo3hQFo7XQ1aM8zbGz/5EZQ== Date: Mon, 6 May 2013 15:20:23 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.110.254] Content-Type: multipart/alternative; boundary="_000_BBF5DDFE515C3946BC18D733B20DAD2338D69FDEXMB104ADSrimnet_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJKsWRmVeSWpSXmKPExsXC5Zyvp2txqj3QYP9acYulkxawOjB6LFny kymAMaqB0SYpsaQsODM9T9/OJjEvL78ksSRVISW1ONlWySc1PTFHIaAosywxuVLBJbM4OScx Mze1SEkhM8VWyURJoSAnMTk1NzWvxFYpsaAgNS9FyY5LAQPYAJVl5imk5iXnp2TmpdsqeQb7 61pYmFrqGirZ6SZ08mTMvV5WsLW8YufXFcwNjP1pXYwcHBICJhJ3r/F2MXICmWISF+6tZ+ti 5OIQEmhjkuj6OoMZwtnEKDH/2Tc2kCo2AS2J/YenM4HYIgLaEkdXdYEVCQssYZRo2HuGHcQR EVjJKPF43xFmiCo9iYt3ToF1swioSDRc3cEOYvMKeEjsuPwIbBIj0O7vp9aA2cwC4hK3nsxn grhJQGLJnvPMELaoxMvH/1ghbEWJZSdOskHU50u8Wb6REWKmoMTJmU9YJjAKzUIyahaSsllI yiDiOhILdn9ig7C1JZYtfM0MY5858JgJWXwBI/sqRsHcjGIDM8PkvGS9osxcvbzUkk2MoOh3 1DDYwfj+vcUhRgEORiUe3rT97YFCrIllxZW5hxglOJiVRHgr1wCFeFMSK6tSi/Lji0pzUosP MQYBQ2UisxR3cj4wMeWVxBsbGBDJURLnrXKrDBQSSAcmpuzU1ILUIpihTBycIEu5pESKgekl tSixtCQjHpQE44uBaVCqgbF0TtJU/k1bjM4Upm/ResL+gmHO/bTtLaEnJAsO3ra9Oc3ZYq2Q r8vr40cX/7WT7kn9FDVHO6C+JsJ7Ia9Hi9T69C9uJ2onffBL936qETMxQXQ5u6WvbFLdPxZP xsRT9f6b3K/NnMh8X8AlcmHX6ktlS5ZI7DVw05OyOPoksv5fq2hBpZ+pjRJLcUaioRZzUXEi ANCF49tMAwAA Subject: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and draft-allen-dispatch-imei-urn-as-instanceid and new draft draft-allen-dispatch-poc-instanceid-usage X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 15:20:39 -0000 --_000_BBF5DDFE515C3946BC18D733B20DAD2338D69FDEXMB104ADSrimnet_ Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable New Versions of draft-montemurro-gsma-imei-urn and draft-allen-dispatch-imei= -urn-as-instanceid have been submitted. http://www.ietf.org/id/draft-montemurro-gsma-imei-urn-14.txt http://www.ietf.org/id/draft-allen-dispatch-imei-urn-as-instanceid-09.txt Also a new draft draft-allen-dispatch-poc-instanceid-usage has been submitte= d that describes the additional usage by OMA PoC of the Instance ID in non-r= egister requests. http://www.ietf.org/id/draft-allen-dispatch-imei-urn-as-instanceid-08.txt These implement the way forward proposed in the discussion below. Please provide comments. Thanks Andrew From: Andrew Allen Sent: Monday, April 29, 2013 2:29 AM To: 'dispatch@ietf.org' Subject: Notes and Summary of April 17 call on draft-montemurro-gsma-imei-ur= n and draft-allen-dispatch-imei-urn-as-instanceid In order to make progress on draft-montemurro-gsma-imei-urn and draft-allen-= dispatch-imei-urn-as-instanceid a conference call was held on Wednesday April 17 attended by Culllen Jennings, Atle Monrad, John Luc Bakker and myse= lf. Below are the combined notes and summary from Cullen and I of this call on t= he IMEI drafts: 1) change draft-allen-dispatch-imei-urn-as-instanceid to say IMEI is only us= ed in either a register request or also in an emergency invite request Cullen will then be OK with it from a privacy point of view as long as it ex= plains the trade offs. It should be highlighted in draft-montemurro-gsma-imei-urn that using the IM= EI as a security credential is a bad thing even though some popular commerci= al applications are actually doing this and some service providers are using= knowledge of the IMEI to verify the legitimacy of caller being the authoriz= ed user/owner of the device. The IMEI is usually extremely easy to obtain by= anyone who has very brief physical access to the device as it is often prin= ted on the device beneath the battery and can be displayed by using a well-k= nown key press sequence. Change draft-allen-dispatch-imei-urn-as-instanceid to not be open to any ext= ension to URN but instead require a draft updating this draft if any paramet= er other than ver=3D0 was to be included. Also add text in draft-montemurro= -gsma-imei-urn and, draft-aindicating that extensions to the IMEI parameters= will require an update of draft-allen-dispatch-imei-urn-as-instanceid. 2) Write a new separate draft that tries to deal with the OMA push to talk c= ase. This would have the UA include the IMEI in an INVITE request in very particu= lar instances where the UA knew that request was going to the POC server and= that the POC server would remove it. I'm not sure what I would think of thi= s draft - Cullen might hate it - but regardless of if folks thought it was g= ood or bad, splitting it into a separate problem can allow the use in the fi= rst draft to proceed. Cullen would want this draft to be very clear on how a= UA knew it was "safe" to put the IMEI in a INVITE and Cullen does not think= the IME should ever be in an anonymous INVITE. The current text around you= only include the IMEI if you know it is safe does not seem implementable so= Cullen would prefer something where it was really clear when the UA did it= and when it did not. Cullen thinks this is much easier to do in the specifi= c case of push to talk than trying to solve it for all uses of an INVITE so= this should be easier to get people on board with than the current draft. Response to Cullen on the IME should never be in an anonymous INVITE point.= - in 3GPP networks there is really no such thing as an anonymous INVITE sin= ce the P-CSCF always knows the identity of the UE and will always include a= P-Asserted-Identity header field. There are instead requests where privacy= is requested and the P-Asserted-Identity header field is removed at the ed= ge of the trust domain. Thus in my view there is no need for a UE in the PoC= case where it knows the PoC Server will remove the instance ID to prohibit= inclusion of the IMEI. Cullen any comments to that? 3) Update draft-montemurro-gsma-imei-urn security section to clarify that th= e IMEI-SV is not updated based on the OS version or when new applications ar= e added but represents the software version of lower layer software that has= completed certification testing. I am in the process of updating the drafts as described above. Comments on the above are of course welcome Andrew --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. --_000_BBF5DDFE515C3946BC18D733B20DAD2338D69FDEXMB104ADSrimnet_ Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable

 

New Versions of draft-m= ontemurro-gsma-imei-urn and draft-allen-dispatch-imei-urn-as-instanceid = ; have been submitted.

 

http://www.ietf.org/id/dra= ft-montemurro-gsma-imei-urn-14.txt

 

http://www.ie= tf.org/id/draft-allen-dispatch-imei-urn-as-instanceid-09.txt<= /span>

 

 

Also a new draft draft-= allen-dispatch-poc-instanceid-usage has been submitted that describes the ad= ditional usage by OMA PoC of the Instance ID in non-register requests.<= /o:p>

 

http://www.ie= tf.org/id/draft-allen-dispatch-imei-urn-as-instanceid-08.txt<= /span>

 

These implement the way= forward proposed in the discussion below.

 

Please provide comments= .

 

Thanks

Andrew

 

 

From: Andrew Alle= n
Sent: Monday, April 29, 2013 2:29 AM
To: 'dispatch@ietf.org'
Subject: Notes and Summary of April 17 call on draft-montemurro-gsma-= imei-urn and draft-allen-dispatch-imei-urn-as-instanceid

 

 

In order to make progress on draft-montemurro-gsma= -imei-urn and draft-allen-dispatch-imei-urn-as-instanceid a conference call= was held on Wednesday

April 17 attended by Culllen Jennings, Atle Monrad= , John Luc Bakker and myself.

 

Below are the combined notes and summary from Cull= en and I of this call on the IMEI drafts:

 

 

1) change draft-allen-dispatch-imei-urn-as-instanc= eid to say IMEI is only used in either a register request or also in an emer= gency invite request

 

Cullen will then be OK with it from a privacy poin= t of view as long as it explains the trade offs.

 

It should be highlighted in draft-montemurro-gsma-= imei-urn that using the IMEI as a security credential is a bad thing even th= ough some popular commercial applications are actually doing this and some s= ervice providers are using knowledge of the IMEI to verify the legitimacy of caller being the authorized user/ow= ner of the device. The IMEI is usually extremely easy to obtain by anyone wh= o has very brief physical access to the device as it is often printed on the= device beneath the battery and can be displayed by using a well-known key press sequence.

 

Change draft-allen-dispatch-imei-urn-as-instanceid= to not be open to any extension to URN but instead require a draft updating= this draft if any parameter other than ver=3D0 was to be included.  Al= so add text in draft-montemurro-gsma-imei-urn and, draft-aindicating that extensions to the IMEI parameters will require= an update of draft-allen-dispatch-imei-urn-as-instanceid.

 

 

2) Write a new separate draft that tries to deal w= ith the OMA push to talk case.

 

This would have the UA include the IMEI in an INVI= TE request in very particular instances where the UA knew that request was g= oing to the POC server and that the POC server would remove it. I'm not sure= what I would think of this draft - Cullen might hate it - but regardless of if folks thought it was good or= bad, splitting it into a separate problem can allow the use in the first dr= aft to proceed. Cullen would want this draft to be very clear on how a UA kn= ew it was "safe" to put the IMEI in a INVITE and Cullen does not think the IME should ever be in an anonymou= s INVITE.  The current text around you only include the IMEI if you kno= w it is safe does not seem implementable so Cullen would prefer something wh= ere it was really clear when the UA did it and when it did not. Cullen thinks this is much easier to do in the= specific case of push to talk than trying to solve it for all uses of an IN= VITE so this should be easier to get people on board with than the current d= raft.

 

Response to Cullen on the IME should never be in a= n anonymous INVITE point. - in 3GPP networks there is really no such thing a= s an anonymous INVITE since the P-CSCF always knows the identity of the UE a= nd will always include a P-Asserted-Identity header field. There are instead requests where privacy is requested and the=   P-Asserted-Identity header field is removed at the edge of the trust= domain. Thus in my view there is no need for a UE in the PoC case where it= knows the PoC Server will remove the instance ID to prohibit inclusion of the IMEI. Cullen any comments to that?=

 

3) Update draft-montemurro-gsma-imei-urn security= section to clarify that the IMEI-SV is not updated based on the OS version= or when new applications are added but represents the software version of l= ower layer software that has completed certification testing.

 

I am in the process of updating the drafts as desc= ribed above.

 

Comments on the above are of course welcome

 

Andrew

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. --_000_BBF5DDFE515C3946BC18D733B20DAD2338D69FDEXMB104ADSrimnet_-- From worley@shell01.TheWorld.com Mon May 6 15:01:16 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1D7C21F9321 for ; Mon, 6 May 2013 15:01:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.38 X-Spam-Level: X-Spam-Status: No, score=-0.38 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KNryKI0l2-oM for ; Mon, 6 May 2013 15:01:11 -0700 (PDT) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id EA67921F931F for ; Mon, 6 May 2013 15:01:05 -0700 (PDT) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r46M0xlu023079; Mon, 6 May 2013 18:01:01 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r46M0wsk4268686; Mon, 6 May 2013 18:00:58 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r46M0wjP4269356; Mon, 6 May 2013 18:00:58 -0400 (EDT) Date: Mon, 6 May 2013 18:00:58 -0400 (EDT) Message-Id: <201305062200.r46M0wjP4269356@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Christer Holmberg In-reply-to: <7594FB04B1934943A5C02806D1A2204B1C36B7BA@ESESSMB209.ericsson.se> (christer.holmberg@ericsson.com) References: <339625C1-F16E-429F-BA62-066F6F6B3B51@edvina.net> <6360A039-E87A-4872-A480-587FC9F84D2F@edvina.net> <201305021842.r42Ig2DO3979809@shell01.TheWorld.com> <201305030115.r431FRoS4006275@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C36B55D@ESESSMB209.ericsson.se>, <201305031801.r43I1cSY4050203@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C36B7BA@ESESSMB209.ericsson.se> Cc: dispatch@ietf.org Subject: Re: [dispatch] SIP outbound and in-dialog requests X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 22:01:16 -0000 > From: Christer Holmberg > > >> Perhaps this could work in some cases, but as Inaki said: it breaks > >> RFC 3261, and RFC 5626. Only for new dialogs can a new flow (read: > >> route set) be selected. > > > > The trouble seems to be that when the dialog is established, the > > particular flow from the proxy to the UA is Record-Routed. If the UA > > uses a GRUU as its Contact URI, a Record-Route isn't needed to record > > the particular route, since the GRUU can be resolved when each > > in-dialog request is processed. > > The in-dialog requests need to traverse the edge proxy, so the edge > proxy needs to Record-Route. In-dialog requests need to traverse *an* edge proxy, but (in order to arrive), they needn't always traverse the *same* edge proxy. As long as the final URI is a GRUU for the UA, there is enough information in the request to allow successful routing, even if new flows are established. But 3261 requires the edge proxy used in the dialog-forming request to always be in the path. Dale From ibc@aliax.net Mon May 6 15:04:28 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5C3621F937B for ; Mon, 6 May 2013 15:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3PzHCMEhi7pc for ; Mon, 6 May 2013 15:04:28 -0700 (PDT) Received: from mail-qa0-x22f.google.com (mail-qa0-x22f.google.com [IPv6:2607:f8b0:400d:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 311E821F9376 for ; Mon, 6 May 2013 15:04:28 -0700 (PDT) Received: by mail-qa0-f47.google.com with SMTP id i13so1767813qae.20 for ; Mon, 06 May 2013 15:04:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=L7LKMQ7kGaMqTIkBdOnwMKk2Io3QXpbRJ93F5E30ExY=; b=l9pvSAjC5+JzPwavPkRHXWg6PE9zt4BMfIIW1ZDYm1b838zMZPus2fBlTswRn1cZub H56SX3IWs0Vvn0Zyc1L+oolaMfwSc9qaFNosi/vZx1g7Jb8DIbmNVESuWACB+vTks03r SNy0VQ5tpEBjVq9UpNc3pkT6VykEOa+6A1MjhTtk/1d81oOwIIGjtVbexOmvPZsPHiT8 RMFTChtMjS/jebPBIlvqtSTS5lLk7EAbXRNXKRhgt13z9S7tZY6+Il+CJKWL91fETQEt sjOQA4oNYqfJFCKYK1dCck9zXzmzNolxTzz9KyWvmdibSgLmPIkCg/gX97Oobiu7+ZUS +DyQ== X-Received: by 10.49.39.68 with SMTP id n4mr29272680qek.44.1367877867552; Mon, 06 May 2013 15:04:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.81.175 with HTTP; Mon, 6 May 2013 15:04:07 -0700 (PDT) In-Reply-To: <201305062200.r46M0wjP4269356@shell01.TheWorld.com> References: <339625C1-F16E-429F-BA62-066F6F6B3B51@edvina.net> <6360A039-E87A-4872-A480-587FC9F84D2F@edvina.net> <201305021842.r42Ig2DO3979809@shell01.TheWorld.com> <201305030115.r431FRoS4006275@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C36B55D@ESESSMB209.ericsson.se> <201305031801.r43I1cSY4050203@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C36B7BA@ESESSMB209.ericsson.se> <201305062200.r46M0wjP4269356@shell01.TheWorld.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 7 May 2013 00:04:07 +0200 Message-ID: To: "Dale R. Worley" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlxWVEJWksMPnP3G0V/Y8oWfAvbXAqLXUInd6AZpEsGsXmc4l6QddS9CVDPd/aaa8GbDIFf Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP outbound and in-dialog requests X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 22:04:28 -0000 2013/5/7 Dale R. Worley : > In-dialog requests need to traverse *an* edge proxy, but (in order to > arrive), they needn't always traverse the *same* edge proxy. As long > as the final URI is a GRUU for the UA, there is enough information in > the request to allow successful routing, even if new flows are > established. But 3261 requires the edge proxy used in the > dialog-forming request to always be in the path. So we have a problem? or not? :) Please let me focus on the issue described in my two previous mails: the registrar performs GRUU for an in-dialog request so the request gets a *NEW* Route header (which is added to the Route headers already present in the request due to the route set). -- I=C3=B1aki Baz Castillo From christer.holmberg@ericsson.com Tue May 7 01:35:10 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EC8D21F8FDC for ; Tue, 7 May 2013 01:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SBNSZgiOb17C for ; Tue, 7 May 2013 01:35:03 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 1F05B21F8E96 for ; Tue, 7 May 2013 01:35:02 -0700 (PDT) X-AuditID: c1b4fb25-b7f396d000007d06-31-5188bcb5aa24 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 98.2C.32006.5BCB8815; Tue, 7 May 2013 10:35:02 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.02.0328.009; Tue, 7 May 2013 10:35:01 +0200 From: Christer Holmberg To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , "Dale R. Worley" Thread-Topic: [dispatch] SIP outbound and in-dialog requests Thread-Index: AQHOR5uxaZW6BfvFUkyNBG2wEi4qB5jzclcwgABPfmKAABoxwoAE3z2Q///fQICAAM6HUA== Date: Tue, 7 May 2013 08:35:01 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C36C7C8@ESESSMB209.ericsson.se> References: <339625C1-F16E-429F-BA62-066F6F6B3B51@edvina.net> <6360A039-E87A-4872-A480-587FC9F84D2F@edvina.net> <201305021842.r42Ig2DO3979809@shell01.TheWorld.com> <201305030115.r431FRoS4006275@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C36B55D@ESESSMB209.ericsson.se> <201305031801.r43I1cSY4050203@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C36B7BA@ESESSMB209.ericsson.se> <201305062200.r46M0wjP4269356@shell01.TheWorld.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.20] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrELMWRmVeSWpSXmKPExsUyM+Jvre62PR2BBg/PslksnbSA1WL6PhuL lyfKHJg9zjW8Z/eYvP8rs8eSJT+ZApijuGxSUnMyy1KL9O0SuDJez1zPVjBNtGLWu5ssDYwX RLoYOTkkBEwkzs3pYoewxSQu3FvP1sXIxSEkcJhR4s2m54wQzmJGiRvvtgBlODjYBCwkuv9p gzSICKRK/DvfDNbMLKAt8f/6OkYQW1jAWuLLoXY2iBobiWN7QeIcQHaYxJH9dSBhFgEViW/L r4G18gr4Stx894cdYtVjdomt114zgyQ4BQIlnrdOB5vJCHTc91NrmCB2iUvcejKfCeJoAYkl e84zQ9iiEi8f/2OFsBUlrk5fzgSyl1lAU2L9Ln2IVkWJKd0PofYKSpyc+YRlAqPYLCRTZyF0 zELSMQtJxwJGllWM7LmJmTnp5UabGIHxcnDLb9UdjHfOiRxilOZgURLnTeZqDBQSSE8sSc1O TS1ILYovKs1JLT7EyMTBKdXAmHTmYtZGue0PVP2LnjgYCPDNfN/YdbZV89LB/ZHV/KIZLot/ KcxZXxtpMWtrftGjtuX5m20/F7e5v7lyo2hN3QwxTdNZ/Gt9olUf+BQ2cLv45s2Ka1pS8f2Y wXe+dWImnr+/T+e+X3U8MDVF35SZt0nRsHLqsYQTBjdPpUU32L7JnN4d8u+qEktxRqKhFnNR cSIAWOHPBmUCAAA= Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP outbound and in-dialog requests X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 08:35:10 -0000 SGksDQoNCk9uZSBvZiB0aGUgYXJndW1lbnRzIGhhdmUgYmVlbiB0aGF0IHRoZSBVQSB3b24ndCBz ZWUgdGhlIGNoYW5nZWQgcm91dGUgc2V0LCBhcyB0aGUgUm91dGUgaGVhZGVycyBhcmUgcmVtb3Zl ZCBmcm9tIHJlcXVlc3RzIHNlbnQgdG93YXJkcyB0aGUgVUEuDQoNCkJ1dCwgYW5kIEkgYmVsaWV2 ZSB0aGlzIHdhcyBhbHNvIGluZGljYXRlZCwgdGhlIFVBIG1heSBhbHNvIFNFTkQgcmVxdWVzdHMg LSBzbyBpdCB3b3VsZCBuZWVkIHRvIHVwZGF0ZSBpdHMgb3duIHJvdXRlIHNldCBhbHNvLg0KDQpO b3csIGV2ZW50aG91Z2ggaXQgYnJlYWtzIFJGQyAzMjYxLCBpdCBjYW4gcHJvYmFibHkgYmUgbWFk ZSB0byB3b3JrIGluIHNvbWUgc2NlbmFyaW9zLg0KDQpIb3dldmVyLCB0aGVyZSBhcmUgb3RoZXIg YXNwZWN0cyB0aGF0IG5lZWQgdG8gYmUgY29uc2lkcmVkLg0KDQoxKSBUaGVyZSBtaWdodCBiZSBv dGhlciBpbnRlcm1lZGlhcmllcyB0aGFuIHRoZSBlZGdlIHByb3h5IGJldHdlZW4gdGhlIFVBIGFu ZCByZWdpc3RyYXIuIFNvbWUgb2YgdGhvc2UgbWlnaHQgYmUgc3RhdGVmdWwuDQoNCjIpIFRoZXJl IG1pZ2h0IGJlIGludGVybWVkaWFyaWVzIHRoYXQgYW5jaG9yIHRoZSBtZWRpYS4gVGhlIG1lZGlh IHBhdGggd2lsbCBub3QgY2hhbmdlIGp1c3QgYmVjYXVzZSB5b3Ugc3dpdGNoIHNpZ25hbGluZyBy b3V0ZSBzZXQuDQoNCjMpIFRoZSBVQSBtYXkgaGF2ZSBuZWdvdGlhdGVkIHRoZSBzZW5kaW5nIG9m IGtlZXAtYWxpdmVzLCBlaXRoZXIgb24gdGhlIHJlZ2lzdHJhdGlvbi0gb3IgdGhlIGRpYWxvZyBs ZXZlbCwgYW5kIHRoZXJlIG1pZ2h0IGJlIGludGVybWVkaWFyaWVzIHRoYXQgZS5nLiB0cmlnZ2Vy IHNlc3Npb24gcmVsZWFzZSBpZiB0aG9zZSBrZWVwLWFsaXZlcyBkb24ndCBhcnJpdmUuDQoNCkV0 YyBldGMuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQpGcm9tOiBJw7Fha2kgQmF6IENhc3RpbGxvIFttYWlsdG86aWJjQGFsaWF4Lm5l dF0gDQpTZW50OiA3LiB0b3Vrb2t1dXRhIDIwMTMgMTowNA0KVG86IERhbGUgUi4gV29ybGV5DQpD YzogQ2hyaXN0ZXIgSG9sbWJlcmc7IGRpc3BhdGNoQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW2Rp c3BhdGNoXSBTSVAgb3V0Ym91bmQgYW5kIGluLWRpYWxvZyByZXF1ZXN0cw0KDQoyMDEzLzUvNyBE YWxlIFIuIFdvcmxleSA8d29ybGV5QGFyaWFkbmUuY29tPjoNCj4gSW4tZGlhbG9nIHJlcXVlc3Rz IG5lZWQgdG8gdHJhdmVyc2UgKmFuKiBlZGdlIHByb3h5LCBidXQgKGluIG9yZGVyIHRvIA0KPiBh cnJpdmUpLCB0aGV5IG5lZWRuJ3QgYWx3YXlzIHRyYXZlcnNlIHRoZSAqc2FtZSogZWRnZSBwcm94 eS4gIEFzIGxvbmcgDQo+IGFzIHRoZSBmaW5hbCBVUkkgaXMgYSBHUlVVIGZvciB0aGUgVUEsIHRo ZXJlIGlzIGVub3VnaCBpbmZvcm1hdGlvbiBpbiANCj4gdGhlIHJlcXVlc3QgdG8gYWxsb3cgc3Vj Y2Vzc2Z1bCByb3V0aW5nLCBldmVuIGlmIG5ldyBmbG93cyBhcmUgDQo+IGVzdGFibGlzaGVkLiAg QnV0IDMyNjEgcmVxdWlyZXMgdGhlIGVkZ2UgcHJveHkgdXNlZCBpbiB0aGUgDQo+IGRpYWxvZy1m b3JtaW5nIHJlcXVlc3QgdG8gYWx3YXlzIGJlIGluIHRoZSBwYXRoLg0KDQpTbyB3ZSBoYXZlIGEg cHJvYmxlbT8gb3Igbm90PyA6KQ0KDQpQbGVhc2UgbGV0IG1lIGZvY3VzIG9uIHRoZSBpc3N1ZSBk ZXNjcmliZWQgaW4gbXkgdHdvIHByZXZpb3VzIG1haWxzOg0KdGhlIHJlZ2lzdHJhciBwZXJmb3Jt cyBHUlVVIGZvciBhbiBpbi1kaWFsb2cgcmVxdWVzdCBzbyB0aGUgcmVxdWVzdCBnZXRzIGEgKk5F VyogUm91dGUgaGVhZGVyICh3aGljaCBpcyBhZGRlZCB0byB0aGUgUm91dGUgaGVhZGVycyBhbHJl YWR5IHByZXNlbnQgaW4gdGhlIHJlcXVlc3QgZHVlIHRvIHRoZSByb3V0ZSBzZXQpLg0KDQoNCi0t DQpJw7Fha2kgQmF6IENhc3RpbGxvDQo8aWJjQGFsaWF4Lm5ldD4NCg== From ibc@aliax.net Tue May 7 02:21:23 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A58F21F8F0A for ; Tue, 7 May 2013 02:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pgML3x9TVZ5k for ; Tue, 7 May 2013 02:21:21 -0700 (PDT) Received: from mail-qc0-x234.google.com (mail-qc0-x234.google.com [IPv6:2607:f8b0:400d:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id E18C821F8EFD for ; Tue, 7 May 2013 02:21:19 -0700 (PDT) Received: by mail-qc0-f180.google.com with SMTP id a10so156187qcx.39 for ; Tue, 07 May 2013 02:21:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=Eu3SsKu1lKnYh7qJe6YaJQcWXQ2r2ctuutA5kp/Dt28=; b=O3Fj0osTpkcZPniyqlGajrqDEM6JvWBrHDwbeh67OGV1ur2Sn+kGK5hNYO0UCQGb2l M8JvufaVZF5XZQ/J0PwNjB9094AefAUa2mBL5pIDKzAlCRrDfiu4naB/JKMsgI7ADhHW nzcqS7ezH7qRbG1/CRNT4Upg+hMgd3tWkgyPDIQkLCKmT7wXosU9r94PF1tC5zRA/fYA 2ZPF/ESTQCu8w5a2Az095/XOUwpt4Hei0/0BefRl65GuskKYiFyfJc4vz6+/OajI/9MA dAPRf51jMD/+VfTXqZPGAhrtfZoLFWtZwUhbnArQ5GZ1Rov6rnbXYkQSKqflONYIOAqj qKVQ== X-Received: by 10.224.66.136 with SMTP id n8mr1053003qai.84.1367918479264; Tue, 07 May 2013 02:21:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.81.175 with HTTP; Tue, 7 May 2013 02:20:59 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C36C7C8@ESESSMB209.ericsson.se> References: <339625C1-F16E-429F-BA62-066F6F6B3B51@edvina.net> <6360A039-E87A-4872-A480-587FC9F84D2F@edvina.net> <201305021842.r42Ig2DO3979809@shell01.TheWorld.com> <201305030115.r431FRoS4006275@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C36B55D@ESESSMB209.ericsson.se> <201305031801.r43I1cSY4050203@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C36B7BA@ESESSMB209.ericsson.se> <201305062200.r46M0wjP4269356@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C36C7C8@ESESSMB209.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 7 May 2013 11:20:59 +0200 Message-ID: To: "dispatch@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkt8401I/9yp8wScpCvrjz0M6hUdCNRJZ7AjGDHfaXWXajf7OlwTpw7zFaI+f9nS7xOcYin Subject: Re: [dispatch] SIP outbound and in-dialog requests X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 09:21:24 -0000 2013/5/7 Christer Holmberg : > But, and I believe this was also indicated, the UA may also SEND requests= - so it would need to update its own route set also. No, it's not needed. The UA will still indicate GRUU in its Contact so the registrar will do lookup and also "replace" the existing old Route header with the new one retrieved from the new Path (if there was an Edge proxy). Anyhow, it seems that nobody wants to reply to the problem I describe. Is it not clear? Let me re-explain it: ****************************************************** PLEASE FOLKS READ AND REPLY BELOW ****************************************************** Scenario: --------------------------------------------------------- Alice --- REGISTRAR --- EDGE --- Bob --------------------------------------------------------- - Bob registers with GRUU and Outbound. EDGE adds Path: Path: - Alice calls Bob. Once the call is established, the route set from Alice is as follows: Route: Route: - So an in-dialog INFO from Alice looks as follows: INFO sip:bob@biloxi.com;gr=3DGRUU_1 Route: Route: - When the INFO arrives to the REGISTRAR, the REGISTRAR MUST perform GRUU lookup, RIGHT?? - So the REGISTRAR retrieves the Bob binding which includes Path above (to be converted into Route header), but such a Route header is ALREADY present in the INFO due to previous and common record-routing. So the REGISTRAR: - Must DELETE the Route pointing to next node (EDGE). - And MUST add the Route retrieved from the Path. - YES OR NOT PLEASE??? - Then the INFO arrives to EDGE as follows: INFO sip:bob@BOB_IP Route: - Later during the dialog, Bob is disconnected so reconnects to EDGE and re-registers. Now a new Outbound Flow Token is generated and added to the Path header by EDGE: Path: - Alice sends BYE to Bob: BYE sip:bob@biloxi.com;gr=3DGRUU_1 Route: Route: - The REGISTRAR does GRUU lookup and retrieves the new Path that must be added as a new Route: - The REGISTRAR removes the Route pointint to EDGE: Route: - And adds a new one based on the new Path of Bob: Route: - So the BYE arriving to EDGE is: BYE sip:bob@BOB_IP Route: - ...which is properly routed to Bob via the new connection. And no need for Alice and Bob to change the dialog route set. Ok folks, please HELP ME, I cannot describe the problem in a better way. Do you see the ugly play with Route headers above? the REGISTRAR must remove a Route header that points to the next node (EDGE proxy) before REGISTRAR adds the Route mirrored from the Path !!!! - How is supposed that a proxy can be able to remove Route headers belonging to proxies located after it?? - Is GRUU broken? - Can GRUU work with in-dialog request or not? -- I=C3=B1aki Baz Castillo From christer.holmberg@ericsson.com Tue May 7 02:33:57 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B967821F8F0D for ; Tue, 7 May 2013 02:33:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.024 X-Spam-Level: X-Spam-Status: No, score=-6.024 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B4mVuz9BKW4r for ; Tue, 7 May 2013 02:33:51 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id EA35221F8EFD for ; Tue, 7 May 2013 02:33:50 -0700 (PDT) X-AuditID: c1b4fb30-b7f3a6d0000007a4-af-5188ca7d8b63 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 0B.93.01956.D7AC8815; Tue, 7 May 2013 11:33:49 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.02.0328.009; Tue, 7 May 2013 11:33:49 +0200 From: Christer Holmberg To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , "dispatch@ietf.org" Thread-Topic: [dispatch] SIP outbound and in-dialog requests Thread-Index: AQHOR5uxaZW6BfvFUkyNBG2wEi4qB5jzclcwgABPfmKAABoxwoAE3z2Q///fQICAAM6HUP//7paAgAAkpuA= Date: Tue, 7 May 2013 09:33:48 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C36C867@ESESSMB209.ericsson.se> References: <339625C1-F16E-429F-BA62-066F6F6B3B51@edvina.net> <6360A039-E87A-4872-A480-587FC9F84D2F@edvina.net> <201305021842.r42Ig2DO3979809@shell01.TheWorld.com> <201305030115.r431FRoS4006275@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C36B55D@ESESSMB209.ericsson.se> <201305031801.r43I1cSY4050203@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C36B7BA@ESESSMB209.ericsson.se> <201305062200.r46M0wjP4269356@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C36C7C8@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrGLMWRmVeSWpSXmKPExsUyM+JvrW7tqY5Ag+4jxhZLJy1gtZi+z8Zi 4fLNTBYvVx9itnh5osyB1eNcw3t2j8n7vzJ7TFu7ktVjyZKfTB5737UxBrBGcdmkpOZklqUW 6dslcGWcezGNqeCURsXO/p9MDYxH1LsYOTkkBEwk9rzawQZhi0lcuLceyObiEBI4zCjR3P6F FcJZzChx5d51IIeDg03AQqL7nzZIg4hAusS3K8eYQWxmgVqJ/k1NYIOEBawlvhxqZ4OosZE4 tncdI4SdJPHk6iwWkDEsAioSrdP4QcK8Ar4SH5etZIJY9Y5D4vnT46wgCU6BQIlvU9awgNiM QMd9P7WGCWKXuMStJ/OZII4WkFiy5zwzhC0q8fLxP1YIW1Hi6vTlTCC7mAU0Jdbv0odoVZSY 0v2QHWKvoMTJmU9YJjCKzUIydRZCxywkHbOQdCxgZFnFyJ6bmJmTXm6+iREYVwe3/DbYwbjp vtghRmkOFiVx3mSuxkAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjGF/KjPOLVzGazaz+69l bELpJ9NjkoGfjqUkzdx2bWvNkdmuTs94L6pfPPldb+e5CS216cYChVNs36087x96yPe5Vsnc ArE5ZsWzeT+fZ99z/cv+3cszzXct4rHN80t8M7Ot3Cj/oC+j+p3dexrbJjCxMbx7KRP0jHnl H9VVki+uF8Xyx+2WS1BiKc5INNRiLipOBABos0GYeQIAAA== Subject: Re: [dispatch] SIP outbound and in-dialog requests X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 09:33:57 -0000 SGksDQoNCkkgd2lsbCBsb29rIGludG8geW91ciBsYXRlc3QgcmVwbHkgbGF0ZXIsIGJ1dCBpbiBn ZW5lcmFsOiB3aGlsZSB0aGUgU0lQIHByb3RvY29sIGltcGFjdHMgb2YgdGhpcyBhcmUgZGlzY3Vz c2VkLCBJIHRoaW5rIHRoaXMgZGlzY3Vzc2lvbiBzaG91bGQgdGFrZSBwbGFjZSBvbiB0aGUgU0lQ Q09SRSBsaXN0IDopDQoNClRoZW4sIGlmIHRoZXJlIGlzIGEgc3VnZ2VzdGlvbiB0byBzdGFydCBz b21lIG5ldyB3b3JrLCB0aGF0IGNhbiBiZSBicm91Z2h0IHRvIERJU1BUQUNILg0KDQpSZWdhcmRz LA0KDQpDaHJpc3Rlcg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBJw7Fh a2kgQmF6IENhc3RpbGxvIFttYWlsdG86aWJjQGFsaWF4Lm5ldF0gDQpTZW50OiA3LiB0b3Vrb2t1 dXRhIDIwMTMgMTI6MjENClRvOiBkaXNwYXRjaEBpZXRmLm9yZw0KQ2M6IERhbGUgUi4gV29ybGV5 OyBDaHJpc3RlciBIb2xtYmVyZzsgT2xsZSBFIEpvaGFuc3NvbjsgS2xhdXMgRGFyaWxpb24NClN1 YmplY3Q6IFJlOiBbZGlzcGF0Y2hdIFNJUCBvdXRib3VuZCBhbmQgaW4tZGlhbG9nIHJlcXVlc3Rz DQoNCjIwMTMvNS83IENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nv bi5jb20+Og0KPiBCdXQsIGFuZCBJIGJlbGlldmUgdGhpcyB3YXMgYWxzbyBpbmRpY2F0ZWQsIHRo ZSBVQSBtYXkgYWxzbyBTRU5EIHJlcXVlc3RzIC0gc28gaXQgd291bGQgbmVlZCB0byB1cGRhdGUg aXRzIG93biByb3V0ZSBzZXQgYWxzby4NCg0KTm8sIGl0J3Mgbm90IG5lZWRlZC4gVGhlIFVBIHdp bGwgc3RpbGwgaW5kaWNhdGUgR1JVVSBpbiBpdHMgQ29udGFjdCBzbyB0aGUgcmVnaXN0cmFyIHdp bGwgZG8gbG9va3VwIGFuZCBhbHNvICJyZXBsYWNlIiB0aGUgZXhpc3Rpbmcgb2xkIFJvdXRlIGhl YWRlciB3aXRoIHRoZSBuZXcgb25lIHJldHJpZXZlZCBmcm9tIHRoZSBuZXcgUGF0aCAoaWYgdGhl cmUgd2FzIGFuIEVkZ2UgcHJveHkpLg0KDQpBbnlob3csIGl0IHNlZW1zIHRoYXQgbm9ib2R5IHdh bnRzIHRvIHJlcGx5IHRvIHRoZSBwcm9ibGVtIEkgZGVzY3JpYmUuDQpJcyBpdCBub3QgY2xlYXI/ IExldCBtZSByZS1leHBsYWluIGl0Og0KDQoNCioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKg0KUExFQVNFIEZPTEtTIFJFQUQgQU5EIFJFUExZIEJF TE9XDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioNCg0KDQoNClNjZW5hcmlvOg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkFsaWNlIC0tLSBSRUdJU1RSQVIgLS0tIEVER0UgLS0t IEJvYg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQoNCg0KLSBCb2IgcmVnaXN0ZXJzIHdpdGggR1JVVSBhbmQgT3V0Ym91bmQuIEVER0Ug YWRkcyBQYXRoOg0KDQogICBQYXRoOiA8c2lwOkZMT1dfVE9LRU5fMUBFREdFO2xyPg0KDQoNCi0g QWxpY2UgY2FsbHMgQm9iLiBPbmNlIHRoZSBjYWxsIGlzIGVzdGFibGlzaGVkLCB0aGUgcm91dGUg c2V0IGZyb20gQWxpY2UgaXMgYXMgZm9sbG93czoNCg0KICBSb3V0ZTogPHNpcDpSRUdJU1RSQVI7 bHI+DQogIFJvdXRlOiA8c2lwOkZMT1dfVE9LRU5fMUBFREdFO2xyPg0KDQotIFNvIGFuIGluLWRp YWxvZyBJTkZPIGZyb20gQWxpY2UgbG9va3MgYXMgZm9sbG93czoNCg0KICBJTkZPIHNpcDpib2JA Ymlsb3hpLmNvbTtncj1HUlVVXzENCiAgUm91dGU6IDxzaXA6UkVHSVNUUkFSO2xyPg0KICBSb3V0 ZTogPHNpcDpGTE9XX1RPS0VOXzFARURHRTtscj4NCg0KLSBXaGVuIHRoZSBJTkZPIGFycml2ZXMg dG8gdGhlIFJFR0lTVFJBUiwgdGhlIFJFR0lTVFJBUiBNVVNUIHBlcmZvcm0gR1JVVSBsb29rdXAs IFJJR0hUPz8NCg0KLSBTbyB0aGUgUkVHSVNUUkFSIHJldHJpZXZlcyB0aGUgQm9iIGJpbmRpbmcg d2hpY2ggaW5jbHVkZXMgUGF0aCBhYm92ZSAodG8gYmUgY29udmVydGVkIGludG8gUm91dGUgaGVh ZGVyKSwgYnV0IHN1Y2ggYSBSb3V0ZSBoZWFkZXIgaXMgQUxSRUFEWSBwcmVzZW50IGluIHRoZSBJ TkZPIGR1ZSB0byBwcmV2aW91cyBhbmQgY29tbW9uIHJlY29yZC1yb3V0aW5nLg0KU28gdGhlIFJF R0lTVFJBUjoNCg0KICAtIE11c3QgREVMRVRFIHRoZSBSb3V0ZSBwb2ludGluZyB0byBuZXh0IG5v ZGUgKEVER0UpLg0KICAtIEFuZCBNVVNUIGFkZCB0aGUgUm91dGUgcmV0cmlldmVkIGZyb20gdGhl IFBhdGguDQoNCi0gWUVTIE9SIE5PVCBQTEVBU0U/Pz8NCg0KLSBUaGVuIHRoZSBJTkZPIGFycml2 ZXMgdG8gRURHRSBhcyBmb2xsb3dzOg0KDQogIElORk8gc2lwOmJvYkBCT0JfSVANCiAgUm91dGU6 IDxzaXA6RkxPV19UT0tFTl8xQEVER0U7bHI+DQoNCg0KLSBMYXRlciBkdXJpbmcgdGhlIGRpYWxv ZywgQm9iIGlzIGRpc2Nvbm5lY3RlZCBzbyByZWNvbm5lY3RzIHRvIEVER0UgYW5kIHJlLXJlZ2lz dGVycy4gTm93IGEgbmV3IE91dGJvdW5kIEZsb3cgVG9rZW4gaXMgZ2VuZXJhdGVkIGFuZCBhZGRl ZCB0byB0aGUgUGF0aCBoZWFkZXIgYnkgRURHRToNCg0KICBQYXRoOiA8c2lwOkZMT1dfVE9LRU5f MkBFREdFO2xyPg0KDQotIEFsaWNlIHNlbmRzIEJZRSB0byBCb2I6DQoNCiAgQllFIHNpcDpib2JA Ymlsb3hpLmNvbTtncj1HUlVVXzENCiAgUm91dGU6IDxzaXA6UkVHSVNUUkFSO2xyPg0KICBSb3V0 ZTogPHNpcDpGTE9XX1RPS0VOXzFARURHRTtscj4NCg0KLSBUaGUgUkVHSVNUUkFSIGRvZXMgR1JV VSBsb29rdXAgYW5kIHJldHJpZXZlcyB0aGUgbmV3IFBhdGggdGhhdCBtdXN0IGJlIGFkZGVkIGFz IGEgbmV3IFJvdXRlOg0KDQogIC0gVGhlIFJFR0lTVFJBUiByZW1vdmVzIHRoZSBSb3V0ZSBwb2lu dGludCB0byBFREdFOg0KICAgICAgUm91dGU6IDxzaXA6RkxPV19UT0tFTl8xQEVER0U7bHI+DQog IC0gQW5kIGFkZHMgYSBuZXcgb25lIGJhc2VkIG9uIHRoZSBuZXcgUGF0aCBvZiBCb2I6DQogICAg ICBSb3V0ZTogPHNpcDpGTE9XX1RPS0VOXzJARURHRTtscj4NCg0KLSBTbyB0aGUgQllFIGFycml2 aW5nIHRvIEVER0UgaXM6DQoNCiAgQllFIHNpcDpib2JAQk9CX0lQDQogIFJvdXRlOiA8c2lwOkZM T1dfVE9LRU5fMkBFREdFO2xyPg0KDQotIC4uLndoaWNoIGlzIHByb3Blcmx5IHJvdXRlZCB0byBC b2IgdmlhIHRoZSBuZXcgY29ubmVjdGlvbi4gQW5kIG5vIG5lZWQgZm9yIEFsaWNlIGFuZCBCb2Ig dG8gY2hhbmdlIHRoZSBkaWFsb2cgcm91dGUgc2V0Lg0KDQoNCg0KT2sgZm9sa3MsIHBsZWFzZSBI RUxQIE1FLCBJIGNhbm5vdCBkZXNjcmliZSB0aGUgcHJvYmxlbSBpbiBhIGJldHRlciB3YXkuIERv IHlvdSBzZWUgdGhlIHVnbHkgcGxheSB3aXRoIFJvdXRlIGhlYWRlcnMgYWJvdmU/IHRoZSBSRUdJ U1RSQVIgbXVzdCByZW1vdmUgYSBSb3V0ZSBoZWFkZXIgdGhhdCBwb2ludHMgdG8gdGhlIG5leHQg bm9kZSAoRURHRSBwcm94eSkgYmVmb3JlIFJFR0lTVFJBUiBhZGRzIHRoZSBSb3V0ZSBtaXJyb3Jl ZCBmcm9tIHRoZSBQYXRoICEhISENCg0KLSBIb3cgaXMgc3VwcG9zZWQgdGhhdCBhIHByb3h5IGNh biBiZSBhYmxlIHRvIHJlbW92ZSBSb3V0ZSBoZWFkZXJzIGJlbG9uZ2luZyB0byBwcm94aWVzIGxv Y2F0ZWQgYWZ0ZXIgaXQ/Pw0KLSBJcyBHUlVVIGJyb2tlbj8NCi0gQ2FuIEdSVVUgd29yayB3aXRo IGluLWRpYWxvZyByZXF1ZXN0IG9yIG5vdD8NCg0KDQoNCg0KDQoNCg0KDQoNCi0tDQpJw7Fha2kg QmF6IENhc3RpbGxvDQo8aWJjQGFsaWF4Lm5ldD4NCg== From hugh.waite@crocodile-rcs.com Tue May 7 02:51:51 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A49021F8D2C for ; Tue, 7 May 2013 02:51:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I37Cs8J7aNXD for ; Tue, 7 May 2013 02:51:27 -0700 (PDT) Received: from oproxy6-pub.bluehost.com (oproxy6-pub.bluehost.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id 82C9E21F8766 for ; Tue, 7 May 2013 02:51:25 -0700 (PDT) Received: (qmail 17222 invoked by uid 0); 7 May 2013 09:51:01 -0000 Received: from unknown (HELO just121.justhost.com) (173.254.28.121) by cpoproxy3.bluehost.com with SMTP; 7 May 2013 09:51:01 -0000 Received: from [90.152.0.102] (port=54374 helo=[192.168.0.185]) by just121.justhost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.80) (envelope-from ) id 1UZeY0-0000Pg-FZ for dispatch@ietf.org; Tue, 07 May 2013 03:51:00 -0600 Message-ID: <5188CE78.100@crocodile-rcs.com> Date: Tue, 07 May 2013 10:50:48 +0100 From: Hugh Waite Organization: Crocodile RCS Ltd. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: dispatch@ietf.org References: <339625C1-F16E-429F-BA62-066F6F6B3B51@edvina.net> <6360A039-E87A-4872-A480-587FC9F84D2F@edvina.net> <201305021842.r42Ig2DO3979809@shell01.TheWorld.com> <51875CDA.6020800@pernau.at> <7594FB04B1934943A5C02806D1A2204B1C36BE0E@ESESSMB209.ericsson.se> <59D83BB5-1EE1-421E-A1D7-18C772E466B1@edvina.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090504020304080905080704" X-Identified-User: {596:just121.justhost.com:crocodi1:crocodile-rcs.com} {sentby:smtp auth 90.152.0.102 authed with hugh.waite@crocodile-rcs.com} Subject: Re: [dispatch] SIP outbound and in-dialog requests X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 09:51:51 -0000 This is a multi-part message in MIME format. --------------090504020304080905080704 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 06/05/2013 14:44, Iñaki Baz Castillo wrote: > 2013/5/6 Olle E. Johansson : >> It seems to me that Outbound only handles dialog-forming requests, but currently can't handle survival of a dialog between >> two or more flows between the UA and the edge proxy. That's something that needs to be fixed. > Right, let me please simplify this issue with an example: > > > Alice --- REGISTRAR --- EDGE --- Bob > > > - Bob registers with GRUU through EDGE Proxy which performs Path. > > - Alice calls Bob. > > - Bob disconnectes, connects again and sends a new REGISTER. > > - EDGE sets a new outbound flow token in the Path header. The new > binding (with new Path) replaces the previous one in the location DB. > > - Alice sends BYE to Bob. The BYE arrives to REGISTRAR which performs > lookup for the binding of the GRUU URI of the BYE, and retrieves the > new binding of Bob, so adds such a Route to the request, which now > looks as follows: > > BYE sip:bob@billoxi.com;gr=qweasdzxc > Route: (removed by REGISTRAR) > Route: > Route: (removed by REGSISTRAR OR NOT ????) > > - Of course here RFC 3261 is violated since the route set is changed. > However endpoints will not realize of it since EDGE would remove both > remaining Route headers before routing the request to Bob, but for > that to work, REGISTRAR should previously also remove the > EDGE-BOB-OLD-PATH Route header (otherwise EDGE Proxy would try to > route via the old closed connection). > > > Well, we have here a pain of Route headers added by intermediary > proxies within a dialog, which seems ugly. We need a solution: > > > > 1) Is the above allowed by RFC 5626/5627 or not? From RFC 5627 § 6.1: Special considerations apply to the processing of any Path headers stored in the registration (seeRFC 3327 [3 ]). If the received request has Route header field values beyond the one pointing to the authoritative proxy itself (this will happen when the request is a mid-dialog request),*the Path URI MUST be discarded*. This is permitted byRFC 3327 [3 ] as a matter of local policy; usage of GRUUs will require this policy in order to avoid call spirals and likely call failures. From my reading of this, the RFC for GRUUs does not allow changing (or adding to) the route-set mid-dialog. *IF* the registrar were to remove all forward Routes and replace them with a new route-set from the registration, I agree that the request is likely to reach the UA, even if the registration was through a different edge proxy (for example). However, I can think of examples where it is important to make sure that the path being replaced is going directly to the UA, e.g. when there are additional hops added during call setup (media servers, stateful proxies etc). Also, if a UA is forced to use a second connection for an in-dialog request, then the route-set for the dialog will not match, e.g. if the first hop in the new route is a different edge proxy. Does routing traffic in this direction need to be considered at the same time as the main discussion? When a UA detects a lost connection (whether that is signalling, media or moving from a 3G signal to a WiFi signal), the dialog needs to be re-targetted (and/or re-directed) and it may need to renegotiate media. Can something like the 'replaces' mechanism be used to take over the dialog using out-of-dialog requests? Would this work round any of the problems discussed here? Hugh > > 2) How to avoid it? In case a new registration modifies the binding > (including Path header with outbound flow token), nothing prevents the > registrar to use the new binding for an in-dialog request, but it > violates RFC 3261 (route set changed). > > 3) Anyhow endpoints will never see the new Route set so, does this > violate 3261 or not? > > 4) and anyhow... the REGISTRAR (see example above) needs to remove the > Route header pointing to next step before it inserts a new one due to > the binding lookup and Path retrieval. Otherwise the request arrives > to the EDGE proxy with two Route (with Flow-Token) headers pointing to > it. > > > All of this is really unclear. I hope there is an answer that allows a > dialog to remain alive once the NATted TCP connection of an endpoint > is closed during the dialog. Otherwise, nobody cared about mobile > intermittent networks when RFC 5626/5627 were written? > > > > Regards. > > > -- > Iñaki Baz Castillo > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch -- Hugh Waite Principal Design Engineer Crocodile RCS Ltd. --------------090504020304080905080704 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 06/05/2013 14:44, Iñaki Baz Castillo wrote:
2013/5/6 Olle E. Johansson <oej@edvina.net>:

It seems to me that Outbound only handles dialog-forming requests, but currently can't handle survival of a dialog between
two or more flows between the UA and the edge proxy. That's something that needs to be fixed.

Right, let me please simplify this issue with an example:


Alice --- REGISTRAR --- EDGE --- Bob


- Bob registers with GRUU through EDGE Proxy which performs Path.

- Alice calls Bob.

- Bob disconnectes, connects again and sends a new REGISTER.

- EDGE sets a new outbound flow token in the Path header. The new
binding (with new Path) replaces the previous one in the location DB.

- Alice sends BYE to Bob. The BYE arrives to REGISTRAR which performs
lookup for the binding of the GRUU URI of the BYE, and retrieves the
new binding of Bob, so adds such a Route to the request, which now
looks as follows:

  BYE sip:bob@billoxi.com;gr=qweasdzxc
  Route: <sip:REGISTRAR> (removed by REGISTRAR)
  Route: <sip:EDGE-BOB-NEW-PATH>
  Route: <sip:EDGE-BOB-OLD-PATH> (removed by REGSISTRAR OR NOT ????)

- Of course here RFC 3261 is violated since the route set is changed.
However endpoints will not realize of it since EDGE would remove both
remaining Route headers before routing the request to Bob, but for
that to work, REGISTRAR should previously also remove the
EDGE-BOB-OLD-PATH Route header (otherwise EDGE Proxy would try to
route via the old closed connection).


Well, we have here a pain of Route headers added by intermediary
proxies within a dialog, which seems ugly. We need a solution:



1) Is the above allowed by RFC 5626/5627 or not?
From RFC 5627 § 6.1:
   Special considerations apply to the processing of any Path headers
   stored in the registration (see RFC 3327 [3]).  If the received
   request has Route header field values beyond the one pointing to the
   authoritative proxy itself (this will happen when the request is a
   mid-dialog request), the Path URI MUST be discarded.  This is
   permitted by RFC 3327 [3] as a matter of local policy; usage of GRUUs
   will require this policy in order to avoid call spirals and likely
   call failures.
From my reading of this, the RFC for GRUUs does not allow changing (or adding to) the route-set mid-dialog.

*IF* the registrar were to remove all forward Routes and replace them with a new route-set from the registration, I agree that the request is likely to reach the UA, even if the registration was through a different edge proxy (for example). However, I can think of examples where it is important to make sure that the path being replaced is going directly to the UA, e.g. when there are additional hops added during call setup (media servers, stateful proxies etc).

Also, if a UA is forced to use a second connection for an in-dialog request, then the route-set for the dialog will not match, e.g. if the first hop in the new route is a different edge proxy. Does routing traffic in this direction need to be considered at the same time as the main discussion?


When a UA detects a lost connection (whether that is signalling, media or moving from a 3G signal to a WiFi signal), the dialog needs to be re-targetted (and/or re-directed) and it may need to renegotiate media. Can something like the 'replaces' mechanism be used to take over the dialog using out-of-dialog requests? Would this work round any of the problems discussed here?

Hugh


2) How to avoid it? In case a new registration modifies the binding
(including Path header with outbound flow token), nothing prevents the
registrar to use the new binding for an in-dialog request, but it
violates RFC 3261 (route set changed).

3) Anyhow endpoints will never see the new Route set so, does this
violate 3261 or not?

4) and anyhow... the REGISTRAR (see example above) needs to remove the
Route header pointing to next step before it inserts a new one due to
the binding lookup and Path retrieval. Otherwise the request arrives
to the EDGE proxy with two Route (with Flow-Token) headers pointing to
it.


All of this is really unclear. I hope there is an answer that allows a
dialog to remain alive once the NATted TCP connection of an endpoint
is closed during the dialog. Otherwise, nobody cared about mobile
intermittent networks when RFC 5626/5627 were written?



Regards.


--
Iñaki Baz Castillo
<ibc@aliax.net>
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch



-- 
Hugh Waite
Principal Design Engineer
Crocodile RCS Ltd.
--------------090504020304080905080704-- From christer.holmberg@ericsson.com Tue May 7 03:04:22 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C81821F8B2B for ; Tue, 7 May 2013 03:04:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.024 X-Spam-Level: X-Spam-Status: No, score=-6.024 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Oe-AP5PlzV5 for ; Tue, 7 May 2013 03:04:15 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 873EE21F89A5 for ; Tue, 7 May 2013 03:04:09 -0700 (PDT) X-AuditID: c1b4fb30-b7f3a6d0000007a4-e4-5188d1976da8 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id CA.09.01956.791D8815; Tue, 7 May 2013 12:04:08 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.02.0328.009; Tue, 7 May 2013 12:04:07 +0200 From: Christer Holmberg To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , "dispatch@ietf.org" Thread-Topic: [dispatch] SIP outbound and in-dialog requests Thread-Index: AQHOR5uxaZW6BfvFUkyNBG2wEi4qB5jzclcwgABPfmKAABoxwoAE3z2Q///fQICAAM6HUP//7paAgAAr4BA= Date: Tue, 7 May 2013 10:04:07 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C36C8C7@ESESSMB209.ericsson.se> References: <339625C1-F16E-429F-BA62-066F6F6B3B51@edvina.net> <6360A039-E87A-4872-A480-587FC9F84D2F@edvina.net> <201305021842.r42Ig2DO3979809@shell01.TheWorld.com> <201305030115.r431FRoS4006275@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C36B55D@ESESSMB209.ericsson.se> <201305031801.r43I1cSY4050203@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C36B7BA@ESESSMB209.ericsson.se> <201305062200.r46M0wjP4269356@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C36C7C8@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrGLMWRmVeSWpSXmKPExsUyM+Jvre6Mix2BBo0bWSyWTlrAajF9n43F wuWbmSxerj7EbPHyRJkDq8e5hvfsHpP3f2X2mLZ2JavHkiU/mTz2vmtjDGCN4rJJSc3JLEst 0rdL4MpYdHoiW8ER7YpN0/6wNzBu0epi5OSQEDCR+P7xEBOELSZx4d56ti5GLg4hgcOMEnda 5kA5ixkltmx8BlTFwcEmYCHR/U8bpEFEIF3i25VjzCA2s0CtRP+mJjYQW1jAWuLLoXY2iBob iWN71zFC2EkSU3csZAcZwyKgIjHzPT9ImFfAV2Lp9ensEKvecUg8f3qcFSTBKRAo8W3KGhYQ mxHouO+n1jBB7BKXuPVkPtTRAhJL9pxnhrBFJV4+/scKYStKXJ2+HOxkZgFNifW79CFaFSWm dD9kh9grKHFy5hOWCYxis5BMnYXQMQtJxywkHQsYWVYxsucmZuakl5tvYgTG1cEtvw12MG66 L3aIUZqDRUmcN5mrMVBIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDY7Hv+d/vVM92CX9boDMp /8XEjfY/5LzsthUfC9B40BlpzWD9wUx481uFi/dX37ihHrv9p1Yyt80el1/s5xk+pHbni0l/ MN8R175lgSt/zJopKpc4GN82s0pyr/6WHLO4d9HGbYeeaWe2ivSuTo0PinvflN71dOGHrNbG 5HNcx5Js7pw6mdb6VomlOCPRUIu5qDgRADKdsYl5AgAA Subject: Re: [dispatch] SIP outbound and in-dialog requests X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 10:04:22 -0000 SGksDQoNCllvdXIgZXhhbXBsZSBiZWxvdyBvbmx5IHNob3dzIHJlcXVlc3RzIHNlbnQgZnJvbSBB bGljZS4gQW5kLCB0cnVlLCBCb2Igd2lsbCBub3Qgc2VlIHRoYXQgYSBkaWZmZXJlbnQgcm91dGUg c2V0IGlzIHVzZWQsIGFzIHRoZSBSb3V0ZSBoZWFkZXJzIGFyZSByZW1vdmVkIG9uIHRoZSBwYXRo IChvZiBjb3Vyc2UsIHRoZSBWaWEgaGVhZGVycyB3aWxsIGJlIGRpZmZlcmVudCwgYnV0IEkgZG91 YnQgd2lsbCBzdG9yZSBhbmQgY29tcGFyZSB0aGVtKS4NCg0KQnV0LCBteSBjb21tZW50IHdhcyBh Ym91dCB3aGVuL2lmIEJvYiBzZW5kcyBhbiBpbi1kaWFsb2cgcmVxdWVzdCAoSU5GTywgQllFLCBv ciB3aGF0ZXZlcikuDQoNCkkgYW0gbm90IHJlYWxseSBzdXJlIHdoYXQgeW91IG1lYW4gYnkgR1JV VSAiYmVpbmcgYnJva2VuIi4gSW4gdGhlIHNhbWUgd2F5IGFzIE91dGJvdW5kLCBHUlVVIHdhcyBk ZXNpZ25lZCB3aXRoIGluaXRpYWwgZGlhbG9nIHJlcXVlc3RzIChvciBzdGFuZC1hbG9uZSByZXF1 ZXN0cykgaW4gbWluZCwgbm90IG1pZC1kaWFsb2cgcmVxdWVzdHMuDQoNClJlZ2FyZHMsDQoNCkNo cmlzdGVyDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEnDsWFraSBCYXog Q2FzdGlsbG8gW21haWx0bzppYmNAYWxpYXgubmV0XSANClNlbnQ6IDcuIHRvdWtva3V1dGEgMjAx MyAxMjoyMQ0KVG86IGRpc3BhdGNoQGlldGYub3JnDQpDYzogRGFsZSBSLiBXb3JsZXk7IENocmlz dGVyIEhvbG1iZXJnOyBPbGxlIEUgSm9oYW5zc29uOyBLbGF1cyBEYXJpbGlvbg0KU3ViamVjdDog UmU6IFtkaXNwYXRjaF0gU0lQIG91dGJvdW5kIGFuZCBpbi1kaWFsb2cgcmVxdWVzdHMNCg0KMjAx My81LzcgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT46 DQo+IEJ1dCwgYW5kIEkgYmVsaWV2ZSB0aGlzIHdhcyBhbHNvIGluZGljYXRlZCwgdGhlIFVBIG1h eSBhbHNvIFNFTkQgcmVxdWVzdHMgLSBzbyBpdCB3b3VsZCBuZWVkIHRvIHVwZGF0ZSBpdHMgb3du IHJvdXRlIHNldCBhbHNvLg0KDQpObywgaXQncyBub3QgbmVlZGVkLiBUaGUgVUEgd2lsbCBzdGls bCBpbmRpY2F0ZSBHUlVVIGluIGl0cyBDb250YWN0IHNvIHRoZSByZWdpc3RyYXIgd2lsbCBkbyBs b29rdXAgYW5kIGFsc28gInJlcGxhY2UiIHRoZSBleGlzdGluZyBvbGQgUm91dGUgaGVhZGVyIHdp dGggdGhlIG5ldyBvbmUgcmV0cmlldmVkIGZyb20gdGhlIG5ldyBQYXRoIChpZiB0aGVyZSB3YXMg YW4gRWRnZSBwcm94eSkuDQoNCkFueWhvdywgaXQgc2VlbXMgdGhhdCBub2JvZHkgd2FudHMgdG8g cmVwbHkgdG8gdGhlIHByb2JsZW0gSSBkZXNjcmliZS4NCklzIGl0IG5vdCBjbGVhcj8gTGV0IG1l IHJlLWV4cGxhaW4gaXQ6DQoNCg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqDQpQTEVBU0UgRk9MS1MgUkVBRCBBTkQgUkVQTFkgQkVMT1cNCioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KDQoN Cg0KU2NlbmFyaW86DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KQWxpY2UgLS0tIFJFR0lTVFJBUiAtLS0gRURHRSAtLS0gQm9iDQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cg0KDQotIEJvYiByZWdpc3RlcnMgd2l0aCBHUlVVIGFuZCBPdXRib3VuZC4gRURHRSBhZGRzIFBh dGg6DQoNCiAgIFBhdGg6IDxzaXA6RkxPV19UT0tFTl8xQEVER0U7bHI+DQoNCg0KLSBBbGljZSBj YWxscyBCb2IuIE9uY2UgdGhlIGNhbGwgaXMgZXN0YWJsaXNoZWQsIHRoZSByb3V0ZSBzZXQgZnJv bSBBbGljZSBpcyBhcyBmb2xsb3dzOg0KDQogIFJvdXRlOiA8c2lwOlJFR0lTVFJBUjtscj4NCiAg Um91dGU6IDxzaXA6RkxPV19UT0tFTl8xQEVER0U7bHI+DQoNCi0gU28gYW4gaW4tZGlhbG9nIElO Rk8gZnJvbSBBbGljZSBsb29rcyBhcyBmb2xsb3dzOg0KDQogIElORk8gc2lwOmJvYkBiaWxveGku Y29tO2dyPUdSVVVfMQ0KICBSb3V0ZTogPHNpcDpSRUdJU1RSQVI7bHI+DQogIFJvdXRlOiA8c2lw OkZMT1dfVE9LRU5fMUBFREdFO2xyPg0KDQotIFdoZW4gdGhlIElORk8gYXJyaXZlcyB0byB0aGUg UkVHSVNUUkFSLCB0aGUgUkVHSVNUUkFSIE1VU1QgcGVyZm9ybSBHUlVVIGxvb2t1cCwgUklHSFQ/ Pw0KDQotIFNvIHRoZSBSRUdJU1RSQVIgcmV0cmlldmVzIHRoZSBCb2IgYmluZGluZyB3aGljaCBp bmNsdWRlcyBQYXRoIGFib3ZlICh0byBiZSBjb252ZXJ0ZWQgaW50byBSb3V0ZSBoZWFkZXIpLCBi dXQgc3VjaCBhIFJvdXRlIGhlYWRlciBpcyBBTFJFQURZIHByZXNlbnQgaW4gdGhlIElORk8gZHVl IHRvIHByZXZpb3VzIGFuZCBjb21tb24gcmVjb3JkLXJvdXRpbmcuDQpTbyB0aGUgUkVHSVNUUkFS Og0KDQogIC0gTXVzdCBERUxFVEUgdGhlIFJvdXRlIHBvaW50aW5nIHRvIG5leHQgbm9kZSAoRURH RSkuDQogIC0gQW5kIE1VU1QgYWRkIHRoZSBSb3V0ZSByZXRyaWV2ZWQgZnJvbSB0aGUgUGF0aC4N Cg0KLSBZRVMgT1IgTk9UIFBMRUFTRT8/Pw0KDQotIFRoZW4gdGhlIElORk8gYXJyaXZlcyB0byBF REdFIGFzIGZvbGxvd3M6DQoNCiAgSU5GTyBzaXA6Ym9iQEJPQl9JUA0KICBSb3V0ZTogPHNpcDpG TE9XX1RPS0VOXzFARURHRTtscj4NCg0KDQotIExhdGVyIGR1cmluZyB0aGUgZGlhbG9nLCBCb2Ig aXMgZGlzY29ubmVjdGVkIHNvIHJlY29ubmVjdHMgdG8gRURHRSBhbmQgcmUtcmVnaXN0ZXJzLiBO b3cgYSBuZXcgT3V0Ym91bmQgRmxvdyBUb2tlbiBpcyBnZW5lcmF0ZWQgYW5kIGFkZGVkIHRvIHRo ZSBQYXRoIGhlYWRlciBieSBFREdFOg0KDQogIFBhdGg6IDxzaXA6RkxPV19UT0tFTl8yQEVER0U7 bHI+DQoNCi0gQWxpY2Ugc2VuZHMgQllFIHRvIEJvYjoNCg0KICBCWUUgc2lwOmJvYkBiaWxveGku Y29tO2dyPUdSVVVfMQ0KICBSb3V0ZTogPHNpcDpSRUdJU1RSQVI7bHI+DQogIFJvdXRlOiA8c2lw OkZMT1dfVE9LRU5fMUBFREdFO2xyPg0KDQotIFRoZSBSRUdJU1RSQVIgZG9lcyBHUlVVIGxvb2t1 cCBhbmQgcmV0cmlldmVzIHRoZSBuZXcgUGF0aCB0aGF0IG11c3QgYmUgYWRkZWQgYXMgYSBuZXcg Um91dGU6DQoNCiAgLSBUaGUgUkVHSVNUUkFSIHJlbW92ZXMgdGhlIFJvdXRlIHBvaW50aW50IHRv IEVER0U6DQogICAgICBSb3V0ZTogPHNpcDpGTE9XX1RPS0VOXzFARURHRTtscj4NCiAgLSBBbmQg YWRkcyBhIG5ldyBvbmUgYmFzZWQgb24gdGhlIG5ldyBQYXRoIG9mIEJvYjoNCiAgICAgIFJvdXRl OiA8c2lwOkZMT1dfVE9LRU5fMkBFREdFO2xyPg0KDQotIFNvIHRoZSBCWUUgYXJyaXZpbmcgdG8g RURHRSBpczoNCg0KICBCWUUgc2lwOmJvYkBCT0JfSVANCiAgUm91dGU6IDxzaXA6RkxPV19UT0tF Tl8yQEVER0U7bHI+DQoNCi0gLi4ud2hpY2ggaXMgcHJvcGVybHkgcm91dGVkIHRvIEJvYiB2aWEg dGhlIG5ldyBjb25uZWN0aW9uLiBBbmQgbm8gbmVlZCBmb3IgQWxpY2UgYW5kIEJvYiB0byBjaGFu Z2UgdGhlIGRpYWxvZyByb3V0ZSBzZXQuDQoNCg0KDQpPayBmb2xrcywgcGxlYXNlIEhFTFAgTUUs IEkgY2Fubm90IGRlc2NyaWJlIHRoZSBwcm9ibGVtIGluIGEgYmV0dGVyIHdheS4gRG8geW91IHNl ZSB0aGUgdWdseSBwbGF5IHdpdGggUm91dGUgaGVhZGVycyBhYm92ZT8gdGhlIFJFR0lTVFJBUiBt dXN0IHJlbW92ZSBhIFJvdXRlIGhlYWRlciB0aGF0IHBvaW50cyB0byB0aGUgbmV4dCBub2RlIChF REdFIHByb3h5KSBiZWZvcmUgUkVHSVNUUkFSIGFkZHMgdGhlIFJvdXRlIG1pcnJvcmVkIGZyb20g dGhlIFBhdGggISEhIQ0KDQotIEhvdyBpcyBzdXBwb3NlZCB0aGF0IGEgcHJveHkgY2FuIGJlIGFi bGUgdG8gcmVtb3ZlIFJvdXRlIGhlYWRlcnMgYmVsb25naW5nIHRvIHByb3hpZXMgbG9jYXRlZCBh ZnRlciBpdD8/DQotIElzIEdSVVUgYnJva2VuPw0KLSBDYW4gR1JVVSB3b3JrIHdpdGggaW4tZGlh bG9nIHJlcXVlc3Qgb3Igbm90Pw0KDQoNCg0KDQoNCg0KDQoNCg0KLS0NCknDsWFraSBCYXogQ2Fz dGlsbG8NCjxpYmNAYWxpYXgubmV0Pg0K From christer.holmberg@ericsson.com Tue May 7 09:57:26 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2213621F9079 for ; Tue, 7 May 2013 09:57:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.142 X-Spam-Level: X-Spam-Status: No, score=-6.142 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SZeOjjdJmqtL for ; Tue, 7 May 2013 09:57:21 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4A42421F90E0 for ; Tue, 7 May 2013 09:57:19 -0700 (PDT) X-AuditID: c1b4fb2d-b7f536d000006e05-4e-5189326e3837 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 91.E7.28165.E6239815; Tue, 7 May 2013 18:57:18 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.02.0328.009; Tue, 7 May 2013 18:57:18 +0200 From: Christer Holmberg To: Michael Hammer , "ibc@aliax.net" , "dispatch@ietf.org" Thread-Topic: [dispatch] SIP outbound and in-dialog requests Thread-Index: AQHOR5uxaZW6BfvFUkyNBG2wEi4qB5jzclcwgABPfmKAABoxwoAE3z2Q///fQICAAM6HUP//7paAgAAr4BCAABJbgIAAYqpw Date: Tue, 7 May 2013 16:57:16 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C36CBCB@ESESSMB209.ericsson.se> References: <339625C1-F16E-429F-BA62-066F6F6B3B51@edvina.net> <6360A039-E87A-4872-A480-587FC9F84D2F@edvina.net> <201305021842.r42Ig2DO3979809@shell01.TheWorld.com> <201305030115.r431FRoS4006275@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C36B55D@ESESSMB209.ericsson.se> <201305031801.r43I1cSY4050203@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C36B7BA@ESESSMB209.ericsson.se> <201305062200.r46M0wjP4269356@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C36C7C8@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C36C8C7@ESESSMB209.ericsson.se> <00C069FD01E0324C9FFCADF539701DB3A03C17A6@EX2K10MB1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3A03C17A6@EX2K10MB1.corp.yaanatech.com> Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrKLMWRmVeSWpSXmKPExsUyM+JvrW6eUWegwdwdhhZLJy1gtZi+z8Zi 3cpvLA7MHuca3rN7LFnyk8nj+sEexgDmKC6blNSczLLUIn27BK6MlnVPmAsmWVTM/XWaqYHx hlkXIweHhICJxPXZNV2MnECmmMSFe+vZuhi5OIQEDjNKrDr+HcpZzChx+tAbRpAGNgELie5/ 2iANIgK1Esem7QQLCwtYS1w4zA8RtpE4tncdI4SdJ/FzzmUwm0VAReLpwlvMIOW8Ar4SO5ca QEz/wymx+95zJpAaToEQiSUX/rOD2IxA93w/tQYsziwgLvHh4HVmiDsFJJbsOQ9li0q8fPyP FcJWkmhc8oQVZD6zgKbE+l36EK2KElO6H4KN5BUQlDg58wnLBEbRWUimzkLomIWkYxaSjgWM LKsY2XMTM3PSyw03MQKj4uCW37o7GE+dEznEKM3BoiTOm8TVGCgkkJ5YkpqdmlqQWhRfVJqT WnyIkYmDU6qBMVd+IWescKTrhUuhIdVnD9RPtLxwR/5Ug6JYivP0H0LBLkIJMqLKtpcWzZVx fT/7wCU+6zf/n6zPFGT9NG9DZO3nvb/rVne8ZW2yOhvafq1lR4Pf0/K0Pcy+f8wmW59VbDTc e+Bm3+WEFXGXxXwVpebryhxremWQ+9swe8OnQ7u2q1Szq087p8RSnJFoqMVcVJwIAPWYEpFY AgAA Subject: Re: [dispatch] SIP outbound and in-dialog requests X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 16:57:26 -0000 SGkgTWlrZSwNCg0KVGhlIGVkZ2UgcHJveHkgaXMgcGFydCBvZiB0aGUgT3V0Ym91bmQgYXJjaGl0 ZWN0dXJlIDopDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCi0tLS0tQWxrdXBlcsOkaW5lbiB2 aWVzdGktLS0tLQ0KTMOkaGV0dMOkasOkOiBNaWNoYWVsIEhhbW1lciBbbWFpbHRvOm1pY2hhZWwu aGFtbWVyQHlhYW5hdGVjaC5jb21dIA0KTMOkaGV0ZXR0eTogNy4gdG91a29rdXV0YSAyMDEzIDE2 OjA0DQpWYXN0YWFub3R0YWphOiBDaHJpc3RlciBIb2xtYmVyZzsgaWJjQGFsaWF4Lm5ldDsgZGlz cGF0Y2hAaWV0Zi5vcmcNCkFpaGU6IFJFOiBbZGlzcGF0Y2hdIFNJUCBvdXRib3VuZCBhbmQgaW4t ZGlhbG9nIHJlcXVlc3RzDQoNCkhtbW0uLi4gIEl0IHdvdWxkIHNlZW0geW91ciBwcm9ibGVtIGlz IHRoYXQgdGhlcmUgaXMgdGhpcyBFREdFIHByb3h5IGJldHdlZW4gQm9iIGFuZCB0aGUgUmVnaXN0 cmFyLg0KUGVyaGFwcyBpZiB5b3UgZWxpbWluYXRlIHRoYXQsIHRoZW4geW91ciBwcm9ibGVtcyBn byBhd2F5Lg0KRG8geW91IGhhdmUgYW4gUkZDIHRoYXQgZGV0YWlscyB3aGF0IHRoZSBFREdFIHBy b3h5IGlzIGRvaW5nPw0KDQpPSywgc28gdGhhdCBpcyBhIGJpdCBmYWNldGlvdXMsIGJ1dCBJIGhh dmUgdG8gd29uZGVyIGlmIHRoaXMgZXhlcmNpc2UgaXMgYSBiaXQgbGlrZSBicmVha2luZyB0aGUg YXJjaGl0ZWN0dXJlLCANCnRoZW4gdHVybmluZyBhcm91bmQgYXNraW5nIHdoeSBpdCBzZWVtcyB0 byBiZSBicm9rZW4uDQoNCk1pa2UNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJv bTogZGlzcGF0Y2gtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmRpc3BhdGNoLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBDaHJpc3RlciBIb2xtYmVyZw0KU2VudDogVHVlc2RheSwgTWF5 IDA3LCAyMDEzIDY6MDQgQU0NClRvOiBJw7Fha2kgQmF6IENhc3RpbGxvOyBkaXNwYXRjaEBpZXRm Lm9yZw0KU3ViamVjdDogUmU6IFtkaXNwYXRjaF0gU0lQIG91dGJvdW5kIGFuZCBpbi1kaWFsb2cg cmVxdWVzdHMNCg0KSGksDQoNCllvdXIgZXhhbXBsZSBiZWxvdyBvbmx5IHNob3dzIHJlcXVlc3Rz IHNlbnQgZnJvbSBBbGljZS4gQW5kLCB0cnVlLCBCb2Igd2lsbCBub3Qgc2VlIHRoYXQgYSBkaWZm ZXJlbnQgcm91dGUgc2V0IGlzIHVzZWQsIGFzIHRoZSBSb3V0ZSBoZWFkZXJzIGFyZSByZW1vdmVk IG9uIHRoZSBwYXRoIChvZiBjb3Vyc2UsIHRoZSBWaWEgaGVhZGVycyB3aWxsIGJlIGRpZmZlcmVu dCwgYnV0IEkgZG91YnQgd2lsbCBzdG9yZSBhbmQgY29tcGFyZSB0aGVtKS4NCg0KQnV0LCBteSBj b21tZW50IHdhcyBhYm91dCB3aGVuL2lmIEJvYiBzZW5kcyBhbiBpbi1kaWFsb2cgcmVxdWVzdCAo SU5GTywgQllFLCBvciB3aGF0ZXZlcikuDQoNCkkgYW0gbm90IHJlYWxseSBzdXJlIHdoYXQgeW91 IG1lYW4gYnkgR1JVVSAiYmVpbmcgYnJva2VuIi4gSW4gdGhlIHNhbWUgd2F5IGFzIE91dGJvdW5k LCBHUlVVIHdhcyBkZXNpZ25lZCB3aXRoIGluaXRpYWwgZGlhbG9nIHJlcXVlc3RzIChvciBzdGFu ZC1hbG9uZSByZXF1ZXN0cykgaW4gbWluZCwgbm90IG1pZC1kaWFsb2cgcmVxdWVzdHMuDQoNClJl Z2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IEnDsWFraSBCYXogQ2FzdGlsbG8gW21haWx0bzppYmNAYWxpYXgubmV0XSANClNlbnQ6IDcuIHRv dWtva3V1dGEgMjAxMyAxMjoyMQ0KVG86IGRpc3BhdGNoQGlldGYub3JnDQpDYzogRGFsZSBSLiBX b3JsZXk7IENocmlzdGVyIEhvbG1iZXJnOyBPbGxlIEUgSm9oYW5zc29uOyBLbGF1cyBEYXJpbGlv bg0KU3ViamVjdDogUmU6IFtkaXNwYXRjaF0gU0lQIG91dGJvdW5kIGFuZCBpbi1kaWFsb2cgcmVx dWVzdHMNCg0KMjAxMy81LzcgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVy aWNzc29uLmNvbT46DQo+IEJ1dCwgYW5kIEkgYmVsaWV2ZSB0aGlzIHdhcyBhbHNvIGluZGljYXRl ZCwgdGhlIFVBIG1heSBhbHNvIFNFTkQgcmVxdWVzdHMgLSBzbyBpdCB3b3VsZCBuZWVkIHRvIHVw ZGF0ZSBpdHMgb3duIHJvdXRlIHNldCBhbHNvLg0KDQpObywgaXQncyBub3QgbmVlZGVkLiBUaGUg VUEgd2lsbCBzdGlsbCBpbmRpY2F0ZSBHUlVVIGluIGl0cyBDb250YWN0IHNvIHRoZSByZWdpc3Ry YXIgd2lsbCBkbyBsb29rdXAgYW5kIGFsc28gInJlcGxhY2UiIHRoZSBleGlzdGluZyBvbGQgUm91 dGUgaGVhZGVyIHdpdGggdGhlIG5ldyBvbmUgcmV0cmlldmVkIGZyb20gdGhlIG5ldyBQYXRoIChp ZiB0aGVyZSB3YXMgYW4gRWRnZSBwcm94eSkuDQoNCkFueWhvdywgaXQgc2VlbXMgdGhhdCBub2Jv ZHkgd2FudHMgdG8gcmVwbHkgdG8gdGhlIHByb2JsZW0gSSBkZXNjcmliZS4NCklzIGl0IG5vdCBj bGVhcj8gTGV0IG1lIHJlLWV4cGxhaW4gaXQ6DQoNCg0KKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQpQTEVBU0UgRk9MS1MgUkVBRCBBTkQgUkVQ TFkgQkVMT1cNCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKg0KDQoNCg0KU2NlbmFyaW86DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KQWxpY2UgLS0tIFJFR0lTVFJBUiAtLS0gRURH RSAtLS0gQm9iDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCg0KDQotIEJvYiByZWdpc3RlcnMgd2l0aCBHUlVVIGFuZCBPdXRib3VuZC4g RURHRSBhZGRzIFBhdGg6DQoNCiAgIFBhdGg6IDxzaXA6RkxPV19UT0tFTl8xQEVER0U7bHI+DQoN Cg0KLSBBbGljZSBjYWxscyBCb2IuIE9uY2UgdGhlIGNhbGwgaXMgZXN0YWJsaXNoZWQsIHRoZSBy b3V0ZSBzZXQgZnJvbSBBbGljZSBpcyBhcyBmb2xsb3dzOg0KDQogIFJvdXRlOiA8c2lwOlJFR0lT VFJBUjtscj4NCiAgUm91dGU6IDxzaXA6RkxPV19UT0tFTl8xQEVER0U7bHI+DQoNCi0gU28gYW4g aW4tZGlhbG9nIElORk8gZnJvbSBBbGljZSBsb29rcyBhcyBmb2xsb3dzOg0KDQogIElORk8gc2lw OmJvYkBiaWxveGkuY29tO2dyPUdSVVVfMQ0KICBSb3V0ZTogPHNpcDpSRUdJU1RSQVI7bHI+DQog IFJvdXRlOiA8c2lwOkZMT1dfVE9LRU5fMUBFREdFO2xyPg0KDQotIFdoZW4gdGhlIElORk8gYXJy aXZlcyB0byB0aGUgUkVHSVNUUkFSLCB0aGUgUkVHSVNUUkFSIE1VU1QgcGVyZm9ybSBHUlVVIGxv b2t1cCwgUklHSFQ/Pw0KDQotIFNvIHRoZSBSRUdJU1RSQVIgcmV0cmlldmVzIHRoZSBCb2IgYmlu ZGluZyB3aGljaCBpbmNsdWRlcyBQYXRoIGFib3ZlICh0byBiZSBjb252ZXJ0ZWQgaW50byBSb3V0 ZSBoZWFkZXIpLCBidXQgc3VjaCBhIFJvdXRlIGhlYWRlciBpcyBBTFJFQURZIHByZXNlbnQgaW4g dGhlIElORk8gZHVlIHRvIHByZXZpb3VzIGFuZCBjb21tb24gcmVjb3JkLXJvdXRpbmcuDQpTbyB0 aGUgUkVHSVNUUkFSOg0KDQogIC0gTXVzdCBERUxFVEUgdGhlIFJvdXRlIHBvaW50aW5nIHRvIG5l eHQgbm9kZSAoRURHRSkuDQogIC0gQW5kIE1VU1QgYWRkIHRoZSBSb3V0ZSByZXRyaWV2ZWQgZnJv bSB0aGUgUGF0aC4NCg0KLSBZRVMgT1IgTk9UIFBMRUFTRT8/Pw0KDQotIFRoZW4gdGhlIElORk8g YXJyaXZlcyB0byBFREdFIGFzIGZvbGxvd3M6DQoNCiAgSU5GTyBzaXA6Ym9iQEJPQl9JUA0KICBS b3V0ZTogPHNpcDpGTE9XX1RPS0VOXzFARURHRTtscj4NCg0KDQotIExhdGVyIGR1cmluZyB0aGUg ZGlhbG9nLCBCb2IgaXMgZGlzY29ubmVjdGVkIHNvIHJlY29ubmVjdHMgdG8gRURHRSBhbmQgcmUt cmVnaXN0ZXJzLiBOb3cgYSBuZXcgT3V0Ym91bmQgRmxvdyBUb2tlbiBpcyBnZW5lcmF0ZWQgYW5k IGFkZGVkIHRvIHRoZSBQYXRoIGhlYWRlciBieSBFREdFOg0KDQogIFBhdGg6IDxzaXA6RkxPV19U T0tFTl8yQEVER0U7bHI+DQoNCi0gQWxpY2Ugc2VuZHMgQllFIHRvIEJvYjoNCg0KICBCWUUgc2lw OmJvYkBiaWxveGkuY29tO2dyPUdSVVVfMQ0KICBSb3V0ZTogPHNpcDpSRUdJU1RSQVI7bHI+DQog IFJvdXRlOiA8c2lwOkZMT1dfVE9LRU5fMUBFREdFO2xyPg0KDQotIFRoZSBSRUdJU1RSQVIgZG9l cyBHUlVVIGxvb2t1cCBhbmQgcmV0cmlldmVzIHRoZSBuZXcgUGF0aCB0aGF0IG11c3QgYmUgYWRk ZWQgYXMgYSBuZXcgUm91dGU6DQoNCiAgLSBUaGUgUkVHSVNUUkFSIHJlbW92ZXMgdGhlIFJvdXRl IHBvaW50aW50IHRvIEVER0U6DQogICAgICBSb3V0ZTogPHNpcDpGTE9XX1RPS0VOXzFARURHRTts cj4NCiAgLSBBbmQgYWRkcyBhIG5ldyBvbmUgYmFzZWQgb24gdGhlIG5ldyBQYXRoIG9mIEJvYjoN CiAgICAgIFJvdXRlOiA8c2lwOkZMT1dfVE9LRU5fMkBFREdFO2xyPg0KDQotIFNvIHRoZSBCWUUg YXJyaXZpbmcgdG8gRURHRSBpczoNCg0KICBCWUUgc2lwOmJvYkBCT0JfSVANCiAgUm91dGU6IDxz aXA6RkxPV19UT0tFTl8yQEVER0U7bHI+DQoNCi0gLi4ud2hpY2ggaXMgcHJvcGVybHkgcm91dGVk IHRvIEJvYiB2aWEgdGhlIG5ldyBjb25uZWN0aW9uLiBBbmQgbm8gbmVlZCBmb3IgQWxpY2UgYW5k IEJvYiB0byBjaGFuZ2UgdGhlIGRpYWxvZyByb3V0ZSBzZXQuDQoNCg0KDQpPayBmb2xrcywgcGxl YXNlIEhFTFAgTUUsIEkgY2Fubm90IGRlc2NyaWJlIHRoZSBwcm9ibGVtIGluIGEgYmV0dGVyIHdh eS4gRG8geW91IHNlZSB0aGUgdWdseSBwbGF5IHdpdGggUm91dGUgaGVhZGVycyBhYm92ZT8gdGhl IFJFR0lTVFJBUiBtdXN0IHJlbW92ZSBhIFJvdXRlIGhlYWRlciB0aGF0IHBvaW50cyB0byB0aGUg bmV4dCBub2RlIChFREdFIHByb3h5KSBiZWZvcmUgUkVHSVNUUkFSIGFkZHMgdGhlIFJvdXRlIG1p cnJvcmVkIGZyb20gdGhlIFBhdGggISEhIQ0KDQotIEhvdyBpcyBzdXBwb3NlZCB0aGF0IGEgcHJv eHkgY2FuIGJlIGFibGUgdG8gcmVtb3ZlIFJvdXRlIGhlYWRlcnMgYmVsb25naW5nIHRvIHByb3hp ZXMgbG9jYXRlZCBhZnRlciBpdD8/DQotIElzIEdSVVUgYnJva2VuPw0KLSBDYW4gR1JVVSB3b3Jr IHdpdGggaW4tZGlhbG9nIHJlcXVlc3Qgb3Igbm90Pw0KDQoNCg0KDQoNCg0KDQoNCg0KLS0NCknD sWFraSBCYXogQ2FzdGlsbG8NCjxpYmNAYWxpYXgubmV0Pg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCmRpc3BhdGNoIG1haWxpbmcgbGlzdA0KZGlzcGF0 Y2hAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGlzcGF0 Y2gNCg== From pkyzivat@alum.mit.edu Tue May 7 11:21:51 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CBFF21F8EF7 for ; Tue, 7 May 2013 11:21:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.055 X-Spam-Level: X-Spam-Status: No, score=0.055 tagged_above=-999 required=5 tests=[AWL=0.493, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lMMimHgPqOVb for ; Tue, 7 May 2013 11:21:46 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 2F31D21F8F28 for ; Tue, 7 May 2013 11:21:45 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta03.westchester.pa.mail.comcast.net with comcast id YyYU1l00B1c6gX8536MjZw; Tue, 07 May 2013 18:21:43 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta23.westchester.pa.mail.comcast.net with comcast id Z6Mj1l00R3ZTu2S3j6MjPs; Tue, 07 May 2013 18:21:43 +0000 Message-ID: <51894635.9090409@alum.mit.edu> Date: Tue, 07 May 2013 14:21:41 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: dispatch@ietf.org References: <339625C1-F16E-429F-BA62-066F6F6B3B51@edvina.net> <6360A039-E87A-4872-A480-587FC9F84D2F@edvina.net> <201305021842.r42Ig2DO3979809@shell01.TheWorld.com> <51875CDA.6020800@pernau.at> <7594FB04B1934943A5C02806D1A2204B1C36BE0E@ESESSMB209.ericsson.se> <59D83BB5-1EE1-421E-A1D7-18C772E466B1@edvina.net> <5188CE78.100@crocodile-rcs.com> In-Reply-To: <5188CE78.100@crocodile-rcs.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1367950903; bh=jyf5HSLcrUcIfCd/1d/oYWf2JQvi7aPl53sEIJ75xVc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=sSh0QznYLsmSsLjozEYGbafhmb3SLxX3HU8bQchS6s5HWyS+BMQ0+fzDViS36iiHw 0LTJJqyCQGOxqxbzrgGBY4UR7ihD5QxSPrV8CK4MG8TNVN/AmPoqECWexF2dNGEESw ljh909jOSJ3r324KLpaW4BJXYSiun72iQQ9RPBrnFUM7ltDnJhy/yqXH1DRWPpAKL/ XDcT5U43zYUMmsXZ9e88SHQlSmkkCOe5O8cpYPHEEWZs+HfJyb0aVWg3BH/LCVZ3TX 3vigVDfYH/bTrf2kTquqF/AsB1n5JrvnP3x053XQrMEcTM11pDdx8xGUg2CprEenh/ XzSt7pr6Qc/VA== Subject: Re: [dispatch] SIP outbound and in-dialog requests X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 18:21:51 -0000 (Not replying to anyone in particular, just the thread to date) I scanned the long list of messages in this thread over the last few days, and if I'm not mistaken, something may have been overlooked. The route set is established at time of the initial invite, based on the contents of the Record-Route header. The Path header, used in REGISTER, subsequently affects *Route* headers put in outgoing requests from the home proxy. It doesn't necessarily affect what goes in Record-Route. If edge proxies Record-Route in INVITEs that use a GRUU as the contact, they can easily make a big mess by spiraling requests. The alternative is for them to *not* R-R in that case, and count on the home proxy inserting the Path into the Route when processing a GRUU. Does that solve the problem? Thanks, Paul On 5/7/13 5:50 AM, Hugh Waite wrote: > On 06/05/2013 14:44, Iñaki Baz Castillo wrote: >> 2013/5/6 Olle E. Johansson: >>> It seems to me that Outbound only handles dialog-forming requests, but currently can't handle survival of a dialog between >>> two or more flows between the UA and the edge proxy. That's something that needs to be fixed. >> Right, let me please simplify this issue with an example: >> >> >> Alice --- REGISTRAR --- EDGE --- Bob >> >> >> - Bob registers with GRUU through EDGE Proxy which performs Path. >> >> - Alice calls Bob. >> >> - Bob disconnectes, connects again and sends a new REGISTER. >> >> - EDGE sets a new outbound flow token in the Path header. The new >> binding (with new Path) replaces the previous one in the location DB. >> >> - Alice sends BYE to Bob. The BYE arrives to REGISTRAR which performs >> lookup for the binding of the GRUU URI of the BYE, and retrieves the >> new binding of Bob, so adds such a Route to the request, which now >> looks as follows: >> >> BYEsip:bob@billoxi.com;gr=qweasdzxc >> Route: (removed by REGISTRAR) >> Route: >> Route: (removed by REGSISTRAR OR NOT ????) >> >> - Of course here RFC 3261 is violated since the route set is changed. >> However endpoints will not realize of it since EDGE would remove both >> remaining Route headers before routing the request to Bob, but for >> that to work, REGISTRAR should previously also remove the >> EDGE-BOB-OLD-PATH Route header (otherwise EDGE Proxy would try to >> route via the old closed connection). >> >> >> Well, we have here a pain of Route headers added by intermediary >> proxies within a dialog, which seems ugly. We need a solution: >> >> >> >> 1) Is the above allowed by RFC 5626/5627 or not? > From RFC 5627 § 6.1: > > Special considerations apply to the processing of any Path headers > stored in the registration (seeRFC 3327 [3 ]). If the received > request has Route header field values beyond the one pointing to the > authoritative proxy itself (this will happen when the request is a > mid-dialog request),*the Path URI MUST be discarded*. This is > permitted byRFC 3327 [3 ] as a matter of local policy; usage of GRUUs > will require this policy in order to avoid call spirals and likely > call failures. > > From my reading of this, the RFC for GRUUs does not allow changing (or > adding to) the route-set mid-dialog. > > *IF* the registrar were to remove all forward Routes and replace them > with a new route-set from the registration, I agree that the request is > likely to reach the UA, even if the registration was through a different > edge proxy (for example). However, I can think of examples where it is > important to make sure that the path being replaced is going directly to > the UA, e.g. when there are additional hops added during call setup > (media servers, stateful proxies etc). > > Also, if a UA is forced to use a second connection for an in-dialog > request, then the route-set for the dialog will not match, e.g. if the > first hop in the new route is a different edge proxy. Does routing > traffic in this direction need to be considered at the same time as the > main discussion? > > > When a UA detects a lost connection (whether that is signalling, media > or moving from a 3G signal to a WiFi signal), the dialog needs to be > re-targetted (and/or re-directed) and it may need to renegotiate media. > Can something like the 'replaces' mechanism be used to take over the > dialog using out-of-dialog requests? Would this work round any of the > problems discussed here? > > Hugh > >> >> 2) How to avoid it? In case a new registration modifies the binding >> (including Path header with outbound flow token), nothing prevents the >> registrar to use the new binding for an in-dialog request, but it >> violates RFC 3261 (route set changed). >> >> 3) Anyhow endpoints will never see the new Route set so, does this >> violate 3261 or not? >> >> 4) and anyhow... the REGISTRAR (see example above) needs to remove the >> Route header pointing to next step before it inserts a new one due to >> the binding lookup and Path retrieval. Otherwise the request arrives >> to the EDGE proxy with two Route (with Flow-Token) headers pointing to >> it. >> >> >> All of this is really unclear. I hope there is an answer that allows a >> dialog to remain alive once the NATted TCP connection of an endpoint >> is closed during the dialog. Otherwise, nobody cared about mobile >> intermittent networks when RFC 5626/5627 were written? >> >> >> >> Regards. >> >> >> -- >> Iñaki Baz Castillo >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > > > -- > Hugh Waite > Principal Design Engineer > Crocodile RCS Ltd. > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From peter.dunkley@crocodile-rcs.com Fri May 10 04:20:11 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F3B721F90F1 for ; Fri, 10 May 2013 04:20:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TlQLzcccglRk for ; Fri, 10 May 2013 04:20:06 -0700 (PDT) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [69.89.24.6]) by ietfa.amsl.com (Postfix) with SMTP id 57C4C21F8CEC for ; Fri, 10 May 2013 04:20:06 -0700 (PDT) Received: (qmail 10949 invoked by uid 0); 10 May 2013 11:19:45 -0000 Received: from unknown (HELO just121.justhost.com) (173.254.28.121) by oproxy9.bluehost.com with SMTP; 10 May 2013 11:19:45 -0000 Received: from [90.152.0.102] (port=40428 helo=[192.168.0.156]) by just121.justhost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.80) (envelope-from ) id 1UalMW-0005xm-M0 for dispatch@ietf.org; Fri, 10 May 2013 05:19:44 -0600 Message-ID: <518CD7CE.4010808@crocodile-rcs.com> Date: Fri, 10 May 2013 12:19:42 +0100 From: Peter Dunkley User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130402 Thunderbird/17.0.5 MIME-Version: 1.0 To: dispatch@ietf.org References: <20130510111326.30541.54451.idtracker@ietfa.amsl.com> In-Reply-To: <20130510111326.30541.54451.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130510111326.30541.54451.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------010508090201050605070304" X-Identified-User: {596:just121.justhost.com:crocodi1:crocodile-rcs.com} {sentby:smtp auth 90.152.0.102 authed with peter.dunkley@crocodile-rcs.com} Subject: [dispatch] Fwd: New Version Notification for draft-pd-dispatch-msrp-websocket-02.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 11:20:11 -0000 This is a multi-part message in MIME format. --------------010508090201050605070304 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hello, There is an updated draft-pd-dispatch-msrp-websocket available. I hope this addresses most of the comments that have been made on this list. Regards, Peter -------- Original Message -------- Subject: New Version Notification for draft-pd-dispatch-msrp-websocket-02.txt Date: Fri, 10 May 2013 04:13:26 -0700 From: internet-drafts@ietf.org To: Victor Pascual , Peter Dunkley , Gavin Llewellyn A new version of I-D, draft-pd-dispatch-msrp-websocket-02.txt has been successfully submitted by Peter Dunkley and posted to the IETF repository. Filename: draft-pd-dispatch-msrp-websocket Revision: 02 Title: The WebSocket Protocol as a Transport for the Message Session Relay Protocol (MSRP) Creation date: 2013-05-10 Group: Individual Submission Number of pages: 21 URL: http://www.ietf.org/internet-drafts/draft-pd-dispatch-msrp-websocket-02.txt Status: http://datatracker.ietf.org/doc/draft-pd-dispatch-msrp-websocket Htmlized: http://tools.ietf.org/html/draft-pd-dispatch-msrp-websocket-02 Diff: http://www.ietf.org/rfcdiff?url2=draft-pd-dispatch-msrp-websocket-02 Abstract: The WebSocket protocol enables two-way real-time communication between clients and servers. This document specifies a new WebSocket sub-protocol as a reliable transport mechanism between MSRP (Message Session Relay Protocol) clients and relays to enable usage of MSRP in new scenarios. This document normatively updates RFC 4975 and RFC 4976. The IETF Secretariat --------------010508090201050605070304 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Hello,

There is an updated draft-pd-dispatch-msrp-websocket available.

I hope this addresses most of the comments that have been made on this list.

Regards,

Peter


-------- Original Message --------
Subject: New Version Notification for draft-pd-dispatch-msrp-websocket-02.txt
Date: Fri, 10 May 2013 04:13:26 -0700
From: internet-drafts@ietf.org
To: Victor Pascual <vpascual@acmepacket.com>, Peter Dunkley <peter.dunkley@crocodile-rcs.com>, Gavin Llewellyn <gavin.llewellyn@crocodile-rcs.com> 


A new version of I-D, draft-pd-dispatch-msrp-websocket-02.txt
has been successfully submitted by Peter Dunkley and posted to the
IETF repository.

Filename:	 draft-pd-dispatch-msrp-websocket
Revision:	 02
Title:		 The WebSocket Protocol as a Transport for the Message Session Relay Protocol (MSRP)
Creation date:	 2013-05-10
Group:		 Individual Submission
Number of pages: 21
URL:             http://www.ietf.org/internet-drafts/draft-pd-dispatch-msrp-websocket-02.txt
Status:          http://datatracker.ietf.org/doc/draft-pd-dispatch-msrp-websocket
Htmlized:        http://tools.ietf.org/html/draft-pd-dispatch-msrp-websocket-02
Diff:            http://www.ietf.org/rfcdiff?url2=draft-pd-dispatch-msrp-websocket-02

Abstract:
   The WebSocket protocol enables two-way real-time communication
   between clients and servers.  This document specifies a new WebSocket
   sub-protocol as a reliable transport mechanism between MSRP (Message
   Session Relay Protocol) clients and relays to enable usage of MSRP in
   new scenarios.  This document normatively updates RFC 4975 and RFC
   4976.

                                                                                  


The IETF Secretariat


--------------010508090201050605070304-- From peter.dunkley@crocodile-rcs.com Fri May 10 04:28:34 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8BC521F8E3C for ; Fri, 10 May 2013 04:28:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.931 X-Spam-Level: X-Spam-Status: No, score=-2.931 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N5cO-mn-R33u for ; Fri, 10 May 2013 04:28:29 -0700 (PDT) Received: from oproxy12-pub.bluehost.com (oproxy12-pub.bluehost.com [50.87.16.10]) by ietfa.amsl.com (Postfix) with SMTP id C5A7C21F8ADF for ; Fri, 10 May 2013 04:28:29 -0700 (PDT) Received: (qmail 7196 invoked by uid 0); 10 May 2013 11:28:00 -0000 Received: from unknown (HELO just121.justhost.com) (173.254.28.121) by oproxy12.bluehost.com with SMTP; 10 May 2013 11:28:00 -0000 Received: from [90.152.0.102] (port=40455 helo=[192.168.0.156]) by just121.justhost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.80) (envelope-from ) id 1UalUW-0008KE-4k for dispatch@ietf.org; Fri, 10 May 2013 05:28:00 -0600 Message-ID: <518CD9BD.4040502@crocodile-rcs.com> Date: Fri, 10 May 2013 12:27:57 +0100 From: Peter Dunkley User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130402 Thunderbird/17.0.5 MIME-Version: 1.0 To: dispatch@ietf.org References: <20130510111432.23919.65009.idtracker@ietfa.amsl.com> In-Reply-To: <20130510111432.23919.65009.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130510111432.23919.65009.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------080107080908030205030208" X-Identified-User: {596:just121.justhost.com:crocodi1:crocodile-rcs.com} {sentby:smtp auth 90.152.0.102 authed with peter.dunkley@crocodile-rcs.com} Subject: [dispatch] MSRP over WebRTC X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 11:28:35 -0000 This is a multi-part message in MIME format. --------------080107080908030205030208 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hello DISPATCHers, There is new draft for MSRP over WebRTC. This is a very early (and not yet implementable) draft due to the current state of the WebRTC Data Channel work. This draft is a companion to draft-pd-dispatch-msrp-websocket as I believe that MSRP over WebSocket and MSRP over WebRTC are complementary technologies that are each suited to different use-cases. Support for MSRP over WebRTC will be added to the Crocodile MSRP stack (http://code.google.com/p/crocodile-msrp/) once reliable WebRTC Data Channels become available in Chrome or Firefox. At this point the stack will support both MSRP over WebSocket and MSRP over WebRTC through a single API. Although this draft makes use of WebRTC I think it belongs in DISPATCH as this is where changes and updates to MSRP are discussed. Regards, Peter -------- Original Message -------- Subject: New Version Notification for draft-pd-msrp-webrtc-00.txt Date: Fri, 10 May 2013 04:14:32 -0700 From: internet-drafts@ietf.org To: Peter Dunkley , Gavin Llewellyn A new version of I-D, draft-pd-msrp-webrtc-00.txt has been successfully submitted by Peter Dunkley and posted to the IETF repository. Filename: draft-pd-msrp-webrtc Revision: 00 Title: The WebRTC Data Channel as a Transport for the Message Session Relay Protocol (MSRP) Creation date: 2013-05-10 Group: Individual Submission Number of pages: 10 URL: http://www.ietf.org/internet-drafts/draft-pd-msrp-webrtc-00.txt Status: http://datatracker.ietf.org/doc/draft-pd-msrp-webrtc Htmlized: http://tools.ietf.org/html/draft-pd-msrp-webrtc-00 Abstract: The WebRTC Data Channel enables two-way real-time communication between browsers. This document updates normatively updates RFC 4975 to add support for WebRTC Data Channel as a transport for MSRP (Message Session Relay Protocol). This will enable secure, low- latency, structured peer-to-peer messaging between WebRTC end-points. The IETF Secretariat --------------080107080908030205030208 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hello DISPATCHers,

There is new draft for MSRP over WebRTC.  This is a very early (and not yet implementable) draft due to the current state of the WebRTC Data Channel work.

This draft is a companion to draft-pd-dispatch-msrp-websocket as I believe that MSRP over WebSocket and MSRP over WebRTC are complementary technologies that are each suited to different use-cases.

Support for MSRP over WebRTC will be added to the Crocodile MSRP stack (http://code.google.com/p/crocodile-msrp/) once reliable WebRTC Data Channels become available in Chrome or Firefox.  At this point the stack will support both MSRP over WebSocket and MSRP over WebRTC through a single API.

Although this draft makes use of WebRTC I think it belongs in DISPATCH as this is where changes and updates to MSRP are discussed.

Regards,

Peter


-------- Original Message --------
Subject: New Version Notification for draft-pd-msrp-webrtc-00.txt
Date: Fri, 10 May 2013 04:14:32 -0700
From: internet-drafts@ietf.org
To: Peter Dunkley <peter.dunkley@crocodile-rcs.com>, Gavin Llewellyn <gavin.llewellyn@crocodile-rcs.com> 


A new version of I-D, draft-pd-msrp-webrtc-00.txt
has been successfully submitted by Peter Dunkley and posted to the
IETF repository.

Filename:	 draft-pd-msrp-webrtc
Revision:	 00
Title:		 The WebRTC Data Channel as a Transport for the Message Session Relay Protocol (MSRP)
Creation date:	 2013-05-10
Group:		 Individual Submission
Number of pages: 10
URL:             http://www.ietf.org/internet-drafts/draft-pd-msrp-webrtc-00.txt
Status:          http://datatracker.ietf.org/doc/draft-pd-msrp-webrtc
Htmlized:        http://tools.ietf.org/html/draft-pd-msrp-webrtc-00


Abstract:
   The WebRTC Data Channel enables two-way real-time communication
   between browsers.  This document updates normatively updates RFC 4975
   to add support for WebRTC Data Channel as a transport for MSRP
   (Message Session Relay Protocol).  This will enable secure, low-
   latency, structured peer-to-peer messaging between WebRTC end-points.

                                                                                  


The IETF Secretariat


--------------080107080908030205030208-- From fas_vm@surguttel.ru Fri May 10 08:06:06 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F08521F859A for ; Fri, 10 May 2013 08:06:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.472 X-Spam-Level: * X-Spam-Status: No, score=1.472 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQD9pAvq4fb1 for ; Fri, 10 May 2013 08:06:00 -0700 (PDT) Received: from mail.s86.ru (mail.s86.ru [217.8.80.233]) by ietfa.amsl.com (Postfix) with ESMTP id 4D49B21F85C0 for ; Fri, 10 May 2013 08:05:59 -0700 (PDT) Received: by mail.s86.ru (Postfix, from userid 1116) id F3E4A513916; Fri, 10 May 2013 21:02:53 +0600 (YEKT) Received: from Gateway (unknown [151.252.67.1]) by mail.s86.ru (Postfix) with ESMTPA id CF89A5143A0 for ; Fri, 10 May 2013 21:02:50 +0600 (YEKT) Message-ID: <5743F6407CB04BF7BD23451A83A2DE7B@Gateway> From: "Anton Tveretin" To: Date: Fri, 10 May 2013 20:37:23 +0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="koi8-r"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Antivirus: avast! (VPS 130510-0, 10.05.2013), Outbound message X-Antivirus-Status: Clean Subject: [dispatch] I-D Announcement X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 15:06:06 -0000 Dear All, I have issued a new I-D: draft-ietf-dispatch-tveretin-00. There are still open issues. For instance, should PPTP be registered (procedures included) with the same RFC? Editing is clearly required. Sincerely yours, Anton Tveretin From oej@edvina.net Fri May 10 23:22:28 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF59021F8EE8 for ; Fri, 10 May 2013 23:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UXZgKqY-O3Hv for ; Fri, 10 May 2013 23:22:28 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 117DE21F8EDF for ; Fri, 10 May 2013 23:22:26 -0700 (PDT) Received: from [IPv6:2001:16d8:cc57:1000::42:100a] (unknown [IPv6:2001:16d8:cc57:1000::42:100a]) by smtp7.webway.se (Postfix) with ESMTPA id 81D9493C2A1; Sat, 11 May 2013 06:22:23 +0000 (UTC) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: "Olle E. Johansson" In-Reply-To: Date: Sat, 11 May 2013 08:22:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <014CFAE2-73BB-44C2-858F-952ECBFE1507@edvina.net> References: <339625C1-F16E-429F-BA62-066F6F6B3B51@edvina.net> <6360A039-E87A-4872-A480-587FC9F84D2F@edvina.net> <201305021842.r42Ig2DO3979809@shell01.TheWorld.com> <201305030115.r431FRoS4006275@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C36B55D@ESESSMB209.ericsson.se> <201305031801.r43I1cSY4050203@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C36B7BA@ESESSMB209.ericsson.se> <201305062200.r46M0wjP4269356@shell01.TheWorld.com> <7594FB04B1934943A5C0280 6D1A2204B1C36C7C8@ESESSMB209.ericsson.se> To: =?iso-8859-1?Q?Castillo_Baz_I=F1aki?= , "dispatch@ietf.org list" X-Mailer: Apple Mail (2.1503) Subject: Re: [dispatch] SIP outbound and in-dialog requests X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 May 2013 06:22:28 -0000 7 maj 2013 kl. 11:20 skrev I=F1aki Baz Castillo : > - The REGISTRAR does GRUU lookup and retrieves the new Path that must > be added as a new Route: "Special considerations apply to the processing of any Path headers stored in the registration (see RFC 3327 [3]). If the received request has Route header field values beyond the one pointing to the authoritative proxy itself (this will happen when the request is a mid-dialog request), the Path URI MUST be discarded. This is permitted by RFC 3327 [3 as a matter of local policy; usage of GRUUs will require this policy in order to avoid call spirals and likely call failures." This is from RFC 5627, section 6.1. What I understand is that if you already have a route to the edge proxy = that=20 has the failed flow, you are still not allowed to change the route set = based on the Path header in the registration. Now, if the edge proxy doesn't record-route we have a different = situation. In that case we have no flow token either. Section 5.3.2 of RFC 5626 (outbound) has an interesting implementation = note: "Implementation note: Specific procedures at the edge proxy to ensure that mid-dialog requests are routed over an existing flow are not part of this specification. However, an approach such as having the edge proxy add a Record-Route header with a flow token is one way to ensure that mid-dialog requests are routed over the correct flow." /O From peter.dunkley@crocodile-rcs.com Sat May 11 02:41:12 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DEBD21F8517 for ; Sat, 11 May 2013 02:41:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.665 X-Spam-Level: X-Spam-Status: No, score=-1.665 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_41=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ANH1PTuKVEB for ; Sat, 11 May 2013 02:41:07 -0700 (PDT) Received: from oproxy14-pub.unifiedlayer.com (oproxy14-pub.unifiedlayer.com [67.222.51.224]) by ietfa.amsl.com (Postfix) with SMTP id 6E1AC21F84E7 for ; Sat, 11 May 2013 02:41:07 -0700 (PDT) Received: (qmail 15067 invoked by uid 0); 11 May 2013 09:41:01 -0000 Received: from unknown (HELO just121.justhost.com) (173.254.28.121) by oproxy14.unifiedlayer.com with SMTP; 11 May 2013 09:41:01 -0000 Received: from [127.0.0.1] (port=44229 helo=crocodile-rcs.com) by just121.justhost.com with esmtpa (Exim 4.80) (envelope-from ) id 1Ub6IX-0005N3-H6; Sat, 11 May 2013 03:41:01 -0600 Received: from 86.15.139.171 ([86.15.139.171]) (SquirrelMail authenticated user peter.dunkley@crocodile-rcs.com) by crocodile-rcs.com with HTTP; Sat, 11 May 2013 10:41:01 +0100 Message-ID: In-Reply-To: <014CFAE2-73BB-44C2-858F-952ECBFE1507@edvina.net> References: <6360A039-E87A-4872-A480-587FC9F84D2F@edvina.net> <201305021842.r42Ig2DO3979809@shell01.TheWorld.com> <201305030115.r431FRoS4006275@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C36B55D@ESESSMB209.ericsson.se> <201305031801.r43I1cSY4050203@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C36B7BA@ESESSMB209.ericsson.se> <201305062200.r46M0wjP4269356@shell01.TheWorld.com> <7594FB04B1934943A5C0280 6D1A2204B1C36C7C8@ESESSMB209.ericsson.se> <014CFAE2-73BB-44C2-858F-952ECBFE1507@edvina.net> Date: Sat, 11 May 2013 10:41:01 +0100 From: "Peter Dunkley" To: dispatch@ietf.org User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Identified-User: {:just121.justhost.com:crocodi1:just121.justhost.com} {sentby:program running on server} Subject: Re: [dispatch] SIP outbound and in-dialog requests X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 May 2013 09:41:12 -0000 RFC 5626 section 4.3: If the UAC is using a Globally Routable UA URI (GRUU) [RFC5627] that was instantiated using a Contact header field value that included an "ob" parameter, the UAC sends the request over the flow used for registration, and subsequent requests will arrive over that same flow. If the UAC is not using such a GRUU, then the UAC adds an "ob" parameter to its Contact header field value. RFC 5626 section 5.3.2: If the edge proxy receives an outgoing dialog-forming request, the edge proxy can use the presence of the "ob" URI parameter in the UAC's Contact URI (or topmost Route header field) to determine if the edge proxy needs to assist in mid-dialog request routing. The effect here is that if GRUU is being used a flow-token will not be added to the record-route added by the first edge proxy. The impact of this is that if the UA is behind a NAT device mid-dialog requests cannot be routed to it. The only way I can see to get these mid-dialog requests to route correct is to replace the route-set with the Path:s from the registrar. The statement, "and subsequent requests will arrive over that same flow" implies this too. Regards, Peter > > 7 maj 2013 kl. 11:20 skrev Iñaki Baz Castillo : > >> - The REGISTRAR does GRUU lookup and retrieves the new Path that must >> be added as a new Route: > > "Special considerations apply to the processing of any Path headers > stored in the registration (see RFC 3327 [3]). If the received > request has Route header field values beyond the one pointing to the > authoritative proxy itself (this will happen when the request is a > mid-dialog request), the Path URI MUST be discarded. This is > permitted by RFC 3327 [3 as a matter of local policy; usage of GRUUs > will require this policy in order to avoid call spirals and likely > call failures." > > This is from RFC 5627, section 6.1. > > What I understand is that if you already have a route to the edge proxy > that > has the failed flow, you are still not allowed to change the route set > based > on the Path header in the registration. > > Now, if the edge proxy doesn't record-route we have a different situation. > In that case we have no flow token either. > > Section 5.3.2 of RFC 5626 (outbound) has an interesting implementation > note: > > "Implementation note: Specific procedures at the edge proxy to > ensure that mid-dialog requests are routed over an existing flow > are not part of this specification. However, an approach such as > having the edge proxy add a Record-Route header with a flow token > is one way to ensure that mid-dialog requests are routed over the > correct flow." > > /O > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > -- Peter Dunkley Technical Director Crocodile RCS Ltd From hangzhou.chenxin@huawei.com Tue May 14 19:01:44 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 379BE21F898B for ; Tue, 14 May 2013 19:01:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eN0d4Ls0xgQg for ; Tue, 14 May 2013 19:01:40 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A809E21F8529 for ; Tue, 14 May 2013 19:01:39 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ARJ69815; Wed, 15 May 2013 02:01:34 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 15 May 2013 03:01:10 +0100 Received: from SZXEML419-HUB.china.huawei.com (10.82.67.158) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 15 May 2013 03:01:33 +0100 Received: from SZXEML538-MBS.china.huawei.com ([169.254.3.34]) by szxeml419-hub.china.huawei.com ([10.82.67.158]) with mapi id 14.01.0323.007; Wed, 15 May 2013 10:01:03 +0800 From: "Chenxin (Xin)" To: "dispatch@ietf.org" Thread-Topic: New Version Notification for draft-chenxin-behave-turn-websocket-00.txt Thread-Index: AQHOUEBzwmg1PRmVTkGgLh5/jvIzeJkFdPzAgAAKAZA= Date: Wed, 15 May 2013 02:01:01 +0000 Message-ID: <9E34D50A21D1D1489134B4D770CE03974C6DC858@szxeml538-mbs.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.41.129] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [dispatch] FW: New Version Notification for draft-chenxin-behave-turn-websocket-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 02:01:44 -0000 VGhpcyBkcmFmdCBkZWZpbmVzIGEgd2Vic29ja2V0IGV4dGVuc2lvbiB0byBUVVJOIHRvIG1ha2Ug VFVSTiBkYXRhIGhhdmUgdGhlIGFiaWxpdHkgdG8gdHJhbnNwb3J0IG92ZXIgdGhlIHdlYnNvY2tl dCBjb25uZWN0aW9uLg0KVGhpcyBtZXRob2QgY291bGQgYmUgYSBvcHRpb24gdG8gc29sdmUgdGhl IEh0dHAtZmFsbGJhY2sgcmVxdWlyZW1lbnQgaW4gUlRDV0VCLiANCg0KICAgIEYzNyAgICAgICAg ICAgIFRoZSBicm93c2VyIE1VU1QgYmUgYWJsZSB0byBzZW5kIHN0cmVhbXMgYW5kDQogICAgICAg ICAgICAgICAgICAgZGF0YSB0byBhIHBlZXIgaW4gdGhlIHByZXNlbmNlIG9mIEZXcyB0aGF0IG9u bHkNCiAgICAgICAgICAgICAgICAgICBhbGxvd3MgaHR0cChzKSB0cmFmZmljLg0KDQpCZXNpZGVz LCBUdXJuIHNlcnZlciB3aXRoIHdlYnNva2NldCBleHRlbnNpb24gY291bGQgYmUgYSBnZW5lcmFs IHJlbGF5IHNlcnZlciBmb3Igc29tZSBvdmVyIHdlYnNvY2tldCBwcm90b2NvbCwgc3VjaCBhcyBC RkNQIG92ZXIgd2Vic29ja2V0IG9yIE1TUlAgb3ZlciB3ZWJzb2NrZXQuIFRoaXMgY291bGQgc2F0 aXNmeSBzb21lIFBlZXIgdG8gUGVlciBzY2VuZSB3aGVuIHVzaW5nIHRoZXNlIHByb3RvY29sIGlu IHRoZSB3ZWIgZW52aXJvbm1lbnQgLCB3aXRob3V0IGEgc3BlY2lmaWMgY2VudGVyIHNlcnZlci4N Cg0KQ29tbWVudHMgYW5kIHN1Z2dlc3Rpb25zIGFyZSB3ZWxjb21lLg0KDQpCZXN0IFJlZ2FyZHMs DQogICAgIFhpbiANCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJu ZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANClNl bnQ6IFR1ZXNkYXksIE1heSAxNCwgMjAxMyA5OjE1IEFNDQpUbzogQ2hlbnhpbiAoWGluKTsgQ2hl bnhpbiAoWGluKQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1j aGVueGluLWJlaGF2ZS10dXJuLXdlYnNvY2tldC0wMC50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9m IEktRCwgZHJhZnQtY2hlbnhpbi1iZWhhdmUtdHVybi13ZWJzb2NrZXQtMDAudHh0DQpoYXMgYmVl biBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFhpbiBDaGVuIGFuZCBwb3N0ZWQgdG8gdGhlDQpJ RVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOgkgZHJhZnQtY2hlbnhpbi1iZWhhdmUtdHVybi13 ZWJzb2NrZXQNClJldmlzaW9uOgkgMDANClRpdGxlOgkJIFRyYXZlcnNhbCBVc2luZyBSZWxheXMg YXJvdW5kIE5BVCAoVFVSTikgRXh0ZW5zaW9ucyBmb3IgV2Vic29ja2V0IEFsbG9jYXRpb25zDQpD cmVhdGlvbiBkYXRlOgkgMjAxMy0wNS0xMw0KR3JvdXA6CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9u DQpOdW1iZXIgb2YgcGFnZXM6IDcNClVSTDogICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9y Zy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtY2hlbnhpbi1iZWhhdmUtdHVybi13ZWJzb2NrZXQtMDAu dHh0DQpTdGF0dXM6ICAgICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtY2hlbnhpbi1iZWhhdmUtdHVybi13ZWJzb2NrZXQNCkh0bWxpemVkOiAgICAgICAgaHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2hlbnhpbi1iZWhhdmUtdHVybi13ZWJzb2NrZXQt MDANCg0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhbiBleHRlbnNpb24g dG8gVFVSTiB0aGF0IGFsbG93cyBpdCB0byBydW4gb3Zlcg0KICAgYSBXZWJzb2NrZXQgW1JGQzY0 NTVdIGNoYW5uZWwuICBUaGlzIHdpbGwgYWxsb3cgYSBjbGllbnQgaW4gYQ0KICAgcmVzdHJpY3Rp dmUgbmV0d29yayB0byBleGNoYW5nZSBhbmQgcmVsYXkgbWVkaWEgb3IgZGF0YSBvdmVyIHRoZQ0K ICAgd2Vic29ja2V0Lg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KVGhlIElFVEYg U2VjcmV0YXJpYXQNCg0K From oej@edvina.net Fri May 17 05:54:00 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50A6421F93E8 for ; Fri, 17 May 2013 05:54:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Afs6G6wq6BL for ; Fri, 17 May 2013 05:53:59 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 31CE321F89C3 for ; Fri, 17 May 2013 05:53:50 -0700 (PDT) Received: from [192.168.40.23] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 6D5E893C1AF; Fri, 17 May 2013 12:53:47 +0000 (UTC) From: "Olle E. Johansson" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 17 May 2013 14:53:46 +0200 Message-Id: <49B1CBCA-9F4E-4C35-A908-E348624764E0@edvina.net> To: "dispatch@ietf.org list" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) Subject: [dispatch] Surviving outbound X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 12:54:00 -0000 It seems to me like the conclusion on the discussion on dialog survival = during failure is=20 A) When using GRUU there's a chance for survival of a dialog there's a = possibility for the dialog to survive B) If GRUU is not used, the dialog doesn't survive since the route set = is fixed. Is this correct? If so, anyone interested in discussing a possible solution? /O= From worley@shell01.TheWorld.com Fri May 17 09:24:18 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A75B21F977D for ; Fri, 17 May 2013 09:24:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.98 X-Spam-Level: X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f1b851YQnyNL for ; Fri, 17 May 2013 09:24:12 -0700 (PDT) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id 1D52421F9704 for ; Fri, 17 May 2013 09:24:02 -0700 (PDT) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r4HGNWSY024254; Fri, 17 May 2013 12:23:36 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r4HGNTrR4951562; Fri, 17 May 2013 12:23:29 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r4HGNSr64942933; Fri, 17 May 2013 12:23:28 -0400 (EDT) Date: Fri, 17 May 2013 12:23:28 -0400 (EDT) Message-Id: <201305171623.r4HGNSr64942933@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: "Olle E. Johansson" In-reply-to: <49B1CBCA-9F4E-4C35-A908-E348624764E0@edvina.net> (oej@edvina.net) References: <49B1CBCA-9F4E-4C35-A908-E348624764E0@edvina.net> Cc: dispatch@ietf.org Subject: Re: [dispatch] Surviving outbound X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 16:24:18 -0000 > From: "Olle E. Johansson" > > It seems to me like the conclusion on the discussion on dialog > survival during failure is > > A) When using GRUU there's a chance for survival of a dialog there's > a possibility for the dialog to survive > B) If GRUU is not used, the dialog doesn't survive since the route > set is fixed. > > Is this correct? > > If so, anyone interested in discussing a possible solution? I don't see much value in worrying about the non-GRUU case, but the GRUU case is best current practice and yet we do not currently have a generally accepted/implemented solution to dialog survival. Dale From ibc@aliax.net Mon May 20 10:21:33 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C84521F9691 for ; Mon, 20 May 2013 10:21:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3es70NTAJL1t for ; Mon, 20 May 2013 10:21:32 -0700 (PDT) Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id B327921F9683 for ; Mon, 20 May 2013 10:21:32 -0700 (PDT) Received: by mail-qc0-f179.google.com with SMTP id e1so1580834qcx.38 for ; Mon, 20 May 2013 10:21:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=NJu0GqgIWSw7wwTYmk5GueB1AMgu3pZA0fzjDH3TZoQ=; b=QqHUzbp4hLCslYudBDXRcYsb89mfDXrAiQXt4b2e1JWuJ7XnCBYYrNDeQr6PCc3u4x 2fOP8NsfaTCYhjZZmwe57cqv+kySsVgn1U+FCvWrp20XUjhWx/tBop3dmQXoZp7w5Jfl 9zzevAbLDEJXXNqVe6vk44J1DcyAZiGlBqLx4W6P1rKB6N+U7AqCQalzcVHg77KAEmqZ MSq6RLDqDtIGBBoVC/jyn828PXUB2aSIMwpY//LlYrBrTeFTvwkUF0+1mPwatYmkfaM8 7hTzDAiIhuZycxGq1A19CgZcZe43/TRPEWBIWIkM4fmO/U6LWyyHKrGFhfFV1wOrjQNI kLlA== X-Received: by 10.224.109.65 with SMTP id i1mr49332433qap.50.1369070491936; Mon, 20 May 2013 10:21:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.26.103 with HTTP; Mon, 20 May 2013 10:21:10 -0700 (PDT) In-Reply-To: <201305171623.r4HGNSr64942933@shell01.TheWorld.com> References: <49B1CBCA-9F4E-4C35-A908-E348624764E0@edvina.net> <201305171623.r4HGNSr64942933@shell01.TheWorld.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 20 May 2013 19:21:10 +0200 Message-ID: To: "Dale R. Worley" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlvLzGLNwR871tm/uM+Cff8+A/FvTcCD56nwob08Qz5K5ByvK4hqD0vRvE9iRQ5iDk0Nc8W Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Surviving outbound X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 17:21:33 -0000 2013/5/17 Dale R. Worley : > I don't see much value in worrying about the non-GRUU case, but the > GRUU case is best current practice and yet we do not currently have a > generally accepted/implemented solution to dialog survival. It just works if the route set is modified by the intermediary registrar (the route set between the registrar itself and the outbound edge proxy the user is connected to). And for that to work, the registrar must be able to remove Route headers pointing to the next hop (the outbound proxy). So yes, no real way. -- I=C3=B1aki Baz Castillo From christer.holmberg@ericsson.com Tue May 21 00:30:28 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C9B321F9728 for ; Tue, 21 May 2013 00:30:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.968 X-Spam-Level: X-Spam-Status: No, score=-5.968 tagged_above=-999 required=5 tests=[AWL=-0.019, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gZ-DnhQXRLx0 for ; Tue, 21 May 2013 00:30:22 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 0F6D021F965C for ; Tue, 21 May 2013 00:30:21 -0700 (PDT) X-AuditID: c1b4fb25-b7efb6d000007c26-a2-519b228ccea7 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 93.0E.31782.C822B915; Tue, 21 May 2013 09:30:20 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.02.0328.009; Tue, 21 May 2013 09:30:20 +0200 From: Christer Holmberg To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , "Dale R. Worley" Thread-Topic: [dispatch] Surviving outbound Thread-Index: AQHOUv2jlBlAIDXlOkq3RTDO3gs7f5kJj/4NgASlVgCAAQym4A== Date: Tue, 21 May 2013 07:30:19 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C374F9A@ESESSMB209.ericsson.se> References: <49B1CBCA-9F4E-4C35-A908-E348624764E0@edvina.net> <201305171623.r4HGNSr64942933@shell01.TheWorld.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.17] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrILMWRmVeSWpSXmKPExsUyM+JvrW6P0uxAgy8HLC2WTlrAajF9n43F yxNlDswe5xres3tM3v+V2WPJkp9MAcxRXDYpqTmZZalF+nYJXBkdn+cyFvQJVhzc9JixgfGK QBcjJ4eEgInEi9evmCFsMYkL99azdTFycQgJHGaUmLH9KAuEs4RR4kfnQSCHg4NNwEKi+582 SIOIQKrEv/PN7CA2s4C2xP/r6xhBbGEBLYmDO/pZIGq0Jf4ufMQMYTtJdN3tZQOxWQRUJf7N +8IKYvMK+Ercv/odbI6QwC5GiQ2HlUBsToFAiflHNoDNZAQ67vupNUwQu8Qlbj2ZzwRxtIDE kj3noR4QlXj5+B8ryJkSAooSy/vlQExmAU2J9bv0IToVJaZ0P2SH2CoocXLmE5YJjGKzkAyd hdAxC0nHLCQdCxhZVjGy5yZm5qSXG21iBEbLwS2/VXcw3jkncohRmoNFSZy3V3tqoJBAemJJ anZqakFqUXxRaU5q8SFGJg5OqQbGft7X6xfkHtjawWwrydwfe2PhF5XMiXpfHJNfOmy6YHhr XcqpTXrLGS4v2xpc53jrm+HEXEWp+KaMRY/8qi6ay22PWDr/rg6XRekLxfhDbXsuRD/NmnZi s9WVNKmmVQ/8mq5W8qtwLZVPV/M3Eo3N2WxrnGhUfUZhJcvkJzJhulvmyqV2f9ukxFKckWio xVxUnAgAazlGJGQCAAA= Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Surviving outbound X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 07:30:28 -0000 SGksDQoNCkkgZmFpbCB0byBzZWUgdGhlIEdSVVUgdnMgbm9uLUdSVVUgYXNwZWN0LCBidXQgbWF5 YmUgdGhhdCBpcyBub3QgaW1wb3J0YW50IDopDQoNClBlcmhhcHMgdGhlcmUgYXJlIHNjZW5hcmlv cyB3aGVyZSBtb2RpZnlpbmcgdGhlIHJvdXRlIHNldCB3b3VsZCB3b3JrLCBidXQgdGhlIHBvaW50 IGlzIHRoYXQgaXMgZ29lcyBhZ2FpbnN0IFJGQyAzMjYxLCBhbmQgYXMgc29vbiBhcyB0aGUgbmV3 IHJvdXRlIHNldCBjb250YWlucyBhIG5ldyBzdGF0ZWZ1bCBwcm94eSB0aGluZ3Mgd2lsbCBicmVh aywgYmVjYXVzZSBpdCB3aWxsIHJlamVjdCBtaWQtZGlhbG9nIHJlcXVlc3RzIGZvciBkaWFsb2dz IGl0IGlzIG5vdCBhd2FyZSBvZi4NCg0KVGhlIHdheSBlLmcuIDNHUFAgc29sdmVzIHRoaXMsIGZv ciBkaWZmZXJlbnQgdHlwZXMgb2Ygc2NlbmFyaW9zLCBpcyBieSBlc3RhYmxpc2hpbmcgYSBuZXcg ZGlhbG9nIGJldHdlZW4gdGhlIFVBIGFuZCBzb21lIEIyQlVBLiBUaGUgZGlhbG9nIGJldHdlZW4g dGhlIEIyQlVBIGFuZCB0aGUgcmVtb3RlIFVBIGlzIHVuY2hhbmdlZC4NCg0KUmVnYXJkcywNCg0K Q2hyaXN0ZXINCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBkaXNwYXRj aC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86ZGlzcGF0Y2gtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIEnDsWFraSBCYXogQ2FzdGlsbG8NClNlbnQ6IDIwLiB0b3Vrb2t1dXRhIDIwMTMg MjA6MjENClRvOiBEYWxlIFIuIFdvcmxleQ0KQ2M6IGRpc3BhdGNoQGlldGYub3JnDQpTdWJqZWN0 OiBSZTogW2Rpc3BhdGNoXSBTdXJ2aXZpbmcgb3V0Ym91bmQNCg0KMjAxMy81LzE3IERhbGUgUi4g V29ybGV5IDx3b3JsZXlAYXJpYWRuZS5jb20+Og0KPiBJIGRvbid0IHNlZSBtdWNoIHZhbHVlIGlu IHdvcnJ5aW5nIGFib3V0IHRoZSBub24tR1JVVSBjYXNlLCBidXQgdGhlIA0KPiBHUlVVIGNhc2Ug aXMgYmVzdCBjdXJyZW50IHByYWN0aWNlIGFuZCB5ZXQgd2UgZG8gbm90IGN1cnJlbnRseSBoYXZl IGEgDQo+IGdlbmVyYWxseSBhY2NlcHRlZC9pbXBsZW1lbnRlZCBzb2x1dGlvbiB0byBkaWFsb2cg c3Vydml2YWwuDQoNCkl0IGp1c3Qgd29ya3MgaWYgdGhlIHJvdXRlIHNldCBpcyBtb2RpZmllZCBi eSB0aGUgaW50ZXJtZWRpYXJ5IHJlZ2lzdHJhciAodGhlIHJvdXRlIHNldCBiZXR3ZWVuIHRoZSBy ZWdpc3RyYXIgaXRzZWxmIGFuZCB0aGUgb3V0Ym91bmQgZWRnZSBwcm94eSB0aGUgdXNlciBpcyBj b25uZWN0ZWQgdG8pLiBBbmQgZm9yIHRoYXQgdG8gd29yaywgdGhlIHJlZ2lzdHJhciBtdXN0IGJl IGFibGUgdG8gcmVtb3ZlIFJvdXRlIGhlYWRlcnMgcG9pbnRpbmcgdG8gdGhlIG5leHQgaG9wICh0 aGUgb3V0Ym91bmQgcHJveHkpLg0KDQpTbyB5ZXMsIG5vIHJlYWwgd2F5Lg0KDQoNCi0tDQpJw7Fh a2kgQmF6IENhc3RpbGxvDQo8aWJjQGFsaWF4Lm5ldD4NCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpkaXNwYXRjaCBtYWlsaW5nIGxpc3QNCmRpc3BhdGNo QGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rpc3BhdGNo DQo= From oej@edvina.net Tue May 21 01:06:13 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33D6621F978E for ; Tue, 21 May 2013 01:06:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nhSDth-EIRJd for ; Tue, 21 May 2013 01:06:12 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 1FC2621F9785 for ; Tue, 21 May 2013 01:06:11 -0700 (PDT) Received: from [IPv6:2001:16d8:cc57:1000::42:1005] (unknown [IPv6:2001:16d8:cc57:1000::42:1005]) by smtp7.webway.se (Postfix) with ESMTPA id 9F54893C2A1; Tue, 21 May 2013 08:06:08 +0000 (UTC) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: "Olle E. Johansson" In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C374F9A@ESESSMB209.ericsson.se> Date: Tue, 21 May 2013 10:06:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <49B1CBCA-9F4E-4C35-A908-E348624764E0@edvina.net> <201305171623.r4HGNSr64942933@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C374F9A@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1503) Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Surviving outbound X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 08:06:13 -0000 21 maj 2013 kl. 09:30 skrev Christer Holmberg = : > Hi, >=20 > I fail to see the GRUU vs non-GRUU aspect, but maybe that is not = important :) >=20 > Perhaps there are scenarios where modifying the route set would work, = but the point is that is goes against RFC 3261, and as soon as the new = route set contains a new stateful proxy things will break, because it = will reject mid-dialog requests for dialogs it is not aware of. You mean a call stateful proxy? >=20 > The way e.g. 3GPP solves this, for different types of scenarios, is by = establishing a new dialog between the UA and some B2BUA. The dialog = between the B2BUA and the remote UA is unchanged. Well, that's application specific but nothing we can rely on as a = recommended solution. Seems like there is a gap to fill here. Many workarounds, but most of = them break RFC 3261. /O >=20 > Regards, >=20 > Christer >=20 >=20 >=20 > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of I=F1aki Baz Castillo > Sent: 20. toukokuuta 2013 20:21 > To: Dale R. Worley > Cc: dispatch@ietf.org > Subject: Re: [dispatch] Surviving outbound >=20 > 2013/5/17 Dale R. Worley : >> I don't see much value in worrying about the non-GRUU case, but the=20= >> GRUU case is best current practice and yet we do not currently have a=20= >> generally accepted/implemented solution to dialog survival. >=20 > It just works if the route set is modified by the intermediary = registrar (the route set between the registrar itself and the outbound = edge proxy the user is connected to). And for that to work, the = registrar must be able to remove Route headers pointing to the next hop = (the outbound proxy). >=20 > So yes, no real way. >=20 >=20 > -- > I=F1aki Baz Castillo > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From christer.holmberg@ericsson.com Tue May 21 02:02:13 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D22921F97BF for ; Tue, 21 May 2013 02:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.128 X-Spam-Level: X-Spam-Status: No, score=-6.128 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fpMoovhHcv4h for ; Tue, 21 May 2013 02:02:08 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id E270121F97BC for ; Tue, 21 May 2013 02:02:05 -0700 (PDT) X-AuditID: c1b4fb30-b7f8a6d000001a2d-b4-519b380cd87a Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id F4.7F.06701.C083B915; Tue, 21 May 2013 11:02:05 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.02.0328.009; Tue, 21 May 2013 11:02:04 +0200 From: Christer Holmberg To: "Olle E. Johansson" Thread-Topic: [dispatch] Surviving outbound Thread-Index: AQHOUv2jlBlAIDXlOkq3RTDO3gs7f5kJj/4NgASlVgCAAQym4P//6pwAgAAwjiA= Date: Tue, 21 May 2013 09:02:04 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C375170@ESESSMB209.ericsson.se> References: <49B1CBCA-9F4E-4C35-A908-E348624764E0@edvina.net> <201305171623.r4HGNSr64942933@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C374F9A@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHLMWRmVeSWpSXmKPExsUyM+JvrS6vxexAg5372SyWTlrAajF9n43F y9WHmC1enihzYPE41/Ce3WPy/q/MHtPWrmT1WLLkJ1MASxSXTUpqTmZZapG+XQJXxuYbj5gL 3ghWzPoylbGBcTNfFyMnh4SAiUT79FvsELaYxIV769lAbCGBw4wSu2ZndzFyAdlLGCVWTu5n 7GLk4GATsJDo/qcNUiMioCFx4csVNpAaZoFuRokPG1cwgiSEBbQkDu7oZ4Eo0pb4u/ARM4Tt J3Fv73WwBSwCqhK3O2exgti8Ar4Sa87dZIFYtolJ4kDHfLAGTgE7ifnbboI1MAJd9/3UGiYQ m1lAXOLWk/lMEFcLSCzZc54ZwhaVePn4HyvIoRICihLL++UgyvUkbkydwgZha0ssW/iaGWKv oMTJmU9YJjCKzUIydRaSlllIWmYhaVnAyLKKkT03MTMnvdx8EyMwjg5u+W2wg3HTfbFDjNIc LErivH3aUwOFBNITS1KzU1MLUovii0pzUosPMTJxcEo1MDp4717k2aHvNMPtlcanVLmMvCdT RcXqnm7NTWi/d2rNy/+6dYZF/jybgrfcj1CN+Lx43d7LHL6ZV5kZj/yqS7R1u2yWttzjF0cf 58IbG7R2x+of/Pwp0iKzeZHUjLA4yR+XGlom5O4/0uASznmqxvPlkYcz1HffmvpOqO/IjEWW 0VFBAV+m7FdiKc5INNRiLipOBAB2i8h2cQIAAA== Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Surviving outbound X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 09:02:13 -0000 Hi, >> I fail to see the GRUU vs non-GRUU aspect, but maybe that is not=20 >> important :) >>=20 >> Perhaps there are scenarios where modifying the route set would work, bu= t the point is that is goes against=20 >> RFC 3261, and as soon as the new route set contains a new stateful proxy= things will break, because it will reject mid-dialog requests for dialogs = it is not aware of. >You mean a call stateful proxy? Yes.=20 >> The way e.g. 3GPP solves this, for different types of scenarios, is by e= stablishing a new dialog between the UA and some B2BUA. The dialog between = the B2BUA and the remote UA is unchanged. > Well, that's application specific but nothing we can rely on as a recomme= nded solution. > > Seems like there is a gap to fill here. Many workarounds, but most of the= m break RFC 3261. You could use the Replaces header field (RFC 3891), but you would still rep= lace one dialog with another, rather than updating the route set for an exi= sting dialog. Regards, Christer > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On=20 > Behalf Of I=F1aki Baz Castillo > Sent: 20. toukokuuta 2013 20:21 > To: Dale R. Worley > Cc: dispatch@ietf.org > Subject: Re: [dispatch] Surviving outbound >=20 > 2013/5/17 Dale R. Worley : >> I don't see much value in worrying about the non-GRUU case, but the=20 >> GRUU case is best current practice and yet we do not currently have a=20 >> generally accepted/implemented solution to dialog survival. >=20 > It just works if the route set is modified by the intermediary registrar = (the route set between the registrar itself and the outbound edge proxy the= user is connected to). And for that to work, the registrar must be able to= remove Route headers pointing to the next hop (the outbound proxy). >=20 > So yes, no real way. >=20 >=20 > -- > I=F1aki Baz Castillo > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From oej@edvina.net Tue May 21 02:08:17 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0217B21F97D4 for ; Tue, 21 May 2013 02:08:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nr16mikOX9gc for ; Tue, 21 May 2013 02:08:16 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 9D5B621F97C2 for ; Tue, 21 May 2013 02:08:13 -0700 (PDT) Received: from [192.168.40.5] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 4CFB293C1AF; Tue, 21 May 2013 09:08:12 +0000 (UTC) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: "Olle E. Johansson" In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C375170@ESESSMB209.ericsson.se> Date: Tue, 21 May 2013 11:08:11 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <49B1CBCA-9F4E-4C35-A908-E348624764E0@edvina.net> <201305171623.r4HGNSr64942933@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C374F9A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C375170@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1503) Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Surviving outbound X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 09:08:17 -0000 21 maj 2013 kl. 11:02 skrev Christer Holmberg = : > Hi, >=20 >>> I fail to see the GRUU vs non-GRUU aspect, but maybe that is not=20 >>> important :) >>>=20 >>> Perhaps there are scenarios where modifying the route set would = work, but the point is that is goes against=20 >>> RFC 3261, and as soon as the new route set contains a new stateful = proxy things will break, because it will reject mid-dialog requests for = dialogs it is not aware of. >> You mean a call stateful proxy? >=20 > Yes.=20 >=20 >>> The way e.g. 3GPP solves this, for different types of scenarios, is = by establishing a new dialog between the UA and some B2BUA. The dialog = between the B2BUA and the remote UA is unchanged. >> Well, that's application specific but nothing we can rely on as a = recommended solution. >>=20 >> Seems like there is a gap to fill here. Many workarounds, but most of = them break RFC 3261. >=20 > You could use the Replaces header field (RFC 3891), but you would = still replace one dialog with another, rather than updating the route = set for an existing dialog. So the logic is that if a UA finds out that one flow is broken, it = checks if there was any active dialogs running on that flow. If there = was, you send INVITE with replaces to re-capture the calls on a working = flow. In theory that could work regardless of b2bua. You restart ICE and = reset any SRTP streams as well. Yeah, that works. Interesting. Like outbound, you put the responsibility = for dialog survival on the UA, which seems logical in a Spock sense. Thanks for the feedback. Anyone that sees problems with that? Could that become a BCP? /O= From ibc@aliax.net Tue May 21 02:14:22 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C908921F978F for ; Tue, 21 May 2013 02:14:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.178 X-Spam-Level: X-Spam-Status: No, score=-2.178 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-rSssbq3cMk for ; Tue, 21 May 2013 02:14:03 -0700 (PDT) Received: from mail-qe0-f44.google.com (mail-qe0-f44.google.com [209.85.128.44]) by ietfa.amsl.com (Postfix) with ESMTP id EAB9A21F8D00 for ; Tue, 21 May 2013 02:14:02 -0700 (PDT) Received: by mail-qe0-f44.google.com with SMTP id 6so209394qeb.3 for ; Tue, 21 May 2013 02:14:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=ZqWV+3nrk3rlRnWHM/Qt2UNVfpUMw3W93eKzx8TDvtk=; b=m/nTtzDgSw89vn8nRYdCCQDN3x8s4QEKPMDn/B+G6EPDHrOYevbvlbqowVJLQDjgrV WPyxPbvgvYa6Ft2eRme9xtCdwz/iRw4DL9g0hZUKzlHes7MzpKvj6eC5fqrxdrRRYjYc M21MKBjudwxaNJbyaYK3VbohMXWKr79KUoZaGTZ2SzhsLrtwBrSYpN8G2N1AH4MK9d5/ Xhrwi5eGQqV9ToW0DuDAkd1h7O55jxm/boDmMmxtSXTMIBhTCvc5P56aVlkC9Tcg3tHf zQwAFAKaRS2ysHUcikxhf3QPorrGGb3+s9k2xNmY7E83IIcq458vTYNVpM9eufr9zRZL Xb7g== X-Received: by 10.224.109.65 with SMTP id i1mr1696763qap.50.1369127642398; Tue, 21 May 2013 02:14:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.26.103 with HTTP; Tue, 21 May 2013 02:13:42 -0700 (PDT) In-Reply-To: References: <49B1CBCA-9F4E-4C35-A908-E348624764E0@edvina.net> <201305171623.r4HGNSr64942933@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C374F9A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C375170@ESESSMB209.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 21 May 2013 11:13:42 +0200 Message-ID: To: "Olle E. Johansson" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnKBDG2KH29s7Kw8fTiRRebcqRcTLvIW8jUzhLjh8/sRsjXbdfH/GCGvlYAKdVqvOpv9tqi Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Surviving outbound X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 09:14:22 -0000 2013/5/21 Olle E. Johansson : > Anyone that sees problems with that? Could that become a BCP? The ellegant solution (without envolving re-negotiation of every sessions) would be that the connection problem between the UA and its outbound proxy (or registrar) was "fixed" by themself in a transparent way. -- I=C3=B1aki Baz Castillo From christer.holmberg@ericsson.com Tue May 21 02:25:36 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9FAC21F96FC for ; Tue, 21 May 2013 02:25:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.133 X-Spam-Level: X-Spam-Status: No, score=-6.133 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yXpk5lWJhWkz for ; Tue, 21 May 2013 02:25:26 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 915DE21F929F for ; Tue, 21 May 2013 02:25:25 -0700 (PDT) X-AuditID: c1b4fb25-b7efb6d000007c26-4e-519b3d843765 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id EE.94.31782.48D3B915; Tue, 21 May 2013 11:25:24 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.02.0328.009; Tue, 21 May 2013 11:25:23 +0200 From: Christer Holmberg To: "Olle E. Johansson" Thread-Topic: [dispatch] Surviving outbound Thread-Index: AQHOUv2jlBlAIDXlOkq3RTDO3gs7f5kJj/4NgASlVgCAAQym4P//6pwAgAAwjiD//+DIgIAAJHmA Date: Tue, 21 May 2013 09:25:22 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3751D5@ESESSMB209.ericsson.se> References: <49B1CBCA-9F4E-4C35-A908-E348624764E0@edvina.net> <201305171623.r4HGNSr64942933@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C374F9A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C375170@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrLLMWRmVeSWpSXmKPExsUyM+JvrW6L7exAg50vFCyWTlrAajF9n43F y9WHmC1enihzYPE41/Ce3WPy/q/MHtPWrmT1WLLkJ1MASxSXTUpqTmZZapG+XQJXxsZPh5kK 1vBXPNg1jbmBsZWni5GTQ0LAROLmt0+sELaYxIV769m6GLk4hAQOM0pM/H6VCcJZwiixZsEf 9i5GDg42AQuJ7n/aIA0iAhoSF75cAWtgFuhmlPiwcQUjSEJYQEvi4I5+FogibYm/Cx8xQ9hR EtcPHQCzWQRUJV6ubGcGmckr4Cvxsl0PYtcqZolL/S0sIHFOATuJHat1QMoZgY77fmoNE4jN LCAucevJfCaIowUkluw5zwxhi0q8fPyPFaRVQkBRYnm/HES5nsSNqVPYIGxtiWULX4OV8woI Spyc+YRlAqPYLCRTZyFpmYWkZRaSlgWMLKsY2XMTM3PSy402MQKj6OCW36o7GO+cEznEKM3B oiTO26s9NVBIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDI+u7qfkTLm89xjTH/KdOWfT0smPW y5acCI/Kjo7bneZYNl/GXSM4Q2y+48H3z4I2H515cgl/DNMqGVXD7aWHk/Z19HDI31XNm8xf q54z9c195Q9f7wgFeDqJCYssnR+ocpIv/XgXm/2tbc4yl287bfundf/oP8VJ3NlROh5bJzzV cFffYHZeX4mlOCPRUIu5qDgRAPW+AYNwAgAA Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Surviving outbound X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 09:25:36 -0000 Hi, >>>> I fail to see the GRUU vs non-GRUU aspect, but maybe that is not=20 >>>> important :) >>>>=20 >>>> Perhaps there are scenarios where modifying the route set would=20 >>>> work, but the point is that is goes against RFC 3261, and as soon as t= he new route set contains a new stateful proxy things will break, because i= t will reject mid-dialog requests for dialogs it is not aware of. >>> You mean a call stateful proxy? >>=20 >> Yes.=20 >>=20 >>>> The way e.g. 3GPP solves this, for different types of scenarios, is by= establishing a new dialog between the UA and some B2BUA. The dialog betwee= n the B2BUA and the remote UA is unchanged. >>> Well, that's application specific but nothing we can rely on as a recom= mended solution. >>>=20 >>> Seems like there is a gap to fill here. Many workarounds, but most of t= hem break RFC 3261. >>=20 >> You could use the Replaces header field (RFC 3891), but you would still = replace one dialog with another, rather than updating the route set for an = existing dialog. > > So the logic is that if a UA finds out that one flow is broken, it checks= if there was any active dialogs running on that flow. If there was, you se= nd INVITE with replaces to re-capture the calls on a working flow.=20 Yes. > In theory that could work regardless of b2bua. You restart ICE and reset = any SRTP streams as well. Sure. A B2BUA could "hide" the dialog change from the remote UE, but techni= cally there is no difference. > Yeah, that works. As long as there is no intermediary changing the dialog identifier, resulti= ng in the receiver not finding the dialog identified by the Replaces header= field :) Session-id could work, but I believe it is outside the scope to use it for = this kind of functionality. > Anyone that sees problems with that? Could that become a BCP? If people think such BCP is needed, I would not object :) Regards, Christer From oej@edvina.net Tue May 21 03:19:37 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 915D621F9008 for ; Tue, 21 May 2013 03:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FsomwPCVPkFW for ; Tue, 21 May 2013 03:19:37 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id CDFEB21F9003 for ; Tue, 21 May 2013 03:19:35 -0700 (PDT) Received: from [IPv6:2001:16d8:cc57:1000::42:1005] (unknown [IPv6:2001:16d8:cc57:1000::42:1005]) by smtp7.webway.se (Postfix) with ESMTPA id 8347893C1AF; Tue, 21 May 2013 10:19:32 +0000 (UTC) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: "Olle E. Johansson" In-Reply-To: Date: Tue, 21 May 2013 12:19:32 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <069902B7-0DDB-4B40-A3C1-BF958D2BA84A@edvina.net> References: <49B1CBCA-9F4E-4C35-A908-E348624764E0@edvina.net> <201305171623.r4HGNSr64942933@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C374F9A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C375170@ESESSMB209.ericsson.se> To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1503) Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Surviving outbound X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 10:19:37 -0000 21 maj 2013 kl. 11:13 skrev I=F1aki Baz Castillo : > 2013/5/21 Olle E. Johansson : >> Anyone that sees problems with that? Could that become a BCP? >=20 > The ellegant solution (without envolving re-negotiation of every > sessions) would be that the connection problem between the UA and its > outbound proxy (or registrar) was "fixed" by themself in a transparent > way. >=20 Absolutely. But that would require a new RFC. If we go down that path - how would it look. The path header that becomes part of the route set is the problem here, = right. The route set can not change during the lifetime of the dialog. Typically the path header includes a flow token and an IP address. Can we change the content of the path to something that doesn't point to = a specific flow, but a set of flows? A group of edge proxys? /O= From oej@edvina.net Tue May 21 03:25:51 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6556521F8900 for ; Tue, 21 May 2013 03:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.375 X-Spam-Level: X-Spam-Status: No, score=-2.375 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BFc+Yf00-p2c for ; Tue, 21 May 2013 03:25:51 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 2008F21F95C3 for ; Tue, 21 May 2013 03:25:43 -0700 (PDT) Received: from [IPv6:2001:16d8:cc57:1000::42:1005] (unknown [IPv6:2001:16d8:cc57:1000::42:1005]) by smtp7.webway.se (Postfix) with ESMTPA id EE77093C2A1; Tue, 21 May 2013 10:25:42 +0000 (UTC) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: "Olle E. Johansson" In-Reply-To: <069902B7-0DDB-4B40-A3C1-BF958D2BA84A@edvina.net> Date: Tue, 21 May 2013 12:25:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <27A4FEA8-12CE-4764-A34F-A82929FA3D14@edvina.net> References: <49B1CBCA-9F4E-4C35-A908-E348624764E0@edvina.net> <201305171623.r4HGNSr64942933@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C374F9A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C375170@ESESSMB209.ericsson.se> <069902B7-0DDB-4B40-A3C1-BF958D2BA84A@edvina.net> To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1503) Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Surviving outbound X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 10:25:51 -0000 21 maj 2013 kl. 12:19 skrev "Olle E. Johansson" : >=20 > 21 maj 2013 kl. 11:13 skrev I=F1aki Baz Castillo : >=20 >> 2013/5/21 Olle E. Johansson : >>> Anyone that sees problems with that? Could that become a BCP? >>=20 >> The ellegant solution (without envolving re-negotiation of every >> sessions) would be that the connection problem between the UA and its >> outbound proxy (or registrar) was "fixed" by themself in a = transparent >> way. >>=20 >=20 > Absolutely. But that would require a new RFC. >=20 > If we go down that path - how would it look. >=20 > The path header that becomes part of the route set is the problem = here, right. The route set can not change > during the lifetime of the dialog. >=20 > Typically the path header includes a flow token and an IP address. >=20 > Can we change the content of the path to something that doesn't point = to a specific flow, but a set of > flows? A group of edge proxys? Why restrict a dialog to a specific flow, btw? Even RFC 3263 suggests sending in-dialog requests to other proxys if the = first one fails. It doesn't specify how, but I suspect that the = recommendation is to use DNS names in route headers, names that has = multiple SRV records. Just brainstorming. /O= From ibc@aliax.net Tue May 21 04:15:03 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FBF421F93BD for ; Tue, 21 May 2013 04:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yrt-LESrc17i for ; Tue, 21 May 2013 04:15:02 -0700 (PDT) Received: from mail-qa0-x232.google.com (mail-qa0-x232.google.com [IPv6:2607:f8b0:400d:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id BF49621F93B7 for ; Tue, 21 May 2013 04:15:01 -0700 (PDT) Received: by mail-qa0-f50.google.com with SMTP id bn16so299094qab.16 for ; Tue, 21 May 2013 04:15:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=JW4S7CQq70/OLwePNzDHYtEsQdVzQN1oeHt80fF1akw=; b=UJVg4+MzPcZeMStVehvG06B2ZR9bmSPShdlFxCwduxoJM1/hJd+r91ybYMvQF2zjOr l+QNJGeTJlQRICwZ8a9tcSFM2xA90zDYVEQuHdGjl9QHppPcq8GLftsfWlVVfXGP51D4 9Ek27fklBfAJ4pdW/DlZBT3uCsM8Gl9JqFEaxT0W4BGdDVyopm5WwBci7yVf3ZAZfzqi qUQuksFJ5AjKAlFOymZ/Zf4hLjjdQuQrsyd2f7NTJUES1rR+GIXFU1PReryaZvDgCM20 vS4DOM/opNYwOv5+tXfAuDugqUyBPtXFsitsJEDgHdZwA8Cc6kBZ3kz5bEQMXgJqesqk 2DJA== X-Received: by 10.229.149.198 with SMTP id u6mr719230qcv.20.1369134900925; Tue, 21 May 2013 04:15:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.26.103 with HTTP; Tue, 21 May 2013 04:14:40 -0700 (PDT) In-Reply-To: <069902B7-0DDB-4B40-A3C1-BF958D2BA84A@edvina.net> References: <49B1CBCA-9F4E-4C35-A908-E348624764E0@edvina.net> <201305171623.r4HGNSr64942933@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C374F9A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C375170@ESESSMB209.ericsson.se> <069902B7-0DDB-4B40-A3C1-BF958D2BA84A@edvina.net> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 21 May 2013 13:14:40 +0200 Message-ID: To: "Olle E. Johansson" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlFRXq/B6edZGmx6SjQFz5rPV6ZIT1Bah99lSDfyZYitDctxDcO+CWr9pnqHycDW8b7ZLiY Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Surviving outbound X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 11:15:03 -0000 2013/5/21 Olle E. Johansson : > The path header that becomes part of the route set is the problem here, r= ight. The route set can not change > during the lifetime of the dialog. So don't change the route set :) > Typically the path header includes a flow token and an IP address. Yes, if it is an outbound edge proxy. > Can we change the content of the path to something that doesn't point to = a specific flow, but a set of > flows? A group of edge proxys? That would require changes to Outbound so 100% discouraged IMHO. I have another idea on mind: - Client connects to the Outbound EDGE proxy (or registrar). - Client sends REGISTER. - The proxy assigns an Outbound Flow Token id and enters it into the Path header. - The registrar replies 200. - The proxy adds a header to the 200 before routing it to the client: Outbound-Info: flow-token=3DABCD;recovery-passwd=3D1234 - The client is in a dialog with Bob. - The connection of the client is closed (proxy restarted or whatever). - The client detects it, reconnects to the proxy, and sends a new REGISTER (a refresh REGISTER) with an extra header: Outbound-Replace: flow-token=3DABCD;recovery-passwd=3D1234 - The proxy assigns the *same* flow token to this new connection so routes the REGISTER with same Path value as before. - Bob sends BYE. BYE arrives to the Outbound Proxy with the Route header including flow token ABCD (as usual). - The outbound proxy routes it via the new connection that previously replaced the old one. Transparent, no route set changes, no Outbound changes (just an extension to be supported by the client and its outbound proxy). Cool? -- I=C3=B1aki Baz Castillo From oej@edvina.net Tue May 21 04:29:35 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C58821F88FB for ; Tue, 21 May 2013 04:29:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.984 X-Spam-Level: X-Spam-Status: No, score=-1.984 tagged_above=-999 required=5 tests=[AWL=0.315, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dnkx5iCj6Ofx for ; Tue, 21 May 2013 04:29:34 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id E240A21F84EF for ; Tue, 21 May 2013 04:29:32 -0700 (PDT) Received: from [192.168.40.5] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id E005393C1AF; Tue, 21 May 2013 11:29:31 +0000 (UTC) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: "Olle E. Johansson" In-Reply-To: Date: Tue, 21 May 2013 13:29:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <49B1CBCA-9F4E-4C35-A908-E348624764E0@edvina.net> <201305171623.r4HGNSr64942933@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C374F9A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C375170@ESESSMB209.ericsson.se> <069902B7-0DDB-4B40-A3C1-BF958D2BA84A@edvina.net> To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1503) Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Surviving outbound X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 11:29:35 -0000 21 maj 2013 kl. 13:14 skrev I=F1aki Baz Castillo : > 2013/5/21 Olle E. Johansson : >> The path header that becomes part of the route set is the problem = here, right. The route set can not change >> during the lifetime of the dialog. >=20 > So don't change the route set :) >=20 >=20 >> Typically the path header includes a flow token and an IP address. >=20 > Yes, if it is an outbound edge proxy. >=20 >=20 >> Can we change the content of the path to something that doesn't point = to a specific flow, but a set of >> flows? A group of edge proxys? >=20 > That would require changes to Outbound so 100% discouraged IMHO. I > have another idea on mind: >=20 > - Client connects to the Outbound EDGE proxy (or registrar). >=20 > - Client sends REGISTER. >=20 > - The proxy assigns an Outbound Flow Token id and enters it into the > Path header. What's in the Path header? Details, please! >=20 > - The registrar replies 200. >=20 > - The proxy adds a header to the 200 before routing it to the client: >=20 > Outbound-Info: flow-token=3DABCD;recovery-passwd=3D1234 >=20 > - The client is in a dialog with Bob. >=20 > - The connection of the client is closed (proxy restarted or = whatever). >=20 > - The client detects it, reconnects to the proxy, and sends a new > REGISTER (a refresh REGISTER) with an extra header: >=20 > Outbound-Replace: flow-token=3DABCD;recovery-passwd=3D1234 The client should already have a working flow with another edge proxy. = That's the idea with outbound - we don't have to wait for a new flow to open up. >=20 > - The proxy assigns the *same* flow token to this new connection so > routes the REGISTER with same Path value as before. >=20 > - Bob sends BYE. BYE arrives to the Outbound Proxy with the Route > header including flow token ABCD (as usual). >=20 > - The outbound proxy routes it via the new connection that previously > replaced the old one. >=20 > Transparent, no route set changes, no Outbound changes (just an > extension to be supported by the client and its outbound proxy). It would be faster if we could use the existing flow. Try that for a challenge :-) /O >=20 >=20 > Cool? >=20 >=20 > -- > I=F1aki Baz Castillo > From ibc@aliax.net Tue May 21 04:40:23 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A49321F8A54 for ; Tue, 21 May 2013 04:40:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XwpO-prCLYLQ for ; Tue, 21 May 2013 04:40:22 -0700 (PDT) Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id A7DAE21F89D5 for ; Tue, 21 May 2013 04:40:22 -0700 (PDT) Received: by mail-qc0-f179.google.com with SMTP id e1so253646qcx.24 for ; Tue, 21 May 2013 04:40:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=znSQ6jM9kwr8WD4560jfrTd4Kap24ClcTsFWH2N4oBA=; b=gPOjxcqChL0nyBbW6N8Tcu9b+pcnKDbYGLYrBIbYLZZN7jENreZIlSlUZ/czHbZbj2 X4IP6XqJCPdAxcqvAXAUui0vWFzZpjEKWvRvDmDWH2iwKUSQxZUsJ8oaEk8qrwXq+HL+ rusm1u5+qE5kRWWInEYJUd5Sw+tQfxxAIDHd2em7UVkzFIUQCR03E8fcsHTEicqktotM /J8fhAeUgEXRMJH7ZZgX5MWf4D93Esn0WGv2TQchdIBt/87DeSmFAEVPCKLAEsVi4Nse 7reRehfTUICmkCXn4mKRmFXT1J0vbuXmTR578G9ESBiN60jC4ahy5qQIraN4IpVrfz4a g6FA== X-Received: by 10.229.124.80 with SMTP id t16mr693952qcr.93.1369136421929; Tue, 21 May 2013 04:40:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.26.103 with HTTP; Tue, 21 May 2013 04:40:01 -0700 (PDT) In-Reply-To: References: <49B1CBCA-9F4E-4C35-A908-E348624764E0@edvina.net> <201305171623.r4HGNSr64942933@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C374F9A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C375170@ESESSMB209.ericsson.se> <069902B7-0DDB-4B40-A3C1-BF958D2BA84A@edvina.net> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 21 May 2013 13:40:01 +0200 Message-ID: To: "Olle E. Johansson" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmKX5sOfqruikrP2cH0IeQ7ujwvsYLm+BkX7lh4Weh8fr5VYtWsiLOAaB09MxHZKXlN5Wft Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Surviving outbound X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 11:40:23 -0000 2013/5/21 Olle E. Johansson : > > 21 maj 2013 kl. 13:14 skrev I=C3=B1aki Baz Castillo : >> - Client connects to the Outbound EDGE proxy (or registrar). >> >> - Client sends REGISTER. >> >> - The proxy assigns an Outbound Flow Token id and enters it into the >> Path header. > What's in the Path header? Details, please! Usual content: Path: >> - The registrar replies 200. >> >> - The proxy adds a header to the 200 before routing it to the client: >> >> Outbound-Info: flow-token=3DABCD;recovery-passwd=3D1234 >> >> - The client is in a dialog with Bob. >> >> - The connection of the client is closed (proxy restarted or whatever). >> >> - The client detects it, reconnects to the proxy, and sends a new >> REGISTER (a refresh REGISTER) with an extra header: >> >> Outbound-Replace: flow-token=3DABCD;recovery-passwd=3D1234 > The client should already have a working flow with another edge proxy. Th= at's the idea > with outbound - we don't have to wait for a new flow to open up. Nobody cares about mobile networks? having two connections is really a bad idea for a mobile (battery). I don't like the "multi connection solution" proposed by RFC 5626. I prefer= : - Connection is closed. - UA try to reconnect to the same server. - If it fails connect to the other server (based on RFC 3263 and so on). >> - The proxy assigns the *same* flow token to this new connection so >> routes the REGISTER with same Path value as before. >> >> - Bob sends BYE. BYE arrives to the Outbound Proxy with the Route >> header including flow token ABCD (as usual). >> >> - The outbound proxy routes it via the new connection that previously >> replaced the old one. >> >> Transparent, no route set changes, no Outbound changes (just an >> extension to be supported by the client and its outbound proxy). > It would be faster if we could use the existing flow. But that exactly my proposal: the flow token id is the same in the nex connection with the outbound proxy. It something like: - Hi outbound proxy, my previous connection with flow token ABCD has been closed, so let me assign flow token ABCD to this new connection I'm establishing with you, so I will be able to receive incoming requests for existing dialogs. -- I=C3=B1aki Baz Castillo From oej@edvina.net Tue May 21 04:56:16 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16CF921F96D2 for ; Tue, 21 May 2013 04:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29lHqDvbjwOd for ; Tue, 21 May 2013 04:56:15 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 0C5EF21F96B6 for ; Tue, 21 May 2013 04:56:15 -0700 (PDT) Received: from [IPv6:2001:16d8:cc57:1000::42:1005] (unknown [IPv6:2001:16d8:cc57:1000::42:1005]) by smtp7.webway.se (Postfix) with ESMTPA id 308D493C1AF; Tue, 21 May 2013 11:56:14 +0000 (UTC) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: "Olle E. Johansson" In-Reply-To: Date: Tue, 21 May 2013 13:56:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <49B1CBCA-9F4E-4C35-A908-E348624764E0@edvina.net> <201305171623.r4HGNSr64942933@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C374F9A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C375170@ESESSMB209.ericsson.se> <069902B7-0DDB-4B40-A3C1-BF958D2BA84A@edvina.net> To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1503) Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Surviving outbound X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 11:56:16 -0000 21 maj 2013 kl. 13:40 skrev I=F1aki Baz Castillo : > 2013/5/21 Olle E. Johansson : >>=20 >> 21 maj 2013 kl. 13:14 skrev I=F1aki Baz Castillo : >=20 >>> - Client connects to the Outbound EDGE proxy (or registrar). >>>=20 >>> - Client sends REGISTER. >>>=20 >>> - The proxy assigns an Outbound Flow Token id and enters it into the >>> Path header. >> What's in the Path header? Details, please! >=20 > Usual content: >=20 > Path: That IP_PROXY is a problem for failover to another flow. >=20 >=20 >=20 >>> - The registrar replies 200. >>>=20 >>> - The proxy adds a header to the 200 before routing it to the = client: >>>=20 >>> Outbound-Info: flow-token=3DABCD;recovery-passwd=3D1234 >>>=20 >>> - The client is in a dialog with Bob. >>>=20 >>> - The connection of the client is closed (proxy restarted or = whatever). >>>=20 >>> - The client detects it, reconnects to the proxy, and sends a new >>> REGISTER (a refresh REGISTER) with an extra header: >>>=20 >>> Outbound-Replace: flow-token=3DABCD;recovery-passwd=3D1234 >> The client should already have a working flow with another edge = proxy. That's the idea >> with outbound - we don't have to wait for a new flow to open up. >=20 > Nobody cares about mobile networks? having two connections is really a > bad idea for a mobile (battery). I guess that's why IMS does the INVITE/REPLACE thing. >=20 > I don't like the "multi connection solution" proposed by RFC 5626. I = prefer: >=20 > - Connection is closed. >=20 > - UA try to reconnect to the same server. >=20 > - If it fails connect to the other server (based on RFC 3263 and so = on). >=20 >=20 >=20 >=20 >>> - The proxy assigns the *same* flow token to this new connection so >>> routes the REGISTER with same Path value as before. >>>=20 >>> - Bob sends BYE. BYE arrives to the Outbound Proxy with the Route >>> header including flow token ABCD (as usual). >>>=20 >>> - The outbound proxy routes it via the new connection that = previously >>> replaced the old one. >>>=20 >>> Transparent, no route set changes, no Outbound changes (just an >>> extension to be supported by the client and its outbound proxy). >=20 >> It would be faster if we could use the existing flow. >=20 > But that exactly my proposal: the flow token id is the same in the nex > connection with the outbound proxy. It something like: No, you set up a new flow with the identifier of an old, broken, one. = That's different. >=20 > - Hi outbound proxy, my previous connection with flow token ABCD has > been closed, so let me assign flow token ABCD to this new connection > I'm establishing with you, so I will be able to receive incoming > requests for existing dialogs. Connection setup can take a long time - considering you set up TLS to the server and verify with OCSP and the edge proxy sets up a new TLS and verifies that one and then the registrar needs to talk with a=20 database and...=20 TCP setup is three roundtrip messages, TLS at least nine. Add digest = auth before your registration is done. The client will be down for a long time - will a request coming in from = the other side survive this time or will the dialog fail anyway? /O >=20 >=20 >=20 >=20 > -- > I=F1aki Baz Castillo > From ibc@aliax.net Tue May 21 05:11:08 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE81921F8A53 for ; Tue, 21 May 2013 05:11:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7rHVm60RXaRE for ; Tue, 21 May 2013 05:11:08 -0700 (PDT) Received: from mail-qc0-x22f.google.com (mail-qc0-x22f.google.com [IPv6:2607:f8b0:400d:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id AD9B221F88AC for ; Tue, 21 May 2013 05:11:07 -0700 (PDT) Received: by mail-qc0-f175.google.com with SMTP id a1so273702qcx.34 for ; Tue, 21 May 2013 05:11:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=FimutldY55XuTwKEA21E96yjZyjcVFhQ+1OYYDQ/xJM=; b=nKwxgCxDpGJtThq/wjUIszP/h3qJPiEl9KqmtVkFXAO7BmXtwKF+qkZRxX3EOQwWMv 1mqYgWuEFTF1+QPTRc7QzkRj8hsnhZPc+orApPHhAvDgiLd5ZHDq2lFVjd6yMZV2R6Tl 0amXit7FZ/iWvRAIp9tD21WzKYeRYzvHqSanLv7+RG1lv31RpSBE7QS9WDS9wrPd18Ys 5qMsdOzlCzPfIn7IuQzC7P0L6RAboCfGLBn2WIFd4xsbvK27yB6tTw/wC7dxsXQcyG2U j0Ra9v6/jeJXJ0IpOMGgFjOAQ9lA2S9SyEFa1xg+iAQCrELnGOPKcxH9+CsNQwtjLmTP vLrA== X-Received: by 10.224.201.198 with SMTP id fb6mr2239756qab.68.1369138267065; Tue, 21 May 2013 05:11:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.26.103 with HTTP; Tue, 21 May 2013 05:10:47 -0700 (PDT) In-Reply-To: References: <49B1CBCA-9F4E-4C35-A908-E348624764E0@edvina.net> <201305171623.r4HGNSr64942933@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C374F9A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C375170@ESESSMB209.ericsson.se> <069902B7-0DDB-4B40-A3C1-BF958D2BA84A@edvina.net> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 21 May 2013 14:10:47 +0200 Message-ID: To: "Olle E. Johansson" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmV2XSSASvGn2/j81RXcvBkLfEw7Xy5M0bv+RDG7ai4SlCFSVkEqSSMNAnCILqBMQDRx/Ll Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Surviving outbound X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 12:11:08 -0000 2013/5/21 Olle E. Johansson : >>> What's in the Path header? Details, please! >> >> Usual content: >> >> Path: > That IP_PROXY is a problem for failover to another flow. Yes. I insisit: I don't like the "two connections" approach :) >> Nobody cares about mobile networks? having two connections is really a >> bad idea for a mobile (battery). > I guess that's why IMS does the INVITE/REPLACE thing. This is a SIP design fault if we need to renegotiate a session just because the connection between the client and its outbound proxy has been closed. >>> It would be faster if we could use the existing flow. >> >> But that exactly my proposal: the flow token id is the same in the nex >> connection with the outbound proxy. It something like: > No, you set up a new flow with the identifier of an old, broken, one. Tha= t's different. But the "existing" flow is broken, right? :) so how to use it? >> - Hi outbound proxy, my previous connection with flow token ABCD has >> been closed, so let me assign flow token ABCD to this new connection >> I'm establishing with you, so I will be able to receive incoming >> requests for existing dialogs. > Connection setup can take a long time - considering you set up TLS > to the server and verify with OCSP and the edge proxy sets up a new > TLS and verifies that one and then the registrar needs to talk with a > database and... > TCP setup is three roundtrip messages, TLS at least nine. Add digest auth > before your registration is done. > > The client will be down for a long time - will a request coming in from t= he other > side survive this time or will the dialog fail anyway? If the client had a single connection (true in 99% of cases and appropriate for mobile networks) then a reconnection is needed anyway, right? The reconnection and re-registration could take may be 3 seconds. IMHO it is not so hard to assume that we are not going to receive in-dialog requests during that process. -- I=C3=B1aki Baz Castillo From oej@edvina.net Tue May 21 05:36:15 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2953B21F8F27 for ; Tue, 21 May 2013 05:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.338 X-Spam-Level: X-Spam-Status: No, score=-2.338 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pDWYwH9Dggpc for ; Tue, 21 May 2013 05:36:14 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id CE4C421F8C23 for ; Tue, 21 May 2013 05:36:13 -0700 (PDT) Received: from [IPv6:2001:16d8:cc57:1000::42:1005] (unknown [IPv6:2001:16d8:cc57:1000::42:1005]) by smtp7.webway.se (Postfix) with ESMTPA id 5DAC493C1AF; Tue, 21 May 2013 12:36:12 +0000 (UTC) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: "Olle E. Johansson" In-Reply-To: Date: Tue, 21 May 2013 14:36:11 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <49B1CBCA-9F4E-4C35-A908-E348624764E0@edvina.net> <201305171623.r4HGNSr64942933@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C374F9A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C375170@ESESSMB209.ericsson.se> <069902B7-0DDB-4B40-A3C1-BF958D2BA84A@edvina.net> To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1503) Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Surviving outbound X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 12:36:15 -0000 21 maj 2013 kl. 14:10 skrev I=F1aki Baz Castillo : > 2013/5/21 Olle E. Johansson : >>>> What's in the Path header? Details, please! >>>=20 >>> Usual content: >>>=20 >>> Path: >=20 >> That IP_PROXY is a problem for failover to another flow. >=20 > Yes. I insisit: I don't like the "two connections" approach :) I insist that it is the intention of Outbound to have it. Let's try to = divide the discussion in "full outbound" and "half outbound" then. >=20 >=20 >=20 >>> Nobody cares about mobile networks? having two connections is really = a >>> bad idea for a mobile (battery). >=20 >> I guess that's why IMS does the INVITE/REPLACE thing. >=20 > This is a SIP design fault if we need to renegotiate a session just > because the connection between the client and its outbound proxy has > been closed. A design fault we're trying to find a solution for. >=20 >=20 >=20 >=20 >>>> It would be faster if we could use the existing flow. >>>=20 >>> But that exactly my proposal: the flow token id is the same in the = nex >>> connection with the outbound proxy. It something like: >=20 >> No, you set up a new flow with the identifier of an old, broken, one. = That's different. >=20 > But the "existing" flow is broken, right? :) > so how to use it? In the "full outbound" case there's a working secondary flow up and = active. In the=20 "half outbound" case, you are right. >=20 >=20 >=20 >=20 >>> - Hi outbound proxy, my previous connection with flow token ABCD has >>> been closed, so let me assign flow token ABCD to this new connection >>> I'm establishing with you, so I will be able to receive incoming >>> requests for existing dialogs. >=20 >> Connection setup can take a long time - considering you set up TLS >> to the server and verify with OCSP and the edge proxy sets up a new >> TLS and verifies that one and then the registrar needs to talk with a >> database and... >> TCP setup is three roundtrip messages, TLS at least nine. Add digest = auth >> before your registration is done. >>=20 >> The client will be down for a long time - will a request coming in = from the other >> side survive this time or will the dialog fail anyway? >=20 > If the client had a single connection (true in 99% of cases and > appropriate for mobile networks) then a reconnection is needed anyway, > right? Yes, in the "half outbound" scenario. In the full outbound scenario, = there's no need to wait for a reconnection. It can happen in the background. > The reconnection and re-registration could take may be 3 seconds. IMHO > it is not so hard to assume that we are not going to receive in-dialog > requests during that process. What's your T1 and your session timers? There is a chance that something will be going on exactly then. /O >=20 >=20 >=20 >=20 >=20 > -- > I=F1aki Baz Castillo > From ibc@aliax.net Tue May 21 08:19:07 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8859A21F97E7 for ; Tue, 21 May 2013 08:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.427 X-Spam-Level: X-Spam-Status: No, score=-2.427 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PXbyRQC8jscf for ; Tue, 21 May 2013 08:19:02 -0700 (PDT) Received: from mail-qe0-f52.google.com (mail-qe0-f52.google.com [209.85.128.52]) by ietfa.amsl.com (Postfix) with ESMTP id 58DE021F9856 for ; Tue, 21 May 2013 08:19:02 -0700 (PDT) Received: by mail-qe0-f52.google.com with SMTP id 1so440300qec.25 for ; Tue, 21 May 2013 08:18:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=GSJxKFOrnAYQC7TeD+BalpnNIWtx6G6qKfbDmJG460A=; b=iownRwPOv4nHAdhGye1WAVb+uoWCEmZXg5VPACbV0GbYovvoL/Hq3eT+O1t0dWt/tl id3VnEczJjIj2/nX3NDRTt6M8ZKXCUO7fof/OZWKw6vt1etzkzlZlAY14Ti3RgPQd9gp ns68N5CzdwUJd29LsTTgpeyWeaGDK1jlaVMFdz+qfi6tMMahzizLn4SVZEDITiCyhXY1 naG+Xwtr4mupsh+zQFoA9KR2AmOqRBHKdIPPJC3/uuv4uJsbsK29i+nLVezadZSz46UK AwdxCz1HbKplYCFZ51vmmR87lEsFXUSD5EjSBqWUnkA1bXDd1jkJIppe1GHz02XnSMyd 0PzA== X-Received: by 10.49.0.244 with SMTP id 20mr3105213qeh.50.1369149533724; Tue, 21 May 2013 08:18:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.26.103 with HTTP; Tue, 21 May 2013 08:18:33 -0700 (PDT) In-Reply-To: References: <49B1CBCA-9F4E-4C35-A908-E348624764E0@edvina.net> <201305171623.r4HGNSr64942933@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C374F9A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C375170@ESESSMB209.ericsson.se> <069902B7-0DDB-4B40-A3C1-BF958D2BA84A@edvina.net> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 21 May 2013 17:18:33 +0200 Message-ID: To: "Olle E. Johansson" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnlQOhpD/qxLK2LosGX4egeFygHo306SlB3J7iVXfgIj5o6gyaXH2+u3FDXgWbNCeJfQ82y Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Surviving outbound X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 15:19:07 -0000 2013/5/21 Olle E. Johansson : >> If the client had a single connection (true in 99% of cases and >> appropriate for mobile networks) then a reconnection is needed anyway, >> right? > Yes, in the "half outbound" scenario. In the full outbound scenario, ther= e's > no need to wait for a reconnection. It can happen in the background. Ok, we need a solution for both "half" and "full" Outbound scenarios. Main problem of the "full" case is that the route set points, of course, to just one of the edge proxies. Using a domain with N SRV records in the Path header is not a good idea since the edge proxy does not know wheter the UA will also register via the other edge proxy or not. I'm pretty sure that the "full" scenario has no solution without changing the route set. Let's think about it :) -- I=C3=B1aki Baz Castillo From keith.drage@alcatel-lucent.com Sat May 25 16:21:53 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EE1921F8895 for ; Sat, 25 May 2013 16:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4FGEuYvPScWL for ; Sat, 25 May 2013 16:21:46 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 4F13621F8551 for ; Sat, 25 May 2013 16:21:46 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (h135-5-2-63.lucent.com [135.5.2.63]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r4PNLinj021074 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 25 May 2013 18:21:44 -0500 (CDT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id r4PNLiLI011692 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 25 May 2013 19:21:44 -0400 Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) by US70TWXCHHUB04.zam.alcatel-lucent.com (135.5.2.36) with Microsoft SMTP Server (TLS) id 14.2.247.3; Sat, 25 May 2013 19:21:44 -0400 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.201]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Sun, 26 May 2013 01:21:41 +0200 From: "DRAGE, Keith (Keith)" To: Andrew Allen , "dispatch@ietf.org" Thread-Topic: [dispatch] Notes and Summary of April 17 call on draft-montemurro-gsma-imei-urn and draft-allen-dispatch-imei-urn-as-instanceid Thread-Index: Ac5DsEOLJ60tgoO0QGKMbkCcTXG9NAV7fMYQ Date: Sat, 25 May 2013 23:21:39 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B041DDC@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8B041DDCFR712WXCHMBA11zeu_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Subject: Re: [dispatch] Notes and Summary of April 17 call on draft-montemurro-gsma-imei-urn and draft-allen-dispatch-imei-urn-as-instanceid X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 May 2013 23:21:53 -0000 --_000_949EF20990823C4C85C18D59AA11AD8B041DDCFR712WXCHMBA11zeu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I do have a question. This new RFC to be drafted would appear to be doing nothing more than a spe= c (T), which does not require an RFC to be published. So why not just a requirement to document rather than somehow have to put i= t out as a RFC. Surely that is just trying to turn the IETF into the policeman Keith ________________________________ From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Andrew Allen Sent: 29 April 2013 07:29 To: dispatch@ietf.org Subject: [dispatch] Notes and Summary of April 17 call on draft-montemurro-= gsma-imei-urn and draft-allen-dispatch-imei-urn-as-instanceid In order to make progress on draft-montemurro-gsma-imei-urn and draft-allen= -dispatch-imei-urn-as-instanceid a conference call was held on Wednesday April 17 attended by Culllen Jennings, Atle Monrad, John Luc Bakker and mys= elf. Below are the combined notes and summary from Cullen and I of this call on = the IMEI drafts: 1) change draft-allen-dispatch-imei-urn-as-instanceid to say IMEI is only u= sed in either a register request or also in an emergency invite request Cullen will then be OK with it from a privacy point of view as long as it e= xplains the trade offs. It should be highlighted in draft-montemurro-gsma-imei-urn that using the I= MEI as a security credential is a bad thing even though some popular commer= cial applications are actually doing this and some service providers are us= ing knowledge of the IMEI to verify the legitimacy of caller being the auth= orized user/owner of the device. The IMEI is usually extremely easy to obta= in by anyone who has very brief physical access to the device as it is ofte= n printed on the device beneath the battery and can be displayed by using a= well-known key press sequence. Change draft-allen-dispatch-imei-urn-as-instanceid to not be open to any ex= tension to URN but instead require a draft updating this draft if any param= eter other than ver=3D0 was to be included. Also add text in draft-montemu= rro-gsma-imei-urn and, draft-aindicating that extensions to the IMEI parame= ters will require an update of draft-allen-dispatch-imei-urn-as-instanceid. 2) Write a new separate draft that tries to deal with the OMA push to talk = case. This would have the UA include the IMEI in an INVITE request in very partic= ular instances where the UA knew that request was going to the POC server a= nd that the POC server would remove it. I'm not sure what I would think of = this draft - Cullen might hate it - but regardless of if folks thought it w= as good or bad, splitting it into a separate problem can allow the use in t= he first draft to proceed. Cullen would want this draft to be very clear on= how a UA knew it was "safe" to put the IMEI in a INVITE and Cullen does no= t think the IME should ever be in an anonymous INVITE. The current text ar= ound you only include the IMEI if you know it is safe does not seem impleme= ntable so Cullen would prefer something where it was really clear when the = UA did it and when it did not. Cullen thinks this is much easier to do in t= he specific case of push to talk than trying to solve it for all uses of an= INVITE so this should be easier to get people on board with than the curre= nt draft. Response to Cullen on the IME should never be in an anonymous INVITE point.= - in 3GPP networks there is really no such thing as an anonymous INVITE si= nce the P-CSCF always knows the identity of the UE and will always include = a P-Asserted-Identity header field. There are instead requests where privac= y is requested and the P-Asserted-Identity header field is removed at the = edge of the trust domain. Thus in my view there is no need for a UE in the = PoC case where it knows the PoC Server will remove the instance ID to prohi= bit inclusion of the IMEI. Cullen any comments to that? 3) Update draft-montemurro-gsma-imei-urn security section to clarify that t= he IMEI-SV is not updated based on the OS version or when new applications = are added but represents the software version of lower layer software that = has completed certification testing. I am in the process of updating the drafts as described above. Comments on the above are of course welcome Andrew --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. --_000_949EF20990823C4C85C18D59AA11AD8B041DDCFR712WXCHMBA11zeu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I do have a question.

 

This new RFC to be drafted would appea= r to be doing nothing more than a spec (T), which does not require an RFC t= o be published.

 

So why not just a requirement to docum= ent rather than somehow have to put it out as a RFC.

 

Surely that is just trying to turn the= IETF into the policeman

 

Keith

 

From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of Andrew Allen
Sent: 29 April 2013 07:29 To: dispatch@ietf.org
Subject: [dispatch] Notes an= d Summary of April 17 call on draft-montemurro-gsma-imei-urn and draft-alle= n-dispatch-imei-urn-as-instanceid

 

 

In order to make progress on draft-montemu= rro-gsma-imei-urn and draft-allen-dispatch-imei-urn-as-instanceid a confere= nce call was held on Wednesday

April 17 attended by Culllen Jennings, Atl= e Monrad, John Luc Bakker and myself.

 

Below are the combined notes and summary f= rom Cullen and I of this call on the IMEI drafts:<= /p>

 

 

1) change draft-allen-dispatch-imei-urn-as= -instanceid to say IMEI is only used in either a register request or also i= n an emergency invite request

 

Cullen will then be OK with it from a priv= acy point of view as long as it explains the trade offs.

 

It should be highlighted in draft-montemur= ro-gsma-imei-urn that using the IMEI as a security credential is a bad thin= g even though some popular commercial applications are actually doing this and some service providers are using knowledge of = the IMEI to verify the legitimacy of caller being the authorized user/owner= of the device. The IMEI is usually extremely easy to obtain by anyone who = has very brief physical access to the device as it is often printed on the device beneath the battery and ca= n be displayed by using a well-known key press sequence.<= /font>

 

Change draft-allen-dispatch-imei-urn-as-in= stanceid to not be open to any extension to URN but instead require a draft= updating this draft if any parameter other than ver=3D0 was to be included.  Also add text in draft-montemurro-g= sma-imei-urn and, draft-aindicating that extensions to the IMEI parameters = will require an update of draft-allen-dispatch-imei-urn-as-instanceid.=

 

 

2) Write a new separate draft that tries t= o deal with the OMA push to talk case.

 

This would have the UA include the IMEI in= an INVITE request in very particular instances where the UA knew that requ= est was going to the POC server and that the POC server would remove it. I'm not sure what I would think of this draft = - Cullen might hate it - but regardless of if folks thought it was good or = bad, splitting it into a separate problem can allow the use in the first dr= aft to proceed. Cullen would want this draft to be very clear on how a UA knew it was "safe" to pu= t the IMEI in a INVITE and Cullen does not think the IME should ever be in = an anonymous INVITE.  The current text around you only include the IME= I if you know it is safe does not seem implementable so Cullen would prefer something where it was really clear when the UA did= it and when it did not. Cullen thinks this is much easier to do in the spe= cific case of push to talk than trying to solve it for all uses of an INVIT= E so this should be easier to get people on board with than the current draft.

 

Response to Cullen on the IME should never= be in an anonymous INVITE point. - in 3GPP networks there is really no suc= h thing as an anonymous INVITE since the P-CSCF always knows the identity of the UE and will always include a P-Asserted-I= dentity header field. There are instead requests where privacy is requested= and the  P-Asserted-Identity header field is removed at the edge of t= he trust domain. Thus in my view there is no need for a UE in the PoC case where it knows the PoC Server will rem= ove the instance ID to prohibit inclusion of the IMEI. Cullen any comments = to that?

 

3) Update draft-montemurro-gsma-imei-urn s= ecurity section to clarify that the IMEI-SV is not updated based on the OS = version or when new applications are added but represents the software version of lower layer software that has compl= eted certification testing.

 

I am in the process of updating the drafts= as described above.

 

Comments on the above are of course welcome

 

Andrew

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient is prohibited. If you have rec= eived this transmission in error, please immediately reply to the sender an= d delete this information from your system. Use, dissemination, distributio= n, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

--_000_949EF20990823C4C85C18D59AA11AD8B041DDCFR712WXCHMBA11zeu_-- From stpeter@stpeter.im Tue May 28 14:21:48 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9657E21F8D90 for ; Tue, 28 May 2013 14:21:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xh+qrUDHv24s for ; Tue, 28 May 2013 14:21:43 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id CB1DE21F8E3C for ; Tue, 28 May 2013 14:21:37 -0700 (PDT) Received: from ergon.local (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D8C2E411C2; Tue, 28 May 2013 15:34:22 -0600 (MDT) Message-ID: <51A51FDE.7000006@stpeter.im> Date: Tue, 28 May 2013 15:21:34 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Emil Ivov References: <51744F5B.8010506@jitsi.org> <5175A133.5040309@stpeter.im> <5175A9C6.9010707@alum.mit.edu> <8393F7ED-51FD-4CE1-B8A3-FD95EA185016@vidyo.com> <5176A9B9.3050105@jitsi.org> <5176CBA0.6000602@stpeter.im> <51773F1B.3020907@jitsi.org> In-Reply-To: <51773F1B.3020907@jitsi.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org" , Jonathan Lennox Subject: Re: [dispatch] Announcing a MUC with RFC4575 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 21:21:49 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4/23/13 8:10 PM, Emil Ivov wrote: > There it is then: > > http://tools.ietf.org/html/draft-ivov-grouptextchat-purpose An additional security consideration might be opening another attack vector for the conference (e.g., chatroom flooding). Furthermore, an attack on the auxiliary chatroom might be easier (or harder) than an attack on the main conference depending on the security policies in effect. Emil, regarding such mismatches you might borrow some text from draft-ivov-xmpp-cusax, but I think it would also be helpful to describe the nature of the chatroom attack vector (you might find it helpful to look at Section 13 of XEP-0045, especially 13.6.) Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRpR/eAAoJEOoGpJErxa2pE5gP/1FMP1nWnEZqeHl2ivesPxZY pRriCt94jEbKEVp86tCNBtMmCg5K6VjOIx6gFcMKXGWvg0HBRCT+bbLgNAAPlqIn 6zTbRTmbhpvClA4Y8CIUrqoExHynOoMvfDCbEo9OLRdKpiDYMESWboekgEqAAkL8 nE/ErJxfr3hvrd8gZUBAepQd3qPnbmgQUw9cg0Y+euT5mfURPk04J4rn8kFECDR2 XT6CcNSodFW7QYC7tYIAgseSsfHZV6bLlvrOrIOXE4lIxgoln9JRXJ5CnLPnvX9d 9uE/G3WxcqrlTd7U0XuvtOsQJ9nZowOL2MBDMuECEXlNjPfKqFKHfwyPX50puUB5 anfX1MVysrc7v9gKUJLuBomQXCZovJMC5Yr9SHuxLzmqkCuN/Go00uCKo8fh0oQV tofwS03MIWTtglUI0iXxgDTOc7ZvGgxYgnLt2qxskw2lQqK+6VwYfoMwzV2Q5MEW LD12OA2jnLeaYQKkyxwJJaTssLeXjLYqyUtPT0RZwxZIcjUKJlRk6YIaG9tYKSWW bN5yqsKWIr3cpudofS1fkEnC1MP4AhDZdDcYFVbSONzR0JFnCZwPEV22lmApo9VH Nb7QkJShrzH+QI/eRx/+UtEfjZrEzrXxV5oKYzTsCsbt5hb0ejXNtRJIT74mtW+K GI720Wp5gFkYanUn0Vk5 =JW6y -----END PGP SIGNATURE----- From mary.ietf.barnes@gmail.com Wed May 29 14:11:07 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E91EB21F856D; Wed, 29 May 2013 14:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IHnKibaij5t0; Wed, 29 May 2013 14:11:05 -0700 (PDT) Received: from mail-qc0-x22c.google.com (mail-qc0-x22c.google.com [IPv6:2607:f8b0:400d:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id F030221F9677; Wed, 29 May 2013 14:10:47 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id z1so5018279qcx.17 for ; Wed, 29 May 2013 14:10:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=IoMb7hZ7/BPxALOnAjjDJXimCUugMvCMrzLIz77MQ2I=; b=epXzv4hJuvh4JK8LctVwKmBb63P0IaU6hpZEaMqlL3j2z5Dy65wB4/GnfS8xBTPpX4 tNopkmVTx5BTRPSoDPbyymeeBbpQCNPHX68rkNYNbts1aKoXVpopL5eMrBwCXUV42IH3 ei5SnXLjtxVPTkx6zRonQxxVbpqdJGTFHuTgSVFsgJENlnipgZ8QTvvz79f2YB4JvBr1 DTwsfIQNeQiYEFTiw7OWuHUSZ4vGg2NritQkUiaygTge7T/o391/WeK7zx/oP/rvCsMh da4RtwvQcYuPMj8hvRJ8YIMkojBveH1eZ5lLy+vR7NdVENNJ2kHuI4gxYZP3L+eq6LVg CEqA== MIME-Version: 1.0 X-Received: by 10.229.177.10 with SMTP id bg10mr1602426qcb.135.1369861847369; Wed, 29 May 2013 14:10:47 -0700 (PDT) Received: by 10.49.41.68 with HTTP; Wed, 29 May 2013 14:10:47 -0700 (PDT) In-Reply-To: References: Date: Wed, 29 May 2013 16:10:47 -0500 Message-ID: From: Mary Barnes To: DISPATCH , "rai@ietf.org" , CLUE Content-Type: text/plain; charset=ISO-8859-1 Subject: [dispatch] Fwd: Nomcom 2013-14 Volunteering - 2nd Call X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 21:11:07 -0000 Sorry for the multiple copies, but just in case you are not subscribed to the IETF announce or IETF discussion lists. This is a very important volunteer opportunity, as the voting members selected from this pool of volunteers will be responsible for selecting the individuals to serve in IETF leadership positions. Please consider volunteering - note that volunteering doesn't necessarily commit you as the process for selection is entirely random. However, the more diverse set of volunteers, the more diverse nomcom we will have. Mary. ---------- Forwarded message ---------- From: Mankin, Allison Date: Wed, May 29, 2013 at 4:04 PM Subject: Nomcom 2013-14 Volunteering - 2nd Call To: "ietf-announce@ietf.org" Cc: "" Hi, everyone, Remember that I'm challenging the IETF to come up with 200 volunteers for the upcoming nomcom. You can volunteer just by hitting Reply to this email. What are you waiting for?? The more volunteers we get, the better chance we have of choosing a random yet representative cross section of the IETF population. Respond to the 200-volunteer challenge and hit Reply right now. (Well, much as I want you to do this, please look below at the posts being filled and be sure you are willing to forgo trying for any of them this year). The official information: The IETF nominating committee (nomcom) process for 2013-14 is under way. The IETF nomcom appoints folks to fill the open slots on the IAOC, the IAB, and the IESG. Ten voting members for the nomcom are selected in a verifiably random way from a pool of volunteers. The details of the selection and operation of the nomcom can be found in RFCs 3777, 5078, 5633, 5680, and 6859. Four of those RFCs (3777, 5633, 5680 and 6859) comprise BCP 10. We will also reference RFC 3797. Volunteers must have attended 3 of the past 5 IETF meetings. As specified in RFC 3777, that means three out of the five past meetings up to the time this email announcement goes out to start the solicitation of volunteers. The five meetings out of which you must have attended three are IETF 82, 83, 84, 85, 86. If you qualify, reply to this email and volunteer. The list of people and posts whose terms end with the March 2014 IETF meeting, and thus the positions for which this nomcom is responsible, are IAOC: Chris Griffiths IAB: Bernard Aboba Marc Blanchet Ross Callon Eliot Lear Hannes Tschofenig IESG: Barry Leiba (Applications) Brian Haberman (Internet) Benoit Claise (Operations and Management) Gonzalo Camarillo (RAI) Stewart Bryant (Routing) Sean Turner (Security) Martin Stiemerling (Transport) The primary activity for this nomcom will begin in July 2013 and should be completed in January 2014. Being a nomcom member will require some time commitment - there will be interviews with candidates at meetings, regularly scheduled conference calls to ensure progress, collection and review of requirements from the commitment, review of candidate questionnaires and of community feedback. A more detailed timetable for the nomcom tasks will appear soon. Please respond to this email before 11:59 pm EDT (UTC -4 hours) June 16, 2013. In the body include: 1. your Given Name as you enter it when you register for the IETF 2. your Family Name as you enter it when you register for the IETF 3. your current primary affilation (the information you enter into the Company field) 4. any/all email addresses you've used to register for IETF meetings 5. which email address you prefer 6. your phone number (for our use in confirming you if selected). You should expect an email response from me within 3 business days stating whether or not you are qualified (and added to the list). If you don't receive this response, please re-send your email adding the tag "RESEND" to the subject line. Participating in the IETF nomcom is a meaningful and fun way to contribute to the IETF. Please help us meet the 200-volunteer challenge by hitting Reply to this message today. Allison Allison Mankin Nomcom Chair 2013-2014 From emil@sip-communicator.org Thu May 30 09:33:31 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F33121F8F43 for ; Thu, 30 May 2013 09:33:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P5N4BJITXMWh for ; Thu, 30 May 2013 09:33:29 -0700 (PDT) Received: from mail-bk0-x22c.google.com (mail-bk0-x22c.google.com [IPv6:2a00:1450:4008:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 0042C21F8F12 for ; Thu, 30 May 2013 09:33:28 -0700 (PDT) Received: by mail-bk0-f44.google.com with SMTP id jc3so272884bkc.17 for ; Thu, 30 May 2013 09:33:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=kbficy+LH+2y345EAriOqZ/6L/9nkTGv1UTtLzcERY8=; b=gRc9DTvjUBzWoBn7iT1VUSayu+HSD6d4rEHqVUUzkxF9y239myHb+Ro1nEWpYsZnM2 rr2autqZRa71iIo39KCzlEnIYXfcK83fKKMyZ6geXGFPGr7zuqVI3K4S0rTp2yndjk65 jpZWqKZ9/+2nORe8EKEAI8wFx9c/ckB8590eTr5DNCcZCK5OYIuaF8aoER/tpDP21wLp SNJSgImxstyUl94k+W/5KEoPbsQqiBMtKqmbjtyy2N9TwduhWjkQr9kZXffuCK94nKBc 6FYpxQuRpLnOWZfV8Kh7Yx8qDoj7w+AwvE9qj7YsTQ1RSo07OWEb8VzI4+C5fyN2bBCJ yXIQ== X-Received: by 10.204.57.142 with SMTP id c14mr2113497bkh.7.1369931607804; Thu, 30 May 2013 09:33:27 -0700 (PDT) Received: from [192.168.1.118] ([88.203.232.9]) by mx.google.com with ESMTPSA id np10sm5036841bkb.10.2013.05.30.09.33.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 30 May 2013 09:33:26 -0700 (PDT) Message-ID: <51A77F54.3040309@jitsi.org> Date: Thu, 30 May 2013 19:33:24 +0300 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Peter Saint-Andre References: <51744F5B.8010506@jitsi.org> <5175A133.5040309@stpeter.im> <5175A9C6.9010707@alum.mit.edu> <8393F7ED-51FD-4CE1-B8A3-FD95EA185016@vidyo.com> <5176A9B9.3050105@jitsi.org> <5176CBA0.6000602@stpeter.im> <51773F1B.3020907@jitsi.org> <51A51FDE.7000006@stpeter.im> In-Reply-To: <51A51FDE.7000006@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQls4b1r15jC45dkFrAZSa/fE5dUk3Ubu8KeTHZ0hLJzSGbouYqI4yvhhJeIuKB/cDyMolLG Cc: "dispatch@ietf.org" , Jonathan Lennox Subject: Re: [dispatch] Announcing a MUC with RFC4575 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 16:33:31 -0000 Thanks Peter, I've just updated the security considerations but wanted to make sure they reflect what you said before resubmitting, so here they are: https://github.com/emcho/grouptextchat-purpose/blob/master/draft-ivov-grouptextchat-purpose-02.txt Could you please confirm that this works for you? Cheers, Emil On 29.05.13, 00:21, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 4/23/13 8:10 PM, Emil Ivov wrote: >> There it is then: >> >> http://tools.ietf.org/html/draft-ivov-grouptextchat-purpose > > An additional security consideration might be opening another attack > vector for the conference (e.g., chatroom flooding). Furthermore, an > attack on the auxiliary chatroom might be easier (or harder) than an > attack on the main conference depending on the security policies in > effect. Emil, regarding such mismatches you might borrow some text > from draft-ivov-xmpp-cusax, but I think it would also be helpful to > describe the nature of the chatroom attack vector (you might find it > helpful to look at Section 13 of XEP-0045, especially 13.6.) > > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.19 (Darwin) > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBAgAGBQJRpR/eAAoJEOoGpJErxa2pE5gP/1FMP1nWnEZqeHl2ivesPxZY > pRriCt94jEbKEVp86tCNBtMmCg5K6VjOIx6gFcMKXGWvg0HBRCT+bbLgNAAPlqIn > 6zTbRTmbhpvClA4Y8CIUrqoExHynOoMvfDCbEo9OLRdKpiDYMESWboekgEqAAkL8 > nE/ErJxfr3hvrd8gZUBAepQd3qPnbmgQUw9cg0Y+euT5mfURPk04J4rn8kFECDR2 > XT6CcNSodFW7QYC7tYIAgseSsfHZV6bLlvrOrIOXE4lIxgoln9JRXJ5CnLPnvX9d > 9uE/G3WxcqrlTd7U0XuvtOsQJ9nZowOL2MBDMuECEXlNjPfKqFKHfwyPX50puUB5 > anfX1MVysrc7v9gKUJLuBomQXCZovJMC5Yr9SHuxLzmqkCuN/Go00uCKo8fh0oQV > tofwS03MIWTtglUI0iXxgDTOc7ZvGgxYgnLt2qxskw2lQqK+6VwYfoMwzV2Q5MEW > LD12OA2jnLeaYQKkyxwJJaTssLeXjLYqyUtPT0RZwxZIcjUKJlRk6YIaG9tYKSWW > bN5yqsKWIr3cpudofS1fkEnC1MP4AhDZdDcYFVbSONzR0JFnCZwPEV22lmApo9VH > Nb7QkJShrzH+QI/eRx/+UtEfjZrEzrXxV5oKYzTsCsbt5hb0ejXNtRJIT74mtW+K > GI720Wp5gFkYanUn0Vk5 > =JW6y > -----END PGP SIGNATURE----- > -- https://jitsi.org From stpeter@stpeter.im Thu May 30 10:38:02 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95C6A21F9354 for ; Thu, 30 May 2013 10:38:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.49 X-Spam-Level: X-Spam-Status: No, score=-102.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y7-d1Qqq7rrK for ; Thu, 30 May 2013 10:37:58 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 50A9A21F91CE for ; Thu, 30 May 2013 10:37:58 -0700 (PDT) Received: from sjc-vpn2-825.cisco.com (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id C7C724113B; Thu, 30 May 2013 11:50:49 -0600 (MDT) Message-ID: <51A78E73.20903@stpeter.im> Date: Thu, 30 May 2013 11:37:55 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Emil Ivov References: <51744F5B.8010506@jitsi.org> <5175A133.5040309@stpeter.im> <5175A9C6.9010707@alum.mit.edu> <8393F7ED-51FD-4CE1-B8A3-FD95EA185016@vidyo.com> <5176A9B9.3050105@jitsi.org> <5176CBA0.6000602@stpeter.im> <51773F1B.3020907@jitsi.org> <51A51FDE.7000006@stpeter.im> <51A77F54.3040309@jitsi.org> In-Reply-To: <51A77F54.3040309@jitsi.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org" , Jonathan Lennox Subject: Re: [dispatch] Announcing a MUC with RFC4575 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 17:38:02 -0000 Yes, that looks good! On 5/30/13 10:33 AM, Emil Ivov wrote: > Thanks Peter, > > I've just updated the security considerations but wanted to make sure > they reflect what you said before resubmitting, so here they are: > > https://github.com/emcho/grouptextchat-purpose/blob/master/draft-ivov-grouptextchat-purpose-02.txt > > > Could you please confirm that this works for you? > > Cheers, > Emil > > On 29.05.13, 00:21, Peter Saint-Andre wrote: > On 4/23/13 8:10 PM, Emil Ivov wrote: >>>> There it is then: >>>> >>>> http://tools.ietf.org/html/draft-ivov-grouptextchat-purpose > > An additional security consideration might be opening another attack > vector for the conference (e.g., chatroom flooding). Furthermore, an > attack on the auxiliary chatroom might be easier (or harder) than an > attack on the main conference depending on the security policies in > effect. Emil, regarding such mismatches you might borrow some text > from draft-ivov-xmpp-cusax, but I think it would also be helpful to > describe the nature of the chatroom attack vector (you might find it > helpful to look at Section 13 of XEP-0045, especially 13.6.) > > Peter > >> >