Call Recording use case (was Re: [Sipping] I-D on service identification now available)

[Eric Burger <eburger at bea.com>]

I have to agree with Dean here.  The assumption in Route: urn:call-recorder
is the access network is the ONLY network that will act on this request.
This assumption is either trivial or wrong.

The trivial case is the one brought up earlier where the endpoint is always
connected to the same access network.  In this case, it is trivial to
configure either the outbound proxy or the endpoint to "do the right thing"
by either having the UAC explicitly routing through a call recorder, having
the UAC insert a proprietary token (like a URN) into the INVITE, having the
UAC do 3pcc to a media server, or having the outbound proxy apply whatever
logic would lead it to record the call (like being in a financial services
firm).

The wrong case is the endpoint puts in a token saying, "record this,"
without the endpoint knowing who will do the recording.  One bad outcome:
the first access network does the recording, and the user has no idea where
their recording is.  That could be quite embarrassing if you happen to be
roaming on the WiFi network of your local gossip magazine.  Another bad
outcome: the first access network and the termination network do the
recording, but *your* network, which never is in the call path, does not do
the recording.  Yet another bad outcome is the outbound proxy has no idea
what the URN is, and by applying loose routing strips the request from the
INVITE, so no recording gets done.


On 5/12/07 6:14 PM, "Dean Willis" <dean.willis at softarmor.com> wrote:

> On Fri, 11 May 2007 20:08:29 -0400
> Paul Kyzivat <pkyzivat at cisco.com> wrote:
> 
>> Certainly it should be fine for the phone to be configured with the
>> server to use.
>> 
>> Using a URN is a tradeoff between need for configuration and need for
>> standardization. By using a standard URN you can avoid the need for
>> configuration, while delegating the job of allocating a particular
>> resource to a proxy.
>> 
>> This is not much different from the use of a service:sos URN for
>> emergency calling. In that case we are using standardization to allow
>> delegation of the selection of the PSAP to a proxy.
>> 
>> It does have some of the same issues as service identification. But at
>> least it is not e2e. It is a contract between you and your provider.
> 
> yes, but which provider? Even in a "simple" user->originating
> provider->terminating provider->user model, there's a question of which
> "provider" executes on the URN, and what happens if the two providers have
> conflicting efinition of the URN.
> 
> When there is a many-layer model, with possibly remote service invocations, it
> gets complicated.
> 
> The URI model doesn't have this, since it explicitly indicates WHO the service
> should be provided by.
> 
> My guess is that the URN model only works for a few services of global
> significance, like emergency calling.
> 
> --
> Dean
> 
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors at cs.columbia.edu for questions on current sip
> Use sip at ietf.org for new developments of core SIP


Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.


_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sip at ietf.org for new developments of core SIP