Nice. Thanks for the help
On Wed, Aug 26, 2009 at 10:55 AM, Bogdan-Andrei Iancu (via Nabble) < [email protected]<ml-user%[email protected]> > wrote: > Hi Duane, > > You can replace the complicated: > > subst_uri('/^sip:([0-9]+)@(.*)$/sip:$avp(s:areacode)\...@\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)\...@\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 > >>>>> > >>>>> [hidden > >>>>> email]<http://n2.nabble.com/user/SendEmail.jtp?type=node&node=3516196&i=0> > >>>>> > >>>>> > >>>>> > >>>>> 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. [hidden > >>>>>>> email]<http://n2.nabble.com/user/SendEmail.jtp?type=node&node=3516196&i=1>), > and configured > >>>>>>> an > >>>>>>> alias that included the DID for that person (ex. [hidden > >>>>>>> email]<http://n2.nabble.com/user/SendEmail.jtp?type=node&node=3516196&i=2>). > > >>>>>>> > >>>>>>> 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 > >>>>>> [hidden > >>>>>> email]<http://n2.nabble.com/user/SendEmail.jtp?type=node&node=3516196&i=3> > >>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>>> > >>>> _______________________________________________ > >>>> Users mailing list > >>>> [hidden > >>>> email]<http://n2.nabble.com/user/SendEmail.jtp?type=node&node=3516196&i=4> > >>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > >>>> > >>>> > >>>> > >>>> > >>> > >>> > >> _______________________________________________ > >> Users mailing list > >> [hidden > >> email]<http://n2.nabble.com/user/SendEmail.jtp?type=node&node=3516196&i=5> > >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > >> > >> > >> > > > > > > > _______________________________________________ > Users mailing list > [hidden > email]<http://n2.nabble.com/user/SendEmail.jtp?type=node&node=3516196&i=6> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > ------------------------------ > View message @ > http://n2.nabble.com/Multiple-Area-Codes-in-Customer-Area-tp3419932p3516196.html > To unsubscribe from Re: Multiple Area Codes in Customer Area, click here< > (link removed) =>. > > > -- -- *--*--*--*--*--* Duane *--*--*--*--*--* -- -- View this message in context: http://n2.nabble.com/Multiple-Area-Codes-in-Customer-Area-tp3419932p3517646.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
