[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[MMUSIC] ICE, TURN, and QoS interactions
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?
Thanks
Kevin
Johns
_______________________________________________
mmusic mailing list
mmusic at ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic