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 ...
Regards, Ovidiu Sas On Mon, Apr 28, 2014 at 4:17 PM, Richard Fuchs <[email protected]> wrote: > On 28/04/14 03:52 PM, Alex Balashov wrote: >> >> On 04/28/2014 03:48 PM, Richard Fuchs wrote: >> >>> If ICE isn't supported and you don't want the traffic to go through the >>> RTP proxy, you can just not call _offer()/_answer(). >> >> >> It seems to me the disagreement here is about how much "management" the >> _offer/_answer() functions should "wrap". > > > Hmmm no not really... I just think that since rtpengine itself cannot know > whether or not ICE is supported, it shouldn't assume that it is, with the > result in the opposite case being that it effectively does nothing. > > I'm not opposed to an explicit "no-touchy-m-and-c" flag, but the default > behaviour should be that rtpengine should try to do what it's designed to > do, which is to proxy RTP packets. Especially since in the case that this is > supposed to address (ICE is supported) it doesn't seem to make a difference > anyway. > > 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
