| Item# | Type of change. If REJECTED it is not in the specification | Change | Requirement (if any) | Description (if needed) | Change |
|---|
| 1348 | REJECTED | The initial texts of the JSR could be better written | - | - | None |
| 1355 | Error | Spec references for REFER are useless | - | - | Clarify references to RFC. Only textual, no API change. |
| 1357 | REJECTED | SIP INFO is not supported | The JSR 281 shall support the SIP INFO method | To enable for new services in IMS, this method need support in the API. | None |
| 1649 | New req | Media and codecs: adding MMTel specific properties | The JSR 281 shall support 3GPP 26.114 | - | Add new streaming media profile "mmtel" (new value for the 'mprof' registry property). More attributes reserved in Session- and MediaDescriptor. setBandwidthInfo gets reserved, and throws exception if modified in mmtel and vs profiles. |
| 1771 | Clarification | Permission class definition is required for MSA and MIDP3 | - | Add permission class definitions of MIDP3 to comply with MSA2 | Updated the table security chapter in overview.html to map MIDP2 permission strings to MIDP3 permission classes. |
| 1772 | Clarification | Media types (MSA and MIDP3 alignment) | - | Clarify relation of media types of MSA2 to JSR 281 | Only textual, no API change. Media types are specified in relation to media profiles descriptions. |
| 1774 | Clarification | API may implement change media with UPDATE or re-INVITE. Re-INVITE is preferred when adding media. | - | A session can be updated using either a re-INVITE or UPDATE. | Javadoc updated for SessionUpdateReceived: This method is called when a media has been added to the session, and the application may accept or reject it. Impl guidelines has a section on session updates, which type of update generates which call back and how to handle a mix of update types. |
| 1938 | New req | Not possible for an application to set final response codes. | The JSR 281 shall allow an application to set SIP response codes where applicable. | - | For methods that reject an incoming ServiceMethod, it will be possible to supply a response code explaining the reason for the rejection. Session.reject(int) - New method. Session.rejectWithDiversion(String) - New method. Session - Added statusCode constants |
| 1939 | REJECTED | Support to set device-level q-value | The JSR shall support setting device Q-value according to RFC3841 Caller Preferences Framework. | This makes it possible for a user to indicate the preference of a device according to RFC 3841 | None |
| 1940 | Clarification | MSRP to follow model of RFC 4145 for NAT traversal. | The implementation of MSRP shall support connection model of RFC 4145 | Clarify requirements on the TCP connection model used in MSRP | No API change expected, but impl guidelines updated in a chapter on NAT traversal. |
| 1942 | Clarification | TCP connection setup using c-line IP address and m-line port | The implementation of MSRP shall use the c-line address and m-line port, rather than the a=path line. | Propose alternative way of using the c-line IP address and m-line port to enable OMA IM. | No API change expected, but impl guidelines updated in a chapter on NAT traversal. |
| 2012 | Error | createReference and createCapability in Session need to throw ImsException if they cannot be created. | - | - | Add missing exceptions to API. Updated Session.java to throw ImsException. |
| 2023 | New req | Support display name for user id arguments throughout the spec | The JSR 281 shall support display names for SIP URIs where applicable | Allow display names to be used where applicable. | API changes: The From and To arguments of service methods accept display names together with the URIs. Connector.open allows display name in userId= parameter. ServiceMethod.getRemoteUserId returns an array of strings of asserted identities known about the remote. Added example about display name in CoreService.java Clarified impl guidelines that Connector.open userId= parameter maps to P-Preferred-Identity. Display name is supported for TEL URIs as well. Added MO anonymity based on the domain name anonymous.invalid |
| 2026 | REJECTED | Home- or geolocal numbers in phone-context | The JSR shall interprete local number tel URIs in geo-local and home-local contexts according to 3GPP TS 23.228, 3GPP TS 24.229 and RFC 3966. | - | None |
| 2027 | REJECTED | default application | The JSR shall allow an IMS application with no capabilities in the registry. | This is needed to handle legacy applications that are not within the caller preferences framework. | None |
| 2040 | REJECTED | IllegalArgumentException is thrown if file could not be found. | - | FramedMedia.sendFile and receiveFile may need to be clarified about which exception is thrown if the file cannot be found. | None |
| 2041 | Error | Syntax of CoreService IARI, ICSI and FT fields, and make sure to specify which delimiters are allowed to separate the identifiers within each of these fields. | - | The Registry is used to encode feature tags, ICSI and IARI. | No API changes. Clarified ICSI, IARI and Feature tags are whitespace separated in registry. javax.microedition.ims: The JSR 281 IMS Application Registry, Static Installation CoreService, Dynamic Installation CoreService, configuration.setRegistry example. |
| 2065 | Error | Define exactly when when the transferProgress shall be called. | - | TransferProgress callback is repeatedly called to track transfer of large content in FramedMedia. | New section in impl guidelines for FramedMedia describing when to call the listener. The impl guidelines sets no parameter for how often it should be called, only after each chunk has been sent. MSRP sets each chunk to be 2k, but it may be impl dependent. No API change. |
| 2091 | Error | Inadequate error message from creating ServiceMethods. | - | Improve error messages from the service methods. | New interface Reason.java supported in ServiceClosed and CoreServiceException only. No change for service methods, since we can pick out reasons using the message interface. Reason.java introduced. |
| 2105 | Clarification | Connector.open registers additional public user identities | - | It is possible to do multiple connector.open with different userId parameters. | Impl guidelines: If the device supports explicit registration of additional public user identities, then the device attempts to register them. Otherwise not. |
| 2107 | Error | missing method Configuration.hasRegistry | - | The method is needed in applications. | Method added. |
| 2108 | REJECTED | Allow AppId argument to setRegistry (etc) to be a connector string | - | Makes development of application easier. | None |
| 2140 | New req | Media and codecs: enhance interoperability. | The JSR 281 shall support the media handling of 3GPP TS 26.235 and 3GPP TS 26.114 | The media interoperability requirements were too weak in the final release. | Text on Streaming Media profiles introduced together with requirements. Registry updated with mprof attribute that encodes the streaming media profile name. Impl guidelines: When the IMS engine creates the codec offer on MO side for streaming media, it considers what is available in the media profile and allows only them.
|
| 2141 | New req | The API has no HOLD function, this could mean that the codec-resource is not released when SDP direction is change: SendRecv->sendOnly. On a platform with limited resources it may prevent a new outgoing call during Hold e.g. going from 2-party to 3-party. | The JSR 281 shall enable an application to put its media in a HOLD state. | Used to pause sending content over a media component | Clarified how direction influences Media and Player states together with a description in StreamMedia. Exceptions for when getting Players are modified, especially that you can get them regardless of media directions. |
| 2144 | New req | No application dependant response is possible to INVITE i.e. no listener triggered by receiving an INVITE | The JSR 281 shall allow the terminating side to make an application-specific answer to an offer from the originating side according to RFC3264. | Important addition to enable new services and advanced applications. | This is Early session framework effectively enabling RFC3264 offer/answer model for applications in the JSR. New interfaces EarlySession, EarlySessionListener introduced to cover the space between INVITE and 200 Ok on MT side. A new media state introduced for media components on MT side (state-offer). Also new call back interface SessionEarlyListener for Session to cover the same space for reINVITE for the MT side. These things were done separately from Session to avoid a complete redesign of the session and media handling in the JSR. |
| 2145 | New req | The headers in a SIP response message cannot be updated (only headers in a SIP request can be updated). | The JSR 281 shall support read and write to SIP headers in SIP response messages | - | Added method getNextResponse in ServiceMethod interface. Added text and table in Impl Guidelines for ServiceMethod |
| 2146 | New req | It is not possible to populate the Replaces parameter in Refer-To header in REFER (used when going from 2-party to 3-party). This includes both inserting and reading the replaces header, and also its inclusion in the header portion of a SIP URI header. | JSR 281 shall support processing of the replaces parameter of the refer-to header in REFER requests according to RFC3515. | This eliminates the need to have duplicate media streams while transfering a call to a server. | CoreService.createReference() updated so referMethod can be null. New methods Reference.setReplaces(), Reference.getReplaces(). Changes to: Reference.refer() now takes boolean argument, ReferenceListener.referenceDelivered() has state can be Referring or Terminated. Reference: Updated picture of statemachine to match above. |
| 2147 | New req | Early media is not supported, the media player is not realized until the media session is established (200 OK to initial INVITE). | The JSR 281 shall support playing out media contents available before called user accepts session | Support the concept of "Early media" | Make media players of StreamMedia go into REALIZED state as soon as they can, rather than being dependent on session establishment. Solution requires adding new boolean methods exists(), canRead(), canWrite() to Media interface where the app will know if it is allowed to operate on the media flow, and a new interface MediaListener that reports if the allow change. Impl guideline describes how the IMS engine shall compute boolean values. Javadoc updated for all media types, though no more methods have been added there. Rationale is in Media javadoc, and exceptions for all methods that write or read to media objects are revised. Despite the additions, the interfaces are simpler to use. |
| 2148 | REJECTED | No listener triggered on originating side by 181 (Call is being forwarded). | The JSR 281 shall notify the MO application of received progress reports before session is established. | - | None |
| 2151 | New req | Video adaption with SIP UPDATE. | The JSR 281 shall apply UPDATE when minor media change is required that does not need user intervention. | - | No API change needed. Impl guideline describes that this type of update should be done separately from application-initiated updates. |
| 2152 | REJECTED | The API supports SIP and TEL URIs, but it is not referencing the latest (any) TEL URI RFC. | - | - | None |
| 2341 | New req | Suppress implicit subscription to refer event package | The JSR 281 shall enable an application to choose if implicit subscription for REFER should be done (RFC4488) | - | Add boolean arg to CoreService.createReference that flags whether to make the implicit subscription or not. |
| 2342 | New req | Enable multiple refer | The JSR 281 shall enable an application to implement multiple refer according to RFC5368 | - | The procedure should be described in javadoc for reference so the application does it properly. The argument referToUserId renamed to referTo and method Reference.getReferToUserId renamed to getReferTo, and examples provided. |
| 2344 | Clarification | Handling of multiple body parts in a message is too unspecified | - | It is not sufficiently defined how Message with MessageBodyPart is mapped to SIP messages on the sending side, and how SIP message with multipart body is mapped to a Message with MessageBodyParts on receiving side. On top of this, it is not specified how the content types should be handled. | No API change, but Javadoc needs to be clarified. |
