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 <[email protected]> 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 > [email protected] > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev -- VoIP Embedded, Inc. http://www.voipembedded.com _______________________________________________ sr-dev mailing list [email protected] http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
