Can I add the authorization to a call?
Moderator: Brekeke Support Team
Can I add the authorization to a call?
1. Brekeke Product Name and Version: 2.4.8.6/286.3
2. Java version: 1.6.0_05
3. OS type and the version: Windows Server 2008
4. UA (phone), gateway or other hardware/software involved:
5. Your problem:
My setup:
T38 Fax Client <---> Brekeke Sip Server <---> Multiple SIP providers
I have a fax client receiving t.38 calls from multiple providers. All off them but one authorize us by IP. One of them needs us to send username/password to be able to receive the fax. I can't put the authorization info on the fax client, that way all providers will receive this info.
My question is, can I add the authorization info on BS to a call? If the call comes from x provider, add the authorization info to the call. Is it possible?
2. Java version: 1.6.0_05
3. OS type and the version: Windows Server 2008
4. UA (phone), gateway or other hardware/software involved:
5. Your problem:
My setup:
T38 Fax Client <---> Brekeke Sip Server <---> Multiple SIP providers
I have a fax client receiving t.38 calls from multiple providers. All off them but one authorize us by IP. One of them needs us to send username/password to be able to receive the fax. I can't put the authorization info on the fax client, that way all providers will receive this info.
My question is, can I add the authorization info on BS to a call? If the call comes from x provider, add the authorization info to the call. Is it possible?
Yes, the Authorization part of the SIP header looks like this:Harold wrote:Do you know which SIP header it is?
It it based on SIP's digest authentication?
Code: Select all
Authorization: Digest username="abc",realm="aaa.bbb.ccc",nonce="xxxx",uri="sip:123@x.x.x.x",response="abc",algorithm=MD5,cnonce="123",qop=auth,nc=00000001
It seems like the provider send an INVITE and then the client sends and INVITE back:Laurie wrote:ioan,
If a provider sends an INVITE, I think you don't need any authentication for the FAX client. Is it correct?
INVITE sip:2027217140@150.12.12.53:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 139.24.5.16:5060;branch=z9hG4bKfk4b3m30e8606r7b75e0.1
Via: SIP/2.0/UDP 10.0.1.10:5060;received=10.0.1.10;branch=z9hG4bK-6b205c72d30b82b665a94abcdc92a9771-10.0.1.10-1;rport=5060
Allow-Events: message-summary, refer, dialog, line-seize, presence, call-info, as-feature-event
Call-ID: 14BFA11D@10.0.1.10
From: "Test, Test" <sip:5075812758@139.24.5.16:5060>;tag=10.0.1.10+1+487e14+23a32d02;isup-oli=00
To: <sip:2027217140@150.12.12.53>
CSeq: 219567218 INVITE
Expires: 180
Organization: MetaSwitch
Supported: resource-priority, 100rel
Content-Length: 126
Content-Type: application/sdp
Max-Forwards: 69
Contact: "Test, Test" <sip:5075812758@139.24.5.16:5060;transport=udp>;isup-oli=00
P-Asserted-Identity: "Test, Test" <sip:5075812758@139.24.5.16:5060>
v=0
o=- 3755718694 3755718694 IN IP4 139.24.5.16
s=-
c=IN IP4 139.24.5.16
t=0 0
m=audio 11908 RTP/AVP 0
a=ptime:20
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 139.24.5.16:5060;branch=z9hG4bKfk4b3m30e8606r7b75e0.1
Via: SIP/2.0/UDP 10.0.1.10:5060;received=10.0.1.10;branch=z9hG4bK-6b205c72d30b82b665a94abcdc92a9771-10.0.1.10-1;rport=5060
From: "Test, Test" <sip:5075812758@139.24.5.16:5060>;tag=10.0.1.10+1+487e14+23a32d02;isup-oli=00
To: <sip:2027217140@150.12.12.53>
Call-ID: 14BFA11D@10.0.1.10
CSeq: 219567218 INVITE
Server: Brekeke SIP Server rev.286.3
Content-Length: 0
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 139.24.5.16:5060;branch=z9hG4bKfk4b3m30e8606r7b75e0.1
Via: SIP/2.0/UDP 10.0.1.10:5060;received=10.0.1.10;branch=z9hG4bK-6b205c72d30b82b665a94abcdc92a9771-10.0.1.10-1;rport=5060
Record-Route: <sip:150.12.12.53:5060;lr>
From: "Test, Test" <sip:5075812758@139.24.5.16:5060>;tag=10.0.1.10+1+487e14+23a32d02;isup-oli=00
To: <sip:2027217140@150.12.12.53>;tag=IPF_PORT_0010_100D
Call-ID: 14BFA11D@10.0.1.10
CSeq: 219567218 INVITE
Contact: <sip:2027217140@150.12.12.53:5060>
User-Agent: Fax Client
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/UDP 139.24.5.16:5060;branch=z9hG4bKfk4b3m30e8606r7b75e0.1
Via: SIP/2.0/UDP 10.0.1.10:5060;received=10.0.1.10;branch=z9hG4bK-6b205c72d30b82b665a94abcdc92a9771-10.0.1.10-1;rport=5060
Record-Route: <sip:150.12.12.53:5060;lr>
From: "Test, Test" <sip:5075812758@139.24.5.16:5060>;tag=10.0.1.10+1+487e14+23a32d02;isup-oli=00
To: <sip:2027217140@150.12.12.53>;tag=IPF_PORT_0010_100D
Call-ID: 14BFA11D@10.0.1.10
CSeq: 219567218 INVITE
Contact: <sip:2027217140@150.12.12.53:5060>
User-Agent: Fax Client
Allow: INVITE, ACK, BYE, CANCEL, REFER, NOTIFY
Content-Type: application/sdp
Content-Length: 166
v=0
o=IPFax 0 0 IN IP4 54.245.113.67
s=SIP Fax Call
i=IPFax
c=IN IP4 54.245.113.67
t=0 0
m=audio 49190 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=ptime:20
a=sendrecv
ACK sip:2027217140@150.12.12.53:5060 SIP/2.0
Via: SIP/2.0/UDP 139.24.5.16:5060;branch=z9hG4bKi45nd310eg91gpf4h6j1.1
Via: SIP/2.0/UDP 10.0.1.10:5060;branch=z9hG4bK-85e5febf326d844d75358a669b6c1b1b1-10.0.1.10-1
Allow-Events: message-summary, refer, dialog, line-seize, presence, call-info, as-feature-event
Max-Forwards: 69
Call-ID: 14BFA11D@10.0.1.10
From: "Test, Test" <sip:5075812758@139.24.5.16:5060>;tag=10.0.1.10+1+487e14+23a32d02;isup-oli=00
To: <sip:2027217140@150.12.12.53>;tag=IPF_PORT_0010_100D
CSeq: 219567218 ACK
Contact: "Test, Test" <sip:5075812758@139.24.5.16:5060;transport=udp>;isup-oli=00
Organization: MetaSwitch
Content-Length: 0
Route: <sip:150.12.12.53:5060;lr>
INVITE sip:5075812758@139.24.5.16:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 150.12.12.53:5060;rport;branch=z9hG4bK2f11ddf77f6fe11431cb5-efab17c9-8b5d5f67
Via: SIP/2.0/UDP 10.248.1.115:5060;branch=z9hG4bK100E;received=54.245.113.67
From: <sip:2027217140@150.12.12.53>;tag=IPF_PORT_0010_100D
To: "Test, Test" <sip:5075812758@139.24.5.16:5060>;tag=10.0.1.10+1+487e14+23a32d02;isup-oli=00
Call-ID: 14BFA11D@10.0.1.10
CSeq: 219567219 INVITE
Max-Forwards: 69
Contact: <sip:2027217140@150.12.12.53:5060>
User-Agent: Fax Client
Supported: timer,replaces,billing,presence,*
Allow: INVITE, ACK, BYE, CANCEL, REFER, NOTIFY
P-Behind-NAT: Yes
Record-Route: <sip:150.12.12.53:5060;lr>
Content-Type: application/sdp
Content-Length: 280
v=0
o=IPFax 0 1 IN IP4 54.245.113.67
s=SIP Fax Call
i=IPFax
c=IN IP4 54.245.113.67
t=0 0
m=image 49170 udptl t38
a=T38FaxVersion:0
a=T38MaxBitRate:14400
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxBuffer:200
a=T38FaxMaxDatagram:72
a=T38FaxUdpEC:t38UDPRedundancy
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 150.12.12.53:5060;received=150.12.12.53;branch=z9hG4bK2f11ddf77f6fe11431cb5-efab17c9-8b5d5f67;rport=5060
Via: SIP/2.0/UDP 10.248.1.115:5060;received=54.245.113.67;branch=z9hG4bK100E
From: <sip:2027217140@139.24.5.16>;tag=IPF_PORT_0010_100D
To: "Test, Test" <sip:5075812758@150.12.12.53:5060>;tag=10.0.1.10+1+487e14+23a32d02;isup-oli=00
Call-ID: 14BFA11D@10.0.1.10
CSeq: 219567219 INVITE
WWW-Authenticate: Digest realm="accesspbx.someprovider.com",nonce="2ed257a3b66b",stale=false,algorithm=MD5,qop="auth"
Server: DC-SIP/2.0
Organization: MetaSwitch
Supported: resource-priority, 100rel
Content-Length: 0
Did you make this fax client? or someone else?
Ask the developer why it sends INVITE to the caller in the above case.
Since both initial INVITE and and second INVITE were on the same Call-ID: 14BFA11D@10.0.1.10, the second one is a re-INVITE .
Generally re-INVITE doesn't have to have authentication headers.
but it seems the provider requires authentication with "401 Unauthorized".
Ask the developer to look at the packet trace.
Ask the developer why it sends INVITE to the caller in the above case.
Since both initial INVITE and and second INVITE were on the same Call-ID: 14BFA11D@10.0.1.10, the second one is a re-INVITE .
Generally re-INVITE doesn't have to have authentication headers.
but it seems the provider requires authentication with "401 Unauthorized".
Ask the developer to look at the packet trace.
I did not make the client.Laurie wrote:Did you make this fax client? or someone else?
Generally re-INVITE doesn't have to have authentication headers.
but it seems the provider requires authentication with "401 Unauthorized".
The provider requires authentication and told me that there is no way around it, so my question still stands:
Can I add the authentication info to the call on the BS?