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

["Elwell, John" <[e-mail]>]

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?

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.

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.

4. In 7.4, 2nd sentence, there appears to be an erroneous reference to
4.5.1.

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