Mal wieder ein Gesprächsabbruch. Bei einem ausgehenden Call zu einem telefonica-mobile - Kunden bricht das Gespräch nach 407s ab (die Gesprächsqualität war bis zum Ende einwandfrei - Callee war zu Hause). Der Abbruch geschieht direkt als Folge zweier OPTIONS-Methoden - die ich so in einem telefonica-Gespräch in meinen sämtlichen Logs über Monate noch nie gesehen habe.
Es stellen sich also zwei Fragen? Warum kommen da plötzlich mittendrin OPTIONS-Pakete? Zweitens, was schmeckt der Telekom (oder telefonica) an der Antwort nicht?
Im Detail das eingehende OPTIONS-Paket und die Antwort von Asterisk dazu
Direkt danach kommt die zweite - leicht modifizierte Anfrage - dann nach dem Ok durch Asterisk sofort der Abbruch / Bye:
Was ist anders in der zweiten Anfrage? CSEQ ist plötzlich eine völlig andere - von 1 -> 15431 (die Anfrage scheint von einem anderen Device gestellt worden zu sein im Vergleich zur ersten). Es ist jetzt auch ein Contact-Header und Allow-Header vorhanden, die beide vorher nicht da waren.
Evtl. ist es relevant, dass die Sequenz während eines verschlüsselten Gesprächs (also mediasec) stattgefunden hat. Allerdings sind die Antworten der Telekom auf die regelmäßigen von Asterisk generierten OPTIONS - Pakte auch nicht spezifisch hinsichtlich mediasec.
Hat irgendjemand eine Idee, was da los gewesen sein könnte?
Update 10.04.2021:
Habe dieses Verhalten seither nicht mehr gesehen und auch vorher nie - keine Ahnung, was den TN B da geritten hat.
Es stellen sich also zwei Fragen? Warum kommen da plötzlich mittendrin OPTIONS-Pakete? Zweitens, was schmeckt der Telekom (oder telefonica) an der Antwort nicht?
Im Detail das eingehende OPTIONS-Paket und die Antwort von Asterisk dazu
Code:
Request-Line: OPTIONS sip:[email protected]:5061;transport=tcp SIP/2.0
Method: OPTIONS
Request-URI: sip:[email protected]:5061;transport=tcp
[Resent Packet: False]
Message Header
Max-Forwards: 70
Via: SIP/2.0/TLS 217.0.20.195:5061;branch=z9hG4bKg3Zqkv7ix6fl8jo25deekjg8xmvlwb86i
To: <sip:[email protected];user=phone>;tag=3e0bc408-7f9e-4ce1-805c-bc5e233df342
From: <sip:[email protected];user=phone>;tag=h7g4Esbg_p65558t1613974594m393367c92318s1_3193970756-1299187758
Call-ID: 109bb682-7735-4e99-b151-d68be0353ace
CSeq: 1 OPTIONS
Content-Length: 0
Antwort
Status-Line: SIP/2.0 200 OK
Status-Code: 200
[Resent Packet: False]
[Request Frame: 18]
[Response Time (ms): 1]
Message Header
Via: SIP/2.0/TLS 217.0.20.195:5061;rport=5061;received=217.0.20.195;branch=z9hG4bKg3Zqkv7ix6fl8jo25deekjg8xmvlwb86i
Call-ID: 109bb682-7735-4e99-b151-d68be0353ace
From: <sip:[email protected];user=phone>;tag=h7g4Esbg_p65558t1613974594m393367c92318s1_3193970756-1299187758
To: <sip:[email protected];user=phone>;tag=3e0bc408-7f9e-4ce1-805c-bc5e233df342
CSeq: 1 OPTIONS
[truncated]Accept: application/dialog-info+xml, application/xpidf+xml, application/cpim-pidf+xml, application/simple-message-summary, application/pidf+xml, application/pidf+xml, application/dialog-info+xml, application/simple-message-sum
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
Supported: 100rel, timer, replaces, norefersub
Accept-Encoding: identity
Accept-Language: en
Server: FPBX-15.0.17.12(18.2.0)
Content-Length: 0Direkt danach kommt die zweite - leicht modifizierte Anfrage - dann nach dem Ok durch Asterisk sofort der Abbruch / Bye:
Code:
Request-Line: OPTIONS sip:[email protected]:5061;transport=tcp SIP/2.0
Method: OPTIONS
Request-URI: sip:[email protected]:5061;transport=tcp
[Resent Packet: False]
Message Header
Max-Forwards: 66
Via: SIP/2.0/TLS 217.0.20.195:5061;branch=z9hG4bKg3Zqkv7iveou8w6gf4cjvb37rth8xhn6z
To: <sip:[email protected];user=phone>;tag=3e0bc408-7f9e-4ce1-805c-bc5e233df342
From: <sip:[email protected];user=phone>;tag=h7g4Esbg_p65558t1613974594m393367c92318s1_3193970756-1299187758
Call-ID: 109bb682-7735-4e99-b151-d68be0353ace
CSeq: 15431 OPTIONS
Contact: <sip:[email protected]:5061;transport=tls>;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"
Content-Length: 0
Allow: REGISTER, REFER, NOTIFY, SUBSCRIBE, PUBLISH, MESSAGE, UPDATE, PRACK, INFO, INVITE, ACK, OPTIONS, CANCEL, BYE
Antwort:
Status-Line: SIP/2.0 200 OK
Status-Code: 200
[Resent Packet: False]
[Request Frame: 20]
[Response Time (ms): 1]
Message Header
Via: SIP/2.0/TLS 217.0.20.195:5061;rport=5061;received=217.0.20.195;branch=z9hG4bKg3Zqkv7iveou8w6gf4cjvb37rth8xhn6z
Call-ID: 109bb682-7735-4e99-b151-d68be0353ace
From: <sip:[email protected];user=phone>;tag=h7g4Esbg_p65558t1613974594m393367c92318s1_3193970756-1299187758
To: <sip:[email protected];user=phone>;tag=3e0bc408-7f9e-4ce1-805c-bc5e233df342
CSeq: 15431 OPTIONS
[truncated]Accept: application/dialog-info+xml, application/xpidf+xml, application/cpim-pidf+xml, application/simple-message-summary, application/pidf+xml, application/pidf+xml, application/dialog-info+xml, application/simple-message-sum
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
Supported: 100rel, timer, replaces, norefersub
Accept-Encoding: identity
Accept-Language: en
Server: FPBX-15.0.17.12(18.2.0)
Content-Length: 0Evtl. ist es relevant, dass die Sequenz während eines verschlüsselten Gesprächs (also mediasec) stattgefunden hat. Allerdings sind die Antworten der Telekom auf die regelmäßigen von Asterisk generierten OPTIONS - Pakte auch nicht spezifisch hinsichtlich mediasec.
Hat irgendjemand eine Idee, was da los gewesen sein könnte?
Update 10.04.2021:
Habe dieses Verhalten seither nicht mehr gesehen und auch vorher nie - keine Ahnung, was den TN B da geritten hat.
Zuletzt bearbeitet:
