Subject: RE: [SIP] Re: [Fwd: Announcements in SIP]

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 29 Jan 2001 02:56:28 -0500

I've somehow only gotten a subset of the messages in this thread, so I'm a
bit confused as to what exactly has been proposed.

SIP has a way to handle in-band announcements, both before and after a call
is setup. SIP also has a way to redirect a caller to fetch error information
from a URL. All of this is in bis-02. 

Bryan has asked for, in addition to this:

> Desired behavior 1: There should be a mechanism so that local
> annoucements override network annoucements.

I recall somewhere in this thread that there were proposals for things like
SUpported: announcements, or something like that, which indicated whether
the UA wanted to play local announcements or not. I think thats an awful
idea. Ultimately, the issue comes down to control. If control resides with
proxies in the network, the call will be answered and/or early media is
used, and that is what the UA hears. If the call is redirected or responded
to with an Error-Info back to the caller, then control resides in the UA,
and it can play a local announcement. We already have a general purpose
mechanism that allows a UA to request to remain in control - caller
preferences. The request-disposition header can ask for proxy or redirect
for this call:

Request-Disposition: redirect

this would have the effect of allowing the UA to control the local
announcements. I'd rather use a general purpose mechanism like this than
invent some one specifically for announcements.

Bryan has also asked for:
> > Desired behavior 2: There should be a mechanism so that 
> announcements
> > are not billable.

This has nothing to do with the protocol. A service provider bills for
services. If they answer a call and play some kind of error announcement,
its that providers responsibility to bill or not bill accordingly. I don't
see what more needs be done in SIP for this.

-Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

> -----Original Message-----
> From: Henning G. Schulzrinne [mailto:[email-masked]]
> Sent: Sunday, January 28, 2001 1:15 PM
> To: Bryan Byerly; [email-masked]
> Subject: [SIP] Re: [Fwd: Announcements in SIP]
> 
> 
> Bryan Byerly wrote:
> > 
> > I'd appreciate your thoughts on annoucements.
> 
> I probably missed most of the discussion on this, but almost all SIP
> clients have a textual display of at least two lines, so they 
> can render
> the 404 announcement as text. Thus, the lack of local announcements is
> only a problem for gatewayed black phones (which doesn't make the
> problem disappear, but qualifies the statement "no local announcement
> capability"). 
> 
> Also, this is very similar to early media and can be handled by the
> proxy instructing an RTSP server, for example, to send audio to the IP
> address contained in the caller SDP. Override would presumably be
> handled similar for all early media, if text-to-speech conversion is
> used.
> 
> Finally, in case this hasn't been mentioned, 2543bis02 provides the
> Error-Info header, which seems ideally suited to provide a 
> reference to
> further information, using either an RTSP, SIP or HTTP URL (or even a
> data URL, if you don't mind longer messages). The header allows a
> comma-separated list, so that the callee can provide a range 
> of options
> for the caller to choose from, depending on client capabilities and
> human preferences. It does not seem unreasonable for a 
> gateway to speak
> HTTP and RTSP, for example, to retrieve such announcements. (SIP
> soft/hard UAs such as PC software or SIP phones, as I said above, are
> not likely to face this problem.)
> 
> Thus, I'm not exactly sure why this requires additional SIP mechanisms
> or considerations.
> 
> 
> > For this thread of discussion, we're talking about 
> announcements which
> > are played when an error occurred during call setup.  For 
> instance, on
> > 404, a message could be played "The URL you have dialed 
> B...O...B. is
> > not in service, please check the URL or dial the operator for
> > assistance".
> > 
> > There are at least two desired behaviors w/r/t annoucements:
> > Desired behavior 1: There should be a mechanism so that local
> > annoucements override network annoucements.
> > Desired behavior 2: There should be a mechanism so that 
> announcements
> > are not billable.
> > 
> > Like call forwarding features in SIP, there are implementable
> > solutions to play annoucements using user agents or proxies.
> > 
> > In the diagrams below, A, B, and C are user agents, Po is an
> > originating proxy and Pt is a terminating proxy.
> > 
> > User agent: Event based local announcement
> > A                 Po             Pt
> > |                  |              |
> > |--INV Bob@B------>|              |
> > |                  |              |
> > |<-404-------------|              |
> > |                  |              |
> > A generates
> > local audio
> > indicating
> > "The URL you have dialed B...O...B is not in service, 
> please check the
> > 
> >  URL or dial the operator for assistance."
> > 
> > 
> > Proxy: Event based call diversion (recursive)
> > A                  Po             Pt        Announcement
> >                                               Server
> > |                  |              |             |
> > |--INV Bob@B------>|              |             |
> > |                  |--INV Bob@B-->|             |
> > |                  |<-404---------|             |
> > |            proxy implements     |             |
> > |            call forward on 404  |             |
> > |                  |--INV AnnServer------------>|
> > |                  |  Diversion: Bob@B          |
> > |                  |              |             |
> > |<-200------------------------------------------|
> > |<==="The URL you have dialed B...O...B is not==|
> > |     in service, please check the URL or dial  |
> > |     the operator for assistance"
> > 
> > 
> > Both approaches are viable and there are advantages/disadvantages to
> > each.  If all user agents supported local generation of 
> announcements,
> > then an event based call diversion solution may not be needed.
> > However, in today's world, many user agent implementations 
> do not have
> > support for generating local announcements.
> > 
> > Advantages for "event based local announcements"
> > a) requires no network bandwidth
> > b) requires no annoucements server
> > 
> > Disadvantages for "event based local announcements"
> > a) Not all SIP user agents support locally generated announcements
> > b) provisioning issues for large-scale deployments. (i.e. If
> > desirable, how would a network admin configure multi-vendor 
> SIP phones
> > in his net with certain announcements).
> > 
> > Advantages for "event based call diversion"
> > a) Provides annoucement support in multi-vendor networks across all
> > SIP user agents
> > b) Provisioning is centralized at proxy and announcement server
> > 
> > Disadvantages for "event based call diversion"
> > a) requires network bandwidth to play annoucements
> > b) requires presence of an announcements server
> > 
> > I'm not interested in a holy war of which to use.  Each 
> solution will
> > be appropriate for certain network deployments.  There will soon be
> > implementations of event based local annoucements and event 
> based call
> > diversion.  The more important issue is to define a mechanism to get
> > desired feature interaction.
> > 
> > 
> > 
> > Desired behavior 1: There should be a mechanism so that local
> > annoucements override network annoucements.
> > 
> > I would like the behavior that locally generated annoucements take
> > precendence over proxy event based call diversion.  In other words,
> > given a UA that is configured to play announcement X and 
> proxy that is
> > configured to divert to an announcement server to play message Y, I
> > want X to be played.  i.e. I want the behavior of a smart UA to be
> > able to override the behavior (provided by proxies in the 
> network) to
> > dumb UAs.
> > 
> > Unfortunately, Po gets a chance to divert the call first:
> > Proxy: Event based call diversion (recursive)
> > A                  Po             Pt         AnnServer
> > |                  |              |             |
> > |--INV Bob@B------>|              |             |
> > |                  |--INV Bob@B-->|             |
> > |                  |<-404---------|             |
> > |            proxy implements     |             |
> > |            call forward on 404  |             |
> > |                  |--INV AnnServer------------>|
> > |                  |  Diversion: Bob@B          |
> > |                  |              |             |
> > |<-200------------------------------------------|
> > |<==="The URL you have dialed B...O...B is not==|
> > |     in service, please check the URL or dial  |
> > |     the operator for assistance"
> > 
> > Solution 1a: Non-recursive implementation of call diversion
> > A possible solution would be to implement the diversion
> > non-recursively:
> > Proxy: Event based call diversion (non-recursive)
> > A                  Po             Pt         AnnServer
> > |                  |              |             |
> > |--INV Bob@B------>|              |             |
> > |                  |--INV Bob@B-->|             |
> > |                  |<-404---------|             |
> > |            proxy implements     |             |
> > |            non-recursive        |             |
> > |            call forward on 404  |             |
> > |<-302-------------|              |             |
> > |  Contact: AnnServer             |             |
> > |  Diversion: Bob@B; reason=404   |             |
> > |                  |              |             |
> > |--INV AnnServer------------------------------->|
> > |  Diversion: Bob@B; reason=404   |             |
> > |                  |              |             |
> > |<-200------------------------------------------|
> > |<==="The URL you have dialed B...O...B is not==|
> > |     in service, please check the URL or dial  |
> > |     the operator for assistance"
> > 
> > then the feature interaction could be:
> > A ignores 302s with Diversion header indicating reason 
> codes for which
> > A local generation of annoucements.
> > Proxy: Event based call diversion (non-recursive)
> > User agent: Event based local announcement (overriding 302s with
> > already covered Diversion reason codes)
> > A                  Po             Pt         AnnServer
> > |                  |              |             |
> > |--INV Bob@B------>|              |             |
> > |                  |--INV Bob@B-->|             |
> > |                  |<-404---------|             |
> > |            proxy implements     |             |
> > |            non-recursive        |             |
> > |            call forward on 404  |             |
> > |<-302-------------|              |             |
> > |  Contact: AnnServer             |             |
> > |  Diversion: Bob@B; reason=404   |             |
> > |                  |              |             |
> > A generates
> > local audio
> > indicating
> > "The URL you have dialed B...O...B is not in service, 
> please check the
> > 
> >  URL or dial the operator for assistance."
> > 
> > Solution 1b: "Supported: annoucements" header
> > Another possible solution would be for smart UAs (that support
> > announcements) to use a "Supported: annoucements" header.  This
> > supported header would be used to indicate to proxies that 
> they should
> > not implement event based call forwarding (for annoucements):
> > 
> > Proxy: Event based call diversion (deferring implementation to UAC
> > when "Supported: annoucements" is present)
> > User agent: Event based local announcement
> > A                 Po             Pt
> > |                  |              |
> > |--INV Bob@B------>|              |
> > |  Supported: annoucements        |
> > |                  |              |
> > |<-404-------------|              |
> > |                  |              |
> > A generates
> > local audio
> > indicating
> > "The URL you have dialed B...O...B is not in service, 
> please check the
> > 
> >  URL or dial the operator for assistance."
> > 
> > 
> > 
> > Desired behavior 2:  There should be a mechanism so that 
> announcements
> > are not billable.
> > 
> > Another issue that has been raised w/r/t annoucements in networks
> > where SIP signalling is billable.  The concern is that in 
> SIP networks
> > where 200 is used to write a start record, implementation of proxy
> > event based call diversion might generate a charge.
> > 
> > Solution 2a: Play annoucements as early media
> > One solution that has been proposed is to play annoucements as early
> > media:
> > 
> > For example, recursively:
> > A                  Po             Pt         AnnServer
> > |                  |              |             |
> > |--INV Bob@B------>|              |             |
> > |                  |--INV Bob@B-->|             |
> > |                  |<-404---------|             |
> > |            proxy implements     |             |
> > |            call forward on 404  |             |
> > |                  |--INV AnnServer------------>|
> > |                  |  Diversion: Bob@B          |
> > |                  |              |             |
> > |<-183------------------------------------------|
> > |  Content-Disposition: session                 |
> > |<==="The URL you have dialed B...O...B is not==|
> > |     in service, please check the URL or dial  |
> > |     the operator for assistance"
> > |<-CANCEL---------------------------------------|
> > |--200 (CANCEL)-------------------------------->|
> > 
> > or non-recursively:
> > A                  Po             Pt         AnnServer
> > |                  |              |             |
> > |--INV Bob@B------>|              |             |
> > |                  |--INV Bob@B-->|             |
> > |                  |<-404---------|             |
> > |            proxy implements     |             |
> > |            non-recursive        |             |
> > |            call forward on 404  |             |
> > |<-302-------------|              |             |
> > |  Contact: AnnServer             |             |
> > |  Diversion: Bob@B; reason=404   |             |
> > |                  |              |             |
> > |--INV AnnServer------------------------------->|
> > |  Diversion: Bob@B; reason=404   |             |
> > |                  |              |             |
> > |<-183------------------------------------------|
> > |  Content-Disposition: session                 |
> > |<==="The URL you have dialed B...O...B is not==|
> > |     in service, please check the URL or dial  |
> > |     the operator for assistance"
> > |<-CANCEL---------------------------------------|
> > |--200 (CANCEL)-------------------------------->|
> > 
> > Solution 2b: Backend billing system is aware of (non-billable)
> > Announcement Server URL
> > Another possible solution is that the URL of the AnnServer could be
> > well-known to the backend billing system and that any accounting
> > records written connection to the AnnServer would not be billed.
> > 
> > I'd like to solicit others' ideas, problems, and proposed solutions
> > w/r/t annoucements in SIP.
> > 
> > I'm also looking for co-authors to write an I-D w/r/t announcements.
> > If interested, please contact me directly at [email-masked].
> > 
> > thanks for your help,
> > Bryan
> > 
> > Bryan J. Byerly
> > [email-masked]
> > 
> > 
> 
> -- 
> Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
> 
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementer's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to [email-masked] with
> "subscribe sip-implementors" in the body.
> 

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to [email-masked] with
"subscribe sip-implementors" in the body.

---

From: "Eric Burger" <[email-masked]>
Date: Tue, 30 Jan 2001 19:27:15 -0500

In my mind, text display and error-info would work just fine.  I do take
exception to early media, however.  We have the opportunity to plug the
early media hole.  Not only that, but we get to provide a more useful
system, as well!

Just because we can do early media doesn't mean we should.  Rather than
telling implementers that the far end can play a SIT announcement, we should
be suggesting an informative text message with an optional place to get an
audio version.

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Jonathan Rosenberg
> Sent: Monday, January 29, 2001 2:56 AM
> To: 'Henning G. Schulzrinne'; Bryan Byerly; [email-masked]
> Subject: RE: [SIP] Re: [Fwd: Announcements in SIP]
>
>

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Wed, 31 Jan 2001 09:40:38 -0500

> be suggesting an informative text message with an optional place to get an

Just in case my position was unclear: I fully agree. Early media is a
last-resort mechanism and should be avoided where possible, as it is far
less semantically rich than more explicit alternatives.