There are a number of different things going on here that we have to keep straight.
If we want to allow extensions (user-parts) that contain '+' (and '+' is allowed by SIP in user-parts), then of course, we have to change the various input fields to allow that. But in *this* case, we aren't talking about having an extension containing '+', we are considering +1234 as an alias for 1234 -- the real extension number is 1234, we just have cope with Bandwidth.com sending it to us as +1234. So we shouldn't be configuring various components to expect certain extensions with prefix '+', because those aren't the real extension numbers. What we are dealing with is a mapping that converts the Bandwidth.com-supplied format (with the prefix '+') to the proper format (without) -- and possibly deletes leading '1', area codes, or other stuff -- whatever is needed to convert the Bandwidth.com format to the form used within sipX. The simplest and most controllable way to do this is with a special mapping (dial) rule. (I think that there are some exceptions where the mapping can or must be done in the ingress gateway, in particular where the incoming user-parts overlap and conflict with the dial plan used within sipX, or with the dial plans used by other ingress gateways. But that is a nasty can of worms, and we shouldn't try that until we know that sipXconfig has proper control over the mapping function in the ingress gateway.) 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
