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

From: Eric Burger <[email-masked]>
Date: Tue, 04 Sep 2007 10:59:31 -0700

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" <[email-masked]>
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:[email-masked]]
>> Gesendet: Donnerstag, 30. August 2007 08:53
>> An: 'Even, Roni'
>> Cc: [email-masked]
>> 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:[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
>> 
>>> -----Original Message-----
>>> From: Peili Xu [mailto:[email-masked]]
>>> Sent: Wednesday, August 29, 2007 5:08 PM
>>> To: Even, Roni
>>> Cc: Huelsemann, Martin; [email-masked]
>>> 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 <[email-masked]>:
>>>> 
>>>> 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:[email-masked]]
>>>>> Sent: Wednesday, August 29, 2007 1:05 PM
>>>>> To: Even, Roni
>>>>> Cc: [email-masked]; [email-masked]
>>>>> 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:[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.
>>>>>> 
>>>>>> 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.
>>>>>>> 
>>>>>>> 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:[email-masked]]
>>>>>>>> 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,
>>>>>>>> 
>>>>>>>> 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:[email-masked]]
>>>>>>>>>> Gesendet: Freitag, 24. August 2007 17:06
>>>>>>>>>> An: Alexeitsev, Denis; [email-masked]
>>>>>>>>>> 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
>> [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
>>>> 
>> 
>> 
>> _______________________________________________
>> 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

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

---

From: Eric Burger <[email-masked]>
Date: Tue, 04 Sep 2007 10:59:31 -0700

---

From: Eric Burger <[email-masked]>
Date: Tue, 04 Sep 2007 10:59:31 -0700

---

From: "Huelsemann, Martin" <[email-masked]>
Date: Wed, 5 Sep 2007 12:58:58 +0200

Hi Eric,

there is nothing new added to RFC 3261, only perhaps some new semantics to subclause 19.1.1. The conference user would have to know about this, but that's okay, there are always some requirements if you want to use a service (REFER as default, proposed "?" usage as fallback).

What are the additions the user who's added to the conference would have to support? The added user would receive basically just a reINVITE, so in principal support of 3261 would be sufficient. 

basically, in principal: the intention to minimize the requirements on B for a service which A uses, in order to maximize the chance this ad-hoc conference will work; perhaps there will be no 100% guarantee for this.

BR, Martin

> Von: Eric Burger [mailto:[email-masked]] 
> Gesendet: Dienstag, 4. September 2007 20:00
> An: Hülsemann, Martin
> Cc: [email-masked]
> Betreff: Re: AW: AW: [Sip] Extension of conference procedures
> 
> 
> 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.
>

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Wed, 5 Sep 2007 13:10:07 +0200

So this is a convenient way to bring us back to the other half of the issue which we do not seem to have discussed yet. When the syntax was defined that allowed ?headers:

      Headers: Header fields to be included in a request constructed
         from the URI.

         Headers fields in the SIP request can be specified with the "?"
         mechanism within a URI.  The header names and values are
         encoded in ampersand separated hname = hvalue pairs.  The
         special hname "body" indicates that the associated hvalue is
         the message-body of the SIP request.

What usage did the SIP WG envisage for this, and thus what semantics did they define for that usage.

Is it appropriate to assign new semantics to such usage?

Regards

Keith

> From: Huelsemann, Martin [mailto:[email-masked]] 
> Sent: Wednesday, September 05, 2007 11:59 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: AW: AW: AW: [Sip] Extension of conference procedures
> 
> Hi Eric,
> 
> there is nothing new added to RFC 3261, only perhaps some new 
> semantics to subclause 19.1.1. The conference user would have 
> to know about this, but that's okay, there are always some 
> requirements if you want to use a service (REFER as default, 
> proposed "?" usage as fallback).
> 
> What are the additions the user who's added to the conference 
> would have to support? The added user would receive basically 
> just a reINVITE, so in principal support of 3261 would be sufficient. 
> 
> 
> basically, in principal: the intention to minimize the 
> requirements on B for a service which A uses, in order to 
> maximize the chance this ad-hoc conference will work; perhaps 
> there will be no 100% guarantee for this.
> 
> 
> BR, Martin
> 
> 
> 
> 
> 
> 
> 
> 
> 
> > I must be missing an important point.  To me, right now, this whole 
> > thread, besides being 11 pages long, seems pointless.
> > 
> > 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.
> > 
> > 
> > >> Your case is even "smarter" than mine ;-)  that's OK for me.
> > >> 
> 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.
> > >> 
> raise the 
> > >> requirements.
> > >> 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
> > >> 
> > >> This list is for NEW development of the core SIP Protocol Use 
> > >> [email-masked] for new developments on the application of sip
> > >> 
> > >> 
> > >> 
> > >> 
> > >> This list is for NEW development of the core SIP Protocol Use 
> > >> [email-masked] for new developments on the application of 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
> > 
> > 
> > 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.
> > 
> 
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: "Peili Xu" <[email-masked]>
Date: Wed, 5 Sep 2007 23:41:28 +0800

