[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