Subject: [Sip] 199: Staus and open issues after Dublin

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 4 Aug 2008 11:25:11 +0200

Hi,

Based on the discussions in Dublin, it was agreed to move forward with
199 based on the following assumptions:

- We will not define an option-tag for 199 support.

- We will remove any text talking about adding a sipfrag body into the
199 response (potential future usage of 199 e.g. to solve HERFP would
define such procedures)

- A UAS IS allowed to send 199 (see more in the remaining open issues
section further down).

Please let me know if you have strong objections to any of these.

OPEN ISSUES, which we need to solve are:

1) Is a proxy allowed to send 199 in the first place, or are only UASes
allowed to do it?

2) Assuming proxies are allowed to send 199 (see issue 1), are proxies
allowed to send 199 reliably? It would mean that they need to terminate
the associated PRACK, which is claimed to not be normal proxy behavior.

3) Assuming proxies are allowed to send 199 (see issue 1), are proxies
allowed to send 199 unreliably, even if 100rel is required? 

Claims for:

- Since 199 is only an indciation, it can be seen as something similar
to 100 Trying, which is never sent reliably
- Proxies are not affected by the Require header, so even  if the
request contains 'Require: 100rel' it does not affect proxies

Claims against:

- It is not normal proxy behvior to trigger and send a non-100 response
in the first place.

4) Is it a MAY/RECOMMENDATION/SHOULD/MUST for UAS to send 199?

Please give your opinions :)

Regards,

Christer

- 

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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 04 Aug 2008 09:22:13 -0400

> 4) Is it a MAY/RECOMMENDATION/SHOULD/MUST for UAS to send 199?

IMO it is generally undesirable for the UAS to send the 199.

The whole point of the 199 is to serve as an optimization. In the 
absence of forking it is typically redundant, and will increase the 
amount of signaling in common cases, and so is counter productive. (My 
guess is that some large fraction, maybe more than half, of all calls 
are not answered by the intended target.)

It is typically a proxy, or another middle box such as a B2BUA, that is 
aware that forking is going on, and thus that there is state the UAC 
might want to know that won't otherwise be available to it. So I think 
the box that knows this should be the one to send the response.

I don't want to *ban* the UAS from sending the response, because it 
might be a middle box, and because even if it is the ultimate endpoint 
it *might* know the outcome of the call before it can finally send it.

Regarding *reliable* 199:

*If* the 199 is to be sent by a middle box, rather than by the UAS whose 
final response is being anticipated by the 199, then the main issue is 
what to-tag is to be used for the 199. The current proposal requires 
that the to-tag match that of the final response from the UAS. Things 
get very messy if the 199 is sent reliably under those conditions:

- the resulting PRACK will be sent in-dialog and thus will consume
   a CSeq value.

- the PRACK will need to be intercepted and handled by the middle box,
   rather than being allowed to follow its normal routing. (The UAS
   doesn't know the 199 was sent, and so won't expect a PRACK for it.)

- Potentially the middle box won't even be on the routing path for the
   PRACK, and so won't see it.

The bottom line for the above is that sending the 199 reliably using the 
to-tag of the UAS is a *terrible* ideal. A slightly less bad alternative 
would be to send the 199 with a to-tag belonging to the middle box 
sending it. But this just complicates things further:

- this new to-tag will create yet another early dialog.

- The 199 response will thus have to terminate both this new one,
   and the original one.

- There will have to be some new header to indicate which early dialog
   is to be terminated. (In addition to the one created by the to-tag
   of the 199 itself.)

So that seems like a bad idea too.

In any case, the 199 is just an optimization. The world will not end if 
it is not received. So an unreliable 199 seems to fit the bill just 
fine. So, I think the 199 should normally be sent unreliably. It could 
be sent reliably in those cases where it is being sent by the UAS 
possessing the to-tag of the dialog it pertains to. (Even when it *can* 
be sent reliably it is probably a bad idea to do so. It increases the 
required signaling, perhaps outweighing the value of this optimization.)

This does mean that some rules need to be relaxed so that it is 
permissible to send this unreliably even when Require:100rel has been 
specified by the UAC. (Perhaps what we ought to do in this regard is say 
that that reliable provisionals are only required when there is 
something essential in the message, such as an offer, answer, or target 
change.)

Perhaps instead of 199, this should be the 101 response, so that it 
appears closer to the 100 response that already gets special treatment.

	Thanks,
	Paul

> ------------------------------------------------------------------------
>

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 4 Aug 2008 15:17:00 -0500

I believe that the Requirents section for this draft is completely inadequate.
 
The only material in section 3 is the following:

	REQ 1: It must be possible to indicate to the UAC that an early dialog has been 
	terminated before a final response is sent.

This is almost as good as "REQ: It must be possible to do whatever this draft says".

This draft must really explain what it is trying to achieve. The Introduction has a bunch
of text that describes what looks and smells exactly like the HERFP problem.

In Dublin, it was stated that this draft does not attempt to solve the HERFP problem. If
that is the case, then I am completely baffled by what exactly is it trying to solve. Yes,
there is a little bit of wording about the need to "release resources" (whatever that means),
but I find it a little bit hard to swallow that we need new protocol for that.
_______________________________________________
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: Mon, 4 Aug 2008 22:28:36 +0200

Hi Francois,

As was agreed during the "requirements phase", we are not going to solve the HERPF problem as part of this task. Nobody objected to that. 

It was agreed that the scope is to only be able to indicate that the early dialog has been terminated.

I have tried to explain different kind of "resources" for which the mechanism could be useful. 

If you want to start a separate work item in order to solve (with or without using 199) other problems you are free to propose such work :) 

Regards,

Christer

---

From: "Brett Tate" <[email-masked]>
Date: Mon, 4 Aug 2008 19:00:23 -0400

> We will not define an option-tag for 199 support. 

Since the working group has issue with using option-tag, I propose
something else be added to request to indicate that something along the
path supports and desires receiving 199.

For instance, rfc4028 allows the UAC or proxy to include
Session-Expires.  A similar header (maybe generic one) could be defined
and optionally contain parameters (uac, proxy, etcetera); for instance,
"Desire-199:".

> 1) Is a proxy allowed to send 199 in the first 
> place, or are only UASes allowed to do it?

I have no issue with allowing it.  However the draft should likely
provide guidance if originator of 199 still considered a proxy or has
morphed into UAS/b2bua when using another's To tag.  Depending upon
interpretation of rfc3261 (and dropped packets), there are potential
issues concerning Contact and Record-Route of the 199 (unless remember
prior for inclusion within 199).  

What should occur when INVITE 2xx received after proxy originated 199
with the same To tag?

> 2) are proxies allowed to send 199 reliably?

I wouldn't consider it a proxy since it is trampling upon another's RSeq
and dialog (depending upon 199's Record-Route and Contact).

> 3) Assuming proxies are allowed to send 199 (see 
> issue 1), are proxies allowed to send 199 
> unreliably, even if 100rel is required? 

Concerning this and other non compliances, not sending the 199 would
likely be best to avoid violating rfc3261/rfc3262.

> 4) Is it a MAY/RECOMMENDATION/SHOULD/MUST for UAS to send 199? 

I prefer MAY.

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Tue, 5 Aug 2008 16:45:16 +0200

(As WG cochair)

The agreement in the SIPPING group where this was discussed was that we were not going to solve the HERPF problem. I think you will find a number of mails in the SIPPING archive confirming this.

It would be useful to identify and correct any text that you believe implies that the HERPF problem is to be solved.

Outside the HERPF problem I have no objection to clarifying the requirements and use cases. Please note that supposedly the SIPPING WG has already regarded these as complete. I would like to see clarification rather than feature creep.

Regards

Keith

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Christer Holmberg
> Sent: Monday, August 04, 2008 9:29 PM
> To: Francois Audet; [email-masked]
> Subject: Re: [Sip] Inadequate Requirements for draft-ietf-sip-199-00
> 
> 
> Hi Francois,
> 
> As was agreed during the "requirements phase", we are not 
> going to solve the HERPF problem as part of this task. Nobody 
> objected to that. 
> 
> It was agreed that the scope is to only be able to indicate 
> that the early dialog has been terminated.
> 
> If you want to start a separate work item in order to solve 
> (with or without using 199) other problems you are free to 
> propose such work :) 
> 
> Regards,
> 
> Christer
> 
> 
> 
> This draft must really explain what it is trying to achieve. 
> The Introduction has a bunch of text that describes what 
> looks and smells exactly like the HERFP problem.
> 
> In Dublin, it was stated that this draft does not attempt to 
> solve the HERFP problem. If that is the case, then I am 
> completely baffled by what exactly is it trying to solve. 
> Yes, there is a little bit of wording about the need to 
> "release resources" (whatever that means), but I find it a 
> little bit hard to swallow that we need new protocol for that.
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 5 Aug 2008 11:49:13 -0500

So let's clarify what we are trying to solve then.

If we remove HERFP, it seems the main "requirement" is for 
a UA to free up RAM for maintaining state information
when early dialogs terminate. 

And we are doing so by adding more protocol that will add more
states to keep track of.

I am extremely sceptical that this actually simplify anything.
Especially since it order to be backwards compatible, a
UA can not assume that a 199 will be sent to free up the "resources".
I find the incentive for anybody to implement this set of procedures
to be completely unconvincing. It seems to me that it add complexity
not remove any.

I was fooled into thinking at the previous meeting that we would 
then build on top of this proposal to actually solve a real problem
(like HERFP) as opposed to theoretical "resource optimization" problem.
If it looks like HERPF will not use this, then I fail to see any 
incentive to implement 199.

> From: DRAGE, Keith (Keith) [mailto:[email-masked]] 
> Sent: Tuesday, August 05, 2008 07:45
> To: Christer Holmberg; Audet, Francois (SC100:3055); [email-masked]
> Subject: RE: [Sip] Inadequate Requirements for draft-ietf-sip-199-00
> 
> (As WG cochair)
> 
> The agreement in the SIPPING group where this was discussed 
> was that we were not going to solve the HERPF problem. I 
> think you will find a number of mails in the SIPPING archive 
> confirming this.
> 
> It would be useful to identify and correct any text that you 
> believe implies that the HERPF problem is to be solved.
> 
> Outside the HERPF problem I have no objection to clarifying 
> the requirements and use cases. Please note that supposedly 
> the SIPPING WG has already regarded these as complete. I 
> would like to see clarification rather than feature creep.
> 
> Regards
> 
> Keith
> 
> > As was agreed during the "requirements phase", we are not going to 
> > solve the HERPF problem as part of this task. Nobody 
> objected to that.
> > 
> (with or 
> > without using 199) other problems you are free to propose 
> such work :)
> > 
> > Regards,
> > 
> > Christer
> > 
> > 
> > 
> > The Introduction has a bunch of text that describes what looks and 
> > smells exactly like the HERFP problem.
> > 
> > In Dublin, it was stated that this draft does not attempt 
> to solve the 
> > HERFP problem. If that is the case, then I am completely baffled by 
> > what exactly is it trying to solve.
> > Yes, there is a little bit of wording about the need to "release 
> > resources" (whatever that means), but I find it a little 
> bit hard to 
> > swallow that we need new protocol for that.
> > 
> > [email-masked] for questions on current sip Use 
> > [email-masked] for new developments on the application of sip
> > 
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 05 Aug 2008 13:40:37 -0400

I don't have strong feelings one way or another about this, but I think 
the resources being freed may be more than just some memory.
E.g. I think there can be DSPs assigned to process media for each early 
dialog.

But this is starting to get very complex, and I am being swayed in 
opposition to it. In particular, if the proxy must track the o/a state 
of the early dialog in order to decide if it can send a 199, then that 
starts to seem unreasonable to me.

	Thanks,
	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 5 Aug 2008 19:49:08 +0200

Hi Francois,

Nobody has said we will not work on solving the HERPF problem - potentially using 199. We only agreed not to do it as part of 199.

You are welcome to draft a proposal, and at least I would be very interested in working on that.  

Reading the use-cases, I think you will see that it's not only about "freeing up some RAM". It can be  used for network/bandwidth/media type-of resources.

It MAY also be part of a future solution for the forking-and-early-media solution, in cases where you can assoicate media with dialogs etc.  

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 5 Aug 2008 19:50:22 +0200

Hi,
 
>E.g. I think there can be DSPs assigned to process media for each early 

Correct. At least in many mobile terminals DSP resources are very limited.

>starts to seem unreasonable to me.

As I said in another reply, I don't think we shall require the proxy to maintain o/a state.

The whole idea was to come up with a relatively simple mechanism.

...which then of course may be used to solve complex problems (like HERPF).

