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