IP offcie Qsig interconnection : lost information of CLI

[gapelbaum]

Hi,

My company have an IP office 406 with software version .1.3.34
I trying to use Qsig over the E1 link joining the IP office with other PBX (Siemens HiCom).

The link work well and calls can be established, but when an external call is transferred from the HiCom to the IP office the IP office always present at the phone display, the phone manager and the call status the number of the HiCom internal number which made the manual transfer and never the number of the external party which is that we are talking.

This is because the HiCom always present the number of the other party who are you talking, when the transfer is made the display is refreshed showing the corrected Ani number of the external phone.

Showing this process using the Ipoffice monitor tool as a tracer of the messages
I saw the the HiCom send a facility message containing the correct ANI after the setup message. I suppose that the Ipoffice can’t decodify this message and therefore can’t show it.

Below is a copy of the call trace, the facility message at 20122ms contain the correct ANI of the external pary. (The ani of the external pary in this example is 26287039)

Avaya say at the 1.3.37 documentation:
“Q931Message: Improved system validation of APDU operational code to ensure that it is a Calling/Called/Connected Name that is being decoded. “

Does any know about if news Ipoffice software version (1.3.37 , 1.4.22) can decode and show the other party CLI ?

Does any have more info about Avaya Qsig implementation enhancement ?

There are any Qsig interconnection test or experience about Siemens Hicom and IpOffcie ?

Does any know which Qsig standard and issue Ipoffice match (ETSI, ISO, ECMA) ?

Any experience or help about this topic will be welcomed.


Thanks,

Gustavo.




== 2/9/2003 23:55 contact made SysMonitor 3.3 (33)
0mS PRN: Monitor Started IP=192.168.32.155 IP 406 1.3(34)
0mS PRN: LAW=A PRI=1, BRI=0, ALOG=0, ADSL=0 VCOMP=20, MDM=0, WAN=0, MODU=3 LANM=0 CkSRC=5 VMAIL=1(VER=2 TYP=1) CALLS=0(TOT=17)
18781mS ISDNL3Rx: v=5 peb=5
ISDN Layer3 Pcol=08(Q931) Reflen=2 ref=0009(Remote)
Message Type = Setup
InformationElement = Sending Complete
InformationElement = BearerCapability
0000 04 03 80 90 a3 .....
InformationElement = CHI
0000 18 03 a9 83 89 .....
InformationElement = FAC
0000 1c 1f 91 aa 06 80 01 00 82 01 00 8b 01 00 a1 11 ................
0010 02 02 0a 70 06 04 2b 0c 09 29 03 05 00 80 00 00 ...p..+..)......
0020 00 .
InformationElement = FAC
0000 1c 1a 91 aa 06 80 01 00 82 01 00 8b 01 00 a1 0c ................
0010 02 02 0a 80 06 04 2b 0c 09 00 84 00 ......+.....
InformationElement = PI
0000 1e 02 a0 90 ....
InformationElement = CallingPartyNumber
0000 6c 05 00 83 38 30 30 l...800
InformationElement = CalledPartyNumber

0000 70 04 80 32 32 37 p..227
InformationElement = HigherLayerCompat
0000 7d 02 91 81 }...
InformationElement = ??(95)
InformationElement = ??(31)
0000 31 01 80 1..
InformationElement = ??(32)
0000 32 01 82 2..
18782mS ISDNL3Evt: v=5 stacknum=5 State, new=Present, old=NullState id=13
18856mS ISDNL3Tx: v=5 peb=5
ISDN Layer3 Pcol=08(Q931) Reflen=2 ref=0009(Local)
Message Type = CallProceeding
InformationElement = CHI
0000 18 03 a9 83 89 .....
18857mS ISDNL3Evt: v=5 stacknum=5 State, new=Received, old=Present id=13
18857mS ISDNL3Tx: v=5 peb=5
ISDN Layer3 Pcol=08(Q931) Reflen=2 ref=0009(Local)
Message Type = Alerting
InformationElement = CHI
0000 18 03 a9 83 89 .....
20122mS ISDNL3Rx: v=5 peb=5
ISDN Layer3 Pcol=08(Q931) Reflen=2 ref=0009(Remote)
Message Type = Facility
InformationElement = FAC
0000 1c 46 91 aa 06 80 01 00 82 01 00 8b 01 00 a1 38 .F.............8
0010 02 02 0b 00 06 04 2b 0c 09 0c 30 2c 0a 01 01 a0 ......+...0,....
0020 0d 80 08 32 36 32 38 37 30 33 39 0a 01 03 40 04 ...26287039...@.
0030 1e 02 80 81 a1 0f 04 0a 49 53 4e 44 20 41 4e 54 ........ISND ANT
0040 45 4c 02 01 01 0a 01 00 EL......
24935mS ISDNL3Evt: v=5 stacknum=5 State, new=ConnReq, old=Received id=13
24935mS ISDNL3Tx: v=5 peb=5
ISDN Layer3 Pcol=08(Q931) Reflen=2 ref=0009(Local)
Message Type = Connect
InformationElement = FAC
0000 1c 1e 9f aa 06 80 01 00 82 01 00 8b 01 00 a1 10 ................
0010 02 02 58 ae 02 01 02 80 07 4c 50 6f 6c 69 74 6f ..X......LPolito
25035mS ISDNL3Rx: v=5 peb=5
ISDN Layer3 Pcol=08(Q931) Reflen=2 ref=0009(Remote)
Message Type = ConnectAck
25036mS ISDNL3Evt: v=5 stacknum=5 State, new=Active, old=ConnReq id=13
75513mS ISDNL3Evt: v=5 stacknum=5 State, new=DiscReq, old=Active id=-1
75513mS ISDNL3Tx: v=5 peb=5
ISDN Layer3 Pcol=08(Q931) Reflen=2 ref=0009(Local)
Message Type = Disconnect
InformationElement = CAUSE
0000 08 02 80 90 ....
75719mS ISDNL3Rx: v=5 peb=5
ISDN Layer3 Pcol=08(Q931) Reflen=2 ref=0009(Remote)
Message Type = Release
75719mS ISDNL3Tx: v=5 peb=5
ISDN Layer3 Pcol=08(Q931) Reflen=2 ref=0009(Local)
Message Type = ReleaseComplete
75719mS ISDNL3Evt: v=5 stacknum=5 State, new=NullState, old=DiscReq id=-1

 

[MrIPO]

My first suggestion would be to upgrade to 1.4(22) or 1.4(25) when its released.

With 1.4(X) the IPO comforms to
Supplementary Service ETSI Reference
Simple Telephony Call/Basic Call ETS300 171/172
Circuit Switched Data Call/Basic Call ETS300 171/172
Called/Calling Line ID Presentation ETS300 173
Called/Calling Name Presentation ETS300 237/238
Message Waiting EN301 260/

We have done the configuration you are speaking of many times. In your case here The IPO on its QSIG call setup is being presented with the internal extension number of the connecting PABX as you have noted. We had this same case when connecting a IPO to Eccrission MD110 via E1. It ended up being the programming on the connecting pabx and require a software upgrade. The connecting PABX had to be programmed to pass the DDI through to the IPO as part of its call setup on the IPO in QSIG A configuration.

You have also probley seen that when you connect QSIG A-B configuration via PRO card on the IP, the incoming call bypasses Incoming call routs and looks directly at extension number with a match or direct to System Short code and into VM Pro for AA configuration.

Hope this helps

 

[gapelbaum]

Hello,

Thank for your help, but I need some more clarification:

Special I’m not fully understand your phrase:

“It ended up being the programming on the connecting pabx and require a software upgrade. The connecting PABX had to be programmed to pass the DDI through to the IPO as part of its call setup on the IPO in QSIG A configuration”

What’s mean that the connecting PABX (in your case a Ericsson MD110) pass the DDI to the IPO as part of the call setup ?

1) The DDI is the ANI of the external party or the number of the internal phone at the people who made the transfer at the connecting PBX ?

2) The software upgrade was in the MD110 or in the IPO ?

3) In your scenario, finally the IPO show the correct external (Public PSTN) ANI for a call transfer from the MD110 ?

When I made the test with the company that sold the HiCom , the HiCom has a lot of variants about Qsig (ECMA v1 seg 1, ECMA v1 seg 9, ECMA v2 seg 1, PSS1, EDSS1Net, etc, etc ), An the IPO has only Qsig-A and Qsig-B.

Some combination of protocols version works only in one way for a simple call setup.

Only 2 combination works for two way call setup:
IPO (v1.3.34) with Q-sig B and HiCom with ECMA v1 seg 1 or EDSS1Net.

What is the difference between Qsig A and B ?

In all cases HiCom send the external ANI as a facility Q.931 message after the call is transferred.

Siemens people say that it is not possible to change this behaviour.

Do you think that a new IPO software version 1.4.x can fix our trouble ?.

A lot of Thanks.

Gustavo.