[SR-Users] mediaproxy-ng query

[Alex Balashov]

On 06/08/2014 09:00 AM, Richard Fuchs wrote:
> On 06/07/14 12:39, Alex Balashov wrote:
>> 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.

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.f.rtpproxy_offer

-- 
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