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 > > > Alexander Agranovsky wrote: >> Aside from the ability to integrate multipart bodies, it'd be >> cleaner, IMHO. >> So, I could see PJSUA (or a new layer between it and INV layer) >> implementing Offer/Answer model, but call state layer probably should >> not bother with such mundane details as media negotiation, SDP format >> etc ;-) In the extreme, one should be able to run INVITE session >> without message body specified at all. >> >> - Alex >> >> On Nov 4, 2007, at 6:40 AM, Benny Prijono wrote: >> >>> Alexander Agranovsky wrote: >>>> Benny, >>>> >>>> What would it take to make "inv" layer to not put any attention to >>>> SDP? E.g. it'd help to be able to send INVITE/response to INVITE >>>> with >>>> a blob of text as a body, and not have invite session object >>>> drop the >>>> call, because it notices that there's no SDP associated with it. >>> The invite session layer is coupled pretty tightly with SDP since I >>> think that's what invite abstraction is supposed to do. So it would >>> probably take significant effort to decouple them. Why do you want >>> this? >>> >>> cheers, >>> -benny > > > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip at lists.pjsip.org > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
