cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
815
Views
0
Helpful
14
Replies

present calling/originating number on outgoing PRI calls

lkc
Level 1
Level 1

I've got a lot of users dialing out using a PRI connected to a 53XX. I would like to present their DID number when dialing out but for some reason i do not present the number when doing outward dialing.

doing a "debug isdn standard" shows me that:

2w4d: ISDN Se3/0:15 EVENTd: pak_private_number: Calling Number IE is being stripped

2w4d: ISDN Se3/0:15 EVENTd: pak_private_number: called type/plan overridden by call_decode

2w4d: ISDN Se3/0:15 EVENTd: pak_public_number: Calling Number IE is being stripped

and i don't have a clue as to why this is happening.

Anybody have any pointers ?

Regards

Lasse

14 Replies 14

horst.wagner
Level 1
Level 1

Hi Lasse,

I´ve the same bullshit on a 1760 with BRI´s. Any time I dial out from a fxs-port attached Phone over the BRI on the same the calling number is stripped with the same debug- reason.

Unfortunately like you I´ve no idea what to do against it. Maybe because the source is a analog phone or fax. With IP-Phones I do not have the problem. Also a analog phone/fax attached to a ATA-Box does not show the problem. If I dial from the fxs over a voip-dialpeer and than out the BRI it also does not show the problem. Only if the fxs´s are in the same router as the bri it strips the calling party number.

So I think we have the same problem.

Unfortunately this won´t help you directly but shows that also others a facing the same problem. To me it looks like a bug.

regards

Horst

Any time you have an issue with ISDN, get the debug ISDN Q931 debug logs and put them in the post. Without these we can't give you a firm idea of the problem. Also a basic diagram showing call flow helps.

If you have a FXS port on the 1760, add the command 'answer-address NNNN' where NNNN is the number you want to appear as the calling number of the FXS port. When the FXS port makes a call, this will be used as the ANI for the outgoing Q931 setup message.

Don't forget that most Telcos won't allow you to inject fake ANI towards them - if the calling number in the setup message does not match with what the switch has programmed into it as the registered number range on the particular ISDN service, then they will ignore the vlaue in the setup message, otherwise you could make malicious calls and they would not be traceable !

This may be what is happening wuth the AS5300 - if the ANI that comes in on one side of the network does not match with what the egress side is expecting, then it will be ignored by the remote network.

I agree on putting the debug ISDN q931 in the post but the "debug isdn standard" showed me what i expect is the problem.

I've got DID and the Telco tells me that they allow the DID range that i have as originating number.

The debug output gave me the idea that i'm at the end where the stripping occurs ? but could i be wrong about the ? I thought that the debug were pretty straightforward ?

What is the default setting on PRI's for calling number presentation ? It's been some time since i've fooled around with ISDN so i'm a bit rusty on that side !

Regards,

Lasse

Hi Lasse,

how are your users connected to the router?

IP-Phones, PABX with what interfaces, FXs´s with analog phones or what?

I agree with you that the debug shows your router is the one who strips the calling-party number. I got the same debug output and debug isdn q931 only shows that the router does not send a calling ID.

I´m convinced you are facing the same problem as me and may be if the answer-address helps me it should also help you.

I will trie today evening.

Horst

Debug ISDN Q.931 is the trace to use. That way you can see exactly what is being sent.

The trace you have posted shows the number is being stripped out, but the Q.931 may show the reason.

You should also look at the number type that you are sending, it's probably best to set the CLI to national and make sure you are sending the full national number by masking it in the Route group / Route List config.

More config info would help diagnose the problem.

Paul

..

.

Soory Sir,

your hint with the "answer-address" did not work. Waht I find logically because the router already konws the nimber by te destination pattern. However I tried answer-address NNNN and it was just the same as before. It smells like a bug.

I tried IOS 12.3(6),12.3(4)T3 and 12.3(7)T; all the same behaviour.

Following a debug ISDN q931 an isdn events detail:

router#deb isdn q931

debug isdn q931 is ON.

router#deb isdn event det

debug isdn event detail is ON.

router#

*Mar 12 13:43:39.326: ISDN BR2/0 EVENTd: isdn_get_guid: Got Guid F99FF39980D7Rec

eived pdata len 0x3F data:1C 39 9E 1 0 3 67 74 64 0 0 0 2E 49 41 4D 2C D A 47 43

49 2C 66 39 39 66 66 33 39 39 33 34 66 35 31 31 64 36 38 30 64 37 63 62 36 63 3

5 38 33 34 31 62 39 33 D A D A 1E 2 81 83

*Mar 12 13:43:39.330: ISDN BR2/0 EVENTd: process_bri_call: No name in GTD

*Mar 12 13:43:39.330: ISDN BR2/0 EVENTd: pak_private_number: Calling Number IE i

s being stripped

*Mar 12 13:43:39.330: ISDN BR2/0 EVENTd: calltrkr_setup_received: isdn_info=2202

512272l, call_id=0x8040 ORIGINATE

*Mar 12 13:43:39.330: ISDN BR2/0 EVENTd: calltrkr_setup_received: calltracker di

sabled

*Mar 12 13:43:39.334: ISDN BR2/0 Q931: TX -> SETUP pd = 8 callref = 0x3C

Bearer Capability i = 0x8090A3

Standard = CCITT

Transer Capability = Speech

Transfer Mode = Circuit

Transfer Rate = 64 kbit/s

Channel ID i = 0x81

Progress Ind i = 0x8183 - Origination address is non-ISDN

Called Party Number i = 0x80, '01728154711'

Plan:Unknown, Type:Unknown

*Mar 12 13:43:39.562: ISDN BR1/0 Q931: RX <- SETUP_ACK pd = 8 callref = 0xBC

Channel ID i = 0x89

*Mar 12 13:43:39.562: ISDN BR2/0 Q931: RX <- SETUP_ACK pd = 8 callref = 0xBC

Channel ID i = 0x89

*Mar 12 13:43:43.605: ISDN BR1/0 Q931: RX <- ALERTING pd = 8 callref = 0xBC

*Mar 12 13:43:43.605: ISDN BR2/0 Q931: RX <- ALERTING pd = 8 callref = 0xBC

*Mar 12 13:43:48.997: ISDN BR2/0 EVENTd: process_disconnect: call id 0x8040, cal

l type is VOICE, b_idb 0x8347BF98, ces 1, cause Normal call clearing(0x10)

*Mar 12 13:43:49.001: ISDN BR2/0 EVENTd: calltrkr_call_disconnected: isdn_info=0

x8347D964, call_id=0x8040

*Mar 12 13:43:49.001: ISDN BR2/0 EVENTd: process_disconnect: Raw Release Message

0x0501018040040802FF9008028090

*Mar 12 13:43:49.005: ISDN BR2/0 Q931: TX -> DISCONNECT pd = 8 callref = 0x3C

Cause i = 0x8090 - Normal call clearing

*Mar 12 13:43:49.114: ISDN BR1/0 Q931: RX <- RELEASE pd = 8 callref = 0xBC

*Mar 12 13:43:49.114: ISDN BR2/0 Q931: RX <- RELEASE pd = 8 callref = 0xBC

*Mar 12 13:43:49.118: ISDN EVENTd: cc_clear_free_list freed 0x82E62094

What is the calling number type specified on the gateway in Call Manager?

It looks like call manager is instructing the gateway that the calling number is private so the gateway is stripping it out.

Paul

I found the solution by myself.

First to paul --> There´s no callmanager involved in. Just calling from an FXs-Port out the isdn.

The solution is to configure "station-id number NNN"

and everything works fine.

Maybe Lasse this will also help you out of the dilemma?

In the documentation is written that this parameter only is useful for onnet-calls. So to me it looks furthermore like a bug and I found a workaround.

bye

Horst

I think my problem could be as simple as specifying the number type on the PRI as "unknown" and therefore the external side strips it !

But since my internal numbering is exactly the same as i would like to show as caller id (so i would not need to do any number transformations) then i cannot seem to find out how to change from unknown to national/international without having to modify the calling number ?

Any pointers !

Regards

Lasse

Tried setting the following command on the GW

int ser3/0:15

isdn map address . plan isdn type national

in the debug isdn q931 it shows me that it changes the numbering type from unknown to national. Great - although calling number is still being stripped

i even tried adding "isdn calling-number ........" ! have no idea as to whether it's possible. But it still does not work.

I have attached my debug isdn q931 and debug isdn standard.

Now i have absolutely no idea as to what might be wrong ??

Regards

Lasse

I don´t think the problem is on the isdn-interface, because clid is stripped before call-setup.

So how are your user phones connected?

Something lets the router believe it are private calls and so it hides the calling id.

regards Horst

You're absolutely right ! It was'nt the interface.

Just for the heck of it i remotely upgraded the router and now it works ! with no changes at all !

Never saw that one coming. Thanks all for the great pointers,

Lasse :-)

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: