[pjsip] Getting "inv" layer to not maintain SDP

Alexander Agranovsky alex at voxeo.com
Wed Nov 7 11:42:19 EST 2007


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





More information about the pjsip mailing list