I think it is nice that they support it. Do they also support MOH from the phone and consultative AND blind transfers? They would typically want to insulate all the types of failure scenarios by letting you use a gateway/sbc that uses refer locally and inserts its own MOH that will successfully negotiate.
You should configure an unmanaged gateway to them and test the different call scenarios. REFER will be an issue with any ITSP unless they also support "Refer with Replaces". SIPCONNECT says the REFER should be locally handled. There were several discussions (dating back years) in the sip archives that disuss the question of whether or not sipXbridge should support REFER if the provider supported it (as a gateway level option). In the end, it was decided that REFER is an issue with ITSP's and will be for some time to come because of all the call cases which can pose a potential for call failure (consultative transfer, MOH, etc.). If it were me, and its not, I would do several call case tests with the ITSP as an unamaged gateway and see if the call fails. If so, I would repeat the failure and send a trace to the ITSP asking them to support "each failed call case". SBC's generally insulate this by performing the REFER locally. Whether it is an Ingate, OpenSBC, OpenSIPS or sipXbridge., its typical to do this in order to support SIPCONNECT. Does the switch vendor assure SIPCONNECT compatibility? On Tue, Sep 21, 2010 at 3:01 PM, Burden, Mike <[email protected]> wrote: > OK, the ITSP got a response from the soft-switch vendor: > > > > > > We need to clarify some points in order to be sure that we're on the same > > page. > > > > As was previously mentioned by my colleague according to our official > > documentation and the list of currently supported RFC (2327, 2543, 3261, > > 3262, 3263, 3264, 3265, 3311, 3323, 3324, 3325, 3428, 3489, 3515, 3581, > > 3842, 4566) the transfer feature is handling in PortaSwitch by REFER method > > (please see RFC3515 to familiarize with the method logic). And it's the > only > > one currently supported method for performing blind/attended transfer > within > > existent dialog. > > As we can see from the ticket's history, you're referring to re-invite as a > > method for transfer establishing. But it's used for modifying session > > description parameters within existent dialog (please see section 14 > > Modifying an Existing Session, RFC3261), such as codecs set, media ports, > > etc. The To, From, Call-ID, CSeq, and Request-URI of a re-INVITE are set > > following the same rules as for regular requests within an existing dialog. > > There are no tools, currently implemented in PortaSwitch that allows any > > kind of transfer using re-invite method. > > > > Please provide us with the link to the corresponding RFC that describes > > transfer using re-invite method, in order we can inform our Developers > about > > non RFC-compatible behavior of transfer feature. > > > > > > I had previously forwarded to them an excerpt from RFC3261: > > > > 14 Modifying an Existing Session > > > > A successful INVITE request (see Section 13) establishes both a > > dialog between two user agents and a session using the offer-answer > > model. Section 12 explains how to modify an existing dialog using a > > target refresh request (for example, changing the remote target URI > > of the dialog). This section describes how to modify the actual > > session. This modification can involve changing addresses or ports, > > adding a media stream, deleting a media stream, and so on. This is > > accomplished by sending a new INVITE request within the same dialog > > that established the session. An INVITE request sent within an > > existing dialog is known as a re-INVITE. > > > > Note that a single re-INVITE can modify the dialog and the > > parameters of the session at the same time. > > > > Either the caller or callee can modify an existing session. > > > > > > And if I read the Vendor’s response correctly, they are apparently saying > that this section of this RFC is not sufficient to indicate that a transfer > can be indicated by a re-INVITE rather than a REFER. > > > > Can someone tell me either: > > 1. Is there another RFC (or another section in RFC3261) that I overlooked > that spells this out more clearly > > or > > 2. Can someone tell me what specific parameters of the session are > changed by the re-INVITE when an internal transfer is performed? (I assume > that said parameters will all be in the list of things that can be changed > by a re-INVITE) > > > > > > > > Mike Burden > > Lynk Systems, Inc > > e-mail: [email protected] > > Phone: 616-532-4985 > > > > _______________________________________________ > sipx-users mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-users/ > -- ====================== Tony Graziano, Manager Telephone: 434.984.8430 sip: [email protected] Fax: 434.984.8431 Email: [email protected] LAN/Telephony/Security and Control Systems Helpdesk: Telephone: 434.984.8426 sip: [email protected] Fax: 434.984.8427 Helpdesk Contract Customers: http://www.myitdepartment.net/gethelp/ Why do mathematicians always confuse Halloween and Christmas? Because 31 Oct = 25 Dec.
_______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/
