The NAT Direct Media Group is a collection of public signaling IP addresses for NAT devices supporting Direct Media (DM). A NAT Direct Media Group name can be maximum of 32 characters. However, "0.0.0.0" (IPv4) and "::0" (IPv6) are not allowed.
Include Page |
---|
| DM_support_NAT_nonNAT |
---|
| DM_support_NAT_nonNAT |
---|
|
To allow Direct Media between NAT devices, or between NAT and Non-NAT devices, the following configuration is necessary.
Note |
---|
The configuration of Direct Media with NAT is not allowed under following conditions: - If the
addressContext name of both the endpoints does not match. - If the call is a Lawful Intercepted call.
|
Anchor |
---|
| Configuration for Direct Media Between Endpoints Behind Same NAT |
---|
| Configuration for Direct Media Between Endpoints Behind Same NAT |
---|
|
Configuring Direct Media Between Endpoints Behind the Same NAT
ACCESS SIDE:
- At Sip Trunk Group Level
directMediaAllowed
enableddirectMediaAllowedBehindNat
enabled
- At Packet Service Profile Level
CORE SIDE (towards Application Server):
- At IPSP Level
sendDirectMediaInfoInSdpAttribute
enabled
- At Packet Service Profile Level
Note |
---|
The dmNatPrefix table is not required to create as the endpoints are behind the same NAT. |
Anchor |
---|
| Configuration for Direct Media Between Endpoints Behind Different NAT |
---|
| Configuration for Direct Media Between Endpoints Behind Different NAT |
---|
|
Configuring Direct Media Between Endpoints Behind the Different NAT
ACCESS SIDE:
- At Sip Trunk Group Level
directMediaAllowed
enableddirectMediaAllowedBehindNat
enabledsdpTransparencyState
disabled
- At Packet Service Profile Level
CORE SIDE (towards Application Server):
- At IPSP Level
sendDirectMediaInfoInSdpAttribute
enabled
- At Packet Service Profile Level
- At Address Context Level
- Creating the table
dmNatPrefix
on addressContext
- Adding the signaling IP Address of NAT Box, which can have direct media among them.
Anchor |
---|
| Configuration for Direct Media Between Endpoints Behind NAT and Non-NAT Endpoint |
---|
| Configuration for Direct Media Between Endpoints Behind NAT and Non-NAT Endpoint |
---|
|
Configuring Direct Media Between Endpoints Behind the NAT and Non-NAT Endpoint
This is an occasional scenario where an endpoint behind NAT can have Direct Media with endpoint not behind NAT. However, if such a case exists, SBC exchanges the media IPs of such devices, while the actual exchange of media depends on the network.
ACCESS SIDE:
- At Sip Trunk Group Level
directMediaAllowed
enableddirectMediaAllowedBehindNat
enabledsdpTransparencyState
disabled
- At Packet Service Profile Level
CORE SIDE (towards Application Server):
- At IPSP Level
sendDirectMediaInfoInSdpAttribute
enabled
- At Packet Service Profile Level
- At Address Context Level:
- Creating
dmNatPrefix
on addressContext
- Adding signaling IP Address of,
- NAT Box
- Endpoint signaling IP not behind NAT.
The CLI syntax to enable Direct Media with NAPT on trunk group is the following:
Code Block |
---|
% set addressContext <name> zone <name> sipTrunkGroup <TG-Name> media directMediaAllowedBehindNapt <disable|enable> |
The CLI syntax to group the endpoint signaling IP addresses for which to allow Direct Media with NAPT is the following:
Code Block |
---|
% set addressContext <name> natDirectMediaGroup <groupName> dmNatPrefix <IpV4_Address> <prefixLen> |
A flow diagram of this behavior is depicted in the figure below. Please see CLI Reference Guide for command details and examples.
Caption |
---|
0 | Figure |
---|
1 | Direct Media Behind NAT Flow |
---|
|
Image Modified |
Note |
---|
For Direct Media calls (both audio and audio+video), the media does not flow through the SBC. However, SDP attributes need to be communicated to the endpoints. To accomplish this, enable the flag sdpAttributesSelectiveRelay at the Trunk Group level to relay the SDP attributes to the endpoints (see example CLI syntax below). |
Excerpt Include |
---|
| Video Support |
---|
| Video Support |
---|
nopanel | true |
---|
|
Code Block |
---|
|
% set addressContext default zone ZONE1 sipTrunkGroup PERFIPS_SBX_INT media sdpAttributesSelectiveRelay enabled |
For command details, refer to SIP Trunk Group - Media - CLI or SIP Trunk Group - Media (EMA) page.
Direct Media is intended for IAD-to-IAD calls where the SBC is positioned between each IAD and its registrar/application server whereby calls are set up between two endpoints so media is exchanged directly without consuming bandwidth to and from the SBC. The endpoints may be on the same IP subnet, in the same IP network, or on different IP networks. However, media packets from each IAD must be able to reach the other IAD without going through the SBC.
Caption |
---|
0 | Figure |
---|
1 | IAD to IAD with Direct Media |
---|
|
Image Modified |
Note |
---|
If the IADs share a common codec and do not need the SBC to transcode, then media flows directly between the IADs. |
SBC provides direct media support for SIP in the following scenarios:
- Intra-SBC—Both call legs must be in the same Direct Media Group Id.
- Inter-SBC—The endpoints of a call use different SBCs.
SBC supports the ability to perform media release and allows end points to have media flow directly between each other while signaling traverses the system.
When using Direct Media for IAD-to-IAD calls, the following parameters apply:
- Enable directMediaAllowed flag for both the ingress and the egress SIP trunk groups. This parameter specifies whether Direct Media is attempted for calls to/ from endpoints in the trunk group. If enabled, the SBC attempts to set up a media path such that media flows directly between two Direct Media-enabled endpoints in the same Zone.
- The directMediaGroupId parameter in both the ingress and egress SIP trunk groups must match. In an environment where calls pass through different SBCs, the directMediaGroupId assigned for the corresponding zones must match.
- The directMediaGroupId parameter in both Sip trunk groups (for the calling and called IADs) must match. Only calls spanning trunk groups with the same directMediaGroupId are eligible for Direct Media. In an environment where calls pass through different SBCs, the directMediaGroupId assigned for those zones must match.
- Enable Direct Media endpoints for all call legs (in both the Packet Service Profile facing the calling IAD and the called IAD, as well as the Packet Service Profiles facing the application server using the Use Direct Media flag in the Flags section).
- Enable Direct Media endpoints for all call legs associated with application server (in IP Signaling Profiles facing the application server using the Send Direct Media Info in SDP Attribute flag in the Common IP Attributes section).
Note |
---|
For Direct Media to function properly, the Application Server must not remove any SDP lines associated with unknown parameters. More specifically, if the Application Server receives an SDP with an unknown session-level attribute, it must pass this attribute and its value unchanged to the other leg. |
The SBC also supports the following Direct Media functionality in both Access and Peering scenarios:
In this model, the Direct Media feature requires SBC to exhibit SIP proxy-like behavior wherein signaling passes through SBC, and media directly flows between endpoints or between the endpoint and egress gateway.
Note |
---|
Direct Media can apply to both Access and Peering scenarios. |
Media Zone is a configurable parameter attached to a Gateway Trunk Group. If Media Zone of two legs is same, Direct Media is possible between the two legs.
If direct media is desired for GW-GW calls between SBC and GSX, the media zone in the GSX must be named "INTERNAL" and directmediaGroupid parameter in SBC must be set to "0". Any action taken by GSX gateway protocol legs related to RTP inactivity (such as call tear down) must be withheld for Direct Media calls because media does not flow through the SBC gateway leg.
Direct Media between SBC and GSX. Irrespective of the call leg on the egress GSX-2, we will be supporting direct media flow between ingress SIP peer and GSX-2 GW leg, provided media zone of GSX-2 and ingress peer is same. For this purpose, SBC-1 must publish the ingress peer's SDP to GSX-2 via GW protocol, so that GSX-2 sets its media peer as ingress SIP peer. Similarly GSX-2 must publish its ingress GW media IP and port back to SBC-1 so that SBC-1 can publish this as media IP and port in the SDP to ingress peer. Support for this deployment model has been available since GSX release 10.1.
Caption |
---|
|
Image Modified |
In this deployment, the SBC will set up a Direct Media call between two SIP endpoints with only signaling passing through the SBCs in SIP-GW-SIP model. For this purpose SBC-1 and SBC-2 must publish peer's media proposal (SDP) within GW protocol so that the respective SIP legs can offer or answer with Peer's SDP instead of SBCs.
Caption |
---|
|
|