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

Anca Vamanu anca at voice-system.ro
Wed Nov 14 11:23:50 UTC 2007


Hello,

I have just tested with that scenario and there is no problem with that 
condition. It works as it should.
Please make sure that the expected output is the wright one.
You should have a Subscribe with Expires:0 inside a dialog that receives 
a  "481 Subscription does not exist" reply, and then another Subscribe 
is generated - which should have Expires:0. If it doesn't then you are 
wright. In this case send the log for the pua callback handling the 481 
reply.

regards,
Anca

Reinhold Buchinger wrote:
> 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
>>
>>   
>
>




More information about the Devel mailing list