On Wed, Feb 25, 2009 at 6:16 AM, Gabor Paller <[email protected]> wrote: > “Once the call is answered, your PSTN gateway shouldn't be involved in the > transfer process.” > > > > Well, I understand it works like this (actually, I checked with my test > system and it does J. Devices: Snom300, Cisco 2651 ISDn router) > > PSTN gateway sends an INVITE to target1. > Target1 answers with OK to the PSTN gateway and establishes the call > Transfer starts. Target1 sends a REFER to the PSTN gateway with target2 as > Refer-To. > The PSTN gateway INVITEs target2. > > > > Since I sent the mail, we made it working with the Cisco. The solution > involved a new dial peer matching the short internal numbers. If the > destination pattern matches the internal numbering plan, the dial peer sends > back the call to SipX. This way the Cisco gateway can handle the internal > SipX users when they are targeted with Refer-To. > > > > Funny how much the Cisco gateway does not care about domains. > > > > I am interested in experiences with SIP trunks. Do I understand correctly > that the Ingate device handles REFER if the trunk is not able to? > > > > Regards, > > Gabor >
Gabor, you may also wish to check out sipxbridge in 3.11. It does the signaling translation from REFER to re-INVITE. It is not production ready yet quite close. Ranga > > > ________________________________ > > From: Tony Graziano [mailto:[email protected]] > Sent: 25 February 2009 11:08 > To: [email protected]; Gabor Paller > Subject: Re: [sipx-users] Best practices for transfer > > > > Once the call is answered, your PSTN gateway shouldn't be involved in the > transfer process. When a call is transferred it is handled by the proxy, and > your UA's (phones, target1/target2) should be able to handle this procedure. > > If ANY call comes in from the PSTN and hits an AA, and then can transfer to > an extension successfully, it means your PSTN gateway handles the refer > properly. Once audio is established with a target, you should be able to > tarnsfer repeatedly. > > If it is a siptrunking device, Ingate for example, you should make sure the > ITSP supports the feature, and your SBC or siptrunk gateway does as well. > > I has "subsequent transfer failures" with an Ingate using a siptrunk, but > solved it here: http://track.sipfoundry.org/browse/XECS-2098 > >>>> "Gabor Paller" <[email protected]> 02/25/09 3:58 AM >>> > Hi, > > I am curious about the best practices for transferring external incoming > calls. > > The scenario is very common: Source (an external number) calls target1 > (an internal number, SipX user). Target1 transfers the call to target2 > (another internal number). This models a common case of a secretary > transferring calls. > > I understand that SIP-wise, the scenario depends on REFER request sent > from target1 device to the device representing the source. As the source > is a PSTN number, the device representing the source is either a gateway > or a SIP trunking equipment which don't know about the target2 internal > number. What is the best way of getting the gateway/trunking equipment > to know about target2? > > Regards, > Gabor > _______________________________________________ > sipx-users mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-users > Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users > > _______________________________________________ > sipx-users mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-users > Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users > -- 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
