Alcatel Unleashed

Hello!

I have a following setup:
Definity (user 6060) <--E1 ISDN, EDSS1--> OXE A CH R9.1 <--H.323, speeddial--> OXE B CH R9.1 <--E1 ISDN, EDSS1--> Definity (user 4040)


Here is a part of call of a 4040 user to 6060 user which shows a connect message, containing CONNECTED_NUMBER field (trace from OXE A, connect message going into H.323):

______________________________________________________________________________
| (723656:000014) 1250: Send_IO1 (link-nbr=1, sapi=0, tei=0) :
| long: 67 desti: 0 source: 15 cryst: 2 cpl: 0 us: 8 term: 0 type a5
| tei: 0 <<<< message sent : CONNECT (07) Call ref : 80 31
|______________________________________________________________________________
|
| [9f] Non-locking shift. codeset : 7
| IE:[06] EI_IP_PAYLOADS (l=1) -> G723 Ece 1 Vad 0
| [9f] Non-locking shift. codeset : 7
| IE:[0a] EI_RTP_INFO (l=30)
| -> stop_packet=0 stop_rtp=0 h323=0 wc=0 rf=0 udp=0 rqm=0
| -> Transm_Bande=1 detection_Q23=1 dtmf_payload=96
| -> Port RTP = 32592, IPv4 : 192. 168. 1. 19.
| -> Port RTCP SR = 32593, IPv4 : 192. 168. 1. 19.
| -> Port RTCP RR = 32593, IPv4 : 192. 168. 1. 19.
| -> Port Fax = 32592, IPv4 : 192. 168. 1. 19.
| IE:[1e] PROGRESS_ID (l=2) 80 82
| IE:[4c] CONNECTED_NUMBER (l=6) -> 21 80 Num : 6060
|______________________________________________________________________________



Here is the CONNECT message from the same call but from the trace of OXE B as it comes out of H.323 trunk and a following CONNECT message resended towards Definity via ISDN :


______________________________________________________________________________
| (868158:000009) Concatenated-Physical-Event :
| long: 64 desti: 0 source: 0 cryst: 2 cpl: 0 us: 0 term: 0 type a5
| tei: 0 >>>> message received : CONNECT (07) Call ref : 80 32
|______________________________________________________________________________
|
| IE:[28] DISPLAY (l=4) `6060`
| IE:[4c] CONNECTED_NUMBER (l=2) -> 00 80 Num :
| [97] Locking shift. codeset : 7
| IE:[06] EI_IP_PAYLOADS (l=1) -> G723 Ece 0 Vad 0
| IE:[0a] EI_RTP_INFO (l=30)
| -> stop_packet=0 stop_rtp=0 h323=1 wc=0 rf=0 udp=0 rqm=0
| -> Transm_Bande=0 detection_Q23=1
| -> Port RTP = 32596, IPv4 : 192. 168. 1. 19.
| -> Port RTCP SR = 32597, IPv4 : 192. 168. 1. 19.
| -> Port RTCP RR = 32597, IPv4 : 192. 168. 1. 19.
| -> Port Fax = 0, IPv4 : 0. 0. 0. 0.
|______________________________________________________________________________

______________________________________________________________________________
| (868158:000011) 1213: Send_IO1 (link-nbr=1, sapi=0, tei=0) :
| long: 18 desti: 0 source: 15 cryst: 2 cpl: 0 us: 8 term: 0 type a5
| tei: 0 <<<< message sent : CONNECT ACK (0f) Call ref : 00 32
|______________________________________________________________________________

______________________________________________________________________________
| (868158:000012) 1213: Send_IO1 (link-nbr=1, sapi=0, tei=0) :
| long: 25 desti: 0 source: 15 cryst: 2 cpl: 6 us: 8 term: 0 type a5
| tei: 0 <<<< message sent : CONNECT (07) Call ref : 81 b2
|______________________________________________________________________________
|
| IE:[29] DATE (l=5) -> date : 24 / 07 / 05 02:37
|______________________________________________________________________________

The format of a message has changed - there is a field DISPLAY which now holds the actual number and the field connected_number is empty. As you can see below the CONNECT message being sent to Definity doesn't hold any number at all - which results in my problem - no connected number is displayed on a calling user set.

The Ext.Callback Translator is configured DEF,0.

Any ideas are very welcomed.
Thanks in advance.

It's weird, Sent CONNECT != Received CONNECT.
What kind of IP connection between OXEs do you have - Internet cloud, VPN, private network? Can you check H.323/H.225 packets on Ethernet ports of GDs/INTIPs?

Hello Alex, thanks for reply. OXEs are connected in the most simple way - I have uplinks of CSes interconnected. Will try to get a ethereal trace of ethernet ports.

Hello!
Got some update. It looks like the t3 output is incorrect on OXE A and the real CONNECT message format is as it comes out of IP-trunk on OXE B. I mean that the DISPLAY field is already there on output from OXE A to H.323 trunk. So the conversion of CONNECT message appears in OXE A during a transit form ISDN to H.323. So the question is now what are the parameters affecting this on OXE A ?

I am 100% sure that there is no conversion between IEs. As H.232 and EDSS1 are based on Q.931 so we have direct relation between IE. I mean IEs DISPLAY and CONNECTED NUMBER in EDSS1 and in H323 are the same so they are just copied to messages. Looks it is a problem of Private/public (byte 3) transition and correlation of EDSS1 which is pure "user<->network" and H.323 which is "user<->user" protocols.
So how does CONNECT message on EDSS1 part look?

Absent the first trace Definity-OXE, Definity send Connected number like this:

IE:[4c] CONNECTED_NUMBER (l=5) -> a1 Num : 6060

Without 3a octet (absent screening indicator). So number "user-provided, not screened" instead of "user-provided, verified and passed".

Hello !

I'm sorry, I'm not 100% sure what vad says.

Anyways here is an Ethereal trace of an H.323 connect message sent by OXE A .

Also if I replace the H.323 trunk between OXEs with the ISDN trunk and keep the rest intact the connected number is tranferred ok.

Here is some parts of a t3 trace with ISDN trunks between OXEs:

This is a connect message received by OXE A from definity (looke exactly like H.323 case)

______________________________________________________________________________
| (031570:000008) Concatenated-Physical-Event :
| long: 29 desti: 0 source: 0 cryst: 2 cpl: 6 us: 0 term: 0 type a5
| tei: 0 >>>> message received : CONNECT (07) Call ref : 80 0b
|______________________________________________________________________________
|
| IE:[1e] PROGRESS_ID (l=2) 81 82
| IE:[4c] CONNECTED_NUMBER (l=5) -> a1 Num : 6060
|______________________________________________________________________________

And here is a CONNECT mesage sent by OXE A towards OXE B through ISDN

______________________________________________________________________________
| (031570:000010) 1175: Send_IO1 (link-nbr=1, sapi=0, tei=0) :
| long: 37 desti: 0 source: 15 cryst: 2 cpl: 7 us: 8 term: 0 type a5
| tei: 0 <<<< message sent : CONNECT (07) Call ref : 80 07
|______________________________________________________________________________
|
| IE:[1e] PROGRESS_ID (l=2) 81 82
| IE:[29] DATE (l=5) -> date : 29 / 07 / 10 14:30
| IE:[4c] CONNECTED_NUMBER (l=6) -> 21 80 Num : 6060
|______________________________________________________________________________

Also here is a raw mst trace from Definity, connected to OXE A:

list mst continuous auto-page Page 1
MESSAGE SEQUENCE TRACE DATA
Number Date/Time Type Message
1 07/29/10
16:58:58.100 60 00 00 3D 0F 08 02 00 06 05 04 03 90 90 A3 18 03
A9 83 87 6C 05 A1 34 30 30 30 70 05 A1 36 30 36
30 A1
2 16:58:58.100 62 00 00 3D 0F 08 02 80 06 02 18 03 A9 83 87
3 16:58:58.100 62 00 00 3D 0F 08 02 80 06 01 1E 02 81 88
4 16:58:59.160 62 00 00 3D 0F 08 02 80 06 07 1E 02 81 82 4C 05 A1
36 30 36 30
5 16:58:59.180 60 00 00 3D 0F 08 02 00 06 0F 18 03 A9 83 87
6 16:59:00.720 62 00 00 3D 0F 08 02 80 06 45 08 02 81 90
7 16:59:00.860 60 00 00 3D 0F 08 02 00 06 4D 08 02 81 90
8 16:59:00.860 62 00 00 3D 0F 08 02 80 06 5A
9 16:59:05.820 71 01 00 01



Thanks anyway.
Regards,
Pavel.

When H323 replaced ISDN - management the same? Call via Speed dial or ARS, NPD number in TG, Network mode in digital access, private yes or not (in global TG parameters).

pavel wrote: I replace the H.323 trunk between OXEs with the ISDN trunk and keep the rest intact the connected number is tranferred ok.

Great. Now just carefully check all configurations of all TGs parameters - common, local, NPD etc - between both TGs (H.323 and EDSS1). "The Truth is Out There";), I hope.

The best solution - send from Definity Calling/ Connected number not like this
IE:[6c] CALLING_NUMBER (l=5) -> a1 Num : 4000
But with screening indicator, like this
IE:[6c] CALLING_NUMBER (l=6) -> a1 81 Num : 4000 (you can see one more byte before number)

Without this you will have another problem in future. F.e. when user 4000 call DISA in OXE - automatic substitution can not works without additional management (system/ other system/ DISA param - With NDS (DDI) not controlled) - like for GSM gate.