[asterisk-bugs] [JIRA] (ASTERISK-25588) Problem exchanging device states with PJSIP

[Marco Paland (JIRA)]

Marco Paland created ASTERISK-25588:
---------------------------------------

             Summary: Problem exchanging device states with PJSIP
                 Key: ASTERISK-25588
                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-25588
             Project: Asterisk
          Issue Type: Bug
      Security Level: None
          Components: Channels/chan_pjsip, Resources/res_pjsip_outbound_publish
    Affects Versions: 13.6.0
         Environment: Linux
            Reporter: Marco Paland
            Severity: Minor


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 at 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 at 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 at 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 at 192.168.1.1>;tag=9c921261-a400-4ffe-a19b-b674cd8b99f2
To: <sip:instance-bremen at 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 at 192.168.1.1>;tag=9c921261-a400-4ffe-a19b-b674cd8b99f2
To: <sip:instance-bremen at 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.



--
This message was sent by Atlassian JIRA
(v6.2#6252)