[OpenSER-Devel] [Fwd: Re: pua module - unsubscribe]

[Reinhold Buchinger]

Hi,

Thanks for the changes. Only the second if is not working correctly at 
the moment:

if((hentity->desired_expires- (int)time(NULL))<= 0)

because hentity->desired_expires is of type unsigned int.
If you add a cast to int it should work, I guess...

Regards,
Reinhold

Anca Vamanu schrieb:
> -------- Original Message --------
> Subject: 	Re: [OpenSER-Devel] pua module - unsubscribe
> Date: 	Tue, 13 Nov 2007 11:57:03 +0200
> From: 	Anca Vamanu <anca at voice-system.ro>
> To: 	Reinhold Buchinger <reinhold.buchinger at gmail.com>
> References: 	<473420DF.8020809 at gmail.com> 
> <47342410.4080307 at voice-system.ro> <47348B90.8070700 at gmail.com> 
> <47381EEA.6090702 at voice-system.ro> <4738CC58.6040105 at gmail.com>
>
>
>
> Hello,
>
> The succession on checks was wrong. Please test with the latest revision.
>
> Thanks and regards,
> Anca
>
> Reinhold Buchinger wrote:
>   
>> Hi,
>>
>> Unfortunately, there is also an unwanted side-effect. If a 
>> subscription is renewed expires is set to -1 for the call-back 
>> parameter (infinite subscribes). In case of an error this also 
>> triggers a new subscription with expires = 0....
>>
>> regards,
>> Reinhold
>>
>> Anca Vamanu schrieb:
>>     
>>> Hello,
>>>
>>> It is not about retransmission there, but about the cases in which a 
>>> request is sent inside a dialog stored by pua but which is not 
>>> recognized by the client (the case of a client signing off and no 
>>> Subscribe with expires= 0 sent to pua to announce it that the dialog 
>>> has ended). The logics are like this: if someone asked me to send a 
>>> request (for publish it's the same) and I matched it with a stored 
>>> dialog and it failed, try again with an initial request. This is to 
>>> ensure a a certain reliability.
>>> Therefore, in that case that you mentioned, when a second attempt is 
>>> made, it is no longer about an unsubscribe. The request sent will be 
>>> an fetching Subscribe(one with expires= 0)- I have made the changes 
>>> to make this case possible. However,even if an unsubscribe was 
>>> desired, the effects are the same, the dialog is already no longer 
>>> valid, the pua record is deleted, and a Notify is sent.
>>>
>>> regards,
>>> Anca Vamanu
>>>
>>> Reinhold Buchinger wrote:
>>>       
>>>> Hi,
>>>>
>>>> Thanks for your answer. But there is still a problem with 
>>>> subs_cback_func(...) if a retransmission is triggered. This message 
>>>> cannot be send with expires=0.
>>>>
>>>> subs.expires= (hentity->desired_expires>0)?
>>>>                    hentity->desired_expires- (int)time(NULL)+ 10:-1;
>>>>
>>>> Regards,
>>>> Reinhold
>>>>
>>>>
>>>> Anca Vamanu schrieb:
>>>>         
>>>>> Hello,
>>>>>
>>>>> The expires= 0 case is covered in subs_build_hdr(...) :
>>>>>  
>>>>>     if( expires<= min_expires)
>>>>>        subs_expires= int2str(min_expires, &len);    else
>>>>>        subs_expires= int2str(expires+ 10, &len);
>>>>>
>>>>> if the module parameter min_expires maintains its default value, 
>>>>> which is 0.
>>>>> I will test to see if indeed it is not possible now to unsubscribe.
>>>>>
>>>>> regards,
>>>>> Anca Vamanu
>>>>>
>>>>> Reinhold Buchinger wrote:
>>>>>           
>>>>>> Hi,
>>>>>>
>>>>>> Using the pua module, I cannot send a subscription with expires=0. 
>>>>>> If you look at subs_build_hdr(...)  in send_subscribe.c this case 
>>>>>> is not covered.
>>>>>>
>>>>>> Regards,
>>>>>> Reinhold
>>>>>>
>>>>>> _______________________________________________
>>>>>> Devel mailing list
>>>>>> Devel at lists.openser.org
>>>>>> http://lists.openser.org/cgi-bin/mailman/listinfo/devel
>>>>>>
>>>>>>   
>>>>>>             
>>>>>           
>>>>         
>>>       
>>     
>
>
>
> _______________________________________________
> Devel mailing list
> Devel at lists.openser.org
> http://lists.openser.org/cgi-bin/mailman/listinfo/devel
>
>