Hi Benny, On 01 May 2009, at 16:45, Benny Prijono wrote: > On Fri, Apr 24, 2009 at 1:17 PM, Ruud Klaver <ruud at ag-projects.com> > wrote: > > I've also noticed another problem, which is sending a negative reply > to a re-INVITE. This is only possible the on_rx_reinvite patch I > sent to this list some time ago. PJSIP does not seem to handle this > well, since the SDP negotiator gets stuck in the REMOTE_OFFER state > and there is no way to cancel that. Personally I decided to just not > send negative replies to re-INVITEs, since I can work around that, > but it could be worth while to remember. > > > First of all, I just added this in the 1.3 roadmap: http://trac.pjsip.org/repos/ticket/817 > > You're right about the REMOTE_OFFER state above, so I attached in > the ticket a patch which adds new API to the SDP negotiator to > cancel the REMOTE_OFFER state. The invite session would need to call > this if application sends non-2xx response for the re-INVITE. > > I was ready to commit these patches, then I realized that we put the > on_reinvite() callback inside inv_check_sdp_in_incoming_msg(), which > means that the callback is only called when the re-INVITE contains > SDP. I think this is not right, don't you think? That's why I'm > deferring this for next next release, since we're pretty close to > release now. Sorry about that. > > thanks > Benny Thanks for committing the patch I submitted. As a user of sip_inv, I don't really see a case where I want to be informed of an incoming re-INVITE without SDP. In fact, I think the course of action after applying this patch is the following, the last negotiated SDP is sent. When the remote party sends and ACK with SDP in response, the on_media_update is called with the newly negotiated SDP. Note that I am not entirely sure this happens, as I have no way to test it, I have nothing that sends an empty re-INVITE. In any case, I think this is the desired behaviour. That's for supplying that patch to cancel a REMOTE_OFFER, I've included "pjsip-2553-sip_inv- cancel_sdp_neg_on_sending_negative_reply_to_reinvite.patch", which makes use of this patch by canceling the remote SDP proposal when giving a negative reply to a re-INVITE. Perhaps you could review it and include it in the ticket. -------------- next part -------------- A non-text attachment was scrubbed... Name: pjsip-2553-sip_inv-cancel_sdp_neg_on_sending_negative_reply_to_reinvite.patch Type: application/octet-stream Size: 584 bytes Desc: not available URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20090505/a0ffbf14/attachment.patch> -------------- next part -------------- It's probably good if you don't include this in the latest release, as there are still some issues with re-INVITEs. I took some time to investigate and try to fix them. I've included another two patches for this purpose. I've noticed that whenever you receive a 408 or 481 response with the INVITE dialog, you end the INVITE session. This is indeed what the RFC prescribes, but I've found that ending the session when receiving a 408 in response to a re-INVITE is probably not desired behaviour. What I'm doing in our application is sending a 180 in response to a re- INVITE and presenting a prompt to the user whenever a stream gets added in the SDP. Now if the user is away or not paying attention, the SIP proxy will send a 408 to the sender of the re-INVITE, which will terminate the session. I don't think this is what should happen, so I've included "pjsip-2553-sip_inv- dont_disconnect_on_408_reply_to_reinvite.patch", which doesn't terminate the INVITE session on a 408 if the state is CONFIRMED. -------------- next part -------------- A non-text attachment was scrubbed... Name: pjsip-2553-sip_inv-dont_disconnect_on_408_reply_to_reinvite.patch Type: application/octet-stream Size: 687 bytes Desc: not available URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20090505/a0ffbf14/attachment-0001.patch> -------------- next part -------------- In the same scenario the proxy sends a CANCEL to the recipient of the re-INVITE. PJSIP doesn't seem to associate the incoming CANCEL with the re-INVITE transaction and does not terminate it. Calling inv_respond_incoming_cancel(), which is used for the original INVITE, seems to do the right thing. "pjsip-2553-sip_inv-terminate-reinvite- tsx-on-cancel.patch" does this in this situation. -------------- next part -------------- A non-text attachment was scrubbed... Name: pjsip-2553-sip_inv-terminate-reinvite-tsx-on-cancel.patch Type: application/octet-stream Size: 780 bytes Desc: not available URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20090505/a0ffbf14/attachment-0002.patch> -------------- next part -------------- Of course, these patches should just be taken as suggestions for improvement. I hope you can review them and find them useful. Thanks in advance. Ruud Klaver AG Projects
