Greger Viken Teigre wrote: I don't believe I understand what you are asking re: active media. Are you talking about some control I can set in SER or rtpproxy? Because those are the only knobs available to me. The company sending the call to us doesn't want to change settings on their equipment to accomodate what they consider to be our incompatibility (what rtpproxy is doing), as what they are doing (not sending audio until they receive audio from us) isn't a problem when they send calls to other carriers. If you are suggesting something I have SER patch into the 183/200 SDP payload to trick the calling system to send audio without waiting to see some audio from us, what exactly are you suggesting be added and how would that be done? As a FYI, the PSTN gateway switch behind our SER system has virtually no SIP controls, as the first thing it does is make the call look as much like a TDM call as possible, right down to assigning a pseudo trunk number for the call to be carried in. Of course, this is the device that is happily sending RTP audio which rtpproxy is throwing away, so I don't think I can fix the problem from that side even if there was a knob to change something since this side is already working. And yes, you can create this same problem that I am reporting by having the audio for a call pass between two SER systems with rtpproxy on both with no NAT present whatsoever (no re-routing of audio, just bridging isolated networks). Neither rtpproxy daemon will blink until the other does, and so audio never works. This has got to be wrong. I'll point out that when I reported this a month of two ago, someone on the list came out and said rtpproxy does not do what I was reporting, can't do this, always passes audio in a given direction the instant the SDP payload for that direction passes through SER. I don't find that to be the case and the demonstration proves that the behavior is different. I also don't understand the comment above about sending back to the source port. From what I can see, rtpproxy opens four separate ports, two on each interface, one for incoming and one for outgoing on each I would assume. If not, then that would be a different bug as rtpproxy is opening twice the number of ports it actually needs. (I think it is using all four in the two-interface mode.) Please clarify what you are saying/suggesting if you can. Examples appreciated. Thanks.