[OpenSIPS-Users] Strange BLF behaviour on double call

[Anca Vamanu]

Hi Vallimamod,

Indeed I should have changed there also. Now I have reexamined the flow 
of operations and it was a bit inefficient with by first version, the 
change was done two times. Can you please try the new version ( I have 
just made a commit).

Thanks and regards,

-- 
Anca Vamanu
www.voice-system.ro




On 10/07/2010 04:16 PM, Vallimamod ABDULLAH wrote:
> Well answering to myself, I have changed "full" by "partial" in presence_dialoginfo/notify_body.c (patch attached) and this have solved my problem: The notifications have also state="partial" and the phones know how to handle them (tested with linksys and aastra.) But I have no idea if there are any side effects.
>
> Regards,
> Vallimamod
> .
>
>
>
>    
>
>
>
> On Oct 7, 2010, at 2:44 PM, Vallimamod ABDULLAH wrote:
>
>    
>> Hello Anca,
>>
>> Thank you for your quick answer.
>> If I understand correctly, with this patch, all the notify requests should have state='partial'. My test shows that the publish request has actually state="partial" but the corresponding notify still have state="full" for the second call. So nothing change in the notifications received by the phone. Have I missed something ?
>>
>> Here is the notify body received by the phone when the second call is cancelled:
>>
>> <?xml version="1.0"?>
>> <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="6"           state="full" entity="33500009700 at sipb02.domain.com"><dialog id="0d61b71c6dd00dd3785629463ba23a4e at 192.168.5.122" call-id="0d61b71c6dd00dd3785629463ba23a4e at 192.168.5.122" direction="recipient"><state>terminated</state><remote><identity>sip:2036 at 192.168.5.122</identity><target uri="sip:2036 at 192.168.5.122"/></remote><local><identity>sip:33500009700 at sipb02.domain.com</identity><target uri="sip:33500009700 at sipb02.domain.com"/></local></dialog></dialog-info>
>>
>>
>> Regards,
>> Vallimamod
>> .
>>
>>
>>
>> On Oct 7, 2010, at 12:43 PM, Anca Vamanu wrote:
>>
>>      
>>> Hi Vallimamod,
>>>
>>> There was an issue in pua_dialoginfo module indeed - it always sent
>>> publish messages with state="full" so in the scenario you described,
>>> when opensips started sending notifies about the second call it deleted
>>> the state about the previous one. I have now fixed this in both 1.6
>>> branch and trunk. Please update from svn.
>>>        
>
>
>    
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>    
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opensips.org/pipermail/users/attachments/20101007/3aa2bb5e/attachment.htm