[OpenSIPS-Users] Multiple Area Codes in Customer Area
osiris123d
duane.larson at gmail.com
Wed Aug 26 18:07:21 CEST 2009
Nice.
Thanks for the help
On Wed, Aug 26, 2009 at 10:55 AM, Bogdan-Andrei Iancu (via Nabble) <
ml-user+121376-262234704 at n2.nabble.com<ml-user%2B121376-262234704 at n2.nabble.com>
> wrote:
> 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
> >>>>>
> >>>>> [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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opensips.org/pipermail/users/attachments/20090826/828162b6/attachment.htm
More information about the Users
mailing list