I have the same "problem". My solution is differentiate in extensions.conf, since all calls are terminated to different MSISDN's.
So in extensions.conf I have something like: [incoming] exten => 9995551212,1,Goto(company1-context,s,1) exten => 9995551213,1,Goto(company2-context,s,1) etc. Rene Kluwen Chimit -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Michael George Sent: woensdag 1 maart 2006 15:48 To: [email protected] Subject: [Asterisk-Users] SIP contexts being confused I have an * system running version 1.0.8 and it works mostly fine. I am using it as a virtual PBX and we share the box among companies. I have the calls all staying separate, we well as the companies' extensions, voicemail, etc. The only problem I'm having is with two accounts that use the same SIP termination provider. * seems to be confusing the sip contexts for the incoming calls. The sip contexts involved are: [Cust1_in] canreinvite=no context=incoming fromdomain=voip.provider.net host=voip.provider.net fromuser=9995551212 username=9995551212 nat=no type=friend disallow=all allow=g729 musiconhold=Cust1 accountcode=Cust1 amaflags=documentation [Cust2_in] canreinvite=no context=incoming fromdomain=voip.provider.net host=voip.provider.net fromuser=9995551213 username=9995551213 nat=no type=friend disallow=all allow=ulaw musiconhold=Cust2 accountcode=Cust2 amaflags=documentation There is no SIP registration involved because the service provider knows the address of the PBX server and will contact that address for calls on either trunk. I'm not sure that "fromuser" and "username" are even being used by the provider or *. However, *all* calls coming in for either account are reported in "show channels" and the verbose output as being from the second context. Also, * is negotiating the codec based on that latter context, so when the channels should be 729, they are being negotiated as ulaw. I was tempted to blame the provider, but if I change the order of these two entries in sip.conf, then the Cust1_in context is used. All calls appear as coming from that SIP channel and the incoming calls fail because it will only allow 729 and the provider only allows ulaw. [I have analogous Cust1_out and Cust2_out contexts for outgoing calls, but they seem to work fine.] It's almost as though the call comes in from the provider and the IP address is looked up in a table to find the context that applies. Asterisk then looks for an entry with that IP address, finds the last of these two in sip.conf, and uses that for the incoming channel. So it appears that we cannot have two customers with this SIP provider and keep things straight. It is possible that the problem is a shortcoming with the provider, but it's looking more like a shortcoming with *. Can anyone help me by offering a solution and/or explanation of what's happening here? If I need to provide more information, I'd be happy to. I'm sure the vPBX concept will work well, but this problem is holding everything up. If I cannot fix it, we cannot continue selling slots on the vPBX. Thank you! -- -M There are 10 kinds of people in this world: Those who can count in binary and those who cannot. _______________________________________________ --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 _______________________________________________ --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
