In this section:

Related articles:

Direct Media Behind NAT and Non-NAT Devices

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.

For the SBC to support direct media between NAT and non-NAT endpoints, the NAT router used in the call must have SIP Application Level Gateway (ALG) functionality for the media to flow between end points.

To allow Direct Media between NAT devices, or between NAT and Non-NAT devices, the following configuration is necessary.

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.

Configuring Direct Media Between Endpoints Behind the Same NAT

ACCESS SIDE:

  • At Sip Trunk Group Level
    • directMediaAllowed enabled
    • directMediaAllowedBehindNat enabled
  • At Packet Service Profile Level
    •  useDirectMedia enabled

CORE SIDE (towards Application Server):

  • At IPSP Level
    • sendDirectMediaInfoInSdpAttribute enabled
  • At Packet Service Profile Level
    • useDirectMedia enabled

The dmNatPrefix table is not required to create as the endpoints are behind the same NAT.

Configuring Direct Media Between Endpoints Behind the Different NAT

 ACCESS SIDE:

  • At Sip Trunk Group Level
    • directMediaAllowed enabled
    • directMediaAllowedBehindNat enabled
    • sdpTransparencyState disabled
  • At Packet Service Profile Level
    • useDirectMedia enabled

CORE SIDE (towards Application Server):

  • At IPSP Level
    • sendDirectMediaInfoInSdpAttribute enabled
  • At Packet Service Profile Level
    • useDirectMedia enabled
  • 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.

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 enabled
    • directMediaAllowedBehindNat enabled
    • sdpTransparencyState disabled
  • At Packet Service Profile Level
    • useDirectMedia enabled

CORE SIDE (towards Application Server):

  • At IPSP Level
    • sendDirectMediaInfoInSdpAttribute enabled
  • At Packet Service Profile Level
    • useDirectMedia enabled
  • 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:

% 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:

% 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.

Direct Media Behind NAT Flow

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).

Direct Media is not supported for H.323-H.323 or H.323-SIP calls involving Video.

Secured RTP is not supported for H.323.

% 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.

IAD-to-IAD Calls

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.

IAD to IAD with Direct Media

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).

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.

GW to GW Calls

The SBC also supports the following Direct Media functionality in both Access and Peering scenarios:

  • SIP Gateway-to-SIP Gateway

  • SIP Gateway-to-GSX

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.

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.

Deployment Model 1: SIP-GW-GW-GSX

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.

SIP-GW-GW-GSX

Deployment Model 2: SIP-GW-SIP

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.

SIP-GW-SIP

  • No labels