I know this post contains a lot of questions but hey are all linked.
i hope u can fidn usefull what we did and help us in sovling what we couldnt. since the digium support wasnt of great help.
Situation:
One HP server - RHEL 4.3 - astersike BE B.2.2.1 -TC400B Card (firmware w-tc400m.bin) -Zaptel 1.2.20.1
CPE: linksys SPA 9XX and PAP2T
We are trying to use G723 on our linksys CPEs.
Problem TC440B support G723@5.3kbps ONLY.
Linksys CPEs Both G723@5.3 and G723@6.3.
#Call between astersik and Linksys in G723= doesnt work
when we try to make a call the codec negotiaotion goes wrong the linksys negotiates the G723 without specifying the bit rate, the astersik on the other side will be in G723@5.3. for some reason the linksys product will be in G723@6.3. so it doesnt work.
we when further in try to modfiy the chan_sip.c ( we have a BE, but we replaced it with the open source) to hard code the bit rate to be used (SDP parameter (RFC 3555 – 4.1.3).)
As per the code below and the packet cap you will see that the packet is modified. (in red)
The outcome:nothing changes; asterisk send in @5.3 and the CPE in @6.3. Asterisk also freeze a short while after the com is established.
Here is the code:
static void add_codec_to_sdp(const struct sip_pvt *p, int codec, int sample_rate,
char **m_buf, size_t *m_size, char **a_buf, size_t *a_size,
int debug)
{
int rtp_code;
if (debug)
ast_verbose("Adding codec 0x%x (%s) to SDP\n", codec, ast_getformatname(codec));
if ((rtp_code = ast_rtp_lookup_code(p->rtp, 1, codec)) == -1)
return;
ast_build_string(m_buf, m_size, " %d", rtp_code);
ast_build_string(a_buf, a_size, "a=rtpmap:%d %s/%d\r\n", rtp_code,
ast_rtp_lookup_mime_subtype(1, codec),
sample_rate);
if (codec == AST_FORMAT_G729A)
/* Indicate that we don't support VAD (G.729 annex B) */
ast_build_string(a_buf, a_size, "a=fmtp:%d annexb=no\r\n", rtp_code);
else if (codec == AST_FORMAT_G723_1)
/* Indicate that we don't support VAD (G.723.1 annex A) */
[color=red] ast_build_string(a_buf, a_size, “a=fmtp:%d annexa=no bitrate=5300\r\n”, rtp_code);[/color]
}
And here the cap, notice how the bitrate is specified @5300
To: sip:888@xxxxxx;tag=as4f01c3aa
Call-ID: 9e52f60b-45c10373@192.168.1.103
CSeq: 102 INVITE
User-Agent: SIP
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Contact: sip:888@xxxxxxx
Content-Type: application/sdp
Content-Length: 346
v=0
o=root 9481 9481 IN IP4 xxx.xxx.xxx.xxx
s=session
c=IN IP4 xxx.xxx.xxx.xxx
t=0 0
m=audio 30010 RTP/AVP 4 18 8 0 101
a=rtpmap:4 G723/8000
[color=red]a=fmtp:4 annexa=no bitrate=5300[/color]
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
#Voice mail: (using linksys @g723)
answer form digium business support:
Asterisk supports passthrough mode on G.723.1 5.3 kbps by default, there should be no issues with tones or prompts or voicemail as long as the endpoints support it.
we tried, we have the same problem as when making calls
all happens in G723@6.3. we cant record any message (but can hear them) so this is a no go too.
#Pass through.
To remove load form a server or a card, it woudl be nie if there was a way to favorize pasthrough, it mean that if the incomning call form CPE is in G723 (for example) and the provider on the other side accepts it will saty in that code avoiding useless conversion/ regardless of what are the preferences of the provider.
conclusion:
digium told me that they will have a new firmware that will fix this (i have no idea what it means,what it will fix… And i have no details on the time of release…)
as for linksys it is very hard to get an answer form them on how to block the G723@5.3 on their CPE.
Janus