[Spce-user] Fwd: 404
Jeremie Chism
jchism2 at gmail.com
Tue Nov 13 13:36:05 EST 2012
WOW! Thanks for taking the time to write all this down. I appreciate it.
Now im going to take some time to analyze all of this.
On Tue, Nov 13, 2012 at 12:32 PM, Andreas Granig <agranig at sipwise.com>wrote:
> Hi Jeremie,
>
> As Skyler already pointed out, don't do this.
>
> Sit back, breath deeply, and listen:
>
> 1. On the CE, you've a subscriber "13184504920 at 107.7.157.250" with an
> E164 number "+1 318 4504920", and I suppose to put the "1" into the cc
> field, the 318 into the ac field, and the 4504920 into the sn field when
> creating the subscriber, right?
>
> 2. You peering provider sends you a call with
> R=sip:3184504920 at something, so you see the "1" is missing there. Don't
> worry, this is normal, and that's exactly where rewrite rules come into
> play.
>
> 3. In order to find a subscriber on the CE based on what a peer or
> another subscriber is dialing, you need to craft rewrite rules which
> take the dialled number and put them exactly into the format
> <cc><ac><sn>, which in your case would be "13184504920". I don't know
> about US dial plans, but as far as I understood it, numbers holding the
> cc, the ac and the sn are always 11 digits long, however you're allowed
> to leave the ac (the "1" out), leaving it 10 digits long. So what you
> can do is creating an "Inbound Rewrite Rule for Callee", like this:
>
> "^([0-9]{10})$" -> "1\1"
>
> So what does this do? It checks in the received user-part of the R-URI
> (3184504920) in your case from start to end (which is what the ^ and $
> do) if there are 10 consecutive numberic characters there. What it also
> does is saving the matched characters into "\1" by enclosing it with (),
> so you can reuse it in your replacement part again. In the replacement
> part, it inserts a "1" and then the digits saved in the matching
> patterns. So basically it checks if its a purely numeric string (by
> using "[0-9]"), it checks if it's 10 digits long (the "{10}" part, which
> makes sure the pattern in front of it is matched 10 times), and if it
> matches, it pefixes it with a "1".
>
> This rule would match any 10-digit long number, like 0123456789,
> 9876543210 etc. Now you probably know that the number will never start
> with a "0", so you can refine your rule a bit:
>
> "^([1-9][0-9]{9})$" -> "1\1"
>
> So what did we do here? We check if the first character is a digit from
> 1 to 9, and then there must be 9 consecutive characters which can range
> from 0-9. So this will NOT match 0123456789 anymore, but 9876543210 is
> perfectly fine. Again, if it matches, it adds the "1" in front of the
> matched string by saving it in () in the match part and reusing it with
> \1 in the replacement part.
>
> Regarding saving matched parts of your string, you can use it as often
> as you want. The first () will be stored in \1, the second () in \2 etc.
>
> So what if someone doesn't dial "3184504920", but "+13184504920"
> instead? In this case, you must strip off the leading "+" again to end
> up with your final "13184504920", so we can create an additional rule
> (e.g. below the other one), doing this:
>
> "^\+(1[1-9][0-9]{9})$" -> "\1"
>
> So what happend here? We're checking if the number starts with a "+"
> (you need to escape the literal "+" sign, as it has a different meaning
> in regular expressions - e.g. "1+" means match one or more "1"
> characters, similar to "1{9}" means match exactly 9 "1" characters),
> then if the next character is a "1", then there is one character in the
> range 1 to 9 and then 9 characters in the range 0 to 9. If this is the
> case, we're just re-using what we saved between our (), which is
> everything except for the "+" sign.
>
> You can be brave and combine these two rules we discussed now into one,
> like this:
>
> "^(\+1)?([1-9][0-9]{9})$" -> "1\2"
>
> Hold on, what happended here? We're checking if the number starts with
> "+1" and group it into \1, but the "?" sign afterwards tells the
> matching engine that the group is optional ("?" means match the pattern
> in front zero or one times, like the "+" says one or more time and the
> {5} means exactly five times). So again, it checks if there is a "+1" in
> front, and if so, save it into \1, if not, an empty string is saved into
> \1. Then we do the check you're already familiar with from above,
> checking if there is a digit from 1 to 9, and then 9 digits from 0 to 9,
> saving it into \2.
> In the replacement part, we set a "1" and then the part matched in the
> second (), so pretty much the same as in our first/second example.
>
> Easy, eh? :D
>
> These rewrite rules are extremely powerful as you can map any dialled
> string into anything you want. It's just quite difficult to catch on in
> the beginning. You might want to execute "perldoc perlre" on you CE
> machine, it's an in-depth documentation of regular expressions. There's
> also plenty of material on the web and even books. Dive into it, it's
> worth it.
>
> Andreas
>
> On 11/13/2012 06:41 PM, Jeremie Chism wrote:
> > I figured it out (I think). All i had to do was leave the 1 out on the
> > sip URI when setting up the subscriber. Is there a problem with doing
> this?
> >
> >
> > On Tue, Nov 13, 2012 at 11:24 AM, Skyler <skchopperguy at gmail.com
> > <mailto:skchopperguy at gmail.com>> wrote:
> >
> > Depends on your desire, I strip leading '+' in all four in/out
> > callee/caller. could do the same with 10-digits to 11-digits I think.
> >
> >
> >
> > On Tue, Nov 13, 2012 at 9:19 AM, Jeremie Chism <jchism2 at gmail.com
> > <mailto:jchism2 at gmail.com>> wrote:
> >
> > ok. thank you for this help. this is inbound rewrite rules for
> > callee right?
> >
> >
> > On Tue, Nov 13, 2012 at 11:16 AM, Skyler <skchopperguy at gmail.com
> > <mailto:skchopperguy at gmail.com>> wrote:
> >
> > Also, watch out for this:
> >
> > /2 <-- wrong
> > \2 <-- correct
> >
> >
> > Skyler
> >
> > On Tue, Nov 13, 2012 at 9:02 AM, Skyler
> > <skchopperguy at gmail.com <mailto:skchopperguy at gmail.com>>
> wrote:
> >
> > I don't have that in my box but off the top of my head
> > (not tested) would look something like:
> >
> > ^([2-9][0-9]{8})$ ${caller_cc}\1
> >
> > or
> >
> > ^([2-9][0-9]{8})$ 1\1
> >
> >
> > Skyler
> >
> > On Tue, Nov 13, 2012 at 8:53 AM, Jeremie Chism
> > <jchism2 at gmail.com <mailto:jchism2 at gmail.com>> wrote:
> >
> > Do you have a standard rewrite rule for this. I am
> > going to ask my upstream but not sure i will get
> > much of a reply.
> >
> >
> > On Tue, Nov 13, 2012 at 10:49 AM, Skyler
> > <skchopperguy at gmail.com
> > <mailto:skchopperguy at gmail.com>> wrote:
> >
> > No problem. Just for future, this type of issue
> > really only need to see the INVITE and not
> > necessarily the whole call flow in a capture. ;)
> >
> > The R=sip:3184504920 <tel:3184504920> is the
> > problem because SPCE bases all routing decisions
> > on the R-URI (Request URI) which is what the 'R'
> > in the logs is.
> >
> > S
> >
> > On Tue, Nov 13, 2012 at 8:44 AM, Jeremie Chism
> > <jchism2 at gmail.com <mailto:jchism2 at gmail.com>>
> > wrote:
> >
> > My email was probably going out as you were
> > sending yours.
> >
> >
> > On Tue, Nov 13, 2012 at 10:42 AM, Skyler
> > <skchopperguy at gmail.com
> > <mailto:skchopperguy at gmail.com>> wrote:
> >
> > Jeremy,
> >
> > Slow down, read your INVITE.
> > .....
> > INVITE sip:3184504920 at 107.7.157.250
> > <mailto:sip%3A3184504920 at 107.7.157.250>
> > SIP/2.0'
> >
> > Also in the
> > log.....R=sip:3184504920 at 107.7.157.250
> > <mailto:3184504920 at 107.7.157.250>
> >
> > What Jon is saying is that clearly,
> > 3184504920 <tel:3184504920> is NOT a
> > valid number on your SPCE box. Your peer
> > is sending you a request for 10-digits
> > but SPCE only uses 11-digits. You need
> > to either ask upstream to send you e164
> > (11-digits) or you need a rewrite rule
> > that matches 10-digits and ... adds a 1
> > in front.
> >
> > Skyler
> >
> >
> >
> >
> >
> > --
> > Jeremie Chism
> > Triton Communications
> >
> >
> >
> >
> >
> >
> > --
> > Jeremie Chism
> > Triton Communications
> >
> >
> >
> >
> >
> > --
> > Jeremie Chism
> > Triton Communications
> >
> >
> > _______________________________________________
> > Spce-user mailing list
> > Spce-user at lists.sipwise.com
> > http://lists.sipwise.com/listinfo/spce-user
> >
>
>
> _______________________________________________
> Spce-user mailing list
> Spce-user at lists.sipwise.com
> http://lists.sipwise.com/listinfo/spce-user
>
>
--
Jeremie Chism
Triton Communications
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sipwise.com/pipermail/spce-user_lists.sipwise.com/attachments/20121113/bafc7833/attachment-0001.html>
More information about the Spce-user
mailing list