Subject: [Sip] Extension of conference procedures

From: "Alexeitsev, D" <[email-masked]>
Date: Fri, 24 Aug 2007 15:00:58 +0200

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-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Fri, 24 Aug 2007 17:05:52 +0200

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:
> 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:
> 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.

---

From: "Huelsemann, Martin" <[email-masked]>
Date: Sun, 26 Aug 2007 14:42:47 +0200

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-masked]] 
> Gesendet: Freitag, 24. August 2007 17:06
> An: Alexeitsev, Denis; [email-masked]
> Betreff: Re: [Sip] Extension of conference procedures
> 
> 
> Denis,
>

---

From: Jeroen van Bemmel <[email-masked]>
Date: Sun, 26 Aug 2007 15:23:49 +0200

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:
>>> I'd like to discuss the extension of the current conference 
>>>       
>> procedures
>>     
>>> Conferencing Framework (RFC 4353) and for one possibility 
>>>       
>> of inviting
>>     
>>> 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
>>     
>>> of already established dialogs, the focus then has the 
>>>       
>> possibility to
>>

---

From: [email-masked]
Date: Sun, 26 Aug 2007 21:52:58 -0400

From: "Huelsemann, Martin" <[email-masked]>

   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.

Why would you want to consider user agents that do not support
Replaces?  They would be unable to execute consultative transfers,
call pick-ups, and many other features.

Dale

---

From: "Huelsemann, Martin" <[email-masked]>
Date: Mon, 27 Aug 2007 11:59:11 +0200

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

> Gesendet: Sonntag, 26. August 2007 15:24
> An: Hülsemann, Martin
> Cc: Alexeitsev, Denis; [email-masked]
> Betreff: Re: AW: [Sip] Extension of conference procedures
> 
> 
> Martin,
> 
> > 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
> >
> >
> >
> >
> >
> >

---

From: "Even, Roni" <[email-masked]>
Date: Mon, 27 Aug 2007 13:15:53 +0300

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-masked]]
> Sent: Monday, August 27, 2007 12:59 PM
> To: [email-masked]
> Cc: [email-masked]
> 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.
> 
> 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
> 
> 
> 
> 
>

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 27 Aug 2007 11:11:40 -0400

Yeah, and, coming soon, emergency call.  

Endpoints may have to be able to have a two way call to a call center
upgraded to an emergency 3 way call using a bridge at a PSAP.  This means
all devices, effectively, will have to support 3891.

This would occur when you call a call center that handles a wide range of
help and the call center decides it needs to make the call an emergency
call.  It's hard to know in advance which devices may have a need to do
this.

Brian

> From: [email-masked] [mailto:[email-masked]]
> Sent: Sunday, August 26, 2007 9:53 PM
> To: [email-masked]
> Subject: Re: AW: [Sip] Extension of conference procedures
>

---

From: "Huelsemann, Martin" <[email-masked]>
Date: Wed, 29 Aug 2007 12:05:16 +0200

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

> Von: Even, Roni [mailto:[email-masked]] 
> Gesendet: Montag, 27. August 2007 12:16
> An: Hülsemann, Martin; [email-masked]
> Cc: [email-masked]
> 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. 
> 
> 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
>

---

From: "Even, Roni" <[email-masked]>
Date: Wed, 29 Aug 2007 13:12:11 +0300

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

> Sent: Wednesday, August 29, 2007 1:05 PM
> To: Even, Roni
> Cc: [email-masked]; [email-masked]
> 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
> 
> 
> 
> 
>

---

From: "Peili Xu" <[email-masked]>
Date: Wed, 29 Aug 2007 22:07:52 +0800

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

---

From: "Even, Roni" <[email-masked]>
Date: Thu, 30 Aug 2007 09:09:07 +0300

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

> From: Peili Xu [mailto:[email-masked]]
> Sent: Wednesday, August 29, 2007 5:08 PM
> To: Even, Roni
> Cc: Huelsemann, Martin; [email-masked]
> > A "simple" RFC 3261 only phone relies on a 3PCC or softswitch to manage
> telephony services (not only conferencing)
> >
> > Roni Even
> >
> > > > > > >> http://www.ietf.org/internet-drafts/draft-ietf-sipping-
> service
> > > > > > >> -examples-13.txt
> > > > > > >> scenario 2.5
> > > > > > >>

---

From: Peili Xu <[email-masked]>
Date: Thu, 30 Aug 2007 14:53:02 +0800

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-masked]] 
Sent: Thursday, August 30, 2007 2:09 PM
To: Peili Xu
Cc: [email-masked]
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

> 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.
> 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.
> 
> > 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
> > > 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
> > > > The recommended way to do it is for A to send a
Refer to B to 
> > > > the focus.
> > > > A consensus means that everyone agrees to say
collectively what 
> > > > no one believes individually
> > > > > 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
> > > > > On the other hand, this fallback might be
useful for a
> > > > normal SIP client
> > > > > 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?
> > > > > > Now it becomes more clear. So the
requirement is to
> > > > enable a scenario
> > > > > > where a regular call is transformed into a
conference
> > > > call, assuming
> > > > > > - 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
> > > > > > 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.
> > > > > > 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.
> > > > > > >
> > > > > > >> 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
> 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
> > > > > > >>> I'd like to discuss the extension of the
current 
> > > > > > >>> conference
> > > > > > >>> 3GPP conference specifications are
basing generally on 
> > > > > > >>> the Conferencing Framework (RFC 4353)
and for one 
> > > > > > >>> possibility
> > > > > > >>> Using the conferencing framework, the
following 
> > > > > > >>> situation
> > > > > > can occur
> > > > > > >>> User A is in a dialog with user B, and
decides to start 
> > > > > > >>> a
> > > > > > >>> 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
> > > > > > >>> send re-INVITES in the indicated dialogs
and connect the
> > > > > > media from
> > > > > > >>> In the URI list the dialogs can be
indicated using the
> > > > > > "?" mechanism
<resource-lists 
> > > > > > >>> xmlns="urn:ietf:params:xml:ns:resource-
> lists"
> > > > > > >>>
> > > > > > >>>    <entry
uri="B?Call-ID=1&From=A%3Btag%3Da&To=B%3Btag%3Db"
> > > > > > >>>    <entry
uri="C?Call-ID=2&From=A%3Btag%3Da&To=C%3btag%3Dc"
> > > > > > >>> Sip mailing list  
https://www1.ietf.org/mailman/listinfo/sip
> > > > > > >>> This list is for NEW development of the
core SIP 
> > > > > > >>> Protocol Use
[email-masked] for 
> > > > > > >>> questions on
> > > > current sip
> > > > > > >>> Use [email-masked] for new
developments on the
> > > > > > application of sip
> > > > > > >> Sip mailing list  
https://www1.ietf.org/mailman/listinfo/sip
> > > > > > >> Use [email-masked] for
questions on
> > > > current sip
> > > > > > >> Use [email-masked] 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-masked] for questions
on current sip 
> > > > > Use [email-masked] 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-masked] for questions on
current sip Use 
> > [email-masked] 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-masked] for
questions on current sip Use [email-masked] for new
developments on the application of sip

---

From: "Huelsemann, Martin" <[email-masked]>
Date: Thu, 30 Aug 2007 10:37:26 +0200

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

> Von: Peili Xu [mailto:[email-masked]] 
> Gesendet: Donnerstag, 30. August 2007 08:53
> An: 'Even, Roni'
> Cc: [email-masked]
> core SIP Protocol