Codec payloads

Related specifications

  • AMR-NB

    • 3GPP TS 26.090, AMR Speech Codec; Transcoding Functions, available at http://www.3gpp.org/

    • RFC 4867, RTP Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs, available at http://www.ietf.org/

  • AMR-WB

    • 3GPP TS 26.190, Wideband (AMR-WB) speech codec; Transcoding Functions, available at http://www.3gpp.org/

    • RFC 4867, RTP Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs, available at http://www.ietf.org/

    • G.711 (PCMA/PCMU)

    • ITU-T G.711 Appendix I, available at http://www.itu.int

    • ITU-T G.711 Appendix II, available at http://www.itu.int

    • RFC 3551, RTP Profile for Audio and Video Conferences with Minimal Control, available at http://www.ietf.org/

    • RFC 4855, Media Type Registration of RTP Payload Formats, available at http://www.ietf.org/

    • RFC 4856, Media Type Registration of Payload Formats in the RTP Profile for Audio and Video Conferences, available at http://www.ietf.org/

  • G.729

  • G.726

    • ITU-T G.726, available at http://www.itu.int

    • RFC 3551, RTP Profile for Audio and Video Conferences with Minimal Control, available at http://www.ietf.org/

    • ITU-T I.366.2, AAL type 2 service specific convergence sublayer for trunking, available at http://www.itu.int

    • RFC 4855, Media Type Registration of RTP Payload Formats, available at http://www.ietf.org/

    • RFC 4856, Media Type Registration of Payload Formats in the RTP Profile for Audio and Video Conferences, available at http://www.ietf.org/

  • iLBC

  • GSM-FR

  • GSM-EFR

    • 3GPP TS 46.060, Enhanced Full Rate (EFR) speech transcoding, available at http://www.3gpp.org/

    • RFC 3551, RTP Profile for Audio and Video Conferences with Minimal Control, available at http://www.ietf.org/

Implementation notes

  • AMR-NB and AMR-WB:

    • Payload format does not support UEP or UED. (Section 3.6.1, RFC 4867.) This means that frame CRCs are not supported also. (Section 4.4.2, RFC 4867.)

    • RTP Packets containing NO_DATA frames only are not sent. NO_DATA frame blocks that contain NO_DATA at the end of an RTP packet are sent. (Section 4.3.2, RFC 4867.) The implementation does support receiving packets consisting of NO_DATA frame blocks only (for example, between SID_UPDATEs).

    • Payload format supports single or double redundancy (AMR FEC) only. (Section 3.7.1, RFC 4867.)

    • The following MIME parameters are supported and can be negotiated: octet-align, mode-set, mode-change-period, mode-change-neighbor, ptime, maxptime, and max-red.

    • The following MIME parameters are neither supported nor accepted in negotiation: crc, robust-sorting, interleaving, and mode-change-capability.

    • The following MIME parameters have a restricted set of values that can be negotiated: channels; single channel payload is supported (channels=1) and used by default if omitted in negotiation, and max-red; see the following table for the restrictions:

      SDP offer

      FEC defined in the provisioned VoIP settings

      FEC not defined in the provisioned VoIP settings

      Mobile Originated

      max-red is ptime multiplied by FEC. [54] defines the highest value for max-red as 220. If ptime multiplied by FEC exceeds 220, FEC will be set to 0 for that codec. If ptime is not defined in the settings, max-red is given the default ptime value of 20.

      max-red is not advertised in the offer.

      Mobile Terminated

      If the received values for max-red and ptime are the same and the corresponding value has been defined for ptime in the settings, max-red is given the received value in the SDP answer.

      If the received value of ptime does not correspond with the received value of max-red or the value of ptime in the settings, max-red is set to 0 in the SDP answer.

      If ptime is not present in the received offer, max-red is given the default ptime value of 20 in the SDP answer.

      If max-red is present in the received offer, it is set to 0 in the SDP answer. If max-red is not present in the offer, it will not be present in the answer.

  • G.711:

    • DTX is supported with Generic Comfort Noise (CN) on the sender side. (Section 4.1, RFC 3551.)

    • G.711 payload format are supported. (Section 4.5.14, RFC 3551.)

    • The following MIME parameters are supported and can be negotiated: ptime, multiples of 10ms are supported, and maxptime.

  • G.729:

    • DTX is supported with G.729 Annex B on the sender side. (Section 4.1, RFC 3551.)

    • G.729 payload formats G.729, G.729A, and G.729 Annex B are support. (Section 4.5.6, RFC 3551). Other G.729 versions are not supported.

    • The following MIME parameters are supported and can be negotiated: ptime; multiples of 10ms are supported, maxptime, and annexb, value yes is implied if this parameter is omitted in negotiation.

  • G.726:

    • DTX is supported with Generic Comfort Noise (CN) on sender side. (Section 4.1, RFC 3551.)

    • Support for G.726 payload format as specified in Annex E of ITU-T I.366.2 or Section 4.5.4 of RFC 3551 depends on the provisioned VoIP settings, which are defined in the Nokia Asha Java VoIP API v1.0 VoIP Settings Configuration Tutorial.

    • All bitrates are supported, MIME subtypes: G726-16, G726-24, G726-32, and G726-40.

    • The following MIME parameters are supported and can be negotiated: ptime, multiples of 10ms are supported, and maxptime.

  • iLBC:

    • DTX is supported. (Section 4.1, RFC 3551.)

    • iLBC payload format is supported (RFC 3952).

    • The following MIME parameters are supported and can be negotiated: ptime, maxptime, and mode, the 30ms mode (mode=30) is used by default if omitted in negotiation.

  • Payload types:

    • Codecs having dynamic payload types will be numbered in ascending order starting from 96 (that is 96, 97, 98 and so on) according to the order of codecs in the phone’s provisioned VoIP settings, with the exception that the Telephone-event is given the last value.