[Serusers] Can mediaproxy support relaying audio between destinations on two ethernet interfaces?

[Frank Durda IV]

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 at 192.168.200.30.
CSeq: 102 INVITE.
From: "VOIP TEST 1000" <sip:3797271700 at 192.168.200.30>;tag=as5fc6504f.
To: <sip:9613789999 at 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 at 192.168.200.30:5060;nat=yes;ftag=as5fc6504f;lr=on>
.
Contact: <sip:9613789999 at 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 at 10.9.193.130:5060 SIP/2.0.
Via: SIP/2.0/UDP 192.168.200.10:5060;branch=z9hG4bK6793020d;rport.
Route: <sip:9613789999 at 192.168.200.30:5060;nat=yes;ftag=as5fc6504f;lr=on>.
From: "VOIP TEST 1000" <sip:3797271700 at 192.168.200.30>;tag=as5fc6504f.
To: <sip:9613789999 at 192.168.200.30>;tag=13f0000-0-402969611.
Contact: <sip:3797271700 at 192.168.200.10>.
Call-ID: 7d640cca12391c1601a2d6e535c1ef2d at 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