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: m...@lynk.com<mailto:m...@lynk.com>
Phone: 616-532-4985
_______________________________________________
sipx-users mailing list
sipx-users@list.sipfoundry.org
List Archive: http://list.sipfoundry.org/archive/sipx-users/
