List Info

Thread: Re: ?headers ( was RE: AW: AW: Extension of conference procedures
Re: ?headers ( was RE: AW: AW: Extension of conference procedures
country flaguser name
Netherlands		 2007-09-05 14:38:39 
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=<SDP 
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) <dragealcatel-lucent.com>:
>   
>> 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
RE: AW: AW: Extension of conference procedures
country flaguser name
Canada		 2007-09-11 17:11:54 

  


  

      
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&gt; 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>

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
&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. 
>
> 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) ALCATEL-LUCENT.COM>:
> 
>> 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
>&gt; encoded in ampersand separated hname = hvalue pairs. The
>&gt; special hname "body" indicates that the associated hvalue is
>>; the message-body of the SIP request.
&gt;>
>;> 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?
>;>
>&gt; Regards
&gt;>
>> Keith
>>
>&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
>
&gt; 


_______________________________________________
Sip mailing list https://www1.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

2;
      
 Check out  the hottest 2008 models today at Yahoo! Autos.





  

  
  
   
     
    

  

    Re: AW: AW:  Extension of conference
procedures
  


  

     user name

     2007-09-12 09:14:52
  


  

    
Hi Jerry,

please see my comments in line.

2007/9/12, Jerry Yin <jerry.yinyahoo.com>:
>
> 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

[Peili] Solution 2 is interesting, but as my interpretation
of
RFC3911, it seems join header should only be added in a new
INVITE. I
copy the text here "The UAC places the Call-ID, to-tag,
and from-tag
information for the target dialog in a single Join  header
field and
sends the new INVITE to the target."

> 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
>


_______________________________________________
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-3]











   
 





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