Re: [Sip] New version (-04) of draft-ietf-sip-199

"Elwell, John" <john.elwell@siemens.com> Wed, 07 January 2009 11:10 UTC

Return-Path: <sip-bounces@ietf.org>
X-Original-To: sip-archive@optimus.ietf.org
Delivered-To: ietfarch-sip-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 365AE3A6808; Wed, 7 Jan 2009 03:10:59 -0800 (PST)
X-Original-To: sip@core3.amsl.com
Delivered-To: sip@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 398BE3A6808 for <sip@core3.amsl.com>; Wed, 7 Jan 2009 03:10:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.532
X-Spam-Level:
X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gtTz9Ic+fGfp for <sip@core3.amsl.com>; Wed, 7 Jan 2009 03:10:57 -0800 (PST)
Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id EECF33A6806 for <sip@ietf.org>; Wed, 7 Jan 2009 03:10:56 -0800 (PST)
Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KD30074ELOYQI@siemenscomms.co.uk> for sip@ietf.org; Wed, 07 Jan 2009 11:10:40 +0000 (GMT)
Date: Wed, 07 Jan 2009 11:10:32 +0000
From: "Elwell, John" <john.elwell@siemens.com>
In-reply-to: A <CA9998CD4A020D418654FCDEF4E707DF0A392F09@esealmw113.eemea.ericsson.se>
To: Christer Holmberg <christer.holmberg@ericsson.com>, sip@ietf.org
Message-id: <0D5F89FAC29E2C41B98A6A762007F5D00167DF83@GBNTHT12009MSX.gb002.siemens.net>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Thread-Topic: [Sip] New version (-04) of draft-ietf-sip-199
Thread-Index: AclwpMa2gVaTl0oqRZ+oKLyml2UY7wAEccgw
Content-class: urn:content-classes:message
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
References: A <CA9998CD4A020D418654FCDEF4E707DF0A392F09@esealmw113.eemea.ericsson.se>
Subject: Re: [Sip] New version (-04) of draft-ietf-sip-199
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

Christer,

"If the received initial request contains an 199 option tag, the UAS
   SHOULD NOT send a 199 response for a dialog on which it intends to
   send a final response, unless it e.g. has been configured to do so
   due to lack of 199 support by forking proxies or other intermediate
   SIP entities."

I doubt that a UAS would implement a new configurable parameter just so
that it can reduce resource consumption at the UAC when the forking
proxy has not bothered to implement 199. It is far easier for the UAS
never to send 199. So is it really worth specifying this option?

"When a forking proxy receives a non-2xx final response which
   terminates one or more (if forking has occured downstream a final
   response received by the forking proxy MAY terminate multiple early
   dialogs), and the proxy does not intend to forward the final response
   immedialetly (due to the rules for a forking proxy), and the UAC has
   indicated support of the 199 response code, the proxy SHOULD generate
   and send a 199 response upstream for the early dialog on which the
   non-2xx final response was received, unless the proxy has previously
   recieved and forwarded a 199 response for the dialog."
Wow! We really must shorten this sentence. In particular I don't like
including a second normative sentence in parentheses within the main
sentence.

"If the forking proxy has stored the Contact and Record-Route headers
   for the early dialogs, it SHALL insert the headers in the 199
   responses."
Which Contact and Record-Route header fields? Presumably the ones
received from the UAS (as opposed to the UAC), but it doesn't make this
clear. Also, if there is no compulsion to store these header fields, why
make it mandatory to transmit them if they have been stored?


John 


________________________________

	From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On
Behalf Of Christer Holmberg
	Sent: 07 January 2009 08:49
	To: sip@ietf.org
	Subject: [Sip] New version (-04) of draft-ietf-sip-199
	
	


	Hi, 

	Based on comments and discussions, I've submitted a new version
of the 199 draft. 

	The currently remaining to-do is to add text to the security
chapter. 

	The draft can also be found at: 

	http://users.piuha.net/cholmber/drafts/draft-ietf-sip-199-04.txt
<http://users.piuha.net/cholmber/drafts/draft-ietf-sip-199-04.txt>  

	Regards, 

	Christer 

_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip