Subject: [Sip] draft-ietf-sip-199 use-cases

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 17 Nov 2008 23:38:28 -0500

Howdy,
In the SIP WG today there was a discussion on whether 199 was just an optimization, and what its benefits/use-cases are that warrant working on it.  I read the draft but I didn't grok what the big deal/need for it was.  It keeps talking about "resources" as if that's some big limiting factor that saving a few dozen seconds-worth of would be a big advantage.  I understand DSP resource limitations but I couldn't see how you were going to truly save them just because you get a 199, because as far as you know there will be other forks that will use those codecs too so until the 200 ok comes back you can't unallocate them.  So then I thought maybe the draft was referring to bandwidth, but AFAIK most folks don't reserve bandwidth for all forks because they know only one of them will succeed in the end, so they pick the worst one until the call is answered.

But I think there are some real use-cases for this 199 response, that are *more* than an optimization: they affect user experience. (which is much more important IMO)

        Case 1: You're a basic endpoint or PSTN Gateways the UAC, and have to pick one of many 183 w/SDP responses for which to play early media for.  Typically they pick the first one received, and don't change until the 200 ok. (some pick the most recently received one instead, but that's just guessing too)  So if I call Bob, and it went to a simple find-me-follow-me service, the service plays "we're looking for Bob, please hold...".  Once it finds Bob, and Bob's phone rings, I would like my UAC to stop listening to the announcement and instead switch to Bob's ringback.  So the proxy needs to send my UAC the 199.

        Case 2: Your call went through some evil SBC thingy, which is doing NAT traversal fixing for the far-end.  Typically SBC's "latch" onto the RTP stream from the far-end, such that they only forward media to the latched address, and only allow media back through from that far-end.  They can play tricks to let media move, but typically if the call forked there is no moving from the first latched one until the 200 ok, because they know the UAC can only play one of the streams anyway, and they don't bother allocating more hardware for naught; and if the UAC was itself behind a NAT then there's only one pinhole to get media back through anyway.  So if a 199 were sent back from the forking proxy, it would let the SBC re-latch or pick another flow, and get the other media through, even by sending it back through the same single NAT pinhole.  Again, it's not so much a resource thing - it's a user experience thing.

        Case 3: SRTP.  Like the latching case, middle-boxes or gateways that terminate SRTP typically only terminate it for one of the forks, because again they themselves can only render one, or they assume the UAC will only play one RTP stream anyway, and only one will get through the SBC's or NAT pinholes to begin with, so allocating more SRTP hardware crypto engines for multiple forked response SDP's/keys has no value.  So like the SBC case, if they got the 199, they could change their SRTP hardware to start decrypting another fork's keys, and the user would hear something different.

-hadriel

_______________________________________________
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: Tue, 18 Nov 2008 17:49:03 +0100

Hi Hadriel, 

>In the SIP WG today there was a discussion on whether 199 was just an
optimization, and what its benefits/use-cases are 
>that warrant working on it.

I guess it depends on what we mean by "optimiztion". The new thing is
that thee UAC can get informed about terminated early dialogs when it
happens. Is that only optimization, or is it also new functionality?

>I read the draft but I didn't grok what the big deal/need for it was.
It keeps talking 
>about "resources" as if that's some big limiting factor that saving a
few dozen seconds-worth of would be a big 
>advantage.  I understand DSP resource limitations but I couldn't see
how you were going to truly save them just because 
>you get a 199, because as far as you know there will be other forks
that will use those codecs too so until the 200 ok 
>comes back you can't unallocate them. 

There MAY be other forks that use the codecs.

And, it's not only about the number of different codecs used, but for
how many media sessions the UA manages to use a specific fork.

>So then I thought maybe the draft was referring to bandwidth, but AFAIK
most folks don't reserve bandwidth for all forks 
>because they know only one of them will succeed in the end, so they
pick the worst one until the call is answered.

It is true that Uas in many cases will not reserved bandwidth for an
unlimited number of forks. BUT, they are still required to provide
quality for the forks they DO accept, which means they may only accept a
certain number of early dialogs. So, in those cases it is good to know
when a previously used early dialog is not used anymore, so that another
early dialog can be accepted instead.

>But I think there are some real use-cases for this 199 response, that
are *more* than an optimization: they affect user 
>experience. (which is much more important IMO)

The examples above ARE real-life issues - at least in the
mobile-wireless-limited-bandwidth-limited-dsp-limited-battery-limited-me
mory environment where I am working. The reason I started to work with
the draft in the first place was in order to be able to use to solve
(or, at least ease) such problems.

>Case 1: You're a basic endpoint or PSTN Gateways the UAC, and have to
pick one of many 183 w/SDP responses for which to 
>play early media for.  Typically they pick the first one received, and
don't change until the 200 ok. (some pick the 
>most recently received one instead, but that's just guessing too)  So
if I call Bob, and it went to a simple find-me-
>follow-me service, the service plays "we're looking for Bob, please
hold...".  Once it finds Bob, and Bob's phone rings, 
>I would like my UAC to stop listening to the announcement and instead
switch to Bob's ringback.  So the proxy needs to 
>send my UAC the 199.

Correct. That is how many gateways/UACs work today, and one use-case
I've had in mind where 199 could be useful. The reaons I didn't add it
to the draft before was because it is not so much related to resources,
but more to early dialog policy, but for sure I could add it to the
draft.

>Case 2: Your call went through some evil SBC thingy, which is doing NAT
traversal fixing for the far-end.  Typically 
>SBC's "latch" onto the RTP stream from the far-end, such that they only
forward media to the latched address, and only 
>allow media back through from that far-end.  They can play tricks to
let media move, but typically if the call forked 
>there is no moving from the first latched one until the 200 ok, because
they know the UAC can only play one of the 
>streams anyway, and they don't bother allocating more hardware for
naught; and if the UAC was itself behind a NAT then 
>there's only one pinhole to get media back through anyway.  So if a 199
were sent back from the forking proxy, it would 
>let the SBC re-latch or pick another flow, and get the other media
through, even by sending it back through the same 
>single NAT pinhole.  Again, it's not so much a resource thing - it's a
user experience thing.

Correct. It even doesn't have to be a full scale SBC. It could also be a
gating type of function. 

I could add that example also, but I want to avoid
we-make-this-just-because-SBCs-have-problems type of comments :)

>Case 3: SRTP.  Like the latching case, middle-boxes or gateways that
terminate SRTP typically only terminate it for one 
>of the forks, because again they themselves can only render one, or
they assume the UAC will only play one RTP stream 
>anyway, and only one will get through the SBC's or NAT pinholes to
begin with, so allocating more SRTP hardware crypto 
>engines for multiple forked response SDP's/keys has no value.  So like
the SBC case, if they got the 199, they could 
>change their SRTP hardware to start decrypting another fork's keys, and
the user would hear something different.

Correct. I think the draft does talk about media plane security, but
maybe mostly on the in-band negotiation part.

Regards,

Christer

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 20 Nov 2008 00:02:53 +0000

Christer, 

> but more to early dialog policy, but for sure I could add it to the
[JRE] Personally I think this is a more compelling use case.

John

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 20 Nov 2008 05:54:30 +0100

Hi, 

>>play early media for.  Typically they pick the first one
>>received, and don't change until the 200 ok. (some pick the most
recently received one instead, but that's just Z
>>guessing too)  So if I call Bob, and it went to a simple
find-me-follow-me service, the service plays "we're looking 
>>for Bob, please hold...".  Once it finds Bob, and Bob's phone rings,
>to the draft before was because it is not so much related to 
>resources, but more to early dialog policy, but for sure I could add 
>it to the draft.

I'll add it to the draft.

Regards,

Christer