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