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?
Thanks,
I think I might have just answered my own question:
From http://kamailio.org/docs/modules/4.1.x/modules/rtpproxy-ng.html#rtpproxy-ng....:
---
r - flags that IP address in SDP should be trusted. Without this flag, rtpproxy ignores address in the SDP and uses source address of the SIP message as media address which is passed to the RTP proxy.
---
Still, any elaboration welcome.
On 06/07/2014 12:39 PM, 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?
Thanks,
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
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....
On 20/06/14 05:31 AM, Alex Balashov wrote:
Thanks for this clarification, Richard. I really appreciate it.
By "asymmetric flag", which flag do you mean precisely? I assume 'r'?
It would be the "a" flag, however I should mention that I was describing things from an rtpengine perspective, which has a spelled out "asymmetric" flag, and also that only the newer rtpengine actually honours this flag, while the older mediaproxy-ng doesn't.
cheers
-
Alex Balashov -
Richard Fuchs