Asterisk creating a second sip invite while only one is expected

I facing a problem with Asterisk 13.38.2, and hope someone can help me. When my Asterisk receives a sip invite and then dial to extension (like Dial(SIP/103)) it works as expected, generating only one invite to extension 103.

When the same DID is routed to a queue, then Asterisk creates two sip invites (one for the extension as expected and another to the caller contact address).

This only happens with a specific provider, so I think it might be caused by some INVITE parameter.

Any idea why the last invite is created?

asterisk -rx “queue show 600”:

600 has 0 calls (max unlimited) in 'linear' strategy (0s holdtime, 0s talktime), W:0, C:0, A:0, SL:0.0% within 60s
Members: 
      Local/103@test-queue (ringinuse enabled) (dynamic) (Not in use) has taken no calls yet
   No Callers

This is my test dial plan:

# extension dial context
[test-queue]
exten => _X.,1,Dial(SIP/103)

# incoming context
[test-int]
exten => s,1,Answer()
same => n,Queue(600)

These are the invites:

# Invite received by Asterisk
INVITE sip:+2020202020@1.1.1.180:5060 SIP/2.0
Record-Route: <sip:1.1.1.18:5060;r2=on;lr;ftag=p65540t1617838888m773513c7005s1_2017909308-538403679>
Record-Route: <sip:1.1.1.18;transport=tcp;r2=on;lr;ftag=p65540t1617838888m773513c7005s1_2017909308-538403679>
Via: SIP/2.0/UDP 1.1.1.18:5060;branch=z9hG4bK4b8e.e54a976359c351d06657262d335cf2ea.0;i=1
Via: SIP/2.0/TCP 1.1.1.38:5060;branch=z9hG4bKkitt7g10305hb5b2mao0.1
To: <sip:+2020202020@1.1.1.180;user=phone>
From: sip:+90909090@1.1.1.18;user=phone;tag=p65540t1617838888m773513c7005s1_2017909308-538403679
Call-ID: p65540t1617838888m773513c7005s2
CSeq: 1 INVITE
Max-Forwards: 65
Content-Length: 1060
Contact: <sip:p65540t1617838888m773513c7005s1@1.1.1.38:5060;transport=tcp>
Content-Type: application/sdp
Allow: REGISTER, REFER, NOTIFY, SUBSCRIBE, PRACK, UPDATE, INVITE, ACK, OPTIONS, CANCEL, BYE
Accept: application/sdp
Accept-Contact: xxxxxxxxxxxxxxxxx
Supported: timer, 100rel, histinfo
P-Asserted-Identity: <sip:+90909090@1.1.1.38;cpc=ordinary>
History-Info: <sip:+2020202020@ims2xxxxxxxx;user=phone>;index=1
History-Info: <sip:+2020202020@ims2xxxxxxxx;cause=302;user=phone>;index=1.1
Min-SE: 900
Session-Expires: 1800
P-Charging-Vector: icid-value=mOTin606e4328d92c500100001b5d;icid-generated-at=ssdfd.xxxx.xxx.xx;orig-ioi=xxxx.xxx.xx;orig-icid=13212312131231
P-Early-Media: supported
Session-ID: a3a86bb42ac1e8c58592a9663bbd5ed5

# Invite sent to extension (correct)
INVITE sip:aguc9dt7@dachr2hc3gfe.invalid;transport=ws SIP/2.0
Via: SIP/2.0/WS 1.1.1.180:5060;branch=z9hG4bK544ff0c7;rport
Max-Forwards: 70
From: "+90909090" <sip:+90909090@1.1.1.180>;tag=as185ed728
To: <sip:aguc9dt7@dachr2hc3gfe.invalid;transport=ws>
Contact: <sip:+90909090@1.1.1.180:5060;transport=ws>
Call-ID: 5ece1d376d522a03461cb9671f6af1ec@1.1.1.180:5060
CSeq: 102 INVITE
Date: Wed, 07 Apr 2021 23:41:33 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 794

# No idea why Dial(SIP/103) created this invite!
INVITE sip:p65540t1617838888m773513c7005s1@1.1.1.38:5060;transport=tcp SIP/2.0
Via: SIP/2.0/UDP 1.1.1.180:5060;branch=z9hG4bK77194dbb
Route: <sip:1.1.1.18:5060;r2=on;lr;ftag=p65540t1617838888m773513c7005s1_2017909308-538403679>,<sip:1.1.1.18;transport=tcp;r2=on;lr;ftag=p65540t1617838888m773513c7005s1_2017909308-538403679>
Max-Forwards: 70
From: <sip:+2020202020@1.1.1.180;user=phone>;tag=as7a03d243
To: sip:+90909090@1.1.1.18;user=phone;tag=p65540t1617838888m773513c7005s1_2017909308-538403679
Contact: <sip:+2020202020@1.1.1.180:5060>
Call-ID: p65540t1617838888m773513c7005s2
CSeq: 102 INVITE
Session-Expires: 1800;refresher=uac
Min-SE: 90
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
P-Asserted-Identity: "Test" <sip:103@1.1.1.18>
Content-Type: application/sdp
Content-Length: 614

There may be an incorrect assumption that Asterisk is a proxy and simply forwards INVITEs.

The second INVITE is a re-INVITE, which modifies an existing session. If it is immediate, it is being send to update the caller with the actual connected line information, or to specify a direct media path (unfortunately you deleted the SDP, and the entire 200 OK response). If it is delayed, it is being sent to refresh the session timeout.

The caller has sent Session-Expires, so it must be prepared for the latter, and it has used P-Asserted-Identity itself, so it presumably understands that, even if it choose to ignore it. If it is a direct media update, the chances are that the provider won’t like that, and you have misconfigured your direct media setting (also known by obsolete the name canreinvite in the deprecated chan_sip driver).

chan_sip is scheduled for removal in the near future, and Asterisk 13, is in its lame duck period, before end of life, in October, and only receives security fixes.

Thank you for all the information @david551 !
As I am not used to analyze SIP flow, I couldn’t figure out the reason for this re-inivite. It is immediate.

Here is the complete information:

invite carrier → asterisk

Via: SIP/2.0/UDP 1.1.1.18;branch=z9hG4bKsr-u1iP3coD6ENuPjI768PQ3wtS6UQ568uD6c7JF8Ig6CWurCjbxn9f9lpL0qFkBnkTxtm19bWLmw.G9cmS6-HlFCZV0wFRFMHq6EQ5
To: sip:+20202020@1.1.1.180;user=phone
From: sip:+92929292@1.1.1.18;user=phone;tag=p65540t1618166553m581242c6803s1_3265208993-1853517772
Call-ID: mC9jF8PO.Ctg6875Fw9jF8FWF8756wPS9c9Q6CFc67**
CSeq: 1 INVITE
Max-Forwards: 65
Content-Length: 1061
Contact: sip:1.1.1.18;line=sr-mgiOhlIgF8u16vP5FwtQ689gF8uc08uQ68o16q6ghCIcmcHI68PQ3wtS6UQ568uD6c7JF8Ig6CW1mqHDmMzYmlPN.-FO
Content-Type: application/sdp
Allow: REGISTER, REFER, NOTIFY, SUBSCRIBE, PRACK, UPDATE, INVITE, ACK, OPTIONS, CANCEL, BYE
Accept: application/sdp
Accept-Contact: *;+g.3gpp.icsi-ref=“urn%3Aurn-7%3A3gpp”
Supported: timer, 100rel, histinfo
P-Asserted-Identity: sip:+92929292@1.1.1.38;cpc=ordinary
History-Info: sip:+20202020@ims2carrier.com;user=phone;index=1
History-Info: sip:+02020202@ims2carrier.com;cause=302;user=phone;index=1.1
Min-SE: 900
Session-Expires: 1800
P-Charging-Vector: icid-value=mOTin60734319abc68a93;icid-generated-at=mta002-frc2;orig-ioi=lll;orig-icid=E1A5-0411-20423304
P-Early-Media: supported
Session-ID: 4fe14c4041c264c458c54466d7b341da

v=0
o=- 1895837702 3762494695 IN IP4 1.1.1.206
s=-
c=IN IP4 1.1.1.206
t=0 0
m=audio 11762 RTP/AVP 8 97 98 99 100 101 102 9 104 103
c=IN IP4 1.1.1.18
b=RR:3000
b=RS:1000
a=maxptime:40
a=rtpmap:8 PCMA/8000
a=rtpmap:97 AMR/8000
a=fmtp:97 mode-set=0,2,4,7;mode-change-period=2;mode-change-capability=2;mode-change-neighbor=1;max-red=0
a=rtpmap:98 AMR/8000
a=fmtp:98 mode-set=0,2,4,7;mode-change-period=2;mode-change-capability=2;mode-change-neighbor=1;max-red=0;octet-align=1
a=rtpmap:99 AMR/8000
a=fmtp:99 mode-set=7;max-red=0
a=rtpmap:100 AMR/8000
a=fmtp:100 mode-set=7;max-red=0;octet-align=1
a=rtpmap:101 AMR-WB/16000
a=fmtp:101 mode-set=0,1,2;mode-change-period=2;mode-change-capability=2;mode-change-neighbor=1;max-red=0
a=rtpmap:102 AMR-WB/16000
a=fmtp:102 mode-set=0,1,2;mode-change-period=2;mode-change-capability=2;mode-change-neighbor=1;max-red=0;octet-align=1
a=rtpmap:9 G722/8000
a=rtpmap:104 telephone-event/8000
a=fmtp:104 0-15
a=rtpmap:103 telephone-event/16000
a=fmtp:103 0-15
a=sendrecv
a=rtcp:11763

200 ok asterisk → carrier

SIP/2.0 200 OK
Via: SIP/2.0/UDP 1.1.1.18:5060;branch=z9hG4bKda6e.5265f6afe96d5c38b5994afd25ecafa2.0;i=1;received=1.1.1.18
Via: SIP/2.0/UDP 1.1.1.18;branch=z9hG4bKsr-u1iP3coD6ENuPjI768PQ3wtS6UQ568uD6c7JF8Ig6CWurCjbxn9f9lpL0qFkBnkTxtm19bWLmw.G9cmS6-HlFCZV0wFRFMHq6EQ5
Record-Route: sip:1.1.1.18:5060;r2=on;lr;ftag=p65540t1618166553m581242c6803s1_3265208993-1853517772
Record-Route: sip:1.1.1.18;line=sr-mgiOhwtTFEQSFCoD68tD687f.vpL0lFO0Mp1BnXwmCWS6wjY0wWRmwWq.-HlBnIgF8u16vP5FwtQ689gF8uc08uQ68o16q6ghCIcmcHa6cogF8oOhCbT6S15hCucF8tMFcmS
From: sip:+92929292@1.1.1.18;user=phone;tag=p65540t1618166553m581242c6803s1_3265208993-1853517772
To: sip:+20202020@1.1.1.180;user=phone;tag=as2023ca77
Call-ID: mC9jF8PO.Ctg6875Fw9jF8FWF8756wPS9c9Q6CFc67**
CSeq: 1 INVITE
Server: ITSP
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Session-Expires: 1800;refresher=uas
Contact: sip:+20202020@1.1.1.180:5060
Content-Type: application/sdp
Require: timer
Content-Length: 616

v=0
o=Agent 1020137968 1020137968 IN IP4 1.1.1.180
s= ITSP
c=IN IP4 1.1.1.180
t=0 0
m=audio 26860 RTP/AVP 8 104
a=rtpmap:8 PCMA/8000
a=rtpmap:104 telephone-event/8000
a=fmtp:104 0-16
a=ptime:20
a=maxptime:150
a=ice-ufrag:222beb10191e99dd63024a482a922001
a=ice-pwd:33263afb1f02e93a4c9fe2ff20b27d30
a=candidate:Hb22000b4 1 UDP 2130706431 1.1.1.180 26860 typ host
a=candidate:Ha050001 1 UDP 2130706431 10.5.0.1 26860 typ host
a=candidate:Hb22000b4 2 UDP 2130706430 1.1.1.180 26861 typ host
a=candidate:Ha050001 2 UDP 2130706430 10.5.0.1 26861 typ host
a=rtcp-mux
a=sendrecv

re-invite asterisk → carrier

INVITE sip:1.1.1.18;line=sr-mgiOhlIgF8u16vP5FwtQ689gF8uc08uQ68o16q6ghCIcmcHI68PQ3wtS6UQ568uD6c7JF8Ig6CW1mqHDmMzYmlPN.-FO SIP/2.0
Via: SIP/2.0/UDP 1.1.1.180:5060;branch=z9hG4bK7d091827
Route: sip:1.1.1.18:5060;r2=on;lr;ftag=p65540t1618166553m581242c6803s1_3265208993-1853517772,<sip:1.1.1.18;line=sr-mgiOhwtTFEQSFCoD68tD687f.vpL0lFO0Mp1BnXwmCWS6wjY0wWRmwWq.-HlBnIgF8u16vP5FwtQ689gF8uc
uQ68o16q6ghCIcmcHa6cogF8oOhCbT6S15hCucF8tMFcmS>
Max-Forwards: 70
From: sip:+20202020@1.1.1.180;user=phone;tag=as2023ca77
To: sip:+92929292@1.1.1.18;user=phone;tag=p65540t1618166553m581242c6803s1_3265208993-1853517772
Contact: sip:+20202020@1.1.1.180:5060
Call-ID: mC9jF8PO.Ctg6875Fw9jF8FWF8756wPS9c9Q6CFc67**
CSeq: 102 INVITE
User-Agent: ITSP
Session-Expires: 1800;refresher=uac
Min-SE: 90
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
P-Asserted-Identity: “Test” sip:100@1.1.1.18
Content-Type: application/sdp
Content-Length: 616

v=0
o=Agent 1020137968 1020137969 IN IP4 1.1.1.180
s= ITSP
c=IN IP4 1.1.1.180
t=0 0
m=audio 26860 RTP/AVP 8 104
a=rtpmap:8 PCMA/8000
a=rtpmap:104 telephone-event/8000
a=fmtp:104 0-16
a=ptime:20
a=maxptime:150
a=ice-ufrag:222beb10191e99dd63024a482a922001
a=ice-pwd:33263afb1f02e93a4c9fe2ff20b27d30
a=candidate:Hb22000b4 1 UDP 2130706431 1.1.1.180 26860 typ host
a=candidate:Ha050001 1 UDP 2130706431 10.5.0.1 26860 typ host
a=candidate:Hb22000b4 2 UDP 2130706430 1.1.1.180 26861 typ host
a=candidate:Ha050001 2 UDP 2130706430 10.5.0.1 26861 typ host
a=rtcp-mux
a=sendrecv

Do know the possible reason for this re-inivite?

Assuming 1.1.1.180 always represents the same address, I’d say it was to send this update to the connected line information:

It is also sending new SDP, but there don’t seem to be any material changes, other than the serial number, so I assume it is a feature that it is being sent as updated SDP.

You may want to read Manipulating Party ID Information - Asterisk Project - Asterisk Project Wiki

Right. What I can’t understand is the fact that it only happens for incomings calls from a specific carrier, and when using Queue() followed by Dial(). If the incoming call goes direct to Dial() application, then the re-invite isn’t created : /