Re: [Sofia-sip-devel] msg_header_format issue (?)
2009/1/16 Andrew Rechenberg Lists flux...@resurgent.com: I've got the NTLM code returning a Base 64 encoded auth challenge but when I try to run my gssapi char * variable through msg_header_format the actual value of the variable is being modified/overwritten somehow. Interesting... Can you run your code under valgrind? Sounds like a fandango en core problem... I don't believe so. I'm using Apple XCode's integrated interface to GDB to step through my code (the code has a .ar of the sofia code compiled in and I'm using the iPhone simulator to run my code. I'm modified my code so that the pointer isn't getting overwritten now by memcpy'ing the data into the ar struct, however I still am only getting part of the gssapi-data. The amount of data alloc'd for the Authorization header is well short of what is needed and I only get 4 bytes in the portion of the header I set aside for it (the gssapi-data=%s portion. The %s only has 4 character in it). The idea is to try to print header in a small buffer, and if it does not fit, allocate bigger one. If snprintf() works (and why it should not??), there should be no overflow. I have to be doing something wrong, but I have no idea what. :( What the snprintf() returns on the first round, what is the value it returns? -- Pekka.Pessi mail at nokia.com -- 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
Re: [Sofia-sip-devel] SOA_TAG_ACTIVE_AUDIO meaning
2009/1/15 Inca Rose incar...@gmail.com: I don't actually understand when the SOA_TAG_AUDIO_ACTIVE is present, and if it present what it represents. You are not alone. ;) For example in an outgoing INVITE is is present in the first callback ( INVITE Sent ) with active_audio=3. I suppose this means that the Local Offer SDP is full duplex ( send receive ). It is also present in Trying and Ringing when those responses arrives without SDP. So it still flags that the Local SDP is full-duplex ??? And it again is present, for example, in 181 (Forward call), that also has no SDP. I'm getting confused on how to interpret this flag and when to get it (SOA_TAG_ACTIVE_AUDIO). When included in nua_i_state event, it should indicate the current or proposed direction of media. When included in nua_r_invite events, it should indicate the the direction of media from remote end. It should probably be not included in in the event tags if there is no answer/offer in the returned response. -- Pekka.Pessi mail at nokia.com -- 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] Recent automake changes
I'm feeling a bit uneasy with this patch. If anyone developing with Darcs version has any kind of problems with automake or building Sofia SIP with this patch please report them. Tue Jan 13 18:10:10 EET 2009 Pekka Pessi first.l...@nokia.com * rules/silent.am: silence. at last. M ./Makefile.am -2 +5 M ./libsofia-sip-ua-glib/Makefile.am +2 M ./libsofia-sip-ua/Makefile.am +2 A ./rules/silent.am M ./rules/sofia.am +2 -- Pekka.Pessi mail at nokia.com -- 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] Sending outgoing transaction with TCP instead of UDP
Hi all, In a stateful NTA, I am getting SIP SUBSCRIBE from a sip client using TCP connection, and I would like to send back the NOTIFY messages to the subscriber also using TCP, instead of UDP. I found that nta_outgoing_tcreate() uses UDP by default, and I didn't found any way to make it use TCP. I tried to put my own request_url in the nta_outgoing_tcreate function like sip:u...@whatever.com;transport=TCP, and it correctly adds it to the outgoing message, but still it's sending it with UDP. How can I make this work? Thanks in advance, -Aleksander -- 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
Re: [Sofia-sip-devel] How to debug sofia-sip
On date Thursday 2009-01-15 19:35:44 +0200, Pekka Pessi phoned this: 2009/1/14 Stefano Sabatini ssabat...@reilabs.com: I'm trying to debug sofia-sip. I'm configuring with this command: CFLAGS=$CFLAGS -ggdb -O0 ./configure --prefix=$HOME and I can see the symbols in the output libs and the same for the lines of code (using nm -sol), yet it seems I cannot enter the sofia functions with gdb. What am I missing? Do I need some special trick when configuring in order to be able to debug sofia? Nope, I do that all the time. ;-) Are you sure that you are loading with the library you have compiled with debug options, or does your application pull in a system library, for instance? Doh, I'm stupid, I forgot to reset my LD_LIBRARY_PATH to some meaningful value, now gdb and sofia are working as good pals and I can debug sofia. Much thanks! Regards -- 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
Re: [Sofia-sip-devel] msg_header_format issue (?)
The idea is to try to print header in a small buffer, and if it does not fit, allocate bigger one. If snprintf() works (and why it should not??), there should be no overflow. What the snprintf() returns on the first round, what is the value it returns? My data gets overwritten before we even get to the vsnprintf. The first msg_header_alloc before the for() loop in msg_header_vformat() in msg_header_make.c is where my stuff is getting overwritten :( To be more precise, my data is fine up until sub_alloc is called in su_alloc which is called from msg_header_alloc. Once I step into sub_alloc() then the value of my Base 64 response variable is modified. Confidentiality Notice: This e-mail message including attachments, if any, is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. If you are the intended recipient, but do not wish to receive communications through this medium, please so advise the sender immediately. -- 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
Re: [Sofia-sip-devel] ETSI Testing: Originating Call and BYE
2009/1/16 Pekka Pessi ppe...@gmail.com: 2009/1/16 Paulo Pizarro paulo.piza...@gmail.com: 17.1.1.3: ... The To header field in the ACK MUST equal the To header field in the response being acknowledged, and therefore will usually differ from the To header field in the original request by the addition of the tag parameter. This refers to ACK to 3XX/4XX/5XX/6XX? Looks like we have a bug there, I've pushed the fix to darcs. Not only, but to the 2xx response too. All next requests (ACK/BYE/etc) within this dialog must have the same TO header that this final response. This is done for backwards compatibility with RFC 2543 for dialog identification. According with the third paragraph in 12.2.1.1. I think 12.2.1.1. talks about original request, not about final response to initial request? 12.1.2 talsk about setting remote URI from To header field; however, it does not say whether to use To header field from response or from request. 12.1.1.1 then mentions that for 2543-compatibility To header field from original request should be used. I agree with you that the TO header field from original request should be used... Maybe I am not understanding correctly the ETSI tests. What do you think? SIP_CC_OE_CE_V_017 Ref: RFC 3261 [1] sections 12.2.1.1, 13.2.2.4, figure 5 and 17.1.1.3. Purpose: Ensure that the IUT when an INVITE client transaction is in the Calling state, on receipt of a Success (200 OK) response sends an ACK request with the To header set *to the same value as in the received final response*. SIP_CC_OE_CR_V_001 Ref: RFC 3261 [1] sections 12.2.1.1 and 15. Purpose: Ensure that the IUT, once a dialog has been established, to release it sends a BYE request with a *To header set to the same value as in the last received final response*. SIP_CC_OE_CR_V_002 Ref: RFC 3261 [1] sections 12.2.1.1 and 15. Purpose: Ensure that the IUT, once a dialog has been established with a final response in which the TAG in the To header was omitted, to release it sends a BYE request *with an identical To header without TAG value*. - SIP_CC_OE_CE_V_041: A second final response 2XX with a different Record-Route in the same INVITE transaction should change the Route header of the resent ACK. Sofia ignores the second Record-Route header and re sends the ACK exactly as the first one. I think the second paragraph in 13.2.2.4 refers to early dialogs; the route set should not change after first 2XX to that dialog. (The wording says otherwise, however.) I agree with you, it's right that the route set should not change after first 2xx to that dialog. A second final response 2XX with a different Record-Route in the same INVITE transaction only makes sense in the fork scenarios. I made a new test with a fork scenario, and sofia did not sent the second ACK with the new route set for the new dialog. It seems like the hairy fork bug :) So, Is it possible to help you to fix this fork bug? Or it is not advisable ... :) We need more rigorous testing, having those ETSI cases as check test cases (see check_nua.c) would make me confident. Of course, if you are not afraid sharp shards of fragile C code, you can have a peek inside NUA internals... -- Pekka.Pessi mail at nokia.com -- 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
