Menu
▾
▴
tiprotocol-askcisco — Questions about Cisco's use of TIP or Profile
You can subscribe to this list here.
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
(18) |
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
(8) |
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2012 |
Jan
|
Feb
(5) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(5) |
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Nathan B. (nbuckles) <nbu...@ci...> - 2012-08-01 13:27:27
|
hi oren, it will depend on the TIP version in use between the CTS and your side. if you are using TIP version 7, then the presentation information will appear in the 'shared positions' field. this will only appear in the video MUXCTRL and not the audio. hope that helps. nathan. On Aug 1, 2012, at 1:13 PM, Oren Bakshe wrote: Hi Nathan, Small issue regarding the presentation: The CTS (1.8) does not send in its MUXCTRL packet any indication for presentation. I would expected that the “xmit positions” and “rcv positions” will contain “Aux 5fps” or “Aux 30fps” information in case CTS support presentation. Is this a bug? Thanks, Oren. |
|
From: Oren B. <or...@av...> - 2012-08-01 12:14:33
|
Hi Nathan, Small issue regarding the presentation: The CTS (1.8) does not send in its MUXCTRL packet any indication for presentation. I would expected that the "xmit positions" and "rcv positions" will contain "Aux 5fps" or "Aux 30fps" information in case CTS support presentation. Is this a bug? Thanks, Oren. |
|
From: Nathan B. (nbuckles) <nbu...@ci...> - 2012-07-30 16:56:24
|
hi oren, the library is incomplete regarding initiating the transmission of ECHO packets. while initiating ECHO transmission is not required by the protocol, it is the recommended practice, so the library should probably be updated to support that. nathan. On Jul 30, 2012, at 11:49 AM, Oren Bakshe wrote: > Hi Nathan, > Thanks for the info. > Can you tell what is the reason that sending ECHO packets is not handled by the TIP library (like feedback packets)? > > Thanks, > Oren. > > From: Nathan Buckles (nbuckles) [mailto:nbu...@ci...] > Sent: Monday, July 30, 2012 12:26 PM > To: Oren Bakshe > Cc: David Benham (dbenham); Eyal Sayar; Balaji Villupuram (bvillupu); Murthy Atmakuri (muatmaku); Vijay Triplicane (vtriplic); ask-tip(mailer list); tip...@li... > Subject: Re: ECHO packets [CTMS TIP] > > hi oren, > > the TIP library does not send ECHO packets, but it does automatically respond to received ECHO packets. this is handled automatically as part of the CTip::ReceivePacket(…) api. anytime an ECHO is received the library will send back an ECHO response. if you enable RECV and XMIT logging in the library you should see the packets coming in/out. > > nathan. > > On Jul 29, 2012, at 7:54 AM, Oren Bakshe wrote: > > > Hi David, > I can do it but I don’t think it’s a CTMS issue… > CTMS doesn’t get any RTCP packets and disconnects the call. > While debugging this problem I saw we are not sending ECHO packets at all (Even when all other RTCP packets are sent and received OK). > My question is how does the TIP Library sends these ECHO packets? Which API handles sending them? > > Thanks, > Oren. > > From: David Benham (dbenham) [mailto:db...@ci...] > Sent: Friday, July 27, 2012 8:43 AM > To: Oren Bakshe; Eyal Sayar > Cc: Balaji Villupuram (bvillupu); Murthy Atmakuri (muatmaku); Vijay Triplicane (vtriplic); Nathan Buckles (nbuckles); ask-tip(mailer list) > Subject: RE: ECHO packets [CTMS TIP] > > Oren > Can you repeat this and get a pcap for us to look at, as well as the CTMS log for the same time period? Please post those at an ftp server of yours we can get to or post to one of > those (free) file transfer services (eg, dropbox.com). > > > > CTMS “An endpoint's VIDEO channel is detected not responding with 5 ECHO request”. > > From: Oren Bakshe [mailto:or...@av...] > Sent: Thursday, July 26, 2012 4:57 AM > To: David Benham (dbenham) > Cc: Murthy Atmakuri (muatmaku); Vijay Triplicane (vtriplic); Nathan Buckles (nbuckles); ask-tip(mailer list); tip...@li...; Eyal Sayar > Subject: RE: ECHO packets [CTMS TIP] > Importance: High > > Hi David, > Can you please explain how does the Tip Library sends these ECHO packets? I saw how the ECHO ACKs are being sent, but could not find how the Library send requests. > Is there an API to send ECHO packets or is it done internally? > > Our CTMS version is 1.8.3 > > Thanks, > Oren. > > From: David Benham (dbenham) [mailto:db...@ci...] > Sent: Monday, July 23, 2012 7:50 PM > To: Oren Bakshe; Eyal Sayar > Cc: Murthy Atmakuri (muatmaku); Vijay Triplicane (vtriplic); Nathan Buckles (nbuckles); ask-tip(mailer list) > Subject: RE: ECHO packets [CTMS TIP] > > Oren, Eyal > > First, you all should send e-mail to, or at least always copy, either as...@ci... or tip...@li...(use the latter e-mail address for questions about the open source TIP library). Please include one of these mail lists above rather than e-mailing only to individuals at Cisco. > > Second, the best practice (per TIP spec) is to transmit an ECHO packet once per second during a call on each UDP channel, and measure average latency over 10 second periods. Keep track of average latency changes can be useful for encoders and congestion avoidance algorithms. > > Finally, historically, CTMS’ expect responses to ECHO packets are expecting to respond to ECHO requests initiating by its attached TIP peers. Remind us what software version of CTMS you used? > > > From: Oren Bakshe [mailto:or...@av...] > Sent: Monday, July 23, 2012 7:14 AM > To: Steve Fry (sfry) > Cc: Eyal Sayar; David Benham (dbenham) > Subject: ECHO packets > > Hi Steve, > while debugging a problem with CTMS I saw in its log the following: “An endpoint's VIDEO channel is detected not responding with 5 ECHO request”. (Call disconnects afterwards) > After checking this, I realized we don’t send ECHO packets at all. We send ACK on received echo packets but do not initiate an echo request. > I thought the Tip library should be responsible for that, but did not find any relevant method. > > Is it mandatory to send these echo packets? How can I trigger them? > Can you explain the CTMS behavior when one participant (Out of 3 for example) disconnects? > > Many thanks, > Oren. > |
|
From: Oren B. <or...@av...> - 2012-07-30 10:54:02
|
Hi Nathan, Here's an example of MUXCTRL packet which I get this warning on: AUDIO RX packet dump: TYPE: MUXCTRL NTP: 14717977395807490777 VERSION: 7 PROFILE: 0 (AVP) OPTIONS: 0 XMIT: 2 (0x1002)( CENTER LEGACY ) RECV: 4 (0x101e)( CENTER LEFT RIGHT AUX LEGACY ) CONFID: 0 SHARED: 0 (0x0) WARNING numRcv (4) does not match # of rcv positions (0x101e) Thanks, Oren. From: Nathan Buckles (nbuckles) [mailto:nbu...@ci...] Sent: Monday, July 30, 2012 12:26 PM To: Oren Bakshe Cc: ask-tip(mailer list); David Benham (dbenham); Eyal Sayar; tip...@li... Subject: Re: Tip Library warning hi oren, i believe these are just warnings that can be safely ignored, but i would need to see the entire MUXCTRL packet to be sure. in either case, the library will process the message as normal so they should not cause any deeper issues. nathan. On Jul 29, 2012, at 9:13 AM, Oren Bakshe wrote: Hi, While Tip negotiation starts, I receive a MUXCTRL packet from the CTS (Version 1.8 and 1.8.3). >From the Tip Library I get the following warning: WARNING numRcv (4) does not match # of rcv positions (0x101e) Or: WARNING numRcv (7) does not match # of rcv positions (0x1d1e) (For numRcv and numXmit) Can you tell what's the problem here? Thanks, Oren. |
|
From: Oren B. <or...@av...> - 2012-07-30 10:50:22
|
Hi Nathan, Thanks for the info. Can you tell what is the reason that sending ECHO packets is not handled by the TIP library (like feedback packets)? Thanks, Oren. From: Nathan Buckles (nbuckles) [mailto:nbu...@ci...] Sent: Monday, July 30, 2012 12:26 PM To: Oren Bakshe Cc: David Benham (dbenham); Eyal Sayar; Balaji Villupuram (bvillupu); Murthy Atmakuri (muatmaku); Vijay Triplicane (vtriplic); ask-tip(mailer list); tip...@li... Subject: Re: ECHO packets [CTMS TIP] hi oren, the TIP library does not send ECHO packets, but it does automatically respond to received ECHO packets. this is handled automatically as part of the CTip::ReceivePacket(...) api. anytime an ECHO is received the library will send back an ECHO response. if you enable RECV and XMIT logging in the library you should see the packets coming in/out. nathan. On Jul 29, 2012, at 7:54 AM, Oren Bakshe wrote: Hi David, I can do it but I don't think it's a CTMS issue... CTMS doesn't get any RTCP packets and disconnects the call. While debugging this problem I saw we are not sending ECHO packets at all (Even when all other RTCP packets are sent and received OK). My question is how does the TIP Library sends these ECHO packets? Which API handles sending them? Thanks, Oren. From: David Benham (dbenham) [mailto:db...@ci...] Sent: Friday, July 27, 2012 8:43 AM To: Oren Bakshe; Eyal Sayar Cc: Balaji Villupuram (bvillupu); Murthy Atmakuri (muatmaku); Vijay Triplicane (vtriplic); Nathan Buckles (nbuckles); ask-tip(mailer list) Subject: RE: ECHO packets [CTMS TIP] Oren Can you repeat this and get a pcap for us to look at, as well as the CTMS log for the same time period? Please post those at an ftp server of yours we can get to or post to one of those (free) file transfer services (eg, dropbox.com<http://dropbox.com>). > CTMS "An endpoint's VIDEO channel is detected not responding with 5 ECHO request". From: Oren Bakshe [mailto:or...@av...] Sent: Thursday, July 26, 2012 4:57 AM To: David Benham (dbenham) Cc: Murthy Atmakuri (muatmaku); Vijay Triplicane (vtriplic); Nathan Buckles (nbuckles); ask-tip(mailer list); tip...@li...<mailto:tip...@li...>; Eyal Sayar Subject: RE: ECHO packets [CTMS TIP] Importance: High Hi David, Can you please explain how does the Tip Library sends these ECHO packets? I saw how the ECHO ACKs are being sent, but could not find how the Library send requests. Is there an API to send ECHO packets or is it done internally? Our CTMS version is 1.8.3 Thanks, Oren. From: David Benham (dbenham) [mailto:db...@ci...] Sent: Monday, July 23, 2012 7:50 PM To: Oren Bakshe; Eyal Sayar Cc: Murthy Atmakuri (muatmaku); Vijay Triplicane (vtriplic); Nathan Buckles (nbuckles); ask-tip(mailer list) Subject: RE: ECHO packets [CTMS TIP] Oren, Eyal First, you all should send e-mail to, or at least always copy, either as...@ci...<mailto:as...@ci...> or tip...@li...<mailto:tip...@li...>(use the latter e-mail address for questions about the open source TIP library). Please include one of these mail lists above rather than e-mailing only to individuals at Cisco. Second, the best practice (per TIP spec) is to transmit an ECHO packet once per second during a call on each UDP channel, and measure average latency over 10 second periods. Keep track of average latency changes can be useful for encoders and congestion avoidance algorithms. Finally, historically, CTMS' expect responses to ECHO packets are expecting to respond to ECHO requests initiating by its attached TIP peers. Remind us what software version of CTMS you used? From: Oren Bakshe [mailto:or...@av...] Sent: Monday, July 23, 2012 7:14 AM To: Steve Fry (sfry) Cc: Eyal Sayar; David Benham (dbenham) Subject: ECHO packets Hi Steve, while debugging a problem with CTMS I saw in its log the following: "An endpoint's VIDEO channel is detected not responding with 5 ECHO request". (Call disconnects afterwards) After checking this, I realized we don't send ECHO packets at all. We send ACK on received echo packets but do not initiate an echo request. I thought the Tip library should be responsible for that, but did not find any relevant method. Is it mandatory to send these echo packets? How can I trigger them? Can you explain the CTMS behavior when one participant (Out of 3 for example) disconnects? Many thanks, Oren. |
|
From: Nathan B. (nbuckles) <nbu...@ci...> - 2012-07-30 09:26:19
|
hi oren, the TIP library does not send ECHO packets, but it does automatically respond to received ECHO packets. this is handled automatically as part of the CTip::ReceivePacket(…) api. anytime an ECHO is received the library will send back an ECHO response. if you enable RECV and XMIT logging in the library you should see the packets coming in/out. nathan. On Jul 29, 2012, at 7:54 AM, Oren Bakshe wrote: Hi David, I can do it but I don’t think it’s a CTMS issue… CTMS doesn’t get any RTCP packets and disconnects the call. While debugging this problem I saw we are not sending ECHO packets at all (Even when all other RTCP packets are sent and received OK). My question is how does the TIP Library sends these ECHO packets? Which API handles sending them? Thanks, Oren. From: David Benham (dbenham) [mailto:db...@ci...] Sent: Friday, July 27, 2012 8:43 AM To: Oren Bakshe; Eyal Sayar Cc: Balaji Villupuram (bvillupu); Murthy Atmakuri (muatmaku); Vijay Triplicane (vtriplic); Nathan Buckles (nbuckles); ask-tip(mailer list) Subject: RE: ECHO packets [CTMS TIP] Oren Can you repeat this and get a pcap for us to look at, as well as the CTMS log for the same time period? Please post those at an ftp server of yours we can get to or post to one of those (free) file transfer services (eg, dropbox.com<http://dropbox.com>). > CTMS “An endpoint's VIDEO channel is detected not responding with 5 ECHO request”. From: Oren Bakshe [mailto:or...@av...] Sent: Thursday, July 26, 2012 4:57 AM To: David Benham (dbenham) Cc: Murthy Atmakuri (muatmaku); Vijay Triplicane (vtriplic); Nathan Buckles (nbuckles); ask-tip(mailer list); tip...@li...<mailto:tip...@li...>; Eyal Sayar Subject: RE: ECHO packets [CTMS TIP] Importance: High Hi David, Can you please explain how does the Tip Library sends these ECHO packets? I saw how the ECHO ACKs are being sent, but could not find how the Library send requests. Is there an API to send ECHO packets or is it done internally? Our CTMS version is 1.8.3 Thanks, Oren. From: David Benham (dbenham) [mailto:db...@ci...] Sent: Monday, July 23, 2012 7:50 PM To: Oren Bakshe; Eyal Sayar Cc: Murthy Atmakuri (muatmaku); Vijay Triplicane (vtriplic); Nathan Buckles (nbuckles); ask-tip(mailer list) Subject: RE: ECHO packets [CTMS TIP] Oren, Eyal First, you all should send e-mail to, or at least always copy, either as...@ci...<mailto:as...@ci...> or tip...@li...<mailto:tip...@li...>(use the latter e-mail address for questions about the open source TIP library). Please include one of these mail lists above rather than e-mailing only to individuals at Cisco. Second, the best practice (per TIP spec) is to transmit an ECHO packet once per second during a call on each UDP channel, and measure average latency over 10 second periods. Keep track of average latency changes can be useful for encoders and congestion avoidance algorithms. Finally, historically, CTMS’ expect responses to ECHO packets are expecting to respond to ECHO requests initiating by its attached TIP peers. Remind us what software version of CTMS you used? From: Oren Bakshe [mailto:or...@av...] Sent: Monday, July 23, 2012 7:14 AM To: Steve Fry (sfry) Cc: Eyal Sayar; David Benham (dbenham) Subject: ECHO packets Hi Steve, while debugging a problem with CTMS I saw in its log the following: “An endpoint's VIDEO channel is detected not responding with 5 ECHO request”. (Call disconnects afterwards) After checking this, I realized we don’t send ECHO packets at all. We send ACK on received echo packets but do not initiate an echo request. I thought the Tip library should be responsible for that, but did not find any relevant method. Is it mandatory to send these echo packets? How can I trigger them? Can you explain the CTMS behavior when one participant (Out of 3 for example) disconnects? Many thanks, Oren. |
|
From: Nathan B. (nbuckles) <nbu...@ci...> - 2012-07-30 09:26:11
|
hi oren, i believe these are just warnings that can be safely ignored, but i would need to see the entire MUXCTRL packet to be sure. in either case, the library will process the message as normal so they should not cause any deeper issues. nathan. On Jul 29, 2012, at 9:13 AM, Oren Bakshe wrote: Hi, While Tip negotiation starts, I receive a MUXCTRL packet from the CTS (Version 1.8 and 1.8.3). >From the Tip Library I get the following warning: WARNING numRcv (4) does not match # of rcv positions (0x101e) Or: WARNING numRcv (7) does not match # of rcv positions (0x1d1e) (For numRcv and numXmit) Can you tell what’s the problem here? Thanks, Oren. |
|
From: Thomas W. (thomwalt) <tho...@ci...> - 2012-03-16 14:49:02
|
Martin,
It is not obvious to me from the capture as to why no video is being transmitted. I suspect that the Telepresence Server does not think that TIP negotiation has completed on the video channel, as this would trigger a SIP re-INVITE and there is no such re-INVITE in the capture. I need to see the Telepresence Server event log to see if any problems are reported there.
Unfortunately you are using Telepresence Server v2.1 which is a little old now and probably is less resilient to problems in the TIP messaging. You might have more success with version 2.2 (which has been released for some time and can be downloaded for free).
Regards,
Thomas
-----Original Message-----
From: martin harcar [mailto:mar...@ev...]
Sent: 15 March 2012 17:03
To: David Benham (dbenham)
Cc: tip...@li...; Thomas Walton (thomwalt)
Subject: RE: [TIProtocol-askcisco] TIP on TP Server Info Inquiry
David & Thomas.
Sorry to bother you again.
We correctly set up our endpoint with Telepresence Server but after successful TIP negotiation are able to received from Telepresence Server just audio and no video.
I have no idea what could be wrong.
I check also bandwidth setting in telepresence server and there is set maximum 6Mbps.(both to and from endpoint) In attachment is .pcap file with communication between our endpoint and telepresence server. Hope it will be helpful to find the reason that we are able to receive just audio.
Thanks in advance for any hints.
MaRTiN.
On Mon, 2012-02-13 at 14:07 +0100, martin harcar wrote:
> David & Thomas,
>
> After we registered our endpoint with instructions bellow was able to
> received TIP packets from telepresence server.
>
> Thanks a lot
> MaRTiN.
> On Wed, 2012-02-08 at 15:19 -0800, David Benham (dbenham) wrote:
> > Have whomever is accessing the TelePresence Server following the instructions on page 75 and continuing on pages 77-79. Although this document is for TelePresence Server 2.2 (the version being usied 2.1), the wording is only slightly different but is essentially the same instruction/configuration.
> > http://www.cisco.com/en/US/docs/telepresence/infrastructure/ts/user_
> > guide/Cisco_TelePresence_Server_2-2_Product_user_guide.pdf
> >
> > When configuring the endpoint, the “Address” field should be the dial-out URI; i.e. the address the TelePresence Server would dial out to reach your endpoint. However, you are dialling into the TelePresence Server so you also need to configure one or more of the “Call-in match parameters” under “Configuration” for this endpoint. We recommend configuring the “E.164” parameter: this should be the SIP username of the endpoint (i.e. the section of the URI before the @ sign); in your pcap file your endpoint is seevogh@158.197.28.58:5060 so the E.164 should be set to “seevogh” (without the quotes).
> >
> > TelePresence Server version 2.1 will advertise mpeg4-generic in its SDP if matching a preconfigured CTS so you can use that to check the above configuration is successful.
> >
> > Page 142 refers to CTS endpoints only and can be ignored in this case.
> >
> > Thomas
> >
> > ----------------------------
> > David,
> >
> > I have no direct access to tanberg located in USA, but can find out this settings.
> > To be sure what need to be add there. Should be there our endpoint sip adress or only legacy cisco cts 500 up to cts 3210 which is mention on page 142?
> >
> > Martin.
> >
> > > -----Original Message-----
> > > From: martin harcar [mailto:mar...@ev...]
> > > Sent: Wednesday, February 08, 2012 5:24 AM
> > > To: David Benham (dbenham)
> > > Cc: tip...@li...
> > > Subject: Re: [TIProtocol-askcisco] TIP on TP Server Info Inquiry
> > > Importance: High
> > >
> > > David,
> > >
> > > Thanks for your reply.
> > > Our goal is to be TIP compatible with cisco devices.
> > > Firstly we want to achieve successful TIP communication between
> > > our
> > > tool(endpoint) and TANDBERG Telepresence Server 8710 which as I
> > > found that is compatible with TIP.
> > > What we did are follows:
> > > Make sip call with these settings:
> > > m=audio ${A_PORT} RTP/AVP 96 9 0 101
> > > b=TIAS:128000
> > > a=rtpmap:96 mpeg4-generic/48000
> > > a=fmtp:96
> > > profile-level-
> > > id=16;streamtype=5;mode=AAChbr;config=B98C00;sizeLength=13;indexLe
> > > ng
> > > th=3;indexDeltaLength=3;constantDuration=480
> > > a=rtpmap:9 G722/8000
> > > a=rtpmap:0 PCMU/8000
> > > a=rtpmap:101 telephone-event/8000
> > > m=video ${V_PORT} RTP/AVP 112
> > > b=AS:4096
> > > b=TIAS:4096000
> > > a=sendrecv
> > > a=rtpmap:112 H264/90000
> > > a=fmtp:112 profile-level-id=4d0028;packetization-mode=1
> > >
> > > Than did TIP negotiation on video port+1(64181 in this case) using
> > > libTIP.
> > > Here is what we get from TANDBERG Telepresence Server 8710:
> > > v=0
> > > o=CODIAN 1328705765 1328705765 IN IP4 150.199.99.228
> > > s=-
> > > i=TANDBERG Telepresence Server 8710 v2.1(1.37) c=IN IP4
> > > 150.199.99.228
> > > b=AS:1920
> > > t=0 0
> > > m=audio 51732 RTP/AVP 96 9 0 101
> > > a=rtpmap:96 MP4A-LATM/90000
> > > a=fmtp:96 profile-level-id=24;object=23;bitrate=64000
> > > a=rtpmap:9 G722/8000
> > > a=rtpmap:0 PCMU/8000/1
> > > a=rtpmap:101 telephone-event/8000
> > > a=fmtp:101 0-15
> > > a=sendrecv
> > > m=video 64180 RTP/AVP 112
> > > b=AS:1920
> > > a=rtpmap:112 H264/90000
> > > a=fmtp:112 profile-level-id=42e016;max-mbps=108000;max-fs=3600
> > > a=sendrecv
> > >
> > > but we never received any TIP packets from TANDBERG Telepresence
> > > Server
> > > 8710 and immediately after SIP call we get h264 hd720 black video
> > > with 30fps.
> > >
> > > Maybe I miss something and did it wrong way.
> > > In attachment is pcap file with communication between our endpoint
> > > and Tandberg which should be helpful.
> > > IP adress of our endpoint: 158.197.28.58 IP adress of tandberg:
> > > 150.199.99.228
> > >
> > > Hope it will be helpful to identify what is wrong in our setup.
> > > Regards
> > > Martin.
> > >
> > > On Tue, 2012-02-07 at 10:20 -0800, David Benham (dbenham) wrote:
> > > > Martin
> > > > Since your question is specific to Cisco's TIP implementation,
> > > > you should
> > > send your questions to the open source project mail specific to
> > > asking Cisco questions ...
> > > >
> > > > Email: tip...@li...
> > > > Archives:
> > > http://sourceforge.net/mailarchive/forum.php?forum_name=tiprotocol
> > > -
> > > askcisco
> > > >
> > > > Please respond with further detail about your configuration and
> > > > release
> > > numbers (endpoints, UCM, TP Server inclusive) used.
> > > >
> > > > If you have followed the profile instructions to interop with a
> > > > CTS 1.7 or
> > > earlier, meeting all the restricted video details, you will need
> > > to pre- configure your endpoint on the TP Server's 'add an
> > > endpoint' as a "Cisco CTS / Legacy Cisco CTS" per pages 75 or 142 on the user guide (see URL).
> > > >
> > > http://www.cisco.com/en/US/docs/telepresence/infrastructure/ts/use
> > > r_gu ide/Cisco_TelePresence_Server_2-2_Product_user_guide.pdf
> > > > If you have yet done that, do so and try again.
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: martin harcar [mailto:mar...@ev...]
> > > > > Sent: Friday, February 03, 2012 5:50 AM
> > > > > To: tip...@im...
> > > > > Subject: IMTC TIP Info Inquiry
> > > > >
> > > > > Hi.
> > > > >
> > > > > I am trying to make a SIP call to TANDBERG Telepresence Server
> > > > > 8710 follow the rules in TIP documentations. I was able to get
> > > > > HD video but did not receive any TIP rtcp packet.
> > > > > Is some specific port used for TIP negotiation?
> > > > > I did TIP negotiation on local receive audio/video and remote
> > > > > receive audio/video ports get from sip call. Than I try to use
> > > > > ports+1 on both side. In both cases I did not receive any TIP rtcp packets.
> > > > > I am using for tip negotiation open source TIP library and
> > > > > tested it between my two endpoints and works OK.
> > > > >
> > > > > Thanks for any answer.
> > > > > Regards
> > > > > Martin.
> > > >
> >
>
>
|
|
From: martin h. <mar...@ev...> - 2012-02-13 13:07:33
|
David & Thomas, After we registered our endpoint with instructions bellow was able to received TIP packets from telepresence server. Thanks a lot MaRTiN. On Wed, 2012-02-08 at 15:19 -0800, David Benham (dbenham) wrote: > Have whomever is accessing the TelePresence Server following the instructions on page 75 and continuing on pages 77-79. Although this document is for TelePresence Server 2.2 (the version being usied 2.1), the wording is only slightly different but is essentially the same instruction/configuration. > http://www.cisco.com/en/US/docs/telepresence/infrastructure/ts/user_guide/Cisco_TelePresence_Server_2-2_Product_user_guide.pdf > > When configuring the endpoint, the “Address” field should be the dial-out URI; i.e. the address the TelePresence Server would dial out to reach your endpoint. However, you are dialling into the TelePresence Server so you also need to configure one or more of the “Call-in match parameters” under “Configuration” for this endpoint. We recommend configuring the “E.164” parameter: this should be the SIP username of the endpoint (i.e. the section of the URI before the @ sign); in your pcap file your endpoint is seevogh@158.197.28.58:5060 so the E.164 should be set to “seevogh” (without the quotes). > > TelePresence Server version 2.1 will advertise mpeg4-generic in its SDP if matching a preconfigured CTS so you can use that to check the above configuration is successful. > > Page 142 refers to CTS endpoints only and can be ignored in this case. > > Thomas > > ---------------------------- > David, > > I have no direct access to tanberg located in USA, but can find out this settings. > To be sure what need to be add there. Should be there our endpoint sip adress or only legacy cisco cts 500 up to cts 3210 which is mention on page 142? > > Martin. > > > -----Original Message----- > > From: martin harcar [mailto:mar...@ev...] > > Sent: Wednesday, February 08, 2012 5:24 AM > > To: David Benham (dbenham) > > Cc: tip...@li... > > Subject: Re: [TIProtocol-askcisco] TIP on TP Server Info Inquiry > > Importance: High > > > > David, > > > > Thanks for your reply. > > Our goal is to be TIP compatible with cisco devices. > > Firstly we want to achieve successful TIP communication between our > > tool(endpoint) and TANDBERG Telepresence Server 8710 which as I found > > that is compatible with TIP. > > What we did are follows: > > Make sip call with these settings: > > m=audio ${A_PORT} RTP/AVP 96 9 0 101 > > b=TIAS:128000 > > a=rtpmap:96 mpeg4-generic/48000 > > a=fmtp:96 > > profile-level- > > id=16;streamtype=5;mode=AAChbr;config=B98C00;sizeLength=13;indexLeng > > th=3;indexDeltaLength=3;constantDuration=480 > > a=rtpmap:9 G722/8000 > > a=rtpmap:0 PCMU/8000 > > a=rtpmap:101 telephone-event/8000 > > m=video ${V_PORT} RTP/AVP 112 > > b=AS:4096 > > b=TIAS:4096000 > > a=sendrecv > > a=rtpmap:112 H264/90000 > > a=fmtp:112 profile-level-id=4d0028;packetization-mode=1 > > > > Than did TIP negotiation on video port+1(64181 in this case) using > > libTIP. > > Here is what we get from TANDBERG Telepresence Server 8710: > > v=0 > > o=CODIAN 1328705765 1328705765 IN IP4 150.199.99.228 > > s=- > > i=TANDBERG Telepresence Server 8710 v2.1(1.37) > > c=IN IP4 150.199.99.228 > > b=AS:1920 > > t=0 0 > > m=audio 51732 RTP/AVP 96 9 0 101 > > a=rtpmap:96 MP4A-LATM/90000 > > a=fmtp:96 profile-level-id=24;object=23;bitrate=64000 > > a=rtpmap:9 G722/8000 > > a=rtpmap:0 PCMU/8000/1 > > a=rtpmap:101 telephone-event/8000 > > a=fmtp:101 0-15 > > a=sendrecv > > m=video 64180 RTP/AVP 112 > > b=AS:1920 > > a=rtpmap:112 H264/90000 > > a=fmtp:112 profile-level-id=42e016;max-mbps=108000;max-fs=3600 > > a=sendrecv > > > > but we never received any TIP packets from TANDBERG Telepresence Server > > 8710 and immediately after SIP call we get h264 hd720 black video with > > 30fps. > > > > Maybe I miss something and did it wrong way. > > In attachment is pcap file with communication between our endpoint and > > Tandberg which should be helpful. > > IP adress of our endpoint: 158.197.28.58 > > IP adress of tandberg: 150.199.99.228 > > > > Hope it will be helpful to identify what is wrong in our setup. > > Regards > > Martin. > > > > On Tue, 2012-02-07 at 10:20 -0800, David Benham (dbenham) wrote: > > > Martin > > > Since your question is specific to Cisco's TIP implementation, you should > > send your questions to the open source project mail specific to asking Cisco > > questions ... > > > > > > Email: tip...@li... > > > Archives: > > http://sourceforge.net/mailarchive/forum.php?forum_name=tiprotocol- > > askcisco > > > > > > Please respond with further detail about your configuration and release > > numbers (endpoints, UCM, TP Server inclusive) used. > > > > > > If you have followed the profile instructions to interop with a CTS 1.7 or > > earlier, meeting all the restricted video details, you will need to pre- > > configure your endpoint on the TP Server's 'add an endpoint' as a "Cisco CTS > > / Legacy Cisco CTS" per pages 75 or 142 on the user guide (see URL). > > > > > http://www.cisco.com/en/US/docs/telepresence/infrastructure/ts/user_gu > > ide/Cisco_TelePresence_Server_2-2_Product_user_guide.pdf > > > If you have yet done that, do so and try again. > > > > > > > > > > -----Original Message----- > > > > From: martin harcar [mailto:mar...@ev...] > > > > Sent: Friday, February 03, 2012 5:50 AM > > > > To: tip...@im... > > > > Subject: IMTC TIP Info Inquiry > > > > > > > > Hi. > > > > > > > > I am trying to make a SIP call to TANDBERG Telepresence Server 8710 > > > > follow the rules in TIP documentations. I was able to get HD video but > > > > did not receive any TIP rtcp packet. > > > > Is some specific port used for TIP negotiation? > > > > I did TIP negotiation on local receive audio/video and remote receive > > > > audio/video ports get from sip call. Than I try to use ports+1 on both > > > > side. In both cases I did not receive any TIP rtcp packets. > > > > I am using for tip negotiation open source TIP library and tested it > > > > between my two endpoints and works OK. > > > > > > > > Thanks for any answer. > > > > Regards > > > > Martin. > > > > |
|
From: David B. (dbenham) <db...@ci...> - 2012-02-08 23:21:04
|
Have whomever is accessing the TelePresence Server following the instructions on page 75 and continuing on pages 77-79. Although this document is for TelePresence Server 2.2 (the version being usied 2.1), the wording is only slightly different but is essentially the same instruction/configuration. http://www.cisco.com/en/US/docs/telepresence/infrastructure/ts/user_guide/Cisco_TelePresence_Server_2-2_Product_user_guide.pdf When configuring the endpoint, the “Address” field should be the dial-out URI; i.e. the address the TelePresence Server would dial out to reach your endpoint. However, you are dialling into the TelePresence Server so you also need to configure one or more of the “Call-in match parameters” under “Configuration” for this endpoint. We recommend configuring the “E.164” parameter: this should be the SIP username of the endpoint (i.e. the section of the URI before the @ sign); in your pcap file your endpoint is seevogh@158.197.28.58:5060 so the E.164 should be set to “seevogh” (without the quotes). TelePresence Server version 2.1 will advertise mpeg4-generic in its SDP if matching a preconfigured CTS so you can use that to check the above configuration is successful. Page 142 refers to CTS endpoints only and can be ignored in this case. Thomas ---------------------------- David, I have no direct access to tanberg located in USA, but can find out this settings. To be sure what need to be add there. Should be there our endpoint sip adress or only legacy cisco cts 500 up to cts 3210 which is mention on page 142? Martin. > -----Original Message----- > From: martin harcar [mailto:mar...@ev...] > Sent: Wednesday, February 08, 2012 5:24 AM > To: David Benham (dbenham) > Cc: tip...@li... > Subject: Re: [TIProtocol-askcisco] TIP on TP Server Info Inquiry > Importance: High > > David, > > Thanks for your reply. > Our goal is to be TIP compatible with cisco devices. > Firstly we want to achieve successful TIP communication between our > tool(endpoint) and TANDBERG Telepresence Server 8710 which as I found > that is compatible with TIP. > What we did are follows: > Make sip call with these settings: > m=audio ${A_PORT} RTP/AVP 96 9 0 101 > b=TIAS:128000 > a=rtpmap:96 mpeg4-generic/48000 > a=fmtp:96 > profile-level- > id=16;streamtype=5;mode=AAChbr;config=B98C00;sizeLength=13;indexLeng > th=3;indexDeltaLength=3;constantDuration=480 > a=rtpmap:9 G722/8000 > a=rtpmap:0 PCMU/8000 > a=rtpmap:101 telephone-event/8000 > m=video ${V_PORT} RTP/AVP 112 > b=AS:4096 > b=TIAS:4096000 > a=sendrecv > a=rtpmap:112 H264/90000 > a=fmtp:112 profile-level-id=4d0028;packetization-mode=1 > > Than did TIP negotiation on video port+1(64181 in this case) using > libTIP. > Here is what we get from TANDBERG Telepresence Server 8710: > v=0 > o=CODIAN 1328705765 1328705765 IN IP4 150.199.99.228 > s=- > i=TANDBERG Telepresence Server 8710 v2.1(1.37) > c=IN IP4 150.199.99.228 > b=AS:1920 > t=0 0 > m=audio 51732 RTP/AVP 96 9 0 101 > a=rtpmap:96 MP4A-LATM/90000 > a=fmtp:96 profile-level-id=24;object=23;bitrate=64000 > a=rtpmap:9 G722/8000 > a=rtpmap:0 PCMU/8000/1 > a=rtpmap:101 telephone-event/8000 > a=fmtp:101 0-15 > a=sendrecv > m=video 64180 RTP/AVP 112 > b=AS:1920 > a=rtpmap:112 H264/90000 > a=fmtp:112 profile-level-id=42e016;max-mbps=108000;max-fs=3600 > a=sendrecv > > but we never received any TIP packets from TANDBERG Telepresence Server > 8710 and immediately after SIP call we get h264 hd720 black video with > 30fps. > > Maybe I miss something and did it wrong way. > In attachment is pcap file with communication between our endpoint and > Tandberg which should be helpful. > IP adress of our endpoint: 158.197.28.58 > IP adress of tandberg: 150.199.99.228 > > Hope it will be helpful to identify what is wrong in our setup. > Regards > Martin. > > On Tue, 2012-02-07 at 10:20 -0800, David Benham (dbenham) wrote: > > Martin > > Since your question is specific to Cisco's TIP implementation, you should > send your questions to the open source project mail specific to asking Cisco > questions ... > > > > Email: tip...@li... > > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_name=tiprotocol- > askcisco > > > > Please respond with further detail about your configuration and release > numbers (endpoints, UCM, TP Server inclusive) used. > > > > If you have followed the profile instructions to interop with a CTS 1.7 or > earlier, meeting all the restricted video details, you will need to pre- > configure your endpoint on the TP Server's 'add an endpoint' as a "Cisco CTS > / Legacy Cisco CTS" per pages 75 or 142 on the user guide (see URL). > > > http://www.cisco.com/en/US/docs/telepresence/infrastructure/ts/user_gu > ide/Cisco_TelePresence_Server_2-2_Product_user_guide.pdf > > If you have yet done that, do so and try again. > > > > > > > -----Original Message----- > > > From: martin harcar [mailto:mar...@ev...] > > > Sent: Friday, February 03, 2012 5:50 AM > > > To: tip...@im... > > > Subject: IMTC TIP Info Inquiry > > > > > > Hi. > > > > > > I am trying to make a SIP call to TANDBERG Telepresence Server 8710 > > > follow the rules in TIP documentations. I was able to get HD video but > > > did not receive any TIP rtcp packet. > > > Is some specific port used for TIP negotiation? > > > I did TIP negotiation on local receive audio/video and remote receive > > > audio/video ports get from sip call. Than I try to use ports+1 on both > > > side. In both cases I did not receive any TIP rtcp packets. > > > I am using for tip negotiation open source TIP library and tested it > > > between my two endpoints and works OK. > > > > > > Thanks for any answer. > > > Regards > > > Martin. > > |
|
From: martin h. <mar...@ev...> - 2012-02-08 13:50:14
|
David,
Thanks for your reply.
Our goal is to be TIP compatible with cisco devices.
Firstly we want to achieve successful TIP communication between our
tool(endpoint) and TANDBERG Telepresence Server 8710 which as I found
that is compatible with TIP.
What we did are follows:
Make sip call with these settings:
m=audio ${A_PORT} RTP/AVP 96 9 0 101
b=TIAS:128000
a=rtpmap:96 mpeg4-generic/48000
a=fmtp:96
profile-level-id=16;streamtype=5;mode=AAChbr;config=B98C00;sizeLength=13;indexLength=3;indexDeltaLength=3;constantDuration=480
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
m=video ${V_PORT} RTP/AVP 112
b=AS:4096
b=TIAS:4096000
a=sendrecv
a=rtpmap:112 H264/90000
a=fmtp:112 profile-level-id=4d0028;packetization-mode=1
Than did TIP negotiation on video port+1(64181 in this case) using
libTIP.
Here is what we get from TANDBERG Telepresence Server 8710:
v=0
o=CODIAN 1328705765 1328705765 IN IP4 150.199.99.228
s=-
i=TANDBERG Telepresence Server 8710 v2.1(1.37)
c=IN IP4 150.199.99.228
b=AS:1920
t=0 0
m=audio 51732 RTP/AVP 96 9 0 101
a=rtpmap:96 MP4A-LATM/90000
a=fmtp:96 profile-level-id=24;object=23;bitrate=64000
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000/1
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
m=video 64180 RTP/AVP 112
b=AS:1920
a=rtpmap:112 H264/90000
a=fmtp:112 profile-level-id=42e016;max-mbps=108000;max-fs=3600
a=sendrecv
but we never received any TIP packets from TANDBERG Telepresence Server
8710 and immediately after SIP call we get h264 hd720 black video with
30fps.
Maybe I miss something and did it wrong way.
In attachment is pcap file with communication between our endpoint and
Tandberg which should be helpful.
IP adress of our endpoint: 158.197.28.58
IP adress of tandberg: 150.199.99.228
Hope it will be helpful to identify what is wrong in our setup.
Regards
Martin.
On Tue, 2012-02-07 at 10:20 -0800, David Benham (dbenham) wrote:
> Martin
> Since your question is specific to Cisco's TIP implementation, you should send your questions to the open source project mail specific to asking Cisco questions ...
>
> Email: tip...@li...
> Archives: http://sourceforge.net/mailarchive/forum.php?forum_name=tiprotocol-askcisco
>
> Please respond with further detail about your configuration and release numbers (endpoints, UCM, TP Server inclusive) used.
>
> If you have followed the profile instructions to interop with a CTS 1.7 or earlier, meeting all the restricted video details, you will need to pre-configure your endpoint on the TP Server's 'add an endpoint' as a "Cisco CTS / Legacy Cisco CTS" per pages 75 or 142 on the user guide (see URL).
> http://www.cisco.com/en/US/docs/telepresence/infrastructure/ts/user_guide/Cisco_TelePresence_Server_2-2_Product_user_guide.pdf
> If you have yet done that, do so and try again.
>
>
> > -----Original Message-----
> > From: martin harcar [mailto:mar...@ev...]
> > Sent: Friday, February 03, 2012 5:50 AM
> > To: tip...@im...
> > Subject: IMTC TIP Info Inquiry
> >
> > Hi.
> >
> > I am trying to make a SIP call to TANDBERG Telepresence Server 8710
> > follow the rules in TIP documentations. I was able to get HD video but
> > did not receive any TIP rtcp packet.
> > Is some specific port used for TIP negotiation?
> > I did TIP negotiation on local receive audio/video and remote receive
> > audio/video ports get from sip call. Than I try to use ports+1 on both
> > side. In both cases I did not receive any TIP rtcp packets.
> > I am using for tip negotiation open source TIP library and tested it
> > between my two endpoints and works OK.
> >
> > Thanks for any answer.
> > Regards
> > Martin.
>
|
|
From: David B. (dbenham) <db...@ci...> - 2012-02-07 18:21:10
|
Martin
Since your question is specific to Cisco's TIP implementation, you should send your questions to the open source project mail specific to asking Cisco questions ...
Email: tip...@li...
Archives: http://sourceforge.net/mailarchive/forum.php?forum_name=tiprotocol-askcisco
Please respond with further detail about your configuration and release numbers (endpoints, UCM, TP Server inclusive) used.
If you have followed the profile instructions to interop with a CTS 1.7 or earlier, meeting all the restricted video details, you will need to pre-configure your endpoint on the TP Server's 'add an endpoint' as a "Cisco CTS / Legacy Cisco CTS" per pages 75 or 142 on the user guide (see URL).
http://www.cisco.com/en/US/docs/telepresence/infrastructure/ts/user_guide/Cisco_TelePresence_Server_2-2_Product_user_guide.pdf
If you have yet done that, do so and try again.
> -----Original Message-----
> From: martin harcar [mailto:mar...@ev...]
> Sent: Friday, February 03, 2012 5:50 AM
> To: tip...@im...
> Subject: IMTC TIP Info Inquiry
>
> Hi.
>
> I am trying to make a SIP call to TANDBERG Telepresence Server 8710
> follow the rules in TIP documentations. I was able to get HD video but
> did not receive any TIP rtcp packet.
> Is some specific port used for TIP negotiation?
> I did TIP negotiation on local receive audio/video and remote receive
> audio/video ports get from sip call. Than I try to use ports+1 on both
> side. In both cases I did not receive any TIP rtcp packets.
> I am using for tip negotiation open source TIP library and tested it
> between my two endpoints and works OK.
>
> Thanks for any answer.
> Regards
> Martin.
|
|
From: Aravind S. <ara...@te...> - 2011-09-21 20:26:54
|
Hi David Thank you....We will investigate and fix this... as ever, much appreciative Aravind Sethuraman Chief Software Architect Teliris, Inc. 55 Broadway, 14th Floor, New York, NY 10006 C +1.917.355.0119 | O +1.212.490.1065 x1408 | F +1.212.269.2869 On 09/21/2011 04:24 PM, David Benham (dbenham) wrote: > > Aravind > > What the logs indicate to us is; > > - 26 out of 17956 NALs where bad, perhaps because they were larger > than 3320 (item 10). > > - inter-frame RTP timestamp increments do not show as a multiple of > 3003 or 3000 (item 5) > > (log entry at 2011-09-19 15:53:30.271: shows rtp timestamp diff > detected 6300). > > - The TIP negotiation status indicates your endpoint (the TIP peer) > supports LTRP (item 13) and GDR (item 14), but none were received of > either (you said "ignored," so you should probably negotiate those off). > > What the logs cannot tell us is your encoder is adhering to items 8, 9 > and 11, which are required by our decoder. > > *From:*Aravind Sethuraman [mailto:ara...@te...] > *Sent:* Wednesday, September 21, 2011 10:25 AM > *To:* Aravind Sethuraman > *Cc:* David Benham (dbenham); Girish Kondappa; > tip...@li... > *Subject:* Re: TIP Encoder Setting issue (Teliris) > > Hi David and TIPers @ cisco > > any further update on the decode logs? > > Aravind Sethuraman > Chief Software Architect > Teliris, Inc. > 55 Broadway, 14th Floor, New York, NY 10006 > C +1.917.355.0119 | O +1.212.490.1065 x1408 | F +1.212.269.2869 > > > On 09/19/2011 01:29 PM, Aravind Sethuraman wrote: > > Folks > > Sorry for the delay in getting the logs back to you as i was off in > conference > attached is the video logs generated from the CTS 1000 whilst in call... > > http://db.tt/hz6ocbL > > > Hopefully you guys will be able to provided us further insight into > the quality issue > > > On Sep 8, 2011, at 11:00 PM, David Benham (dbenham) wrote: > > > > Hello Aravind > > From a quick, cursory analysis of what you said/described, it seems > that at least #9, 10 and 11 are probably being not being adhered to by > the encoder ... and thus need find a way to enable those restrictions. > > Could you pull a copy the CTS' CMA logs and send back to us (or > provide a link to a drop box we can fetch them from)? > > *From:*Aravind Sethuraman [mailto:ara...@te...] > *Sent:*Tuesday, September 06, 2011 8:08 AM > *Cc:*David Benham (dbenham);tip...@li... > <mailto:tip...@li...>; Girish Kondappa > *Subject:*TIP Encoder Setting issue > > Hi David et al @ cisco tip, > > We have been trying to interop our TIP Client with a CTS 1000 and > whilst we are able to make calls from our TIP Client to CTS 1000m we > are seeing quality issue in the CTS decode. The CTS video is getting > decoded fine in our TIP Client. So we are wondering if CTS 1000 is > extremly strict and we are missing out some encoder settings. > > > If possible,Please share the encoder settings that could troubleshoot > the problem. > > > We are referring 1.6b profile to set the settings in our encoder and > support the following wrt the encoding standard > > > 1. MUST generate H264 Main Profile or High Profile (HiP), if > negotiated, compatible bit stream :*Using MAIN PROFILE* > > 2. MUST support CALVC > > 3. MAY support CABAC as a negotiated option*Using CABAC* > > 4. MUST support 1280x720 or 1920x1080 resolution*Using 1280x720* > > 5. MUST support fixed frame rate: 30 fps or 29.97 fps*Configured to > use 30fps* > > 6. MUST generate one macro block-row per slice > > -1280x720: 45 slices per frame, each slice must be 80 macro blocks in > length*Using 45 * 80* > > -1920x1072: 67 slices per frame, each slice must be 120 macro blocks > in length > > 7. MUST support deblocking_filter_control_present = 1 & > disable_deblocking_filter_idc = 1Added > > 8. MUST only use inter-prediction blocks of size 16x16*Couldn't find > this setting in our encoder* > > 9. MUST only use one reference picture and that reference picture must > be the immediate previous frame or a long term reference > picture*Couldn't find this setting in our encoder* > > 10. Each NAL MUST be less than 3320 bytes in size*Couldn't find this > setting in our encoder* > > 11. POC (Picture Order Count) MUST increment by 2 every frame*Couldn't > find this setting in our encoder* > > 12. MUST NOT USE SPS IDs in the range of 10 to 20*Uses 0* > > 13. Long term reference pictures (LTRPs) MAY be used for error > concealment. LTRPs requires max_num_ref_frames>=3. LTRPs use H.264 > standard picture buffer management. MUST support long_term_frame_idx < > 2, MUST use memory_management_control_operation = 6. LTRPs are > optional and can be disabled.Ignored > > 14. Gradual decoder refresh pictures (GDRs) MAY be used at the start > of a sequence instead of an instantaneous decoder refresh picture > (IDR). A recovery point SEI precedes the GDR. The SEI always has the > broken_link_flag set to 0. GDRs are optional and can be disabled.Ignored > > 15. When high profile is negotiated, MUST support > seq_scaling_matrix_present_flag=0 and > pic_scaling_matrix_present_flag=0, MUST NOT use monochrome pictures, > MUST NOT use quantization matrices.Ignored > > Observations: > > 1.When we use GOP length > 1 We see poor jitter status in the CTS and > the video is bad. > > 2.We always see the black strip exactly at 2/3 from the top in the > screen. And Sometimes we have seen this strip slice catching up > late.. But most of the time it remains black... > > It looks like CTS Decoder is expecting specific AVC bit stream that > our encoder is not able to send.. > > There are few settings above ignored and some couldn't configure in > our encoder. Is that is causing the quality issue? > Also, is it possible to provide a guidance as to how we can debug on > the CTS side for video quality issue? > > regards > > > Aravind Sethuraman > Chief Software Architect > Teliris, Inc. > 55 Broadway, 14th Floor, New York, NY 10006 > C +1.917.355.0119 | O +1.212.490.1065 x1408 | F +1.212.269.2869 > |
|
From: David B. (dbenham) <db...@ci...> - 2011-09-21 20:24:31
|
Aravind What the logs indicate to us is; - 26 out of 17956 NALs where bad, perhaps because they were larger than 3320 (item 10). - inter-frame RTP timestamp increments do not show as a multiple of 3003 or 3000 (item 5) (log entry at 2011-09-19 15:53:30.271: shows rtp timestamp diff detected 6300). - The TIP negotiation status indicates your endpoint (the TIP peer) supports LTRP (item 13) and GDR (item 14), but none were received of either (you said "ignored," so you should probably negotiate those off). What the logs cannot tell us is your encoder is adhering to items 8, 9 and 11, which are required by our decoder. From: Aravind Sethuraman [mailto:ara...@te...] Sent: Wednesday, September 21, 2011 10:25 AM To: Aravind Sethuraman Cc: David Benham (dbenham); Girish Kondappa; tip...@li... Subject: Re: TIP Encoder Setting issue (Teliris) Hi David and TIPers @ cisco any further update on the decode logs? Aravind Sethuraman Chief Software Architect Teliris, Inc. 55 Broadway, 14th Floor, New York, NY 10006 C +1.917.355.0119 | O +1.212.490.1065 x1408 | F +1.212.269.2869 On 09/19/2011 01:29 PM, Aravind Sethuraman wrote: Folks Sorry for the delay in getting the logs back to you as i was off in conference attached is the video logs generated from the CTS 1000 whilst in call... http://db.tt/hz6ocbL Hopefully you guys will be able to provided us further insight into the quality issue On Sep 8, 2011, at 11:00 PM, David Benham (dbenham) wrote: Hello Aravind >From a quick, cursory analysis of what you said/described, it seems that at least #9, 10 and 11 are probably being not being adhered to by the encoder ... and thus need find a way to enable those restrictions. Could you pull a copy the CTS' CMA logs and send back to us (or provide a link to a drop box we can fetch them from)? From: Aravind Sethuraman [mailto:ara...@te...] Sent: Tuesday, September 06, 2011 8:08 AM Cc: David Benham (dbenham); tip...@li...; Girish Kondappa Subject: TIP Encoder Setting issue Hi David et al @ cisco tip, We have been trying to interop our TIP Client with a CTS 1000 and whilst we are able to make calls from our TIP Client to CTS 1000m we are seeing quality issue in the CTS decode. The CTS video is getting decoded fine in our TIP Client. So we are wondering if CTS 1000 is extremly strict and we are missing out some encoder settings. If possible,Please share the encoder settings that could troubleshoot the problem. We are referring 1.6b profile to set the settings in our encoder and support the following wrt the encoding standard 1. MUST generate H264 Main Profile or High Profile (HiP), if negotiated, compatible bit stream : Using MAIN PROFILE 2. MUST support CALVC 3. MAY support CABAC as a negotiated option Using CABAC 4. MUST support 1280x720 or 1920x1080 resolution Using 1280x720 5. MUST support fixed frame rate: 30 fps or 29.97 fps Configured to use 30fps 6. MUST generate one macro block-row per slice -1280x720: 45 slices per frame, each slice must be 80 macro blocks in length Using 45 * 80 -1920x1072: 67 slices per frame, each slice must be 120 macro blocks in length 7. MUST support deblocking_filter_control_present = 1 & disable_deblocking_filter_idc = 1 Added 8. MUST only use inter-prediction blocks of size 16x16 Couldn't find this setting in our encoder 9. MUST only use one reference picture and that reference picture must be the immediate previous frame or a long term reference picture Couldn't find this setting in our encoder 10. Each NAL MUST be less than 3320 bytes in size Couldn't find this setting in our encoder 11. POC (Picture Order Count) MUST increment by 2 every frame Couldn't find this setting in our encoder 12. MUST NOT USE SPS IDs in the range of 10 to 20 Uses 0 13. Long term reference pictures (LTRPs) MAY be used for error concealment. LTRPs requires max_num_ref_frames>=3. LTRPs use H.264 standard picture buffer management. MUST support long_term_frame_idx < 2, MUST use memory_management_control_operation = 6. LTRPs are optional and can be disabled. Ignored 14. Gradual decoder refresh pictures (GDRs) MAY be used at the start of a sequence instead of an instantaneous decoder refresh picture (IDR). A recovery point SEI precedes the GDR. The SEI always has the broken_link_flag set to 0. GDRs are optional and can be disabled. Ignored 15. When high profile is negotiated, MUST support seq_scaling_matrix_present_flag=0 and pic_scaling_matrix_present_flag=0, MUST NOT use monochrome pictures, MUST NOT use quantization matrices. Ignored Observations: 1. When we use GOP length > 1 We see poor jitter status in the CTS and the video is bad. 2. We always see the black strip exactly at 2/3 from the top in the screen. And Sometimes we have seen this strip slice catching up late.. But most of the time it remains black... It looks like CTS Decoder is expecting specific AVC bit stream that our encoder is not able to send.. There are few settings above ignored and some couldn't configure in our encoder. Is that is causing the quality issue? Also, is it possible to provide a guidance as to how we can debug on the CTS side for video quality issue? regards Aravind Sethuraman Chief Software Architect Teliris, Inc. 55 Broadway, 14th Floor, New York, NY 10006 C +1.917.355.0119 | O +1.212.490.1065 x1408 | F +1.212.269.2869 |
|
From: Aravind S. <ara...@te...> - 2011-09-21 17:25:34
|
Hi David and TIPers @ cisco any further update on the decode logs? Aravind Sethuraman Chief Software Architect Teliris, Inc. 55 Broadway, 14th Floor, New York, NY 10006 C +1.917.355.0119 | O +1.212.490.1065 x1408 | F +1.212.269.2869 On 09/19/2011 01:29 PM, Aravind Sethuraman wrote: > Folks > > Sorry for the delay in getting the logs back to you as i was off in > conference > attached is the video logs generated from the CTS 1000 whilst in call... > > http://db.tt/hz6ocbL > > > Hopefully you guys will be able to provided us further insight into > the quality issue > > > regards > Aravind Sethuraman > Chief Software Architect > Teliris, Inc. > 55 Broadway, 14th Floor, New York, NY 10006 > C +1.917.355.0119 | O +1.212.490.1065 x1408 | F +1.212.269.2869 |
|
From: Aravind S. <set...@gm...> - 2011-09-19 17:29:50
|
Folks Sorry for the delay in getting the logs back to you as i was off in conference attached is the video logs generated from the CTS 1000 whilst in call... http://db.tt/hz6ocbL Hopefully you guys will be able to provided us further insight into the quality issue regards Aravind Sethuraman Chief Software Architect Teliris, Inc. 55 Broadway, 14th Floor, New York, NY 10006 C +1.917.355.0119 | O +1.212.490.1065 x1408 | F +1.212.269.2869 |
|
From: Aravind S. <ara...@te...> - 2011-09-19 17:21:36
|
Folks Sorry for the delay in getting the logs back to you as i was off in conference attached is the video logs generated from the CTS 1000 whilst in call... http://db.tt/hz6ocbL Hopefully you guys will be able to provided us further insight into the quality issue regards Aravind Sethuraman Chief Software Architect Teliris, Inc. 55 Broadway, 14th Floor, New York, NY 10006 C +1.917.355.0119 | O +1.212.490.1065 x1408 | F +1.212.269.2869 On 09/08/2011 11:00 PM, David Benham (dbenham) wrote: > > Hello Aravind > > From a quick, cursory analysis of what you said/described, it seems > that at least #9, 10 and 11 are probably being not being adhered to by > the encoder ... and thus need find a way to enable those restrictions. > > Could you pull a copy the CTS' CMA logs and send back to us (or > provide a link to a drop box we can fetch them from)? > > *From:*Aravind Sethuraman [mailto:ara...@te...] > *Sent:* Tuesday, September 06, 2011 8:08 AM > *Cc:* David Benham (dbenham); > tip...@li...; Girish Kondappa > *Subject:* TIP Encoder Setting issue > > Hi David et al @ cisco tip, > > We have been trying to interop our TIP Client with a CTS 1000 and > whilst we are able to make calls from our TIP Client to CTS 1000m we > are seeing quality issue in the CTS decode. The CTS video is getting > decoded fine in our TIP Client. So we are wondering if CTS 1000 is > extremly strict and we are missing out some encoder settings. > > If possible,Please share the encoder settings that could troubleshoot > the problem. > > > We are referring 1.6b profile to set the settings in our encoder and > support the following wrt the encoding standard > > 1. MUST generate H264 Main Profile or High Profile (HiP), if > negotiated, compatible bit stream : *Using MAIN PROFILE* > > 2. MUST support CALVC > > 3. MAY support CABAC as a negotiated option *Using CABAC* > > 4. MUST support 1280x720 or 1920x1080 resolution *Using 1280x720* > > 5. MUST support fixed frame rate: 30 fps or 29.97 fps *Configured to > use 30fps* > > 6. MUST generate one macro block-row per slice > > -1280x720: 45 slices per frame, each slice must be 80 macro blocks in > length *Using 45 * 80 * > > -1920x1072: 67 slices per frame, each slice must be 120 macro blocks > in length > > 7. MUST support deblocking_filter_control_present = 1 & > disable_deblocking_filter_idc = 1 Added > > 8. MUST only use inter-prediction blocks of size 16x16 *Couldn't find > this setting in our encoder* > > 9. MUST only use one reference picture and that reference picture must > be the immediate previous frame or a long term reference picture > *Couldn't find this setting in our encoder* > > 10. Each NAL MUST be less than 3320 bytes in size *Couldn't find this > setting in our encoder* > > 11. POC (Picture Order Count) MUST increment by 2 every frame > *Couldn't find this setting in our encoder* > > 12. MUST NOT USE SPS IDs in the range of 10 to 20 *Uses 0 * > > 13. Long term reference pictures (LTRPs) MAY be used for error > concealment. LTRPs requires max_num_ref_frames>=3. LTRPs use H.264 > standard picture buffer management. MUST support long_term_frame_idx < > 2, MUST use memory_management_control_operation = 6. LTRPs are > optional and can be disabled. Ignored > > 14. Gradual decoder refresh pictures (GDRs) MAY be used at the start > of a sequence instead of an instantaneous decoder refresh picture > (IDR). A recovery point SEI precedes the GDR. The SEI always has the > broken_link_flag set to 0. GDRs are optional and can be disabled.Ignored > > 15. When high profile is negotiated, MUST support > seq_scaling_matrix_present_flag=0 and > pic_scaling_matrix_present_flag=0, MUST NOT use monochrome pictures, > MUST NOT use quantization matrices.Ignored > > Observations: > > 1.When we use GOP length > 1 We see poor jitter status in the CTS and > the video is bad. > > 2.We always see the black strip exactly at 2/3 from the top in the > screen. And Sometimes we have seen this strip slice catching up > late.. But most of the time it remains black... > > It looks like CTS Decoder is expecting specific AVC bit stream that > our encoder is not able to send.. > > There are few settings above ignored and some couldn't configure in > our encoder. Is that is causing the quality issue? > Also, is it possible to provide a guidance as to how we can debug on > the CTS side for video quality issue? > > regards > > Aravind Sethuraman > Chief Software Architect > Teliris, Inc. > 55 Broadway, 14th Floor, New York, NY 10006 > C +1.917.355.0119 | O +1.212.490.1065 x1408 | F +1.212.269.2869 > |
|
From: aravind s. <ara...@te...> - 2011-09-09 17:16:02
|
Hello David Thanks for the response. Whilst we try to see if we can enhance our encoder, we will also try to get the logs.... Also is there any recommendation on how we can do the debug logging on the CTS itself ? regards Aravind On Sep 8, 2011, at 11:00 PM, David Benham (dbenham) wrote: > Hello Aravind > From a quick, cursory analysis of what you said/described, it seems that at least #9, 10 and 11 are probably being not being adhered to by the encoder … and thus need find a way to enable those restrictions. > > Could you pull a copy the CTS’ CMA logs and send back to us (or provide a link to a drop box we can fetch them from)? > > > From: Aravind Sethuraman [mailto:ara...@te...] > Sent: Tuesday, September 06, 2011 8:08 AM > Cc: David Benham (dbenham); tip...@li...; Girish Kondappa > Subject: TIP Encoder Setting issue > > Hi David et al @ cisco tip, > We have been trying to interop our TIP Client with a CTS 1000 and whilst we are able to make calls from our TIP Client to CTS 1000m we are seeing quality issue in the CTS decode. The CTS video is getting decoded fine in our TIP Client. So we are wondering if CTS 1000 is extremly strict and we are missing out some encoder settings. > > If possible,Please share the encoder settings that could troubleshoot the problem. > > We are referring 1.6b profile to set the settings in our encoder and support the following wrt the encoding standard > > 1. MUST generate H264 Main Profile or High Profile (HiP), if negotiated, compatible bit stream : Using MAIN PROFILE > 2. MUST support CALVC > 3. MAY support CABAC as a negotiated option Using CABAC > 4. MUST support 1280x720 or 1920x1080 resolution Using 1280x720 > 5. MUST support fixed frame rate: 30 fps or 29.97 fps Configured to use 30fps > 6. MUST generate one macro block-row per slice > -1280x720: 45 slices per frame, each slice must be 80 macro blocks in length Using 45 * 80 > -1920x1072: 67 slices per frame, each slice must be 120 macro blocks in length > 7. MUST support deblocking_filter_control_present = 1 & disable_deblocking_filter_idc = 1 Added > 8. MUST only use inter-prediction blocks of size 16x16 Couldn’t find this setting in our encoder > 9. MUST only use one reference picture and that reference picture must be the immediate previous frame or a long term reference picture Couldn’t find this setting in our encoder > 10. Each NAL MUST be less than 3320 bytes in size Couldn’t find this setting in our encoder > 11. POC (Picture Order Count) MUST increment by 2 every frame Couldn’t find this setting in our encoder > 12. MUST NOT USE SPS IDs in the range of 10 to 20 Uses 0 > 13. Long term reference pictures (LTRPs) MAY be used for error concealment. LTRPs requires max_num_ref_frames>=3. LTRPs use H.264 standard picture buffer management. MUST support long_term_frame_idx < 2, MUST use memory_management_control_operation = 6. LTRPs are optional and can be disabled. Ignored > 14. Gradual decoder refresh pictures (GDRs) MAY be used at the start of a sequence instead of an instantaneous decoder refresh picture (IDR). A recovery point SEI precedes the GDR. The SEI always has the broken_link_flag set to 0. GDRs are optional and can be disabled. Ignored > 15. When high profile is negotiated, MUST support seq_scaling_matrix_present_flag=0 and pic_scaling_matrix_present_flag=0, MUST NOT use monochrome pictures, MUST NOT use quantization matrices. Ignored > > Observations: > 1. When we use GOP length > 1 We see poor jitter status in the CTS and the video is bad. > > 2. We always see the black strip exactly at 2/3 from the top in the screen. And Sometimes we have seen this strip slice catching up late.. But most of the time it remains black… > > > It looks like CTS Decoder is expecting specific AVC bit stream that our encoder is not able to send.. > > There are few settings above ignored and some couldn’t configure in our encoder. Is that is causing the quality issue? > Also, is it possible to provide a guidance as to how we can debug on the CTS side for video quality issue? > regards > > Aravind Sethuraman > Chief Software Architect > Teliris, Inc. > 55 Broadway, 14th Floor, New York, NY 10006 > C +1.917.355.0119 | O +1.212.490.1065 x1408 | F +1.212.269.2869 > Aravind Sethuraman Chief Software Architect Teliris, Inc. | 55 Broadway, 14th Floor, New York, NY 10006 | C +1.917.355.0119 | O +1.212.490.1065 x1408 | F +1.212.269.2869 | AIM aravindsraman |
|
From: David B. (dbenham) <db...@ci...> - 2011-09-09 03:00:32
|
Hello Aravind >From a quick, cursory analysis of what you said/described, it seems that at least #9, 10 and 11 are probably being not being adhered to by the encoder ... and thus need find a way to enable those restrictions. Could you pull a copy the CTS' CMA logs and send back to us (or provide a link to a drop box we can fetch them from)? From: Aravind Sethuraman [mailto:ara...@te...] Sent: Tuesday, September 06, 2011 8:08 AM Cc: David Benham (dbenham); tip...@li...; Girish Kondappa Subject: TIP Encoder Setting issue Hi David et al @ cisco tip, We have been trying to interop our TIP Client with a CTS 1000 and whilst we are able to make calls from our TIP Client to CTS 1000m we are seeing quality issue in the CTS decode. The CTS video is getting decoded fine in our TIP Client. So we are wondering if CTS 1000 is extremly strict and we are missing out some encoder settings. If possible,Please share the encoder settings that could troubleshoot the problem. We are referring 1.6b profile to set the settings in our encoder and support the following wrt the encoding standard 1. MUST generate H264 Main Profile or High Profile (HiP), if negotiated, compatible bit stream : Using MAIN PROFILE 2. MUST support CALVC 3. MAY support CABAC as a negotiated option Using CABAC 4. MUST support 1280x720 or 1920x1080 resolution Using 1280x720 5. MUST support fixed frame rate: 30 fps or 29.97 fps Configured to use 30fps 6. MUST generate one macro block-row per slice -1280x720: 45 slices per frame, each slice must be 80 macro blocks in length Using 45 * 80 -1920x1072: 67 slices per frame, each slice must be 120 macro blocks in length 7. MUST support deblocking_filter_control_present = 1 & disable_deblocking_filter_idc = 1 Added 8. MUST only use inter-prediction blocks of size 16x16 Couldn't find this setting in our encoder 9. MUST only use one reference picture and that reference picture must be the immediate previous frame or a long term reference picture Couldn't find this setting in our encoder 10. Each NAL MUST be less than 3320 bytes in size Couldn't find this setting in our encoder 11. POC (Picture Order Count) MUST increment by 2 every frame Couldn't find this setting in our encoder 12. MUST NOT USE SPS IDs in the range of 10 to 20 Uses 0 13. Long term reference pictures (LTRPs) MAY be used for error concealment. LTRPs requires max_num_ref_frames>=3. LTRPs use H.264 standard picture buffer management. MUST support long_term_frame_idx < 2, MUST use memory_management_control_operation = 6. LTRPs are optional and can be disabled. Ignored 14. Gradual decoder refresh pictures (GDRs) MAY be used at the start of a sequence instead of an instantaneous decoder refresh picture (IDR). A recovery point SEI precedes the GDR. The SEI always has the broken_link_flag set to 0. GDRs are optional and can be disabled. Ignored 15. When high profile is negotiated, MUST support seq_scaling_matrix_present_flag=0 and pic_scaling_matrix_present_flag=0, MUST NOT use monochrome pictures, MUST NOT use quantization matrices. Ignored Observations: 1. When we use GOP length > 1 We see poor jitter status in the CTS and the video is bad. 2. We always see the black strip exactly at 2/3 from the top in the screen. And Sometimes we have seen this strip slice catching up late.. But most of the time it remains black... It looks like CTS Decoder is expecting specific AVC bit stream that our encoder is not able to send.. There are few settings above ignored and some couldn't configure in our encoder. Is that is causing the quality issue? Also, is it possible to provide a guidance as to how we can debug on the CTS side for video quality issue? regards Aravind Sethuraman Chief Software Architect Teliris, Inc. 55 Broadway, 14th Floor, New York, NY 10006 C +1.917.355.0119 | O +1.212.490.1065 x1408 | F +1.212.269.2869 |
|
From: Aravind S. <ara...@te...> - 2011-09-06 15:48:08
|
Hi David et al @ cisco tip, We have been trying to interop our TIP Client with a CTS 1000 and whilst we are able to make calls from our TIP Client to CTS 1000m we are seeing quality issue in the CTS decode. The CTS video is getting decoded fine in our TIP Client. So we are wondering if CTS 1000 is extremly strict and we are missing out some encoder settings. If possible,Please share the encoder settings that could troubleshoot the problem. We are referring 1.6b profile to set the settings in our encoder and support the following wrt the encoding standard 1. MUST generate H264 Main Profile or High Profile (HiP), if negotiated, compatible bit stream : *Using MAIN PROFILE* 2. MUST support CALVC 3. MAY support CABAC as a negotiated option *Using CABAC* 4. MUST support 1280x720 or 1920x1080 resolution *Using 1280x720* 5. MUST support fixed frame rate: 30 fps or 29.97 fps *Configured to use 30fps* 6. MUST generate one macro block-row per slice -1280x720: 45 slices per frame, each slice must be 80 macro blocks in length *Using 45 * 80 * -1920x1072: 67 slices per frame, each slice must be 120 macro blocks in length 7. MUST support deblocking_filter_control_present = 1 & disable_deblocking_filter_idc = 1 Added 8. MUST only use inter-prediction blocks of size 16x16 *Couldn't find this setting in our encoder* 9. MUST only use one reference picture and that reference picture must be the immediate previous frame or a long term reference picture *Couldn't find this setting in our encoder* 10. Each NAL MUST be less than 3320 bytes in size *Couldn't find this setting in our encoder* 11. POC (Picture Order Count) MUST increment by 2 every frame *Couldn't find this setting in our encoder* 12. MUST NOT USE SPS IDs in the range of 10 to 20 *Uses 0 * 13. Long term reference pictures (LTRPs) MAY be used for error concealment. LTRPs requires max_num_ref_frames>=3. LTRPs use H.264 standard picture buffer management. MUST support long_term_frame_idx < 2, MUST use memory_management_control_operation = 6. LTRPs are optional and can be disabled. Ignored 14. Gradual decoder refresh pictures (GDRs) MAY be used at the start of a sequence instead of an instantaneous decoder refresh picture (IDR). A recovery point SEI precedes the GDR. The SEI always has the broken_link_flag set to 0. GDRs are optional and can be disabled.Ignored 15. When high profile is negotiated, MUST support seq_scaling_matrix_present_flag=0 and pic_scaling_matrix_present_flag=0, MUST NOT use monochrome pictures, MUST NOT use quantization matrices.Ignored Observations: 1.When we use GOP length > 1 We see poor jitter status in the CTS and the video is bad. 2.We always see the black strip exactly at 2/3 from the top in the screen. And Sometimes we have seen this strip slice catching up late.. But most of the time it remains black... It looks like CTS Decoder is expecting specific AVC bit stream that our encoder is not able to send.. There are few settings above ignored and some couldn't configure in our encoder. Is that is causing the quality issue? Also, is it possible to provide a guidance as to how we can debug on the CTS side for video quality issue? regards Aravind Sethuraman Chief Software Architect Teliris, Inc. 55 Broadway, 14th Floor, New York, NY 10006 C +1.917.355.0119 | O +1.212.490.1065 x1408 | F +1.212.269.2869 |
|
From: David B. (dbenham) <db...@ci...> - 2011-07-06 22:32:59
|
Henry Chen Huawei Technologies Co., Ltd. A2 The Cisco TIP Implementation Profile indicates that third party encoders cannot use SPS IDs between 10 and 20 as those are reserved for use by the CTS decoders for older CTS encoder related support. So, it is normal to see a CTS encoder use one of those values. Your TIP-attached decoder should also not use, or ignore in other words, SPS ID values between 10 and 20 that may be present in CTS encoders streams. > -----Original Message----- > From: Chenhuiyong [mailto:che...@hu...] > Sent: Monday, July 04, 2011 11:25 PM > To: David Benham (dbenham) > Subject: 答复: Q to Cisco from Huawei re TIP interop > > Q2 :The second problem is that ,when we decode the RTP stream sent by > CTS3000 terminal ，our decoder throw a error code: "the SPS ID is 18". But > TIP requires “11. MUST NOT USE SPS IDs in the range of 10 to 20”. So if > there is some situation CTS terminal will use the SPS ID value 18? > > Thank you again > > Herny Chen > > |
|
From: Aravind S. <ara...@te...> - 2011-04-28 04:14:23
|
Hello all, we are seeing issues again even with the CSRC being sent. We were wondering if anyone has a sample pcap for a call flow between a cts 500/1000 and another tipua via cucm and could provide us the same. Also, is it possible if i can setup a phone call with one of you gentlemen and resolve this tricky issue we are having? regards Aravind Sethuraman Chief Software Architect Teliris, Inc. | 55 Broadway, 14th Floor, New York, NY 10006 | C +1.917.355.0119 | O +1.212.490.1065 x1408 | F +1.212.269.2869 | AIM aravindsraman On Sunday, April 24, 2011 at 9:43 PM, nermeen wrote: > Hi Aravind, > > 1.7 CTS will include SPS and PPS in its SIP signaling even when it has negotiated and is actually sending them in-band. > > nermeen > > > On 4/20/11 3:26 PM, "Aravind Sethuraman" <ara...@te...> wrote: > > Nermeen, > > We have configured the default single system as per the tip library and it does > > addVideoMediaOption(system, CTipVideoMediaOption::INBAND_PARAM_SETS, > > CTipMediaOption::OPTION_SUPPORTED_BOTH) > > in the tip_profile module. > > > > does this mean is adhering to sending inband param sets although it has signalled out-of-band in the 183? > > > > thanks > > aravind > > > > On 04/20/2011 05:36 PM, nermeen wrote: > > Re: [TIProtocol-askcisco] FW: Teliris & TIP Protocol Start-up Issues Aravind, > > > > > > Can you let us know what has been signaled in the TIP MediaOpts packet in terms of inband support? What has your device transmitted to the CTS and what has it received from the CTS? > > > > > > If the remote device has indicated support for the reception of in band signaling in its MediaOpts then the CTS will transmit inband signaling otherwise it would not. > > > > > > nermeen > > > > > > > > > On 4/20/11 1:22 PM, "David Benham (dbenham)" <db...@ci...> wrote: > > > > > > > > > Aravind > > > > Go ahead and copy the mail list ( tip...@li... ), which I have done here, so the rest of the team at Cisco sees the questions/issues, especially since I am off-site the rest of this week. > > > > > > > > > > > > > > > > From: Aravind Sethuraman [mailto:ara...@te...] > > > > Sent: Wednesday, April 20, 2011 1:12 PM > > > > To: David Benham (dbenham); Girish Kondappa > > > > Subject: Re: FW: Teliris & TIP Protocol Start-up Issues > > > > Importance: High > > > > > > > > Hi David > > > > > > > > Thank you for getting back to us. The issue was the bandwidth in CUCM - changing it enabled us to be in a call. However, we are seeing CTS is sending only out of band parameter sets but the TIP Protocol mandates that all TIP must support in band > > > > Section 5.2 point #6 > > > > Is there another configuration issue? > > > > > > > > much obliged > > > > Aravind > > > > > > > > > > > > On 04/20/2011 03:26 PM, David Benham (dbenham) wrote: > > > > Aravind > > > > > > > > Two issues popped up in our quick review … > > > > > > > > 1) Not enough bandwidth in the offer for Video; 320K. > > > > Venturing a guess, have you configured the CUCM’s default region bandwidth? > > > > > > > > If not, do the following after logging in to the CUCM > > > > System-->Region, click “find”, then the default region will show. Click “default”. > > > > Go to “Modify Relationship to other Regions, and select “Default”. > > > > Under Max Video Call Bit Rate, enter “32000”, and select the “kpbs” radio button. > > > > Click “Save”, then “Reset”. > > > > > > > > 2) The ACK SIP to our SIP 200 OK only indicates G.711, so be sure you offer/ack AAC-LD first or only > > > > > > > > m=audio 53008 RTP/AVP 0^M > > > > b=TIAS:64000^M > > > > a=rtpmap:0 PCMU/8000^M > > > > a=ptime:20^M > > > > > > > > > > > > > > > > > > > > From: Aravind Sethuraman [mailto:ara...@te...] > > > > Sent: Tuesday, April 19, 2011 2:01 PM > > > > To: David Benham (dbenham) > > > > Cc: ste...@te...; tip...@so... > > > > Subject: Re: Teliris & TIP Protocol Start-up Issues > > > > Importance: High > > > > > > > > David, > > > > > > > > Thanks for getting back.. > > > > As per your request attached are the invite.txt and the cts log files > > > > this time, the behaviour was CTS reports Configuration mismatch.... > > > > > > > > much obliged > > > > Aravind > > > > > > > > > > > > > > > > On 04/19/2011 04:12 PM, David Benham (dbenham) wrote: > > > > Aravind, > > > > > > > > Send us a full copy of your initial SIP INVITE containing the SDP. > > > > Also send a copy of the CTS’ logs just in case. > > > > > > > > > > > > From: Aravind Sethuraman [mailto:ara...@te...] > > > > Sent: Tuesday, April 19, 2011 9:31 AM > > > > To: ste...@te... > > > > Cc: David Benham (dbenham) > > > > Subject: Re: Teliris & TIP Protocol License Agreement > > > > > > > > Hello David > > > > Firstly i would like to thank you for offering your help. > > > > What we are building is a TIP user agent plugin which acts as a B2BUA talking TIP on one side and SIP/H264SVC on the other side. Our ultimate goal is to build this to interop with Cisco CTS family of products, 1000-3000. We are currently testing with a CUCM version 8.5 and CTS 1000 version 1.7 and we have chosen to adopt TIP profile version 6. > > > > > > > > The TIPUA does support the following > > > > > > > > SIP signaling > > > > Video > > > > > > > > supports H264 > > > > supports b=TIAS > > > > supports RTP format 112 and packetization mode > > > > supports the profile-id - 4d0028 > > > > > > > > Audio > > > > > > > > AAC-LD (we are faking it currently but @ signal level we are doing it to make CTS happy. We will eventually have this up and running) > > > > G711 > > > > > > > > KeyPress > > > > > > > > RFC2833 ONLY > > > > > > > > TIP Negotiation -> We are having the TIP negotiation module which i will define further below... > > > > > > > > What we are seeing is as follows:- > > > > > > > > Our TIPUA sends invite to CTS (both are registered to CUCM) > > > > CTS sends its SDP in 183 > > > > upon receipt of 183, we start the TIP negotiation -> note, We are assuming the RTCP port available is RTP+1 (in the SDP) > > > > > > > > We are using the libTIP version 1.3 library. > > > > > > > > eventually CTS sends a mid-call re-invite and downgrades to audio only call. > > > > We have not been able to capture ANY RTCP/TIP packets from the CTS leading to eventual failure of TIP and therefore AUDIO only call. > > > > > > > > I am at my wits' end. Are we doing anything glaringly wrong? does CTS 1.7 NOT support TIP ?(highly unlikely) > > > > > > > > I am also available for any phone call if you feel it is necessary to have @ 1917-355-0119 > > > > > > > > much obliged > > > > Aravind Sethuraman > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 04/13/2011 05:42 PM, Steven Gage wrote: > > > > David, > > > > > > > > Aravind is our Chief Software Architect and the technical lead on our Interop efforts. > > > > > > > > Aravind, > > > > > > > > David has been extremely helpful in providing direction on TIP Interoperability. > > > > > > > > Please document our assumptions specifically re sip and tip end point connectivity, minimum bandwidth requirements for video, and audio codec requirements. > > > > > > > > At David's suggestion we will be attending superop but would like to get the basics working in our lab. > > > > > > > > Regards, > > > > Steven Gage > > > > Teliris > > > > 55 Broadway | NY NY 10006 > > > > O+1.212.490.1065 x1400 > > > > F+1.212.202.5432 > > > > M+1.917.952.2212 > > > > > > > > ---------------------------------------------------------------------------- > > > > > > > > This message is a PRIVATE communication. This message and all attachments are a private communication are confidential or > > > > protected by privilege. If you are not the intended recipient, you are > > > > hereby notified that any disclosure, copying, distribution or use of the information contained in or attached to this message is strictly prohibited. Please notify the sender of the delivery error by replying to this message, and then delete it from your system. Thank you. > > > > > > > > > > > > > > > > From: "David Benham (dbenham)" <db...@ci...> <mailto:db...@ci...> > > > > > > > > Date: Wed, 13 Apr 2011 12:58:02 -0700 > > > > > > > > To: Steven Gage<ste...@te...> <mailto:ste...@te...> > > > > > > > > Subject: RE: Teliris & TIP Protocol License Agreement > > > > > > > > > > > > Hi Steven > > > > > > > > The TIP protocol specification does recommend (“SHOULD”), but does not mandate, that endpoints default back to a p2p video and audio call if TIP is not negotiated. The CTS 1000 you have will default back to an audio only (G.7xx) call, in such a case. > > > > > > > > Also, when you do attempt to negotiate TIP with that CTS 1000, you need to indicate AAC-LD in the SDP audio line (per sect 3.1 in the Cisco TIP Endpoint Implementation Profile). Otherwise, the CTS endpoint will assume it is not a TIP session and resort to an audio-only call. > > > > > > > > Let us know if this helps or can answer more questions. > > > > > > > > > > > > > > > > From: Steven Gage [mailto:ste...@te...] > > > > Sent: Wednesday, April 06, 2011 6:56 PM > > > > To: David Benham (dbenham) > > > > Subject: Re: Teliris & TIP Protocol License Agreement > > > > Importance: High > > > > > > > > David, > > > > > > > > > > > > > > > > I posted our issue, here is a synopsis: > > > > > > > > > > > > > > > > We are trying to setup call between a CTS 1000 and SIP Video Endpoint (Mirial ver 7.0.42). > > > > > > > > > > > > > > > > The Mirial client is a pure SIP Video Endpoint capable of supporting H264 AVC and G711. > > > > > > > > > > > > > > > > We have registered it to the CUCM (version 8.5) as a 3rd party Advanced SIP Endpoint with Digest authentication > > > > > > > > > > > > > > > > We have a CTS 1000 registered to same CUCM > > > > > > > > > > > > > > > > While trying to setup call between the CTS 1000 and SIP Video Endpoint (Mirial ver 7.0.42), we are not able to setup a video call. We see in the SIP Packet Transfer, that CUCM re-writes (there are 2 > > > > > > > > SIP Invites sent, but that gets fairly in depth SIP wise) the invite as audio only invite. > > > > > > > > > > > > > > > > Basically we need to figure out what is the configuration (do we have to add a SIP Trunk etc) on the CUCM to make it recognize/support video calls with a pure SIP Video Endpoint. > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > > > > > > > > > Steve > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Apr 2, 2011, at 10:36 AM, David Benham (dbenham) wrote: > > > > > > > > > > > > > > > > > > > > Steven > > > > > > > > Considering it is only 6 weeks away, I strongly suggest attending IMTC’s SuperOp event, where Cisco and Polycom (at least) will have gear set up to test with each other’s TIP products. Non-members are invited to this SuperOp, but do note that if you join IMTC, you can also partake in the TIP Activity Group’s stewardship of TIP as well as other membership benefits. > > > > > > > > > > > > > > > > Here are links and email addresses for further query. > > > > > > > > > > > > > > > > IMTC page for TIP Developers > > > > > > > > http://www.imtc.org/tip/ > > > > > > > > > > > > > > > > IMTC page for TIP Activity Group > > > > > > > > http://www.imtc.org/activity_groups/tip.asp > > > > > > > > > > > > > > > > Places to post questions tip...@im... > > > > > > > > or at the TIP open source project > > > > > > > > http://sourceforge.net/projects/tiprotocol/support > > > > > > > > > > > > > > > > IMTC page for SuperOp event (top item on page) > > > > > > > > http://www.imtc.org/events/ > > > > > > > > > > > > > > > > Cisco page for TIP Developers > > > > > > > > http://www.cisco.com/go/tip > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > Benefiting from Server Virtualization: Beyond Initial Workload > > > > Consolidation -- Increasing the use of server virtualization is a top > > > > priority.Virtualization can reduce costs, simplify management, and improve > > > > application availability and disaster protection. Learn more about boosting > > > > the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev > > > > > > > > _______________________________________________ > > > > TIProtocol-askcisco mailing list > > > > TIP...@li... > > > > https://lists.sourceforge.net/lists/listinfo/tiprotocol-askcisco > > > > > > > > > > > > > > > > |
|
From: Aravind S. <ara...@te...> - 2011-04-21 20:06:55
|
Here are the logs which can be downloaded as follows 1. the cts logs http://db.tt/r53Q4eZ 2. SIP Packet capture http://db.tt/Mv6fdCJ 3. RTP/RTCP packet capture http://db.tt/k1OdFyq the cts is at 10.160.3.105 registering itself to 10.160.3.106 at extension 7000. Our software is 8888 from 10.160.3.203 let me know if you need any furtehr information thanks aravind On 04/21/2011 02:14 PM, nermeen wrote: > Hi Aravind, > > Yes that is a valid assessment. I just wanted to make sure that you > are not concluding that no in-band parameters are being sent because > you see the out-of-band parameters being sent as well. > > Please forward the packet capture and the CTS logs and we will have a > look. > > nermeen > > > On 4/21/11 8:50 AM, "Aravind Sethuraman" > <ara...@te...> wrote: > > Hi nermeen and Steve, > > I have done a packet capture of the actual media and have not been > able to do a decode via videsnarf or other tools. This lets me > think there may be missing in-band parameters. I could be wrong. > Is this a valid assesment? > > thanks > aravind > > > > On 04/21/2011 11:20 AM, nermeen wrote: > > Re: [TIProtocol-askcisco] sprops parameter set for CTS 1000 > version 1.7 I also want to reiterate that CTS supports in-band > signaling of SPS/PPS as well as out of band signaling of > SPS/PPS. In other words CTS always sends SPS/PPS in SDP even > when it is also sending them in-band. > > nermeen > > > > > On 4/20/11 10:45 PM, "Steve Fry" <sf...@ci...> wrote: > > > Hi Aravind, > CTS does look at the SPS/PPS and uses these to detect the > profile idc, image height / width, and coding mode (CABAC > vs. CAVLC). > If you can please collect the CTS logs from one of the > calls and send them to me, we can take a look at it and > try to determine > what the issue is. Also a Wireshark trace of the call > startup would be helpful. > > Thanks > Steve Fry > CTS endpoint team > > > > On 4/20/11 1:32 PM, "Aravind Sethuraman" > <ara...@te...> wrote: > > > Hello all > > We are building a TIP aware end point and we want to > know if there is any way CTS can support in band RTP > payload parameter set instead of out of band via > sprop-parameter-sets. according to the TIP protocol > Section 5.2 item #6 states that TIP endpoints must > indicate support for inband parameter sets. > > Currently we are able to setup a call with the cTS > 1000 and achieved TIP negotiation and have the packet > flowing but neither our end point not CTS 1000 are > able to decode. > > any help will be much appreciated > > regards > > Aravind Sethuraman > Chief Software Architect > Teliris, Inc. | 55 Broadway, 14th Floor, New York, NY > 10006 | C +1.917.355.0119 | O +1.212.490.1065 x1408 | > F +1.212.269.2869 | AIM aravindsraman > > > ------------------------------------------------------------------------ > ------------------------------------------------------------------------------ > Benefiting from Server Virtualization: Beyond Initial > Workload > Consolidation -- Increasing the use of server > virtualization is a top > priority.Virtualization can reduce costs, simplify > management, and improve > application availability and disaster protection. > Learn more about boosting > the value of server virtualization. > http://p.sf.net/sfu/vmware-sfdev2dev > > ------------------------------------------------------------------------ > _______________________________________________ > TIProtocol-askcisco mailing list > TIP...@li... > https://lists.sourceforge.net/lists/listinfo/tiprotocol-askcisco > > > > ------------------------------------------------------------------------ > ------------------------------------------------------------------------------ > Benefiting from Server Virtualization: Beyond Initial > Workload > Consolidation -- Increasing the use of server > virtualization is a top > priority.Virtualization can reduce costs, simplify > management, and improve > application availability and disaster protection. Learn > more about boosting > the value of server virtualization. > http://p.sf.net/sfu/vmware-sfdev2dev > > ------------------------------------------------------------------------ > _______________________________________________ > TIProtocol-askcisco mailing list > TIP...@li... > https://lists.sourceforge.net/lists/listinfo/tiprotocol-askcisco > > > |
|
From: nermeen <ne...@ci...> - 2011-04-21 18:14:18
|
Hi Aravind, Yes that is a valid assessment. I just wanted to make sure that you are not concluding that no in-band parameters are being sent because you see the out-of-band parameters being sent as well. Please forward the packet capture and the CTS logs and we will have a look. nermeen On 4/21/11 8:50 AM, "Aravind Sethuraman" <ara...@te...> wrote: > Hi nermeen and Steve, > > I have done a packet capture of the actual media and have not been able to do > a decode via videsnarf or other tools. This lets me think there may be missing > in-band parameters. I could be wrong. Is this a valid assesment? > > thanks > aravind > > > > On 04/21/2011 11:20 AM, nermeen wrote: >> Re: [TIProtocol-askcisco] sprops parameter set for CTS 1000 version 1.7 I >> also want to reiterate that CTS supports in-band signaling of SPS/PPS as well >> as out of band signaling of SPS/PPS. In other words CTS always sends SPS/PPS >> in SDP even when it is also sending them in-band. >> >> nermeen >> >> >> >> >> On 4/20/11 10:45 PM, "Steve Fry" <sf...@ci...> wrote: >> >> >>> Hi Aravind, >>> CTS does look at the SPS/PPS and uses these to detect the profile idc, image >>> height / width, and coding mode (CABAC vs. CAVLC). >>> If you can please collect the CTS logs from one of the calls and send them >>> to me, we can take a look at it and try to determine >>> what the issue is. Also a Wireshark trace of the call startup would be >>> helpful. >>> >>> Thanks >>> Steve Fry >>> CTS endpoint team >>> >>> >>> >>> On 4/20/11 1:32 PM, "Aravind Sethuraman" <ara...@te...> >>> wrote: >>> >>> >>>> Hello all >>>> >>>> We are building a TIP aware end point and we want to know if there is any >>>> way CTS can support in band RTP payload parameter set instead of out of >>>> band via sprop-parameter-sets. according to the TIP protocol Section 5.2 >>>> item #6 states that TIP endpoints must indicate support for inband >>>> parameter sets. >>>> >>>> Currently we are able to setup a call with the cTS 1000 and achieved TIP >>>> negotiation and have the packet flowing but neither our end point not CTS >>>> 1000 are able to decode. >>>> >>>> any help will be much appreciated >>>> >>>> regards >>>> >>>> Aravind Sethuraman >>>> Chief Software Architect >>>> Teliris, Inc. | 55 Broadway, 14th Floor, New York, NY 10006 | C >>>> +1.917.355.0119 | O +1.212.490.1065 x1408 | F +1.212.269.2869 | AIM >>>> aravindsraman >>>> >>>> >>>> >>>> --------------------------------------------------------------------------- >>>> --- >>>> Benefiting from Server Virtualization: Beyond Initial Workload >>>> Consolidation -- Increasing the use of server virtualization is a top >>>> priority.Virtualization can reduce costs, simplify management, and improve >>>> application availability and disaster protection. Learn more about boosting >>>> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev >>>> >>>> >>>> _______________________________________________ >>>> TIProtocol-askcisco mailing list >>>> TIP...@li... >>>> https://lists.sourceforge.net/lists/listinfo/tiprotocol-askcisco >>>> >>> >>> >>> >>> ---------------------------------------------------------------------------- >>> -- >>> Benefiting from Server Virtualization: Beyond Initial Workload >>> Consolidation -- Increasing the use of server virtualization is a top >>> priority.Virtualization can reduce costs, simplify management, and improve >>> application availability and disaster protection. Learn more about boosting >>> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev >>> >>> >>> _______________________________________________ >>> TIProtocol-askcisco mailing list >>> TIP...@li... >>> https://lists.sourceforge.net/lists/listinfo/tiprotocol-askcisco >>> > > |
|
From: Aravind S. <ara...@te...> - 2011-04-21 15:51:16
|
Hi nermeen and Steve, I have done a packet capture of the actual media and have not been able to do a decode via videsnarf or other tools. This lets me think there may be missing in-band parameters. I could be wrong. Is this a valid assesment? thanks aravind On 04/21/2011 11:20 AM, nermeen wrote: > I also want to reiterate that CTS supports in-band signaling of > SPS/PPS as well as out of band signaling of SPS/PPS. In other words > CTS always sends SPS/PPS in SDP even when it is also sending them > in-band. > > nermeen > > > > > On 4/20/11 10:45 PM, "Steve Fry" <sf...@ci...> wrote: > > Hi Aravind, > CTS does look at the SPS/PPS and uses these to detect the profile > idc, image height / width, and coding mode (CABAC vs. CAVLC). > If you can please collect the CTS logs from one of the calls and > send them to me, we can take a look at it and try to determine > what the issue is. Also a Wireshark trace of the call startup > would be helpful. > > Thanks > Steve Fry > CTS endpoint team > > > > On 4/20/11 1:32 PM, "Aravind Sethuraman" > <ara...@te...> wrote: > > Hello all > > We are building a TIP aware end point and we want to know if > there is any way CTS can support in band RTP payload parameter > set instead of out of band via sprop-parameter-sets. according > to the TIP protocol Section 5.2 item #6 states that TIP > endpoints must indicate support for inband parameter sets. > > Currently we are able to setup a call with the cTS 1000 and > achieved TIP negotiation and have the packet flowing but > neither our end point not CTS 1000 are able to decode. > > any help will be much appreciated > > regards > > Aravind Sethuraman > Chief Software Architect > Teliris, Inc. | 55 Broadway, 14th Floor, New York, NY 10006 | > C +1.917.355.0119 | O +1.212.490.1065 x1408 | F > +1.212.269.2869 | AIM aravindsraman > > ------------------------------------------------------------------------ > ------------------------------------------------------------------------------ > Benefiting from Server Virtualization: Beyond Initial Workload > Consolidation -- Increasing the use of server virtualization > is a top > priority.Virtualization can reduce costs, simplify management, > and improve > application availability and disaster protection. Learn more > about boosting > the value of server virtualization. > http://p.sf.net/sfu/vmware-sfdev2dev > ------------------------------------------------------------------------ > _______________________________________________ > TIProtocol-askcisco mailing list > TIP...@li... > https://lists.sourceforge.net/lists/listinfo/tiprotocol-askcisco > > > ------------------------------------------------------------------------ > ------------------------------------------------------------------------------ > Benefiting from Server Virtualization: Beyond Initial Workload > Consolidation -- Increasing the use of server virtualization is a top > priority.Virtualization can reduce costs, simplify management, and > improve > application availability and disaster protection. Learn more about > boosting > the value of server virtualization. > http://p.sf.net/sfu/vmware-sfdev2dev > ------------------------------------------------------------------------ > _______________________________________________ > TIProtocol-askcisco mailing list > TIP...@li... > https://lists.sourceforge.net/lists/listinfo/tiprotocol-askcisco > |
5 messages has been excluded from this view by a project administrator.
