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

[Rohan Mahy <[e-mail]>]

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