Here are some comments on this I-D. I don't think that any of them
modify our understanding of the proposal. I guess this is very terse;
please use these suggestions as you see fit.
* Abstract
Clarify:
This specification defines a new SIP response code, 199 Early
Dialog Terminated, which a SIP entity can use to indicate upstream
that an early dialog has been terminated. The response code can be
used by a SIP entity (a SIP proxy or UAS), to inform the UAC that
an early dialog has been terminated. As the 199 response is a
provisional response, often the UAC will receive it before
receiving a final response to its request.
* Section 1
When a forking proxy receives a non-2xx final response, it does not
always immediately forward the response upstream towards the sender
of the associated request. Instead, the forking proxy "stores" it
and waits for further final responses from remote destinations where
the forked request was forwarded.
The text does not allow for serial forking, only parallel forking,
which might be confusing to people who are more aware of serial
forking. So amend the last sentence to:
Instead, the forking proxy "stores" it and waits for further final
responses from remote destinations where the forked request was
forwarded, and possibly forwards the request to additional
destinations.
Also, Avoid using "..." except when indicating that the word is used
in a non-standard way or that one is discussing the word itself:
Instead, the forking proxy "stores" it [...]
should be:
Instead, the forking proxy stores it [...]
* Section 3.
REQ 1: It must be possible to indicate to the UAC that an early
dialog has been terminated before a final response is sent.
Oddly, though everyone thinks they understand this sentence, it
doesn't really say what we want. To really ensure that the UAC
understands the early dialog has been terminated before the UAS sends
a final response, the UAS would have to send 199 *and get the PRACK
saying that it was received* before sending a final response. This may
well be worse than the present state of affairs.
What we really mean is:
REQ 1: It must be possible for a UAS or proxy to send an indication
to the UAC that an early dialog has been terminated, which
indication will not be delayed waiting for a final response from
any UAS.
* Section 4
When a client receives a 199 Early Dialog Terminated provisional
response it MAY release resources and procedures associated with the
early dialog the 199 response is received on.
Amend to clarify the meaning of 199 independently of the consequences
of that meaning:
When a client receives a 199 Early Dialog Terminated provisional
response, it has positive knowledge that the UAS that created the
early dialog has terminated it, and so the client MAY release
resources and procedures associated with the early dialog for which
the 199 response is received.
* Section 4
Add this paragraph before the last paragraph:
A UAC that receives a 199 response for an early dialog MUST NOT
send any further requests on that dialog, except for a PRACK if the
199 response was sent reliably, and PRACKs for other reliable
provisional responses that are to be acknowledged.
This is copied from section 7 (Backward Compatibility), but since it
is a constraint on UACs, it should also be stated in this section.
* Section 4
The UAC MAY use additional information (for example the final
response which triggered the 199 response) received in the 199
response when initiating new sessions, if it is possible to avoid the
new session initiation request to be rejected.
What is the meaning of the final clause?
* Section 5
Add "early" as marked:
When a UAS wants to terminate *an early* dialog it sends a non-2xx
SIP final response, as specified in [RFC3261]. In addition, prior
to sending the non-2xx SIP final response, the UAS MAY send a 199
response to indicate that the dialog is being terminated.
This clarifies that 199 cannot be used to terminate a confirmed
dialog.
(The reason a UAS may want to send a 199 is to provide this
information even when the upstream proxy does not support 199.)
There is a subtlty to the second sentence:
Sending the 199 *before* the final response is not necessary due to
the semantics of 199 (as it will probably reach the UAC first anyway,
and it would not matter if it did not), but rather to prevent the
upstream proxy from generating a 199 based on the final response, and
then to transmit the UAS's 199 immediately after -- if the UAS sends
the 199 first, any upstream proxy will (most likely) see the 199
before seeing the final response (which might induce the proxy to send
its own 199).
* Section 6
When a forking proxy receives a non-2xx final response which
terminates one or more early dialogs and the proxy does not intend to
forward the final response immediately (due to the rules for a
forking proxy) it MUST send a 199 provisional response, for each
associated early dialog that it can associate with the final
response, upstream towards the sender of the associated request.
Clarify, and note that if the proxy has already passed a 199 for an
early dialog, it need not generate one itself. Also, I've reduced
MUST to SHOULD, because (as the following NOTE explains), the proxy
may not know of all early dialogs which are terminated by the final
response.
[...] it SHOULD initiate a 199 provisional response upstream
towards the sender of the associated request, for each terminated
early dialog, excepting those for which it has already transmitted
a 199 response.
Note that the "already transmitted 199 responses" may have come from
downstream proxies as well as downstream UASs, so this consideration
applies even if we do not allow UASs to send 199s.
* Section 7
Since all SIP entities involved in a session setup do not necessarily
support the specific meaning of the 199 Early Dialog Terminated
provisional response, the sender of the response MUST be prepared to
receive SIP requests associated with the dialog for which the 199
response was sent.
This situation can also result due to race conditions. Amend to:
Because of race conditions and because the client may not support the
specific meaning of the 199 provisional response, the sender of the
response MUST be prepared to receive SIP requests associated with
the dialog for which the 199 response was sent.
And add a qualifier to this sentence:
If such request is received, and the receiver maintains state of
the dialogs, the receiver MUST reply to such requests with a 481
final response (unless another error response is more appropriate).
* Section 7
Remove "..." from this sentence and add "even" as marked:
The 199 Early Dialog Terminated response code MUST NOT replace a
final response. A final response MUST always be sent, *even* after
one or many 199 Early Dialog Terminated provisional responses have
been sent.
* Section 8
Clarify this sentence to:
The 199 Early Dialog Terminated response code allows a SIP entity
to indicate to upstream entities that a specific early dialog has
been terminated, before a final response reaches the upstream
entities.
Add the following:
The early dialog that has been terminated is identified by the Call-Id
header and the to-tag value of the 199 response.
Future standards may define optional additional information carried
in the headers and/or body of the response.
* Section 9
A 199 Early Dialog Terminated provisional response MUST NOT contain a
new SDP offer/answer message body, but the sender of the response MAY
insert a copy of a previously sent offer/answer message body as
otherwise allowed by the offer/answer rules for a provisional
response.
This rule seems excessively strict, as it seems OK to send a new SDP
answer in a 199, even if the dialog will be immediately terminated.
Certainly, the UAC cannot tell the difference, as there could have
been a previous but lost 1xx response carrying the same SDP.
The interaction of 199 and SDP probably needs further study...
* Section 11
Nit: Use "reject" here rather than "rejects":
UAS_2 and UAS_3 *reject* the INVITE by sending a 4xx error response.
Here is a modification of the example, showing how a UAS can send a
199, and how the proxy handles it. (You may or may not want to use
this.) I've also added the ACK's for the 4xx's, which were missing in
the original.
[...] UAS_2 and UAS_3 reject the INVITE by sending a 4xx error
response. UAS_3 sends a 199 with its 4xx. When P1 receives the
4xx response from UAS_2 it immediately sends a 199 Early Dialog
Terminated associated with UAS_2's dialog towards the UAC. P1
transmits UAS_3's 199, and so does not initiate one itself for
UAS_3's dialog when it receives UAS_3's 4xx response.
UAC P1 UAS_2 UAS_3 UAS_4
--- INVITE ------>
--- INVITE (leg 2) ->
--- INVITE (leg 3) ---------->
--- INVITE (leg 4) ------------------->
<-- 18x (leg 2) -----
<-- 18x (leg 2) --
<-- 18x (leg 3) --------------
<-- 18x (leg 3) --
<-- 18x (leg 4) -----------------------
<-- 18x (leg 4) --
<-- 4xx (leg 2) -----
<-- 199 (leg 2) --
--- ACK (leg 2) ---->
<-- 199 (leg 3) --------------
<-- 199 (leg 3) --
<-- 4xx (leg 3) --------------
--- ACK (leg 3) ------------->
<-- 200 (leg 4) -----------------------
<-- 200 (leg 4) --
--- ACK (leg 4) ->
--- ACK (leg 4) ---------------------->
Dale
_______________________________________________
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
