test.unit.gov.nist.javax.sip.stack.nonblocking

Class NonBlockingTest.Client

java.lang.Object

test.unit.gov.nist.javax.sip.stack.nonblocking.NonBlockingTest.Client

All Implemented Interfaces:

Closeable, AutoCloseable, EventListener, SipListener

Enclosing class:

NonBlockingTest

public class NonBlockingTest.Client
extends Object
implements Closeable

Constructor Summary

Constructors

Constructor and Description
NonBlockingTest.Client()

Method Summary

Methods

Modifier and Type	Method and Description
void	close()
void	processResponse(ResponseEvent arg0) Processes a Response received on a SipProvider upon which this SipListener is registered.
void	sendInvite(int serverPort)

Methods inherited from class java.lang.Object

clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait

Constructor Detail

NonBlockingTest.Client

public NonBlockingTest.Client()

Method Detail

sendInvite

public void sendInvite(int serverPort)
                throws Exception

Throws:

Exception

close

public void close()
           throws IOException

Specified by:

close in interface Closeable

Specified by:

close in interface AutoCloseable

Throws:

IOException

processResponse

public void processResponse(ResponseEvent arg0)

Description copied from interface: SipListener

Processes a Response received on a SipProvider upon which this SipListener is registered.

Handling Responses:
When the application receives a ResponseEvent from the SipProvider the ResponseEvent may or may not correlate to an existing Request of the application. The application can be determine if the ResponseEvent belongs to an existing Request by checking the client transaction of the ResponseEvent.

• If the the client transaction equals null the ResponseEvent does not belong to an existing Request and the Response is considered stray, i.e. stray response can be identitied, if responseEvent.getClientTransaction() == null;. Handling of these "stray" responses is dependent on the application i.e. a proxy will forward them statelessly using the SipProvider.sendResponse(Response)method, while a User Agent will discard them.
• If the client transaction does NOT equal null the application determines it action to the ResponseEvent based on the content of the Response information.

User Agent Client (UAC) behaviour:
After possibly receiving one or more provisional responses (1xx) to a Request, the UAC will get one or more 2xx responses or one non-2xx final response. Because of the protracted amount of time it can take to receive final responses to an INVITE, the reliability mechanisms for INVITE transactions differ from those of other requests. A UAC needs to send an ACK for every final Response it receives, however the procedure for sending the ACK depends on the type of Response. For final responses between 300 and 699, the ACK processing is done by the transaction layer i.e. handled by the implementation. For 2xx responses, the ACK processing is done by the UAC application, to guarantee the three way handshake of an INVITE transaction. This specification defines a utility thats enables the SipProvider to handle the ACK processing for an INVITE transaction, see the SipStack.isRetransmissionFilterActive()method.
A 2xx response to an INVITE establishes a session, and it also creates a dialog between the UAC that issued the INVITE and the UAS that generated the 2xx response. Therefore, when multiple 2xx responses are received from different remote User Agents, i.e. the INVITE forked, each 2xx establishes a different dialog and all these dialogs are part of the same call. If an INVITE client transaction returns a TimeoutEvent rather than a response the UAC acts as if a 408 (Request Timeout) response had been received from the UAS.

Stateful Proxies:
A proxy application that handles a response statefully must do the following processing:

• Find the appropriate response context.
• Remove the topmost Via header.
• Add the response to the response context.
• Check to determine if this response should be forwarded immediately.
• When necessary, choose the best final response from the response context. If no final response has been forwarded after every client transaction associated with the response context has been terminated, the proxy must choose and forward the "best" response from those it has seen so far.

Additionally the following processing MUST be performed on each response that is forwarded.

• Aggregate authorization header values if necessary.
• Optionally rewrite Record-Route header values.
• Forward the response using the ServerTransaction.sendResponse(Response)method.
• Generate any necessary CANCEL requests.

Stateless Proxies:
As a stateless proxy does not have any notion of transactions, or of the response context used to describe stateful proxy behavior, responseEvent.getClientTransaction == null; always return true . Response processing does not apply, the transaction layer of the SipProvider implementation is by-passed. An application intending to stateless proxy the Response MUST:

• Inspect the sent-by value in the first Via header.
• If that address matches the proxy, the proxy MUST remove that header from the response.
• Forward the resulting response to the location indicated in the next Via header using the SipProvider.sendResponse(Response)method.

Specified by:

processResponse in interface SipListener

Parameters:

arg0 - - the responseEvent fired from the SipProvider to the SipListener representing a Response received from the network.