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
Via: SIP/2.0/UDP 999.999.999.999;rport;branch=
CSeq: 102235968 INVITE
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
o=FreeSWITCH 1485122965 1485122966 IN IP4 999.999.999.999
c=IN IP4 999.999.999.999
m=audio 21100 RTP/AVP 0 102 103 9 8 3 101 13
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 Disqus
Most Read Posts in Technology
Read about IT, Migration, Business, Money, Marketing and other subjects.
Some subjects: FusionPBX, FreeSWITCH, Linux, Security, Canada, Cryptocurrency, Trading.