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

[Robert Sparks <[e-mail]>]

> -----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