[Freeswitch-users] Hangup causes
anthony.minessale at gmail.com
Wed Jul 24 22:43:34 MSD 2013
Its because you continued in the dialplan after the attempted bridge and
hungup with normal clearing by reaching the final app in the dialplan
you would actually have to explicitly execute
<action application="hangup" data="hangup_cause"/>
or set continue_on_fail=false before calling bridge.
On Wed, Jul 24, 2013 at 1:19 PM, Muhammad Naseer Bhatti
<nbhatti at gmail.com>wrote:
> I think 480 is because as mentioned in the wiki "Unspecified causes codes
> (no value in the "SIP Equiv." column in the table) are translated to SIP
> "480 Temporarily Unavailable" by FreeSwitch." But why in this case both
> Q.850 and SIP Equiv cause not matching?
> Muhammad Naseer Bhatti
> Steven Ayre wrote:
> Missed you'd included the logs ;)
> As suspected, the 480 contains 16 so that's where normal clearing comes
> 480 temporary failure is the SIP cause
> 16 Normal Clearing is the ISDN Q850 one
> Internally FS will use ISDN causes and map protocol specific ones between
> them (which isn't 1:1), Reason lets the endpoint override that mapping
> because its already providing the exact one
> On Wednesday, July 24, 2013, Steven Ayre wrote:
>> 16 is normal clearing - they are the q850 names for the same thing.
>> Why that's being done for 480 is another question - seeing the full call
>> context and any Reason headers might shed might on that
>> 480 maps to 41 not 16 iirc, but would be overridden by a Reason header or
>> if something else was going on on the call such as calling the hangup after
>> the bridge
>> On Wednesday, July 24, 2013, Muhammad Naseer Bhatti wrote:
>>> Got a little confusion here.
>>> FreeSWITCH log: http://pastebin.freeswitch.org/21226
>>> SIP trace: http://pastebin.freeswitch.org/21227
>>> Both were taken once after each other but other than the timing,
>>> everything else remains the same.
>>> This is a vanilla install for FreeSWITCH Version
>>> 1.5.5b+git~20130724T035836Z~3ae87091e1 (git 3ae8709 2013-07-24 03:58:36Z).
>>> Just dialing a non existent number (98871002) from a registered user 1001.
>>> The hangup cause returned by the switch shows
>>> mod_sofia.c:463 Channel sofia/internal/1001 at 10.211.55.3:50601 hanging
>>> up, cause: NORMAL_CLEARING
>>> However the SIP capture shows SIP/2.0 480 Temporarily Unavailable. This
>>> 480 is also showing by the switch mod_sofia.c:597 Responding to INVITE
>>> with: 480. I know the mapping is done by FreeSWITCH. In this case why
>>> 480, returned Normal Temporary Failure while the switch shows
>>> NORMAL_CLEARING? Is this because Q.850 returned is 16 and FreeSWITCH
>>> mapping for 16 is NORMAL_CLEARING?
>>> Or is there something I am missing.
>>> Muhammad Naseer Bhatti
> Professional FreeSWITCH Consulting Services:consulting at freeswitch.orghttp://www.freeswitchsolutions.com
> FreeSWITCH-powered IP PBX: The CudaTel Communication Server
> Official FreeSWITCH Siteshttp://www.freeswitch.orghttp://wiki.freeswitch.orghttp://www.cluecon.com
> FreeSWITCH-users mailing listFreeSWITCH-users at lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> Official FreeSWITCH Sites
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
Anthony Minessale II
MSN:anthony_minessale at hotmail.com
GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference
sip:888 at conference.freeswitch.org
googletalk:conf+888 at conference.freeswitch.org
-------------- next part --------------
An HTML attachment was scrubbed...
Join us at ClueCon 2011 Aug 9-11, 2011
More information about the FreeSWITCH-users