Hi Arjun,
The local SDP fmtp you've set up there is to tell the remote encoder
about our decoder preference (while our decoder itself doesn't really
understand some of those fmtp settings :) So, honestly I cannot see
why there was problem when such AMR fmtp param was not set up.
And actually the IPP wrapper only support SDP fmtp as described by the
doc, e.g: our IPP encoder will only obey "mode-set" & "octet-align"
AMR fmtp signalled by remote (any other fmtp settings will be
ignored), and our IPP decoder basically will just check/strict-to the
"octet-align" setting.
BR,
nanang
On Tue, Jul 24, 2012 at 2:51 PM, Arjun Kamath <junnaonly at gmail.com> wrote:
> 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>
>>
>> -
>
>
>
> _______________________________________________
> Visit our blog: http://blog.pjsip.org
>
> pjsip mailing list
> pjsip at lists.pjsip.org
> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>
