3) detect this special case and change existing
conntrack to point to
the MoH sever, putting it back later
Ruud Klaver wrote:
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.
Stuart wrote:
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
The 200OK SDP from the MoH sever is not used
So MoH starts to send Audio to what it thinks is (A) but actually sends
it to (B)
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"
Ignoring the 200OK from the MoH server for now
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)
Disruption to existing audio is fine as this will only happen on
transition to / from MoH
WDYT?
Stuart
Ruud Klaver wrote:
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
--
_________________________________
Dr Stuart Marsden
MyPhones.com - 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: [email protected]
_________________________________
|
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
