[Home]

Summary:ASTERISK-25588: Problem exchanging device states with PJSIP
Reporter:Marco Paland (mpaland)Labels:
Date Opened:2015-11-23 06:56:03.000-0600Date Closed:2020-01-14 11:13:24.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Resources/res_pjsip Resources/res_pjsip_outbound_publish
Versions:13.6.0 Frequency of
Occurrence		Constant
Related
Issues:
Environment:debian derivatAttachments:
Description:I'm trying to exchange device states between two asterisk boxes (both on 13.6.0) connected via an openvpn tunnel. Tunnel and routing are fine.

First box is 192.168.1.1 (instance-hannover) and second box is 192.168.2.1 (instance-bremen)
Both systems are using pjsip 2.4.5.

The setup is like the description in the wiki: https://wiki.asterisk.org/wiki/display/AST/Exchanging+Device+and+Mailbox+State+Using+PJSIP

The setup on 192.168.1.1 (instance-hannover) is:
{code}
[transport-udp]
type=transport
protocol=udp
bind=0.0.0.0
local_net=192.168.0.0/16
local_net=127.0.0.1/32

[instance-bremen]
type=endpoint
transport=transport-udp

[instance-bremen-devicestate]
type=outbound-publish
server_uri=sip:instance-hannover@192.168.2.1
event=asterisk-devicestate

[instance-bremen]
type=inbound-publication
event_asterisk-devicestate=instance-bremen

[instance-bremen]
type=asterisk-publication
devicestate_publish=instance-bremen-devicestate
device_state=yes
{code}

And the counter part on 192.168.2.1 (instance-bremen):
{code}
[transport-udp]
type=transport
protocol=udp
bind=0.0.0.0
local_net=192.168.0.0/16
local_net=127.0.0.1/32

[instance-hannover]
type=endpoint
transport=transport-udp

[instance-hannover-devicestate]
type=outbound-publish
server_uri=sip:instance-bremen@192.168.1.1
event=asterisk-devicestate

[instance-hannover]
type=inbound-publication
event_asterisk-devicestate=instance-hannover

[instance-hannover]
type=asterisk-publication
devicestate_publish=instance-hannover-devicestate
device_state=yes
{code}


Problem is the following pjsip trace on box 1:
{code}
<--- Received SIP request (572 bytes) from UDP:192.168.2.1:1025 --->
PUBLISH sip:instance-bremen@192.168.1.1 SIP/2.0
Via: SIP/2.0/UDP 10.0.11.2:5060;rport;branch=z9hG4bKPj7fc6f34e-845d-4947-810f-ed4696570380
From: <sip:instance-bremen@192.168.1.1>;tag=9c921261-a400-4ffe-a19b-b674cd8b99f2
To: <sip:instance-bremen@192.168.1.1>
Call-ID: ad96f104-18e0-49ac-9c5d-7fb659530c75
CSeq: 61337 PUBLISH
Event: asterisk-devicestate
Expires: 3600
Max-Forwards: 70
User-Agent: Asterisk
Content-Type: application/json
Content-Length:   101

{"type":"devicestate","state":"RINGING","device":"PJSIP/1001","cachable":1,"eid":"00:00:00:00:00:00"}
<--- Transmitting SIP response (444 bytes) to UDP:192.168.2.1:1025 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.0.11.2:5060;rport=1025;received=192.168.2.1;branch=z9hG4bKPj7fc6f34e-845d-4947-810f-ed4696570380
Call-ID: ad96f104-18e0-49ac-9c5d-7fb659530c75
From: <sip:instance-bremen@192.168.1.1>;tag=9c921261-a400-4ffe-a19b-b674cd8b99f2
To: <sip:instance-bremen@192.168.1.1>;tag=z9hG4bKPj7fc6f34e-845d-4947-810f-ed4696570380
CSeq: 61337 PUBLISH
SIP-ETag: 9905
Expires: 3600
Server: Asterisk
Content-Length:  0
{code}

A SIP request is received from 192.168.2.1 outgoing port 1025.
The response is sent back to 192.168.2.1:1025, but not received there, cause pjsip is listening on port 5060.
This results in:
{code}[2015-11-23 13:46:39] NOTICE[8727]: res_pjsip_outbound_publish.c:923 sip_outbound_publish_callback: No response received for outbound publish 'instance-hannover-devicestate'
{code} on 192.168.2.1 and vice versa.

I can't figure out, how to send the response back to 5060, settings like "from_uri" seem to be ignored.
The wiki documentation is quite not very clear here.

I don't post the full pjsip/extension config here, because I think it's not relevant and the problem is about pjsip publishing.
Comments:By: Asterisk Team (asteriskteam) 2015-11-23 06:56:04.694-0600

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].
By: Rusty Newton (rnewton) 2015-11-23 18:05:45.541-0600

Hmm, what happens when you use the following?

{noformat}
server_uri=sip:instance-hannover@192.168.2.1:5060
{noformat}

Even if this works it may only be a workaround. I don't yet understand why the response goes back to the port it was received from.
By: Marco Paland (mpaland) 2015-11-25 17:17:41.796-0600

Tested it, but your suggested
{code}server_uri=sip:instance-hannover@192.168.2.1:5060{code} doesn't change anything. Still returning to source port.
By: Joshua C. Colp (jcolp) 2015-12-20 17:38:50.688-0600

The 'force_rport' option on the endpoint controls the behavior for sending responses. According to the RFC responses should be sent to the IP address and port that the request was received from. If you set 'force_rport' to no this behavior will be disabled and the response will be sent to the IP address and port in the Via header. If you do this does it work?
By: Marco Paland (mpaland) 2015-12-21 16:38:17.420-0600

Thank you, Joshua, for your input, but unfortunately force_rport=no in "endpoint" section of the above config doesn't help either. (I think I already tried this earlier). But I made a new test, and it's pretty much the same.
Perhaps it has something to do with the VPN tunnel?

I still get: (here on box 2)
{code}
<--- Received SIP request (525 bytes) from UDP:192.168.1.1:1038 --->
PUBLISH sip:instance-hannover@192.168.2.1:5060 SIP/2.0
Via: SIP/2.0/UDP 10.0.12.1:5060;rport;branch=z9hG4bKPjc6ae340c-c14e-45c3-80b6-ceab39c05d28
From: <sip:instance-hannover@192.168.2.1>;tag=df4fe03f-7a25-497c-8716-dc5e5b8e312a
To: <sip:instance-hannover@192.168.2.1>
Call-ID: 7a4139b8-f44e-44fa-8082-57bad82a5c22
CSeq: 8008 PUBLISH
Event: asterisk-devicestate
Expires: 3600
Max-Forwards: 70
User-Agent: Asterisk
Content-Type: application/json
Content-Length:    44

{"type":"refresh","eid":"00:00:00:00:00:00"}
<--- Transmitting SIP response (447 bytes) to UDP:192.168.1.1:1038 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.0.12.1:5060;rport=1038;received=192.168.1.1;branch=z9hG4bKPjc6ae340c-c14e-45c3-80b6-ceab39c05d28
Call-ID: 7a4139b8-f44e-44fa-8082-57bad82a5c22
From: <sip:instance-hannover@192.168.2.1>;tag=df4fe03f-7a25-497c-8716-dc5e5b8e312a
To: <sip:instance-hannover@192.168.2.1>;tag=z9hG4bKPjc6ae340c-c14e-45c3-80b6-ceab39c05d28
CSeq: 8008 PUBLISH
SIP-ETag: 8174
Expires: 3600
Server: Asterisk
Content-Length:  0
{code}

And besides, I created some hints on both systems to reflect the according state device of the other box. But all states are not updated on both sides.
Personally I find the documentation on how to use the distributed device states a bit short, say not existing for this new topic.

By: Joshua C. Colp (jcolp) 2015-12-21 16:41:51.483-0600

Did you set force_rport on both sides? And yes, I'd expect to see the source being port 5060.
By: Marco Paland (mpaland) 2015-12-22 03:59:49.405-0600

Yes I did. Both sides have
{code}
[instance-xxx]
type=endpoint
transport=transport-udp
force_rport=no
{code}

By: Rusty Newton (rnewton) 2015-12-22 18:54:59.298-0600

Marco can you setup two boxes that are not connected over VPN  (on a LAN maybe) and see if you can replicate the same issue there?

Either way, provide wire-shark readable packet captures of the traffic in both cases.
By: Asterisk Team (asteriskteam) 2016-01-06 12:00:21.005-0600

Suspended due to lack of activity. This issue will be automatically re-opened if the reporter posts a comment. If you are not the reporter and would like this re-opened please create a new issue instead. If the new issue is related to this one a link will be created during the triage process. Further information on issue tracker usage can be found in the Asterisk Issue Guidlines [1].

[1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines