Vodafones SIP Server verstößt gegen Schnittstellenbeschreibung

[Ein_Nutzer]

Hallo,

in der Schnittstellenbeschreibung von Vodafone wird die RFC3261 referenziert und ein Endgerät muss mit dieser übereinstimmen (mit einigen Außnahmen die in der Schnittstellenbeschreibung näher definiert werden). Leider ist mit einem Client der die RFC3261 streng befolgt nach einiger Zeit kein ausgehendes Gespräch mehr möglich:

Ein Client sendet eine REGISTER-Anfrage an den SIP Server mit einer gewissen Expire-Dauer die der Client sich wünscht. Der Server legt eine Dauer fest, die RFC sagt dazu:

The registrar MAY choose an expiration less than the requested
expiration interval. If and only if the requested expiration
interval is greater than zero AND smaller than one hour AND
less than a registrar-configured minimum, the registrar MAY
reject the registration with a response of 423 (Interval Too
Brief). This response MUST contain a Min-Expires header field
that states the minimum expiration interval the registrar is
willing to honor. It then skips the remaining steps.

Das heißt also der Server darf eine Zeit geringer als meine angefragte Zeit nehmen (im Beispiel unten weniger als 10 Sekunden), jedoch darf er keine Zeit nehmen die größer ist als meine angefragte. Dies ist in der RFC nicht vorgesehen, auch in der Schnittstellenbeschreibung ist dies nicht vorgesehen. Dies wäre alles halb so schlimm wenn das angegebene expires=3600 funktionieren würde, jedoch werden ausgehende Gespräche bereits nach dem angeforderten Expires von 10 Sekunden mit einem 403 Forbidden abgelehnt. Eingehende Gespräche sind bis zum Ende der 3600 Sekunden erfolgreich. Ein konformer Client (wie er in der Schnittstellenbeschreibung gefordert ist) wartet nun jedoch bis zum Ende der 3600 Sekunden um seine Registrierung zu erneuern (und das zu Recht denn diese Dauer wurde ihm, wenn auch zu Unrecht, als Gültigkeit angegeben), dies ist bei Asterisk mit pjsip ein Problem da dieser Client völlig konform läuft, bei chan_sip war der Client nicht konform und dementsprechend gab es dort bislang keine Probleme weil die Antwort ignoriert wurde.

Dies sieht als Traffic so aus (man beachte das angefragte "Expires: 10" und das erhaltene expires=3600):

<--- History Entry 36 Sent to xx.xxx.xxx.xxx:5060 at 1559610640 --->
REGISTER sip:xxx.xxxxxxxxx.xxxxxxxx.xx SIP/2.0
Via: SIP/2.0/UDP xx.xx.xxx.xx:5060;rport;branch=z9hG4bKPj16be6009-4ebd-4b71-8656-7da0fda7b9b2
From: <sip:xxxxxxxxxx@xxx.xxxxxxxxx.xxxxxxxx.xx>;tag=7b623796-18f1-411d-abed-cde1e5fb285b
To: <sip:xxxxxxxxxx@xxx.xxxxxxxxx.xxxxxxxx.xx>
Call-ID: 76e6c939-2517-431a-ad5c-6021112f0fac
CSeq: 7550 REGISTER
Contact: <sip:xxxxxxx@x.x.x.x:5060>
Expires: 10
Allow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REGISTER, MESSAGE, REFER
Max-Forwards: 70
User-Agent: Asterisk PBX
Authorization: Digest username="xxxxxx", realm="xxxxxxx.xxxxxxxxxxxx.xx", nonce="xxxxxxxxxxxxxxxxxx", uri="sip:xxx.xxxxxxxxxx.xxxxx.xxx", response="xxxxxxxxxxxxxxxxxxxxx", algorithm=MD5
Route: <sip:xxx.xxxxxxxxx.xxxxxxxx.xx>
Content-Length:  0

<--- History Entry 37 Received from xx.xxx.xxx.xxx:5060 at 1559610640 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP xx.xx.xxx.xx:5060;rport=62474;received=xx.xx.xxx.xx;branch=z9hG4bKPj16be6009-4ebd-4b71-8656-7da0fda7b9b2
From: <sip:xxxxxxxxxx@xxx.xxxxxxxxx.xxxxxxxx.xx>;tag=7b623796-18f1-411d-abed-cde1e5fb285b
To: <sip:xxxxxxxxxx@xxx.xxxxxxxxx.xxxxxxxx.xx>;tag=SDrokq999-rr5t6p5t
Call-ID: 76e6c939-2517-431a-ad5c-6021112f0fac
CSeq: 7550 REGISTER
Contact: <sip:xxxxxxx@x.x.x.x:5060>;q=1;expires=3600
Content-Length: 0
Content-Length:  0

