New to voip, need some help

Hello guys,

I've been designated to implement a CME solution for a new branch office, and I am currently having some issues integrating this new router with the existing router on the main office.

Currently, they have several other sites (using FXS interfaces for the phones and H323 connection to the main router) and this specific site I mentioned is the first one using SIP phones (100% voip).

I already have the phones up and calling each other on the site, but I can't seem to get the calls routed over the H323 connection to the main router. Right after dialing the numbers, the phone gets a mute line.

It seems like a signaling issue, maybe between the routers.

I've read several config guides, and could not figure out what is wrong with this.

Edit:

Thank you in advance

Find more posts tagged with

Comments

davenull

As a quick check, make sure you got all 4 variations under voice service voip (allow-connections sip to h323 etc).

Your best bet in figuring out what's going on is to make a test call while running debugs on the router. I'd try 'debug ccsip messages' and 'debug voice ccapi inout'.

d4nz1g

davenull wrote: »

As a quick check, make sure you got all 4 variations under voice service voip (allow-connections sip to h323 etc).

I have this configured already... Today I will use these commands and try to figure it out. I am sure it is on h323 signaling.

I will post the output here.

Thanks!

d4nz1g

It was the damn codec, could you believe that?
It seems like that my phones or my cme does not support g729r8. Changed to g711* and it worked.

Now I ran into the issue where I can place calls from the branch to the head office but from the head office to the branch I get the busy tone.

I got the debug output here, if I see no clue on that I will post it here

d4nz1g

This is where it fails (i guess):

Dec 29 23:05:21: //54/768FD60280A9/CCAPI/ccCallSetContext:
Context=0x2100EE64
Dec 29 23:05:21: //53/768FD60280A9/CCAPI/ccSaveDialpeerTag:
Outgoing Dial-peer=3
Dec 29 23:05:21: //54/768FD60280A9/CCAPI/ccGetMediaClassTag:
media class tag 0
Dec 29 23:05:21: //54/768FD60280A9/CCAPI/ccSetMediaclassIp2ipTags:
media class tags set: NR 0, ASP 0
Dec 29 23:05:21: //53/768FD60280A9/CCAPI/ccGetMediaClassTag:
media class tag 0
Dec 29 23:05:21: //53/768FD60280A9/CCAPI/ccSetMediaclassIp2ipTags:
media class tags set: NR 0, ASP 0
Dec 29 23:05:21: //54/768FD60280A9/CCAPI/ccGet_xc_nr_asp_info:
media class tags: NR 0, ASP 0
Dec 29 23:05:21: //53/768FD60280A9/CCAPI/ccGet_xc_nr_asp_info:
media class tags: NR 0, ASP 0
Dec 29 23:05:21: //-1/xxxxxxxxxxxx/CCAPI/cc_is_cng_fax_detect_active:
Call Id 54
Dec 29 23:05:21: //-1/xxxxxxxxxxxx/CCAPI/cc_is_cng_fax_detect_active:
Failure with registry invocation of cng fax detection being allowed 54
Dec 29 23:05:21: //-1/xxxxxxxxxxxx/CCAPI/cc_is_cng_fax_detect_active:
Call Id 53
Dec 29 23:05:21: //-1/xxxxxxxxxxxx/CCAPI/cc_is_cng_fax_detect_active:
Failure with registry invocation of cng fax detection being allowed 53
Dec 29 23:05:21: //54/768FD60280A9/CCAPI/cc_api_call_disconnected:
Cause Value=3, Interface=0x3EB40F40, Call Id=54
Dec 29 23:05:21: //54/768FD60280A9/CCAPI/cc_api_call_disconnected:
Call Entry(Responsed=TRUE, Cause Value=3, Retry Count=0)
Dec 29 23:05:21: //53/768FD60280A9/CCAPI/ccCallReleaseResources:
release reserved xcoding resource.
Dec 29 23:05:21: //54/768FD60280A9/CCAPI/ccCallSetAAA_Accounting:
Accounting=0, Call Id=54
Dec 29 23:05:21: //54/768FD60280A9/CCAPI/ccCallDisconnect:
Cause Value=3, Tag=0x0, Call Entry(Previous Disconnect Cause=0, Disconnect Cause=3)
Dec 29 23:05:21: //54/768FD60280A9/CCAPI/ccCallDisconnect:
Cause Value=3, Call Entry(Responsed=TRUE, Cause Value=3)
Dec 29 23:05:21: //54/768FD60280A9/CCAPI/cc_api_get_transfer_info:
Transfer Number=NULL
Dec 29 23:05:21: //54/768FD60280A9/CCAPI/cc_api_call_disconnect_done:
Disposition=0, Interface=0x3EB40F40, Tag=0x0, Call Id=54,
Call Entry(Disconnect Cause=3, Voice Class Cause Code=0, Retry Count=0)
Dec 29 23:05:21: //54/768FD60280A9/CCAPI/cc_api_call_disconnect_done:
Call Disconnect Event Sent

davenull

Is this a debug from the branch or head office router?

Cause Value=3 should mean 'No route to destination' according to Cisco IOS Voice Troubleshooting and Monitoring -- VoIP Cause Codes and Debug Values - DocWiki

I'd look for more clues here Cisco IOS Voice Troubleshooting and Monitoring -- H.323 Gateway Troubleshooting - DocWiki

Try 'show dialplan number xxxx', that will give you the outgoing dialpeer. Also, 'debug voip dialpeer'. You can try an undocumented 'csim start number' command from the router to simulate a call. Disclaimer: I think I read it's undocumented because Cisco believes it can crash the router in very rare cases.

d4nz1g

I noticed that too...it is from the branch office router.

I checked every dial-peer command and it seems fine.

The router on the other end (main office) is a gatekeeper, and the dialpeer for the 4.... numbers is configured as "session target ras". The router on another branch (4....) is a gateway.

Another thing: calls from the main office to the branch always fail (busy tone) but calls on the other way (branch to main) are ok.

What do you think?

Edit: Dec 29 23:05:21: //53/768FD60280A9/CCAPI/ccSaveDialpeerTag:
Outgoing Dial-peer=3

It finds a dial-peer but returns error 3..weird
If you want me to post the config on the branch router just let me know.

Thank you mate!

davenull

Yeah, post a sanitized config maybe something will jump out.

You may get this resolved faster if you open a TAC case assuming you got some sort of contract. Alternatively, you could try your luck with cisco-voip@puck.nether.net mailing list. There are many knowledgeable voip engineers there.

d4nz1g

Sorry about the delay. Worked on that and I found 2 NAT points inside the customer's network, lol.
Removed that and everything worked fine.

Now I've got only 1 situation, where calls from pstn to IP phones get disconnected off-hook.

Opened a TAC case and may be solved this week.