We are trying to get an Asterisk/Digium G100 gateway to work with an Avaya Devinity R8. We have gotten the calls to process, but we can't get them to go to voice mail at the far end due to an acsii character inserted before the extension Basically we have the following:
Avaya PBX T1 interface(no voice mail, system uses vmail on far end) ---> G100 (T1/Sip Gateway)---> VPN ----> G100 (T1/Sip GAteway)------> Avaya PBX T1 interface with Avaya Voicemail System
The caller id shows something like:
a:i2555 (The lower case i is actually an i with two dots above it) Our Engineer explained the findings below:
Here is what the Avaya sends for calling number on the caller side: 6c 05 a1 32 38 32 36
The A1 byte is the type of number (National) and presentation (allowed, not screened)
We can see that the gateway sends the proper CID in the SIP invite going to the other end (2826)
On the receiving side, here is what the Gateway sends to the Avaya if the TON is set to National: 6c 06 21 80 32 38 32 36
You can see that the format of the TON and presentation is different. There are two ways to format TON and presentation in the Q.931 spec, and the gateway uses the second way. The most significant bit of byte 3 tells the receiver if the CID follows immediately, or if there is another byte of information before the CID. When it is set to 1, like for the Avaya above, it means the next byte is the start of the CID. When it is not set, like with the gateway, it means the next byte contains more information. In this case, because the next byte is 80, it means the next byte starts the CID.
So sending A1, or 21 80 result in the exact same thing.
Now, it looks like the Avaya on the receiving end treats the TON/presentation byte/bytes as the first CID character. The character "î" displayed on the phone is actually hex A1.
There must be a setting in the Avaya to specify the presence of TON/Presentation information in the CID header or the format of the CID (also called "calling number". Apparently, older(very old) version of the Q.931 spec did not include TON/presentation information. Maybe there is a setting on Q.931 version support or something like it.
Here are the Avaya Definity Rls 8 settings:
DS1 CIRCUIT PACK
Location: 01B10 Name: DCS NODE 1
Bit Rate: 1.544 Line Coding: b8zs
Line Compensation: 1 Framing Mode: esf
Signaling Mode: isdn-pri
Connect: pbx Interface: network
CentreVu Long Timers? n Country Protocol: 1
Interworking Message: PROGress Protocol Version: a = (5ess or 4ess)
CRC? n
Idle Code: 11111111
DCP/Analog Bearer Capability: 3.1kHz
Any ideas on what we can change on the Avaya PBX? Can I change the dial plan or manipulate the digits being sent some how? Thanks!
Avaya PBX T1 interface(no voice mail, system uses vmail on far end) ---> G100 (T1/Sip Gateway)---> VPN ----> G100 (T1/Sip GAteway)------> Avaya PBX T1 interface with Avaya Voicemail System
The caller id shows something like:
a:i2555 (The lower case i is actually an i with two dots above it) Our Engineer explained the findings below:
Here is what the Avaya sends for calling number on the caller side: 6c 05 a1 32 38 32 36
The A1 byte is the type of number (National) and presentation (allowed, not screened)
We can see that the gateway sends the proper CID in the SIP invite going to the other end (2826)
On the receiving side, here is what the Gateway sends to the Avaya if the TON is set to National: 6c 06 21 80 32 38 32 36
You can see that the format of the TON and presentation is different. There are two ways to format TON and presentation in the Q.931 spec, and the gateway uses the second way. The most significant bit of byte 3 tells the receiver if the CID follows immediately, or if there is another byte of information before the CID. When it is set to 1, like for the Avaya above, it means the next byte is the start of the CID. When it is not set, like with the gateway, it means the next byte contains more information. In this case, because the next byte is 80, it means the next byte starts the CID.
So sending A1, or 21 80 result in the exact same thing.
Now, it looks like the Avaya on the receiving end treats the TON/presentation byte/bytes as the first CID character. The character "î" displayed on the phone is actually hex A1.
There must be a setting in the Avaya to specify the presence of TON/Presentation information in the CID header or the format of the CID (also called "calling number". Apparently, older(very old) version of the Q.931 spec did not include TON/presentation information. Maybe there is a setting on Q.931 version support or something like it.
Here are the Avaya Definity Rls 8 settings:
DS1 CIRCUIT PACK
Location: 01B10 Name: DCS NODE 1
Bit Rate: 1.544 Line Coding: b8zs
Line Compensation: 1 Framing Mode: esf
Signaling Mode: isdn-pri
Connect: pbx Interface: network
CentreVu Long Timers? n Country Protocol: 1
Interworking Message: PROGress Protocol Version: a = (5ess or 4ess)
CRC? n
Idle Code: 11111111
DCP/Analog Bearer Capability: 3.1kHz
Any ideas on what we can change on the Avaya PBX? Can I change the dial plan or manipulate the digits being sent some how? Thanks!