Subject: [rtcweb] JSEP - Order of SDP and RTP

From: Cullen Jennings <[email-masked]>
Date: Fri, 27 Jan 2012 08:33:04 -0700

I’m having a little trouble understanding what the permitted order of setLocal()/setRemote() are.
In the basic call setup case, you have:

Caller::setLocal()
Callee::setRemote()
Callee::setLocal()
Caller::setRemote()

But then in Section 7.3, you show something different:

Responder::setRemote()
Responder:setLocal()
Initiator::setLocal()
Initiator::setRemote()

This seems a bit different than SDP which says when you send an offer in SDP, you need to be able to receive the media described in the offer. What might  happen in some cases is if the RTP from the responder (with the new SDP parameters) arrives at the initiator before the initiator is ready to receive it, one way or another the RTP may be rejected. For example, if initiator has not opened the port in the SDP, the host may send an ICMP destination unreachable. Some firewalls seeing this from the side to the outside would use it block future packets on the same flow for some period of time so even after A did open the port, future RTP packets could be blocked. Other implementation that received a RTP packets for a codec that was not yet negotiated would consider it a serious error and some implementation would close the DTLS connection as things were clearly messed up. If the web side was gatewaying to SIP that inspected by SBC, firewalls other other policy devices, they would almost all discard RTP for codecs that were not yet negotiated in the SDP and many would terminate the session as an attack. Any thoughts on how this is going to work in practice?

---

From: Justin Uberti <[email-masked]>
Date: Fri, 27 Jan 2012 14:40:55 -0500

On Fri, Jan 27, 2012 at 10:33 AM, Cullen Jennings <[email-masked]> wrote:

> This seems a bit different than SDP which says when you send an offer in
> SDP, you need to be able to receive the media described in the offer. What
> might  happen in some cases is if the RTP from the responder (with the new
> SDP parameters) arrives at the initiator before the initiator is ready to
> receive it, one way or another the RTP may be rejected. For example, if
> initiator has not opened the port in the SDP, the host may send an ICMP
> destination unreachable. Some firewalls seeing this from the side to the
> outside would use it block future packets on the same flow for some period
> of time so even after A did open the port, future RTP packets could be
> blocked. Other implementation that received a RTP packets for a codec that
> was not yet negotiated would consider it a serious error and some
> implementation would close the DTLS connection as things were clearly
> messed up. If the web side was gatewaying to SIP that inspected by SBC,
> firewalls other other policy devices, they would almost all discard RTP for
> codecs that were not yet negotiated in the SDP and many would terminate the
> session as an attack. Any thoughts on how this is going to work in practice?
>

The thinking here was to allow easy handling of the case where the remote
side rejects the request, i.e. it becomes a no-op. I was also thinking that
in the add-source case, each offer/answer exchange would add a
unidirectional stream (from offerer to answerer), so the race you mention
above would be less of an issue.

That being said, I see your point and it's not hard to change the behavior
around to be like 7.1. It just means the old description needs to be kept
around and re-installed in the event the offer is rejected (which is
admittedly a corner case).

>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>