From jmillan@aliax.net Tue Jul 2 09:20:26 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FCA721F9D42 for ; Tue, 2 Jul 2013 09:20:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.176 X-Spam-Level: X-Spam-Status: No, score=-2.176 tagged_above=-999 required=5 tests=[AWL=-0.100, 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 qBw1sC+lUgLI for ; Tue, 2 Jul 2013 09:20:11 -0700 (PDT) Received: from mail-ve0-f170.google.com (mail-ve0-f170.google.com [209.85.128.170]) by ietfa.amsl.com (Postfix) with ESMTP id 16CE321F934B for ; Tue, 2 Jul 2013 09:20:02 -0700 (PDT) Received: by mail-ve0-f170.google.com with SMTP id 14so5064469vea.29 for ; Tue, 02 Jul 2013 09:20: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:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=nHMRK6RIbMjK/IRzTimV+jWM9UeFHbflW3tv+5mkMjk=; b=cmx7vl7tkDLQJHFo32zhi39UpvBD4kEepQ1b8x9JThy1pFvNK1e1TeLmR5BSd9a6hi kZPPzCLGnyyxyF5/lcZAZiI2xG7gXjYAMjsuhwGGmNXzkbShPOZ5+ZmjwJwQRppLtHGj GRm5lKvM2zQNp/YqpxPAn2xj/dT3JYIIO4h2pF/RsvNdpFWkHutoR7GsdXdcQK7gj8aR 46AWE6LcDzbeKKayKsBlnFPLjmvRPd/GbCZBW92XuG0VQz6D6/dV0C97YsvUXQTJIG5i TRH1SIIyirMrqinQczHEkg8fFCWvhm1AsbjRfI41q3c4B6rcaCtBqUDIgxvH892u9yDB vT+g== MIME-Version: 1.0 X-Received: by 10.52.163.46 with SMTP id yf14mr9640540vdb.58.1372782001438; Tue, 02 Jul 2013 09:20:01 -0700 (PDT) Received: by 10.220.49.138 with HTTP; Tue, 2 Jul 2013 09:20:01 -0700 (PDT) In-Reply-To: <201306282034.r5SKYs1E115839@shell01.TheWorld.com> References: <201306282034.r5SKYs1E115839@shell01.TheWorld.com> Date: Tue, 2 Jul 2013 18:20:01 +0200 Message-ID: From: =?UTF-8?B?Sm9zw6kgTHVpcyBNaWxsw6Fu?= To: "Dale R. Worley" Content-Type: multipart/alternative; boundary=001a11c2ccca8cd70604e089b748 X-Gm-Message-State: ALoCoQnDZPj24poCWJ9PdMAT9ohc3ef79OgeMVh22K6R0+0S1Ivr+Ti2K5I53VlU+fBzDLA9GHlQ Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" Subject: Re: [sipcore] Outbound clarification X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 16:20:26 -0000 --001a11c2ccca8cd70604e089b748 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Dale, I thought that too, but based on the definition of the ;ob parameter, it has no sense in a Contact header of a REGISTER request, since such request does never belong to a dialog. ''' The "ob" parameter is a SIP URI parameter that has a different meaning depending on context. In a Path header field value, it is used by the first edge proxy to indicate that a flow token was added to the URI. In a Contact or Route header field value, it indicates that the UA would like other requests in the same dialog to be routed over the same flow. ''' 2013/6/28 Dale R. Worley > > From: JosC) Luis MillC!n > > > > May it mean that the GRUU was obtained from a REGISTER request which > > Contact header contained the ;ob parameter? > > Yes, I believe that is what it means. Every GRUU refers to an > underlying Contact address, which is where requests to that GRUU will > be routed to. That Contact address is what was used in the REGISTER > request to obtain the GRUU. The question seems to be, "Does this GRUU > refer to a Contact address that includes an "ob" parameter?" > > Dale > --=20 Jos=C3=A9 Luis Mill=C3=A1n --001a11c2ccca8cd70604e089b748 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Dale,

I= thought that too, but based on the definition of the ;ob parameter, it has= no sense in a Contact header of a REGISTER request, since such request doe= s never belong to a dialog.

'''
The "ob" parameter is a = SIP URI parameter that has a different meaning depending on context. In a P= ath header field value, it is used by the first edge proxy to indicate that= a flow token was added to the URI. In a Contact or Route header field valu= e, it indicates that the UA would like other requests in the same dialog to= be routed over the same flow.
'''




2013/6/28 Dale R. Worley <wor= ley@ariadne.com>
> From: JosC) Luis MillC!n <jmillan@aliax.net>
>
> May it mean that the GRUU was obtained from a REGISTER request which > Contact header contained the ;ob parameter?

Yes, I believe that is what it means. =C2=A0Every GRUU refers to an underlying Contact address, which is where requests to that GRUU will
be routed to. =C2=A0That Contact address is what was used in the REGISTER request to obtain the GRUU. =C2=A0The question seems to be, "Does this= GRUU
refer to a Contact address that includes an "ob" parameter?"=

Dale



