Attila,
Sure we can take the approach of leaving it to the UAS to decide whether
to send a 199.
My concern is that it may be inefficient, not just for that UA, but for
the system as a whole. So I think we need to be a little careful here.
I'm not suggesting forbidding this - clearly there are cases where it is
the right thing to do.
Paul
Attila Sipos wrote:
>
> >>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.
>
> It may or may not be helpful but as you say, you can
> see no reason to forbid it.
>
> Why restrict it if the restriction isn't needed?
>
> As someone has pointed out, a B2BUA scenario might benefit
> from 199. In fact, any kind of SIP gateway might benefit.
>
> > 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.
>
> If the UAS wants to send it, that is a decision for
> them - not something that needs to be prevented.
>
> SIP forking, in the technical sense of sending a
> response with a different to-tag, is always legal.
> So, any UA which has used forking
> should also be able to use 199.
>
> I don't think we need to include any specific text about UAS
> except to say that a UAS can use it if the UAS has created
> the forking.
>
> Regards,
>
> Attila
>
>
>
> -----Original Message-----
> From: [EMAIL PROTECTED] on behalf of Paul Kyzivat
> Sent: Fri 13/06/2008 15: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
