11-16-2017 05:43 AM - edited 03-17-2019 11:36 AM
Hi,
I have a customer with a CUBE which works most of the time correctly. But sometimes a call fails (call drops). This is normally a codec issue, but there is a transcoder in the CUBE. What I see with calls that fail is that the SDP looks quite different. In a normal SIP INVITE SDP I see the codecs, but with calls that fail I see as SDP this:
v=0
o=XXXXXXXXX
s=-
c=IN IP4 XXXXXXXX
t=0 0
m=audio 21322 RTP/AVP 8 101 18
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=fmtp:18 annexb=yes
I have checked several of my customers with CUBE's but the INVITES CUBE receives or send always include something like:
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
And some other rtpmap's
Any one seen this, is this a correct SDP? I am using a rather older IOS, is it an IOS issue?
Any idea?
Thanks
JH
11-16-2017 06:28 AM
11-16-2017 06:59 AM
Hello Ayodeji,
Thanks for the quick response.
So if they are the same, what does the first sdp means (without CODEC info) What CODECS are offered then by the provider?
The issue seems to be annexb=no and annexb=yes
The 'simple' SDP has annexb=yes, finally the CUCM gives an ACK with annexb=no
And then the CUBE sneds a BYE with "Reason: Q.850;cause=65"
Other INVITES which we receive and have the 'full' SDP, meaning an rtmap for G729 and an rtpmap for g711 works fine
I cannot send you the whole debug here on the forum, might send to an e-mail address
Thanks
Jan
11-16-2017 09:36 PM - edited 11-16-2017 09:55 PM
The first SDP, even though didn't use the rtpmap attributes to explain the codecs.. Still has same codec payloads as the second one. Here is what the RFC says.
rtpmap:<payload type> <encoding name>/<clock rate> [/<encoding
parameters>]
This attribute maps from an RTP payload type number (as used in
an "m=" line) to an encoding name denoting the payload format
to be used. It also provides information on the clock rate and
encoding parameters. It is a media-level attribute that is not
dependent on charset.
Handley, et al. Standards Track [Page 25]
RFC 4566 SDP July 2006 Although an RTP profile may make static assignments of payload type numbers to payload formats, it is more common for that assignment to be done dynamically using "a=rtpmap:" attributes. As an example of a static payload type, consider u-law PCM coded single-channel audio sampled at 8 kHz. This is completely defined in the RTP Audio/Video profile as payload type 0, so there is no need for an "a=rtpmap:" attribute, and the media for such a stream sent to UDP port 49232 can be specified as:
m=audio 49232 RTP/AVP 0
As you can see we don't need this for static payloads like G729 and G711..
For annexb, when your SDP doesn't state it, it is assumed to be yes. This is why I said they are the same.
You may have an issue with your old iOS not interpreting the SDP correctly
11-23-2017 06:38 AM
Hi,
Issues were solved when we created an IOS MTP with codec G729br8 and the command "g729 annexb-all"
Thanks!
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide