[OpenSIPS-Users] RTPProxy Support - Not prefilling callees address
Nick Khamis
symack at gmail.com
Fri Mar 22 16:20:39 CET 2013
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
>
More information about the Users
mailing list