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)>>
