On Tue, 2008-11-04 at 10:51 -0500, M. Ranganathan wrote: > Hello, > > I would like to discuss the implications of forwarding REFER to the > ITSP. There are some ITSPs that support REFER ( notably bt.com). If we > exploited this capability, that could result in a better user > experience. For example, this would have the effect of the caller > hearing Ringing on blind transfers assuming that the inbound INVITE > has an Allow: REFER. Note that in general the ITSP may not > Allow:REFER as it may well be dealing with an endpoint that does not > handle REFER ( such as a PSTN phone ) so the user may not hear RINGING > on blind transfer anyway. > > Is XECS-1849 worthwhile? If you are calling pbx to pbx, I can see XECS > 1849 being worthwhile.
If you look at INVITES from this and other ITSPs (setting aside the pbx-pbx case for a moment), is the presence or absence of 'Supported: refer' a reliable indication of whether or not it is supported? We probably should not use REFER to an ITSP unless they also support Refer with Replaces. > Questions: > > Are we better off simulating RINGING using our park server for a > uniform user experience or should we forward REFER to the iTSP for > In-DIALOG refers received from the PBX? I don't think we should simulate ringing - there are many worms in that can... > If so, we also need to be able > to handle inbound REFER from the ITSP (which adds more complexity to > the code). Why would we need to handle inbound REFER? Have you seen one? > Is the current solution of turning off MOH on the phone and turning it > on for sipxbridge so that MOH plays till pickup for blind transfers > adequate for this release? Yes. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
