CUBE INVITE

[j.huizinga]

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

[Ayodeji Okanlawon]

JH, The SDP looks okay. It is actually the same as the other SDP you have listed. You need to provide more details as to why the call failed. E.g. Send us the sip logs..i.e. Debug ccsip message

[j.huizinga]

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

[Ayodeji Okanlawon]

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 

[j.huizinga]

Hi,

Issues were solved when we created an IOS MTP with codec G729br8 and the command "g729 annexb-all"

Thanks!