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
