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.
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
<http://us.rd.yahoo.com/evt=51201/*http://autos.yahoo.com/new_cars.html;_ylc=X3oDMTE5NWVzZGVyBF9TAzk3MTA3MDc2BHNlYwNtYWlsdGFncwRzbGsDYXV0b3MtbmV3Y2Fy>
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
_______________________________________________
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
