[Home]

Summary:ASTERISK-16757: SIP 200 OK withou ACK
Reporter:Bereterbide Marcelo (marhbere)Labels:
Date Opened:2010-09-30 16:35:36Date Closed:2011-06-07 14:00:42
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:Frequency of
Occurrence
Related
Issues:
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

Tanks
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.

thanks
schmidts
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.

Rgds
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:

id,calldate,clid,src,dst,dcontext,channel,dstchannel,lastapp,lastdata,duration,billsec,disposition,amaflags,accountcode,uniqueid,userfield
746980,"2010-10-01 20:30:52","","21111111","545454","RPInbound","SIP/EXT-SRVARG009-0004a830","","Playback","we-dont-have-tech-support",3,3,"ANSWERED",3,"","1285965052.305200",""
746981,"2010-10-01 20:31:24","","21111111","545454","RPInbound","SIP/EXT-SRVARG009-0004a831","","Playback","we-dont-have-tech-support",3,3,"ANSWERED",3,"","1285965084.305201",""
//*
The DialPlan:
[RPInbound]

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.

Best Regards,
MB.
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


Global Settings:
----------------
 UDP SIP Port:           5060
 UDP Bindaddress:        0.0.0.0
 TCP SIP Port:           Disabled
 TLS SIP Port:           Disabled
 Videosupport:           No
 Textsupport:            No
 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
 From: Domain:          
 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 impl:      
 Jitterbuffer log:       No

Network Settings:
---------------------------
 SIP address remapping:  Disabled, no localnet list
 Externhost:             <none>
 Externip:               0.0.0.0:0
 Externrefresh:          10
 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
 Auto-Framing:           No
 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

Default Settings:
-----------------
 Allowed transports:     UDP
 Outbound transport:     UDP
 Context:                default
 Nat:                    RFC3581
 DTMF:                   auto
 Qualify:                0
 Use ClientCode:         No
 Progress inband:        No
 Language:               en
 MOH Interpret:          default
 MOH Suggest:            default
 Voice Mail Extension:   asterisk
 Forward Detected Loops: Yes

Thanks,
Marcelo B.
By: David Woolley (davidw) 2010-10-06 13:43:21

This doesn't look right to me (branch 1.6.2 SVN):

case AST_STATE_UP:
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[10748] 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.

best regards

Stefan Schmidt