[asterisk-dev] [Code Review] SIP: Pineapple

Klaus Darilion klaus.mailinglists at pernau.at
Fri Oct 23 10:13:44 CDT 2009

Michiel van Baak schrieb:
> On 14:57, Fri 23 Oct 09, Klaus Darilion wrote:
>> Michiel van Baak schrieb:
>>> On 17:05, Thu 22 Oct 09, Klaus Darilion wrote:
>>>>> And we have a good couple of setups that have an asterisk box specific
>>>>> for routing, it grabs the calls from ITSP and landlines and routes those
>>>>> calls to other boxen. Most of them use a different route when setting up
>>>>> an outbound call.
>>>>> Many many possibilities that dont match the simple setup you described.
>>>> The thing is: the SIP channel needs not be aware of how you use the 
>>>> "trunks". Even if you do specify a trunk as outgoing-only, this can not 
>>>> avoid that the other side can send you calls over this "trunk".
>>> Agreed.
>>>> As you handle LCR in the dialplan (not in the SIP channel) you can 
>>>> decide in the dialplan too if you use a "trunk" for in, out or both. 
>>>> Don't make the SIP configuration to complex.
>>> I guess it would be enough (see your previous mail with the comments on
>>> my reply) to route the incoming calls to an empty context for a trunk
>>> you only want to use for outbound.
>> So we have two possibilities:
>> 1. Let the user handle this by explicitly making an empty context in 
>> extensions.conf and specify this empty context in the relevant "trunk" 
>> section.
>> 2. make the "trunk" option direction=[in|out|both] where:
>>    "out": all incoming requests gets rejected with 403
>>    "in":  all Dial(SIP/trunkname) attempts will cause
>>           immediate CHANUNAVAIL
>>    "both": allows both directions
> 3. If a trunk is only for outgoing calls, don't specify a context.
> Then it will default to 'default' (or whatever you configured in the
> global sip settings) and you are not accepting calls there either right
> ? (maybe some for ENUM stuff, but those should be named anywayz)
> Not using a trunk for outbound calls is as simple as never using
> Dial(SIP/trunkname)
> I think 3. is all we need and already available at the moment.

Actually your 3. is identical to my 1.

More information about the asterisk-dev mailing list