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] <mailto:[email protected]>
Phone: 616-532-4985
------------------------------------------------------------------------
_______________________________________________
sipx-users mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-users/
