Step 4 Janus still sends DTMF as rfc2833 as it was in his initial invite; but provider do not accepts it as it was removed from the codec list by Janus
We are using latest unistream version, we can update to latest multistream but i am not sure that it will fix the issue
Global scheme
I am not exacly sure why it is happening, normally Janus should reply with something like
a=rtpmap:126 telephone-event/8000 in SDP of the 200 OK
Any idea how to fix that ?
If Janus sends X as payload type for DTMF and the SIP endpoint replies with a different payload type, then that’s the reason why it’s removed. You mentioned 110 and 101, which are different payload types.
They both uses a dynamic payload type of 126 and 101 i am not sure why Janus do not accepts it and stripts from reply, this normally means that codec is not compatible.
I am not sure where should i correct that, a provider has a right to reinvite, and as there is not DTMF in codec list it will never work. There are two solution for this
1: Quick and dirty
Change Janus 126 rtpmap to 101 in initial invite, which is not that bad as the number is still dynamic range, and looks like a lot of systems are still at rfc2833 which assumed 101
2: Make in sort that Janus accepts the 101 in Reinvite, and reply with 101 in 200 ok, which is a proper way.
I have compared a SNOM and Yealink phone, they do solution 2.
There’s good chances that it’s the browser that’s rejecting that payload type change, and you can’t change browsers. If you want to do 1., you still need to do that in browsers (e.g., via SDP munging), not Janus.