Regards,

Christer

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 5 Aug 2008 12:59:59 -0500

All I am saying is that this solution seems to be to try to address a 
problem that is too narrow to justify the complexity and extra protocol
in this draft, and that the problem is not described properly in the draft.

If it helped with something else (like HEFP), then perhaps it would be useful.

I have heard in Dublin from Robert Sparks that "something else" (with no
details on what he has in mind) would be better to solve HERFP.

This is getting me extremely worried that we are jumping ahead too fast
on this 199 proposal, without a clear direction of where HERFP will take us.

To answer Keith's question: the whole introduction in Christer's draft 
(except the very last paragraph about undefined "saved resources") 
describes what the HERFP problem is, i.e., that when forking occurs,
final responses are not passed to the UAC and it causes problems. That
is what HERFP is.

I see it as very disingeneous that we are pretending that this has
nothing to do with HERFP when it very is clearly related to it.

> From: Christer Holmberg [mailto:[email-masked]] 
> Sent: Tuesday, August 05, 2008 10:49
> To: Audet, Francois (SC100:3055); DRAGE, Keith (Keith); [email-masked]
> Subject: VS: [Sip] Inadequate Requirements for draft-ietf-sip-199-00
> 
> 
> Hi Francois,
> 
> Nobody has said we will not work on solving the HERPF problem 
> - potentially using 199. We only agreed not to do it as part of 199.
> 
> Reading the use-cases, I think you will see that it's not 
> only about "freeing up some RAM". It can be  used for 
> network/bandwidth/media type-of resources.
> 
> It MAY also be part of a future solution for the 
> forking-and-early-media solution, in cases where you can 
> assoicate media with dialogs etc.

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 5 Aug 2008 21:15:33 +0200

Hi,
 
>in this draft, and that the problem is not described properly in the draft.

Again, the idea is to make it as little complex as possibly, and that is why we are discussing a number of issue in order not to make it too complex.

>If it helped with something else (like HEFP), then perhaps it would be useful.

It may help with HERPF.

>details on what he has in mind) would be better to solve HERFP.

We need to look into th alternatives when they are available.

>final responses are not passed to the UAC and it causes problems. That

To me HERFP is a little more than that. HERFP also talks about SIP procedures taking place after the UAC has received the information: sending new INVITEs etc.

199 was also presented at the previous 3GPP CT1 meeting, and people agreed it would be a useful mechanism. 3GPP has never discussed HERFP, however, but only issues related to forking and resources. So, there is a need for this even without a HERFP solution.

Regards,

Christer

---

From: Anders Kristensen <[email-masked]>
Date: Tue, 05 Aug 2008 20:20:28 -0700

I don't think it's just about releasing resources like memory. In fact, 
the draft does mention that it can help a UAC determine when to start 
rendering a different (early) audio stream. That seems pretty useful.

That said, I'm sure we're all in favor of simplicity and reuse of mechanism.

Thanks,
Anders

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 06 Aug 2008 07:59:04 -0400

> rendering a different (early) audio stream. That seems pretty useful.

I don't see how that would work. As it is there is really no general way 
to distinguish which early signaling session a given incoming media 
stream corresponds to. In any case, one would expect that media would 
not be sent by an early session that has been terminated. When you stop 
receiving media from one source you should start rendering something else.

	Thanks,
	Paul

>>> From: Christer Holmberg [mailto:[email-masked]] Sent: 
>>> Tuesday, August 05, 2008 10:49
>>> Nobody has said we will not work on solving the HERPF problem - 
>>> potentially using 199. We only agreed not to do it as part of 199.
>>>
>>> Reading the use-cases, I think you will see that it's not only about 
>>> "freeing up some RAM". It can be  used for network/bandwidth/media 
>>> type-of resources.
>>>
>>> forking-and-early-media solution, in cases where you can assoicate 
>>> media with dialogs etc.

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 6 Aug 2008 14:07:30 +0200

Hi, 

>>I don't think it's just about releasing resources like memory. In
fact, the draft does mention that it can help a UAC determine when to 
>>start rendering a different (early) audio stream. That seems pretty
useful.
>
>I don't see how that would work. As it is there is really no general
way to distinguish which early signaling session a given incoming media
stream corresponds to. In any case, one would expect 
>that media would not be sent by an early session that has been
terminated. When you stop receiving media from one source you should
start rendering something else.

Just because you stop receiving media it doesn't automatically mean the
dialog is terminated, or that you would want to start listening to
another stream. There may simply be a pause.

I DO agree, however, that there is currently no general way to associate
media with dialogs. In cases where you have security associations for
the media it may be possible, however (I am no expert on that, though).

But, the how-to-associate-media-with-dialogs has also been discussed
every now and then, and there seems to be interest among people (both in
IETF and other SDOs) to start working on a general solution. But, that
work would also be outside the scope of 199 (I guess it wouldn't
necessarily even be done in SIP/SIPPING - at least not without
involvement of other groups).

Regards,

Christer

>> problem that is too narrow to justify the complexity and extra 
>> protocol in this draft, and that the problem is not described 
>> properly in the draft.
>>
>> I have heard in Dublin from Robert Sparks that "something else" (with

>> no details on what he has in mind) would be better to solve HERFP.
>>
>> This is getting me extremely worried that we are jumping ahead too 
>> fast on this 199 proposal, without a clear direction of where HERFP 
>> will take us.
>>
>> To answer Keith's question: the whole introduction in Christer's 
>> draft (except the very last paragraph about undefined "saved 
>> resources") describes what the HERFP problem is, i.e., that when 
>> forking occurs, final responses are not passed to the UAC and it 
>> causes problems. That is what HERFP is.
>>

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 6 Aug 2008 15:56:18 +0200

Hi Brett,

Session-Expires.  A similar header (maybe generic one) could be defined
and optionally contain parameters (uac, proxy, etcetera); for 
>instance, "Desire-199:".

The group never discussed if there is any "issue" with using an
option-tag (e.g. if proxies are allowed to insert values). The opinion
was more that there is no need for any sort of indication.

>>1) Is a proxy allowed to send 199 in the first place, or are only
UASes allowed to do it?
provide guidance if originator of 199 still considered a proxy or has
morphed into UAS/b2bua when using another's To tag.  
>Depending upon interpretation of rfc3261 (and dropped packets), there
are potential issues concerning Contact and Record-Route of the 199
(unless remember prior for inclusion within 199).  
with the same To tag?

I am not sure how that could happened. If the proxy received a final
response, which triggered the 199, I don't think it will later receive
an 2xx with the same To tag.

>I wouldn't consider it a proxy since it is trampling upon another's
RSeq and dialog (depending upon 199's Record-Route and Contact).

I think it's rather clear that people don't want proxies to send proxy
originated 199 responses reliably. Or, does anyone have another opinion?

Ok. This is one of the issues still discussed.

>>4) Is it a MAY/RECOMMENDATION/SHOULD/MUST for UAS to send 199? 

Ok.

Thanks for your comments!

Regards,

Christer

---

From: "Brett Tate" <[email-masked]>
Date: Wed, 6 Aug 2008 11:27:19 -0400

Hi Christer,

Thanks for response.  Reply inline. 

> The group never discussed if there is any "issue" with 
> using an option-tag (e.g. if proxies are allowed to 
> insert values). The opinion was more that there is no 
> need for any sort of indication.

After Cullen mentioned the reason for it, I guess that I should stayed
at the microphone and re-iterated the reasons.

Sending 199 is useless overhead unless something along the path supports
and wants it.  

If UAC does not support 199, sending it might cause more harm than good.

> > I have no issue with allowing it.  However the draft 
> > should likely provide guidance if originator of 199 
> > still considered a proxy or has morphed into UAS/b2bua when 
> > using another's To tag.  Depending upon interpretation of 
> > rfc3261 (and dropped packets), there are potential issues 
> > concerning Contact and Record-Route of the 199 (unless 
> > remember prior for inclusion within 199).  
> >
> > What should occur when INVITE 2xx received after proxy 
> > originated 199 with the same To tag?
> 
> I am not sure how that could happened. If the proxy received 
> a final response, which triggered the 199, I don't think it 
> will later receive an 2xx with the same To tag.

If no proxy steals another's To tag for originating a final INVITE
response, I agree.  I don't recall what rfc3261 and invfix recommend
concerning the abnormal situation from proxy and UAC perspectives.  I
was mainly just asking for conceptual reasons based upon the paragraph
prior to my question.  If it occurs, should the originator of 199 tag X
process the 2xx tag X like a UAC or proxy?
_______________________________________________
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: "Francois Audet" <[email-masked]>
Date: Wed, 6 Aug 2008 12:32:16 -0500

> I DO agree, however, that there is currently no general way 
> to associate media with dialogs. In cases where you have 
> security associations for the media it may be possible, 
> however (I am no expert on that, though).
> 
> But, the how-to-associate-media-with-dialogs has also been 
> discussed every now and then, and there seems to be interest 
> among people (both in IETF and other SDOs) to start working 
> on a general solution. But, that work would also be outside 
> the scope of 199 (I guess it wouldn't necessarily even be 
> done in SIP/SIPPING - at least not without involvement of 
> other groups).

This is what worries me: we are defining micro-procedures that
don't really address the whole problem with the vague hope that
one day it will actually be useful. MAYBE it will help with 
media stream choosing. MAYBE it will help with HERFP.

I find it unproductive to standardized protocol before we
know if it actually helps in fixing actual problems.

So don't get me wrong: I am not against us working on 199. I
just don't think we should RFC it before we have progressed
along the rest of the procedures that would actually make it
useful in the real world. If this is done through different drafts,
be it. But there is definitively inter-dependency between them.
_______________________________________________
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, 6 Aug 2008 20:06:50 +0200

Hi,

>know if it actually helps in fixing actual problems.

There are already problems which 199 CAN solve, without any other work.

And, regarding associating media with dialogs, I belive it today can be done at least when SRTP is used - without any further work. I haven't looked into other media security mechanisms.

>be it. But there is definitively inter-dependency between them.

The purpose of 199 is to provide a mechanism indicating that an early dialog has been terminated. Period. There are some details we need to sort out, but at the end of the day there aren't that many different directions we can go as far as the basic purpose of 199 is concerned.

IF we at some point want to use 199 for HERPF, we can easily say that entities which support it shall insert a sipfrag in the 199 response. That is why we decided not to say anything about it, so that we don't forbid it for future use.

IF we at some point get a general mechanism to associate dialogs with headers, and that mechanism uses e.g. some new SIP headers, nothing prevents us from using those in 199.

Etc etc etc.

There IS a need for "basic 199 functionality" today. Based on previous work, solving the HERPF problem etc can take quite a while, and I see no reason to delay 199 just because of that. That will again cause delays and show inefficiency, when we try to save the world in one single go. Instead I think we shall try not to restrict things for no good reason (something we should also keep in mind for other work we do), in case it may be needed later.   

Regards,

Christer

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 6 Aug 2008 13:12:53 -0500

> There are already problems which 199 CAN solve, without any 

And those are?

They should be clearly described. All I hear is examples of things where
199 is not sufficient (e.g., Media choosing, HERFP). 

If SRTP actually solves the problem for media choosing, then let's state it in the 
document.

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 6 Aug 2008 20:37:35 +0200

Hi,
 
>199 is not sufficient (e.g., Media choosing, HERFP). 

I have tried to describe examples not related to media choosing.

One example is related to in-band procedures (e.g. ICE, in-band security negotiations). At least in the mobile world those can consume radio- and battery resources, so it is good to be informed about terminated dialogs as soon as possible, without having to detect it using re-transmission failures etc.

Another example in the mobile world is related to codecs and DSP resources. If you have negotiated codec X only for one early dialog, and that dialog is terminated, you know that you can free the codec X resources (you can do that without having to be able to associate media with dialogs) and e.g .. allow reservation of other codecs needed for other dialogs. Especially when we move into the world of multimedia, using video etc, this kind of functionality becomes important. 

Another example in the mobile world is radio resources. In case of forking and multiple stream there may not be possible to allow early media on all dialogs, so some dialogs may e.g. be set to "inactive". It is then very useful to know when a dialog is terminated, so that media can be allowed on other dialogs. How those inactive decissions are made is based on local policy etc, but 199 provides a tool which is useful for taking those decissions.

Due to the cases above, and others, terminals may restrict the number of accepted SIP dialogs, so by knowing when one dialog has been terminated it can accept another dialog.

These are not theoretical issues, but problems that exist today. Maybe not in your PC with unlimited memory, connected to fixed access with unlimited bandwidth, but in some other places :)

>If SRTP actually solves the problem for media choosing, then let's state it in the 

Sure, I can do that.

Regards,

Christer

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 6 Aug 2008 13:43:51 -0500

Ok, now we are getting somewhere.

Can you describe that in the document.

Also, in the REQ section, let's write requirements that are specific
and are able to address the problems you listed below.

The ICE/DTLS-SRTP one is quite important.  

> Sent: Wednesday, August 06, 2008 11:38
> To: Audet, Francois (SC100:3055); Paul Kyzivat; Anders Kristensen
> Cc: [email-masked]; DRAGE, Keith (Keith)
> One example is related to in-band procedures (e.g. ICE, 
> in-band security negotiations). At least in the mobile world 
> those can consume radio- and battery resources, so it is good 
> to be informed about terminated dialogs as soon as possible, 
> without having to detect it using re-transmission failures etc.
> 
> Another example in the mobile world is related to codecs and 
> DSP resources. If you have negotiated codec X only for one 
> early dialog, and that dialog is terminated, you know that 
> you can free the codec X resources (you can do that without 
> having to be able to associate media with dialogs) and e.g .. 
> allow reservation of other codecs needed for other dialogs. 
> Especially when we move into the world of multimedia, using 
> video etc, this kind of functionality becomes important. 
> 
> Another example in the mobile world is radio resources. In 
> case of forking and multiple stream there may not be possible 
> to allow early media on all dialogs, so some dialogs may e.g. 
> be set to "inactive". It is then very useful to know when a 
> dialog is terminated, so that media can be allowed on other 
> dialogs. How those inactive decissions are made is based on 
> local policy etc, but 199 provides a tool which is useful for 
> taking those decissions.
> 
> Due to the cases above, and others, terminals may restrict 
> the number of accepted SIP dialogs, so by knowing when one 
> dialog has been terminated it can accept another dialog.
> 
> These are not theoretical issues, but problems that exist 
> today. Maybe not in your PC with unlimited memory, connected 
> to fixed access with unlimited bandwidth, but in some other places :)
> 
> >If SRTP actually solves the problem for media choosing, then let's 
> >state it in the document.
> 
> Sure, I can do that.
> 
> Regards,
> 
> Christer
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 6 Aug 2008 20:53:12 +0200

Hi,

>Sending 199 is useless overhead unless something along the path supports

Correct. But useless can still be harmless :)

Personally I don't care what we do - I simply indicated what seemed to be the agreement at the meeting.

>If UAC does not support 199, sending it might cause more harm than good.

A UAC should discard what it doesn't support.

One potential use for an indicator could be if we decide to allow sending of 199 unreliably even if 100rel is required. An indicator would then make sure that the UAC is prepared for that.

But, even if the UAC doesn't support 199, receiving it unreliably even if 100rel is required should not in my opinion cause problems in a good and robust UAC implementation. The UAC should simply discard it.  

Maybe this should be discussed as part of the sending-199-unreliably-even-if-100rel-is-required discussion...

>process the 2xx tag X like a UAC or proxy?

I don't think a forking proxy would steal a tag when forwarding 200 OK, because the UAC needs to know   which dialog it belongs to. Maybe it could steal a tag when sending an error response, but in that case I guess it doesn't matter very much. I guess the UAC could simply ACK it.

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 6 Aug 2008 20:58:49 +0200

Hi,
 
>Can you describe that in the document.

I thought I had done that in the use-case section, but for sure I can have another look at the use-case text and see whether I can clarify/extend the text.

>and are able to address the problems you listed below.

Well, I think the use-cases justifies the existing requirement. Do you want to have specific requirement for all the use-cases?

Regards,

Christer

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 6 Aug 2008 14:02:24 -0500

> Well, I think the use-cases justifies the existing 
> requirement. Do you want to have specific requirement for all 
> the use-cases?

Yes.

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 6 Aug 2008 21:15:17 +0200

Hi,

>>requirement. Do you want to have specific requirement for all 

Again, I thought we normally use use-cases in order to justify the requirement(s). All use-cases justify the same requirement: being able to indicate that the early dialog has been terminated.

Regards,

Christer

---

From: "Brett Tate" <[email-masked]>
Date: Wed, 6 Aug 2008 16:15:01 -0400

> > Sending 199 is useless overhead unless something 
> > along the path supports and wants it.
> 
> Personally I don't care what we do - I simply 
> indicated what seemed to be the agreement at the meeting.

