The key here is to not discuss this with the switch vendor as a
call-transfer. Discuss it as changing the media stream in mid-dialog
via a reinvite. I they are not forwarding the re-invite, a lot of
stuffs may happen in the RTP stream that will result to a corrupted
audio session.
1. SSRC will change and will be dropped by the receiver
2. Timestamps/Sequence would change and would be dropped by the receiver
3. If the codec is changed, the payload size and type would change and
would be dropped by the receiver.
This list would go on. So the right question to post is if they support
re-invites and they seem to not relay it to the remote end, then that is
an outright noncompliance to the RFC... period! When you put them
on-hold, do they at least hear the MoH? That is not even transfer
yet. Thats just plain old re-invite. If they screw up at that point,
then there is no use discussing call-transfer even.
Joegen
On Wednesday, 22 September, 2010 03:01 AM, Burden, Mike 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] <mailto:[email protected]>
Phone: 616-532-4985
_______________________________________________
sipx-users mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-users/
_______________________________________________
sipx-users mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-users/
