[cisco-voip] Recieved Calls List Digits Lose Prefix
Ruben Montes (EU)
Ruben.Montes at eu.didata.com
Tue Aug 1 06:32:44 EDT 2006
Hi Nick,
thanks for your quick response... I'm from Spain, but customer also needs 0 to be prepended to make any external call. If you're using translation rules, I assume you're using H323 as signaling protocol. I think this solution doesn't fit for my customer because they're using MGCP and, for my understanding, translation rules are not applied to the call in this case.
Many thanks,
Ruben
________________________________
De: Nick Kassel [mailto:Nick.Kassel at Charles-Stanley.co.uk]
Enviado el: mar 01/08/2006 12:18
Para: Ruben Montes (EU)
CC: cisco-voip at puck.nether.net
Asunto: RE: [cisco-voip] Recieved Calls List Digits Lose Prefix
Hi Ruben
As you can see from the debug below we get the number provided without the 0, so we have added the following translation rules to our gateways to prefix whatever number comes in with a 90, we do not do any configuration on the call manager for this just on the gateway. Are you in the UK too?
translation-rule 1
Rule 0 ^0.% 900
Rule 1 ^1.% 901
Rule 2 ^2.% 902
Rule 3 ^3.% 903
Rule 4 ^4.% 904
Rule 5 ^5.% 905
Rule 6 ^6.% 906
Rule 7 ^7.% 907
Rule 8 ^8.% 908
Rule 9 ^9.% 909
!
Regards
Nick
________________________________
From: Ruben Montes (EU) [mailto:Ruben.Montes at eu.didata.com]
Sent: Tuesday, August 01, 2006 11:04 AM
To: Nick Kassel
Subject: RE: [cisco-voip] Recieved Calls List Digits Lose Prefix
Hi Nick,
I'm trying to do the same you've done succesfully: prepend a number to the received calls in order to permit the user to hit the dial key without editing the number. I've tried to use the NAtional prefix, International prefix, etc with no luck...
Can you please explain me with some detail which method are you using?
Thanks in advance,
Ruben
________________________________
De: cisco-voip-bounces at puck.nether.net en nombre de Nick Kassel
Enviado el: mar 01/08/2006 11:50
Para: Fedorov, Konstantin; cisco-voip at puck.nether.net
Asunto: Re: [cisco-voip] Recieved Calls List Digits Lose Prefix
I have listed the 2 debugs below but they appear to be the same, am I missing something here?
Here is the debug from Colt which works fine.
*Aug 1 08:42:35.373: ISDN Se0/0/0:15 Q931: RX <- SETUP pd = 8 callref = 0x18F3
Bearer Capability i = 0x8090A3
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA1839E
Preferred, Channel 30
Progress Ind i = 0x8481 - Call not end-to-end ISDN, may have in-band info
Calling Party Number i = 0x2083, '2079532000'
Plan:Unknown, Type:National
Called Party Number i = 0xA1, '496515'
Plan:ISDN, Type:National
Sending Complete
*Aug 1 08:42:35.385: ISDN Se0/0/0:15 Q931: TX -> CALL_PROC pd = 8 callref = 0x98F3
Channel ID i = 0xA9839E
Exclusive, Channel 30
*Aug 1 08:42:35.413: ISDN Se0/0/0:15 Q931: TX -> ALERTING pd = 8 callref = 0x98F3
Progress Ind i = 0x8188 - In-band info or appropriate now available
*Aug 1 08:42:37.269: ISDN Se0/0/0:15 Q931: TX -> CONNECT pd = 8 callref = 0x98F3
*Aug 1 08:42:37.321: ISDN Se0/0/0:15 Q931: RX <- CONNECT_ACK pd = 8 callref = 0x18F3
*Aug 1 08:42:40.069: ISDN Se0/0/0:15 Q931: RX <- DISCONNECT pd = 8 callref = 0x18F3
Cause i = 0x8090 - Normal call clearing
*Aug 1 08:42:40.073: ISDN Se0/0/0:15 Q931: TX -> RELEASE pd = 8 callref = 0x98F3
*Aug 1 08:42:40.121: ISDN Se0/0/0:15 Q931: RX <- RELEASE_COMP pd = 8 callref = 0x18F3
London_PRI1#
Here is the BT debug
*Mar 13 18:02:13.989: ISDN Se1/0:15 Q931: RX <- SETUP pd = 8 callref = 0x0001
Sending Complete
Bearer Capability i = 0x8090A3
Standard = CCITT
Transer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98381
Exclusive, Channel 1
Calling Party Number i = 0x2180, '2071496515'
Plan:ISDN, Type:National
Called Party Number i = 0x81, '671503'
Plan:ISDN, Type:Unknown
*Mar 13 18:02:14.021: ISDN Se1/0:15 Q931: TX -> CALL_PROC pd = 8 callref = 0x8001
Channel ID i = 0xA98381
Exclusive, Channel 1
*Mar 13 18:02:14.193: ISDN Se1/0:15 Q931: TX -> ALERTING pd = 8 callref = 0x8001
Progress Ind i = 0x8188 - In-band info or appropriate now available
*Mar 13 18:02:21.241: ISDN Se1/0:15 Q931: TX -> CONNECT pd = 8 callref = 0x8001
*Mar 13 18:02:21.309: ISDN Se1/0:15 Q931: RX <- CONNECT_ACK pd = 8 callref = 0x0001
________________________________
From: Fedorov, Konstantin [mailto:kfedor at amt.ru]
Sent: Tuesday, August 01, 2006 9:24 AM
To: Nick Kassel; cisco-voip at puck.nether.net
Subject: RE: [cisco-voip] Recieved Calls List Digits Lose Prefix
Hi, Nick.
Compare isdn traces ( debug isdn q931) from BT and Colt, where you don't have problem.
That give you answer what wrong in the BT.
I assume that after connect BT send connected number IE, which is not translated.
If you can. Send this traces to the list.
-----------------------
Sincerely Yours,
Konstantin Fedorov
________________________________
From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Nick Kassel
Sent: Tuesday, August 01, 2006 12:06 PM
To: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] Recieved Calls List Digits Lose Prefix
Has any one come across this before or have any ideas?
________________________________
From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Nick
Sent: Monday, July 31, 2006 11:54 AM
To: cisco-voip at puck.nether.net
Subject: [cisco-voip] Recieved Calls List Digits Lose Prefix
We have an issue with a number of remote sites with the Recieved calls list, on the gateways we have added the translation rules to prefix the digits with a 90, the telco (BT in UK) sends the digits without the zero such as 207XXXXXXX, the translation rule prefixes the 90 so incoming calls show as 90207XXXXXXX so therefore if the call is missed the Missed calls list will show the correct number and they can just hit dial, however as soon as the call is connected by someone answering it the 90 gets droppped. This is currently happening on all our sites with the telco BT, but not on our PRI provided by Colt at HQ site. The translation rules are the same for all our gateways including Branch and HQ. I presume that the telco will be able to make the change but does anyone know what needs to be changed in order for me to communicate the issue to the telco efficiently.
***********************************************************************************************
The information contained in this e-mail is strictly confidential, some or all
of which may be legally privileged. It is for the intended recipient only.
Access to this e-mail by any other person is prohibited. If you are not the
intended recipient, any use, disclosure, copying, printing, distribution of,
replying to or any action taken or omitted to be taken in reliance on this
e-mail, is prohibited and may be unlawful. Please contact the sender immediately
should this e-mail have been incorrectly addressed or transmitted.
You accept that any instructions are deemed to have been given at the time the
recipient(s) accesses them and that delivery receipt does not constitute
acknowledgement or receipt by the intended recipient(s). You accept that there
may be a delay in processing the instructions received from e-mails after
Charles Stanley has received them. You are advised that urgent, time sensitive
and confidential communications should not be sent by e-mail.
You acknowledge that e-mails are not secure and you accept the risk of
malfunction, viruses, unauthorised interference, mis-delivery or delay.
************************************************************************************************
Charles Stanley & Co. Ltd
Registered Office: 25 Luke Street London EC2A 4AR
Tel: 0207 739 8200 Fax: 0207 739 7798
Registered in England No. 1903304
Charles Stanley Sutherlands and Charles Stanley Securities are divisions of Charles Stanley & Co. Ltd
Authorised and Regulated by the Financial Services Authority, Member of the
London Stock Exchange, International Securities Markets Association, and The London International Financial Futures &
Options Exchange.
This footnote also confirms that this email message has been swept by McAfee
VirusScan and SurfControl Email Filter software.
***********************************************************************************************
The information contained in this e-mail is strictly confidential, some or all
of which may be legally privileged. It is for the intended recipient only.
Access to this e-mail by any other person is prohibited. If you are not the
intended recipient, any use, disclosure, copying, printing, distribution of,
replying to or any action taken or omitted to be taken in reliance on this
e-mail, is prohibited and may be unlawful. Please contact the sender immediately
should this e-mail have been incorrectly addressed or transmitted.
You accept that any instructions are deemed to have been given at the time the
recipient(s) accesses them and that delivery receipt does not constitute
acknowledgement or receipt by the intended recipient(s). You accept that there
may be a delay in processing the instructions received from e-mails after
Charles Stanley has received them. You are advised that urgent, time sensitive
and confidential communications should not be sent by e-mail.
You acknowledge that e-mails are not secure and you accept the risk of
malfunction, viruses, unauthorised interference, mis-delivery or delay.
************************************************************************************************
Charles Stanley & Co. Ltd
Registered Office: 25 Luke Street London EC2A 4AR
Tel: 0207 739 8200 Fax: 0207 739 7798
Registered in England No. 1903304
Charles Stanley Sutherlands and Charles Stanley Securities are divisions of Charles Stanley & Co. Ltd
Authorised and Regulated by the Financial Services Authority, Member of the
London Stock Exchange, International Securities Markets Association, and The London International Financial Futures &
Options Exchange.
This footnote also confirms that this email message has been swept by McAfee
VirusScan and SurfControl Email Filter software.
***********************************************************************************************
The information contained in this e-mail is strictly confidential, some or all
of which may be legally privileged. It is for the intended recipient only.
Access to this e-mail by any other person is prohibited. If you are not the
intended recipient, any use, disclosure, copying, printing, distribution of,
replying to or any action taken or omitted to be taken in reliance on this
e-mail, is prohibited and may be unlawful. Please contact the sender immediately
should this e-mail have been incorrectly addressed or transmitted.
You accept that any instructions are deemed to have been given at the time the
recipient(s) accesses them and that delivery receipt does not constitute
acknowledgement or receipt by the intended recipient(s). You accept that there
may be a delay in processing the instructions received from e-mails after
Charles Stanley has received them. You are advised that urgent, time sensitive
and confidential communications should not be sent by e-mail.
You acknowledge that e-mails are not secure and you accept the risk of
malfunction, viruses, unauthorised interference, mis-delivery or delay.
************************************************************************************************
Charles Stanley & Co. Ltd
Registered Office: 25 Luke Street London EC2A 4AR
Tel: 0207 739 8200 Fax: 0207 739 7798
Registered in England No. 1903304
Charles Stanley Sutherlands and Charles Stanley Securities are divisions of Charles Stanley & Co. Ltd
Authorised and Regulated by the Financial Services Authority, Member of the
London Stock Exchange, International Securities Markets Association, and The London International Financial Futures &
Options Exchange.
This footnote also confirms that this email message has been swept by McAfee
VirusScan and SurfControl Email Filter software.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://puck.nether.net/pipermail/cisco-voip/attachments/20060801/8e826b3f/attachment-0001.html
More information about the cisco-voip
mailing list