Dynamic Payload Type Interworking for DTMF and Codec Packets for SIP-to-SIP Calls

The Dynamic Payload Type Interworking for DTMF and Codec Packets for SIP-to-SIP Calls feature provides dynamic payload type interworking for dual tone multifrequency (DTMF) and codec packets for Session Initiation Protocol (SIP) to SIP calls.

Based on this feature, the Cisco Unified Border Element (Cisco UBE) interworks between different dynamic payload type values across the call legs for the same codec. Also, Cisco UBE supports any payload type value for audio, video, named signaling events (NSEs), and named telephone events (NTEs) in the dynamic payload type range 96 to 127.

Feature Information for Dynamic Payload Type Interworking for DTMF and Codec Packets for SIP-to-SIP Calls

The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to https://cfnng.cisco.com/. An account on Cisco.com is not required.
Table 1. Feature Information for Dynamic Payload Interworking for DTMF and Codec Packets Support

Feature Name

Releases

Feature Information

Dynamic Payload Type Interworking for DTMF and Codec Packets for SIP-to-SIP Calls

15.0(1)XA 15.1(1)T

The Dynamic Payload Type Interworking for DTMF and Codec Packets for SIP-to-SIP Calls feature provides dynamic payload type interworking for DTMF and codec packets for SIP-to-SIP calls.

The following commands were introduced or modified: asymmetric payload and voice-class sip asymmetric payload .

Dynamic Payload Type Interworking for DTMF and Codec Packets for SIP-to-SIP Calls

Cisco IOS Release XE 3.1S

The Dynamic Payload Type Interworking for DTMF and Codec Packets for SIP-to-SIP Calls feature provides dynamic payload type interworking for DTMF and codec packets for SIP-to-SIP calls.

The following commands were introduced or modified: asymmetric payload and voice-class sip asymmetric payload .

Restrictions for Dynamic Payload Type Interworking for DTMF and Codec Packets for SIP-to-SIP Calls

The Dynamic Payload Type Interworking for DTMF and Codec Packets for SIP-to-SIP Calls feature is not supported for the following:

  • H323-to-H323 and H323-to-SIP calls.

  • All transcoded calls.

  • Secure Real-Time Protocol (SRTP) pass-through calls.

  • Flow-around calls.

  • Asymmetric payload types are not supported on early-offer (EO) call legs in a delayed-offer to early-offer (DO-EO) scenario.

  • Cisco fax relay.

  • Multiple m lines with the same dynamic payload types, where m is:

m = audio <media-port1> RTP/AVP XXX m = video <media-port2> RTP/AVP XXX

Symmetric and Asymmetric Calls

Cisco UBE supports dynamic payload type negotiation and interworking for all symmetric and asymmetric payload type combinations. A call leg on Cisco UBE is considered as symmetric or asymmetric based on the payload type value exchanged during the offer and answer with the endpoint:

  • A symmetric endpoint accepts and sends the same payload type.

  • An asymmetric endpoint can accept and send different payload types.

The Dynamic Payload Type Interworking for DTMF and Codec Packets for SIP-to-SIP Calls feature is enabled by default for a symmetric call. An offer is sent with a payload type based on the dial-peer configuration. The answer is sent with the same payload type as was received in the incoming offer. When the payload type values negotiated during the signaling are different, the Cisco UBE changes the Real-Time Transport Protocol (RTP) payload value in the VoIP to RTP media path.

To support asymmetric call legs, you must enable The Dynamic Payload Type Interworking for DTMF and Codec Packets for SIP-to-SIP Calls feature. The dynamic payload type value is passed across the call legs, and the RTP payload type interworking is not required. The RTP payload type handling is dependent on the endpoint receiving them.

High Availability Checkpointing Support for Asymmetric Payload

High availability for a call involving asymmetric payloads is supported. In case of fail-over from active to stand-by, the asymmetric payload interworking will be continued as new active CUBE passes across the payload type values according to the negotiation and call establishment.
Figure 1. Sample High-Availability Topology


How to Configure Dynamic Payload Type Passthrough for DTMF and Codec Packets for SIP-to-SIP Calls

Configuring Dynamic Payload Type Passthrough at the Global Level

Perform this task to configure the pass through of DTMF or codec payload to the other call leg (instead of performing dynamic payload type interworking) feature at the global level.

SUMMARY STEPS

  1. enable
  2. configure terminal
  3. voice service voip
  4. sip
  5. asymmetric payload {dtmf | dynamic-codecs | full | system }
  6. end

DETAILED STEPS

  Command or Action Purpose

Step 1

enable

Example:


Device> enable

Example:

Enables privileged EXEC mode.

  • Enter your password if prompted.

Step 2

configure terminal

Example:


Device# configure terminal

Enters global configuration mode.

Step 3

voice service voip

Example:


