[OpenSER-Users] SIP Trunk doesn't response to 200OK with an ACK

Robert Dyck rob.dyck at telus.net
Mon Feb 18 17:45:52 CET 2008


You can move openser to the "edge" so that it can have a public address. This 
can be done with openwrt installed in compatible routers or use an obsolete 
cumputer ( dirt cheap or free, you do not need much horsepower ) with a 
private and public interface. It can also host the rtpproxy. Openser can 
listen on both interfaces. The default behaviour of the RR module is to add 
two entries to the RR list, the public and private IP's.

On Monday 18 February 2008, Iñaki Baz Castillo wrote:
> El Monday 18 February 2008 14:33:25 Eric Phetteplace escribió:
> > Sorry about that: Network Topology.
> >
> > 8.21.8.24 is the PSTN gateway (WAN IP)
> >
> > 192.168.2.5 UAS (simple IP phone, "PC to PC" no registrar, etc)
> > 192.168.2.1 NAT Router with 192.168.2.10 in DMZ  WAN Address is 2.6.7.9
> > in my previous message.
> > 192.168.2.10 OpenSER and RTPProxy.
>
> Do you have then port forwarding in the router? I think so but please
> confirm it.
>
> In that case the problem is simple: your OpenSer set a "Record-Route:
> 192.168.2.10" so in the next in-dialog message from the UAC or UAS it will
> be routed to that IP.
>
> Note that:
>
> - Your PSTN gateway calls to a PSTN number that is received in your
> OpenSer. - The INVITE arrives to your OpenSer who adds  "Record-Route:
> 192.168.2.10". - Then it sends the INVITE to the local phone (UAS).
> - The UAS replies with 200 OK. This reply arrives to the OpenSer who
> adds "Record-Route: 192.168.2.10" and forwards it to the gateway.
> - Now the gw has to send an ACK, but note that the ACK is an **in-dialog**
> request so it will go throught the IP set in "Record-Route" (192.168.2.10).
> - Of course, your gw **cannot** route a request to a private IP so it's
> lost.
>
> Solution: You must force OpenSer to set a custom IP (your router public IP)
> in the "Record-Route" header **just** when the request goes to the gateway.
> I'm not sure on how to do it but I think I've read sometime a about it in
> this maillist.
>
> In conclusion: It's not a fault in your provider, but in your
> configuration.






More information about the sr-users mailing list