Hi Martin, See below.
Regards Andy > > Hi, > > > > The following comments are based on feedback I obtained from > > some developers. Sorry that they are sent last minute. > > > > 1. Section 4.2 "Call-Completion procedures" (1st Para.). The > > text indicates that call completion procedures are not > > required if the callee's UAs return a success response. This > > is incorrect and in conflict with the definition of "Failed > > Call" in the definitions. The requirement for call completion > > is independent of the success/failure of the SIP INVITE request. > > > > > > 2. Section 4.2. (2nd para.) Again it is implied that the call > > completion procedures seems tied to the state of the > > preceding INVITE initiated dialog with the statement > > "Eventually, the INVITE fails, or the resulting dialog(s) are > > terminated". However it is not the case that the call > > completion procedures are independent of the state any > > proceeding dialog. For example it should be possible to > > initiate call completion even before the original INVITE > > dialog is terminated. > > I've tried to combine the 2 paragrapgs: > > "The caller's UA sends an INVITE to a request URI. One or > more forks of this request reach one or more of the callee's > UAs. However there might be the situation that the calling > user considers the result of the call insufficient to satisfy > his needs, e.g. the INVITE fails and the resulting dialog(s) > are terminated, or the INVITE might succeed at some other UA." > [AndyHutton] - I think it needs to be made clear that the SUBSCRIBE for call completion can be initiated whatever the state of the original INVITE dialog. For example a 180 or 200OK response could be received to the original INVITE request and the user decides to invoke call completion before terminating the INVITE dialog. Maybe a statement to this effect could be made in section 4.2 and/or section 6.2. _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
