The Connection-Oriented Media (Comedia) Enhancements for SIP feature provides the following feature to symmetric NAT traversal:

• Allows the Cisco gateway to check the media source of incoming (RTP) packets.

• Allows the endpoint to advertise its presence inside or outside of NAT.

NAT, which maps the source IP address of a packet from one IP address to a different IP address, has varying functionality and configurations. NAT can help conserve IP version 4 (IPv4) addresses, or it can be used for security purposes to hide the IP address and LAN structure behind the NAT. VoIP endpoints may both be outside NAT, both inside, or one inside and the other outside.

In symmetric NAT, all requests from an internal IP address and port to a specific destination IP address and port are mapped to the same external IP address and port. The feature provides additional capabilities for symmetric NAT traversal.

Prior to the implementation of connection-oriented media enhancements, NAT traversal presented challenges for both SIP, which signals the protocol messages that set up a call, and for RTP, the media stream that transports the audio portion of a VoIP call. An endpoint with connections to clients behind NATs and on the open Internet had no way of knowing when to trust the addressing information it received in the SDP portion of SIP messages, or whether to wait until it received a packet directly from the client before opening a channel back to the source IP:port of that packet. Once a VoIP session was established, the endpoint was, in some scenarios, sending packets to an unreachable address. This scenario typically occurred in NAT networks that were SIP-unaware.

In addition to the challenges posed by NAT traversal in SIP, NAT traversal in RTP requires that a client must know what type of NAT it sits behind, and that it must also obtain the public address for an RTP stream. Any RTP connection between endpoints outside and inside NAT must be established as a point-to-point connection. The external endpoint must wait until it receives a packet from the client so that it knows where to reply. The connection-oriented protocol used to describe this type of session is known as Connection-Oriented Media (Comedia), as defined in the IETF draft, draft-ietf-mmusic-sdp-comedia-04.txt, Connection-Oriented Media Transport in SDP .

Cisco IOS VoiceXML features implement one of many possible SIP solutions to address problems with different NAT types and traversals. With Cisco IOS VoiceXM, the gateway can open an RTP session with the remote end and then update or modify the existing RTP session remote address and port (raddr:rport) with the source address and port of the actual media packet received after passing through NAT. The feature allows you to configure the gateway to modify the RTP session remote address and port by implementing support for the SDP direction (a=direction:<role>) attribute defined in, draft-ietf-mmusic-sdp-comedia-04.txt, Connection-Oriented Media Transport in SDP . Valid values for the attribute are as follows:

• active--the endpoint initiates a connection to the port number on the m= line of the session description from the other endpoint.

• passive--the endpoint accepts a connection to the port number on the m= line of the session description sent from itself to the other endpoint.

• both--the endpoint both accepts an incoming connection and initiates an outgoing connection to the port number on the m= line of the session description from the other endpoint.

The feature introduces CLI commands to configure the following SIP user-agent settings for symmetric NAT:

• The nat symmetric check-media-src command enables checking the incoming packet for media source address. This capability allows the gateway to check the source address and update the media session with the remote media address and port.

• The nat symmetric role command specifies the function of the endpoint in the connection setup procedure. Set the role keyword to one of the following:

  • active --The endpoint initiates a connection to the port number on the m= line of the session description from the other endpoint.
  • passive --The endpoint accepts a connection to the port number on the m= line of the session description sent from itself to the other endpoint.

Note	The Cisco Comedia implementation does not support a=direction:both. If the Cisco gateway receives a=direction:both in the SDP message, the endpoint is considered active.

The following example shows a sample SDP message that describes a session with the direction:<role> attribute set to passive:

v=o
o=CiscoSystemsSIP-GW-UserAgent 5732 7442 IN IP4 10.15.66.43
s=SIP Call
c=IN IP4 10.15.66.43
t=0 0
m=audio 17306 RTP/AVP 0 100
a=rtpmap:0 PCMU/8000
a=rtpmap:100 X-NSE/8000
a=fmtp:100 192-194
a=ptime:20
a=direction:passive

The following call flow diagrams describe call setup during symmetric NAT traversal scenarios. The figure below shows a NAT device that is unaware of SIP or SDP signaling. The SIP endpoints are not communicating the connection-oriented media direction role in the SDP message. The originating gateway is configured, using the nat symmetric check-media-src command to detect the media source and update the VoIP RTP session to the network address translated address:port pair.

The figure below shows a NAT device that is unaware of SIP or SDP signaling, but the SIP endpoints are communicating the connection-oriented media direction role in the SDP message. The originating gateway is configured as a passive entity in the network using the nat symmetric role command. When the passive entity receives a direction role of active, it updates the VoIP RTP session to the network address translated address:port pair.

