[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Sip] Proposal for 'Transfer-From' INVITE header.
Title: Message
Hello
All,
I am usually a
passive reader of this forum, but there has been an issue that my development
group has been struggling with for a while. We have been using a 'proprietary'
header for some time, for which I am hoping to legitimize via a draft or get
information as to existing solutions.
On most PBX and key
system digital stations, in order to perform a supervised transfer of a call,
the transferee is put onhold and a new call is automatically created in the
dialtone state. The transfer target is then dialed on the new dialtone call. If
the transferor decides to complete the transfer, the transferor usually either
hangs up or presses a transfer key to complete the transfer.
This scenario is a
two-step transfer process:
1) Put transferee
onhold-pend-transfer, which creates new call to be dialed on to reach transfer
destination.
2) Complete
transfer.
The two-step
transfer process allows the transferor to possibly abort the transfer, drop the
transfer destination and reconnect to the transferee call.
In implementing a
PBX/SIP gateway to PBX/key systems that operate in this manner, we have a
problem with Re-INVITE (hold), INVITE (new party), REFER/replaces to perform the
transfer. When the gateway receives the Re-INVITE (hold) method, the gateway
does not know the 'intent' of the hold request. Is it a regular 'put the call
onhold', or is the requestor intending to later make another outbound call on
the same line and transfer the original call. On a PBX, the 'intent' needs to be
known upfront, since the way that the call is put onhold depends on the intent
of the requester (put the call onhold so another call can be made, or put the
call onhold-pend-transfer to eventually dial a transfer
target).
In order to support
this functionality, we have been using our own 'Transfer-From' header. The
'Transfer-From' header is placed in the INVITE that the requestor sends to dial
the transfer destination. The 'Transfer-From' header specifies the call-ID
of the transferee call that the gateway should put onhold-pend-transfer. The
destination specified by the INVITE in the To header is then dialed as the
transfer destination. If the requestor later sends a REFER/replaces specifying
the transferee and the transfer target, then the gateway completes the transfer.
The requestor can also send a BYE or CANCEL on the transfer target dialog to
drop the transfer target and unhold the original transferee call. Media is then
re-established to the original transferee call upon the gateway receiving a
Re-INVITE (unhold) request.
I know that this is
very specific to a PBX-gateway device, but is what we are doing relevant to any
other interfaces/implementations? Is this header viable in any broader sense, is
it worth a draft, or is there an existing standard for this type of
functionality?
Thank you for your
help.
Tom Greier
Intel Corporation
Network Building
Block Division
55 Dodge Rd.
Getzville, NY 14068