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: asterisk-users-bounces@lists.digium.com
[mailto:asterisk-users-bounces@lists.digium.com]On Behalf Of Michael
George
Sent: woensdag 1 maart 2006 15:48
To: asterisk-users@lists.digium.com
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