[Serusers] Can SER 2.0.0-rc1 pstn.cfg file actually work with BYE from PSTN?

[Frank Durda IV]

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.