Greger Viken Teigre wrote:
Good to hear that it now works. I don't agree in your analysis. IMHO, using fix_nated_contact("fixed_IP") is what got you in this mess in the first place. Leaving that out, SER should be fine using two interfaces.
The problem is that without fix_nated_contact, the Contact address seen by at least one party is an address they can't reach, if the two interfaces are connected to networks that are really isolated.
The issues are all with the SIP calling to TDM direction, the PSTN switch doesn't really care about the Contact being wrong as it uses Record-Route (if present) or Via to figure out where 180/183/200 replies should go. It all falls apart though when the PSTN switch initiates a BYE or a re-INVITE.
Meanwhile, some calling SIP devices (not asterisk but other high-end SBCs) are want to use the Contact value, and SER sticks an IP address in there of the second network, the one the calling network cannot possibly reach.
So while people may make it work without fix_nated_contact, I bet both interfaces/IP addresses are reachable from the calling and called parties and are not isolated, so it doesn't matter if the Contact address isn't the one on the network that party is on.
I'm in the middle of an all-day conference call right now with a telco (geez they love conference calls), so I can't do much on this at the moment, but I'll be happy to provide a sample of what was found to be needed to make things work.
I know others have done it (I haven't myself), but I assume pulling out a working example out of their (probably complex) ser.cfg is the reason for why you haven't received an example on this list.
Actually it is pretty simple as we run separate instances of SER for each "trunk". This was a lot easier than adding tests everywhere that didn't always work for whom this and what features they are supposed to get or not get), but as I have been forced to add some calls and flags to the various nathelper to get around problems and limitations. It also gets around a bug in rtpproxy that I have never been able to fix that causes it to always assign the two IP addresses it hands out in the order they are listed on the command line, regardless of the flags you pass. Again, something that probably works fine when only one interface is used, but goes off the rails when two are used that are isolated and if you get an address not on your network, the audio for that call is dead.
Finally, I assumed people seeing mystery flags and extra parameters to known calls would be a major distraction and prevent any review from getting to the heart of the issue I was asking about.
I was planning to contribute those enhancements back (so I don't have to keep re-importing them), but haven't had the time to do that yet.
As Michal points out, it's really all about building the right Record-Route set in one direction (for route-changing messages) and constructing the reverse in the other direction (the user agent's responsbility). Your problem has been that the last hop towards the user agent uses the request uri and as you "fixed" the contact, this uri will be wrong. Unless you have a way of "unfixing" the ruri of the last-hop in-dialog messages, the message will either loop or go out some other direction (depending on your ser.cfg).
Like I said, if you could get SER to put out the right IP address in Contact that is on the same network as the interface that given message was sent from, all would be well. But it doesn't do that, unless you force it.
I can certainly go back and pull the SIP messages intercepted from calls showing it doing the wrong thing unless you either went back to one interface , allowed the two networks to not be isolated from one another, or use fix_nated_contact liberally to show the distant parties IP addresses that they can actually reach. This isn't a NAT thing, although I expect someone using two interfaces to reach across a network that was NATed would have equal trouble.