cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3067
Views
0
Helpful
7
Replies

CUBE (SIP-SIP) session to CUCM does not work

k-baba
Level 1
Level 1

I have a problem on CUBE at call routing from SIP server by provider to CUCM.

Attached files are config and debug output (debug ccsip all, debug voip ccapi inout)

SIP by provider is on UDP and SIP for CUCM is on TCP.

Call from IPT(CUCM 10.106.199.5,10.106.199.7,10.106.199.133) to SIP server 192.168.1.7 works, but call from SIP server 192.168.1.7 to CUCM 10.106.199.7 does not work.

The debug output does not contain significant failure, but there is no response message to SIP server 192.168.1.7.

What will be suppressing the process of call from SIP server ?

Platform is Cisco2951 and IOS version is 15.4(3)M5

And we ordered it with CUBE (bundled 25 +25 session) license

Regards,

2 Accepted Solutions

Accepted Solutions

Leszek Wojnarski
Cisco Employee
Cisco Employee

Hi,

Indeed there is not clear error why the CUBE doesn't send any SIP message but it looks like the call is not successful because of the following error:

Jun 30 04:28:40.990: //-1/xxxxxxxxxxxx/SIP/Info/critical/512/sipConnectionManagerUnregisterCtxtInConnection: Could not find conn holder for addr=192.168.1.7
Jun 30 04:28:40.990: //1193/E1DADE1E854D/SIP/Transport/sipSPITransportContextCleanup: Could not purge context gcb=0x15C3A078 from the connection; gcb might be locked

I don't know how to clearly read this. But what me good to try is 1 thing to try if possible,:

1. Change to TCP on telco site

Maybe other guys on the forum have some more suggestions.

Leszek

View solution in original post

Deepak Mehta
VIP Alumni
VIP Alumni

Two things,

1) You have bind commands on local LAN interface for both traffic for CUCM and also for CUBE.

Does your ITSP talk to you on local LAN interface , do you have routing in place?

2) I can see h323 bind is also configured on the same LAN interface which is being used for SIP , is it delibrate ?

View solution in original post

7 Replies 7

Leszek Wojnarski
Cisco Employee
Cisco Employee

Hi,

Indeed there is not clear error why the CUBE doesn't send any SIP message but it looks like the call is not successful because of the following error:

Jun 30 04:28:40.990: //-1/xxxxxxxxxxxx/SIP/Info/critical/512/sipConnectionManagerUnregisterCtxtInConnection: Could not find conn holder for addr=192.168.1.7
Jun 30 04:28:40.990: //1193/E1DADE1E854D/SIP/Transport/sipSPITransportContextCleanup: Could not purge context gcb=0x15C3A078 from the connection; gcb might be locked

I don't know how to clearly read this. But what me good to try is 1 thing to try if possible,:

1. Change to TCP on telco site

Maybe other guys on the forum have some more suggestions.

Leszek

Hello Leszek,

Though I have not asked provider about option of SIP over TCP, it will not be possible since their equipment for the service is rather old platform.

I will keep your suggestion as one of resort.

Regards,

-----

Koji Baba

Deepak Mehta
VIP Alumni
VIP Alumni

Two things,

1) You have bind commands on local LAN interface for both traffic for CUCM and also for CUBE.

Does your ITSP talk to you on local LAN interface , do you have routing in place?

2) I can see h323 bind is also configured on the same LAN interface which is being used for SIP , is it delibrate ?

Deepak,

1) actually SIP server is configured LAN IP address as source of SIP session. and there is no routing issue between SIP server and CUBE.

2) h323 will be planned to be used for call on ISDN to separate session counter between SIP and ISDN. In case SIP to CUCM is the cause of issue, we might consolidate every session to h323 dial-peer

Regards,

----

KojiBaba

k-baba
Level 1
Level 1

Sorry, but I clicked "correct answer" mistakenly.

I noticed

voice service voip

mode border-element license capacity 50

will enable control on media pass method and codec complexity for CUBE session.

I will try it and test again.

-----

Koji Baba

Hi Koji,

One suggestion for testing.

Can you try changing session destination port from 5062 to 5060 and then test inbound calls.

Cause I can see when we send calls are send to 5062 but incoming from 5060, normally this should not cause any issue, but would be nice to test, as this is just a quick test.

Leszek

k-baba
Level 1
Level 1

Just a follow-up on this thread.

The missing debug events seemed to be caused by taking huge message with "terminal monitor".

I could complete debug output by "show logging" from buffer.

The cause of disconnection was "SIP/2.0 422 Session Timer too small".

Because it was not accepted to change service parameters on CUCM, I advised following config as a tentative solution, and they said it solved the issue.

voice class sip-profiles 20

request INVITE sip-header Min-SE modify "180" "1800"

request INVITE sip-header Session-Expires modify "180" "1800"

request REINVITE sip-header Min-SE modify "180" "1800"

request REINVITE sip-header Session-Expires modify "180" "1800"

!

dial-peer voice 11 voip

voice-class sip profiles 20

!

Sorry, but I could not get debug of successful call after applying the config.

regards,

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: