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
________________________________
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
