SIP Trunk Configuration Problems

[James Burns]

Hi,

Have recently created SIP Trunks as a means of an intercluster trunk to a third party telephone system.

Have created Route Pattern, Route List and Route Group which contains 2 SIP Trunks. Also created New Non Secure SIP Trunk Profile for the SIP Trunks. SIP Trunks using the Standard SIP Profile

My telephone is a 7965 using SCCP.

Route pattern 443X created to use SIP Trunk using standard port of 5060.

Have checked partitions and calling search spaces and these look correct.

Problem is that I receive engaged tone when dialling any 4-digit 443X extension.

CUCM version 7.1.3

Screenshot of SIP Trunk attached.

Thanks for any assistance.

James

[chrysostomos1980]

Hi James

What is the remote PBX

What about the incoming calls from this destination

If the phones are into partition then for the incoming parameteres into the sip trunk(css )

Try to uncheck teh MTP into teh trunks

Finally enable details traces into the cucm do the call and collect the traces form RTMT

Please rate all useful posts

Regards
Chrysostomos

""The Most Successful People Are Those Who Are Good At Plan B""

[Ben Morgan]

If you are to keep Require MTP on the Trunk, I have found in the past I have needed to actually specify the MRGL on the trunk and rely on the Trunk referencing the MRGL via the Device Pool.

In your case ensure you have a G711alaw mtp resource available or a Transcoder available depending on the Codec used on the third-party PABX.

But like Chrysostomos mentioned, if you enable SIP traces via the serviceability page, then try the call a couple of times. Collect the traces and post them up.

Ben

[James Burns]

Ben,

Thanks for the info so far. [and to Chrysostomos1980]

Sorry but I have been trying to track down the relevant file in RTMT but without success, for the last couple of days. I have made a number of calls to the range of extensions over the last couple of days so there will be multiple records but cannot find the relevant log file.

[Ben Morgan]

James,

Normally, I'll make a few calls then go to RTMT and collect logs based on the last 5 or 10 mins. That way RTMT provides the relevant logs etc.

Alternatively, if your CUCM is not busy you could tail the trace in the CLI, if you use putty, could log the session to get output on file.

admin:  file tail activelog /cm/trace/ccm/sdi/ recent

or

admin:  file tail activelog /cm/trace/ccm/sdl/ recent

make a call and wait to here the fast busy, then press 'Control-C' to stop the tail.

Ben

[James Burns]

Ben,

The live system is too busy to do the trace in the CLI. I could do this from our Development system but there are some subtle difference in the partitions & calling search spaces.

Do you know what I need to select in Trace & Log Central within RTMT to browse to the correct file.

Thanks

James

[James Burns]

Hi Ben,

Sorry, ignore my previous post. Please find attached the log from a call attempt from my extension 6065 on a SCCP phone to 4430 which is the destination extension.

Thanks

James

[chrysostomos1980]

Hi

It looks that you didnt enable details sip traces

Please rate all useful posts

Regards
Chrysostomos

""The Most Successful People Are Those Who Are Good At Plan B""

[Jagpreet Singh]

Hi James,

     The file attached had no traces. Go to CUCM Serviceability >> Traces >> Configuration and make sure that the traces are set exactly like the image which I am attaching along.

Make a test call, when it fails, collect the CCM traces for the last 10 minutes and share with us with the call details.

Thank you.

Regards,

Jagpreet

[James Burns]

Hi All,

Thanks for the screenshot, that was most helpful. I made a couple of calls earlier and have captured the traces for one of them.

My extension is 6065, phone MAC FCFBFBCBE79A. Destination extension 4431.

Phone model is Cisco 7965 and destination is an IPC Unigy Dealerboard system.

Thanks for your help.

James

[Ayodeji Okanlawon]

James,

Unfortunately you have sent the SDL log files. Looking at the SDL logs I can see this..

TransType=1 PeerAddr = 10.134.117.9:5060 Sip_disc_cause= 403 cause=57 isReasonHdrVal= T

065159714| 2013/07/25 08:27:51.298| 009| SdlSig    | SIPDisconnInd                         | incoming_call_proceeding9     | SIPCdpc(9,100,55,36)            | SIPD(9,100,54,16)               | (9,100,45,1).13775-(*:10.134.117.9)     | [R:NP - HP: 0, NP: 0, LP: 0, VLP: 0, LZP: 0 DBP: 0] CcbId= 13745 --TransType=1 PeerAddr = 10.134.117.9:5060 Sip_disc_cause= 403 cause=57 isReasonHdrVal= T

To know in detail whats going on..we need you to send the SDI trace files..When you download the traces, there are tow of them SDI and SDL...We need the SDI file

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

[James Burns]

Thanks for the info, I have now attached the SDI trace.

James

[Ayodeji Okanlawon]

James,

The 3rd party telephone system is disconnecting the call. The reason ius higlighted below. You need to speak with whoever manages the phone system and ask them what Unknow CDI or trunk mean. In SIP 403 means forbidded. So for some reason the 3rd part phone system is rejecting your call. It could be it doesnt allow calls from the ip address you are using or the extension you are calling from

07/25/2013 08:27:51.298 CCM|//SIP/SIPTcp/wait_SdlReadRsp: Incoming SIP TCP message from 10.134.117.9 on port 5060 index 17 with 602 bytes:

SIP/2.0 403 Unknown CDI or Trunk

To: <4431>;tag=2be5ee5b

Via: SIP/2.0/TCP 10.134.116.22:5060;branch=z9hG4bK3b5cdf75e3

Allow: INVITE

Reason: SIP;cause=403;text="Unknown CDI or Trunk"

Call-ID: b542bb00-1f01d377-3c-1674860a@10.134.116.22

User-Agent: Cisco-CUCM7.1

From: "James Burns" <6065>;tag=6ae15877-0eae-4822-815b-b16d51ba29ba-157564882

Max-Forwards: 70

Date: Thu, 25 Jul 2013 07:27:51 GMT

Call-Info: ; security= NotAuthenticated; gci= 9-2919281

Expires: 180

CSeq: 101 INVITE

Content-Length: 0

Allow-Events: presence

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

[James Burns]

Fantastic, that did the job!

We now have both inbound and outbound calls working successfully between the two systems. I had previously provided the Publisher IP address to use. This has now been replaced with the IP addresses of our Subscriber servers.

Thanks very much for your help .

James

[Ayodeji Okanlawon · Accepted solution]

Glad to help. You can mark the thread as answered..It helps others to identify helpful threads

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"