CUCM/Expressway IP@x.x.x.x Call from Polycom Endpoint Goes Out as SIP Instead of H323

[jriacono5]

Hello,

When we make a call out to ip@172.243.2.68 (WebEx) from a Polycom endpoint registered as a SIP device in CUCM, the call does not go through. When we make the same call from a Cisco endpoint, it works fine. When looking at the search history, we are seeing a working call route out as H323, and we see the failed call being tried as SIP. Can someone please provide insight on what may be happening here?

Working Call

• Search (121)

• State: Completed

• Found: True

• Type: SIP (INVITE)

• SIPVariant: Standards-based

• CallRouted: True

• CallSerial Number: 21a1aa52-6270-4178-b77b-95cf65a38ad4

• Tag: 050c11e2-1cdd-43fe-886c-4c6549b16257

• Source (1)

• Authenticated: False

• Aliases (1)

• Alias (1)

• Type: Url

• Origin: Unknown

• Value: pcstoretest22@na.xilinx.com

• Zone (1)

• Name: TraversalZone

• Type: TraversalServer

• Path (1)

• Hop (1)

• Address: 172.19.154.255:5061

• Hop (2)

• Address: 172.19.152.42:5065

• Destination (1)

• Alias (1)

• Type: Url

• Origin: Unknown

• Value: sip:173.243.2.68

• StartTime: 2019-02-13 13:35:02

• Duration: 32.29

• SubSearch (1)

• Type: Transforms

• Action: Not Transformed

• ResultAlias (1)

• Type: Url

• Origin: Unknown

• Value: 173.243.2.68

• SubSearch (1)

• Type: Admin Policy

• Action: Proxy

• ResultAlias (1)

• Type: Url

• Origin: Unknown

• Value: 173.243.2.68

• SubSearch (1)

• Type: FindMe

• Action: Proxy

• ResultAlias (1)

• Type: Url

• Origin: Unknown

• Value: 173.243.2.68

• SubSearch (1)

• Type: Search Rules

• CallsToUnknownIPAddresses (1)

• Mode: Direct

• Zone (1)

• Name: DefaultZone

• Type: Default

• Protocol: SIP

• Found: False

• Reason: Request Timeout

• StartTime: 2019-02-13 13:35:02

• Duration: 32.01

• Gatekeeper (1)

• Alias (1)

• Type: Url
• Origin: Unknown
• Value: 243.2.68

• Zone (2)

• Name: DefaultZone

• Type: Default

• Protocol: H323

• Found: True

• StartTime: 2019-02-13 13:35:35

• Duration: 0.26

• Gatekeeper (1)

• Address: 173.243.2.68:1720

• Alias (1)

• Type: Url
• Origin: Unknown
• Value: 243.2.68

Failed Call:

• Search (148)

• State: Cancelled

• Found: False

• Reason: Cancelled

• Type: SIP (INVITE)

• SIPVariant: Standards-based

• CallSerial Number: f231b654-5e6b-4685-a396-d4a237ea4af0

• Tag: b6a29c53-6db3-4695-82a5-d9c6b05e3d87

• Source (1)

• Authenticated: False

• Aliases (1)

• Alias (1)

• Type: Url

• Origin: Unknown

• Value: pchdxtest-xsj@na.xilinx.com

• Zone (1)

• Name: TraversalZone

• Type: TraversalServer

• Path (1)

• Hop (1)

• Address: 172.19.154.255:5061

• Hop (2)

• Address: 172.19.152.42:5065

• Destination (1)

• Alias (1)

• Type: Url

• Origin: Unknown

• Value: sip:173.243.2.68

• StartTime: 2019-02-14 14:08:29

• Duration: 32.02

• SubSearch (1)

• Type: Transforms

• Action: Not Transformed

• ResultAlias (1)

• Type: Url

• Origin: Unknown

• Value: 173.243.2.68

• SubSearch (1)

• Type: Admin Policy

• Action: Proxy

• ResultAlias (1)

• Type: Url

• Origin: Unknown

• Value: 173.243.2.68

• SubSearch (1)

• Type: FindMe

• Action: Proxy

• ResultAlias (1)

• Type: Url

• Origin: Unknown

• Value: 173.243.2.68

• SubSearch (1)

• Type: Search Rules

• CallsToUnknownIPAddresses (1)

• Mode: Direct

• Zone (1)

• Name: DefaultZone

• Type: Default

• Protocol: SIP

• StartTime: 2019-02-14 14:08:29

• Gatekeeper (1)

• Alias (1)

• Type: Url
• Origin: Unknown
• Value: 173.243.2.68

[jriacono5]

I gathered more logs and it looks like the Expressway Edge tries to route the IP address as SIP first for working and non-working calls. On the working call, after the SIP invites all timeout, it changes to H323. In the search history, I see the address as SIP:173.243.2.68, I'm thinking that should just be showing as the IP without SIP: in front. Any ideas as to why the Edge is trying to route this as a SIP call at all?

[Shalid Kurunnan Chalil · Accepted solution]

hi,
Please see the UDP under SIP configuration on your expressway is turned off.
you find it in Configuration > Protocols >SIP .

Regards,
Shalid

[jriacono5]

Thank you, Shalid! That fixed it. I turned SIP UDP mode to off. Do you anticipate this could cause any issues with our normal SIP video calls?

[Jonathan Schulenberg]

Cisco typically recommends disabling SIP UDP on the public internet to avoid fragmentation problems. Also, it raises the “cost” for malicious connections since they have to bother with with a TCP handshake. At least, that’s the explanation I have been given.

[jriacono5]

Thank you!