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 PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
