BLF resubscription fails with PJSIP

swheeler · June 6, 2023, 9:14pm

We recently made the switch from chan_sip to chan_pjsip and I am trying to figure out how to resolve and issue with BLF subscriptions. It appears that the value of the Contact header in the 200 response is incorrect causing the phone to fail to resubscribe. Here’s the flow seen with chan_pjsip:

Phone                                  Proxy                                 Asterisk
  | SUBSCRIBE sip:123@example.com        |                                      |
  | -----------------------------------> |                                      |
  |                                      | SUBSCRIBE sip:123@example.com        |
  |                                      | -----------------------------------> |
  |                                      | 200 OK (Contact: <sip:1.1.1.1:5060>) |
  |                                      | <----------------------------------- |
  | 200 OK (Contact: <sip:1.1.1.1:5060>) |                                      |
  | <----------------------------------- |                                      |
... Subscription nears expiration ...
  | SUBSCRIBE sip:1.1.1.1:5060           |                                      |
  | -----------------------------------> |                                      |
  |                                      | SUBSCRIBE sip:1.1.1.1:5060           |
  |                                      | -----------------------------------> |
  |                                      | 200 OK (Contact: <sip:1.1.1.1:5060>) |
  |                                      | <----------------------------------- |
  | 200 OK (Contact: <sip:1.1.1.1:5060>) |                                      |
  | <----------------------------------- |                                      |

Compared to the flow seen with chan_sip:

Phone                                      Proxy                                     Asterisk
  | SUBSCRIBE sip:123@example.com            |                                          |
  | ---------------------------------------> |                                          |
  |                                          | SUBSCRIBE sip:123@example.com            |
  |                                          | ---------------------------------------> |
  |                                          | 200 OK (Contact: <sip:123@1.1.1.1:5060>) |
  |                                          | <--------------------------------------- |
  | 200 OK (Contact: <sip:123@1.1.1.1:5060>) |                                          |
  | <--------------------------------------- |                                          |
... Subscription nears expiration ...
  | SUBSCRIBE sip:123@example.com            |                                          |
  | ---------------------------------------> |                                          |
  |                                          | SUBSCRIBE sip:123@example.com            |
  |                                          | ---------------------------------------> |
  |                                          | 200 OK (Contact: <sip:123@1.1.1.1:5060>) |
  |                                          | <--------------------------------------- |
  | 200 OK (Contact: <sip:123@1.1.1.1:5060>) |                                          |
  | <--------------------------------------- |                                          |

The main difference between the two packet captures is that when using chan_sip the Contact header in the 200 OK response from Asterisk contains the extension being subscribed to and when using chan_pjsip it is missing. Is there a configuration option that will allow me to include the extension in that response?

jcolp · June 6, 2023, 9:36pm

Where is the failure? What actually happens? What is the actual full SIP trace with console log for PJSIP?

swheeler · June 6, 2023, 9:48pm

The failure is not terribly straightforward, following the resubscribe the notify messages are no longer delivered to the phone and Asterisk eventually deletes the subscription. My current theory is that something in the resubscribe logic causes the RURI to change. However, the original source of the issue appears to be that the BLF extension is missing from the Contact header of the 200 OK in response to the original SUBSCRIBE request.

It doesn’t appear that I can upload PCAP files here, but this link should work: https://file.io/oATVNdueTa0S

If needed I can provide a PCAP showing the flow in chan_sip on an older Asterisk version.

jcolp · June 6, 2023, 10:34pm

A PCAP shows the SIP trace, doing it in Asterisk along with the console logging embeds it all in one place, and debug logging would provide more insight[1]. Otherwise it’s guessing what Asterisk actually did with it.

[1] Collecting Debug Information - Asterisk Project - Asterisk Project Wiki

swheeler · June 7, 2023, 5:20pm

I am unable to attach the log file as I am a new user on this forum. It should be available here: https://file.io/dppB3l6D2TCN

Some notable timestamps:
11:12:41 - REGISTER from monitoring phone
11:12:41 - SUBSCRIBE sip:104@ravon.net from monitoring phone
11:12:41 - 200 OK with Contact: <sip:216.17.0.222:5060> to monitoring phone
11:12:41 - NOTIFY to monitoring phone with current state of x104
11:12:41 - 200 OK from monitoring phone
11:12:45 - Placed a test call from x104
11:12:45 - NOTIFY to monitoring phone with updated state of x104
11:12:45 - 200 OK from monitoring phone
11:13:14 - SUBSCRIBE sip:216.17.0.222:5060 from monitoring phone
11:13:14 - 200 OK with Contact: <sip:216.17.0.222:5060> to monitoring phone
11:13:14 - NOTIFY to monitoring phone with current state of x104 but wrong RURI
Numerous retransmissions of the failed NOTIFY message

Based on the debug messages my guess is it has something to do with this line:

[2023-06-07 11:12:41] DEBUG[31193] res_pjsip/pjsip_message_filter.c: Re-wrote Contact URI host/port to 216.17.0.222:5060 (this may be re-written again later)

jcolp · June 7, 2023, 5:30pm

From a SIP perspective and even within this, the Contact header can change. It doesn’t have to contain the original request user. It looks fine. We handle the resubscribe successfully, send out the NOTIFY, when we get no response the subscription is then terminated. I think you’d need to look upstream to see if there is some kind of requirement within the proxy configuration that is requiring it for some reason.

swheeler · June 7, 2023, 6:08pm

I don’t see the same behavior in chan_sip. The changed contact header in the 200 OK seems to cause the Polycom phone to resubscribe differently. The only thing that has changed is switching from chan_sip to chan_pjsip. The same phone and proxy work just fine with chan_sip.

jcolp · June 7, 2023, 6:18pm

I understand you don’t see the same behavior in chan_sip. From the perspective of Asterisk I see nothing wrong with what it is doing. The resubscribe is successful. The only thing that comes to mind is if the proxy configuration requires specific signaling or the Contact behavior you are referring to.

And there is no option to enable such behavior. I also went back in history and from what I can tell it has behaved this way since the introduction of PJSIP support in Asterisk 10 years ago.

swheeler · June 8, 2023, 9:54pm

After some further digging it appears that the RURI mixup was caused by a missing Record-Route header when subscribing in-dialog. I’m still not sure why we didn’t see this in chan_sip, but it appears to be working correctly now. Thanks for your help.

system · July 8, 2023, 9:55pm

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.