<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman, new york, times, serif;font-size:12pt"><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;">Ah jeez. All I wanted to do was connect to a carrier and then perform fail over logic based on their SIP response.<br>Not supposed to be difficult. This is what Asterisk is supposed to be good at.<br>We have a SIP module, why not have SIP responses available to the module.<br><br>Now, I have to look at the lossy HANGUPCAUSE variable and make a best guess.<br>Not an ideal situation.<br><br>We're trying to improve the ASR's we get from providers. They are low, and often they fail calls for no particular reason. They all do it, even the big ones like Verizon. Checking their responses for purpose of trying another carrier on the fly, and reporting is pretty critical.<br><br>Doug.<br><br><br><div style="font-family:
times new roman,new york,times,serif; font-size: 12pt;">----- Original Message ----<br>From: Raj Jain <rj2807@gmail.com><br>To: Asterisk Users Mailing List - Non-Commercial Discussion <asterisk-users@lists.digium.com><br>Sent: Saturday, October 27, 2007 11:29:21 AM<br>Subject: Re: [asterisk-users] Getting SIP Response Code from HANGUPCAUSE<br><br>
> > The only place where it is reasonable to customize is in the <br>> > specification of the channel in the configuration file. <br>> That is where <br>> > you would customize, for example, whether DTMF is inband, <br>> SIP INFO, or <br>> > RFC 2833, as well as what codecs will be negotiated for that <br>> > particular user/peer.<br>> > <br>> <br>> But you already have the SIP_HEADER function, which is quite <br>> contradictory to what you say. This allows users who know <br>> what they are doing to examine headers directly. We use this <br>> a lot. What would be the harm in having a SIP_RESPONSE <br>> function or something alike? <br><br>I'd agree that SIP response code should be accessible from the dial
plan.<br>Knowing the exact SIP response code could be critical for making call<br>processing decisions. The conversion of SIP response codes to Q.931
codes<br>(HANGUPCAUSE) is just too lossy. Building a truly protocol agnostic
dial<br>plan API is a worthy goal. But, I think it is somewhat of an unsolvable<br>problem. The signaling protocols are very different and for various
reasons<br>people have always wanted access to native information elements carried
in<br>the protocol.<br><br>Perhaps, a very simple solution for this problem could be to support a<br>keyword such as "TOPLINE" in the SIP_HEADER function to fetch the
topmost<br>line in a SIP message. This will not only get the caller the response
code<br>for SIP response messages, but will also have the nice byproduct of
making<br>the Request-URI available if the message in question is a SIP request.<br><br>- Raj<br><br><br>_______________________________________________<br>--Bandwidth and Colocation Provided by <a href="http://www.api-digital.com--" target="_blank">http://www.api-digital.com--</a><br><br>asterisk-users mailing list<br>To UNSUBSCRIBE or update options visit:<br> <a href="http://lists.digium.com/mailman/listinfo/asterisk-users" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-users</a><br></div><br></div></div><br>__________________________________________________<br>Do You Yahoo!?<br>Tired of spam? Yahoo! Mail has the best spam protection around <br>http://mail.yahoo.com </body></html>