I'm not certain I understand the point you are making.
Is it that we don't need info events because we could accomplish the
same thing using subscriptions to suitable event packages?
If that is your point, we have been down that path already. Many of us
have taken that position in the past (and may still believe it today),
but there were many arguments that that approach is to heavy weight.
Evidence of that is the continued use of info for DTMF even though we
have an event package for that.
Paul
Nasir Khan wrote:
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] <mailto:[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. <http://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]
<mailto:[EMAIL PROTECTED]> for questions on current sip
Use [EMAIL PROTECTED] <mailto:[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
_______________________________________________
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
