o rabs@dimension-virtual.com on 01/27/2011 01:13 PM:
Danny Dias ing.diasdanny@gmail.com escribió:
Hi Iñaki,
2011/1/27 Iñaki Baz Castillo ibc@aliax.net
2011/1/26 Danny Dias ing.diasdanny@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