AMR-WB bit packing format (IF1 and IF2) specification

HI Chris,

The TI AMR-WB also supports storage format called as GSMWBAMR_MMS_IO_FORMAT, which is the storage format defined in RFC4867 (earlier it is RFC3267).

The supported packing formats with TI GSMWBAMR are 1) GSMWBAMR_IF1_FORMAT_NO_CRC (2) GSMWBAMR_IF1_FORMAT_WITH_CRC (3) GSMWBAMR_IF2_FORMAT and (4) GSMWBAMR_MMS_IO_FORMAT

Please let us know what is the exact problem you are facing?

-Venkat

Venkat,

The problem I am facing is that the TI AMR-WB codec don't seem to be compatible with the AMR-WB codecs used on the softphones I am testing with. From capturing and analyzing pcap files, the softphones appear to be using the RTP payload formats defined in RFC4867. One uses the bandwidth efficient mode and the other uses the octet aligned mode. The TI codec on the other hand uses the formats defined in the 3GPP spec for bandwidth efficient mode and octet aligned mode and uses the RFC spec for the storage format as you mentioned. I had thought that IF1 corresponded to bandwidth efficient mode and IF2 corresponded to octet aligned mode, but it looks like this is only in the 3GPP spec and not in the RFC spec. Originally I had misunderstood what the IF1 and IF2 settings for the TI codec corresponded to. 

Is there any support from TI for the RTP payload formats (bandwidth efficient and octet aligned) defined in RFC4867?

Thanks,
Chris

Hi Chris,

Yes. TI AMR-WB implementation supports IF1/IF2 payload formats as per 3GP spec and the storage format (MMS-IO) is as per RFC.

However, the Codec doesn't fill and output the header, it only outputs speech frames. The storage format speech frames are same as the octet aligned-mode (RFC4867) speech frames. We can append the payload header to the codec output and make it compatible with RFC for Octet aligned mode. BW-efficient mode is not supported with TI codec.

-Venkat

Venkat-

Could we manually modifiy a TI AMR-WB codec generated octet aligned payload to be compatible with bandwidth efficient mode?  For example, remove padding bits...

Maybe this is not possible, but seems worthwhile to ask.  Thanks.

-Jeff
Signalogic

Jeff,

Yes. That could be an option, but tedious process, as we need to move all the bits that are following TOC.

-Venkat

Venkat,

Just to confirm,

For encode, if I take the output from the TI AMR-WB encoder using the MMS_IO format and add the 1 byte payload header to the beginning of the frame, it would be identical to octet aligned format as defined in RFC4867. The speech frame header for the storage formate would be identical to the frame header used in octet aligned RTP format with the exception of the first bit. If there is only one frame per payload though, then there would be no difference because that first bit would be 0 in both cases.

For decode, the payload header would just need to be skipped over. Potentially the first bit in frame header would need to be modified but if there's only one frame per payload then it doesn't need to be changed.

Does this all sound correct?

Chris

Venkat-

I don't see mention of MMS in RFC3267/RFC4867.  Other than IF1, can you clarify what support TI's AMR codecs have for those RFCs?  Thanks.

-Jeff

HI Chris, You are correct. First byte is the only difference between storage format and octect aligned mode of RFC.

-Venkat

Hi Jeff,

MMS is referred as Storage format in the RFC.

TI implementation supports IF1 with/without CRC, IF2, and MMS (Storage format as per RFC).

-Venkat

Venkat-

If you read through both RFCs (3267, 4867), MMS is not actually mentioned in any context.  MMS is only mentioned in the 3GPP spec.

This is not a problem for us, I just wanted to make it clear.  We're able to encapsulate the TI AMR codecs to support all payload format modes, including RFC-defined frame headers, bandwidth efficient mode, etc.

-Jeff

All-

To close this thread, we've implemented bandwidth efficient mode and other RFC4867 items not supported by TI's AMR codecs.  This is working fine.

-Jeff
Signalogic