Hi,
My Kamailio box works very well for a year, in front of a Freeswitch box. Nowadays, some of my users live problems about receiving calls. But this problem occurs on a couple of specific users. %1 of users complain about it. When I capture the traffic, I see that, Kamailio receives an invite package from freeswitch but takes no action. Normally it should response with a 100 trying message. Here is the INVITE package. 1.2.3.6 is the Freeswitch box and 1.2.3.2 is the Kamailio box. I captured this package on Kamailio box.
U 1.2.3.6:5060 -> 1.2.3.2:5060 INVITE sip:2000@test.example.net SIP/2.0. Via: SIP/2.0/UDP 1.2.3.6;rport;branch=z9hG4bKZU1Z76FvDZ26r. Route: sip:1.2.3.2;lr. Max-Forwards: 65. From: "908508850000" sip:908508850000@test.example.net;tag=KjcgDe0NyKN0B. To: sip:2000@88.235.112.33:1028. Call-ID: 72b344f4-1c09-1233-ad8d-0050568e9066. CSeq: 70585075 INVITE. Contact: sip:mod_sofia@1.2.3.6:5060. User-Agent: FreeSWITCH-mod_sofia/1.4.14+git~20141119T221113Z~ca1d990cfc~64bit. Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE. Supported: timer, path, replaces. Allow-Events: talk, hold, conference, presence, as-feature-event, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer. Content-Type: application/sdp. Content-Disposition: session. Content-Length: 270. X-AUTH-IP: 159.253.40.138. X-BF-SRC: 2. X-FS-Support: update_display,send_info. Remote-Party-ID: "908508850000" <sip:908508850000@test.example.net
;party=calling;screen=yes;privacy=off.
. v=0. o=FreeSWITCH 1421813895 1421813896 IN IP4 1.2.3.6. s=FreeSWITCH. c=IN IP4 1.2.3.6. t=0 0. m=audio 28384 RTP/AVP 3 8 0 101 13. a=rtpmap:3 GSM/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:0 PCMU/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=ptime:20.
I use standart location lookup and relay procedure in Kamailio default script. Is there anything wrong with this INVITE package and how can I trace this issue on Kamailio box?
Thank you.
/Volkan
On Wednesday 21 January 2015 13:42:07 Volkan Oransoy wrote:
Content-Length: 270.
v=0. o=FreeSWITCH 1421813895 1421813896 IN IP4 1.2.3.6. s=FreeSWITCH. c=IN IP4 1.2.3.6. t=0 0. m=audio 28384 RTP/AVP 3 8 0 101 13. a=rtpmap:3 GSM/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:0 PCMU/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=ptime:20.
Is there anything wrong with this INVITE package and how can I trace this issue on Kamailio box?
Content-Length = 270 bytes. I count 248 if line endings are \n, or 260 is lines end in \r\n. Packet is incomplete, looks like something is breaking when you are going over +/- 1300bytes per invite. Make a capture with tcpdump/tshark/wireshark to see if there is more.
Thank you Daniel,
The weird thing is, this problem is not persistent. Now it works as usual and I can't reproduce the problem.
According to your reply, problem may be at Freeswitch box.
How can I calculate Content Length from capture? And if this is a message size issue, how can I fix it?
/Volkan
2015-01-21 14:58 GMT+02:00 Daniel Tryba d.tryba@pocos.nl:
On Wednesday 21 January 2015 13:42:07 Volkan Oransoy wrote:
Content-Length: 270.
v=0. o=FreeSWITCH 1421813895 1421813896 IN IP4 1.2.3.6. s=FreeSWITCH. c=IN IP4 1.2.3.6. t=0 0. m=audio 28384 RTP/AVP 3 8 0 101 13. a=rtpmap:3 GSM/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:0 PCMU/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=ptime:20.
Is there anything wrong with this INVITE package and how can I trace this issue on Kamailio box?
Content-Length = 270 bytes. I count 248 if line endings are \n, or 260 is lines end in \r\n. Packet is incomplete, looks like something is breaking when you are going over +/- 1300bytes per invite. Make a capture with tcpdump/tshark/wireshark to see if there is more.
--
Telefoon: 088 0100 700 Sales: sales@pocos.nl | Service: servicedesk@pocos.nl http://www.pocos.nl/ | Croy 9c, 5653 LC Eindhoven | Kamer van Koophandel 17097024
On Wednesday 21 January 2015 15:10:07 Volkan Oransoy wrote:
The weird thing is, this problem is not persistent. Now it works as usual and I can't reproduce the problem.
According to your reply, problem may be at Freeswitch box.
It is to early to conclude, the ngrep outpout isn't complete. If an invite is fragmented and transmitted with UDP my experience is that you will not see the other fragments with ngrep. tcpdump/tshark will capture them (and may or may not show them properly in wireshark).
How can I calculate Content Length from capture? And if this is a message size issue, how can I fix it?
Content-Length is the size of the body, which starts after the first empty line. So from "v=0" to "a=ptime:20". The dots at the end of the lines are \r characters and an "invisible" \n you have to count too. Simpelest way is to save it to a file and look at the filesize :)