innovaphone Apps SDK Developer Forum

Registered 4 years 74 days

Richard 5560 Monday, 6 September 2021, 05:23 AM

WebSocket API: Inconsistent RCC events

Hi guys,

We had received the following events from the RCC api on a customers site which do not appear to be correct. We do not know the exact calls scenario

The last message (at 11:18:37.10) in the attached trace appears inconsistent.

The state of 132 (or 4) corresponds with Alerting (Offering) as seen from the preceeding message.

The state of 135 (or 7) corresponds with disconnect, so a CallInfo event with "state"=132 and "msg"="del" is inconsistent.

Can you please advise if this is an issue the events the RCC Api is providing and what information is required to resolve it if it is?

Kind Regards

Richard

RCCtrace.txt

Moderator

Registered 13 years 260 days

Andreas Fink (innovaphone) Monday, 6 September 2021, 12:03 PM

Re: WebSocket API: Inconsistent RCC events

Hello Richard,

it seems to me, the call scenario was following:

a call was signalled with: "state": 129 (setup, outbound call), r-setup (received setup)
the call was disconnected almost immediately: "state": 134 (disconnect sent, outbound call), r-rel (received release)
we send out an alert (phone starts to ring, since do not have any info about disconnect yet), but it is too late: "state": 132 (alert, outbound call), x-alert (transmitted alert)

This is just a timing issue you will see on such distributed systems all the time, and you have to deal with this somehow.

In this case it could be an unregistered VoIP endpoint.

The PBX just translates the events from VoIP signalling to RCC API.

Best Regards

Andreas Fink

Registered 4 years 74 days

Richard 5560 Tuesday, 7 September 2021, 02:37 AM

Re: WebSocket API: Inconsistent RCC events

Hi Andreas,

Thank you for the review.

It's the last message i am specifically querying.

11:18:37.10

"mt": "CallInfo",

"user": 6,

"call": 18,

"conf": null,

"state": 132,

"peer": { redacted

"msg": "del",

"api": "RCC",

What specifically does "msg" = "del" refer to?

looking at other calls, it correlates mostly to a state of 6/134 or 7/135, but in this case the state is 132 (alerting), and the logs also have a state 5 (Connected).

Like the sample code, our implementation relies on the state value to determine what the CallInfo event is. But by relying on the state alone we appear that we will misinterpret events.

Can you please advise.

Kind Regards

Richard

Moderator

Registered 13 years 260 days

Andreas Fink (innovaphone) Tuesday, 7 September 2021, 12:40 PM

Re: WebSocket API: Inconsistent RCC events

Hello Richard,

this message is not a real "on-wire" signalling message like call-setup or call-release, it is an internal RCC message of the API, providing an info that the call was deleted from the PBX.

In your special case in the initial post the call was terminated just in the alerting state. This is the reason, you see alerting state until the "end" message - it was the last state this call was in, before it was terminated.

Important to understand- there was no "call release" message, the call was terminated probably due signalling issues on VoIP path, so the last VoIP message PBX got on this call must be alerting. This state remains until the call is deleted.

Do you see this scenario often?

Best Regards

Andreas Fink

Registered 4 years 74 days

Richard 5560 Wednesday, 8 September 2021, 05:49 AM

Re: WebSocket API: Inconsistent RCC events

Hi Andreas,

How do we determine this is not a real signaling message?

The only difference appears to be the "msg" = "del".

Are we recommended to

a) check the msg and ignore the state if msg = del

b) ignore any events (eg X-alert) after r-rel on an extension?

this is the only example provided to us by the customer, but they could be having more they haven't told us about

Kind Regards

Richard,

Moderator

Registered 13 years 260 days

Andreas Fink (innovaphone) Thursday, 9 September 2021, 05:50 PM

Re: WebSocket API: Inconsistent RCC events

Hello Richard,

> How do we determine this is not a real signaling message?

There are only few signalling messages, based on H.225 or Q.931 that you will see on RCC API. The del message is not a part of H.225 and is probably the only message not related to a real signalling.

> Are we recommended to

> a) check the msg and ignore the state if msg = del

It depends on what your application does with the call data.

In case the application only lists active or ringing calls, you can just remove this call from a list, as soon you see any call release or del.

You can ignore the state, if the call is deleted anyway. Exception is, you have to write down the state changes for some reason (e.g. to have statistics for calls ended by agent or customer)

A possible approach is to monitor only the state changes in the CallInfo messages and perform actions according to a state machine you build depending on your application.

b) Yes, an alert after release is no longer relevant and makes no sense in this case.

Best Regards

Andreas Fink

Registered 4 years 74 days

Richard 5560 Friday, 10 September 2021, 05:54 AM

Re: WebSocket API: Inconsistent RCC events

Thank you Andreas, we will look to make the changes you recommend.

You are here