If two RTP streams are presented on the same UDP port on a Cisco IOS Gateway running SIP, the gateway mixes the two audio streams and plays the two streams to the PSTN party

[TCC_2]

Core Issue

A Cisco router running Session Initiation Protocol (SIP) is correctly playing an Real Time Protocol (RTP) stream to the PSTN. This stream has a destination address of the LAN interface on the router. If two RTP streams are presented on the same User Datagram Protocol (UDP) port on the router, the router mixes the two audio streams and plays the two streams to the PSTN party. The person on the PSTN leg hears the two audio streams mixed together perfectly. The person on the IP leg is unaware that the PSTN party is hearing a mix of two audio streams.

For a call coming from SIP trunk and terminating on the Cisco CallManager Express IP phone, if several mid-call re-invites come in with different remote addresses and ports, Cisco CallManager Express uses the same local port to listen to these media streams. If the remote side does not shut down the old media stream before switch to new media stream, Cisco CallManager Express automatically mixes them and sends them to the IP phone.

Resolution

This issue is a slight variation of Cisco bug ID CSCei58858.

This bug is fixed in IOS versions 12.4(4.7)PI3a, 124(4.7)T and beyond.

To resolve this issue, upgrade the Cisco IOS Software Release to 12.4(4.7)T. In this version, these Cisco IOS commands can be issued:

• voice service voip
  
• sip
  
• source filter

To download Cisco IOS version 12.4(4.7)T, refer to Software Center (Downloads)-Cisco IOS Software.

[Daniele Giordano]

I've found this note about the issue in title:

•CSCtk34885

Symptoms: Crosstalk being heard intermittently on inbound calls.

Conditions: Inbound calls from PSTN to Ingress gateway hearing crosstalk on Rout call leg (DSP to PSTN) on AS5400XM.

Workaround: The following command in IOS can mitigate this for SIP:

voice service voip sip source filter

This eliminates the risk for crosstalk since the gateway blocks all rogue audio out to the PSTN with this command.

The above command only works for SIP, so H323, MGCP, and SCCP are still affected.

The following enhancement requests have been filed:

CSCtq47019 - support on H.323, SCCP, and MGCP. This will allow the command to be used in all VoIP environments.

CSCtq47431 - To get this feature added to IP phones.

PSIRT Evaluation: The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are 1.8/1.6:

https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&version=2&vector=AV:A/AC:H/Au:N/C:P/I:N/A:N/E:F/RL:W/RC:C

No CVE ID has been assigned to this issue.

Additional information on Cisco's security vulnerability policy can be found at the following URL: http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html

Do you know if Cisco has already prepared a workaround for MGCP scenario?

Regards.