[Freeswitch-users] Determining if Freeswitch channel is using a video codec

Tue Mar 3 00:35:10 MSK 2015

Actually, I do not necessarily need the codec. I only need to determine if
a call is using video or not. The codec is useful additional information,
but not necessary.

On Mon, Mar 2, 2015 at 4:28 PM, Dylan Mikus <dylan at onsip.com> wrote:

> I’m trying to determine if a given channel over Freeswitch is using a
> video codec. In my config/vars.xml file, I’ve set the codecs line to:
>
> <X-PRE-PROCESS cmd="set" data="global_codec_prefs=OPUS,G722,PCMU,PCMA,H264"/>
>
> Logs
>
> My SDP negotiation appears to be correct. The INVITE:
>
> INVITE sip:queuecard at cyberdyne.onsip.com SIP/2.0
> Via: SIP/2.0/WS o8iatftbl1mn.invalid;branch=z9hG4bK8962099
> Max-Forwards: 70
> To: <sip:queuecard at cyberdyne.onsip.com>
> From: "Bender Rodriguez" <sip:bender at cyberdyne.onsip.com>;tag=fneppn1lhh
> Call-ID: n3o4g4i724sq7qkekp07
> CSeq: 8622 INVITE
> Proxy-Authorization: Digest algorithm=MD5, username="cyberdyne_bender", realm="jnctn.net", nonce="54f4ce2e000013e4888519dec3ca2ee1ef9023f82d4d8922", uri="sip:queuecard at cyberdyne.onsip.com", response="f842951ecc11c3510d1e1b7abcdeb51f", qop=auth, cnonce="d153n6udlh74", nc=00000001
> Contact: <sip:1fjqm8ps at o8iatftbl1mn.invalid;transport=ws;ob>
> Allow: ACK,CANCEL,BYE,OPTIONS,INFO,NOTIFY,INVITE,MESSAGE
> Content-Type: application/sdp
> Supported: 100rel,outbound
> User-Agent: SIP.js/0.6.3 InstaPhone
> Content-Length: 1649
>
> v=0
> o=Mozilla-SIPUA-35.0.1 10886 0 IN IP4 0.0.0.0
> s=SIP Call
> t=0 0
> a=ice-ufrag:a256418b
> a=ice-pwd:62e2ae7154b57f00ed0b1a2003ccf7af
> a=fingerprint:sha-256 EA:C4:92:D4:94:62:18:41:39:2E:42:B4:4E:B7:32:9E:66:FE:7C:01:57:AC:2C:4C:E4:66:4F:3B:B6:91:FA:DC
> m=audio 9 UDP/TLS/RTP/SAVPF 109 9 0 8 101
> c=IN IP4 0.0.0.0
> a=rtpmap:109 opus/48000/2
> a=ptime:20
> a=rtpmap:9 G722/8000
> a=rtpmap:0 PCMU/8000
> a=rtpmap:8 PCMA/8000
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-15
> a=sendrecv
> a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
> a=setup:actpass
> a=rtcp-mux
> a=candidate:0 1 UDP 2130379007 192.168.1.38 58531 typ host
> a=candidate:0 2 UDP 2130379006 192.168.1.38 64677 typ host
> a=candidate:1 1 UDP 1694236671 38.104.167.182 49209 typ srflx raddr 192.168.1.38 rport 58531
> a=candidate:1 2 UDP 1694236670 38.104.167.182 51209 typ srflx raddr 192.168.1.38 rport 64677
> m=video 9 UDP/TLS/RTP/SAVPF 120 126 97
> c=IN IP4 0.0.0.0
> a=rtpmap:120 VP8/90000
> a=rtpmap:126 H264/90000
> a=fmtp:126 profile-level-id=42e01f;packetization-mode=1
> a=rtpmap:97 H264/90000
> a=fmtp:97 profile-level-id=42e01f
> a=sendrecv
> a=rtcp-fb:120 nack
> a=rtcp-fb:120 nack pli
> a=rtcp-fb:120 ccm fir
> a=rtcp-fb:126 nack
> a=rtcp-fb:126 nack pli
> a=rtcp-fb:126 ccm fir
> a=rtcp-fb:97 nack
> a=rtcp-fb:97 nack pli
> a=rtcp-fb:97 ccm fir
> a=setup:actpass
> a=rtcp-mux
> a=candidate:0 1 UDP 2130379007 192.168.1.38 59562 typ host
> a=candidate:0 2 UDP 2130379006 192.168.1.38 61464 typ host
> a=candidate:1 1 UDP 1694236671 38.104.167.182 59357 typ srflx raddr 192.168.1.38 rport 59562
> a=candidate:1 2 UDP 1694236670 38.104.167.182 21168 typ srflx raddr 192.168.1.38 rport 61464
>
> The 200 OK response:
>
> SIP/2.0 200 OK
> Via: SIP/2.0/WS o8iatftbl1mn.invalid;branch=z9hG4bK8962099
> Record-Route: <sip:38.109.82.167;lr;ftag=fneppn1lhh;did=24.0b0068f6>
> Record-Route: <sip:38.109.82.192;lr;ftag=fneppn1lhh;did=24.4c4e8343>
> Record-Route: <sip:38.109.82.193:5060;transport=udp;lr;ovid=cac1e79d>
> Record-Route: <sip:2b14c410c1 at 38.109.82.193:80;transport=ws;lr;ovid=cac1e79d>
> From: "Bender Rodriguez" <sip:bender at cyberdyne.onsip.com>;tag=fneppn1lhh
> To: <sip:queuecard at cyberdyne.onsip.com>;tag=30yQvF62DQyyg
> Call-ID: n3o4g4i724sq7qkekp07
> CSeq: 8622 INVITE
> Contact: <sip:dtlsgw0 at app2-1.55-broad-1.app.jnctn.net>
> Accept: application/sdp
> Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, PRACK, NOTIFY
> Supported: precondition, 100rel, timer, path, replaces
> Content-Type: application/sdp
> Content-Disposition: session
> Content-Length: 1738
>
> v=0
> o=FreeSWITCH 1425307798 1425307799 IN IP4 38.109.82.228
> s=FreeSWITCH
> c=IN IP4 38.109.82.228
> t=0 0
> a=msid-semantic: WMS 61ZdxYMnyCuYhu6FrqjCFIr1DUjUALvw
> m=audio 21882 UDP/TLS/RTP/SAVPF 109 101
> a=rtpmap:109 opus/48000/2
> a=fmtp:109 useinbandfec=1;usedtx=1;maxaveragebitrate=30000
> a=rtpmap:101 telephone-event/8000
> a=recvonly
> a=silenceSupp:off - - - -
> a=ptime:20
> a=fingerprint:sha-256 D6:87:51:92:F6:80:BE:0D:5B:9A:97:C3:53:A7:40:C5:A2:19:60:CA:48:2D:18:A2:53:AF:B6:E1:4E:02:39:D2
> a=rtcp:21883 IN IP4 38.109.82.228
> a=ssrc:2365215248 cname:CkzZ9cdxFymMTiha
> a=ssrc:2365215248 msid:61ZdxYMnyCuYhu6FrqjCFIr1DUjUALvw a0
> a=ssrc:2365215248 mslabel:61ZdxYMnyCuYhu6FrqjCFIr1DUjUALvw
> a=ssrc:2365215248 label:61ZdxYMnyCuYhu6FrqjCFIr1DUjUALvwa0
> a=ice-ufrag:zqC4ZTWsD5d4Hyqa
> a=ice-pwd:IQ0IT35osh0bq7bPoDKenwwR
> a=candidate:9358589392 1 udp 659136 38.109.82.228 21882 typ host generation 0
> a=candidate:9358589392 2 udp 659134 38.109.82.228 21883 typ host generation 0
> m=video 23680 UDP/TLS/RTP/SAVPF 126
> b=AS:256
> a=rtpmap:126 H264/90000
> a=fmtp:126 profile-level-id=42e01f;packetization-mode=1
> a=recvonly
> a=fingerprint:sha-256 D6:87:51:92:F6:80:BE:0D:5B:9A:97:C3:53:A7:40:C5:A2:19:60:CA:48:2D:18:A2:53:AF:B6:E1:4E:02:39:D2
> a=rtcp:23681 IN IP4 38.109.82.228
> a=rtcp-fb:* fir pli
> a=ssrc:1652571152 cname:CkzZ9cdxFymMTiha
> a=ssrc:1652571152 msid:61ZdxYMnyCuYhu6FrqjCFIr1DUjUALvw v0
> a=ssrc:1652571152 mslabel:61ZdxYMnyCuYhu6FrqjCFIr1DUjUALvw
> a=ssrc:1652571152 label:61ZdxYMnyCuYhu6FrqjCFIr1DUjUALvwv0
> a=ice-ufrag:kirEYQCPyInSpi7Y
> a=ice-pwd:fbIhKWJB3fFuGVyQ4QlSwNxU
> a=candidate:9055446981 1 udp 659136 38.109.82.228 23680 typ host generation 0
> a=candidate:9055446981 2 udp 659134 38.109.82.228 23681 typ host generation 0
>
> We offer:
>
> a=rtpmap:120 VP8/90000
> a=rtpmap:126 H264/90000
>
> and we accept:
>
> a=rtpmap:126 H264/90000
>
> Note that this is on Firefox 35.0.1.
> Response
>
> While this call is up, I run show channels in fs_cli and get the
> following:
>
> uuid,direction,created,created_epoch,name,state,cid_name,cid_num,ip_addr,dest,application,application_data,dialplan,context,read_codec,read_rate,read_bit_rate,write_codec,write_rate,write_bit_rate,secure,hostname,presence_id,presence_data,callstate,callee_name,callee_num,callee_direction,call_uuid,sent_callee_name,sent_callee_num
> b41772a4-c11b-11e4-a78f-7585ed98a76c,inbound,2015-03-02 20:35:45,1425328545,sofia/sip0/bender at cyberdyne.onsip.com,CS_SOFT_EXECUTE,Bender Rodriguez,bender,38.109.82.167,queuecard,uuid_bridge,bc7c6d64-c11b-11e4-a798-7585ed98a76c,XML,default,opus,48000,0,opus,48000,0,srtp:dtls:AES_CM_128_HMAC_SHA1_80,app-server2-1.55-broad-1.jnctn.net,,,ACTIVE,Outbound Call,terabithia,SEND,b41772a4-c11b-11e4-a78f-7585ed98a76c,Outbound Call,terabithia
> bc7c6d64-c11b-11e4-a798-7585ed98a76c,outbound,2015-03-02 20:35:59,1425328559,sofia/app/c3po at cyberdyne.onsip.com,CS_EXCHANGE_MEDIA,Bender Rodriguez,bender,38.109.82.167,1000,uuid_bridge,b41772a4-c11b-11e4-a78f-7585ed98a76c,XML,generic-app,opus,48000,0,opus,48000,0,,app-server2-1.55-broad-1.jnctn.net,,,ACTIVE,Outbound Call,terabithia,SEND,b41772a4-c11b-11e4-a78f-7585ed98a76c,Bender Rodriguez,bender
> bc80f1f4-c11b-11e4-a7a0-7585ed98a76c,inbound,2015-03-02 20:35:59,1425328559,sofia/sip0/bender at cyberdyne.onsip.com,CS_EXECUTE,Bender Rodriguez,bender,38.109.82.167,gl8k15o7,bridge,{force_transfer_context=refer}sofia/sip0/sip:gl8k15o7 at e6kin9qicasi.invalid;transport=ws;aor=c3po%40cyberdyne.onsip.com,XML,default,opus,48000,0,opus,48000,0,,app-server2-1.55-broad-1.jnctn.net,,,ACTIVE,Outbound Call,gl8k15o7,SEND,bc80f1f4-c11b-11e4-a7a0-7585ed98a76c,Outbound Call,gl8k15o7
> bc82805a-c11b-11e4-a7ae-7585ed98a76c,outbound,2015-03-02 20:35:59,1425328559,sofia/sip0/sip:gl8k15o7 at e6kin9qicasi.invalid,CS_EXCHANGE_MEDIA,Bender Rodriguez,bender,38.109.82.167,gl8k15o7,,,XML,default,opus,48000,0,opus,48000,0,srtp:dtls:AES_CM_128_HMAC_SHA1_80,app-server2-1.55-broad-1.jnctn.net,,,ACTIVE,Outbound Call,gl8k15o7,SEND,bc80f1f4-c11b-11e4-a7a0-7585ed98a76c,Bender Rodriguez,bender
>
> The read codecs and write codecs are OPUS, except for a websocket
> transport that lists an XML codec, I think. Is something up with my setup,
> or do we only show the audio codec being used when we run the show
> channels command? Any other idea for how to determine whether a
> Freeswitch channel is using video? I’m trying to stay away from sending
> custom headers and I want to be able to figure this out within Freeswitch.
> In other words, I don’t want a receiving application to try to figure out
> whether it is in video or not. I just want to query my Freeswitch service
> to find out.
>
> Thanks, guys! I appreciate any help.
> 
>
> --
> Dylan Mikus
> Software Engineer
> OnSIP
> www.onsip.com
> p. 212.933.9190 x7060
> SIP/Email: dylan at onsip.com
>

-- 
Dylan Mikus
Software Engineer
OnSIP
www.onsip.com
p. 212.933.9190 x7060
SIP/Email: dylan at onsip.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20150302/300ac906/attachment-0001.html 