[Asterisk-Dev] dump_user_user() and other UUI questions

Fri Sep 19 15:15:30 MST 2003

Hi John,

Thank you very much for the guidance and the references.  I'm glad to hear
that UUI in SIP is being thought about by others as well.  I'm also
working with VXML platforms, so it makes sense that Nuance would want
this.  In my experience, you sort of get a blank stare when you talk to
commerical PRI <-> VoIP gateway providers for this, so this seems like a
cool opportunity for * to provide something that you can't buy anywhere
else.

I'll take a look at II digits as well, since these sort of go together
with UUI.  If anyone wants to at least see what UUI they're receiving off
of a PRI circuit, here's the basic patch:

--- libpri/q931.c       Tue Sep 16 14:29:21 2003
+++ libpri_20030918/q931.c      Thu Sep 18 15:42:44 2003
@@ -830,10 +830,11 @@

 static void dump_user_user(q931_ie *ie, int len, char prefix)
 {
-
+       char cnum[256];
+       q931_get_number(cnum, sizeof(cnum), ie->data + 1, len - 3);
+       pri_message("%c User-User Information (len=%2d) ['%s']\n", prefix,
len, cnum);
 }

I'll submit a better patch that deals with non-printing characters and
such via the mantis interface.

Cheers,
tony

On Fri, 19 Sep 2003, John Todd wrote:

> >I've written a (very minor) patch for libpri that prints out the UUI
> >information received during call setup, which I will submit via the bugs
> >interface.  Before I submit it, I was wondering if anyone had any feedback
> >on presentation of the UUI string.  Currently, I'm dumping it as a string,
> >but I know that the field can contain most anything.  (One of our partners
> >sends us what is essentially a packed data structure, full of all kinds of
> >non-printable characters.)  Do people think it's worthwhile to run the
> >string through isprint(), and/or dump the hex of the UUI alongside the
> >string?
> >
> >I'm also working on transmit_user_user(), since I need * to propagate UUI
> >information when it acts as a gateway.  This appears to be much more
> >complex than just a function to tack the IE on to the end of the setup
> >message, because the change cascades back through q931_setup() to
> >pri_call().  To give you an idea of where I'm going with this, intially,
> >my need is merely to pass UUI information between calls over PRI trunks,
> >so the code would be restricted to PRI -> PRI transfers/calls.  However,
> >eventually I need to be able to pass this information to/from a SIP call,
> >so that I can gateway ISDN inbound calls to a SIP-based IVR, and then
> >REFER them back through the gateway to an ACD (at the end of another PRI
> >trunk).
> >
> >Assuming that there will be an applicable IETF draft on how to pass UUI
> >info via SIP, is this the sort of modification that would be considered
> >for inclusion in *?
> >
> >Thanks,
> >tony
> >
> >   tony at mancill.com     | 'If Bill Gates had a dime
> >http://www.debian.org  |    for every time Windows crashed...
> >            (anonymous) |       ... Oh wait a minute, he already does...'
>
> Tony -
>    Yes, I think that would be a useful addition.  I haven't personally
> run across any systems that implement UUI yet, but I would see how it
> could be very useful if your vendor provides it or at least passes it
> through their network between two of your Asterisk PRI-enabled
> endpoints.
>
>    As a matter of fact, an issue that was related to this (but working
> with IAX2) was discussed yesterday by Lele Forzani.  He was asking
> how he could transfer an original accountcode when an IAX2 call was
> 'released' to a different Asterisk server.  It seems that UUI would
> allow that transfer of account code (or anything else) for IAX2 or
> PRI calls that are 'released' between two Asterisk servers.
>
>    A method to set UUI and a method to read UUI would be optimal, of
> course.  Having that method accessible through the Dialplan and AGI
> scripts would be desired.  A generic method for setting this would
> also be optimal, using an abstracted layer that doesn't care about
> what channel type is being used, so eventually this could be built
> into IAX2, H323, MGCP, etc.  A little research finds that there is
> partial work already done on this for SIP.
>
>
> http://lists.digium.com/pipermail/asterisk-users/2003-June/014123.html
> states that there are header types of "uui=" methods that have been
> seen in SIP headers from at least one vendor (Nuance) and that
> Asterisk already has the ability to embed these (arbitrary)
> additional fields into a SIP header with the slightly mis-named
> "VXML-URL" variable.
>
>    All you need to do is make things work with q.931 signalling, and
> then also handle receiving such additional headers from SIP requests
> and exposing them to the dialplan/AGI.  Discussion with Mark on how
> to insert this type of information into IAX2 would be required if you
> wanted to extend that channel type to support this method (which
> might be very useful, and I like the sound of that the more I think
> about it.)
>
>    I would suggest submitting a feature request to the
> http://bugs.digium.com/ interface, and then populating it with your
> existing patches as well as updating it as you make progress, so that
> others can avoid duplicating your work and may also offer comments.
> To implement this in full compliance with the AT&T specification
> seems to be complex, but that perhaps is only due to the amount of
> stuff that you should _not_ do according to the standard.  :-)
>
> JT
>
>
>
> References:
>
> Tellme.com's notes on UUI for their proprietary system:
> http://studio.tellme.com/advnet/uui-p.html
>
>
>  From http://www.att.com/cpetesting/faq.html#i10
> What is User-to-User Information (UUI) exchange?
> User-to User-Information exchange is a means by which two ISDN users
> can  exchange packet-oriented data. The purpose and use of that data
> is left  to the user's application. For example, a call center
> operator may redirect  an incoming call to another party (such as a
> billing representative), using  a B channel for the circuit-switched
> connection, and at the same time use  the D channel to send
> information about that call (for example, the caller's  account
> number).  The types of UUI capabilities are:
>
> Message Associated User-to-User Information (MA UUI) - allows two
> users  to exchange data in the call control messages exchanged during
> call setup  and/or disconnect.
> Call Associated Temporary Signaling Connections - allows two users to
> exchange data in conjunction with a circuit-switched connection. The
> data  exchange takes place during or after the call setup request.
> Non-Call Associated Temporary Signaling Connections - allows two
> users  to exchange data without setting up a circuit-switched
> connection.
>
> For detailed information about User-to-User Information, see AT&T
> Technical Reference (TR) 41459.
>
> AT&T Technical Refernce 41459:
> http://www.att.com/cpetesting/pdf/tr41459_99.pdf

