Page 388 - Asterisk™: The Future of Telephony

allowed_failed_screen
Presentation allowed, failed screen
allowed
Presentation allowed, network number
prohib_not_screened
Presentation prohibited, not screened
prohib_passed_screen
Presentation prohibited, passed screen
prohib_failed_screen
Presentation prohibited, failed screen
prohib
Presentation prohibited, network number
unavailable
Number unavailable
=yes|no
canreinvite (both)
The SIP protocol tries to connect endpoints directly. However, Asterisk must re-
main in the transmission path between the endpoints if it is required to detect
DTMF (for more information, see Chapter 4):
canreinvite=no
context (both)
A context is assigned to a channel definition to direct incoming calls into the
matching context in extensions.conf, where call handling is performed (see Chap-
ters Chapter 4 and Chapter 5). Any channel connecting to an Asterisk machine has
to have a context defined into which it will arrive. The context is essential for any
user channel definition; if you do not define a context, incoming calls will be di-
rected to the default context:

context=incoming
You should be aware of an unusual scenario that will require a
context definition for a peer. When a call comes through the SIP
channel, it first tries to find a matching user definition (based on
the user name in square brackets and the secret). If it can’t find any
matching users, it then looks for matching peers, based on the IP
address that the call is coming from. Since peers don’t normally
have contexts, this will cause such a call to arrive in the default
context. While this will work, the default context shouldn’t really
be used to handle incoming calls. The solution is to define a con-
text, on a per-peer basis, for any peers that might match on
incoming calls. To experiment with this, you can call your Free
World Dialup number; the call will come right back to you.

360 | Appendix A: VoIP Channels