cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4823
Views
0
Helpful
17
Replies

CUBE with Cbeyond SIP trunk

Hi All

I am trying to get a SIP trunk from Cbeyond connected to our CUCM7.1 via a Cisco CUBE.

I have registred the account and on calls in and out, I can see signaling but the call gets rejected.

After some discussion with Cbeyond support the tell me that the headers are changed during the callsetup and therefore the call is in the end rejected.

Does any one have a running config with this setup??

I am working on getting a test account from Cbeyond to some more indepth debugging, but if some one had some inputs that would be much appreciated.

thank you.

17 Replies 17

sbraychuk
Level 1
Level 1

Write down the result of debug ccsip messages.

Attached is a debug ccsip messages.

When I try to make an outbound call I get a prerecorded message from Cbeyond that the call cannot be completed. So the sip trunk is working, but Cbeyond is telling me that they see an IP-address, where they expect a name; sipconnect....

Inbound call is working after I changed the signaling between the UCM and CUBE to H323.

So the callflow is: Phone - UCM - H323 - CUBE - SIP - Cbeyond

Any suggestions?

Hello Martin,

First and foremost, I will suggest you do sip all the way. That is instead of using H323 between CCM and CUBE, use a sip trunk. So you flow ill look like this..

phone-CUCM-SIPTrunk-CUBE-SIP-Cbeyond

Secondly,

A sample of the trace you sent..

INVITE sip:4085264000@sip-proxy.sfo0.cbeyond.net:5060 SIP/2.0

Via: SIP/2.0/UDP 10.0.1.150:5060;branch=z9hG4bKBB5F8E

From: <>5108994949@sipconnect.sfo0.cbeyond.net>;tag=DD9446E4-15BA

To: <>4085264000@sip-proxy.sfo0.cbeyond.net>

SIP/2.0 100 Trying

Via: SIP/2.0/UDP 10.0.1.150:5060;branch=z9hG4bKBB5F8E

From: <>5108994949@sipconnect.sfo0.cbeyond.net>;tag=DD9446E4-15BA

To: <>4085264000@sip-proxy.sfo0.cbeyond.net>

There is no IP address in there, its the FQDN that is been used. I will go back to the Service provider and let them know that there is no IP in the trace...They should investgate  further on their part and send you a trace that shows the headers are modified.

Please rate all useful posts

the issue was the sip-proxy.sfo.cbeyond.net, should be sipconnect.

So now I have a working setup with the use of H323 between UCM and CUBE.

My initial setup was with SIP, but this failed and moved to H323, where I have success.

I tried to switch back to SIP and did some troubleshooting and have discovered the following line is giving the issues:

voice service voip

sip

  outbound-proxy dns:sip-proxy.sfo0.cbeyond.net

If I remove the line, I can make inbound calls from the provider to UCM, but outbound calls receive:

Received:

SIP/2.0 604 Does not exist anywhere

Via:SIP/2.0/UDP sipconnect.sfo0.cbeyond.net:5060;received=10.0.1.150;branch=z9hG4bKCFD6B2

From:<>5108994949@sipconnect.sfo0.cbeyond.net>;tag=F1FA68D0-FA8

To:<>4085264000@sipconnect.sfo0.cbeyond.net>;tag=479582213-1328605176623

Call-ID:E50C6817-50A011E1-87E6D484-B235FF17@sipconnect.sfo0.cbeyond.net

CSeq:101 INVITE

Content-Length:0

If I add the line, outbound calls succeeds but indbound calls never reaches the UCM.

SO it looks like there is a configuration issue. Can you send the trace for the succesful inbound calls and the trace for the failed outbound calls. debug ccsip messages

Please rate all useful posts

Attached is the requested trace.

first call is the successfull inbound call

second call is the outbound call failing.

Thank you for your assistance.

can you also send me a sh run please. I need to see your full config

Please rate all useful posts

Here is a config.

Martin,

After digging in and looking through the traces and a few research, I still cant say whats going on, but I have observed a few things.

The error  604 Does Not Exist Anywhere     implies that the server has authoritative information that the user indicated in    the Request-URI does not exist anywhere. In simple words, there is something you are sending in your headers that the sip server does not like.

In the two traces, here is my observation..

The failed call had the following format for the remote-party id:

Remote-Party-ID: <5108994949>;party=calling;screen=yes;privacy=off

the succesful call has this..

Remote-Party-ID: "Torsten Thomsen" <1293>;party=called;screen=yes;privacy=off

You can see that the format for the failed call is missing the actual calling or called party name. I will suggest that you involve your SP, let them take a look at the log, see what you are sending that their server does not like.

Can you also check that on your sip trunk you have the remote-party-id checked...

.

can you also confirm what is the called and calling number for clarification. Is it the same number you have been dialling, have you tried another number?

Please rate all useful posts

the inbound call is made from 2818172060 to 5108994949 which is then translated to 1293

The outbound call is made from 5108994949 to 4085264000

The remote-party-id is set on the trunk in the UCM

The UCM Ip is 10.1.1.51 and the CUBE is 10.102.43.10 on inside IP and 10.0.1.150 on outside towards Cbeyond.

Do I gain any thing form using SIP instead of H323? else I would shift to H323....

I think you gain a lot using SIP. H323 is old and there is no development on it. Going back to it, is like looking backwards rather than moving forward. Moreso SIP to SIP on CUBE is much more desirable and recommended by cisco. Question is what do you gain by going back to H323 in this case? Will it solve your problems?

Please rate all useful posts

If I shift back to H323, it works.

but yes, agreed SIP would be the way, but I have previously had issues with SIP-trunks that was solved by shifting to H323 between the CUBE and UCM.

Right. I will look more at solving the sip issue while I can. I didnt know you had it working with h323. It didnt work yesterday with it. I think there ate issues with the sip profiles and headers you have configured. Why dont you want to engage your SP? The sip service provider. They may tell you right away what they want.

Please rate all useful posts

Sorry if my post this morning: Feb 7, 2012 2:26 AM wasn't clear.

I have no problems contacting the SP although they would proberly say that it is the missing sip-proxy statement..

they only have experience with the CME...

If it is possible, I would greatly appreciate your 2nd view on this matter.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: