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

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Sun, 28 Jan 2001 13:14:31 -0500

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.