Scott Lawrence wrote:
On Thu, 2009-02-12 at 12:37 -0500, Dale Worley wrote:
Generally, allowing an alternative form of anything is increasing
complexity and will cause difficulties. In this case, '+' is a
perfectly valid character for user-parts, and RFC 3261 specifies that
sip:+1...@domain is different from sip:1...@domain.
In regard to DIDs from ITSPs, one generally wants the ingress gateway to
translate the request-URI from whatever format the ITSP provides to the
form used internally within the sipX system.
I disagree - I think that you only want to modify addresses in the call
routing core (proxy/redirect servers). Spreading those changes around
through a larger number of components makes debugging flows much more
difficult.
The subject usecase can be facilitated in two ways:
1. On the Devices-->SBCs-->Internal SBC-->SIP screen set up the
"incoming call destination" as conference extension.
(Now, this would */hard code/* the incoming call destination on the
sipXbridge, thereby making all inbound calls through any ITSP, terminate
at the conference extension)
2. Create a custom dial plan such as ( *Dialed number* 'Prefix'
+19497776946 and 0 digits , *Resulting call*, 'Dial' 9497776946 and
append 'Nothing' )
where 9497776946 is the bandwidth directory number (which can be
assigned as Conference, ACD or Hunt group extension).
(here any Incoming call arriving with a +19497776946 results in getting
*re-routed* to 9497776946)
Other than these, we also have a bunch of testcases wherein we assign
the Conference/ACD line/Hunt group extension as the ITSP directory (DID)
number, so that when an outside caller dials the directory number, he
directly reaches these extensions (without any re-routing). These set of
testcases have already been tested with BT BBV and callwithus ITSP's
without any issues . Since an Inbound call made using bandwidth.com
reaches SCS as +19497776946 and +19497776946 cannot be assigned to any
of the above extensions, these set of testcases will fail as far as
bandwidth.com is concerned.
Thanks,
Chaitra
_______________________________________________
sipx-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
