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
