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

[Greger Viken Teigre]

Ok, Frank. You have told me that you don't want me to respond, but I 
will anyway as you are referring to the Getting Started config and I'm 
one of the authors.
Can you send some traces? I'm particularly interested in the first 
INVITE and the BYE, and of course the ruri and Route set in these.
There seems to be a problem with in-dialog constructed messages from 
your gw. They should be constructed as specified in RFC3261, section 12.
My guess is that there are no Route lines in the BYE (except for the one 
pointing to SER) and that the BYE's ruri has username at ip-of-gw (at least 
that would be the easy explanation :-)

g-)
PS. A top for later questions on the list: you are far more likely to 
get responses if you make it short and sweet and include details.

Frank Durda IV wrote:
> 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 at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers