Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

3300 ICP Call Forwarding to Mobile 1

Status
Not open for further replies.

CDEMitel

Technical User
Dec 16, 2010
9
GB
Hi All,

I am having trouble trying to pin point the issues experienced using call forwarding.

We are running a Mitel 3300 MXe II controller (version 4.2) with the majority of users as Hot Desk accounts, all our ingress/egress trunks are running SIP (we do not use E1/T1 PRI connections). The user has set their extension to forward all calls to their mobile (Call Forward Always), he is currently away on business in Malaysia.

The issue experienced is when an external caller dials his DDI extension the call should be forward to his mobile, unfortunately what happens is there is a 10 seconds delay in silence it rings once (on his mobile) and the call is pushed to our auto attendant greeting (if calls not answered it should push to his personal voicemail).

I have checked the users COS, COR along with the interconnect timer which all seems connect.

I have tested call forwarding from my extension to my mobile (Both in the UK) and dialling from an external source which works without issue and allows more than one ring for me to answer and if I don't answer the call will be redirected to my voicemail (this is expected).

I have run CCS traces to try and find the path the call will take before being diverted to the auto attendant, but the only difference in comparison to the traces captured when forwarding to my mobile is the following line:

09:57:12 ROL DPN PEER <Primary SIP Trunk> 251 C SSRM_C <Forwarded Mobile Number>

My question is, is there any other traces I can perform to find any errors in the path the call takes before it is bounced to the auto attendant?

Any tips or troubleshooting suggestions are welcome.
 
Sorry made a mistake...

The CCS trace line that looks out of place is the following:

09:57:21 RIL DPN PEER NIL_PEER_ 250 A CRM/CIM ;30;*234*Gp#

All other lines look OK in comparison
 
The call is being cleared down from the other end. The reason is a lott better to see by using the EDT trace.
EDT tr tsp l2l3 x x x x, where x x x x is plid info.
Look at the Disconect message to see what the reason for cleardown is.
 
Thanks for the reply DoubleUT, unfortunately we do not use BRI, PRI or QSIG for data signalling through ISDN, we have redundant SIP trunks to our service provider who handle the breakout to the PSTN. So when I run the suggested command I do not receive any data back from the system.

Thanks for the tip though
 
Sorry for that....................
You've already wrote that you where using SIP.
A wireshark trace would clarify a lot. Otherwise use the 3300 to trace the SIP messaging.
type the following commands:

SIP all set storage C
SIP all set level 3
SIP all trace on

when finished type:

SIP all trace off

You shoud see the crear message and work from there.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top