The extensibility model of SIP and SDP is very powerful in most ways.
It is often done by adding a new thing and if both sides understand
it, they use it, and if they don't understand it, they use the other
data in the messages that they both do understand and "fall back" to
the old behavior. We can do this for headers, URI, and other places
in SIP. We can do if for SDP attributes. However, there is one place
were SIP is very lacking in it's ability to be upgraded in the
future. This is around body extensibility.
The typical way to deal with extensibility of bodies is using MIME
multipart. This allows a SIP message to cary more than one body and
the receiver to select and use whichever ones it understands - This
is all defined for sip except for one problem. It was not mandatory
to implement and as you can see from the stats below, lots of UAs
don't implement it.
I believe that sooner or later we will have to do this - it's pretty
trivial to implement support for receiving multipart even if SDP is
the only thing your UA knows how to handle. Now we could argue about
if emergency calls were the thing that absolutely required us to do
this but my point is sooner or later we are going to need to deal
with this - it has come up many times in the past. I suspect it will
only get more difficult over time to make this change.
I think the WG should consider an update to 3261 (likely done through
the process Keith has proposed) that makes this multipart/MIME
mandatory to implement.
Cullen
On Apr 27, 2007, at 11:48 AM, Brian Rosen wrote:
I'd like to point out one thing about this:
This is how they answered for multipart/mime:
2% I break if someone sends me multipart/mime
24% I pretend multipart/mime doesn't exist if someone sends it
to me
24% I ignore multipart/mime but will proxy it or hand it to my
application if it shows up
10% I try to do something useful with multipart/mime I receive,
but I never send it
4% I ignore multipart/mime that I receive, but I try to do
something useful with multipart/mime I send
24% I try to do something useful with multipart/mime I send and
receive
12% Other
Moving forward, SIP UAs and proxies will be required to support
location-conveyance (currently draft-ietf-sip-location-
conveyance-07) in
order to support location for emergency calls (citizen to
authority, like
1-1-2 or
9-1-1). -conveyance requires multipart support.
The consequences of not supporting emergency call location will be
serious.
I believe it is likely that there will eventually be regulatory
requirements
to support emergency calls in some jurisdictions. Upgrades to several
components of today's infrastructure will be needed before this all
works,
but stack vendors and UA developers should put multipart (and
location-conveyance) on their development plans for next year at
the latest.
Brian
_______________________________________________
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
