Media Type Subnames
You can define multiple versions of a media profile for a single codec by using the subnames feature. You can then reference the new media profile by a combination of the media profile name and media profile subname.
Some media types are not unique per just their value in an SDP m= line, they must be uniquely identified by looking at additional SDP parameters. For example, you can define a media profile for G729, when only the parameter and value annexb=yes is present in the SDP. By creating a media profile + subname that defines both a media type and parameter, you can perform various operations on G729 only when annexb=yes is encountered.
Some applications of media type subnames are:
- maintaining different versions of the same codec with different bandwidth ceilings
- maintaining different versions of the same codec with different ptimes
- grouping codecs by using customer as a subname
- grouping codecs by using realm as a subname
SDP Parameter Matching
This feature matches parameters in the a=fmtp, codec-specific SDP a= line. It does not try to match a global m= line attribute like a=ptime.
Using Subnames with Codec Policies
Media profiles are defined and referenced in the ACLI by a name and subname in the following format
<name>::<subname>
If no subname has been created for a media profile, you may continue using the media profile name without any subname specifier.
For example, to remove a media profile and subname configured as PCMU::customer1 from all SDP entering the egress realm, you would configure the codec policy allow-codecs parameter as follows:
allow-codecs PCMU::customer1:no
media-profile subtype Configuration Restrictions
media-profiles are subject to stringent configuration restrictions. You must avoid creating a media-profile with configured subtype parameter that does not substantively differ (in all additional parameters) from the default (unconfigured) media profile. An example of an invalid configuration is media-profile, name of g729, and a media-profile, subname of g729, with no additional parameter configurations other than the default values. Such configuration can cause unexpected behaviors and must be avoided.
Subname Syntax With the Wildcard Character
You can use the wildcard character in one or both portions (name and subname) of a media type and subname pair:
- When you use the wildcard character the name portion of the value, you can provide a specific subname that the Oracle Communications Session Border Controller (SBC) uses to find matching media profiles.
- When you use the wildcard character in the subname portion of the value, you can provide a specific name that the SBC uses to find matching media profiles.
The following table defines and explains using a subname with the wildcard character and shows the syntax:
Syntax | Example Value | Description |
---|---|---|
<name> | PCMU | Matches any and all media profiles with the name value configured as PCMU. This entry has the same meaning as a value with this syntax: <name>::*. |
<name>:: | PCMU:: | Matches a media profile with the name with the name value configured as PCMU with an empty subname parameter. |
<name>::* | PCMU::* | Matches any and all media profiles with the name value configured as PCMU with any and all subname configured. |
<name>::<subname> | PCMU::64k | Matches a media profiles with the name with the name value configured as PCMU with the subname parameter set to 64k. |
* | * | Matches anything, but does not have to be a defined media profile. |
*::* | *::* | Matches any and all media profiles, but requires the presence of media profile configurations. |
*::<subname> | *::64k | Matches all media profiles with this subname. You might have a group of media profiles with different names, but the same subname value. |
*:: | *:: | Matches any media profiles with an empty subname parameter. |
:: | :: | Invalid |
::* | ::* | Invalid |
Wildcard Character in add-codecs-on-egress Limitation
It is important to note that you may not configure add-codecs-on-egress with a wildcard character in a subname in a codec policy. You may only add a specific instance of a media type.
Valid:
add-codecs-on-egress PCMU
add-codecs-on-egress PCMU::customer1
Invalid:
add-codecs-on-egress PCMU::*
Configure Media Type and Subname
To use media type subnames with a codec policy, you must first configure a media profile and subname. Then you can configure a codec policy with a media type and subname pair for your application
To use configure a media type and subname:
Configure a Codec Policy with a Media Type with a Subname
To configure a codec policy with a media type with subname:
Updating the b=AS line for Transcoded Calls
The Oracle Communications Session Border Controller (SBC) can evaluate transcoding call scenarios and mitigate between end stations and policy servers to request appropriate bandwidth. You can configure a specific value to be included in the SDP's b=AS line to ensure that it requests the correct bandwidth for transcoded calls. Depending on the transcoding scenario, this value may or may not be used.
The SBC can change the egress answer b=AS line in a call to a value based on the media profile configuration of the codec to which the media is being transcoded. This ensures that the SBC makes bandwidth requests that are applicable to the leg on which that codec is used.
Use the following syntax to specify 124 kbps for the b=AS line a in media profile.
(media-profile)#as-bandwidth 124
The default value is zero, meaning it is disabled. The range is from 0 to 4294967295, measured in kbps.
The SBC can modify a b=AS: line at both the SDP media level and SDP session level. Session level b=AS modification does not use an as-bandwidth setting.
The SBC updates a media level b=AS: line to the configured as-bandwidth value only for the Egress SDP Answer, not the offer.
The SBC modifies a session level b=AS: value only if every m-line in the SDP also has a b=AS: value. When an incoming message has SDP with a session level b=AS value, and every m-line in the SDP has a b=AS value, then the SBC updates the outgoing message session level b=AS value to the sum of the transcoding/IPv4-IPv6 adjusted media level b=AS values in the outgoing message. When an incoming message has SDP with a session level b=AS value, but not every m-line in the SDP has a b=AS value, the SBC does not modify the session level b=AS value in the outgoing message.
When the SBC updates a b=AS: line in the egress answer's SDP to a configured as-bandwidth value, and the original ingress offer SDP already had a b=AS: line, the SBC changes the egress answer SDP's b=AS: back to the ingress offer's b=AS: value, not to the configured as-bandwidth value.
Important operational considerations include:
- The value can be understood as IP neutral, meaning the system recognizes when the call is IPv4 to IPv6 interworking, and adjusts the value of the b=AS line to compensate for the IP version of the applicable leg. The SBC does this for both transcoded and non-transcoded calls in both the egress offer and answer.
- The configuration has no effect when the initial message received has no b=AS line.
- The configuration has no effect when the m line is not transcoded.
- The system does not change a session b=AS value when the SDP has a media line with b=AS value of 0.