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

From: Alan Johnston <[email-masked]>
Date: Fri, 13 Dec 2002 12:02:02 -0600

(response trimmed to the sipping list)

Frank,

I read your email with great interest - I have been looking forward to the 
day when we would begin discussing how to interwork QSIG features with SIP 
features.  This is important work, and I applaud you for reading the SIP 
and SIPPING documents relating to transfer and using SIP terminology in 
your discussion.

I would suggest you read one more important document that describes the SIP 
philosophy of service design, "A Multi-party Application Framework for SIP" 
(http://www.ietf.org/internet-drafts/draft-ietf-sipping-cc-framework-01.txt). 
Most of my answers (and the motivation) are better explained in the document.

Fundamentally, in SIP we don't standardize services or features, we just 
standardize the primitives (or protocol building blocks) that enable 
services to be implemented.  As such, there is no notion that a transfer 
target or transferee "understands" that it is participating in an attended 
transfer.  Only the transferor knows what service or feature is being 
invoked.  The other participants just follow the SIP requests and 
primitives and the net result is that an attended transfer has happened.

This might seem strange, and even a serious deficiency, to you and other 
QSIG experts, based on your description of how QSIG does features and 
services.  However, this is just how we do things in the IETF in general 
and specifically in SIP.

Now, this doesn't mean that SIP and QSIG can not interwork, but we need to 
figure out how to satisfy both service models.  The main goal is that the 
interworking function "speaks" standard SIP to the SIP endpoints and 
standard QSIG to the QSIG endpoints.  The result is that services and 
features interwork and neither network is even aware that interworking is 
taking place.

See more comments below.

Thanks,
Alan Johnston
WorldCom
sip:[email-masked]

At 02:57 PM 12/13/2002 +0100, [email-masked] wrote:
>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).

Replaces is a SIP call control primitive - it only means, replace an 
existing dialog with this new dialog.  It does not mean that a call 
transfer is taking place, or what kind of transfer it is.

>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.

This is true, and as described in the Multiparty Framework, by design.

>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).

No - Replaces does not mean this.  Replaces just has specific call control 
properties.

>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.

Interesting - this is a very different model.

>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.

No.  The way to interwork this is for the SIP/QSIG gateway (which appears 
to the SIP devices as just another UA) to translate the QSIG notification 
requests into a SIP REFER request.  The call flow on the SIP side would be 
identical to that if all parties were SIP phones.  To put it another way, 
the SIP transferee and target don't even know that the transferor is in 
fact a QSIG PBX.

>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.

The QSIG endpoint would not need to be upgraded - it would just think that 
it is talking to another QSIG endpoint.  It is the QSIG/SIP gateway that 
would perform the conversion.  In this true interworking scenario, neither 
the QSIG or SIP devices know that a gateway is in the middle, which is how 
it should be.

>  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.

But the QSIG/SIP gateway does, and it does the special protocol 
interworking on behalf of the QSIG endpoint.

>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:

None of these options are needed as the problem does not need to be 
solved.  My comments on the other scenario would just be repetitive, so I 
will stop here.

Hopefully this helps you understand the service and interworking philosophy 
of SIP.

>- 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

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

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 16 Dec 2002 10:23:33 +0000

Alan,

See my remarks in-line.

John Elwell
e-mail: mailto:[email-masked]

> -----Original Message-----
> From: Alan Johnston [mailto:[email-masked]]
> Sent: 13 December 2002 18:02
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: Challenges when interworking QSIG and SIP Call Transfer
> 
> 

[JRE] I can accept that the other participants do not need to know that
transfer is being invoked. But it is importnat that they are able to be
aware that the partner in the SIP dialog has changed. I don't think this is
out of line with the multiparty framework draft.

> features interwork and neither network is even aware that 

[JRE] I agree.

> This is true, and as described in the Multiparty Framework, by design.

[JRE] I don't think that lack of awareness of what is going on is part of
the design of the multi-party framework draft. For example, 4.4 of that
draft states "Participants should have access to information about the other
participants in a conversation space....".

> Interesting - this is a very different model.

[JRE] Yes, but transfer by join is the most commonly implemented model in
QSIG. Sometimes it is followed up by a "path replacement" feature that
optimises the circuit-switched path.

> the SIP transferee and target don't even know that the 

[JRE] This is one of the three ways suggested later on in Frank's original
message. The use of Replaces would be essential in this scenario, because it
is important that the INVITE request resulting from the REFER be routed back
to the same QSIG-SIP gateway and be used to replace the correct SIP dialog.
Interestingly the Replaces header would identify the dialog on which the
REFER was sent, not some third dialog as is the normal case for
REFER/Replaces in SIP. Would there be any adverse effects?

I would like to see some discussion of the pros and cons of the three
methods suggested by Frank.

> interworking on behalf of the QSIG endpoint.

[JRE] The difficulty with this scenario is that there are two different QSIG
gateways - one between the transferor and the transferee, and one between
the transferor and the transfer target. Each gateway will be unaware of the
other. It seems there is nothing that they can do to instigate a direct
dialog between the transferee and the transfer target. Therefore this is a
limitation we might have to accept for the scenario where transfer by join
takes place in the QSIG network and there are two separate gateways. It
might be possible to do more for the particular case where the two calls go
via the same gateway.

> solved.

[JRE] There IS a problem to be solved - to inform the transferee that he is
now connected to the transfer target and vice versa.

> My comments on the other scenario would just be 
> repetitive, so I 
> will stop here.
>

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 17 Dec 2002 08:22:57 +0000

Jonathan,

See in-line.

John Elwell

> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: 17 December 2002 03:37
> To: Elwell, John
> Cc: 'Patrick Mourot'; Francois Audet; 'Alan Johnston';
> [email-masked]; [email-masked]
> Subject: Re: [Sipping] Re: Challenges when interworking QSIG and SIP
> Call Transfer
> 
> 
> inline.
> 
> Elwell, John wrote:
> > Patrick,
> 
> > My take on the transfer by join service is that it may not 
> have much to 
> > do with REFER. 
> > 
> > I think solving the transfer by join scenario is very 
> important as it is 
> > very frequently used in TDM networks. 
> > 
> > Let's say A and B are in a session. B and C are also in a 
> session. B wants 
> > to transfer A to C. In a transfer by join (in traditional 
> networks), B 
> > will be kept in the signalling path, will bridge the A and 
> C locally, and 
> > them tell A and C that they are now talking to a different 
> user (done 
> > after the transfer). The important is that from a 
> signalling point of 
> > view, there is still a "call" from A to B and another one 
> from B to C. 
> > 
> > In SIP, it seems to me that this is very similar to third 
> party call control
> > 
> > scenario (
> > http://www.ietf.org/internet-drafts/draft-ietf-sipping-3pcc-02.txt
> > 
> <http://www.ietf.org/internet-drafts/draft-ietf-sipping-3pcc-0
> 2.txt> ). 
> > 
> > B would re-INVITE A with C's SDP, and re-INVITE C with A's 
> SDP. (There might
> > 
> > be some a=sendonly sent to place calls on hold but that is OK). 
> > At that point A and C would be communicating.  
> > 
> > [pm] In some cases the transferror does not the SDP 
> description of the
> > transferree and the transfer target  (i.e A & C behind 2 
> different GWs)...
> > so re-INVITE is not sufficient. I think we need another 
> INVITE towards A & C
> > and then use QSIG  "Facilitiy PathReplacePropose " to 
> update media path. 
> > 
> > [JRE] I think re-INVITE is indeed sufficient (along with 
> the other two
> > solutions suggested in the message from Frank that started 
> this thread). The
> > gateway between the transferor and the transferee would 
> send re-INVITE to
> > the transferee. The gateway between the transferor and the 
> transfer target
> > would send re-INVITE to the transfer target. The 
> interesting thing is that
> > SDP would not normally change. The only think that would 
> change would be the
> > identify of the source of the re-INVITE request (e.g., in the
> > P-Asserted-Identity header).
> 
> THis is not the intended use of P-Asserted-ID, and falls outside the 
> scope of its applicability. P-Asserted-ID allows one element, who has 
> authenticated the requestor, to inform another element (over 
> a trusted 
> link) about the identity of the requestor.
> 
> Here, you are trying to have one element tell another element 
> that its 
> media is actually coming from a different source. We have no 
> way to do 
> that in SIP.
[JRE] For a request coming from circuit-switched network, the
P-Asserted-Identity header needs to convey the identity of the entity in the
circuit-switched network that (indirectly) initiated the request. The
circuit-switched network is deemed to be sufficiently trusted that the
gateway can assert the identity of the entity concerned with confidence. I
don't see this as being different from other uses of the P-Asserted-Identity
header.

> 
> > 
> > Another alternative, similar to re-INVITE, would be UPDATE.
> > 
> > I believe the "replaces" mechanism 
> > ( http://www.ietf.org/internet-drafts/draft-ietf-sip-replaces-02.txt
> > 
> <http://www.ietf.org/internet-drafts/draft-ietf-sip-replaces-0
2.txt> ) 
> can be used to update the identity of the party.  
> 
> [pm] Same Problem as above. Moreover We never see re-INVITE containing a
> replaces.

Replaces has nothing to do with it.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Patrick Mourot" <[email-masked]>
Date: Tue, 17 Dec 2002 10:21:03 +0100

Jonathan,

In Frank's e-mail  3 possible solutions are described to  tackle the
Problem.
Does your answer mean that we should use 1 of them ? or are there
other solutions that we have missed ?

Best Regards,

Patrick

> > Sent: Tuesday, December 17, 2002 4:37 AM
> > To: Elwell, John
> > > I think solving the transfer by join scenario is very important
> > as it is
> > > will be kept in the signalling path, will bridge the A and C
> > locally, and
> > > them tell A and C that they are now talking to a different user (done
> > > after the transfer). The important is that from a signalling point of
> > > In SIP, it seems to me that this is very similar to third party
> > call control
> > >
> > > scenario (
> <http://www.ietf.org/internet-drafts/draft-ietf-sipping-3pcc-02.txt> ).
> > >
> > > B would re-INVITE A with C's SDP, and re-INVITE C with A's SDP.
> > (There might
> > >
> > > [pm] In some cases the transferror does not the SDP description of the
> > > so re-INVITE is not sufficient. I think we need another INVITE
> > towards A & C
> > > and then use QSIG  "Facilitiy PathReplacePropose " to update
> > media path.
> > >
> > > [JRE] I think re-INVITE is indeed sufficient (along with the other two
> > > solutions suggested in the message from Frank that started this
> > thread). The
> > > gateway between the transferor and the transferee would send
> > re-INVITE to
> > > would send re-INVITE to the transfer target. The interesting
> > thing is that
> > > SDP would not normally change. The only think that would change
> > would be the
> > authenticated the requestor, to inform another element (over a trusted
> > Here, you are trying to have one element tell another element that its
> > media is actually coming from a different source. We have no way to do
> > that in SIP.
> >
> > >
<http://www.ietf.org/internet-drafts/draft-ietf-sip-replaces-02.txt> )