Re: [Sip-implementors] rtpmap:18 G729a/8000 ?

I second Attila. Therefore if you want to use G729 Annex A encoding, do so using G729 in a-line of sdp, and encode using G729 annex A in bearer. G729 and "G729 Annex A" are inter-operable and there should be no difficulties. However you should specifically mention "annexb=no" as absence of this pa

Re: [Sip-implementors] SIP media change - Is the precedence for c=0.0.0.0 or a= attribute?

Subbu Rajendran wrote: > I was trying to prove that if offer contains c=0.0.0.0 > and any one of the a=recvonly/sendonly/sendrecv/inactive attribute then > the client can safely process this offer in the same manner as for hold. I don't know what you mean when you say "the cl

Re: [Sip-implementors] SIP media change - Is the precedence for c=0.0.0.0 or a= attribute?

I was trying to prove that if offer contains c=0.0.0.0 and any one of the a=recvonly/sendonly/sendrecv/inactive attribute then the client can safely process this offer in the same manner as for hold. I think I confused things with my explanation in my previous email :-) For the example used below,

Re: [Sip-implementors] rtpmap:18 G729a/8000 ?

no, annexb and annexa are different things: annexa is a codec efficiency improvement annexb is silence suppression In practice, I have seen usage of "rtpmap:18 G729a/8000" but it has no RFC-based meaning. There is no way to indicate g729A. You just have to use g729. The reason for lack of g729a

Re: [Sip-implementors] rtpmap:18 G729a/8000 ?

I think you need to represent in two lines a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no Somesh S Shanbhag M G L Bangalore -Original Message- From: [EMAIL PROTECTED] on behalf of [EMAIL PROTECTED] Sent: Mon 11/3/2008 6:08 PM To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implemen

[Sip-implementors] rtpmap:18 G729a/8000 ?

Hi, Please let me know if "rtpmap:18 G729a/8000" is a wrong format. I guess RFC3551 says it should work (page 19, as pasted below) and I am not able to find anything so specific in RFC3550. 4.5