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
