<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<blockquote type="cite">3) detect this special case and change existing
conntrack to point to
<br>
the MoH sever, putting it back later
<br>
</blockquote>
Ruud Klaver wrote:<br>
<br>
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.
<br>
<br>
Stuart wrote:<br>
<br>
The problem is the Sipura/Linksys/Cisco Phones do it the other way
round - the phone going on hold (A) sends a normal sendonly to the
caller(B) . Then (A) sends a brand new invite to the MoH server(C) ,
passing what it thinks is the SDP of the phone (B), but is actually
the mediarelay<br>
<br>
The 200OK SDP from the MoH sever is not used<br>
<br>
So MoH starts to send Audio to what it thinks is (A) but actually sends
it to (B) <br>
<br>
I can detect at the SIP level the invite to MoH (based on the TO), the
SDP contains the IP:Port of a valid conntrack session , so inside
mediaproxy would need a new method called from opensips - "update the
conntrack session (ignoring callid,) using SDP IP:Port as a key"<br>
Ignoring the 200OK from the MoH server for now<br>
<br>
Then when the user is taken off hold the phone (A) will send a new
invite to undo the sendonly to (B) and drop the call to (C)<br>
<br>
Disruption to existing audio is fine as this will only happen on
transition to / from MoH<br>
<br>
WDYT?<br>
<br>
Stuart<br>
<br>
<br>
Ruud Klaver wrote:
<blockquote
cite="mid:D43D49CD-D128-4FA7-A85D-F14F39FF78FE@ag-projects.com"
type="cite">Hi Stuart,
<br>
<br>
On 30 Jun 2009, at 14:41, Stuart Marsden wrote:
<br>
<br>
<blockquote type="cite">Hi,
<br>
<br>
I am testing a mediaproxy sever using 2.3.4
<br>
<br>
The tests I have done so far have worked, however there is one scenario
<br>
where once the call has been setup a phone can generate Music on Hold
<br>
<br>
It does this by making a 2nd call (unrelated to the first at the SIP
<br>
level) and passes what it thinks is the IP:port of the 1st call far
end
<br>
(actually the mediaproxy) to the MoH server.
<br>
<br>
the MoH sever then sends audio to the mediaproxy.
<br>
<br>
However since the source of the audio is not the phone, conntrack is
not
<br>
forwarding on the audio to the other end.
<br>
<br>
Options as far as I can see are
<br>
<br>
1) remove the restriction on the source IP on who is allowed to forward
<br>
rtp - from what I have ready this probably wont work
<br>
</blockquote>
<br>
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?
<br>
<br>
<blockquote type="cite">2) detect this special case and construct a
temporary additional "1
<br>
way" conntrack just for the MoH
<br>
</blockquote>
<br>
No such thing, as they are bidirectional.
<br>
<br>
<blockquote type="cite">3) detect this special case and change
existing conntrack to point to
<br>
the MoH sever, putting it back later
<br>
</blockquote>
<br>
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.
<br>
<br>
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).
<br>
<br>
<blockquote type="cite">changes would be detected at the SIP level,
or more likely conntrack
<br>
call backs
<br>
<br>
any suggestions / help appreciated.
<br>
<br>
Stuart
<br>
</blockquote>
<br>
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.
<br>
<br>
Ruud Klaver
<br>
AG Projects
<br>
<br>
<br>
<br>
</blockquote>
<br>
<div class="moz-signature">-- <br>
<pre class="moz-signature" cols="72"><font color="fuchsia">_________________</font><font
color="red">________________</font>
<b>Dr Stuart Marsden
MyPhones.com - <font color="#cccccc">Extreme Digital Voice
Meade House
Chesham Rd
Wigginton
Tring
Herts
HP23 6JE
Myphones Voice: +44 (0)1494 414100
Legacy Voice: +44 (0)1494 758204
Fax: +44 (0)1494 757000
Mob: +44 (0)7788 107013
mail to: <a href="mailto:stuart@myPhones.com">stuart@myPhones.com</a></font></b>
<font color="fuchsia">_________________</font><font color="red">________________</font>
</pre>
</div>
</body>
</html>