[SIPForum-techwg] Reliable provisional responses in SIPconnect1.1

[Johnston, Alan B (Alan)]

I agree 100% with John. Making PRACK mandatory just adds complexity to
this specification.  And saying that early media does not work without
it is just plain wrong.

The whole point of doing 1.1 was to reduce and refine this spec, getting
rid of things that are not completely necessary.  To do otherwise is to
fail at our task at hand.

See a few comments below.

Thanks,
Alan

-----Original Message-----
From: techwg-bounces at sipforum.org [mailto:techwg-bounces at sipforum.org]
On Behalf Of Elwell, John
Sent: Wednesday, October 01, 2008 5:36 AM
To: Hadriel Kaplan; techwg at sipforum.org
Subject: Re: [SIPForum-techwg] Reliable provisional responses in
SIPconnect1.1

Hadriel, 

> -----Original Message-----
> From: Hadriel Kaplan [mailto:HKaplan at acmepacket.com] 
> Sent: 01 October 2008 06:50
> To: Elwell, John; techwg at sipforum.org
> Subject: RE: Reliable provisional responses in SIPconnect 1.1
> 
> 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.
[JRE] Good point, since with an offer-less INVITE, you can't send SDP
offer in an unreliable response, and waiting for the 200 OK would deny
the possibility of early media. So perhaps an IP-PBX that supports the
sending of offerless INVITEs MUST support 100rel, and a SP that supports
early media in response to offerless INVITEs MUST support 100rel.

AJ> If you send an offer-less INVITE, you can expect to have some media
clipping.  We are not going to support all kinds of offer/answer
scenarios - this is a huge source of interop failure with SIP.  We do
not want to mandate this in SIPConnect.


> 
> 
> > 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. :)  
[JRE] Probably not that soon, but the point I was making was avoid
making things mandatory now that would not be needed in the longer term.
It sounds like a good principle, although it might not be practicable in
this particular case.


AJ> The point is that PRACK is a bad SIP extension and a dead-end in
terms of future development of the protocol.  We should drop it sooner
rather than later.

> BTW, DTLS-SRTP does 
> not achieve the same result, fwiw, and even ICE should work 
> better with reliable provisional responses.
[JRE] Why would ICE work better - wouldn't the STUN packets typically
get there quicker than PRACK? I guess not if you have to wait for
several candidates to be tried before one gets through, but in the
majority of cases I would have thought it would work better (if better
means faster).

> 
> > 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.
[JRE] Agreed.

>  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.
[JRE] Well, offerless INVITES apart, if you support PRACK you
essentially have to repeat the 18x if you get a timeout. You can repeat
an unreliable 18x at intervals anyway, although the recommended
frequency is too slow. However, if you really want to increase the
chances of an unreliable 18x arriving, repeat it a couple of times, with
a delay of say 2*T1 before each retransmission. Note that the early
media RTP itself is also not guaranteed to arrive, so ensuring that the
UAC has received the SDP answer will not ensure that it receives early
media.

I don't necessarily disagree with your points. I just want to explore
whether there is a way of avoiding mandating 100rel.

John

_______________________________________________
techwg mailing list
Send mail to: techwg at sipforum.org
Unsubscribe or edit options at:
http://sipforum.org/mailman/listinfo/techwg