[Users] Problem with module dispatcher

[Jose Gil Navarrete]

Hi 
  In my server I have:
   
  if (!method=="REGISTER"){
                setflag(1);
                setflag(2);
                record_route();
}

   
   
  Date: Fri, 29 Sep 2006 09:36:49 +0300
From: Daniel-Constantin Mierla <daniel at voice-system.ro>
Subject: Re: [Users] Problem with module dispatcher
To: Jose Gil Navarrete <gijoenav at yahoo.com.mx>
Cc: users at openser.org
Message-ID: <451CBF01.9030508 at voice-system.ro>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Hello,

do you do record routing on server? The ACK should follow Route 
headers.

A network trace (ngrep, ethereal) will help to identify the cause for 
the problem.

Cheers,
Daniel


On 09/29/06 00:29, Jose Gil Navarrete wrote:
> Hi all
>
> I have implemented the load balance in mode statefull, I obtained the 
> next messages:
>
> phone1                 dispatcher               
> sipserver                  phone2
>     --------INVITE-------->    ----INVITE----------->      
> ----INVITE-------->
>     <----100 TRYING----    <---100 TRYING----      <---100 TRYING----
>     <----180 RINGING--    <---180 RINGING---      <---180 RINGING---
>     <----200 OK----------     <----- 200 OK--------      <---200 
> OK--------
>     -------- ACK -------->     --------- ACK -------->    
>
>
> You can see that the sipserver never sends ACK message to 
video_phone2.
> Is this correct?
>
> Then I try the next, in the sipserver:
>  if (method =="ACK"){
>                 if (!t_relay()) {
>                         sl_reply_error();
>                 };
>                 return;
>         }
>
> But the sipserver doesn't send the message ACK at the phone2?
> Does some body know what it's wrong?
>
> 


 		
---------------------------------
  Do You Yahoo!? La mejor conexión a Internet y 2GB extra a tu correo por $100 al mes. http://net.yahoo.com.mx 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20061004/24a3dc0c/attachment.htm>