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.
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.)
- 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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
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.)
- 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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-
Frank Durda IV -
Greger Viken Teigre