Re: [Sip] [sipcore] [Technical Errata Reported] RFC3261 (2910)
Iñaki Baz Castillo <ibc@aliax.net> Sat, 06 August 2011 12:16 UTC
Return-Path: <ibc@aliax.net>
X-Original-To: sip@ietfa.amsl.com
Delivered-To: sip@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76C8C21F87BC; Sat, 6 Aug 2011 05:16:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.649
X-Spam-Level:
X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id juu1UiD2YVLu; Sat, 6 Aug 2011 05:16:31 -0700 (PDT)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7E1A021F8772; Sat, 6 Aug 2011 05:16:31 -0700 (PDT)
Received: by qwc23 with SMTP id 23so243289qwc.31 for <multiple recipients>; Sat, 06 Aug 2011 05:16:51 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.68.41 with SMTP id t41mr2614254qci.63.1312633011313; Sat, 06 Aug 2011 05:16:51 -0700 (PDT)
Received: by 10.229.224.212 with HTTP; Sat, 6 Aug 2011 05:16:51 -0700 (PDT)
Received: by 10.229.224.212 with HTTP; Sat, 6 Aug 2011 05:16:51 -0700 (PDT)
In-Reply-To: <CAFQP3_afcp=COozZqB+g39LU3XVtYi-tSrxCuyZkOLWbNVasfw@mail.gmail.com>
References: <20110802145359.C9DEE98C50D@rfc-editor.org> <DC49588FF3643F43B3A2A8F6F0A625F0284638642A@mailbox1.acmepacket.com> <69373B11-F46D-4F88-B4A8-BF56A8EC2624@nostrum.com> <CALiegf=1=ZqEcs0kE=Y+ykrcd9miPDSN=mzP99-EWytVXdXMwA@mail.gmail.com> <9B06B312-4BCF-499D-979F-33D8E70DAD5A@nostrum.com> <CAFQP3_afcp=COozZqB+g39LU3XVtYi-tSrxCuyZkOLWbNVasfw@mail.gmail.com>
Date: Sat, 06 Aug 2011 14:16:51 +0200
Message-ID: <CALiegfnqzes0b_uCFVwHko5SG_fTuJ0Bx60ceFYKDZ0RCbqNww@mail.gmail.com>
From: Iñaki Baz Castillo <ibc@aliax.net>
To: Romel Khan <romel.khan@idt.net>
Content-Type: multipart/alternative; boundary="0016e651395e5c1e0e04a9d53095"
Cc: "sip@ietf.org List" <sip@ietf.org>, "SIPCORE (Session Initiation Protocol Core) WG" <sipcore@ietf.org>
Subject: Re: [Sip] [sipcore] [Technical Errata Reported] RFC3261 (2910)
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sip>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 06 Aug 2011 12:16:32 -0000
El 04/08/2011 21:09, "Romel Khan" <romel.khan@idt.net> escribió: > > So it is useful if one of UAS or UAC requires it, but it does not have to be mandatory. Some comments: > -- RFC3261 mentions early dialog without mentioning RFC3262. Then it seems logical to me that it needs to be made clear in this RFC3261 that early dialog must mean Contact and Record-Route (if Record-Route was received in INVITE) headers is mandatory in 1xx without reference to 100rel. > > -- A UAS could always send 1xx with headers that are required for early dialog but it doesn't have to enforce 100rel (eg because the origination or UAS side itself may not support reliable provisional response handling, or reliable provisioning not really required for its operation). UAS could send "support:100rel" if it supports it, or it would not send it if it doesn't support this. In my opinion, if UAC hasn't sent 100rel required, it should be up to the UAS to decide whether to enforce 100rel (with "required:100rel") if its application really requires SIP requests before call answer. If the origination side (UAC) side has a need to send early requests, like UPDATE, then the UAC should require 100rel from the termination side (UAS) by sending this yin INVITE. In a VoIP service provider world, these kind of capabilities are configured during interconnect turn up. > > -- I notice that some vendors gateway implementations, even if gateway is the termination side, require 100rel for the gateway to receive pre-answer requests such as UPDATE. This really didn't have to be this way. I have always seen these gateways, when it is the termination side, respond back SIP 183 with the headers that create early dialog. So if the origination side received the SIP 183 response, then there is no reason for the origination side to now not be able to send UPDATE request. Also, no reason for the termination gateways to not accept the SIP UPDATE without requiring PRACK. I entirely agree with it. And I also think that the fact that a 1xx response without 100rel is not reliable does not mean that it does not create a dialog so Contact and RR are required.
- [Sip] [Technical Errata Reported] RFC3261 (2910) RFC Errata System
- Re: [Sip] [Technical Errata Reported] RFC3261 (29… Bob Penfield
- Re: [Sip] [Technical Errata Reported] RFC3261 (29… Iñaki Baz Castillo
- [Sip] Table2/3 maintenance (was Re: [Technical Er… Robert Sparks
- Re: [Sip] [Technical Errata Reported] RFC3261 (29… Robert Sparks
- Re: [Sip] [Technical Errata Reported] RFC3261 (29… Iñaki Baz Castillo
- Re: [Sip] Table2/3 maintenance (was Re: [Technica… Iñaki Baz Castillo
- Re: [Sip] [sipcore] [Technical Errata Reported] R… Robert Sparks
- Re: [Sip] [sipcore] [Technical Errata Reported] R… Samir Srivastava
- Re: [Sip] [sipcore] [Technical Errata Reported] R… Paul Kyzivat
- Re: [Sip] [sipcore] [Technical Errata Reported] R… Iñaki Baz Castillo
- Re: [Sip] [sipcore] [Technical Errata Reported] R… Worley, Dale R (Dale)
- Re: [Sip] [sipcore] [Technical Errata Reported] R… Romel Khan
- Re: [Sip] [sipcore] [Technical Errata Reported] R… Samir Srivastava
- Re: [Sip] [sipcore] [Technical Errata Reported] R… Paul Kyzivat