[Problem] Höre eigene Music on Hold wenn Gegenüber Anruf hält

[hiasB]

Hallo zusammen,

seit der Umstellung von Telekom ISDN-PMX auf IP SIP-Trunk haben wir immer wieder das Problem, wenn der Kunde den Anruf in die Warteschleife bei sich setzt, hören wir unsere eigene Warteschleifen-Musik. Kann sich jemand das Verhalten erklären?

Asterisk-Version: 13

Vielen Dank schon mal für die Unterstützung!

 

[ubsyathEe]

Es obliegt dem Client zu entscheiden ob eigenes oder fremdes Audio abgespielt wird. Wenn kein fremdes Audio da ist, dann wird wohl immer versucht die eigene Haltemusik abzuspielen. Für Details müsste man sich die Anbindung der Anlage und die zugehörigen SIP-Traces ansehen.

 

[IEEE]

Ich höre das Phänomen auch 2-3 mal im Jahr von verschiedenen Anwendern von Asterisk Installation von mir. Erklären konnte ich es mir bisher auch nicht und leider konnte ich es bisher nicht nachstellen.

 

[gehtdoch]

Kenne das Phänomen auch. Immer bei dem gleichen. An der Stelle hilft nur ein Kompletttrace und mal vergleichen mit einem anderen Fall, wo dsa Phänomen nicht auftritt. Hatte bisher jedoch noch nicht den nötigen Druck, weil ich eigentlich ganz glücklich bin damit, die betreffende Originalwartemusik nicht hören zu müssen

 

[gehtdoch]

So, jetzt hatte ich mal die Möglichkeit, von dem Phänomen einen Trace zu bekommen.

Zusammenhang:
Ausgehender Call (49123456789) via Trunk direkt in eine Warteschleife des Callee (49456789100). Zunächst auch alles ok - die Wartemusik der Warteschleife mit Blabla des Callee. Dann plötzlich die eigene Wartemusik. Was steckt dahinter?
Dahinter steckt ein in dialog ReInvite vom Trunk (hier Telekom AllIP):

<--- Received SIP request (1076 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=z9hG4bKg3Zqkv7i2ii95g6vhbdsvwthyb2jpgjlq
To: <sip:[email protected]>;tag=dc836a99-022a-4a9c-92cb-c48fe3ece7df
From: <sip:[email protected]>;tag=h7g4Esbg_p65540t1572281639m210536c580555514s1_1486328459-875247633
Call-ID: 444c413a-3f52-4c30-a641-464932b200db
CSeq: 16180 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
Supported: resource-priority
Content-Type: application/sdp
Content-Length: 279
Allow: REGISTER, REFER, NOTIFY, SUBSCRIBE, PRACK, UPDATE, INFO, INVITE, ACK, OPTIONS, CANCEL, BYE

v=0
o=- 837846700 1486972075 IN IP4 217.0.20.195
s=IMSS
c=IN IP4 217.0.135.5
t=0 0
m=audio 30044 RTP/SAVP 8 101
a=rtpmap:101 telephone-event/8000
a=sendonly
a=ptime:20
a=3ge2ae:applied
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:sg8P1x2QfMteixo84KtFehovv0CRZKF5mYtq6WZ6

Das entscheidende hier: der Callee teilt im SDP teilt mit, dass er von nun an nur noch RTP-Daten sendet, aber keine mehr annimmt (a=sendonly). Warum asterisk an dieser Stelle auf die Idee kommt, dem (lokalen) Caller das eigene MOH zu präsentieren, entzieht sich meiner Kenntnis.
BTW: Hast Du evtl. FreePBX (wie ich) im Einsatz? Ich bin mir nicht sicher, ob das evtl. an FreePBX liegen könnte.

Die eigene MOH wird im Übrigen durch einen weiteren in dialog ReInvite beendet:

<--- Received SIP request (1076 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=z9hG4bKg3Zqkv7iug6idz4x88msm7foh8n28rsq4
To: <sip:[email protected]>;tag=dc836a99-022a-4a9c-92cb-c48fe3ece7df
From: <sip:[email protected]>;tag=h7g4Esbg_p65540t1572281639m210536c580555514s1_1486328459-875247633
Call-ID: 444c413a-3f52-4c30-a641-464932b200db
CSeq: 16181 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
Supported: resource-priority
Content-Type: application/sdp
Content-Length: 279
Allow: REGISTER, REFER, NOTIFY, SUBSCRIBE, PRACK, UPDATE, INFO, INVITE, ACK, OPTIONS, CANCEL, BYE

v=0
o=- 837846700 1486972076 IN IP4 217.0.20.195
s=IMSS
c=IN IP4 217.0.135.5
t=0 0
m=audio 30044 RTP/SAVP 8 101
a=rtpmap:101 telephone-event/8000
a=sendrecv
a=ptime:20
a=3ge2ae:applied
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:sg8P1x2QfMteixo84KtFehovv0CRZKF5mYtq6WZ6

Hier relevant: a=sendrecv