Subject: RE: [SIP] 183 in call flows.

From: "Ryner, Jerry" <[email-masked]>
Date: Mon, 16 Apr 2001 12:48:16 -0700

Another point to consider on this is that allowing media to be processed in
the absence of a remote SDP is a serious security risk.  Without a remote
SDP to verify received packets, (assuming no encryption), the gateway could
possibly play out ANYTHING that comes into it on that RTP port.  Hackers
will be able to inject audio into any call during the early media phase
simply by sending RTP packets.  A more likely failure case, however, is when
the previous call's media was not terminated properly for any number of
reasons.  A "stuck" channel on a remote gateway from a previous call will
corrupt the audio on the new call attempt. 
 
Nuera has been requested by multiple carriers to never accept media without
a valid SDP in place.
 
Regards,
Jerry Ryner
Nuera Communications, Inc.

-----Original Message-----
From: Fairlie-Cuninghame, Robert [mailto:[email-masked]]
Sent: Friday, April 13, 2001 4:45 AM
To: [email-masked]'
Subject: [SIP] 183 in call flows.

Hi, 
I recently noticed in the call flow documents that it states that early
media sessions can be established by simply returning a 183 without SDP
(giving the argument that the early media is unidirectional and thus only
needs the caller's SDP).
I don't remember this change being discussed on the list and I have not seen
this behavior stated in any of the bis or old-183 drafts. Where did it come
from  and why?
Although strictly speaking, the SDP is not required I still think it should
still be required in the 183 response because:
a.       it  now forms a response-code specific behavior that is in contrast
to the general early media handling for other provisional responses, eg SDP
in 180. 
b.      Does not allow symmetric RTP or any other type of NAT friendly
processing to occur (because the source address is unknown).
c.       Is an unnecessary "saving". Why not send the SDP? Sending the
reverse SDP doesn't hurt and is in line with processing for other early
media sessions (eg 180 with SDP). Just because the both SDP are specified,
does not mean that the UAS need accept any media in the forward direction.
 
What do other people think? I know we all hate early media but at least
let's make the handling of what we have consistent across all response
codes.
Cheers, 
Robert.

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 17 Apr 2001 09:43:05 +0300

Hi Robert,

What do you consider as a "valid" SDP?

For example, if dynamic IP address allocation is used, or if one party
is behind a firewall, or in a VPN, it is very difficult to make the
validity test based on the media IP address. And, if it's only about
sending any SDP in the 183 message, I think the hacker can also do that
as well.

Regards,

Christer Holmberg
Ericsson Finland

---

From: "Dean Willis" <[email-masked]>
Date: Tue, 17 Apr 2001 12:50:15 -0500

183 in call flows.
I believe that your model illustrates a common fallacy about SIP (that some might say is a problem with SIP).

The conventional usage of SDP says NOTHING about the source of the media streams -- it describes only the DESTINATION of the media. So, waiting until one receives SDP before listening for RTP accomplishes very little (except for perhaps chopping the first few words of the conversation).

A UA can in general not assume that it will be receiving RTP from the same place it sends RTP.

Once can envision a two part "phone" where the earpiece has a different IP address than the mouthpiece. This is perfectly legal in SIP.

This is part of why it is so hard to make SIP NAT-and-firewall friendly. On the other hand, it's still more tractable than H.323  . . .

There is hope that the work being done with secure RTP will resolve the obvious difficulties.

--
Dean

----- Original Message ----- 
  From: Ryner, Jerry 
  To: Fairlie-Cuninghame, Robert ; [email-masked]' 
  Sent: Monday, April 16, 2001 2:48 PM
  Subject: RE: [SIP] 183 in call flows.

  Another point to consider on this is that allowing media to be processed in the absence of a remote SDP is a serious security risk.  Without a remote SDP to verify received packets, (assuming no encryption), the gateway could possibly play out ANYTHING that comes into it on that RTP port.  Hackers will be able to inject audio into any call during the early media phase simply by sending RTP packets.  A more likely failure case, however, is when the previous call's media was not terminated properly for any number of reasons.  A "stuck" channel on a remote gateway from a previous call will corrupt the audio on the new call attempt. 

  Nuera has been requested by multiple carriers to never accept media without a valid SDP in place.

  Regards,

  Jerry Ryner

   

  -----Original Message-----
  From: Fairlie-Cuninghame, Robert [mailto:[email-masked]]
  Sent: Friday, April 13, 2001 4:45 AM
  To: [email-masked]'
  Subject: [SIP] 183 in call flows.

  Hi, 

  I recently noticed in the call flow documents that it states that early media sessions can be established by simply returning a 183 without SDP (giving the argument that the early media is unidirectional and thus only needs the caller's SDP).

  I don't remember this change being discussed on the list and I have not seen this behavior stated in any of the bis or old-183 drafts. Where did it come from  and why?

  Although strictly speaking, the SDP is not required I still think it should still be required in the 183 response because:

  a.       it  now forms a response-code specific behavior that is in contrast to the general early media handling for other provisional responses, eg SDP in 180. 

  b.      Does not allow symmetric RTP or any other type of NAT friendly processing to occur (because the source address is unknown).

  c.       Is an unnecessary "saving". Why not send the SDP? Sending the reverse SDP doesn't hurt and is in line with processing for other early media sessions (eg 180 with SDP). Just because the both SDP are specified, does not mean that the UAS need accept any media in the forward direction.

  What do other people think? I know we all hate early media but at least let's make the handling of what we have consistent across all response codes.

  Cheers, 

  Robert.