[OpenSIPS-Users] RLS(Resource List Server)

[Yoo Chan Jeon]

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.h
struct 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




On Wed, Oct 29, 2008 at 8:43 AM, Anca Vamanu <anca at voice-system.ro> wrote:

> Hi Jeon,
>
> I have committed the fixes on trunk. Could you please update and test?
>
> regards,
> Anca
>
> Yoo Chan Jeon wrote:
>
>> Now I understand how Openser RLS works.
>>  My answers are in the red texts.
>> I am wondering if I have to change the codes.
>>  Thanks.
>> Jeon
>>
>> On Tue, Oct 28, 2008 at 12:15 PM, Anca Vamanu <anca at voice-system.ro<mailto:
>> anca at voice-system.ro>> wrote:
>>
>>    Hi 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
>>>
>>>        On Tue, Oct 28, 2008 at 9:14 AM, Anca Vamanu
>>>    <anca at voice-system.ro <mailto:anca at voice-system.ro>> wrote:
>>>
>>>        You can also find the slide presentation here:
>>>        http://opensips.org/index.php?n=Resources.DocsPapPa.
>>>
>>>        Anca
>>>
>>>        Anca Vamanu wrote:
>>>
>>>            Hi 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.
>>>
>>>            regards,
>>>            Anca
>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opensips.org/pipermail/users/attachments/20081031/792d2b36/attachment-0001.htm