Asterisk does accept cancel request: 481 Call does not exist

Thats my dialplan
exten => _.,1,Dial(SIP/${EXTEN}@fritzbox620)
It works as long as the called answers. But when he does not answer and I hang up, Asterisk keeps dialing and thus ringing with the called person.
I use android integrated SIP as VOIP client.

Thats the invite request:

[code]INVITE sip:**610@ SIP/2.0
Call-ID: a7154dfe533ea48a7e2f09a073bc89b6@
CSeq: 2142 INVITE
From: “user” sip:user@;tag=480132910
To: sip:**610@
Via: SIP/2.0/UDP;branch=z9hG4bKe4b859e6e5aa2f713a97804f9864f7c7373331;rport
Max-Forwards: 70
Contact: “user” sip:user@;transport=udp
Content-Type: application/sdp
Authorization: Digest username=“user”,realm=“asterisk”,nonce=“70b2f277”,uri=“sip:**610@”,response=“a708704f30c2ce0b9ec98ba885304102”,algorithm=MD5
Content-Length: 300

o=- 1361998548287 1361998548288 IN IP4
c=IN IP4
t=0 0
m=audio 3416 RTP/AVP 96 97 3 0 8 127
a=rtpmap:96 GSM-EFR/8000
a=rtpmap:97 AMR/8000
a=rtpmap:3 GSM/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:127 telephone-event/8000
a=fmtp:127 0-15

Now the cancel request:

CANCEL sip:**610@ SIP/2.0
Call-ID: a7154dfe533ea48a7e2f09a073bc89b6@
To: <sip:**610@>
CSeq: 2142 CANCEL
From: "user" <sip:user@>;tag=480132910
Via: SIP/2.0/UDP;branch=z9hG4bKe4b859e6e5aa2f713a97804f9864f7c7373331;rport
Max-Forwards: 70
Content-Length: 0

Asterisk answers with

SIP/2.0 481 Call/Transaction Does Not Exist Via: SIP/2.0/UDP;branch=z9hG4bKe4b859e6e5aa2f713a97804f9864f7c7373331;received=;rport=52380 From: "user" <sip:user@>;tag=480132910 To: <sip:**610@>;tag=as22f0886f Call-ID: a7154dfe533ea48a7e2f09a073bc89b6@ CSeq: 2142 CANCEL Server: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH Supported: replaces, timer Content-Length: 0

So it is obivius that Asterisk doesn’t stop to dial because it does not recognise the Cancel request. The question is now why.
Server Ubuntu, Asterisk Version built by buildd @ panlong on a i686 running Linux on 2012-10-09 20:10:53 UTC

Broken client (no To tag). The work round is to unset pedantic mode, so that it is more tolerant of broken clients.

Thanks very mucg for the fast answer. Setting pedantic=no worked perfect.
But where is the missing tag?
In the Cancel request is From: "user" <sip:user@>;tag=480132910
So “tag” is there and a To-Tag is also there

One last question to pedantic=no mode: Why do I have to set it twice? Once in [general] and in [user] extension section in sip.conf? Only when both are set it works.

Yes. The To tag in the Cancel.

You should only need to set it in general. There is no internal flag for it at other than the global level.

I tried it twice pedantic=no must be in both sections.

What is missing in the Cancel request because there is a “To” tag?

There is a [color=#FF0000]To[/color] header, but it has no [color=#FF0000]tag[/color]. The tag is highlighted in the following:

To: sip:**610@[color=#FF0000];tag=as22f0886f[/color]

Even in HTML, most people use tag incorrectly (e.g. to mean element or attribute) so maybe it is not surprising that they confuse header and tag.

Actually, I think this may be an Asterisk bug. The tagging of the CANCEL should match the original request, so it looks like it should not take account of tags received on intermediate responses. If I read RFC 3261 correctly, pedantic mode should be rejecting any To tag!

Unfortunately, you are a long way behind the current version. You would really need to confirm the problem in or later before raising a bug report.