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

Tue Mar 3 18:35:47 MSK 2015

So, poking around, I might have found a solution:

eval uuid:<THE_CHANNEL_UUID> ${variable_video_read_codec}

Other possible variables to check:

variable_video_possible
variable_video_read_codec
variable_video_write_codec
variable_rtp_last_video_codec_string
variable_rtp_use_video_codec_name
variable_rtp_use_video_codec_fmtp

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

> 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
>

-- 
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/20150303/39322460/attachment-0001.html 