On Wed, Nov 12, 2008 at 12:18 PM, Scott Lawrence <[EMAIL PROTECTED]> wrote: > > On Wed, 2008-11-12 at 10:49 -0500, M. Ranganathan wrote: >> On Wed, Nov 12, 2008 at 10:31 AM, Dale Worley <[EMAIL PROTECTED]> wrote: >> > On Wed, 2008-11-12 at 15:02 +0000, Scott Lawrence wrote: >> >> If we're going to support PBX-to-PBX we don't _need_ the ITSP, and we >> >> should not send the call to them in the first place. >> >> >> >> Let's keep our conceptual model clean here: an ITSP is a Gateway to the >> >> PSTN - it is NOT some kind of intermediary between us and any other >> >> SIP-capable system. If by chance we don't know the SIP address and send >> >> to the ITSP, and it sends the call with SIP directly to the target >> >> without actually going through the PSTN, that's fine, but to us it's all >> >> the same. >> > >> > I can easily imagine ITSPs making a business niche connecting SIP >> > systems, e.g., by providing QoS guarantees. If such an ITSP is >> > transparent, we should surely support it, but I expect that the real >> > world will be plagued by intermediate cases as well. >> > >> > Dale >> > >> > >> >> Actually the AT&T certification suite requires that two instances of >> pbx connect to each other via AT&T. They recommended that I do the >> test using loopback. > > Certifying is all well and good, but let's be clear - in a real > customer deployment we will encourage them to connect directly between > sites, not using any ITSP, so we shouldn't use this as a motivation for > any feature. > > >
Well, all this could be moot. When I send the REFER to bt.com , it sends me back a 202 Accepted and then drops the call with a BYE. AT&T simply does not allow you to send REFER and SIPCONNECT says the REFER should be locally handled. So the conclusion is we may be stuck with the current scheme of not forwarding REFER until ITSPs are able to handle it. Traces for BT.com available if anybody has the time/inclination to look at them. Thanks -- M. Ranganathan _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
