Examples of SipProvider

javax.sip.SipProvider
etf.org/rfc/rfc3261.txt">RFC3261.
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
org.zoolu.sip.provider.SipProvider
SipProvider implements the SIP transport layer, that is the layer responsable for sending and receiving SIP messages. Messages are received by the callback function defined in the interface SipProviderListener.
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:
- messages within a specific transaction,
- messages within a specific dialog,
- messages related to a specific SIP method. It is also possible to use the the identifier ANY to specify
- all messages that are out of any transactions, dialogs, or already specified method types.
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.

Examples of javax.sip.SipProvider

220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 return; } logger.info("transaction state is " + tid.getState()); logger.info("Dialog = " + tid.getDialog()); logger.info("Dialog State is " + tid.getDialog().getState()); SipProvider provider = (SipProvider) responseReceivedEvent.getSource(); try { CSeqHeader cseq = (CSeqHeader) response.getHeader(CSeqHeader.NAME); if (response.getStatusCode() == Response.OK && cseq.getMethod().equals(Request.INVITE)) { // Request cancel = inviteTid.createCancel(); // ClientTransaction ct = // sipProvider.getNewClientTransaction(cancel); Dialog dialog = tid.getDialog(); Request ackRequest = dialog.createAck(cseq.getSeqNumber()); TlsTest.assertTrue( "Secure URI", ((SipURI)ackRequest.getRequestURI()).isSecure() ); logger.info("Ack request to send = " + ackRequest); logger.info("Sending ACK"); dialog.sendAck(ackRequest); // Send a Re INVITE but this time force it // to use UDP as the transport. Else, it will // Use whatever transport was used to create // the dialog. if (reInviteCount == 0) { Request inviteRequest = dialog .createRequest(Request.INVITE); Thread.sleep(100); ClientTransaction ct = provider .getNewClientTransaction(inviteRequest); dialog.sendRequest(ct); reInviteCount++; } else { this.okReceived = true;

View Full Code Here

Examples of org.zoolu.sip.provider.SipProvider

170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 NameAddress from=dialog.getLocalName(); NameAddress target=dialog.getRemoteContact(); if (target==null) target=to; SipURL request_uri=target.getAddress(); if (request_uri==null) request_uri=dialog.getRemoteName().getAddress(); SipProvider sip_provider=dialog.getSipProvider(); String via_addr=sip_provider.getViaAddress(); int host_port=sip_provider.getPort(); boolean rport=sip_provider.isRportSet(); String proto; if (target.getAddress().hasTransport()) proto=target.getAddress().getTransport(); else proto=sip_provider.getDefaultTransport(); NameAddress contact=dialog.getLocalContact(); if (contact==null) contact=from; // increment the CSeq, if method is not ACK nor CANCEL if (!SipMethods.isAck(method) && !SipMethods.isCancel(method)) dialog.incLocalCSeq(); String call_id=dialog.getCallID();

View Full Code Here

0 1 2 3 4 5

TOP

Copyright © 2018 www.massapi.com. All rights reserved.

All source code are property of their respective owners. Java is a trademark of Sun Microsystems, Inc and owned by ORACLE Inc. Contact coftware#gmail.com.