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 "+".)
Dale
_______________________________________________
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/
