Re: [Siproxd-users] Debug mode changing siproxd behaviour ??

[Thomas R. <tr...@gm...>]

Hello Étienne,

You should concentrate on the rtp_proxy stuff in the log.

- Can siproxd properly allocate and bind to the RTP ports?
- Are sufficient RTP ports configured (siproxd.cofn)
- Do you see any ERROR or WARNINGs in the log?

Also, you should look at a possible differences in the log of the
working (non-daemonized) and non-working (daemonized) configuration.

You may also correlate the siproxd log with your TCPDUMP traces, i.e. is
the RTP audio sent to the correct (expected by siproxd) ports?

You mention an ICMP port unreachable - what causes this? This *might*
happen if an UA does send RTP traffic to a port that is either:
- not allowed by the packet filter
- nobody is listening on that port
This could indicate issues with symmetric RTP (that should be fixed in a
later version of siproxd).

Other questions:
- Does your UA (phone) use any NAT helpers like STUN or other
  mechanisms? If so, DISABLE.

This should give you some hints where to start.

Regards,
/Thomas

On  3 Apr, Étienne wrote:
> On Fri, Apr 02, 2010 at 11:18:09PM +0200, Thomas Ries wrote:
> 
> Hi Thomas,
> 
>> First you should really consider upgrading siproxd to the current
>> version (which meanwhile is 0.8.0 !). Quite a number of changes (and
>> fixes) have been made that include improvements in RTP processing.
> 
> I was expecting this, but on a lightweight gateway with no build
> capabilities, I'm pretty much stuck with what is available in OpenBSD
> ports, especially with no other OpenBSD platform at hand in the
> immediate future. I'll certainly look forward to install the latest
> siproxd available, though.
>  
>> Second, siproxd allows logging (incl. debug information) via TCP
>> connection - even if runnign in background;
>> check the 'debug_port' config option.
> 
> Thank you, I now have a log. Lots of stuff in it, any advice on what I
> should be looking for, considering the symptoms given earlier ?
> 
> Thanks a lot, and happy Easter.
>