For functions that could be per conference, session, participant, or stream, they would have a session and a participant parameter. A NULL for either of these would be a wildcard.

PurpleMediaManager?

Functions:

*_initiate 	 # Creates a PurpleMedia instance. Probably have a flag 
		   as to whether it's the initiator or responder

Signals:

init-media	# Same as the current signal. Is triggered when *_initiate is called
init-video-src	# These are all triggered when the corresponding *_get_* functions are called
init-video-sink	  The one problem I've thought of with them is that this way it wouldn't
init-audio-src	  be very easy to have multiple srcs or sinks of the same type.
init-audio-sink

Get:

*_get		# Returns a global instance of the PurpleMediaManager

*_get_pipeline	# Returns a global pipeline to be used for all PurpleMedia instances.

*_get_video_src	# These all create their respective types if they don't exist.
*_get_video_sink  Otherwise they return a src/sink-pad for the existing src/sink.
*_get_audio_src
*_get_audio_sink

# The next three functions will probably have a type parameter (audio or video, src or sink)
*_get_plugins	# Return a list of audio/video GStreamer plugins (eg. v4lsrc, alsasrc)
*_get_devices	# Return a list of devices for a specific plugin
*_get_devices_autodetect # Eventually, return a list of devices detected for all supported plugins

PurpleMedia?

Functions:

All of these functions will have parameters for session_id and participant_id NULL for either of these would indicate a wildcard and do this operation for all matching streams

*_add_stream	# Adds a stream/session/participant to the conference, automatically
		  creates participants and FsSessions as necessary
*_add_candidate  # Adds a single candidate to the stream (May not be necessary. Could alternately add a list)
*_set_candidates # Sets a list of candidates for the stream
*_set_codecs	 # Sets a list of codecs for the stream
*_set_direction	 # Changes the direction of a stream/session/participant
		   (could use *_add_stream to accomplish this)

*_accept	# Accept a session (User clicked the accept button)

# The following two could probably be merged into one function
*_mute	# Mutes an audio stream/session/participant (sending and/or receiving?)
*_pause # Pauses a video stream/session/participant (sending and/or receiving?)

*_end	# Ends a stream/session/participant/conference

Signals:

These signals also apply to the wildcard note above

ready	# Waits for both codecs-ready to be TRUE and candidates-prepared to have fired
	  (possibly also wait for the user to click accept if they are the responder
	  otherwise we'll probably need an "accepted" signal)
state-changed # Has an enum state (containing such states as connected, end, and ice-specific values)
		Signals for stream/session/participant/conference

More signals may be necessary for different protocols. Jingle ice-udp may also need a new-candidate and/or new-candidate-pair and a codecs-changed equivalent

Get:

I'm not certain all of these will be necessary

*_codecs	# gets codecs per sessions
*_candidates	# gets candidates per stream
*_streams	# gets stream_ids by session or by participant
*_sessions	# gets session_ids in the conference
*_participants	# gets participant names by conference or by session