Subject: [Sipping] Mid-Call Reqs ID comments

From: "James M. Polk" <[email-masked]>
Date: Fri, 21 Jan 2005 00:13:53 -0600

Authors of this ID

I read your short ID with interest in the angle you would take and have a 
few comments about each requirement you list.

Regarding REQ 1: The solution must enable SIP based IADs or PBXs to provide 
the same POTS interface to the end user:

  - isn't this too loose of a requirement to be clearly addressed. In other 
words, don't you need to list the specific and individual requirements in 
this (or another document) for each to be discussed first?

Regarding REQ 2: The solution shall try to provide a generic framework for 
reporting mid-call events which is extensible:

  - where is this reporting of the event to? To the UA itself? To the 
Softswitch? To the App Server? Is this event something that a SIP element 
other than the UA can Subscribe to the UA to then be Notified of? I agree 
this is likely an event or events that have not been defined yet.

Mid-session incident (or change in state or status) of a session or a SIP 
element is generally signaled to another. If this incident is a change in 
the status of the session itself and needs to be communicated to another 
SIP element that was in the path of the transaction/dialog establishment 
(which is most of what I read into your ID), then either an UPDATE or a 
reINVITE should suffice to that SIP element with the change indication of 
the newly desired parameters for that session.

My guess here is you are in fact treading into the MMUSIC WG and SDP 
parameters of the session to get a hook-flash indication as the state change.

Regarding REQ 3: The solution shall provide the flexibility in service 
mapping and preferences

  - this seems like something that Henry's device configuration document 
could have/does address (already).

Regarding REQ 4:

  - I'm not so sure this WG can specify a physical button be on every SIP 
UA, even if only covering all new UAs being built.

cheers,
James

                                *******************
                 Truth is not to be argued... it is to be presented

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP