Subject: [SIP] Ringback draft

From: "Adam B. Roach" <[email-masked]>
Date: Fri, 10 Nov 2000 10:24:16 -0600 (CST)

I now have an I-D out telling how to describe an appropriate
ringback tone to be played to a caller for a SIP-initiated
voice call; it does so by including new headers in the
"180 Ringing" message. I currently plan to progress this as a 
non-workgroup informational draft, but am open to other
suggestions. Let me know if this topic is of interest to you. 
Comments solicited.

Abstract

     This document describes a mechanism by which an appropriate
     ringback tone may be played to the calling party when the called
     party's device is alerting. It is written specifcally to address
     the case where the Session Initiation Protocol (SIP) is used to
     initiate voice-over-IP calls. It also lists ringback
     characteristics for several countries.

http://search.ietf.org/internet-drafts/draft-roach-voip-ringtone-00.txt

-- 
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
[email-masked]   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Fri, 10 Nov 2000 17:50:09 -0500

I would suggest making the location information somewhat more generic,
as this is useful for other applications, as pointed out in

http://www.ietf.org/internet-drafts/draft-schulzrinne-sip-911-01.txt

Also, there are related efforts in other areas that address the location
problem. It would seem appropriate to take these into consideration, in
the "tradition" of trying to leverage HTTP/web-related work going on, as
well as avoiding too many telephony-only extensions.

http://www.ietf.org/internet-drafts/draft-daviel-http-geo-header-02.txt

http://www.ietf.org/internet-drafts/draft-costanzo-dns-gl-03.txt

(The latter is obviously DNS, but the labeling may be applicable, as
shown in the 911 draft.)

Users can obviously omit details they'd rather not specify or don't
know. 

Also, there's an obvious relationship to RFC 2833 (RTP "tones") that
should be explored. Note also that you could use the Alert-Info for the
same purpose, by providing an external (cached) reference to whatever
national tones you'd like the caller to hear.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: David Shrader <[email-masked]>
Date: Fri, 10 Nov 2000 23:39:09 -0500

Henning has a good point about leveraging the location work going on
elsewhere in the IETF. One question I then have is should the ringback tone
be based on my current location or rather on my home location so that the
caller hears what they expect to hear.

On the other hand, I always found the different tones in different countries
confusing. One advantage to not specifying them is that the originator has
his system customized for his location and he hears a consistent set of
tones regardless of where the callee is located.

I actually don't really like the idea of the originating side reconstructing
the ring pattern for the terminating side in such a specific manner. The use
of the Alert-Info: header provides an ideal solution to the problem.

If we are going to all this trouble for the callee to tell the calling party
what to hear, maybe its better to send a 183 and include the tones via RTP.
Maybe this is something the PSTN did right :-)

----------------------------
David Shrader
Master Consultant, Inc.
"Solution Oriented Engineering"
[email-masked]
http://www.EyeForTheFuture.com

> From: "Henning G. Schulzrinne" <[email-masked]>
> Organization: Dept. of Computer Science, Columbia University
> Date: Fri, 10 Nov 2000 17:50:09 -0500
> To: "Adam B. Roach" <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [SIP] Ringback draft
>

---

From: "Cullen Jennings" <[email-masked]>
Date: Fri, 10 Nov 2000 21:59:35 -0800

One of the nice parts of sending the Ringback tone in the media channel is
that the media channel is established (at least in one direction) before the
callee picks up. This ensure that the first "Hello" of the person answering
the phone is not cut off. This early set up of RTP is probably even more
important when you consider that perhaps QoS and/or encryption are also
being set up for the RTP connection.

If the issue with ring back via RTP is that it wastes bandwidth, I imagine
some special "Ringback tone" style RTP packets could be defined.

Cullen Jennings

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 11 Nov 2000 09:46:33 -0500

> some special "Ringback tone" style RTP packets could be defined.

Well, RFC 2833 already allows to define any tone you want. You can even
do harmonies. All we need is a MIDI-to-RTP translator...

In general, I have to admit that I find the notion of having to
replicate the called country's tones a bit too much of the "it might be
a strange artifact of the phone system, but we have to replicate every
bit of it" syndrom. I can see the advantage that if I'm traveling, to
hear familiar tone sequences regardless of my location. However, that
should be done by configuring either my portable device or, temporarily,
the Internet pay phone to play familiar sounds. I can't say that I've
been confused or comforted by "foreign" ringback; the problem tends to
be more trying to understand the Swedish version of "this number has
been disconnected". More confusing than ringback are usually the various
busy and fast-busy tones.

---

From: "Piotr S. Kossowski" <[email-masked]>
Date: Sat, 11 Nov 2000 17:39:59 +0100

First off, I have to admit that I didn't explored RFC 2833.
But looking thru the "Ringback draft" thread of the SIP list, I thought
about payments, if we consider network with payment policy.
So my appologies for, perhaps, improper question: Who will be paying for 
transmission of RTP ringback tones if transaction is not succesfuly 
completed (e.g. rejected by callee). As i suppose, ringback RTP/UDP 
requires much more bandwith than SIP messages/UDP, and should not be
passed over ?...

Piotr

---

From: "Simon Barber" <[email-masked]>
Date: Sat, 11 Nov 2000 14:00:19 -0800

SIP calls, where the endpoint is IP based will probably not be charged for
(the phone companies will slowly wake up to this fact), unless the call
involves a gateway to the PSTN, special service, or some QoS mechanism.

Simon Barber

---

From: Henry Sinnreich <[email-masked]>
Date: Sat, 11 Nov 2000 17:37:23 -0600

Payment policy that is user friendly would prevent charging for tones. IMHO,
charging for very short intervalls of time, such as the beginning of a
conversation, say for less than 30 seconds is more expensive to the service
provider than not charging at all for such short transients. Even if a
gateway is involved, charging for 10s of seconds does not seem to make
sense, given present ever dropping LD prices.

Henry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Piotr S. Kossowski
Sent: Saturday, November 11, 2000 10:40 AM
To: SIP List
Subject: Re: [SIP] Ringback draft

Piotr

---

From: "Adam B. Roach" <[email-masked]>
Date: Mon, 13 Nov 2000 11:12:54 -0600 (CST)

Henning G. Schulzrinne writes:
>Note also that you could use the Alert-Info for the

I believe this to be the opposite of "Alert-Info."

My understanding is that "Alert-Info" indicates content to be rendered
to the callED party. My draft addresses content to be rendered to the
callING party.

Please correct me if I'm mistaken.

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Mon, 13 Nov 2000 12:28:47 -0500

> Please correct me if I'm mistaken.

You're right; as currently defined. What I meant and should have spelled
out is that it may make sense (if this functionality makes sense, which
I'm less than convinced...) to also define Alert-Info as a response
header, not just a request header.