[Asterisk-Dev] CVS HEAD not compiling:
It appears that CVS HEAD is not currently compiling! I don't think I'm doing anything stupid: libpri: iax1:/usr/src/libpri # make install Makefile:92: .depend: No such file or directory ./mkdep -Wall -Werror -Wstrict-prototypes -Wmissing-prototypes -g `ls *.c` cc -Wall -Werror -Wstrict-prototypes -Wmissing-prototypes -g -c -o pri.o pri.c cc -Wall -Werror -Wstrict-prototypes -Wmissing-prototypes -g -c -o q921.o q921.c cc -Wall -Werror -Wstrict-prototypes -Wmissing-prototypes -g -c -o prisched.o prisched.c cc -Wall -Werror -Wstrict-prototypes -Wmissing-prototypes -g -c -o q931.o q931.c q931.c: In function `receive_generic_digits': q931.c:1567: warning: comparison between signed and unsigned make: *** [q931.o] Error 1 asterisk: gcc -pipe -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -g -Iinclude -I../include -D_REENTRANT -D_GNU_SOURCE -O6 -march=i686 -DZAPTEL_OPTIMIZATIONS -DASTERISK_VERSION=\CVS-HEAD-11/30/04-07:33:25\ -DASTERISK_VERSION_NUM=99 -DINSTALL_PREFIX=\\ -DASTETCDIR=\/etc/asterisk\ -DASTLIBDIR=\/usr/lib/asterisk\ -DASTVARLIBDIR=\/var/lib/asterisk\ -DASTVARRUNDIR=\/var/run\ -DASTSPOOLDIR=\/var/spool/asterisk\ -DASTLOGDIR=\/var/log/asterisk\ -DASTCONFPATH=\/etc/asterisk/asterisk.conf\ -DASTMODDIR=\/usr/lib/asterisk/modules\ -DASTAGIDIR=\/var/lib/asterisk/agi-bin\ -DBUSYDETECT_MARTIN -fPIC -c -o pbx_dundi.o pbx_dundi.c pbx_dundi.c:54:18: zlib.h: No such file or directory pbx_dundi.c: In function `update_key': pbx_dundi.c:1315: warning: implicit declaration of function `crc32' pbx_dundi.c: In function `dundi_decrypt': pbx_dundi.c:1371: warning: implicit declaration of function `uncompress' pbx_dundi.c:1371: error: `Z_OK' undeclared (first use in this function) pbx_dundi.c:1371: error: (Each undeclared identifier is reported only once pbx_dundi.c:1371: error: for each function it appears in.) pbx_dundi.c: In function `dundi_encrypt': pbx_dundi.c:1396: warning: implicit declaration of function `compress' pbx_dundi.c:1397: error: `Z_OK' undeclared (first use in this function) pbx_dundi.c: In function `socket_read': pbx_dundi.c:1985: warning: comparison between signed and unsigned make[1]: *** [pbx_dundi.o] Error 1 make[1]: Leaving directory `/usr/src/asterisk/pbx' make: *** [subdirs] Error 1 ___ Asterisk-Dev mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] SS7 for *
UK-ISUP has more than minor differences from the ETSI brand of ISUP (it is effectively a BT version). ETSI-ISUP in use in the UK (both version 1 2) are identical and the EU approval version would be fine for the UK. Its a long time since I worked on UK SS7, but it didn't seem like such a big difference. Maybe, but UKISUP v2 is to replace BT-IUP as the BT interconnect protocol, so BT have had to shove a whole load of stuff into it to make it 'conform' to the old way of doing things. Linus ___ Asterisk-Dev mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] SS7 for *
We use Kingston in the UK, they wont be charging us for interconnect testing, so if you fancy testing it with us (which we would be MORE than happy to do) then we can get the approval done, with little costs involved. Although remember that won't get you on the BT approved list, all that covers is that KCL would be happy. Linus ___ Asterisk-Dev mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] Time to lock down v1.1?
1.1 (today's head) is more of a let's try if this works' release. Please spend time testing it. Remember, CVS HEAD, is not meant to be stable. Now and then, it might not even compile cleanly. It's a developer's release, at some point in future aimed to be stable. Surely this is the reason of most peoples complaints today, all of us who are using Asterisk in real world, commercial environments get extremely frustrated when 'key' issues get fixed in the 'head' release, for example, recent fixes for IAX and SIP voice quality, and are not back ported to the stable/release/whatever version. It leaves us in a very difficult position, as commercially we are placing our users at unnecessary risk by using the 'head' version to get a specific bug fix, but also giving them poor service if we stick with the 'broken' version. Please can those responsible have some understanding of this, as a rule would it not make sense that all (or at least all major) 'fixes' go into both after being appropriately tested, and keep 'head' for the more 'bleeding edge' new features and more radical changes etc? Linus ___ Asterisk-Dev mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] IAX2 call variable passing between servers
Hi John,
I am very interested in the idea of passing extra data with IAX2 as I see
that is one of the most major areas that it is lacking.
My particular interest is in passing call related information at two times,
a) call establishment and b) call end.
The first fits in with what you have proposed here, and I agree that you
don't want to be sending or receiving all of the tasks 'environment'
variables. I also agree in principle with the thoughts behind the
inbound.variable, outbound.variable system, although I would tend to suggest
not directly linking the variables in the same 'name' space, instead you
might have:
SetCallVar(Q931BEARER=039090)
SetCallVar(Q931NOA=INTERNATIONAL)
and
ReadCallVar(Q931BEARER,BEARER)
ClearCallVar(Q931NOA)
blah blah ${BEARER}
Any variables that are set and contained in the 'callvar' name space will be
automatically passed on any outbound Dial call unless specifically cleared -
or maybe blocked with a Dial option.
These variables may be set by the application *but could also be set* by the
channel code itself, for example chan_zap.c/q931.c might set Q931BEARER, and
more importantly might *read* it and set it in the Q931 call setup packet.
With this mechanism in IAX2 and appropriate support in Zap/pri/q931 IAX2
then becomes a very real transport for telco applications where we need to
transit call flags.
Secondly, an additional variable that I would like to see passed would be
sent and read *in reverse* when a call clears. At the moment, a very real
restriction on IAX2 is that calls either connect and then clear or fail to
connect and clear. There is no way to tell *why* the call cleared. I'd like
to be able to pass, whether as a variable or otherwise a 'CLEARCAUSE'
variable whoes values could reflect a far wider range of values ( at the
very least Busy, Congested, Number Unobtainable, Call Failed, Call Rejected,
Out Of Order, Incompatible Equipment)
What do you think?
Linus
Magrathea
- Original Message -
From: John Todd [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, December 02, 2003 3:42 PM
Subject: [Asterisk-Dev] IAX2 call variable passing between servers
Here's an idea for you all to shoot down. I'll await the nonexistant
comments before I open a feature request.
We have the luxury of moving calls around with IAX2, where we (the
Asterisk community) have control of the protocol. Various hacks are
being installed into SIP headers to move data around, as I'm
experiencing with some of the installations I've now seen. With
IAX2, it seems apparent that we should be able to move variables
around semi-transparently, since IAX2 integrates with Asterisk
completely.
Sending all variables might be difficult/insecure/silly, as we don't
want to clutter the call setup with a slew of variables, some of
which may be inherently secure and should not leave the server on
which they were generated. Perhaps some naming convention could be
used to differentiate variables that would be passed to the remote
end as special case variables.
There are two possible methods that could be used to determine if
certain variables might get passed. The first method is the
simplest, which is to simply search all the named variables and see
if any of them begin with resend. and then transmit those
automatically. Alternately (and perhaps, in addition to this method)
one could add yet another modifier to the Dial command, such as v
which stands for send [v]ariables.
I propose a format like this for outbound: outbound.VARNAME
I propose a format like this for inbound: inbound.VARNAME
I think that it would be wise to sandbox the variables with a
distinguishing feature (name prefix) so that we do not inadvertently
move variables out of or into local/remote dialplan executions. The
extra two steps is a small enough effort. (really, one step at each
end is needed to be clean, but we could skip the re-translation at
the far end and just use ${inbound.VARNAME} if we were lazy.)
As an example:
exten = 123,1,SetVar(GREETING=hello there)
exten = 123,2,SetVar(NAME=John Doe)
exten = 123,3,SetVar(outbound.GREETING=${GREETING})
exten = 123,4,SetVar(outbound.NUMBER=${EXTEN})
exten = 123,5,Dial(IAX2/[EMAIL PROTECTED]/${EXTEN},,v)
Upon receiving the call, the other host (hub1) would then have to
translate back like this:
[from-remote1]
exten = _X.,1,SetVar(OURGREETING=${inbound.GREETING})
exten = _X.,2,SetVar(DIALEDNUMBER=${inbound.NUMBER})
exten = _X.,3,blah blah blah
SIP:
As far as having this work across channels other than IAX2: SIP can
handle almost any number of additional headers. It could be possible
to incorporate a custom header if there are any variables that fall
into the 'resend.' group. Of course, fully escaped syntax would need
to be followed. As an example, a custom header could be
generated/parsed:
Asterisk-Variables: FOO=hello there;NUMBER=123
PRI:
There are special areas in the PRI outbound call which
[Asterisk-Dev] Bug Num 0000456
(http://bugs.digium.com/bug_view_page.php?bug_id=456)
Hi Mark et al,
Please, if you have a moment, can you answer this one:
Was it your intention that the ability to set/override a callerid by using a
parameter in iax.conf DOES NOT APPLY if the incoming call sent a NULL
callerid?
If not, then the fix is easy, remove the if (strlen) bit from:
if (strlen(iaxs[callno]-callerid)) {
if (user-hascallerid)
strncpy(iaxs[callno]-callerid, user-callerid,
sizeof(iaxs[callno]-callerid)-1);
strncpy(iaxs[callno]-ani, user-callerid, sizeof(iaxs[callno]-ani)-1);
}
If it was your intent, please say so, and we can make a note to manually
patch it our end each time we checkout as we need the callerid= bit to
always work.
Linus
___
Asterisk-Dev mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-dev
[Asterisk-Dev] caller display in a telco environment.
Hi John,
In response to your question, and a couple of other items seen recently,
I've produced this, which is my view on the Q931/PRI caller display issues.
(Due to different terminology I'm using the UK abreviation CLI, caller line
identity in the following text, but it could also be termed caller display
or ANI or 'A' Number)
There have been a number of threads recently regarding CLI both entering *
from a PRI, or being delivered from * to a PRI and in most cases this is
handled 'incorrectly' if the equipment is to be used in a telco environment.
I'm not currently that famililar with the * code, but this should help those
that are make the correct choices when making patches.
Firstly, some definitions. Q931 specifies two seperate flags, which the
'zap' libraries incorrectly bundle into the one set of 'presentation'
#defines.
The first is the presentation indicator, which has three primary values:
0 which indicates that the CLI if present is freely available for display
purposes,
1 which indicates that the user/users system has made a decision not to make
the number available for display, or
2 which indicates that the number cannot be used for display, but this is
not because of user choice action. (although the title is 'number not
available due to interworking' this doesnt mean there is not a number)
(These are in bits 7 6 and so take the values in the field of
0x00,0x20,0x40,0x60)
The second is the screening indicator. These values are:
0 - The user equipment has provided the number and no network equipement has
attempted to verify the number. (In all these definitions, network equipment
refers to authoritive switching systems that are part of the PSTN and can be
trusted to provide genuine information).
1 - The user equipment has provided the number and network equipment has
validated it.
2 - The user equipment has provided the number and network equipment has
rejected it.
3 - Number has been provided by authoritive network equipment.
Now, dealing first with calls arriving from a PRI. As a telco, connections
are generally classified as trusted or not trusted. Connections to a user
are always not trusted, connections using a protocol that does not support
withholding number display are not trusted and international connections are
not trusted. As far as Asterisk is concerned sensible defaults would be to
count PRI as trusted and all none PRI (SIP, IAX etc) as none trusted, but
this should be a per trunk/user configuration option (trustwithcli=yes|no?).
Thus if Asterisk is delivering a call that arrives on a PRI it should only
pass CLI if the presentation indicator is zero unless the trunk is 'trusted'
in which case the CLI can be passed in all cases, with whatever flags the
outgoing protocol allows to closely mirror the PRI flags - especially the
presentation indicator.
Secondly, dealing with calls being delivered out from Asterisk on a PRI, to
be standards compliant, (unless the call also arrived on a PRI), all calls
should send the CLI provided but marked 'number not available due to
interworking', and 'user provided not screened' - a byte value of 0x40. A
second per user/trunk configuration item should be provided
(clivalid=yes|no?) which then overrides this behaviour and then allows the
number to be delivered to the PRI with the flags set as presentation
allowed, user provided not verified, a byte value of 0x00.
Whilst the above doesnt show any code, hopefully it is enough to help!
Linus
Magrathea
- Original Message -
From: John Todd [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Tuesday, August 05, 2003 7:25 PM
Subject: Re: [Asterisk-Users] Syntax for hiding caller ID but still passing
ANI?
Lorenzo -
I've submitted a feature request with this patch
(http://bugs.digium.com/bug_view_page.php?bug_id=052). Your
patch isn't completely descriptive, since I still don't know how you
set the hidecallerid value from within a dialplan. Can you explain a
bit more, please? Have you submitted a disclaimer to Digium so this
patch might be added if it's seen as a useful addition?
Linus -
Thanks for the specifications. Did you have a patch or comments on
how this might be implemented in the code?
JT
We did something like this in chan_zap at pri_call() time:
case SIG_PRI:
[...]
if (ast-callerid) {
strncpy(callerid, ast-callerid, sizeof(callerid)-1);
ast_callerid_parse(callerid, n, l);
if (l) {
ast_shrink_phone_number(l);
if (!ast_isphonenumber(l))
l = NULL;
}
}
[...]
if (l) {
pres = ast-hidecallerid ?
PRES_PROHIB_USER_NUMBER_NOT_SCREENED :
PRES_ALLOWED_USER
} else
pres = PRES_NUMBER_NOT_AVAILABLE;
if (pri_call(p-pri-pri, p-call,
p-digital ? PRI_TRANS_CAP_DIGITAL : PRI_TRANS_CAP_SPEEC
p-prioffset, p-pri-nodetype == PRI_NETWORK ? 0 : 1, 1, l,
p-pri-dialplan - 1,
c + p-stripmsd, p-pri-dialplan - 1,
[Asterisk-Dev] Re: [Asterisk-Users] Syntax for hiding caller ID but still passing ANI?
(as a follow up to my own post) It seems that there are two options that block the presentation: 0x23 and 0x21 No no! Protocol wise, they are different flags in each nibble. If the high nibble is not zero then the number is not for general use. Any number presentation block in PRI-SIP conversion should only pass the CLI if the high nibble is zero. Cut and paste from the ITU Spec Q931 Presentation indicator (octet 3a) Bits 7 6 Meaning 0 0 Presentation allowed 0 1 Presentation restricted 1 0 Number not available due to interworking 1 1 Reserved NOTE 1 - The meaning and the use of this field is defined in 3/Q.951 and 4/Q.951. Screening indicator (octet 3a) Bits 2 1 Meaning 0 0 User-provided, not screened 0 1 User-provided, verified and passed 1 0 User-provided, verified and failed 1 1 Network provided NOTE 2 - The meaning and the use of this field is defined in 3/Q.951 and 4/Q.951. Linus ___ Asterisk-Dev mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-dev
