-
Notifications
You must be signed in to change notification settings - Fork 293
DUM Definitions
Main class that keeps track of all the DialogSet, Dialog, and Usage objects.
A user agent server is a logical entity that generates a response to a SIP request. The response accepts, rejects, or redirects the request. This role lasts only for the duration of that transaction. In other words, if a piece of software responds to a request, it acts as a UAS for the duration of that transaction. If it generates a request later, it assumes the role of a user agent client for the processing of that transaction. (Definition from http://www.faqs.org/rfcs/rfc3261.html)
A user agent client is a logical entity that creates a new request, and then uses the client transaction state machinery to send it. The role of UAC lasts only for the duration of that transaction. In other words, if a piece of software initiates a request, it acts as a UAC for the duration of that transaction. If it receives a request later, it assumes the role of a user agent server for the processing of that transaction. (Definition from http://www.faqs.org/rfcs/rfc3261.html)
A container class that will hold a set of dialogs that were generated from a common request. They share the same call-id and the same from tag in the request that generated the dialog.
A term to generically describe the container for the usage created from a non-dialog creating request such as REGISTER or PUBLISH. Monologs exist for both the UAC and UAS. (This might better be named MonoUsage).
A container holding such things and local and remote CSEQ, URI, Call-ID and such as defined by the SIP standard.
An identifier that uniquely finds a a Dialog by Call-ID, and To and From tags.
An identifier that uniquily identifies a Dialog-Set and is formed from Call-ID and From tag.
These are the objects that are using a dialog. They include ClientInviteSession, ClientOutOfDialogReq, ClientPublication, ClientRegistration, ClientSubscription, ServerInviteSession, ServerOutOfDialogReq, ServerPublication, ServerRegistration, and ServerSubscription. Notice that this is almost, but not entirely, what "usage" means in the IETF specifications. An Invite session or a Subscription is a usage there. The old "psuedo-dialog" concept surrounding registration should be called a Psuedo-Usage or at best Mono-Usage. At the moment, however, these are all reflected in code as "Usages"
These are objects uses to derive class from that allow callbacks from this layer to the application. They include InviteSessionHandler, OutOfDialogHandler, RegistrationHandler, SubscriptionHandler, and PublictionHandler.
All the Usages and Handlers are not really exposed to the applications using this layer. Instead, handles to them are passed out. When the applications goes to use a handle, the underlying object may have been deleted and the applications must be prepared for this not to work.
- Navigation
- Developers
- Packages
- Community