Vandaag ontving ik een bericht dat mijn Google (tm) AdWords (tm) advertentie gewraakt was vanwege het gebruik van een handelsmerk in de advertentietekst.
Het woord in kwestie was Asterisk (tm) aangezien ik er in had staan dat ik een Asterisk specialist ben.
Het leukste daarbij is dat deze regel alleen van toepassing is in USA en Canada (volgens Google's eigen richtlijnen) tenzij de eigenaar van het handelsmerk er over klaagt!
Met andere woorden, iemand bij Digium (tm) heeft het bestaan om alle kleine advertenties op heel het Internet af te zoeken en voor alle gevallen waar hun woordjes in stonden een bericht aan Google te sturen!?!
Heeft er iemand zin om de woorden Metselaar, Schilder en/of Timmerman te trademarken? Hoe zit het met de woorden Tweede of Kamer?
Het leukste lijkt me om het woord Trademark of de afkorting TM te trademarken...
Vanzelfsprekend heb ik onmiddellijk mijn advertentie campagne helemaal gestopt, leverde toch al weinig tot niets op en als ik de producten niet in mijn advertentie mag noemen die ik ondersteun (en aanprijs!) dan heeft adverteren geen enkele zin meer!

I have created a full course on the below which you can take at www.centreforonlinelearning.com.

-------------

It is possible to capture a SIP/RTP call directly from the "wire" (Ethernet). This is the easiest to do when you have root access on the machine running Asterisk but can also be done using a softphone on a PC.

The program you need is called WireShark which is the successor of Ethereal.

Simply install it and start a capture. Place a call or wait for a call to take place.
Using the "Analyse" menu you can scan your capture(s) for SIP information (number and type of SIP messages and even isolate complete SIP dialogs).

Using the RTP option you can reassemble the complete call and even save the audio (payload) as a file to disk. Note that this only works reliably if you have at least the START of the call in your capture. You might need to tell WireShark explicitly that some UDP packets are in fact RTP as RTP does not use a specific port number, which may confuse WireShark.

Specifically of interest are of course any problems that WireShark detects like packets that are out of order, dropped (lost) packets or very long delta's (which cause gaps in the audio).

Note that if you save the payload many of this problems will be "corrected" and the audio may be much cleaner than was experienced during the actual call.

It is not possible on a switched Ethernet network to capture calls from "other people" unless you have control over a managed Ethernet switch (that is in the circuit) or have root access to the VoIP PBX (Asterisk) itself.

If you do not have a graphical environment on the server running the VoIP PBX you can still capture the VoIP traffic using "tcpdump -s0 -wfilename.pcap udp" (and probably some more options for the proper interface to use and so on). You can then transfer the "filename.pcap" file to a workstation that has WireShark installed to do the analysis.

Scanning large capture files is very memory and CPU intensive. It is most definitely NOT a good idea to do this on a "live" (operational) VoIP PBX directly. Running the tcpdump program is fairly light but can consume lots of disk space very quickly.

I have just posted a detailed description of the wrapuptime in queues.conf issue on the general Asterisk forum:

http://forums.digium.com/viewtopic.php?t=18838

As I described there, you may be able to work around the issue by setting a global wrapuptime in agents.conf

This entry is in English as it is probably of international interest.

One interesting concept that app_queue has is that a QUEUE has a wrapuptime, rather than an AGENT!

So, in short, if you have two queues (A and B), A with a wrapuptime setting of 30 seconds and B with a wrapuptime of 5 seconds, an agent that is in both queues will get a call only 5 seconds after the last call from queue A if the queue B has a waiting caller!

To further complicate this problem, the way app_queue determines if the agent is eligible is by comparing now against the time of the last call of the agent in this queue!

The latter issue clearly seems a bug and I'll try to submit that to the Asterisk community later this weekend.

The only work-around I can see is to make the agent pause immediately after handling a call, thus defeating the whole wrapuptime mechanism :(

Vandaag ben ik, in het kader van een vraag van een klant, bezig geweest om een gewone ISDN/2 kaart te gebruiken als telefonie kanaal in Asterisk.

De resultaten waren ronduit teleurstellend (sterker nog, binnen de beschikbare tijd heb ik de kaart niet werkend weten te krijgen) en ook op het Internet wordt er nogal geklaagt over deze optie (echo problemen, vastlopende Asterisk, enzovoorts).

Er bestaat een alternatieve oplossing voor de klassieke ISDN4k/CAPI aanpak, onder de naam VISDN, waar echter sinds oktober 2005 niets aan gedaan lijkt te zijn. Jammer want op zich ziet het er erg goed uit!

Kortom, voor professioneel gebruik van ISDN/2 (dus ook S0-bus) wil ik voorlopig de Sangoma A500 aanbevelen als goedkoopste optie (te vinden voor onder de 350 euro ex BTW voor het 2-poorts basismodel).