Re: [Sipping] RE: Comments on draft-ietf-sip-cc-transfer-05

["Dean Willis" <[e-mail]>]

Following up here -- the Replaces draft is now in the SIP working group, as
draft-ietf-sip-replaces-00.txt.

--
Dean

----- Original Message -----
From: "Rohan Mahy" <[e-mail]>
To: "Robert Sparks" <[e-mail]>
Cc: "'Elwell, John'" <[e-mail]>; <[e-mail]>
Sent: Friday, January 11, 2002 1:51 PM
Subject: [Sipping] RE: Comments on draft-ietf-sip-cc-transfer-05


> Hi,
>
> Re: the Replaces draft, I plan to have an updated revision on Monday.
>
> thanks,
> -rohan
>
> On Thu, 10 Jan 2002, Robert Sparks wrote:
>
> >
> >
> > > -----Original Message-----
> > > From: Elwell, John [mailto:[e-mail]]
> > > Sent: Thursday, January 10, 2002 6:14 AM
> > > To: '[e-mail]'; '[e-mail]'
> > > Subject: Comments on draft-ietf-sip-cc-transfer-05
> > >
> > >
> > > Robert,
> > >
> > > 1. I understand this document is in WG last call. However, there is a
> > > dependency on the Replaces header, which appears to have
> > > expired. In my
> > > opinion the Replaces header is an essential part of transfer,
> > > as a means of
> > > avoiding getting 486 Busy Here in response to an INVITE to an
> > > agent that
> > > does not have call waiting or equivalent. In particular, this
> > > is likely to
> > > arise when the destination of the INVITE is in a legacy network. The
> > > Replaces header would provide a means for the call agent
> > > acting as gateway
> > > to the legacy network to associate the INVITE with the original call,
> > > thereby avoiding establishing a second call through the
> > > legacy network with
> > > a fair chance of encountering a busy destination. Also there could be
> > > charging implications, particularly in the case where the
> > > INVITE is sent
> > > from the transfer target to the transferee - the transfer
> > > target could end
> > > up paying for a call that was originally being paid for by
> > > the transferee.
> > >
> > > Therefore what steps are being taken to formalise the Replaces header?
> >
> > Rohan Mahy is taking on editorship of the draft - I'll let him comment
> > on its status.
> >
> > >
> > > 2. In section 4, item 2, it says "The Transferor and the
> > > Transferee must not
> > > be removed from a session as part of a transfer transaction."
> > > It might be
> > > better to say "....until the conclusion of a transfer
> > > transaction". In fact
> > > the examples all seem to show the clearing down of the
> > > original session on
> > > conclusion of transfer.
> >
> > The point is that the refer transaction does not terminate
> > the dialog between the transferor and the transferee - some other
> > action must be taken to accomplish that (specifically a BYE).
> > See the REFER draft for a better statement of it - I'll be sure
> > the language in the transfer draft is updated to match.
> >
> > >
> > > 3. In 7.2, it should be noted that the transferee call agent
> > > may respond to
> > > the INVITE from the transfer target with 486 Busy Here unless
> > > it has a means
> > > to accept a second call (e.g., call waiting). Similarly in
> > > some of the later
> > > diagrams.
> >
> > Or works with Replaces - I'll make sure that possibility is called
> > out somewhere in the document so that future readers won't have to
> > rediscover it.
> >
> > >
> > > 4. In 7.4, 2nd sentence, there appears to be an erroneous reference to
> > > 4.5.1.
> > Thanks - will fix.
> > >
> > > Regards,
> > >
> > > John
> > >
> > > --------------------------------------------------------------
> > > John Elwell ([e-mail])
> > > Siemens Communications Limited,
> > > Technology Drive, Beeston,
> > > Nottingham NG9 1LA, UK
> > > Tel: [phone]   Fax: [phone]
> > > --------------------------------------------------------------
> > > Internet communications are not secure and therefore Siemens
> > > Communications Limited does not accept legal responsibility
> > > for the contents
> > > of this message. Any views or opinions presented are solely
> > > those of the
> > > author and do not necessarily represent those of Siemens
> > > Communications
> > > Limited unless otherwise specifically stated.
> > >
> > >
> > >
> >
>
>
> _______________________________________________
> Sipping mailing list  http://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [e-mail] for questions on current sip
> Use [e-mail] for new developments of core SIP
>
>


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