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