Note

Configuring the originating gateway for passive or active setting can differ from the NAT device setup. The SIP user agent communicates the CLI configured direction role in the SDP body. Checking for media packets is automatically enabled only if the gateway receives a direction role of active or both.

When renegotiating media mid call, such as when the call is moving from standard to T38 fax relay, the UDP ports used are often renegotiated on third-party endpoints. This new port is not recognized by the symmetric NAT feature.

The SIP: Multilevel Precedence and Priority Support feature enables Cisco IOS gateways to interoperate with other MLPP-capable circuit-switched networks. The U.S. Department of Defense (DoD) and Defense Information Service Agency (DISA) mandate that all VoIP network elements support this capability.

MLPP is a service that allows properly validated users to preempt lower-priority phone calls either to targeted stations or through fully subscribed shared resources such as time-division multiplexing (TDM) trunks or conference bridges. With this capability, high-ranking personnel are ensured communication to critical organizations and personnel during a national emergency.

Connections and resources that belong to a call from an MLPP subscriber are marked with a precedence level and domain identifier and are preempted only by calls of higher precedence from MLPP users in the same domain. The DSN switch sets the maximum precedence level for a subscriber statically. When that subscriber originates a call, it is tagged with that precedence level (if none is provided) or with one that the user provides.

Cisco IOS gateways act as transit trunking network elements to map incoming precedence levels to outgoing signaling. This does not provide any schemes to configure the maximum levels for the subscriber lines, or interpret the levels based on the prefixes when a call is offered through a channel-associated signaling/R2 (CAS/R2) type of interface.

Precedence provides for preferred handling of call-service requests. It involves assigning and validating priority levels to calls and prioritized treatment of MLPP service requests. The nature of precedence assignment is based on an internal decision, in that the user chooses to apply or not to apply assigned precedence level to a call. MLPP precedence is unrelated to other call admission control (CAC) or enhanced emergency services (E911) services. User invocation of an MLPP request is provided through dedicated dial access codes and selectors in the dial string. In particular, a precedence call is requested by the user using the string prefix NP, where P is the requested precedence level and N is the preconfigured MLPP access digit.

The range of precedence values in DSN/Public SS7 Network Format (DSN/Q.735) service domains is shown in the table below.

The Defense Red Switched Network (DRSN) service domain has six levels of precedence as shown in the table below.

A subscriber A (0100) calling B (0150) that wants to explicitly associate a precedence level (priority) to a particular call, would dial the following digits:

8555-3-0150

^ ^ ^

| | |___________ Called number

| |_____________ Call precedence--priority

|__________________ MLPP service prefix

If subscriber A is an ordinary customer with an assigned precedence level of 4 (routine), then MLPP automatically treats this call as a routine call.

In SIP and ISDN signaling, however, the precedence levels and domain-name space information are carried discretely in the protocol messages and do not require appropriate prefixes to the dialed digits.

Preemption is the termination of existing calls of lower precedence and extension of a call of higher precedence to or through a target device. Precedence includes notification and acknowledgment of preempted users and reservation of any shared resources immediately after preemption and before preempted call termination.

Preemption takes one of two forms:

• The called party may be busy with a lower precedence call, which must be preempted in favor of completing higher precedence call from the calling party.

• Network resources may be busy with calls, some of which are of lower precedence than the calls requested by the calling party. One or more of these lower-precedence calls is preempted to complete the higher-precedence call.

Cisco IOS gateways do not implement any type of preemption service logic; that task wholly rests with the DSN switch.

The figure below shows the system flow for a typical user scenario.

The request from a higher priority interrupts a lower-priority usage at a user terminal, such as an IP phone.

The Primary Rate Interface (PRI) is connected to a DSN WAN through a Cisco IOS gateway. For the purpose of this illustration, we assume that users A, B, C, and D are properly configured in the DSN switch with the appropriate maximum priority levels, as follows:

• User A--Priority FLASH

• User B--Priority IMMEDIATE

• User C--Priority ROUTINE

• User D--Priority FLASH

User C establishes a call with User A. User C wants the call to be set to the maximum priority value and so dials the appropriate code. User D tries to call a security advisor. Because User D’s call has the highest priority, the figure below provides an overall illustration on how MLPP works in this scenario and the part this new functionality on the Cisco IOS gateway plays in achieving MLPP.

Note	The MLPP application is an existing feature and is leveraged while interworking with Cisco IOS gateways through SIP.

A typical network solution and call flow is as follows (see the figure above):

