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

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! _______________________________________________ Serusers mailing list Serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers