Paul Kyzivat wrote:
> Very early on there were proprietary INFO-based DTMF methods.
> For fairly good reasons, those techniques were found wanting.
> Rather than do another INFO-based mechanism, KPML was defined. But it
> has not never gotten traction. Meanwhile other mechanisms have been
> deplo
On 1/31/2011 6:06 PM, Mikko Lehto wrote:
> I fail to understand why DTMF delivery methods in signaling path are not as
> stabilized as RFC 2833/4733 is.
> There are many use cases where nice features can be enabled with events
> while dedicated event detector is not feasible in media path.
Hist
On 02/01/2011 09:23 AM, Raphael Tryster wrote:
> The statement that "registered payload numbers *MUST NOT* be used for
> any format other than the one that is registered" seems to be directly
> contradicted by the following text from RFC 3551:
>
> "This profile reserves payload type numbers in the
The statement that "registered payload numbers *MUST NOT* be used for
any format other than the one that is registered" seems to be directly
contradicted by the following text from RFC 3551:
"This profile reserves payload type numbers in the range 96-127
exclusively for dynamic assignment. Applic
On 02/01/2011 08:37 AM, Worley, Dale R (Dale) wrote:
>
> From: sip-implementors-boun...@lists.cs.columbia.edu
> [sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Kevin P.
> Fleming [kpflem...@digium.com]
>
> I assume by 'static' you mean 'IANA
> From: Mikko Lehto [msle...@gmail.com]
>
> Let's say I want to have incoming media delivered straight to my RTP
> capable household appliance (loudspeakers, TV, playstation), while
> signaling is handled entirely by mobile device.
In that case, the mobile device uses SIP to contact the media sou
From: sip-implementors-boun...@lists.cs.columbia.edu
[sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Kevin P. Fleming
[kpflem...@digium.com]
I assume by 'static' you mean 'IANA registered' RTP payload numbers, and
the answer is no; any offer
On 02/01/2011 04:55 AM, Peter Krebs wrote:
> Hello,
>
> I have a question regarding the usage of asymmetric SDP format
> parameters/RTP payload types in offer and answer. From RFC 3264, sec. 5.1 I
> have understood that the actual number used as payload type for sending a
> specific codec is effect
Hello,
I have a question regarding the usage of asymmetric SDP format
parameters/RTP payload types in offer and answer. From RFC 3264, sec. 5.1 I
have understood that the actual number used as payload type for sending a
specific codec is effectively chosen by the receiver, and needs not be the
sam
