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

John Todd jtodd at loligo.com
Fri Sep 19 11:29:54 MST 2003


>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



More information about the asterisk-dev mailing list