Hello all,
We are currently performing a number of interoperability tests between OpenSER and SIP Communicator over IPv6.
The good news is that we have successfully established IPv6 calls between two SIP Communicator instances registered on our local OpenSER installation (version 1.1.0-7 on Debian testing).
There is however something weird we'd appreciate any ideas on what might be causing it:
When running OpenSER with a default configuration, any ACKs that the caller tries to proxy through OpenSER don't get forwarded to the callee. Changing syn_branch to "no" (we saw somewhere that this might be related) didn't have any effect. I am attaching a log snippet that seems to be corresponding to the ACK processing.
In a desperate attempt to resolve the issue we added the following to our route{} clause:
if (method == "ACK") { forward("[2001:660:4701:f009:213:ceff:fea7:a88c]:5060"); exit; }
where [2001:660:4701:f009:213:ceff:fea7:a88c] is the IPv6 address of the callee.
This worked but it is obviously not (even close to) a "viable" solution.
So our question is, what would be the best way to make OpenSER forward ACKs that a caller is trying to send to a callee?
Thanks Emil
2(11235) receive_msg: cleaning up 4(11237) SIP Request: 4(11237) method: <ACK> 4(11237) uri: sip:emcho@ipv6.sip-communicator.org 4(11237) version: <SIP/2.0> 4(11237) parse_headers: flags=2 4(11237) Found param type 232, <branch> = <z9hG4bKc01a084c923dbc4a5de11530d611fe64>; state=16 4(11237) end of header reached, state=5 4(11237) parse_headers: Via found, flags=2 4(11237) parse_headers: this is the first via 4(11237) After parse_msg... 4(11237) preparing to run routing scripts... 4(11237) DEBUG : sl_filter_ACK: to late to be a local ACK! 4(11237) parse_headers: flags=100 4(11237) get_hdr_field: cseq <CSeq>: <1> <ACK> 4(11237) DEBUG: add_param: tag=b9b9c012 4(11237) DEBUG:parse_to:end of header reached, state=29 4(11237) DBUG:parse_to: display={"emcho"}, ruri={sip:emcho@ipv6.sip-communicator.org} 4(11237) DEBUG: get_hdr_field: <To> [60]; uri=[sip:emcho@ipv6.sip-communicator.org] 4(11237) DEBUG: to body ["emcho" sip:emcho@ipv6.sip-communicator.org] 4(11237) DEBUG:maxfwd:is_maxfwd_present: value = 70 4(11237) DEBUG: add_param: tag=b7cb05bc 4(11237) DEBUG:parse_to:end of header reached, state=29 4(11237) DBUG:parse_to: display={"77"}, ruri={sip:77@ipv6.sip-communicator.org} 4(11237) parse_headers: flags=200 4(11237) is_preloaded: No 4(11237) grep_sock_info - checking if host==us: 25==25 && [ipv6.sip-communicator.org] == [ipv6.sip-communicator.org] 4(11237) grep_sock_info - checking if port 5060 matches port 5060 4(11237) after_strict: Next hop: 'sip:[2001:660:4701:1001:20E:7FFF:FEB5:AAA3];ftag=b7cb05bc;lr=on' is loose router 4(11237) parse_headers: flags=ffffffffffffffff 4(11237) DEBUG: get_hdr_body : content_length=0 4(11237) found end of header 4(11237) rewrite_uri: Rewriting Request-URI with 'sip:[2001:660:4701:1001:20E:7FFF:FEB5:AAA3];ftag=b7cb05bc;lr=on' 4(11237) after_strict: The last route URI: 'sip:[2001:660:4701:1001:20E:7FFF:FEB5:AAA3];ftag=b7cb05bc;lr=on' 4(11237) parse_headers: flags=ffffffffffffffff 4(11237) DEBUG: t_newtran: msg id=3 , global msg id=2 , T on entrance=0xffffffff 4(11237) parse_headers: flags=ffffffffffffffff 4(11237) parse_headers: flags=78 4(11237) t_lookup_request: start searching: hash=42196, isACK=1 4(11237) parse_headers: flags=38 4(11237) DEBUG: t_lookup_request: e2e proxy ACK found 4(11237) DEBUG:tm:REF_UNSAFE: after is 1 4(11237) DEBUG:tm:t_newtran: building branch for end2end ACK 4(11237) DEBUG:tm:UNREF_UNSAFE: after is 0 4(11237) DEBUG:tm:t_relay: forwarding ACK 4(11237) DEBUG: mk_proxy: doing DNS lookup... 4(11237) check_via_address(2001:660:4701:F009:215:FF:FE35:EE1F, 0.0.0.0, 0) 4(11237) Sending: ACK sip:[2001:660:4701:1001:20E:7FFF:FEB5:AAA3];ftag=b7cb05bc;lr=on SIP/2.0 Record-Route: sip:[2001:660:4701:1001:20E:7FFF:FEB5:AAA3];lr=on;ftag=b7cb05bc Via: SIP/2.0/UDP [2001:660:4701:1001:20E:7FFF:FEB5:AAA3];branch=z9hG4bK4d4a.9db19213.2 Via: SIP/2.0/UDP 0.0.0.0;received=2001:660:4701:F009:215:FF:FE35:EE1F;branch=z9hG4bKc01a084c923dbc4a5de11530d611fe64 CSeq: 1 ACK Call-ID: 39bdf32f765ff3a4b67d1eedc2d538c9@0.0.0.0 From: "77" sip:77@ipv6.sip-communicator.org;tag=b7cb05bc To: "emcho" sip:emcho@ipv6.sip-communicator.org;tag=b9b9c012 User-Agent: SIP Communicator 1.0 CVS-Fri_Jan_05_18-27-08_EET_2007 Max-Forwards: 69 Content-Length: 0 P-hint: rr-enforced
. 4(11237) orig. len=490, new_len=679, proto=1 4(11237) DEBUG:destroy_avp_list: destroying list (nil)
Hi Emil!
Are you sure that the ACK is correct formated? Maybe you can attach a "ngrep -W byline port 5060" dump and your config.
regards klaus
Emil Ivov wrote:
Hello all,
We are currently performing a number of interoperability tests between OpenSER and SIP Communicator over IPv6.
The good news is that we have successfully established IPv6 calls between two SIP Communicator instances registered on our local OpenSER installation (version 1.1.0-7 on Debian testing).
There is however something weird we'd appreciate any ideas on what might be causing it:
When running OpenSER with a default configuration, any ACKs that the caller tries to proxy through OpenSER don't get forwarded to the callee. Changing syn_branch to "no" (we saw somewhere that this might be related) didn't have any effect. I am attaching a log snippet that seems to be corresponding to the ACK processing.
In a desperate attempt to resolve the issue we added the following to our route{} clause:
if (method == "ACK") { forward("[2001:660:4701:f009:213:ceff:fea7:a88c]:5060"); exit; }
where [2001:660:4701:f009:213:ceff:fea7:a88c] is the IPv6 address of the callee.
This worked but it is obviously not (even close to) a "viable" solution.
So our question is, what would be the best way to make OpenSER forward ACKs that a caller is trying to send to a callee?
Thanks Emil
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users