Re: [MMUSIC] ICE, TURN, and QoS interactions

[RÃmi Denis-Courmont <Remi.Denis-Courmont at nokia.com>]

On Friday 07 September 2007 22:26:24 ext Kevin Johns wrote:
> While looking at ICE, TURN, and QoS interactions I am struggling with a
> scenario that I would like to see if others have any thoughts on.
>
> The driver for this is a desire to ensure necessary overhead for STUN
> Data/Send Indications are accounted for in QoS allocations prior to an
> active destination being set by the UA.
>
> ICE does not appear to provide any guidance on when the UA should set
> the active destination. Section 12.1.1 of ICE talks about interactions
> with SIP and requires that no media be sent till a valid candidate for
> each component has entered the valid list. If the valid candidate is a
> relayed candidate and media begins to flow, should the UA first set the
> active destination or send the media wrapped in a STUN Send Indication
> and only set the active destination at some later point in the call
> flow? I would think you want to set the active destination as soon as
> possible to avoid the extra overhead, but was unsure what the
> implications of such an approach might be. If the expectation is to
> always set the active destination prior to sending media, then the QoS
> calculations would not need to account for any additional overhead.
>
> Is there a case where media would begin flowing but the UA would be
> unable to set the active destination?

If it keeps changing its "primary" peer.

Otherwise, you mostly have send/data indications while forking.

-- 
RÃmi Denis-Courmont
Software engineer

_______________________________________________
mmusic mailing list
mmusic at ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic