cisco asa-asa tunnel from dmz port on one side - same subnets on both sides

You're not accidentally doing NAT exemption are you? If you can post the sanitized config of each I can go through it real quick and verify NAT/Policy NAT is correct.

there is a nat exemption on that DMZ port, but not for the tunnel.  I need that to exempt traffic from the dmz into the inside, and to one other dmz port defined on the asa (192.168.5.1/24).

nat (dmz) 0 access-list acl_dmz_nonat

acl_dmz_nonat permit ip 192.168.7.0 255.255.255.0 192.168.5.0 255.255.255.0
acl_dmz_nonat permit ip 192.168.7.0 255.255.255.0 192.166.1.0 255.255.255.0

Would I need to also static map in place of the nat exemption?

static (dmz,inside) 192.168.7.0 access-list acl_dmz_inside
static (dmz,dmz2) 192.168.7.0 access-list acl_dmz_dmz2

acl_dmz_inside permit ip 192.168.7.0 255.255.255.0 192.168.5.0 255.255.255.0
acl_dmz_dmz2 permit ip 192.168.7.0 255.255.255.0 192.166.1.0 255.255.255.0

No since they're not part of the encryption traffic it wouldn't be necessary

I made that change anyways.  there is no "nat (dmz,outside) 0" of any kind.  There are other nat 0's for other dmz ports but they are also acl-based.

The remote side too, with no dmz, does not show any crypto traffic.  I removed the nat 0 on that side as well.

This is Site B - the slightly less complex config.  This does not generate any crypto isa debugs when I "ping inside 10.222.77.10".

(I am external to both devices and only have ssh access to a device in the dmz at Site A - so I can try to ping from 192.168.7.10 to an internal IP at Site B - that doesn't generate crypto debug either).

ASA Version 8.2(5)
!
hostname mmasa5505
domain-name mmp.com
enable password cLY95rSlw5/gj3iX encrypted
passwd 2KFQnbNIdI.2KYOU encrypted
names
!
interface Ethernet0/0
 switchport access vlan 2
!
interface Ethernet0/1
!
!
interface Vlan1
 nameif inside
 security-level 100
 ip address 192.168.1.1 255.255.255.0
!
interface Vlan2
 nameif outside
 security-level 0
 ip address 24.111.222.98 255.255.255.248
!
clock timezone GMT 0
dns domain-lookup outside
dns server-group DefaultDNS
 name-server 208.67.222.222
 name-server 208.67.220.220
 name-server 4.2.2.2
 domain-name mmp.com
access-list acl_crypto_ibs extended permit ip 10.24.111.0 255.255.255.0 10.222.77.0 255.255.255.0
access-list in.outside extended permit icmp any any echo-reply
access-list acl_nat_inside_ibs extended permit ip 192.168.1.0 255.255.255.0 10.222.77.0 255.255.255.0
mtu inside 1500
mtu outside 1500
icmp unreachable rate-limit 1 burst-size 1
icmp permit any outside
global (outside) 1 interface
nat (inside) 1 0.0.0.0 0.0.0.0
static (inside,outside) tcp interface www 192.168.1.28 www netmask 255.255.255.255
static (inside,outside) 10.24.111.0  access-list acl_nat_inside_ibs
access-group in.outside in interface outside
route outside 0.0.0.0 0.0.0.0 24.111.222.97 1

dynamic-access-policy-record DfltAccessPolicy

crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac
crypto ipsec security-association lifetime seconds 28800
crypto ipsec security-association lifetime kilobytes 4608000
crypto map outside_map 1 match address acl_crypto_ibs
crypto map outside_map 1 set peer 222.77.227.130
crypto map outside_map 1 set transform-set ESP-3DES-SHA
crypto map outside_map interface outside
crypto isakmp identity address
crypto isakmp enable outside
crypto isakmp policy 10
 authentication pre-share
 encryption 3des
 hash sha
 group 2
 lifetime 86400
ssh 192.168.1.0 255.255.255.0 inside
ssh timeout 30
management-access inside
dhcpd dns 192.168.1.1 4.2.2.2
dhcpd auto_config outside
!
dhcpd address 192.168.1.201-192.168.1.254 inside
dhcpd enable inside
!

threat-detection basic-threat
threat-detection statistics access-list
no threat-detection statistics tcp-intercept
webvpn

tunnel-group 222.77.227.130 type ipsec-l2l
tunnel-group 222.77.227.130 ipsec-attributes
 pre-shared-key *****
!
!

You don't have any ACL's configured, are you allowing VPN traffic via the "sysopt connection permit-vpn" command?

I'm not getting phase 1 or phase 2.

The packet trace on Site B is dropped at the VPN step - after it NAT's to the "made-up" address.  It seems like the acl_crypto_ibs is not coming up with a match.  

So it NAT's 192.168.1.10 to 10.24.111.0/24 in the previous steps.  Let me know if you need the entire packet trace - I'm editing the IP's so the less I have to edit, the less likely I am to make a mistake here.

Phase: 6
Type: VPN
Subtype: encrypt
Result: DROP
Config:
Additional Information:
 Forward Flow based lookup yields rule:
 out id=0xca1e5180, priority=70, domain=encrypt, deny=false
        hits=1, user_data=0x0, cs_id=0xc9d70848, reverse, flags=0x0, protocol=0
        src ip=10.24.111.0, mask=255.255.255.0, port=0
        dst ip=10.222.77.0, mask=255.255.255.0, port=0, dscp=0x0

I noticed earlier you are testing by doing "ping inside 10.222.77.10". You should be testing from a workstation on the inside and not from the ASA itself as typically you cannot ping across a VPN when sourcing from the ASA (there are ways around this but let's just stick to basics for testing)

What is the "way around" pinging from the ASA into a tunnel?  That would be helpful.

I must have had a typo somewhere, or an overlapping nat on the Site A side.  I moved the connection to one of the other named dmz ports in a different local subnet (192.168.4.0/24), and re-configured using the same principles, including the "nat (dmz4,outside) 10.222.77.0 access-list acl_nat_remote"...

The tunnel came up and the packet-tracer on Site B no longer drops the packet - I'm guessing that means it was dropping it before because the tunnel was not up, and the "ping inside" from Site B was not enough to bring up the tunnel.

I still can't ping across, but the tunnel is up, which is my OP.

Thanks!

Not the solution directly, but led me to rebuild the config on Site A and move the NAT to a different named dmz port.

The management-access interface command allows you to ping the ASA's inside interface