On Mon, 2009-06-15 at 14:36 -0400, Dale Worley wrote:
> The use-case for XX-5173 is given as:
>
> The need for supporting extensions having prefix as + arises
> while using bandwidth.com as the ITSP. The Bandwidth numbers are
> in the default E.164 format, which is '+14444444444' . Hence it
> is mandatory that the SCS extensions have a prefix of +1 to
> receive the Inbound calls.
>
> It seems to me that supporting extensions with prefix + is not a good
> solution for this use-case and probably isn't sufficient to solve the
> use-case, either.
>
> In the use-case, we assume that the request-URI has user-part
> "+144444444", and that it is not translated further within sipX. (If it
> was translated into a shorter extension that was all digits by some
> mechanism, we wouldn't need to support an extension containing "+".)
> And we assume that "+144444444" is delivered to and accepted by the
> conference server. (The details of that were clipped in the above
> quote.) But that would leave us in the strange state that an internal
> phone couldn't call that line on the conference server, since few phones
> can dial "+".
>
> To make this situation work smoothly, the configuration needs to
> translate the incoming URI "+144444444444" into the appropriate internal
> dial string (usually a short suffix of the DID number, like "444"),
> which has to be all-digits. Which eliminates the need to have
> extensions contain "+". (Although we may need to allow extension
> *aliases* to contain "+".)
I agree that for supporting inbound calling to an E.164 number (which is
what that '+' really signifies - that this is a globally complete phone
number), using a dial rule to map it to an internal form is preferred,
even if that rule just strips the '+' off.
Such rules are easy to construct.
Tony replied:
> FWIW - We strip the "+1" of incoming calls with bandwidth.com in our
> ingate as part of it's own dial plan. This allows the aliases to
> remain 10 digits. I think it's a good idea to leave the manipulation
> in sipxbridge, and that function would have to be created and added to
> sipxbridge.
I _strongly_ prefer that we _not_ modify addresses _anywhere_ but in
sipXproxy (yes, I know sipXbridge will do some of this - I consider that
feature a bug). The reasons for this are pretty simple:
* We don't need to - everything ends up going through the proxy
anyway.
* If we have more than one place that can change addresses, then
there's more than one way to do things, which means there are
more places to check when they don't work, and more ways to get
them wrong.
SIP routing is hard to debug (that's why I have a little text file to
paste into mail messages on how to collect a trace). We can't really
fix that, ultimately, but we can minimize the number of variables.
Yes, other systems that are used with sipXecs can change addresses,
including phones, gateways, SBCs, and who knows what else. If you want
your system to be easy to debug, I recommend that you _not_ use those
features. If someone can describe a real world addressing problem that
cannot be solved by rewriting addresses in the proxy (by which I mean
the sipXecs proxy/registar combination, really), I will cheerfully
accept that as a bug report and try to get it fixed.
_______________________________________________
sipx-dev mailing list [email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
sipXecs IP PBX -- http://www.sipfoundry.org/
