>>> On 6/15/2009 at 2:36 PM, in message <[email protected]>, "Dale Worley" <[email protected]> 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 "+".) > > 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/ >
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. Since a normal SBC can strip the "+", is it reasonable to assume the function should be added to sipxbridge as the sbc (or the gateway)? The alternative is to create a phantom user right now and forward those calls (with the alias of "+" on the phantomn user) to the itended service or recipient. Right now, using sipxbridge, aliases do have to contain "+1<10_digits_here>" to receive a call. Tony Tony _______________________________________________ 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/
