If you allways route the requests from the broken caller to the other gateway, you can use something like that:


...
if (loose_route() {
  if (src__ip=10.10.10.128) {
    $rd=10.20.20.153;
    $du="sip:10.20.20.153:5060";
  }
  ... normal loose-route processing
  t_relay();
  exit;
}
...

regards
Klaus

Am 02.07.2010 17:28, schrieb Claudio Furrer:
Hi, I have a similar issue,

It is not possible to debug this issue without full SIP trace!

ngrep -Wbyline -t -d any port 5060

I find it unpleasant to read such a trace. Please really use ngrep to get
a
nice formated SIP trace, or supply the pcap file.


Ok, here it goes again.

Pay attention to the "200: OK" response from the PSTN-GW. I think its
Contact
header should be read by the Cisco GW (calling party), and then send its
ACK-request with R-URI based on that Contact. But it doesn't happen. Then
here i
think this is the failure. (rfc3261, section 12.1.1 and 12.2.1.2). May i am
wrong..

What do you think?
I'd appreciate your comments.

You are right. Caller behaves wrong, it should send ACK with
RURI=ContactOf200Ok.

Maybe this is a buggy NAT traversal feature of Caller (Cisco?) which can be
turned off.

If you can't fix it at Caller-side, you can make some workarounds at the proxy
(if it is a fixed routing to the other gateway)


I think being a cisco device, there isn't too much to touch/modify. Just to
start thinking about a workaround. Which kind of modification, source code or
ser.cfg config? Maybe accepting and relaying all ACKs sent by this gw; simple,
but insecure, not sure.

Thank you Klaus,
Caio

_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Reply via email to