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

[Jerry Yin <[e-mail]>]

  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 <[e-mail]> wrote:  Concretely, would we be looking at something like

sip:[e-mail]?From=[e-mail];tag=x&To=sip:[e-mail];tag=y&Call-ID=i&CSeq=1234&Route=rrr&body=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:
> 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:[e-mail]] 
> Sent: Wednesday, September 05, 2007 10:41 AM
> To: DRAGE, Keith (Keith)
> Cc: [e-mail]
> Subject: Re: AW: AW: [Sip] Extension of conference procedures
>
> 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.
>
> 2007/9/5, DRAGE, Keith (Keith) :
> 
>> 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
>>
>> 
> Note: I snipped the rest of this thread as it was getting really LONG.
>
>
> _______________________________________________
> 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


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

_______________________________________________
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