Sorry guys, i thought i sent this email only to Stefan.... It is just a summup of what previous email.
-Raphael. Raphael Coeffic wrote: > 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 > _______________________________________________ Semsdev mailing list [email protected] http://lists.iptel.org/mailman/listinfo/semsdev
