[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.
Yes.
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
sufficient.
regards
klaus
More information about the asterisk-dev
mailing list