Posted: Fri Sep 19, 2003 4:51 pm Post subject: [Asterisk-Dev] dump_user_user() and other UUI questions
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@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...'
Posted: Fri Sep 19, 2003 6:29 pm Post subject: [Asterisk-Dev] dump_user_user() and other UUI questions
Quote:
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@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. :-)
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.
Posted: Fri Sep 19, 2003 10:15 pm Post subject: [Asterisk-Dev] dump_user_user() and other UUI questions
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:
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:
Quote:
>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@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. :-)
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.
Posted: Sat Sep 20, 2003 12:14 am Post subject: [Asterisk-Dev] dump_user_user() and other UUI questions
[comments in-line]
At 3:15 PM -0700 9/19/03, tony mancill wrote:
Quote:
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.
There are many features that * has that you can't buy anywhere else. ;-)
Quote:
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:
I'll submit a better patch that deals with non-printing characters and
such via the mantis interface.
[snip]
I await your patch, and I would also be interested in any further
work you could do towards making this a set-able option for outbound
PRI calls as well. This could be a "secret" method of communications
between two previously unrelated Asterisk end nodes across the PSTN
if the carrier will transport the data unchanged. Data that could
possibly be stored in there might be
"iax2://3023321212@some.host.com/" or even just a pointer to an ENUM
entry. Each end could then hang up (not answer?) the PRI setup
message, and then re-path the call out through IP.
...boy, would AT&T be pissed. He he he.
That is just one of many possible uses and data formats would need a
lot more thought, but it's certainly one to think about. I don't
have time to look at the spec in detail, but it sounds like it might
be workable. Can anyone speak to this who knows the q.931 spec and
practical usages in more detail?
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum