List Info

Thread: AW: AW: AW: Extension of conference procedures
AW: AW: AW: Extension of conference procedures
user name
 2007-09-13 07:41:45 

  


  

    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:jerry.yinyahoo.com] 
Gesendet: Mittwoch, 12. September 2007 
  22:14
An: Alan Johnston
Cc: sipietf.org; 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 <alansipstation.com> 
  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.
&gt; 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.
&gt; 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 ZONNET.NL>/* 
    wrote:
>;
> Concretely, would we be looking at something 
    like
>
> 
    sip:b-partyprovider.com?From=sip%3ca-partyprovider.com;tag=x&amp;To=sip:b-partyprovider.com;tag=y&amp;Call-ID=i&CSeq=1234&Route=rrr&body=
> 
    with proper session versions etc>
&gt;
> in order to help the 
    conference server fake a reINVITE towards B?
>
&gt; RFC3261 
    provides some guidance on the types of headers that elements
&gt; might 
    accept as part of a URI. Specifically, it states in 19.1.5:
&gt; "An 
    implementation SHOULD NOT honor these obviously dangerous header
>; 
    fields: From, Call-ID, CSeq, Via, and Record-Route."
>
&gt; I 
    believe the usage that was foreseen for this mechanism (as
> 
    illustrated
> by some of the examples in RFC3261) was to provide some 
    context
&gt; for the
> request, such as Subject and Priority 
    fields. In other words,
>; optional
&gt; information that might help 
    the receiver understand the context.
&gt;
> The above are not 
    different semantics for headers in a URI (concept
&gt; 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
&gt; element such that it can reconstruct that state and assume 
    the
> role of
> the party which shared the 
    state).
&gt;
> Apart from the fact that this approach will fall 
    short for SDP
> related
&gt; state: is this 
    desirable?
>
> Regards,
&gt; 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
&gt; > semantics perfectly 
    applicable). I do think that the use of the
> headers
&gt; > 
    that might be escaped using this mechanism should be explained,
> > 
    particularly in cases where you might be extending the use of
> 
    existing
&gt; > headers as I did for the Privacy header.
&gt; 
    >
> > Mary.
> >
> > -----Original 
    Message-----
> > From: Peili Xu [mailtoupeiligmail.com]
> 
    > Sent: Wednesday, September 05, 2007 10:41 AM
> > To: DRAGE, 
    Keith (Keith)
&gt; > Cc: sipietf.org
&gt; > 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
> >>
&gt; > 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.
> >>
&gt; >> Headers fields in the SIP request can 
    be specified with the
> >>
&gt; > "?"
> >
> 
    >> 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.
&gt; 
    >>
&gt; >> What usage did the SIP WG envisage for this, and 
    thus what
> semantics
> >>
&gt; > did they define 
    for that usage.
>; >
> >> Is it appropriate to assign 
    new semantics to such usage?
>; >>
&gt; >> 
    Regards
&gt; >>
&gt; >> Keith
> >>
&gt; 
    >>
&gt; > 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
&gt; > Use 
    sip-implementorscs.columbia.edu for questions on current sip
> > 
    Use sippingietf.org 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
&gt; Use 
    sip-implementorscs.columbia.edu for questions on current sip
> Use 
    sippingietf.org for new developments on the application of 
    sip
>
&gt;
> 
    ------------------------------------------------------------------------
>; 
    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
&gt; Use 
    sip-implementorscs.columbia.edu for questions on current sip
> Use 
    sippingietf.org for new developments on the application of 
  sip



  

  

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

  

  
  
   
     
    

  

    Re: AW: AW: AW:  Extension of conference
procedures
  


  

     country flaguser name
United States		
     2007-09-13 09:00:27
  


  

    
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:jerry.yinyahoo.com]
>     *Gesendet Mittwoch,
12. September 2007 22:14
>     *An Alan
Johnston
>     *Cc sipietf.org;
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 <alansipstation.com>/*
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:b-partyprovider.com?From=sip%3ca-partyprovider.com;tag=x&To=sip:b-partyprovider.com;tag=y&Call-ID=i&CSeq=1234&Ro
ute=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 [mailtoupeil
igmail.com]
>          > > Sent: Wednesday, September 05, 2007
10:41 AM
>          > > To: DRAGE, Keith (Keith)
>          > > Cc: sipietf.org
>          > > 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://ww
w1.ietf.org/mailman/listinfo/sip
>          > > This list is for NEW development of
the core SIP Protocol
>          > > Use sip-implementorscs.columbia.edu for questions on
>         current sip
>          > > Use sippingietf.org for new
developments on the
>         application of sip
>          > >
>          > >
>          >
>          >
>          >
_______________________________________________
>          > Sip mailing list https://ww
w1.ietf.org/mailman/listinfo/sip
>          > This list is for NEW development of the
core SIP Protocol
>          > Use sip-implementorscs.columbia.edu for questions on current sip
>          > Use sippingietf.org for new
developments on the application
>         of sip
>          >
>          >
>          >
>        
------------------------------------------------------------
------------
>          > Check out
>          >
>          > the hottest 2008 models today at Yahoo!
Autos.
>          >
>        
------------------------------------------------------------
------------
>          >
>          >
_______________________________________________
>          > Sip mailing list https://ww
w1.ietf.org/mailman/listinfo/sip
>          > This list is for NEW development of the
core SIP Protocol
>          > Use sip-implementorscs.columbia.edu for questions on current sip
>          > Use sippingietf.org 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=X3oD
MTI5MGx2aThyBF9TAzIxMTU1MDAzNTIEX3MDMzk2NTQ1MTAzBHNlYwNCQUJw
aWxsYXJfTklfMzYwBHNsawNQcm9kdWN0X3F1ZXN0aW9uX3BhZ2U-?link=li
st&sid=396545469>from
>     someone who knows.
>     Yahoo! Answers - Check it out. 
> 
> 
>
------------------------------------------------------------
------------
> 
> _______________________________________________
> Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP
Protocol
> Use sip-implementorscs.columbia.edu for
questions on current sip
> Use sippingietf.org for new developments on the
application of sip


_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip



  


  

    
  

  
  
   
     
    






 [1-2]











   
 





about | contact  Other archives ( Real Estate discussion Medical topics )