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 ?
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.
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 !
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.
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.
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.
*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
*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'
*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
*Mar 12 13:43:49.001: ISDN BR2/0 EVENTd: process_disconnect: Raw Release Message
*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.
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.
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 !
Tried setting the following command on the GW
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 ??
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.
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,