Maybe it warrants a separate thread but I would like to discuss section 7.1.3 of this draft where 3265 is talked about as an alternative. Since we are talking about the notion of well defined info packages and the INFO messages will carry information as a result of an event like an ISUP event or DTMF event (the name of the draft itself has "event" in it), then the two User Agents can very well subscribe to these events and use the notifications for the information exchange. This will automatically inherit all the good work done around notification framework and will lay to rest lot of questions and perhaps save some re-invention.
Regards Nasir On Mon, Oct 27, 2008 at 4:48 PM, Christer Holmberg < [EMAIL PROTECTED]> wrote: > > Hi, > > >>>My preference would be for a new value, say "package", "info", or > >>>"info-package". I think we *might* be able to define that "render" > >>>serves this purpose *for INFO messages*, but I would rather not do > >>>that because it is indeed asking from trouble and confusion. > >> > >>IF we define a new C-D value, which is unique for info packages, I > have no problem with a C-D based solution. > > > >OK. That is progress!!! > > > >>But, it would still be more work to define info packages, because you > >>would need to specify which C-T value to use. > > > >The document already calls for this: > > > > 7.2.4. INFO Bodies > > > > Each Info Package MUST define what type or types of bodies are > > expected in INFO requests. Such packages MUST specify or cite > > detailed specifications for the syntax and semantics associated > with > > such a body. > > > > Info Packages also MUST define a default MIME type if the "Accept" > > header fails to define any MIME types in the INVITE request. > > Yes, it's in the document. The point was that one may have to define > this new MIME type. But, maybe that is not a big problem (I haven't > defined mime types, so I can't tell). > > >The wording could be better. There are no explicit IANA considerations > about registering an INFO package. Its just implied here. Its a little > confusing here what is intended to be part of the > >*definition* of a new package vs. what is intended to be in the content > of a particular package instance in an INFO message. > > We do need to have a section on what needs to be part of an info package > definition. The mime type is one thing, for sure. > > I guess we should also look at what/if we can re-use from SIP events. > > We also need to decide whether info packages should have a version > number system. From experience I think that would be very useful. > > Info-Package: foo-package;version=1 > > ...or something like that. > > >>My issue is if we want to re-use an existing value, because I don't > think we for sure can say that couldn't be a case where more than one > >>body part has a "render" value (or whatever existing value we would > choose for info packages). > > > >This is all hypothetical, because we don't have any usages with the new > info package stuff. > > Exactly. > > >What I guess you are getting at is if there are any existing uses of > body parts with "render" that might have to coexist with the info > package in the message. > > Yes. > > >So I agree, we need a new value. > > Good :) > > Regards, > > Christer > > _______________________________________________ > Sip mailing list https://www.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 > -- Get the most comprehensive open source SIP testing framework at http://sipper.agnity.com
_______________________________________________ Sip mailing list https://www.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
