Based on my post yesterday, and the call trace I have, if Asterisk were to make a decision a little differently when sending the the ReINVITEs to phone B in your example (lets say Phone A is the one behind NAT) media might work both directions. In the trace I posted, asterisk first send a reinvite with the private IP of phone A, but then it sent a second reinvite with the visible IP of phone A, which I think would have made the call work in some NAT environments, but then it sent a *3rd* reinvite to phone B, back to the private IP of phone A, breaking the audio from phone B to phone A.
What I think happened was when phone A send the 200 OK for its reinvite, Asterisk saw the SDP info from that packet and triggered the 3rd reinvite to phone B, but since nat=1 was on, it should have ignored that SDP, or at least sent the visible IP in the 3rd reinvite and not the private IP. In case you don't have it handy, the call trace I am referring to is here: http://www.cheapnet.net/~mike/asterisk_excel_with_reinvite.log In this log, only the 192.x network is nat'd. 10.x and 172.x have straight routing between them. 10.10.11.77 is the visible IP to 192.168.222.197 according to 10.x and 172.x. _______________________________________________ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
