Hi Benny, On 06 May 2009, at 13:05, Benny Prijono wrote: > 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. > Hrm. That would mean that setting on_rx_reinvite would override both on_rx_offer and on_create_offer, giving the pjsip_inv user full control over what to do on re-INVITE. Yes, that is probably a more consistent interface, although I wonder how difficult it would be to implement. Maybe I can give it a look at least. > >> 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. > That sound like a good workaround. The question is, who should be responsible for repeating the last provisional response, the pjsip_inv object or whomever is using it? I think both for the original INVITE and subsequent re-INVITEs the application could resend the provisional response itself, calling pjsip_inv functions. >> 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. Without provisional responses to re-INVITEs you would indeed not run into this situation. > > 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! Well thanks for reviewing them. ;) Ruud Klaver AG Projects
