1.      Excellent job of capturing the requirements!

2.      Section 2

1.      Domain model (page 2)– although there are many SipEndPoints out there only the one communicating with the SIP connector are relevant here – therefore, the relationship should be 0..* endpoints communicate with 1 SipConnector.

[Yes, it missed that change. Thanks]

2.      Section 2.1.2 – the use case should also include Registration.

[We discussed about it. Was it understood that Registration is part of the SipConnector?]

3.      ModifyCall Use Case – is the intention to pass all re-INVITEs through CSE?

[No, re-Invite’s coming from endpoint are forwarded. However, the UserAgentCall maintains a state diagram to reflect the new state of the call. CSE will be able to use re-INVITEs through compound functions. Any re-INVITE from CSE during a re_INVITE initiated from endpoint must be handled properly!]

4.      REFER support is not required for 3.0.0, you may want to consider using the same use case to describer the new release and reconnect.

[REFER is mentioned as not required in R3.0.0 For Release and Reconnect see the comments made by Alex.]

5.      Section 2.3.3 & 3.2.2.4 – transfer call use case should clarify that the call leg state may be in connected or proceeding

[It is understood that there are many variants of the same use case. SICC specification defines all possible states of the call leg involved in CSE invoked operations. The Detail Design will clarify that.]

 

6.      Section 2.3.3 – abort call use case – the use of term FCP and network call is interchangeably used. FCP is a logical construct; whereas the network call is a tangible software structure and they don’t necessarily map one-to-one. It would be consistent to use network call in the design documents until there is an agreed upon definition of FCP.

[I missed that change. Thanks.]

7.      Section 3.1 diagram – SipServerDialog is handled either by a B2BDlg or UserAgentCall, but not by both, or did I get this wrong?

[The diagram shows the capability of SipServerDialog to communicate with both.  The 3.3.3.2, 3.1.1.3 explains on how it communicates. SipServerDialog acts as dispatcher of events to an event owner. The event owner is defined per incoming call basis. The ownership once established is immutable]

 

8.      Section 3.1 diagram – how many UserAgentCall can a NetworkCall manage?

[It can handle 0..*.UA calls The Detail Design will define that with accuracy. It might be 2 or 3 ]

9.      Section 3.2.2.3 – just want to clarify that makecall is not a requirement for 3.0.0, but its good that you analyzed the design

10.  Section 3.2.2.5 – again Reconnect Orig is not part of 3.0.0 requirement.

[Call Park it is using it. Is Call Park part of R3.0.0?]

11.  Section 3.2.3.1 figure 8 – during join the state machine starts from DEST_OFFERING, why not ORIG_OFFERING? Do DEST/ORIG states refer to original call direction?

[As mentioned before, most of the scenarios will have variants(based on the initial state of NC and based on the call leg that receives  the join operation) to accommodate the requirements of SICC specification. I will add a note for that]

12.  Connected-Outgoing Figure 9 – Despite the validity of the call flow, INVITE with no SDP is not very friendly with a lot of implementations. We should avoid.

[ Radvision is using it! See page 14 Back to Back module- Third Party Call Control Section- Connect scenario]

13.  Incoming-Incoming Figure 11 – what is the purpose of re-INVITE? Is there a limitation that we cannot handle the flow described in the requirements (Block A in Figure 7)?

[The purpose is to let the endpoints to negotiate the media. The main idea is: answer to an offer with the intersection of capabilities not with another offer. It avoids the variants presented in BLOCK B and BLOC C from your document.]

14.  Outgoing-Outgoing Figure 13 and Connected-Connected Figure 15 – same comment; INVITE with no SDP should be avoided.

[ Radvision is using it! See page 14 Back to Back module- Third Party Call Control Section- Connect scenario]

15.  Based on updated requirements from Phil park and retrieve, dynamic disposition, change device services need to be added – you should wait for these changes until the requirements are committed. In addition there will be a join case during the offering state, i.e. offering-incoming.

[All incoming calls are considered in OFFERING state. Incoming-Incoming means two incoming calls in OFFERING state]

3.      Not in the document:

1.      Summarizing the call states (may be using the network call states) during which the SIP-C will/will not communicate with the CSE to proceed to the next call state will be helpful to identify which response/provisional responses are percolated to service layer

[State Diagrams are usually part of the Detail Design. The Detail Design will provide a more detailed description.]