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 PROTECTED]> wrote: Concretely, would we be looking
at something like
sip:[EMAIL PROTECTED]@provider.com;tag=x&To=sip:[EMAIL
PROTECTED];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:[EMAIL PROTECTED]
> Sent: Wednesday, September 05, 2007 10:41 AM
> To: DRAGE, Keith (Keith)
> Cc: [email protected]
> 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 [EMAIL PROTECTED] for questions on current sip
> Use [EMAIL PROTECTED] 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 PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] 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 [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
