Rsrb with multiple ring groups on head ends with one phy ring?

Question

working on an issue for a customer and I cant find good documentation on this anywhere for multiple ring-groups
have 2 routers, each with 2 ring groups connected on a mau terminating multiple serial connections (wan, hence the rsrb) and utilizing rsrb tcp with local ack. The configuration was done sometime ago. It was set up to utilize frame which now they are using ptp t1s. I see in the remote routers they are forwarding pakcets to both routers to ring 20. (there are 2 routers if one fails then it is meant to learn its path to the CIP through the other router)
---------router1
source-bridge ring-group 30
source-bridge ring-group 31
blahblah peers tcp local-ack
int t0
source-bridge 20 1 30 <----notice bridge 1
source-bridge spanning
int t1
source-bridge 20 1 31 <----notice bridge 1
source-bridge spanning
--------router2
source-bridge ring-group 30
source-bridge ring-group 31
blahblah peers tcp local-ack
int t0
source-bridge 20 2 30 <----notice bridge 2
source-bridge spanning
int t1
source-bridge 20 2 31 <----notice bridge 2
source-bridge spanning
I thought the physical rings had to be different in order to run parrallel links. Or are different bridge #'s feasible? The end issue they are having is that when links bounce, they are not releasing the tcp session and the show llc shows remote sides as busy and the head end as connected. (then obviously removal of local ack fixed the issue)
Not ready to live without local ack... could the same ring # on both routers be the issue since they are on the same mau and destined for the same location?
==MAU to CIP==
| | | | all physical connection on mau are ring 20
router1 router2
| | | | | ring groups 30 and 31 configured on both routers with 1 statement to each router in the network per router (so each remote side is only connected to either ring group 30 or 31 (not both since you can only do over token ring) and the show source-bridge is showing forwards to each head end router's physical ring 20. I thought I would see one with forwards the other 0 since first response, but then saw the bridge # differed.)

Answer 1

case was opened over a month ago with no luck or serious help. Have had great luck in the past with tac, but this one was frustrating and nothing was done.
case#D039413
And the remote routers connect directly to the cip with LLC2. (end to end connection, not remote to router 1 and 2 to CIP)
show llc shows the local mac of the gateway and the cip token.
the network goes like this
rr = remote router
fr= frame relay
ptp= ptp t1
rtr1 and rtr2 = router 1 and 2
rr--fr--rr--ptp--rtr1 and rtr2 ---rr---cip
I have tried numerous things on this and its apparent that the only option is dlsw and I have pressed the issue enough to start on it with test segments.
my theory was when the host queried the gateway, its first reply was local-ack on rtr2 (could be rtr1 but for theory we will say rtr2) which was giving back RR and the other end was actually in a disconnect state and sending rnr's to the rtr1 (in this exapmple the host was talking thru rtr2 to the remote side and the remote side was trying the opposite router) which local ack would reply to the supervisor frames
what was causing the problems in my opinion is the host provider does not utilize local ack since they only have lanned token rings and the customer provides their own wan routers. So the explorer would be answered quicker by the other router and that would be the source route bridged path to the remote side, where the other sides local ack and rif cache was routing through the opposite router. Unfortunately the site where we collected the data on I can not test since I have transitioned it to dlsw to solve their issues and show them the benfits of dlsw