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