Call Forwarding with german ISDN provider

Unanswered Question
Jan 3rd, 2010

Hello,

In Germany we have a feature of the local provider called "Anrufweiterschaltung".
This is a feature where call forwarding is implemented at the providers switch-equipment using some commands initiated by the local ISDN-Switch.
The command to implement this feature is *21*CFN*MSN# (where CFN is the call forwarding number and MSN is the local MSN). This is implemented somehow via D-Channel (I dont konw exactly how).

Nearly every simple cheap ISDN switch in germany is aware of this feature but I could not find this function with CISCO UC520.


A big advantage for this feature is the availablity of keeping the 2 B-Channels of an ISDN free. With the UC520 a call-forwarding blocks two ISDN Channels and is therefore unusable for many of our customers.

Is there any solution to implement this feature with a CISCO UC520. I spent already many hours in finding a solution for this but was not successful.

Any hints are welcome.

reagards

hmk

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Marcos Hernandez Sun, 01/03/2010 - 08:50

Are you sure this star code feature is activated over the D channel? If so, what field is used to activate it? Called Number?

You could try to define in your CCA outgoing dialplan, an entry for *21. This should be very easy to do. If using CLI, you will need a POTS dial peer.


Let us know if you need more help.

Marcos

Hubert Mayr-Kne... Sun, 01/03/2010 - 09:23

Hello Marcos,

thanks for your response.

Indeed this is obviously a very tricky feature. I assume its activated via D-Channel according to a lot of documents and discussions I've been reading through.

There is an explanation of this feature form the provider, but it is in german, so might not be useful for you.

I tried the following dial-peer


dial-peer voice 1000 pots
destination-pattern *21*0171xxxxxxx*91xxxxx#        (x replaces digits to protect privacy)
port 0/1/1
forward-digits all

The resulting ISDN Q.931 debug looks like:

Jan  3 11:42:49.915 met: ISDN BR0/1/1 Q931: Applying typeplan for sw-type 0x1 is 0x0 0x0, Calling num 200
Jan  3 11:42:49.915 met: ISDN BR0/1/1 Q931: Sending SETUP  callref = 0x006E callID = 0x8704 switch = basic-net3 interface = User
Jan  3 11:42:49.915 met: ISDN BR0/1/1 Q931: TX -> SETUP pd = 8  callref = 0x6E
    Bearer Capability i = 0x8090A3
        Standard = CCITT
        Transfer Capability = Speech 
        Transfer Mode = Circuit
        Transfer Rate = 64 kbit/s
    Channel ID i = 0x81
        Preferred, B1
    Progress Ind i = 0x8183 - Origination address is non-ISDN 
    Calling Party Number i = 0x0080, '200'
        Plan:Unknown, Type:Unknown
    Called Party Number i = 0x80, '*21*0171xxxxxxx*91xxxxx#'    
(x replaces digits to protect privacy)
        Plan:Unknown, Type:Unknown
    Sending Complete
Jan  3 11:42:50.063 met: ISDN BR0/1/1 Q931: RX <- RELEASE_COMP pd = 8  callref = 0xEE
    Cause i = 0x829C - Invalid number format (incomplete number)

I have a standard ISDN-switch parallel on the BRI-Ports. When activating the feature with this phone, there is the following ISDN Q.931 Log on the UC520 which is obviously the answer from the provider-switch. I did not manage yet to get a log of the sending data.


Jan  3 11:09:14.299 met: ISDN BR0/1/1 Q931: RX <- FACILITY pd = 8  callref = N/A
    Facility i = 0x91A1300202E4F202010930270A01000A01003011A10F0A0102120A3137313x3x3x3x3x3x3xA10C0A0104120739313x3x3x3x3x
        Protocol Profile = Remote Operations Protocol
        0xA1300202E4F202010930270A01000A01003011A10F0A0102120A3137313x3x3x3x3x3x3xA10C0A0104120739313x3x3x3x3x
        Component = Invoke component
            Invoke Id = 58610
            Operation = Activate Diversion Notify
Jan  3 11:09:14.331 met: ISDN BR0/1/1 Q931: RX <- FACILITY pd = 8  callref = N/A
    Facility i = 0x91A203020101
        Protocol Profile = Remote Operations Protocol
        0xA203020101
        Component = Return Result component
            Invoke Id = 1

    (again x replaces digits to protect privacy)

I hope this informations are useful for you. Maybe there are other things I can try. Any help is welcome.

regards

Marcos Hernandez Sun, 01/03/2010 - 10:05

I see. The additional digits need to be delivered in the Facility IE, from what I can see. You could try the following under your BRI ports:

isdn outgoing ie facility

and also the global command

isdn gateway-max-interworking

Let me know if this helps.


Marcos

Hubert Mayr-Kne... Sun, 01/03/2010 - 10:50

Hello Marcos,

I did "isdn gateway-max-interworking"

The command "isdn outgoing ie facility" under the BRI interface responded with an error message "gateway-max-internetworking" already definded.

After trying to dial the command the follwoing error appeared:

Cause i = 0x82E39828 - Information element not implemented

Attached please find a log file of the ISDN Q.931 debug log.

regards.

Attachment: 
Marcos Hernandez Sun, 01/03/2010 - 12:33

I will take a look at the debug, but the error is probably caused by something unrelated to your original problem. I recommend that you open a TAC case. It's been a while since I last supported ISDN trunks and it is not clear to me whether we can do additional digits in a Facility IE/Keypad IE or not. Back in 2004 we couldn't, but maybe this changed. Notice this points to an issue with our broader ISDN code, and not something UC500 specific.

Thanks,


Marcos

Hubert Mayr-Kne... Mon, 01/04/2010 - 01:51

Hello Marco,

thanks for your continued support.

Can you tell me how to open a TAC-Case without having a service contract. I just bought the UC500 box with lots of differnet phones for testing purposes.

regards.

Steven Smith Mon, 01/04/2010 - 07:35

I believe you have 90 days to open a case from when you purchase the box.  A case can be opened up under warranty.

Hubert Mayr-Kne... Mon, 01/04/2010 - 11:35

Hello Steven,

thanks for that information, but my box is a bit older! I tested many things until I came to that problem.

regards

Steven Smith Mon, 01/04/2010 - 12:27

Does your ISDN provider require the sending complete IE?  I see it in the debugs, but was not sure if it was required.

Hubert Mayr-Kne... Tue, 01/05/2010 - 06:50

I'm not sure what my provider is expecting, because I do not know the exact protocol.

Perhaps someone can give me hint how to sniffer on the ISDN connection of my old ISDN-Switch and the Provider. This might clarify something.

I have various cisco-routers with isdn-ports. Perhaps I can use those for debugging, but I dont know how to put it in the line.

regards

Marcos Hernandez Tue, 01/05/2010 - 14:02

My internal queries have yielded no results. I am afraid that what you want to do here is not supported by the Cisco ISDN implementation.


Marcos

Hubert Mayr-Kne... Thu, 01/07/2010 - 12:07

It's really a pity, so much business in the SMB area will depend on a feature like this.

Is there any way to get this escalated!


Please let me know where I can put this feature request. Otherwise I see little chance for the UC500 series in the traditional ISDN countries.

regards

HMK

martinluginbuehl Thu, 01/07/2010 - 14:06

We have the same problem in Switzerland. A lot of clients need this feature.

Every help is welcome.

THX

Martin

David Harper Thu, 01/07/2010 - 20:04

I'm not sure how helpful this will be, but IOS supports two B-channel transfers on PRI interfaces using facility messages.  I'm not sure if the functionality as it is implemented in IOS is exactly the same as what you are using here, but if you have access to a PRI service to test with, it would be worth checking.  To enable the capability you need to configure 'isdn supp-service tbct' under the isdn interface.

Unfortunately even if this does work, it won't solve the immediate problem, as it has not been implemented for BRI interfaces.  But it would be much easier to extend the existing feature to support BRI than it would be to implement completely new functionality, so it is still worth testing if we can.

Cheers,

Dave.

Hubert Mayr-Kne... Fri, 01/08/2010 - 04:53

PRI will not be the answer. I will hardly find somebody using PRI with this feature (maybe its not even supported on PRI by the provider).

I will not even find somebody let me do tests on his PRI Interface.

So, thanks for the advice, but it will not help us.

Again, is there somebody within CISCO who could help us in solving this problem, or giving us the appropriate contacts!

regards

Marcos Hernandez Fri, 01/08/2010 - 06:44

I have been in conversations with some engineering folks. As it turns out, we might be able to forward any information in the Facility IE of a Q.931 Setup if we receive it properly encoded (ASN.1)  from the IP side (VoIP). This means the limitation is not really with our ISDN stack. In any case, this is not supported and will be treated as a feature.


I am trying to determine if an enhancement request already exists for this feature, in which case I might be able to get confirmation of status. If it doesn't exist, it has to be formally requested via a TAC case, which I know will be a problem for you...

Thanks,


Marcos

Hubert Mayr-Kne... Sat, 01/09/2010 - 04:37

That sounds good, something is going on, even with small steps.

If it helps to push things I will try to bring my UC520 under support by buying a smartnet.

regards

Marcos Hernandez Sun, 01/10/2010 - 06:14

It is always good to have your product covered under a support contract, but to be honest, it could take a long time (if ever) to implement this feature.

Thanks,


Marcos

Actions

This Discussion

Related Content