Hey,
On 09.03.2011 07:10, 侯旭光 wrote:
> well, all my config files are in the attachment.
There are no attachments in your email (at least not for me).
Cheers,
--Timo
> 在 2011年3月8日 下午7:57,Timo Reimann <timo.reimann(a)1und1.de> 写道:
>> Hey,
>>
>>
>> On 08.03.2011 12:37, 侯旭光 wrote:
>>> I modified the source code and took the solutions in cfg file that
>>> you guys suggested and no error exist.
>>>
>>> But my problem isn't totally solved.
>>>
>>> Actually when I use the dispatcher module and set the profile , in
>>> case the "invite" request forwarded by ds_select_domain function ,
>>> then the dialog terminated.
>>> dlg_list and get_profile_size get nothing.
>>>
>>> In detail:
>>>
>>> there're two proxys : server #1 192.168.1.12 and server #2 192.168.1.13
>>>
>>> two users: 1012 register on 192.168.1.12 and 2013 register on
> 192.168.1.13
>>>
>>> when user 1012 dial 2013, server 1# use the dispatcher module,
>>> forward the request to server #2 and set the profile.server #2 get
>>> the invite request and set the profile too, then call user 2013,Dialog
>>> Establish.
>>>
>>> At this time,server #2 has the dialog info,but server #1 doesn't.
>>>
>>> How can I trace the dialog info at both server #1 and server #2 ?
>>
>> Unless the dispatcher module terminates the dialog in a B2BUA fashion
>> (which I think it doesn't but I am not familiar with the module), calls
>> routed in the setup you described should be listed via dlg_list through
>> the course of dialog lifetime.
>>
>> Are you 100% sure you are tracking dialogs on proxy #1? (I think
>> set_dlg_profile() fails silently if the dialog isn't being tracked.)
>> Maybe you want to provide the relevant configuration snippet of the
>> proxy so we can double-check.
>>
>>
>> Cheers,
>>
>> --Timo
Hi,
short question:
I think i remember something about the fact, that there was a way to
define multiple parameters, e.g.
modparam("module", "var_name", "a")
modparam("module", "var_name", "b")
modparam("module", "var_name", "c")
=> Parameter "var_name" has the values "a", "b" and "c"
Does anyone remember, if i am correct and, if yes, can anyone give me
a pointer, where such construct was used (or where a "howto" is)?
Thanks,
Carsten
--
Carsten Bock
http://www.ng-voice.com
mailto:carsten@ng-voice.com
Hello all,
i'm clearing up my patch queue and have some patches ready for merge. Unless i
receive any comments or objections, i'll merge them to master by the end of
the week.
They're in branch alexh/master now.
--
Greetings,
Alex Hermann
Hey,
On 08.03.2011 12:37, 侯旭光 wrote:
> I modified the source code and took the solutions in cfg file that
> you guys suggested and no error exist.
>
> But my problem isn't totally solved.
>
> Actually when I use the dispatcher module and set the profile , in
> case the "invite" request forwarded by ds_select_domain function ,
> then the dialog terminated.
> dlg_list and get_profile_size get nothing.
>
> In detail:
>
> there're two proxys : server #1 192.168.1.12 and server #2 192.168.1.13
>
> two users: 1012 register on 192.168.1.12 and 2013 register on 192.168.1.13
>
> when user 1012 dial 2013, server 1# use the dispatcher module,
> forward the request to server #2 and set the profile.server #2 get
> the invite request and set the profile too, then call user 2013,Dialog
> Establish.
>
> At this time,server #2 has the dialog info,but server #1 doesn't.
>
> How can I trace the dialog info at both server #1 and server #2 ?
Unless the dispatcher module terminates the dialog in a B2BUA fashion
(which I think it doesn't but I am not familiar with the module), calls
routed in the setup you described should be listed via dlg_list through
the course of dialog lifetime.
Are you 100% sure you are tracking dialogs on proxy #1? (I think
set_dlg_profile() fails silently if the dialog isn't being tracked.)
Maybe you want to provide the relevant configuration snippet of the
proxy so we can double-check.
Cheers,
--Timo
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has a new comment added:
FS#117 - t_check_trans is not allowed in onreply_route
User who did this - Alex Hermann (axlh)
----------
Sorry, i was trying both as t_check_trans gave an error. But the same probably applies to t_lookup_request.
I noticed the fix you committed, even though that works (and matches my patch :)), it is a bit different from the 1.5 implementation. There this additional code is present to set the branch value:
trans = get_t();
if ((trans == 0) || (trans == T_UNDEFINED))
return -1;
msg->branch_index = branch+1;
return 1;
Isn't that necessary anymore in 3.1?
----------
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=117#comment168
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task is now closed:
FS#103 - $snd(name) pvar contains local instead of remote socket info
User who did this - Daniel-Constantin Mierla (miconda)
Reason for closing: Implemented
Additional comments about closing: In the repository branches.
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=103
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has a new comment added:
FS#117 - t_check_trans is not allowed in onreply_route
User who did this - Daniel-Constantin Mierla (miconda)
----------
You use t_lookup_request() in the config and mention t_check_trans() in the message. Which one you are looking for?
For t_check_trans() I updated the exports flag, it was enabled only for tm module specific onreply route.
----------
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=117#comment167
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.