It’s really not the ‘s’ option. It’s the context.
Contexts are a way to segment the services and connections of an Asterisk server.
In your system, you had your sip device (in this case, a client with a phone number of 6042887777) as part of a context called from-sip (Well, originally. CustomGT had you change that to from-sip-6042887777.)
Calls originate at a particular channel, and inherit the “context” assigned to that channel. When Asterisk checks the extensions.conf file to see what to do with that call, it starts in the default context. If the default context doesn’t have instructions, it must have an include statement to allow the call to check other contexts for further instructions.
If you start in another context, Asterisk checks for routing instructions in that context.
The order that they are listed is somewhat important. If determines which context is checked first, second, third and so forth. If you want calls that seek outside trunks to try your SIP provider first, and then try a local analog line (because the SIP calls are cheaper than analog) you’d might list it like this:
include => sip-provider
include => local-line
Now, you COULD have simply put all of the lines you had for the 6042887777 sip client into the default context. But, as CustomGT said, it makes things a bit messy when you just pile everything into default. Segmenting things with contexts allows you to have more control.
However, when you design your extensions.conf file to use that control, you need to take the extra steps necessary to tie everything together, with consideration for the order you want events to happen.
In your case, if you had simply added the incude => from-sip to the bottom of your list of include statements like this:
include => internal
include => out-pstn
include => from-sip
The incoming calls will start the services in the first context that they find has instructions that they can execute. If there is an ‘s’ instruction in the internal context, it’ll always choose that first, and never make it to the from-sip context to dial your station.
You have to think about the events you’d like to have happen. (Like ringing a station, and starting an IVR application.) Build those events in individual contexts, and then put those events into the system in the order you’d like them to occur.
I would have done this…
include => from-sip
include => internal
include => out-pstn
…if I wanted to have a sip client that may or may not be registered, and I wanted that sip client to be the first thing to ring for incoming calls if it was registered. If that sip client wasn’t registered, I’d have the system try the internal context where it would find my IVR that would allow callers to leave me a message, or find other information in an automated way.