Device(config)# voice service voip

Enters voice service configuration mode.

Step 4

sip

Example:


Device(conf-voi-serv)# sip

Enters voice service SIP configuration mode.

Step 5

asymmetric payload {dtmf | dynamic-codecs | full | system }

Example:


Device(conf-serv-sip)# asymmetric payload full

Configures global SIP asymmetric payload support.

Note

 

The dtmf and dynamic-codecs keywords are internally mapped to the full keyword to provide asymmetric payload type support for audio and video codecs, DTMF, and NSEs.

Step 6

end

Example:


Device(conf-serv-sip)# end

Exits voice service SIP configuration mode and enters privileged EXEC mode.

Configuring Dynamic Payload Type Passthrough for a Dial Peer

Perform this task to configure the pass through of DTMF or codec payload to the other call leg (instead of performing dynamic payload type interworking) feature at the dial-peer level.

SUMMARY STEPS

  1. enable
  2. configure terminal
  3. dial-peer voice tag voip
  4. voice-class sip asymmetric payload {dtmf | dynamic-codecs | full | system }
  5. end

DETAILED STEPS

  Command or Action Purpose

Step 1

enable

Example:


Device> enable

Enables privileged EXEC mode.

  • Enter your password if prompted.

Step 2

configure terminal

Example:


Device# configure terminal

Enters global configuration mode.

Step 3

dial-peer voice tag voip

Example:


Device(config)# dial-peer voice 77 voip

Enters dial peer voice configuration mode.

Step 4

voice-class sip asymmetric payload {dtmf | dynamic-codecs | full | system }

Example:


Device(config-dial-peer)# voice-class sip asymmetric payload full

Configures the dynamic SIP asymmetric payload support.

Note

 

The dtmf and dynamic-codecs keywords are internally mapped to the full keyword to provide asymmetric payload type support for audio and video codecs, DTMF, and NSEs.

Step 5

end

Example:


Device(config-dial-peer)# end

(Optional) Exits dial peer voice configuration mode and enters privileged EXEC mode.

Verifying Dynamic Payload Interworking for DTMF and Codec Packets Support

This task shows how to display information to verify Dynamic Payload Type Interworking for DTMF and Codec Packets for SIP-to-SIP Calls configuration feature. These show commands need not be entered in any specific order.

SUMMARY STEPS

  1. enable
  2. show call active voice compact
  3. show call active voice

DETAILED STEPS

  Command or Action Purpose

Step 1

enable

Example:


Device> enable

Enables privileged EXEC mode.

  • Enter your password if prompted.

Step 2

show call active voice compact

Example:


Device# show call active voice compact

(Optional) Displays a compact version of call information.

Step 3

show call active voice

Example:


Device# show call active voice

(Optional) Displays call information for voice calls in progress.

Troubleshooting Tips

Use the following commands to debug any errors that you may encounter when you configure the Dynamic Payload Type Interworking for DTMF and Codec Packets for SIP-to-SIP Calls feature:

  • debug ccsip all

  • debug voip ccapi inout

  • debug voip rtp

Use the following debug commands to troubleshoot HA Checkpointing for Asymmetric Payload:

  • debug voip ccapi all
  • debug voice high-availability all
  • debug voip rtp error
  • debug voip rtp inout
  • debug voip rtp packet
  • debug voip rtp high-availability
  • debug voip rtp function
  • debug ccsip all

Use the following show commands to troubleshoot HA Checkpointing for Asymmetric Payload:

  • show redundancy state
  • show redundancy inter-device
  • show standby brief
  • show voice high-availability summary
  • show voip rtp stats
  • show voip rtp high-availability stats
  • show voip rtp connection detail
  • show call active voice brief
  • show call active voice [summary]
  • show call active video brief
  • show call active video [summary]
  • show align
  • show memory debug leak

Configuration Examples for Assymetric Payload Interworking

Example: Asymmetric Payload Interworking—Passthrough Configuration 


!
voice service voip 
 allow-connections sip to sip
sip
  rel1xx disable
  asymmetric payload full
  midcall-signaling passthru
!
dial-peer voice 1 voip
 voice-class sip asymmetric payload full
 session protocol sipv2
 rtp payload-type cisco-codec-fax-ind 110
 rtp payload-type cisco-codec-video-h264 112
 session target ipv4:9.13.8.23
!

In the above example, it is assumed that 110 and 112 are not used for any other payload.

Example: Asymmetric Payload Interworking—Interworking Configuration 


!
voice service voip 
 allow-connections sip to sip
!
dial-peer voice 1 voip
 session protocol sipv2
 rtp payload-type cisco-codec-fax-ind 110
 rtp payload-type cisco-codec-video-h264 112
 session target ipv4:9.13.8.23
!

In the above example, it is assumed that 110 and 112 are not used for any other payload.