[SR-Users] Missing ACK
Klaus Darilion
klaus.mailinglists at pernau.at
Fri Jul 2 18:37:33 CEST 2010
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
More information about the sr-users
mailing list