Hi, I am sorry if this has been explained before but I am really confused in all this, reading everything I can on the subject, but I need to fully understand how to read a specific CDR scenario for my office.
We have software that reads the raw CDR output collected live
from the cs1000 (version 6) via the serial port. We then save
this info in order to make reports. Now this usually goes
really well, we thought we understood the CDR format
correctly and that EVERY single call was successfully
captured, except recently we have noticed that a good amount
of calls are not being imported by our software. After
analyzing in greater detail I notice one scenario that does
not fit our defined formats (the ones we capture
successfully). So I just wanted to show you a few raw CDR
examples and how we read them, as well as show you the
'weird' ones that I don't know how to interpret.
Example #1:
------------------------------------------------------------
S 054 00 T000035 8958 09/26 14:50 00:00:20
& 0000 0000 4182651919XXXXXX
...
...
E 073 00 T000035 8988 09/26 14:53 00:02:50
& 0000 0000 4182651919XXXXXX
------------------------------------------------------------
This is a VALID CALL for me, I would interpret this example
as the following:'8958' receives an INCOMING call from
'4182651919', then transfers the call to '8988'.
My logic for treating this call is: 'S' (Record Type) means
the START of a call that will be on multiple lines, so once
I receive a 'S' I look for the next '000035' (Originating)
that is also a Record Type 'E' (END). So in a perfect world,
that is exactly how I build up my calls, so first of all is
this the PERFECT way of doing?
Now here is an example of a format that I DON'T know how to
handle:
------------------------------------------------------------
S 103 00 T000034 8958 09/26 14:16 00:10:52
& 0000 0000 4189156852XXXXXX
...
...
E 055 00 T000034 A009042 09/26 14:36 00:08:40
& 0000 0000 4189156852XXXXXX
------------------------------------------------------------
I have the START (S) I have the END (E), I link them
together by finding the Originating (000034), but look at
the Terminating... What is this, how do I interpret this?
'8958' received an INCOMING call from '4189156852', then
transferred the call to..... 'A009042'?? What does this
mean, it represents about 10% of all my office calls. Now after reading most of the latest Avaya CDR manual, I found this means a "Answer Supervision" call. Then I studied this and from what I get (correct me if I am wrong), this is a signal that the CO sends to confirm the recipient has answered, and in the CDR there is an option to only output the answered calls (OAN = CDR for answered calls only). Which makes sense, this is what I want, but that still doesnt tell me how do I handle this call. Basically what calling scenario happened to results in this CDR output, THAT is the part I need to understand..
Here is another example that I just don't know how to read,
can you translate into words how you see this call?
------------------------------------------------------------
S 102 00 8958 T009042 09/26 14:27 00:00:00 A
790918666084746
& 0000 0000
...
...
E 055 00 T000034 A009042 09/26 14:36 00:08:40
& 0000 0000 4189156852XXXXXX
------------------------------------------------------------
Notice in this case the START (S) is not in the same order
(Originating/Terminating) as most other calls, how to you
read this START line? I am also not sure what is the correct
END (E), I guessed this END because of the '009042' but I am
really not sure. Maybe you can find the correct END (if any)
in the raw log attached to this ticket.
Basically if you REALLY want to help me, I would be
extremely thankful if you can read this small CDR log that I
will attach to this ticket. It is the CDR of ONE day from my
cs1000. Don't be overwhelmed by the number of lines, what I
would love is if you can analyse only all the calls from
'8958' and tell me how you would define the actions of this
extension for this given day. There are only 14 references
to '8958' in the entire log so it will only take you a few
minutes. After this I will feel a lot more confident that I
am treating all my calls correctly.
Thanks A LOT in advance guys, so glad I found this forum!
We have software that reads the raw CDR output collected live
from the cs1000 (version 6) via the serial port. We then save
this info in order to make reports. Now this usually goes
really well, we thought we understood the CDR format
correctly and that EVERY single call was successfully
captured, except recently we have noticed that a good amount
of calls are not being imported by our software. After
analyzing in greater detail I notice one scenario that does
not fit our defined formats (the ones we capture
successfully). So I just wanted to show you a few raw CDR
examples and how we read them, as well as show you the
'weird' ones that I don't know how to interpret.
Example #1:
------------------------------------------------------------
S 054 00 T000035 8958 09/26 14:50 00:00:20
& 0000 0000 4182651919XXXXXX
...
...
E 073 00 T000035 8988 09/26 14:53 00:02:50
& 0000 0000 4182651919XXXXXX
------------------------------------------------------------
This is a VALID CALL for me, I would interpret this example
as the following:'8958' receives an INCOMING call from
'4182651919', then transfers the call to '8988'.
My logic for treating this call is: 'S' (Record Type) means
the START of a call that will be on multiple lines, so once
I receive a 'S' I look for the next '000035' (Originating)
that is also a Record Type 'E' (END). So in a perfect world,
that is exactly how I build up my calls, so first of all is
this the PERFECT way of doing?
Now here is an example of a format that I DON'T know how to
handle:
------------------------------------------------------------
S 103 00 T000034 8958 09/26 14:16 00:10:52
& 0000 0000 4189156852XXXXXX
...
...
E 055 00 T000034 A009042 09/26 14:36 00:08:40
& 0000 0000 4189156852XXXXXX
------------------------------------------------------------
I have the START (S) I have the END (E), I link them
together by finding the Originating (000034), but look at
the Terminating... What is this, how do I interpret this?
'8958' received an INCOMING call from '4189156852', then
transferred the call to..... 'A009042'?? What does this
mean, it represents about 10% of all my office calls. Now after reading most of the latest Avaya CDR manual, I found this means a "Answer Supervision" call. Then I studied this and from what I get (correct me if I am wrong), this is a signal that the CO sends to confirm the recipient has answered, and in the CDR there is an option to only output the answered calls (OAN = CDR for answered calls only). Which makes sense, this is what I want, but that still doesnt tell me how do I handle this call. Basically what calling scenario happened to results in this CDR output, THAT is the part I need to understand..
Here is another example that I just don't know how to read,
can you translate into words how you see this call?
------------------------------------------------------------
S 102 00 8958 T009042 09/26 14:27 00:00:00 A
790918666084746
& 0000 0000
...
...
E 055 00 T000034 A009042 09/26 14:36 00:08:40
& 0000 0000 4189156852XXXXXX
------------------------------------------------------------
Notice in this case the START (S) is not in the same order
(Originating/Terminating) as most other calls, how to you
read this START line? I am also not sure what is the correct
END (E), I guessed this END because of the '009042' but I am
really not sure. Maybe you can find the correct END (if any)
in the raw log attached to this ticket.
Basically if you REALLY want to help me, I would be
extremely thankful if you can read this small CDR log that I
will attach to this ticket. It is the CDR of ONE day from my
cs1000. Don't be overwhelmed by the number of lines, what I
would love is if you can analyse only all the calls from
'8958' and tell me how you would define the actions of this
extension for this given day. There are only 14 references
to '8958' in the entire log so it will only take you a few
minutes. After this I will feel a lot more confident that I
am treating all my calls correctly.
Thanks A LOT in advance guys, so glad I found this forum!