[OpenSER-Devel] [ openser-Bugs-1834421 ] openserctl does not work
Bugs item #1834421, was opened at 2007-11-19 11:03 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=743020aid=1834421group_id=139143 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: tools Group: ver devel Status: Open Resolution: None Priority: 5 Private: No Submitted By: Bogdan-Andrei Iancu (bogdan_iancu) Assigned to: Nobody/Anonymous (nobody) Summary: openserctl does not work Initial Comment: On behalf of Juha: a while back, i tried to make openserctl work in trunk: http://www.nabble.com/openserctl-ping-p12307302.html my conclusion was that bask does not allow newlines in arguments and some other strategy needs to be used. ping may still be broken (i don't remember seeing any fix committed), but would be nice to get working before 1.3 is released. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=743020aid=1834421group_id=139143 ___ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSER-Devel] openserctl ping may still be broken
Hi Juha, i submitted in your behalf a bug on the tracker. Regards, Bogdan Juha Heinanen wrote: a while back, i tried to make openserctl work in trunk: http://www.nabble.com/openserctl-ping-p12307302.html my conclusion was that bask does not allow newlines in arguments and some other strategy needs to be used. ping may still be broken (i don't remember seeing any fix committed), but would be nice to get working before 1.3 is released. i can't use the tracker, because sf responses too slow from my part of the world. a better replacement for the tracker would be highly appreciated. -- juha ___ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel ___ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSER-Devel] SF.net SVN: openser: [3132] trunk
Hi Juha, actually the DB table definition was not change - there was a bug in the newly added db schema for generating the DB definitions. Regards, Bogdan Juha Heinanen wrote: Bogdan-Andrei Iancu writes: - fixed DB schema: 1) domain column may be NULL in location and aliases tables (if use_domain=0) 2) prefix column may be NULL in lcr table Closes bug report: 1829179 in my opinion, each time when there is a change in a database table definition, the version number of the table should be upgraded. if this is not done, it is impossible to write a database upgrade script that checks if database tables are up to date and if not makes the necessary changes. -- juha ___ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSER-Devel] SF.net SVN: openser: [3048] trunk/tcp_main.c
Hi Juha, I will give it a try - thanks for the hint! Regards, Bogdan Juha Heinanen wrote: Bogdan-Andrei Iancu writes: I'm not able to reproduce this...could you get the full debug (from start to shutdown) and send it to me? bogdan, i noticed that the error message only appears when i stop openser when there is a sip ua registered to the proxy using tcp transport. to reproduce, try the following: start openser, register a sip ua (i used kphone) using tcp, stop openser. -- juha i noticed that when i stop openser, i get this kind of error message to console: Nov 8 13:00:24 rautu /usr/sbin/openser[31903]: core:io_watch_del: invalid fd 25, not in [0, 0) ___ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
[OpenSER-Devel] SF.net SVN: openser: [3167] trunk/mi
Revision: 3167 http://openser.svn.sourceforge.net/openser/?rev=3167view=rev Author: bogdan_iancu Date: 2007-11-19 02:36:08 -0800 (Mon, 19 Nov 2007) Log Message: --- - to avoid buffer overflow or garbage printing due bogus statis lens, a new macro is added to auto-compute the len of the static string at compile time (no penalty at runtime). Pontential problem reported by Dan Pascu. Modified Paths: -- trunk/mi/mi_core.c trunk/mi/tree.h This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
[OpenSER-Devel] SF.net SVN: openser: [3168] trunk/modules/permissions/mi.c
Revision: 3168 http://openser.svn.sourceforge.net/openser/?rev=3168view=rev Author: bogdan_iancu Date: 2007-11-19 02:37:12 -0800 (Mon, 19 Nov 2007) Log Message: --- - use the newly added macro for setting the lens of the static MI strings. Modified Paths: -- trunk/modules/permissions/mi.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSER-Devel] SF.net SVN: openser: [3163] trunk/modules/permissions/mi.c
On Monday 19 November 2007, Bogdan-Andrei Iancu wrote: Hi Dan, makes sense what you are saying - actually there are a lot of places where the return codes of the MI commands needs to be change (there are mixture between the return code of the MI command and the retune code of the command itself - like if I a look after an non-existing AOR, the MI command is successful and it should return 200 OK but the command itself should return 404 NF ). I think it is a bit too late for this changes now, but it is a must for the next release (1.4). Maybe so for the other commands, but this specific return code that I'm speaking of was just introduced because it core dumped in a specific situation, so I see no problem in fixing this specific case. -- Dan ___ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSER-Devel] SF.net SVN: openser: [3163] trunk/modules/permissions/mi.c
Right - please have it changed. Regards, Bogdan Dan Pascu wrote: On Monday 19 November 2007, Bogdan-Andrei Iancu wrote: Hi Dan, makes sense what you are saying - actually there are a lot of places where the return codes of the MI commands needs to be change (there are mixture between the return code of the MI command and the retune code of the command itself - like if I a look after an non-existing AOR, the MI command is successful and it should return 200 OK but the command itself should return 404 NF ). I think it is a bit too late for this changes now, but it is a must for the next release (1.4). Maybe so for the other commands, but this specific return code that I'm speaking of was just introduced because it core dumped in a specific situation, so I see no problem in fixing this specific case. ___ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
[OpenSER-Devel] [ openser-Feature Requests-1833733 ] server_header should add Server: by itself
Feature Requests item #1833733, was opened at 2007-11-17 20:29 Message generated for change (Comment added) made by bogdan_iancu You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=743023aid=1833733group_id=139143 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: core Group: ver devel Status: Open Resolution: None Priority: 5 Private: No Submitted By: Iñaki Baz (ibc_sf) Assigned to: Nobody/Anonymous (nobody) Summary: server_header should add Server: by itself Initial Comment: As it's explained in: http://openser.org/dokuwiki/doku.php/core-cookbook:devel#server_header To set the Server header is needed: server_header=Server: My Company SIP Proxy If not and it's set as: server_header=My Company SIP Proxy then it will be a wrong line: My Company SIP Proxy Since Server is a RFC 3261 header the word Server: should be added automatically by this server_header parameter. -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2007-11-19 12:52 Message: Logged In: YES user_id=1275325 Originator: NO not a bug, but rather an enhancement. Anyhow, it is too late for changing the meaning of a parameter right now. regards, bogdan -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=743023aid=1833733group_id=139143 ___ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSER-Devel] openserctl ping may still be broken
it is slow, but workable for me... regards, PS: I do parallel tasks :P Dan Pascu wrote: On Monday 19 November 2007, Bogdan-Andrei Iancu wrote: Hi Juha, i submitted in your behalf a bug on the tracker. At times, the sf tracker is dead slow for me as well. ___ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSER-Devel] SF.net SVN: openser: [3156 ] trunk/modules/permissions/mi.c
On Monday 19 November 2007, Bogdan-Andrei Iancu wrote: Hi, To solve this potential problem without any change in the MI interface and without no runtime penalties (strlen), I just added a small macro MI_SSTR (MI Static String) to compute the len of a static string at compile time. With it, instead of having: add_mi_node_child( rpl, 0, Server, 6,.. you can do: add_mi_node_child( rpl, 0, MI_SSTR(Server),. As a POC, I did the changes on the MI core functions and the permission module. I think this is a short term solution to avoid issues, but I do not see it as an ideal solution. The main issue with it is that it hides the interface and makes a 3 argument function look like a 2 argument one in the code. I still believe that after 1.3 we should make that function receive a char* only and compute the length internally because a str doesn't help here and the macro computes strlen(_s) so there will be no runtime penalty anyway. -- Dan ___ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSER-Devel] SF.net SVN: openser: [3163] trunk/modules/permissions/mi.c
On Monday 19 November 2007, Bogdan-Andrei Iancu wrote: Right - please have it changed. Have it changed to what exactly? 200 OK or some other 2xx Reload not necessary? Regards, Bogdan Dan Pascu wrote: On Monday 19 November 2007, Bogdan-Andrei Iancu wrote: Hi Dan, makes sense what you are saying - actually there are a lot of places where the return codes of the MI commands needs to be change (there are mixture between the return code of the MI command and the retune code of the command itself - like if I a look after an non-existing AOR, the MI command is successful and it should return 200 OK but the command itself should return 404 NF ). I think it is a bit too late for this changes now, but it is a must for the next release (1.4). Maybe so for the other commands, but this specific return code that I'm speaking of was just introduced because it core dumped in a specific situation, so I see no problem in fixing this specific case. -- Dan ___ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
[OpenSER-Devel] [ openser-Bugs-1682036 ] Check return codes everywhere
Bugs item #1682036, was opened at 2007-03-16 13:55 Message generated for change (Comment added) made by bogdan_iancu You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=743020aid=1682036group_id=139143 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: core Group: ver devel Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Markus Elfring (elfring) Assigned to: Bogdan-Andrei Iancu (bogdan_iancu) Summary: Check return codes everywhere Initial Comment: Some checks for return codes are missing. Examples: Would you like to add more error handling for return values from fprintf like in the function daemonize and from close in the function init_unixsock_children? http://openser.svn.sourceforge.net/viewvc/openser/trunk/daemonize.c?revision=1782view=markup http://openser.svn.sourceforge.net/viewvc/openser/trunk/unixsock_server.c?revision=1782view=markup How do you think about to improve your software quality with exception handling? http://dietmar-kuehl.de/mirror/c++-faq/exceptions.html#faq-17.1 http://cexcept.sourceforge.net/ -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2007-11-19 13:21 Message: Logged In: YES user_id=1275325 Originator: NO Hi Markus, Chacking is goog, but is not necessary in all the cases. If to check the return code of a function depends on the code context. There are case where you are not really intersted (as further processing) in the return code. I suggest to have a more particular aproach, rather than a a global one I made the fixes you suggested - if you find others, please report them by opening on the tracker. Thanks and regards, Bogdan -- Comment By: Markus Elfring (elfring) Date: 2007-03-16 14:18 Message: Logged In: YES user_id=572001 Originator: YES Would you like to detect every error situation as early as possible? -- Comment By: Henning Westerholt (henningw) Date: 2007-03-16 14:14 Message: Logged In: YES user_id=337916 Originator: NO Better error handling is allways good, but i don't think we would gain much if you implement it for the function you mentioned. Exception are good (if you use e.g. C++), and i miss them honestly. But for C this is another case. The project you mentioned is IMHO really unmaintained, the last update was in 2000.. And i don't know any other well known C project that uses such a mechanism. I think it is better to ask such general questions at the devel mailinglist. Henning -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=743020aid=1682036group_id=139143 ___ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSER-Devel] SF.net SVN: openser: [3156] trunk/modules/permissions/mi.c
Dan Pascu wrote: On Monday 19 November 2007, Bogdan-Andrei Iancu wrote: Hi, To solve this potential problem without any change in the MI interface and without no runtime penalties (strlen), I just added a small macro MI_SSTR (MI Static String) to compute the len of a static string at compile time. With it, instead of having: add_mi_node_child( rpl, 0, Server, 6,.. you can do: add_mi_node_child( rpl, 0, MI_SSTR(Server),. As a POC, I did the changes on the MI core functions and the permission module. I think this is a short term solution to avoid issues, but I do not see it as an ideal solution. The main issue with it is that it hides the interface and makes a 3 argument function look like a 2 argument one in the code. That is true, but I do not find it a major issue. I still believe that after 1.3 we should make that function receive a char* only and compute the length internally because a str doesn't help here I most of the case, the MI functions gets as info from either static strings (with known len), either str* values (again with known len). I see no logic to recalculate the len even if 70% you already know it. To be honest, I'm not in favour of easy coding and nice interfaces, but with no performance concerns. and the macro computes strlen(_s) so there will be no runtime penalty anyway. The macro uses sizeof() which is replaced at compile time with the size of the string. No strlen is done. Regards, Bogdan ___ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSER-Devel] SF.net SVN: openser: [3163] trunk/modules/permissions/mi.c
On Monday 19 November 2007, Bogdan-Andrei Iancu wrote: Good question :)...Maybe 202 Accepted ?? That's why I asked the question, to see what other people think of this. -- Dan ___ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
[OpenSER-Devel] SF.net SVN: openser: [3170] trunk/modules/carrierroute
Revision: 3170 http://openser.svn.sourceforge.net/openser/?rev=3170view=rev Author: henningw Date: 2007-11-19 06:15:17 -0800 (Mon, 19 Nov 2007) Log Message: --- - add missing documentation about cr_prime_balance_by_from function Modified Paths: -- trunk/modules/carrierroute/README trunk/modules/carrierroute/doc/carrierroute_user.sgml This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSER-Devel] SF.net SVN: openser: [3132] trunk
Bogdan-Andrei Iancu writes: actually the DB table definition was not change - there was a bug in the newly added db schema for generating the DB definitions. bogdan, i remember checking svn diffs of one .sql file and saw that some column now allowed NULL value which was now allowed in previous version. -- juha ___ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSER-Devel] SF.net SVN: openser: [3132] trunk
Juha, in 1.2 that columns were accepting NULL values (in the mysql_openser script), but when creating the DB schema, by mistake, the columns were set as NOT NULL. The error was when a new way of creating the DB table was implemented - a translation error. From openser point of view nothing changed. regards, bogdan Juha Heinanen wrote: Bogdan-Andrei Iancu writes: actually the DB table definition was not change - there was a bug in the newly added db schema for generating the DB definitions. bogdan, i remember checking svn diffs of one .sql file and saw that some column now allowed NULL value which was now allowed in previous version. -- juha ___ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
[OpenSER-Devel] SF.net SVN: openser: [3172] trunk/main.c
Revision: 3172 http://openser.svn.sourceforge.net/openser/?rev=3172view=rev Author: bogdan_iancu Date: 2007-11-19 10:00:25 -0800 (Mon, 19 Nov 2007) Log Message: --- - fixed destroy sequence - if script check is done, do not make a general clenup as none of the services to be cleaned are even initialized. Closes 1827363. Modified Paths: -- trunk/main.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
[OpenSER-Devel] [ openser-Bugs-1827363 ] configuration check deletes fifo and socket files
Bugs item #1827363, was opened at 2007-11-07 09:36 Message generated for change (Comment added) made by dan_pascu You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=743020aid=1827363group_id=139143 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: ver devel Status: Open Resolution: Fixed Priority: 7 Private: No Submitted By: Dan (dan_pascu) Assigned to: Bogdan-Andrei Iancu (bogdan_iancu) Summary: configuration check deletes fifo and socket files Initial Comment: I got these error messages while running openser -c to check the configuration: Nov 2 19:29:44 [10055] ERROR:mi_datagram:mi_destroy: cannot delete the socket (/var/run/openser/socket): Permission denied Nov 2 19:29:44 [10055] ERROR:mi_fifo:mi_destroy: cannot delete the fifo (/var/run/openser/fifo): Permission denied As it seems, trying to check the configuration will attempt to remove the fifo and socket files. Fortunately I didn't have enough privileges to remove those files as the user I was when checking the config, but I recall that I noticed repeatedly that my fifo and socket files were gone and couldn't explain why. Trying to remove them while just checking for the configuration is wrong. I may have a server already running and I only want to make sure the new config is OK before I attempt to restart it. We even have this check in the debian init.d file before restarts to make sure we won't restart unless the config is valid. But with this behavior, the running server will be crippled by any attempt to simply check the configuration. Those files shouldn't be removed, even on a normal start, unless openser is sure it is not already running. Else it will error that it cannot bind to the SIP socket and fail to start, but will cripple at the same time an already running server. -- Comment By: Dan (dan_pascu) Date: 2007-11-19 23:17 Message: Logged In: YES user_id=1296758 Originator: YES Seems to be working fine now. -- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2007-11-19 20:01 Message: Logged In: YES user_id=1275325 Originator: NO Dan, can you give it a try with the current SVN version? Bogdan -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=743020aid=1827363group_id=139143 ___ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
[OpenSER-Devel] openser messages
I've noticed that openser is very chatty lately. I see these lines on the console when I run openser -c: Nov 19 22:12:19 [8885] NOTICE:core:main: initialize the pseudo random generator from /dev/urandom Nov 19 22:12:19 [8885] INFO:core:pv_parse_hdr_name: using hdr type (21) instead of Event IMO, they should be at debug level. They do not offer any information about a possible error as they're just informational. Even more the information they offer is related to the inner depths of openser itself and is nothing that is useful to be seen everytime openser starts. Maybe for a developer who wishes to trace what the program is doing and if it behaves as expected they may be of use. -- Dan ___ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
[OpenSER-Devel] [ openser-Bugs-1834860 ] parse_rr_body doesn't delimit route_set properly
Bugs item #1834860, was opened at 2007-11-19 16:43
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=743020aid=1834860group_id=139143
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: core
Group: ver devel
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: reticent (unspin)
Assigned to: Nobody/Anonymous (nobody)
Summary: parse_rr_body doesn't delimit route_set properly
Initial Comment:
When parsing the route set in reverse order the print_rr_body incorrectly
counts the number of elements in the route set leading to a route set value in
the dialog (and maybe others?) structure that is missing a delimiter
Below is an example of the bug:
Example sip message headers:
Record-Route:
sip:65.39.180.33:15061;r2=on;lr;ftag=725f9dde1c6dbbb2o1;nid=UX0.v9G.Wu3.
Record-Route:
sip:65.39.180.33:15061;transport=tcp;r2=on;lr;ftag=725f9dde1c6dbbb2o1;nid=UX0.v9G.Wu3.
Record-Route:
sip:207.232.98.31:15061;transport=tcp;r2=on;lr;ftag=725f9dde1c6dbbb2o1;bid=bPP.x3v.E7g.
Record-Route:
sip:207.232.98.31:15061;r2=on;lr;ftag=725f9dde1c6dbbb2o1;bid=bPP.x3v.E7g.
After print_rr_body, parsed in reverse order, and skipping 1 entry.
sip:207.232.98.31:15061;transport=tcp;r2=on;lr;ftag=16ed1c322255e7feo1;bid=bPP.x3v.E7g,
sip:65.39.180.33:15061;transport=tcp;r2=on;lr;ftag=16ed1c322255e7feo1;nid=UX0.v9G.Wu3
sip:65.39.180.33:15061;r2=on;lr;ftag=16ed1c322255e7feo1;nid=UX0.v9G.Wu3
Notice between the last two RRs there is no delimiter (,)
Below is a patch that should fix this issue, file: parse_rr.c.patch:
--- trunk/parse_rr.c2007-11-19 21:43:13.0 +
+++ fixed/parse_rr.c2007-11-19 21:52:55.0 +
@@ -429,7 +429,7 @@ int print_rr_body(struct hdr_field *irou
{
memcpy(cp, route[i].s, route[i].len);
cp += route[i].len;
- if (--i0)
+ if (--i=0)
*(cp++) = ',';
}
}
Found by:
Tavis Paquette ([EMAIL PROTECTED])
Peter Baer ([EMAIL PROTECTED])
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=743020aid=1834860group_id=139143
___
Devel mailing list
Devel@lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/devel
[OpenSER-Devel] openser messages
Dan Pascu writes: I've noticed that openser is very chatty lately. this reminds me about memory debug that is now on by default in trunk. if one is not interested in memory debugging, it is hard to find the relevant degug lines among the memory ones. would it be possible to make memory debug messages appear at a higher debug level than other debug messages? -- juha ___ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
[OpenSER-Devel] [ openser-Bugs-1834870 ] dialog route_set contains invalid information
Bugs item #1834870, was opened at 2007-11-19 17:14
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=743020aid=1834870group_id=139143
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: core
Group: ver devel
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: reticent (unspin)
Assigned to: Nobody/Anonymous (nobody)
Summary: dialog route_set contains invalid information
Initial Comment:
When changing the transmission protocol from UDP to TCP and using
Record-Routing the resultant route_set in the dialog structure ('route_set' in
the dialog or 'caller_route_set' and 'callee_route_set' in the database when
using DB dialog persistence) contains a local URI (pointing to the local server)
This seems to be related to a lack of logic in dealing with double record-route
situations (like that which occurs when changing the sip transmission protocol)
Here is the 200 OK from which the callee_route_set will be created
SIP/2.0 200 OK.
To: sip:[EMAIL PROTECTED]:15061;tag=4368efa7801ad038i0.
From: NA sip:[EMAIL PROTECTED]:15061;tag=e97ea43d566bae1bo1.
Call-ID: [EMAIL PROTECTED]
CSeq: 102 INVITE.
Via: SIP/2.0/TCP 207.232.98.31:15061;rport=44195;branch=z9hG4bKb344.260ffd61.0.
Via: SIP/2.0/UDP
192.168.99.19:5070;rport=9006;received=207.232.98.114;branch=z9hG4bK-ded28820.
Record-Route:
sip:65.39.180.33:15061;r2=on;lr;ftag=e97ea43d566bae1bo1;nid=UX0.v9G.Wu3.
Record-Route:
sip:65.39.180.33:15061;transport=tcp;r2=on;lr;ftag=e97ea43d566bae1bo1;nid=UX0.v9G.Wu3.
Record-Route:
sip:207.232.98.31:15061;transport=tcp;r2=on;lr;ftag=e97ea43d566bae1bo1;bid=bPP.x3v.E7g.
Record-Route:
sip:207.232.98.31:15061;r2=on;lr;ftag=e97ea43d566bae1bo1;bid=bPP.x3v.E7g.
Contact: unspin sip:[EMAIL PROTECTED]:1024.
Server: Linksys/SPA962-5.1.7.
Content-Length: 213.
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER.
Supported: replaces.
Content-Type: application/sdp.
However when we look at callee_route_set the value in the database we see that
there is an element that references the local system which shouldn't be there
207.232.98.31:15061 is the local SIP proxy
Database callee_route_set value:
sip:207.232.98.31:15061;transport=tcp;r2=on;lr;ftag=16ed1c322255e7feo1;bid=bPP.x3v.E7g,sip:65.39.180.33:15061;transport=tcp;r2=on;lr;ftag=16ed1c322255e7feo1;nid=UX0.v9G.Wu3,sip:65.39.180.33:15061;r2=on;lr;ftag=16ed1c322255e7feo1;nid=UX0.v9G.Wu3
Expected callee_route_set value:
sip:65.39.180.33:15061;transport=tcp;r2=on;lr;ftag=16ed1c322255e7feo1;nid=UX0.v9G.Wu3,sip:65.39.180.33:15061;r2=on;lr;ftag=16ed1c322255e7feo1;nid=UX0.v9G.Wu3
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=743020aid=1834870group_id=139143
___
Devel mailing list
Devel@lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/devel
