Hi,
Ooops the first patch to packet-sip.c to remove a space before the boundary parameter was faulty, I have
now corrected it.
Enclosed is a patch against the latest packet-sip.c in CVS.
I'll check in the change tonight or tomorrow, as I can't do it from work.
Best regards
Anders
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.
Attachment:
sip.diff
Description: Binary data
