[sip-comm-dev] Fwd: Re: [sip-comm] DTMP tones supported?


#1

Hello,

I started testing sip-communicator with our Cisco products last week.

I was testing sip-communicator with our MeetingPlace solution but for some reason DTMF tones sent weren't been picked up by the server.
I checked our documentation and the following tone formats should be detected:
- In band audio tones (as defined in ITU-T Q.23, Q.24 (AT&T) standard)
- RFC 2833
- H.245 signal messages

Our VoiceMail server is picking up the tones sent but the MeetingPlace isn't for some reason. Does this ring any bells?

Any help or pointers appreciated.

Regards,

···

--

Daniel Castro

Software QA Engineer
Unified Communications Business Unit
danicast@cisco.com
Phone: +353 91 38 4778
Mobile: +353 83 318 2058

Cisco Systems Internetworking (Ireland) Limited
Oranmore Business Park
Oranmore, Galway
Ireland
Cisco.com - http://www.cisco.com/global/UK/

Cisco Systems Internetworking (Ireland) Limited a private limited company registered in Ireland under company number 314989 with its registered office at Block 6, Eastpoint Business Park, Dublin 3, Ireland

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

-------- Original Message --------
Subject: Re: [sip-comm] DTMP tones supported?
Date: Thu, 29 Jul 2010 21:29:50 +0300

From: Damian Minkov <damencho@sip-communicator.org>

Reply-To: users@sip-communicator.dev.java.net
To: users@sip-communicator.dev.java.net

Hi Daniel,

On Thu, Jul 29, 2010 at 8:18 PM, Daniel Castro<danicast@cisco.com> wrote:

   Hi,

I'm now to sip-communicator and new to this list. Excellent application btw!

Thanks for the kind words.

I was just testing it and tried to join a meeting that requires me to send
DTMF codes, but apparently sip-communicator it's not sending them.
Does anyone know if this is supported or if this is a known issue?

Currently we support two type of DTMFs:- rfc4733(which is compatible
with rfc2833) and sending using SIP (SIP INFO messages). The first one
should be default, maybe if it doesn't work for you, you can try
disabling it by unchecking the option in Configuration form under
Audio, search for "telephone-event/8000". When you uncheck it you will
use the one with sip info messages.

Cheers
damencho

Thanks,

--

Daniel Castro

Software QA Engineer
Unified Communications Business Unit
danicast@cisco.com
Phone: +353 91 38 4778
Mobile: +353 83 318 2058

Cisco Systems Internetworking (Ireland) Limited
Oranmore Business Park
Oranmore, Galway
Ireland
Cisco.com - http://www.cisco.com/global/UK/

Cisco Systems Internetworking (Ireland) Limited a private limited company
registered in Ireland under company number 314989 with its registered office
at Block 6, Eastpoint Business Park, Dublin 3, Ireland

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

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

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


#2

Hey Daniel

На 03.08.10 12:17, Daniel Castro написа:

I checked our documentation and the following tone formats should be
detected:
- In band audio tones (as defined in ITU-T Q.23, Q.24 (AT&T) standard)
- RFC 2833

That's the kind you'd be getting from SIP Communicator.

Our VoiceMail server is picking up the tones sent but the MeetingPlace
isn't for some reason. Does this ring any bells?

Sounds strange. Would it be too much trouble to ask you for a Wireshark
dump that contains DTMF tones sent from an application that works with
your MeetingPlace, as well as another one that shows those coming out of
SC when you are testing it?

Cheers,
Emil

···

Any help or pointers appreciated.

Regards,
--

Daniel Castro

Software QA Engineer
Unified Communications Business Unit
danicast@cisco.com
Phone: +353 91 38 4778
Mobile: +353 83 318 2058

Cisco Systems Internetworking (Ireland) Limited
Oranmore Business Park
Oranmore, Galway
Ireland
Cisco.com - http://www.cisco.com/global/UK/

Cisco Systems Internetworking (Ireland) Limited a private limited company registered in Ireland under company number 314989 with its registered office at Block 6, Eastpoint Business Park, Dublin 3, Ireland

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

-------- Original Message --------
Subject: Re: [sip-comm] DTMP tones supported?
Date: Thu, 29 Jul 2010 21:29:50 +0300
From: Damian Minkov <damencho@sip-communicator.org>
Reply-To: users@sip-communicator.dev.java.net
To: users@sip-communicator.dev.java.net

Hi Daniel,

On Thu, Jul 29, 2010 at 8:18 PM, Daniel Castro <danicast@cisco.com> wrote:

Hi,

I'm now to sip-communicator and new to this list. Excellent application btw!

Thanks for the kind words.

I was just testing it and tried to join a meeting that requires me to send
DTMF codes, but apparently sip-communicator it's not sending them.
Does anyone know if this is supported or if this is a known issue?

Currently we support two type of DTMFs:- rfc4733(which is compatible
with rfc2833) and sending using SIP (SIP INFO messages). The first one
should be default, maybe if it doesn't work for you, you can try
disabling it by unchecking the option in Configuration form under
Audio, search for "telephone-event/8000". When you uncheck it you will
use the one with sip info messages.

Cheers
damencho

Thanks,

--

Daniel Castro

Software QA Engineer
Unified Communications Business Unit
danicast@cisco.com
Phone: +353 91 38 4778
Mobile: +353 83 318 2058

Cisco Systems Internetworking (Ireland) Limited
Oranmore Business Park
Oranmore, Galway
Ireland
Cisco.com - http://www.cisco.com/global/UK/

Cisco Systems Internetworking (Ireland) Limited a private limited company
registered in Ireland under company number 314989 with its registered office
at Block 6, Eastpoint Business Park, Dublin 3, Ireland

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

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

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-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

Hi Emil,

No trouble at all. I'll try to get this done before the end of the week. What's the process? Do you have a bug tracking system? Should I open a bug and attach those logs to it? Please advise.

Thanks,
Daniel.

···

On 03/08/10 13:06, Emil Ivov wrote:

Hey Daniel

На 03.08.10 12:17, Daniel Castro написа:

I checked our documentation and the following tone formats should be
detected:
- In band audio tones (as defined in ITU-T Q.23, Q.24 (AT&T) standard)
- RFC 2833

That's the kind you'd be getting from SIP Communicator.

Our VoiceMail server is picking up the tones sent but the MeetingPlace
isn't for some reason. Does this ring any bells?

Sounds strange. Would it be too much trouble to ask you for a Wireshark
dump that contains DTMF tones sent from an application that works with
your MeetingPlace, as well as another one that shows those coming out of
SC when you are testing it?

Cheers,
Emil

Any help or pointers appreciated.

Regards,
--

Daniel Castro

Software QA Engineer
Unified Communications Business Unit
danicast@cisco.com
Phone: +353 91 38 4778
Mobile: +353 83 318 2058

Cisco Systems Internetworking (Ireland) Limited
Oranmore Business Park
Oranmore, Galway
Ireland
Cisco.com - http://www.cisco.com/global/UK/

Cisco Systems Internetworking (Ireland) Limited a private limited company registered in Ireland under company number 314989 with its registered office at Block 6, Eastpoint Business Park, Dublin 3, Ireland

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

-------- Original Message --------
Subject: Re: [sip-comm] DTMP tones supported?
Date: Thu, 29 Jul 2010 21:29:50 +0300
From: Damian Minkov<damencho@sip-communicator.org>
Reply-To: users@sip-communicator.dev.java.net
To: users@sip-communicator.dev.java.net

Hi Daniel,

On Thu, Jul 29, 2010 at 8:18 PM, Daniel Castro<danicast@cisco.com> wrote:

  Hi,

I'm now to sip-communicator and new to this list. Excellent application btw!

Thanks for the kind words.

I was just testing it and tried to join a meeting that requires me to send
DTMF codes, but apparently sip-communicator it's not sending them.
Does anyone know if this is supported or if this is a known issue?

Currently we support two type of DTMFs:- rfc4733(which is compatible
with rfc2833) and sending using SIP (SIP INFO messages). The first one
should be default, maybe if it doesn't work for you, you can try
disabling it by unchecking the option in Configuration form under
Audio, search for "telephone-event/8000". When you uncheck it you will
use the one with sip info messages.

Cheers
damencho

Thanks,

--

Daniel Castro

Software QA Engineer
Unified Communications Business Unit
danicast@cisco.com
Phone: +353 91 38 4778
Mobile: +353 83 318 2058

Cisco Systems Internetworking (Ireland) Limited
Oranmore Business Park
Oranmore, Galway
Ireland
Cisco.com - http://www.cisco.com/global/UK/

Cisco Systems Internetworking (Ireland) Limited a private limited company
registered in Ireland under company number 314989 with its registered office
at Block 6, Eastpoint Business Park, Dublin 3, Ireland

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

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

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


#4

На 03.08.10 17:24, Daniel Castro написа:

  Hi Emil,

No trouble at all. I'll try to get this done before the end of the week.

Great!

What's the process? Do you have a bug tracking system? Should I open a
bug and attach those logs to it? Please advise.

We generally open bugs once they are confirmed as such and I am thinking
that in this case the issue might be with MeetingPlace. Therefore, could
you please send the traces here?

Cheers,
Emil

···

Thanks,
Daniel.

On 03/08/10 13:06, Emil Ivov wrote:

Hey Daniel

На 03.08.10 12:17, Daniel Castro написа:

I checked our documentation and the following tone formats should be
detected:
- In band audio tones (as defined in ITU-T Q.23, Q.24 (AT&T) standard)
- RFC 2833

That's the kind you'd be getting from SIP Communicator.

Our VoiceMail server is picking up the tones sent but the MeetingPlace
isn't for some reason. Does this ring any bells?

Sounds strange. Would it be too much trouble to ask you for a Wireshark
dump that contains DTMF tones sent from an application that works with
your MeetingPlace, as well as another one that shows those coming out of
SC when you are testing it?

Cheers,
Emil

Any help or pointers appreciated.

Regards,
--

Daniel Castro

Software QA Engineer
Unified Communications Business Unit
danicast@cisco.com
Phone: +353 91 38 4778
Mobile: +353 83 318 2058

Cisco Systems Internetworking (Ireland) Limited
Oranmore Business Park
Oranmore, Galway
Ireland
Cisco.com - http://www.cisco.com/global/UK/

Cisco Systems Internetworking (Ireland) Limited a private limited company registered in Ireland under company number 314989 with its registered office at Block 6, Eastpoint Business Park, Dublin 3, Ireland

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

-------- Original Message --------
Subject: Re: [sip-comm] DTMP tones supported?
Date: Thu, 29 Jul 2010 21:29:50 +0300
From: Damian Minkov<damencho@sip-communicator.org>
Reply-To: users@sip-communicator.dev.java.net
To: users@sip-communicator.dev.java.net

Hi Daniel,

On Thu, Jul 29, 2010 at 8:18 PM, Daniel Castro<danicast@cisco.com> wrote:

  Hi,

I'm now to sip-communicator and new to this list. Excellent application btw!

Thanks for the kind words.

I was just testing it and tried to join a meeting that requires me to send
DTMF codes, but apparently sip-communicator it's not sending them.
Does anyone know if this is supported or if this is a known issue?

Currently we support two type of DTMFs:- rfc4733(which is compatible
with rfc2833) and sending using SIP (SIP INFO messages). The first one
should be default, maybe if it doesn't work for you, you can try
disabling it by unchecking the option in Configuration form under
Audio, search for "telephone-event/8000". When you uncheck it you will
use the one with sip info messages.

Cheers
damencho

Thanks,

--

Daniel Castro

Software QA Engineer
Unified Communications Business Unit
danicast@cisco.com
Phone: +353 91 38 4778
Mobile: +353 83 318 2058

Cisco Systems Internetworking (Ireland) Limited
Oranmore Business Park
Oranmore, Galway
Ireland
Cisco.com - http://www.cisco.com/global/UK/

Cisco Systems Internetworking (Ireland) Limited a private limited company
registered in Ireland under company number 314989 with its registered office
at Block 6, Eastpoint Business Park, Dublin 3, Ireland

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

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

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-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

Hi Emil,

Here are the two wireshark dumps. Please let me know if there's anything else I can do.

Regards,
Daniel.

bad-DTMF.pcap (475 KB)

good-DTMF.pcap (727 KB)

···

On 03/08/10 19:28, Emil Ivov wrote:

На 03.08.10 17:24, Daniel Castro написа:

   Hi Emil,

No trouble at all. I'll try to get this done before the end of the week.

Great!

What's the process? Do you have a bug tracking system? Should I open a
bug and attach those logs to it? Please advise.

We generally open bugs once they are confirmed as such and I am thinking
that in this case the issue might be with MeetingPlace. Therefore, could
you please send the traces here?

Cheers,
Emil

Thanks,
Daniel.

On 03/08/10 13:06, Emil Ivov wrote:

Hey Daniel

На 03.08.10 12:17, Daniel Castro написа:

I checked our documentation and the following tone formats should be
detected:
- In band audio tones (as defined in ITU-T Q.23, Q.24 (AT&T) standard)
- RFC 2833

That's the kind you'd be getting from SIP Communicator.

Our VoiceMail server is picking up the tones sent but the MeetingPlace
isn't for some reason. Does this ring any bells?

Sounds strange. Would it be too much trouble to ask you for a Wireshark
dump that contains DTMF tones sent from an application that works with
your MeetingPlace, as well as another one that shows those coming out of
SC when you are testing it?

Cheers,
Emil

Any help or pointers appreciated.

Regards,
--

Daniel Castro

Software QA Engineer
Unified Communications Business Unit
danicast@cisco.com
Phone: +353 91 38 4778
Mobile: +353 83 318 2058

Cisco Systems Internetworking (Ireland) Limited
Oranmore Business Park
Oranmore, Galway
Ireland
Cisco.com - http://www.cisco.com/global/UK/

Cisco Systems Internetworking (Ireland) Limited a private limited company registered in Ireland under company number 314989 with its registered office at Block 6, Eastpoint Business Park, Dublin 3, Ireland

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

-------- Original Message --------
Subject: Re: [sip-comm] DTMP tones supported?
Date: Thu, 29 Jul 2010 21:29:50 +0300
From: Damian Minkov<damencho@sip-communicator.org>
Reply-To: users@sip-communicator.dev.java.net
To: users@sip-communicator.dev.java.net

Hi Daniel,

On Thu, Jul 29, 2010 at 8:18 PM, Daniel Castro<danicast@cisco.com> wrote:

   Hi,

I'm now to sip-communicator and new to this list. Excellent application btw!

Thanks for the kind words.

I was just testing it and tried to join a meeting that requires me to send
DTMF codes, but apparently sip-communicator it's not sending them.
Does anyone know if this is supported or if this is a known issue?

Currently we support two type of DTMFs:- rfc4733(which is compatible
with rfc2833) and sending using SIP (SIP INFO messages). The first one
should be default, maybe if it doesn't work for you, you can try
disabling it by unchecking the option in Configuration form under
Audio, search for "telephone-event/8000". When you uncheck it you will
use the one with sip info messages.

Cheers
damencho

Thanks,

--

Daniel Castro

Software QA Engineer
Unified Communications Business Unit
danicast@cisco.com
Phone: +353 91 38 4778
Mobile: +353 83 318 2058

Cisco Systems Internetworking (Ireland) Limited
Oranmore Business Park
Oranmore, Galway
Ireland
Cisco.com - http://www.cisco.com/global/UK/

Cisco Systems Internetworking (Ireland) Limited a private limited company
registered in Ireland under company number 314989 with its registered office
at Block 6, Eastpoint Business Park, Dublin 3, Ireland

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

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

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


#6

Hi,

I was looking at the dumps. The good dump is using g722 and as I not
see any dtmf (vie sip info or vie rtp dtmf rfc2833) I suppose there
are send like tones in the audio(inband).
About the bad dump, I see there the dtmfs and wireshark successfully
recognize them as rfc2833. But what I notice: we are invited and we
respond with RINGING, TRYING, OK and in the OK we offer the dtmf as
"Media Attribute (a): rtpmap:100 telephone-event/8000". Later in the
ACK of our OK we receive "Media Attribute (a):
rtpmap:101 telephone-event/8000" and at the end we send the dtmf
events with payload 100 (as in our offer). So here I'm not sure which
is the correct behaviour, do we have to send the dtmfs with payload
101, or the other party must accept our offer and receive them as 100
not as 101.

Regards
damencho

···

On Wed, Aug 4, 2010 at 6:43 PM, Daniel Castro <danicast@cisco.com> wrote:

Hi Emil,

Here are the two wireshark dumps. Please let me know if there's anything
else I can do.

Regards,
Daniel.

On 03/08/10 19:28, Emil Ivov wrote:

На 03.08.10 17:24, Daniel Castro написа:

Hi Emil,

No trouble at all. I'll try to get this done before the end of the week.

Great!

What's the process? Do you have a bug tracking system? Should I open a
bug and attach those logs to it? Please advise.

We generally open bugs once they are confirmed as such and I am thinking
that in this case the issue might be with MeetingPlace. Therefore, could
you please send the traces here?

Cheers,
Emil

Thanks,
Daniel.

On 03/08/10 13:06, Emil Ivov wrote:

Hey Daniel

На 03.08.10 12:17, Daniel Castro написа:

I checked our documentation and the following tone formats should be
detected:
- In band audio tones (as defined in ITU-T Q.23, Q.24 (AT&T) standard)
- RFC 2833

That's the kind you'd be getting from SIP Communicator.

Our VoiceMail server is picking up the tones sent but the MeetingPlace
isn't for some reason. Does this ring any bells?

Sounds strange. Would it be too much trouble to ask you for a Wireshark
dump that contains DTMF tones sent from an application that works with
your MeetingPlace, as well as another one that shows those coming out of
SC when you are testing it?

Cheers,
Emil

Any help or pointers appreciated.

Regards,
--

Daniel Castro

Software QA Engineer
Unified Communications Business Unit
danicast@cisco.com
Phone: +353 91 38 4778
Mobile: +353 83 318 2058

Cisco Systems Internetworking (Ireland) Limited
Oranmore Business Park
Oranmore, Galway
Ireland
Cisco.com - http://www.cisco.com/global/UK/

Cisco Systems Internetworking (Ireland) Limited a private limited
company registered in Ireland under company number 314989 with its
registered office at Block 6, Eastpoint Business Park, Dublin 3, Ireland

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

-------- Original Message --------
Subject: Re: [sip-comm] DTMP tones supported?
Date: Thu, 29 Jul 2010 21:29:50 +0300
From: Damian Minkov<damencho@sip-communicator.org>
Reply-To: users@sip-communicator.dev.java.net
To: users@sip-communicator.dev.java.net

Hi Daniel,

On Thu, Jul 29, 2010 at 8:18 PM, Daniel Castro<danicast@cisco.com> >>>>> wrote:

Hi,

I'm now to sip-communicator and new to this list. Excellent
application btw!

Thanks for the kind words.

I was just testing it and tried to join a meeting that requires me to
send
DTMF codes, but apparently sip-communicator it's not sending them.
Does anyone know if this is supported or if this is a known issue?

Currently we support two type of DTMFs:- rfc4733(which is compatible
with rfc2833) and sending using SIP (SIP INFO messages). The first one
should be default, maybe if it doesn't work for you, you can try
disabling it by unchecking the option in Configuration form under
Audio, search for "telephone-event/8000". When you uncheck it you will
use the one with sip info messages.

Cheers
damencho

Thanks,

--

Daniel Castro

Software QA Engineer
Unified Communications Business Unit
danicast@cisco.com
Phone: +353 91 38 4778
Mobile: +353 83 318 2058

Cisco Systems Internetworking (Ireland) Limited
Oranmore Business Park
Oranmore, Galway
Ireland
Cisco.com - http://www.cisco.com/global/UK/

Cisco Systems Internetworking (Ireland) Limited a private limited
company
registered in Ireland under company number 314989 with its registered
office
at Block 6, Eastpoint Business Park, Dublin 3, Ireland

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

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

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail:
users-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


#7

Hey all,

I guess this is indeed the most plausible explanation.

According to RFC 3264:

   in the case of RTP, the mapping from a particular dynamic payload type
   number to a particular codec within that media stream MUST NOT change
   for the duration of a session. For example, if A generates an offer
   with G.711 assigned to dynamic payload type number 46, payload type
   number 46 MUST refer to G.711 from that point forward in any offers
   or answers for that media stream within the session. However, it is
   acceptable for multiple payload type numbers to be mapped to the same
   codec, so that an updated offer could also use payload type number 72
   for G.711.

So basically, it is wrong for MeetingPlace to be trying to change our
RTP payload mapping from 100 to 101. Besides, in the exchange that we
are seeing here MeetingPlace is actually trying to redefine the payload
type number for both telephone-event, that we declare as 100, and H.264,
that we declare as 101 (naughty, naughty! :slight_smile: ).

Daniel, do you thing this is something that could be repaired in
MeetingPlace?

Emil

На 05.08.10 10:11, Damian Minkov написа:

···

Hi,

I was looking at the dumps. The good dump is using g722 and as I not
see any dtmf (vie sip info or vie rtp dtmf rfc2833) I suppose there
are send like tones in the audio(inband).
About the bad dump, I see there the dtmfs and wireshark successfully
recognize them as rfc2833. But what I notice: we are invited and we
respond with RINGING, TRYING, OK and in the OK we offer the dtmf as
"Media Attribute (a): rtpmap:100 telephone-event/8000". Later in the
ACK of our OK we receive "Media Attribute (a):
rtpmap:101 telephone-event/8000" and at the end we send the dtmf
events with payload 100 (as in our offer). So here I'm not sure which
is the correct behaviour, do we have to send the dtmfs with payload
101, or the other party must accept our offer and receive them as 100
not as 101.

Regards
damencho

On Wed, Aug 4, 2010 at 6:43 PM, Daniel Castro <danicast@cisco.com> wrote:

Hi Emil,

Here are the two wireshark dumps. Please let me know if there's anything
else I can do.

Regards,
Daniel.

On 03/08/10 19:28, Emil Ivov wrote:

На 03.08.10 17:24, Daniel Castro написа:

  Hi Emil,

No trouble at all. I'll try to get this done before the end of the week.

Great!

What's the process? Do you have a bug tracking system? Should I open a
bug and attach those logs to it? Please advise.

We generally open bugs once they are confirmed as such and I am thinking
that in this case the issue might be with MeetingPlace. Therefore, could
you please send the traces here?

Cheers,
Emil

Thanks,
Daniel.

On 03/08/10 13:06, Emil Ivov wrote:

Hey Daniel

На 03.08.10 12:17, Daniel Castro написа:

I checked our documentation and the following tone formats should be
detected:
- In band audio tones (as defined in ITU-T Q.23, Q.24 (AT&T) standard)
- RFC 2833

That's the kind you'd be getting from SIP Communicator.

Our VoiceMail server is picking up the tones sent but the MeetingPlace
isn't for some reason. Does this ring any bells?

Sounds strange. Would it be too much trouble to ask you for a Wireshark
dump that contains DTMF tones sent from an application that works with
your MeetingPlace, as well as another one that shows those coming out of
SC when you are testing it?

Cheers,
Emil

Any help or pointers appreciated.

Regards,
--

Daniel Castro

Software QA Engineer
Unified Communications Business Unit
danicast@cisco.com
Phone: +353 91 38 4778
Mobile: +353 83 318 2058

Cisco Systems Internetworking (Ireland) Limited
Oranmore Business Park
Oranmore, Galway
Ireland
Cisco.com - http://www.cisco.com/global/UK/

Cisco Systems Internetworking (Ireland) Limited a private limited
company registered in Ireland under company number 314989 with its
registered office at Block 6, Eastpoint Business Park, Dublin 3, Ireland

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

-------- Original Message --------
Subject: Re: [sip-comm] DTMP tones supported?
Date: Thu, 29 Jul 2010 21:29:50 +0300
From: Damian Minkov<damencho@sip-communicator.org>
Reply-To: users@sip-communicator.dev.java.net
To: users@sip-communicator.dev.java.net

Hi Daniel,

On Thu, Jul 29, 2010 at 8:18 PM, Daniel Castro<danicast@cisco.com> >>>>>> wrote:

  Hi,

I'm now to sip-communicator and new to this list. Excellent
application btw!

Thanks for the kind words.

I was just testing it and tried to join a meeting that requires me to
send
DTMF codes, but apparently sip-communicator it's not sending them.
Does anyone know if this is supported or if this is a known issue?

Currently we support two type of DTMFs:- rfc4733(which is compatible
with rfc2833) and sending using SIP (SIP INFO messages). The first one
should be default, maybe if it doesn't work for you, you can try
disabling it by unchecking the option in Configuration form under
Audio, search for "telephone-event/8000". When you uncheck it you will
use the one with sip info messages.

Cheers
damencho

Thanks,

--

Daniel Castro

Software QA Engineer
Unified Communications Business Unit
danicast@cisco.com
Phone: +353 91 38 4778
Mobile: +353 83 318 2058

Cisco Systems Internetworking (Ireland) Limited
Oranmore Business Park
Oranmore, Galway
Ireland
Cisco.com - http://www.cisco.com/global/UK/

Cisco Systems Internetworking (Ireland) Limited a private limited
company
registered in Ireland under company number 314989 with its registered
office
at Block 6, Eastpoint Business Park, Dublin 3, Ireland

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

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

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail:
users-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


#8

Hey all,

I guess this is indeed the most plausible explanation.

According to RFC 3264:

   in the case of RTP, the mapping from a particular dynamic payload type
   number to a particular codec within that media stream MUST NOT change
   for the duration of a session. For example, if A generates an offer
   with G.711 assigned to dynamic payload type number 46, payload type
   number 46 MUST refer to G.711 from that point forward in any offers
   or answers for that media stream within the session. However, it is
   acceptable for multiple payload type numbers to be mapped to the same
   codec, so that an updated offer could also use payload type number 72
   for G.711.

So basically, it is wrong for MeetingPlace to be trying to change our
RTP payload mapping from 100 to 101. Besides, in the exchange that we
are seeing here MeetingPlace is actually trying to redefine the payload
type number for both telephone-event, that we declare as 100, and H.264,
that we declare as 101 (naughty, naughty! :slight_smile: ).

Daniel, do you thing this is something that could be repaired in
MeetingPlace?

Emil

На 05.08.10 10:11, Damian Minkov написа:

···

Hi,

I was looking at the dumps. The good dump is using g722 and as I not
see any dtmf (vie sip info or vie rtp dtmf rfc2833) I suppose there
are send like tones in the audio(inband).
About the bad dump, I see there the dtmfs and wireshark successfully
recognize them as rfc2833. But what I notice: we are invited and we
respond with RINGING, TRYING, OK and in the OK we offer the dtmf as
"Media Attribute (a): rtpmap:100 telephone-event/8000". Later in the
ACK of our OK we receive "Media Attribute (a):
rtpmap:101 telephone-event/8000" and at the end we send the dtmf
events with payload 100 (as in our offer). So here I'm not sure which
is the correct behaviour, do we have to send the dtmfs with payload
101, or the other party must accept our offer and receive them as 100
not as 101.

Regards
damencho

On Wed, Aug 4, 2010 at 6:43 PM, Daniel Castro <danicast@cisco.com> wrote:

Hi Emil,

Here are the two wireshark dumps. Please let me know if there's anything
else I can do.

Regards,
Daniel.

On 03/08/10 19:28, Emil Ivov wrote:

На 03.08.10 17:24, Daniel Castro написа:

  Hi Emil,

No trouble at all. I'll try to get this done before the end of the week.

Great!

What's the process? Do you have a bug tracking system? Should I open a
bug and attach those logs to it? Please advise.

We generally open bugs once they are confirmed as such and I am thinking
that in this case the issue might be with MeetingPlace. Therefore, could
you please send the traces here?

Cheers,
Emil

Thanks,
Daniel.

On 03/08/10 13:06, Emil Ivov wrote:

Hey Daniel

На 03.08.10 12:17, Daniel Castro написа:

I checked our documentation and the following tone formats should be
detected:
- In band audio tones (as defined in ITU-T Q.23, Q.24 (AT&T) standard)
- RFC 2833

That's the kind you'd be getting from SIP Communicator.

Our VoiceMail server is picking up the tones sent but the MeetingPlace
isn't for some reason. Does this ring any bells?

Sounds strange. Would it be too much trouble to ask you for a Wireshark
dump that contains DTMF tones sent from an application that works with
your MeetingPlace, as well as another one that shows those coming out of
SC when you are testing it?

Cheers,
Emil

Any help or pointers appreciated.

Regards,
--

Daniel Castro

Software QA Engineer
Unified Communications Business Unit
danicast@cisco.com
Phone: +353 91 38 4778
Mobile: +353 83 318 2058

Cisco Systems Internetworking (Ireland) Limited
Oranmore Business Park
Oranmore, Galway
Ireland
Cisco.com - http://www.cisco.com/global/UK/

Cisco Systems Internetworking (Ireland) Limited a private limited
company registered in Ireland under company number 314989 with its
registered office at Block 6, Eastpoint Business Park, Dublin 3, Ireland

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

-------- Original Message --------
Subject: Re: [sip-comm] DTMP tones supported?
Date: Thu, 29 Jul 2010 21:29:50 +0300
From: Damian Minkov<damencho@sip-communicator.org>
Reply-To: users@sip-communicator.dev.java.net
To: users@sip-communicator.dev.java.net

Hi Daniel,

On Thu, Jul 29, 2010 at 8:18 PM, Daniel Castro<danicast@cisco.com> >>>>>> wrote:

  Hi,

I'm now to sip-communicator and new to this list. Excellent
application btw!

Thanks for the kind words.

I was just testing it and tried to join a meeting that requires me to
send
DTMF codes, but apparently sip-communicator it's not sending them.
Does anyone know if this is supported or if this is a known issue?

Currently we support two type of DTMFs:- rfc4733(which is compatible
with rfc2833) and sending using SIP (SIP INFO messages). The first one
should be default, maybe if it doesn't work for you, you can try
disabling it by unchecking the option in Configuration form under
Audio, search for "telephone-event/8000". When you uncheck it you will
use the one with sip info messages.

Cheers
damencho

Thanks,

--

Daniel Castro

Software QA Engineer
Unified Communications Business Unit
danicast@cisco.com
Phone: +353 91 38 4778
Mobile: +353 83 318 2058

Cisco Systems Internetworking (Ireland) Limited
Oranmore Business Park
Oranmore, Galway
Ireland
Cisco.com - http://www.cisco.com/global/UK/

Cisco Systems Internetworking (Ireland) Limited a private limited
company
registered in Ireland under company number 314989 with its registered
office
at Block 6, Eastpoint Business Park, Dublin 3, Ireland

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

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

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail:
users-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


#9

Hi Emil,

Let me get in contact with the developers and I'll get back to you.

Thanks very much,
Daniel.

···

On 05/08/10 10:23, Emil Ivov wrote:

Hey all,

I guess this is indeed the most plausible explanation.

According to RFC 3264:

    in the case of RTP, the mapping from a particular dynamic payload type
    number to a particular codec within that media stream MUST NOT change
    for the duration of a session. For example, if A generates an offer
    with G.711 assigned to dynamic payload type number 46, payload type
    number 46 MUST refer to G.711 from that point forward in any offers
    or answers for that media stream within the session. However, it is
    acceptable for multiple payload type numbers to be mapped to the same
    codec, so that an updated offer could also use payload type number 72
    for G.711.

So basically, it is wrong for MeetingPlace to be trying to change our
RTP payload mapping from 100 to 101. Besides, in the exchange that we
are seeing here MeetingPlace is actually trying to redefine the payload
type number for both telephone-event, that we declare as 100, and H.264,
that we declare as 101 (naughty, naughty! :slight_smile: ).

Daniel, do you thing this is something that could be repaired in
MeetingPlace?

Emil

На 05.08.10 10:11, Damian Minkov написа:

Hi,

I was looking at the dumps. The good dump is using g722 and as I not
see any dtmf (vie sip info or vie rtp dtmf rfc2833) I suppose there
are send like tones in the audio(inband).
About the bad dump, I see there the dtmfs and wireshark successfully
recognize them as rfc2833. But what I notice: we are invited and we
respond with RINGING, TRYING, OK and in the OK we offer the dtmf as
"Media Attribute (a): rtpmap:100 telephone-event/8000". Later in the
ACK of our OK we receive "Media Attribute (a):
rtpmap:101 telephone-event/8000" and at the end we send the dtmf
events with payload 100 (as in our offer). So here I'm not sure which
is the correct behaviour, do we have to send the dtmfs with payload
101, or the other party must accept our offer and receive them as 100
not as 101.

Regards
damencho

On Wed, Aug 4, 2010 at 6:43 PM, Daniel Castro<danicast@cisco.com> wrote:

  Hi Emil,

Here are the two wireshark dumps. Please let me know if there's anything
else I can do.

Regards,
Daniel.

On 03/08/10 19:28, Emil Ivov wrote:

На 03.08.10 17:24, Daniel Castro написа:

   Hi Emil,

No trouble at all. I'll try to get this done before the end of the week.

Great!

What's the process? Do you have a bug tracking system? Should I open a
bug and attach those logs to it? Please advise.

We generally open bugs once they are confirmed as such and I am thinking
that in this case the issue might be with MeetingPlace. Therefore, could
you please send the traces here?

Cheers,
Emil

Thanks,
Daniel.

On 03/08/10 13:06, Emil Ivov wrote:

Hey Daniel

На 03.08.10 12:17, Daniel Castro написа:

I checked our documentation and the following tone formats should be
detected:
- In band audio tones (as defined in ITU-T Q.23, Q.24 (AT&T) standard)
- RFC 2833

That's the kind you'd be getting from SIP Communicator.

Our VoiceMail server is picking up the tones sent but the MeetingPlace
isn't for some reason. Does this ring any bells?

Sounds strange. Would it be too much trouble to ask you for a Wireshark
dump that contains DTMF tones sent from an application that works with
your MeetingPlace, as well as another one that shows those coming out of
SC when you are testing it?

Cheers,
Emil

Any help or pointers appreciated.

Regards,
--

Daniel Castro

Software QA Engineer
Unified Communications Business Unit
danicast@cisco.com
Phone: +353 91 38 4778
Mobile: +353 83 318 2058

Cisco Systems Internetworking (Ireland) Limited
Oranmore Business Park
Oranmore, Galway
Ireland
Cisco.com - http://www.cisco.com/global/UK/

Cisco Systems Internetworking (Ireland) Limited a private limited
company registered in Ireland under company number 314989 with its
registered office at Block 6, Eastpoint Business Park, Dublin 3, Ireland

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

-------- Original Message --------
Subject: Re: [sip-comm] DTMP tones supported?
Date: Thu, 29 Jul 2010 21:29:50 +0300
From: Damian Minkov<damencho@sip-communicator.org>
Reply-To: users@sip-communicator.dev.java.net
To: users@sip-communicator.dev.java.net

Hi Daniel,

On Thu, Jul 29, 2010 at 8:18 PM, Daniel Castro<danicast@cisco.com> >>>>>>> wrote:

   Hi,

I'm now to sip-communicator and new to this list. Excellent
application btw!

Thanks for the kind words.

I was just testing it and tried to join a meeting that requires me to
send
DTMF codes, but apparently sip-communicator it's not sending them.
Does anyone know if this is supported or if this is a known issue?

Currently we support two type of DTMFs:- rfc4733(which is compatible
with rfc2833) and sending using SIP (SIP INFO messages). The first one
should be default, maybe if it doesn't work for you, you can try
disabling it by unchecking the option in Configuration form under
Audio, search for "telephone-event/8000". When you uncheck it you will
use the one with sip info messages.

Cheers
damencho

Thanks,

--

Daniel Castro

Software QA Engineer
Unified Communications Business Unit
danicast@cisco.com
Phone: +353 91 38 4778
Mobile: +353 83 318 2058

Cisco Systems Internetworking (Ireland) Limited
Oranmore Business Park
Oranmore, Galway
Ireland
Cisco.com - http://www.cisco.com/global/UK/

Cisco Systems Internetworking (Ireland) Limited a private limited
company
registered in Ireland under company number 314989 with its registered
office
at Block 6, Eastpoint Business Park, Dublin 3, Ireland

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

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

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail:
users-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

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


#10

Hi Emil,

I talked to the developers and this is what they replied:

RFC3264 permits the use of asymmetric payload type. The paragraph they are quoting applies to the offerer MUST not change the offer once extended. But the answer may have different value. No one can restrict the answer value.

Quoting RFC3264 :
“For sendrecv RTP streams, the payload type numbers indicate the value of the payload type field the offerer expects to receive, and would prefer to send. However, for sendonly and sendrecv streams, the answer might indicate different payload type numbers for the same codecs, in which case, the offerer MUST send with the payload type numbers from the answer.”

Is it possible for me to change the payload value to 101 somehow as a workaround?

Any plans to let users control this? For example, Twinkle provides the following in the GUI:

I don't think I can persuade for a fix/change in MP... can't provide a business case at this stage that will justify the work.

Regards,
Daniel.

···

On 05/08/10 10:23, Emil Ivov wrote:

Hey all,

I guess this is indeed the most plausible explanation.

According to RFC 3264:

    in the case of RTP, the mapping from a particular dynamic payload type
    number to a particular codec within that media stream MUST NOT change
    for the duration of a session. For example, if A generates an offer
    with G.711 assigned to dynamic payload type number 46, payload type
    number 46 MUST refer to G.711 from that point forward in any offers
    or answers for that media stream within the session. However, it is
    acceptable for multiple payload type numbers to be mapped to the same
    codec, so that an updated offer could also use payload type number 72
    for G.711.

So basically, it is wrong for MeetingPlace to be trying to change our
RTP payload mapping from 100 to 101. Besides, in the exchange that we
are seeing here MeetingPlace is actually trying to redefine the payload
type number for both telephone-event, that we declare as 100, and H.264,
that we declare as 101 (naughty, naughty! :slight_smile: ).

Daniel, do you thing this is something that could be repaired in
MeetingPlace?

Emil

На 05.08.10 10:11, Damian Minkov написа:

Hi,

I was looking at the dumps. The good dump is using g722 and as I not
see any dtmf (vie sip info or vie rtp dtmf rfc2833) I suppose there
are send like tones in the audio(inband).
About the bad dump, I see there the dtmfs and wireshark successfully
recognize them as rfc2833. But what I notice: we are invited and we
respond with RINGING, TRYING, OK and in the OK we offer the dtmf as
"Media Attribute (a): rtpmap:100 telephone-event/8000". Later in the
ACK of our OK we receive "Media Attribute (a):
rtpmap:101 telephone-event/8000" and at the end we send the dtmf
events with payload 100 (as in our offer). So here I'm not sure which
is the correct behaviour, do we have to send the dtmfs with payload
101, or the other party must accept our offer and receive them as 100
not as 101.

Regards
damencho

On Wed, Aug 4, 2010 at 6:43 PM, Daniel Castro<danicast@cisco.com> wrote:

  Hi Emil,

Here are the two wireshark dumps. Please let me know if there's anything
else I can do.

Regards,
Daniel.

On 03/08/10 19:28, Emil Ivov wrote:

На 03.08.10 17:24, Daniel Castro написа:

   Hi Emil,

No trouble at all. I'll try to get this done before the end of the week.

Great!

What's the process? Do you have a bug tracking system? Should I open a
bug and attach those logs to it? Please advise.

We generally open bugs once they are confirmed as such and I am thinking
that in this case the issue might be with MeetingPlace. Therefore, could
you please send the traces here?

Cheers,
Emil

Thanks,
Daniel.

On 03/08/10 13:06, Emil Ivov wrote:

Hey Daniel

На 03.08.10 12:17, Daniel Castro написа:

I checked our documentation and the following tone formats should be
detected:
- In band audio tones (as defined in ITU-T Q.23, Q.24 (AT&T) standard)
- RFC 2833

That's the kind you'd be getting from SIP Communicator.

Our VoiceMail server is picking up the tones sent but the MeetingPlace
isn't for some reason. Does this ring any bells?

Sounds strange. Would it be too much trouble to ask you for a Wireshark
dump that contains DTMF tones sent from an application that works with
your MeetingPlace, as well as another one that shows those coming out of
SC when you are testing it?

Cheers,
Emil

Any help or pointers appreciated.

Regards,
--

Daniel Castro

Software QA Engineer
Unified Communications Business Unit
danicast@cisco.com
Phone: +353 91 38 4778
Mobile: +353 83 318 2058

Cisco Systems Internetworking (Ireland) Limited
Oranmore Business Park
Oranmore, Galway
Ireland
Cisco.com - http://www.cisco.com/global/UK/

Cisco Systems Internetworking (Ireland) Limited a private limited
company registered in Ireland under company number 314989 with its
registered office at Block 6, Eastpoint Business Park, Dublin 3, Ireland

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

-------- Original Message --------
Subject: Re: [sip-comm] DTMP tones supported?
Date: Thu, 29 Jul 2010 21:29:50 +0300
From: Damian Minkov<damencho@sip-communicator.org>
Reply-To: users@sip-communicator.dev.java.net
To: users@sip-communicator.dev.java.net

Hi Daniel,

On Thu, Jul 29, 2010 at 8:18 PM, Daniel Castro<danicast@cisco.com> >>>>>>> wrote:

   Hi,

I'm now to sip-communicator and new to this list. Excellent
application btw!

Thanks for the kind words.

I was just testing it and tried to join a meeting that requires me to
send
DTMF codes, but apparently sip-communicator it's not sending them.
Does anyone know if this is supported or if this is a known issue?

Currently we support two type of DTMFs:- rfc4733(which is compatible
with rfc2833) and sending using SIP (SIP INFO messages). The first one
should be default, maybe if it doesn't work for you, you can try
disabling it by unchecking the option in Configuration form under
Audio, search for "telephone-event/8000". When you uncheck it you will
use the one with sip info messages.

Cheers
damencho

Thanks,

--

Daniel Castro

Software QA Engineer
Unified Communications Business Unit
danicast@cisco.com
Phone: +353 91 38 4778
Mobile: +353 83 318 2058

Cisco Systems Internetworking (Ireland) Limited
Oranmore Business Park
Oranmore, Galway
Ireland
Cisco.com - http://www.cisco.com/global/UK/

Cisco Systems Internetworking (Ireland) Limited a private limited
company
registered in Ireland under company number 314989 with its registered
office
at Block 6, Eastpoint Business Park, Dublin 3, Ireland

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

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

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail:
users-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


#11

Hey Daniel,

На 06.08.10 16:25, Daniel Castro написа:

Hi Emil,

I talked to the developers and this is what they replied:

RFC3264 permits the use of asymmetric payload type. The paragraph they
are quoting applies to the offerer MUST not change the offer once
extended. But the answer may have different value. No one can restrict
the answer value.

Quoting RFC3264 :
“For sendrecv RTP streams, the payload type numbers indicate the value
of the payload type field the offerer expects to receive, and would
prefer to send. However, for sendonly and sendrecv streams, the answer
might indicate different payload type numbers for the same codecs, in
which case, the offerer MUST send with the payload type numbers from the
answer.”

Ah darn, so much for our beautiful PT negotiation code :). Anyways, this
is indeed a valid point so we'll need to address it. Could you please
file an issue in our tracker?

Is it possible for me to change the payload value to 101 somehow as a
workaround?

Any plans to let users control this? For example, Twinkle provides the
following in the GUI:

We'll think about it. Ideally I'd prefer us to simply respect the RFC.
However, enabling our streams to send media with one payload type number
and receive it with a different one might turn out to be quite a hassle,
so we might indeed go for that kind of a work around.

Thanks for the suggestion!

Emil

···

I don't think I can persuade for a fix/change in MP... can't provide a
business case at this stage that will justify the work.

Regards,
Daniel.

On 05/08/10 10:23, Emil Ivov wrote:

Hey all,

I guess this is indeed the most plausible explanation.

According to RFC 3264:

   in the case of RTP, the mapping from a particular dynamic payload type
   number to a particular codec within that media stream MUST NOT change
   for the duration of a session. For example, if A generates an offer
   with G.711 assigned to dynamic payload type number 46, payload type
   number 46 MUST refer to G.711 from that point forward in any offers
   or answers for that media stream within the session. However, it is
   acceptable for multiple payload type numbers to be mapped to the same
   codec, so that an updated offer could also use payload type number 72
   for G.711.

So basically, it is wrong for MeetingPlace to be trying to change our
RTP payload mapping from 100 to 101. Besides, in the exchange that we
are seeing here MeetingPlace is actually trying to redefine the payload
type number for both telephone-event, that we declare as 100, and H.264,
that we declare as 101 (naughty, naughty! :slight_smile: ).

Daniel, do you thing this is something that could be repaired in
MeetingPlace?

Emil

На 05.08.10 10:11, Damian Minkov написа:

Hi,

I was looking at the dumps. The good dump is using g722 and as I not
see any dtmf (vie sip info or vie rtp dtmf rfc2833) I suppose there
are send like tones in the audio(inband).
About the bad dump, I see there the dtmfs and wireshark successfully
recognize them as rfc2833. But what I notice: we are invited and we
respond with RINGING, TRYING, OK and in the OK we offer the dtmf as
"Media Attribute (a): rtpmap:100 telephone-event/8000". Later in the
ACK of our OK we receive "Media Attribute (a):
rtpmap:101 telephone-event/8000" and at the end we send the dtmf
events with payload 100 (as in our offer). So here I'm not sure which
is the correct behaviour, do we have to send the dtmfs with payload
101, or the other party must accept our offer and receive them as 100
not as 101.

Regards
damencho

On Wed, Aug 4, 2010 at 6:43 PM, Daniel Castro <danicast@cisco.com> wrote:

Hi Emil,

Here are the two wireshark dumps. Please let me know if there's anything
else I can do.

Regards,
Daniel.

On 03/08/10 19:28, Emil Ivov wrote:

На 03.08.10 17:24, Daniel Castro написа:

  Hi Emil,

No trouble at all. I'll try to get this done before the end of the week.

Great!

What's the process? Do you have a bug tracking system? Should I open a
bug and attach those logs to it? Please advise.

We generally open bugs once they are confirmed as such and I am thinking
that in this case the issue might be with MeetingPlace. Therefore, could
you please send the traces here?

Cheers,
Emil

Thanks,
Daniel.

On 03/08/10 13:06, Emil Ivov wrote:

Hey Daniel

На 03.08.10 12:17, Daniel Castro написа:

I checked our documentation and the following tone formats should be
detected:
- In band audio tones (as defined in ITU-T Q.23, Q.24 (AT&T) standard)
- RFC 2833

That's the kind you'd be getting from SIP Communicator.

Our VoiceMail server is picking up the tones sent but the MeetingPlace
isn't for some reason. Does this ring any bells?

Sounds strange. Would it be too much trouble to ask you for a Wireshark
dump that contains DTMF tones sent from an application that works with
your MeetingPlace, as well as another one that shows those coming out of
SC when you are testing it?

Cheers,
Emil

Any help or pointers appreciated.

Regards,
--

Daniel Castro

Software QA Engineer
Unified Communications Business Unit
danicast@cisco.com
Phone: +353 91 38 4778
Mobile: +353 83 318 2058

Cisco Systems Internetworking (Ireland) Limited
Oranmore Business Park
Oranmore, Galway
Ireland
Cisco.com - http://www.cisco.com/global/UK/

Cisco Systems Internetworking (Ireland) Limited a private limited
company registered in Ireland under company number 314989 with its
registered office at Block 6, Eastpoint Business Park, Dublin 3, Ireland

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

-------- Original Message --------
Subject: Re: [sip-comm] DTMP tones supported?
Date: Thu, 29 Jul 2010 21:29:50 +0300
From: Damian Minkov<damencho@sip-communicator.org>
Reply-To: users@sip-communicator.dev.java.net
To: users@sip-communicator.dev.java.net

Hi Daniel,

On Thu, Jul 29, 2010 at 8:18 PM, Daniel Castro<danicast@cisco.com> >>>>>>>> wrote:

  Hi,

I'm now to sip-communicator and new to this list. Excellent
application btw!

Thanks for the kind words.

I was just testing it and tried to join a meeting that requires me to
send
DTMF codes, but apparently sip-communicator it's not sending them.
Does anyone know if this is supported or if this is a known issue?

Currently we support two type of DTMFs:- rfc4733(which is compatible
with rfc2833) and sending using SIP (SIP INFO messages). The first one
should be default, maybe if it doesn't work for you, you can try
disabling it by unchecking the option in Configuration form under
Audio, search for "telephone-event/8000". When you uncheck it you will
use the one with sip info messages.

Cheers
damencho

Thanks,

--

Daniel Castro

Software QA Engineer
Unified Communications Business Unit
danicast@cisco.com
Phone: +353 91 38 4778
Mobile: +353 83 318 2058

Cisco Systems Internetworking (Ireland) Limited
Oranmore Business Park
Oranmore, Galway
Ireland
Cisco.com - http://www.cisco.com/global/UK/

Cisco Systems Internetworking (Ireland) Limited a private limited
company
registered in Ireland under company number 314989 with its registered
office
at Block 6, Eastpoint Business Park, Dublin 3, Ireland

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

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

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail:
users-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


#12

Hi Emil,

Thanks for the follow up. Raised bug 848 <https://sip-communicator.dev.java.net/issues/show_bug.cgi?id=848>.
Didn't add much detail to the bug as it's all on this thread, let me know if you need me to add anything else to the report.

Thanks,
Daniel.

···

On 06/08/10 15:46, Emil Ivov wrote:

Hey Daniel,

На 06.08.10 16:25, Daniel Castro написа:

  Hi Emil,

I talked to the developers and this is what they replied:

RFC3264 permits the use of asymmetric payload type. The paragraph they
are quoting applies to the offerer MUST not change the offer once
extended. But the answer may have different value. No one can restrict
the answer value.

Quoting RFC3264 :
“For sendrecv RTP streams, the payload type numbers indicate the value
of the payload type field the offerer expects to receive, and would
prefer to send. However, for sendonly and sendrecv streams, the answer
might indicate different payload type numbers for the same codecs, in
which case, the offerer MUST send with the payload type numbers from the
answer.”

Ah darn, so much for our beautiful PT negotiation code :). Anyways, this
is indeed a valid point so we'll need to address it. Could you please
file an issue in our tracker?

Is it possible for me to change the payload value to 101 somehow as a
workaround?

Any plans to let users control this? For example, Twinkle provides the
following in the GUI:

We'll think about it. Ideally I'd prefer us to simply respect the RFC.
However, enabling our streams to send media with one payload type number
and receive it with a different one might turn out to be quite a hassle,
so we might indeed go for that kind of a work around.

Thanks for the suggestion!

Emil

I don't think I can persuade for a fix/change in MP... can't provide a
business case at this stage that will justify the work.

Regards,
Daniel.

On 05/08/10 10:23, Emil Ivov wrote:

Hey all,

I guess this is indeed the most plausible explanation.

According to RFC 3264:

    in the case of RTP, the mapping from a particular dynamic payload type
    number to a particular codec within that media stream MUST NOT change
    for the duration of a session. For example, if A generates an offer
    with G.711 assigned to dynamic payload type number 46, payload type
    number 46 MUST refer to G.711 from that point forward in any offers
    or answers for that media stream within the session. However, it is
    acceptable for multiple payload type numbers to be mapped to the same
    codec, so that an updated offer could also use payload type number 72
    for G.711.

So basically, it is wrong for MeetingPlace to be trying to change our
RTP payload mapping from 100 to 101. Besides, in the exchange that we
are seeing here MeetingPlace is actually trying to redefine the payload
type number for both telephone-event, that we declare as 100, and H.264,
that we declare as 101 (naughty, naughty! :slight_smile: ).

Daniel, do you thing this is something that could be repaired in
MeetingPlace?

Emil

На 05.08.10 10:11, Damian Minkov написа:

Hi,

I was looking at the dumps. The good dump is using g722 and as I not
see any dtmf (vie sip info or vie rtp dtmf rfc2833) I suppose there
are send like tones in the audio(inband).
About the bad dump, I see there the dtmfs and wireshark successfully
recognize them as rfc2833. But what I notice: we are invited and we
respond with RINGING, TRYING, OK and in the OK we offer the dtmf as
"Media Attribute (a): rtpmap:100 telephone-event/8000". Later in the
ACK of our OK we receive "Media Attribute (a):
rtpmap:101 telephone-event/8000" and at the end we send the dtmf
events with payload 100 (as in our offer). So here I'm not sure which
is the correct behaviour, do we have to send the dtmfs with payload
101, or the other party must accept our offer and receive them as 100
not as 101.

Regards
damencho

On Wed, Aug 4, 2010 at 6:43 PM, Daniel Castro<danicast@cisco.com> wrote:

  Hi Emil,

Here are the two wireshark dumps. Please let me know if there's anything
else I can do.

Regards,
Daniel.

On 03/08/10 19:28, Emil Ivov wrote:

На 03.08.10 17:24, Daniel Castro написа:

   Hi Emil,

No trouble at all. I'll try to get this done before the end of the week.

Great!

What's the process? Do you have a bug tracking system? Should I open a
bug and attach those logs to it? Please advise.

We generally open bugs once they are confirmed as such and I am thinking
that in this case the issue might be with MeetingPlace. Therefore, could
you please send the traces here?

Cheers,
Emil

Thanks,
Daniel.

On 03/08/10 13:06, Emil Ivov wrote:

Hey Daniel

На 03.08.10 12:17, Daniel Castro написа:

I checked our documentation and the following tone formats should be
detected:
- In band audio tones (as defined in ITU-T Q.23, Q.24 (AT&T) standard)
- RFC 2833

That's the kind you'd be getting from SIP Communicator.

Our VoiceMail server is picking up the tones sent but the MeetingPlace
isn't for some reason. Does this ring any bells?

Sounds strange. Would it be too much trouble to ask you for a Wireshark
dump that contains DTMF tones sent from an application that works with
your MeetingPlace, as well as another one that shows those coming out of
SC when you are testing it?

Cheers,
Emil

Any help or pointers appreciated.

Regards,
--

Daniel Castro

Software QA Engineer
Unified Communications Business Unit
danicast@cisco.com
Phone: +353 91 38 4778
Mobile: +353 83 318 2058

Cisco Systems Internetworking (Ireland) Limited
Oranmore Business Park
Oranmore, Galway
Ireland
Cisco.com - http://www.cisco.com/global/UK/

Cisco Systems Internetworking (Ireland) Limited a private limited
company registered in Ireland under company number 314989 with its
registered office at Block 6, Eastpoint Business Park, Dublin 3, Ireland

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

-------- Original Message --------
Subject: Re: [sip-comm] DTMP tones supported?
Date: Thu, 29 Jul 2010 21:29:50 +0300
From: Damian Minkov<damencho@sip-communicator.org>
Reply-To: users@sip-communicator.dev.java.net
To: users@sip-communicator.dev.java.net

Hi Daniel,

On Thu, Jul 29, 2010 at 8:18 PM, Daniel Castro<danicast@cisco.com> >>>>>>>>> wrote:

   Hi,

I'm now to sip-communicator and new to this list. Excellent
application btw!

Thanks for the kind words.

I was just testing it and tried to join a meeting that requires me to
send
DTMF codes, but apparently sip-communicator it's not sending them.
Does anyone know if this is supported or if this is a known issue?

Currently we support two type of DTMFs:- rfc4733(which is compatible
with rfc2833) and sending using SIP (SIP INFO messages). The first one
should be default, maybe if it doesn't work for you, you can try
disabling it by unchecking the option in Configuration form under
Audio, search for "telephone-event/8000". When you uncheck it you will
use the one with sip info messages.

Cheers
damencho

Thanks,

--

Daniel Castro

Software QA Engineer
Unified Communications Business Unit
danicast@cisco.com
Phone: +353 91 38 4778
Mobile: +353 83 318 2058

Cisco Systems Internetworking (Ireland) Limited
Oranmore Business Park
Oranmore, Galway
Ireland
Cisco.com - http://www.cisco.com/global/UK/

Cisco Systems Internetworking (Ireland) Limited a private limited
company
registered in Ireland under company number 314989 with its registered
office
at Block 6, Eastpoint Business Park, Dublin 3, Ireland

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

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

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail:
users-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


#13

Hey Daniel,

Could you please try the latest build (2858) and see whether that's
working better?

As mentioned previously, adding the possibility for a stream to use
different payload type numbers, for the same payload, when sending and
receiving, is a too much of a hassle.

Instead, we've implemented the possibility to assign "preferred" dynamic
payload type numbers to media formats. This way, whenever we try to
allocate a dynamic payload type to a format, we'll first try that number.

I've seen 101 used for telephone-event in various situations so we've
decided to hard code it as preferred for the corresponding media format.
At some point we may also add the possibility to change this from the
user interface but this didn't seem like something particularly urgent
at this point.

Please, let us know how this works out for you.

Cheers,
Emil

На 06.08.10 17:45, Daniel Castro написа:

···

Hi Emil,

Thanks for the follow up. Raised bug 848
<https://sip-communicator.dev.java.net/issues/show_bug.cgi?id=848>.
Didn't add much detail to the bug as it's all on this thread, let me
know if you need me to add anything else to the report.

Thanks,
Daniel.

On 06/08/10 15:46, Emil Ivov wrote:

Hey Daniel,

На 06.08.10 16:25, Daniel Castro написа:

Hi Emil,

I talked to the developers and this is what they replied:

RFC3264 permits the use of asymmetric payload type. The paragraph they
are quoting applies to the offerer MUST not change the offer once
extended. But the answer may have different value. No one can restrict
the answer value.

Quoting RFC3264 :
“For sendrecv RTP streams, the payload type numbers indicate the value
of the payload type field the offerer expects to receive, and would
prefer to send. However, for sendonly and sendrecv streams, the answer
might indicate different payload type numbers for the same codecs, in
which case, the offerer MUST send with the payload type numbers from the
answer.”

Ah darn, so much for our beautiful PT negotiation code :). Anyways, this
is indeed a valid point so we'll need to address it. Could you please
file an issue in our tracker?

Is it possible for me to change the payload value to 101 somehow as a
workaround?

Any plans to let users control this? For example, Twinkle provides the
following in the GUI:

We'll think about it. Ideally I'd prefer us to simply respect the RFC.
However, enabling our streams to send media with one payload type number
and receive it with a different one might turn out to be quite a hassle,
so we might indeed go for that kind of a work around.

Thanks for the suggestion!

Emil

I don't think I can persuade for a fix/change in MP... can't provide a
business case at this stage that will justify the work.

Regards,
Daniel.

On 05/08/10 10:23, Emil Ivov wrote:

Hey all,

I guess this is indeed the most plausible explanation.

According to RFC 3264:

   in the case of RTP, the mapping from a particular dynamic payload type
   number to a particular codec within that media stream MUST NOT change
   for the duration of a session. For example, if A generates an offer
   with G.711 assigned to dynamic payload type number 46, payload type
   number 46 MUST refer to G.711 from that point forward in any offers
   or answers for that media stream within the session. However, it is
   acceptable for multiple payload type numbers to be mapped to the same
   codec, so that an updated offer could also use payload type number 72
   for G.711.

So basically, it is wrong for MeetingPlace to be trying to change our
RTP payload mapping from 100 to 101. Besides, in the exchange that we
are seeing here MeetingPlace is actually trying to redefine the payload
type number for both telephone-event, that we declare as 100, and H.264,
that we declare as 101 (naughty, naughty! :slight_smile: ).

Daniel, do you thing this is something that could be repaired in
MeetingPlace?

Emil

На 05.08.10 10:11, Damian Minkov написа:

Hi,

I was looking at the dumps. The good dump is using g722 and as I not
see any dtmf (vie sip info or vie rtp dtmf rfc2833) I suppose there
are send like tones in the audio(inband).
About the bad dump, I see there the dtmfs and wireshark successfully
recognize them as rfc2833. But what I notice: we are invited and we
respond with RINGING, TRYING, OK and in the OK we offer the dtmf as
"Media Attribute (a): rtpmap:100 telephone-event/8000". Later in the
ACK of our OK we receive "Media Attribute (a):
rtpmap:101 telephone-event/8000" and at the end we send the dtmf
events with payload 100 (as in our offer). So here I'm not sure which
is the correct behaviour, do we have to send the dtmfs with payload
101, or the other party must accept our offer and receive them as 100
not as 101.

Regards
damencho

On Wed, Aug 4, 2010 at 6:43 PM, Daniel Castro <danicast@cisco.com> wrote:

Hi Emil,

Here are the two wireshark dumps. Please let me know if there's anything
else I can do.

Regards,
Daniel.

On 03/08/10 19:28, Emil Ivov wrote:

На 03.08.10 17:24, Daniel Castro написа:

  Hi Emil,

No trouble at all. I'll try to get this done before the end of the week.

Great!

What's the process? Do you have a bug tracking system? Should I open a
bug and attach those logs to it? Please advise.

We generally open bugs once they are confirmed as such and I am thinking
that in this case the issue might be with MeetingPlace. Therefore, could
you please send the traces here?

Cheers,
Emil

Thanks,
Daniel.

On 03/08/10 13:06, Emil Ivov wrote:

Hey Daniel

На 03.08.10 12:17, Daniel Castro написа:

I checked our documentation and the following tone formats should be
detected:
- In band audio tones (as defined in ITU-T Q.23, Q.24 (AT&T) standard)
- RFC 2833

That's the kind you'd be getting from SIP Communicator.

Our VoiceMail server is picking up the tones sent but the MeetingPlace
isn't for some reason. Does this ring any bells?

Sounds strange. Would it be too much trouble to ask you for a Wireshark
dump that contains DTMF tones sent from an application that works with
your MeetingPlace, as well as another one that shows those coming out of
SC when you are testing it?

Cheers,
Emil

Any help or pointers appreciated.

Regards,
--

Daniel Castro

Software QA Engineer
Unified Communications Business Unit
danicast@cisco.com
Phone: +353 91 38 4778
Mobile: +353 83 318 2058

Cisco Systems Internetworking (Ireland) Limited
Oranmore Business Park
Oranmore, Galway
Ireland
Cisco.com - http://www.cisco.com/global/UK/

Cisco Systems Internetworking (Ireland) Limited a private limited
company registered in Ireland under company number 314989 with its
registered office at Block 6, Eastpoint Business Park, Dublin 3, Ireland

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

-------- Original Message --------
Subject: Re: [sip-comm] DTMP tones supported?
Date: Thu, 29 Jul 2010 21:29:50 +0300
From: Damian Minkov<damencho@sip-communicator.org>
Reply-To: users@sip-communicator.dev.java.net
To: users@sip-communicator.dev.java.net

Hi Daniel,

On Thu, Jul 29, 2010 at 8:18 PM, Daniel Castro<danicast@cisco.com> >>>>>>>>>> wrote:

  Hi,

I'm now to sip-communicator and new to this list. Excellent
application btw!

Thanks for the kind words.

