[OpenSIPS-Users] refer scenario - record-route header

Bogdan-Andrei Iancu bogdan at opensips.org
Thu May 9 13:25:58 CEST 2013


Hi Lazlo,

Good the problem was sorted out. May I ask what kind of misconfiguration
lead to a missing IP in RR hdr ? were you doing manual RR via
record_route_preset() ? or ?

Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com


On 05/07/2013 12:08 PM, Laszlo wrote:
> Hi Bogdan,
>
> There was no record_route before firing up b2b, just a logical mistake
> in the config.
>
> It is now sorted out, thanks!
>
>
> -Laszlo
>
>
> 2013/4/30 Bogdan-Andrei Iancu <bogdan at opensips.org
> <mailto:bogdan at opensips.org>>
>
>     The bogus RR belongs to .170 which is the B2B - are you by mistake
>     doing record_route before pushing the call into the b2b ? if so,
>     this is wrong and take it out..
>
>     Regards,
>
>     Bogdan-Andrei Iancu
>     OpenSIPS Founder and Developer
>     http://www.opensips-solutions.com
>
>
>     On 04/30/2013 01:09 PM, Laszlo wrote:
>>     Hi Bogdan,
>>
>>     Sorry for not explaining it well :)
>>
>>
>>     this is my problem:
>>
>>     U 2013/04/30 02:13:50.130487 xx.xx.xx.xx:5060
>>     <http://103.29.214.170:5060> -> yy.yy.yy.yy:5060
>>     <http://85.25.27.69:5060>
>>     SIP/2.0 183 Session Progress.
>>     Record-Route:
>>     <sip:6288808754418@;r2=on;lr;ftag=as439eda7d;did=35.b69971a2>.
>>     Record-Route: <sip:6288808754418 at xx.xx.xx.xx
>>     <mailto:sip%3A6288808754418 at 103.29.214.170>;r2=on;lr;ftag=as439eda7d;did=35.b69971a2>.
>>
>>     it is the packet relayed to the calling party, see the first
>>     record-route header, it's missing the host part.
>>
>>     It is missing when I use the b2b refer scenario. The refer-to is
>>     not processed in the trace, I'm just saying that the host part is
>>     missing :)
>>
>>
>>     when using the b2b top hiding scenario, the problem isn't present!
>>
>>
>>     -Laszlo
>>
>>
>>
>>
>>
>>     2013/4/30 Bogdan-Andrei Iancu <bogdan at opensips.org
>>     <mailto:bogdan at opensips.org>>
>>
>>         Hi Lazlo,
>>
>>         I do not understand - the LB + b2b refer capture shows a call
>>         going through the B2B and receiving a 503.....there is no
>>         REFER stuff there at all...
>>
>>         Is there something I mis ?
>>
>>
>>         Regards,
>>
>>         Bogdan-Andrei Iancu
>>         OpenSIPS Founder and Developer
>>         http://www.opensips-solutions.com
>>
>>
>>         On 04/29/2013 04:09 PM, Laszlo wrote:
>>>         Hi Bogdan,
>>>
>>>         with the stock LB config:
>>>         http://pastebin.com/xxxxxxxxxxx <http://pastebin.com/Msw6Hk0p>
>>>
>>>
>>>         with LB + b2b refer
>>>         http://pastebin.com/xxxxxxxxxxx <http://pastebin.com/zYb3PxLe>
>>>
>>>
>>>
>>>
>>>         2013/4/29 Bogdan-Andrei Iancu <bogdan at opensips.org
>>>         <mailto:bogdan at opensips.org>>
>>>
>>>             Hi Lazlo,
>>>
>>>             Could you post somewhere the SIP capture of the call ?
>>>             Just to be sure I correctly understand your scenario.
>>>
>>>             Regards,
>>>
>>>             Bogdan-Andrei Iancu
>>>             OpenSIPS Founder and Developer
>>>             http://www.opensips-solutions.com
>>>
>>>
>>>             On 04/29/2013 02:38 PM, Laszlo wrote:
>>>>             Hello,
>>>>
>>>>
>>>>             Just tried to play with the b2b refer scenario with
>>>>             opensips.
>>>>             The config is pretty much the default LB config from
>>>>             opensips.org <http://opensips.org>, so nothing sexy in
>>>>             the conf, it works fine without the b2b stuff. LB
>>>>             destinations are reachable through the private ip of
>>>>             the server.
>>>>
>>>>             if I use the b2b topology hiding scenario, it also work
>>>>             fine.
>>>>             when I use the refer scenario, things goes mad :)
>>>>
>>>>             Sending this to the caller party (default LB config):
>>>>
>>>>             U 2013/04/30 02:19:05.920262 opensips_public_ip:5060 ->
>>>>             caller_ip:5060
>>>>
>>>>             SIP/2.0 183 Session Progress.
>>>>
>>>>             Via: SIP/2.0/UDP
>>>>             caller_ip:5060;received=caller_ip;branch=z9hG4bK25704719;rport=5060.
>>>>
>>>>             Record-Route:
>>>>             <sip:username at opensips_private_ip;r2=on;lr;ftag=as38e68f66;did=a3c.83df6ae1>.
>>>>
>>>>             Record-Route:<sip:username at opensips_public_ip;r2=on;lr;ftag=as38e68f66;did=a3c.83df6ae1>.
>>>>
>>>>
>>>>
>>>>
>>>>             New call  with the refer settings applied:
>>>>
>>>>             U 2013/04/30 02:13:50.130487 opensips_public_ip:5060 ->
>>>>             caller_ip:5060
>>>>             SIP/2.0 183 Session Progress.
>>>>             Record-Route:
>>>>             <sip:6288808754418@;r2=on;lr;ftag=as439eda7d;did=35.b69971a2>.
>>>>             Record-Route:
>>>>             <sip:6288808754418 at opensips_public_ip;r2=on;lr;ftag=as439eda7d;did=35.b69971a2>.
>>>>
>>>>
>>>>             In the first record-route header, the host part is missing.
>>>>
>>>>             The relevant lines from the syslog in this case:
>>>>             Apr 30 02:13:47 svr2 /usr/local/sbin/opensips[30081]:
>>>>             CRITICAL:core:lumps_len: lumps_len called with null
>>>>             send_sock
>>>>             Apr 30 02:13:47 svr2 /usr/local/sbin/opensips[30081]:
>>>>             CRITICAL:core:lump_check_opt: null send socket
>>>>             Apr 30 02:13:47 svr2 /usr/local/sbin/opensips[30081]:
>>>>             CRITICAL:core:lump_check_opt: null send socket
>>>>             Apr 30 02:13:47 svr2 /usr/local/sbin/opensips[30081]:
>>>>             CRITICAL:core:lump_check_opt: null send socket
>>>>             Apr 30 02:13:47 svr2 /usr/local/sbin/opensips[30081]:
>>>>             CRITICAL:core:lump_check_opt: null send socket
>>>>             Apr 30 02:13:47 svr2 /usr/local/sbin/opensips[30081]:
>>>>             CRITICAL:core:process_lumps: null bind_address
>>>>             Apr 30 02:13:47 svr2 /usr/local/sbin/opensips[30081]:
>>>>             CRITICAL:core:lump_check_opt: null send socket
>>>>             Apr 30 02:13:47 svr2 /usr/local/sbin/opensips[30081]:
>>>>             CRITICAL:core:lump_check_opt: null send socket
>>>>             Apr 30 02:13:47 svr2 /usr/local/sbin/opensips[30081]:
>>>>             CRITICAL:core:lump_check_opt: null send socket
>>>>             Apr 30 02:13:47 svr2 /usr/local/sbin/opensips[30081]:
>>>>             CRITICAL:core:lump_check_opt: null send socket
>>>>
>>>>
>>>>             What can cause this?
>>>>             It is a multihomed enviroment with opensips 1.9.
>>>>             # opensips -V
>>>>             version: opensips 1.9.0-notls (x86_64/linux)
>>>>             flags: STATS: Off, USE_IPV6, USE_TCP, 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:9980
>>>>             @(#) $Id: main.c 9790 2013-02-15 10:14:34Z bogdan_iancu $
>>>>             main.c compiled on 00:52:55 Apr 30 2013 with gcc 4.4.6
>>>>
>>>>
>>>>             -Laszlo
>>>>
>>>>
>>>>             _______________________________________________
>>>>             Users mailing list
>>>>             Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>>>>             http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20130509/76ec28b7/attachment-0001.htm>


More information about the Users mailing list