I have noted that the pstn.cfg example (or anything built from its premise) doesn't work right for one very important situation, that hopefully someone has already discovered and has a good fix for. The documentation isn't helping.
The situation: I have a call initiated by some SIP client, with the INVITE passing through SER and sent on to a PSTN gateway (the SIP to SS7/ISUP conversion occurs there). The call is in progress (post 200 OK) and both parties are chatting away. So far, so good.
The problem: Trouble begins when the called-party (somewhere on the PSTN) hangs up first.
What happens: This event triggers a SS7 REL message, and the SIP/SS7 switch providing the VOIP gateway service emits a BYE message, which gets sent to SER. SER receives the message and doesn't treat it as a reply (because it isn't), but instead it comes in the door at route {}.
The pstn.cfg-like script quickly determines that this BYE message is coming from the gateway (correct) and skips all the authentication checks (good), and does a rewritehostport() using the PSTN gateway IP address (bad), and finally does a t_relay() (very bad).
The BYE is now emitted by SER and sent back to the PSTN gateway switch, rather than on to wherever the INVITE originally came from, the device that needs to know about this BYE.
This quickly degenerates into a small battle between PSTN gateway switch and SER, as the PSTN gateway isn't getting the answer back it is expecting in response to the BYE it sent to SER, and the PSTN gateway certainly doesn't want to see the message it just sent out come back over and over. Eventually various looping checks or timers kick in and the argument ends, but the calling system remains in the dark over the fact that the call is now over (other than getting a lot of silence).
So that behavior is obviously wrong, but that's what the stock copy of pstn.cfg does here. SER obviously wants to be involved, because it added a Record-Route, but the script really isn't able to deal with the consequences.
If the calling network was all SIP this would be merely annoying, but if it is another ISUP network (with a SIP leg in the middle), the originating ISUP legs of the call just rack up the toll charges, unaware that the other legs of the call are gone.
Bad things also happen if the original INVITE included a Session-Expires: header, which causes the PSTN gateway to emit its own INVITE back to the calling network (via the SER) at intervals during the call, starting at 50% of the time specified in that header. These packets also die a horrible fate in the PSTN-Gateway and SER packet loop, which causes the call to collapse 32 seconds later. (That's unbelieveably bad.)
Recognizing this apparent-shortcoming in the pstn.cfg example, and using the fact that the script could determine that this called-party-BYE or INVITE message came from the PSTN gateway and not somewhere else, I added tests to not perform the rewritehost that sends the message back to the gateway, but instead sets the address to that of the known place where the INVITE originally came from, because in this super simple example, there is only one place, eg phone-asterisk-SER-PSTN-SS7network-... Forcing BYE/INVITEs coming from the PSTN direction sort of fixes the problem of called-party BYEs, and the PSTN gateway device emitting re-INVITEs. However, it only works for ONE source, which is lousy as you have to hard-code the right place for the call in both directions!
And of course, someone has too many calls for their one SBC (aka an asterisk box) and they have more than one now. In fact, many more, and any of them can send me the same range of calls from the same sources and to the same PSTN gateway. And it would be really nice if I sent the called-party-BYE or re-INVITEs back to the right SBC. But how?
An examination of the numerous variables that SER has (as viewed via xlog() when the called-party-BYE or called-network-reINVITE comes in) shows that SER actually has the right IP address available that the called-party-BYE or re-INVITE should be sent back to (apparently saved as part of the transaction details from the original INVITE), but I can't figure out how to reference this value in "rewritehost()". Like most SER functions, rewritehost() doesn't appear to accept variable names as parameters, and as xlog uses cryptic abbreviations for what it displays, I probably wouldn't know what variable name to specify in rewritehost() anyway. (Did two different programmers do these parts?)
Now, if you don't use "rewritehost()" in the send-back-to-caller direction and are hoping that SER will do the right thing on its own, you will be disappointed. The t_relay() merely sends the message back itself and you get a much smaller SIP message loop going. (This is because SER puts its IP address all over the original INVITE message so that the PSTN gateway would talk to SER rather than the true source of the call.)
So that appears to means that you must set rewritehost() to a reasonable destination to get the message to move beyond SER, and somehow I have to choose a destination from many possible destinations the original INVITE came from, based on some piece of trivia that was in the original INVITE that I can somehow trigger on.
That means if there are 250 different SBCs out there sending me calls, and one of them was where the original INVITE came from for the call I just got a called-party-BYE from, how do I force that called-party-BYE (or a called-network re-INVITE) to go back to the right place? Must I build a giant if statement that tests the addresses of all 250 sources and leaves a flag or something that can be used in 250 if statements later when the called-party-BYE or called-network-reINVITE shows up? Sounds horrible and a giant kludge! Any other solutions?
Thanks in advance for thinking about this one!
Frank, I think you are looking for the answer in the wrong place. A BYE should never have to reach the rewritehostport section as the message should already contain what is required to forward the message correctly. Normally, the ruri is username@ipaddressoflocation:port,i.e. the location, and a Route is found in the message. Then the message will be loose routed (but normally the ruri indicates the next hop and only one Route is present, which points to your SER).
So, from what you are saying, I would guess that the gateway sends you a ruri with the IP of your server after @. You need to detect that and do an actual contact lookup also for these buys (i.e. treat the BYE as an INVITE). g-)
Frank Durda IV wrote:
I have noted that the pstn.cfg example (or anything built from its premise) doesn't work right for one very important situation, that hopefully someone has already discovered and has a good fix for. The documentation isn't helping.
The situation: I have a call initiated by some SIP client, with the INVITE passing through SER and sent on to a PSTN gateway (the SIP to SS7/ISUP conversion occurs there). The call is in progress (post 200 OK) and both parties are chatting away. So far, so good.
The problem: Trouble begins when the called-party (somewhere on the PSTN) hangs up first.
What happens: This event triggers a SS7 REL message, and the SIP/SS7 switch providing the VOIP gateway service emits a BYE message, which gets sent to SER. SER receives the message and doesn't treat it as a reply (because it isn't), but instead it comes in the door at route {}.
The pstn.cfg-like script quickly determines that this BYE message is coming from the gateway (correct) and skips all the authentication checks (good), and does a rewritehostport() using the PSTN gateway IP address (bad), and finally does a t_relay() (very bad).
The BYE is now emitted by SER and sent back to the PSTN gateway switch, rather than on to wherever the INVITE originally came from, the device that needs to know about this BYE.
This quickly degenerates into a small battle between PSTN gateway switch and SER, as the PSTN gateway isn't getting the answer back it is expecting in response to the BYE it sent to SER, and the PSTN gateway certainly doesn't want to see the message it just sent out come back over and over. Eventually various looping checks or timers kick in and the argument ends, but the calling system remains in the dark over the fact that the call is now over (other than getting a lot of silence).
So that behavior is obviously wrong, but that's what the stock copy of pstn.cfg does here. SER obviously wants to be involved, because it added a Record-Route, but the script really isn't able to deal with the consequences.
If the calling network was all SIP this would be merely annoying, but if it is another ISUP network (with a SIP leg in the middle), the originating ISUP legs of the call just rack up the toll charges, unaware that the other legs of the call are gone.
Bad things also happen if the original INVITE included a Session-Expires: header, which causes the PSTN gateway to emit its own INVITE back to the calling network (via the SER) at intervals during the call, starting at 50% of the time specified in that header. These packets also die a horrible fate in the PSTN-Gateway and SER packet loop, which causes the call to collapse 32 seconds later. (That's unbelieveably bad.)
Recognizing this apparent-shortcoming in the pstn.cfg example, and using the fact that the script could determine that this called-party-BYE or INVITE message came from the PSTN gateway and not somewhere else, I added tests to not perform the rewritehost that sends the message back to the gateway, but instead sets the address to that of the known place where the INVITE originally came from, because in this super simple example, there is only one place, eg phone-asterisk-SER-PSTN-SS7network-... Forcing BYE/INVITEs coming from the PSTN direction sort of fixes the problem of called-party BYEs, and the PSTN gateway device emitting re-INVITEs. However, it only works for ONE source, which is lousy as you have to hard-code the right place for the call in both directions!
And of course, someone has too many calls for their one SBC (aka an asterisk box) and they have more than one now. In fact, many more, and any of them can send me the same range of calls from the same sources and to the same PSTN gateway. And it would be really nice if I sent the called-party-BYE or re-INVITEs back to the right SBC. But how?
An examination of the numerous variables that SER has (as viewed via xlog() when the called-party-BYE or called-network-reINVITE comes in) shows that SER actually has the right IP address available that the called-party-BYE or re-INVITE should be sent back to (apparently saved as part of the transaction details from the original INVITE), but I can't figure out how to reference this value in "rewritehost()". Like most SER functions, rewritehost() doesn't appear to accept variable names as parameters, and as xlog uses cryptic abbreviations for what it displays, I probably wouldn't know what variable name to specify in rewritehost() anyway. (Did two different programmers do these parts?)
Now, if you don't use "rewritehost()" in the send-back-to-caller direction and are hoping that SER will do the right thing on its own, you will be disappointed. The t_relay() merely sends the message back itself and you get a much smaller SIP message loop going. (This is because SER puts its IP address all over the original INVITE message so that the PSTN gateway would talk to SER rather than the true source of the call.)
So that appears to means that you must set rewritehost() to a reasonable destination to get the message to move beyond SER, and somehow I have to choose a destination from many possible destinations the original INVITE came from, based on some piece of trivia that was in the original INVITE that I can somehow trigger on.
That means if there are 250 different SBCs out there sending me calls, and one of them was where the original INVITE came from for the call I just got a called-party-BYE from, how do I force that called-party-BYE (or a called-network re-INVITE) to go back to the right place? Must I build a giant if statement that tests the addresses of all 250 sources and leaves a flag or something that can be used in 250 if statements later when the called-party-BYE or called-network-reINVITE shows up? Sounds horrible and a giant kludge! Any other solutions?
Thanks in advance for thinking about this one!
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-
Frank Durda IV -
Greger Viken Teigre