[QUESTION]PCMA vs PCMU for 2-way audio issue with alexa

[henryChmn]

"From Amazon:

An additional item that we wanted to discuss is support for PCMA vs PCMU. We plan on modifying the offer to you to include the following:

m=audio 1 UDP/TLS/RTP/SAVPF 96 0 8

This line flags that we are supporting PCMA. Today you are accepting an offer from us that flags PCMU returning you support PCMU but actually sending PCMA packets. I am assuming this change is at the Climax end but we should have this as another item that needs to come in the firmware prior to 12/2 date."

We not sure this requirement, as we think this are belong SDK behavior: https://github.com/awslabs/amazon-kinesis-video-streams-webrtc-sdk-c/blob/c279625baa130fc2902955ee93ecd73de8aef6b3/src/source/PeerConnection/PeerConnection.c#L1124-L1128

Do we still need to do some implement in current sample code for this requirement?

Thanks Logging Add relevent SDK logging. IMPORTANT NOTE: Please make sure to NOT share AWS access credentials under any circumstance! Please make sure they are not in the logs.

Any design considerations/constraints Explain in detail how you would like to integrate our SDK into your solution

If you would not like to open an issue to discuss your solution in open-platform, please email your question to kinesis-video-support@amazon.com

[hassanctech]

I'm a bit confused here not sure where that quote is coming from.

I want to understand the issue you're having so is it that the offer/answer negotiation settles on PCM mu-law for the audio codec but the packets you're receiving are encoded with PCM a-law?

I suspect this is an issue with your media pipeline. Look at this: https://github.com/awslabs/amazon-kinesis-video-streams-webrtc-sdk-c/blob/master/samples/Common.c#L436

This specifies for our sample application the codec for the audio track. In your application when you set the audio codec perhaps you're setting PCMU, but the actual audio is PCMA. In this case the offer/answer negotiation may end up with PCMU but since the underlying audio in that track is PCMA, that is what will be set. You need to make sure the audio track codec specific is actually the one being produced by your media pipeline.

[jonescx]

@hassanctech We've already modified the common.c and replaced RTC_CODEC_OPUS by RTC_CODEC_ALAW (please refer the attached image). When we use the chrome webrtc test webpage, there is NO problem to use our current setting to send audio to viewer and receive audio from the webpage. The problem only happens on echo show which identifies our device supports both PCMA and PCMU during the negotiation. However, we have no idea how to let echo show know we don't support PCMU.

[hassanctech]

Ok so if I understood correctly the answer is coming from your device (master) and the echo show is a viewer (produces the offer), correct? If this is the case, can you please share the offer and answer? The offer should contain the supported codecs so whatever is present there is fair game for the answerer side to choose.

[jonescx]

Yes, you are right. Our device is the master and webpage or echo show are viewers. Here is the debug log for two different viewer connection. First is test web page and second one is the echo show. You can tell them from the client id that echo show uses "echoshow" as prefix, such as "echoshow645" in the attached file. BTW, the message is cut if its length is over 4096.

aws_client0.log

[hassanctech]

The offfer/answer SDP are not present here, can you please do:

export DEBUG_LOG_SDP=TRUE

So we can see the offer/answer SDP?

[jonescx]

@hassanctech Here is the log with DEBUG_LOG_SDP=TRUE aws_client0_sdp.log

[hassanctech]

I see there is no rtpmap or fmtp attributes included in the offer/answer, these are required in the SDP. We will investigate to see what could have caused them to be excluded from the offer.

[MushMal]

Any update on this issue?

[MushMal]

Resolving as stale. Please cut a new issue with all of the details.

[MushMal]

Some context:

_Alexa sends SDP offer with PCMU/Opus App sends SDP answer with PCMU

Actual audio over the media connection is PCMA.

On Alexa side, we will start returning an SDP offer with PCMU/PCMA/Opus, and as such the following should happen:

Alexa sends SDP offer with PCMU/PCMA/Opus App sends SDP answer with PCMA

Actual audio over the media connection is PCMA

When we did make the above change, we did not get back PCMA from SDP despite the media connection sending us PCMA. Instead, we received PCMU in the SDP._

[henryChmn]

@MushMal This ticket fixed by modify WebRTC codec supported with RTC_CODEC_MULAW format in our application. Thanks

[henryChmn]

close this ticket