<div>see <a href="http://www.voip-info.org/wiki/view/Asterisk+SIP+user+vs+peer">http://www.voip-info.org/wiki/view/Asterisk+SIP+user+vs+peer</a></div>
<div>perhaps it can help you <br><br> </div>
<div><span class="gmail_quote">2006/8/11, Rich Adamson <<a href="mailto:radamson@routers.com">radamson@routers.com</a>>:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Shaun Hofer wrote:<br>> ok maybe I can explain my problem better. There two trunks both have the same<br>
> details except one is type=peer (and only does ulaw) and the other is type<br>> friend (and does ulaw/alaw/g729). Incoming calls should be only going into<br>> the type=friend trunk, NOT into the type=peer trunk. Both should be able to
<br>> make out going calls. Yet depending on the order in sip.conf, the type=peer<br>> will receive calls.<br>><br>> Marco I understand how type works, thats not the problem. It seems Asterisk is<br>> sending incoming calls to a trunk that has type=peer. As you clearly pointed
<br>> out to every one else that this shouldn't be happening.<br><br>If I recall correctly (and that could be an issue), Olle posted<br>something a month or so ago relative to this. I believe he was heading<br>in a direction that essentially did away with this friend, peer, user
<br>stuff. I'm thinking that same post talked about which parameters were<br>used for finding a match, and the ordering of those parameters (eg, IP,<br>username, secret).<br><br>I didn't save the post, but maybe he'll read this and repost something
<br>more accurate then my memory. ;)<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> <a href="http://lists.digium.com/mailman/listinfo/asterisk-users">http://lists.digium.com/mailman/listinfo/asterisk-users</a><br></blockquote></div><br>