RE: [Ethereal-dev] Changes for sip-t decoding

["Anders Broman (AL/EAB)" <anders.broman@xxxxxxxxxxxx>]

Hi,
As you may know the ISUP message is wrongly coded, no CIC should be included not even zero, see abstract from RFC below,
If I interprete your packet-multipart "patch" correctly, it would accept leading spaces before the boundary string, this is not according to the RFC,
e,g RFC 2046 page 17 " The boundary delimiter MUST occure at the begining of a line....".

http://www.ietf.org/rfc/rfc3204.txt
--- snip ---

3.1 ISUP Media Type

   This media type is defined by the following information:

   Media type name: application
   Media subtype name: ISUP
   Required parameters: version
   Optional parameters: base
   Encoding scheme: binary
   Security considerations: See section 5.

   The ISUP message is encapsulated beginning with the Message Type Code
   (i.e., omitting Routing Label and Circuit ID Code).
--- snip ---
Best regards
Anders

-----Original Message-----
From: ethereal-dev-bounces@xxxxxxxxxxxx [mailto:ethereal-dev-bounces@xxxxxxxxxxxx]On Behalf Of Chernishov Yury
Sent: den 1 april 2004 05:35
To: 'ethereal-dev@xxxxxxxxxxxx'
Subject: [Ethereal-dev] Changes for sip-t decoding


Hello!
I'm working on SIP-T testing now and I see, that ethereal decoding of this
protocol doesn't works <<packet-isup.c>>  <<packet-multipart.c>>  
<<packet-sip.c>> 
correct. I send you my changes and some traces. 
If in is necesary - I can answer on any question about reason of changes.

I don't now exactly ethereal development procedure,
can you explain me this? 
I can work on sip-t decoding in future also!

Best regards!
Chernishov Yury,
Telecommunication testing team manager,
IskraUralTel,
Ekaterinburg, Russia.




 <<IP_Phone(SSW1)_IP_Phone(SSW2)>>