Hi,
Assume there is already a call between User A and User B.
Now, if User A wants to invite User C, then it sends a fresh INVITE to
User C.
At this point, there are two calls established, A<->B, A<->C.
Now, A receives media from B and C and mixes them. A sends media
containing A,C to B
and media containing A, B to C.
This should make a 3-way conference with A as a mixer...There is no need of
a
call between B and C.
You may refer to draft-ietf-sipping-conferencing-models-01.txt....
Rgds
Seshu
--------------------------------------------
http://www.hssworld.com
feng zhang <[EMAIL PROTECTED]> on 08/15/2002 06:01:10 PM
Please respond to [EMAIL PROTECTED]
To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
cc: (bcc: Seshashayi T/HSSBLR)
Subject: RE: [Sip-implementors] 3-way Conference
Hi Michael,
Yes , every part has a media mixer.
for example, User A has a mixer, and A has setup a RTP channel with B
and another RTP channel with C, the mixer mix B & C's voice stream, and
then send it to A. Because there is a RTP channel between A and B, thus,
A's voice stream can be sent on this channel, the same to C, there is a
RTP channel between A and C , then, A's voice stream can be sent on that
channel, this separated process can be done simultaneously.
But I want to know: when User C receives two INVITEs(from A and B), how
User C knows the two INVITEs are for "3-way conference" , and how User B
sends INVITE to User C in the scenario below:
User A User B User C
| INVITE | |
|---------------->| |
| INVITE |
|------------------------------------>|
| | How B sends INVITE to C ?
Best Regard.
>Hi Feng Zhang.
>
>This is not the way ''3-way conference'' is normally implemented.
>
>In a ''3-way conference'' User B as example should be able to take part
>of the voice stream content between User A & User C.
>
>You would need a voice media mixer for this purpose ex. at User B side.
>
>The voice streams from User A to User C would then pass the media mixer
>at User B and not pass directly from User A to User C.
>
>Hope this answers your question or I have misunderstood what you want.
>
>Regards, Michael.
>
>-----Original Message-----
>From: feng zhang [mailto:[EMAIL PROTECTED]]
>Sent: den 15 augusti 2002 12:17
>To: [EMAIL PROTECTED]
>Subject: [Sip-implementors] 3-way Conference
>
>
>Hi All,
>
> I want to fulfill "3-way Conference" in this way :
>
> User A------------User B
> \ /
> \ /
> \ /
> \ / <------------------- RTP channels
> \ /
> \ /
> \ /
> User C
>
> Notes: 1) User A, User B, User C want to "3-way Conference"
> 2) Every user should setup two RTP channels with the other two
users,
> for examples, User A should setup a RTP channel with User B ,
and should
> setup a RTP channel with User C, thus , User A's Voice can be
sent to B & C,
> on the other hand, User B & C 's voice can be received
separately on two
> RTP channels, and User A can hear B & C's voice
simultaneously. In this way,
> I can fulfill "3-way Conference".
>
> But I want to know :
> 1) look at the scenario below:
>
> User A User B User C
> | INVITE | |
> |------------------>| |
> | | |
> | INVITE |
> |--------------------------------------->|
> | |
> How User B INVITE User C , AND let User C know this INVITE is for
the same
> session(3-way Conference) ?
>
> 2) in RFC3261 section "13.3.1 Processing of the INVITE"
>
> it says:
>
> "The INVITE may contain a session description, in which case the
UAS
> is being presented with an offer for that session. It is possible
> that the user is already a participant in that session, even though
> the INVITE is outside of a dialog. This can happen when a user is
> invited to the same multicast conference by multiple other
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> participants. If desired, the UAS MAY use identifiers within the
> session description to detect this duplication. For example, SDP
> contains a session id and version number in the origin (o) field. "
>
> I want to know whether "the same multicast conference by multiple
other
> participants" it mentions is the way to fulfill a service like "3-way
conference"?
>
> Thank you!
>
>Best Regard!
>
>
>
>
>_______________________________________________
>Sip-implementors mailing list
>[EMAIL PROTECTED]
>http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>
>.
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors