SmartMedia: SDP profile configuration guidelines
Posted by Michal Podoski, Last modified by Danny Staub on 15 November 2017 02:50 PM
You can specify the Profile SDP Description to define which voice codecs are supported in the NAP using this Profile.
Here is the default Profile SDP Description.
m=audio 0 RTP/AVP 0 8 4 96 97 18 98 13 a=rtpmap:96 iLBC/8000 a=rtpmap:97 iLBC/8000 a=fmtp:97 mode=20 a=rtpmap:98 telephone-event/8000
Each line of the Profile SDP Description consists of text of the form <type>=<value>. <type> is always exactly one character and is case-significant. <value> is a structured text string whose format depends on <type>. It also will be case-significant unless a specific field defines otherwise. Whitespace is not permitted either side of the '=' sign. In general <value> is either a number of fields delimited by a single space character or a free format string.
In our Profile SDP Description, only 2 types of <type> field are used:
The format of media announcement is as follows.
The payload type, which is carried in the actual RTP packet header, is used to identify the type of codec information carried in the packet. A list of payload type values for each codec is defined within RFC3551. Unfortunately, since the payload type field is only 7 bits-wide, all codecs cannot have a permanent payload type value understood universally by all VoIp systems. Therefore, some codecs have dynamic values that need to be negotiated through a call control or session control protocol such as SIP before the actual RTP session can take place.
Here is the list of codec payload type values per RFC3551.
When you use dynamic payload types, you need to specify the additional encoding information using the attribute for media announcement.
Attribute for Media Announcement
A media description may have any number of attributes ("a=" fields) which are media specific. The format of attribute is as follows.
Here are some examples of attributes.
Dynamic payload type
You specify the additional encoding information for dynamic payload type in the following format:
a=rtpmap:<payload type> <encoding name>/<clock rate>[/<encoding parameters>]
For audio streams, <encoding parameters> may specify the number of audio channels. This parameter may be omitted if the number of channels is one provided no additional parameters are needed.
Other media specific attribute
The use of other media specific attributes depends on the specification of the RTP payload format for the specific media type. Here are some example of attributes.
This attribute allows parameters that are specific to a particular format to be conveyed in a way that SDP doesn't have to understand them. The format must be one of the formats specified for the media. Format-specific parameters may be any set of parameters required to be conveyed by SDP and given unchanged to the mediatooll that will use this format.
This gives the length of time in milliseconds represented by the media in a packet. This is probably only meaningful for audio data. It should not be necessary to know ptime to decode RTP, and it is intended as a recommendation for the encoding/packetisation of audio. It is a media attribute, and is not dependent on charset.
Here are some examples of the attributes found in the default profile SDP description.
a=rtpmap:97 iLBC/8000 a=fmtp:97 mode=20
The above defines iLBC codec of 8000/sec sample rate with 20ms frame size.
The above defines the DTMF relay using RFC2833.
Here is another example, enabling Voice Activity Detection (VAD) for G.711 ulaw, G.711 alaw, G.723.1a and G.729b, in addition to telephony events.
m=audio 0 RTP/AVP 0 8 4 18 98 13 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:4 G723/8000 a=fmtp:4 bitrate=6300;annexa=yes a=rtpmap:18 G729/8000 a=fmtp:18 annexb=yes a=rtpmap:98 telephone-event/8000 a=fmtp:98 0-15 a=rtpmap:13 CN/8000
Another example to disable silence suppression explicitly in the SDP.
m=audio 0 RTP/AVP 0 8 101 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=silenceSupp:off - - - -
Below is a direct SIP INVITE with T.38. This can be useful if you know this route will always be with fax. It also doesn't require any IVR resources to detect the fax tones:
m=image 0 udptl t38 a=T38FaxVersion:0 a=T38MaxBitRate:14400 a=T38FaxFillBitRemoval:0 a=T38FaxTranscodingMMR:0 a=T38FaxTranscodingJBIG:0 a=T38FaxRateManagement:transferredTCF a=T38FaxMaxBuffer:400 a=T38FaxMaxDatagram:400 a=T38FaxUdpEC:t38UDPRedundancy