Subject: [SIP] Conferencing

From: [email-masked]
Date: Tue, 10 Oct 2000 22:46:19 -0600

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

---

From: Doug Harbert <[email-masked]>
Date: Wed, 11 Oct 2000 10:53:44 -0600

> and is this documented somewhere?

Aparna:
    In either case, the conference controller must have some mechanism to
correlate all of these calls and place them into the appropriate conference.

    In my opinion, supplying the conference identification in the request URI
provides more flexibility for the SIP conference UA, and for the conference
participants. I don't know how much control the third party conference
controller assumes here, but participants may wish to access the conference via
other means, for example, using the web to monitor the conference and dial out
additional participants. It seems more intuitive to specify the name of the
conference rather than a Call-ID and tag.

   The question that I have regarding the model in which all calls in a
conference have the same Call-ID but are distinguished by tags on the FROM
header is this: How do I know whether an INVITE represents a new call, or is
simply an existing call which was forked by some proxy?

Doug Harbert