[Problem] Verbindungsabbrüche VOIP zu T-Mobile (Asterisk)

[mgernoth]

Hallo,

seit ca. 1 Woche brechen bei mir Telefonanrufe von Telekom VOIP (DeutschlandLAN IP Voice/Data L Premium) zu T-Mobile-Anschlüssen nach genau 15 Minuten ab. Dies geschieht, wenn Asterisk zur Terminierung des Telekom SIP-Accounts eingesetzt wird, aber nicht, wenn stattdessen eine Digitalisierungsbox Premium genutzt wird.

Anscheinend geht beim 15 minütigen erneuern der SIP-Session der RTP-Stream auf Seiten der Telekom verloren, zumindest hören die RTP-Pakete direkt nach dem durch die Telekom ausgelösten reINVITE (noch mit korrektem RTP Quellport) auf. Weitere INVITEs von der Telekom geben dann auf einmal UDP-Port 0 als RTP-Quellport an. Die Digitalisierungsbox unterstützt im Gegensatz zu Asterisk die UPDATE-Methode, welche von der Telekom statt der reINVITEs genutzt wird, hier tritt das Problem nach einem UPDATE nach 15 Minuten nicht auf.

Andere Ziele (getestet mit Festnetz bei Telekom und anderen Providern) haben dieses Problem nicht, hier bleibt der RTP-Stream nach den reINVITEs bestehen.

Tritt dieses Problem noch bei anderen Leuten auf (evtl. auch mit anderen SIP-Clients), wenn von einem Telekom VOIP-Anschluss ein T-Mobile-Anschluss angerufen wird, oder bin ich der einzige?

Danke & Viele Grüße
Michael

 

[frankfiedler]

Halllo Michael!
Ich habe leider das selbe Problem bei einer unserer Anlagen. Nach ca. 15 Minuten kommt von Seiten der Telekom ein reInvite in dem der RTP Port auf 0 geschrieben wird.
Ich habe bei dem peer schon auf "canreinvite=no" als auch "canreinvite=update" gesetzt, leider bringt beides keine Abhilfe.
Hast du noch einen Weg gefunden wie das bei dir nun funktionieren?

Inzwischen ist das ganze zu 100% reproduzierbar. Allerdings nur in bestimmten Kombinationen: Ausgehender Anruf auf eine Mobilfunknummer. Auch bemerkenswert ist, dass es immer nur dann auftritt bei einer Kommunikation mit einem Server der Telekom der die IP-Adresse "217.0.23.100" hat. Ab und an hat das Gespräch auch schon mal länger als 15 Minuten funktioniert, dann ist es allerdings nach 30 Minuten abgebrochen.

Über weitere Ideen wär ich sehr Dankbar. Werde mich aber auch mal an den Telekom-Support wenden.

Danke und viele Grüße
Frank

Hier ein Beispiel für einen solchen "falschen" Invite: (Werte abgeändert)

INVITE sip:[email protected]:5060 SIP/2.0
Max-Forwards: 66
Via: SIP/2.0/UDP 217.0.23.100:5060;branch=z9hG4bKg3Zqkv7isv3viguq3x1tsbb8sl49h5p2y
To: "0987654321" <sip:[email protected]>;tag=as78adbf6f
From: <sip:[email protected]>;tag=h7g4Esbg_p65542t1476860612m218715c1167213114s1_1747751973-1587766360
Call-ID: [email protected]
CSeq: 106 INVITE
Contact: <sip:[email protected];transport=udp>;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"
Min-Se: 900
Session-Expires: 1800;refresher=uac
Supported: timer
Content-Type: application/sdp
Content-Length: 175
Allow: REGISTER, REFER, NOTIFY, SUBSCRIBE, INFO, PRACK, UPDATE, INVITE, ACK, OPTIONS, CANCEL, BYE

v=0
o=- 778908697 1750042392 IN IP4 131.59.53.129
s=-
t=0 0
m=audio 0 RTP/AVP 9 101
a=rtpmap:9 G722/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20

 

[mgernoth]

Hallo Frank,

Hast du noch einen Weg gefunden wie das bei dir nun funktionieren?

Ja, allerdings einen recht aufwändigen: Ich bin von dem in Debian enthaltenen Asterisk 11 mit chan_sip auf Asterisk 14.0.2 mit PJSIP umgestiegen, welches die UPDATE-Methode unterstützt. Damit brechen Mobilfunkgespräche nicht mehr ab.

Falls man aber einige Spezialfunktionen von chan_sip benutzt (Call-Pickup bei SNOM z.B., dann geht das bei PJSIP nicht mehr. Ich fühle mich 10 Jahre in der Zeit zurückversetzt...)

Inzwischen ist das ganze zu 100% reproduzierbar. Allerdings nur in bestimmten Kombinationen: Ausgehender Anruf auf eine Mobilfunknummer. Auch bemerkenswert ist, dass es immer nur dann auftritt bei einer Kommunikation mit einem Server der Telekom der die IP-Adresse "217.0.23.100" hat.

Ja, bei mir war es auch immer die 217.0.23.100.

Über weitere Ideen wär ich sehr Dankbar. Werde mich aber auch mal an den Telekom-Support wenden.

Das mach ich nicht mehr bei solchen Fehlern, da der Support dann nur wieder die DSL-Leitung kaputt macht (habe ein IPv6 Routing-Problem gemeldet, führte dazu, dass ich nur am KVz auf ein neues Adernpaar gelegt wurde. Am APL hat niemand vorbeigeschaut, Routing wurde natürlich auch nicht repariert...).

PJSIP Config:

[transport-dtag]
type=transport
protocol=udp
bind=0.0.0.0:1234
tos=cs6

[dtag-defaults](!)
type=registration
transport=transport-dtag
outbound_auth=dtag
server_uri=sip:tel.t-online.de
line=yes
endpoint=dtag
retry_interval=60
expiration=480
auth_rejection_permanent=false
max_retries=535680

[dtag-MSN1](dtag-defaults)
client_uri=sip:[email protected]
contact_user=+49911MSN1

[dtag-MSN2](dtag-defaults)
client_uri=sip:[email protected]
contact_user=+49911MSN2

[dtag]
type=auth
auth_type=userpass
[email protected]
password=geheimespasswort
realm=tel.t-online.de

[dtag]
type=endpoint
transport=transport-dtag
context=dtag-in
disallow=all
allow=g722
allow=alaw
outbound_auth=dtag
from_domain=tel.t-online.de
aors=dtag
direct_media=no
tos_audio=ef
trust_id_outbound=yes
send_pai=yes
timers=no

[dtag]
type=aor
contact=sip:tel.t-online.de

Dialplan:

context set-identity {
        ppi => {
                Set(PJSIP_HEADER(add,P-Preferred-Identity)=${PPI});
                Return();
        };
};

context dtag-out {
        _[*#+0123456789]. => {
                Set(_PPI=<sip:${CALLERID(num)}@tel.t-online.de>);
                Dial(PJSIP/${EXTEN}@dtag,,b(set-identity^ppi^1));
                Hangup(${HANGUPCAUSE});
        }
...

Viele Grüße
Michael