>>>>> Luca Scheuring <lscheuring.biz@xxxxxxxxx> wrote: > could emit a BYE to the Transferee as soon as the REFER transaction > completes. This flow is sometimes known as "unattended transfer" or > "blind transfer". > [...] > The last sentence implies that if the transferor _wants_ to > participate in the remainder of the REFER process (and therefore waits > with sending the BYE until another NOTIFY with "200 OK" has been > received) this is called attended transfer. But both rfc5359 and > draft-ietf-sipping-cc-transfer-11 define "attended transfer" as a > transfer where the transferor establishes a call with the transfer > target to alert it to the impending transfer. Can somebody clarify > this issue? Paragraph 7.6 says of the same draft says: " In any of the consultation hold flows above, the Transferor may decide to terminate its attempt to contact the Transfer target before that session is established. Most frequently, that will be the end of the scenario, but in some circumstances, the transferor may wish to proceed with the transfer action. For example, the Transferor may wish to complete the transfer knowing that the transferee will end up eventually talking to the transfer-target's voice-mail service. Some PBX systems support this feature, sometimes called "semi-attended transfer", that is effectively a hybrid between a fully attended transfer and an unattended transfer." so we have three transfer kinds: 1) attended - when transferor makes call to transfer target (this implies their real consultation as "dear Bob, could you please deal with this client? I have no enough competency...") and then sends REFER-with-Replaces to recombine legs; 2) semi-attended - sent as REFER-without-Replaces but keeping supervision on call with intention to restore if failed; 3) blind - sent as REFER-without-Replaces with immediate BYE. > This question came up when analyzing problems that occur if > Alice/transferor is an agent that remains in the transfer process > until NOTIFY with "200 OK" is received (in order to offer the > possibility to un-hold call to Bob/transferee again in case transfer > target doesn't reply / declines the call) while Bob/transferee is an > agent who expects a call flow as described in rfc5359 section 2.4. > Observed problem: Alice is on a call with Bob and then wants to > attempt an unattended/blind transfer to Carol. Carol's phone is > ringing, but no answer yet. Alice thinks Carol won't answer and > therefore un-holds the call to Bob in order to recover. Alice and Bob > are in communication again, but Bob is still calling Carol. If Carol > finally answers, Bob doesn't know how to handle this session. Call > from Bob to Carol ends up as a "phantom call" at Bob that cannot be > terminated by Bob. This seems incorrect - in this scenario Alice (transferor) shall _not_ have possibility to restore the call to Bob until notification from Bob. "Iron" PBX (I've mostly used Nortel Norstar & Meridian) can implement this scenario that Alice hooks on, but if Carol doesn't answer, Alice gets ring (of special distinctive type) and her call to Bob is restored when she hooks off. -- Valentin Nechayev PortaOne Inc., Software Engineer mailto:netch@xxxxxxxxxxxx _______________________________________________ Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip Use sip@xxxxxxxx for new developments of core SIP
