I have a situation where SER sits between two independent networks, one being an isolated network and the other being the rest of the Internet. The isolated network is also a PSTN gateway with only one switch on that network. SER has two physical interfaces, and uses force_send_socket and rewritehost to make sure things go out the right interfaces.
The problem is when the called network hangs up first and generates a BYE* first, if SER didn't add a record-route, the called network switch bypasses SER and attempts to send directly to the calling IP address, which doesn't work because the two networks cannot be reached directly.
If I add just one record-route in SER, the called network now knows how to get back to SER to tell it about the BYE, and SER passes that BYE on to the calling network. So far so good.
Unfortunately, this also causes the called network to add Record-Route to responses it sends out, like 183/200 with its own IP address. Those reach the SER without problem, but SER doesn't add its own Record-Route to the reply, so when this reaches the calling network, they only have a Record-route that points to an IP address they cannot possibly reach.
I tried a number of things to get around this, and all failed. 1. Tried to add my own Record-Route to the reply, but SER doesn't allow this. Won't even start.
2. Tried to remove the Record-Route from the reply, but SER also doesn't allow this. Won't even start.
3. Tried to add both IP addresses for the two interfaces to by using two Record-Routes at the INVITE. This doesn't fix the response messages, and actually causes looping behavior or "I'm terribly sorry" responses. (I tried this with and without the "enable_double_rr" parameter set and it didn't seem to make any difference.) By altering the order of the two Record-Route you are pretty-much guaranteed to confuse one party or the other as each needs the Record-Routes listed in the opposite order.
4. Tried some combinations of the above with loose_route() but the usual outcome is SER sending messages back to itself rather than to the right place and eventually the dreaded "I'm terribly sorry" or "481 Transaction" gets sent out, usually to nobody in particular.
So, are there any working examples out there for a SER that has two network interfaces, each in its own isolated network that correctly route messages between the two sides? I need SER to not only add Record-Routes when appropriate but to strip them off or replace them as the replies pass back through and back to the initiator.
The network isolation was a security thing, not a NAT thing (although private IP space is in use), but it is not possible for a message from one network to reach the other without passing through SER, and some commercial equipment I am working with ignores the source of a message and only sends the response to wherever the record-route(s) say it should go and if no record-route, it honors the Via, while other gear ignored both and only replies to the source of the message.
*The problems affecting called-party BYEs also causes major grief when re-INVITEs occur, which fail to make it to the calling network (or more likely, the 200 OK replies fail to make it back), causing the call to die after 32 seconds.
Any examples would be greatly appreciated.
Hi Frank, I seem to remember there was an example in source code example dir, but that's some time ago, so I don't know if its still there. Double record routing is the way to go and you need to make sure that SER recognizes both interfaces as itself (alias). To me it looks like that's where the problem is, but hard to say. I know people have this working. g-)
Frank Durda IV wrote:
I have a situation where SER sits between two independent networks, one being an isolated network and the other being the rest of the Internet. The isolated network is also a PSTN gateway with only one switch on that network. SER has two physical interfaces, and uses force_send_socket and rewritehost to make sure things go out the right interfaces.
The problem is when the called network hangs up first and generates a BYE* first, if SER didn't add a record-route, the called network switch bypasses SER and attempts to send directly to the calling IP address, which doesn't work because the two networks cannot be reached directly.
If I add just one record-route in SER, the called network now knows how to get back to SER to tell it about the BYE, and SER passes that BYE on to the calling network. So far so good.
Unfortunately, this also causes the called network to add Record-Route to responses it sends out, like 183/200 with its own IP address. Those reach the SER without problem, but SER doesn't add its own Record-Route to the reply, so when this reaches the calling network, they only have a Record-route that points to an IP address they cannot possibly reach.
I tried a number of things to get around this, and all failed.
- Tried to add my own Record-Route to the reply, but
SER doesn't allow this. Won't even start.
- Tried to remove the Record-Route from the reply, but
SER also doesn't allow this. Won't even start.
- Tried to add both IP addresses for the two interfaces
to by using two Record-Routes at the INVITE. This doesn't fix the response messages, and actually causes looping behavior or "I'm terribly sorry" responses. (I tried this with and without the "enable_double_rr" parameter set and it didn't seem to make any difference.) By altering the order of the two Record-Route you are pretty-much guaranteed to confuse one party or the other as each needs the Record-Routes listed in the opposite order.
- Tried some combinations of the above with loose_route()
but the usual outcome is SER sending messages back to itself rather than to the right place and eventually the dreaded "I'm terribly sorry" or "481 Transaction" gets sent out, usually to nobody in particular.
So, are there any working examples out there for a SER that has two network interfaces, each in its own isolated network that correctly route messages between the two sides? I need SER to not only add Record-Routes when appropriate but to strip them off or replace them as the replies pass back through and back to the initiator.
The network isolation was a security thing, not a NAT thing (although private IP space is in use), but it is not possible for a message from one network to reach the other without passing through SER, and some commercial equipment I am working with ignores the source of a message and only sends the response to wherever the record-route(s) say it should go and if no record-route, it honors the Via, while other gear ignored both and only replies to the source of the message.
*The problems affecting called-party BYEs also causes major grief when re-INVITEs occur, which fail to make it to the calling network (or more likely, the 200 OK replies fail to make it back), causing the call to die after 32 seconds.
Any examples would be greatly appreciated.
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Hi Frank,
as Greger pointed already out the solution for your problem should be double record routing of the INVITE. It might depend on your SER version your config script etc., but theoretically SER should do this double record routing automatically if you use two interfaces with different IP addresses.
Now from reading your mail it sounds like the UAS in your setup does not copy the record route headers into the reply, but instead places its own record route header into the replies. If that is the case: blame the vendor of the UAS! It is totally broken and they should fix it asap.
Theoretically you try to "fix" this issue on the replies. But it is not easy to do that because you need to identify the correct interfaces used for the request from looking at the reply. I think it should be doable with new code in SER, but probably not with the given function set.
Greetings Nils
Am 08.09.09 22:42, schrieb Frank Durda IV:
I have a situation where SER sits between two independent networks, one being an isolated network and the other being the rest of the Internet. The isolated network is also a PSTN gateway with only one switch on that network. SER has two physical interfaces, and uses force_send_socket and rewritehost to make sure things go out the right interfaces.
The problem is when the called network hangs up first and generates a BYE* first, if SER didn't add a record-route, the called network switch bypasses SER and attempts to send directly to the calling IP address, which doesn't work because the two networks cannot be reached directly.
If I add just one record-route in SER, the called network now knows how to get back to SER to tell it about the BYE, and SER passes that BYE on to the calling network. So far so good.
Unfortunately, this also causes the called network to add Record-Route to responses it sends out, like 183/200 with its own IP address. Those reach the SER without problem, but SER doesn't add its own Record-Route to the reply, so when this reaches the calling network, they only have a Record-route that points to an IP address they cannot possibly reach.
I tried a number of things to get around this, and all failed.
- Tried to add my own Record-Route to the reply, but
SER doesn't allow this. Won't even start.
- Tried to remove the Record-Route from the reply, but
SER also doesn't allow this. Won't even start.
- Tried to add both IP addresses for the two interfaces
to by using two Record-Routes at the INVITE. This doesn't fix the response messages, and actually causes looping behavior or "I'm terribly sorry" responses. (I tried this with and without the "enable_double_rr" parameter set and it didn't seem to make any difference.) By altering the order of the two Record-Route you are pretty-much guaranteed to confuse one party or the other as each needs the Record-Routes listed in the opposite order.
- Tried some combinations of the above with loose_route()
but the usual outcome is SER sending messages back to itself rather than to the right place and eventually the dreaded "I'm terribly sorry" or "481 Transaction" gets sent out, usually to nobody in particular.
So, are there any working examples out there for a SER that has two network interfaces, each in its own isolated network that correctly route messages between the two sides? I need SER to not only add Record-Routes when appropriate but to strip them off or replace them as the replies pass back through and back to the initiator.
The network isolation was a security thing, not a NAT thing (although private IP space is in use), but it is not possible for a message from one network to reach the other without passing through SER, and some commercial equipment I am working with ignores the source of a message and only sends the response to wherever the record-route(s) say it should go and if no record-route, it honors the Via, while other gear ignored both and only replies to the source of the message.
*The problems affecting called-party BYEs also causes major grief when re-INVITEs occur, which fail to make it to the calling network (or more likely, the 200 OK replies fail to make it back), causing the call to die after 32 seconds.
Any examples would be greatly appreciated.
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers