Twilio not responding to SIP invite

Question

I have a freeSwitch implementation using Twilio's Elastic SIP trunking. For the most part this is working flawlessly. I can receive incoming call from a PSTN to my SIP trunk and onwards to my freeswitch PBX. I can also initiate calls on the termination trunk without issues.

I am having problems when my FollowMe feature tries to dial out through the Termination SIP trunk to call my cell phone.

I have used FS_CLI to monitor the communication out to Twilio, and can see the SIP Invite message - but Twilio does not respond back.

I have even compared (for the most part) the request between when I call out from my extension to a PSTN, and when freeSwitch attempts to call out with FollowMe. They look similar. I have provided the request below, and if anyone can see something thats weird, please let me know. This request just repeats itself and eventually gives up - no response from Twilio, and no log of it in either the Debugger or the Trunk logs. (I have XXXX'ed my numbers)

  send 1506 bytes to udp/[54.172.60.1]:5060 at 16:47:51.442983: ------------------------------------------------------------------------ INVITE sip:+1XXXXXXXXX6@XXXXXX.pstn.twilio.com SIP/2.0 Via: SIP/2.0/UDP XX.XX.XX.XX;rport;branch=z9hG4bKe92m35UyNXe2a Max-Forwards: 59 From: "+1XXXXXXXXX0" <sip:+1XXXXXXXXX0@XXXXXX.oxigenx.com>;tag=3UHvjrXHmUyXp To: <sip:+1XXXXXXXXX6@XXXXXX.pstn.twilio.com> Call-ID: a369c6b9-82af-1235-e490-0050561ee798 CSeq: 104375771 INVITE Contact: <sip:gw+a741d1e8-2e0a-4527-b18d-518edbe57d73@XX.XX.XX.XX:5060;transport=udp;gw=a741d1e8-2e0a-4527-b18d-518edbe57d73> User-Agent: FreeSWITCH 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: 246 Diversion: <sip:+1XXXXXXXXX6@public-vip.us1.twilio.com>;reason=unconditional X-Twilio-AccountSid: XXXXXXXXXXX X-Twilio-CallSid: CA05acdaaae18a720113ab2e78cbd1db63 X-accountcode: admin1.oxigenx.com X-FS-Support: update_display,send_info Remote-Party-ID: "+1XXXXXXXXX0" <sip:+1XXXXXXXXX0@XXXXXX.oxigenx.com>;party=calling;screen=yes;privacy=off v=0 o=FreeSWITCH 1489394171 1489394172 IN IP4 XX.XX.XX.XX s=FreeSWITCH c=IN IP4 XX.XX.XX.XX t=0 0 m=audio 29500 RTP/AVP 0 101 13 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=rtpmap:13 CN/8000 a=ptime:20 ------------------------------------------------------------------------ 

Answer 1

I figured out the problem. Twilio didn't like the Remote-Party-ID parameter that was being sent as part of the INVITE. I turned off the RPID in the SIP Configuration by enabling "caller-id-type" to "none".

To do this, go into your "SIP Profiles" under the "Advanced" menu. From there, select the SIP Profile that you need to disable the RPID. Scroll down the list to find "caller-id-type" with value "none". Click on it and set Enabled to TRUE. Save and restart Sofia from the CLI.

Answer 2

Twilio developer evangelist here.

I am just passing on information I have picked up internally based on this question, I am not a SIP expert. However, it might help.

The MTU (maximum transition unit) for SIP over UDP is 1500 bytes. The spec suggests that SIP messages should be less than 1300 bytes to allow for headers and such, or that the message should be sent over TCP.

It looks as though you were sending 1506 bytes according to the top of your log and removing Remote-Party-ID would have pushed the size of the message under 1500. Effectively, removing any non-essential parameter would have done the same, so it is not that Twilio dislikes the Remote-Party-ID parameter, but your messages were being dropped along the way for being too big. We couldn't find logs of the INVITEs and that is why you couldn't see any logs either.

In this case Remote-Party-ID is not really used by Twilio, especially in the case where the caller id is the same as the From , and is quite a long header. So your solution is probably the best.

You could also drop the Allow-Events header which is to do with the SUBSCRIBE method which Twilio doesn't support.