Subject: RE: [Sip] SDP in REFER triggered INVITE

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 7 Sep 2001 02:04:57 -0400

> -----Original Message-----
> From: Aaron Lo [mailto:[email-masked]]
> Sent: Tuesday, September 04, 2001 8:39 PM
> To: [email-masked]; [email-masked]
> Subject: RE: [Sip] SDP in REFER triggered INVITE
> 
> 
> Consider this scenario:
> 
> Say A, and B are in an audio call. If A wants to invite C into their
> session and establish a conference call, A could use REFER to 
> set up the
> call, correct?

Well, REFER is part of it. You would refer everyone to a conference server.
So, specifically, A would invite the conference server itself, and then
refer B and refer C to the same URI on the conference server.

> If C can establish whatever session with A and 
> B, C could
> possibly choose to establish an IM session with the other two 
> parties. 

We have not specified fully distributed conferencing models, which is waht
you seem to be talking about. In the centralized variants (which includes
everything but large scale multicast in the conferencing models draft), the
conference server (which is the end system in the end system mixing case)
would be able to coordinate what media types are used as part of its
policies. One could very well have a conference server that is audio only.
If C is referred to it, and does not provide any audio streams, the server
rejects it. The NOTIFY triggered by the REFER would then tell A that the
conference cannot be established, and indeed, the included message would
tell A why. 

> 
> Also consider this:
> 
> Say A and B are in an audio call. A is a sip phone that is 
> incapable of
> doing IM. Say B wants to transfer the call to C, C may establish an IM
> session with A (which may fail). A and C would not be able to have a
> meaningful session. 

If the referred INVITE from C to A fails becaue A has no support for IM,
then no signaling in the world will help you. The REFER mecahnisms will
allow B to know why the transfer has failed, and thats the best you can do.
If the referred INVITE from C to A fails because C indicated an IM stream
only (but it supports audio), it can still work. The rejection from A would
include an SDP listing the media types it supports. Thus, C can learn that
only audio can be established, so it can retry with audio only.

> If A has the option to specify the type of session it wants C to
> establish with the refer-to party, C could establish a meaningful
> session. If C does not want to set up a session of the specified type,
> it could still decline the REFER. 
> 
> An option to specify the media type in refer seems very attractive. 

I really don't see the value in that. The SIP mechanisms will make sure that
communications are established with whatever modalities are common. Why is
that not what you want?

-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

_______________________________________________
Sip mailing list  http://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: "Tom-PT Taylor" <[email-masked]>
Date: Fri, 7 Sep 2001 02:20:19 -0400

Why refer B and C to the conference server rather than the reverse?  I'm
looking at an ad hoc conferencing flow right now where A and B are already
talking and they're switching to a three-way conference.  By having the
conference server call C you can get it to play ringing tone out to A and B
until the C-call-leg gets set up.

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Friday, September 07, 2001 2:05 AM
To: 'Aaron Lo'; [email-masked]; [email-masked]
Subject: RE: [Sip] SDP in REFER triggered INVITE

...

[snip]

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 7 Sep 2001 11:27:52 -0400

-----Original Message-----
From: Tom-PT Taylor [mailto:[email-masked]]
Sent: Friday, September 07, 2001 2:20 AM
To: 'Jonathan Rosenberg'
Cc: [email-masked]'
Subject: RE: [Sip] SDP in REFER triggered INVITE

>Why refer B and C to the conference server rather than the reverse?  I'm
looking at an ad 
>hoc conferencing flow right now where A and B are already talking and
they're switching to 
>a three-way conference.  By having the conference server call C you can get
it to play 
>ringing tone out to A and B until the C-call-leg gets set up.

This is fine also. My arguments apply equally well to that case.

-Jonathan R.

---

---

From: "Aaron Lo" <[email-masked]>
Date: Fri, 7 Sep 2001 12:22:28 -0700

Please see comment below. Thanks.

> everything but large scale multicast in the conferencing models
draft),
> the
> I really don't see the value in that. The SIP mechanisms will make
sure
> that

[Aaron] This mechanism makes sense in 2-party case. However, in the
multi-party case, we may want to restrict to a uniform mode of
communication as per above discussion. What we have now is only the
ability to tell that the REFERral has failed and why it has failed. I
think we can do better by having REFER specify the media type so the
referred can decline the REFER if it sees it cannot connect with the
specified media type.