3 Feb
2011
3 Feb
'11
3:38 p.m.
Hello,
On 2/3/11 7:07 PM, Thomas Baumann wrote:
Hi Daniel,
thanks for the hints, with debug_level they are some hints what happened.
Normal Operation:
5(20410) DEBUG: dispatcher [dispatch.c:2305]: probing set #1, URI sip:10.12.19.31:5060
5(20410) DEBUG: dispatcher [dispatch.c:2305]: probing set #1, URI sip:10.12.19.21:5060
4(20409) DEBUG: dispatcher [dispatch.c:2250]: OPTIONS-Request was finished with code 200
(to sip:10.12.19.21:5060, group 1)
3(20407) DEBUG: dispatcher [dispatch.c:2250]: OPTIONS-Request was finished with code
200 (to sip:10.12.19.31:5060, group 1)
Service is stopped at 10.12.19.21, the next INVITE with timeout will trigger
ds_mark_dst("i");
This event will enable the Gateway again:
5(20410) DEBUG: dispatcher [dispatch.c:2250]: OPTIONS-Request was finished with code 408
(to sip:10.12.19.21:5060, group 1)
But the funny part is that this 408 does not belong to a OPTION-Request. It was an reply
to an INVITE.
it is very unlikely that a reply for an INVITE will match a keepalive
OPTIONS request. Can you grap SIP trace for such case, along with debug
messages?
I disabled the parameter
modparam("dispatcher", "ds_ping_reply_codes",
"class=2;class=4") in the config, now the gateway remains inactive until a 200
ok is received for an option.
I don't understand why this 408 matched. Why I need to trigger always
ds_mark_dst("i"); , OPTIONS are send out anyway. Disabling the gateway could be
done in the background, or maybe I missed something in the documentation.
You have to trigger ds_marck_dst("i") if you want that the gw becomes
inactive immediately, otherwise will be set inactive at next keepalive
round.
Cheers,
Daniel
regards,
Thomas
___________________________________________________________
Empfehlen Sie WEB.DE DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.web.de
--
Daniel-Constantin Mierla
http://www.asipto.com