[OpenSIPS-Users] opensips + rtpproxy bridge on loopback interfaces
Cédric ML
cedric.bassaget.ml at gmail.com
Wed Oct 26 16:06:03 CEST 2016
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 10000 -M 20000 -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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 222.251.208.61:5060 as5f5f1868
>>>>> as200acccf"
>>>>> Oct 26 10:05:13 localhost rtpproxy[775]:
>>>>> INFO:handle_delete:36fe8745364f35b61411304154da2db3 at 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 at 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 at 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 at 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 at lists.opensips.org
>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
More information about the Users
mailing list