Bria 5 presence with Freepbx 15


(Adel Elmenyawy) #1

We are using Bria 5 the licensed version with Freepbx 15. Calls working fine with no issues but presence doesn’t work. Whenever we change the status from Bria nothing happens and users in directory are still showns as “Available”.

Checked the pcap when changing the presence status and I can see Bria sending a PUBLISH request to Freepbx which is responding first with 401 Unauthorized. Then Bria sens again a PUBLISH request with the new presence state and Freepbx responds with 489 Bad Event.

Please let me know if there is something I can do to fix that or there is a module needs to be purchased in order to have that working. Also, if it is a compatibility issue, what other solutions are guaranteed to work?

Please find the pcap output below:
(Bria’s computer IP is 192.168.239.1 and Freepbx’s IP is 192.168.239.133)

No. Time Source Destination Protocol Length Info
13 5.959568 192.168.239.1 192.168.239.133 SIP/XML 1051 Request: PUBLISH sip:500@192.168.239.133 |

Frame 13: 1051 bytes on wire (8408 bits), 1051 bytes captured (8408 bits) on interface 0
Ethernet II, Src: Vmware_c0:00:08 (00:50:56:c0:00:08), Dst: Vmware_fd:27:46 (00:0c:29:fd:27:46)
Internet Protocol Version 4, Src: 192.168.239.1, Dst: 192.168.239.133
User Datagram Protocol, Src Port: 54369, Dst Port: 5060
Session Initiation Protocol (PUBLISH)
Request-Line: PUBLISH sip:500@192.168.239.133 SIP/2.0
Method: PUBLISH
Request-URI: sip:500@192.168.239.133
Request-URI User Part: 500
Request-URI Host Part: 192.168.239.133
[Resent Packet: False]
Message Header
Via: SIP/2.0/UDP 192.168.239.1:54369;branch=z9hG4bK-524287-1—a0adb84387f05b00;rport
Transport: UDP
Sent-by Address: 192.168.239.1
Sent-by port: 54369
Branch: z9hG4bK-524287-1—a0adb84387f05b00
RPort: rport
Max-Forwards: 70
Contact: sip:500@192.168.239.1:54369
Contact URI: sip:500@192.168.239.1:54369
To: sip:500@192.168.239.133
SIP to address: sip:500@192.168.239.133
From: "test1"sip:500@192.168.239.133;tag=b9337e17
SIP Display info: “test1”
SIP from address: sip:500@192.168.239.133
SIP from tag: b9337e17
Call-ID: 99262YWFhMTA4OTMwNTlmMjkzZWE4NzkyMTM5ZGI3YjM0ODI
[Generated Call-ID: 99262YWFhMTA4OTMwNTlmMjkzZWE4NzkyMTM5ZGI3YjM0ODI]
CSeq: 1 PUBLISH
Sequence Number: 1
Method: PUBLISH
Expires: 60
Allow: OPTIONS, SUBSCRIBE, NOTIFY, INVITE, ACK, CANCEL, BYE, REFER, INFO, MESSAGE
Content-Type: application/pidf+xml
User-Agent: Bria 5 release 5.6.2 stamp 99262
Event: presence
Content-Length: 445
Message Body
eXtensible Markup Language
<?xml
version=“1.0”
encoding=“UTF-8”
?>




open



<dm:person
id=“75e4ef07f933e640da”>
dm:note
On the phone
</dm:note>
rpid:activities
rpid:on-the-phone/
</rpid:activities>
</dm:person>

No. Time Source Destination Protocol Length Info
14 5.960511 192.168.239.133 192.168.239.1 SIP 587 Status: 401 Unauthorized |

Frame 14: 587 bytes on wire (4696 bits), 587 bytes captured (4696 bits) on interface 0
Ethernet II, Src: Vmware_fd:27:46 (00:0c:29:fd:27:46), Dst: Vmware_c0:00:08 (00:50:56:c0:00:08)
Internet Protocol Version 4, Src: 192.168.239.133, Dst: 192.168.239.1
User Datagram Protocol, Src Port: 5060, Dst Port: 54369
Session Initiation Protocol (401)
Status-Line: SIP/2.0 401 Unauthorized
Status-Code: 401
[Resent Packet: False]
[Request Frame: 13]
[Response Time (ms): 0]
Message Header
Via: SIP/2.0/UDP 192.168.239.1:54369;rport=54369;received=192.168.239.1;branch=z9hG4bK-524287-1—a0adb84387f05b00
Transport: UDP
Sent-by Address: 192.168.239.1
Sent-by port: 54369
RPort: 54369
Received: 192.168.239.1
Branch: z9hG4bK-524287-1—a0adb84387f05b00
Call-ID: 99262YWFhMTA4OTMwNTlmMjkzZWE4NzkyMTM5ZGI3YjM0ODI
[Generated Call-ID: 99262YWFhMTA4OTMwNTlmMjkzZWE4NzkyMTM5ZGI3YjM0ODI]
From: “test1” sip:500@192.168.239.133;tag=b9337e17
SIP Display info: “test1”
SIP from address: sip:500@192.168.239.133
SIP from tag: b9337e17
To: sip:500@192.168.239.133;tag=z9hG4bK-524287-1—a0adb84387f05b00
SIP to address: sip:500@192.168.239.133
SIP to tag: z9hG4bK-524287-1—a0adb84387f05b00
CSeq: 1 PUBLISH
Sequence Number: 1
Method: PUBLISH
WWW-Authenticate: Digest realm=“asterisk”,nonce=“1600228298/e8883b2b900407f1da8239dd4fce19db”,opaque=“686986073a877d23”,algorithm=md5,qop=“auth”
Authentication Scheme: Digest
Realm: “asterisk”
Nonce Value: “1600228298/e8883b2b900407f1da8239dd4fce19db”
Opaque Value: “686986073a877d23”
Algorithm: md5
QOP: “auth”
Server: FPBX-15.0.16.72(16.11.1)
Content-Length: 0

No. Time Source Destination Protocol Length Info
15 5.970575 192.168.239.1 192.168.239.133 SIP/XML 1335 Request: PUBLISH sip:500@192.168.239.133 |

Frame 15: 1335 bytes on wire (10680 bits), 1335 bytes captured (10680 bits) on interface 0
Ethernet II, Src: Vmware_c0:00:08 (00:50:56:c0:00:08), Dst: Vmware_fd:27:46 (00:0c:29:fd:27:46)
Internet Protocol Version 4, Src: 192.168.239.1, Dst: 192.168.239.133
User Datagram Protocol, Src Port: 54369, Dst Port: 5060
Session Initiation Protocol (PUBLISH)
Request-Line: PUBLISH sip:500@192.168.239.133 SIP/2.0
Method: PUBLISH
Request-URI: sip:500@192.168.239.133
Request-URI User Part: 500
Request-URI Host Part: 192.168.239.133
[Resent Packet: False]
Message Header
Via: SIP/2.0/UDP 192.168.239.1:54369;branch=z9hG4bK-524287-1—013cee25d8138077;rport
Transport: UDP
Sent-by Address: 192.168.239.1
Sent-by port: 54369
Branch: z9hG4bK-524287-1—013cee25d8138077
RPort: rport
Max-Forwards: 70
Contact: sip:500@192.168.239.1:54369
Contact URI: sip:500@192.168.239.1:54369
To: sip:500@192.168.239.133
SIP to address: sip:500@192.168.239.133
From: “test1"sip:500@192.168.239.133;tag=b9337e17
SIP Display info: “test1”
SIP from address: sip:500@192.168.239.133
SIP from tag: b9337e17
Call-ID: 99262YWFhMTA4OTMwNTlmMjkzZWE4NzkyMTM5ZGI3YjM0ODI
[Generated Call-ID: 99262YWFhMTA4OTMwNTlmMjkzZWE4NzkyMTM5ZGI3YjM0ODI]
CSeq: 2 PUBLISH
Sequence Number: 2
Method: PUBLISH
Expires: 60
Allow: OPTIONS, SUBSCRIBE, NOTIFY, INVITE, ACK, CANCEL, BYE, REFER, INFO, MESSAGE
Content-Type: application/pidf+xml
User-Agent: Bria 5 release 5.6.2 stamp 99262
[truncated]Authorization: Digest username=“500”,realm=“asterisk”,nonce=“1600228298/e8883b2b900407f1da8239dd4fce19db”,uri=“sip:500@192.168.239.133”,response=“22e5038dd9d46c5eafee6afa6571b625”,cnonce=“a83ea6555f32ba6f718d40741715ee53”,nc=0
Authentication Scheme: Digest
Username: “500”
Realm: “asterisk”
Nonce Value: “1600228298/e8883b2b900407f1da8239dd4fce19db”
Authentication URI: "sip:500@192.168.239.133
Digest Authentication Response: “22e5038dd9d46c5eafee6afa6571b625”
CNonce Value: “a83ea6555f32ba6f718d40741715ee53”
Nonce Count: 00000001
QOP: auth
Algorithm: md5
Opaque Value: “686986073a877d23”
Event: presence
Content-Length: 445
Message Body
eXtensible Markup Language
<?xml
version=“1.0”
encoding=“UTF-8”
?>




open



<dm:person
id=“75e4ef07f933e640da”>
dm:note
On the phone
</dm:note>
rpid:activities
rpid:on-the-phone/
</rpid:activities>
</dm:person>

No. Time Source Destination Protocol Length Info
16 5.971489 192.168.239.133 192.168.239.1 SIP 438 Status: 489 Bad Event |

Frame 16: 438 bytes on wire (3504 bits), 438 bytes captured (3504 bits) on interface 0
Ethernet II, Src: Vmware_fd:27:46 (00:0c:29:fd:27:46), Dst: Vmware_c0:00:08 (00:50:56:c0:00:08)
Internet Protocol Version 4, Src: 192.168.239.133, Dst: 192.168.239.1
User Datagram Protocol, Src Port: 5060, Dst Port: 54369
Session Initiation Protocol (489)
Status-Line: SIP/2.0 489 Bad Event
Status-Code: 489
[Resent Packet: False]
[Request Frame: 15]
[Response Time (ms): 0]
Message Header
Via: SIP/2.0/UDP 192.168.239.1:54369;rport=54369;received=192.168.239.1;branch=z9hG4bK-524287-1—013cee25d8138077
Transport: UDP
Sent-by Address: 192.168.239.1
Sent-by port: 54369
RPort: 54369
Received: 192.168.239.1
Branch: z9hG4bK-524287-1—013cee25d8138077
Call-ID: 99262YWFhMTA4OTMwNTlmMjkzZWE4NzkyMTM5ZGI3YjM0ODI
[Generated Call-ID: 99262YWFhMTA4OTMwNTlmMjkzZWE4NzkyMTM5ZGI3YjM0ODI]
From: “test1” sip:500@192.168.239.133;tag=b9337e17
SIP Display info: “test1”
SIP from address: sip:500@192.168.239.133
SIP from tag: b9337e17
To: sip:500@192.168.239.133;tag=z9hG4bK-524287-1—013cee25d8138077
SIP to address: sip:500@192.168.239.133
SIP to tag: z9hG4bK-524287-1—013cee25d8138077
CSeq: 2 PUBLISH
Sequence Number: 2
Method: PUBLISH
Server: FPBX-15.0.16.72(16.11.1)
Content-Length: 0


(Dave Burgess) #2

Just so you’re not hanging - I have no idea.

BUT, since the system is open source, you could skulk through the source for PJ-SIP and see if you can find the code that processes the PUBLISH subcommand. I’m not even sure that such a thing exists: I know we handle presence in FreePBX through the XMPP interface. I’m also pretty sure that Bria is expecting to speak to their own server interface, so that might be part of the issue.


(Joshua C. Colp) #3

There is no support for handling PUBLISH requests like this from endpoints, thus the response. The actual PUBLISH support is pluggable so it could be added, but such functionality does not exist currently.

Asterisk itself calculates/determines the state of an endpoint within the system based on channels, registration status, etc.