Subject: [SIP] Attended Transfer Call Flow:draft-ietf-sip-service-examples-00.txt

From: Henry Chen <[email-masked]>
Date: Fri, 01 Dec 2000 12:21:44 -0600

Hi Alan:

    In the call flow of Attended Transfer in
draft-ietf-sip-service-examples-00.txt,
    INVITE (F9) and INVITE (F16) have same Call-ID header and same To
header, but the From headers are different.
    I need to confirm that:
        - Is INVITE (F16) a legal Re-Invite and Shall User C accept it?
        - If it is legal, what should User C do?
            Ring (as a new call) or just establishes a new media stream
and change the display of  calling party (as a same call)?

    Thanks,

    Henry

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Billy Biggs <[email-masked]>
Date: Fri, 1 Dec 2000 12:49:35 -0600

Henry Chen ([email-masked]):

> draft-ietf-sip-service-examples-00.txt, INVITE (F9) and INVITE (F16)
> have same Call-ID header and same To header, but the From headers are
> different.
>
> I need to confirm that:
>      Ring (as a new call) or just establishes a new media stream and
>      change the display of  calling party (as a same call)?

  This call flow has two glaring errors:

  1. The UA made two calls with the same Call-ID, but did not add a From
     tag.

  2. The UA which received the REFER made a new call using the same
     Call-ID as the call leg the REFER was received on.  Ouch.

  It is now generally accepted that the call-id should not be used to
infer that an incoming call should replace or have any association with
an ongoing call.  Doing so leads to problems in some forking situations,
and is a general overloading of the meaning.

  For a cleaner method of signalling attended transfer where you don't
want the target's phone to ring, please see (and comment on) our
replaces draft (draft-biggs-sip-replaces-00.txt):

  http://www.sip-happens.com/replaces/

-- 
Billy Biggs, 3Com               Email: [email-masked]
http://www.div8.net/billy/      Phone: [email-masked]

---

From: Alan Johnston <[email-masked]>
Date: Mon, 04 Dec 2000 10:18:48 -0600

See my comments below.

Alan Johnston

> > have same Call-ID header and same To header, but the From headers are

I have corrected the error in reusing the Call-ID.

> >      change the display of  calling party (as a same call)?

This flow shows that B and C exchange media ("talk") prior to the REFER
being sent by B to A.  The INVITE (F16) is answered immediately since C is
expecting the call.  (Since the corrected flow has a different Call-ID, this
is not a reINVITE but a new INVITE.) The two media streams (B to C and A to
C) are separate.

>      Call-ID as the call leg the REFER was received on.  Ouch.

The reuse of the Call-ID has been fixed - I'll scan the rest of the flows
for this type of error.

---

From: Henry Chen <[email-masked]>
Date: Mon, 04 Dec 2000 10:44:32 -0600

> is not a reINVITE but a new INVITE.) The two media streams (B to C and A to

If INVITE (F16) is a new call, C will get ring again during the transfer.
I think that the same Call-ID in F16 is legal (a new call leg) and
provides a way for C to establish a media stream
for a new call leg (A-C) in the same call without additional ring.
The media stream from the call leg B-C will be dropped by the BYE (F22).
So the same Call-ID in F16 is better.

Thanks,

Henry

---

From: Billy Biggs <[email-masked]>
Date: Mon, 4 Dec 2000 11:03:51 -0600

> If INVITE (F16) is a new call, C will get ring again during the

  Yes.  Please see our replaces draft for one solution to this problem.
Overloading the call-id is not a good idea.

> provides a way for C to establish a media stream for a new call leg
> (A-C) in the same call without additional ring.  The media stream from
> the call leg B-C will be dropped by the BYE (F22).  So the same
> Call-ID in F16 is better.

  I mentioned the problems with this before:

>>>   It is now generally accepted that the call-id should not be used
>>> to infer that an incoming call should replace or have any
>>> association with an ongoing call.  Doing so leads to problems in
>>> some forking situations, and is a general overloading of the
>>> meaning.
>>>
>>>   For a cleaner method of signalling attended transfer where you
>>> don't want the target's phone to ring, please see (and comment on)
>>> our replaces draft (draft-biggs-sip-replaces-00.txt):
>>>

---

From: Henry Chen <[email-masked]>
Date: Mon, 04 Dec 2000 11:58:04 -0600

> Overloading the call-id is not a good idea.

Is this a  perfect case for same call with different call legs and is
acceptable?

> >>> some forking situations, and is a general overloading of the

Could you give a call scenario for the forking situation which leads to
problems?

Thanks,

Henry

---

From: Billy Biggs <[email-masked]>
Date: Mon, 4 Dec 2000 14:44:37 -0600

Henry Chen ([email-masked]):

>>   Yes.  Please see our replaces draft for one solution to this
>> problem.  Overloading the call-id is not a good idea.
> 

  Huh?

>> infer that an incoming call should replace or have any association
>> with an ongoing call.  Doing so leads to problems in some forking
>> situations, and is a general overloading of the meaning.
> 
> Could you give a call scenario for the forking situation which leads
> to problems?

  Sure.

  1. A single INVITE may complete at multiple remote parties (multiple
     200 OK responses).  The UA may choose to keep around all of these
     calls.  When a new call with the same call-id comes in, which of
     these multiple calls is it associated with?

  2. A UA receives a call and answers it, then later receives a
     retransmission of the original INVITE from a different proxy
     (request merging).  I want to protect this UA from mistaking this
     as a replacement call for the answered one.

  3. A broken UA may make multiple calls within the same Call-ID.  I
     want to protect against mis-associating these calls.

  4. Most (all) commercially available SIP UAs don't give larger scope
     to the call-id.  As well, there is no way to tell if a UA will give
     it any significance.  Cleaner to seperate replacement or
     association as new headers.

---

From: Henry Chen <[email-masked]>
Date: Mon, 04 Dec 2000 17:31:41 -0600

Please check following comments and questions.

    Thanks,

Henry

>      these multiple calls is it associated with?

Same situation for the replacement also. Some one need to decide which call
is to be replaced.

>      as a replacement call for the answered one.

This can be done by comparing CSeq and Call-leg.

>      want to protect against mis-associating these calls.

This is a very rare case and may also be detected by comparing CSeq. Right?

>      association as new headers.

What is the acceptance of "Replacement"?