Telekom All IP Privat endlich erfolgreiche Registierung SSL/TLS möglich

Sidebar Sidebar
Upgrade 3CX to v18 and get it hosted free!
Ich habe hier auch mal mit einem SIP-Client direkt am Trunk getestet - da ging es auch - aber das war auch ein anderer Server. Witzigerweise sind da gleich 2 ReInvites gekommen! Wie Du beschrieben hast, hat der Client auch beim 200 OK nach dem ReInivte auch nochmal alle Codecs mitgeschickt und nicht nur das Ergebnis aus dem ersten Invite, wie Asterisk (was dem entspricht, was die Telekom angeboten hat - abgesehen von fmtp:101 0-16 vs. fmtp:101 0-15).

Initial INVITE:
Code: 
o=- 1786997583 1786997583 IN IP4 [meine IP]
200 OK nach ReInvite
Code: 
o=- 1786997583 1786997583 IN IP4 [meine IP]
-> die sind identisch obwohl SDP-Inhalt jeweils unterschiedlich ist. Bei dem anderen Softclient (wo es funktioniert hat), waren die SDPs immer gleich - aber <sess-version> wurde jeweils um eins hochgezählt.

Interessant ist auch, dass sowohl die <sess-id> als auch die <sess-version> identisch sind bei Asterisk - während sie bei dem anderen SIP-Client völlig unterschiedlich sind. Ist aber bei Asterisk immer so (habe ich gerade mal nachgesehen - was nicht heißt, dass das gut sein muss).

Vielleicht wäre es doch besser, im late offer-Fall doch nochmal den kompletten SDP-Satz zu schicken - nicht dass da irgendwer unterwegs ein Problem mit hat und dann silently nicht mehr mitspielen möchte. Außerdem die <sess-version> hoch zählen. Könnte es daran hängen?

So sehen die beiden ACKs der Telekom in Sachen SDP aus, die mit dem anderen SIP-Client erzielt werden:

ACK nach erstem ReInivte
Code: 
    Message Body
        Session Description Protocol
            Session Description Protocol Version (v): 0
            Owner/Creator, Session Id (o): - 542931999 1383793760 IN IP4 217.0.28.160
            Session Name (s): media server session
            Bandwidth Information (b): AS:80
            Time Description, active time (t): 0 0
            Media Description, name and address (m): audio 19956 RTP/AVP 8 101
            Connection Information (c): IN IP4 217.0.6.180
            Bandwidth Information (b): AS:80
            Bandwidth Information (b): RR:0
            Bandwidth Information (b): RS:0
            Media Attribute (a): rtpmap:8 PCMA/8000
            Media Attribute (a): ptime:20
            Media Attribute (a): rtpmap:101 telephone-event/8000
            Media Attribute (a): fmtp:101 0-15,32,36
            Media Attribute (a): maxptime:50
            Media Attribute (a): sendrecv

ACK nach zweitem ReInivte:
Code: 
    Message Body
        Session Description Protocol
            Session Description Protocol Version (v): 0
            Owner/Creator, Session Id (o): - 542931999 1383793761 IN IP4 217.0.28.160
            Session Name (s): phone-call
            Connection Information (c): IN IP4 217.0.6.180
            Time Description, active time (t): 0 0
            Media Description, name and address (m): audio 19956 RTP/AVP 8 101
            Media Attribute (a): ptime:20
            Media Attribute (a): sendrecv
            Media Attribute (a): rtpmap:8 pcma/8000
            Media Attribute (a): rtpmap:101 telephone-event/8000
            Media Attribute (a): fmtp:101 0-15
 
gehtdoch schrieb:
Initial INVITE:
Code: 
o=- 1786997583 1786997583 IN IP4 [meine IP]
200 OK nach ReInvite
Code: 
o=- 1786997583 1786997583 IN IP4 [meine IP]
-> die sind identisch obwohl SDP-Inhalt jeweils unterschiedlich ist.
Zum Vergrößern anklicken....
Das ist die Ursache für den fehlerhaften Call, denn das ist eine harte Verletzung des SDP Offer/Answer Prozesses:

RFC6337, 5.2.5. Subsequent Offers and Answers
o In the "o=" line, only the version number may change, and if it
changes, it must increment by one from the one previously sent as
an offer or answer. (Section 8 of [RFC3264].) If it doesn't
change, then the entire SDP body must be identical to what was
previously sent as an offer or answer. Changing the "o=" line,
except version number value, during the session is an error case.
The behavior when receiving such a non-compliant offer/answer SDP
body is implementation dependent. If a UA needs to negotiate a
'new' SDP session, it should use the INVITE/Replaces method.
Zum Vergrößern anklicken....
 
Ok - dann werde ich mal in diese Richtung schauen, was sich machen lässt! Das klingt zumindest sehr verdächtig! Das muss auf jeden Fall repariert werden - auch wenn es evtl. noch nicht dieses konkrete Problem lösen sollte. Mal sehen, was die Asterisk-Kollegen dazu sagen.
 
Ich habe gerade einmal mit MicroSIP 3.19.14 getestet, welches ebenfalls PJSIP und pjmedia nutzt.
Hiermit funktioniert der Anruf.:

Initiales INVITE:
Code: 
v=0
o=- 3769797022 3769797022 IN IP4 192.168.178.24
s=pjmedia
b=AS:84
t=0 0
a=X-nat:0
m=audio 4000 RTP/AVP 8 0 121 120 3 101
c=IN IP4 192.168.178.24
b=TIAS:64000
a=rtcp:4001 IN IP4 192.168.178.24
a=sendrecv
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:121 AMR-WB/16000
a=fmtp:121 octet-align=1
a=rtpmap:120 AMR/8000
a=fmtp:120 octet-align=1
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ssrc:1066955392 cname:4709586c1d014ff6

200 OK auf das Re-Invite:
Code: 
v=0
o=- 3769797022 3769797023 IN IP4 192.168.178.24
s=pjmedia
b=AS:84
t=0 0
a=X-nat:0
m=audio 4000 RTP/AVP 8 0 121 120 3 101
c=IN IP4 192.168.178.24
b=TIAS:64000
a=rtcp:4001 IN IP4 192.168.178.24
a=sendrecv
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:121 AMR-WB/16000
a=fmtp:121 octet-align=1
a=rtpmap:120 AMR/8000
a=fmtp:120 octet-align=1
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ssrc:1066955392 cname:4709586c1d014ff6

