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

[Paul Kyzivat <[e-mail]>]

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

	Paul


Huelsemann, Martin wrote:
> 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:[e-mail]]
>     *Gesendet:* Mittwoch, 12. September 2007 22:14
>     *An:* Alan Johnston
>     *Cc:* [e-mail]; 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.
>      
>     BTW, I saw the RFC 4579 depends on out-dialog REFER. Would it be a
>     security concern?
>      
>     thanks,
>     Jerry
> 
> 
>     */Alan Johnston <[e-mail]>/* wrote:
> 
>         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 /* 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
> 
> 
>     ------------------------------------------------------------------------
>     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.
>     Yahoo! Answers - Check it out. 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> 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