VoIP Mailing List Archives

[klaus.teller at gmx.net]

Hi Team,

I'm still in need of a way to reject a call without answering it. I very much appreciate your help.

Klaus.
--
GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate und Telefonanschluss
für nur 17,95 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02

_______________________________________________
Freeswitch-users mailing list
Freeswitch-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org

[intralanman at freeswi...]

Klaus Teller wrote:

[brian at freeswitch.org]

respond will do exactly that... try just hangup

/b

On Jun 11, 2009, at 9:19 AM, Klaus Teller wrote:

[klaus.teller at gmx.net]

Hi Folks,

Here is what i'm observing. When i connect with Xlite (registered device) and call the 9444 extension (see below), Freeswitch does hangup as i would like it to.

But when i call via gafachi, something weird happens. What i can see is that Freeswitch sends a hangup signal (service temporarily not available) to Gafachi, but the guys keep sending back the very same call.


It looks to me like a Gafachi issue. But can anything else be done on the Freeswitch side?

I'm attaching the logs for the gafachi call this. All you see in there is just one single call. You will see that a new channel is created more than once.

Any thought?

Klaus.

The gafachi respond extension (under conf/dialplan/public/reject.xml):
<include>
<extension name="reject-test">
<condition field="destination_number" expression="^866.*$">
<action application="respond" data="503"/>
</condition>
</extension>
</include>


The gafachi profile (under conf/sip_profiles/external/gafachi.xml):
<include>
<gateway name="sip.gafachi.com">
<param name="username" value="authenticationid"/>
<param name="password" value="secret"/>
<param name="register" value="true"/>
</gateway>
</include>

The Xlite respond test extension (in default.xml):
<extension name="reject-test">
<condition field="destination_number" expression="^9444$">
<action application="respond"/>
</condition>
</extension>


Any idea?

[krice at freeswitch.org]

Hah they are just retrying the call to see if they get a different answer
the 2nd and 3rd time around... This is common unfortunately since 503 in the
VoIP world is typically interpreted by the PSTN world as a "Temp congestion"
(and rightly so) so they will retry and not fail the call... You can try
responding w/ 486 Busy if you know the call doesn't need to fail somewhere
else...

[klaus.teller at gmx.net]

Excellent! Thank you everybody. Response 486 did the trick.

Klaus.
-------- Original-Nachricht --------

[freeswitch-users-list ...]

Although a little overkill, RFC3398 also describes some desirable interop
behavior between ISUP, ISDN and SIP.

(From "7.2.4.1 ISDN Cause Code to Status Code Mapping")

[...]
ISUP Cause value SIP response
---------------- ------------
1 unallocated number 404 Not Found
2 no route to network 404 Not found
3 no route to destination 404 Not found
16 normal call clearing --- (*)
17 user busy 486 Busy here
18 no user responding 408 Request Timeout
19 no answer from the user 480 Temporarily unavailable
20 subscriber absent 480 Temporarily unavailable
21 call rejected 403 Forbidden (+)
22 number changed (w/o diagnostic) 410 Gone
22 number changed (w/ diagnostic) 301 Moved Permanently
23 redirection to new destination 410 Gone
26 non-selected user clearing 404 Not Found (=)
27 destination out of order 502 Bad Gateway
28 address incomplete 484 Address incomplete
29 facility rejected 501 Not implemented
31 normal unspecified 480 Temporarily unavailable

[...]
Resource unavailable

This kind of cause value indicates a temporary failure. A 'Retry-After'
header MAY be added to the response if appropriate.

ISUP Cause value SIP response
---------------- ------------
34 no circuit available 503 Service unavailable
38 network out of order 503 Service unavailable
41 temporary failure 503 Service unavailable
42 switching equipment congestion 503 Service unavailable
47 resource unavailable 503 Service unavailable


----- Original Message -----
From: "Ken Rice" <krice@freeswitch.org>
To: <freeswitch-users@lists.freeswitch.org>
Sent: Thursday, June 11, 2009 12:31 PM
Subject: Re: [Freeswitch-users] Rejecting calls without answering


Hah they are just retrying the call to see if they get a different answer
the 2nd and 3rd time around... This is common unfortunately since 503 in the
VoIP world is typically interpreted by the PSTN world as a "Temp congestion"
(and rightly so) so they will retry and not fail the call... You can try
responding w/ 486 Busy if you know the call doesn't need to fail somewhere
else...