Re: [OpenSIPS-Users] opensips + rtpproxy bridge on loopback interfaces
Hi Razvan,
Le 26/10/2016 à 15:35, Răzvan Crainea a écrit :
Hi, Cedric!
If you double checked the PCAP and you really are missing the flow
from RTPProxy to callee, I take your word for it. Pehaps the logging
is misleading.
Now, if RTPProxy does not send any packet to the callee, this means
that it doesn't get any packets from him. This means that there is
something wrong with the flow from callee to RTPProxy
(192.168.157.141:12704 to 192.168.157.121:17226). If you see it in the
PCAP on the RTPProxy machine, it might be blocked at the firewall level?
There is no firewall anywhere (for testing purpose, of course).
I can see the flow from the callee (192.168.157.141) to rtpproxy
(192.168.157.121) in the capture, and this flow is relayed correctly to
the "external" side of rtpproxy.
Another thing that you could try: I saw that you are passing the "a"
flag to the rtpproxy functions. Do you really need it? Can you try to
remove it and test again?
I tried this morning : I have the same problem. I've tried with/without
flags "o" & "c" too.
Tried with rtpproxy on a different host too (adjusting socket parameter,
of course) : same result.
I'll sent you the last capture I've done a few minutes ago.
Thanks again for your help.
Regards,
Cédric
Best regards,
Răzvan Crainea
OpenSIPS Solutions
www.opensips-solutions.com
On 10/26/2016 03:46 PM, Cédric ML wrote:
Hello Razvan,
Le 26/10/2016 à 13:52, Răzvan Crainea a écrit :
Hi, Cedric!
Are you sure that the flows you do not see are the ones you
mentioned? According to the logs, you do not see the RTP coming from
the caller:
RTP stats: 410 in from callee, 0 in from caller
Do these stats work correctly when rtpproxy works in bridge mode ?
Seems like it only watches on "internal" side of bridge, not on
"external" side.
Caller is 222.251.208.61 (external side, asterisk server), and callee
is 192.168.157.141 (internal side, asterisk server too)
stream from 222.251.208.61:18592 to 111.122.100.20:17826 : OK (rtp
stream from caller to rtpproxy)
stream from 192.168.157.121:17226 to 192.168.157.141:12704 : MISSING
(rtp stream from rtpproxy to callee)
stream from 192.168.157.141:12704 to 192.168.157.121:17226 : OK (rtp
stream from callee to rtpproxy)
stream from 111.122.100.20:17826 to 222.251.208.61:18592 : OK (rtp
stream from rtpproxy to caller)
So the missing flow is RTP from the rtpproxy to the callee.
So the problem seems to be not on the private network, but on the
public one. Or there is a reporting bug in RTPProxy :).
What's the user experience for this call? Do any of the participants
hear each other? Also, where are you doing the trace of the RTP?
I'm capturing on the opensips / rtpproxy host.
I can't tell you anything about the user experience, I'm using
asterisk to generate a call ('originate') and stream a sound file,
and the callee is an asterisk too, which just answers and plays a
sound file.
I can send you an example pcap file if you need it.
Thank you for your help !!!
Best regards,
Cédric
Best regards,
Răzvan Crainea
OpenSIPS Solutions
www.opensips-solutions.com
On 10/26/2016 12:35 PM, Cédric ML wrote:
I've made a new test, replacing mediaproxy "external" address by
111.122.100.18 (which is the SIG address).
It works fine (rtp stream is complete), but that's not what I'm
trying to do. I need to have a different address for the SIG and
for the MEDIA.
Hope it helps...
Regards,
Cédric
Le 26/10/2016 à 10:39, Cédric ML a écrit :
Hello,
I'm trying to set up opensips (v2.2.2) and rtpproxy
(2.0.beta.20150106) one the same server, using loopback interfaces.
--
network config :
lo:2 : inet 111.122.100.18/32 (SIG address)
lo:4 : inet 111.122.100.20/32 (MEDIA address)
eth1 : 192.168.157.121/24
routing :
222.251.208.61 via 192.168.157.1 dev eth1 src 111.122.100.18
222.251.120.61 via 192.168.157.1 dev eth1 src 111.122.100.20
--
opensips setup :
listen=udp:0.0.0.0:5060
loadmodule "rtpproxy.so"
modparam("rtpproxy", "rtpproxy_sock",
"unix:/var/run/rtpproxy/rtpproxy.sock")
#routing
...
if (is_method("INVITE")) {
t_on_reply("handle_nat");
$rd="192.168.157.141";
if (has_body("application/sdp"))
{
rtpproxy_offer("afeiroc");
}
}
onreply_route[handle_nat] {
if ( has_body("application/sdp") ){
rtpproxy_answer("afieroc");
}
}
...
--
rtpproxy setup :
/usr/local/bin/rtpproxy -s
unix:/var/run/rtpproxy/rtpproxy.sock -u rtpproxy rtpproxy -p
/var/run/rtpproxy/rtpproxy.pid -l 192.168.157.121 111.122.100.20
-d DBUG LOG_LOCAL5 -m 1 -M 2 -w rw
--
When
Re: [OpenSIPS-Users] opensips + rtpproxy bridge on loopback interfaces
Hello Razvan,
Le 26/10/2016 à 13:52, Răzvan Crainea a écrit :
Hi, Cedric!
Are you sure that the flows you do not see are the ones you mentioned?
According to the logs, you do not see the RTP coming from the caller:
RTP stats: 410 in from callee, 0 in from caller
Do these stats work correctly when rtpproxy works in bridge mode ? Seems
like it only watches on "internal" side of bridge, not on "external" side.
Caller is 222.251.208.61 (external side, asterisk server), and callee is
192.168.157.141 (internal side, asterisk server too)
stream from 222.251.208.61:18592 to 111.122.100.20:17826 : OK (rtp
stream from caller to rtpproxy)
stream from 192.168.157.121:17226 to 192.168.157.141:12704 : MISSING
(rtp stream from rtpproxy to callee)
stream from 192.168.157.141:12704 to 192.168.157.121:17226 : OK (rtp
stream from callee to rtpproxy)
stream from 111.122.100.20:17826 to 222.251.208.61:18592 : OK (rtp
stream from rtpproxy to caller)
So the missing flow is RTP from the rtpproxy to the callee.
So the problem seems to be not on the private network, but on the
public one. Or there is a reporting bug in RTPProxy :).
What's the user experience for this call? Do any of the participants
hear each other? Also, where are you doing the trace of the RTP?
I'm capturing on the opensips / rtpproxy host.
I can't tell you anything about the user experience, I'm using asterisk
to generate a call ('originate') and stream a sound file, and the callee
is an asterisk too, which just answers and plays a sound file.
I can send you an example pcap file if you need it.
Thank you for your help !!!
Best regards,
Cédric
Best regards,
Răzvan Crainea
OpenSIPS Solutions
www.opensips-solutions.com
On 10/26/2016 12:35 PM, Cédric ML wrote:
I've made a new test, replacing mediaproxy "external" address by
111.122.100.18 (which is the SIG address).
It works fine (rtp stream is complete), but that's not what I'm
trying to do. I need to have a different address for the SIG and for
the MEDIA.
Hope it helps...
Regards,
Cédric
Le 26/10/2016 à 10:39, Cédric ML a écrit :
Hello,
I'm trying to set up opensips (v2.2.2) and rtpproxy
(2.0.beta.20150106) one the same server, using loopback interfaces.
--
network config :
lo:2 : inet 111.122.100.18/32 (SIG address)
lo:4 : inet 111.122.100.20/32 (MEDIA address)
eth1 : 192.168.157.121/24
routing :
222.251.208.61 via 192.168.157.1 dev eth1 src 111.122.100.18
222.251.120.61 via 192.168.157.1 dev eth1 src 111.122.100.20
--
opensips setup :
listen=udp:0.0.0.0:5060
loadmodule "rtpproxy.so"
modparam("rtpproxy", "rtpproxy_sock",
"unix:/var/run/rtpproxy/rtpproxy.sock")
#routing
...
if (is_method("INVITE")) {
t_on_reply("handle_nat");
$rd="192.168.157.141";
if (has_body("application/sdp"))
{
rtpproxy_offer("afeiroc");
}
}
onreply_route[handle_nat] {
if ( has_body("application/sdp") ){
rtpproxy_answer("afieroc");
}
}
...
--
rtpproxy setup :
/usr/local/bin/rtpproxy -s unix:/var/run/rtpproxy/rtpproxy.sock
-u rtpproxy rtpproxy -p /var/run/rtpproxy/rtpproxy.pid -l
192.168.157.121 111.122.100.20 -d DBUG LOG_LOCAL5 -m 1 -M 2
-w rw
--
When I'm making a call from 222.251.208.61 :
- INVITE arrives on the external side of opensips (111.122.100.18),
SDP contains 222.251.208.61:18592
- INVITE is relayed on the internal side to 192.168.157.141, SDP is
modified to 192.168.157.121:17226
- 200 OK : 192.168.157.141 replies with a 200 OK, SDP contains
192.168.157.141:12704
- 200 OK : opensips relays 200 OK to 193.252.208.61, SDP is modified
to 111.122.100.20:17826
So everything looks good in the SDP.
Now looking to the rtp streams :
stream from 222.251.208.61:18592 to 111.122.100.20:17826 : OK
stream from 192.168.157.121:17226 to 192.168.157.141:12704 : MISSING
stream from 192.168.157.141:12704 to 192.168.157.121:17226 : OK
stream from 111.122.100.20:17826 to 222.251.208.61:18592 : OK
It seems that rtpproxy fails to bridge the "external -> internal"
part of the media.
rtpproxy debug :
Oct 26 10:05:04 localhost rtpproxy[775]: DBUG:get_command:GLOBAL:
received command "UAEIc8,101
36fe8745364f35b61411304154da2db3@222.251.208.61:5060 222.251.208.61
18592 as5f5f1868;1"
Oct 26 10:05:04 localhost rtpproxy[775]:
INFO:rtpp_command_ul_handle:GLOBAL: new session
36fe8745364f35b61411304154da2db3@222.251.208.61:5060, tag
as5f5f1868;1 requested, type strong
Oct 26 10:05:04 localhost rtpproxy[775]:
INFO:rtpp_command_ul_handle:36fe8745364f35b61411304154da2db3@222.251.208.61:5060:
new session on a port 17226 created, tag as5f5f1868;1
Oct 26 10:05:04
Re: [OpenSIPS-Users] opensips + rtpproxy bridge on loopback interfaces
I've made a new test, replacing mediaproxy "external" address by
111.122.100.18 (which is the SIG address).
It works fine (rtp stream is complete), but that's not what I'm trying
to do. I need to have a different address for the SIG and for the MEDIA.
Hope it helps...
Regards,
Cédric
Le 26/10/2016 à 10:39, Cédric ML a écrit :
Hello,
I'm trying to set up opensips (v2.2.2) and rtpproxy
(2.0.beta.20150106) one the same server, using loopback interfaces.
--
network config :
lo:2 : inet 111.122.100.18/32 (SIG address)
lo:4 : inet 111.122.100.20/32 (MEDIA address)
eth1 : 192.168.157.121/24
routing :
222.251.208.61 via 192.168.157.1 dev eth1 src 111.122.100.18
222.251.120.61 via 192.168.157.1 dev eth1 src 111.122.100.20
--
opensips setup :
listen=udp:0.0.0.0:5060
loadmodule "rtpproxy.so"
modparam("rtpproxy", "rtpproxy_sock",
"unix:/var/run/rtpproxy/rtpproxy.sock")
#routing
...
if (is_method("INVITE")) {
t_on_reply("handle_nat");
$rd="192.168.157.141";
if (has_body("application/sdp"))
{
rtpproxy_offer("afeiroc");
}
}
onreply_route[handle_nat] {
if ( has_body("application/sdp") ){
rtpproxy_answer("afieroc");
}
}
...
--
rtpproxy setup :
/usr/local/bin/rtpproxy -s unix:/var/run/rtpproxy/rtpproxy.sock -u
rtpproxy rtpproxy -p /var/run/rtpproxy/rtpproxy.pid -l 192.168.157.121
111.122.100.20 -d DBUG LOG_LOCAL5 -m 1 -M 2 -w rw
--
When I'm making a call from 222.251.208.61 :
- INVITE arrives on the external side of opensips (111.122.100.18),
SDP contains 222.251.208.61:18592
- INVITE is relayed on the internal side to 192.168.157.141, SDP is
modified to 192.168.157.121:17226
- 200 OK : 192.168.157.141 replies with a 200 OK, SDP contains
192.168.157.141:12704
- 200 OK : opensips relays 200 OK to 193.252.208.61, SDP is modified
to 111.122.100.20:17826
So everything looks good in the SDP.
Now looking to the rtp streams :
stream from 222.251.208.61:18592 to 111.122.100.20:17826 : OK
stream from 192.168.157.121:17226 to 192.168.157.141:12704 : MISSING
stream from 192.168.157.141:12704 to 192.168.157.121:17226 : OK
stream from 111.122.100.20:17826 to 222.251.208.61:18592 : OK
It seems that rtpproxy fails to bridge the "external -> internal" part
of the media.
rtpproxy debug :
Oct 26 10:05:04 localhost rtpproxy[775]: DBUG:get_command:GLOBAL:
received command "UAEIc8,101
36fe8745364f35b61411304154da2db3@222.251.208.61:5060 222.251.208.61
18592 as5f5f1868;1"
Oct 26 10:05:04 localhost rtpproxy[775]:
INFO:rtpp_command_ul_handle:GLOBAL: new session
36fe8745364f35b61411304154da2db3@222.251.208.61:5060, tag as5f5f1868;1
requested, type strong
Oct 26 10:05:04 localhost rtpproxy[775]:
INFO:rtpp_command_ul_handle:36fe8745364f35b61411304154da2db3@222.251.208.61:5060:
new session on a port 17226 created, tag as5f5f1868;1
Oct 26 10:05:04 localhost rtpproxy[775]:
INFO:rtpp_command_ul_handle:36fe8745364f35b61411304154da2db3@222.251.208.61:5060:
pre-filling caller's address with 222.251.208.61:18592
Oct 26 10:05:04 localhost rtpproxy[775]: DBUG:rtpc_doreply:GLOBAL:
sending reply "17226 192.168.157.121#012"
Oct 26 10:05:05 localhost rtpproxy[775]: DBUG:get_command:GLOBAL:
received command "LAIEc8,101
36fe8745364f35b61411304154da2db3@222.251.208.61:5060 192.168.157.141
12704 as5f5f1868;1 as200acccf;1"
Oct 26 10:05:05 localhost rtpproxy[775]:
INFO:rtpp_command_ul_handle:36fe8745364f35b61411304154da2db3@222.251.208.61:5060:
lookup on ports 17226/17826, session timer restarted
Oct 26 10:05:05 localhost rtpproxy[775]:
INFO:rtpp_command_ul_handle:36fe8745364f35b61411304154da2db3@222.251.208.61:5060:
pre-filling callee's address with 192.168.157.141:12704
Oct 26 10:05:05 localhost rtpproxy[775]: DBUG:rtpc_doreply:GLOBAL:
sending reply "17826 111.122.100.20#012"
Oct 26 10:05:13 localhost rtpproxy[775]: DBUG:get_command:GLOBAL:
received command "D
36fe8745364f35b61411304154da2db3@222.251.208.61:5060 as5f5f1868
as200acccf"
Oct 26 10:05:13 localhost rtpproxy[775]:
INFO:handle_delete:36fe8745364f35b61411304154da2db3@222.251.208.61:5060:
forcefully deleting session 1 on ports 17226/17826
Oct 26 10:05:13 localhost rtpproxy[775]:
INFO:remove_session:36fe8745364f35b61411304154da2db3@222.251.208.61:5060:
RTP stats: 410 in from callee, 0 in from caller, 410 relayed, 0 dropped
Oct 26 10:05:13 localhost rtpproxy[775]:
INFO:remove_session:36fe8745364f35b61411304154da2db3@222.251.208.61:5060:
RTCP stats: 1 in from callee, 0 in from caller, 1 relayed, 0 dropped
Oct 26 10:05:13 localhost rtpproxy[775]:
INFO:remove_session:36fe8745364f35b61411304154da2db3@
[OpenSIPS-Users] opensips + rtpproxy bridge on loopback interfaces
Hello,
I'm trying to set up opensips (v2.2.2) and rtpproxy (2.0.beta.20150106)
one the same server, using loopback interfaces.
--
network config :
lo:2 : inet 111.122.100.18/32 (SIG address)
lo:4 : inet 111.122.100.20/32 (MEDIA address)
eth1 : 192.168.157.121/24
routing :
222.251.208.61 via 192.168.157.1 dev eth1 src 111.122.100.18
222.251.120.61 via 192.168.157.1 dev eth1 src 111.122.100.20
--
opensips setup :
listen=udp:0.0.0.0:5060
loadmodule "rtpproxy.so"
modparam("rtpproxy", "rtpproxy_sock",
"unix:/var/run/rtpproxy/rtpproxy.sock")
#routing
...
if (is_method("INVITE")) {
t_on_reply("handle_nat");
$rd="192.168.157.141";
if (has_body("application/sdp"))
{
rtpproxy_offer("afeiroc");
}
}
onreply_route[handle_nat] {
if ( has_body("application/sdp") ){
rtpproxy_answer("afieroc");
}
}
...
--
rtpproxy setup :
/usr/local/bin/rtpproxy -s unix:/var/run/rtpproxy/rtpproxy.sock -u
rtpproxy rtpproxy -p /var/run/rtpproxy/rtpproxy.pid -l 192.168.157.121
111.122.100.20 -d DBUG LOG_LOCAL5 -m 1 -M 2 -w rw
--
When I'm making a call from 222.251.208.61 :
- INVITE arrives on the external side of opensips (111.122.100.18), SDP
contains 222.251.208.61:18592
- INVITE is relayed on the internal side to 192.168.157.141, SDP is
modified to 192.168.157.121:17226
- 200 OK : 192.168.157.141 replies with a 200 OK, SDP contains
192.168.157.141:12704
- 200 OK : opensips relays 200 OK to 193.252.208.61, SDP is modified to
111.122.100.20:17826
So everything looks good in the SDP.
Now looking to the rtp streams :
stream from 222.251.208.61:18592 to 111.122.100.20:17826 : OK
stream from 192.168.157.121:17226 to 192.168.157.141:12704 : MISSING
stream from 192.168.157.141:12704 to 192.168.157.121:17226 : OK
stream from 111.122.100.20:17826 to 222.251.208.61:18592 : OK
It seems that rtpproxy fails to bridge the "external -> internal" part
of the media.
rtpproxy debug :
Oct 26 10:05:04 localhost rtpproxy[775]: DBUG:get_command:GLOBAL:
received command "UAEIc8,101
36fe8745364f35b61411304154da2db3@222.251.208.61:5060 222.251.208.61
18592 as5f5f1868;1"
Oct 26 10:05:04 localhost rtpproxy[775]:
INFO:rtpp_command_ul_handle:GLOBAL: new session
36fe8745364f35b61411304154da2db3@222.251.208.61:5060, tag as5f5f1868;1
requested, type strong
Oct 26 10:05:04 localhost rtpproxy[775]:
INFO:rtpp_command_ul_handle:36fe8745364f35b61411304154da2db3@222.251.208.61:5060:
new session on a port 17226 created, tag as5f5f1868;1
Oct 26 10:05:04 localhost rtpproxy[775]:
INFO:rtpp_command_ul_handle:36fe8745364f35b61411304154da2db3@222.251.208.61:5060:
pre-filling caller's address with 222.251.208.61:18592
Oct 26 10:05:04 localhost rtpproxy[775]: DBUG:rtpc_doreply:GLOBAL:
sending reply "17226 192.168.157.121#012"
Oct 26 10:05:05 localhost rtpproxy[775]: DBUG:get_command:GLOBAL:
received command "LAIEc8,101
36fe8745364f35b61411304154da2db3@222.251.208.61:5060 192.168.157.141
12704 as5f5f1868;1 as200acccf;1"
Oct 26 10:05:05 localhost rtpproxy[775]:
INFO:rtpp_command_ul_handle:36fe8745364f35b61411304154da2db3@222.251.208.61:5060:
lookup on ports 17226/17826, session timer restarted
Oct 26 10:05:05 localhost rtpproxy[775]:
INFO:rtpp_command_ul_handle:36fe8745364f35b61411304154da2db3@222.251.208.61:5060:
pre-filling callee's address with 192.168.157.141:12704
Oct 26 10:05:05 localhost rtpproxy[775]: DBUG:rtpc_doreply:GLOBAL:
sending reply "17826 111.122.100.20#012"
Oct 26 10:05:13 localhost rtpproxy[775]: DBUG:get_command:GLOBAL:
received command "D 36fe8745364f35b61411304154da2db3@222.251.208.61:5060
as5f5f1868 as200acccf"
Oct 26 10:05:13 localhost rtpproxy[775]:
INFO:handle_delete:36fe8745364f35b61411304154da2db3@222.251.208.61:5060:
forcefully deleting session 1 on ports 17226/17826
Oct 26 10:05:13 localhost rtpproxy[775]:
INFO:remove_session:36fe8745364f35b61411304154da2db3@222.251.208.61:5060:
RTP stats: 410 in from callee, 0 in from caller, 410 relayed, 0 dropped
Oct 26 10:05:13 localhost rtpproxy[775]:
INFO:remove_session:36fe8745364f35b61411304154da2db3@222.251.208.61:5060:
RTCP stats: 1 in from callee, 0 in from caller, 1 relayed, 0 dropped
Oct 26 10:05:13 localhost rtpproxy[775]:
INFO:remove_session:36fe8745364f35b61411304154da2db3@222.251.208.61:5060:
session on ports 17226/17826 is cleaned up
Oct 26 10:05:13 localhost rtpproxy[775]: DBUG:rtpc_doreply:GLOBAL:
sending reply "0#012"
I can't figure out what's wrong in my config. Can you please help me ?
Should I post this message on rtpproxy mailing list too ?
Best regards,
Cédric
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
