Hunting parameter not working for multiple disconnect codes of same type

roco · October 17, 2024, 5:40pm

i have 408 “SIP transaction timeout” on which I don’t want to stop hunting
i have also 408 “Request Timeout” on which I want to stop hunting
the result is that every 408 code is stopped and no rerouting is done.
The problem is that if a termination is offline ( 408 “SIP transaction timeout” ), and I have multiple providers on cascade, the first provider offline will stop hunting on other providers, so basically the rerouting will not work.
How can I solve?
thanks

also, the rewrite is not working, on the line where I’ve set rewrite to 500, I can’t see this rewrite on origination side on cdr.

roco · October 18, 2024, 7:14am

Is there a way to assign to 408 sip transaction timeout a different code like 500 sip transaction timeout?
If i change it on db could it works?

dmitry.s · October 18, 2024, 11:40am

could you provide CDR and debug log.

roco · October 18, 2024, 12:04pm

sure, i made some attempts on a inexistent ip set on 2 different gateways in an lcr routing setting. the result is that after hitting the first gateway it doesn´t reroute on the other one. if I disable “stop sip hunting” on 408 “request timeout” in this way is working properly

dmitry.s · October 18, 2024, 12:33pm

there is no rerouting on your screenshot. This is just retransmissions.

roco · October 18, 2024, 12:44pm

408 “sip transaction timeout” stop hunting disabled
408 “request timeout” sip hunting enabled

this is the screenshot of this configuration.

it should reroute because the gateway ip is not existent but it is not happening (the retransmission is because it tries to contact the gateway, normal behaviour).
if i enable hunting on 408 “request timeout” it will do the reroute.

Basically 408 “sip transaction timeout” is like a ghost code not rerouted by the switch because “request timeout” has some kind of priority or possibly is not managed as a return code from the switch so it will use the generic 408 code with his rules

roco · October 19, 2024, 10:22am

Do you need something else for checking what’s happening?
Thank you very much

dmitry.s · October 19, 2024, 2:05pm

yes, I still waiting for sems debug log.

roco · October 19, 2024, 2:32pm

How can I extract debug log on a live server? Can you please let me know? Also it’s easy to replicate if you create two termination gateways with non existent ip and follow the steps I’ve already explained

roco · October 19, 2024, 2:37pm

ok I found a way, I isolate one node and extract the debug log for sending it to you

