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 protected]]
Sent: Wednesday, April 08, 2009 7:21 PM
To: Tan, Ya Ching (NSN - DE/Munich)
Cc: [email protected]
Subject: RE: [Sip] 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
_______________________________________________
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
