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:
c=IN IP4 XXXXXXXX
m=audio 21322 RTP/AVP 8 101 18
I have checked several of my customers with CUBE's but the INVITES CUBE receives or send always include something like:
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?
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
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