[OpenSIPS-Users] RTPProxy Support - Not prefilling callees address
Nick Khamis
symack at gmail.com
Wed Mar 20 21:45:29 CET 2013
Hello Razvan, and Sammy,
I really appreciate any help I can get in the matter. Not to sound
like a broken record, but when the SIP and RTP stream are coming from
the same source:
U 2013/03/20 16:13:55.029233 69.147.236.82:5060 -> 192.168.2.5:5060
o=root 19098 19098 IN IP4 69.147.236.82.
c=IN IP4 69.147.236.82.
RTP and RTCP stats are flowing as expected, and we have two way audio:
INFO:remove_session: RTP stats: 751 in from callee, 730 in from
caller, 1481 relayed, 0 dropped
INFO:remove_session: RTCP stats: 1 in from callee, 0 in from caller, 1
relayed, 0 dropped
It would seem that, the problem arises when the SIP and RTP streams
are coming from different sources:
U 2013/03/20 16:27:36.758048 81.201.86.45:5060 -> 192.168.2.5:5060
o=root 5539 5539 IN IP4 81.201.86.26.
c=IN IP4 81.201.86.26
RTPProxy reports that RTP traffic is flowing from the callee, but in
fact there is no audio both ways:
INFO:remove_session: RTP stats: 148 in from callee, 0 in from caller,
148 relayed, 0 dropped
INFO:remove_session: RTCP stats: 0 in from callee, 0 in from caller, 0
relayed, 0 dropped
Commenting out the RTP stuff in OpenSIPS leads to one way outgoing
audio. Looking closer at the RTP proxy log I see that it's prefilling
the caller's address to the source of the SIP messages and not to the
source of the RTP stream:
INFO:handle_command: pre-filling caller's address with 81.201.86.45:10118
A trace on the RTP stream confirms this:
130.427203 192.168.2.100 -> 192.168.2.5 UDP 214 Source port: vtsas
Destination port: 9624
130.427338 192.168.2.5 -> 81.201.86.45 UDP 214 Source port: 30060
Destination port: 17020
130.468931 192.168.2.100 -> 192.168.2.5 UDP 214 Source port: vtsas
Destination port: 9624
130.468985 192.168.2.5 -> 81.201.86.45 UDP 214 Source port: 30060
Destination port: 17020
Thanks in Advance,
Nick.
On 3/19/13, Nick Khamis <symack at gmail.com> wrote:
> Hello Razvan,
>
> I should have mentioned that we only experienced this issue with this
> particular DID provider. With others everything works perfectly. We
> suspect the issue is because the RTP stream is coming from a different
> source that of the SIP messages. So I think it's a matter of lining up
> rtpproxy_offer/answer parameters (i.e., co).
>
> Unfortunately, their service to our zone today is down. Will post
> detailed logs as soon as we can initiate some calls.
>
> Nick.
>
> On 3/19/13, Răzvan Crainea <razvan at opensips.org> wrote:
>> Hi, Nick!
>>
>> You said that you can see logs for RTPProxy. Can you set the debug level
>> to DBUG and paste (preferably on pastebin) the logs of the session?
>>
>> Best regards,
>>
>> Razvan Crainea
>> OpenSIPS Core Developer
>> http://www.opensips-solutions.com
>>
>> On 03/19/2013 03:52 PM, Nick Khamis wrote:
>>> I wanted to mention that the same setup works perfectly with VoIP.ms
>>> but not Voxbone. I think the problem is that the SIP messages and RTP
>>> stream for voxbone are coming from different sources. With other
>>> origination providers SIP and RTP streams came from the same source,
>>> so we never experienced a problem.
>>>
>>> We are currently looking into rtpproxy_orffer/answer parameters (i..e,
>>> "reico"...) to see if we can line things up nicely.
>>>
>>> Nichola.
>>>
>>> On 3/19/13, Nick Khamis <symack at gmail.com> wrote:
>>>> RTPProxy does work behind NAT. It's mediaporxy that must be on a public
>>>> ip.
>>>>
>>>> Thanks for your help.
>>>>
>>>> Nick.
>>>>
>>>> On 3/19/13, Muhammad Shahzad <shaheryarkh at gmail.com> wrote:
>>>>> If you are unfamiliar with rtp proxy and how it works, then it would
>>>>> be
>>>>> better for you to use engage_rtp_proxy rather then offer / answer
>>>>> model.
>>>>> Also RTP Proxy requires public IP address, its likely not to work on
>>>>> private subnets (unless you have all SIP entities on same LAN, in
>>>>> which
>>>>> case theoretically it should work but i have never tested it myself).
>>>>>
>>>>> Thank you.
>>>>>
>>>>>
>>>>> On Mon, Mar 18, 2013 at 4:18 PM, Nick Khamis <symack at gmail.com> wrote:
>>>>>
>>>>>> I am not sure if this is the correct place to post OpenSIPS+RTPProxy
>>>>>> questions however, I tried to subscribing to the RTP proxy mailing
>>>>>> list and never heard from them since. If it is ok to post RTP proxy
>>>>>> related questions here.... I am trying to test OpenSIPS with RTP
>>>>>> proxy
>>>>>> with everything behind the same NAT box (i.e., 2 UAs, OpenSIPS,
>>>>>> RTPPoxy) just for testing.
>>>>>>
>>>>>> The code I am using is:
>>>>>>
>>>>>> route {
>>>>>> force_rport();
>>>>>> }
>>>>>> route[1] {
>>>>>> if (is_method("INVITE")) {
>>>>>> t_on_branch("1");
>>>>>> t_on_reply("1");
>>>>>> t_on_failure("1");
>>>>>>
>>>>>> if (has_body("application/sdp")) rtpproxy_offer();
>>>>>> }
>>>>>> else if (is_method("BYE|CANCEL")) {
>>>>>> unforce_rtp_proxy();
>>>>>> }
>>>>>>
>>>>>> if (!t_relay()) {
>>>>>> sl_reply_error();
>>>>>> };
>>>>>> exit;
>>>>>> }
>>>>>> onreply_route[1] {
>>>>>> if (has_body("application/sdp")) rtpproxy_answer();
>>>>>> }
>>>>>>
>>>>>>
>>>>>> There is no way audio using RTP proxy, but audio is fine between the
>>>>>> UA without including the RTP proxy related script. Looking at the log
>>>>>> I found that RTP is prefilling the callers address twice, but not the
>>>>>> callees address.
>>>>>>
>>>>>>
>>>>>> INFO:main: rtpproxy started, pid 7287
>>>>>> INFO:handle_command: new session
>>>>>> ae450168-538e-e211-8550-001b7700a65b at oakville, tag
>>>>>> d23f0168-538e-e211-8550-001b7700a65b;1 requested, type strong
>>>>>> INFO:handle_command: new session on a port 35010 created, tag
>>>>>> d23f0168-538e-e211-8550-001b7700a65b;1
>>>>>> INFO:handle_command: pre-filling caller's address with
>>>>>> 192.168.2.101:5062
>>>>>> INFO:handle_command: new session
>>>>>> ae450168-538e-e211-8550-001b7700a65b at oakville, tag
>>>>>> d23f0168-538e-e211-8550-001b7700a65b;2 requested, type strong
>>>>>> INFO:handle_command: new session on a port 22982 created, tag
>>>>>> d23f0168-538e-e211-8550-001b7700a65b;2
>>>>>> INFO:handle_command: pre-filling caller's address with
>>>>>> 192.168.2.101:5064
>>>>>> INFO:handle_delete: forcefully deleting session 1 on ports 35010/0
>>>>>> INFO:remove_session: RTP stats: 0 in from callee, 0 in from caller, 0
>>>>>> 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 35010/0 is cleaned up
>>>>>> INFO:handle_delete: forcefully deleting session 2 on ports 22982/0
>>>>>> INFO:remove_session: RTP stats: 0 in from callee, 0 in from caller, 0
>>>>>> 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 22982/0 is cleaned up
>>>>>>
>>>>>> Is it possible to test RTP relaying with everything on the same
>>>>>> network?
>>>>>>
>>>>>> Thanks in Advance,
>>>>>>
>>>>>> Nick.
>>>>>>
>>>>>> _______________________________________________
>>>>>> Users mailing list
>>>>>> Users at lists.opensips.org
>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Mit freundlichen Grüßen
>>>>> Muhammad Shahzad
>>>>> -----------------------------------
>>>>> CISCO Rich Media Communication Specialist (CRMCS)
>>>>> CISCO Certified Network Associate (CCNA)
>>>>> Cell: +49 176 99 83 10 85
>>>>> MSN: shari_786pk at hotmail.com
>>>>> Email: shaheryarkh at googlemail.com
>>>>>
>>> _______________________________________________
>>> 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