[SIPForum-techwg] Can we please have at least one real codec

[Spencer Dawkins]

From: "Cullen Jennings" <fluffy at cisco.com>
> 
> On Feb 12, 2009, at 5:03 AM, DOLLY, MARTIN C, ATTLABS wrote:
> 
>> G729b, but we would have to clearly define the codec negotiation, as  
>> it is a source of interop problems
> 
> I may be very wrong about this - someone that operated big 729  
> networks would have a better idea. But I think most of theses interop  
> problems have been sorted out at this point. But 100% agree with  
> Martin that we would need to make sure we nailed this down carefully  
> in the spec as it has been a problem in the past .

We had a previous discussion about this a couple of revisions ago - we added text in Section 16.2 saying (in blue):

1.1      Codec Support and Media Transport
 

A Media Endpoint MUST transport voice samples using the real-time transport protocol (RTP) as described in RFC 3550. 

 

Any media endpoint that originates and/or terminates RTP traffic over UDP MUST use the same UDP port for sending and receiving session media (i.e. symmetric RTP.)

 

Any media endpoint that originates and/or terminates RTP traffic SHOULD be capable of processing RTP packets with different packetization rate than the one used for sending. It is RECOMMENDED that negotiation of packetization rate during SDP offer/answer makes use of the same packetization rate for both sending and receiving.

 

Any media endpoint that originates and/or terminates voice traffic MUST support the ITU-T G.711 µ-Law and G.711 A-Law PCM codecs with a packetization rate of 20 ms. Any device intended for low-bandwidth operation SHOULD support ITU-T G.729 codecs.

 

In the absence of a specific indication that silence suppression (i.e., G.729 Annex B) is NOT supported, the Media Endpoint MUST assume that it is supported. In order to indicate that silence suppression is NOT supported, the a=fmtp: <payload-type> annexb=no attribute MUST be included. See 4.1.9 in RFC 3555.

 

It is possible that the Answerer supports receiving G.729B but not sending it. In that case, it would be perfectly legal to send an Answer with annexb=yes (or without any parameter since it means the same thing).  The Answerer in this case is expressing its willingness to receive G.729B packets, even if it never sends any itself.

Does this address the concerns about negotiation?

Thanks,

Spencer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://sipforum.org/pipermail/techwg/attachments/20090212/97a91c38/attachment.html