Hi everyone and Nanang especially,
I have a new related issue with AMR, that I hope you can help out with.
When my tool is receiving a call, the SDP of INVITE is as below:
v=0
o=- 8916555 8916555 IN IP4 MSC35.TE4
s=-
c=IN IP4 10.52.227.142
t=0 0
a=sendrecv
m=audio 46670 RTP/AVP 96 97 98 99 8 100 101 102 103
c=IN IP4 10.52.227.142
b=RR:0
b=RS:0
a=rtpmap:96 AMR-WB/16000
a=fmtp:96
mode-set=0,1,2;mode-change-period=2;mode-change-capability=2;mode-change-neighbor=1;max-red=0
a=rtpmap:97 AMR-WB/16000
a=fmtp:97
mode-set=0,1,2;mode-change-period=2;mode-change-capability=2;mode-change-neighbor=1;max-red=0;octet-align=1
a=rtpmap:98 AMR/8000
a=fmtp:98
mode-set=0,2,4,7;mode-change-period=2;mode-change-capability=2;mode-change-neighbor=1;max-red=0
a=rtpmap:99 AMR/8000
a=fmtp:99
mode-set=0,2,4,7;mode-change-period=2;mode-change-capability=2;mode-change-neighbor=1;max-red=0;octet-align=1
a=rtpmap:8 PCMA/8000
a=rtpmap:100 AMR/8000
a=fmtp:100 mode-set=7;max-red=0
a=rtpmap:101 AMR/8000
a=fmtp:101 mode-set=7;max-red=0;octet-align=1
a=rtpmap:102 telephone-event/16000
a=fmtp:102 0-15
a=rtpmap:103 telephone-event/8000
a=fmtp:103 0-15
a=maxptime:40
Now, in my code. I have
...
//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");
...
This works and the tool replies with SDP mode-set=0,1,2
However it doesn't work with
param[0].setting.dec_fmtp.param[0].val = pj_str("0,1,2,3,4,5,6,7");
or anything other than "0,1,2"
Whatever the incoming SDP, the tool replies with the ENTIRE MODE-SET STRING
that I have in my code. Shouldn't it reply with only those from the
incoming SDP that it has in the string? Have I misunderstood anything?
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
> > >>
> > >> ----------------------------------------------------------------------
> > >> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20120809/369e8634/attachment-0001.html>
