Incorrect call direction

[szaidi1]

Cusotmer has deployed Mynavoice recording solution to record calls of IP extensions of Avaya IPO. Problem is that Mynavoice gets a ringing event just before when an IP extension makes an outbound call and that makes Mynavoice classifying that outbound call as an inbound call.

Could we do anything on Avaya side?


Here are the logs Mynavoice shared:

 

[holdmusic34]

Not really. They're reading Monitor wrong or wireshark wrong. Xima read it correctly with no telephony changes. They should too.

Some songs are very, very long. This one isn't.

 

[IPGuru]

are these ISDN lines or SIP
what are Mynavoice monitoring from the IPO (if anything) to help with their diagnostic of call type?
Do they have any other IP Office installations?
are thay signed up to the Avaya Dev-Connect program or are they trying to go it alone?

My guess is that they are misinterpreting whatever they are using, there will be nothing on the IP Office you can do to control this



Do things on the cheap & it will cost you dear

 

[montyzummer]

So Below is the SMDR mechanics.I have also included some examples (all from the knowledge base), there is an SMDR collection tool Specifically for IPO it is at the below address under Tools, that will show you in real time what is happening (just in case monitor and SSA don't give you the proof you need I:E direction of call)

http://marketingtools.avaya.com/knowledgebase/businesspartner/index.html

As the other techs have already pointed out , this is not the IPO reporting incorrect data , simply the way your vendor is reading the data , lets be very clear do not waste time trouble shooting this , provide them with the below information , point them to this post and get them to manage their application to collect and read the data correctly , sounds harsh maybe but its as simple as that.

http://marketingtools.avaya.com/knowledgebase/businesspartner/index.html

SMDR Fields
The SMDR output contains the following fields. Note that time values are rounded up to the nearest second.

Call Start

Call start time in the format YYYY/MM/DD HH:MM:SS. For all transferred call segment this is the time the call was initiated, so each segment of the call has the same call start time.

Connected Time

Duration of the connected part of the call in HH:MM:SS format. This does not include ringing, held and parked time. A lost or failed call will have a duration of 00:00:00. The total duration of a record is calculated as Connected Time + Ring Time + Hold Time + Park Time.

Ring Time

Duration of the ring part of the call in seconds.

For inbound calls this represents the interval between the call arriving at the switch and it being answered, not the time it rang at an individual extension.

For outbound calls, this indicates the interval between the call being initiated and being answered at the remote end if supported by the trunk type. Analog trunks are not able to detect remote answer and therefore cannot provide a ring duration for outbound calls.

Caller

The callers' number. If the call was originated at an extension, this will be that extension number. If the call originated externally, this will be the CLI of the caller if available, otherwise blank.

For SIP trunks, the field can contain the number plus IP address. For example 12345@192.0.2.123.

Direction

Direction of the call – I for Inbound, O for outbound. Internal calls are represented as O for outbound. This field can be used in conjunction with Is_Internal below to determine if the call is internal, external outbound or external inbound.

Called Number

This is the number called by the system. For a call that is transferred this field shows the original called number, not the number of the party who transferred the call.

Internal calls: The extension, group or short code called.

Inbound calls: The target extension number for the call.

Outbound calls: The dialed digits.

Voice Mail: Calls to a user's own voicemail mailbox.

Dialled Number

For internal calls and outbound calls, this is identical to the Called Number above. For inbound calls, this is the DDI of the incoming caller.

Account

The last account code attached to the call.

note Note
System account codes may contain alphanumeric characters.

Is Internal

0 or 1, denoting whether both parties on the call are internal or external (1 being an internal call). Calls to destinations on other switches in a network are indicated as internal.

Direction Is Internal Call Type
I 0 Incoming external call.
O 1 Internal call.
O 0 Outgoing external call.
Call ID

This is a number starting from 1,000,000 and incremented by 1 for each unique call. If the call has generates several SMDR records, each record will have the same Call ID. Note that the Call ID used is restarted from 1,000,000 if the system is restarted.

Continuation

1 if there is a further record for this call id, 0 otherwise.

Party1Device

The device 1 number. This is usually the call initiator though in some scenarios such as conferences this may vary. If an extension/hunt group is involved in the call its details will have priority over a trunk. That includes remote network destinations.

Type Party Device Party Name
Internal Number E<extension number> <name>
Voicemail V<9500 + channel number> VM Channel <channel number>
Conference V<1><conference number>+<channel number> CO Channel <conference number.channel number>
Line T<9000+line number> Line <line number>.<channel if applicable>
Other V<8000+device number> U<device class> <device number>.<device channel>
Unknown/Tone V8000 U1 0.0
Party1Name

The name of the device – for an extension or agent, this is the user name.

Party2Device

The other party for the SMDR record of this call segment. See Party1Device above.

For barred calls, this field is populated with “Barred”.

Party2Name

The other party for the SMDR record of this call segment. See Party1Name above.

For barred calls, this field is populated with “Barred”.

Hold Time

The amount of time in seconds the call has been held during this call segment.

Park Time

The amount of time in seconds the call has been parked during this call segment.

AuthCode

For security, this field shows n/a regardless of whether an authorization code was used.

AuthValid

This field is used for authorization codes. This field shows 1 for valid authorization or 0 for invalid authorization.

User Charged

This and the following fields are used for ISDN Advice of Charge (AoC). The user to which the call charge has been assigned. This is not necessarily the user involved in the call.

Call Charge

The total call charge calculated using the line cost per unit and user markup.

Currency

The currency. This is a system wide setting set in the system configuration.

Amount at Last User Change

The current AoC amount at user change.

Call Units

The total call units.

Units at Last User Change

The current AoC units at user change.

Cost per Unit

This value is set in the system configuration against each line on which Advice of Charge signalling is set. The values are 1/10,000th of a currency unit. For example if the call cost per unit is £1.07, a value of 10700 should be set on the line.

Mark Up

Indicates the mark up value set in the system configuration for the user to which the call is being charged. The field is in units of 1/100th, for example an entry of 100 is a markup factor of 1 .

External Targeting Cause

This field indicates who or what caused the external call and a reason code. For example U FU indicates that the external call was caused by the Forward Unconditional setting of a User.

Targeted by Reason Code
HG Hunt Group. fb Forward on Busy.
U User. fu Forward unconditional.
LINE Line. fnr Forward on No Response.
AA Auto Attendant. fdnd Forward on DND.
ICR Incoming Call Route. CfP Conference proposal (consultation) call.
RAS Remote Access Service. Cfd Conferenced.
? Other. MT Mobile Twinning.
TW Teleworker.
XfP Transfer proposal (consultation) call.
Xfd Transferred call.
External Targeter Id

The associated name of the targeter indicated in the External Targeting Cause field. For hunt groups and users this will be their name in the system configuration. For an Incoming Call Route this will be the Tag if set, otherwise ICR.

External Targeted Number

This field is used for forwarded, Incoming Call Route targeted and mobile twin calls to an external line. It shows the external number called by the system as a result of the off switch targeting where as other called fields give the original number dialled.

Server IP address of the caller extension

Fields 31 to 34 are used to uniquely identify a call made in an IP Office Server Edition solution.

This IP address identifies the server where the call was initiated. If the field does not contain an IP address, then the call originated outside the IP Office network.

Unique call id for the caller extension

Numerical value that is a unique identifier of the call on the server where the call was initiated.

Server IP address of the called extension

This IP address identifies the server where the called extension is logged in. If the field does not contain an IP address, then the call is to a trunk outside the IP Office network.

Unique call id for the called extension

Numerical value that is a unique identifier of the call on the server where the called extension is logged in.

UTC time

Coordinated Universal Time (UTC) using the format YYYY/MM/DD HH:MM:SS.

Parent topic: Appendix: SMDR


THIS IS SOME EXAMPLE OUTPUTS



Contents Bookmark
SMDR Examples
The following are examples of system SMDR records for common call scenarios.

Lost incoming Call
In this record, the Call duration is zero and the Continuation field is 0, indicating that the call was never connected. The Ring Time shows that it rang for 9 seconds before ending.

2014/06/28 09:28:41,00:00:00,9,8004206,I,4324,4324,,0,1000014155,0,E4324,Joe Bloggs,T9161,LINE 5.1,0,0,,,,,,,,,,,,,
Call Answered by Voicemail
In this example, 215 has made a call to 211. However the Party2Device and Party2Name show that the call was answered by voicemail.

2014/10/20 06:43:58,00:00:10,21,215,O,211,211,,I,28,0,E215,Extn215,V9051,VM Channel 1,0,0,,,,,,,,,,,,,
Call Transferred to Voicemail
In this example, the Continuation field in the first record tells us that it wasn't the end of the call. The matching Call ID identifies the second record as part of the same call. The change in Party 1 details between the two records show that the call was transferred to voicemail.

2014/06/28 09:30:57,00:00:13,7,01707392200,I,299999,299999,,0,1000014160,1,E4750,John Smith,T9002,LINE 1.2,11,0,,,,,,,,,,,,, 2014/06/28 09:30:57,00:00:21,0,01707392200,I,299999,299999,,0,1000014160,0,V9502,VM Channel 2,T9002,LINE 1.2,0,0,,,,,,,,,,,,,
External Call
The Is Internal field being 0 shows this to be a external call. The Direction field as I shows that it was an incoming call. The Ring Time was 7 seconds and the total Connected Time was 5 seconds.

2014/08/01 15:14:19,00:00:05,7,01707299900,I,403,390664,,0,1000013,0,E403,Extn403,T9001,Line 1.2,0,0,,,,,,,,,,,,,,
Internal Call
The Is Internal field being 1 shows this to be a internal call. The Ring Time was 4 seconds and the total Connected Time was 44 seconds.

2014/06/26 10:27:44,00:00:44,4,4688,O,4207,4207,,1,1000013898,0,E4688,Joe Bloggs,E4207,John Smith,0,0,,,,,,,,,,,,,
Outgoing Call
The combination of the Direction field being outbound and the Is Internal field be 0 show that this was a outgoing external call. The line (and in this case channel) used are indicated by the Party2 Name and being a digital channel the Ring Time before the call was answered is also shown.

2014/06/28 08:55:02,00:08:51,9,4797,O,08000123456,08000123456,,0,1000014129,0,E4797,Joe Bloggs,T9001,LINE 1.1,0,0,,,,,,,,,,,,,
Voicemail Call
The two records below show calls to voicemail. The first shows the Dialed Number as*17, the default short code for voicemail access. The second shows the Dialed Number as VoiceMail, indicating some other method such as the Message key on a phone was used to initiate the call.

2014/06/28 09:06:03,00:00:19,0,4966,O,*17,*17[1],,1,1000014131,0,E4966,John Smith,V9501,VM Channel 1,0,0,,,,,,,,,,,,, 2014/06/28 09:06:03,00:00:19,0,4966,O,VoiceMail,VoiceMail,,1,1000014134,0,E4966,John Smith,V9501,VM Channel 1,0,0,,,,,,,,,,,,,
Parked Call
In this example the first record has a Park Time showing that the call was parked. The Continuation field indicates that the call did not end this way and there are further records. The second record has the same Call ID and shows a change in the Party2Name [4], indicating that party unparked the call. Note also that both records share the same call start time.

2014/10/20 07:18:31,00:00:12,3,215,O,210,210,,1,38,1,E215,Extn215,E210,Extn210,0,7,,,,,,,,,,,,, 2014/10/20 07:18:31,00:00:10,0,215,O,210,210,,1,38,0,E215,Extn215,E211,Extn211,0,0,,,,,,,,,,,,,
Incoming call with Account Code
In this example, at some stage as the call was made or during the call, an Account Code has been entered.

2014/06/28 11:29:12,00:00:02,2,5002,I,1924,1924,Support,0,1000014169,0,E1924,Extn1924,T9620,LINE 8.20,0,0,,,,,,,,,,,,,
Conference Using Conference Add Short Code
In this example 2101 has made a call and put put it on hold (record 2), then made another call and put it on hold (record 1) and then dialled the default short code *47 to conference all their held calls (record 3). The records for the first two calls have the Continuation field set as 1 indicating that the calls continued in further records.

Record 3 shows 2101 making a new call in which they dial *47, which places them and their held calls into a conference. This is shown by the Party Device and Party Name details as being a conference (100) and the conference channel used for each.

For both the Continuation fields show that the calls do not end but rather have subsequent records.

2014/07/09 17:55,00:00:03,3,2101,O,8262623#,8262623#,,0,1000024,1,E2101,Extn2101,T9002,Line 2.1,8,0,,,,,,,,,,,,,
2014/07/09 17:54,00:00:29,7,2101,O,2121,2121,,1,1000023,1,E2101,Extn2101,E2121,Extn2121,23,0,,,,,,,,,,,,,
2014/07/09 17:55,00:00:46,0,2101,O,*47,*47,,1,1000026,0,E2101,Extn2101,V11001,CO Channel 100.1,0,0,,,,,,,,,,,,,
2014/07/09 17:54,00:00:49,0,,O,71234567890,71234567890,,1,1000023,0,E2121,Extn2121,V11003,CO Channel 100.3,0,0,,,,,,,,,,,,,
2014/07/09 17:55,00:00:49,0,,O,8262623#,8262623#,,0,1000024,0,V11002,CO Channel 100.2,T9002,Line 2.1,0,0,,,,,,,,,,,,,
Conference Using Conference Button
In this example, an extension user answers a call and then brings in another user by using the Conference button on their phone. Again we see records for the initial call, the conference proposal call and then for the 3 parties in the conference that is created.

2014/07/09 15:05:41,00:00:04,3,203,O,201,201,,1,1000009,1,E203,Extn203,E201,Extn201,0,0,,,,,,,,,,,,,
2014/07/09 15:05:26,00:00:09,3,207,O,203,203,,1,1000008,1,E207,Extn207,E203,Extn203,10,0,,,,,,,,,,,,,
2014/07/09 15:05:41,00:00:08,0,,O,,,,1,1000009,0,E201,Extn201,V11001,CO Channel 100.1,0,0,,,,,,,,,,,,,
2014/07/09 15:05:50,00:00:10,0,203,O,201,201,,1,1000010,0,E203,Extn203,V11002,CO Channel 100.2,0,0,,,,,,,,,,,,,
2014/07/09 15:05:26,00:00:10,0,207,O,203,203,,1,1000008,0,E207,Extn207,V11003,CO Channel 100.3,0,0,,,,,,,,,,,,,
Adding a Party to a Conference
This example is a variant on that above. Having started a conference, extension 203 adds another party.

2014/07/09 15:08:31,00:00:03,3,203,O,201,201,,1,1000014,1,E203,Extn203,E201,Extn201,0,0,,,,,,,,,,,,,
2014/07/09 15:08:02,00:00:22,6,207,O,203,203,,1,1000013,1,E207,Extn207,E203,Extn203,9,0,,,,,,,,,,,,,
2014/07/09 15:08:45,00:00:02,4,203,O,403,403,,0,1000016,1,E203,Extn203,E403,Libby Franks,0,0,,,,,,,,,,,,,
2014/07/09 15:08:02,00:00:24,0,207,O,203,203,,1,1000013,0,E207,Extn207,V11003,CO Channel 100.3,0,0,,,,,,,,,,,,,
2014/07/09 15:08:39,00:00:17,0,203,O,201,201,,1,1000015,0,E203,Extn203,V11002,CO Channel 100.2,8,0,,,,,,,,,,,,,
2014/07/09 15:08:31,00:00:26,0,,O,,,,1,1000014,0,E201,Extn201,V11001,CO Channel 100.1,0,0,,,,,,,,,,,,,
2014/07/09 15:08:45,00:00:12,0,,O,403,403,,0,1000016,0,E403,Libby Franks,V11004,CO Channel 100.4,0,0,,,,,,,,,,,,,
Transfer
In this example 2126 has called 2102. The record (1) for this has the Continuation set a 1 indicating that it has further records. In the following record (3) with the same Call ID it can be seen that the Party 2 Device and Party 2 Name fields have changed, indicating that the call is now connected to a different device, in this example 2121. We can infer the blind transfer from the intermediate record (2) which shows a call of zero Connected Time between the original call destination 2102 and the final destination 2121.

2014/07/09 17:51,00:00:38,18,2126,O,2102,2102,,1,1000019,1,E2126,Extn2126,E2102,Extn2102,19,0,,,,,,,,,,,,,
2014/07/09 17:52,00:00:00,7,2102,O,2121,2121,,1,1000020,0,E2102,Extn2102,E2121,Extn2121,0,0,,,,,,,,,,,,,
2014/07/09 17:51,00:00:39,16,2126,O,2102,2102,,1,1000019,0,E2126,Extn2126,E2121,Extn2121,0,0,,,,,,,,,,,,,
In this second example extension 402 answers an external call and then transfers it to extension 403. Again the two legs of the external call have the same time/date stamp and same call ID.

2014/08/01 15:23:37,00:00:04,7,01707299900,I,4001,390664,,0,1000019,1,E402,Extn402,T9001,Line 1.1,6,0,,,,,,,,,,,,,,
2014/08/01 15:23:46,00:00:00,3,402,O,403,403,,1,1000020,0,E402,Extn402,E403,Extn403,0,0,,,,,,,,,,,,,,
2014/08/01 15:23:37,00:00:04,4,01707299900,I,4001,390664,,0,1000019,0,E403,Extn403,T9001,Line 1.1,0,0,,,,,,,,,,,,,,
Busy/Number Unavailable Tone
In this example 2122 calls 2123 who is set to DND without voicemail. This results in 2122 receiving busy tone.

The records shows a call with a Connected Time of 0. The Call Number field shows 2123 as the call target but the Party 2 Device and Party 2 Name fields show that the connection is to a virtual device.

2014/07/09 17:59,00:00:00,0,2122,O,2123,2123,,1,1000033,0,E2122,Extn2122,V8000,U1 0.0,0,0,,,,,,,,,,,,,
Call Pickup
The first record shows a call from 2122 to 2124 with a Connected Time of zero but a Ring Time of 8. The Continuation field indicates that the call has further records.

The second record has the same Call ID but the Party 2 Device and Party 2 Name details show that the call has been answered by 2121.

2014/07/09 18:00,00:00:00,8,2122,O,2124,2124,,1,1000038,1,E2122,Extn2122,E2124,Extn2124,0,0,,,,,,,,,,,,,
2014/07/09 18:00,00:00:38,1,2122,O,2124,2124,,1,1000038,0,E2122,Extn2122,E2121,Extn2121,0,0,,,,,,,,,,,,,
Internal Twinning
The records for scenarios such as internal call forwarding or follow me indicate the rerouting in a single record by having Caller and Called Number details that differ from the final Party 1 and Party 2 details. Internal twinning differs is showing a call answered at the twin exactly the same as having been answered at the primary.

203 is internally twinned to 201. Call from 207 to 203 but answer at 201.

2014/07/09 16:25:26,00:00:03,7,207,O,203,203,,1,1000037,0,E207,Extn207,E203,Extn203,0,0,,,,,,,,,,,,,
Park and Unpark
Parking and unparking of a call at the same extension is simply shown by the Park Time field of the eventual SMDR record. Similarly calls held and unheld at the same extension are shown by the Held Time field of the eventual SMDR record for the call. The records below however show a call parked at one extension and then unparked at another.

The records show a call from 207 to 203. 203 then parks the call shown by the Park Time. The call is unparked by 201, hence the first record is indicated as continued in its Continuation field. The matching Call ID indicates the subsequent record for the call.

2014/07/09 16:39:11,00:00:00,2,207,O,203,203,,1,1000052,1,E207,Extn207,E203,Extn203,0,4,,,,,,,,,,,,,
2014/07/09 16:39:11,00:00:02,0,207,O,203,203,,1,1000052,0,E207,Extn207,E201,Extn201,0,0,,,,,,,,,,,,,
Distributed Hunt Group Call
An incoming call to site A is targeted to a distributed hunt group member on site B. They transfer the call back to a hunt group member on site A.

2014/08/01 15:32:52,00:00:10,19,01707299900,I,4002,390664,,0,1000024,1,E209,Luther-209,T9001,Line 1.2,0,0,,,,,,,,,,,,,,
2014/08/01 15:33:19,00:00:00,2,209,I,403,403,,0,1000025,0,E209,Luther-209,E403,Extn403,0,0,,,,,,,,,,,,,,
2014/08/01 15:32:52,00:00:03,3,01707299900,I,4002,390664,,0,1000024,0,E403,Extn403,T9001,Line 1.2,0,0,,,,,,,,,,,,,,
Voicemail Supervised Transfer
A call is routed to a voicemail module that performs a supervised transfer.

2014/08/01 16:36:04,00:00:09,0,01707299900,I,xfer,390664,,0,1000061,1,T9001,Line 1.1,V9508,VM Channel 8,0,0,,,,,,,,,,,,,,
2014/08/01 16:36:07,00:00:03,4,,I,402,402,,0,1000062,0,E402,Extn402,V8000,U12 0.8,0,0,,,,,,,,,,,,,,
2014/08/01 16:36:04,00:00:09,0,01707299900,I,402,390664,,0,1000061,0,E402,Extn402,T9001,Line 1.1,0,0,,,,,,,,,,,,,,
Outgoing External Call
The External Targeting Cause indicates that the external call was caused by a user. The lack of specific reason implies that it was most likely dialed. The External Targeter ID is the user name in this example

… 16:23:06,00:00:04,5,203,O,9416,9416,,0,1000035,0,E203,Extn203,T9005,Line 5.1,0,0,,,Extn203,,,,,,,,U,Extn203,,
Rerouted External Call
In this example an incoming external call has been rerouted back off switch, shown by the Party 1 fields and the Party 2 fields being external line details. The External Targeter Cause shows that rerouting of the incoming call was done by an incoming call route (ICR). The External Targeter ID in this case is the Tag set on the incoming call route. The External Targeted Number is the actual external number call.

… 08:14:27,00:00:03,5,392200,I,9416,200,,0,1000073,0,T9005,Line 5.1,T9005,Line 5.2,0,0,,,,0000.00,,0000.00,0,0,618,0.01,ICR,Main ICR,416,
External Forward Unconditional
In this example, user 203 has a forward unconditional number set for calls. This is indicated by the External Targeting Cause showing user and forward unconditional. The External Targeter ID shows the source of the call being forwarded, in this example user 207. The External Targeted Number shows the actual external number called by the system.

… 16:22:41,00:00:02,5,207,O,203,203,,0,1000034,0,E207,Extn207,T9005,Line 5.1,0,0,,,Extn203,0000.00,,0000.00,0,0,618,1.00,U fu,Extn207,9416,
Transferred Manually
In this example the internal user transfers a call to an external number. The External Targeting Cause in the first record indicates that this external call is the result of a user (U) transfer proposal (XfP) call. The Continuation field indicates that another record with the same Call ID will be output.

The additional records are output after the transferred call is completed. The first relates to the initial call prior. The second is the transferred call with the External Targeting Cause now indicating user (U) transferred (Xfd).

… 16:33:19,00:00:05,3,203,O,9416,9416,,0,1000044,1,E203,Extn203,T9005,Line 5.1,0,0,,,,,,,,,,,U XfP,Extn207,,
… 16:33:09,00:00:02,2,207,O,203,203,,1,1000043,0,E207,Extn207,E203,Extn203,11,0,,,,,,,,,,,,,,
… 16:33:19,00:00:04,0,207,O,9416,9416,,0,1000044,0,E207,Extn207,T9005,Line 5.1,0,0,,,Extn207,,,,,,,,U Xfd,Extn203,,
Mobile Twinned Call Answered Internally
For this example user 203 has mobile twining enabled to the external number 9416 as twin. Their mobile dial delay is set to 2 seconds. The call is answered at the user's internal extension.

In this scenario the record for the external call part of twinning is output immediately the call is answered internally. The Call Start for this record differs dues to the user's Mobile Dial Delay setting. The External Targeting Cause indicates the external call was the result of user (U) mobile twinning (MT) settings. If the call had been answered before the mobile dial delay expired, no external call and therefore no record would be produced. When the call is completed the second record is output.

… 16:17:59,00:00:00,7,,O,9416,9416,,0,1000028,0,E203,Extn203,T9005,Line 5.1,0,0,,,,,,,,,,,U MT,Extn203,9416,
… 16:17:58,00:00:07,9,207,O,203,203,,1,1000027,0,E207,Extn207,E203,Extn203,0,0,,,,,,,,,,,,,,
Mobile Twinned Call Answered at the Mobile Twin
This is the same scenario as the example above except that the call is answered at the external mobile twinning destination. Unlike the previous example the external call record has a non-zero Call Time showing that the call was also answered externally.

… 16:17:04,00:00:06,9,,O,9416,9416,,0,1000026,0,E203,Extn203,T9005,Line 5.1,0,0,,,,,,,,,,,U MT,Extn203,9416
… 16:17:02,00:00:06,11,207,O,203,203,,1,1000025,0,E207,Extn207,E203,Extn203,0,0,,,,,,,,,,,,,,
Mobile Twinned Call Picked Up Using the Twinning Button
This is the same scenario as the example above, however after answering the call on the external twinned device, the user has picked it up internally by using a twinning button. The first two records are for the answered external call and are output when that call is picked up by the internal extension. The third record is output when the call is ended internally.

… 16:19:18,00:00:05,11,207,O,203,203,,1,1000029,1,E207,Extn207,E203,Extn203,0,0,,,,,,,,,,,,,,
… 16:19:20,00:00:05,9,,O,9416,9416,,0,1000030,0,E203,Extn203,T9005,Line 5.1,0,0,,,,,,,,,,,U MT,Extn203,9416
… 16:19:18,00:00:05,0,207,O,203,203,,1,1000029,0,E207,Extn207,E203,Extn203,0,0,,,,,,,,,,,,,,
External Conference Party
This is similar to internal conferencing (see examples above) but the conference setup and progress records include External Targeting Cause codes for user (U) conference proposal (CfP) and user (U) conferenced (Cfd).

… 16:48:58,00:00:02,2,203,O,9416,9416,,0,1000066,1,E203,Extn203,T9005,Line 5.1,0,0,,,,,,,,,,,U CfP,Extn203,,
… 16:48:37,00:00:04,3,203,O,207,207,,1,1000064,1,E203,Extn203,E207,Extn207,7,0,,,,,,,,,,,,,,
… 16:49:04,00:00:08,0,203,O,9416,9416,,1,1000067,0,E203,Extn203,V11002,CO Channel 100.2,0,0,,,,,,,,,,,,,,
… 16:48:37,00:00:13,0,,O,,,,1,1000064,0,E207,Extn207,V11003,CO Channel 100.3,0,0,,,,,,,,,,,,,,
… 16:48:58,00:00:13,0,,O,9416,9416,,0,1000066,0,V11001,CO Channel 100.1,T9005,Line 5.1,0,0,,,Extn203,,,,,,,,U Cfd,Extn203,
Call Routed by Incoming Call Route
Call from external number 403 rerouted by incoming call route (ICR) for incoming line group 701 back out to 404.

2014/08/01 11:45:36,00:00:01,2,403,I,9404,,,0,1000007,0,T9001,Line 1.0,T9010,Line 10.0,0,0,0,n/a,,,,,,,,,ICR,ICR701,404
Two Outgoing External Calls Transferred Together
This scenario shows an outgoing call which is then transferred to another outgoing call.

2009/02/19 11:13:26,00:00:06,0,203,O,9403,9403,,0,1000012,1,E203,Extn203,T9001,Line 1.0,8,0,0,n/a,,,,,,,,,U,Extn203,,
2009/02/19 11:13:36,00:00:02,0,203,O,8404,8404,,0,1000013,0,E203,Extn203,T9002,Line 2.0,0,0,0,n/a,,,,,,,,,U XfP,Extn203,,
2009/02/19 11:13:26,00:00:11,0,8404,I,404,,,0,1000012,0,T9002,Line 2.0,T9001,Line 1.0,0,0,0,n/a,,,,,,,,,LINE Xfd,0.1038.0 13 Alog Trunk:2,,
Authorization code
In this example, an authorization code was used and the 0 indicates that it is invalid:

2014/02/20 11:04:59,00:00:00,0,319,O,,,,0,1000009,0,E319,Alice,V8000,U1 0.0,0,0,0,n/a,,,,,,,,,U,Alice,
In this example, the authorization code is valid.

2014/02/20 11:04:59,00:00:00,0,319,O,,,,0,1000009,0,E319,Alice,V8000,U1 0.0,0,0,1,n/a,,,,,,,,,U,Alice,
Server Edition Call ID
In this example, a call is made from extension 1234 on Expansion1 to extension 4321 on Expansion2.

Expansion1 IP address: 192:168:42:192

Call ID on Expansion1: 1002

Expansion2 IP address: 192:168:42:193

Call ID on Expansion2: 1004

Primary output:
2014/04/08 16:42:05,00:00:01,3,1234,O,4321,4321,,1,1000000,0,E1234,Extn1234,E4321,Extn4321,0,0,,,,,,,,,,,,,
Expansion1 output:
2014/04/08 16:42:04,00:00:01,3,1234,O,4321,4321,,1,1000000,0,E1234,Extn1234,E4321,Extn4321,0,0,,,,,,,,,,,,,
Expansion2 output:
2014/04/08 13:42:05,00:00:01,3,1234,I,4321,4321,,1,1000000,0,E1234,Extn1234,E4321,Extn4321,0,0,,,,,,,,,,,,,
Parent topic: Appendix: SMDR

ACSS (UC/SBCE/SM/SME)

Not that they mean a thing anymore , get a brain dump pass the test crash the system.

 

[montyzummer]

That is of course if the application uses SMDR , if not just ignore the above

ACSS (UC/SBCE/SM/SME)

Not that they mean a thing anymore , get a brain dump pass the test crash the system.

 

[szaidi1]

Sorry for the late reply.

IP Phones are using analog lines for outbound. Mynavoice records calls by monitoring data/voice streams on LAN switch ports.

There is a document on their website about their connectivity with Avaya IP Office. Not much in document though.

http://www.mynavoice.com/products/voice-recording/connectivity.html

Any suggestions?

 

[janni78]

You can't fix the IPO, they need to adapt their application to IP Office, or at least tell you what you've done wrong.

It's not strange that you get ringing on outgoing calls.

"Trying is the first step to failure..." - Homer

 

[amriddle01]

The systems coding is fixed, it cannot be changed by anyone except Avaya. It works with every call recorder/logger that has done proper compatibility testing or tailored their software to read the feeds from the IP Office correctly.

I would say Mynavoice have done neither, and there is no way you can change the way the IP Office works at such a fundamental level to account for or compensate for their shortcomings. If they had bothered doing the testing correctly this would have come to light instantly, it's always worked this way

Tell them to fix their sh1t, it's not your issue to fix, nor Avaya's