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

["Olivier Biot" <ethereal@xxxxxxxxxx>]

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.