login | register
Fri 09 of May, 2008 [14:03 UTC]

voip-info.org

Search with Google
Search this site with Google. Results may not include recent changes.
 
Google Ads
Shoutbox
  • Nick Barnes, Fri 09 of May, 2008 [11:36 UTC]: Christopher - yesterday I tried an Asterisk install on a CentOS 5.1 box with stock GUI and it all worked fine. Sorry I can't help.
  • aero, Fri 09 of May, 2008 [08:20 UTC]: can someone help me out on this, i tried to play some sound files on my asterisk box and this is the error message i got. WARNING[4429]: format_wav.c:169 check_header: Unexpected freqency 22050 May 8 11:17:39 WARNING[4433]: codec_gsm.c:194 gsmtolin_fra
  • Christopher Faust, Thu 08 of May, 2008 [14:15 UTC]: I beleive that I may have to change something in the xserver configuration. Please advise
  • Christopher Faust, Thu 08 of May, 2008 [14:14 UTC]: Everything was perfect. In the bios I have increased the memory allocated Still receive input not supported on my display.
  • Christopher Faust, Thu 08 of May, 2008 [14:13 UTC]: This would not be my main box. I am doing some testing to see if I can install zaptel and asterisk 1.4 on a full centos 5.1 box with development software Its bizzare, because before I went through the asterisk and zaptel installation everything was perfe
  • Nick Barnes, Thu 08 of May, 2008 [13:44 UTC]: Christopher - I can't see any way in which an Asterisk installation would muck your GUI, but remember that it is advised not to use a GUI on an Asterisk box anyway.
  • Christopher Faust, Wed 07 of May, 2008 [15:28 UTC]: When I try to startx I ge input not supported. Though before installing asterisk I had no video issue to start the GUI
  • Christopher Faust, Wed 07 of May, 2008 [15:26 UTC]: Hi Nick, I got centos 5.1 and asterisk up But now I cannot start startx I have set the depth from 24 to 16 for the video i810 driver for the i845 on my netvista machine but I cannot start GNOME. Please advise
  • Nick Barnes, Wed 07 of May, 2008 [10:01 UTC]: Howard - You'll need to provide a lot more information if you really want help.
  • Nick Barnes, Wed 07 of May, 2008 [10:00 UTC]: Christopher - Search the Wiki and you'll find a page I wrote detailing exactly what you have to do for Asterisk 1.4 + CentOS 5.1.
Server Stats
  • Execution time: 0.18s
  • Memory usage: 2.18MB
  • Database queries: 29
  • GZIP: Disabled
  • Server load: 1.36

SIP method prack

PRACK is defined in RFC 3262: Reliability of Provisional Responses in the Session Initiation Protocol (SIP)


The PRACK request plays the same role as ACK, but for provisional responses. There is an important difference, however. PRACK is a normal SIP message, like BYE. As such, its own reliability is ensured hop-by-hop through each stateful proxy. Also like BYE, but unlike ACK, PRACK has its own response. If this were not the case, the PRACK message could not traverse proxy servers compliant to RFC 2543.





Numerous implementation problems seen in the field
A SIP UA indicates support for this standard by including a "Supported: 100rel" or "Required: 100rel" as a SIP header. Several major SIP stacks — including the one in IOS and on PolyCom SoundPoint IP 500 phones — have shown problems with it, at least in previous versions. The SIP headers claim to support it or require it, but when you send them a non-100 1xx message, they don't PRACK it.




Created by oej, Last modification by markrlindsey on Thu 28 of Apr, 2005 [02:07 UTC]

Comments Filter

Cisco IOS issues with PRACK and Reliable1xx SOLUTION

by Travis May on Friday 30 of June, 2006 [10:13:50 UTC]
Inbound SIP calls to a Cisco AS5x00 disconnecting with SIP message "CCSIP-SPI-CONTROL: act_sentrel1xx_wait_prack" initiating the disconnect. Inbound calls would properly connect if CONNECT within 20 seconds. However, if the called party did not answer within 20 seconds, IOS SIP stack would disconnect. Inbound INVITE header contained "Supported: 100rel". IOS would continually send "183 Session Progress" with "Require: 100rel" in the header for 20 seconds and then disconnect "act_sentrel1xx_wait_prack" after 20 seconds. I believe this would have been a non-issue, however the sending peer was using NAT and the PRACK requests were either not being received by the peer or the PRACK responses were not reaching the SIP stack of the Cisco IOS (due to NAT).<BR>
<BR>
Lazy solution: Disable reliable prack.<BR>
voice service voip<BR>
sip<BR>
 rel1xx disable<BR>
<BR>
Robust solution: Fix the NAT traversal issues<BR>
<BR>
Travis May, CCNP<BR>
VoIP Engineer<BR>
<BR>
<a href="http://www.TollFreeForwarding.com">www.TollFreeForwarding.com</a><BR>

Please update this page with new information, just login and click on the "Edit" or "Add Comment" button above. Get a free login here: Register Thanks! - support@voip-info.org

Page Changes | Comments

Sponsored by:

Terms of Service Privacy Policy
© 2003-2008 VOIP-Info.org LLC

Powered by bitweaver