What is directmedia?

To put it simply, is the process where Asterisk tries to redirect the RTP media stream to go directly from the caller to the callee. Be careful that some devices do not support this (especially if one of them is behind a NAT). The default setting is YES.

When to use it?

If you have all clients behind a NAT, or for some other reason want Asterisk to stay in the audio path, you may want to turn this off.

If you want to allow media path redirection (reinvite) only when the peer where the media is being  sent is known to not be behind a NAT (as the RTP core can determine it based on the apparent IP address the media arrives from), set this to nonat.

What should I do in order to to be as secure as possible and with “clean” logs?

Well, for an article about Asterisk security best practices, consider reading this article.

About SIP and NAT best practices, in short, the simplest answer is to always use ‘nat=yes’ (or at least ‘nat=force_rport’ in recent versions of Asterisk that support it), until you come across a SIP endpoint that fails to work properly with that setting. If you do come across such an endpoint, try hard to get it to work with that setting; if you can’t, then set ‘nat=no’ for that endpoint, and understand that the endpoint’s name could be discoverable using the attack methods previously disclosed.

If the endpoint’s configuration is suitably locked down (permit/deny, for example) this may not be a concern for you. If it’s not locked down (for example, if it has to register to your Asterisk server from random locations), then the next step would be to seriously consider requesting that the user of that endpoint consider switching to some other SIP endpoint.

Finally, to date, the only endpoints that have been identified that do not work with Asterisk’s ‘rport’ handling forced upon them are Cisco phones. In that case, you could consider using a Digium IP phone in order to take the most out of your Asterisk Installation.

(Thanks to Kevin P. Fleming for his elaborated answers on the Asterisk Mailing List)

If you were wondering about the correct format of US numbers then this might come in handy. In short: The proper way to send CallerID number is 10 digit (from NANPA numbers), no preceding 1 or plus sign (+) as this is handled by the provider to the end user if at all.

How many numbers to send?
First of all, if you are sending a CLID inside the US (Home NPA Local Calls) you should not send more than 10 digits (do not include the ’1′) or your call might be considered ”Home NPA Toll Calls” or “Foreign NPA Toll Calls” and some providers might block you.

What does the plus (+) sign means?
When you are making a call, the plus sign (+) is an abbreviation that  means “this is an international call” and instructs your cellphone, for example, to replace “+” with whatever is the international dialing code for the location where it’s currently located (for example, in USA it would be replaced by ’011′). So, if you are sending a CLID, do not send it either.

If you receive a call and the CLID have the plus sign, it means that it is an overseas call.

Finally, the providers do not send 1 on the PSTN. The fact that you see a + in your CallerID is often because your mobile phone automatically fills it in, as well as the 1 (when the call is US).

If after installing Asterisk 10.1.1 you see the following errors on SIP reload:

This might be because a possible regression. Please open an issue in JIRA referencing this thread.

[1] http://svnview.digium.com/svn/asterisk?view=revision&revision=347727

Due to high volume of outbound calls you might be asked to alternate the outbound traffic by your termination provider.

Basically, what what you need to do here is: Having 2 destinations (Dst_A, Dst_B), check/set a variable in the AstDB. Then if the variable is 1, set it to 2 and route via Dst_A; otherwise, set it to 1 and route via Dst_B.

This code snippet might be what  you are looking for:

Maybe in a future you might want to think in another approach to this task, but in the meantime this might come in handy.