|Summary:||ASTERISK-16757: SIP 200 OK withou ACK|
|Reporter:||Bereterbide Marcelo (marhbere)||Labels:|
|Date Opened:||2010-09-30 16:35:36||Date Closed:||2011-06-07 14:00:42|
|Environment:||Attachments:||( 0) Flow-Call-Debug_Verbose.log|
( 1) Flow-Call-Debug_Verbose-within-1-6-2.log
|Description:||We have the issue when happening a problem into network.|
When Receive INVITE and we respond 200 OK, and this last not arrived to the originator, then the originator resend INVITE many times. But the *Asterisk "Answers" all this call such as if it were differents calls.
I guess this is heavy problem when will try conciliation with CDR calls.
Please can tell me if we have any mistake
|Comments:||By: Stefan Schmidt (schmidts) 2010-10-01 05:31:58|
could you please add some logs with verbose and debug set to level 10 and sip debug to this issue.
if the client acts rfc conform the caller-id should not change when an invite is sent again, so asterisk should find the call and just resend a 200 ok. atleast a 200 ok will be resent from asterisk if no ack is received.
By: Bereterbide Marcelo (marhbere) 2010-10-01 11:14:18
Thanks Schmidts; I try asap will make a Lab scenario because now these happened into production service. Please just give me a time.
By: Bereterbide Marcelo (marhbere) 2010-10-01 16:30:33
When make a call and it isn´t answerd, after sometime was received "Service Unavailable". But The *Asterisk of Destination have registered 2 Calls in CDR:
exten => 545454,1,Playback(we-dont-have-tech-support);
You can See the file with Debug Attached.
Thanks for advance
By: Leif Madsen (lmadsen) 2010-10-05 15:05:15
Looking through this log, I'm not sure this is a problem with Asterisk. Asterisk is responding with the 200 OK, and the other end is not ACKing it. We keep accepting the INVITEs and then ignoring them until the maximum time is reached at which point it appears the setup has failed and is then discarded from memory.
The other end continues to send INVITES back and since there is no dialog in memory, Asterisk is treating it as a new call.
This is pretty much what I would expect to happen. From my viewpoint, it looks like a NAT or firewall configuration problem on the network in which the other end point is sending an INVITE to Asterisk, and is not getting the responses, so it keeps trying over and over again.
Additionally, you marked this as against Asterisk 1.6.0 which is no longer receiving bug fixes -- only security fixes.
By: Leif Madsen (lmadsen) 2010-10-05 15:05:32
Per the Asterisk maintenance timeline page at http://www.asterisk.org/asterisk-versions maintenance (bug) support for the 1.6.0 and 1.6.1 branches has ended. For continued maintenance support please move to the 1.6.2 branch.
More information on this change can be found in the release announcement: http://www.asterisk.org/node/49924
By: Bereterbide Marcelo (marhbere) 2010-10-05 17:15:27
Hi Lmadsen, Now Upgrade to 1.6.2 and still the same issue.
A -> SVN-branch-1.6.2-r272459 - XXX.XXX.XXX.2XX
B -> SVN-branch-1.6.2-r281912 - YYY.YYY.YYY.3YY
Actually I run a Firewall in the mid for reproduce the issue. Since I guess the asterisk should wait Ack before changed the disposition to ANSWERED, and so generate inconsistency. Because a Third party bug can cause the ack not will arrive, but the asterik I see aren´t taking this on consideration.
May be, exist any change to do in config within sip.conf that solvent it. But I don´t know wich.
By: Stefan Schmidt (schmidts) 2010-10-06 01:27:23
@Leif i understand what you mean, and asterisk acts as it should by retransmit the 200 ok until T1*64 is reached and then drop the call but it should handle the incoming invites (which are retransmits) not as a new call.
i have looked at the code and the Ignoring this Invite message doesnt cause anything to the dialog of this message.
@marhbere you could try to set "pedantic=yes" in the sip config. With this enabled asterisk use a stricter method to find the old dialog and so this may not happens.
By: Bereterbide Marcelo (marhbere) 2010-10-06 12:14:28
@schmidts, I have tried with pedntic=yes, but still happening the same.
The call is logged such as if this have been two calls; and with billsec=3.
I know isn´t often that happen, but in a enviroment production it is to happended to us, And I consider is a conceptual case of how to asterisk must manage the Flow sip calls.
sip show settings
UDP SIP Port: 5060
UDP Bindaddress: 0.0.0.0
TCP SIP Port: Disabled
TLS SIP Port: Disabled
Ignore SDP sess. ver.: No
AutoCreate Peer: No
Match Auth Username: No
Allow unknown access: No
Allow subscriptions: No
Allow overlap dialing: No
Allow promsic. redir: No
Enable call counters: Yes
SIP domain support: Yes
Realm. auth: No
Our auth realm srv.teleCompany.com
Call to non-local dom.: Yes
URI user is phone no: No
Always auth rejects: No
Direct RTP setup: No
User Agent: MyCompanyIVRv1
SDP Session Name: Asterisk PBX SVN-branch-1.6.2-r281912
SDP Owner Name: root
Reg. context: (not set)
Regexten on Qualify: No
Caller ID: asterisk
Record SIP history: Off
Call Events: On
Auth. Failure Events: Off
T.38 support: No
T.38 EC mode: Unknown
T.38 MaxDtgrm: -1
SIP realtime: Disabled
Qualify Freq : 60000 ms
Network QoS Settings:
IP ToS SIP: CS0
IP ToS RTP audio: CS0
IP ToS RTP video: CS0
IP ToS RTP text: CS0
802.1p CoS SIP: 4
802.1p CoS RTP audio: 5
802.1p CoS RTP video: 6
802.1p CoS RTP text: 5
Jitterbuffer enabled: No
Jitterbuffer forced: No
Jitterbuffer max size: -1
Jitterbuffer resync: -1
Jitterbuffer log: No
SIP address remapping: Disabled, no localnet list
Internal IP: 127.0.0.1:5060
STUN server: 0.0.0.0:0
Global Signalling Settings:
Codecs: 0xc (ulaw|alaw)
Codec Order: ulaw:20,alaw:20
Relax DTMF: No
RFC2833 Compensation: No
Compact SIP headers: No
RTP Keepalive: 0 (Disabled)
RTP Timeout: 0 (Disabled)
RTP Hold Timeout: 0 (Disabled)
MWI NOTIFY mime type: application/simple-message-summary
DNS SRV lookup: No
Pedantic SIP support: Yes
Reg. min duration 60 secs
Reg. max duration: 3600 secs
Reg. default duration: 120 secs
Outbound reg. timeout: 30 secs
Outbound reg. attempts: 0
Notify ringing state: Yes
Include CID: No
Notify hold state: Yes
SIP Transfer mode: open
Max Call Bitrate: 384 kbps
Outb. proxy: <not set>
Session Timers: Accept
Session Refresher: uas
Session Expires: 1800 secs
Session Min-SE: 90 secs
Timer T1: 500
Timer T1 minimum: 200
Timer B: 32000
No premature media: No
Allowed transports: UDP
Outbound transport: UDP
Use ClientCode: No
Progress inband: No
MOH Interpret: default
MOH Suggest: default
Voice Mail Extension: asterisk
Forward Detected Loops: Yes
By: David Woolley (davidw) 2010-10-06 13:43:21
This doesn't look right to me (branch 1.6.2 SVN):
ast_debug(2, "%s: This call is UP.... \n", c->name);
transmit_response(p, "100 Trying", req);
Surely if the channel is UP, the dialogue state has passed PROCEEDING no provisional responses should be sent? (It looks to me as though Asterisk is collapsing some of the abstract layers in the SIP RFC.)
I'm not sure how that interacts with the CDRs, which seems to be the real issue here.
By: Stefan Schmidt (schmidts) 2010-10-06 15:07:16
Not really. A 100 trying have to be send as a reply to an invite. Its just an acknowledge to the sender its message has been received.
after looking at this part of code and also the handle_incoming everything looks fine there.
As leif said asterisk acts as expected and send the 200 OK unreliable back after the first invite, which means there are no further retransmits to the second invite, only retransmit the messages for the first invite and finally close the call after 32 seconds.
You noticed this as you see the 5xx response to one invite and also you can see it in the logs the time difference between this two calls are exactly 32 seconds.
but as david said the real issue is the wrong cdr value.
By: Stefan Schmidt (schmidts) 2010-10-06 15:44:37
i close this issue cause i have seen there is nothing wrong after catching what i have missed before.
asterisk really act like it should act in this case. you see the response to the first invite which will be retransmitted and on every further invite there is only one (unreliable) responde which is exactly the same like the first respond. This is just the way RFC said what should happens also if the Call is allready UP.
Asterisk does not start a new call, its still only one call.
how long is the we-dont-have-tech-support file you use for playback? if i have to guess i would say exactly 3 seconds.
Cause in your log you can see this row:
[Oct 5 21:36:26] VERBOSE pbx.c: -- Auto fallthrough, channel 'SIP/EXT-SRVARG009-00002775' status is 'UNKNOWN'
After looking into the main pbx function i see why this happens, the call is still in an undefinate state cause there was no ACK to the 200 OK message.
Thats why the pbx function breaks further running through the dialplan after 3 seconds (as i guess after the playback is finished) and makes a CDR Update to save the information.
This cdr information means nothing else than the call is answered (200 ok was sent so its answered) and until now 3 seconds passed by. You see this information in your cdrs.
And further this is exactly what asterisk should do in this case cause reseting the cdr informations could produce massive side effects (think of an reinvite message after a one hour call which could lead to the same result)
So i would suggest to use the Answer application before the playback so playback would not even start cause the channel is not really up or another way could be to set a channel variable and create a h extension to do a CDRRESET if this channel var is empty.