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

[Greger Viken Teigre]

Frank Durda IV wrote:
> 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.

Well, I think the key point here is that I cannot see why that is a 
problem? As long as your SER can resolve the Contact when it is put in 
the request uri, you can put whatever you want in Contact (and reverse, 
when you "fix" it with fix_nated_contact you cannot resolve the contact 
when you receive it back in the BYE). It is not used by any of the 
parties when record routing is done. A UAC shall according to RFC3261 
send the request to the address in the topmost Route header and only use 
the Contact if there are no Route headers (section 12.2).
g-)

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