Hi Benny, On 19 Jan 2009, at 22:33, Benny Prijono wrote: > Okay, I think I got a clearer picture now. So if the app doesn't > implement on_rx_reinvite() callback, this is the flow when a re- > INVITE is received: > > - on_rx_offer() is called > - app calls pjsip_inv_set_sdp_answer() inside the callback > - pjsip negotiates the SDP, and calls on_media_update() callback > - pjsip sends 200/OK response automatically with the negotiated > answer > > When the callback is implemented, the flow changes: > > - on_rx_reinvite() is called > - app calls pjsip_inv_answer() with SDP initial answer > - pjsip negotiates the SDP and calls on_media_update() callback > - app calls pjsip_inv_send_msg() with the negotiated answer > > I'm hesitating a bit because of the flow changes, but this looks > reasonable and I can't see any alternatives either, and you've done > good job with the doxygen comments which should explain this flow > change. Fro the code in sip_inv.c and what code I have so far in my application, this indeed seems to be the correct code flows. Personally I like that it follows the same flow as the original INVITE, but there is some asymmetry with regards to the UPDATE. Also, depending on which callback is set, the behaviour is quite different (correct me if I'm wrong): - When on_rx_offer() and on_rx_reinvite() are both NOT set, both UDPATEs and re-INVITEs are responded by PJSIP with the last current SDP. - When on_rx_offer() is set and on_rx_reinvite() is NOT set, on_rx_offer() will get called for both UPDATEs and re-INVITEs (this maintains backwards compatibility, yay). - When on_rx_offer() is NOT set and on_rx_reinvite() is set, on_rx_reinvite() will get called for an incoming re-INVITE, but an incoming UPDATE will be replied to automatically with the latest local SDP - When on_rx_offer() and on_rx_reinvite() are both set, on_rx_reinvite() will get called for an incoming re-INVITE, but on_rx_offer() will get called for an incoming UPDATE. Although this behaviour is a bit obtuse, I think it is correct and maintains backwards compatibility. I think it is desired as long as it is properly documented. > >>Also what about UPDATE? :) > > >Ah, good question. I spent some time thinking about this when > making the change to the code, but in the end this functionality is > not required for UPDATE, as it requires and immediate >response > according to the RFC. This is why, for an incoming UPDATE, > on_rx_offer() is still called. > > > You're right. Right I think I can take this on board. Last but not > least, since this is quite a significant piece of code, would you > mind following up http://trac.pjsip.org/repos/wiki/ContributionAgreement? > It's one of the thing that we have to do unfortunately. :) > > thanks > Benny I will have my employer look over the agreement. Ruud Klaver AG Projects
