VoIP Mailing List Archives

[wchao at yahoo.com]

Hangups do not work for me under certain circumstances. Here is the
background information:

* Our carrier uses a Metaswitch server with Acme Packet in front as a
proxy/SBC. Only the Acme Packet machine is publicly visible
(64.115.128.6).

* Our Freeswitch server is at 216.57.23.143.

* For calls originating from Freeswitch and terminating on Metaswitch
(216.57.23.143 -> 64.115.128.6), Freeswitch authenticates with
Metaswitch and everything works hunky-dorey. Either side can hang up and
the other side will automatically hang up without requiring a manual
hang-up.

Now the problem:

For calls originating from Metaswitch to Freeswitch (64.115.128.6 ->
216.57.23.143), Metaswitch does not authenticate with Freeswitch.
Metaswitch also does not use the existing authenticated registration that
our Freeswitch server initiates with Metaswitch upon startup of
Freeswitch. Metaswitch just begins a new (unauthenticated) session and we
have configured Freeswitch to allow any inbound calls from 64.115.128.6
without requiring authentication.

We receive inbound calls (Metaswitch to Freeswitch, 64.115.128.6 ->
216.57.23.143) just fine. The phone rings and we can have a normal
conversation. If the caller (the endpoint attached to Metaswitch) hangs
up, both sides hang up. If I hang up (remember, I'm at the endpoint
attached to Freeswitch), the caller's line remains attached forever.

I have recorded a packet trace. Look at freeswitch_2.cap in the ZIP file,
and you want to graph the first call starting at 21.202 and ending 53.798.
If you go to time 53.087, you can see that my Freeswitch server sends a
BYE to Metaswitch. This is a result of me hanging up my phone. At time
53.089, you see Metaswitch responding with 401 Unauthorized. Later at time
53.777, you see a BYE from Metaswitch to Freeswitch, but you should ignore
this because that was a result of the caller (the guy hooked up to
Metaswitch) manually hanging up. If he had not hung up his phone, the BYE
from Metaswitch to Freeswitch would not have been issued and his phone
would just stay on the line forever. Also, when I hang up my phone, I see
the following at the Freeswitch console:

2008-10-29 23:03:28 [ERR] sofia_reg.c:1089
sofia_reg_handle_sip_r_challenge() No Matching gateway found

I presume that Freeswitch emits this error because it got the 401
Unauthorized from Metaswitch.

I also asked our carrier for a packet trace of a successful hangup on the
Aastra platform (the engineer at the carrier says it is an Asterisk
derivative -- I'm not sure about that). Look at
Aastra_authentication_test.cap in the ZIP file. Graph the first call
starting at 43.633 and ending 93.156. If you go to 93.118, you'll see that
the Aastra server sends a BYE. Just like our Freeswitch scenario,
Metaswitch sends back a 401 Unauthorized, but in response to the 401
Unauthorized, Aastra then sends back another BYE with the difference that
the second BYE is authenticated. Metaswitch gets the second BYE and
responds with 200 OK.

I am pretty sure that if Freeswitch were to send back a second BYE (but
with authentication), it would work fine. Now my question is how can I do
this? I am not sure if this divergence of behavior is caused by: (a) my
own error in configuring Freeswitch, (b) Metaswitch lacking standard SIP
support (maybe it's not supposed to send the 401 Unauthorized), or (c)
Freeswitch lacking standard SIP support (maybe it's supposed to send back
a second BYE with authentication automatically). I don't know the SIP
standards (or Freeswitch) well enough to know whether this problem is
caused by me or by a deficiency in one of the two products (Metaswitch or
Freeswitch).

Can you provide some pointers?

The ZIP file with the packet traces can be downloaded here:
http://216.57.23.143/hangup_problem.zip

_______________________________________________
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

[anthony.minessale at g...]

just setup a gateway in fs that has reg=false and the proper credentials to pass the challenge.


On Thu, Oct 30, 2008 at 2:49 PM, Wellie Chao <wchao@yahoo.com (wchao@yahoo.com)> wrote:

[wchao at yahoo.com]

Here is what I have:

<include>
<gateway name="broadview">
<param name="username" value="MY_USERNAME"/>
<param name="password" value="MY_PASSWORD"/>
<param name="realm" value="64.115.128.6"/>
<param name="proxy" value="64.115.128.6"/>
<param name="register" value="false"/>
</gateway>
</include>

Whether register is true or false doesn't seem to make a difference
(except that Freeswitch then comes up with broadview in NOREG state). On
calls from Metaswitch to Freeswitch, it's the same problem, and I get the
same message in the Freeswitch logs:

2008-10-30 17:39:04 [ERR] sofia_reg.c:1089
sofia_reg_handle_sip_r_challenge() No Matching gateway found

I presume this is the same thing with the 401 Unauthorized packet being
sent by Metaswitch in response to Freeswitch's BYE message. Note that the
call itself goes just fine. I pick up, both sides can hear each other.
Just the hangup gets messed up and for some reason Metaswitch expects an
authenticated BYE message even though the connection was not authenticated
in the beginning when Metaswitch initiated it. The packet trace shows this
and it's very odd.

Is that what you meant when you said set up a gateway in Freeswitch that
has reg=false and the proper credentials?

On Thu, 30 Oct 2008, Anthony Minessale wrote:

[brian at freeswitch.org]

Turn on the TPORT_LOG=1 ./freeswitch and let me see the challenge
packet.

/b

On Oct 30, 2008, at 4:45 PM, Wellie Chao wrote:

[anthony.minessale at g...]

make sure realm matches the realm in the challenge packet from the other device.

On Thu, Oct 30, 2008 at 5:11 PM, Brian West <brian@freeswitch.org (brian@freeswitch.org)> wrote:

[wchao at yahoo.com]

Here is the BYE from Freeswitch to Metaswitch:

send 683 bytes to udp/[64.115.128.6]:5060 at 00:44:46.607025:

------------------------------------------------------------------------
BYE sip:9172388084@64.115.128.6:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 216.57.23.143;rport;branch=z9hG4bKNa693jZ8SD54D
Max-Forwards: 70
From: <sip:2675379325@216.57.23.143>;tag=r4yBmtX3U0Hrr
To:
<sip:9172388084@64.115.128.6:5060;transport=udp>;tag=Broadview1+1+25f76f+cc3ba534
Call-ID: CEB9027F@Broadview1
CSeq: 106588607 BYE
Contact: <sip:mod_sofia@216.57.23.143:5060;transport=udp>
User-Agent: FreeSWITCH-mod_sofia/1.0.1-9171
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE,
NOTIFY, REFER, UPDATE, REGISTER, INFO, PUBLISH
Supported: 100rel, timer, precondition, path, replaces
Reason: Q.850;cause=16;text="NORMAL_CLEARING"
Content-Length: 0


------------------------------------------------------------------------

Metaswitch is not so happy with the BYE message:

recv 491 bytes from udp/[64.115.128.6]:5060 at 00:44:46.630445:

------------------------------------------------------------------------
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP
216.57.23.143;received=216.57.23.143;branch=z9hG4bKNa693jZ8SD54D;rport=5060
From: <sip:2675379325@216.57.23.143>;tag=r4yBmtX3U0Hrr
To:
<sip:9172388084@64.115.128.6:5060;transport=udp>;tag=Broadview1+1+25f76f+cc3ba534
Call-ID: CEB9027F@Broadview1
CSeq: 106588607 BYE
WWW-Authenticate: Digest
realm="SipLocal",nonce="3e952db60fb8",stale=false,algorithm=MD5,qop="auth"
Server: DC-SIP/2.0
Organization:
Supported: 100rel
Content-Length: 0


------------------------------------------------------------------------

Right after receiving the 401 Unauthorized message from Metaswitch,
Freeswitch emits the following error on the console:

2008-10-30 20:44:46 [ERR] sofia_reg.c:1089
sofia_reg_handle_sip_r_challenge() No Matching gateway found

At this point, the caller (the endpoint connected to Metaswitch) just
remains on the line, never having received the BYE.

Did you take a look at the packet traces I captured? The carrier
gave me a packet trace for an Aastra PBX/softswitch, and it had the same
interaction, but immediately upon receiving the 401 Unauthorized from
Metaswitch, the Aastra machine then sent a second BYE, this time with
authentication. Is there some way I can tell Freeswitch to do the same?

Regards,
Wellie

On Thu, 30 Oct 2008, Brian West wrote:

[wchao at yahoo.com]

If I change the realm, I will not be able to make outgoing calls because
the realm must be 64.115.128.6 in order to register with Metaswitch for
outbound calls.

Are you suggesting I create two gateway entries, one for outbound and one
for inbound? Will Freeswitch respond with an authenticated BYE message
even if the session was initiated in an authenticated fashion by
Metaswitch? It's a little frustrating because Metaswitch is initiating the
call to Freeswitch without authentication, yet it expects Freeswitch to
reply with an authenticated BYE message in order to end the call. It
really should be smart enough to realize that since it initiated the call
to a particular Freeswitch instance at A.B.C.D IP address, it should allow
unauthenticated BYE messages from that IP address.

On Thu, 30 Oct 2008, Anthony Minessale wrote:

[wchao at yahoo.com]

Just to correct an error, I asked below "Will Freeswitch respond with an
authenticated BYE message even if the session was initiated in an
authenticated fashion by Metaswitch?" and I meant "even if the session was
initiated in an UNauthenticated fashion".

Also, to expound on the problem, I don't see how changing the realm will
help because the problem is not that Freeswitch is sending the wrong
realm, but that Freeswitch is not responding with an authenticated BYE
message at all -- it's only sending an unauthenticated BYE message. The
realm, while possibly important later, assumes that Freeswitch is using
authentication in the BYE message it sends to Metaswitch. Right now it's
not. From an intuitive point of view, it makes sense: Freeswitch is
thinking, "well Metaswitch, you called me, why do I need to authenticate
myself to you". The Aastra softswitch (in the other packet trace in the
ZIP file I sent in a previous email to this list) deals with this by
sending an authenticated BYE when the unauthenticated BYE fails with 401
Unauthorized. Is there some way I can configure Freeswitch to do the same?

On Thu, 30 Oct 2008, Wellie Chao wrote:

[brian at freeswitch.org]

They really shouldn't be challenging the bye like that because not every device can answer the challenge properly. Either case it doesn't matter if you have a proper domain 206.57.23.143 in your user directory with the proper user and realm set to meet this challenge. We have a setting in FreeSWITCH to auth all packets and when we did that we found out that some devices just do not work properly when doing that. I need to see your original gateway XML. You can email it off list if you like and let me try to solve this.

/b

On Oct 30, 2008, at 7:52 PM, Wellie Chao wrote:

[anthony.minessale at g...]

See what they said in the challenge?

WWW-Authenticate: Digest
realm="SipLocal",nonce="3e952db60fb8",stale=false,algorithm=MD5,qop="auth"

Since this is a spontaneous challenge (which i think is somewhat silly since it lets you talk on the phone for 40
minutes then makes you authenticate to hangup but *shrug*) FS does not know which gateway to use for credentials.

The realm they sent was SipLocal so FS is looking in its configuration for a gateway with that name.
The 2nd thing it tries is the host from the To: header (64.115.128.6). if there was a gateway with either of those names,
it would find it.

So try naming your gateway SipLocal or 64.115.128.6
or you can try setting the variable sip_use_gateway=<whatever> on the channel which can give it a hint which
gateway to use.



On Thu, Oct 30, 2008 at 8:42 PM, Brian West <brian@freeswitch.org (brian@freeswitch.org)> wrote:

[wchao at yahoo.com]

Where do you recommend I put the sip_use_gateway=broadview action?

I have tried in the conf/dialplan/public.xml like so:

<extension name="public_did_broadview">
<condition field="destination_number"
expression="^(12675379324|2675379324|12675379325|2675379325)$">
<action application="set" data="sip_use_gateway=broadview"/>
<action application="transfer" data="$1 XML default"/>
</condition>
</extension>

I've also tried in conf/dialplan/extensions/7_inbound.xml (a file I
created that is pulled in via an include pre-processor directive):

<extension name="broadview_inbound_9325">
<condition field="destination_number"
expression="^12675379325|2675379325$">
<action application="set" data="sip_use_gateway=broadview"/>
<action application="transfer" data="1001"/>
</condition>
</extension>

I have a gateway named broadview in conf/sip_profiles/external. In both
cases, I still get the following error on the Freeswitch console:

2008-10-31 10:37:28 [ERR] sofia_reg.c:1089
sofia_reg_handle_sip_r_challenge() No Matching gateway found

On Fri, 31 Oct 2008, Anthony Minessale wrote:

[wchao at yahoo.com]

I tried the following in conf/dialplan/extensions/7_inbound.xml:

<extension name="broadview_inbound_9325">
<condition field="destination_number" expression="^12675379325|2675379325$">
<action application="export" data="sip_use_gateway=broadview"/>
<action application="transfer" data="1001"/>
</condition>
</extension>

Also tried the following in conf/dialplan/public.xml:

<extension name="public_did_broadview">
<condition field="destination_number" expression="^(12675379324|2675379324|12675379325|2675379325)$">
<action application="export" data="sip_use_gateway=broadview"/>
<action application="transfer" data="$1 XML default"/>
</condition>
</extension>

Neither helped. When you say add it to the dial string directly that calls
it, I'm not sure what you mean (I know the general format of
{var_name=var_value}, so that's not my question). Do you mean add it in
front of the 1001 as the target of the transfer?

