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:mayamatake...@gmail.com]
Sent: Thursday, August 18, 2011 8:14 PM
To: Corcione, John
Cc: sipp-users@lists.sourceforge.net
Subject: Re: [Sipp-users] Entering DTMF in the SIPP Scenario PLEASE READ
On Fri, Aug 19, 2011 at 5:13 AM, Corcione, John
<john.corci...@hrblock.com<mailto:john.corci...@hrblock.com>> 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
------------------------------------------------------------------------------
Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
user administration capabilities and model configuration. Take
the hassle out of deploying and managing Subversion and the
tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
_______________________________________________
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users
