SIP protocol retransmissions

[Alexander Litvak]

I am having issue with false alarms when monitor SIP server.

Monit complains with this error

Connection failed Service xbroker 

    Date:        Wed, 11 Jun 2014 17:19:00
    Action:      alert
    Host:        node2cl2-chi.siptalk.com
    Description: failed protocol test [SIP] at INET[node2cl2-chi.siptalk.com:[e-mail]] via UDP -- SIP: error sending data -- No route to host

Your faithful employee,
Monit

However server is alive, well, and not under the high load. I see it receiving and sending calls.

My question is how monit determines if connection using SIP failed? I ran a tcpdump capture and I see that monit sends 4 SIP Option packets almost simultaneously on each monitor action. What is the reason for sending 4 packet at once? Does your code decide if 4 packets received responses than it is OK and if 3 or less received responses then it is NOT OK?

IMO, It doesn't make sense from the SIP perspective. It makes sense to retransmit or just rely on users settings for timeout and retry in the same cycle.

Below is an example of one cycle of SIP protocol monitor.

09:22:54.229671 IP cluster-phip.54767 > cluster-phip.sip: SIP, length: 379
E.....@.@...&lx$&lx$......>.OPTIONS sip:[e-mail] SIP/2.0
Via: SIP/2.0/UDP 38.108.120.36:54767;branch=z9hG4bKh878249217;rport
Max-Forwards: 1
To: <sip:[e-mail]>
From: monit <sip:monit@38.108.120.36>;tag=1339649344
Call-ID: 1577039923
CSeq: 63104 OPTIONS
Contact: <sip:38.108.120.36:54767>
Accept: application/sdp
Content-Length: 0
User-Agent: monit/5.9


09:22:54.229699 IP cluster-phip.54767 > cluster-phip.sip: SIP, length: 379
E.....@.@...&lx$&lx$......>.OPTIONS sip:[e-mail] SIP/2.0
Via: SIP/2.0/UDP 38.108.120.36:54767;branch=z9hG4bKh878249217;rport
Max-Forwards: 1
To: <sip:[e-mail]>
From: monit <sip:monit@38.108.120.36>;tag=1339649344
Call-ID: 1577039923
CSeq: 63104 OPTIONS
Contact: <sip:38.108.120.36:54767>
Accept: application/sdp
Content-Length: 0
User-Agent: monit/5.9


09:22:54.229719 IP cluster-phip.54767 > cluster-phip.sip: SIP, length: 379
E.....@.@...&lx$&lx$......>.OPTIONS sip:[e-mail] SIP/2.0
Via: SIP/2.0/UDP 38.108.120.36:54767;branch=z9hG4bKh878249217;rport
Max-Forwards: 1
To: <sip:[e-mail]>
From: monit <sip:monit@38.108.120.36>;tag=1339649344
Call-ID: 1577039923
CSeq: 63104 OPTIONS
Contact: <sip:38.108.120.36:54767>
Accept: application/sdp
Content-Length: 0
User-Agent: monit/5.9


09:22:54.229738 IP cluster-phip.54767 > cluster-phip.sip: SIP, length: 379
E.....@.@...&lx$&lx$......>.OPTIONS sip:[e-mail] SIP/2.0
Via: SIP/2.0/UDP 38.108.120.36:54767;branch=z9hG4bKh878249217;rport
Max-Forwards: 1
To: <sip:[e-mail]>
From: monit <sip:monit@38.108.120.36>;tag=1339649344
Call-ID: 1577039923
CSeq: 63104 OPTIONS
Contact: <sip:38.108.120.36:54767>
Accept: application/sdp
Content-Length: 0
User-Agent: monit/5.9


09:22:54.229873 IP cluster-phip.sip > cluster-phip.54767: SIP, length: 304
E..L..@.@..d&lx$&lx$.....8>jSIP/2.0 200 OK
Via: SIP/2.0/UDP 38.108.120.36:54767;branch=z9hG4bKh878249217;rport=54767
From: "monit" <sip:monit@38.108.120.36>;tag=1339649344
To: <sip:[e-mail]>;tag=xcast-140717294995568
Call-ID: 1577039923
CSeq: 63104 OPTIONS
Server: XCast Carrier/1.0
Content-Length: 0


09:22:54.230039 IP cluster-phip.sip > cluster-phip.54767: SIP, length: 304
E..L..@.@..c&lx$&lx$.....8>jSIP/2.0 200 OK
Via: SIP/2.0/UDP 38.108.120.36:54767;branch=z9hG4bKh878249217;rport=54767
From: "monit" <sip:monit@38.108.120.36>;tag=1339649344
To: <sip:[e-mail]>;tag=xcast-140717294995568
Call-ID: 1577039923
CSeq: 63104 OPTIONS
Server: XCast Carrier/1.0
Content-Length: 0


09:22:54.230233 IP cluster-phip.sip > cluster-phip.54767: SIP, length: 304
E..L..@.@..a&lx$&lx$.....8>jSIP/2.0 200 OK
Via: SIP/2.0/UDP 38.108.120.36:54767;branch=z9hG4bKh878249217;rport=54767
From: "monit" <sip:monit@38.108.120.36>;tag=1339649344
To: <sip:[e-mail]>;tag=xcast-140717294995568
Call-ID: 1577039923
CSeq: 63104 OPTIONS
Server: XCast Carrier/1.0
Content-Length: 0


09:22:54.230407 IP cluster-phip.sip > cluster-phip.54767: SIP, length: 304
E..L.!@.@.._&lx$&lx$.....8>jSIP/2.0 200 OK
Via: SIP/2.0/UDP 38.108.120.36:54767;branch=z9hG4bKh878249217;rport=54767
From: "monit" <sip:monit@38.108.120.36>;tag=1339649344
To: <sip:[e-mail]>;tag=xcast-140717294995568
Call-ID: 1577039923
CSeq: 63104 OPTIONS
Server: XCast Carrier/1.0
Content-Length: 0

[Alexander Litvak]

I couldn't find any other information on the Internet or general mailing list.

Perhaps this bug returned ?

* Fix bug #32583: Multiple SIP OPTIONS messages use the same header
  data.  Thanks to Hugh Waite for patch.

But I most likely mistaken.

[Tildeslash]

Do you have a SIP server we can test? (it has been a long time since we tested SIP and the test server we used seems to be offline). Also provide the exact check host statement you use. You can send this information to [e-mail] with subject SIP-test

[Alexander Litvak]

Information you requested including configuration file has been sent you e-mail you provided.

[Alexander Litvak]

Hi, could you test with the SIP server I provided?

[Tildeslash]

I tried to test against your server now, but it appears to be down? We have removed the retransmit scheme and improved timeout handling which should improve UDP protocol testing much. However your original problem seems to be related to routing in some way and if so, it is not really a Monit problem per se. If you continue to have this or other SIP problems let us know otherwise will close this issue in a day or two.

[Tildeslash]

Changes to UDP w/r to retransmit and timeout seems to fix any problem with the SIP test.

[Tildeslash]

Removing version: 5.8.1 (automated comment)