I am trying to send DTMFs through SIPp. Since the play_pcap_audio action was not 100% reliable, I wanted to construct SIP INFO messages to make my tests more robust, however when I send INFO packets I get 501 - Not implemented response from Asterisk.
If I set my softphone to use SIP INFO for sending DTMFs, that works fine, so I am assuming it has to do with the messages I am sending. However comparing the actual messages did not reveal any difference.
The INVITE I send:
INVITE sip:*203@192.168.200.208:5060 SIP/2.0
Via: SIP/2.0/UDP 172.17.0.2:5060;branch=z9hG4bK-234-1-7;rport
From: sipp <sip:2018005@192.168.200.208>;tag=1
To: <sip:*203@192.168.200.208:5060>
Call-ID: 1-234@172.17.0.2
CSeq: 4 INVITE
Contact: sip:2018005@172.17.0.2:5060
Authorization: //auth header omitted
Max-Forwards: 70
Allow: OPTIONS, SUBSCRIBE, NOTIFY, INVITE, ACK, CANCEL, BYE, REFER, INFO
Content-Type: application/sdp
Content-Length: 195
v=0
o=user1 53655765 2353687637 IN IP4 172.17.0.2
s=-
c=IN IP4 172.17.0.2
t=0 0
m=audio 8192 RTP/AVP 0
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
and the INFO message:
INFO sip:192.168.200.208:5060 SIP/2.0
Via: SIP/2.0/UDP 172.17.0.2:5060;branch=z9hG4bK-234-1-16
Max-Forwards: 70
Contact: <sip:2018005@172.17.0.2:5060;transport=UDP>
To: <sip:*203@192.168.200.208:5060>
From: "sipp" <sip:2018005@192.168.200.208>;tag=1
Call-ID: 1-234@172.17.0.2
CSeq: 5 INFO
User-Agent: SIPp docker
Authorization: // auth header omitted
Content-Length: 22
Signal=1
Duration=160
I have made sure it's not to do with the dtmfmode configuration in Asterisk.
One thing I noticed is when Asterisk responds to INVITE, it contains the following header:
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
I would expect INFO to be here - but again, it's the same when using the softphone and it all works.
What other areas could affect the processing of SIP INFOs?
Any help would be much appreciated on further debugging.
Turned out to be a problem with SIP dialogs.
The tags (+ a call-id) identify a dialog. After an INVITE is sent the UAS responds with an OK, sticking a remote tag to the To: field. Every subsequent request has to use the same tags (local and remote + call-id) to refer to the same dialog. This can be achieved by sticking [last_To:] into the header when using a SIPp scenario, so that we get the correct remote tag:
<send>
<![CDATA[
ACK sip:[field3]@[remote_ip]:[remote_port] SIP/2.0
Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
From: <sip:[field0]@[field1]>;tag=[call_number]
[last_To:]
Call-ID: [call_id]
CSeq: [cseq] ACK
Contact: sip:[field0]@[local_ip]:[local_port]
Max-Forwards: 10
Content-Length: 0
]]>
</send>
In the above case an ACK is sent back from the UAC and the dialog is established. Now when we send the INFO, we have to refer to the same dialog (by setting the correct tags) and it all works. Interestingly, when not setting these values properly, pjsip gives 501 Not Implemented, whereas chan_sip responds with 481 Call/Transaction Does Not Exist which is much more accurate.