[Asterisk-Users] SIP contexts being confused

[Michael George]

On Wed, Mar 01, 2006 at 10:39:36PM +0100, Rene Kluwen wrote:
> 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)

I have done something similar.  So the calls are being handled
correctly as the progress through the system.

The problem is that when doing a "show channels" all connections from
either trunk are indicated as being from the last one in sip.conf.
Also, and this is the bigger problem, I don't have the control over
codecs that I would like.

To allow 729 for one trunk and ulaw for the other requires that both
trunks be defined to allow both codecs and hope that the VoIP provider
will always prefer the right one.

Question for you: In your sip.conf for your two SIP trunks, do they use
any authentication (username and password) or do they use IP exclusively
to "determine" the trunk?

Thank you for your reply!

> -----Original Message-----
> From: asterisk-users-bounces at lists.digium.com
> [mailto:asterisk-users-bounces at lists.digium.com]On Behalf Of Michael
> George
> Sent: woensdag 1 maart 2006 15:48
> To: asterisk-users at 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
> 
> 
> 
> _______________________________________________
> --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
> ---
> [This E-mail scanned for viruses by Declude Virus]
> 
> 

-- 
-M

There are 10 kinds of people in this world:
	Those who can count in binary and those who cannot.