Subject: [Sip] INFO, from a reformed Abuser

From: Eric Burger <[email-masked]>
Date: Sun, 17 Jun 2007 13:48:33 +0900

Who am I?  My name is Eric.  I have a problem.  I am on the road to
recovery...

Yes, I am responsible for RFC 4722, which, as a side effect, instructs
people on the THEN state-of-the-art (pre-SUB/NOT) of how to transport user
stimulus that HAPPENS to be key presses on a key pad using INFO messages.

As a side note, 90% of the time, we are really talking about real DTMF
detection, extracted from G.711, at a media server.

I am also responsible for RFC 4730, KPML, which instructs people on the
CURRENT state-of-the-art of how to transport user stimulus using SUBSCRIBE
and NOTIFY.

Note the key [sic] phrase: "transport user stimulus."

There were some suggestions to use RFC 2833 / 4733 to transport DTMF.  I
would offer, if your goal is to TRANSPORT IN-BAND TONES THAT HAPPEN TO BE
DTMF, your ONE and ONLY ONE option is RFC 4733.  You are *transporting*
media; use a media transport protocol.

If your goal is to TRANSPORT USER *SIGNALING*, your ONE and ONLY ONE option
is RFC 4730, KPML.  We have seen tons and tons of reasons why INFO is "bad."
I would offer that INFO is simply underspecified.  Namely, the remedy is to
fix the "why am I getting this message and what am I supposed to do with it"
question.  Event: and Content-Type: do this for NOTIFY.  A similar mechanism
could be done for INFO (note the deliberate use of passive voice).

Since we do not seem to have pressure to add those facilities to INFO, I
would offer we get on with life.

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 youFrom [email-masked] Mon Jun 18 02:36:56 2007
Date: Sun, 17 Jun 2007 13:48:33 +0900
From: Eric Burger <[email-masked]>
To: <[email-masked]>
Subject: [Sip] INFO, from a reformed Abuser

Who am I?  My name is Eric.  I have a problem.  I am on the road to
recovery...

Yes, I am responsible for RFC 4722, which, as a side effect, instructs
people on the THEN state-of-the-art (pre-SUB/NOT) of how to transport user
stimulus that HAPPENS to be key presses on a key pad using INFO messages.

As a side note, 90% of the time, we are really talking about real DTMF
detection, extracted from G.711, at a media server.

I am also responsible for RFC 4730, KPML, which instructs people on the
CURRENT state-of-the-art of how to transport user stimulus using SUBSCRIBE
and NOTIFY.

Note the key [sic] phrase: "transport user stimulus."

There were some suggestions to use RFC 2833 / 4733 to transport DTMF.  I
would offer, if your goal is to TRANSPORT IN-BAND TONES THAT HAPPEN TO BE
DTMF, your ONE and ONLY ONE option is RFC 4733.  You are *transporting*
media; use a media transport protocol.

If your goal is to TRANSPORT USER *SIGNALING*, your ONE and ONLY ONE option
is RFC 4730, KPML.  We have seen tons and tons of reasons why INFO is "bad."
I would offer that INFO is simply underspecified.  Namely, the remedy is to
fix the "why am I getting this message and what am I supposed to do with it"
question.  Event: and Content-Type: do this for NOTIFY.  A similar mechanism
could be done for INFO (note the deliberate use of passive voice).

Since we do not seem to have pressure to add those facilities to INFO, I
would offer we get on with life.

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.

_______________________________________________
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