implement UniMRCP server with avaya EP

[Waiting Wu]

Hi,

I use UniMRCP 1.5.0 and KaldiSR plugin 1.1.0 for avaya EP.

ASR is work now. 

But every calls will hangout around 30 seconds.

And I found the SIP error log in the MRCP server logs.

2018-05-30 18:16:21:375522 [INFO]   Receive SIP Event [nua_i_error] Status 408 ACK Timeout [SIP-Agent-1]

2018-05-30 18:16:21:376417 [INFO]   Receive SIP Event [nua_i_state] Status 0 ACK Timeout [SIP-Agent-1]

2018-05-30 18:16:21:376486 [NOTICE] SIP Call State 0x7fe754001a18 [terminating]

What's happen with these logs?

[Arsen Chaloyan]

Hi Waiting,

This is a known interop issue with Avaya. A few months ago, I was involved in investigation of such an issue with Verizon and Avaya's support team. So, too keep it short, here is the conclusion:

Option 1

Use UDP for SIP transport. This needs to be changed from the configuration of Avaya. UniMRCP server accepts both TCP and UDP connections by default.

 

Option 2

Leave only TCP in the configuration of UniMRCP server.

 

      <sip-transport>tcp</sip-transport>

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

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

[Waiting Wu]

HI Arsen Chaloyan,

I appreciate your message.

In fact I already leave only TCP in the configure for UniMRCP.

I reference the log from avaya and I found something strange.

2018-05-31 16:41:17.857273 recv 967 bytes from tcp/[10.134.162.76]:31004
INVITE sip:mres...@10.134.130.5 SIP/2.0
From: sip:mpp@epmqc;tag=22d2f5181c63e812110086a4ca2
To: sip:mres...@10.134.130.5
Call-ID: 36d2f5181c63e812210086a4ca2
CSeq: 1 INVITE
Max-Forwards: 70
Via: SIP/2.0/TCP 10.134.162.76:8061;branch=z9hG4bK64dbf5181c63e812310086a4ca2
User-Agent: Avaya-VoicePortal/7.1.0.1.0006
Supported: 100rel, timer, replaces, join, histinfo
Allow: INVITE, CANCEL, BYE, ACK, PRACK, SUBSCRIBE, NOTIFY, REFER, OPTIONS, INFO, PUBLISH, UPDATE
Contact: <sip:10.134.162.76:8061;transport=tcp>
Session-Expires: 1200;refresher=uac
Min-SE: 1200
Content-Type: application/sdp
Content-Length: 340
v=0
o=- 1 1 IN IP4 10.134.162.76
s=-
t=0 0
m=audio 11022 RTP/AVP 18 0 8 127
c=IN IP4 10.134.162.76
a=rtpmap:18 G729/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:127 telephone-event/8000
a=sendonly
m=application 9 TCP/MRCPv2 1
c=IN IP4 10.134.130.5
a=setup:active
a=connection:new
a=cmid:1
a=resource:speechrecog

I got this INVITE from avaya via TCP.

2018-05-31 16:41:17.876950 recv 355 bytes from tcp/[10.134.162.76]:31004
ACK sip:10.134.130.5:8061 SIP/2.0
From: <sip:mpp@epmqc>;tag=22d2f5181c63e812110086a4ca2
To: <sip:mres...@10.134.130.5>;tag=F8g95e29BU96N
Call-ID: 36d2f5181c63e812210086a4ca2
CSeq: 1 ACK
Max-Forwards: 70
Via: SIP/2.0/UDP 10.134.162.76:8061;branch=z9hG4bK5ae7f8181c63e812410086a4ca2
User-Agent: Avaya-VoicePortal/7.1.0.1.0006
Content-Length: 0

But I could not take this ACK from avaya via UDP.

I think this is the root cause of "ACK Timeout".

Is it possible use TCP and UDP in same time?

Arsen Chaloyan於 2018年6月1日星期五 UTC+8上午8時47分23秒寫道：

Hi Waiting,

This is a known interop issue with Avaya. A few months ago, I was involved in investigation of such an issue with Verizon and Avaya's support team. So, too keep it short, here is the conclusion:

Option 1

Use UDP for SIP transport. This needs to be changed from the configuration of Avaya. UniMRCP server accepts both TCP and UDP connections by default.

 

Option 2

Leave only TCP in the configuration of UniMRCP server.

 

      <sip-transport>tcp</sip-transport>

On Wed, May 30, 2018 at 9:03 PM, Waiting Wu <nick321...@gmail.com> wrote:

Hi,

I use UniMRCP 1.5.0 and KaldiSR plugin 1.1.0 for avaya EP.

ASR is work now. 

But every calls will hangout around 30 seconds.

And I found the SIP error log in the MRCP server logs.

2018-05-30 18:16:21:375522 [INFO]   Receive SIP Event [nua_i_error] Status 408 ACK Timeout [SIP-Agent-1]

2018-05-30 18:16:21:376417 [INFO]   Receive SIP Event [nua_i_state] Status 0 ACK Timeout [SIP-Agent-1]

2018-05-30 18:16:21:376486 [NOTICE] SIP Call State 0x7fe754001a18 [terminating]

What's happen with these logs?

--
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.

[Waiting Wu]

Hi Arsen Chaloyan,

Sorry I have to update the message.

I can got the ACK in sofia-sip-uas.log.

But still ACK Timeout.

Waiting Wu於 2018年6月1日星期五 UTC+8上午10時29分10秒寫道：

[Waiting Wu]

Hi Arsen Chaloyan,

I found the discuss topic https://groups.google.com/forum/#!topic/unimrcp/wmA5meumXfk
That exactly what my face on to now.

I modified the unimrcpserver.xml, leave only TCP in the configuration.

But it's still got "ACK timeout".


Waiting Wu於 2018年6月1日星期五 UTC+8上午10時35分29秒寫道：

[Arsen Chaloyan]

This is the exact problem I was referring to. It is confirmed from various places (including Avaya's representatives themselves) that by setting SIP transport to TCP only in unimrcpserver.xml helps resolve the problem.

Have you restarted the server after making the configuration change.

To unsubscribe from this group and stop receiving emails from it, send an email to unimrcp+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Waiting Wu]

Hi Arsen Chaloyan,

Yes, I restarted the server after the configuration change.

I upload the entire logs for more detail information.

2018-05-31 15:55:57:956997 [NOTICE] Create SofiaSIP Agent [SIP-Agent-1] [1.12.11-234-gd74df2e] sip:172.20.0.95:8061;transport=tcp

It's only tcp for transport.

And receive the SIP event,

2018-05-31 15:56:21:281541 [INFO]   Receive SIP Event [nua_i_invite] Status 100 Trying [SIP-Agent-1]

2018-05-31 15:56:21:281604 [INFO]   Receive SIP Event [nua_i_state] Status 100 Trying [SIP-Agent-1]

But no  nua_i_ack event till 

2018-05-31 15:56:53:288817 [INFO]   Receive SIP Event [nua_i_error] Status 408 ACK Timeout [SIP-Agent-1]

Arsen Chaloyan於 2018年6月7日星期四 UTC+8上午8時28分49秒寫道：

This is the exact problem I was referring to. It is confirmed from various places (including Avaya's representatives themselves) that by setting SIP transport to TCP only in unimrcpserver.xml helps resolve the problem.

Have you restarted the server after making the configuration change.

On Fri, Jun 1, 2018 at 12:57 AM, Waiting Wu <nick321...@gmail.com> wrote:

Hi Arsen Chaloyan,

I found the discuss topic https://groups.google.com/forum/#!topic/unimrcp/wmA5meumXfk
That exactly what my face on to now.

I modified the unimrcpserver.xml, leave only TCP in the configuration.

But it's still got "ACK timeout".


Waiting Wu於 2018年6月1日星期五 UTC+8上午10時35分29秒寫道：

Hi Arsen Chaloyan,

Sorry I have to update the message.

I can got the ACK in sofia-sip-uas.log.

But still ACK Timeout.

Waiting Wu於 2018年6月1日星期五 UTC+8上午10時29分10秒寫道：

HI Arsen Chaloyan,

I appreciate your message.

In fact I already leave only TCP in the configure for UniMRCP.

I reference the log from avaya and I found something strange.

2018-05-31 16:41:17.857273 recv 967 bytes from tcp/[10.134.162.76]:31004

INVITE sip:mr...@10.134.130.5 SIP/2.0
From: sip:mpp@epmqc;tag=22d2f5181c63e812110086a4ca2
To: sip:mr...@10.134.130.5

To: <sip:mr...@10.134.130.5>;tag=F8g95e29BU96N

[Arsen Chaloyan]

I double checked the Sofia-SIP logs that you provided. The response from UniMRCP server does NOT contain TCP attribute in the Contact header field, as it should, if you indeed set the transport to TCP only. It is very obvious.

Here is the INVITE from Avaya

2018-05-31 16:45:14.408520 recv 966 bytes from tcp/[10.134.162.76]:31004
INVITE sip:mres...@10.134.130.5 SIP/2.0
From: sip:mpp@epmqc;tag=7619f5a51c63e819910086a4ca2
To: sip:mres...@10.134.130.5
Call-ID: 8a19f5a51c63e819a10086a4ca2

CSeq: 1 INVITE
Max-Forwards: 70

Via: SIP/2.0/TCP 10.134.162.76:8061;branch=z9hG4bKe22f5a51c63e819b10086a4ca2

User-Agent: Avaya-VoicePortal/7.1.0.1.0006
Supported: 100rel, timer, replaces, join, histinfo
Allow: INVITE, CANCEL, BYE, ACK, PRACK, SUBSCRIBE, NOTIFY, REFER, OPTIONS, INFO, PUBLISH, UPDATE
Contact: <sip:10.134.162.76:8061;transport=tcp>

SIP OK from UniMRCP server

2018-05-31 16:45:14.417918 sent 971 bytes to tcp/[10.134.162.76]:31004
SIP/2.0 200 OK
Via: SIP/2.0/TCP 10.134.162.76:8061;branch=z9hG4bKe22f5a51c63e819b10086a4ca2;rport=31004
From: <sip:mpp@epmqc>;tag=7619f5a51c63e819910086a4ca2
To: <sip:mres...@10.134.130.5>;tag=yFcX04yy00QZK
Call-ID: 8a19f5a51c63e819a10086a4ca2
CSeq: 1 INVITE
Contact: <sip:10.134.130.5:8061>
User-Agent: EmotibotSIP 1.5.0

Instead of

Contact: <sip:10.134.130.5:8061>

there should have been

Contact: <sip:10.134.130.5:8061;transport=tcp>

This is so obvious and works as intended, if you set the transport to TCP only, unless you are using your own/locally modified version of UniMRCP server.

Here comes the problem. Avaya sent SIP ACK over TCP setting UDP in the VIA header. This is wrong, but workaround is clear.

2018-05-31 16:45:14.424595 recv 355 bytes from tcp/[10.134.162.76]:31004

ACK sip:10.134.130.5:8061 SIP/2.0

From: <sip:mpp@epmqc>;tag=7619f5a51c63e819910086a4ca2
To: <sip:mres...@10.134.130.5>;tag=yFcX04yy00QZK
Call-ID: 8a19f5a51c63e819a10086a4ca2

CSeq: 1 ACK
Max-Forwards: 70

Via: SIP/2.0/UDP 10.134.162.76:8061;branch=z9hG4bK429bf7a51c63e819c10086a4ca2
User-Agent: Avaya-VoicePortal/7.1.0.1.0006
Content-Length: 0

As a result, Sofia-SIP drops this message, and does it right, as Avaya clearly violates SIP spec 

http://tools.ietf.org/html/rfc3261#section-17.1.1.3

The ACK MUST contain a single Via header field, and this MUST be equal to the top Via header field of the original request.

There is nothing more to say, and the situation is very clear. Please carefully follow the responses you were given so far.

To unsubscribe from this group and stop receiving emails from it, send an email to unimrcp+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Tomasz Jadczyk]

Hi Arsen,

we're currently using some kind of workaround for this ACK timeout problem.

In unimrcpserver.xml we set <sip-t1x64> (components/sip-uas section) to quite large value (10 hours or so) and ... it works, but could you tell me - are there any drawbacks in this workaroud ? Waiting threads in background or some other resource-consuming components?

Thanks in advance,
Tomasz

W dniu piątek, 1 czerwca 2018 02:47:23 UTC+2 użytkownik Arsen Chaloyan napisał:
> Hi Waiting,
>
>
> This is a known interop issue with Avaya. A few months ago, I was involved in investigation of such an issue with Verizon and Avaya's support team. So, too keep it short, here is the conclusion:
>
>
>
>
>
>
> Option 1
>
>
>
>
>
>
> Use
> UDP for SIP transport. This needs to be changed from the configuration
> of Avaya. UniMRCP server accepts both TCP and UDP connections by
> default.
>
>
>
>
>  
>
>
>
>
>
>
>
>
>
>
>
>
> Option 2
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Leave only TCP in the configuration of UniMRCP server.
>
>
>
>
>  
>
>
>
>
>       <sip-transport>tcp</sip-transport>
>
>
>
>
>
> On Wed, May 30, 2018 at 9:03 PM, Waiting Wu <nick321...@gmail.com> wrote:
>
>
> Hi,
>
>
> I use UniMRCP 1.5.0 and KaldiSR plugin 1.1.0 for avaya EP.
>
> ASR is work now. 
>
>
> But every calls will hangout around 30 seconds.
>
> And I found the SIP error log in the MRCP server logs.
>
>
> 2018-05-30 18:16:21:375522 [INFO]   Receive SIP Event [nua_i_error] Status 408 ACK Timeout [SIP-Agent-1]
> 2018-05-30 18:16:21:376417 [INFO]   Receive SIP Event [nua_i_state] Status 0 ACK Timeout [SIP-Agent-1]
> 2018-05-30 18:16:21:376486 [NOTICE] SIP Call State 0x7fe754001a18 [terminating]
>
>
> What's happen with these logs?
>
>
>
>
> --
>
> 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.

[Arsen Chaloyan]

Hi Tomasz,

By setting a large timeout, both the MRCP and RTP layers would be fully functional and do not seem affected. On the other side, this is quite misleading, as the SIP dialog will remain incomplete. Any modification in the SIP session, such as re-INVITE, Session Timers, will fail, not to mention SIP session termination. The client would assume that the session is normally established and will send a regular SIP BYE. However, the server will respond to the incoming SIP BYE with an error and will not terminate the session, until your specified timeout is reached. I am not quite sure about the latter, this needs to be tested explicitly. But anyway, if we are talking about a workaround for the missing SIP ACK, then I would probably use this option last.

To unsubscribe from this group and stop receiving emails from it, send an email to unimrcp+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Rehman Aamir]

Hi,

I saw your post, I have installed the same unimrcp and Kalsi, everything looks good on unimrcp and Kalsi side, I see that messages are coming from Avaya aaep 7.2 to Kalsi but aaep is still unable to reach to speech server, I. Wondering if you have document instructions to configure Kalsi setting on aaep side that would be great.

Regards
Aamir