AW: ?headers ( was RE: AW: AW: [Sip] Extension of conferenceprocedures

["Huelsemann, Martin" <[e-mail]>]

Yes, that would be the way the reINVITE could look like. For the SDP I think a new offer from the focus is needed.

It's the question if this is desirable, but if it works and we can handle the security aspects, I think it's at least not completely undesirable as a fallback solution for a conference. Of course this should not be the normal way of activating the ad-hoc conference.

If we agree on the usage, where could this usage of the regarding headers be documented? Would it make necessary a new I-D? Or could this also be described in existing drafts related to this topic, e. g. draft-ietf-sip-uri-list-conferencing? 


BR, Martin




> -----Ursprüngliche Nachricht-----
> Von: Jeroen van Bemmel [mailto:[e-mail]] 
> Gesendet: Mittwoch, 5. September 2007 21:39
> An: Mary Barnes
> Cc: [e-mail]; DRAGE, Keith (Keith)
> Betreff: Re: ?headers ( was RE: AW: AW: [Sip] Extension of 
> conferenceprocedures
> 
> 
> 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=r
> rr&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 [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) <[e-mail]>:
> >   
> >> 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
> 


_______________________________________________
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