Re: [Sipping] SIP call transfer as in draft-ietf-sipping-service-examples-02.txt

Alan Johnston <alan.johnston@wcom.com> Wed, 17 July 2002 01:56 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07770 for <sipping-archive@odin.ietf.org>; Tue, 16 Jul 2002 21:56:50 -0400 (EDT)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA07977 for sipping-archive@odin.ietf.org; Tue, 16 Jul 2002 21:57:48 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA06991; Tue, 16 Jul 2002 21:41:46 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA06960 for <sipping@optimus.ietf.org>; Tue, 16 Jul 2002 21:41:43 -0400 (EDT)
Received: from dgesmtp01.wcom.com (dgesmtp01.wcom.com [199.249.16.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06533 for <sipping@ietf.org>; Tue, 16 Jul 2002 21:40:44 -0400 (EDT)
Received: from dgismtp01.wcomnet.com ([166.38.58.141]) by firewall.wcom.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0GZD0008NE0N51@firewall.wcom.com> for sipping@ietf.org; Wed, 17 Jul 2002 01:41:11 +0000 (GMT)
Received: from dgismtp01.wcomnet.com by dgismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0GZD00A01E0N2J@dgismtp01.wcomnet.com>; Wed, 17 Jul 2002 01:41:11 +0000 (GMT)
Received: from ajohnston.wcom.com ([166.42.32.91]) by dgismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0GZD004J0E0GH0@dgismtp01.wcomnet.com>; Wed, 17 Jul 2002 01:41:11 +0000 (GMT)
Date: Tue, 16 Jul 2002 20:23:35 -0500
From: Alan Johnston <alan.johnston@wcom.com>
Subject: Re: [Sipping] SIP call transfer as in draft-ietf-sipping-service-examples-02.txt
In-reply-to: <8C9A566C643ED6119E8900A0C9DE297A1AE0A5@saturn.aculab.com>
X-Sender: Alan.Johnston@pop.mcit.com
To: Matthew.Gardiner@aculab.com, sipping@ietf.org
Message-id: <5.0.0.25.0.20020716200428.00aaea88@pop.mcit.com>
MIME-version: 1.0
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Content-type: text/plain; charset="us-ascii"; format="flowed"
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
X-BeenThere: sipping@ietf.org

(trimmed to just the sipping list)

Hi Matthew,

Thanks for your comments on the draft.  You have found a typo in the 
document.  All references to Call-ID=12345678900@here.com should be changed 
to 12345600@here.com.  Through cut and paste, the error is also present in 
the following messages in the document:

Section 2.5: F15, F16, F22, F23, F24, F25
Section 2.9: F7, F8, F12, F12, F14, F15, F16
Section 2.10: F20, F21, F22, F23

In answer to your second question, even when the REFER message F15 in flow 
2.5 has the correct Call-ID to make it part of the dialog between A&B, 
there is no specific reference to the held session between A&B.  This is 
not an error but the way that SIP primitives (such as REFER) work.  The 
target of the REFER does not need to understand what type of transfer is 
taking place, but only needs to know how to implement the primitive as 
requested.  The design principles behind this are described in the 
Multiparty Framework document:

    http://www.ietf.org/internet-drafts/draft-ietf-sipping-cc-framework-01.txt

Also, note that anyone implementing transfer should use the SIP Call 
Control - Transfer document as the primary reference.  Note that the next 
version of this document will actually be a sipping wg document.

    http://search.ietf.org/internet-drafts/draft-ietf-sip-cc-transfer-05.txt

Thanks,
Alan Johnston
sip:alan@siptest.wcom.com

At 09:43 AM 7/16/2002 +0100, Matthew.Gardiner@aculab.com wrote:
>Hi All,
>
>A colleague and I are currently trying to design call transfer into a system
>and are therefore consulting draft-ietf-sipping-service-examples-02.txt to
>assist us. We are finding the example of "Attended transfer" a little
>confusing; we can understand messages F1 to F14, but we do not understand
>how message F15 is able to confer to user A any useful information.
>
>1) At this stage user A has a call held (id=12345600@here.com) with user B,
>but the REFER (F15) message uses a new callid (12345678900@here.com).
>2) Furthermore the REFER message itself does not seem to have any fields
>which relate to the held call at user A.
>
>If anyone understands how SIP call transfer is achieved, with regard to the
>"Attended transfer" example in draft-ietf-sipping-service-examples-02.txt,
>could they possibly send me an explanation?
>
>Thanks for your time,
>
>Matthew Gardiner
>Software Engineer
>Aculab
>Tel: +44 (0) 1908 273 911
>Fax: +44 (0) 1908 273 801
>Email: matthew.gardiner@aculab.com>
>Website: http://www.aculab.com
>
>
>
>
>_______________________________________________
>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP Protocol
>Use sip-implementors@cs.columbia.edu for questions on current sip
>Use sipping@ietf.org for new developments on the application of sip


_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP