Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00

From: Paul Kyzivat <[email-masked]>
Date: Tue, 10 Jun 2008 17:12:28 -0400

Christer,

I finally got around to this. A few comments:

Section 1:

    When SIP entities upstream
    receive the 2xx final response they will automatically terminate
    other associated outstanding early dialogs.

This isn't always wise. At this point it is still possible to receive 
additional 2xx responses. Discarding the early dialog is probably fine 
if subsequent 2xx responses with be dealt with by sending BYE. Retaining 
the early dialog isn't useful in that case. But if the UAC is planning 
to accept an additional 2xx response and retain the dialog rather than 
terminate it, then it should not discard the early dialog upon receipt 
of the first 2xx.

(Note that sending cancel upon receipt of a 2xx is MUST in 3261, but it 
is overridden by a 'Request-Disposition: no-cancel' specified in RFC 
3841. Terminating the early dialog at the UAC is also a MUST, but seems 
like it is probably an error.)

Section 4:

You give examples of kinds of resources that may be freed upon receipt 
of the 199. But you also hint at a problem:

    If the client is able to associate the 199 response with a specific
    media stream,

In many cases it may be hard/impossible to accomplish this. Can you give 
some plausible examples of cases when this will be possible?

I don't understand the following:

    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 initation request to be rejected.

I can't parse it into anything meaningful.

Section 5: When would it be advantageous for the UAS to send a 199?

Section 6:

This has MUST strength language. But of course not all proxies will 
implement this draft if/when it becomes an RFC. It it expected that this 
is to be an independent RFC to which support may be claimed?

Section 8:

    OPEN ISSUE: We need to discuss whether the To tag in the 199
    identifies the dialog that has been terminated, and/or if some
    additional information element (e.g.  SIP header) can be used, which
    would allow to indicate the termination of multiple dialogs in a
    single 199 response.

My preference is to use the To-tag, so that normal dialog matching rules 
will apply. We don't need more irregularities to complicate sip stacks.

    OPEN ISSUE: We need to discuss whether, in addition to the dialog
    identifier, some additional information (e.g. the non-2xx final
    response which triggered the 199 response) should be provided in the
    199 response.

I think it would be useful to at least acknowledge that a sipfrag can be 
carried in the 199, in a similar way to is carried in a refer event 
package notification. Would probably be good to state that it SHOULD NOT 
be included unless there was an Accept header mentioning the sipfrag 
content type in the request.

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.

    A forking proxy or a UAS MUST NOT trigger and send a 199 Early Dialog
    Terminated provisional response reliably in a situation where a
    reliable provisional response is required to contain an SDP offer/
    answer message body, according to [RFC3262] and [RFC3264].

These two paragraphs seem to be slightly at odds with one another, 
regarding the sending of an answer in a reliable 199. This can be fixed 
by changing the 2nd paragraph to only mention "offer", not "answer".

Section 10:

    OPEN ISSUE: We need to discuss whether a proxy should send 199
    reliably at all, since the proxy would have to terminate the
    associated PRACK, and support the logic associated with 100rel.  If
    not sent, how would required 100rel affect the usage of 199?

IMO it is a bad idea for a proxy to send a reliable 199. The problem is 
that you aren't sending the 199 unless there was already an early 
dialog. If there was, the proxy is not the second party in that dialog. 
The PRACK will be sent to the peer in the dialog, not the proxy. The 
proxy has no business terminating and responding to it. Yet the UAS 
won't be expecting it.

So I think it would only be possible to send a reliable 199 as part of 
some new dialog terminated by the proxy. But that then means the To-tag 
can't be used to indicate which dialog is being terminated. It just 
keeps getting more and more complicated.

And there really isn't any great value in sending this reliably. So 
don't do it.

	Thanks,
	Paul
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 11 Jun 2008 07:56:51 +0200

Hi Paul,
 
>if subsequent 2xx responses with be dealt with by sending BYE.
 
Correct. I can add some text, clarifying that the SIP enitty should
still be prepared to receive additional 2xx responses and deal with the
accordingly.

>Retaining the early dialog isn't useful in that case. But if the UAC is
planning
>terminate it, then it should not discard the early dialog upon receipt

I will mention that also.

>like it is probably an error.)

I can mention that RFC 3841 may affect the behavior of entities
regarding termination of early dialogs.

media stream,
>
>In many cases it may be hard/impossible to accomplish this. Can you
give some plausible examples of cases when this will be possible?

Maybe if the media stream is encrypted, and there are some encryption
parameters associated with the dialog. I am not an expert on that,
though....

Every now and then there have also been discussions of including
parameters, which are sent in the media stream, also in SIP messages, so
that media streams can be associated with an early dialog.

>I can't parse it into anything meaningful.

This is related to the HERFP problem. I has been agreed to not solve
that problem in this draft, but it was agreed to add some words about
what the information could be used for.

>Section 5: When would it be advantageous for the UAS to send a 199?

This is one of the issues which was perviously discussed, so I listed
the possibility.

Francois also had that question, and I am ok with removing it.

>This has MUST strength language. But of course not all proxies will
implement this draft if/when it becomes an RFC.

Well, the text only applies to proxies supporting the draft, so...

>It it expected that this is to be an independent RFC to which support
may be claimed?

Yes. The idea is NOT to make a normative reference to RFC3261.

>will apply. We don't need more irregularities to complicate sip stacks.

I agree. I am happy to remove the OPEN ISSUE, unless someone else has a
different opinion.

>content type in the request.

This was discussed based on input from Francois just a few days ago, so
please take a look whether you are ok with the outcome of that
discussion. 

We did not discuss the Accept header, though, and I think that is a good
point.

>by changing the 2nd paragraph to only mention "offer", not "answer".

Ok

>And there really isn't any great value in sending this reliably. So

I have no problem with that. A UA that doesn't support 199, but has
required 100rel, may discard the unreliable 199, but it really doesn't
matter.

Thank you very much for the comments!
 
Regards,
 
Christer

---

From: [email-masked]
Date: Thu, 12 Jun 2008 22:55:00 -0400

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

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

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 13 Jun 2008 12:37:51 +0200

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:
>

[CHH] Ok.

>The text does not allow for serial forking, only parallel forking,
which might be confusing to people who are more aware >of serial
>   forwarded, and possibly forwards the request to additional

[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
>   Instead, the forking proxy stores it [...]

[CHH] Ok.

>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:
>

[CHH] I hear what you are saying, but it is a copy of the requirement
text we agreed to in SIPPING.

>   the 199 response is received.

[CHH] Ok.

>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.

>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.

>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.)
>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.

>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.
>
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.

>   final response (unless another error response is more appropriate).

[CHH Ok.

>   one or many 199 Early Dialog Terminated provisional responses have

[CHH] Same issue as before regarding the marking method.

>   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.

>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.

[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.

>   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.
>                         --- ACK (leg 4) ---------------------->

[CHH] I'm ok with your modficiation of the example.

Thanks!

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 13 Jun 2008 10:07:22 -0400

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

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 13 Jun 2008 12:43:05 -0500

I can think of one scenario...

If the UAS in question is actually some sort of B2BUA. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Paul Kyzivat
> Sent: Friday, June 13, 2008 07:07
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00
> 
> 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:
> 
> 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
> 
> > 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:
> > 
> > This list is for NEW development of the core SIP Protocol Use 
> > [email-masked] for questions on current sip Use 
> > [email-masked] for new developments on the application of sip
> > 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 13 Jun 2008 15:10:39 -0400

> 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

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 13 Jun 2008 14:10:54 -0500

Yeah, exactly. 

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: Friday, June 13, 2008 12:11
> To: Audet, Francois (SC100:3055)
> Cc: [email-masked]; [email-masked]
> And in that case we would expect the B2BUA to follow the 
> rules for proxies about handling and generating 199.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 13 Jun 2008 17:03:46 -0400

So the text certainly needs to permit this case.

But I think some care is needed about a UAS that is really at the end of 
the end of the stream (downstream, where the packets soak into the 
ground.) Do we want to allow that UAS to send 199 responses? If so, what 
if any guidelines should be given?

Seems to me we need a pretty strong SHOULD NOT here, with the B2BUA 
being the known exception.

	Paul

---

From: [email-masked]
Date: Fri, 13 Jun 2008 17:57:05 -0400

From: Paul Kyzivat <[email-masked]>

I admit I hadn't considered whether a UAS sending 199 is useful.

But in giving the rules for proxies, we must take care of the case
where a downstream proxy sends a 199.  This is where we get the rule
that if a proxy propagates a 199 for an early dialog, then it should
not send a 199 for that early dialog itself.  Once we've set that rule
for proxies, then a UAS can also send a 199 without breaking anything.

But it does look like there is no gain from sending a 199 unless the
corresponding final response will not be sent immediately.

Dale

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 13 Jun 2008 17:16:20 -0500

Yeah, I think we should say that this feature is intended to be used by Proxies and
not by UAS. The reason it is allowed for UAS is for B2BUA who often act in many ways
like a proxy. 

> Sent: Friday, June 13, 2008 14:04
> But I think some care is needed about a UAS that is really at 
> the end of the end of the stream (downstream, where the 
> packets soak into the
> ground.) Do we want to allow that UAS to send 199 responses? 
> If so, what if any guidelines should be given?
> 
> Seems to me we need a pretty strong SHOULD NOT here, with the 
> B2BUA being the known exception.
> 
> 	Paul
> 
> Francois Audet wrote:
> > Yeah, exactly. 
> > 
> >

---

From: [email-masked] (Juha Heinanen)
Date: Sat, 14 Jun 2008 09:59:18 +0300

> being the known exception.

i don't agree excepting B2BUA for anything as long as b2bua has been
officially added and defined as a new sip related entity in addition to
UAs, registrars and proxies.  once that is done, then every sip
specification has to state if/when ua procedures also apply to these
B2BUAs.

-- juha

---

From: "Christer Holmberg" <[email-masked]>
Date: Sat, 14 Jun 2008 14:46:17 +0200

Hi Juha,
 
Chapter 6 of RFC3261 DOES define Back-to-Back User Agent.
 
 Back-to-Back User Agent: A back-to-back user agent (B2BUA) is a
         logical entity that receives a request and processes it as a
         user agent server (UAS).  In order to determine how the request
         should be answered, it acts as a user agent client (UAC) and
         generates requests.  Unlike a proxy server, it maintains dialog
         state and must participate in all requests sent on the dialogs
         it has established.  Since it is a concatenation of a UAC and
         UAS, no explicit definitions are needed for its behavior.

We could of course say something like:
 
"UAS, when part of a B2BUA"
 
Regards,
 
Christer

________________________________

From: [email-masked] on behalf of Juha Heinanen
Sent: Sat 14/06/2008 08:59
To: Paul Kyzivat
Cc: [email-masked]; Francois Audet
Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00

-- juha

---

From: [email-masked] (Juha Heinanen)
Date: Sat, 14 Jun 2008 16:20:38 +0300

Christer Holmberg writes:

 >          it has established.  

according to the B2BUA definition:

	Since it is a concatenation of a UAC and
      UAS, no explicit definitions are needed for its behavior.

this means that there is no need to say anything special about 199
either.  b2bus in terms of protocol specification, is just an uas like
any other.

-- juha

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 14 Jun 2008 10:52:29 -0400

Well, the specification could be abstracted to remove the mention of the 
B2BUA while still having the same effect. It would have to say something 
about a UAS should send a 199 if it knows the dialog will be terminated 
before it can send the final response. But I think we would still need 
to include an example of a B2BUA in order for anybody to have a clue 
what we were talking about.

	Paul

---

From: "Attila Sipos" <[email-masked]>
Date: Sat, 14 Jun 2008 16:59:36 +0100

>>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.

> 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-masked] on behalf of Paul Kyzivat
Sent: Fri 13/06/2008 15:07
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 14 Jun 2008 17:35:07 -0400

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:
> .

---

From: "Christer Holmberg" <[email-masked]>
Date: Sun, 15 Jun 2008 13:02:12 +0200

Hi,
 
Maybe we could talk about the case when a UAS establishes more than one dialog? 
 
Regards,
 
Christer

From: [email-masked] on behalf of Paul Kyzivat
Sent: Sat 14/06/2008 23:35
To: Attila Sipos
Cc: [email-masked]
Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00

Attila,

        Paul

---

From: <[email-masked]>
Date: Mon, 16 Jun 2008 13:01:45 +0530

Referring to introduction part in the draft.
   " At some point the proxy uses a specified mechanism to determine the
"best" final response code, and forwards that final response upstream
towards the sender of the associated request."
 
Considering a scenario where all the forks have failed in yielding a 2xx
response from different UASes (UAS2 , 3 & 4 in the diagram) with
different error codes, how will the proxy determine the "best" final
response and to which leg would it send the best final response. What
would happen after 199 to leg 4?
 
      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) --
                         <-- 5xx (leg 3) --------------
       <-- 199 (leg 3) --
                         <-- 6xx (leg 4) -----------------------
       <-- 199 (leg 4) --

Best Regards, 
Ashish Saxena 
877-5570 

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Attila Sipos
Sent: Saturday, June 14, 2008 9:30 PM
To: Paul Kyzivat; [email-masked]
Cc: [email-masked]
Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00

Regards,

Attila

-----Original Message-----
From: [email-masked] on behalf of Paul Kyzivat
Sent: Fri 13/06/2008 15:07
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00

        Paul

> saying that it was received* before sending a final response.  This
may

.

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 16 Jun 2008 10:11:36 +0200

Hi,
 
The way the "best" final response code is chosen is described in RFC 3261, and the intention of 199 is not to change that.
 
Regarding whether a 199 will be sent for leg 4: if the proxy is now going to send a "best" final response I guess it doesn't need to send 199 for leg 4.
 
Regards,
 
Christer

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 16. kesäkuuta 2008 10:32
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00

Referring to introduction part in the draft.
   " At some point the proxy uses a specified mechanism to determine the "best" final response code, and forwards that final response upstream towards the sender of the associated request."
 
Considering a scenario where all the forks have failed in yielding a 2xx response from different UASes (UAS2 , 3 & 4 in the diagram) with different error codes, how will the proxy determine the "best" final response and to which leg would it send the best final response. What would happen after 199 to leg 4?
 
      UAC               P1                  UAS_2    UAS_3    UAS_4

       --- INVITE ------>
                         --- INVITE (leg 2) ->

Best Regards, 
Ashish Saxena 
877-5570 

From: [email-masked] [mailto:[email-masked]] On Behalf Of Attila Sipos
Sent: Saturday, June 14, 2008 9:30 PM
To: Paul Kyzivat; [email-masked]
Cc: [email-masked]
Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00

Regards,

Attila

-----Original Message-----
From: [email-masked] on behalf of Paul Kyzivat
Sent: Fri 13/06/2008 15:07
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00

        Paul

.

---

From: <[email-masked]>
Date: Mon, 16 Jun 2008 16:35:29 +0530

Thanks Christer,
We have a query on our basic understanding of this draft.
 
I too had the same query as Ashish, I can rephrase it for all of us.
What we mean to ask is that, considering the scenario shown by the SIP msg flow below, at what point does the proxy decide to send 199 response and on which call legs.
 
For e.g. in the scenario below, when proxy receives 403 on leg 2, and it is yet to receive responses on leg 3 and 4. In this case, the proxy cannot send a 199 to the UAC (is my understanding, please correct if wrong).
Also after having received 5xx and 6xx on the leg 3 and 4, there is no use sending 199 now because the best final response sent to UAC is sufficient to indicate that the leg 3 and 4 are terminated.

Please correct us if we are missing some hidden lines in the draft w.r.t our understanding.
 
Thanks,
Best Regards,
Rekha
(ESN : 6-877-5834)
(PSTN : 81168)

From: [email-masked] [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: Monday, June 16, 2008 1:42 PM
To: Ashish Saxena (WT01 - Telecom Equipment); [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00

Hi,

 
Regards,
 
Christer

 
 
      UAC               P1                  UAS_2    UAS_3    UAS_4

       --- INVITE ------>
                         --- INVITE (leg 2) ->

Best Regards, 
Ashish Saxena 
877-5570 

Regards,

Attila

-----Original Message-----
From: [email-masked] on behalf of Paul Kyzivat
Sent: Fri 13/06/2008 15:07
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00

        Paul

.

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 16 Jun 2008 13:35:44 +0200

Hi, 

>What we mean to ask is that, considering the scenario shown by the SIP msg flow below, at what point does the proxy decide to send 199 response and on which call legs.

A proxy would send a 199 as soon as it receives a final non-2xx response for a leg.

>please correct if wrong).

Yes, it can send 199 for leg 2. In SIP you can send as many provisional responses as you want.

>Also after having received 5xx and 6xx on the leg 3 and 4, there is no use sending 199 now because the best final response sent to UAC is sufficient to indicate that the leg 3 and 4 are 

If the proxy is going to send a best final response immediately there is no need to send 199. But, if the proxy is still waiting for final responses, it would send 199.

Regards,

Christer

 
Hi,

 
Regards,
 
Christer

 
 
      UAC               P1                  UAS_2    UAS_3    UAS_4

       --- INVITE ------>
                         --- INVITE (leg 2) ->

Best Regards, 
Ashish Saxena 
877-5570 

Regards,

Attila

-----Original Message-----
From: [email-masked] on behalf of Paul Kyzivat
Sent: Fri 13/06/2008 15:07
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00

        Paul

.

Please do not print this email unless it is absolutely necessary. 

The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. 

WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. 

www.wipro.com

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Mon, 16 Jun 2008 14:38:32 +0200

As you can never tell whether a UA is a UA by itself, or part of a
B2BUA, this must remain general UA behaviour.

The most you can do is add some informative material that essentially
says this is useful for B2BUAs only.

Regards

Keith 

> Behalf Of Juha Heinanen
> Sent: Saturday, June 14, 2008 2:21 PM
> To: Christer Holmberg
> Cc: [email-masked]; Paul Kyzivat; Francois Audet
> this means that there is no need to say anything special 
> about 199 either.  b2bus in terms of protocol specification, 
> is just an uas like any other.
> 
> -- juha

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 16 Jun 2008 15:12:18 +0200

Hi, 

My proposal was to simply talk about a UA which creates multiple To
tags. 

Regards,

Christer

> Juha Heinanen

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 16 Jun 2008 12:10:08 -0400

[email-masked] wrote:
> What we mean to ask is that, considering the scenario shown by the SIP 
> msg flow below, *at what point *does the proxy decide to send 199 
> response *and on which *call legs.

I believe the time to send a 199 is when the proxy has received a final 
error response and has elected *not* to forward it on at that time - in 
hopes of getting a better response.

The 199 should be sent upstream using the to-tag from the final response 
that is not being forwarded.

> For e.g. in the scenario below, when proxy receives 403 on leg 2, and it 
> is yet to receive responses on leg 3 and 4. In this case, the proxy 
> cannot send a 199 to the UAC (is my understanding, please correct if wrong).

IMO you are wrong. What makes you think this isn't ok?

> Also after having received 5xx and 6xx on the leg 3 and 4, there is no 
> use sending 199 now because the best final response sent to UAC is 
> sufficient to indicate that the leg 3 and 4 are terminated.

At the time the 5xx is received there is still another possibility, so 
the 199 is appropriate.

When the 6xx is received, there are no more legs, and presumably the 6xx 
prevents the proxy from generating any more legs. It should be sending a 
final response immediately at that time, so I see no value in a 199 there.

BUT if the proxy takes a lenient view of how to handle 6xx (treating it 
as advisory rather than definitive regarding *global* failure) then it 
might decide that it now will be trying another destination. If so, the 
199 response might be appropriate. But the call flow is then incomplete.

	Thanks,
	Paul

> ------------------------------------------------------------------------
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of 
> *Christer Holmberg
> *Sent:* Monday, June 16, 2008 1:42 PM
> *To:* Ashish Saxena (WT01 - Telecom Equipment); [email-masked]; 
> [email-masked]
> *Cc:* [email-masked]
> *Subject:* Re: [Sip] Draft submission: draft-ietf-sip-199-00
> 
>  
> Hi,
>  
> The way the "best" final response code is chosen is described in RFC 
> 3261, and the intention of 199 is not to change that.
>  
> Regarding whether a 199 will be sent for leg 4: if the proxy is now 
> going to send a "best" final response I guess it doesn't need to send 
> 199 for leg 4.
>  
> Regards,
>  
> Christer
>  
>  
>  
> 
> ------------------------------------------------------------------------
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of 
> [email-masked]
> *Sent:* 16. kesäkuuta 2008 10:32
> *To:* [email-masked]; [email-masked]
> *Cc:* [email-masked]
> *Subject:* Re: [Sip] Draft submission: draft-ietf-sip-199-00
> 
>                          <-- *4xx* (leg 2) -----
>                          <-- *5xx *(leg 3) --------------
>        <-- 199 (leg 3) --
>                          <-- *6xx *(leg 4) -----------------------
>        <-- 199 (leg 4) --
> 
> Best Regards,
> Ashish Saxena
> 877-5570
> 
>  
> 
> ------------------------------------------------------------------------
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of 
> *Attila Sipos
> *Sent:* Saturday, June 14, 2008 9:30 PM
> *To:* Paul Kyzivat; [email-masked]
> *Cc:* [email-masked]
> *Subject:* Re: [Sip] Draft submission: draft-ietf-sip-199-00
> 
> 
> * Please do not print this email unless it is absolutely necessary. *
> 
> The information contained in this electronic message and any attachments 
> to this message are intended for the exclusive use of the addressee(s) 
> and may contain proprietary, confidential or privileged information. If 
> you are not the intended recipient, you should not disseminate, 
> distribute or copy this e-mail. Please notify the sender immediately and 
> destroy all copies of this message and any attachments.
> 
> WARNING: Computer viruses can be transmitted via email. The recipient 
> should check this email and any attachments for the presence of viruses. 
> The company accepts no liability for any damage caused by any virus 
> transmitted by this email.
> 
> www.wipro.com
>

---

From: [email-masked]
Date: Mon, 16 Jun 2008 22:51:44 -0400

I think the situation is simpler than people are making it out to be.

The situations in which having an agent generate and send a 199 is
useful are when all of the following are true:

- the agent knows that an early dialog has been created because it
  transmitted a 1xx response (either that it generated, or that it
  received from downstream) (And as Rocksun pointed out, "1xx"
  explicitly excludes both "100" and "199".), and

- the agent knows that the early dialog has been terminated due to
  receiving a failure final response which includes the early dialog
  (which was from the downstream leg from which the 1xx came), and

- the agent has not transmitted a 199 response to terminate the early
  dialog, and

- the agent will not be immediately sending a failure final response
  (which would indicate the termination of the early dialog)

It turns out that an ordinary UAS never is in this situation (because
it only generates one early dialog for an INVITE, and only ends the
early dialog when it sends a failure final response), so by
implication, an ordinary UAS never should send a 199.

If we enumerate the above criteria, we don't have to describe the
various cases of UA vs. B2BUA, etc., because they're all covered.  And
by making the criteria explicit, we increase the probability of useful
and effective implementations.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 16 Jun 2008 23:53:16 -0400

Dale,

I'm fine with spinning it this way. It avoids using the *term* B2BUA, 
but it still is talking about a B2BUA since it is talking about a UA 
that has received a response from downstream of itself. So we are 
playing political correctness gavmes. But I'm ok with that.

	Thanks,
	Paul

---

From: Dean Willis <[email-masked]>
Date: Mon, 16 Jun 2008 23:01:08 -0500

>   what we were talking about.

Could it be explained in terms of a UA that is acting as a protocol  
gateway?

--
Dean

---

From: [email-masked]
Date: Tue, 17 Jun 2008 15:49:22 -0400

More importantly, the rule I suggest handles proxies, UAs, B2BUAs,
gateways, etc. *uniformly*.  (I use the term "agent" for "all devices
which send and receive SIP".)  There's no point attempting to make
general statements about the consequences of the rule for particular
classes of devices, as that only risks making a mistake by overlooking
unusual cases.  The rule states exactly when a 199 should be sent.

Dale

---

From: [email-masked]
Date: Wed, 18 Jun 2008 19:01:24 -0400

From: "Christer Holmberg" <[email-masked]>

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.

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?

That is true, if we forbid reliable 199, then this proposed paragraph
would be modified in parallel with the paragraph in section 7.

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."

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.

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.

It is to allow future standardization of additional headers or
body-content (e.g., to provide HERFP information).

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

---

From: <[email-masked]>
Date: Fri, 20 Jun 2008 10:56:21 +0530

Hi Christer,
	From Section 4 (Client Behaviour) part of this draft, I
understood that primary objective of this draft is to give indication to
UAC to release resources, if any. I am little worried about extra
messaging that will be seen because of 199 implementation. Can there be
a way to tell proxies and UAS downstream that UAC has some resources
reserved for this call and would be interested in receiving 199, if
possible?

IMO, UAC (mostly) is in better understanding of the resources that it
has reserved for a particular call. So UAC can selectively add something
in INVITE to tell downstream proxies/ UAS' about its interest. 

IMO, we can have a package for 199 and UAC can use "Supported" header to
indicate entities downstream that it would be interested in getting 199
for this *particular* call. Implicitly it would mean that UAC has
reserved some resources. I understand that we would changing the meaning
of "Supported" header on per call basis :-(. Something else may be?

Comments please.

Best Regards,
Ashish Saxena

---

From: <[email-masked]>
Date: Mon, 23 Jun 2008 10:23:49 +0530

Probably everybody is busy. Any thoughts on this one.

Best Regards,
Ashish Saxena
877-5570

-----Original Message-----
From: Ashish Saxena (WT01 - Telecom Equipment) 
Sent: Friday, June 20, 2008 10:56 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [Sip] Draft submission: draft-ietf-sip-199-00

Hi Christer,

Comments please.

Best Regards,
Ashish Saxena

---

From: "Avasarala Ranjit-A20990" <[email-masked]>
Date: Mon, 23 Jun 2008 14:56:43 +0800

Hi

Can we use Require:199 to indicate to proxy to send 199? 

Regards
Ranjit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Monday, June 23, 2008 10:24 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00

Best Regards,
Ashish Saxena
877-5570

-----Original Message-----
From: Ashish Saxena (WT01 - Telecom Equipment)
Sent: Friday, June 20, 2008 10:56 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [Sip] Draft submission: draft-ietf-sip-199-00

Hi Christer,

Comments please.

Best Regards,
Ashish Saxena

---

From: <[email-masked]>
Date: Mon, 23 Jun 2008 14:29:54 +0530

Thanks Ranjit,
	IMO it will be too restrictive on entities because we do not
want to block the call if the entities do not support this package.

Thanks.

Best Regards,
Ashish Saxena
877-5570

-----Original Message-----
From: Avasarala Ranjit-A20990 [mailto:[email-masked]] 
Sent: Monday, June 23, 2008 12:27 PM
To: Ashish Saxena (WT01 - Telecom Equipment);
[email-masked]
Cc: [email-masked]
Subject: RE: [Sip] Draft submission: draft-ietf-sip-199-00

Hi

Regards
Ranjit

-----Original Message-----

Best Regards,
Ashish Saxena
877-5570

-----Original Message-----
From: Ashish Saxena (WT01 - Telecom Equipment)
Sent: Friday, June 20, 2008 10:56 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [Sip] Draft submission: draft-ietf-sip-199-00

Hi Christer,

Comments please.

Best Regards,
Ashish Saxena

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 23 Jun 2008 14:33:27 +0200

Hi, 

>Can we use Require:199 to indicate to proxy to send 199? 

No. The Require header is only applicaple to a UAS.

You can use Proxy-Require for proxies, but the problem is that you would
require this from EVERY proxy in the path.

Regards,

Christer

-----Original Message-----

Best Regards,
Ashish Saxena
877-5570

-----Original Message-----
From: Ashish Saxena (WT01 - Telecom Equipment)
Sent: Friday, June 20, 2008 10:56 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [Sip] Draft submission: draft-ietf-sip-199-00

Hi Christer,

Comments please.

Best Regards,
Ashish Saxena

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 23 Jun 2008 14:39:36 +0200

Hi, 

>From Section 4 (Client Behaviour) part of this draft, I understood that
primary objective of this draft is to give 
>indication to UAC to release resources, if any. I am little worried
about extra messaging that will be seen because of 
>199 implementation. Can there be a way to tell proxies and UAS
downstream that UAC has some resources reserved for this 
>call and would be interested in receiving 199, if possible?
>
has reserved for a particular call. So UAC can 
>selectively add something in INVITE to tell downstream proxies/ UAS'
about its interest. 
>
>IMO, we can have a package for 199 and UAC can use "Supported" header
to indicate entities downstream that it would be 
>interested in getting 199 for this *particular* call. Implicitly it
would mean that UAC has reserved some resources. I 
>understand that we would changing the meaning of "Supported" header on
per call basis :-(. Something else may be?

I am not sure you would "break" anything by using Supported "per call".
As far as I know, it is nowhere said that a UAC must included the same
option-tags in the Supported header for every call it makes...

It is true that the primary objective is to give the indication to the
UAC, but in some environments there could also be intermediates (P-CSCF
controlling PCC in IMS for example) that are interested in this
indication.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 23 Jun 2008 11:46:15 -0400

> Probably everybody is busy. Any thoughts on this one.

If the call has been forked, and provisional responses with multiple 
to-tags have been sent back to the UAC, then it is certain that the UAC 
has *some* resources tied up with each early dialog. The 199 will allow 
some of that to be released.

Are you suggesting that the UAC indicate if it considers those resources 
to be sufficient to justify processing an extra message? Or maybe you 
are just concerned with the likelihood that the UAC doesn't support 199, 
so that the message will just be ignored in any case?

I could go either way on this one.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 23 Jun 2008 11:50:13 -0400

Right - Require is inappropriate. Supported is certainly possible. I 
think it would simply mean that the UAC understands the significance of 
199 and so is prepared to take advantage of it if received. I see no 
reason why you would change it on a call by call basis. The resources 
aren't committed at the time of the INVITE - rather at the time the 
provisional response is received, so doing on a per-call basis wouldn't 
make much sense.

	Paul

---

From: [email-masked]
Date: Fri, 20 Jun 2008 18:37:38 -0400

If we ever might allow 199 to be used for HERFP, we should admit the
possibility of sending it reliably in the first draft.  Otherwise,
we'll be locked out of sending it reliably in the future.

Dale

---

From: <[email-masked]>
Date: Tue, 24 Jun 2008 11:16:33 +0530

Just combining both the discussions here.
-----------------------------------------

[email-masked] wrote
to-tags have been sent back to the UAC, then it is certain that the UAC
has >*some* resources tied up with each early dialog. The 199 will allow
some of that to be released.

>Are you suggesting that the UAC indicate if it considers those
resources to be sufficient to justify processing an extra message? Or
maybe you   >are just concerned with the likelihood that the UAC doesn't
support 199, so that the message will just be ignored in any case?

>	Paul

[email-masked] wrote
reason why you would change it on a call by call basis. The resources
aren't > committed at the time of the INVITE - rather at the time the
provisional response is received, so doing on a per-call basis wouldn't
make much > > sense.

[Ashish Saxena] I am concerned about both (justify processing of an
extra message & UAC does not support 199). I brought up this discussion
with the assumption that UAC (mostly) is in better situation to
understand about resources reserved at its end. But Christer pointed out
that even intermediate entities may also be interested in releasing
resources asap. So if an entity knows that it has reserved resources and
would appreciate if they can be relinquished earlier, then it can simply
put "Supported" header to indicate entities downstream that it can
handle 199. This is why I was suggesting it to be call by call basis. 

	But with Paul's reasoning, it will be good to have for all
calls. It is easier to implement also. (otherwise UAC will have to put
extra intelligence to calculate whether it needs 199 in this call).
	
	IMO, Supported header will >

	a) Will stop proxies sending 199 because they would already know
that UAC does not understand it anyways.
	b) Reduce some 199s on network because of (a).

Best Regards,
Ashish Saxena

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Monday, June 23, 2008 9:20 PM
To: Christer Holmberg
Cc: Avasarala Ranjit-A20990; Ashish Saxena (WT01 - Telecom Equipment);
[email-masked]

	Paul

> IMO, we can have a package for 199 and UAC can use "Supported" header
to

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 24 Jun 2008 09:12:54 +0200

Hi, 

>>to-tags have been sent back to the UAC, then it is certain that the
UAC has *some* resources tied up with each early 
>>dialog. The 199 will allow some of that to be released.
>>
>>maybe you are just concerned with the likelihood that the UAC doesn't
aren't committed at the time of the INVITE - 
>>rather at the time the provisional response is received, so doing on a
per-call basis wouldn't make much > > sense.
>[Ashish Saxena] I am concerned about both (justify processing of an
extra message & UAC does not support 199). I brought 
>up this discussion with the assumption that UAC (mostly) is in better
situation to understand about resources reserved at 
>its end. But Christer pointed out that even intermediate entities may
also be interested in releasing resources asap. So 
>if an entity knows that it has reserved resources and would appreciate
if they can be relinquished earlier, then it can 
>simply put "Supported" header to indicate entities downstream that it
can handle 199. This is why I was suggesting it to 
>be call by call basis. 

[CHH] Sure, if it's ok to say that an intermediate can add an option-tag
to the Supported header.

>But with Paul's reasoning, it will be good to have for all calls. It is
easier to implement also. (otherwise UAC will 
>have to put extra intelligence to calculate whether it needs 199 in
this call).
>	
>	IMO, Supported header will 
>

If an intermediate inserts the option-tag in the Supported header the
UAC would of course still get the 199.

>	b) Reduce some 199s on network because of (a).

[CHH] I don't have any strong feelings whether we define an option-tag
or not.

Regards,

Christer

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]]
Sent: Monday, June 23, 2008 9:20 PM
To: Christer Holmberg
Cc: Avasarala Ranjit-A20990; Ashish Saxena (WT01 - Telecom Equipment);
[email-masked]

	Paul

> 	From Section 4 (Client Behaviour) part of this draft, I
understood 
> that primary objective of this draft is to give indication
to
to

www.wipro.com

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 24 Jun 2008 09:16:37 +0200

Hi,

I agree it may be a good idea to not forbid sending it reliably.

I do think it would be good to have text, saying that it can be sent unreliable even if reliable responses are required, though, so that proxies aren't forced to terminate PRACKs etc.

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 21. kesäkuuta 2008 1:38
To: [email-masked]
Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00

If we ever might allow 199 to be used for HERFP, we should admit the possibility of sending it reliably in the first draft.  Otherwise, we'll be locked out of sending it reliably in the future.

Dale
This list is for NEW development of the core SIP Protocol Use [email-masked] for questions on current sip Use [email-masked] for new developments on the application of sip

---

From: Jeroen van Bemmel <[email-masked]>
Date: Tue, 24 Jun 2008 09:38:07 +0200

Christer,

Should the 199 response contain a Contact header? And if yes, in case a 
proxy sends it, should it contain the address of that proxy (since the 
UAS already sent a final response)?

Should we say that a proxy may only generate and send a 199 when it 
receives a final error response on an INVITE client Transaction which 
was in the PROCEEDING state? (i.e. 1xx response was received before, so 
conceptually sending the 199 response is an action associated with the 
transition from PROCEEDING to COMPLETED)

Regards,
Jeroen

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 24 Jun 2008 10:05:05 +0200

Hi, 

>Should the 199 response contain a Contact header? And if yes, in case a proxy sends it, should it contain the address of 
>that proxy (since the UAS already sent a final response)?

IF the 199 is sent reliably be the proxy must contain a Contact header containing the address of the proxy, yes.

>Should we say that a proxy may only generate and send a 199 when it receives a final error response on an INVITE client 
>Transaction which was in the PROCEEDING state? (i.e. 1xx response was received before, so conceptually sending the 199 
>response is an action associated with the transition from PROCEEDING to COMPLETED)

I am not sure I understand. The idea IS to send 199 when a final error response is received by the forking proxy, if a 18x has previously been received.

Regards,

Christer

---

From: "Rockson Li (zhengyli)" <[email-masked]>
Date: Tue, 24 Jun 2008 18:23:01 +0800

Comment in line
-Rockson
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: Tuesday, June 24, 2008 4:05 PM
To: Jeroen van Bemmel
Cc: [email-masked]
Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00

Hi, 

>proxy sends it, should it contain the address of that proxy (since the UAS already sent a final response)?

I am not sure I understand. The idea IS to send 199 when a final error response is received by the forking proxy, if a 18x has previously been received.
[Rockson] PROCEEDING does not mean early-dialog is established, 100 Trying also move  INVITE client Transaction to PROCEEDING state.
                Also, a forking proxy with multiple INVITE client Transaction may receive/forward 180 from one of them, and receive no provisional resp and final resp directly
                from the other one, so  INVITE client Transaction's state is not dependable. The decision making must be done in TU.

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 24 Jun 2008 12:31:37 +0200

Hi, 

>[Rockson] PROCEEDING does not mean early-dialog is established, 100 Trying also move  INVITE client Transaction to 

[Christer] 199 is only sent when an early dialog has been established. 100 Trying does not establish an early dialog.

Regards,

Christer

Also, a forking proxy with multiple INVITE client Transaction may receive/forward 180 from one of them, and receive no 
provisional resp and final resp directly from the other one, so  INVITE client Transaction's state is not dependable. The 
decision making must be done in TU.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 24 Jun 2008 08:24:35 -0400

There is a very messy slippery slope here with the reliable 199.

I believe we have agreed that the 199 is to have the to-tag used by the 
UAS. So conceptually it is *from* the UAS. If you want the proxy to send 
the 199 reliably, then it will have to field the response. As others 
have mentioned, this seems to mean that it will have to use its own 
contact address, which will be a change from the contact used previously 
by the UAS for this early dialog.

That gives me heartburn - it just seems wrong. Ignoring that, it puts 
the 199 into the middle of the open question about changing of contact 
addresses and how they take effect.

This could be addressed by always sending the 199 with a To-tag assigned 
by the proxy. But that has its own problems. It actually makes the 
situation worse for UACs that don't support 199.

We sidestep all these problems by not sending the 199 reliably.

Maybe we we should say that the UAC must be prepared to handle both 
reliable and unreliable 199, but for now we don't specify any cases when 
a reliable 199 is sent.

Another thought - there aren't any issues if the *UAS* sends the 199 
reliably. But that isn't going to be the common case.

	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 24 Jun 2008 14:30:20 +0200

Hi,

If the proxy assignes its own To-tag, we can't use the To-tag to indciate which dialog was terminated.

One option, as proposed by Paul, is to say that a UAC shall be able to RECEIVE reliable 199 responses.

One ugly solution would be to retransmit the UNRELIABLE 199 a few times - we already use that type of mechanism in ICE, so... ;)

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: 24. kesäkuuta 2008 15:25
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00

I believe we have agreed that the 199 is to have the to-tag used by the UAS. So conceptually it is *from* the UAS. If you want the proxy to send the 199 reliably, then it will have to field the response. As others have mentioned, this seems to mean that it will have to use its own contact address, which will be a change from the contact used previously by the UAS for this early dialog.

That gives me heartburn - it just seems wrong. Ignoring that, it puts the 199 into the middle of the open question about changing of contact addresses and how they take effect.

This could be addressed by always sending the 199 with a To-tag assigned by the proxy. But that has its own problems. It actually makes the situation worse for UACs that don't support 199.

Maybe we we should say that the UAC must be prepared to handle both reliable and unreliable 199, but for now we don't specify any cases when a reliable 199 is sent.

Another thought - there aren't any issues if the *UAS* sends the 199 reliably. But that isn't going to be the common case.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 24 Jun 2008 08:43:50 -0400

> If the proxy assignes its own To-tag, we can't use the To-tag to indciate which dialog was terminated.

Right. That was part of my point. In addition, the to-tag it does use 
creates *another* early dialog.

And then, suppose we did allow the proxy to reuse the existing dialog 
for the 199, with a new contact. Then the UAC, upon receipt of the 199, 
will have to send the PRACK within the dialog. So the dialog can't be 
immediately destroyed. When *does* it get destroyed??? When the 200 to 
the PRACK is received?

The extra state management and time required to handle this seems to run 
contrary to the goal of the 199.

> One option, as proposed by Paul, is to say that a UAC shall be able to RECEIVE reliable 199 responses.

Based on my comments above, I am reconsidering the advisability of that.

> One ugly solution would be to retransmit the UNRELIABLE 199 a few times - we already use that type of mechanism in ICE, so... ;)

Yes, that *is* ugly!

	Paul

---

From: "Rockson Li (zhengyli)" <[email-masked]>
Date: Tue, 24 Jun 2008 20:53:16 +0800

Yes, it's a typo, 100 does not establish early-dialog.
-Rockson 

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]] 
Sent: Tuesday, June 24, 2008 6:32 PM
To: Rockson Li (zhengyli); Jeroen van Bemmel
Cc: [email-masked]
Subject: RE: [Sip] Draft submission: draft-ietf-sip-199-00

Hi, 

>>Should the 199 response contain a Contact header? And if yes, in case 
>>a proxy sends it, should it contain the address of that proxy (since the UAS already sent a final response)?
>
>>was in the PROCEEDING state? (i.e. 1xx response was received before, 
>>so conceptually sending the 199 response is an action associated with 
>>the transition from PROCEEDING to COMPLETED)
>
>I am not sure I understand. The idea IS to send 199 when a final error 
>response is received by the forking proxy, if a 18x has previously been received.
>[Rockson] PROCEEDING does not mean early-dialog is established, 100 
>Trying also move  INVITE client Transaction to PROCEEDING state.

Regards,

Christer

Also, a forking proxy with multiple INVITE client Transaction may receive/forward 180 from one of them, and receive no provisional resp and final resp directly from the other one, so  INVITE client Transaction's state is not dependable. The decision making must be done in TU.

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 24 Jun 2008 17:23:00 +0200

Hi, 

>Right. That was part of my point. In addition, the to-tag it does use creates *another* early dialog.
>
>>And then, suppose we did allow the proxy to reuse the existing dialog for the 199, with a new contact. Then the UAC, 
>>upon receipt of the 199, will have to send the PRACK within the dialog. So the dialog can't be immediately destroyed. 
>>When *does* it get destroyed??? When the 200 to the PRACK is received?
>
>The extra state management and time required to handle this seems to run contrary to the goal of the 199.

Correct.

>Based on my comments above, I am reconsidering the advisability of that.

Well, I guess it wouldn't affect the complexness in the UAC, since it will have to be able to handle reliable provisional responses anyway (if it indicates support of it, that is).

And, if the sender of the 199 is a B2BUA, I guess it COULD send it reliably.

But, I have no strong feelings regarding this.

Regards,

Christer

> Paul Kyzivat

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 24 Jun 2008 13:53:00 -0400

> Well, I guess it wouldn't affect the complexness in the UAC, since it will have to be able to handle reliable provisional responses anyway (if it indicates support of it, that is).

Yes, I think it does increase the complexity in the implementation of 
199 handling.

You are right that the PRACK itself would be handled by the standard 
machinery for reliable provisionals. But then tearing down the dialog, 
which is what the 199 is supposed to trigger, can't be done upon receipt 
of a reliable 199. Rather it must wait until the after the PRACK is at 
least send, and perhaps until the 200 for the prack is received. And 
this is different than for the unreliable 199. This isn't rocket 
science, but it is more complexity. And of course it requires something 
that sends reliable 199s in order to test the UAC.

	Paul

---

From: Jeroen van Bemmel <[email-masked]>
Date: Tue, 24 Jun 2008 20:23:27 +0200

Christer,

My point was to formalize the moment a 199 is sent by relating it to the 
RFC3261 ICT state machine (BTW we're all silently assuming non-INVITE 
requests don't use provisional responses here)
So associated with PROCEEDING-->COMPLETED, but indeed only if a to-tag 
was received before (so not only 100)

Regards,
Jeroen

PS perhaps an idea to explicitly disallow 199 for non-INVITE requests?

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 25 Jun 2008 17:39:34 +0200

Hi, 

>>Well, I guess it wouldn't affect the complexness in the UAC, since it
will have to be able to handle reliable 
>>provisional responses anyway (if it indicates support of it, that is).
>
199 handling.
>You are right that the PRACK itself would be handled by the standard
machinery for reliable provisionals. But then 
>tearing down the dialog, which is what the 199 is supposed to trigger,
can't be done upon receipt of a reliable 199. 
>Rather it must wait until the after the PRACK is at least send, and
perhaps until the 200 for the prack is received. And >this is different
than for the unreliable 199. This isn't rocket science, but it is more
complexity. And of course it 
>requires something that sends reliable 199s in order to test the UAC.

It is true that the PRACK transaction must be "alive" until the 200 OK
is received, but I assume all other "resources" can be released once the
199 is received.

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 25 Jun 2008 17:47:28 +0200

Hi Jeroen,

Forgive me if I don't understand what you are trying to say, but if you have an early dialog it means that you have received a non-100 provisional response with a to-tag.

Are you asking that I should indicate which state the entity is in when it sends the 199? Do you have some wording proposal?

Regards,

Christer 

-----Original Message-----
From: Jeroen van Bemmel [mailto:[email-masked]] 
Sent: 24. kesäkuuta 2008 21:23
To: Rockson Li (zhengyli)
Cc: Christer Holmberg; [email-masked]
Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00

Christer,

My point was to formalize the moment a 199 is sent by relating it to the
RFC3261 ICT state machine (BTW we're all silently assuming non-INVITE requests don't use provisional responses here) So associated with PROCEEDING-->COMPLETED, but indeed only if a to-tag was received before (so not only 100)

Regards,
Jeroen

Rockson Li (zhengyli) wrote:
>>> Should the 199 response contain a Contact header? And if yes, in 
>>> case a proxy sends it, should it contain the address of that proxy (since the UAS already sent a final response)?
>>>       
>>> receives a final error response on an INVITE client Transaction 
>>> which was in the PROCEEDING state? (i.e. 1xx response was received 
>>> before, so conceptually sending the 199 response is an action 
>>> associated with the transition from PROCEEDING to COMPLETED)
>>>       
>> I am not sure I understand. The idea IS to send 199 when a final 
>> error response is received by the forking proxy, if a 18x has previously been received.