Hi Jamey!
Im interested in the presence agent module, especially in including geographical user information into the presence data.
What is the body type of the publication/notifications? Is it XML based presence like used by Windows Messenger and Kphone? Is this format defined somewhere? Is this the same as this old draft? http://www.iptel.org/info/players/ietf/presence/outdated/draft-rosenberg -impp-pidf-00.txt
The presentity table includes x and y colums? Are these to represent the geographical location of the publisher?
regards, Klaus
-----Original Message----- From: Jamey Hicks [mailto:jamey.hicks@hp.com] Sent: Wednesday, January 21, 2004 7:24 PM To: Kevin Chu Cc: SER Users Subject: [Serusers] Re: problem for using the latest pa module
Kevin Chu wrote:
Hi Jamey,
I am interested for testing the new extensions of the pa
module from the
latest unstable release. However, I got problem for configuring pa module.
I will check in a fix to prevent this segv.
However, I don't know how to create the db for pa, I still
can not get it
running correctly.
I will add a pa.sql script for creating the tables.
It will be appreciated if you can provide me some
instructions or examples
for creating the db as well as setting the new parameters
(presentity_table,
watcherinfo_table) and using the new commands.
The db_url is the same form as that of the usrloc db, e.g., mysql.
Here are the pa params I'm using now: # -- pa params -- modparam("pa", "use_db", 1) modparam("pa", "db_url", "mysql://ser:heslo@localhost/ser")
There is currently a problem that pa does not pick up basic presence from ser itself, because it needs that info on a per contact basis, which means some changes to usrloc. I attempted that, but did not get it working. Right now pa is depending on the UA or presence UA PUBLISH'ing that info using application/cpim-pidf+xml format.
Here are routing rules for PUBLISH and SUBSCRIBE: if (method=="PUBLISH") { if (!t_newtran()) { log(1, "newtran error\n"); sl_reply_error(); }; handle_publish("registrar"); log(1,"handled publish\n"); break; };
if (method=="SUBSCRIBE") { if (!t_newtran()) { log(1, "newtran error\n"); sl_reply_error(); }; log(1, "handling subscription\n"); handle_subscription("registrar"); log(1,"handled subscribe\n"); break; };
Another problem is that Windows Messenger does not like the notifies that pa is sending. If anyone has any ideas what is wrong I would like to know about it.
I'm deploying this version of the PA at the Internet2 Joint Techs Meeting in Hawaii next week as part of an Internet2 Presence Integrated Communication working group demo.
-Jamey
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Klaus Darilion wrote:
Hi Jamey!
Im interested in the presence agent module, especially in including geographical user information into the presence data.
What is the body type of the publication/notifications? Is it XML based presence like used by Windows Messenger and Kphone? Is this format defined somewhere? Is this the same as this old draft? http://www.iptel.org/info/players/ietf/presence/outdated/draft-rosenberg -impp-pidf-00.txt
The presentity table includes x and y colums? Are these to represent the geographical location of the publisher?
Hi Klaus,
The body type is application/cpim-pidf+xml with a couple extensions modeled on geopriv and civil location. The same body type is accepted by the code that handles PUBLISH and updates the database. The NOTIFY messages are generated from that. We have an 802.11 location tracking system that generates PUBLISH messages that include site, floor, room, x, y and radius of the position estimate. Our location tracking service yields roughly office-level resolution for the two floors of our building that we occupy. The position data is for the client device from which a user is registered. We also have PHP code for a presence portal that lets users update their location manually if no location service is available or if they wish to override the location provided by the location service.
The presence agent still needs some work -- it currently allows anyone to subscribe. I have mostly coded support for the watcherinfo event package and for xcap access to presence-lists, so that users can be notified when a new person requests to subscribe to their presence info and so that users can use xcap to authorize/deny those requests. I have been working with Xiaotao Wu at Columbia to debug that against the sipc user agent and I've been adding code to linphone. It would be great if someone wants to add similar support to kphone. I may get to kphone but I have a lot on my plate right now.
The other thing that the presence agent should have with respect to physical location is a way for a user to specify the resolution of the location information to be shared with other users. For example, I might want to let people know I'm on the 12th floor here but not which office I'm in.
Another problem with the presence agent is that Windows Messenger does not accept the NOTIFY messages, so none of your contacts looks to be online. I'm not interested in supporting a UA that does not support the internet draft standards but if minor tweaks would make this work that would be OK.
The final issue that comes to mind with the PA is that it is set up to aggregate presence for all user agents. It handles SUBSCRIBE and PUBLISH, and it generates NOTIFY. It gets basic online/offline status from the usrloc module but depends on the UA or other presence agent to PUBLISH more detailed information.
I hope this is helpful. I am planning to write a document that outlines how this works and what is needed from UA's. I imagine that review and revision of that document will lead to changes in the PA implementation to make the whole system work better.
Jamey
Hi Jamey!
Thanks for the information. One of my students here at the university tries to implement a system where you can watch mobile user running around and call them by clicking on the moving point at the map - all with SIP. Currently we produce the location information at the mobile client (ipaq + xlite) by reading the GPS data from a bluetooth GPS receiver.
On the other side, we would like to have a Windows based client, which uses the RTC API. So the idea was to include the GPS information into the presence by using the "user-provided presence info" (like "x=123;y=456" instead of "i'm at lunch and come back at 2:30"). Nevertheless, therefore it would be necessary that the RTC API accepts the notficiations from ser.
The RTC api sends its notifieys as application/xpidf+xml, not as application/cpim-pidf+xml. Is this the same format with a different name? I tried to find the definition of them, but I found several outdated drafts. I took a closer look at the drafts from the impp working group, but for example i couldn't find the definition of the <presentitiy> tag. Can you point me to a document which describes the format used by the RTC. Btw: which format uses the sipc or other commerical SIP-based IM applications?
I also found no description of adding the exact geographical location into the presence information in a more generic way (not the workaround described above). Have you ever thought of this (as the columns are already defined in the database tables)? E.g. it could be a dedicated tag or an attribute in the location tag.
Regards, Klaus
Jamey Hicks wrote:
Klaus Darilion wrote:
Hi Jamey!
Im interested in the presence agent module, especially in including geographical user information into the presence data.
What is the body type of the publication/notifications? Is it XML based presence like used by Windows Messenger and Kphone? Is this format defined somewhere? Is this the same as this old draft? http://www.iptel.org/info/players/ietf/presence/outdated/draft-rosenberg -impp-pidf-00.txt
The presentity table includes x and y colums? Are these to represent the geographical location of the publisher?
Hi Klaus,
The body type is application/cpim-pidf+xml with a couple extensions modeled on geopriv and civil location. The same body type is accepted by the code that handles PUBLISH and updates the database. The NOTIFY messages are generated from that. We have an 802.11 location tracking system that generates PUBLISH messages that include site, floor, room, x, y and radius of the position estimate. Our location tracking service yields roughly office-level resolution for the two floors of our building that we occupy. The position data is for the client device from which a user is registered. We also have PHP code for a presence portal that lets users update their location manually if no location service is available or if they wish to override the location provided by the location service.
The presence agent still needs some work -- it currently allows anyone to subscribe. I have mostly coded support for the watcherinfo event package and for xcap access to presence-lists, so that users can be notified when a new person requests to subscribe to their presence info and so that users can use xcap to authorize/deny those requests. I have been working with Xiaotao Wu at Columbia to debug that against the sipc user agent and I've been adding code to linphone. It would be great if someone wants to add similar support to kphone. I may get to kphone but I have a lot on my plate right now.
The other thing that the presence agent should have with respect to physical location is a way for a user to specify the resolution of the location information to be shared with other users. For example, I might want to let people know I'm on the 12th floor here but not which office I'm in.
Another problem with the presence agent is that Windows Messenger does not accept the NOTIFY messages, so none of your contacts looks to be online. I'm not interested in supporting a UA that does not support the internet draft standards but if minor tweaks would make this work that would be OK.
The final issue that comes to mind with the PA is that it is set up to aggregate presence for all user agents. It handles SUBSCRIBE and PUBLISH, and it generates NOTIFY. It gets basic online/offline status from the usrloc module but depends on the UA or other presence agent to PUBLISH more detailed information.
I hope this is helpful. I am planning to write a document that outlines how this works and what is needed from UA's. I imagine that review and revision of that document will lead to changes in the PA implementation to make the whole system work better.
Jamey
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers