Re: [Asterisk-Dev] Asterisk extra logging to file
You can set the debug and verbosity level either via command line param (-vvv [verbose] -ddd [debug) or via the CLI set verbose level set debug level On 12/28/05, ast guy [EMAIL PROTECTED] wrote: /etc/asterisk/logger.conf, does it allow to set verbosity level input to log file ? messages = notice,warning,error,debug,verbose but still extra detail is not logged into file! On 12/28/05, BJ Weschke [EMAIL PROTECTED] wrote: On 12/28/05, ast guy [EMAIL PROTECTED] wrote: Hi! Connecting to asterisk through command # asterisk -r ( using ast_log fxn with LOG_VERBOSE option in code ) Gives me much logging for debug, even to the called functions line number of included files on runtime at CONSOLE, but I'm unable to log this level information to asterisk log file (/var/log/asterisk/messages) Yes. Take a look at the logger.conf file in /etc/asterisk to see what logging channels you'd like to put into what files. -- Bird's The Word Technologies, Inc. http://www.btwtech.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 ___ --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 -- Bird's The Word Technologies, Inc. http://www.btwtech.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
Re: [Asterisk-Dev] Re: [Asterisk-Users] Asterisk does not handle call from a Cisco IAD correctly
Tilghman Lesher wrote: On Tuesday 27 December 2005 14:15, James Sizemore wrote: I think I found what is munging up the peer lookup: This call from another Asterisk box starts: -- SIP read from 192.168.69.254:5060: The peer lookup that fail reads: -- SIP read from 192.168.7.250:52141: Asterisk seem to be thrown off by the fact that the return port is not 5060, and fails the peer lookup. This is a * bug then. I have documented it with both 1.0.9 and 1.2.1. Time to dig through the sip code. No, this is actually sane. This is necessary behavior in order to support multiple SIP clients from behind the same NAT. Asterisk needs to know the control port for your host, and it needs to stay consistent between a REGISTER and an INVITE. If Asterisk sees a different control port, it quite naturally assumes that that's a different client. Thanks for the reply I do not see this as sane, this is not a register, this is a peer statement, and needs to be treated differently then a register. Any call from this peer should be allowed regardless of the port used. I agree that if I had registered and given a port that I should continue to use said port. But in this case I never registered and calls from 192.168.7.250 should be allowed with out restriction. I am not a big fan of the way cisco does a lot of stuff, but in this case using a random port for an out going calls from the device to 5060 on the receiving device is pretty normal way to establish a out going connection. Although I think I can get the Cisco to always use 5060 as it's out going port (and there work around the problem) I still think the error is on the Asterisk side. [bna-vonx-iad] type=peer context=trusted-out host=192.168.7.250 canreinvite=no ___ --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
[Asterisk-Dev] asterisk 1.2 g729 compile errors
Hello Diyanat Ali ,Christian Braun and others
My g729 is working OK with the old patch
g729-rob.diff.
Now i am trying the new patch ipp-050903.diff.txt
getting following errors
I patch against the vm_types_linux32.h include and now
getting errors
gcc -I./include -I./vm/include
-I/opt/intel/ipp41/ia32_itanium/include -include
/opt/intel/ipp41/ia32_itanium/tools/staticlib/ipp_a6.h
-D__unix__ -Dlinux -Dlinux32 -DNDEBUG -DLINUX32
-DNO_SCRATCH_MEMORY_USED -c -O6 -mcpu=pentium3
-march=pentium3 -ffast-math -fomit-frame-pointer
-osamples/encoder.o samples/encoder.c
In file included from ./vm/include/vm_types.h:17,
from ./vm/include/vm_thread.h:14,
from samples/encoder.h:28,
from samples/encoder.c:35:
./vm/include/sys/vm_types_linux32.h:36: error: syntax
error before ast_cond_t
./vm/include/sys/vm_types_linux32.h:36: warning: no
semicolon at end of struct or union
./vm/include/sys/vm_types_linux32.h:37: warning: data
definition has no type or storage class
./vm/include/sys/vm_types_linux32.h:40: error: syntax
error before '}' token
./vm/include/sys/vm_types_linux32.h:40: warning: data
definition has no type or storage class
./vm/include/sys/vm_types_linux32.h:51: error: syntax
error before ast_mutex_t
./vm/include/sys/vm_types_linux32.h:51: warning: no
semicolon at end of struct or union
./vm/include/sys/vm_types_linux32.h:53: error: syntax
error before '}' token
./vm/include/sys/vm_types_linux32.h:53: warning: data
definition has no type or storage class
./vm/include/sys/vm_types_linux32.h:57: error: syntax
error before ast_cond_t
./vm/include/sys/vm_types_linux32.h:57: warning: no
semicolon at end of struct or union
./vm/include/sys/vm_types_linux32.h:58: warning: data
definition has no type or storage class
./vm/include/sys/vm_types_linux32.h:60: error: syntax
error before '}' token
./vm/include/sys/vm_types_linux32.h:60: warning: data
definition has no type or storage class
make: *** [samples/encoder.o] Error 1
[EMAIL PROTECTED] G729-float]#
The new vm_types_linux32.h is
/*
/
//
// INTEL CORPORATION PROPRIETARY
INFORMATION
// This software is supplied under the terms of a
license agreement or
// nondisclosure agreement with Intel Corporation
and may not be copied
// or disclosed except in accordance with the
terms of that agreement.
// Copyright(c) 2003-2004 Intel Corporation.
All Rights Reserved.
//
// Cross-architecture support tool.
// Linux types header.
*/
#ifdef LINUX32
#ifdef __cplusplus
extern C {
#endif
typedef unsigned long vm_var32;
typedef unsigned long long vm_var64;
typedef char vm_char;
#define VM_ALIGN_DECL(X,Y) Y __attribute__
((aligned(X)))
#include pthread.h
#include sys/types.h
#include semaphore.h
/* vm_thread.h */
typedef struct {
pthread_t handle;
int is_valid;
} vm_thread;
/* vm_event.h */
typedef struct {
ast_cond_t cond;
ast_mutex_t mutex;
int manual;
int state;
} vm_event;
/* vm_mmap.h */
typedef struct {
intfd;
void *address;
size_t sizet;
} vm_mmap;
/* vm_mutex.h */
typedef struct {
ast_mutex_t handle;
int is_valid;
} vm_mutex;
/* vm_semaphore.h */
typedef struct {
ast_cond_t cond;
ast_mutex_t mutex;
int count;
} vm_semaphore;
#ifdef __cplusplus
};
#endif
#endif
PLEASE HELP
Regards
Hem
__
Yahoo! DSL Something to write home about.
Just $16.99/mo. or less.
dsl.yahoo.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
Re: [Asterisk-Dev] Help Debugging Dropped Call Audio
Mike Benoit wrote: I got my hands on a couple of the raw .wav files, and it seems they do not contain the artifacts I described in earlier emails. I ran my mp3 conversion script on the .wav's and the resulting mp3's do have the artifacts (if played in XMMS only). So unless the MP3 conversion is somehow picking up dropped audio packets which XMMS is exposing, this doesn't appear to be the same issue you are running in to. Mike, Thank you for taking the time to look into this. It's unfortunate that we're not experiencing the same issue, but I appreciate your efforts nonetheless. Sincerely, Matthew Roth InterMedia Marketing Solutions Software Engineer and Systems Developer ___ --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
Re: [Asterisk-Dev] asterisk 1.2 g729 compile errors
On Wed, 2005-12-28 at 08:37 -0800, hemant surjuse wrote: Beyond my normal annoyance at the intel G729 hack, couldn't you read this file enough to realize you probably broke your license by mailing this? We in the opensource world need to be very mindful of intelectual property. Many of us are deed holders in the intelectual property world and wwant our wishes respected, so respect others wishes and legal obligations. /* / // // INTEL CORPORATION PROPRIETARY INFORMATION // This software is supplied under the terms of a license agreement or // nondisclosure agreement with Intel Corporation and may not be copied // or disclosed except in accordance with the terms of that agreement. // Copyright(c) 2003-2004 Intel Corporation. All Rights Reserved. // // Cross-architecture support tool. // Linux types header. */ -- Steven Critchfield [EMAIL PROTECTED] ___ --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
Re: [Asterisk-Dev] Help Debugging Dropped Call Audio
On Tue, 2005-12-27 at 11:40 -0800, Mike Benoit wrote: I got my hands on a couple of the raw .wav files, and it seems they do not contain the artifacts I described in earlier emails. I ran my mp3 conversion script on the .wav's and the resulting mp3's do have the artifacts (if played in XMMS only). So unless the MP3 conversion is somehow picking up dropped audio packets which XMMS is exposing, this doesn't appear to be the same issue you are running in to. First off, mp3 is a BAD choice for telephony audio storage. It doesn't compress very much compared to other options available to you and the sound quality doesn't make enough of a trade off for the size of the file. Second, are you experiencing the audio problems on raw wav files? It very well may be that the interaction between your encoder and xmms is what is causing your problems. -- Steven Critchfield [EMAIL PROTECTED] ___ --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
[Asterisk-Dev] ztdummy? is it necessary?
Greetings, I was having a conversation with someone the other day and was informed that ztdummy is basically unnecessary in BSD and perhaps in more recent linux kernels. Is this indeed the case? Would you need to run asterisk at a realtime priority for this to work? Getting rid of the ztdummy requirement would be an amazing win for OS portability, as long as it could rely on the OS's realtime timer. ___ --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
Re: [Asterisk-Dev] ztdummy? is it necessary?
On 12/28/05, Jason DiCioccio [EMAIL PROTECTED] wrote: Greetings, I was having a conversation with someone the other day and was informed that ztdummy is basically unnecessary in BSD and perhaps in more recent linux kernels. Is this indeed the case? Would you need to run asterisk at a realtime priority for this to work? Getting rid of the ztdummy requirement would be an amazing win for OS portability, as long as it could rely on the OS's realtime timer. This is more a question for asterisk-users, but there are certain applications (app_meetme) that require ztdummy if you don't already have a valid Zaptel timing source. They will not operate without it. -- Bird's The Word Technologies, Inc. http://www.btwtech.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
[Asterisk-Dev] Re: ztdummy? is it necessary?
Based on the initial response, I should probably clarify what I'm asking. I know that some applications, as asterisk is developed now, require a zaptel timing source. However, is this requirement necessary? Would certain platforms, if asterisk was written to accept it, be able to handle everything fine without the zaptel timing requirement? My understand of the issue is that older versions of Linux had an inaccurate real-time clock. I also understand that this has since been fixed? And that BSD does not have the issue? So does this extra driver really need to be required on all platforms? Or just the ones with the broken RTC? Basically, I'm not asking if asterisk as it is today requires ztdummy. I'm asking if the requirement is necessary. Thanks! -JD- ___ --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
RE: [Asterisk-Dev] Re: ztdummy? is it necessary?
Based on the initial response, I should probably clarify what I'm asking. I know that some applications, as asterisk is developed now, require a zaptel timing source. However, is this requirement necessary? Would certain platforms, if asterisk was written to accept it, be able to handle everything fine without the zaptel timing requirement? My understand of the issue is that older versions of Linux had an inaccurate real-time clock. I also understand that this has since been fixed? And that BSD does not have the issue? So does this extra driver really need to be required on all platforms? Or just the ones with the broken RTC? Basically, I'm not asking if asterisk as it is today requires ztdummy. I'm asking if the requirement is necessary. Yes and no. Recent advances in Linux (RT patches, Hi-Res timers) that are approaching a merge to the mainline kernel raise the possibility that timing could be migrated to the core of Asterisk. On the other hand, if you have a hardware timer, you might prefer to use it, in which case making ztdummy use these new features is still a better way to improve timing and allow for flexibility. Lastly, even if these improvements make it in to the mainline Linux kernel, will there be a portable way to implement the same functionality on other operating systems? So to answer a theoratical question with a theoretical answer: It is possible that ztdummy will not be necessary in the relatively near future (on Linux), but my guess is that it will be maintained and improved instead of eliminated. Dan Thanks! -JD- ___ --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
Re: [Asterisk-Dev] Re: ztdummy? is it necessary?
Jason You make a good point. However, until every old telcom person out there keels over, people will want to know the timing source. Some platforms may or may not have a good system timer and thus neet the ZtDummy. Andrew On 12/28/05, Jason DiCioccio [EMAIL PROTECTED] wrote: Based on the initial response, I should probably clarify what I'm asking. I know that some applications, as asterisk is developed now, require a zaptel timing source. However, is this requirement necessary? Would certain platforms, if asterisk was written to accept it, be able to handle everything fine without the zaptel timing requirement? My understand of the issue is that older versions of Linux had an inaccurate real-time clock. I also understand that this has since been fixed? And that BSD does not have the issue? So does this extra driver really need to be required on all platforms? Or just the ones with the broken RTC? Basically, I'm not asking if asterisk as it is today requires ztdummy. I'm asking if the requirement is necessary. Thanks! -JD- ___ --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 -- --- Andrew Latham - AKA: LATHAMA (lay-th-ham-eh) [EMAIL PROTECTED] - [EMAIL PROTECTED] - [EMAIL PROTECTED] If any of the above are down we have bigger problems than my email! --- ___ --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
RE: [Asterisk-Dev] Re: ztdummy? is it necessary?
Yes and no. Recent advances in Linux (RT patches, Hi-Res timers) that are approaching a merge to the mainline kernel raise the possibility that timing could be migrated to the core of Asterisk. This would be great in my mind.. On the other hand, if you have a hardware timer, you might prefer to use it, in which case making ztdummy use these new features is still a better way to improve timing and allow for flexibility. That's fine too. Having the option for hardware timing is fine with me,. But requiring ztdummy if and when there is support in the kernel that makes it unnecessary doesn't seem like a necessary requirement. Lastly, even if these improvements make it in to the mainline Linux kernel, will there be a portable way to implement the same functionality on other operating systems? I thought this was a POSIX thing, but if not, then who knows. I'm sorry that I don't have more information, I suppose I was curious about the whole situation. So to answer a theoratical question with a theoretical answer: It is possible that ztdummy will not be necessary in the relatively near future (on Linux), but my guess is that it will be maintained and improved instead of eliminated. My understanding is that on OS's other than Linux (FreeBSD, for example), the support is there right now for this, but instead of having asterisk support these native timers directly, ztdummy was ported. Dan Thanks! -JD- ___ --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
[Asterisk-Dev] any reason for #define FREE in the code ?
there are a few files, probably derived from some old template,
that still have these blocks:
#ifdef __AST_DEBUG_MALLOC
static void FREE(void *ptr)
{
free(ptr);
}
#else
#define FREE free
#endif
the files in question are the following:
./res/res_features.c:static void FREE(void *ptr)
./res/res_features.c.orig:static void FREE(void *ptr)
./pbx/.svn/text-base/pbx_ael.c.svn-base:static void FREE(void *ptr)
./pbx/.svn/text-base/pbx_config.c.svn-base:static void FREE(void *ptr)
./pbx/pbx_config.c:static void FREE(void *ptr)
./pbx/pbx_ael.c:static void FREE(void *ptr)
i don't think there is any reason for that, especially
considering that the actual function or macro is not used
consistently across the code. It should go, right ?
cheers
luigi
___
--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
RE: [Asterisk-Dev] Re: ztdummy? is it necessary?
On Wed, 2005-12-28 at 14:04 -0500, Jason DiCioccio wrote: My understanding is that on OS's other than Linux (FreeBSD, for example), the support is there right now for this, but instead of having asterisk support these native timers directly, ztdummy was ported. Why wouldn't you just create a ztdummy like module that allowed yourself the ability to hook into what ever native timer you could use? This would allow you to drive the asterisk need for a timer of some form through an already well known and well tested API. Not to mention the current API seems to allow you to drive asterisk from any timer you can create meaning it is already very cross platform capable, you just need to make the right portion of the driver to use the timer of your choice on the platform of your choice. -- Steven Critchfield [EMAIL PROTECTED] ___ --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
Re: [Asterisk-Dev] Re: ztdummy? is it necessary?
On Wed, Dec 28, 2005 at 10:46:41AM -0800, Dan Austin wrote: Basically, I'm not asking if asterisk as it is today requires ztdummy. I'm asking if the requirement is necessary. Yes and no. Recent advances in Linux (RT patches, Hi-Res timers) that are approaching a merge to the mainline kernel raise the possibility that timing could be migrated to the core of Asterisk. Reminder: on Linux Asterisk depends (for part of its functionality) on some kernel-level code (zaptel) that shows no signs of being merged into kernel.org's kernel. Thus Fedora's maintainer, for instance, won't touch it. -- Tzafrir Cohen icq#16849755 +972-50-7952406 [EMAIL PROTECTED] 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
Re: [Asterisk-Dev] any reason for #define FREE in the code ?
Luigi Rizzo wrote:
there are a few files, probably derived from some old template,
that still have these blocks:
#ifdef __AST_DEBUG_MALLOC
static void FREE(void *ptr)
{
free(ptr);
}
#else
#define FREE free
#endif
This is being done because there are API calls in those files that pass
the _address_ of free() to another function, and when AST_DEBUG_MALLOC
is enabled then free is a macro (with additional arguments), not a function.
___
--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
