24 Jun
2015
24 Jun
'15
8:06 a.m.
On 23/06/15 19:06, Andrey Utkin wrote:
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Book: SIP Routing With Kamailio - http://www.asipto.com
2015-06-23 18:49 GMT+03:00 Daniel-Constantin Mierla
<miconda(a)gmail.com>om>:
Jisti has options to enable logging -- search on the web how to enable
and where is located the log file.
It would be interesting to see if it receives any packet and prints any
error message there.
Have you tried with tls? That will rule out eventual packet mangling on
the way done by providers/routers ALGs.
Cheers,
Daniel
Have you grabbed the sip trace on client side to
see what it is
receiving? Are the clients reporting errors?
Yes, see this
https://gist.github.com/krieger-od/c9fe6ea4bb64fac82cda
this is taken on Linux box running Jitsi desktop app.
It doesn't report anything, or I haven't seen the log, ut just doesn't
show the incoming call. If you have a snom phone, you can easily see the
received sip packets
via web interface. Perhaps the desktop phones will have also some logs
printing what is happening that can be accessed easily.
Eventually you can try to run a kamailio locally, near the client, using
it as an intermediate proxy between the phone and the main sip server.
The timestamps I checked in previous traces were not following the sip
retransmissions intervals (0.5sec, 1sec, 2sec, ...), a clear indication
that it is not kamailio transaction layer doing retransmissions.
As I said before, ngrep is not a source to trust
when dealing with large
packets. Also, it can happen that it prints the same packet twice.
But what
sniffer should I try instead of ngrep to have more details
and confidence?
Also I guess you mean this to be an issue of Linux kernel on any side,
or possibly of routing hardware somewhere in the route?