Tony Graziano said,

"They are supposed to be the same. The phone does not matter here.
Sipxbridge manages that. Your vyaTta router is not doing symmetric nat."

Ok, I see that now. I traced the packets on the public side and indeed the
firewall is rewriting the port number. So if I can change my firewall to
symmetric NAT it will work. However, if I understand correctly, it will not
be optimal. Please allow me to explain.

First there is a problem with when the port is opened. Sipx request media be
sent to port 30000 (for example) AND sipx will send media from port 30000.
If the gateway send media to sipx before sipx sends media to the gateway the
port will not be opened. Sipx must send media to the gateway first to allow
the NAT masquerade rule to be established, thereby establishing an inbound
connection.

This has been verified with a packet trace. The gateway sends the ring tone
to the phone upon receiving the INVITE, but the RTP stream is blocked. After
the phone receives the 183 Session Progress it begins sending some media
(also a ring tone???). This opens the port and allows the gateway's ringtone
through, which is then heard on the phone handset. At least that's how it
would work if I had symmetric NAT.

The second problem is that sipx doesn't need to be involved in the media.
Ideally sipx would leave the SDP alone so that the gateway would send media
directly to the phone. This is possible if the firewall performs the ALG
function by opening the port within the SDP and creating a DNAT rule to
forward the traffic to the phone. This would allow my network solution to be
much more scalable.

Working is better than not working, so of course if I can't implement the
optimal solution what you said is fine. Please correct me if I misunderstood
something.

Thanks again,
Brian


_______________________________________________
sipx-users mailing list sipx-users@list.sipfoundry.org
List Archive: http://list.sipfoundry.org/archive/sipx-users
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users
sipXecs IP PBX -- http://www.sipfoundry.org/

Reply via email to