Ovidiu,

Ok altered the RTP Packet size in the SPA and the RTP Events have changed, but not quite the expected results.

RTP EV Payload type=RTP Event, DTMF Five 5                 Duration: 320
RTP EV Payload type=RTP Event, DTMF Five 5                 Duration: 320
RTP EV Payload type=RTP Event, DTMF Five 5                 Duration: 320
RTP EV Payload type=RTP Event, DTMF Five 5                 Duration: 480
RTP EV Payload type=RTP Event, DTMF Five 5                 Duration: 640
RTP EV Payload type=RTP Event, DTMF Five 5 (end)        Duration: 800
RTP EV Payload type=RTP Event, DTMF Zero 0                 Duration: 320
RTP EV Payload type=RTP Event, DTMF Zero 0                 Duration: 320
RTP EV Payload type=RTP Event, DTMF Zero 0                 Duration: 320
RTP EV Payload type=RTP Event, DTMF Zero 0                 Duration: 480
RTP EV Payload type=RTP Event, DTMF Zero 0                 Duration: 640
RTP EV Payload type=RTP Event, DTMF Zero 0 (end)        Duration: 720
RTP EV Payload type=RTP Event, DTMF Zero 0 (end)        Duration: 720
RTP EV Payload type=RTP Event, DTMF Zero 0 (end)        Duration: 720
RTP EV Payload type=RTP Event, DTMF Eight 8                Duration: 320
RTP EV Payload type=RTP Event, DTMF Eight 8                Duration: 320
RTP EV Payload type=RTP Event, DTMF Eight 8                Duration: 320
RTP EV Payload type=RTP Event, DTMF Eight 8                Duration: 480
RTP EV Payload type=RTP Event, DTMF Eight 8                Duration: 640
RTP EV Payload type=RTP Event, DTMF Eight 8 (end)       Duration: 800

It seems to be working more consistently, but I'm wondering what the difference is, how to control it and the impact. I see the Polycom starts with a duration of 160 and steps up by 160 to 800 or 960 before sending the end packet, where the Sipura doesn't send a 160 but two 320's then steps up to just 640 before sending the end packet. The other difference is the number and duration of the end packets.

Any explanation would be appreciated, even if it works I'd like to really understand why. Also when different the why how that they interoperate.

Again!
Thanks,

Mike

Ovidiu Sas wrote:
It seems that the SPA is using 30ms packetization.  Can you change
that to be 20?
Sometimes asterisk seems to have issues with packetizations other than 20ms.


Regards,
Ovidiu Sas

On 7/19/07, Mike Ashton <[EMAIL PROTECTED]> wrote:

 Ovidiu,

Thanks for the pointer. I fired up wireshark and I can see both the Polycom
& SPA sending the RTP Event packets, but the number and duration are
different (see below). So I guess the question is how to get the SPA to
behave?

 I've tried adjusting the DTMF Playback length & level values, but that
seems to have no effect on the ETP Event packets, same number and durations.
Below is a brief summary of the two, any ideas would be appreciated.

 Mike

 Polycom:
RTP EV Payload type=RTP Event, DTMF Five 5 Duration: 160 RTP EV Payload type=RTP Event, DTMF Five 5 Duration: 320 RTP EV Payload type=RTP Event, DTMF Five 5 Duration: 480 RTP EV Payload type=RTP Event, DTMF Five 5 Duration: 640 RTP EV Payload type=RTP Event, DTMF Five 5 Duration: 800 RTP EV Payload type=RTP Event, DTMF Five 5 Duration: 960
 RTP EV Payload type=RTP Event, DTMF Five 5 (end)        Duration: 1440
 RTP EV Payload type=RTP Event, DTMF Five 5 (end)        Duration: 1440
 RTP EV Payload type=RTP Event, DTMF Five 5 (end)        Duration: 1440
RTP EV Payload type=RTP Event, DTMF Zero 0 Duration: 160 RTP EV Payload type=RTP Event, DTMF Zero 0 Duration: 320 RTP EV Payload type=RTP Event, DTMF Zero 0 Duration: 480 RTP EV Payload type=RTP Event, DTMF Zero 0 Duration: 640 RTP EV Payload type=RTP Event, DTMF Zero 0 Duration: 800
 RTP EV Payload type=RTP Event, DTMF Zero 0 (end)        Duration: 1200
 RTP EV Payload type=RTP Event, DTMF Zero 0 (end)        Duration: 1200
 RTP EV Payload type=RTP Event, DTMF Zero 0 (end)        Duration: 1200
RTP EV Payload type=RTP Event, DTMF Eight 8 Duration: 160 RTP EV Payload type=RTP Event, DTMF Eight 8 Duration: 320 RTP EV Payload type=RTP Event, DTMF Eight 8 Duration: 480 RTP EV Payload type=RTP Event, DTMF Eight 8 Duration: 640 RTP EV Payload type=RTP Event, DTMF Eight 8 Duration: 800 RTP EV Payload type=RTP Event, DTMF Eight 8 Duration: 960
 RTP EV Payload type=RTP Event, DTMF Eight 8 (end)       Duration: 1440
 RTP EV Payload type=RTP Event, DTMF Eight 8 (end)       Duration: 1440
 RTP EV Payload type=RTP Event, DTMF Eight 8 (end)       Duration: 1440

 SPA2002:
RTP EV Payload type=RTP Event, DTMF Five 5 Duration: 400 RTP EV Payload type=RTP Event, DTMF Five 5 Duration: 400 RTP EV Payload type=RTP Event, DTMF Five 5 Duration: 400 RTP EV Payload type=RTP Event, DTMF Five 5 Duration: 640
 RTP EV Payload type=RTP Event, DTMF Five 5 (end)        Duration: 720
 RTP EV Payload type=RTP Event, DTMF Five 5 (end)        Duration: 720
 RTP EV Payload type=RTP Event, DTMF Five 5 (end)        Duration: 720
RTP EV Payload type=RTP Event, DTMF Zero 0 Duration: 400 RTP EV Payload type=RTP Event, DTMF Zero 0 Duration: 400 RTP EV Payload type=RTP Event, DTMF Zero 0 Duration: 400 RTP EV Payload type=RTP Event, DTMF Zero 0 Duration: 640
 RTP EV Payload type=RTP Event, DTMF Zero 0 (end)        Duration: 880
RTP EV Payload type=RTP Event, DTMF Eight 8 Duration: 400 RTP EV Payload type=RTP Event, DTMF Eight 8 Duration: 400 RTP EV Payload type=RTP Event, DTMF Eight 8 Duration: 400 RTP EV Payload type=RTP Event, DTMF Eight 8 Duration: 640 RTP EV Payload type=RTP Event, DTMF Eight 8 Duration: 880
 RTP EV Payload type=RTP Event, DTMF Eight 8 (end)       Duration: 960
 RTP EV Payload type=RTP Event, DTMF Eight 8 (end)       Duration: 960
 RTP EV Payload type=RTP Event, DTMF Eight 8 (end)       Duration: 960

 Ovidiu Sas wrote:
Hi Mike,


 100rel has nothing to do with DTMF.  100rel stands for "Reliability of
 Provisional Responses in the Session Initiation Protocol (SIP)"
 see: http://www.ietf.org/rfc/rfc3262.txt

 rfc2833 is the right way of sending DTMF digits over rtp and that
 option seems to be enabled for both phones.

 Try to capture the rtp traffic for a problematic call and open it with
 wireshark.  Wireshark will display all the digits that are sent
 between phones.  By analyzing the rtp traffic you will be able to
 debug your problem.


 Regards,
 Ovidiu Sas

 On 7/19/07, Mike Ashton <[EMAIL PROTECTED]> wrote:


  Hi all,

I'm having some strange DTMF behavior and wondering if someone can shed
 some light on it. I'm dialing out and sending DTMF after the call is
established, and this usually works just find. But occasionally it fails
 from a sipura 2002 and PAP2, but works from my Polycom 501.

Now looking at the channels when set up the only difference I can see, is
 that the Polycom has a SIP Option set.

  Polycom:
    Format                  ulaw
    DTMF Mode:              rfc2833
    SIP Options:            100rel

  Spa
    Format                  ulaw
    DTMF Mode:              rfc2833
    SIP Options:            (none)

Can some one explain what the 100rel is and how do I get the SPA to invoke
 it if possible. I Googled this and came up empty.

  Thanks,

  Mike

  --
 Mike Ashton

 Quality Track Intl

 Ph: 647-722-2092 x 301
 Cell: 416-527-4995
 Fax: 416-352-6043

 QTI CONFIDENTIAL AND PROPRIETARY INFORMATION

The contents of this material are confidential and proprietary to Quality
 Track International, Inc.
 and may not be reproduced, disclosed, distributed or used without the
 express permission of an authorized representative of QTI.
Use for any purpose or in any manner other than that expressly authorized
is
 prohibited.
If you have received this communication in error, please immediately delete
 it and all copies, and promptly notify the sender.



---------------------------------------------------------------------
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]





 --
Mike Ashton

Quality Track Intl

Ph: 647-722-2092 x 301
Cell: 416-527-4995
Fax: 416-352-6043

QTI CONFIDENTIAL AND PROPRIETARY INFORMATION

The contents of this material are confidential and proprietary to Quality
Track International, Inc.
and may not be reproduced, disclosed, distributed or used without the
express permission of an authorized representative of QTI.
Use for any purpose or in any manner other than that expressly authorized is
prohibited.
If you have received this communication in error, please immediately delete
it and all copies, and promptly notify the sender.



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
Mike Ashton

Quality Track Intl

Ph:     647-722-2092 x 301
Cell:   416-527-4995
Fax:    416-352-6043

QTI CONFIDENTIAL AND PROPRIETARY INFORMATION

The contents of this material are confidential and proprietary to Quality Track 
 International, Inc.
and may not be reproduced, disclosed, distributed or used without the express 
permission of an authorized representative of QTI.
Use for any purpose or in any manner other than that expressly authorized is 
prohibited.
If you have received this communication in error, please immediately delete it 
and all copies, and promptly notify the sender.



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to