[Spce-user] Fwd: 404
Andreas Granig
agranig at sipwise.com
Tue Nov 13 13:32:36 EST 2012
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
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 897 bytes
Desc: OpenPGP digital signature
URL: <http://lists.sipwise.com/pipermail/spce-user_lists.sipwise.com/attachments/20121113/e5428200/attachment-0001.asc>
More information about the Spce-user
mailing list