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

Mon Jun 20 19:28:22 CEST 2011

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
>> <basic>closed</basic> 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: <sip:9013349018 at 108.67.136.231:31194;transport=udp>.
>> To: "9013349018"<sip:9013349018 at irock.com>.
>> From: "9013349018"<sip: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.
>> .
>> <?xml version='1.0' encoding='UTF-8'?><presence
>> xmlns='urn:ietf:params:xml:ns: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@
>> irock.com'><tuple
>> id='td9cbb9c2'><status><basic>closed</basic></status></tuple><dm:person
>> id='p0f48c387'></dm:person></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: <sip:9013349018 at irock.com>;tag=31ec65e482de21ae66d7d44df69d3d8c-c4ef.
>>
>> From: "9013349018"<sip: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 | <?xml version='1.0' encoding='UTF-8'?><presence
>> xmlns='urn:ietf:params:xml:ns: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@
>> irock.com'><tuple
>> id='t1f9e4914'><status><basic>closed</basic></status></tuple><dm:person
>> id='pf69e3d57'></dm:person></presence> | | |
>> | 2916 | 9013349018 | irock.com | presence | a.1308527728.29010.37.2 |
>> 1308538423 | 1308534823 | <?xml version='1.0' encoding='UTF-8'?><presence
>> xmlns='urn:ietf:params:xml:ns: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@
>> irock.com'><tuple
>> id='tb1de818c'><status><basic>closed</basic></status></tuple><dm:person
>> id='p43342606'></dm:person></presence> | | |
>> | 2915 | 9013349019 | irock.com | presence | a.1308527728.29012.38.7 |
>> 1308538476 | 1308534876 | <?xml version='1.0' encoding='UTF-8'?><presence
>> xmlns='urn:ietf:params:xml:ns: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@
>> irock.com'><tuple
>> id='t5762491b'><status><basic>open</basic></status></tuple><dm:person
>> id='pb4ae929f'><dm:note>Available</dm:note></dm:person></presence> | | |
>> | 2917 | 9013349018 | irock.com | presence | a.1308527728.29013.33.2 |
>> 1308538770 | 1308535170 | <?xml version='1.0' encoding='UTF-8'?><presence
>> xmlns='urn:ietf:params:xml:ns: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@
>> irock.com'><tuple
>> id='t4246cfbe'><status><basic>closed</basic></status></tuple><dm:person
>> id='p49e1604e'></dm:person></presence> | | |
>> | 2918 | 9013349018 | irock.com | presence | a.1308527728.29012.42.1 |
>> 1308538823 | 1308535223 | <?xml version='1.0' encoding='UTF-8'?><presence
>> xmlns='urn:ietf:params:xml:ns: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@
>> irock.com'><tuple
>> id='td9cbb9c2'><status><basic>open</basic></status></tuple><dm:person
>> id='p0f48c387'><dm:note>Available</dm:note></dm:person></presence> | | |
>> +------+------------+-----------+----------+--------------------------+------------+---------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+--------+
>>
>>
>>
>> If I delete all the Presentity records in the presentity table that have
>> the <basic>closed</basic> 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 <basic>closed</basic>.
>>
>> 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/703b06f4/attachment.htm>