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 _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
