Re: Draft new version: draft-ietf-sip-199-07

Hi, 

>1) Section 6 Proxy behaviour:
> 
>"When a proxy receives a 199 response, it MUST process the response as
any other non-100 provisional responses."
> 
>Do we really want this on a 199-aware proxy ?  It is not stated here
that the 199 response received by the proxy is only 
>recognised if sent in an existing early dialog.  If the 199 response is
received by a 199-aware proxy out of any existing 
>early dialog, should the dialog-stateful proxy create a new dialog with
the new To tag and allocate resources "as any 
>other non-100 provisional responses" ?  

Receiving 199 out-of-dialog is an error case, and I think it's an
implementation issue how those are handled. We normally don't specify
that.

I also think it is quite clear that a proxy which support 199 would not
create a new dialog.

------

>Another condition should be added to the list of conditions that must
be satisfied for the generation of the 199 by the 
>proxy :
>
>- No 2xx response has been sent on the server transaction
>
>As 199 is meant to meet REQ 1 "to indicate to the UAC that an early
dialog has been terminated BEFORE A FINAL RESPONSE is 
>sent", and according to RFC3261/16.7 bullet 5:
>
>
>  "After a final response has been sent on the server transaction,
>   the following responses MUST be forwarded immediately:
>
>   -  Any 2xx response to an INVITE request
>
>   A stateful proxy MUST NOT immediately forward any other
>   responses."
>
>199 belongs to "any other responses" which MUST not be forwarded.

I guess the text you propose applies to any final response (not only
2xx) sent by the forking proxy. 

I guess I could add some text, eventhough I think it is obvious. When
the forking proxy forwards a final response it terminates all early
dialogs.

-----

>2) Section 7 Backward compatibilility
>
>"The 199 Early Dialog Terminated response code does not "replace" a
final response.  A final response is always sent, 
>after one or many 199 provisional responses have been sent."
>
>A final response is NOT always sent.  If the forking has resulted in at
least one 2xx being sent on the server 
>transaction, no 3xx/4xx/5xx/6xx is allowed to be sent to the same
server transaction after the 2xx.

Well, in that case a final response (the 2xx) HAS been sent. The text
doesn't say that a final response must be sent on each early dialog.

>So these early dialogs which receive non-2xx final response AFTER a
first 2xx final response will not get 199 but will 
>only be considered terminated by the UAC 64*T1 seconds after the
reception of the first 2xx response.  Even those early 
>dialogs for which 199 responses have been sent (because the final
responses were received before the first 2xx) will not 
>receive a final response.
>
>RFC3261/13.2.2.4:
>
>  "The UAC core considers the INVITE transaction completed 64*T1
seconds
>   after the reception of the first 2xx response.  At this point all
the
>   early dialogs that have not transitioned to established dialogs are
>   terminated.  Once the INVITE transaction is considered completed by
>   the UAC core, no more new 2xx responses are expected to arrive." 

The intention is to say that IF the server has an intention to send a
final response on a specific dialog, it must not "replace" that final
response with a 199.
 
------

>3) Minor comments:
>
>   Section 4.1 : "...When the P-Early-Media header is used..."
>   Add [RFC5009] after the "header".

I will do that.

------

>Section 6 : "...., it generates a unique Via header branch parameter
value for each fork".
>Replace "fork" with "forked leg" because the term "fork" has not be
defined officially or used in RFC 3261 for this 
>purpose.

I will do that.

------

>Section 6: "A forking proxy which supports generating of 199 response
codes..."
>Replace "codes" with "code".

I would propose to say "generating of 199 responses..." instead. That is
more alligned with the wording in other places of the document.

------

Thank You very much for your comments!


Regards,

Christer




	
	        From: [email protected] [mailto:[email protected]]
On Behalf Of Christer Holmberg
	        Sent: Wednesday, April 01, 2009 00:31
	        To: [email protected]
	        Subject: [Sip] Draft new version: draft-ietf-sip-199-07
	       
	       
	
	
	        Hi,
	
	        I have put together a new version (-07) of the 199
draft, based on the latest discussions.
	
	        The changes are in chapters 5 (new note added) and 6
(text simplified). 100rel and SDP o/a impacts have also been added to
chapters 5 and 6 (I have still kept chapters 9 and 10, though).
	
	
http://www.ietf.org/internet-drafts/draft-ietf-sip-199-07.txt
<http://www.ietf.org/internet-drafts/draft-ietf-sip-199-07.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 [email protected] for questions on current
sip
	Use [email protected] for new developments on the application of
sip
	



	.

	________________________________

		_______________________________________________
	Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
	This list is for NEW development of the core SIP Protocol
	Use [email protected] for questions on current
sip
	Use [email protected] for new developments on the application of
sip

_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip