28 Apr
2014
28 Apr
'14
11:57 p.m.
It's in the ICE spec. I can't remember all the details.
Try to make a call between two ICE clients that are using UPDATE to
confirm the negotiated stream (I think with prflx candidates).
Regards,
Ovidiu Sas
On Mon, Apr 28, 2014 at 4:41 PM, Richard Fuchs <rfuchs(a)sipwise.com> wrote:
On 28/04/14 04:21 PM, Ovidiu Sas wrote:
--
VoIP Embedded, Inc.
http://www.voipembedded.com
I can't remember all the details, but after an ICE negotiation, during
the UPDATE that confirms the negotiated parameters, the c line
shouldn't be touched (if touched, it breakes the ICE negotiation).
Maybe the new rtpproxyengine handles this by default ...
I wasn't aware of this, is there an RFC which specifies this? All the ICE
negotiations I've seen so far were done entirely outside of signalling
(apart from the initial offers and answers). I believe rtpproxy would also
be guilty of this then, as it also always modifies m= and c=.
cheers
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev