[pjsip] Getting "inv" layer to not maintain SDP
alex at voxeo.com
Wed Nov 7 11:42:19 EST 2007
Lets see here ;-)
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?
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
> As for multipart bodies, my thought was to make something like this:
> a) have the capability to encode/decode multipart body in
> 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?
> 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:
>>>> 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
>>>> 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
> Visit our blog: http://blog.pjsip.org
> pjsip mailing list
> pjsip at lists.pjsip.org
More information about the pjsip