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

Klaus Darilion klaus.mailinglists at pernau.at
Thu Oct 22 10:00:38 CDT 2009

Alexander Harrowell schrieb:
> On Thursday 22 October 2009 10:47:18 Olle E. Johansson wrote:
>  > 22 okt 2009 kl. 11.30 skrev Nick Lewis:
>  > > oej
>  > >
>  > > re new types: I like the proposal to have peer types related to the
>  > > actual network architecture rather than the barmy type=user/peer/
>  > > friend
>  > > but I find the actual words you have chosen to be confusing. The
>  > > relationship that you name "service" is what I regard as a sip trunk
>  > > and
>  > > which I get from my internet telephony service provider.
> Yes - is it really a common use case to have end points or trunks that 
> are one-way (as the current typing implies)? I'm sure there will be 
> fancy deployments that have phones attached that are only ever used for 
> inbound, or that send their outbound traffic to a different carrier than 
> they receive inbound from. But I would suspect 90-odd % of Asterisk 
> instances have a SIP carrier on one side carrying both inbound and 
> outbound (i.e. a "friend" in currentspeak) and Linksys desk phones on 
> the other that both receive and place calls.


Further, if a "frog|trunk" supports to handle incoming and outgoing, you 
do not have to use both directions if you do not want, e.g. the "trunk" 
will never be used as outgoing unless there is a Dial() command with the 
"trunk" name, and incoming can be directed to a dummy context/exten if 
incoming calls should not be handled on this "trunk". Thus, IMO make 
incoming-trunks and outgoing-trunks seems to be overhead for me. Just 
having a "trunk" (IMO this term is better to be used for Asterisk<->ITSP 
services) which supports in&out, and having the option "register=yes" is 


More information about the asterisk-dev mailing list