Ein Workaround ist die Expires Anfrage auf 3600 hochzudrehen, das gibt jedoch viele andere Probleme mit Firewalls die dann Probleme mit dem UDP Datenverkehr haben. Vielleicht könnte man dort einmal nachbessern und den expires-Header in der Antwort nicht unzulässigerweise erhöhen, insbesondere das "halb" erhöhen sodass eingehende Anrufe möglich sind, jedoch keine ausgehenden ist hier schädlich.

Wäre super nett wenn ein Mod das ganze einmal an die entsprechende Fachabteilung weitergeben kann, das ist doch sehr störend so. Dies passiert seit Januar, irgendwann zwischen dem 20. Januar und dem 28. Januar.

[meister_voda]

Hallöchen,

ohne deine verwendete sip.conf genau zu kennen, kann man dir nur schlecht weiterhelfen.  Generell kann ich nur sagen, dass ein derart kleiner Registrierungsintervall generell wenig zielführend ist.  Um die Ports einer Firewall offen zu halten, bietet Asterisk bessere Optionen…

Pro-Tipp von mir:

Unter in der sip.conf unter [general] die Parameter rtpkeepalive = 10 und keepalive=60 setzen, sowie die expiry auf 3600 zu setzen.  Ggf. kann man hilfsweise noch register_retry_403=yes setzen.

[Ein_Nutzer]

Hi,

ich nutze nicht chan_sip sondern das neue chan_pjsip, demnach wäre das wenn dann die pjsip.conf. Bislang hatte ich 120 Sekunden als register-interval, das finde ich jetzt nicht übertrieben kurz sondern durchaus normal und angemessen.

Mein Problem ist nur, das der Server seit einigen Monaten mit einem expiry antwortet was größer ist als das von mir angefragte, was dann dafür sorgt das Asterisk "aus Nettigkeit" diesen Wert akzeptiert und erst nach 3600 Sekunden erneut wieder anfragt. Das ganze ist aber im Standard gar nicht gewollt, wenn mein Interval zu klein ist sollte eine "Interval too Brief"-Antwort kommen und nicht der Server einfach am expiry rumändern. Daher fände ich es gut bzw. notwendig, wenn diese Änderung wieder rückgängig gemacht wird, die RFC nochmal gelesen wird und dann nochmal das ganze implementiert wird. Oder wenn wenigstens auch dem Teil der für die ausgehenden Anrufe verantwortlich ist mitgeteilt wird das es eine (unzulässige) Erhöhung des expiry's gab sodass nicht die Registrierung für eingehende Gespräche nach 3600 Sekunden ein Timeout hat und die Authorisierung für ausgehende Gespräche nach meiner angefragten Zeit. Nach Ablauf der von mir angefragten Zeit sind dann keine Gespräche mehr möglich, also wenn ich 10 Sekunden anfrage dann kann ich für 10 Sekunden lang ausgehende Gespräche führen und danach nur noch eingehende empfangen, bis nach 3600 Sekunden wieder erneuert wird.

Bei mir gibt es auch keine Firewall-Probleme damit, ich habe in meiner Firewall das Timeout einfach entsprechend hochgedreht, aber bei anderen ist das durchaus möglich und warscheinlich kann/will nicht jeder einfach in der Firewall am State Timeout was ändern, bei einer FritzBox wird das nämlich schon schwierig werden.

[meister_voda]

Ups, dass es die pjsip.conf ist, war mir gestern abend gar nicht aufgefallen…

Allerdings lässt sich auch dort unter [global] die Option keep_alive_interval=10 und unter [endpoint] die Option rtp_keepalive=10 setzen, damit das State Timeout der FW nicht zum Tragen kommt. Dann kann man die Expiry unproblematisch auf dem Default-Wert von 3600 Sekunden lassen.

[Ein_Nutzer]

In der demo-pjsip config steht:

;keep_alive_interval=20 ; The interval (in seconds) at which to send keepalive
                        ; messages on all active connection-oriented transports
                        ; (default: "0")

Wir sind hier aber mit UDP gar nicht bei "connection-oriented" (Verbindungsorientierte Paketvermittlung), das wäre TCP, sondern haben hier Verbindungslose Paketvermittlung durch UDP, die Option ist hier also wirkungslos. Wie sollte denn so ein UDP keepalive-Paket auch aussehen, zumal wenn die Gegenseite nicht antwortet das ganze nichts bringt da eine halbe Verbindung nutzlos ist (insbesondere wenn die Hälfte geschlossen ist die nicht einfach wieder aufgebaut werden kann).

[Ein_Nutzer]

Möchte sich niemand diesem Problem annehmen? 

[ERFD]

Hallo Ein_Nutzer,

wir schauen uns dies gern an. Wir benötigen dafür Deine Kundennummer, Anschrift, Dein Geburtsdatum und die gesamte Konfiguration Deinerseits per Privatnachricht.

Schreibe mir hier kurz, wenn Du die Daten verschickt hast.

Gruß Fred