Under disconnect reason, for all calls we also appear to see the same 2 entries for all calls(either undetermined or unknown)- is this because the call is ingressing over an IP(SIP trunk) and this field isn't supported? Should we expect to see other causes for ISDN calls?
Solved! Go to Solution.
Hi again Jonathan
I'd be glad to help you further with this one.
To make it more relevant, can you present to me a block diagram of the communications solution, including Trunk presentations/ egress and ingress points to the public network and a screen shot sample of the cdr records you mention.
Your supposition could well be correct, especially where inbound SIP calls are presented to multiple devices eg: a desk set and a UM client like Skype or a One X client. If you get three devices alerting and one forwards the call to VM for example or the user is on a call and rejects a second call via SKYPE, then other devices or trunks will just "lose the call" for no reason as they are not part of the end to end signalling tearing down the call. There is much more in ISDN messaging than in SIP, such that several messages in ISDN relating to call progress may well translate to a common message in SIP and some that are considered as information only or progress messages, will not be translated at all and end up as Unknown. A better more detailed look at your experiences would aid a more precise response. Feel free to contact me, firstname.lastname@example.org (UKI) and pass the screen shot via email along with the topography diagram for your comms solution.
I may ask that you collect a sample of raw cdr data via the Prognosis tools for playback and appraisal. This will be used for this question only, not displayed in this forum and be deleted once we are both satisfied with the answer
There is one other setting on the Avaya CM that may get over looked.
"disconnect reason instead of FRL" to Y, to ensure any messaging that the CM has is passed onto the CDR record. (Thanks for the prompt Felix)
If it is set or setting it makes no difference, then please contact me with some screen shots of the display and possible a CDR dump .. 1 minute / 10 calls would be enough.
I hope you have had an opportunity to check the CDR configuration via SAT to confirm that disconnect reason instead of FRL is enabled. If it is and you are still only seeing the two reasons for disconnect, can you asses the individual CDR records for which trunk group the call passed over? Is the inadequate disconnect reason displayed, only associated with SIP routes? Are there any other disconnect reasons displayed for calls transitioning standard PSTN services? What results do you see for internal calls?
If the display is only showing these two disconnect reasons on all routes and call types, then the next step will be to set up a CDR Collection to file for Replay off line. The contents of the FRL field can then be assesed in the raw record (parse into MS Excel and view there, rather than replay to Prognosis), to check if the different disconnect reasons are being forwarded to Prognosis from the Avaya CM.
It would be good to know if you have made progress with the issue or need assistance in identifying the reason for the lack of detail in the display.
If my answer helped you today, please be sure to mark the 'Accept as Solution' button and click like to help others find the answer, thanks.
Sorry for the delay
I can see on our system that our CDR parameters have this field set to N - what i will do is go through the CDR set up by the book using the config guide and see if that helps.
Disconnect Information in Place of FRL? n
lets close this thread as resolved and I will report back if still having issues
Thanks for your time.
Just for anyone who is following this thread- we chnaged the setting on CDR as advised(disconnect information in place of FRL) and we are now seeing call disposition codes being populated.
We are also using SIP trunks and the detail seems to populating through as expected.
Is it worth getting IR to update their docs as in mine it tells me to not enable this setting and leave it to N ?
Having looked at the planning phase in session one of this series, we will turn our focus to the readiness phase. The all important technical capabilities assessment, ensuring the network, endpoints and users are adequately prepared for the move.
Hear first hand from IR's Global Head of Information Systems and Technology, Jason Schwendinger, on how he has been tackling these issues.Join webinar