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.
------------------------------------------------------------------------------
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
