From: "Christer Holmberg" <[EMAIL PROTECTED]>
Regarding the few open items:
>* 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.
Yes, I am sure that you did not intend to prevent or ignore serial
forking. But I am afraid that the original text might lead a naive
reader to assume that only parallel forking is relevant regarding 199.
Fortunately, we only need to add a few words to ensure that no such
misunderstanding happens.
>* 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.
The odd thing is that although the mechanism described in the I-D
solves the problem we want to solve, the requirement *as stated* does
not describe the problem we want to solve, nor does the I-D satisfy
the requirement as stated. It is easy, when reading the requirement
to mis-interpret it (I did so myself several times), but what it
says is not what we intend. How do we proceed if what SIPPING
approved is not what we are interested in?
>* 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.
That is true, if we forbid reliable 199, then this proposed paragraph
would be modified in parallel with the paragraph in section 7.
>* 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.
How about: "The UAC MAY use additional information (for example the
final response which triggered the 199 response) received in the 199
response for additional purposes."
>* 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?
I am using *...* to make clear the words I inserted. I do not intend
that the "*" would remain in the text of the I-D.
>(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.
My preference is to state the explicit rule for when to send 199 that
we've been discussing on the list. That rule implies all of the
consequences we've discussed. It also correctly handles various
peculiar situations whose proper handling might not be clear at first
analysis.
Example:
Suppose that before ringing, a UA plays a message to the caller
through a separate early dialog. So it sends the following messages:
183 Session Progress, to-tag = A, with SDP A
RTP, according to SDP A
199 Early Dialog Terminated, to-tag = A
180 Ringing, to-tag = B
200 OK, to-tag = B, with SDP B
Following the rule, it's clear that sending the 199 is acceptable (and
it is useful).
Of course, we could also analyze the UA as a proxy that forks the
call serially to two UAs, one of which plays the announcement, and
we would obtain the same result. But it's easier to apply the rule
to the UA as a whole.
>* 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.
It is to allow future standardization of additional headers or
body-content (e.g., to provide HERFP information).
>* 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.
Originally, I saw no use for having an SDP body in a 199, but I saw no
reason to forbid it, either.
Except that I have changed my mind -- since we are reserving the body
of 199 for future standardization (especially, to carry the
corresponding failure response), we should avoid letting it be used
for other purposes.
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
