List Info

Thread: Re: AW: AW: Extension of conference procedures
Re: AW: AW: Extension of conference procedures
country flaguser name
United States		 2007-09-12 09:48:46 
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 <jbemmelzonnet.nl>/* 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 
> <http://us.rd.yahoo.c
om/evt=51201/*http://autos.yahoo.com/new_cars.html;_ylc=X3oD
MTE5NWVzZGVyBF9TAzk3MTA3MDc2BHNlYwNtYWlsdGFncwRzbGsDYXV0b3Mt
bmV3Y2Fy> 
> 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



_______________________________________________
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
Re: AW: AW: Extension of conference procedures
country flaguser name
Canada		 2007-09-12 15:13:45 

  


  

      
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


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



  

  
  
   
     
    






 [1-2]











   
 





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