markus monka
2004-Apr-21 03:34 UTC
[Asterisk-Users] SIP ACK // CSeq 0 => ZAP Channel hangup
Szenario: UA(Grandstream) => PROXY(SER) => GATEWAY(*) => PSTN After sending the SIP ACK From Gateway (*) ACK sip:123456@127.0.0.1 SIP/2.0 Via: SIP/2.0/UDP 127.0.0.1;branch=z9hG4bK86c0bd474ea746b5 From: "Me" <sip:123456@mydomain.de>;tag=0f63d269bc25545d To: <sip:100@mydomain.de>;tag=as05df60b5 Contact: <sip:100@192.168.0.1> Call-ID: 57727a5f8b576b8f@192.168.0.1 CSeq: 0 ACK ^^^ User-Agent: Grandstream 1.0.4.39 Warning: 399 192.168.0.1 "detected firewall/NAT type is full cone" Max-Forwards: 68 Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE Content-Length: 0 The * Channels hangs up: ^@16 headers, 0 lines ^@^M^[[K*CLI> ^MNEW_HANGUP DEBUG: Calling q931_hangup, ourstate Active, peerstate Connect Request ^@> Protocol Discriminator: Q.931 (8) len=9 ^@> Call Ref: len= 2 (reference 280/0x118) (Originator) ^@> Message type: DISCONNECT (69) ^@> Cause (len= 2) [ Ext: 1 Coding: CCITT (ITU) standard (0) 0: 0 Location: Private network serving the local user (1) ^@> Ext: 1 Cause: Normal Clearing (16), class = Normal Event (1) ] ^@ -- Hungup 'Zap/9-1' Is this a * Problem? Looking into the Sources shows(chan_sip.c): else if (!strcasecmp(cmd, "ACK")) { /* Uhm, I haven't figured out the point of the ACK yet. Are we supposed to retransmit responses until we get an ack? Make sure this is on a valid call */ __sip_ack(p, seqno, 1); if (strlen(get_header(req, "Content-Type"))) { if (process_sdp(p, req)) return -1; } if (!p->lastinvite && !strlen(p->randdata)) ^^^^^^^^^^^^^^ p->needdestroy = 1; } Could it be, that * hangs up while getting zero as p->lastresult (CSeq == 0 )? Also it looks like a bug in the grandstreamfirmware sending CSeq zero? would something like this solve the Problem? if (!p->lastinvite >= 0 && !strlen(p->randdata)) ^^^^^ ? Best Regards Markus