Re: [OpenSIPS-Users] DIALOG not deleted on BYE
Hi Bogdan, The problem is fixed with the changes in dlg_handlers.c rev 5806. Thanks a lot 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 dialogthis 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:: 240f6fed145ac8251915f50d3d54b...@10.20.138.105 >>> from_uri:: sip:9904...@10.20.138.105:5100 >>> from_tag:: as619609ab >>> caller_contact:: sip:9904...@10.20.138.105:5100 >>> caller_cseq:: 102 >>> caller_route_set:: >>> caller_bind_addr:: udp:10.20.138.125:5100 >>> to_uri:: sip:4315302...@asn2.domain.de:5100 >>> to_tag:: ZdwulVArZJyQZ6lMpIk9pvPlzPV73upl >>> callee_contact:: sip:4315302...@10.20.139.62:5060 >>> callee_cseq:: 102 >>> callee_route_set:: >>> >>> 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
Re: [OpenSIPS-Users] DIALOG not deleted on BYE
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 dialogthis 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:: 240f6fed145ac8251915f50d3d54b...@10.20.138.105 >> from_uri:: sip:9904...@10.20.138.105:5100 >> from_tag:: as619609ab >> caller_contact:: sip:9904...@10.20.138.105:5100 >> caller_cseq:: 102 >> caller_route_set:: >> caller_bind_addr:: udp:10.20.138.125:5100 >> to_uri:: sip:4315302...@asn2.domain.de:5100 >> to_tag:: ZdwulVArZJyQZ6lMpIk9pvPlzPV73upl >> callee_contact:: sip:4315302...@10.20.139.62:5060 >> callee_cseq:: 102 >> callee_route_set:: >> >> 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
Re: [OpenSIPS-Users] DIALOG not deleted on BYE
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 dialogthis 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:: 240f6fed145ac8251915f50d3d54b...@10.20.138.105 > from_uri:: sip:9904...@10.20.138.105:5100 > from_tag:: as619609ab > caller_contact:: sip:9904...@10.20.138.105:5100 > caller_cseq:: 102 > caller_route_set:: > caller_bind_addr:: udp:10.20.138.125:5100 > to_uri:: sip:4315302...@asn2.domain.de:5100 > to_tag:: ZdwulVArZJyQZ6lMpIk9pvPlzPV73upl > callee_contact:: sip:4315302...@10.20.139.62:5060 > callee_cseq:: 102 > callee_route_set:: > > 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 > Users@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > >>> ___ >>> Users m
Re: [OpenSIPS-Users] DIALOG not deleted on BYE
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 dialogthis 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:: 240f6fed145ac8251915f50d3d54b...@10.20.138.105 from_uri:: sip:9904...@10.20.138.105:5100 from_tag:: as619609ab caller_contact:: sip:9904...@10.20.138.105:5100 caller_cseq:: 102 caller_route_set:: caller_bind_addr:: udp:10.20.138.125:5100 to_uri:: sip:4315302...@asn2.domain.de:5100 to_tag:: ZdwulVArZJyQZ6lMpIk9pvPlzPV73upl callee_contact:: sip:4315302...@10.20.139.62:5060 callee_cseq:: 102 callee_route_set:: 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 Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >>> >>> >> ___ >> Users mailing list >> Users@lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >> > > > ___ > Users mailing list > Users@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > ___ Users mailing list Users@lists.opensips.o
Re: [OpenSIPS-Users] DIALOG not deleted on BYE
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 dialogthis 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:: 240f6fed145ac8251915f50d3d54b...@10.20.138.105 >>> from_uri:: sip:9904...@10.20.138.105:5100 >>> from_tag:: as619609ab >>> caller_contact:: sip:9904...@10.20.138.105:5100 >>> caller_cseq:: 102 >>> caller_route_set:: >>> caller_bind_addr:: udp:10.20.138.125:5100 >>> to_uri:: sip:4315302...@asn2.domain.de:5100 >>> to_tag:: ZdwulVArZJyQZ6lMpIk9pvPlzPV73upl >>> callee_contact:: sip:4315302...@10.20.139.62:5060 >>> callee_cseq:: 102 >>> callee_route_set:: >>> >>> 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 >>> Users@lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >>> >> >> > > > ___ > Users mailing list > Users@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] DIALOG not deleted on BYE
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:: 240f6fed145ac8251915f50d3d54b...@10.20.138.105 >> from_uri:: sip:9904...@10.20.138.105:5100 >> from_tag:: as619609ab >> caller_contact:: sip:9904...@10.20.138.105:5100 >> caller_cseq:: 102 >> caller_route_set:: >> caller_bind_addr:: udp:10.20.138.125:5100 >> to_uri:: sip:4315302...@asn2.domain.de:5100 >> to_tag:: ZdwulVArZJyQZ6lMpIk9pvPlzPV73upl >> callee_contact:: sip:4315302...@10.20.139.62:5060 >> callee_cseq:: 102 >> callee_route_set:: >> >> 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 >> Users@lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > > > ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] DIALOG not deleted on BYE
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. Unfort I was not able to find out what the states and the events means. 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? 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:: 240f6fed145ac8251915f50d3d54b...@10.20.138.105 > from_uri:: sip:9904...@10.20.138.105:5100 > from_tag:: as619609ab > caller_contact:: sip:9904...@10.20.138.105:5100 > caller_cseq:: 102 > caller_route_set:: > caller_bind_addr:: udp:10.20.138.125:5100 > to_uri:: sip:4315302...@asn2.domain.de:5100 > to_tag:: ZdwulVArZJyQZ6lMpIk9pvPlzPV73upl > callee_contact:: sip:4315302...@10.20.139.62:5060 > callee_cseq:: 102 > callee_route_set:: > > 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 > Users@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- kiste lat: 54.322684, lon: 10.13586 ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] DIALOG not deleted on BYE
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:: 240f6fed145ac8251915f50d3d54b...@10.20.138.105 from_uri:: sip:9904...@10.20.138.105:5100 from_tag:: as619609ab caller_contact:: sip:9904...@10.20.138.105:5100 caller_cseq:: 102 caller_route_set:: caller_bind_addr:: udp:10.20.138.125:5100 to_uri:: sip:4315302...@asn2.domain.de:5100 to_tag:: ZdwulVArZJyQZ6lMpIk9pvPlzPV73upl callee_contact:: sip:4315302...@10.20.139.62:5060 callee_cseq:: 102 callee_route_set:: 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 > -- kiste lat: 54.322684, lon: 10.13586 dialog.gz Description: GNU Zip compressed data ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] DIALOG not deleted on BYE
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 -- kiste lat: 54.322684, lon: 10.13586 ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
