Multiple packages per INFO can trivially be supported by defining a
Content-Type parameter to indicate the INFO event package being used,
instead of the "Info-Package" header
So:
INFO sip:foo at bar.com
To:...
From:...
Content-Type:multipart/mixed
Content-Length:...
--boundary
Content-Type: application/foo-data;info-package=foo
foo data
--boundary
Content-ID: abcdefg
Content-Type: application/some-header-data
some other (non-info package) data
--boundary--
I believe this models things better, as the INFO event package being
used is really just an attribute of the Content-Type to help
interpretation of the contents, just like Content-Type helps interpret
the format
Regards,
Jeroen
Elwell, John wrote:
I agree with Paul and Christer concerning multiple packages per dialog.
It seems a very reasonable thing to do and doesn't cost anything in
complexity.
John
-----Original Message-----
From: Paul Kyzivat [mailto:pkyzivat at cisco.com]
Sent: 23 October 2008 13:13
To: Christer Holmberg
Cc: DRAGE, Keith (Keith); Elwell, John; Dean Willis; SIP
IETF; Eric Burger
Subject: Re: [Sip] draft-ietf-sip-info-events-00: multiple
packages per INFO
I also agree it is too extreme to restrict to one package per dialog.
But as I stated earlier, I'm fine not defining multiple
packages per INFO.
Paul
Christer Holmberg wrote:
Hi,
I don't have a problem agreeing with that.
Note that buried somewhere in this thread was a question
of whether we
had a use case for multiple packages per dialog, or can we
simplify even
further.
I don't think we should go that far, because that could become very
restrictive.
For example, assume I want to use INFO packages e.g. for
DTMF during the
call setup, and then other INFO package(s) for something
else during the
call.
Regards,
Christer
-----Original Message-----
From: Christer Holmberg [mailto:christer.holmberg at ericsson.com]
Sent: Thursday, October 23, 2008 10:51 AM
To: Elwell, John; Dean Willis; DRAGE, Keith (Keith)
Cc: SIP IETF; Eric Burger; Paul Kyzivat
Subject: RE: [Sip] draft-ietf-sip-info-events-00: multiple
packages
per INFO
Hi,
I agree with John. Let's keep it simple. If allowing
multiple packages
in a single INFO causes issues, let's forget about it.
The whole idea with this is to allow people using INFO to
do so in an
easy and standardized way, so let's not shoot ourselves in
the foot
with complexity.
Regards,
Christer
-----Original Message-----
From: Elwell, John [mailto:john.elwell at siemens.com]
Sent: 23. lokakuuta 2008 12:30
To: Christer Holmberg; Dean Willis; DRAGE, Keith (Keith)
Cc: SIP IETF; Eric Burger; Paul Kyzivat
Subject: RE: [Sip] draft-ietf-sip-info-events-00: multiple
packages
per INFO
In reply to this whole thread, please bear in mind that we
had lots of
discussion about whether it would be worthwhile defining
this new INFO
mechanism, since existing applications are unlikely to
change and the
best we can hope for is that new applications will exploit the new
mechanism. Therefore we want to keep the mechanism as simple as
possible. The complexities of matching body parts to
header fields,
dealing with cases where only some of the packages are understood,
etc.
are hardly likely to persuade people to implement the mechanism.
Please keep it simple.
John
-----Original Message-----
From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On
Behalf Of
Christer Holmberg
Sent: 23 October 2008 08:17
To: Dean Willis; DRAGE, Keith (Keith)
Cc: SIP IETF; Eric Burger; Paul Kyzivat
Subject: Re: [Sip] draft-ietf-sip-info-events-00:
multiple packages
per INFO
Hi,
Why does putting two different packages in the same INFO
work better
than two different INFO messages each with their own
package usage? Is
there a desirable relationship that can be implemented
between the two
that we would otherwise lose?
We have one package per NOTIFY. Let's stick with one package
per INFO,
unless we want to go back to using mime-types as the only
distinguisher of packages.
I raised that issue in another e-mail.
But, never the less, I have no strong feelings on the
single versus
multiple package issue.
Regards,
Christer
_______________________________________________
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
|