SIP OPTIONS and capabilities of MRCP server

[GoogleCodeExporter]

Please provide the detailed description of the feature being requested and
outline the use cases.

SIP OPTIONS to learn the capabilities of MRCP server has not been
implemented in UniMRCP, yet. Thus, it is not possible to create sessions
between clients, which send SIP OPTIONS, and the server.

Original issue reported on code.google.com by bayrambo...@gmail.com on 11 Mar 2009 at 12:16

[GoogleCodeExporter]

I'll provide a quick workaround in a day or two.

Original comment by achalo...@gmail.com on 11 Mar 2009 at 12:23

• Changed state: Accepted
• Added labels: Component-Client, Component-Server, Milestone-Release-0.6, OpSys-All, Priority-Medium, Type-Enhancement

[GoogleCodeExporter]

Bayram,
Find attached a patch (sip-options.patch) against the latest trunk, which 
modifies
only mrcp_sofiasip_server_agent.c to respond incoming SIP-OPTIONS with hard 
coded
capabilities.
That modification should be simple to apply to the older released versions too.
Hope this helps and let me know in case of any questions.

Original comment by achalo...@gmail.com on 13 Mar 2009 at 11:46

Attachments:

• sip-options.patch

[GoogleCodeExporter]

Thanks Arsen, I have applied patch to version we have. Also we upgraded to 
latest
trunk. I will let you know the result.

Original comment by bayrambo...@gmail.com on 16 Mar 2009 at 1:26

[GoogleCodeExporter]

Hi Arsen,

It just works great! Thanks :-)

Best wishes,
Bayram

Original comment by bayrambo...@gmail.com on 16 Mar 2009 at 2:23

[GoogleCodeExporter]

Hi Bayram,
I'm glad to see it works for you. 

Finally those capabilities should not be hard coded, but must be configuration
dependent. I'll implement it in the future, in the interim, perhaps it'd be 
better to
respond with hard coded capabilities.

Thanks for the feedback (sometimes users only post when they need something).
Arsen.

Original comment by achalo...@gmail.com on 17 Mar 2009 at 7:05

[GoogleCodeExporter]

Hi Arsen, I have bad news. There is this GVP IVR, when we made a call our the 
request
reached to UniMRCP server and so the text was synthesized. But after first 
call, the
other requests never reached to server. But UniMRCP server logs were always 
saying this:

nta_agent: received garbage from udp/192.168.5.178:8060/sip

After we upgraded latest trunk and applied the patch you supplied. We tested the
program and I dont know why, but that time all successive requests reached to 
the
server and so all texts were synthesized.

But we still started to get the same problem. And the problem is not UniMRCP's 
being
not able to respond SIP OPTIONS request. The problem is Sofia-SIP treats that 
SIP
message as a garbage and never let UniMRCP to process it.

I used wireshark and copied the raw text of the sip message:

OPTIONS sip:speechsynth@172.16.5.224:8060@172.16.5.224 SIP/2.0\r\n
Via: SIP/2.0/UDP 192.168.5.178:7080;branch=z9hG4bK01add590c0bced\r\n
From: 
sip:VoiceGenie@192.168.5.178:7080;tag=E8ACE618-6ABC-4E89-28B7-E70EBE7E3B52\r\n
To: sip:speechsynth@172.16.5.224:8060@172.16.5.224\r\n
Max-Forwards: 70\r\n
CSeq: 1 OPTIONS\r\n
Call-ID: C4C8F662-2B45-4445-4688-8098B2559A01-7080@192.168.5.178\r\n
Contact: <sip:VoiceGenie@192.168.5.178:7080>\r\n
Content-Length: 0\r\n
Supported: timer\r\n
\r\n

When this message is sent, Sofia-SIP treats it as a garbage...and we see

nta_agent: received garbage from udp/192.168.5.178:8060/sip

message in UniMRCP logs.

It seems the SIP message is true, and I don't have any idea why Sofia-SIP 
thinks that
it is a garbage. Have you ever had this problem? Any idea?

In nta.c file of Sofia-SIP, there is this function:

agent_recv_message

and there, we see this code segment:

 if (sip && sip->sip_request) {
    agent_recv_request(agent, msg, sip, tport);
  }
  else if (sip && sip->sip_status) {
    agent_recv_response(agent, msg, sip, tport_via, tport);
  }
  else {
    agent_recv_garbage(agent, msg, tport);
  }

I added a code that prints out if the followings are null or not:

sip, sip->request, sip->status

And the result is:

NOT NULL, NULL, NULL

so, the message is garbage (!)

Anyway, I will be working on it, if I find anything I will let you know.

Best wishes,
Bayram

ps: our ip was: 172.16.5.224
GVP IVR ip was: 192.168.5.178

Original comment by bayrambo...@gmail.com on 18 Mar 2009 at 9:37

[GoogleCodeExporter]

Hi Bayram,
First of all I'd suggest to setup GVP IVR and UniMRCP server on the same net, 
if it's
possible. I'm not sure, but different subnets may cause this problem 
(172.16.5.224,
192.168.5.178).
I need Wireshark trace and UniMRCP server console output containing both 
successful
and non-successful cases. Also turn Sofia-SIP debug output on.

Before running UniMRCP server from command line set the following environment 
vars

>Windows
set SOFIA_DEBUG=9
set NUA_DEBUG=9
set SOA_DEBUG=9
set NEA_DEBUG=9
set IPTSEC_DEBUG=9
set NTA_DEBUG=9
set TPORT_DEBUG=9
set TPORT_LOG=9
set TPORT_DUMP=/tmp/tport_sip.log
set SU_DEBUG=9
unimrcpserver

>Linux
export SOFIA_DEBUG=9
export NUA_DEBUG=9
export SOA_DEBUG=9
export NEA_DEBUG=9
export IPTSEC_DEBUG=9
export NTA_DEBUG=9
export TPORT_DEBUG=9
export TPORT_LOG=9
export SU_DEBUG=9
./unimrcpserver

Original comment by achalo...@gmail.com on 18 Mar 2009 at 11:23

[GoogleCodeExporter]

Hello Arsen,

I am sorry for being late. But I have the logs now.

We used Cisco Systems VPN client to connect the network in which the GVP is
installed. When I find opportunity to try in the same network I will again save 
the
logs and will inform you about that.

So in attachments I am sending wireshark logs, unimrcpserver console logs, and
tport_sip.log file.

In this scenario, I restarted GVP, and first two attempts were successfull 
although I
have seen the same garbage messages. But later, I tried 3 more times but they 
are not
successfull.

Best wishes,
Bayram

Original comment by bayrambo...@gmail.com on 23 Mar 2009 at 8:18

Attachments:

• unimrcpserver_console_logs.txt
• tport_sip.log
• wireshark_logs.pcap

[GoogleCodeExporter]

Hello Bayram,

I've just looked through the attachments.
First of all, I believe GVP uses SIP Options as keep alive message, but not to
actually learn the capabilities of server as it is described in spec.
Next, I agree with Sofia, SIP Options GVP sends is invalid. Pay attention to 
SIP URI
in message start-line.

instead of 
OPTIONS sip:speechsynth@172.16.5.224:8060@172.16.5.224 SIP/2.0

should be
OPTIONS sip:speechsynth@172.16.5.224:8060 SIP/2.0

The same is for SIP To header.

More over, I see only two MRCP sessions (SIP Invites), thus I have no clue why 
the
final 3 attempts was unsuccessful, at least no SIP Invite reached MRCP server. 
Most
probably the problem is in client side.

HTH,
Arsen.

Original comment by achalo...@gmail.com on 23 Mar 2009 at 11:41

[GoogleCodeExporter]

Wow, you are right! The message is wrong! :-)

And I really appreciate your help Arsen. If you had not helped us, it would have
taken a lot of time of us.

Best wishes, thanks
Bayram

Original comment by bayrambo...@gmail.com on 23 Mar 2009 at 3:09

[GoogleCodeExporter]

Hello Arsen, I want to ask you another question... Does UniMRCP handles v1 
equivalent
of SIP OPTIONS message, which is DESCRIBE?

Best wishes,
Bayram

ps... I get this message with Avaya IR

2009-03-30 12:30:54:468750 [INFO]   Receive RTSP Stream [83 bytes]
DESCRIBE rtsp://media/speechsynthesizer RTSP/1.0
CSeq: 0
Accept: application/sdp

2009-03-30 12:30:54:484375 [NOTICE] Create RTSP Session <88c63612aec73441>
2009-03-30 12:30:54:484375 [INFO]   Found Profile [MRCPv1-Default]
2009-03-30 12:30:54:484375 [INFO]   Add RTSP Session <88c63612aec73441>
2009-03-30 12:30:54:484375 [WARN]   Failed to Handle Message <88c63612aec73441>
2009-03-30 12:30:54:484375 [INFO]   Send RTSP Stream [47 bytes]
RTSP/1.0 500 Internal Server Error
CSeq: 0

Original comment by bayrambo...@gmail.com on 30 Mar 2009 at 9:37

[GoogleCodeExporter]

Hi Bayram,
The resolution for RTSP Describe is just the same as for SIP Options and the
procedure will be the same. First, I'll provide a workaround to respond with 
hard
coded capabilities during the days, which should help you move forward with 
your interop.
Regards,
Arsen.

