SIP NOTIFY (Event: check-sync) not relaying to UA

cphillips.ia · Post by **cphillips.ia** » Fri May 29, 2015 10:37 am

1. Brekeke Product Name and Version:
Brekeke SIP Server 3.4.5.1/410

2. Java version:
1.6.0_32

3. OS type and the version:
Debian Wheezy 64bit

4. UA (phone), gateway or other hardware/software involved:
Polycom Phones, Asterisk PBX

5. Your problem:
SIP NOTIFY Event: check-sync packets issued from PBX (to reboot UA) are not being relayed. Packet sent from PBX stops at the SIP Server. My rule for packets from the PBX to UA's is pretty wide open, so I am scratching my head here... Please take a look as I must be missing something. Thanks!

I will post my rule below (again this is only the FROM PBX to UA rule) I should also note that all other functionality works with this configuration

Code: Select all

Matching Patterns:
$addr=x.x.x.x (PBX address)
To=sip:(.+)@

Deploy Patterns:
To=sip:%1@domain.com (domain matching thru registration domain)

ambrosio · Post by **ambrosio** » Fri May 29, 2015 1:08 pm

There are two types of NOTIFY messages. NOTIFY inside of a dialog or outside of a dialog.
If there is a SUBSCRIBE prior to NOTIFY, the NOTIFY may share the same Call-ID as an inside of the SUBSCRIBE's dialog. If so, DialPlan can not catch this NOTIFY.

Let you check SUBSCRIBE and NOTIFY's Call-ID.

cphillips.ia · Post by **cphillips.ia** » Fri May 29, 2015 1:11 pm

There would be no SUBSCRIBE related to this NOTIFY as it is generated on the PBX as means to prompt the phone to reboot.

cphillips.ia · Post by **cphillips.ia** » Fri May 29, 2015 1:18 pm

Quick Update...

Looking at the PBX logs, Asterisk seems to think BSS does not support NOTIFY at all

[2015-05-29 16:15:51] WARNING[663]: chan_sip.c:20568 handle_response: Host 'x.x.x.x:5060' does not implement 'NOTIFY'

ambrosio · Post by **ambrosio** » Fri May 29, 2015 1:23 pm

Are there any response sent from the Brekeke SIP Server to NOTIFY?
You can check the error response code in the [Error Logs] page after you set "INVITE Only=off".

Can you find NOTIFY sender's IP address (PBX's IP address) under the [Blocked IP Address] list?

ambrosio · Post by **ambrosio** » Fri May 29, 2015 1:29 pm

Your DialPlan rule requires a "userinfo" part of To's SIP-URI.
Does NOTIFY meet this requirement?

Brekeke SIP Server can accept NOTIFY but your DialPlan and Asterisk's NOTIFY doesn't match.

cphillips.ia · Post by **cphillips.ia** » Fri May 29, 2015 5:31 pm

ambrosio wrote:Are there any response sent from the Brekeke SIP Server to NOTIFY?
You can check the error response code in the [Error Logs] page after you set "INVITE Only=off".

Can you find NOTIFY sender's IP address (PBX's IP address) under the [Blocked IP Address] list?

There is no response at all sent from BSS

There are no errors present in the logs

The PBX is not in the block list and functions for INVITE events, SUBSCRIBE / NOTIFY (MWI BLF and such), etc perfectly..

Your DialPlan rule requires a "userinfo" part of To's SIP-URI.
Does NOTIFY meet this requirement?

Request-Line: NOTIFY sip:120@x.x.x.x:5060 SIP/2.0

To: <sip:120@x.x.x.x:5060>

... So userinfo is there

Brekeke SIP Server can accept NOTIFY but your DialPlan and Asterisk's NOTIFY doesn't match.

I am not sure what could be wrong with it, it looks like it should match that rule. I am sure I am missing something...

ambrosio · Post by **ambrosio** » Fri May 29, 2015 9:13 pm

It is strange..

Did you capture packets to confirm that NOTIFY reaches the SIP server?

Enable the logging. It may provide a clue.
http://wiki.brekeke.com/wiki/log-SIP-packets

cphillips.ia · Post by **cphillips.ia** » Sat May 30, 2015 3:44 am

ambrosio wrote:It is strange..

Did you capture packets to confirm that NOTIFY reaches the SIP server?

Enable the logging. It may provide a clue.
http://wiki.brekeke.com/wiki/log-SIP-packets

Yes, I am capturing the packets @ the BSS server.

Would logging the SIP packet with BSS provide any more info than tcpdump? If so I will look into that on Monday...

Thanks for all the effort!

taitan · Post by **taitan** » Sat May 30, 2015 10:25 pm

SIP server's log will provide more info such as internal activities .

cphillips.ia · Post by **cphillips.ia** » Wed Jun 17, 2015 5:35 am

Sorry for the slow reply, this had to go on the back burner for a bit...

I set log levels to 255 as described in the Wiki article (which is extremely verbose), but there appears to be no record of the NOTIFY packets in the log. This is strange since the packets are definitely making it there as they are represented in the tcpdump.

Even if BSS did not know how to handle them they should still be in the log at that level... correct?

Again, thanks for the help on this!

taitan · Post by **taitan** » Wed Jun 17, 2015 10:15 am

The log setting "net.listener.loglevel.file=255" will write all of received SIP packets into the log file...

Is the SIP server running on the port 5060?
Does the sender client send NOTIFY to the port 5060?
Which transport is it ? UDP? or TCP?

cphillips.ia · Post by **cphillips.ia** » Wed Jun 17, 2015 10:43 am

taitan wrote:The log setting "net.listener.loglevel.file=255" will write all of received SIP packets into the log file...

Is the SIP server running on the port 5060?
Does the sender client send NOTIFY to the port 5060?
Which transport is it ? UDP? or TCP?

Yes, all of the packets are there in the log except the NOTIFY... The tcpdump (from the BSS) picks them up though and there is nothing that would prevent them from getting through.

Yes
Yes
UDP

INVITE and OPTION packets are passing just fine. This system works completely (MWI and BLF and all) with the exception of this one issue.

taitan · Post by **taitan** » Wed Jun 17, 2015 12:54 pm

Can you copy NOTIFY packet image from the tcpdump's result and copy it here?

cphillips.ia · Post by **cphillips.ia** » Wed Jun 17, 2015 1:13 pm

I sure will. Thanks for the reply!

NOTIFY sip:120@**BSSADDRESS**:5060 SIP/2.0
Via: SIP/2.0/UDP **PBXADDRESS**:0;branch=z9hG4bK60fe2fe2;rport
Max-Forwards: 70
From: "Unknown" <sip:Unknown@**PBXADDRESS**:0>;tag=as2d46885b
To: <sip:120@**BSSADDRESS**:5060>
Contact: <sip:Unknown@**PBXADDRESS**:0>
Call-ID: 4f34ebeb366aca8d739d3bc848065103@**PBXADDRESS**:0
CSeq: 102 NOTIFY
User-Agent: **UASTRING**
Date: **DATETIME** GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Subscription-State: terminated
Event: check-sync
Content-Length: 0

taitan · Post by **taitan** » Wed Jun 17, 2015 3:20 pm

> Via: SIP/2.0/UDP **PBXADDRESS**:0;branch=z9hG4bK60fe2fe2;rport
> Contact: <sip:Unknown@**PBXADDRESS**:0>

Does it indicate port 0?

cphillips.ia · Post by **cphillips.ia** » Thu Jun 18, 2015 4:34 am

That is what the packet looks to be indicating as the From address, but being a check-sync Event there is no reply required from the UA, only a timestamp check of autoprovisioning configuration files against the PBX (via FTP or TFTP in this case). I should also mention that this was captured via a tcpdump of port 5060 only (so it definitely came in on 5060) and that it does function correctly without BSS in the middle.

taitan · Post by **taitan** » Thu Jun 18, 2015 9:23 am

What's the actual remote port of the NOTIFY packet? Is it also 0??
What kind of SIP client is it?

Can you try another SIP client for sending NOTIFY?

If possible, try Windows instead of Debian.

cphillips.ia · Post by **cphillips.ia** » Thu Jun 18, 2015 11:01 am

Actual from port is 5060

Sender of NOTIFY is an Asterisk PBX

Here is a NOTIFY packet from a MWI trigger (which works perfectly and passes through without issue):

NOTIFY sip:120@**BSSADDRESS**:5060 SIP/2.0
Via: SIP/2.0/UDP **PBXADDRESS**:5060;branch=z9hG4bK6b47c993;rport
Max-Forwards: 70
From: "Unknown" <sip:Unknown@**PBXADDRESS**>;tag=as1409af10
To: <sip:120@**BSSADDRESS**:5060>
Contact: <sip:Unknown@**PBXADDRESS**:5060>
Call-ID: 63e64fc23b8384aa345566bb2a02136e@**PBXADDRESS**:5060
CSeq: 102 NOTIFY
User-Agent: **UASTRING**
Event: message-summary
Content-Type: application/simple-message-summary
Content-Length: 95

Messages-Waiting: yes
Message-Account: sip:*97@**PBXADDRESS**:5060
Voice-Message: 1/1 (0/0)

And here is the subsiquent packet that is sent from the BSS to the endpoint (Polycom phone):

NOTIFY sip:120@192.168.60.108:5060 SIP/2.0
Via: SIP/2.0/UDP **BSSADDRESS**:5060;branch=z9hG4bK34a470d1127d-30-17fe15
Via: SIP/2.0/UDP **PBXADDRESS**:5060;branch=z9hG4bK6b47c993;rport=5060
Max-Forwards: 69
From: "Unknown" <sip:Unknown@**PBXADDRESS**>;tag=as1409af10
To: <sip:120@ucs.sbc30.lmbx.net>
Contact: <sip:Unknown@**BSSADDRESS**:5060>
Call-ID: 63e64fc23b8384aa345566bb2a02136e@**PBXADDRESS**:5060
CSeq: 102 NOTIFY
User-Agent: **UASTRING**
Event: message-summary
Record-Route: <sip:**BSSADDRESS**:5060;lr>
Content-Type: application/simple-message-summary
Content-Length: 95

Messages-Waiting: yes
Message-Account: sip:*97@**PBXADDRESS**:5060
Voice-Message: 1/1 (0/0)

Is it possible that BSS does not support "Event: check-sync"? I know that before the recent addition of support for "Reason" header on Cancel the system would simply disregard it...

taitan · Post by **taitan** » Thu Jun 18, 2015 11:27 am

What does "passes through" mean?
Do you mean that the SIP Server forwards NOTIFY without an issue but can not catch it with DialPlan?

cphillips.ia · Post by **cphillips.ia** » Thu Jun 18, 2015 12:05 pm

I meant that in the example of my last reply (a NOTIFY for MWI), PBX sends a NOTIFY to BSS and then BSS relays it on (with an added via and record route) to the Endpoint UA (Polycom phone) and the MWI lights up. I included both packets for verification (packet from PBX to BSS then BSS to Endpoint). This makes sense as it follows the pattern match listed in my very 1st post. I think I was just trying to demonstrate how the MWI NOTIFY is matched and deployed, but the "check-sync" NOTIFY is ignored...

taitan · Post by **taitan** » Thu Jun 18, 2015 12:42 pm

As I said, Call-ID of NOTIFY should be unique if you want to catch it with DialPlan. It means DialPlan doesn't catch a SIP packet if it is sent within an existing dialog.

Are you sure NOTIFY doesn't share a dialog with other SIP requests such as INVITE or SUBSCRIBE?

Add this line in the [Config]->[Advanced] page. It will treat NOTIFY as outside of dialog packets.
------------
net.sip.outside.dialog.pattern = ^NOTIFY
------------