Re: [Siproxd-users] ERROR:I'm trying to delete a VIA but it's not mine!

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

Hi Colin,

If you still get the error about deleting vias (and you are sure that
the via in question is your external IP address), please send me a debug
log (loglevel = -1) including the error (and all output before, starting
when the offending DIALOG started).

An error of "unable to parse SIP message" does mean that the libosip2
parser did fail to parse the SIP message. Usually this is due to
incorrect SIP headers (on classic is having Asterisk adding an
Alert-Info header without using the '<>' around the value part).
What you need is the SIP message that provokes this error. That message
will be included in the debug output for any debuglevel != 0. Then you
have to investigate header for header.
I usually first create a simple text file containing the exact UDP
playload of the offending SIP packet and send it to siproxd using
netcat. This must provoke the error. Then, I start removing / modifying
the headers until I get the guilty. RFC3261 does include a detailed
syntax description of how the headers must look like, which are
mandatory and which are optional.

Regards,
/Thomas

On 24 Jun, Colin Guthrie wrote:
> Hi Thomas,
> 
> Thomas Ries wrote:
>> Two things.
>> First, the ERROR you describe about trying to delete a VIA that is
>> not mine: There was a bug that did take the "real" external IP
>> address (host_outbound config directive) to be a siproxd local
>> address - resulting in this error (usually during incoming responses
>> only).
> 
>> The bug (issue #1) is fixed, you may want to try the latest snapshot,
>> I hope the ERRORs should now be gone completely - and maybe also the
>> need to reset the phones.
> 
> Well I've updated to the latest snapshot but unf. these errors are
> still occurring for me. I've not reset the phones (I'm not actually in
> the office, so perhaps this is a hangover from not clearing out the
> phones own internal caches but (perhaps naively) I presumed the bug
> would be localised to the proxy only.
> 
> 
>> Second, you say you need to use another (chained) proxy to get things
>> work. This may be perfectly legal - some providers require this
>> (possibly to overcome firewall/NAT issues on their own side). Not
>> using this additional proxy will result in "things almost working".
>> However, this should be somehow documented on your providers side
>> (configuration help / examples that show you requires their proxy).
> 
> The provider unfortunately doesn't support the use of a local proxy
> e.g. siproxd, so we're the first client to use it!
> 
> I'll maybe try doing a few trial and error things on Monday when I'm
> back in the office. Pehraps with the latest snapshot and the VIA
> errors being fixed I can now remove the proxy, so we'll see if that
> works now :)
> 
> 
> 
> As a quick (unrelated) question, if I get an error about being upable
> to parse SIP message, what level of debug would be useful to you? My
> SNOM 360 seems to get hit by this problem if I channel it through the
> proxy, but no point in me reporting anything unless I can give you
> useful debug :)
> 
> 
> Cheers.
> 
> Col