Hi Benny, Sorry about the late reply... On 18 Jul 2008, at 11:00, Benny Prijono wrote: > On Thu, Jul 17, 2008 at 6:22 PM, Ruud Klaver <ruud at ag-projects.com> > wrote: > Hi, > > I'm in the process of writing an application that uses PJSIP and > should have a greater degree of control over the SDP by manually > generating the structs involved and passing them to PJSIP. This holds > for an original INVITE as well as for re-INVITEs. > > > Okay. > > I was looking at how re-INVITEs are handled in sip_inv.c and from what > I could see the callback asking for a SDP response does get called > (rx_offer), but the callback needs to set a new SDP answer immediately > which is then automatically sent in a 200 OK response (or a 500 if the > > Yes. > > > SDP negotiation fails). How I would want my endpoint to behave is to > send a provisional response (180) in reply to a re-INVITE, present the > new SDP to the user somehow and wait for his/her input before sending > a SDP response in a 200 or maybe even some 4xx if the user does not > agree. The scenario for this would be useful for example for adding a > stream to an existing session. > > > Yeah currently we don't support that. With current code, re-INVITE > needs to be answered immediately. > > To support user confirmation scenario, I'm thinking that application > could just answer the re-INVITE with a provisional SDP (e.g. with > "a=recvonly") in 200, and then ask for user confirmation about the > modification, and then send re-INVITE with another SDP to activate > or deactivate the changes depending on user approval. A creative workaround, although I'm not sure all endpoints support this. Also, it does not really work when using MSRP. > My question is what is the best way to get the code in sip_inv.c to > behave in this fashion? I'm sure I could modify it to fit my needs, > but maybe there needs to be some consensus about this. Is this > behaviour wanted by more people? > > > It could be useful to implement that, so go ahead if you want to > hack it. :) > Probably the way to do it is to add new sip_inv callback specific to > handling incoming re-INVITE, and for reINVITE it will be called in > preference to on_rx_offer() if it is implemented. With this > callback, sip_inv.c won't send 500 if SDP answer is not immediately > available, and application MUST answer the re-INVITE manually. > > Cheers > Benny That sounds like a good way to do it, and it's backwards compatible as well. I won't get right on it, but I'll keep it in the back of my mind to hack this into sip_inv.c. Thanks for the reply. Ruud Klaver AG Projects
