CUCM SIP trunk header issue

[tca_arosen]

Hello extremely knowledgeable and helpful community that will surely figure out how to fix my problem (is that enough flattery?)

We have a CUCM 9.x with a CUBE 2911 set up with a SIP trunk to our provider. As a backup solution (which I was told would be easy to implement - HAH!), we are creating a backup SIP trunk over our internet ISP in case our primary SIP lines are cut (yes, I know no QOS, but we hopefully won't have to fallback on this too often). Our Cisco vendor recommended we originate the SIP trunk from the CUCM system, as then if the CUBE goes down we would have redundancy for that.

After some work, we got our SIP trunk negotiated with our provider, but we are getting one-way audio (from our phones to the outside world). Looking into the problem, we are sending our Invite with our From and P-Asserted-Identity referencing our internal IP address (From: "Adam Rosen" <sip:716...@192.168.X.X>;...), creating a failure to route our incoming packets. 

How can I fix this, preferably without any additional hardware (since this was supposed to work with our existing configuration). Can I use a SIP normalization script on the SIP trunk to re-write the IP address, and if so can anyone point me to an almost-ready-to-go example? Our firewall can do SIP packet inspection for the purposes of dynamically opening RTP ports, but cannot do this level of inspection/modification.

I appreciate any help you can give.

Thanks

Adam

[George Thomas]

Please post debug ccsip messages and your SIP configuration from the CUBE.

[tca_arosen]

George - 

I will if it necessary, but as I am trying to connect directly from CUCM and bypass the CUBE, is that helpful? I have a lot to learn about these systems, so I don't know if I'm missing something, or if you were misunderstanding the question, so I thought I would double check.

Thanks

Adam

[George Thomas]

Do you have SIP inspection on the firewall, if so please turn it off. What is the IP address that you see listed in the SDP section of the SIP messages? That is where the media will be sent to and you need to make sure that this IP address is being correctly routed to where it needs to go. Since the issue is from provider to your phones, I would be interested to see the SDP that is being sent out to the provider. If its an internal address, that is your problem but please verify.

[Ayodeji Okanlawon]

You have fallen into the hole that your vendor has dug for you, in a few moment, you will be buried 6 feet below!!! ahaha, until we (cisco community comes to rescue you!)

The first rule of thumb is never bypass CUBE. From a security point of view, CUBE provides a point of demarcation and from a functionality and features point of view CUBE gives the flexibility that is required for integration and interoperability with ITSP...

The issue at hand is a good case that lends its voice to the functionality part of the CUBE solution. With a CUBE, this would have been a 2 minutes job. You will just need to create sip bind statements that will source your sip signalling traffic based how you want your sip messages to be routed. However without CUBE, you need the expertise of writing "lua-scripts" for sip normalization. now that is tough! About 1 in 100000000 people know how to use lua-scripts and fortunately for you, I am not one of them.

So back to the drawing board..get your CUBE in the mix and don't let your vendor bury you for real!!!

[tca_arosen]

Ahhh, the fun just keeps on coming. Just to clarify, we do have a CUBE for primary connectivity - the SIP trunk terminating at CUCM is just for failover purposes so we don't need to have a second CUBE in our infrastructure. 

I think I need a drink.

[George Thomas]

I agree with Ayodeji on this. The effort you will have to put into getting this work will cost you more compared to buying a low end CUBE, but please post the information and we can see what we can do.

[tca_arosen]

I just want to thank everyone for their input so far. I am trying to get RTMT up and running. I've had it work in the past, but right now when I run it I am getting "RTMT failed to initialize. Exiting...". I'll post an update once I can make some progress.

Adam

[greg.newman]

How'd you fix the RTMT issue? I have the same problem trying to run RTMT against one of the two CUC nodes running Unity here... "RTMT failed to initialize. Exiting...". But only on one of the 2 nodes, strangely.

Thanks!

[Ayodeji Okanlawon]

Okay, all is well then. Please use RTMT to download cucm SDL logs file and attach here. Include the calling, called number and time of call. Lets have a look at whats going on.

[George Thomas]

But the 2nd SIP is not going through the CUBE, correct? Only the primary one is?

[tca_arosen]

Correct, CUBE is only being used for the primary connection.