Hi Dale,
>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.
[CHH] Ok.
>* 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.
[CHH] I can change the text. My intention was not to prevent serial
forking. Because, no matter what type of forking it is, the forking
proxy will "store" final responses from the different forked legs.
>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 [...]
[CHH] Ok.
>* 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.
[CHH] I hear what you are saying, but it is a copy of the requirement
text we agreed to in SIPPING.
>* 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.
[CHH] Ok.
>* 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.
[CHH] Whether the text should be in the document at all depends on if we
allow 199 to be sent reliably in the first place. Based on the comments
received so far we should not mandate 199 to be sent reliably, even if
100rel is required by the UAC. But, the question if whether we want to
FORBID sending it reliably.
>* 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?
[CHH] Others have asked the same, so I guess it needs some modification.
The meaning is that the information received in the 199 may be used to
solve the HERFP problem. It is not in the scope of the document to solve
that problem, just to mention that the information may be used for a
future mechanism solving it.
>* 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.
[CHH] I have nothing against your proposal as such, but is this marking
method that you are proposing something we normally use in IETF specs?
>(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).
[CHH] This depends on whether we should keep the UAS text in the first
place, or only describe when proxies send 199. Based on the comments
I've received so far, we should not describe UAS behavior for sending
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.
[CHH] I need to think a little more, but it looks ok.
>* 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).
[CHH Ok.
>* 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.
[CHH] Same issue as before regarding the marking method.
>* 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.
[CHH] I am ok with the first sentence, but I don't understand the
meaning of the other ("Future standards...") in this context.
>* 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...
[CHH] If we are not going to specify UAS sending of 199 then there will
be no SDP in it. I don't think the forking proxy should store received
SDPs, and then insert one when triggering the 199.
>* Section 11
>
>Nit: Use "reject" here rather than "rejects":
>
>
> UAS_2 and UAS_3 *reject* the INVITE by sending a 4xx error response.
[CHH] Ok.
>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 usethis.) 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) ---------------------->
[CHH] I'm ok with your modficiation of the example.
Thanks!
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
