[OpenSIPS-Users] RTPProxy Support - Not prefilling callees address
Răzvan Crainea
razvan at opensips.org
Fri Mar 22 09:37:51 CET 2013
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
More information about the Users
mailing list