Response Codes

[GoogleCodeExporter]

To clarify the terms: I think that what is called "MRCP signaling" in the 
code comments, refers generically to SIP or RTSP, respectively. Am I wrong 
about this?

It would be nice if recog_application_on_channel_add() allowed the access 
to the SIP response codes received from Sofia, in case the the SIP session 
establishment failed. I see that Sofia returns such codes (408-timeout, or 
503 if there are no server licenses, for instance). Of course, the MRCPv2 
codes may have to be reconciled with MRCPv1 codes, something which you 
already do probably in some fashion.

The response codes may provide useful information to the user application. 
There may be a problem though: some of the SIP response codes coincide 
numerically with some of the MRCP responses (bad choice made by the MRCP 
designers).

Original issue reported on code.google.com by Curat...@gmail.com on 28 May 2010 at 1:18

[GoogleCodeExporter]

Hi Vlad,

Sorry for the delay in responding. I thought I had already provided a comment 
on this.

>I think that what is called "MRCP signaling" in the code comments, refers
generically to SIP or RTSP, respectively.

Yes, and a better name would be "MRCP session management" as the term signaling 
is
more generic one.

> Of course, the MRCPv2 codes may have to be reconciled with MRCPv1 codes, 
something
which you already do probably in some fashion.

Yes, the response codes are almost similar. Though almost doesn't mean always.

> The response codes may provide useful information to the user application. 

I agree that it should be useful. However, the application API is protocol 
version
independent currently. Thus, I cannot use the SIP response codes in the generic 
API.

Anyway, I'll have to analyze those response codes more carefully, when I start 
the
implementation of the "fail-over" functionality.

More to come soon. Thoughts are welcome in the meantime.

Thanks,
Arsen

Original comment by achalo...@gmail.com on 2 Jun 2010 at 8:56

• Added labels: Component-Client

[GoogleCodeExporter]

Hi Arsen,

I have come across this same issue testing with Nuance’s MRCPv2 Speech 
Server.  It will return SIP 503 when no licenses are available.

If the SIP response is immediate (< 1 second) I would like to retry another 
server.  Knowing the exact cause (or a more granular generic mapping ) would be 
helpful to the client user application.

Have you come up with an approach and timeline for this?

Thank you,
-Rick

Original comment by rjj...@gmail.com on 14 Mar 2013 at 4:40

[GoogleCodeExporter]

Hi Rick,

I wanted to address this issue long time ago but it has undeservedly stayed 
unattended until today.

In r1906, I've added a new client API function which allows to retrieve the 
response code of a session management request (add channel, remove channel, 
etc). 

It was clear how to retrieve the response code from the underlying SIP (MRCPv2) 
and/or RTSP (MRCPv1) stacks. The question was how to make the response code 
available to the client user application. It wouldn't have been wise to change 
the existing API for such a minor but still valuable addition. That's why I 
decided to add a new function such as:

MRCP_DECLARE(int) mrcp_application_session_response_code_get(const 
mrcp_session_t *session);

This function is supposed to be called by a client user application after it 
receives a response to the session management request. In other words, when the 
corresponding handler is invoked.

Note: the function shouldn't be called if there is an ongoing request.

Original comment by achalo...@gmail.com on 22 Mar 2013 at 12:24

• Changed state: Fixed
• Added labels: Milestone-Release-1.1

[GoogleCodeExporter]

Hi Arsen,

I have synced up to trunk r1912 and dependencies 1.1.3 to test the r1906 
enhancement.  Unfortunately the change does not appear to satisfy what I am 
trying to accomplish.

When the speech server returns SIP 503, the function 
‘mrcp_sofia_on_session_terminate’ is called however the SIP status does not 
get copied to the newly implemented ‘descriptor->response_code’.  
Accordingly when the ‘on_channel_add’ handler bubbles up to my client 
application, the call to ‘mrcp_application_session_response_code_get’ 
returns 0 rather than the 503.

Additionally, by implementing the response_code in the  
‘mrcp_session_descriptor_t’ an SDP dependency has been created.  Of course 
there is no SDP sub message included with SIP 5xx messages therefore additional 
design consideration may be required to provide unconditional access to the SIP 
response code.

I appreciate you looking into this and apologize if there is some 
misunderstanding,
Rick

Original comment by rjj...@gmail.com on 23 Mar 2013 at 5:30

[GoogleCodeExporter]

https://groups.google.com/forum/?fromgroups=#!topic/unimrcp/v9xmAj9WCmc

Original comment by achalo...@gmail.com on 26 Mar 2013 at 9:01

• Changed state: Started
• Added labels: Milestone-Release-1.2, Priority-Medium
• Removed labels: Milestone-Release-1.1, Priority-Low

[GoogleCodeExporter]

Hi Rick,

This issue should have finally been addressed in r1946. Please give it another 
try. Thanks.

Original comment by achalo...@gmail.com on 4 Apr 2013 at 9:08

• Changed state: Fixed

[GoogleCodeExporter]

Hi Arsen,

The latest change does indeed provide unconditional access to the SIP response 
code.  Thank you for the quick turnaround.

Along with the enhancement I noticed the on_channel_add mrcp_sig_status_code_e 
changed from MRCP_SIG_STATUS_CODE_TERMINATE to MRCP_SIG_STATUS_CODE_FAILURE.  
Personally I felt the terminate status was more appropriate and in line with 
SIP RFC 3261 “All early dialogs are considered terminated upon reception of 
the non-2xx final response”.  I realize UniMRCP supports both versions 1 and 
2 and if that has something to do with the change I can accept that.

Thank you for your contributions, great project!
Rick

Original comment by rjj...@gmail.com on 5 Apr 2013 at 7:45

[GoogleCodeExporter]

Thank you, Rick!

Agreed with your note on the status code. Reverted that behavior in r1948.

Original comment by achalo...@gmail.com on 6 Apr 2013 at 2:54