I know the ingate devices have this feature to enable ring-back during transfer, so if it's a requirement you may want to look at once of those.
If the MoH server ever gets modified to support multiple MoH sources, it would be easy enough to simply have a "ringing" wav file and then add a configuration setting in sipxbridge that allows you to choose which MoH url to use during "hold" and which one during "transfer". I know multiple MoH source is in the tracker, just not sure what the ETA is on it. -M >>> "M. Ranganathan" <[email protected]> 06/26/09 9:38 AM >>> (Aside: We follow the convention of bottom posting in this list. Please add comments to the bottom when replying to posts. ) On Fri, Jun 26, 2009 at 9:14 AM, Tim Byng<[email protected]> wrote: > We've had the same discussion at my work about this. Everyone is in > agreement that silence is unacceptable. MoH is acceptable, but we would > prefer a ringback tone as well. Also, if you have call forwarding set up > (ring at same time) and MoH is enabled, you will first briefly hear the > music before you hear a ringback tone. It is not consistent for users > calling us, as sometimes they will hear music and sometimes a ringback tone. There is no easy way around it. As should be apparent by now, SipXbridge does more than simply proxy the request. Phones are set up to ring when they see a REFER until the called party picks up. When a calling party calls via the PSTN it never sees a REFER. One of the things sipxbridge does is to "Short" the REFER. This is because REFER ( call transfer ) is not handled by most ITSPs ( for accounting reasons I suspect ). When SipXbridge sees a REFER, it will convert this to an INVITE and sends the INVITE to the target of the REFER. Rather than have "dead air" in the period of time when the called party is ringing (unacceptable), sipXbridge initiates MOH by interacting with the park server. > > It's a minor issue for us, but I thought I'd share my opinion since the > subject was brought up. > > Regards, > Tim > > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Nikolay > Kondratyev > Sent: June 26, 2009 8:45 AM > To: 'M. Ranganathan' > Cc: [email protected] > Subject: Re: [sipx-users] no ringback tone on an auto attandant > transferredcall > > The thing is that it is quite common scenario: > Incoming call is routed to AA, caller dials several DTMF digits and the call > is routed to the recipient. > And callers are used to hear a ringback (for many years) after the call is > transferred to the recipient's phone. > Silence is completely unacceptable, music.. hmm... it's better then silence, > but anyway I would prefer a ringback tone... Not possible in general I'm afraid. We would have to simulate such a ringback tone and play it from the park server. It will not necessarily match the caller's ringback tone. Remember that Ringback is produced by the caller's phone. > > BTW, when an incoming call is coming "in an old way", not through a > sipxbridge, all is working as expected... caller hears an AA greeting, dials > internal number, hears a ringback tone... It would be ideal to have the user experience be unchanged in both cases but unfortunately this is difficult to achieve because of the "Shorted" REFER. > > I'm not sure if it is a good idea, but is it possible for sipxbridge to play > ringback tone to the caller in case the "incoming call leg" is already > established? Or something like that? sipXbridge simply interacts with the park server. I suppose we can support a special URL parameter which instructs the park server to play a "simulated Ringback tone" but it will not match the caller's expected ring tone. > > What is your recommendation in case one needs to route incoming calls > through AA, and MoH service should also work? It does work. Please turn on MOH for sipxbridge. The current working recommendation is to not have it *simultaneously* turned on for the phones and sipxbridge for a production system but please experiment with that too. I am willing to fix any bugs that may arise and it is a better configuration to have it work that way when all bugs have been worked out. > > Anyway I'll test the sipxbridge MoH capability and report the results. Please test MOH on the bridge with MOH on phones OFF as well as ON. Please make sure you are using r15853. I fixed a MOH related bug yesterday (http://track.sipfoundry.org/browse/XX-6027). Let us know how the testing goes. Thanks Ranga > > Thanks and regards, > Nikolay. > >> -----Original Message----- >> From: M. Ranganathan [mailto:[email protected]] >> Sent: Friday, June 26, 2009 4:08 PM >> To: Nikolay Kondratyev >> Cc: srinivasa rao; [email protected] >> Subject: Re: [sipx-users] no ringback tone on an auto attandant >> transferredcall >> >> On Fri, Jun 26, 2009 at 4:45 AM, Nikolay Kondratyev<[email protected]> wrote: >> >> >> Is your inbound call through sipxbridge ? You will not hear >> >> >> ringing >> >> >> because the REFER is not sent to the calling phone. >> >> >> >> >> >> Enable music on hold for the bridge and you will hear music >> >> >> as the >> >> >> call is being transferred. >> > >> > What will happen then when the destination phone will put the call on >> hold? >> > Will both the phone and sipxbridge try to initiate a MoH session? >> >> >> Yes there is a race condition that is possible. Sipxbridge has an >> algorithm that handles the race condition which essentially allows the >> phone to win if there is a clash. >> >> If the phone initiates a MOH renegotiation (or indeed the called party >> picks up ) in 500 ms. then sipxbridge will not talk to the park >> server to initiate the MOH. >> On the other hand if sipxbridge does not see signaling that indicates >> that the phone has initiated the MOH within that 500 ms, then it will >> initiate the MOH INVITE. >> >> This has been quite tricky to get working correctly so you are not >> advised to turn MOH on the phone AND on sipXbridge ON at the same time >> ( it is not a supported configuration - I fixed a bug just yesterday >> in that connection). >> >> However, it *should* work even if both are enabled simultaneously. If >> you are running an experimental installation, please test the >> configuration and report back any problems. >> >> Thanks >> >> Ranga >> >> >> >> >> -- >> M. Ranganathan > > > _______________________________________________ > sipx-users mailing list [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-users > Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users > sipXecs IP PBX -- http://www.sipfoundry.org/ > > -- M. Ranganathan _______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users sipXecs IP PBX -- http://www.sipfoundry.org/
_______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users sipXecs IP PBX -- http://www.sipfoundry.org/
