Subject: [sipcore] A SIP OAuth use case

From: Matt Ryan <[email-masked]>
Date: Sat, 23 Aug 2014 07:05:01 -0600

Included is the use case I spoke of before.  My apologies for the delay.

This is written as though it could be included in [draft-yusef-sipcore-sip-oauth] at section 6.

6. Examples

6.1. Example: Call Recording Service

This example illustrates the use of SIP OAuth between three parties:  A hosted VoIP service provider, a Call Recording Service provider, and a phone system end-user.  In this example:
- The phone system end-user is a customer of both the hosted VoIP provider and the Call Recording Service provider
- The hosted VoIP service provider is a standard provider of hosted business-class VoIP telephone service using SIP
- The Call Recording Service provider is a distinct entity from the hosted VoIP provider

The Call Recording Service provides to customers both the call recording abilities and management of call recordings (configuration, sharing and distribution, retention, etc.).  This service can accept and record RTP traffic, associate all RTP streams with a single call together, and store and catalog the recorded data for future searching and retrieval.  The service also offers a web interface where customers may view and retrieve stored calls.  Stored calls may range from simple person-to-person voice calls to multi-party conferences with a multitude of audio and video streams.  In this example, customers are billed based on the amount of data they store, although other models are certainly possible.

6.1.1. OAuth 2.0 Roles

In this example, each party assumes the following OAuth 2.0 roles as defined in [RFC6749] Section 1.1:
- The end-user assumes the role of resource owner
- The hosted VoIP service provider assumes the role of client
- The Call Recording Service provider assumes the role of resource server as well as the role of authorization server

6.1.2. Description

There are two parts to the example:  Initial configuration and real-time recording authorization.

Each section includes a simplified flow diagram for the purpose of describing the corresponding portion of the example.  For the sake of brevity, certain parts of the OAuth dialog have been eliminated.  Implements should refer to [RFC6749] for details on OAuth.

6.1.2.1 Initial Configuration

  +-------------+     +---------------+     +--------------+
  |  End-User   |     | VoIP Provider |     | CRS Provider |
  | Web Browser |     |    Website    |     |              |
  +-------------+     +---------------+     +--------------+
         |                    |                     |
	 | HTTP 1             |                     |
	 | (Configure CRS)    |                     |
	 |------------------->|                     |
	 |                    |                     |
	 | HTTP 2             |                     |
	 | (OAuth Redirect    |                     |
	 |  to CRS Website)   |                     |
	 |<-------------------|                     |
	 |                    |                     |
	 | HTTP 3             |                     |
	 | (Authorize SIP from VoIP provider        |
	 |----------------------------------------->|
	 |                    |                     |
	 | HTTP 4             |                     |
	 | (OAuth Redirect back to VoIP portal)     |
	 |<-----------------------------------------|
	 |                    |                     |
	 | HTTP 5             |                     |
	 |------------------->|                     |
	 |                    | HTTP 6              |
	 |                    | (Request Access and |
	 |                    |  refresh tokens)    |
	 |                    |-------------------->|
	 |                    |                     |

Some time after having signed up for both services, but prior to attempting to record any calls, the end-user logs into the web portal of the hosted VoIP provider with a web browser and configures their call recording service (HTTP 1).  This configuration includes providing a URI where the call recording service may be reached, along with a set of API credentials, provided by the call recording service, which will allow the client to initiate an OAuth exchange.  The end-user also configures the conditions under which call recordings should take place.  For example, the end-user may request to record every multi-party (conference) call, or every call involving a specific set of users.  The end-user may also specify other restrictions, such as restricting codec negotiation to G.711u for audio and H.264 for video in order to record the RTP streams.
Once the end-user saves the configuration, the hosted VoIP provider web portal redirects the end-user's web browser to the call recording service website and a standard HTTP OAuth dialog begins (HTTP 2).  The end-user authorizes the hosted VoIP provider to access (i.e. send SIP and RTP traffic to) the call recording service, for the purpose of recording calls, so long as the configured conditions are met (HTTP 3).  The result of this interaction is that the hosted VoIP provider ends up receiving an OAuth access token and refresh token from the call recording service (HTTP 4, HTTP 5, HTTP 6).  These tokens are saved in the end-user's hosted VoIP account database.

6.1.2.2 Real-time Recording Authorization

  +-------------+     +---------------+      +--------------+
  |  End-User   |     | VoIP Provider |      | CRS Provider |
  |  SIP Phone  |     |    Website    |      |              |
  +-------------+     +---------------+      +--------------+
         |                    |                      |
         | SIP INVITE 1       |                      |
	 |------------------->|                      |
	 |                    | SIP INVITE 2         |
	 |                    | (with access token)  |
	 |                    |--------------------->|
	 |                    |                      |
	 |                    | SIP 401 Unauthorized |
	 |                    |<---------------------|
	 |                    |                      |
	 |                    | SIP INVITE 3         |
	 |                    | (with refresh token) |
	 |                    |--------------------->|
	 |                    |                      |
	 |                    | SIP 200 1            |
	 |                    | (new access token)   |
	 |                    |<---------------------|
	 |                    |                      |
	 |                    | SIP INVITE 4         |
	 |                    | (with access token)  |
	 |                    |--------------------->|
	 |                    |                      |
	 |                    | SIP 200 2            |
	 |                    |<---------------------|
	 |                    |                      |
		 
Independently of and after the initial configuration phase, the end-user makes a telephone call using the hosted VoIP provider (SIP INVITE 1).  When this call takes place, the hosted VoIP provider looks to see whether it believes this call should be recorded.  If so, at this point it would branch the call session to the call recording service, using SIP OAuth to pass the previously provided access token for authorization (SIP INVITE 2).  Once the access token is validated by the call recording service (perhaps after first providing a new access token based on receipt of a valid refresh token), the call recording service will check the rights that were previously authorized and examine the SIP to determine whether it can accept the call.  If so, it completes the establishment of the session and begins receiving and recording the RTP stream(s) (SIP 200 OK).  The call recording service provider could also deny the request, either because the tokens are invalid or because the content of the SIP invite does not match the previously authorized conditions, in which case a SIP 403 would be returned by the call recording service provider and the call would not be recorded - however, the initial call branch would continue without interruption.

Note:
[RFC6749] specifies that when a client uses a refresh token to request a new access token, the response is HTTP 200 with the new access token and optionally a new refresh token included in the payload.  In this example, a SIP 200 response (SIP 200 1) is sent which contains the new token(s).  However, this could be confusing as SIP 200 is generally viewed as the acceptance of the INVITE, which is not what is happening in this case.  Should SIP 200 be used for consistency, or should another mechanism be used?

6.1.3. Justification

6.1.3.1. Hosted VoIP Service Provider

In this example, the hosted VoIP service provider can allow their customers to enable call recording in their VoIP service by selecting from any of a number of supported call recording service providers.  This allows the hosted VoIP service provider to offer this feature to customers without requiring that the hosted VoIP service provider implement and support this feature themselves.

6.1.3.2. Call Recording Service Provider

In this example, the Call Recording Service provider can focus on value and innovation in the area of recording calls and managing recorded calls without having to build a full-featured telephony offering.

6.1.3.3. Customer

In this example, the customer has more flexibility in choosing a complete solution that meets all of the customer needs.  The customer does not have to settle for a substandard call recording service offering in order to obtain other features they seek in a hosted VoIP provider, and vice versa.

6.1.4. Variants

A simple variant of this example is one wherein one of the services (either the VoIP service or the call recording service) is managed directly by the end-user, but the other is not.  For example, the end-user may wish to make use of an external hosted VoIP service provider, but may have business or legal reasons that forbid the end-user from allowing a third party to store and manage recorded calls.  The end-user could choose to set up their own call recording service as described in this example, and use SIP OAuth to facilitate interaction between the hosted VoIP service and the end-user's own call recording service.

6.2. Other SIP OAuth examples

Many other SIP-based services could leverage SIP OAuth to provide value-added service to an end-user of a hosted VoIP service provider.  Some examples of these types of services are listed below.

Voicemail service provider:  The end-user configures their hosted VoIP service provider to manage voicemail through a separate voicemail service provider, which chooses whether to store voicemail based on existing quotas, Caller ID, etc.

Conferencing service provider:  A conferencing service may wish to bill customers in a more granular fashion, for example, based on the number of participants and attendees in a conference, the duration of conference, whether video was also included, which codecs were being used, etc. instead of a flat monthly rate.  SIP OAuth would facilitate metered authorization for a client's use of the service, instead of all-or-nothing access.

Call center service provider:  A third party may provide ring groups or call queues for a hosted VoIP provider along with detailed reports and dashboards.  The end-user uses OAuth over SIP to control who can log into which queues or ring groups, etc.

--
Matt Ryan
code slinger | zoomulus.com
ietf at mvryan dot org

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Mon, 25 Aug 2014 11:50:23 -0400

Hi Matt,

The use case and the solution provided assumes that the VoIP Provider makes
the decision on when and what to record.
While this is a valid use case, there are other use cases that allow the
user to decide on when and what to record; take a look at RFC6341 for more
info.
http://datatracker.ietf.org/doc/rfc6341/

For these use cases, where the user is in control, you need to away to
authenticate and control which users are allowed to record and the level of
service provided for that specific user.
This is where the solutions provided in section 3 or section 4 of the SIP
OAuth proposal come into play.
Obviously, in this case the authorization server is different from
authorization server used to establish the trust relationship between the
VoIP Provider and the CRS Provider.
In this case, the authorization server must authenticate the user and
provide his UA with an access token or a code that controls the user's
access to the service.

Regards,
 Rifaat

On Sat, Aug 23, 2014 at 9:05 AM, Matt Ryan <[email-masked]> wrote:

> This is written as though it could be included in
> [draft-yusef-sipcore-sip-oauth] at section 6.
>
>
> 6. Examples
>
> This example illustrates the use of SIP OAuth between three parties:  A
> hosted VoIP service provider, a Call Recording Service provider, and a
> phone system end-user.  In this example:
> - The hosted VoIP service provider is a standard provider of hosted
> business-class VoIP telephone service using SIP
> The Call Recording Service provides to customers both the call recording
> abilities and management of call recordings (configuration, sharing and
> distribution, retention, etc.).  This service can accept and record RTP
> traffic, associate all RTP streams with a single call together, and store
> and catalog the recorded data for future searching and retrieval.  The
> service also offers a web interface where customers may view and retrieve
> stored calls.  Stored calls may range from simple person-to-person voice
> calls to multi-party conferences with a multitude of audio and video
> streams.  In this example, customers are billed based on the amount of data
> they store, although other models are certainly possible.
>
> 6.1.1. OAuth 2.0 Roles
>
> - The Call Recording Service provider assumes the role of resource server
> as well as the role of authorization server
>
> 6.1.2. Description
>
> Each section includes a simplified flow diagram for the purpose of
> describing the corresponding portion of the example.  For the sake of
> brevity, certain parts of the OAuth dialog have been eliminated.
> Implements should refer to [RFC6749] for details on OAuth.
>
> Some time after having signed up for both services, but prior to
> attempting to record any calls, the end-user logs into the web portal of
> the hosted VoIP provider with a web browser and configures their call
> recording service (HTTP 1).  This configuration includes providing a URI
> where the call recording service may be reached, along with a set of API
> credentials, provided by the call recording service, which will allow the
> client to initiate an OAuth exchange.  The end-user also configures the
> conditions under which call recordings should take place.  For example, the
> end-user may request to record every multi-party (conference) call, or
> every call involving a specific set of users.  The end-user may also
> specify other restrictions, such as restricting codec negotiation to G.711u
> for audio and H.264 for video in order to record the RTP streams.
> Once the end-user saves the configuration, the hosted VoIP provider web
> portal redirects the end-user's web browser to the call recording service
> website and a standard HTTP OAuth dialog begins (HTTP 2).  The end-user
> authorizes the hosted VoIP provider to access (i.e. send SIP and RTP
> traffic to) the call recording service, for the purpose of recording calls,
> so long as the configured conditions are met (HTTP 3).  The result of this
> interaction is that the hosted VoIP provider ends up receiving an OAuth
> access token and refresh token from the call recording service (HTTP 4,
> HTTP 5, HTTP 6).  These tokens are saved in the end-user's hosted VoIP
> account database.
>
> Independently of and after the initial configuration phase, the end-user
> makes a telephone call using the hosted VoIP provider (SIP INVITE 1).  When
> this call takes place, the hosted VoIP provider looks to see whether it
> believes this call should be recorded.  If so, at this point it would
> branch the call session to the call recording service, using SIP OAuth to
> pass the previously provided access token for authorization (SIP INVITE
> 2).  Once the access token is validated by the call recording service
> (perhaps after first providing a new access token based on receipt of a
> valid refresh token), the call recording service will check the rights that
> were previously authorized and examine the SIP to determine whether it can
> accept the call.  If so, it completes the establishment of the session and
> begins receiving and recording the RTP stream(s) (SIP 200 OK).  The call
> recording service provider could also deny the request, either because the
> tokens are invalid or because the content of
>  the SIP invite does not match the previously authorized conditions, in
> which case a SIP 403 would be returned by the call recording service
> provider and the call would not be recorded - however, the initial call
> branch would continue without interruption.
>
> Note:
> [RFC6749] specifies that when a client uses a refresh token to request a
> new access token, the response is HTTP 200 with the new access token and
> optionally a new refresh token included in the payload.  In this example, a
> SIP 200 response (SIP 200 1) is sent which contains the new token(s).
> However, this could be confusing as SIP 200 is generally viewed as the
> acceptance of the INVITE, which is not what is happening in this case.
> Should SIP 200 be used for consistency, or should another mechanism be used?
>
> 6.1.3. Justification
>
> In this example, the hosted VoIP service provider can allow their
> customers to enable call recording in their VoIP service by selecting from
> any of a number of supported call recording service providers.  This allows
> the hosted VoIP service provider to offer this feature to customers without
> requiring that the hosted VoIP service provider implement and support this
> feature themselves.
>
> In this example, the Call Recording Service provider can focus on value
> and innovation in the area of recording calls and managing recorded calls
> without having to build a full-featured telephony offering.
>
> 6.1.3.3. Customer
>
> In this example, the customer has more flexibility in choosing a complete
> solution that meets all of the customer needs.  The customer does not have
> to settle for a substandard call recording service offering in order to
> obtain other features they seek in a hosted VoIP provider, and vice versa.
>
> 6.1.4. Variants
>
> A simple variant of this example is one wherein one of the services
> (either the VoIP service or the call recording service) is managed directly
> by the end-user, but the other is not.  For example, the end-user may wish
> to make use of an external hosted VoIP service provider, but may have
> business or legal reasons that forbid the end-user from allowing a third
> party to store and manage recorded calls.  The end-user could choose to set
> up their own call recording service as described in this example, and use
> SIP OAuth to facilitate interaction between the hosted VoIP service and the
> end-user's own call recording service.
>
> Many other SIP-based services could leverage SIP OAuth to provide
> value-added service to an end-user of a hosted VoIP service provider.  Some
> examples of these types of services are listed below.
>
> Voicemail service provider:  The end-user configures their hosted VoIP
> service provider to manage voicemail through a separate voicemail service
> provider, which chooses whether to store voicemail based on existing
> quotas, Caller ID, etc.
>
> Conferencing service provider:  A conferencing service may wish to bill
> customers in a more granular fashion, for example, based on the number of
> participants and attendees in a conference, the duration of conference,
> whether video was also included, which codecs were being used, etc. instead
> of a flat monthly rate.  SIP OAuth would facilitate metered authorization
> for a client's use of the service, instead of all-or-nothing access.
>
> Call center service provider:  A third party may provide ring groups or
> call queues for a hosted VoIP provider along with detailed reports and
> dashboards.  The end-user uses OAuth over SIP to control who can log into
> which queues or ring groups, etc.
>
>
>
> --
> Matt Ryan
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 25 Aug 2014 14:44:10 -0400

On 8/25/14 11:50 AM, Rifaat Shekh-Yusef wrote:
> Hi Matt,
>
> The use case and the solution provided assumes that the VoIP Provider
> makes the decision on when and what to record.
> user to decide on when and what to record; take a look at RFC6341 for
> more info.

SIPREC supports numerous topologies.
It would support the one that Matt outlines as well as end-user 
controlled ones.

I found Matt's use case interesting. I think it would be nice if such 
services were available in that form. But I have difficulty imagining 
any of the VoIP providers I'm aware of supporting this model. My 
impression is that this means that they are giving up a value added 
revenue market, that they are loath to do. The most likely justification 
I can imagine that they don't want to legal consequences of doing recording.

	Thanks,
	Paul

> authenticate and control which users are allowed to record and the level
> of service provided for that specific user.
> This is where the solutions provided in section 3 or section 4 of the
> SIP OAuth proposal come into play.
> authorization server used to establish the trust relationship between
> the VoIP Provider and the CRS Provider.
> On Sat, Aug 23, 2014 at 9:05 AM, Matt Ryan <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     This example illustrates the use of SIP OAuth between three
>     parties:  A hosted VoIP service provider, a Call Recording Service
>     provider, and a phone system end-user.  In this example:
>     - The phone system end-user is a customer of both the hosted VoIP
>     provider and the Call Recording Service provider
>     The Call Recording Service provides to customers both the call
>     recording abilities and management of call recordings
>     (configuration, sharing and distribution, retention, etc.).  This
>     service can accept and record RTP traffic, associate all RTP streams
>     with a single call together, and store and catalog the recorded data
>     for future searching and retrieval.  The service also offers a web
>     interface where customers may view and retrieve stored calls.
>     Stored calls may range from simple person-to-person voice calls to
>     multi-party conferences with a multitude of audio and video
>     streams.  In this example, customers are billed based on the amount
>     of data they store, although other models are certainly possible.
>
>     6.1.1. OAuth 2.0 Roles
>
>     - The Call Recording Service provider assumes the role of resource
>     server as well as the role of authorization server
>
>     6.1.2. Description
>
>     describing the corresponding portion of the example.  For the sake
>     of brevity, certain parts of the OAuth dialog have been eliminated.
>     attempting to record any calls, the end-user logs into the web
>     portal of the hosted VoIP provider with a web browser and configures
>     their call recording service (HTTP 1).  This configuration includes
>     providing a URI where the call recording service may be reached,
>     along with a set of API credentials, provided by the call recording
>     service, which will allow the client to initiate an OAuth exchange.
>     The end-user also configures the conditions under which call
>     recordings should take place.  For example, the end-user may request
>     to record every multi-party (conference) call, or every call
>     involving a specific set of users.  The end-user may also specify
>     other restrictions, such as restricting codec negotiation to G.711u
>     Once the end-user saves the configuration, the hosted VoIP provider
>     web portal redirects the end-user's web browser to the call
>     recording service website and a standard HTTP OAuth dialog begins
>     (HTTP 2).  The end-user authorizes the hosted VoIP provider to
>     access (i.e. send SIP and RTP traffic to) the call recording
>     service, for the purpose of recording calls, so long as the
>     configured conditions are met (HTTP 3).  The result of this
>     interaction is that the hosted VoIP provider ends up receiving an
>     OAuth access token and refresh token from the call recording service
>     (HTTP 4, HTTP 5, HTTP 6).  These tokens are saved in the end-user's
>     hosted VoIP account database.
>
>     Independently of and after the initial configuration phase, the
>     end-user makes a telephone call using the hosted VoIP provider (SIP
>     INVITE 1).  When this call takes place, the hosted VoIP provider
>     looks to see whether it believes this call should be recorded.  If
>     so, at this point it would branch the call session to the call
>     recording service, using SIP OAuth to pass the previously provided
>     access token for authorization (SIP INVITE 2).  Once the access
>     token is validated by the call recording service (perhaps after
>     first providing a new access token based on receipt of a valid
>     refresh token), the call recording service will check the rights
>     that were previously authorized and examine the SIP to determine
>     whether it can accept the call.  If so, it completes the
>     establishment of the session and begins receiving and recording the
>     RTP stream(s) (SIP 200 OK).  The call recording service provider
>     could also deny the request, either because the tokens are invalid
>     or because the content of
>       the SIP invite does not match the previously authorized
>     conditions, in which case a SIP 403 would be returned by the call
>     recording service provider and the call would not be recorded -
>     however, the initial call branch would continue without interruption.
>
>     Note:
>     [RFC6749] specifies that when a client uses a refresh token to
>     request a new access token, the response is HTTP 200 with the new
>     access token and optionally a new refresh token included in the
>     payload.  In this example, a SIP 200 response (SIP 200 1) is sent
>     which contains the new token(s).  However, this could be confusing
>     as SIP 200 is generally viewed as the acceptance of the INVITE,
>     which is not what is happening in this case.  Should SIP 200 be used
>     for consistency, or should another mechanism be used?
>
>     6.1.3. Justification
>
>     customers to enable call recording in their VoIP service by
>     selecting from any of a number of supported call recording service
>     providers.  This allows the hosted VoIP service provider to offer
>     this feature to customers without requiring that the hosted VoIP
>     service provider implement and support this feature themselves.
>
>     In this example, the Call Recording Service provider can focus on
>     value and innovation in the area of recording calls and managing
>     recorded calls without having to build a full-featured telephony
>     offering.
>
>     6.1.3.3. Customer
>
>     In this example, the customer has more flexibility in choosing a
>     complete solution that meets all of the customer needs.  The
>     customer does not have to settle for a substandard call recording
>     service offering in order to obtain other features they seek in a
>     hosted VoIP provider, and vice versa.
>
>     6.1.4. Variants
>
>     (either the VoIP service or the call recording service) is managed
>     directly by the end-user, but the other is not.  For example, the
>     end-user may wish to make use of an external hosted VoIP service
>     provider, but may have business or legal reasons that forbid the
>     end-user from allowing a third party to store and manage recorded
>     calls.  The end-user could choose to set up their own call recording
>     service as described in this example, and use SIP OAuth to
>     facilitate interaction between the hosted VoIP service and the
>     value-added service to an end-user of a hosted VoIP service
>     provider.  Some examples of these types of services are listed below.
>
>     Voicemail service provider:  The end-user configures their hosted
>     VoIP service provider to manage voicemail through a separate
>     voicemail service provider, which chooses whether to store voicemail
>     based on existing quotas, Caller ID, etc.
>
>     Conferencing service provider:  A conferencing service may wish to
>     bill customers in a more granular fashion, for example, based on the
>     number of participants and attendees in a conference, the duration
>     of conference, whether video was also included, which codecs were
>     being used, etc. instead of a flat monthly rate.  SIP OAuth would
>     facilitate metered authorization for a client's use of the service,
>     instead of all-or-nothing access.
>
>     Call center service provider:  A third party may provide ring groups
>     or call queues for a hosted VoIP provider along with detailed
>     reports and dashboards.  The end-user uses OAuth over SIP to control
>     who can log into which queues or ring groups, etc.
>
>
>
>     --
>     Matt Ryan
>     code slinger | zoomulus.com <http://zoomulus.com>
>     ietf at mvryan dot org
>
>
>
>
>     [email-masked] <mailto:[email-masked]>

---

From: Matt Ryan <[email-masked]>
Date: Mon, 25 Aug 2014 13:22:46 -0600

Comments below

On Aug 25, 2014, at 9:50 AM, Rifaat Shekh-Yusef <[email-masked]> wrote:

> Hi Matt,
> 
> The use case and the solution provided assumes that the VoIP Provider makes the decision on when and what to record.

This is true - and not true.  The VoIP provider is making the decision on what SIP and RTP traffic to send to the call recording service.  This decision is based (presumably) on settings provided to the VoIP provider by the user.  So unless the VoIP provider either has buggy code or is dishonest, the VoIP provider will make this decision based on the user’s preferences.
The VoIP provider does NOT decide when and what to record.  That decision is made by the call recording service, based on information contained within the SIP traffic sent to it by the VoIP provider.  This decision is, again, based upon the user’s settings that they themselves have made.

So, assuming everyone is writing functional code and is following the outlined use case, the user controls what gets recorded by how they have configured both services.

> While this is a valid use case, there are other use cases that allow the user to decide on when and what to record; take a look at RFC6341 for more info.
> For these use cases, where the user is in control, you need to away to authenticate and control which users are allowed to record and the level of service provided for that specific user.
> This is where the solutions provided in section 3 or section 4 of the SIP OAuth proposal come into play.
> Obviously, in this case the authorization server is different from authorization server used to establish the trust relationship between the VoIP Provider and the CRS Provider.
> In this case, the authorization server must authenticate the user and provide his UA with an access token or a code that controls the user's access to the service.

No, the authorization server does not need to authenticate the user.  It simply needs to validate the access token or refresh token sent to it by the client.

---

From: Matt Ryan <[email-masked]>
Date: Mon, 25 Aug 2014 13:27:57 -0600

On Aug 25, 2014, at 12:44 PM, Paul Kyzivat <[email-masked]> wrote:

> It would support the one that Matt outlines as well as end-user controlled ones.
> 
> I found Matt's use case interesting. I think it would be nice if such services were available in that form. But I have difficulty imagining any of the VoIP providers I'm aware of supporting this model. My impression is that this means that they are giving up a value added revenue market, that they are loath to do. The most likely justification I can imagine that they don't want to legal consequences of doing recording.

I think it depends on the VoIP provider’s strategy, whether they view integration with other offerings as a plus or a minus.

One example that comes readily to mind for this specific use case is a health care provider - say, a clinic in a small town.  The clinic might need 20 or 30 phones, making them an ideal candidate for hosted service.  They may also wish to record calls, but perhaps HIPAA (I’m no HIPAA expert) would not allow them to store recorded calls outside of their own management.  A solution like this would allow them to bring the call recording into their own control without having to manage the whole telephony system.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 25 Aug 2014 15:39:26 -0400

> One example that comes readily to mind for this specific use case is a health care provider - say, a clinic in a small town.  The clinic might need 20 or 30 phones, making them an ideal candidate f…

That is a good example.
It is a case where the provider is probably legally unable to provide 
the service. (Or at least unwilling to jump through the hoops 
necessary.) And yet the provider may well be motivated to allow the 
outsourcing of this feature in order to get the rest of the business.

	Thanks,
	Paul

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Mon, 25 Aug 2014 15:53:44 -0400

Inline...

On Mon, Aug 25, 2014 at 3:22 PM, Matt Ryan <[email-masked]> wrote:

> This is true - and not true.  The VoIP provider is making the decision on
> what SIP and RTP traffic to send to the call recording service.  This
> decision is based (presumably) on settings provided to the VoIP provider by
> the user.  So unless the VoIP provider either has buggy code or is
> dishonest, the VoIP provider will make this decision based on the user's
> preferences.
> The VoIP provider does NOT decide when and what to record.  That decision
> is made by the call recording service, based on information contained
> within the SIP traffic sent to it by the VoIP provider.  This decision is,
> again, based upon the user's settings that they themselves have made.
>
> So, assuming everyone is writing functional code and is following the
> outlined use case, the user controls what gets recorded by how they have
> configured both services.
>
>
Some use cases cannot be addressed by some user preferences set by the user.
One of the use cases allows the user to start a call, and then start and
stop recording based on a command from the user.

> No, the authorization server does not need to authenticate the user.  It
> simply needs to validate the access token or refresh token sent to it by
> the client.
>
>
Well, you need to authenticate the user at least once to get access and
refresh tokens.

Regards,
 Rifaat