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

gehtdoch

Neuer User
Mitglied seit
3 Feb 2019
Beiträge
53
Punkte für Reaktionen
0
Punkte
6
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
 

Meester Proper

Neuer User
Mitglied seit
24 Mai 2014
Beiträge
116
Punkte für Reaktionen
7
Punkte
18
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.
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.
 

gehtdoch

Neuer User
Mitglied seit
3 Feb 2019
Beiträge
53
Punkte für Reaktionen
0
Punkte
6
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.
 

Meester Proper

Neuer User
Mitglied seit
24 Mai 2014
Beiträge
116
Punkte für Reaktionen
7
Punkte
18
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.
 

qupfer2

Neuer User
Mitglied seit
30 Jan 2016
Beiträge
12
Punkte für Reaktionen
0
Punkte
1
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^^
 

gehtdoch

Neuer User
Mitglied seit
3 Feb 2019
Beiträge
53
Punkte für Reaktionen
0
Punkte
6
Ich habe gerade einmal mit MicroSIP 3.19.14 getestet, welches ebenfalls PJSIP und pjmedia nutzt.
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.
 

gehtdoch

Neuer User
Mitglied seit
3 Feb 2019
Beiträge
53
Punkte für Reaktionen
0
Punkte
6
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^^
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).
 

Meester Proper

Neuer User
Mitglied seit
24 Mai 2014
Beiträge
116
Punkte für Reaktionen
7
Punkte
18
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?
 

gehtdoch

Neuer User
Mitglied seit
3 Feb 2019
Beiträge
53
Punkte für Reaktionen
0
Punkte
6
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
 

gehtdoch

Neuer User
Mitglied seit
3 Feb 2019
Beiträge
53
Punkte für Reaktionen
0
Punkte
6
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.
 

3CX PBX - GRATIS
Linux / Win / Cloud

Statistik des Forums

Themen
232,073
Beiträge
2,018,454
Mitglieder
349,399
Neuestes Mitglied
fabian2066