User Rating: 5 / 5

Star Active Star Active Star Active Star Active Star Active
 

Last week, one of my very best customers asked me to do a dial plan that forwards an incoming call to an external server. So far, that can be done with a bridge statement pointing to sofia/internal/xxxx@server. But it was more complex as it seemed. The system administrator of the remote server claimed that no calls were arriving.

Symptom

I did put a sniffer with tcpdump and found the SIPI INVITE signal as follows:

23:01:05.856957 IP (tos 0x0, ttl 64, id 8448, offset 0, flags [none], proto UDP (17), length 1541)
999.999.999.999.sip > 888.888.888.888.sip: SIP, length: 1513
INVITE sip:This email address is being protected from spambots. You need JavaScript enabled to view it. SIP/2.0
Via: SIP/2.0/UDP 999.999.999.999;rport;branch= z9hG4bKFBpmSFN07SDyr
Max-Forwards: 68
From: "3120000000" <This email address is being protected from spambots. You need JavaScript enabled to view it.">;tag=jra8pUv0H67SS
To: <This email address is being protected from spambots. You need JavaScript enabled to view it.>
Call-ID: 67bad02b-5bc3-1235-09a5- 04015e498801
CSeq: 102235968 INVITE
Contact: <sip:This email address is being protected from spambots. You need JavaScript enabled to view it.:5060>
User-Agent: FreeSWITCH-mod_sofia/1.4.20~ 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
Privacy: none
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 412
X-CORP-ID: 93362127
X-SUB-ADX: ib03slc;noa=4
X-ORIG-CDPN: 18661231234;noa=4
X-CHARGE-NUM: 13120000000;noa=4
X-INFO-DIG: 0
X-ORIG-CGPN: 0
X-HOP-CNT: 2
X-SC-HOST: DNJ-SC31
X-FS-Support: update_display,send_info
P-Asserted-Identity: "3120000000" <This email address is being protected from spambots. You need JavaScript enabled to view it.>

v=0
o=FreeSWITCH 1485122965 1485122966 IN IP4 999.999.999.999
s=FreeSWITCH
c=IN IP4 999.999.999.999
t=0 0
m=audio 21100 RTP/AVP 0 102 103 9 8 3 101 13
a=rtpmap:0 PCMU/8000
a=rtpmap:102 G7221/32000
a=fmtp:102 bitrate=48000
a=rtpmap:103 G7221/16000
a=fmtp:103 bitrate=32000
a=rtpmap:9 G722/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20

So far so good this seemed pretty wel. However, after some retries, I found this:

23:01:11.683409 IP (tos 0x0, ttl 54, id 29990, offset 0, flags [none], proto ICMP (1), length 576)
888.888.888.888 > 999.999.999.999: ICMP ip reassembly time exceeded, length 556
IP (tos 0x0, ttl 54, id 8445, offset 0, flags [+], proto UDP (17), length 1500)

You do not need to be very smart to realize that this issue is related to IP fragmentation. As I didn't have access to the remote server or any kind of communication, I decided to do the minimizing approach.

Workaround

To make this work, I followed these steps:

  1. Turn ON compact headers in the Internal Profile by adding enable-compact-headers=true. This requires a reload of mod_sofia.
  2. Strip useless headers by using the unset action. All the X-* headers are custom headers that can be stripped by doing something like unset sip_h_X-HEADER just before the bridging command.
  3. Take out useless codecs by setting absolute_codec_string=PCMU,PCMA just before the bridging command

After that, I reduce the UDP packet and the call went through.

Good Luck!

blog comments powered by Disqus