Bogdan, Sorry for bothering again. I tried the latest trunk from svn and opensips is dying after accessing the mysql db.
I will attach the trace. BR Uwe Bogdan-Andrei Iancu schrieb: > OK - with the fix from SVN you should be able to call loose_route() as > many times you want without any risk - just let me know if it works as > expected. > > Regards, > Bogdan > > Uwe Kastens wrote: >> Hi Bogdan, >> >> Again, thanks a lot for your help. >> >> The loose_route() seems to cause the problem, but somehow its needed to >> pass byes correctly to the UA. So I need to work a little on my skript. >> >> I will try the 1.6 ASAP and let you know the result. >> >> BR >> >> Uwe >> >> >> >> Bogdan-Andrei Iancu schrieb: >> >>> If you could test, a fix is available on 1.6 (trunk) version - if ok, I >>> will do the backport. >>> >>> Regards, >>> Bogdan >>> >>> Bogdan-Andrei Iancu wrote: >>> >>>> Hi Uwe, >>>> >>>> Thanks for the traces. Looking at the opensips logs, I say you do >>>> loose_route() twice for the ACK which looks twice for the dialog and >>>> increase the ref twice for the dialog....this is why the ref never >>>> gets back to 0 to allow the dialog to be destroyed.. >>>> >>>> Could you confirm this for me ? >>>> >>>> even if it's a script error , the dialog module should cope with it..I >>>> will look for a fix. >>>> >>>> Thanks and regards, >>>> Bogdan >>>> >>>> Bogdan-Andrei Iancu wrote: >>>> >>>> >>>>> Hi Uwe, >>>>> >>>>> >>>>> Uwe Kastens wrote: >>>>> >>>>>> Hi again, >>>>>> >>>>>> So I think it might be a bug. One direction (UA to PSTN) works >>>>>> everytime >>>>>> perfectly. It doesn't matter on which side the BYE is sent. If I try >>>>>> the >>>>>> other direction, the dialog will not be removed. Again it won't >>>>>> matter >>>>>> on which side the BYE is sent - the dialog will stay active. >>>>>> >>>>> yes, it sounds like. >>>>> >>>>>> Unfort I was not able to find out what the states and the events >>>>>> means. >>>>>> >>>>> You can find the meaning of each state in: modules/dialog/dlg_hash.h >>>>> >>>>> >>>>> >>>>>> So its not easy to debug further. >>>>>> >>>>>> Working direction: >>>>>> DBG:dialog:next_state_dlg: dialog 0xd7a30870 changed from state 1 to >>>>>> state 2, due event 2 >>>>>> DBG:dialog:next_state_dlg: dialog 0xd7a30870 changed from state 2 to >>>>>> state 3, due event 3 >>>>>> DBG:dialog:next_state_dlg: dialog 0xd7a30870 changed from state 3 to >>>>>> state 4, due event 6 >>>>>> DBG:dialog:next_state_dlg: dialog 0xd7a30870 changed from state 4 to >>>>>> state 4, due event 6 >>>>>> DBG:dialog:next_state_dlg: dialog 0xd7a30870 changed from state 4 to >>>>>> state 4, due event 1 >>>>>> >>>>>> Not Working >>>>>> DBG:dialog:next_state_dlg: dialog 0xd7a2c6e0 changed from state 1 to >>>>>> state 2, due event 2 >>>>>> DBG:dialog:next_state_dlg: dialog 0xd7a2c6e0 changed from state 2 to >>>>>> state 2, due event 2 >>>>>> DBG:dialog:next_state_dlg: dialog 0xd7a2c6e0 changed from state 2 to >>>>>> state 3, due event 3 >>>>>> DBG:dialog:next_state_dlg: dialog 0xd7a2c6e0 changed from state 3 to >>>>>> state 5, due event 7 >>>>>> DBG:dialog:next_state_dlg: dialog 0xd7a2c6e0 changed from state 5 to >>>>>> state 5, due event 1 >>>>>> >>>>>> Anyone could help please? >>>>>> >>>>> I can try : ) >>>>> >>>>> could you (privately if needed) please send me the the full logs for >>>>> the entire call (debug=6) - for the non working part. >>>>> >>>>> Thanks and regards, >>>>> Bogdan >>>>> >>>>>> BR >>>>>> >>>>>> Uwe >>>>>> >>>>>> >>>>>> Uwe Kastens schrieb: >>>>>> >>>>>>> Hello again, >>>>>>> >>>>>>> I think the dialog is destroyed, if no reference is left. And so I >>>>>>> asume >>>>>>> the dialog is missing the ACK for the BYE. Or do I need to unref it >>>>>>> manually via reply_route? I will attach the log. >>>>>>> >>>>>>> dialog:: hash=440:1838775488 >>>>>>> state:: 5 >>>>>>> user_flags:: 0 >>>>>>> timestart:: 1246005835 >>>>>>> timeout:: 0 >>>>>>> callid:: [email protected] >>>>>>> from_uri:: sip:[email protected]:5100 >>>>>>> from_tag:: as619609ab >>>>>>> caller_contact:: sip:[email protected]:5100 >>>>>>> caller_cseq:: 102 >>>>>>> caller_route_set:: >>>>>>> caller_bind_addr:: udp:10.20.138.125:5100 >>>>>>> to_uri:: sip:[email protected]:5100 >>>>>>> to_tag:: ZdwulVArZJyQZ6lMpIk9pvPlzPV73upl >>>>>>> callee_contact:: sip:[email protected]:5060 >>>>>>> callee_cseq:: 102 >>>>>>> callee_route_set:: >>>>>>> <sip:10.20.138.145;lr;ftag=as619609ab;did=8b1.8ddb7a7> >>>>>>> callee_bind_addr:: udp:10.20.138.125:5100 >>>>>>> >>>>>>> BR >>>>>>> >>>>>>> Uwe >>>>>>> >>>>>>> Uwe Kastens schrieb: >>>>>>> >>>>>>>> Hello list, >>>>>>>> >>>>>>>> I am using DIALOG for the Concurrent calls limitation following the >>>>>>>> tutorial. Its working pretty well - in one direction :-) >>>>>>>> >>>>>>>> DIALOGs from UA to PSTN are deleted after processing the BYE. In >>>>>>>> the >>>>>>>> other direction I see that the BYE is processed correctly, but >>>>>>>> DIALOGs >>>>>>>> are staying in state 5. >>>>>>>> >>>>>>>> Where can I find the documentation for the states? Which will >>>>>>>> delete a >>>>>>>> DIALOG. The BYE or the ack for the BYE? >>>>>>>> >>>>>>>> >>>>>>>> BR >>>>>>>> >>>>>>>> Uwe >>>>>>>> >>>>>>>> >>>>>>> ------------------------------------------------------------------------ >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Users mailing list >>>>>>> [email protected] >>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>>>> >>>>>> >>>>> _______________________________________________ >>>>> Users mailing list >>>>> [email protected] >>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>> >>>>> >>>> _______________________________________________ >>>> Users mailing list >>>> [email protected] >>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>> >>>> >>> >> >> >> > > -- kiste lat: 54.322684, lon: 10.13586
trace.gz
Description: GNU Zip compressed data
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
