Yes. You could also send to <sip-implementors@lists.cs.columbia.edu>.
Its an active enough place with people that are likely to have insight
into what others are doing.
Thanks,
Paul
Vinay Pande (vipande) wrote:
> Emailing the authors of 4733 sounds like a good 1st step, since this can
> become important as 4733 gains acceptance.
> Will you be doing that? if yes, please include Naidu, Girish and myself
> apart from anyone else you feel should be on it,
>
> Thanks,
> Vinay
>
>
>
> ------------------------------------------------------------------------
> *From:* Maulik Shah (maushah)
> *Sent:* Tuesday, February 23, 2010 9:28 AM
> *To:* Vinay Pande (vipande); artg-sip-bliss(mailer list); Toleti Danayya
> Naidu (naidud); Paul Kyzivat (pkyzivat)
> *Subject:* RE: RFC 2833 / RFC 4733 - question on duration "0"
>
> Hi Vinay
>
>
>
> I think the 3^rd party vendor is going to claim RFC4733 compatibility
> and apparently in that RFC there is this section on backwards compatibility:
>
>
>
> The memo has been significantly restructured, incorporating a large
>
> number of clarifications to the specification. *With the exception of*
>
> * those items noted below*, the changes to the memo are intended to be
>
> backwards-compatible clarifications. However, due to inconsistencies
>
> and unclear definitions in RFC 2833 [12] it is likely that some
>
> implementations interpreted that memo in ways that differ from this
>
> version.
>
>
>
> …
>
>
>
> *Section 2.3.5* introduces the possibility of "state" events and
>
> defines procedures for setting the duration field for reports of such
>
> events.
>
>
>
> Reading through the above seems to suggest that duration = 0 is not
> meant to be backwards compatible possibly though its not explicitly
> stated. I think this may become a larger issue for us as more vendors
> adopt RFC4733 and follow the above. Wonder if this requires an email to
> the authors to see what should be done unless there are other thoughts.
>
>
>
> Thanks
>
> Maulik
>
>
>
> SBTG Product Marketing
>
> Cisco Systems
>
> 408 525 7827
>
> Small Business Support Community
> <https://www.myciscocommunity.com/community/smallbizsupport?view=overview>
>
>
>
> *From:* Vinay Pande (vipande)
> *Sent:* Tuesday, February 23, 2010 12:09 AM
> *To:* Maulik Shah (maushah); artg-sip-bliss(mailer list); Toleti Danayya
> Naidu (naidud); Paul Kyzivat (pkyzivat)
> *Subject:* RE: RFC 2833 / RFC 4733 - question on duration "0"
>
>
>
> -Q1- I dont think 2833 spells it out explicitly that 0 is not allowed -
> it is one of those "gray" areas of RFCs I guess...but we never had a
> problem with other vendors so far -- Why doesnt the other vendor's box
> read and plan the packet with duration of 400?
>
> -Q2- Looking at the sec 2.3.5, we seem to be in violation of 4733, since
> 0 seems to be a special duration (forever)
>
> -Q3- If RFC 2833 doesnt in anyway say that 0 is an illegal duration,
> then this is more of a problem that they havent maintained b/ward
> compatibility between 4733 and 2833.
>
> Ideally, the 3rd party GW should be lenient in accepting this -- there
> are many such instances where you are strict when sending, but lenient
> when you receive something...especially when RFCs are not b/ward compatible
>
>
>
> Thanks,
> Vinay
>
>
>
>
>
> ------------------------------------------------------------------------
>
> *From:* Maulik Shah (maushah)
> *Sent:* Monday, February 22, 2010 10:11 PM
> *To:* artg-sip-bliss(mailer list); Toleti Danayya Naidu (naidud); Paul
> Kyzivat (pkyzivat); Vinay Pande (vipande)
> *Subject:* RFC 2833 / RFC 4733 - question on duration "0"
>
> All
>
> Hope this is the right mailer – trying to get my head around something
> odd causing an interop issue with the Cisco SIP stack and a 3^rd party:
>
>
>
> Setup:
>
> phone – Cisco SIP GW – SIP – 3^rd party GW
>
>
>
> When dialing digits using RFC2833 on the phone, here is what the Cisco
> GW sends when user pressed digit 1:
>
>
>
> *CISCO*
>
> DTMF EVENT #
>
>
>
> END
>
>
>
> DURATION
>
>
>
> VOLUME
>
> 1
>
>
>
> FALSE
>
>
>
> * 0 *
>
>
>
> 10
>
> 1
>
>
>
> FALSE
>
>
>
> * 0 *
>
>
>
> 10
>
> 1
>
>
>
> FALSE
>
>
>
> * 0 *
>
>
>
> 10
>
> 1
>
>
>
> FALSE
>
>
>
> 400
>
>
>
> 10
>
> 1
>
>
>
> TRUE
>
>
>
> 800
>
>
>
> 10
>
> 1
>
>
>
> TRUE
>
>
>
> 800
>
>
>
> 10
>
> 1
>
>
>
> TRUE
>
>
>
> 800
>
>
>
> 10
>
>
>
> The 3^rd party GW ignores the first 3 packets as the duration is 0 –
> subsequently it does not play out the digit as there is no “start event”
> for the digit.
>
>
>
> 1. Reading RFC2833 – here is what it says about duration:
>
>
>
> duration: Duration of this digit, in timestamp units. Thus, the
>
> event began at the instant identified by the RTP timestamp
>
> and has so far lasted as long as indicated by this parameter.
>
> The event may or may not have ended.
>
>
>
> Question 1. Should this be interpreted to mean the source MUST send a
> non zero value for duration OR zero is acceptable? The Linksys SPA
> phones for example send duration of 160 (sample size of the audio code)
> in the first 3 packets.
>
>
>
> 2. I read a snip on RFC4733 which claims duration = 0 is illegal
> to send by the source:
>
>
>
> 2.3.5. Duration Field
>
>
>
> The duration field indicates the duration of the event or segment
>
> being reported, in timestamp units, expressed as an unsigned integer
>
> in network byte order. For a non-zero value, the event or segment
>
> began at the instant identified by the RTP timestamp and has so far
>
> lasted as long as indicated by this parameter. The event may or may
>
> not have ended. If the event duration exceeds the maximum
>
> representable by the duration field, the event is split into several
>
> contiguous segments as described below (Section 2.5.1.3).
>
>
>
> *The special duration value of zero is reserved to indicate that the*
>
> * event lasts "forever", i.e., is a state and is considered to be*
>
> * effective until updated. A sender MUST NOT transmit a zero duration*
>
> * for events other than those defined as states. The receiver SHOULD*
>
> * ignore an event report with zero duration if the event is not a*
>
> * state.*
>
>
>
> Question 2. Cisco GW is clearly in violation of RFC4733 in this aspect
> (unless a DTMF digit qualifies as a state??). I do not think we claim
> RFC4733 compliance yet but is my understanding correct?
>
>
>
> Question 3. RFC4733 obsoletes RFC2833 but in general there is the
> concept of backwards compatibility – unclear on if the above qualifies
> or not but is there a case for us to ask the vendor of the 3^rd party GW
> to be backwards compatible with RFC2833?
>
>
>
> Not sure if I was clear enough – appreciate any feedback.
>
>
>
> Thanks
>
> Maulik
>
>
>
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
