[asterisk-users] SIP trunks: order or type

[Shaun Hofer]

ok maybe I can explain my problem better. There two trunks both have the same 
details except one is type=peer (and only does ulaw) and the other is type 
friend (and does ulaw/alaw/g729). Incoming calls should be only going into 
the type=friend trunk, NOT into the type=peer trunk. Both should be able to 
make out going calls. Yet depending on the order in sip.conf, the type=peer 
will receive calls.

Marco I understand how type works, thats not the problem. It seems Asterisk is 
sending incoming calls to a trunk that has type=peer. As you clearly pointed 
out to every one else that this shouldn't be happening.

-Shaun

On Thursday 10 August 2006 21:04, Marco Mouta wrote:
> Just a question:
>
> Don't you need type=user to receive in this trunk?
>
> As far as I know, peer is where you dial calls, and user is where  calls
> can be placed.
>
> To outbound a call from you * box via SIP trunk, this trunk must be
> type=peer or type=friend
> To inbound calls to * box via SIP trunk , this trunk must be type=user or
> type=friend.
>
> "friend=user+peer"
>
> peers cannot place calls into the Asterisk server
>
> http://www.asteriskpbx.com/
>
>
> Best regards,
> Marco Mouta
>
> On 8/10/06, Shaun Hofer <shaun.hofer at altcall.com> wrote:
> > I have two trunks to the same machine (x.x.x.2), one is type=friend,
> > other is
> > type=peer. Asterisk seems to choose which trunk to use by the order by
> > which
> > they are set out in sip.conf.
> > When a incoming call comes into Asterisk, it always uses the last trunk.
> > My
> > understanding was that a peer trunk can't receive incoming calls. Does
> > Asterisk ignore the type when dealing with incoming calls from the same
> > host/machine ?
> >
> > I want all incoming calls to use the back-trunk only. When I change the
> > order
> > around from what it looks like below it works perfectly. I've been told
> > that
> > order of things appearing in sip.conf should not matter.
> >
> > --Shaun
> >
> > sip.conf:
> > [back-trunk]
> > type            =  friend
> > username        =  8880006111
> > secret          =  vvvvvv
> > host            =  x.x.x.2
> > dtmfmode        =  rfc2833
> > nat             =  no
> > canreinvite     =  no
> > insecure        =  port,invite
> > qualify         =  no
> > disallow        =  all
> > allow           =  ulaw
> > allow           =  alaw
> > allow           =  g729
> > context         =  shared-back-trunk-incoming
> >
> > [back-trunk-ulaw]
> > type            =  peer
> > username        =  8880006113
> > secret          =  vvvvvv
> > host            =  x.x.x.2
> > dtmfmode        =  rfc2833
> > nat             =  no
> > canreinvite     =  no
> > insecure        =  port,invite
> > qualify         =  no
> > disallow        =  all
> > allow           =  ulaw
> > context         =  shared-back-trunk-ulaw-incoming
> >
> > Asterisk CLI:
> > Aug 10 12:17:15 DEBUG[21756]: chan_sip.c:7242 check_user_full: Setting
> > NAT on
> > RTP to 0
> >
> > Aug 10 12:17:15 DEBUG[21756]: chan_sip.c:10497 handle_request_invite:
> > Checking
> > SIP call limits for device 8880006113
> >
> > Aug 10 12:17:15 DEBUG[21756]: chan_sip.c:1401 __sip_ack: Stopping
> > retransmission on '79119-3364165035-362070 at x.x.x.x' of Response 1: Match
> > Found
> >
> > _______________________________________________
> > --Bandwidth and Colocation provided by Easynews.com --
> >
> > asterisk-users mailing list
> > To UNSUBSCRIBE or update options visit:
> >    http://lists.digium.com/mailman/listinfo/asterisk-users

-- 
Shaun Hofer
System Administrator
Altcall Pty Ltd
Telephone: +61 (07) 55913588
Facsimile: +61 (07) 55916588
Email: shaun.hofer at altcall.com

*******************************************************
If you receive this email by mistake, please notify us and do not make any
use of the email.  We do not waive any privilege, confidentiality or
copyright associated with it.