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

[Frank Durda IV]

Does SER 2.0.0-rc1/examples/pstn.cfg or the much more complete
one in Chapter 8 of "SER Getting Started" actually work when
it comes to a BYE comming from the PSTN gateway?

So far, it appears these two cfg files don't cope with the
called party on the PSTN hangs up first, and it isn't clear
how it could be made to work in anything more complex than
a one-SIP-call-source one pstn-gateway configuration.

Let's say I have four clients from which a call can originate
and arrive at SER, with the caller source IP addresses of
"A", "B", "C" and "D".   "C" sends the INVITE of a call
that SER determined is destined for the PSTN gateway, which
is at IP address "P".  Here, the INVITE, 100 Trying,
180/183, 200 OK and ACK messages all go to the right
places and look more or less correct.

If "C" sends a BYE to end the call, this also works
correctly, with SER forwarding that on to "P" and the
200 OK being returned.  So far, so good.

However, if the called party on the PSTN hangs up first,
"P" sends SER a BYE and SER simply sends the BYE right
back to "P", whom responds with a "481" back.  The
originating party at "C" never finds out that the call
has ended, because SER didn't pass the BYE on to the
calling device.  The SIP phone stays in the "Connected"
state.

In my case, the calling sites A, B, C and D don't include
a Record-Route of their own, but sometimes have a Via:
header.  In either case, SER still doesn't send a BYE or
re-INVITE coming from P to the correct destination of
A, B, C or D.

I don't know how I could force SER to send the BYE or INVITE
on to the right place, given four possible call-initiator
IP addresses, of which only "C" would know about
this sample call.

I don't believe I can stick in an extra Record-Route when
handling the original INVITE that has the call source IP
address in it (in addition to a Record-Route of my own),
simply because I don't believe SER will let me dynamically
select which senders IP address should go in the forged
Record-Route, or if doing so would really help the situation
later when that trail of crumbs might be helpful.

Also, even though the pstn.cfg sample in the book has lots
of steps to check for fraud before processing a re-INVITE
coming from the PSTN (and the footnotes say that this is what
these checks are for), I don't see how SER would know
the right place to send the re-INVITE that came from the
PSTN once it the authentication checks were done.  It looks
like SER will always send it to "P" regardless of which
direction it should be sent, which doesn't help much, and
puts any call using Session-Expires: to failure, when 50%
of that time (plus 32.5 seconds) has passed.


So, is there with a corrected pstn.cfg out there, or better
still, has anybody actually made these two situations work,
which are:
(1) The called party on the PSTN hangs-up first which
causes a BYE to be sent to SER.  SER forwards the BYE to
the right caller (or whatever the so-called proxy is
supposed to do), AND
(2) the SIP-PSTN gateway device sends a re-INVITE to
SER and it goes somewhere that will generate an OK reply

If someone has made it work, can they show an example,
rather than just say "it should be possible" or "works for me"?
Such responses are encouraging, but not that helpful.
Thanks in advance!