Subject: [SIP] Announcements in SIP

From: Bryan Byerly <[email-masked]>
Date: Mon, 22 Jan 2001 11:53:54 -0500

Hi guys,

I'd like to solicit ideas/consensus w/r/t announcements in SIP.

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]

---

From: Rick Dean <[email-masked]>
Date: Wed, 24 Jan 2001 11:33:37 -0600

Sadly, I just discovered the hard way that the contact
header of a 407 and 401 (authentication required) response
is like 3xx not 200.  

From: draft-ietf-sip-rfc2543bis-02.txt
>        4xx, 5xx and 6xx responses: The Contact response-header field
>             can be used with a 4xx, 5xx or 6xx response to indicate the
>             location where additional information about the error can
>             be found.

I suppose this also means these response cannot form a route.

Does anyone use them in this fashon for 401 and 407?  

--
Rick

> User agent: Event based local announcement

_______________________________________________
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.