-
Type:
Bug
-
Status: Closed
-
Priority:
Critical
-
Resolution: Fixed
-
Affects Version/s: 12
-
Fix Version/s: None
-
Component/s: Class of Service (Commercial)
-
Labels:None
-
ToDo:
-
Asterisk Version:11
-
Distro Version:6.12.65-28
-
Distro:FreePBX Distro
We've been experiencing occasional failed call transfers, and finally diagnosed what is causing them. When transferring certain calls, Class of Service restrictions on Routes are not being enforced, causing some calls to go out routes they shouldn't.
The attached file has the log from two calls. In the first call, 9897080313 (outside caller) calls extension 9898373790712 directly. Transfer to 151 honors Class of Service to use a route to direct the call to 9898373790151.
This line shows the Class of Service restrictions being consulted:
[2015-08-11 11:17:31] VERBOSE[20467][C-0003619f] pbx.c: -- Executing [151@restrictedroute-470f44ddc5abf4a3789ddd6a820f2191:4] Set("SIP/lecmi-0002d997", "INTRACOMPANYROUTE=YES") in new stack
And here, the call is rewritten to go to 9898373790151, which is the expected behavior:
[2015-08-11 11:17:31] VERBOSE[20467][C-0003619f] pbx.c: -- Executing [151@restrictedroute-470f44ddc5abf4a3789ddd6a820f2191:7] Macro("SIP/lecmi-0002d997", "dialout-trunk,9,9898373790151,,off") in new stack
In the second call, 9897080313 (outside caller) calls the Operator, which rings several phones, including extension 9898373790712. Extension 9898373790712 answers and transfers to 151, but Class of Service is not consulted and a wrong route is used.
This line shows all outbound routes being used without considering Class of Service:
[2015-08-11 11:18:09] VERBOSE[20571][C-000361a4] pbx.c: – Executing [151@outbound-allroutes:4] Set("SIP/lecmi-0002d9a2", "INTRACOMPANYROUTE=YES") in new stack
The first route matched is used, which rewrites 151 to 9894869798151, which is not the intended recipient and an invalid extension:
[2015-08-11 11:18:09] VERBOSE[20571][C-000361a4] pbx.c: – Executing [151@outbound-allroutes:7] Macro("SIP/lecmi-0002d9a2", "dialout-trunk,9,9894869798151,,off") in new stack
I didn't check to see if calls delivered via Queue would have a similar problem. Hopefully you can test that while you fix this.
Thanks,
Dave