Thanks for the replies, Dale. I fear I didn't make myself very clear
with my initial question as I am talking about a re-INVITE to X that
doesn't make much sense in the context/timeframe in which it occurs,
which is why I called it extraneous.
Witness the below call flow from draft-ietf-sipping-cc-transfer-06:
Transferor (X) Transferee (Y) Transfer (Z)
| | Target
| INVITE F1 | |
dialog1 |<-------------------| |
| 200 OK F2 | |
dialog1 |------------------->| |
| ACK | |
dialog1 |<-------------------| |
| INVITE (hold) | |
dialog1 |------------------->| |
| 200 OK | |
dialog1 |<-------------------| |
| ACK | |
dialog1 |------------------->| |
| REFER F3 | |
dialog1 |------------------->| |
| 202 Accepted | |
dialog1 |<-------------------| |
| NOTIFY (100 Trying) F4 |
dialog1 |<-------------------| |
| 200 OK | |
dialog1 |------------------->| |
| | INVITE F5 |<<********
dialog2 | |------------------->|
| | 200 OK |
dialog2 | |<-------------------|
| | ACK |
dialog2 | |------------------->|
| NOTIFY (200 OK) F6| |
dialog1 |<-------------------| |
| 200 OK | |
dialog1 |------------------->| |
| BYE | |
dialog1 |------------------->| |
| 200 OK | |
dialog1 |<-------------------| |
| | BYE |
dialog2 | |<-------------------|
| | 200 OK |
dialog2 | |------------------->|
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.
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?
Thanks again,
Emily
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf
> Of [EMAIL PROTECTED]
> Sent: Monday, June 26, 2006 2:47 PM
> To: [email protected]
> Subject: Re: [Sip-implementors] SIP blind transfer question
>
>
> From: "Emily Smith" <[EMAIL PROTECTED]>
>
> I am new to the list and relatively new to SIP as well. I have a
> question I hope someone can answer here. I have searched the SIP
> RFCs and drafts to no avail.
>
> It's subtle -- the problem is that the question you state has
> no one answer. The deeper problem is that you say "performs
> a blind transfer", but that operation has a number of steps. Usually,
>
> X sends a REFER to Y,
> Y sends 202 to X,
> Y sends an INVITE to Z,
> Z sends 200 to Y,
> Y sends NOTIFY containing the 200 to X,
> Y sends BYE to X,
> X sends 200 (NOTIFY) and 200 (BYE) to Y.
>
> One you focus on the fact that a "blind transfer" is a
> complicated series of actions, you see that "a re-INVITE is
> valid up until the dialog is ended". If the re-INVITE is
> sent from X to Y, it is acceptable to Y until Y sends BYE to
> X. If the re-INVITE is send from Y to X, it is acceptable to
> X until it receives the BYE from Y. If the re-INVITE is
> accepted, it is followed by 200 and ACK. If the re-INVITE is
> rejected (because the dialog has been terminated), it is
> followed by 481 and ACK.
>
> Since party X is on-hook at the time [...]
>
> Only if the transfer has succeeded at this point, and the
> other end has sent a BYE to terminate the dialog, or the user
> at this end has hung up, leaving the UA to finish the
> transfer sequence.
>
> 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
