[SR-Users] SIP Recorder

[rabs at dimension-virtual.com]

Danny Dias <ing.diasdanny at gmail.com> escribió:

> Many thanks Jaremya,
>
> The main problem is that both terminals, SHALL (required and must not be
> changed, because of standards of EUROCAE ED-137 Part3) initiate a session
> with the recorder server (a commercial one, can't use Asterisk for my
> disgrace) sending INVITE and receiving the subsequent responses from sip
> recording server to stablish the session with it...after this, when the
> media starts to go directly peer to peer (the normal call), the terminals
> (specials ones) must summarize the IN+OUT audio to the recording server and
> through rtsp the media should be recorded...it's weird, but thats the
> requirement :S
>
> 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
>
> Then, The audio will go directly from A to B (because of the normal
> procedures), and also, A and B, will summarize IN+OUT on each site and send
> this result through RTSP to the recording server (this is not important to
> the proxy righ not)...My real doubt is how to stablish the session between
> the peers A and B to the recording server through the Proxy and also (at the
> same time) continue with the normal flow of the call (invite from a to b,
> 200 ok viceversa etc etc...)
>
> Should i use some function like t_replicate to send 2 invites like this:
>
> A --INVITE--> PROXY --INVITE--> B
>                          .
>                          . INVITE
>                          .
>              RECORDER SERVER
>
>
> But the problem here is that the session between A and PROXY would be OK,
> but i can't see the way how B should send INVITE to the recorder server..
>
> I hope to be clear on my problem :( and i know it looks very weird, but it's
> the requirement of the document mentioned above

But tha's not a SIP flow for a call stablishment ... it seems more  
like a conference service, than a call service.

How does B know that A wants to talk with him? ... It doesn't know

Also, no matter if they are "special" SIP terminals, because you say  
that the will "sumarize IN+OUT and send it to the record server" ...  
dear sir ... that's not SIP compliant at all!


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.