20 Jun
2014
20 Jun
'14
12:31 p.m.
On 06/08/2014 09:00 AM, Richard Fuchs wrote:
On 06/07/14 12:39, Alex Balashov wrote:
Thanks for this clarification, Richard. I really appreciate it.
By "asymmetric flag", which flag do you mean precisely? I assume 'r'?
http://kamailio.org/docs/modules/4.1.x/modules/rtpproxy-ng.html#rtpproxy-ng…
--
Alex Balashov - Principal
Evariste Systems LLC
Tel: +1-678-954-0670
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
Please be kind to the English language:
http://www.entrepreneur.com/article/232906
Hello,
I'm invoking mediaproxy-ng with rtpproxy_offer/answer("ow") and am
getting a scenario where:
INVITE is forwarded to signalling gateway xxx.xxx.xxx.xxx, which returns
an SDP answer of yyy.yyy.yyy.yyy:51964. rtpproxy is invoked in both
directions. However, media forwarded from media endpoint A is sent to
xxx.xxx.xxx.xxx:51964 (the correct port, but to the signalling gateway),
rather than yyy.yyy.yyy.yyy:51964, which is what's specified in the SDP
answer in the 200 OK from xxx.xxx.xxx.xxx.
No media is coming back to mediaproxy-ng from yyy.yyy.yyy.yyy:51964. The
cause of this is a separate and logically unrelated issue. Nevertheless,
I am curious as to why mediaproxy-ng doesn't send media from the near
end to yyy.yyy.yyy.yyy:51964--in other words, to the specified SDP
endpoint on the far end, rather than to the signalling gateway.
I initially imagined that this might be due to the "w" option to
rtpproxy_offer(), which the documentation says forces symmetric RTP.
However, this behaviour is not elaborated upon or defined. I tried
removing the 'w' option but seem to be getting the same result.
Is this a default behaviour of COMEDIA-style source port latching? In
other words, does mediaproxy-ng need to latch onto incoming RTP from
yyy.yyy.yyy.yyy:51964 before it will send media there, as opposed to the
signalling gateway? If so, is there any way this behaviour can be
disabled, so that mediaproxy-ng simply follows SDP in all cases?
Mediaproxy-ng/rtpengine initially forwards RTP to the endpoint specified
in the SDP (address and port), unless the trust-address flag is not
specified, as you have found out, in which case the source address of
the SIP packet is used instead.
It then attempts to learn the correct endpoint by looking at the source
address and port of RTP packets arriving on the other side of the
fowarding pair. This learning phase is active only for a few seconds and
can be disabled entirely by using the "asymmetric" RTP flag. If no
packets are received in the opposite direction, then the original
endpoint will continue to be used.
After the learning phase is finished, endpoints are fixed and any
changes in RTP source addresses are ignored.