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

[Dan Pascu]

On 30 Jun 2009, at 15: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

That is not an arbitrary restriction. That is how the forwarding works  
at the conntrack level. You have four IP:port pairs (2 a tthe  
endpoints and 2 on the media relay machine). The conntrack rule simply  
forwards the packets between the far endpoints using the 2 local  
IP:port pairs as a meeting ground. You cannot simply mix in data  
coming from some other random IP:port source that was not initially  
specified in the conntrack rule when it was created.

>
> 2) detect this special case and construct a temporary additional  "1
> way"  conntrack just for the MoH
> 3) detect this special case and change existing conntrack to point to
> the MoH sever, putting it back later
>

How exactly do you imagine that this special case can be detected,  
since you said that the second call is unrelated to the first at the  
SIP level? You want to match the proposed IP:port of some stream with  
whatever sessions you already have running and simply assume they are  
related? That is unfeasible and naive. If such a thing would be  
implemented, it will open the doors for hijacking RTP streams with  
official support from the SIP proxy and the media relay.

The proper way to do it (which by the way is already supported by  
mediaproxy) is to send a re-INVITE inside the same dialog with the  
proper IP:port in the stream pointing to the MOH, not to send a  
completely unrelated INVITE that creates a new dialog and hope that  
the proxy and the media relay will somehow figure out that they are  
related and magically bridge them.

--
Dan