|
Hi Yury,
The MIME multipart dissector Anders and
myself have contributed is RFC compliant, and contains its operation mode in the
comment section at the top of the source file:
* General format of a MIME multipart
document:
* [ preamble line-end ]
* dash-boundary transport-padding
line-end
* body-part
* *encapsulation
* close-delimiter
transport-padding
* [ line-end epilogue ]
*
* Where:
* dash-boundary := "--" boundary
* encapsulation := delimiter transport-padding line-end
body-part
* delimiter :=
line-end body-part
* close-delimiter := delimiter "--"
* body-part :=
MIME-part-headers [ line-end *OCTET ]
* transport-padding := *LWSP-char
*
* Note that line-end is often a LF instead of a CRLF.
As you can see, you MUST add a line-end
sequence if you add bytes *before* the first boundary sequence. Should you not
do so, then you cannot detect the end of your preamble! Also note that you MUST
NOT add a line-end sequence after the final boundary sequence... unless you want
to transmit an epilogue.
Regards,
Olivier
----- Original Message -----
From:
Chernishov Yury
| Hello!
|
| I check my implementation of SIP
client.
| You completely right, that it was error in our code!
| That's
mean, that ethereal works o'k with SIP header.
| Now I check second problem
(error with boundary).
|
| Best Regards!
| Yury.
|
|
|
-----Original Message-----
| From: Anders Broman
|
| Hi,
| I
checked in a change to packet-sip.c to remove any spaces before the
|
parameter in the line ( space after ; ) :
| Content-type: multypart/mixed ;
boundary....
| Are you saying this didn't work ? I coundn't test it as packet
3 in your
| trace isn't decoded because of the wrongly coded(?) SIP URI.
|
Could you apply your changes to the latest CVS version of packet-sip.c and
|
try it, or send a diff -u file and I could try it out.
|
| Best
regards
| Anders
|
| -----Original Message-----
| From: Chernishov
Yury
|
| Hi!
|
| Does SIP-T part works for you? I mean
multupart/mixed dissection.
| As far as I can judge, packet-multupart.c
receive wrong data
| from packet-sip.c about "boundary" value
| (the
problem is "space" character before "bondary" value)!
| Therefore
packet-multipart.c can not separate
| different multipart from each other
correctly!
|
| Can somebody send me trace for ethereal, if it works for
you?
|
|
|
|
| -----Original Message-----
| From: Jeff
Morriss|
| Anders Broman (AL/EAB) wrote:
|
| > Hi,
| > Note
that this is only affecting SIP-T.
| > With the present code a line in the
GUI containing a SIP/application/isup
| would look like :
| >
| > 13 0.302286 10.28.2.11 10.28.1.11 SIP/ISUP Status:
183 Session
| Progress, ISUP:reserved
| > Without "ISUP" it'd look
:
| >
| > 13 0.302286 10.28.2.11 10.28.1.11
SIP/ISUP Status: 183 Session
| Progress, reserved
| >
| > I
thought with the former it was clearer that "reserved" belonged to the
| ISUP
dissection rather than to SIP.
| > But feel free to change it if you like,
I have no strong preferenses
| either way.
|
| Oops, my bad. I
thought this change was in 'dissect_isup()', not in
|
'dissect_application_isup()' (I keep forgetting that there are multiple
|
entry points in the ISUP dissector). Sorry for the
noise.
|