Subject: RE: [SIP] Conferencing

From: [email-masked]
Date: Wed, 11 Oct 2000 11:19:38 -0600

Doug,
Pl. see my comments below.
-Aparna

-----Original Message-----
From: Doug Harbert [ mailto:[email-masked]
<mailto:[email-masked]> ]
Sent: Wednesday, October 11, 2000 10:54 AM
To: Vemuri, Aparna
Cc: [email-masked]
Subject: Re: [SIP] Conferencing

[email-masked] wrote:

> 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
<http://lists.bell-labs.com/mailman/listinfo/sip> 

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?

Aparna says:
1.    A call-leg is defined by a combination of the Call-ID, the To and the
From (including any tags). The process for determining whether a request is
new or not   involves a three step process described in section 11.5 of the
spec (and I believe it involves a comparison of the To and the From
(including the tags) and the Call-ID.) My understanding is that a mismatch
in the To and the From (tags included) should be interpreted as a new
call-leg. 
 
2. The tag in the From MUST be present when there are two instances of a
user sharing a SIP address making call invitations with the same Call-ID.
Our case is similar to this in that the controller issues INVITEs on behalf
of all the participants.
 
3. The proxy copies the To, From, Call-ID and Contact tags from the original
request. The proxy does not modify the tags in any way. It adds a branch
parameter to the Via field.
Aparna

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

---

From: Doug Harbert <[email-masked]>
Date: Wed, 11 Oct 2000 17:43:40 -0600

> parameter to the Via field.

Aparna:
    I think I see what you are saying. I was confused by this statement in the
draft-ietf-sip-rfc2543bis-01 document
in section 6.24 From. "The distinction between call and call leg matters in
calls with multiple responses to a forked request".

   As long as the tags are generated by the UA originating the calls, and not
modified by intermediat proxies, then a unique combination of Call-Id, To and
From headers will uniquely identify a call leg.

Thanks

Doug Harbert