[OpenSER-Users] No NOTIFY after presence unsubscription

Anca-Maria Vamanu anca at voice-system.ro
Thu Jul 5 10:44:19 CEST 2007


Hello,

I fixed that with the last commit.  Thanks for the reports.

regards,

Anca



Michel de Boer wrote:

>Hi Anca,
>
>Thanks for your help. I didn't realize the presence module
>was reorganized. It's working now again.
>
>And openser indeed sends a NOTIFY after a SUBCRIBE with
>expires = 0. :)
>
>However, the Subscription-State in the NOTIFY is incorrect :(
>Openser sends this Subscription-State header:
>
>  Subscription-State: active;expires=0
>
>RFC 3265 section 3.3.6 states:
>
>   Note that the NOTIFY messages triggered by SUBSCRIBE messages with
>   "Expires" headers of 0 will contain a "Subscription-State" value of
>   "terminated", and a "reason" parameter of "timeout".
>
>So I expect the following header:
>
>  Subscription-State: terminated;reason=timeout
>
>I hope I am not too much of a pain :)
>
>Cheers,
>Michel
>
>
>Anca-Maria Vamanu wrote:
>  
>
>>Hello,
>>
>>There has been a reorganization in the trunk version for the presence
>>modules. You need to load also presence_xml. You have to make the
>>following changes. Insert ' loadmodule "presence_xml.so"  '.
>>If you have set force_active , then replace the line
>>modparam("presence", "force_active", 1) with  modparam("presence_xml",
>>"force_active", 1).
>>However, the reply is indeed malformed . I will fix that. Thanks.
>>
>>regards,
>>
>>Anca Vamanu
>>
>>Michel de Boer wrote:
>>
>>    
>>
>>>Hi,
>>>
>>>I just checked out the sources from the trunk.
>>>And the presence module does not seem to work anymore :(
>>>
>>>On the SUBSCRIBE (Event header set to "presence") I send, I get a 489
>>>Bad Event response.
>>>The SUBSCRIBE is exactly the same as the SUBSCRIBE I used with
>>>version 1.2.1. There it worked.
>>>
>>>Furthermore, the 489 reponse is malformed. The mandatory
>>>Allow-Events header is missing.
>>>
>>>This is what I see in the error logging:
>>>
>>>7(16680) parse_headers: flags=ffffffffffffffff
>>>7(16680) PRESENCE: handle_subscribe:Missing or unsupported event header
>>>field value
>>>
>>>Regards,
>>>Michel
>>>
>>>Anca-Maria Vamanu wrote:
>>> 
>>>
>>>      
>>>
>>>>Hello,
>>>>
>>>>Indeed the module did not sent Notify messages when unsubscribing. It
>>>>did, however, sent them when an initial Subscribe with expires 0 was
>>>>received. I have fixed that in the latest commit.
>>>>Thanks for reporting.
>>>>
>>>>Best regards,
>>>>
>>>>Anca Vamanu
>>>>
>>>>Michel de Boer wrote:
>>>>
>>>>  
>>>>        
>>>>
>>>>>Hi,
>>>>>
>>>>>I am currently experimenting with the presence module (openser v1.2.1).
>>>>>It seems to work really fine. I only encountered a small problem.
>>>>>
>>>>>When my client unsubscribes from the presence event by sending a
>>>>>SUBSCRIBE request with expires=0, then openser responds with a 200 OK.
>>>>>After the 200 OK, I expect to receive a NOTIFY message, but openser
>>>>>never sends this NOTIFY. It is this NOTIFY that should terminate
>>>>>the subscription dialog through its Subscription-State header
>>>>>set to "terminated".
>>>>>
>>>>>RFC 3856 states this:
>>>>>
>>>>> The subscriber can terminate the subscription by sending a SUBSCRIBE,
>>>>> within the dialog, with an Expires header field (which indicates
>>>>> duration of the subscription) value of zero.  This causes an
>>>>> immediate termination of the subscription.  A NOTIFY request is then
>>>>> generated by the presence agent with the most recent state.
>>>>>
>>>>>This behavior is based on the general requirements for event handling
>>>>>as defined in RFC 3265.
>>>>>
>>>>>Is this a bug or is there some configuration stuff that
>>>>>enables/disables
>>>>>the NOTIFY for a SUBSCRIBE with epxpires=0.
>>>>>
>>>>>A SUBSCRIBE with expires=0 can also arrive as the initial and final
>>>>>SUBSCRIBE for a subscription. In that case it will be fetching
>>>>>the presence information only once. Without the NOTIFY, a fetch
>>>>>does not work.
>>>>>
>>>>>Cheers,
>>>>>Michel
>>>>>
>>>>>
>>>>>
>>>>>    
>>>>>          
>>>>>
>>>>  
>>>>        
>>>>
>>> 
>>>
>>>      
>>>
>>
>>    
>>
>
>  
>





More information about the sr-users mailing list