[OpenSIPS-Users] Mediaproxy ver 2.3.4 - Conntrack meets Music on Hold

[Ruud Klaver]

Hi Stuart,

On 30 Jun 2009, at 14:41, Stuart Marsden wrote:

> Hi,
>
> I am testing a mediaproxy sever using 2.3.4
>
> The tests I have done so far have worked, however there is one  
> scenario
> where once the call has been setup a phone can generate Music on Hold
>
> It does this by making a 2nd call (unrelated to the first at the SIP
> level) and passes what it thinks is  the IP:port of the 1st call far  
> end
> (actually the mediaproxy) to the MoH server.
>
> the MoH sever then sends audio to the mediaproxy.
>
> However since the source of the audio is not the phone, conntrack is  
> not
> forwarding on the audio to the other end.
>
> Options as far as I can see are
>
> 1) remove the restriction on the source IP on who is allowed to  
> forward
> rtp - from what I have ready this probably wont work

The conntrack rule is bidirectional. If you allow data from multiple  
sources to one destination then how would the relay know where to send  
traffic in the reverse direction to?

> 2) detect this special case and construct a temporary additional  "1
> way"  conntrack just for the MoH

No such thing, as they are bidirectional.

> 3) detect this special case and change existing conntrack to point to
> the MoH sever, putting it back later

We actually considered implementing this, but not for this particular  
scenario. Some modems seem to switch IP address every X hours. If this  
change is during a relayed call, the RTP from one end will suddenly  
come from a new IP address, like in your scenario. What could be done  
is that the relay keeps listening on the allocated ports in userspace  
for traffic from a different host and switch the conntrack rule to the  
new IP if there is no traffic coming in anymore from the old IP.

The downside of this is that it could actually allow someone to hijack  
your call if the relay and port are known (and there is a temporary  
glitch in traffic in the conntrack rule).

> changes would be detected at the SIP level, or more likely conntrack
> call backs
>
> any suggestions / help appreciated.
>
> Stuart

How would you detect changes at SIP level in this case? The reason I'm  
asking is because the proper way your phone should deal with this is  
by sending a re-INVITE with the RTP endpoint of the MoH server in the  
SDP. This should trigger mediaproxy into resetting the conntrack rule.  
Does it currently do this, because this should already be working.

Ruud Klaver
AG Projects