Hi Nanang, So basically there's something fishy happening here :) because the whole thing seems to be working pretty well now. I have a couple of things to ask here, if you could be so kind. As per what I have understood- By adding the extra SDP fmtp parameters, I am telling the server that I can decode using these particular parameters, when in fact the decoder doesn't even understand these parameters. But then, the confusing bit is that I am actually able to decode the packets that the server sends me on the basis of this 'lie'. I think I will wait and see what happens further. Another thing I wanted to ask is whether this restriction of being able to set only 'octet-align' and 'mode-set' parameters is due to PJSIP or Intel IPP? The document made me believe that it's Intel's fault while in your reply you say that '... our encoder will only obey...' making it seem like PJSIP is lacking something. I ask this to know if there could be improvement expected, by a future version of PJSIP or Intel IPP. I have the latest versions of both. Regards, Arjun ------------------------------ > > 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@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(.., &param); > > ... > > //Set values for AMR-WB > > pjmedia_codec_mgr_get_default_param(codec_mgr, info[0], &param[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], &param[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@gmail.com> > >> > To: pjsip@lists.pjsip.org > >> > Subject: [pjsip] IMS sending immediate BYE when Intel IPP AMR codec > >> > used > >> > Message-ID: > >> > < > >> > CADzHbEWSgFENhaMVHqXLXu7TPYSCC61_hRyJ2v-ZSw9NaaXZtg@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 > >> >