On Thu, May 24, 2012 at 6:41 PM, Vitaliy Aleksandrov vitalik.voip@gmail.com wrote:
Thanks for the reply.
We have already came to the same conclusion by some testing in our lab. It seems its a bug in provider which not constructing BYE message properly.
But i'm interested in if its possible to detect the fault in this BYE and construct a new one and then relay it to the UAC.
I mean can i do this :
contact-header = INVITE's contact-header if (contact-header != BYE's ruri) { construct BYE message with contact header t_relay() }
Cheers aft
Hi aft,
I think to do what you want you can save Contact field + callid pair taken from the INVITEs that comes from your side. Then when BYE comes from such provider you should find a correct Contact for that call-id and if it exists and not equal to R-URI you can rewrite it.
For example to write to R-URI value from $var(correct_ruri) you can use $ru = $var(correct_ruri); statement.
What about a place where contact can be saved, i think htable will be the nice one. Please pay attention to "autoexpire" parameter of htable module. You should take care about the staled records to avoid memory usage problems.
Cheers, Vitaliy Aleksandrov
Hi Aleksandrov,
Thanks for the suggestion. I was playing with the dialog module to achieve the same thing. But your suggestion seems more lightweight ans sensible than invoking full blown dialog functionality most of which i do not need for my purpose.
I will try your approach and post the update.
In the mean time, my dialog module approach is not working either as expected.
I used dialog module like following :
#!ifdef WITH_DLG modparam("dialog", "enable_stats",0) modparam("dialog", "dlg_flag",DLG_FLAG ) modparam("dialog", "default_timeout",100) #!endif
request_route { # per request initial checks route(REQINIT); #!ifdef WITH_DLG if (is_method("INVITE") && !has_totag()){ $dlg_ctx(timeout_route) = 12; $dlg_ctx(timeout_bye) = 1; } dlg_manage(); #!endif
................................................................... ................................................................... route[WITHINDLG] {
if (has_totag()) { # sequential request withing a dialog should # take the path determined by record-routing #!ifdef WITH_DLG if (is_method("BYE")){ dlg_get ("$ci","$ft","$tt"); dlg_bye ("all"); return; } #!endif if (loose_route()) { if (is_method("BYE")) { setflag(FLT_ACC); # do accounting ... setflag(FLT_ACCFAILED); # ... even if tansaction fails .................................................................... ....................................................................
#!ifdef WITH_DLG route[12]{ dlg_bye("all"); xdbg("bye everyone"); } #!endif
I'm not worried about timeout right now. This does not work. When bye message arrives i can see the following in kamailio log :
[4016]: DEBUG: <core> [parser/msg_parser.c:624]: SIP Request: [4016]: DEBUG: <core> [parser/msg_parser.c:626]: method: <BYE> [4016]: DEBUG: <core> [parser/msg_parser.c:628]: uri: sip:1010@x.x.x.x:5060 [4016]: DEBUG: <core> [parser/msg_parser.c:630]: version: <SIP/2.0> [4016]: DEBUG: <core> [parser/parse_via.c:1289]: Found param type 232, <branch> = <z9hG4bK-d8754z-d51775683d085d3b-1---d8754z->; state=16 [4016]: DEBUG: <core> [parser/parse_via.c:2564]: end of header reached, state=5 [4016]: DEBUG: <core> [parser/msg_parser.c:511]: parse_headers: Via found, flags=2 [4016]: DEBUG: <core> [parser/msg_parser.c:513]: parse_headers: this is the first via -- [4016]: DEBUG: <core> [parser/msg_parser.c:190]: DEBUG: to body ["1010"sip:1010@x.x.x.x] [4016]: DEBUG: <core> [parser/msg_parser.c:168]: get_hdr_field: cseq <CSeq>: <3> <BYE> [4016]: DEBUG: <core> [parser/msg_parser.c:202]: DEBUG: get_hdr_body : content_length=0 [4016]: DEBUG: <core> [parser/msg_parser.c:104]: found end of header [4016]: DEBUG: <core> [parser/parse_to.c:178]: DEBUG: add_param: tag=e06d7c6a [4016]: DEBUG: <core> [parser/parse_to.c:802]: end of header reached, state=29 [4016]: DEBUG: sanity [mod_sanity.c:255]: sanity checks result: 1 [4016]: DEBUG: dialog [dlg_hash.c:652]: no dialog callid='OTljOWU1NTU1NWE1ZmEzZGE4NDNhNGQyNDE2MmUzZDc.' found [4016]: DEBUG: dialog [dlg_hash.c:683]: no dialog callid='OTljOWU1NTU1NWE1ZmEzZGE4NDNhNGQyNDE2MmUzZDc.' found [4016]: DEBUG: dialog [dlg_handlers.c:1166]: Callid 'OTljOWU1NTU1NWE1ZmEzZGE4NDNhNGQyNDE2MmUzZDc.' not found ..... ..... [4016]: DEBUG: dialog [dlg_hash.c:652]: no dialog callid='OTljOWU1NTU1NWE1ZmEzZGE4NDNhNGQyNDE2MmUzZDc.' found [4016]: DEBUG: dialog [dlg_hash.c:683]: no dialog callid='OTljOWU1NTU1NWE1ZmEzZGE4NDNhNGQyNDE2MmUzZDc.' found
After some inspection i found out this :
[4017]: DEBUG: dialog [dlg_hash.c:646]: dialog callid='OTljOWU1NTU1NWE1ZmEzZGE4NDNhNGQyNDE2MmUzZDc.' found on entry 321, dir=1 [4017]: DEBUG: dialog [dlg_profile.c:406]: setting current dialog [321:12199] [4017]: DEBUG: dialog [dlg_hash.c:940]: dialog 0xb5d10150 changed from state 5 to state 5, due event 6 (ref 2) [4017]: DEBUG: dialog [dlg_hash.c:753]: unref dlg 0xb5d10150 with 1 -> 1 -- [4017]: DEBUG: tm [t_lookup.c:1379]: DEBUG: t_newtran: msg id=6 , global msg id=5 , T on entrance=0xffffffff [4017]: DEBUG: tm [t_lookup.c:527]: t_lookup_request: start searching: hash=53621, isACK=1 [4017]: DEBUG: tm [t_lookup.c:485]: DEBUG: RFC3261 transaction matching failed [4017]: DEBUG: tm [t_lookup.c:709]: DEBUG: t_lookup_request: no transaction found [4017]: DEBUG: tm [t_funcs.c:315]: SER: forwarding ACK statelessly [4017]: DEBUG: <core> [receive.c:293]: receive_msg: cleaning up [4021]: DEBUG: tm [t_hooks.c:288]: DBG: trans=0xb5d0e930, callback type 131072, id 0 entered [4021]: DEBUG: dialog [dlg_hash.c:588]: ref dlg 0xb5d10150 with 1 -> 2 [4021]: DEBUG: dialog [dlg_hash.c:590]: dialog id=12199 found on entry 321 [4021]: DEBUG: dialog [dlg_hash.c:753]: unref dlg 0xb5d10150 with 2 -> 0 [4021]: DEBUG: dialog [dlg_hash.c:753]: ref <=0 for dialog 0xb5d10150 [4021]: DEBUG: dialog [dlg_hash.c:315]: destroying dialog 0xb5d10150 (ref 0) [4021]: DEBUG: dialog [dlg_hash.c:331]: removed timer for dlg 0xb5d10150 [321:12199] with clid 'OTljOWU1NTU1NWE1ZmEzZGE4NDNhNGQyNDE2MmUzZDc.' and tags 'e06d7c6a' '' [4021]: DEBUG: dialog [dlg_handlers.c:322]: freeing dlg iuid [321:12199] (0xb5d0f5c0) [4021]: DEBUG: dialog [dlg_handlers.c:322]: freeing dlg iuid [321:12199] (0xb5d100d0)
It seems to me that after forwarding ACK, the dialog entry is removed for some reason. And hence when BYE arrives and i try to generate a dlg_bye() by searching the dialog, no dialog is found.
Cheers.
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users