[OpenSIPS-Users] Multiple Area Codes in Customer Area
Bogdan-Andrei Iancu
bogdan at voice-system.ro
Wed Aug 26 10:50:52 CEST 2009
Hi Duane,
You can replace the complicated:
subst_uri('/^sip:([0-9]+)@(.*)$/sip:$avp(s:areacode)\1@\2/i');
with more nicer:
$rU = $avp(s:areacode) + $rU;
Regards,
Bogdan
osiris123d wrote:
> Got it working! Man OpenSIPS sure can do anything with SIP
>
> So here is what I did for future searchers
>
> So the users account is a 7 digit DID number XXXXXXX at blah.com
>
> I set up an AVP called areacode for the whole domain blah.com (this assumes
> that the whole domain blah.com is only in one areacode)
>
> opensipsctl avp add -T usr_preferences 0 at blah.com areacode 1 201
> opensipsctl avp add -T usr_preferences 0 at foo.com areacode 1 339
>
>
> In the opensips.cfg file I do the following (it depends on your config as to
> where you want to put this)
> if (uri=~"^sip:[2-9][0-9]{6}@") {
> avp_db_load("$ru/domain","$avp(s:areacode)");
> subst_uri('/^sip:([0-9]+)@(.*)$/sip:$avp(s:areacode)\1@\2/i');
> };
>
> So when someone calls a 7 digit number the avp_db_load() loads the variable
> for areacode and the subst_uri adds the areacode at the beginning of the
> Request-URI.
>
>
>
>
>
>
> Bogdan-Andrei Iancu wrote:
>
>> Hi Duane,
>>
>> You can correlate AVPs you a USER, a DOAMAIN, etc - it is up to you,
>> from the script, when loading the AVP - is a pure logical mapping.
>>
>> Regards,
>> Bogdan
>>
>> osiris123d wrote:
>>
>>> 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
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>>
>
>
More information about the Users
mailing list