Re: [Users] sst bye issue

Hi Ron, thanks for the note. Ok, I see your point.I agree that the call is eventually terminated, but as there is no CDR generated, how do you handle CDR's, as openser never sends a 200 ok to the bye? Andy On 3/5/07, Ron Winacott &lt;ronw(a)somanetworks.com&gt; wrote: > Andy, > I am not sure where your issue is (or I am missing it, which is > most likely the case). The SST module is to protect the OpenSER server > from memory/dialog leaks due to catastrophic AU failures. What I see in > the dialog is a normal (abnormal) termination due to time out if the > reINVITE/BYE. The sst timer in OpenSER did *not* fire. The AU (149) > terminated the call because the reINVITE timed out (200 OK not seen) and > sent a BYE. OpenSER seen the BYE and terminated the dialog. (as a normal > termination) > > Where SST comes into play is if both sides are killed, or the AU that > agreed to send the reINVITE dies. The reINVITE is send at about 80% of > the time interval (depending on the AU) and if the full 100% of the time > interval passes, the SST interval timer will fire and OpenSER will "deem" > the call as dead and release all local resources it is holding as its > role as a proxy. > > In your case, the AU(149) should timeout on the BYEs missing 200 OK and > terminate the call. Because OpenSER is acting as a proxy and *not* as a > B2B user agent, it cannot inject 200 OK's or BYEs into the dialog. > > I currently use the SST module in conjunction with the dialog modules > call backs into a proprietary OpenSER module (to SOMA) that cleans up > other locally held resources in the radio network. It is needed because > of the unreliability of the radio links. > > As I stated above, if I am missing the point, please reply and I hope > this helps to clear things up with the SST module. > > ronw (karwin) > > On Monday 05 March 2007 1:55 am, Andy Pyles wrote: > > Hi, > > > > I'm trying to understand how the SST handles the case of a UA that is > > off the network when the session timer expires. > > > > I have the following configuration: > > x-lite has session timer support, so using that to test the module. > > min session timer is set to 91 seconds. > > > > x-lite (149) - > openser --> x-lite ( 101) > > INVITE ---> > > -> INVITE > > <--100 trying > > 100 trying <----- > > <-180 ringing > > 180 ringing <-- > > <-200 ok > > 200 ok <--- > > ack ---> > > -->ack > > Call is setup at this point. > > I then remove the power supply from 101. > > some seconds later we see this: > > > > INVITE -------> --> INVITE > > 100 trying <------ > > ...... ( no response from 101) > > <--- 408 timeout > > BYE ----------> > > .... > > Ok at this point openser never sends a 200 ok to the BYE. > > > > >From what I can see in the SST module, that it deletes the dialog.in > > > > memory, but not sure how that will help here. > > > > > > --- debug logs -- where the FIRST bye comes in from 149: > > > > 0(5526) SIP Request: > > 0(5526) method: <BYE> > > 0(5526) uri: <sip:101@192.168.0.104:5061> > > 0(5526) version: <SIP/2.0> > > 0(5526) parse_headers: flags=2 > > 0(5526) Found param type 232, <branch> = > > <z9hG4bK-d87543-8f727a53ca51673e-1--d87543->; state=6 > > 0(5526) Found param type 235, <rport> = <n/a>; state=17 > > 0(5526) end of header reached, state=5 > > 0(5526) parse_headers: Via found, flags=2 > > 0(5526) parse_headers: this is the first via > > 0(5526) After parse_msg... > > 0(5526) preparing to run routing scripts... > > 0(5526) parse_headers: flags=100 > > 0(5526) DEBUG:maxfwd:is_maxfwd_present: value = 70 > > 0(5526) parse_headers: flags=10 > > 0(5526) DEBUG: add_param: tag=faea2a83cd5fd6c1 > > 0(5526) DEBUG:parse_to:end of header reached, state=29 > > 0(5526) DBUG:parse_to: display={"101"}, ruri={sip:101@192.168.0.101} > > 0(5526) DEBUG: get_hdr_field: <To> [51]; uri=[sip:101@192.168.0.101] > > 0(5526) DEBUG: to body ["101"<sip:101@192.168.0.101>] > > 0(5526) DEBUG: add_param: tag=5077431e > > 0(5526) DEBUG:parse_to:end of header reached, state=29 > > 0(5526) DBUG:parse_to: display={"149"}, ruri={sip:149@192.168.0.101} > > 0(5526) parse_headers: flags=200 > > 0(5526) is_preloaded: No > > 0(5526) grep_sock_info - checking if host==us: 13==13 && > > [192.168.0.104] == [192.168.0.101] > > 0(5526) grep_sock_info - checking if port 5060 matches port 5061 > > 0(5526) grep_sock_info - checking if host==us: 13==13 && > > [192.168.0.104] == [192.168.0.101] > > 0(5526) grep_sock_info - checking if port 5060 matches port 5061 > > 0(5526) DEBUG:check_self: host != me > > 0(5526) grep_sock_info - checking if host==us: 13==13 && > > [192.168.0.101] == [192.168.0.101] > > 0(5526) grep_sock_info - checking if port 5060 matches port 5060 > > 0(5526) after_loose: Topmost route URI: > > 'sip:192.168.0.101;lr;ftag=5077431e;did=5ff.8e4f3775' is me > > 0(5526) parse_headers: flags=200 > > 0(5526) get_hdr_field: cseq <CSeq>: <3> <BYE> > > 0(5526) DEBUG: get_hdr_body : content_length=0 > > 0(5526) found end of header > > 0(5526) find_next_route: No next Route HF found > > 0(5526) after_loose: No next URI found > > 0(5526) DBG:rr:run_rr_callbacks: callback id 0 entered with > > <lr;ftag=5077431e;did=5ff.8e4f3775> > > 0(5526) DEBUG:dialog:dlg_onroute: route param is '5ff.8e4f3775' > > (len=12) 0(5526) DEBUG:dialog:lookup_dlg: dialog id=1467217128 found on > > entry 4085 0(5526) DEBUG:dialog:run_create_callbacks: > > dialog=0xb5c65280, type=16 0(5526) > > DEBUG:sst_handlers.c:sst_dialog_terminate_CB:403: Terminating DID > > 0xb5c65280 session > > 0(5526) DEBUG:sst_handlers.c:sst_dialog_terminate_CB:410: Freeing the > > sst_info_t from dialog 0xb5c65280 > > 0(5526) DBUG:dialog:unref_dlg: unref dlg 0xb5c65280 with 2 > > (delete=1)-> 0 0(5526) DBUG:dialog:destroy_dlg: destroing dialog > > 0xb5c65280 > > 0(5526) loose_route() succeeded - M=BYE > > RURI=sip:101@192.168.0.104:5061 F=sip:149@192.168.0.101 > > T=sip:101@192.168.0.101 IP=192.168.0.102 > > ID=NTUzNzA5NWNjYmM5YWQ2MjQxYzgzZDdkZTRlMmQwODk. > > 0(5526) ERROR:dialog:dlg_status: res->ri = 5 > > 0(5526) comp_scriptvar: int 20 : 5 / 0 > > 0(5526) DEBUG: t_newtran: msg id=8 , global msg id=7 , T on > > entrance=0xffffffff 0(5526) parse_headers: flags=ffffffffffffffff > > 0(5526) parse_headers: flags=78 > > 0(5526) t_lookup_request: start searching: hash=10869, isACK=0 > > 0(5526) DEBUG: RFC3261 transaction matching failed > > 0(5526) DEBUG: t_lookup_request: no transaction found > > 0(5526) DBG: trans=0xb5c67b00, callback type 1, id 1 entered > > 0(5526) DBG: trans=0xb5c67b00, callback type 1, id 0 entered > > 0(5526) parse_headers: flags=78 > > 0(5526) DEBUG: mk_proxy: doing DNS lookup... > > 0(5526) check_via_address(192.168.0.102, 192.168.0.102, 0) > > 0(5526) DBG:check_against_rule_list: using list dns > > 0(5526) DEBUG:tm:set_timer: relative timeout is 500000 > > 0(5526) DEBUG: add_to_tail_of_timer[4]: 0xb5c67c4c (61500000) > > 0(5526) DEBUG:tm:set_timer: relative timeout is 30 > > 0(5526) DEBUG: add_to_tail_of_timer[0]: 0xb5c67c68 (91) > > 0(5526) DEBUG:tm:t_relay_to: new transaction fwd'ed > > 0(5526) DEBUG:tm:UNREF_UNSAFE: after is 0 > > 0(5526) DEBUG:destroy_avp_list: destroying list (nil) > > 0(5526) receive_msg: cleaning up > > > > --- > > > > thanks, > > Andy > > > > _______________________________________________ > > Users mailing list > > Users(a)openser.org > > http://openser.org/cgi-bin/mailman/listinfo/users > > -- > Ron Winacott - SOMA Networks, Inc. > --- > Chaos, panic and disorder...my work here is done.