["Venna, Nagarjuna" <nvenna@xxxxxxxxxxx>]

Just because an implementation does something, that doesn't make it right.

I tried to write a SDP parser as specified in RFC 2327 and I'm yet to see a
single SDP that would parse correctly if the parser strictly implements the
RFC. What Ethereal was doing was to show attributes in the right place as
misplaced and all I tried to do is fix that with minimal code changes. I
agree with you that all one would care about is whether an attribute is a
session level attribute or a media level attribute, butI also think Ethereal
should not show a correctly written SDP as having "misplaced" attributes.

Thanks


-----Original Message-----
From: Guy Harris [mailto:gharris@xxxxxxxxx]
Sent: Thursday, August 22, 2002 5:18 PM
To: Venna, Nagarjuna
Cc: 'ethereal-dev@xxxxxxxxxxxx'
Subject: Re: [Ethereal-dev] SDP Fix


On Sun, Aug 18, 2002 at 02:38:01PM -0700, Guy Harris wrote:
> Well, unfortunately for some simple SDP parsers, I've seen a capture of
> a Quicktime session where we have

And, in fact, I just now went to

	http://www.uwc.ca/racerock/video4.htm

and the SDP session for the live Quicktime video feed there has no time
information whatsoever:

Session Description Protocol
    Session Description Protocol Version (v): 0
    Session Name (s): Live Channel
    Session Attribute (a): x-qt-text-nam:racerocks.com, camera 4
        Session Attribute Fieldname: x-qt-text-nam
        Session Attribute Value: racerocks.com, camera 4
    Session Attribute (a): x-qt-text-des:webcast from Race Rocks using Live
Channel
        Session Attribute Fieldname: x-qt-text-des
        Session Attribute Value: webcast from Race Rocks using Live Channel
    Session Attribute (a): x-qt-text-cmt:2002, Lester B. Pearson College
        Session Attribute Fieldname: x-qt-text-cmt
        Session Attribute Value: 2002, Lester B. Pearson College
    Session Attribute (a): x-qt-text-cpy:Garry Fletcher and students of
rr.com activity
        Session Attribute Fieldname: x-qt-text-cpy
        Session Attribute Value: Garry Fletcher and students of rr.com
activity
    Session Attribute (a): x-qt-text-swr:Live Channel Pro 1.3.2b5
        Session Attribute Fieldname: x-qt-text-swr
        Session Attribute Value: Live Channel Pro 1.3.2b5
    Connection Information (c): IN IP4 0.0.0.0
        Connection Network Type: IN
        Connection Address Type: IP4
        Connection Address: 0.0.0.0
    Session Attribute (a): control:*
        Session Attribute Fieldname: control
        Session Attribute Value: *
    Media Description, name and address (m): audio 0 RTP/AVP 100 
        Media Type: audio
        Media Port: 0
        Media Proto: RTP/AVP
        Media Format: 100
        Media Format: 
    Media Attribute (a): rtpmap:100 X-QT/22050
        Media Attribute Fieldname: rtpmap
        Media Attribute Value: 100 X-QT/22050
    Media Attribute (a): control:trackID=1
        Media Attribute Fieldname: control
        Media Attribute Value: trackID=1
    Media Description, name and address (m): video 0 RTP/AVP 99 
        Media Type: video
        Media Port: 0
        Media Proto: RTP/AVP
        Media Format: 99
        Media Format: 
    Media Attribute (a): rtpmap:99 X-QT/600
        Media Attribute Fieldname: rtpmap
        Media Attribute Value: 99 X-QT/600
    Media Attribute (a): control:trackID=2
        Media Attribute Fieldname: control
        Media Attribute Value: trackID=2
    Media Attribute (a): x-bufferdelay:8
        Media Attribute Fieldname: x-bufferdelay
        Media Attribute Value: 8

> 
> 	v=0
> 	s={session name}
> 	u={URL}
> 	e={email address}
> 	c={connection information}
> 	a=contro:/
> 	a=x-qt-text-cpy:Copyright 1997-1998 Apple Computer, Inc.
> 	a=range:npt=0-   0.06667
> 	m=video 0 RTP/AVP 96
> 	a=rtpmap:96 X-Q^/600
> 	a=control:trackID=2
> 
> with no time description whatsoever.  Perhaps some device between the
> client and server deleted them, perhaps because they indicated that it
> was an unbounded, permanent session and they mistakenly removed it, or
> perhaps because there was a bug, but I don't consider that sufficient
> reason to mark them as misplaced items rather than session attributes
> (a simple parser doesn't *need* to keep track of whether there's a time
> description - it could just switch from parsing session descriptions to
> media descriptions based on whether it'd seen an m= entry or not, as per
> my comment about how Ethereal could handle this).
> 
> So I'm not going to have the SDP dissector report those a= entries as
> "misplaced".
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
>