Hier wird die Session Version hochgezählt, obwohl sich ansonsten am SDP nichts geändert.
Das ist zwar nicht 100% konform, aber auch kein direkter Fehler.
 
Kurze Frage, ist das ein Bug von asterisk/pjsip oder liegt das an dem mediasec Patch? Oder ganz woanders? :-D Für mich ist das alles noch Neuland^^
 
Meester Proper schrieb:
Ich habe gerade einmal mit MicroSIP 3.19.14 getestet, welches ebenfalls PJSIP und pjmedia nutzt.
Zum Vergrößern anklicken....

Dein Tip war Gold Wert! Asterisk generiert den SDP ja selbst. In wie weit sie damit auch für das Verwalten der SDP-Version zuständig sind oder nicht, habe ich jetzt nicht weiter erforscht. Der (temporäre) Patch hier behebt das Problem auf jeden Fall. Funktioniert auch problemlos mit dem Mediasec-Patch (auch "normale" Calls funktionieren weiterhin). Die auf die beiden ReInivtes folgenden 200 OK haben nun auch jeweils den gleichen Cryptokey (wie beim initialen INVITE).

Man muss eben ein paar Sekunden warten bei 116116 bis die ganzen Weiterleitungen durch sind - aber final funktionierts.
 
qupfer2 schrieb:
Kurze Frage, ist das ein Bug von asterisk/pjsip oder liegt das an dem mediasec Patch? Oder ganz woanders? :-D Für mich ist das alles noch Neuland^^
Zum Vergrößern anklicken....

Das hat mit dem Mediasec-Patch absolut nichts zu tun - funktioniert auch ohne nicht, weil das SDP-Handling grundsätzlich nicht passt. Mit dem oben genannten Patch ist das bereinigt. Der Patch passt zu Asterisk Version 16.3/4 (ich habe es mit 4 getestet - geht aber mit ziemlicher Sicherheit genauso mit 16.3). Mediasec tut damit auch mit 16.4 (ich habe es in Summe getestet, weil ich nur noch verschlüsselt unterwegs bin).
 
Sendest du die Security-Verify-Header bei dem 200 OK auf das Re-Invite mit oder funktioniert es auch ohne?

Könntest du die Re-Invites inklusive Antworten mit SRTP&TLS hier posten?
 
Ich habe jetzt mal den kompletten Call incl. initialem INVITE reingehängt. Ist vielleicht für andere auch noch interessant. Der Call lief mit aktivem 100rel (PRACK). Ich habe größere Absätze drin für die einzelnen Abschnitte.

Hast Du noch mehr interessante Nummern, gegen die man testen könnte, die in irgendeiner Weise nicht 0815-Standard sind, im Sinne von: kommt nicht so oft vor?

Code: 
<--- Transmitting SIP request (1192 bytes) to TLS:217.0.20.195:5061 --->
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/TLS 46.91.12.57:5061;rport;branch=z9hG4bKPjf4e5386d-f27e-47e2-a251-df10c9ada444;alias
From: <sip:[email protected]>;tag=ed2437ec-1349-425f-8061-a0a272ffa67b
To: <sip:[email protected]>
Contact: <sip:[email protected]:5061;transport=TLS>
Call-ID: 42ab1001-7254-4cf3-97c4-5f21af620171
CSeq: 3111 INVITE
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
Supported: 100rel, timer, replaces, norefersub
Session-Expires: 1800
Min-SE: 90
Security-Verify: msrp-tls;mediasec
Security-Verify: sdes-srtp;mediasec
Security-Verify: dtls-srtp;mediasec
Max-Forwards: 70
User-Agent: FPBX-14.0.11(16.4.0)
Content-Type: application/sdp
Content-Length:   390

v=0
o=- 1405868408 1405868409 IN IP4 46.91.12.57
s=Asterisk
c=IN IP4 46.91.12.57
t=0 0
m=audio 10034 RTP/SAVP 9 8 0 101
a=3ge2ae:requested
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:5UrvnVqB7sXxPfCSDxctmyepR4nt080VRrh/EpuS
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

<--- Received SIP response (562 bytes) from TLS:217.0.20.195:5061 --->
SIP/2.0 407 Proxy Authentication Required 02035034C
Via: SIP/2.0/TLS 46.91.12.57:5061;received=46.91.12.57;rport=37373;branch=z9hG4bKPjf4e5386d-f27e-47e2-a251-df10c9ada444;alias
To: <sip:[email protected]>;tag=h7g4Esbg_70516d1c02c806c3f0d877887e378252
From: <sip:[email protected]>;tag=ed2437ec-1349-425f-8061-a0a272ffa67b
Call-ID: 42ab1001-7254-4cf3-97c4-5f21af620171
CSeq: 3111 INVITE
Content-Length: 0
Proxy-Authenticate: ...


<--- Transmitting SIP request (442 bytes) to TLS:217.0.20.195:5061 --->
ACK sip:[email protected] SIP/2.0
Via: SIP/2.0/TLS 46.91.12.57:5061;rport;branch=z9hG4bKPjf4e5386d-f27e-47e2-a251-df10c9ada444;alias
From: <sip:[email protected]>;tag=ed2437ec-1349-425f-8061-a0a272ffa67b
To: <sip:[email protected]>;tag=h7g4Esbg_70516d1c02c806c3f0d877887e378252
Call-ID: 42ab1001-7254-4cf3-97c4-5f21af620171
CSeq: 3111 ACK
Max-Forwards: 70
User-Agent: FPBX-14.0.11(16.4.0)
Content-Length:  0






<--- Transmitting SIP request (1477 bytes) to TLS:217.0.20.195:5061 --->
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/TLS 46.91.12.57:5061;rport;branch=z9hG4bKPjfb6c4442-2f06-4004-b2c0-beafe5aa4dd4;alias
From: <sip:[email protected]>;tag=ed2437ec-1349-425f-8061-a0a272ffa67b
To: <sip:[email protected]>
Contact: <sip:[email protected]:5061;transport=TLS>
Call-ID: 42ab1001-7254-4cf3-97c4-5f21af620171
CSeq: 3112 INVITE
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
Supported: 100rel, timer, replaces, norefersub
Session-Expires: 1800
Min-SE: 90
Security-Verify: msrp-tls;mediasec
Security-Verify: sdes-srtp;mediasec
Security-Verify: dtls-srtp;mediasec
Max-Forwards: 70
User-Agent: FPBX-14.0.11(16.4.0)
Proxy-Authorization: ...
Content-Type: application/sdp
Content-Length:   390

v=0
o=- 1405868408 1405868410 IN IP4 46.91.12.57
s=Asterisk
c=IN IP4 46.91.12.57
t=0 0
m=audio 10034 RTP/SAVP 9 8 0 101
a=3ge2ae:requested
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:5UrvnVqB7sXxPfCSDxctmyepR4nt080VRrh/EpuS
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

<--- Received SIP response (354 bytes) from TLS:217.0.20.195:5061 --->
SIP/2.0 100 Trying
Via: SIP/2.0/TLS 46.91.12.57:5061;received=46.91.12.57;rport=37373;branch=z9hG4bKPjfb6c4442-2f06-4004-b2c0-beafe5aa4dd4;alias
To: <sip:[email protected]>
From: <sip:[email protected]>;tag=ed2437ec-1349-425f-8061-a0a272ffa67b
Call-ID: 42ab1001-7254-4cf3-97c4-5f21af620171
CSeq: 3112 INVITE
Content-Length: 0


<--- Received SIP response (1049 bytes) from TLS:217.0.20.195:5061 --->
SIP/2.0 183 Session Progress
Via: SIP/2.0/TLS 46.91.12.57:5061;received=46.91.12.57;rport=37373;branch=z9hG4bKPjfb6c4442-2f06-4004-b2c0-beafe5aa4dd4;alias
To: <sip:[email protected]>;tag=h7g4Esbg_p65540t1560870358m922456c170430787s1_1934145808-1437309507
From: <sip:[email protected]>;tag=ed2437ec-1349-425f-8061-a0a272ffa67b
Call-ID: 42ab1001-7254-4cf3-97c4-5f21af620171
CSeq: 3112 INVITE
Contact: <sip:[email protected]:5061;transport=tls>
Record-Route: <sip:217.0.20.195:5061;transport=tls;lr>
P-Early-Media: sendonly
Require: 100rel
RSeq: 2
Supported: timer
Content-Type: application/sdp
Content-Length: 308
Allow: REGISTER, REFER, NOTIFY, SUBSCRIBE, PRACK, UPDATE, INVITE, ACK, OPTIONS, CANCEL, BYE

v=0
o=- 36003913 1935390660 IN IP4 217.0.20.195
s=Basic Session
c=IN IP4 217.0.135.7
t=0 0
m=audio 47226 RTP/SAVP 8 101
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=rtpmap:8 PCMA/8000
a=ptime:20
a=sendrecv
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:CrufFLwEoEHNsF+avR5icqWksbxP7vOEfjEF/iYD


<--- Transmitting SIP request (557 bytes) to TLS:217.0.20.195:5061 --->
PRACK sip:[email protected]:5061;transport=tls SIP/2.0
Via: SIP/2.0/TLS 46.91.12.57:5061;rport;branch=z9hG4bKPja2d033a9-c557-4f0e-8aa6-64a5274a5c13;alias
From: <sip:[email protected]>;tag=ed2437ec-1349-425f-8061-a0a272ffa67b
To: <sip:[email protected]>;tag=h7g4Esbg_p65540t1560870358m922456c170430787s1_1934145808-1437309507
Call-ID: 42ab1001-7254-4cf3-97c4-5f21af620171
CSeq: 3113 PRACK
Route: <sip:217.0.20.195:5061;transport=tls;lr>
RAck: 2 3112 INVITE
Max-Forwards: 70
User-Agent: FPBX-14.0.11(16.4.0)
Content-Length:  0


<--- Received SIP response (539 bytes) from TLS:217.0.20.195:5061 --->
SIP/2.0 200 OK
Via: SIP/2.0/TLS 46.91.12.57:5061;received=46.91.12.57;rport=37373;branch=z9hG4bKPja2d033a9-c557-4f0e-8aa6-64a5274a5c13;alias
To: <sip:[email protected]>;tag=h7g4Esbg_p65540t1560870358m922456c170430787s1_1934145808-1437309507
From: <sip:[email protected]>;tag=ed2437ec-1349-425f-8061-a0a272ffa67b
Call-ID: 42ab1001-7254-4cf3-97c4-5f21af620171
CSeq: 3113 PRACK
P-Early-Media: sendonly
Content-Length: 0
Allow: REGISTER, REFER, NOTIFY, SUBSCRIBE, PRACK, UPDATE, INVITE, ACK, OPTIONS, CANCEL, BYE


<--- Received SIP response (1481 bytes) from TLS:217.0.20.195:5061 --->
SIP/2.0 200 OK
Via: SIP/2.0/TLS 46.91.12.57:5061;received=46.91.12.57;rport=37373;branch=z9hG4bKPjfb6c4442-2f06-4004-b2c0-beafe5aa4dd4;alias
To: <sip:[email protected]>;tag=h7g4Esbg_p65540t1560870358m922456c170430787s1_1934145808-1437309507
From: <sip:[email protected]>;tag=ed2437ec-1349-425f-8061-a0a272ffa67b
Call-ID: 42ab1001-7254-4cf3-97c4-5f21af620171
CSeq: 3112 INVITE
Contact: <sip:[email protected]:5061;transport=tls>;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"
Record-Route: <sip:217.0.20.195:5061;transport=tls;lr>
Session-Expires: 1800;refresher=uas
Supported: timer
Content-Type: application/sdp
Content-Length: 308
Session-ID: c22dfc34129ee033b7fd5927c4ceb9f3
Authentication-Info: ...
Allow: REGISTER, REFER, NOTIFY, SUBSCRIBE, PRACK, UPDATE, INVITE, ACK, OPTIONS, CANCEL, BYE
Accept: application/sdp
Accept: application/vnd.etsi.sci+xml
Accept: application/vnd.etsi.pstn+xml
Accept: multipart/mixed
Accept: application/vnd.telekom.service_indication+xml
Accept: application/vnd.etsi.cug+xml

