Re: [SR-Users] Kamailio auth_radius: duplicate User-Name attribute

2011-03-04 Thread Kosilov Fedor 
Again for testing, I pointed Kamailio directly to my billing radius,
bypassing Freeradius. The situation is the same, so the problem is
definitely not with the Freeradius server.

2011/3/5 Kosilov Fedor 

> Hello, Daniel, thank you for your attention to my problem.
>
> I actually don't need accounting support, I just want to implement an
> authorization using radius.
> But for testing purposes, I loaded the acc module and set "radius_extra"
> param. Nothing has changed.
>
> Here is a part of my config:
>
>
> ...
> modparam("acc", "radius_config", "/etc/radiusclient-ng/radiusclient.conf")
> modparam("acc", "radius_extra", "User-Name=$Au")
> ...
> modparam("auth_radius", "radius_config",
> "/etc/radiusclient-ng/radiusclient.conf")
> modparam("auth_radius", "auth_extra",  "NAS-Identifier=$var(ident)")
> ...
> route {
> #Definitions
> $var(ident) = "kamserv.example.com";
> ...
> route(3); #Auth
> ...
> }
>
> ...
>
> route[3] {
> if (is_method("REGISTER"))
> {
> if (is_from_local()) {
> if (!radius_www_authorize("$td"))
> {
> www_challenge("$sel(to.uri.host)", "1");
> exit;
> } else {
>
> avp_db_delete("$sel(to.uri)","$avp(s:ip)");
>
> avp_db_delete("$sel(to.uri)","$avp(s:dpid)");
>
> avp_db_delete("$sel(to.uri)","$avp(s:fr_timer)");
>
> avp_db_delete("$sel(to.uri)","$avp(s:calls_limit)");
>
> avp_db_store("$sel(to.uri)","$avp(s:ip)");
>
> avp_db_store("$sel(to.uri)","$avp(s:dpid)");
>
> avp_db_store("$sel(to.uri)","$avp(s:fr_timer)");
>
> avp_db_store("$sel(to.uri)","$avp(s:calls_limit)");
>
>if
> ($au!=$sel(to.uri.user))||($au!=$sel(from.uri.user)) {
> sl_send_reply("403","Forbidden auth
> ID");
> exit;
> } else {
> if ($avp(s:ip)!='any' &&
> $sel(src.ip)!=$avp(s:ip)) {
>
> sl_send_reply("403","Forbidden");
> exit;
> }
> }
> }
>
> } else {
> sl_send_reply("403","Forbidden");
> exit;
> }
> } else {
> if ($sel(src.ip)=="192.168.0.2") {
> return;
> } else if (is_from_local()) {
> if
> (!radius_proxy_authorize("$sel(from.uri.host)","$sel(from.uri.user)")) {
> proxy_challenge("$sel(from.uri.host)",
> "1");
> exit;
> }
> if ($avp(s:ip)!='any' && $sel(src.ip)!=$avp(s:ip))
> {
>  sl_send_reply("403","Forbidden");
> exit;
> }
>
> if (is_method("PUBLISH"))
> {
> if ($au!=$sel(to.uri.user)) {
> sl_send_reply("403","Forbidden auth
> ID");
> exit;
> }
> } else if ($au!=$sel(from.uri.user)) {
> sl_send_reply("403","Forbidden auth ID");
> exit;
> }
> consume_credentials();
> } else {
> sl_send_reply("403","Forbidden");
> exit;
> }
> }
> }
> ...
>
> And again a part of the freeradius log:
>
> rad_recv: Access-Request packet from host 127.0.0.1 port 58933, id=135,
> length=298
>
> *User-Name = "2219...@example.com"*
> Digest-Attributes = 0x0a0932323139303031
> Digest-Attributes = 0x01106c696e6b2d726567696f6e2e7275
> Digest-Attributes =
> 0x0222545848676630317833314f7076767759512b6b73674c63554d51784f6c347634
>
> Digest-Attributes = 0x04147369703a6c696e6b2d726567696f6e2e7275
> Digest-Attributes = 0x030a5245474953544552
> Digest-Attributes = 0x050661757468
> Digest-Attributes = 0x090a3030303030303031
> Digest-Attributes = 0x080c39636238383130616531
> Digest-Response = "efdcf92b58f694b97928856614057436"
>
> Service-Type = Sip-Session
> Sip-Uri-User = "2219001"
> *User-Name = "call-id=zomdnicqsndxrnh@koffe-work"*
>
> NAS-Identifier = "kamserv.example.com"
> NAS-Port = 5060
> NAS-IP-Address = 127.0.0.1
>
>
> Regards,
> Fedor.
>
>
>
> 2011/3/5 Daniel-Constantin Mierla 
>
>  Hello,
>>
>> what is the value of parameter radius_extra for acc module?
>>
>> Cheers,
>> Daniel
>>
>>
>> On 3/4/11 1:06 PM, Kosilov Fedor wrote:
>>
>> Hello List!
>>
>> I'm trying to set up authorization with our

Re: [SR-Users] Kamailio auth_radius: duplicate User-Name attribute

2011-03-04 Thread Kosilov Fedor 
Hello, Daniel, thank you for your attention to my problem.

I actually don't need accounting support, I just want to implement an
authorization using radius.
But for testing purposes, I loaded the acc module and set "radius_extra"
param. Nothing has changed.

Here is a part of my config:


...
modparam("acc", "radius_config", "/etc/radiusclient-ng/radiusclient.conf")
modparam("acc", "radius_extra", "User-Name=$Au")
...
modparam("auth_radius", "radius_config",
"/etc/radiusclient-ng/radiusclient.conf")
modparam("auth_radius", "auth_extra",  "NAS-Identifier=$var(ident)")
...
route {
#Definitions
$var(ident) = "kamserv.example.com";
...
route(3); #Auth
...
}

...

route[3] {
if (is_method("REGISTER"))
{
if (is_from_local()) {
if (!radius_www_authorize("$td"))
{
www_challenge("$sel(to.uri.host)", "1");
exit;
} else {

avp_db_delete("$sel(to.uri)","$avp(s:ip)");

avp_db_delete("$sel(to.uri)","$avp(s:dpid)");

avp_db_delete("$sel(to.uri)","$avp(s:fr_timer)");

avp_db_delete("$sel(to.uri)","$avp(s:calls_limit)");

avp_db_store("$sel(to.uri)","$avp(s:ip)");

avp_db_store("$sel(to.uri)","$avp(s:dpid)");

avp_db_store("$sel(to.uri)","$avp(s:fr_timer)");

avp_db_store("$sel(to.uri)","$avp(s:calls_limit)");

   if
($au!=$sel(to.uri.user))||($au!=$sel(from.uri.user)) {
sl_send_reply("403","Forbidden auth
ID");
exit;
} else {
if ($avp(s:ip)!='any' &&
$sel(src.ip)!=$avp(s:ip)) {

sl_send_reply("403","Forbidden");
exit;
}
}
}

} else {
sl_send_reply("403","Forbidden");
exit;
}
} else {
if ($sel(src.ip)=="192.168.0.2") {
return;
} else if (is_from_local()) {
if
(!radius_proxy_authorize("$sel(from.uri.host)","$sel(from.uri.user)")) {
proxy_challenge("$sel(from.uri.host)", "1");

exit;
}
if ($avp(s:ip)!='any' && $sel(src.ip)!=$avp(s:ip)) {
 sl_send_reply("403","Forbidden");
exit;
}

if (is_method("PUBLISH"))
{
if ($au!=$sel(to.uri.user)) {
sl_send_reply("403","Forbidden auth
ID");
exit;
}
} else if ($au!=$sel(from.uri.user)) {
sl_send_reply("403","Forbidden auth ID");
exit;
}
consume_credentials();
} else {
sl_send_reply("403","Forbidden");
exit;
}
}
}
...

And again a part of the freeradius log:

rad_recv: Access-Request packet from host 127.0.0.1 port 58933, id=135,
length=298
*User-Name = "2219...@example.com"*
Digest-Attributes = 0x0a0932323139303031
Digest-Attributes = 0x01106c696e6b2d726567696f6e2e7275
Digest-Attributes =
0x0222545848676630317833314f7076767759512b6b73674c63554d51784f6c347634
Digest-Attributes = 0x04147369703a6c696e6b2d726567696f6e2e7275
Digest-Attributes = 0x030a5245474953544552
Digest-Attributes = 0x050661757468
Digest-Attributes = 0x090a3030303030303031
Digest-Attributes = 0x080c39636238383130616531
Digest-Response = "efdcf92b58f694b97928856614057436"
Service-Type = Sip-Session
Sip-Uri-User = "2219001"
*User-Name = "call-id=zomdnicqsndxrnh@koffe-work"*
NAS-Identifier = "kamserv.example.com"
NAS-Port = 5060
NAS-IP-Address = 127.0.0.1


Regards,
Fedor.



2011/3/5 Daniel-Constantin Mierla 

>  Hello,
>
> what is the value of parameter radius_extra for acc module?
>
> Cheers,
> Daniel
>
>
> On 3/4/11 1:06 PM, Kosilov Fedor wrote:
>
> Hello List!
>
> I'm trying to set up authorization with our billing proprietary radius
> server, using Freeradius as a proxy. Currently I'm experiencing the
> following problem:
>
> The Access-Request packet, sent by Kamailio, contains two User-Name
> attribute records
> Here is a log from the Freeradius server:
>
> rad_recv: Access-Request packet from host 127.0.0.1 port 59294, id=112,
> length=298
> User-Name = "2219...@example.com"
> Digest-Attributes = 0x0a0932323139303031
> Digest-Attributes = 0x01106c696e6b2d726

[SR-Users] Newly acquired SIP fails authorization from softphone

2011-03-04 Thread Larry Baumbach 
I am a newbie to the world of VIOP.  I am attempting to set up an ATA with SIP.

 I created a SIP at account iptel.com and received an email
confirmation stating "We are reserving the following SIP address for
you: sip:larry.baumb...@iptel.org".

I tried to testing this address in Xlite but got messages saying:
"Account failed to enable.  Account Iptel could not be enabled.
Verify your user ID, password and authorization name.

When I set up the SIP account in Xlite I used:
UserID: larry.baumb...@iptel.org  ( I also tried
"larry.baumbach"  & "sip:larry.baumb...@iptel.org")
Domain: sip.iptel.org
Password: my password
Authorization name:  (I left blank as I did not receive any)

I can log into SERweb with the same UserID and Password and access my account.

What am I doing wrong?  Or is there some kind of wait time before my
SIP address is activated?
I have spent too much time trying to get this to work on my own.

Thanks very much for any help you can provide.



-- 
Larry Baumbach
920.358.8695
larry.baumb...@gmail.com

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] stats in kamailio

2011-03-04 Thread Daniel-Constantin Mierla 



On 2/27/11 5:27 AM, Juha Heinanen wrote:

Henning Westerholt writes:


"kamctl fifo get_statistics all" will show you all available statistics,
for a more simpler view try "kamctl moni". The closest thing you'll
find regards to the load are inuse transaction, or concurrent dialogs.

tmx:inuse_transactions would be more useful if it would contain an
average over some time (1-5 minutes or something like the routers have)
rather than an instantaneous value.  but last time when i looked, it was
difficult to implement in k any kind of stat with average value.
perhaps that has now changed with sip router?
What I used, even in older versions, is to combine statistics with 
rtimer and htable. The statistics were just simple counters, holding 
integer value, incremented/decremented as wanted.


There are some stats that just increment, practically counting different 
events.


Here is what I do if I want to get like "load" stats - i.e., number of 
events in a specific period of time. For example number of 2xx 
transactions per minute:


Load htable module and define a htable, say stats.

In event_route[htable:mod-init] I set $sht(stats=>2xx_transactions) = 0;

Load rtimer module to execute a route block every minute. In that route 
block, do this kind of logic:


$var(stats) = $stat(2xx_transactions);
$var(diff) = $var(stats) - $sht(stats=>2xx_transactions);
$sht(stats=>2xx_transactions) = $var(stats);

- insert in db the value of $var(diff) along with the timestamp so you 
have the number of transactions answered with 2xx during the last 
minute. Then configure siremis to make a graph out of the db records


You can have another rtimer route executed not that often that can 
delete records older than 1-2 days, so you don't fill up the database.


Cheers,
Daniel

tmx:2xx_transactions


--
Daniel-Constantin Mierla
http://www.asipto.com

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Calls are killed during kamailio restart

2011-03-04 Thread Daniel-Constantin Mierla 

Hello,

On 2/28/11 10:52 AM, Henning Westerholt wrote:

On Thursday 24 February 2011, Efelin Novak wrote:

I'd like to ask whether my situation is normal. During kamailio restart
calls are dropped from mediaproxy. Those two programs are connected using
kamailio.sock. Why RTP strem is dropped when SIP proxy is restarted? I
would expect just undelivered BYE or something.

Hi Efelin,

i'm not an expert with mediaproxy, but does the kamailio hold some state that
mediaproxy need to proper route the RTP packets? This would explain the
behaviour that you observe, as this would probably lost during a restart.
even if it needs details from SIP signaling, then it is a bug IMO that 
media proxy kills the calls. Kamailio recovers the states of active 
calls upon restart when dialog module is loaded, nothing is lost.


I never used media proxy, but restarts of kamailio when using rtpproxy 
to relay the rtp does not impact at all the ongoing calls.


Cheers,
Daniel

--
Daniel-Constantin Mierla
http://www.asipto.com


___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] problem unreferencing dialog in dialog module

2011-03-04 Thread Daniel-Constantin Mierla 

Hello,

On 3/3/11 10:19 AM, Anton Roman wrote:

Hello,

thanks for your quick reply, my answer is inline.

2011/3/2 Daniel-Constantin Mierla >


Hello,

looks like related to the callbacks for dialog module. Are you
loading other modules that require dialog module?

we are using some features of dialog module such as ending dialogs 
after a timeout period, and we are using engage_mediaproxy() function, 
as well. It's an old configuration we had to put in production with no 
 time enough to test. Do you recommend not to use dialog module if not 
strictly required?


usage of dialog module was always safe and working great for me. But I 
use it mostly alone, never with mediaproxy module, just with 
pua_dialoginfo module in some cases. From the logs, the crash was 
related to the callback system exported by dialog module for the other 
modules willing to hook into dialog, it is why I asked about the other 
modules to be sure there is at list one binding to dialog.


So, like with other modules, if there is a problem discovered there, it 
is important that we fix it - this is a module used a lot by many. 
Therefore usage is encouraged when needed :-)


Cheers,
Daniel

--
Daniel-Constantin Mierla
http://www.asipto.com

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] problem unreferencing dialog in dialog module

2011-03-04 Thread Daniel-Constantin Mierla 

Hello,

just committed a safety check for this case. If anyone can give it some 
tests, then we can backport.


I will analyze to see why it got in such case, but anyhow it is better 
and safer to detect bogus dereferences to dialogs and not crash.


Thanks,
Daniel

On 3/3/11 11:34 AM, Timo Reimann wrote:

Argh:


On 03.03.2011 11:11, Timo Reimann wrote:

What I can tell though is that the crash happens because too much dialog
reference counter decrementing takes place. Although I have no clue why,

^

...the crash happens,


I believe the implementation of unref_dlg_unsafe() (a macro) could be
somewhat more robust by not unlinking and destroying a dialog when the
counter drops below zero. That is, instead of running the following block

if ((_dlg)->ref<=0) { \
 unlink_unsafe_dlg( _d_entry, _dlg);\
 LM_DBG("ref<=0 for dialog %p\n",_dlg);\
 destroy_dlg(_dlg);\
}\



for _dlg->ref<= 0, I see no reason to change the compare operator to ==.

I see no reason *not* to change compare operator to ==. That is, I want
the block to execute iff the reference counter is found to be zero.


--Timo

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


--
Daniel-Constantin Mierla
http://www.asipto.com


___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Kamailio auth_radius: duplicate User-Name attribute

2011-03-04 Thread Daniel-Constantin Mierla 

Hello,

what is the value of parameter radius_extra for acc module?

Cheers,
Daniel

On 3/4/11 1:06 PM, Kosilov Fedor wrote:

Hello List!

I'm trying to set up authorization with our billing proprietary radius 
server, using Freeradius as a proxy. Currently I'm experiencing the 
following problem:


The Access-Request packet, sent by Kamailio, contains two User-Name 
attribute records

Here is a log from the Freeradius server:

rad_recv: Access-Request packet from host 127.0.0.1 port 59294, 
id=112, length=298

User-Name = "2219...@example.com "
Digest-Attributes = 0x0a0932323139303031
Digest-Attributes = 0x01106c696e6b2d726567696f6e2e7275
Digest-Attributes = 
0x022254584452634531773045524b7368796f30684a70544f4f6a69424d386b32534a

Digest-Attributes = 0x04147369703a6c696e6b2d726567696f6e2e7275
Digest-Attributes = 0x030a5245474953544552
Digest-Attributes = 0x050661757468
Digest-Attributes = 0x090a3030303030303031
Digest-Attributes = 0x080c32383034636535373032
Digest-Response = "e79b47955c02401fe52d05f7956609aa"
Service-Type = Sip-Session
Sip-Uri-User = "2219001"
*User-Name = "call-id=domcmqmnychbwlp@koffe-work"*
NAS-Identifier = "kamserv.example.com "
NAS-Port = 5060
NAS-IP-Address = 127.0.0.1
# Executing section authorize from file 
/etc/freeradius/sites-enabled/default

+- entering group authorize {...}
++[preprocess] returns ok
++[chap] returns noop
++[mschap] returns noop
[digest] Checking for correctly formatted Digest-Attributes
[digest] Digest-Attributes look OK.  Converting them to something more 
usful.

Digest-User-Name = "2219001"
Digest-Realm = "example.com "
Digest-Nonce = "TXDRcE1w0ERKshyo0hJpTOOjiBM8k2SJ"
Digest-URI = "sip:example.com "
Digest-Method = "REGISTER"
Digest-QOP = "auth"
Digest-Nonce-Count = "0001"
Digest-CNonce = "2804ce5702"
[digest] Adding Auth-Type = DIGEST
++[digest] returns ok
[suffix] Looking up realm "example.com " for 
User-Name = "2219...@example.com "

[suffix] Found realm "example.com "
[suffix] Adding Realm = "example.com "
[suffix] Proxying request from user 2219001 to realm example.com 

[suffix] Preparing to proxy authentication request to realm 
"example.com "

++[suffix] returns updated
[eap] No EAP-Message, not doing EAP
++[eap] returns noop
++[files] returns noop
++[expiration] returns noop
++[logintime] returns noop
++[pap] returns noop
Sending Access-Request of id 250 to 127.0.0.1 port 1822
User-Name = "2219...@example.com "
Digest-Attributes = 0x0a0932323139303031
Digest-Attributes = 0x01106c696e6b2d726567696f6e2e7275
Digest-Attributes = 
0x022254584452634531773045524b7368796f30684a70544f4f6a69424d386b32534a

Digest-Attributes = 0x04147369703a6c696e6b2d726567696f6e2e7275
Digest-Attributes = 0x030a5245474953544552
Digest-Attributes = 0x050661757468
Digest-Attributes = 0x090a3030303030303031
Digest-Attributes = 0x080c32383034636535373032
Digest-Response = "e79b47955c02401fe52d05f7956609aa"
Service-Type = Sip-Session
Sip-Uri-User = "2219001"
*User-Name = "call-id=domcmqmnychbwlp@koffe-work"*
NAS-Identifier = "kamserv.example.com "
NAS-Port = 5060
NAS-IP-Address = 127.0.0.1
Proxy-State = 0x313132
Proxying request 1 to home server 127.0.0.1 port 1822

As I understand, this second User-Name attribute has to be a call-id 
attribute.











___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


--
Daniel-Constantin Mierla
http://www.asipto.com

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] WARNING: [db_id.c:281]: identical DB URLs, but different DB connection pid [30123/30107]

2011-03-04 Thread Daniel-Constantin Mierla 



On 3/4/11 8:59 PM, Juha Heinanen wrote:

Klaus Darilion writes:


So, when it is fixed, why printing a WARNING? Is it something I have to
  be aware of? I use mysql with 3 modules doing DB lookups. I get this
warning 3 times.

Since ever usually most modules use the same db_url. So I am confused.

If there isn't a problem anymore we should change the WARNING to an
DBG.

i agree with klaus.  if a module does not use db correctly, it needs to
be fixed.  otherwise, please change log level to debug.
I will change that. The warning is fully harmless, but I let it for a 
while just to be sure is all fine. The update done could have caused 
kamailio not to start if some module would do some extra internal checks 
over the existence of db connection -- the warning would give a clear 
indication about what could be the issue in such case.


Cheers,
Daniel

--
Daniel-Constantin Mierla
http://www.asipto.com


___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] WARNING: [db_id.c:281]: identical DB URLs, but different DB connection pid [30123/30107]

2011-03-04 Thread Juha Heinanen 
Klaus Darilion writes:

> So, when it is fixed, why printing a WARNING? Is it something I have to
>  be aware of? I use mysql with 3 modules doing DB lookups. I get this
> warning 3 times.
> 
> Since ever usually most modules use the same db_url. So I am confused.
> 
> If there isn't a problem anymore we should change the WARNING to an
> DBG.

i agree with klaus.  if a module does not use db correctly, it needs to
be fixed.  otherwise, please change log level to debug.

-- juha

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] re-SUBSCRIBE and Record-Route

2011-03-04 Thread Henning Westerholt 
On Friday 04 March 2011, Klaus Darilion wrote:
> Am 04.03.2011 16:07, schrieb marius zbihlei:
> >> What do you think?
> > 
> > Replying to myself..
> > 
> > Of course, this is almost the same as your idea, the question would this
> > suffice, of a param to loose_route will be needed to enable/disable this
> > behavior ?!
> 
> I think so.

Hello,

i like the discussed way without the additional parameter more, if it not 
interfere with possible other implementations which also maybe works the same 
way.

Cheers

Henning

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] re-SUBSCRIBE and Record-Route

2011-03-04 Thread Klaus Darilion 


Am 04.03.2011 16:07, schrieb marius zbihlei:
>> What do you think?
>>
> Replying to myself..
> 
> Of course, this is almost the same as your idea, the question would this
> suffice, of a param to loose_route will be needed to enable/disable this
> behavior ?!

I think so.

klaus

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] WARNING: [db_id.c:281]: identical DB URLs, but different DB connection pid [30123/30107]

2011-03-04 Thread Robert Verspuy 

Op 04-03-11 16:05, Klaus Darilion schreef:

Hi Robert!


See the thread here:
http://lists.sip-router.org/pipermail/sr-dev/2010-October/009545.html

So, when it is fixed, why printing a WARNING? Is it something I have to
  be aware of? I use mysql with 3 modules doing DB lookups. I get this
warning 3 times.

Since ever usually most modules use the same db_url. So I am confused.

If there isn't a problem anymore we should change the WARNING to an DBG.

You really have to ask that to Daniel-Constantin Mierla.
See his answer on my patch on 
http://lists.sip-router.org/pipermail/sr-dev/2010-November/009866.html


So I guess the warning means the module is doing some kind of incorrect 
DB initialization ??
I don't know what the correct way is, I'm not a openser / kamailio 
developer.
I just started using Kamailio in september 2010, found an issue, and 
made a patch.


With kind regards,
Robert Verspuy

