Re: [Sipp-users] Entering DTMF in the SIPP Scenario PLEASE READ

[Corcione, J. <joh...@hr...>]

Mayama,

This is my invite to the IVR Platform - How is SIP INFO used in this case.  And how do I force the IVR to accept the codec? Should I also add a line to the a=rtpmap: for G711 as well?

INVITE sip:[service]@[remote_ip]:[remote_port] SIP/2.0
Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
From: <sip:sipp@[local_ip]:[local_port]>;tag=[call_number]
To: <sip:[service]@[remote_ip]:[remote_port]>
Call-ID: [call_id]
CSeq: 1 INVITE
Supported: 100rel, replaces
Max-Forwards: 70
Accept: application/sdp
Allow: INVITE, ACK, CANCEL, OPTIONS,BYE, UPDATE, REFER, NOTIFY
Contact: <sip:sipp@[local_ip]:[local_port];transport=[transport]>
Content-Type: application/sdp
Content-Length: [len]

v=0
o=user1 53655765 2353687637 IN IP[local_ip_type] [local_ip]
s=SIP Media Capabilities
c=IN IP[media_ip_type] [media_ip]
t=0 0
m=audio [media_port] RTP/AVP 18 0 2 96
a=rtpmap:18 G729/8000
a=rtpmap:2 G726-32/8000
a=rtpmap96 telephone-event/8000
a=fmtp:96 0-15
a=fmtp:18 annexb=no
a=fmtp:96 0-15
a=maxptime:20
a=sendrecv]]>
      </send>
      <recv response="100" crlf="true" />
      <recv response="183" crlf="true" />
      <send>

From: mayamatakeshi [mailto:may...@gm...]
Sent: Thursday, August 18, 2011 8:14 PM
To: Corcione, John
Cc: sip...@li...
Subject: Re: [Sipp-users] Entering DTMF in the SIPP Scenario PLEASE READ


On Fri, Aug 19, 2011 at 5:13 AM, Corcione, John <joh...@hr...<mailto:joh...@hr...>> wrote:
I am curious to know.

XML file plays a dtmf CC# and PIN, however when my IVR telecom person checks the IVR application he advises that the Voice Portal Application log says it is not receiving any digits however the messaging in the scenario seems to be working invite 100, 183, prack , 200, 200 ack, bye etc....  Can anyone explain this?

Nothing to be surprised about: SIPp deals with SIP messages so it can only check if SIP transactions were successful. DTMF can be transmitted using RTP (in-band, out-of-band) or using SIP INFO. So assuming you are not using SIP INFO for this (as you have not mentioned it), then you are using RTP and so SIPp have no way to tell if the digits were received or not.
SIPp just offers the feature of playing a pcap file containing whatever you want but you are on your own to check if they are being properly processed by the distant-end.

To identify the problem, you need to inspect a packet capture from the IVR side.
I can imagine the following possibilities:
  - packets are not reaching the IVR (blocked UDP ports)
  - if you are using in-band DTMF, you might have negotiated one codec, but the pcap file contains packets for a different codec (for example, if you offer more than one codec in your INVITE, you must check the SDP from the IVR and play a different file depending on which codec the IVR selected). (Actually, in this case, I recommend to send just one codec in the INVITE so that the distant-end will have no choice).
  - if you are using out-of-band DTMF, the payload-type for telephone-event is mismatched (for example, you offered it as 101 and the packets in the pcap file are set as such, but the IVR answered setting it to another value like 112 and so it is discarding your packets as garbage).
  - codec negotiation is fine but you are using a codec which cannot transmit DTMF reliably.

regards,
takeshi