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 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
> >
>
>
>
> ------------------------------
>
> Message: 3
> Date: Fri, 27 Jul 2012 09:05:37 -0600
> From: Magnus Kempe <mkempe@xxxxxxxxxxxxxxxx>
> To: pjsip at lists.pjsip.org
> Subject: uninitialized variable in icedemo
> Message-ID:
> <
> CAPBogZdi3i6+zqPEKn20TqBv0jRuup-JN9yMsAm_6ZSR0WGXog at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> I found a bug in icedemo.c -- use of an uninitialized variable.
>
> In static int encode_session(char buffer[], unsigned maxlen)
> I added
> cand_cnt = PJ_ICE_ST_MAX_CAND;
> before
> status = pj_ice_strans_enum_cands(icedemo.icest, comp+1,
> &cand_cnt, cand);
> because this parameter's in value defines the maximum number of candidates.
>
> The uninitialized variable seemed to work (randomly?) on Linux and Windows
> but not at all on MacOS X.
>
> Without that fix I would never see the candidates included in the SDP when
> running ice demo on MacOS X. After the fix the candidates were listed.
>
> thanks,
> Magnus
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20120727/4734d262/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 4
> Date: Fri, 27 Jul 2012 08:49:28 -0700 (PDT)
> From: Matt DiMeo <mattdimeo@xxxxxxxxx>
> To: "pjsip at lists.pjsip.org" <pjsip at lists.pjsip.org>
> Subject: fix the list digest?
> Message-ID:
> <1343404168.65212.YahooMailNeo at web39305.mail.mud.yahoo.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> The digest list email seems to be getting sent on an hourly (?) schedule
> instead of daily. ?Can this get straightened out?
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20120727/123d6e43/attachment-0001.html
> >
>
> ------------------------------
>
> _______________________________________________
> pjsip mailing list
> pjsip at lists.pjsip.org
> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>
>
> End of pjsip Digest, Vol 59, Issue 73
> *************************************
>
--
Best Regards,
Arjun P. Kamath
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20120731/307fc396/attachment-0001.html>
