On Tue, May 19, 2009 at 2:35 AM, Ruud Klaver <ruud at ag-projects.com> wrote: > Hi Benny, > > On 12 May 2009, at 20:27, Benny Prijono wrote: > >> >>>> 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 >> > > I informed about this and it would seem that SIP proxies don't always > behave as you assume in this case. In fact, in OpenSIPS it's a setting if > provisional responses should reset the timeout timer. So your proposed > solution may not always work. > > Aw, it's a problem then. But rather than this is a proposed solution, actually this is something that we need to fix in order to comply with the spec. RFC 3261 is pretty clear about this: The requirement to terminate dialog on 408/481: 12.2.1.2 If the response for a request within a dialog is a 481 (Call/Transaction Does Not Exist) or a 408 (Request Timeout), the UAC SHOULD terminate the dialog. A UAC SHOULD also terminate a dialog if no response at all is received for the request (the client transaction would inform the TU about the timeout.) While the proxy behavior to reset the timeout timer upon receiving provisional response is in: 16.6 11. Set timer C In order to handle the case where an INVITE request never generates a final response, the TU uses a timer which is called timer C. Timer C MUST be set for each client transaction when an INVITE request is proxied. The timer MUST be larger than 3 minutes. Section 16.7 bullet 2 discusses how this timer is updated with provisional responses, and Section 16.8 discusses processing when it fires. and 16.7: 2. Update timer C for provisional responses For an INVITE transaction, if the response is a provisional response with status codes 101 to 199 inclusive (i.e., anything but 100), the proxy MUST reset timer C for that client transaction. The timer MAY be reset to a different value, but this value MUST be greater than 3 minutes. So spec wise, we know what to do (right?) :) cheers Benny -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20090519/1128f02b/attachment.html>
