LumenVox hangs up calls if no TTS resources are available

[Nicola Ruggiero]

Hi all,
I have a LumenVox TTS Server for testing with only 1 TTS licence.
I use app_unimrc.so 1.3.0 on Asterisk 11.16 (CentOS 6.6 x86_64)
When I try to make 2 simultaneous calls containig TTS synthesis, the second get hung up:

[2015-02-19 17:02:25] NOTICE[1683][C-00000004]: app_mrcpsynth.c:515 app_synth_exec: MRCPSynth() prompt: State usando il TTS LumenVox su ti di esse claud.net, emme erre ci pi versione 1
[2015-02-19 17:02:25] NOTICE[1683][C-00000004]: app_mrcpsynth.c:533 app_synth_exec: MRCPSynth() options: l=it-IT&p=lumenvox_tdscloud.net-mrcp1
[2015-02-19 17:02:25] ERROR[1441]: app_mrcpsynth.c:217 speech_on_channel_add: (TTS-3) Channel error status=2, response code=0!
[2015-02-19 17:02:25] NOTICE[1683][C-00000004]: app_mrcpsynth.c:472 mrcpsynth_exit: MRCPSynth() exiting status: ERROR on SIP/XXXXX-00000003
  == Spawn extension (LocalSets, 10411, 2) exited non-zero on 'SIP/PC-014-00000003'

Tried the same using Nuance Vocalizer for enterprise and the call remains active thus I can wait until the TTS resouce became newly available.

Is there a way to avoid that LumenVox TTS hangs up my calls if no resources are available?

Thank you very much

[Arsen Chaloyan]

Hi Nicola,

On Thu, Feb 19, 2015 at 8:39 AM, Nicola Ruggiero <nrugg...@gmail.com> wrote:

Hi all,
I have a LumenVox TTS Server for testing with only 1 TTS licence.
I use app_unimrc.so 1.3.0 on Asterisk 11.16 (CentOS 6.6 x86_64)
When I try to make 2 simultaneous calls containig TTS synthesis, the second get hung up:

[2015-02-19 17:02:25] NOTICE[1683][C-00000004]: app_mrcpsynth.c:515 app_synth_exec: MRCPSynth() prompt: State usando il TTS LumenVox su ti di esse claud.net, emme erre ci pi versione 1
[2015-02-19 17:02:25] NOTICE[1683][C-00000004]: app_mrcpsynth.c:533 app_synth_exec: MRCPSynth() options: l=it-IT&p=lumenvox_tdscloud.net-mrcp1
[2015-02-19 17:02:25] ERROR[1441]: app_mrcpsynth.c:217 speech_on_channel_add: (TTS-3) Channel error status=2, response code=0!

If I'm not mistaken, Lumenvox responds with the response code "486 Busy Here" when all licensed channels are in use. Since you got the response code 0, I'd suspect the synthesis terminated prematurely because of an error. If you enabled debug output, I'd be able to tell more.

 

[2015-02-19 17:02:25] NOTICE[1683][C-00000004]: app_mrcpsynth.c:472 mrcpsynth_exit: MRCPSynth() exiting status: ERROR on SIP/XXXXX-00000003
  == Spawn extension (LocalSets, 10411, 2) exited non-zero on 'SIP/PC-014-00000003'

Tried the same using Nuance Vocalizer for enterprise and the call remains active thus I can wait until the TTS resouce became newly available.

Is there a way to avoid that LumenVox TTS hangs up my calls if no resources are available?

No, there is no such an option to reattempt failed sessions. I thought about fail-over redirects/attempts based on specific response codes... can be implemented relatively easily, but haven't reached that point yet.

 

Thank you very much

You are welcome.

--
You received this message because you are subscribed to the Google Groups "UniMRCP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to unimrcp+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Arsen Chaloyan
Author of UniMRCP
http://www.unimrcp.org

[Nicola Ruggiero]

Hi Arsen,

thank very much for the answer.

my comments below:

Il giorno giovedì 19 febbraio 2015 22:05:34 UTC+1, Arsen Chaloyan ha scritto:

Hi Nicola,

On Thu, Feb 19, 2015 at 8:39 AM, Nicola Ruggiero <nrugg...@gmail.com> wrote:

Hi all,
I have a LumenVox TTS Server for testing with only 1 TTS licence.
I use app_unimrc.so 1.3.0 on Asterisk 11.16 (CentOS 6.6 x86_64)
When I try to make 2 simultaneous calls containig TTS synthesis, the second get hung up:

[2015-02-19 17:02:25] NOTICE[1683][C-00000004]: app_mrcpsynth.c:515 app_synth_exec: MRCPSynth() prompt: State usando il TTS LumenVox su ti di esse claud.net, emme erre ci pi versione 1
[2015-02-19 17:02:25] NOTICE[1683][C-00000004]: app_mrcpsynth.c:533 app_synth_exec: MRCPSynth() options: l=it-IT&p=lumenvox_tdscloud.net-mrcp1
[2015-02-19 17:02:25] ERROR[1441]: app_mrcpsynth.c:217 speech_on_channel_add: (TTS-3) Channel error status=2, response code=0!

If I'm not mistaken, Lumenvox responds with the response code "486 Busy Here" when all licensed channels are in use. Since you got the response code 0, I'd suspect the synthesis terminated prematurely because of an error. If you enabled debug output, I'd be able to tell more.

I get this error using MRCPv1 and only on the second call having one license, so it concerns underlicensing, no other error. I saw the error code "486" if I use MRCPv2 profile, same behavior. Anyway, tomorrow I will try enabling debug.

 

 

[2015-02-19 17:02:25] NOTICE[1683][C-00000004]: app_mrcpsynth.c:472 mrcpsynth_exit: MRCPSynth() exiting status: ERROR on SIP/XXXXX-00000003
  == Spawn extension (LocalSets, 10411, 2) exited non-zero on 'SIP/PC-014-00000003'

Tried the same using Nuance Vocalizer for enterprise and the call remains active thus I can wait until the TTS resouce became newly available.

Is there a way to avoid that LumenVox TTS hangs up my calls if no resources are available?

No, there is no such an option to reattempt failed sessions. I thought about fail-over redirects/attempts based on specific response codes... can be implemented relatively easily, but haven't reached that point yet.

 

The problem here is that Nuance TTS server and LumenVox TTS server behave differently... In case of underlicensing Nuance don't produce TTS syntesis nor error, but the call flow continues, so I can take other actions, while LumenVox TTS breaks down calls and this is extremely serious!!!

Any ideas?

[Arsen Chaloyan]

Hi Nicola,

On Thu, Feb 19, 2015 at 4:11 PM, Nicola Ruggiero <nrugg...@gmail.com> wrote:

Hi Arsen,

thank very much for the answer.

my comments below:

Il giorno giovedì 19 febbraio 2015 22:05:34 UTC+1, Arsen Chaloyan ha scritto:

Hi Nicola,

On Thu, Feb 19, 2015 at 8:39 AM, Nicola Ruggiero <nrugg...@gmail.com> wrote:

Hi all,
I have a LumenVox TTS Server for testing with only 1 TTS licence.
I use app_unimrc.so 1.3.0 on Asterisk 11.16 (CentOS 6.6 x86_64)
When I try to make 2 simultaneous calls containig TTS synthesis, the second get hung up:

[2015-02-19 17:02:25] NOTICE[1683][C-00000004]: app_mrcpsynth.c:515 app_synth_exec: MRCPSynth() prompt: State usando il TTS LumenVox su ti di esse claud.net, emme erre ci pi versione 1
[2015-02-19 17:02:25] NOTICE[1683][C-00000004]: app_mrcpsynth.c:533 app_synth_exec: MRCPSynth() options: l=it-IT&p=lumenvox_tdscloud.net-mrcp1
[2015-02-19 17:02:25] ERROR[1441]: app_mrcpsynth.c:217 speech_on_channel_add: (TTS-3) Channel error status=2, response code=0!

If I'm not mistaken, Lumenvox responds with the response code "486 Busy Here" when all licensed channels are in use. Since you got the response code 0, I'd suspect the synthesis terminated prematurely because of an error. If you enabled debug output, I'd be able to tell more.

I get this error using MRCPv1 and only on the second call having one license, so it concerns underlicensing, no other error. I saw the error code "486" if I use MRCPv2 profile, same behavior. Anyway, tomorrow I will try enabling debug.

Oh, well. Being mostly focused on MRCPv2, I tend to overlook MRCPv1 issues. It turns out the response code was not propagated from the RTSP client to the core (fixed it in r2277). It won't make any difference in your case, but help output a proper response code in the logs.

Noticed a tiny issue in the LumenVox 486 responses, which actually contain a body without having content-type specified. Not sure providing an SDP message in 4xx responses is reasonable, but if it is present, then the content-type must also be specified.

 

 

 

[2015-02-19 17:02:25] NOTICE[1683][C-00000004]: app_mrcpsynth.c:472 mrcpsynth_exit: MRCPSynth() exiting status: ERROR on SIP/XXXXX-00000003
  == Spawn extension (LocalSets, 10411, 2) exited non-zero on 'SIP/PC-014-00000003'

Tried the same using Nuance Vocalizer for enterprise and the call remains active thus I can wait until the TTS resouce became newly available.

Is there a way to avoid that LumenVox TTS hangs up my calls if no resources are available?

No, there is no such an option to reattempt failed sessions. I thought about fail-over redirects/attempts based on specific response codes... can be implemented relatively easily, but haven't reached that point yet.

 

The problem here is that Nuance TTS server and LumenVox TTS server behave differently... In case of underlicensing Nuance don't produce TTS syntesis nor error, but the call flow continues, so I can take other actions, while LumenVox TTS breaks down calls and this is extremely serious!!!

Any ideas?

I understood your point. You probably will not be able to alter the server behavior with this regard. What you could do is to attempt initiating a new session based on the status variable set in speech_on_channel_add(), if you are comfortable changing the code, of course.

https://code.google.com/p/unimrcp/source/browse/solutions/asterisk-unimrcp/app-unimrcp/app_mrcpsynth.c#185

 

Thank you very much

You are welcome.

--
You received this message because you are subscribed to the Google Groups "UniMRCP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to unimrcp+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Arsen Chaloyan
Author of UniMRCP
http://www.unimrcp.org

--
You received this message because you are subscribed to the Google Groups "UniMRCP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to unimrcp+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Michele Cipolletti]

Good morning,
unfortunately I have the same problem... so I'm interested on the possible solutions.

First of all, it is absurd that LumenVox CRASHES in this case, instead of return a CHANNEL ERROR or some other error messages!!!

However, about your suggestion to test the value of some variable set in speech_on_channel_add()... I can't read and test a variable AFTER calling MRCPSynth app because this function cause the crash and any further dialplan instructions are skipped.

Is there a specific variable I can test BEFORE calling MRCPSynth app?

Thanks in advance.
Best regards,
Michele

[Arsen Chaloyan]

Hi Michele,

On Mon, Feb 23, 2015 at 1:11 AM, Michele Cipolletti <michele.c...@gmail.com> wrote:

Good morning,
unfortunately I have the same problem... so I'm interested on the possible solutions.

First of all, it is absurd that LumenVox CRASHES in this case, instead of return a CHANNEL ERROR or some other error messages!!!

I'd be more cautious about the statements. What do you mean by crash? None of the components crashes in this case. Instead, in case of a failure in session initialization, the application MRCPSynth() returns an error to the Asterisk core, which in turn terminates the dialplan execution.

Is this behavior logical or not? There was a similar discussion a few months ago, where I stated that the application function should ideally return an error to Asterisk in case of severe conditions only; for all other cases, a normal execution should follow having the STATUS variable set. Sooner or later this behavior will be changed, but it is currently not a priority for me. I hope someone from the community can do that, it's nearly a trivial change.

Anyway, you can have a total control of your application call flow even now by using AGI/AMI instead of dialplan.

 

However, about your suggestion to test the value of some variable set in speech_on_channel_add()... I can't read and test a variable AFTER calling MRCPSynth app because this function cause the crash and any further dialplan instructions are skipped.

It seems you got me wrong. I meant implementing the requested functionality in the C code instead of Asterisk diaplan and probably contributing it back to the project in terms of an easy-to-apply patch. But who thinks that way? Hm...
 

Is there a specific variable I can test BEFORE calling MRCPSynth app?

No. Perhaps now, having a better understanding of what is going on underneath, you can solve your problem.

[Michele Cipolletti]

Hi Arsen,

I would explain that I say "crash" because an exception, somewhere, cause my dialplan exit with error. That's all.  :)

So, I understand that the solution could be to fix this behavior in the specific function causing the exception (speech_on_channel_add() or another one).

Maybe this could be done adding a few lines of code... write C code is not a problem, but unfortunately at the moment I have to understand where and how.

Your suggestion (try AGI/AMI instead of dialplan to have total control of this behavior) could be an instant solution! I can try this "workaround" right now.

Thank you for your support.

Best regards,

Michele

--
You received this message because you are subscribed to a topic in the Google Groups "UniMRCP" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/unimrcp/Se4BmS3-XN8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to unimrcp+u...@googlegroups.com.

[Nicola Ruggiero]

Hi Arsen,

Thank you very much for you help.

Since there is a SINTHSTATUS variable, I don't understand why, in case of error, it isn't valorized as "ERROR" instead of hanging up the line!

Maybe you can help people making this trivial change to the code to get things work! :-) and continue use MRCPSynt inside dialplan instead of calling external AGI scripts to catch exceptions, which (IMHO) is not the best way...

Thank you very much,

Nicola

[Arsen Chaloyan]

Hi Nicola, Michele,

I value very much suggestions and feedback coming from you and other users. While the requested change might be trivial and also commonsensical, if we add up similar requests, believe it or not, the result will equal in many months of development. Having said, each particular case seems easy, but this approach cannot be generalized. Not to mention that maintaining the project for quite a long time and continuously helping its users, I don't seem to be heard when I call for support. People tend to misuse and misinterpret the concept behind the open source development. Please don't get it personally, but here are the options I see in general:

Option 1

If you have the time and passion, try to dig into the source code and implement the change by yourself. You may rely on my assistance.

Option 2

If you want me to implement the change, this would qualify for a 2-hour incident-based support.

http://unimrcp.org/ecosystem/commercial-support

Option 3

Become a member, support UniMRCP, gain access to additional resources. In return, I'd also be glad to implement this change for you.

http://unimrcp.org/ecosystem/membership

Thanks for your understanding!

[Nicola Ruggiero]

Hi Arsen,

I really appreciate your efforts to develop and maintain this project and do understand and agree with the Open Source philosophy.

I spoke with LumenVox technical support trying to understand more about this issue.

What do I understood is that, when no more TTS licences are available, the LumneVox Server answeres with an error (code=486!) message that is slighly different from what you aspect, so MRCPSynth can't handle this exception and hangs up the line. Is that correct?

--------------------------------------------------------------------------------------------------------------

[2015-02-25 14:43:11] ERROR[20600]: app_mrcpsynth.c:217 speech_on_channel_add: (TTS-3) Channel error status=2, response code=486!

[2015-02-25 14:43:11] NOTICE[20600]: src/mrcp_client_session.c:387 : Receive App Request TTS-3 <new> [1]

[2015-02-25 14:43:11] NOTICE[20600]: src/mrcp_client_session.c:833 : Terminate Session TTS-3 <new>

[2015-02-25 14:43:11] NOTICE[20600]: src/mrcp_client_session.c:209 : Session Terminated TTS-3 <new>

[2015-02-25 14:43:11] NOTICE[20600]: src/mrcp_client.c:710 : Remove MRCP Handle TTS-3 <new>

[2015-02-25 14:43:11] NOTICE[20600]: src/mrcp_client_session.c:455 : Raise App Response TTS-3 <new> [1] SUCCESS [0]

[2015-02-25 14:43:11] NOTICE[20600]: src/mrcp_application.c:182 : Destroy MRCP Handle TTS-3

[2015-02-25 14:43:11] NOTICE[564][C-00000cb7]: app_mrcpsynth.c:472 mrcpsynth_exit: MRCPSynth() exiting status: ERROR on SIP/XXX-00000036

  == Spawn extension (LocalSets, 10412, 2) exited non-zero on 'SIP/XXX-00000036'

[2015-02-25 14:43:13] NOTICE[20601]: src/mrcp_client_connection.c:635 : Receive MRCPv2 Data X.X.X.X:40053 <-> X.X.X.X:20022 [162 bytes]

MRCP/2.0 162 SPEAK-COMPLETE 1 COMPLETE

Channel-Identifier: c097ad5c-1702-46af-b@speechsynth

Completion-Cause: 000 normal

Speech-Marker: timestamp=131197865

--------------------------------------------------------------------------------------------------------------

So, IMHO it looks like a coommunication protocol error or misunderstanding or misconfiguration beetwenn MRCPSynt and LumenVox Server.

Who and how, in your opinion, should fix this issue?

- LumenVox should change the error message to be compliant with your communication protocol?

- MRCPSynt shoud be so clever to not hang up calls in case of unhandled exceptions?

- Both of the above statements are correct?

- None?

I'm asking you that, because both you and LumenVox are asking me to pay for fixing this, so now I have to decide which is the best way to get things work!

I hope you will understand my point of view...

Best regards,

Nicola

[Arsen Chaloyan]

Hi Nicola,

No worries, I am open to continue the discussion. So, please see my comments below.

On Wed, Feb 25, 2015 at 6:08 AM, Nicola Ruggiero <nrugg...@gmail.com> wrote:

Hi Arsen,

I really appreciate your efforts to develop and maintain this project and do understand and agree with the Open Source philosophy.

I spoke with LumenVox technical support trying to understand more about this issue.

What do I understood is that, when no more TTS licences are available, the LumneVox Server answeres with an error (code=486!) message that is slighly different from what you aspect, so MRCPSynth can't handle this exception and hangs up the line. Is that correct?

In case of any 4xx errors, including 486 one, as well as other errors in session/channel initialization, MRCPSynth returns -1 to the Asterisk core, which results in call termination.

 

--------------------------------------------------------------------------------------------------------------

[2015-02-25 14:43:11] ERROR[20600]: app_mrcpsynth.c:217 speech_on_channel_add: (TTS-3) Channel error status=2, response code=486!

[2015-02-25 14:43:11] NOTICE[20600]: src/mrcp_client_session.c:387 : Receive App Request TTS-3 <new> [1]

[2015-02-25 14:43:11] NOTICE[20600]: src/mrcp_client_session.c:833 : Terminate Session TTS-3 <new>

[2015-02-25 14:43:11] NOTICE[20600]: src/mrcp_client_session.c:209 : Session Terminated TTS-3 <new>

[2015-02-25 14:43:11] NOTICE[20600]: src/mrcp_client.c:710 : Remove MRCP Handle TTS-3 <new>

[2015-02-25 14:43:11] NOTICE[20600]: src/mrcp_client_session.c:455 : Raise App Response TTS-3 <new> [1] SUCCESS [0]

[2015-02-25 14:43:11] NOTICE[20600]: src/mrcp_application.c:182 : Destroy MRCP Handle TTS-3

[2015-02-25 14:43:11] NOTICE[564][C-00000cb7]: app_mrcpsynth.c:472 mrcpsynth_exit: MRCPSynth() exiting status: ERROR on SIP/XXX-00000036

  == Spawn extension (LocalSets, 10412, 2) exited non-zero on 'SIP/XXX-00000036'

[2015-02-25 14:43:13] NOTICE[20601]: src/mrcp_client_connection.c:635 : Receive MRCPv2 Data X.X.X.X:40053 <-> X.X.X.X:20022 [162 bytes]

MRCP/2.0 162 SPEAK-COMPLETE 1 COMPLETE

Channel-Identifier: c097ad5c-1702-46af-b@speechsynth

Completion-Cause: 000 normal

Speech-Marker: timestamp=131197865

--------------------------------------------------------------------------------------------------------------

So, IMHO it looks like a coommunication protocol error or misunderstanding or misconfiguration beetwenn MRCPSynt and LumenVox Server.

I really don't think so.

 

Who and how, in your opinion, should fix this issue?

- LumenVox should change the error message to be compliant with your communication protocol?

No, what LumenVox could do is not to return error but wait for a channel to be available. In this case, no changes would be required in MRCPSynth.

 

- MRCPSynt shoud be so clever to not hang up calls in case of unhandled exceptions?

Yes, MRCPSynth could be clever enough to either

1) re-initiate call setup in case of 4xx errors. This is the approach I initially suggested to you.

and/or

2) not to return -1 to Asterisk in case of 4xx errors, which would allow you and other users to handle this sort of errors appropriately in the dialplan and continue operation thereafter. This is the change I quoted you in my previous mail.

 

- Both of the above statements are correct?

- None?

Partly yes and no.

I'm asking you that, because both you and LumenVox are asking me to pay for fixing this, so now I have to decide which is the best way to get things work!

I hope you will understand my point of view...

Sure, no problem. Let me know if you need further clarifications.

[Michele Cipolletti]

Hi Arsen,

following your last suggestion I have modified function mrcpsynth_exit() in this way:

Before: return status != SPEECH_CHANNEL_STATUS_ERROR ? 0 : -1;

After: return 0;

This avoid MRCPSynth app exits returning -1, causing the Spawn extension... isn't it?

First tests, after rebuild, seem to confirm this new scenario. It sounds good!

Unfortunatly, I ignore at the moment the possible side-effects... I hope it will continue working as well as before... :)

Thank you so much for your support.

Best regards,

Michele

--
You received this message because you are subscribed to a topic in the Google Groups "UniMRCP" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/unimrcp/Se4BmS3-XN8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to unimrcp+u...@googlegroups.com.