Seeing an interesting issue with sending an eavesdrop where the outbound call gets established, but no useful audio is transmitted until around 15-30 seconds into the call. Prior to that point, FS is transmitting all identical RTP frames with the payload containing: 24 1c 61 7a 7f 55 55 55 50 06 83 ff ff ff ff ff ff ff ff ff ff ff ff aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa af ff ..... ff This is minimal version of command that was being issued: originate sofia/internal/6679@voice-dev.mst.edu &eavesdrop(ca887b3b-013f-4972-aa7c-37a7b132bf52) Reproduced with head of master as of a few minutes ago. Restarting FS and trying again, the FIRST attempted eavesdrop seems to not have the long delay, but the second one does. The 'dummy' payload appears to have the same content in subsequent requests. Interestingly, if I let the outbound call ring longer before I pick up, the delay appears to be reduced by the period of time I let the phone ring for. if I pick up immediately, 25-30 second audio delay approx, if I pick up after 25 seconds of ringing, I get only a couple second delay. Any idea where to start looking for where this buffering might be getting introduced? For the "only eavesdrop" case it's not as big of an issue, but when you switch over to barge, can't really have multi-second audio delay. -- Nathan ------------------------------------------------------------ Nathan Neulinger nneul@mst.edu Missouri S&T Information Technology (573) 612-1412 System Administrator - Architect