SIP (RFC3261) and SDP (RFC3264) and RFC3267, was Fwd: In the firing line

From: Andrew Rutherford <[email protected]>
Subject: Re: In the firing line

Message-Id: <p05200f09baad54dde84d@[203.32.153.90]>
In-Reply-To: <[email protected]>
References: <1048264190.513.76.camel@fred>
 <p05200f01baa14fa16f87@[203.32.153.158]>
 <[email protected]>
 <p05200f01baa3ef28b277@[203.32.153.90]>
 <[email protected]>
 <p05200f00baa6a0761eca@[203.32.153.90]>
 <[email protected]>
 <p05200f03baa8030b79a8@[203.32.153.90]>
 <[email protected]>
 <p05200f01baa93183011d@[203.32.153.90]>
 <[email protected]>
Date: Mon, 31 Mar 2003 11:50:27 +0930

At 2:51 PM +0100 29/3/03, clemens fischer wrote:

>seems SDP/SIP has most of what im2000 needs.  i know SIP is "Session
>Initiation Protocol, but what is SDP?  RFC?

Session Description Protocol - application/sdp is a MIME type for 
communicating setup information for multimedia sessions, including 
multiple types at the same time (eg, audio, video, whiteboard, etc, 
in the same packet).

The original SDP spec was used in multicast advertisments for 
multicast video conferencing. See RFC 2327 for the original spec, and 
RFC 3267 for media stream option negotiation using a combination for 
SDP and SIP.

>  > Basically, the originator sends a list of offers in preference
>>  order, and the recipient picks the best one and puts just it in the
>>  200 OK response. The sender can then sign and store the message in
>>  the appropriate format, then send the ACK back, so the recipient now
>>  knows the mail is ready to pick up.
>
>there's one item missing here:  neither sender nor recipient may know
>more than each others names by the time communication starts.
>keyservers will have to engage into this, ie. the agreement protocol
>must contact several keyservers, present the results first to the
>users MTAs and possibly even to their MUAs in case a human did not
>specify enough rules to infer the keys he will eventually accept.

Yup, I'm assuming that the recipient will go through the list of 
offers and attempt to see if it can resolve keyservers and all other 
relevant bits before it decides which one is "best" and returns the 
200 specifying which option it has selected.

There is a defined "Warning" header, so an implementation can specify 
if it chooses to that the reason it didn't pick one higher up the 
list was that it couldn't get keyserver authentication or whatever.

-- 
Andrew Rutherford      sip:[email protected]      244 Pirie Street
Iagu Networks          tel:+61-8-8425-2255       Adelaide SA 5000
http://www.iagu.net/   mailto:[email protected]   Australia