Ignoring a codec from caller while still using it for transcoding with callee

[Anton Olofsson]

So I have a setup where a PSTN caller, Alice, offers G722, PCMA, PCMU, and Bob, in our internal VoIP environment, speaks nothing but OPUS. I have a Kamailio+rtpengine in the middle for transcoding, which is working great.

Some times another caller from the PSTN, Charlie, comes along and offers OPUS, G722, PCMA, PCMU, even though he clearly doesn't understand OPUS.

Thus, I'm trying to figure out if there's a way to ignore Charlie's OPUS offering while still speaking OPUS with Bob. I don't know if I'm doing something wrong, but I can't seem to figure out how to get the final 200 OK back to the caller to not use OPUS.

My most recent attempt in the kamailio.cfg look something like this:
When processing the incoming offer
rtpengine_offer("codec-strip=opus codec-transcode=opus codec-accept=G722 codec-accept=PCMA codec-accept=PCMU");

And then in onreply_route
rtpengine_answer("codec-strip=opus");

My reasoning for the above goes as follows:

1. strip+transcode opus according to this special case.
2. accept codecs which we want to allow the caller to use according to this.
3. strip opus again on the way out in order to make it unavailable as an option when replying to the caller.

Is this entirely misguided? Very appreciative of any pointers.

/Anton Olofsson

[Richard Fuchs]

This is a scenario that isn't really explicitly supported, but intuitively the first thing I would try (and I haven't actually tried this myself) is to set "codec-accept-all" in the offer (or selectively accept just the codecs you may want to use towards Charlie) and then set "codec-strip-opus" in the answer. This should (and again this is off the top of my head) mark the codecs towards Charlie for transcoding, and then leave only non-Opus codecs usable in the answer.

So more or less what you have already. The strip/transcode combination shouldn't be necessary I think, unless you want to influence the order/priority of the codecs, and/or make sure that Opus is actually present in the offer.

Make sure you use a recent version though (11.5 should be good) as older versions of rtpengine are a bit dumber when it comes to codec negotiations, and may not support all the options.

Cheers

[Anton Olofsson]

We have managed to solve these calls while still using opus, but I figured I'd get back to you with my results from trying to exclude it (although I wouldn't swear on any of it as there were a lot of pcaps flying around yesterday and I'm just now trying to piece it all together).

I tried this using 12.0.1.1, 11.5.1.13 and 10.5.5.5, but it did not seem to be possible to solve this case. Using "codec-accept-all" in the offer and "codec-strip-opus" in the answer resulted in a final 200 OK towards Charlie without any payload types in the media description ("m="), although opus and telephone-event was still included in the session attributes ("a="), as you can see in the example SDP below:
v=0
o=user1 1699415672 1699415673 IN IP4 xx.xx.xx.xx
s=-
c=IN IP4 yy.yy.yy.yy
t=0 0
m=audio 23078 RTP/AVP 107
a=rtpmap:107 opus/48000/2
a=fmtp:107 stereo=1; useinbandfec=1
a=sendrecv
a=rtcp:23079
a=ptime:20