On Fri, May 22, 2009 at 12:15 AM, Giorgio Bongiorni <g.bongiorni at selta.it>wrote: > Hi Benny and all, > I'm trying to implement a simple UAS to handle incoming INVITE requests. I > first create the uas dialog, the sdp session and the invite uas session. At > this point, I've obtained these logs: > > 16:52:12.651 sip_endpoint.c Processing incoming message: Request msg > INVITE/cseq=101 (rdata0x9a86694) > 16:52:12.651 tsx0x9a94bdc Transaction created for Request msg > INVITE/cseq=101 (rdata0x9a86694) > 16:52:12.651 tsx0x9a94bdc Incoming Request msg INVITE/cseq=101 > (rdata0x9a86694) in state Null > 16:52:12.651 tsx0x9a94bdc State changed from Null to Trying, > event=RX_MSG > 16:52:12.651 dlg0x9a943d4 Transaction tsx0x9a94bdc state changed to > Trying > 16:52:12.651 dlg0x9a943d4 UAS dialog created > 16:52:12.651 dlg0x9a943d4 Module mod-invite added as dialog usage, > data=0x9a956a0 > 16:52:12.651 dlg0x9a943d4 Session count inc to 2 by mod-invite > 16:52:12.651 inv0x9a943d4 UAS invite session created for dialog > dlg0x9a943d4 > > Now, if I want to send a 100 Trying provisonal response, I have to call the > "pjsip_inv_initial_answer" function (or something like that). But, from > RFC3261 - section 17.2.1: " When a server transaction is constructed for a > request, it enters in the "Proceeding" state. The server transaction MUST > generate a 100 (Trying) response unless it knows that the TU will generate a > provisonal or a final response within 200ms [...] This provisonal response > is needed to quench retransmission rapidily in order to avoid network > congestion". Despite that, I've noticed that the transaction we create is > not in the Proceeding state (it enters only after the > pjsip_inv_initial_answer call): > > 17:01:53.384 endpoint Response msg 100/INVITE/cseq=101 > (tdta0x8d0afc8) created > 17:01:53.384 dlg0x8d083d4 Initial answer Response msg > 100/INVITE/cseq=101 (tdta0x8d0afc8) > 17:01:53.384 inv0x8d083d4 Sending Response msg 100/INVITE/cseq=101 > (tdta0x8d0afc8) > 17:01:53.384 dlg0x8d083d4 Sending Response msg 100/INVITE/cseq=101 > (tdta0x8d0afc8) > 17:01:53.384 tsx0x8d08bdc Sending Response msg 100/INVITE/cseq=101 > (tdta0x8d0afc8) in state Trying > 17:01:53.384 sip_resolve.c Target '10.13.0.104:5060' type=UDP resolved > to '10.13.0.104:5060' type=UDP (UDP transport) > 17:01:53.384 tsx0x8d08bdc State changed from Trying to Proceeding, > event=TX_MSG > 17:01:53.384 dlg0x8d083d4 Transaction tsx0x8d08bdc state changed to > Proceeding > 17:01:53.384 myapp.c Call state changed to INCOMING > > I think this might be wrong. What happens if I wait before creating the > provisonal response? Don't you think it would be better to automatically > generate the 100 Trying response as soon as possible (e.g. inside the > pjsip_inv_create_uas) and then give the control back to the user? > > At pjsip level (not pjsua-lib), the stack doesn't know what the appropriate action for the INVITE would be. It could be that the application would automatically respond with 180, or even reject the call if the user is busy. Hence it's not so wise to automatically respond it with 100, at the very least that would be a waste of packet. So yes, as application programmer you need to tell it exactly what to send initially. I don't think there's nothing wrong here, unless if you decide not to send anything. At pjsua-lib level, the library has more knowledge about application state (e.g. if user is busy), so it will send 100 automatically. cheers Benny > Thanks, > Giorgio > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip at lists.pjsip.org > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20090522/dd6fec74/attachment.html>
