Re: [asterisk-dev] measure call quality for performance test
Jared Smith [EMAIL PROTECTED] writes: On Mon, 2008-01-28 at 14:41 -0500, Di-Shi Sun wrote: We plan to do the performace test again with bi-direction media stream. Somebody mention to us that we should measure the call quality. Does anybody have ideas about how to do it? Does Asterisk provide any support for it? You may want to go look up RTCP and start looking to see if your endpoints will send RTCP reports. I've found this is a first good step in monitoring call quality. Are there any good tools for looking at RTCP reports? Wireshark is a bit cumbersome for the job, and the Asterisk support for storing RTCP values for statistics seems a bit lacking still. Or maybe I just don't know how to use it properly, that's certainly likely. It would be nice if something like the patch from http://bugs.digium.com/view.php?id=10590 would be accepted into 1.6. /Benny ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] RFT: Expanded DNS SRV handling in Asterisk 1.4
JT == John Todd [EMAIL PROTECTED] writes: JT Here's why I ask: I've had first-hand experience with JT prioritized/weighted SRV records that cause serious problems. JT Someone puts 10 10 _sip._udp.inside-proxy.foo.com as their first JT SRV record for foo.com, and 20 20 JT _sip._udp.outside-proxy.foo.com as their second preference SRV JT record for foo.com. The host inside-proxy isn't reachable from JT the Internet. Therefore, every call attempt that goes to their JT domain goes first to a proxy that times out (wait... wait... JT wait...) and then goes to the second one that completes. This JT leads to unacceptable timeouts, and eventually leads to hard-coded JT SRV record data put into a local resolving nameserver (can you say JT domain hijacking for operational purposes?) to avoid the delay. JT This is Very Bad, and leads to User Anger. Isn't that a case of Doctor, it hurts when I...? I bet most SIP calls are between cooperating companies, so it should be possible to fix the problem correctly instead of doing workarounds. JT I guess I'm saying that SRV record lookups should be able to be JT turned off within Dial (which does exist today, despite my JT approval of SRV lookups being on by default) and a function that JT performs SRV lookups should be created so that the local JT administrator can start to create a good/bad list of possible SRV JT response entries for future use. This would not change the way * JT behaves today; it would simply provide an alternative for the more JT sophisticated administrator to control their own fate. I believe that is complication for no good reason. JT I'm all for SRV automation behind-the-scenes as the default JT behavior. However, I am less happy when there are no alternatives JT to letting an administrator do things in a better way. You can just ignore the SRV record and define your own IP-based peer. JT I'm sure I'm not alone here when I say that I dislike programs JT that think they're smarter than me and won't let me change the JT settings. I have never heard of a mail server which allows you to ignore certain MX records but obey the others. If you want to override MX for a certain domain, you create a policy for sending mail to that domain, and that ignores all the MX records. JT Summary: I'd love to see a function that resolves and returns an JT array-like set of SRV lookup results for a domain. Let the JT administrator write a routine that then runs through the various JT possible destinations. That on the other hand makes sense. If you keep all SRV priority handling out of asterisk itself, you can probably keep the asterisk code simple. There is a risk that the dial plan code gets too complicated though. /Benny ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[asterisk-dev] Retransmission timers, an old bug coming back
Back in 1.2.13 I discovered a bug,
http://bugs.digium.com/view.php?id=9020. Unfortunately the fix that
was backported from 1.4 to 1.2 was incomplete, and the problem still
persists in some cases in 1.2.24.
The problem is that sometimes asterisk will decide that a phone or
other asterisk is so close, that all retransmissions happen within
less than 100ms. That gives the other device no time to react to the
retransmissions, which ends up with this:
Oct 23 19:06:12 WARNING[3313] chan_sip.c: Maximum retries exceeded on
transmission [EMAIL PROTECTED] for seqno 102 (Critical Response)
The fix is easy:
--- asterisk-1.2.24.old/channels/chan_sip.c 2007-07-23 16:32:07.0
+0200
+++ asterisk-1.2.24/channels/chan_sip.c 2007-10-24 09:10:08.0 +0200
@@ -7412,7 +7412,7 @@
if (peer-callingpres)
p-callingpres = peer-callingpres;
if (peer-maxms peer-lastms)
- p-timer_t1 = peer-lastms;
+ p-timer_t1 = peer-lastms DEFAULT_T1MIN ?
DEFAULT_T1MIN : peer-lastms;
if (ast_test_flag(peer, SIP_INSECURE_INVITE)) {
/* Pretend there is no required authentication
*/
p-peersecret[0] = '\0';
You can check that the fix works with this patch:
--- asterisk-1.2.24.old/channels/chan_sip.c 2007-07-23 16:32:07.0
+0200
+++ asterisk-1.2.24/channels/chan_sip.c 2007-10-24 09:10:08.0 +0200
@@ -1225,7 +1225,7 @@
/* Too many retries */
if (pkt-owner pkt-method != SIP_OPTIONS) {
if (ast_test_flag(pkt, FLAG_FATAL) || sipdebug) /* Tell us if
it's critical or if we're debugging */
- ast_log(LOG_WARNING, Maximum retries exceeded on
transmission %s for seqno %d (%s %s)\n, pkt-owner-callid, pkt-seqno,
(ast_test_flag(pkt, FLAG_FATAL)) ? Critical : Non-critical,
(ast_test_flag(pkt, FLAG_RESPONSE)) ? Response : Request);
+ ast_log(LOG_WARNING, Maximum retries exceeded on
transmission %s for seqno %d (%s %s) -- timer_t1 is %d\n, pkt-owner-callid,
pkt-seqno, (ast_test_flag(pkt, FLAG_FATAL)) ? Critical : Non-critical,
(ast_test_flag(pkt, FLAG_RESPONSE)) ? Response : Request, pkt-timer_t1);
} else {
if (pkt-method == SIP_OPTIONS sipdebug)
ast_log(LOG_WARNING, Cancelling retransmit of OPTIONs
(call id %s) \n, pkt-owner-callid);
Then the warning messages will tell you what timer_t1 was set to, and
if it is lower than DEFAULT_T1MIN, the bugfix didn't help.
Anyway, I know this will not be applied to the 1.2.x series, since
that is security fix only, but now it is at least out there for those
who for some reason decide to not upgrade yet.
/Benny
___
--Bandwidth and Colocation Provided by http://www.api-digital.com--
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Better pattern matching
SM == Steve Murphy [EMAIL PROTECTED] writes: SM As far as AEL goes-- I don't understand the problem. What you SM said, in a different context: ...there is no way I'll touch C, SM which compiles to something as complicated as the current .asm ! There are excellent debugging tools for C, so much so that backtraces mention source lines -- you hardly ever need to refer to the actual asm. Also, asm is in most cases simple, and in the only other common case, at least thoroughly debugged. (Yes, I've read Intel errata sheets, and while they may be somewhat scary reading, the errata tend to be VERY obscure). SM I don't see how AEL's output is any worse than hand-written SM extensions.conf files. Someday, we might generate stuff with SM labels only, but never saw it as a requirement to do so; We aren't SM expecting folks to hand-edit the output of AEL. Doesn't make SM sense. Edit the source AEL file, and regenerate the file. It only SM takes a second. I don't want to edit the generated file, I just want to make sure that it's safe. And if I have to read it to make sure that it's safe, I might as well just write it in the first place. SM Tell me what's keeping you from adopting AEL, maybe we can make it SM easier for you. Just make an interpreter for the simpler and more regular syntax of AEL... /Benny ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [asterisk-users] AgentCallBackLogin vsAddQueueMember
SC == Steven Critchfield [EMAIL PROTECTED] writes: SC That statement isn't exactly correct. Just because you CAN write SC the code doesn't give you a vote. Think about the monkeys and SC typewriters quote. The vote only counts when code has been SC written, disclaimed, and presented for review. The merit is in the SC code, not the ability to code. Also, I bet votes are for sale by several asterisk developers. You don't actually have to write the code yourself, bribing someone else works too. /Benny ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[asterisk-dev] Re: extensions.conf included contexts priorities
AK == Andrew Kohlsmith [EMAIL PROTECTED] writes: AK That's exactly what I'd have expected to happen as well... If not, AK maybe some AK damn-i-seem-to-still-be-a-newbie-after-years-of-using-asterisk AK warning that states include statement encountered before end of AK context, this may not do what you expect it to do type of thing. How about a more general extensions not ordered, this may not do what you expect it to do? Or simply fixing the problem by turning off all this sorting and reordering... /Benny ___ --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: The New CDR system
SM == Steve Murphy [EMAIL PROTECTED] writes: SM FYI-- I've been collecting all the CDR related bugs. I have a SM branch, team/murf/bug8221-1.4, where I've been testing out fixes SM to problems reported. I'm about to clean it up and commit it to SM 1.4 and trunk. SM If there's one thing I've concluded, it's that there are some SM problems with the CDR system, and something different is in order. SM [insightful description of new system snipped] I think your approach sounds brilliant! One minor thing that is actually our particular biggest problem with the current CDR's: You cannot tell which phone touched the call last. If a call comes in from 555- and the phone foo does a redirect to 555-, no record of foo is in the CDR's -- so foo cannot be billed. In the new CDR system, redirects should be recorded as well /Benny ___ --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: Proposed Sound Acceptance Policy
SM == Steve Murphy [EMAIL PROTECTED] writes: SM In order to get sounds into the official tarball distributions, SM here is the requirements, as far as I can make out: SM 1. The scripts of the sounds are provided in English, in text SM format, 8859-1 format. If they are in English, what's wrong with plain ASCII? Going incompatible with UTF-8 just to be able to spell naïve seems a bit excessive. /Benny ___ --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: redirecting a call after a Queue
DB == Dov Bigio [EMAIL PROTECTED] writes: DB So, the idea would be to have a parameter for the Queue app that DB would be the extension to transfer the call to in case the call is DB finished by the agent. You can catch the call in the h extension (with a Goto). We have been playing with that; unfortunately not with complete success. /Benny ___ --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: Kernel modules = mainline kernel
OP == Oron Peled [EMAIL PROTECTED] writes: OP On Wednesday, 14 בFebruary 2007 01:40, Benny Amorsen wrote: OP == Oron Peled [EMAIL PROTECTED] writes: OP A host with several cards of different types (drivers) would have OP multiple 1000 interrupts/sec. Why? Just turn off interrupts on all the cards, and poll them every 1ms. Then you can call zt_transmit and zt_receive on all of them in order. OP In *different* drivers? Can you elaborate how one driver can poll OP cards handled by a different driver? True, one driver can't poll another drivers cards. Each driver can hang off the same timer interrupt though (by using the kernel timing infrastructure). OP That's why my original post highlighted the lack of a global OP zaptel tick that calls the low level drivers. OP Such (not existing yet) mechanism would make your claim valid. The mechanism is the generic kernel timing infrastructure. /Benny ___ --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: Kernel modules = mainline kernel
OP == Oron Peled [EMAIL PROTECTED] writes: OPThis means that even with an ideal low-level driver that OP generates only the theoretical 1000 interrupts/sec. A host with OP several cards of different types (drivers) would have multiple OP 1000 interrupts/sec. Why? Just turn off interrupts on all the cards, and poll them every 1ms. Then you can call zt_transmit and zt_receive on all of them in order. /Benny ___ --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: chan_sip - performance, and OPTIONS poking for 1000s of peers
JT == John Todd [EMAIL PROTECTED] writes: JT Perhaps if this became an option that these numbers would be JT settable from within sip.conf? I always get a vague feeling of JT unease when I see numbers like timers hardcoded into chan_sip... Tunables are a problem, everyone gets them wrong. IMHO this issue is being fixed in a way too heavy-handed way. Trying to reduce CPU load by adding rand() (not a fast function) and a modulo is a bit odd. /Benny ___ --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: chan_sip - performance, and OPTIONS poking for 1000s of peers
RM == Ryan Mitchell [EMAIL PROTECTED] writes: RM int to2 = DEFAULT_FREQ_OK + thread_safe_rand() % 8000 - 4; peer- pokeexpire = ast_sched_add(sched, to2, sip_poke_peer_s, peer); Would this code get run for each OPTION packet sent? If so, perhaps a less expensive random function could be found. Or maybe thread_safe_rand is already cheap enough, it just seems overkill for something with such a low requirement for randomness quality. /Benny ___ --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: How to busy out PRI channels?
TM == Tony Mountifield [EMAIL PROTECTED] writes: TM But does it stop new calls coming in while it's waiting for the TM existing calls to finish? I suspect not. It does. It returns an error when someone tries to open a call on the PRI while it is shutting down. Still, it would be very useful to be able to do it for just one span instead of killing the whole PBX. /Benny ___ --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: autoconf issues for FreeBSD
DN == Dinesh Nair [EMAIL PROTECTED] writes:
DN FreeBSD has a policy of separating what's part of the base system
DN which sits in /usr/bin, /usr/sbin, /usr/lib etc and what comes in
DN from ports which goes into /usr/local/{bin,sbin,lib,etc}. while
DN this may seem confusing to non-FreeBSD users, it has become second
DN nature to FreeBSD users.
So why doesn't the C compiler in FreeBSD look in /usr/local/ for
includes and libraries?
/Benny
___
--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: [PATCH] CLID spoof option added to Dial application
TH == Tony Howat [EMAIL PROTECTED] writes: TH This patch adds an s(callerid:calleridname) option to dial which TH overrides normal clid alterations within dial. It is necessary TH as in some applications you wish to Dial a number and spoof the TH CLID. eg. I have an application where I need to outdial to a TH secure line where the PBX will only accept calls with a certain TH CLID - this doesn't match my normal CLID which I don't actually TH want to alter. Why don't you want to alter your normal CLID? You can save it in a variable if you need it after the dial. /Benny -- http://www.ipvision.dk/ Hosted VoIP PBX ___ --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: IAX native bridge and NAT
TD == Tim Davies [EMAIL PROTECTED] writes: TD Not that I have cut any code yet, but... As far as I know, the TD current transfer code only uses the call number and a transfer id TD to verify the host. Hardly a security measure, it is really just TD to make sure the correct channel is bridged. I hadn't intended on TD changing this. It can be a perfectly good security measure; it can prevent attacks coming from third-parties which are unable to listen in. Assuming that the call number and transfer ID are sufficiently hard to predict, of course. If the attacker can listen in on the original path, all bets are off though. Cryptography would be needed to defend against that. /Benny ___ --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