Original comment by achalo...@gmail.com on 30 Mar 2009 at 11:35

[GoogleCodeExporter]

Hi Arsen,

I appreciate your help. I will be looking forward to the path.

Best wishes,
Bayram

Original comment by bayrambo...@gmail.com on 30 Mar 2009 at 2:22

[GoogleCodeExporter]

Hi Bayram,
I've just committed the fix (r883) to respond to incoming RTSP DESCRIBE, see 
below
http://code.google.com/p/unimrcp/source/detail?r=883

I have no enough time and an actual MRCPv1 client, which sends RTSP DESCRIBE to 
test
against, nevertheless it should work, please try and let me know, if it helps.
Regards,
Arsen.

Original comment by achalo...@gmail.com on 31 Mar 2009 at 9:42

[GoogleCodeExporter]

Hi Arsen,

Thanks for your effort. I will try it and let you know the result. By the way, 
there
is an RTSP client program which can send DESCRIBE and wait for a respond... And 
it is
very easy to use... See the link below:

http://alax.info/blog/343/comment-page-1

Best wishes,
Bayram

Original comment by bayrambo...@gmail.com on 2 Apr 2009 at 11:04

[GoogleCodeExporter]

By the way it is hard to see download link at the page. (Well, it was hard for 
me:-)
So I am just writing it here:

http://alax.info/blog/wp-content/uploads/2007/09/rtspclient-100213.zip

Bayram

Original comment by bayrambo...@gmail.com on 2 Apr 2009 at 11:06

[GoogleCodeExporter]

Hi Arsen,

First good news is: it works cool with the rtspclient program I previously 
wrote about.

Best wishes,
Bayram

Original comment by bayrambo...@gmail.com on 2 Apr 2009 at 12:07

[GoogleCodeExporter]

Hi Bayram,
Well, I've just downloaded that tool, will try it our later, should be indeed 
helpful.

Thanks,
Arsen.

Original comment by achalo...@gmail.com on 2 Apr 2009 at 12:38

[GoogleCodeExporter]

Original comment by achalo...@gmail.com on 3 Apr 2009 at 6:40

• Changed state: Started

[GoogleCodeExporter]

Hi Arsen, I tried, and it works with Avaya IR. (MRCPv1)

But I really coulnt make it work with GVP...(MRCPv2)

Best wishes,
Bayram

Original comment by bayrambo...@gmail.com on 9 Apr 2009 at 12:45

[GoogleCodeExporter]

Hi Bayram,

> I tried, and it works with Avaya IR. (MRCPv1)
Well, can you please add a comment to Interoperability Guide

> But I really coulnt make it work with GVP...(MRCPv2)
I've never tested it myself. I'll try to dig into, if I have GVP installed on 
my side...

Regards,
Arsen.

Original comment by achalo...@gmail.com on 9 Apr 2009 at 1:20

[GoogleCodeExporter]

Just an update to clarify current status of this issue.

Both client and server side resource discovery routines have already been
implemented. However, server side responses are hard coded yet. They should be
constructed based on actual configuration. I'll implement the remaining stuff, 
when
find some time for it.

Original comment by achalo...@gmail.com on 18 Oct 2009 at 1:31

• Added labels: Priority-Low
• Removed labels: Milestone-Release-0.6, Priority-Medium

[GoogleCodeExporter]

Hi,
      I am facing a similar issue with Asterisk and Nuance. Nuance Speech Server 
MRCPv2 accepts L16/97/8000 and Unimrcp was sending L16/96/8000 by default. I 
changed 
it to L16/97/8000. But in either case, it gives the same error at Nuance - code 
error (128) unknown codec and sampling packet size (160). MRCP and SIP message 
flow 
seems to be okay.

- VS

Original comment by vsoffice...@gmail.com on 17 Dec 2009 at 7:27

[GoogleCodeExporter]

Oh, I forgot to mention This is through the ast bridge MRCPSynth using Nuance 
Vocalizer TTS and Nuance Speech Server.

- VS

Original comment by vsoffice...@gmail.com on 17 Dec 2009 at 7:29

[GoogleCodeExporter]

Hi Bayram,

As far the actual submitted issue has been fixed for a while, I'm going to 
change the
status of this issue to fixed too.
In the meantime, as far as the capabilities of the server are still hard coded, 
I've
logged another related issue-61 and will implement it when possible.

If there is anything I have missed, please let me know.

Original comment by achalo...@gmail.com on 17 Jan 2010 at 8:26

• Changed state: Fixed

[GoogleCodeExporter]

Original comment by achalo...@gmail.com on 27 Apr 2010 at 12:01

• Changed state: Verified