DTMF payload type conversion from 96 to 101

[Aditya Uppuluri]

Hello Team.

First of all, thanks for the amazing product. I recently started working on using rtpengine (controller by kamailio) and so far it works great. I want to know if there is a way to change the telephone-event payload type explicitly ?

I am receiving the following from one endpoint

m=audio 17372 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000

m=audio 29490 RTP/AVP 0 8 96
c=IN IP4 10.10.144.93
b=TIAS:64000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:96 telephone-event/8000

As you see one side its 101 and other side its 96. Is there a way to change the number from 96 to 101 in rtpengine?

[Richard Fuchs]

No, there's no such feature. Can I ask why you need it numbered in a particular way?

Cheers

[Aditya Uppuluri]

Thank you for the response :) .

 I have a scenario where a call is initiated from asterisk which is anouncing payload type as 101. The sip client receives the notification of the call via some other means (using firebase realtime database). Then client (written with pjsip library) sends an invite to kamailio with payload type as 96. The bridging between these two calls happen in another B2BUA. Audio is working fine. but there are problems with DTMF tones. asterisk responding with *Unknown RTP codec 96 received from x.x.x.x*.  I don't have control at the client level or at the asterisk level (as they are mainained by some other team). 

So i want to do the transcoding at the RtpEngine level. As per the current architecture, only clients have the ability to talk to rtpengine.

Hope this clarifies.

Let me know if i can provide you with any further information.

Thank you

[Richard Fuchs]

On 20/07/2022 11.26, [EXT] Aditya Uppuluri wrote:
>
> Thank you for the response :) .
>  I have a scenario where a call is initiated from asterisk which is
> anouncing payload type as 101. The sip client receives the
> notification of the call via some other means (using firebase realtime
> database). Then client (written with pjsip library) sends an invite to
> kamailio with payload type as 96. The bridging between these two calls
> happen in another B2BUA. Audio is working fine. but there are problems
> with DTMF tones. asterisk responding with *Unknown RTP codec 96
> received from x.x.x.x*.  I don't have control at the client level or
> at the asterisk level (as they are mainained by some other team).
>
> So i want to do the transcoding at the RtpEngine level. As per the
> current architecture, only clients have the ability to talk to rtpengine.
>
> Hope this clarifies.
> Let me know if i can provide you with any further information.
>

Ok I see. So you basically have two SDP offers and are using those to
establish a call by pretending that one is an answer. This is
fundamentally difficult as it breaks the offer/answer model that a
regular RTP/SDP client (including rtpengine) expects. While rtpengine
could theoretically handle this, it's not something that is currently
implemented nor supported.

Cheers

[Aditya Uppuluri]

Sorry. if i created any confusion. It's an offer/answer model itself. 
The bridging between these two calls happen in another B2BUA. So it sends 200OK (answer) for client's INVITE (offer) and 200OK (answer) for asterisk's invite (offer). But it is not' doing transcoding. So it's sending 96 payload type in 200OK to client and 101 to asterisk. 

Thank you

[Richard Fuchs]

On 20/07/2022 12.01, [EXT] Aditya Uppuluri wrote:
> Sorry. if i created any confusion. It's an offer/answer model itself.
> The bridging between these two calls happen in another B2BUA. So it
> sends 200OK (answer) for client's INVITE (offer) and 200OK (answer)
> for asterisk's invite (offer). But it is not' doing transcoding. So
> it's sending 96 payload type in 200OK to client and 101 to asterisk.

Ok, but the offer/answer doesn't happen between the two clients that end
up exchanging media. The usual solution would be to trigger a final
re-invite between the two clients (client <> Asterisk) from the B2Bua,
let them do a full offer/answer negotiation between themselves, and
remove the B2Bua from being involved in the SDP handshake (i.e. just
pass the SDPs through). One side would then see a change in payload
types, but that shouldn't be a problem for a well behaved client, and in
theory that should allow them to settle on one single payload type
number for DTMF (among other things that are negotiated via SDP exchanges).

Either way I don't think rtpengine can help here at the moment. It can
do transcoding, sure, but only when in the path of a proper offer/answer
exchange, and not in between two separate offer/answer exchanges. What
you're looking for is not transcoding. You're looking to a solve an SDP
negotiation problem.

Cheers

[Aditya Uppuluri]

Understood. Thanks for the clarification. Let me see if i can remove B2BUA from media path by re-invite.