roco · October 19, 2024, 3:03pm

 [1571598/1571659] [sip/sip_trans.cpp:259] DEBUG: New timer of type A at time=8957 (repeated=4)(trans=0x7fd47c078470)
 [1571598/1571659] [sip/sip_trans.cpp:201] DEBUG: Clearing old timer of type A (timer=0x7fd48407a170)(trans=0x7fd47c078470)
 [1571598/1571659] [sip/sip_trans.cpp:218] DEBUG: Transaction timer expired: type=B, trans=0x7fd47c078470, eta=8582, t=8582
 [1571598/1571659] [sip/sip_trans.cpp:201] DEBUG: Clearing old timer of type B (timer=0x7fd47c0785f0)(trans=0x7fd47c078470)
 [1571598/1571659] [sip/trans_layer.cpp:2654] DEBUG: Transaction timeout!
 [1571598/1571659] [sip/sip_trans.cpp:259] DEBUG: New timer of type BL at time=10182 (repeated=0)(trans=0x7fd47c078470)
 [1571598/1571659] [SipCtrlInterface.cpp:1229] DEBUG: Received reply: 408 Timeout
 [1571598/1571659] [SipCtrlInterface.cpp:1230] DEBUG: reply.callid = <1-017EC0DF-6713C8EF00053E26-8B482700>
 [1571598/1571659] [SipCtrlInterface.cpp:1231] DEBUG: reply.from_tag = <1-5933A858-6713C8EF00053CCD-8B482700>
 [1571598/1571659] [SipCtrlInterface.cpp:1232] DEBUG: reply.to_tag = <>
 [1571598/1571659] [SipCtrlInterface.cpp:1233] DEBUG: reply.contact = <>
 [1571598/1571659] [SipCtrlInterface.cpp:1234] DEBUG: reply.to_uri = <>
 [1571598/1571659] [SipCtrlInterface.cpp:1235] DEBUG: cseq = <10>
 [1571598/1571659] [SipCtrlInterface.cpp:1236] DEBUG: reply.route = <>
 [1571598/1571659] [SipCtrlInterface.cpp:1237] DEBUG: hdrs = <>
 [1571598/1571659] [SipCtrlInterface.cpp:1238] DEBUG: body-ct = <>
 [1571598/1571659] [SipCtrlInterface.cpp:1242] DEBUG: ^^ M [1-017EC0DF-6713C8EF00053E26-8B482700|1-5933A858-6713C8EF00053CCD-8B482700] ru SIP reply 408 Timeout handled ^^
 [1571598/1571604] [AmSessionProcessor.cpp:178] DEBUG: processing events for  up to 1 sessions
 [1571598/1571604] [AmSession.cpp:440] DEBUG: vv S [1-017EC0DF-6713C8EF00053E26-8B482700|1-5933A858-6713C8EF00053CCD-8B482700] Trying, running, 1 UACTransPending, 0 usages vv
 [1571598/1571604] [yeti:SBCCallLeg.cpp:2327] DEBUG: process(0x7fd47c039720|1-5933A858-6713C8EF00053CCD-8B482700,legB)
 [1571598/1571604] [yeti:SBCCallLeg.cpp:2365] DEBUG: reply event  code: 408, reason:'Timeout'
 [1571598/1571604] [AmSession.cpp:756] DEBUG: AmSession processing event
 [1571598/1571604] [AmBasicSipDialog.cpp:634] DEBUG: onRxReply(rep = 408 Timeout): transaction found!
 [1571598/1571604] [AmBasicSipDialog.cpp:125] DEBUG: setting SIP dialog status: Trying->Disconnected
 [1571598/1571604] [AmOfferAnswer.cpp:202] DEBUG: after 408 reply to INVITE: resetting OA state
 [1571598/1571604] [AmOfferAnswer.cpp:70] DEBUG: setting SIP dialog O/A status: OfferSent->None
 [1571598/1571604] [yeti:SBCCallLeg.cpp:2128] DEBUG: onRemoteDisappeared(0x7fd47c039720,legB)
 [1571598/1571604] [yeti:SBCCallLeg.cpp:2009] DEBUG: onSipReply: 408 Timeout (fwd=1)
 [1571598/1571604] [yeti:SBCCallLeg.cpp:2010] DEBUG: onSipReply: content-type =
 [1571598/1571604] [uac_auth:UACAuth.cpp:442] DEBUG: [0x7fd3e002c7c0] UACAuth::onSipReply() code:408
 [1571598/1571604] [yeti:cdr/Cdr.cpp:236] DEBUG: Cdr::update_with_sip_reply(AmSipReply)
 [1571598/1571604] [yeti:CallLeg.cpp:859] DEBUG: 1-5933A858-6713C8EF00053CCD-8B482700: SIP reply 408/10 INVITE (to relayed request) received in NoReply state 
 [1571598/1571604] [AmB2BSession.cpp:553] DEBUG: onSipReply: INVITE -> 408 Timeout (fwd=true), c-t=
 [1571598/1571604] [AmB2BSession.cpp:584] DEBUG: relaying B2B SIP reply 408 Timeout
 [1571598/1571604] [yeti:SBCCallLeg.cpp:1542] DEBUG: Yeti::relayEvent(0x7fd47c039720) filtering body for reply 408 cseq.method 'INVITE' (c/t '') oa_state = 0
 [1571598/1571604] [yeti:SBCCallLeg.cpp:1617] DEBUG: relayEvent(): process asnwer in reply
 [1571598/1571604] [yeti:sdp_filter.cpp:859] DEBUG: processSdpAnswer() method = INVITE, a_leg = 0, answer_is_mandatory = 0
 [1571598/1571604] [yeti:sdp_filter.cpp:863] DEBUG: empty body
 [1571598/1571604] [AmB2BSession.cpp:714] DEBUG: AmB2BSession::relayEvent: to other_id='1-0ACF4A09-6713C8EF0005196B-50858700'
 [1571598/1571604] [yeti:CallLeg.cpp:1092] DEBUG: B leg 1-5933A858-6713C8EF00053CCD-8B482700 changing status from NoReply to Disconnected

 [1571598/1571604] [yeti:SBCCallLeg.cpp:3314] DEBUG: Yeti::onStateChange(0x7fd47c039720|1-5933A858-6713C8EF00053CCD-8B482700) a_leg = 0
 [1571598/1571604] [AmSession.cpp:1421] DEBUG: removing timer 12
 [1571598/1571604] [yeti:CodesTranslator.cpp:350] DEBUG: translate_db_code: 130, override_id: 0
 [1571598/1571604] [yeti:CodesTranslator.cpp:336] DEBUG: translation result: internal = <408:'SIP transaction timeout'>, response = <408:'SIP transaction timeout'>, silently_drop = 0, store_cdr = 1
 [1571598/1571604] [yeti:cdr/Cdr.cpp:421] DEBUG: Cdr[0x7fd47c009200]::update_internal_reason(initiator = 1,reason = 'SIP transaction timeout',code = 408) cdr.disconnect_initiator_writed = 0
 [1571598/1571604] [yeti:cdr/Cdr.cpp:304] DEBUG: Cdr::update_with_action(act = End)
 [1571598/1571604] [yeti:SBCCallLeg.cpp:3442] DEBUG: onCallStatusChange(0x7fd47c039720,legB,state = Disconnected, cause = SipReply. code = 408)
 [1571598/1571604] [yeti:SBCCallLeg.cpp:3261] DEBUG: onStop(0x7fd47c039720,legB)
 [1571598/1571604] [AmB2BMedia.cpp:1344] DEBUG: stop B leg

 [1571598/1571604] [AmB2BMedia.cpp:838] DEBUG: [0x7fd47c04b240] clear B leg audio

 [1571598/1571604] [AmMediaTransport.cpp:834] DEBUG: [0x7fd47c074110] stopReceiving() l_sd:115, seq:0
 [1571598/1571604] [AmMediaTransport.cpp:834] DEBUG: [0x7fd47c075430] stopReceiving() l_sd:116, seq:0
 [1571598/1571604] [AmRtpStream.cpp:195] DEBUG: ~AmRtpStream[0x7fd47c04cac0]() session = 0x7fd47c039720
 [1571598/1571604] [yeti:SBCCallLeg.cpp:3548] DEBUG: onRTPStreamDestroy(0x7fd47c039720,legB) 
[1571598/1571604] [AmMediaTransport.cpp:89] DEBUG: ~AmMediaTransport[0x7fd47c074110] l_sd = 115
 [1571598/1571604] [AmMediaTransport.cpp:89] DEBUG: ~AmMediaTransport[0x7fd47c075430] l_sd = 116
 [1571598/1571604] [AmB2BMedia.cpp:732] DEBUG: changing B leg session to (nil)

 [1571598/1571604] [AmB2BMedia.cpp:357] DEBUG: delayed stream initialization for session (nil)
 [1571598/1571604] [AmB2BMedia.cpp:1082] DEBUG: updating stream in A leg
 [1571598/1571604] [AmB2BMedia.cpp:1086] DEBUG: updating stream in B leg
 [1571598/1571604] [AmB2BMedia.cpp:1090] DEBUG: update relay for stream in A leg
 [1571598/1571604] [AmB2BMedia.cpp:1094] DEBUG: update relay for stream in B leg
 [1571598/1571604] [AmB2BMedia.cpp:1098] DEBUG: [0x7fd47c04b240] audio streams (nil)/(nil) updated

 [1571598/1571604] [AmMediaProcessor.cpp:246] DEBUG: AmMediaProcessor::removeSession 0x7fd47c04b240
 [1571598/1571604] [AmMediaProcessor.cpp:254] DEBUG: attempt to remove session 0x7fd47c04b240 without active media callgroup. ignore
 [1571598/1571604] [AmB2BMedia.cpp:783] DEBUG: session changed

 [1571598/1571604] [AmMediaProcessor.cpp:246] DEBUG: AmMediaProcessor::removeSession 0x7fd47c04b240
 [1571598/1571604] [AmMediaProcessor.cpp:254] DEBUG: attempt to remove session 0x7fd47c04b240 without active media callgroup. ignore
 [1571598/1571604] [AmSipDialog.cpp:639] DEBUG: bye(): we are not connected (status=Disconnected). do nothing!

 [1571598/1571604] [AmSession.cpp:458] DEBUG: ^^ S [1-017EC0DF-6713C8EF00053E26-8B482700|1-5933A858-6713C8EF00053CCD-8B482700] Disconnected, stopped, 0 UACTransPending, 0 usages
^^
 [1571598/1571604] [AmSessionProcessor.cpp:197] DEBUG: finalizing 1 sessions
 [1571598/1571604] [AmSessionProcessor.cpp:201] DEBUG: finalizing session [0x7fd47c039720/1-017EC0DF-6713C8EF00053E26-8B482700/1-5933A858-6713C8EF00053CCD-8B482700]
 [1571598/1571604] [yeti:SBCCallLeg.cpp:1723] DEBUG: finalize(0x7fd47c039720|1-5933A858-6713C8EF00053CCD-8B482700,legB) 
[1571598/1571604] [AmSession.cpp:539] DEBUG: running finalize sequence...
 [1571598/1571604] [yeti:SBCCallLeg.cpp:1686] DEBUG: onBeforeDestroy(0x7fd47c039720|1-5933A858-6713C8EF00053CCD-8B482700,legB)
 [1571598/1571604] [AmSession.cpp:584] DEBUG: AmSession::destroy()
 [1571598/1571604] [AmSession.cpp:555] DEBUG: AmSession::stop()
 [1571598/1571604] [AmSession.cpp:748] DEBUG: Audio cleared !!!
 [1571598/1571604] [AmSession.cpp:547] DEBUG: session is stopped.
 [1571598/1571604] [AmSessionProcessor.cpp:139] DEBUG: running processing loop
 [1571598/1571604] [AmSessionProcessor.cpp:178] DEBUG: processing events for  up to 1 sessions
 [1571598/1571604] [AmSession.cpp:440] DEBUG: vv S [LOpTxc4T_p7vSLD1FKlDHw..|1-0ACF4A09-6713C8EF0005196B-50858700] Trying, running, 0 UACTransPending, 0 usages vv
 [1571598/1571604] [yeti:SBCCallLeg.cpp:2327] DEBUG: process(0x7fd3e0029550|1-0ACF4A09-6713C8EF0005196B-50858700,legA)
 [1571598/1571604] [yeti:CallLeg.cpp:424] DEBUG: 1-0ACF4A09-6713C8EF0005196B-50858700: B2B SIP reply 408/1 INVITE received in NoReply state

 [1571598/1571604] [yeti:CallLeg.cpp:440] DEBUG: established CSeq: 1, forward: yes

 [1571598/1571604] [yeti:CallLeg.cpp:392] DEBUG: clean-up after non-ok reply (reply: 408, status NoReply, other: )
 [1571598/1571604] [AmB2BMedia.cpp:717] DEBUG: last reference to AmB2BMedia [0x7fd47c04b240] cleared, destroying
 [1571598/1571604] [AmB2BMedia.cpp:677] DEBUG: ~AmB2BMedia[0x7fd47c04b240]()
 [1571598/1571604] [yeti:CallLeg.cpp:1092] DEBUG: A leg 1-0ACF4A09-6713C8EF0005196B-50858700 changing status from NoReply to NoReply 
 [1571598/1571604] [yeti:SBCCallLeg.cpp:3314] DEBUG: Yeti::onStateChange(0x7fd3e0029550|1-0ACF4A09-6713C8EF0005196B-50858700) a_leg = 1
 [1571598/1571604] [yeti:SBCCallLeg.cpp:3442] DEBUG: onCallStatusChange(0x7fd3e0029550,legA,state = NoReply, cause = SipReply. code = 408)
 [1571598/1571604] [yeti:SBCCallLeg.cpp:3449] DEBUG: onBLegRefused(0x7fd3e0029550,legA)
 [1571598/1571604] [AmSession.cpp:1421] DEBUG: removing timer 13
 [1571598/1571604] [yeti:cdr/Cdr.cpp:236] DEBUG: Cdr::update_with_sip_reply(AmSipReply)
 [1571598/1571604] [yeti:cdr/Cdr.cpp:395] DEBUG: Cdr::update_bleg_reason(reason = 'Timeout',code = 408)
 [1571598/1571604] [yeti:CodesTranslator.cpp:268] DEBUG: translated 408:'Timeout' -> 408:'Request Timeout'
 [1571598/1571604] [yeti:CodesTranslator.cpp:268] DEBUG: translated 408:'Request Timeout' -> 408:'Request Timeout'
 [1571598/1571604] [yeti:cdr/Cdr.cpp:421] DEBUG: Cdr[0x7fd47c009200]::update_internal_reason(initiator = 1,reason = 'Request Timeout',code = 408) cdr.disconnect_initiator_writed
= 1
 [1571598/1571604] [yeti:cdr/Cdr.cpp:304] DEBUG: Cdr::update_with_action(act = End)
 [1571598/1571604] [yeti:cdr/Cdr.cpp:409] DEBUG: Cdr::update_aleg_reason(reason = 'Request Timeout',code = 408)
 [1571598/1571604] [yeti:CodesTranslator.cpp:309] DEBUG: stop_hunting = 1 for code '408'
 [1571598/1571604] [yeti:SBCCallLeg.cpp:3488] DEBUG: stop hunting
 [1571598/1571604] [AmB2BSession.cpp:1005] DEBUG: relaying SIP reply 408 Request Timeout
 [1571598/1571604] [AmOfferAnswer.cpp:437] DEBUG: after 408 reply to INVITE: resetting OA state
 [1571598/1571604] [AmOfferAnswer.cpp:70] DEBUG: setting SIP dialog O/A status: OfferRecved->None
 [1571598/1571604] [AmBasicSipDialog.cpp:125] DEBUG: setting SIP dialog status: Trying->Disconnected
 [1571598/1571604] [sip/trans_layer.cpp:456] DEBUG: reply_len = 336
 [1571598/1571604] [sip/trans_layer.cpp:628] DEBUG: Sending to XXX.XX.70.75:58716 <SIP/2.0 408 Request Timeout
Via: SIP/2.0/UDP 10.8...>
 [1571598/1571604] [sip/udp_trsp.cpp:284] DEBUG: send msg via UDP from xxx.xxx.xxx.xxx:5060 to XXX.XX.70.75:58716 
--++--
SIP/2.0 408 Request Timeout
Via: SIP/2.0/UDP 10.8.0.2:58716;branch=z9hG4bK-524287-1---b89c6199a7344b2a;rport=58716;received=XXX.XX.70.75
To: <sip:34612333333@xxx.xxx.xxx.xxx>
From: <sip:341234567@xxx.xxx.xxx.xxx;transport=UDP>;tag=53e83d32
Call-ID: LOpTxc4T_p7vSLD1FKlDHw..
CSeq: 1 INVITE
Server: Yeti
Content-Length: 0

--++--

dmitry.s · October 19, 2024, 3:16pm

share your disconnect codes configuration what you have during this call

roco · October 19, 2024, 3:17pm

this one?

dmitry.s · October 19, 2024, 3:23pm

will it reroute call if you will set stop hunting = no in code #64 ?

roco · October 19, 2024, 3:24pm

exactly!

dmitry.s · October 19, 2024, 3:25pm

And if rewrite code and reason configured in code #64 will it rewrite?

roco · October 19, 2024, 3:27pm

yes, and what’s strange is that if i set stop hunting = no on both, it can use also the rewrite of the #130

dmitry.s · October 19, 2024, 3:30pm

Why you think you receiving code #130? I think you have disconnect initiator = destination in CDR.

dmitry.s · October 19, 2024, 3:35pm

because rfc telling us:

8.1.3.1 Transaction Layer Errors

   In some cases, the response returned by the transaction layer will
   not be a SIP message, but rather a transaction layer error.  When a
   timeout error is received from the transaction layer, it MUST be
   treated as if a 408 (Request Timeout) status code has been received....

So locally generated 408 should be treated in same way as 408 received from remote gw.

roco · October 19, 2024, 3:38pm

my mistake, that is not true, rewrite on #130 will not work., only on #64, I’ve just checked.

disconnect initiator is leg b because of timeout of the called termination gateway not online.

What I would need to do is to separate these 2 events:

408 “Request timeout” is a termination that tried to contact customer and it doesn’t reply, in this case I don’t want to have rerouting.

408 “timeout” or “sip transaction timeout” is a termination not online and I want to reroute on another thermination.

dmitry.s:

because rfc telling us:

8.1.3.1 Transaction Layer Errors

   In some cases, the response returned by the transaction layer will
   not be a SIP message, but rather a transaction layer error.  When a
   timeout error is received from the transaction layer, it MUST be
   treated as if a 408 (Request Timeout) status code has been received....

So locally generated 408 should be treated in same way as 408 received from remote gw.

this is ok but sems is able to detect if gateway is online or not, so I would like to be able to detect it for the rerouting part.

Right now it seems that rule #130 is not working if I set stop hunting on #64, I would like to work with both.