• User C (7777) calls User A (1000) and they are in a routine call.

• User D (8888) wants to call User A (1000). User D (8888) goes off-hook and dials 1000.

• The DSN switch interprets the call priority by looking at the dialed digits and maps to the ISDN SETUP message:

Precedence IE: Level - 0000, Service Domain - 0000000

The call is routed through the Cisco IOS gateway.

• The Cisco IOS gateway passes the incoming call with the dialed digits. It maps the incoming ISDN Precedence IE to the Resource-Priority header values. The management system applies the local policy (as configured on the gateway) to choose the name space where it wants to represent the levels:

INVITE Resource-Priority: dsn.flash

The management system validates the dialed number (DN) and identifies that User A (1000) is already in a call.

• The management system looks at the precedence level of the call from User D (8888) (FLASH) and compares this with the precedence of the existing call between User A (1000) and User C (7777) (ROUTINE).

• The management system decides to preempt the User C (7777) to User A (1000) call.

There are two options for the management system to provide the treatment to User C (7777). It either provides the preemption tone from its end if it was transcoding and Real-Time Transport Protocol (RTP) streams were controlled by it. Or if the RTP streams were directly established between the endpoints gateway and the phone, it inserts a suitable cause value in the SIP Reason header and lets the gateway or the DSN switch provide the treatment. The management system presents the cause value either in new Reason header name space preemption or in Q.850 format:

BYE Reason: Preemption; cause=1;text=”UA_Preemption”

• The application marks the endpoint User A available for reuse and offers User D’s call to it.

• If User D (8888) disconnects the call, the management system clears the resources and preserves the existing call between User A (1000) and User C (7777).

If a higher precedence call comes in during the User D (8888) to User A (1000) call, the management system processes the higher-order preemption. For the IP phones, when a user’s profile is assigned to the phone, calls initiated from the phone inherit the precedence of the assigned user.

The next two figures show examples of a Resource-Priority (R-P) header call flows with loose mode and strict mode selected.

Note	In the loose mode, unknown values of name space or priority values received in the Resource-Priority header in SIP requests are ignored by the gateway. The request is processed as if the Resource-Priority header were not present.

With the SIP Support for Media Forking feature, you can create up to three Real-Time Transport Protocol (RTP) media streams to and from a single DS0 channel. In addition, separate gateway destinations (IP address or UDP port) are maintained for each of the streams. The streams are bidirectional; media received from the destination gateways are mixed in the DSP before being sent to the DS0 channel, and pulse code modulation (PCM) received from the DS0 is duplicated and sent to the destination gateways.

Originating gateways establish multiple media streams on the basis of Session Description Protocol (SDP) information included in midcall re-Invites received from a destination gateway, third-party call controller, or other SIP signaling entity. Only one SIP call leg is involved in media forking at the gateway, so the SIP signaling entity that initiates the re-Invites must be capable of aggregating the media information for multiple destinations (such as IP address, port number, payload types, or codecs) into one SDP description. Multiple m-lines in the SDP are used to indicate media forking, with each m-line representing one media destination.

Note	SIP media streams are created and deleted only through re-Invite messages; no specific CLI is required.

The ability to create midcall multiple streams (or branches) of audio associated with a single call and send those streams of data to different destinations is similar to a three-way or conference call. A media-forked call has some differences. For example, in a three-way call, each party hears all of the other parties. But in a media-forked call, only the originating caller (the controller) hears the audio (voice and DTMF digits) from all the other participants. The other participants hear audio only from the originating caller and not from each other.

Another difference between a three-way call and a media-forked call is that media streams can be configured on the gateway. Three-way calls send the audio to all of the other parties involved in the call. However, media-forking permits each media stream to be independently configured. For example, one media stream to one party may include both voice and DTMF digits, whereas another media stream to another party may include only DTMF digits.

The feature supports three types of media streams: voice, DTMF-relay only, and voice plus DTMF-relay.

In addition to the following discussion, see the following as appropriate:

• For information on codecs, see "Map Payload Types to Dynamic Payload Codecs".

• For information on payload types see "Multiple Codec Selection Order and Dynamic Payload Codecs".

• For information on DTMF relay, see the "SIP INFO Method for DTMF Tone Generation” section of the "Configuring SIP DTMF Features" chapter.

When using multiple codecs you must create a voice class in which you define a selection order for codecs, and you can then apply the voice class to VoIP dial peers. The voice class codec command in global configuration mode allows you to define the voice class that contains the codec selection order. Then you use the voice-class codec command in dial-peer configuration mode to apply the class to individual dial peers.

If there are any codecs that use dynamic payload types (g726r16, g726r24), Cisco IOS software assigns the payload types to these codecs in the order in which they appear in the configuration, starting with the first available payload type in the dynamic range. The range for dynamic payload types is from 96 to 127, but Cisco IOS software preassigns the following payload types by default.

Because the payload types have been reserved by the default assignments shown in the table, Cisco IOS software automatically assigns 98 to the first dynamic codec in the dial-peer configuration, 99 to the second, and 102 to the third.

Some of these preassigned payload types can be changed with the modem relay command. This command allows changes to the available payload types that can be used for codecs.

For outgoing calls on the originating gateway, all of the codecs that are configured in the codec list used by the dial peer are included in the SDP of the Invite message.

On the terminating gateway, Cisco IOS software always uses the dynamic payload types that the originating gateway specified in the SDP of the Invite message. This practice avoids the problem of misaligned payload types for most call types. The exception is when a delayed-media Invite message is received. A delayed-media Invite can be used by a voice portal to signal a terminating gateway before re-Inviting a forking gateway. If a delayed-media Invite is used, the Invite message does not contain SDP information, and the terminating gateway must advertise its own codecs and payload types. It does this in the SDP of its response message (either a 183 or a 200 OK). The terminating gateway assigns payload types to dynamic codecs using the same rules as the originating gateway. However, if there is a difference in either the preassigned dynamic payload types or the order in which the dynamic codecs are listed in the codec list used by the dial peer, the payload types may not be assigned consistently on the originating and terminating gateways. If the terminating gateway selects a different payload type for a dynamic codec, the call may fail.

If a G.726 codec is assigned in the first active stream of the call, there are some scenarios in which the voice portal sends a delayed-media re-Invite message to the second or third terminating gateway. Then, it is necessary to ensure that the originating gateway and the second and third terminating gateways have the same preassigned payload types and the same order of dynamic codecs in the codec list for the dial peer being used for the call. Otherwise, the added media stream may be rejected by the originating gateway if the payload types do not match.

A web-browsing application that uses voice recognition and text-to-speech (TTS) technology to make reservations, verify shipments, or order products is a typical application of media forking. In The figure below, a client (Party A) uses a telephone to browse the web. Party A calls the voice portal (Party B), and the call is routed through the originating gateway. The voice portal operates like a standard voice gateway and terminates calls to a voice response system that has voice recognition and TTS capabilities. This voice response system takes input from Party A by DTMF digits or voice recognition and returns responses (for example, stock quotes retrieved from the web) to Party A.

The voice portal, or Party B, is also capable of third-party call control (3pcc) and can set up a call between Party A and a third participant (Party C) without requiring direct signaling between Party A and Party C. One example of a possible call between Party A and Party C is if Party A found a restaurant listing while browsing the web and wanted to speak directly to the restaurant to make reservations.

Another feature of the voice portal is that once the call between parties A and C is established, the voice portal can continue to monitor the audio from Party A. By doing so, the voice portal can terminate the connection between Party A and Party C when a preestablished DTMF digit or voice command is received. Party B retains the connection between itself and Party A, in case Party A has any further requests. Continuing with the restaurant example, the continuous connection is important if Party A decides to query yet another restaurant. Party A simply goes back to the connection with Party B, who sets up a call with the new restaurant.

Another important aspect of media forking is that although there can be more than one media destination, there is only one signaling destination (in this case, the voice portal). The call leg that was originally set up (from the originating gateway to the voice portal) is maintained for the life of the session. The media destinations are independent of the signaling destination, so media streams (or new destinations) can be added and removed dynamically through re-Invite messages. Media streams are created and deleted only through re-Invite messages rather than through any CLIs.

If you configure the timer receive-rtcp command for a gateway, a Session Initiation Protocol (SIP) media inactivity timer is started for each active media stream. The timer monitors and disconnects calls if no RTCP packets are received within a configurable time period. If any of the timers expire, the entire call is terminated--not just the stream on which the timer expired. If a stream is put on call hold, the timer for that stream is stopped. When the stream is taken off hold, the timer for that stream is started again.

There is a maximum of three VoIP media streams that can be established per call. The figure below shows the maximum number of streams.

Media forking is initiated by specifying multiple media fields (m-lines) in the SDP of a re-Invite message. The rules for adding and deleting multiple m-lines conform to RFC 2543, SIP: Session Initiation Protocol Appendix B .

Multiple streams are not created through CLIs.

To configure codec complexity on a Cisco 2600 series, Cisco 3600 series, Cisco 37xx, or Cisco AS5300, or Cisco 7200 series, perform one of the following tasks, according to your router type.