Back-to-Back User Agent (B2BUA) Using UniMRCP
craigvan...@gmail.com
We are now interested in creating a "back-to-back user agent" using
the UniMRCP framework.
In case you don't know, a B2BUA is a SIP/MRCP user agent that consists
of both server and client aspects. A "media client" initiates contact
with the B2BUA, and its server aspect accepts the "call", then the
client aspect of the B2BUA sets up a SIP/MRCP connection with the
media resource server (e.g. unimrcpserver). This is all described on
page 88 (Fig. .5.4.3) of Burke's book ("Speech Processing for IP
Networks, Media Resource Control Protocol (MRCP)".
I am trying to figure out how to create a B2BUA out of UniMRCP
elements. We want to use a B2BUA architecture because:
1. We want a separate, light media client that does only SIP/RTP stuff
2. We want to build a MRCP VXML browser that's part of the B2BUA
Because of the way the signaling works in the media client + B2BUA
client + media resource server architecture, it appears that we'll
have to at least rewrite mrcp_sofiasip_server_agent.c and also change
some structures and add a bunch of stuff for the client aspect of
B2BUA. Right now it looks like the the most straightforward approach
is to add the client aspect needed for B2BUA to
mrcp_sofiasip_server_agent.c. My idea is to make the B2BUA behavior
XML configurable, so that mrcp_sofiasip_server_agent.c would do what
it does now unless B2BUA is configured in the XML.
Have you thought about this problem (creating a B2BUA) at all? If you
have any suggestions or ideas on the best way to build this piece we'd
love to hear them.
Craig Vanderborgh
Arsen Chaloyan
It sounds very interesting, please see my comments below.
On Thu, Jan 28, 2010 at 3:52 AM, craigvan...@gmail.com
<craigvan...@gmail.com> wrote:
> Hi Arsen:
>
> We are now interested in creating a "back-to-back user agent" using
> the UniMRCP framework.
>
> In case you don't know, a B2BUA is a SIP/MRCP user agent that consists
> of both server and client aspects. A "media client" initiates contact
> with the B2BUA, and its server aspect accepts the "call", then the
> client aspect of the B2BUA sets up a SIP/MRCP connection with the
> media resource server (e.g. unimrcpserver). This is all described on
> page 88 (Fig. .5.4.3) of Burke's book ("Speech Processing for IP
> Networks, Media Resource Control Protocol (MRCP)".
Unfortunately, I haven't read that book yet, but spending almost 10
years in SIP/RTP and having a small input in MRCP, conceptually it
looks very clear to me.
>
> I am trying to figure out how to create a B2BUA out of UniMRCP
> elements. We want to use a B2BUA architecture because:
>
> 1. We want a separate, light media client that does only SIP/RTP stuff
I guess this can be any generic SIP compliant user agent
> 2. We want to build a MRCP VXML browser that's part of the B2BUA
Exactly what you described in the preamble.
>
> Because of the way the signaling works in the media client + B2BUA
> client + media resource server architecture, it appears that we'll
> have to at least rewrite mrcp_sofiasip_server_agent.c and also change
> some structures and add a bunch of stuff for the client aspect of
> B2BUA. Right now it looks like the the most straightforward approach
> is to add the client aspect needed for B2BUA to
> mrcp_sofiasip_server_agent.c. My idea is to make the B2BUA behavior
> XML configurable, so that mrcp_sofiasip_server_agent.c would do what
> it does now unless B2BUA is configured in the XML.
I though about this initially. As you may have noticed, an abstract
signaling interface I use is much alike SIP. I implemented the same
interface in mrcp_sofiasip client and server agents respectively.
Probably, there should be mrcp_sofiasip_b2b agent next to them. I
can't say it's very easy to do, but from other side, I see no problem,
all the underlying components will be reused and you will get exactly
what you're looking for. Implementation of SDP offer/answer will be
straightforward.
>
> Have you thought about this problem (creating a B2BUA) at all? If you
> have any suggestions or ideas on the best way to build this piece we'd
> love to hear them.
I see clear uses cases and this is an ideal approach for IVRs.
In the meantime, unimrcpclient stack still provides generic API. The
target is telephony platforms with already implemented VoIP or
traditional telephony interfaces, which need an MRCP client stack for
their ASR/TTS interfaces.
>
> Craig Vanderborgh
>
> --
> You received this message because you are subscribed to the Google Groups "UniMRCP" group.
> 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
The author of UniMRCP
http://www.unimrcp.org