Subject: RE: [Sipping] New Tones draft (was: "who plays the tone" or something like th...

From: "Eric Burger" <[email-masked]>
Date: Mon, 14 Jul 2003 11:09:43 -0400

Decay: suppose it could be negative (gets louder)

I think direction 1 (user agent to user) is the only sensible thing for this draft.  I guess that presupposes the whole idea is sensible in the first place Z-)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Mon, June 23, 2003 1:25 PM
To: [email-masked]; [email-masked]
Subject: Re: [Sipping] New Tones draft (was: "who plays the tone" or something like th...

In a message dated 6/23/2003 2:02:12 AM Eastern Standard Time, [email-masked] writes: 

wrote the following draft in order to provide some discussion on 
alternatives to in-band early-media ringback, and to discuss the issue 
of playing tones in general which I believe is inherently linked to 
3pcc and application interaction. 

Rohan, 

This seems to handle the general case of instructing a UA to generate a tone based on a specific set of characteristics (frequencies, levels, duration, decay, modulation, etc.) One of the immediate questions is what is the full set of possibilites required and what happens when someone wants a tone that is outside of that defined set? For example, you've shown examples of "decay", but what if the required tone starts low and gets louder? Luckily, no one has used a tone that varies in frequency over time. 

I didn't see anything in your write-up or in RFC 2833 about specifying which direction the UA should send the tone. There can be cases which the UA needs to be told: 

1. send the tone only to the user of that UA (e.g., Call Waiting) 
2. send the tone only to the other end (e.g., Audible Ringing) 
3. send the tone to both (e.g., Recorder Warning) 

Volume is defined with a range of -3 to -63 decibels. However, I believe that off-hook warning tone needs to be higher than -3 dB. Or maybe this function should be done in a different way, since the UA is presumed to have other alerting mechanisms (like ringing when already "off-hook"). 

This proposal would work, if every UA were required to support it. 

Mike Pierce 

_______________________________________________
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: "Eric Burger" <[email-masked]>
Date: Mon, 14 Jul 2003 14:46:21 -0400

Wouldn't the reverse direction just be another target for another tone?  For example, what if the indicator tone was different in different countries, per Q.35?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Mon, July 14, 2003 2:05 PM
To: Eric Burger; [email-masked]
Subject: Re: [Sipping] New Tones draft (was: "who plays the tone" or something like th...

In a message dated 7/14/2003 11:11:46 AM Eastern Daylight Time, [email-masked] writes: 

think direction 1 (user agent to user) is the only sensible thing for this draft.  I guess that presupposes the whole idea is sensible in the first place Z-) 

I believe that being able to tell the UA to send the tone in either direction or both is a basic requirement. If not included now, we'll be sorry later. I believe it is easy to find cases for the use of each. 

Mike Pierce

---

From: [email-masked]
Date: Mon, 14 Jul 2003 15:46:04 EDT

In a message dated 7/14/2003 2:48:07 PM Eastern Daylight Time, 
[email-masked] writes:

> Wouldn't the reverse direction just be another target for another tone?  
> For example, what if the indicator tone was different in different countries, 
> per Q.35?
> 

Not sure what your comment is. The thing being discussed is the contents of 
the data (XML) being sent to a specific end device ("terminal" or "UA") to tell 
it to inject a tone to someone. It needs to include something like:

            <xs:element maxOccurs="1" minOccurs="1"
                 name="direction" type="directionType"/>

      <xs:complexType name="directionType">
         <xs:attribute name="type" use="required">
            <xs:simpleType>
               <xs:restriction base="xs:string">
                  <xs:enumeration value="toLocal"/>
                  <xs:enumeration value="toFar"/>
                  <xs:enumeration value="toBoth"/>
               </xs:restriction>
            </xs:simpleType>
         </xs:attribute>

(I'm not an XML expert.)

Mike Pierce

---

From: [email-masked]
Date: Thu, 17 Jul 2003 04:49:25 EDT

In a message dated 7/16/2003 8:14:30 PM Eastern Daylight Time, 
[email-masked] writes:

>  find the notion that an application can instruct a user to send 
> media to its peer in a call - frightening. It can be the source of 
> some potentially bad attacks where a not-so-nice application has you 
> sending media to your friends that you otherwise would not want to 
> send. Its particularly worrisome if you go beyond just a "tones" 
> markup and consider something much richer like VoiceXML.
> 

I share completely the concern with any ability to send someone not-so-nice 
media, which is why I oppose any notion of some general purpose, infinitely 
flexible method (via url or similar) to instruct a device to send an unknown 
media stream (tone or announcement) to anyone, whether to the user of the same 
device or the person at the other end of the call. Your concern with an 
application being able to tell your UA to send something to "your friends" should also 
apply to the possibility of that same application telling your UA to send the 
same thing to yourself or for the same application to tell your friend's UA to 
send something to them. The actual directionality in either UA is not the 
issue.

But, in the existing network, the local exchange switch that one party is 
connected to often has to send tones or announcements to the user at the other 
end. When SIP assumes that there is no equivalent to the "local exchange", it 
must depend on the UA to do some of those functions. This includes sending tones 
in either direction.

To address the concern with "not-so-nice" media being sent, the instructions 
to the UA (for tone insertion) can be in either form:

1. Send tone of such-and-such freq, level, duration, direction, etc. (with 
the UA being unaware of what the tone is intended to mean). The limits on the 
parameter values effectively prevents misuse (e.g., level no greater than -3dB).

2. Send ringing tone, busy tone, preempt tone, etc. (with the UA being 
expected to know the proper charactersitics for the desired tone, including which 
way to send it.)

I believe that similar possibilities should apply for announcements (or any 
more complicated media streams). It must provide procedures so that only the 
desired message (e.g., "The party you are calling is not available.") is sent to 
either user without being replaced by advertising or an obscene message.

Mike Pierce