[Sip] RE: Question regarding draft-ietf-sip-cc-transfer-05

["Chiou, Mark" <[e-mail]>]

Hi Robert,

Thanks for clarification. I agree the REFER should not tear down the session between the transferor and the transferee. But the Call Transfer application SHOULD tear down the session between the transferor and the transferee for successful case.

Thanks again,

Mark

-----Original Message-----
From: Robert Sparks [mailto:[e-mail]]
Sent: Thursday, May 09, 2002 8:58 AM
To: Chiou, Mark
Cc: [e-mail]; Sridhar Kuppanna
Subject: Re: Question regarding draft-ietf-sip-cc-transfer-05


On Wed, 2002-05-08 at 12:04, Chiou, Mark wrote:
> Hi Robert,
> 
> This is a question regarding Call transfer successful scenario.
> 
> In the Call transfer draft, section 4, it mentions the connection between transferor and the transferee MUST be maintained in case of un-successful cases. (i.e. No answer, busy, & etc.), such that the transferor has the ability to retreat the call back.
> 
> In section 5, it mentions "Note that a successful REFER transaction does not terminate the session between the Transferor and the Transferee. If those parties wish to terminate their session, they must do so with a subsequent BYE request." 
> 
> The questions are :
> 
> 1) neither party (transferor or the transferee) physically hits an "end" key to release the call, then the session will not be released. Is it what we want? It wastes resources.

The draft does not place a requirement for there to be a physical action
on the part of either party in order for the BYE to be sent. Is it only
the sentence above that gave you that impression or was there something
else?

It is very important that the REFER itself not tear down a dialog - that
has to happen with a BYE. The BYE can (and usually will) be sent as part
of the transfer application once the REFER association compeletes (the
REFERor sees a NOTIFY with a sufficient final response, or decides it
doesn't care anymore).

> 
> 2) each party (transferor or transferee) can send a re-INVITE request message to get the conversation back. It is different behavior than the PSTN network. (In the existing call transfer, especially PSTN network, the connection between transferor and the transferee is released.)
And this is a very good thing. If our goal is only to reproduce the
PSTN, we're wasting our time - we've already got a PSTN that does that.
We must do more.
> 
> 3) If the transferee sends a re-INVITE request message to the transferor, does it become a 3-way call? 
Not without extra mechanism.

For the scenario you are thinking about, the transferee would end up in
two distinct dialogs with thier own sessions (and would have to use
whatever interface motif it has available for multiple calls).

When the conferencing work ripens a little more, we'll see that the
REFER could be to a conference that the transferor and transferee were
already in. The conferencing mechanisms would have to recognize the
reinvite reactivated a leg in the same conference.
> 
> Here is my penny thought, Can we change the note in section 5 as" the User Agent application for the transferor SHALL automatically send a subsequent BYE request message to release the session between the transferor and the transferee"? For transferee, we might say " the User Agent application for the transferee MAY automatically send a subsequent BYE request message to release the session between the transferor and the transferee."
No - it needs to be MAY for both.
> 
> By the way, I do not have problem for a PSTN user as the transferor because the PSTN network (i.e. switch) will ensure the disconnect, which is mapped to a BYE request message for the IP network. The same behavior is used for MGCP user too. The only problem is in SIP environment (i.e. Transferor, transferee and transfer Target are SIP phones), which requires an extra step to release the session.
> 
> Regards,
> 
> Mark Chiou



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip