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 rfuchs@sipwise.com 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 sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev