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:[EMAIL PROTECTED] > Gesendet: Mittwoch, 5. September 2007 21:39 > An: Mary Barnes > Cc: [email protected]; DRAGE, Keith (Keith) > Betreff: Re: ?headers ( was RE: AW: AW: [Sip] Extension of > conferenceprocedures > > > Concretely, would we be looking at something like > > sip:[EMAIL PROTECTED]@provider.com;tag=x > &To=sip:[EMAIL PROTECTED];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:[EMAIL PROTECTED] > > Sent: Wednesday, September 05, 2007 10:41 AM > > To: DRAGE, Keith (Keith) > > Cc: [email protected] > > 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) <[EMAIL PROTECTED]>: > > > >> 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 [EMAIL PROTECTED] for questions on current sip > > Use [EMAIL PROTECTED] 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 [EMAIL PROTECTED] for questions on current sip > Use [EMAIL PROTECTED] 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 [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
