Re: [MMUSIC] Trickle ICE for SIP Questions

["Stach, Thomas" <[e-mail]>]

Paul,

> -----Original Message-----
> From: Paul Kyzivat [mailto:[e-mail]]
> Sent: Monday, 08 July, 2013 18:05
> To: Stach, Thomas
> Cc: [e-mail]
> Subject: Re: [MMUSIC] Trickle ICE for SIP Questions
> 
> Just responding to things that haven't already been covered.
> 
> On 7/8/13 5:44 AM, Stach, Thomas wrote:
> 
> >> Yes, why is it such an issue to require PRACK?
> > [TS] I see potential for easier GW/SBC interworking with vanilla-ICE
> UAs, that did not implement PRACK
> 
> I don't get it.
> 
> If you are talking about SBCs that terminate/relay media, then the leg
> doing trickle-ICE is separate from the leg doing vanilla-ICE. So what
> is
> the issue?

> 
> And if you have a signaling-only SBC, and one leg supports trickle-ICE
> while the other side supports only vanilla-ICE, then just use
> vanilla-ICE e2e. You won't gain anything by an intermediary trying to
> map trickle-ICE to vanilla-ICE.
[TS] 
If the trickle-ICE side uses PRACK and the vanilla ICE side does not, the interworking SBC does not only have to collect the trickled candidates and send it on as a bunch once trickling finished. It also has to interwork PRACK.
As you know the PRACK request can contain a new SDP offer or you could also use UPDATE for another SDP O/A before the 200 OK to the INVITE request. This is rather nasty to interwork if not impossible.

> 
> >> It is a good thing to implement for many reasons.
> > [TS] There are also good reasons against PRACK. e.g. the much more
> complicated state machine.
> 
> Yes, but once you have done it then it is there to use for all sorts of
> things. The alternative seems to be to instead introduce a lot of new
> complexity that is *only* applicable to trickle-ICE.
> 
> 	Thanks,
> 	Paul