Subject: RE: [SIP] Re-invites in a multi-party call

From: Deepika Giri <[email-masked]>
Date: Tue, 12 Jun 2001 10:57:16 +0530

That was not my question, not to put a single user on hold, I need to put
all "conference participants on hold".

Anyway, I think multi-cast should work as suggested by Iliff TIna.

Deepika

-----Original Message-----
From: Ranjit Avasarala [mailto:[email-masked]]
Sent: Tuesday, June 12, 2001 3:00 AM
To: Deepika Giri
Cc: [email-masked]
Subject: Re: [SIP] Re-invites in a multi-party call

Hi  Deepika,

      to put usr B on HOLD usr A sends a Re INVITE (HOLD) message with a
session description containing a null (0.0.0.0) address.
when used with SDP the 'c' address field of media types is set to 0.

Regards
Ranjit
Mascon Communication Technologies
http://www.masconit.com

----- Original Message -----
From: Deepika Giri <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, June 11, 2001 5:03 AM
Subject: [SIP] Re-invites in a multi-party call

Hi,

I am trying to implement a multi-party conference control application in SIP
using 3pcc.
My problem is this:

Usr A is currently in a conference call with User B and C, now it wishes to
put the current conference call on hold, by sending a re-INVITE, but what
will be the sip request url for this re-invite, does it send hold messages
to B and C individually?  If it has to do this, it has to maintain the users
currently in the conference call, but does a standard SIP-phone maintain
this information?   The number of users in a conference is not always known
to each client in a conference, there has to be a mechanism by which the
users get a fresh list of participants every time one leaves the call or
joins in. Can someone explains how such a feature would be implemented in a
SIP phone?

I need to know how a sip phone behaves in this scenario, b'cos my 3rd party
application has to handle this "hold " invocation by any of the users in a
call.

Can you please clarify?

Thanks
Deepika

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to
[email-masked] with "subscribe" in the body.

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.

---

From: Wai Wu <[email-masked]>
Date: Tue, 12 Jun 2001 09:58:33 -0400

I have been working with several so call standard SIP phones. All of them
assume that a conference bridge exists in the lan. When an UAC puts the
conference on hold, it sends a re INVITE to the conference bridge.

-----Original Message-----
From: Ranjit Avasarala [mailto:[email-masked]]
Sent: Monday, June 11, 2001 3:00 PM
To: Deepika Giri
Cc: [email-masked]
Subject: Re: [SIP] Re-invites in a multi-party call

Hi  Deepika,

Regards
Ranjit

----- Original Message -----
From: Deepika Giri <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, June 11, 2001 5:03 AM
Subject: [SIP] Re-invites in a multi-party call

Hi,

Can you please clarify?

Thanks
Deepika

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 12 Jun 2001 16:40:05 -0400

> From: Deepika Giri [mailto:[email-masked]]
> Sent: Monday, June 11, 2001 6:03 AM
> To: [email-masked]
> to B and C individually? 

This question cannot be answered without knowing what conferencing model is
being used. Conferencing models for SIP are discussed at length in:

http://search.ietf.org/internet-drafts/draft-rosenberg-sip-conferencing-mode
ls-00.txt

In the case of a dial-in conference server, you would hold the other
participants by sending a re-INVITE to the server itself, with a 0.0.0.0
SDP.

In the case of end system mixing, described in section 2 of the above
document, you would send a hold individually to all the other participants
being mixed.

> Anyway, I think multi-cast should work as suggested by Iliff TIna.

Multicast? The phrases "multicast" and "should work" are contradictory and
usually don't belong in the same sentence. In any case, multicast won't help
you in any way for anything but multicast conferences. In the case of a
multicast conference (where the media is distributed via multicast), there
is no possibility for a hold. You would simply stop listening for media.

-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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 21 Jun 2001 03:37:11 -0400

> Sent: Wednesday, June 13, 2001 8:27 AM
> To: Jonathan Rosenberg
> Subject: RE: [SIP] Re-invites in a multi-party call
> 
> 
> My conferencing model centralized in nature, where the conference
> server/bridge does the mixing.  The usr A is not aware that 
> he's connected
> to the bridge, only the Conference Control application does 
> the bridging of
> all the users to the CB, this is using 3pcc.
> 
> As far as A is concerned, he knows that he is in conference 
> with B and C,
> so, he can put them on hold by sending them messages 
> individually. right? or
> can he send a single hold message that will put both of the 
> users on hold?
> how does a standard SIP phone do this?

Adam responded:
> Not with the architecture you just described. As far as user A's
> equipment is concerned, he is communicating with exactly one
> party: the conference bridge. He will hold the conference bridge.

That is correct. To add to that, it doesn't even make sense. If A sends a
hold to C, so that C stops sending media to the mixer, then B will not hear
A. That doesn't make sense.

Perhaps what you want is that A gets to decide that it doesn't want to hear
C anymore, but that B should still continue to hear C. To do this, you need
a conference control protocol in order to set the mixing matrix used by the
bridge. There is not yet a standardized protocol, but I would note that
using a web interface to control this can get you a very long way.

> 
> what if there is a situation where there is one more user D in the
> conference(brought in by C, whose presence A is not aware of? 
>  He cannot
> send a hold message to D, he doesn't even know he exists, 
> unless the list of
> participants in the conference is constantly given to each of 
> the users.

No, there is a direct SIP signaling relationship between each user an the
bridge. There are no other SIP relationships.

-Jonathan R.

---

_______________________________________________
Sip mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/sip

---

From: Michael Hammer <[email-masked]>
Date: Thu, 21 Jun 2001 09:50:03 -0400

In the centralized model, is the concept that one controls the other 
parties streams or that one controls the flows to/from oneself?  That is, 
when I do a hold, I am not putting other parties on hold from the bridge, I 
am putting myself on hold from the bridge.  I control myself, not 
others.  If other parties wish to continue communicating, I have no control 
over that.  I believe this latter makes more sense in a distributed control 
environment.

Mike

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 26 Jun 2001 02:52:15 -0400

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Thursday, June 21, 2001 7:01 PM
> To: Jonathan Rosenberg
> Cc: 'Michael Hammer'; 'Deepika Giri'; [email-masked]'
> Jonathan Rosenberg wrote:
> [snip] 
> > Right. If you send a re-INVITE with 0.0.0.0 in the SDP, you 
> will stop
> > receiving media. This has nothing to do with anyone else.
> 
> This is really only true with cooperative partners isn't it?

Sure, but its not that interesting to have a phone call with a UA that
doesn't actually want to cooperate with you. THere are lots of other things
it can choose to ignore (such as the entire INVITE in the first place).

-Jonathan R.

---

_______________________________________________
Sip mailing list  http://www.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