Non fatal error in log: No supported output codec found in SDP

[Den4t]

Hi !

With using T38 transcoding i have permanent non fatal error in log:

No supported output codec found in SDP

In my call flow "A" side always offer T38 capability in SDP, but some of "B" side have

refuse T38, so i use transcoding to PCM with rtpengine. In fact 

T38 stream never work, just using this theme only for codec ngotiation,

which, I must say, happens correctly.

I use:

Ubuntu 18.04.6 LTS

rtpengine 9.5.5.0+0~mr9.5.5.0 git-mr9.5-aadf5995

call log in attachment.

What can cause this error ?

Thanks !

[Richard Fuchs]

On 20/09/2022 10.59, [EXT] Den4t wrote:
> Hi !
>
> With using T38 transcoding i have permanent non fatal error in log:
> No supported output codec found in SDP
>
> In my call flow "A" side always offer T38 capability in SDP, but some
> of "B" side have
> refuse T38, so i use transcoding to PCM with rtpengine. In fact
> T38 stream never work, just using this theme only for codec ngotiation,
> which, I must say, happens correctly.
>

The answer SDP rejects the second media section (second `m=` line) by
setting the port to zero and using a bogus codec number:

Sep 20 15:24:35 sbc3 rtpengine[5128]: m=audio 0 RTP/AVP 19

This is valid usage and rtpengine probably shouldn't complain about it.

As for T.38 itself, the original offer is using an SDP with two media
sections, one for PCM audio and one for T.38:

Sep 20 15:24:35 sbc3 rtpengine[5128]: m=audio 21432 RTP/AVP 8 0 96
Sep 20 15:24:35 sbc3 rtpengine[5128]: m=image 50000 udptl t38

Using `T.38=decode` instructs rtpengine to decode the T.38 section to an
audio section, leaving you with an SDP with two audio sections:

Sep 20 15:24:35 sbc3 rtpengine[5128]: m=audio 41920 RTP/AVP 8 0 96
Sep 20 15:24:35 sbc3 rtpengine[5128]: m=audio 41932 RTP/AVP 0 8

This in turn leads to the B side rejecting the second audio section.

This type of dual-media SDP (one audio media, one T.38 media) to offer
T.38 unfortunately isn't supported by rtpengine right now. The use cases
for T.38 we've seen so far have always been an initial audio offer (one
audio media section), which is then followed by a re-invite to T.38
(again with just one media section) after the fax signal has been detected.

Supporting this type of dual-media offer shouldn't be too difficult
though, so pull requests welcome.

Cheers

[Den4t]

Hi, Richard !

This type of dual-media SDP (one audio media, one T.38 media) to offer
T.38 unfortunately isn't supported by rtpengine right now. The use cases
for T.38 we've seen so far have always been an initial audio offer (one
audio media section), which is then followed by a re-invite to T.38
(again with just one media section) after the fax signal has been detected.

Agree with you, initial T.38 capability is some exotic, re-invite is more generally accepted,
but this is a specific оf only one customer. In any case, nothing fatal happens.

Thanks for the clarification.

вторник, 27 сентября 2022 г. в 16:14:14 UTC+3, Richard Fuchs: