[Fwd: [Asterisk-Users] Having problems with RTP packets and H old]

Regovich, Timothy timothy_regovich at merck.com
Tue Feb 10 12:58:25 MST 2004


Can you send the sip debug messages along?  That would help.  I am
interested in what the original invites looked like dialog information) and
what the subsequent invite looks like.

-----Original Message-----
From: asterisk-users-admin at lists.digium.com
[mailto:asterisk-users-admin at lists.digium.com] On Behalf Of Clif Jones
Sent: Tuesday, February 10, 2004 2:16 PM
To: asterisk-users at lists.digium.com
Cc: asterisk-dev at lists.digium.com
Subject: Re: [Fwd: [Asterisk-Users] Having problems with RTP packets and H
old]


Good question.  If you look at my original post, you will see that this 
problem was discovered after
this "feature" was evidently added to our AudioCodes gateway GA 
firmware.  The beta code didn't
do this.  They are probably trying to solve the problem of detecting 
dropped calls from the IP side
but if this "feature" is not selectable you run into problems like 
this.  I'm actually beating them up over
this but I have not been impressed with their support as a company.  I 
have still failed to get DTMF
bridging via RFC2833 working 100%.  If anyone has had success with 
Audiocodes FXO SIP gateways
and Asterisk, I would like to know the magic formula that makes all this 
work. :)

Regovich, Timothy wrote:

>Why does the FXO gateway treat a lack of RTP packets as a dropped call (and
>what heuristic does it use to determine?)
>Until the SIP UA sends an actual BYE message, the Dialog should still be
>considered active, regardless of the RTP that may or may not be happening.
>
>
>
>-----Original Message-----
>From: asterisk-users-admin at lists.digium.com
>[mailto:asterisk-users-admin at lists.digium.com] On Behalf Of Clif Jones
>Sent: Tuesday, February 10, 2004 1:33 PM
>To: asterisk-dev at lists.digium.com; asterisk users
>Subject: [Fwd: [Asterisk-Users] Having problems with RTP packets and Hold]
>
>
>If anyone is familiar with the SIP SDP handling routines I would appreciate
>some
>
>insight.  The following problem that I found using Asterisk appears to be
>improper
>
>handling of a call put on hold when there is no music on hold:
>
>[FXO gateway]                         [Asterisk]
>[IP phone]
>
>    |-------[INVITE s/SDP]---------------->|-------[INVITE
>s/SDP]---------------->|
>    |                                      |
>|
>    |<--------[180 Ringing]----------------|<--------[180
>Ringing]----------------|
>    |                                      |
>|
>    |<----[183 Session Progress]-----------|<-----------[200
>OK/SDP]--------------|
>    |                                      |
>|
>    |<--------[200
>OK/SDP]-----------------|------------[ACK]-------------------->|
>    |                                      |<=========== RTP
>====================>|
>    |------------[ACK]-------------------->|
>|
>    |<=========== RTP ====================>|
>|
>
>                                                 {IP phone puts caller on
>hold}
>
>    |                                      |<-----[INVITE/held
>SDP]---------------|
>    |                                      |
>|
>    |                                      |-----------[200
>OK/SDP]-------------->|
>    |                                      |
>|
>    |
>|<------------[ACK]--------------------|
>    |============ RTP (one-way)===========>|
>|
>    |                                      |
>|
>    |----------[BYE]---------------------->|
>|
>    |                                      |
>|
>    |<------------[200 OK]-----------------|
>|
>
>When the IP phone puts the gateway on hold, Asterisk gets the re-INVITE
with
>held
>media but Asterisk doesn't re-INVITE the gateway.  The RTP traffic to the
>gateway
>stops so the gateway handles the condition as a lost connection.  Shouldn't
>asterisk
>be forwarding the re-INVITE to the gateway unless MOH is enabled?
>
>
>
>
>---------------------------------------------------------------------------
---
>Notice:  This e-mail message, together with any attachments, contains
>information of Merck & Co., Inc. (One Merck Drive, Whitehouse Station, New
>Jersey, USA 08889), and/or its affiliates (which may be known outside the
>United States as Merck Frosst, Merck Sharp & Dohme or MSD and in Japan, as
>Banyu) that may be confidential, proprietary copyrighted and/or legally
>privileged. It is intended solely for the use of the individual or entity
>named on this message.  If you are not the intended recipient, and have
>received this message in error, please notify us immediately by reply
e-mail
>and then delete it from your system.
>---------------------------------------------------------------------------
---
>_______________________________________________
>Asterisk-Users mailing list
>Asterisk-Users at lists.digium.com
>http://lists.digium.com/mailman/listinfo/asterisk-users
>To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-users
>
>  
>
_______________________________________________
Asterisk-Users mailing list
Asterisk-Users at lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-users
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users



------------------------------------------------------------------------------
Notice:  This e-mail message, together with any attachments, contains information of Merck & Co., Inc. (One Merck Drive, Whitehouse Station, New Jersey, USA 08889), and/or its affiliates (which may be known outside the United States as Merck Frosst, Merck Sharp & Dohme or MSD and in Japan, as Banyu) that may be confidential, proprietary copyrighted and/or legally privileged. It is intended solely for the use of the individual or entity named on this message.  If you are not the intended recipient, and have received this message in error, please notify us immediately by reply e-mail and then delete it from your system.
------------------------------------------------------------------------------



More information about the asterisk-users mailing list