Subject: [SIP] sip-cc-transfer-04 UA behavior question

From: "Cullen Jennings" <[email-masked]>
Date: Mon, 12 Mar 2001 09:15:27 -0800

I'm not sure about how the UA is supposed to behave to certain message
sequences. In the example in section 4.5.1 consider just the message flow
that the transfer target UA gets. First it gets the INVITE, the user answers
the phone and we do the /200 OK/ACK then the far end initiates the BYE/200
OK. This is a perfectly normal call flow so far, this UA has no idea a
transfer is taking place. It is still off hook. Now the next INVITE arrives,
it has a different Call-ID than the previous call, this single line phone is
off hook, so why does the UA connect the call and return a 200 instead of
just returning a 486?

There is a similar issue in section 4.5.2 - The transferred is on hold and
the transfer target sends it and INVITE - again it seems the UA should say
it is busy instead of answering the call.

If the UA decided by matching information in the Referred-By header, it seam
that it may not match if the original call was forwarded to a different
party. If the Referred-By header also carried the original calls Call-ID
information it would solve this problem or if the Replace header was used.
This would also provide a very low level security - at least the party
sending the INVITE that contained the Referred-By knows the Call-ID of the
current call.

Thanks, Cullen

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.

---

From: Billy Biggs <[email-masked]>
Date: Mon, 12 Mar 2001 13:01:08 -0500

Cullen Jennings ([email-masked]):

> sequences. In the example in section 4.5.1 consider just the message
> flow that the transfer target UA gets. First it gets the INVITE, the
> user answers the phone and we do the /200 OK/ACK then the far end
> initiates the BYE/200 OK. This is a perfectly normal call flow so far,
> this UA has no idea a transfer is taking place. It is still off hook.
> Now the next INVITE arrives, it has a different Call-ID than the
> previous call, this single line phone is off hook, so why does the UA
> connect the call and return a 200 instead of just returning a 486?

  In the example 4.5.1, the two calls to the target are completely
independent.  It is not "attended transfer", but instead the phone rings
when the transfered call arrives.

> There is a similar issue in section 4.5.2 - The transferred is on hold
> and the transfer target sends it and INVITE - again it seems the UA
> should say it is busy instead of answering the call.

  In section 4.5.2, the transferee is a multi-line phone, which can
handle two active calls at once.  Again, it is not attended transfer,
the two calls are independent.

> If the UA decided by matching information in the Referred-By header,
> it seam that it may not match if the original call was forwarded to a
> different party. If the Referred-By header also carried the original
> calls Call-ID information it would solve this problem or if the
> Replace header was used.  This would also provide a very low level
> security - at least the party sending the INVITE that contained the
> Referred-By knows the Call-ID of the current call.

  REFER without Replaces (or similar) is insufficient for attended
transfer.

  In the Replaces draft, we give examples of how to perform attended
transfer which is sufficient even if the target is a single line phone.

-- 
Billy Biggs                     [email-masked]
http://www.billybiggs.com/      [email-masked]