Genesys SIP Problem

[PP]

I am using Genesys SIP server and I have a problem with calls getting stuck in Stream Manager.

Here is the a sample of the log showing call not being released properly:

sipcs: -party [9401@01eaaad8:0]
18:37:22.171  -- deleted aTmParty 01EAAAD8
18:37:22.171  -- RemoveParty 9401.01EAAAD8-02A6D9B8:1
18:37:22.171  -- call leg removed leg_id=2
18:37:22.171  -- deleted party_info_tspp 01E9D3F8

[color=green]@18:37:22.1710 [0] 7.5.000.38 distribute_event: message EventReleased
AttributeEventSequenceNumber 00000000000008c3
AttributeTimeinuSecs 171000
AttributeTimeinSecs 1236332242 (18:37:22)
AttributeANI '9002'
AttributeDNIS '9401'
AttributeUserData [727] 00 1C 00 00..
AttributeTransferConnID 00c401aaa8dc3001
AttributeCallUUID '9LVNMD22G55AV0FU0A64A6HVFO00000J'
AttributeConnID 00c401aaa8dc3002
AttributeCallID 2
AttributeCallType 2
AttributeThisDN 'C_SIP_Switch::'
@18:37:22.1710 [ISCC] Debug: Translate: '9002' -> ''; result 1 ()
@18:37:22.1710 [ISCC] Debug: Party object is removed: p:0000000000000000,00000000 n::
@18:37:22.1710 [ISCC] Warning: No call is associated with the event, skipped
@18:37:22.1710 [ISCC] Warning: No call is associated with the event, skipped
@18:37:22.1710 [ISCC] Warning: No call is associated with the event, skipped
@18:37:22.1710 [ISCC] Warning: No call is associated with the event, skipped[/color]

SIP server version is 7.5.0.38

What am I doing wrong?

[Fra]

We can't say anything just looking at the very last message; please zip and upload the full trace of the call.

Fra

[Timur Karimov]

hmm, why u r bother about it? it's jast be an warning/informational message. had any problem? then seek error message.

[victor]

PP,

I will be a mind-reader here, and guess:

this is an original call that was put on hold while agent was originating call transfer to a different site, right?
You also have an HA environment, using Windows NLB, right? Your call original call gets stuck in Stream Manager after HA switchover that causes SIP T-Server to mysteriously drop your calls, yet ignoring to send BYE to call still parked on Stream Manager.

Am I right?

Here is why I am thinking this:
AttributeCallType  2
AttributeThisDN  'C_SIP_Switch::'

Obviously an inbound call that is on hold because AttributeTransferConnID attribute.
It is a multi-site related call, because ThisDN is starting with a switch (I am guessing here... but still)

And it has switched because you have
18:37:22.1710 [ISCC] Warning: No call is associated with the event, skipped

which we have experienced when backup T-Server becomes active and tries to match SIP with ConnIDs and Agent States, only to find that it is missing some pairs, causing NON-SYNC disconnect.

If I am right my best advice would be to actually upgrade. This cannot be saved...At least not in any way that I know off...

And, please, please, please, make sure that next time you post more of the log, since it will take a lot of guess work out of this

Best regards,
Vic

[JTL]

[quote author=victor link=topic=3936.msg17292#msg17292 date=1236843738]
PP,

I will be a mind-reader here, and guess:

this is an original call that was put on hold while agent was originating call transfer to a different site, right?
You also have an HA environment, using Windows NLB, right? Your call original call gets stuck in Stream Manager after HA switchover that causes SIP T-Server to mysteriously drop your calls, yet ignoring to send BYE to call still parked on Stream Manager.

Am I right?

Here is why I am thinking this:
AttributeCallType   2
AttributeThisDN   'C_SIP_Switch::'

Obviously an inbound call that is on hold because AttributeTransferConnID attribute.
It is a multi-site related call, because ThisDN is starting with a switch (I am guessing here... but still)

And it has switched because you have
18:37:22.1710 [ISCC] Warning: No call is associated with the event, skipped

which we have experienced when backup T-Server becomes active and tries to match SIP with ConnIDs and Agent States, only to find that it is missing some pairs, causing NON-SYNC disconnect.

If I am right my best advice would be to actually upgrade. This cannot be saved...At least not in any way that I know off...

And, please, please, please, make sure that next time you post more of the log, since it will take a lot of guess work out of this

Best regards,
Vic








[/quote]
Victor,

I'm interested to hear more about the problems you've had with NLB / HA and how you've overcome them...

[victor]

TLB:

well, here I was just analyzing the log (or tiny fragment from it) and I just shared what I thought was the reason for the problem.

The problem like this is inherent to pre-7.6 version of SIP T-Server, because it fails to correctly synchronize the data between primary and backup servers. The only way to fix it would be to actually upgrade.

As for NLB/HA, what exactly woudl you like to know? I have spent the last three years on pretty much rolling it out left and right and I still hate the way it handles switch-overs.

[JTL]

[quote author=victor link=topic=3936.msg17812#msg17812 date=1238585369]
TLB:

well, here I was just analyzing the log (or tiny fragment from it) and I just shared what I thought was the reason for the problem.

The problem like this is inherent to pre-7.6 version of SIP T-Server, because it fails to correctly synchronize the data between primary and backup servers. The only way to fix it would be to actually upgrade.

As for NLB/HA, what exactly woudl you like to know? I have spent the last three years on pretty much rolling it out left and right and I still hate the way it handles switch-overs.






[/quote]


Victor, I understand that "later" version of the SIP server allow the HA information to be relayed directly between the servers themselves, which is an architectural change which may be beneficial.

Regarding the NLB/HA question - I wondered if you'd replaced the NLB with anything else.

[siddharth.taneja]

Hi There,

The issue of calls getting stuck in the stream manager is related to SIP TServer. If the call completion message does not reach the stream manager from SIP TServer, it will continue recording.

It can be rectified by upgrading the SIP TServer to 7.6.000.70.

You can refer to the release notes of the above mentioned SIP TServer.

Regards.
Siddharth.