[OpenSIPS-Users] OpenSIPS - RTP Proxy Integration (One Way Audio Debugging)

[Nick Khamis]

On 2/7/13, Răzvan Crainea <razvan at opensips.org> wrote:
> Hi, Nick!
>
>  From what I see in your trace, the callee (Asterisk) is not sending
> anything to RTPProxy. Have you tried taking a trace on the asterisk
> ports to see if it is indeed sending anything?
>
> Best regards,
>
> Razvan Crainea
> OpenSIPS Core Developer
> http://www.opensips-solutions.com
>
>
> On 02/07/2013 02:20 AM, Nick Khamis wrote:
>> Hello Everyone,
>>
>> It's been an on-again/off-again experience with OpenSIPS + RTP Proxy
>> Integration. Throwing together bits and pieces of code found from
>> various sources. The only absolute is one way (outgoing) audio. This
>> is two weeks of testing, and I am asking for the advice of the
>> experts. The basic flow of packets is intended to be:
>>
>> Router (192.168.2.1) ->  OpenSIPS/RTPProxy (192.168.2.105) ->  Asterisk
>> (192.168.2.10) ->  Back to the Router (192.168.2.1)
>>
>> A little about the network:
>> Port Forwarding ports (5060, and 8000-60000) to OpenSIPS (192.168.2.1)
>> The OpenSIPS server is also in the DMZ for testing, hopefully I don't have
>> to
>> keep it as such when things are working.
>> Not sure if it's related, I am using the Dlink DIR615 router, and ALG
>> is checked. Unchecked, nothing works....
>> The firewall on the router is turned off.
>>
>> For one call I have the following trace from RTP Proxy:
>>
>> INFO:main: rtpproxy started, pid 3565
>> INFO:handle_command: new session
>> a7c30ffb-8fb3bd0d-5f25720c at 192.168.2.11, tag 46A441DF-6FB2C1FE;1
>> requested, type strong
>> INFO:handle_command: new session on a port 8030 created, tag
>> 46A441DF-6FB2C1FE;1
>> INFO:handle_command: pre-filling caller's address with 192.168.2.11:10004
>> INFO:handle_command: adding strong flag to existing session, new=1/0/0
>> INFO:handle_command: lookup on ports 8030/18930, session timer restarted
>> INFO:handle_command: pre-filling callee's address with 192.168.2.10:47686
>> INFO:process_rtp: session timeout
>> INFO:remove_session: RTP stats: 0 in from callee, 35 in from caller,
>> 35 relayed, 0 dropped
>> INFO:remove_session: RTCP stats: 0 in from callee, 0 in from caller, 0
>> relayed, 0 dropped
>> INFO:remove_session: session on ports 8030/18930 is cleaned up
>>
>> tshark slice from OpenSIPS/RTPProxy:
>>
>> 103.009046 192.168.2.11 ->  192.168.2.105 UDP 214 Source port: 10004
>> Destination port: 18930
>> 103.009266 192.168.2.105 ->  192.168.2.10 UDP 214 Source port: 8030
>> Destination port: 47686
>>
>> tshark slice from Asterisk:
>>
>> 102.939445 192.168.2.105 ->  192.168.2.10 UDP 214 Source port: 8030
>> Destination port: 47686
>> 102.939696 192.168.2.10 ->  199.47.127.10 UDP 214 Source port: 51758
>> Destination port: 20680
>>
>> Taking OpenSIPS/RTPProxy out of the picture (i.e., only asterisk), I
>> have two way audio. I hope this is enough info, and I can add related
>> ngrep traces if needed.
>>
>>
>> Your Help is Greatly Appreciated!!!!
>>
>> Nick.
>>
>> _______________________________________________
>> 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
>


Hello Razan,

I knew I should have posted more information, but did not want a
really long email. Just to explain

Nat box from hell <-------> OpenSIPS/RTPProxy <----> Asterisk
(192.168.2.1)                     (192.168.2.105)            (192.168.2.10)

I did a trace on port 5060:

The OpenSIPS Box: http://pastebin.com/p32rnBH6
The Asterisk Box: http://pastebin.com/HJ1SJjSU

I really hope I was more proficient in reading these traces, but they
all look fine to me! If you could point out something that does not
look right, I would really appreciate it.

Thanks in Advance,

Nick.