Twilio reagiert nicht auf SIP-Einladung

Question

Ich habe eine FreeSwitch-Implementierung mit Twilio Elastic SIP Trunking. Zum größten Teil funktioniert das einwandfrei. Ich kann einen eingehenden Anruf von einem PSTN zu meinem SIP-Trunk und weiter zu meiner Freeswitch-PBX empfangen. Ich kann auch Anrufe auf der Abschlussleitung ohne Probleme einleiten.

Ich habe Probleme, wenn meine FollowMe-Funktion versucht, über die Termination-SIP-Amtsleitung zu wählen, um mein Mobiltelefon anzurufen.

Ich habe FS_CLI verwendet, um die Kommunikation zu Twilio zu überwachen, und kann die Nachricht SIP Invite sehen - aber Twilio antwortet nicht zurück.

Ich habe sogar verglichen (zum größten Teil) die Anfrage zwischen, wenn ich aus meiner Nebenstelle zu einem PSTN aufrufen, und wenn freeSwitch versucht, mit FollowMe aufzurufen. Sie sehen ähnlich aus. Ich habe die unten stehende Anfrage gestellt, und wenn jemand etwas seltsames sehen kann, lass es mich wissen. Diese Anfrage wiederholt sich nur und gibt schließlich auf - keine Antwort von Twilio und keine Protokollierung in den Debugger- oder Trunk-Protokollen. (Ich habe meine Nummern XXXX'ed)

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

Twilio Entwickler Evangelist hier.

Ich gebe nur Informationen weiter, die ich intern anhand dieser Frage gesammelt habe, ich bin kein SIP-Experte. Es könnte jedoch helfen.

Die MTU (maximale Übergangseinheit) für SIP über UDP beträgt 1500 Byte. Die Spezifikation schlägt vor, dass SIP-Nachrichten weniger als 1300 Bytes umfassen sollten, um Header und dergleichen zu ermöglichen, oder dass die Nachricht über TCP gesendet werden sollte.

Es sieht so aus, als ob Sie 1506 Bytes gemäß dem oberen Ende Ihres Protokolls gesendet hätten und das Entfernen Remote-Party-ID hätte die Größe der Nachricht unter 1500 geschoben. Effektiv hätte das Entfernen von nicht-essentiellen Parametern das Gleiche getan ist nicht, dass Twilio den Parameter Remote-Party-ID ablehnt, aber Ihre Nachrichten wurden auf dem Weg fallengelassen, weil sie zu groß waren. Wir konnten keine Logs der INVITEs finden und deshalb konnten Sie auch keine Logs sehen.

In diesem Fall Remote-Party-ID nicht wirklich von Twilio, vor allem in dem Fall verwendet, bei dem die Anrufer-ID das gleiche wie die From ist, und ist ein ziemlich langer Header. Ihre Lösung ist wahrscheinlich die beste.

Sie könnten auch die Allow-Events Header, die mit der SUBSCRIBE Methode, die Twilio nicht unterstützt, fallen lassen.

Answer 2

ich das Problem gelöst. Twilio mochte den Parameter Remote-Party-ID nicht, der als Teil von INVITE gesendet wurde. Ich habe die RPID in der SIP-Konfiguration deaktiviert, indem ich "caller-id-type" auf "none" gesetzt habe.

Um dies zu tun, gehen Sie in Ihre "SIP-Profile" im Menü "Advanced". Wählen Sie dort das SIP-Profil aus, das Sie zum Deaktivieren der RPID benötigen. Scrollen Sie in der Liste nach "caller-id-type" mit dem Wert "none". Klicken Sie darauf und setzen Sie Enabled auf TRUE. Speichern und starten Sie Sofia von der CLI aus neu.