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.
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=
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-
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~
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.
To make this work, I followed these steps:
After that, I reduce the UDP packet and the call went through.
Good Luck!
blog comments powered by DisqusMost Read Posts in Technology
About
Read about IT, Migration, Business, Money, Marketing and other subjects.
Some subjects: FusionPBX, FreeSWITCH, Linux, Security, Canada, Cryptocurrency, Trading.