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