7 Mar
2003
7 Mar
'03
11:43 a.m.
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(a)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(a)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(a)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.
3 Jul
3 Jul
12:15 p.m.
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(a)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(a)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(a)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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
10 Mar
10 Mar
7:47 a.m.
| 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
--
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.
11 Mar
11 Mar
6:17 a.m.
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:
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.
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.
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.
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.
3) 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.
7961
days inactive
7965
days old
3 comments
3 participants
participants (3)
-
Jan Janak -
Jan Janak -
Stephan Reiff-Marganiec