SIP with Connection preservation 1

[DirectelTech]

Good day, help required please.

I have a single line on my IP Office 9.0.12 that registers 27 accounts (Needed this way because of the way the SIP ISP presents calls)

My current issue is that ocassionally one of the accounts does not receive the 200 OK message for SIP registration back.

The IP Office see this as a failed registration attempt, puts the line out of service and sets a back off timer of 30 seconds to register and enables Media Preservation on the trunk. In theory this is great so the line goes out of service for a few seconds but the calls continue, nice way to handle a SIP registration failure.

However what I am finding is that due to the fact that the client talks for ages, the calls that get flagged with media preserved do not get unflagged whe the SIP line restores, and then after a variable time the IP Office dumps all the calls on the trunk as it thinks it is out of service.

I have tried:
- Changing SIP reg to TCP (Firewall seems to block these)
- Creating multiple lines (Calls dont route in because IPO looks at the first line to the SIP ISP)
- Changing SIP reg time to large number eg 720 (12 Hours).

SIP ISP says the IPO is being way to sensitive and the odd packet loss is to be expected as it is UDP. Is there any hidden Avaya way to allow the trunk to go out of preserved state as soon as the trunk is re-registered. Or a way that a call will not diconnect until RTP stops?

Any ideas will be really appreciated as I am at a loss.

Thanks in advance

 

[DirectelTech]

Hi there and a happy new year to all.

My issue that I have is UDP is not a guaranteed delivery protocol, and the odd packet does do astray, so why does the Avaya put the line into preservation state until it retries again a bit later. If it is expecting an response from the registering server, and does not receive it, then resend the request.

The problem with the preservation state is that all functionality is removed from the handset, this is realy not good on a busy call centre.

With regards to Stun Servers, my sites carry live IP addresses, so there is no need sor the stun. We do this to get rid of any of the funnies that crop up with NAT.

Cheers

 

[hairlessupportmonkey]

you have your IP Office public facing? Please say it aint so?

SIP was designed to work with NAT.

Here are my tips.

1) Employ an SBC
2) Get an ISP that can offer some voice assurance, or provision part of their connection for voice to your ITSP
3) Packet loss really shouldnt be an issue unless its heavy loss, however any packet loss on a mission critical connection really should be taken up with the ISP.



ACSS - SME
General Geek