Subject: [SIP] Is SDP sufficient?

From: "Doug Sauder" <[email-masked]>
Date: Wed, 12 Jul 2000 12:34:14 -0400

I have been thinking through some issues associated with RTP streams and
security in the context of two party calls.  The main issue is, How can the
RTP receiver filter the incoming RTP packets in a way that guarantees -- or
at least provides reasonable assurance -- that those packets come from the
other party to the call?  The SDP that comes as part of a SIP message tells
the IP address and UDP port of a receiver, but not of a sender.

What I think is worth considering as a solution would be for the two parties
in the call to communicate their source IDs (the SSRC in RTP), since that is
probably the best way to filter incoming RTP packets.  Perhaps this could be
done with an attribute in the SDP.  Alternatively, the sending host address
and port could identify a sender, but that would not allow for media
hand-offs to another host.

I know a complete solution for security could not be accomplished without
use of authentication and encryption.  But, even at a philosophical level, I
have a hard time with the way calls are set up -- namely, the fact that the
two parties to a call exchange information about their receiving ports, but
do not exchange any information to identify the streams they are sending.

Doug Sauder
Broadsoft, Inc

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Colin Perkins <[email-masked]>
Date: Wed, 12 Jul 2000 15:35:35 -0400

>hand-offs to another host.

Note that the RTP SSRC of a participant may change if the session is a
multicast one (due to SSRC collision detection and avoidance).

Colin

---

From: Jiri Kuthan <[email-masked]>
Date: Wed, 12 Jul 2000 21:57:25 +0200

> hand-offs to another host.

There is a new I-D on conveying source information in SDP:
draft-ietf-mmusic-sdp-srcfilter-00.txt. Media hand-offs
have to be solved at application layer by sending
appropriate INVITEs.

Jiri

---

From: Philip Levis <[email-masked]>
Date: Mon, 17 Jul 2000 15:53:21 -0600 (MDT)

I've looked over 2543 several times, and been unable to determine whether
an SDP payload can have multiple sessions specified within it. RFC 2327
(SDP) states that multiple sessions may be specified unless annnounced by
SAP.

I take this to mean that multiple SDP sessions may be specified. Is this
correct?

The next question is, what would multiple SDP sessions signify?

Phil

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 18 Jul 2000 01:04:21 -0400

> (SDP) states that multiple sessions may be specified unless annnounced by

You can have multiple media streams (i.e., multiple m lines in the SDP).
For example, one audio and one video. 

-Jonathan R.
-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: Philip Levis <[email-masked]>
Date: Mon, 17 Jul 2000 23:25:13 -0600 (MDT)

> For example, one audio and one video. 

I'm concerned with sessions, not streams. Not having multiple streams in a
given SDP session description would be problematic for the media
negotation that goes on between parties.

2327:

When SDP is conveyed by SAP, only one session description is allowed per
packet.  When SDP is conveyed by other means, many SDP session
descriptions may be concatenated together (the `v=' line indicating the
start of a session description terminates the previous description).

PINT does so with a defined semantic meaning; I'm wondering what it
corresponds to in standard SIP. It seems to me to be a useful mechanism
for 3pcc.

Phil