Concerns using SM for recording

[victor]

Guys, the more I look into SM for recording, the more uncomfortable I get with the concept. In order to use SM for recording, alll of the conversations have to stream through that SM. So, if for some reasons, SM decides to go south for the winter, every conversation streamed through that SM would just abruptly end, with all the participants hearing the sweet sound of silence.

[attachimg=1]
I am certain Genesys thought of this; however, I cannot find any information on how to avoid SM from becoming call center's Achille's Heel. Any ideas?

[David Starnes]

I was concerned with this as well. To mitigate the issue, I have installed 4 SMs and spread the load. Over time i expect add additional SMs and spread the load further. In the event that a machine failes, I will limit my total loss.

[Timur Karimov]

Hi all

Viktor, don't panic =) It's picture jast not so realistic =) Schema on it not show main rtp stream between GW and internal abonent. And so if SM goes down u jast lose the recording function, but not a rtp strewm between GW and extension.

WBR Timur I. Karimov

[victor]

Timur,

I think you are wrong, because all RTP packets are send to SM from GW and from SM then they are mirrored to all end-points. At least this is my understanding. Am I totally wrong?

I know that SIP had build in redundancy, but I am not seeing any sort of mention of redirecting packets should SM go down in the manual anywhere. What am I missing?

Vic

[Timur Karimov]

[quote author=victor link=topic=3260.msg14008#msg14008 date=1222395999]
Timur,
I think you are wrong, because all RTP packets are send to SM from GW and from SM then they are mirrored to all end-points. At least this is my understanding. Am I totally wrong?
Vic
[/quote]

ok.same time ago , when we thinking about it , we read and check all documents and not found answer for this questen. and we build the test site, install on all pc and servers network packet snifer and jast cupture all network traffic before, in the time to shutdown sm and after. and i told u - evry time then external abonent call to internal operator, and this operator extension has record enabled - evry time we see double rtp traffic from gw to extension, and from gw and extension to sm.

[Timur Karimov]

going check it again:
"Call recording does not change call topology in the SIP Server" - it's completely true
"When call recording is started, SIP Server creates two new SIP dialogs with Stream Manager.  SIP Server then re-INVITEs call participants with the SDP from the Stream Manager" - checked too and it's completely true
"As a result, RTP stream between call participants is passed via the Stream Manager. " - let's check it again.

[Marco64]

[quote author=victor link=topic=3260.msg14008#msg14008 date=1222395999]
I know that SIP had build in redundancy, but I am not seeing any sort of mention of redirecting packets should SM go down in the manual anywhere. What am I missing?

Vic
[/quote]

altough TServer / SIP Server can support redundancy (backup in hot standby) SM doesn't. We use this mostly for messages and knowing this deploy one (or two) more just in case one goes off. But all are Primary and not supporting redundancy. 

[kowari]

Yes, Genesys know this is an issue. 
I have not seen a resolution to the issue as yet (possibly because there has not been customer demand for one)

Basically, SM is an endpoint, so if SM goes down, the end point is effectively disconnected, halting recording, streaming and anything else it is doing at the time.  There is no way I have found yet to rectify this issue for calls in progress, and I actually dont think there IS from a software point of view.  For FAILOVER redundancy, you can do some work with clustering and virtual IPs (did some investigations into this at the start of the year) to ensure that another instance of SM is ready to go (or to loadshare etc etc)

So, for call recording, SIPTserver forks off a leg of the call to SM (effectively a conference).  Therefore, when SM falls over all that stops is the recording leg of the call.  The ACTUAL call is still up and happy, but recording halts at that point.  At least, that is the theory, I have not actually done this myself