Re: Should payload dissectors' (RTP) packets depend on call-setup dissectors' (SIP) packets?

[Anders Broman <a.broman () bredband net>]

Jeff Morriss skrev 2012-06-01 22:13:
> Are you saying that the correct frame is currently not tagged or that 
> it may not always be or...?
(Simplified) In SIP there is an offer answer model the offer contains a 
list of possible codecs and perhaps ports
The answer contains the choices acceptable by the receiver finally the 
offerer starts sending
on one of the available choices and the receiver sends on one of the 
offered channels. A RE-INVITE
could contain new choices. Currently we are setting up conversations on 
both the offer and answer I think.
This causes misinterpretation of the RTP content at times.
Regards
Anders
> I suppose I should find a sample capture and try it out.
>
> Anyway: good idea, bad idea?
>
> Jaap Keuter wrote:
> > Hi,
> >
> > Yes, that setup frame should be sufficient. The problem now is that 
> > not the correct setup frame is tagged, but that is another matter. 
> > Point is case is the SIP/SDP packet defining the conversation, to 
> > which the RTP dissector is set.
> > Thanks,
> > Jaap
> >
> > Send from my iPhone
> >
> > On 1 jun. 2012, at 20:44, Jeff Morriss <jeff.morriss.ws () gmail com> 
> > wrote:
> >
> > > One of the more frequently asked questions/reported bugs is users 
> > > filtering for RTP, saving^W exporting those displayed packets, then 
> > > opening the new capture file only to find plain UDP.  This is 
> > > because the call-setup protocol (e.g., SIP) wasn't included in the 
> > > display filter.
> > >
> > > Now we have the ability to mark frames as dependent on others.  
> > > Should, for example, RTP frames mark the call-setup frames as 
> > > dependencies?  (I noticed that RTP has a Setup Frame field; would 
> > > one frame really be enough?)
> > > ___________________________________________________________________________ 
> > >
> > > Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
> > > Archives:    http://www.wireshark.org/lists/wireshark-dev
> > > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
> > >            
> > > mailto:wireshark-dev-request () wireshark org?subject=unsubscribe
> > ___________________________________________________________________________ 
> >
> > Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
> > Archives:    http://www.wireshark.org/lists/wireshark-dev
> > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
> >              
> > mailto:wireshark-dev-request () wireshark org?subject=unsubscribe
>
> ___________________________________________________________________________ 
>
> Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
> Archives:    http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>             
> mailto:wireshark-dev-request () wireshark org?subject=unsubscribe

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
            mailto:wireshark-dev-request () wireshark org?subject=unsubscribe