[OpenSIPS-Users] RTPProxy Support - Not prefilling callees address

Răzvan Crainea razvan at opensips.org
Mon Mar 25 09:22:35 CET 2013 

Hi, Nick!

You don't have to wipe out your database. There is already a DB 
migration tool that can help you [1].

[1] http://www.opensips.org/Resources/DocsMigration180to190

Best regards,

Razvan Crainea
OpenSIPS Core Developer
http://www.opensips-solutions.com

On 03/22/2013 04:20 PM, Nick Khamis wrote:
> I am using version 1.8.2 I think? I can check when I get back in the
> office. I thought we had downloaded the latest stable not too long ago
> but guess not. Is updating easy (i.e., no database wipe out?).
>
> Nick.
>
> On 3/22/13, Răzvan Crainea <razvan at opensips.org> wrote:
>> Hi, Nick!
>>
>> What version of OpenSIPS are you using? This has been introduced in 1.9.
>>
>> Best regards,
>>
>> Razvan Crainea
>> OpenSIPS Core Developer
>> http://www.opensips-solutions.com
>>
>> On 03/21/2013 05:19 PM, Nick Khamis wrote:
>>> Is it not possible to pass a var or avp as an argument to the
>>> ip_address parameter of rtpproxy_answer/offer:
>>>
>>> $var(privateIP) = "192.168.2.5";
>>> $avp(privateIP) = $var(privateIP);
>>>
>>> if (has_body("application/sdp")) rtpproxy_offer("rc","$avp(privateIP)");
>>>
>>> I am getting a socket error....
>>>
>>> Thanks in Advance,
>>>
>>> Nick.
>>>
>>> On 3/20/13, Nick Khamis <symack at gmail.com> wrote:
>>>> You beat me to it!!!! I was just going to post my solution!!!!!
>>>>
>>>> So, pretending that Sammy did not say that :).
>>>>
>>>> I first fixed no audio with the "r" flag. This got outgoing audio
>>>> going as it uses the IP address from c= in the SDP payload. Now I
>>>> still had the problem with incoming RTP stream. Seemed like it was
>>>> getting routed elsewhere because it was not entering our network (no
>>>> it was no the firewall). After tinkering with ie, and shedding a few
>>>> tears.... I was able to fix this issue using the c flag and pointing
>>>> to public ip, for replies going out of the network.
>>>> I hope this saves someone two days some day:
>>>>
>>>>
>>>> route[1] {
>>>>           if (is_method("INVITE")) {
>>>>                   t_on_branch("1");
>>>>                   t_on_reply("1");
>>>>                   t_on_failure("1");
>>>>
>>>>
>>>>                   if (has_body("application/sdp")) {
>>>>                           if (client_nat_test("3"))
>>>> rtpproxy_offer("rc","public ip");
>>>>                                   else rtpproxy_offer("rc","private ip");
>>>>                   }
>>>>           }
>>>>           else if (is_method("BYE|CANCEL")) {
>>>>                   unforce_rtp_proxy();
>>>>           }
>>>>
>>>>           if (!t_relay()) {
>>>>                   sl_reply_error();
>>>>           };
>>>>           exit;
>>>> }
>>>> onreply_route[1] {
>>>>           xlog("incoming reply\n");
>>>>           if (has_body("application/sdp")) {
>>>>                   if (client_nat_test("3")) rtpproxy_answer("rc","public
>>>> ip");
>>>>                           else rtpproxy_answer("rc","private ip");
>>>>           }
>>>> }
>>>>
>>>>
>>>> Sammy I know you went through this a while back, that is why I sent
>>>> you the private email. I hope it did not offend you in any way!
>>>>
>>>> Nick.
>>>>
>>>> On 3/20/13, SamyGo <govoiper at gmail.com> wrote:
>>>>> Hi Nick,
>>>>>
>>>>> When I first hit the same issue where media was to be sent/received from
>>>>> a
>>>>> different IP other than signalling I used 'r' flag in the
>>>>> engage_rtpproxy()
>>>>> function. I don't think you are using this function rather using offer
>>>>> and
>>>>> answer functions which I'd say a manual approach.
>>>>> Tell me if using the 'r' flag in both offer and answer helps with these
>>>>> calls.
>>>>> Umm...and yeah also check with your media server not to directmedia with
>>>>> the carrier.
>>>>>
>>>>> Thanks
>>>>> Sammy
>>>>> On Mar 21, 2013 1:45 AM, "Nick Khamis" <symack at gmail.com> wrote:
>>>>>
>>>>>> 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
>>>>>>>>
>>> _______________________________________________
>>> 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