[Sofia-sip-devel] nua_invite segfaults
Hello there, I've downloaded Sofia-SIP today and just started to test it. I've compiled the tutorial application from the wiki and it worked fine. Now I'm trying to modify it so that it sends an invite instead of a hello world message. I have not changed the application except for the send_message function, replacing nua_message for nua_invite and adding the relevant tags. But when I try to run it, I get the following (under gdb): Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1212736608 (LWP 18363)] 0xb7ee6cc5 in signal_call_state_change (nh=0x804e038, ss=0x0, status=900, phrase=0xb7f5809e "Cannot Initialize Request", next_state=nua_callstate_init, oa_recv=0xc5a , oa_sent=0x0) at nua_session.c:3471 3471 if (ss->ss_state == nua_callstate_ready) My guess is that I cannot send an invite before I call su_root_run (). Is that correct? If so, is a multi-threaded application the only way to test an invite? I'd like to run the simplest possible test. Thank you in advance for any help. Fabio - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
Re: [Sofia-sip-devel] nua_invite segfaults
Well, Kai Vehmanen's answer to the other thread came in perfect timing, and I thought it applied to my problem too... :-) So I tried the solution with the timer, and I'm having a little trouble with that as well... I defined my timer callback function as: su_timer_f timer_wakeup(su_root_magic_t *magic, su_timer_t *t, su_timer_arg_t *arg); and then called su_timer_set like this: su_timer_set(timer, timer_wakeup, NULL); But compilation generates this warning: passing argument 2 of 'su_timer_set' from incompatible pointer type What's the correct way to declare the timer callback function? Anyway, I put a printf inside the callback and it gets printed despite the warning. But my initial problem (the segfault) still occurs. What am I missing here? Is there any additional initialization of the state machine that needs to be done? thanks On 1/5/07, Fabio Margarido <[EMAIL PROTECTED]> wrote: Hello there, I've downloaded Sofia-SIP today and just started to test it. I've compiled the tutorial application from the wiki and it worked fine. Now I'm trying to modify it so that it sends an invite instead of a hello world message. I have not changed the application except for the send_message function, replacing nua_message for nua_invite and adding the relevant tags. But when I try to run it, I get the following (under gdb): Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1212736608 (LWP 18363)] 0xb7ee6cc5 in signal_call_state_change (nh=0x804e038, ss=0x0, status=900, phrase=0xb7f5809e "Cannot Initialize Request", next_state=nua_callstate_init, oa_recv=0xc5a , oa_sent=0x0) at nua_session.c:3471 3471 if (ss->ss_state == nua_callstate_ready) My guess is that I cannot send an invite before I call su_root_run (). Is that correct? If so, is a multi-threaded application the only way to test an invite? I'd like to run the simplest possible test. Thank you in advance for any help. Fabio - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] Possible bug in nua_session.c
Hey there,
I started another thread explaining some problems I'm having with a SIGSEGV
in Sofia. Investigating it further, I opened up the source for the nua
module and found this in nua_session.c, starting at line 3464 (version
1.12.4):
if (ss) {
/* Update state variables */
if (next_state > ss_state)
ss->ss_state = next_state;
else if (next_state == nua_callstate_init && ss_state <
nua_callstate_ready)
ss->ss_state = nua_callstate_init, next_state =
nua_callstate_terminated;
}
if (ss->ss_state == nua_callstate_ready)
nh->nh_active_call = 1;
else if (next_state == nua_callstate_terminated)
nh->nh_active_call = 0;
I believe that last if should read ss_state instead of ss->ss_state, is that
correct?
Thanks, I hope this was helpful.
Fabio
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] Turn off DNS resolver
Hi there, is there any way to tell the Sofia library (when I create a root_t or nua_t instance, for example) that I don't want to use the DNS resolver feature? That is, when I try to send an invite the invite will be sent regardless of knowledge about the destination availability... I couldn't find and answer neither in the documentation nor the mailing list. Thank you Fabio Margarido - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
Re: [Sofia-sip-devel] nua_invite segfaults
On 1/9/07, Pekka Pessi <[EMAIL PROTECTED]> wrote: There is bug in signal_call_state_change, which is fixed in darcs version. Or so I hope. You get this crash when the stack fails to generate a valid INVITE request. I guess there is something fishy with your tags. Yeah, I had the buggy version... The tags were OK, fixing signal_call_state_changed did the trick... Thanks. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
Re: [Sofia-sip-devel] Turn off DNS resolver
On 1/9/07, Pekka Pessi <[EMAIL PROTECTED]> wrote: On 1/8/07, Fabio Margarido <[EMAIL PROTECTED]> wrote: > is there any way to tell the Sofia library (when I create a root_t or nua_t > instance, for example) that I don't want to use the DNS resolver feature? > That is, when I try to send an invite the invite will be sent regardless of > knowledge about the destination availability... I think I did not fully grasp your meaning. Sorry for not making myself clearer... Let me give an example of what I am seeing here: when I try to send an invite to IP 10.0.64.100 I get this (and a lot more output, both NUA_DEBUG and SOFIA_DEBUG are set to 9): nta: selecting scheme sip tport(0x804d6e0): EXPENSIVE unresolved */10.0.64.100:5060 tport_tsend(0x804d6e0) tpn = */10.0.64.100:5060 tport_resolve addrinfo = 10.0.64.100:5060 tport_by_addrinfo(0x804d6e0): not found by name */10.0.64.100:5060 tport_vsend(0x804d6e0): Invalid argument with (s=9 */10.0.64.100:5060) tport_vsend returned -1 nta: INVITE (2): Invalid argument (22) with */[10.0.64.100]:5060 The machine with IP 10.0.64.100 is not listening on port 5060, so I'm guessing this is what the message is complaining about. But I don't want to care about that, I want the invite to be sent anyway... Sorry if there is something else I'm missing here and that error has nothing to do with the port on the remote machine... Monitoring the network reveals nothing is being sent and then I get a trace for a 503 response, which I'm guessing the stack fakes so that the states are updated correctly... Thank you for your help - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
Re: [Sofia-sip-devel] Turn off DNS resolver
On 1/9/07, Pekka Pessi <[EMAIL PROTECTED]> wrote:
The tport_resolve converts the string-formatted host IP address in URI
("10.0.64.100") and port number to sockaddr_in structure. It looks
like tport_vsend()/su_vsend() returns -1 and EINVAL in errno. I wonder
if you run sofia-sip on Linux or on some other OS? Do you have IPv6
enabled on your computer?
Well, looks like I got it wrong then :-)
Yes, I'm running Ubuntu Linux 6.10... I didn't know about IPv6 on Ubuntu, so
I checked it and it was indeed enabled (it's the default). After a bit of
googling I found out how to disable it (at least ifconfig doesn't show an
IPv6 address anymore), but when I tried to run my application again, the
behaviour and the error messages were exactly the same...
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
Re: [Sofia-sip-devel] Turn off DNS resolver
Please, any further help will be greatly appreciated.
On 1/9/07, Fabio Margarido <[EMAIL PROTECTED]> wrote:
On 1/9/07, Pekka Pessi <[EMAIL PROTECTED]> wrote:
>
> The tport_resolve converts the string-formatted host IP address in URI
> ("10.0.64.100") and port number to sockaddr_in structure. It looks
> like tport_vsend()/su_vsend() returns -1 and EINVAL in errno. I wonder
> if you run sofia-sip on Linux or on some other OS? Do you have IPv6
> enabled on your computer?
Well, looks like I got it wrong then :-)
Yes, I'm running Ubuntu Linux 6.10... I didn't know about IPv6 on Ubuntu,
so I checked it and it was indeed enabled (it's the default). After a bit of
googling I found out how to disable it (at least ifconfig doesn't show an
IPv6 address anymore), but when I tried to run my application again, the
behaviour and the error messages were exactly the same...
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
Re: [Sofia-sip-devel] Turn off DNS resolver
On 1/22/07, Pekka Pessi <[EMAIL PROTECTED]> wrote:
It looks like the stack binds only to 127.0.0.1, which is probably
because you give nua_create() parameter like
NUTAG_URL("sip:127.0.0.1"). Please use something like
NUTAG_URL("sip:0.0.0.0") and let Sofia SIP stack to pick up the
suitable address.
Yes, changing the bind address to 0.0.0.0 solved the issue (I had copied the
code with 127.0.0.1 from the tutorial in the wiki) and now the invite is
sent as expected.
But now it looks like we've come back to my original doubt about Sofia: the
invite is sent to a machine that is not listening on port 5060, and so my
application receives an ICMP port unreachable response, and stops the call
at this point. Isn't there a way for me to tell Sofia not to care about the
remote side state and keep retransmiting the request despite the ICMP
responses (I guess it's not the best behaviour as it wastes bandwidth, but
maybe the application I'm going to write has to do it like that)?
Thank you very much for your help so far.
Fabio Margarido
--
Pekka.Pessi mail at nokia.com
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] Bug in BYE after 200 OK retransmissions?
Hi there, I'm using sofsip-cli to simulate a number of conformance test cases and got struck by a problem... In the case of an invite server transaction where the client never sends an ACK to the 200 OK, sofsip-cli should send a BYE request after it's done retransmitting the 200s. But it was never sent and I got an error message saying "900 Invalid handle for BYE". I traced the message to nua_session.c, inside the nua_bye_client_init function (I'm using the darcs version). Changing the line: if (!ss || ss->ss_state >= nua_callstate_terminating) to if (!ss || ss->ss_state > nua_callstate_terminating) seems to have solved the issue. Can anybody else confirm the described behaviour? Is that change correct or if not, does it affect other cases? Thanks in advance. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
Re: [Sofia-sip-devel] Bug in BYE after 200 OK retransmissions?
On 2/1/07, Pekka Pessi <[EMAIL PROTECTED]> wrote: The idea is to prevent stack from sending multiple BYE requests. The correct fix would probably involve setting the callstate, instead of setting callstate to terminating and then sending BYE the stack should just send BYE and let BYE client take care of updating the call state. Unfortunately we miss the test cases here. Is there anything more I can do to help you find this? -- Pekka.Pessi mail at nokia.com - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
Re: [Sofia-sip-devel] Bug in BYE after 200 OK retransmissions?
On 2/2/07, Fabio Margarido <[EMAIL PROTECTED]> wrote: On 2/1/07, Pekka Pessi <[EMAIL PROTECTED]> wrote: > > I just pushed a patch to darcs that should fix the problem. Please > give it a try. Great, thanks. I'll try to run the test case again on Monday. I just got to run that test case on the new darcs version and it works ok now. Thanks again. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] Sofia accepts BYE without To tag
Hey there guys, I've been doing some more tests and noticed that if I have an established dialog and receive (using sofsip-cli) a BYE without a tag in the To header, Sofia accepts the BYE and answers with 200 OK. If I'm not mistaken, that's obsoleted RFC 2543 behavior, right? I guess the correct behavior would be to send a 481. Let me know if you need any further info. Thanks Fabio Margarido - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
Re: [Sofia-sip-devel] Sofia accepts BYE without To tag
On 2/6/07, Pekka Pessi <[EMAIL PROTECTED]> wrote: On 2/6/07, Fabio Margarido <[EMAIL PROTECTED]> wrote: > I've been doing some more tests and noticed that if I have an established > dialog and receive (using sofsip-cli) a BYE without a tag in the To header, > Sofia accepts the BYE and answers with 200 OK. If I'm not mistaken, that's > obsoleted RFC 2543 behavior, right? I guess the correct behavior would be to > send a 481. You are completely right... I wonder what happens here. Something fishy in nta. ;-/ Hi Pekka, I have identified another troublesome situation that may be related to the BYE problem I reported earlier. What happens is when I have an INVITE server transaction in the proceeding state and receive a CANCEL request with a different 'Via' but identical request URI, to tag (none), from tag call-id and cseq as the INVITE, Sofia responds with a 482 Request Merged, when I believe it should be a 481. Maybe it has to do with the fact that the CANCEL arrives without a tag in the to header like the BYE request did. If the two situations are related, does the fix for the other problem help here too? (I ran this test before you committed it) Sorry if it's not too clear, let me know if I can do anything else. Thanks. Fabio - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
Re: [Sofia-sip-devel] Sofia accepts BYE without To tag
On 2/8/07, Pekka Pessi <[EMAIL PROTECTED]> wrote: On 2/8/07, Fabio Margarido <[EMAIL PROTECTED]> wrote: > I have identified another troublesome situation that may be related to the > BYE problem I reported earlier. What happens is when I have an INVITE server > transaction in the proceeding state and receive a CANCEL request with a > different 'Via' but identical request URI, to tag (none), from tag call-id > and cseq as the INVITE, Sofia responds with a 482 Request Merged, when I > believe it should be a 481. Nope, these two problems are not related. > Sorry if it's not too clear, let me know if I can do anything else. Are you running some kind of standard test set? Yes, I'm running ETSI TS 102 027-1 V2.1.1 set of conformance tests in order to evaluate free SIP stack implementations. If you're interested, I can report all the issues I find. Now, as I understand RFC 3261, the CANCEL with different Via is processed correctly. The processing is described in RFC 3261 section 9.2 and 8.2: if we have an another transaction with matching call-id/to/from tags and CSeq, we respond with 482 as specified in 8.2.2.2. Sorry, I guess I was a little confusing. Do the rules from section 8.2.2.2apply when there are two different methods involved? The test case involves an INVITE and then a CANCEL with equal parameters. Also, section 9.2 states that: "If the UAS did not find a matching transaction for the CANCEL according to the procedure above (transaction matching procedures of Section 17.2.3), it SHOULD respond to the CANCEL with a 481 (...)". Thanks. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] Response with 2 Vias is not discarded
Hi Pekka, thanks for the last fix for the merged requests issue (I haven't tested it yet though). Moving on, the next thing I've noticed is that Sofia sends an ACK to a 200 OK response that has 2 Via headers, when section 8.1.3.3 says it should discard that 200. It's recommended behavior though, so maybe there's a reason for this. Thanks. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
Re: [Sofia-sip-devel] Response with 2 Vias is not discarded
No comments on this one? On 2/12/07, Fabio Margarido <[EMAIL PROTECTED]> wrote: Hi Pekka, thanks for the last fix for the merged requests issue (I haven't tested it yet though). Moving on, the next thing I've noticed is that Sofia sends an ACK to a 200 OK response that has 2 Via headers, when section 8.1.3.3 says it should discard that 200. It's recommended behavior though, so maybe there's a reason for this. Thanks. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
Re: [Sofia-sip-devel] Response with 2 Vias is not discarded
On 2/15/07, Pekka Pessi <[EMAIL PROTECTED]> wrote: I don't recall that there has been any particular reason not to discard responses with two or more Via headers, I guess that behavior is just the way the interface has evolved. Can you fix it then? - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] How to get Call-ID from outgoing INVITE request
Hey there, When I start an outgoing INVITE request, how can I get the Call-ID (or other headers) that Sofia gave to that request? Is there a function I can call after nua_handle and nua_invite that returns such info? (preferably synchronously, but if something like nua_get_params works, I can work it out) Thanks in advance. Fabio - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] Failed assertion
Hi there, I've been running performance tests on Sofia-SIP and hit a problem today. I have one machine running a simple server application that uses Sofia-SIP. It merely answers 180 and then 200 OK to incoming INVITE requests and 200 OK to incoming BYE requests. Another machine runs a SIPp script that generates the requests. Calls were being made at a rate of 800 caps and were set for 15 seconds of conversation time. After about 80 million successful calls, my test application died with the following message: teste: nua_session.c:1266: nua_session_usage_refresh: Asserion `cr' failed. Aborted I'm using sofia-sip-1.12.5work3, and have not much further info on what was going on when the fail occurred, as the tests were run over night. Any clues on what might have happened? Let me know if there's something else I can report. Thanks in advance. Fabio Margarido - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] NTA tags documentation
Hi there, can anybody tell me if there is doxygen documentation for NTA statistics tags (NTATAG_S_*)? I couldn't find anything in the nta_tag.h file reference (where I think it should be). I need to get statistics information in my application, but I couldn't guess from the source the exact information each tag represents. If indeed there is no documentation for those tags, could someone please add it? Thanks in advance. Fabio Margarido - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
Re: [Sofia-sip-devel] NTA tags documentation
On 4/19/07, Pekka Pessi <[EMAIL PROTECTED]> wrote: I don't think those statistics tags has been documented. There is some software that uses them, I'll try to find it and see if we can release it. You have to wait after 1.12.6, however, for the documentation to be updated.. That's great, thanks. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] Duplicate sip_t structure
Hi there, sorry if this is a dumb question, but I couldn't find anything neither in the documentation nor the mailing list archives... I'd like to know if there is a function to duplicate an entire sip_t object. I see that there are header-specific functions, like sip_to_dup(), but is there something like a sip_msg_dup? I'd like to copy the whole structure and send it for processing in another process so I don't hang the sofia-sip main loop. Thanks in advance. Fabio - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] NTA statistics tags documentation
Hey all, some time ago I asked if it would be possible to have the NTA documentation updated so that information on the statistics related tags would be included, and was told to wait until 1.12.6 was released. Now that it's been out for some time, could someone please add the info on those tags? Thanks in advance. Fabio Margarido - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] Still regarding statistics
Hi everyone, first of all, thanks a lot for the new documentation on statistics related tags, it's been very helpful. What I'd like to do now is take statistics one step further: 1) Is it possible to query the stack for statistics passing some kind of parameters (like asking for the number of retransmissions to target IP x.x.x.x, or number of retransmissions of INVITEs)? - I'm guessing no 2) If not, would it be hard to do? 3) If that's not up in your priorities list, is it something someone who's not so familiar with the code (say, me) would be able to do? Thanks. Fabio Margarido - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] Parameters in user part of url
Hi there, I need my application to support the cpc parameter described in draft-mahy-iptel-cpc-06 ( http://tools.ietf.org/wg/iptel/draft-mahy-iptel-cpc-06.txt ), so I'll receive messages with headers like: From: ;tag=12341234 I believe the 'user' parameter will be parsed and put in the url parameters of the From header structure, right? But what about the 'cpc' parameter? Do i have to manually parse the user part of the url to get it? Thanks in advance. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] Sofia doesn't send an ACK for 487 after a CANCEL
Hi there, I am observing the following behavior from Sofia in my application: I send an INVITE to a sip softphone in another machine, and receive 100 and 180 as responses. After some time, my application calls nua_handle_destroy() on this call, and Sofia automatically sends a CANCEL to the pending INVITE (I'm using nua). I've noticed that the CANCEL goes out without a tag in the To header, despite being sent after the reception of the 180 (i think this issue might be related with this thread: http://sourceforge.net/mailarchive/message.php?msg_id=97bf55c20705160751l44f5a0eagd366f7a558c0d8ab%40mail.gmail.com , but i don't know if this issue has already been fixed. I'm using the latest darcs revision). Despite the missing tag, the softphone replies with a 200 (with tag), and then a 487 for the initial INVITE. But Sofia never ACKs the 487, which is retransmitted over and over. I also see on the terminal an error message saying: "nta_outgoing_tcancel: trying to cancel cancelled request". Is there something I should be doing different? If not, could you please confirm that this is indeed a bug and if it will be fixed soon? Thanks in advance. Fabio Margarido PS: if you need a trace, I've got one handy. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
Re: [Sofia-sip-devel] Sofia doesn't send an ACK for 487 after a CANCEL
Hi all, Just a quick update to the issue I reported earlier: I set the SOFIA_DEBUG environment variable to 9 and found that I get the following messages regarding the 487: tport_wakeup_pri(0x806bbf0): events IN tport_recv_event(0x806bbf0) tport_recv_iovec(0x806bbf0) msg 0x8084fb0 from (udp/10.0.66.27:5060) has 361 bytes, veclen = 1 tport_deliver(0x806bbf0): msg 0x8084fb0 (361 bytes) from udp/10.0.66.9:5060/sip next=(nil) nta: received 487 Request Terminated for INVITE (87778107) nta: 487 Request Terminated was discarded I browsed the source code for the 'discarded' message and found it to be printed in nta.c, line 2699 (from the darcs version). Digging around I saw this comment on line 2657: "/* XXX - should check if msg should be discarded based on via? */". Then I checked the Via headers in both the INVITE sent by Sofia and the 487 received, and verified that they differ: Via from INVITE: Via: SIP/2.0/UDP 10.0.66.27;rport;branch=z9hG4bKrt1vS4B0ZHayF Via from 487: Via: SIP/2.0/UDP 10.0.66.27;rport=5060;received=10.0.66.27;branch=z9hG4bKrt1vS4B0ZHayF As you can see, the softphone adds a 'received' parameter to the Via header. Is this what may be causing the message to be discarded? Thanks again. Fabio Margarido On 8/22/07, Fabio Margarido <[EMAIL PROTECTED]> wrote: > Hi there, > > I am observing the following behavior from Sofia in my application: > > I send an INVITE to a sip softphone in another machine, and receive > 100 and 180 as responses. After some time, my application calls > nua_handle_destroy() on this call, and Sofia automatically sends a > CANCEL to the pending INVITE (I'm using nua). > I've noticed that the CANCEL goes out without a tag in the To header, > despite being sent after the reception of the 180 (i think this issue > might be related with this thread: > http://sourceforge.net/mailarchive/message.php?msg_id=97bf55c20705160751l44f5a0eagd366f7a558c0d8ab%40mail.gmail.com > , but i don't know if this issue has already been fixed. I'm using the > latest darcs revision). > Despite the missing tag, the softphone replies with a 200 (with tag), > and then a 487 for the initial INVITE. But Sofia never ACKs the 487, > which is retransmitted over and over. > I also see on the terminal an error message saying: > "nta_outgoing_tcancel: trying to cancel cancelled request". > Is there something I should be doing different? If not, could you > please confirm that this is indeed a bug and if it will be fixed soon? > Thanks in advance. > > Fabio Margarido > > PS: if you need a trace, I've got one handy. > - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
Re: [Sofia-sip-devel] Sofia doesn't send an ACK for 487 after a CANCEL
So, is it easily fixable? Thanks. Fabio On 8/22/07, Pekka Pessi <[EMAIL PROTECTED]> wrote: > 2007/8/22, Fabio Margarido <[EMAIL PROTECTED]>: > > As you can see, the softphone adds a 'received' parameter to the Via > > header. Is this what may be causing the message to be discarded? > > Nope, only the "host-port" and branch parameter are taken into account > when comparing Via. > > My guess is that the current timer code manages to discard the INVITE > transaction after 200 OK to CANCEL is received but before 487 to > INVITE is received. > > --Pekka > > -- > Pekka.Pessi mail at nokia.com > - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
Re: [Sofia-sip-devel] Fwd: Sofia doesn't send an ACK for 487 after a CANCEL
Just checked out the new darcs version, works great now. Thank you very much for the quick fix Pekka. On 8/23/07, Pekka Pessi <[EMAIL PROTECTED]> wrote: > Oops. > > -- Forwarded message -- > From: Pekka Pessi <[EMAIL PROTECTED]> > Date: 23.8.2007 17:54 > Subject: Re: [Sofia-sip-devel] Sofia doesn't send an ACK for 487 after a > CANCEL > To: Fabio Margarido <[EMAIL PROTECTED]> > > > 2007/8/22, Fabio Margarido <[EMAIL PROTECTED]>: > > So, is it easily fixable? > > Should be, if the problem is where I think it is. Looks like there is > the same problem already present in test_nua, the stack sends 487 > responses all the time. > > --Pekka > > > On 8/22/07, Pekka Pessi <[EMAIL PROTECTED]> wrote: > > > 2007/8/22, Fabio Margarido <[EMAIL PROTECTED]>: > > > > As you can see, the softphone adds a 'received' parameter to the Via > > > > header. Is this what may be causing the message to be discarded? > > > > > > Nope, only the "host-port" and branch parameter are taken into account > > > when comparing Via. > > > > > > My guess is that the current timer code manages to discard the INVITE > > > transaction after 200 OK to CANCEL is received but before 487 to > > > INVITE is received. > > > > > > --Pekka > > > > > > -- > > > Pekka.Pessi mail at nokia.com > > > > > > > > -- > Pekka.Pessi mail at nokia.com > > > -- > Pekka.Pessi mail at nokia.com > > - > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > ___ > Sofia-sip-devel mailing list > Sofia-sip-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel > - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] Manual responses to BYE requests
Hi there, is there a way for me to tell Sofia not to auto-respond 200 OK for incoming BYE requests? In my case, I need responses to BYEs to have an encapsulated body. How can I do that? Thanks in advance. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
Re: [Sofia-sip-devel] Manual responses to BYE requests
Sorry for posting prior to searching thoroughly... :) I guess NUTAG_APPL_METHOD solves my problem... On 8/27/07, Fabio Margarido <[EMAIL PROTECTED]> wrote: > Hi there, > > is there a way for me to tell Sofia not to auto-respond 200 OK for > incoming BYE requests? In my case, I need responses to BYEs to have an > encapsulated body. How can I do that? > Thanks in advance. > - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] Escaped characters in Request-URI
Hi there, what do I have to do to force an INVITE to be sent with an escaped '=' in the Request-URI? I'm calling nua_invite with something like this: INVITE sip:[EMAIL PROTECTED];voicexml=http://www.123.com/dir/script.vxml%3fpar%3dvalue which is changed in the sent package to: INVITE sip:[EMAIL PROTECTED];voicexml=http://www.123.com/dir/script.vxml%3fpar=value The receiving side generates an error in this situation. Is there something I can do that will make the message go out exactly as the application asks? Thanks. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
Re: [Sofia-sip-devel] Escaped characters in Request-URI
Anybody? This is kinda urgent... Any help will be much appreciated. Thanks On 8/28/07, Fabio Margarido <[EMAIL PROTECTED]> wrote: > Hi there, > > what do I have to do to force an INVITE to be sent with an escaped '=' > in the Request-URI? I'm calling nua_invite with something like this: > > INVITE sip:[EMAIL > PROTECTED];voicexml=http://www.123.com/dir/script.vxml%3fpar%3dvalue > > which is changed in the sent package to: > > INVITE sip:[EMAIL > PROTECTED];voicexml=http://www.123.com/dir/script.vxml%3fpar=value > > The receiving side generates an error in this situation. Is there > something I can do that will make the message go out exactly as the > application asks? > Thanks. > - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
Re: [Sofia-sip-devel] Escaped characters in Request-URI
Hi, ok then. I don't know if you expect to be able to do it soon, but in the meantime, is there a quick and dirty hack I can do to get me going until the final solution? Thanks On 8/31/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Hi, > > Yes, it looks like a Sofia-SIP bug. > '=' is a reserved character, so the bug is the same as the issue with > unescaped '@' spotted before. > > Maybe I should sit down and write a big patch to that URI code some day... > > >-Original Message- > >From: [EMAIL PROTECTED] > >[mailto:[EMAIL PROTECTED] On > >Behalf Of ext Fabio Margarido > >Sent: Thursday, August 30, 2007 10:25 PM > >To: sofia-sip-devel@lists.sourceforge.net > >Subject: Re: [Sofia-sip-devel] Escaped characters in Request-URI > > > >Anybody? This is kinda urgent... > >Any help will be much appreciated. > >Thanks > > > >On 8/28/07, Fabio Margarido <[EMAIL PROTECTED]> wrote: > >> Hi there, > >> > >> what do I have to do to force an INVITE to be sent with an > >escaped '=' > >> in the Request-URI? I'm calling nua_invite with something like this: > >> > >> INVITE > >sip:[EMAIL PROTECTED];voicexml=http://www.123.com/dir/script.v > >xml%3fpar%3dvalue > >> > >> which is changed in the sent package to: > >> > >> INVITE > >sip:[EMAIL PROTECTED];voicexml=http://www.123.com/dir/script.v > >xml%3fpar=value > >> > >> The receiving side generates an error in this situation. Is there > >> something I can do that will make the message go out exactly as the > >> application asks? > >> Thanks. > >> > > > >--- > >-- > >This SF.net email is sponsored by: Splunk Inc. > >Still grepping through log files to find problems? Stop. > >Now Search log events and configuration files using AJAX and a browser. > >Download your FREE copy of Splunk now >> http://get.splunk.com/ > >___ > >Sofia-sip-devel mailing list > >Sofia-sip-devel@lists.sourceforge.net > >https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel > > > - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] Payload in ACK to error responses
Hey there, I recently posted a question about how to suppress the automatic response sent by NUA upon receipt of a BYE request, because in some cases I needed to include a payload in the response. Shortly after I found the answer was the NUTAG_APPL_METHOD tag. But there's also the case in which I must include a payload in the ACK to an error response I may get for an outgoing INVITE. The NUTAG_AUTOACK tag documentation states "that ACK is always sent automatically by lower layers of the stack after receiving an error response 3XX, 4XX, 5XX or 6XX". Since NUTAG_APPL_METHOD can't help me here, what should I do to include a payload in the ACK in such cases? Thanks in advance. Fabio Margarido - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] Darcs build failure
Hi, the latest darcs release does not compile anymore in my environment (yesterday everythnig was fine). I get the following error: gcc -g -O2 -o .libs/sip-options sip-options.o ../libsofia-sip-ua/.libs/libsofia-sip-ua.so /usr/lib/libglib-2.0.so -lssl -lcrypto -lrt -lpthread ../libsofia-sip-ua/.libs/libsofia-sip-ua.so: undefined reference to `tptag_trusted' collect2: ld returned 1 exit status I tried with my constantly updated local copy and with a fresh 'darcs get', both gave the same message. Thanks - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] PRACK not working
Hi there, when my application receives a 180 with a Require header containing 100rel, the PRACK requests Sofia sends lacks the user part of the url of the From header, which causes the remote agent to respond with a 481. I tried to include PRACK in the list of headers my application takes care of with NUTAG_APPL_METHOD, but when I call nua_prack like this: nua_prack(call_handle, TAG_END()); the message is never sent to the network. I get a "nua(0xXX): signal r_prack" and then nothing else. Is there something I'm missing? Thanks in advance. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] Incorrect From header in requests within outgoing call
Hi there, I noticed that if I have an established outgoing call and then try to send, for example, a BYE request with: nua_bye(call_handle, TAG_END); the 'From' header of the BYE request does not include the user part of the URL of the original INVITE. The documentation for nua_invite says: "Please note that the template message is not used when ACK, PRACK, UPDATE or INFO requests are created (however, these requests will include dialog-specific headers like To, From, and Call-ID as well as preference headers Allow, Supported, User-Agent, Organization)." Isn't the user part kept in this case? Is this a bug or is it expected that I manually add the user information in every request within the dialog? Thanks in advance. Fabio Margarido - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
Re: [Sofia-sip-devel] PRACK not working
On 10/1/07, Pekka Pessi <[EMAIL PROTECTED]> wrote:
> That is interesting. How you set the From header when you send INVITE?
> A tag in nua_handle() or in nua_invite()? In any case, according to
> the spec it is O.K. to change the From URI as long as the From tag is
> kept same.
>
I've tried both, but the outcome is the same. At first, I was using
SIPTAG_FROM_STR with nua_invite, and I thought this was the problem.
But changing it to nua_handle did not solve the issue. I got it to
work by using SIPTAG_FROM_STR with every method.
> You need the response sequence number (RSeq) from the 180 response in
> the RAck header. The following should work:
>
> {
> sip_rack_t rack[1];
>
> sip_rack_init(rack);
> rack->ra_response = sip->sip_rseq->rs_response;
> rack->ra_cseq = sip->sip_cseq->cs_seq;
> rack->ra_method = sip->sip_cseq->cs_method;
> rack->ra_method_name = sip->sip_cseq->cs_method_name;
> nua_prack(call_handle, SIPTAG_RACK(rack), TAG_END());
> }
>
> ...but it seems to me that there is no tests for PRACK as a user
> method in test_nua. Hmph.
>
Have you seen the bug I filed in the tracker for this PRACK issue?
Apparently there is some code missing in nua_stack.c/.h . Changing
those files made it work, no need to manually setting RAck.
Fabio Margarido
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] Trailing CRLF in multipart body
Hi there, In my application, I follow the guideline presented in the "MIME Multipart Body" section of the documentation in order to generate multipart/mixed bodies. The BNF grammar for multipart bodies defines the closing delimiter as: close-delimiter := delimiter "--" What happens is that the multipart body generated by Sofia contains an extra CRLF after the closing delimiter which apparently shouldn't be there. I know of some cases in which the remote agent complains of those extra bytes. I currently work around this issue by decrementing 2 from pl_len before passing it on to the stack, but it would be nice to get rid of this hack. Thanks. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
Re: [Sofia-sip-devel] 1.12.6 Application Interface
Hi there, On 10/2/07, Kai Vehmanen <[EMAIL PROTECTED]> wrote: > Sofia-SIP is an event-driven library where you can have multiple event > loops, but each of those has to be accessed from at most one thread. > > So if you have a multithreaded application, you can: >- run multiple separate nua instance (with their own su_root), one per > thread, or >- have multiple threads, but concentrate all access to nua objects > (sharing a single su_root) to a single thread > > Now with your current design, su_root_run() might trigger calls to nua > code (from timers, network i/o, etc), while you could be at the same time > calling nua functions from other threads. This leads to potentially > entering the event loop in multiple places, and this is not supported (and > can lead to hard to debug errors). > > 1.12.4 allowed you to create the su_root object in one thread, and then > run it in another. This was changed in 1.12.6. But even with 1.12.4, you > weren't supposed to access nua objects from two threads at the same time! > This hasn't changed since 1.12.4 AFAIK. I've been following this thread from a certain distance because I believed Jerry's problem was only related to calling nua_create and su_root_run from different threads. But if I understand what you are saying correctly, it means that I can't have su_root_run() in one thread and call nua_invite(), for example, from another thread, which my application does. Is this right? If that's so, I believe nua documentation is a bit misleading. Quoting the section 'Initialization and deinitialization': "If the application is not just responding to incoming SIP messages there must also be means to send messages to NUA. This can be handled for example by having a separate thread that calls NUA functions to send messages (...)" Isn't that somewhat opposed to what you explained? Thanks. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
Re: [Sofia-sip-devel] 1.12.6 Application Interface
On 10/3/07, Kai Vehmanen <[EMAIL PROTECTED]> wrote: > So it would seem this is supported as well after all and the documentation > is in fact correct. Sorry for adding to > the confusion, and thanks Fabio for pointing this out! Thank you for making this clear and my worries go away... :) - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] Payload in error responses sent automatically by Sofia
Hi there, is there a way I can tell Sofia to include a payload in the error responses sent automatically by the nua stack? Any help is much appreciated, I really need something like this. Thanks. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] Wrong remote target in client INVITE requests
Hi there, I'm observing odd behavior from Sofia when the 2XX response to an outgoing INVITE is received with Record-Route headers. According to section 12.1.2 UAC Behavior: "The route set MUST be set to the list of URIs in the Record-Route header field from the response, taken in reverse order and preserving all URI parameters. If no Record-Route header field is present in the response, the route set MUST be set to the empty set. This route set, even if empty, overrides any pre-existing route set for future requests in this dialog. The remote target MUST be set to the URI from the Contact header field of the response." However, my test case shows that when the 200 OK contains Record-Route headers, the packet destination and the Request-URI in the ACK sent by Sofia is the URI in the last Record-Route, and not the URI from the Contact header. Thanks. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
Re: [Sofia-sip-devel] Payload in error responses sent automatically by Sofia
> No, not at the moment. Is the payload constant, or should it change? Hi there. In my case it should change, and even worse, it should not be always included, it would depend on something like the IP of the originator. But I've already managed to work around it for now. Thanks - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] Memory leaks in 1.12.7
Hi there,
I'm observing serious memory leaks when using Sofia-sip 1.12.7 . I
have a simple UAS test program with a NUA callback like:
void event_callback(nua_event_t event,
int status,
char const *phrase,
nua_t*nua,
nua_magic_t *magic,
nua_handle_t *nh,
nua_hmagic_t *hmagic,
sip_t const *sip,
tagi_ttags[])
{
switch (event) {
case nua_i_invite:
nua_respond(nh, 180, NULL, TAG_END());
nua_respond(nh, 200, NULL,
SIPTAG_CONTENT_TYPE_STR("application/sdp"),
SIPTAG_PAYLOAD_STR(g_sdp),
TAG_END());
break;
case nua_i_bye:
nua_handle_destroy(nh);
break;
default:
break;
}
}
When I link this program against sofia-sip 1.12.6 I can keep it
running for ages with 350 caps and the memory usage never goes above
6% in a 2 GB machine. With 1.12.7, 100% memory is used after about 10
minutes.
My test setup uses SIPp to originate the calls. After 26 calls, the
valgrind report gives me this:
==13602== Memcheck, a memory error detector.
==13602== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
==13602== Using LibVEX rev 1658, a library for dynamic binary translation.
==13602== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
==13602== Using valgrind-3.2.1-Debian, a dynamic binary
instrumentation framework.
==13602== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
==13602== For more details, rerun with: -v
==13602==
==13602==
==13602== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 25 from 1)
==13602== malloc/free: in use at exit: 226,587 bytes in 1,851 blocks.
==13602== malloc/free: 4,567 allocs, 2,716 frees, 643,119 bytes allocated.
==13602== For counts of detected errors, rerun with: -v
==13602== searching for pointers to 1,851 not-freed blocks.
==13602== checked 8,664,364 bytes.
==13602==
==13602== 136 bytes in 1 blocks are possibly lost in loss record 3 of 17
==13602==at 0x402095F: calloc (vg_replace_malloc.c:279)
==13602==by 0x400FFA7: (within /lib/ld-2.5.so)
==13602==by 0x401006B: _dl_allocate_tls (in /lib/ld-2.5.so)
==13602==by 0x444AA4F: pthread_create@@GLIBC_2.1 (in
/lib/tls/i686/cmov/libpthread-2.5.so)
==13602==by 0x411A205: su_pthreaded_port_start (su_pthread_port.c:262)
==13602==by 0x411C1F2: su_epoll_clone_start (su_epoll_port.c:564)
==13602==by 0x41193A8: su_default_clone_start (su_port.c:78)
==13602==by 0x4119277: su_clone_start (su_port.c:304)
==13602==by 0x40C4473: nua_create (nua.c:166)
==13602==by 0x80488BA: main (teste.c:26)
==13602==
==13602==
==13602== 212,391 (37,752 direct, 174,639 indirect) bytes in 78 blocks
are definitely lost in loss record 15 of 17
==13602==at 0x402095F: calloc (vg_replace_malloc.c:279)
==13602==by 0x410E833: su_home_new (su_alloc.c:549)
==13602==by 0x40866CC: msg_create (msg.c:61)
==13602==by 0x40A3F71: nta_msg_create_for_transport (nta.c:2746)
==13602==by 0x4124F2C: tport_msg_alloc (tport.c:2622)
==13602==by 0x41257D9: tport_recv_iovec (tport.c:3068)
==13602==by 0x41321BB: tport_recv_dgram (tport_type_udp.c:266)
==13602==by 0x4130011: tport_recv_event (tport.c:2815)
==13602==by 0x4130347: tport_base_wakeup (tport.c:2754)
==13602==by 0x411BCAB: su_epoll_port_wait_events (su_epoll_port.c:506)
==13602==by 0x4119D01: su_base_port_run (su_base_port.c:336)
==13602==by 0x4111E28: su_root_run (su_port.h:309)
==13602==
==13602== LEAK SUMMARY:
==13602==definitely lost: 37,752 bytes in 78 blocks.
==13602==indirectly lost: 174,639 bytes in 1,690 blocks.
==13602== possibly lost: 136 bytes in 1 blocks.
==13602==still reachable: 14,060 bytes in 82 blocks.
==13602== suppressed: 0 bytes in 0 blocks.
==13602== Reachable blocks (those to which a pointer was found) are not shown.
==13602== To see them, rerun with: --show-reachable=yes
I'm interested in moving to 1.12.7 as soon as possible, but this is a
major show-stopper.
I'll be happy to provide further info. Hope this helps.
Thanks.
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] ACK to non-2xx responses
Hi there, I'm observing a small issue with Sofia in which it ACKs two sequential non-2XX (500 and 603, in my case) responses to an outgoing INVITE transaction. Section 13.2.2.3 of RFC3261 says that after the first non-2XX response "subsequent final responses (which would only arrive under error conditions) MUST be ignored." Thanks. Fabio - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
Re: [Sofia-sip-devel] ACK to non-2xx responses
On Nov 4, 2007 7:33 PM, Pekka Pessi <[EMAIL PROTECTED]> wrote: > In my reading of the spec the section 13.2.2.3 refers to "UAC core" > layer (in Sofia, NUA) but the second final error response is already > ACKed at transaction layer described by RFC 3261 section 17 (in Sofia, > NTA). Oh, OK. Would that mean that the part about the second non-2XX response in the RFC doesn't make sense? Thanks. > -- > Pekka.Pessi mail at nokia.com > - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] Forked calls
Hi there, is there anything I have to do to tell nua to inform me about forked calls? In my tests, when I have a client INVITE transaction that receives two 200 OK differing only in the 'To' tag, my callback is never informed of 'nua_i_fork'. Thanks. Fabio Margarido - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
Re: [Sofia-sip-devel] Forked calls
On Nov 14, 2007 1:32 PM, <[EMAIL PROTECTED]> wrote: > Welcome to the club :) > This was discussed just days ago: > Oh, I'm sorry... :) I hadn't read that whole thread. Looking forward for more info on that subject then. Thanks. Fabio - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] Responses generated by the stack
Hi there, I'd like to know if there is a way for me to tell if a response my callback gets came from a remote host or was generated by the underlying stack layer. For instance, if I send an INVITE and get an ICMP, Sofia automatically generates a 503 response and passes that to my callback. How can I tell this 503 apart from a 503 generated by a remote host? Thanks. Fabio - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] "Internal NUA Error" followed by crash
Hi there,
I'm seeing constant nua crashes when my application is under traffic.
I always get the following backtrace after the SIGSEGV:
(gdb) where
#0 0x400a2130 in nua_update_client_report (cr=0x9685940, status=900,
phrase=0x401084d7 "Internal NUA Error", sip=0x0,
orq=0x0, tags=0x0) at nua_session.c:3109
#1 0x40094306 in nua_client_report (cr=0x9685940, status=900,
phrase=0x401084d7 "Internal NUA Error", sip=0x0, orq=0x0,
tags=0x0) at nua_stack.c:2822
#2 0x40094161 in nua_base_client_response (cr=0x9685940, status=900,
phrase=0x401084d7 "Internal NUA Error", sip=0x0,
tags=0x0) at nua_stack.c:2762
#3 0x4009e687 in nua_session_client_response (cr=0x9685940,
status=900, phrase=0x401084d7 "Internal NUA Error", sip=0x0)
at nua_session.c:863
#4 0x4009388b in nua_client_response (cr=0x9685940, status=900,
phrase=0x401084d7 "Internal NUA Error", sip=0x0)
at nua_stack.c:2478
#5 0x400930a0 in nua_client_request_try (cr=0x9685940) at nua_stack.c:2190
#6 0x40092e9f in nua_client_init_request (cr=0x9685940) at nua_stack.c:2098
#7 0x4009443e in nua_client_next_request (cr=0x9685940, invite=0) at
nua_stack.c:2861
#8 0x400942b8 in nua_base_client_response (cr=0x839b118, status=408,
phrase=0x4010881c "Request Timeout", sip=0x957ddb4,
tags=0x0) at nua_stack.c:2806
#9 0x4009e687 in nua_session_client_response (cr=0x839b118,
status=408, phrase=0x4010881c "Request Timeout", sip=0x957ddb4)
at nua_session.c:863
#10 0x4009388b in nua_client_response (cr=0x839b118, status=408,
phrase=0x4010881c "Request Timeout", sip=0x957ddb4)
at nua_stack.c:2478
#11 0x40093698 in nua_client_orq_response (cr=0x839b118,
orq=0x960b120, sip=0x957ddb4) at nua_stack.c:2381
#12 0x4007f55e in outgoing_recv (orq=0x960b120, status=408,
msg=0x957dd18, sip=0x957ddb4) at nta.c:8371
#13 0x4008025f in outgoing_reply (orq=0x960b120, status=408,
phrase=0x4010881c "Request Timeout", delayed=0) at nta.c:8688
---Type to continue, or q to quit---
#14 0x4007e0a4 in outgoing_timeout (orq=0x960b120, now=-647435610) at nta.c:8010
#15 0x4007de62 in outgoing_timer_bf (q=0x8128040, timer=0x4011a12b
"F", now=-647435610) at nta.c:7953
#16 0x40088967 in outgoing_timer (sa=0x8127e90, next=-647435529) at nta.c:7875
#17 0x40070c41 in agent_timer (rm=0x8126960, timer=0x8127960,
agent=0x8127e90) at nta.c:746
#18 0x400d6bd5 in su_timer_expire (timers=0x8126cac,
timeout=0xbf3ffab0, now={tv_sec = 3405261630, tv_usec = 118073})
at su_timer.c:533
#19 0x400d7c93 in su_base_port_run (self=0x8126c88) at su_base_port.c:328
#20 0x400d0aaa in su_root_run (self=0x81276a0) at su_port.h:309
#21 0x400d8542 in su_pthread_port_clone_main (varg=0xbf5ff8dc) at
su_pthread_port.c:321
#22 0x4014b0ce in pthread_start_thread (arg=0xbf3ffc00) at manager.c:291
(gdb) p ss
$1 = (nua_session_usage_t *) 0x0
(gdb)
Considering that there are only sofia addresses in the trace, is this
an internal sofia bug or is it possible that my application is
misbehaving and causing the crash?
This is on vanilla 1.12.7 minus the patch that caused the memory leaks.
Thanks in advance.
Fabio Margarido
-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] Memory leaks
Hi there, I noticed that one of the commits to darcs last week had a comment saying that it seemed to fix the memory leak introduced in 1.12.7. I ran some tests with Valgrind again today and while it doesn't report lost memory anymore, the output is still a little weird. I'm running a very simple server application that uses Sofia against SIPp originating the calls and the longer I leave the application running, more still reachable but non-freed memory is reported by Valgrind. Is this behaviour expected or is this still reachable memory going to keep adding up forever? Thanks. Fabio Margarido - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] Assertion `sub && sub->sub_ref != 0' failed
Hi there,
I got this one today when running more performance tests on my
application. Is this my fault or could it be a bug?
Thanks.
nta_outgoing_tcancel: trying to cancel cancelled request
tport_vsend(0x8128f20): send truncated for UDP/10.20.90.31:5060
nta: ACK (92573398): Input/output error (5) with UDP/[10.20.90.31]:5060
nta(0x823bff8): responding 503 Service Unavailable to ACK!
tpsip: su_alloc.c:571: su_home_ref: Assertion `sub && sub->sub_ref != 0'
failed.
Program received signal SIGABRT, Aborted.
[Switching to Thread 3076 (LWP 1695)]
0x401f4621 in kill () from /lib/libc.so.6
Current language: auto; currently c
(gdb) where
#0 0x401f4621 in kill () from /lib/libc.so.6
#1 0x4014e26b in raise (sig=6) at signals.c:65
#2 0x401f5a53 in abort () from /lib/libc.so.6
#3 0x401ede12 in __assert_fail () from /lib/libc.so.6
#4 0x400cca9a in su_home_ref (home=0x868db40) at su_alloc.c:571
#5 0x400ce518 in su_home_mutex_lock (home=0x868db40) at su_alloc.c:1483
#6 0x4005c2ec in msg_destroy (msg=0x868db40) at msg.c:160
#7 0x4007fb9c in outgoing_recv (orq=0x86b7ce8, status=487,
msg=0x868db40, sip=0x868dbdc) at nta.c:8416
#8 0x40075dc3 in agent_recv_response (agent=0x8127d10, msg=0x868db40,
sip=0x868dbdc, tport_via=0x8128ea0,
tport=0x8128f20) at nta.c:2656
#9 0x4007453a in agent_recv_message (agent=0x8127d10, tport=0x8128f20,
msg=0x868db40, tport_via=0x8128ea0, now=
{tv_sec = 3406372299, tv_usec = 469809}) at nta.c:2177
#10 0x400e8620 in tport_base_deliver (self=0x8128f20, msg=0x868db40,
now={tv_sec = 3406372299, tv_usec = 469809})
at tport.c:3010
#11 0x400e85c5 in tport_deliver (self=0x8128f20, msg=0x868db40,
next=0x0, sc=0x0, now=
{tv_sec = 3406372299, tv_usec = 469809}) at tport.c:2999
#12 0x400e8244 in tport_parse (self=0x8128f20, complete=1, now={tv_sec =
3406372299, tv_usec = 469809}) at tport.c:2916
#13 0x400e8055 in tport_recv_event (self=0x8128f20) at tport.c:2858
#14 0x400e7dca in tport_base_wakeup (self=0x8128f20, events=1) at
tport.c:2760
#15 0x400da20f in su_poll_port_wait_events (self=0x8126af8, tout=38) at
su_poll_port.c:590
#16 0x400d8598 in su_base_port_run (self=0x8126af8) at
su_base_port.c:342
#17 0x400d120a in su_root_run (self=0x8127510) at su_port.h:310
#18 0x400d8e22 in su_pthread_port_clone_main (varg=0xbf5ff8ec) at
su_pthread_port.c:321
#19 0x4014b0ce in pthread_start_thread (arg=0xbf3ffc00) at manager.c:291
(gdb)
-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
Re: [Sofia-sip-devel] Assertion `sub && sub->sub_ref != 0' failed
Bump. Any help anyone? This is kinda urgent.
Thanks.
On Dec 12, 2007 8:41 AM, Fabio Margarido <[EMAIL PROTECTED]> wrote:
> Hi there,
>
> I got this one today when running more performance tests on my
> application. Is this my fault or could it be a bug?
> Thanks.
>
> nta_outgoing_tcancel: trying to cancel cancelled request
> tport_vsend(0x8128f20): send truncated for UDP/10.20.90.31:5060
> nta: ACK (92573398): Input/output error (5) with UDP/[10.20.90.31]:5060
> nta(0x823bff8): responding 503 Service Unavailable to ACK!
> tpsip: su_alloc.c:571: su_home_ref: Assertion `sub && sub->sub_ref != 0'
> failed.
>
> Program received signal SIGABRT, Aborted.
> [Switching to Thread 3076 (LWP 1695)]
> 0x401f4621 in kill () from /lib/libc.so.6
> Current language: auto; currently c
> (gdb) where
> #0 0x401f4621 in kill () from /lib/libc.so.6
> #1 0x4014e26b in raise (sig=6) at signals.c:65
> #2 0x401f5a53 in abort () from /lib/libc.so.6
> #3 0x401ede12 in __assert_fail () from /lib/libc.so.6
> #4 0x400cca9a in su_home_ref (home=0x868db40) at su_alloc.c:571
> #5 0x400ce518 in su_home_mutex_lock (home=0x868db40) at su_alloc.c:1483
> #6 0x4005c2ec in msg_destroy (msg=0x868db40) at msg.c:160
> #7 0x4007fb9c in outgoing_recv (orq=0x86b7ce8, status=487,
> msg=0x868db40, sip=0x868dbdc) at nta.c:8416
> #8 0x40075dc3 in agent_recv_response (agent=0x8127d10, msg=0x868db40,
> sip=0x868dbdc, tport_via=0x8128ea0,
> tport=0x8128f20) at nta.c:2656
> #9 0x4007453a in agent_recv_message (agent=0x8127d10, tport=0x8128f20,
> msg=0x868db40, tport_via=0x8128ea0, now=
> {tv_sec = 3406372299, tv_usec = 469809}) at nta.c:2177
> #10 0x400e8620 in tport_base_deliver (self=0x8128f20, msg=0x868db40,
> now={tv_sec = 3406372299, tv_usec = 469809})
> at tport.c:3010
> #11 0x400e85c5 in tport_deliver (self=0x8128f20, msg=0x868db40,
> next=0x0, sc=0x0, now=
> {tv_sec = 3406372299, tv_usec = 469809}) at tport.c:2999
> #12 0x400e8244 in tport_parse (self=0x8128f20, complete=1, now={tv_sec =
> 3406372299, tv_usec = 469809}) at tport.c:2916
> #13 0x400e8055 in tport_recv_event (self=0x8128f20) at tport.c:2858
> #14 0x400e7dca in tport_base_wakeup (self=0x8128f20, events=1) at
> tport.c:2760
> #15 0x400da20f in su_poll_port_wait_events (self=0x8126af8, tout=38) at
> su_poll_port.c:590
> #16 0x400d8598 in su_base_port_run (self=0x8126af8) at
> su_base_port.c:342
> #17 0x400d120a in su_root_run (self=0x8127510) at su_port.h:310
> #18 0x400d8e22 in su_pthread_port_clone_main (varg=0xbf5ff8ec) at
> su_pthread_port.c:321
> #19 0x4014b0ce in pthread_start_thread (arg=0xbf3ffc00) at manager.c:291
> (gdb)
>
-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] No buffer space available
Hi there, I'm getting a bunch of these after a large number of calls in my application: tport_vsend(0x81276a8): No buffer space available with (s=9 UDP/10.40.0.9:5060)\par incoming_reply: tport_tsend: error (No buffer space available) while sending 183 Session Progress for INVITE (1)\par tport_vsend(0x81276a8): No buffer space available with (s=9 UDP/10.40.0.9:5060)\par incoming_reply: tport_tsend: error (No buffer space available) while sending 183 Session Progress for INVITE (1)\par tport_vsend(0x81276a8): No buffer space available with (s=9 UDP/10.40.0.250:5060)\par incoming_reply: tport_tsend: error (No buffer space available) while sending 200 OK for UPDATE (3)\par tport_vsend(0x81276a8): No buffer space available with (s=9 UDP/10.40.0.250:5060)\par incoming_reply: tport_tsend: error (No buffer space available) while sending 500 Internal Server Error for UPDATE (3)\par tport_vsend(0x81276a8): No buffer space available with (s=9 UDP/10.40.0.30:5060)\par incoming_reply: tport_tsend: error (No buffer space available) while sending 183 Session Progress for INVITE (1)\par tport_vsend(0x81276a8): No buffer space available with (s=9 UDP/10.40.0.30:5060)\par incoming_reply: tport_tsend: error (No buffer space available) while sending 183 Session Progress for INVITE (1)\par tport_vsend(0x81276a8): No buffer space available with (s=9 UDP/10.40.0.9:5060)\par incoming_reply: tport_tsend: error (No buffer space available) while sending 183 Session Progress for INVITE (1)\par tport_vsend(0x81276a8): No buffer space available with (s=9 UDP/10.40.0.5:5060)\par incoming_reply: tport_tsend: error (No buffer space available) while sending 183 Session Progress for INVITE (1)\par tport_vsend(0x81276a8): No buffer space available with (s=9 UDP/10.40.0.9:5060)\par incoming_reply: tport_tsend: error (No buffer space available) while sending 183 Session Progress for INVITE (1)\par tport_vsend(0x81276a8): No buffer space available with (s=9 UDP/10.40.0.9:5060)\par nta: BYE (92840831): No buffer space available (105) with */[10.40.0.9]:5060\par Does anyone have a clue at the cause? Thanks. Fabio Margarido - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
Re: [Sofia-sip-devel] Assertion `sub && sub->sub_ref != 0' failed
Hey there On Dec 19, 2007 7:38 AM, <[EMAIL PROTECTED]> wrote: > Do you explicitly destroy any handles rather than unreffing them? > I remember I had some problem with posthumous event delivery in a corner case, > or something. Yes, I do. From what I understood from the documentation, this shouldn't be a problem. Should I call nua_handle_unref and then call nua_handle_destroy? Thank you Fabio - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
Re: [Sofia-sip-devel] No buffer space available
Hey there, sorry to keep replying to my own posts and asking for help, but these issues I'm having are constant and rather serious. I'm trying to figure out what's going on from the source code, but haven't gone much far. Can anyone with more in-depth knowledge of the stack have a look at the error messages below and try to help me figure out what's wrong? Thanks a lot. On Dec 18, 2007 5:13 PM, Fabio Margarido <[EMAIL PROTECTED]> wrote: > Hi there, > > I'm getting a bunch of these after a large number of calls in my application: > > tport_vsend(0x81276a8): No buffer space available with (s=9 > UDP/10.40.0.9:5060)\par > incoming_reply: tport_tsend: error (No buffer space available) while > sending 183 Session Progress for INVITE (1)\par > tport_vsend(0x81276a8): No buffer space available with (s=9 > UDP/10.40.0.9:5060)\par > incoming_reply: tport_tsend: error (No buffer space available) while > sending 183 Session Progress for INVITE (1)\par > tport_vsend(0x81276a8): No buffer space available with (s=9 > UDP/10.40.0.250:5060)\par > incoming_reply: tport_tsend: error (No buffer space available) while > sending 200 OK for UPDATE (3)\par > tport_vsend(0x81276a8): No buffer space available with (s=9 > UDP/10.40.0.250:5060)\par > incoming_reply: tport_tsend: error (No buffer space available) while > sending 500 Internal Server Error for UPDATE (3)\par > tport_vsend(0x81276a8): No buffer space available with (s=9 > UDP/10.40.0.30:5060)\par > incoming_reply: tport_tsend: error (No buffer space available) while > sending 183 Session Progress for INVITE (1)\par > tport_vsend(0x81276a8): No buffer space available with (s=9 > UDP/10.40.0.30:5060)\par > incoming_reply: tport_tsend: error (No buffer space available) while > sending 183 Session Progress for INVITE (1)\par > tport_vsend(0x81276a8): No buffer space available with (s=9 > UDP/10.40.0.9:5060)\par > incoming_reply: tport_tsend: error (No buffer space available) while > sending 183 Session Progress for INVITE (1)\par > tport_vsend(0x81276a8): No buffer space available with (s=9 > UDP/10.40.0.5:5060)\par > incoming_reply: tport_tsend: error (No buffer space available) while > sending 183 Session Progress for INVITE (1)\par > tport_vsend(0x81276a8): No buffer space available with (s=9 > UDP/10.40.0.9:5060)\par > incoming_reply: tport_tsend: error (No buffer space available) while > sending 183 Session Progress for INVITE (1)\par > tport_vsend(0x81276a8): No buffer space available with (s=9 > UDP/10.40.0.9:5060)\par > > nta: BYE (92840831): No buffer space available (105) with > */[10.40.0.9]:5060\par > > Does anyone have a clue at the cause? > Thanks. > > Fabio Margarido > - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
Re: [Sofia-sip-devel] No buffer space available
On Jan 3, 2008 10:21 AM, Pekka Pessi <[EMAIL PROTECTED]> wrote:
> The UDP socket has run out of buffer space. Manual page for sendmsg() says
>
>ENOBUFS
> The output queue for a network interface was full. This gener-
> ally indicates that the interface has stopped sending, but may
> be caused by transient congestion. (Normally, this does not
> occur in Linux. Packets are just silently dropped when a device
> queue overflows.)
>
> From my recollection of Linux nw code the sentence in parenthesis is
> no longer true.
>
> You can use tport tags TPTAG_UDP_RMEM() and TPTAG_UDP_WMEM() to adjust
> the amount of buffer space. On Linux systems, you should also consider
> adjusting rmem and wmem sysctls.
>
> --Pekka
I'll try fiddling with those, but in the meantime I had changed the
values for TPTAG_THRPSIZE and TPTAG_THRPRQSIZE and it seemed to help.
I haven't had any more of those buffer-related problems, but it is
possible that they have only been postponed, because my application
keeps crashing. I'm still getting SIGSEGVs like the one below:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 3076 (LWP 1749)]
0x40246c74 in free () from /lib/libc.so.6
Current language: auto; currently c
(gdb) bt
#0 0x40246c74 in free () from /lib/libc.so.6
#1 0x40246bf4 in free () from /lib/libc.so.6
#2 0x400ccc67 in su_home_unref (home=0xe87b568) at su_alloc.c:673
#3 0x4005c2d9 in msg_destroy (msg=0xe87b568) at msg.c:168
#4 0x40079f91 in incoming_reclaim_queued (rm=0x0, msg=0x0,
u=0xbf3ff97c) at nta.c:4924
#5 0x400895f5 in incoming_mass_destroy (sa=0x8127cd8, q=0xbf3ff97c)
at nta.c:6328
#6 0x40088403 in incoming_timer (sa=0x8127cd8, next=-1908420432) at nta.c:6288
#7 0x400710bf in agent_timer (rm=0x8126790, timer=0x81277a0,
agent=0x8127cd8) at nta.c:747
#8 0x400d74a5 in su_timer_expire (timers=0x8126ae4,
timeout=0xbf3ffab0, now={tv_sec = 3408295612, tv_usec = 540469})
at su_timer.c:533
#9 0x400d8573 in su_base_port_run (self=0x8126ac0) at su_base_port.c:334
#10 0x400d120a in su_root_run (self=0x81274d8) at su_port.h:310
#11 0x400d8e22 in su_pthread_port_clone_main (varg=0xbf5ff8dc) at
su_pthread_port.c:321
#12 0x4014b0ce in pthread_start_thread (arg=0xbf3ffc00) at manager.c:291
(gdb) up
#1 0x40246bf4 in free () from /lib/libc.so.6
(gdb) up
#2 0x400ccc67 in su_home_unref (home=0xe87b568) at su_alloc.c:673
673 su_alloc.c: No such file or directory.
in su_alloc.c
(gdb) p home
$1 = (su_home_t *) 0xe87b568
(gdb) p *home
$2 = {suh_size = 504, suh_blocks = 0x0, suh_lock = 0x0}
(gdb) up
#3 0x4005c2d9 in msg_destroy (msg=0xe87b568) at msg.c:168
168 msg.c: No such file or directory.
in msg.c
(gdb) p *msg
$3 = {m_home = {{suh_size = 504, suh_blocks = 0x0, suh_lock = 0x0}},
m_class = 0x8125808, m_oflags = 2,
m_object = 0xe87b604, m_maxsize = 0, m_size = 370, m_chain =
0xf39f098, m_tail = 0xcb761f8, m_chunk = 0x0, m_buffer = {{
mb_data = 0xf09f120 "p\031,\017ð\234¯\r200 OK\r\nVia:
SIP/2.0/UDP 10.40.0.250:5060;branch=z9hG4bK34849\r\nFrom:
;tag=14391SIPpTag0034849\r\nTo:
;tag=3N12cB7QHHFaN\r\nCall-ID:
34849-1439"..., mb_size = 1024, mb_used = 370, mb_commit = 0, mb_eos =
0, 0}}, m_stream = 0x0, m_ssize = 0, m_extract_err = 0,
m_set_buffer = 0, m_streaming = 0, m_prepared = 1, 0, m_next = 0x0,
m_parent = 0xe87b368, m_refs = 0, m_addrinfo = {
ai_flags = 0, ai_family = 2, ai_socktype = 2, ai_protocol = 17,
ai_addrlen = 16, ai_addr = 0xe87b5e0,
ai_canonname = 0x0, ai_next = 0x0}, m_addr = {{su_dummy = 2, su_family = 2,
su_array = "\002\000\023Ä\n(\000ú", '\000' ,
su_array16 = {2, 50195, 10250, 64000,
0 }, su_array32 = {3289579522, 4194314250,
0, 0, 0, 0, 0, 0}, su_sa = {sa_family = 2,
sa_data = "\023Ä\n(\000ú\000\000\000\000\000\000\000"}, su_sin
= {sin_family = 2, sin_port = 50195, sin_addr = {
s_addr = 4194314250}, sin_zero =
"\000\000\000\000\000\000\000"}, su_sin6 = {sin6_family = 2, sin6_port
= 50195,
sin6_flowinfo = 4194314250, sin6_addr = {in6_u = {u6_addr8 =
'\000' , u6_addr16 = {0, 0, 0, 0,
0, 0, 0, 0}, u6_addr32 = {0, 0, 0, 0}}}, sin6_scope_id =
0}}}, m_errno = 0}
(gdb)
You've told me before that they are probably related to some memory
overrun. I've ran my application under valgrind and there were no
errors reported for a single call, so I'm guessing it's something
related to concurrency under heavy load. Could you please try to give
me a hint of what I could be doing to overflow the stack's memory
space?
I'm really looking forward for your help. Thanks in advance.
Fabio Margarido
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual
Re: [Sofia-sip-devel] No buffer space available
On Jan 3, 2008 1:11 PM, Pekka Pessi <[EMAIL PROTECTED]> wrote: > 2008/1/3, Fabio Margarido <[EMAIL PROTECTED]>: > > I ran configure with --enable-ndebug, but the funny thing is I didn't > > see -DNDEBUG in the compilation commands anywhere. There's a detail in > > my implementation that I a little suspicious about. I have a class > > that represents a SIP call, and associated with each object of this > > class is a su_home_t instance. I don't know if that's a bad design > > decision, but if you feel that might be a problem, it could be > > changed. The destructor of this class calls su_home_unref for the > > object's instance of su_home_t. While I'm at it, the whole list of > > sofia calls my destructor does is, in order: > > > > nua_handle_magic, to obtain my context associated to the call, and > > then free on the pointer returned; > > And subsequent call to nua_handle_bind(nh, NULL)? > > > nua_handle_unref (it was nua_handle_destroy, but someone on the list > > suggested I changed it); > > Please, use nua_handle_destroy(). You may get events after nua_handle_unref() > > > nua_destroy_event (for all the saved events I have on a list in each > > object); > > su_home_deinit on the object's memory home. > > > Do you see any problem with this approach? I'm thinking of leaving the > > su_home_t of each object pointing to NULL instead of using > > su_home_init in the constructor and see where that goes. > > Unless you call nua_handle_destroy() you may get events from stack and > if you do not call nua_handle_bind(nh, NULL) the stack keeps your > stale pointer around and passes it to your callback in events... > > I send this to list, too.. Hi there, the main problem with my application seems to be fixed now, it proved to be concurrency corrupting the heap after all. Your tip about doing 'nua_handle_bind(nh, NULL)' was really helpful though, I wasn't doing it and it definitely helped. However there is still one issue causing me trouble. After I changed back to nua_handle_detroy() from nua_handle_unref(), as you suggested, I got a crash with a SIGABRT today, but the machine rebooted and I was unable to fetch any further info about it. I suspect it is the same issue I described in my other thread (http://sourceforge.net/mailarchive/forum.php?thread_name=1715019e0712120241j71323d0bs6ae65bd9bd60166c%40mail.gmail.com&forum_name=sofia-sip-devel), in which Mikhail Zabaluev suggested I used nua_handle_unref(). If I confirm this was indeed the same issue, what should I do? If I understand correctly, the right way is to use nua_handle_destroy(), but it has a known problem, is that it? Thanks again. Fabio Margarido - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
Re: [Sofia-sip-devel] No buffer space available
On Jan 22, 2008 3:27 PM, Pekka Pessi <[EMAIL PROTECTED]> wrote: > There was in deef memory corruption in nta if sending ACK failed.. I > push fix to darcs asap. > That's great to hear! I've been on vacation and haven't followed the list for a couple of weeks. Is the fix already in darcs? Is it in 1.12.8? Thanks. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
Re: [Sofia-sip-devel] 1.12.8 compilation error with openssl 0.9.6
On Jan 30, 2008 5:13 PM, Michael Jerris <[EMAIL PROTECTED]> wrote: > This code was added so the debugging from openssl would hit the sofia > callbacks. if you don't need tls support, you could easily build > without and not have the issue at all, otherwise, commenting that out > should be fine. Maybe we need to add a configure check if that > function is there and if so use it, otherwise, just print to stdout > like it has?? I don't need tls yet, but probably will in the not-so-distant future. A fallback to stdout would be great, so I don't have to upgrade my openssl. Thanks - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] 1.12.8 compilation error with openssl 0.9.6
Hi there, I tried to compile sofia-sip-1.12.8 today on a machine with an older kernel and older libraries and got this error: gcc -Wall -g -O2 -o .libs/sip-options sip-options.o ../libsofia-sip-ua/.libs/libsofia-sip-ua.so -lssl -lcrypto -lpthread -Wl,--rpath -Wl,/usr/local/lib ../libsofia-sip-ua/.libs/libsofia-sip-ua.so: undefined reference to `ERR_print_errors_cb' I dug around and googled a bit and found out that my machine's openssl is version 0.9.6, and apparently ERR_print_errors_cb isn't present in 0.9.6, only from 0.9.7 on. Is it really a pre-requisite for sofia now to have openssl >= 0.9.7? If so, shouldn't the configure script check for this? As I cannot change the library version on this machine, I simply commented out the lines in tport_tls.c which called ERR_print_errors_cb. This shouldn't give me major headaches, right? Thanks. Fabio Margarido - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] Strange crash with 1.12.8
Hi there,
I got the following crash during my performance tests this weekend:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 3076 (LWP 2008)]
0x4024a17a in malloc () from /lib/libc.so.6
Current language: auto; currently c
(gdb) bt
#0 0x4024a17a in malloc () from /lib/libc.so.6
#1 0x40249f68 in malloc () from /lib/libc.so.6
#2 0x400ccd6c in sub_alloc (home=0x572943c8, sub=0x4ba5ebc8, size=32,
zero=do_malloc) at su_alloc.c:482
#3 0x400cd37f in su_alloc (home=0x572943c8, size=32) at su_alloc.c:763
#4 0x40063673 in msg_header_alloc (home=0x572943c8, hc=0x401252e0,
extra=0) at msg_parser.c:2299
#5 0x40061d80 in header_parse (msg=0x572943c8, mo=0x57294464, hr=0x8130600,
s=0x5a3a77f8 "[EMAIL PROTECTED]: 1 ACK\r\nContact:
sip:[EMAIL PROTECTED]:5060\r\nMax-Forwards: 70\r\nSubject:
Performance Test\r\nContent-Length: 0\r\n\r\n", slen=22,
copy_buffer=0) at msg_parser.c:1114
#6 0x40061c7d in extract_header (msg=0x572943c8, mo=0x57294464,
b=0x5a3a77ef "Call-ID: [EMAIL PROTECTED]: 1
ACK\r\nContact: sip:[EMAIL PROTECTED]:5060\r\nMax-Forwards:
70\r\nSubject: Performance Test\r\nContent-Length: 0\r\n\r\n",
bsiz=153, eos=1, copy_buffer=0) at msg_parser.c:1071
#7 0x400616e8 in msg_extract (msg=0x572943c8) at msg_parser.c:903
#8 0x400e87f5 in tport_parse (self=0x40501db8, complete=1,
now={tv_sec = 3412712137, tv_usec = 504419}) at tport.c:2885
#9 0x400e85e5 in tport_recv_event (self=0x40501db8) at tport.c:2858
#10 0x400e835a in tport_base_wakeup (self=0x40501db8, events=1) at tport.c:2760
#11 0x400da79f in su_poll_port_wait_events (self=0x81316b8, tout=6) at
su_poll_port.c:590
#12 0x400d8b28 in su_base_port_run (self=0x81316b8) at su_base_port.c:342
#13 0x400d179a in su_root_run (self=0x81320d0) at su_port.h:310
#14 0x400d93b2 in su_pthread_port_clone_main (varg=0xbf5ff8dc) at
su_pthread_port.c:321
#15 0x4014f0ce in pthread_start_thread (arg=0xbf3ffc00) at manager.c:291
(gdb) up
#1 0x40249f68 in malloc () from /lib/libc.so.6
(gdb) up
#2 0x400ccd6c in sub_alloc (home=0x572943c8, sub=0x4ba5ebc8, size=32,
zero=do_malloc) at su_alloc.c:482
482 su_alloc.c: No such file or directory.
in su_alloc.c
(gdb) p sub
$1 = (su_block_t *) 0x4ba5ebc8
(gdb) p *sub
$2 = {sub_parent = 0x0, sub_preload = 0x0, sub_stats = 0x0,
sub_destructor = 0, sub_ref = 1, sub_used = 8, sub_n = 31,
sub_prsize = 0, sub_prused = 0, sub_hauto = 0, sub_auto = 0,
sub_preauto = 0, sub_auto_all = 0, 0, sub_nodes = {{
sua_size = 0, sua_home = 0, 0, sua_data = 0x0}, {sua_size = 0,
sua_home = 0, 0, sua_data = 0x0}, {sua_size = 0,
sua_home = 0, 0, sua_data = 0x0}, {sua_size = 0, sua_home = 0,
0, sua_data = 0x0}, {sua_size = 0, sua_home = 0, 0,
sua_data = 0x0}, {sua_size = 0, sua_home = 0, 0, sua_data =
0x0}, {sua_size = 0, sua_home = 0, 0, sua_data = 0x0}, {
sua_size = 0, sua_home = 0, 0, sua_data = 0x0}, {sua_size = 32,
sua_home = 0, 1450317896, sua_data = 0x56721848}, {
sua_size = 32, sua_home = 0, 1442187992, sua_data = 0x55f60ad8},
{sua_size = 0, sua_home = 0, 0, sua_data = 0x0}, {
sua_size = 0, sua_home = 0, 0, sua_data = 0x0}, {sua_size = 80,
sua_home = 0, 150857, sua_data = 0x59eaf390}, {
sua_size = 76, sua_home = 0, 1487017344, sua_data = 0x58a21580},
{sua_size = 0, sua_home = 0, 0, sua_data = 0x0}, {
sua_size = 0, sua_home = 0, 0, sua_data = 0x0}, {sua_size = 0,
sua_home = 0, 0, sua_data = 0x0}, {sua_size = 0,
sua_home = 0, 0, sua_data = 0x0}, {sua_size = 68, sua_home = 0,
1539973688, sua_data = 0x5bca2238}, {sua_size = 0,
sua_home = 0, 0, sua_data = 0x0}, {sua_size = 0, sua_home = 0,
0, sua_data = 0x0}, {sua_size = 32, sua_home = 0,
1127749488, sua_data = 0x43381770}, {sua_size = 0, sua_home = 0,
0, sua_data = 0x0}, {sua_size = 80, sua_home = 0,
1518436040, sua_data = 0x5a817ec8}, {sua_size = 0, sua_home = 0,
0, sua_data = 0x0}, {sua_size = 0, sua_home = 0, 0,
sua_data = 0x0}, {sua_size = 0, sua_home = 0, 0, sua_data =
0x0}, {sua_size = 0, sua_home = 0, 0, sua_data = 0x0}, {
sua_size = 0, sua_home = 0, 0, sua_data = 0x0}, {sua_size = 361,
sua_home = 0, 1513781024, sua_data = 0x5a3a7720}, {
sua_size = 0, sua_home = 0, 0, sua_data = 0x0}}}
(gdb) p home
$3 = (su_home_t *) 0x572943c8
(gdb) p *home
$4 = {suh_size = 504, suh_blocks = 0x4ba5ebc8, suh_lock = 0x0}
(gdb) p data
$5 = (void *) 0x0
Any ideas?
Thanks in advance.
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] NUTAG_WITH and msg_dup
Hi there, is it okay if I use NUTAG_WITH() passing a deep copy of the msg_t request (obtained with msg_dup) instead of the original msg_t structure? This is apparently not working for me... Thanks. Fabio - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
Re: [Sofia-sip-devel] NUTAG_WITH and msg_dup
Let me elaborate a little more on my previous e-mail, maybe someone can help me in a different way... As you can see from my previous messages to the list, I'm having problems with SIGSEGVs in my application... I'm trying to reproduce the problem under valgrind, but as it only happens under heavy load, the performance hit introduced by valgrind is changing the outcome, but I'm still trying... In the meantime, I analyzed my code and sofia's source and I believe the problem lies in the way I use nua_saved_event_t... My application interacts with other applications and must wait for answers from these applications before it can send a response to the request... So, for each call, I keep a stack of pointers to nua_saved_event_ts around, so I can use the last saved event in nua_respond() when the whole processing chain is complete... In the destructor of my 'call' class if pop the remaining elements (if any) from the stack and call nua_destroy_event() on them... If all goes well with the call there should be no event left unanswered int the stack when it's destructed, but when things start to escalate and thousands of calls are simultaneously active, the other applications can kill the call, for example, and then the stack would be populated when the call is destructed... If I understand correctly, nua_save_event() doesn't do a deep copy of the message being saved... So in practice my application and sofia are sharing different pointers to the same memory locations, and I believe those error conditions lead to some situation in which I call nua_destroy_event() and then the stack for some other reason tries to deallocate some portion of the same memory area again (or vice-versa). Maybe I'm way off here, does that make any sense? So what I was trying to do is get rid of those shared pointers, and thought of keeping pointers for msg_t (obtained via msg_dup()) instead of nua_saved_event_t, thus using NUTAG_WITH() in nua_respond instead of NUTAG_WITH_SAVED(), but that didn't seem to work out very well... I'm feeling a bit lost right now.. I don't know if I should change my application's design, or how... nua_handle_destroy() doesn't free all the saved events by any chance, does it? Any help will be much appreciated. Thanks in advance. On Wed, Feb 27, 2008 at 3:49 PM, Fabio Margarido <[EMAIL PROTECTED]> wrote: > Hi there, > > is it okay if I use NUTAG_WITH() passing a deep copy of the msg_t > request (obtained with msg_dup) instead of the original msg_t > structure? This is apparently not working for me... > Thanks. > > Fabio > - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] Assertion failed
Hi there, I've hit this today: nua_session.c:1974: nua_invite_server_preprocess: Assertion 'ss->ss_state >= nua_callstate_ready || ss->ss_state == nua_call_state_init' failed. I can't tell what has happening at the moment to trigger this error. Any thoughts? I've already asked this before but never got any answer: this is with a library compiled with --enable-ndebug. Is this flag working correctly? Thanks in advance. Fabio - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
Re: [Sofia-sip-devel] Assertion failed
The attached patch fixes the behavior of --enable-ndebug. No thoughts on the assertion? Thanks. On Wed, Mar 26, 2008 at 12:32 PM, Fabio Margarido <[EMAIL PROTECTED]> wrote: > Hi there, > > I've hit this today: > > nua_session.c:1974: nua_invite_server_preprocess: Assertion > 'ss->ss_state >= nua_callstate_ready || ss->ss_state == > nua_call_state_init' failed. > > I can't tell what has happening at the moment to trigger this error. > Any thoughts? > I've already asked this before but never got any answer: this is with > a library compiled with --enable-ndebug. Is this flag working > correctly? > Thanks in advance. > > Fabio > --- configure.orig 2008-03-29 09:27:02.0 -0300 +++ configure 2008-03-29 10:07:04.0 -0300 @@ -21315,7 +21315,7 @@ -if test x$enable_ndebug = yes; then +if test x$enable_ndebug = xyes; then NDEBUG_TRUE= NDEBUG_FALSE='#' else @@ -21338,7 +21338,7 @@ fi -if test x$enable_expensive_checks != no; then +if test x$enable_expensive_checks != xno; then EXPENSIVE_CHECKS_TRUE= EXPENSIVE_CHECKS_FALSE='#' else - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
Re: [Sofia-sip-devel] Assertion failed
On Tue, Apr 1, 2008 at 6:50 PM, Pekka Pessi <[EMAIL PROTECTED]> wrote: > Thanks for the patch. Please note that configure is generated from > configure.ac and assorted m4 files in m4 directory, which should be > fixed instead of configure. > Oops... zero knowledge in autotools causes this, sorry.. :) Hopefully this is the right one: --- sac-general.m4.orig 2008-01-17 12:45:31.0 -0200 +++ sac-general.m4 2008-04-02 08:32:20.0 -0300 @@ -325,7 +325,7 @@ AC_ARG_ENABLE(ndebug, [ --enable-ndebug compile with NDEBUG [[disabled]]], , enable_ndebug=no) -AM_CONDITIONAL(NDEBUG, test x$enable_ndebug = yes) +AM_CONDITIONAL(NDEBUG, test x$enable_ndebug = xyes) ]) dnl == @@ -339,7 +339,7 @@ if test $enable_expensive_checks != no; then AC_SUBST([TESTS_ENVIRONMENT], [EXPENSIVE_CHECKS=1]) fi -AM_CONDITIONAL(EXPENSIVE_CHECKS, test x$enable_expensive_checks != no) +AM_CONDITIONAL(EXPENSIVE_CHECKS, test x$enable_expensive_checks != xno) ]) > > I think your assertion problem has been fixed in the darcs version, I > think it was caused by a glare problem (re-INVITE sent by both > end-points simultaneously) that was not detected correctly. In the > current code, glare detection has been fixed and the assertion > removed. Great. As soon as I can, I'll give it a try. Thanks a lot. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] Another assertion falied
Hi there, I got this while randomly using my application today: nta.c:781: agent_timer: Assertion `!agent->sa_out.trying->q_head' failed. Any ideas on what might cause it? Thanks. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Register now and save $200. Hurry, offer ends at 11:59 p.m., Monday, April 7! Use priority code J8TLD2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
Re: [Sofia-sip-devel] Another assertion falied
This is with 1.12.8. No, I haven't tried current darcs yet. Is there something different there? I don't think I can easily reproduce this, I hadn't seen it before in many months. Fabio On Mon, Apr 7, 2008 at 9:13 AM, Michael Jerris <[EMAIL PROTECTED]> wrote: > What version of sofia-sip is this? Have you tried w/ current darcs? > > Mike > > > > On Apr 7, 2008, at 8:00 AM, Fabio Margarido wrote: > > > Hi there, > > > > I got this while randomly using my application today: > > > > nta.c:781: agent_timer: Assertion `!agent->sa_out.trying->q_head' > > failed. > > > > Any ideas on what might cause it? Thanks. > > > > - > > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > > Register now and save $200. Hurry, offer ends at 11:59 p.m., > > Monday, April 7! Use priority code J8TLD2. > > > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > > ___ > > Sofia-sip-devel mailing list > > Sofia-sip-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel > > > - > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Register now and save $200. Hurry, offer ends at 11:59 p.m., > Monday, April 7! Use priority code J8TLD2. > > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > ___ > Sofia-sip-devel mailing list > Sofia-sip-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel > - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Register now and save $200. Hurry, offer ends at 11:59 p.m., Monday, April 7! Use priority code J8TLD2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] How to obtain stack statistics from a NUA application
Hi there, is there a way for me to obtain the stack statistics via nta_agent_get_stats() from an application that uses NUA? If I try to access the nua_nta pointer in my nua_t object I get a compilation error. Thanks. Fabio - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
Re: [Sofia-sip-devel] How to obtain stack statistics from a NUA application
On Wed, Apr 16, 2008 at 9:42 AM, Pekka Pessi <[EMAIL PROTECTED]> wrote: > Currently, there is no way to do so. I guess doing so needs a new nua > level action with response event. Ouch... Can you plan on adding such a feature sometime, please? Thanks. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] 500 Overlapping Offer/Answer
Hi there, I'm observing strange behavior with sofia 1.12.8 in the following scenario: 1) My application receives INVITE with SDP 2) My application sends 183 with multipart/mixed payload (SDP + ISUP) 3) My application receives PRACK 4) My application sends 200 OK to PRACK 5) My application receives UPDATE with a new SDP 6) Sofia generates a '500 Overlapping Offer/Answer' response with Retry-After header Looking at the source code, my guess is that the test at nua_session.c:3222 (3377 in current darcs) is failing. Is it possible that Sofia doesn't consider the multipart/mixed payload in the 183 as an answer to the offer received in the INVITE, and thus does not update its internal offer/answer states correctly? Thanks in advance. Fabio - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
Re: [Sofia-sip-devel] 500 Overlapping Offer/Answer
On Wed, Apr 30, 2008 at 5:26 AM, Pekka Pessi <[EMAIL PROTECTED]> wrote: > You got it right. MIME multipart support (or its very limited nature) > requires the application to do all the SDP-related stuff by itself. I'm using NUTAG_MEDIA_ENABLE(0) and handling all of the negotiations. Additionally, what should I do to force Sofia to update its internal states when there are multipart payloads involved? Thanks. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
Re: [Sofia-sip-devel] 500 Overlapping Offer/Answer
Nothing? On Wed, Apr 30, 2008 at 8:55 AM, Fabio Margarido <[EMAIL PROTECTED]> wrote: > On Wed, Apr 30, 2008 at 5:26 AM, Pekka Pessi <[EMAIL PROTECTED]> wrote: > > You got it right. MIME multipart support (or its very limited nature) > > requires the application to do all the SDP-related stuff by itself. > > I'm using NUTAG_MEDIA_ENABLE(0) and handling all of the negotiations. > Additionally, what should I do to force Sofia to update its internal > states when there are multipart payloads involved? > Thanks. > - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] Overriding stack RSeq
Hi there, I'm trying to set a manually generated RSeq header with SIPTAG_RSEQ_STR() in nua_respond(), but 100rel 18X messages go out with a stack generated RSeq anyway. PRACK is not among my NUTAG_APPL_METHOD()s in this case. Is there something I'm missing or is this behavior expected? - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
Re: [Sofia-sip-devel] Overriding stack RSeq
Sorry to double post, but I've given this some more reading, and now
I'm a bit afraid of the answer I'm likely to get to my original
question. I've found this in the documentation for nta:
"The nta takes care of assigning a serial number to each reliable
response and resending them if no PRACK request is received"
And this in the documentation for nua_handle():
"Note that certain SIP headers cannot be saved with the handle. They
include Content-Length, CSeq, RSeq, RAck, and Timestamp."
Does this mean there is no way to change the RSeq header in outgoing
reliable 18X responses without modifying the stack's code in (or so I
believe) the lines below:
if (irq->irq_must_100rel ||
(sip->sip_supported &&
sip_has_feature(sip->sip_supported, "100rel"))) {
irq->irq_rseq = su_randint(1, 0x7fff); /* Initialize rseq */
}
?
On a side note, from what I've observed the number generated by this
su_randint() call doesn't seem very random. I've noticed it is always
around 10 digits long. Is that expected?
Thanks.
On Tue, Jun 17, 2008 at 2:13 PM, Fabio Margarido
<[EMAIL PROTECTED]> wrote:
> Hi there,
>
> I'm trying to set a manually generated RSeq header with
> SIPTAG_RSEQ_STR() in nua_respond(), but 100rel 18X messages go out
> with a stack generated RSeq anyway. PRACK is not among my
> NUTAG_APPL_METHOD()s in this case. Is there something I'm missing or
> is this behavior expected?
>
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
Re: [Sofia-sip-devel] Overriding stack RSeq
OK, I believe this has turned into a bug in the stack. I've noticed
some more details:
- When I send a 183 response with nua_respond() containing
SIPTAG_RSEQ() or SIPTAG_RSEQ_STR() the stack disregards my RSeq and
uses its own, and PRACK is treated correctly;
- When I send a 180 response in exactly the same way the stack uses my
supplied RSeq in the response, but when a PRACK is received with a
RAck header containing the number I supplied in the response RSeq,
sofia responds to the PRACK with '481 No Such Response'. I believe the
RSeq value internally stored with the leg information is not updated
when RSeq is supplied.
Is there a reason 183 and 180 are treated differently in this situation?
Thanks.
On Tue, Jun 17, 2008 at 4:47 PM, Fabio Margarido
<[EMAIL PROTECTED]> wrote:
> Sorry to double post, but I've given this some more reading, and now
> I'm a bit afraid of the answer I'm likely to get to my original
> question. I've found this in the documentation for nta:
>
> "The nta takes care of assigning a serial number to each reliable
> response and resending them if no PRACK request is received"
>
> And this in the documentation for nua_handle():
>
> "Note that certain SIP headers cannot be saved with the handle. They
> include Content-Length, CSeq, RSeq, RAck, and Timestamp."
>
> Does this mean there is no way to change the RSeq header in outgoing
> reliable 18X responses without modifying the stack's code in (or so I
> believe) the lines below:
>
> if (irq->irq_must_100rel ||
> (sip->sip_supported &&
> sip_has_feature(sip->sip_supported, "100rel"))) {
>irq->irq_rseq = su_randint(1, 0x7fff); /* Initialize rseq */
> }
>
> ?
>
> On a side note, from what I've observed the number generated by this
> su_randint() call doesn't seem very random. I've noticed it is always
> around 10 digits long. Is that expected?
> Thanks.
>
> On Tue, Jun 17, 2008 at 2:13 PM, Fabio Margarido
> <[EMAIL PROTECTED]> wrote:
>> Hi there,
>>
>> I'm trying to set a manually generated RSeq header with
>> SIPTAG_RSEQ_STR() in nua_respond(), but 100rel 18X messages go out
>> with a stack generated RSeq anyway. PRACK is not among my
>> NUTAG_APPL_METHOD()s in this case. Is there something I'm missing or
>> is this behavior expected?
>>
>
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
Re: [Sofia-sip-devel] NDEBUG enable not working...
Hi there... Yes, I've already sent a patch to fix this but it never got in I'm afraid... I've worked around this by setting CFLAGS manually when I run configure... Best regards On Thu, Jun 19, 2008 at 5:11 PM, Colin Whittaker <[EMAIL PROTECTED]> wrote: > I'm trying to get rid of the possibility of assert() by passing > --enable_ndebug to configure. > It does not seem to work. > I think the problem may be in m4/sac-general.m4 > Starting at line 323. > AC_DEFUN([SAC_ENABLE_NDEBUG],[ > AC_REQUIRE([SAC_TOOL_CC]) > AC_ARG_ENABLE(ndebug, > [ --enable-ndebug compile with NDEBUG [[disabled]]], > , enable_ndebug=no) > AM_CONDITIONAL(NDEBUG, test x$enable_ndebug = yes) > ]) > > Shouldn't the test be just $enable_ndebug = yes, without the 'x' ? > > Looks like enable_expensive_checks might have the same problem. > > Colin.. > > > - > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > ___ > Sofia-sip-devel mailing list > Sofia-sip-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel > - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
Re: [Sofia-sip-devel] Overriding stack RSeq
I've taken a stab at fixing the issues I reported earlier and have
come up with a solution for one of them. The attached patches address
the issue of not being able to use a user specified RSeq header when
1XX answers are sent reliably.
I'm not sure this is the best way to solve this issue, so someone
please review them. Also, sorry if the naming conventions are not
coherent with the rest of the code. Anyway, it works for me.
Additionally, I've figured out the other issue and the difference
between responding with 180 or 183. Turns out simply including and SDP
in the 180 response is not enough for the stack to understand it as
early media, I have to set NUTAG_EARLY_MEDIA() as well. In this case,
the 180 answer is not sent reliably and the RSeq header supplied by
the application is used as expected. But the associated nta_incoming_t
structure is not updated, and the PRACK is refused with 481. I've not
yet looked into this one.
Thanks.
On Wed, Jun 18, 2008 at 10:28 AM, Fabio Margarido
<[EMAIL PROTECTED]> wrote:
> OK, I believe this has turned into a bug in the stack. I've noticed
> some more details:
>
> - When I send a 183 response with nua_respond() containing
> SIPTAG_RSEQ() or SIPTAG_RSEQ_STR() the stack disregards my RSeq and
> uses its own, and PRACK is treated correctly;
> - When I send a 180 response in exactly the same way the stack uses my
> supplied RSeq in the response, but when a PRACK is received with a
> RAck header containing the number I supplied in the response RSeq,
> sofia responds to the PRACK with '481 No Such Response'. I believe the
> RSeq value internally stored with the leg information is not updated
> when RSeq is supplied.
>
> Is there a reason 183 and 180 are treated differently in this situation?
> Thanks.
>
>
--- nua_session.c 2008-06-05 12:33:41.0 -0300
+++ nua_session.c.new 2008-06-25 16:32:25.0 -0300
@@ -2278,6 +2278,15 @@
}
if (reliable && sr->sr_status < 200) {
+tagi_t const *t = tl_find_last(tags, siptag_rseq);
+if (t)
+ incoming_override_rseq(sr->sr_irq, ((sip_rseq_t *)t->t_value)->rs_response);
+else {
+ t = tl_find_last(tags, siptag_rseq_str);
+ if (t)
+ incoming_override_rseq(sr->sr_irq, strtoul((const char *)t->t_value, NULL, 10));
+}
+
sr->sr_response.msg = NULL, sr->sr_response.sip = NULL;
if (nta_reliable_mreply(sr->sr_irq, process_prack, sr, msg) == NULL)
return -1;
--- nta.c 2008-06-04 05:57:28.0 -0300
+++ nta.c.new 2008-06-25 16:37:30.0 -0300
@@ -10955,3 +10955,9 @@
return 0;
}
+
+void incoming_override_rseq(nta_incoming_t *irq, uint32_t rseq)
+{
+ if (irq != NULL)
+irq->irq_rseq = rseq;
+}
--- nta.h 2008-05-26 09:25:11.0 -0300
+++ nta.h.new 2008-06-25 16:39:19.0 -0300
@@ -323,6 +323,8 @@
SOFIAPUBFUN void nta_incoming_destroy(nta_incoming_t *irq);
+SOFIAPUBFUN void incoming_override_rseq(nta_incoming_t *irq, uint32_t rseq);
+
/* Functions for feature, method, mime, session-timer negotation */
SOFIAPUBFUN
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
Re: [Sofia-sip-devel] Overriding stack RSeq
On Fri, Jul 25, 2008 at 11:31 AM, Pekka Pessi <[EMAIL PROTECTED]> wrote: > Is it enough if you just set the initial RSeq? Yes, that's pretty much what I need. Sorry for not being clearer before. > The current nua code does not detect reliably sent preliminary > responses from the presence of RSeq header, but from the 100rel > feature tag in the Require header. If you modify your application to > include the suitable Require header, the 180 is sent reliably just > like 183. 183 is an exception, it is sent reliably even if the > application did not include the 100rel tag in the Require header if > UAC had included the 100rel in Supported header. Of course, it would > make sense to test the presence of RSeq header, too, however, only the > value from the initial 100rel response could be used, rest would be > overwritten by stack. Thanks for the explanation, I'll try to adapt my application as needed. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
Re: [Sofia-sip-devel] 200 OK answer to CANCEL with no "to-tag"
On Mon, Jul 21, 2008 at 11:49 PM, Magnus Correa Marques Russo
<[EMAIL PROTECTED]> wrote:
> Hello,
> it seems that Sofia-sip is not including a tag in the field "To" when
> answering a CANCEL,
Hi all,
I have also been having this problem and have come up with a hack to
make it work. I'm attaching the patch that I've applied to my stack
which apparently does the job. Please take a look and see if it's
useful.
Thanks.
Fabio
--- nta.c 2008-07-31 10:11:48.0 -0300
+++ nta.c.new 2008-07-31 14:46:55.0 -0300
@@ -181,6 +181,8 @@
sip_call_id_t const *i,
char const *from_tag,
char const *to_tag);
+static nta_leg_t *leg_find_call_id(nta_agent_t const *sa,
+ sip_call_id_t const *i);
static nta_leg_t *dst_find(nta_agent_t const *sa, url_t const *u0,
char const *method);
static void leg_recv(nta_leg_t *, msg_t *, sip_t *, tport_t *);
@@ -3075,6 +3077,17 @@
SU_DEBUG_3(("%s: no Via\n", __func__));
}
else {
+if (sip->sip_status && sip->sip_status->st_status > 100 &&
+sip->sip_to && !sip->sip_to->a_tag &&
+sip->sip_cseq && sip->sip_cseq->cs_method == sip_method_cancel) {
+ nta_leg_t *leg = leg_find_call_id(agent, sip->sip_call_id);
+ if (leg && leg->leg_local && leg->leg_local->a_tag) {
+sip_to_tag(msg_home(reply), sip->sip_to, leg->leg_local->a_tag);
+ } else {
+SU_DEBUG_3(("%s: cannot add To tag in CANCEL reply\n", __func__));
+ }
+}
+
if (tport == NULL)
tport = tport_delivered_by(agent->sa_tports, req_msg);
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] Memory leak in timeouts?
Hi there Pekka, back in April, I got this response to a question about an assertion regarding nta timers: > The code calculating the timeouts has flawed logic, the problem shows > up if the system clock is adjusted or the load is too high. I'd like to know if this issue has already been resolved in the darcs tree. I've noticed that when the system clock is adjusted sofia-sip apparently leaks memory. I'm still using 1.12.8 because of the other memory leaks in 1.12.9 that have been reported to the list. Are those fixed too? Thanks. Fabio - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
Re: [Sofia-sip-devel] Memory leak in timeouts?
Great. Thanks for your help.
Fabio
On Tue, Aug 5, 2008 at 7:30 PM, Colin Whittaker
<[EMAIL PROTECTED]> wrote:
>
> I think the memory leaks are still there if the Time of Day gets updated too
> far.
> It looks like su_monotime() was added, but the timers are not using it.
>
> I'm testing a fix that changes su_time() and forces it to be monotonic much
> like the way the kernel does monotonic time.
> The time of day will be off for su_time() but it didn't seem to hurt
> anything.
> I think the better fix is to change all the calls to su_time() for timers
> and call su_monotime() instead.
>
> Here is my code for the 1.12.6 version The function is su_time().,
>
> diff -r1.1 -r1.2
> 70a71,75
>> // attempt at making time monotonic
>> unsigned long prev_tv_sec = 0;
>> unsigned long prev_tv_usec = 0;
>> unsigned long mono_tv_sec_adj = 0;
>>
> 75a81,104
>> if ( prev_tv_sec &&
>> ( (tv->tv_sec > prev_tv_sec + 2) ||
>>(tv->tv_sec < prev_tv_sec) ) )
>> {
>> // Time warp.(someone set the clock or we fell asleep
>> over 2 seconds.)
>> // fix up our monotonic so we are in the same second as last
>> time
>> unsigned long adj;
>>
>> adj = (prev_tv_sec - tv->tv_sec);
>>
>> // if we were futher along in the second jump to the next.
>> if ( prev_tv_usec > tv->tv_usec )
>> {
>> adj++;
>> }
>> SU_DEBUG_2(("Clock slip detected, %ld seconds. Previous
>> Monotonic adjustment %ld. Current %ld sec, %ld usec, Prev %ld sec %ld usec",
>> adj, mono_tv_sec_adj, tv->tv_sec,
>> tv->tv_usec, prev_tv_sec, prev_tv_usec ));
>> mono_tv_sec_adj += adj;
>> }
>>
>> prev_tv_sec = tv->tv_sec;
>> prev_tv_usec = tv->tv_usec;
>> tv->tv_sec += mono_tv_sec_adj;
>>
>
> Colin..
>
> Fabio Margarido wrote:
>
> Hi there Pekka,
>
> back in April, I got this response to a question about an assertion
> regarding nta timers:
>
>
>
> The code calculating the timeouts has flawed logic, the problem shows
> up if the system clock is adjusted or the load is too high.
>
>
> I'd like to know if this issue has already been resolved in the darcs
> tree. I've noticed that when the system clock is adjusted sofia-sip
> apparently leaks memory.
> I'm still using 1.12.8 because of the other memory leaks in 1.12.9
> that have been reported to the list. Are those fixed too?
> Thanks.
>
> Fabio
>
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> Sofia-sip-devel mailing list
> Sofia-sip-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
>
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
Re: [Sofia-sip-devel] 200 OK answer to CANCEL with no "to-tag"
Hi there. Any news on this issue? Thanks a lot. On Thu, Jul 31, 2008 at 3:02 PM, Fabio Margarido <[EMAIL PROTECTED]> wrote: > On Mon, Jul 21, 2008 at 11:49 PM, Magnus Correa Marques Russo > <[EMAIL PROTECTED]> wrote: >> Hello, >> it seems that Sofia-sip is not including a tag in the field "To" when >> answering a CANCEL, > > Hi all, > > I have also been having this problem and have come up with a hack to > make it work. I'm attaching the patch that I've applied to my stack > which apparently does the job. Please take a look and see if it's > useful. > Thanks. > > Fabio > - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
Re: [Sofia-sip-devel] NUA: Handle error
Hi there,
you're not supposed to destroy the handle after sending the message. The
handle is your "call" representation, it should only be destroyed after
you're done processing all the requests and responses associated with it. In
your case, I believe it would be after you receive a response to the
message.
On Thu, Sep 4, 2008 at 8:08 AM, Diego Costantini
<[EMAIL PROTECTED]> wrote:
> Hi, I am getting this error while trying to send a message, does anyone
> have any idea hot to get more info to dig into the problem?
>
> I couldn't find anything around.
>
>
>
> nua: nua_r_message with invalid handle (nil)
>
>
>
> The piece of code around it is:
>
>
>
> nua_handle_t *handle;
>
>
>
> handle = nua_handle(nua, NULL, SIPTAG_TO_STR("sip:[EMAIL PROTECTED]:5068"),
> TAG_END());
>
>
>
> nua_message(handle,
>
> SIPTAG_TO_STR(to),
>
> SIPTAG_FROM_STR(from),
>
> SIPTAG_ALLOW_STR("INVITE,
> CANCEL, BYE, ACK, PUBLISH"),
>
>
> SIPTAG_EVENT_STR("vq-rtcpxr"),
>
>
> SIPTAG_ACCEPT_STR("application/sdp, message/sipfrag"),
>
>
> SIPTAG_CONTENT_TYPE_STR("application/vq-rtcpxr"),
>
>
> SIPTAG_CONTENT_LENGTH_STR(buf),
>
>
> SIPTAG_PAYLOAD_STR(message),
>
> TAG_END());
>
>
>
> nua_handle_destroy (handle);
>
>
>
> It is pretty straightforward, and it tells the problem is the handle, but I
> suspect it could be elsewhere.
>
> I don't know how to get more info.
>
>
>
> Thanks
>
>
>
> =
>
> Diego Costantini
>
> NEC Europe Ltd.
>
> NEC Laboratories Europe
>
> Network Research Division
>
>
>
> Kurfuersten-Anlage 36
>
> 69115 Heidelberg
>
> Germany
>
>
>
> [EMAIL PROTECTED]
>
> http://www.nw.neclab.eu
>
>
>
> =
>
>
>
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> Sofia-sip-devel mailing list
> Sofia-sip-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
>
>
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] Really fast retransmission of 200 OK responses
Hi there, I'm observing some strange behavior from sofia-sip when running heavy load tests on my application. The application is a B2BUA and the calls are originated by a SIPp script. The receiving end is another machine running a UAS SIPp script. When we start 500 calls per second, limited to 2 simultaneous calls with 100 seconds conversation time, the fist wave of calls are established with no errors or retransmissions. But as soon as these 2 first calls start to hangup and the subsequent calls are simultaneously generated, we see a lot of retransmissions and unexpected messages in SIPp. When this happens, sofia-sip starts printing "strange ACK from " messages on the screen. I've managed to isolate one call which showed odd behavior. We can see the INVITE received by Sofia, and the 200 OK response. After SIPp sends an ACK, a lot of 200 OK retransmissions exist, separated by approximately 10 usecs. Sofia then sends a BYE to this call even before SIPp has a chace to retransmit the ACKs, which come afterwards. Pekka, do you have any clue what might be happening? Can I get any other data to help understand this issue? If you want the trace I can provide it. Thanks a lot. Fabio - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
Re: [Sofia-sip-devel] Really fast retransmission of 200 OK responses
Hi Pekka, thanks for your attention. On Thu, Sep 11, 2008 at 10:00 AM, Pekka Pessi <[EMAIL PROTECTED]> wrote: > Profiling data would be useful, e.g,, there might be somewhere that > stack spends far too much time which starves the retransmission > handling. > Hmm... I believe that if I run my application under Valgrind it won't come even close to being able to handle the call rate we're using, and the results will be different. Is there another way to get such data which might be interesting to you? > A trace would be excellent, preferrably tcpdump on both hosts running > sipp and Sofia. > What I already have is a Wireshark trace obtained from the machine running SIPp (both SIPp scripts run on the same machine, bound to different network interfaces), with all the messages from the test. Would that suffice? I don't know how I can send this to you, however. The total size is about 250 MB. Any ideas? If you'd really rather have the tcpdump traces, I'll see if I can work on those. Thanks again. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
Re: [Sofia-sip-devel] Really fast retransmission of 200 OK responses
I forgot to mention that my sofia is compiled with --with-rt=no. We use an older 2.4 kernel with which this option causes compilation errors. Maybe this is relevant somehow. Thanks On Thu, Sep 11, 2008 at 10:30 AM, Fabio Margarido <[EMAIL PROTECTED]>wrote: > Hi Pekka, thanks for your attention. > > On Thu, Sep 11, 2008 at 10:00 AM, Pekka Pessi <[EMAIL PROTECTED]> wrote: > >> Profiling data would be useful, e.g,, there might be somewhere that >> stack spends far too much time which starves the retransmission >> handling. >> > > Hmm... I believe that if I run my application under Valgrind it won't come > even close to being able to handle the call rate we're using, and the > results will be different. Is there another way to get such data which might > be interesting to you? > > >> A trace would be excellent, preferrably tcpdump on both hosts running >> sipp and Sofia. >> > > What I already have is a Wireshark trace obtained from the machine running > SIPp (both SIPp scripts run on the same machine, bound to different network > interfaces), with all the messages from the test. Would that suffice? I > don't know how I can send this to you, however. The total size is about 250 > MB. Any ideas? > If you'd really rather have the tcpdump traces, I'll see if I can work on > those. > Thanks again. > - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
Re: [Sofia-sip-devel] P-Early-Media: supported
You can use SIPTAG_HEADER_STR(). See http://sofia-sip.sourceforge.net/refdocs/sip/sip__tag_8h.html#2ede8377bc75d6a0d14fadfa70cf Regards. Fabio On Thu, Oct 30, 2008 at 18:19, Jerry Richards <[EMAIL PROTECTED]>wrote: > Hello All, > > Is there an existing tag to include the "P-Early-Media: supported" header > in > an outbound INVITE? If not, perhaps it should be added? Setting > NUTAG_EARLY_MEDIA(1) in the nua_invite() does not generate the > P-Early-Media > header. > > Best Regards, > Jerry > > > - > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > ___ > Sofia-sip-devel mailing list > Sofia-sip-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel > - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] Retrying UDP does not send message to network
Hi there, I'm having a problem when I try to send a large INVITE with Sofia. When the stack detects that my INVITE exceeds the MTU and the default transport is UDP, it correctly tries to send it via TCP. However, if the TCP connection fails, when sofia tries to fall back to UDP again the INVITE does not get sent to the network. I've captured a log: nua: nh_create_handle: entering nua: nua_invite: entering nua(0x81429d8): sent signal r_invite nua: nua_stack_set_params: entering nta_leg_tcreate(0x40502908) nua(0x81429d8): adding session usage nua: unknown Content-Type: multipart/mixed nta: selecting scheme sip tport_tsend(0x8140540) tpn = */10.10.10.236:5060 tport_resolve addrinfo = 10.10.10.236:5060 tport_by_addrinfo(0x8140540): not found by name */10.10.10.236:5060 nta: INVITE (110482403) too large for UDP, trying TCP tport_tsend(0x81407e8) tpn = tcp/10.10.10.236:5060 tport_resolve addrinfo = 10.10.10.236:5060 tport_by_addrinfo(0x81407e8): not found by name tcp/10.10.10.236:5060 tport_alloc_secondary(0x81407e8): new secondary tport 0x40501430 tport_base_connect(0x40501430): connecting to tcp/10.10.10.236:5060/sip tport(0x40501430): reset timer tport_queue(0x40501430): queueing 0x40505310 for tcp/10.10.10.236:5060 nta: sent INVITE (110482403) to tcp/10.10.10.236:5060 tport_pend(0x40501430): pending 0x40505310 for tcp/10.10.10.236:5060 (already 0) nta: timer shortened to 5000 ms nua(0x81429d8): call state changed: init -> calling nua: nua_application_event: entering nta: timer N3 fired, try UDP instead INVITE (110482403) tport_release(0x40501430): 0x40505310 by 0x40500a38 with (nil) nta: INVITE (110482403) TCP refused, trying UDP tport(0x40501430): reset timer nta: timer set next to 7676 ms nta: timer J fired, terminate 200 response incoming_reclaim_all((nil), (nil), 0xbe7ff9ac) nta_incoming_timer: 0/0 resent, 0/0 tout, 1/4 term, 1/4 free nta: timer set next to 2104 ms nta: timer J fired, terminate 200 response incoming_reclaim_all((nil), (nil), 0xbe7ff9ac) nta_incoming_timer: 0/0 resent, 0/0 tout, 1/3 term, 1/3 free nta: timer set next to 7238 ms nta: timer J fired, terminate 200 response incoming_reclaim_all((nil), (nil), 0xbe7ff9ac) nta_incoming_timer: 0/0 resent, 0/0 tout, 1/2 term, 1/2 free nta: timer set next to 2693 ms nua: nua_cancel: entering nua(0x81429d8): sent signal r_cancel nua: nua_stack_set_params: entering nta: delayed sending CANCEL (110482403) nta: timer J fired, terminate 200 response incoming_reclaim_all((nil), (nil), 0xbe7ff9ac) nta_incoming_timer: 0/0 resent, 0/0 tout, 1/1 term, 1/1 free nta: timer set next to 7215 ms nta: timer B fired, timeout INVITE (110482403) nua(0x81429d8): call state changed: calling -> terminated nta: outgoing_free(0x40500a38) nua(0x81429d8): removing session usage nta_leg_destroy(0x40502908) nta_leg_destroy((nil)) nta_outgoing_timer: 0/0 resent, 1/1 tout, 0/0 term, 0/2 free nta: timer set next to 5000 ms nua: nua_application_event: entering nua: nua_ack: entering nua(0x81429d8): sent signal r_ack nua: nua_application_event: entering nua: nua_application_event: entering nua: nua_application_event: entering nua: nua_handle_magic: entering nua: nua_handle_bind: entering nua: nua_handle_destroy: entering nua(0x81429d8): sent signal r_destroy nta_leg_destroy((nil)) nta: timer K fired, terminate CANCEL (110482403) outgoing_reclaim_all((nil), (nil), 0xbe7ff9ac) nta_outgoing_timer: 0/0 resent, 0/0 tout, 1/1 term, 1/1 free nta: timer not set tport_connected(0x40501430): events ERR nta_agent: tport: Connection timed out tport_close(0x40501430): tcp/10.10.10.236:5060/sip After the "nta: INVITE (110482403) TCP refused, trying UDP" message nothing happens until the timers start firing. Shouldn't the UDP INVITE be sent immediately after sofia verifies that TCP has failed? Is it waiting on a timer of some sort? Am I missing something here? This is with Sofia-SIP 1.12.10. Thanks in advance. Fabio -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] Short headers inside multipart body not parsed
Hi there, I'm observing a problem when our application receives an INVITE with a multipart/mixed payload that contain 'Content-Type' headers in the short form inside each part, like the following example: --unique-boundary-1 c: application/SDP v=0 (...) --unique-boundary-1 c: application/ISUP;version=BR_ETSI121;base=ETSI121 Content-Disposition: signal;handling=optional (...) --unique-boundary-1-- The msg_multipart_t structure that results from msg_multipart_parse() has NULL mp_content_type fields. When the headers are in the long form, everything is parsed correctly. The 'Content-Type' header in the message before the payload is also in the short form and is parsed correctly. I'm searching the source code for the possible bug, but maybe you'll find it faster than me. Thanks in advance. -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
Re: [Sofia-sip-devel] Short headers inside multipart body not parsed
On Tue, Feb 10, 2009 at 12:26, Pekka Pessi wrote: > Could you please check that all the header class structures in > msg_mime.c have correct short forms? > Thanks for the quick response. I believe the short forms are correct indeed. Fabio. -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
Re: [Sofia-sip-devel] Short headers inside multipart body not parsed
Besides, couldn't this (compact form enabled) be made the default? Thanks again. On Tue, Feb 10, 2009 at 14:01, Fabio Margarido wrote: > On Tue, Feb 10, 2009 at 12:26, Pekka Pessi wrote: > >> Could you please check that all the header class structures in >> msg_mime.c have correct short forms? >> > > > Thanks for the quick response. > I believe the short forms are correct indeed. > > Fabio. > > -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
Re: [Sofia-sip-devel] Short headers inside multipart body not parsed
Hi Pekka, still on this issue, I've observed that simply changing the Makefile.am you mentioned did not solve the problem. Compact headers inside multipart bodies are still not being parsed correctly. Thanks -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
[Sofia-sip-devel] No BYE sent after error in re-INVITE
Hi there, I'm observing some odd behavior from Sofia in the following scenario: I have an answered call and receive a re-INVITE; when I generate an error for the re-INVITE (480, for instance) and then try to send a BYE and destroy the leg in the sequence, the BYE is not sent to the network. This is what the log shows with SOFIA_DEBUG=9: nua: nua_respond: entering nua(0x985ddb8): sent signal r_respond nua: nua_bye: entering nua(0x985ddb8): sent signal r_bye nua(0x985ddb8): ready call updated: received received offer nua: nua_stack_set_params: entering nua: nua_invite_server_respond: entering tport_tsend(0x985cb50) tpn = UDP/10.0.66.27:5060 tport_resolve addrinfo = 10.0.66.27:5060 tport_by_addrinfo(0x985cb50): not found by name UDP/10.0.66.27:5060 tport_vsend returned 409 nta: sent 480 Temporarily Unavailable for INVITE (111410412) nua(0x985ddb8): removing session usage nua(0x985ddb8): call state changed: ready -> terminated nta_leg_destroy(0x985e980) Is this behavior expected? Thanks in advance. -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
Re: [Sofia-sip-devel] No BYE sent after error in re-INVITE
On Mon, Feb 23, 2009 at 12:30, Pekka Pessi wrote: > When you return 480 to re-INVITE, nua considers the dialog terminated and > clears its state. I wonder why re-INVITEs are treated different (if indeed they are). I believe this could cause other problems, as section 12.2.2 of the RFC states: "Requests sent within a dialog, as any other requests, are atomic. If a particular request is accepted by the UAS, all the state changes associated with it are performed. If the request is rejected, none of the state changes are performed." In my case, my application is a B2BUA. I've noticed this problem in a scenario in which the call is established and the receiving end generates a re-INVITE. The originating end answers with the 480, which is ACKed, and then nothing happens. The end that generated the re-INVITE chooses not to disconnect the call and the conversation should still be going on. What happens next is that after some time, the original caller chooses to hang up, and sends a BYE. nua correctly answers the BYE, but when my application tries to hang up the second leg (the one that received the re-INVITE), nothing happens and the receiving end wastes resources until the person decides to hang up too because of the lack of audio. > In that sense, the behaviour is as expected. Nua > should probably allow sending BYE after the session has otherwise been > cleared, however. I'd appreciate that very much as I believe this is a fairly serious problem in our scenario. Thanks a lot. Fabio -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H___ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
Re: [Sofia-sip-devel] nua_prack() Not Including RAck and RSeq
On Thu, Feb 26, 2009 at 14:10, Jerry Richards wrote:
> Another issue related to nua_prack(): The RAck and RSeq headers are
> missing
> in the outbound PRACK message.
>
Hi Jerry,
about your last issue, you have to include RAck in your PRACK manually.
Quoting the answer I got from Pekka back when I was facing problems with
PRACK:
You need the response sequence number (RSeq) from the 180 response in
> the RAck header. The following should work:
>
> {
> sip_rack_t rack[1];
>
> sip_rack_init(rack);
> rack->ra_response = sip->sip_rseq->rs_response;
> rack->ra_cseq = sip->sip_cseq->cs_seq;
> rack->ra_method = sip->sip_cseq->cs_method;
> rack->ra_method_name = sip->sip_cseq->cs_method_name;
> nua_prack(call_handle, SIPTAG_RACK(rack), TAG_END());
> }
Regarding RSeq, as you can also see in the quote above, it's not supposed to
be present in PRACK, but in the 18X which you're PRACKing.
Regards.
--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
