On Tue, May 5, 2009 at 7:59 PM, Ruud Klaver <ruud at ag-projects.com> wrote: > 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. It's just that as it is now, it doesn't do what it says in the tin. The callback should be called on each incoming reinvite, and that should be it. Obviously application needs to handle the case when there's no offer in the request. > 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. > > To be precise, what happens now is (when re-INVITE or UPDATE without SDP is received) the on_create_offer() callback is called, if application implements it. If not, then it proceeds as you described above. 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. > > Thanks. I just attached it in the ticket for future reference. > > 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. > > IMO ending the invite session on 408/481 is (still) the right thing to do. The real problem here is pjsip doesn't retransmit the 180. According to the spec, proxy may terminate (INVITE) transaction after it sees provisional response if it doesn't see further responses within 3 minutes, hence UAS must retransmit (last sent) provisional response every 1 minute. Currently we don't do that. I just added https://trac.pjsip.org/repos/ticket/822 to fix this in 1.3. > > > 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. > > You're probably right, I don't suppose we handle that since originally we respond to re-INVITE immediately. I attached the patch to the ticket. > > > 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. > > The *are* useful, many thanks indeed! cheers Benny > Ruud Klaver > AG Projects > _______________________________________________ > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20090506/fbf58c26/attachment.html>
