Subject: [Sip] Challenges when interworking QSIG and SIP Call Transfer

From: [email-masked]
Date: Fri, 13 Dec 2002 14:57:36 +0100

When trying to put together some interworking scenarios between SIP call
transfer and QSIG call transfer, some problems were identified. The
purpose of this E-mail message is to solicit advice on how these
problems could best be tackled. In the below text, SIP terminology is
used, rather than telecoms terminology. Therefore, parties that would
normally be referred to as "Party X or X-Party" are being referred to
as Transferor, Transferee and Transfer Target. Hopefully, this makes the
text more readable. 

Currently there is no specific SIP mechanism to notify parties involved
in SIP call transfer that a call transfer is taking place or has taken
place, without establishing a new session. I.e. the notification of
transfer and the communication of identities is solved (for attended
transfer only) by including a Replaces "header" in a SIP URI in the
Refer-to header in a REFER (to the Transferee) and/or by including a
Replaces header in an INVITE (to the Transfer Target). 

The current mechanisms are sufficient to effect the call transfer, but
in some cases the Transferee and/or the Transfer Target will not be
aware of what is going on. In particular in interworking scenarios with
QSIG, some difficulties have been identified. 

Below, first an attempt to analyse the situation for a pure SIP
situation is presented. The purpose of this is to determine if the
problems that were identified for QSIG interworking scenarios have a
broader scope. 

The "All" SIP situation 

The below examples are based on the situation that the Transferor has a
session established with both the Transferee and the Transfer Target.
For the purpose of this analysis, this will be referred to as "attended
transfer". 

1) When the Transferor does not support the use of the
Replaces header in the Refer-to URI, neither the Transferee, nor the
Transfer Target can be explicitely aware of a transfer. This knowledge,
however, could be inferred from the fact that the calls between the
Transferor and the Transferee and between the Transferor and the
Transfer Target are terminated shortly after the new call between the
Transferee and the Transfer Target has been established. Both the
Transferee and the Transfer Target are aware of each other's identity
because the Tranferee establishes the new session with the Transfer
Target. 

2) When the Transferor does support the use of the Replaces
header in the Refer-to URI, but the Transferee does not, the situation,
could be identical to the above one, provided that the Transferee simply
ignores this header. An alternative could be that the Transferee does
not interpret this header and simply copies it into the INVITE to the
Transfer Target. The Transfer Target, depending on its capabilities, can
then be aware of the fact that a call transfer is taking place. The
Transferee will not be aware of this. The Transferee and the Transfer
Target are aware of each other's identity. 

3) When the Transferor and the Transferee support the use of
Replaces header in a Refer-to URI and the Transfer Target supports
the use of the Replaces header in an INVITE message, both the Transferee
and the Transfer Target are aware of the transfer and the identities of
the new parties in the call. 

Summarising the above situations, it can be stated that in all the above
cases the Transferee and the Transfer Target are aware of each other's
identity, but may not be aware of the fact that a transfer has taken
place. When all involved parties know about support the use of the
Replaces header (in a Refer-to URI and/or an INVITE message), the
Transferee and the Transfer Target are both aware of transfer taking
place and the identities of each other. The means of "signalling" that a
transfer is taking place is the Replaces header (either in a Refer-to
URI or in an INVITE message). 

For situations in which the Transferor does have a session established
with the Transferee, but not with the Transfer Target (prior to sending
a REFER message to the Transferee) the situation is somewhat simpler.
For the purpose of this analysis, this will be referred to as "unattended
transfer". It is not possible to use the Replaces header (either in a
Refer-to URI or in an INVITE message) because there is no session to
replace. Therefore, neither the Transferee nor the Transfer Target are
explicitely aware of the fact that a transfer is taking place. The
Transferee and the Transfer Target are aware of each other's identity. 

Interworking scenarios with QSIG 

When interworking with QSIG call transfer (attended transfer) or QSIG
single step call transfer ("unattended transfer"), the situation is
different. Two examples (one for attended transfer and one for
unattended transfer) are given below. 

1) Attended transfer. 

The Transferor is in QSIG and the Transferee and the Transfer Target are
in SIP. When the Transferor performs a Call Transfer by join, it will
send a notification to both the Transferee and the Transfer Target and
then connect the B-channels of the respective calls. 
Each notification will arrive at a SIP gateway, which has an established
session with either Transferee or the Transfer Target. No SIP signalling
is required to "connect" these two sessions at the Transferor. Although
it may be desirable (from a SIP point of view or for QoS reasons) to
have the Transferee establish a session with the Transfer Target, this
would complicate matters from the QSIG point of view: The (QSIG)
Transferor assumes that it is in control over the two calls and the
associated B-channels. Relinquishing control to the Transferee would cut
the Transferor out of the picture. Furthermore, the Transferor in this
situation is a node in the QSIG network and we cannot assume that this
node will be upgraded in order to support calls via gateways to/from
SIP. In any case, such a node is unlikely to be aware that the
transferee and transfer target are in a SIP network, and therefore will
not be in a position to treat such a scenario differently from a normal
QSIG-only scenario. 

To be able to inform the Transferee and the Transfer Target about the
transfer that took place and about the identities of the new parties in
the call, the options that are available today would seem to be the
following: 

- send a new INVITE with a Replaces header to both the Transferee and
  the Transfer Target. The destination of the INVITE, however, has to
  support the Replaces header to avoid undesirable side effects.

- send a re-INVITE, optionally with a Referred-By header, to both the 
  Transferee and the Transfer Target. Although the meaning of 
  "Referred-By" is not that a call transfer took place, subsequent 
  release of the already established sessions (in combination with 
  Referred-by) could be used as a strong hint that call transfer did 
  take place.

- send a REFER to the Transferee (with the address of the GW in the
  Refer-to URI) and an INVITE with a Replaces header to the Transfer
  Target. 

These methods seem to generate a lot of messages and processing, while 
the only purpose of the establishment of the new sessions is to inform 
both parties about the transfer and/or the identities of the new 
parties. 

2) Unattended transfer. 

The Transferor is in QSIG and the Transferee and the Transfer Target are
in SIP. When the Transferor performs an unattended transfer, it can
establish a call with the Transfer Target (which also notifies the
Transfer Target that a transfer is taking place) and notify the
Transferee about the fact that a transfer is taking place and about the
progress of this new call. When the new call is established, the
B-channels of the two calls can be connected at the Transferor. There is
no way to inform the Transfer Target that this call is the result of a
transfer. There is no way to inform the Transferree that transfer is
taking place. The only way to "repair" this situation would seem to be
the use of the options mentioned in the previous example. Another 
possibility, is that the INVITE to the Transfer Target contains
history-info with a new reason code to indicate transfer.

Several interworking scenarios between SIP and QSIG for call transfer 
present this sort of problem. In most cases it would be sufficient if it 
were possible to simply send a notification message (i.e. a message that 
does neither modify the characteristics of the session nor its state) to 
the Transferee and/or the Transfer Target. (An example this could 
be a be a SIP INFO message with a P-Asserted-Identity header)

Any comments and/or proposals on the above are welcomed. 

Regards,

Frank
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Rohan Mahy <[email-masked]>
Date: Sun, 15 Dec 2002 23:31:14 -0800

Hi,

I appreciate the thorough analysis in your mail.  I plan to reply to 
the content of your message shortly. However, I wanted to reply to your 
mail right away with an important list management issue.

In the spirit of reducing cross postings between SIP and SIPPING, I am 
removing SIP from this reply.  This is purely a SIPPING issue, so 
everyone please do not post/reply to both lists. I think this is 
especially important when we are also cross posting to another 
standards group mailing list.

many thanks,
-rohan