On Sat, 25 Nov 2006 02:45:17 +0100 Daniel Huhardeaux <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] www.postincrement.com.au Phone: +61 243654666 ICQ: #86852844 Fax: +61 243656905 MSN: [EMAIL PROTECTED] Mobile: +61 417231046 Jabber: [EMAIL PROTECTED] "It takes a man to suffer ignorance and smile. Be yourself, no matter what they say." Sting _______________________________________________ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list
