Subject: [Sip] Draft new version: draft-ietf-sip-199-07

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 1 Apr 2009 09:30:42 +0200

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

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 2 Apr 2009 14:02:05 +0200

Hi,
 
Please also note that the WGLC process har started for the draft.
 
I know that a number of people have read the draft, and the -07 version
should cover all the comments and open issues, but it is still good to
make sure all editorials etc are in order :)
 
Thanks!
 
Christer

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Christer Holmberg
Sent: Wednesday, April 01, 2009 8:31 AM
To: [email-masked]
Subject: [Sip] Draft new version: draft-ietf-sip-199-07

Hi, 

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

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 7 Apr 2009 12:16:12 -0500

Minor comment: It would improve readability of the Figures if the vertical bars where ]
included in the pictures.

	From: [email-masked] [mailto:[email-masked]] On Behalf Of Christer Holmberg
	Sent: Wednesday, April 01, 2009 00:31
	To: [email-masked]
	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

---

From: "Attila Sipos" <[email-masked]>
Date: Tue, 7 Apr 2009 20:16:44 +0100

Francois' comment about the diagram
also brought to my attention the fact that figure 3
is probably "illegal" for RFCs - isn't there usually
an 80 character line-length limit?
 
Anyway, I've "re-drawn" figure 3 and removed
the word "leg" - this can obviously be made
clear with an explanation.
 
   UAC           P1               P2               UAS_2     UAS_3    UAS_4
    --- INVITE--->
                  --- INVITE (2) ------------------->
                  --- INVITE ----->
                                   --- INVITE (3) ------------>
                                   --- INVITE (4) --------------------->
                                   <-- 18x (3) ----------------
                  <-- 18x (3) -----
    <-- 18x (3) --
                                   <-- 18x (4) -------------------------
                  <-- 18x (4) -----
    <-- 18x (4) --
                                   <-- 4xx (3) ----------------
                                   --- ACK (3) --------------->
                                   <-- 4xx (4) -------------------------
                                   --- ACK (4) ------------------------>
                  <-- 4xx (3) ----
                  --- ACK (3) --->
    <-- 199 (3) --
    <-- 199 (4) --
                  <-- 200 (2) ----------------------
    <-- 200 (2) --
    --- ACK (2) ->
                  --- ACK (2) --------------------->

Only issue now is that this makes figure 3 inconsistent with the others.

From: [email-masked] on behalf of Francois Audet
Sent: Tue 07/04/2009 18:16
To: Christer Holmberg; [email-masked]
Subject: Re: [Sip] Draft new version: draft-ietf-sip-199-07

        Hi,

        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-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 7 Apr 2009 14:37:50 -0500

Re: [Sip] Draft new version: draft-ietf-sip-199-07I apologize for this post in advance (lowest added value post to this mailing list in some time), but

http://www.rfc-editor.org/rfc-editor/instructions2authors.txt

says 

B. Basic Formatting                                        |  3.1
                                                           |
    o   Only printable ASCII characters                    |  3.1(1),
                                                           |    3.1(4)
    o   No lines exceeding 72 characters                   |  3.1(2)
        [This is especially important for "as is" tables   |
         and figures, which cannot be easily reformatted by|
         the RFC Editor.]   

Thanks,

Spencer
  ----- Original Message ----- 
  From: Attila Sipos 
  To: Francois Audet ; Christer Holmberg ; [email-masked] 
  Sent: Tuesday, April 07, 2009 2:16 PM
  Subject: Re: [Sip] Draft new version: draft-ietf-sip-199-07

------------------------------------------------------------------------------

          Hi,

          Regards,

          Christer

  .

------------------------------------------------------------------------------

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 7 Apr 2009 21:40:01 +0200

Thanks Spencer and Attila! I'll fix the flows.
 
Regards,
 
Christer

From: Spencer Dawkins [mailto:[email-masked]] 
Sent: Tuesday, April 07, 2009 10:38 PM
To: Attila Sipos; Francois Audet; Christer Holmberg; [email-masked]
Subject: Re: [Sip] Draft new version: draft-ietf-sip-199-07

I apologize for this post in advance (lowest added value post to this
mailing list in some time), but

says 

Thanks,
 
Spencer

	----- Original Message ----- 
	From: Attila Sipos <mailto:[email-masked]>  
	To: Francois Audet <mailto:[email-masked]>  ; Christer
Holmberg <mailto:[email-masked]>  ; [email-masked] 
	Sent: Tuesday, April 07, 2009 2:16 PM
	Subject: Re: [Sip] Draft new version: draft-ietf-sip-199-07

	 
	   UAC           P1               P2               UAS_2
UAS_3    UAS_4
	    --- INVITE--->
	                  --- INVITE (2) ------------------->
	                  --- INVITE ----->
	                                   --- INVITE (3) ------------>
	                                   --- INVITE (4)
--------------------->
	                                   <-- 18x (3) ----------------
	                  <-- 18x (3) -----
	    <-- 18x (3) --
	                                   <-- 18x (4)
-------------------------
	                  <-- 18x (4) -----
	    <-- 18x (4) --
	                                   <-- 4xx (3) ----------------
	                                   --- ACK (3) --------------->
	                                   <-- 4xx (4)
-------------------------
	                                   --- ACK (4)
------------------------>
	                  <-- 4xx (3) ----
	                  --- ACK (3) --->
	    <-- 199 (3) --
	    <-- 199 (4) --
	                  <-- 200 (2) ----------------------
	    <-- 200 (2) --
	    --- ACK (2) ->
	                  --- ACK (2) --------------------->

	Only issue now is that this makes figure 3 inconsistent with the
others.

	Minor comment: It would improve readability of the Figures if
the vertical bars where ]
	included in the pictures.

	        From: [email-masked] [mailto:[email-masked]]
On Behalf Of Christer Holmberg
	        Sent: Wednesday, April 01, 2009 00:31
	        To: [email-masked]
	        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).

	        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-masked] for questions on current
sip
	Use [email-masked] 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-masked] for questions on current
sip
	Use [email-masked] for new developments on the application of
sip

---

From: "Tan, Ya Ching (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 8 Apr 2009 18:40:08 +0200

Some comments :

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" ?  
 
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.

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.  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." 

3) Minor comments:

   Section 4.1 : "...When the P-Early-Media header is used..."
   Add [RFC5009] after the "header".

   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.

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

Regards,
Ya-Ching

	
	
	        Hi,

	
	        Regards,
	
	        Christer

	.

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 8 Apr 2009 19:20:58 +0200

Hi, 

>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 :
dialog has been terminated BEFORE A FINAL RESPONSE is 
>sent", and according to RFC3261/16.7 bullet 5:
>
>

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.

-----

>"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."
>
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 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.
 
------

>   Add [RFC5009] after the "header".

I will do that.

------

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.

------

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

	
	
	        Hi,

	
	        Regards,
	
	        Christer

	.

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 8 Apr 2009 22:09:03 +0200

Hi, 

-----

>least one 2xx being sent on the server transaction, no 3xx/4xx/5xx/6xx
is allowed to be sent to the same
>after the reception of the first 2xx response.  At this point all
>the early dialogs that have not transitioned to established dialogs are

I propose the following text:

"The 199 Early Dialog Terminated response code does not "replace" a
final response. A final response must always be sent when mandated by
the procedures in RFC3261."

I think that would clarify that we are not modifying the core SIP rules
on sending final responses.

Regards,

Christer

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 9 Apr 2009 00:45:52 +0200

Is that a "MUST" or something that is not must like "RFC 3261 specifies when a final response is sent."

Keith 

> -----Original Message-----
> Sent: Wednesday, April 08, 2009 9:09 PM
> To: Tan, Ya Ching (NSN - DE/Munich)
> Cc: [email-masked]
> Subject: Re: [Sip] Draft new version: draft-ietf-sip-199-07 - 
> comment on section 7
> 
> 
> Hi, 
> 
> -----
> 
> >terminated.  Once the INVITE transaction is considered 
> completed by the 
> >UAC core, no more new 2xx responses are expected to arrive."
> >
> 
> "The 199 Early Dialog Terminated response code does not 
> "replace" a final response. A final response must always be 
> sent when mandated by the procedures in RFC3261."
> 
> I think that would clarify that we are not modifying the core 
> SIP rules on sending final responses.
> 
> Regards,
> 
> Christer
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 9 Apr 2009 06:53:37 +0200

Hi, 

>Is that a "MUST" or something that is not must like "RFC 3261 specifies
when a final response is sent."

RFC 3261 does specify when a final response is sent. Would you prefer
something like:

"The 199 Early Dialog Terminated response code does not "replace" a
final response. RFC 3261 specifies when a final response is sent."

Regards,

Christer

> - comment 
> > on section 7
> "replace" a 
> > I think that would clarify that we are not modifying the core SIP 
> > rules on sending final responses.
> > 
> > Regards,
> > 
> > Christer
> > 
> > [email-masked] for questions on current sip Use 
> > [email-masked] for new developments on the application of sip
> > 
>

---

From: "Tan, Ya Ching (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 9 Apr 2009 11:05:32 +0200

I would still propose to replace :

  "When a proxy receives a 199 response, it MUST process the response as
   any other non-100 provisional responses...."

with 

  "When a proxy receives a 199 response on an early dialog, it MUST 
   process the response as any other non-100 provisional responses....

   If a proxy receives a 199 response out of dialog, it MUST drop the 
   response."

You are writing a RFC here and everything must be spelt out.  This is
not simply an implementation issue and it is contradictory to state on
one hand that the proxy "MUST process the response as any other non-100
provisional responses", and on the other hand thinking that it is quite
clear that a proxy which support 199 would not create a new dialog.
Creating a new dialog is the normal behaviour of receiving a non-100
provisional response with a new To tag.  A 199-unaware proxy will
certainly do that.

--------------

And to your reply

"When the forking proxy forwards a final response it terminates all
early
dialogs."

I do not agree that when the forking proxy forwards a final response it
terminates all early dialogs, as we are talking about INVITE transaction
here.

RFC3261/16.7 bullet 10:

         If the forwarded response was a final response, the proxy MUST
         generate a CANCEL request for all pending client transactions
         associated with this response context....

         The requirement to CANCEL pending client transactions upon
         forwarding a final response does not guarantee that an endpoint
         will not receive multiple 200 (OK) responses to an INVITE.  200
         (OK) responses on more than one branch may be generated before
         the CANCEL requests can be sent and processed.

and RFC3261/16.7 bullet 5:

         This step, combined with the next, ensures that a stateful
proxy
         will forward exactly one final response to a non-INVITE
request,
         and either exactly one non-2xx [final] response or one or more
         2xx responses to an INVITE request.

and 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 199 mechanism will only indicate early dialogs that are terminated
before the first 2xx.  If the first 2xx arrives very early, immediately
after many early dialogs are created, all subsequent non-2xx final 
responses for those early dialogs cannot be conveyed to the UAC with
199.  Even if the first confirmed 2xx dialog is terminated with BYE,
the UAC still could expect further 2xx responses to arrive on early
dialogs within 64*T1 seconds after the reception of the first 2xx
response.

Regards,
Ya-Ching

-----Original Message-----
From: ext Christer Holmberg [mailto:[email-masked]] 
Sent: Wednesday, April 08, 2009 7:21 PM
To: Tan, Ya Ching (NSN - DE/Munich)
Cc: [email-masked]
Subject: RE: [Sip] Draft new version: draft-ietf-sip-199-07

Hi, 

-----

>   after the reception of the first 2xx response.  At this point all
the

------

I will do that.

------

value for each fork".

I will do that.

------

codes..."

------

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 9 Apr 2009 11:31:40 +0200

Hi, 

response."
> 
>You are writing a RFC here and everything must be spelt out.  
>
>This is not simply an implementation issue and it is 
>contradictory to state on one hand that the proxy "MUST 
>process the response as any other non-100 provisional 
>responses", and on the other hand thinking that it is quite 
>Creating a new dialog is the normal behaviour of receiving a 
>non-100 provisional response with a new To tag.  A 
>199-unaware proxy will certainly do that.

I would then propose that we say that a proxy SHOULD drop unreliable 199
responses which are sent out-of-dialog. 

If the 199 response is sent reliably, I don't think we can drop it.

>--------------
> 
>And to your reply
> 
>"When the forking proxy forwards a final response it 
>terminates all early dialogs."
> 
>I do not agree that when the forking proxy forwards a final 
>response it terminates all early dialogs, as we are talking 
>about INVITE transaction here.
> 
>RFC3261/16.7 bullet 10:
> 
>If the forwarded response was a final response, the 
>proxy MUST generate a CANCEL request for all pending client
transactions
>forwarding a final response does not guarantee that 
>an endpoint will not receive multiple 200 (OK) responses to an 
>INVITE. 200 (OK) responses on more than one branch may be 
>generated before the CANCEL requests can be sent and processed.

Yes. It's a race condition.

>This step, combined with the next, ensures that a 
>stateful proxy will forward exactly one final response to a 
>non-INVITE request, and either exactly one non-2xx [final] response or 
>one or more 2xx responses to an INVITE request.
> 
>and 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
>the UAC core, no more new 2xx responses are expected to arrive.

Implementations will normally terminate all other early dialogs when the
first 2xx is recevied. Then, if additional 2xx response (on other
dialogs) are received, implementations will normally send ACK+BYE for
them. So, yes, the INVITE transaction is still alive, but the early
dialogs are normally terminated.

>The 199 mechanism will only indicate early dialogs that are 
>terminated before the first 2xx.  If the first 2xx arrives 
>very early, immediately after many early dialogs are created, 
>all subsequent non-2xx final responses for those early 
>dialogs cannot be conveyed to the UAC with 199. Even if the 
>first confirmed 2xx dialog is terminated with BYE, the UAC 
>still could expect further 2xx responses to arrive on early 
>dialogs within 64*T1 seconds after the reception of the first 
>2xx response.

I doubt that a UAC implementation which recieves the first 200 OK, and
then send BYE for it, will sit and wait for additional 2xx responses to
arrive. The UAC will consider the call to be terminated, and free all
resources for it. Otherwise, if resources are limited, the UAC may not
be able to make a new call until 64*T1 seconds...

Also, as the text in 16.7 says, once a final response has been
forwarded, the forking proxy sends a CANCEL for all other forked legs.
So, additonal 2xx responses will only reach the UAC if some an UAS sent
a 2xx response before it received the CANCEL from the forking proxy.

But, in any case, I can add a bullet with a condition that 199 is only
sent if a final response has yet not been sent.

Regards,

Christer

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 9 Apr 2009 11:41:54 +0200

Yep, unless there really is a new "MUST" to write in the 199 draft.

regards

Keith 

> From: Christer Holmberg [mailto:[email-masked]] 
> Sent: Thursday, April 09, 2009 5:54 AM
> To: DRAGE, Keith (Keith); Tan, Ya Ching (NSN - DE/Munich)
> Cc: [email-masked]
> Subject: RE: [Sip] Draft new version: draft-ietf-sip-199-07 - 
> comment onsection 7
> 
> 
> Hi, 
> 
> >Is that a "MUST" or something that is not must like "RFC 
> 3261 specifies
> RFC 3261 does specify when a final response is sent. Would 
> you prefer something like:
> 
> "replace" a final response. RFC 3261 specifies when a final 
> response is sent."
> 
> Regards,
> 
> Christer
> 
> 
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 9 Apr 2009 11:47:55 +0200

>Yep, unless there really is a new "MUST" to write in the 199 draft.

Not in my opinion.

Regards,

Christer

> > onsection 7

---

From: "Tan, Ya Ching (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 9 Apr 2009 12:55:34 +0200

Comments inline start with [Tan] :

-----Original Message-----
From: ext Christer Holmberg [mailto:[email-masked]] 
Sent: Thursday, April 09, 2009 11:32 AM
To: Tan, Ya Ching (NSN - DE/Munich)
Cc: [email-masked]
Subject: RE: [Sip] Draft new version: draft-ietf-sip-199-07

---snip snip---

[Tan] 199 response sent reliably out-of-dialog are still illegal 199.
If the proxy can't drop it, does it create a new dialog with its new To
tag like any non-100 responses ? Do we forward such reliable 199
responses to UAC which did not indicate support of 199 just because you
think that we cannot drop reliable 1xx.  If yes, such reliable but
illegal 199 responses will create new early dialogs at UAC.  Even if the
UAC has indicated support of 199, should the reception of out-of-dialog
199 by UAC create a new early dialog ?

---snip snip---
 
dialogs are

[Tan] The RFC has to be able to stand by itself and not be dependant on
what implementations would normally do.

Regards,
Ya-Ching

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 9 Apr 2009 13:05:07 +0200

> what implementations would normally do.

It is obviously impossible to implement 199 without also implementing and conforming to RFC 3261. If the required behaviour is already specified in RFC 2119 language in RFC 3261, then we should not repeat that requirement in the 199 draft. 

Any RFC 2119 language should be limited to requirements that are changes to RFC 3261 behaviour.

regards

Keith

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Tan, Ya Ching (NSN - DE/Munich)
> Sent: Thursday, April 09, 2009 11:56 AM
> To: ext Christer Holmberg
> Cc: [email-masked]

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 9 Apr 2009 13:35:05 +0200

Hi, 

>I would then propose that we say that a proxy SHOULD drop 
>unreliable 199 responses which are sent out-of-dialog. 
> 
>If the proxy can't drop it, does it create a new dialog with 
>its new To tag like any non-100 responses ? Do we forward such reliable
199
>responses to UAC which did not indicate support of 199 just 
>because you think that we cannot drop reliable 1xx.  If yes, such
reliable but
>illegal 199 responses will create new early dialogs at UAC.  
>Even if the UAC has indicated support of 199, should the reception of 
>out-of-dialog 199 by UAC create a new early dialog ?

Even if the proxy recieves the 199 out-if-dialog, the UAS may actually
have sent it in-dialog, before the final response was sent. The 199 and
the final response then "crossed each other" on the link, so that the
proxy recieves the 199 before the final response.

So, if the 199 is sent reliably, in-dialog, the UAS may have a state
machine re-transmitting it until it receives a PRACK. Therefor I don't
think the proxy can drop it.

And, since other proxies upstream have already received the final
response, I don't think they will reserve any resources when they
receive the 199.

Exactly the same thing can happen with any reliable provisional
response.

And, if proxies receive 199 out-of-dialog, without any associated INVITE
transaction, they are not going to reserve any resources. 

>>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
>[Tan] The RFC has to be able to stand by itself and not be 
>dependant on what implementations would normally do.

Yes. I have now added some text.

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 9 Apr 2009 13:46:24 +0200

Hi,

I think it would be enough to say:

"If a proxy receives a 199 response out of dialog, it processes it as
other non-100 provisional responses received out of dialog."

I think the case when it will happen is really rare, so I don't see any
advantage in specifying specific 199 procedures for what most likely is
going to be an error case anyway.

Regards,

Christer

> Behalf Of DRAGE, Keith (Keith)
> Sent: 9. huhtikuuta 2009 14:05
> To: Tan, Ya Ching (NSN - DE/Munich); Christer Holmberg
> Cc: [email-masked]
> dependant 
> > on what implementations would normally do.
> 
> It is obviously impossible to implement 199 without also 
> implementing and conforming to RFC 3261. If the required 
> behaviour is already specified in RFC 2119 language in RFC 
> 3261, then we should not repeat that requirement in the 199 draft. 
> 
> unreliable 
> > 199 responses which are sent out-of-dialog.
> > 
> > If the proxy can't drop it, does it create a new dialog 
> with its new 
> > To tag like any non-100 responses ? Do we forward such reliable 199 
> > responses to UAC which did not indicate support of 199 just because 
> > you think that we cannot drop reliable 1xx.  If yes, such 
> reliable but 
> > Even if the
> >  At this
> > Implementations will normally terminate all other early 
> dialogs when 
> > the first 2xx is recevied. Then, if additional 2xx response 
> (on other
> dependant 
> > on what implementations would normally do.
> > 
> > 
> > Regards,
> > Ya-Ching