March 2008 - freeswitch-dev@lists.freeswitch.org

[Freeswitch-dev] SRTP and negotiation and vendor compliance.
by Brian West 15 Mar '08

15 Mar '08

After many talks and various vendors and more reading RFC3711 and RFC4568 below is what we have determined to be correct for SRTP negotiation in the SDP over TLS: Here is how the SDP's should look in all three cases: On but optional/preferred: v=0 o=root 1130561626 1130561626 IN IP4 10.0.1.241 s=call c=IN IP4 10.0.1.241 t=0 0 m=audio 52970 RTP/SAVP 9 0 8 2 3 18 4 101 a=rtpmap:9 g722/8000 a=rtpmap:0 pcmu/8000 a=rtpmap:8 pcma/8000 a=rtpmap:2 g726-32/8000 a=rtpmap:3 gsm/8000 a=rtpmap:18 g729/8000 a=rtpmap:4 g723/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:WvPreyjK82pM0I5vtUY2zkpIKPbRVSKH1QcPrsWP a=ptime:60 m=audio 52970 RTP/AVP 9 0 8 2 3 18 4 101 a=rtpmap:9 g722/8000 a=rtpmap:0 pcmu/8000 a=rtpmap:8 pcma/8000 a=rtpmap:2 g726-32/8000 a=rtpmap:3 gsm/8000 a=rtpmap:18 g729/8000 a=rtpmap:4 g723/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:60 On but Manditory: v=0 o=root 1130561626 1130561626 IN IP4 10.0.1.241 s=call c=IN IP4 10.0.1.241 t=0 0 m=audio 52970 RTP/SAVP 9 0 8 2 3 18 4 101 a=rtpmap:9 g722/8000 a=rtpmap:0 pcmu/8000 a=rtpmap:8 pcma/8000 a=rtpmap:2 g726-32/8000 a=rtpmap:3 gsm/8000 a=rtpmap:18 g729/8000 a=rtpmap:4 g723/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:WvPreyjK82pM0I5vtUY2zkpIKPbRVSKH1QcPrsWP a=ptime:60 Off not offered/Not Supported: v=0 o=root 1130561626 1130561626 IN IP4 10.0.1.241 s=call c=IN IP4 10.0.1.241 t=0 0 m=audio 52970 RTP/AVP 9 0 8 2 3 18 4 101 a=rtpmap:9 g722/8000 a=rtpmap:0 pcmu/8000 a=rtpmap:8 pcma/8000 a=rtpmap:2 g726-32/8000 a=rtpmap:3 gsm/8000 a=rtpmap:18 g729/8000 a=rtpmap:4 g723/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:60 I would like some feedback on this as I'm getting what seems to be some push back from vendors that do this incorrectly. i.e. having crypto lines in an RTP/AVP which is wrong. You should never have crypto lines in an RTP/AVP they belong in the RTP/SAVP profile as per RFC3711. I'm working with as many vendors as I can to ensure that they all behave the same way. Can someone tell me if I'm wrong here? Polycom already does it like this, snom should be following suit and i'm working with Grandstream and Aastra right now on this. In addition a vendor shouldn't turn on the padlock/secure logo if the exchange didn't take place over TLS. Thanks, Brian West FreeSWITCH.org

1 0

Re: [Freeswitch-dev] OZ Question: zap_span_find()
by Anthony Minessale 07 Mar '08

07 Mar '08

correct, Assuming the typo in the example was an accident. (span not my_span_pointer declared on the first line) zap_span_t *my_span_pointer = NULL; uint32_t span_id = 1; zap_status_t result; result = zap_span_find(span_id, &my_span_pointer); if it returns ZAP_SUCCESS, that indicates that the desired span exists, is in use and that the pointer will now point to it. Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ AIM: anthm MSN:anthony_minessale@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org pstn:213-799-1400 ----- Original Message ---- From: Michael Collins <mcollins(a)fcnetwork.com> To: freeswitch-dev(a)lists.freeswitch.org Sent: Thursday, March 6, 2008 8:27:35 PM Subject: [Freeswitch-dev] OZ Question: zap_span_find()  Does this function do what I think it does? If I give it a span number to look for, it returns ZAP_SUCCESS if it finds the span and it sets the value of the pointer variable that I call it with? Example, what happens if I do this, assuming span 1 is a real span? zap_span_t *span = NULL; uint32_t span_id = 1; result = zap_span_find(span_id, &my_span_pointer); Does *my_span_pointer now point to span 1? Any caveats that I should be aware of? Thanks, MC -----Inline Attachment Follows----- _______________________________________________ Freeswitch-dev mailing list Freeswitch-dev(a)lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

2 1

[Freeswitch-dev] OZ Question: zap_span_find()
by Michael Collins 07 Mar '08

07 Mar '08

Does this function do what I think it does? If I give it a span number to look for, it returns ZAP_SUCCESS if it finds the span and it sets the value of the pointer variable that I call it with? Example, what happens if I do this, assuming span 1 is a real span? zap_span_t *span = NULL; uint32_t span_id = 1; result = zap_span_find(span_id, &my_span_pointer); Does *my_span_pointer now point to span 1? Any caveats that I should be aware of? Thanks, MC

1 0

Re: [Freeswitch-dev] VAD, TALK and NOTALK events
by Anthony Minessale 05 Mar '08

05 Mar '08

The algorithm used is not so great and could stand to be replaced by a better one if we get the chance. basically we decode the audio to signed linear 16bit samples for each packet we receive and iterate the samples and add up the absolute values then compute the average and compare it to the acceptable level considered "talking" then we use a counter to make sure it's in the same state several times in a row before actually changing the status of the channel to talking or not talking. A real vad algorithm would also be able to filter out the voice from the background noise and judge the energy based only on that. Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ AIM: anthm MSN:anthony_minessale@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org pstn:213-799-1400 ----- Original Message ---- From: KMTDBOURSE <kmtdbourse(a)free.fr> To: freeswitch-dev(a)lists.freeswitch.org Sent: Thursday, February 14, 2008 1:51:55 PM Subject: Re: [Freeswitch-dev] VAD, TALK and NOTALK events Hi, I ma interested in the VAD algorithm used where where is the code exactly? maybe a link any document support about the vad alogorithm used therein? thanks, Zelda At 01:47 14/02/2008, Anthony Minessale wrote: They are enabled by the vad params in the sofia profile xml <param name="vad"> Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ AIM: anthm MSN:anthony_minessale@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org pstn:213-799-1400 ----- Original Message ---- From: Cesar Cepeda <cesar(a)auronix.com> To: freeswitch-dev(a)lists.freeswitch.org Sent: Wednesday, February 13, 2008 10:17:23 AM Subject: Re: [Freeswitch-dev] VAD, TALK and NOTALK events Please correct me if I’m wrong. The events are indeed fired, but only if the SWITCH_VAD_FLAG_EVENTS_TALK or NOTALK flags are set for an rtp_session. I found no place in the code where those flags are set. That is what I meant by not being “enabled”. I subscribed to the events and received nothing. Then I set the flags on switch_rtp_enable_vad function, and then I started receiving the events. Perhaps there is another way of doing it that I’m missing. Cesar Cepeda. De: freeswitch-dev-bounces(a)lists.freeswitch.org [ mailto:freeswitch-dev-bounces@lists.freeswitch.org] En nombre de Anthony Minessale Enviado el: Miércoles, 13 de Febrero de 2008 08:17 Para: freeswitch-dev(a)lists.freeswitch.org Asunto: Re: [Freeswitch-dev] VAD, TALK and NOTALK events The events are fired. I don't know what you mean by "enabled" You can either bind an event to a callback in the load function of your custom module. or connect to mod_event_socket on tcp and request "events talk notalk" void my_event_handler(switch_event_t *event) { } if (switch_event_bind(modname, SWITCH_EVENT_TALK, SWITCH_EVENT_SUBCLASS_ANY, my_event_handler, NULL) != SWITCH_STATUS_SUCCESS) { switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_ERROR, "Couldn't bind!\n"); return SWITCH_STATUS_GENERR; } if (switch_event_bind(modname, SWITCH_EVENT_NOTALK, SWITCH_EVENT_SUBCLASS_ANY, my_event_handler, NULL) != SWITCH_STATUS_SUCCESS) { switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_ERROR, "Couldn't bind!\n"); return SWITCH_STATUS_GENERR; } Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ AIM: anthm MSN:anthony_minessale@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org pstn:213-799-1400 ----- Original Message ---- From: Cesar Cepeda <cesar(a)auronix.com> To: freeswitch-dev(a)lists.freeswitch.org Sent: Tuesday, February 12, 2008 6:53:03 PM Subject: [Freeswitch-dev] VAD, TALK and NOTALK events Hi, >From looking at the code of switch_rtp.c I can see that VAD is done if enabled in the sip profile in order to not send packets when there is no noise. There are also two events {TALK, NOTALK} which can be fired when VAD kicks in, nevertheless these two events are enabled nowhere (or at least I didn't find a place in the code where they were enabled), so no matter if you ask for them you don't receive them. My questions are the following: Is there some particular reason for not enabling these two events? Is the event queue easily overflowed if these two events are enabled? Thanks. Cesar Cepeda. _______________________________________________ Freeswitch-dev mailing list Freeswitch-dev(a)lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE: http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org Never miss a thing. Make Yahoo your homepage. -----Inline Attachment Follows----- _______________________________________________ Freeswitch-dev mailing list Freeswitch-dev(a)lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE: http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org Looking for last minute shopping deals? Find them fast with Yahoo! Search. _______________________________________________ Freeswitch-dev mailing list Freeswitch-dev(a)lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org -----Inline Attachment Follows----- _______________________________________________ Freeswitch-dev mailing list Freeswitch-dev(a)lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org ____________________________________________________________________________________ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping

6 10