Subject: [Sip] INFO usage (or not)

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 13 Jun 2007 08:28:53 -0500

(As WG chair)

We have got a number of threads floating round on INFO usage, and it
would be nice to identify this into a potential body of work, and see if
there is support for it.

We have two previous drafts that never went anywhere, although contents
of both carried support in the WG at the time:

http://tools.ietf.org/html/draft-rosenberg-sip-info-harmful-00

   The Session Initiation Protocol (SIP) INFO method defines a means for
   transporting mid-dialog application layer data between user agents.
   Its initial use was to support the transport of ISUP mid-call
   messages which could not be mapped to any other SIP request method.
   However, since its initial usage for that purpose, INFO has seen
   widespread abuse as a means for introducing non-standard and
   non-interoperable extensions to SIP.  For this reason, we now believe
   INFO should be considered harmful, and therefore, deprecated in its
   current form.

http://tools.ietf.org/html/draft-willis-sip-infopackage-00

   The SIP INFO method (RFC 2976) establishes a method by which
   applications may transfer application-specific information within a
   SIP dialog.  However, RFC 2976 does not provide a mechanism for
   describing and documenting an application of INFO, nor does it
   provide a mechanism by which applications may negotiate such uses.
   This document provides a framework for documenting and naming
   specific uses of INFO (called INFO packages), for registering those
   package names with IANA, and for negotiating the support for various
   INFO packages between applications using SIP.

In the thread so far there have also been suggestions that cover:

-	support to mediactrl for their discussion on requirements
-	something for hitchhiker's guide to point to:
-	something that answers all the questions that recur on this list
on INFO usage
-	"I've been getting a lot of offline questions asking for the
"right" way to carry information related to the session-usage (often
information that's being tunneled around from companion or gatewayed
protocols)."
-	INVITE dialog usage only, or already covered by RFC 2976
-	It would be OK with me if we ALSO had this type of guidance
("don't look HERE, look over THERE") available ("stated strongly enough
in an easy to stumble across place"), but if coming up with that
guidance takes more than about a week, I don't see a lot of reason to
hold up on "don't go there" 
while we explore alternatives.
-	INFO and DTMF
-	XML payloads
-	But people really need is guidance on when to use INFO, when to
use events, and when to use something entirely different.
-	identification of purpose of info (Content-Type? - impacted by
multipart/mixed)
-	any framework for control of usages (IANA registration? - RFC
3427 update)

Would anybody out there like to have a go at drafting an abstract for a
potential WG deliverable (and also identifying level - Info, BCP,
standards track) and submitting it to the list for discussion. Remember
an abstract needs to:

------------------------------------------------------------------------
-------
Every RFC must have an Abstract section following the Copyright notice.
An Abstract will typically be 5-10 lines. An Abstract of more than 20
lines is generally not acceptable. 

The Abstract section should provide a concise and comprehensive overview
of the purpose and contents of the entire document, to give a
technically knowledgeable reader a general overview of the function of
the document. In addition to its function in the RFC itself, the
Abstract section text will appear in publication announcements and in
the online index of RFCs. 

Composing a useful Abstract generally requires thought and care. Usually
an Abstract should begin with a phrase like "This memo ..." or "This
document ...". A satisfactory abstract can often be constructed in part
from material within the Introduction section, but a good abstract will
be shorter, less detailed, and perhaps broader in scope than the
Introduction. Simply copying and pasting the first few paragraphs of the
Introduction is tempting, but it may result in an Abstract that is both
incomplete and redundant. Note also that an Abstract is not a substitute
for an Introduction; the RFC should be self-contained as if there were
no Abstract section. 

An Abstract should be complete in itself; it should not contain
citations unless they are completely defined within the Abstract.
Abbreviations appearing in the Abstract should generally be expanded in
parentheses. There is a small set of reasonable exceptions to this rule
(see guidelines on abbreviations, above.) 
------------------------------------------------------------------------
------

And as such should give a clear idea of whether there is anything we
should charter here or not.

Regards

Keith

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Eric Burger <[email-masked]>
Date: Sun, 17 Jun 2007 18:52:58 +0900

How about this:

This document describes why the Session Initiation Protocol (SIP) INFO
method, introduced in RFC 2976, has serious issues with any use outside its
use as a transport mechanism for ISDN User Part (ISUP) call signaling in
SIP-signaled networks.  In the years since the introduction of the INFO
method, the IETF has published numerous, interoperable extensions to SIP.
This document explains why there are INFO-based, proprietary protocols in
the wild; the flaws of using INFO; and prescriptions for how to use
existing, interoperable SIP mechanisms to accomplish most any of these
tasks.

My personal preference is for the document to be Standards Track and be a
Work Group chartered item.  The reason is that for this document to be
useful, it MUST update RFC 2976.  If it updates RFC 2976, then newbies get
the pointer when the download RFC 2976, pointing them to this document,
before they go off, create draft-mumble-foo-over-INFO, and get flamed on the
list.  The essence of the normative content of the document is, "one MUST
NOT use INFO for anything other than transporting ISUP or QSIG messages."

Because the normative content is so thin, I could understand not saying that
and making the document Informational (or BCP).  However, I really and truly
believe that will significantly reduce the impact the document will have.

Outline:
Introduction
- Requirements for UA-to-UA signaling
- The INFO method
- The INFO method for ISUP signaling
Issues with INFO
- No or incomplete negotiation
- No real identification of payload purpose on receipt
Alternatives to INFO
- State Updates: SUBSCRIBE / NOTIFY
- DTMF Transport: KPML (an example of state updates)
- Establishment of direct UA-to-UA signaling channel: MRCPv2, MSRP
- Prescriptions for deciding which method is appropriate under what
circumstances
Update to RFC 2976
- Limiting use of INFO to ISUP transport only
Security Considerations

> standards track) and submitting it to the list for discussion. Remember

Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.

---

From: "Jesske, R" <[email-masked]>
Date: Mon, 18 Jun 2007 11:01:29 +0200

Hi,
Why should be RFC's that are now 6 Years out in the world be restricted?
RFC 2976 clearly states for what INFO can be used.
I'm concerned about implementations that works with INFO regarding the rules defined within 2976.
Many implementations work based on that RFC. Like define a MIME, put it into INFO and it works.

I thought also that INFO was defined to put in some end to end information that shall be exchanged by UA's.
Why to restrict such a use in such a case?

If RFC 2976 will be changed is backward compatibility guaranteed?

Best Regards

Roland

> -----Ursprüngliche Nachricht-----
> Von: Eric Burger [mailto:[email-masked]] 
> Gesendet: Sonntag, 17. Juni 2007 11:53
> An: Keith Drage; IETF SIP List
> Betreff: Re: [Sip] INFO usage (or not)
> 
> 
> How about this:
> 
> Notice:  This email message, together with any attachments, 
> may contain information  of  BEA Systems,  Inc.,  its 
> subsidiaries  and  affiliated entities,  that may be 
> confidential,  proprietary,  copyrighted  and/or legally 
> privileged, and is intended solely for the use of the 
> individual or entity named in this message. If you are not 
> the intended recipient, and have received this message in 
> error, please immediately return this by email and then delete it.
> 
>

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Mon, 18 Jun 2007 11:19:55 +0200

Hi,

I am very concerned some some people use the word "newbies", and make it sound that people using INFO are beginners which have no clue about SIP.

Also, I have never heard about interoperability problems with INFO. One reason people are using INFO for certain things IS in order to interop with other implementations.

I am also confused that people seem to think that INFOs will start flying around for no reason, without the sender having any clue about whether the receiver will understand them or not. As we have discussed, there ARE mechanisms in SIP to negotiate what content types etc entities support. Yes, MAYBE we need to extend that (e.g. being able to indicate which methods can be used to carry a specific content type), if what we have is not enough. But, to me that is not the same thing has having "tons of problem".

Having said that, if there are issues with INFO, I have nothing against discussing them. But, if you are going to talk about alternative solutions, you also need to look at possible issues with those (having to set up multiple dialogs just in order to send some DTMFs associated with another dialog etc). 

We can sit in our <insert-your-favorite-Hilton-hotel> meeting rooms and write whatever you-must-to-this-and-you-must-not-do-that documents, but if we don't care about the feedback we get from the real world OUTSIDE the meeting room it won't help much. In the long run it will cause more harm than good.

Regards,

Christer

> -----Original Message-----
> From: Eric Burger [mailto:[email-masked]] 
> Sent: 17. kesäkuuta 2007 12:53
> To: Keith Drage; IETF SIP List
> Subject: Re: [Sip] INFO usage (or not)
> 
> How about this:
> 
> This document describes why the Session Initiation Protocol 
> (SIP) INFO method, introduced in RFC 2976, has serious issues 
> with any use outside its use as a transport mechanism for 
> ISDN User Part (ISUP) call signaling in SIP-signaled 
> networks.  In the years since the introduction of the INFO 
> This document explains why there are INFO-based, proprietary 
> protocols in the wild; the flaws of using INFO; and 
> prescriptions for how to use existing, interoperable SIP 
> mechanisms to accomplish most any of these tasks.
> 
> 
> My personal preference is for the document to be Standards 
> Track and be a Work Group chartered item.  The reason is that 
> for this document to be useful, it MUST update RFC 2976.  If 
> it updates RFC 2976, then newbies get the pointer when the 
> download RFC 2976, pointing them to this document, before 
> they go off, create draft-mumble-foo-over-INFO, and get 
> flamed on the list.  The essence of the normative content of 
> the document is, "one MUST NOT use INFO for anything other 
> than transporting ISUP or QSIG messages."
> 
> Because the normative content is so thin, I could understand 
> not saying that and making the document Informational (or 
> BCP).  However, I really and truly believe that will 
> significantly reduce the impact the document will have.
> 
> 
> Outline:
> Introduction
> - Prescriptions for deciding which method is appropriate 
> under what circumstances Update to RFC 2976
> - Limiting use of INFO to ISUP transport only Security Considerations
> 
> 
> 
> 
> 
> > would be nice to identify this into a potential body of 
> work, and see 
> > if there is support for it.
> > 
> > We have two previous drafts that never went anywhere, although 
> > contents of both carried support in the WG at the time:
> > 
> > - something that answers all the questions that recur on 
> this list on 
> > INFO usage
> > - "I've been getting a lot of offline questions asking for 
> the "right" 
> > way to carry information related to the session-usage (often 
> > - It would be OK with me if we ALSO had this type of 
> guidance ("don't 
> > look HERE, look over THERE") available ("stated strongly 
> enough in an 
> > easy to stumble across place"), but if coming up with that guidance 
> > takes more than about a week, I don't see a lot of reason 
> to hold up 
> > on "don't go there"
> > - But people really need is guidance on when to use INFO, 
> when to use 
> > events, and when to use something entirely different.
> > Would anybody out there like to have a go at drafting an 
> abstract for 
> > a potential WG deliverable (and also identifying level - Info, BCP, 
> > standards track) and submitting it to the list for discussion. 
> > Remember an abstract needs to:
> > 
> > 
> > The Abstract section should provide a concise and comprehensive 
> > overview of the purpose and contents of the entire 
> document, to give a 
> > Composing a useful Abstract generally requires thought and care. 
> > Usually an Abstract should begin with a phrase like "This 
> memo ..." or 
> > "This document ...". A satisfactory abstract can often be 
> constructed 
> > in part from material within the Introduction section, but a good 
> > abstract will be shorter, less detailed, and perhaps 
> broader in scope 
> > than the Introduction. Simply copying and pasting the first few 
> > paragraphs of the Introduction is tempting, but it may result in an 
> > Abstract that is both incomplete and redundant. Note also that an 
> > Abstract is not a substitute for an Introduction; the RFC should be 
> > self-contained as if there were no Abstract section.
> > 
> > Abbreviations appearing in the Abstract should generally be 
> expanded 
> > in parentheses. There is a small set of reasonable 
> exceptions to this 
> > rule (see guidelines on abbreviations, above.)
> > 
> > This list is for NEW development of the core SIP Protocol Use 
> > [email-masked] for questions on current sip Use 
> > [email-masked] for new developments on the application of sip
> 
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 18 Jun 2007 11:48:12 -0500

My preference would be to restrict the use of INFO to supporting
legacy PSTN protocols. We could even restrict it to the ones in 
RFC 3204.

In other words, let's just cap it.

And yes, I'd say Standards track that updates RFC 2976.

> Sent: Sunday, June 17, 2007 02:53

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 19 Jun 2007 19:34:17 -0400

inline.

Christer Holmberg (JO/LMF) wrote:

> I am also confused that people seem to think that INFOs will start
> flying around for no reason, without the sender having any clue about
> whether the receiver will understand them or not. As we have
> discussed, there ARE mechanisms in SIP to negotiate what content
> types etc entities support. Yes, MAYBE we need to extend that (e.g.
> being able to indicate which methods can be used to carry a specific
> content type), if what we have is not enough. But, to me that is not
> the same thing has having "tons of problem".

There is a big difference between, "I can support this format", and "I 
am interested in having you send me events in this format". This is why 
we didn't go with the INFO method for DTMF. Since DTMF would already be 
arriving at the UAS in the form of 2833, the primary entities needing 
signaling-based solutions are applications not on the media path. But, 
we only want to send such signaling when there is an application that is 
interested. This is exactly what SUB/NOT is for - to ask for 
notifications of events.

Furthermore, by using a separate dialog we could have the notifications 
sent just to the interested application server, so that the proxies on 
the path of the original dialog don't need to see INFO messages flying 
by if they weren't interested.

Consider further the other UA in the call. If it supports both 
DTMF-over-INFO and RFC2833, what does it mean to get both? If you 
generate DTMF on receipt of INFO, you stand a real risk of generating 
double DTMF which is very bad. You avoid this problem if you only send 
DTMF over signaling when asked; this way the thing getting the rfc2833 
doesn't ask for it.

Using SUB/NOT also allowed the application to customize when it would 
get a notification. So for example an app that needed each digit as it 
was pressed could get them immediately. One only needing them after some 
  pattern was matched could only get it then. This was also a perfect 
match for SUB/NOT.

So there are serious technical limitations to carrying DTMF over INFO. 
Sure, it can 'work', but it is very suboptimal and can cause problems.

As for a general INFO usage, my opinion is unchanged on this. We have 
numerous methods for extending SIP by adding new headers and methods and 
event packages. Can you demonstrate a use case where one of these 
extensibility mechanisms is not sufficient for some use case?

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Wed, 20 Jun 2007 21:33:40 +0200

Hi, 

>>flying around for no reason, without the sender having any 
>>clue about whether the receiver will understand them or not. As we
have 
>>discussed, there ARE mechanisms in SIP to negotiate what content types

>>etc entities support. Yes, MAYBE we need to extend that (e.g.
>>being able to indicate which methods can be used to carry a 
>>specific content type), if what we have is not enough. But, to me 
>>that is not the same thing has having "tons of problem".
> 
>There is a big difference between, "I can support this 
>format", and "I am interested in having you send me events in 
>this format". 

When you indicate the stuff you support in an OPTIONS response, I agree
it's "I can support this format".

But, if I in an INVITE response indicate support of a certain content
type I think that can also be seen as "When/if you are going to send me
X, please use this format".

>This is why we didn't go with the INFO method for DTMF. Since DTMF
would already be arriving at the UAS in 
>the form of 2833, the primary entities needing signaling-based
solutions are applications not on the media 
>path.

In most cases, yes, and my intention is not to promote people to use a
signaling-based solution instead of 2833. We could even make very strong
recommendations to always use 2833, when possible.

(However, in theory you could also have a signalling gateway, without
access to media, which sends the DTMFs using a signaling-based solution
since the protocol "on the other side" also does it.)

>But, we only want to send such signaling when there is an application
that is interested. This is exactly what 
>SUB/NOT is for - to ask for notifications of events.

The application may not necessarily know that I am going to send him
anything, and then it will have to ask "just in case".
 
>Furthermore, by using a separate dialog we could have the 
>notifications sent just to the interested application server, 
>so that the proxies on the path of the original dialog don't 
>need to see INFO messages flying by if they weren't interested.

That is an advantage, yes.

...eventhough I wonder how many proxies you actually would be able to
"skip" in real life scenarios. You may have routes established using
Path and/or Service-Route, for example.

>Consider further the other UA in the call. If it supports 
>both DTMF-over-INFO and RFC2833, what does it mean to get 
>both? If you generate DTMF on receipt of INFO, you stand a 
>real risk of generating double DTMF which is very bad.

You have exactly the same problem with SUB/NOT, if you BOTH subscribbe
to the DTMF event AND inciate support of 2833 in your SDP.

So, the solution is: you indicate EITHER support of 2833 OR the
signaling-based mechanism (whatever it is). 

>You avoid this problem if you only send DTMF over signaling when asked;
this way the thing getting the rfc2833 doesn't 
>ask for it.

I am not sure I understand that. Even if I use SUB/NOT I don't know
exactly when the DTMF event will come (if it will come), and I could
still also receive 2833 while the subscription is active.

>Using SUB/NOT also allowed the application to customize when it would
get a notification. So for example an app that 
>needed each digit as it was pressed could get them immediately. One
only needing them after some
match for SUB/NOT.

Well, obviously people using INFO do not need the subscriber to be able
to "push" the digitmap. But, if I am asked to give 4 digits I may
implement a user interface which allows me to enter the digits before
they are sent in a single INFO (assuming the INFO based mechanism allows
it).

>As for a general INFO usage, my opinion is unchanged on this. 
>We have numerous methods for extending SIP by adding new 
>headers and methods and event packages. Can you demonstrate a 
>use case where one of these extensibility mechanisms is not 
>sufficient for some use case?

>From a functional perspective I am pretty sure they are sufficient.

And, I am not saying that all INFO usages are good, and that you
couldn't use a better (both from a functionality and complexity
perspective) alternative.

Regards,

Christer