Hi,
I think I have solved the problem, but I am not sure if this is even
allowed.
The documentation says
'Negotiation of various AMR optional parameters in SDP is currently not
supported. The RFC 3267 section 8.1 specifies a list of optional parameters
for AMR/AMR-WB, however, the parameters supported by the IPP codecs are
just octet-align and mode-set.'
But the INVITE message SDP contained this line for AMR WB:
Media Attribute (a): fmtp:96
mode-set=0,1,2;mode-change-period=2;mode-change-capability=2;mode-change-neighbor=1;max-red=0;octet-align=1
So in my code I have added:
...
pjmedia_codec_param param;
pjmedia_codec_mgr_get_default_param(.., ¶m);
...
//Set values for AMR-WB
pjmedia_codec_mgr_get_default_param(codec_mgr, info[0], ¶m[0]);
param[0].setting.dec_fmtp.param[0].name = pj_str("mode-set");
param[0].setting.dec_fmtp.param[0].val = pj_str("0,1,2");
param[0].setting.dec_fmtp.param[1].name = pj_str("mode-change-period");
param[0].setting.dec_fmtp.param[1].val = pj_str("2");
param[0].setting.dec_fmtp.param[2].name = pj_str("mode-change-capability");
param[0].setting.dec_fmtp.param[2].val = pj_str("2");
param[0].setting.dec_fmtp.param[3].name = pj_str("mode-change-neighbor");
param[0].setting.dec_fmtp.param[3].val = pj_str("1");
param[0].setting.dec_fmtp.param[4].name = pj_str("max-red");
param[0].setting.dec_fmtp.param[4].val = pj_str("0");
param[0].setting.dec_fmtp.param[5].name = pj_str("octet-align");
param[0].setting.dec_fmtp.param[5].val = pj_str("1");
param[0].setting.dec_fmtp.cnt = 6;
pjmedia_codec_mgr_set_default_param(codec_mgr, info[0], ¶m[0]);
...
So has IPP begun to support these other parameters? If yes, then the
documentation needs updating.
Regards,
Arjun
> I investigated a little further and found an unexpected behaviour with
> respect to the default payload format of AMR using Intel IPP. The problem
> as explained in the message below, is that while using AMR, the IMS server
> sends an immediate BYE.
>
> As per the documentation in <
> http://www.pjsip.org/pjmedia/docs/html/group__PJMED__IPP__CODEC.htm> the
> default payload type is octet-align. However in my scenario the pjsip
> client responds to the INVITE message with a 200 OK containing Media
> attribute as the following, even though the INVITE message had attribute as
> octet-align=1:
>
> a: rtpmap:96 AMR/8000
> a: fmtp:96 mode-set=0,1,2;octet-align=0
>
> Another observation is that, my client manages to send a few AMR packets to
> the MGW(kindly read the below message) which I expand on wireshark as:
>
> Adaptive Multi-Rate
> Payload decoded as RFC 3267
> 1111 .... = CMR: No mode request (15)
> Reserved != 0, wrongly encoded or not octet aligned. Decoding as
> bandwidth-efficient mode
>
> A side question here is about encoding and decoding. I believe encoding
> happens when the client sends packets and decoding when it receives.
> Correct me if I am wrong, but if I am correct why is a packet that the
> client is sending being 'decoded as bandwidth-efficient'
>
> Regards,
> Arjun
>
> ----------------------------------------------------------------------
> >
> > Message: 1
> > Date: Thu, 19 Jul 2012 16:43:19 +0300
> > From: Arjun Kamath <junnaonly@xxxxxxxxx>
> > To: pjsip at lists.pjsip.org
> > Subject: IMS sending immediate BYE when Intel IPP AMR codec
> > used
> > Message-ID:
> > <
> > CADzHbEWSgFENhaMVHqXLXu7TPYSCC61_hRyJ2v-ZSw9NaaXZtg at mail.gmail.com>
> > Content-Type: text/plain; charset="iso-8859-1"
> >
> > Hi all,
> >
> > I am developing a VoIP client for Windows using VS2008. I have purchased
> > the Intel IPP package and have added and linked the codecs properly(with
> > some trouble I might add). When I use 2 instances of the client on my PC
> > and make calls using AMR its working fine.
> >
> > The error scenario is that I receive a call from the IMS server to which
> I
> > am already registered. The media is handled by the MGW(Kindly check the
> > below message diagram):
> >
> >
> >
> IMS-------------------------------------(INVITE)------------------------------->Client
> >
> IMS<-------------------------------(100_Trying)-------------------------------Client
> >
> MGW<-------------------(RTCP-Recvr-Report)----------------------------Client
> >
> IMS<--------------------------------(200_OK)----------------------------------Client
> > MGW<-------------------(AMR-WB-packet)
> ------------------------------Client
> >
> IMS-------------------------------------(ACK)---------------------------------->Client
> >
> IMS-------------------------------------(BYE)---------------------------------->Client(Reason:Q.850;cause=111[Protocol
> Error, unspecified])
> >
> IMS<--------------------------------(200_OK)----------------------------------Client
> > MGW<--------------(RTCP-Sender-Rep-Goodbye) --------------------Client
> >
> > The problem I see immediately is that the MGW is not sending me any
> > packets, which it should and does when I use PCMU/A codec. With PCMA, the
> > MGW sends me both RTCP and PCMA RTP packets without any problems. So for
> > some reason, on using the Intel IPP codecs, the MGW stops liking my
> client.
> > This is my estimate, though something else could be wrong as well.
> >
> > I have extensive wireshark and PJSUA logs of both successful and failed
> > scenarios. So if any of that would help, please tell me. I didn't want to
> > write a humungous e-mail on the first go :)
> >
> > Regards,
> > Arjun
> > -------------- next part --------------
> > An HTML attachment was scrubbed...
> > URL: <
> >
> http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20120719/920dd481/attachment-0001.html
> > >
> >
> > ------------------------------
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20120723/b46efafb/attachment-0001.html
> >
>
> -
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20120724/4fe82350/attachment.html>
