[Serusers] 2 questions regarding user location

[Kyriakos]

Hello and thank you for the reply.

 

The thing is that in register block I use fix_nated_register but when SER is
sending back the 200 OK reply the routeblock for replies uses
fix_nated_contact  (I took this out of the getting started  05a
configuration for NAT handling).

 

 

 

route[2] {

 

  # -----------------------------------------------------------------

  # REGISTER Message Handler

  # ----------------------------------------------------------------

   log (1,"route[2]:Register detected \n");

  sl_send_reply("100", "Trying");

 

  if (!search("^Contact:[ ]*\*") && client_nat_test("7")) { 

     log (1,"route[2]:Caller is nated \n");

    setflag(6);

    fix_nated_register();

    force_rport();

  };

 

  if (!www_authorize("","subscriber")) {

    log (1,"route[2]:Requesting credentials \n");

    www_challenge("","0");

    break;

  };

 

  if (!check_to()) {

    sl_send_reply("401", "Unauthorized");

    break;

  };

 

  consume_credentials();

 

  if (!save("location")) {

    sl_reply_error();

  };

}

 

 

 

onreply_route[1] {

 

  log (1,"onreply route\n");

  if ((isflagset(6) || isflagset(7)) && (status=~"(180)|(183)|2[0-9][0-9]"))
{ 

 

    if (!search("^Content-Length:[ ]*0")) {

      

     log (1,"onreply route:using media proxy\n");

     use_media_proxy();

    };

  };

 

  if (client_nat_test("1")) {

    log (1,"onreply route:fixing nat contact\n");

   fix_nated_contact();

  };

 

 

 

KM

  _____  

From: Greger V. Teigre [mailto:greger at teigre.com] 
Sent: Wednesday, June 28, 2006 12:20 PM
To: Kyriakos
Cc: serusers at lists.iptel.org
Subject: Re: [Serusers] 2 questions regarding user location

 



Kyriakos wrote: 

Hi,

   I have two questions regarding  user location.

 

1) Is there a way of getting the user location info for manipulating it in
ser.cfg ? Something like lookup but without rewriting anything. Basically
what I want to do is check if the caller and the caller are NATed and belong
to a certain same network then I should not use media proxy. The criterion
for the same network would be that both sides are originating from the same
public ip.  Thus I would have to retrieve the "received" field value for the
calee  and compare it with the ip contained in the contact header field of
the caller in the INVITE .    Perhaps there is also another way to do this?

Not that I know of. However, cvs head has a new type of route where you can
access the actual destination ip and port.



 

2) What happens when I have multiple phones registered under one user? How
lookup(location) works when I have more than one ips in location table for
the user? During tests I had a UA  behind NAT  registering to SER with an ip
assigned from the dhcp. After a while I had the UA assigned a different ip
from the dhcp and the Register on SER under the same user name. The problem
was that during registration SER would respond back to the UA for requesting
authorisation credentials but when it was time to send the 200 OK message
for registration , it would send it only to the previous location of the UA
and not the one it sent the REGISTER message from with of course failure to
register because UA would not get the OK from SER. I noticed that in Contact
header of the 200 message there were more than one return ips (the old one
and the new one), Of course as soon as the old location timed out the
registration would go ok.

 

This has nothing to do with how location works. A new REGISTER should not
NOT hit lookup(location), so you have an error in your script. You should
run fix_nated_register() on the message. By default, SER will respond to the
rcvd address and not Contact if they are different.
g-)



 

 

 

Thanks

KM

 

 

 

 





  _____  



 
_______________________________________________
Serusers mailing list
Serusers at lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20060628/c2fad859/attachment.htm>