By the way, hangup DOES work properly if I create another gateway and name
it 64.115.128.6. However, I'd love to get it working without having to
create a duplicate gateway with a non-intuitive name. It's definitely a
lot better than nothing to do it that way, but I'd prefer to have it work
with the sip_use_gateway scheme you mention. I'm assuming I'm just doing
something wrong with how sip_use_gateway should be specified in the XML
configuration files. Can you tell what I am doing wrong?

On Fri, 31 Oct 2008, Anthony Minessale wrote:

[anthony.minessale at g...]

Yes i mean add it to the dial string inside the {}
it only will work if the channel with the variable set is tied to the FS session obj.

sofia_reg.c 1122 is where it all happens
so if session is null there the var code won't work.

you can add some debug code there and try to figure out what's wrong.



On Fri, Oct 31, 2008 at 10:06 AM, Wellie Chao <wchao@yahoo.com (wchao@yahoo.com)> wrote:

[anthony.minessale at g...]

try using "export" instead of "set" or add it to the dial string directly that calls it

{sip_use_gateway=broadview}sofia/.......


On Fri, Oct 31, 2008 at 9:42 AM, Wellie Chao <wchao@yahoo.com (wchao@yahoo.com)> wrote:

[wchao at yahoo.com]

I added some debug code and determined that session is null in sofia_reg.c
in the sofia_reg_handle_sip_r_challenge function, which is called by
sofia_event_callback in sofia.c. I added further debug code and found that
sofia_event_callback only sets session if sofia_private->uuid exists. The
strange thing is that during the call setup for a call from Metaswitch to
Freeswitch (which is unauthenticated, remember), sofia_private->uuid
exists and is a valid call ID, and session is also set to a valid value,
but when I hang up from the Freeswitch side, sofia_private->uuid is null
in that particular call to sofia_event_callback (and thus session is
obviously left null). On the call setup, there are two legs (Metaswitch to
Freeswitch, then Freeswitch to the extension). The call hangup is being
performed by the extension. The session initiated by Metaswitch is
unauthenticated, as I mentioned.

I can look into this further, but I wanted to see if you had any quick
pointers before delving in more deeply.

On Fri, 31 Oct 2008, Anthony Minessale wrote: