[OpenSIPS-Users] RTPProxy Support - Not prefilling callees address
Nick Khamis
symack at gmail.com
Thu Mar 21 17:19:14 CET 2013
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
>>> >>
>>> >
>>>
>>
>
More information about the Users
mailing list