Subject: Re: [SIP] Announcements in SIP

From: Bryan Byerly <[email-masked]>
Date: Mon, 22 Jan 2001 15:03:55 -0500

Dinesh Nambisan wrote:

>  Hi Bryan,  had a couple of questions with reference to your proposal;
> how would in-band announcements be handledwhen it is relayed through
> SIP-ISDN (read POTS) gateways ? Typically (atleast in the H.323
> world), when a call isnot end to end ISDN and an announcement needs to
> be played, the far-end switch would use either the "progress"indicator
> in Proceeding/Alerting or would send an Progress msg itself to
> indicate to the call originatorabout presence of inband information
> (in most cases, a tone or an announcement), which is relayed by the
> g/w to the originator. Hence if the voice path has already been setup,
> the originating endpoint is ready to receive in-band media (esp with
> it being told before hand using progress) and the originator hears the
> announcement without a CONNECT beingever sent along the path and
> without the call being billed. In this case, the g/w sending a 200 to
> indicate an announcement seems to break that model, is it not ?

"183" (Session Progress) is the analogous SIP response for Q.931's
"Progress" message.  Both are end-to-end provisional responses.

And, similarly "100" (Trying) is the analogous SIP resposne for Q.931's
"Call Proceeding" message.  Both are hop-by-hop provisional responses.

Thus, it seems that usage of 183 with early media (for
announcements) would mimic preexisting Q.931 behavior.

Is everyone ok with using early media to play annoucements?  Is it safe
to assume that even dumb UAs will support 183 with early media?

> On the other hand, say we dont have a 200 response, the announcements
> therefore are "early-media", am not sure how many endpoints handle
> that to begin with, but one major hole seems to be the case of forking
> proxies: a forking proxy inbetween sends the requests to multiple
> destinations, and in a weird situation which is very much likely, we
> get announcement early media from multiple places !!!

I agree that such weird situations are undesirable.  I think this
particular problem could be addressed operationally.  In order to
prevent such weird situations, I think it seem natural to configure the
"originating" proxy to perform the diversion.  Since the originating
proxy would only send one response upstream normally, the originating
proxy could choose to implement call diversion based upon that one
response he would normally send upstream.
 As long as an/the originating proxy performs the diversion, then we're
ok, right?

thanks for your help,
Bryan
 Cheers,Dinesh-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Bryan Byerly
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: "Dinesh Nambisan" <[email-masked]>
Date: Mon, 22 Jan 2001 12:26:10 -0800

Billy Biggs had outlined a whole set of problems with early media in one of
his earlier emails; see
http://lists.bell-labs.com/pipermail/sip/2000q4/004141.html
Looks like there is a definite problem which needs to be resolved, to
maintain interop with existing public infrastructure support of early media
is unavoidable,
but existing proxy behaviour in coordination with early media can create a
few problems, just curious, have there been any attempts to iron this out ?
/Dinesh
  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]]
  Sent: Monday, January 22, 2001 12:04 PM
  To: Dinesh Nambisan; [email-masked]
  Cc: [email-masked]
  Subject: Re: [SIP] Announcements in SIP

  Dinesh Nambisan wrote:
     Hi Bryan,  had a couple of questions with reference to your proposal;
how would in-band announcements be handledwhen it is relayed through
SIP-ISDN (read POTS) gateways ? Typically (atleast in the H.323 world), when
a call isnot end to end ISDN and an announcement needs to be played, the
far-end switch would use either the "progress"indicator in
Proceeding/Alerting or would send an Progress msg itself to indicate to the
call originatorabout presence of inband information (in most cases, a tone
or an announcement), which is relayed by the g/w to the originator. Hence if
the voice path has already been setup, the originating endpoint is ready to
receive in-band media (esp with it being told before hand using progress)
and the originator hears the announcement without a CONNECT beingever sent
along the path and without the call being billed. In this case, the g/w
sending a 200 to indicate an announcement seems to break that model, is it
not ?
  "183" (Session Progress) is the analogous SIP response for Q.931's
"Progress" message.  Both are end-to-end provisional responses.
  And, similarly "100" (Trying) is the analogous SIP resposne for Q.931's
"Call Proceeding" message.  Both are hop-by-hop provisional responses.

  Thus, it seems that usage of 183 with early media (for announcements)
would mimic preexisting Q.931 behavior.

  Is everyone ok with using early media to play annoucements?  Is it safe to
assume that even dumb UAs will support 183 with early media?

    On the other hand, say we dont have a 200 response, the announcements
therefore are "early-media", am not sure how many endpoints handle that to
begin with, but one major hole seems to be the case of forking proxies: a
forking proxy inbetween sends the requests to multiple destinations, and in
a weird situation which is very much likely, we get announcement early media
from multiple places !!!

  I agree that such weird situations are undesirable.  I think this
particular problem could be addressed operationally.  In order to prevent
such weird situations, I think it seem natural to configure the
"originating" proxy to perform the diversion.  Since the originating proxy
would only send one response upstream normally, the originating proxy could
choose to implement call diversion based upon that one response he would
normally send upstream.
   As long as an/the originating proxy performs the diversion, then we're
ok, right?

  thanks for your help,
  Bryan

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

    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.

    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

    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.

    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.

    A possible solution would be to implement the diversion non-recursively:

    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:

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

    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: Billy Biggs <[email-masked]>
Date: Mon, 22 Jan 2001 15:40:38 -0500

> "Progress" message.  Both are end-to-end provisional responses.

  In Q.931 you have a point-to-point connection, while in SIP you have
an unconnected point-to-multipoint tree.  Please read:

  for a discussion on the problems with mapping a Q.931 "Progress"
message to early media.  This issue is an ongoing debate.  I strongly
urge for implementors to ensure that all playback of media (including
streaming ringback and announcements) is performed only once a
point-to-point session has been established.

-- 
Billy Biggs                     [email-masked]
http://www.billybiggs.com/      [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.