regards
Klaus



--
*Exa-Omicron*
Patroonsweg 10
3892 DB Zeewolde
Tel.: 088-OMICRON (66 427 66)
http://www.exa-omicron.nl
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] re-SUBSCRIBE and Record-Route

2011-03-04 Thread marius zbihlei 

On 03/04/2011 05:05 PM, marius zbihlei wrote:

On 03/04/2011 04:56 PM, Klaus Darilion wrote:
   

Not so easy .

16.4 Route Information Preprocessing


 The proxy MUST inspect the Request-URI of the request.  If the
 Request-URI of the request contains a value this proxy previously
 placed into a Record-Route header field (see Section 16.6 item 4),
 the proxy MUST replace the Request-URI in the request with the last
 value from the Route header field, and remove that value from the
 Route header field.  The proxy MUST then proceed as if it received
 this modified request.

This will only happen when the element sending the request to the
proxy (which may have been an endpoint) is a strict router.  This
rewrite on receive is necessary to enable backwards compatibility
with those elements.  It also allows elements following this
specification to preserve the Request-URI through strict-routing
proxies (see Section 12.2.1.1).


Thus, Kamailio should somehow detect if the URI is inserted by himself
or not. This may only happen if the previous hop is a strict-router. As
Kamailio is a loose-router and always adds the ;lr parameter, the check
could be extended to check if the RURI also cotains lr parameter. If the
lr parameter is not present, this means for sure that the RURI was not
generated by Kamailio.


 

Hello,

I was thinking of maybe adding a new configurable RR param. A strict
router would copy this header into the RURI. But a.t.m. loose_route does
not perform any checking on tags. Maybe an exclude_uri_tag module param
that can work like this:

modparam("rr", "exclude_uri_tag", "mark=on");

Then, when the initial SUBSCRIBE (dialog setting message) comes

add_rr_param(";mark=on");

In the loose_route processing, if exclude_uri_tag is set and  !(RURI =~
exclude_uri_tag), then perform loose routing on that request (the
request isn't coming from a strict router)

What do you think?
   

Replying to myself..

Of course, this is almost the same as your idea, the question would this 
suffice, of a param to loose_route will be needed to enable/disable this 
behavior ?!


Marius



Marius
   

Of course this would require code changes.

A dirty hack would be to manipulate the Route headers manually and set $du.


regards
Klaus



Am 04.03.2011 15:25, schrieb marius zbihlei:

 

Hello list,

An UAC sends a resubscribe in the form

SUBSCRIBE sip:al...@example.com SIP/2.0
Route:
Route:


The request has a to tag, from tag... Basic resubscribe(R-URI is the
same as original SUBSCRIBE) The proxy that handles it is a Kamailio (1.5
but this refers to 3.1 as well). The problem is that loose_route()
treats this request as coming from a strict routing router, not from the
UAC, so it applies the strict-to-loose rules and rewrites the request as:

SUBSCRIBE sip:sip.next-hop.example.com;lr=on SIP/2.0
Route:


The segment that handles this is pretty standard:

if (loose_route()) {
  # sequential request withing a dialog should take the path
  # determined by record-routing
  if(has_totag()) {
  forward();
  exit;
}

It sees that message has Route set, it finds the to tag (so the routes
were not a preset), and then , the important thing, sees that the domain
from the RURI matches itself (kamailio has aliases configured for
example.com), thus considering the request as coming from a strict
router. Then it takes the bottom Route header and overwrites the RURI.

What is the best way to ensure that loose routing is applied to the
resubscribe as described above?

Cheers,
Marius

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

   


 


___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

   



___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] re-SUBSCRIBE and Record-Route

2011-03-04 Thread marius zbihlei 

On 03/04/2011 04:56 PM, Klaus Darilion wrote:

Not so easy .

16.4 Route Information Preprocessing


The proxy MUST inspect the Request-URI of the request.  If the
Request-URI of the request contains a value this proxy previously
placed into a Record-Route header field (see Section 16.6 item 4),
the proxy MUST replace the Request-URI in the request with the last
value from the Route header field, and remove that value from the
Route header field.  The proxy MUST then proceed as if it received
this modified request.

   This will only happen when the element sending the request to the
   proxy (which may have been an endpoint) is a strict router.  This
   rewrite on receive is necessary to enable backwards compatibility
   with those elements.  It also allows elements following this
   specification to preserve the Request-URI through strict-routing
   proxies (see Section 12.2.1.1).


Thus, Kamailio should somehow detect if the URI is inserted by himself
or not. This may only happen if the previous hop is a strict-router. As
Kamailio is a loose-router and always adds the ;lr parameter, the check
could be extended to check if the RURI also cotains lr parameter. If the
lr parameter is not present, this means for sure that the RURI was not
generated by Kamailio.

   


Hello,

I was thinking of maybe adding a new configurable RR param. A strict 
router would copy this header into the RURI. But a.t.m. loose_route does 
not perform any checking on tags. Maybe an exclude_uri_tag module param 
that can work like this:


modparam("rr", "exclude_uri_tag", "mark=on");

Then, when the initial SUBSCRIBE (dialog setting message) comes

add_rr_param(";mark=on");

In the loose_route processing, if exclude_uri_tag is set and  !(RURI =~ 
exclude_uri_tag), then perform loose routing on that request (the 
request isn't coming from a strict router)


What do you think?

Marius

Of course this would require code changes.

A dirty hack would be to manipulate the Route headers manually and set $du.


regards
Klaus



Am 04.03.2011 15:25, schrieb marius zbihlei:
   

Hello list,

An UAC sends a resubscribe in the form

SUBSCRIBE sip:al...@example.com SIP/2.0
Route:
Route:


The request has a to tag, from tag... Basic resubscribe(R-URI is the
same as original SUBSCRIBE) The proxy that handles it is a Kamailio (1.5
but this refers to 3.1 as well). The problem is that loose_route()
treats this request as coming from a strict routing router, not from the
UAC, so it applies the strict-to-loose rules and rewrites the request as:

SUBSCRIBE sip:sip.next-hop.example.com;lr=on SIP/2.0
Route:


The segment that handles this is pretty standard:

if (loose_route()) {
 # sequential request withing a dialog should take the path
 # determined by record-routing
 if(has_totag()) {
 forward();
 exit;
}

It sees that message has Route set, it finds the to tag (so the routes
were not a preset), and then , the important thing, sees that the domain
from the RURI matches itself (kamailio has aliases configured for
example.com), thus considering the request as coming from a strict
router. Then it takes the bottom Route header and overwrites the RURI.

What is the best way to ensure that loose routing is applied to the
resubscribe as described above?

Cheers,
Marius

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
 
   



___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] WARNING: [db_id.c:281]: identical DB URLs, but different DB connection pid [30123/30107]

2011-03-04 Thread Klaus Darilion 
Hi Robert!

Am 04.03.2011 15:49, schrieb Robert Verspuy:
> Op 04-03-11 15:43, Henning Westerholt schreef:
>> On Friday 04 March 2011, Henning Westerholt wrote:
>>> By searching for Robert you should be able to find the initial
>>> discussion
>>> of this problem, i guess.
>> [sr-dev] invalid type (3) or nul (0) version columns for trusted
>> (kamailio 3.1
>> latest from git)
>>
> See the thread here:
> http://lists.sip-router.org/pipermail/sr-dev/2010-October/009545.html

So, when it is fixed, why printing a WARNING? Is it something I have to
 be aware of? I use mysql with 3 modules doing DB lookups. I get this
warning 3 times.

Since ever usually most modules use the same db_url. So I am confused.

If there isn't a problem anymore we should change the WARNING to an DBG.

regards
Klaus

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] re-SUBSCRIBE and Record-Route

2011-03-04 Thread Klaus Darilion 
Not so easy .

16.4 Route Information Preprocessing


   The proxy MUST inspect the Request-URI of the request.  If the
   Request-URI of the request contains a value this proxy previously
   placed into a Record-Route header field (see Section 16.6 item 4),
   the proxy MUST replace the Request-URI in the request with the last
   value from the Route header field, and remove that value from the
   Route header field.  The proxy MUST then proceed as if it received
   this modified request.

  This will only happen when the element sending the request to the
  proxy (which may have been an endpoint) is a strict router.  This
  rewrite on receive is necessary to enable backwards compatibility
  with those elements.  It also allows elements following this
  specification to preserve the Request-URI through strict-routing
  proxies (see Section 12.2.1.1).


Thus, Kamailio should somehow detect if the URI is inserted by himself
or not. This may only happen if the previous hop is a strict-router. As
Kamailio is a loose-router and always adds the ;lr parameter, the check
could be extended to check if the RURI also cotains lr parameter. If the
lr parameter is not present, this means for sure that the RURI was not
generated by Kamailio.

Of course this would require code changes.

A dirty hack would be to manipulate the Route headers manually and set $du.


regards
Klaus



Am 04.03.2011 15:25, schrieb marius zbihlei:
> Hello list,
> 
> An UAC sends a resubscribe in the form
> 
> SUBSCRIBE sip:al...@example.com SIP/2.0
> Route: 
> Route:
> 
> 
> The request has a to tag, from tag... Basic resubscribe(R-URI is the
> same as original SUBSCRIBE) The proxy that handles it is a Kamailio (1.5
> but this refers to 3.1 as well). The problem is that loose_route()
> treats this request as coming from a strict routing router, not from the
> UAC, so it applies the strict-to-loose rules and rewrites the request as:
> 
> SUBSCRIBE sip:sip.next-hop.example.com;lr=on SIP/2.0
> Route: 
> 
> 
> The segment that handles this is pretty standard:
> 
> if (loose_route()) {
> # sequential request withing a dialog should take the path
> # determined by record-routing
> if(has_totag()) {
> forward();
> exit;
> }
> 
> It sees that message has Route set, it finds the to tag (so the routes
> were not a preset), and then , the important thing, sees that the domain
> from the RURI matches itself (kamailio has aliases configured for
> example.com), thus considering the request as coming from a strict
> router. Then it takes the bottom Route header and overwrites the RURI.
> 
> What is the best way to ensure that loose routing is applied to the
> resubscribe as described above?
> 
> Cheers,
> Marius
> 
> ___
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users@lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] WARNING: [db_id.c:281]: identical DB URLs, but different DB connection pid [30123/30107]

2011-03-04 Thread Robert Verspuy 

Op 04-03-11 15:43, Henning Westerholt schreef:

On Friday 04 March 2011, Henning Westerholt wrote:

By searching for Robert you should be able to find the initial discussion
of this problem, i guess.

[sr-dev] invalid type (3) or nul (0) version columns for trusted (kamailio 3.1
latest from git)


See the thread here:
http://lists.sip-router.org/pipermail/sr-dev/2010-October/009545.html

With kind regards,
Robert Verspuy

--
*Exa-Omicron*
Patroonsweg 10
3892 DB Zeewolde
Tel.: 088-OMICRON (66 427 66)
http://www.exa-omicron.nl
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] WARNING: [db_id.c:281]: identical DB URLs, but different DB connection pid [30123/30107]

2011-03-04 Thread Henning Westerholt 
On Friday 04 March 2011, Henning Westerholt wrote:
> By searching for Robert you should be able to find the initial discussion
> of this problem, i guess.

[sr-dev] invalid type (3) or nul (0) version columns for trusted (kamailio 3.1 
latest from git)

This was it.

Henning

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] WARNING: [db_id.c:281]: identical DB URLs, but different DB connection pid [30123/30107]

2011-03-04 Thread Henning Westerholt 
On Friday 04 March 2011, Klaus Darilion wrote:
> Any idea what does it mean? Where does it come from? Do I have to change
> my config? How?
> 
> WARNING:  [db_id.c:281]: identical DB URLs, but different DB
> connection pid [30123/30107]

Hi Klaus,

its related to this change:

commit f138cce2c0968872f26538983e06a128a1b41344
Author: Daniel-Constantin Mierla 
Date:   Wed Dec 1 23:30:34 2010 +0100

srdb1: keep PID per DB connection

- print warning when PID mismatches - it is cross-process shared DB
  connection
- initial patch by Robert Verspuy

By searching for Robert you should be able to find the initial discussion of 
this problem, i guess.

Cheers,

Henning

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] WARNING: [db_id.c:281]: identical DB URLs, but different DB connection pid [30123/30107]

2011-03-04 Thread Klaus Darilion 
Any idea what does it mean? Where does it come from? Do I have to change
my config? How?

WARNING:  [db_id.c:281]: identical DB URLs, but different DB
connection pid [30123/30107]


Thanks
Klaus

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] re-SUBSCRIBE and Record-Route

2011-03-04 Thread marius zbihlei 

Hello list,

An UAC sends a resubscribe in the form

SUBSCRIBE sip:al...@example.com SIP/2.0
Route: 
Route:


The request has a to tag, from tag... Basic resubscribe(R-URI is the 
same as original SUBSCRIBE) The proxy that handles it is a Kamailio (1.5 
but this refers to 3.1 as well). The problem is that loose_route() 
treats this request as coming from a strict routing router, not from the 
UAC, so it applies the strict-to-loose rules and rewrites the request as:


SUBSCRIBE sip:sip.next-hop.example.com;lr=on SIP/2.0
Route: 


The segment that handles this is pretty standard:

if (loose_route()) {
# sequential request withing a dialog should take the path
# determined by record-routing
if(has_totag()) {
forward();
exit;
}

It sees that message has Route set, it finds the to tag (so the routes 
were not a preset), and then , the important thing, sees that the domain 
from the RURI matches itself (kamailio has aliases configured for 
example.com), thus considering the request as coming from a strict 
router. Then it takes the bottom Route header and overwrites the RURI.


What is the best way to ensure that loose routing is applied to the 
resubscribe as described above?


Cheers,
Marius

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] Kamailio auth_radius: duplicate User-Name attribute

2011-03-04 Thread Kosilov Fedor 
Hello List!

I'm trying to set up authorization with our billing proprietary radius
server, using Freeradius as a proxy. Currently I'm experiencing the
following problem:

The Access-Request packet, sent by Kamailio, contains two User-Name
attribute records
Here is a log from the Freeradius server:

rad_recv: Access-Request packet from host 127.0.0.1 port 59294, id=112,
length=298
User-Name = "2219...@example.com"
Digest-Attributes = 0x0a0932323139303031
Digest-Attributes = 0x01106c696e6b2d726567696f6e2e7275
Digest-Attributes =
0x022254584452634531773045524b7368796f30684a70544f4f6a69424d386b32534a
Digest-Attributes = 0x04147369703a6c696e6b2d726567696f6e2e7275
Digest-Attributes = 0x030a5245474953544552
Digest-Attributes = 0x050661757468
Digest-Attributes = 0x090a3030303030303031
Digest-Attributes = 0x080c32383034636535373032
Digest-Response = "e79b47955c02401fe52d05f7956609aa"
Service-Type = Sip-Session
Sip-Uri-User = "2219001"
*User-Name = "call-id=domcmqmnychbwlp@koffe-work"*
NAS-Identifier = "kamserv.example.com"
NAS-Port = 5060
NAS-IP-Address = 127.0.0.1
# Executing section authorize from file
/etc/freeradius/sites-enabled/default
+- entering group authorize {...}
++[preprocess] returns ok
++[chap] returns noop
++[mschap] returns noop
[digest] Checking for correctly formatted Digest-Attributes
[digest] Digest-Attributes look OK.  Converting them to something more
usful.
Digest-User-Name = "2219001"
Digest-Realm = "example.com"
Digest-Nonce = "TXDRcE1w0ERKshyo0hJpTOOjiBM8k2SJ"
Digest-URI = "sip:example.com"
Digest-Method = "REGISTER"
Digest-QOP = "auth"
Digest-Nonce-Count = "0001"
Digest-CNonce = "2804ce5702"
[digest] Adding Auth-Type = DIGEST
++[digest] returns ok
[suffix] Looking up realm "example.com" for User-Name = "2219...@example.com
"
[suffix] Found realm "example.com"
[suffix] Adding Realm = "example.com"
[suffix] Proxying request from user 2219001 to realm example.com
[suffix] Preparing to proxy authentication request to realm "example.com"
++[suffix] returns updated
[eap] No EAP-Message, not doing EAP
++[eap] returns noop
++[files] returns noop
++[expiration] returns noop
++[logintime] returns noop
++[pap] returns noop
Sending Access-Request of id 250 to 127.0.0.1 port 1822
User-Name = "2219...@example.com"
Digest-Attributes = 0x0a0932323139303031
Digest-Attributes = 0x01106c696e6b2d726567696f6e2e7275
Digest-Attributes =
0x022254584452634531773045524b7368796f30684a70544f4f6a69424d386b32534a
Digest-Attributes = 0x04147369703a6c696e6b2d726567696f6e2e7275
Digest-Attributes = 0x030a5245474953544552
Digest-Attributes = 0x050661757468
Digest-Attributes = 0x090a3030303030303031
Digest-Attributes = 0x080c32383034636535373032
Digest-Response = "e79b47955c02401fe52d05f7956609aa"
Service-Type = Sip-Session
Sip-Uri-User = "2219001"
*User-Name = "call-id=domcmqmnychbwlp@koffe-work"*
NAS-Identifier = "kamserv.example.com"
NAS-Port = 5060
NAS-IP-Address = 127.0.0.1
Proxy-State = 0x313132
Proxying request 1 to home server 127.0.0.1 port 1822

As I understand, this second User-Name attribute has to be a call-id
attribute.
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] set_dlg_profile() in failure_route

2011-03-04 Thread Timo Reimann 
On 04.03.2011 10:42, Timo Reimann wrote:
> You set flag 2 but showed flag 4 to be modparam'ed to the dialog flag.
> Is that intentional?
> 
> Anyways, since you are doing dlg_manage() in the INVITE transaction, you
> should still be fine. Just for the sake of debugging, can you set flag 4
> in your 'is_method("INVITE")' block and see if it makes a difference? I
> have no in-depth experience with on demand dialog tracking as we use the
> dialog flag exclusively.

I ran a quick test myself: When you use (and set) the dialog flag in the
INVITE transaction, assigning dialogs to profiles works perfectly in
failure routes. However, when you use dlg_manage(), calling
set_dlg_profile() triggers the error you described.

I'll have to dig a little deeper to figure out why profiling
capabilities in the dialog module differ with flag-based and on-demand
tracking. In the meantime, you may opt to employing the dialog flag.


Cheers,

--Timo

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] set_dlg_profile() in failure_route

2011-03-04 Thread 侯旭光 
I did trace the dialog in the initial REQUEST

my script:
...
modparam("dialog","dlg_flag","4")
...
route{

 if (is_method("INVITE")){
   dlg_setflag("2");
   dlg_manage();
   ...
   if(avp_db_load("$ruri/username","$avp(s:busyforward)"))
   {
   setflag(26);
   t_on_failure(FAIL_ONE);
   }
   ...
}
failure_route[FAIL_ONE]{
   ...
   if(isflagset(26)&&t_check_status("486"))
   {
   $ru=$avp(s:busyforward);
   append_branch();
   dlg_setflag("2");
   avp_delete("$avp(s:busyforward)");
   resetflag("26");
   lookup("location");
   route(RELAY);
   }
   ...
}
route[RELAY]{
   if(!t_relay()){
sl_reply_error();
   }
}
#--#

Is anything wrong?

2011/3/3 Timo Reimann :
> Hi,
>
>
> On 03.03.2011 14:47, 侯旭光 wrote:
>> set_dlg_profile() function carshed in failure_route when I need do the
>> call-forwarding.
>>
>> When in busy-call-forward or no-answer-forward mode ,it'll run into
>> the failure_route.But at the time , the route_type of the dialog is
>> FAILURE_ROUTE and the get_current_dialog() return NULL,
>>
>> then the set_dlg_profile() function won't work.
>>
>> How can I set dialog profile in the busy or no-answer call-forwarding ?
>>
>> CRITIAL dialog [dlg_profile.c]:  BUG - dialog not found in non REQUEST route
>> ERROR dialog [dialog.c]  :  failed to set  profile
>
> I think you did not track the dialog in the first place, i.e., when the
> initial request associated to the dialog you seek to profile was processed.
>
> Are you using dlg_flag, and if so, have you enabled it in REQUEST_ROUTE?
> If you want to track dialogs on demand instead, try calling dlg_manage()
> prior to calling set_dlg_profile(). I'm not sure if this is the most
> elegant approach for your use case but it might at least work.
>
>
> Cheers,
>
> --Timo
>

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] set_dlg_profile() in failure_route

2011-03-04 Thread Timo Reimann 
Hey 侯旭光,

please keep SR-Users in CC so others can share in some assistance and
benefit from a solution.


On 04.03.2011 08:29, 侯旭光 wrote:
> I did trace the dialog in the initial REQUEST
> 
> my script:
> ...
> modparam("dialog","dlg_flag","4")
> ...
> route{
> 
>   if (is_method("INVITE")){
> dlg_setflag("2");
> dlg_manage();
> ...
> if(avp_db_load("$ruri/username","$avp(s:busyforward)"))
> {
> setflag(26);
> t_on_failure(FAIL_ONE);
> }
> ...
> }
> failure_route[FAIL_ONE]{
> ...
> if(isflagset(26)&&t_check_status("486"))
> {
> $ru=$avp(s:busyforward);
> append_branch();
> dlg_setflag("2");
> avp_delete("$avp(s:busyforward)");
> resetflag("26");
> lookup("location");
> route(RELAY);
> }
> ...
> }
> route[RELAY]{
> if(!t_relay()){
>  sl_reply_error();
> }
> }
> #--#
> 
> Is anything wrong?

You set flag 2 but showed flag 4 to be modparam'ed to the dialog flag.
Is that intentional?

Anyways, since you are doing dlg_manage() in the INVITE transaction, you
should still be fine. Just for the sake of debugging, can you set flag 4
in your 'is_method("INVITE")' block and see if it makes a difference? I
have no in-depth experience with on demand dialog tracking as we use the
dialog flag exclusively.

By the way, I see no calls to set_dlg_profile() in your route logic. Is
this really an excerpt of the configuration you are having trouble with?


Cheers,

--Timo



> 
> 2011/3/3 Timo Reimann :
>> Hi,
>>
>>
>> On 03.03.2011 14:47, 侯旭光 wrote:
>>> set_dlg_profile() function carshed in failure_route when I need do the
>>> call-forwarding.
>>>
>>> When in busy-call-forward or no-answer-forward mode ,it'll run into
>>> the failure_route.But at the time , the route_type of the dialog is
>>> FAILURE_ROUTE and the get_current_dialog() return NULL,
>>>
>>> then the set_dlg_profile() function won't work.
>>>
>>> How can I set dialog profile in the busy or no-answer call-forwarding ?
>>>
>>> CRITIAL dialog [dlg_profile.c]:  BUG - dialog not found in non
> REQUEST route
>>> ERROR dialog [dialog.c]  :  failed to set  profile
>>
>> I think you did not track the dialog in the first place, i.e., when the
>> initial request associated to the dialog you seek to profile was
> processed.
>>
>> Are you using dlg_flag, and if so, have you enabled it in REQUEST_ROUTE?
>> If you want to track dialogs on demand instead, try calling dlg_manage()
>> prior to calling set_dlg_profile(). I'm not sure if this is the most
>> elegant approach for your use case but it might at least work.
>>
>>
>> Cheers,
>>
>> --Timo

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users