[Ekiga-list] Receiving SIP RTP before media description [was ekiga answers with delay ...?]

[Craig Southeren]

On Sat, 25 Nov 2006 02:45:17 +0100
Daniel Huhardeaux <devel at tootai.net> wrote:

..deleted

> > > I don't see this as a bug. Check the implementations in various other
> > > phones.
> > > ---------------
> > > So here's my throw of RFC 3264, Section 5.1:
> > > 
> > > "Once the offerer has sent the offer, it MUST be prepared to receive media
> > > for any recvonly streams described
> > > by that offer. It MUST be prepared to send and receive media for any
> > > sendrecv streams in the offer, and send
> > > media for any sendonly streams in the offer (of course, it cannot actually
> > > send until the peer provides an
> > > answer with the needed address and port information). In the case of RTP,
> > > even though it may receive media
> > > before the answer arrives, it will not be able to send RTCP receiver
> > > reports until the answer arrives."
> > > --------------------
> > > Say hello to Damien from me, I hope that he can join us at AstriVideoCon
> > > in Paris!
> > > 
> > > Good luck fixing this bug in Ekiga   :-) 
> > > 
> > > ----------------------------------------------------------------------
> > >   oej - 10-29-06 10:37
> > > ----------------------------------------------------------------------
> > > Not a bug in Asterisk, bug in Ekiga until proven otherwise   :-) 

I think we differ in the interpretation of this paragraph, and I
don't think this behaviour is a bug in Ekiga. 

If anything, it would be a bug in OPAL, and so I have copied this email
to the correct OPAL mailing list so that other people who are
knowledgeable in SIP may see it.

My reading of this paragraph is that the offerer must have the
UDP sockets ready to receive data before it sends the offer, so that the
sender does not get ICMP "destination not ready" errors. This same
requirement exists in other VoIP protocols such as H.323, because the
media may arrive before the acknowledge (but this difference should be
measured in milliseconds, not seconds).

There are many reasons why it is not feasible to treat the arrival of an
RTP packet as the de-facto start of the media session:

1) The receiving endpoint can use completely different payload types
than the offering endpoint. As an example, an offering endpoint cannot 
assume that simply because it offered to send Speex using dynamic payload
type 108 that any RTP data it receives with payload type 108 is Speex.
If it does, it could end up trying to push H.263 video data or iLBC
audio through a Speex codec. There is no way to avoid this unless the
offerer waits for the session information.

2) In certain SIP scenarios, it is impossible to process received media
until the SDP session information is received. Some video codecs (such
as H.263 and H.264) transmit information in the SDP parameters that is
required to decode the media. Media encryption also requires that the
offerer have the encryption key (which is in the SDP session information)
before the media can be decrypted.

3) It is a gaping security hole. It means that a black hat has simply to
send an RTP packet to an endpoint that has sent a session offer, and the
offering endpoint will then start allocating resources and presenting
whatever media it receives to the user. When the real media starts
arriving from the reaal endpoint, it could be lost or ignored.

4) For endpoints that offer a wide variety of codecs, being prepared to
receive any offered media type at any time prior to receiving the
session description would require the allocation of any infeasibly large
amount of resources. For example, this would require Ekiga to allocate
an instance of every audio and video codec and have them ready and
prepared to receive media. When there are 10 different audio codecs, and
two video codecs, this is not an option.

5) The correct way to start media before answer supervision starts (i.e.
before sending the 200 OK) is to send a session description in an
intermediate response, such as a 183. This will allow the offered to
start the media session and receive any inband tones or early media
prior to the start of answer supervision signalling. 

   Craig

-----------------------------------------------------------------------
 Craig Southeren          Post Increment – VoIP Consulting and Software
 craigs at postincrement.com.au                   www.postincrement.com.au

 Phone:  +61 243654666      ICQ: #86852844
 Fax:    +61 243656905      MSN: craig_southeren at hotmail.com
 Mobile: +61 417231046      Jabber: craigs at jabber.org

 "It takes a man to suffer ignorance and smile.
  Be yourself, no matter what they say."   Sting