[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sip] Multiple body-parts in one INFO



Hadriel Kaplan wrote:

-----Original Message-----
From: Christer Holmberg [mailto:christer.holmberg at ericsson.com]
Sent: Sunday, November 30, 2008 4:58 PM

Sounds ok.
But, doesn't the Info-Package header syntax still have to allow the
piggy-backer to:
1) List multiple info packages
2) For each listed info package, provide the cid


Nope.  We've already said we're going to not bother doing multiple packages. (or at least I think people have agreed with that, I hope)
So the next question was on multiple body-parts.  Since INVITE, UPDATE, PRACK, SUBSCRIBE/NOTIFY, MESSAGE, and legacy INFO, can all carry bodies and not one of them defined a CID mechanism for the body part that was specific to their message method context, we shouldn't need to for INFO either.
The problem is that none of them really considered the impact of multiple body parts, so it is anything but clear how an application is supposed to decipher one of these messages when it does contain multiple body parts. We are going to find that when combined with body parts for other purposes, implementations will do a variety of things. (That includes existing legal usages, such as body parts with C-D of "alert", which have been defined for a long time but never used.)
The body-handling draft tries to sort this out. But based on that we need to do better going forward than we did in the past.
Things were only "simple" in the past because we left things unspecified that needed to be specified.
You can have your "simple" solution here, analogous to the historic mechanism, by explicitly defining that body part(s?) with the content-disposition of "render" are to be considered to be the info-package payload. I say "render" because that is the *default* C-D, so it keeps things "simple" since it can be omitted. However you then should specify what happens if there are multiple body parts with C-D of "render". Also, you then need to specify whether a multipart body with a C-D of "render" should be viewed (in total) as the info-package payload, or whether some contained part of it should be the payload.
Personally, I would rather go with something less "simple" but more explicit here. Either a special C-D, or the CID reference. 

	Thanks,
	Paul


A "piggy-backer" is an extension to SIP that piggy-backs bodies onto any message method types.  Geolocation is an example of one.  Since it's the responsibility of the piggy-backer to handle identifying its specific body-part and dis-ambiguating it from the method's, we don't have to do anything.  In other words, Geolocation would already have to deal with current INFO message and body syntax.

For example, let's suppose someone creates an INFO package for sending virtual location information in a game, using a content-type of application/pidf+xml.  (whether they should have done it in SIP vs. the media layer is orthogonal)  And let's suppose for whatever reason the SIP stack always adds Geolocation information of the UA's physical location.
Here is what it would look like:

----BEGIN----
INFO sip:bob at example.com SIP/2.0
Call-ID: 6994090221306382483-1149617605 at 192.168.1.1
From: <sip:alice at example.com>;tag=27285
To: <sip:bob at example.com>;tag=GR52RWG346-34
CSeq: 2 INFO
Via: SIP/2.0/UDP 192.168.1.1:5060;branch=z9hG4bK-6110000000000893
Max-Forwards: 70
Info-Package: virtual-loc
Geolocation: <cid:whereami@invalid>
Content-Length: [whatever]
Content-Type: multipart/mixed;boundary="boundary1"

--boundary1
Content-Type: application/pidf+xml

[xml stuff goes here]
--boundary1
Content-Type: application/pidf+xml
Content-Disposition: by-reference
Content-ID: whereami at invalid

[xml stuff goes here]
--boundary1--
----END----
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip


_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip