I just spend a lot of time to fix a trouble with Cisco AS5300 (AS5350) BYE message disapearing. The same not resolved case here: http://lists.iptel.org/pipermail/serusers/2005-July/021698.html
The source of trouble was in the nat_uac_test parameter 16:
Here is the part of cisco log: Jul 31 12:16:00.726 UKR: CCSIP-SPI-CONTROL: act_idle_connection_created: Connid(1) created to 193.28.184.13:5060, local_port 50058
--Skipped--- Jul 31 12:16:00.738 UKR: Sent: INVITE sip:3039100@193.28.184.13:5060 SIP/2.0 Via: SIP/2.0/UDP 193.28.184.21:5060 From: sip:2308228@193.28.184.21;tag=12E601F8-10C7 To: sip:3039100@193.28.184.13
Via header the same in the all availible IOS-es.
As the result openser considerate the Cisco is out of the nat box.
The question is: Can someone show me the case when this parameter is necessary, before I'll switch it of on the production server?
Thanks in advance.
Andrew O. Zhukov.
On 31.07.2009 11:55 Uhr, Andrew O. Zhukov wrote:
I just spend a lot of time to fix a trouble with Cisco AS5300 (AS5350) BYE message disapearing. The same not resolved case here: http://lists.iptel.org/pipermail/serusers/2005-July/021698.html
The source of trouble was in the nat_uac_test parameter 16:
Here is the part of cisco log: Jul 31 12:16:00.726 UKR: CCSIP-SPI-CONTROL: act_idle_connection_created: Connid(1) created to 193.28.184.13:5060, local_port 50058
--Skipped--- Jul 31 12:16:00.738 UKR: Sent: INVITE sip:3039100@193.28.184.13:5060 SIP/2.0 Via: SIP/2.0/UDP 193.28.184.21:5060 From: sip:2308228@193.28.184.21;tag=12E601F8-10C7 To: sip:3039100@193.28.184.13
Via header the same in the all availible IOS-es.
As the result openser considerate the Cisco is out of the nat box.
The question is: Can someone show me the case when this parameter is necessary, before I'll switch it of on the production server?
I am not sure I got the problem here. Can you send entire sip trace for such a call? ser/openser does not store dialog state, so the ua should update details within calls. be sure you can the nathelper contact update function for ack as well.
Daniel
Daniel-Constantin Mierla пишет:
On 31.07.2009 11:55 Uhr, Andrew O. Zhukov wrote:
I just spend a lot of time to fix a trouble with Cisco AS5300 (AS5350) BYE message disapearing. The same not resolved case here: http://lists.iptel.org/pipermail/serusers/2005-July/021698.html
The source of trouble was in the nat_uac_test parameter 16:
Here is the part of cisco log: Jul 31 12:16:00.726 UKR: CCSIP-SPI-CONTROL: act_idle_connection_created: Connid(1) created to 193.28.184.13:5060, local_port 50058
--Skipped--- Jul 31 12:16:00.738 UKR: Sent: INVITE sip:3039100@193.28.184.13:5060 SIP/2.0 Via: SIP/2.0/UDP 193.28.184.21:5060 From: sip:2308228@193.28.184.21;tag=12E601F8-10C7 To: sip:3039100@193.28.184.13
Via header the same in the all availible IOS-es.
As the result openser considerate the Cisco is out of the nat box.
The question is: Can someone show me the case when this parameter is necessary, before I'll switch it of on the production server?
I am not sure I got the problem here. Can you send entire sip trace for such a call? ser/openser does not store dialog state, so the ua should update details within calls. be sure you can the nathelper contact update function for ack as well.
Daniel
route[5] { # if (src_ip==193.28.184.21) { # xlog("L_INFO", "AS5300 requrst - M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n"); # return; # } if (nat_uac_test("19")) { force_rport(); if (method=="REGISTER") { fix_nated_register(); } else { fix_nated_contact(); }; setflag(5);
http://www.ipshka.com/core/Nat.txt commented if src= http://www.ipshka.com/core/NoNat.txt Not commented
btw: ngrep -W byline makes the trace readable :-)
klaus
Andrew O. Zhukov schrieb:
Daniel-Constantin Mierla пишет:
On 31.07.2009 11:55 Uhr, Andrew O. Zhukov wrote:
I just spend a lot of time to fix a trouble with Cisco AS5300 (AS5350) BYE message disapearing. The same not resolved case here: http://lists.iptel.org/pipermail/serusers/2005-July/021698.html
The source of trouble was in the nat_uac_test parameter 16:
Here is the part of cisco log: Jul 31 12:16:00.726 UKR: CCSIP-SPI-CONTROL: act_idle_connection_created: Connid(1) created to 193.28.184.13:5060, local_port 50058
--Skipped--- Jul 31 12:16:00.738 UKR: Sent: INVITE sip:3039100@193.28.184.13:5060 SIP/2.0 Via: SIP/2.0/UDP 193.28.184.21:5060 From: sip:2308228@193.28.184.21;tag=12E601F8-10C7 To: sip:3039100@193.28.184.13
Via header the same in the all availible IOS-es.
As the result openser considerate the Cisco is out of the nat box.
The question is: Can someone show me the case when this parameter is necessary, before I'll switch it of on the production server?
I am not sure I got the problem here. Can you send entire sip trace for such a call? ser/openser does not store dialog state, so the ua should update details within calls. be sure you can the nathelper contact update function for ack as well.
Daniel
route[5] { # if (src_ip==193.28.184.21) { # xlog("L_INFO", "AS5300 requrst - M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n"); # return; # } if (nat_uac_test("19")) { force_rport(); if (method=="REGISTER") { fix_nated_register(); } else { fix_nated_contact(); }; setflag(5);
http://www.ipshka.com/core/Nat.txt commented if src= http://www.ipshka.com/core/NoNat.txt Not commented
sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Hello,
On 31.07.2009 14:20 Uhr, Andrew O. Zhukov wrote:
Daniel-Constantin Mierla пишет:
On 31.07.2009 11:55 Uhr, Andrew O. Zhukov wrote:
I just spend a lot of time to fix a trouble with Cisco AS5300 (AS5350) BYE message disapearing. The same not resolved case here: http://lists.iptel.org/pipermail/serusers/2005-July/021698.html
The source of trouble was in the nat_uac_test parameter 16:
Here is the part of cisco log: Jul 31 12:16:00.726 UKR: CCSIP-SPI-CONTROL: act_idle_connection_created: Connid(1) created to 193.28.184.13:5060, local_port 50058
--Skipped--- Jul 31 12:16:00.738 UKR: Sent: INVITE sip:3039100@193.28.184.13:5060 SIP/2.0 Via: SIP/2.0/UDP 193.28.184.21:5060 From: sip:2308228@193.28.184.21;tag=12E601F8-10C7 To: sip:3039100@193.28.184.13
Via header the same in the all availible IOS-es.
As the result openser considerate the Cisco is out of the nat box.
The question is: Can someone show me the case when this parameter is necessary, before I'll switch it of on the production server?
I am not sure I got the problem here. Can you send entire sip trace for such a call? ser/openser does not store dialog state, so the ua should update details within calls. be sure you can the nathelper contact update function for ack as well.
Daniel
route[5] { # if (src_ip==193.28.184.21) { # xlog("L_INFO", "AS5300 requrst - M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n"); # return; # } if (nat_uac_test("19")) { force_rport(); if (method=="REGISTER") { fix_nated_register(); } else { fix_nated_contact(); }; setflag(5);
caught in some other task meanwhile ... however, the nat is changed for the cisco indeed, from PRACK there is a different source port. But the 200ok for invite goes to old port and is accepted by cisco. Then the ACK comes from the new port -- pretty strange.
Since the PRACK and ACK do not have contact header, you can try add it. Might help, although the callee should update its dialog state otherwise there is not a easy solution.
So:
if(is_method("PRACK|ACK") && !is_present_hf("Contact")) append_hf("Contact: sip:$si:$sp;nat=yes\r\n");
Let me know if works.
Cheers, Daniel
commented if src= http://www.ipshka.com/core/NoNat.txt Not commented
sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
So:
if(is_method("PRACK|ACK") && !is_present_hf("Contact")) append_hf("Contact: sip:$si:$sp;nat=yes\r\n");
Let me know if works.
Cheers, Daniel
I try it. Do not working. http://www.ipshka.com/core/fix_ask.txt Snom use the port from INVITE, mesage not from ASK Possible it can fix the trouble for other UA. Anyway it's not a common solution.
Actually, if Cisco is over the port restricted or symmetric nat, without the port mapping it's not possible to fix it at all.
Thanks Andrew.
The problem arises because the Cisco is SIP asymmetric. Thus, why do you apply NAT traversal at all?
I would make something like this:
route{ if (src_ip==ip.of.cisco.gw) { xlog("request from cisco, no NAT traversal"); } else { force_rport(); if (is_method("REGISTER)) { fix_nated_register(); } else { fix_nated_contact(); } } ... }
reply_route[x] { if (src_ip==ip.of.cisco.gw) { xlog("request from cisco, no NAT traversal"); } else { fix_nated_contact(); } ... }
regards klaus
Andrew O. Zhukov schrieb:
So:
if(is_method("PRACK|ACK") && !is_present_hf("Contact")) append_hf("Contact: sip:$si:$sp;nat=yes\r\n");
Let me know if works.
Cheers, Daniel
I try it. Do not working. http://www.ipshka.com/core/fix_ask.txt Snom use the port from INVITE, mesage not from ASK Possible it can fix the trouble for other UA. Anyway it's not a common solution.
Actually, if Cisco is over the port restricted or symmetric nat, without the port mapping it's not possible to fix it at all.
Thanks Andrew.
sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users