clearning overflow not doing anything

[ssteiner]

I'm testing the routing again in release 29.

I'm starting out with this state

Code: Select all

{
	"presentationRoutes": [
		{
			"destinations": [
				{
					"type": "OFFICE",
					"selected": true
				}
			]
		}
	],
	"forwardRoutes": [
		{
			"forwardType": "NO_ANSWER",
			"destinations": [
				{
					"type": "VOICEMAIL"
				}
			]
		}
	],
	"overflowRoutes": [
		{
			"overflowType": "NO_ANSWER",
			"destinations": [
				{
					"type": "NUMBER",
					"number": "1004"
				}
			]
		}
	],
	"dndState": {
		"activate": false
	}
}

Then I'm sending a DELETE http://srvroxe01.nxodev.intra/api/rest/ ... me=oxe7890. I get a 204 response back, so Im assuming all is well.

However, if I make a subsequent GET http://srvroxe01.nxodev.intra/api/rest/ ... me=oxe7890, I'm seeing the exact same values returned again. I would expect the overflow route to be cleared

I would expect a subsequent get of the routing state to not have an overflow route anymore, yet

[yblanchard]

Cannot reproduce the pb. (doing same operations)

The cause may be that management PBX events are no longer received by O2G:
Please:
- if possible check OXE Subscriber/Dynamic_State_User to check if the delete command really runs
and provide logs:
- put cache module in debug (from .../api/Log4jAdmin page)
- and provide: /logs/tomcat/chameleon/cache.log or zip all .log files

After, O2G service tomcatd restart, does the pb persist ?
If yes, is it possible to check in OXE the number of Events_Routing_Discriminator IP addresses? (there is a max number, which depends on OXE version)

merci

[ssteiner]

Here you go with the traces.

I wrote a little test case so you can see the timestamps

10:02:41 User oxe7890 has one overflow route of type NO_ANSWER, destination Destination type NUMBER acceptable device 1004 selected continuing test
10:02:45 cleared overflow route of oxe7890, trying to extract state again: OK
10:02:45 Server srvroxe01.nxodev.intra is now reachable
10:02:50 User oxe7890 still has an overflow route of type NO_ANSWER destination Destination type NUMBER acceptable device 1004 selected . Test failed

I already verified that nothing is being done directly through OXE last Friday.

I'll try rebooting now and run the test again.

@edit: rebooted, ran the test again. Same result

[yblanchard]

ok: the problem appears in multidevice user configuration and is located at OXE level: if the request contains overflow to "none" but includes the associated number with unchanged value, the overflow is set to no_answer default value.

(the same operation on mono device user is working)

The problem should be fixed at OXE level.

But waiting for that, we have 2 bypass solutions :

1) at OG level, remove the associated number parameter when the operation is overflow cancel => need a new O2G version
2) the application can make an overflow with associated number=itself: it will produce the same result than a DELETE
POST .../routing/overflow?loginName=oxe70123
{
"overflowRoutes": [ {
"overflowType": "NO_ANSWER", <-- use this value only
"destinations": [ {
"type": "NUMBER",
"number": "70123" <-- the number of the user itself
} ]
} ]
}

[ssteiner]

That works.. unfortunately, the next bug is right behind it..