Dean Willis wrote:
On May 9, 2007, at 3:22 PM, Ted Hardie wrote:
At 2:40 PM -0500 5/9/07, James M. Polk wrote:
It's possible/probable/obvious (depending on who you talk to) that
multipart will have to be supported for emergency calling, in which
there is an SDP body and a Location message body...
This doesn't mean UAs that *don't* establish voice/video dialogs will
have to support multipart, just for those UAs that do establish
voice/video dialogs with emergency response centers (again, depending
on who you talk to).
That won't be multipart/alternative, though, as the location body and
the SDP body
won't be alternatives but independent items. I think they would be
multipart/mixed. See this from RFC 2046:
Right. Mixed is a far cleaner semantic problem than alternative. It
means "Use all of these that you understand, to the best of your
ability, and complain if there's nothing you understand."
IIUC you needn't complain if you don't understand any of the parts.
Rather, the handling parameter of the Content-Disposition header of each
part needs to be examined. For handling=optional the part can be ignored
if you don't understand it. For handling=required you need to complain
if you don't understand it.
So for example, you could have an INVITE that contains a multipart/mixed
where the parts are:
- a part with Content-Type:text/plain and
Content-Disposition:render;handling=optional.
- a part with Content-Type:image/gif and
Content-Dispostion:icon;handling=optional
This should be treated as an offerless INVITE even if neither subpart is
understood.
The case of location conveyance does present an interesting issue that I
have wondered about for some time and never found an answer to:
Suppose you are making a call, and for some reason think that providing
location information will be helpful. But it isn't critical that the
recipient understand it. So you send a request like:
INVITE sips:[EMAIL PROTECTED] SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9
Max-Forwards: 70
To: Bob <sips:[EMAIL PROTECTED]>
From: Alice <sips:[EMAIL PROTECTED]>;tag=9fxced76sl
Call-ID: [EMAIL PROTECTED]
Geolocation: <cid:[email protected]>
;inserted-by=endpoint
Supported: geolocation
Accept: application/sdp, application/pidf+xml
CSeq: 31862 INVITE
Contact: <sips:[EMAIL PROTECTED]>
Content-Type: multipart/mixed; boundary=boundary1
Content-Length: ...
--boundary1
Content-Type: application/sdp
...SDP here
--boundary1
Content-Type: application/pidf+xml
Content-ID: [EMAIL PROTECTED]
Content-Disposition:???;handling=optional
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:gs="urn:ietf:params:xml:ns:pidf:geopriv10:geoShape"
entity="pres:[EMAIL PROTECTED]">
<tuple id="sg89ae">
<timestamp>2007-03-20T14:00:00Z</timestamp>
<status>
<gp:geopriv>
...
</gp:geopriv>
</status>
</tuple>
</presence>
--boundary1--
You need the Content-Dispostion header so that you can insert the
handling=optional parameter. But what is the content-disposition value?
None of the currently defined values, such as "session", or "render"
seems appropriate.
In some sense its content-disposition is irrelevant because the
processing of the part is determined by the cid: reference in the
Geolocation header. But a UAS that doesn't understand the Geolocation
header won't know that.
We have some parts whose handling is governed by their type and
disposition, without need of explicit reference from another header. And
we have other parts that shouldn't be processed at all unless there is
an explicit reference to them elsewhere that has itself been understood.
IMO there needs to be a Content-Disposition that covers the latter case.
But that has never been recognized and specified.
This of course is a potential issue even if the body part is there by
itself, without an enclosing multipart.
Paul
_______________________________________________
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
