Stream voice to Asterisk

Package: dpkg-cross
Version: 1.28
Severity: normal

I'm trying to install
linux-headers-2.6.17-1-nslu2_2.6.17-2_arm.deb
with dpkg-cross. The original deb contains lots of symlinks
such as:

lrwxrwxrwx root/root         0 2006-07-01 18:34
./usr/src/linux-headers-2.6.17-1-nslu2/arch/arm/kernel/Makef
ile ->
../../../../linux-headers-2.6.17-1/arch/arm/kernel/Makefile

~$ dpkg -c linux-headers-2.6.17-1-nslu2_2.6.17-2_arm.deb |
grep -- "->"|wc
    973    7784  165399

These are critical for correct operation. But they are not
in the converted deb:

~$ dpkg -c
linux-headers-2.6.17-1-nslu2-arm-cross_2.6.17-2_all.deb |
grep -- "->"
lrwxrwxrwx root/root         0 2006-07-20 08:22
./usr/arm-linux-gnu/lib/modules/2.6.17-1-nslu2/build ->
../../../src/linux-headers-2.6.17-1-nslu2
lrwxrwxrwx root/root         0 2006-07-20 08:22
./usr/arm-linux-gnu/src/linux-headers-2.6.17-1-nslu2/include
/asm -> asm-arm

-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500,
'stable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16-2-686
Locale: LANG=sv_SE.UTF-8, LC_CTYPE=sv_SE.UTF-8
(charmap=UTF-8)

Versions of packages dpkg-cross depends on:
ii  binutils                      2.17-1     The GNU
assembler, linker and bina
ii  dpkg-dev                      1.13.21    package
building tools for Debian
ii  file                          4.17-2     Determines file
type using "magic"

dpkg-cross recommends no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-embedded-REQUESTlists.debian.org
with a subject of "unsubscribe". Trouble?
Contact listmasterlists.debian.org

On Thursday 27 July 2006 14:00, John Todd wrote:
> At 12:48 PM -0500 7/27/06, Tilghman Lesher wrote:
> >On Thursday 27 July 2006 11:55, Douglas Garstang
wrote:
> >>  Found this thread on this list, from almost
three years ago.
> >>
> >  > http://lists.digium.com/pipermail/asterisk-dev/2
003-December/002
> >  >398.html
> >>
> >>  It talks about passing variables in IAX2.
> >>
> >>  Was any of it ever implemented?
> >
> >No, and it probably won't be, until it gets past
the "wouldn't it be
> >cool if..." stage.  Not to mention that
debugging a session where
> >the variables could change midexecution in the
dialplan would be
> >pure hell.
>
> Can you explain a bit more how the variables might
change
> mid-execution?  I don't quite follow this, but I
perhaps had some
> assumptions that were built into my original idea that
I did not make
> obvious.  Let me put a few of them out here for
discussion:
>
>   - any variables with "outbound." as a
prefix would be sent with
>       any Dial execution, and could not be altered once
the Dial
>       has been run.  In other words: variables would be
transmitted
>       only once to the remote server, during the call
setup and could
>       and should not change during the call (though
that does sound
>       like it could be done with both SIP and IAX2, it
seems too
>       complex to tackle for a first swing at such
variable
> transport.)

For such a restriction, there are less issues, but with such
a
restriction, you'll also lose quite a bit of what people
would like to
be able to do.  Additionally, there's no advantage to this
system over
simply encoding your variables directly into the Dial
string.

>    - any received variables would not change once the
dialplan
> started executing on the receiving machine, so
variables would not
> change once the call setup request had been accepted by
the remote
> machine.  In other words, "inbound."
prefixed variables would never
> change during the life of a call.
>
> The good news is that since I wrote that original post
several years
> ago, there is now the ability to parse SIP headers
within the
> dialplan, so that with a little creative string
manipulation it is
> possible to move variables between two systems with SIP
headers.  Now
> the only thing remaining is the ability to do the same
thing with
> IAX2.  This seems a bit backwards - Asterisk seems like
it should
> easily move variables around in it's native protocol
instead of in
> SIP, but that's the way it is until someone comes up
with the code.

I suppose you could hack in variables into the SIP headers,
but that's
not really what that interface is for.

-- 
Tilghman
_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Comments in-line.

On 29 Jul 2006, at 01:48, John Todd wrote:

> At 1:03 PM -0500 7/28/06, Tilghman Lesher wrote:
>> On Friday 28 July 2006 12:12, Douglas Garstang
wrote:
>>> what's the length limitation on the called
number?
>>
>> In terms of the dialplan, 80.  In terms of the IAX2
protocol, 255.
>>
>> --
>> Tilghman
>
> This message is a summary of some of the comments made
in this  
> thread; apologies for not including all forwards - it
was a bit messy.
>
>  - I don't know if there was any particular
"use" for the SIP  
> header read/write routines; saying that inclusion of
variables in  
> there wasn't part of it's intention might be an
overstatement of  
> intent.  I think they can be used for whatever the
administrator  
> wants; variable transfer from server to server seems
like a totally  
> reasonable and SIP-consistent method.
>
>
>  - I would disagree that using IAX2 to transport
variables in a  
> "static" fashion is equivalent to putting
the variables into the  
> dialed number sequence.  Firstly, you've hit upon an
obvious limit  
> in having only 255 characters, which is a serious
problem to any  
> robust transfer of values across the channel. 
Secondly, ordering  
> variables inside of such a string is ugly and prone to
fragility.   
> Thirdly, it would require that the remote server is
ALWAYS one that  
> can handle such garbled string dial requests, since an
unsuspecting  
> server would surely fail on a dial pattern of such
massive  
> length.   Lastly, it is overly onerous to the dialplan 

> administrator who has to write a fairly obtuse section
of string- 
> chopping code to make things work.  It seems that this
could fairly  
> elegantly be "hidden" in the internals of
Asterisk to let the  
> administrator simply use the values instead of parsing
them as well.
>
> There are often concessions within Asterisk that make
life easier  
> for the administrator, and putting  variables inside of
IAX2 does  
> not seem to only have those benefits but many others as
well.

I agree that we should formalise the method and not leave it
up to  
the dialplan to chop the strings.

When I said we could use url style values in the dial plan,
I was  
thinking of having it work like this:

dial(IAX2/mexuar/3?customer="JoeBob")

Asterisk would strip ?customer="JoeBob" from the
dial string before  
sending it.
It would then add an (optional) InfoElement to the NEW frame
with the  
variable name and value in it

The receiving IAX would either ignore the extra InfoElement,
or if it  
supported it, it would
check to see if the variable existed, if not, create it and
assign  
the value.
(pre existing asterisks will ignore IEs they don't
understand)

>
> While I agree that setting of variables on the
initiation of calls  
> (and not dynamically changing them as the call
progresses) is of  
> limited use, I would say that it is of enough use that
it merits  
> attention from any enterprising programmer who wishes
to fill an  
> uneventful Saturday afternoon (and Sunday, and
Monday...) with good  
> coding.  Once the ability exists in a start-of-call
fashion,  
> perhaps demand and interest will push others to solve
the problems  
> surrounding dynamic variable transmission.  "Do
not let perfection  
> be the enemy of 'good enough'."
>
>
>  - The suggestion that variables can be set on
conclusion of the  
> call is a good idea, and I had not thought of it.  It
does not seem  
> to be much more complex than the setting of
start-of-call  
> variables, as long as they are transmitted back to the
originating  
> server only on disconnection or redirection of the
signalling  
> stream (note I didn't say "media stream").
>
> Skeletal example (IAX configs omitted for brevity):
>
> server1:
> [foo]
> exten =>
123,1,Set(outbound.customer="JoeBob")
> exten => 123,n,NoOp(${inbound.result})
> exten => 123,n,Dial(IAX2/server1server2/main)
> exten => 123,n,NoOp(${inbound.result})
> exten => 123,n,Hangup
>
> server2:
> [bar]
> exten => main,1,NoOp(${inbound.customer})
> exten => main,n,Set(outbound.result=99999)
> exten => main,n,Hangup
>
>
> Execution on foo:123 on server1 would look like this:
>
>     -- Executing [foo:1]
Set("SIP/2203-6696",  
> "outbound.customer=JoeBob") in new stack
>     -- Executing [foo:2]
NoOp("SIP/2203-6696", "") in new
stack
>     -- Executing [foo:3]
Dial("SIP/2203-6696", "IAX2/ 
> server1server2/main") in new stack
>     -- Executing [foo:4]
NoOp("SIP/2203-6696", "99999") in
new stack
>
>
> Execution on server2 would look like this:
>
>     -- Executing [foo:1]
NoOp("IAX2/2203-6696", "JoeBob") in
new stack
>     -- Executing [foo:2]
Set("IAX2/2203-6696",  
> "outbound.result=99999") in new stack
>     -- Executing [foo:3]
Hangup("IAX2/2203-6696", "") in new
stack
>

But what happens if server1 hangs up first ?

>
> Finally, I think there is interest in such a patch, but
my hand- 
> waving or anyone else's complaints about it won't
produce code.   
> Everyone on the list might think it's a good idea, but
only the  
> person that is willing to code it will be the one to
submit the  
> patch.  I'll put up $50 to seeing this patch idea or
something  
> close enough to it written in such a way that would
permit (and  
> results in) it's inclusion into TRUNK - anyone else
want to put  
> their money where their mouth is, or their code where
their mouth  
> is, or something to that effect?
>
> JT
>

Tim Panton

www.mexuar.com



_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

On Sat, Jul 29, 2006 at 09:19:28AM +0100, Tim Panton wrote:

> When I said we could use url style values in the dial
plan, I was  
> thinking of having it work like this:
> 
> dial(IAX2/mexuar/3?customer="JoeBob")
> 
> Asterisk would strip ?customer="JoeBob"
from the dial string before  
> sending it.
> It would then add an (optional) InfoElement to the NEW
frame with the  
> variable name and value in it
> 
> The receiving IAX would either ignore the extra
InfoElement, or if it  
> supported it, it would
> check to see if the variable existed, if not, create it
and assign  
> the value.
> (pre existing asterisks will ignore IEs they don't
understand)

One side point: would you really want to allow a remote
server to
override any local variable you have? Shouldn't there be a
separate
namespace (e.g: prefix) for variables that could be supplied
by the 
remote party?

-- 
Tzafrir Cohen         sip:tzafrirlocal.xorcom.com
icq#16849755          iax:tzafrirlocal.xorcom.com
+972-50-7952406          jabber:tzafrirjabber.org
tzafrir.cohenxorcom.com     http://www.xorcom.com
_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

On Friday 28 July 2006 19:48, John Todd wrote:
> This message is a summary of some of the comments made
in this
> thread; apologies for not including all forwards - it
was a bit
> messy.
>
>  - I don't know if there was any particular
"use" for the SIP
> header read/write routines; saying that inclusion of
variables in
> there wasn't part of it's intention might be an
overstatement of
> intent.  I think they can be used for whatever the
administrator
> wants; variable transfer from server to server seems
like a totally
> reasonable and SIP-consistent method.

The major reason for having these is the ability to send
custom
headers to particular devices to cause particular behavior,
such as
to force a SIP phone to go into auto-answer mode or to ring
a
particular ring.  While I agree that they could be used to
send
variables to a remote server, that was not their original
intended
use.

>  - I would disagree that using IAX2 to transport
variables in a
> "static" fashion is equivalent to putting
the variables into the
> dialed number sequence.  Firstly, you've hit upon an
obvious limit
> in having only 255 characters, which is a serious
problem to any
> robust transfer of values across the channel.

There is always a limit; for the protocol, it is 255, but
even with
80, you have more than enough room to pass reasonable
indications to
a remote IAX2 server that you control.  Remember, passing
variables
is useful only when you can control their interpretation on
the remote
end.  Even if you encode variables within the protocol
itself, you
should be mindful of the fact that MTU limits mean that a
SETUP
message exceeding that limit could cause your call delivery
more than
the usual delay.

> Secondly, ordering 
> variables inside of such a string is ugly and prone to
fragility. 

Ugliness is a subjective judgement and requires no response.
 In terms
of fragility, variable passing is just as fragile, given
that the
remote server may or may not understand (or could even
misinterpret!)
the variables you're passing, if that server is not within
your
control.

> Thirdly, it would require that the remote server is
ALWAYS one that
> can handle such garbled string dial requests, since an
unsuspecting
> server would surely fail on a dial pattern of such
massive length. 

An unsuspecting server would also fail to process any
variables sent
or could misinterpret them and do something unexpected and
unintended.

>  Lastly, it is overly onerous to the dialplan
administrator who has
> to write a fairly obtuse section of string-chopping
code to make
> things work.  It seems that this could fairly elegantly
be "hidden"
> in the internals of Asterisk to let the administrator
simply use
> the values instead of parsing them as well.

I think that string chopping is much more obvious and easy
to
understand for the casual administrator who might be
surprised to see
variables suddenly appear in the dialplan for which there
were no
originating assignments.  Again, debugging is easier when
you can see
all the values in front of you on the server you're working
on.

> There are often concessions within Asterisk that make
life easier
> for the administrator, and putting  variables inside of
IAX2 does
> not seem to only have those benefits but many others as
well.
>
> While I agree that setting of variables on the
initiation of calls
> (and not dynamically changing them as the call
progresses) is of
> limited use, I would say that it is of enough use that
it merits
> attention from any enterprising programmer who wishes
to fill an
> uneventful Saturday afternoon (and Sunday, and
Monday...) with good
> coding.  Once the ability exists in a start-of-call
fashion,
> perhaps demand and interest will push others to solve
the problems
> surrounding dynamic variable transmission.  "Do
not let perfection
> be the enemy of 'good enough'."
>
>
>  - The suggestion that variables can be set on
conclusion of the
> call is a good idea, and I had not thought of it.  It
does not seem
> to be much more complex than the setting of
start-of-call
> variables, as long as they are transmitted back to the
originating
> server only on disconnection or redirection of the
signalling
> stream (note I didn't say "media stream").

The AOC messages that someone else is implementing is
similar to this,
and they're going through all the problems that passing
arbitrary
variables entails.

> Skeletal example (IAX configs omitted for brevity):
>
> server1:
> [foo]
> exten =>
123,1,Set(outbound.customer="JoeBob")
> exten => 123,n,NoOp(${inbound.result})
> exten => 123,n,Dial(IAX2/server1server2/main)
> exten => 123,n,NoOp(${inbound.result})
> exten => 123,n,Hangup
>
> server2:
> [bar]
> exten => main,1,NoOp(${inbound.customer})
> exten => main,n,Set(outbound.result=99999)
> exten => main,n,Hangup

While I disagree with the premise, your syntax is begging
for
dialplan functions.

> Finally, I think there is interest in such a patch, but
my
> hand-waving or anyone else's complaints about it
won't produce
> code.  Everyone on the list might think it's a good
idea, but only
> the person that is willing to code it will be the one
to submit the
> patch.  I'll put up $50 to seeing this patch idea or
something
> close enough to it written in such a way that would
permit (and
> results in) it's inclusion into TRUNK - anyone else
want to put
> their money where their mouth is, or their code where
their mouth
> is, or something to that effect?

Coding to spec would in no way guarantee its inclusion in
trunk, but
it's an interesting enough idea that I'd code it simply to
end this
thread.

-- 
Tilghman
_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

On 29 Jul 2006, at 12:59, Tzafrir Cohen wrote:

> On Sat, Jul 29, 2006 at 09:19:28AM +0100, Tim Panton
wrote:
>
>> When I said we could use url style values in the
dial plan, I was
>> thinking of having it work like this:
>>
>> dial(IAX2/mexuar/3?customer="JoeBob")
>>
>> Asterisk would strip ?customer="JoeBob"
from the dial string before
>> sending it.
>> It would then add an (optional) InfoElement to the
NEW frame with the
>> variable name and value in it
>>
>> The receiving IAX would either ignore the extra
InfoElement, or if it
>> supported it, it would
>> check to see if the variable existed, if not,
create it and assign
>> the value.
>> (pre existing asterisks will ignore IEs they don't
understand)
>
> One side point: would you really want to allow a remote
server to
> override any local variable you have? Shouldn't there
be a separate
> namespace (e.g: prefix) for variables that could be
supplied by the
> remote party?

No, I think it is simpler if the variables are in the same
namespace,  
we are
all used to there being variables which just appear as the
result of
functions in a dialplan.


I don't think sent variables should override existing local
variables,
hence the test to see if the variable already exists (see
above).


Tim Panton

www.mexuar.com



_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev