Mike, thanks for the reply.

Mmm… looks like I need more detailed instructions where to dig…

Is there a way to turn off “challenging” completely?

I thought that <param name="auth-calls" value="false"/> should do it, but alas…

By the way should this parameter be visible in either “sofia status profile external” or “sofia status gateway sipx4.lab.nstel.ru” ? I don’t see it…

I attached traces of failed and successful calls.

Thanks and regards,

Nikolay.

From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Michael Jerris
Sent: Wednesday, January 13, 2010 8:30 PM
To: freeswitch-users@lists.freeswitch.org
Subject: Re: [Freeswitch-users] sip trunk question: why call throughexternal profile is challenged?

Look at how sipx sets up the users when they build the extensions and such for conferences, there was something special here, but I can't recall what.

Mike

On Jan 13, 2010, at 9:10 AM, Nikolay Kondratyev wrote:

Hi all!

I’m brand new to FreeSwitch, but have some experience with SipX.

Our company is evaluating FS.

For test purposes I set up FS on a virtual machine (vmware esxi). I use CentOS.

The FS version I use is 1.0.5-20100110-0400.

I have a question regarding sip trunk between FS and SipX.

I created the following GW in external profile:

[freeswitch@freeswitch external]$ cat sipx-lab.xml | grep -v '<!--'

</gateway>

</include>

External.xml file is not modified after installation.

I see this gateway via fs_cli:

freeswitch@internal> sofia status gateway sipx4.lab.nstel.ru

=================================================================================================

Name sipx4.lab.nstel.ru

Profile external

Scheme Digest

Realm sipx4.lab.nstel.ru

Username zxcv

Password yes

From <sip:zxcv@sipx4.lab.nstel.ru;transport=udp>

Contact <sip:gw+sipx4.lab.nstel.ru@172.23.22.49:5080;transport=udp;gw=sipx4.lab.nstel.ru>

Exten zxcv

To sip:zxcv@sipx4.lab.nstel.ru

Proxy sip:sipx4.lab.nstel.ru

Context public

Expires 3600

Freq 3600

Ping 0

PingFreq 0

PingState 0/0/0

State NOREG

Status UP

CallsIN 0

CallsOUT 0

=================================================================================================

I created new FS extension 2853. I registers (xlite) and I can call it.

Now I want to call FS user from sipx.

From the sipx side one can configure link to FS differently. There are two options:

1. Call FS directly trough sipxproxy (the core part of sipx works as sip proxy, not as b2bua)

2. Call trough embedded b2bua, named sipxbridge.

When a call is going trough sipxbridge, it is successfully landed at FS extension 2853.

But when a call is going from the sipxproxy, it is challenged with Status 407 “proxy authentication required’, and then call fails.

(I’m not sure if sipx should handle this challenge, but this is separate question for the sipx forum).

At the default log level I see nothing in the freeswitch.log.

So the question is why one call through external profile is being challenged while the other is not?

I suspect that the reason is in the difference in the two Invite messages:

Here is challenged Invite:

INVITE sip:2853@fs.lab.nstel.ru:5080;transport=udp SIP/2.0

Record-Route: <sip:172.23.12.104:5060;lr;sipXecs-rs=%2Aauth%7E.%2Afrom%7EOTRiZjI3MjgtYWMxNzBjZTktMTNjNC0yZjZkZWMtNjNkNmUwN2UtMmY2ZGVj.900_ntap%2Aid%7EMjIyNjAtMQ%60%60%213ba6d85f6946c4c6001bee1d3b54474f>

From: "testphone3857"<sip:3857@lab.nstel.ru>;tag=94bf2728-ac170ce9-13c4-2f6dec-63d6e07e-2f6dec

To: <sip:2853@lab.nstel.ru>

Call-Id: 94bed2a0-ac170ce9-13c4-2f6dec-68ffdb81-2f6dec@lab.nstel.ru

Cseq: 2 INVITE

Via: SIP/2.0/UDP 172.23.12.104;branch=z9hG4bK-sipXecs-000eaf48a36fe4029c7cde004a6f44424847

Via: SIP/2.0/TCP 172.23.12.104;branch=z9hG4bK-sipXecs-000bf3008cfa3f3e70470789c75232ba9499~ac7fd729330fd563f83cacd941311e75;id=22260-1

Via: SIP/2.0/UDP 172.23.12.233:5060;branch=z9hG4bK-2f6dec-b9456412-7ad07784

Max-Forwards: 18

Supported: replaces

User-Agent: LG-Nortel LIP 6812 v1.2.38sp SN/00405A18B634

Contact: <sip:3857@172.23.12.233:5060;x-sipX-nonat>

Proxy-Authorization: Digest username="3857",realm="lab.nstel.ru",nonce="e2152722611af1bbe59f3a8eb31b8eb84b4db2ca",uri="sip:2853@lab.nstel.ru",response="a09c34fbd897783c9b9af50bd044ccaa",algorithm=MD5

Content-Type: application/sdp

Content-Length: 301

Date: Wed, 13 Jan 2010 11:47:22 GMT

Expires: 60

X-Sipx-Handled: X172.23.12.104-81.211.30.104

v=0

o=LGEIPP 16246 16247 IN IP4 172.23.12.233

s=SIP Call

c=IN IP4 172.23.12.233

t=0 0

m=audio 23008 RTP/AVP 0 8 18 4 101

a=rtpmap:0 PCMU/8000

a=rtpmap:8 PCMA/8000

a=rtpmap:18 G729/8000

a=rtpmap:4 G723/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:18 annexb=no

a=fmtp:101 0-11

a=sendrecv

And here is successful Invite:

INVITE sip:2853@fs.lab.nstel.ru;user=phone SIP/2.0

Call-ID: 94bec3b8-ac170ce9-13c4-2f6d47-2fee09d0-2f6d47@lab.nstel.ru.0

CSeq: 1 INVITE

From: "testphone3857" <sip:3857@172.23.12.104>;tag=816640414244159961

To: <sip:2853@fs.lab.nstel.ru;user=phone>

Via: SIP/2.0/UDP 172.23.12.104:5080;branch=z9hG4bK885dde2c8680f5315845cd3350b8b605373534

Max-Forwards: 70

User-Agent: sipXecs/4.0.2 sipXecs/sipxbridge (Linux)

P-Asserted-Identity: <sip:1004@172.23.12.104>

Contact: <sip:1004@172.23.12.104:5080;transport=udp>

Route: <sip:172.23.22.49:5080;transport=udp;lr>

Session-Expires: 1800;refresher=uac

Allow: INVITE,BYE,ACK,CANCEL,OPTIONS

Content-Type: application/sdp

Content-Length: 315

v=0

o=sipxbridge 6640787141824452741 1 IN IP4 172.23.12.104

s=SIP Call

c=IN IP4 172.23.12.104