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

[Greger Viken Teigre]

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. 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.
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).

g-)


Frank Durda IV wrote:
> A follow-up on this.  One of the questions  Mr. Teigre asked
> earlier got me thinking about some things I tried some months
> ago where I thought I solved these issues before getting
> stuck on one point and not being able to get any ideas on
> the list at that time about what was going on.   This evening
> I went back and tried reducing the ser.cfg file, then adding
> the pieces back as long as each one got things closer to what
> was desired.
>
> I finally hit on a combination that works and visually seems
> correct, but at a cost that I guess I will have to pay.
> It requires me to abandon using two interfaces for SER.
> I have to let the router split the traffic towards the two
> now-not-as-isolated networks rather than let SER sit between
> the two isolated network as was the original design.   Router
> access lists will have to provide protection to keep rogue
> packets from the public network from reaching the isolated
> network with the PSTN switch, rather than letting SER stand
> entirely in the way as was the original design.
>
> The reason SER doesn't appear to work with two interfaces that
> connect to two isolated networks is pretty simple:  If you use
> record_route() and loose_route() to handle the called-party BYE
> and re-INVITEs addressing correctly and fix_nated_contact()
> to straighten out the Contact headers in both directions
> on most messages, SER also inserts two Record-Route: headers,
> which is fine for the direction the Method message is sent in,
> but the order is only good for that direction.  On the replies
> (such as 180/183/200) once you get past the SER, everything
> falls apart.  The two Record-Routes that come out of SER
> (or are just passed-through) are now in the wrong order for
> the side of the isolated networks that the reply is sent out
> of SER to, so the machine receiving them tries to send the
> PRACK/ACK back to SER on the IP address of the other isolated
> network because that Record-Route line appears first, and of
> course you can't get there from here.
>
> If you force the Record-Routes to come out with the listener IP
> addresses in reverse order, then the same scenario just fails
> earlier, because now the PSTN gateway sees the first
> Record-Route of the network it can't reach and sends the
> 180/183/200 reply there, so it promptly gets lost since that
> destination can't be reached either.
>
> There doesn't seem to be any logic in SER to flip the order
> of the two Record-Routes that SER added when the replies pass
> back through SER (or are regenerated in that order by SER),
> even though SER knows both of these Record-Routes are ones
> that it added.   As these are reply messages, I doubt I can
> use the ser.cfg language to fix the problem since SER doesn't
> allow much editing on reply messages.  It will likely require
> a code change somewhere within SER to allow isolated networks
> each on its own interface to really work.
>
> The earlier samples included various attempts to avoid the
> record_route/loose_route trap, but that meant much more
> complexity in the ser.cfg file and even then all the issues
> couldn't quite be resolved.
>
>
> As I have been battling many different problems with SER
> for two years now and many of the problems are the result of
> trying to use the two listener/interface address feature,
> I think I will give up now and go with just one listen
> interface.  The parts I need in SER seem to be really
> wired to only work that way.  Naturally, the SER documentation
> talks mainly about the one-interface model too.   Pity,
> because this was the main reason we originally wanted
> to use SER, to put a wall between outside IP traffic and
> only SIP messages that managed to get past SER config file
> and malformed packet checks would reach the somewhat
> vulnerable PSTN switch.   A poor-mans Acme Packet SBC
> if you will.  Unfortunately, SIP-capable PSTN switches
> are far too easy to confuse, or make angry, or both.
>
>
> Thanks to Mr. Teigre for responding and reviewing this mess.
>