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