Hi,
I have seen case where some kind of IVR accepts only telephone-event if
media type is 101. We had to add more codecs in our gateway on that trunk so
that tele-events were always offered as 101.
In our case we tried this after traced calls in and from IVR and in IVR
messages sdp tele-events were offered mediatype 101.
BR Tomi
On Aug 19, 2011 6:07 PM, <sipp-users-requ...@lists.sourceforge.net> wrote:
> Send Sipp-users mailing list submissions to
> sipp-users@lists.sourceforge.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.sourceforge.net/lists/listinfo/sipp-users
> or, via email, send a message with subject or body 'help' to
> sipp-users-requ...@lists.sourceforge.net
>
> You can reach the person managing the list at
> sipp-users-ow...@lists.sourceforge.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Sipp-users digest..."
>
>
> Today's Topics:
>
> 1. Re: Entering DTMF in the SIPP Scenario PLEASE READ
> (Patrick Wakano)
> 2. Re: Entering DTMF in the SIPP Scenario PLEASE READ (mayamatakeshi)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 19 Aug 2011 11:55:15 -0300
> From: Patrick Wakano <pwak...@gmail.com>
> Subject: Re: [Sipp-users] Entering DTMF in the SIPP Scenario PLEASE
> READ
> To: "Corcione, John" <john.corci...@hrblock.com>
> Cc: "sipp-users@lists.sourceforge.net"
> <sipp-users@lists.sourceforge.net>
> Message-ID:
> <CAPu3kNWyQaP7eU1C7RA43ub=wyhwwa0aq9eqyq8_bdaqi3h...@mail.gmail.com>
> Content-Type: text/plain; charset="windows-1252"
>
> Study this example:
> http://sipp.sourceforge.net/doc/uac_pcap.xml.html
> I think it has everything you need.
> It sends out of band DTMF digit using G711 a-law and you can adapt to your
> case
> Don't go for DTMF in INFO unless this is what you want to test. DTMF in
INFO
> is not a very common practice, prefer out of band DTMF as RC2833.....
>
>
>
> On Fri, Aug 19, 2011 at 11:29 AM, Corcione, John
> <john.corci...@hrblock.com>wrote:
>
>> 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>
>> 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
>>
>>
> -------------- next part --------------
> An HTML attachment was scrubbed...
>
> ------------------------------
>
> Message: 2
> Date: Sat, 20 Aug 2011 00:07:40 +0900
> From: mayamatakeshi <mayamatake...@gmail.com>
> Subject: Re: [Sipp-users] Entering DTMF in the SIPP Scenario PLEASE
> READ
> To: "Corcione, John" <john.corci...@hrblock.com>
> Cc: "sipp-users@lists.sourceforge.net"
> <sipp-users@lists.sourceforge.net>
> Message-ID:
> <CABaNFCaA9_qw=3jhWOtwNnWNUZ=pcgflughqyodn2jh4agr...@mail.gmail.com>
> Content-Type: text/plain; charset="windows-1252"
>
> On Fri, Aug 19, 2011 at 11:29 PM, Corcione, John
> <john.corci...@hrblock.com>wrote:
>
>> Mayama,****
>>
>> ** **
>>
>> This is my invite to the IVR Platform ? How is SIP INFO used in this
case.
>>
>
> INFO is just a request like RE-INVITE, UPDATE, BYE. So after the call is
> answered, you could send INFO requests inside the call. But of course this
> depends if the UAS can handle this.
>
>
>> And how do I force the IVR to accept the codec?
>>
>
> If you offer just one codec in the SDP, then I think a well behaving UAS
> would:
> - accept the call using that codec
> - refuse the call with something like "488 Not Acceptable Here"
>
> I am not sure about the above because i don't spend much time reading the
> SIP RFCs, but I believe this is the expected behavior from the tests I do
> with actual equipment (however, I remember once I tested with with a PBX
by
> sending the single codec set to speex, but speex was disabled in the pbx
and
> it decided to answer with PCMU).
> Anyway, you can always use a regex to check if the UAS selected the codec
> you expected or to act differently depending of the codec selected (like
> playing a different file. But as I said, mostly, if you force the UAS to
use
> the codec that is present in the pcap file, you don't have to bother
> yourself with this).
>
>
>> Should I also add a line to the a=rtpmap: for G711 as well?
>>
>
> No. G711 is a static payload and doesn't require rtpmap.
> What you have to do is:
> Decide if you are going to interact using in-band DTMF (digits sent as
> audio in the voice stream) or out-of-band DTMF (special RTP packets as
> defined in RFC2833).
> If you decide to use in-band DTMF, then get a packet capture with the
> digits you need to send in the codec that you are going to use, then
adjust
> the SDP to only offer that codec and to not offer codec telephone-event
> (this is RFC2833).
> If you decide to use out-of-band DTMF, then get a packet capture with the
> digits being sent using RFC2833, offer a single codec like PCMU and also
> offer codec telephone-event.
>
>
>
>> ****
>>
>> ** **
>>
>> 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
>>
>
> Assuming that you are using in-band DTMF:
> In the above, just offer a single codec like this:
>
> m=audio [media_port] RTP/AVP 0
>
> (if you decide for 18, take note that G729 doesn't transmit DTMF
reliably).
>
>
>> ****
>>
>> a=rtpmap:18 G729/8000****
>>
>> a=rtpmap:2 G726-32/8000****
>>
>> a=rtpmap96 telephone-event/8000
>>
>
> Remove the above line if you are using in-band DTMF as some UAs will
ignore
> in-band DTMF if codec telephone-event is offered.
> -------------- next part --------------
> An HTML attachment was scrubbed...
>
> ------------------------------
>
>
------------------------------------------------------------------------------
> 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
>
>
> End of Sipp-users Digest, Vol 63, Issue 6
> *****************************************
------------------------------------------------------------------------------
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
