Fri, Jul 21, 2006 at 23:11:30, Craig.Peacock wrote about "[Sip-implementors] rtpmap encoding name G729a":
> I've been reading the posts earlier this year about the "G729a" not > being a valid encoding name as per RFC3551. > There appears to be a popular ATA vendor that sends : > a=rtpmap:18 G729a/8000 > in the SDP for what I can gather is most of their product range. Yes, this is true at least for most Sipura and some Linksys products. But as 18 is number from fixed codec range, this would not give a sufficient problem for codec parsing. In practice, there were very rare cases when remote UA didn't accept such SDP; it seems most of them first see to codec number, and then peek codec name only if codec number falls to dynamic range (96-127). > This therefore causes quite a few compatibility problems for VoIP to > VoIP calls as many ATAs and softphones are strict do not accept "G729a", > only "G729". > What is the general consensus for handing this issue? Do you write work > arounds into your code to accept it, or do you return an error? Some of > the code I have seen, does a comparison byte by byte on "G729" & the > encoding name and conveniently never sees the 'a' postfixing the name. PortaOne explicitly declares in its recommendations for used UAs that G729a shall be understood as same as G729; this was declared because some time ago Sipura products was considered as the most featured and stable in their class (1-2 line SIP ATAs) and there were no reason yet to change this opinion. > I've also been looking at the behavior of some SIP proxies. Some will > rewrite the SDP sending a compliant "G729" instead, others appear to > just pass it on unaltered. -- Valentin Nechayev PortaOne Inc., Software Engineer mailto:[EMAIL PROTECTED] _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
