[SR-Users] mediaproxy-ng query

[Richard Fuchs]

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.

cheers