Page History

Refer to DSP Channel Densities for SBC 5000 and 7000 Series for a comparison of different DSP card configurations for

See  DSP Channel Densities for SBC 5000 and 7000 Series for a comparison of different DSP card configurations for

In a transcode call scenario, the 

The SBC supports the following AI to PEM interworking functionality using the flag aiToPemInterworking:

• Interworking between a network supporting AI header (based on the Legacy Mobile Station Domain (LMSD) format) to a network supporting PEM header. The SBC supports interworking irrespective of the existence of a provisioned tone on the SBC.
• Interworking between a network that does not support PEM header to a network that supports PEM header. For example, the ingress network supports PEM header; however, the egress network does not.
• Interworking between networks that support PEM headers.

When a tone is configured on the SBC,

• If the flag aiToPemInterworking is disabled, the SBC plays tone based on the LMSD format. For more information, refer to Tones and Announcements. 

• If the flag aiToPemInterworking is enabled, the SBC supports interworking between AI and PEM headers. The SBC plays tone when it receives AI header with sig-id=rt in the 180 provisioning response (either first 180 response or subsequent 180 response) from the Mobile Switching Center (MSC) (CDMA network). 
  

  Info
  title Note
  When all the tone playing criteria are fulfilled, the SBC inserts PEM header as SENDRECV (PEM: SENDRECV) and sends it towards the ingress network. When the SBC fails to play tone, the SBC inserts PEM header as INACTIVE (PEM: INACTIVE) and sends it towards the ingress network.

When tone is not configured on the SBC; and the IPSP flag acceptAlertInfo is enabled on the egress TG, and the INVITE message is received with PEM: SUPPORTED,

• If the flag aiToPemInterworking is disabled, the SBC falls back to the existing LMSD interwoking functionality. For more information, refer to LMSD Interworking without Tones.
  

• If the flag aiToPemInterworking is enabled, the SBC supports interworking between AI header (received in the LMSD format) and PEM header.
   

  Info
  title Note
  When the User-Agent Server (UAS) plays tone, the SBC inserts PEM header as SENDRECV (PEM: SENDRECV) and sends it towards the ingress network. When the User-Agent Client (UAC) plays tone, the SBC inserts PEM header as INACTIVE (PEM: INACTIVE) and sends it towards the ingress network.

P-Early Media to Alert-Info Header Interworking

The SBC supports interworking between a network supporting PEM header to a network supporting Al header. To support this functionality, the flag aiToPemInterworking is used in the IP Signaling Profile. The SBC performs PEM to AI interworking once the 180 response is received with PEM header, while forwarding 180 response. If the peer does not explicitly provide early media authorization using a PEM header in 180 response with SDP answer, the SBC monitors the RTP traffic from the egress TG and performs a cut-through if RTP is received from the egress. To support this functionality, the flag monitorRTP is added to the SIP Trunk Group.

Interworking between PEM and AI Headers

The SBC supports PEM to AI interworking when PEM header is supported on the Trunk Group towards which 180 provisional response message is received and acceptAlertInfo flag is enabled on the Trunk Group towards which 180 provisional response message is sent.

• When the SBC receives 180 response with PEM header, while forwarding 180 response:  
  • if PEM is inactive and the SBC does not play tone, the SBC inserts AI header with sig-id=rt. 
  • if PEM is inactive and the SBC plays tone, the SBC inserts AI header with sig-id=null.
    
  • if PEM is sendrecv or sendonly independent of the SBC is configured to play tone or not, the SBC inserts AI header with sig-id=null.
    

• When the SBC receives 180 response with PEM header, while forwarding 180 response:

  • In case of first 180 response without SDP and PEM is inactive:
    • if the SBC does not play tone, the SBC inserts AI header with sig-id=rt.
      
    • if the SBC plays tone, the SBC inserts AI header with sig-id=null.
  • In case of subsequent 180 response without SDP and PEM header is not received in previous provisional response, the PEM is assumed to be inactive:
    • if the SBC does not play tone, the SBC inserts AI header with sig-id=rt.
      
    • if the SBC plays tone, the SBC inserts AI header with sig-id=null.
  • In case of subsequent 180 response with or without SDP and PEM header is received in previous provisional response:
    • if the SBC does not play tone and previous PEM is inactive, the SBC inserts AI header with sig-id=rt.
      
    • if the SBC does not play tone and previous PEM is sendonly or sendrecv, the SBC inserts AI header with sig-id=null.
      
    • if the SBC plays tone, the SBC inserts AI header with sig-id=null. 
      

PEM to PEM Interworking

