I had the same problem with Callweaver 1.2 4274 svn revision.
The solution for me:

type=friend
fromuser=something
trustrpid=yes

I have multiple sip trunk, which are distinguashed by the fromuser. For right callerid presentation I use username from the Remote-Party-Id header. For this i use trustrpid setting.

I had the same problem (two accounts with the same provider) and all the incoming calls ended up in the same context (the last one configured in the conf file). I solved this with the information I found here: http://www.aussievoip.com.au/wiki/How+to+get+the+DID+of+a+SIP+trunk

Basically all I had to do was to look at the "To" field in the SIP headers and the number of the account from which the call was coming in was there. I changed extensions.conf like this:

[DID_trunk_1_and_2]
exten = _X.,1,Goto(DID_trunk_with_number,${CUT(CUT(SIP_HEADER(To),@,1),:,2)},1)

[DID_trunk_with_number]
exten = <number1>,1,Goto(default|<ext1>|1)
exten = <number2>,1,Goto(default|<ext2>|1)

Now if a call comes from account with <number1> extension <ext1> rings, and if the call comes from account with <number2> then extension <ext2> rings.

I'm still facing this problem. Is there a solution in the mean time ?

I have the same problem. When an incoming call arrives from provider, always matching to the first 'peer', what are in sip show peers output. How can I control this procedure? It's a big problem, because the phones using this accounts simultaneously, I need to know, which one is free for dialout.

I have the same problem. When an incoming call arrives from provider, always matching to the first 'peer', what are in sip show peers output. How can I control this procedure? It's a big problem, because the phones using this accounts simultaneously, I need to know, which one is free for dialout.

Hi I have got this working but it did take some figuring out. It appears that when looking for a matching incoming SIP peer that * starts at the bottom of the sip.conf file and works up. Therefore the last one to put in is the incoming calls peer. You can put the other peers for outgoing calls above them and still use them no bother by calling them directly e.g. Dial(SIP/{THEPHONENUMBER}@provider_line1). I'd be interested to hear if this works for anyone else.


general
bindport=5060
bindaddr=0.0.0.0
context=default
disallow=all
allow=gsm
allow=ilbc
allow=ulaw
allow=alaw
srvlookup=yes

register => 3377:???????@2x2.2x3.x56.2x6
register => 3378:???????@2x2.2x3.x56.2x6

3377
type=friend
host=dynamic
defaultip=192.168.1.12
username=3377
secret=3377
context=default
dtmfmode=rfc2833
mailbox=3377
callerid="SPA1" <3377>
nat=no

3378
type=friend
host=dynamic
defaultip=192.168.1.12
username=3378
secret=3378
context=default
dtmfmode=rfc2833
mailbox=3378
callerid="SPA2" <3378>
nat=no

provider_line1
type=peer
host=2x2.2x3.x56.2x6
username=3377
secret=???????
context=testA
fromuser=3377
fromdomain=2x2.2x3.x56.2x6
nat=no

provider_line2
type=peer
host=2x2.2x3.x56.2x6
username=3378
secret=???????
context=testB
fromuser=3378
fromdomain=2x2.2x3.x56.2x6
nat=no

provider-in
type=peer
host=2x2.2x3.x56.2x6
context=default
insecure=invite
nat=no



The result is that SIP SHOW PEERS gives me

myserver*CLI> sip show peers
Name/username Host Dyn Nat ACL Port Status
provider-in 2x2.2x3.x56.2x6 5060 Unmonitored
provider_line2/3378 2x2.2x3.x56.2x6 5060 Unmonitored
provider_line1/3377 2x2.2x3.x56.2x6 5060 Unmonitored
3378/3378 192.168.1.12 D 5061 Unmonitored
3377/3377 192.168.1.12 D 5060 Unmonitored
5 sip peers 5 online , 0 offline

Where you can see everything is in the reverse order of sip.conf.

I am guessing here that * works down this list and applies the first rule it can...

I forgot to mention, this should work with a single account that does incoming and outgoing by the way. The key there is to use the insecure=invite setting as this is what causes the 407. You will still authenticate on outgoing connections, just not incoming ones (which would seem to be what we want)

provider.tld ; incoming and outgoing
type=peer
host=2x2.2x3.x56.2x6
username=3378
secret=???????
context=testB
fromuser=3378
fromdomain=2x2.2x3.x56.2x6
insecure=invite
nat=no

Havent really tested it in depth but pretty sure it was one of the things I had tried in arriving at the solution below.

see http://www.voip-forum.com/news.php?p=187

I had the same problem (3 accounts at Sipphone.com) and I finally eliminated it be using the following entery in sip.conf:

sipphone-inbound
type=user
host=proxy01.sipphone.com
context=incoming-sipphone

With just this entry in sip.conf and my 3 register => statements in sip.conf I get calls in to my extensions file where they are matched against Sipphone's fake number (begins with 1747...)

Unfortunatley I can no longer send outbound calls to Sipphone as I had to remove the following outbound entry in sip.conf:

sipphone-outbound
context=incoming-sipphone
type=peer
indecure=very
host=proxy01.sipphone.com
username=17476489138
fromuser=17476489138
secret=XXXXXXX
fromdomain=proxy01.sipphone.com

The sip.conf entry above was catching all the inbound INVITE messages from Sipphone and asking them to authenticate themselves (407) after which the call would disapear.

I signed up with Draytel for my outbound calls.

I hope we get a better soultion to thie problem from someone....

ok, but what about this case:

I have 3 different accounts with the same SIP provider. That leads me to have 3 different "register" commands on my sip.conf file.

If i issue the SIP SHOW PEERS command I can see the 3 accounts registered, but they are all registered with the same IP/PORT, as my SIP provider sends all the calls from the same IP/PORT (I guess that's pretty normal).

Then, if somebody calls me, no matter which one of the 3 telephone numbers they dialed, the incoming call always match the first register found on my Asterisk box. This is a big problem on my case since I need to know exactly which number the caller person has dialed.

My first thought was that user/password would be great to solve this issue, but now I'm a bit confused.

Any suggestions or ideas on how to re-configure Asterisk to handle this case correctly?