[OpenSIPS-Devel] [ opensips-Bugs-2075002 ] In-correct VIA header for MHOMED Proxy

[SourceForge.net]

Bugs item #2075002, was opened at 2008-08-26 15:00
Message generated for change (Comment added) made by jimbohamez
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2075002&group_id=232389

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: 1.4.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jim Burke (jimbohamez)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: In-correct VIA header for MHOMED Proxy

Initial Comment:
If a UAC is registered via an external IP address, when using t_relay(ip_address) to force an INVITE message to internal IP address after location_lookup the first Via header is the external IP and not the internal IP address used in the t_relay command.

This results in messages returned from the B2BUA ie 100 "Trying" to be sent to the external IP and not the internal IP address this causes the calls to fail.

OS: Fedora Core 5
version: opensips 1.4.1-tls (i386/linux)
flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, DISABLE_NAGLE, USE_MCAST, SHM_MEM, SHM_MMAP, PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
svnrevision: 2:4624M
@(#) $Id: main.c 4504 2008-07-29 09:55:03Z bogdan_iancu $
main.c compiled on 12:02:51 Aug 26 2008 with gcc 4.1.1
 
If you need some further information please let me know.

Regards,
Jim



----------------------------------------------------------------------

>Comment By: Jim Burke (jimbohamez)
Date: 2008-09-09 23:07

Message:
Hi Bogdan,

Thanks!  Your suggestion resolves the issue.

Regards,
Jim

----------------------------------------------------------------------

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2008-09-09 18:03

Message:
Hi Jim,

As said, the lookup("location") is automatically trying to set as outbound
interface the same interface as the one the REGISTER was received on - in
your case, the external interface. But you send the call via the internal
interface - to route the call to B2BUA.

Try doing a force_send_socket("inernal_interface") before sending the call
to B2BUA.
        http://www.opensips.org/index.php?n=Resources.DocsCoreFcn

Regards,
Bogdan

----------------------------------------------------------------------

Comment By: Jim Burke (jimbohamez)
Date: 2008-09-07 21:09

Message:
Logged In: YES 
user_id=1986627
Originator: YES

Hi Bogdan,

Thanks for your follow-up!

Server Setup:
Duplicated linux servers running opensips bound to external and internal
IP on port 5060 and b2bua bound to internal IP address on port 5070.
REGISTER messages have PATH included and duplicated to second server so NAT
UAC are handled correctly. 

Call scenario:

1, A and B UAC registered via external IP address
2, A calls B, INVITE incoming via external IP address.
3, After checking for local number a lookup location is performed.
4, If user is online we bill the call then force the INVITE via internal
IP to B2BUA to handle call timing.
5, B2BUA routes the call back to Opensips and out via external IP to B.

Regards,
Jim 


----------------------------------------------------------------------

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2008-08-31 00:56

Message:
Logged In: YES 
user_id=1275325
Originator: NO

Hi Jim,

So, your scenario is:
  1) receive call and force the internal ip
  2) do lookup("location") where destination is a device registered with
the external Ip

I'm asking as lookup("location") internally forces the interface to be
used to the one used to receive the REGISTER from the device. So, if the
device registered via external IP, all the calls to it will be delivered
via the external interface.

Maybe a more clear description of your flow will help in understanding the
problem.

Regards,
bogdan


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2075002&group_id=232389