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 <[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 -- Shaun Hofer System Administrator Altcall Pty Ltd Telephone: +61 (07) 55913588 Facsimile: +61 (07) 55916588 Email: [EMAIL PROTECTED] ******************************************************* 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. _______________________________________________ --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
