[reSIProcate] DnsResult blacklistLast,greylistLast question.
Byron Campen
docfaraday at gmail.com
Tue Dec 24 22:06:13 CST 2013
I can see making this configurable, but how is the proxy ending up
with a URI for UA2 that did not either have a transport=udp param, or
NAPTR set up to only support UDP?
Best regards,
Byron Campen
On 12/24/13 8:06 AM, Sergey Pavlov wrote:
> Hi, resiprocate devels.
> I just want to return to the topic described in the quoted email below
> i.e. to the question of separate
> transport/target blacklisting. I am colleague of the mail author and I
> want a clarify a situation
> a little bit. The initial schema of SIP communication was following:
>
> UA1 -> Proxy(resiprocate stack) ->UA2
>
> where
> 1) The Proxy was configured with UDP and TCP transports.
> 2) UA1 and UA2 used only UDP transport and didn't have TCP support
> enabled.
> 3) UA1 sent INVITE with broken To header field
> 4) UA2 detected malformed To header filed and answered with 500
> response without(!) To field
> 5) The resiprocate detected malformed response and ignored that and
> UA2 was greylisted on some time.
> 6) As result all requests targeted to UA2 were sent over TCP during
> greylist period. However, taking into account
> taht UA2 doesn't support TCP we just had a broken signalling during
> this period of time.
>
> Such behaviour is more or less acceptable in case when UA2 is just
> end-user UA. But in our case it can
> be some vendor gateway or our own B2BUA so we simply face out-of-order
> condition for large amount of calls.
>
> To put it simply, we have a situation when an unanswered SIP
> transaction leads to out-of-order service
> condition during significant period of time. So the provided patch is
> aimed to introduce some control
> for grey-listing mechanism. Frankly speaking, complete disabling of
> grey-list functionality also will help
> in our case. The question is - is there possibilty to make it without
> respirocate patching?
>
> --
> Best regards,
> Sergey Pavlov
>
> > 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?
>
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel at resiprocate.org
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20131224/1b08bb1c/attachment.htm>
More information about the resiprocate-devel
mailing list