Direct Media

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.

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

• Configuring Direct Media Between Endpoints Behind Same NAT
• Configuring Direct Media Between Endpoints Behind Different NAT
• Configuring Direct Media Between Endpoints Behind NAT and Non-NAT Endpoint

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

% 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

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

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

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 causes the SBC to exhibit SIP proxy-like behavior wherein signaling passes through the SBC, and media directly flows between endpoints or between the endpoint and egress gateway.

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 the SBC and GSX, the media zone in the GSX must be named "INTERNAL" and directmediaGroupid parameter in the SBC must be set to "0". Any action taken by the 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 the 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 sets 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 the Peer's SDP instead of the SBC's SDP.

SIP-GW-SIP

Direct Media SDP Information on Incoming INVITE to Outgoing INVITE

In a direct media call, the SBC  changes the SDP parameters (such as packet size) while sending out direct media SDP which results in a call failure. To overcome this limitation, the SBC is enhanced to remove any default value SDP parameters (if it is not correct) added by the SBC in direct media basic DM, DM Anti trombone and DM Xdmi calls. The SBC identified the SDP parameters (such as  packet size) values that the SBC is modifying to default or based on configured value, while sending Direct Media Sdp parameters in outgoing INVITE. Currently, Direct Media SDP Information on Incoming INVITE to Outgoing INVITE in not fully supported for GW-GW Direct Media calls.

In the direct media call, the SBC adds the default/configured parameters in outgoing SDP and does not pass the exact incoming SDP as direct media, in an outgoing SDP. Neither the ingress and nor the egress leg have the same protocol (one leg is SIPS protocol and other leg is H323 protocol).

For example:

In this case, the SBC does not copy the exact content of SDP of the incoming INVITE from End Point 1 and add the copied SDP on the outgoing INIVTE toward End Point 2. Almost all the portions are copied, but the SBC adds the extra lines based on the default configuration.

End Point 1(Orig)/End Point 2(Term) — <TLS/SRTP> — <SBC> — <SIP/RTP/G711> — <C5 Registration>

As defined in the example, where the content of SDP in the incoming INVITE is not copied in the outgoing INVITE.

<Incoming INVITE>
 v=0
 o=- 3727161348 3727161348 IN IP4 110.163.224.115
 s=-
 c=IN IP4 110.163.224.115　　<===
 t=0 0
 m=audio 4000 RTP/SAVP 120  <===
 c=IN IP4 110.163.224.115  <===
 a=sendrecv
 a=rtpmap:120 opus/48000/2 <===
 a=fmtp:120 useinbandfec=1 <===
 a=crypto:1 AES_256_CM_HMAC_SHA1_80 inline:uUDYq/NwP1KFCtogteM0UygvJHiCSaUHJYrXvBewe1ESnJGUkjh2ldWdCyyJ7w==
<Outgoing INVITE>
 v=0
 o=Sonus_UAC 444391 744030 IN IP4 192.168.0.2
 s=SIP Media Capabilities
 c=IN IP4 110.163.224.115  <===
 t=0 0
 m=audio 4000 RTP/SAVP 120  <===
 a=crypto:1 AES_256_CM_HMAC_SHA1_80 inline:uUDYq/NwP1KFCtogteM0UygvJHiCSaUHJYrXvBewe1ESnJGUkjh2ldWdCyyJ7w==
 a=rtpmap:120 opus/48000/2  <===
 a=fmtp:120 minptime=10; useinbandfec=1; maxaveragebitrate=510000  <===
 a=sendrecv
 a=ptime:150  <===
 a=rtcp:4001  <===

This features identifies and removes the default/configured media parameters added by the SBC in direct media when sending the direct media SDP parameters in outgoing INVITE.

The SDP parameters whose default value is added in the direct media SDP include, but not limited to:

• rtcp (port)
• codec parameters minptime.
• codec parameters maxavaragebitrate

The SBC SDP functions include:

• Storing the appropriate SDP content (c-line, m-line, a-line) on the incoming INVITE
• Adding the stored SDP content on the outgoing INVITE
• Supporting this function on both, direct media and antiTrombone
• Supporting for SRTP