I tried changing the : m=audio [media_port] RTP/AVP 0
line and still the platform is not receiving the tones. I am not sure how to apply Dmitry's patch as I don't want to mess the scripts I already have working... From: mayamatakeshi [mailto:[email protected]] Sent: Friday, August 19, 2011 10:08 AM To: Corcione, John Cc: [email protected] Subject: Re: [Sipp-users] Entering DTMF in the SIPP Scenario PLEASE READ On Fri, Aug 19, 2011 at 11:29 PM, Corcione, John <[email protected]<mailto:[email protected]>> 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.
------------------------------------------------------------------------------ uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev
_______________________________________________ Sipp-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sipp-users
