[asterisk-commits] mmichelson: branch group/pimp_my_sip r379087 - /team/group/pimp_my_sip/res/

[SVN commits to the Asterisk project]

Author: mmichelson
Date: Mon Jan 14 16:57:11 2013
New Revision: 379087

URL: http://svnview.digium.com/svn/asterisk?view=rev&rev=379087
Log:
Start filling in the on_rx_request method for the session module.

At this point, the most that can happen is that the INVITE will come in
and we'll print a NOTICE level message saying that we got the INVITE.

This can't be tested yet because res_sip does not set up any transports,
meaning that the PJSIP endpoint cannot listen for incoming SIP requests
anywhere.

A good idea would be to set up a hard-coded transport for now until configuration
comes into play.


Modified:
    team/group/pimp_my_sip/res/res_sip_session.c

Modified: team/group/pimp_my_sip/res/res_sip_session.c
URL: http://svnview.digium.com/svn/asterisk/team/group/pimp_my_sip/res/res_sip_session.c?view=diff&rev=379087&r1=379086&r2=379087
==============================================================================
--- team/group/pimp_my_sip/res/res_sip_session.c (original)
+++ team/group/pimp_my_sip/res/res_sip_session.c Mon Jan 14 16:57:11 2013
@@ -300,10 +300,56 @@
 	return PJ_SUCCESS;
 }
 
+static void handle_new_invite(pjsip_rx_data *rdata)
+{
+	/* The goal here is to create SIP work and throw it into
+	 * the threadpool. The threadpool callback will deal with
+	 * actually creating a new session and all the other bells
+	 * and whistles
+	 */
+	/* XXX STUB */
+	return;
+}
+
+/*!
+ * \brief Called when a new SIP request comes into PJSIP
+ *
+ * This function is called under two circumstances
+ * 1) An out-of-dialog request is received by PJSIP
+ * 2) An in-dialog request that the inv_session layer does not
+ *    handle is received (such as an in-dialog INFO)
+ *
+ * In all cases, there is very little we actually do in this function
+ * 1) For requests we don't handle, we return PJ_FALSE
+ * 2) For new INVITEs, throw the work into the SIP threadpool to be done
+ *    there to free up the thread(s) handling incoming requests
+ * 3) For in-dialog requests we handle, we defer handling them until the
+ *    on_inv_state_change() callback instead (where we will end up putting
+ *    them into the threadpool).
+ */
 static pj_bool_t session_on_rx_request(pjsip_rx_data *rdata)
 { 
-	/* XXX STUB */
-	return PJ_FALSE;
+	pjsip_dialog *dlg = pjsip_rdata_get_dlg(rdata);
+	pj_bool_t res = PJ_FALSE;
+	switch (rdata->msg_info.msg->line.req.method.id) {
+	case PJSIP_INVITE_METHOD:
+		if (dlg) {
+			ast_log(LOG_WARNING, "on_rx_request called for INVITE in mid-dialog?\n");
+			break;
+		}
+		ast_log(LOG_NOTICE, "INVITE request received by session module!\n");
+		handle_new_invite(rdata);
+		res = PJ_TRUE;
+		break;
+	case PJSIP_OTHER_METHOD:
+		/* Area for INFO and REFER, possibly other methods */
+		res = PJ_TRUE;
+		break;
+	default:
+		break;
+	}
+
+	return res;
 }
 
 static void session_on_tsx_state(pjsip_transaction *tsx, pjsip_event *event)