I'm having a problem with Mediaproxy, and am wondering if this is something it simply can't do (or won't do as written).

I have a SER/mediaproxy server connected to two networks that cannot be reached by other means. So the only way for a SIP phone on one network to have a conversation with the other would be for the SER/mediaproxy combination to accept the audio from one side and shove it out to the destination on the other end.

Network diagram: [SIP phone]---------+ [Asterisk Server]--[ethswitch]---[interface re2 on SER box]

[PSTN switch]--------------------[interface re0 on SER box]

SIP phone 192.168.200.20 Asterisk box 192.168.200.10 SER re2 192.168.200.30

PSTN switch RTP 10.9.193.146 SER re0 10.9.193.148

Again, these two networks are isolated and only meet at the SER box. This layout was a prototype for later use of NAT and the fact that the Asterisk (or a similar device) and phones would be at another company, on a network likely NAT-ed at least one more time. But for the moment there is no NAT activity, just two networks that can't send SIP data to each other except by what SER and mediaproxy/rtpproxy allow.

What we see is that the call originating at the SIP phone is set up, the distant POTS phone rings, POTS phone answers, the SIP phone is informed, and we see audio passing from the PSTN network to the SER box, but no audio in either direction between SER box and SIP phone.

So, mediaproxy did manage to insert itself into things enough so that the PSTN gateway knows the audio should go to a port there, so that is working.

The reason for no audio on the SIP-phone side appears to be that mediaproxy is only aware of a single network interface being involved, and when the call was established, it gave the SIP phone an unreachable IP address of the network interface on the PSTN side of the SER box, not the IP address of the SER server interface on the side that is facing the SIP phone.

(Packet sniff as viewed leaving the SER server)

# U 192.168.200.30:5060 -> 192.168.200.10:5060 SIP/2.0 200 OK. Call-ID: 7d640cca12391c1601a2d6e535c1ef2d@192.168.200.30. CSeq: 102 INVITE. From: "VOIP TEST 1000" sip:3797271700@192.168.200.30;tag=as5fc6504f. To: sip:9613789999@192.168.200.30;tag=13f0000-0-402969611. Via: SIP/2.0/UDP 192.168.200.10:5060;branch=z9hG4bK7d39191f;rport=5060. Server: DC-SIP/1.2. Supported: timer. Record-Route: sip:9613789999@192.168.200.30:5060;nat=yes;ftag=as5fc6504f;lr=on . Contact: sip:9613789999@10.9.193.130:5060. Content-Type: application/sdp. Content-Length: 175. . v=0 o=- 3411495426 3411495447 IN IP4 10.9.193.130 s=- c=IN IP4 10.9.193.148 t=0 0 m=audio 10004 RTP/AVP 0 a=sendrecv a=ptime:20 a=rtpmap:0 PCMU/8000 a=silenceSupp:off - - - -

# U 192.168.200.10:5060 -> 192.168.200.30:5060 ACK sip:9613789999@10.9.193.130:5060 SIP/2.0. Via: SIP/2.0/UDP 192.168.200.10:5060;branch=z9hG4bK6793020d;rport. Route: sip:9613789999@192.168.200.30:5060;nat=yes;ftag=as5fc6504f;lr=on. From: "VOIP TEST 1000" sip:3797271700@192.168.200.30;tag=as5fc6504f. To: sip:9613789999@192.168.200.30;tag=13f0000-0-402969611. Contact: sip:3797271700@192.168.200.10. Call-ID: 7d640cca12391c1601a2d6e535c1ef2d@192.168.200.30. CSeq: 102 ACK. User-Agent: Asterisk PBX. Max-Forwards: 70. Content-Length: 0. .

but because the c=IN IP4 10.9.193.148 isn't set to 192.168.200.30, the SIP phone doesn't send any audio that is addressed for the SER/mediaproxy box, and so no one or two-way audio happens.

So the ten %currency_unit question is this: Is this a limitation of Mediaproxy, that all audio must enter and leave (from and to all sources) on a single interface? A look at the source code suggests that it can only cope with a single interface, but I have not written code in Python, so may not be reading this right.

The second question would be is this also a restriction of rtpproxy, or can it deal with having two or more network interfaces handling audio traffic? If it can, we'll switch to rtpproxy. If neither can handle it, we have problems.

It seems odd that SER supports this situation but the audio component would not.

Our mediaproxy is 1.7.2 Our ser is 0.9.6

Thanks in advance,

Frank