|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Detailed DescriptionThis structure contains callbacks to be registered by application to receieve notifications from the framework about various events in the invite session. Field Documentation
This callback is called when the invite sesion state has changed. Application should inspect the session state (inv_sess->state) to get the current state of the session. This callback is mandatory.
This callback is called when the invite usage module has created a new dialog and invite because of forked outgoing request. This callback is mandatory.
This callback is called whenever any transactions within the session has changed their state. Application MAY implement this callback, e.g. to monitor the progress of an outgoing request, or to send response to unhandled incoming request (such as INFO). This callback is optional.
This callback is called when the invite session has received new offer from peer. Application can inspect the remote offer in "offer", and set the SDP answer with pjsip_inv_set_sdp_answer(). When the application sends a SIP message to send the answer, this SDP answer will be negotiated with the offer, and the result will be sent with the SIP message.
This callback is optional, and it is used to ask the application to create a fresh offer, when the invite session has received re-INVITE without offer. This offer then will be sent in the 200/OK response to the re-INVITE request. If application doesn't implement this callback, the invite session will send the currently active SDP as the offer.
This callback is called after SDP offer/answer session has completed. The status argument specifies the status of the offer/answer, as returned by pjmedia_sdp_neg_negotiate(). This callback is optional (from the point of view of the framework), but all useful applications normally need to implement this callback.
This callback is called when the framework needs to send ACK request after it receives incoming 2xx response for INVITE. It allows application to manually handle the transmission of ACK request, which is required by some 3PCC scenarios. If this callback is not implemented, the framework will handle the ACK transmission automatically. When this callback is overridden, application may delay the sending of the ACK request (for example, when it needs to wait for answer from the other call leg, in 3PCC scenarios). Application creates the ACK request Once it has sent the ACK request, the framework will keep this ACK request in the cache. Subsequent receipt of 2xx response will not cause this callback to be called, and instead automatic retransmission of this ACK request from the cache will be done by the framework. This callback is optional.
This callback is called when the session is about to resend the INVITE request to the specified target, following the previously received redirection response. Application may accept the redirection to the specified target (the default behavior if this callback is implemented), reject this target only and make the session continue to try the next target in the list if such target exists, stop the whole redirection process altogether and cause the session to be disconnected, or defer the decision to ask for user confirmation. This callback is optional. If this callback is not implemented, the default behavior is to NOT follow the redirection response.
The documentation for this struct was generated from the following file:
Copyright (C) 2006-2008 Teluu Inc.
| |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||