On Tue, Nov 4, 2008 at 3:10 PM, Scott Lawrence <[EMAIL PROTECTED]> wrote: > > 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?
I can experiment with this case. I am not sure about it at the moment. > > We probably should not use REFER to an ITSP unless they also support > Refer with Replaces. OK > >> 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? I am thinking about PBX to PBX connection via an ITSP In that case, I suppose, if I strip the Allow:REFER from the outbound INVITE from sipxbridge, the ITSP cannot send an inbound REFER legally. > >> 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. > > > -- M. Ranganathan _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
