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
