Re: [Sofia-sip-devel] Multiple ethernet interface support?

[Pekka Pessi]

2009/2/9  :
> To think of it, a simple heuristic would be to look at the routing table and
> see which interface has the default route. This should work in most cases,
> e.g. VPN. Pekka, what do you think?

That would be a good idea. su_localinfo() could prefer the iface
(and/or) address with default route.

-- 
Pekka.Pessi mail at nokia.com

--
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] IPv6 Link Address Bind Fail

[Pekka Pessi]

2009/2/11 Jerry Richards :
> Anyone know why sofia-sip's tport UDP bind() invocation is happy if I use
> the phone's IPv6 Global address, but gets an error (Invalid Argument) when I
> use the phone's IPv6 Link address?

You should somehow tell bind(2) which interface to use (don't ask me
why; there is probably a good reason for that).

-- 
Pekka.Pessi mail at nokia.com

--
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] Stack crash when the IP on the device changes

[Pekka Pessi]

2009/2/11 Inca Rose :
> I'm experiencing a crashing when the IP on the machine where the Sofia SIP
> stack runs changes.
> I am getting the following error :
> Assertion failed: (su_port_own_thread(self)), function
> su_kqueue_port_register, file
> /sofia-sip-1.12.10/libsofia-sip-ua/su/su_kqueue_port.c, line 200.
> Program received signal:  "SIGABRT".

Uh-oh. Looks like nw change detection used wrong root pointer. I
suspect that is a victim of bit rot, perhaps it should be implemented
for Linux with netlink...

> I also found the following code in nua_register.c
> if nw_updates is initialized with NUA_NW_DETECT_TRY_FULL the
> case NUA_NW_DETECT_ONLY_INFO: will never happens. This is the desired
> behavior ?

Probably not. The nw_updates should come from nua_global_preferences.

I pushed fixes to those issues, but I'd be interested in finding where
it now crashes..

-- 
Pekka.Pessi mail at nokia.com

--
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] NTLM patch questions

[Pekka Pessi]

2009/2/4 Andrew Rechenberg Lists :
> I have the NTLM code in Sofia working about 95% now (with regard to
> authenticating to a Microsoft Office Communications Server 2007) but I
> have some questions as to the proper places to put things before I
> submit a patch (multiple patches (?)).

That sounds cool. Tp-sofiasip sure needs it ;-)

> In its current incarnation the NTLM code relies on a couple of extra
> dependencies - zlib and iconv are the only ones as far as I can
> remember.  Zlib is used for one function call to generate an NTLM
> signature used to sign the SIP requests.  Iconv is used to convert
> usernames, passwords, and domains to UTF-16LE.

NTLM uses some zlib hash? Yikes.

Do you know if the UTF-16LE conversion is mechanical or does it
involve some kind of case conversions, so, like, converting username
YrjöMöykkälä to YRJÖMÖYKKÄLÄ? If it is mechanical, utf8 to utf16
should be relative trivial (in fact, I think there are some ancient
Sofia code doing utf-8 to ucs-2 bmp).

> All of the NTLM code is just ported from the SIPE project (SIP for
> Exchange plugin for the Pidgin IM client - http://sipe.sourceforge.net/,
> http://repo.or.cz/w/siplcs.git).  Thanks to Gabriel Burt for him writing
> the initial code and for help troubleshooting the port.
>
> I'm not sure what your stance is on adding more dependencies to Sofia,
> but they would only be added if the user wanted to compile the library
> with NTLM support.  I tried to keep the additions to a minimum.

> I have added some fields to the auth_challenge_t and auth_response_t
> structs however those structs are defined in auth_digest.h.  Should I
> move my bits to auth_ntlm.h and create auth_ntlm_challenge_t and
> auth_ntlm_response_t structs or leave them where they are?  If I create
> new structs will that interfere with any other bits of the iptsec code
> that will require additional modifications?

It is hard to say yes or aye without seeing the code... Could you post
your modified code (publish it on internet, to the list or to me
personally)?

-- 
Pekka.Pessi mail at nokia.com

--
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] Question on adding code to NTA for MS OCS SRV resolution

[Pekka Pessi]

2009/2/6 Andrew Rechenberg Lists :
> OK, I've added code to nta.c for the SRV records, however this line is
> tripping me up:
>
> if (strcmp(tpname, "*")) /* Looking for only one transport */
>  break;
>
> I've dug through the code and can't find out how to set this tpname.  Is
> there an NTATAG that I can use to set the tpname to "tls" so that it
> looks up all of the sipdns_tports[] that have "tls" instead of stopping
> at the first one?

I'm afraid that this is the sf.net bug #1292657, open since 2005. I'll
have a peek in the resolving code if something could be done with
reasonable effort...

-- 
Pekka.Pessi mail at nokia.com

--
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] Authentication-Info, Allow-Events, and Contact header parsing

[Pekka Pessi]

2009/2/3 Andrew Rechenberg Lists :
> My Sofia-based application is talking to a Microsoft OCS 2007 server and
> I believe, in true MS fashion, that certain headers are not quite in
> adherence to the RFCs.  Could it be that Sofia is not parsing those
> headers as a result of them not being standard?

>   Authentication-Info: NTLM rspauth="01002DBA2B7889FDE4C9",
> srand="E8CDC093", snum="1", opaque="F06AE926", qop="auth",
> targetname="OCS1.flux.local", realm="SIP Communications Service"

Authentication-Info is non-standard (MS-version borrows the syntax
from WWW-Authenticate, it seems to me). I have not checked, but the
rest of the comma-separated fields should be in ai_items[] array.

Please note that sip->sip_authentication_info->ai_common->h_data is
not valid if the parser has not been asked to cache the unparsed
contents (TPORT_LOG environment variable forces the parser to do
caching. It might be quite confusing if your code works with debugging
logs on, but does not when they are turned off).

>   Allow-Events:
> vnd-microsoft-provisioning,vnd-microsoft-roaming-contacts,vnd-microsoft-
> roaming-ACL,presence,presence.wpending,vnd-microsoft-roaming-self,vnd-mi
> crosoft-provisioning-v2

> The Allow-Events information in sip->sip_allow_events seems to only
> contain the first entry (in my case I only see
> "vnd-microsoft-provisioning" in the debugger).
> sip->sip_allow_events->k_next is NULL.

Allow-Events is parsed as a "list" header, that is, instead of having
separate sip_allow_events_t structure for each token, tokens are
stored in k_items. So vnd-microsoft-roamin-contacts should be in
k_items[1] (In retrospective, that is feature that overtly complicates
header processing).

> Also, the sip->sip_contact information only has pieces of the full
> contact line listed above.

> In particular I need to keep track of the gruu="*" information in the
> Contact header, and some additional information in the
> Authentication-Info, and Allow-Events headers.

The params from Contact URL are as a single string in
m_url->url_params (you can use url_param() function to access any of
them). The header parameters (like gruu, outside <>) are in m_params[]
array.

-- 
Pekka.Pessi mail at nokia.com

--
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] tport_listen patch

[Pekka Pessi]

2009/2/11 Della Betta Filippo :
> tport_listen, when the address is already in use returns error, but fails to 
> set errno.
> I suggest the attached patch to overcome this bug.

Thanks. Applied.

-- 
Pekka.Pessi mail at nokia.com

--
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] Using STUN

[Pekka Pessi]

2009/2/11 Bengt Werstén :
> We have got sofia-SIP to work when no NAT is involved but now we need a NAT
> solution using STUN. So far I have added the STUN define and changed my
> register from:
>

I think the STUN code was never really polished, the most of the
implementation is from pre-bis era. I'm afraid the way Sofia SIP uses
STUN is not really valid and fails in most cases (I think it mostly
assumes NATs are full-cone).

> Even if the STUN server
> is responding with a correct IP the REGISTER sent with a strange contact
> header "". Sofia SIP
> prints out this during the process:
>
> stun: Timeout no. 1, retransmitting.
>
> tport_stun_bind_cb: stun_discovery_done
>
> stun: Timeout no. 1, retransmitting.
>
> tport_stun_bind_cb: stun_discovery_done
>
> stun: Timeout no. 2, retransmitting.
>
> stun: Timeout no. 3, retransmitting.
>
> stun: Timeout no. 4, retransmitting.

> Is there any examples on how to enable STUN since it seems that I do
> something wrong but I cannot figure out what. Any help is very much
> appreciated.

Your wireshark message traces would be very helpful trying to figure
out what goes wrong there...

-- 
Pekka.Pessi mail at nokia.com

--
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] NAT keep-alive

[Pekka Pessi]

2009/2/11 Bengt Werstén :
> I have a problem with NAT usage. First I thought I needed STUN but the rport
> thing did it so much better and now it works fine doing a register. The
> connect fields looks perfect but the problem now is that the keep-alive
> mechanism does not work.

The first OPTIONS is used to check that there is nothing fishy with
NAT and SIP server. Unfortunately, it looks like there is something
fishy here.

> As I understand it Sofia-SIP send OPTIONS to itself to keep the NAT happy.
> The problem is that both SIP (IMS actually) servers I have tested with reply
> using a different source port as the sent to. I try to illustrate where is
> goes wrong:
>
> Sofia SIP (from port X to port 5800) -> REGISTER -> NAT (from port Y to port
> 5800) -> Server // Fine so far
>
> … Authentication and things
>
> Server (from port 5800 to port Y) -> 200 OK -> NAT (from port 5800 to port
> X) -> Server // Fine so far
>
> Sofia SIP (from port X to port 5800) -> OPTIONS -> NAT (from port Y to port
> 5800) -> Server // Fine so far
>
> Server (from port 5801 to port Y) -> 200 OK -> NAT (5801 is not 5800 so NAT
> throws this away)

> After a while Sofia-SIP prints:
>
> outbound(015D0100): FAILED to validate 
> outbound(015D0100): FAILED with 408 Request Timeout

> It there any workaround for this? I cannot change the NAT or SIP Server
> behaviors. I really like it to work independent of SIP server assuming that
> it supports rport.

Assuming that you turn off the contact validation (AFAIK add
"no-validate" to NUTAG_OUTBOUND()), can you get back responses from
any other SIP requests but REGISTER? If yes, perhaps fiddling with
OPTIONS would help, if no, you probably want to get better IMS...

-- 
Pekka.Pessi mail at nokia.com

--
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] Stack crash when the IP on the device changes

[Pekka Pessi]

2009/2/11 Inca Rose :
> I will grab the changes and test again.
>
> Can you pls tell me the changed files so I take only those changes ???
> If it helps, I'm using Sofia SIP on an iPhone.

$ darcs changes --last 10 --patch network_change -s
Wed Feb 11 22:51:48 EET 2009  Pekka Pessi 
  * nua_i_network_changed: use NUTAG_DETECT_NETWORK_UPDATES() preference

M ./libsofia-sip-ua/nua/nua_register.c -1 +3

Wed Feb 11 22:52:29 EET 2009  Pekka Pessi 
  * nua_stack_launch_network_change_detector: fixed root usage

  su_root_add_network_changed() should use stack root, not api root.

M ./libsofia-sip-ua/nua/nua_register.c -1 +1

-- 
Pekka.Pessi mail at nokia.com

--
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] do SDP negotiation in application level

[Pekka Pessi]

2009/2/12 liu yang :
> Do we have API provided to negotiate session capability in application level?
> Let's say, is there one function which takes two parameters of type
> soa_session_t, and return whether they are compatible with each other?

Not really. What you can do is to clone soa_session_t objects,
generate offer from one, feed it to another and generate answer, and
see if the answer if satisfactory.  The hard part is to determine when
the answer is satisfactory, but at least it should contain no rejected
m= lines. Except if they were present in offer.

-- 
Pekka.Pessi mail at nokia.com

--
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] sofia 1.12.9 : SOA module : User specified , , of "o=" not updated as local SDP

[Pekka Pessi]

2009/2/8 liu yang :
> I found a weird problem that ,  
> specified by application via SOATAG_USER_SDP_STR would be changed as other
> value forcely by sofia internally.

> Went through the stack, I caught the spotted code.
>
> File : soa_static.c
> Function:  soa_offer_answer_step()
>
> Code snippet :
>
> if (local->sdp_origin) {
>   o->o_username = local->sdp_origin->o_username;
>   /* o->o_address = local->sdp_origin->o_address; */
> }
> if (!o->o_address)
>   o->o_address = c0;
> local->sdp_origin = o;
>
> if (soa_init_sdp_origin(ss, o, c_address) < 0) {
>   phrase = "Cannot Get IP Address for Media";
>   goto internal_error;
> }
>
>
> We can see, the code which expects to perform  copy from user
> sdp to local sdp which is finally used by sofia stack is commented out.
> I don;t know why this is commented. Is there any speicial consideration?

I think our application once used pretty static user SDP (containing
preferences) having a o= line with a fixed IP address because the SDP
syntax required one. The soa code then changed it to IP address
actually found on device.

On more general level, the idea is that the o= is generated by the guy
who is actually generates the SDP.  Therefore o= line must be
different in user SDP (preferences) and local SDP (actual
offer/answer).  However, perhaps just having different ID on o= line
is enough. Also, I'd thought that o= line is not very important, its
only purpose is to be unique, but apparently many implementations get
shocked if it contains something they consider fishy (like IP6
address).

I have some code that tries to check if the address on o= line is
something su_localinfo() would return, perhaps I should clean it a bit
and push it.



-- 
Pekka.Pessi mail at nokia.com

--
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] IPv6 Link Address Bind Fail

[Pekka Pessi]

2009/2/12 Jerry Richards :
> Thank You.  Adding the following line just prior to the bind() call in
> tport_bind_socket() did the trick.  The bind succeeds when passing it the
> IPv6 Link Address or the IPv6 Global Address.
>
> su->su_sin6.sin6_scope_id = (unsigned long)if_nametoindex("esw0");

Cool.

> Perhaps a TPTAG tag should be added to pass in the name of the interface or
> index of the interface (unless there already is one)?

That sounds like a good idea. Perhaps the information could be
included in url used to bind the server (NUTAG_URL() to nua_create()),
too.

-- 
Pekka.Pessi mail at nokia.com

--
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] Stack crash when the IP on the device changes

[Pekka Pessi]

2009/2/12 Inca Rose :
> I just patch the code with your two patches from last night and here are the
> results:
> -- It takes the right case in the switch ( TRY_FULL or ONLY_INFO )
> -- if NUA_NW_DETECT_TRY_FULL is set,  the stack crash again with:
> Assertion failed: (tport_name_is_resolved(orq->orq_tpn)), function
> outgoing_create, file /sofia-sip-1.12.10/libsofia-sip-ua/nta/nta.c, line
> 7665.
> Program received signal:  "SIGABRT".
> If you need more info pls let me know.

A backtrace would be very helpful. Also, a check test case would be
++good (something to add to nua/check_register.c, however, triggering
the nw change might require writing custom functions to use instead of
ones in su_os_nw.c.)

-- 
Pekka.Pessi mail at nokia.com

--
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] PATCH: add/fix more tls init logging

[Pekka Pessi]

2009/2/12 Jarod Neuner :
> Just trying to make tport_tls init a bit noisier.

Thanks. Applied.

-- 
Pekka.Pessi mail at nokia.com

--
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] Handling in-dialog requets with NTA

[Pekka Pessi]

2009/2/4 Saúl Ibarra :
> I'm trying to get the control over in-dialog requets, but there is
> something I'm doing wrong and I can't get to solve it.

If you want to catch requests to particular dialog, use normal leg per
dialog (without NO_DIALOG(1), of course). You need
from/to/call_id/cseq as tags. In case you sent initial request, those
will come from your own request or response to it. If you create leg
from request you received, swap from and to and include cseq in
NTATAG_REMOTE_CSEQ().

If you just want to check if request is in-dialog one, you can check
if there is To tag.


-- 
Pekka.Pessi mail at nokia.com

--
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] SIP Parser

[Pekka Pessi]

2009/2/13 Della Betta Filippo :
>I noticed some strange behavior in extract_first of msg_parser.c. It 
> seems that a request line that begins with LWS, or ends after CRLF is a valid 
> request line.
> The followings are all valid according sofia-sip parser (double quote 
> excluded).
>
> "   INVITE sip:a...@b.c SIP/2.0"
>
> "INVITE sip:a...@b.c SIP/2.0
>  "
>
> I also noticed that you have tests for that (test1.txt and test1a.txt).
> According to RFC3261, request line is
> Request-Line = Method SP Request-URI SP SIP-Version CRLF
> and Method cannot begin with SP. Also Request-Line ends with CRLF.
> Headers have HCOLON that could span multiple line (but always begin at the 
> start of the line), but not Request-Line.
> Also I noticed that in RFC 4475 (SIP Torture Test Messages), the 3.1.1.1 
> message (that recalls test1.txt very much) has not spaces before the To 
> header.
> What do you think ?
> Is there any reason for that implementation ?

According RFC 2543 empty lines should be ignored, and the whitespace
after first line but before first header is in some of the 2543bis
drafts (which much later become RFC3261). The torture message is from
around 2001.

Is there a reason to be more conservative when receiving?

-- 
Pekka.Pessi mail at nokia.com

--
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] Away next week

[Pekka Pessi]

Just GYI, I'm going to spend next week way from e-mail. Don't panic.

-- 
Pekka.Pessi mail at nokia.com

--
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

[Pekka Pessi]

2009/2/19 Fabio Margarido :
> 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?

Currently nua uses the function sip_response_termionates_dialog() to
determine what each returned response code does with the dialog. When
you return 480 to re-INVITE, nua considers the dialog terminated and
clears its state. In that sense, the behaviour is as expected. Nua
should probably allow sending BYE after the session has otherwise been
cleared, however.

-- 
Pekka.Pessi mail at nokia.com

--
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] TCP Source Port 3072?

[Pekka Pessi]

2009/2/26 Jerry Richards :
> Hello All,
>
> When I configure the sofia transport=udp, then I see SIP UDP packets sent
> with source port 5060 and destination port 5060.  When the only change I
> make is transport=tcp, then I see SIP TCP packets sent with source port 3072
> and destination port 5060.
>
> Has anyone seen this?  Maybe I'm missing a tag or there is something weird
> happening in my TCP/IP stack?

This is perfectly normal for TCP. The source port is not usually bind
to any known value but system selects an ephemeral port for it.  (If
it was, we would run into serious problems if the connection ever got
closed.)

-- 
Pekka.Pessi mail at nokia.com

--
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] TCP Source Port 3072?

[Pekka Pessi]

2009/2/26 Jerry Richards :
> Okay, thank you.  By the way, if I wanted to temporarily patch the source
> port, do you know a good place (i.e. function) to do it?  I just want to
> confirm that the source port is not an issue with a SIP server I'm
> interfacing with.

It might be a bit hard, you can try to bind to tp_pri->tp_addr  in
tport_tcp_init_secondary(). bind() might succeed or then not,
depending on how the reuseraddr is implemented on your system.

--Pekka

> -Original Message-----
> From: Pekka Pessi [mailto:ppe...@gmail.com]
> Sent: Thursday, February 26, 2009 12:15 PM
> To: Jerry Richards
> Cc: sofia-sip-devel@lists.sourceforge.net
> Subject: Re: [Sofia-sip-devel] TCP Source Port 3072?
>
> 2009/2/26 Jerry Richards :
>> Hello All,
>>
>> When I configure the sofia transport=udp, then I see SIP UDP packets
>> sent with source port 5060 and destination port 5060.  When the only
>> change I make is transport=tcp, then I see SIP TCP packets sent with
>> source port 3072 and destination port 5060.
>>
>> Has anyone seen this?  Maybe I'm missing a tag or there is something
>> weird happening in my TCP/IP stack?
>
> This is perfectly normal for TCP. The source port is not usually bind to any
> known value but system selects an ephemeral port for it.  (If it was, we
> would run into serious problems if the connection ever got
> closed.)
>
> --
> Pekka.Pessi mail at nokia.com
>
>



-- 
Pekka.Pessi mail at nokia.com

--
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] Loop through all headers in a message

[Pekka Pessi]

2009/2/26 Fabio Margarido :
> I'd like to know what's the best way to check if a header is present (and
> get its contents) in a sip_t (or msg_t) structure by name (as a string) or
> if there is a way to loop through all the headers in a sip_t structure,
> checking if each one's name matches an arbitrary string the user of my
> application has passed and get the contents of the headers in case there is
> a match.

You can get msg_href_t by name with msg_find_hclass(), like

  msg_href_t *href = msg_find_hclass(msg_mclass(msg), name, NULL);
  msg_header_t **slot = (char *)sip + href->hr_offset;

  if (href->hr_class->hc_name[0]) {
/* Well-known header */
  }
  else {
   /* Unknown header */
  }

The header contents (including its name) are in (*slot)->sh_data,
lenght in (*slot)->sh_len. In order to gain access to the unparsed
contents,  you have to add NTATAG_SIP_FLAGS(MSG_FLG_EXTRACT_COPY) when
calling nua_create() or nta_agent_create()).

Alternatively, you can convert the header field to string with
sip_header_as_string(). Header field is usually a thing that you can
put on separate headers or on a a single header separated with commas.
E.g., header

Contact: , 

contains two header fields and it could be represented as two headers

Contact: 
Contact: 

The (*slot)->sh_next pointer will contain the next header field or
next header with the same name.

The authentication headers are an exception in SIP, there the header
field contains all the comma-separated values from a single header.

Sofia SIP makes another exception for so called list headers where the
header field consists of single token, so if the original message
contains headers

Require: 100rel
Require: timer

the 100rel and timer are collected in a single list (on
sip->sip_require->k_items[] array) and they are returned in a single
call to sip_header_as_string().

If you want to make your application bomb-proof, you probably have to
go through the list of bad headers in sip->sip_error, too.

-- 
Pekka.Pessi mail at nokia.com

--
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] TCP Source Port 3072?

[Pekka Pessi]

2009/2/26 Jerry Richards :
> Do you mean that you don't want to bind the TCP connection to port 5060,
> because some other program might be using it?  Or some other program might
> close that port?  We have a hard-phone and I know nothing else except
> sofia-sip would use that port number.

The port 5060 is used by Sofia SIP itself for serving incoming INVITE
and friends. Serious problems refer to the situation where you have a
TCP connection, it gets closed, and when you try to open another, you
can not, because the new one has exactly the same
source-ip-port/destination-ip-port tuple.

(The bright idea of making port 5060 as source port for client
connections has occurred to me, too, and it simply does not work. And
at least Linux makes its hardest to prevent you from shooting yourself
into foot (or head) as binding a client-side tcp connection to same
port as you use for a server is practically impossible.)

--Pekka

>
> -Original Message-----
> From: Pekka Pessi [mailto:ppe...@gmail.com]
> Sent: Thursday, February 26, 2009 12:15 PM
> To: Jerry Richards
> Cc: sofia-sip-devel@lists.sourceforge.net
> Subject: Re: [Sofia-sip-devel] TCP Source Port 3072?
>
> 2009/2/26 Jerry Richards :
>> Hello All,
>>
>> When I configure the sofia transport=udp, then I see SIP UDP packets
>> sent with source port 5060 and destination port 5060.  When the only
>> change I make is transport=tcp, then I see SIP TCP packets sent with
>> source port 3072 and destination port 5060.
>>
>> Has anyone seen this?  Maybe I'm missing a tag or there is something
>> weird happening in my TCP/IP stack?
>
> This is perfectly normal for TCP. The source port is not usually bind to any
> known value but system selects an ephemeral port for it.  (If it was, we
> would run into serious problems if the connection ever got
> closed.)
>
> --
> Pekka.Pessi mail at nokia.com
>
>



-- 
Pekka.Pessi mail at nokia.com

--
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] Ordering of SDP Fields

[Pekka Pessi]

2009/2/27 Jerry Richards :
> When my application specifies the SDP in the SOATAG_USER_SDP(), I noticed
> sofia-sip sometimes reorders the lines of the SDP in the message that is
> actually transmitted.  Do you know why this is?  Does the order matter?

The order matters - the order of m= lines should be same in answer as
it is in offer. Sofia SIP tries to reorder your user SDP so that the
m= lines on answer match those on offer, like, if you support audio
and video, but offer contains

m=image
m=video
m=audio

dummy image line is generated and your video line is before the audio
line. You can change the behaviour with SOATAG_ORDERED_USER().

-- 
Pekka.Pessi mail at nokia.com

--
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] Using su_msg_r

[Pekka Pessi]

2009/2/27 Aleksander Morgado :
> In my case, no such reply/report is needed, as I just need to dispatch the
> su_msg_r and nothing else, so I was wondering if this other approach is
> acceptable:

> * Instead of `su_msg_create()', use `su_msg_new()'
> * Then, instead of `su_msg_send()', use `su_msg_send_to()', as this last
> function only needs the receiver's su_task_r.
>
> Is this a correct approach?

Yes, su_msg_new()/su_msg_send_to() is way to go. It would probably be
better always to use su_msg_new()/su_msg_send_to().

-- 
Pekka.Pessi mail at nokia.com

--
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] Loop through all headers in a message

[Pekka Pessi]

2009/2/27 Fabio Margarido :
> On Thu, Feb 26, 2009 at 18:21, Pekka Pessi  wrote:
>>
>> You can get msg_href_t by name with msg_find_hclass(), like
>>
>>  msg_href_t *href = msg_find_hclass(msg_mclass(msg), name, NULL);
>>  msg_header_t **slot = (char *)sip + href->hr_offset;
>>
>>  if (href->hr_class->hc_name[0]) {
>>    /* Well-known header */
>>  }
>>  else {
>>   /* Unknown header */
>>  }
...
> The lines that triggered errors were the 'msg_header_t **slot (...)' line
> and the 'if (...)' line. I believe I'm not allowed to access the members of
> href. Is there something else I'm missing?

You need

#include 


--
Pekka.Pessi mail at nokia.com

--
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] Move documentation from *.c to *.h

[Pekka Pessi]

2009/3/2 Stefano Sabatini :
> Is it OK what in subject?
>
> I think the rationale is quite obvious, docs should be documented in
> the interface rather than in the implementation, also this avoids
> duplication.

I think the documentation should as close to implementation as
possible. For C, it means that the macros, public structs, etc. should
be documented in .h files, functions in .c files. This way there is
much better chances that the documentation gets updated when the
functionality is updated.

The interface gets documented in one place, however, thanks to Dimitri
van Heesch and Doxygen. I think most editors can get from headers to
doxygen-generated docs in a couple of keystrokes or mouse clicks. Or
to the source code, if you prefer raw @annotation.

For Sofia, it is a bit ambiguous how to document tags as there is not
much to implement. The type-casting  function is declared within the
macro in *.h and the actual name and type in *.c. I prefer a short
list *.h files and in some Sofia SIP modules I have moved the
documentation  into the *_tag.c files. Other problematic things
include the platform-specific parts of su modules.

Generally separating documentation from implementation creates extra
work that is needed to get the documentation updated. That extra work
has a tendency of not getting done as you might have noticed from
those @briefs now in *.h files.

> If that's OK I'll post here some patches for doing that, one header at
> a time.

If you want to get rid of duplicate and contradictory @brief entries
I'd prefer removing the extra @brief comments from headers rather than
collecting the documentation to the *.h files.

-- 
Pekka.Pessi mail at nokia.com

--
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] how to ignore 302 redirect responses (NUA)

[Pekka Pessi]

2009/2/26 techsgin :
> We would like to know how to ignore 302 redirect responses.

It is not possible to disable only 302 recursion, but you can limit
error recursion in general with NUTAG_RETRY_COUNT(0).

-- 
Pekka.Pessi mail at nokia.com

--
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] memory leak

[Pekka Pessi]

2009/2/27 Della Betta Filippo :
> with the following code (nua_create fails since IP is not valid on my
> machine), I spot two memory leaks of sofia-sip stack.
>
> One is due to the fact that task nua->nua_client is not deinit’ed in case of
> error, the other is due to the fact that nua default handle holds a
> soa_session_t pointer created with soa_create that is not deleted with
> soa_destroy (actually there is also sm_create that has no sm_destroy, but I
> have no code for that)
>
> Attached there is a possible patch for this (sm_destroy is missing…).

Thanks for the patch. I think the soa_destroy() should be called by
the stack deinit function. I'll try check that and apply the relevant
parts, anyways.

-- 
Pekka.Pessi mail at nokia.com

--
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] srand / rand win32 problem

[Pekka Pessi]

2009/3/2 Della Betta Filippo :
>  I noticed that su_random implementation on windows is not working correctly 
> since srand() must be called per-thread (see 
> http://msdn.microsoft.com/en-us/library/f0d4wb4t.aspx).
> I suggest a patch like that attached to overcome this issue on windows 
> systems.

Thanks. Applied.

-- 
Pekka.Pessi mail at nokia.com

--
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] How to get the state of a nua_handle

[Pekka Pessi]

2009/3/3 Stefano Sabatini :
> I was investigating about how to get the state of a nua_handle,
> couldn't find nothing about it.

The current state is not very well defined, nor it is kept in handle.

> I also wonder if it is possible for example to extract other
> informations related to it, for example the Call-ID of a dialog.

nua_handle_make_replaces() returns a Replaces header, you can get
Call-ID from it.

I'll gladly accept patch for something like

char *nua_handle_make_call_id(nua_handle_t *nh)

> The nh_status is not defined in nua_handle_s, and the macro NH_STATUS
> looks like it is never used in the code, so maybe this is just a
> fossil.

Yep, it was some fossilized code, I'll zap it..

-- 
Pekka.Pessi mail at nokia.com

--
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] Authentication

[Pekka Pessi]

2009/3/3 Stuart Whelan :
>  I have a registrar that is embedded in my application, and I would
> like to add authentication to it.
>
> Would anyone be willing to throw up a quick sample or example that
> shows what steps to go through to validate a register request using
> internally validation?
>
> I basically want to verify the realm/user/password against an config
> value stored within my app.
>
> I have found an example that references an external md5 database, but
> that is not quite what I am after... I am not sure where else to look.

There is a simple example in tests/check_proxy.c that does
authentication in process_register()/challenge_transaction().

Are you referring to it and still looking even simpler approach?

-- 
Pekka.Pessi mail at nokia.com

--
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] Changes in CANCEL handling

[Pekka Pessi]

Hello all,

There was yet-another bug of brown paper-bag variety in the way
CANCELed INVITE transactions were handled. Looks like they were not
timed out properly but restarted and restarted over again in certain
scenarios.

When fixing that I also improved the timer C behaved (now CANCELing
INVITE transactions that have not received a peep from server for 3
minutes) and also the way nta_outgoing_tagged() aka forked INVITE
transactions behave.

Quoting from RELEASE:

- Timing out CANCELed INVITE client transactions is now done with timer D.
  Previously, the INVITE client transactions were restarted instead of
  timing out under certain circumstances.
- An INVITE transaction that has been timed out with stack timer C is now
  CANCELed automatically. Previously, such the INVITE client transactions
  were restarted instead of timing out under certain circumstances.
- Timing out forked INVITE client transactions is now done by stack.
  The stack generates a 408 response to each INVITE transaction fork that
  has not received a final response within 32 seconds (or 64 times SIP T1)
  after first final response to the INVITE was received.

While I added some testing to check_nua and started writing
check-based test cases for nta, too, it is likely that there are still
some problems (especially related to handling of 100rel responses,
PRACK and all that jazz). As usual, be vigilant and report any
irregularities to the list...

-- 
Pekka.Pessi mail at nokia.com

--
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] Retrying UDP does not send message to network

[Pekka Pessi]

2009/1/29 Fabio Margarido :
> 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.

For some reason, the two lines of code actually sending the request
over UDP was missing from the timer N3 case.

-- 
Pekka.Pessi mail at nokia.com

--
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] Short headers inside multipart body not parsed

[Pekka Pessi]

2009/3/4 Fabio Margarido :
> the attached set of patches against current darcs fixes the issue of parsing
> headers in compact form inside a multipart payload. I've also tried to
> include some tests in test_msg.c, but don't know if they're enough.

Thanks. I've applied the applicable parts of you patch and also added
a test parsing a MIME multipart with the short-form headers.

-- 
Pekka.Pessi mail at nokia.com

--
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] How to get the state of a nua_handle

[Pekka Pessi]

2009/3/5 Stefano Sabatini :
> sofsip_cli bookeeps this information in the ssc_oper_s struct
> (ssc_oper.h), I also tried the i_state event management approach but
> it is not correct, since the i_state event (setting the state in the
> operation context/magic) is processed by the sofia event handler
> *after* the actual event which causes the state transition.

If you call nua_bye(), it will actually send a CANCEL request if no
final response has been received for the INVITE transaction. Also, if
2XX has been received, nua_bye() is supposed to send ACK, too. Please
report if that is not the case.

> So I wonder if it would make sense to set this information in the
> handle itself, when the various nua_invite/nua_ack/... operations are
> performed, rather than re-implement that logic in every app.

While is possible to cache the latest call state in nua handle,
however, I don't think it will solve your problem.

-- 
Pekka.Pessi mail at nokia.com

--
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] Building sofia-sip with mingw

[Pekka Pessi]

2009/3/6 Jonas Jalminger :
> Building sofia-sip on Windows using mingw/msys is hard. I have not seen
> too many posts regarding this so I will share my experience so far.

Thanks for sharing.

> I started by doing an autreconf in the top directory.

I'm afraid that this is a mistake. autoconf and automake has number of
version-related problem. In this particular case, autoconf does not
warn if you miss autoconf macros of pkg-config.

>Trying configure
> gave the following problem:
>  ./configure: line 16805: syntax error near unexpected token `GLIB,'
> ./configure: line 16805: `  PKG_CHECK_MODULES(GLIB, glib-$with_glib,
> HAVE_GLIB=yes, HAVE_GLIB=no)'
> Trying --with-glib=no had no effect. Instead I manually removed the test
> in the configure script and set HAVE_GLIB=no.

> Next, it stopped once again on a PKG_CHECK_MODULE for ssl. The same
> problem here and I had to manually set HAVE_OPENSSL=0.
>
> Same problem with CHECK. Same soultion, have_check=0.
>
> Next, it says that the compiler cannot handle 64-bit integers, which it
> can. Again I manully changed it to use %llu and the rest even if the
> test failed.

Could you have a peek in your config.log and see why and what exactly
failed there?

> The configuration now completed without errors. Time to do make and it
> failed much right away with the first libtool command:
> if /bin/sh ../../libtool --mode=compile --tag=CC gcc -DHAVE_CONFIG_H -I.
> -I. -I../.. -I../../libsofia-sip-ua/su/sofia-sip    -Wall     -g -O2
> -I../../win32/pthread -DWINVER=0x0501     -D_WIN32_WINNT=0x0501
> -DIN_LIBSOFIA_SIP_UA -DIN_LIBSOFIA_SRES   -mms-bitfields  -pipe
> -mno-cygwin -mwindows -mconsole -Wall -g -O0 -MT su.lo -MD -MP -MF
> ".deps/su.Tpo" -c -o su.lo su.c; \
> then mv -f ".deps/su.Tpo" ".deps/su.Plo"; else rm -f ".deps/su.Tpo";
> exit 1; fi
> ../../libtool: line 828: X--mode=compile: command not found
> ../../libtool: line 828: X--tag=CC: command not found
> ../../libtool: line 861: libtool: ignoring unknown tag : command not found
> ../../libtool: line 995: *** Warning: inferring the mode of operation is
> deprecated.: command not found
> ../../libtool: line 996: *** Future versions of Libtool will require
> --mode=MODE be specified.: command not found
> ../../libtool: line 1139: Xgcc: command not found
> and so forth. It seems like there is an extra X inserted.

> I have no idea which file to modify to remove the extra X. It would be
> great if someone could point me to where the problem is.

I think autoreconf used M4 macros from newer libtool for autoconf, but
failed to install the libtool script itself. Or vice versa. Either
copy the original configure and Makefile.in files from release tar, or
run libtoolize --force --install.

-- 
Pekka.Pessi mail at nokia.com

--
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] Variable number of tag parameters

[Pekka Pessi]

2009/3/9 Fabio Margarido :
> I'd like to know it there is a way for me to pass a variable number of
> tagged parameters for Sofia functions. For example, I have an array with an
> unknown number of strings that represent headers, and I'd like to call
> nua_invite() with a SIP_HEADER_STR() tag for each member of the array.
> As I don't think there are tags for loops, is there a way to do this?

You can pass an array of tagi_t structs, like

invite_with_headers(nua_handle_t *nh, char **headers, size_t n_headers)
{
   tagi_t *tags = su_zalloc(NULL, sizeof(*tags) * (n_headers + 1);

   for (i = 0; i < n_headers; i++) {
  tags[i].t_tag = siptag_header_str;

  }
}



-- 
Pekka.Pessi mail at nokia.com

--
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] Variable number of tag parameters

[Pekka Pessi]

...oops, too fast clickin...

2009/3/9 Fabio Margarido :
> I'd like to know it there is a way for me to pass a variable number of
> tagged parameters for Sofia functions. For example, I have an array with an
> unknown number of strings that represent headers, and I'd like to call
> nua_invite() with a SIP_HEADER_STR() tag for each member of the array.
> As I don't think there are tags for loops, is there a way to do this?

You can pass an array of tagi_t structs, like

invite_with_headers(nua_handle_t *nh, char **headers, size_t n_headers)
{
  tagi_t *tags = su_zalloc(NULL, sizeof(*tags) * (n_headers + 1);

  for (i = 0; i < n_headers; i++) {
     tags[i].t_tag = siptag_header_str;
 tags[i].t_value = (tag_value_t)headers[i];
 }
   nua_invite(nh, ...other tags..., TAG_NEXT(tags));
   su_free(NULL, tags);
}

--Pekka

-- 
Pekka.Pessi mail at nokia.com

--
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] Variable number of tag parameters

[Pekka Pessi]

2009/3/9 Aleksander Morgado :
>>   nua_invite(nh, ...other tags..., TAG_NEXT(tags));

> Isn't TAG_END() needed here at the end? Or is it implicitly taken from the
> tag list?

The NULL pointer at tags[n_headers].t_tag is used as sentinel. NULL is
as good as TAG_END()


-- 
Pekka.Pessi mail at nokia.com

--
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] Building sofia-sip with mingw

[Pekka Pessi]

2009/3/11 Della Betta Filippo :
> Dear Jonas, all
> if you want to compile the latest version win mingw I found the following:
> 1) to overcome the PKG_CHECK_MODULE problem, you need to install pkg-config 
> (see http://www.mingw.org/wiki/FAQ - How do I get pkg-config installed? -)
> 2) I noticed that there are o lot of warnings on mingw complaining 
> declaration with SOFIAPUBVAR. I think extern is missing (see patch attached)

Hm, wonder what was the reason to drop the extern in first place?

> 3) Makefile.am should be modified to include (in case of MinGW platform) 
> su_win32_port.c on the list of libsu_la_SOURCES (and removed from EXTRA_DIST)

I'll see how to do detection...

> 4) I also had some problem with gai_strerror function (the check in 
> sac-su2.m4 line 529 don't find gai_strerror for mingw, but actually 
> gai_strerror is present on mingw platform). To overcome this issue, I simply 
> changed config.h generated defining HAVE_GAI_STRERROR to 1

You could have a peek in config.log and see config.log which
diagnostics the gcc spews out there.

> 5) I had some problem with s2check (s2base.c line 77 timespec is not defined 
> on mingw platform). I included pthread.h on s2base.c and changed code a 
> little since timespec in pthread.h has tv_nsec instead of tv.tv_usec.

copy&paste error, that should be struct timeval.

> 6) Regarding error in winbase.h, this is due to the fact that #include 
>  and #include  (needed for va_list macro definition) are 
> missing on line 274 of sac-su2.m4)

OK, I'll add those...

> 7) The -lpthreadVC2 is correct, what mingw doesn't like (I don't know why) is 
> the -I and -L syntax with $(top_srcdir). I overcome this issue I put the full 
> path of pthread dir (i.e. -I/home/Administrator/sofia-sip/win32/pthread and 
> -L/home/Administrator/sofia-sip/win32/pthread) in sac-general.m4

Do you use msys or cygwin to run configure?

There is also some problems with thread-specific storage in
su_uniqueid.c. Currently, I plan to solve the issue with pthread_once,
pthread_key and a cleanup function declared with GCC
__attribute__((destructor)) on Unix systems. I plan to call the
destructor fucntion from a DllMain() function in win32/64, but perhaps
someone more familiar with mingw could tell me how mingw gcc and
runtime implements __attribute__((destructor)) and what happens if
sofia-sip has defined its own DllMain()?

-- 
Pekka.Pessi mail at nokia.com

--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-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] Building sofia-sip with mingw

[Pekka Pessi]

2009/3/13 Della Betta Filippo :
>>Hm, wonder what was the reason to drop the extern in first place?
>
> What do you mean ? Sorry I don't get it :(

At some point in Sofia history, there was extern there. But it has
been removed, and I wonder (aloud) why.

>>>generated defining HAVE_GAI_STRERROR to 1
>
>>You could have a peek in config.log and see config.log which
>>diagnostics the gcc spews out there.
>
> Attached the program that configure generates to detect gai_strerror. For 
> mingw gai_strerror is defined inline in header 

Thanks.

>>There is also some problems with thread-specific storage in
>>su_uniqueid.c. Currently, I plan to solve the issue with pthread_once,
>>pthread_key and a cleanup function declared with GCC
>>__attribute__((destructor)) on Unix systems. I plan to call the
>>destructor fucntion from a DllMain() function in win32/64, but perhaps
>>someone more familiar with mingw could tell me how mingw gcc and
>>runtime implements __attribute__((destructor)) and what happens if
>>sofia-sip has defined its own DllMain()?
>
> I saw :( thread is ignored by mingw...What do you mean by "has defined its 
> own DllMain()" ? If you don't write it, it doesn't have it..

I've always thought that the function called by Windows dynamic loader
would be DllMain. D'oh. This seems to be a bit more complicated.

Quick googling revealed that normally C runtime includes its own
initialization code in DLLs as DllMainCRTStartup() and this
initialization code invokes constructors, prepares for destructors and
then calls DllMain:




(looks like _pei386_runtime_relocator() is the thing that I've been
missing all these years. Damn MS. Damn DllMainCRTStartup()).

This looks like the way to implement __attribute__((destructor)) with MSVC:



--
Pekka.Pessi mail at nokia.com

--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-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] TRansport and NUA o

[Pekka Pessi]

2009/4/12 Inca Rose :
> I cant find any way to add/remove transports to an already created NUA
> object.
>
> I have to be able to create a NUA object with an IP when calling nua_create,
> but during
> the lifetime of the objects that IP may change by:
> DHCP, changing access points, etc
>
> Can anybody point me to some code or API ?

It seems to me that there is no way change the IP addresses.
Definitely some kind of API is needed.

-- 
Pekka.Pessi mail at nokia.com

--
Register Now & Save for Velocity, the Web Performance & Operations 
Conference from O'Reilly Media. Velocity features a full day of 
expert-led, hands-on workshops and two days of sessions from industry 
leaders in dedicated Performance & Operations tracks. Use code vel09scf 
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] TCP UAS resource leak [win]

[Pekka Pessi]

2009/3/16 Arsen Chaloyan :
> Problem description:
> Accepted socket remains in CLOSE_WAIT state.

Is it leaking sockets?

> How to reproduce:
> UAC connects to Sofia-SIP UAS, makes basic call and finally tears down TCP
> connection.
>
> Tport output:
> // Windows
> tport_wakeup(00CB7310): events HUP
> tport(00CB7310)
> tport(00CB7310, 0)
> tport_set_events(00CB7310): events
> tport(00CB7310): set timer at 1797891 ms because idle since send
>
> // Linux
> tport_wakeup(0x9cf91e8): events IN
> tport_recv_event(0x9cf91e8)
> tport_shutdown0(0x9cf91e8, 2)
> tport_close(0x9cf91e8): tcp/x.x.x.x:3095/sip
> tport(0x9cf91e8): set timer at 0 ms because zap
>
> When remote UAC tears down TCP connection 'events HUP' is raised on Windows,
> while 'events IN' on Linux.
> If I modify Sofia's code to raise 'events IN' in case of Windows too, socket
> is closed.
> The other workaround is to modify tport_hup_event handler
> isntead of
> <  tport_shutdown0(self, 0);
> use
>>  tport_shutdown0(self, 2);
>
> Any inside thoughts would be really helpful.

Does it help to use

tport_shutdown0(self, tport_has_queued(self) ? 0 : 2);

instead of

tport_shutdown0(self, 0);

?

-- 
Pekka.Pessi mail at nokia.com

--
Register Now & Save for Velocity, the Web Performance & Operations 
Conference from O'Reilly Media. Velocity features a full day of 
expert-led, hands-on workshops and two days of sessions from industry 
leaders in dedicated Performance & Operations tracks. Use code vel09scf 
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] "a=sendrecv" Not sent during SIP INVITE

[Pekka Pessi]

2009/4/24 Saurav SAHU :
> I am using Sofia-sip 1.12.10 for running my applciation.
>
> In my application with Sofia-sip 1.12.10, I would like to send an INVITE 
> message with SDP attribute parameter "a=sendrecv".
...
> However, the problem is that we do not observe SDP attribute "a=sendrecv" in 
> the transmitted SIP INVITE packet. If we were to use "a=sendonly" or 
> "a=recvonly", it works with first method. But I want to send specifically 
> "a=sendrecv" attribute in INVITE (even though, its absence may corresspond to 
> default presence).
>
> Could you please advise us on how we could use nua_invite() to have 
> "a=sendrecv" in the transmitted INVITE SDP.

The sdp_print() function does not include the a=sendrecv as it is
considered the default. What you can do is to modify the soa.c source
code and include the flag sdp_mode_always as the last parameter to
sdp_print() calls, that should do the trick. You can also include
a=sendrecv at the session level, I believe, but then it might not work
as intended.

There probably should be a SOATAG_SDP_FLAGS() etc. that could be used
to pass the sdp_parse()/sdp_print() flags to soa.

-- 
Pekka.Pessi mail at nokia.com

--
Register Now & Save for Velocity, the Web Performance & Operations 
Conference from O'Reilly Media. Velocity features a full day of 
expert-led, hands-on workshops and two days of sessions from industry 
leaders in dedicated Performance & Operations tracks. Use code vel09scf 
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] TCP UAS resource leak [win]

[Pekka Pessi]

2009/4/29 Arsen Chaloyan :
>> Is it leaking sockets?
> Yes, at least netstat clearly shows it.
>
>>Does it help to use tport_shutdown0(self, tport_has_queued(self) ? 0 : 2);
>> instead of tport_shutdown0(self, 0);
> Yes, it helps, at least it fixes the reported issue.

OK, I'll push the fix to darcs...

-- 
Pekka.Pessi mail at nokia.com

--
Register Now & Save for Velocity, the Web Performance & Operations 
Conference from O'Reilly Media. Velocity features a full day of 
expert-led, hands-on workshops and two days of sessions from industry 
leaders in dedicated Performance & Operations tracks. Use code vel09scf 
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Broken session timer behavior when initial INVITE has multipart/mixed payload

[Pekka Pessi]

2009/3/25 Fabio Margarido :
> Is there a way to work around this issue?

Set NUTAG_AUTOACK(0) on per-handle basis.

>Why does Sofia send the ACK
> automatically despite NUTAG_AUTOACK(0) being set globally in
> nua_create()?

The idea was to make session timer work behind the back of
application.  Now NUTAG_AUTOACK() behaves like NUTAG_AUTOANSWER(), the
re-INVITE auto-ACKs unless you explicitly forbid it. I'll add a
mention of it to the NUTAG_AUTOACK() documentation..

-- 
Pekka.Pessi mail at nokia.com

--
Register Now & Save for Velocity, the Web Performance & Operations 
Conference from O'Reilly Media. Velocity features a full day of 
expert-led, hands-on workshops and two days of sessions from industry 
leaders in dedicated Performance & Operations tracks. Use code vel09scf 
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Broken session timer behavior when initial INVITE has multipart/mixed payload

[Pekka Pessi]

2009/4/29 Pekka Pessi :
> The idea was to make session timer work behind the back of
> application.  Now NUTAG_AUTOACK() behaves like NUTAG_AUTOANSWER(), the
> re-INVITE auto-ACKs unless you explicitly forbid it. I'll add a
> mention of it to the NUTAG_AUTOACK() documentation..

Looks like autoanswer already checks if media is disabled and avoids
autoanswering in re-INVITE. I suppose that is what application most
probably wants from auto-ACK, too.


-- 
Pekka.Pessi mail at nokia.com

--
Register Now & Save for Velocity, the Web Performance & Operations 
Conference from O'Reilly Media. Velocity features a full day of 
expert-led, hands-on workshops and two days of sessions from industry 
leaders in dedicated Performance & Operations tracks. Use code vel09scf 
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
___
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 avoid "m= audio 0 RTP/AVP 19" being prepended to "m= image 9000 udptl t38"

[Pekka Pessi]

2009/4/27 Kaustubh Madhav PATWARDHAN :
> With this I am expecting to see:-
>
> " m= image 9000 udptl t38
>   a= T38MaxBitrate:14400
>   a=T38FaxRateManagement:transferredTCF"
>
> But when I see in the network capture file, I am seeing this request
> incorporates a request for media audio with port 0 like
>
> "m= audio 0 RTP/AVP 19
>  m= image 9000 udptl t38
>  a= T38MaxBitrate:14400
>  a=T38FaxRateManagement:transferredTCF"
>
> Why Sofia sip stack is adding the "m=audio 0 RTP/AVP 19" preceding the
> actual t38 media message.

By default, the SDP O/A engine matches the media lines by their name.
If you use SOATAG_ORDERED_USER(1) the O/A engine replaces the audio
media line with fax media line.

-- 
Pekka.Pessi mail at nokia.com

--
Register Now & Save for Velocity, the Web Performance & Operations 
Conference from O'Reilly Media. Velocity features a full day of 
expert-led, hands-on workshops and two days of sessions from industry 
leaders in dedicated Performance & Operations tracks. Use code vel09scf 
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Regarding destroying the irq, orq and nta_leg

[Pekka Pessi]

2009/4/29 Krishna Kishore G :
> Hi,
>   I am trying to build a b2bua using NTA. I need some clarifications
> regarding the destroying of objects like nta_icoming etc.
>  For intial request i get a call back with irq,leg,sip
>
> For example:
>
> static int proxy_request(union proxy_or_domain *proxy,
>     nta_leg_t *leg,
>     nta_incoming_t *irq,
>     sip_t const *sip);
>
>
>   In the callback i will create a new leg(new_leg) for this request so
> that can send new requests for the client using this leg.
> I keep this leg until the dialog persists and call nta_leg_destroy(new_leg)
> on newly created leg.
>
> What should I do with the objects that come as a part of callback?
> a) Do I need to call nta_incoming_destroy(irq) immediately  once I respond
> with final response for this transaction
> ex: nta_incoming_treply(irq,response_code,reason_phrase);
>  nta_incoming_destroy(irq);

Yes. Or in case of INVITE and 200 OK, you can keep original INVITE
until you get ACKed.

> b)Do Ineed destroy the nta_leg which i received in callback ?

That is probably your default leg. Do not destroy it.

-- 
Pekka.Pessi mail at nokia.com

--
Register Now & Save for Velocity, the Web Performance & Operations 
Conference from O'Reilly Media. Velocity features a full day of 
expert-led, hands-on workshops and two days of sessions from industry 
leaders in dedicated Performance & Operations tracks. Use code vel09scf 
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Session-Expires

[Pekka Pessi]

2009/4/29 Linus Surguy :
> We have a b2bua application where session timers are used on the
> outbound leg. The session timer functionality is requested by the far
> end with a response in the 200 OK.
>
> "Require: timer
>  Session-Expires: 900;refresher=uac"
>
> These session timers appear to run correctly and at first refresh time,
> Sofia generates the INVITE. However, it only appears to add a 'Min-SE'
> header to this and not a 'Session-Expires'.
>
> RFC4028 appears to suggest that it should:
>
> 7.4.  Generating Subsequent Session Refresh Requests
> [...]In a session refresh request sent within a dialog with an active
>   session timer, the Session-Expires header field SHOULD be present.[...]
...
> We're using sofia 1.20.10
>
> Does anyone have any thoughts?

Indeed, Sofia does not include Session-Expires headers in refreshes.
I've pushed a patch fixing the problem into darcs.
(nua_session.c: include Session-Expires to session refresh requests).

-- 
Pekka.Pessi mail at nokia.com

--
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image 
processing features enabled. http://p.sf.net/sfu/kodak-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] tport.c:3155: tport_tsend: Assertion `self' failed.

[Pekka Pessi]

2009/5/8 Markus Bucher :
> Ok, I found what was wrong.
>
> I had a Via-Header to describe that the Message was routed on an
> P2P-network:
>
> Via: SIP/2.0/IGOR 3ad326ea83e06744319ec4711a0c025b74327d01
>
> The problem is that Sofia tries to send the message to this host, which
> it obviously is not able to do.
>
> So the solution I have is just to not insert the Via-header in the first
> place.
>
> Is there a way to make Sofia skip this Via-Host without removing the Header?

So you want to route the response message based on the address in the
url instead of Via? If you look at the code, you probably should hack
the nta_msg_tsend() to use the nta_tpn_by_url() with u (if u is
non-NULL) instead of calling nta_tpn_by_via() with topmost via.

Patch is most welcome.

-- 
Pekka.Pessi mail at nokia.com

--
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image 
processing features enabled. http://p.sf.net/sfu/kodak-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] Avoid sending 100 Trying?

[Pekka Pessi]

2009/5/13 Aleksander Morgado :
> Hi Pekka,
> I prepared a small patch (attached) to current darcs implementing a new tag
> NTATAG_AVOID_100(), which can be used in nta_incoming_set_params(). That
> function was meant to provide sigcomp support (at least the allowed tags
> were just only for that), but I guess it's the correct place to include it.

Thanks for the patch. Yes, that is  the correct place for setting it
on transaction basis.

> By default, the nta_incoming_t of an invite will have the avoid_100 set to
> false, so that it works as before, sending the 100 Trying in an INVITE
> transaction if N1 timer gets fired. If nta_incoming_set_params(irq,
> NTATAG_AVOID_100(1), TAG_END()); is called just after receiving the INVITE
> irq in the given leg, the sending of 100 Trying is avoided ( so this
> featrure is given per incoming transaction, and not per NTA agent ).
>
> If you dislike the patch, I can modify it. If you don't like the feature
> (it's really more a hack to support buggy clients), or you prefer it in some
> other way, tell me.

I'd prefer reusing the NTATAG_EXTRA_100(). So perhaps copy the bit
irq_avoid_100 bit (or rename it as irq_extra_100) from  sa_extra_100
in incoming_create(), set it like you did in nta_incoming_set_params()
then check the bit (like you did) in incoming_timer() but also in
incoming_recv() (which you overlooked).

-- 
Pekka.Pessi mail at nokia.com

--
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image 
processing features enabled. http://p.sf.net/sfu/kodak-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] "Require: 100rel" in 180 Ringing Message

[Pekka Pessi]

2009/5/15 Jerry Richards :
> If I invoke nua_respond(nh, 180, "Ringing", SIPTAG_REQUIRE_STR("100rel"))
> alone, then sofia doesn't send out the 180 Ringing message at all.

Does your client indicate that it supports 100rel? If not, then Sofia
eats your 180.

-- 
Pekka.Pessi mail at nokia.com

--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables 
unlimited royalty-free distribution of the report engine 
for externally facing server and web deployment. 
http://p.sf.net/sfu/businessobjects
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] TAGS Seg Fault

[Pekka Pessi]

2009/6/21 Miguel Goncalves :
...
>            char *header;
>            header = sip_header_as_string( cli->home, (void*)
> sip->sip_content_type);
>
>            printf("\nCONTENT TYPE -> %s\n", header);
>        }
>
> but i just keep getting :
> INVITE : 200 OK
>
> CONTENT TYPE -> (null)
>
> can anyone help please? Where should i get the content_type and how?

That should work, it seems fine..

You could also print the value of sip->sip_content_type pointer, if
there is a syntax error that is hidden somewhere.

There was a bug in sip_header_as_string() before 1.12.9, I think, so
make sure you have recent enough version.

-- 
Pekka.Pessi mail at nokia.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] SIPTAG_HEADER_STR("Expires: 240") in nua_invite() Causes 900 Internal Error

[Pekka Pessi]

2009/6/24 Jerry Richards :
> If I include an "Expires: 240" header line in my nua_invite() call, it
> causes sofia-sip to generate the following error and the INVITE is not sent.
> This happens if I use SIPTAG_HEADER_STR("Expires: 240") or
> SIPTAG_EXPIRES_STR("240").
>
> nua_r_invite event: 900 Internal error at
>   ../../../libsofia-sip-ua/nua/nua_stack.c:2388
>
> I'm using version 1.12.9.  Does anyone know why this might be happening?

Complete mystery. The line number above does not seem to match the
released version.

Invite processing does not seem to touch to Expires in any way.

-- 
Pekka.Pessi mail at nokia.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] STUN integration

[Pekka Pessi]

2009/6/30 Inca Rose :
> I know the STUN code is not complete or is not 100% integrated on NUA
> or NTA.
> I would like to take a look and see if I can finish this work by
> integrating the missing parts.
> I have done similar work on my company's own SIP Stack and STUN Stack.

> All that I need is a some guidelines on where to start looking at the
> code.

We planned some 5 years ago to use "public transport address" API for
various NAT traversal mechanisms. IOW STUN would  figure out the
public binding within tport and the tport would then give upper layers
the public address. That does not work very well, at least with STUN.

So the outbound module is the best bet. The outbound is easier to use
only first REGISTER has been responded (after nta has resolved the
transport adddress) but perhaps we have to change that (but then we
would propably need changes in nua_register.c, too).

You probably need some hooks to send and receive STUN messages through
nta and tport. Have a peek on nta_transport_keepalive(), but perhaps
you have to invent whole new methods there.

> I what to integrate it on the signaling ( even if I agree that rport
> can do a better job ) and in the SDP.

The SDP part is problematic, I think it would be better to integrate
the STUN with RTP. How do you plan to use STUN here? Separate STUN
client running its own sockets, trying to find out the public
bindings?

> So, please, if someone can send me some guides on where to start I will
> put some resources ( 2 engineers ) to finish it.

-- 
Pekka.Pessi mail at nokia.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] SIP reinvite example

[Pekka Pessi]

2009/6/29 jonathan augenstine :
> I have been trying to find documentation or examples of how to bridge two
> calls and then transfer the media to the new endpoint.  Basically, the
> server places a call to a SIP URI and the call is established with endpoint
> A.  Then the server places a call to a second endpoint B.  After the call is
> established with endpoint B, the server performs a reinvite to transfer the
> RTP media stream to establish the RTP connection between endpoint A and
> endpoint B.

> I understand what needs to happen from a SIP standpoint, but I have not
> found the information on how to perform that operation with the Sofia-SIP
> library.  Can someone please point me towards an example that shows how to
> accomplish this task.  Thank you.

Say you have two nh's, a->nh and b->nh. If you use soa (enabled with
tag NUTAG_MEDIA_ENABLE(1)), you then proceed to

nua_invite(a->nh, SOATAG_USER_SDP(b->sdp), ...)

and once you get response with SDP answer, you do

nua_invite(b->nh, SOATAG_USER_SDP(a->sdp), ...)

However, you could also play 3pcc, and send re-INVITE without SDP to A

nua_invite(a->nh, NUTAG_MEDIA_ENABLE(0), NUTAG_AUTOACK(0),..)

and once you get the response with SDP offer, send it to B with

nua_invite(b->nh, NUTAG_MEDIA_ENABLE(0),
SIPTAG_CONTENT_TYPE(a_sip_resp->sip_content_type),
SIPTAG_PAYLOAD(a_sip_resp->sip_payload), 

When you get response with SDP answer back from B, you would send the
response to A in ACK (assuming offer was in 200 OK)

nua_ack(a->nh, SIPTAG_CONTENT_TYPE(b_sip_resp->sip_content_type),
SIPTAG_PAYLOAD(b_sip_resp->sip_payload), 

--
Pekka.Pessi mail at nokia.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] SIPTAG_REQUIRE_STR("timer") Does Not Include Session-Expires In Outbound INVITE

[Pekka Pessi]

2009/6/29 Jerry Richards :
> I noticed if I use SIPTAG_REQUIRE_STR("timer"), then the outbound INVITE
> does NOT include a "Session-Expires" header.  However, if I use
> SIPTAG_SUPPORTED_STR("timer"), then the outbound INVITE does include a
> "Session-Expires" header.  Also by the way, in both cases I set
> NUTAG_SESSION_TIMER(3600), NUTAG_MIN_SE(120),
> NUTAG_SESSION_REFRESHER(nua_any_refresher), and NUTAG_UPDATE_REFRESH(0).
>
> Is this expected behavior?  I would think sofia-sip would add the
> "Session-Expires" header in both cases.

The session timers are hairy - this is as expected. The Require header
is not considered when deciding if the "timer" feature is to be
supported locally.

RFC 4028 section 7.1 (UAC behavior):

   The Supported header field containing 'timer' MUST still
   be included, even if the Require or Proxy-Require header fields are
   present containing 'timer'.

-- 
Pekka.Pessi mail at nokia.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-sip debugging with DUMA

[Pekka Pessi]

2009/6/29 Bernhard Suttner :
> I am trying to find a certain bug in our application and tried D.U.M.A. ( 
> http://duma.sourceforge.net/ , based on efence).
>
> If I run the application, I get the following error:
>
> Program terminated with signal 11, Segmentation fault.
>
>
> #0  0xb7b3e559 in memccpy () from /lib/libc.so.6
>
> (gdb) bt
> #0  0xb7b3e559 in memccpy () from /lib/libc.so.6
> #1  0xb7c49406 in msg_params_dup () from /usr/lib/libsofia-sip-ua.so.0
> #2  0xb7c4c391 in msg_list_dup_one () from /usr/lib/libsofia-sip-ua.so.0
> #3  0xb7c41f2b in msg_header_dup_as () from /usr/lib/libsofia-sip-ua.so.0
> #4  0xb7c8709a in nhp_merge_lists () from /usr/lib/libsofia-sip-ua.so.0
> #5  0xb7c8652d in nhp_set_tags () from /usr/lib/libsofia-sip-ua.so.0
> #6  0xb7c8576f in nua_stack_set_params () from /usr/lib/libsofia-sip-ua.so.0
> #7  0xb7c7a078 in nua_stack_signal () from /usr/lib/libsofia-sip-ua.so.0
> #8  0xb7ccf425 in su_base_port_execute_msgs () from 
> /usr/lib/libsofia-sip-ua.so.0
> #9  0xb7ccf1bd in su_base_port_getmsgs () from /usr/lib/libsofia-sip-ua.so.0
> #10 0xb7ccf4ff in su_base_port_run () from /usr/lib/libsofia-sip-ua.so.0
> #11 0xb7ccc7c7 in su_port_run () from /usr/lib/libsofia-sip-ua.so.0
> #12 0xb7ccc7a2 in su_root_run () from /usr/lib/libsofia-sip-ua.so.0
> #13 0xb7cd in su_pthread_port_clone_main () from 
> /usr/lib/libsofia-sip-ua.so.0
>
>
> Does somebody know if that is really a bug of sofia-sip, or it is a bug of 
> DUMA? Is there any possibility to ignore that memccpy "mistake"?

Perhaps DUMA checks memccpy parameters, so you could apply the patch
below and see if that changes anything:

--- old-sofia-sip/libsofia-sip-ua/msg/msg_parser_util.c 2009-07-02
19:41:59.0 +0300
+++ new-sofia-sip/libsofia-sip-ua/msg/msg_parser_util.c 2009-07-02
19:41:59.0 +0300
@@ -539,7 +539,7 @@
   b += sizeof(*pp) * MSG_PARAMS_NUM(n + 1);

   for (i = 0; s[i]; i++) {
-MSG_STRING_DUP(b, pp[i], s[i]);
+MSG_STRING_DUP2(b, pp[i], s[i], e);
   }
   pp[i] = NULL;


--- old-sofia-sip/libsofia-sip-ua/msg/sofia-sip/msg_parser.h2009-07-02
19:41:59.0 +0300
+++ new-sofia-sip/libsofia-sip-ua/msg/sofia-sip/msg_parser.h2009-07-02
19:41:59.0 +0300
@@ -206,6 +206,10 @@
   (void)((s)?((p)=(char*)memccpy((void *)((d)=(char*)p),(s),0,INT_MAX))\
:((d)=NULL))

+#define MSG_STRING_DUP2(p, d, s, e)\
+  (void)((s)?((p)=(char*)memccpy((void *)((d)=(char*)p),(s),0,(e)-(d)))
\
+   :((d)=NULL))
+
 /* Solaris has broken memccpy - it considers last argument as signed */

 /** Calculate string size. @HI */

-- 
Pekka.Pessi mail at nokia.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] nua: call termination after INFO-timeout

[Pekka Pessi]

2009/7/7 Stefan Eckel :
> Some time ago I posted a question about handling the timeout problem with
> INFO messages.
>
> See: http://article.gmane.org/gmane.comp.telephony.sofia-sip.devel/3402
>
> We now found a solution, with a simple modification:
...
> I don’t know whether the solution is suitable for public project. We havn’t
> found any disadvantates so far.

Sorry about that, sip_response_terminates_dialog() and how it is used
by nua should be documented better.

INFO is somewhat problematic, the Freeswitch project have turned it as
a generic.purpose method (iow it behaves pretty much like MESSAGE, and
it does not anything to do with INVITE-initiated session. Probably
what is best way to go in a public project.

-- 
Pekka.Pessi mail at nokia.com

--
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time, 
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] IPv6 Authentication Bug

[Pekka Pessi]

Sorry, this has been slipped through...

2009/4/10 Jerry Richards :
> I found a rare sofia bug when answering a "401 Authentication Required"
> message if the realm is defined as an IPv6 address (e.g.
> "scheme:\"[fe80::204:23ff:fea7:d60a]\":user:password").  The symptom was a
> "904 No Matching Challenge" reply to the nua_authenticate().

Oops. The semicolon in the realm is the reason why the API has been
defined to use quotes there.

> I changed the following lines (from base version 1.12.9+) in
> libsofia-sip-ua/iptsec/auth_client.c (diff file also attached).  This
> modification successfully authenticates the IPv6 formatted realm.

Thanks for the patch, I'll push it shortly.

--Pekka

> 303,308c303,309
> <   /* Data is string like "Basic:\"agni\":user1:secret" */
> <   if (s && (s = strchr(scheme = s, ':')))
> <     *s++ = 0;
> <   if (s && (s = strchr(realm = s, ':')))
> <     *s++ = 0;
> <   if (s && (s = strchr(user = s, ':')))
> ---
>>   /* Data is string like "Basic:\"agni\":user1:secret" (IPv4) or
> "Basic:\"[fe80::204:23ff:fea7:d60a]\":user1:secret" (IPv6) */
>>   if (s && (s = strchr(scheme = s, '\"')))
>>     *(s-1) = 0;
>>   if (s) realm = s++;
>>   if (s && (s = strchr(s, '\"')))
>>     *++s = 0;
>>   if (s && (s = strchr(user = ++s, ':')))
>
> Best Regards,
> Jerry
>
> --
> This SF.net email is sponsored by:
> High Quality Requirements in a Collaborative Environment.
> Download a free trial of Rational Requirements Composer Now!
> http://p.sf.net/sfu/www-ibm-com
> ___
> Sofia-sip-devel mailing list
> Sofia-sip-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
>
>



-- 
Pekka.Pessi mail at nokia.com

--
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time, 
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] 64-bit issue in sofia-sip (patch)

[Pekka Pessi]

2009/9/24 Aleksander Morgado :
> We just faced an issue happening only in 64-bit architecture, and found that
> it was already fixed by FreeSWITCH guys in their own sofia-sip repo:
> http://jira.freeswitch.org/browse/SFSIP-136
>
> It seems the fix is not included in the official repo, which would be good
> to have.

Thanks for noticing this. I've applied Stephan's patch.


-- 
Pekka.Pessi mail at nokia.com

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] problem shutting down nua

[Pekka Pessi]

2009/9/23 Francesco Lamonica :
> hi ppl, i am having some problems in shutting down the nua; i am still
> using sofia 1.12.9 and i am handling the eventloop with su_root_step.
>
>  I read on the list  the procedure pessi suggested:
>  1. call nua_shutdown(mynua)
>  2. wait for nua_r_shutdown with status code 200 then
>  3. call nua_destroy
>  4. break out of event loop (this should not be necessary in my case right?)
>  5. then call su_deinit()
>  my problem is that i never get the nua_r_shutdown, with any status

> what can i check?

That sounds weird. Best you can do is to enable more detailed
debugging output (e.g., env vars NUA_DEBUG=9 NTA_DEBUG=9) and try to
see where the execution hangs within the stack.

-- 
Pekka.Pessi mail at nokia.com

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] New release schedule?

[Pekka Pessi]

2009/9/23 Aleksander Morgado :
> Is there any planned date for a new stable (1.12.11) release of sofia-sip?

My current plan is to make a next release after we (Maemo devices
within Nokia) have stable Maemo 5 release. That should happen Real
Soon Now. However, there are few patches by Mikhail Zabaluev, who is
responsible for telepathy-sofiasip, that I'd like to include in the
stable release.

At the same time I'm planning to ditch Darcs as the principal VCS and
start using git. I'll have to check if it is possible to host
sofia-sip on maemo.org or should I set up something different.

-- 
Pekka.Pessi mail at nokia.com

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Question aboiut NTA and sip_t

[Pekka Pessi]

2009/9/9 Daniel Corbe :
> When NTA receives a request which doesn't match an existing transaction it 
> passes a pointer to the callback function of type sip_t.  Can this pointer be 
> dereferenced through the lifetime of the transaction or does it go poof as 
> soon as I exit the callback function?

As Aleksander said, you can use sip_t as long as the transaction is alive.

The sip_t pointer lives inside an abstract msg_t container and you can
also get a new reference to it with nta_incoming_getrequest(). After
you are done with your sip_t / msg_t reference, you should remove the
reference with msg_destroy().

-- 
Pekka.Pessi mail at nokia.com

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] sresolv: DNS response code 5 (refused) not handled / Fallback to second DNS server not working

[Pekka Pessi]

2009/9/18 Timo Bruhn :
> [...] When sofia-sip tries to register its user agents at startup, the first 
> dns server is used
> to resolve the server name. The server refuses the request. Now the expected 
> behaviour
> should be a fallback to the second server. Unfortunately this never happens.

Yes, the fallback is probably the right thing to do.

> One way to fix this is to mark the server as temporarily unavailable as I did 
> in the patch
> attached to this mail. The fix is working fine in my test environment.

> Could anyone of the developers please have a look at it to verify that it 
> does not break
> anything else i did not see?

It should not break anything, or at least I don't think it does, but
here is my patch that also falls to the next server on server error
and
 not implemented error. Please give it a try, and report if it fixes
your problems (or crashes and burns), too.

-- 
Pekka.Pessi mail at nokia.com
--- old-sofia-sip/libsofia-sip-ua/sresolv/sres.c	2009-09-24 13:16:38.0 +0300
+++ new-sofia-sip/libsofia-sip-ua/sresolv/sres.c	2009-09-24 13:16:38.0 +0300
@@ -3503,6 +3503,14 @@
 sres_send_dns_query(res, query);
 query->q_retry_count++;
   }
+  else if (error == SRES_AUTH_ERR ||
+	   error == SRES_UNIMPL_ERR ||
+	   error == SRES_SERVER_ERR) {
+dns->dns_icmp = res->res_now;
+sres_cache_free_answers(res->res_cache, reply);
+/* Resend query/report error to application */
+sres_resend_dns_query(res, query, 0);
+  }
   else if (!error && reply) {
 /* Remove the query from the pending list */
 sres_remove_query(res, query, 1);
--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Modify sofsip cli to work with PCMA instead of PCMA

[Pekka Pessi]

2009/9/14 fabien comte 
> I want sofsip cli works with PCMA instead of PCMU. How to modify it ?

Just in case you have not figured out it yet: you have to change the
RTP payload type on m= line to 8, too. The rtpmap should work,
provided the payload number on m=audio line and a=rtpmap are same, at
least in principle, but most implementations just look the payload
type number for well-known codecs like PCMU or PCMA.

> I modified ssc_media_gst.c [...] I tryed
> ->
>   self->sm_pt = 8; /* PT=0 => PCMA */
>   /* step: initialize the PT<->caps hash table */
>   pt_caps = gst_caps_new_simple ("application/x-rtp",
>  "clock-rate", G_TYPE_INT, 8000,
>  "encoding-name", G_TYPE_STRING, "PCMA",
>  NULL);
>
>   /* step: describe capabilities in SDP terms */
>   /* support only G711/PCMA */
>   caps_sdp_str = su_strcat(home, caps_sdp_str,
>   "v=0\r\n"
>   "m=audio 0 RTP/AVP 0\r\n"
>   "a=rtpmap:8 PCMA/8000\r\n");

   "m=audio 0 RTP/AVP 8\r\n"
   "a=rtpmap:8 PCMA/8000\r\n");

>   *dest = strdup(caps_sdp_str);
>   su_free(home, caps_sdp_str);
> It does not work (FAILED with 501 Not Implemented Yet)

--
Pekka.Pessi mail at nokia.com

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
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 use NUA iso NTA for basic registrar and calls

[Pekka Pessi]

2009/9/14 EiSl 1972 :
> I would like to use the NUA abstraction layer for my very simplified SIP
> call 'generator', which is of itself a kind of PBX (from SIP client point of
> view). Maybe call it an 'announcement server', calling each client when
> there is something to say :)
>
> Basically my requirements are:
> - Allow incoming registrations from multiple SIP clients
> - Being able to make calls (INVITE) to those registered clients, where I
> already know the media endpoints on my side. So I sent INVITE with valid SDP
> entries.
> - Being able to reINVITE to those clients
> - Being able to end calls (CANCEL / BYE)
> ==> it is no problem if the contact-info or from-field of the sent INVITEs
> equals for all clients.
>
> My point is:
> I would like to use NUA for this rather than NTA and then using the
> test_proxy.c as reference.
> Maybe I'm very wrong, but I'm under impression that this could be possible
> when I was checking the developers archive referring to introduction to
> nua_i_register and the discussion "NUTAG_IDENTITY and contact header"
> somewhere middle 2006.

Yes, it is possible to use nua as registrar. As far as i can recall,
you should include the tag NUTAG_ALLOW("REGISTER") with nua_create()
or some initial nua_set_params() call in order to get nua_i_register
events. As you said, there is some implementation on registrar
protocol in test_proxy.c. It is basically just the rules on accepting
and updating the Contact URIs and their expiration times.

> I'm aware that NUA is meant to be an UserAgent abstraction, but in principle
> it could still acts as a user-agent towards each registered client.
> If this is possible, can someone provide some guidelines? This since there
> is no reference on how to do this. Especially with respect to how to use
> nua_invite to build the correct messages to each client.

> The realization of
> the register seems straight-forward, except that a (re)register from the
> same client results into new handle so this gives me the impression that NUA
> is just doing a pass-through and does not do any administration on these.
> I'm willing to put the gathered knowledge in some Wiki / help to be added to
> the Sofia online docs.

You should save AoR (in To header) and Contact URIs from each
nua_i_register event from your clients. You then use AoR/To header
from nua_i_register as To header in INVITE, and Contact URI as request
URI (passed in as NUTAG_URL()).

The proxy case is bit different, it uses request URI in incoming
message to look for an AoR and the forward the request to the Contact
URIs.

-- 
Pekka.Pessi mail at nokia.com

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Wrong answer from sofia-sip

[Pekka Pessi]

2009/8/26 Bernhard Suttner :
> attached the network trace. You have to decode the first paket as SIP in 
> Wireshark (destination ip).

Contact is used when the callee send caller a BYE request (or OPTIONS
or UPDATE or INFO etc...).

The RFC 3261 (section 18.2.1) specifies how to send the response:
unless you happen to have maddr parameter, the response is sent to the
source address, which is 10.251.0.1. If you can include a maddr
parameter in the incoming INVITE Sofia should send the response to the
address specified in maddr parameter. So you could have request like
this:

INVITE sip:757-2...@10.251.0.101:12004 SIP/2.0
Via: SIP/2.0/UDP 10.27.0.60:5060;branch=z9hG4bK3745033304-3162;maddr=10.27.0.60
From: "Aman DECT" ;tag=shorUA_3745033458-3162
To: 757-2026 
Contact: "Aman DECT" 
...

and Sofia would respond like this (to 10.27.0.60):

SIP/2.0 100 Trying
Via: SIP/2.0/UDP
10.27.0.60:5060;branch=z9hG4bK3745033304-3162;maddr=10.27.0.60;received=10.251.b0.1
From: "Aman DECT" ;tag=shorUA_3745033458-3162
To: 757-2026 
...



--Pekka

> -Ursprüngliche Nachricht-
> Von: Michael Jerris [mailto:m...@jerris.com]
> Gesendet: Mittwoch, 26. August 2009 16:53
> An: sofia-sip-devel
> Betreff: Re: [Sofia-sip-devel] Wrong answer from sofia-sip
>
> Can you paste the actual sip trace here.
>
> Mike
>
> On Aug 26, 2009, at 6:45 AM, Bernhard Suttner wrote:
>
>> Hi,
>>
>> I have the following problem (using sofia sip 1.12.9):
>>
>> A (non sofia-sip) sends INVITE to B (user agent with sofia-sip)
>> B send back a Trying
>> B send Ringing and then a 200 OK
>>
>> Most important data for the INVITE from A:
>> Src IP: 10.251.0.1
>> Dest IP: 10.251.0.101
>> Contact: 10.27.0.60
>>
>> The Trying generated from sofia-sip has the data:
>> Src IP: 10.251.0.101
>> Dest IP: 10.251.0.1
>> VIA: SIP/2.0/UDP 10.27.0.60;branch=ydfasfasfsf;received=10.251.0.1
>>
>> The problem is, that B use the IP 10.251.0.1 as destination and not
>> the
>> contact of the INVITE (that would be 10.27.0.60). Also in the RINGING
>> and 200 OK sofia-sip will use the Src-IP and not the Contact addr.
>>
>> Can I somehow configure sofia-sip in that way, that it will use the
>> CONTACT addr instead of the Src IP?
>>
>> Thanks in advance!
>>
>> Best regards,
>> Bernhard Suttner
>>
>> --
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
>> 30-Day
>> trial. Simplify your report design, integration and deployment - and
>> focus on
>> what you do best, core application coding. Discover what's new with
>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>> ___
>> Sofia-sip-devel mailing list
>> Sofia-sip-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
>
>
> --
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> ___
> Sofia-sip-devel mailing list
> Sofia-sip-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
>
> --
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> ___
> Sofia-sip-devel mailing list
> Sofia-sip-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
>
>



-- 
Pekka.Pessi mail at nokia.com

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Mac OS X 10.6 build problems

[Pekka Pessi]

Any news on this? Perhaps you have something in /usr/local/lib linking
to iconv? What is the "intl" library?

Try grep -l iconv /usr/lib/* /usr/local/lib/* ...

--Pekka


2009/9/1 Michael Jerris :
> I am chasing down this same issue on my box.  I should have fixes sometime
> this week and will push patches for them when I have them.  Note, I did have
> a successfull snow lep build a few weeks back before they did gold master on
> a different box, still trying to chase down what changed sense then.
> Mike
> On Aug 31, 2009, at 7:03 PM, Daniel Corbe wrote:
>
> gmake[3]: Leaving directory
> `/usr/local/src/sofia-sip-1.12.10/libsofia-sip-ua-glib/su-glib'
> gmake[3]: Entering directory
> `/usr/local/src/sofia-sip-1.12.10/libsofia-sip-ua-glib'
> /bin/sh ../libtool --tag=CC --mode=link gcc  -g -O2   -o
> libsofia-sip-ua-glib.la -rpath /usr/local/lib -version-info 3:0:0
>  su-glib/libsu-glib.la -L/usr/local/lib -lglib-2.0 -lintl   -lssl -lcrypto
> -lz   -lpthread
> mkdir .libs
> grep: /usr/lib/libiconv.la: No such file or directory
> sed: /usr/lib/libiconv.la: No such file or directory
> libtool: link: `/usr/lib/libiconv.la' is not a valid libtool archive
> gmake[3]: *** [libsofia-sip-ua-glib.la] Error 1
> gmake[3]: Leaving directory
> `/usr/local/src/sofia-sip-1.12.10/libsofia-sip-ua-glib'
> gmake[2]: *** [all-recursive] Error 1
> gmake[2]: Leaving directory
> `/usr/local/src/sofia-sip-1.12.10/libsofia-sip-ua-glib'
> gmake[1]: *** [all-recursive] Error 1
> gmake[1]: Leaving directory `/usr/local/src/sofia-sip-1.12.10'
> gmake: *** [all] Error 2
> sh-3.2# cd /usr/lib
> sh-3.2# ls *iconv*
> libiconv.2.4.0.dylib    libiconv.2.dylib        libiconv.dylib
>
> --
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.
>  http://p.sf.net/sfu/bobj-july___
> Sofia-sip-devel mailing list
> Sofia-sip-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
>
>
> --
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> ___
> Sofia-sip-devel mailing list
> Sofia-sip-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
>
>



-- 
Pekka.Pessi mail at nokia.com

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] 2nd SIP INVITE for Fax Call- 200 OK port set to 0

[Pekka Pessi]

2009/8/31 Kaustubh Madhav PATWARDHAN :
> I am developing a fax gateway application using the Sofia SIP.
>
> Following is the sequence of SIP messages happening in that order between
> Calling and Called Gateways
>
> Both the gateways are running Sofia SIP
>
> Calling Gateay    Called Gateway
>
> 1) INVITE (audio 9000 RTP..)     -> 2) 200 OK (audio 9000 RTP...)
>   |
>   |
>  \/
> 4) 200 OK (image 0 UDPTL t38) <- 3) INVITE (image 9000 UDPTL t38)
>
> When the Called Gateway sends the second INVITE for fax data, the Calling
> Gateway sends 200 OK, with image port set to 0. Then sending of fax data
> fails. I do not know, why the 200 OK should send image with port set to 0 ?
> Could you please provide your valuable insight and expert advice on this?

You should probably replace your user SDP with m=image line when
responding to 2nd INVITE?

If your user SDP does not have m=image line, then the explanation is
simple, m=image 0 means that the proposed fax transmission media in
2nd INVITE got rejected.

If you do have m=image line, then you have two options:

* use SOATAG_ORDERED_USER(1) and include only m=image line in user SDP
* use SOATAG_ORDERED_USER(0) (default) and include m=audio and m=image
lines in user SDP

Or then there might be a bug, so an example of the your session
including the SDPs sent in all 4 messages along with debugging output
with env variables NUA_DEBUG=9 SOA_DEBUG=9 would be very helpful...

-- 
Pekka.Pessi mail at nokia.com

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Making sofia request type AAAA in DNS Query

[Pekka Pessi]

2009/8/26 Jerry Richards :
> I am cross-compiling sofia-sip and I'm wondering if anyone has gotten
> sofia-sip to request type  addresses in its DNS query?  Right now I only
> see it do a type A request and if that fails, it gives up.  I would like it
> to attempt type A and if that fails, attempt type .

I'm afraid you have to fix the source code. The sa_res_order field in
nta_t object is used to determine the order, and it is never
initialized (and it defaults to nta_res_ip6_ip4). A tag for
determining it value is missing.

You can add its initialization in nta_agent_create().

> I can see the RES_OPTIONS and SRES_OPTIONS in the documentation.  Are these
> compile-time environment variables?  Or are they runtime environment
> variables.  This makes a big difference when cross-compiling.

They are environment variables, I'm sorry if the documentation is
unclear. However, they do not change the nta resolving order.

-- 
Pekka.Pessi mail at nokia.com

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] problem shutting down nua

[Pekka Pessi]

2009/9/29 Francesco Lamonica :
> Hi all, this is what i get (with latest darcs) when i call nua_shutdown(nua);

There is nothing from nua/nta? Do you set your debuging log levels
with su_log_set_level()?

--Pekka

> tport_tsend(0x1a961b0) tpn = */192.168.23.200:5060/sip
> tport_resolve addrinfo = 192.168.23.200:5060
> tport_by_addrinfo(0x1a961b0): not found by name */192.168.23.200:5060/sip
> tport_vsend(0x1a961b0): 693 bytes of 693 to udp/192.168.23.200:5060
> tport_vsend returned 693
> tport_pend(0x1a961b0): pending 0x7f8d4801add0 for
> udp/192.168.23.2:5080 (already 0)
> shutdown result: 0
> tport_wakeup_pri(0x1a961b0): events IN
> tport_recv_event(0x1a961b0)
> tport_recv_iovec(0x1a961b0) msg 0x7f8d480197d0 from
> (udp/192.168.23.2:5080) has 430 bytes, veclen = 1
> tport_deliver(0x1a961b0): msg 0x7f8d480197d0 (430 bytes) from
> udp/192.168.23.200:5080/sip next=(nil)
> tport_release(0x1a961b0): 0x7f8d4801add0 by 0x7f8d480173a0 with
> 0x7f8d480197d0 (preliminary)
> tport_wakeup_pri(0x1a961b0): events IN
> tport_recv_event(0x1a961b0)
> tport_recv_iovec(0x1a961b0) msg 0x7f8d480197d0 from
> (udp/192.168.23.2:5080) has 506 bytes, veclen = 1
> tport_deliver(0x1a961b0): msg 0x7f8d480197d0 (506 bytes) from
> udp/192.168.23.200:5080/sip next=(nil)
> tport_release(0x1a961b0): 0x7f8d4801add0 by 0x7f8d480173a0 with 0x7f8d480197d0
> tport_destroy(0x1ad7650)
>
> still no nua_r_shutdown received in my callback
>
> any suggestions?
>



-- 
Pekka.Pessi mail at nokia.com

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
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 disable auto-respond for incoming REFER

[Pekka Pessi]

2009/9/30 Stefano Sabatini :
> and seems to *assume* that the response to the REFER event will be
> automatically sent, and I experienced the sofia-sip stack will
> automatically send a response with status 202.
>
> I wonder if it is possible to disable this behavior, and manually
> choose (e.g. with nua_respond()) which response to give to the REFER
> method.

Yes, you can do that. Include the tag NUTAG_APPL_METHOD("REFER") in
nua_create() or nua_set_params().

-- 
Pekka.Pessi mail at nokia.com

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Fw: Changing IP address.

[Pekka Pessi]

2009/10/2 Robert Han 
> I just want to raise the issue that we asked you earlier back in July 31 (see 
> below).
>
> You said that if we shutdown the sofia stack, and if there are outstanding 
> sip sessions (for example 4 active sessions), we do not need to nua_bye() or 
> even nua_handle_destroy() before invoking nua_shutdown().
>
> according to your reply, the nua stack is guaranteed to terminate outstanding 
> nua operations, and then publish nua_i_terminate as the final event with a 
> operation handle, so that we can destroy that handle.
>
> that never happened.

That *should* happen. however, the IP address change also means that
all the TCP connections and the UDP sockets bound to the old IP
address become useless. Do you include maddr= parameter in the
NUTAG_URL() in nua_create()?

--Pekka

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

[Sofia-sip-devel] FYI: Back again

[Pekka Pessi]

Hello all,

As you might have noticed I've not spent much time with Sofia SIP
lately. However, Sofia SIP has not been abandoned completely. From now
on, I have reserved some time specifically to maintaining Sofia SIP
and following this mailing list.

-- 
Pekka.Pessi mail at nokia.com

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] SIP_PAYLOAD_STR first byte 0x00 always causes 0 length content.

[Pekka Pessi]

2010/3/11 Trevor Nunes :
> I'm trying to send encapsulated 3GPP2 MO-SMS ( CDMA text message ). To do
> this the first byte of the payload must be 0x00, if I use SIP_PAYLOAD_STR(
> data ) and first byte is zero it seems to truncate assuming the 0x0 is a
> NULL terminator.
>
> I've tried using SIP_PAYLOAD( sip_payload_t my_payload ) but not making much
> progress. I can successfully generate L2-ACK's since the first byte is
> always 0x02.
>
> void send_3gpp2_sms_mo(nua_t *nua, sip_t const *sip)
> {
>  nua_handle_t *h;
>  sip_payload_t payload = SIP_PAYLOAD_INIT;
>
>  char mo_payload[] =  {
>    0x00, 0x00, 0x10, 0x02   // P2P MSG + Teleservice ID
>   ,0x04, 0x02, 0x02, 0x07
>   ,0x62, 0x69, 0x69, 0x69   // Phone number garbled for email!
>   ,0x80, 0x55, 0x01, 0x06
>   ,0x08, 0x38, 0x00, 0x16
>   ,0x20, 0x03, 0x50, 0x0d
>   ,0x03, 0x01, 0x0d, 0x10
>   ,0x0a, 0x50, 0x40, 0x01   // Tele Type
>   ,0x07, 0x0e, 0x09, 0x05   // Callback and other crap
>   ,0x2a, 0x1a, 0x4c, 0x3c
>   ,0x00, 0x80, '\0'
>     };
>
>   fprintf(stderr,"smsagent: Tx SMS to phone \n");
>   h = nua_handle(nua, NULL, SIPTAG_TO_STR(gREMOTE_CLIENT_TAG), TAG_END() );
>   nua_message(h, SIPTAG_CONTENT_TYPE_STR("application/vnd.3gpp2.sms"),
> SIPTAG_PAYLOAD( &payload ), TAG_END() );
>   nua_handle_destroy(h);
>
> }
>
> So how can I generate a byte sequence where the first byte is zero and have
> it correctly determine the length of the payload?  Is there an example of a
> direct sip_payload_t .pl_data  memcpy or similar that I can get working ?

Probably there are, but all you have to do is to initialize pl_data
with data pointer and pl_len with its length.

--Pekka


-- 
Pekka.Pessi mail at nokia.com

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
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_respond and deallocated memory

[Pekka Pessi]

2010/3/12 Martin Drasar :
> On 3.3.2010 16:36, Jarod Neuner wrote:
>> Calls to nua_respond, or any other method that sends or receives a response, 
>> should always be considered an async operation.  A reasonable approach would 
>> be to use the memory home associated with that handle (nua_handle_home) to 
>> allocate the data - the data would be automatically released when the handle 
>> is destroyed.  If that particular message is generated multiple times for 
>> each handle, use the application pointer (nua_handle_magic) to avoid a 
>> memory leak.
>
> Thank you Jarod for clarification. Using a home seems like a reasonable
> idea when the stack is not making local copies (which makes me wonder
> why not).

It was a bug, but I think it was fixed in 1.12.10.

-- 
Pekka.Pessi mail at nokia.com

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] suppress Content Disposition

[Pekka Pessi]

2010/3/8 Ronny Aruch :
> I use sofia 1.12.8.

> How can I suppress Content Disposition header from being sent.
> I added SIPTAG_CONTENT_DISPOSITION(NULL)to NUA_INVITE but the header is
> still sent.


It seems to me that there is no way to do that above the API, you have
to hack inside the stack.

-- 
Pekka.Pessi mail at nokia.com

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Please, make the sigcomp plugin for sofia-sip free software

[Pekka Pessi]

2010/3/9 Aleksander Morgado :
> My humble request is then, please make the sigcomp plugin for sofia-sip
> free software, publicly available for everyone, so that we can keep on
> developing applications using the sofia-sip stack also including SigComp
> support.

I'll have a peek on the libraries and see if one of them could be used
with reasonable effort. However, there might be some legal issues,
too, so I can't promise anything.

-- 
Pekka.Pessi mail at nokia.com

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] simple memory allocation question

[Pekka Pessi]

2010/3/15  :
> Simple questionwhen I use sip_X_make( home, char *) and then attach that 
> header to a response message I am sending via nta, do I need to explicitly 
> su_free that header?  i.e.
>
> sip_contact_t *c1 = sip_contact_make( home, szContact1 ) ;
> nta_incoming_treply( irq, SIP_300_MULTIPLE_CHOICES,  SIPTAG_CONTACT( c1 ), 
> TAG_END() ) ;
> //DO I NEED TO su_free this?

Nope, it will be freed when your home is destroyed/unref:ed.

> If I do need to free it, can I do so immediately after calling 
> nta_incoming_reply?

You can do it immediately after calling nta_incoming_reply().

-- 
Pekka.Pessi mail at nokia.com

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] SIP_PAYLOAD_STR first byte 0x00 always causes 0 length content.

[Pekka Pessi]

2010/3/12 Trevor Nunes :
> The problem is I can send any type of content I want as long as the first
> byte is not 0x00 ... If this byte is 0x00 it will send a 0 byte SIP message
> out.  So for example here is a short message that works perfectly, If I
> change the payload[0] = 0x02 line to payload[0] = 0x00 an empty Content
> Length is generated ...
>
>
> --
>   nua_handle_t *h;
>   static int lastSequenceNum = -1;
>   char payload[5];
>
>   payload[0] = 0x02;
>   payload[1] = 0x07;
>   payload[2] = 0x01;
>   payload[3] = gMOSMS_seqnum << 2;
>   payload[4] = '\0';
>
>
>   printf("smsagent: Sending L2-ACK with seq: %d \n", gMOSMS_seqnum );
>
>   if( lastSequenceNum == gMOSMS_seqnum)
>   {
>     printf("smsagent: duplicate seq: %d \n", gMOSMS_seqnum );
>   }
>
>   // send_3ggp2_sms(nua, payload );
>
>   h = nua_handle(nua, NULL, SIPTAG_TO_STR(gREMOTE_CLIENT_TAG), TAG_END() );
>   nua_message(h, SIPTAG_CONTENT_TYPE_STR("application/vnd.3gpp2.sms"),
> SIPTAG_PAYLOAD_STR( payload ), TAG_END() );
>   nua_handle_destroy(h);

> I guess I need to use a different macro that doesn't treat the payload as a
> string or initialize an empty SIP message and cast the pl_data pointer to my
> new message ? Should I just malloc() a bunch of bytes and assign this to
> pl_data and set pl_en  even so I'm still using the SIPTAG_PAYLOAD_STR()
> macro so is there way of creating a nua_message where it will treat the
> pl_data not as a string ?

Yes, you are correct - you need to use the tag macro SIPTAG_PAYLOAD()
with a pointer to initialized sip_payload_t structure as its argument.
For example,

nua_handle_t *h;
static int lastSequenceNum = -1;
char payload[5];

payload[0] = 0x02;
payload[1] = 0x07;
payload[2] = 0x01;
payload[3] = gMOSMS_seqnum << 2;
payload[4] = '\0';

printf("smsagent: Sending L2-ACK with seq: %d \n", gMOSMS_seqnum );

sip_payload_t pl = SIP_PAYLOAD_INIT();
pl.pl_data = payload;
pl.pl_len = sizeof payload;

h = nua_handle(nua, NULL, SIPTAG_TO_STR(gREMOTE_CLIENT_TAG), TAG_END() );
nua_message(h, SIPTAG_CONTENT_TYPE_STR("application/vnd.3gpp2.sms"),
  SIPTAG_PAYLOAD(&pl), TAG_END() );
nua_handle_destroy(h);

-- 
Pekka.Pessi mail at nokia.com

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] simple memory allocation question

[Pekka Pessi]

2010/3/16  :
> Just to make sure I am not doing something wrong, my home gets allocated when 
> my program starts, and I do not destroy it until my (long running) program 
> ends.  So although it would not be a true memory leak it sounds like it would 
> cause memory growth if I do not free it, and thus I would be better to free 
> it immediately after nta_incoming_reply(), is that correct ?

Yes, that is right.

> BTW, while we are on the subject of memory allocation, I am also using 
> messages using su_msg_create() to send msgs between my root and clone tasks, 
> where I use the feature to have some user-specified data area allocated with 
> the message, and I never explicitly need to free that memory, correct?

Yes, you are correct. The data-area is allocated with a single
malloc() along with the main su message.

--Pekka


-- 
Pekka.Pessi mail at nokia.com

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] recvonly attibute unrecognized

[Pekka Pessi]

2010/3/22 elisa_murgia :
> I'm doing some tests with on hold features. When trying to send an offer with 
> a=recvonly attribute, I'd expect an answer with a=sendonly attribute:
>
> RFC 3264
> If a media stream is
> listed as recvonly in the offer, the answer MUST be marked as
> sendonly or inactive in the answer.
>
> but, Sofia always answers without any onhold attribute and stream continues 
> in full-duplex mode.
> Any hints?

I'm afraid you have found a bug. The logic is in soa_sdp_mode_set() in
libsofia-sip-ua/soa/soa_static.c, it seems to me that recvonly in
remote SDP is just ignored.

-- 
Pekka.Pessi mail at nokia.com

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Problem with processing responses to outgoing requests in a different thread

[Pekka Pessi]

2010/3/18 Aleksander Morgado :
...
> Now, in order to avoid this, the idea is to just make sure that at least
> one reference of the msg_t is available while we process the reply in
> thread B. This could be managed if inside our callback stored in
> orq->orq_callback we could call msg_ref_create() and call ourselves
> msg_destroy() when we no longer need to process the associated sip_t.

It seems to me that your solution with msg_t reference fine.

> Of course, with this solution we just avoid the invalid reads in
> valgrind, but, still we will see that retransmissions arrive to the
> nta_agent_t and they are not treated as retransmissions, as we still
> didn't 'complete' the outgoing request in thread B while received the
> new message in thread A. Any possible way of avoiding this?

You have to keep track of 2XX responses to INVITE somehow. Perhaps
easiest way is to create a tagged outgoing transaction with
nta_outgoing_tagged() before handling the 200 OK to thread B. If the
stack receives a new 200 OK with the same To tag, it should be fed to
the tagged transaction and its callback, not the original one.
(However, please note that the code dealing with the tagged
transactions is not very throughly tested.)  A simpler method would
just store the To tag and check that (and drop the newly received 200
OK if the tags match.)

In any case, you are left with an interesting problem: what to do with
two 200 OK messages from two different endpoints.

-- 
Pekka.Pessi mail at nokia.com

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
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-SIP sorting of SRV records defeats DNS server round-robin SIP traffic distribution

[Pekka Pessi]

2010/3/19 Jim Thomas :
> The DNS server is provisioned to rotate the SRV records
> round-robin, so the first choice will alternate among the three
> destinations.  I can see in a packet trace that the SRV record
> sequence is in fact alternating across DNS lookups.  (These are
> the external DNS lookups after the Sofia-SIP DNS cache expires).
> The problem is that even though the DNS response presents the
> SRV records in varying order, Sofia-SIP always selects the same
> particular SRV record, so outbound calls always go to a single
> destination and are not distributed.
...
> The result is that Sofia-SIP loses the SRV record sequence intended
> by the round-robin ordering by the DNS server, and the SRV record
> selected by Sofia-SIP is always the record that just happens to have
> the target name with the lowest alpha sort key.

Sofia SIP is supposed to select SRV record randomly. However there is
a problem with SRV records with zero weight. If all the SRV records
have zero weight, the first one after the sort is always selected. A
far as I can remember, this is because the weight 0 is used to
indicate that no server selection is done. If the weights are greater
than 0, the server selection should be pretty random.

> It seems to me that the correct sort would be by priority and weight
> only, and where those are identical for adjacent records, the original
> SRV record sequence would be preserved so the first choice intended
> by the DNS server round-robin ordering would be used by Sofia-SIP
> to determine where to send the SIP for the outbound call.

You are right, the sorting tries now support stateless proxies, the
nta should probably not use the default sorting algorithm but do its
own or do some special randomization in case of 0 weights.

-- 
Pekka.Pessi mail at nokia.com

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Remove an unknown sip header

[Pekka Pessi]

2010/3/26 Alexandre Brito :
> I flowing through sofia sip documentation/code trying to find the best way to 
> remove an unknown sip header.
> I found that its easy to add any header my using SIPTAG_HEADER_STR or even 
> SIPTAG_HEADER(x) by define a new header struct.
>
> However, what's the best option to remove those kind of headers from a sip 
> message?

I don't think it is possible when using the tags.

> Should I create a new SIPTAG around the new header, for instance 
> SIPTAG_P_CHARGING_VECTOR()? What are my options?

You have to either go through the list of unknown headers explicitly,
or define your own header parser class object. See the sofia-sip-2543
package for examples. If you feel like it, a sofia-sip-3455 package
would probably be appropriated by many folks here.

-- 
Pekka.Pessi mail at nokia.com

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] I need to send a re-invite with the SDP address set to 0.0.0.0

[Pekka Pessi]

2010/6/22 Inca Rose :
> Can someone help me here ?
> I cannot find a way to set the SDP c= line to 0.0.0.0 I a session update (
> re-invite )
> I set the SOA_ADDRESS tag to 0.0.0.0 in the reinvite but the new INVITE
> request keeps sending the c line with the original value.

The c=0.0.0.0 is a magic value for call hold, soa does not want to use it.

> What I'm doing wrong ??

You are not doing anything wrong, but there should be a tag which
would allow you to use c=0.0.0.0 to hold a session.

-- 
Pekka.Pessi mail at nokia.com

--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Is sofia-sip dead?

[Pekka Pessi]

2010/6/18 Stefano Sabatini :
> On date Thursday 2010-06-17 01:26:51 -0400, Michael Jerris phoned this:
>> sofia-sip is not dead.  The repository is in the process of moving
>> to a new repo.  I expect a chunk of patches to be merged in soon, I
>> was discussing this with the maintainer last week.
>>
>> Mike
>>
>> On Jun 16, 2010, at 9:27 PM, Daniel Jabbour wrote:
>>
>> > Hi,
>> >
>> > I am just getting started with a SIP application that I'm writing
>> > for a personal project. I am getting ready to use Sofia-SIP as my
>> > app's library. However, I noticed:
>> >
>> > * Sofia-Sip's CVS on SF is 18+ months old, and the latest release in CVS 
>> > was 1.12.9
>> > * Links on the download page for snapshots, release notes archive, etc are 
>> > broken
>> > * The latest packaged source release is 1.12.10
>> >
>> > So, if the latest release is greater than the version tagged in
>> > CVS, where is development taking place? Has the repository moved?
>> > Is Nokia working entirely in-house? Or is Sofia-SIP dead?
>> >
>> > Any thoughts would be greatly appreciated.
>
> The last darcs commit:
> Tue Sep 29 14:24:17 CEST 2009  Pekka Pessi 
>
>  Bug report and original patch by Timo Bruhn.
>
> and there hasn't been much activity from the maintainers in the last
> months and the project somehow didn't managed to get a significant
> community of developers/contributors.

> That said, there are many projects depending on sofia-sip, so I hope
> that there will be enough interest to keep the project alive and
> possibly make it better, switching to a less obscure SCCS may help.

Well, yes, we are currently trying to switch over to git. The git
repository is available at

http://gitorious.org/sofia-sip

The master branch currently contains the more or less the same commits
as the darcs repository at sofia-sip.org. It would be useful to
mention also that on the sf.net.

The next features (and bug fixes) mostly involve DNS resolving and
transport handling. There seems to be some nasty bugs in transport
handling that might be hard to fix unless some backwards-incompatible
changes are made. At the same time it would me nice to get
multiprocessing support and perhaps complete the hooks for a SigComp
library.

-- 
Pekka.Pessi mail at nokia.com

--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] [PATCH] Fix configuration under MinGW

[Pekka Pessi]

2010/7/6 Stefano Sabatini :
> this patch fixes the configuration problem as reported here:
> http://thread.gmane.org/gmane.comp.telephony.sofia-sip.devel/3853

Thanks for the patch.

>-CFLAGS="$CFLAGS -I\$(top_srcdir)/win32/pthread -DWINVER=0x0501 \
>+CFLAGS="$CFLAGS -I${srcdir}/win32/pthread -DWINVER=0x0501 \

Can you actually compile sofia-sip with this? It seems to me that the
relative srcdir does dot work when make descends deeper into source
tree.

--Pekka

-- 
Pekka.Pessi mail at nokia.com

--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] [PATCH] Fix gai_strerror re-declaration in MinGW

[Pekka Pessi]

2010/7/6 Stefano Sabatini :
> Hi, as in subject.
>
> The patch requires to run autoheader to re-generate the config.h.in
> file.

Thanks for patch. I wonder if it is enough just to #undef
gai_strerror? No need to check its declaration?

-- 
Pekka.Pessi mail at nokia.com

--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Still no answer to DNS problems

[Pekka Pessi]

2010/7/2 Inca Rose :
> I dont know if this only happen to me or I'm not using a configuration flag
> that is document, but I have a very hard time figuring this out.
...
> The problem is that the next REGISTER goes again to 1.2.3.4.
> There is no mechanism that nta can remember that 1.2.3.4 is not answering
> and put it at the bottom of the list and continue to use 1.2.3.5, the
> last one that did respond ?
> In other words, how to force the stack to use from now 1.2.3.5 and not
> 1.2.3.4 ???

We would need blacklisting/graylisting for the 1.2.3.4. The current
code implements graylisting for SRV records (by manipulating their
priority, if I recall correctly). However, there is no priority
associated with A records, so we would need a different solution.
Perhaps a list (or binary tree or hash table or ...) of bad IP
addresses/ports/protocols?

-- 
Pekka.Pessi mail at nokia.com

--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
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: initializing SIP stack failed

[Pekka Pessi]

2010/6/30 Stefano Sabatini :
> Hi all, I'm running this simple code in Windows Vista:
> nta: master transport created
> tport(00F27958) to */*:*/sip
> tport(00F27958): calling tport_listen for udp
> tport(00F27958): new primary tport 00F28128
> tport(00F27958): bind(pf=2 udp/[192.168.0.1]): No such file or directory
> nta: bind(*:*;transport=*): No such file or directory
> nua: initializing SIP stack failed


> Can you suggest what the problem may be?

For some reason binding a socket to IP address 192.168.0.1 fails.
Where the address comes from? Does you Vista box try to share internet
connection?

If you can compile and run localinfo command, see what it prints?

You can also modify

NUTAG_URL("sip:stef...@*:*")

so it explicitly mentions the IP address, e.g.,

NUTAG_URL("sip:stef...@*:*;maddr=10.2.3.4")

-- 
Pekka.Pessi mail at nokia.com

--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] [PATCH] Fix gai_strerror re-declaration in MinGW

[Pekka Pessi]

2010/7/8 Stefano Sabatini :
> Exactly, this way the patch is much simpler.

Thanks! Applied.

-- 
Pekka.Pessi mail at nokia.com

--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Multiple Registration support

[Pekka Pessi]

Hi,

2010/7/12 Nauman Sulaiman 
>
> Then i tried with 2 different accounts, one Sipgate the other Callcentric. I 
> created 2 separate register handles and separate call back handlers for each 
> handle. I call nua_register twice with the separate handles now.

It should work fine, there is probably something else hosed in your code..

>
> What i noticed is the REGISTER messages go out to the 2 different providers 
> and i get a 401 back from each one, but my callback handlers are not getting 
> called, its like the stack is not passing these on.
> I also noticed that the REGISTER messages to the 2 differnet providers are 
> getting sent with the same CSEQ number!!! So i assume the stack is getting 
> completely confused with the responses. I assumed that sending nua_register 
> with separate handles would allow each REGISTER transaction to be treated 
> separately and the responses would be routed to the separate handlers.

The CSeq number is generated based on the current time. Two REGISTERs
may have same CSeq as long as their Call-ID header (and tags in From
and To headers) are different.

>
> Can someone give me a high level description how to set up what i want to, as 
> mentioned i have a single account working fine.

It should work just fine, but you can try to enable more detailed
debugging logging with NUA_DEBUG=9 and NTA_DEBUG=9 environment
variable.

--
Pekka.Pessi mail at nokia.com

--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Does soa module support “Del ayed Offer” ?

[Pekka Pessi]

2010/7/21 edson.gomes.leme :
> Hi Pekka Pessi;
>
> a) Does the Sofia-SIP soa module support “Delayed Offer” ?

Yes..

> b) How can this call scenario be implemented with the soa module?
>
>     SOFIA-SIP (soa)
>      A (UAC) B (UAS)
>     |   |
>     |<--  INVITE  --|
>     |   |
>     |---  100 Trying  ->|
>     |---  180 Ringing  >|
>     |   |
>     |---  200 (offer)  >|
>     |<--  ACK (answer)  |
>     |   |

You need nothing special (but the usual remote sdp tags in
nua_i_invite are missing).

> c) How can this call scenario be implemented with the soa module?
>
>        SOFIA-SIP (soa)
>             A (UAC)                         B (UAS)
>                |                               |
>                |--  INVITE  -->|
>                |                               |
>                |<---  100 Trying  -|
>                |<---  180 Ringing  |
>                |                               |
>                |<---  200 (offer)  |
>                |--  ACK (answer)  >|
>                |                               |

Currently, this requires a kludge, you have to include an empty
payload (I think SIPTAG_PAYLOAD_STR("") is ok) in nua_invite().

--Pekka

-- 
Pekka.Pessi mail at nokia.com
--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] adding rinstance to NOTIFY request line in nua

[Pekka Pessi]

2010/7/22 Markus Bucher :
>> Is the notify for a existing subscribe/notify session or is it for a
>> "blind notify"?
>
> It's actually for both, though blind notifies have priority.
> The scenario is, that there is a security server between my application an
> the receiver of the notify (client).
> This server adds the rinstance to the contact-header of a register. I save
> this rinstance-tag and have to add it to the request line of all requests to
> the client (that are initiated by my application).
> If a packet is not in a dialog and does not have the rinstance tag, the
> packet will be droped by the server.
>
> I'm nor really able to try it, so I don't really know if subscribe/notify
> sessions are concerned, but blind notifies are definitely concerned.

NUTAG_URL() should work for blind NOTIFYs but not with the SUBSCRIBEd
NOTIFYs. The latter take the URL from the Contact (or Record-Route)
header. However, they are part of an existing dialog, so your security
servers should let them through. (You may need to respond to SUBSCRIBE
before sending NOTIFY, however.)

-- 
Pekka.Pessi mail at nokia.com

--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
___
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 authentication request problem

[Pekka Pessi]

2010/7/24 Mayur Mahajan :
>  I have made a shorter version of my mail.
>   When I send a request to the server through my NTA client, I get the
> response of the message(407 Unauthorized) in the callback. So, when the
> callback function gets the 407 message it invokes authorize_ua() method. The
> problem is I am not able to send the request which authorizes me.  Could you
> please help me in the following things :-

The 407 Unauthorized is sent by a proxy (as opposed to the 401
Unauthorized which is sent by UAS). The 407 carries Proxy-Authenticate
header (instead of WWW-Authenticate in 401) and the subsequent retry
should contain Proxy-Authorization header.

> nta_leg_destroy(context->c_leg), context->c_leg = NULL;
>
>   if (context->c_leg)

This is an another problem...

-- 
Pekka.Pessi mail at nokia.com

--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Null Callid and To Tag

[Pekka Pessi]

2010/7/26 Vikas Bhat :
> Sofia stack is not able to detect empty/null CallID in INVITE request.
> similarly Sofia is not able to detect empty/NULL TO TAG.
> Ideally Sofia should reject the calls in above scenerios.

I think NTA is supposed to return a 400 response to a request received
from network if CallID header is missing.

On client side, it generates a CallID automatically, if application
has not provided one. Likewise, it generates a random To tag if
application has not provided one.

The To tag is always empty or missing in initial requests; do you
propose that a Sofia should automatically try to clear any call if a
response to an INVITE request contains empty/null To tag?

-- 
Pekka.Pessi mail at nokia.com

--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel