On Wed, May 6, 2009 at 8:32 PM, Ruud Klaver <ruud at ag-projects.com> wrote: > > 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. > > I'm thinking that the transaction object should be responsible for this. So while the app doesn't send final response, the transaction should retransmit last provisional response every 1 minute. I don't think you have any complaints with this approach. :) cheers Benny -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20090512/1ae5107e/attachment.html>
