Sending Responses:
The server side of the transport layer is responsible for sending the responses. The application passes the Response to the ServerTransaction or the SipProvider that will send the Response over one of its ListeningPoints. RFC3261. The response must be sent from the same ListeningPoint on which the request was received.
Receiving Requests:
A SipProvider should be prepared to receive requests on any IP address, port and transport encapsulated in one of its ListeningPoints. When the SipProvider receives a request over any transport, it must examine the value of the "sent-by" parameter in the top Via header. If the host portion of the "sent-by" parameter contains a domain name, or if it contains an IP address that differs from the packet source address, the server must add a "received" parameter to that Via header field value. This parameter must contain the source address from which the packet was received. This is to assist the SipProvider in sending the response, since it must be sent to the source IP address from which the request came. Next, the SipProvider attempts to match the request to a server transaction. If there are any server transactions in existence, the server transport uses the matching procedures of Chapter 17 of RFC3261 to attempt to match the response to an existing transaction. If a matching server transaction is found, the request is passed to that transaction, encapsulated into a RequestEvent and fired to the application for processing. If no match is found, the request is passed to the application, which may decide to construct a new server transaction for that request.
Receiving Responses
Responses are first processed by the transport layer and then passed up to the transaction layer. The transaction layer performs its processing and then passes the response up to the application. When a response is received, the SipProvider examines the top Via header. If the value of the "sent-by" parameter in that header field value does not correspond to a value that the client transport is configured to insert into requests, the response MUST be silently discarded. If there are any client transactions in existence, the client transport uses the matching procedures of Chapter 17 of RFC3261 to attempt to match the response to an existing transaction. If there is a match, the response must be passed to that transaction, encapsulated into a ResponseEvent and fired to the application. Otherwise, the response is stray and must be passed to the application to determine its outcome i.e. a proxy will forward them, while a User Agent will discard.
@see SipListener
@see SipStack
@author BEA Systems, NIST
@version 1.2
SipProvider implements also multiplexing/demultiplexing service through the use of SIP interface identifiers and onReceivedMessage() callback function of specific SipProviderListener.
A SipProviderListener can be added to a SipProvider through the addSipProviderListener(id,listener) method, where: - id is the SIP interface identifier the listener has to be bound to, - listener is the SipProviderListener that received messages are passed to.
The SIP interface identifier specifies the type of messages the listener is going to receive for. Together with the specific SipProvider, it represents the complete SIP Service Access Point (SAP) address/identifier used for demultiplexing SIP messages at receiving side. The identifier can be of one of the three following types: transaction_id, dialog_id, or method_id. These types of identifiers characterize respectively:When receiving a message, the SipProvider first tries to look for a matching transaction, then looks for a matching dialog, then for a matching method type, and finally for a default listener (i.e. that with identifier ANY). For the matched SipProviderListener, the method onReceivedMessage() is fired.
Note: no 482 (Loop Detected) responses are generated for requests that does not properly match any ongoing transactions, dialogs, nor method types.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|