Subject: RE: [SIP] Conferencing

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 11 Oct 2000 14:24:38 -0400

In the dial-up conference model, the request URI is really the only usable
identifier that can describe the conference.

Think of it as exactly the way conferences work in the PSTN; you dial a
number plus a passcode (whcih is just an extension of the number, needed
because of the limited number of phone numbers available), and that number
represents the conference. Same here. A conferencing server should mix
together everyone who calls the same request URI; that would be the nature
of the resource defined by the collection of URIs on the conference server.
As an example, a conference server might define:

[email-masked]

where * is anything, to represent ad-hoc conferences which don't even need
to be pre-established. 

Junyoung writes:
> I know request-URI may be changed by proxies.
> So, How changable field can be used as ID?
> And, I think, SIP is not necessary to support multi-unicast 
> call itself.
> It overburden SIP. I like SIP for its simplicity.
> I use origin of SDP for conference ID.

Request URIs are not changed arbitrarily. They are changed in order to
properly route the request to the identifed resource. Such translations may
be needed even for conferences. Here's an example. Lets say you have a
conference service, conferences.com. It hosts two servers, one for ad-hoc
conferences, and another for pre-established conferences. WHen a call
arrives at the conferences.com proxy, it examines the user part of the
request URI. If its foo-adhoc, it gets translated to
[email-masked], and proxied there. If its just some
pre-arranged conference, [email-masked], that might get
proxied to [email-masked]. Each of those servers is
then configured to accept calls only for [email-masked]
in the first case, and [email-masked] in the second.

As another example, lets say I'm supposed to be in a conference call with
Joe at 10am. I've forgotten the conference ID (i.e., the request URI), so I
call joe. Joe has a CPL configured that if I call him during the conference,
it proxies the request to the conference ID. Thus, the call will be
forwarded there and I get dropped right into the conference with Joe. This
service would not be possible if the request URI were not used as the
conference ID.

Whenever you want to access a service associated with some server on the
network, and that server acts as a user agent (examples include IVR servers,
media servers, conferencing servers, translation servers, etc.), using the
request URI as the service identifier is an absolute MUST. This is exactly
what the definition of the request URI is, and it has the really important
advantage of turning a variety of service access problems into *routing*
problems. Thats why I can write a CPL to drop someone into a conference when
they call at a certain time; using the request URI as the conference
identifier makes it into a routing problem, which is within the domain of
CPL.

I have an I-D pending that puts this all together and explains how this
model of accessing certain services through defined patterns on the request
URI has huge advantages. Should be out in a few weeks.

-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: (973) 952-5000
http://www.dynamicsoft.com

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, October 11, 2000 12:46 AM
> To: [email-masked]
> Subject: [SIP] Conferencing
> 
> 
> Hello.
> I have a question about SIP-based conferencing. Let us assume 
> the existence
> of a SIP UA that performs conferencing. SIP UAs that want to join a
> conference send SIP INVITEs to the conference server to 
> conference them in,
> i.e. for an n-party conference, the CS will receive n 
> INVITEs. I believe
> there has to be  a need for corrolation and disambiguation of 
> the different
> call-legs at the conference server. For a dial-in conference 
> such as this, I
> think the easiest (and the most intuitive) way to corrolate 
> all these n
> INVITEs (that have different Call-IDs) is via the dialed number/
> conference-ID  (i.e. the "To" field). 
> 
> However, if all these different call-legs were initiated by a 
> third-party
> entity (called the controller) that sent these INVITEs on 
> behalf of the
> actual participants, how should the corrolation and disambiguation of
> call-legs be performed at the conference server? 
> 
> I think there are two options:
> a) Same as before. Have each one of the INVITEs have 
> different Call-IDs and
> have the conferencing SIP UA corrolate them based on the "To" field. 
> This requires the controller to have a mechanism to corrolate 
> all these
> call-legs at its end.
> 
> b) Mandate that all the call-legs share the same Call-ID. The 
> 'From' field
> in each INVITE  sent to the CS (from the controller) must 
> then be tagged.
> The CS could use the Call-ID to corrolate all these call-legs 
> and the tag in
> the From to help distinguish one from the other.
> 
> Is there a reason to prefer one over the other? Is there a 
> third option that
> I have missed? Is there a preferred/ accepted mechanism to 
> accomplish this
> and is this documented somewhere?
> 
> Thanks,
> Aparna
> 
> _______________________________________________
> 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: Doug Harbert <[email-masked]>
Date: Wed, 11 Oct 2000 17:22:53 -0600

> > and is this documented somewhere?

Jonathan:
   How would a SIP Conference server register with an inbound proxy to accept
such adhoc calls "[email-masked]"? As I understand the registration
process, the conference server would issue a Register with From and To headers
representing some name at the proxy address, and a Contact which specifies some
name at the conference servers address. A call comes into the inbound proxy,
and is sent to the URI found in the Contact. The name in this URI is FIXED and
so it cannot be used to reference a previously unknown conference.

   What I would like to be able to do is to receive Invites with a URI like:
SIP:[email-masked]. All calls arriving with this URI would go into
the adhoc conference "JohnSmith". I don't necessarily want to know about
John Smith ahead of time.

   One idea I had was to register with the proxy as [email-masked], and
then expect to see an Invite with a URI like:
SIP:adhoc:[email-masked], using the password field of the URI to
specify the actual conference name. Is this an appropriate use of this field?
Are there any other ways that I can get this information?

Thanks

Doug Harbert.

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 11 Oct 2000 19:27:12 -0400

If you're willing to have something like [email-masked],
the company.com server just forwards everything for
@conferences.example.com to the conference server. A normal proxy server
should do this automatically, even if you need to do some
internal/external DNS acrobatics. (Normally, calls for
[email-masked] would never see the company.com proxy
server.) 

Note that not every call *has* to go through a proxy server.

This is only a problem if the conference server and regular users share
the same name space, which is probably not a particularly good idea if
you want to avoid somebody registering the conferencing
[email-masked] and all your calls going to the conference server.
You could restrict names in various ways (e.g., no user can have names
with adhoc-*), but it seems preferable to do hierachical naming that
expresses this intent much cleaner.

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