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
