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