Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

Extension Issue

Hi Greetings

We are facing an issue in our organization. We have connected two ip phones with extentions 6901 and 6902. Extension to extension call is happening. When we call from a mobile or landline the call is landing on 6902 without any issues. In the similar way if we call the call is not landing on 6901. If we recreate the extention from 6901 to any other extention the call from pstn gets landed on it. we are able to make calls from 6901 across the pstn. I have attached the logs taken when the incomming call is made. 9663381809 is the number from which call is made. 07580226901 is the number which the call lands.We searched for duplicate enteries but did not find any.

Please look into this issue and provide a workaround on this.


Re: Extension Issue

Hi Greetings

This is to update to the previous . Please find the below SDL logs

Called Party Number:- 6901

Calling Party Number:- 9909944753

Party=41302624 DevId=(0,0,0) dn=:tn=0npi=1nd=6901pi=0si1 matchDialPartition=6cee09cc-4e27-ff1d-fbec-30b659d2b214 matchDialPattern= matchInterceptPartition=6cee09cc-4e27-ff1d-fbec-30b659d2b214 matchInterceptPattern=6901 ignoreIntercept = 0 MLPP Enable=F isCallerExternal=T PL=5

PLDmn=0 cgpn=:tn=2npi=1nd=9909944753pi=0si3 matchIntPatternCss=6901:6cee09cc-4e27-ff1d-fbec-30b659d2b214 preXCdpn=:tn=0npi=0nd=6901pi=0si0


lPart= lPatt= lModNum=tn=2npi=1nd=9909944753pi=1si3 lName=locale: 1 Name:  UnicodeName:  pi: 0 cName=locale: 1 Name:  UnicodeName:  pi: 0

cn:tn=0npi=0nd=6901pi=1si0 cVMbox= lCnPart=6cee09cc-4e27-ff1d-fbec-30b659d2b214 lCnPatt=6cee09cc-4e27-ff1d-fbec-30b659d2b214 rn:tn=0npi=0nd=6901pi=0si0

lLRPart=6cee09cc-4e27-ff1d-fbec-30b659d2b214 lLRPatt=6cee09cc-4e27-ff1d-fbec-30b659d2b214 lOCdpnPart=6cee09cc-4e27-ff1d-fbec-30b659d2b214

In the above SDL traces can anyone confirm whether the matchDialPartition=6cee09cc-4e27-ff1d-fbec-30b659d2b214 matchDialPattern= matchInterceptPartition=6cee09cc-4e27-ff1d-fbec-30b659d2b214 matchInterceptPattern=6901

Is the correct sequence for the call maturing or is there any guide to correctly interept these traces

Message was edited by: rjose52727

New Member

Re: Extension Issue


I experienced a similar problem some years ago when implementing VoIP in our company. I am not sure if it is applicable to you but you have to find out from your PSTN company. In my case our PSTN supplied us with six PRI's with number ranges from e.g. 0114311000 to 0114312799. However, when we allocated extensions we discovered that it was impossible to receive external calls from the PSTN/Cellphone destined for  any extensions  from 0114311001 to 0114311005 (The first five) Then it was confirmed by the PSTN that they have reserved the first 5 numbers for their billing purposes. So I guess there is one number reserved per PRI, hence we had 6 PRI's. Just find out from your PSTN company.

Re: Extension Issue



Thank you very much for the update. Is it possible to decode the numerics which is highlighted in red. Please we are eager to find where the call is getting matched.

Super Bronze

Re: Extension Issue


The references to partitons are made by PKID, which is a unique key in the DB.

Try this from the server CLI:

run sql select * from routepartition where pkid = '6cee09cc-4e27-ff1d-fbec-30b659d2b214'

Type carefully.



Please rate helpful posts...

Aaron Please remember to rate helpful posts to identify useful responses, and mark 'Answered' if appropriate!

Re: Extension Issue


Thank you for your valuable information. I have also rated for the same. Please guide me to know if the logs which we have highlighted is the normal flow of call mature or is there any deviation from it.

Super Bronze

Re: Extension Issue


First thing  - your DNA outputs aren't suited to troubleshooting an inbound call. The DNA analysis you have done shows what may happen when 6901 or 6902 dial out to the PSTN, not the other way... What you want to do is see what happens when the gateway tries to reach the internal extension number.

1) Use DNA like so:

Analysis/Gateways, Find, select your gateway, and then click the port on the gateway which the call is arriving on.

Set Dialed Number to what the service provider sends you (i.e. what you see in a debug isdn q931 on the gateway when the call is attempted - often this is the last 4 digits of the DDI number e.g. 6901).

Set caling number to whatever you like (as we aren't routing based on this it doesn't matter).

Post back the output.

2) Numbering plan :

I noticed you have multiple instances of 6901 and 6902 :

6901,,FAX_PRT,Device,SEP002584A2095C,Auto 1328

6901,,BRREF_CUG_PRT,Device,SEP002584A2095C,Auto 1328

6902,,FAX_PRT,Device,SEP002584A20ABB,Auto 1329

6902,,BRREF_CUG_PRT,Device,SEP002584A20ABB,Auto 1329

Why is this?



Aaron Please remember to rate helpful posts to identify useful responses, and mark 'Answered' if appropriate!