Re: AW: [Sip] Extension of conference procedures

["Peili Xu" <[e-mail]>]

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



2007/8/29, Even, Roni <[e-mail]>:
>
> 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
>
> > -----Original Message-----
> > From: Huelsemann, Martin [mailto:[e-mail]]
> > Sent: Wednesday, August 29, 2007 1:05 PM
> > To: Even, Roni
> > Cc: [e-mail]; [e-mail]
> > Subject: AW: AW: [Sip] Extension of conference procedures
> >
> > 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
> >
> >
> >
> >
> >
> > > -----Ursprüngliche Nachricht-----
> > > Von: Even, Roni [mailto:[e-mail]]
> > > Gesendet: Montag, 27. August 2007 12:16
> > > An: Hülsemann, Martin; [e-mail]
> > > Cc: [e-mail]
> > > 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.
> > >
> > > 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:[e-mail]]
> > > > Sent: Monday, August 27, 2007 12:59 PM
> > > > To: [e-mail]
> > > > Cc: [e-mail]
> > > > 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:[e-mail]]
> > > > > Gesendet: Sonntag, 26. August 2007 15:24
> > > > > An: Hülsemann, Martin
> > > > > Cc: Alexeitsev, Denis; [e-mail]
> > > > > 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:[e-mail]]
> > > > > >> Gesendet: Freitag, 24. August 2007 17:06
> > > > > >> An: Alexeitsev, Denis; [e-mail]
> > > > > >> 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 [e-mail] for questions on
> > > current sip
> > > > > >>> Use [e-mail] 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 [e-mail] for questions on
> > > current sip
> > > > > >> Use [e-mail] 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 [e-mail] for questions on current sip
> > > > Use [e-mail] 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 [e-mail] for questions on current sip
> Use [e-mail] 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 [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip