CCS Trace

[nappyshock]

Can anyone help debugging a ccs trace....

The background, i'm connecting a 3300 with a Cisco Call Manager via a SIP trunk and all is working fine execept for one senario. When a Cisco device calls a Mitel device that is set to call forward to a Cisco device it crashes the Call Manager. Both systems are using 4 digit extensions and both sides are set to route via the SIP trunk when a 22 is used as a leading digit, they are both also configured to insert a 22 in the call info so they both receive a six digit 22xxxx number.

This trace is taken on the 3300 where a Cisco ext 3615 is calling a Mitel ext 7516 that is call forwarding to a cisco ext 3230 (223230).


15:02:25 RIL DPN PEER Massy-sip 179 2B ISRM_I
;10;*3#*19*Z#*58*Ca*1*Z#*100*3615-RaphaelGAM#
15:02:25 RIL DPN PEER Massy-sip 179 28 SSRM_C
*58*CW*l[tp@@@@@]Nd;7E;p#*50*223615#227516
15:02:25 ROL DPN PEER Massy-sip 180 2B ISRM_I
;10;*3#*19*Y#*58*Ca*1*Z#*100*3615-RaphaelGAM#
15:02:25 ROL DPN PEER Massy-sip 180 2C SSRM_I
*58*CW*l[tp@@@@@]Nd;7E;p#*50*223615#*37F*7516#
15:02:25 ROL DPN PEER Massy-sip 180 21 SSRM_C
*58*C4*1*01*01#*58*C6*001#223230
15:02:25 RIL DPN PEER Massy-sip 180 7 NIM *51*3#
15:02:25 ROL DPN PEER Massy-sip 179 7 NIM *51*3#
15:02:38 RI1030 DPN A CCM *58*CP*G#
15:02:57 RIL DPN PEER NIL_PEER_ 180 17 CRM/CIM ;1C;*58*C2*G*504#*234*Y`#
15:02:57 ROL DPN PEER Massy-sip 179 17 CRM/CIM ;1C;*58*C2*G*504#*234*Y`#

Unfortunately this is the only trace i have as i had to cut short the job for the weekend but i'm back Monday.

Does anything look unusual to anyone that can understand it.

Thanks

 

[Bigsin]

It's not clear for me why you are sending the digits 22 to the Mitel and Cisco.
How you are deleting the 22 in the Mitel? Trunkservice or are you using speedcalls for it?

Same question for the Cisco.

I think it's going wrong in the next lines.

15:02:25 ROL DPN PEER Massy-sip 180 2C SSRM_I
*58*CW*l[tp@@@@@]Nd;7E;p#*50*223615#*37F*7516#
15:02:25 ROL DPN PEER Massy-sip 180 22 SSRM_I
*58*C4*1*01*01#*58*C6*001#223230

In these lines the Mitel is telling the Cisco that extension 7516 is forwarded(*37F*7516) to extension 223230 .

The Cisco is receiving the extension number 7516. I don't know if te Cisco can handle 7516 instead of 227516. I think for the Cisco the extension number is a unknown number.

I had in the past also a few forwardings problems with the Mitel connected to different PABX systems. We always solved the issues in the other PABX not in the Mitel. In the Mitel you can't change 7516 into 227516 in this forwarding case, because the forwarding is not going through the ARS or Speedcalls.

 

[nappyshock]

The 22 digits are sent as the two sites four digit extension numbers overlap, the incoming 22 is absorbed in the trunk. What is done in the Cisco i have no idea as that is being handled by a another engineer (different company) on a remote site, it's a little hard to get detailed info as the Cisco site is in France and i'm in the UK so there is a bit of a language barrier, but saying that it has gone very well so far except for this one issue.

Thanks for your reply Bigsin it looks like you have identified the cause of the problem.
I'm using CPN substitution in the SIP peer profile to insert the 22 on the outgoing caller id so the Cisco see's the calls as coming from a 22xxxx number and it then knows it's from the Mitel. It looks like as you say the call forwarding is bypassing this. It seems as if the call forwarding has the information embedded a bit deeper in the programming and it is not subject to the rules you configure.

With the Mitel sending the 7516 instead of 227516 that will confuse the Cisco (make it crash in this case).

As you mentioned you have solved this in the past on the other PABX to the Mitel, I will try and explain this to the French Engineer and hope he has a solution, he seems like he knows his stuff.

Thanks again.

 

[Mitelpassion]

from the last two lines it appears the that routes go out of service, proabably cause the Call manager has crashed.

let us know how you get on in resolving this

 

[nappyshock]

This job has been put on hold as the Cisco Engineer has reported that Cisco believe there is a bug in their system.

When he says there is a bug i think it is the fact the Cisco System crashes not the call forwarding failing.

What I'm expecting when the job is re-scheduled is to find the call forwarding still not working but this time the Cisco system not crashing.

With Bigsins expanation of the call forwarding by-passing the ARS etc and the 4 digit extension being forwarded not the six digit, then i can't see it being resolvable on the Mitel side. I think it'll be down to what can be done on the Cisco side.

As a side note if they resolve the Cisco crashing then with everything except this one very seldom used senerio working, i can see the customer living with the setup.

I will let you know the outcome.

 

[nappyshock]

The bug fix has now been applied to the Cisco System and it has not resolved the issue, the Cisco System still crashes when a call is call forwarded to it.

Does anyone know of a way of disabling call forwarding to a group of Ext No's. If so i can disable call forwarding to the Cisco System and the problem will be resolved.

 

[kwbMitel]

This isn't a definitive answer although it might sound like one. If someone can prove me wrong then so be it.

If you can dial it, you can forward to it.

*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.

 

[Bigsin]

I think you have to ask the Cisco engineer if it's necessary to receive the digits 22 with incomming calls.

If there is a solution it is not not necessary any more you can absorb the 22 in the ARS of the Mitel.
Now the Cisco expects 22xxxx, but receives on this moment xxxx during call forwarding.

I don't do promisses, but you can try it.

 

[nappyshock]

Thanks for the suggestions guys, i didn't think there was an easy answer. I will look at geting rid of the need for the 22.

 

[nappyshock]

If i only used the 22 at both ends to route the call over the SIP trunk and striped the 22 in the ARS as it left the Mitel. What would be the scenario if there was a call for example from the Cisco that arrived over the SIP trunk to an extension number on the Mitel system, but the extension number of the Cisco device calling was an extension number that already existed on the Mitel system (a duplicate ext number). Would the Mitel be able to establish communication because it knows to send return traffic over the SIP trunk and the number of the caller is irrelevent or would it just get confused because the caller is an extension number that already exists on it's own system.

 

[kwbMitel]

If I understand your question correctly, the Mitel does not care what the calling device DN is and will route the call to the Local DN based on received digits and respond to the remote phone via the established route. Or to put another way, once the call is established the routing would be by IP not DN.

The only reason for the end points to receive the routing digits (22) is if there is alternate routing available. For example if there were 3 systems with respective routing digits of 21, 22, and 23, routing could be designed to route thru 1 system to another either for redundancy (Mesh networking) or for cost savings (Hub and Star).

If the call to the system will always terminate to a local DN then there is no reason for the routing digits to be received.

*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.