public interface IncomingSipResponse extends 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| Modifier and Type | Method and Description |
|---|---|
OutgoingSipRequest |
createAck() |
OutgoingSipRequest |
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.
|
Proxy |
getProxy() |
OutgoingSipRequest |
getRequest() |
boolean |
isForked()
Determines whether this response was the result of a downstream element forking the initial request.
|
getReasonPhrase, getStatus, setStatus, setStatusaddAcceptLanguage, 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, setParameterableHeaderOutgoingSipRequest getRequest()
getRequest in interface SipResponseProxy getProxy()
OutgoingSipRequest createAck()
OutgoingSipRequest createPrack() throws Rel100Exception
Rel100Exception - if this response is not a reliable provisional response.boolean isForked()
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 SipSession activity 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.
true if this response is the result of a downstream element forking;
otherwise false.