[SR-Users] SIP Recorder

Stefan Sayer stefan.sayer at googlemail.com
Thu Jan 27 15:51:00 CET 2011


o rabs at dimension-virtual.com on 01/27/2011 01:13 PM:
> Danny Dias <ing.diasdanny at gmail.com> escribió:
> 
>> Hi Iñaki,
>>
>>
>> 2011/1/27 Iñaki Baz Castillo <ibc at aliax.net>
>>
>>> 2011/1/26 Danny Dias <ing.diasdanny at gmail.com>:
>>> > i mean....
>>> > signaling: A---->PROXY---->B (the normal procedure)
>>> > At the same time, this must be done: (I'm not sure how to do 
>>> this...the
>>> > proxy could be out of this or not, not sure :()
>>> > A ---INVITE---> SIP_PROXY ---INVITE---> SIP_RECORDER
>>> > B ---INVITE---> SIP_RECORDER --INVITE--> SIP_RECORDER
>>>
>>
>>  B ---INVITE---> SIP_PROXY --INVITE--> SIP_RECORDER
>>
>> Each peer must send an INVITE to the sip_recorder server, to stablish a
>> session with it...
> 
> So ... if each UAC send an INVITE to the SIP-RECODER ... where is the 
> problem? ... the RTP will be from UAC A to SIP-RECORDER .. that's all. 
no, I think what he wants is in the proxy to intercept the call which 
is from UAC A to UAC B, and place two additional calls to his 
SIP-RECORDER, which should transmit both signaling and RTP to the 
SIP-RECORDER.

To the OP: this is IMO not possible to do properly in a SIP proxy, 
even if its as flexible as s-r; while you can replicate the initial 
INVITE to the SIP-RECORDER, and even change the RTP media address in 
the SDP in order to make RTP go through rtpproxy, which might be 
modified to send a copy of the traffic to your SIP recorder, I really 
doubt that you can change the 200 to establish another INVITE to the 
SIP-RECORDER, let alone that you need to process the responses to the 
INVITEs to SIp-RECORDER, generate ACKs, handle in-dialog requests 
(e.g. session timer, hold etc etc).

For this stuff you need a SIP app server/B2BUA/media server, which has 
two dialogs on each side, and another two dialogs to the SIP-RECORDER. 
You might possibly be interested in SEMS' sbc module (shameless ad ;), 
latest development features RTP relay, you might be able to change it 
to create two more dialogs to SIP-RECORDER, using the original 
signaling, and relay the RTP also there. If that doesn't suit you, 
possibly you could have a look at implementing this using pjsip, 
freeswitch, asterisk (maybe in that order, depending on how 
transparent the thing in the middle should be). An alternative is to 
use s-r proxy and rtpproxy, and add some custom app server (again 
built possibly with sems/pjsip/freeswitch etc), which somehow gets 
signaling and RTP traffic from s-r/rtpproxy and sends them into two 
separate calls which are established to SIP-RECORDER. This type of 
stuff is usually implemented for LI (which hopefully we all don't 
like) and has further requirements regarding being transparent etc.

hth
Stefan


-- 
Stefan Sayer
VoIP Services Consulting and Development

Warschauer Str. 24
10243 Berlin

tel:+491621366449
sip:sayer at iptel.org
email/xmpp:stefan.sayer at gmail.com





More information about the sr-users mailing list