The "harmless" uselessness would likely depend upon the frequency of 199
versus the extra option-tag or header to negotiate the mechanism.

I don't have a strong opinion about the need for negotiating the
mechanism.  I'm just trying to avoid some unnecessary interop issues and
capacity hits.

> A UAC should discard what it doesn't support.

RFC 3261 section 8.1.3.2: "A UAC MUST treat any provisional response
different than 100 that it does not recognize as 183 (Session
Progress)."

The above requirement adds complication for devices (not supporting 199)
only maintaining a limited number of early dialogs or using latest 1xx
to recognize most likely active early dialog.

The 199 could trigger them to forgot or not prefer a useful early dialog
for the one associated with 199.

> > If no proxy steals another's To tag for originating 
> > a final INVITE response, I agree.  I don't recall 
> > what rfc3261 and invfix recommend concerning the 
> > abnormal situation from proxy and UAC perspectives.  
> > I was mainly just asking for conceptual reasons 
> > based upon the paragraph prior to my question.  
> > If it occurs, should the originator of 199 tag X 

<snip>

> Maybe it could steal a tag when sending an error 
> response, but in that case I guess it doesn't 
> matter very much. I guess the UAC could simply ACK it.

Yes, my question was mainly concerning situation caused by proxies that
incorrectly use another's early dialog To tag when originating a failure
INVITE response like 487 when no final INVITE response has been
received.  Hopefully there are no longer proxies that actually do it. :)
If the 199 originator uses such a tag to send 199 and INVITE 200
received using the same tag, I was curious how the 199 originator should
behave (as proxy or UAC).  If it proxies the INVITE 200, the call might
actually get established and stay up when UAC does not support 199 or
199 was dropped.
_______________________________________________
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: Thu, 7 Aug 2008 07:32:50 +0200

Hi Brett,

>
>The above requirement adds complication for devices (not supporting
199) only maintaining a limited number of early dialogs or using latest
1xx to recognize most likely active early dialog.
>
>The 199 could trigger them to forgot or not prefer a useful early
dialog for the one associated with 199.

Wouldn't that mean that, if the UAC does not insert the indicator,
proxies are not allowed to insert it either? Because, if they do, and
receive 199 I guess they will simply forward the 199 towards the UAC,
and you end up in the same situation. An intermediate B2BUA could of
course terminate the 199, and not forward it towards a UAC not
supporting it, but I don't think we want to define such behavior for
normal proxies.

>>>concerning the abnormal situation from proxy and UAC perspectives.
>>>I was mainly just asking for conceptual reasons based upon the 
>>>paragraph prior to my question.
>>>If it occurs, should the originator of 199 tag X process the 2xx tag 
>>>X like a UAC or proxy?
>> 
>>
>><snip>
>>
>>Maybe it could steal a tag when sending an error response, but in that

>>case I guess it doesn't matter very much. I guess the UAC could simply

>>ACK it.
incorrectly use another's early dialog To tag when originating a failure
INVITE response like 487 when no final INVITE 
>response has been received.  Hopefully there are no longer proxies that
actually do it. :) If the 199 originator uses such a tag to send 199 and
INVITE 200 received using the same tag, I was 
>curious how the 199 originator should behave (as proxy or UAC).  If it
proxies the INVITE 200, the call might actually get established and stay
up when UAC does not support 199 or
>199 was dropped.

In this case I guess the UAC could simply send ACK + BYE. It may not be
the desired behavior, but could be the result of badly "tag stealing"
behaving proxies.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 07 Aug 2008 07:53:14 -0400

> supporting it, but I don't think we want to define such behavior for

If we postulate such an indicator, then why would a proxy *want* to 
insert it? I agree it would be a bad thing.

	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 7 Aug 2008 13:58:14 +0200

Hi, 

Progress)."
>>>199) only maintaining a limited number of early dialogs or using 
>>>latest 1xx to recognize most likely active early dialog.

I guess proxies would normally NOT insert it, since they normally don't
control media resources etc. However, I guess e.g. an P-CSCF could be
interested in inserting the indicator if not received from the UE. 

But, if we choose to define an indicator I guess a P-CSCF that wants to
do such thing would have to act as a B2BUA.

That also means we could use an option-tag.

Regards,

Christer