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 > > -- 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. _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
