gmlc
gmlc copied to clipboard
RestComm
onDialogTimeout is unconditionally sending http response
https://github.com/RestComm/gmlc/blob/master/core/slee/services/sbbs/src/main/java/org/mobicents/gmlc/slee/MobileCoreNetworkInterfaceSbb.java#L228
this logic should check if an http response was already sent!!!
potentially reuse http://docs.oracle.com/javaee/6/api/javax/servlet/ServletResponse.html#isCommitted() so no new flag is required
@jaimecasero
this logic should check if an http response was already sent!!!
I am trying to understand why "http response was already sent". DialogTimeout means that we have not received a resposne from SS7 network and therefore not generated any HTTP response. May it be that this response may be already generated by HTTP RA because of it's timeout for example ?
well we were chcecking tracing from SBB that showed DialogTimeout was creating the "additional" response. Anyway, it may be worth investigating the SS7 beahvior, so we may need to add traces to thsi ticket...
I have seen this happen before if jss7 is not configured. The 503 it throws does infact conflict with the resulting dialogtimeout, but I wouldn't call this a bug.
JSS7 DialogTimout event comes in some delays like a minute. We may have DialogTimout events in case of SS7 stack is not properly configured (and therefore no response form a ss7 peer). So may it be HTTP request is already timed out at the time of JSS7 DialogTimout event is coming ?
@FerUy I've been reassigned to other projects at work so I won't have time to help out, sorry! Was just passing through and saw something I could comment on. :)
@FerUy No problem, of course :) It's been a while since I looked at the code, but when I was investigating this the conflicting 503's were thrown from pretty deep in the jss7 stack. I suspect the bug is better placed in that repo, where it should be firing an appropriate dialog response back up to the GMLC instead of directly outputting its own 503 http response.