Yes, It's vague in RFC3261.  I'm only aware of the usage in REFER now.
It'll be good to clarify the semantics in the usage in url-list.

---

From: "Mary Barnes" <[email-masked]>
Date: Wed, 5 Sep 2007 11:05:09 -0500

RFC 4244 (History-Info) also uses this mechanism to capture the Reason
and Privacy associated with the URIs that are included as part of the
History-Info header.  My understanding is that it's really just a nifty
way to compactly reuse existing headers (i.e., it makes the History-Info
much more compact as I didn't need to define additional parameters for
the header, but could rather reuse the existing ones, whose existing
semantics perfectly applicable).  I do think that the use of the headers
that might be escaped using this mechanism should be explained,
particularly in cases where you might be extending the use of existing
headers as I did for the Privacy header.  

Mary.  

-----Original Message-----
From: Peili Xu [mailto:[email-masked]] 
Sent: Wednesday, September 05, 2007 10:41 AM
To: DRAGE, Keith (Keith)
Cc: [email-masked]
Subject: Re: AW: AW: [Sip] Extension of conference procedures

2007/9/5, DRAGE, Keith (Keith) <[email-masked]>:
> So this is a convenient way to bring us back to the other half of the
issue which we do not seem to have discussed yet. When the syntax was
> Is it appropriate to assign new semantics to such usage?
Note: I snipped the rest of this thread as it was getting really LONG.

---

From: Jeroen van Bemmel <[email-masked]>
Date: Wed, 05 Sep 2007 21:38:39 +0200

Concretely, would we be looking at something like

sip:[email-masked]?From=[email-masked];tag=x&To=sip:[email-masked];tag=y&Call-ID=i&CSeq=1234&Route=rrr&body=<SDP 
with proper session versions etc>

in order to help the conference server fake a reINVITE towards B?

RFC3261 provides some guidance on the types of headers that elements 
might accept as part of a URI. Specifically, it states in 19.1.5:
"An implementation SHOULD NOT honor these obviously dangerous header 
fields: From, Call-ID, CSeq, Via, and Record-Route."

I believe the usage that was foreseen for this mechanism (as illustrated 
by some of the examples in RFC3261) was to provide some context for the 
request, such as Subject and Priority fields. In other words, optional 
information that might help the receiver understand the context.

The above are not different semantics for headers in a URI (concept 
remains: form a new request based on the URI, inserting the headers), 
but it does imply a deviation from the basic SIP call model (basically a 
way of encoding dialog state in a SIP URI, and sending that to another 
element such that it can reconstruct that state and assume the role of 
the party which shared the state).

Apart from the fact that this approach will fall short for SDP related 
state: is this desirable?

Regards,
Jeroen

Mary Barnes wrote:
>>          Headers fields in the SIP request can be specified with the
>>     
> "?"
>   
>> What usage did the SIP WG envisage for this, and thus what semantics
>>     
> did they define for that usage.
>

---

From: Dean Willis <[email-masked]>
Date: Wed, 5 Sep 2007 19:19:52 -0500

On Sep 5, 2007, at 6:10 AM, DRAGE, Keith ((Keith)) wrote:

> So this is a convenient way to bring us back to the other half of  
> the issue which we do not seem to have discussed yet. When the  
> syntax was defined that allowed ?headers:
>
> What usage did the SIP WG envisage for this, and thus what  
> semantics did they define for that usage.
>

I believe we were confused about the differences between headers and  
URI parameters and didn't quite get the "?" notation used with HTTP  
cgi-bin.

But that's just where it started. "?" notation has since been fairly  
widely used as a way to "flatten" elements of a SIP request for  
expression on a single (if somewhat long) line, which has been shown  
to be somewhat useful in both REFER and in retargeting proxies that  
allow one-line configuration of a target URL.

--
Dean

---

From: "Huelsemann, Martin" <[email-masked]>
Date: Tue, 11 Sep 2007 15:13:02 +0200

Yes, that would be the way the reINVITE could look like. For the SDP I think a new offer from the focus is needed.

It's the question if this is desirable, but if it works and we can handle the security aspects, I think it's at least not completely undesirable as a fallback solution for a conference. Of course this should not be the normal way of activating the ad-hoc conference.

If we agree on the usage, where could this usage of the regarding headers be documented? Would it make necessary a new I-D? Or could this also be described in existing drafts related to this topic, e. g. draft-ietf-sip-uri-list-conferencing? 

BR, Martin

> Von: Jeroen van Bemmel [mailto:[email-masked]] 
> Gesendet: Mittwoch, 5. September 2007 21:39
> An: Mary Barnes
> Cc: [email-masked]; DRAGE, Keith (Keith)
> Betreff: Re: ?headers ( was RE: AW: AW: [Sip] Extension of 
> conferenceprocedures
> 
> 
> sip:[email-masked]?From=[email-masked];tag=x
> &To=sip:[email-masked];tag=y&Call-ID=i&CSeq=1234&Route=r
> rr&body=<SDP 
> semantics

---

From: Jerry Yin <[email-masked]>
Date: Tue, 11 Sep 2007 15:11:54 -0700 (PDT)

I think there are two ways to invoke a conference. One is to invoke the conference by the conference server. The other is ad-hoc conference invoked by the participants. The draft-ietf-sip-uri-list-conferencing was trying to solve the problem by initiating a conference from the server. 
  Here's what I think for the ad-hoc conference.
  Participants: A calls B (a UA or a conference room) and put B on-hold, and then A calls C. Now A presses the conf button.
  1. If B has a conference room url, A will transfer C to B (by REFER), as some of you discussed already. It actually is supported by some companies already as I know.
  2. But if B is a UA, when the conf button is pressed, the only SIP messages send out by A is the re-Invite (off-hold) to B since most SIP phones support 3-way conference locally. Then A will do the audio mixing locally. So far I didn't find any solution to transfer the local 3-way conference to a centralized conference yet. Currently in our system, we adopted the "Join" header (RFC3911). When A sends the re-Invite to B, it also includes a Join header contains the C's dialog info. The B2B server will translate the Join to a centralized conference. It will Invite C with a Replace header to replace the session between A and C. C will sends a BYE to A. The server will update the media to A and B (reInvite). Then all three parties are in the centralized conference room.
  I hope the new RFC for conference also capture the behavior described in 2. Whether it's Join header or something else. The user should be able to call someone first and then decided to setup a conference.
Jerry

Jeroen van Bemmel <[email-masked]> wrote:  Concretely, would we be looking at something like

sip:[email-masked]?From=[email-masked];tag=x&To=sip:[email-masked];tag=y&Call-ID=i&CSeq=1234&Route=rrr&body=with proper session versions etc>

Regards,
Jeroen

Mary Barnes wrote:
> 2007/9/5, DRAGE, Keith (Keith) :
> 

       
---------------------------------
 Check out  the hottest 2008 models today at Yahoo! Autos.

---

From: "Peili Xu" <[email-masked]>
Date: Wed, 12 Sep 2007 22:14:52 +0800

Hi Jerry,

please see my comments in line.

2007/9/12, Jerry Yin <[email-masked]>:
>
> I think there are two ways to invoke a conference. One is to invoke the
> conference by the conference server. The other is ad-hoc conference invoked
> by the participants. The
> draft-ietf-sip-uri-list-conferencing was trying to solve
> the problem by initiating a conference from the server.
> Participants: A calls B (a UA or a conference room) and put B on-hold, and
> then A calls C. Now A presses the conf button.
> 1. If B has a conference room url, A will transfer C to B (by REFER), as
> some of you discussed already. It actually is supported by some companies
> already as I know.
> 2. But if B is a UA, when the conf button is pressed, the only SIP messages
> send out by A is the re-Invite (off-hold) to B since most SIP phones support
> 3-way conference locally. Then A will do the audio mixing locally. So far I
> didn't find any solution to transfer the local 3-way conference to a
> centralized conference yet. Currently in our system, we adopted the "Join"
> header (RFC3911). When A sends the re-Invite to B, it also includes a Join
> header contains the C's dialog info. The B2B server will translate the Join
> to a centralized conference. It will Invite C with a Replace header to

[Peili] Solution 2 is interesting, but as my interpretation of
RFC3911, it seems join header should only be added in a new INVITE. I
copy the text here "The UAC places the Call-ID, to-tag, and from-tag
information for the target dialog in a single Join  header field and
sends the new INVITE to the target."

> replace the session between A and C. C will sends a BYE to A. The server
> will update the media to A and B (reInvite). Then all three parties are in
> the centralized conference room.
> I hope the new RFC for conference also capture the behavior described in 2.
> Whether it's Join header or something else. The user should be able to call
> someone first and then decided to setup a conference.Jerry
>

---

From: Alan Johnston <[email-masked]>
Date: Wed, 12 Sep 2007 09:48:46 -0500

Hi Jerry,

The use of a Join header field in a re-INVITE in your system is 
problematic.  RFC 3911 does not seem to specifically rule it out but 
implies that it can only be used in a initial (dialog creating) INVITE.  
Also, the error response generation described in RFC 3911 can not be 
applied to a re-INVITE scenario, so I'm curious what you do if the Join 
does not match an existing one.

There are solutions in RFC 4579 for transitioning conferences to and 
from point to point sessions that may be of use to you.

Thanks,
Alan

Jerry Yin wrote:
> I think there are two ways to invoke a conference. One is to invoke 
> the conference by the conference server. The other is ad-hoc 
> conference invoked by the participants. The 
> draft-ietf-sip-uri-list-conferencing was trying to solve the problem 
> by initiating a conference from the server.
> Participants: A calls B (a UA or a conference room) and put B on-hold, 
> and then A calls C. Now A presses the conf button.
> 1. If B has a conference room url, A will transfer C to B (by REFER), 
> as some of you discussed already. It actually is supported by some 
> companies already as I know.
> 2. But if B is a UA, when the conf button is pressed, the only SIP 
> messages send out by A is the re-Invite (off-hold) to B since most SIP 
> phones support 3-way conference locally. Then A will do the audio 
> mixing locally. So far I didn't find any solution to transfer the 
> local 3-way conference to a centralized conference yet. Currently in 
> our system, we adopted the "Join" header (RFC3911). When A sends the 
> re-Invite to B, it also includes a Join header contains the C's dialog 
> info. The B2B server will translate the Join to a centralized 
> conference. It will Invite C with a Replace header to replace the 
> session between A and C. C will sends a BYE to A. The server will 
> update the media to A and B (reInvite). Then all three parties are in 
> I hope the new RFC for conference also capture the behavior described 
> in 2. Whether it's Join header or something else. The user should be 
> able to call someone first and then decided to setup a conference.
> Jerry
>
> */Jeroen van Bemmel <[email-masked]>/* wrote:
>
> ------------------------------------------------------------------------
> Check out 
> <http://us.rd.yahoo.com/evt=51201/*http://autos.yahoo.com/new_cars.html;_ylc=X3oDMTE5NWVzZGVyBF9TAzk3MTA3MDc2BHNlYwNtYWlsdGFncwRzbGsDYXV0b3MtbmV3Y2Fy> 
> the hottest 2008 models today at Yahoo! Autos.
> ------------------------------------------------------------------------
>

---

From: Jerry Yin <[email-masked]>
Date: Wed, 12 Sep 2007 13:13:45 -0700 (PDT)

Hi Alan and Peili,
   
  Thanks for your responses. I saw Alan's RFC before. I revisited it today briefly. But I still can't find the solution I am looking for. Basically in your RFC, even for the ad-hoc conference, the user always starts with calling the conference server first. What I am looking for is that the user puts two (or more) lines on hold, then he decides to conference them together in a conference room.
   
  The solution I proposed will allow user to have a smooth experience to conduct a conference in a conference room, if the server supports this feature. If server does not support it then it will be a local 3way conference on the phone that most SIP phones support. The UI design and user experience will be exactly the same in both the cases.
   
  As to the RFC3911, I agree that it didn't say explicitly that the Join header can be used in a re-Invite. I also admit that my proposal does not interpret the Join header as the RFC defines. But if it works, then we might want to re-interpret the defintion of Join header? Or we might want to consider introducing a new header for this purpose!
   
  To answer your question, if the join does not match an existing dialog, then according to the RFC 3911, it will be ignored. 
   
  BTW, I saw the RFC 4579 depends on out-dialog REFER. Would it be a security concern?
   
  thanks,
  Jerry

Alan Johnston <[email-masked]> wrote:
  Hi Jerry,

Thanks,
Alan

Jerry Yin wrote:
> */Jeroen van Bemmel /* wrote:
>

---------------------------------
Be a better Globetrotter. Get better travel answers from someone who knows.
Yahoo! Answers - Check it out.

---

From: "Huelsemann, Martin" <[email-masked]>
Date: Thu, 13 Sep 2007 14:41:45 +0200

Hi all,
 
thanks for your interest in this, but I think my question pointed in a littlebit different direction.
 
I think the procedures to start a centralized ad-hoc dial-out conference are fine, you send an INVITE to the conference factory to start the conference, and then you send REFERS to the focus referring INVITEs to the other participants. Even better is an INVITE to the confernce with a URI list of the participants who shall be invited to the conference, because this needs lees messages.
 
The problem is the INVITE from the focus to the participants. As this is an ad-hoc conference, it's clear that the invited user is already in a dialog with the inviting user, and because of this it depends on the invited user if he accepts the invitation to the conference, or if he e.g. just answers with a 486. The proposal is to trigger a re-INVITE in the original dialog by using the "?" mechanism to transfer the dialog ID of the original dialog to the focus, as this wouldn't cause a 2nd dialog at the invited UE and therefore means the fewest requirements on the invited user.
 
To mee it seems that the Join header cannot solve this problem. If you include the Join header in the INVITE to the focus, that means you want to join some dialog at the focus which doesn't exist. 
If you include the Join header also using "?" in the header portion in the Refer-to header of a REFER or in the header protions in the URI list, this means the focus shall generate an INVITE including a Join header and sends this to the invited user. The invited user then would have to start the procedures to include the focus in the original dialog. If he accepts the 2nd INVITE and is compatible to RFC3911.
Triggering a re-INVITE because of the Join header part in the Refer-to header to me seems to be not in accordance with RFC3911.
Because of this I don't think the usage of the Join header can solve the problem of 2 dialogs at the invited user in case of an ad-hoc dial-out conference.
 
BR, Martin

-----Ursprüngliche Nachricht-----
Von: Jerry Yin [mailto:[email-masked]] 
Gesendet: Mittwoch, 12. September 2007 22:14
An: Alan Johnston
Cc: [email-masked]; DRAGE, Keith (Keith); Mary Barnes
Betreff: Re: AW: AW: [Sip] Extension of conference procedures

Hi Alan and Peili,

 

 
thanks,
Jerry

Hi Jerry,

Thanks,
Alan

> > Note: I snipped the rest of this thread as it was getting really

  _____  

Be a better Globetrotter. Get  <http://us.rd.yahoo.com/evt=48254/*http://answers.yahoo.com/dir/_ylc=X3oDMTI5MGx2aThyBF9TAzIxMTU1MDAzNTIEX3MDMzk2NTQ1MTAzBHNlYwNCQUJwaWxsYXJfTklfMzYwBHNsawNQcm9kdWN0X3F1ZXN0aW9uX3BhZ2U-?link=list&sid=396545469> better travel answers from someone who knows.
Yahoo! Answers - Check it out.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 13 Sep 2007 10:00:27 -0400

Why not simply REFER the focus to send an INVITE/Replaces to the calls 
with existing dialogs?

	Paul

Huelsemann, Martin wrote:
> I think the procedures to start a centralized ad-hoc dial-out conference 
> are fine, you send an INVITE to the conference factory to start the 
> conference, and then you send REFERS to the focus referring INVITEs to 
> the other participants. Even better is an INVITE to the confernce with a 
> URI list of the participants who shall be invited to the conference, 
> because this needs lees messages.
>  
> The problem is the INVITE from the focus to the participants. As this is 
> an ad-hoc conference, it's clear that the invited user is already in a 
> dialog with the inviting user, and because of this it depends on the 
> invited user if he accepts the invitation to the conference, or if he 
> e.g. just answers with a 486. The proposal is to trigger a re-INVITE in 
> the original dialog by using the "?" mechanism to transfer the dialog ID 
> of the original dialog to the focus, as this wouldn't cause a 2nd dialog 
> at the invited UE and therefore means the fewest requirements on the 
> invited user.

> To mee it seems that the Join header cannot solve this problem. If you 
> include the Join header in the INVITE to the focus, that means you want 
> to join some dialog at the focus which doesn't exist.
> If you include the Join header also using "?" in the header portion in 
> the Refer-to header of a REFER or in the header protions in the URI 
> list, this means the focus shall generate an INVITE including a Join 
> header and sends this to the invited user. The invited user then would 
> have to start the procedures to include the focus in the original 
> dialog. If he accepts the 2nd INVITE and is compatible to RFC3911.
> Triggering a re-INVITE because of the Join header part in the Refer-to 
> header to me seems to be not in accordance with RFC3911.
> Because of this I don't think the usage of the Join header can solve the 
> problem of 2 dialogs at the invited user in case of an ad-hoc dial-out 
> conference.
>  
> BR, Martin
>  
>  
>  
> 
>     *Von:* Jerry Yin [mailto:[email-masked]]
>     *Gesendet:* Mittwoch, 12. September 2007 22:14
>     *An:* Alan Johnston
>     *Cc:* [email-masked]; DRAGE, Keith (Keith); Mary Barnes
>     *Betreff:* Re: AW: AW: [Sip] Extension of conference procedures
> 
>     Hi Alan and Peili,
>      
>     Thanks for your responses. I saw Alan's RFC before. I revisited it
>     today briefly. But I still can't find the solution I am looking for.
>     Basically in your RFC, even for the ad-hoc conference, the user
>     always starts with calling the conference server first. What I am
>     looking for is that the user puts two (or more) lines on hold, then
>     he decides to conference them together in a conference room.
>      
>     The solution I proposed will allow user to have a smooth experience
>     to conduct a conference in a conference room, if the server supports
>     this feature. If server does not support it then it will be a local
>     3way conference on the phone that most SIP phones support. The UI
>     design and user experience will be exactly the same in both the cases.
>      
>     As to the RFC3911, I agree that it didn't say explicitly that the
>     Join header can be used in a re-Invite. I also admit that my
>     proposal does not interpret the Join header as the RFC defines. But
>     if it works, then we might want to re-interpret the defintion of
>     Join header? Or we might want to consider introducing a new header
>     for this purpose!
>      
>     To answer your question, if the join does not match an existing
>     dialog, then according to the RFC 3911, it will be ignored.
>      
>     */Alan Johnston <[email-masked]>/* wrote:
> 
>         Hi Jerry,
> 
>          > > History-Info header. My understanding is that it's really
>         just a
>          > nifty
>          > > Yes, It's vague in RFC3261. I'm only aware of the usage in
>         REFER
>          > now.
>          > > Note: I snipped the rest of this thread as it was getting
>         really
>          > LONG.
>          > >
>          > >
>     Be a better Globetrotter. Get better travel answers
>     <http://us.rd.yahoo.com/evt=48254/*http://answers.yahoo.com/dir/_ylc=X3oDMTI5MGx2aThyBF9TAzIxMTU1MDAzNTIEX3MDMzk2NTQ1MTAzBHNlYwNCQUJwaWxsYXJfTklfMzYwBHNsawNQcm9kdWN0X3F1ZXN0aW9uX3BhZ2U-?link=list&sid=396545469>from
>     someone who knows.

---

From: "Huelsemann, Martin" <[email-masked]>
Date: Thu, 13 Sep 2007 17:08:52 +0200

Yes, that is of course the prefered solution and this are the normal procedure how this ad-hoc conference will be activated.. 
But like in the other thread we discuss in also here is the problem with a dumb phone, in the worst case only compliant to RFC 3261 and only able to handle 1 dialog at the same time. And for this our proposal is, to develop a fallback basing on sending a re-INVITE in the original dialog. That minimizes the requirements on the invited user and maximizes the chance the conference will be established.
Of course the normal case is that there are smart phones compliant to all RFCs needed for the service. But I think it's useful to have at least a fallback for the case that B does not fulfil all the requirements needed for a service you're providing to A. Or simply doesn't want to accept a 2nd INVITE.

BR, Martin

> Von: Paul Kyzivat [mailto:[email-masked]] 
> Gesendet: Donnerstag, 13. September 2007 16:00
> An: Hülsemann, Martin
> Cc: [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Betreff: Re: AW: AW: AW: [Sip] Extension of conference procedures
> 
> 
> > thanks for your interest in this, but I think my question 
> pointed in a 
> > littlebit different direction.
> >  
> >     BTW, I saw the RFC 4579 depends on out-dialog REFER. 
> Would it be a
> >     security concern?
> >      
> >     thanks,
> >     Jerry
> > 
> > 
> >         implies that it can only be used in a initial 
> (dialog creating)
> >         INVITE.
> >         Also, the error response generation described in 
> RFC 3911 can
> >         not be
> >         applied to a re-INVITE scenario, so I'm curious 
> what you do if
> >         the Join
> >         There are solutions in RFC 4579 for transitioning 
> conferences to
> >         and
> >          > I think there are two ways to invoke a 
> conference. One is to
> >         invoke
> >          > draft-ietf-sip-uri-list-conferencing was trying 
> to solve the
> >         problem
> >          > Participants: A calls B (a UA or a conference 
> room) and put B
> >         on-hold,
> >          > 1. If B has a conference room url, A will 
> transfer C to B (by
> >         REFER),
> >          > as some of you discussed already. It actually is 
> supported by
> >         some
> >          > messages send out by A is the re-Invite 
> (off-hold) to B since
> >         most SIP
> >          > phones support 3-way conference locally. Then A 
> will do the
> >         audio
> >          > mixing locally. So far I didn't find any 
> solution to transfer
> >         the
> >          > our system, we adopted the "Join" header 
> (RFC3911). When A
> >         sends the
> >          > re-Invite to B, it also includes a Join header 
> contains the
> >         C's dialog
> >          > conference. It will Invite C with a Replace 
> header to replace
> >         the
> >          > session between A and C. C will sends a BYE to 
> A. The server
> >         will
> >          > I hope the new RFC for conference also capture 
> the behavior
> >         described
> >          > in 2. Whether it's Join header or something 
> else. The user
> >         should be
> &To=sip:[email-masked];tag=y&Call-ID=i&CSeq=1234&Route=rrr&body=
> >          > RFC3261 provides some guidance on the types of 
> headers that
> >         elements
> >          > "An implementation SHOULD NOT honor these 
> obviously dangerous
> >         header
> >          > I believe the usage that was foreseen for this 
> mechanism (as
> >          > illustrated
> >          > by some of the examples in RFC3261) was to 
> provide some context
> >          > for the
> >          > request, such as Subject and Priority fields. In 
> other words,
> >          > optional
> >          > The above are not different semantics for 
> headers in a URI
> >         (concept
> >          > remains: form a new request based on the URI, 
> inserting the
> >         headers),
> >          > but it does imply a deviation from the basic SIP 
> call model
> >          > (basically a
> >          > way of encoding dialog state in a SIP URI, and 
> sending that to
> >          > another
> >          > element such that it can reconstruct that state 
> and assume the
> >          > role of
> >          > Apart from the fact that this approach will fall 
> short for SDP
> >          > related
> >          > > RFC 4244 (History-Info) also uses this 
> mechanism to capture the
> >          > Reason
> >          > > and Privacy associated with the URIs that are 
> included as part
> >          > of the
> >          > > way to compactly reuse existing headers (i.e., 
> it makes the
> >          > History-Info
> >          > > the header, but could rather reuse the 
> existing ones, whose
> >         existing
> >          > > semantics perfectly applicable). I do think 
> that the use of the
> >          > headers
> >          > > particularly in cases where you might be 
> extending the use of
> >          > existing
> >          > >> So this is a convenient way to bring us back 
> to the other half
> >          > of the
> >          > >>
> >          > > issue which we do not seem to have discussed 
> yet. When the
> >          > syntax was
> SIP Protocol
> questions on current sip
> >          > Use [email-masked] for new developments on the 
> application
> >         of sip
> >          >
> >          >
> >          >
> >         
> questions on current sip
> >          > Use [email-masked] for new developments on the 
> application
> >         of sip
> > 
> > 
> >     
> <http://us.rd.yahoo.com/evt=48254/*http://answers.yahoo.com/di
> r/_ylc=X3oDMTI5MGx2aThyBF9TAzIxMTU1MDAzNTIEX3MDMzk2NTQ1MTAzBHN
> lYwNCQUJwaWxsYXJfTklfMzYwBHNsawNQcm9kdWN0X3F1ZXN0aW9uX3BhZ2U-?
> link=list&sid=396545469>from
> >     someone who knows.

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Mon, 24 Sep 2007 10:35:44 +0200

It looks to me like we could usefully have some informational text
drafted on the usage of "?", i.e. what it can be used for and what it
cannot.

Further, can any implementation use it, or does it need specification 

Any volunteers.

Regards

Keith 

> From: Dean Willis [mailto:[email-masked]] 
> Sent: Thursday, September 06, 2007 1:20 AM
> To: DRAGE, Keith (Keith)
> Cc: Huelsemann, Martin; [email-masked]; [email-masked]
> I believe we were confused about the differences between 
> headers and URI parameters and didn't quite get the "?" 
> notation used with HTTP cgi-bin.
> 
> But that's just where it started. "?" notation has since been 
> fairly widely used as a way to "flatten" elements of a SIP 
> request for expression on a single (if somewhat long) line, 
> which has been shown to be somewhat useful in both REFER and 
> in retargeting proxies that allow one-line configuration of a 
> target URL.
> 
> 
> --
> Dean
> 
>

---

From: Adam Roach <[email-masked]>
Date: Mon, 24 Sep 2007 10:05:55 -0500

> URI parameters and didn't quite get the "?" notation used with HTTP 

I'm not certain there was any actual confusion here when we settled on 
that syntax originally. RFC 2396 (which was current at the time, 
although it has been superseded by RFC 3986) describes this portion of a 
URI as nothing more than: "The query component is a string of 
information to be interpreted by the resource." I think SIP's use is 
consistent with that.

Additionally, RFC 2368 gives clear and strong precedent for precisely 
this interpretation of the query component of URIs.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 24 Sep 2007 12:38:23 -0400

Adam,

I agree with you that the interpretation as sip headers is clear.

What is not so clear is which sip headers should be honored in which 
contexts of use for the URL. Most of the uses (with the exception of 
H-I) will not work unless the recipient actually incorporates certain of 
the headers into the resulting request. But the UA is given a lot of 
discretion regarding inclusion of headers and is warned that some are 
dangerous. AFAIK there is no requirement that certain headers be 
honored, in general or in conjunction with support of particular options.

	Thanks,
	Paul