Re: mediaproxy/rtpproxy problem with reinvites

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: mediaproxy/rtpproxy problem with reinvites

Jeff Pyle
Iñaki,

I've implemented your suggestions.  The scenario has changed, but not improved.

Here's the current situation.  I place a call from the NATed device through the proxy to a user behind Asterisk.  Asterisk sends back a 183 during ringing.  I hear this correctly on the NATed phone.  The Asterisk user answers, the call goes 200, Asterisk reinvites, 200 again.  At this point any RTP I send from the NATed phone to rtpproxy gets sent right back to me at the NATed phone.  In other words, rtpproxy is functioning as an echo-test.  Meanwhile, the Asterisk-side user hears nothing.

I've inserted a bunch of xlogs to see what's happening.  Everything appears to be triggering at the proper time.  There are no errors or warnings.  But, RTP obviously isn't flowing where it should.

Is there some way I can see what Opensips is telling rtpproxy?  Do you have another suggestions how I might troubleshoot this?


- Jeff


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Iñaki Baz Castillo
Sent: Friday, October 31, 2008 9:11 AM
Cc: [hidden email]
Subject: Re: [OpenSIPS-Users] mediaproxy/rtpproxy problem with reinvites

2008/10/31 Jeff Pyle <[hidden email]>:
> How *should* rtpproxy/mediaproxy handle reinvites?  I only got this
> far by using unforce_rtp_proxy, then force_rtp_proxy on a loose-routed
> INVITE w/ SDP (in other words a reinvite).  Should that be necessary?  Might the "s"
> swap flag be helpful in this scenario somewhere?

I do the following:

In in-dialog section (loose-route) I run force_rtp_proxy("l"). In case the initial INVITE used RtpProxy then this command re-enables it and $rc = 1. In case the initial INVITE didn't use RtpProxy then this command return other value (false) and no SDP modification is performed.
In the first case, I set a flag that I check in onreply_route since the 180/183/200 responses also need to run "force_rtp_proxy":


# in-dialog:
          t_on_reply("1");
          force_rtp_proxy("l");
                      if ($rc == 1) {
                                setbflag(9);  # Enable RtpProxy in the reply.
                        }


onreply_route[1] {

        if (status =~ "(180)|(183)|2[0-9][0-9]") {
                if (isbflagset(6) || nat_uac_test("1"))
                        fix_nated_contact();
                if (isbflagset(9) && has_body("application/sdp") && $cl != 0) {
                        force_rtp_proxy("l");
                }
        }

}

--
Iñaki Baz Castillo
<[hidden email]>

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: mediaproxy/rtpproxy problem with reinvites

Iñaki Baz Castillo
El Lunes, 3 de Noviembre de 2008, Jeff Pyle escribió:
> I've inserted a bunch of xlogs to see what's happening.

At this point, the most efective is to capture a SIP trace and examine it.

--
Iñaki Baz Castillo

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: mediaproxy/rtpproxy problem with reinvites

Jeff Pyle
Makes sense to me.  I have several to choose from.  :)

In the in-dialog section, if I replace your force_rtp_proxy("l") with an unforce-then-force (no flags), I can restore the on-net operation.  It seems to work 100% of the time.  However, on calls from my PSTN gateway to the NATed user (via Asterisk), it works about 20% of the time.

In every case the SDPs for the invites and reinvites look appropriate.  As such, all the gateways and UAs engaged in the call send RTP to the proper place (to rtpproxy).  The problem seems to be where rtpproxy relays the RTP, if anywhere at all, after the reinvites take place.


- Jeff


 

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Iñaki Baz Castillo
Sent: Monday, November 03, 2008 2:57 PM
To: [hidden email]
Subject: Re: [OpenSIPS-Users] mediaproxy/rtpproxy problem with reinvites

El Lunes, 3 de Noviembre de 2008, Jeff Pyle escribió:
> I've inserted a bunch of xlogs to see what's happening.

At this point, the most efective is to capture a SIP trace and examine it.

--
Iñaki Baz Castillo


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: mediaproxy/rtpproxy problem with reinvites

Jeff Pyle
It seems like this has less and less to do with routing logic and more to do with the timing of packets arriving at rtpproxy.  It seems like this:  if no RTP packets arrive at an established rtpproxy session before the session is reinvited and re-established, the re-established session will fail in both directions.  However, if at least one packet arrives at the original bridge, the reinvited session will also work.

Does that make any sense?


- Jeff


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Jeff Pyle
Sent: Monday, November 03, 2008 3:17 PM
To: Iñaki Baz Castillo; [hidden email]
Cc: [hidden email]
Subject: Re: [OpenSIPS-Users] mediaproxy/rtpproxy problem with reinvites

Makes sense to me.  I have several to choose from.  :)

In the in-dialog section, if I replace your force_rtp_proxy("l") with an unforce-then-force (no flags), I can restore the on-net operation.  It seems to work 100% of the time.  However, on calls from my PSTN gateway to the NATed user (via Asterisk), it works about 20% of the time.

In every case the SDPs for the invites and reinvites look appropriate.  As such, all the gateways and UAs engaged in the call send RTP to the proper place (to rtpproxy).  The problem seems to be where rtpproxy relays the RTP, if anywhere at all, after the reinvites take place.


- Jeff


 

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Iñaki Baz Castillo
Sent: Monday, November 03, 2008 2:57 PM
To: [hidden email]
Subject: Re: [OpenSIPS-Users] mediaproxy/rtpproxy problem with reinvites

El Lunes, 3 de Noviembre de 2008, Jeff Pyle escribió:
> I've inserted a bunch of xlogs to see what's happening.

At this point, the most efective is to capture a SIP trace and examine it.

--
Iñaki Baz Castillo

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: mediaproxy/rtpproxy problem with reinvites

Iñaki Baz Castillo
El Lunes, 3 de Noviembre de 2008, Jeff Pyle escribió:
> It seems like this has less and less to do with routing logic and more to
> do with the timing of packets arriving at rtpproxy.  It seems like this:
>  if no RTP packets arrive at an established rtpproxy session before the
> session is reinvited and re-established, the re-established session will
> fail in both directions.  However, if at least one packet arrives at the
> original bridge, the reinvited session will also work.

In Asterisk you can enable Comedia mode by setting "nat=yes" for the
peer "opensips" (calls coming from opensips). With Comedia mode you don't
need RtpProxy since Asterisk will wait for incoming RTP and sends its RTP to
the received address:port.

--
Iñaki Baz Castillo

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users