[OpenSIPS-Users] mediaproxy stops relaying packets

[Ruud Klaver]

Hi Jeff,

On 21 Jul 2009, at 21:09, Jeff Pyle wrote:

> Hello,
>
> No reinvites.  No Asterisk.  Just Opensips 1.5.1 on sparc,  
> Mediaproxy 2.3.4,
> and endpoints.
>
> Here is the flow.
>
>         User Endpoint
>               |
>               |
>    User Proxy (with Mediaproxy)
>               |
>               |
>   Carrier Proxy (signaling only)
>               |
>               |
>          PSTN Gateway
>
>
> There is no NAT.  For this test, Mediaproxy is engaged on all calls  
> at the
> User Proxy.  The User Endpoint sends an INVITE to his User Proxy, who
> authenticates the call and sends it to the Carrier Proxy for  
> termination.
>
> There are several gateways the carrier proxy can choose to use to  
> terminate
> the call.  I've found that at least 2 work properly in this  
> configuration,
> and at least 1 does not.  I've attached traces for a call through  
> the one
> that does not.
>
> It seems that at some point early in the call the relay decides to  
> stop
> relaying.  I don't see what's causing it.  This is visible in the
> relay6.packets file.  The last packet the relay sends is at timestamp
> 14:49:44.694363 about 30 packets in.  This seems to correlate with the
> arrival of the first packet from the User IP.
>
> Mediaproxy Relay is configured to use ports 16384:32768, and  
> iptables is
> configured to match on the interface the relay uses for RTP.
>
> Any thoughts on what might cause this?
>
>
> Thanks,
> Jeff

Thanks for the comprehensive traces, it's a bit of a mystery indeed.

First of all, are you sure there is a correlation between the gateway  
being used and mediaproxy working or not? Are all hosts on public IPs?

Indeed the relaying stops once the first packet from the user endpoint  
is receives. Up to this point the relay does not know what the ip/port  
of the caller, so the forwarding is performed in userspace. When it  
receives the first packet from the caller, it learns its ip/port,  
forwards the received packet through userspace and creates the  
connection tracking rule.

Now for some reason the connection tracking rule doesn't seem to work,  
but from what you gave me I cannot tell you why not, but this is the  
direction you have to search in. A few questions you could look into:
- Are the connection tracking rules working for some calls but not for  
others?
- Are all the IPs involved public, i.e. are they using the same  
interface?
- Is the connection tracking rule actually installed, you can check by  
using doing "conntrack -L" and grepping the list
- Is ip packet forwarding enabled in the proc filesystem?
- Is anything else on the system blocking forwarding of packets (maybe  
in the FORWARD table)

In fact, what was that you mentioned about iptables?

Ruud Klaver
AG Projects