ASR1K 5xE1 MFR Frame relay traffic not forwarding in one direction

Question

 Dear Techies, 
 Hope all is well !
Im doing this inter-op testing with Alcatel device for frame-relay and MFRs and got stuck at this situation which is actually mind boggling and I think i might be missing something "silly" :-(
Its a simple setup of
1. My ASR 1002-X with a LAN (Gig0/0/0) port is connected to a traffic generator.(ixia).
2. ASR WAN port is a 5xE1 bundled into a MFR circuit.
3. WAN link goes to a Alcatel box giving me my FR-DCE with E1s over MFR.
Issue is , I can send traffic to max throughput with  flow initiated from  LAN to WAN bit NOT the reverse flow initiated  from WAN side to LAN port. I see traffic coming into my 5xE1s (1.8 mbps each) but the traffic just wont go to the LAN side , somewhere it gets "stuck" or "dropped".
PING works fine from both sides.......but sending traffic is not possible !!
ASR CONFIG
controller SONET 0/3/0
 framing sdh
 clock source line
 aug mapping au-4
 au-4 1 tug-3 1
  mode c-12
  tug-2 1 e1 1 unframed
  tug-2 1 e1 2 unframed
  tug-2 1 e1 3 unframed
  tug-2 2 e1 1 unframed
  tug-2 2 e1 2 unframed
  tug-2 2 e1 3 unframed
 au-4 1 tug-3 2
  mode c-12
  tug-2 1 e1 1 unframed
  tug-2 1 e1 2 unframed
  tug-2 1 e1 3 unframed
 au-4 1 tug-3 3
  mode c-12
interface MFR1
 no ip address
 encapsulation frame-relay IETF
 load-interval 30
 frame-relay multilink bid 10MB-PiPe
 frame-relay multilink bandwidth-class a
 frame-relay lmi-type ansi
interface MFR1.1 point-to-point
 ip address 10.10.17.2 255.255.255.0
 frame-relay interface-dlci 100   
interface GigabitEthernet0/0/0
 no ip address
 load-interval 30
 negotiation auto
interface GigabitEthernet0/0/0.110
 encapsulation dot1Q 110
 ip address 11.11.11.1 255.255.255.0
interface Serial0/3/0.1/1/1/1:0
 no ip address
 encapsulation frame-relay MFR1
 frame-relay multilink lid First-Link
interface Serial0/3/0.1/1/1/2:0
 no ip address
 encapsulation frame-relay MFR1
 frame-relay multilink lid Second-Link
interface Serial0/3/0.1/1/1/3:0
 no ip address
 encapsulation frame-relay MFR1
 frame-relay multilink lid Third-Link
interface Serial0/3/0.1/1/2/1:0
 no ip address
 encapsulation frame-relay MFR1
 frame-relay multilink lid Fourth-Link
interface Serial0/3/0.1/1/2/2:0
 no ip address
 encapsulation frame-relay MFR1
 frame-relay multilink lid Fifth-Link
SDH_FR#sh frame-relay mul
SDH_FR#sh frame-relay multilink 
Bundle: MFR1, State = up, class = A, fragmentation disabled
 BID = 10MB-PiPe
 Bundle links:
  Serial0/3/0.1/1/1/1:0, HW state = up, link state = Up, LID = First-Link
  Serial0/3/0.1/1/2/2:0, HW state = up, link state = Up, LID = Fifth-Link
  Serial0/3/0.1/1/2/1:0, HW state = up, link state = Up, LID = Fourth-Link
  Serial0/3/0.1/1/1/3:0, HW state = up, link state = Up, LID = Third-Link
  Serial0/3/0.1/1/1/2:0, HW state = up, link state = Up, LID = Second-Link
SDH_FR#
SDH_FR#
SDH_FR#
SDH_FR#sh fram
SDH_FR#sh frame-relay pvc 100
PVC Statistics for interface MFR1 (Frame Relay DTE)
DLCI = 100, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = MFR1.1
  input pkts 8045          output pkts 8044         in bytes 515748    
  out bytes 527920         dropped pkts 0           in pkts dropped 0         
  out pkts dropped 0                out bytes dropped 0         
  in FECN pkts 0           in BECN pkts 0           out FECN pkts 0         
  out BECN pkts 0          in DE pkts 0             out DE pkts 0         
  out bcast pkts 0         out bcast bytes 0         
  5 minute input rate 1000 bits/sec, 2 packets/sec
  5 minute output rate 1000 bits/sec, 2 packets/sec
  pvc create time 01:07:58, last time pvc status changed 01:07:58
  fragment type end-to-end fragment size 1400
SDH_FR#
SDH_FR#
SDH_FR#
SDH_FR#
SDH_FR#
SDH_FR#
SDH_FR#ping 10.10.17.1-------------------------------------------------------------------------- THIS IS ALCATEL SIDE FROM TRAFFIC HAS TO COME.
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.17.1, timeout is 2 seconds:
Success rate is 100 percent (5/5), round-trip min/avg/max = 3/3/4 ms
SDH_FR#
SDH_FR#
SDH_FR#sh frame-relay traffic
Frame Relay statistics:
        ARP requests sent 0, ARP replies sent 0
        ARP request recvd 0, ARP replies recvd 0
SDH_FR#

Answer 1

What is the access rate of the head end?
Are you using a codec other than G711?
How many total sites are involved, what protocols are you running?
From the math, 32K is not enough CIR to ensure 4 calls proper Bandwidth. At what point is the voice degrading, is is choppy missing message, sound, jitter, echo or after 1, 2 or 3 calls.
Even if you are using G729a, voice packets could be dropped. Not to say that it is here, but look at the FRS stats to see ip packets are being dropped.
Traffic shaping is always recommended, rtp header compression will help, but the trade-off is around a 20% CPU hit.
If you implement traffic shapping , it needs to be done throughout the network as queueing delays related to data on other slow links and at the headend (specifically here) could be the cause of the distortion alone. I would at least try traffic shapping first, then if the problem doen't go away, increase CIR for Voice, if there are still issues, implement LLQ.