Using unimrcp framework to write a MRCP B2B/Relay/proxy
Glayal Laurent
Hello,
I would like your POV on the following ideas.
- Currently some ASR/TTS providers' mrcp servers do not support CDRs nor
load balancing nor failover
- client applications can interact with MRCP TTS server, but some
applications may only interact with an MRCP version (MRCPv1 or MRCPv2) which is
not the one in use in MRCP TTS Server
- some mrcp servers do not properly set up their rtp/endpoints stack if
all source/dest @IP are not the same (for ex. if SIP ip address is not the same
as the RTP ip address)
Do you thing it would be possible to use unimrcp libraries to write a
server acting as a proxy/relay/b2b between client applications and final mrcp
server
[Client]======[Mrcp Server Relay]=====[FinalMRCP Server]
The MRCP Server Relay would have to :
- forward requests from client to final server by modifying the
endpoints addresses for signaling an media
- write CDR to track requests (containing for ex. some parts of
information contained in MRCP messages and events)
- shadow the real number of final MRCP server and load balance requests
to these servers
- failover on another final server if connection to one can't be initiated
- process MRCPv1 Requests on one side and translate to MRCPv2 requests
to the other side
The troubles I see
- when relaying media the server has to forward packets
without rtp stack (in order to reduce latency and overhead on the host), it has
to allocate rtp endpoints on 'each' side and change IP adresses in requests
- when relaying rtp and rtcp without rtp/rtcp stack some
rtcp reports containing adresses or hostnames may be wrong.
- some providers use proprietary headers for tuning ASR,
these headers must be forwarded untouched.
- is it possible to really convert MRCPv1 into MRCPv2
requests ?
I've seen some discussions about using opensips to act as a proxy, but
this solution can't adapt MRCPv1/MRCPv2 requests, and a parser for MRCP
requests have to be written to generate CDRs.
Thank you.
Regards
Laurent
Arsen Chaloyan
On Fri, Aug 5, 2011 at 5:12 AM, Glayal Laurent <spgl...@gmail.com> wrote:
> Hello,
> I would like your POV on the following ideas.
I may be late but will share my point of view with pleasure.
>
> - Currently some ASR/TTS providers' mrcp servers do not support CDRs nor
> load balancing nor failover
I'd say there is no complete solution for this purpose.
> - client applications can interact with MRCP TTS server, but some
> applications may only interact with an MRCP version (MRCPv1 or MRCPv2) which
> is not the one in use in MRCP TTS Server
understood.
> - some mrcp servers do not properly set up their rtp/endpoints stack if
> all source/dest @IP are not the same (for ex. if SIP ip address is not the
> same as the RTP ip address)
yes.
>
> Do you thing it would be possible to use unimrcp libraries to write a
> server acting as a proxy/relay/b2b between client applications and final
> mrcp server
>
> [Client]======[Mrcp Server Relay]=====[FinalMRCP Server]
It'd be possible. For a simple B2BUA, almost all the components are available.
>
> The MRCP Server Relay would have to :
> - forward requests from client to final server by modifying the endpoints
> addresses for signaling an media
I see several modes of operation here:
1) B2BUA
There will be two call/session legs. The B2BUA will act as UAS for the
client and as UAC for the server. The B2BUA may even translate the
legs, let's say, from RTSP/MRCPv1 to SIP/MRCPv2. The RTP stream should
be relayed from the client to the server through the B2BUA without
entering the RTP stack, unless the capabilities of the client and the
server don't match and a transcoding is required.
2) Stateful Proxy Server.
The proxy server will stay in the signaling path from call/session
origination to termination forwarding the session management requests
from the client to server. However, the MRCP signaling and the RTP
streams may go straight from the client to the server. As opposite to
the B2BUA, the proxy server would consume less bandwidth and other
resources in general. It's still possible to do a load balancing and
fail-over on the session management level. However, this would work
only for SIP/MRCPv2.
> - write CDR to track requests (containing for ex. some parts of
> information contained in MRCP messages and events)
ok
> - shadow the real number of final MRCP server and load balance requests to
> these servers
exactly
> - failover on another final server if connection to one can't be initiated
quite useful
> - process MRCPv1 Requests on one side and translate to MRCPv2 requests to
> the other side
The RTSP signaling can be one to one mapped to the SIP signaling, of
course, in the MRCP context not in general. However, vice-versa (SIP
-> RTSP) is not always possible.
Unfortunately, there is a difference between MRCP headers of v1 and v2
too. Anyway, translation from v1 to v2 is possible, v2 to v1 - not
always.
>
> The troubles I see
> - when relaying media the server has to forward packets without rtp
> stack (in order to reduce latency and overhead on the host), it has to
> allocate rtp endpoints on 'each' side and change IP adresses in requests
exactly
> - when relaying rtp and rtcp without rtp/rtcp stack some rtcp reports
> containing adresses or hostnames may be wrong.
agree, the RTCP packets cannot be just relayed. The IP addresses used
in some of the reports should be rewritten, if anybody cares, of
course.
> - some providers use proprietary headers for tuning ASR, these headers
> must be forwarded untouched.
What headers do you mean: SIP/RTSP or MRCP ones?
> - is it possible to really convert MRCPv1 into MRCPv2 requests ?
brief answer is yes.
>
> I've seen some discussions about using opensips to act as a proxy, but
> this solution can't adapt MRCPv1/MRCPv2 requests, and a parser for MRCP
> requests have to be written to generate CDRs.
right.
>
> Thank you.
> Regards
>
> Laurent
Regards,
>
> --
> You received this message because you are subscribed to the Google Groups
> "UniMRCP" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/unimrcp/-/Lxk93RS8zJ0J.
> To post to this group, send email to uni...@googlegroups.com.
> To unsubscribe from this group, send email to
> unimrcp+u...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/unimrcp?hl=en.
>
--
Arsen Chaloyan
Author of UniMRCP
http://www.unimrcp.org
Randy Olson
balancing works well, but the failover is a little more of a trick
that I'm still working through issues. It works well if the server is
out of licenses, but not so well for a failed server. The main
problem is that you have to recognize and react much more quickly to a
missing server than you would for a telephone call. Typically you can
go through a standard 30 second retry cycle before you fail a voice
call, but you can't typically wait much more than a second for TTS/
Speech Rec. I'm going to look at whether my speech servers will
respond to a SIP OPTIONS ping.
Most proxy servers have some capability of capturing CDRs of the
event variety (ie begin, end, etc.), but if you need a single CDR that
encompasses the whole session you will either need to get that via a
backend process from the event records, or find a proxy that is
stateful across the whole call dialog which isn't very common.
Randy Olson
Glayal Laurent
Thanks a lot for all your answers
> - some providers use proprietary headers for tuning ASR, these headers
> must be forwarded untouched.
What headers do you mean: SIP/RTSP or MRCP ones?
Both, but for a different purpose,
- most ASR platforms can be tuned using proprietary MRCP headers
- some IVR platform can send additionnal information in SIP messages that can be usefull to track requests when generating CDRs. These headers are not used to tune ASR.
Thank you.
Regards.
Arsen Chaloyan
Indeed, the default INVITE transaction timeout (SIP Timer B = 64*T1 =
32 seconds) is not acceptable for ASR/TTS sessions. I mean the
failover case you described when the server is down or doesn't respond
to incoming SIP messages. So, I think you can decrease that timeout
from the proxy. Please check the link below for the available SIP
timers and timer based failovers
http://kamailio.net/docs/modules/1.5.x/tm.html#id2505495
Depending on the version of OpenSER/Kamailio you use, the supported
timers may slightly differ, but the concept is the same.
Hope this helps.