Alex Hermann writes:

...

rtpproxy_offer and answer functions have "r" flag described as follows:

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.

how does rtpproxy "use" this ip address?

It directly starts forwarding packets to it. If you don't use this flag, rtpproxsy will wait until it has received poackets from both parties in the call.

it is not what the above description tells. it just tells where rtpproxy takes the address, nothing about when it starts to send packets. proper use of rtpproxy or mediaproxy-ng is difficult until this has been clarified. waiting for both parties to send something first, would not work if the other party is muted.

...

if sip message comes from behind nat, ip address in sdp is local address, not the address where rtp packets come from. and if this request has passed another (e.g. outbound) proxy before hitting the current one, also source address of sip message is not the address where rtp packets come from. either address thus seems to be useless for rtpproxy.

You can make the addres more "usefull" by rewriting the address with fix_natted_sdp() on the first proxy the UAC reaches (load-balancer). If you don't have that possibility, maybe you can call fix_natted_sdp() on the proxy itself and call msg_apply_changes() before invoking the rtpproxy.

it would result in double rewrite of the sdp when one motivation of using mediaproxy-ng is that it does the rewriting only once. there should be possibility pass sdp ip address as parameter in offer and answer calls.

-- juha

Richard Fuchs writes:

In case of mediaproxy-ng, it doesn't wait. If it hasn't received anything from the other endpoint yet, then it will use whatever address it was given (either from the SDP or the SIP source address). Once it has received a packet from the other endpoint, it will use this source address. That's about as good as it gets without ICE.

thanks for the explanation.

...

it would result in double rewrite of the sdp when one motivation of using mediaproxy-ng is that it does the rewriting only once. there should be possibility pass sdp ip address as parameter in offer and answer calls.

This is possible through the second parameter to rtpproxy_offer/answer/manage(). Mediaproxy-ng doesn't support this yet (we have no use for it, auto-discovery works well enough), but it's next up on my todo list for compatibility's sake.

ok,

-- juha

Richard Fuchs writes:

...

This is possible through the second parameter to rtpproxy_offer/answer/manage(). Mediaproxy-ng doesn't support this yet (we have no use for it, auto-discovery works well enough), but it's next up on my todo list for compatibility's sake.

This is now implemented in both rtpproxy-ng and mediaproxy-ng.

thanks, i tested and media address param worked fine.

-- juha