I was just testing it and tried to join a meeting that requires me to
send
DTMF codes, but apparently sip-communicator it's not sending them.
Does anyone know if this is supported or if this is a known issue?

Currently we support two type of DTMFs:- rfc4733(which is compatible
with rfc2833) and sending using SIP (SIP INFO messages). The first one
should be default, maybe if it doesn't work for you, you can try
disabling it by unchecking the option in Configuration form under
Audio, search for "telephone-event/8000". When you uncheck it you will
use the one with sip info messages.

Cheers
damencho

Thanks,

--

Daniel Castro

Software QA Engineer
Unified Communications Business Unit
danicast@cisco.com
Phone: +353 91 38 4778
Mobile: +353 83 318 2058

Cisco Systems Internetworking (Ireland) Limited
Oranmore Business Park
Oranmore, Galway
Ireland
Cisco.com - http://www.cisco.com/global/UK/

Cisco Systems Internetworking (Ireland) Limited a private limited
company
registered in Ireland under company number 314989 with its registered
office
at Block 6, Eastpoint Business Park, Dublin 3, Ireland

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

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

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail:
users-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


#14

Hi Emil,

I wasn't expecting a fix so quick, this is excellent!

I tested it with our MP and it is working fine now.

Thank you very much,
Daniel.

···

On 06/08/10 22:02, Emil Ivov wrote:

Hey Daniel,

Could you please try the latest build (2858) and see whether that's
working better?

As mentioned previously, adding the possibility for a stream to use
different payload type numbers, for the same payload, when sending and
receiving, is a too much of a hassle.

Instead, we've implemented the possibility to assign "preferred" dynamic
payload type numbers to media formats. This way, whenever we try to
allocate a dynamic payload type to a format, we'll first try that number.

I've seen 101 used for telephone-event in various situations so we've
decided to hard code it as preferred for the corresponding media format.
At some point we may also add the possibility to change this from the
user interface but this didn't seem like something particularly urgent
at this point.

Please, let us know how this works out for you.

Cheers,
Emil

На 06.08.10 17:45, Daniel Castro написа:

  Hi Emil,

Thanks for the follow up. Raised bug 848
<https://sip-communicator.dev.java.net/issues/show_bug.cgi?id=848>.
Didn't add much detail to the bug as it's all on this thread, let me
know if you need me to add anything else to the report.

Thanks,
Daniel.

On 06/08/10 15:46, Emil Ivov wrote:

Hey Daniel,

На 06.08.10 16:25, Daniel Castro написа:

  Hi Emil,

I talked to the developers and this is what they replied:

RFC3264 permits the use of asymmetric payload type. The paragraph they
are quoting applies to the offerer MUST not change the offer once
extended. But the answer may have different value. No one can restrict
the answer value.

Quoting RFC3264 :
“For sendrecv RTP streams, the payload type numbers indicate the value
of the payload type field the offerer expects to receive, and would
prefer to send. However, for sendonly and sendrecv streams, the answer
might indicate different payload type numbers for the same codecs, in
which case, the offerer MUST send with the payload type numbers from the
answer.”

Ah darn, so much for our beautiful PT negotiation code :). Anyways, this
is indeed a valid point so we'll need to address it. Could you please
file an issue in our tracker?

Is it possible for me to change the payload value to 101 somehow as a
workaround?

Any plans to let users control this? For example, Twinkle provides the
following in the GUI:

We'll think about it. Ideally I'd prefer us to simply respect the RFC.
However, enabling our streams to send media with one payload type number
and receive it with a different one might turn out to be quite a hassle,
so we might indeed go for that kind of a work around.

Thanks for the suggestion!

Emil

I don't think I can persuade for a fix/change in MP... can't provide a
business case at this stage that will justify the work.

Regards,
Daniel.

On 05/08/10 10:23, Emil Ivov wrote:

Hey all,

I guess this is indeed the most plausible explanation.

According to RFC 3264:

    in the case of RTP, the mapping from a particular dynamic payload type
    number to a particular codec within that media stream MUST NOT change
    for the duration of a session. For example, if A generates an offer
    with G.711 assigned to dynamic payload type number 46, payload type
    number 46 MUST refer to G.711 from that point forward in any offers
    or answers for that media stream within the session. However, it is
    acceptable for multiple payload type numbers to be mapped to the same
    codec, so that an updated offer could also use payload type number 72
    for G.711.

So basically, it is wrong for MeetingPlace to be trying to change our
RTP payload mapping from 100 to 101. Besides, in the exchange that we
are seeing here MeetingPlace is actually trying to redefine the payload
type number for both telephone-event, that we declare as 100, and H.264,
that we declare as 101 (naughty, naughty! :slight_smile: ).

Daniel, do you thing this is something that could be repaired in
MeetingPlace?

Emil

На 05.08.10 10:11, Damian Minkov написа:

Hi,

I was looking at the dumps. The good dump is using g722 and as I not
see any dtmf (vie sip info or vie rtp dtmf rfc2833) I suppose there
are send like tones in the audio(inband).
About the bad dump, I see there the dtmfs and wireshark successfully
recognize them as rfc2833. But what I notice: we are invited and we
respond with RINGING, TRYING, OK and in the OK we offer the dtmf as
"Media Attribute (a): rtpmap:100 telephone-event/8000". Later in the
ACK of our OK we receive "Media Attribute (a):
rtpmap:101 telephone-event/8000" and at the end we send the dtmf
events with payload 100 (as in our offer). So here I'm not sure which
is the correct behaviour, do we have to send the dtmfs with payload
101, or the other party must accept our offer and receive them as 100
not as 101.

Regards
damencho

On Wed, Aug 4, 2010 at 6:43 PM, Daniel Castro<danicast@cisco.com> wrote:

  Hi Emil,

Here are the two wireshark dumps. Please let me know if there's anything
else I can do.

Regards,
Daniel.

On 03/08/10 19:28, Emil Ivov wrote:

На 03.08.10 17:24, Daniel Castro написа:

   Hi Emil,

No trouble at all. I'll try to get this done before the end of the week.

Great!

What's the process? Do you have a bug tracking system? Should I open a
bug and attach those logs to it? Please advise.

We generally open bugs once they are confirmed as such and I am thinking
that in this case the issue might be with MeetingPlace. Therefore, could
you please send the traces here?

Cheers,
Emil

Thanks,
Daniel.

On 03/08/10 13:06, Emil Ivov wrote:

Hey Daniel

На 03.08.10 12:17, Daniel Castro написа:

I checked our documentation and the following tone formats should be
detected:
- In band audio tones (as defined in ITU-T Q.23, Q.24 (AT&T) standard)
- RFC 2833

That's the kind you'd be getting from SIP Communicator.

Our VoiceMail server is picking up the tones sent but the MeetingPlace
isn't for some reason. Does this ring any bells?

Sounds strange. Would it be too much trouble to ask you for a Wireshark
dump that contains DTMF tones sent from an application that works with
your MeetingPlace, as well as another one that shows those coming out of
SC when you are testing it?

Cheers,
Emil

Any help or pointers appreciated.

Regards,
--

Daniel Castro

Software QA Engineer
Unified Communications Business Unit
danicast@cisco.com
Phone: +353 91 38 4778
Mobile: +353 83 318 2058

Cisco Systems Internetworking (Ireland) Limited
Oranmore Business Park
Oranmore, Galway
Ireland
Cisco.com - http://www.cisco.com/global/UK/

Cisco Systems Internetworking (Ireland) Limited a private limited
company registered in Ireland under company number 314989 with its
registered office at Block 6, Eastpoint Business Park, Dublin 3, Ireland

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

-------- Original Message --------
Subject: Re: [sip-comm] DTMP tones supported?
Date: Thu, 29 Jul 2010 21:29:50 +0300
From: Damian Minkov<damencho@sip-communicator.org>
Reply-To: users@sip-communicator.dev.java.net
To: users@sip-communicator.dev.java.net

Hi Daniel,

On Thu, Jul 29, 2010 at 8:18 PM, Daniel Castro<danicast@cisco.com> >>>>>>>>>>> wrote:

   Hi,

I'm now to sip-communicator and new to this list. Excellent
application btw!

Thanks for the kind words.

I was just testing it and tried to join a meeting that requires me to
send
DTMF codes, but apparently sip-communicator it's not sending them.
Does anyone know if this is supported or if this is a known issue?

Currently we support two type of DTMFs:- rfc4733(which is compatible
with rfc2833) and sending using SIP (SIP INFO messages). The first one
should be default, maybe if it doesn't work for you, you can try
disabling it by unchecking the option in Configuration form under
Audio, search for "telephone-event/8000". When you uncheck it you will
use the one with sip info messages.

Cheers
damencho

Thanks,

--

Daniel Castro

Software QA Engineer
Unified Communications Business Unit
danicast@cisco.com
Phone: +353 91 38 4778
Mobile: +353 83 318 2058

Cisco Systems Internetworking (Ireland) Limited
Oranmore Business Park
Oranmore, Galway
Ireland
Cisco.com - http://www.cisco.com/global/UK/

Cisco Systems Internetworking (Ireland) Limited a private limited
company
registered in Ireland under company number 314989 with its registered
office
at Block 6, Eastpoint Business Park, Dublin 3, Ireland

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

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

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail:
users-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