Comments (32)
Reported by achaloyan
on 2008-12-12 12:55:16
- Status changed:
Accepted
- Labels added: Type-Defect, Priority-Medium, OpSys-All
from unimrcp.
Reported by achaloyan
on 2009-01-12 20:15:15
- Labels added: Component-Parser, Milestone-Release-0.5
from unimrcp.
Reported by achaloyan
on 2009-01-15 20:39:08
- Status changed:
Started
- Labels added: Component-Client, Component-Server
from unimrcp.
Matthew this issue should be fixed in r741. I wonder if you can verify it on your
side with Aculab client.
Reported by achaloyan
on 2009-01-22 20:43:35
- Status changed:
Fixed
from unimrcp.
Hi, will do. Currently looks like my Aculab client is broken because of system
upgrades and my sys manager is away skiing. Hope to verify the fix within a week or
so.
Reported by matthewaylett
on 2009-01-23 17:26:37
from unimrcp.
Matthew, have you got a chance to verify this issue?
Reported by achaloyan
on 2009-02-25 20:05:56
from unimrcp.
Yes, apologies, I meant to add a comment.
The aculab MRCP v1 server compatibility test now passes. It doesn't work with v2 but
that as you pointed out
that is probably a bug in their client.
I haven't tried a more sophisticated test as yet but the bug caused by splitting the
packets is fixed.
Reported by matthewaylett
on 2009-02-25 22:00:28
from unimrcp.
Really good news!
Now proceeding to MRCPv2 interop. As far as I remember, my assumption was Aculab
didn't support SIP-Trying and expected SIP-OK with SDP. If you are still interested
in and will be able to patch Sofia-SIP, probably I'll try to hack Sofia-SIP not to
send SIP-Trying. Just curious if it helps.
Reported by achaloyan
on 2009-02-26 11:16:55
from unimrcp.
Sure, very happy to try that out.
Reported by matthewaylett
on 2009-02-26 11:27:47
from unimrcp.
Matthew,
I'm attaching the patched nta.c file, the only difference compared to the original
one can be found in nta.c.diff.
Please note the patch was made against Sofia-SIP 1.12.10 and it's just an ugly hack
which ignores all outgoing SIP-Trying responses.
Let me know if it helps.
Reported by achaloyan
on 2009-02-27 08:56:15
- _Attachment: [nta.c](https://storage.googleapis.com/google-code-attachments/unimrcp/issue-7/comment-10/nta.c)_ - _Attachment: [nta.c.diff](https://storage.googleapis.com/google-code-attachments/unimrcp/issue-7/comment-10/nta.c.diff)_
from unimrcp.
Matthew, do you have any updates on this?
Reported by achaloyan
on 2009-03-11 12:30:24
from unimrcp.
MRCPv1 interoperability has been tested and verified recently.
Reported by achaloyan
on 2009-04-15 18:11:00
- Status changed:
Verified
from unimrcp.
There is always the issue.
In my case, I received several messages AND the last message is incomplete (cf. line
1884 and 1937 in the attached file). I haven't the case where I receive only an
incomplete message (but I can try to reproduce that)
I use v0.6.0 and a other client MRCPv1
Reported by amasse.atwork
on 2009-05-20 14:42:45
- _Attachment: [unimrcpserver.log](https://storage.googleapis.com/google-code-attachments/unimrcp/issue-7/comment-13/unimrcpserver.log)_
from unimrcp.
I feel the problem occurs only in case start-line is incomplete/segmented. I'll try
to have a closer look later. Thanks.
Reported by achaloyan
on 2009-05-20 17:03:57
from unimrcp.
Well, actually there is nothing wrong there, but the warning messages in the logs.
Lets analyze the first warning message containing "Cannot parse RTSP start-line"
TEARDOWN rtsp://192.168.1.29:1554/speechrecognizer RTSP/1.0
2009-05-20 15:30:22:240826 [WARN] Cannot parse RTSP start-line
CSeq: 57
Session: 03b2887e46ef3d40
2009-05-20 15:30:23:068951 [NOTICE] Remove Session <03b2887e46ef3d40>
RTSP Message was only partially received, therefore parser originally failed to parse
it. However the message was successfully parsed and further processed as soon as
continuation data was received.
In other words, probably it makes sense to log warning messages only in case parser
finally fails, but not in case continuation is expected.
Reported by achaloyan
on 2009-05-25 06:09:15
from unimrcp.
Ok, I'm going to make new test to validate
Reported by amasse.atwork
on 2009-05-25 09:58:57
from unimrcp.
I found the issue in my case :
If you received an incomplete message like this :
---
TEARDOWN rtsp://192.168.1.29:1554/speechrecognizer RTSP/1.0<CRLF>
CSeq: 592<CRLF>
Session: 39f
---
The apt_text_header_read function does not detect the incomplete "Session:" header
and returns true.
The pair->value.buf contains the truncated "session id" and pair->value.length equals
0 (because no CR and/or LF).
Reported by amasse.atwork
on 2009-05-25 10:42:58
from unimrcp.
Honestly I don't like what apt_text_header_read() returns now. At least it should
return TRUE only in case of valid headers, which end with CRLF and/or LF.
Even though overall processing still should work correct now, as rtsp_header_parse()
returns TRUE only in case the last header is empty. All the headers will be restarted
(parsed again) when the whole message will be finally received.
Reported by achaloyan
on 2009-05-25 11:14:59
from unimrcp.
I made a little modification in the apt_text_header_read() to return TRUE only in case
of valid headers, which end with CRLF and/or LF to continue my test.
I have always an issue. Did you see another issue about that ?
I'm watching the case when the stack receives only the start-line
Reported by amasse.atwork
on 2009-05-26 07:47:31
from unimrcp.
1. Enhancement of apt_text_header_read()
Yesterday I locally modified this stuff to return TRUE only in case header is indeed
valid according to our discussion, and I'll commit the modifications later today.
However it's just an enhancement and overall there should be no issue concerning
message segmentation even with the current trunk.
2. The remaining issue
If you still have an issue, I think it should not relate to message segmentation. Can
you describe what the remaining issue is? How do you observe it?
Reported by achaloyan
on 2009-05-26 09:52:49
from unimrcp.
I don't understand why you say : "there should be no issue concerning message
segmentation."
If we don't modify the apt_text_header_read() function to return TRUE only in case
of
valids hearders :
- which end with CRLF and/or LF
- which contains at least one header
and If you receive an incomplete message which corresponds to the previous cases
(easy to reprodruce with my client), the unimrcpserver server returns "Bad Request".
I re-ran my test with r940 and the modifications correct the "issue".
As I tell you before, I have another issue but I'm trying to find the sequence
Reported by amasse.atwork
on 2009-05-27 12:31:36
from unimrcp.
I found the sequence :
You receive a SETUP in two steps as following :
1.
SETUP rtsp://192.168.1.29:1554/speechrecognizer RTSP/1.0<CR><LF>
CSeq: 10184<CR><LF>
Transport: RTP/AVP;unicast;client_port=54218-54219<CR><LF>
Content-Type: application/sdp<CR><LF>
Content-Length: 258<CR><LF>
<CR>
=> start-line OK
=> headers OK
=> "result == RTSP_STREAM_MESSAGE_TRUNCATED"
2.
<LF>
v=0<CR><LF>
o=telisma 1243428652 1243428652 IN IP4 192.168.1.175<CR><LF>
s=telisma MRCP Client<CR><LF>
c=IN IP4 192.168.1.175<CR><LF>
t=0 0<CR><LF>
m=audio 54218 RTP/AVP 0 8 101<CR><LF>
a=rtpmap:0 pcmu/8000/1<CR><LF>
a=rtpmap:8 pcma/8000/1<CR><LF>
a=rtpmap:101 telephone-event/8000<CR><LF>
a=fmtp:101 0-15<CR><LF>
a=sendonly<CR><LF>
<CR><LF>
=> In the rtsp_parser_run, you process "continuation data" and the buffer contains
:
<LF>
v=0<CR><LF>
o=telisma 1243428652 1243428652 IN IP4 192.168.1.175<CR><LF>
s=telisma MRCP Client<CR><LF>
c=IN IP4 192.168.1.175<CR><LF>
t=0 0<CR><LF>
m=audio 54218 RTP/AVP 0 8 101<CR><LF>
a=rtpmap:0 pcmu/8000/1<CR><LF>
a=rtpmap:8 pcma/8000/1<CR><LF>
a=rtpmap:101 telephone-event/8000<CR><LF>
a=fmtp:101 0-15<CR><LF>
a=sendonly<CR><LF>
<CR><NUL>
=> With this buffer the sdp_session function in mrcp_unirtsp_sdp.c return NULL then
mrcp_descriptor_generate_by_sdp_session function generates a coredump
Reported by amasse.atwork
on 2009-05-27 14:21:06
from unimrcp.
Lines are normally terminated by CRLF, but receivers should be prepared to interpret
CR and/or LF as line terminators too.
Thus
Content-Length: 258<CR><LF>
<CR>
=> start-line OK
=> headers OK
=> "result == RTSP_STREAM_MESSAGE_TRUNCATED"
looks correct, but the continuation <LF> is really fuzzy in this case.
The only solution I see at the moment is to skip preceding <LF> from message content
/ if any.
Regarding the segfault: SDP parser may fail in several cases, and this cases should
be still processed gracefully. Must be fixed.
Reported by achaloyan
on 2009-05-27 15:59:50
from unimrcp.
Reply to comment 10.
We have done some tests on aculab Prosody S.
Aculab mrcp1 --> unimrcp : working great
Aculab mrcp2 --> unimrcp : seems that unimrcp answer to the SDP invitation with a
Content-Length = 0 in the following SDP block.
Applying your patch fix the problem.
Do you know if this patch may have bad behaviour with other platform than aculab?
Is there an other way to be compatible with Aculab (except with a fix by aculab)?
Reported by jeanmichel.reghem
on 2009-05-29 07:42:49
from unimrcp.
Jan-Michel,
Thanks for the update.
Actually SIP TRYING contains no SDP and content-length of that message is always
0. You confirm that my patch fixes the issue, it means Aculab indeed doesn't support
optional SIP TRYING and is expected SIP OK.
The patch I introduced is just a hack, which prevents Sofia sending TRYING. However
there is a better solution. Just recently someone has submitted another patch to
Sofia's dev list which makes TRYING configurable from user space. Hopefully this
patch will be included into Sofia's tree. Then I'll provide a configuration option
in
unimrcpsever.xml to trigger this behviour.
From other hand, I hope Aculab sooner or later will support SIP TRYING to fully comply
with SIP RFC3261.
Reported by achaloyan
on 2009-05-29 09:27:05
from unimrcp.
Here there are my modifications to support all uncomplete messages :
1. First character of the body part
-> Suppress the CR or LF is exist
In the rtsp_message_body_read() function (rtsp_stream.c file)
---
apr_size_t required_length = message->header.content_length - message->body.length;
if (message->body.length == 0 && (*stream->pos == APT_TOKEN_LF || *stream->pos ==
APT_TOKEN_CR))
{
stream->pos++;
stream_length--;
}
if(required_length > stream_length) {
---
2. Manage all uncomplete cases. I beleive your apt_text_stream_scroll() function is
not correct (I supposs ;) ):
-> New version of the apt_text_stream_scroll() function (apt_text_stream.c file)
APT_DECLARE(apt_bool_t) apt_text_stream_scroll(apt_text_stream_t *stream)
{
apr_size_t scroll_length = (stream->text.length + stream->text.buf) - stream-
>pos;
if(scroll_length == stream->text.length) {
stream->pos = stream->text.buf + scroll_length;
return FALSE;
}
memmove(stream->text.buf,stream->pos,scroll_length);
stream->text.length = scroll_length;
stream->text.buf[scroll_length]='\0';
stream->pos = stream->text.buf + scroll_length;
return TRUE;
}
-> return of the apt_text_stream_scroll() function (rstp_stream.c file)
if(apt_text_stream_scroll(stream) == TRUE) {
apt_log(APT_LOG_MARK,APT_PRIO_INFO,"Scroll RTSP Stream TRUE [%d]",stream->pos
- stream->text.buf);
}
else {
// do nothing
}
Reported by amasse.atwork
on 2009-05-29 15:46:32
from unimrcp.
Anthony, thanks for considering not only reporting issues, but also trying to fix them.
1. Actually <CR> | <LF> segmentation may occur not only between header and body, but
also between header fields or even between messages which contain no body. I'll try
to completely address these cases during the days.
2. I consider apt_text_stream_scroll() doing what it's intended to do: scroll buffer,
prepare for the next read/parse in case message is only partially parsed with current
attempt.
Reported by achaloyan
on 2009-06-01 07:45:41
from unimrcp.
Arsen,
1. My current test allows to test all segmentations (the SETUP length is 248 bytes
in
my test, then I run sequentially 248 calls with all the possible segmentations. I
also run a test with several call and random segmentation).
2. About the apt_text_stream_scroll() function, I beleive to understand what it's
intended to do but are you sure about your memmove "definition" ? This C function
does not move (or scroll) memory. It's only make a copy of n bytes with overlap
protection. The third parameter (of the memmove) must be the lentgh of the bytes to
move (but not the length of the bytes to scroll).
I hope to be wake up when I say that ;)
Reported by amasse.atwork
on 2009-06-02 08:56:26
from unimrcp.
Anthony,
1. Just great, however I'm afraid only one case still remains
TEARDOWN rtsp://192.168.0.1:1554/media/speechsynthesizer RTSP/1.0
CSeq: 3
Session: 50ec40b84b3efb49
<CR>
---segmentation---
<LF>TEARDOWN rtsp://192.168.0.1:1554/media/speechsynthesizer RTSP/1.0
CSeq: 3
Session: 50ec40b84b3efb98
<CR><LF>
The probability it happens is less than 0.01%, but it's still possible.
I'll try to address it later today.
2. My apologies, you are completely right here. I could be blind or just a bit tired.
Thanks for the catch. Fixed in the trunk.
Reported by achaloyan
on 2009-06-03 13:40:39
from unimrcp.
Anthony,
1. Done in r962, please have a look and run your test cases again if needed.
Reported by achaloyan
on 2009-06-03 18:20:07
from unimrcp.
Arsen,
2. There is always an issue :
your code :
if(!remaining_length || remaining_length == stream->text.length) {
stream->pos = stream->text.buf + remaining_length;
return FALSE;
}
I believe the good solution (tested) is :
if(!remaining_length || remaining_length == stream->text.length) {
stream->pos = stream->text.buf + remaining_length;
return FALSE;
}
or
if(remaining_length == stream->text.length) {
stream->pos = stream->text.buf + remaining_length;
return FALSE;
}
because if (remaining_length == 0) then (remaining_length == stream->text.length)
Reported by amasse.atwork
on 2009-06-04 08:44:12
from unimrcp.
Anthony,
2. Hopefully finally fixed in r963. Thanks!
Reported by achaloyan
on 2009-06-04 13:18:33
from unimrcp.
Related Issues (20)
- Possibility custom response in recog plugin HOT 1
- UniMRCP Yandex Plugin SR Case insensitive HOT 1
- unimrcp crash when timer reschedule HOT 1
- Completion-Cause: 002 no-input-timeout HOT 1
- Why there are so many temporary files in code repository
- No reply Local SDP after running for a while HOT 1
- how to get sip informations from unimrcp HOT 1
- the "sip-session-expires" trigger early HOT 2
- How to build with cmake HOT 1
- Write a concurrent client HOT 1
- how to develop myself tts plugin,someone knows to do that? HOT 1
- Re-INVITE may causes the session keep forever and will not be free HOT 1
- Why speech_complete_timeout is set as mpf_activity_detector_silence_timeout? HOT 1
- Is unimrcp support process the MRCP Signal via multi-thread?
- APR library has security vulnerabilities HOT 1
- Getting No NLSML data available on speech recognition input validation [AzureSR]
- Unimrcpclient does not respect the codecs
- `apr_pool_mutex_set' HOT 1
- Segmentation fault mrcp_start_line_init (message/src/mrcp_start_line.c:321)
- Redacted
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from unimrcp.