Hi, It can be made to work - trust me
Phone A puts Phone B on hold The new Session A-> MoH Invite contains the relay port of the existing A->B call (functionality fixed by the phone, it thinks it is passing phone B) the MoH server will now start to send audio to the mediaproxy session for the original A-B Call you now replace phone A in that session with the IP:port of the inbound MoH RTP audio will now flow from the MoH to Phone B when Phone A takes B off hold the original connections will be re-established We have a well defined subnet were all our servers live, so you can make this process secure by restricting this operation to that subnet Stuart Ruud Klaver wrote: > Hi, > > On 30 Jun 2009, at 19:42, Stuart Marsden 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) > > So the phone actually starts a completely new session to the MoH > server, which never receives any RTP in this session? This can never > work, because the relay needs to receive RTP from the other endpoint > of the session to know where to send the RTP from the MoH server to. > All it has learnt from the SDP exchange is its own IP, because that > was put as the RTP endpoint by phone A. > > Ruud Klaver > AG Projects > > _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
