Thanks for the input. Yes, parsing and encoding function is called in the transport layer. But I'm not sure if multipart should be handled in this layer though, because transport layer does not need to care about the message body content. IMO this is good for efficiency (for example, proxies do not care about message body), so I'd like to keep it that way. On the other hand, I do understand that multipart functionality may be needed by several modules (not just invite), so it is desirable to implement it somewhere where it is easily accessible and reused, and the "core" pjsip layer (the parsing and encoding layer) is indeed one of such place where this could be done. So it's quite a dilemma. -benny Alexander Agranovsky wrote: > Lets see here ;-) > > a) yes > b) I'd say, let transport layer (or whoever actually parses the > message ... I think it's transport, right?) parse the message and > store all the body parts (including SDP) as a set of strings (content > type, content length, content encoding, actual string). Then the next > layer will parse/process the SDP body as it does now. > c) do pretty much the same for TX message ... enable adding a set of > structs to pjsip_tx_data, which, if provided, will be used along with > the SDP struct built by the stack to send the message. > > Think that'd be feasible? > > - Alex > > On Nov 6, 2007, at 7:42 PM, Benny Prijono wrote: > >> I knew you're going to mention multipart. ;-) >> >> I had considered separating the invite layer from SDP offer/answer >> logic, but I chose not to mainly for simplicity. We have too many >> layers already with pjsip, so another abstraction will make pjsip >> even more complicated then it should. Especially since for invite >> session, invite session will *always* be tied up with SDP offer >> answer, so it sounds logical to put them on the same module. And >> maintaining offer/answer is not easy, believe me. Maybe it is with >> the simplest INVITE, but when you put in late offer, UPDATE, and >> PRACK, things become hairy! So the invite session tries to help >> easing the burden of maintaining this as much as possible for >> application. >> >> As for multipart bodies, my thought was to make something like this: >> a) have the capability to encode/decode multipart body in >> pjlib-util, >> b) on incoming message with body, have the invite session decode >> the multipart body and only inspect and process the SDP part, >> c) somehow add capability to send multipart body with invite >> session. The invite session will again only inspect the >> SDP part of the body. >> >> What do you think? >> >> -benny
