Voice Treatment Ports (SIP) data in CCPulse

[eduardosaito]

Hi,

Recently weīve configured SIP IVR in our environment and our common CCPulse template doesnīt work with it.

As I could see, our TDM IVR, in CME, are configured as places, so they have more statistics to be collected in CCPulse than SIP.

Looking at the documentation, I can configure my stat server statistic to collect Calls Answered in VTP but I cannot collect Calls Abandoned. My goal is to configure a CCPulse template to show Calls Abandoned in a VTP and Total Ringing Time.

In CurrentState, the view always shows "CallInbound" and never changes. Is it normal?

Do you guys have any idea on how to configure Stat Server statistics to collect the data I need?

Thanks in advance.

ps: my Stat Server version is 7.6

[cavagnaro]

?? But there is no "Ringing" on SIP as it is digital, is not as TDM...
For abandon...where? In the IVR or in the RP?
As SIP ports are logical, they are not monitored in the same way, even not sure you need them...

[bublepaw]

In general VTP is not recommended way of configuring IVR behind SIP Server. In SIP world there is not such thing as port/line - probably closes term is session. If Your IVR is GVP more interesting and detailed reports can be obtained from Reporting Server.

[Fra]

Possibly, Eduardo's implementation is CTI through IVR Server, behind, PBX station-side connected, where the PBX is connected to the PSTN on one side and to a media gateway on the other, from which there's a SIP trunk to SIP Server.
When the call lands on the PBX, it actually hits a VTP on the the premise TServer, which in turn sends the EventRinging to the IVR Server.
I'm not sure why he can't gather stats on those ports if they are correctly assigned to places and monitored by Stat Server though.

Fra

[Kubig]

I agree with bublepaw, future of VTP is not good in general words and reporting server (part of R8 GVP) can get very detailed and useful information/data, better than VTP and their reporting ever can.

[cavagnaro]

VTP stands for Voice Treatment Port, right? What reporting does it provides? Not talking about VTO, right?

[eduardosaito]

Our implementation (not mine, cause I am responsable only for Historical Reports and the Oracle Database) was like Fra posted.

We are using release 7.6 with upgrade to 8 in about 6 months, but now we need to monitor the SIP IVR to detect when they start failing and our IVR starts to drop customers calls (or keep ringing till they drop).

But FRA, as I checked in CME, the VTP are not assigned to any places ... the implementation in IRD is routing the call to an ACD QUEUE that uses dnis pooling to choose the VTP to redirect the call.

Is this kind of implementation wrong or, at least, not recommended?

When I use CCPulse to monitor VTP's status, it shows always "Inbound call" status and never changes.

[eduardosaito]

cavagnaro,

yes, Voice Treatment Port. I can display answered calls, but what I need is abandoned calls and time in ringing state. Both status canīt be collected from VTP according to my tests.

[cavagnaro]

Yes, and as mentioned, as they are SIP I don't expect to see those messages there due the architecture and the protocol used.
For Abandon I'd monitor the RP, there is where Abandon occurs, not on a port...
For Ringing...ringing where? SIP doesn't ring actually...it has establishment in a immediate way, check the SIP messages, there probably a ringing but is only for compatibility

[Kubig]

Link the VTP with places and you can use standard Genesys statistics for objects of type "place". VTP ports are still monitored by IVR T-Server and standard events are generated for that. But, if you can - forget to VTP and use VoIP clear architecture.

[Fra]

[quote author=eduardosaito link=topic=8049.msg35420#msg35420 date=1382456104]
But FRA, as I checked in CME, the VTP are not assigned to any places ... the implementation in IRD is routing the call to an ACD QUEUE that uses dnis pooling to choose the VTP to redirect the call.

Is this kind of implementation wrong or, at least, not recommended?
[/quote]
Frankly, I've never heard about this implementation. I'm not sure whether this is not recommended or what: if it has worked so far, it may well be not best practise, however, still do the job.

[quote author=cavagnaro link=topic=8049.msg35422#msg35422 date=1382460458]
Yes, and as mentioned, as they are SIP I don't expect to see those messages there due the architecture and the protocol used.
For Abandon I'd monitor the RP, there is where Abandon occurs, not on a port...
For Ringing...ringing where? SIP doesn't ring actually...it has establishment in a immediate way, check the SIP messages, there probably a ringing but is only for compatibility
[/quote]
I think here you're mixing up two different things, Cav. 
We are not talking about what happens on the SIP part of the solution, but rather on the TServer / IVR Server part: as the VTPs are created in the premise TServer switch, Tserver will indeed generate an EventRinging, as soon as the call comes in from the PBX.

[quote author=Kubig link=topic=8049.msg35428#msg35428 date=1382517047]
Link the VTP with places and you can use standard Genesys statistics for objects of type "place". VTP ports are still monitored by IVR T-Server and standard events are generated for that. But, if you can - forget to VTP and use VoIP clear architecture.
[/quote]
I agree with Kubig: add each VTP to a place, and all places to a group, you should be then able to monitor regular stats.

Depending on how your v8 solution will be integrated to the PSTN, the architecture may change, but the cleanest way is without IVR Server.

Fra

[cavagnaro]

[quote author=Fra link=topic=8049.msg35429#msg35429 date=1382519913]

I think here you're mixing up two different things, Cav. 
We are not talking about what happens on the SIP part of the solution, but rather on the TServer / IVR Server part: as the VTPs are created in the premise TServer switch, Tserver will indeed generate an EventRinging, as soon as the call comes in from the PBX.

[/quote]

Yeah I know the event, even on SIP you will see a ringing, but it is on ms. Usually you measure it on TDM to know if a port is answering, how long is it taking to answer the call, if the port got stuck. But on SIP...on SIP or all answer or none answers...

So what is the point of measuring that on SIP?
I'd be more concerned on errors (sip headers) rather than measuring tons of ums, or am I missing something more?

[eduardosaito]

He still have TDM too here (will only disable them when our SIP works 100% fine) and in IRD, the strategy routes the call to a place group which contains all the places assigned to vtp ...

When the infra responsable implemented SIP here, he used , as I said earlier, he designed the strategy to route te call to an ACD Queue .....

Yesterday, I assigned a SIP vtp to a place, and linked it to a TDM Place Group ... in CCPulse, the place state is always in CallInbound, never changes, so even assigning it to a place, it still doesnīt gather data correctly ....

I wanted to find a way to monitor it through CCPulse, cause I didnīt want to create another program to analyze logs ... in TServer Log, I found a  ReRoute event with some particular data that showed me when a VTP doesnīt answer (I made a call, it didnīt answer, kept ringing for me, and then I collected the log data) and I can develop a program to detect this .... unfortunately, it would not be a real time application ....

I've already developed a program that detects when an agent hangs up a call with a client and when they push some specific buttons on the phone that makes their DN unavailable to receive a call so URS has to reroute it to another one, but my boss wants me to avoid this kind of solution cause I am the only one that can change it and help when something goes wrong ....

[cavagnaro]

Yes I do understand your idea, still saying the same...no way CCPulse will show that and on SIP a RINGING will not happen as TDM perpetually if the IVR doesn't answer.

[Kubig]

For VTP on SIP env is generated EventRinging as well. From T-Lib point of view there are no changes between TDM and SIP env (or  a few changes)