From nobody Thu May 1 00:57:16 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CE2D1A88B9 for ; Thu, 1 May 2014 00:57:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.601 X-Spam-Level: X-Spam-Status: No, score=-103.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qR5E1qQABVWz for ; Thu, 1 May 2014 00:57:04 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id B66F21A007C for ; Thu, 1 May 2014 00:57:03 -0700 (PDT) X-AuditID: c1b4fb30-f790e6d000001067-4b-5361fe4dfd62 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id F4.10.04199.D4EF1635; Thu, 1 May 2014 09:57:01 +0200 (CEST) Received: from [131.160.126.189] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.38) with Microsoft SMTP Server id 14.3.174.1; Thu, 1 May 2014 09:57:00 +0200 Message-ID: <5361FE4C.8020108@ericsson.com> Date: Thu, 1 May 2014 10:57:00 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Paul Kyzivat , References: <39B5E4D390E9BD4890E2B31079006101126C0371@ESESSMB301.ericsson.se> <53610AAD.1020102@alum.mit.edu> In-Reply-To: <53610AAD.1020102@alum.mit.edu> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrELMWRmVeSWpSXmKPExsUyM+Jvja7vv8Rgg5/9MhYrNhxgtfj6YxOb A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJVxb9tTloKlyhVXb8Y2MH6T6mLk4JAQMJH4 3xLfxcgJZIpJXLi3nq2LkYtDSOAoo0TTvqssEM4aRok7v6ezglTxCmhL9L/uZQKxWQRUJK42 NjKC2GwCFhJbbt1nAbFFBaIkuic9YoeoF5Q4OfMJWFxEwEbi/rQtzCC2sECAxPb1L1hAjhAS yJV4cCEGJMwpoCNx9MtkFojbxCV6GoNAwswCehJTrrYwQtjyEtvfzgGbIgR0zfJnLSwTGAVn IVk2C0nLLCQtCxiZVzGKFqcWJ+WmGxnppRZlJhcX5+fp5aWWbGIEBurBLb8NdjC+fO54iFGA g1GJh7f4S2SwEGtiWXFl7iFGaQ4WJXHeb2fdg4UE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUw Lo7c+3Apj912nZqf/cuC37zhVHi8u1657GBYo0fotQfiHSFlB25cXhr53v7ypu/7DLdsPiB2 Y8WvpXcTbkybMfkPj/ID6RdC6czv5/3c/3BpoouDaonUkyqP1Po/SmczI76peKjP1dBP0xaP eO6y3ldVyfnwpYnr3zOV/mjj4pLgPVbyiO9kghJLcUaioRZzUXEiAFmL2s01AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/rzBnc8rzJp7qBwAQk3VaEhbutao Subject: Re: [sipcore] Precondition and status confirmation requested by offerer X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 07:57:08 -0000 Hi, thanks for bringing this to my attention, Paul. When the original offer/answer exchange (which includes the request for "conf") completes the resources are already reserved. So, the answerer does not need to send an additional offer. It will only need to send one if the "threshold is crossed". That is, since the *initial* status has already all the resources reserved, the threshold is not crossed. If the resources were to be lost at some point, then an offer would naturally need to be sent. Cheers, Gonzalo On 30/04/2014 5:37 PM, Paul Kyzivat wrote: > Ivo, > > I just skimmed this, but before digging into it I think we need to > settle on the proper place to discuss it. My first thought was that it > is not really a sip thing and ought to be discussed in mmusic. But > looking back I see the the drafts leading to 3312 were processed in the > sip wg. Since sipcore and dispatch are the descendents of the sip wg, > maybe sipcore isn't wrong. Normally I would say that mmusic would be the > right place to deal with a SDP issue such as this. But mmusic is fully > engaged in other things now, and this would likely get lost there. So > for the time being I guess we might as well discuss it in sipcore. > > Perhaps we can have an opinion on this by Gonzalo, since he was editor > of 3312 and its update 4032. > > Thanks, > Paul > > On 4/30/14 10:07 AM, Ivo Sedlacek wrote: >> Hello, >> >> can you please help me with a question related to precondition handling >> in RFC3312? >> >> Scenario: >> >> Bob receives an SDP offer O1 containing (not all lines are shown): >> >> m=audio >> >> a=curr:qos local sendrecv >> >> a=curr:qos remote none >> >> a=des:qos mandatory local sendrecv >> >> a=des:qos mandatory remote sendrecv >> >> a=conf:qos remote sendrecv >> >> Bob has needed resources and generates and sends an SDP answer A1 >> containing (not all lines are shown): >> >> m=audio >> >> a=curr:qos local sendrecv >> >> a=curr:qos remote sendrecv >> >> a=des:qos mandatory local sendrecv >> >> a=des:qos mandatory remote sendrecv >> >> Question: >> >> Does "a=conf:qos remote sendrecv" included in SDP offer O1 mandate Bob >> to send an additional SDP offer O2 immediately after sending the SDP >> answer A1? >> >> RFC3312 seems to mandate sending such additional SDP offer since it >> states: >> >> -------------------- >> >> The confirm-status attribute MAY be used in both offers and answers. >> >> This attribute represents a threshold for the resource reservation. >> >> >>When this threshold is reached or surpassed, the user agent MUST >> send >> >> an offer to the peer user agent, reflecting the new current status of >> >> the media line as soon as allowed by the SIP offer/answer >> rules<<. If >> >> this threshold is crossed again (e.g., the network stops providing >> >> resources for the media stream), the user agent MUST send a new offer >> >> as well, as soon as allowed by the SIP offer/answer rules. >> >> >>If a peer has requested confirmation on a particular stream, an >> agent >> >> MUST mark that stream with a flag in its local status table. When >> >> all the rows with this flag have a "Current" value of "yes", the user >> >> agent MUST send a new offer to the peer.<< This offer will >> contain the >> >> current status of resource reservation in the current-status >> >> attributes. Later, if any of the rows with this flag transition to >> >> "No", a new offer MUST be sent as well. >> >> -------------------- >> >> However: >> >> - sending of such additional SDP offer O2 should not be necessary since >> SDP answer A1 indicates that Bob's resources are reserved. >> >> - if order of the SDP answer A1 and the additional SDP offer O2 is >> swapped on the way to the remote UA, then the remote UA rejects the >> UPDATE request carrying the additional offer O2 with 491 (Request >> Pending) response. >> >> The situation above occurs with third party call control. I am aware >> that in regular two party calls, it should not occur. >> >> Kind regards >> >> Ivo Sedlacek >> >> >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > From nobody Tue May 6 04:21:07 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A49331A01C7 for ; Tue, 6 May 2014 04:21:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y2O4F6qpcPKl for ; Tue, 6 May 2014 04:21:04 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1ECC61A02A5 for ; Tue, 6 May 2014 04:21:03 -0700 (PDT) X-AuditID: c1b4fb2d-f79036d00000126a-db-5368c59b3c73 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id D7.ED.04714.B95C8635; Tue, 6 May 2014 13:20:59 +0200 (CEST) Received: from ESESSMB205.ericsson.se ([169.254.5.151]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0174.001; Tue, 6 May 2014 13:20:58 +0200 From: Taisto Qvist To: "sipcore@ietf.org" Thread-Topic: NAPTR priorities vs rfc3261s rule of 1300 bytes. Thread-Index: Ac9pHP9cp8lC8RabRQm+miRqkj+W3g== Date: Tue, 6 May 2014 11:20:58 +0000 Message-ID: <9664C7EC07DF664E8FDC68CEC4AB35C916509751@ESESSMB205.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrALMWRmVeSWpSXmKPExsUyM+Jvje7soxnBBodPmVp8/bGJzYHRY8mS n0wBjFFcNimpOZllqUX6dglcGdtWvmEvOM5d8XnpIuYGxm7OLkZODgkBE4n+XxOZIWwxiQv3 1rN1MXJxCAkcZZRo7bvEDOEsZpTYO20nE0gVm4CexNM9z8A6RAQ0JZZ/28oOYgsLWEr0nupl g4jbSSxsWsYOYetJdD25ywhiswioSEz4cAFsDq+Ar8SeOa/A6hmBNn8/tQYsziwgLnHryXwm iIsEJJbsOQ91najEy8f/WCFsRYmPr/YxQtTrSCzY/YkNwtaWWLbwNTPEfEGJkzOfsExgFJ6F ZOwsJC2zkLTMQtKygJFlFaNocWpxcW66kbFealFmcnFxfp5eXmrJJkZgkB/c8lt3B+Pq146H GAU4GJV4ePe0ZgQLsSaWFVfmHmKU5mBREudtu+sdLCSQnliSmp2aWpBaFF9UmpNafIiRiYNT qoGRfUvzqWjrx18cG3I5fi73MJVM/XnP/9CztKcaYq9v8nOsK2aa+O5z9LK3fwIS9jEYPog4 x/l3u1tw+vmtlRfNRdesTxHjEBOLUZHuPGa8/n6oUfC09B4JsebiXd/XPeapbGbOlsy5svHs 1DbvzP/KqSvbMpfXbfZ5dP3mtBjethPP2VoyN2spsRRnJBpqMRcVJwIAigI8xVMCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/ii_9r6m4n01_Tsf8cpkrDs8p-ic Subject: [sipcore] NAPTR priorities vs rfc3261s rule of 1300 bytes. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 11:21:05 -0000 Hi,=20 I have been figure out how to interpret the MUST rule of rfc3261's chapter = 18.1.1. that says: If a request is within 200 bytes of the path MTU, or if it is larger than 1300 bytes and the path MTU is unknown, the request MUST be sent using an RFC 2914 [43] congestion controlled transport protocol, such as TCP. in relation to DNS NAPTR priorities for selecting transport protocol. The initial paragraph(just preceding the above rule) of 18.1.1 says that: "The user of the transport layer passes the client transport the request= ,=20 an IP address, port, transport, and possibly TTL for multicast destinati= ons." Which to me implies that DNS lookup according to rfc3263 has been performed= , and that the rule above will/can OVERRIDE the NAPTR priorities? Reading rfc3263 sometimes uses the phrase:=20 However, another transport, such as TCP, MAY be used if the guidelines o= f=20 SIP mandate it for this particular request. =20 However, only directly in connection with URI's containing IP and/or port, = or scenarios where NAPTR does not exist. So, in a scenario where NAPTR *are* configured(for instance with UDP as hig= hest priority), are you supposed to ignore the MUST rule in 18.1.1 above?? I am definitely in need of clarification, since 18.1.1 doesn't refer at all= to the procedures of rfc3263 and how they can impact this rule of protocol= selection. Best Regards Taisto Qvist From nobody Tue May 6 05:13:21 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 582181A02A1 for ; Tue, 6 May 2014 05:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2yPWxCPyKXiB for ; Tue, 6 May 2014 05:13:18 -0700 (PDT) Received: from mail-ve0-f171.google.com (mail-ve0-f171.google.com [209.85.128.171]) by ietfa.amsl.com (Postfix) with ESMTP id BB68C1A020A for ; Tue, 6 May 2014 05:13:18 -0700 (PDT) Received: by mail-ve0-f171.google.com with SMTP id oz11so2702062veb.2 for ; Tue, 06 May 2014 05:13:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:content-type; bh=8N+ColEoYUDMByF7aR1Fx8W9zzvZCtQvcwNH9D8Tv2U=; b=M9JcNo2ZqWJWjkL+CfENGbu9ZTKLJogASIuqyLZQEKBNIwAyUAs/z3YmmmF3AHQebC 05ts7baVhdFAS/37d3VuK02j4yxeLtqfEKSymfbN7R0bNWdodk2U4HjzEUhrNNzFTmhm uF6aRoC7aRj5BqxlCQGZ/nVgR5coo93NpsfNq4hau/nk77pa80Bdlo9UI1NHf0rfDDSk N3QR8oM8VTkQHGyLtTJoqPc9on86PRJn9DxWjxQNcjV9QPaVD1EXENr4qgOpMcETNccz unVdDhkrHcp03vEo3j684uRqfHBZ3G0wiLjXt+CBXqBg+GgDaShCJVCvPLyGyPJIljWZ QB7A== X-Gm-Message-State: ALoCoQncEmQsyJvNHftwbC8m3Ve4ucWkPAVeaMfNrrYaf+DbjSukQcOpyCzZ9Ulh94Weml0VkKuWDn15D8G2BpwY+tr/zg+uMQ== X-Received: by 10.58.38.40 with SMTP id d8mr184298vek.61.1399378394664; Tue, 06 May 2014 05:13:14 -0700 (PDT) From: Brett Tate References: <9664C7EC07DF664E8FDC68CEC4AB35C916509751@ESESSMB205.ericsson.se> In-Reply-To: <9664C7EC07DF664E8FDC68CEC4AB35C916509751@ESESSMB205.ericsson.se> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac9pHP9cp8lC8RabRQm+miRqkj+W3gAAScAw Date: Tue, 6 May 2014 08:13:13 -0400 Message-ID: To: Taisto Qvist , sipcore@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/GIuigXxfnGrx5OEQUoazec2I0XQ Subject: Re: [sipcore] NAPTR priorities vs rfc3261s rule of 1300 bytes. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 12:13:20 -0000 > Which to me implies that DNS lookup according to rfc3263 > has been performed, and that the rule above will/can > OVERRIDE the NAPTR priorities? Correct; the size rule overrides the already determined transport for the request (unless CANCEL or non-2xx ACK). > So, in a scenario where NAPTR *are* configured (for > instance with UDP as highest priority), are you supposed > to ignore the MUST rule in 18.1.1 above?? No. -- See why you should attend BroadSoft Connections 2014 This email is intended solely for the person or entity to which it is addressed and may contain confidential and/or privileged information. If you are not the intended recipient and have received this email in error, please notify BroadSoft, Inc. immediately by replying to this message, and destroy all copies of this message, along with any attachment, prior to reading, distributing or copying it. From nobody Tue May 6 06:48:08 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9D561A030B for ; Tue, 6 May 2014 06:48:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SSJrGbIVCbC9 for ; Tue, 6 May 2014 06:48:04 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id 7AB9D1A00DF for ; Tue, 6 May 2014 06:48:04 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta09.westchester.pa.mail.comcast.net with comcast id yc7v1n0051ZXKqc59do0FN; Tue, 06 May 2014 13:48:00 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta21.westchester.pa.mail.comcast.net with comcast id ydo01n0071KKtkw3hdo0ol; Tue, 06 May 2014 13:48:00 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s46DlxoE008389; Tue, 6 May 2014 09:47:59 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s46Dlxbd008388; Tue, 6 May 2014 09:47:59 -0400 Date: Tue, 6 May 2014 09:47:59 -0400 Message-Id: <201405061347.s46Dlxbd008388@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Taisto Qvist In-reply-to: <9664C7EC07DF664E8FDC68CEC4AB35C916509751@ESESSMB205.ericsson.se> (taisto.qvist@ericsson.com) References: <9664C7EC07DF664E8FDC68CEC4AB35C916509751@ESESSMB205.ericsson.se> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1399384080; bh=7ga3x1r9G0FyU2XTJHMHxpoahkkpggrLgXkCWmQh3sA=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=FRBnn0rdEbMypE/AH7DvhHkUmoSHu40Bo80GMfaJZY3z7lIMENLrJ9NEhQIeb3bNK d6Rq5ZJ2Zt2ssYPICjAsPg6d0bAif7L6yNESWS3NbrgLtQu3n+yTWxp6vN9v628n39 T8tpsrfBrzKrBJ2NhhU5R0jP3r3SNFOWan1NMPhM01xS6qYnBaMPX0oVKcVWLXMPy1 jfIHaoYvFUaKOpsbdeBxzZqRLH/oVa5Jb1Hujg1HL1UUByWn9CN0kQGyRxtYyaBMTc W2V/Y/IxWor/pS0egYcFdY6VwexfBj5OHZ36IuQob4IID63MoqgmdLVkrQsdtwT2qI 1SkfphvyBdWZg== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/YMokM_x5HE5504KynyzfzvepQ3c Cc: sipcore@ietf.org Subject: Re: [sipcore] NAPTR priorities vs rfc3261s rule of 1300 bytes. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 13:48:05 -0000 > From: Taisto Qvist > > I have been figure out how to interpret the MUST rule of rfc3261's > chapter 18.1.1. that says: > > If a request is within 200 bytes of the path MTU, or if it is larger > than 1300 bytes and the path MTU is unknown, the request MUST be sent > using an RFC 2914 [43] congestion controlled transport protocol, such > as TCP. > > in relation to DNS NAPTR priorities for selecting transport protocol. My interpretation of the rules is that the DNS lookup process generates a prioritized list of addresses/ports/transports. This list is then filtered depending on the context. If the rule in 18.1.1 is triggered, all the elements of the list that have transport=UDP are removed. If not, and if a transport parameter was specified, elements that do not match the transport parameter are removed. (There is further filtering if the URI is sips:, but I don't know them.) Dale From nobody Tue May 6 07:08:44 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC51B1A0329 for ; Tue, 6 May 2014 07:08:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JD7oHUzqDn8P for ; Tue, 6 May 2014 07:08:41 -0700 (PDT) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id 353DC1A029E for ; Tue, 6 May 2014 07:08:40 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s46E8O4Q026622 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 May 2014 09:08:25 -0500 (CDT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s46E8LiD006973 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 6 May 2014 16:08:23 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.4]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Tue, 6 May 2014 16:08:19 +0200 From: "DRAGE, Keith (Keith)" To: "Dale R. Worley" , Taisto Qvist Thread-Topic: [sipcore] NAPTR priorities vs rfc3261s rule of 1300 bytes. Thread-Index: Ac9pHP9cp8lC8RabRQm+miRqkj+W3gAFNIeRAACSQHA= Date: Tue, 6 May 2014 14:08:18 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B19603E@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <9664C7EC07DF664E8FDC68CEC4AB35C916509751@ESESSMB205.ericsson.se> <201405061347.s46Dlxbd008388@hobgoblin.ariadne.com> In-Reply-To: <201405061347.s46Dlxbd008388@hobgoblin.ariadne.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/cZeAn19bkftCU-xi5J_ykKnXp4s Cc: "sipcore@ietf.org" Subject: Re: [sipcore] NAPTR priorities vs rfc3261s rule of 1300 bytes. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 14:08:43 -0000 Agree - it is still possible to take information from the NAPTR record and = comply with the RFC 3261 requirement, e.g. in selecting TCP over SCTP. Regards Keith=20 > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of=20 > Dale R. Worley > Sent: 06 May 2014 14:48 > To: Taisto Qvist > Cc: sipcore@ietf.org > Subject: Re: [sipcore] NAPTR priorities vs rfc3261s rule of=20 > 1300 bytes. >=20 > > From: Taisto Qvist > >=20 > > I have been figure out how to interpret the MUST rule of rfc3261's=20 > > chapter 18.1.1. that says: > >=20 > > If a request is within 200 bytes of the path MTU, or if=20 > it is larger > > than 1300 bytes and the path MTU is unknown, the request=20 > MUST be sent > > using an RFC 2914 [43] congestion controlled transport=20 > protocol, such > > as TCP. > >=20 > > in relation to DNS NAPTR priorities for selecting transport=20 > protocol. >=20 > My interpretation of the rules is that the DNS lookup process=20 > generates a prioritized list of addresses/ports/transports. =20 > This list is then filtered depending on the context. If the=20 > rule in 18.1.1 is triggered, all the elements of the list=20 > that have transport=3DUDP are removed. If not, and if a=20 > transport parameter was specified, elements that do not match=20 > the transport parameter are removed. (There is further=20 > filtering if the URI is sips:, but I don't know them.) >=20 > Dale >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From nobody Tue May 6 07:40:55 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 309F21A0330 for ; Tue, 6 May 2014 07:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZnuoVNK7W34E for ; Tue, 6 May 2014 07:40:52 -0700 (PDT) Received: from mail-vc0-f174.google.com (mail-vc0-f174.google.com [209.85.220.174]) by ietfa.amsl.com (Postfix) with ESMTP id 55B9F1A008D for ; Tue, 6 May 2014 07:40:52 -0700 (PDT) Received: by mail-vc0-f174.google.com with SMTP id ib6so1054884vcb.19 for ; Tue, 06 May 2014 07:40:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:content-type; bh=0j2Sm/WtuQW43oAGiF9tvXjB3nPCInavx2hIYzn5sTw=; b=OyeNKhlOV0vIJ7V/RPl+mJy2ehBKPm2/OTDYW4V+vij5MJlLodwOrbtnJCM4n6yGu6 im/9gUpyxXi8h5IggKZfOcPSOIuoh3yTnLNa/yKHT7Qrh95EFslnZFVvWVehrBaD/8qC r+vetxMQhYC0DqlyIR7w4XyxseEuiMo2jV62ht/2RSPt6RMFVU/NMEEe4wCnZ6VIGeqQ 8VQC9vl3jTg/d92CmaKFgPPeUGhcUngwd72NWXE44FeTzAnBiL4lrtZYA+q1lnnIuM7S rVX0V2iV5jaPDMbNcSM7I6RB2YV580Q/6TyetryNT2uCDKcfTaMVriHLc12Oott6Y8DH aorQ== X-Gm-Message-State: ALoCoQmmqQUnMQlRiQUet+jPyTiksre+bcVVFaBH23F1ti8lHYkw0YiWe3jyYkshER9Kb2egfYQ0IVrVTuXxu9jUt+Oz1vVcUQ== X-Received: by 10.52.78.231 with SMTP id e7mr6816339vdx.28.1399387248352; Tue, 06 May 2014 07:40:48 -0700 (PDT) From: Brett Tate References: <9664C7EC07DF664E8FDC68CEC4AB35C916509751@ESESSMB205.ericsson.se> <201405061347.s46Dlxbd008388@hobgoblin.ariadne.com> <949EF20990823C4C85C18D59AA11AD8B19603E@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B19603E@FR712WXCHMBA11.zeu.alcatel-lucent.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac9pHP9cp8lC8RabRQm+miRqkj+W3gAFNIeRAACSQHAAADduwA== Date: Tue, 6 May 2014 10:40:46 -0400 Message-ID: <51f5634ce255964c695abb68ef2e9d76@mail.gmail.com> To: "DRAGE, Keith (Keith)" , "Dale R. Worley" , Taisto Qvist , sipcore@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/T7wtkPD9q9T86waZCNLbagkOuBM Subject: Re: [sipcore] NAPTR priorities vs rfc3261s rule of 1300 bytes. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 14:40:54 -0000 Hi, I disagree with both interpretations. My interpretation is that the RFC 3263 NAPTR/SRV process only selects a single transport type; UDP was selected within this situation. The RFC 3261 size rule overrides the selected transport type (but still uses the address and port associated with UDP) and provides a fallback to the selected transport type. This is the reason for the following RFC 3261 section 18.2.1 snippet: "For any port and interface that a server listens on for UDP, it MUST listen on that same port and interface for TCP. This is because a message may need to be sent using TCP, rather than UDP, if it is too large." > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of DRAGE, > Keith (Keith) > Sent: Tuesday, May 06, 2014 10:08 AM > To: Dale R. Worley; Taisto Qvist > Cc: sipcore@ietf.org > Subject: Re: [sipcore] NAPTR priorities vs rfc3261s rule of 1300 bytes. > > Agree - it is still possible to take information from the NAPTR record > and comply with the RFC 3261 requirement, e.g. in selecting TCP over > SCTP. > > Regards > > Keith > > > -----Original Message----- > > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of > > Dale R. Worley > > Sent: 06 May 2014 14:48 > > To: Taisto Qvist > > Cc: sipcore@ietf.org > > Subject: Re: [sipcore] NAPTR priorities vs rfc3261s rule of > > 1300 bytes. > > > > > From: Taisto Qvist > > > > > > I have been figure out how to interpret the MUST rule of rfc3261's > > > chapter 18.1.1. that says: > > > > > > If a request is within 200 bytes of the path MTU, or if > > it is larger > > > than 1300 bytes and the path MTU is unknown, the request > > MUST be sent > > > using an RFC 2914 [43] congestion controlled transport > > protocol, such > > > as TCP. > > > > > > in relation to DNS NAPTR priorities for selecting transport > > protocol. > > > > My interpretation of the rules is that the DNS lookup process > > generates a prioritized list of addresses/ports/transports. > > This list is then filtered depending on the context. If the > > rule in 18.1.1 is triggered, all the elements of the list > > that have transport=UDP are removed. If not, and if a > > transport parameter was specified, elements that do not match > > the transport parameter are removed. (There is further > > filtering if the URI is sips:, but I don't know them.) > > > > Dale > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore -- See why you should attend BroadSoft Connections 2014 This email is intended solely for the person or entity to which it is addressed and may contain confidential and/or privileged information. If you are not the intended recipient and have received this email in error, please notify BroadSoft, Inc. immediately by replying to this message, and destroy all copies of this message, along with any attachment, prior to reading, distributing or copying it. From nobody Tue May 6 08:27:52 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0A041A0779 for ; Tue, 6 May 2014 08:27:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7s41AbQ6lJYm for ; Tue, 6 May 2014 08:27:51 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id F33A31A00A2 for ; Tue, 6 May 2014 08:27:50 -0700 (PDT) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by QMTA11.westchester.pa.mail.comcast.net with comcast id ybqB1n0030cZkys5BfTnqq; Tue, 06 May 2014 15:27:47 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta10.westchester.pa.mail.comcast.net with comcast id yfTm1n0123ZTu2S3WfTn8u; Tue, 06 May 2014 15:27:47 +0000 Message-ID: <5368FF72.8020900@alum.mit.edu> Date: Tue, 06 May 2014 11:27:46 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: sipcore@ietf.org References: <9664C7EC07DF664E8FDC68CEC4AB35C916509751@ESESSMB205.ericsson.se> <201405061347.s46Dlxbd008388@hobgoblin.ariadne.com> In-Reply-To: <201405061347.s46Dlxbd008388@hobgoblin.ariadne.com> 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=q20140121; t=1399390067; bh=tSpnaRqGcLQFEcIqPAb/Q6DEpY9HzpQbX34NsidIx74=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=amX9wsACCJC7Cpdz4bjHfy9zPGRWPpG1JAM9jixXh43j1qW9jKheDQiwx+3R+6OJ5 F8uHAdB81zUhnv5SZcaQbCs9Z1nXAfh3Rn8yQy76Eb+KSgFJZLDPD9OspAnB9fwlPq v23TLNpa7MOCZieLtN7zKt/YQ8FGrO0B7BENRT81ytSeM8tMLPhPzjDKO6zHXscXW0 uJCocO1GiO8F7kLhoUELbhD2RPdO5XDsGLTu27+8COmLJd9iZwwi79ag6Lxe756vu6 Ncm6U0zrBwVJaGu/QNVCERJ+2xThMutMHYsCvdSCs5ZCdp2te7URGgm6LnGNEtGtmJ clF6q5+0FDQCA== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/vKqrHcPOl2Yq_QKVEA5W7bS7nJA Subject: Re: [sipcore] NAPTR priorities vs rfc3261s rule of 1300 bytes. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 15:27:52 -0000 On 5/6/14 9:47 AM, Dale R. Worley wrote: >> From: Taisto Qvist >> >> I have been figure out how to interpret the MUST rule of rfc3261's >> chapter 18.1.1. that says: >> >> If a request is within 200 bytes of the path MTU, or if it is larger >> than 1300 bytes and the path MTU is unknown, the request MUST be sent >> using an RFC 2914 [43] congestion controlled transport protocol, such >> as TCP. >> >> in relation to DNS NAPTR priorities for selecting transport protocol. > > My interpretation of the rules is that the DNS lookup process > generates a prioritized list of addresses/ports/transports. This list > is then filtered depending on the context. If the rule in 18.1.1 is > triggered, all the elements of the list that have transport=UDP are > removed. If not, and if a transport parameter was specified, elements > that do not match the transport parameter are removed. (There is > further filtering if the URI is sips:, but I don't know them.) This is consistent with my feeling of how it *ought* to work. Whether that is what was *intended* is a slightly different question, and one I don't know the answer to. Thanks, Paul From nobody Tue May 6 23:52:09 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2D731A03B3 for ; Tue, 6 May 2014 23:52:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01lVtd4SjJ1o for ; Tue, 6 May 2014 23:52:06 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 208ED1A024E for ; Tue, 6 May 2014 23:52:05 -0700 (PDT) X-AuditID: c1b4fb2d-f79036d00000126a-f0-5369d8112c19 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 4B.7F.04714.118D9635; Wed, 7 May 2014 08:52:01 +0200 (CEST) Received: from ESESSMB205.ericsson.se ([169.254.5.151]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0174.001; Wed, 7 May 2014 08:52:00 +0200 From: Taisto Qvist To: "DRAGE, Keith (Keith)" , "Dale R. Worley" Thread-Topic: [sipcore] NAPTR priorities vs rfc3261s rule of 1300 bytes. Thread-Index: Ac9pHP9cp8lC8RabRQm+miRqkj+W3gAFMy6H///kIwD//sa1MA== Date: Wed, 7 May 2014 06:52:00 +0000 Message-ID: <9664C7EC07DF664E8FDC68CEC4AB35C916509B1C@ESESSMB205.ericsson.se> References: <9664C7EC07DF664E8FDC68CEC4AB35C916509751@ESESSMB205.ericsson.se> <201405061347.s46Dlxbd008388@hobgoblin.ariadne.com> <949EF20990823C4C85C18D59AA11AD8B19603E@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B19603E@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyM+Jvja7gjcxgg09/JSyeNp5ltPj6YxOb xcsTZQ7MHq3P9rJ6TN7/ldljyZKfTAHMUVw2Kak5mWWpRfp2CVwZP96+ZClYKVhxd+YJ5gbG L7xdjJwcEgImEjdX3GGEsMUkLtxbz9bFyMUhJHCUUeLVod/sEM5iRonuuTNZQarYBPQknu55 xgxiiwikSLy9PQUsziygKfFo514mEFtYwF3i+P/fLBA1HhJXf60HqucAsp0kpnaEgIRZBFQk Vp68CzaGV8BX4uSp9SwQu64wStx5eR/sIk6BaIlHsy+zg9iMQNd9P7WGCWKXuMStJ/OZIK4W kFiy5zwzhC0q8fLxP1YIW1Hi46t9jBD1OhILdn9ig7C1JZYtfA21WFDi5MwnLBMYxWYhGTsL ScssJC2zkLQsYGRZxShanFpcnJtuZKyXWpSZXFycn6eXl1qyiREYUwe3/Nbdwbj6teMhRgEO RiUe3gevMoKFWBPLiitzDzFKc7AoifO23fUOFhJITyxJzU5NLUgtii8qzUktPsTIxMEp1cDo sePI82VdVj9zXeus6h7pp61dmbG/48c796UNb2wW1RT7pO95nHnyd4OYcPnn51kalYfWeQYI n5rf8XfbtjrVhsnPvTSnrr55+NKBWYL8tlWqjUc2CN375epwmeHaLYfqeDNp1xjHkkPBCz7x LH96992qoo26f21UnOaGH32YsHtadEDYrjnlSizFGYmGWsxFxYkAJihPoooCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/AqqUw-43tIrPIBM5MCdlgoSklAk Cc: "sipcore@ietf.org" Subject: Re: [sipcore] NAPTR priorities vs rfc3261s rule of 1300 bytes. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 06:52:08 -0000 Thanks Keith, but I was more thinking about the situation that NAPTR config= uration prioritizes UDP, and then the message is larger than 1300 bytes. In this case it I don't know which rule is more important? When NAPTR confi= g "disagrees" with rfc3261, which takes precedence? Regards Taisto -----Original Message----- From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com]=20 Sent: den 6 maj 2014 16:08 To: Dale R. Worley; Taisto Qvist Cc: sipcore@ietf.org Subject: RE: [sipcore] NAPTR priorities vs rfc3261s rule of 1300 bytes. Agree - it is still possible to take information from the NAPTR record and = comply with the RFC 3261 requirement, e.g. in selecting TCP over SCTP. Regards Keith=20 > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Dale R.=20 > Worley > Sent: 06 May 2014 14:48 > To: Taisto Qvist > Cc: sipcore@ietf.org > Subject: Re: [sipcore] NAPTR priorities vs rfc3261s rule of > 1300 bytes. >=20 > > From: Taisto Qvist > >=20 > > I have been figure out how to interpret the MUST rule of rfc3261's=20 > > chapter 18.1.1. that says: > >=20 > > If a request is within 200 bytes of the path MTU, or if > it is larger > > than 1300 bytes and the path MTU is unknown, the request > MUST be sent > > using an RFC 2914 [43] congestion controlled transport > protocol, such > > as TCP. > >=20 > > in relation to DNS NAPTR priorities for selecting transport > protocol. >=20 > My interpretation of the rules is that the DNS lookup process=20 > generates a prioritized list of addresses/ports/transports. > This list is then filtered depending on the context. If the rule in=20 > 18.1.1 is triggered, all the elements of the list that have=20 > transport=3DUDP are removed. If not, and if a transport parameter was=20 > specified, elements that do not match the transport parameter are=20 > removed. (There is further filtering if the URI is sips:, but I don't=20 > know them.) >=20 > Dale >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From nobody Wed May 7 00:15:05 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7A4C1A0678 for ; Wed, 7 May 2014 00:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y8t7J-Iz7T5i for ; Wed, 7 May 2014 00:15:01 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) by ietfa.amsl.com (Postfix) with ESMTP id D5EA81A0674 for ; Wed, 7 May 2014 00:15:00 -0700 (PDT) X-AuditID: c1b4fb3a-f79a86d0000010e9-8e-5369dd7017d7 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 9B.6B.04329.07DD9635; Wed, 7 May 2014 09:14:56 +0200 (CEST) Received: from ESESSMB205.ericsson.se ([169.254.5.151]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0174.001; Wed, 7 May 2014 09:14:54 +0200 From: Taisto Qvist To: "Dale R. Worley" Thread-Topic: [sipcore] NAPTR priorities vs rfc3261s rule of 1300 bytes. Thread-Index: Ac9pHP9cp8lC8RabRQm+miRqkj+W3gAFMy6HACQGq7A= Date: Wed, 7 May 2014 07:14:55 +0000 Message-ID: <9664C7EC07DF664E8FDC68CEC4AB35C916509B6A@ESESSMB205.ericsson.se> References: <9664C7EC07DF664E8FDC68CEC4AB35C916509751@ESESSMB205.ericsson.se> <201405061347.s46Dlxbd008388@hobgoblin.ariadne.com> In-Reply-To: <201405061347.s46Dlxbd008388@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyM+JvjW7B3cxgg6udQhZff2xis3h5osyB yWPy/q/MHkuW/GQKYIrisklJzcksSy3St0vgymg4c4W14JRgxeEbT9gbGL/xdjFyckgImEg8 3PaaHcIWk7hwbz1bFyMXh5DAUUaJaScXsEA4ixkluo//YAGpYhPQk3i65xlzFyMHh4iApkTH ghyQMDOQ+WjnXiYQW1jAXeL4/99g5SICHhJXf61nhrCtJKYvn8oKYrMIqEg8bFoDFucV8JW4 +HkeWK+QQDOjxOJ9tiA2p4CDxOnlh8HijEDHfT+1hglil7jErSfzmSCOFpBYsuc8M4QtKvHy 8T9WCFtR4uOrfYwQ9ToSC3Z/YoOwtSWWLXwNtVdQ4uTMJywTGMVmIRk7C0nLLCQts5C0LGBk WcUoWpxaXJybbmSkl1qUmVxcnJ+nl5dasokRGD0Ht/y22sF48LnjIUYBDkYlHt4HrzKChVgT y4orcw8xSnOwKInzTlrkHiwkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBkVOXt3btnpi3Sxhs Ut5J6u1y+FM1/5pKaHF4w9zqDxvqP6rc8yvtni1s2qHWtPCo0w3eb5sKQ6TZT2Ud8hJdeno2 w+wzMxat6evlW3mbW9aOgWOvR13k35vRXXzO+/5d3LxxEeOuBKePljfyxKo55F7YmbsvyOVu llR9uj9xhZtmcPzqhdOWKbEUZyQaajEXFScCAGOHACB/AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/dCkg07ACx1Pgs9ML5xfgEULpFoA Cc: "sipcore@ietf.org" Subject: Re: [sipcore] NAPTR priorities vs rfc3261s rule of 1300 bytes. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 07:15:03 -0000 Hi,=20 This is somewhat similar to what my interpretation has been before as well.= But after some discussions with Brett on sip-implementors, I've realized = that I've missed the rules of 2915/NAPTR Order values, which quite(?) clear= ly says that once you've selected a NAPTR RR with a specific Order value, t= hat *it*.=20 Low numbers are processed before high numbers, and once a NAPTR is found whose rule "matches" the target, the client MUST NOT consider any NAPTRs with a higher value for order.... So at least in the case of different Order values for the different protoco= ls, you should only use the first match. If the Order values are the same t= hough.....? But still...it feels like the two algorithms/rules collide a bit, or are at= least in need of clarification. Especially that rfc 3263, chapter 4.1 only= refers to the size-rule as a *MAY* in scenarios where we don't have or use= NAPTR.=20 A MAY requirement, referring to a MUST requirement. Regards Taisto Qvist -----Original Message----- From: Dale R. Worley [mailto:worley@ariadne.com]=20 Sent: den 6 maj 2014 15:48 To: Taisto Qvist Cc: sipcore@ietf.org Subject: Re: [sipcore] NAPTR priorities vs rfc3261s rule of 1300 bytes. > From: Taisto Qvist >=20 > I have been figure out how to interpret the MUST rule of rfc3261's=20 > chapter 18.1.1. that says: >=20 > If a request is within 200 bytes of the path MTU, or if it is larger > than 1300 bytes and the path MTU is unknown, the request MUST be sent > using an RFC 2914 [43] congestion controlled transport protocol, such > as TCP. >=20 > in relation to DNS NAPTR priorities for selecting transport protocol. My interpretation of the rules is that the DNS lookup process generates a p= rioritized list of addresses/ports/transports. This list is then filtered = depending on the context. If the rule in 18.1.1 is triggered, all the elem= ents of the list that have transport=3DUDP are removed. If not, and if a t= ransport parameter was specified, elements that do not match the transport = parameter are removed. (There is further filtering if the URI is sips:, bu= t I don't know them.) Dale From nobody Wed May 7 04:09:05 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 290C71A06FF for ; Wed, 7 May 2014 04:09:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n_ubI12VFzgH for ; Wed, 7 May 2014 04:09:00 -0700 (PDT) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 0A0F41A06FE for ; Wed, 7 May 2014 04:08:59 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s47B8mbN017769 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 May 2014 06:08:50 -0500 (CDT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s47B8m9j003738 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 May 2014 13:08:48 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.4]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Wed, 7 May 2014 13:08:48 +0200 From: "DRAGE, Keith (Keith)" To: Taisto Qvist , "Dale R. Worley" Thread-Topic: [sipcore] NAPTR priorities vs rfc3261s rule of 1300 bytes. Thread-Index: Ac9pHP9cp8lC8RabRQm+miRqkj+W3gAFMy6H///kIwD//sa1MP/9S6qA Date: Wed, 7 May 2014 11:08:47 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B196A4F@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <9664C7EC07DF664E8FDC68CEC4AB35C916509751@ESESSMB205.ericsson.se> <201405061347.s46Dlxbd008388@hobgoblin.ariadne.com> <949EF20990823C4C85C18D59AA11AD8B19603E@FR712WXCHMBA11.zeu.alcatel-lucent.com> <9664C7EC07DF664E8FDC68CEC4AB35C916509B1C@ESESSMB205.ericsson.se> In-Reply-To: <9664C7EC07DF664E8FDC68CEC4AB35C916509B1C@ESESSMB205.ericsson.se> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/gcszHB7Vk-svm3-GMt55AuT8rjg Cc: "sipcore@ietf.org" Subject: Re: [sipcore] NAPTR priorities vs rfc3261s rule of 1300 bytes. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 11:09:02 -0000 Exactly as others have indicated. If the length exceeds the limit then the = absolute RFC 3261 requirement (MUST) applies, i.e. not use UDP.=20 I am aware of implementations that can be set to override this, but they ar= e non-conformant to the RFC. Regards Keith > -----Original Message----- > From: Taisto Qvist [mailto:taisto.qvist@ericsson.com]=20 > Sent: 07 May 2014 07:52 > To: DRAGE, Keith (Keith); Dale R. Worley > Cc: sipcore@ietf.org > Subject: RE: [sipcore] NAPTR priorities vs rfc3261s rule of=20 > 1300 bytes. >=20 > Thanks Keith, but I was more thinking about the situation=20 > that NAPTR configuration prioritizes UDP, and then the=20 > message is larger than 1300 bytes. >=20 > In this case it I don't know which rule is more important?=20 > When NAPTR config "disagrees" with rfc3261, which takes precedence? >=20 > Regards > Taisto >=20 > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com] > Sent: den 6 maj 2014 16:08 > To: Dale R. Worley; Taisto Qvist > Cc: sipcore@ietf.org > Subject: RE: [sipcore] NAPTR priorities vs rfc3261s rule of=20 > 1300 bytes. >=20 > Agree - it is still possible to take information from the=20 > NAPTR record and comply with the RFC 3261 requirement, e.g.=20 > in selecting TCP over SCTP. >=20 > Regards >=20 > Keith=20 >=20 > > -----Original Message----- > > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf=20 > Of Dale R.=20 > > Worley > > Sent: 06 May 2014 14:48 > > To: Taisto Qvist > > Cc: sipcore@ietf.org > > Subject: Re: [sipcore] NAPTR priorities vs rfc3261s rule of 1300=20 > > bytes. > >=20 > > > From: Taisto Qvist > > >=20 > > > I have been figure out how to interpret the MUST rule of=20 > rfc3261's=20 > > > chapter 18.1.1. that says: > > >=20 > > > If a request is within 200 bytes of the path MTU, or if > > it is larger > > > than 1300 bytes and the path MTU is unknown, the request > > MUST be sent > > > using an RFC 2914 [43] congestion controlled transport > > protocol, such > > > as TCP. > > >=20 > > > in relation to DNS NAPTR priorities for selecting transport > > protocol. > >=20 > > My interpretation of the rules is that the DNS lookup process=20 > > generates a prioritized list of addresses/ports/transports. > > This list is then filtered depending on the context. If the rule in > > 18.1.1 is triggered, all the elements of the list that have=20 > > transport=3DUDP are removed. If not, and if a transport=20 > parameter was=20 > > specified, elements that do not match the transport parameter are=20 > > removed. (There is further filtering if the URI is sips:,=20 > but I don't=20 > > know them.) > >=20 > > Dale > >=20 > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > >=20 > = From nobody Thu May 15 02:35:57 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1ADF1A0471 for ; Thu, 15 May 2014 02:35:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.221 X-Spam-Level: X-Spam-Status: No, score=0.221 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DdPLZN1ZYqP4 for ; Thu, 15 May 2014 02:35:54 -0700 (PDT) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 659A01A0463 for ; Thu, 15 May 2014 02:35:54 -0700 (PDT) Received: by mail-qc0-f182.google.com with SMTP id e16so1296797qcx.41 for ; Thu, 15 May 2014 02:35:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-type:content-transfer-encoding; bh=4LEvSKhcwV1wB1NWa+5n/V7iJCxT4aCHuxYQymI5hB8=; b=bvmlZRgxGurteJl+UhU0VQpBnB+Y17YIiwtdSYduA8gb4bDT6iZPZ9C2d2kUQsNQv0 +7SaKzJkzGFBqe9Tpyl7GJhBVguy5+m+Uhjk5AM8z38YWm4JfXSOK/PVmLHb77Em6lJ1 N4h1SeHYXWF97M6LP/2XYAlpCwUWIAEXHLv85Y7m1McKtOSNcw/iazy/hYMGrnLnd750 zYhxdNrp2QvpQBIkffsPOknIvGrA8Xar07UPbyZiOtLvWKtMn6A+ri0wy4O0BY9HVPvp XXHN95soJmkqsTIYRMWX11DAsm2+8K/ZUg/EXGWo2xwrjbhaAIwbrnwYmT6OBMAeTNKE PNUg== X-Gm-Message-State: ALoCoQleBf90mhWYoSwyWHTPOrJOt3PrjcZGZCcOWKKncNcd8LJr1uehtDCdgOUVOUbk3tJYt2Tf X-Received: by 10.140.40.81 with SMTP id w75mr13108172qgw.112.1400146546776; Thu, 15 May 2014 02:35:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.203.165 with HTTP; Thu, 15 May 2014 02:35:26 -0700 (PDT) From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 15 May 2014 11:35:26 +0200 Message-ID: To: "SIPCORE (Session Initiation Protocol Core) WG" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/THo5P1NaB214KYhgPgMd3LbENgw Cc: Emil Ivov Subject: [sipcore] Trickle ICE is a MUST for SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 09:35:56 -0000 Hi, IMHO we need Trickle ICE for SIP ASAP. Otherwise any custom protocol designed by people with less RTC knowledge than SIP folks will be better than SIP when ICE is in use (of course I mean WebRTC). I actively try to argue that SIP is suitable for browsers and WebRTC, but this is no longer true if Trickle ICE is not feasible with SIP. Having a VPN or a virtual interface (VMware, VirtualBox, etc) in the computer makes SIP a bad choice because the ICE triggering process takes too long (timeout due to virtual interfaces). Is there interest in draft-ivov-mmusic-trickle-ice-sip [*] ? Really, I don't think we can wait one year for a standard. There are lot of people using SIP for WebRTC. Trickle ICE is a MUST. Best regards. [*] http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-sip-01 --=20 I=C3=B1aki Baz Castillo From nobody Thu May 15 04:36:57 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89B951A0031 for ; Thu, 15 May 2014 04:36:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.921 X-Spam-Level: X-Spam-Status: No, score=0.921 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0M8noAuYzDfU for ; Thu, 15 May 2014 04:36:54 -0700 (PDT) Received: from mail-qg0-f49.google.com (mail-qg0-f49.google.com [209.85.192.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 679111A0029 for ; Thu, 15 May 2014 04:36:54 -0700 (PDT) Received: by mail-qg0-f49.google.com with SMTP id a108so1430295qge.36 for ; Thu, 15 May 2014 04:36:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=oWcqbla9f2Mxrjpvl6z6jKMkRJ/2uqM47YrgSxNzODw=; b=PdCn/ohvrFPHrHjBKVzzsGMhTSWzbjui5O2faBkIketV05BVtiMeNJ146njqMlz0Jo SmT51z3vdWSMeFYVYNqE8zEaEZRRGzR8W4UtZQfwxdhe5hUHiRCz9OOUPDTok1pe3ZCn vmLBStayPFCwtjyBtnwej+HPg2dU7kLsYGOslguv3YWyRuxG9vcAsONaC+QwhWiXVReC 2EyomjxZnvaTb8U3zXDr3Q4ZRBGn/CEzZ4eYRXzE1F+ynq3bEjig35GivoOmwAZXD9ji WyKtOxv2rTMRvbqgQX8xqUEtP/espJnNXiHo4E/EfLQrvEpDR5UcnDSw3/Cd2csOe9ch AV/A== X-Gm-Message-State: ALoCoQkZfKLA6HYdtxv7M+23SncgITQbU8VKfjkvBZUDJPr3JL9vir8RvNyk+BXL8/9d9TOT8FHU X-Received: by 10.140.81.146 with SMTP id f18mr13625376qgd.47.1400153806908; Thu, 15 May 2014 04:36:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.203.165 with HTTP; Thu, 15 May 2014 04:36:26 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 15 May 2014 13:36:26 +0200 Message-ID: To: "SIPCORE (Session Initiation Protocol Core) WG" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/b_CiMW3YROQwV9jlBv0suvXjHho Cc: Emil Ivov Subject: Re: [sipcore] Trickle ICE is a MUST for SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 11:36:55 -0000 Hi, Will join this topic in the MMUSIC WG where the draft is being proposed. Regards. 2014-05-15 11:35 GMT+02:00 I=C3=B1aki Baz Castillo : > Hi, > > IMHO we need Trickle ICE for SIP ASAP. Otherwise any custom protocol > designed by people with less RTC knowledge than SIP folks will be > better than SIP when ICE is in use (of course I mean WebRTC). > > I actively try to argue that SIP is suitable for browsers and WebRTC, > but this is no longer true if Trickle ICE is not feasible with SIP. > Having a VPN or a virtual interface (VMware, VirtualBox, etc) in the > computer makes SIP a bad choice because the ICE triggering process > takes too long (timeout due to virtual interfaces). > > Is there interest in draft-ivov-mmusic-trickle-ice-sip [*] ? Really, I > don't think we can wait one year for a standard. There are lot of > people using SIP for WebRTC. Trickle ICE is a MUST. > > Best regards. > > > > [*] http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-sip-01 > > > -- > I=C3=B1aki Baz Castillo > --=20 I=C3=B1aki Baz Castillo From nobody Thu May 15 08:47:33 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6DEC1A0371 for ; Thu, 15 May 2014 08:47:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.664 X-Spam-Level: X-Spam-Status: No, score=0.664 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id En6CqUPwoHsJ for ; Thu, 15 May 2014 08:47:23 -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 C4CEE1A00CB for ; Thu, 15 May 2014 08:47:18 -0700 (PDT) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta14.westchester.pa.mail.comcast.net with comcast id 2BCl1o00327AodY5EFnBqe; Thu, 15 May 2014 15:47:11 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta19.westchester.pa.mail.comcast.net with comcast id 2FnB1o00N3ZTu2S3fFnB3z; Thu, 15 May 2014 15:47:11 +0000 Message-ID: <5374E17F.8090806@alum.mit.edu> Date: Thu, 15 May 2014 11:47:11 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: sipcore@ietf.org References: 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=q20140121; t=1400168831; bh=HZwERRF/kJaOX4BshTxcKE1hhlx/hJPX89qNW44QaO0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=LZkElLpy0e18AC3zC4v8ryF7fh/sEIZeqzlyMxPFGQEy3RuIvqx0797GdAIjxjIlJ bYfznync3FLw2aMLlL+UQotweeSsm2txPg2g8dPNkQQ0+4oqcyCVzoHeWwkYTfBMKQ CYbLa/2NAA5lbw60We+1eTa9oYgSTsXjX3Yq8/AvJ0Gug5iaJ+n1MR1lIaWHwDhGe3 +x0Bq28M9M2yrgjzlnJfdk6LmJ3xgpOeG9XefFJQXglYbObGR1NHASRM9ZSYGoi2Ii uCe8k4MDu3Bo04KP19u17LxAQrnobWLRwVWQmrmQHgLeiHK7iGI1hR+k8nPw1p5wCe b4hEw5sZJHr4A== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/g3nxXvisbdIxFpOq4pMadMN07iA Subject: Re: [sipcore] Trickle ICE is a MUST for SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 15:47:24 -0000 Iñaki, O/A was carefully partitioned so that the basic O/A mechanism is independent of sip, so RFC 3264 could be handled by mmusic, while the means of conveying O/A in sip is defined in 3261 that was handled by the sip wg. We have similar turf issues for trickle ICE. The basic mechanism for trickle ICE is independent of SIP, but the mechanism for conveying it in sip is a different matter. So the conveyance of trickle ICE in sip via INFO or most likely should be handled in DISPATCH or SIPCORE, but it *may* be most appropriate to handle the actual message content describing the trickling in MMUSIC. It is not necessary to process info packages in sipcore. In principle one could be done in mmusic, if people are comfortable with that. I know this is all bureaucratic BS, but better to sort it out up front than later on. OTOH mmusic is very busy, so doing the work elsewhere might be quicker. Thanks, Paul On 5/15/14 7:36 AM, Iñaki Baz Castillo wrote: > Hi, > > Will join this topic in the MMUSIC WG where the draft is being proposed. > > Regards. > > 2014-05-15 11:35 GMT+02:00 Iñaki Baz Castillo : >> Hi, >> >> IMHO we need Trickle ICE for SIP ASAP. Otherwise any custom protocol >> designed by people with less RTC knowledge than SIP folks will be >> better than SIP when ICE is in use (of course I mean WebRTC). >> >> I actively try to argue that SIP is suitable for browsers and WebRTC, >> but this is no longer true if Trickle ICE is not feasible with SIP. >> Having a VPN or a virtual interface (VMware, VirtualBox, etc) in the >> computer makes SIP a bad choice because the ICE triggering process >> takes too long (timeout due to virtual interfaces). >> >> Is there interest in draft-ivov-mmusic-trickle-ice-sip [*] ? Really, I >> don't think we can wait one year for a standard. There are lot of >> people using SIP for WebRTC. Trickle ICE is a MUST. >> >> Best regards. >> >> >> >> [*] http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-sip-01 >> >> >> -- >> Iñaki Baz Castillo >> > > > From nobody Thu May 15 10:28:42 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD4C1A02D1 for ; Thu, 15 May 2014 10:28:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id naNEjtuxcQJS for ; Thu, 15 May 2014 10:28:37 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 273621A02F2 for ; Thu, 15 May 2014 10:28:36 -0700 (PDT) X-AuditID: c1b4fb3a-f79a86d0000010e9-a9-5374f93cfd57 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 98.17.04329.C39F4735; Thu, 15 May 2014 19:28:28 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.191]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0174.001; Thu, 15 May 2014 19:28:27 +0200 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Trickle ICE is a MUST for SIP Thread-Index: AQHPcFT6DdmMDtjMQECBInU4gqLHeJtB5Wfw Date: Thu, 15 May 2014 17:28:27 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D2FDE35@ESESSMB209.ericsson.se> References: <5374E17F.8090806@alum.mit.edu> In-Reply-To: <5374E17F.8090806@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUyM+Jvja7Nz5JggzsX1C1WbDjAavH1xyY2 ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSujrf0aW0GDTMX6N4sYGxiXSHcxcnJICJhI LGu4zQRhi0lcuLeerYuRi0NI4CijxJaHf6GcJYwSW3f9AnI4ONgELCS6/2mDNIgIBEpcXTKB GcQWBhrUd+QAG0TcVOLWx8WMELaRxLHJy1hAbBYBVYmXS++zg9i8Ar4S57ZdYoGYv5NRYsWt VWDNnAI6Ep8fzAezGYEu+n5qDdh1zALiEreezIe6VEBiyZ7zzBC2qMTLx/9YIWwliUW3PzOB 3MksoCmxfpc+RKuixJTuh1B7BSVOznzCMoFRdBaSqbMQOmYh6ZiFpGMBI8sqRtHi1OLi3HQj I73Uoszk4uL8PL281JJNjMAoObjlt9UOxoPPHQ8xCnAwKvHwKqwvDhZiTSwrrsw9xCjNwaIk znvjcEmwkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsYVNm6vZ6+wE5bWs3zrXzv9h47jpwcM 3xxM/mxz/pKT4ld3ONJ34xcnL71ryVYc/9N2WHffMbPxkfCz3RA08SfbnVUGc281L2UTaJV9 vjHYvGt2md5h979bPl5quGYzccu/QIaltZcLcpXjty5mKnh6qfx6ZafAnB+iAlJVLOLbtjxy 3rnFJk2JpTgj0VCLuag4EQCjXfVycwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/UI_DJNe8mZT_ukthxc_7UFD68p8 Subject: Re: [sipcore] Trickle ICE is a MUST for SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 17:28:40 -0000 SXQgaXMgdHJ1ZSB0aGF0IE1NVVNJQyBpcyB2ZXJ5IGJ1c3kgZHVyaW5nIHRoZSBtZWV0aW5ncywg YnV0IGJldHdlZW4gdGhlIG1lZXRpbmdzIHRoZXJlIGlzIGxvdHMgb2Ygc3BhY2UgYXZhaWxhYmxl IG9uIHRoZSBtYWlsaW5nIGxpc3QuLi4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHNpcGNvcmUgW21haWx0bzpzaXBjb3JlLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBQYXVsIEt5eml2YXQNClNlbnQ6IDE1IE1heSAyMDE0 IDE4OjQ3DQpUbzogc2lwY29yZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtzaXBjb3JlXSBUcmlj a2xlIElDRSBpcyBhIE1VU1QgZm9yIFNJUA0KDQpJw7Fha2ksDQoNCk8vQSB3YXMgY2FyZWZ1bGx5 IHBhcnRpdGlvbmVkIHNvIHRoYXQgdGhlIGJhc2ljIE8vQSBtZWNoYW5pc20gaXMgaW5kZXBlbmRl bnQgb2Ygc2lwLCBzbyBSRkMgMzI2NCBjb3VsZCBiZSBoYW5kbGVkIGJ5IG1tdXNpYywgd2hpbGUg dGhlIG1lYW5zIG9mIGNvbnZleWluZyBPL0EgaW4gc2lwIGlzIGRlZmluZWQgaW4gMzI2MSB0aGF0 IHdhcyBoYW5kbGVkIGJ5IHRoZSBzaXAgd2cuDQoNCldlIGhhdmUgc2ltaWxhciB0dXJmIGlzc3Vl cyBmb3IgdHJpY2tsZSBJQ0UuIFRoZSBiYXNpYyBtZWNoYW5pc20gZm9yIHRyaWNrbGUgSUNFIGlz IGluZGVwZW5kZW50IG9mIFNJUCwgYnV0IHRoZSBtZWNoYW5pc20gZm9yIGNvbnZleWluZyBpdCBp biBzaXAgaXMgYSBkaWZmZXJlbnQgbWF0dGVyLiBTbyB0aGUgY29udmV5YW5jZSBvZiB0cmlja2xl IElDRSBpbiBzaXAgdmlhIElORk8gb3IgbW9zdCBsaWtlbHkgc2hvdWxkIGJlIGhhbmRsZWQgaW4g RElTUEFUQ0ggb3IgU0lQQ09SRSwgYnV0IGl0DQoqbWF5KiBiZSBtb3N0IGFwcHJvcHJpYXRlIHRv IGhhbmRsZSB0aGUgYWN0dWFsIG1lc3NhZ2UgY29udGVudCBkZXNjcmliaW5nIHRoZSB0cmlja2xp bmcgaW4gTU1VU0lDLg0KDQpJdCBpcyBub3QgbmVjZXNzYXJ5IHRvIHByb2Nlc3MgaW5mbyBwYWNr YWdlcyBpbiBzaXBjb3JlLiBJbiBwcmluY2lwbGUgb25lIGNvdWxkIGJlIGRvbmUgaW4gbW11c2lj LCBpZiBwZW9wbGUgYXJlIGNvbWZvcnRhYmxlIHdpdGggdGhhdC4NCg0KSSBrbm93IHRoaXMgaXMg YWxsIGJ1cmVhdWNyYXRpYyBCUywgYnV0IGJldHRlciB0byBzb3J0IGl0IG91dCB1cCBmcm9udCB0 aGFuIGxhdGVyIG9uLiBPVE9IIG1tdXNpYyBpcyB2ZXJ5IGJ1c3ksIHNvIGRvaW5nIHRoZSB3b3Jr IGVsc2V3aGVyZSBtaWdodCBiZSBxdWlja2VyLg0KDQoJVGhhbmtzLA0KCVBhdWwNCg0KT24gNS8x NS8xNCA3OjM2IEFNLCBJw7Fha2kgQmF6IENhc3RpbGxvIHdyb3RlOg0KPiBIaSwNCj4NCj4gV2ls bCBqb2luIHRoaXMgdG9waWMgaW4gdGhlIE1NVVNJQyBXRyB3aGVyZSB0aGUgZHJhZnQgaXMgYmVp bmcgcHJvcG9zZWQuDQo+DQo+IFJlZ2FyZHMuDQo+DQo+IDIwMTQtMDUtMTUgMTE6MzUgR01UKzAy OjAwIEnDsWFraSBCYXogQ2FzdGlsbG8gPGliY0BhbGlheC5uZXQ+Og0KPj4gSGksDQo+Pg0KPj4g SU1ITyB3ZSBuZWVkIFRyaWNrbGUgSUNFIGZvciBTSVAgQVNBUC4gT3RoZXJ3aXNlIGFueSBjdXN0 b20gcHJvdG9jb2wgDQo+PiBkZXNpZ25lZCBieSBwZW9wbGUgd2l0aCBsZXNzIFJUQyBrbm93bGVk Z2UgdGhhbiBTSVAgZm9sa3Mgd2lsbCBiZSANCj4+IGJldHRlciB0aGFuIFNJUCB3aGVuIElDRSBp cyBpbiB1c2UgKG9mIGNvdXJzZSBJIG1lYW4gV2ViUlRDKS4NCj4+DQo+PiBJIGFjdGl2ZWx5IHRy eSB0byBhcmd1ZSB0aGF0IFNJUCBpcyBzdWl0YWJsZSBmb3IgYnJvd3NlcnMgYW5kIFdlYlJUQywg DQo+PiBidXQgdGhpcyBpcyBubyBsb25nZXIgdHJ1ZSBpZiBUcmlja2xlIElDRSBpcyBub3QgZmVh c2libGUgd2l0aCBTSVAuDQo+PiBIYXZpbmcgYSBWUE4gb3IgYSB2aXJ0dWFsIGludGVyZmFjZSAo Vk13YXJlLCBWaXJ0dWFsQm94LCBldGMpIGluIHRoZSANCj4+IGNvbXB1dGVyIG1ha2VzIFNJUCBh IGJhZCBjaG9pY2UgYmVjYXVzZSB0aGUgSUNFIHRyaWdnZXJpbmcgcHJvY2VzcyANCj4+IHRha2Vz IHRvbyBsb25nICh0aW1lb3V0IGR1ZSB0byB2aXJ0dWFsIGludGVyZmFjZXMpLg0KPj4NCj4+IElz IHRoZXJlIGludGVyZXN0IGluIGRyYWZ0LWl2b3YtbW11c2ljLXRyaWNrbGUtaWNlLXNpcCBbKl0g PyBSZWFsbHksIA0KPj4gSSBkb24ndCB0aGluayB3ZSBjYW4gd2FpdCBvbmUgeWVhciBmb3IgYSBz dGFuZGFyZC4gVGhlcmUgYXJlIGxvdCBvZiANCj4+IHBlb3BsZSB1c2luZyBTSVAgZm9yIFdlYlJU Qy4gVHJpY2tsZSBJQ0UgaXMgYSBNVVNULg0KPj4NCj4+IEJlc3QgcmVnYXJkcy4NCj4+DQo+Pg0K Pj4NCj4+IFsqXSBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pdm92LW1tdXNpYy10 cmlja2xlLWljZS1zaXAtMDENCj4+DQo+Pg0KPj4gLS0NCj4+IEnDsWFraSBCYXogQ2FzdGlsbG8N Cj4+IDxpYmNAYWxpYXgubmV0Pg0KPg0KPg0KPg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0Kc2lwY29yZSBtYWlsaW5nIGxpc3QNCnNpcGNvcmVAaWV0 Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZQ0K From nobody Thu May 15 10:35:41 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4C361A02B9 for ; Thu, 15 May 2014 10:35:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vgbz8UVpaUAI for ; Thu, 15 May 2014 10:35:37 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 079C61A0075 for ; Thu, 15 May 2014 10:35:31 -0700 (PDT) X-AuditID: c1b4fb25-f798c6d000001521-ac-5374fadbd59c Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id BA.6A.05409.BDAF4735; Thu, 15 May 2014 19:35:23 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.191]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0174.001; Thu, 15 May 2014 19:35:22 +0200 From: Christer Holmberg To: Christer Holmberg , Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Trickle ICE is a MUST for SIP Thread-Index: AQHPcFT6DdmMDtjMQECBInU4gqLHeJtB5WfwgAAB1OA= Date: Thu, 15 May 2014 17:35:22 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D2FDEBC@ESESSMB209.ericsson.se> References: <5374E17F.8090806@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2FDE35@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D2FDE35@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPLMWRmVeSWpSXmKPExsUyM+Jvje7tXyXBBl2dShYrNhxgtfj6YxOb A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJVxr28KS8E0pYrtn10aGJcodjFyckgImEj0 zXvEDGGLSVy4t56ti5GLQ0jgKKNE9611rBDOEkaJNxsagBwODjYBC4nuf9ogcRGBVkaJLRvu MoJ0C4NMOnKADcQWETCVuPVxMSNIvYiAlcSZTXkgYRYBVYmNU/rBynkFfCU+dR5hgZj/l1Fi 88wdLCAJTgE/iT/rV7GC2IxAF30/tYYJxGYWEJe49WQ+E8SlAhJL9pyHulpU4uXjf6wQtpLE otufmUD2MgtoSqzfpQ/RqigxpfshO8ReQYmTM5+wTGAUnYVk6iyEjllIOmYh6VjAyLKKUbQ4 tTgpN93IWC+1KDO5uDg/Ty8vtWQTIzBGDm75rbqD8fIbx0OMAhyMSjy8CuuLg4VYE8uKK3MP MUpzsCiJ8944XBIsJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgbE2MJQp8meF9ecfJcfdgv4t m7VQk8HnXyDzhpVnYvvm5xgpHrB48Vskf0P42QQHX54PGzOX/V5U5JQQe2Fig2jw0uhrsk9u Cl/YsjSvLu4mh+Knpx5uDVsYkpxXtat97Mi885b9utLx+5cT9u9bdFn6+LlXp0UToj/ve1qd wV+e3/icVee/tLMSS3FGoqEWc1FxIgBuyj8icgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/38Bn-oyMyzht6D_DQOgLbwsaPMM Subject: Re: [sipcore] Trickle ICE is a MUST for SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 17:35:39 -0000 SW4gYWRkaXRpb24sIGFuIEluZm8gUGFja2FnZSBkb2Vzbid0IGV2ZW4gaGF2ZSB0byBiZSBzcGVj aWZpZWQgaW4gSUVURi4NCg0KVHJpY2tsZSBJQ0UgaXMgb2J2aW91c2x5IGEgc3BlY2lhbCBjYXNl LCB0aG91Z2gsIGFuZCBub3QganVzdCBzb21lIGFwcGxpY2F0aW9uIGRhdGEgc2VudCBiZXR3ZWVu IHR3byBlbnRpdGllcyA6KQ0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogc2lwY29yZSBbbWFpbHRvOnNpcGNvcmUtYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIENocmlzdGVyIEhvbG1iZXJnDQpTZW50OiAxNSBNYXkgMjAxNCAy MDoyOA0KVG86IFBhdWwgS3l6aXZhdDsgc2lwY29yZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtz aXBjb3JlXSBUcmlja2xlIElDRSBpcyBhIE1VU1QgZm9yIFNJUA0KDQpJdCBpcyB0cnVlIHRoYXQg TU1VU0lDIGlzIHZlcnkgYnVzeSBkdXJpbmcgdGhlIG1lZXRpbmdzLCBidXQgYmV0d2VlbiB0aGUg bWVldGluZ3MgdGhlcmUgaXMgbG90cyBvZiBzcGFjZSBhdmFpbGFibGUgb24gdGhlIG1haWxpbmcg bGlzdC4uLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KRnJvbTogc2lwY29yZSBbbWFpbHRvOnNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIFBhdWwgS3l6aXZhdA0KU2VudDogMTUgTWF5IDIwMTQgMTg6NDcNClRvOiBzaXBj b3JlQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3NpcGNvcmVdIFRyaWNrbGUgSUNFIGlzIGEgTVVT VCBmb3IgU0lQDQoNCknDsWFraSwNCg0KTy9BIHdhcyBjYXJlZnVsbHkgcGFydGl0aW9uZWQgc28g dGhhdCB0aGUgYmFzaWMgTy9BIG1lY2hhbmlzbSBpcyBpbmRlcGVuZGVudCBvZiBzaXAsIHNvIFJG QyAzMjY0IGNvdWxkIGJlIGhhbmRsZWQgYnkgbW11c2ljLCB3aGlsZSB0aGUgbWVhbnMgb2YgY29u dmV5aW5nIE8vQSBpbiBzaXAgaXMgZGVmaW5lZCBpbiAzMjYxIHRoYXQgd2FzIGhhbmRsZWQgYnkg dGhlIHNpcCB3Zy4NCg0KV2UgaGF2ZSBzaW1pbGFyIHR1cmYgaXNzdWVzIGZvciB0cmlja2xlIElD RS4gVGhlIGJhc2ljIG1lY2hhbmlzbSBmb3IgdHJpY2tsZSBJQ0UgaXMgaW5kZXBlbmRlbnQgb2Yg U0lQLCBidXQgdGhlIG1lY2hhbmlzbSBmb3IgY29udmV5aW5nIGl0IGluIHNpcCBpcyBhIGRpZmZl cmVudCBtYXR0ZXIuIFNvIHRoZSBjb252ZXlhbmNlIG9mIHRyaWNrbGUgSUNFIGluIHNpcCB2aWEg SU5GTyBvciBtb3N0IGxpa2VseSBzaG91bGQgYmUgaGFuZGxlZCBpbiBESVNQQVRDSCBvciBTSVBD T1JFLCBidXQgaXQNCiptYXkqIGJlIG1vc3QgYXBwcm9wcmlhdGUgdG8gaGFuZGxlIHRoZSBhY3R1 YWwgbWVzc2FnZSBjb250ZW50IGRlc2NyaWJpbmcgdGhlIHRyaWNrbGluZyBpbiBNTVVTSUMuDQoN Ckl0IGlzIG5vdCBuZWNlc3NhcnkgdG8gcHJvY2VzcyBpbmZvIHBhY2thZ2VzIGluIHNpcGNvcmUu IEluIHByaW5jaXBsZSBvbmUgY291bGQgYmUgZG9uZSBpbiBtbXVzaWMsIGlmIHBlb3BsZSBhcmUg Y29tZm9ydGFibGUgd2l0aCB0aGF0Lg0KDQpJIGtub3cgdGhpcyBpcyBhbGwgYnVyZWF1Y3JhdGlj IEJTLCBidXQgYmV0dGVyIHRvIHNvcnQgaXQgb3V0IHVwIGZyb250IHRoYW4gbGF0ZXIgb24uIE9U T0ggbW11c2ljIGlzIHZlcnkgYnVzeSwgc28gZG9pbmcgdGhlIHdvcmsgZWxzZXdoZXJlIG1pZ2h0 IGJlIHF1aWNrZXIuDQoNCglUaGFua3MsDQoJUGF1bA0KDQpPbiA1LzE1LzE0IDc6MzYgQU0sIEnD sWFraSBCYXogQ2FzdGlsbG8gd3JvdGU6DQo+IEhpLA0KPg0KPiBXaWxsIGpvaW4gdGhpcyB0b3Bp YyBpbiB0aGUgTU1VU0lDIFdHIHdoZXJlIHRoZSBkcmFmdCBpcyBiZWluZyBwcm9wb3NlZC4NCj4N Cj4gUmVnYXJkcy4NCj4NCj4gMjAxNC0wNS0xNSAxMTozNSBHTVQrMDI6MDAgScOxYWtpIEJheiBD YXN0aWxsbyA8aWJjQGFsaWF4Lm5ldD46DQo+PiBIaSwNCj4+DQo+PiBJTUhPIHdlIG5lZWQgVHJp Y2tsZSBJQ0UgZm9yIFNJUCBBU0FQLiBPdGhlcndpc2UgYW55IGN1c3RvbSBwcm90b2NvbCANCj4+ IGRlc2lnbmVkIGJ5IHBlb3BsZSB3aXRoIGxlc3MgUlRDIGtub3dsZWRnZSB0aGFuIFNJUCBmb2xr cyB3aWxsIGJlIA0KPj4gYmV0dGVyIHRoYW4gU0lQIHdoZW4gSUNFIGlzIGluIHVzZSAob2YgY291 cnNlIEkgbWVhbiBXZWJSVEMpLg0KPj4NCj4+IEkgYWN0aXZlbHkgdHJ5IHRvIGFyZ3VlIHRoYXQg U0lQIGlzIHN1aXRhYmxlIGZvciBicm93c2VycyBhbmQgV2ViUlRDLCANCj4+IGJ1dCB0aGlzIGlz IG5vIGxvbmdlciB0cnVlIGlmIFRyaWNrbGUgSUNFIGlzIG5vdCBmZWFzaWJsZSB3aXRoIFNJUC4N Cj4+IEhhdmluZyBhIFZQTiBvciBhIHZpcnR1YWwgaW50ZXJmYWNlIChWTXdhcmUsIFZpcnR1YWxC b3gsIGV0YykgaW4gdGhlIA0KPj4gY29tcHV0ZXIgbWFrZXMgU0lQIGEgYmFkIGNob2ljZSBiZWNh dXNlIHRoZSBJQ0UgdHJpZ2dlcmluZyBwcm9jZXNzIA0KPj4gdGFrZXMgdG9vIGxvbmcgKHRpbWVv dXQgZHVlIHRvIHZpcnR1YWwgaW50ZXJmYWNlcykuDQo+Pg0KPj4gSXMgdGhlcmUgaW50ZXJlc3Qg aW4gZHJhZnQtaXZvdi1tbXVzaWMtdHJpY2tsZS1pY2Utc2lwIFsqXSA/IFJlYWxseSwgDQo+PiBJ IGRvbid0IHRoaW5rIHdlIGNhbiB3YWl0IG9uZSB5ZWFyIGZvciBhIHN0YW5kYXJkLiBUaGVyZSBh cmUgbG90IG9mIA0KPj4gcGVvcGxlIHVzaW5nIFNJUCBmb3IgV2ViUlRDLiBUcmlja2xlIElDRSBp cyBhIE1VU1QuDQo+Pg0KPj4gQmVzdCByZWdhcmRzLg0KPj4NCj4+DQo+Pg0KPj4gWypdIGh0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWl2b3YtbW11c2ljLXRyaWNrbGUtaWNlLXNpcC0w MQ0KPj4NCj4+DQo+PiAtLQ0KPj4gScOxYWtpIEJheiBDYXN0aWxsbw0KPj4gPGliY0BhbGlheC5u ZXQ+DQo+DQo+DQo+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpzaXBjb3JlIG1haWxpbmcgbGlzdA0Kc2lwY29yZUBpZXRmLm9yZw0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc2lwY29yZSBtYWlsaW5nIGxpc3QNCnNpcGNv cmVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29y ZQ0K From nobody Fri May 16 01:14:08 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C90B1A00C9 for ; Fri, 16 May 2014 01:13:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id khCWbR_M2piG for ; Fri, 16 May 2014 01:13:47 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 554811A00BD for ; Fri, 16 May 2014 01:13:46 -0700 (PDT) Received: from [192.168.40.24] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 80D5493C2A1; Fri, 16 May 2014 08:13:28 +0000 (UTC) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: "Olle E. Johansson" In-Reply-To: <5374E17F.8090806@alum.mit.edu> Date: Fri, 16 May 2014 10:13:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5374E17F.8090806@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/VSP-Q0xbO4qKE1yU9vIKdW_hhwg Cc: sipcore@ietf.org, Olle E Johansson Subject: Re: [sipcore] Trickle ICE is a MUST for SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2014 08:13:50 -0000 On 15 May 2014, at 17:47, Paul Kyzivat wrote: > I=F1aki, >=20 > O/A was carefully partitioned so that the basic O/A mechanism is = independent of sip, so RFC 3264 could be handled by mmusic, while the = means of conveying O/A in sip is defined in 3261 that was handled by the = sip wg. >=20 > We have similar turf issues for trickle ICE. The basic mechanism for = trickle ICE is independent of SIP, but the mechanism for conveying it in = sip is a different matter. So the conveyance of trickle ICE in sip via = INFO or most likely should be handled in DISPATCH or SIPCORE, but it = *may* be most appropriate to handle the actual message content = describing the trickling in MMUSIC. >=20 > It is not necessary to process info packages in sipcore. In principle = one could be done in mmusic, if people are comfortable with that. >=20 > I know this is all bureaucratic BS, but better to sort it out up front = than later on. OTOH mmusic is very busy, so doing the work elsewhere = might be quicker. I propose we get it dispatched to SIPCORE and handle it quickly. I=F1aki - please resend your message to dispatch and we'll handle it = from there. /O >=20 > Thanks, > Paul >=20 > On 5/15/14 7:36 AM, I=F1aki Baz Castillo wrote: >> Hi, >>=20 >> Will join this topic in the MMUSIC WG where the draft is being = proposed. >>=20 >> Regards. >>=20 >> 2014-05-15 11:35 GMT+02:00 I=F1aki Baz Castillo : >>> Hi, >>>=20 >>> IMHO we need Trickle ICE for SIP ASAP. Otherwise any custom protocol >>> designed by people with less RTC knowledge than SIP folks will be >>> better than SIP when ICE is in use (of course I mean WebRTC). >>>=20 >>> I actively try to argue that SIP is suitable for browsers and = WebRTC, >>> but this is no longer true if Trickle ICE is not feasible with SIP. >>> Having a VPN or a virtual interface (VMware, VirtualBox, etc) in the >>> computer makes SIP a bad choice because the ICE triggering process >>> takes too long (timeout due to virtual interfaces). >>>=20 >>> Is there interest in draft-ivov-mmusic-trickle-ice-sip [*] ? Really, = I >>> don't think we can wait one year for a standard. There are lot of >>> people using SIP for WebRTC. Trickle ICE is a MUST. >>>=20 >>> Best regards. >>>=20 >>>=20 >>>=20 >>> [*] http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-sip-01 >>>=20 >>>=20 >>> -- >>> I=F1aki Baz Castillo >>> >>=20 >>=20 >>=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Sun May 18 16:04:55 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 633D11A01EE for ; Sun, 18 May 2014 16:04:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.699 X-Spam-Level: X-Spam-Status: No, score=0.699 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nmTeLJhsULyc for ; Sun, 18 May 2014 16:04:51 -0700 (PDT) Received: from outbound.mailhostbox.com (outbound.mailhostbox.com [162.222.225.28]) by ietfa.amsl.com (Postfix) with ESMTP id 19CAD1A01E4 for ; Sun, 18 May 2014 16:04:50 -0700 (PDT) Received: from userPC (unknown [122.167.204.88]) (Authenticated sender: partha@parthasarathi.co.in) by outbound.mailhostbox.com (Postfix) with ESMTPA id 3341516C8018; Sun, 18 May 2014 23:04:46 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1400454290; bh=nxFYKq30f1ga8uUwFjSN7O9Qu8Iu5nwQ6NtgqNLrmo0=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=LkgYXuF8mJ2iZesluPLFD2FkobKSzFwfZw5tdI82zZ2y3N93dyj2Sc1PBQqS3qtLV ++rqzWDma3yRZUgs+dVUoJwPUDczWxO0oeLmw5oHFFEoqnsNVNv8VYFRyA7qUtIZvw km4NXGSdsc/IVgAHZJ26YhNYPCSVuKH1jySgVC6c= From: "Parthasarathi R" To: "'Christer Holmberg'" , "'Paul Kyzivat'" , References: <5374E17F.8090806@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2FDE35@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D2FDEBC@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D2FDEBC@ESESSMB209.ericsson.se> Date: Mon, 19 May 2014 04:34:41 +0530 Message-ID: <00a201cf72ed$91a18110$b4e48330$@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: AQHPcFT6DdmMDtjMQECBInU4gqLHeJtB5WfwgAAB1OCABRAVoA== Content-Language: en-us X-CTCH-RefID: str=0001.0A02020A.53793C92.002C, 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 172.18.214.93 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/At0ktqRWGJK6KcLMuM6cngjnITg Subject: Re: [sipcore] Trickle ICE is a MUST for SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 May 2014 23:04:53 -0000 Hi all, I agree that Trickle ICE is a special case but it should not be designed = in a way to break the existing O/A model. I have explained the usecases = in MMUSIC WG wherein INFO creates race condition within O/A = (http://www.ietf.org/mail-archive/web/mmusic/current/msg13287.html). = Irrespective of WG where this usecase is developed, this issue has to be = resolved. Thanks Partha > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer > Holmberg > Sent: Thursday, May 15, 2014 11:05 PM > To: Christer Holmberg; Paul Kyzivat; sipcore@ietf.org > Subject: Re: [sipcore] Trickle ICE is a MUST for SIP >=20 > In addition, an Info Package doesn't even have to be specified in = IETF. >=20 > Trickle ICE is obviously a special case, though, and not just some > application data sent between two entities :) >=20 > Regards, >=20 > Christer >=20 > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer > Holmberg > Sent: 15 May 2014 20:28 > To: Paul Kyzivat; sipcore@ietf.org > Subject: Re: [sipcore] Trickle ICE is a MUST for SIP >=20 > It is true that MMUSIC is very busy during the meetings, but between > the meetings there is lots of space available on the mailing list... >=20 > Regards, >=20 > Christer >=20 > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul > Kyzivat > Sent: 15 May 2014 18:47 > To: sipcore@ietf.org > Subject: Re: [sipcore] Trickle ICE is a MUST for SIP >=20 > I=C3=B1aki, >=20 > O/A was carefully partitioned so that the basic O/A mechanism is > independent of sip, so RFC 3264 could be handled by mmusic, while the > means of conveying O/A in sip is defined in 3261 that was handled by > the sip wg. >=20 > We have similar turf issues for trickle ICE. The basic mechanism for > trickle ICE is independent of SIP, but the mechanism for conveying it > in sip is a different matter. So the conveyance of trickle ICE in sip > via INFO or most likely should be handled in DISPATCH or SIPCORE, but > it > *may* be most appropriate to handle the actual message content > describing the trickling in MMUSIC. >=20 > It is not necessary to process info packages in sipcore. In principle > one could be done in mmusic, if people are comfortable with that. >=20 > I know this is all bureaucratic BS, but better to sort it out up front > than later on. OTOH mmusic is very busy, so doing the work elsewhere > might be quicker. >=20 > Thanks, > Paul >=20 > On 5/15/14 7:36 AM, I=C3=B1aki Baz Castillo wrote: > > Hi, > > > > Will join this topic in the MMUSIC WG where the draft is being > proposed. > > > > Regards. > > > > 2014-05-15 11:35 GMT+02:00 I=C3=B1aki Baz Castillo : > >> Hi, > >> > >> IMHO we need Trickle ICE for SIP ASAP. Otherwise any custom = protocol > >> designed by people with less RTC knowledge than SIP folks will be > >> better than SIP when ICE is in use (of course I mean WebRTC). > >> > >> I actively try to argue that SIP is suitable for browsers and > WebRTC, > >> but this is no longer true if Trickle ICE is not feasible with SIP. > >> Having a VPN or a virtual interface (VMware, VirtualBox, etc) in = the > >> computer makes SIP a bad choice because the ICE triggering process > >> takes too long (timeout due to virtual interfaces). > >> > >> Is there interest in draft-ivov-mmusic-trickle-ice-sip [*] ? = Really, > >> I don't think we can wait one year for a standard. There are lot of > >> people using SIP for WebRTC. Trickle ICE is a MUST. > >> > >> Best regards. > >> > >> > >> > >> [*] http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-sip-01 > >> > >> > >> -- > >> I=C3=B1aki Baz Castillo > >> > > > > > > >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Mon May 19 02:01:44 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C47201A0329 for ; Mon, 19 May 2014 02:01:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RSdFXy2Yfvn1 for ; Mon, 19 May 2014 02:01:39 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 725901A0323 for ; Mon, 19 May 2014 02:01:39 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am0FAGPHeVPGmAcV/2dsb2JhbABZgkIjIVFYxAcBgQ8WdIInAQEDEhteAQwJFVYmAQQbGogfAZ4JhFuuZheOH4NjgRUEoG2MB4M3gjA X-IronPort-AV: E=Sophos; i="4.98,865,1392181200"; d="scan'208,217"; a="64004740" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 19 May 2014 05:01:38 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 19 May 2014 04:44:36 -0400 Received: from AZ-FFEXMB01.global.avaya.com ([fe80::39ee:75fe:e67a:cf4a]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.03.0174.001; Mon, 19 May 2014 11:01:36 +0200 From: "Goren, Ofer (Ofer)" To: "sipcore@ietf.org" Thread-Topic: SIP response is larger than MTU Thread-Index: Ac9zQOl0XrG5xIFnTkCR6dTnaCebOQ== Date: Mon, 19 May 2014 09:01:35 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: multipart/alternative; boundary="_000_E13E2A10A9E01C40B51180C484B573391F049FBCAZFFEXMB01globa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/IhSgATOUJcuz2BAs-pxB_tLNVcA Subject: [sipcore] SIP response is larger than MTU X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 May 2014 09:01:42 -0000 --_000_E13E2A10A9E01C40B51180C484B573391F049FBCAZFFEXMB01globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi I saw this question raised @ 2006, but I did not see any follow up or a fin= al decision. There was a draft suggested that became dead @ 2006 as well. Anyway, what if I send an empty INVITE, for example, using UDP, and the res= ulted response with SDP offer, exceeds the MTU? I cannot switch to TCP for = the response, as it needs to follow the request's VIAs. Thank you, Ofer. --_000_E13E2A10A9E01C40B51180C484B573391F049FBCAZFFEXMB01globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi

 

I saw this question raised @ 2006, but I did not see= any follow up or a final decision. There was a draft suggested that became= dead  @ 2006 as well.

Anyway, what if I send an empty INVITE, for example,= using UDP, and the resulted response with SDP offer, exceeds the MTU? I ca= nnot switch to TCP for the response, as it needs to follow the request̵= 7;s VIAs.

 

Thank you,

 

Ofer.

--_000_E13E2A10A9E01C40B51180C484B573391F049FBCAZFFEXMB01globa_-- From nobody Mon May 19 04:18:47 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B6BF1A0348 for ; Mon, 19 May 2014 04:18:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.08 X-Spam-Level: X-Spam-Status: No, score=-0.08 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5JGOKCNjPeRr for ; Mon, 19 May 2014 04:18:41 -0700 (PDT) Received: from mail-vc0-f171.google.com (mail-vc0-f171.google.com [209.85.220.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97B1D1A0358 for ; Mon, 19 May 2014 04:18:39 -0700 (PDT) Received: by mail-vc0-f171.google.com with SMTP id lc6so9299845vcb.16 for ; Mon, 19 May 2014 04:18:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:content-type; bh=47zVRqHFabg1EpoRr8mj3Dq/HI+hhJ6gCmuJBFujL4A=; b=RtqMZfQxu3Ie/nRNz2D1tKyibG30ODQLqOBlmQLQ8wXyFO6nSZdGQ39kGdfBDi3hyV 5vfZpc33QSgezaGEeaR43/ijOvxiD0XEqvA5UxQb/1cA65oWYyun/yJwhkMQZfEP1nDq eRv0DFkdcGufkQGZma7Aw5XrsjB0H1Hg8aLCYAzirdh/Gds7rC5M0jn+FKQNrBo1ma2l Yrd3vNiMffXqrJPbAoGgP6/991Xaq1j5kbSgar9GHhBMuR0bauyfzQTf7s2apOsUQ/2d 9Xc19dIUAoJiKQ4zVM9GON2w3t5vIdyRlG0dmEyvKEbKsuyYZzwpgXeD4wtK12MbxkNZ s+/w== X-Gm-Message-State: ALoCoQnMKyOgEa7z9bJ9xZqySJCSscW9drKIrmc+dP8f/ZTiY57mOmp+f51rlYGuRKwP+u4Jiwel+UlQ6l3T7imo2L2FJEiTpw== X-Received: by 10.221.27.8 with SMTP id ro8mr13860974vcb.30.1400498318738; Mon, 19 May 2014 04:18:38 -0700 (PDT) From: Brett Tate References: In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac9zQOl0XrG5xIFnTkCR6dTnaCebOQAD/bJQ Date: Mon, 19 May 2014 07:18:37 -0400 Message-ID: <9b0c685b3c4f5a4159624620e7dd52ff@mail.gmail.com> To: "Goren, Ofer (Ofer)" , sipcore@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/aKB5KLbOYPXtcu9_130G53QZ6eg Subject: Re: [sipcore] SIP response is larger than MTU X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 May 2014 11:18:44 -0000 > what if I send an empty INVITE, for example, using > UDP, and the resulted response with SDP offer, > exceeds the MTU? I cannot switch to TCP for the > response, as it needs to follow the request's VIAs. RFC 3261 section 18.1.1 discusses that 1) UDP fragmentation will occur for SIP messages over (approximately) 1300 bytes, and 2) implementations MUST be able to handle 65535 byte SIP messages sent over UDP. The fragmented UDP response can typically be successfully delivered/handled unless someone has disabled fragmentation support or there was excessive fragmentation. However as you noticed, the attempt to deploy "preferring UDP and switch to TCP only for large messages" does have limitations. -- See why you should attend BroadSoft Connections 2014 This email is intended solely for the person or entity to which it is addressed and may contain confidential and/or privileged information. If you are not the intended recipient and have received this email in error, please notify BroadSoft, Inc. immediately by replying to this message, and destroy all copies of this message, along with any attachment, prior to reading, distributing or copying it. From nobody Mon May 26 14:46:32 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3C351A029C for ; Mon, 26 May 2014 14:46:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KZjeaSvVxXbX for ; Mon, 26 May 2014 14:46:30 -0700 (PDT) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65A4F1A02A1 for ; Mon, 26 May 2014 14:46:30 -0700 (PDT) Received: by mail-ie0-f173.google.com with SMTP id lx4so8089574iec.18 for ; Mon, 26 May 2014 14:46:27 -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=rkegx9/ub/HVyNT03WJbFtEGXa0CFnCQGIbv5UJpn+w=; b=Oc58vXHuZAewO4QpubWiar70rWBHPB8cgF6s/zbo3Mjmer/KncPOe3lMHO3dl5jav9 LeuhfG/mW2a5lD17fwjJslIaTG2nLtXZKrorvi1J4TezCVcRqBglyf7xtmtMS0o8DwS0 Vsg91DBlyymUwY/cmAORj2gtdLh2B2YxfSay3PezBleup5HPnMoXXjqBOL6zMgfiL37p E8oPYHEJEtRo08Dnk8lyCV9u6w74jKE0JHnaL2CQVJ6bD+NpFn+MHn+6HBUZuLXs8MV5 o/FkZrZk3DcJu/bFjhb0gqx+qnlXoDU93ljR2ZqDjbbQmMwU2AFSe4bcELI4J+qemUbk QMDg== MIME-Version: 1.0 X-Received: by 10.50.65.3 with SMTP id t3mr28796658igs.20.1401140787134; Mon, 26 May 2014 14:46:27 -0700 (PDT) Received: by 10.50.111.170 with HTTP; Mon, 26 May 2014 14:46:27 -0700 (PDT) Date: Mon, 26 May 2014 17:46:27 -0400 Message-ID: From: Rifaat Shekh-Yusef To: "sipcore@ietf.org" Content-Type: multipart/alternative; boundary=047d7b3a982ee5d65604fa54822f Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/8U4NNmogW-w56wFJJR0hbqNYtVo Subject: [sipcore] Fwd: New Version Notification for draft-yusef-sipcore-sip-oauth-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2014 21:46:32 -0000 --047d7b3a982ee5d65604fa54822f Content-Type: text/plain; charset=ISO-8859-1 Hi, I have just submitted a draft that has some initial thoughts for an authorization framework for SIP that is based on OAuth. The draft is still missing lots of details, but I think it has enough information to allow us to start the discussion on the mailing list. We would appreciate it if people review the document and provide us with their thoughts. Regards, Rifaat ---------- Forwarded message ---------- From: Date: Mon, May 26, 2014 at 5:37 PM Subject: New Version Notification for draft-yusef-sipcore-sip-oauth-00.txt To: Victor Pascual , Rifaat Shekh-Yusef < rifaat.ietf@gmail.com> A new version of I-D, draft-yusef-sipcore-sip-oauth-00.txt has been successfully submitted by Rifaat Shekh-Yusef and posted to the IETF repository. Name: draft-yusef-sipcore-sip-oauth Revision: 00 Title: The Session Initiation Protocol (SIP) OAuth Document date: 2014-05-26 Group: Individual Submission Pages: 18 URL: http://www.ietf.org/internet-drafts/draft-yusef-sipcore-sip-oauth-00.txt Status: https://datatracker.ietf.org/doc/draft-yusef-sipcore-sip-oauth/ Htmlized: http://tools.ietf.org/html/draft-yusef-sipcore-sip-oauth-00 Abstract: The Session Initiation Protocol (SIP) uses a challenge-response framework to authenticate the user, but it does not have an authorization framework to control the user's access to various services in the system. This document defines an authorization framework for SIP that is based on the OAuth 2.0 framework. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --047d7b3a982ee5d65604fa54822f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

I have just submitted a draft that = has some initial thoughts for an authorization framework for SIP that is ba= sed on OAuth.
The draft is still missing lots of details, but I t= hink it has enough information to allow us to start the discussion on the m= ailing list.

We would appreciate it if people review the document an= d provide us with their thoughts.

Regards,
=A0Rifaat



--= -------- Forwarded message ----------
From: <internet-drafts@ietf.org>
= Date: Mon, May 26, 2014 at 5:37 PM
Subject: New Version Notification for= draft-yusef-sipcore-sip-oauth-00.txt
To: Victor Pascual <victor.= pascual@quobis.com>, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>



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

Name: =A0 =A0 =A0 =A0 =A0 draft-yusef-sipcore-sip-oauth
Revision: =A0 =A0 =A0 00
Title: =A0 =A0 =A0 =A0 =A0The Session Initiation Protocol (SIP) OAuth
Document date: =A02014-05-26
Group: =A0 =A0 =A0 =A0 =A0Individual Submission
Pages: =A0 =A0 =A0 =A0 =A018
URL: =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf.org= /internet-drafts/draft-yusef-sipcore-sip-oauth-00.txt
Status: =A0 =A0 =A0 =A0 https://datatracker.ietf.org/doc= /draft-yusef-sipcore-sip-oauth/
Htmlized: =A0 =A0 =A0 http://tools.ietf.org/html/draft-yusef= -sipcore-sip-oauth-00


Abstract:
=A0 =A0The Session Initiation Protocol (SIP) uses a challenge-response
=A0 =A0framework to authenticate the user, but it does not have an
=A0 =A0authorization framework to control the user's access to various<= br> =A0 =A0services in the system.

=A0 =A0This document defines an authorization framework for SIP that is
=A0 =A0based on the OAuth 2.0 framework.





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

The IETF Secretariat


--047d7b3a982ee5d65604fa54822f-- From nobody Wed May 28 04:55:58 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EAD51A00A6 for ; Wed, 28 May 2014 04:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Ikt4hQbXmyJ for ; Wed, 28 May 2014 04:55:55 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 137BA1A00A2 for ; Wed, 28 May 2014 04:55:54 -0700 (PDT) X-AuditID: c1b4fb30-f79a56d000006536-dd-5385cec5b785 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 3A.5F.25910.5CEC5835; Wed, 28 May 2014 13:55:50 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.173]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0174.001; Wed, 28 May 2014 13:55:49 +0200 From: Ivo Sedlacek To: "sipcore@ietf.org" Thread-Topic: Precondition and status confirmation in regular two party calls Thread-Index: Ac96Zajf1+EEuKX/StyoBSSQQDfk1Q== Date: Wed, 28 May 2014 11:55:48 +0000 Message-ID: <39B5E4D390E9BD4890E2B31079006101126DDBAB@ESESSMB301.ericsson.se> Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: multipart/alternative; boundary="_000_39B5E4D390E9BD4890E2B31079006101126DDBABESESSMB301erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+Jvje6xc63BBjMmsFh8/bGJzYHRY8mS n0wBjFFcNimpOZllqUX6dglcGZdeTWIsuG9esbFlPVsD4y/DLkZODgkBE4nuH7+ZIWwxiQv3 1rOB2EICRxkl1k9W6WLkArKXMEr8PLueBSTBJqAnMXHLEVYQW0RAU2L5t63sILawgIfE4nvf gGwOoLivRPcTaYgSPYmLW+cwgdgsAqoS0zZPARvDC1SycukBsFZGAVmJq396GUFsZgFxiVtP 5jNB3CMgsWTPeajbRCVePv7HCmErSrQ/bYCqz5do/zaNCWKmoMTJmU9YJjAKzUIyahaSsllI yiDiOhILdn9ig7C1JZYtfM0MY5858JgJWXwBI/sqRtHi1OKk3HQjI73Uoszk4uL8PL281JJN jMCIOLjlt8EOxpfPHQ8xCnAwKvHwLrjUEizEmlhWXJl7iFGag0VJnPeiRnWwkEB6Yklqdmpq QWpRfFFpTmrxIUYmDk6pBsYcNVGp3Lu6t5+WN55R2BVSbXWuoKX8yhnODK1kkR4+nqUZhUbL 7vb8ln8SuLdP0Ltw5xsTzstPBBXXf/fZXPJR94Dw3zvLd/KETSuaLzT948zNr5cdNBF19T7U rtlhrX/kzjTVzz2mDhOOMOSl5OXYNjtkqN5e5FBqfvx98nlR2wtsk6bI71ZiKc5INNRiLipO BAD5ZHgvaQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/215h-WuoK24h20GGRlPRARX5cy0 Subject: [sipcore] Precondition and status confirmation in regular two party calls X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 11:55:57 -0000 --_000_39B5E4D390E9BD4890E2B31079006101126DDBABESESSMB301erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, can you please help me with a one more question related to precondition han= dling in RFC3312? RFC3312 describes usage of confirm-status attribute - in summary, if a UA r= eceives the confirm-status attribute, the UA shall send UPDATE once the UA = finishes resource reservation. However, RFC3312 does not explicitly state anything about sending UPDATE if= the confirm-status attribute has NOT been received. If the UA does *NOT* r= eceive confirm-status attribute, and if the UA sent the UPDATE request once= the UA finishes resource reservation, it may cause unnecessary race condit= ions since both UAs can send UPDATEs at about the same time. Question: ----------- I assume that if a UA does *NOT* receive confirm-status attribute, then whe= n the UA finishes the resource reservation, the UA SHOULD NOT send UPDATE r= equest. Is this correct understanding? ----------- Thanks for clarification. Kind regards Ivo Sedlacek --_000_39B5E4D390E9BD4890E2B31079006101126DDBABESESSMB301erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

can you please help me with a one more qu= estion related to precondition handling in RFC3312?

 

RFC3312 describes usage of confirm-status= attribute - in summary, if a UA receives the confirm-status attribute, the= UA shall send UPDATE once the UA finishes resource reservation.

 

However, RFC3312 does not explicitly stat= e anything about sending UPDATE if the confirm-status attribute has NOT bee= n received. If the UA does *NOT* receive confirm-status attribute, and if the UA sent the UPDATE request once the UA finishes reso= urce reservation, it may cause unnecessary race conditions since both UAs c= an send UPDATEs at about the same time.

 

Question:

-----------

I assume that if a UA does *NOT* receive = confirm-status attribute, then when the UA finishes the resource reservatio= n, the UA SHOULD NOT send UPDATE request. Is this correct understanding?

-----------

 

Thanks for clarification.

 

Kind regards

 

Ivo Sedlacek

 

--_000_39B5E4D390E9BD4890E2B31079006101126DDBABESESSMB301erics_-- From nobody Wed May 28 11:32:00 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6C641A04A8 for ; Wed, 28 May 2014 11:31:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EC8WOVI9_ghP for ; Wed, 28 May 2014 11:31:57 -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 5785B1A01E1 for ; Wed, 28 May 2014 11:31:57 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta14.westchester.pa.mail.comcast.net with comcast id 7WSg1o0051ap0As5EWXtCf; Wed, 28 May 2014 18:31:53 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta22.westchester.pa.mail.comcast.net with comcast id 7WXt1o00Z1KKtkw3iWXttD; Wed, 28 May 2014 18:31:53 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s4SIVqfH026533; Wed, 28 May 2014 14:31:52 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s4SIVqf4026532; Wed, 28 May 2014 14:31:52 -0400 Date: Wed, 28 May 2014 14:31:52 -0400 Message-Id: <201405281831.s4SIVqf4026532@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Ivo Sedlacek In-reply-to: <39B5E4D390E9BD4890E2B31079006101126DDBAB@ESESSMB301.ericsson.se> (ivo.sedlacek@ericsson.com) References: <39B5E4D390E9BD4890E2B31079006101126DDBAB@ESESSMB301.ericsson.se> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1401301913; bh=Ui6BSA5MvkFFPLoUW5vB26i0GnI3eEy6I/KvsBluOQ0=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=tbXEgWNywr9gSQmN2hPykDoGTRLbQ9yt4DGUdKSayMGJ/TkWTw/jYIo5Vctlv4ubW PR8FIUKiK0bFrcTsqGPC/wZfjlyiNcnG0xN9SVqRR/PC4G81IPcNIgAhlATFxKD4YV TqF3nfEXND33Zo4J+5n0O3iDjQ1YCsjM6VkAVQzdvJ2+/yAP4AV3VaSD1h2mAoIYlz UqJv0AVLp72R93eQ1pyQFrtvty2m3ebzbXlnDXJtlDfRZv36YDFaM7U5hFcpzSMp/G jMP7FAo0V5JiZZeX0JfaY0XGTZdHKYx+Pck7/Gz3wcJIN0yjTKDSSurXIR4IkzRUgK emRtC9i84jS6w== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/MA-xTN5Kp6j_1NAfifcyp1ZUu5U Cc: sipcore@ietf.org Subject: Re: [sipcore] Precondition and status confirmation in regular two party calls X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 18:31:59 -0000 > From: Ivo Sedlacek > However, RFC3312 does not explicitly state anything about sending > UPDATE if the confirm-status attribute has NOT been received. If the > UA does *NOT* receive confirm-status attribute, and if the UA sent > the UPDATE request once the UA finishes resource reservation, it may > cause unnecessary race conditions since both UAs can send UPDATEs at > about the same time. The handling of race conditions regarding UPDATE is described in RFC 3331 section 5.2: A UAS that receives an UPDATE before it has generated a final response to a previous UPDATE on the same dialog MUST return a 500 response to the new UPDATE, and MUST include a Retry-After header field with a randomly chosen value between 0 and 10 seconds. If an UPDATE is received that contains an offer, and the UAS has generated an offer (in an UPDATE, PRACK or INVITE) to which it has not yet received an answer, the UAS MUST reject the UPDATE with a 491 response. Similarly, if an UPDATE is received that contains an offer, and the UAS has received an offer (in an UPDATE, PRACK, or INVITE) to which it has not yet generated an answer, the UAS MUST reject the UPDATE with a 500 response, and MUST include a Retry-After header field with a randomly chosen value between 0 and 10 seconds. [...] > Question: > ----------- > I assume that if a UA does *NOT* receive confirm-status attribute, > then when the UA finishes the resource reservation, the UA SHOULD > NOT send UPDATE request. Is this correct understanding? > ----------- In principle, a UA can send an UPDATE at any time when it is not forbidden to. RFC 3311 section 5.1 gives some guidelines: The UPDATE request is constructed as would any other request within an existing dialog, as described in Section 12.2.1 of RFC 3261. It MAY be sent for both early and confirmed dialogs, and MAY be sent by either caller or callee. Although UPDATE can be used on confirmed dialogs, it is RECOMMENDED that a re-INVITE be used instead. This is because an UPDATE needs to be answered immediately, ruling out the possibility of user approval. Such approval will frequently be needed, and is possible with a re-INVITE. Dale From nobody Wed May 28 17:22:46 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B57671A079C; Wed, 28 May 2014 17:22:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ja987On89qWW; Wed, 28 May 2014 17:22:33 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id 655F31A0704; Wed, 28 May 2014 17:22:33 -0700 (PDT) Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-pink.research.att.com (Postfix) with ESMTP id 8B322120AC1; Wed, 28 May 2014 20:24:41 -0400 (EDT) Received: from njfpsrvexg8.research.att.com (unknown [135.207.255.243]) by mail-blue.research.att.com (Postfix) with ESMTP id 4A5FEF03C9; Wed, 28 May 2014 20:22:29 -0400 (EDT) Received: from NJFPSRVEXG8.research.att.com ([fe80::cdea:b3f6:3efa:1841]) by njfpsrvexg8.research.att.com ([fe80::cdea:b3f6:3efa:1841%13]) with mapi; Wed, 28 May 2014 20:22:29 -0400 From: "MORTON, ALFRED C (AL)" To: "bmwg@ietf.org" , "sipcore@ietf.org" Date: Wed, 28 May 2014 20:22:28 -0400 Thread-Topic: WGLC: draft-ietf-bmwg-sip-bench-term and -meth Thread-Index: AQHPetQS55DhwGs0jEa+XkhR9eDGMw== Message-ID: <2845723087023D4CB5114223779FA9C80178E0CD8C@njfpsrvexg8.research.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/gBSfs-H0egnUICvr3ShM8GtkqAc Subject: [sipcore] WGLC: draft-ietf-bmwg-sip-bench-term and -meth X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 00:22:39 -0000 BMWG (and SIPCORE): A WG Last Call period for the Internet-Drafts on SIP Device Benchmarking: http://datatracker.ietf.org/doc/draft-ietf-bmwg-sip-bench-term/ http://datatracker.ietf.org/doc/draft-ietf-bmwg-sip-bench-meth/ will be open from 28 May 2014 through 11 June 2014. These drafts are continuing the BMWG Last Call Process. See http://www1.ietf.org/mail-archive/web/bmwg/current/msg00846.html The first WGLC was completed on 5 April 2010 with comments. The second WGLC was completed on 18 May 2012 with comments. The third WGLC was completed on 10 Dec 2012 with comments. An IETF Last Call followed, and completed on 30 Jan 2013 with comments. Please read and express your opinion on whether or not these Internet-Drafts should be forwarded to the Area Directors for publication as Informational RFCs. Send your comments to this list or acmorton@att.com and sbanks@akamai.com Al bmwg co-chair = From nobody Thu May 29 06:51:08 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E42671A0933 for ; Thu, 29 May 2014 06:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.579 X-Spam-Level: X-Spam-Status: No, score=-3.579 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RneE7rpjTGkk for ; Thu, 29 May 2014 06:51:03 -0700 (PDT) Received: from psmtp.com (na3sys009aob139.obsmtp.com [74.125.149.251]) by ietfa.amsl.com (Postfix) with SMTP id 60F911A091C for ; Thu, 29 May 2014 06:51:03 -0700 (PDT) Received: from mail-wi0-f172.google.com ([209.85.212.172]) (using TLSv1) by na3sys009aob139.postini.com ([74.125.148.12]) with SMTP ID DSNKU4c7Q3eBZQ2hqD3F2/jDwfWiBvVAHMEQ@postini.com; Thu, 29 May 2014 06:51:00 PDT Received: by mail-wi0-f172.google.com with SMTP id hi2so5677692wib.5 for ; Thu, 29 May 2014 06:50:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Qf4vU/32LP8JGGV+5BfnZg6Go4rHvXe1PXnnTHxYvsU=; b=eNqjisMgzTDSdNCbOhiO4vfAL1bJaxCnukyHu1NViA0kzgf0tdIBTe1D/7r5bKwz6L m0yuu5mM8lTaB0s71AjzB9uB3AHBKGtGvXreo2qXAFNsGHyV8OBwkK0zvW5Wj+ODDTD2 CZgW2i/YkBV40Yu0RJM7gMTGKKOBuUWJ/OpbU+ii227djFg5pnullLyhUVbsr/2gH/dA ULFYngsVqV4e8jjS+7XXwAjBkdIjESFlcpncD4qCaZPnjoYGJ5vaEk3mMKf7qANa3DXw hsqg7L5ZXZQgXqngXKl6KdbqcVya1FqCDv3mRMmS6epgeDWIKED/2JcRS+pJ4FWorL4G TfVw== X-Gm-Message-State: ALoCoQnNcYdz+4f/9eNavrXY8DQWhWY+JlhpDLpu3vooxJRM8UPXojFDRECSqdmZ9Hwl0CsUzOcl+DprhMBWr7PbyWIihjmg+8Em9avCptIHtatYAeMdA9B1uy0gJIf78QmY0R/1w+Uw X-Received: by 10.194.8.229 with SMTP id u5mr10759500wja.65.1401371458053; Thu, 29 May 2014 06:50:58 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.8.229 with SMTP id u5mr10759475wja.65.1401371457885; Thu, 29 May 2014 06:50:57 -0700 (PDT) Received: by 10.194.190.8 with HTTP; Thu, 29 May 2014 06:50:57 -0700 (PDT) In-Reply-To: References: Date: Thu, 29 May 2014 14:50:57 +0100 Message-ID: From: Michael Procter To: Rifaat Shekh-Yusef Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/qwFMXBbqo075tSJCJBP9HlyDR4c Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Fwd: New Version Notification for draft-yusef-sipcore-sip-oauth-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 13:51:06 -0000 Hi Rifaat, On 26 May 2014 22:46, Rifaat Shekh-Yusef wrote: > We would appreciate it if people review the document and provide us with > their thoughts. Would you be able to provide a couple of motivating use cases? The ones I've come up with either aren't fully met by the outlines in this document, or might be achieved more easily with existing pieces of protocol. A couple of typos: Section 1, last paragraph: "Single Sing-On" should be "Single Sign-On" Section 3.4, last paragraph: "with toke, token refresh, and the master-key" should be "with token, refresh_token, and the master-key" Regards, Michael From nobody Thu May 29 07:33:32 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4C171A098B for ; Thu, 29 May 2014 07:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XBGJkm_0ggUi for ; Thu, 29 May 2014 07:33:29 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAE7A1A094E for ; Thu, 29 May 2014 07:33:28 -0700 (PDT) X-AuditID: c1b4fb30-f79a56d000006536-5c-53874533eb5d Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 39.F3.25910.33547835; Thu, 29 May 2014 16:33:23 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.173]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0174.001; Thu, 29 May 2014 16:33:22 +0200 From: Ivo Sedlacek To: "Dale R. Worley" Thread-Topic: [sipcore] Precondition and status confirmation in regular two party calls Thread-Index: AQHPeqMZ2vpklsp7EkukvXxbyikpPZtXnK2Q Date: Thu, 29 May 2014 14:33:22 +0000 Message-ID: <39B5E4D390E9BD4890E2B31079006101126DE833@ESESSMB301.ericsson.se> References: <39B5E4D390E9BD4890E2B31079006101126DDBAB@ESESSMB301.ericsson.se> <201405281831.s4SIVqf4026532@hobgoblin.ariadne.com> In-Reply-To: <201405281831.s4SIVqf4026532@hobgoblin.ariadne.com> Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyM+Jvja6xa3uwwfxb8hZff2xis3h5osyB yWPy/q/MHkuW/GQKYIrisklJzcksSy3St0vgypj58ClrwSHZik/HtzI1MK4X72Lk5JAQMJH4 +LKNBcIWk7hwbz1bFyMXh5DAUUaJh1uuM0E4SxglXq3rZAepYhPQk5i45QhrFyMHh4iApkTH ghyQMDOQ+WjnXiYQW1ggQmLviftMECWREl8XaYOERQSMJC5s+QZWwiKgKrG6dxkziM0r4Ctx 5eZKRohVzYwSk6b8YwNJcAo4SCxaeQmsiFFAVuLqn15GiF3iEreezGeCOFpAYsme88wQtqjE y8f/WCFsRYn2pw1Q9XoSz07NYoGwtSWWLXwNtVhQ4uTMJywTGMVmIRk7C0nLLCQts5C0LGBk WcUoWpxanJSbbmSkl1qUmVxcnJ+nl5dasokRGD0Ht/w22MH48rnjIUYBDkYlHl4FlbZgIdbE suLK3EOM0hwsSuK8FzWqg4UE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwaq3sXsqV8NjdNml/ QumJxVO5dsbJi9Z/P7YlfMX6atWFPRkbPz4pLufZ5vAqdEJNSdJr39Z+Z7ZnB2byfF/edMh3 oUyl1yXWuq1GaYYqXB+9kkI4FxVfKd1SXuppuNN/8sbLsgxRLxzfRiatuVA7fee0MwL3Dedf mrCj3PjAFKcFdiFV/ZX8SizFGYmGWsxFxYkA5ABrc38CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/8ilufV7abTlFTlZIkwnN9iRDp0Y Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Precondition and status confirmation in regular two party calls X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 14:33:30 -0000 Hello, The issue is not the race condition as such. As you say, UPDATE is allowed= to be sent at any time and there are procedures to handle UPDATEs being se= nt by both UAs at about the same time. The question was rather: Is it advisable for a UA to send an UPDATE indicat= ing that its resources are available if confirm-status attribute was *NOT* = received? Sending such non-requested UPDATE can generate unnecessary signalling (if b= oth UAs reserve resources at about the same time, both UAs send UPDATE at a= bout the same time and 491 would be generated) and call setup delay (since = at last one of the UPDATEs will need to be repeated). The whole reason for the confirm-status attribute is to request a confirmat= ion when resources becomes available. So if the confirm-status attribute is= *NOT* present, when resources becomes available, a UA should refrain from = sending UPDATE (unless there is another reason, not related to resource res= ervation, for doing so). Do you agree? Kind regards Ivo Sedlacek This Communication is Confidential. We only send and receive email on the b= asis of the terms set out at www.ericsson.com/email_disclaimer=20 -----Original Message----- From: Dale R. Worley [mailto:worley@ariadne.com]=20 Sent: 28. kv=ECtna 2014 20:32 To: Ivo Sedlacek Cc: sipcore@ietf.org Subject: Re: [sipcore] Precondition and status confirmation in regular two = party calls > From: Ivo Sedlacek > However, RFC3312 does not explicitly state anything about sending=20 > UPDATE if the confirm-status attribute has NOT been received. If the=20 > UA does *NOT* receive confirm-status attribute, and if the UA sent the=20 > UPDATE request once the UA finishes resource reservation, it may cause=20 > unnecessary race conditions since both UAs can send UPDATEs at about=20 > the same time. The handling of race conditions regarding UPDATE is described in RFC 3331 section 5.2: A UAS that receives an UPDATE before it has generated a final response to a previous UPDATE on the same dialog MUST return a 500 response to the new UPDATE, and MUST include a Retry-After header field with a randomly chosen value between 0 and 10 seconds. If an UPDATE is received that contains an offer, and the UAS has generated an offer (in an UPDATE, PRACK or INVITE) to which it has not yet received an answer, the UAS MUST reject the UPDATE with a 491 response. Similarly, if an UPDATE is received that contains an offer, and the UAS has received an offer (in an UPDATE, PRACK, or INVITE) to which it has not yet generated an answer, the UAS MUST reject the UPDATE with a 500 response, and MUST include a Retry-After header field with a randomly chosen value between 0 and 10 seconds. [...] > Question: > ----------- > I assume that if a UA does *NOT* receive confirm-status attribute,=20 > then when the UA finishes the resource reservation, the UA SHOULD NOT=20 > send UPDATE request. Is this correct understanding? > ----------- In principle, a UA can send an UPDATE at any time when it is not forbidden = to. RFC 3311 section 5.1 gives some guidelines: The UPDATE request is constructed as would any other request within an existing dialog, as described in Section 12.2.1 of RFC 3261. It MAY be sent for both early and confirmed dialogs, and MAY be sent by either caller or callee. Although UPDATE can be used on confirmed dialogs, it is RECOMMENDED that a re-INVITE be used instead. This is because an UPDATE needs to be answered immediately, ruling out the possibility of user approval. Such approval will frequently be needed, and is possible with a re-INVITE. Dale From nobody Thu May 29 07:59:03 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A39EE1A073E for ; Thu, 29 May 2014 07:59:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jgRKBM25mF-0 for ; Thu, 29 May 2014 07:59:00 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C29751A0960 for ; Thu, 29 May 2014 07:58:59 -0700 (PDT) X-AuditID: c1b4fb30-f79a56d000006536-2f-53874b2e78d0 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 63.96.25910.E2B47835; Thu, 29 May 2014 16:58:54 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.173]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0174.001; Thu, 29 May 2014 16:58:54 +0200 From: Ivo Sedlacek To: Ivo Sedlacek , "Dale R. Worley" Thread-Topic: [sipcore] Precondition and status confirmation in regular two party calls Thread-Index: AQHPeqMZ2vpklsp7EkukvXxbyikpPZtXnK2QgAAJwgA= Date: Thu, 29 May 2014 14:58:53 +0000 Message-ID: <39B5E4D390E9BD4890E2B31079006101126DE88C@ESESSMB301.ericsson.se> References: <39B5E4D390E9BD4890E2B31079006101126DDBAB@ESESSMB301.ericsson.se> <201405281831.s4SIVqf4026532@hobgoblin.ariadne.com> <39B5E4D390E9BD4890E2B31079006101126DE833@ESESSMB301.ericsson.se> In-Reply-To: <39B5E4D390E9BD4890E2B31079006101126DE833@ESESSMB301.ericsson.se> Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyM+Jvja6ed3uwwcLXqhZff2xis3h5osyB yWPy/q/MHkuW/GQKYIrisklJzcksSy3St0vgynjU3sla0CJXsX3yV8YGxo/iXYycHBICJhJn j91mhLDFJC7cW8/WxcjFISRwlFFi1dKb7BDOEkaJLfcawarYBPQkJm45wgpiiwiESmx9dpUZ xGYW0JR4tHMvE4gtLBAhsffEfSCbA6gmUuLrIm2IciuJ108/soDYLAKqEi17PrKD2LwCvhK7 7m1lgth1nFHiUetksJmcAn4Say88AStiFJCVuPqnlxFil7jErSfzmSCuFpBYsuc8M4QtKvHy 8T9WCFtRov1pA1S9nsSzU7NYIGxtiWULXzNDLBaUODnzCcsERrFZSMbOQtIyC0nLLCQtCxhZ VjGKFqcWJ+WmGxnppRZlJhcX5+fp5aWWbGIExs/BLb8NdjC+fO54iFGAg1GJh1dBpS1YiDWx rLgy9xCjNAeLkjjvRY3qYCGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2MrYrl+2b0ff1rYbhj 6d6A1yWP5tkdeaL/wFzI9CC3l42D7rVb+Z9uvD/+K+Ka9WrtpPZHM47rr+BLtjoSeHlPd7Dm R8P/AgV3fRpe/o/U/D7rq8KZvwkt8ze++XRNJ+Dq1fdv61a+SqozcH+rzvxL783dez6X593R zb1j8M3jjGXJovD+ZPVNJkosxRmJhlrMRcWJAEGjsPeAAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/JpJ3p6HzZ8IbYmXgebehHWDfzgs Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Precondition and status confirmation in regular two party calls X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 14:59:01 -0000 (minor reformulation below, sorry about being sloppy). Hello, The issue is not the race condition as such. As you say, UPDATE is allowed= to be sent at any time and there are procedures to handle UPDATEs being se= nt by both UAs at about the same time. The question was rather: Is it advisable for a UA to send an UPDATE indicat= ing that its resources are available if confirm-status attribute was *NOT* = received? Sending such non-requested UPDATE can generate unnecessary signalling (if b= oth UAs reserve resources at about the same time, both UAs send UPDATE at a= bout the same time and 491 would be generated) and call setup delay (since = at last one of the UPDATEs will need to be repeated). The whole reason for the confirm-status attribute is to request a confirmat= ion when resources becomes available. So if UA has *NOT* received the confi= rm-status attribute, then when resources of the UA becomes available, the U= A should refrain from sending UPDATE (unless there is another reason, not r= elated to resource reservation, for doing so). Do you agree? Kind regards Ivo Sedlacek -----Original Message----- From: Dale R. Worley [mailto:worley@ariadne.com] Sent: 28. kv=ECtna 2014 20:32 To: Ivo Sedlacek Cc: sipcore@ietf.org Subject: Re: [sipcore] Precondition and status confirmation in regular two = party calls > From: Ivo Sedlacek > However, RFC3312 does not explicitly state anything about sending=20 > UPDATE if the confirm-status attribute has NOT been received. If the=20 > UA does *NOT* receive confirm-status attribute, and if the UA sent the=20 > UPDATE request once the UA finishes resource reservation, it may cause=20 > unnecessary race conditions since both UAs can send UPDATEs at about=20 > the same time. The handling of race conditions regarding UPDATE is described in RFC 3331 section 5.2: A UAS that receives an UPDATE before it has generated a final response to a previous UPDATE on the same dialog MUST return a 500 response to the new UPDATE, and MUST include a Retry-After header field with a randomly chosen value between 0 and 10 seconds. If an UPDATE is received that contains an offer, and the UAS has generated an offer (in an UPDATE, PRACK or INVITE) to which it has not yet received an answer, the UAS MUST reject the UPDATE with a 491 response. Similarly, if an UPDATE is received that contains an offer, and the UAS has received an offer (in an UPDATE, PRACK, or INVITE) to which it has not yet generated an answer, the UAS MUST reject the UPDATE with a 500 response, and MUST include a Retry-After header field with a randomly chosen value between 0 and 10 seconds. [...] > Question: > ----------- > I assume that if a UA does *NOT* receive confirm-status attribute,=20 > then when the UA finishes the resource reservation, the UA SHOULD NOT=20 > send UPDATE request. Is this correct understanding? > ----------- In principle, a UA can send an UPDATE at any time when it is not forbidden = to. RFC 3311 section 5.1 gives some guidelines: The UPDATE request is constructed as would any other request within an existing dialog, as described in Section 12.2.1 of RFC 3261. It MAY be sent for both early and confirmed dialogs, and MAY be sent by either caller or callee. Although UPDATE can be used on confirmed dialogs, it is RECOMMENDED that a re-INVITE be used instead. This is because an UPDATE needs to be answered immediately, ruling out the possibility of user approval. Such approval will frequently be needed, and is possible with a re-INVITE. Dale _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From nobody Thu May 29 10:45:58 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D80801A01A0 for ; Thu, 29 May 2014 10:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ttYmh24elI6 for ; Thu, 29 May 2014 10:45:56 -0700 (PDT) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A575A1A018A for ; Thu, 29 May 2014 10:45:56 -0700 (PDT) Received: by mail-ig0-f173.google.com with SMTP id hn18so4067708igb.12 for ; Thu, 29 May 2014 10:45:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DB6LrUTU+82uWEkmTSKOVuRH6WripmLUlc3VITKjOeg=; b=xCvYm2IfDYD5McaDtLksrorX61VduHl168gfig/DU4fS7Nix09UCSWHLfAM06Pm8yU 2N2eP55oaKOyN/nW2R0QQSZla6ksCC4aBNWLaodXqRJCXMBq8/1CED7K6Cw6AfiAfj1S CZH8EgWhoXh/I1dLyPCq81jBxtZJuCzP3mxcL9a/TxpywwfUr7Z6b7kBdm9/YvEZddzP RQEZZ3cGQRmqUwIr5H65YZUk9w1QC1quxUJy35E3KEGMZjKqcVyv7JjwlOOi05EKS1cx HZs0+7TJbPx5DBMYYS0KWlgtoMKY6UsQAPkU4IGv5lASm8Sv2u2N6GzzxlAH7a64c9Op mCMg== MIME-Version: 1.0 X-Received: by 10.42.120.15 with SMTP id d15mr9453408icr.35.1401385552507; Thu, 29 May 2014 10:45:52 -0700 (PDT) Received: by 10.50.111.170 with HTTP; Thu, 29 May 2014 10:45:52 -0700 (PDT) In-Reply-To: References: Date: Thu, 29 May 2014 13:45:52 -0400 Message-ID: From: Rifaat Shekh-Yusef To: Michael Procter Content-Type: multipart/alternative; boundary=90e6ba613c3a0cf91404fa8d80a3 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/9ZfbRDCzqORf7OeZ1Yu7TW4UmqQ Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Fwd: New Version Notification for draft-yusef-sipcore-sip-oauth-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 17:45:58 -0000 --90e6ba613c3a0cf91404fa8d80a3 Content-Type: text/plain; charset=ISO-8859-1 Hi Michael, Thanks for the review and feedback. Sure, I will add a section to talk about uses cases. Would you be able to share your use cases to see if we can cover them in this document? Thanks, Rifaat On Thu, May 29, 2014 at 9:50 AM, Michael Procter wrote: > Hi Rifaat, > > On 26 May 2014 22:46, Rifaat Shekh-Yusef wrote: > > We would appreciate it if people review the document and provide us with > > their thoughts. > > Would you be able to provide a couple of motivating use cases? The > ones I've come up with either aren't fully met by the outlines in this > document, or might be achieved more easily with existing pieces of > protocol. > > A couple of typos: > Section 1, last paragraph: > "Single Sing-On" should be "Single Sign-On" > > Section 3.4, last paragraph: > "with toke, token refresh, and the master-key" > should be > "with token, refresh_token, and the master-key" > > Regards, > > Michael > --90e6ba613c3a0cf91404fa8d80a3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Michael,

Thanks for the review and f= eedback.

Sure, I will add a section to talk about = uses cases.
Would you be able to share your use cases to see if w= e can cover them in this document?

Thanks,
=A0Rifaat

<= div class=3D"gmail_extra">

On Thu, May 29= , 2014 at 9:50 AM, Michael Procter <michael@voip.co.uk> wro= te:
Hi Rifaat,

On 26 May 2014 22:46, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
> We would appreciate it if people review the document and provide us wi= th
> their thoughts.

Would you be able to provide a couple of motivating use cases? =A0The=
ones I've come up with either aren't fully met by the outlines in t= his
document, or might be achieved more easily with existing pieces of
protocol.

A couple of typos:
Section 1, last paragraph:
"Single Sing-On" should be "Single Sign-On"

Section 3.4, last paragraph:
"with toke, token refresh, and the master-key"
should be
"with token, refresh_token, and the master-key"

Regards,

Michael

--90e6ba613c3a0cf91404fa8d80a3-- From nobody Fri May 30 07:28:29 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF9681A0911; Fri, 30 May 2014 07:28:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QInsDuiKo73Y; Fri, 30 May 2014 07:28:23 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F5511A0901; Fri, 30 May 2014 07:28:22 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id bs8so1250123wib.6 for ; Fri, 30 May 2014 07:28:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EhdaMli6ItsBkZDhY51nUPfK+aRLzl3xlGcING2sDM4=; b=GbMtDjAF6mxHBWt3ITorkOzFiGPXp1pQT740HHKsF0dUQm9hxd7eRrVhWvAeMMHuUS mUHrIeX3jcsryH+4e2q7F7q50mC7/H3iPm+c+G64kbbxNZm6pnoBczpGB7GDNHCRuaZj iOe9l7dcIWHBCE037cy7i3EpieLxbT6TmN59/qqq6WQzY+kqVo53ZcHwqFJ2pPfuVn9l BLQuMc2rkxYRRhBeJs+SUqYp0Wdmu9vw/tCUljgHGrjgb73n4zzTNiT2vMwZ/Ym9RQjX f3jAgztq8cIebc65hbmGlRqhTOoj4d5Qu4ASomZ5i555hJMIa3+C5kB8s0Y65mkUPNkU Od6Q== MIME-Version: 1.0 X-Received: by 10.194.184.179 with SMTP id ev19mr22669867wjc.85.1401460095782; Fri, 30 May 2014 07:28:15 -0700 (PDT) Received: by 10.216.202.74 with HTTP; Fri, 30 May 2014 07:28:15 -0700 (PDT) In-Reply-To: <53862503.2a108c0a.3b2d.60c4SMTPIN_ADDED_BROKEN@mx.google.com> References: <53862503.2a108c0a.3b2d.60c4SMTPIN_ADDED_BROKEN@mx.google.com> Date: Fri, 30 May 2014 09:28:15 -0500 Message-ID: From: Mary Barnes To: DISPATCH Content-Type: multipart/alternative; boundary=047d7b87371e2d155a04fa9edb53 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/rNpDoKdQVkpxALdM18bDxmLgZ1Q Cc: SIPCORE Subject: [sipcore] Fwd: [SIPForum-techwg] SIPNOC 2014: Only Two Weeks Away! X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 14:28:26 -0000 --047d7b87371e2d155a04fa9edb53 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'm forwarding this as I believe the event is quite relevant for a lot of folks on this list. If your schedule allows I think you'll find a lot of the topics to be of interest. Regards, Mary. ---------- Forwarded message ---------- From: Marc Robins Date: Wed, May 28, 2014 at 1:00 PM Subject: [SIPForum-techwg] SIPNOC 2014: Only Two Weeks Away! To: techwg@sipforum.org [image: Introducing SIPNOC - The SIP Network Operators Conference] *PLATINUM SPONSORS* [image: Image] *GOLD SPONSORS * [image: Image] [image: Image] [image: Image] [image: Image] *POWERSTATION SPONSORS* [image: Image] Two-Weeks Till SIPNOC 2014! Don=E2=80=99t Miss the Opportunity to Network with Some of the IP Communica= tions Industry=E2=80=99s Best and Brightest! Now in its fourth year, *SIPNOC 2014* is a unique educational conference for international telecom stakeholders responsible for the deployment, management and ongoing operation of SIP-based services in service provider networks. Come meet the engineering talent from service providers of all sizes, leading equipment vendors, and the brightest minds doing academic research. *Symposium Atmosphere, Absent of Marketing Spin* This is not a marketing meeting full of vendor sales pitches. It's about real-world problems and how the technical community is solving them. *Learn how to* *avoid problems before you even encounter them.* Attending service providers have included AT&T, Armstrong Utilities, babyTEL, Bandwidth.com, Bell Canada, Bright House Networks, Broadvox, Cablevision, Cbeyond, Cinchcast, Cincinnati Bell, Comcast Cable, Cologix, Consolidated Telecom, Cox Communications, Deutche Telecom, France Telecom Orange, Global Crossing, Grandstream Networks, iBasis, Level3, Liveops, nexVortex, NTT, One Source Networks, Optimum Lightpath, Purple Communications, Rogers Business Solutions, Shoretel, Socket Telecom, Sorenson Communications, Sprint, Swisscom, TDS Telecom, Time Warner Cable, Telefonica International, Telmex, UNINETT, Verizon, Vocalocity, Vonage, Voxbone, WDT (World Discount Telecommunications), Wholesale Carrier Services, XO Communications, and Ziggo. In addition to carrier participants, SIPNOC regularly attracts a group of SIP community stakeholders from vendors, governments and research organizations such as AudioCodes, Avaya, Broadsoft, CableLabs, Cequint, Cisco Systems, Commetrex, Current Analysis, Dialogic, ECG Inc, Edgewater Networks, Ericsson, Faxcore, Federal Communications Commission, GENBAND, Georgetown University, Huawei Technologies, iconectiv, Integrated Research, Internet Society (ISOC), Metaswitch Networks, NENA, NetNumber, NTCA, Oracle, Patton Electronics, Polycom, Public Knowledge, RecordMyCalls, Sangoma Technologies, Sansay, SecureLogix, ScanSource, SNOM Technology, Sonus Networks, UNH-IOL, Unify, and Yealink Network Technology. You can review the *SIPNOC 2014 conference schedule * and list of presenters now. Speakers will explore critical =E2=80=9Creal-world=E2=80=9D service provide= r challenges related to SIP applications and infrastructure, including: network security, SIP trunking, testing and application development, Fax over IP, call routing and peering, IPv6, troubleshooting and monitoring, emergency services and more. *SIPNOC 2014 Registration Information* For a limited time, you can take advantage of a special discounted rate of $895, a savings of $100 off the regular rate. To obtain the discount, enter the following code on the registration page: =E2=80=9Csipnoctmc100=E2=80=9D= . Your registration includes access to all conference sessions, keynotes, meals and breaks, plus networking receptions each evening. *To register for SIPNOC 2014, please visit http://www.regonline.com/sipnoc2014 .* *Don't Forget!* Individuals from SIP Forum Full Member companies save even more! Please contact Marc Robins, SIP Forum President and Managing Director, at marc.robins@sipforum.org to obtain the exclusive Full Member discount code. *Hotel Reservations* SIPNOC 2014 is located at the four-star Hyatt Dulles Hotel. To reserve your stay at the Hyatt Dulles, please visit: https://resweb.passkey.com/go/SIPNOC2014 *For more information, please visit:www.sipnoc.org or email sipnocinfo@sipforum.org * _______________________________________________ techwg mailing list Send mail to: techwg@sipforum.org Unsubscribe or edit options at: http://sipforum.org/mailman/listinfo/techw= g --047d7b87371e2d155a04fa9edb53 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm forwarding this as I believe the event is quite re= levant for a lot of folks on this list. =C2=A0If your schedule allows I thi= nk you'll find a lot of the topics to be of interest.

Regards,
Mary.=C2=A0

---------- Forwarded mes= sage ----------
From: Marc Robins <marc.robins@s= ipforum.org>
Date: Wed, May 28, 2014 at 1:00 PM
Subject: [SIPForum-techwg] SIPNOC 201= 4: Only Two Weeks Away!
To: techw= g@sipforum.org


=C2=A0

<= table border=3D"0" cellspacing=3D"0" cellpadding=3D"0" width=3D"650" style= =3D"width:487.5pt;background:white">

3D"Introducing

=

=

=

= =

=

3D"Image"=

PLATINUM SPONSORS

GOLD SPONSORS <= u>

3D"=

3D"I=

3D"I=

3D"Image"

POWERST= ATION SPONSORS

3D"Image=

= Two-Weeks Till SIPNOC = 2014!

Don=E2=80=99t Miss the Opportunity to= Network with Some of the IP Communications Industry=E2=80=99s Best and Bri= ghtest!

Now in its fourth year, SIPNOC 2014 is a unique educational conference for international telecom stakeholder= s responsible for the deployment, management and ongoing operation of SIP-b= ased services in service provider networks. =C2=A0Come meet the engineering= talent from service providers of all sizes, leading equipment vendors, and the brightest minds doing academic= research.

Symposium Atmosphere, Absent of Marketing Spin
=
This is not a marketing meeting full of vendor sales=C2=A0pitches. It&#= 39;s about real-world problems and how the technical community is solving t= hem.=C2=A0Learn how to=C2=A0avoid problems=C2=A0before you even= encounter them.

Attending service providers have included AT&T, Armstrong Utilities= , babyTEL, Bandwidth.com, Bell Canada, Bright House Networks, Broadvox, Cab= levision, Cbeyond, Cinchcast, Cincinnati Bell, Comcast Cable, Cologix, Cons= olidated Telecom, Cox Communications, Deutche Telecom, France Telecom Orang= e, Global Crossing, Grandstream Networks, iBasis, Level3, Liveops,=C2=A0 ne= xVortex, NTT, One Source Networks, Optimum Lightpath, Purple Communications= , Rogers Business Solutions, Shoretel, Socket Telecom, Sorenson Communicati= ons, Sprint, Swisscom, TDS Telecom, Time Warner Cable, Telefonica Internati= onal, Telmex, UNINETT, Verizon, Vocalocity, Vonage, Voxbone, WDT (World Dis= count Telecommunications), Wholesale Carrier Services, XO Communications, a= nd Ziggo.

In addition to carrier participants, SIPNOC regularly attracts a group = of SIP community stakeholders from vendors, governments and research organi= zations such as AudioCodes, Avaya, Broadsoft, CableLabs, Cequint, Cisco Sys= tems, Commetrex, Current Analysis, Dialogic, ECG Inc, Edgewater Networks, E= ricsson, Faxcore, Federal Communications Commission, GENBAND, Georgetown Un= iversity, Huawei Technologies, iconectiv, Integrated Research, Internet Soc= iety (ISOC), Metaswitch Networks, NENA, NetNumber, NTCA, Oracle, Patton Ele= ctronics, Polycom, Public Knowledge, RecordMyCalls, Sangoma Technologies, S= ansay, SecureLogix, ScanSource, SNOM Technology, Sonus Networks, UNH-IOL,= =C2=A0 Unify, and Yealink Network Technology.

You can review the SIPNOC 2014 conference schedule and list of presenters= now. Speakers will explore critical =E2=80=9Creal-world=E2=80=9D service p= rovider challenges related to SIP applications and infrastructure, includin= g: network security, SIP trunking, testing and application development, Fax= over IP, call routing and peering, IPv6, troubleshooting and monitoring, e= mergency services and more.

SIPNOC 2014 Registration Information
For = a limited time, you can take advantage of a special discounted rate of $895= , a savings of $100 off the regular rate. To obtain the discount, enter the= following code on the registration page: =E2=80=9Csipnoctmc100=E2=80=9D. Y= our registration includes access to all conference sessions, keynotes, meal= s and breaks, plus networking receptions each evening.

To register for SIPNOC 2014, please visit http= ://www.regonline.com/sipnoc2014.

Don't Forget!
Individuals fro= m SIP Forum Full Member companies save even more! Please contact Marc Robin= s, SIP Forum President and Managing Director, at marc.robi= ns@sipforum.org to obtain the exclusive Full Member discount cod= e.

Hotel Reservations
SIPNOC 2014 is located= at the four-star Hyatt Dulles Hotel. To reserve your stay at the Hyatt Dul= les, please visit: https://resweb.passkey.com/go/= SIPNOC2014

=

For more information, please visit:
www.sipnoc.org or email sipnocinfo@sipfor= um.org

= =


_______________________________________________
techwg mailing list
Send mail to: techwg@sipforum.org
Unsubscribe or edit options at: =C2=A0http://sipforum.org/mailman/listinfo/t= echwg


--047d7b87371e2d155a04fa9edb53-- From nobody Fri May 30 12:14:43 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FBB71A8035 for ; Fri, 30 May 2014 12:14:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uKVGlRL1luSs for ; Fri, 30 May 2014 12:14:39 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 6F6EE1A7029 for ; Fri, 30 May 2014 12:14:39 -0700 (PDT) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta02.westchester.pa.mail.comcast.net with comcast id 8Jny1o0051GhbT851KEbJ2; Fri, 30 May 2014 19:14:35 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta07.westchester.pa.mail.comcast.net with comcast id 8KEa1o00B1KKtkw3TKEarU; Fri, 30 May 2014 19:14:35 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s4UJEYA6006273 for ; Fri, 30 May 2014 15:14:34 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s4UJEYP2006272; Fri, 30 May 2014 15:14:34 -0400 Date: Fri, 30 May 2014 15:14:34 -0400 Message-Id: <201405301914.s4UJEYP2006272@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: sipcore@ietf.org In-reply-to: <39B5E4D390E9BD4890E2B31079006101126DE88C@ESESSMB301.ericsson.se> (ivo.sedlacek@ericsson.com) References: <39B5E4D390E9BD4890E2B31079006101126DDBAB@ESESSMB301.ericsson.se> <201405281831.s4SIVqf4026532@hobgoblin.ariadne.com> <39B5E4D390E9BD4890E2B31079006101126DE833@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101126DE88C@ESESSMB301.ericsson.se> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1401477275; bh=I6WfJKwTsXqmwn3PAsfJNAHiv5dC5MJg8A5tS68JmPY=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=HxMba5emPCoOlhW364zkKe72E1lRZBVNg2TnY58YR+ItO098ElK1ghis7Q82e4Na+ LPIWU4L/YLtWZqK8SPeFWqWMba8aKf9cRc+vv9qdh4qNcvsRHOm7dvF9hV0WTWRyOH cQy5ktKV+y+w4SE8hUlMDZelCi00TI1GTENLmgYvXlfOZ44WVZH2Hgskx0adEomEF7 /3oAbi3h9n0PT67JBL1ALGlfHj3xbe/2qhF8SQpZEXmL6TEw1uYU7txF+d4Nc3e2pZ rvxOXuLbTgUT211yBdKSFkkw/SUO4i11d6NK0fn2GfbVBjSnqSH1+goMDV/mAuu1Eq FwySVS0fLUrJA== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/yjkMSQ_rnuZ7ZQz7QTOMJPyMJak Subject: Re: [sipcore] Precondition and status confirmation in regular two party calls X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 19:14:41 -0000 > From: Ivo Sedlacek > The whole reason for the confirm-status attribute is to request a > confirmation when resources becomes available. So if UA has *NOT* > received the confirm-status attribute, then when resources of the UA > becomes available, the UA should refrain from sending UPDATE (unless > there is another reason, not related to resource reservation, for > doing so). > > Do you agree? Yes. It seems to be a case of "Do not send UPDATE unless there is a reason to." Dale From nobody Sat May 31 07:20:48 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8302C1A08D0 for ; Sat, 31 May 2014 07:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hHy8gncsBRWo for ; Sat, 31 May 2014 07:20:45 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8E801A0403 for ; Sat, 31 May 2014 07:20:44 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.1-0) with ESMTP id 835e9835.2b5ec421f940.6494962.00-2415.17946791.nbfkord-smmo05.seg.att.com (envelope-from ); Sat, 31 May 2014 14:20:40 +0000 (UTC) X-MXL-Hash: 5389e538733491bf-3041261bbdab10988d78720c902883ff4c9f4633 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.1-0) over TLS secured channel with ESMTP id d25e9835.0.6494898.00-2274.17946619.nbfkord-smmo05.seg.att.com (envelope-from ); Sat, 31 May 2014 14:20:37 +0000 (UTC) X-MXL-Hash: 5389e53565931959-9d1ebc1fce3364767dfa55cc83387a143a090102 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s4VEKTWL008200; Sat, 31 May 2014 10:20:29 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s4VEKLYB008083 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 31 May 2014 10:20:27 -0400 Received: from MISOUT7MSGHUBAD.ITServices.sbc.com (MISOUT7MSGHUBAD.itservices.sbc.com [130.9.129.148]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Sat, 31 May 2014 14:20:12 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUBAD.ITServices.sbc.com ([130.9.129.148]) with mapi id 14.03.0174.001; Sat, 31 May 2014 10:20:12 -0400 From: "DOLLY, MARTIN C" To: "Dale R. Worley" Thread-Topic: [sipcore] Precondition and status confirmation in regular two party calls Thread-Index: Ac96Zajf1+EEuKX/StyoBSSQQDfk1ZtXnK2Q5Kp4EoCAAZbE1oABQAno Date: Sat, 31 May 2014 14:20:11 +0000 Message-ID: <605C3074-3334-4A8B-8BC4-7109F354DCE2@att.com> References: <39B5E4D390E9BD4890E2B31079006101126DDBAB@ESESSMB301.ericsson.se> <201405281831.s4SIVqf4026532@hobgoblin.ariadne.com> <39B5E4D390E9BD4890E2B31079006101126DE833@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101126DE88C@ESESSMB301.ericsson.se>, <201405301914.s4UJEYP2006272@hobgoblin.ariadne.com> In-Reply-To: <201405301914.s4UJEYP2006272@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=DOA4FVxb c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=pucQfARjEy0A:10 a=ofMgfj31e3cA:10 a=BLceEmwcHowA:10 a=kj9] X-AnalysisOut: [zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=wh29FQHvAAAA:8 a=0FD05c-RA] X-AnalysisOut: [AAA:8 a=48vgC7mUAAAA:8 a=j_xsFF64dGRuwiwFn_UA:9 a=CjuIK1q_] X-AnalysisOut: [8ugA:10 a=qM39cor4HRgA:10 a=Hz7IrDYlS0cA:10 a=T0GrRU3177cA] X-AnalysisOut: [:10 a=f7GxY0FH8QIA:10 a=lZB815dzVvQA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/EN3G2SzYnjHLsEMqe1n_NuD6jeY Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Precondition and status confirmation in regular two party calls X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 May 2014 14:20:46 -0000 I Agree as well Martin Dolly Lead Member of Technical Staff Core Network & Gov't/Regulatory Standards =20 AT&T Standards and Industry Alliances +1-609-903-3360 md3135@att.com On May 30, 2014, at 3:14 PM, "Dale R. Worley" wrote: >> From: Ivo Sedlacek >=20 >> The whole reason for the confirm-status attribute is to request a >> confirmation when resources becomes available. So if UA has *NOT* >> received the confirm-status attribute, then when resources of the UA >> becomes available, the UA should refrain from sending UPDATE (unless >> there is another reason, not related to resource reservation, for >> doing so). >>=20 >> Do you agree? >=20 > Yes. It seems to be a case of "Do not send UPDATE unless there is a > reason to." >=20 > Dale >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore