Integration with avaya voice portal

[firstmah...@gmail.com]

dear arsen
iam working these days in Integration with avaya voice portal. im
trying to integrate unimrcp server version one with my tts plugin and
avaya mrcp client. the problem is that the client send only start
session request then speak request and no end session request is sent.
after amount of time the end session request is sent.i want to control
the end session process regardless of the time out do you know how to
handle this?avaya does not send end session unless time out is occured.

[Arsen Chaloyan]

Hi Mahmoud,

On Wed, May 20, 2009 at 6:59 PM, firstmah...@gmail.com <firstmah...@gmail.com> wrote:

dear arsen
iam working these days in Integration with avaya voice portal. im
trying to integrate unimrcp server version one with my tts plugin and
avaya mrcp client.

Great.

the problem is that the client send only start
session request then speak request and no end session request is sent.
after amount of time the end session request is sent.i want to control
the end session process regardless of the time out do you know how to
handle this?avaya does not send end session unless time out is occured.

I'm not sure I understand you right.
Did you mean the following scenario
1. C->S: RTSP SETUP
2. S->C: RTSP OK
3. C->S: RTSP ANNOUNCE SPEAK
4. S->C: RTSP ANNOUNCE IN-PROGRESS
5. S->C: RTSP ANNOUNCE SPEAK-COMPLETE
6. C->S: RTSP TEARDOWN
7. S->C: RTSP OK

Is it what you described. Did you send SPEAK-COMPLETE event?
Regards,
Arsen.

[mahmoud hassan]

dear arsen,
yes i sent speak complete event but the client did not send tear down request after it finish speaking and receive speak complete event it wait for a period and then send the tear down request. i want to know how to handle the tear down or is it not needed to send tear down request from the client? 

[Arsen Chaloyan]

Hi Mahmoud,
Actually client has not to send TERADOWN as soon as it receives SPEAK-COMPLETE. It's based on actual scenario executed from Avaya portal and probably user interaction as well. Perhaps there is nothing wrong, I guess, at least it's not under the influence of MRCP server at all.

Regards,
Arsen.

[mahmoud hassan]

arsen
i know that there is no problem in the server at all as when it receives tear down it respond correctly.the problem is that the client does not send tear down after the secnario is finished it do this after a time out period elapsed or something like this. this late in sending tear down produces a problem for my tts engine as i used to create a TTS channel  when a session is created and release the TTS channel when a session is destroyed so when the user create session and dont release it the TTS channel is allocated for this session although it is no longer being used.
consider this case which may cause the system not to work effecienttly:
we have a TTS engine that can support only 10 concurrent channels at the same time.then the mrcp client asks the server to create 10 sessions and for each session created the tts engine intializes channel for it so all TTS channels are now busy serving the 10 customers.consider now that one customer end his call but does  not send tear down request and another customer make a call at this time it will not be handled because all TTS channels are busy. it will be handled when time out elabsed for the customer that end his call so this is a weak point in the system. the issue is that the client does not send tear down unless a time out elapsed and this cause the problem i stated above :) do you have any suggestions concerning this issue?
sory for disturbance and thanks 4 ur time

mahmoud

[Arsen Chaloyan]

Mahmoud,
Your concerns are very clear now, and I see no good reason why Avaya shouldn't tear down MRCP session, as soon as caller hangs up the call. Unfortunately I have no clue at the moment, as I've never used that platform so far. Hopefully other users who did it, can help you out.

Regards,
Arsen.

[garmt]

Hi Mahmoud,

Two weeks ago I tested unimrcp with my plugin with an Avaya Voice
Portal.
I cannot remember seeing the same issue that you report, but then
again I may not have noticed (I was already happy it worked).
Unfortunately, I did not save any traces, so I cannot see if we had
the same problem.
(By the way - thanks Arsen for adding the "plugin logging" feature, so
next time I will have a trace....)

I guess the obvious thing to do is to already close and destroy your
TTS channel once your TTS engine is ready generating speech.
At least you solved your TTS engine's resource problem.
The fact that you have unimrcp channels and sessions that linger is
perhaps less problematic, as you pointed out that the tear down will
arrive.

I will try and get some of the traces of my AVP - Unimrcp test, but I
don't have an Avaya myself, so it will probably be some workday next
week.

Garmt

[firstmah...@gmail.com]

hi garmt
you may not noticed this problem because you tried to test the server
with creating few sessions but if you tried to do heavy test and your
tts engine has limited channels the problem will be clear.
by the way you tried to do the integration only or you tried to test
this integration through telephony application (IVR)

[mahmoud hassan]

hi garmt

concerning your suggestion to use TTS channel when speaking and release it after speaking, using this scenario will lead to lose a lot of mrcp powerful features like set-params get-params and define-lexicon as the tts channel will not be restricted to only one session and every channel will resuse this channel will reuse the previous session that held the TTS channel previous properties.
consider this case

session 1 created.
session 1 speak with paramters rate fast and voice female.
session 1 uses TTS channel 1.
session 1 released
session 2 created
session 2 speak with voice male.
now session 2 speak uses tts channel 1.
session 2 uses voice male and rate fast which was assigned to session 1.

[garmt]

Hi Mahmoud,

Of course my suggestion is just a bypass, not a solution.

I guess it depends on the capabilities and implementation of the TTS
engine. And my suggestion would probably work reasonably in our case.
Opening or closing a TTS channel is not very resource intensive when
using our TTS engine (fluency) nor is switching between voices.
However, starting synthesis is. So I chose not to reuse TTS channels
in my plugin (and I actually don't use the set/get params). Changing
the (default) voice can be achieved by specifying the appropriate VXML
tags (in our case). Rather than having to parse the VMXL stuff in the
unimrcp client (and in our plugin) and additionally create the
apropriate unimrcp calls to change voices or rates, we pass the VXML
on to the Fluency TTS engine. And of course this engine doesn't
support everything...

If someone wants a lot of calls with simultenaous TTS one can
distribute the load using multiple CPU's and/or hosts.
Of course there is some work to be done there, but it's easier than
further optimizing the TTS engine.

Cheers,

Garmt

[garmt]

It was a minimal IVR application accessed by dialing (internally) from
a IP-phoneset.
The good news was that it worked, the bad news was that we did not
manage to get both NUANCE and UniMRCP to work at the same time.
We really did minimal testing.

[Сергей Будай]

Hi everyone ! 

Has anybody integrated avaya voice portal and UniMRCP? Is there any documentation  about it ?

[Arsen Chaloyan]

Hi Сергей,

I personally haven't tried it but can recall users who set it up without troubles. They used MRCPv1 and adjusted the RTSP port number and resource names.

Note: that's kind of disappointing nobody from the community steps up to share with their knowledge. Please try to be a bit more collaborative.

On Mon, Oct 6, 2014 at 6:14 AM, Сергей Будай <webt...@gmail.com> wrote:

Hi everyone ! 

Has anybody integrated avaya voice portal and UniMRCP? Is there any documentation  about it ?

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

[Сергей Будай]

Hi Arsen. Thank you for your answer. Maybe you can show me the guys who did it, and can describe the process in more detail? 

Is Avaya uses the old protocol version 1 instead of MRCPv2 ?

пятница, 10 октября 2014 г., 4:15:27 UTC+3 пользователь Arsen Chaloyan написал:

[Arsen Chaloyan]

Hi Сергей,

When I last heard about interoperability with Avaya, it was MRCPv1 only. However currently, Avaya Voice Portal seems to support MRCPv2 too. I can easily guide you through the setup in the scope of commercial support options. Contact me off-list, if interested.

[Jeff Chun-Hsun Chen]

Hi Arsen,

Did you meant that we can not directly use Unimrcp Server to contact with Avaya Voice Portal Client?

I'm also trying to integrate Avaya Voice Portal Client and Unimrcp Server. My goal now is to make sure the audios can be correctly received by Server from Client.

In advance, I've tried the connection between Avaya Voice Portal Client and Nuance Server first. And it works fine, the audio is received by Server: (RTP(mpf engine) works fine.)

MRCP/2.0 191 RECOGNIZE 6

Channel-Identifier: 56@speechrecog

cancel-if-queue: true

content-type: text/uri-list

start-input-timers: false

Content-length: 29

session:1

session:2

session:3MRCP/2.0 69 6 200 IN-PROGRESS

Channel-Identifier: 56@speechrecog

MRCP/2.0 72 START-INPUT-TIMERS 7

Channel-Identifier: 56@speechrecog

MRCP/2.0 66 7 200 COMPLETE

Channel-Identifier: 56@speechrecog

MRCP/2.0 134 START-OF-INPUT 6 IN-PROGRESS

Channel-Identifier: 56@speechrecog

Proxy-Sync-Id: 0-56@speechrecog

Input-Type: speech

MRCP/2.0 881 RECOGNITION-COMPLETE 6 COMPLETE

Channel-Identifier: 56@speechrecog

Completion-Cause: 000 success

Content-Type: application/nlsml+xml

Content-Length: 708

But when I changed the Nuance Server into UniMRCP Server, then  Avaya Voice Portal Client connect again, it showed:

MRCP/2.0 205 RECOGNIZE 6

Channel-Identifier: 43b0799109931943@speechrecog

cancel-if-queue: true

content-type: text/uri-list

start-input-timers: false

Content-length: 29

session:1

session:2

session:3MRCP/2.0 83 6 200 IN-PROGRESS

Channel-Identifier: 43b0799109931943@speechrecog

MRCP/2.0 86 START-INPUT-TIMERS 7

Channel-Identifier: 43b0799109931943@speechrecog

MRCP/2.0 80 7 200 COMPLETE

Channel-Identifier: 43b0799109931943@speechrecog

MRCP/2.0 72 STOP 8

Channel-Identifier: 43b0799109931943@speechrecog

There is no START-OF-INPUT action, and also the server can not receive the audio. 

Seems like RTP is not running by wireshark, but it do use MRCPv2 actions as the logs above showed.

I'm struggling now. Are there something wrong with the configuration file or others?

Thanks,

Jeff

[Arsen Chaloyan]

Hi Jeff,

On Tue, Oct 14, 2014 at 12:23 AM, Jeff Chun-Hsun Chen <jef...@gmail.com> wrote:

Hi Arsen,

Did you meant that we can not directly use Unimrcp Server to contact with Avaya Voice Portal Client?

No, quite the opposite, surely you can. However, if you feel the need in professional services or consulting, don't hesitate to contact me.

If there is no START-OF-INPUT, then either the server doesn't receive RTP stream or the issue is in VAD. You may find the answers in the logs of UniMRCP server.

Seems like RTP is not running by wireshark, but it do use MRCPv2 actions as the logs above showed.

If you don't see RTP in Wireshark, then most probably the SDP answer had an inappropriate IP address set.

I'm struggling now. Are there something wrong with the configuration file or others?

The problem is not in the MRCPv2 layer but in SDP/RTP as far as I can tell.

[Jeff Chun-Hsun Chen]

Hi Arsen,

About the problem of the connection between avaya voice portal and unimrcp server,

I've tested it again today and found RTP in Wireshark, but still get a 0kb audio file in %UNIMRCPfolder/data.  (which named  as utter-8kHz-XXX.pcm)

On the otherhand,  this unimrcp server works fine with my unimrcp client.

Seems curious. I think the voice is loud enough, so it must not be a VAD problem.

The server side log is as follows:

2014-10-15 10:35:40:169576 [DEBUG]  Wait for Messages [MRCPv2-Agent-1]

2014-10-15 10:35:40:180577 [DEBUG]  Process Signalled Descriptor [MRCPv2-Agent-1]

2014-10-15 10:35:40:182577 [INFO]   Receive MRCPv2 Stream 10.51.231.141:1544 <-> 10.51.216.51:59472 [205 bytes]

MRCP/2.0 205 RECOGNIZE 6

Channel-Identifier: 61a1047094a36c45@speechrecog

cancel-if-queue: true

content-type: text/uri-list

start-input-timers: false

Content-length: 29

session:1

session:2

session:3

2014-10-15 10:35:40:187577 [DEBUG]  Signal Message to [MRCP Server] [2;3]

2014-10-15 10:35:40:188577 [DEBUG]  Wait for Messages [MRCPv2-Agent-1]

2014-10-15 10:35:40:188577 [DEBUG]  Process Message [MRCP Server] [2;3]

2014-10-15 10:35:40:191577 [DEBUG]  Dispatch Signaling Message [1]

2014-10-15 10:35:40:192577 [INFO]   Process RECOGNIZE Request <61a1047094a36c45@speechrecog> [6]

2014-10-15 10:35:40:194577 [DEBUG]  Signal Message to [Demo Recog Engine] [1;0]

2014-10-15 10:35:40:195577 [DEBUG]  Wait for Messages [MRCP Server]

2014-10-15 10:35:40:195577 [DEBUG]  Process Message [Demo Recog Engine] [1;0]

2014-10-15 10:35:40:200578 [DEBUG]  Signal Message to [MRCP Server] [3;4]

2014-10-15 10:35:40:201578 [DEBUG]  Wait for Messages [Demo Recog Engine]

2014-10-15 10:35:40:201578 [DEBUG]  Process Message [MRCP Server] [3;4]

2014-10-15 10:35:40:204578 [INFO]   Process RECOGNIZE Response <61a1047094a36c45@speechrecog> [6]

2014-10-15 10:35:40:205578 [INFO]   State Transition IDLE -> RECOGNIZING <61a1047094a36c45@speechrecog>

2014-10-15 10:35:40:207578 [DEBUG]  Signal Message to [MRCPv2-Agent-1] [1;0]

2014-10-15 10:35:40:208578 [DEBUG]  Wait for Messages [MRCP Server]

2014-10-15 10:35:40:209578 [DEBUG]  Process Poller Wakeup [MRCPv2-Agent-1]

2014-10-15 10:35:40:211578 [DEBUG]  Process Message [MRCPv2-Agent-1] [1;0]

2014-10-15 10:35:40:213578 [INFO]   Send MRCPv2 Stream 10.51.231.141:1544 <-> 10.51.216.51:59472 [83 bytes]

MRCP/2.0 83 6 200 IN-PROGRESS

Channel-Identifier: 61a1047094a36c45@speechrecog

nta: Via check: invalid transport "SIP/2.0/UDP" from [clientIP]:31000

2014-10-15 10:35:40:215579 [DEBUG]  Wait for Messages [MRCPv2-Agent-1]

nta: Via check: invalid transport "SIP/2.0/UDP" from [clientIP]:31000

nta: Via check: invalid transport "SIP/2.0/UDP" from [clientIP]:31000

2014-10-15 10:35:46:939963 [DEBUG]  Process Signalled Descriptor [MRCPv2-Agent-1]

2014-10-15 10:35:46:940963 [INFO]   Receive MRCPv2 Stream 10.51.231.141:1544 <-> 10.51.216.51:59472 [86 bytes]

MRCP/2.0 86 START-INPUT-TIMERS 7

Channel-Identifier: 61a1047094a36c45@speechrecog

2014-10-15 10:35:46:943963 [DEBUG]  Signal Message to [MRCP Server] [2;3]

2014-10-15 10:35:46:945963 [DEBUG]  Wait for Messages [MRCPv2-Agent-1]

2014-10-15 10:35:46:945963 [DEBUG]  Process Message [MRCP Server] [2;3]

2014-10-15 10:35:46:948964 [DEBUG]  Dispatch Signaling Message [1]

2014-10-15 10:35:46:950964 [INFO]   Process START-INPUT-TIMERS Request <61a1047094a36c45@speechrecog> [7]

2014-10-15 10:35:46:952964 [DEBUG]  Signal Message to [Demo Recog Engine] [1;0]

2014-10-15 10:35:46:953964 [DEBUG]  Wait for Messages [MRCP Server]

2014-10-15 10:35:46:953964 [DEBUG]  Process Message [Demo Recog Engine] [1;0]

2014-10-15 10:35:46:957964 [DEBUG]  Signal Message to [MRCP Server] [3;4]

2014-10-15 10:35:46:958964 [DEBUG]  Wait for Messages [Demo Recog Engine]

2014-10-15 10:35:46:958964 [DEBUG]  Process Message [MRCP Server] [3;4]

2014-10-15 10:35:46:961964 [INFO]   Process START-INPUT-TIMERS Response <61a1047094a36c45@speechrecog> [7]

2014-10-15 10:35:46:963964 [DEBUG]  Signal Message to [MRCPv2-Agent-1] [1;0]

2014-10-15 10:35:46:965965 [DEBUG]  Wait for Messages [MRCP Server]

2014-10-15 10:35:46:965965 [DEBUG]  Process Poller Wakeup [MRCPv2-Agent-1]

2014-10-15 10:35:46:968965 [DEBUG]  Process Message [MRCPv2-Agent-1] [1;0]

2014-10-15 10:35:46:970965 [INFO]   Send MRCPv2 Stream 10.51.231.141:1544 <-> 10.51.216.51:59472 [80 bytes]

MRCP/2.0 80 7 200 COMPLETE

Channel-Identifier: 61a1047094a36c45@speechrecog

2014-10-15 10:35:46:973965 [DEBUG]  Wait for Messages [MRCPv2-Agent-1]

nta: Via check: invalid transport "SIP/2.0/UDP" from [clientIP]:31000

nta: Via check: invalid transport "SIP/2.0/UDP" from [clientIP]:31000

2014-10-15 10:35:51:940249 [DEBUG]  Process Signalled Descriptor [MRCPv2-Agent-1]

2014-10-15 10:35:51:941249 [INFO]   Receive MRCPv2 Stream 10.51.231.141:1544 <-> 10.51.216.51:59472 [72 bytes]

MRCP/2.0 72 STOP 8

Channel-Identifier: 61a1047094a36c45@speechrecog

I don't know if the yellow highlighted lines cause the server side can't correctly received the RTP sent audio files?

Thanks,

Jeff

[Arsen Chaloyan]

Hi Jeff,

The extracted logs mostly apply to the MRCPv2 message exchange, whereas the problem seems to be in the SDP offer/answer. Logs encompassing whole session and corresponding network capture are required to identify the problem.

You may also enable the following entries in <sip-uas> settings:

      <sip-message-output>true</sip-message-output>
      <sip-message-dump>/tmp/sofia-sip.log</sip-message-dump>

As for the RTP statistics, look at the statement "Close RTP Receiver" which follows the number of packets received, lost, etc [r:101 l:0 j:0 p:50 d:0 i:0].

[Jeff Chun-Hsun Chen]

Hi Arsen,

After I did the changes, seems like the SIP/TCP is executing normally now. (as attached file 20141023_avaya_UniMRCPServer(sofiasipRevised).pcapng showed)

But the audio still not received in the data folder. (The pcm file is 0kb.)

There is another test that I use another MRCP client instead of avaya Client, to connect to the same UniMRCP v1.0.0 server, and the audio is successfully received by the server.

This test, the SIP connection is under UDP instead of TCP. (as attached file 20141015_AnotherMRCPclient_UniMRCPServer.pcapng showed)

Does the audio receiving problem happened because of the avaya SIP connection using TCP instead of UDP? 

Thanks,

Jeff

2014-10-23 3:18 GMT+08:00 Arsen Chaloyan <acha...@gmail.com>:

Hi Jeff,

I believe it works with NSS because of the transport parameter in the Contact header of SIP OK.

Contact: <sip:mrcps...@10.51.231.141:5060;transport=TCP>

Whereas, in case of UniMRCP server, it looks like

Contact: <sip:10.51.231.141:5060>

Avaya makes a wrong assumption here. If the transport parameter is not specified, that doesn't mean that the requested transport is UDP. And in fact, they send the ACK message over TCP having set UDP in Via. Very weird.

By default, UniMRCP Server / Sofia-SIP accepts both TCP and UDP connections for SIP.

      <sip-transport>udp,tcp</sip-transport>

And in this case, since both are supported, there shouldn't be any transport parameter in the Contact header.

Anyway, to make it work with Avaya via TCP, you can do the following

1) Leave only TCP in the configuration

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

2) Comment or just take out the following line from the function mrcp_sofia_on_session_answer() in modules/mrcp-sofiasip/src/mrcp_sofia_server_agent.c

                SIPTAG_CONTACT_STR(sofia_agent->sip_contact_str),

This would allow Sofia-SIP to implicitly set the contact header with the corresponding transport parameter in the SIP OK.

3) Build the server

For further communication, please post your messages to the discussion group, instead of sending them directly to me.

On Sun, Oct 19, 2014 at 7:41 PM, Jeff Chun-Hsun Chen <jef...@gmail.com> wrote:

Hi Arsen,

OK. I'll try to configure Avaya to use UDP for SIP first.

But I hope you to see attached the Wireshark catched packets of the connection between avaya client and nuance server.

Seems like the SIP/TCP is working with Nuance MRCP Server:

From: sip:mpp@VP;tag=90964d199c52e419b80033a33d8

To: sip:mres...@10.51.231.141

Call-ID: e0964d199c52e419c80033a33d8

CSeq: 1 INVITE

Max-Forwards: 70

Via: SIP/2.0/TCP 10.51.216.51;branch=z9hG4bKd0ab4d199c52e419d80033a33d8

User-Agent: Avaya-VoicePortal/6.0.2.0.0501

Supported: 100rel, timer, replaces, join, histinfo

Allow: INVITE, CANCEL, BYE, ACK, PRACK, SUBSCRIBE, NOTIFY, REFER, OPTIONS, INFO, PUBLISH

Contact: <sip:10.51.216.51;transport=tcp>

Session-Expires: 1200;refresher=uac

Min-SE: 1200

Content-Type: application/sdp

Content-Length: 339

v=0

o=- 1 1 IN IP4 10.51.216.51

s=-

t=0 0

m=audio 23892 RTP/AVP 0 8 18 127

c=IN IP4 10.51.216.51

a=rtpmap:0 PCMU/8000

a=rtpmap:8 PCMA/8000

a=rtpmap:18 G729/8000

a=rtpmap:127 telephone-event/8000

a=sendonly

m=application 9 TCP/MRCPv2 1

c=IN IP4 10.51.231.141

a=setup:active

a=connection:new

a=cmid:1

a=resource:speechrecog

SIP/2.0 200 OK

Via: SIP/2.0/TCP 10.51.216.51;branch=z9hG4bKd0ab4d199c52e419d80033a33d8

Contact: <sip:mrcps...@10.51.231.141:5060;transport=TCP>

To: <sip:mres...@10.51.231.141>;tag=1478854f

From: <sip:mpp@VP>;tag=90964d199c52e419b80033a33d8

Call-ID: e0964d199c52e419c80033a33d8

CSeq: 1 INVITE

Content-Type: application/sdp

Content-Length: 387

v=0

o=- 1413351342 1413351342 IN IP4 10.51.231.141

s=Nuance MRCP session V2

c=IN IP4 10.51.231.141

t=0 0

m=audio 7892 RTP/AVP 0 8 127 122

a=rtpmap:0 pcmu/8000

a=rtpmap:8 pcma/8000

a=rtpmap:127 telephone-event/8000

a=rtpmap:122 l16/8000

a=fmtp:127 0-15

a=mid:1

a=recvonly

m=application 6075 TCP/MRCPv2 1

a=cmid:1

a=setup:passive

a=connection:new

a=channel:1@speechrecog

ACK sip:mrcps...@10.51.231.141:5060;transport=TCP SIP/2.0

From: <sip:mpp@VP>;tag=90964d199c52e419b80033a33d8

To: <sip:mres...@10.51.231.141>;tag=1478854f

Call-ID: e0964d199c52e419c80033a33d8

CSeq: 1 ACK

Max-Forwards: 70

Via: SIP/2.0/TCP 10.51.216.51;branch=z9hG4bK2622a4199c52e419e80033a33d8

User-Agent: Avaya-VoicePortal/6.0.2.0.0501

Content-Length: 0

BYE sip:mrcps...@10.51.231.141:5060;transport=TCP SIP/2.0

From: sip:mpp@VP;tag=90964d199c52e419b80033a33d8

To: sip:mres...@10.51.231.141;tag=1478854f

Call-ID: e0964d199c52e419c80033a33d8

CSeq: 2 BYE

Max-Forwards: 70

Via: SIP/2.0/TCP 10.51.216.51;branch=z9hG4bK10878a259c52e419f80033a33d8

User-Agent: Avaya-VoicePortal/6.0.2.0.0501

Content-Length: 0

SIP/2.0 200 OK

Via: SIP/2.0/TCP 10.51.216.51;branch=z9hG4bK10878a259c52e419f80033a33d8

Contact: <sip:mrcps...@10.51.231.141:5060;transport=TCP>

To: <sip:mres...@10.51.231.141>;tag=1478854f

From: <sip:mpp@VP>;tag=90964d199c52e419b80033a33d8

Call-ID: e0964d199c52e419c80033a33d8

CSeq: 2 BYE

Content-Length: 0

Maybe I'm misunderstanding. Or is that meant the Nuance MRCP Server did special processing for the SIP/TCP case?

Thanks,
Jeff

2014-10-18 2:28 GMT+08:00 Arsen Chaloyan <acha...@gmail.com>:

Hi Jeff,

Much better. The more complete is the report, the closer is the resolution.

I'd expect UniMRCP 1.0.0 and 1.2.0 to behave the same way in this respect, but I really don't remember all the differences between these two versions. Note that 1.0.0 is 4-years old.

Now, let's focus on 1.2.0 and the attempt you marked as successful. Although RTP packets were normally received and processed, SIP session was not fully established, and the problem is in how Avaya constructs the Via header in the SIP ACK message. Below are the corresponding SIP messages extracted from your network capture:

INVITE sip:mres...@10.51.231.141 SIP/2.0
From: sip:mpp@VP;tag=28b855e63854e411100033a33d8
To: sip:mres...@10.51.231.141
Call-ID: 5ab855e63854e411200033a33d8
CSeq: 1 INVITE
Max-Forwards: 70
Via: SIP/2.0/TCP 10.51.216.51;branch=z9hG4bK18cd55e63854e411300033a33d8
User-Agent: Avaya-VoicePortal/6.0.2.0.0501
Supported: 100rel, timer, replaces, join, histinfo
Allow: INVITE, CANCEL, BYE, ACK, PRACK, SUBSCRIBE, NOTIFY, REFER, OPTIONS, INFO, PUBLISH
Contact: <sip:10.51.216.51;transport=tcp>
Session-Expires: 1200;refresher=uac
Min-SE: 1200
Content-Type: application/sdp
Content-Length: 339

v=0
o=- 1 1 IN IP4 10.51.216.51
s=-
t=0 0
m=audio 23020 RTP/AVP 0 8 18 127
c=IN IP4 10.51.216.51
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=rtpmap:127 telephone-event/8000
a=sendonly
m=application 9 TCP/MRCPv2 1
c=IN IP4 10.51.231.141
a=setup:active
a=connection:new
a=cmid:1
a=resource:speechrecog
SIP/2.0 100 Trying
Via: SIP/2.0/TCP 10.51.216.51;branch=z9hG4bK18cd55e63854e411300033a33d8;rport=31004
From: sip:mpp@VP;tag=28b855e63854e411100033a33d8
To: sip:mres...@10.51.231.141
Call-ID: 5ab855e63854e411200033a33d8
CSeq: 1 INVITE
User-Agent: UniMRCP SofiaSIP
Content-Length: 0

SIP/2.0 200 OK
Via: SIP/2.0/TCP 10.51.216.51;branch=z9hG4bK18cd55e63854e411300033a33d8;rport=31004
From: sip:mpp@VP;tag=28b855e63854e411100033a33d8
To: <sip:mres...@10.51.231.141>;tag=34g0D8Zv0UNer
Call-ID: 5ab855e63854e411200033a33d8
CSeq: 1 INVITE
Contact: <sip:10.51.231.141:5060>
User-Agent: UniMRCP SofiaSIP
Accept: application/sdp
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE, NOTIFY, REFER, UPDATE
Supported: timer, 100rel
Session-Expires: 1200;refresher=uac
Min-SE: 1200
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 359

v=0
o=UniMRCPServer 6451443600073151064 520690701680639504 IN IP4 10.51.231.141
s=-
c=IN IP4 10.51.231.141
t=0 0
m=audio 5000 RTP/AVP 0 127
a=rtpmap:0 PCMU/8000
a=rtpmap:127 telephone-event/8000
a=fmtp:127 0-15
a=recvonly
a=mid:0
m=application 1544 TCP/MRCPv2 1
a=setup:passive
a=connection:new
a=channel:cb9cd7da2ee42148@speechrecog
a=cmid:1

ACK sip:10.51.231.141:5060 SIP/2.0
From: sip:mpp@VP;tag=28b855e63854e411100033a33d8
To: <sip:mres...@10.51.231.141>;tag=34g0D8Zv0UNer
Call-ID: 5ab855e63854e411200033a33d8
CSeq: 1 ACK
Max-Forwards: 70
Via: SIP/2.0/UDP 10.51.216.51;branch=z9hG4bK70ff6be63854e411400033a33d8
User-Agent: Avaya-VoicePortal/6.0.2.0.0501
Content-Length: 0

As you noted, Sofia-SIP complains about an invalid transport in the Via header, and it does absolutely right. Instead of

Via: SIP/2.0/UDP 10.51.216.51;branch=z9hG4bK70ff6be63854e411400033a33d8

there MUST have been

Via: SIP/2.0/TCP 10.51.216.51;branch=z9hG4bK18cd55e63854e411300033a33d8

The SIP spec is quite clear about that. See section 17.1.1.3 (http://tools.ietf.org/html/rfc3261#section-17.1.1.3), in particular:

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

As a result, Sofia-SIP drops the invalid ACK and keeps sending (re-transmitting) SIP OK messages to the client, and the client re-transmitting the final ACK response with no go. Eventually, the session abnormally timed out. The timeout was longer than your utterance, that's why you probably didn't notice anything wrong.

You may report this to Avaya. I'm not sure if User-Agent: Avaya-VoicePortal/6.0.2.0.0501 is their latest release or not, but this particular version is definitely affected. Alternatively, try to configure Avaya to use UDP for SIP, the problem might be gone then.

On Fri, Oct 17, 2014 at 12:17 AM, Jeff Chun-Hsun Chen <jef...@gmail.com> wrote:

Hi Arsen,

I'm using UniMRCP v1.0.0 Server, which did not have the <sip-message-output> and <sip-message-dump> settings. 

But I've found that UniMRCP v1.2.0 Server do have these settings , so today I've also tried UniMRCP v1.2.0 Server to receive the audios sent from Avaya Voice Portal.

Surprisingly, it can correctly receive the audios. (and it do show MRCPv2 START-OF-INPUT action)

Though I also saw the nta: Via check: invalid transport "SIP/2.0/UDP" from [clientIP]:31000 error line wih UniMRCP v1.2.0,

it seems like the nta problem did not really prevent the server from receiving audios. 

For some reason I should use the UniMRCP v1.0.0 Server, how to find out why the problem only happened in v1.0.0 but not in v1.2.0?

(the UniMRCP v1.0.0 Server used is from the SDK one, I did not change any code for this testing.)

The attached file contain 2 folders:
UniMRCPv1.0.0_failedReceiveAudio:  the whole session unimrcpserver-0.log (loglevel=7) file and the wireshark catched packets from server side with UniMRCPv1.0.0
UniMRCPv1.2.0_successReceiveAudio:  the whole session unimrcpserver-0.log (loglevel=7) file and the wireshark catched packets from server side with UniMRCPv1.2.0

Many thanks for help to check about it.

Thanks,

Jeff

[Arsen Chaloyan]

Hi Jeff,

On Wed, Oct 22, 2014 at 10:25 PM, Jeff Chun-Hsun Chen <jef...@gmail.com> wrote:

Hi Arsen,

After I did the changes, seems like the SIP/TCP is executing normally now. (as attached file 20141023_avaya_UniMRCPServer(sofiasipRevised).pcapng showed)

Glad it helped. I'll consider applying that change to the upstream version too. Don't see any downsides so far.

 

But the audio still not received in the data folder. (The pcm file is 0kb.)

Did you ever check for the statement CloseRTPReceiver, which I suggested earlier. How many packets were received dropped, etc?

Anyway, I wonder why you don't simply use 1.2.0, which works well according to you. Sorry, but I don't have the time and courage to look back at 1.0.0. It was released in 2010.

There is another test that I use another MRCP client instead of avaya Client, to connect to the same UniMRCP v1.0.0 server, and the audio is successfully received by the server.

This test, the SIP connection is under UDP instead of TCP. (as attached file 20141015_AnotherMRCPclient_UniMRCPServer.pcapng showed)

Does the audio receiving problem happened because of the avaya SIP connection using TCP instead of UDP? 

No, SIP transport has most probably no relevance to the RTP issue.

[Jeff Chun-Hsun Chen]

Hi Arsen, 

My developing environment is under VC6 (should integrate with other VC6 libraries and projects), and I use UniMRCP v1.0.0 because I've already built its libraries under VC6 before.

But in order to solve this problem, I've already compiled and built the UniMRCP v1.2.0 libraries and unimrcp-server under VC6 these days.

Now when running this VC6 built unimrcp-server-v1.2.0 with your mrcp-sofiasip revised version, it seems the problem is solved. 

I'll do further testing and intergrating to make sure it.

Thanks,

Jeff

[Arsen Chaloyan]

Hi Jeff,

Thanks for the update. VC6 is a very rare case nowadays, and you are on an unexplored territory. Nevertheless, if you get it compiled, the rest should work as is.

I have made a few relevant changes in r2216.

https://code.google.com/p/unimrcp/source/detail?r=2216

There shouldn't be anything new in terms of functionality you are interested in compared to the version you already have. The transport parameter will be set in the SIP Contact header, if either TCP or UDP (but not both) is specified in the configuration. And that makes Avaya compose a proper SIP Via header in ACK.

[Jeff Chun-Hsun Chen]

Hi Arsen,

Thanks for this updated version.

In fact, Avaya once said that their Avaya Aura Experience Portal(AAEP) did not support UniMRCP. (They did not explain what is not supported, but I think it is mainly about the SIP/TCP issue.)
But with this updated UniMRCP v1.2 version, now I can correctly connect it to AAEP and the audio is recognized successfully.

Thanks,

Jeff

[Arsen Chaloyan]

Hi Jeff,

I'd guess Avaya might be streamlined to support solutions on par with them and may not care too much about an open source project. At the same time, I'd wish they could better comply with the specs not to have the SIP VIA transport set to UDP in a message being actually sent over TCP. It was kind of ridiculous.