23 Jun
2015
23 Jun
'15
11:49 a.m.
Have you grabbed the sip trace on client side to see what it is
receiving? Are the clients reporting errors?
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.
Daniel
On 23/06/15 17:32, Andrey Utkin wrote:
2015-06-19 12:45 GMT+03:00 Daniel-Constantin Mierla
<miconda(a)gmail.com>om>:
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Book: SIP Routing With Kamailio - http://www.asipto.com
Also, ngrep is not always good at capturing big
packets, so just seeing
partial sip packets is ok as long as the receiving party doesn't
complain of broken/incomplete sip packet.
Thank you Daniel for answering.
We still struggle from this weird issue. Now I can reproduce it in my
location with recent Kamailio from git, with all SIP over TCP clients
- Linphone, Sipdroid, Jitsi (desktop Java-based app).
Here are ngrep logs from both server and client sides, and server
syslog containing Kamailio output (filtered by substring "tcp"
case-insensitively).
https://gist.github.com/krieger-od/55427f2b3923b910bacb
https://gist.github.com/krieger-od/c9fe6ea4bb64fac82cda
https://gist.github.com/krieger-od/96ef40ca15ef2407b5f4
Here you can see that only a "tail" of INVITE message gets transmitted
to client side, which is weird.
This is Amazon server; it have MTU 9001 by default, but setting it to
900 or 1100 haven't made any difference. Also I have reproduced this
issue on DigitalOcean VPS, so this mustn't be Amazon-specific issue.
Because I have tried different SIP useragents supporting TCP, I'm
afraid this can be considered Kamailio issue (honestly, I still don't
quite believe as I percept Kamailio as robust and stable software).
Any review and comment helps.