28 Apr
2014
28 Apr
'14
11:21 p.m.
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(a)sipwise.com> wrote:
On 28/04/14 03:52 PM, Alex Balashov wrote:
--
VoIP Embedded, Inc.
http://www.voipembedded.com
On 04/28/2014 03:48 PM, Richard Fuchs wrote:
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev 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".