DTMF digit with SIPP test - sip

I am trying to send the DTMF digits through sipp to IVR application
This is my sip xml and works good except action part...
Call is successful but DTMF digit 1 is not received. It is showing that digit received as null..not getting the actual problem is there any configuration for this pcap ?or anytthing problem with the script?
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE scenario SYSTEM "sipp.dtd">
<scenario name="UAC with media">
<send retrans="500">
<![CDATA[
INVITE sip:[field0]#[remote_ip]:[remote_port] SIP/2.0
Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
From: sipp <sip:[field1]#[local_ip]:[local_port]>;tag=[call_number]
To: sut <sip:[field0]#[remote_ip]:[remote_port]>
Call-ID: [call_id]
CSeq: 1 INVITE
Contact: sip:[field1]#[local_ip]:[local_port]
Max-Forwards: 70
Subject: Performance Test
Content-Type: application/sdp
Content-Length: [len]
v=0
o=user1 53655765 2353687637 IN IP[local_ip_type] [local_ip]
s=-
c=IN IP[local_ip_type] [local_port]
t=0 0
m=audio [auto_media_port] RTP/AVP 96 0 9 8 101 13
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-1
]]>
</send>
<recv response="100" optional="true">
</recv>
<recv response="183" optional="true">
</recv>
<recv response="200">
</recv>
<![CDATA[
ACK sip:[field0]#[remote_ip]:[remote_port] SIP/2.0
Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
From: sipp <sip:[field1]#[local_ip]:[local_port]>;tag=[call_number]
To: sut <sip:[field0]#[remote_ip]:[remote_port]>[peer_tag_param]
Call-ID: [call_id]
CSeq: 1 ACK
Contact: sip:sipp#[local_ip]:[local_port]
Max-Forwards: 70
Subject: Performance Test
Content-Length: 0
]]>
</send>
<pause milliseconds="5000"/>
<nop>
<action>
<exec play_pcap_audio="pcap/dtmf_2833_1.pcap"/>
</action>
</nop>
<pause milliseconds="2000"/>
<recv request="BYE"> </recv>
<send>
<![CDATA[
SIP/2.0 200 OK sip:[service]#[remote_ip]:[remote_port] SIP/2.0
Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
From: sipp <sip:[field]#[local_ip]:[local_port]>;tag=[call_number]
To: sut <sip:[service]#[remote_ip]:[remote_port]>[peer_tag_param]
Call-ID: [call_id]
CSeq: 1 INVITE
Contact: sip:sipp[call_number]#[local_ip]:[local_port]
Max-Forwards: 70
Subject: Performance Test
Content-Length: 0
]]>
</send>
<ResponseTimeRepartition value="10, 20, 30, 40, 50, 100, 150, 200"/>

Actually you have in your script an explicit request to negotiate dtmf in-band using
RTP events :
m=audio [auto_media_port] RTP/AVP 96 0 9 8 101 13
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-1
The peer has accepted you offer I assume and is waiting dtmf as a rtp event packet; you should be able to send a pcap with an rtp event or if not switch to sip notify or info.
This mode is documented in RFC 2833 first and updated by rfc5244.

You have multiple ways of sending DTMF
In-band: where the tone is sent mixed in the audio stream (what you are trying to do)
Out-of-band: in a separate SIP message like SIP INFO or SIP NOTIFY, which are basically messages saying "DTMF 1 was pressed" without putting it in the audio stream. Much easier for an IVR programmer, and more reliable.
The out-of-band method has become so commonplace, that many vendors will not bother turning on their in-band detectors by default. You may want to search for a configuration setting named like "In-band DTMF detection" or "DTMF recognizer" ...
Of course, I don't know the system you are using so "digit received as null" may mean:
"nothing received", possibly meaning the in-band detector is not enabled
"something received but could not understand it", possibly meaning something wrong with your audio file content OR transmission of that content
Since it's SIP-to-SIP I would recommend switching to an out-of-band dtmf message.

Related

Process INVITES when recording is enabled on both parties phones in Cisco CUCM

I am using jain-sip to implement a sip server to process call events and then record the calls in Cisco CUCM. It works fine when a call is made from a recording-enabled phone to a recording-disabled phone or vice versa. I receive two INVITES one for each far-end and near-end phone.
But when a call is made between two phones where recording is enabled on both phones (think internal call), I receive four invites and there is no way of differentiating between far-end and near-end and no way of knowing which invites to process and which to ignore. Both phones send two invites, one for itself and one for the other phone. When call is ended, four BYEs are sent.
What is the proper way of handling this situation?
below are the four invites;
INVITE sip:88888#192.168.1.x.x:5060 SIP/2.0
Via: SIP/2.0/TCP 192.168..x.x:5060;branch=z9hG4bK2095e06f3b8;rport=58747
From: <sip:2400#192.168..x.x;x-nearend;x-refci=27425142;x-nearendclusterid=BR-Cluster2;x-nearenddevice=SEPD0C282D15AAF;x-nearendaddr=2400;x-farendrefci=27425141;x-farendclusterid=BR-Cluster2;x-farenddevice=sikander1;x-farendaddr=2701>;tag=519~00d3be95-408b-41c6-90cf-01ef66258892-27425149
To: <sip:88888#192.168.1.124>
Date: Mon, 09 Nov 2020 07:13:13 GMT
Call-ID: 6649000-fa81ec09-1f6-3001a8c0#192.168..x.x
Supported: timer,resource-priority,replaces,X-cisco-srtp-fallback,Geolocation
Min-SE: 120
User-Agent: Cisco-CUCM11.5
Allow: INVITE,OPTIONS,INFO,BYE,CANCEL,ACK,PRACK,UPDATE,REFER,SUBSCRIBE,NOTIFY
CSeq: 101 INVITE
Expires: 180
Allow-Events: presence,kpml
Call-Info: <sip:192.168..x.x:5060>;method="NOTIFY;Event=telephone-event;Duration=500"
Session-ID: 00000000000000000000000000000000;remote=00000000000000000000000000000000
Cisco-Guid: 0107253760-0000065536-0000000011-0805415104
Session-Expires: 120
P-Asserted-Identity: <sip:2400#192.168..x.x>
Remote-Party-ID: <sip:2400#192.168..x.x>;party=calling;screen=yes;privacy=off
Contact: <sip:2400#192.168..x.x:5060;transport=tcp>;isFocus
Max-Forwards: 70
Content-Length: 0
-----------------------------------------
INVITE sip:88888#192.168.x.x:5060 SIP/2.0
Via: SIP/2.0/TCP 192.168.x.x:5060;branch=z9hG4bK20a2071bec;rport=58747
From: <sip:2701#192.168.x.x;x-nearend;x-refci=27425141;x-nearendclusterid=BR-Cluster2;x-nearenddevice=sikander1;x-nearendaddr=2701;x-farendrefci=27425142;x-farendclusterid=BR-Cluster2;x-farenddevice=SEPD0C282D15AAF;x-farendaddr=2400>;tag=520~00d3be95-408b-41c6-90cf-01ef66258892-27425150
To: <sip:88888#192.168..x.x>
Date: Mon, 09 Nov 2020 07:13:13 GMT
Call-ID: 6649000-fa81ec09-1f7-3001a8c0#192.168..x.x
Supported: timer,resource-priority,replaces,X-cisco-srtp-fallback,Geolocation
Min-SE: 120
User-Agent: Cisco-CUCM11.5
Allow: INVITE,OPTIONS,INFO,BYE,CANCEL,ACK,PRACK,UPDATE,REFER,SUBSCRIBE,NOTIFY
CSeq: 101 INVITE
Expires: 180
Allow-Events: presence,kpml
Call-Info: <sip:192.168..x.x:5060>;method="NOTIFY;Event=telephone-event;Duration=500"
Session-ID: 00000000000000000000000000000000;remote=00000000000000000000000000000000
Cisco-Guid: 0107253760-0000065536-0000000012-0805415104
Session-Expires: 120
P-Asserted-Identity: <sip:2701#192.168..x.x>
Remote-Party-ID: <sip:2701#192.168.1.x.x>;party=calling;screen=yes;privacy=off
Contact: <sip:2701#192.168.x.x:5060;transport=tcp>;isFocus
Max-Forwards: 70
Content-Length: 0
-------------------------
INVITE sip:88888#192.168..x.x:5060 SIP/2.0
Via: SIP/2.0/TCP 192.168..x.x:5060;branch=z9hG4bK20b5eb383e9;rport=58747
From: <sip:2400#192.168..x.x;x-farend;x-refci=27425142;x-nearendclusterid=BR-Cluster2;x-nearenddevice=SEPD0C282D15AAF;x-nearendaddr=2400;x-farendrefci=27425141;x-farendclusterid=BR-Cluster2;x-farenddevice=sikander1;x-farendaddr=2701>;tag=521~00d3be95-408b-41c6-90cf-01ef66258892-27425155
To: <sip:88888#192.168..x.x>
Date: Mon, 09 Nov 2020 07:13:13 GMT
Call-ID: 6649000-fa81ec09-1f8-3001a8c0#192.168..x.x
Supported: timer,resource-priority,replaces,X-cisco-srtp-fallback,Geolocation
Min-SE: 120
User-Agent: Cisco-CUCM11.5
Allow: INVITE,OPTIONS,INFO,BYE,CANCEL,ACK,PRACK,UPDATE,REFER,SUBSCRIBE,NOTIFY
CSeq: 101 INVITE
Expires: 180
Allow-Events: presence,kpml
Call-Info: <sip:192.168..x.x:5060>;method="NOTIFY;Event=telephone-event;Duration=500"
Session-ID: 00000000000000000000000000000000;remote=00000000000000000000000000000000
Cisco-Guid: 0107253760-0000065536-0000000013-0805415104
Session-Expires: 120
P-Asserted-Identity: <sip:2400#192.168.x.x>
Remote-Party-ID: <sip:2400#192.168..x.x>;party=calling;screen=yes;privacy=off
Contact: <sip:2400#192.168..x.x:5060;transport=tcp>;isFocus
Max-Forwards: 70
Content-Length: 0
-------------------------
INVITE sip:88888#192.168.1.124:5060 SIP/2.0
Via: SIP/2.0/TCP 192.168..x.x:5060;branch=z9hG4bK20c2f880eb2;rport=58747
From: <sip:2701#192.168..x.x;x-farend;x-refci=27425141;x-nearendclusterid=BR-Cluster2;x-nearenddevice=sikander1;x-nearendaddr=2701;x-farendrefci=27425142;x-farendclusterid=BR-Cluster2;x-farenddevice=SEPD0C282D15AAF;x-farendaddr=2400>;tag=522~00d3be95-408b-41c6-90cf-01ef66258892-27425156
To: <sip:88888#192.168.1.124>
Date: Mon, 09 Nov 2020 07:13:13 GMT
Call-ID: 6649000-fa81ec09-1f9-3001a8c0#192.168..x.x
Supported: timer,resource-priority,replaces,X-cisco-srtp-fallback,Geolocation
Min-SE: 120
User-Agent: Cisco-CUCM11.5
Allow: INVITE,OPTIONS,INFO,BYE,CANCEL,ACK,PRACK,UPDATE,REFER,SUBSCRIBE,NOTIFY
CSeq: 101 INVITE
Expires: 180
Allow-Events: presence,kpml
Call-Info: <sip:192.168..x.x:5060>;method="NOTIFY;Event=telephone-event;Duration=500"
Session-ID: 00000000000000000000000000000000;remote=00000000000000000000000000000000
Cisco-Guid: 0107253760-0000065536-0000000014-0805415104
Session-Expires: 120
P-Asserted-Identity: <sip:2701#192.168..x.x>
Remote-Party-ID: <sip:2701#192.168..x.x>;party=calling;screen=yes;privacy=off
Contact: <sip:2701#192.168..x.x:5060;transport=tcp>;isFocus
Max-Forwards: 70
Content-Length: 0
I guess in general the idea would be to potentially record all 4 call legs - i.e. both sides of the 'same' call. An example might be software that analyzes the voice quality experienced by each party when both are recorded, in case one experiences RTP flow issues or other anomalies. Codec differences or transcoding may cause one 'version' of the same 2-party call to sound better/worse (or have larger storage requirements).
If you don't care about the RTP data at that level, you may need to check the x-refci and other From: fields, so you can 'de-dupe' them during or after the fact...

Cannot send RTP by SIPp tool

I am trying to replay an captured pcap file with sipp as follows:
In Sending.xml
...
<recv response="200" rrs="true">
<action>
<ereg regexp="(.*)" search_in="hdr" header="To:" assign_to="TO_REQUEST"/>
</action>
</recv>
<send >
<![CDATA[
ACK [next_url] SIP/2.0
To: [$TO_REQUEST]
From: [$FROM_REQUEST]
Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
Call-ID: [call_id]
CSeq: [last_cseq_number] ACK
Contact: <sip:[local_ip]:[local_port]>
[routes]
Max-Forwards: 70
Subject: Performance Test
Content-Length: 0
]]>
</send>
<nop>
<action>
<exec play_pcap_audio="pcap/g711a.pcap"/>
</action>
</nop>
...
However, I always get the same error:
extract_rtp_remote_addr: no IP address found in SDP message body.
I tried to test with other *.pcap and *.raw files and edit my script but I still cannot.
When I only send the signal not RTP, the call is successful.
Anyone can help me send RTP by SIPp?
Thanks in advance!
I recall I had similar issues with that at some point due to my .pcap not being very 'clean'.
Are you sure the pcap contains just the RTP packets and nothing else?
For a working example of pcap played by sipp, you can check webrtc-test project and more specifically: .pcap and relevant sipp xml
Also notice that sipp usually only plays just one direction of the RTP media, so it's best if you have media flowing in both directions to make sure.
Hope this helps.
Best regards,
Antonis Tsakiridis
This may have to do with the SDP in your INVITE. extract_rtp_remote_addr will be looking for an IP address to send the RTP to.
Check your INVITE in the XML has the correct IP address in the c line.

i want to implement sip protocol on microcontroller i.e. using embedded c ,but i want to parse sip packets using perl or tcl

a typical sip packet looks like this
INVITE sip:bob#biloxi.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob <sip:bob#biloxi.com>
From: Alice <sip:alice#atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710#pc33.atlanta.com
CSeq: 314159 INVITE
Contact: <sip:alice#pc33.atlanta.com>
Content-Type: application/sdp
Content-Length: 142
so is it possible to embedd perl or tcl parser in c
I would use a packet sniffer in C. Then identify SIP protocol based on data, push it somewhere and parse it with Perl/TCL from there. Example:
http://www.tcpdump.org/sniffex.c, or you can build packet sniffer from Perl/TCL itself, very easy task just some considerations when handling TCP/UDP fragmentation

Asterisk API SDP Handling

I have two SIP clients ( "A" and "B" ) connected to asterisk on generic bridge mode.
"A"'s video is playing back on "B" but "B"'s video is NOT playing back on "A". I triple checked with wireshark that the media ( audio / video )
is arriving at "A"'s ip address. Audio is working well on both sides.
My best guess is that this issue is related to asterisk's internal SDP handling.
So, lets delve into the problem.
"A" sends the followind INVITE:
INVITE sip:700#192.168.7.227 SIP/2.0
Via: SIP/2.0/UDP 192.168.7.225:10074;branch=z9hG4bK-224696310;rport
From: "danflu-portsip"<sip:danflu-portsip#192.168.7.227>;tag=87652133
To: <sip:700#192.168.7.227>
Contact: <sip:danflu-portsip#192.168.7.225:10074;transport=udp>;
Call-ID: YTc0NDRjNDYtMWRhMS01MzE2LWVlNDEtYmV
CSeq: 1354707857 INVITE
Content-Type: application/sdp
Content-Length: 447
Max-Forwards: 70
Authorization: Digest username="danflu-portsip",realm="asterisk",nonce="5ac40c6d",uri="sip:700#192.168.7.227",response="fae8a78ba97 2f6cb0c76846d76f13786",algorithm=MD5
User-Agent: PortSIP SDK for IOS
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, REGISTER, SUBSCRIBE, INFO
P-Preferred-Identity: <sip:danflu-portsip#192.168.7.227>
Supported: 100rel
v=0
o=portsip 2013 678901 IN IP4 192.168.7.225
s=-
c=IN IP4 192.168.7.225
t=0 0
m=audio 20554 RTP/AVP 8 0 97 18
a=ptime:20
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:97 SPEEX/8000
a=rtpmap:18 g729/8000
a=fmtp:18 annexb=yes
a=sendrecv
a=ssrc:258325709 cname:258325709
m=video 29350 RTP/AVP 104
a=rtpmap:104 H264/90000
a=fmtp:104 profile-level-id=42801E; packetization-mode=1
a=sendrecv
a=ssrc:1956389748 cname:1956389748
and receives a "200 OK" message from Asterisk:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.7.225:10010;branch=z9hG4bK-282879312 received=192.168.7.225;
rport=10010
From: "danflu-portsip"<sip:danflu-portsip#192.168.7.227>;tag=539964865
To: <sip:9993#192.168.7.227>;tag=as1b6086b5
Call-ID: OTE4MjM3NzUtMDIzNy1mNTM1LWM3MzYtOGZ
CSeq: 1074035624 INVITE
Server: Asterisk PBX SVN-branch-1.8-r402287M
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Contact: <sip:9993#192.168.7.227:5060>
Content-Type: application/sdp
Content-Length: 375
v=0
o=root 826339596 826339596 IN IP4 192.168.7.227
s=Asterisk PBX SVN-branch-1.8-r402287M
c=IN IP4 192.168.7.227
b=CT:384
t=0 0
m=audio 9540 RTP/AVP 8 0 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv
m=video 7450 RTP/AVP 104
a=rtpmap:104 H264/90000
a=sendrecv
Note that the lines:
a=fmtp:104 profile-level-id=42801E; packetization-mode=1
and
a=ssrc:1956389748 cname:1956389748
simply disappeared in the response and I really think thats the reason the video is not working.
So, my question:
What API can I use to customize this behavior, so the lines above are not removed when Asterisk handles the SDP from both sides ?
If there is not an official API where could I look in the code for this ? So I could maybe write a patch for my specific situation ?
I looked in chan_sip.c and there is a function:
static int process_sdp(struct sip_pvt *p, struct sip_request *req, int t38action)
But I'm not sure if this SDP handling ( removing lines and the like ) is perfomed by asterisk core or by the sip channel driver.
Thanks
Asterisk video is very strange thing. Becuase asterisk not do transcoding for video codecs/streams.
Only really working mode - all video codecs are turned off and only single codec turned on on all peers.
For more info see Asterisk Video on voip-info.org

Send a user defined String within the SDP packet

is there a way to send a short user defined string from the Caller to the Callee within the SDP part of an INVITE message (in a manner like steganography)? I tried to set the string with a length of approximately 15, in the k=, p=, e=, u= field. However the Asterisk server does not accept the Invite message. For sure, I set the new length in the IP-Header and UDP-Header furthermore I calculated the new Internet checksum of the IP-Header. As well I considered the CRLF scheme and the order of the fields.
Goal is, to transport data within the SDP data from the Caller to the Callee and vice versa, when the Callee responds with the 200 OK message to the Caller.
Thank you in advance!
Message with i=111.111.111.111 which is not accepted by the Asterisk:
INVITE sip:1000#192.168.0.14 SIP/2.0
Via: SIP/2.0/UDP 192.168.11.2:6060;rport;branch=z9hG4bKGvBkM0qF4
Max-Forwards: 70
To: <sip:1000#192.168.0.14>
From: <sip:2000#192.168.0.14>;tag=SOXFP4ir
Call-ID: BEkXWRwn-1318101970419#x61.local
CSeq: 39 INVITE
Content-Length: 231
Content-Type: application/sdp
Contact: <sip:2000#192.168.11.2:6060;transport=UDP>
v=0
o=user1 1396633799 2096570444 IN IP4 192.168.11.2
s=-
i=111.111.111.111
c=IN IP4 192.168.11.2
t=0 0
m=audio 8000 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=sendrecv
Same Message but without i=111.111.111.111. This packet is accepted and the call proceeding ends successfully (with TRYING, RING 200OK)
INVITE sip:1000#192.168.0.14 SIP/2.0
Via: SIP/2.0/UDP 192.168.11.2:6060;rport;branch=z9hG4bKESGSZD1V6
Max-Forwards: 70
To: <sip:1000#192.168.0.14>
From: <sip:2000#192.168.0.14>;tag=YPPrCWLp
Call-ID: 10MpKHYD-1318102031971#x61.local
CSeq: 41 INVITE
Content-Length: 211
Content-Type: application/sdp
Contact: <sip:2000#192.168.11.2:6060;transport=UDP>
v=0
o=user1 1682420165 643979666 IN IP4 192.168.11.2
s=-
c=IN IP4 192.168.11.2
t=0 0
m=audio 8000 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=sendrecv
Actually everything looks fine. And I can not see the response. I am intercepting the packets over iptables with NFQUEUE. Then just a few strstr, memcpy etc. to alter and build the new packets. I know there are some SDP stacks/APIs but in my case the quick and dirty solution is sufficient.
Try the i= field. As stated in RFC 4566:
The "i=" field is intended to provide a free-form human-readable description of the session or the purpose of a media stream. It is not suitable for parsing by automata.
So the Asterisk server shouldn't validate that field, enabling you to put the text you want there.