Subject: Re: [SIP] Announcements in SIP

From: Bryan Byerly <[email-masked]>
Date: Mon, 22 Jan 2001 14:41:30 -0500

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]]
>      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 15:46:28 -0500

Michael Thomas wrote:

> Bryan Byerly writes:
>    How so? It's the announcement server that has the
>    smarts, right?

UAs which are RFC2543 compliant but not rfc2543bis-02 (including clients
supporting minimal implementations of SIP defined by RFC2543 aand
rfc2543bis-02) (i.e. dumb UAs) do not support the following behavior added in
the rfc2543bis-02 draft:
4xx, 5xx, 6xx:
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.

That being said, this is definitely a solution that could be used with
RFC2543bis-02 compliant UAs.

>    It's not like the smart UA would need to be
>    *forced* to use the contact header, right?
>    If it thinks it can put on a better side show
>    than the announcement server, nothing's
>    stopping it, right?

Agreed.

>    contact: sip:[email-masked]?luser=bob
>
>    or some such?

So, we could discuss such an approach.  However, we'd need additional
URL syntax for reason codes, we'd need to talk about how this works when
there are multiple diversions and with private numbering plans.  And, we'd
need an I-D that explains what URI parameters to use so that different
vendor's implementations of user agents, gateways, proxies, and anoucements
servers would be interoperable.

My guess is that we'd end up to a functionally equivalent solution to using
the Diversion header.  But, I'm open to discussing it.

>    The problem with the diversion header is that
>    my UA never got a chance to, oh say, have my
>    UA brew me another cup of coffee while I'm
>    camping on Bob to become available. Instead,
>    the *proxy* decided that for me, and as a
>    result I get no coffee to pacify me.
>
>             Mike

A Diversion header provides supplemental information to the ultimately called
UA, regardless of whether the diversion was implemented by a user agent or
proxy.  The draft does not give preference to either method.. that's a policy
decision.  If that's not clear from the Diversion I-D, then I'd appreciate
your pointing out the confusing sections so I may fix them.

thanks for your help,
Bryan

Bryan J. Byerly
[email-masked]

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