Examples of ToHeader

javax.sip.header.ToHeader
The To header field first and foremost specifies the desired "logical" recipient of the request, or the address-of-record of the user or resource that is the target of this request. This may or may not be the ultimate recipient of the request. Requests and Responses must contain a ToHeader, indicating the desired recipient of the Request. The UAS or redirect server copies the ToHeader into its Response.
The To header field MAY contain a SIP or SIPS URI, but it may also make use of other URI schemes i.e the telURL, when appropriate. All SIP implementations MUST support the SIP URI scheme. Any implementation that supports TLS MUST support the SIPS URI scheme. Like the From header field, it contains a URI and optionally a display name, encapsulated in a {@link javax.sip.address.Address}.
A UAC may learn how to populate the To header field for a particular request in a number of ways. Usually the user will suggest the To header field through a human interface, perhaps inputting the URI manually or selecting it from some sort of address book. Using the string to form the user part of a SIP URI implies that the User Agent wishes the name to be resolved in the domain to the right-hand side (RHS) of the at-sign in the SIP URI. Using the string to form the user part of a SIPS URI implies that the User Agent wishes to communicate securely, and that the name is to be resolved in the domain to the RHS of the at-sign. The RHS will frequently be the home domain of the requestor, which allows for the home domain to process the outgoing request. This is useful for features like "speed dial" that require interpretation of the user part in the home domain.
The telURL may be used when the User Agent does not wish to specify the domain that should interpret a telephone number that has been input by the user. Rather, each domain through which the request passes would be given that opportunity. As an example, a user in an airport might log in and send requests through an outbound proxy in the airport. If they enter "411" (this is the phone number for local directory assistance in the United States), that needs to be interpreted and processed by the outbound proxy in the airport, not the user's home domain. In this case, tel:411 would be the right choice.
Two To header fields are equivalent if their URIs match, and their parameters match. Extension parameters in one header field, not present in the other are ignored for the purposes of comparison. This means that the display name and presence or absence of angle brackets do not affect matching.
- The "Tag" parameter - is used in the To and From header fields of SIP messages. It serves as a general mechanism to identify a dialog, which is the combination of the Call-ID along with two tags, one from each participant in the dialog. When a UA sends a request outside of a dialog, it contains a From tag only, providing "half" of the dialog ID. The dialog is completed from the response(s), each of which contributes the second half in the To header field. When a tag is generated by a UA for insertion into a request or response, it MUST be globally unique and cryptographically random with at least 32 bits of randomness. Besides the requirement for global uniqueness, the algorithm for generating a tag is implementation specific. Tags are helpful in fault tolerant systems, where a dialog is to be recovered on an alternate server after a failure. A UAS can select the tag in such a way that a backup can recognize a request as part of a dialog on the failed server, and therefore determine that it should attempt to recover the dialog and any other state associated with it.
A request outside of a dialog MUST NOT contain a To tag; the tag in the To field of a request identifies the peer of the dialog. Since no dialog is established, no tag is present.
For Example:
To: Carol sip:carol@jcp.org To: Duke sip:duke@jcp.org;tag=287447 @see HeaderAddress @author BEA Systems, NIST @version 1.2
org.zoolu.sip.header.ToHeader
SIP Header To. The To header field specifies the desired "logical" recipient of the request, or the address-of-record of the user or resource that is the target of this request. This may or may not be the ultimate recipient of the request. Like the From header field, it contains a URI and optionally a display name.
A request outside of a dialog MUST NOT contain a To tag; the tag in the To field of a request identifies the peer of the dialog. Since no dialog is established, no tag is present. The original recipient may or may not be the UAS processing the request, due to call forwarding or other proxy operations. A UAS MAY apply any policy it wishes to determine whether to accept requests when the To header field is not the identity of the UAS. However, it is RECOMMENDED that a UAS accept requests even if they do not recognize the URI scheme (for example, a tel: URI) in the To header field, or if the To header field does not address a known or current user of this UAS. If, on the other hand, the UAS decides to reject the request, it SHOULD generate a response with a 403 (Forbidden) status code and pass it to the server transaction for transmission.

Examples of javax.sip.header.ToHeader

            }


            // Check if it is an initial SUBSCRIBE or a refresh / unsubscribe
            String toTag = Integer.toHexString( (int) (Math.random() * Integer.MAX_VALUE) );
            response = messageFactory.createResponse(202, refer);
            ToHeader toHeader = (ToHeader) response.getHeader(ToHeader.NAME);


            // Sanity check: to header should not have a tag. Else the dialog
            // should have matched
            TestHarness.assertNull("To-tag!=null but no dialog match! My dialog=" + dialog, toHeader.getTag());
            toHeader.setTag(toTag); // Application is supposed to set.


            this.dialog = st.getDialog();
            // REFER dialogs do not terminate on bye.
            this.dialog.terminateOnBye(false);
            if (dialog != null) {

View Full Code Here

Examples of org.zoolu.sip.header.ToHeader




   /** Updates the registration of a local user.
     * @return it returns the response message for the registration. */
   protected Message updateRegistration(Message msg)
   {  ToHeader th=msg.getToHeader();
      if (th==null)  
      {  printLog("ToHeader missed: message discarded",LogLevel.HIGH);
         int result=400;
         return MessageFactory.createResponse(msg,result,SipResponses.reasonOf(result),null);  
      }         
      SipURL dest_uri=th.getNameAddress().getAddress();
      String user=dest_uri.getUserName()+"@"+dest_uri.getHost();


      int exp_secs=server_profile.expires;
      // set the expire value
      ExpiresHeader eh=msg.getExpiresHeader();

View Full Code Here

0 1 2 3 4 5

TOP

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.