v=0
o=- 36003913 1935390660 IN IP4 217.0.20.195
s=Basic Session
c=IN IP4 217.0.135.7
t=0 0
m=audio 47226 RTP/SAVP 8 101
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=rtpmap:8 PCMA/8000
a=ptime:20
a=sendrecv
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:CrufFLwEoEHNsF+avR5icqWksbxP7vOEfjEF/iYD


<--- Transmitting SIP request (532 bytes) to TLS:217.0.20.195:5061 --->
ACK sip:[email protected]:5061;transport=tls SIP/2.0
Via: SIP/2.0/TLS 46.91.12.57:5061;rport;branch=z9hG4bKPj50e69db6-1ce1-4d7c-be8f-ee091d9867c2;alias
From: <sip:[email protected]>;tag=ed2437ec-1349-425f-8061-a0a272ffa67b
To: <sip:[email protected]>;tag=h7g4Esbg_p65540t1560870358m922456c170430787s1_1934145808-1437309507
Call-ID: 42ab1001-7254-4cf3-97c4-5f21af620171
CSeq: 3112 ACK
Route: <sip:217.0.20.195:5061;transport=tls;lr>
Max-Forwards: 70
User-Agent: FPBX-14.0.11(16.4.0)
Content-Length:  0






<--- Received SIP request (721 bytes) from TLS:217.0.20.195:5061 --->
INVITE sip:[email protected]:5061;transport=tcp SIP/2.0
Max-Forwards: 64
Via: SIP/2.0/TLS 217.0.20.195:5061;branch=z9hG4bKg3Zqkv7i3hyqkbq9zvvi97sggxghgkuqm
To: <sip:[email protected]>;tag=ed2437ec-1349-425f-8061-a0a272ffa67b
From: <sip:[email protected]>;tag=h7g4Esbg_p65540t1560870358m922456c170430787s1_1934145808-1437309507
Call-ID: 42ab1001-7254-4cf3-97c4-5f21af620171
CSeq: 3113 INVITE
Contact: <sip:[email protected]:5061;transport=tls>;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"
Min-Se: 900
Session-Expires: 1800;refresher=uac
Supported: timer
Content-Length: 0
Allow: REGISTER, REFER, NOTIFY, SUBSCRIBE, PRACK, UPDATE, INVITE, ACK, OPTIONS, CANCEL, BYE


<--- Transmitting SIP response (1091 bytes) to TLS:217.0.20.195:5061 --->
SIP/2.0 200 OK
Via: SIP/2.0/TLS 217.0.20.195:5061;rport=5061;received=217.0.20.195;branch=z9hG4bKg3Zqkv7i3hyqkbq9zvvi97sggxghgkuqm
Call-ID: 42ab1001-7254-4cf3-97c4-5f21af620171
From: <sip:[email protected]>;tag=h7g4Esbg_p65540t1560870358m922456c170430787s1_1934145808-1437309507
To: <sip:[email protected]>;tag=ed2437ec-1349-425f-8061-a0a272ffa67b
CSeq: 3113 INVITE
Session-Expires: 1800;refresher=uac
Require: timer
Contact: <sip:[email protected]:5061;transport=TLS>
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
Supported: 100rel, timer, replaces, norefersub
Server: FPBX-14.0.11(16.4.0)
Content-Type: application/sdp
Content-Length:   342

v=0
o=- 1405868408 1405868409 IN IP4 46.91.12.57
s=Asterisk
c=IN IP4 46.91.12.57
t=0 0
m=audio 10034 RTP/SAVP 8 101
a=3ge2ae:requested
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:5UrvnVqB7sXxPfCSDxctmyepR4nt080VRrh/EpuS
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv


<--- Received SIP request (957 bytes) from TLS:217.0.20.195:5061 --->
ACK sip:[email protected]:5061;transport=tcp SIP/2.0
Max-Forwards: 64
Via: SIP/2.0/TLS 217.0.20.195:5061;branch=z9hG4bKg3Zqkv7ilmv6i9qhs8vxifxrg1nnquwt7
To: <sip:[email protected]>;tag=ed2437ec-1349-425f-8061-a0a272ffa67b
From: <sip:[email protected]>;tag=h7g4Esbg_p65540t1560870358m922456c170430787s1_1934145808-1437309507
Call-ID: 42ab1001-7254-4cf3-97c4-5f21af620171
CSeq: 3113 ACK
Contact: <sip:[email protected]:5061;transport=tls>;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"
Content-Type: application/sdp
Content-Length: 370

v=0
o=- 36003913 1935390661 IN IP4 217.0.20.195
s=media server session
b=AS:80
t=0 0
m=audio 47226 RTP/SAVP 8 101
c=IN IP4 217.0.135.7
b=AS:84
b=RR:0
b=RS:0
a=rtpmap:8 PCMA/8000
a=ptime:20
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15,32,36
a=maxptime:50
a=sendrecv
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:CrufFLwEoEHNsF+avR5icqWksbxP7vOEfjEF/iYD






<--- Received SIP request (721 bytes) from TLS:217.0.20.195:5061 --->
INVITE sip:[email protected]:5061;transport=tcp SIP/2.0
Max-Forwards: 64
Via: SIP/2.0/TLS 217.0.20.195:5061;branch=z9hG4bKg3Zqkv7ipfw1goop5lm9qzgzch5owlc18
To: <sip:[email protected]>;tag=ed2437ec-1349-425f-8061-a0a272ffa67b
From: <sip:[email protected]>;tag=h7g4Esbg_p65540t1560870358m922456c170430787s1_1934145808-1437309507
Call-ID: 42ab1001-7254-4cf3-97c4-5f21af620171
CSeq: 3114 INVITE
Contact: <sip:[email protected]:5061;transport=tls>;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"
Min-Se: 900
Session-Expires: 1800;refresher=uac
Supported: timer
Content-Length: 0
Allow: REGISTER, REFER, NOTIFY, SUBSCRIBE, PRACK, UPDATE, INVITE, ACK, OPTIONS, CANCEL, BYE


<--- Transmitting SIP response (1091 bytes) to TLS:217.0.20.195:5061 --->
SIP/2.0 200 OK
Via: SIP/2.0/TLS 217.0.20.195:5061;rport=5061;received=217.0.20.195;branch=z9hG4bKg3Zqkv7ipfw1goop5lm9qzgzch5owlc18
Call-ID: 42ab1001-7254-4cf3-97c4-5f21af620171
From: <sip:[email protected]>;tag=h7g4Esbg_p65540t1560870358m922456c170430787s1_1934145808-1437309507
To: <sip:[email protected]>;tag=ed2437ec-1349-425f-8061-a0a272ffa67b
CSeq: 3114 INVITE
Session-Expires: 1800;refresher=uac
Require: timer
Contact: <sip:[email protected]:5061;transport=TLS>
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
Supported: 100rel, timer, replaces, norefersub
Server: FPBX-14.0.11(16.4.0)
Content-Type: application/sdp
Content-Length:   342

v=0
o=- 1405868408 1405868409 IN IP4 46.91.12.57
s=Asterisk
c=IN IP4 46.91.12.57
t=0 0
m=audio 10034 RTP/SAVP 8 101
a=3ge2ae:requested
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:5UrvnVqB7sXxPfCSDxctmyepR4nt080VRrh/EpuS
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv


<--- Received SIP request (908 bytes) from TLS:217.0.20.195:5061 --->
ACK sip:[email protected]:5061;transport=tcp SIP/2.0
Max-Forwards: 64
Via: SIP/2.0/TLS 217.0.20.195:5061;branch=z9hG4bKg3Zqkv7i6ofpt5l2rx66zkfgky3cnjn3r
To: <sip:[email protected]>;tag=ed2437ec-1349-425f-8061-a0a272ffa67b
From: <sip:[email protected]>;tag=h7g4Esbg_p65540t1560870358m922456c170430787s1_1934145808-1437309507
Call-ID: 42ab1001-7254-4cf3-97c4-5f21af620171
CSeq: 3114 ACK
Contact: <sip:[email protected]:5061;transport=tls>;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"
Content-Type: application/sdp
Content-Length: 321

v=0
o=- 36003913 1935390662 IN IP4 217.0.20.195
s=phone-call
c=IN IP4 217.0.135.7
t=0 0
m=audio 47226 RTP/SAVP 8 101
a=ptime:20
a=maxptime:150
a=sendrecv
a=rtpmap:8 pcma/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:CrufFLwEoEHNsF+avR5icqWksbxP7vOEfjEF/iYD






<--- Transmitting SIP request (556 bytes) to TLS:217.0.20.195:5061 --->
BYE sip:[email protected]:5061;transport=tls SIP/2.0
Via: SIP/2.0/TLS 46.91.12.57:5061;rport;branch=z9hG4bKPjd82642a3-b1a3-4483-8e46-ed4bd15a71ae;alias
From: <sip:[email protected]>;tag=ed2437ec-1349-425f-8061-a0a272ffa67b
To: <sip:[email protected]>;tag=h7g4Esbg_p65540t1560870358m922456c170430787s1_1934145808-1437309507
Call-ID: 42ab1001-7254-4cf3-97c4-5f21af620171
CSeq: 3114 BYE
Route: <sip:217.0.20.195:5061;transport=tls;lr>
Reason: Q.850;cause=16
Max-Forwards: 70
User-Agent: FPBX-14.0.11(16.4.0)
Content-Length:  0


<--- Received SIP response (512 bytes) from TLS:217.0.20.195:5061 --->
SIP/2.0 200 OK
Via: SIP/2.0/TLS 46.91.12.57:5061;received=46.91.12.57;rport=37373;branch=z9hG4bKPjd82642a3-b1a3-4483-8e46-ed4bd15a71ae;alias
To: <sip:[email protected]>;tag=h7g4Esbg_p65540t1560870358m922456c170430787s1_1934145808-1437309507
From: <sip:[email protected]>;tag=ed2437ec-1349-425f-8061-a0a272ffa67b
Call-ID: 42ab1001-7254-4cf3-97c4-5f21af620171
CSeq: 3114 BYE
Content-Length: 0
Allow: REGISTER, REFER, NOTIFY, SUBSCRIBE, PRACK, UPDATE, INVITE, ACK, OPTIONS, CANCEL, BYE
 
Noch eine wichtige Anmerkung, die relevant wird, wenn man von SRTP/Mediasec zurückwechseln möchte auf RTP (unverschlüsselt). Hier macht sich das Verhalten des Telekom-Voice-Servers bemerkbar, welches ich hier beschrieben habe: Das deaktivieren von Mediasec alleine genügt nicht, weil man ansonsten durch den Server der Telekom trotzdem im Mediasec-Pfad gehalten wird, weil dieser nach wie vor Mediasec erwartet und auch nicht davon abrückt (konsequenterweise). Das üble ist dabei, dass das nicht sofort auffällt (zumindest nicht auf Basis des Register-Status), weil die Registrierung ja zunächst durchaus funktioniert (weil nicht bei jedem Register die Mediasec-Erweiterungen erwartet werden). Calls gehen jedoch von Anfang an nicht mehr (in beide Richtungen, weil der Telekomserver ja die Verschlüsselung erzwingt) - trotz scheinbar erfolgreichem Register.

Wie kann man also zurückwechseln (auf Basis des Mediasec-Patches und FreePBX)? Man muss auf Basis der aktuellen Registrierung ein unregister durchführen (asterisk macht das beim Restart nicht automatisch - zumindest nicht wenn man den Prozess direkt durchstartet).
  1. Asterisk ohne Mediasec-Patch installieren (yum downgrade ... z.B.).
  2. In FreePBX in betroffenen Trunks SDP-Verschlüsselung deaktivieren.
  3. In der Asterisk-Konsole (asterisk -r als root) folgendes eingeben (für jeden relevanten Trunk):

    pjsip send unregister [Trunk Name]

    (eine Liste der gültigen Trunknamen bekommt man durch 2 maliges drücken der Tab-Taste wie man es von der Bash kennt).
  4. Asterisk durchstarten.
Wenn man doch mal gefangen wurde:
Asterisk mit Mediasec wieder installieren und dann den Prozess wie oben angeführt ausführen. Oder einfach austimen lassen (ca. 20 Minuten) - dazu muss Asterisk gestoppt sein. Oder auf SIP/UDP wechseln und hoffen, dass man einen anderen Server zugeordnet bekommt.
 
Ich bin vor eniegen Tagen von TLS/SRTP halb zurück auf TLS/RTP gewechselt. Nach dem unregister-register lief das auch problemlos.
Heute hat sich dann der FreePBX Rechner aufgehangen. Nach einem Neustart ging dann weder rein-noch raus. Laut Log war aber Registrierung OK.
Ausgehend bekam ich die Meldung "all channels are busy now" und eingehend wurde es nicht zu mir geroutet. (mit tcpdump nichts auf Port 5061)

Noch jemand Probleme zur Zeit?

Und müsste nicht
"openssl s_client -connect tel.t-online.de:5061"
zumindestens den TLS-Handshare zurück geben?
Edit: Okay, muss er nicht.
 
Zuletzt bearbeitet:
Ich beobachte keinerlei Probleme, die offensichtlich auf die Verschlüsselung / SRTP zurückzuführen wären.

Was den openssl s_client .. angeht:
Wenn Du einen TLS-fähigen Server der Telekom erwischst, funktioniert das. Bekommst Du mit diesem Befehl:

dig srv _sips._tcp.tel.t-online.de


Vodafone liefert zur Zeit Schrott-SDPs aus (weiß nicht, ob es schon gefixt ist - nö, gerade getestet, kommt immer noch Schrott). Hat sich bei mir durch fehlendes Audio (in einem speziellen Fall - war eine "Rückverbindung" von MOH auf das Telefon seitens des Callee - könnte natürlich auch was anderes als Ursache sein - aber ich kann das in diesem Fall nicht näher analysieren, weil das Ziel dafür nicht geeignet ist) reproduzierbar bemerkbar gemacht. Ansonsten funktioniert es eigentlich seltsamerweise trotzdem hier bei bekannten Nummern mit diesem Fehler.
 
Hallo zusammen,
irgendetwas muss sich bei Telekom verändert haben. Seit heute Nacht scheint die SIPS Verschlüsselung nicht mehr zu funktionieren.
Die Accounts wurden zwar registriert, aber ankommende Anrufer bekommen ein "schnelles besetzt".

Also mal abwarten, was Telekom mal wieder an ihrer Software herumbastelt.

Gruß
Michael
 
Kann ich nicht nachvollziehen - funktioniert hier ganz normal. Kannst Du das von beliebigen Providern aus reproduzieren? Oder nur von manchen? Das beschriebene Verhalten deutet auf ein SDP-Problem hin. Ist aber nur spekulativ.

Hast Du Dir das Ganze in asterisk -r und "pjsip set logger on" und hinterher off schonmal angeschaut? Bzw. zusätzlich noch Debugeinstellungen.
 
Code: 
pbx*CLI> pjsip set logger on
PJSIP Logging enabled
<--- Received SIP request (930 bytes) from UDP:172.16.0.4:38722 --->
INVITE sip:*123*[email protected] SIP/2.0
Via: SIP/2.0/UDP 192.168.2.108:38722;branch=z9hG4bK935707883;rport
From: <sip:[email protected]>;tag=78150829
To: <sip:*123*[email protected]>
Call-ID: [email protected]
CSeq: 470 INVITE
Contact: <sip:[email protected]:38722>
Max-Forwards: 70
User-Agent: Grandstream Wave 1.0.3.29
Privacy: none
P-Preferred-Identity: <sip:[email protected]>
Supported: replaces, path, timer, eventlist
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE, MESSAGE
Content-Type: application/sdp
Accept: application/sdp, application/dtmf-relay
Content-Length:   272

v=0
o=888 8000 8000 IN IP4 192.168.2.108
s=SIP Call
c=IN IP4 192.168.2.108
t=0 0
m=audio 53646 RTP/AVP 0 8 101
a=sendrecv
a=rtcp:53647 IN IP4 192.168.2.108
a=rtpmap:0 PCMU/8000
a=ptime:20
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

<--- Transmitting SIP response (482 bytes) to UDP:172.16.0.4:38722 --->
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.2.108:38722;rport=38722;received=172.16.0.4;branch=z9hG4bK935707883
Call-ID: [email protected]
From: <sip:[email protected]>;tag=78150829
To: <sip:*123*[email protected]>;tag=z9hG4bK935707883
CSeq: 470 INVITE
WWW-Authenticate: Digest realm="asterisk",nonce="1565332173/9e18f014b9257991e4a58135189a047d",opaque="51ac3df27cd889c4",algorithm=md5,qop="auth"
Server: FPBX-15.0.16(16.4.1)
Content-Length:  0


<--- Received SIP request (296 bytes) from UDP:172.16.0.4:38722 --->
ACK sip:*123*[email protected] SIP/2.0
Via: SIP/2.0/UDP 192.168.2.108:38722;branch=z9hG4bK935707883;rport
From: <sip:[email protected]>;tag=78150829
To: <sip:*123*[email protected]>;tag=z9hG4bK935707883
Call-ID: [email protected]
CSeq: 470 ACK
Content-Length: 0


<--- Received SIP request (1208 bytes) from UDP:172.16.0.4:38722 --->
INVITE sip:*123*[email protected] SIP/2.0
Via: SIP/2.0/UDP 192.168.2.108:38722;branch=z9hG4bK902114594;rport
From: <sip:[email protected]>;tag=78150829
To: <sip:*123*[email protected]>
Call-ID: [email protected]
CSeq: 471 INVITE
Contact: <sip:[email protected]:38722>
Authorization: Digest username="888", realm="asterisk", nonce="1565332173/9e18f014b9257991e4a58135189a047d", uri="sip:*123*[email protected]", response="53528b250adaa393060398065220b436", algorithm=md5, cnonce="07371636", opaque="51ac3df27cd889c4", qop=auth, nc=0000000b
Max-Forwards: 70
User-Agent: Grandstream Wave 1.0.3.29
Privacy: none
P-Preferred-Identity: <sip:[email protected]>
Supported: replaces, path, timer, eventlist
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE, MESSAGE
Content-Type: application/sdp
Accept: application/sdp, application/dtmf-relay
Content-Length:   272

v=0
o=888 8000 8000 IN IP4 192.168.2.108
s=SIP Call
c=IN IP4 192.168.2.108
t=0 0
m=audio 53646 RTP/AVP 0 8 101
a=sendrecv
a=rtcp:53647 IN IP4 192.168.2.108
a=rtpmap:0 PCMU/8000
a=ptime:20
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

<--- Transmitting SIP response (309 bytes) to UDP:172.16.0.4:38722 --->
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.2.108:38722;rport=38722;received=172.16.0.4;branch=z9hG4bK902114594
Call-ID: [email protected]
From: <sip:[email protected]>;tag=78150829
To: <sip:*123*[email protected]>
CSeq: 471 INVITE
Server: FPBX-15.0.16(16.4.1)
Content-Length:  0


<--- Transmitting SIP request (1042 bytes) to TLS:217.0.25.99:5061 --->
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/TLS 87.148.193.85:5061;rport;branch=z9hG4bKPjcbbc4b5a-4c6e-4aa9-bb9a-b88420a6537a;alias
From: <sip:[email protected]>;tag=5295514c-52bc-4e72-b4ad-3c2b4bc3f412
To: <sip:[email protected]>
Contact: <sip:[email protected]:5061;transport=TLS>
Call-ID: 6d07e64b-0f7e-4435-89c1-223975499975
CSeq: 377 INVITE
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
Supported: 100rel, timer, replaces, norefersub
Session-Expires: 1800
Min-SE: 90
Max-Forwards: 70
User-Agent: FPBX-15.0.16(16.4.1)
Content-Type: application/sdp
Content-Length:   339

v=0
o=- 1062047367 1062047367 IN IP4 87.148.193.85
s=Asterisk
c=IN IP4 87.148.193.85
t=0 0
m=audio 14724 RTP/AVP 8 9 3 0 119 101
a=rtpmap:8 PCMA/8000
a=rtpmap:9 G722/8000
a=rtpmap:3 GSM/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:119 speex/32000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:60
a=sendrecv

<--- Received SIP response (360 bytes) from TLS:217.0.25.99:5061 --->
SIP/2.0 488 Not Acceptable Here
Via: SIP/2.0/TCP 87.148.193.85:5061;rport;branch=z9hG4bKPjcbbc4b5a-4c6e-4aa9-bb9a-b88420a6537a;alias
To: <sip:[email protected]>;tag=huag5u2qnht
From: <sip:[email protected]>;tag=5295514c-52bc-4e72-b4ad-3c2b4bc3f412
Call-ID: 6d07e64b-0f7e-4435-89c1-223975499975
CSeq: 377 INVITE
Content-Length: 0


<--- Transmitting SIP request (422 bytes) to TLS:217.0.25.99:5061 --->
ACK sip:[email protected] SIP/2.0
Via: SIP/2.0/TLS 87.148.193.85:5061;rport;branch=z9hG4bKPjcbbc4b5a-4c6e-4aa9-bb9a-b88420a6537a;alias
From: <sip:[email protected]>;tag=5295514c-52bc-4e72-b4ad-3c2b4bc3f412
To: <sip:[email protected]>;tag=huag5u2qnht
Call-ID: 6d07e64b-0f7e-4435-89c1-223975499975
CSeq: 377 ACK
Max-Forwards: 70
User-Agent: FPBX-15.0.16(16.4.1)
Content-Length:  0


<--- Transmitting SIP response (838 bytes) to UDP:172.16.0.4:38722 --->
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP 192.168.2.108:38722;rport=38722;received=172.16.0.4;branch=z9hG4bK902114594
Call-ID: [email protected]
From: <sip:[email protected]>;tag=78150829
To: <sip:*123*[email protected]>;tag=5ace91a5-70d1-465e-97af-604d82c6f789
CSeq: 471 INVITE
Server: FPBX-15.0.16(16.4.1)
Contact: <sip:87.148.193.85:5060>
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
P-Asserted-Identity: "CID:123123123123" <sip:*123*[email protected]>
Content-Type: application/sdp
Content-Length:   223

v=0
o=- 8000 8002 IN IP4 172.16.0.80
s=Asterisk
c=IN IP4 172.16.0.80
t=0 0
m=audio 42378 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv

<--- Transmitting SIP request (482 bytes) to TLS:217.0.25.99:5061 --->
OPTIONS sip:[email protected] SIP/2.0
Via: SIP/2.0/TLS 87.148.193.85:5061;rport;branch=z9hG4bKPjd20cfad8-07f8-45da-979b-4ec0c7786763;alias
From: <sip:[email protected]>;tag=7b0ed6ef-987d-48b2-8bd5-df452ba8085d
To: <sip:[email protected]>
Contact: <sip:[email protected]:5061;transport=TLS>
Call-ID: b0e6a5bc-d632-45ac-8876-80990675e551
CSeq: 7318 OPTIONS
Max-Forwards: 70
User-Agent: FPBX-15.0.16(16.4.1)
Content-Length:  0


<--- Received SIP response (485 bytes) from TLS:217.0.25.99:5061 --->
SIP/2.0 200 In Ordnung
Via: SIP/2.0/TLS 87.148.193.85:5061;received=87.148.193.85;rport=43862;branch=z9hG4bKPjd20cfad8-07f8-45da-979b-4ec0c7786763;alias
To: <sip:[email protected]>;tag=h7g4Esbg_bzfs9hc3wzt4yz2q288hsu1l6i6uz1x1
From: <sip:[email protected]>;tag=7b0ed6ef-987d-48b2-8bd5-df452ba8085d
Call-ID: b0e6a5bc-d632-45ac-8876-80990675e551
CSeq: 7318 OPTIONS
Content-Length: 0
Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,REGISTER,INFO,PRACK,UPDATE,REFER


