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 >>> >>> [email protected] >>> >>> >>> >>> 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. [email protected]), and configured >>>>> an >>>>> alias that included the DID for that person (ex. [email protected]). >>>>> >>>>> 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 >>>> [email protected] >>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>> >>>> >>>> >>>> >>> >>> >> _______________________________________________ >> Users mailing list >> [email protected] >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >> > > _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
