All,
Please tell me whether the following line in sdp is syntactically correct to
identify the codec as G729A:
a=rtpmap:18 G729A/8000
My code is expecting in the following way for G729A:
a=fmtp:18 annexb=no
should we support both forms?
Regards,
Aswin Bhupalam.
----- Original Message -----
From: [EMAIL PROTECTED]
To: Aswin Bhupalam
Sent: Tuesday, July 19, 2005 12:17 PM
Subject: Re: [Sip-implementors] G 729 a & b negotiation
Aswin
Don't worry about annex A, as I said it is compatible with G.729 so you don't
need to do anything to support it.
So the only question is whether you and your party support the annex B.
If no annexb parameter is present, it does mean G.729B according to the RFC.
So formally the behavior of your code is correct .
However please note :
1. Many implementation are not aware of the annexb parameter, so maybe they
don't support annex B but they simply don't declare it out of ignorance.
2. You can consider not rejecting the call, and simply discard the G.729 SID
frames you receive (this is the meaning of annex B). So if your other party
does not support annex B - everything is good. If it does - then you can still
have a call but with poorer quality.
Thanks
Uzi
"Aswin Bhupalam" <[EMAIL PROTECTED]>
"Aswin Bhupalam" <[EMAIL PROTECTED]>
07/19/2005 09:28 AM
To
<[EMAIL PROTECTED]>
cc
Subject
Re: [Sip-implementors] G 729 a & b negotiation
Uzi,
Thanks for the quick reply.
If I recieve "18" and no annexb parameter in "a=" line, then what does that
indicate?
just g.729 or g.729a or g.729b (or g.729ab)?
my code has a default of g.729b as per rfc 3555. But, many phones are sending
codec "18" with out any annexb param in "a=" line, so we are rejecting the call
as we are not supporting g.729b.
Thanks,
Aswin Bhupalam.
----- Original Message -----
From: [EMAIL PROTECTED]
To: Aswin Bhupalam
Sent: Tuesday, July 19, 2005 11:32 AM
Subject: Re: [Sip-implementors] G 729 a & b negotiation
Please see RFC 3555:
annexb: indicates that Annex B, voice activity detection, is
used or preferred. Permissible values are "yes" and "no"
(without the quotes); "yes" is implied if this parameter is
omitted.
G.729A does not need to be negotiated, as it is fully compatible with G.729.
Thanks
Uzi
"Aswin Bhupalam" <[EMAIL PROTECTED]>
"Aswin Bhupalam" <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
07/19/2005 08:17 AM
To
<[email protected]>
cc
"Sushil \(E-mail\)" <[EMAIL PROTECTED]>, Uttam Kumar Sarkar
<[EMAIL PROTECTED]>
Subject
[Sip-implementors] G 729 a & b negotiation
All,
say "a=" line is not having 'annexb' parameter, which one(g729a or g729b)
should we take as default.
Snom phone sends an INVITE with the following SDP:
v=0
o=root 743184990 743184990 IN IP4 10.50.10.146
s=call
c=IN IP4 10.50.10.146
t=0 0
m=audio 10014 RTP/AVP 18 101
a=rtpmap:18 g729/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=sendrecv
Which codec is being negotiated here?(g729a or g729b)
Dave,
I found your mail regarding the same question.
kindly let me know if you've found something useful.
Regards,
Aswin Bhupalam.
-----Messaggio originale-----
Da: sip-implementors-bounces at cs.columbia.edu
[mailto:sip-implementors-bounces at cs.columbia.edu] Per conto di David
Stuart
Inviato: giovedì 8 luglio 2004 20.10
A: sip-implementors at cs.columbia.edu
Oggetto: [Sip-implementors] g729 annex B negotiation
Hi All,
What is the correct way to negotiate annex B when using g.729 (as opposed to
A)? They both use the same payload type, 18.
I see two different mentions of this, RFC 3555 section 4.1.9, and RFC
3108 sec 5.6.3.2 but they seem to be saying different things.
Can anyone point me to the correct example as to how to achieve this?
--
David Stuart, SIPquest
Email: dave (at) sipquest (dot) com
Phone: 254-8886 x234 Web: http://www.sipquest.com/
Address: 106 - 350 Terry Fox Drive, Kanata Ontario, K2K 2P5
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
********************** Legal Disclaimer ****************************
"This email may contain confidential and privileged material for the sole use
of the intended recipient. Any unauthorized review, use or distribution by
others is strictly prohibited. If you have received the message in error,
please advise the sender by reply email and delete the message. Thank you."
**********************************************************************
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
