Strange SIP problem

[jonathan.salter]

Inbound Call

PSTN>>>CUBE>>>CUCM (Sub1and Sub2 in DC1, Sub3 and Sub4 in DC2)

INVITE comes into cube from carrier

CUBE sends invite to Sub1....no response

CUBE sends invite to Sub1....no response

I then set a DP to send calls to Sub3 and Sub4

INVITE comes into cube from carrier

CUBE sends invite to Sub3....gets response call completes

Outbound Call

CUCM>>>CUBE>>>PSTN

Sub1 sends INVITE to CUBE...CUBE responds call completes

MGCP and SCCP messages flow from CUBE to all subs with no issues.

Network team states NO drops in firewall

SIP deep packet inspection is ON

PCAP on CUBE shows INVITES leaving destine for IP of Sub1 or Sub2

PCAP on Sub1 or Sub2 .....INVITES never hit the Subs

I am at a loss at this point

[Gregory Brunn]

I would say you need to start getting pcaps of anything you can between the cube and the subscribers. Might have to move to security team firewall is dropping. What happens if you turn of sip inspection? 

[jonathan.salter]

I don't have access to the firewall to capture anything or configure.

Network team is going to pcap on Monday.

Asked them to turn SIP inspection off today and they wouldn't do it during business hours and it was too late for a "change" request.

[jonathan.salter]

Still fighting with the network guys about the firewall.
I changed the transport from UDP to TCP and the call worked so again I lean towards the firewall.

[jonathan.salter]

Just an update....the problem was the SIP packet inspection. Once we disable the problem resolved.

Unfortunately this breaks some communication in our Polycom environment.

We will have to take this to Checkpoint and let me fix it.

[Gregory Brunn]

Happy to hear my suggestion of turning of inspection fixed the issue.

Are you saying turning of sip inspection breaks something with polycom?

[jonathan.salter]

---

@Gregory Brunn wrote:

Happy to hear my suggestion of turning of inspection fixed the issue.

Are you saying turning of sip inspection breaks something with polycom?

---

Yeah we had to turn ON SIP inspection to clear up some random drops on the Polycom.  We tested everything on the CUCM side but never realized the call was bouncing to our other CUBE since the tester reported good calls.  I originally asked him to turn it off and it did not help so I moved on to the next troubleshooting piece, but the network/firewall guy didn't let the firewall cue clear so the rule never got applied.  SMH

[Gregory Brunn]

How about this.... replace polycom? 

[jonathan.salter]

---

@Gregory Brunn wrote:

How about this.... replace polycom? 

---

Actually we tried when we move into our new headquarters last year, I created a presentation and a report on the Cisco solution.  We made it to the last round of "cuts" and eventually lost out to Polycom which we already had in our old building.  So unfortunately we are running into some of the same issues we had before now at our new location.  I am in the process of building out a "lab" environment with Cisco but it's a tough sell.