12 Jul
2013
12 Jul
'13
6:59 a.m.
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?
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.
-- juha
12 Jul
12 Jul
10:21 a.m.
On Friday 12 July 2013 06:59:38 Juha Heinanen wrote:
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.
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.
--
Alex Hermann
11:48 a.m.
Alex Hermann writes:
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.
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
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. 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. 
2:32 p.m.
On 07/12/13 05:48, Juha Heinanen wrote:
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.
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.
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.
cheers
3:11 p.m.
Richard Fuchs writes:
ok,
-- juha
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.
6:29 p.m.
On 07/12/13 08:32, Richard Fuchs wrote:
This is now implemented in both rtpproxy-ng and mediaproxy-ng.
cheers
On 07/12/13 05:48, Juha Heinanen wrote:
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.
13 Jul
13 Jul
9:08 a.m.
Richard Fuchs writes:
thanks, i tested and media address param worked fine.
-- juha
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.
4115
days inactive
4116
days old
6 comments
3 participants
participants (3)
-
Alex Hermann -
Juha Heinanen -
Richard Fuchs