Vikram/Vipul, Regarding definition of Attendant Transfer, most of the Analog/ Digital PBX allows you to perform the Attendant Transfer activity even when Transfer Target is in ringing state. Analog/ Digital PBX does not (generally) differentiate between Blind and Attendant Call Transfer. If Transferor performs the Transfer Activity before call being answered by Transfer Target, they define it as Blind Transfer whereas if Transfer Target has been answered the call, and then perform the Transfer Activity, they define it as Attendant Transfer.
Now the situation is different in SIP, we have different signaling mechanism to perform the Blind and Attendant Transfer. To make the interface of SIP clients same as analog/digital terminals (PBX), SIP based clients must support performing Attendant Transfer activity when Transfer Target is in Ringing state (and even it is possible if Transferor has been received 180 Ringing with TO Tag). But the situation gets worse when Transfer Target receives the INVITE (replaces) and dialog information matches with the early dialog which is not initiated by Transfer Target. As per RFC, such INVITE should not be accepted. And all this leads to Interoperability. I have checked it in Linksys SPA3102 and found that when Linksys (Transfer Target) receives the INVITE (replaces) and dialog information receives in INVITE (replaces) matches with any early dialog which is not initiated by Transfer Target (Linksys), then even Linksys terminates the early dialog (between Tranfer Target viz Linksys and Transferor) by sending 487 Request Terminated and then sends 180 Ringing in response to Transfer Target. Now Linksys is simply not following the RFC but if we want to make our SIP clients interoperable with Linksys (and probably other products which are following this), we shall also have to ignore such statements from RFC. I would appreciate you valuable feedbacks if you have been came across such issues. Best Regards, Vivek Batra -----Original Message----- From: Vikram Chhibber [mailto:vikram.chhib...@gmail.com] Sent: Thursday, May 07, 2009 3:25 AM To: Vivek Batra Cc: sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] Early dialog can be replaced if Transfer Target is the reciepient of dialog (early) during Attendant Call Transfer On Tue, May 5, 2009 at 9:41 PM, Vivek Batra <vivek.ba...@matrixtelesol.com> wrote: > Hi Folks, > > I have one straight question may be I am not able to read between the words. > > > As per RFC 3891 Section 3: > > > > If the Replaces header field matches an early dialog that was not > initiated by this UA, it returns a 481 (Call/Transaction Does Not > Exist) response to the new INVITE, and leaves the matched dialog > unchanged. > > If we correlate the above RFC statement with the Attendant Call Transfer, > does it mean that if Transfer Target receives the INVITE (replaces) header > and it matches with the early dialog which is not initiated by the transfer > target, transfer target should not replace the early dialog and return 481 > Call Leg Doesn't Exist. > > Please consider the following: > > Transferor Transferee > Transfer Target > > ------------One way Speech---------------> (1) > > ---------------------------------------------INVITE------------------------- > -----------------------> (2) > > <--------------------------------------------100 > Trying------------------------------------------- (3) > > <--------------------------------------------180 Ringing (with TO Tag) > --------------------- (4) > > ------------REFER (Replaces) ------------> (5) > > <--------------202 Accepted------------------ (6) > > ---------------INVITE > (Replaces) -----------> (7) > > In the above case of Attendant Call Transfer, when Transfer Target receives > the INVITE (Replaces) in message 7 and dialog information receives in > replaces header of INVITE matches with early dialog (between Transfer Target > and Transferor), can Transfer Target replaces the early dialog by sending > any suitable 4XX response to Transferor and send 180 Ringing to Transferee. > No. From the RFC 3891, it is clear that you can only replace early dialog which is initiated by the UA. In your scenario, how can you say it is attended-transfer when the transferor and transfer-target never had a conversation? > If Yes, how we correlate it with the RFC Section 3 which states to not > replace the early dialog if not initiated by the Transfer Target. Transfer > Target in this case is the recipient of the dialog (early). > > Best Regards, > Vivek Batra > > > > > > > > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > Email Scanned for Virus & Dangerous Content by : www.CleanMailGateway.com _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