The SBC supports PEM to PEM interworking when PEM header is supported on the Trunk Group towards which 180 provisional response message is received and PEM is supported on the Trunk Group towards which 180 provisional response message is sent.

• When the SBC is not configured to play tone:  
• if the SBC receives 180 response with PEM header, while forwarding 180 response, the SBC relays the received PEM header towards ingress.
• if the SBC does not receive PEM header, the SBC inserts PEM header based on the SDP direction in 180 provisional  response while forwarding 180 response towards ingress.
• if the SBC does not receive PEM header and the flag monitorRTP is enabled, the SBC forwards 180 response without PEM and monitors RTP.
• When the SBC is configured to play tone:
  • if the SBC receives an inactive PEM, the SBC inserts PEM sendrecv while forwarding 180 response towards ingress.
  • if the SBC does not receive PEM and the flag monitorRTP is enabled, the SBC inserts PEM sendrecv provided any of the previous provisional response did not receive PEM while sending 180 response towards ingress.
  • if the SBC receives PEM with sendrecv/sendonly, the SBC does not play tone and relays the received PEM header towards ingress.

Monitoring RTP

The SBC monitors the RTP packets when all or either of the following conditions are met.

• when the SBC sends an INVITE with PEM=supported and an early media SDP answer (in any 18x response) is received without PEM header.
• when the flag defaultGatingMethod is set as none. For more information on the flag defaultGatingMethod, refer to SIP Trunk Group - Media - CLI.
  

Playing Tone Locally

The SBC is enhanced to play LRBT locally without considering PEM header. To achieve this functionality, the flag withOrWithOutSdp is added to the toneAndAnnouncementProfile.

The SBC plays tone locally when it receives:

• first 180 response without SDP and PEM header or with PEM=inactive.
• first 180 response with SDP and PEM=inactive.
• first 180 response with SDP is received without PEM header.
• subsequent 180 responses without SDP and PEM header and the previous provisional response does not contain PEM header (even during an RTP monitoring).
• subsequent 180 responses without SDP with PEM=inactive.
• subsequent 180 responses with SDP and without PEM header or PEM=inactive and the previous provisional response does not contain PEM header (even during an RTP monitoring).

SBC does not Stop Playing Tone when UPDATE is Received from the UAS

The SBC is enhanced to continue playing the ringback tone after receiving an UPDATE message from the User Agent Server (UAS), rather than stopping the tone. The SBC then monitors the egress leg, stops the tone, if it receives an RTP packet or 200 OK message and opening the audio path in both directions. The UAS sends an UPDATE message, a codec upgrade, or a media hold. If the UPDATE message is due to a codec upgrade, the SBC continues playing the ringback tone using the new codec. If the SBC is not configured to continue playing the ringback tone after UPDATE, the caller may hear a very short ringback tone followed by a long period of silence until the final response is received. To achieve this functionality, the flag monitorRtpOnEgressUpdate is added to the egressIpAttributes of the IP Signaling Profile.

The SBC supports early media authorization in UPDATE, 200 OK to UPDATE, and PRACK messages towards the Trunk Group that supports PEM. 

• The SBC processes:

• • if PEM is received, the data path mode is set based on intersection of the SDP direction attribute and PEM header received.
  • if PEM is not received in the egress UPDATE, the SBC relays the UPDATE towards the ingress without PEM.
  • if PEM is not received in 200 OK (UPDATE), the SBC does not add PEM header. It only adds PEM header in the 200 OK if UPDATE is received from the ingress with PEM: inactive or without PEM and the SBC is configured to play the tone.
• The SBC receives and processes:

• • UPDATE without PEM and forwards UPDATE without PEM header, when SBC is not playing tone. 

  • UPDATE without PEM and forwards UPDATE with PEM=sendrecv header, when SBC is playing tone (when RTP monitoring is configured). 

  • if UPDATE is received on a leg, on which tone is being played, UPDATE is locally handled and tone is played with the new codec.
• The SBC receives and processes:
  • 200 OK to UPDATE with PEM and relays 200 OK to UPDATE with PEM header.
• The SBC processes the PEM header received in:
  • PRACK message and  relays PRACK with PEM header.
  • PRACK message and if PRACK message is received without PEM header, the SBC relays PRACK without PEM header.
• The SBC is configured to play tone:
  • if UPDATE is received without PEM or PEM:inactive from egress, the SBC inserts UPDATE with PEM:sendrecv towards ingress.
  • if UPDATE is received with sendrecv/sendonly/recvonly, the SBC relays UPDATE with PEM towards ingress.