UniMRCP recognition plugin demo issues

[Pallaris]

Hello!

Right after build I've started unimrcpserver and umc, and run "run recog umi1". As a result I've expected to see an 'utter%.pcm' file in var directory similar to 'one-8kHz.pcm' which being sent after all the encoding-decoding. But it contains only zeros with overall file size of 80000 bytes. What am I missing?

And I cannot start "run recog" (which should use mrcpv2 protocol, I guess) - its simply doesnt interact with server providint client request timeout

2017-10-04 21:13:31:485963 [INFO]   Receive SIP Event [nua_i_state] Status 0 INV

ITE sent [SIP-Agent-1]

2017-10-04 21:13:31:488463 [NOTICE] SIP Call State umc-1 [calling]

2017-10-04 21:14:03:484994 [INFO]   Receive SIP Event [nua_r_invite] Status 408

Request Timeout [SIP-Agent-1]

2017-10-04 21:14:03:484994 [INFO]   Receive SIP Event [nua_i_state] Status 408 R

equest Timeout [SIP-Agent-1]

2017-10-04 21:14:03:487008 [NOTICE] SIP Call State umc-1 [terminated]

2017-10-04 21:14:03:488020 [INFO]   Receive Answer umc-1 <new> [c:0 a:0 v:0] Sta

tus 408

2017-10-04 21:14:03:489001 [INFO]   Raise App Response umc-1 <new> [2] FAILURE [

2]

2017-10-04 21:14:03:491019 [INFO]   Receive App Request umc-1 <new> [1]

2017-10-04 21:14:03:491019 [INFO]   Terminate Session umc-1 <new>

2017-10-04 21:14:03:493014 [INFO]   Session Terminated umc-1 <new>

2017-10-04 21:14:03:500024 [INFO]   Remove MRCP Handle umc-1 <new>

2017-10-04 21:14:03:500024 [INFO]   Raise App Response umc-1 <new> [1] SUCCESS [

0]

2017-10-04 21:14:03:503010 [NOTICE] Destroy MRCP Handle umc-1

Guess its something about sofia sip agent?

Any help would be appreciated

[Arsen Chaloyan]

Hello,

On Wed, Oct 4, 2017 at 7:17 AM, Pallaris <dri...@gmail.com> wrote:

Hello!

Right after build I've started unimrcpserver and umc, and run "run recog umi1". As a result I've expected to see an 'utter%.pcm' file in var directory similar to 'one-8kHz.pcm' which being sent after all the encoding-decoding. But it contains only zeros with overall file size of 80000 bytes. What am I missing?

Maybe you can track RTP stats output in client logs after "Close RTP Transmitter" and "Close RTP Receiver" on the server respectively to make sure the data is getting through.

 

And I cannot start "run recog" (which should use mrcpv2 protocol, I guess) - its simply doesnt interact with server providint client request timeout

2017-10-04 21:13:31:485963 [INFO]   Receive SIP Event [nua_i_state] Status 0 INV

ITE sent [SIP-Agent-1]

2017-10-04 21:13:31:488463 [NOTICE] SIP Call State umc-1 [calling]

2017-10-04 21:14:03:484994 [INFO]   Receive SIP Event [nua_r_invite] Status 408

Request Timeout [SIP-Agent-1]

2017-10-04 21:14:03:484994 [INFO]   Receive SIP Event [nua_i_state] Status 408 R

equest Timeout [SIP-Agent-1]

2017-10-04 21:14:03:487008 [NOTICE] SIP Call State umc-1 [terminated]

2017-10-04 21:14:03:488020 [INFO]   Receive Answer umc-1 <new> [c:0 a:0 v:0] Sta

tus 408

2017-10-04 21:14:03:489001 [INFO]   Raise App Response umc-1 <new> [2] FAILURE [

2]

2017-10-04 21:14:03:491019 [INFO]   Receive App Request umc-1 <new> [1]

2017-10-04 21:14:03:491019 [INFO]   Terminate Session umc-1 <new>

2017-10-04 21:14:03:493014 [INFO]   Session Terminated umc-1 <new>

2017-10-04 21:14:03:500024 [INFO]   Remove MRCP Handle umc-1 <new>

2017-10-04 21:14:03:500024 [INFO]   Raise App Response umc-1 <new> [1] SUCCESS [

0]

2017-10-04 21:14:03:503010 [NOTICE] Destroy MRCP Handle umc-1

Guess its something about sofia sip agent?

I'd check the ports. Are you sure your server is running and listening on the intended port such as 8060 by default. Use netstat.

 

Any help would be appreciated

If you follow the default routine, then everything should work as documented. What is the OS?

Anyway, if your could provide the complete output of client and server logs, including start-up of applications, I would be probably be of more help.

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

[Pallaris]

Hello!

Thank you for quick answer.

I'm currently on Windows 8.1 Pro x64

I've attached server and client logs with debug level containing both sides init and "recog" scenario information. 

Netstat shows correct ports, telnet approves

 TCP    10.154.2.149:1544      0.0.0.0:0              LISTENING

 TCP    10.154.2.149:1554      0.0.0.0:0              LISTENING

 TCP    10.154.2.149:8060      0.0.0.0:0              LISTENING

There is strange timeout on server side on init step, but it doesnt seem to affect anything

2017-10-05 11:37:38:931919 [NOTICE] Create RTSP Server [RTSP-Agent-1] 10.154.2.149:1554 [100] connection timeout [600 sec]

With audio data passed  over RTP everything seems fine

Client

2017-10-05 11:37:45:940373 [INFO]   Media Path umc-1 Source->[LPCM/8000/1]->Bridge->[LPCM/8000/1]->Encoder->[PCMU/8000/1]->Sink

2017-10-05 11:37:45:940373 [INFO]   Raise App Response umc-1 <d7f24ba2f9c7054d> [2] SUCCESS [0]

Server

2017-10-05 11:37:45:933334 [INFO]   Media Path 0x26aaa40 Source->[PCMU/8000/1]->Decoder->[LPCM/8000/1]->Bridge->[LPCM/8000/1]->Sink

Still 'utter%.pcm' is filled with zeroes. I've tried to limit codec list to L16/96/8000 on both sides with no effect. 

Client

2017-10-05 11:59:52:173538 [INFO]   Open RTP Transmitter 10.154.2.149:4000 -> 10.154.2.149:5000

2017-10-05 11:59:52:173538 [INFO]   Media Path umc-1 Source->[LPCM/8000/1]->Bridge->[LPCM/8000/1]->Encoder->[L16/8000/1]->Sink

2017-10-05 11:59:52:173538 [INFO]   Raise App Response umc-1 <1b70ca3e453c724b> [2] SUCCESS [0]

Server

2017-10-05 11:59:52:164498 [INFO]   Open RTP Receiver 10.154.2.149:5000 <- 10.154.2.149:4000 playout [50 ms] bounds [0 - 600 ms] adaptive [1] skew detection [1]

2017-10-05 11:59:52:164498 [INFO]   Media Path 0xaeaa40 Source->[L16/8000/1]->Decoder->[LPCM/8000/1]->Bridge->[LPCM/8000/1]->Sink

2017-10-05 11:59:52:164498 [INFO]   Send Answer 0xaeaa40 <1b70ca3e453c724b> [c:0 a:1 v:0] Status OK 

Actually I'm curious why it uses encoding-decoding in this case anyway?

 

четверг, 5 октября 2017 г., 6:06:07 UTC+7 пользователь Arsen Chaloyan написал:

Hello,

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]

OK, let's interpret your log statements with regards to RTP stats.

Client
2017-10-05 11:37:45:940373 [INFO]   Open RTP Transmitter 10.154.2.149:4000 -> 10.154.2.149:5000
2017-10-05 11:37:50:971203 [INFO]   Close RTP Transmitter 10.154.2.149:4000 -> 10.154.2.149:5000 [s:101 o:16160]

The above indicates that the client sent 101 RTP packets to the server 10.154.2.149:5000.

Server

2017-10-05 11:37:45:933334 [INFO]   Open RTP Receiver 10.154.2.149:5000 <- 10.154.2.149:4000 playout [50 ms] bounds [0 - 600 ms] adaptive [1] skew detection [1]
2017-10-05 11:37:50:983240 [INFO]   Close RTP Receiver 10.154.2.149:5000 <- 10.154.2.149:4000 [r:0 l:0 j:0 p:50 d:0 i:0]

All is good, but the server actually received 0 packets. I do not know any good reason, and I think you should answer this question. As a hint, I see that RTSP packets are getting through, since they are going over TCP, whereas RTP is over UDP. The same is for SIP. Sofia-SIP is configured to use the UDP transport by default. That's why you could not establish an MRCPv2 session. I guess if you change the SIP transport to TCP, you will have the same picture as for RTSP/MRCPv1: call signaling will work, but not RTP. So, find out what is wrong with UDP ports on your system.

2017-10-05 11:59:52:164498 [INFO]   Media Path 0xaeaa40 Source->[L16/8000/1]->Decoder->[LPCM/8000/1]->Bridge->[LPCM/8000/1]->Sink

> Actually I'm curious why it uses encoding-decoding in this case anyway?

There is no actual encoding or decoding involved in case of L16. The audio samples are just swapped to/from network order before being set in or read from RTP packets.

https://tools.ietf.org/html/rfc3551#section-4.5.11

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.