-- Jos=C3=A9 Luis Mill=C3=A1n
--001a11c2ccca8cd70604e089b748-- From ibc@aliax.net Tue Jul 2 17:27:24 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C166321F99CF for ; Tue, 2 Jul 2013 17:27:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.627 X-Spam-Level: X-Spam-Status: No, score=-2.627 tagged_above=-999 required=5 tests=[AWL=0.050, 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 QYXequEmOxBi for ; Tue, 2 Jul 2013 17:27:15 -0700 (PDT) Received: from mail-qa0-f47.google.com (mail-qa0-f47.google.com [209.85.216.47]) by ietfa.amsl.com (Postfix) with ESMTP id F2C9621F99CD for ; Tue, 2 Jul 2013 17:27:14 -0700 (PDT) Received: by mail-qa0-f47.google.com with SMTP id i13so3247816qae.6 for ; Tue, 02 Jul 2013 17:27:13 -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=oq72nNQkxGfI65D5CFg2a9DlZ2bwxSIM6ifmdI7O9dg=; b=VXHwZduVrOQv9boLVRIyWPg9sSvnma/LU0npSBqf9I7brc2lSMIVEWfpXT+dcNkGb5 64+qSVnyjMC0ckxis+L7L2f4BHchgl80rdMTfjjFpsuNkMQP+ZfKU6RU0E8vFIUlzVVD NShxFtyI2Z/XDCDMlsDQFWx5kz5NzQ6a40jrv6bBfqVpdvQritZ8SByfzpsawmsM2F6w gGuDcyiIPrrPbqoJvRU8CVoXmd9ioF8hbQbEC7AUJCSea6om0NMgeWfcUL3j0bddTFjO ZVM7aPD7MxxbVZeTI1UZjwn9l87CIb2KArt9IAx2x0uS1LmuNOE5riCKeiZtVRl0bKKw lv0w== X-Received: by 10.49.84.164 with SMTP id a4mr8646199qez.4.1372811233087; Tue, 02 Jul 2013 17:27:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.72.132 with HTTP; Tue, 2 Jul 2013 17:26:53 -0700 (PDT) In-Reply-To: <201306282034.r5SKYs1E115839@shell01.TheWorld.com> References: <201306282034.r5SKYs1E115839@shell01.TheWorld.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 3 Jul 2013 02:26:53 +0200 Message-ID: To: "Dale R. Worley" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlrboXCwvtkD+rXag0DbTPb/ZvgDGMtAoz62WdxNo/oDYiShYZGrsSgV7AP5fBKjQXXOh8X Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" , Jose Luis Millan Subject: Re: [sipcore] Outbound clarification X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 00:27:24 -0000 2013/6/28 Dale R. Worley : > Yes, I believe that is what it means. Every GRUU refers to an > underlying Contact address, which is where requests to that GRUU will > be routed to. That Contact address is what was used in the REGISTER > request to obtain the GRUU. The question seems to be, "Does this GRUU > refer to a Contact address that includes an "ob" parameter?" The problem is: alice ---- Proxy+Registrar ---- bob - alice has a GRUU registration. - alice calls bob with ;gr in Contact. - Let's suppose P+R adds Outbound flow token in R-R. - Call is established. - Later bob sends BYE. - Such a BYE arrives to P+R with a Route header containg an outbound flow token and with a RURI containing ;gr. How should P+R route the BYE? by using Outbound (looking for the connection associated to the flow token in the Route header)? or by performing GRUU (replacing the RURI with the real Contact? In the former, if the TCP connection of alice was re-established during the dialog, the BYE could not be sent. -- I=C3=B1aki Baz Castillo From ibc@aliax.net Fri Jul 5 02:27:28 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D70C21F9E70 for ; Fri, 5 Jul 2013 02:27:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.636 X-Spam-Level: X-Spam-Status: No, score=-2.636 tagged_above=-999 required=5 tests=[AWL=0.041, 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 F9pR5+wj7Tg9 for ; Fri, 5 Jul 2013 02:27:23 -0700 (PDT) Received: from mail-qa0-f52.google.com (mail-qa0-f52.google.com [209.85.216.52]) by ietfa.amsl.com (Postfix) with ESMTP id 2F33721F9FFA for ; Fri, 5 Jul 2013 02:27:23 -0700 (PDT) Received: by mail-qa0-f52.google.com with SMTP id bv4so1132053qab.4 for ; Fri, 05 Jul 2013 02:27: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=mSXFskylD2aI4vUkKJf3QP4rs3hBUJxltoZ3C0hrwAU=; b=LqcUOGWZKJsLuA4akIXz8DKxVGoq6/JCj6gXYTiKuOtO5ygaM46Hq7C0Lq7kQAiK4k aIwUJjhySj+H1aEb05SPQkwlAjKAU92aU08dMjkKDsdjHJmVCYU4xG16ZDNblOCZZ7Kw AVgmLpl11eoSgMekFI+OuJ4Clwx366c9L2zpm8PuFXvvcqFBECZCZnFC5OSV5hMfmb+R L435Zdx0DVkLvYCr25+Aft+cZRg0n1O2L+FVWF10hrgoAtev4VI04fLaAIVvE74p3Szz v0pS5ymIsnwEs7WMkEuw8iU+WRRLdKlGNpdZxzPtY8/0Cl31OEadTwaHivXT+GLENqux RQPg== X-Received: by 10.224.90.1 with SMTP id g1mr9119034qam.0.1373016442529; Fri, 05 Jul 2013 02:27:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.72.132 with HTTP; Fri, 5 Jul 2013 02:27:02 -0700 (PDT) In-Reply-To: <51CC52F0.3050809@alum.mit.edu> References: <003f01ce6aaf$aabda760$0038f620$@co.in> <011e01ce6c44$3c70e290$b552a7b0$@co.in> <019a01ce6d24$8ee95670$acbc0350$@co.in> <51C3267F.8040709@alum.mit.edu> <002301ce713c$c2672880$47357980$@co.in> <51CB0532.3020107@alum.mit.edu> <51CC52F0.3050809@alum.mit.edu> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Fri, 5 Jul 2013 11:27:02 +0200 Message-ID: To: Paul Kyzivat Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmCheGcUegGmvRb+WJT+quH0ByoHVNw/QTix2LlFF1Fj/2HTao0CRxksWGbPBJfT53Wnscw Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" Subject: Re: [sipcore] Open issues in draft-ietf-sipcore-sip-websocket-09 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 09:27:28 -0000 2013/6/27 Paul Kyzivat : > The simple answer would be that websocket proxy handling a dialog > establishing request should *always* R-R. But there has been an assertion > that there may be some sip-websocket UACs that are also capable of being > sip-websocket servers. In that case, it would be desirable for the proxy = to > *not* R-R, so that it won't be in the signaling path for the entire dialo= g. > But how would the proxy know that it is safe to not R-R? > > One thing that comes to mind for me is that the UAC could decide whether = or > not to tag its contact URI with ";gr". If it were so tagged, then that sa= ys > it is globally routable, so it would be safe for the proxy to bypass the > R-R. If the contact isn't a gruu, then the proxy would decide that it mus= t > R-R. Hi, let me show a similar example: alice --- (SCTP) --- Proxy --- (UDP) --- bob - alice calls to bob with Contact SCTP URI. - bob does not implement SCTP. - if Proxy does not R-R then bob has no way to contact alice for sending her in-dialog requests. Now my question: how does the proxy know whether it must do R-R or not in this scenario? IMHO there is no reply for this question, and anyhow, this is not an issue related to SIP-over-WS. So IMHO there is no need to address this issue into the draft (instead it should be covered in some other work like RFC 5626bis or RFC 5627bis). Am I wrong? Whether the proxy does R-R or not if decided by local policy. It's safe for a proxy to always add R-R in connections from clients (via UDP, TCP, WS transports). And as Paul pointed out, the proxy could decide not to add R-R in case the UA's Contact has ;gr so R-R is not needed. Please let me insist on it a bit more: > But there has been an assertion > that there may be some sip-websocket UACs that are also capable of being > sip-websocket servers. In that case, it would be desirable for the proxy = to > *not* R-R, so that it won't be in the signaling path for the entire dialo= g. > But how would the proxy know that it is safe to not R-R? Any TCP SIP UA is capable of listening for incoming connections but that does not mean that the proxy should not R-R. If the UA is behind NAT then RFC 5626 must be used (I avoid here proprietary similar mechanisms), and RFC 5626 *alreay* mandates R-R for such a mechanism to work. If GRUU is also in use then the proxy can decide not to R-R (not needed since incoming requests will arrive via the registration path which will of course include Outbound stuff). So honestly, I don't understand why draft-ietf-sipcore-sip-websocket should address issues that are not different than when using other transports, and that are already covered by other specifications. Correct me if I'm wrong. Best regards. -- I=C3=B1aki Baz Castillo From ibc@aliax.net Fri Jul 5 02:37:17 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB8E111E8274 for ; Fri, 5 Jul 2013 02:37:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.638 X-Spam-Level: X-Spam-Status: No, score=-2.638 tagged_above=-999 required=5 tests=[AWL=0.039, 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 uswn4TtA9Eso for ; Fri, 5 Jul 2013 02:37:12 -0700 (PDT) Received: from mail-qc0-f179.google.com (mail-qc0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 8288F11E8276 for ; Fri, 5 Jul 2013 02:37:12 -0700 (PDT) Received: by mail-qc0-f179.google.com with SMTP id e11so1121617qcx.24 for ; Fri, 05 Jul 2013 02:37:12 -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=hWw9ta8haZutui26EAhIXuVRJd5Uce0JC7JYY8gYkfc=; b=CHzrMXEGOj4G2a3huDXSFVMLFriBHmRUZRYRLZ7r0Era6kFXjRUz8nfhUmCHIk0GjI VeqooCAoPddXTsLTUwnW/IxQbjDAwNcJ/1t9DYcbEw41ZRlvcb+6nmkayirWnGAM19Ma +uB8qpd6ntzN3S3n6QGDsP6wP5n2coL2WRQLnF4kH9CLMDwVvx+ae2WAFSBDs31Dv6ez wKgRmw3z4B8l4SXa7Ny8Mv+IBWhWFqXaEjRF23139tr3zMGpjgwkZVuPGmxy5+X2U1hD kghBQDi/v5KEVBxf4wzQNUGE0IK0gXPl2i1MvpzLSJAcYqJ1thW5eqzqQajf+NFskSRR OPmQ== X-Received: by 10.229.52.1 with SMTP id f1mr1423811qcg.100.1373017031989; Fri, 05 Jul 2013 02:37:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.72.132 with HTTP; Fri, 5 Jul 2013 02:36:51 -0700 (PDT) In-Reply-To: References: <003f01ce6aaf$aabda760$0038f620$@co.in> <011e01ce6c44$3c70e290$b552a7b0$@co.in> <019a01ce6d24$8ee95670$acbc0350$@co.in> <51C3267F.8040709@alum.mit.edu> <002301ce713c$c2672880$47357980$@co.in> <51CB0532.3020107@alum.mit.edu> <51CC52F0.3050809@alum.mit.edu> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Fri, 5 Jul 2013 11:36:51 +0200 Message-ID: To: Paul Kyzivat Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmtZ6vh5mNEXQWC4wVIWwzULT4Lz9DkysacKBa1RulQeJk6+jnHHyXOgGtl+8zpNhbfe8Gg Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" Subject: Re: [sipcore] Open issues in draft-ietf-sipcore-sip-websocket-09 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 09:37:17 -0000 Please, let me insist even a bit more on it: 2013/7/5 I=C3=B1aki Baz Castillo : > Any TCP SIP UA is capable of listening for incoming connections but > that does not mean that the proxy should not R-R. If the UA is behind > NAT then RFC 5626 must be used (I avoid here proprietary similar > mechanisms), and RFC 5626 *alreay* mandates R-R for such a mechanism > to work. If GRUU is also in use then the proxy can decide not to R-R > (not needed since incoming requests will arrive via the registration > path which will of course include Outbound stuff). a) If the SIP-WS UA runs in a browser then the website developer can make usage of RFC 5626 so the UA *requests* Outbound usage to its proxy. b) If the SIP-WS UA runs in a desktop and is both a SIP WS Client and SIP WS Server (and let's assume it has public IP) then it can avoid requesting Outbound to the proxy. If the proxy does R-R it is because the proxy wants to be in the patch of the dialog (local policy) and not because it is required for the dialog to work. Of course, in case b), if the peer does not speak WS and the proxy does not R-R here we have a problem, but this is *exactly* the same problem as if the caller was a UA using SCTP in its Contact URI. So again, this is about local policy in the proxy whether to decide it does R-R or not. I don't find "Record-Route" word in RFC 4168 so I expect there should be no "MUST" keyword about Record-Route in draft-ietc-sipcore-sip-websocket. Let me know if I'm wrong. Summarizing: - This is not an issue introduced by this new WS transport. - The issue is not new. - There are already standard mechanism to make it to work (the *client* can request them to the proxy !). - I see no reason at all to mandate nothing in the sip-ws draft about this. - Guidelines section in the draft already covers it in an informative way. Hope I am right. Best regards. -- I=C3=B1aki Baz Castillo From ibc@aliax.net Fri Jul 5 05:55:36 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06E7411E82CC for ; Fri, 5 Jul 2013 05:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.639 X-Spam-Level: X-Spam-Status: No, score=-2.639 tagged_above=-999 required=5 tests=[AWL=0.038, 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 Cqft2aCHR9Pt for ; Fri, 5 Jul 2013 05:55:31 -0700 (PDT) Received: from mail-qc0-f180.google.com (mail-qc0-f180.google.com [209.85.216.180]) by ietfa.amsl.com (Postfix) with ESMTP id C7ACA11E82C5 for ; Fri, 5 Jul 2013 05:55:30 -0700 (PDT) Received: by mail-qc0-f180.google.com with SMTP id a1so1211183qcx.39 for ; Fri, 05 Jul 2013 05:55:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :content-transfer-encoding:x-gm-message-state; bh=L+xQyeezWNR4giWGuLOnhz/0xV8YSJs5FrrbNEF+7Z4=; b=JJs4kTS32tSHPz7caDgtBNIqZNJcsDKmh/3PaZsdfBm3QUUc9osoKNkqyLQ0J8zmv6 X7iMVpgXDscPPaNNYi44JdMpLOqQ00uIQUhPziBwWQJnx1+4csdGryCah4N0U/5eAuJW jPp75j20irLtLTRo/RTL01F0asfF6apU3qU5X7/i6Y4bnCmbYIuFbcHyBtgjOYvuC4Y/ f9At7bog6Ewf0mv3UJq6yhto/CjOktVycgk9LDHSQqjvf1Nt+FqEaEPUEz05DjnubPux GqyPEHwtMKMKnE8VjuMhacdAJi53zgxBc5/I5HiIqeYtdMjocH0VAIE2/l+ST7Gqq8un sNpA== X-Received: by 10.224.59.142 with SMTP id l14mr8829698qah.22.1373028929666; Fri, 05 Jul 2013 05:55:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.72.132 with HTTP; Fri, 5 Jul 2013 05:55:09 -0700 (PDT) From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Fri, 5 Jul 2013 14:55:09 +0200 Message-ID: To: "SIPCORE (Session Initiation Protocol Core) WG" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlKmYPc0jeb/Vf026dzUTjvw+V96EH7IQeWj6Ny4y/9GklsHb8SdYoJ3Xm2XFiY1sBtw+Wl Subject: [sipcore] Need RFC 5627-bis (GRUU improvements and clarifications, and RFC 3261 update) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 12:55:36 -0000 Hi, after leading a lot with Outbound and GRUU I think there are well known problems and specification issues that IMHO should be addressed in some kind of RFC 5627-bis. The problem ------------------ alice --- OP --- Registrar --- bob - OP is an Outbound EDGE Proxy. - Registrar is GRUU capable. Flow showing the problem: - alice registers requesting GRUU. - OP adds Path. - alice obtains a GRUU URI. case A) 1) alice calls bob by using her GRUU in Contact. alice also requests Outbound usage by adding ;ob in Contact of INVITE. 2) OP adds Record-Route. 3) OP routes to registrar which adds Record-Route and routes to Bob. 4) Bob sends INFO to alice. 5) Registrar receives INFO with GRUU RURI (;gr), removes Route pointing to it, and still has Route with Outbound flow token identifier pointing to OP. 6) Registrar decides to route based on RURI GRUU so performs lookup and obtains the binding for such a GRUU URI, and of course adds Route mirroring the registration Path. 7) INFO arrives to OP with Route belonging to the dialog (with Outbound flow identifier) and *also* Route produced by the Path. Typically this means "duplicated route set". So it could fail routing the request (loop), and OF COURSE, Route set is broken (RFC 3261) since Route set has been modified within a dialog. case B) 1) alice calls bob by using her GRUU in Contact. alice does NOT request Outbound usage (she does NOT add ;ob in Contact of INVITE) 2) OP does NOT add R-R. 3) OP routes to registrar which adds Record-Route and routes to Bob. 4) Bob sends INFO to alice. 5) Registrar receives INFO with GRUU RURI (;gr), removes Route pointing to = it. 6) Registrar routes based on GRUU so performs lookup and obtains the binding for such a GRUU URI, and of course adds Route mirroring the registration Path. 7) INFO arrives to OP with Route produced by the registration Path. OP will be able to route the request, of course, but Route set has also been modified (breaks RFC 3261). 8) Now alice wants to send BYE to bob. It just adds to the request the Route mirroring R-R received in the 200 for the initial INVITE, which just contains the Route pointing to the registrar (since OP did not R-R). 9) OP receives an in-dialog request *without* a Route pointing to it. In several proxy configurations this request would be rejected (why does the in-dialog request arrive to OP if it did not R-R?). One could argue "alice should send BYE to Registrar by following the Route set rules", but this is not how things work in Outbound, even less if the transport is WebSocket and the UA can just talk with OP). In both cases Route set is modified during a dialog and breaks RFC 3261. My opinion: This is GOOD since it makes possible for the dialog to continue alive even if the TCP connection between alice and OP was closed and re-opened (new Outbound flow token identifier, refreshed in a new registration so new Path). The "nice" solution to avoid problem in case a) dot 7 is: If a Registrar receives an in-dialog request with a GRUU RURI pointing to it, it MUST remove all the Route header present in the request (and ignore them), and then do lookup, replace RURI with the real binding and add Route mirroring registration Path values. After lot of thinking this seems to be the best and only? solution for GRUU to properly work for in-dialog requests. So I propose a new work RFC 5627-bis to clarify all of this, and also to "update RFC 3261" stating that dialog Route set can be modified if GRUU is used as Contact by any of the peers. Thoughts? Best regards. -- I=C3=B1aki Baz Castillo From pkyzivat@alum.mit.edu Fri Jul 5 08:53:46 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A95211E8319 for ; Fri, 5 Jul 2013 08:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.181 X-Spam-Level: X-Spam-Status: No, score=0.181 tagged_above=-999 required=5 tests=[AWL=0.318, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3, 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 b2Qd5RtsaeLa for ; Fri, 5 Jul 2013 08:53:40 -0700 (PDT) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:64]) by ietfa.amsl.com (Postfix) with ESMTP id 168A611E813D for ; Fri, 5 Jul 2013 08:53:39 -0700 (PDT) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta07.westchester.pa.mail.comcast.net with comcast id wfZo1l0050mv7h057ftfET; Fri, 05 Jul 2013 15:53:39 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta11.westchester.pa.mail.comcast.net with comcast id wfte1l00w3ZTu2S3XfteKo; Fri, 05 Jul 2013 15:53:39 +0000 Message-ID: <51D6EC02.8070508@alum.mit.edu> Date: Fri, 05 Jul 2013 11:53:38 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <003f01ce6aaf$aabda760$0038f620$@co.in> <011e01ce6c44$3c70e290$b552a7b0$@co.in> <019a01ce6d24$8ee95670$acbc0350$@co.in> <51C3267F.8040709@alum.mit.edu> <002301ce713c$c2672880$47357980$@co.in> <51CB0532.3020107@alum.mit.edu> <51CC52F0.3050809@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1373039619; bh=BnEIYbblnukOeibeautQIiGaQP+vGoUha9ept667iTw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=U2tkNGXeT8aTIT6MHd4lBEGynx2RKKMIx+kxHu8tkfTlKbXJhf4HA2h7/wNEy6P0Y Emz4GGsIKiw2ZJh1htMJz64NGz7VfHdITsOuLbRPyfjmuxD09wcPQUWVNj1c9c31Dr HzX9tmBMfIPWveNSNugaMNsKDCLMPB7CWFNWPXAetxtM/x14z9h/6neJ3NKu4zTdT9 eQWVyM3ghI9w3ZvjdZqIAGnEgalZRm9aJqip903N8xkgmpRARRMlsG5jVmMs7Zn5XE WbcQqT5TnNeJFJUQ5doUgNPSMa2JAMQbuR4d9N4/QgayY8qvZMS2pDh+o0wUxOaJJo usYrtUDL5F3JA== Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" Subject: Re: [sipcore] Open issues in draft-ietf-sipcore-sip-websocket-09 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 15:53:46 -0000 I don't claim to have the answer here, but the discussion is helpful. The analogy to other transports doesn't hold wrt TCP/UDP because until now both TCP and UDP support was *required*. There is a better analogy to IPv4 vs. IPv6. But in general all of these things end up being treated as examples or best practices rather than normative requirements. You make a good case for leaving it at that. Thanks, Paul On 7/5/13 5:36 AM, Iñaki Baz Castillo wrote: > Please, let me insist even a bit more on it: > > > > 2013/7/5 Iñaki Baz Castillo : >> Any TCP SIP UA is capable of listening for incoming connections but >> that does not mean that the proxy should not R-R. If the UA is behind >> NAT then RFC 5626 must be used (I avoid here proprietary similar >> mechanisms), and RFC 5626 *alreay* mandates R-R for such a mechanism >> to work. If GRUU is also in use then the proxy can decide not to R-R >> (not needed since incoming requests will arrive via the registration >> path which will of course include Outbound stuff). > > > > a) If the SIP-WS UA runs in a browser then the website developer can > make usage of RFC 5626 so the UA *requests* Outbound usage to its > proxy. > > b) If the SIP-WS UA runs in a desktop and is both a SIP WS Client and > SIP WS Server (and let's assume it has public IP) then it can avoid > requesting Outbound to the proxy. If the proxy does R-R it is because > the proxy wants to be in the patch of the dialog (local policy) and > not because it is required for the dialog to work. > > > Of course, in case b), if the peer does not speak WS and the proxy > does not R-R here we have a problem, but this is *exactly* the same > problem as if the caller was a UA using SCTP in its Contact URI. So > again, this is about local policy in the proxy whether to decide it > does R-R or not. > > I don't find "Record-Route" word in RFC 4168 so I expect there should > be no "MUST" keyword about Record-Route in > draft-ietc-sipcore-sip-websocket. Let me know if I'm wrong. > > > > Summarizing: > > - This is not an issue introduced by this new WS transport. > - The issue is not new. > - There are already standard mechanism to make it to work (the > *client* can request them to the proxy !). > - I see no reason at all to mandate nothing in the sip-ws draft about this. > - Guidelines section in the draft already covers it in an informative way. > > > > Hope I am right. > > Best regards. > > > > -- > Iñaki Baz Castillo > > From internet-drafts@ietf.org Mon Jul 8 12:24:28 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DA3521F9C55; Mon, 8 Jul 2013 12:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.076, 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 KJX0sDJ0DNmx; Mon, 8 Jul 2013 12:24:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F97721F9C38; Mon, 8 Jul 2013 12:24:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130708192425.32464.51141.idtracker@ietfa.amsl.com> Date: Mon, 08 Jul 2013 12:24:25 -0700 Cc: sipcore@ietf.org Subject: [sipcore] I-D Action: draft-ietf-sipcore-rfc4244bis-callflows-04.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 19:24:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Session Initiation Protocol Core Working = Group of the IETF. Title : Session Initiation Protocol (SIP) History-Info Header Ca= ll Flow Examples Author(s) : Mary Barnes Francois Audet Shida Schubert Hans Erik van Elburg Christer Holmberg Filename : draft-ietf-sipcore-rfc4244bis-callflows-04.txt Pages : 46 Date : 2013-07-08 Abstract: This document describes use cases and documents call flows which require the History-Info header field to capture the Request-URIs as a Session Initiation Protocol (SIP) Request is retargeted. The use cases are described along with the corresponding call flow diagrams and messaging details. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-rfc4244bis-callflows There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sipcore-rfc4244bis-callflows-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipcore-rfc4244bis-callflows-= 04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From jmillan@aliax.net Tue Jul 9 02:01:45 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0553621F9F12 for ; Tue, 9 Jul 2013 02:01:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.451 X-Spam-Level: X-Spam-Status: No, score=-2.451 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 wLYm74-Gz2VX for ; Tue, 9 Jul 2013 02:01:40 -0700 (PDT) Received: from mail-ve0-f169.google.com (mail-ve0-f169.google.com [209.85.128.169]) by ietfa.amsl.com (Postfix) with ESMTP id 7037A21F9EE6 for ; Tue, 9 Jul 2013 02:01:39 -0700 (PDT) Received: by mail-ve0-f169.google.com with SMTP id m1so4412789ves.28 for ; Tue, 09 Jul 2013 02:01:39 -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:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=/4z3q4djjSrtUmq/H+zI4T2q7aNRF4DedLa5w89zkSY=; b=McJaSnP1yoAgpU8kDpUlfcwMuG8G+v3fIW5BGDmW2CB0gfat+iKIUdpQ/E/1uQ6dbL vzFI9IWNljBqixXSW+Yc90GTOOpUUsBZhR6blTTVfiP6/BiOdqDPsLe7yXHw6l7Vtdwd lleoyNr37O3G5Q2g4bEkn/vUaJtwapNm6FuVCxidYj67LfSwG8ZmqghS+fNxHMSlAoch PdAamqEUIwVLxcJBIQFtSRc+20aCqBnKBIg94rzGx3qIwBu4EljKqO0UKejIlc7de3lR ofaroCocJqjrJgNA+e4/cVWDsrSo6+s5LB94FkcQx7Cyjf7RO2OLzWManBm8P7zq09vs d1yw== MIME-Version: 1.0 X-Received: by 10.220.59.69 with SMTP id k5mr1023709vch.34.1373360499336; Tue, 09 Jul 2013 02:01:39 -0700 (PDT) Received: by 10.220.49.138 with HTTP; Tue, 9 Jul 2013 02:01:39 -0700 (PDT) In-Reply-To: References: Date: Tue, 9 Jul 2013 11:01:39 +0200 Message-ID: From: =?UTF-8?B?Sm9zw6kgTHVpcyBNaWxsw6Fu?= To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=001a11c2012cb63b7a04e110681c X-Gm-Message-State: ALoCoQme60K9gW6Ibz/vgE+KusEC18gA5WcebBObpbihBvUHRVOuPJG5gxiWNbcUsOax7fqkg3AI Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" Subject: Re: [sipcore] Need RFC 5627-bis (GRUU improvements and clarifications, and RFC 3261 update) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 09:01:45 -0000 --001a11c2012cb63b7a04e110681c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I do agree with I=C3=B1aki that this scenario, which takes more relevance w= ith the time, requires a clarification. RFC 5627 Section 6.1 states that in order to avoid the exposed spiral case, the Path URI Must be discarded when the request contains Route header/s, but in fact, the Path determines the right route to the UA. ''' 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. ''' While RFC 5626 Section 7 states near the contrary. The proxy MUST send the request over the flow determined by the Path header: ''' 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. ''' 2013/7/5 I=C3=B1aki Baz Castillo > Hi, after leading a lot with Outbound and GRUU I think there are well > known problems and specification issues that IMHO should be addressed > in some kind of RFC 5627-bis. > > > The problem > ------------------ > > alice --- OP --- Registrar --- bob > > - OP is an Outbound EDGE Proxy. > - Registrar is GRUU capable. > > Flow showing the problem: > > - alice registers requesting GRUU. > - OP adds Path. > - alice obtains a GRUU URI. > > case A) > > 1) alice calls bob by using her GRUU in Contact. alice also requests > Outbound usage by adding ;ob in Contact of INVITE. > > 2) OP adds Record-Route. > > 3) OP routes to registrar which adds Record-Route and routes to Bob. > > 4) Bob sends INFO to alice. > > 5) Registrar receives INFO with GRUU RURI (;gr), removes Route > pointing to it, and still has Route with Outbound flow token > identifier pointing to OP. > > 6) Registrar decides to route based on RURI GRUU so performs lookup > and obtains the binding for such a GRUU URI, and of course adds Route > mirroring the registration Path. > > 7) INFO arrives to OP with Route belonging to the dialog (with > Outbound flow identifier) and *also* Route produced by the Path. > Typically this means "duplicated route set". So it could fail routing > the request (loop), and OF COURSE, Route set is broken (RFC 3261) > since Route set has been modified within a dialog. > > > case B) > > 1) alice calls bob by using her GRUU in Contact. alice does NOT > request Outbound usage (she does NOT add ;ob in Contact of INVITE) > > 2) OP does NOT add R-R. > > 3) OP routes to registrar which adds Record-Route and routes to Bob. > > 4) Bob sends INFO to alice. > > 5) Registrar receives INFO with GRUU RURI (;gr), removes Route pointing t= o > it. > > 6) Registrar routes based on GRUU so performs lookup and obtains the > binding for such a GRUU URI, and of course adds Route mirroring the > registration Path. > > 7) INFO arrives to OP with Route produced by the registration Path. OP > will be able to route the request, of course, but Route set has also > been modified (breaks RFC 3261). > > 8) Now alice wants to send BYE to bob. It just adds to the request the > Route mirroring R-R received in the 200 for the initial INVITE, which > just contains the Route pointing to the registrar (since OP did not > R-R). > > 9) OP receives an in-dialog request *without* a Route pointing to it. > In several proxy configurations this request would be rejected (why > does the in-dialog request arrive to OP if it did not R-R?). One could > argue "alice should send BYE to Registrar by following the Route set > rules", but this is not how things work in Outbound, even less if the > transport is WebSocket and the UA can just talk with OP). > > > > In both cases Route set is modified during a dialog and breaks RFC > 3261. My opinion: This is GOOD since it makes possible for the dialog > to continue alive even if the TCP connection between alice and OP was > closed and re-opened (new Outbound flow token identifier, refreshed in > a new registration so new Path). > > The "nice" solution to avoid problem in case a) dot 7 is: > > If a Registrar receives an in-dialog request with a GRUU RURI pointing > to it, it MUST remove all the Route header present in the request (and > ignore them), and then do lookup, replace RURI with the real binding > and add Route mirroring registration Path values. After lot of > thinking this seems to be the best and only? solution for GRUU to > properly work for in-dialog requests. > > > So I propose a new work RFC 5627-bis to clarify all of this, and also > to "update RFC 3261" stating that dialog Route set can be modified if > GRUU is used as Contact by any of the peers. > > > Thoughts? > > Best regards. > > > > > > -- > I=C3=B1aki Baz Castillo > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --=20 Jos=C3=A9 Luis Mill=C3=A1n --001a11c2012cb63b7a04e110681c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I do agree with I=C3=B1aki that this scenario, which takes= more relevance with the time, requires a clarification.

RFC 5627 Section 6.1 states that in order to avoid the exposed spiral case= , the Path URI Must be discarded when the request contains Route header/s, = but in fact, the Path determines the right route to the UA.

'''
Special consid=
erations 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 [<=
a href=3D"http://tools.ietf.org/html/rfc5627#ref-3" title=3D""Session =
Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjace=
nt Contacts"">3] as a matter of local policy; usage of GRUUs
will require this policy in order to avoid call spirals and likely
call failures.
'''

Whi= le RFC 5626 Section 7 states near the contrary. The proxy MUST send the req= uest over the flow determined by the Path header:

'''
The proxy uses the next-hop tar=
get 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.
'''



2013/7/5 I=C3=B1aki Baz Cast= illo <ibc@aliax.net>
Hi, after leading a lot with Outbound and GR= UU I think there are well
known problems and specification issues that IMHO should be addressed
in some kind of RFC 5627-bis.


The problem
------------------

alice --- OP --- Registrar --- bob

- OP is an Outbound EDGE Proxy.
- Registrar is GRUU capable.

Flow showing the problem:

- alice registers requesting GRUU.
- OP adds Path.
- alice obtains a GRUU URI.

case A)

1) alice calls bob by using her GRUU in Contact. alice also requests
Outbound usage by adding ;ob in Contact of INVITE.

2) OP adds Record-Route.

3) OP routes to registrar which adds Record-Route and routes to Bob.

4) Bob sends INFO to alice.

5) Registrar receives INFO with GRUU RURI (;gr), removes Route
pointing to it, and still has Route with Outbound flow token
identifier pointing to OP.

6) Registrar decides to route based on RURI GRUU so performs lookup
and obtains the binding for such a GRUU URI, and of course adds Route
mirroring the registration Path.

7) INFO arrives to OP with Route belonging to the dialog (with
Outbound flow identifier) and *also* Route produced by the Path.
Typically this means "duplicated =C2=A0route set". So it could fa= il routing
the request (loop), and OF COURSE, Route set is broken (RFC 3261)
since Route set has been modified within a dialog.


case B)

1) alice calls bob by using her GRUU in Contact. alice does NOT
request Outbound usage (she does NOT add ;ob in Contact of INVITE)

2) OP does NOT add R-R.

3) OP routes to registrar which adds Record-Route and routes to Bob.

4) Bob sends INFO to alice.

5) Registrar receives INFO with GRUU RURI (;gr), removes Route pointing to = it.

6) Registrar routes based on GRUU so performs lookup and obtains the
binding for such a GRUU URI, and of course adds Route mirroring the
registration Path.

7) INFO arrives to OP with Route produced by the registration Path. OP
will be able to route the request, of course, but Route set has also
been modified (breaks RFC 3261).

8) Now alice wants to send BYE to bob. It just adds to the request the
Route mirroring R-R received in the 200 for the initial INVITE, which
just contains the Route pointing to the registrar (since OP did not
R-R).

9) OP receives an in-dialog request *without* a Route pointing to it.
In several proxy configurations this request would be rejected (why
does the in-dialog request arrive to OP if it did not R-R?). One could
argue "alice should send BYE to Registrar by following the Route set rules", but this is not how things work in Outbound, even less if the<= br> transport is WebSocket and the UA can just talk with OP).



In both cases Route set is modified during a dialog and breaks RFC
3261. My opinion: This is GOOD since it makes possible for the dialog
to continue alive even if the TCP connection between alice and OP was
closed and re-opened (new Outbound flow token identifier, refreshed in
a new registration so new Path).

The "nice" solution to avoid problem in case a) dot 7 is:

If a Registrar receives an in-dialog request with a GRUU RURI pointing
to it, it MUST remove all the Route header present in the request (and
ignore them), and then do lookup, replace RURI with the real binding
and add Route mirroring registration Path values. After lot of
thinking this seems to be the best and only? solution for GRUU to
properly work for in-dialog requests.


So I propose a new work RFC 5627-bis to clarify all of this, and also
to "update RFC 3261" stating that dialog Route set can be modifie= d if
GRUU is used as Contact by any of the peers.


Thoughts?

Best regards.





--
I=C3=B1aki Baz Castillo
<ibc@aliax.net>
_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore



--
Jos=C3=A9 Lu= is Mill=C3=A1n
--001a11c2012cb63b7a04e110681c-- From rjsparks@nostrum.com Tue Jul 9 15:13:57 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0522F11E816F for ; Tue, 9 Jul 2013 15:13:55 -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, SPF_PASS=-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 7RrHCoaL+KjE for ; Tue, 9 Jul 2013 15:13:52 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id B15E221F9C8E for ; Tue, 9 Jul 2013 15:13:47 -0700 (PDT) Received: from unnumerable.local (mobile-166-147-068-200.mycingular.net [166.147.68.200]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r69MDkE4065923 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK) for ; Tue, 9 Jul 2013 17:13:47 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-ID: <51DC8B15.90709@nostrum.com> Date: Tue, 09 Jul 2013 17:13:41 -0500 From: Robert Sparks 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: "sipcore@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 166.147.68.200 is authenticated by a trusted mechanism) Subject: [sipcore] Already published forking callflow that shows 100s and CANCELs X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 22:13:57 -0000 SIPCORE - On the INSIPID list, James asked me for a callflow showing 100s and CANCELs that he could mark up with Session-IDs. I went looking for a callflow that had forking that showed 100s and CANCELs. I was hoping to find a simple one (either one or two proxies and two UAs). One that showed 183s establishing dialogs would be even better. I was really surprised to find very few examples of forking in ladder diagrams at _all_. There are none in 3665 or 3666. Adam pointed to a diagram in the 199 RFC, but it doesn't show 100s or CANCELs. Can anybody find something already published that does? If not, I'll make one for INSIPIDs purposes. (But I boggle). RjS From worley@shell01.TheWorld.com Wed Jul 10 13:04:09 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A885321F9E2A for ; Wed, 10 Jul 2013 13:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.68 X-Spam-Level: X-Spam-Status: No, score=-2.68 tagged_above=-999 required=5 tests=[AWL=0.300, 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 7qNaZMEt7gww for ; Wed, 10 Jul 2013 13:04:04 -0700 (PDT) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id 67B4621F9D91 for ; Wed, 10 Jul 2013 13:04:03 -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 r6AK2uD8000590; Wed, 10 Jul 2013 16:02:58 -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 r6AK2r02777453; Wed, 10 Jul 2013 16:02:53 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r6AK2px5778262; Wed, 10 Jul 2013 16:02:51 -0400 (EDT) Date: Wed, 10 Jul 2013 16:02:51 -0400 (EDT) Message-Id: <201307102002.r6AK2px5778262@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Robert Sparks In-reply-to: <51DC8B15.90709@nostrum.com> (rjsparks@nostrum.com) References: <51DC8B15.90709@nostrum.com> Cc: sipcore@ietf.org Subject: Re: [sipcore] Already published forking callflow that shows 100s and CANCELs X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 20:04:09 -0000 > From: Robert Sparks > > On the INSIPID list, James asked me for a callflow showing 100s and > CANCELs that he could mark up with Session-IDs. > > I went looking for a callflow that had forking that showed 100s and > CANCELs. I was hoping to find a simple one > (either one or two proxies and two UAs). One that showed 183s > establishing dialogs would be even better. These look like plausible sources to me: rfc 3087 section 4.2.2 rfc 3665 section 3.2, 3.8 rfc 5359 section 2.9 Dale From rjsparks@nostrum.com Wed Jul 10 13:37:28 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D81D511E812F for ; Wed, 10 Jul 2013 13:37:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, SPF_PASS=-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 io8NgtZQtIyu for ; Wed, 10 Jul 2013 13:37:28 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id BBDE311E8129 for ; Wed, 10 Jul 2013 13:37:27 -0700 (PDT) Received: from unnumerable.local ([4.30.77.1]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r6AKbJHW021002 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK); Wed, 10 Jul 2013 15:37:19 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-ID: <51DDC5FF.50507@nostrum.com> Date: Wed, 10 Jul 2013 15:37:19 -0500 From: Robert Sparks 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: "Dale R. Worley" References: <51DC8B15.90709@nostrum.com> <201307102002.r6AK2px5778262@shell01.TheWorld.com> In-Reply-To: <201307102002.r6AK2px5778262@shell01.TheWorld.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 4.30.77.1 is authenticated by a trusted mechanism) Cc: sipcore@ietf.org Subject: Re: [sipcore] Already published forking callflow that shows 100s and CANCELs X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 20:37:29 -0000 On 7/10/13 3:02 PM, Dale R. Worley wrote: >> From: Robert Sparks >> >> On the INSIPID list, James asked me for a callflow showing 100s and >> CANCELs that he could mark up with Session-IDs. >> >> I went looking for a callflow that had forking that showed 100s and >> CANCELs. I was hoping to find a simple one >> (either one or two proxies and two UAs). One that showed 183s >> establishing dialogs would be even better. > These look like plausible sources to me: > > rfc 3087 section 4.2.2 > rfc 3665 section 3.2, 3.8 > rfc 5359 section 2.9 > > Dale Thanks Dale. That last one is a good spot. (I had looked already at the first two, but they either don't show the 100s/CANCELS, or don't have forking) RjS From mary.ietf.barnes@gmail.com Wed Jul 10 15:49:56 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2092D11E8135 for ; Wed, 10 Jul 2013 15:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.018, 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 qOWz3QxlnavK for ; Wed, 10 Jul 2013 15:49:55 -0700 (PDT) Received: from mail-qe0-x22f.google.com (mail-qe0-x22f.google.com [IPv6:2607:f8b0:400d:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id A108C11E8141 for ; Wed, 10 Jul 2013 15:49:55 -0700 (PDT) Received: by mail-qe0-f47.google.com with SMTP id 1so4077850qec.20 for ; Wed, 10 Jul 2013 15:49:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=uIjPe6BFtv2uU/r/ocl8u0q/R62ORbYpIGoB6phku/0=; b=MDj3NjvZq2ctzPS2TdM4ckz7cxAqZM5tLebQ/jwk5wlZDxNlsauLmxjMBhVLuAQbBv rOe6px8AsWKD+DWUOW29SNr+QarUveUcuZz57gN7vMSj44m20MEYJFrc/tdtH43xdDqd 9Qi5+XMnyVvVgz1JDVF/CRezEXWKz2ZtgbZZrJz0QfiXClIEZ3MBZ2Mzh3tsozKXDVbN 6yzycc6i0OiiL/nhdb/tgarzQDO8vJ4TQEb5mXCwJlcBkGlcqelmvfM4tjZybjUBucLb EzvaCQtXMhWymD10G1H1OWviFrqK2jWmHcPL3VidOy1fWw4uQ9omg7Z0dkwj3TtEzP/Y rl/g== MIME-Version: 1.0 X-Received: by 10.224.149.199 with SMTP id u7mr30220998qav.37.1373496594072; Wed, 10 Jul 2013 15:49:54 -0700 (PDT) Received: by 10.49.76.167 with HTTP; Wed, 10 Jul 2013 15:49:54 -0700 (PDT) Date: Wed, 10 Jul 2013 17:49:54 -0500 Message-ID: From: Mary Barnes To: SIPCORE Content-Type: text/plain; charset=ISO-8859-1 Subject: [sipcore] Is there a meeting in Berlin? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 22:49:56 -0000 I didn't see it on the main agenda, but I also couldn't find a note to the mailing indicating such. Is it correct that SIPCORE is not meeting in Berlin? There is one document that has had some discussion on the DISPATCH mailing list that could most likely be progressed in SIPCORE: http://www.ietf.org/id/draft-johansson-dane-sip-00.txt Thanks, Mary. From pkyzivat@alum.mit.edu Wed Jul 10 18:54:11 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F387B11E80EE for ; Wed, 10 Jul 2013 18:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.125 X-Spam-Level: X-Spam-Status: No, score=-0.125 tagged_above=-999 required=5 tests=[AWL=0.312, 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 OnGBCVJYWVE6 for ; Wed, 10 Jul 2013 18:54:06 -0700 (PDT) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id 0319E11E80E4 for ; Wed, 10 Jul 2013 18:54:05 -0700 (PDT) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta14.westchester.pa.mail.comcast.net with comcast id yo0n1l0050xGWP85Epu42B; Thu, 11 Jul 2013 01:54:04 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id ypu41l00q3ZTu2S3Ypu4wc; Thu, 11 Jul 2013 01:54:04 +0000 Message-ID: <51DE103C.40406@alum.mit.edu> Date: Wed, 10 Jul 2013 21:54:04 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: sipcore@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1373507644; bh=M1d9emxE1Rj0SivYz1AGCzFDbShSDgerdH86hEhmUNY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Mm/AdGjVLnl2MwTdugzjD8KKALXDusyGrIVyz9z556Yd94XhyicJ9iIkl2ygYtjpV ywfvB9RhfR+vKIey+oW+6oSXUAmdrfu+gSu8otWLqNo6yDGKZuOLHNuh44s2RdjZvi U91BxnY0HV/tV+GDYLDPrGKW/a45+RVwFN5MYWhtc3hf+60kWCK5p+ZWGlUIQcWpj5 KTCbdKturOHOR2ik8L0dmoLR9xOcMOrpbhjJablF7BKT2udMAt19/H4CkVLX9iXpb+ SN21/fVYUBJXUvk/2j5EtE2zCq4lzXiD2S4im8MmGwTnCuMttcyQ4e5d/q8vc8mesV It4xudbG9S2gA== Subject: Re: [sipcore] Is there a meeting in Berlin? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 01:54:11 -0000 No, no meeting. On 7/10/13 6:49 PM, Mary Barnes wrote: > I didn't see it on the main agenda, but I also couldn't find a note to > the mailing indicating such. Is it correct that SIPCORE is not > meeting in Berlin? > > There is one document that has had some discussion on the DISPATCH > mailing list that could most likely be progressed in SIPCORE: > http://www.ietf.org/id/draft-johansson-dane-sip-00.txt > > > Thanks, > Mary. > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From worley@shell01.TheWorld.com Thu Jul 11 10:00:18 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C62BF21F9CFE for ; Thu, 11 Jul 2013 10:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.83 X-Spam-Level: X-Spam-Status: No, score=-2.83 tagged_above=-999 required=5 tests=[AWL=0.150, 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 0uWowpfzPQLG for ; Thu, 11 Jul 2013 10:00:12 -0700 (PDT) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id 2573911E80ED for ; Thu, 11 Jul 2013 10:00: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 r6BGxsg7020035 for ; Thu, 11 Jul 2013 12:59:56 -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 r6BGxsEv824669 for ; Thu, 11 Jul 2013 12:59:54 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r6BGxpgN823965; Thu, 11 Jul 2013 12:59:51 -0400 (EDT) Date: Thu, 11 Jul 2013 12:59:51 -0400 (EDT) Message-Id: <201307111659.r6BGxpgN823965@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: sipcore@ietf.org In-reply-to: <51DDC5FF.50507@nostrum.com> (rjsparks@nostrum.com) References: <51DC8B15.90709@nostrum.com> <201307102002.r6AK2px5778262@shell01.TheWorld.com> <51DDC5FF.50507@nostrum.com> Subject: Re: [sipcore] Already published forking callflow that shows 100s and CANCELs X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 17:00:19 -0000 > From: Robert Sparks > > Thanks Dale. That last one is a good spot. > (I had looked already at the first two, but they either don't show the > 100s/CANCELS, or don't have forking) The technique I used this for query is to search all the RFCs for ones that contain these regexps: |.*|.*|.*| (to find railroad diagrams containing forking) 100 trying (case insensitive) CANCEL There are only 13 RFCs that pass the test, and searching for the first regexp with an editor find the railroad diagrams directly. In *nix, this can be done with one command line: grep --files-with-match -E '\' ~/RFCs/rfc[3-9]???.txt | xargs grep --files-with-match -- '|.*|.*|.*|' | xargs grep --files-with-match -i -- '100 trying' | xargs grep --files-with-match -- 'CANCEL' Similar searches can answer a remarkable number of questions about the corpus of RFCs, especially questions about "How is *** normally formatted in RFCs?" Dale From worley@shell01.TheWorld.com Thu Jul 11 12:46:11 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B23421F9931 for ; Thu, 11 Jul 2013 12:46:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.88 X-Spam-Level: X-Spam-Status: No, score=-2.88 tagged_above=-999 required=5 tests=[AWL=0.100, 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 6pdVUogVoDEq for ; Thu, 11 Jul 2013 12:46:05 -0700 (PDT) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id 2EDA621F968B for ; Thu, 11 Jul 2013 12:46:03 -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 r6BJjQ5h005773 for ; Thu, 11 Jul 2013 15:45: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 r6BJjQUL824153 for ; Thu, 11 Jul 2013 15:45:26 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r6BJjORN831823; Thu, 11 Jul 2013 15:45:24 -0400 (EDT) Date: Thu, 11 Jul 2013 15:45:24 -0400 (EDT) Message-Id: <201307111945.r6BJjORN831823@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: sipcore@ietf.org Subject: [sipcore] Copy edits for draft-ietf-sipcore-rfc4244bis-callflows-04 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 19:46:11 -0000 Thanks to Shida for revising draft-ietf-sipcore-rfc4244bis-callflows! This is a bunch of copy-edits to draft-ietf-sipcore-rfc4244bis-callflows-04. Section pointers are marked with "*" at the left margin. Discussion items are marked with "." at the left margin. All copy-edits are displayed in "diff" format. All of my copy-edits to draft-ietf-sipcore-rfc4244bis-callflows-03 have been resolved, excepting any that may be repeated below * Section 3.1. Sequentially Forking (History-Info in Response) . In message F11, the text "index=1.2.1" appears twice. F11 486 Busy Here home -> example.com SIP/2.0 486 Busy Here Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bKx5st Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 From: Alice ;tag=sr3dds To: Bob ;tag=55rdds Call-Id: 12345600@example.com History-Info: ;index=1 History-Info: ;\ index=1.1;rc=1 History-Info: ;\ index=1.2;mp=1 History-Info: ;\ - index=1.2.1;index=1.2.1;rc=1.2 + index=1.2.1;rc=1.2 History-Info: ;index=1.3;mp=1 History-Info: ;index=1.3.1;rc=1.3 CSeq: 1 INVITE Content-Length: 0 * Section 3.6. PBX Voicemail Example . In message F7, it appears that the Reason values 480 in index 1.3 and 1.3.1 are both incorrectly changed to 408, because the value 480 is used in the preceding message (which is the first appearance of 1.3 and 1.3.3). F6 INVITE Example.com -> VM INVITE sip:vm@192.0.2.6;target=sip:bob%40example.com;cause=480\ SIP/2.0 Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bK4523 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK42t2 Max-Forward: 69 From: Alice ;tag=kkaz- To: Bob Supported: histinfo Call-Id: 12345600@example.com CSeq: 1 INVITE History-Info: ;index=1 History-Info: ;\ index=1.1;rc=1 History-Info: ;index=1.2;mp=1 History-Info: ;index=1.2.1;rc=1.2 History-Info: ;\ index=1.3;mp=1 History-Info: ;\ index=1.3.1;rc=1.3 Contact: Alice Content-Type: application/sdp Content-Length: F7 200 OK VM -> Example.com SIP/2.0 200 OK Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bK4523;\ received=192.0.2.101 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK42t2 From: Alice ;tag=kkaz- To: Bob ;tag=3dweggs Supported: histinfo Call-Id: 12345600@example.com CSeq: 1 INVITE History-Info: ;index=1 History-Info: ;\ index=1.1;rc=1 History-Info: ;index=1.2;mp=1 History-Info: ;index=1.2.1;rc=1.2 History-Info: ;\ + target=sip:bob%40example.com;cause=480>;\ index=1.3;mp=1 History-Info: ;\ + target=sip:bob%40example.com;cause=480>;\ index=1.3.1;rc=1.3 Contact: Content-Type: application/sdp Content-Length: * Section 3.7. Consumer Voicemail Example . In message F4, index 1.1, there is a '>' that is doubled. In F5, index 1.1, this '>>' is turned into '>">'. In F6, index 1.1, it is again '>>'. In message F7, index 1.1, it is shown correctly as '>'. . In message F6, index 1.2.2 has the portion "index=1.2.2;mp=1.2" on a separate line that does not start with whitespace. As such, it is not a continuation of the previous header line. What was probably intended was that that line was the tail of the preceding line, which now contains just a semicolon. . In message F6, index 1.2 has "Reason=...408", but the fork descendant from 1.2 has not terminated yet. This Reason parameter should be on index 1.2.1 instead. F7 needs the same fix on index 1.2, although index 1.2.1 is correct. . In message F6, the URI in index 1.2.2 probably needs a "cause=408" parameter. This isn't absolutely certain, as the target of the URI is a service whose exact interface is unspecified, but it seems like adding "cause" would be the best practice re RFC 4458. The same change would then be needed in message F7. The "cause=408" parameter would then probably be carried over into the URI of index 1.2.2.1 (in both F6 and F7). In any case, the "cause=408" *header* parameter in message F6, index 1.2.2.1 is incorrect. . In message F6, index 1.2.2.1, the "rc" parameter should be 1.2.2 rather than 1.3. F4 INVITE Example.com -> Carol INVITE sip:carol@192.0.2.4 SIP/2.0 Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bK24s5 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK42t2 Max-Forward: 69 From: Alice ;tag=kkaz- To: Bob Supported: histinfo Call-Id: 12345600@example.com CSeq: 1 INVITE History-Info: ;index=1 History-Info: >\ + %3Btext%3D%22Moved%20Temporarily%22>\ ;index=1.1;rc=1 History-Info: ;index=1.2;mp=1 History-Info: ;index=1.2.1;rc=1.2 Contact: Alice Content-Type: application/sdp Content-Length: F5 180 Ringing Carol -> Example.com SIP/2.0 180 Ringing Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bK24s5;\ received=192.0.2.101 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK42t2 From: Alice ;tag=kkaz- To: Bob ;tag=setss3x Supported: histinfo Call-Id: 12345600@example.com CSeq: 1 INVITE History-Info: ;index=1 History-Info: ">\ + %3Btext%3D%22Moved%20Temporarily%22>\ ;index=1.1;rc=1 History-Info: ;index=1.2;mp=1 History-Info: ;index=1.2.1;rc=1.2 Contact: Content-Type: application/sdp Content-Length: F6 INVITE Example.com -> VM INVITE sip:vm@192.0.2.6;target=sip:carol%40example.com SIP/2.0 Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bKbbg4 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK42t2 Max-Forward: 69 From: Alice ;tag=kkaz- To: Bob Supported: histinfo Call-Id: 12345600@example.com CSeq: 1 INVITE History-Info: ;index=1 History-Info: >\ + %3Btext%3D%22Moved%20Temporarily%22>\ ;index=1.1;rc=1 - History-Info: ;\ + History-Info: ;\ index=1.2;mp=1 - History-Info: ;index=1.2.1;rc=1.2 + History-Info: ;index=1.2.1;rc=1.2 - History-Info: \ - ; - index=1.2.2;mp=1.2 + History-Info: \ + ;index=1.2.2;mp=1.2 - History-Info: \ - ;cause=408;index=1.2.2.1;rc=1.3 + History-Info: \ + ;index=1.2.2.1;rc=1.2.2 Contact: Alice Content-Type: application/sdp Content-Length: F7 200 OK VM -> Example.com SIP/2.0 200 OK Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bKbbg4 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK42t2 From: Alice ;tag=kkaz- To: Bob ;tag=3dweggs Supported: histinfo Call-Id: 12345600@example.com CSeq: 1 INVITE History-Info: ;index=1 History-Info: \ ;index=1.1;rc=1 - History-Info: ;\ + History-Info: ;\ index=1.2;mp=1 History-Info: ;\ index=1.2.1;rc=1.2 - History-Info: ;\ + History-Info: ;\ index=1.2.2;mp=1.2 - History-Info: ;\ + History-Info: ;\ index=1.2.2.1;rc=1.2.2 Contact: Content-Type: application/sdp Content-Length: Dale From shida@ntt-at.com Thu Jul 11 13:32:21 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F4A911E813D for ; Thu, 11 Jul 2013 13:32:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.058 X-Spam-Level: X-Spam-Status: No, score=-101.058 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 ngLVwEis6RDq for ; Thu, 11 Jul 2013 13:32:17 -0700 (PDT) Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id C519C21F9AC1 for ; Thu, 11 Jul 2013 13:32:16 -0700 (PDT) Received: from [50.152.169.249] (port=55829 helo=[192.168.1.8]) by gator465.hostgator.com with esmtpa (Exim 4.80) (envelope-from ) id 1UxNXC-0000QX-BE; Thu, 11 Jul 2013 15:32:14 -0500 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Shida Schubert In-Reply-To: <201307111945.r6BJjORN831823@shell01.TheWorld.com> Date: Thu, 11 Jul 2013 13:32:13 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <40E95101-CBDA-421D-B23D-DA238F90C2D9@ntt-at.com> References: <201307111945.r6BJjORN831823@shell01.TheWorld.com> To: Dale R. Worley X-Mailer: Apple Mail (2.1283) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator465.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.8]) [50.152.169.249]:55829 X-Source-Auth: shida.schubert+tingle.jp X-Email-Count: 1 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t Cc: sipcore@ietf.org Subject: Re: [sipcore] Copy edits for draft-ietf-sipcore-rfc4244bis-callflows-04 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 20:32:21 -0000 Hi Dale; Thank you again for a thorough review and I apologize for=20 redundant error on my side.=20 I will try to reflect these fixes and update it before the submission=20= deadline, coming Monday. Thanks again Shida On Jul 11, 2013, at 12:45 PM, Dale R. Worley wrote: > Thanks to Shida for revising draft-ietf-sipcore-rfc4244bis-callflows! >=20 > This is a bunch of copy-edits to > draft-ietf-sipcore-rfc4244bis-callflows-04. Section pointers are > marked with "*" at the left margin. Discussion items are marked with > "." at the left margin. All copy-edits are displayed in "diff" > format. >=20 > All of my copy-edits to draft-ietf-sipcore-rfc4244bis-callflows-03 > have been resolved, excepting any that may be repeated below >=20 > * Section 3.1. Sequentially Forking (History-Info in Response) >=20 > . In message F11, the text "index=3D1.2.1" appears twice. >=20 > F11 486 Busy Here home -> example.com >=20 > SIP/2.0 486 Busy Here > Via: SIP/2.0/TCP proxy.example.com:5060;branch=3Dz9hG4bKx5st > Via: SIP/2.0/TCP 192.0.2.3:5060;branch=3Dz9hG4bK4321 > From: Alice ;tag=3Dsr3dds > To: Bob ;tag=3D55rdds > Call-Id: 12345600@example.com > History-Info: ;index=3D1 > History-Info: ;\ > index=3D1.1;rc=3D1 > History-Info: ;\ > = index=3D1.2;mp=3D1 > History-Info: ;\ > - index=3D1.2.1;index=3D1.2.1;rc=3D1.2 > + index=3D1.2.1;rc=3D1.2 > History-Info: ;index=3D1.3;mp=3D1 > History-Info: ;index=3D1.3.1;rc=3D1.3 > CSeq: 1 INVITE > Content-Length: 0 >=20 >=20 > * Section 3.6. PBX Voicemail Example >=20 > . In message F7, it appears that the Reason values 480 in index 1.3 > and 1.3.1 are both incorrectly changed to 408, because the value 480 > is used in the preceding message (which is the first appearance of > 1.3 and 1.3.3). >=20 > F6 INVITE Example.com -> VM >=20 > INVITE sip:vm@192.0.2.6;target=3Dsip:bob%40example.com;cause=3D480\ > SIP/2.0 > Via: SIP/2.0/TCP proxy.example.com:5060;branch=3Dz9hG4bK4523 > Via: SIP/2.0/TCP 192.0.2.3:5060;branch=3Dz9hG4bK42t2 > Max-Forward: 69 > From: Alice ;tag=3Dkkaz- > To: Bob > Supported: histinfo > Call-Id: 12345600@example.com > CSeq: 1 INVITE > History-Info: ;index=3D1 > History-Info: ;\ > index=3D1.1;rc=3D1 > History-Info: = = 408>;index=3D1.2;mp=3D1 > History-Info: = 408>;index=3D1.2.1;rc=3D1.2 > History-Info: target=3Dsip:bob%40example.com;cause=3D480>;\ > index=3D1.3;mp=3D1 > History-Info: target=3Dsip:bob%40example.com;cause=3D480>;\ > index=3D1.3.1;rc=3D1.3 > Contact: Alice > Content-Type: application/sdp > Content-Length: >=20 >=20 > F7 200 OK VM -> Example.com >=20 > SIP/2.0 200 OK > Via: SIP/2.0/TCP proxy.example.com:5060;branch=3Dz9hG4bK4523;\ > received=3D192.0.2.101 > Via: SIP/2.0/TCP 192.0.2.3:5060;branch=3Dz9hG4bK42t2 > From: Alice ;tag=3Dkkaz- > To: Bob ;tag=3D3dweggs > Supported: histinfo > Call-Id: 12345600@example.com > CSeq: 1 INVITE > History-Info: ;index=3D1 > History-Info: ;\ > index=3D1.1;rc=3D1 > History-Info: = = 408>;index=3D1.2;mp=3D1 > History-Info: 408>;index=3D1.2.1;rc=3D1.2 > History-Info: - target=3Dsip:bob%40example.com;cause=3D408>;\ > + target=3Dsip:bob%40example.com;cause=3D480>;\ > index=3D1.3;mp=3D1 > History-Info: - target=3Dsip:bob%40example.com;cause=3D408>;\ > + target=3Dsip:bob%40example.com;cause=3D480>;\ > index=3D1.3.1;rc=3D1.3 > Contact: > Content-Type: application/sdp > Content-Length: >=20 >=20 >=20 > * Section 3.7. Consumer Voicemail Example >=20 > . In message F4, index 1.1, there is a '>' that is doubled. In F5, > index 1.1, this '>>' is turned into '>">'. In F6, index 1.1, it is > again '>>'. In message F7, index 1.1, it is shown correctly as '>'. >=20 > . In message F6, index 1.2.2 has the portion "index=3D1.2.2;mp=3D1.2" = on a > separate line that does not start with whitespace. As such, it is not > a continuation of the previous header line. What was probably > intended was that that line was the tail of the preceding line, which > now contains just a semicolon. >=20 > . In message F6, index 1.2 has "Reason=3D...408", but the fork > descendant from 1.2 has not terminated yet. This Reason parameter > should be on index 1.2.1 instead. F7 needs the same fix on index 1.2, > although index 1.2.1 is correct. >=20 > . In message F6, the URI in index 1.2.2 probably needs a "cause=3D408" > parameter. This isn't absolutely certain, as the target of the URI is > a service whose exact interface is unspecified, but it seems like > adding "cause" would be the best practice re RFC 4458. The same > change would then be needed in message F7. The "cause=3D408" = parameter > would then probably be carried over into the URI of index 1.2.2.1 (in > both F6 and F7). In any case, the "cause=3D408" *header* parameter in > message F6, index 1.2.2.1 is incorrect. >=20 > . In message F6, index 1.2.2.1, the "rc" parameter should be 1.2.2 > rather than 1.3. >=20 > F4 INVITE Example.com -> Carol >=20 > INVITE sip:carol@192.0.2.4 SIP/2.0 > Via: SIP/2.0/TCP proxy.example.com:5060;branch=3Dz9hG4bK24s5 > Via: SIP/2.0/TCP 192.0.2.3:5060;branch=3Dz9hG4bK42t2 > Max-Forward: 69 > From: Alice ;tag=3Dkkaz- > To: Bob > Supported: histinfo > Call-Id: 12345600@example.com > CSeq: 1 INVITE > History-Info: ;index=3D1 > History-Info: - = %3Btext%3D%22Moved%20Temporarily%22>>\ > + = %3Btext%3D%22Moved%20Temporarily%22>\ > ;index=3D1.1;rc=3D1 > History-Info: ;index=3D1.2;mp=3D1 > History-Info: ;index=3D1.2.1;rc=3D1.2 > Contact: Alice > Content-Type: application/sdp > Content-Length: >=20 >=20 > F5 180 Ringing Carol -> Example.com >=20 > SIP/2.0 180 Ringing > Via: SIP/2.0/TCP proxy.example.com:5060;branch=3Dz9hG4bK24s5;\ > received=3D192.0.2.101 > Via: SIP/2.0/TCP 192.0.2.3:5060;branch=3Dz9hG4bK42t2 > From: Alice ;tag=3Dkkaz- > To: Bob ;tag=3Dsetss3x > Supported: histinfo > Call-Id: 12345600@example.com > CSeq: 1 INVITE > History-Info: ;index=3D1 > History-Info: - = %3Btext%3D%22Moved%20Temporarily%22>">\ > + = %3Btext%3D%22Moved%20Temporarily%22>\ > ;index=3D1.1;rc=3D1 > History-Info: ;index=3D1.2;mp=3D1 > History-Info: ;index=3D1.2.1;rc=3D1.2 > Contact: > Content-Type: application/sdp > Content-Length: >=20 >=20 > F6 INVITE Example.com -> VM >=20 > INVITE sip:vm@192.0.2.6;target=3Dsip:carol%40example.com SIP/2.0 > Via: SIP/2.0/TCP proxy.example.com:5060;branch=3Dz9hG4bKbbg4 > Via: SIP/2.0/TCP 192.0.2.3:5060;branch=3Dz9hG4bK42t2 > Max-Forward: 69 > From: Alice ;tag=3Dkkaz- > To: Bob > Supported: histinfo > Call-Id: 12345600@example.com > CSeq: 1 INVITE > History-Info: ;index=3D1 > History-Info: - = %3Btext%3D%22Moved%20Temporarily%22>>\ > + = %3Btext%3D%22Moved%20Temporarily%22>\ > ;index=3D1.1;rc=3D1 > - History-Info: ;\ > + History-Info: ;\ > index=3D1.2;mp=3D1 > - History-Info: ;index=3D1.2.1;rc=3D1.2 > + History-Info: = ;index=3D1.2.1;rc=3D1.2 > - History-Info: \= > - = ; > - index=3D1.2.2;mp=3D1.2 > + History-Info: = \ > + = ;index=3D1.2.2;mp=3D1.2 > - History-Info: \ > - = ;cause=3D408;index=3D1.2.2.1;rc=3D1.3 > + History-Info: = \ > + = ;index=3D1.2.2.1;rc=3D1.2.2 > Contact: Alice > Content-Type: application/sdp > Content-Length: >=20 >=20 > F7 200 OK VM -> Example.com >=20 > SIP/2.0 200 OK > Via: SIP/2.0/TCP proxy.example.com:5060;branch=3Dz9hG4bKbbg4 > Via: SIP/2.0/TCP 192.0.2.3:5060;branch=3Dz9hG4bK42t2 > From: Alice ;tag=3Dkkaz- > To: Bob ;tag=3D3dweggs > Supported: histinfo > Call-Id: 12345600@example.com > CSeq: 1 INVITE > History-Info: ;index=3D1 > History-Info: = %3Btext%3D%22Moved%20Temporarily%22>\ > ;index=3D1.1;rc=3D1 > - History-Info: ;\ > + History-Info: ;\ > index=3D1.2;mp=3D1 > History-Info: ;\ > = index=3D1.2.1;rc=3D1.2 > - History-Info: = ;\ > + History-Info: = ;\ > index=3D1.2.2;mp=3D1.2 > - History-Info: ;\ > + History-Info: = ;\ > index=3D1.2.2.1;rc=3D1.2.2 > Contact: > Content-Type: application/sdp > Content-Length: >=20 > Dale > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From internet-drafts@ietf.org Thu Jul 11 22:49:57 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11FF911E820D; Thu, 11 Jul 2013 22:49:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.529 X-Spam-Level: X-Spam-Status: No, score=-102.529 tagged_above=-999 required=5 tests=[AWL=0.071, 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 HtqbGQ7BOdoV; Thu, 11 Jul 2013 22:49:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9054D11E8141; Thu, 11 Jul 2013 22:49:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130712054956.22727.16385.idtracker@ietfa.amsl.com> Date: Thu, 11 Jul 2013 22:49:56 -0700 Cc: sipcore@ietf.org Subject: [sipcore] I-D Action: draft-ietf-sipcore-rfc4244bis-callflows-05.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 05:49:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Session Initiation Protocol Core Working = Group of the IETF. Title : Session Initiation Protocol (SIP) History-Info Header Ca= ll Flow Examples Author(s) : Mary Barnes Francois Audet Shida Schubert Hans Erik van Elburg Christer Holmberg Filename : draft-ietf-sipcore-rfc4244bis-callflows-05.txt Pages : 46 Date : 2013-07-11 Abstract: This document describes use cases and documents call flows which require the History-Info header field to capture the Request-URIs as a Session Initiation Protocol (SIP) Request is retargeted. The use cases are described along with the corresponding call flow diagrams and messaging details. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-rfc4244bis-callflows There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sipcore-rfc4244bis-callflows-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipcore-rfc4244bis-callflows-= 05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Jul 15 04:36:37 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69BC611E80E3; Mon, 15 Jul 2013 04:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.067, 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 DvY+n2SVef+f; Mon, 15 Jul 2013 04:36:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0269B21F9F6E; Mon, 15 Jul 2013 04:36:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130715113636.8882.43109.idtracker@ietfa.amsl.com> Date: Mon, 15 Jul 2013 04:36:36 -0700 Cc: sipcore@ietf.org Subject: [sipcore] I-D Action: draft-ietf-sipcore-rfc4244bis-callflows-06.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 11:36:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Session Initiation Protocol Core Working = Group of the IETF. Title : Session Initiation Protocol (SIP) History-Info Header Ca= ll Flow Examples Author(s) : Mary Barnes Francois Audet Shida Schubert Hans Erik van Elburg Christer Holmberg Filename : draft-ietf-sipcore-rfc4244bis-callflows-06.txt Pages : 46 Date : 2013-07-14 Abstract: This document describes use cases and documents call flows which require the History-Info header field to capture the Request-URIs as a Session Initiation Protocol (SIP) Request is retargeted. The use cases are described along with the corresponding call flow diagrams and messaging details. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-rfc4244bis-callflows There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sipcore-rfc4244bis-callflows-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipcore-rfc4244bis-callflows-= 06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From partha@parthasarathi.co.in Wed Jul 17 10:13:03 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE1B521F9E1A for ; Wed, 17 Jul 2013 10:13:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.09 X-Spam-Level: X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[AWL=-0.359, BAYES_40=-0.185, IP_NOT_FRIENDLY=0.334, 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 MxIkL69jJr7s for ; Wed, 17 Jul 2013 10:12:59 -0700 (PDT) Received: from smtp.mailhostbox.com (outbound-us2.mailhostbox.com [69.93.141.233]) by ietfa.amsl.com (Postfix) with ESMTP id 82CCB21F9D2C for ; Wed, 17 Jul 2013 10:12:59 -0700 (PDT) Received: from userPC (unknown [122.179.36.181]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id 0EC27638FF9; Wed, 17 Jul 2013 17:12:54 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1374081178; bh=1ACes02bYEpsm/GtTVclk2Z4sZdA5Ecs1FzSydFzKMU=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=jMU9X+lTjwnx2Wv03ItmQbguh1YR0RljqzOToc1m9suQvGgIiCwuCVMvx6AktVm3U 8cWTzYFgRYNg064xZSVqPUTYCK0e4+aN1S5ntNXx70neTsPpUmSJKabIEGIrPY+CdB VHQaNhLXJ99M9BwE3GP40qEvEAg82rf/nA0y30AY= From: "Parthasarathi R" To: =?UTF-8?Q?'I=C3=B1aki_Baz_Castillo'?= , "'Paul Kyzivat'" References: <003f01ce6aaf$aabda760$0038f620$@co.in> <011e01ce6c44$3c70e290$b552a7b0$@co.in> <019a01ce6d24$8ee95670$acbc0350$@co.in> <51C3267F.8040709@alum.mit.edu> <002301ce713c$c2672880$47357980$@co.in> <51CB0532.3020107@alum.mit.edu> <51CC52F0.3050809@alum.mit.edu> In-Reply-To: Date: Wed, 17 Jul 2013 22:42:39 +0530 Message-ID: <02de01ce8310$db8c8d60$92a5a820$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac55Yz6kEcZV8/KERuy5crCmpqB5nQJrXFig Content-Language: en-us X-CTCH-RefID: str=0001.0A0C0208.51E6D09A.00FB, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 70.87.28.142 Cc: "'SIPCORE \(Session Initiation Protocol Core\) WG'" Subject: Re: [sipcore] Open issues in draft-ietf-sipcore-sip-websocket-09 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 17:13:03 -0000 Hi Inaki, I have mentioned earlier = (http://www.ietf.org/mail-archive/web/sipcore/current/msg05614.html) = that the issue raised by me is related to SIP routing and you are mixing = it with NAT & Firewall. In case you wish to cover the issue in the holistic way, Please suggest = the complete text. I have disagreement for the statement that SIP over SCTP does not = document those issue, so SIP over WebSocket will not document the same.=20 Thanks Partha PS: I have work experience in SCTP transport with RR added by proxy to = overcome this issue. > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > Behalf Of I=C3=B1aki Baz Castillo > Sent: Friday, July 05, 2013 3:07 PM > To: Paul Kyzivat > Cc: SIPCORE (Session Initiation Protocol Core) WG > Subject: Re: [sipcore] Open issues in = draft-ietf-sipcore-sip-websocket- > 09 >=20 > Please, let me insist even a bit more on it: >=20 >=20 >=20 > 2013/7/5 I=C3=B1aki Baz Castillo : > > Any TCP SIP UA is capable of listening for incoming connections but > > that does not mean that the proxy should not R-R. If the UA is = behind > > NAT then RFC 5626 must be used (I avoid here proprietary similar > > mechanisms), and RFC 5626 *alreay* mandates R-R for such a mechanism > > to work. If GRUU is also in use then the proxy can decide not to R-R > > (not needed since incoming requests will arrive via the registration > > path which will of course include Outbound stuff). >=20 >=20 >=20 > a) If the SIP-WS UA runs in a browser then the website developer can > make usage of RFC 5626 so the UA *requests* Outbound usage to its > proxy. >=20 > b) If the SIP-WS UA runs in a desktop and is both a SIP WS Client and > SIP WS Server (and let's assume it has public IP) then it can avoid > requesting Outbound to the proxy. If the proxy does R-R it is because > the proxy wants to be in the patch of the dialog (local policy) and > not because it is required for the dialog to work. >=20 >=20 > Of course, in case b), if the peer does not speak WS and the proxy > does not R-R here we have a problem, but this is *exactly* the same > problem as if the caller was a UA using SCTP in its Contact URI. So > again, this is about local policy in the proxy whether to decide it > does R-R or not. >=20 > I don't find "Record-Route" word in RFC 4168 so I expect there should > be no "MUST" keyword about Record-Route in > draft-ietc-sipcore-sip-websocket. Let me know if I'm wrong. >=20 >=20 >=20 > Summarizing: >=20 > - This is not an issue introduced by this new WS transport. > - The issue is not new. > - There are already standard mechanism to make it to work (the > *client* can request them to the proxy !). > - I see no reason at all to mandate nothing in the sip-ws draft about > this. > - Guidelines section in the draft already covers it in an informative > way. >=20 >=20 >=20 > Hope I am right. >=20 > Best regards. >=20 >=20 >=20 > -- > I=C3=B1aki Baz Castillo > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From brett@broadsoft.com Wed Jul 31 07:25:03 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6384221E80EB for ; Wed, 31 Jul 2013 07:25:02 -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 PIRBb3oKXh0D for ; Wed, 31 Jul 2013 07:24:55 -0700 (PDT) Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.204]) by ietfa.amsl.com (Postfix) with ESMTP id CE2EF11E81B9 for ; Wed, 31 Jul 2013 07:24:47 -0700 (PDT) Received: from CASUMHUB03.citservers.local (172.16.98.219) by Xedge02.citservers.local (172.16.98.248) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 31 Jul 2013 07:24:56 -0700 Received: from MBX08.citservers.local ([fe80::2564:652:8dc8:caae]) by CASUMHUB03.citservers.local ([::1]) with mapi id 14.02.0247.003; Wed, 31 Jul 2013 07:24:56 -0700 From: Brett Tate To: "sipcore@ietf.org" Thread-Topic: [sipcore] SIP and Internationalisation Thread-Index: AQHOTZpIQ0aL+Xy1fUG/uJlsjuC+EZl/VGXQ Date: Wed, 31 Jul 2013 14:24:55 +0000 Message-ID: <576A8B541C219D4E9CEB1DF8C19C7B881A05712D@MBX08.citservers.local> References: <984edebb3d71943ddd13940a3ea1b148@imap.plus.net> <518D1D76.800@nostrum.com> In-Reply-To: <518D1D76.800@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.98.77] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] SIP and Internationalisation X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 14:25:03 -0000 > There are probably some similar issues for password=20 > normalization, although I'm not sure that's as much=20 > of an issue, since passwords, by their nature, are=20 > generated in a more repeatable way than usernames are.=20 > I would expect that people who have spent far more time=20 > than I have thinking about the problem have some ideas here. Although some of their work is experimental, the httpauth working group is = updating RFC 2617 for internationalization and security. http://tools.ietf.org/wg/httpauth/ From stpeter@stpeter.im Wed Jul 31 08:03:27 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19EF321F8947 for ; Wed, 31 Jul 2013 08:03:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.442 X-Spam-Level: X-Spam-Status: No, score=-102.442 tagged_above=-999 required=5 tests=[AWL=0.157, 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 b0HhAhr+BQQz for ; Wed, 31 Jul 2013 08:03:22 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 9816621F8BE6 for ; Wed, 31 Jul 2013 08:03:22 -0700 (PDT) Received: from che-vpn-cluster-2-456.cisco.com (unknown [198.135.0.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D451440046; Wed, 31 Jul 2013 09:05:36 -0600 (MDT) Message-ID: <51F92737.5040404@stpeter.im> Date: Wed, 31 Jul 2013 17:03:19 +0200 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Brett Tate References: <984edebb3d71943ddd13940a3ea1b148@imap.plus.net> <518D1D76.800@nostrum.com> <576A8B541C219D4E9CEB1DF8C19C7B881A05712D@MBX08.citservers.local> In-Reply-To: <576A8B541C219D4E9CEB1DF8C19C7B881A05712D@MBX08.citservers.local> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "sipcore@ietf.org" Subject: Re: [sipcore] SIP and Internationalisation X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 15:03:27 -0000 On 7/31/13 4:24 PM, Brett Tate wrote: >> There are probably some similar issues for password >> normalization, although I'm not sure that's as much >> of an issue, since passwords, by their nature, are >> generated in a more repeatable way than usernames are. >> I would expect that people who have spent far more time >> than I have thinking about the problem have some ideas here. > > Although some of their work is experimental, the httpauth working group is updating RFC 2617 for internationalization and security. > > http://tools.ietf.org/wg/httpauth/ See the username profile we've been defining in the PRECIS WG (which I think the httpauth folks will end up using): http://datatracker.ietf.org/doc/draft-ietf-precis-saslprepbis/ Peter -- Peter Saint-Andre https://stpeter.im/