Francois Audet wrote:
> I can think of one scenario...
>
> If the UAS in question is actually some sort of B2BUA.
OK. That is a good one.
That is certainly a reason not to forbid it.
And in that case we would expect the B2BUA to follow the rules for
proxies about handling and generating 199.
Thanks,
Paul
>> -----Original Message-----
>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
>> Behalf Of Paul Kyzivat
>> Sent: Friday, June 13, 2008 07:07
>> To: [EMAIL PROTECTED]
>> Cc: [email protected]
>> Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00
>>
>> This all sounds like good stuff.
>>
>> However I am still scratching my head about the UAS sending a
>> 199. While I see no reason to forbid it I'm trying to find a
>> situation when it would be helpful. The only case I have been
>> able to think of is:
>>
>> There is a forking proxy upstream of the UAS, but it doesn't
>> support 199. Yet it may delay the final response while it
>> tries other forks. So the UAS sending the 199 makes up for
>> the inadequacy of the forking proxy.
>>
>> The trouble with this is that it is inefficient in many
>> cases. If each proxy that forks also supports the sending of
>> 199, and the UAS doesn't send one, then we avoid sending the
>> message except in cases where it is helpful. If the UAS
>> always sends it we have increased the message count by one
>> for all failing calls. And the majority of failing calls get
>> no benefit from a 199.
>>
>> This is one of those cases that could probably benefit from
>> simulation to judge the merits. My gut feel is that the costs
>> of the UAS sending the 199 outweigh the benefits. Barring
>> some analysis to the contrary I think I would say that a UAS
>> SHOULD NOT send a 199. Or perhaps MAY send, but without any
>> guidance of when.
>>
>> Paul
>>
>> [EMAIL PROTECTED] wrote:
>>> 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
>>>
>> _______________________________________________
>> 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
