FreePBX Telekom pjsip ab 20.03.2023

[Tom-VoIP]

Hallo Zusammen,

seit ca. 1 Jahr arbeitet FreePBX in einer VMWare VM absolut fehlerfrei.

Seit dem 20.03.2023 konnte ich weder angerufen werden, noch rausrufen.

Asterisk zeigt die Trunks mit dem Status "Registered".

Nach langem Suchen habe ich herausgefunden, dass die Trunk Option "Media Encryption = SRTP via in-SDP (recommended)" Abhilfe für die eingehenden Telefonate bringt. Sprich ich kann nun wieder angerufen werden.

Ausgehende Gespräche quittiert FreePBX mit "Die Zielrufnummer ist gesperrt der Verbindungsaufbau ist nicht möglich. Zur Zeit sind alle Verbindungen belegt. Please try your call again later."

Der Asterisk Debug bringt mich nicht wirklich weiter. sngrep zeigt "SIP/2.0 503 Service Unavailable":


[Edit Novize: Riesenbild gemäß der Forumsregeln auf Vorschau verkleinert]

Setup:
Asterisk Version: 19.3.0
FreePBX 16.0.33
FritzBox 7590 (keine NAT Freigaben)
MagentaZuhause L

Ich weis gar nicht wo ich jetzt ansetzen / debuggen könnte. Was hat die Telekom da wieder geändert :-(

DANKE IM VORAUS !!

 

[gehtdoch]

Der Trace ist an der falschen Stelle - Du brauchst den Trace von Asterisk -> Telekom.

 

[Tom-VoIP]

Absolut, aber ich glaube ich komme gar nicht soweit.

Ich habe via " asterisk -rvvvv" und "sip set debug on" ein debug erzeugt. Wegen der Länge hier als Dateianhang.

Für mich als SIP Laie finde ich nur:

== Everyone is busy/congested at this time (1:0/0/1)​

"Dial failed for some reason with DIALSTATUS = CHANUNAVAIL and HANGUPCAUSE = 21"​

Bei eingehende Gesprächen ist alles in Ordnung...

Ich bin wieder ein Schritt weiter und habe es geschafft einen SIP Trace zu erzeugen
=> Dateianhang: ausgehend.txt
(asterisk -r / pjsip set logger on)

freepbx*CLI> pjsip show endpoints Endpoint: <Endpoint/CID.....................................> <State.....> <Channels.> I/OAuth: <AuthId/UserName...........................................................> Aor: <Aor............................................> <MaxContact> Contact: <Aor/ContactUri..........................> <Hash....> <Status> <RTT(ms)..> Transport: <TransportId........> <Type> <cos> <tos> <BindAddress..................> Identify: <Identify/Endpoint.........................................................> Match: <criteria.........................> Channel: <ChannelId......................................> <State.....> <Time.....> Exten: <DialedExten...........> CLCID: <ConnectedLineCID.......> ========================================================================================== Endpoint: 60/60 Unavailable 0 of inf InAuth: 60-auth/60 Aor: 60 1 Endpoint: 1234567_xxxx Not in use 0 of inf OutAuth: 1234567_xxxx/[email protected] Aor: 1234567_xxxx 0 Contact: 1234567_xxxx/sip:[email protected] 147becc859 Avail 38.334 Transport: 0.0.0.0-tls tls 3 96 0.0.0.0:5061 Identify: 1234567_xxxx/1234567_xxxx Match: 217.0.148.5/32 Match: 217.0.29.32/32 Match: 217.0.28.32/32 Match: 217.0.29.36/32 Match: 217.0.28.34/32

[Edit Novize: Beiträge zusammengefasst - siehe Forumsregeln]

Mit einem Wireshark Trace werde ich auch nicht schlauer. Alles TLS:

 

[gehtdoch]

Hallo @Tom-VoIP, die Traces sind aufschlussreich.

Es wird zur Telekom verschlüsselt gesprochen. Das ist ok. Es wird kein mediasec benötigt (d.h., das ist einer der neuen SIP-Server der Telekom, die benötigen das nicht mehr).

Der ausgehende Call zur Telekom wird auch einwandfrei aufgebaut (INVITE, TRYING, RINGING mit 100rel). Dann wird das interne Device darüber informiert (via Trying und Session Progress). Der Session Progress scheint ihm (Bria) nicht zu schmecken - es legt einfach auf. Das wird dann natürlich bis zum TN B transportiert und der Call wieder abgebaut.

Was kann man final sagen:
1. Du hast keinerlei Problem mit der Telekom
2. Dein eigenes Telefon spielt nicht mit - sagt aber nicht, warum (falls Du es nicht warst, der aufgelegt hat).

Ich habe den Verdacht, dass es an der Codec-Konfiguration des Bria liegen könnte. Vielleicht mal auf G722 / G711 (oder andere Reihenfolge testweise, also G711 / G722 oder G722 ganz weglassen) reduzieren und alles andere rauswerfen? Mehr brauchst Du im Festnetz sowieso nicht.

 

[Tom-VoIP]

Danke gehtdoch,

das wäre eine super logische Erklärung warum ich nur angerufen werden kann. Leider aber ohne Erfolg, ich habe G711 aLaw, G711 uLaw und G722 jeweils einzeln getestet.

Ich habe auch noch 2 FritzFon's welche via FritzBox-Dect via SIP Extension an die FreePBX angeschlossen sind. Auch diese können nicht raus (nur rein).
Anbei ein Trace von einem FritzFon (Anhang fritzfon trace.txt).

Hier finde ich ein 603 Decline Paket:

<--- Received SIP response (853 bytes) from TLS:217.0.148.5:5061 --->​

SIP/2.0 603 Decline​

Via: SIP/2.0/TLS 79.213.138.123:5061;received=79.213.138.123;rport=45393;branch=z9hG4bKPj01d0cde6-3290-4d22-95ed-5e3ae718dabd;alias​

From: <sip:[email protected];user=phone>;tag=1ccb9463-e6e8-4f4a-a67f-1242c7177794​

To: <sip:[email protected];user=phone>;tag=p65550t1680200628m86517c106414s1_832016351-1​

Call-ID: e5905f11-f8d1-4f29-910d-7f30b3626539​

CSeq: 22210 INVITE​

Contact: <sip:mavodi-0-266-45-4-fffffff0-11c30000-5f6d21ed48f33-91c-ffffffffffffffff-@217.0.148.5:5061>​

Record-Route: <sip:mavodi-0-266-45-4-ffffffff-11c30000-5f6d21ed48f33-91c-ffffffffffffffff-mavsipodi-0-26c-b5-4-51e80000-5f6d21ed04e85-91c@217.0.148.5:5061;transport=tls;lr;mavsipodi-0-26c-b5-4-51e80000-5f6d21ed04e85-91c>​

Session-ID: 00000000000000000000000000000000; remote=a4043594571c08491b1efde9088df357​

Content-Length: 0​

 

[gehtdoch]

Das Szenario ist aber ein komplett anderes Scenario wie das erste. Im letzten Fall lehnt die Telekom den Call wahrscheinlich deshalb ab, weil die Codecs nicht gepasst haben (Du bzw. asterisk bietest ausschließlich G722 an - wenn der TN B das nicht unterstützt ist hier Ende Gelände - die Telekom wird das nicht transkodieren, weil Du die Schnittstelle damit verletzt hast (Du musst mindestens G711 und G722 anbieten)).

An den Codecs im Trunk sollst Du auch nichts verändern! Lass Asterisk / FreePBX so, wie er ursprünglich beim ersten Test war (Trunk: G722 / G711). Das Problem ist nicht Asterisk, sondern Dein Telefon (hatte ich doch geschrieben). Dort sollst Du die Codecs auf G711 / G722 reduzieren.

 

[Tom-VoIP]

Ich habe die Trunks echt nicht angefasst. WIRKLICH

Anbei ein Bria Trace mit G711 / G722

 

[gehtdoch]

Ok, dann lag es daran, dass Asterisk die nicht angebotenen Codecs vom Telefon hinten raus auch nicht angeboten hat (was ja durchaus auch sinnvoll ist). Wie ist es denn, wenn Du genau zum gleichen Ziel wie gerade nur den G711 (bzw. alaw/ulaw wie es in FreePBX konfiguriert wird) aktivierst?

Noch was: Nimm zum Testen mal bitte als TN B die Telekom 08003303000 - ist die Bestellhotline und damit ein Automat der da dran geht. Da ist wenigstens die Codec-Konfiguration eindeutig (G711 only und nichts weiter)


Update:
Normalerweise sollte am Trunk genau das an Codecs rausgehen, was im Trunk konfiguriert ist (gerade nocheinmal nachgestellt) - egal, womit TN A angewackelt kommt. In soweit ist also schon fragwürdig, was da im Trunk eingestellt ist. Allerdings habe ich hier kein asterisk 19 - das mag sich vielleicht anders verhalten wie asterisk 18.

 

[Tom-VoIP]

Das war meine alte Einstellung die fast 1 Jahr lang lief (g722, ulaw, alaw):



Nehme ich g722 raus und rufe die Bestellhotline an. Gibt es jetzt auch ein 603 Decline. Dito G711 only.

<--- Received SIP response (857 bytes) from TLS:217.0.148.5:5061 --->
SIP/2.0 603 Decline
Via: SIP/2.0/TLS 79.213.138.200:5061;received=79.213.138.200;rport=56469;branch=z9hG4bKPjd4065cbf-8d89-4670-9e10-12fe5b0d1c44;alias
From: <sip:[email protected];user=phone>;tag=912743cb-9104-49a9-b671-7c5149e8934c
To: <sip:[email protected];user=phone>;tag=p65550t1680204999m813673c85229s1_908775175-1
Call-ID: 25c2994a-9ba0-42e3-93a0-9a9d6dbc5a53
CSeq: 10586 INVITE
Contact: <sip:mavodi-0-266-b12-2-fffffff0-e92e0000-5f6d302371c17-92b-ffffffffffffffff-@217.0.148.5:5061>
Record-Route: <sip:mavodi-0-266-b12-2-ffffffff-e92e0000-5f6d302371c17-92b-ffffffffffffffff-mavsipodi-0-26c-1db-2-4ff40000-5f6d302310a4b-92b@217.0.148.5:5061;transport=tls;lr;mavsipodi                                                                    -0-26c-1db-2-4ff40000-5f6d302310a4b-92b>
Session-ID: 00000000000000000000000000000000; remote=fd37aea8ee05e5113049241b43831bf1
Content-Length: 0

 

[stoney]

Bitte verwende doch BB-Codes

In Deinem Fall hier also [CODE] INHALT [/CODE]

Macht es für die Hilfswilligen deutlich leichter zu lesen.

 

[gehtdoch]

Von der Reihenfolge her: ulaw am Schluss - in Europa ist alaw angesagt.

Die decline-Meldung ist uninteressant (mit der kann man nichts anfangen) - entscheidend ist, was rausging im Invite!

Stell im Telefon G711 ein und mach dann den Test gegen die Bestellhotline. Und dann darauf achten, welche Codecs rausgehen zur Telekom. Die stehen im INVITE im SDP

v=0
o=- 303341045 303341045 IN IP4 79.198.a.x
s=Asterisk
c=IN IP4 79.198.a.x
t=0 0
m=audio 10122 RTP/SAVP 9 8 0 101
a=3ge2ae:requested
a=crypto:1 AES_256_CM_HMAC_SHA1_80 inline:gbw38pt/1b32TaeMPWUxdLWlowRQTG43VkDeF3i2/9XTWCBPQYoZaZw2qYO9Lg==
a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:c479R/olPM7bkJG4sETEuKCQLAfpPDwsG8iEM5my
a=rtpmap:9 G722/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv

 

[Tom-VoIP]

Hmm steht immer G722 drin. Egal was im Trunk oder Bria einstelle. << IRRTUM Reboot hilft...

Aber auch a=rtpmap:8 PCMA/8000 hilft nicht :-(

<--- Received SIP response (1376 bytes) from TLS:217.0.148.5:5061 --->
SIP/2.0 180 Ringing
Via: SIP/2.0/TLS 79.213.a.b:5061;received=79.213.a.b;rport=44704;branch=z9hG4bKPj0eb92bef-0eee-4e3e-b30c-365dd6e35dce;alias
From: <sip:[email protected];user=phone>;tag=a2e21f34-adc2-431f-ab7a-853e7df92fa3
To: <sip:[email protected];user=phone>;tag=p65550t1680206793m373737c84861s1_2702336990-1
Call-ID: 8df18503-11b0-4e1c-adb8-8a9ed1540b0a
CSeq: 28601 INVITE
Require: 100rel
RSeq: 2
Contact: <sip:mavodi-0-266-bb0-6-fffffff0-ed6e0000-5f6d555ee4769-979-ffffffffffffffff-@217.0.148.5:5061>
Allow: REGISTER,REFER,NOTIFY,SUBSCRIBE,UPDATE,PRACK,INVITE,ACK,OPTIONS,CANCEL,BYE
Record-Route: <sip:mavodi-0-266-bb0-6-ffffffff-ed6e0000-5f6d555ee4769-979-ffffffffffffffff-mavsipodi-0-26c-1a4-6-6b210000-5f6d555ea4f1b-979@217.0.148.5:5061;transport=tls;lr;mavsipodi-0-26c-1a4-6-6b210000-5f6d555ea4f1b-979>
P-Early-Media: sendonly
Session-ID: 00000000000000000000000000000000; remote=f4018a4b4b92dbbb2c90a8bccf8e46ed
Content-Type: application/sdp
Content-Length: 351

v=0
o=ccs-0-615-6 0612629198705 270356675 IN IP4 217.0.162.45
s=media server session
c=IN IP4 217.0.162.45
t=0 0
m=audio 42890 RTP/SAVP 8 101
a=ptime:20
a=maxptime:40
a=sendrecv
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:5HuiZzMdISDKm+s6oTAPIEd0unGHLp8hcK7vA94c
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15,32,36

 

[gehtdoch]

Und was war jetzt? Die Telekom hat im RINGING den Codec mitgegeben (early media) - damit nehme ich an, dass Dein Telefon nun wieder nicht wollte und aufgelegt hat. Korrekt?

zur weiteren Vorgehensweise:
In FreePBX setzt du bitte sowohl die Trunks als auch die Nebenstellen (oder auch Endpoint oder Extension) codecseitig auf G722 / alaw / ulaw. Dann werden diese Einstellungen nicht mehr angerührt. Im Telefon selbst stell dann nur mal G711 ein (bzw. alaw / ulaw falls möglich). Das muss dann mit der Bestellhotline auf jeden Fall funktionieren. Wenn das tatsächlich nicht funktionieren sollte, will ich nochmal den kompletten Trace mit beiden Legs sehen (also sowohl zwischen Telefon und asterisk als auch zwischen asterisk und Telekom).

Zur Einstellung der Codecs in den Nebenstellen:
Zulässige Codecs: !all,g722,alaw,ulaw

Zur Einstellung der Codecs in den Trunks:
Im Tab Codecs: g722, alaw, ulaw in genau der Reihenfolge anhaken.

Die Idee, mit einem anderen Telefon zu testen, ist gut. Mach das. Stelle auch da die Codecs wie oben beschrieben ein.

Außerdem noch bei Trunk und endpoint prüfen:

rasterisk
pjsip show endpoint [endpointname bzw. trunk]

Was steht bei incoming_call_offer_pref bzw. outgoing_call_offer_pref? Das sollte jeweils so aussehen:

incoming_call_offer_pref           : local
outgoing_call_offer_pref           : remote_merge

Das sind die default Einstellungen. Da erwarte ich, dass die sich genauso verhalten, wie bei mir auch.

Sicherstellen, dass asterisk transkodieren kann (g722 und alaw / ulaw müssen in beiden Achsen vorkommen und es muss eine Zeit drinstehen - kein -):

core show translation  
         Translation times between formats (in microseconds) for one second of data
          Source Format (Rows) Destination Format (Columns)

            amr amrwb   evs  ulaw  alaw   gsm  g726 g726aal2 adpcm slin8 slin12 slin16 slin24 slin32 slin44 slin48 slin96 slin192 lpc10  ilbc  g722 siren7 siren14 testlaw  opus silk8 silk12 silk16 silk24
      amr     - 23000 15000 15000 15000 15000 15000    15000 15000  9000  17000  17000  17000  17000  17000  17000  17000   17000 15000 15000 17250  23000   23000   15000 23000 15000  23000  23000  23000
    amrwb 23500     - 14999 23500 23500 23500 23500    23500 23500 17500  17500   9000  17000  17000  17000  17000  17000   17000 23500 23500 15000  15000   23000   23500 23000 23500  23500  15000  23000
      evs 15000 14999     - 15000 15000 15000 15000    15000 15000  9000  17000   8999  16999   8999  16999   8999  16999   16999 15000 15000 14999  14999   14999   15000 14999 15000  23000  14999  22999
     ulaw 15000 23000 15000     -  9150 15000 15000    15000 15000  9000  17000  17000  17000  17000  17000  17000  17000   17000 15000 15000 17250  23000   23000   15000 23000 15000  23000  23000  23000
     alaw 15000 23000 15000  9150     - 15000 15000    15000 15000  9000  17000  17000  17000  17000  17000  17000  17000   17000 15000 15000 17250  23000   23000   15000 23000 15000  23000  23000  23000
      gsm 15000 23000 15000 15000 15000     - 15000    15000 15000  9000  17000  17000  17000  17000  17000  17000  17000   17000 15000 15000 17250  23000   23000   15000 23000 15000  23000  23000  23000
     g726 15000 23000 15000 15000 15000 15000     -    15000 15000  9000  17000  17000  17000  17000  17000  17000  17000   17000 15000 15000 17250  23000   23000   15000 23000 15000  23000  23000  23000
 g726aal2 15000 23000 15000 15000 15000 15000 15000        - 15000  9000  17000  17000  17000  17000  17000  17000  17000   17000 15000 15000 17250  23000   23000   15000 23000 15000  23000  23000  23000
    adpcm 15000 23000 15000 15000 15000 15000 15000    15000     -  9000  17000  17000  17000  17000  17000  17000  17000   17000 15000 15000 17250  23000   23000   15000 23000 15000  23000  23000  23000
    slin8  6000 14000  6000  6000  6000  6000  6000     6000  6000     -   8000   8000   8000   8000   8000   8000   8000    8000  6000  6000  8250  14000   14000    6000 14000  6000  14000  14000  14000
   slin12 14500 14000 13999 14500 14500 14500 14500    14500 14500  8500      -   8000   8000   8000   8000   8000   8000    8000 14500 14500 14000  14000   14000   14500 14000 14500   6000  14000  14000
   slin16 14500  6000  5999 14500 14500 14500 14500    14500 14500  8500   8500      -   8000   8000   8000   8000   8000    8000 14500 14500  6000   6000   14000   14500 14000 14500  14500   6000  14000
   slin24 14500 14500 13999 14500 14500 14500 14500    14500 14500  8500   8500   8500      -   8000   8000   8000   8000    8000 14500 14500 14500  14500   14000   14500 14000 14500  14500  14500   6000
   slin32 14500 14500  5999 14500 14500 14500 14500    14500 14500  8500   8500   8500   8500      -   8000   8000   8000    8000 14500 14500 14500  14500    6000   14500 14000 14500  14500  14500  14500
   slin44 14500 14500 13999 14500 14500 14500 14500    14500 14500  8500   8500   8500   8500   8500      -   8000   8000    8000 14500 14500 14500  14500   14500   14500 14000 14500  14500  14500  14500
   slin48 14500 14500  5999 14500 14500 14500 14500    14500 14500  8500   8500   8500   8500   8500   8500      -   8000    8000 14500 14500 14500  14500   14500   14500  6000 14500  14500  14500  14500
   slin96 14500 14500 14499 14500 14500 14500 14500    14500 14500  8500   8500   8500   8500   8500   8500   8500      -    8000 14500 14500 14500  14500   14500   14500 14500 14500  14500  14500  14500
  slin192 14500 14500 14499 14500 14500 14500 14500    14500 14500  8500   8500   8500   8500   8500   8500   8500   8500       - 14500 14500 14500  14500   14500   14500 14500 14500  14500  14500  14500
    lpc10 15000 23000 15000 15000 15000 15000 15000    15000 15000  9000  17000  17000  17000  17000  17000  17000  17000   17000     - 15000 17250  23000   23000   15000 23000 15000  23000  23000  23000
     ilbc 15000 23000 15000 15000 15000 15000 15000    15000 15000  9000  17000  17000  17000  17000  17000  17000  17000   17000 15000     - 17250  23000   23000   15000 23000 15000  23000  23000  23000
     g722 15600 15000 14999 15600 15600 15600 15600    15600 15600  9600  17500   9000  17000  17000  17000  17000  17000   17000 15600 15600     -  15000   23000   15600 23000 15600  23500  15000  23000
   siren7 23500 15000 14999 23500 23500 23500 23500    23500 23500 17500  17500   9000  17000  17000  17000  17000  17000   17000 23500 23500 15000      -   23000   23500 23000 23500  23500  15000  23000
  siren14 23500 23500 14999 23500 23500 23500 23500    23500 23500 17500  17500  17500  17500   9000  17000  17000  17000   17000 23500 23500 23500  23500       -   23500 23000 23500  23500  23500  23500
  testlaw 15000 23000 15000 15000 15000 15000 15000    15000 15000  9000  17000  17000  17000  17000  17000  17000  17000   17000 15000 15000 17250  23000   23000       - 23000 15000  23000  23000  23000
     opus 23500 23500 14999 23500 23500 23500 23500    23500 23500 17500  17500  17500  17500  17500  17500   9000  17000   17000 23500 23500 23500  23500   23500   23500     - 23500  23500  23500  23500
    silk8 15000 23000 15000 15000 15000 15000 15000    15000 15000  9000  17000  17000  17000  17000  17000  17000  17000   17000 15000 15000 17250  23000   23000   15000 23000     -  23000  23000  23000
   silk12 23500 23000 22999 23500 23500 23500 23500    23500 23500 17500   9000  17000  17000  17000  17000  17000  17000   17000 23500 23500 23000  23000   23000   23500 23000 23500      -  23000  23000
   silk16 23500 15000 14999 23500 23500 23500 23500    23500 23500 17500  17500   9000  17000  17000  17000  17000  17000   17000 23500 23500 15000  15000   23000   23500 23000 23500  23500      -  23000
   silk24 23500 23500 22999 23500 23500 23500 23500    23500 23500 17500  17500  17500   9000  17000  17000  17000  17000   17000 23500 23500 23500  23500   23000   23500 23000 23500  23500  23500      -

 

[Tom-VoIP]

Hallo gehtdoch,

„Und was war jetzt? Die Telekom hat im RINGING den Codec mitgegeben (early media) - damit nehme ich an, dass Dein Telefon nun wieder nicht wollte und aufgelegt hat. Korrekt?“
Ja genauso ich war gestern Abend schon zu müde um ein Invite Paket vom RingRing zu unterscheiden (blöder Autoscroll im Putty)

Ich habe noch viel mit den Codec Kombinationen versucht. Leider erfolglos.

Heute habe ich den verbotenen Trunk (Post #6) angefasst und Einstellungen verändert und HEUREKA Erfolg !

Und ENDLICH nach so vielen Stunden fummeln. FreePBX scheint hin und wieder was mit Esoterik zu tun zu haben.

Meine Trunk Änderungen für die Nachwelt:

General:​

- Outbound CallerID mit +493012345678 anstatt 03012345678​

​

Advanced:​

- Outbound Proxy: Leer anstatt sip:tel.t-online.de:0​

- Contact User: +493012345678​

- AOR Contact: sip:[email protected]​

Vorher schon geändert siehe Post-1:​

- Media Encryption: SRTP via in-SDP (recommended)​

Jetzt kann ich endlich wieder telefonieren ! Yeah

Für die technik detail verliebten extrem User: Ein funktionierender Trace eines abgehendes Gesprächs im Anhang.

VIELEN VIELEN DANK (mal wieder) > gehtdoch < für deine Zeit, die Mühe, Geduld, Leidenschaft, Energie, Knowhow, Kopfzerbrechen... !!! Ich hoffe ich kann mich irgendwann mal erkenntlich zeigen

 

[gehtdoch]

Glückwunsch!

Deine Änderungen sind alle korrekt (siehe hier) - hatten aber nur an einer Stelle Auswirkungen auf das SIP-Paket (diese hatte ich leider übersehen - das Lesen von nicht strukturierten Logfiles ist sehr mühsam und macht (mir) wenig Spaß). Aber die Telekom hat das nicht gestört interessanterweise.

Was mir aber gerade aufgefallen ist (und das scheint mir das Hauptproblem zu sein): Du scheinst einen Mix zwischen pjsip und chan_sip am Laufen zu haben. Das interne Telefon scheint an chan_sip zu hängen (zumindest deutet dieser Logeintrag darauf hin:

[2023-03-31 11:39:36] WARNING[21894][C-0000001e]: chan_sip.c:8155 sip_indicate: Don't know how to indicate condition 36

)

Dass das zu seltsamen Problemen führen kann, da brauchst Du Dich nicht zu wundern - das testet keiner und ist auch nicht recommended. Ich würde dringend raten, chan_sip komplett zu deaktivieren und alles über pjsip zu machen.

Was mir auch noch aufgefallen ist:

Match: 217.0.148.5/32
Match: 217.0.29.32/32
Match: 217.0.28.32/32
Match: 217.0.29.36/32
Match: 217.0.28.34/32

Das ist bei der Telekom eine ganz schlechte Idee, weil deren Arsenal an SIP-Servern unermesslich ist (was ja gut ist aus Gründen der Verfügbarkeit - es gibt immer einen, der funktioniert). So ist der nächste Ausfall bei Dir schon sicher - es ist nur eine Frage der Zeit!

Operiere da besser mit "Send line in Registration" (Trunk -> pjsip -> erweitert). Damit kann Asterisk die eingehenden Calls eindeutig zuordnen und Du bist nicht mehr von irgendwelchen IPs abhängig. Bei Match kannst Du dann 127.0.0.1 reinpinseln (das sollte nie zutreffen).

 

[Tom-VoIP]

Ja aktuell ist chan_sip noch aktiv. Denn ein paar FritzFons brauchen noch die FritzBox als Dect-Gateway. Da es nicht so einfach war (ist?) die FB via pjsip anzubinden ist das historisch so gewachsen.

 

[Normalcy]

Hi ihr beiden!
Wir haben hier auch MagentaZuhause L und bei uns ging das Telefon seit heute morgen nichtmehr. (Konnte sich nichtmehr registrieren - weder angerufen werden noch anrufen hat funktioniert)

Als ich bei "Outbound Proxy" dann

sip:tel.t-online.de

eingetragen habe ging zumindest das angerufen werden wieder.
Da das Problem ja gelöst zu sein scheint: Wäre es möglich eine Auflistung von dem zu bekommen was man im Trunk alles konfigurieren muss, dass es funktioniert?
Meine Trunk Einstellungen (angerufen werden geht, anrufen geht nicht) habe ich mal als Screenshots angehängt.
Ich hab auch bis heute nicht hinbekommen die Verschlüsselung zu aktivieren. Wenn ich die Änderungen aus Post #14 oben anwende registriert er sich nichtmehr also vermute ich, dass irgendwo noch was anderes fehlt.
Die Änderungen bei den Codecs habe ich so angewendet wie vorgeschlagen.

Schonmal Danke im Voraus!

####

-- Zusammenführung Doppelpost gemäß Boardregeln https://www.ip-phone-forum.de/threads/ip-phone-forum-regeln.297224/ by stoney

Okay, ich hab es jetzt ebenfalls zum laufen bekommen. Für die Nachwelt hier eine hoffentlich vollständige Liste von Dingen die man einstellen muss:

- Asterisk SIP Einstellungen
    - General
        - NAT Settings
            - Local Networks: <lokales Netzwerk. Zum Beispiel 192.168.42.0/24>
            - Externe Adresse: <externe IP oder dns>
        - RTP Settings
            - RTP Port Ranges: 9000 - 10999 (Egal welche Range. Hauptsache die Range ist in der Firewall geforwarded)
        - Media Transport Settings
            - STUN Server: stun.t-online.de
        - Audio Codecs:
            - g722
            - alaw
            - ulaw
    - chan_pjsip
        - SSL-Method: tlsv1_2
        - Verify Client: no
        - transports
            - udp: on
            - tcp: on
            - tls: on

- trunks
    - trunkN
        - General
            - Name: ...
            - Outbound CallerID: <+499...>
        - pjsip Einstellungen
            - General
                - Username: +499...
                - Auth username: [email protected]
                - Kennwort: ...
                - SIP-Server: tel.t-online.de
                - Transport: 0.0.0.0-tls
            - Erweitert
                - Contact User: +499...
                - From Domain: tel.t-online.de
                - From User: +499...
                - AOR Contact: sip:[email protected]
                - Media Encryption: SRTP via in-DSP

Das Geheimnis beim TLS bei mir war, dass mein Asterisk standardmäßig TLSv1 versucht, das mag die Telekom anscheinend nicht.
Der Vollständigkeit halber noch ein Tip zum debuggen:

Auf der Konsole per SSH:
    > rasterisk
        > pjsip set logger on
    > asterisk-version-select
        Ändern der momentan aktiven asterisk version

 

[gehtdoch]

Wäre es möglich eine Auflistung von dem zu bekommen was man im Trunk alles konfigurieren muss, dass es funktioniert?

Siehe hier. (Stand aber schon in meinem Post 15).

Was Verschlüsselung angeht: dafür benötigst Du nach wie vor mediasec (bisher ist nur bei einigen wenigen SIP-Servern kein Mediasec nötig).

 

[Tom-VoIP]

Hi Normalcy,

coole Idee für die Dokumentation Meine aktuell funktionierenden Einstellungen unterscheiden sich ein bisschen von deinen.
Ich habe jetzt nur deine dokumentierten Felder geprüft. Da man im "Code" Stil keine Farben hat, hier als Screenshot:



Ich denke für eine Voll-Doku in deinem Still für eine "FreePBX Telekom MagentaZuhause 2023 Config" müsste man einmal eine frische FreePBX VM aufsetzen und genau aufschreiben welche Einstellungen sich von den Defaults unterscheiden.