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

From: "Tom-PT Taylor" <[email-masked]>
Date: Fri, 25 Aug 2000 00:53:21 -0400

I've been plugging REFERS into call flows for each of the services you list
in your latest comment, and it works on the assumption that matching call-id
means that party C shouldn't indicate it is busy or invoke call waiting.
These flows actually take advantage of the fact that the old call leg
remains in place until explicitly taken down.

> -----Original Message-----
> From: Rohan Mahy [mailto:[email-masked]]
> Sent: Thursday, August 24, 2000 1:46 PM
...
> 
> >Rohan Mahy wrote:
> > >
> > > 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,
> >
> >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.
> 
> 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   ??
> >
> >Known call-id.
> 
> 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
> 
> 
> 
> > > 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.
> >
> >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.
> >--
> >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
> 
> 
> 
> _______________________________________________
> SIP mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/sip
> 

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

---

From: Rohan Mahy <[email-masked]>
Date: Fri, 25 Aug 2000 10:37:45 -0700

At 09:53 PM 8/24/00 , Tom-PT Taylor wrote:

>I've been plugging REFERS into call flows for each of the services you 
>list in your latest comment, and it works on the assumption that matching 
>call-id means that party C shouldn't indicate it is busy or invoke call 
>waiting.  These flows actually take advantage of the fact that the old 
>call leg remains in place until explicitly taken down.

So in the interim, you assume the calls are joined/mixed?

thanks,
-rohan

> > From: Rohan Mahy [<mailto:[email-masked]>mailto:[email-masked]]
> > ><http://www.cs.columbia.edu/~jdrosen>http://www.cs.columbia.edu/~jdrose 
> n         PHONE: (732) 741-7244
> > ><http://www.dynamicsoft.com>http://www.dynamicsoft.com
> >
> >
> >
> <http://lists.bell-labs.com/mailman/listinfo/sip>http://lists.bell-labs.co 
> m/mailman/listinfo/sip
> >

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Mon, 28 Aug 2000 22:55:05 -0400

I put the media on hold where necessary, so that flows are happening on just
one branch.

> Sent: Friday, August 25, 2000 1:38 PM
> To: Taylor, Tom-PT [NORSE:B901:EXCH]
> Cc: Jonathan Rosenberg; Brett Tate; SIPbell-labs;
> [email-masked]
> Subject: RE: [SIP] draft-ietf-sip-cc-transfer-00 comments and 
> questions
> 
>