Codeceihenfolge oder Codecs verbieten
Moin zusammen,
Gibt es irgendwo eine Möglichkeit die Reihenfolge der angebotenen Codecs zu beeinflussen oder einen Codes zu sperren?
Im konkreten Fall rufe ich vom Softwarephone via Amt einen externen Teilnehmer an. Das Softwarephone steht auf Opus, um intern HD zu gewährleisten, der SIP-Trunk auf Transparent. Die Codec-Liste sieht wie folgt aus:
Session Description Protocol
Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): - 74103 1 IN IP4 A.B.C.D
Owner Username: -
Session ID: 74103
Session Version: 1
Owner Network Type: IN
Owner Address Type: IP4
Owner Address: A.B.C.D
Session Name (s): -
Time Description, active time (t): 0 0
Session Start Time: 0
Session Stop Time: 0
Media Description, name and address (m): audio 30952 RTP/AVP 109 0 8 18 101 13
Media Type: audio
Media Port: 30952
Media Protocol: RTP/AVP
Media Format: DynamicRTP-Type-109
Media Format: ITU-T G.711 PCMU
Media Format: ITU-T G.711 PCMA
Media Format: ITU-T G.729
Media Format: DynamicRTP-Type-101
Media Format: Comfort noise
Connection Information (c): IN IP4 A.B.C.D
Connection Network Type: IN
Connection Address Type: IP4
Connection Address: A.B.C.D
Media Attribute (a): rtpmap:109 opus/48000/2
Media Attribute Fieldname: rtpmap
Media Format: 109
MIME Type: opus
Sample Rate: 48000
Media Attribute (a): rtpmap:0 PCMU/8000
Media Attribute Fieldname: rtpmap
Media Format: 0
MIME Type: PCMU
Sample Rate: 8000
Media Attribute (a): rtpmap:8 PCMA/8000
Media Attribute Fieldname: rtpmap
Media Format: 8
MIME Type: PCMA
Sample Rate: 8000
Media Attribute (a): rtpmap:18 G729/8000
Media Attribute Fieldname: rtpmap
Media Format: 18
MIME Type: G729
Sample Rate: 8000
Media Attribute (a): rtpmap:101 telephone-event/8000
Media Attribute Fieldname: rtpmap
Media Format: 101
MIME Type: telephone-event
Sample Rate: 8000
Media Attribute (a): rtpmap:13 CN/8000
Media Attribute Fieldname: rtpmap
Media Format: 13
MIME Type: CN
Sample Rate: 8000
Das Ziel (wie auch der Provider) findet Opus doof und nimmt naturgemäß den 2. Codec, welcher G.711u ist:
Session Description Protocol
Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): - 3512555179 1981861747 IN IP4 A.B.C.D
Owner Username: -
Session ID: 3512555179
Session Version: 1981861747
Owner Network Type: IN
Owner Address Type: IP4
Owner Address: A.B.C.D
Session Name (s): TNG-SBC
Connection Information (c): IN IP4 A.B.C.D
Connection Network Type: IN
Connection Address Type: IP4
Connection Address: A.B.C.D
Time Description, active time (t): 0 0
Session Start Time: 0
Session Stop Time: 0
Media Description, name and address (m): audio 12434 RTP/AVP 0 101
Media Type: audio
Media Port: 12434
Media Protocol: RTP/AVP
Media Format: ITU-T G.711 PCMU
Media Format: DynamicRTP-Type-101
Media Attribute (a): rtpmap:0 PCMU/8000
Media Attribute Fieldname: rtpmap
Media Format: 0
MIME Type: PCMU
Sample Rate: 8000
Media Attribute (a): rtpmap:101 telephone-event/8000
Media Attribute Fieldname: rtpmap
Media Format: 101
MIME Type: telephone-event
Sample Rate: 8000
Media Attribute (a): fmtp:101 0-15
Media Attribute Fieldname: fmtp
Media Format: 101 [telephone-event]
Media format specific parameters: 0-15
Media Attribute (a): silenceSupp:off - - - -
Media Attribute Fieldname: silenceSupp
Media Attribute Value: off - - - -
Media Attribute (a): rtcp-mux
Media Attribute (a): sendrecv
Media Attribute (a): ptime:20
Media Attribute Fieldname: ptime
Media Attribute Value: 20
Da das Ziel auch noch DTMF Inband machen will, fühlt sich mein Provider dazu berufen, den Call über einen DSP zu jagen um die DTMF nach Outband zu befördern. Und augenscheinlich haben seine DSPs ein Problem mit G.711u und können nur vernünftig G.711a. Aber vielleicht kann der angerufene Teilnehmer auch schon nicht so gut G.711u wie er denkt. Auf jeden Fall habe ich so ein Problem mit der Payload.
Rufe ich von einem IP222 an (welches auf G.722 steht), oder einem IP112 (auf Opus), dann kommt immer G.711a als 2. Option in der Codec-Liste und habe keine Probleme.
Daher ist die Frage eingangs gestellte Frage.
fehlcodierte Grüße
Niels