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@sipwise.com wrote:
On 28/04/14 04:21 PM, Ovidiu Sas wrote:
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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev