The latest svn trunk( from Thursday) has the fix for this. Please update to the latest.

regards,Anca

Yoo Chan Jeon wrote:

Hi, Anca I download the codes from trunk side.I got a compile error. rls/notify.c:765 'subs_t' has no member named 'sockinfo_str'rls/notify.c:769 'subs_t' has no member named 'sockinfo_str'
rls/notify.c:769 'subs_t' has no member named 'sockinfo_str' I found out that in presence/subscribe.hstruct subscription{ struct socket_info* sockinfo;

} is defined. But rls/notify.c use the one in the 1.4 release which is struct subscription
{ str sockinfo_str;} Would you fix this one?I always appreciate your help. Thanks. Jeon

You are almost there :) but missing one piece of information that I will provide to you now.

Yoo Chan Jeon wrote:

Thanks Anca. I checked the Wireshark trace, and your presentation. Openser RLS seems to send a notify to the user before it receives notify msgs from the presence server.
The Wireshark trace steps are following: I explained the trace using your presentation: 1.Eyebeam subscibes to my list 2. Openser RLS subscribes to Presence server.
3. Openser RLS sends a 200 to the Eyebeam. 4. Openser RLS sends a full notify to the Eyebeam without presence states.

When receiving a Subscribe, RLS , as any notifier is obliged to
send an immediate Notify. So RLS check what state information it has , and since it has none at that time - it sends a Notify with empty body. On the other hand, does this Notify receive a 200 OK from
Eyebeam? I am using the UA built using Sofia SIp

No, it receives the 400 Bad content Type header

I looked at the Notify msg which is sent from RLS. It has a minor problem in the Content-Type header
Our RLS has a ("multi-part/related;type="application/rlmi+xml";start=<12223.....>;boundary=..). I checked this type with rfc 4662 rfc 4662 has a
(multi-part/related;type="application/rlmi+xml";start="<12223.....>";boundary=..). There are three ''(doulbe quote) difference. After I changed the rls_notify_extra_hdr() in the
rls/notify.c to the same as in the rfc 4662 . Notify msg does not inlcude xml body anymore. Before the change, it has a xml body. The chages are made in the following. I only changed the two
lines if(start_cid && boundary_string)

{

str_hdr->len+= sprintf(str_hdr->s+str_hdr->len,

//"Content-Type: \"multipart/related;type=\"application/rlmi+xml\"");

"Content-Type: multipart/related;type=\"application/rlmi+xml\"");

str_hdr->len+= sprintf(str_hdr->s+str_hdr->len,

//";start= <%s>;boundary=%s\r\n", start_cid, boundary_string);

";start=\"<%s>\";boundary=%s\r\n", start_cid, boundary_string);

}

5. Presence server sends notify msgs to the Openser RLS.

Now, when receiving a Notify from the presence server, the RLS should send a Notify to Eyebeam with the update of the state. Do you see that?

I want to mention that there were some problems discovered
in RLS at SIPIT, two weeks ago and I am working now at fixing those. They could also appear in your tests. Anyhow any trouble that you find, please report and I will check to see if it is a new or
know one.

Do you use the latest version of Eyebeam? Does it have RLS support again?

regards, Anca Vamanu

I guess that step 4 should be called after step 5.
I checked the codes again. The rls_handle_subscribe() calls resource_subscription(), reply_200(), and send_full_notify(). The resource_suscription() does the step 2.
The reply_200() does the step 3. The send_full_notify() dose the step 4. The rls_handle_subscribe() never wait for step 5. What did I do wrong ? Thanks
Jeon

You are missing something. Here is a link at the slides from the
presentation I held at VON, San Jose this year -http://www.slideshare.net/alwaysoncarl/vamanu-anca/ ( we
will put it on our site also). At page 24 there is a scheme with how RLS works. It interacts with the client by receiving a Subscribe to
a list and sending it an aggregate Notify. To get the info to put in the Notify it sends Notifies for each buddy in list to the presence server (
where the clients have sent Publish messages). The server will then reply with Notifies that will be processed with rls_handle_notify function.