Hi, I think especially for the case where A has several ongoing dialogs with B and A wants only to include a certain of the dialogs into the conference, he has to give some information in which of the dialogs the AS shall start 3pcc procedures.
Regards, Martin > -----Ursprüngliche Nachricht----- > Von: Peili Xu [mailto:[EMAIL PROTECTED] > Gesendet: Donnerstag, 30. August 2007 08:53 > An: 'Even, Roni' > Cc: [email protected] > Betreff: RE: AW: [Sip] Extension of conference procedures > > > > Hi Roni, > > Your case is even "smarter" than mine ;-) that's OK for > me. > > But, I'm just wondering whether there is case that A has > multiple on going dialogs with say B, C, D and only want > to turn A-B and A-C to a conference then dialog > information maybe needed. > > I'd happy to hear clarification for this point from whom > raise the requirements. > > Peili > > -----Original Message----- > From: Even, Roni [mailto:[EMAIL PROTECTED] > Sent: Thursday, August 30, 2007 2:09 PM > To: Peili Xu > Cc: [email protected] > Subject: RE: AW: [Sip] Extension of conference > procedures > > > > 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:[EMAIL PROTECTED] > > Sent: Wednesday, August 29, 2007 5:08 PM > > To: Even, Roni > > Cc: Huelsemann, Martin; [email protected] > > 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 <[EMAIL PROTECTED]>: > > > > > > 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:[EMAIL PROTECTED] > > > > Sent: Wednesday, August 29, 2007 1:05 PM > > > > To: Even, Roni > > > > Cc: [email protected]; [EMAIL PROTECTED] > > > > 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:[EMAIL PROTECTED] > > > > > Gesendet: Montag, 27. August 2007 12:16 > > > > > An: Hülsemann, Martin; [EMAIL PROTECTED] > > > > > Cc: [email protected] > > > > > 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:[EMAIL PROTECTED] > > > > > > Sent: Monday, August 27, 2007 12:59 PM > > > > > > To: [EMAIL PROTECTED] > > > > > > Cc: [email protected] > > > > > > 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:[EMAIL PROTECTED] > > > > > > > Gesendet: Sonntag, 26. August 2007 15:24 > > > > > > > An: Hülsemann, Martin > > > > > > > Cc: Alexeitsev, Denis; [email protected] > > > > > > > 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:[EMAIL PROTECTED] > > > > > > > >> Gesendet: Freitag, 24. August 2007 17:06 > > > > > > > >> An: Alexeitsev, Denis; [email protected] > > > > > > > >> 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 > [EMAIL PROTECTED] for > > > > > > > >>> questions on > > > > > current sip > > > > > > > >>> Use [EMAIL PROTECTED] 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 [EMAIL PROTECTED] for > questions on > > > > > current sip > > > > > > > >> Use [EMAIL PROTECTED] 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 > > > > > > [EMAIL PROTECTED] for questions > on current sip > > > > > > Use [EMAIL PROTECTED] 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 > > > [EMAIL PROTECTED] for questions on > current sip Use > > > [EMAIL PROTECTED] 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 [EMAIL PROTECTED] for > questions on current sip Use [EMAIL PROTECTED] 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 [EMAIL PROTECTED] for questions on current sip > Use [EMAIL PROTECTED] 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 [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
