• No results found

Verification Standards

In document Konnetic Unity SIP.NET SDK (Page 39-42)

Message Structure

4.4  SDP Example

5.2.2 Verification Standards

Testing of the library against industry standards in important to Konnetic. The following test suites have been used to verify that Unity SIP Library is fully compatible with the standard.

Connection

An association between two endpoints which carries packets across networks. Each endpoint is represented by a network address and port. In SIP, this concept is sometime referred to as a Flow. In the Unity SIP .NET API, a connection can use either TLS, TCP or UDP transport.

Konnetic's Unity SIP .NET API supports two types of connections: inbound and outbound. An inbound connection listens for incoming packets on an assigned local endpoint. Outbound connections initiate transmissions from the local endpoint to the correspondent. Outbound connections will typically use an ephemeral port number and subsequently listen on that port for responses.

Destination Tuple

A destination tuple contains the information needed to connect to a remote network device. It is formed of the IP Adddress of the remote device, the remote listening port and the transport protocol. Clients can either use the libraries DNS facility to resolve addresses, ports and transports, or can send messages directly using a destination tuple contained in the DestinationTuple object.

Dialog

A dialog represents a peer-to-peer SIP relationship between two or more user clients that persists for some time. It is analogous to a conversation or call, and is sometimes refer to as such. A session is typically associated with a dialog.

Header Field

Title Missing Functionality

RFC4475: SIP Torture Test Messages None ETSI: Conformance Test Specification for

SIP Proxy, Registrar, Redirect functionality was not tested

A header field is a component of the SIP message header. A header field can appear as one or more header field rows. Header field rows consist of a header field name and zero or more header field values. Multiple header field values on a given header field row are seperated by commas. Some header fields can only hvae a sinlge field value, and as a result, always appear as a single header field row.

Outbound Proxy

A proxy that receives requests from a client, even though it may not be the server IP

Address resolved by the Request-URI. Typically, a User Agent is manually configured with an outbound proxy, or can learn about one through auto-configuration protocols.

The ProxyServers config section allows the client application to configure the default outbound proxy servers for request messages. Alternative mechanisms are available to provide the proxy services, including on the SipCore.

The proxy servers are used by the outgoing message processsors to create a route-set on the message (unless a route header field is already present). The processor calculates the remote address of the message according to RFC3261 and RFC3263 and takes into account the existance of outbound proxy servers, Route header fields and loose routing rules.

There is a separate configuration for secure proxy servers to be configured as an outbound route-set for all secure transmissions. Only proxy servers with secure SIP URIs are allowed (e.g.

sips:proxy3.com) for secure transmissions.

Route Set

A route set is a collection of ordered SIP or SIP URI which represent a list of network nodes (typically proxies) that must be traversed when sending a particular request. A route set can be learned, through headers like Record-Route, or it can be configured.

SDP

Session Description Protocol, an IETF Internet standard (RFC 4566). It defines a format for

representing multimedia sessions. SDP objects are carried in the body of SIP messages and, based on the offer/answer model, are used to negotiate the media characteristics of a session between users.

Session

participate in some activity or exchange media descriptions required to establish media communication.

SIP

Session Initiation Protocol, an IETF Internet standard (RFC 3261).

SIP Transaction

SIP is a transactional protocol. Interactions between network elements take place in a series of independent message exchanges (Message Exchange Patterns). A SIP transaction consists of a single request and all following responses to that request. Two categories of transaction exist: those that are initated with an INVITE request (Invite Transactions), and those that are not (Generic

Transactions).

User Client

The device that hosts the SIP-based application.

The Unity SIP Library relies upon certain external resources to operate. Those resources must be available at runtime and access-control permissions must be set so as to allow the executing thread to access them. Additionally the library issues Code Access Security (CAS) demands upon the call stack at certain points in the operation.

The resources include:

 Sockets - the SIP Library is a networked library and requires unrestricted access to network

sockets. A CAS demand is placed on the call stack whenever the library access the network.

 DNS - Domain Name Service querys are a fundamental part of using SIP. The library requires

access to the DNS servers specified in the Konnetic.Net.NetworkInformation object. A CAS demand is placed on the call stack whenever the library issues a (non-cached) DNS query.

 File IO - The library must have permission to read the configuration file, and any files it

dynamically links to.

 Reflection - Internally the Unity SIP Library uses information about certain types when

executing. Furthermore, permission to invoke methods on types may be required in future

version.

The following diagram illustrates the overall architecture of the Unity SIP .NET API and important dependencies.

In document Konnetic Unity SIP.NET SDK (Page 39-42)

Related documents