On Jul 2, 2010, at 9:54 AM, Claudio Furrer elc...@gmail.com wrote:
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.
Am 01.07.2010 17:40, schrieb Claudio Furrer:
Am 01.07.2010 14:38, 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
Am 02.07.2010 15:54, 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
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;
}
...
Hi, I have a similar issue, my proxy sip doesn't relay the ACK coming from a
Cisco GW (caller), to a PSTN-GW (callee), then the OK and ACK are retransmitted
for a while till the pstn-gw send a BYE.
Attach a text graph, where:
10.10.10.128 is a Cisco GW.
10.15.15.122 is my Proxy SIP (and oldie
Am 01.07.2010 14:38, 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
regards
Klaus
Sorry, here the trace (gziped).
Regards,
Caio
call_ack_fail1.txt.gz
Description: Binary data
Hello,
The guy operating the Asterisk at the far end have been inspecting the traces
I've sent him. Hen notes that the ACK relayed doesn't entirely comply to the
standard. The values of branch in the VIA header of the relayed ACK
response incorrectly have the value 0 (also rport in the VIA
Den 30/06/2010 kl. 01.23 skrev Iñaki Baz Castillo:
2010/6/29 Ole Kaas o...@tet.dk:
Hi Klaus,
I've mailed pcap dump to you directly for further inspection.
Hi, it's much better if you capture a trace with ngrep -Wbyline -t -q
port 5060 and paste it in a new mail by replacing your public
Hello,
See transmission below. For some reason the ACK package is lost/dropped and the
remote server retransmits the 200 OK status. But Kamailio does not retransmit
the ACK on receiving the retransmitted OK's. Eventually the remote server gives
up and pulls the plug after ~20 seconds. Is this
The log does not tell us anything.
If you want to know from us if your config is wrong or your
clients/server is buggy, then we need an ngrep dump recorded at the SIP
proxy:
ngrep -Wbyline -t -q port 5060
regards
Klaus
Am 29.06.2010 12:37, schrieb Ole Kaas:
Hello,
See transmission below.
I have also seen this with Kamailio 1.5 I have not confirmed whether
Kamailio is sending the 200 OK back down to my asterisk server or not.
On Tue, Jun 29, 2010 at 7:15 AM, Klaus Darilion
klaus.mailingli...@pernau.at wrote:
The log does not tell us anything.
If you want to know from us if
Hi Klaus,
I've mailed pcap dump to you directly for further inspection.
/Ole
Den 29/06/2010 kl. 13.15 skrev Klaus Darilion:
The log does not tell us anything.
If you want to know from us if your config is wrong or your clients/server is
buggy, then we need an ngrep dump recorded at the
2010/6/29 Ole Kaas o...@tet.dk:
Hi Klaus,
I've mailed pcap dump to you directly for further inspection.
Hi, it's much better if you capture a trace with ngrep -Wbyline -t -q
port 5060 and paste it in a new mail by replacing your public IP's
with other values. Then all the people here could
13 matches
Mail list logo
