Thank you, Dale, Your thorough response is very helpful.
Best regards, Emily Smith DMS-10 Software Development Nortel [EMAIL PROTECTED] Office 919.992.7467 > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf > Of [EMAIL PROTECTED] > Sent: Tuesday, June 27, 2006 11:17 AM > To: [email protected] > Subject: Re: [Sip-implementors] SIP blind transfer question > > > From: "Emily Smith" <[EMAIL PROTECTED]> > > You diagram is unusual in that the a BYE is sent from X to Y, > whereas usually in a blind-transfer scenario, that dialog > would be terminated by a BYE from Y to X. But that makes > little difference. > > Of course, this diagram simplifies things because the SIP proxy is > actually transmitting all the messages between the parties > X, Y, and Z, > they are not going directly from end-point to end-point. > Given that, at > the point in the flow where I have added <<******** to the > picture, if > the SIP proxy were to send a re-Invite with dialog 1's > Call_ID to X (not > from Z or Y but directly from the Proxy engine), that is > the question I > am concerned with. > > Since the dialog established by F1 and terminated by the > unlabeled BYE from X to Y, the re-INVITE you mention would > happen while the dialog still exists, and so would be > followed by 200/ACK, under normal circumstances. > > So, to make my question clearer, perhaps, if the SIP proxy > were to send > a re-INVITE with new SDP (port information) to the > Transferer X at this > point, in what way should X respond, and should the X > device, if indeed > he is onhook, as he would probably be in a SIP blind > transfer, rering > the X phone? Or is the answer to this question simply > undefined in the > SIP protocol? > > Whether the phone is on-hook or not (and it may or may not be > physically on-hook, depending on what the user has done) is > irrelevant; the dialog still exists, so the re-INVITE is valid. > > There is never any reason to re-ring a phone when receiving a > re-INVITE. > > I think that you are assuming a situation where the user X > physically hangs up UA X before user Z answers the ring on UA > Z. But that leads to a different call flow, where the BYE > from X to Y happens before the 200 from Z to Y: > > | REFER F3 | | > dialog1 |------------------->| | > | 202 Accepted | | > dialog1 |<-------------------| | > | NOTIFY (100 Trying) F4 | > dialog1 |<-------------------| | > | 200 OK | | > dialog1 |------------------->| | > | | INVITE F5 | > dialog2 | |------------------->| > | | 280 Ringing | > dialog2 | |<-------------------| > | BYE | | > dialog1 |------------------->| | > | 200 OK | | > dialog1 |<-------------------| | > ... time passes here ... > | | > |<<******** > | | 200 OK | > dialog2 | |<-------------------| > | | ACK | > dialog2 | |------------------->| > | NOTIFY (200 OK) F6| | > dialog1 |<-------------------| | > | 200 OK | | > dialog1 |------------------->| | > > Once user X has hung up, UA X sends a BYE and the INVITE > dialog usage of the X-Y dialog ends. (The subscription usage > continues, and that is what contains the NOTIFY F6.) But > once the INVITE dialog usage ends, a re-INVITE is no longer valid. > > Dale > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
