Re: [pjsip] Unexpected behaviour with AMR, (Arjun Kamath) (Arjun Kamath)
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@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
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(.., ¶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=0Another 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 modeA 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)
------------------------------ClientIMS-------------------------------------(ACK)---------------------------------->Client
IMS-------------------------------------(BYE)---------------------------------->Client(Reason:Q.850;cause=111[Protocol
Error, unspecified])IMS<--------------------------------(200_OK)----------------------------------Client
MGW<--------------(RTCP-Sender-Rep-Goodbye) --------------------ClientThe 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