Re: AW: AW: [Sip] Extension of conference procedures

[Eric Burger <[e-mail]>]

I must be missing an important point.  To me, right now, this whole thread,
besides being 11 pages long, seems pointless.

Either a phone knows about REFER or the phone does 3261.  Adding something
new to 3261 means the phone needs to know about it means it might as well
know about REFER.

Hacking 3261 to enable a man-in-the-middle attack, where the conference
server or PSAP can take over a call (good thing) enables a nasty device to
take over a call (bad thing) is not a good idea.


On 8/30/07 4:37 AM, "Huelsemann, Martin" <[e-mail]>
wrote:

> 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


Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.


_______________________________________________
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