📄 sipprovider.html
字号:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<!--NewPage-->
<HTML>
<HEAD>
<!-- Generated by javadoc (build 1.5.0) on Wed Nov 15 07:55:48 PST 2006 -->
<TITLE>
SipProvider (JSIP API v1.2)
</TITLE>
<META NAME="keywords" CONTENT="javax.sip.SipProvider interface">
<LINK REL ="stylesheet" TYPE="text/css" HREF="../../stylesheet.css" TITLE="Style">
<SCRIPT type="text/javascript">
function windowTitle()
{
parent.document.title="SipProvider (JSIP API v1.2)";
}
</SCRIPT>
<NOSCRIPT>
</NOSCRIPT>
</HEAD>
<BODY BGCOLOR="white" onload="windowTitle();">
<!-- ========= START OF TOP NAVBAR ======= -->
<A NAME="navbar_top"><!-- --></A>
<A HREF="#skip-navbar_top" title="Skip navigation links"></A>
<TABLE BORDER="0" WIDTH="100%" CELLPADDING="1" CELLSPACING="0" SUMMARY="">
<TR>
<TD COLSPAN=2 BGCOLOR="#EEEEFF" CLASS="NavBarCell1">
<A NAME="navbar_top_firstrow"><!-- --></A>
<TABLE BORDER="0" CELLPADDING="0" CELLSPACING="3" SUMMARY="">
<TR ALIGN="center" VALIGN="top">
<TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1"> <A HREF="../../overview-summary.html"><FONT CLASS="NavBarFont1"><B>Overview</B></FONT></A> </TD>
<TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1"> <A HREF="package-summary.html"><FONT CLASS="NavBarFont1"><B>Package</B></FONT></A> </TD>
<TD BGCOLOR="#FFFFFF" CLASS="NavBarCell1Rev"> <FONT CLASS="NavBarFont1Rev"><B>Class</B></FONT> </TD>
<TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1"> <A HREF="package-tree.html"><FONT CLASS="NavBarFont1"><B>Tree</B></FONT></A> </TD>
<TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1"> <A HREF="../../deprecated-list.html"><FONT CLASS="NavBarFont1"><B>Deprecated</B></FONT></A> </TD>
<TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1"> <A HREF="../../index-all.html"><FONT CLASS="NavBarFont1"><B>Index</B></FONT></A> </TD>
<TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1"> <A HREF="../../help-doc.html"><FONT CLASS="NavBarFont1"><B>Help</B></FONT></A> </TD>
</TR>
</TABLE>
</TD>
<TD ALIGN="right" VALIGN="top" ROWSPAN=3><EM>
<b>JSIP API v1.2<br><font size=-1>November 2006</font></b></EM>
</TD>
</TR>
<TR>
<TD BGCOLOR="white" CLASS="NavBarCell2"><FONT SIZE="-2">
<A HREF="../../javax/sip/SipListener.html" title="interface in javax.sip"><B>PREV CLASS</B></A>
<A HREF="../../javax/sip/SipStack.html" title="interface in javax.sip"><B>NEXT CLASS</B></A></FONT></TD>
<TD BGCOLOR="white" CLASS="NavBarCell2"><FONT SIZE="-2">
<A HREF="../../index.html?javax/sip/SipProvider.html" target="_top"><B>FRAMES</B></A>
<A HREF="SipProvider.html" target="_top"><B>NO FRAMES</B></A>
<SCRIPT type="text/javascript">
<!--
if(window==top) {
document.writeln('<A HREF="../../allclasses-noframe.html"><B>All Classes</B></A>');
}
//-->
</SCRIPT>
<NOSCRIPT>
<A HREF="../../allclasses-noframe.html"><B>All Classes</B></A>
</NOSCRIPT>
</FONT></TD>
</TR>
<TR>
<TD VALIGN="top" CLASS="NavBarCell3"><FONT SIZE="-2">
SUMMARY: NESTED | FIELD | CONSTR | <A HREF="#method_summary">METHOD</A></FONT></TD>
<TD VALIGN="top" CLASS="NavBarCell3"><FONT SIZE="-2">
DETAIL: FIELD | CONSTR | <A HREF="#method_detail">METHOD</A></FONT></TD>
</TR>
</TABLE>
<A NAME="skip-navbar_top"></A>
<!-- ========= END OF TOP NAVBAR ========= -->
<HR>
<!-- ======== START OF CLASS DATA ======== -->
<H2>
<FONT SIZE="-1">
javax.sip</FONT>
<BR>
Interface SipProvider</H2>
<HR>
<DL>
<DT><PRE>public interface <B>SipProvider</B></DL>
</PRE>
<P>
This interface represents the messaging entity of a SIP stack and as such is the interface that defines the messaging and transactional component view of the SIP stack. It must be implemented by any object representing a SIP stack compliant to this specification that interacts directly with a proprietary implementation of a SIP stack. This interface defines the methods that enable any registered application implementing the <A HREF="../../javax/sip/SipListener.html" title="interface in javax.sip"><CODE>SipListener</CODE></A> interface to: <ul> <li> Register a <A HREF="../../javax/sip/SipListener.html" title="interface in javax.sip"><CODE>SipListener</CODE></A> to the SipProvider. Once the SipListener is registered with the SipProvider it will get notified of Events representing either Request, Response, Timeout messages, Network errors and Transaction termination. <li> De-register a <A HREF="../../javax/sip/SipListener.html" title="interface in javax.sip"><CODE>SipListener</CODE></A> from the SipProvider. Once a SipListener is de-registered, it will no longer receive any Events from that SipProvider. <li> Send <A HREF="../../javax/sip/message/Request.html" title="interface in javax.sip.message"><CODE>Request</CODE></A>'s statelessly. <li> Send <A HREF="../../javax/sip/message/Response.html" title="interface in javax.sip.message"><CODE>Response</CODE></A>'s statelessly. <li> Client and Server Transaction creation methods. <li> Listening Point manipulation methods. <li> New CallIdHeader accessor method. <li> SipStack object accessor method. </ul> <p> <b>Architecture:</b><br> This specification defines a many-to-one relationship between a SipProvider and a SipStack, a one-to-many relationship between a SipProvider and a ListeningPoint and a many-to-one relationship between a SipProvider and a SipListener. <p> Each SipProvider can be related to zero or more ListeningPoints. However, the SipProvider can have only one ListeningPoint for each transport type. For example, a single SipProvider can have one TCP ListeningPoint and one UDP ListeningPoint but cannot have two UDP ListeningPoints. Applications that wish to have multiple ListeningPoints with the same transport must use a separate SipProvider for each such ListeningPoint. <p> The ListeningPoints of the SipProvider specify the local address from where request messages will be sent. When the application sends a request directly from a SipProvider or from an object that the SipProvider created (Dialog or Transaction) the application might not know in advance the transport that this request will use. The transport is often resolved using a DNS server. In the process of sending the request, the remote transport will be resolved. The provider will then be able to send the request from a suitable ListeningPoint according to the resolved transport. If the resolved transport is UDP, the Provider's UDP ListeningPoint will be used. If the resolved address is TCP, the Providers's TCP ListeningPoint will be used. <p> If the application creates a SipProvider with a single ListeningPoint, let's say UDP, it means that UDP requests will be sent from the specific UDP ListeningPoint, and that the application does not care from where TCP requests will be sent. This is left for the SipStack decision. <p> Since the transport might not be known in advance, the application might find it difficult to specify the transport in the Via header. The SipProvider is responsible for fixing the Via header transport if needed. If the application set a sent-by identifier to the ListeningPoint that is different then the sent-by parameter in the message, the sent-by parameter of the message will be updated. <p> If the application created a provider with zero ListeningPoint, it must have only a single SipProvider per SipStack. <p> A SipProvider has the capability to behave transaction statefully, dialog statefully and statelessly. The transaction stateful methods are defined on the ClientTransaction and ServerTransaction respectfully. The transaction stateful method defined specifically for UAC and stateful proxy applications is: <ul> <li> <A HREF="../../javax/sip/ClientTransaction.html#sendRequest()"><CODE>ClientTransaction.sendRequest()</CODE></A> </ul> <p> The stateful (transactional) convenience method defined specifically for UAS and stateful proxy applications is: <ul> <li> <A HREF="../../javax/sip/ServerTransaction.html#sendResponse(javax.sip.message.Response)"><CODE>ServerTransaction.sendResponse(Response)</CODE></A> </ul> <p> The dialog stateful methods defined specifically for UAC and stateful proxy applications are: <ul> <li> <A HREF="../../javax/sip/Dialog.html#sendRequest(javax.sip.ClientTransaction)"><CODE>Dialog.sendRequest(ClientTransaction)</CODE></A> <li> <A HREF="../../javax/sip/Dialog.html#sendAck(javax.sip.message.Request)"><CODE>Dialog.sendAck(Request)</CODE></A> </ul> <p> The stateless methods (non-transactional) defined on the SipProvider are: <ul> <li> <A HREF="../../javax/sip/SipProvider.html#sendResponse(javax.sip.message.Response)"><CODE>sendResponse(Response)</CODE></A> <li> <A HREF="../../javax/sip/SipProvider.html#sendRequest(javax.sip.message.Request)"><CODE>sendRequest(Request)</CODE></A> </ul> <p> <b>Transaction Model:</b><br> This specification supports stateful and stateless applications on a per message basis, hence transactional semantics are not mandated for all messages. This specification defines two types of transactions, server transactions and client transactions. A stateless proxy does not contain a client or server transaction, stateless proxies are effectively transparent with respect to transactions. <p> Client Transaction:<br> A client transaction exists between a UAC and a UAS specific to Request messages and a server transaction exists between a UAS and a UAC specific to Response messages. A transaction either server or client identifies messages sent between two SIP entities. The purpose of a client transaction is to identify a Request sent by an application that will reliably deliver the Request to a server transaction on the responding SIP entity. The purpose of a server transaction is to identify a Response sent by an application that will reliably deliver the Response to the request initiator. <p> Server Transaction:<br> A new server transaction is required for each response that an application decides to respond to statefully, as follows: <ul> <li>Dialog-Creating Requests: A server transaction is not automatically generated by a SipProvider implementation upon receipt of every Dialog-Creating Request i.e. INVITE. Instead the server transaction is set to <code>null</code> in the RequestEvent and the RequestEvent also containing the Request is passed to the application. It is then the responsibility of the application to decide to handle the Dialog-Creating Request statefully or statelessly, using the appropriate send methods on the SipProvider and the ServerTransaction. If a retransmission of the initial Request request is recieved by the SipProvider the following procedures should be adhered to: <ul> <li>Determine if an exisiting transaction is already handling this Request. <li>If a transaction exists do not pass the Request to the application via a RequestEvent. <li>If a transaction doesn't exist pass the retransmitted request to the application as a RequestEvent. </ul> <li>Non-Dialog-Creating Requests - When the SipProvider receives a Non-Dialog-Creating Request upon which this application has already responded to the Dialog-Creating Request of the same dialogue the server transaction is automatically placed to the RequestEvent and passed up to the application upon which it can respond. Note that the server transaction may be null in a stateful implementation if the incoming request does not match any dialog but must be part of one. That is for requests that must have state but for which the stack cannot find that state, the application ⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -