[sip-comm-dev] Dynamic payload for DTMF (or more)


#1

Hi everybody,

For my DTMF implementation I need to negociate a dynamic payload with the
remote side.

I need this behaviour for DTMF, but this same things could happen in other
Sip Communicator projects :
https://sip-communicator.dev.java.net/servlets/ReadMsg?listName=dev&msgNo=2553

What is a dynamic payload type?
In an SDP offer (or answer) there is a media description :
(m): audio 5000 RTP/AVP 0 8 97 ..... 101
The last numbers ( 0 8 97 ..... 101 ) correspond to the payload type of
accepted codec.
If the number is included in the range 97-127, the payload type is dynamic,
we don't know the codec name matching this payload type.
So we add the link in SDP like this :
(a): rtpmap 101 telephone-event/8000 (this is for DTMF)
Now the remote side know that the dynamic payload type 101 is for
telephone-event/8000

Join in this mail you will find my very dirty hack.
I negociate the DTMF payload type in CallSessionImpl and MediaControl.

In CallSessionImpl#createMediaDescriptions() :
If we receive an SDP offer we save the Payload Type
Number. This number will be used in DTMF packets.

In MediaControl#getSupportedAudioEncodings()
We add support for the DTMF Payload Type Number.

In DtmfConstants.DtmfSDP
The DtmfSDP is not a constant anymore because the remote side can change it.

When I tried to add DTMF encoding directly in EncodingConfiguration, it
didn't add DTMF in SDP, but added it in the Codec GUI.

If you have any ideas how to generalize this

Cheers

Romain

CallSessionImpl.patch (2.84 KB)

DtmfConstants.patch (688 Bytes)

MediaControl.patch (1.36 KB)


#2

Hey Romain,

Afraid there's no clean way of handling this for now until we have our
new media implementation, which would be moving SDP outside of the media
package. This is being currently handled as part of issue #701

https://sip-communicator.dev.java.net/issues/show_bug.cgi?id=701

Until that's ready we better limit the changes to as few locations as
possible. I don't think you need to be bothering with MediaControl at
all. Just manually add the mapping to audio media descriptions in
CallSessionImpl.

Does this make sense?

Emil

Romain wrote:

···

Hi everybody,

For my DTMF implementation I need to negociate a dynamic payload with
the remote side.

I need this behaviour for DTMF, but this same things could happen in
other Sip Communicator projects :
https://sip-communicator.dev.java.net/servlets/ReadMsg?listName=dev&msgNo=2553
<https://sip-communicator.dev.java.net/servlets/ReadMsg?listName=dev&msgNo=2553>

What is a dynamic payload type?
In an SDP offer (or answer) there is a media description :
(m): audio 5000 RTP/AVP 0 8 97 ..... 101
The last numbers ( 0 8 97 ..... 101 ) correspond to the payload type of
accepted codec.
If the number is included in the range 97-127, the payload type is
dynamic, we don't know the codec name matching this payload type.
So we add the link in SDP like this :
(a): rtpmap 101 telephone-event/8000 (this is for DTMF)
Now the remote side know that the dynamic payload type 101 is for
telephone-event/8000

Join in this mail you will find my very dirty hack.
I negociate the DTMF payload type in CallSessionImpl and MediaControl.

In CallSessionImpl#createMediaDescriptions() :
If we receive an SDP offer we save the Payload Type
Number. This number will be used in DTMF packets.

In MediaControl#getSupportedAudioEncodings()
We add support for the DTMF Payload Type Number.

In DtmfConstants.DtmfSDP
The DtmfSDP is not a constant anymore because the remote side can change it.

When I tried to add DTMF encoding directly in EncodingConfiguration, it
didn't add DTMF in SDP, but added it in the Codec GUI.

If you have any ideas how to generalize this

Cheers

Romain

------------------------------------------------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
SIP Communicator
emcho@sip-communicator.org PHONE: +33.1.77.62.43.30
http://sip-communicator.org FAX: +33.1.77.62.47.31

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#3

Hey Emil

Yes I understand and for me it is easier to do it in CallSessionImpl only.

So the generic way to handle dynamic payload is reported to the new Media
implementation.

Cheers

Romain

···

2009/7/30 Emil Ivov <emcho@sip-communicator.org>

Hey Romain,

Afraid there's no clean way of handling this for now until we have our
new media implementation, which would be moving SDP outside of the media
package. This is being currently handled as part of issue #701

https://sip-communicator.dev.java.net/issues/show_bug.cgi?id=701

Until that's ready we better limit the changes to as few locations as
possible. I don't think you need to be bothering with MediaControl at
all. Just manually add the mapping to audio media descriptions in
CallSessionImpl.

Does this make sense?

Emil

Romain wrote:
> Hi everybody,
>
> For my DTMF implementation I need to negociate a dynamic payload with
> the remote side.
>
> I need this behaviour for DTMF, but this same things could happen in
> other Sip Communicator projects :
>
https://sip-communicator.dev.java.net/servlets/ReadMsg?listName=dev&msgNo=2553
> <
https://sip-communicator.dev.java.net/servlets/ReadMsg?listName=dev&msgNo=2553
>
>
> What is a dynamic payload type?
> In an SDP offer (or answer) there is a media description :
> (m): audio 5000 RTP/AVP 0 8 97 ..... 101
> The last numbers ( 0 8 97 ..... 101 ) correspond to the payload type of
> accepted codec.
> If the number is included in the range 97-127, the payload type is
> dynamic, we don't know the codec name matching this payload type.
> So we add the link in SDP like this :
> (a): rtpmap 101 telephone-event/8000 (this is for DTMF)
> Now the remote side know that the dynamic payload type 101 is for
> telephone-event/8000
>
> Join in this mail you will find my very dirty hack.
> I negociate the DTMF payload type in CallSessionImpl and MediaControl.
>
> In CallSessionImpl#createMediaDescriptions() :
> If we receive an SDP offer we save the Payload Type
> Number. This number will be used in DTMF packets.
>
> In MediaControl#getSupportedAudioEncodings()
> We add support for the DTMF Payload Type Number.
>
> In DtmfConstants.DtmfSDP
> The DtmfSDP is not a constant anymore because the remote side can change
it.
>
>
> When I tried to add DTMF encoding directly in EncodingConfiguration, it
> didn't add DTMF in SDP, but added it in the Codec GUI.
>
> If you have any ideas how to generalize this
>
> Cheers
>
> Romain
>
>
> ------------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
> For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
SIP Communicator
emcho@sip-communicator.org PHONE: +33.1.77.62.43.30
http://sip-communicator.org FAX: +33.1.77.62.47.31

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#4

I made a new patch for dynamic payload support in DTMF only.
This patch need to be applied on the current DTMF implementation.
https://sip-communicator.dev.java.net/servlets/ReadMsg?listName=dev&msgNo=6771
.

This time, there is no modification of the MediaControl class. The SDP
detection only happen in CallSessionImpl.

I exported the payload type attribute in the DtmfTransformEngine because it
isn't a constant anymore.

If both side accept DTMF, the DtmfTransformEngine.bothSideAcceptDtmf
attribute is set to true.

Warnings are written when SC is configured with DTMF on RTP but the remote
side do not accept DTMF.

I also changed some lines to follow the code convention.

Cheers

Romain

CalSessionImpl.patch (5.16 KB)

DtmfConstants.patch (1.48 KB)

DtmfRawPacket.patch (3.59 KB)

DtmfRTPPacketTransformer.patch (5.47 KB)

DtmfTransformEngine.patch (4.33 KB)

···

2009/7/30 Romain <filirom1@gmail.com>

Hey Emil

Yes I understand and for me it is easier to do it in CallSessionImpl only.

So the generic way to handle dynamic payload is reported to the new Media
implementation.

Cheers

Romain

2009/7/30 Emil Ivov <emcho@sip-communicator.org>

Hey Romain,

Afraid there's no clean way of handling this for now until we have our
new media implementation, which would be moving SDP outside of the media
package. This is being currently handled as part of issue #701

https://sip-communicator.dev.java.net/issues/show_bug.cgi?id=701

Until that's ready we better limit the changes to as few locations as
possible. I don't think you need to be bothering with MediaControl at
all. Just manually add the mapping to audio media descriptions in
CallSessionImpl.

Does this make sense?

Emil

Romain wrote:
> Hi everybody,
>
> For my DTMF implementation I need to negociate a dynamic payload with
> the remote side.
>
> I need this behaviour for DTMF, but this same things could happen in
> other Sip Communicator projects :
>
https://sip-communicator.dev.java.net/servlets/ReadMsg?listName=dev&msgNo=2553
> <
https://sip-communicator.dev.java.net/servlets/ReadMsg?listName=dev&msgNo=2553
>
>
> What is a dynamic payload type?
> In an SDP offer (or answer) there is a media description :
> (m): audio 5000 RTP/AVP 0 8 97 ..... 101
> The last numbers ( 0 8 97 ..... 101 ) correspond to the payload type of
> accepted codec.
> If the number is included in the range 97-127, the payload type is
> dynamic, we don't know the codec name matching this payload type.
> So we add the link in SDP like this :
> (a): rtpmap 101 telephone-event/8000 (this is for DTMF)
> Now the remote side know that the dynamic payload type 101 is for
> telephone-event/8000
>
> Join in this mail you will find my very dirty hack.
> I negociate the DTMF payload type in CallSessionImpl and MediaControl.
>
> In CallSessionImpl#createMediaDescriptions() :
> If we receive an SDP offer we save the Payload Type
> Number. This number will be used in DTMF packets.
>
> In MediaControl#getSupportedAudioEncodings()
> We add support for the DTMF Payload Type Number.
>
> In DtmfConstants.DtmfSDP
> The DtmfSDP is not a constant anymore because the remote side can change
it.
>
>
> When I tried to add DTMF encoding directly in EncodingConfiguration, it
> didn't add DTMF in SDP, but added it in the Codec GUI.
>
> If you have any ideas how to generalize this
>
> Cheers
>
> Romain
>
>
> ------------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
> For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
SIP Communicator
emcho@sip-communicator.org PHONE: +33.1.77.62.43.30
http://sip-communicator.org FAX: +33.1.77.62.47.31

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#5

Hey Romain,

Romain wrote:

I made a new patch for dynamic payload support in DTMF only.
This patch need to be applied on the current DTMF implementation.
https://sip-communicator.dev.java.net/servlets/ReadMsg?listName=dev&msgNo=6771
<https://sip-communicator.dev.java.net/servlets/ReadMsg?listName=dev&msgNo=6771>.

Great work! The media service implementation is one of the most
intricate parts of SIP Communicator and handling the DTMF injection
(including the investigation of alternative implementation methods) is
quite an adventure. Congratulations!

Emil

···

This time, there is no modification of the MediaControl class. The SDP
detection only happen in CallSessionImpl.

I exported the payload type attribute in the DtmfTransformEngine because
it isn't a constant anymore.

If both side accept DTMF, the DtmfTransformEngine.bothSideAcceptDtmf
attribute is set to true.

Warnings are written when SC is configured with DTMF on RTP but the
remote side do not accept DTMF.

I also changed some lines to follow the code convention.

Cheers

Romain

2009/7/30 Romain <filirom1@gmail.com <mailto:filirom1@gmail.com>>

    Hey Emil

    Yes I understand and for me it is easier to do it in CallSessionImpl
    only.

    So the generic way to handle dynamic payload is reported to the new
    Media implementation.

    Cheers

    Romain

    2009/7/30 Emil Ivov <emcho@sip-communicator.org
    <mailto:emcho@sip-communicator.org>>

        Hey Romain,

        Afraid there's no clean way of handling this for now until we
        have our
        new media implementation, which would be moving SDP outside of
        the media
        package. This is being currently handled as part of issue #701

        https://sip-communicator.dev.java.net/issues/show_bug.cgi?id=701

        Until that's ready we better limit the changes to as few
        locations as
        possible. I don't think you need to be bothering with
        MediaControl at
        all. Just manually add the mapping to audio media descriptions in
        CallSessionImpl.

        Does this make sense?

        Emil

        Romain wrote:
        > Hi everybody,
        >
        > For my DTMF implementation I need to negociate a dynamic
        payload with
        > the remote side.
        >
        > I need this behaviour for DTMF, but this same things could
        happen in
        > other Sip Communicator projects :
        >
        https://sip-communicator.dev.java.net/servlets/ReadMsg?listName=dev&msgNo=2553
        <https://sip-communicator.dev.java.net/servlets/ReadMsg?listName=dev&msgNo=2553>
        >
        <https://sip-communicator.dev.java.net/servlets/ReadMsg?listName=dev&msgNo=2553
        <https://sip-communicator.dev.java.net/servlets/ReadMsg?listName=dev&msgNo=2553>>
        >
        > What is a dynamic payload type?
        > In an SDP offer (or answer) there is a media description :
        > (m): audio 5000 RTP/AVP 0 8 97 ..... 101
        > The last numbers ( 0 8 97 ..... 101 ) correspond to the
        payload type of
        > accepted codec.
        > If the number is included in the range 97-127, the payload type is
        > dynamic, we don't know the codec name matching this payload type.
        > So we add the link in SDP like this :
        > (a): rtpmap 101 telephone-event/8000 (this is for DTMF)
        > Now the remote side know that the dynamic payload type 101 is for
        > telephone-event/8000
        >
        > Join in this mail you will find my very dirty hack.
        > I negociate the DTMF payload type in CallSessionImpl and
        MediaControl.
        >
        > In CallSessionImpl#createMediaDescriptions() :
        > If we receive an SDP offer we save the Payload Type
        > Number. This number will be used in DTMF packets.
        >
        > In MediaControl#getSupportedAudioEncodings()
        > We add support for the DTMF Payload Type Number.
        >
        > In DtmfConstants.DtmfSDP
        > The DtmfSDP is not a constant anymore because the remote side
        can change it.
        >
        >
        > When I tried to add DTMF encoding directly in
        EncodingConfiguration, it
        > didn't add DTMF in SDP, but added it in the Codec GUI.
        >
        > If you have any ideas how to generalize this
        >
        > Cheers
        >
        > Romain
        >
        >
        >
        ------------------------------------------------------------------------
        >
        >
        ---------------------------------------------------------------------
        > To unsubscribe, e-mail:
        dev-unsubscribe@sip-communicator.dev.java.net
        <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
        > For additional commands, e-mail:
        dev-help@sip-communicator.dev.java.net
        <mailto:dev-help@sip-communicator.dev.java.net>

        --
        Emil Ivov, Ph.D. 67000 Strasbourg,
        Project Lead France
        SIP Communicator
        emcho@sip-communicator.org <mailto:emcho@sip-communicator.org>
                          PHONE: +33.1.77.62.43.30
        http://sip-communicator.org FAX:
        +33.1.77.62.47.31

        ---------------------------------------------------------------------
        To unsubscribe, e-mail:
        dev-unsubscribe@sip-communicator.dev.java.net
        <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
        For additional commands, e-mail:
        dev-help@sip-communicator.dev.java.net
        <mailto:dev-help@sip-communicator.dev.java.net>

------------------------------------------------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
SIP Communicator
emcho@sip-communicator.org PHONE: +33.1.77.62.43.30
http://sip-communicator.org FAX: +33.1.77.62.47.31

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net