Dear All,
I am experimenting with OpenSER on an IPv6 environment. The pdt module appears not to support using an IPv6 address as destination domain (I guess that is true of source domain too, but I do not need that anyway).
I tried to append a pdt row to MySQL using the documented OpenSER FIFO interface. The message I sent to the FIFO is similar to
:pdt_add:openser_tmp_reply voip.mycompany.com 9 [::ffff:abcd:1234]
However, when the row is created in MySQL pdt, the [:: is apparently missing. I guess that is because the FIFO parser mistook that as the FIFO :-separated message header or something similar?
Testing with an IPv4 address instead as the destination domain, the row can be created properly, and prefix2domain() worked flawlessly in an IPv4 environment.
I would like to use IPv4-mapped IPv6 address to forward to an Asterisk PABX over SIP+IPv4 as Asterisk has no official IPv6 release yet (this is another question, whether OpenSER will handle v4-mapped address properly). This is what I would like to test by setting this pdt rule.
I'm using OpenSER 1.2.0-dev19-notls on i386/linux, by the way.
Thanks for any invaluable insights.
Regards, Bernard Chan.
Hi Bernard,
yes "::" is used as a separator between the name and the value of a attribute (line). Try to place the address between quotes to avoid parsing it:
:pdt_add:openser_tmp_reply voip.mycompany.com 9 "[::ffff:abcd:1234]"
regards, bogdan
Bernard Chan wrote:
Dear All,
I am experimenting with OpenSER on an IPv6 environment. The pdt module appears not to support using an IPv6 address as destination domain (I guess that is true of source domain too, but I do not need that anyway).
I tried to append a pdt row to MySQL using the documented OpenSER FIFO interface. The message I sent to the FIFO is similar to
:pdt_add:openser_tmp_reply voip.mycompany.com 9 [::ffff:abcd:1234]
However, when the row is created in MySQL pdt, the [:: is apparently missing. I guess that is because the FIFO parser mistook that as the FIFO :-separated message header or something similar?
Testing with an IPv4 address instead as the destination domain, the row can be created properly, and prefix2domain() worked flawlessly in an IPv4 environment.
I would like to use IPv4-mapped IPv6 address to forward to an Asterisk PABX over SIP+IPv4 as Asterisk has no official IPv6 release yet (this is another question, whether OpenSER will handle v4-mapped address properly). This is what I would like to test by setting this pdt rule.
I'm using OpenSER 1.2.0-dev19-notls on i386/linux, by the way.
Thanks for any invaluable insights.
Regards, Bernard Chan.
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
於 二，2007-03-06 於 19:20 +0200，Bogdan-Andrei Iancu 提到：
Hi Bernard,
yes "::" is used as a separator between the name and the value of a attribute (line). Try to place the address between quotes to avoid parsing it:
:pdt_add:openser_tmp_reply voip.mycompany.com 9 "[::ffff:abcd:1234]"
Hello,
Thank you for your tips. I tried that and it appeared to be created in the database correctly. However, when I tried to call '90001', for instance, from the UA, the call is not forwarded to the Asterisk server. I monitored the packets with tcpdump and no packet can be observed from OpenSER to the Asterisk server with the message sent in IPv4 as expected. The OpenSER error log does not reveal much about this.
Regards, Bernard Chan.
Hi Bernard,
but, do you see any sip reply from the proxy? or the request is silently dropped?
also, increase the debugging level (set it to 9) and get a full log - maybe something will be relevant there...
regards, bogdan
Bernard Chan wrote:
於 二，2007-03-06 於 19:20 +0200，Bogdan-Andrei Iancu 提到：
Hi Bernard,
yes "::" is used as a separator between the name and the value of a attribute (line). Try to place the address between quotes to avoid parsing it:
:pdt_add:openser_tmp_reply voip.mycompany.com 9 "[::ffff:abcd:1234]"
Hello,
Thank you for your tips. I tried that and it appeared to be created in the database correctly. However, when I tried to call '90001', for instance, from the UA, the call is not forwarded to the Asterisk server. I monitored the packets with tcpdump and no packet can be observed from OpenSER to the Asterisk server with the message sent in IPv4 as expected. The OpenSER error log does not reveal much about this.
Regards, Bernard Chan.
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Hello,
於 三，2007-03-07 於 15:06 +0200，Bogdan-Andrei Iancu 提到：
Hi Bernard,
but, do you see any sip reply from the proxy? or the request is silently dropped?
The reply is 404 not found.
also, increase the debugging level (set it to 9) and get a full log - maybe something will be relevant there...
I switched the debug level to 9 and found this:
3(6119) parsed uri: type=1 user=<91900>(5) passwd=<>(0) host=<voip.mobileclusters.com>(23) port=<>(0): 0 params=<>(0) headers=<>(0) 3(6119) uri params: transport=<>, val=<>, proto=0 3(6119) user-param=<>, val=<> 3(6119) method=<>, val=<> 3(6119) ttl=<>, val=<> 3(6119) maddr=<>, val=<> 3(6119) lr=<> 3(6119) parsed uri: type=1 user=<1900>(4) passwd=<>(0) host=<voip.mobileclusters.com>(23) port=<>(0): 0 params=<>(0) headers=<>(0) 3(6119) uri params: transport=<>, val=<>, proto=0 3(6119) user-param=<>, val=<> 3(6119) method=<>, val=<> 3(6119) ttl=<>, val=<> 3(6119) maddr=<>, val=<> 3(6119) lr=<> 3(6119) PDT: update_new_uri: len=27 uri=sip:1900@[::ffff:ca7a:6903] 3(6119) parsed uri: type=1 user=<1900>(4) passwd=<>(0) host=<[::ffff:ca7a:6903]>(18) port=<>(0): 0 params=<>(0) headers=<>(0) 3(6119) uri params: transport=<>, val=<>, proto=0 3(6119) user-param=<>, val=<> 3(6119) method=<>, val=<> 3(6119) ttl=<>, val=<> 3(6119) maddr=<>, val=<> 3(6119) lr=<> 3(6119) grep_sock_info - checking if host==us: 16==24 && [::ffff:ca7a:6903] == [2002:D203:FE9:0:0:0:1:10] 3(6119) grep_sock_info - checking if port 15060 matches port 5060 3(6119) grep_sock_info - checking if host==us: 16==18 && [::ffff:ca7a:6903] == [FEE0:0:0:0:0:0:1:1] 3(6119) grep_sock_info - checking if port 15060 matches port 5060 3(6119) grep_sock_info - checking if host==us: 16==23 && [::ffff:ca7a:6903] == [0:0:0:0:0:FFFF:C0A8:AA5] 3(6119) grep_sock_info - checking if port 15060 matches port 5060 3(6119) DEBUG:check_self: host != me 3(6119) DEBUG: t_newtran: msg id=8 , global msg id=7 , T on entrance=0xffffffff 3(6119) parse_headers: flags=ffffffffffffffff 3(6119) parse_headers: flags=78 3(6119) t_lookup_request: start searching: hash=46102, isACK=0 3(6119) DEBUG: RFC3261 transaction matching failed 3(6119) DEBUG: t_lookup_request: no transaction found 3(6119) DBG: trans=0xb5c4a020, callback type 1, id 0 entered 3(6119) parse_headers: flags=ffffffffffffffff 3(6119) check_via_address(2002:D203:FE9:0:0:0:1:4, [2002:d203:fe9::1:4], 0) 3(6119) WARNING:vqm_resize: resize(0) called 3(6119) DEBUG:tm:_reply_light: reply sent out. buf=0x813f150: SIP/2.0 1..., shmem=0xb5c48340: SIP/2.0 1 3(6119) DEBUG:tm:_reply_light: finished 3(6119) parsed uri: type=1 user=<1900>(4) passwd=<>(0) host=<[::ffff:ca7a:6903]>(18) port=<>(0): 0 params=<>(0) headers=<>(0) 3(6119) uri params: transport=<>, val=<>, proto=0 3(6119) user-param=<>, val=<> 3(6119) method=<>, val=<> 3(6119) ttl=<>, val=<> 3(6119) maddr=<>, val=<> 3(6119) lr=<> 3(6119) DEBUG: mk_proxy: doing DNS lookup... 3(6119) check_via_address(2002:D203:FE9:0:0:0:1:4, [2002:d203:fe9::1:4], 0) 3(6119) ERROR: udp_send: sendto(sock,0xb5c44938,1052,0,0xb5c4a12c,28): Invalid argument(22) 3(6119) CRITICAL: invalid sendtoparameters one possible reason is the server is bound to localhost and attempts to send to the net 3(6119) msg_send: ERROR: udp_send failed
Obviously the sendto() failed. And I have these in the openser.cfg:
check_via=no # (cmd. line: -v) dns=no # (cmd. line: -r) rev_dns=no # (cmd. line: -R) listen=udp:[2002:d203:fe9::1:10]:15060 listen=udp:[fee0::1:1]:15060 listen=udp:[::ffff:c0a8:0aa5]:15060 port=15060 children=4
alias="voip.mobileclusters.com"
Regards, Bernard Chan.
-
Bernard Chan -
Bogdan-Andrei Iancu