RE: AW: [Sip] Extension of conference procedures
"Even, Roni" <roni.even@polycom.co.il> Thu, 30 August 2007 06:07 UTC
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQdC8-0002Tb-2I; Thu, 30 Aug 2007 02:07:56 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IQdC5-0002R1-TI for sip-confirm+ok@megatron.ietf.org; Thu, 30 Aug 2007 02:07:53 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQdC5-0002Hi-Ds for sip@ietf.org; Thu, 30 Aug 2007 02:07:53 -0400
Received: from fw.polycom.co.il ([212.179.41.2] helo=isrexch01.israel.polycom.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQdC2-0002Xw-VW for sip@ietf.org; Thu, 30 Aug 2007 02:07:52 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: AW: [Sip] Extension of conference procedures
Date: Thu, 30 Aug 2007 09:09:07 +0300
Message-ID: <144ED8561CE90C41A3E5908EDECE315C04DE7CFE@IsrExch01.israel.polycom.com>
In-Reply-To: <317ceda50708290707o41400c0cnbde78f49c9ab18f6@mail.gmail.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: AW: [Sip] Extension of conference procedures
Thread-Index: AcfqRhEX/Me4/dQsRM+wdqt5zk7CTAAhfFiA
From: "Even, Roni" <roni.even@polycom.co.il>
To: Peili Xu <xupeili@gmail.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: dfc64cf6e4c6efdbf6b8f4c995df04df
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org
Hi, I think you misunderstood what I menat by "smart". If there is a softyswitch acting as a 3PCC, it controls the dialogs and can redirect the media to the media server suppling the conference function. There is no need for A to give information about the dialog Roni Even > -----Original Message----- > From: Peili Xu [mailto:xupeili@gmail.com] > Sent: Wednesday, August 29, 2007 5:08 PM > To: Even, Roni > Cc: Huelsemann, Martin; sip@ietf.org > Subject: Re: AW: [Sip] Extension of conference procedures > > Hi Martin, Denis, > > I agree with Roni that you may need to decide who is "smart". > > I guess you want to simulate the 3PTY services in PSTN, > A make call to B, > then A Hold B, > then A Make Call to C, > then A could do sth like hook flash to turn the call between A-B and > A-C to an 3pty conference. > later, A could still turn the conferece back to 2 independant call. > > You have some assumption that the AS who performs conference > is on the path between A-B and A-C. And A could inform the AS to turn > the call between A-B and A-C to a conference. > > If the assumption is correct, what you want is just to tell the AS > which dialogs should be turned to conference by sending an INVITE with > the related dialog information. > > If the above understanding is correct, I'd agree with the initial > proposal from Denis. > Just to convey the dialog information along with the URI-List. > > Peili > > > > 2007/8/29, Even, Roni <roni.even@polycom.co.il>: > > > > Hi, > > In this case, like in PSTN the switch does it. You have to decide who is > "smart" the network or the end device. > > A "simple" RFC 3261 only phone relies on a 3PCC or softswitch to manage > telephony services (not only conferencing) > > > > Roni Even > > > > > -----Original Message----- > > > From: Huelsemann, Martin [mailto:Martin.Huelsemann@t-com.net] > > > Sent: Wednesday, August 29, 2007 1:05 PM > > > To: Even, Roni > > > Cc: sip@ietf.org; jbemmel@zonnet.nl > > > Subject: AW: AW: [Sip] Extension of conference procedures > > > > > > Hi, > > > > > > also for the scenario where A refers B to dial into a conference, the > > > problem is when B has a terminal not supporting REFER (or just doesn't > > > want to accept the REFER for some reasons), A cannot use the > conference > > > service. > > > > > > Of course these simple terminals are not the desired use-case and > there > > > will be limitations. But if there is a possible fallback solution that > at > > > least increases the chance that A can use the service despite the fact > > > that B does not fulfill all the requirements for the service, I think > we > > > should try to figure it out. > > > > > > Regards, Martin > > > > > > > > > > > > > > > > > > > -----Ursprüngliche Nachricht----- > > > > Von: Even, Roni [mailto:roni.even@polycom.co.il] > > > > Gesendet: Montag, 27. August 2007 12:16 > > > > An: Hülsemann, Martin; jbemmel@zonnet.nl > > > > Cc: sip@ietf.org > > > > Betreff: RE: AW: [Sip] Extension of conference procedures > > > > > > > > > > > > Hi, > > > > My view is that every solution where you only have A, B and a > > > > conference server and B only supports RFC 3261 will have some > > > > limitation and will be a hack. > > > > > > > > The recommended way to do it is for A to send a Refer to B to > > > > the focus. > > > > > > > > Also asking that B supporting only RFC 3261 will support > > > > conference event package is contradictory. B will not even be > > > > aware that it is in a conference. > > > > > > > > Roni Even > > > > > > > > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > > > > A consensus means that everyone agrees to say collectively > > > > what no one believes individually > > > > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > > > > > > > > > -----Original Message----- > > > > > From: Huelsemann, Martin [mailto:Martin.Huelsemann@t-com.net] > > > > > Sent: Monday, August 27, 2007 12:59 PM > > > > > To: jbemmel@zonnet.nl > > > > > Cc: sip@ietf.org > > > > > Subject: AW: AW: [Sip] Extension of conference procedures > > > > > > > > > > Hi, > > > > > > > > > > the pure RFC 3261 client won't be the normal case, of > > > > course. But there > > > > > might be networks with which you want to interwork where > > > > those simple > > > > > clients are existing. > > > > > Okay, you got me, it's again the PSTN interworking. So > > > > let's say what is > > > > > needed is a fallback solution for this case. > > > > > On the other hand, this fallback might be useful for a > > > > normal SIP client > > > > > which supports RFC3891, too, e.g. if there are problems with > > > > > authorization. > > > > > > > > > > The user experience of the invitee should be exactly as you > > > > describe. > > > > > > > > > > If A sends the reINVITE / UPDATE himself that could be a > > > > solution, too. > > > > > The only thing is, can B then use all the conference features (e. > g. > > > > > conference event package), when the focus has no knowledge on the > > > > > signalling level that B is connected to the conference bridge? > > > > > > > > > > Regards, Martin > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Ursprüngliche Nachricht----- > > > > > > Von: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > > > > > > Gesendet: Sonntag, 26. August 2007 15:24 > > > > > > An: Hülsemann, Martin > > > > > > Cc: Alexeitsev, Denis; sip@ietf.org > > > > > > Betreff: Re: AW: [Sip] Extension of conference procedures > > > > > > > > > > > > > > > > > > Martin, > > > > > > > > > > > > Now it becomes more clear. So the requirement is to > > > > enable a scenario > > > > > > where a regular call is transformed into a conference > > > > call, assuming > > > > > > that the invitee only has a "pure RFC3261" client. > > > > > > More specifically: > > > > > > > > > > > > - to get a smooth user experience, the scenario must not cause > the > > > > > > invitee's phone to ring, and/or ask the invitee for permission > > > > > > (acceptance is assumed to be implied) > > > > > > > > > > > > What if A would send the reINVITE (or UPDATE) itself, while > > > > > > filling in > > > > > > the SDP according to the media provided by the conference > > > > > > server (i.e. > > > > > > use codecs, media ports as received from the focus)? (trying > > > > > > to get the > > > > > > requirements more clear here) > > > > > > > > > > > > In practice, it may still be a challenge to get such "very > simple > > > > > > terminals" to properly handle a change of media (i.e. new > > > > destination > > > > > > ip/port for sending, new source ip/port and RTP src id, > > > > and possibly > > > > > > different codecs) > > > > > > > > > > > > Regards, > > > > > > Jeroen > > > > > > > > > > > > > > > > > > Huelsemann, Martin wrote: > > > > > > > Hi Jeroen, > > > > > > > > > > > > > > the usage of the Replaces header is of course the best > > > > > > solution, it's also described in the regarding 3GPP > > > > > > conferencing spec. > > > > > > > The disadvantage of the usage of the Repaces header is, > > > > > > that it puts requirements on the UE of the invited user, it > > > > > > would have to support RFC 3891. And if it supports, it really > > > > > > would have to accept the 2nd INVITE, which is not mandatory > > > > > > according to RFC 3891 I think. > > > > > > > Anyway what is needed in addition is a solution how also > > > > > > very simple terminals (e. g. only supporting RFC 3261) can be > > > > > > invited to an ad-hoc conference, whithout having to say to > > > > > > the invited user to please hang up because there will be a > > > > > > call from the focus shortly. > > > > > > > > > > > > > > Re-using an already established dialog at least at the > > > > > > first glance seems to be a simply and invited UE independent > > > > > > solution. And as this re-INVITE it wanted by at least one of > > > > > > the involved user, I would more compare it to some kind of > > > > > > triggered 3rd party call control than to spoofing. > > > > > > > > > > > > > > Of course as you said it would have to be made clear that > > > > > > the focus is able to collect all the information needed for > > > > > > sending re-INVITEs (proposed "?" mechanism usage, dialog > > > > > > event package, etc.). > > > > > > > > > > > > > > > > > > > > > Regards, Martin > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> -----Ursprüngliche Nachricht----- > > > > > > >> Von: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > > > > > > >> Gesendet: Freitag, 24. August 2007 17:06 > > > > > > >> An: Alexeitsev, Denis; sip@ietf.org > > > > > > >> Betreff: Re: [Sip] Extension of conference procedures > > > > > > >> > > > > > > >> > > > > > > >> Denis, > > > > > > >> > > > > > > >> If I understand your scenario, "focus" is a third party > > > > > > >> separate from A and > > > > > > >> B, right? (e.g. a conference server) > > > > > > >> > > > > > > >> In that case the focus is not a party in the A-B dialog, and > > > > > > >> would need more > > > > > > >> than Call-ID, From and To to be able to construct a reINVITE > > > > > > >> that B would > > > > > > >> accept as coming from A (e.g. CSeq). In any case, this looks > > > > > > >> like a very > > > > > > >> inelegant, hacked solution (as the conference server is > > > > > > >> basically spoofing) > > > > > > >> > > > > > > >> RFC4579 section 5.10 provides some insipration, as well as > > > > > > >> http://www.ietf.org/internet-drafts/draft-ietf-sipping- > service > > > > > > >> -examples-13.txt > > > > > > >> scenario 2.5 > > > > > > >> > > > > > > >> For example, A could include a 'Replaces' header in the URI > > > > > > >> it includes in > > > > > > >> its conference URI list. Then the conference server would > > > > > > send a new > > > > > > >> (out-of-dialog) INVITE to B containing this Replaces header, > > > > > > >> and B would > > > > > > >> know that it is associated with the dialog it has with A (and > > > > > > >> can replace > > > > > > >> it, without ringing if the UA is constructed like that) > > > > > > >> > > > > > > >> The conference server should probably also include a > > > > > > >> Referred-By containing > > > > > > >> A's AoR, either automatically (i.e. copy from From header in > > > > > > >> INVITE) or > > > > > > >> included by A in the URI (former is better) > > > > > > >> > > > > > > >> Regards, > > > > > > >> Jeroen > > > > > > >> > > > > > > >> Alexeitsev, D wrote: > > > > > > >> > > > > > > >>> I'd like to discuss the extension of the current conference > > > > > > >>> > > > > > > >> procedures > > > > > > >> > > > > > > >>> with the following functionality. > > > > > > >>> > > > > > > >>> 3GPP conference specifications are basing generally on the > > > > > > >>> Conferencing Framework (RFC 4353) and for one possibility > > > > > > >>> > > > > > > >> of inviting > > > > > > >> > > > > > > >>> users to the confrence on > > > > draft-ietf-sip-uri-list-conferencing. > > > > > > >>> > > > > > > >>> Using the conferencing framework, the following situation > > > > > > can occur > > > > > > >>> when a user is invited to an ad-hoc conference: > > > > > > >>> User A is in a dialog with user B, and decides to start a > > > > > > >>> > > > > > > >> conference, > > > > > > >> > > > > > > >>> for example using an INVITE request to the focus which > > > > > > >>> > > > > > > >> includes a URI > > > > > > >> > > > > > > >>> list with the URIs of the users which shall be added to the > > > > > > >>> conference, incl. B. So when the INVITE request from the > focus > > > > > > >>> arrives at B, he is still in the original dialog with > > > > A, and so it > > > > > > >>> depends on B if he accepts the 2nd INVITE and the > > > > > > conference can be > > > > > > >>> established. > > > > > > >>> > > > > > > >>> At the last 3GPP CT1 meeting the idea of transporting dialog > > > > > > >>> identifiers together with the URIs was introduced to > > > > solve this > > > > > > >>> problem. Basing on the idea that the procedures at > > > > the conference > > > > > > >>> server are extended in that way, that the conference > > > > > > server is aware > > > > > > >>> of already established dialogs, the focus then has the > > > > > > >>> > > > > > > >> possibility to > > > > > > >> > > > > > > >>> send re-INVITES in the indicated dialogs and connect the > > > > > > media from > > > > > > >>> the invited users to the conference bridge. > > > > > > >>> In the URI list the dialogs can be indicated using the > > > > > > "?" mechanism > > > > > > >>> according to subclause 19.1.1 of RFC 3261. > > > > > > >>> > > > > > > >>> Following example shows the proposed mechanism: > > > > > > >>> > > > > > > >>> INVITE Conference > > > > > > >>> To: Conference > > > > > > >>> From: A > > > > > > >>> Require: recipient-list-invite > > > > > > >>> > > > > > > >>> Content-Type: application/resource-lists+xml > > > > > > >>> Content-Disposition: recipient-list > > > > > > >>> > > > > > > >>> <?xml version="1.0" encoding="UTF-8"?> > > > > > > >>> <resource-lists xmlns="urn:ietf:params:xml:ns:resource- > lists" > > > > > > >>> xmlns:cp="urn:ietf:params:xml:ns:copyControl"> > > > > > > >>> <list> > > > > > > >>> <entry uri="B?Call-ID=1&From=A%3Btag%3Da&To=B%3Btag%3Db" > > > > > > >>> cp:copyControl="to"/> > > > > > > >>> <entry uri="C?Call-ID=2&From=A%3Btag%3Da&To=C%3btag%3Dc" > > > > > > >>> cp:copyControl="to"/> > > > > > > >>> </list> > > > > > > >>> </resource-lists> > > > > > > >>> > > > > > > >>> Greetings, > > > > > > >>> Denis Alexeitsev > > > > > > >>> > > > > > > >>> > > > > > > >>> _______________________________________________ > > > > > > >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > > > >>> This list is for NEW development of the core SIP Protocol > > > > > > >>> Use sip-implementors@cs.columbia.edu for questions on > > > > current sip > > > > > > >>> Use sipping@ietf.org for new developments on the > > > > > > application of sip > > > > > > >>> > > > > > > >> > > > > > > >> _______________________________________________ > > > > > > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > > > >> This list is for NEW development of the core SIP Protocol > > > > > > >> Use sip-implementors@cs.columbia.edu for questions on > > > > current sip > > > > > > >> Use sipping@ietf.org for new developments on the > > > > application of sip > > > > > > >> > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > > This list is for NEW development of the core SIP Protocol > > > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > > > Use sipping@ietf.org for new developments on the application of > sip > > > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip
- [Sip] Extension of conference procedures Alexeitsev, D
- Re: [Sip] Extension of conference procedures Jeroen van Bemmel
- AW: [Sip] Extension of conference procedures Huelsemann, Martin
- Re: AW: [Sip] Extension of conference procedures Jeroen van Bemmel
- Re: AW: [Sip] Extension of conference procedures Dale.Worley
- AW: AW: [Sip] Extension of conference procedures Huelsemann, Martin
- RE: AW: [Sip] Extension of conference procedures Even, Roni
- RE: AW: [Sip] Extension of conference procedures Brian Rosen
- AW: AW: [Sip] Extension of conference procedures Huelsemann, Martin
- RE: AW: [Sip] Extension of conference procedures Even, Roni
- Re: AW: [Sip] Extension of conference procedures Peili Xu
- RE: AW: [Sip] Extension of conference procedures Even, Roni
- RE: AW: [Sip] Extension of conference procedures Peili Xu
- AW: AW: [Sip] Extension of conference procedures Huelsemann, Martin
- Re: AW: AW: [Sip] Extension of conference procedu… Eric Burger
- AW: AW: AW: [Sip] Extension of conference procedu… Huelsemann, Martin
- RE: AW: AW: [Sip] Extension of conference procedu… DRAGE, Keith (Keith)
- Re: AW: AW: [Sip] Extension of conference procedu… Peili Xu
- ?headers ( was RE: AW: AW: [Sip] Extension of con… Mary Barnes
- Re: ?headers ( was RE: AW: AW: [Sip] Extension of… Jeroen van Bemmel
- Re: AW: AW: [Sip] Extension of conference procedu… Dean Willis
- RE: AW: AW: [Sip] Extension of conference procedu… Jerry Yin
- AW: ?headers ( was RE: AW: AW: [Sip] Extension of… Huelsemann, Martin
- Re: AW: AW: [Sip] Extension of conference procedu… Peili Xu
- Re: AW: AW: [Sip] Extension of conference procedu… Alan Johnston
- Re: AW: AW: [Sip] Extension of conference procedu… Jerry Yin
- AW: AW: AW: [Sip] Extension of conference procedu… Huelsemann, Martin
- Re: AW: AW: AW: [Sip] Extension of conference pro… Paul Kyzivat
- AW: AW: AW: AW: [Sip] Extension of conference pro… Huelsemann, Martin
- RE: AW: AW: [Sip] Extension of conference procedu… DRAGE, Keith (Keith)
- Re: AW: AW: [Sip] Extension of conference procedu… Adam Roach
- Re: AW: AW: [Sip] Extension of conference procedu… Paul Kyzivat