I have an odd problem with SO. below is an example sent to the client:

Extension 3362 was given recording phone 1432145 at 11:16 utc. We recorded calls for that extension till 18:00 utc. Then the same recording phone was given to extension 3365. We did not record any calls for that extension for the rest of the day. We got no media started events (except for when we dialed the FAC code). Finally extension 3365 is given recording phone 1432039 and we get audio for their calls.

Sounds like the SO was not setup correctly for 3365. Make sure that ithe recorder was disconnected correctly from 3362 and the correct steps were taken for 3365 (on-hook, off-hook FAC). Make sure the FAC worked correctly and any expected responses were received.

You could also try using the DMCC dashboard as the recorder and use it to setup the SO. See if you can reproduce your problem that way, outside of your application.

Martin

Sounds like you are talking about issues at a production site. Is that true?
Has the customer involved Avaya Client Services?
Is your solution DevConnect Compliance tested?
Are you able to reproduce the issue?
Do you have any Avaya side log files of the issue occurring (DMCC & TSAPI)?
How did the application switch from SO of 3362 to SO of 3365? by hanging up, and originating a new call with the SO FAC and extension 3365? or some other activity?
Was this done directly through TSAPI or DMCC?
Which releases of products and SDKs are involved?

There are reasons that Service Observing of a destination station can be blocked intermittently (e.g. already the maximum number of parties in the call).

Martin,

Here is a workflow of how i handle the agents and phone.

1)Extension 3362 logs in and is assigned 1432145.
2)1432145 is registered and after the register terminal response i take the phone off hook, wait 100 ms and dial the extension and fac code.
3) After dialing the fac code, i normally see an immediate media started and media stopped event which is my indication that the SO was successful.
4) 3362 logs out and the only thing i do with 1432145 is unregister the terminal
5) extension 3365 logs in, follow steps 1 thru 4.

Here is a scenario that i just tried in my lab.
1) log in extension 70100. Assign recording phone 70408.
2) dial FAC code, i saw media started and media stopped
3) send call to 70100, verified i saw media started.
4) log out 70100. 70408 terminal is unregistered.
5) log in extension 70101, assign recording phone 70408.
6) dial FAC code, i saw media started and media stopped
7) send call to 70101, verified i saw media started.

In your latest description, your SOs seem to work correctly. What is different to the original problem?

Martin

Martin the code in my lab and the code in production are exactly the same and that is why this problem is very frustrating. The only thing i could think of was that perhaps i need the put the phone on hook before unregistering but i didn't think that would make much of a difference. To be honest i'm out of ideas.

does this scenario fail 100% in production?
Take a very close look at the station and other provisioned configuration information in production.
things like network region, availability of voip resources, a list trace, denial events are all ways to see if you can get a vector to the root issue?

Thanks John, it doesnt fail 100% percent but enough to have us concerned as it appears inconsistent. We have the client looking into it now and they will do a few traces for us.

You should definitely put the recorder on-hook when you are finished using it. I would also suggest that you not unregister it between uses.

Under what criteria do you assign a recorder to a station? per call? time of day? random? Something else?

How do you monitor the recorder to make sure it hasn't dropped out of SO mode? Do you have a SO feature function button assigned to the recorder and observe its state?

I am unsure of the interaction off the top of my head w/o going into the lab and testing it, but what happens to SO if the station that it is monitoring becomes unregistered (logs out)? Is SO canceled?

Martin,

I'm first going to try putting the phone on on hook before unregistering. if that doesnt work then i'll try not unregistering the phone, but how do i dissociate the phone from teh extension it is recording?

John,

Whenever an agent is logged out, the recording phone is recycled. When an agent logs in, it get a recording phone from the recycled pool. I do not know how to figure out if a phone has dropped out of SO mode. As far as i know there is no event i get that indicates whether or not SO was successful or if it has been dropped or cancelled.

"I do not know how to figure out if a phone has dropped out of SO mode" that would be the value of a serv-obsrv feature function button.. the lamp state would tell the application that SO was active (or not).

"how do i dissociate the phone from teh extension it is recording" go on-hook on the recorder. that exits SO mode, and if recording is active, stops it. If there is no active call at the service observee, then going on-hook at the recorder just exists SO mode.

John,

Do you have an example of code that shows me how to retrieve the lamp value for the serv-obsrv function? I looked through examples that come with dmcc app and couldn't find anything obvious.

The softphone sample app in the DMCC Java SDK probably demonstrates that code. Perhaps not for the serv-obs button but probably for a call-app.. you can use the DMCC dashboard to figure out what lamp states are applicable to what SO states.