|
Wait, repro is blacklisting (and
restransmitting!) on a 500? That doesn't make sense. I suspect
that the 500 is also malformed, enough that repro is unable to
match it to the transaction, causing a timeout (which then causes
the blacklist). And, I'm pretty sure we're greylisting on timeout
right? Could I get a trace?
Best regards,
Byron Campen
Dear
resiprocate devels,
resiprocate version 1.8.8
I use proxy,built above resip stack. In particular, there are a
fiew intermediate proxy servers: N1,N2,N3.
I've met next issue:
1) there is an active session.
2) some client starts one more session,sending malformed sip
message to proxy1, proxy1 retransmits that message to Proxy2 and
proxy2 responds with 500 Server internal error. Proxy1 tries to
retransmit that message several times and after the last one it
penalizes given transport by black listing.
3) At the same time session from item1 has not been finished yet.
If any participant from session1 will send any sip message -
TransportSelector will generate TransportFailure or TCP transport
will be selected if it is configured - as result session1 becomes
broken/hung.
I think UAC penalization - is good idea,but proxy penalization
leads to undefined behaviour.
Considering this I would like to ask a few questions,if you don't
mind:
1) Is it possible to add some exception list to
DnsResult::blackListLast/DnsResult::greyListLast stuff?
2) Could you please take a look on provided patch,which provides
some kind of solution?
Appreciate in advance.
_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxx
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
|