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 <[EMAIL PROTECTED] > 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 '[EMAIL PROTECTED]' 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



--
Com os melhores cumprimentos,

Marco Mouta
_______________________________________________
--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

Reply via email to