EventDNOutOfService in case of register request

[Fra]

Corn,

I have just finished analyzing your T-Server startup log file,  what I have found is that in the DN array where T-Server prints out the DN configured, there is:

[i][203] dn = '3500' type = station xtype = DN cfgtype = 7 reg-mode = 0x0 =[/i]

[list]
[li] cfgtype = 7 means that it's a Voice Treatment Port (correct??) [/li]
[li] reg-mode = 0x0 (instead of the default reg-mode = 0x21 = +force) means that the "Register"  box of the DN in the CME is not flagged! T-Server will never register it..and each DN you have configured is so. [/li]
[/list]

Please check the Register box (and the DN type?) and report back 

[corn]

Hi Fra,

many thanks for analyzing the Genesys T-Server trace.

- it's intended that 3500 etc. are configured as voice treatement ports (3500 etc. are ivp sublines of an IVP hunt group in this test environment)

- because of register box: I'm a little bit confused. I think our configuration is for this case ok, because we want that our application initializes the registration of
  the ivp sublines, not the Genesys T-Server; so we've configured the register box with value "on demand". So our application sends a TRegisterAddress request
  and the Genesys T-Server confirms with EventRegistered before we get EventDNOutOfService.


 

[victor]

[quote author=Fra link=topic=1865.msg6161#msg6161 date=1161160494]
Corn,

I have just finished analyzing your T-Server startup log file,  what I have found is that in the DN array where T-Server prints out the DN configured, there is:

[i][203] dn = '3500' type = station xtype = DN cfgtype = 7 reg-mode = 0x0 =[/i]

[list]
[li] cfgtype = 7 means that it's a Voice Treatment Port (correct??) [/li]
[li] reg-mode = 0x0 (instead of the default reg-mode = 0x21 = +force) means that the "Register"  box of the DN in the CME is not flagged! T-Server will never register it..and each DN you have configured is so. [/li]
[/list]

Please check the Register box (and the DN type?) and report back 
[/quote]

Hi, Fra,

damn, that was a pretty nice catch - missed it completely! 

So, to put it simply: he is registering DNs that T-Server did not really register with PBX?

7.2.008.01 send_to_client: message EventRegistered
  AttributeEventSequenceNumber  0000000000000003
  AttributeCustomerID  'Resources'
  AttributeTimeinuSecs  84000
  AttributeTimeinSecs  1160657801 (14:56:41)
  AttributeAddressType  1 (DN)
  AttributeExtensions  [37] 00 02 01 00..
      'AgentStatus'  0
  [color=Red]    'status'  128[/color]
  AttributeReferenceID  1
  AttributeThisDN  '3500'

I don't know what status = 128 for DN means, but since it is greater than 0 it means that something is happening on it. Any ideas?

[Fra]

Hi Corn, hi Victor,

so I guess I got something now 
First of all, the AttributeExtension 'status' =128  just means that the DN is out of service. From the T-Library SDK 7.2 C Developer's Guide:

0x80: DN is out of service.                          -------->128 decimal 
0xC0: DN is undergoing maintenance.
0x90: Device associated with DN is locked out.
0x88: DN is vacant.

From the full log I have got from Corn what I can see is:
[list]
[li]T-server reads the DNs configured,[b] correct[/b];[/li]
[li]T-server doesn't register any of them, [b]correct[/b] since Corn has selected "On-demand" registration in CME;[/li]
[li]as soon as T-server gets the RequestRegisterAdress from the client, it forwards to the Avaya switch, [b]correct[/b];[/li]
[li][i]without [/i]waiting the answer from the switch, it replies to the client with a EventRegistered (status=outofservice) and an EventDnOutOfservice: a bit strange, but I've already seen this behaviour somewhere else with the new 7.2 T-server: it somehow processes the request  just internally... [/li]
[li]and then the surprise!    (Corn, you didn't attach that part of the log in your very first post):
                1. T-server gets the answer from the switch, a successful registration, [b]good[/b], it means the DN exists and it's on service on it;
                2. T-server sends an [b]EventDnBackInService[/b] (status=0, ok&no activity on it) to the client! From now on the DN is
                    in service and can manage the client requests. [/li]
[/list]

So, for me everything works fine..! Corn, probably your client is not able to manage the EventDnBackInService?

[corn]

Hi Victor, hi Fra,

sorry for missunderstandings and again many thanks for your analyzes.

We also thought that this is perhaps the new Genesys 7.2 behaviour and this is correctly
but we're totally unsure because there exists somewhere a customer with Genesys 7.2
and our application works there without changes - for ivp sublines, trunk dns or vdns which
are registered all with startup of our application with EventDNBackInService all may be fine
but if an agent registers dynamically while our application is running and it doesn't work the
first time - it wouldn't be ok for the customer.
You're right, it would be necessary to make some changes in our application to handle
EventDNOutOfService, EventDNBackInService. But because of the already somewhere
running customer installation with Genesys 7.2 with our application without changes we
are still unsure if there's something not ok with our Genesys 7.2 installation.

[Fra]

Corn wrote:[quote]but if an agent registers dynamically while our application is running and it doesn't work the
first time - it wouldn't be ok for the customer.[/quote]

As soon as T-server starts up, your application requests DNs registration to it; after 0.11 secs your application will already have got back a positive registration. Why woulnd't it work if an agent dinamically registers The *issue* here is on startup..

If you have another enviroment where 7.2 T-server acts different, check the version and report back the logs.

[corn]

Hi fra,

thanks again for your answer.
If it would be possible to get Genesys 7.2 support of the "working customer installation" we
would have done it. But this working Genesys 7.2 installation is not from us - it's from a
third party company and we don't have access to this Genesys 7.2 T-Server. It's maintained by
a third party company and there are some instances between us and them ... This Genesys 7.2
T-Server is only a third party component in a running system from us.

As you can see in the following trace lines it is possible that there are problems if an operator agent
registers dynamically because for such a DN in our functionality TAgentLogin is necessary. This TAgentLogin
can't be possible confirmed after EventDNOutOfService. Sure, there's also an EventDNBackInService but
too late.
So we want to go sure if we've to change our application with Genesys 7.2 because there comes
perhaps always EventRegistered, EventDNOutOfService and EventDNBackInService or if we perhaps
can avoid EventDNOutOfService - the goal is if possible not to change our application.

13:35:24.510 Trc 04541 RequestRegisterAddress received from 528 (0002 Fozzie MOS Genesys 5.00)
message RequestRegisterAddress
AttributeThisDN '3023'
AttributeRegisterMode 0
AttributeControlMode 0
AttributeAddressType 0 (Unknown)
AttributeReferenceID 41
map <dn,conf>: find (3023): Ok
[ 4 - ] DN: '3023' Links assigned
13:35:24.510 Trc 20006 Number of seat licenses in use 1 out of 20 available
(tservice_proc) AddressType set to 1 for 3023
(tservice_proc) ControlMode set to 1 for 3023
** ts7.2.008.01[4] <> ** 13:35:24.5100
08 00 00 1B 08 02 00 27 64 96 1C 13 91 A1 10 02 01 0B 02 01 C4 40 08 96 49 05 83 33 30 32 B3
=== parsed message ===
prot_discr = 8
CRV = 27
MsgType = 100 (REGISTER)

Facility:  serv_discr = 17(q932_suppl)  fac_ie = component_tag = A1(INVOKE)
invoke_id tag: 02, value = 11
operation tag: 02, value = 196(Domain_Control)
params = q931_tag = 40
list =
Domain:  type = 3(Extension)  address = [4] 33 30 32 33 '3023'

@13:35:24.5100 [0] 7.2.008.01 send_to_client: message EventRegistered
AttributeEventSequenceNumber 000000000000002f
AttributeCustomerID 'Resources'
AttributeTimeinuSecs 510000
AttributeTimeinSecs 1161344124 (13:35:24)
AttributeAddressType 1 (DN)
AttributeExtensions [37] 00 02 01 00..
'AgentStatus' 0
'status' 128
AttributeReferenceID 41
AttributeThisDN '3023'
13:35:24.510 Trc 04542 EventRegistered sent to 528 (0002 Fozzie MOS Genesys 5.00)
@13:35:24.5100 [0] 7.2.008.01 distribute_event: message EventDNOutOfService
AttributeEventSequenceNumber 0000000000000030
AttributeCustomerID 'Resources'
AttributeTimeinuSecs 510000
AttributeTimeinSecs 1161344124 (13:35:24)
AttributeExtensions [17] 00 01 01 00..
'status' 128
AttributeThisDN '3023'
@13:35:24.5100 [ISCC] Debug: Translate: '' -> ''; result 1 ()
13:35:24.510 Trc 04542 EventDNOutOfService sent to 528 (0002 Fozzie MOS Genesys 5.00)
13:35:24.510 Trc 04541 RequestAgentLogin received from 528 (0002 Fozzie MOS Genesys 5.00)
message RequestAgentLogin
AttributeThisDN '3023'
AttributeAgentID '52100'
AttributeAgentWorkMode 0 (Unknown)
AttributeReferenceID 42
@13:35:24.5100 [0] 7.2.008.01 send_to_client: message EventError
(Out of service)
AttributeEventSequenceNumber 0000000000000031
AttributeCustomerID 'Resources'
AttributeTimeinuSecs 510000
AttributeTimeinSecs 1161344124 (13:35:24)
AttributeReferenceID 42
AttributeErrorCode 58
AttributeErrorMessage 'Invalid request: originator is not monitored'
AttributeThisDN '3023'
13:35:24.510 Int 04545 Interaction message "EventError" sent to 528 ("Fozzie MOS Genesys 5.00")
13:35:24.510 Trc 04542 EventError sent to 528 (0002 Fozzie MOS Genesys 5.00)
13:35:24.542 Trc 04541 RequestAgentLogout received from 528 (0002 Fozzie MOS Genesys 5.00)
message RequestAgentLogout
AttributeThisDN '3023'
AttributeReferenceID 43
@13:35:24.5420 [0] 7.2.008.01 send_to_client: message EventError
(Out of service)
AttributeEventSequenceNumber 0000000000000032
AttributeCustomerID 'Resources'
AttributeTimeinuSecs 542000
AttributeTimeinSecs 1161344124 (13:35:24)
AttributeReferenceID 43
AttributeErrorCode 58
AttributeErrorMessage 'Invalid request: originator is not monitored'
AttributeThisDN '3023'
13:35:24.542 Int 04545 Interaction message "EventError" sent to 528 ("Fozzie MOS Genesys 5.00")
13:35:24.542 Trc 04542 EventError sent to 528 (0002 Fozzie MOS Genesys 5.00)
** link[4] <> ** 13:35:24.5420
08 02 80 27 62 96 1C 06 91 A2 03 02 01 0B
=== parsed message ===
prot_discr = 8
CRV = 8027
MsgType = 98 (FACILITY)

Facility:  serv_discr = 17(q932_suppl)  fac_ie = component_tag = A2(RETURN_RESULT)
invoke_id tag: 02, value = 11
sequence =
WARNING: 'g3_process_pos_ack_general' msg not attached to assoc CRV=0x8027 - processing as positive registration....
@13:35:24.5420 [0] 7.2.008.01 distribute_event: message EventDNBackInService
AttributeEventSequenceNumber 0000000000000033
AttributeCustomerID 'Resources'
AttributeTimeinuSecs 542000
AttributeTimeinSecs 1161344124 (13:35:24)
AttributeExtensions [17] 00 01 01 00..
'status' 0
AttributeThisDN '3023'
@13:35:24.5420 [ISCC] Debug: Translate: '' -> ''; result 1 ()
13:35:24.542 Trc 04542 EventDNBackInService sent to 528 (0002 Fozzie MOS Genesys 5.00)
** ts7.2.008.01[4] <> ** 13:35:24.5420
08 00 00 1E 08 02 00 28 64 96 1C 16 91 A1 13 02 01 0D 02 01 8C 40 0B 6C 05 80 33 30 32 33 96 4D 01 83
=== parsed message ===
prot_discr = 8
CRV = 28
MsgType = 100 (REGISTER)

[Fra]

Hi Corn,

I've understood you goal, anyway the issue you are facing occurs only on TServer startup: your application sends a RequestAgentLogin right away, while TServer is still registering DNs and assigning them to the configured links.