Fields inherited from interface org.jainslee.resources.sip.SipResponse
SC_ACCEPTED, SC_ADDRESS_INCOMPLETE, SC_ALTERNATIVE_SERVICE, SC_AMBIGUOUS, SC_BAD_EXTENSION, SC_BAD_GATEWAY, SC_BAD_REQUEST, SC_BUSY_EVERYWHERE, SC_BUSY_HERE, SC_CALL_BEING_FORWARDED, SC_CALL_LEG_DONE, SC_CALL_QUEUED, SC_DECLINE, SC_DOES_NOT_EXIT_ANYWHERE, SC_EXTENSION_REQUIRED, SC_FORBIDDEN, SC_GONE, SC_INTERVAL_TOO_BRIEF, SC_LOOP_DETECTED, SC_MESSAGE_TOO_LARGE, SC_METHOD_NOT_ALLOWED, SC_MOVED_PERMANENTLY, SC_MOVED_TEMPORARILY, SC_MULTIPLE_CHOICES, SC_NOT_ACCEPTABLE, SC_NOT_ACCEPTABLE_ANYWHERE, SC_NOT_ACCEPTABLE_HERE, SC_NOT_FOUND, SC_NOT_IMPLEMENTED, SC_OK, SC_PAYMENT_REQUIRED, SC_PROXY_AUTHENTICATION_REQUIRED, SC_REQUEST_ENTITY_TOO_LARGE, SC_REQUEST_PENDING, SC_REQUEST_TERMINATED, SC_REQUEST_TIMEOUT, SC_REQUEST_URI_TOO_LONG, SC_RINGING, SC_SERVER_INTERNAL_ERROR, SC_SERVER_TIMEOUT, SC_SERVICE_UNAVAILABLE, SC_SESSION_PROGRESS, SC_TEMPORARLY_UNAVAILABLE, SC_TOO_MANY_HOPS, SC_TRYING, SC_UNAUTHORIZED, SC_UNDECIPHERABLE, SC_UNSUPPORTED_MEDIA_TYPE, SC_UNSUPPORTED_URI_SCHEME, SC_USE_PROXY, SC_VERSION_NOT_SUPPORTED
All Methods Instance Methods Abstract Methods Modifier and Type Method Description
createPrack()Create a PRACK request to acknowledge a reliable provisional response, as defined by RFC 3262: The response status code must be in the range 101-199.
isForked()Determines whether this response was the result of a downstream element forking the initial request.
Methods inherited from interface org.jainslee.resources.sip.SipMessage
addAcceptLanguage, addAddressHeader, addHeader, addHeaderGeneric, addParameterableHeader, getAcceptLanguage, getAcceptLanguages, getAddressHeader, getAddressHeaders, getCallId, getCharacterEncoding, getContent, getContentLanguage, getContentLength, getContentType, getExpires, getFrom, getHeader, getHeaderGeneric, getHeaderNames, getHeaders, getHeadersGeneric, getLocalAddr, getLocalPort, getMethod, getParameterableHeader, getParameterableHeaders, getProtocol, getRawContent, getRemoteAddr, getRemotePort, getRemoteUser, getSequenceNumber, getSession, getSession, getTo, getTransport, getUserPrincipal, isCommitted, isExtensionRequired, isExtensionSupported, isSecure, isUserInRole, removeHeader, setAcceptLanguage, setAddressHeader, setCharacterEncoding, setContent, setContentLanguage, setContentType, setExpires, setHeader, setHeaderGeneric, setParameterableHeader
OutgoingSipRequest createPrack() throws Rel100ExceptionCreate a PRACK request to acknowledge a reliable provisional response, as defined by RFC 3262:
- The response status code must be in the range 101-199.
- The response must contain a Require: 100rel header.
- The response must contain a valid RSeq header.
- an outgoing PRACK request object
Rel100Exception- if this response is not a reliable provisional response.
boolean isForked()Determines whether this response was the result of a downstream element forking the initial request.
If a downstream SIP element forks a dialog-creating initial request, such as INVITE, multiple 1xx and 2xx responses may be received for the same request. The first 1xx or 2xx response to arrive sets the to-tag (remote tag) for the original
SipSession. Additional 1xx or 2xx responses that arrive with different to-tags are forked responses.
Each forked response creates a new
SipSessionactivity representing the new dialog that was created by the fork.
The first final response that arrives (forked or not) will automatically end all other SipSessions (early dialogs) created by earlier 1xx responses. Any stray 2xx responses that arrive on these early dialogs are automatically handled by the RA, which will send an ACK and a BYE to ensure these dialogs are terminated at the UAS.
Forked response events are fired on the ACI of the original SipSession; this is because the service will already be attached to this ACI, and doesn't know about the forked sessions until responses arrive. The
SipMessage.getSession()method on forked responses returns the SipSession that resulted from the fork, so services can retrieve and attach to these activities if necessary.
Subsequent 1xx or 2xx responses may arrive on sessions that were created by an earlier forked response. These subsequent responses are not forked responses, and will be delivered on their respective SipSessions. Therefore a service that wants to see all responses on all forked sessions must attach to forked sessions when they are detected.
trueif this response is the result of a downstream element forking; otherwise
- EasySIP RA Type 1.3