Subject: RE: [SIP] Announcements in SIP

From: "Venkatesh Venkataramanan" <[email-masked]>
Date: Mon, 22 Jan 2001 13:35:26 -0800

I think usage of the diversion-info here is a nice way to notify the
annc-server. For over-coming the problem with dumb UA's may be we can use
something similar to Alert-Info extension that was proposed to provide
alternate information as regards call progress, infact I propose to rename
Alert-Info to CallProgress-Info so that this header may be used to report
call progress/status of any calls, not just alerting. What do u think of
this ? This header could provide inforamation for playing the particular
annc.
 
So to summarize my thoughts a 404 response shall contain a CallProgress-Info
which provides information to dumb UA's as regards annc. Smart UA's can
ignore this information and provide local annc. Does this sound reasonable?
Any repercussions??
 
Venkatesh
 
-----Original Message-----
From: Bryan Byerly [mailto:[email-masked]]
Sent: Monday, January 22, 2001 11:42 AM
To: Venkatesh Venkataramanan; [email-masked]
Cc: [email-masked]
Subject: Re: [SIP] Announcements in SIP

Venkatesh Venkataramanan wrote: 

 Alternate Suggestion:If I understand 404 response right, all that the
proxies do today is to forward them down to the UA. So, instead of making
the proxy either translate the 404 to a 302 or implementing call forwarding
to an annc server on receipt of a 404, I was thinking more on the lines of
just forwarding the 404 response down to the UA, very much like today,
except that the proxy adds a Contact: AnncServer_URL. A smart UA (that can
provide local annc would do so, seeing the 404) where as a UA that doesn't
have any local playback capabilities would contact the Contact: URL to
provide local announcements. So, no extensions involved (except the work of
adding a Contact in a 404 response). Any thoughts on this suggestion?

The approach using a Contact in the response would also work for smart UAs. 

A              Po             Pt           AnnServer 
|              |              |                | 
|--INV Bob@Po->|              |                | 
|              |--INV Bob@Pt->|                |
|              |              |                | 
|              |<-404---------|                | 
|              |              |                | 
|<-404---------|              |                | 
|  Contact: AnnServer         |                | 
|              |              |                | 
|--INV AnnServer------------------------------>| 
|              |              |                | 
|<-183/200-------------------------------------| 
|              |              |                | 
|<="The URL you have dialed B...O...B at Pt is=| 
|   unrouteable, please check the URL or       | 
|   contact your system admin for assistance"  | 

However, 
a) this doesn't provide an announcements solution for dumb UAs 
b) I doubt a smart UA would even need an AnnServer contact.  Since he's
smart, he would either 1) be able to generate annoucements locally or 2)
know the FQDN/IP address of the AnnServer directly.  I'm not aware that
smart UAs need any proxy assist. (Although, they would need to be able to
turn off proxy assist). 

In the proposal above, how would the Announcement server know to say
"B...O...B"? 
One solution would be for the Annoucement server to examine the Diversion
header (draft-levy-sip-diversion-01.txt).  The Diversion header provides the
necessary supplemental information to the announcement server.  Since the
Diversion header is already needed for voicemail servers, I think it is a
good candidate for usage here. 

What do you think? 

thanks, 
Bryan 

Bryan J. Byerly 
[email-masked] 

-----Original Message----- 
From: Bryan Byerly [ mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Monday, January 22, 2001 8:54 AM 
To: [email-masked] 
Cc: [email-masked] 
Subject: [SIP] Announcements in SIP 
 
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: Bryan Byerly <[email-masked]>
Date: Thu, 25 Jan 2001 16:07:11 -0500

Venkatesh Venkataramanan wrote:

>  Hi.Thought I had forwarded this email back to you, but haven't heard
> from you since. Is this a viable suggestion??
>
> Sorry for my slow response.  I was on jury duty the past two days.
> I'm back now.
>  Cheers!
> From: Venkatesh Venkataramanan
> Sent: Monday, January 22, 2001 1:31 PM
> To: 'Bryan Byerly'; Venkatesh Venkataramanan; [email-masked]
> Subject: RE: [SIP] Announcements in SIP
>
> annc-server. For over-coming the problem with dumb UA's may be we can
> use something similar to Alert-Info extension that was proposed to
> provide alternate information as regards call progress, infact I
> propose to rename Alert-Info to CallProgress-Info so that this header
> may be used to report call progress/status of any calls, not just
> alerting. What do u think of this ? This header could provide
> inforamation for playing the particular annc.
>
> Can you point me to the I-D or discussion thread that describes
> Alert-Info?  I'm afraid I've missed it.
>
> So to summarize my thoughts a 404 response shall contain a
> CallProgress-Info which provides information to dumb UA's as regards
> annc. Smart UA's can ignore this information and provide local annc.
> Does this sound reasonable? Any repercussions??Venkatesh-----Original
> Message-----
>     > Alternate Suggestion:If I understand 404 response right,
>     > all that the proxies do today is to forward them down to
>     > the UA. So, instead of making the proxy either translate
>     > the 404 to a 302 or implementing call forwarding to an
>     > annc server on receipt of a 404, I was thinking more on
>     > the lines of just forwarding the 404 response down to the
>     > UA, very much like today, except that the proxy adds a
>     > Contact: AnncServer_URL. A smart UA (that can provide
>     > local annc would do so, seeing the 404) where as a UA that
>     > doesn't have any local playback capabilities would contact
>     > the Contact: URL to provide local announcements. So, no
>     > extensions involved (except the work of adding a Contact
>     > in a 404 response).Any thoughts on this suggestion?
>
>
>      b) I doubt a smart UA would even need an AnnServer contact.
>      Since he's smart, he would either 1) be able to generate
>      annoucements locally or 2) know the FQDN/IP address of the
>      AnnServer directly.  I'm not aware that smart UAs need any
>      proxy assist. (Although, they would need to be able to turn
>      off proxy assist).
>
>      In the proposal above, how would the Announcement server
>      know to say "B...O...B"?
>      One solution would be for the Annoucement server to examine
>      the Diversion header (draft-levy-sip-diversion-01.txt).  The
>      Diversion header provides the necessary supplemental
>      information to the announcement server.  Since the Diversion
>      header is already needed for voicemail servers, I think it
>      is a good candidate for usage here.
>
>      What do you think?
>
>      thanks,
>      Bryan
>
>      Bryan J. Byerly
>      [email-masked]
>
>
>     >      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".
>     >
>     >      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.
>     >
>     >      Announcement
>     >      |
>     >      |
>     >      |                  |--INV Bob@B-->|
>     >      |
>     >      |                  |<-404---------|
>     >      |
>     >      |            proxy implements     |
>     >      |
>     >      |            call forward on 404  |
>     >      |
>     >      |                  |  Diversion: Bob@B
>     >      |
>     >      |
>     >      <-200------------------------------------------|
>     >
>     >      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.
>     >
>     >      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).
>     >
>     >      a) Provides annoucement support in multi-vendor
>     >      networks across all SIP user agents
>     >      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
>     >      AnnServer
>     >      |
>     >      |
>     >      |                  |--INV Bob@B-->|
>     >      |
>     >      |                  |<-404---------|
>     >      |
>     >      |            proxy implements     |
>     >      |
>     >      |            call forward on 404  |
>     >      |
>     >      |                  |  Diversion: Bob@B
>     >      |
>     >      |
>     >      <-200------------------------------------------|
>     >
>     >      AnnServer
>     >      |
>     >      |
>     >      |                  |--INV Bob@B-->|
>     >      |
>     >      |                  |<-404---------|
>     >      |
>     >      |            proxy implements     |
>     >      |
>     >      |            non-recursive        |
>     >      |
>     >      |            call forward on 404  |
>     >      |
>     >      |<-302-------------|              |
>     >      |
>     >      |  Contact: AnnServer             |
>     >      |
>     >      |
>     >      |--INV
>     >      AnnServer------------------------------->|
>     >      |
>     >      <-200------------------------------------------|
>     >
>     >      A ignores 302s with Diversion header indicating
>     >      reason codes for which A local generation of
>     >      annoucements.
>     >      (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             |
>     >      |
>     >      |
>     >      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)
>     >      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
>     >      AnnServer
>     >      |
>     >      |
>     >      |                  |--INV Bob@B-->|
>     >      |
>     >      |                  |<-404---------|
>     >      |
>     >      |            proxy implements     |
>     >      |
>     >      |            call forward on 404  |
>     >      |
>     >      |                  |  Diversion: Bob@B
>     >      |
>     >      |
>     >      <-183------------------------------------------|
>     >
>     >      <-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             |
>     >      |
>     >      |
>     >      |--INV
>     >      AnnServer------------------------------->|
>     >      |
>     >      <-183------------------------------------------|
>     >
>     >      <-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
>     >      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: "Venkatesh Venkataramanan" <[email-masked]>
Date: Thu, 25 Jan 2001 13:28:58 -0800

I see Alert-Info defined in the latest rfc. Section 6.9 in
ietf-sip-rfc2543bis-02.ps talks about this header. 

-----Original Message-----
From: Bryan Byerly [mailto:[email-masked]]
Sent: Thursday, January 25, 2001 1:07 PM
To: Venkatesh Venkataramanan
Cc: [email-masked]; [email-masked]
Subject: Re: FW: [SIP] Announcements in SIP

 Hi.Thought I had forwarded this email back to you, but haven't heard from
you since. Is this a viable suggestion??  

Sorry for my slow response.  I was on jury duty the past two days.  I'm back
now. 
 Cheers! 

-----Original Message----- 
From: Venkatesh Venkataramanan 
Sent: Monday, January 22, 2001 1:31 PM 
To: 'Bryan Byerly'; Venkatesh Venkataramanan; [email-masked] 
Subject: RE: [SIP] Announcements in SIP 

Can you point me to the I-D or discussion thread that describes Alert-Info?
I'm afraid I've missed it. 

Any repercussions??Venkatesh-----Original Message----- 

adding a Contact in a 404 response).Any thoughts on this suggestion?

A              Po             Pt           AnnServer 
|              |              |                | 
|--INV Bob@Po->|              |                | 
|              |--INV Bob@Pt->|                | 
|              |              |                | 
|              |<-404---------|                | 
|              |              |                | 
|<-404---------|              |                | 
|  Contact: AnnServer         |                | 
|              |              |                | 

However, 

What do you think? 

thanks, 
Bryan 

Bryan J. Byerly 
[email-masked] 

-----Original Message----- 
From: Bryan Byerly [ mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Monday, January 22, 2001 8:54 AM 
To: [email-masked] 
Cc: [email-masked] 
Subject: [SIP] Announcements in SIP
Hi guys, 

or non-recursively: 
A                  Po             Pt         AnnServer 
|                  |              |             | 
|--INV Bob@B------>|              |             | 
|                  |--INV Bob@B-->|             | 
|                  |<-404---------|             | 
|            proxy implements     |             | 
|            non-recursive        |             | 

thanks for your help, 
Bryan 

Bryan J. Byerly 
[email-masked]