Subject: [Sipping] additional requirements for draft-culpepper-sipping-app-interact-reqs-01.txt

From: Eric Cheung <[email-masked]>
Date: Mon, 08 Jul 2002 10:49:14 -0400

Hi Bert, Robert

On reviewing this draft again, I noticed the following points that could
lead to additional requirements:

1) Modification of request for indications

It is implied, and certainly the 2 proposals in the WG provide the
capability of a network entity to modify its request for indications
multiple times in the lifetime of a SIP dialog.  However, it would be
nice to make this an explicit requirement, for example:

   "The mechanism must provide a means for a network entity to modify
its prior request to receive indications within a SIP dialog."

2) Removal of DTMF tone from media stream

For interoperability with legacy telephony services such as voice mail,
it is necessary for some network entity to preserve or to generate DTMF
tones and insert them into the media path.  However, for some other
services it is necessary to suppress such DTMF tones such that the
remote party does not hear them (for example, in network-based
Transfer-Connect service one party performs call transfer by pressing
*Txxx-xxx-xxxx.  The tones after *T must be suppressed.)

It is not clear from the requirement what the Reporter's behaviour
should be.  In the case where the Reporter has direct knowledge of the
keys and direct control over the media source (e.g. a SIP "hard" phone),
should the Reporter generate the tones and transmit them?  In the case
where the Reporter is in the media path detecting tones (e.g. a PSTN-SIP
gateway), should the Reporter suppress the tone in the audio stream?

It seems that a solution would be for the mechanism to allow the
Requestor to specify the behaviour.  Possible working for this
requirement may be:

   "For key-based indications, the mechanism must provide the ability
for the network element requesting the indications to also request that
the indications be suppressed from delivery to [all] other end points on
the media path."

3) Multiple Requestors and feature interaction

I know this is a complicated topic and there are a number of possible
solutions, including some that do not impose any requirements on the
protocol.  However, it seems it would be useful to add a notion of
priority or precedence to the request.  If multiple Requestors request
the same indications but with different priorities, then the Reporter
can identify the one Requestor with highest priority to send indications
to.  Possible wording for this may be:

    "To help manage feature interaction, the mechanism must also support
a means of prioritizing requests from multiple network entities within a
single SIP dialog."

I have not seen the agenda for the 54 IETF yet.  Is it your intention to
discuss this draft during the sipping sessions this time?

Regards
Eric Cheung

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

---

From: "Bert Culpepper" <[email-masked]>
Date: Tue, 9 Jul 2002 10:02:42 -0400

Hi Eric,

Thank you for the comments!  some comments below...

Eric Cheung wrote:
> its prior request to receive indications within a SIP dialog.

This seems fine to me.

> the indications be suppressed from delivery to [all] other

I've always assumed that the transport of DTMF will be indicated in SDP,
specifically using the RFC2833 encoding.  So in my mind, an endpoint can
control the sending of DTMF (when its transported using RFC2833).
However, when it's encoded along with the audio, I can see a problem for
devices that only have a display and a traditional phone-like keypad (no
GUI).  If they receive a request for user indications via their keypad
do they assume they shouldn't send DTMF when a key is pressed?  I doubt
it.

So it seems to me that something is needed for this as you describe
above.  But...

Providing a means to suppress DTMF delivery and/or user indications to
others doesn't seem like a good idea.  This also seems tied to 3 below.

> a means of prioritizing requests from multiple network

One obvious case in my mind where this is a problem is when two or more
entities use the same indication in their service.  Your requirement
above provides some means to manage this situation.  I've always thought
the industry would work this out by either informally standardizing on
what user indications invoke a specific service, or allowing a service
provider to provision the indication a service uses so that they
(service providers) can manage feature interaction within their
networks.

> discuss this draft during the sipping sessions this time?

I just finished a round of editing the I-D but didn't get it ready in
time for the upcoming meeting.  But I see we're not finished anyway :)
Neither Robert or I asked for meeting time, so I don't know that the
topic will be included in the SIPPING agenda.  I myself will not be
present in Yokohama.

However, I think some discussion of these points you raise are needed.
We need at least a "story" for 2 and 3 IMHO.  I look forward to
assistance on this.

Best regards,
Bert

---

From: Eric Cheung <[email-masked]>
Date: Thu, 25 Jul 2002 10:10:32 -0400

Hi Bert

Some more comments below:

> do they assume they shouldn't send DTMF when a key is pressed?  I doubt

I don't think whether the endpoint is sending DTMF encoded along with
the audio, or as RFC2833 payload, makes any difference here.  Since
RFC2833 requires that the telephone-event packets and the audio packets
are sent in the same stream, they can be considered just audio stream in
this discussion.

> others doesn't seem like a good idea.  This also seems tied to 3 below.

I think #2 and #3 should be considered separately.

There is an important difference between key presses that
correspond to DTMF set (i.e. 0-9, * #), and other user indications in
response to GUI.  The former, because of interoperability concern with
legacy services such as voice mail, must be present in the audio stream
(encoded with audio or RFC2833).  However, as pointed out in the
Transfer-Connect example, the application server may want to suppress
certain tones in the audio stream.  The other user indications do not
have this problem because in general they do not affect the audio or
other media streams.

#2 deals with the situation where one application server (the Requestor)
indicates to the media endpoint (the Reporter) that certain tones should
be suppressed in the audio stream.  Therefore, the Reporter does not
send the tones in audio stream to any of the other media endpoints to
whcih it is sending audio.

This is separate from #3 below, which concerns multiple Requestors, and
how the Reporter should send the indications to them.

> (service providers) can manage feature interaction within their

I do not agree that the feature interaction problem should/can be solved
by partitioning user indications amongst different services.  This is
because this is not always feasible or desirable.  For example, with
DTMF the set of input indications is too limited to be partitioned
across services.  Also there are cases where a common user input for
multiple services is desirable.  For example, if there are multiple
services that provide a "Help" recording it is desirable that the same
user input (maybe a Help button on user phone or DTMF #0) is used, and
the services figure out which one should respond to it.

If this partitioning of user indications does NOT solve feature
interaction, and multiple Requestors can request for indications within
the same SIP dialog, then it seems a priority type requirement like #3
is needed.

Thanks
Eric

---

From: Bert Culpepper <[email-masked]>
Date: Thu, 25 Jul 2002 13:39:26 -0400

Hi Eric,

see comments inline...

> are sent in the same stream, they can be considered just audio stream in

OK. No one else commented on my statement below so I'm happy adding the 
requirement.  I suspect it'll be easy enough to deal with scenarios (if 
any) that involve unknown network entities that utilize DTMF and users 
with relatively "dumb" terminals.

> how the Reporter should send the indications to them.

OK, I was concerned about services provided by hosts that use "DTMF" in 
an audio stream.  These would no longer be available to the user at the 
reporter while the service requesting DTMF removal from the stream is 
active.  But this may be mitigated with the reporter's ability to 
specify preferences and/or priorities.

> the services figure out which one should respond to it.

This last point should be possible with the addition of a requirement 
Jonathan original proposed that didn't make it into the version of the 
requirements I-D currently posted.  The requirement being "The mechanism 
should allow the user to know which application is associated with which 
user interface/input" (needs some wordsmithing).  Though the Reporter 
will need to convey the "app id" in its reports for these scenarios. 
But this point can wait until the mechanism definition occurs.

> the same SIP dialog, then it seems a priority type requirement like #3

I'll agree here, but I presume the priority a Requestor uses in its 
requests can be managed (an implementation detail).

You've convinced me :), I'll include these in the revision of the I-D.

Thanks,
Bert