[OpenSIPS-Users] Presentity <basic>closed</basic> always Closed

Mon Jun 20 22:45:50 CEST 2011

Anca,

Please ignore. This is a Bria issue it appears. It is true that initially  
when you first log in with a Bria client it sends a Publish message and has
<status><basic>closed</basic></status>
in the message. I was doing an NGREP and after that message is received if  
you wait a little while (about 11 seconds from the NGREP I did) a second  
Publish Message is sent from the Bria client and it has the SIP-If-Match  
withe correct etag and it sets the presence to
<status><basic>open</basic></status>

Does that seem normal for Counterpath/Bria to send two Publish messages?  
Everything works after the second message is sent. I was just wondering if  
you are supposed to do that?

The issue is this (which I found out a while back)
http://opensips-open-sip-server.1449251.n2.nabble.com/Presentity-record-not-deleted-in-database-td5858207.html

I thought I opened a ticket with Counterpath but it obviously isn't fixed.  
I can't believe I wasted a whole day on an issue I found a while back.

On Jun 20, 2011 12:28pm, Duane Larson <duane.larson at gmail.com> wrote:

> Anca,

> Doing some more testing it looks like the Bria client is sending PUBLISH  
> messages and they are "open". Only when they bria client is shut down is  
> the record in the presentity table set to "closed". Then when the Bria  
> client is turned on again a new PUBLISH is sent and entered into the  
> presentity table with "open", but the NOTIFY that is sent to any watchers  
> has the "closed" in the notify. So it appears that because there are  
> multiple entries in the Presentity table for a single user it is  
> confusing things. Here is an example

> I have user 9013349018 that just closed down Bria. Then the user starts  
> Bria back up and you have the following in the table

> http://pastebin.com/1aZdXsbR

> So the new Presentity record for user 9013349018 is record id 2921. And  
> as the bria client came up you see the following Notify message get sent  
> to user 9013349019 and it has the "closed" in the notify message. Here  
> are the Notify messages

> http://pastebin.com/QJvYiD1B

> So you see that the Bria client came up and sent OpenSIPS a PUBLISH  
> message and it doesn't have "closed" in the XML. Yet when OpenSIPS relays  
> a NOTIFY to a watcher you see that the "closed" gets placed in the xml.  
> So now I am thinking that Bria isn't the issue.

> On Mon, Jun 20, 2011 at 11:46 AM, Anca Vamanu anca.vamanu at gmail.com>  
> wrote:

> Hi Duane,

> Sure looks like a Bria problem.. If it sends publishes with status  
> closed, the presence server doesn't have what else to do but to believe  
> that is the real state that it wants to publish. Maybe something in  
> Bria's configuration leads to this...

> Regards,
> Anca Vamanu

> On Mon, Jun 20, 2011 at 5:10 AM, duane.larson at gmail.com> wrote:

> I have OpenSIPS set up with Presence and am using Counterpath's Bria  
> Client. In the past I was able to get Bria/OpenSIPS/OpenXCAP to all work.  
> Now I am trying to get it to work again and I'm having problems. When two  
> users agree to view each others presence it doesn't work. I see that each  
> user is recieving NOTIFY messages about the other users presence but the  
> Bria client doesn't update the users status. I see that every time a Bria  
> client starts up it is Publishing its presence but it always has closed  
> in the xml

> U 2011/06/19 21:00:12.240159 108.67.136.231:31194 -> 173.203.93.107:5060
> PUBLISH sip:9013349018 at irock.com SIP/2.0.

> Via: SIP/2.0/UDP  
> 108.67.136.231:31194;branch=z9hG4bK-d8754z-96515b7ec527b151-1---d8754z-;rport.
> Max-Forwards: 70.
> Contact: 9013349018 at 108.67.136.231:31194;transport=udp>.

> To: "9013349018"9013349018 at irock.com>.

> From: "9013349018"9013349018 at irock.com>;tag=71799813.

> Call-ID: NTJkNzgyYmMwMDQ1ZWUwMzExMzkyM2Y1OTgxNDgwN2U..
> CSeq: 1 PUBLISH.
> Expires: 3600.
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE,  
> SUBSCRIBE, INFO.
> Content-Type: application/pidf+xml.

> User-Agent: Bria 3 release 3.2.1 stamp 62387.
> Event: presence.
> Content-Length: 469.
> .
> pidf' xmlns:dm='urn:ietf:params:xml:ns:pidf:data-model'  
> xmlns:rpid='urn:ietf:params:xml:ns:pidf:rpid'  
> xmlns:c='urn:ietf:params:xml:ns:pidf:cipid'  
> xmlns:lt='urn:ietf:params:xml:ns:location-type'  
> xmlns:caps='urn:ietf:params:xml:ns:pidf:caps'  
> entity='sip:9013349018 at irock.com'>closedtuple>presence>

> #
> U 2011/06/19 21:00:12.244401 173.203.93.107:5060 -> 108.67.136.231:31194
> SIP/2.0 200 OK.

> Via: SIP/2.0/UDP  
> 108.67.136.231:31194;branch=z9hG4bK-d8754z-72b75f4a63995f60-1---d8754z-;rport=31194.
> To: 9013349018 at irock.com>;tag=31ec65e482de21ae66d7d44df69d3d8c-c4ef.

> From: "9013349018"9013349018 at irock.com>;tag=b5e76db3.

> Call-ID: ZGI1OTA4NmEyYjAzZjFiY2VhNDY4OWY1Njk5MWIwZDA..
> CSeq: 1 SUBSCRIBE.
> Expires: 3600.
> Contact: sip:sa at 173.203.93.107:5060>.
> Server: Aethercommunications SIP Proxy.

> Content-Length: 0.

> Then in the Presentity table I have the following

> mysql> select * from presentity;
> +------+------------+-----------+----------+--------------------------+------------+---------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+--------+

> | id | username | domain | event | etag | expires | received_time | body  
> | extra_hdrs | sender |
> +------+------------+-----------+----------+--------------------------+------------+---------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+--------+

> | 2914 | 9013349018 | irock.com | presence | a.1308527728.29011.36.15 |  
> 1308537940 | 1308534340 | pidf'  
> xmlns:dm='urn:ietf:params:xml:ns:pidf:data-model'  
> xmlns:rpid='urn:ietf:params:xml:ns:pidf:rpid'  
> xmlns:c='urn:ietf:params:xml:ns:pidf:cipid'  
> xmlns:lt='urn:ietf:params:xml:ns:location-type'  
> xmlns:caps='urn:ietf:params:xml:ns:pidf:caps'  
> entity='sip:9013349018 at irock.com'>closedtuple>presence> | | |

> | 2916 | 9013349018 | irock.com | presence | a.1308527728.29010.37.2 |  
> 1308538423 | 1308534823 | pidf'  
> xmlns:dm='urn:ietf:params:xml:ns:pidf:data-model'  
> xmlns:rpid='urn:ietf:params:xml:ns:pidf:rpid'  
> xmlns:c='urn:ietf:params:xml:ns:pidf:cipid'  
> xmlns:lt='urn:ietf:params:xml:ns:location-type'  
> xmlns:caps='urn:ietf:params:xml:ns:pidf:caps'  
> entity='sip:9013349018 at irock.com'>closedtuple>presence> | | |

> | 2915 | 9013349019 | irock.com | presence | a.1308527728.29012.38.7 |  
> 1308538476 | 1308534876 | pidf'  
> xmlns:dm='urn:ietf:params:xml:ns:pidf:data-model'  
> xmlns:rpid='urn:ietf:params:xml:ns:pidf:rpid'  
> xmlns:c='urn:ietf:params:xml:ns:pidf:cipid'  
> xmlns:lt='urn:ietf:params:xml:ns:location-type'  
> xmlns:caps='urn:ietf:params:xml:ns:pidf:caps'  
> entity='sip:9013349019 at irock.com'>opendm:person  
> id='pb4ae929f'>Availableperson> | | |

> | 2917 | 9013349018 | irock.com | presence | a.1308527728.29013.33.2 |  
> 1308538770 | 1308535170 | pidf'  
> xmlns:dm='urn:ietf:params:xml:ns:pidf:data-model'  
> xmlns:rpid='urn:ietf:params:xml:ns:pidf:rpid'  
> xmlns:c='urn:ietf:params:xml:ns:pidf:cipid'  
> xmlns:lt='urn:ietf:params:xml:ns:location-type'  
> xmlns:caps='urn:ietf:params:xml:ns:pidf:caps'  
> entity='sip:9013349018 at irock.com'>closedtuple>presence> | | |

> | 2918 | 9013349018 | irock.com | presence | a.1308527728.29012.42.1 |  
> 1308538823 | 1308535223 | pidf'  
> xmlns:dm='urn:ietf:params:xml:ns:pidf:data-model'  
> xmlns:rpid='urn:ietf:params:xml:ns:pidf:rpid'  
> xmlns:c='urn:ietf:params:xml:ns:pidf:cipid'  
> xmlns:lt='urn:ietf:params:xml:ns:location-type'  
> xmlns:caps='urn:ietf:params:xml:ns:pidf:caps'  
> entity='sip:9013349018 at irock.com'>opendm:person  
> id='p0f48c387'>Availableperson> | | |

> +------+------------+-----------+----------+--------------------------+------------+---------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+--------+

> If I delete all the Presentity records in the presentity table that have  
> the closed in them then Presence status updates start working like they  
> should. Then when the Bria client is shut down it updates the record in  
> Presentity with closed.

> Where is the issue? What do I need to fix or is this a Counterpath Bria  
> issue???

> _______________________________________________
> Users mailing list
> Users at lists.opensips.org

> http://lists.opensips.org/cgi-bin/mailman/listinfo/users

> _______________________________________________

> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users

> --
> --
> *--*--*--*--*--*
> Duane
> *--*--*--*--*--*
> --

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20110620/9571d8db/attachment-0001.htm>