AW: AW: [Sip] Extension of conference procedures

["Huelsemann, Martin" <[e-mail]>]

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



> -----Ursprüngliche Nachricht-----
> Von: Peili Xu [mailto:[e-mail]] 
> Gesendet: Donnerstag, 30. August 2007 08:53
> An: 'Even, Roni'
> Cc: [e-mail]
> Betreff: RE: AW: [Sip] Extension of conference procedures
> 
> 
> 
> 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:[e-mail]] 
> Sent: Thursday, August 30, 2007 2:09 PM
> To: Peili Xu
> Cc: [e-mail]
> 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
> 
> > -----Original Message-----
> > From: Peili Xu [mailto:[e-mail]]
> > Sent: Wednesday, August 29, 2007 5:08 PM
> > To: Even, Roni
> > Cc: Huelsemann, Martin; [e-mail]
> > Subject: Re: AW: [Sip] Extension of conference
> procedures
> > 
> > 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
> 
> 
> 
> 
> _______________________________________________
> 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