If I have a SIP message in a char* variable, then I assume that I can parse it into a struct sip_msg* using a function in ser. The most obvious function seems to be parse_msg(). This does not seem to work to my expectation.
Here is a code snippet (which is close to the code in receive.c):
char* response // contains my message struct sip_msg msg // this is were the result should go
memset(msg, 0, sizeof(struct sip_msg)); response[len] = 0; msg->buf = response; msg->len = len; if (parse_msg(response, len, msg))!=0) { LOG(L_ERR, "ERROR"); } LOG(L_ERR, "After parse msg ...") dump_sip_msg(msg) // this just prints the fields of the message to LOG
dump_sip_msg() works fine on the incoming sip message, so the problem is either in my SIP message or in my use of the parse function. However, I think my message is fine (it is the received message with the first line replaced with SIP/2.0 600 Policy Server Msg date time). I enclose a cut from /var/log/messages.
Stephan
/var/log/messages:
Mar 7 14:52:41 d254196 /usr/local/sbin/ser[9566]: After parse_msg... Mar 7 14:52:41 d254196 /usr/local/sbin/ser[9566]: polserv: dump_sip_msg() Mar 7 14:52:41 d254196 /usr/local/sbin/ser[9566]: msg->id: int = 0 Mar 7 14:52:41 d254196 /usr/local/sbin/ser[9566]: msg->first_line: msg_start (rep) 600 Policy Server Msg 2003-03-07 14:52:24^M Via: SIP/2.0/UDP Mar 7 14:52:41 d254196 /usr/local/sbin/ser[9566]: DEBUG: dump_hdr_field: type=1, name=Via, body=SIP/2.0/UDP 139.153.254.196:5062, parsed=0x80a584c, next=(nil) Mar 7 14:52:41 d254196 /usr/local/sbin/ser[9566]: DEBUG: dump_hdr_field: type=1, name=Via, body=SIP/2.0/UDP 139.153.254.196:5062, parsed=0x80a584c, next=(nil) Mar 7 14:52:41 d254196 /usr/local/sbin/ser[9566]: msg->parsed_flag 1 Mar 7 14:52:41 d254196 /usr/local/sbin/ser[9566]: DEBUG: dump_hdr_field: type=1, name=Via, body=SIP/2.0/UDP 139.153.254.196:5062, parsed=0x80a584c, next=(nil) Mar 7 14:52:41 d254196 /usr/local/sbin/ser[9566]: DEBUG: dump_hdr_field: field is NULL Mar 7 14:52:41 d254196 last message repeated 20 times Mar 7 14:52:41 d254196 /usr/local/sbin/ser[9566]: msg->eoh: (null) Mar 7 14:52:41 d254196 /usr/local/sbin/ser[9566]: msg->unparsed: CSeq: 7635 REGISTER^M To: "Stephan" sip:mrs@cs.stir.ac.uk^M Expires: 900^M From: "Stephan" sip:mrs@cs.stir.ac.uk^M Call-Id: 138108089@139.153.254.196^M User-Agent: KPhone/2.11^M Event: registration^M Allow-Events: presence^M Contact: "root" sip:root@139.153.254.196:5062;transport=UDP;methods="INVITE, MESSAGE, INFO, SUBSCRIBE, OPTIONS, BYE, CANCEL, NOTIFY, ACK"^M Content-Length: 0^M ^M ^M Mar 7 14:52:41 d254196 /usr/local/sbin/ser[9566]: msg->buf: SIP/2.0 600 Policy Server Msg 2003-03-07 14:52:24^M Via: SIP/2.0/UDP 139.153.254.196:5062^M CSeq: 7635 REGISTER^M To: "Stephan" sip:mrs@cs.stir.ac.uk^M Expires: 900^M From: "Stephan" sip:mrs@cs.stir.ac.uk^M Call-Id: 138108089@139.153.254.196^M User-Agent: KPhone/2.11^M Event: registration^M Allow-Events: presence^M Contact: "root" sip:root@139.153.254.196:5062;transport=UDP;methods="INVITE, MESSAGE, INFO, SUBSCRIBE, OPTIONS, BYE, CANCEL, NOTIFY, ACK"^M Content-Length: 0^M ^M ^M Mar 7 14:52:41 d254196 /usr/local/sbin/ser[9566]: msg->len: 475 Mar 7 14:52:41 d254196 /usr/local/sbin/ser[9566]: msg->parsed_uri_ok: int = 0 Mar 7 14:52:41 d254196 /usr/local/sbin/ser[9566]: polserv: all fine, returning now ... Mar 7 14:52:41 d254196 /usr/local/sbin/ser[9566]: ERROR: parse_sip_msg_uri: bad uri <600> Mar 7 14:52:41 d254196 /usr/local/sbin/ser[9566]: WARNING: do_action:error in expression
-- Dr Stephan Reiff-Marganiec Research Fellow Department of Computing Science; University of Stirling email: srm@cs.stir.ac.uk tel: 01786 46 7448
Hello,
parse_msg parses only the first line and the topmost Via. We use incremental parsing, that means header fields are parsed once they are really needed.
If you need to parse the whole message header, call parse_headers(msg, HDR_EOH, 0) after parse_msg.
In regards to your log: You seem to be processing this reply (600 Policy Server Msg) in the route block of your config script. This is not possible because the route block can process requests only, it is never executed for replies. That is the reason why you get the error message from parse_sip_msg_uri, this function parses Request URI which is not there because it is a reply. parse_sip_msg_uri gets called either by your module directly or by some other function that follows in the script.
regards, Jan.
On 07-03 16:43, Stephan Reiff-Marganiec wrote:
If I have a SIP message in a char* variable, then I assume that I can parse it into a struct sip_msg* using a function in ser. The most obvious function seems to be parse_msg(). This does not seem to work to my expectation.
Here is a code snippet (which is close to the code in receive.c):
char* response // contains my message struct sip_msg msg // this is were the result should go
memset(msg, 0, sizeof(struct sip_msg)); response[len] = 0; msg->buf = response; msg->len = len; if (parse_msg(response, len, msg))!=0) { LOG(L_ERR, "ERROR"); } LOG(L_ERR, "After parse msg ...") dump_sip_msg(msg) // this just prints the fields of the message to LOG
dump_sip_msg() works fine on the incoming sip message, so the problem is either in my SIP message or in my use of the parse function. However, I think my message is fine (it is the received message with the first line replaced with SIP/2.0 600 Policy Server Msg date time). I enclose a cut from /var/log/messages.
Stephan
/var/log/messages:
Mar 7 14:52:41 d254196 /usr/local/sbin/ser[9566]: After parse_msg... Mar 7 14:52:41 d254196 /usr/local/sbin/ser[9566]: polserv: dump_sip_msg() Mar 7 14:52:41 d254196 /usr/local/sbin/ser[9566]: msg->id: int = 0 Mar 7 14:52:41 d254196 /usr/local/sbin/ser[9566]: msg->first_line: msg_start (rep) 600 Policy Server Msg 2003-03-07 14:52:24^M Via: SIP/2.0/UDP Mar 7 14:52:41 d254196 /usr/local/sbin/ser[9566]: DEBUG: dump_hdr_field: type=1, name=Via, body=SIP/2.0/UDP 139.153.254.196:5062, parsed=0x80a584c, next=(nil) Mar 7 14:52:41 d254196 /usr/local/sbin/ser[9566]: DEBUG: dump_hdr_field: type=1, name=Via, body=SIP/2.0/UDP 139.153.254.196:5062, parsed=0x80a584c, next=(nil) Mar 7 14:52:41 d254196 /usr/local/sbin/ser[9566]: msg->parsed_flag 1 Mar 7 14:52:41 d254196 /usr/local/sbin/ser[9566]: DEBUG: dump_hdr_field: type=1, name=Via, body=SIP/2.0/UDP 139.153.254.196:5062, parsed=0x80a584c, next=(nil) Mar 7 14:52:41 d254196 /usr/local/sbin/ser[9566]: DEBUG: dump_hdr_field: field is NULL Mar 7 14:52:41 d254196 last message repeated 20 times Mar 7 14:52:41 d254196 /usr/local/sbin/ser[9566]: msg->eoh: (null) Mar 7 14:52:41 d254196 /usr/local/sbin/ser[9566]: msg->unparsed: CSeq: 7635 REGISTER^M To: "Stephan" sip:mrs@cs.stir.ac.uk^M Expires: 900^M From: "Stephan" sip:mrs@cs.stir.ac.uk^M Call-Id: 138108089@139.153.254.196^M User-Agent: KPhone/2.11^M Event: registration^M Allow-Events: presence^M Contact: "root" sip:root@139.153.254.196:5062;transport=UDP;methods="INVITE, MESSAGE, INFO, SUBSCRIBE, OPTIONS, BYE, CANCEL, NOTIFY, ACK"^M Content-Length: 0^M ^M ^M Mar 7 14:52:41 d254196 /usr/local/sbin/ser[9566]: msg->buf: SIP/2.0 600 Policy Server Msg 2003-03-07 14:52:24^M Via: SIP/2.0/UDP 139.153.254.196:5062^M CSeq: 7635 REGISTER^M To: "Stephan" sip:mrs@cs.stir.ac.uk^M Expires: 900^M From: "Stephan" sip:mrs@cs.stir.ac.uk^M Call-Id: 138108089@139.153.254.196^M User-Agent: KPhone/2.11^M Event: registration^M Allow-Events: presence^M Contact: "root" sip:root@139.153.254.196:5062;transport=UDP;methods="INVITE, MESSAGE, INFO, SUBSCRIBE, OPTIONS, BYE, CANCEL, NOTIFY, ACK"^M Content-Length: 0^M ^M ^M Mar 7 14:52:41 d254196 /usr/local/sbin/ser[9566]: msg->len: 475 Mar 7 14:52:41 d254196 /usr/local/sbin/ser[9566]: msg->parsed_uri_ok: int = 0 Mar 7 14:52:41 d254196 /usr/local/sbin/ser[9566]: polserv: all fine, returning now ... Mar 7 14:52:41 d254196 /usr/local/sbin/ser[9566]: ERROR: parse_sip_msg_uri: bad uri <600> Mar 7 14:52:41 d254196 /usr/local/sbin/ser[9566]: WARNING: do_action:error in expression
-- Dr Stephan Reiff-Marganiec Research Fellow Department of Computing Science; University of Stirling email: srm@cs.stir.ac.uk tel: 01786 46 7448
-- The University of Stirling is a university established in Scotland by charter at Stirling, FK9 4LA. Privileged/Confidential Information may be contained in this message. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not disclose, copy or deliver this message to anyone and any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. In such case, you should destroy this message and kindly notify the sender by reply email. Please advise immediately if you or your employer do not consent to Internet email for messages of this kind. Opinions, conclusions and other information in this message that do not relate to the official business of the University of Stirling shall be understood as neither given nor endorsed by it.
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
| In regards to your log: | You seem to be processing this reply (600 Policy Server Msg) in the | route block of your config script. This is not possible because the | route block can process requests only, it is never executed | for replies. | That is the reason why you get the error message from | parse_sip_msg_uri, | this function parses Request URI which is not there because it is a | reply. parse_sip_msg_uri gets called either by your module directly or | by some other function that follows in the script.
Managed the Parsing now. I see your point with respect to the response, but how would I handle the following case then:
1) Proxy received Request from UA and should respond to the UA swallowing the original message (that is my module generates a response message) -- as I tried above.
2) Proxy receives response from terminating side UA/Proxy and should respond to them, that is generate a new request without the response bubbling up to the UA.
3) Proxy creates a number of responses/requests to be send.
I do not need stateful routing.
I was assuming to find a functions like send_request(msg) and send_response(msg) or send_msg(msg) that can be used by modules to send msg to the proxy and leave the routing to the proxy according to ser.cfg instructions, but ignoring instructions in the route block *before* the call to the module -- which probably should allow me to do all of the above.
thanks, Stephan
Stephan
Hello,
On 10-03 12:47, Stephan Reiff-Marganiec wrote:
Managed the Parsing now. I see your point with respect to the response, but how would I handle the following case then:
- Proxy received Request from UA and should respond to the UA swallowing
the original message (that is my module generates a response message) -- as I tried above.
sl_send_reply function in sl module, you can call this function directly from the script and it will send a stateless reply, you just give id reply code and reason phrase. You can call this function from your module too, look into ser-0.8.10/modules/registrar/save.c for example.
After you send a reply, your function called from the script should return 0 to the core which indicates that the core should stop processing of the script.
- Proxy receives response from terminating side UA/Proxy and should respond
to them, that is generate a new request without the response bubbling up to the UA.
This can be done using tm module callbacks. See ser-0.8.10/modules/tm/README for more description. tm exports function t_uac_dlg which can send requests. Let me know if you need any further assistance, I will try to find some example how to do it.
- Proxy creates a number of responses/requests to be send.
You can call sl_send_reply/t_uac_dlg several times.
What version of ser are you using, 0.8.10 or a CVS snapshot ?
I was assuming to find a functions like send_request(msg) and send_response(msg) or send_msg(msg) that can be used by modules to send msg to the proxy and leave the routing to the proxy according to ser.cfg instructions, but ignoring instructions in the route block *before* the call to the module -- which probably should allow me to do all of the above.
sl_send_reply (sl module) or t_reply (tm) module can send replies. t_reply also terminates transaction created by the original request. t_uac_dlg (tm module) can send requests.
Jan.
-
Jan Janak -
Jan Janak -
Stephan Reiff-Marganiec