<--- Transmitting SIP response (573 bytes) to UDP:172.16.0.4:38722 --->
SIP/2.0 503 Service Unavailable
Via: SIP/2.0/UDP 192.168.2.108:38722;rport=38722;received=172.16.0.4;branch=z9hG4bK902114594
Call-ID: [email protected]
From: <sip:[email protected]>;tag=78150829
To: <sip:*123*[email protected]>;tag=5ace91a5-70d1-465e-97af-604d82c6f789
CSeq: 471 INVITE
Server: FPBX-15.0.16(16.4.1)
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
Reason: Q.850;cause=34
P-Asserted-Identity: "CID:123123123123" <sip:*123*[email protected]>
Content-Length:  0


<--- Received SIP request (316 bytes) from UDP:172.16.0.4:38722 --->
ACK sip:*123*[email protected] SIP/2.0
Via: SIP/2.0/UDP 192.168.2.108:38722;branch=z9hG4bK902114594;rport
From: <sip:[email protected]>;tag=78150829
To: <sip:*123*[email protected]>;tag=5ace91a5-70d1-465e-97af-604d82c6f789
Call-ID: [email protected]
CSeq: 471 ACK
Content-Length: 0


pbx*CLI> pjsip set logger off
PJSIP Logging disabled
pbx*CLI>
[Edit Novize: Log in Code-Tags gepackt, das macht es doch erheblich übersichtlicher]
 
Zuletzt bearbeitet von einem Moderator:
Im Vergleich zu mipo geht es bei dir um Outbound-Calls. Sind sämtliche Destinations betroffen? Oder geht z.B. die Telekomhotline 08003301000?
Du bekommst ein "488 Not Acceptable Here" - schonmal versucht, die Codecs GSM und speex wegzulassen? Vielleicht stören die sich ja neuerdings daran?

Hast Du mal geprüft, welche SIP-Server Dir die Telekom für TLS zuweisen würde? Hierzu solltest Du sicherheitshalber den DNS befragen, den Dir die Telekom beim PPPoE-Login zugewiesen hat (die vom freien DNS können abweichen). Nutzt Asterisk einen dieser Server (bekommst Du mit

Code: 
netstat | grep 217.0

raus)?

Die Server, die asterisk verwenden sollte, bekommst Du mit

Code: 
dig srv _sips._tcp.tel.t-online.de @DNS-IP

Ich bekomme sowohl vom mir zugewiesenen Telekom-DNS (den verwende ich für die Telefonie) als auch von einem freien DNS-Server andere als die von Dir verwendete IP. Kann aber trotzdem passen.

Ich gehe übrigens davon aus, dass Du asterisk 16.x verwendest mit pjsip (das läuft zumindest hier - incl. mediasec-Patch).
 
Es kann gut sein, dass nun forciert wird, dass SIP over TLS nur mit SRTP verwendet werden kann und SIP over TCP/UDP nur mit RTP.
 
Durchaus denkbar - dann hätte ich aber konsequenterweise auch erwartet, dass bei sips/tcp eine Registrierung nur mit mediasec-Erweiterung durchgeht - oder wird srtp mittlerweile auch ohne mediasec unterstützt oder will man gar von mediasec komplett weg - wäre ja wünschenswert.
 
gehtdoch schrieb:
Im Vergleich zu mipo geht es bei dir um Outbound-Calls. Sind sämtliche Destinations betroffen? Oder geht z.B. die Telekomhotline 08003301000?
Zum Vergrößern anklicken....

Wie weiter oben erwähnt, geht bei mir beides nicht. Rein wie raus. Interessant ist, dass eingehend nichtmal ein Paket bei mir aufschlägt, als ob Telekom schon vorher wegfiltert . Daher kann ich mir das mit den Codecs auch nicht so recht vorstellen.(oder ich habe mich beim tcpdump vertippt).
Versuche gerade mal wieder eine Asterisk Version mit mediasec Patch zu bauen, aber aktuell klemmts noch am "mock", welches sich über eine Fehlende Gruppe beschwert. Vermute aber auch, dass jetzt SRTP Pflicht ist.


Edit: mit SRTP gehts wieder
Edit2: Habe auch den sdp Patch mit drinnen, aber bei der 116116 höre ich dennoch nichts?!
 
Zuletzt bearbeitet:
Hallo zusammen,
ich habe eine Auerswald COMmander 6000 ... dort sind die Debugmöglichkeiten relativ eingeschränkt. Klar, ich kann natürlich den Wireshark mitlaufen lassen. Aber so richtige Logfiles,
wie unter Asterisk möglich, gibt es für den Endanwender leider nicht. Bei mir war, so habe ich bemerkt, auch der ausgehende Verkehr gestört. Also beides ging nicht.

Ich werde mal am WE ein wenig herumspielen, mal schauen woran das liegt. Ärgerlich eigentlich, denn warum sollte man die Kommunikation nicht verschlüsseln ...

Gruß
Michael
 
Um antworten zu können musst du eingeloggt sein.

Zurzeit aktive Besucher

Keine Mitglieder online.
Gesamt: 526 (Mitglieder: 0, Gäste: 526)

Neueste Beiträge

Statistik des Forums

Themen
246,167
Beiträge
2,247,306
Mitglieder
373,705
Neuestes Mitglied
brunomuehl
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.
Ihr E-Mail-Adresse verifizieren

Ihr E-Mail-Adresse verifizieren

Wir haben Ihnen eine E-Mail geschickt. Klicken Sie auf die Schaltfläche im E-Mail-Text, um Ihre E-Mail-Adresse zu verifizieren – (Können Sie diese nicht finden können, dann überprüfen Sie Ihren Spam-Ordner).

IPPF im Überblick

Neueste Beiträge

Direktlinks Telefonanlage

Website-Sponsoren

3CX sponsor
KONTAKTIEREN SIE UNS BEI INTERESSE
| Style by ThemeHouse
XenPorta 2 PRO © Jason Axelrod of 8WAYRUN
Oben Unten
Zurück