[Serusers] Need a way to substitute SIP Response Code 504 for something else

[Greger Viken Teigre]

And if you are on the latest code, you may want to have a look at this 
thread:
http://lists.sip-router.org/pipermail/sr-dev/2010-February/006145.html

On 03.03.2010 08:37, Greger Viken Teigre wrote:
> Hi Frank,
> I think you are the person I know trying to twist SER in the most edgy 
> ways ;-) In many cases, you have tried to brute-force SER to do stuff 
> that you really shouldn't do as you get plenty of side-effects when 
> doing tricks with the SIP dialog. I think I have suggested before that 
> investing time in setting up a B2BUA function, for example sems or 
> b2bu2.org, would probably simplify your ser installation a lot and 
> longer-term reduce your worries.
> I'm not sure which version of SER you are using, but I assume that 
> upgrading is by now just a looming nightmare for you.  If you have 
> already tried replacing an error code without success, unless you are 
> on the latest code, I don't think there is anything new that can help 
> you.
>
> Also note that there are others doing similar tricks, but they don't 
> do everything in ser.cfg. Very often, you will have to do custom 
> development and you need a bigger tool chest.
> g-)
>
> On 12.02.2010 18:59, Frank Durda IV wrote:
>> There is a commercial switch vendor who has recently
>> decided to make two changes that combined are quite evil:
>>
>> 1, They decided to devivate from RFC 3398 and when a
>> given call INVITE timer expire (any of the SS7 ones,
>> plus the SIP ones, including any limit specified
>> in the INVITE itself), instead of translating the
>> ISUP Release Cause 102 into a SIP Response Code of 504
>> (Gateway Timeout), they send out a 503 (Service
>> Unavailable) instead.
>>
>> (503 is commonly used in low-cost carriers and the
>> commercial equipment they use to trigger a
>> route-advance, where the call doesn't end but is
>> relaunched via another slightly more expensive
>> route/carrier who perhaps can get the call to the
>> destination.  Some of these low-cost outfits may
>> retry the same call with five or six carriers
>> before reluctantly sending to the local access tandem
>> which is usually the most expensive choice, but
>> almost certain to work.   This probably isn't what
>> the inventors of the 503 code had in mind, but that
>> is how it is used.  A minority use 404 the same way.)
>>
>>
>> 2.  The same vendor implemented an automatic "Address Reach"
>> testing mechanism for outbound calls.  This thing means that
>> when sending a call to a distant switch, if a single
>> or small number of calls are returned from that
>> distant switch with a SIP Response Code of 504 from
>> the destination, the sending switch will take that
>> destination switch completely out of route ("blacklist")
>> and not send any calls at all to that destination
>> until the blacklist is manually reset.   So a result that
>> applies to one call is fatal to all subsequent calls.
>>
>> This also means that if you sent the INVITE Expires
>> timer to a value less than the number of seconds the
>> calling party is willing to let the called number
>> ring (called party doesn't have voice mail or it
>> doesn't pick up for several rings), you trigger a
>> 504 and bingo, you have killed the route between those
>> two switches.  So your own choices for how long to
>> wait on ring-back for a call dictate how quickly it
>> could kill the entire route for that call.
>>
>>
>> Now, the two changes taken together are also somewhat
>> convienent because this equipment maker just happened
>> to make it impossible for their own equipment to ever
>> return a 504 and do can never trip off their own booby-trap.
>>
>> So in a way what these two changes effectively create a
>> not-our-hardware-detector, triggering route failures
>> only when in contact with RFC-compliant equipment made
>> by somebody else.  I think that behavior is anti-competitive,
>> and probably illegal in quite a few countries (notably
>> the EU), but that is what exists at the moment.  This
>> creation started getting deployed in the past few months.
>>
>>
>> So, to get around this nonsense, I need a way in SER
>> to detect that a 504 has come in and change it to
>> something else before sending it on.  I won't quibble
>> about the "proxies can't forward a 503", so I won't try
>> that.  I would like to turn the 504 into a 404,
>> which is better than having route get pulled all over
>> the place.
>>
>>
>> Now, the last time (a year or so ago) I asked about
>> trying to change a SIP Response Code in SER, the
>> suggested ser.cfg "fix" created all sorts of strange
>> warnings in the logs about timers expiring and I was
>> told to not worry about that.  Well, it seemed to cause
>> a lot more problems than just warnings like memory
>> leaks or cores caused by something, so I ended up having
>> to hard-code the translation I wanted into the SER
>> source code and not use rules in ser.cfg to do this.
>>
>> I'm writing now to (A) alert people about what this
>> major brand switch maker is doing with regard to 504s
>> so you will recognize it if you encounter it, but
>> also (B) to see if maybe has a more elegant way to
>> change SIP Responses via the ser.cfg file has emerged.
>>
>> The obvious things like subst subst_uri don't appear to
>> work, obviously busily editing the non-existent INVITE
>> method message and ignoring the reply message.
>>
>> Using a reply/drop combination to generate a new reply
>> and kill the real one doesn't seem to work either.
>> As I recall it ends up sending the response specified
>> in the reply, and then passing the original response as
>> well.   "drop" apparently doesn't kill it completely
>> and I suspect reply is really meant to be used only during
>> handling of the method messages, and not the response
>> messages.
>>
>>
>> Suggestions appreciated.
>>
>> _______________________________________________
>> Serusers mailing list
>> Serusers at lists.iptel.org
>> http://lists.iptel.org/mailman/listinfo/serusers
>
> _______________________________________________
> Serusers mailing list
> Serusers at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers