Re: [Freeswitch-users] enforcing RTP payload numbers for codecs
No, you can't force codecs in the dynamic range and if properly implemented, it won't matter what number either side chooses. On Jul 8, 2010 8:34 AM, "Tzury Bar Yochay" <tzury.by@reguluslabs.com> wrote: Hi, I just download the latest, build and brought up all is fine. However, our clients are connected via IP over GPRS(UMTS) and thus we are using Speex codec. Is there a way I can enforce speex to have 97 or 98 instead of 99? Currently as it looks in the vars.xml speex is 99. see dump (taken from default vars.xml) thanks Tzury RTP Dynamic Payload Numbers currently used in FreeSWITCH and what for. 96 - AMR 97 - iLBC (30) 98 - iLBC (20) 99 - Speex 8kHz, 16kHz, 32kHz 100 - _______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Brian and Anthony, Dears, I am afraid it is a bug in teh FS See, if during SDP the client declare on payload 98 and fs declare on 99. Then client expect receiving 99 while sending 98. That is fine. However, when both clients are the same (as in our case) since FS is not trans-coding clients receives 98 in given that same sip client cannot work with previous versions of FS where there Speex was 98 (and 97 in older) On Thu, Jul 8, 2010 at 5:08 PM, Anthony Minessale < anthony.minessale@gmail.com> wrote:
No, you can't force codecs in the dynamic range and if properly implemented, it won't matter what number either side chooses.
On Jul 8, 2010 8:34 AM, "Tzury Bar Yochay" <tzury.by@reguluslabs.com> wrote:
Hi,
I just download the latest, build and brought up all is fine. However, our clients are connected via IP over GPRS(UMTS) and thus we are using Speex codec.
Is there a way I can enforce speex to have 97 or 98 instead of 99? Currently as it looks in the vars.xml speex is 99. see dump (taken from default vars.xml)
thanks Tzury RTP Dynamic Payload Numbers currently used in FreeSWITCH and what for.
96 - AMR 97 - iLBC (30) 98 - iLBC (20) 99 - Speex 8kHz, 16kHz, 32kHz 100 -
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Tzury Bar Yochay tzury.by@reguluslabs.com + 972 52 5133399 twitter.com/tzury
The server is required to send the client on the payload it requested regardless of what the server chooses. RFC 3264: Once the answerer has sent the answer, it MUST be prepared to receive media for any recvonly streams described by that answer. It MUST be prepared to send and receive media for any sendrecv streams in the answer, and it MAY send media immediately. The answerer MUST be prepared to receive media for recvonly or sendrecv streams using any media formats listed for those streams in the answer, and it MAY send media immediately. When sending media, it SHOULD use a packetization interval equal to the value of the ptime attribute in the offer, if any was present. It SHOULD send media using a bandwidth no higher than the value of the bandwidth attribute in the offer, if any was present. The answerer MUST send using a media format in the offer that is also listed in the answer, and SHOULD send using the most preferred media format in the offer that is also listed in the answer. In the case of RTP, it MUST use the payload type numbers from the offer, even if they differ from those in the answer. What is pretty amusing though is from the same RFC: In the case of RTP, if a particular codec was referenced with a specific payload type number in the offer, that same payload type number SHOULD be used for that codec in the answer. Even if the same payload type number is used, the answer MUST contain rtpmap attributes to define the payload type mappings for dynamic payload types, and SHOULD contain mappings for static payload types. The media formats in the "m=" line MUST be listed in order of preference, with the first format listed being preferred. In this case, preferred means that the offerer SHOULD use the format with the highest preference from the answer. So SHOULD means they have no nerve to enforce it because it's ambiguous and we can choose not to do it. The MUST in the first example is what we follow. MAYBE its possible to find a way to prefer the callers pt like we SHOULD, we'll have to think about it. On Thu, Jul 8, 2010 at 9:28 AM, Tzury Bar Yochay <tzury.by@reguluslabs.com>wrote:
Brian and Anthony, Dears,
I am afraid it is a bug in teh FS See, if during SDP the client declare on payload 98 and fs declare on 99. Then client expect receiving 99 while sending 98. That is fine. However, when both clients are the same (as in our case) since FS is not trans-coding clients receives 98 in given that same sip client cannot work with previous versions of FS where there Speex was 98 (and 97 in older)
On Thu, Jul 8, 2010 at 5:08 PM, Anthony Minessale < anthony.minessale@gmail.com> wrote:
No, you can't force codecs in the dynamic range and if properly implemented, it won't matter what number either side chooses.
On Jul 8, 2010 8:34 AM, "Tzury Bar Yochay" <tzury.by@reguluslabs.com> wrote:
Hi,
I just download the latest, build and brought up all is fine. However, our clients are connected via IP over GPRS(UMTS) and thus we are using Speex codec.
Is there a way I can enforce speex to have 97 or 98 instead of 99? Currently as it looks in the vars.xml speex is 99. see dump (taken from default vars.xml)
thanks Tzury RTP Dynamic Payload Numbers currently used in FreeSWITCH and what for.
96 - AMR 97 - iLBC (30) 98 - iLBC (20) 99 - Speex 8kHz, 16kHz, 32kHz 100 -
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Tzury Bar Yochay
tzury.by@reguluslabs.com + 972 52 5133399 twitter.com/tzury
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:+19193869900
Anthony, This is what happened according to our log and wireshark analysis. I will read through the RFC again see which side is taking it wrong (FS or PJSIP). Either way, thank you and all others for time and energy you have spent answering this and other posts on the mailing list, let alone FreeSWITCH development and maintenance. Tzury Client caller say in the SDP speex uses PT=98. FS answer in SDP speex will use PT=98, and then the ring tone is played with PT=98 and the caller hears the ringback well. FS invite destination with SDP speex PT=99 (value defined in the code). Client answers SDP speex uses PT=98. Answer client sends speex with PT=99 (according the FS request) and caller send speex PT=98 (according to FS request). Answer waits to get speex with PT=98, and caller waits to get speex with PT=98 (the same it was with the ringtone). Answer side hears caller, but caller doesn't hear client. If FS would have declare PT=(the value requested from the caller), the answer side would have send the PT equal to what was agreed with the FS first leg of the call. On Thu, Jul 8, 2010 at 7:54 PM, Anthony Minessale < anthony.minessale@gmail.com> wrote:
The server is required to send the client on the payload it requested regardless of what the server chooses.
RFC 3264: Once the answerer has sent the answer, it MUST be prepared to receive media for any recvonly streams described by that answer. It MUST be prepared to send and receive media for any sendrecv streams in the answer, and it MAY send media immediately. The answerer MUST be prepared to receive media for recvonly or sendrecv streams using any media formats listed for those streams in the answer, and it MAY send media immediately. When sending media, it SHOULD use a packetization interval equal to the value of the ptime attribute in the offer, if any was present. It SHOULD send media using a bandwidth no higher than the value of the bandwidth attribute in the offer, if any was present. The answerer MUST send using a media format in the offer that is also listed in the answer, and SHOULD send using the most preferred media format in the offer that is also listed in the answer. In the case of RTP, it MUST use the payload type numbers from the offer, even if they differ from those in the answer.
What is pretty amusing though is from the same RFC:
In the case of RTP, if a particular codec was referenced with a specific payload type number in the offer, that same payload type number SHOULD be used for that codec in the answer. Even if the same payload type number is used, the answer MUST contain rtpmap attributes to define the payload type mappings for dynamic payload types, and SHOULD contain mappings for static payload types. The media formats in the "m=" line MUST be listed in order of preference, with the first format listed being preferred. In this case, preferred means that the offerer SHOULD use the format with the highest preference from the answer.
So SHOULD means they have no nerve to enforce it because it's ambiguous and we can choose not to do it. The MUST in the first example is what we follow.
MAYBE its possible to find a way to prefer the callers pt like we SHOULD, we'll have to think about it.
On Thu, Jul 8, 2010 at 9:28 AM, Tzury Bar Yochay <tzury.by@reguluslabs.com
wrote:
Brian and Anthony, Dears,
I am afraid it is a bug in teh FS See, if during SDP the client declare on payload 98 and fs declare on 99. Then client expect receiving 99 while sending 98. That is fine. However, when both clients are the same (as in our case) since FS is not trans-coding clients receives 98 in given that same sip client cannot work with previous versions of FS where there Speex was 98 (and 97 in older)
On Thu, Jul 8, 2010 at 5:08 PM, Anthony Minessale < anthony.minessale@gmail.com> wrote:
No, you can't force codecs in the dynamic range and if properly implemented, it won't matter what number either side chooses.
On Jul 8, 2010 8:34 AM, "Tzury Bar Yochay" <tzury.by@reguluslabs.com> wrote:
Hi,
I just download the latest, build and brought up all is fine. However, our clients are connected via IP over GPRS(UMTS) and thus we are using Speex codec.
Is there a way I can enforce speex to have 97 or 98 instead of 99? Currently as it looks in the vars.xml speex is 99. see dump (taken from default vars.xml)
thanks Tzury RTP Dynamic Payload Numbers currently used in FreeSWITCH and what for.
96 - AMR 97 - iLBC (30) 98 - iLBC (20) 99 - Speex 8kHz, 16kHz, 32kHz 100 -
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Tzury Bar Yochay
tzury.by@reguluslabs.com + 972 52 5133399 twitter.com/tzury
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire
AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:+19193869900
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Tzury Bar Yochay tzury.by@reguluslabs.com + 972 52 5133399 twitter.com/tzury
participants (2)
-
Anthony Minessale
-
Tzury Bar Yochay