[OpenSIPS-Users] Multiple Area Codes in Customer Area

Tue Aug 18 17:56:02 CEST 2009

I was reading Flavio's "Building Telephony Systems with OpenSER" chapter
about AVPOPs and he mentions that AVP's can be used for a whole domain.  I
was thinking that I might be able to configure a area code for Company A's
domain and then route calls that way.  If not that then I can set the AVP on
the fly within the transaction by looking at the callers Request URI's first
3 digits and route it appropriately.

Bogdan-Andrei Iancu wrote:
> 
> Hi,
> 
> Requirements on the format of  CONTACT and TO headers are nonsense as 
> they are not used for routing at all. Only FROM (which provides info on 
> the caller) and RURI (request URI) (which provide info on callee).
> 
> So, bottom line, only the normalization of the RURI should be required 
> on the system.
> 
> Regards,
> Bogdan
> 
> osiris123d wrote:
>> Thanks for the info.
>>
>> I will look into this and work up a config.
>>
>> I also got this direct email about my post from someone else who lives in
>> the US.  I figured I would go ahead and post below what he sent just so
>> its
>> out there.
>>
>>
>> Hello Duane --  
>>
>> You have hit on one of the more difficult areas in SIP and telephony in
>> general -- especially here in the North American Numbering Plan.  Below I
>> will address the problem in general, and not particularly related to the
>> OpenSIPs question, because IMO you need a solution that will work in any
>> architecture, not just OpenSIPs.
>>
>> In a nutshell, I recommend that for your USA users you:
>>
>> 1.) Require From: and Contact: headers to be in NANPA National (10 digit)
>> format.  This is method is standard in the telephone industry, and will
>> allow easy integration with North American ANI or Caller ID format,
>> especially when a call may eventually be handed off to the PSTN.   
>>
>> 2.)  Require incoming To: headers to be in e.164 International format,
>> i.e. 
>> NANPA-destination numbers all begin with the 1 digit, followed by the 10
>> digit National number.   Any incoming call to 612xxxxxxx goes to Sydney,
>> Austrailia, and not Minneapolis, MN.  This requirement should be enforced
>> at
>> the perimeter of your network, where Customer Equipment can enforce the
>> "local" digit normalization policy.  
>>
>> 3.)  If you can't enforce #2 above, you will need to "Normalize" incoming
>> calls to the e.164 International format prior to routing.  The
>> unfortunate
>> reality here in the USA is that the requirements for how many digits to
>> dial
>> for a given destination (the "dialing plan") depends on where the call
>> comes
>> from.   Here in the Chicago area, residents of the 847 area code must
>> today
>> dial all calls as 11 digits.  Calls within the 312 or 773 area code may
>> today be dialed as 7 digits, however beginning on 07 November, all calls
>> originating in 312 and 773 must be dialed as 1+10 digits, due to the new
>> 872
>> overlay area code.    For more information, see
>> http://www.nanpa.com/reports/NPA_Dialing_Plans_05_09.pdf
>>
>> 4.)  Finally, if you have any termination carriers who need special
>> "prefixes,"  append them after you have made your route selection.  
>>
>> If you would like further information or discussion, please feel free to
>> contact me.
>>
>> John S. RobiXXXX
>>
>> jXX at communXXX.com
>>
>>
>>
>> Bogdan-Andrei Iancu wrote:
>>   
>>> Hi there,
>>>
>>> When you have to deal with local dialling you need consider the amount 
>>> of information yon need to keep in order to translate to national format 
>>> and the complexity of the processing you have to do.
>>>
>>> A compromise solution will be to keep in user profile some information 
>>> about the location (like for US, the 2 digits Id of the state) - this 
>>> will reduce the amount of data you need to keep per user. Also, this 
>>> info can be loaded at auth time, using "load_credentials" parameter 
>>> (just an example).
>>>
>>> Now, using the location information, you can use dialplan to do the 
>>> actual transformation. Like, if location is NJ (use a separate plan):
>>>     if 7 digits -> put 011-201 prefix
>>>     if  10 digits -> put 011 prefix
>>>
>>> And so on...
>>>
>>> This works pretty fine and scale (not for local dialling but for 
>>> national dialling in international platforms).
>>>
>>> Regards,
>>> Bogdan
>>>
>>> osiris123d wrote:
>>>     
>>>> I was curious to see how people configure OpenSIPS when their customers
>>>> could
>>>> potentially be in different area codes.  I am located in the US.  Say I
>>>> have
>>>> customers that are in the following area codes
>>>>
>>>> 201-XXX-XXXX    <- New Jersey
>>>> 339-XXX-XXXX    <- Boston
>>>>
>>>> Initially when I was setting up users I configured the username to be
>>>> just
>>>> like the persons email address (ex. bobsmith at xyz.com), and configured
>>>> an
>>>> alias that included the DID for that person (ex. 2011XXXXX1 at xyz.com).
>>>>
>>>> So when bobsmith in New Jersey calls someone and just types 7 digits
>>>> then
>>>> obviously its local.  How do people out there using OpenSIPS usually
>>>> determine if the call is local or not?  I was thinking that I need to
>>>> swap
>>>> my username and alias around so that the username is the 10 digit DID
>>>> and
>>>> then I can look at the first 3 digits to see what the area code is.  My
>>>> other idea was to set up Groups for each area code and add the users to
>>>> their Area Code group and determine it that way.
>>>>
>>>> Am I looking at this the right way or am I making this more
>>>> complicated? 
>>>> I
>>>> would like to get my setup right the first time so that this config
>>>> scales
>>>> well.
>>>>
>>>> Thanks for any input.
>>>>   
>>>>       
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>>     
>>
>>   
> 
> 
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> 
> 

-- 
View this message in context: http://n2.nabble.com/Multiple-Area-Codes-in-Customer-Area-tp3419932p3466884.html
Sent from the OpenSIPS - Users mailing list archive at Nabble.com.