Subject: [SIP] draft-ietf-sip-cc-transfer-00 comments and questions

From: "Brett Tate" <[email-masked]>
Date: Tue, 22 Aug 2000 01:51:32 -0400

Robert,

Thank you for developing
draft-ietf-sip-cc-transfer-00.

Here are some comments/questions.

Brett Tate
BroadSoft

---------------------------

General comments:

1- please specify how receiving BYE effects an 
 outstanding REFER.  I assume that it doesn't
 cancel the REFER.  Should a REFER final
 response of 200 be sent to immediately close the 
 transaction?  Should a new final response
 be defined to indicate the transaction is still
 being processed, but I will be unable to provide
 an accurate response since the call-leg is
 disappearing.

2- please specify if two REFERs can be outstanding
 on a call-leg at the same time.

3- please specify if the call state has to reach
 a specific state before the REFER can be triggered.
 I was glad to hear that REFER may not have to be
 part of an existing session, but can it also be 
 valid during call-setup to hopefully address 
 location, SDP changes, or transfer during ringing?

4- please address any media mixing/switching 
 requirements as a result of the transferor 
 session still being present.  Can a header 
 or parameter be used to better clarify the 
 REFER request from the transferor point of view?

5- please address how a RE-INVITE from the transferor
 effects a successful REFER transaction.

6- please specify that a CANCEL of REFER should 
 trigger a 487 for the REFER.

7- please address how a second REFER from transferor
 effects a successful first REFER from transferor.

8- What provisional response should be sent by the
 transferee to indicate the REFER was received
 and is being processed?  The 100 cannot be used
 since proxies can also send it.   

Section 5.3:

The Content-Length header statement about being
present with value of 0 conflicts with section
5.4 concerning a body being present.  Removing the
"and have a value of zero" should fix the conflict.

Section 6.2.1 flow:

Can a new method/header/parameter be defined
to indicate to the Transfer target that an INVITE 
from new call-leg is about to occur which will 
contain a particular Referred-By.  And when 
received, please handle it based upon the 
Request-Disposition.  This would
be useful so the transferor can switch out of a
call without the transfer target having to hang up
the phone or have call waiting.  This comment is
also useful for 6.2.2, 6.3, and 6.4.

New method: PENDING-INVITE
New header: Request-Disposition = 
  "Request-Disposition" ":" "=" 
 "switch-bye" | "mix" | "reject" | "hold-me" | token

"switch-bye" means quit listening to me and
send a BYE for our session upon receiving the
INVITE.

"mix" means to please mix the media.

"reject" means the REFER was cancelled, and
thus the INVITE should be rejected.

"hold-me" means quit streaming to me until
I send a RE-INVITE.

The PENDING-INVITE would contain the usual 
headers plus Request-Disposition, Referred-By,
Expires, and Date.

The transfer target would compare the Referred-By's
received in the INVITE and PENDING-INVITE.  If equal,
the Request-Disposition is honored.  Otherwise,
the INVITE is received and process as if the 
PENDING-INVITE was not received.
 
The Request-Disposition header could also be used
in a REFER to indicate how the sending wishes the
receiving to handle the REFER concerning the session
and media.  Of course the "reject" does not
make sense in a REFER.  The Request-Disposition 
would addresses general comment number 4.

[The above is just an idea to see if something like
this is needed or even belongs in the transfer draft.]

Section 5.2.2 Variation 2...: 

Should be labeled "6.2.2".

The actors of Transferee and Transfer Target seem reversed.

Please see comments on 6.2.1 as a means to avoid the 
transferee from needing call waiting or a second line 
for the switch to occur.  [ I assume that call-ID would not
be trusted for a quick switch or mix mechanism since 
it does not get encrypted. ]

---

From: "Robert Sparks" <[email-masked]>
Date: Tue, 22 Aug 2000 09:07:06 -0500

Thanks for this effort!

Responses/comments inline -

> an accurate response since the call-leg is

Short answer - no effect.

I think you are asking about the case where you
receive a REFER and then receive a BYE while you
are processing it. While allowing REFER to be sent
outside of a "session" makes this easier to think
about, the sending party could send them as part
of the same session. This isn't a problem for your
end - you finish the REFER transaction with a 
final response when you can. The other side may
be beyond doing anything useful with a non-200
response however.

That originating side should not be overlapping
the REFER and the BYE however. It should either
CANCEL the REFER before the BYE or wait to send
the BYE until the REFER final response comes in
(note that this doesn't imply it has to tie up
its user-interface during that time).

> on a call-leg at the same time.

This would not be different from having REFERs
arrive concurrently for two different call legs.

> location, SDP changes, or transfer during ringing?

Can you elaborate on what you are wanting to accomplish
here? You are wanting to change the address at which
you receive media after you send and INVITE but before
you receive a final response to it? 

> REFER request from the transferor point of view?

REFER has no effect at all on any existing session -
particularly those session's media.
> effects a successful REFER transaction.

Again, REFER (even as it is currently written) has no
afffect on the existing session - an overlapped reINVITE
would not interact with it. (I assume you are describing
something like putting the transferee on hold after
having sent the REFER?)

> trigger a 487 for the REFER.

OK. Was there confusion on this? As I understand it,
CANCEL of _any_ cancellable method results in a
487 being returned for that method.

> effects a successful first REFER from transferor.

Those are independent events (even if they occur on
the same call leg).

> since proxies can also send it.   

Do we really need something for this? 100 lets us know
that it either got there or something in between has
taken responsibility for getting it there. As far as
the sender is concerned, it should now assume that
the request is being processed and a final response
will be forthcoming. I think you are asking for 
something back from the transferee that says
"I got this and I've started to do what it says",
which you can infer from the lack of a non-2xx final
response.

>"and have a value of zero" should fix the conflict.

I've removed it - it was a holdover from the original
bodiless TRANSFER draft.

>also useful for 6.2.2, 6.3, and 6.4.

I would do this instead with header values in
the Refer-To: URI.

 >it does not get encrypted. ]

The signature in the Referred-By header should be used to 
give the referenced target the comfort you are looking
for here. It is intended to give the referenced party
proof of the identity of the original REFERer and 
integrity of the reference (i.e. the signature comes
from the party issuing the REFER) - so you can trust
any information you received in the headers in the
Refer-To: URI to do things like quick switch you
mention.

From a quick scan of the document this morning, its
not clear how that signature gets into the Refered-By
header however. I will correct that.
 
>Should be labeled "6.2.2".

Fixed

>The actors of Transferee and Transfer Target seem reversed.

They aren't, but I can see how the shell game with the names
is confusing. From a black box perspective, the Transferor
is going to do things to cause the Transferee to be connected
to the protected Transfer-Target. This flow shows how to do
this by actually transferring the transfer-target to the 
transferee.

RjS

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 22 Aug 2000 11:49:20 -0400

In general, I think we want to stick with the model that REFER, and the
session during which REFER was sent, are completely unrelated.
Otherwise, we will have many complex interactions like the ones you are
asking about.

-Jonathan R.

> Brett Tate wrote:

-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 22 Aug 2000 11:42:16 -0400

Robert Sparks wrote:

> this by actually transferring the transfer-target to the

I generally find the names of transferor and transferee, etc.,
confusing, particularly since this is no longer just for transfers. What
we're really doing is asking some SIP UA to send a request. I think it
would be helpful if the document used a more "application neutral"
terminology. 

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: "Brett Tate" <[email-masked]>
Date: Wed, 23 Aug 2000 02:44:10 -0400

Hey Jonathan,

Thanks for the response.

Can any member along the path introduce REFER
messages on the path or does it exclude proxies
for CSeq reasons?  Since the REFER is just 
borrowing the route and is unrelated to the
session, do all the rest of the headers
need to match up with the normal call-leg headers
specific to the path?

It seems the document has evolved to show 
how A can request B to INVITE C, instead of how 
to transfer a call.  If a REFER is unrelated to 
the path's session, I find it interesting that the 
Call Transfer draft doesn't explain how to 
perform a transfer.  :)

Please give example of headers as to avoid everyone
from producing a proprietary means to request a 
"transfer", "multi-party", or 
"establish additional unrelated call" when
sending the REFER.

Please give example of headers for how the 
Transferee knows to switch, second line, or 
multi-party the INVITE from the Transfer Target 
within 6.2.2 without presenting it the user to
decide.

Thanks,  
Brett

---

From: "Brett Tate" <[email-masked]>
Date: Wed, 23 Aug 2000 02:44:13 -0400

Hey Robert,

Thanks for the response.  You and Jonathan have
cleared up much of my (and hopefully the news
groups') understanding of the draft.

Please understand that much of my comments
are to help avoid the same questions from being
asked repeatedly within this list.  Thus, maybe
the answers or clarifications can be addressed
within the document text when appropriate.

More questions and comments inline.

Thanks,
Brett Tate

----- Original Message -----
From: Robert Sparks <[email-masked]>
To: Brett Tate <[email-masked]>; SIPbell-labs <[email-masked]>
Sent: Tuesday, August 22, 2000 10:07 AM
Subject: [SIP] RE: draft-ietf-sip-cc-transfer-00 comments and questions

> be beyond doing anything useful with a non-200

Thanks.  Please document answer within the draft.

> arrive concurrently for two different call legs.

Thanks.  Please document answer within the draft.

> you receive a final response to it?

I am mainly just seeking clarity within the draft
concerning restrictions and expected results when the
REFER is used within a verity of session states and
message flow situations.

> particularly those session's media.

Interesting.  How else does the "Transferor" indicate
to the "Transferee" that a transfer should happen?

Please respond and document answer within the draft.

> something like putting the transferee on hold after

Thanks.  I am actually just trying to get clarity in the
draft concerning the new REFER method's effect
on basic call flows and expected results as described
in rfc2543.

> 487 being returned for that method.

Just trying to ensure clarity within the draft as a
reminder for those who implement it.

> Those are independent events (even if they occur on

Thanks.  Please document answer within the draft.

> which you can infer from the lack of a non-2xx final

If a transferor would like to safely send BYE
and ensure that the REFER arrives before the BYE,
a non-100 provisional response would be wonderful
to accomplish this.  The 100 should not be used,
since transaction stateful proxies use it.

It would also be wonderful in a situation where it
takes longer than 10xT2 for the Referred-To party
to answer.  Thus, the Referrer could know to
maybe try more than 11 times before giving up.

The 183 maybe could be used, but a new
provisional response might be better.

> I would do this instead with header values in

For security reasons, I agree that the "Refer-To: URI"
would be a wonderful location concerning 6.2.2.

Please respond with the header/parameter along with the
corresponding defined values and extension format.

Please provide examples within the draft and in your
response.

What do you think about using "referrer-url" or a
parameter within the Referred-By header to
address item 4 about how to know what REFER
means in relation to other established sessions
between the Referrer and Referred (or any other
sessions for which the Referred is involved)?

Would it be useful for a REFER response to
indicate if Referred honored the
"switch" , "mixed" request, or did something
else with it?

> Refer-To: URI to do things like quick switch you

Thanks.  I assume call-ID is the catch-all means to know
for which session to apply the "quick-switch".  Is this
correct?

It would be so wonderful to define another means
in case the Referred-To currently has several sessions
in various states using the same call-ID.  Something
like a PENDING-INVITE containing the Referred-By
is one way. Maybe the INFO containing the
Referred-By might be another.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 23 Aug 2000 12:02:45 -0400

> need to match up with the normal call-leg headers

REFER is no different than any other request. Proxies don't originate
requests on their own.

> Call Transfer draft doesn't explain how to

REFER followed by BYE does transfer. I have no objection to example
sections in the draft which show this kind of application.

> "establish additional unrelated call" when

I don't know what you mean by "example of headers". The
specification defines the headers needed for the refer operation.
You can build transfer with these mechanisms plus BYE as defined 
already.

> within 6.2.2 without presenting it the user to

UI issues are out of scope. Why couldn't an implemenatation
present it to the user to decide? Seems like a good feature.

-Jonathan R.

---

From: Rohan Mahy <[email-masked]>
Date: Wed, 23 Aug 2000 17:42:32 -0700

Hi,

Let me try and rephrase Brett's question.  Let's assume the following scenario:

A sends REFER to B with a Refer-To: <C>
B sends an INVITE to C with Referred-By: <A>

When C receives an INVITE with a Referred-By header, how does C know 
whether to:
         a) accept this INVITE as a new call,
         b) accept this INVITE as a replacement for another call leg, or
         c) accept this INVITE as new party in an existing call   ??

The semantics aren't well-defined yet.  The draft just mentions that you 
can include a call-id in the refer-to or referred-by URL.  It doesn't say 
what that would mean or what you should do with it.

All of these behaviors are reasonable things.  c) is useful for full mesh 
conferences, b) is needed for attended transfer and other redirection 
features, and is useful for desktop call control (my dialer REFERs my phone 
to place an INVITE to a contact).

thanks,
-rohan

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 24 Aug 2000 00:01:49 -0400

>          a) accept this INVITE as a new call,

This is the case when the Call-ID is unknown.

>          b) accept this INVITE as a replacement for another call leg, or

I assume you are talking about the now-defunct Replaces: function? I
believe now
that this function is quite a complex one and something that merits much
more discussion
before deciding if its needed.

>          c) accept this INVITE as new party in an existing call   ??

Known call-id.

> what that would mean or what you should do with it.

Thats something that needs to be addressed in the bis draft. It needs to
say what it means to receive a call from a different party but with the
same call-ID as an existing call.

-Jonathan R.

---

From: Rohan Mahy <[email-masked]>
Date: Thu, 24 Aug 2000 10:46:14 -0700

>before deciding if its needed.

I'm sure folks will want to do things like:

         Attended transfer
         Consultative Conference
         transitioning from a 3-way call to an MCU controlled conference
         screening voicemail messages
         etc...

I could go on for pages.

All these features require a way to take an existing call leg, replace it 
with another, and keep the old resources (speaker/microphone, DS0, video 
window, whatever) associated with the new call leg.

> >          c) accept this INVITE as new party in an existing call   ??

I don't think this is sufficient.  First, I think the existing call-id is 
better suited for replacement of call legs as described above.

Second, from the definition of call, conference, session, and call-id in 
the bis draft, I have always interpreted this to mean that if A calls B, 
and B calls C, if you join these two calls together, they need to keep 
unique call ids.  Neither call was invited by a common source, and neither 
call necessarily has or will use the same session description.

from the bis draft:
>Call: A call consists of all participants in a conference invited by a 
>common source. A SIP call is identified by a globally unique call-id 
>(Section 6.12). Thus, if a user is, for example, invited to the same 
>multicast session by several people, each of these invitations will be a 
>unique call. A point-to-point Internet telephony conversation maps into a 
>single SIP call. In a multiparty conference unit (MCU) based call-in 
>conference, each participant uses a separate call to invite himself to the MCU.

>Conference: A multimedia session (see below), identified by a common 
>session description. A conference can have zero or more members and 
>includes the cases of a multicast conference, a full-mesh confer-ence and 
>a two-party "telephone call", as well as combinations of these. Any number 
>of calls can be used to create a conference.

We need a way to semantically link multiple calls with distinct call-ids.

thanks,
-rohan