[SIPForum-techwg] Reliable provisional responses in SIPconnect 1.1
Hadriel Kaplan
HKaplan at acmepacket.com
Wed Oct 1 01:49:35 EDT 2008
Hey John,
Inline...
> -----Original Message-----
> From: techwg-bounces at sipforum.org [mailto:techwg-bounces at sipforum.org] On
> Behalf Of Elwell, John
>
> There was also an opposing view that suggested that RFC 3262 support
> should be mandatory for IPPBXs. The reason given was that a service
> provider wanting to provide early media would want to be sure that SDP
> answer in a provisional response reaches the IP-PBX.
It's actually for either side really - some Enterprises need it too. And for those which send offer-less Invites it's even more important.
> However, this would
> raise the bar for adoption by IP-PBXs.
Yes, it would. PRACK sucks due to the offer/answer complexity it creates. But providing ring-tone and announcements is a pretty big deal. :(
> The mechanism is know to be
> rather complex, and the need for it will be diminished or even removed
> in the future as ICE and DTLS-SRTP get deployed (since in-band
> mechanisms will achieve the desired result).
Uh huh. That'll be real soon now. :) BTW, DTLS-SRTP does not achieve the same result, fwiw, and even ICE should work better with reliable provisional responses.
> Furthermore, assuming TCP transport, the only benefit of reliable
> provisional responses is when a SIP intermediary somehow "loses" the
> SDP.
That's assuming TCP transport for the whole path, not just the Ent-SP hop.
> Also the mechanism is not helpful if SIP intermediaries (B2BUA)
> generate PRACK on a hop-by-hop basis, rather than ensuring it operates
> end-to-end.
Indeed, that's exactly what I'm trying to avoid. We fought off doing that for years and eventually succumbed to customer demand, but it sucks to do it. If we don't mandate support for PRACK, then B2BUA's will continue to need to "interwork" it for those devices which Require it. (and yes, I've tried to tell them to stop Requiring it)
In fact, I suggest we put in a "MUST NOT Require it in Requests" - where "Require" means putting it in the Require header of a request. That's bad mojo.
"MUST Support it" is a different thing, as you know. If we don't put in a "MUST Support", then we can't assure early media.
-hadriel
More information about the techwg
mailing list