[Kamailio-Devel] pua_dialoginfo, not notified for terminated call

[Eric PTAK]

Hi Klaus,

I first thought of a race condition, but it seems a little bit more
complicated.
After a day of debug, I didn't really progressed. But I've spotted at least
two points :

* first, I don't know why yet, it happens that pua don't get the 200 OK
response to it's publishes whereas it has been received by the core. and so,
the next publish get 412 error.
* second, sometimes, presence_dialoginfo, notify why a version="00000000"
inside the XML...

Regards,

Eric.

2009/3/9 Klaus Darilion <klaus.mailinglists at pernau.at>

>
>
> Klaus Darilion schrieb:
>
> Eric PTAK wrote:
>>
>>> Hi everyone,
>>>  As the previous issue is now fixed, I'm now facing a new one.
>>>  In fact everything goes fine with a simple architecture, with an INVITE
>>> scenarii between two peer with just Kam in the middle.
>>> But the things goes wrongs in our more complex architecture, with an
>>> Asterix on top of Kam and another proprietary element (Mitel).
>>> It happens that the subscriber don't get notified  when the call go in
>>> terminated state.
>>> Doing my research I wondered if it shouldn't be the re-INVITE sent by the
>>> Mitel element which can confuse pua_dialoginfo.
>>> (for exemple Mitel send a re-INVITE to close the stream before sending
>>> the BYE)
>>>  So my first question is quite simple : does pua_dialoginfo support
>>> re-INVITE ?
>>>
>>
>> never tested but it should work.
>>
>
> Maybe there is a race condition, that the BYE callback overtakes the
> reINVITE callback.
>
> regards
> klaus
>
>
>> klaus
>>
>> _______________________________________________
>> Kamailio (OpenSER) - Devel mailing list
>> Devel at lists.kamailio.org
>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/devel
>> http://lists.openser-project.org/cgi-bin/mailman/listinfo/devel
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kamailio.org/pipermail/devel/attachments/20090309/6b2966ba/attachment.htm