As said, SER is not the best vehicle for that as it in its SIP proxy definition
does not process media. SEMS does this (recording, mixing, storing....) quite
decently. I'm just wondering what is the reason that Asterisk can't be used --
perhaps SEMS would fail that criteria as well.

-jiri

On 1/26/11 6:43 PM, Danny Dias wrote:
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

Thanks in advance!!!



2011/1/26 <r...@dimension-virtual.com <mailto:r...@dimension-virtual.com>>

    Danny Dias <ing.diasda...@gmail.com <mailto:ing.diasda...@gmail.com>> 
escribió:

        Thanks Jeremya, but it's a requeriment from the client to record the 
calls
        through an external server and not with rtpproxys, my question is how 
the
        media should be handled in order to record the conversations if the 
server
        is external?

        Signaling: Phone_A <---> Proxy <---> Phone_B

        Media: Phone_A <---> SIP RECORDER <---> Phone_B (Changing the SDP 
headers to
        send RTP to the IP of the SIP RECORDER). The main problem is that the
        recording must be made in ACTIVE way, it means, we should record 
(IN+OUT) in
        Phone A, and the same in B, 2 recording for each call...the customer 
says
        that it's working now in his arquitecture (its analog), and we made the 
same
        with the IP technology...resuming: with a sip recorder in the middle of 
the
        media should work right?



    2 ways of doing that:

    a)
    Signaling: A <-> Proxy <-> B2BUA (recorder) <-> B
    Media: A <-> B2BUA <-> B

    b) Prefered way
    Signaling: A <-> Proxy <-> B
    Media: A<-> RTPPROXY <-> B

    At the end, both solutions are THE SAME, what you do is to tell A to send 
media to the B2BUA or the RTPPRoxy.

    As a matters of scale ... b) solution is the best one.

    Also, another things to take into account are:

    1- Transcoding issues (RTPPRoxy does not do transconding, not easly)
    2- Secured RTP (ZRTP, SRTP, etc.)
    3- LAG in audio.



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


    _______________________________________________
    SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
    sr-users@lists.sip-router.org <mailto:sr-users@lists.sip-router.org>
    http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users






_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Reply via email to