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

 

[janni78]

Frankly I would look for another trunk provider, that's no way to build a SIP trunk.

IPO wouldn't think that the trunk is out of service because of one missed packet, something else is causing it, either several missed or your ISP is replying something that makes it go out of service.

"Trying is the first step to failure..." - Homer

 

[amriddle01]

SIP ISP is talking nonsense then, the setup/teardown on SIP is TCP only the voice packets are UDP, so the system should expect and should always receive a 200 OK message for registration, otherwise it has in fact not registered

 

[DirectelTech]

Hi thanks for the reply.

It is in fact the IPO tearing down the calls. And it is the IPO putting the trunk out of service after a single Missed 200 OK message.

In fairness I had disabled Media preservation this morning to see how the IPO would handle it. The only difference with Media Preservation enabled is it only randomly drops the calls immediately.

So my actual question is the trunk did reregister 30 seconds later as per normal, but it still drops the calls.

I am testing a solution with them where they deliver calls in the way the IPO can route the calls as currently the dialed number is delivered in the Diversion Header and not the invite.

This is received after 1 missed 200 OK message:
11:24:32 168673370mS PRN: SIP Line (17) parameter XXXXXXX registration has failed, setting backoff retry timer to 30 secs
11:24:32 168673370mS Sip: SIP Line (17): SetTrunkInService to false
11:24:32 168673373mS Sip: 17.14610.1 1674 SIPTrunk Endpoint(f462a66c) Connection Preservation Allowed
11:24:32 168673373mS CMCallEvt: 17.14610.1 1674 SIPTrunk Endpoint: StateChange: END=A CMCSConnected->CMCSCompleted
11:24:32 168673383mS CMExtnTx: v=5324, p1=0
CMFacility
Line: type=IPLine 250 Call: lid=324 id=14615 in=0
IE CMIEFastStartInfoData (6) 2 item(s)
Timed: 11/10/16 11:24
11:24:32 168673383mS CMExtnTx: v=5324, p1=8073
CMFacility
Line: type=IPLine 250 Call: lid=324 id=50 in=1
IE CMIEFastStartInfoData (6) 2 item(s)
11:24:32 168673387mS CMExtnTx: v=5324, p1=0
CMFacility
Line: type=IPLine 250 Call: lid=324 id=14615 in=0
Timed: 11/10/16 11:24
11:24:32 168673388mS PRN: CDR - TCPSend maxqueuesize=3000 framecount=0 operational=1
11:24:32 168673399mS CMLOGGING: CALL:2016/10/1111:11,00:12:50,010,0114310939@41.XXX.XXX.XXX,I,2401,4106378,,,,0,,""n/a,0
11:24:32 168673400mS CD: CALL: 17.14610.1 BState=Connected Cut=2 Music=0.0 Aend="Line 17" (0.0) Bend="" [Charne S(5324)] (0.0) CalledNum=2401 (Mauritius) CallingNum=0114310939@41.221.232.45 () Internal=0 Time=780277 AState=Idle
11:24:32 168673400mS CD: CALL: 17.14610.1 Deleted
11:24:32 168673400mS Sip: 17.14610.1 -1 SIPTrunk Endpoint(f462a66c) KeepDlgOnCmCallLost SIPDialog::CALL_UP
11:24:32 168673400mS Sip: 17.14610.1 -1 SIPTrunk Endpoint(f462a66c) Terminating dialog f462a66c, state SIPDialog::CALL_UP(16) for cause CMCauseNetworkOOO
11:24:32 168673401mS Sip: 17.14610.1 -1 SIPTrunk Endpoint(f462a66c) BYE SENT TO 41.XXX.XXX.XXX 5060
11:24:32 168673402mS SIP Call Tx: 17
BYE sip:0114310939@41.XXX.XXX.XXX:5060 SIP/2.0
Via: SIP/2.0/UDP 172.18.49.10:5060;rport;branch=z9hG4bK3c70739a5f3a46879a7f91ea264aa718
Route: <sip:41.XXX.XXX.XXX;lr=on>
From: <sip:XXXXXX@41.XXX.XXX.XXX>;tag=a8aa35c23d184dfe
To: "0114310939" <sip:0114310939@41.XXX.XXX.XXX>;tag=as5bceb3e2
Call-ID: 47f9d0996b22ef284b1f6ce8245c4d92@41.XXX.XXX.XXX5:5060
CSeq: 103 BYE
Contact: <sip:XXXXXX@172.18.49.10:5060;transport=udp>
Max-Forwards: 70
Allow: INVITE,ACK,CANCEL,OPTIONS,BYE,INFO,NOTIFY,UPDATE
Supported: timer
Reason: Q.850;cause=16;text="Normal call clearing"
User-Agent: IP Office 9.0.12.0 build 1006
Content-Length: 0

 

[amriddle01]

The IPO should teardown after a missed 200, you shouldn't get a missed 200, it's TCP

 

[DirectelTech]

Hi, the 200 OK is UDP, not TCP??

Protocol: UDP (17)

Via: SIP/2.0/UDP 172.18.49.10:5060;rport=5060;branch=z9hG4bK7c037f4d2485bf463d4801873827a4e5;received=169.255.1.255

 

[amriddle01]

Indeed it is, ignore my mad ramblings

 

[DirectelTech]

LOL - So the question then remains on how to stop the IPO dropping the calls?

 

[janni78]

This is the interesting part

11:24:32 168673370mS PRN: SIP Line (17) parameter XXXXXXX registration has failed, setting backoff retry timer to 30 secs

What SIP messages do you get before this?
It seems like it's trying to renew the registration and that fails.

"Trying is the first step to failure..." - Homer

 

[DirectelTech]

Summarised version: (Sorry Had to remove IP's etc, cant trust these hackers these days)

11:24:27 168668359mS SIP Tx: UDP 172.18.49.10:5060 -> 41.XXX.XXX.XXX:5060
REGISTER sip:XXXXXXX.co.za SIP/2.0
Via: SIP/2.0/UDP 172.18.49.10:5060;rport;branch=z9hG4bK8dd16884050d6bd703ff2c315257f21a
From: <sip:XXXXXXX@XXXXXXX.co.za>;tag=6e1daf5c047bc011
To: <sip:XXXXXXX@XXXXXXX.co.za>
Call-ID: 8906e02f74db01007fe7ed2025f650fd
CSeq: 1585803231 REGISTER
Contact: "Unknown" <sip:XXXXXXX@172.18.49.10:5060;transport=udp>
Expires: 1200
Max-Forwards: 70
User-Agent: IP Office 9.0.12.0 build 1006
Supported: timer
Content-Length: 0

11:24:27 168668367mS SIP Rx: UDP 41.XXX.XXX.XXX:5060 -> 172.18.49.10:5060
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 172.18.49.10:5060;rport=5060;branch=z9hG4bK8dd16884050d6bd703ff2c315257f21a;received=169.XXX.XXX.XXX
From: <sip:XXXXXXX@XXXXXXX.co.za>;tag=6e1daf5c047bc011
To: <sip:XXXXXXX@XXXXXXX.co.za>;tag=a312bca4eace24957a8c8d4097d61ea9.5f85
Call-ID: 8906e02f74db01007fe7ed2025f650fd
CSeq: 1585803231 REGISTER

http://WWW-Authenticate:

Digest realm="XXXXXXX.co.za", nonce="V/yxDlf8r+KoF12qUTegZjLLt55i7nRH"
Server: Telviva SIP proxy
Content-Length: 0

11:24:27 168668372mS SIP Reg/Opt Tx: 17
REGISTER sip:XXXXXXX.co.za SIP/2.0
Via: SIP/2.0/UDP 172.18.49.10:5060;rport;branch=z9hG4bK92f3638ea30700b597ae221c4eb9e92c
From: <sip:XXXXXXX@XXXXXXX.co.za>;tag=6e1daf5c047bc011
To: <sip:XXXXXXX@XXXXXXX.co.za>
Call-ID: 8906e02f74db01007fe7ed2025f650fd
CSeq: 1585803232 REGISTER
Contact: "Unknown" <sip:XXXXXXX@172.18.49.10:5060;transport=udp>
Expires: 1200
Authorization: Digest username="XXXXXXX",realm="XXXXXXXco.za",nonce="V/yxDlf8r+KoF12qUTegZjLLt55i7nRH",response="2702698759eab616159870f4ee5ead85",uri="sip:XXXXXXX.co.za"
Max-Forwards: 70
User-Agent: IP Office 9.0.12.0 build 1006
Supported: timer
Content-Length: 0

11:24:32 168673370mS PRN: SIP Line (17) parameter XXXXXXX registration has failed, setting backoff retry timer to 30 secs

 

[janni78]

So you have your answer right there!

IPO sends REGISTER, gets Unauthorized, sends REGISTER again with Authinfo and doesn't get an answer.
5 seconds later it put the trunk OOS due to registration failure.

"Trying is the first step to failure..." - Homer

 

[janni78]

Or the last SIP Tx might actually be a duplicate since you have both SIP Tx/Rx and SIP Reg/Opt Rx/Tx enabled in Monitor.

"Trying is the first step to failure..." - Homer

 

[DirectelTech]

The normal procedure is :

Reg request
401 - Unauthorised
Reg request (Including Nonce)
200 OK

So I agree that I do not receive the final 200 OK, however the IPO returns a "11:24:32 168673370mS PRN: SIP Line (17) parameter XXXXXXX registration has failed, setting backoff retry timer to 30 secs" and then puts the line into preservation state, that should maintain the call until the next reg attempt.
There is a reg attempt again within the 30 seconds tha was successful.

However it just dropped the call. The IPO should not do this if the line is in preserved state? "11:24:32 168673373mS Sip: 17.14610.1 1674 SIPTrunk Endpoint(f462a66c) Connection Preservation Allowed

 

[janni78]

Well, have you looked at the help for Media Connection Preservation?

Default = Disabled.
When enabled, allows established calls to continue despite brief network failures. Call handling features are no longer available when a call is in a preserved state. Preservation on public SIP trunks is not supported until tested with a specific service provider.

As it states it doesn't mean that it will work with your provider.
I would also assume that it would work a lot better if you have a SBC so you can have direct media.

"Trying is the first step to failure..." - Homer

 

[DirectelTech]

Media connection is enabled, this does help most of the time to keep the calls going. However my client has lengthy conversations very often 30 mins plus.

When watching this on SSA, you see all the calls that were active when the reg failed go into Preserved state. However the IPO does not take them out of preserved state once the trunk is registered again. I cannot find an actual reason why it disconnects these calls randomly, and as said earlier it dumps all calls that are active on the trunk. There does not seem to be a set time before it clears the calls, and I can find no reference to how it treats these calls.

Once the trunk is re-registered all new calls show a status of connected, while the existing calls remain with a status of preserved.

 

[Wallysworld]

Was there a resolution to this?
Also:

"The normal procedure is :

Reg request
401 - Unauthorised
Reg request (Including Nonce)
200 OK"

IS this the normal procedure for all SIP registration requests?

Battling with the million different variables of SIP now... missing the copper days... plug it in... (1)"HEY it works!" or (2)"Damn Bell!

 

[DirectelTech]

No never got an answer for this, if the Avaya misses a single packet it goes into preservation state

 

[mattKnight]

The
Register
401 unauthorised
Register
200 OK

Is a standard registration conversation where the trunks are authenticated by a password.
The 401 error back from the provider provides a nonce challenge which is sued to encrypt the password information in the second register request


The final (missing) 200 OK from the provider signifies that the regist ration is complete. If the IPO doesn't receive it, why would it assume the registration has done anything other that fail?

Take Care

Matt
I have always wished that my computer would be as easy to use as my telephone.
My wish has come true. I no longer know how to use my telephone.

 

[Wallysworld]

Thanks Matt.

 

[hairlessupportmonkey]

You will often get the call re-presented without the 200 OK acknowledgement.

Have you considered using a STUN server to ensure the public IP is written in the SIP headers correctly?

ACSS - SME
General Geek