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