Emily,
If I understand you, what you are calling a "proxy" is not a proxy at
all - it is a B2BUA. If you have a B2BUA in this, then the flows can be
quite a bit different - the dialogs all terminate on the proxy. If that
is the case you are dealing with, then please draw up the call flow with
exactly what is happening and we can make a more meaningful comment.
Paul
Emily Smith wrote:
> 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
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
