No convention exists.
Just doint what makes most sense to the person writing the dissector and
experienced users.
Making these synthetic fields visible will make ordinary users learn that
the fields exist since they can see them
in the dissect pane.
That allows them then to create filters based on those fields.
----- Original Message -----
From: "Martin Mathieson"
Sent: Monday, April 19, 2004 9:48 PM
Subject: Re: [Ethereal-dev] [PATCH] SIP hidden fields for finding errors
> Can you point me at examples of this? Is there a convention to follow (I
> notice that TCP has a SEQ/ACK tree at the end) ?
>
> I've gotten used to adding hidden fields to my own private dissectors, so
> obviously I know they're there :)
>
>
> ----- Original Message -----
> From: "Ronnie Sahlberg" <ronnie_sahlberg@xxxxxxxxxxxxxx>
> To: "Ethereal development" <ethereal-dev@xxxxxxxxxxxx>
> Sent: 19 April 2004 12:32
> Subject: Re: [Ethereal-dev] [PATCH] SIP hidden fields for finding errors
>
>
> > Why add these as hidden fields?
> >
> > A lot of other dissectors add flags for duplicate detection and also
error
> > conditions and
> > make them visible in the dissect tree.
> > This makes it easier for users to see that the fields exist and that
they
> > can filter on them.
> > (Menu:Match/Selected works)
> >
> > Why not add these fields to the dissect tree as visible fields?
> >
> >
> > ----- Original Message -----
> > From: "Martin Mathieson"
> > Sent: Monday, April 19, 2004 9:16 PM
> > Subject: [Ethereal-dev] [PATCH] SIP hidden fields for finding errors
> >
> >
> > > The attached patches add 2 hidden display filters for SIP - namely:
> > > (1) sip.error (for all responses with code >= 300)
> > > (2) sip.resend (for all packets that appear to have been
> retransmitted).
> > A
> > > field showing a count of these is shown in the SIP stats window.
> > >
> > > These filters make it much easier to zero in on problems in large
> captures
> > > (e.g. bulk call tests) evident from the SIP stats window.
> > >
> > > (1) is straightforward, and needed because the response code is
regarded
> > as
> > > a string, so its not easy to write your own expression
> > >
> > > (2) is more involved, and I would like to hear from other SIP users
> about
> > > this addition. Some notes:
> > > - Only considers UDP packets
> > > - Hash table contains (call_id, source_addr, dest_addr) -> (cseq,
> > > simplified transaction_state).
> > > An earlier version used proper conversations but the call-id is the
most
> > > important part of the key. Addresses are still needed for when e.g.
> more
> > > than one leg of a proxied call is in the same capture.
> > > - Size of hash table key and value memchunks (as number of elements)
> are
> > > settable as a SIP property so as not to waste memory but to still
allow
> > > large values
> > >
> > > Regards,
> > > Martin
> > >
> >
> >
>
> --------------------------------------------------------------------------
> --
> > ----
> >
> >
> > > _______________________________________________
> > > Ethereal-dev mailing list
> > > Ethereal-dev@xxxxxxxxxxxx
> > > http://www.ethereal.com/mailman/listinfo/ethereal-dev
> > >
> >
> > _______________________________________________
> > Ethereal-dev mailing list
> > Ethereal-dev@xxxxxxxxxxxx
> > http://www.ethereal.com/mailman/listinfo/ethereal-dev
>
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
>