No subject

and each medium would have a send and receive chain of elements. The 
client would provide the SDPs, and connect the bin to its audio, video etc 
device elements (xvimagesink, alsasink, alsasrc, etc).

Let's look at how this looks when described with SDP:

--cut--
[local-SDP]
v=0
c=IN IP4 host1.foo.com
m=audio 49170 RTP/AVP 0 97
a=rtpmap:0 PCMU/8000
a=rtpmap:97 iLBC/8000
m=video 51372 RTP/AVP 31 32
a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000

[remote-SDP]
v=0
c=IN IP4 host2.bar.com
m=audio 49920 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 53000 RTP/AVP 32
a=rtpmap:32 MPV/90000
--cut--

The gstsdpbin would need to setup two rtpbins (one for audio, one for 
video), set "host2.bar.com" as the destination address for both rtpbins 
(but use dest-port 49920 for audio, and 53000 for video), prepare the send 
chains to use PCMU (audio, G.711) and MPV (video, MPEG1/2) codecs, set up 
pt-switch/muxes for audio and video (audio: PTs 0 and 97; video: PTs 31 
and 32). And that's it, the session would be ready for use. The rtpbins 
would take care of generating RTCP for audio and video sessions (as they 
are separate RTP sessions).

The gstsdpbin would contain/manage the following elements (N = media 
count, N = 2 in the example above):

session elements:
     N * rtpbin
receive chains:
     N * {rtprecv -> pt-switch -> X*{depayloader+decoder} -> adder -> ghostsrc } 
send chains:
     N * {ghostsink -> Y*{encoder+payloader} -> rtpsend }

X is the number of codecs we have for receiving, and Y the number of 
codecs we have for sending. I'm not entirely sure how to implement the 
switching/muxing described here, but the aim is that you could change the 
send-codec, and support multiple receive-codecs without having to rebuild 
(and pause) the pipelines. And of course, the unused codecs should not 
consume cpu cycles, so just running all the codecs all the time is not an 
option.

Now a simplified version that we could start with would be:

session elements:
     N * rtpbin
receive chains:
     N * {rtprecv/udpsrc -> 1x {depayloader+decoder} -> ghostsrc } 
send chains:
     N * {ghostsink -> 1*{encoder+payloader} -> rtpsend/udpsink }

Additionally, it should be noted that the SDPs (l&r) can change
at any time during a session (change of codec params, etc). The idea would 
be that gstsdpbin would contain the intelligence to do the updates
on behalf of the application.

Links
-----

Farsight
   - http://farsight.sf.net
Sofia-SIP, LGPL'd SIP/SIMPLE stack
   - http://sofia-sip.sf.net
rtpbin, etc
   - http://gstreamer.freedesktop.org/documentation/rtp.html
SIP, SDP and SDP offer/answer
   - SIP: http://www.faqs.org/rfcs/rfc3261.html +
     http://en.wikipedia.org/wiki/Session_Initiation_Protocol
   - SDP - http://www.faqs.org/rfcs/rfc2327.html
   - Offer/answer - http://www.faqs.org/rfcs/rfc3264.html

--
  links, my public keys, etc at http://eca.cx/kv