Summary: | ASTERISK-25588: Problem exchanging device states with PJSIP | ||
Reporter: | Marco Paland (mpaland) | Labels: | |
Date Opened: | 2015-11-23 06:56:03.000-0600 | Date Closed: | 2020-01-14 11:13:24.000-0600 |
Priority: | Minor | Regression? | No |
Status: | Closed/Complete | Components: | Resources/res_pjsip Resources/res_pjsip_outbound_publish |
Versions: | 13.6.0 | Frequency of Occurrence | Constant |
Related Issues: | |||
Environment: | debian derivat | Attachments: | |
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 |