sip trunk question: why call through external profile is challenged?
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 '<!--' <include> <gateway name="sipx4.lab.nstel.ru"> <param name="username" value="zxcv"/> <param name="password" value="2007"/> <param name="register" value="false"/> </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.nste l.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%7EOTRiZjI3MjgtYWMxN zBjZTktMTNjNC0yZjZkZWMtNjNkNmUwN2UtMmY2ZGVj.900_ntap%2Aid%7EMjIyNjAtMQ%60%60 %213ba6d85f6946c4c6001bee1d3b54474f> From: "testphone3857"<sip:3857@lab.nstel.ru>;tag=94bf2728-ac170ce9-13c4-2f6dec-63d 6e07e-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~ac 7fd729330fd563f83cacd941311e75;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="e2152722611af1bbe59f3a8eb31b8eb8 4b4db2ca",uri="sip:2853@lab.nstel.ru",response="a09c34fbd897783c9b9af50bd044 ccaa",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 t=0 0 m=audio 30248 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 Can somebody please if it is a FS configuration problem or a software problem or is it a problem on the sipx side? Thanks in advance, Nikolay.
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 '<!--' <include> <gateway name="sipx4.lab.nstel.ru"> <param name="username" value="zxcv"/> <param name="password" value="2007"/> <param name="register" value="false"/> </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 t=0 0 m=audio 30248 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
Can somebody please if it is a FS configuration problem or a software problem or is it a problem on the sipx side?
Thanks in advance, Nikolay. _______________________________________________ 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
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 '<!--' <include> <gateway name="sipx4.lab.nstel.ru"> <param name="username" value="zxcv"/> <param name="password" value="2007"/> <param name="register" value="false"/> </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.nste l.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%7EOTRiZjI3MjgtYWMxN zBjZTktMTNjNC0yZjZkZWMtNjNkNmUwN2UtMmY2ZGVj.900_ntap%2Aid%7EMjIyNjAtMQ%60%60 %213ba6d85f6946c4c6001bee1d3b54474f> From: "testphone3857"<sip:3857@lab.nstel.ru>;tag=94bf2728-ac170ce9-13c4-2f6dec-63d 6e07e-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~ac 7fd729330fd563f83cacd941311e75;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="e2152722611af1bbe59f3a8eb31b8eb8 4b4db2ca",uri="sip:2853@lab.nstel.ru",response="a09c34fbd897783c9b9af50bd044 ccaa",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 t=0 0 m=audio 30248 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 Can somebody please if it is a FS configuration problem or a software problem or is it a problem on the sipx side? Thanks in advance, Nikolay. _______________________________________________ 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
if you look in the sample configs for the words blind and auth you will find all these settings, also you can setup acls for ip auth to not challenge. Mike On Jan 14, 2010, at 3:26 AM, Nikolay Kondratyev wrote:
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 '<!--' <include> <gateway name="sipx4.lab.nstel.ru"> <param name="username" value="zxcv"/> <param name="password" value="2007"/> <param name="register" value="false"/> </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 t=0 0 m=audio 30248 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
Can somebody please if it is a FS configuration problem or a software problem or is it a problem on the sipx side?
Thanks in advance, Nikolay. _______________________________________________ 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
<call_from_sipx_via_unmanaged_gw.pcap><call_from_sipx_via_siptrunk_sip-only.pcap>_______________________________________________ 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
try setting param accept-blind-auth to true in your sofia profile config internal.xml iirc it was made just for sipX who feels the need to send auth headers even when nobody asked for them. so even when auth-calls is false we will still try to parse the auth if one is sent. On Thu, Jan 14, 2010 at 11:21 AM, Michael Jerris <mike@jerris.com> wrote:
if you look in the sample configs for the words blind and auth you will find all these settings, also you can setup acls for ip auth to not challenge.
Mike
On Jan 14, 2010, at 3:26 AM, Nikolay Kondratyev wrote:
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 '<!--'
<include>
<gateway name="sipx4.lab.nstel.ru">
<param name="username" value="zxcv"/>
<param name="password" value="2007"/>
<param name="register" value="false"/>
</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
t=0 0
m=audio 30248 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
Can somebody please if it is a FS configuration problem or a software problem or is it a problem on the sipx side?
Thanks in advance,
Nikolay.
_______________________________________________ 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
<call_from_sipx_via_unmanaged_gw.pcap> <call_from_sipx_via_siptrunk_sip-only.pcap> _______________________________________________
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
_______________________________________________ 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 II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:+19193869900
This now rings a bell, also, if you create a gateway on that profile who's gateway name matches the realm on the incoming auth header, I think that also was working. Mike On Jan 14, 2010, at 5:01 PM, Anthony Minessale wrote:
try setting param accept-blind-auth to true in your sofia profile config internal.xml iirc it was made just for sipX who feels the need to send auth headers even when nobody asked for them. so even when auth-calls is false we will still try to parse the auth if one is sent.
On Thu, Jan 14, 2010 at 11:21 AM, Michael Jerris <mike@jerris.com> wrote: if you look in the sample configs for the words blind and auth you will find all these settings, also you can setup acls for ip auth to not challenge.
Mike
On Jan 14, 2010, at 3:26 AM, Nikolay Kondratyev wrote:
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.
Mike, Anthony, thanks for the advice. I set accept-blind-auth in my external profile and FS does not challenge the invite any more. Did I understand right that without accept-blind-auth FS challenged incoming Invite because of the presence of Proxy-Authorization header in the Invite? Do I understand right that if I place accept-blind-auth inside <gateway></gateway> it will work for that gateway only? Thank and regards, Nikolay. _____ From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Michael Jerris Sent: Friday, January 15, 2010 1:22 AM To: freeswitch-users@lists.freeswitch.org Subject: Re: [Freeswitch-users] sip trunk question: why call throughexternalprofile is challenged? This now rings a bell, also, if you create a gateway on that profile who's gateway name matches the realm on the incoming auth header, I think that also was working. Mike On Jan 14, 2010, at 5:01 PM, Anthony Minessale wrote: try setting param accept-blind-auth to true in your sofia profile config internal.xml iirc it was made just for sipX who feels the need to send auth headers even when nobody asked for them. so even when auth-calls is false we will still try to parse the auth if one is sent. On Thu, Jan 14, 2010 at 11:21 AM, Michael Jerris <mike@jerris.com> wrote: if you look in the sample configs for the words blind and auth you will find all these settings, also you can setup acls for ip auth to not challenge. Mike On Jan 14, 2010, at 3:26 AM, Nikolay Kondratyev wrote: 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 <http://sipx4.lab.nstel.ru/> " ? I don't see it. I attached traces of failed and successful calls.
I am pretty sure that does not work, as we have not matched the gateway yet. Mike On Jan 15, 2010, at 9:57 AM, Nikolay Kondratyev wrote:
Mike, Anthony, thanks for the advice. I set accept-blind-auth in my external profile and FS does not challenge the invite any more. Did I understand right that without accept-blind-auth FS challenged incoming Invite because of the presence of Proxy-Authorization header in the Invite? Do I understand right that if I place accept-blind-auth inside <gateway></gateway> it will work for that gateway only? Thank and regards, Nikolay.
From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Michael Jerris Sent: Friday, January 15, 2010 1:22 AM To: freeswitch-users@lists.freeswitch.org Subject: Re: [Freeswitch-users] sip trunk question: why call throughexternalprofile is challenged?
This now rings a bell, also, if you create a gateway on that profile who's gateway name matches the realm on the incoming auth header, I think that also was working.
Mike
On Jan 14, 2010, at 5:01 PM, Anthony Minessale wrote:
try setting param accept-blind-auth to true in your sofia profile config internal.xml iirc it was made just for sipX who feels the need to send auth headers even when nobody asked for them. so even when auth-calls is false we will still try to parse the auth if one is sent.
On Thu, Jan 14, 2010 at 11:21 AM, Michael Jerris <mike@jerris.com> wrote:
if you look in the sample configs for the words blind and auth you will find all these settings, also you can setup acls for ip auth to not challenge.
Mike
On Jan 14, 2010, at 3:26 AM, Nikolay Kondratyev wrote:
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.
_______________________________________________ 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
participants (3)
-
Anthony Minessale
-
Michael Jerris
-
Nikolay Kondratyev