Re: [dispatch] Session recording in SIP

[Alan Johnston <[e-mail]>]

These various models and modes of recording are described in

      http://tools.ietf.org/html/draft-wing-sipping-srtp-key-04#section-5

To summarize some of the arguments for forking the media in the middle 
as opposed to doing it in an endpoint:

1.  Requirements to use basic UAs without any extensions
2.  Not always having double the media bandwidth in endpoints, 
especially when they are remote
3.  The recording mode (always on, on demand, required, pause and 
resume) and policy is usually controlled centrally, and so another 
protocol would be needed to tell the UA to start and stop recording.

Thanks,
Alan

James M. Polk wrote:
> At 06:11 PM 6/11/2009, Paul Kyzivat wrote:
>
>
>> Hadriel Kaplan wrote:
>>> Hey Roni,
>>> Being a middlebox man myself, a B2BUA doing the media forking makes 
>>> the most sense to me too, but some other folks don't do it/want-it 
>>> that way.  So the proposed work is to cover both potential models.
>>> The statement you cite reflects the belief that the solution to the 
>>> requirements will be to use SIP between the UA doing the media 
>>> forking, and the recorder doing the collection; and that the work of 
>>> specification will be to define that.
>>> So one diagram could be this, where "TBD" is the To-Be-Defined work:
>>>    +-----+              +-----+
>>>    |     |   Call       |     |
>>>    |UA-A +<------------>+UA-B |
>>>    |     |              |     |
>>>    +-++--+              +-----+
>>>       \\
>>>        \\
>>>     TBD \\
>>>          \\+----------+
>>>           \+          |
>>>            + Recorder |
>>>            |          |
>>>            +----------+
>>
>> This model actually can make a lot of sense in *some* circumstances.
>> For instance, in a call center, where you may have control over what 
>> components are used throughout, it could make sense to do the media 
>> forking for recording and monitoring right at the agent phone.
>
> Paul - how is your call center example *not* better accomplished with 
> the figure below instead of the figure above?
>
> It seems to me that any enterprise based call center would have to 
> have a SIP server of some form (i.e., the caller is not going to have 
> a pt-to-pt SIP established session directly with a call center call 
> taker). It seems much easier if that call center wants to record calls 
> (even some of the calls, that to the caller, the B2BUA is the UAS, 
> meaning the sRTP keys only have to be between the caller and the 
> B2BUA, and not all the way to the call taker.  In this scenario, the 
> B2BUA merely replicates the RTP stream out towards the recording 
> device with RTCP in tact, an can allow the B2BUA provide any meta data 
> about the specifics of the call signaling it wants to also store.
>
> This scenario also means the caller is never aware the call is being 
> recorded, creating anonymity wrt that facet of the solution.
>
> I'm not advocating B2BUAs here, I just see this as a better solution 
> for call center type recording than pt-to-pt between caller and call 
> taker.
>
>
>> But in those sorts of monitoring/recording we don't talk about in 
>> IETF, its essential that the recorded parties not be able to 
>> distinguish calls that are monitored from those that are not. 
>> Anything that requires cooperation by one of the endpoints is a 
>> no-go. Even something as simple as a middlebox replacing one media 
>> port with another in order to initiate monitoring might be enough to 
>> clue in the monitored parties. So  in those cases you had better have 
>> a way that looks exactly the same whether recording is happening or 
>> not, which generally requires something like your picture below.
>>
>>         Thanks,
>>         Paul
>>
>>> Or this:
>>>
>>> +-----+              +-----+              +-----+
>>> |     |     Call     |     |   Call       |     |
>>> |UA-A +<------------>+B2BUA+<------------>+UA-B |
>>> |     |              |     |              |     |
>>> +-----+              +-++--+              +-----+
>>>                         \\
>>>                          \\
>>>                       TBD \\
>>>                            \\+----------+
>>>                             \+          |
>>>                              + Recorder |
>>>                              |          |
>>>                              +----------+
>>> -hadriel
>>>
>>>> -----Original Message-----
>>>> From: Roni Even [mailto:[e-mail]]
>>>> Sent: Thursday, June 11, 2009 3:54 PM
>>>> To: Hadriel Kaplan; 'Hutton, Andrew'; 'Alan Johnston'; 'Romascanu, Dan
>>>> (Dan)'
>>>> Cc: 'Leon Portman'; [e-mail]; 'Jain, Rajnish'
>>>> Subject: RE: [dispatch] Session recording in SIP
>>>>
>>>> Hadriel,
>>>> I am still confused by the following text which was the reason for the
>>>> previous question
>>>>
>>>> "This group will specify requirements for a SIP based protocol 
>>>> interface
>>>> between a communications system and a recorder. The Communications 
>>>> System
>>>> is
>>>> responsible for establishing media sessions where the actual 
>>>> business is
>>>> conducted. The Recorder is the sink of the recorded media."
>>>>
>>>>
>>>> Can someone draw a figure showing the talking parties the 
>>>> Communication
>>>> system and the recorder and explain where is this interface. 
>>>> According to
>>>> your response I can think that there are at least two separate
>>>> architectures
>>>> your are proposing one where the parties (or one of them) in the 
>>>> call know
>>>> the recorder and somehow forwards the media to it. The other 
>>>> architecture
>>>> has some B2BUA in the call path who is either forking the media to the
>>>> recorder and to the parties or the recorder is in the middle of the 
>>>> media
>>>> path.
>>> _______________________________________________
>>> dispatch mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/dispatch
>> _______________________________________________
>> dispatch mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dispatch
>
> _______________________________________________
> dispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch
>