Na? kein plan? Die wahl ist eingentlich nur zwischen zwei (drei) alternativen:
1) Es gibt einen allgemeinen Timer in sipctrl, der gestartet wird, sobald wir eine provisional reply bekommen. 2) Der Timer wird von der anwendung selber gesetzt, und die anwendung sender auch selbstständig einen CANCEL falls zu lange gewartet wurde. 3) sipctrl hat einen default timer, der aber von der anwendung auch gesetzt werden kann (für jede INVITE transaction). (Pb: die ctrl plug-in API gibt es nicht her...) Was meinst du??? -Raphael. Raphael Coeffic wrote: > Houston.... we have a problem! > > So here is the issue for which i am looking for a solution: > > Let's SEMS sends an INVITE out for which it receives a 100 or 183 very > quickly. Now the transaction state is switched to "Proceeding". The > issue is that the RFC does not specify any timer for this state. So, if > the UAS on the other never send a final reply, we will wait for ever... > > So the question is: should it be useful to let the application choose > how long it would wait for a final reply? And if a each 1xx reply would > reset this timer or not? I heard of some SNOM phones sending 180 very > few seconds for ever if the user never picks up the phone. > > If the timer hits, we are supposed to send a CANCEL. Should it be sent > by the sipctrl plugin? I believe yes... in which case the app would just > get the final for the INVITE (if the phone is still alive) or a locally > generated 408. > > Any thoughts/proposals on that? > > -Raphael. > _______________________________________________ > Semsdev mailing list > [email protected] > http://lists.iptel.org/mailman/listinfo/semsdev > _______________________________________________ Semsdev mailing list [email protected] http://lists.iptel.org/mailman/listinfo/semsdev
