Re: [Users] dialog module configuration question

Hello I also have a similar problem. The dialog module doesn't detect the BYE message. I'm using ver 1.1.1. My configuration is as follow: 2 Wifi SIP phones (BCM) connected to the same Access Point and the OpenSER runs on a PC. Attached the debug log, ethereal sniffing on the *Wire* LAN and my config file. For both ACK and BYE message, the dialog module prints the error DEBUG:dialog:dlg_onroute: Route param 'did' not found Did you find a solution? If you want to check the attached files: Caller: 192.168.13.166 Callee: 192.168.13.101 SIP Proxy: 192.168.13.86 Regards, Michel. Bogdan-Andrei Iancu wrote: > Hi Andy, > > in client config, you need to add "[routes]" for ACK and BYE > messages (take a look at the cfg I sent you) > > regards, > bogdan > > Andy Pyles wrote: >> I Just re-read the docs on loose_route(). So please disregard this >> question. ( only processed if Route: header is present. Which isn't >> present because Record-route: header isn't being sent to caller ) >> >> So, I'm still trying to figure out why record-route: header is not >> being sent to caller. >> >> >> On 2/22/07, Andy Pyles <andy.pyles(a)gmail.com> wrote: >>> Hi Bogdan, >>> >>> After running additional debugs, for some reason the call to >>> loose_route() is failing. >>> >>> if (loose_route()) { >>> # mark routing logic in request >>> xlog("L_INFO", "loose_route() succeeded\n "); >>> route(1); >>> } else{ >>> xlog("L_INFO", "loose_route()failed - M=$rm RURI=$ru F=$fu >>> T=$tu IP=$si ID=$ci\n"); >>> }; >>> >>> >>> Any ideas why this could be occuring? >>> >>> >>> On 2/22/07, Andy Pyles <andy.pyles(a)gmail.com> wrote: >>> > HI Bogdan, >>> > >>> > I'm already using an almsot identical version of uas.xml and >>> uac.xml ( >>> > yes rrs=true) is being used. However in your version the uas.xml >>> > doesn't have rrs="true" after initial invite which I think is >>> needed. >>> > See as you can see below, setting rrs="true" for uac will only >>> work if >>> > it receives a Record-Route header in the 200OK which it's not. >>> > >>> > In this case, ALL messages from openser to sipp uac do not >>> contain the >>> > Record-route header. So I don't think it's a sipp problem, but an >>> > openser configuration problem. I've tried using other devices >>> for a >>> > uac, such as x-lite but the same problem. >>> > >>> > Andy >>> > >>> > On 2/22/07, Bogdan-Andrei Iancu <bogdan(a)voice-system.ro> wrote: >>> > > Hi Andy, >>> > > >>> > > so it's about sipp :D - I remember I had some hard times to >>> make it work >>> > > with record Route. >>> > > >>> > > take a look at the attached files, they might help you. >>> > > >>> > > regards, >>> > > bogdan >>> > > >>> > > Andy Pyles wrote: >>> > > > HI Bogdan, >>> > > > >>> > > > thanks for your reply. >>> > > > yes you are correct. The Bye doesn't have the Route header. >>> > > > It appears the the 200 OK sent to the caller doesn't contain a >>> > > > Record-route header. >>> > > > Messages between openser and callee contain record-route >>> information, >>> > > > but messages between caller and openser do not. >>> > > > Is there a way to enable that? >>> > > > >>> > > > Here's more detail: >>> > > > 192.168.0.101 = Caller (sipp) >>> > > > 1.2.3.4 = openser >>> > > > 4.3.2.1 = callee ( sipp) >>> > > > >>> > > > >>> > > > 1.) 192.168.0.101 -> 1.2.3.4 SIP/SDP Request: INVITE >>> > > > sip:service@1.2.3.4:5060, with session description >>> > > > 2.) 1.2.3.4 -> 192.168.0.101 SIP Status: 100 Giving a try >>> > > > 3.) 1.2.3.4 -> 4.3.2.1 SIP/SDP Request: INVITE >>> > > > sip:service@4.3.2.1:5060, with session description >>> > > > 4.) 4.3.2.1 -> 1.2.3.4 SIP Status: 180 Ringing >>> > > > 5.) 4.3.2.1 -> 1.2.3.4 SIP/SDP Status: 200 OK, >>> with session >>> > > > description >>> > > > 6.) 1.2.3.4 -> 192.168.0.101 SIP Status: 180 Ringing >>> > > > 7.) 1.2.3.4 -> 192.168.0.101 SIP/SDP Status: 200 OK, >>> with session >>> > > > description >>> > > > 8.) 192.168.0.101 -> 1.2.3.4 SIP Request: ACK >>> > > > sip:service@1.2.3.4:5060 >>> > > > 9.) 1.2.3.4 -> 4.3.2.1 SIP Request: ACK >>> sip:service@4.3.2.1:5060 >>> > > > 10.) 192.168.0.101 -> 1.2.3.4 SIP Request: BYE >>> > > > sip:service@1.2.3.4:5060 >>> > > > 11.) 1.2.3.4 -> 4.3.2.1 SIP Request: BYE >>> sip:service@4.3.2.1:5060 >>> > > > 12.) 4.3.2.1 -> 1.2.3.4 SIP Status: 200 OK >>> > > > 13.) 1.2.3.4 -> 192.168.0.101 SIP Status: 200 OK >>> > > > >>> > > > --- >>> > > > Packets 6,7 and following contain no Record-route information. >>> > > > The other weird thing is that openser is passing on the >>> Route: header >>> > > > it recevied from callee to the caller. >>> > > > >>> > > > >>> > > > Please see attached for complete ngrep output. >>> > > > >>> > > > >>> > > > On 2/21/07, Bogdan-Andrei Iancu <bogdan(a)voice-system.ro> wrote: >>> > > >> Hi Andy, >>> > > >> >>> > > >> could you check on the net if the BYE contain the Route hdr >>> added to >>> > > >> INVITE as Record-Route? I have some doubts on this as I see: >>> > > >> 0(966) find_first_route: No Route headers found >>> > > >> 0(966) loose_route: There is no Route HF >>> > > >> >>> > > >> and if the BYE is not identified, the dialog is not closed. >>> > > >> >>> > > >> regards, >>> > > >> bogdan >>> > > >> >>> > > >> Andy Pyles wrote: >>> > > >> > Hello, >>> > > >> > >>> > > >> > I have a question on how to configure the dialog module >>> ( 1.2.x from >>> > > >> > cvs yesterday ). >>> > > >> > >>> > > >> > With my config, ( attached) I can make calls and have >>> verified that >>> > > >> > the acc module is working correctly. >>> > > >> > >>> > > >> > My question is, when I enable the dialog module, I can >>> see that it is >>> > > >> > incrementing call count correctly, but when a bye is >>> received, the >>> > > >> > dialog:active_dialogs statistic is never decremented. >>> > > >> > >>> > > >> > In the debug level 9 logs, ( also attached) I see this >>> error after the >>> > > >> > 200OK is sent to the bye: >>> > > >> > >>> > > >> > 1(969) DBUG:dialog:unref_dlg: unref dlg 0xa7ce5a98 with 1 >>> > > >> (delete=0)-> 1 >>> > > >> > >>> > > >> > Is this a case of one of the timers being set too short? >>> by the way >>> > > >> > using a variable call length from well under a second ( >>> using sipp ) >>> > > >> > to 20 second call doesnt' seem to make a difference . >>> > > >> > >>> > > >> > >>> > > >> > Thanks, >>> > > >> > Andy >>> > > >> > > > _______________________________________________ > Users mailing list > Users(a)openser.org > http://openser.org/cgi-bin/mailman/listinfo/users > >