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
